1. - 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hoofdstuk 2 Systeemspecificatietechnieken 2.2 Specificatietalen Prof. dr. ir. Dirk Stroobandt Academiejaar 2004-2005 De transparanten van hoofdstuk 2 werden overgenomen van Prof. Peter Marwedel (Universiteit Dortmund) en waar nodig bijgewerkt. Prof. dr. ir. Dirk Stroobandt Academiejaar 2004-2005 De transparanten van hoofdstuk 2 werden overgenomen van Prof. Peter Marwedel (Universiteit Dortmund) en waar nodig bijgewerkt.

2. - 2 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Inhoud (deel 1) Inleiding over Ingebedde systemen, System-on- Chip en Platform-gebaseerd ontwerp Systeemspecificatietechnieken Functionele specificaties Specificatietalen –Eigenschappen –SDL –Petri nets Exploratie van de ontwerpruimte Inleiding over Ingebedde systemen, System-on- Chip en Platform-gebaseerd ontwerp Systeemspecificatietechnieken Functionele specificaties Specificatietalen –Eigenschappen –SDL –Petri nets Exploratie van de ontwerpruimte

3. - 3 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Types of language specifications Homogeneous modeling Executable Homogeneous Specification CODESIGN HW SW Prototype Virtual Prototype Correspondence between concepts of specs and VP Non-trivial Correspondence between concepts of specs and VP Non-trivial

4. - 4 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Types of language specifications (2) Heterogeneous modeling CODESIGN HW model SW model Prototype Heterogeneous Specification Multilanguage specification. Codesign is simple mapping of HW and SW models on parts. Validation and interfacing is key. Burden mainly on designer. Multilanguage specification. Codesign is simple mapping of HW and SW models on parts. Validation and interfacing is key. Burden mainly on designer.

5. - 5 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Some general properties of languages 1. Synchronous vs. asynchronous languages Description of several processes in many languages non- deterministic: The order in which executable tasks are executed is not specified (may affect result). Synchronous languages: based on automata models. Synchronous languages describe concurrently operating automata. „.. when automata are composed in parallel, a transition of the product is made of the "simultaneous" transitions of all of them“. Description of several processes in many languages non- deterministic: The order in which executable tasks are executed is not specified (may affect result). Synchronous languages: based on automata models. Synchronous languages describe concurrently operating automata. „.. when automata are composed in parallel, a transition of the product is made of the "simultaneous" transitions of all of them“.

6. - 6 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Synchronous languages implicitly assume the presence of a (global) clock. Each clock tick, all inputs are considered, new outputs and states are calculated and then the transitions are made. This requires a broadcast mechanism for all parts of the model. Idealistic view of concurrency. Has the advantage of guaranteeing deterministic behavior.  StateCharts is a synchronous language. Synchronous languages implicitly assume the presence of a (global) clock. Each clock tick, all inputs are considered, new outputs and states are calculated and then the transitions are made. This requires a broadcast mechanism for all parts of the model. Idealistic view of concurrency. Has the advantage of guaranteeing deterministic behavior.  StateCharts is a synchronous language. Some general properties of languages 1. Synchronous vs. asynchronous languages

7. - 7 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Some general properties of languages 2. Properties of processes Number of processes static; dynamic (dynamically changed hardware architecture?) Nested declaration of processes or all declared at the same level Different techniques for process creation Elaboration in the source code, explicit fork and join, process creation calls  StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source code. Number of processes static; dynamic (dynamically changed hardware architecture?) Nested declaration of processes or all declared at the same level Different techniques for process creation Elaboration in the source code, explicit fork and join, process creation calls  StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source code.

