M ARIA : Modular Reachability Analyser for Algebraic System Nets Marko Mäkelä Laboratory for Theoretical Computer Science Helsinki University of Technology P .O.Box 9700 02015 HUT Finland October 29, 2001
Analysis Tools for Concurrent Systems Systems where concurrency is present may contain sporadic errors that are very difficult to reproduce. This kind of errors may become expensive in distributed systems where large numbers of terminals have been sold to customers. Not all concurrency-related errors can be found with a debugger or by testing. The fact that tests do not reveal any erroneous behaviour does not prove a system correct. Only if the analysis covers all possible states and executions of the system, we can be sure that the system (or the model that describes it hopefully correctly) fulfils the desired properties (which have hopefully been chosen in a meaningful way). One method that can be automated easily is reachability analysis , exploring all executions or states. 1
Reachability Analysers at the Helsinki University of Technology 1984–1988: P RENA (thousands of reachable states); Pr/T nets with Pascal inscriptions 1989–: P ROD (millions of reachable states); Pr/T nets with C inscriptions • on-the-fly verification, stubborn sets, . . . 1998–: M ARIA (tens of millions of reachable states); algebraic system nets • two modes of operation: interpreted (C++) and compiled (C/C++) • modular structure: easy to implement new algorithms The tools have been used e.g. for analysing two PLC based railway systems, the back- bone bus of an ATM switch, the ISDN DSS.1 protocol and the UMTS RLC protocol. 2
The Features of M ARIA d e d t e e l r i p p m r e o t n c i � � � � unfolding � � � � � � interactive simulation � � � � on-the-fly liveness checking � � � on-the-fly safety checking � � � � � � � � � � � � exhaustive reachability analysis � � � � � � lossless search � � probabilistic search � � 3
Different Modes of Operation M ARIA can process model systems in two fundamentally different ways. It can either interpret the models, or it can translate a model into a set of C language modules that are compiled into a machine executable library. The interpreter approach is useful when a model is being edited and simulated. The calculation of successor states is slower than when the model is compiled, but the delay caused by compiling the model is avoided. It is best to use the compiler mode only in connection with batch-mode state space ex- ploration. 4
Graph Algorithms in M ARIA M ARIA offers some basic tools for traversing reachability graphs: • listing the successor and predecessor states of a state, • computing shortest paths between two states, or a state and a set of states, • traversing a graph of strongly connected components, and • illustrating execution paths that violate a desired property. The paths or graphs can be displayed either textually or graphically. 5
Interfaces to Other Tools (1/3) M ARIA has a number of interfaces to other tools. Some tools are invoked as subprograms: • a C compiler and linker for translating models, • a translator from linear temporal logic (LTL) to generalised Büchi automata, and • GraphViz by AT&T Labs for illustrating state spaces. 6
Interfaces to Other Tools (2/3) Our research group has developed some tools that translate M ARIA model systems from other specification languages: • CCITT Specification and Description Language translator (under development) • TeleNokia SDL (TNSDL) translator (based on E MMA , a translator from TNSDL to P ROD ) • Tampere Verification Tool (TVT) labelled state transition system (LSTS) translator In addition, a group at Brandenburg University of Technology at Cottbus, Germany, uses M ARIA for analysing programmable logic controller (PLC) systems. 7
Interfaces to Other Tools (3/3) M ARIA supports two fundamentally different output formats. Models can be unfolded to low-level Petri nets in the native format of L O LA, PEP and P ROD . The unfolded models can then be analysed with these tools, which at the moment support better state space reduction methods than M ARIA does. State spaces of models, or selected parts of state spaces can be exported as directed graphs in the GraphViz format, or as labelled state transition systems in TVT format. 8
Example: Verifying a Sliding Window Protocol (1/3) Sliding Window Protocol Acknowledgement channel data Data Data data Receiver Sender target source Channel We have constructed a model of the protocol in the M ARIA modelling language (roughly 200 lines of text). In this variation, two kind of messages are sent until a third kind of mes- sage ends the transmission. The sender and the receiver have a buffer for 1 message. The reachability graph contains 264 states and 582 arcs. If the transmission was contin- uous, the initial state would be reachable from each reachable state, and the reachability graph would thus have one strongly connected component . 9
Example: Verifying a Sliding Window Protocol (2/3) Because the model deadlocks once the terminating message has been sent, its reacha- bility graph has several strongly connected components: rec_msg @0 3(8) @@34 @3 1(6) @@7 @6 2(3) @@7 ch:{{0,blue}} @11 2(4) @@6 send_data @17 2(4) @@6 send_data @25 2(6) @@5 @34 2(2) @@5 @44 0(5) @@0 trans_channel:{} trans_channel:{} trans_channel:{{0,blue}} e:0 trans_channel:{} r:{true} trans_channel:{} r:{false} trans_channel:{} trans_channel:{} trans_channel:{} ack_channel:{} rec_data ack_channel:{} send_msg ack_channel:{} r:{false} ack_channel:{} e:0 ack_channel:{} e:1 ack_channel:{} ack_channel:{0} rec_ack ack_channel:{} sender_data:{} vars:{0,0,0} sender_data:{blue} vars:{1,0,0} sender_data:{blue} t:{red} sender_data:{blue} t:{blue} sender_data:{blue} t:{red} sender_data:{blue} send_ack sender_data:{blue} vars:{1,1,0} sender_data:{} sendervars:{0,0,0} d:{} sendervars:{1,0,0} data:{blue} sendervars:{1,1,0} wr:false sendervars:{1,1,0} wr:false sendervars:{1,1,0} wr:false sendervars:{1,1,0} e:1 sendervars:{1,1,0} channel:{0} sendervars:{0,0,1} lock:true data:blue lock:false channel:{} lock:false br:false lock:false br:true lock:false br:false lock:false ack:{} lock:false data:{blue} lock:false receiver_data:{red} receiver_data:{red} receiver_data:{red} receiver_data:{blue} receiver_data:{red} receiver_data:{red} receiver_data:{red} receiver_data:{red} ackarray:{false} ackarray:{false} ackarray:{false} ackarray:{true} ackarray:{false} ackarray:{false} ackarray:{false} ackarray:{false} e:0 e:0 e:0 e:0 e:1 e:1 e:1 e:1 pc:rec_msg pc:rec_msg pc:rec_msg pc:send_data pc:send_data pc:send_ack pc:rec_msg pc:rec_msg white_req:false white_req:false white_req:false white_req:false white_req:false white_req:false white_req:false white_req:false blue_req:false blue_req:false blue_req:false blue_req:true blue_req:false blue_req:false blue_req:false blue_req:false @@31 @@24 @@15 1 @@28 1 3 @@14 2(1) 1 1(2) 1(6) 6 @@30 @@29 @@33 3(2) 1(3) @@13 @@11 @@10 @@9 6 1 4 @@12 14 1 1 1 3(3) @@27 @@26 @@25 2(2) 2(1) 1 4(2) 1(2) 1(2) 1(1) @@8 1 1 1 @@34 2(1) 1 2(1) 2(1) 1(1) 174 0(3) @@19 @@18 @@17 10(0) 1 1 1 @@32 @@21 2(1) 2(1) 1(1) @@5 @@3 @@2 @@1 @@22 4 1 @@4 14 1 1 1 6 @@6 2(1) @@20 2(2) 1 @@0 4(2) 1(2) 1(2) 1(1) 3(3) 6 1 @@16 @@7 2(1) @@23 1 1(3) 3(2) 1 3 1 0(3) 1(2) 1(6) 2(1) 10
Recommend
More recommend
