PA160: Net-Centric Computing II. Specification and Verification of Network Protocols Vojtěch Řehák Faculty of Informatics Masaryk University Spring 2011 Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 1 / 84 Theory Definition and Usage 2/84 Theory Definition and Usage Specification and Verification Spring 2011 2/84 Theory Definition and Usage Specification and Verification Spring 2011 2/84 Theory Definition and Usage Specification and Verification Spring 2011 2/84 Theory Definition and Usage Specification and Verification Spring 2011 2/84 Theory Defnition and Usage Specification and Verification Spring 2011 2 / 84 Theoretical Results as Tools for Users Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 3/84 Formal Models - what are they good for The basic concept is a model of system (i.e. the object we work with). thought handling individual approach (intra-brain) - to grasp it documentation (inter-brain) - to pass it on automatic/computer processing (comparing model to specification) o testing simulation symbolic execution static analysis model checking equivalence checking theorem proving Specification and Verification Spring 2011 4 / 84 Formal Models in Specification natural language vs. formal language freedom in writing O © restrictions in writing human resources © O automatic methods Specification and Verification Spring 2011 5/84 Formal Models in Specification natural language vs. formal language freedom in writing O © restrictions in writing human resources © O automatic methods nothing < text < structured text < text with formal "pictures" < formal description with informal comments < fully formal description Specification and Verification Spring 2011 5/84 Formal Models in Specification natural language vs. formal language freedom in writing O © restrictions in writing human resources © O automatic methods nothing < text < structured text < text with formal "pictures" < formal description with informal comments < fully formal description Goal: Find an appropriate level of abstraction and keep it. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 5/84 Formal Models in Specification natural language vs. formal language freedom in writing O © restrictions in writing human resources © O automatic methods nothing < text < structured text < text with formal "pictures" < formal description with informal comments < fully formal description Goal: Find an appropriate level of abstraction and keep it. "What will be the model used for?" Specification and Verification Spring 2011 5/84 Map - Abstraction Example Specification and Verification Spring 2011 6/84 Map - Abstraction Example Map - Abstraction Example "Model has to suit its purpose!" Only relevant information are presented; no more, no less. Specification and Verification Spring 2011 6/84 Outline Models we will talk about: o Specification and Description Language (SDL) o Message Sequence Charts (MSC) Petri nets What they can be used for? modelling o specification analysis simulation testing partial implementation Specification and Verification Spring 2011 7/84 Distributed Systems - Key characteristics (Déjä vu) Key Characteristics of Distributed Systems: o Autonomicity - there are several autonomous computational entities, each of which has its own local memory o Heterogeneity - the entities may differ in many ways • computer HW (different data types' representation), network interconnection, operating systems (different APIs), programming languages (different data structures), implementations by different developers, etc. o Concurrency - concurrent (distributed) program execution and resource access No global clock - programs (distributed components) coordinate their actions by exchanging messages o message communication can be affected by delays, can suffer from variety of failures, and is vulnerable to security attacks Independent failures - each component of the system can fail independently, leaving the others still running (and possibly not informed about the failure) o How to know/differ the states when a network has failed or became unusually slow? o How to know if a remote server crashed immediately? Vojtech Rehak (FI MU) Specification and Verification Spring 2011 8/84 Specification Description Language (SDL) Specification Description Language (SDL) Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 9/84 Specification Description Language (SDL) international standard of the ITU-T, Z.100 1972 - Establishment of a working group for SDL 1976 - first version of Z.100 recommendation 2007 - current version of Z.100 recommendation all documents of the current version: o Z.100 - Specification and Description Language (SDL) o Z.100 Annex F1 - SDL formal definition: General overview o Z.100 Annex F2 - SDL formal definition: Static semantics o Z.100 Annex F3 - SDL formal definition: Dynamic semantics o Z.100 Supplement 1 - SDL+ methodology: Use of MSC and SDL • Z.Imp100 - SDL implementer's guide o Z.104 - Encoding of SDL data o Z.105 - SDL combined with ASN.1 modules o Z.106 - Common interchange format for SDL o Z.109 - SDL-2000 combined with UML Vojtech Rehak (FI MU) Specification and Verification Spring 2011 10 / 84 SDL - Specification Description Language An object oriented languages for specification of applications that are o heterogeneous, o distributed (concurrent), o interactive (event-driven, discrete signals), and o real-time dependent (with delays, timeouts). Describes structure (distributed components of the system), behaviour (instructions within the components), and data of distributed systems in real-time environments. Specification and Verification Spring 2011 11 / 84 SDL - Goals What SDL is good for? SDL is designed for unambiguous specification of requirements and description of implementation of the normative requirements of telecommunication protocol standards. For computer based tools to improve the process of o specification (create, maintain, and analyze), and o implementation (automatic code generation). Specification and Verification Spring 2011 12 / 84 SDL - Goals What SDL is good for? SDL is designed for unambiguous specification of requirements and description of implementation of the normative requirements of telecommunication protocol standards. For computer based tools to improve the process of o specification (create, maintain, and analyze), and o implementation (automatic code generation). What SDL is NOT good for? high level system description (what the system serves for), demonstration of good or wrong behaviour, test trace specification, implementation details (primitives for communication, detailed data manipulation), etc. Specification and Verification Spring 2011 12 / 84 SDL - representations Three representations: SDL/GR graphical representation (human readable) SDL/PR textual phrase representation (machine readable) SDL/CIF common interchange format (SDL/PR with graphical information) Specification and Verification Spring 2011 13 / 84 SDL - representations Three representations: SDL/GR graphical representation (human readable) SDL/PR textual phrase representation (machine readable) SDL/CIF common interchange format (SDL/PR with graphical information) In what follows, we focus on the graphical representation (SDL-GR). Basic SDL components system and blocks (structure) processes and procedures (behaviour) Specification and Verification Spring 2011 13 / 84 SDL/GR - Process Vojtech Rehak (FI MU) Specification and Verification source' TIMe Electronic Tevthook v4 0 Spring 2011 14 / 84 SDL/GR - Procedure SDL/GR - Block Specification and Verification source: TIMe Electronic Textbook v4.0 Spring 2011 16 / 84 SDL/GR - Block with block structure Specification and Verification source: TIMe Electronic Textbook v4.0 Spring 2011 17 / 84 SDL/GR - System (the top most block) system AccessContro t Signal definitions for AccessPoinl communication 7 SIGNAL eject-card, lock, unlock /- AccessPoinl input-card, isOpen, isClosed /* ENV display, /' Display keys; /' ENV SIGNAL Code(integer,integer>;/' AccessPoinl SIGNAL OK,NOK,ERR ; /• CentralLlnit TO ENV 7 TO AccessPomr TO ENV 7 TO Keyboard 7 TO CentralLlnit * TO AccessPoinl SIGNALLIST validity = OK, NOK, ERB ; SIGNALLIST outp = EjectCard, display; SIGNALLIST inp . InputCard, keys ; [(outp)] i e AP(100): c [(inp)j j AccessPoint [(validity)] [Code] C block lype t reference i CentralUnit CD [isOpen.isClosed, [lock,unlock] signal block set accord- llM Channel Vojtech Rehak (FI MU) ing to a block type Specification and Verification block (single) source: TIMe Electronic Textbook v4.0 Spring 2011 18 / 84 SDL/GR - Channels Nondelaying channels for "immediate" message delivery (e.g., between processes within a computer). Nondelaying channels Delaying channels for "time consuming" message delivery (e.g., between dislocated blocks). Channels can also be one-directional. Vojtech Řehák (FI MU) Specification and Verification Spring 2011 19 / 84 Summary of SDL Basics System is the top most block surrounded by environment. Block consists of blocks or processes that are connected by channels. express the hierarchical structure of the system. names are references to other objects. Process sends and receives messages. stay in states. can call procedures. Procedure is a subroutine that can finish. does not return any value (only in variables or sent messages). Vojtech Rehak (FI MU) Specification and Verification Spring 2011 20 / 84 Message Exchange o one input buffer for a process o FIFO behaviour o no priority queues o signal which is unspecified in the current state is discarded Specification and Verification source: TIMe Electronic Textbook v4.0 Spring 2011 21 / 84 Asterisk Save, Asterisk State, and Dash State Vojtech Řehák (FI MU) Specification and Verification source: TIMe Electronic Textbook v4.0 Spring 2011 22 / 84 Timer Construction Multiple Instances of a Block source: TIMe Electronic Textbook v4.0 Specification and Verification Spring 2011 24 / 84 Multiple Instances of a Process Specification and Verification Spring 2011 25 / 84 Additional SDL Constructs o Asterisk save, asterisk state, and dash state o Timer construction o Multiple block instances (no dynamic creation) o Multiple process instances (with dynamic creation and limit) o Packages collections of related types and definitions (library) o Subtypes Virtual processes o Process type redefinition and finalization Inherited blocks Specification and Verification Spring 2011 26 / 84 SDL - Overview aiiciffrcmj. heading system Crarrolc _W*mBu%*\ b|ockb1 system example 2(3 system example s2 ol [m] Ml =2 [«e>] cl block b1 2(3;. block d1 1(21 r1 [ fri) ] [ ] r3 Ol 1 f2 [*1 2» ] Systems and blocks ciin contain ^ *'* blocks antl/orprocesses. process p2 £(21) 1(211 put) cess p2 ^_ (W),—k- - - ' " * 01 initial ^ Processes contain / beň avion r an d cannot S contain blocks. ~~ " procedure pr 1(1) Vojtech Ŕehák (FI MU) Specification and Verification Spring 2011 27 / 84 SDL - Tools IBM Rational o from tools of Telelogic (SDT, Geode, Tau) o drawing, import, export o automatic implementation in C++ simulation support SanDriLa SDL o MS Visio stencil drawing, import, export o analyses of states in process diagrams open for addons Cinderella SDL modelling, import, export analyses and simulation Vojtech Řehák (FIMU) Specification and Verification Spring 2011 28 / 84 Distributed Systems "What is the problem of distributed systems?" Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 29 / 84 Distributed Systems World is distributed Specification and Verification Spring 2011 29 / 84 Distributed Systems Distributed vs. Local SDL Specification Description Language ITU-T Z.100 MSC Message Sequence Chart ITU-T Z.120 Specification and Verification Spring 2011 30 / 84 Distributed vs. Local SDL MSC Specification Description Message Sequence Language Chart ITU-T Z.100 ITU-T Z.120 models of components communication model Specification and Verification Spring 2011 30 / 84 Message Sequence Chart (MSC) Message Sequence Chart (MSC) Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 31 / 84 Message Sequence Chart (MSC) international standard of the ITU-T, Z.120 o 1993 - first version of Z.120 recommendation ... 2011 - current version of Z.120 recommendation all documents of the current version: o Z.120 - Message Sequence Chart (MSC) o Z.120 Annex B - Formal semantics of message sequence charts o Z.121 - Specification and Description Language (SDL) data binding to Message Sequence Charts (MSC) Specification and Verification Spring 2011 32 / 84 Message Sequence Chart (MSC) A trace language for the specification and description of the communication behaviour by means of message exchange. Describes o communicating processes, o communication traces, message order, o time information (timeouts, constraints), o high-level form for set of traces. Specification and Verification Spring 2011 33 / 84 MSC - Goals What MSC is good for? Both human and computer readable formalizm for: o basic behaviour demonstration (use cases), o high level system behaviour description, o test case specification, and o (test) log visualization. Specification and Verification Spring 2011 34 / 84 MSC - Goals What MSC is good for? Both human and computer readable formalizm for: o basic behaviour demonstration (use cases), o high level system behaviour description, o test case specification, and (test) log visualization. What MSC is NOT good for? detailed specification (before implementation), hierarchical structure of communicating entities, implementation details (primitives for communication, detailed data manipulation), etc. Specification and Verification Spring 2011 34 / 84 MSC and SDL in Workflow o typical/optimal communication sequences (MSC) o error sequences (MSC) o optionally - full specification in (HMSC) o distributed specification (SDL) Specification and Verification Spring 2011 35 / 84 MSC and SDL in Workflow o typical/optimal communication sequences (MSC) o error sequences (MSC) o optionally - full specification in (HMSC) o distributed specification (SDL) Formal model benefits o (H)MSC to SDL transformation (realization) SDL to source code transformation (implementation) MSC to test case transformation o simulation to MSC transformation (membership checking) Specification and Verification Spring 2011 35 / 84 Message Sequence Chart (MSC) Vojtech Rehak (FI MU) Specification and Verification Spring 2011 36 / 84 Message Sequence Chart (MSC) - semantics Specification and Verification Spring 2011 37 / 84 Message Sequence Chart (MSC) - semantics Specification and Verification Spring 2011 37 / 84 Specification and Verification Spring 2011 37 / 84 MSC - Visual Order Peter Jane Paul MSC - Visual Order - Hasse Diagram Peter Jane Paul Specification and Verification Spring 2011 39 / 84 MSC Properties What is an unwanted behaviour/property? Specification and Verification Spring 2011 40 / 84 MSC Properties What is an unwanted behaviour/property? Fundamental problems in the specified model, e.g. an implementation of the model does not exist in the given environment. Specification and Verification Spring 2011 40 / 84 Acyclic/Cyclic property cyclic dependency among events Instance p Instance q unrealizable in any environment Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 41 / 84 Acyclic/Cyclic property FIFO/non-FIFO property overleaping messages Instance p Instance q Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 43 / 84 FIFO/non-FIFO property overleaping messages Instance p Instance q unrealizable in an environment preserving message order Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 43 / 84 FIFO/non-FIFO property overleaping messages Instance p Instance q Instance p Instance q Instance r unrealizable in an environment preserving message order Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 43 / 84 Instance q Instance r unrealizable in an environment preserving message order realizable in an environment with P2P channel but unrealizable in case of a global channel Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 43 / 84 Race Condition Vojtěch Řehák (Fl MU) Specification and Verification Race Condition Peter Jane Paul 44 / 84 Race Condition Peter Jane Paul Informally, race is when some receive event can come earlier. J Solution #1 - Coregion Construction Let us demonstrate that some events are not ordered. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 45 / 84 Solution #1 - Coregion Construction Let us demonstrate that some events are not ordered. Peter Jane Paul Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 45 / 84 Solution #1 - Coregion Construction Let us demonstrate that some events are not ordered. Peter Jane Paul i ; i i ; i i ; i Events in a coregion are not order; except of related by general ordering. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 45 / 84 Solution #2 - List/set of all possibilities High-Level MSC (HMSC) - ITU-T Z.120 High-Level MSC (HMSC) - ITU-T Z.120 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 High-Level MSC (HMSC) - ITU-T Z.120 Specification and Verification Spring 2011 49 / 84 Deadlock Property Specification and Verification Spring 2011 50 / 84 Livelock Property Specification and Verification Spring 2011 51 / 84 Membership Is a given MSC included in a given HMSC? Specification and Verification Spring 2011 52 / 84 Membership Is a given MSC included in a given HMSC? Vojtech Rehak (FI MU) Specification and Verification Spring 2011 52 / 84 Inline Expressions System 1 System2 System3 altj --" I I I I I I Vojtech Rehak (FI MU) Specification and Verification Spring 2011 53 / 84 Inline Expressions System 1 System2 System3 altj --" I I I I I I Other inline expression types: opt, loop{m, n), exc, seq, par. Vojtech Rehak (FI MU) Specification and Verification Spring 2011 53 / 84 Non-local Choice System 1 System2 System3 altj *—■—-iui^nípí I "1 I "I I -I Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 54 / 84 Non-local Choice System 1 System2 System3 altj *—■—-iui^nípí I "1 I "I I -I System3 does not know which alternative has been chosen. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 54 / 84 Non-local Choice System 1 System2 System3 altj —^^Sfop I I I I I I System3 does not know which alternative has been chosen. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 54 / 84 Universal Boundedness What size of buffer is needed to be sure it will not overflow? M Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 55 / 84 Universal Boundedness What size of buffer is needed to be sure it will not overflow? Every finite input buffer of Y can overflow. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 55 / 84 Universal Boundedness What size of buffer is needed to be sure it will not overflow? M Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 55 / 84 Universal Boundedness What size of buffer is needed to be sure it will not overflow? Buffers of size 1 will not overflow. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 55 / 84 Existential Boundedness The system deadlocks in case of FIFO channels (and FIFO buffers). What size of non-FIFO buffers is needed to avoid deadlock (in case of FIFO channels)? Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 56 / 84 Existential Boundedness The system deadlocks in case of FIFO channels (and FIFO buffers). What size of non-FIFO buffers is needed to avoid deadlock (in case of FIFO channels)? Buffer of size 2 suffices to avoid deadlock. Or one buffer for each message label (type). Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 Race Condition - Solution #3 - Time Constraints Specification and Verification Spring 2011 57 / 84 Time Consistency Are the given time conditions consistent? Client A Proxy Server Specification and Verification Spring 2011 58 / 84 Time Tightening Some time conditions can be tightened. Client A Proxy Server Specification and Verification Spring 2011 59 / 84 Time Tightening Some time conditions can be tightened. Client A Proxy Server Specification and Verification Spring 2011 59 / 84 Timers Vojtech Rehak (FI MU) Specification and Verification Spring 2011 60 / 84 MSC - Summary Basic MSC o instances o messages send events o receive events o conditions o coregions general ordering o inline expressions time constraints timers High-level MSC (HMSC) start node end node reference nodes connection points lines conditions time constraints Specification and Verification Spring 2011 61 / 84 MSC - Properties o Acyclic property o FIFO property o Race Condition o Deadlock o Livelock o Membership Nonlocal Choice Universal Boundedness Existential Boundedness Time Race Condition Time Consistency o Tighten Time Vojtech Řehák (FI MU) Specification and Verification Spring 2011 62 / 84 MSC - Tools IBM Rational, SanDriLa SDL, Cinderella SDL Sequence Chart Studio (SCStudio) o MS Visio addon o drawing, import, export o checkers for all the mentioned properties MSCan academic tool only textual input some checkers Mesa academic tool local choice and time checkers Vojtech Řehák (FIMU) Specification and Verification Spring 2011 63 / 84 Sequence Chart Studio MSC drawing and verification tool developed at FI MU. http://scstudio.sourceforge.net Specification and Verification Spring 2011 64 / 84 Petri Nets Petri Nets Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 65 / 84 Petri Nets C. A. Petri: Kommunikation mit automaten, 1962 Basic components: • places • transitions • tokens • arcs Marking = configuration = distribution of tokens = vector of #s tokens in places A transition can be fired if there is a token in each of its input places. places with tokens inside Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 66 / 84 Petri Nets C. A. Petri: Kommunikation mit automaten, 1962 Basic components: • places • transitions • tokens • arcs Marking = configuration = distribution of tokens = vector of #s tokens in places input places output places Tokens from input places are removed and new tokens are added into the output places of the fired transition. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 66 / 84 Basic Constructions Sequential execution Alternative Parallel execution Iteration © o © © o o o Vojtech Rehak (FI MU) Specification and Verification Spring 2011 67 / 84 a b b a a b a Basic Constructions Basic Constructions T T 9 a? T S--- 9 9 Specification and Verification Spring 2011 69 / 84 Basic Constructions T T I Critical section Specification and Verification Spring 2011 69 / 84 Basic Constructions Basic Constructions Basic Constructions Basic Constructions Different Modifications/Extensions of Petri Nets o Condition/Event Petri nets (C/E PN) o Place/Transition Petri nets (P/T PN) o Coloured Petri nets o Hierarchical Petri nets o Timed Petri nets o Time Petri nets Stochastic Petri nets Specification and Verification Spring 2011 70 / 84 Condition/Event Petri Nets Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 71 / 84 Condition/Event Petri Nets Better and a bit more complicated example. Spring 2011 72 / 84 Transition/Place Petri Nets An arbitrary number of tokens in each place. Specification and Verification Spring 2011 73 / 84 Transition/Place Petri Nets An arbitrary number of tokens in each place. producer t o transp. channel J—o— consumer ■0 notification channel Producer-consumer model for bounded transport channel. Vojtech Rehak (FI MU) Specification and Verification Spring 2011 73 / 84 Additional Constructs - Arc Multiplicity Specification and Verification Spring 2011 74 / 84 Additional Constructs - Arc Multiplicity Specification and Verification Spring 2011 74 / 84 Additional Constructs - Arc Multiplicity Specification and Verification Spring 2011 74 / 84 Additional Constructs - Arc Multiplicity Specification and Verification Spring 2011 74 / 84 Additional Constructs - Inhibitor and Reset Arcs o An inhibitor arc imposes the precondition that the transition may only fire when the place is empty. Specification and Verification Spring 2011 75 / 84 Additional Constructs - Inhibitor and Reset Arcs o An inhibitor arc imposes the precondition that the transition may only fire when the place is empty. o A reset arc does not impose a precondition on firing, and empties the place when the transition fires. Specification and Verification Spring 2011 75 / 84 Properties of Petri nets o reachability - reachability tree or coverability tree o bounded (safe) places o a place with a bound on the number of its tokens in all reachable markings o a place is safe if the number of its tokens < 1 in all reachable markings o liveness o a transition is live if, from every marking, one can reach a marking where the transition is enabled o a net is live if all its transitions are live 76 / 84 Properties of Petri nets o p-invariant o an invariant vector on places, i.e. a multiset of places representing weighting such that any such weighted marking remains invariant by any firing, e.g. 3 * pi + p2 + P3 + P4 + P5 + 3 * p6. t-invariant an invariant vector on transitions, i.e. a multiset of transitions whose firing leave invariant any marking, e.g. t1 + 2 * t2 + t3 + t4 + t5. p2 t2 p3 77 / 84 Coloured Petri Nets Different colours (classes) of tokens. 3'p+2'q+5'r 3,p+l'q+2'r o o marking expression, arc expression, transition guard (next slide) Colours usually serves for data type representation. Vojtěch Řehák (Fl MU) Specification and Verification Spring 2011 78 / 84 Coloured Petri Net Example source: http://scienceblogs.com/goodmath/2007/10/colored_petri_nets.php Specification and Verification Spring 2011 79 / 84 Hierarchical Petri Nets source: http://www.gridworkflow.org/kwfgrid/gwes-web/ Specification and Verification Spring 2011 80 / 84 Time PN, Timed PN, Stochastic PN time from enabling of a transition to fire, interval of the time to fire, time of firing, probability distribution on time to fire, exponential distribution on time to fire, t 5 Specification and Verification Spring 2011 81 / 84 PN Tools CPN Tools • Coloured Petri Nets (with prioritized transitions and real time support) • editor, simulation, analyses TimeNET • High-level PN, Stochastic PN, PN with Time • editor, simulation, analyses (p-invariant, performance analyses) Tapall • Timed-Arc Petri Nets (with real time support) • editor, simulation, CTL logic checker And many more tools and use cases, see, e.g. http://www. informatik. uni-hamburg.de/TGI/Petri Nets/tools/quick, html http://cs.au.dk/cpnets/industrial-use/ Specification and Verification Spring 2011 82 / 84 Relevant Lectures IV113 Úvod do validace a verifikace (Barnat) IV109 Modelovaní a simulace (Peianek) IA159 Formal verification methods (StrejCek) PV177 Laboratoř pokrocilých sítových technologií (Rehak) Specification and Verification Spring 2011 83 / 84 References ITU-T specifications: o Z.100 Specification Description Language (SDL). 2007. o Z.120 Message Sequence Charts (MSC). 2004. Books: o S. Mullender. Distributed Systems. ACM, 1993. o D. Peled. Sofware Reliaility Methods. Springer, 2001. o R. Brak at al. TIMe: The Integrated Method. SINTEF, 1999. o L. Doldi. Validation of Communications Systems with SDL. Wiley, 2003. o M. Broy and K. St0len. Specification and Development of Interactive Systems: Focus on Streams, Interfaces, and Refinement. Springer, 2001. o W. Jia and W. Zhou. Distributed Network Systems: From Concepts to Implementation. Springer, 2005. o M. Ceska. Petriho sítě. Akademicke nakladatelství CERM Brno, 1994. o J. Markl. Petriho site. VŠB - Technicka univerzita Ostrava, 1996. Specification and Verification Spring 2011 84 / 84