8. - 8 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Some general properties of languages 3. Communication paradigms Message passing –Non-blocking communication Sender does not have to wait until message has arrived; potential problem: buffer overflow –Blocking communication, rendez-vous-based communication Sender will wait until receiver has received message –Extended rendez-vous Explicit acknowledge from receiver required. Receiver can do checking before sending acknowledgement. Message passing –Non-blocking communication Sender does not have to wait until message has arrived; potential problem: buffer overflow –Blocking communication, rendez-vous-based communication Sender will wait until receiver has received message –Extended rendez-vous Explicit acknowledge from receiver required. Receiver can do checking before sending acknowledgement.

9. - 9 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Some general properties of languages 3. Communication paradigms Shared memory Variables accessible to several tasks –Critical sections = sections at which exclusive access to some resource r must be guaranteed. Shared memory Variables accessible to several tasks –Critical sections = sections at which exclusive access to some resource r must be guaranteed.  StateCharts uses shared memory for communication between processes.

10. - 10 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Some general properties of languages 4. Specifying timing 4 types of timing specs required [Burns, 1990]: Measure elapsed time Check, how much time has elapsed since last call Means for delaying processes Possibility to specify timeouts We would like to be in a certain state only a certain maximum amount of time. Methods for specifying deadlines With current languages not available or specified in separate control file. 4 types of timing specs required [Burns, 1990]: Measure elapsed time Check, how much time has elapsed since last call Means for delaying processes Possibility to specify timeouts We would like to be in a certain state only a certain maximum amount of time. Methods for specifying deadlines With current languages not available or specified in separate control file.  StateCharts comprises a mechanism for specifying timeouts. Other types of timing specs are not supported.

11. - 11 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Properties of specification languages 5. Using non-standard I/O devices - Direct access to switches, displays etc; No protection required; OS can be much faster than for operating system with protection.  No support in standard StateCharts.  No particular OS support anyhow. Direct access to switches, displays etc; No protection required; OS can be much faster than for operating system with protection.  No support in standard StateCharts.  No particular OS support anyhow.

12. - 12 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Classification of languages Computation models of specification languages. Communication Model Concurrency Single-thread (synchronous) Distributed Control-drivenStateChart, Esterel, SML VHDL, OCCAM, SDL Data-drivenSILAGE, LUSTRE, SIGNAL Asynchronous Data flow

13. - 13 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Synthesis intermediate forms Internal representation to go from spec to architecture. Generally only one intermediate form is used. Internal representation to go from spec to architecture. Generally only one intermediate form is used. System Level Specification Language Oriented Model Architecture Oriented Model Architecture Language Oriented Refinements Architecture Oriented Refinements Graph modelsFSM models

14. - 14 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Language oriented intermediate forms Data Flow Graph (DFG) Nodes represent operators Edges represent values Data Flow Graph (DFG) Nodes represent operators Edges represent values Control Flow Graph (CFG) Loops, global exceptions, synchronization, proc. calls Nodes represent operations Edges represent sequencing relations Control Data Flow Graph (CDFG) Extends DFG with control nodes (if, case, loops) Control Flow Graph (CFG) Loops, global exceptions, synchronization, proc. calls Nodes represent operations Edges represent sequencing relations Control Data Flow Graph (CDFG) Extends DFG with control nodes (if, case, loops) +- * abcd v1v2 v3 e

15. - 15 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund CONTROLE/DATAFLOWGRAAF een neutrale representatie Graaf bestaande uit 2 soorten knopen: operatorknopen: operaties + fan-out naar alle opvolgers selectieknopen: selectie van één voorganger of opvolger (merge, join, entry, exit) Takken geven precedenties weer + eventueel data flow CDFG bevat de hele semantiek van algoritme en bevat tevens meer potentieel voor parallellisme Graaf bestaande uit 2 soorten knopen: operatorknopen: operaties + fan-out naar alle opvolgers selectieknopen: selectie van één voorganger of opvolger (merge, join, entry, exit) Takken geven precedenties weer + eventueel data flow CDFG bevat de hele semantiek van algoritme en bevat tevens meer potentieel voor parallellisme

