Your SlideShare is downloading. ×

Exploring Petri Net State Spaces

634

Published on

Invited talk held by Karsten Wolf on June 26, 2007 on the 28th International Conference on Application and Theory of Petri Nets and Other Models of Concurrency (PETRI NETS 2007) in Siedlce, Poland.

Invited talk held by Karsten Wolf on June 26, 2007 on the 28th International Conference on Application and Theory of Petri Nets and Other Models of Concurrency (PETRI NETS 2007) in Siedlce, Poland.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
634
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Markierungen oftmals schon nach kurzer Suche gefunden bzw. Markierung mittels sweepline und dann Markierung vergrössert und mittels stubborn sets Zeugenpfad
  • What are interesting properties? -> deadlock, dead activities, will the customer always get an answer
    Other approaches are either not feature complete or have to much modelling power (ASMs) and they cannot be verified
  • Model properties that are informally specified in the BPEL specification
  • Remove the tokens
  • Transcript

    • 1. Exploring Petri Net State Spaces Karsten Wolf Universität Rostock
    • 2. Petri net models in verification Benefits: dedicated analysis techniques: – Branching prefix – Linear algebra – Siphons/traps – Coverability graph – ... This talk: Benefits even with formalism independent analysis techniques: explicit state space generation
    • 3. Roadmap • Some experience with the state space tool LoLA • The characteristics of Petri net models • Petri net specific implementation of basic state space routines • Petri net specific approaches to some state space reduction techniques
    • 4. 1. LoLA A Low Level Analyzer
    • 5. History Started in 1998 - after some years experience with INA Goal: convincing performance for reduction techniques 2000: First presented in PN Conference Since then: Integration (PNK, CPN-AMI, MC Kit) Applications
    • 6. Properties & Reduction Techniques Boundedness Reachability EF φ Deadlocks Dead transitions Liveness AG EF φ Reversibility Home states Progress GF φ Stability FG φ Eventually F φ CTL Model Checking Stubborn sets Symmetries Coverability Sweep-Line Cycle coverage State compression Goal-oriented execution Distributed version Abstraction refinement
    • 7. Application 1: GALS wrapper Background: - Cooperation with semiconductor institute in Frankfurt/O - Chip for coding/decoding 802.11 WLAN signals - GALS technology (globally asynchronous/locally synchronous) - Synchr. components embedded in asynchronous wrapper - Goal: Search for hazards in wrapper
    • 8. The Wrapper Clock Control Pausable Clock ST INT_CLK Locally - Synchronous Module Input Port DATAV_IN Output Port ACK_INT REQI1 ACKI1 stretch DATA_L DATA_OUT asynchronous wrapper LCLK REQ_INT DATAV_OUT STOPI Time-out Generator LCLKM Data Latch STOP DLE DATA_IN ACK_A REQ_A REQ_A1 ACK_B REQ_B RST
    • 9. Preprocessing: Model Reduction • Check hazards gate by gate, assume absence of hazards in remaining gates • Abstract other components AND AND OR a b c d e a b c d e
    • 10. LoLA – Clock Control: 26 states – Pausable Clock Generator: 17 states – Timeout Generator: 100 states – Input Port: 10232 states – Output Port: 201 states Reduction techniques: Stubborn sets, Sweep-Line
    • 11. Results • 2 real Hazards found • 6 further hazards in the model, excluded by engineers, due to timing constraints
    • 12. Application 2: Validation of PN Semantics for BPEL BPEL: • modelling language for business processes • BPEL process can be huge  formal verification of BPEL processes needed problems: • BPEL is specified informally • formal verification of BPEL processes not possible
    • 13. Process Sequence Flow A C D Switch B E Fault Handler Compensation Handler
    • 14. Idea of the Petri net semantics • Complete Petri net semantics for BPEL v1.1 Sequence A E Flow • Petri net patterns • interface
    • 15. Example: receive activity
    • 16. Analysis results Purchase Order Online Shop activities 17 53 places 158 410 transitions 249 1,069 states 10,000 6,300,000 red. states 1,300 440,000 Stubborn sets, Sweep-line
    • 17. Application 2‘: Verification of BPEL Choreographies • Translation to PN based on PN semantics, but simplifies most patterns • Examples from Tools4BPEL project • Choreographies include multiple instances of some services  Symmetry (+ stubborn sets) • Able to handle choreographies with 1000 service instances, 12.000 activities
    • 18. Application 3: H. Garavel‘s challenge • Petri net distributed in PN mailing list (4 responses) • 485 Places, 776 Transitions, almost 1022 states • Example stems from LOTOS specification • Problem: Quasi-Liveness LoLA solution: 776 state spaces, each checking whether one single transition is dead most state spaces trivial, due to goal orientation, 2 state spaces out of memory, but solved through goal-oriented executions Longest trace: almost 6000 transitions
    • 19. Application 4: Exploring biochemical pathways • Use LoLA at SRI • places = substances • transition = potential reaction • reachable path = chain of reactions „Use LoLA because it is so incredibly fast in finding paths“ (C. Talcott)
    • 20. Conclusion, Part 1 • LoLA applicable in various areas • Competitive performance • Easy to use, easy to integrate • Best performance in „simple“ properties • Combination of reduction techniques Next: Reason for performance: Petri nets
    • 21. 2. Petri nets
    • 22. Monotonicity of the enabling condition • If t is enabled in m and m‘>m then t is enabled in m‘ • guarded commands do not hold this property • prerequisite of coverability graph, siphon/trap, ...
    • 23. Linearity of the firing rule • m‘ = m + C t • guarded commands do not hold this property • prerequisite of invariant calculus, ... • Linearity and monotonicity are orthogonal: – reset nets: monotonous, nonlinear – inhibitor nets: nonmonotonous, linear
    • 24. Locality • Every transition depends on, and effects, only few places • State machines do not hold this property • prerequisite of branching prefix, ...
    • 25. 3. Basic routines in state space generation
    • 26. Basic routines • Checking enabledness • Firing a transition • Backtracking • Managing the visited states
    • 27. 1. Checking enabledness - After firing, only check: - previously enabled transitions which have lost tokens - previously disabled transitions which have gained tokens ... managed through explicitly stored lists For nets exhibiting locality, only „constant“ effort Monotonicity Locality
    • 28. 2. Firing transitions - Marking changed via list of pre-, list of post-places  effort does not depend on size of net For nets exhibiting locality, only „constant“ effort Locality
    • 29. 3. Backtracking - In depth-first search: fire transition backwards - In breadth-first search: implemented as incremental depth-first search For nets exhibiting locality, only „constant“ effort Locality Linearity
    • 30. Corollary: „write-only“ storage of markings current marking -fire -fire backwards t1 t2 t3 ... Search stack Set of visited markings m old/new
    • 31. 4. Managing the visited states p1 p2 p3 p4 p5 p6 p7 p8 a1 p1 + a2 p2 + a3 p3 = const. b2 p2 + b4 p4 + b6 p6 = const. c3 b3 + c7 p7 + c8 p8 = const. only performed actions: search, insert Place invariants Linearity 30-60% less memory preprocessing <1sec run time gain: 30-60%
    • 32. 4. Reduction techniques
    • 33. 1. Linear algebra • The invariant calculus – originally invented for replacing state spaces – in LoLA: used for optimizing state spaces Already seen: place invariants Transition invariant: firing vector of a potential cycle
    • 34. Transition invariants for termination sufficient: store one state per cycle of occurrence graph implementation in LoLA: transition invariants  set of transitions that occur in every cycle  store states where those transitions enabled saves space, if applied in connection with stubborn sets, costs time Linearity
    • 35. 2. The sweep-line method • Relies on progress measure LoLA computes measure automatically: Linearity m1: p1 m2: p2 m3: p3 m4: p4 t1 t2 t3 p2=p1+∆t1 p3 = p2+∆t2 ... transition invariant
    • 36. 3. The symmetry method • LoLA: A symmetry = a graph automorphism of the PT-Net All graph automorphisms = a group (up to exponentially many members)  stored in LoLA: polynomial generating set A marking class: all markings that can be transformed into each other by a symmetry  executed in LoLA: polynomial time approximation Locality
    • 37. Example 1 2 34 5 6 78 Generating set: 10 automorphisms Aut. group: 48 automorphisms most other symmetry approaches: consider only 1-4 automorphisms
    • 38. 4. Stubborn set method • Dedicated method for each supported property traditional LTL-preserving method: - one enabled transition - the basic stubborness principal - only invisible transitions - at least once, on every cycle, all enabled transitions LoLA: - can avoid some of the criteria, depending on property PN tradition
    • 39. Future of LoLA • Counterexample guided abstraction refinement – decolouring of HL nets – on the coverability graph • Distributed version • Modular state spaces • Support of more properties • Fiona: Operating guidelines for services
    • 40. Conclusion • It makes sense to use plain P/T nets for modeling • It makes sense to study dedicated methods for analysing frequently used properties • It makes sense to combine reduction techniques
    • 41. Further reading • LoLA: ICATPN 2000 • Stubborn sets: ICATPN 1999, Fundamenta Informaticae 2000, Formal Methods in System Design 2006 • Symmetries: Acta Informatica 2000, TACAS 2000 • Linear Algebra: TACAS 2003 • Sweep-Line: TACAS 2004+STTT • Services: BPM 2005, • GALS: ASYNC 2005

    ×