1. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 1/39 June 17, 2005 Building Verifiable Software Prototypes Using Coloured Petri Nets Michael Westergaard Department of Computer Science University of Aarhus Denmark

2. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 2/39June 17, 2005 Overview Example Towards a New State-space Tool Model-based Prototyping and Animation Towards an Interchange Format for Coloured Petri Nets

3. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 3/39June 17, 2005 Example (1/2) 2 runners in a race, halfway through the race is a stand with water Either run) a runner runs to the drink stand, win) a runner wins the race, or lose) a runner loses the race Only one runner can win the race In the beginning neither of the runners have finished any laps

4. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 4/39June 17, 2005 Example (2/2)

5. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 5/39June 17, 2005 Example (2/2)

6. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 6/39June 17, 2005 Example (2/2)

7. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 7/39June 17, 2005 Example (2/2)

8. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 8/39June 17, 2005 Example (2/2)

9. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 9/39 June 17, 2005 Towards a New State-space Tool

10. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 10/39June 17, 2005 Analysis We want to check that our model contains no errors (e.g. that at most one runner can win) Generate the state space, a directed graph with states as nodes and transitions as edges The problem: The state space is large Solution: Make the state space smaller, store only parts of it, or represent the state space in a clever way

11. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 11/39June 17, 2005 The Sweep-Line Method We assume a progress measure, , that assigns to each state a progress value, such that s->s’ =>  (s)≤  (s’) Here, we take  (n,m,b)=n All states to be processed are in front of the sweep- line All new states are added in front of the sweep-line We do not need the states behind the sweep-line; they can safely be removed from memory progress 0132 Not yet discovered state Discovered but unprocessed state Processed state sweep-line

12. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 12/39June 17, 2005 A Condensed Representation We want to represent the entire state space A state of the system is (n,m,b) with n,m  {0…3} and b  {u,d} Only some (10) of the syntactically possible states (4·4·2=32) are reachable At least ceil(log(32))=5 bits are used to store each state, although ceil(log(10))=4 bits would suffice In realistic examples, the number of syntactically possible states is much larger than the number of reachable states, so distinguishing only between reachable states yields a good reduction Alas, we first know the number of reachable states, when we have constructed the reachability graph

13. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 13/39June 17, 2005 Neighbor List We assume that we can enumerate the transitions Assign to each reachable state a number, 0…R-1 Number of transitions Transition Destination state State number 0 1 0 2 0 0 1 1 1 1 1 2 01 23 54 6 9 8 7 0 = run 1 = win 2 = lose

14. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 14/39June 17, 2005 On-the-fly Construction of the Condensed Representation State number Number of transitions New header: Number of bits used to represent the successor states Transition Destination state

15. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 15/39June 17, 2005 Experimental Results In the report, I present an architecture of a state- space tool A prototypical implementation of the described method has been made in the state-space tool presented in the report The implementation does not take into account the different sizes of the numbers, and encodes everything in a machine word

16. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 16/39June 17, 2005 Experimental Results (Runner Example)

17. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 17/39June 17, 2005 Experimental Results (Database Managers)

18. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 18/39June 17, 2005 Experimental Results (Dining Philosophers)

19. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 19/39 June 17, 2005 Model-based Prototyping and Animation

20. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 20/39June 17, 2005 Need for Visualization While the modeling language is graphical, the model is difficult to grasp unless you know Coloured Petri nets or some similar formalism It would be nicer to see the model like this: The goal of this work is to make this possible

21. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 21/39June 17, 2005 Model-driven Prototype Approach

22. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 22/39June 17, 2005 Model-View-Controller

23. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 23/39June 17, 2005 Model-View-Controller Animation GUICPN model

24. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 24/39June 17, 2005 Architecture View Controller + Model Animation Prototype GUI Model-driven prototype Prototype GUI Final product Real implementation Test driver Verification

25. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 25/39June 17, 2005 Case-study: Interoperability Protocol

26. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 26/39 June 17, 2005 Towards an Interchange Format for Coloured Petri Nets

27. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 27/39June 17, 2005 Benefits of being Able to Interchange Coloured Petri Nets Repository of models –Teaching –Benchmarks It is possible to build tools are able to construct models and other tools that analyze the models

28. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 28/39June 17, 2005 Difficulties Labels are not just non-negative integers, but can range over an arbitrary domain – is “1`r(1)++1`r(2)” the same as “ +1* ”? High-level Petri nets (HLPN) often support elaborate composition mechanisms, which have to be dealt with – should we extend PNML to support hierarchical nets? (See the report) Start 1`r(1)++1`r(2) RUNNER

29. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 29/39June 17, 2005 Start 1`r(1)++1`r(2) RUNNER Take as example a net with a place named Start with domain RUNNER and initial marking one token with value r(1) and one token with value r(2) We notice 1)Three labels, the domain, the initial marking, and the name 2)The initial marking is rather complex, and several reasonable concrete syntaxes can express it, e.g. CPN Tools: 1`r(1)++1`r(2) CPN-AMI: + 1* Labels

30. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 30/39June 17, 2005 Example We would store the initial marking as follows (using the concrete syntax of CPN Tools): 1`r(1)++1`r(2) Advantage Very simple approach; easy to implement and understand Disadvantage Different tools use different syntaxes to express the same –CPN Tools: 1`r(1)++1`r(2), or –CPN-AMI: + 1*. and this makes interchange difficult Start 1`r(1)++1`r(2) RUNNER Labels – Solution 1: Store as Concrete Syntax

31. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 31/39June 17, 2005 Labels – Solution 2: Store as Abstract Syntax Tree Example We would store the initial marking as follows: r(1) r(2) Advantage Eliminates differences in concrete syntax Disadvantages Difficult to make simple editors that do not completely parse and check inscriptions Cumbersome to add new features, as a new AST node has to be defined Start 1`r(1)++1`r(2) RUNNER

32. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 32/39June 17, 2005 Labels – Solution 3: Mix Abstract and Concrete Syntax Example We would allowing the initial marking to be stored as either: 1`r(1)++1`r(2) or r(1) r(2) Advantages Tools can save as much or as little using abstract syntax as desired – trade-off between interchangeability and simplicity New features can easily be incorporated by using concrete syntax until an appropriate AST node is defined Start 1`r(1)++1`r(2) RUNNER

33. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 33/39June 17, 2005 Labels – Solution 3: Mix Abstract and Concrete Syntax Added benefits Allows an incremental transition to the interchange format, as tool implementers can choose to save only some (parts of) labels as ASTs Allows the format to be used as primary storage format, as incorrect (and therefore unparsable) inscriptions can be saved using concrete syntax

34. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 34/39 June 17, 2005 Conclusion and Future Plans

35. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 35/39June 17, 2005 Conclusion State-space Analysis We have seen an efficient representation of reachability graphs, and how this representation can be traversed for analysis We have seen how the efficient representation can be calculated efficiently using the sweep-line method We have seen how the method performs on some examples – basically, the method performs well when the sweep-line method performs well, i.e. for systems with a clear notion of progress

36. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 36/39June 17, 2005 Conclusion Model-based Prototyping We have seen that animation of formal models may be beneficial We have introduced the architecture of a tool to support animation of formal models The architecture is based on the Model-View- Controller design pattern By interchanging parts, the animation tool supports –Animation of models –Model-based prototyping –The final product –Verification

37. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 37/39June 17, 2005 Conclusion Interchange Format We have shown 3 different ways to represent labels: 1)using concrete syntax only, 2)using abstract syntax only, and 3)using a mixture of concrete and abstract syntax. We have argued that the 3 rd way is the best, as it is more flexible and allows interchange between tools not sharing concrete syntax

38. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 38/39June 17, 2005 Main Contributions State-space Design/implementation of new state-space tool Design/implementation/test of new reduction technique Design/implementation of state-space analysis of Bigraphical Reactive Systems Model-based prototyping/animation Design/implementation of animation tool –Very flexible architecture Use of animation tool in case-study Interchange of Coloured Petri nets Mix of concrete and abstract syntax for labels Translations from common composition mechanisms to Modular PNML

39. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 39/39June 17, 2005 Future Work Work on model-based prototyping and interchanging Coloured Petri nets is done I will concentrate on state-space analysis during part B –Benchmark the sweep-line method –Visit to Aalborg –Modal logic for (Coloured) Petri nets –Partial state spaces –Telebit project –...

40. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 40/39June 17, 2005 Traversal of Neighbor List We assume the existence of a (partial) mapping next that for a state and a transition gives the next state (e.g. next((1,0), t 3 )=(2,1)) We have not lost any information with this reduction, so analysis is still possible; for example a depth-first traversal would look like: DFS( 0, s I ) proc DFS( i, m ) if (visited( i )) return analyse( m ) for each ( t, i’ ) in E[ i ] DFS( i’, next( m, t )) end for end proc

41. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 41/39June 17, 2005 Labels – Solution 3: Mix Abstract and Concrete Syntax Not a clear-cut separation E. Kindler proposes in the April 2004 proposal for ISO/IEC 15909-2 a similar approach to the representation labels Kindlers proposal requires that a label is stored either using concrete syntax or using abstract syntax Our proposal allows r(1) r(1+1) which clearly is a multi set even if function application is not standardized Thus not having a clear-cut separation of abstract and concrete syntax makes it easy to simulate new AST nodes

42. Building Verifiable Software Prototypes Using Coloured Petri NetsQualifying Exam 42/39June 17, 2005 Composition Constructs A number of composition constructs exist for high-level Petri nets: –Hierarchical nets –Fusion places –Synchronous channels –etc. Composition mechanisms can be represented by adding new labels or special nodes –Example: Fusion places can be implemented by adding a label fusionGroup, which indicates to what fusion group the place belongs In the report, I present a translation to Modular PNML