16. - 16 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund IF-statement -- oude waarden van x,y,... if cond(x,y,..) then block1(x,y,..) else block2(x,y,..) endif -- nieuwe waarden van x,y,... IF-statement -- oude waarden van x,y,... if cond(x,y,..) then block1(x,y,..) else block2(x,y,..) endif -- nieuwe waarden van x,y,... CONTROLE/DATAFLOWGRAAF voorbeelden van syntaxis

17. - 17 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Iteratie -- oude waarden van x,y,... loop block1(x,y,...) if cond(x,y,...) then exit block2(x,y,...) endloop -- nieuwe waarden van x,y,... Iteratie -- oude waarden van x,y,... loop block1(x,y,...) if cond(x,y,...) then exit block2(x,y,...) endloop -- nieuwe waarden van x,y,... CONTROLE/DATAFLOWGRAAF voorbeelden van syntaxis

18. - 18 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Architecture oriented intermediate forms FSM with Data path model (FSMD) FSM extended with operations on data Internal variables and transitions may include operations on variables FSM with Data path model (FSMD) FSM extended with operations on data Internal variables and transitions may include operations on variables Si Sj Cij/Aij Cji/Aji Cij: A <= 0; Cji: A > 0; Aij: X := A + Y; Output <= ‘1’; Aji: X := A - Y; Output <= ‘0’;

19. - 19 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Architecture oriented intermediate forms FSM with Coprocessors (FSMC) FSMD with operations executed on coprocessors FSMD + N coprocessors C (each defined by FSMC) FSM with Coprocessors (FSMC) FSMD with operations executed on coprocessors FSMD + N coprocessors C (each defined by FSMC) Storage Units Calculation Units Co-processor 1Co-processor 2 Data path Top Controller

20. - 20 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Inhoud (deel 1) Inleiding over Ingebedde systemen, System-on- Chip en Platform-gebaseerd ontwerp Systeemspecificatietechnieken Functionele specificaties Specificatietalen –Eigenschappen –SDL –Petri nets Exploratie van de ontwerpruimte Inleiding over Ingebedde systemen, System-on- Chip en Platform-gebaseerd ontwerp Systeemspecificatietechnieken Functionele specificaties Specificatietalen –Eigenschappen –SDL –Petri nets Exploratie van de ontwerpruimte

21. - 21 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund SDL Language designed for specification of distributed systems. Dates back to early 70s, Formal semantics defined in the late 80s, Defined by ITU (International Telecommunication Union): Z.100 recommendation in 1980 Updates in 1984, 1988, 1992, 1996 and 1999 Language designed for specification of distributed systems. Dates back to early 70s, Formal semantics defined in the late 80s, Defined by ITU (International Telecommunication Union): Z.100 recommendation in 1980 Updates in 1984, 1988, 1992, 1996 and 1999

22. - 22 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund SDL Provides textual and graphical formats to please all users, Just like StateCharts, it is based on the CFSM model of computation; each FSM is called a process, However, it uses message passing instead of shared memory for communications, SDL supports operations on data. Provides textual and graphical formats to please all users, Just like StateCharts, it is based on the CFSM model of computation; each FSM is called a process, However, it uses message passing instead of shared memory for communications, SDL supports operations on data.

23. - 23 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund SDL-representation of FSMs/processes output input state

24. - 24 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Operations on data Variables can be declared locally for processes. Their type can be predefined or defined in SDL itself. SDL supports abstract data types (ADTs). Examples: Variables can be declared locally for processes. Their type can be predefined or defined in SDL itself. SDL supports abstract data types (ADTs). Examples:

25. - 25 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Communication among SDL-FSMs Communication between FSMs (or „processes“) is based on message-passing, assuming a potentially indefinitely large FIFO-queue. Each process fetches next entry from FIFO, checks if input enables transition, if yes: transition takes place, if no: input is ignored (exception: SAVE- mechanism). Each process fetches next entry from FIFO, checks if input enables transition, if yes: transition takes place, if no: input is ignored (exception: SAVE- mechanism).

26. - 26 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Process interaction diagrams Interaction between processes can be described in process interaction diagrams (special case of block diagrams). In addition to processes, these diagrams contain channels and declarations of local signals. Example: Interaction between processes can be described in process interaction diagrams (special case of block diagrams). In addition to processes, these diagrams contain channels and declarations of local signals. Example:,

27. - 27 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Designation of recipients 1.Through process identifiers: Example: OFFSPRING represents identifiers of processes generated dynamically. 2.Explicitly: By including the channel name. 3.Implicitly: If signal names imply channel names (B  Sw1) 1.Through process identifiers: Example: OFFSPRING represents identifiers of processes generated dynamically. 2.Explicitly: By including the channel name. 3.Implicitly: If signal names imply channel names (B  Sw1) Counter Via Sw1 Counter TO OFFSPRING

28. - 28 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Hierarchy in SDL Process interaction diagrams can be included in blocks. The root block is called system. Processes cannot contain other processes, unlike in StateCharts.

29. - 29 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Timers Timers can be declared locally. Elapsed timers put signal into queue (not necessarily processed immediately). RESET also removes timer signal from queue. Timers can be declared locally. Elapsed timers put signal into queue (not necessarily processed immediately). RESET also removes timer signal from queue.

30. - 30 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Additional language elements SDL includes a number of additional language elements, like procedures creation and termination of processes advanced description of data SDL includes a number of additional language elements, like procedures creation and termination of processes advanced description of data

31. - 31 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Application: description of network protocols

32. - 32 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Larger example: vending machine Machine° selling pretzels, (potato) chips, cookies, and doughnuts: accepts nickels, dime, quarters, and half- dollar coins. Not a distributed application. ° [J.M. Bergé, O. Levia, J. Roullard: High-Level System Modeling, Kluwer Academic Publishers, 1995]

33. - 33 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Overall view of vending machine

34. Decode Requests p

35. - 35 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund ChipHandler

36. - 36 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Versions and tools SDL-88 SDL-92: object orientation added SDL-96 SDL-2000: Extended graphical support; processes and blocks becoming replaced by agents. Tools for connecting to MSCs (see below) Tools for connecting to UML (see below) Tools for translation to CHILL. Information: www.sdl-forum.org SDL-88 SDL-92: object orientation added SDL-96 SDL-2000: Extended graphical support; processes and blocks becoming replaced by agents. Tools for connecting to MSCs (see below) Tools for connecting to UML (see below) Tools for translation to CHILL. Information: www.sdl-forum.org

37. - 37 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Evaluation Excellent for distributed applications (was used to specify ISDN), Commercial tools available from SINTEF, Telelogic, Cinderella (http://www.cinderella.dk). Not necessarily deterministic (order in which FSMs are reading input is unknown)  no synchronous language, Implementation requires bound for the maximum length of FIFOs; may be very difficult to compute, Timer concept adequate just for soft deadlines, Limited way of using hierarchies, Limited programming language support, No description of non-functional properties. Excellent for distributed applications (was used to specify ISDN), Commercial tools available from SINTEF, Telelogic, Cinderella (http://www.cinderella.dk). Not necessarily deterministic (order in which FSMs are reading input is unknown)  no synchronous language, Implementation requires bound for the maximum length of FIFOs; may be very difficult to compute, Timer concept adequate just for soft deadlines, Limited way of using hierarchies, Limited programming language support, No description of non-functional properties.

38. - 38 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Inhoud (deel 1) Inleiding over Ingebedde systemen, System-on- Chip en Platform-gebaseerd ontwerp Systeemspecificatietechnieken Functionele specificaties Specificatietalen –Eigenschappen –SDL –Petri nets Exploratie van de ontwerpruimte Inleiding over Ingebedde systemen, System-on- Chip en Platform-gebaseerd ontwerp Systeemspecificatietechnieken Functionele specificaties Specificatietalen –Eigenschappen –SDL –Petri nets Exploratie van de ontwerpruimte

39. - 39 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Petri nets Introduced in 1962 by Carl Adam Petri in his PhD thesis. Focus on modeling causal dependencies; No global synchronization assumed (message passing only). Key elements: Conditions Either met or no met. Events May take place if certain conditions are met. Flow relation Relates conditions and events. Conditions, events and the flow relation form a bipartite graph (graph with two kinds of nodes). Introduced in 1962 by Carl Adam Petri in his PhD thesis. Focus on modeling causal dependencies; No global synchronization assumed (message passing only). Key elements: Conditions Either met or no met. Events May take place if certain conditions are met. Flow relation Relates conditions and events. Conditions, events and the flow relation form a bipartite graph (graph with two kinds of nodes).

40. - 40 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Example: Synchronization at single track rail segment „Preconditions“

41. - 41 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Playing the „token game“

42. - 42 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Conflict for resource „track“

43. - 43 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund s More complex example Thalys trains between Cologne, Amsterdam, Brussels and Paris. Synchronization at Brussels and Paris Thalys trains between Cologne, Amsterdam, Brussels and Paris. Synchronization at Brussels and Paris

44. - 44 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Condition/event nets Def.: N=(C,E,F) is called a net, iff the following holds 1.C and E are disjoint sets 2.F  (C  E)  (E  C); is binary relation, („flow relation“) Def.: Let N be a net and let x  (C  E).  x := {y | y F x} is called the set of preconditions. x  := {y | x F y} is called the set of postconditions. Example: Def.: N=(C,E,F) is called a net, iff the following holds 1.C and E are disjoint sets 2.F  (C  E)  (E  C); is binary relation, („flow relation“) Def.: Let N be a net and let x  (C  E).  x := {y | y F x} is called the set of preconditions. x  := {y | x F y} is called the set of postconditions. Example: x xx xx

45. - 45 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Loops and pure nets Def.: Let (c,e)  C  E. (c,e) is called a loop iff cFe  eFc. Def.: Net N=(C,E,F) is called pure, if F does not contain any loops.

46. - 46 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Simple nets Def.: A net is called simple, if disjoint elements have disjoint pre- and postcondition sets. Example (not a simple net): Def.: A net is called simple, if disjoint elements have disjoint pre- and postcondition sets. Example (not a simple net): Def.: Simple nets with no isolated elements meeting some additional restrictions are called condition/event nets (C/E nets). Def.: Simple nets with no isolated elements meeting some additional restrictions are called condition/event nets (C/E nets).

47. - 47 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Place/transition nets Def.: (P, T, F, K, W, M 0 ) is called a place/transition net iff 1.N=(P,T,F) is a net with places p  P and transitions t  T 2.K: P  ( N 0  {  }) \{0} denotes the capacity of places (  symbolizes infinite capacity) 3.W: F  ( N 0 \{0}) denotes the weight of graph edges 4.M 0 : P  N 0  {  } represents the initial marking of places Def.: (P, T, F, K, W, M 0 ) is called a place/transition net iff 1.N=(P,T,F) is a net with places p  P and transitions t  T 2.K: P  ( N 0  {  }) \{0} denotes the capacity of places (  symbolizes infinite capacity) 3.W: F  ( N 0 \{0}) denotes the weight of graph edges 4.M 0 : P  N 0  {  } represents the initial marking of places W M0M0 (Segment of some net) defaults: K =  W = 1

48. - 48 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Computing changes of markings „Firing“ transitions t generate new markings on each of the places p according to the following rules:

49. - 49 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Activated transitions Transition t is „activated“ iff Activated transitions can „take place“ or „fire“, but don‘t have to. We never talk about „time“ in the context of Petri nets. The order in which activated transitions fire, is not fixed (it is non-deterministic).

50. - 50 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Shorthand for changes of markings Let   p  P: M´(p) = M(p)+ t(p) Slide 48: +: vector add  M´ = M+ t

51. - 51 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Matrix N describing all changes of markings Def.: Matrix N of net N is a mapping N: P  T  Z (integers) such that  t  T: N(p,t)=t(p) Component in column t and row p indicates the change of the marking of place p if transition t takes place.

52. - 52 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Example: N = s

53. - 53 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Place-invariants For any transition t j  T we are looking for sets R  P of places for which the accumulated marking is constant: Example:

54. - 54 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Characteristic Vector Let:  Scalar product

55. - 55 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Condition for place invariants Accumulated marking constant for all transitions if Equivalent to N T c R = 0 where N T is the transposed of N

56. - 56 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund More detailed view of computations System of linear equations. Solution vectors must consist of zeros and ones (more complex than standard system of linear equations) Different techniques for solving equation system (manual,..)

57. - 57 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Solution vectors for Thalys example We proved that: the number of trains serving Amsterdam, Cologne and Paris remains constant. the number of train drivers remains constant. We proved that: the number of trains serving Amsterdam, Cologne and Paris remains constant. the number of train drivers remains constant. s C R,2 C R,3 C R,1 C R,4

58. - 58 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Applications Modeling of resources; modeling of mutual exclusion; modeling of synchronization. Modeling of resources; modeling of mutual exclusion; modeling of synchronization.

59. - 59 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Predicate/transition nets Goal: compact representation of complex systems. Key changes: Tokens are becoming individuals; Transitions enabled if functions at incoming edges true; Individuals generated by firing transitions defined through functions Changes can be explained by folding and unfolding C/E nets,  semantics can be defined by C/E nets. Goal: compact representation of complex systems. Key changes: Tokens are becoming individuals; Transitions enabled if functions at incoming edges true; Individuals generated by firing transitions defined through functions Changes can be explained by folding and unfolding C/E nets,  semantics can be defined by C/E nets.

60. - 60 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Example: Dining philosophers problem n>1 philosophers sitting at a round table; n forks, n plates with spaghetti; philosophers either thinking or eating spaghetti (using left and right fork). n>1 philosophers sitting at a round table; n forks, n plates with spaghetti; philosophers either thinking or eating spaghetti (using left and right fork). How to model conflict for forks? How to guarantee avoiding starvation? How to model conflict for forks? How to guarantee avoiding starvation? 2 forks needed!

61. - 61 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Condition/event net model of the dining philosophers problem Let x  {1..3} t x : x is thinking e x : x is eating f x : fork x is available Let x  {1..3} t x : x is thinking e x : x is eating f x : fork x is available Model quite clumsy. Difficult to extend to more philosophers. Model quite clumsy. Difficult to extend to more philosophers.

62. - 62 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Predicate/transition model of the dining philosophers problem Let x be one of the philosophers, let l(x) be the left spoon of x, let r(x) be the right spoon of x. Let x be one of the philosophers, let l(x) be the left spoon of x, let r(x) be the right spoon of x. p1 f1 p3 p2 f2 Tokens: individuals. Semantics can be defined by replacing net by equivalent condition/event net. Model can be extended to arbitrary numbers of people. Tokens: individuals. Semantics can be defined by replacing net by equivalent condition/event net. Model can be extended to arbitrary numbers of people. p1 f1 f2 f3

63. - 63 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2003 Universität Dortmund Evaluation Pros: Appropriate for distributed applications, Well-known theory for formally proving properties, Initially a quite bizarre topic, but now accepted due to increasing number of distributed applications. Cons (for the nets presented) : problems with modeling timing, no programming elements, no hierarchy. Extensions: Enormous amounts of efforts on removing limitations. Pros: Appropriate for distributed applications, Well-known theory for formally proving properties, Initially a quite bizarre topic, but now accepted due to increasing number of distributed applications. Cons (for the nets presented) : problems with modeling timing, no programming elements, no hierarchy. Extensions: Enormous amounts of efforts on removing limitations.