Promela/SPIN Acknowledgements: These notes used some of the material presented by Flavio Lerda as part of Ed Clarke’s model-checking course.

Slides:



Advertisements
Similar presentations
1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
Advertisements

The SPIN System. What is SPIN? Model-checker. Based on automata theory. Allows LTL or automata specification Efficient (on-the-fly model checking, partial.
The SPIN System. What is SPIN? Model-checker. Based on automata theory. Allows LTL or automata specification Efficient (on-the-fly model checking, partial.
1 Carnegie Mellon UniversitySPIN ExamplesFlavio Lerda Bug Catching SPIN Examples.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level.
UPPAAL Introduction Chien-Liang Chen.
© 2011 Carnegie Mellon University SPIN: Part /614 Bug Catching: Automated Program Verification Sagar Chaki April 21, 2014.
/ PSWLAB P ROMELA Semantics from “THE SPIN MODEL CHECKER” by G. J. Holzmann Presented by Hong,Shin 5 th Oct :021PROMELA Semantics.
An Overview of PROMELA. A protocol Validation Language –A notation for the specification and verification of procedure rules. –A partial description of.
The model checker SPIN1 The Model Checker SPIN. The model checker SPIN2 SPIN & Promela SPIN(=Simple Promela Interpreter) –tool for analyzing the logical.
תרגול 9 META LABELS. Basic types of claims State properties.
Frederico Araujo CS6362 – Fall 2010 The SPIN Model Checker.
Wishnu Prasetya Model Checking with SPIN Modeling and Verification with SPIN.
© 2011 Carnegie Mellon University SPIN: Part /614 Bug Catching: Automated Program Verification Sagar Chaki April 21, 2014.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
PSWLAB S PIN Search Algorithm from “THE SPIN MODEL CHECKER” by G Holzmann Presented by Hong,Shin 9 th Nov SPIN Search Algorithm.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
SPIN Verification System The Model Checker SPIN By Gerard J. Holzmann Comp 587 – 12/2/09 Eduardo Borjas – Omer Azmon ☐ ☐
The Spin Model Checker Promela Introduction Nguyen Tuan Duc Shogo Sawai.
1 Choose a Leader Example: find extrema in unidirectional ring There are N processes configured into a unidirectional ring; i.e. For 1
1 Spin Model Checker Samaneh Navabpour Electrical and Computer Engineering Department University of Waterloo SE-464 Summer 2011.
Shin Hong, KAIST17 th April,2007 1/33 Provable Software Laboratory, CS KAIST.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
© 2011 Carnegie Mellon University SPIN: Part Bug Catching: Automated Program Verification and Testing Sagar Chaki November 2, 2011.
© 2011 Carnegie Mellon University SPIN: Part Bug Catching: Automated Program Verification and Testing Sagar Chaki October 31, 2011.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
CS 290C: Formal Models for Web Software Lecture 4: Model Checking Navigation Models with Spin Instructor: Tevfik Bultan.
The Model Checker SPIN Written by Gerard J. Holzmann Presented by Chris Jensen.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Wishnu Prasetya Model Checking with SPIN A Bit More about SPIN.
1 VeriSoft A Tool for the Automatic Analysis of Concurrent Reactive Software Represents By Miller Ofer.
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Scientific Computing By: Fatima Hallak To: Dr. Guy Tel-Zur.
Korea Advanced Institute of Science and Technology The Spin Model Checker - Advanced Features Moonzoo Kim CS Dept. KAIST.
1 Rendez-Vous Logical extension of chan buffer = [N] of byte is chan port = [0] of byte Channel port is a rendez-vous port (binary handshake). Two processes,
CS6133 Software Specification and Verification
Concurrency. A process is a program executing on a virtual computer Processor speed and multiplexing of shared resources are ignored Order of thread execution.
MODEL CHECKING WITH SPIN MODELING AND VERIFICATION WITH SPIN ANDREA ORLANDINI – ISTC (CNR) TexPoint fonts used in EMF. Read the TexPoint manual before.
Today’s Agenda  Quiz 4 next Tuesday  Quick Review  Continue on SPIN Overview.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Temporal Logic Model-checking with SPIN
The Spin Model Checker : Part I Moonzoo Kim KAIST.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Today’s Agenda  Quiz 5 (end of the class)  Quick Review  Finish Search Algorithms Formal Methods in Software Engineering1.
Wishnu Prasetya Model Checking with SPIN Modeling and Verification with Promela.
Using SPIN. INTRODUCTION To extend the protocol simulator from Chapter 12 with an validator generator, all we have to do is to activate two command line.
Symbolic Model Checking of Software Nishant Sinha with Edmund Clarke, Flavio Lerda, Michael Theobald Carnegie Mellon University.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
Formal verification in SPIN
CSE 503 – Software Engineering
An explicit state model checker
The Spin Model Checker - Advanced Features
An explicit state model checker
A Refinement Calculus for Promela
CSE 555 Protocol Engineering
The Spin Model Checker - Advanced Features
CSE 503 – Software Engineering
Presentation transcript:

Promela/SPIN Acknowledgements: These notes used some of the material presented by Flavio Lerda as part of Ed Clarke’s model-checking course

2 SPIN Ü For checking correctness of process interactions  Specified using buffered channels, shared variables or combination  Focus: asynchronous control in software systems  Promela – program-like notation for specifying design choices  Models are bounded and have countably many distinct behaviors Ü Generate a C program that performs an efficient online verification of the system’s correctness properties Ü Types of properties:  Deadlock, violated assertions, unreachable code  System invariants, general LTL properties Ü Random simulations of the system’s execution Ü “Proof approximation”

3 Explicit State Model Checker Ü Represents the system as a finite state machine Ü Visits each reachable state (state space) explicitly (using Nested DFS) Ü Performs on-the-fly computation Ü Uses partial order reduction Ü Efficient memory usage  State compression  Bit-state hashing Ü Version 4:  Uninterpreted C code can be used as part of Promela model

4 High Level Organization LTL Translator Buchi Translator Pan VerifierC Compiler C Generator Automata Generator Promela Parser LTL formulaPromela Model Buchi Automaton Abstract Syntax Tree Automata C Code Verification Result The Buchi automaton is turned into a Promela process and composed with the rest of the system. The generated verifier is specific to the model and property we started with.

5 Promela (Process Meta Language) Ü Asynchronous composition of independent processes Ü Communication using channels and global variables Ü Non-deterministic choices and interleavings Ü Based on Dijkstra’s guarded command language  Every statement guarded by a condition and blocks until condition becomes true Example: while (a != b) skip /* wait for a == b */ vs (a == b)

6 Process Types  State of variable or message channel can only be changed or inspected by processes (defined using proctype ) Ü ; and -> are statement separators with same semantics.  -> used informally to indicate causal relation between statements Example: byte state = 2; proctype A() {(state == 1) -> state = 3 } proctype B() {state = state -1 }  state here is a global variable

7 Process Instantiation Ü Need to execute processes  proctype only defines them Ü How to do it?  By default, process of type init always executes  run starts processes  Alternatively, define them as active (see later) Ü Processes can receive parameters  all basic data types and message channels.  Data arrays and process types are not allowed. Example: proctype A (byte state; short foo) {(state == 1) -> state = foo } init {run A(1, 3) }

8 Example Ü As mentioned earlier, no distinction between a statement and condition. bool a, b; proctype p1() { a = true; a & b; a = false; } proctype p2() { b = false; a & b; b = true; } init { a = false; b = false; run p1(); run p2(); } These statements are enabled only if both a and b are true. In this case b is always false and therefore there is a deadlock.

9 An Example mtype = { NONCRITICAL, TRYING, CRITICAL }; mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1) } NC C T At most one mtype can be declared

10 Other constructs Ü Do loops do :: count = count + 1; :: count = count - 1; :: (count == 0) -> break od

11 Other constructs Ü Do loops Ü Communication over channels proctype sender(chan out) { int x; if ::x=0; ::x=1; fi out ! x; }

12 Other constructs Ü Do loops Ü Communication over channels Ü Assertions proctype receiver(chan in) { int value; in ? value; assert(value == 0 || value == 1) }

13 Other constructs Ü Do loops Ü Communication over channels Ü Assertions Ü Atomic Steps int value; proctype increment() {atomic { x = value; x = x + 1; value = x; }

14 Message Passing chan qname = [16] of {short} qname!expr – writing (appending) to channel qname?expr – reading (from head) of the channel qname??expr – “peaking” (without removing content) qname!!expr – checking if there is room to write can declare channel for exclusive read or write: chan in, out; xr in; xs out; qname!exp1, exp2, exp3 – writing several vars qname!expr1(expr2, expr3) – type and params qname?vari(var2, var3) qname?cons1, var2, cons2 – can send constants  Less parameters sent than received – others are undefined  More parameters sent – remaining values are lost  Constants sent must match with constants received

15 Message Passing Example proctype A(chan q1) {chan q2; q1?q2; q2!123 } proctype B(chan qforb) {int x; qforb?x; print(“x=%d\n”, x) } init{ chan qname = [1] of {chan }; chan qforb = [1] of {int }; run A(gname); run B(qforb); qname!qforb } Prints: 123

16 Randez-vous Communications Ü Buffer of size 0 – can pass but not store messages  Message interactions by definition synchronous Example: #define msgtype 33 chan name = [0] of { byte, byte }; proctype A() {name!msgtype(123); name!msgtype(121); /* non-executable */ } proctype B() {byte state; name?msgtype(state) } init {atomic {run A(); run B() } }

17 Randez-Vous Communications (Cont’d)  If channel name has zero buffer capacity:  Handshake on message msgtype and transfer of value 123 to variable state.  The second statement will not be executable since no matching receive operation in B Ü If channel name has size 1:  Process A can complete its first send but blocks on the second since channel is filled.  B can retrieve this message and complete.  Then A completes, leaving the last message in the channel Ü If channel name has size 2 or more:  A can finish its execution before B even starts

18 Example – protocol  Channels Ain and Bin  to be filled with token messages of type next and arbitrary values (ASCII chars)…  by unspecified background processes: the users of the transfer service  These users can also read received data from the channels Aout and Bout Ü The channels are initialized in a single atomic statement…  And started with the dummy err message.

19 Example Cont’d mtype = {ack, nak, err, next, accept}; proctype transfer (chan in, out, chin, chout) {byte o, I; in?next(o); do :: chin?nak(I) -> out!accept(I); chout!ack(o) :: chin?ack(I) -> out!accept(I); in?next(o); chout!ack(o) :: chin?err(I) -> chout!nak(o) od }

20 Example (Cont’d) init {chan AtoB = [1] of { mtype, byte }; chan BtoA = [1] of { mtype, byte }; chan Ain = [2] of { mtype, byte }; chan Bin = [2] of { mtype, byte }; chan Aout = [2] of { mtype, byte }; chan Bout = [2] of { mtype, byte }; atomic { run transfer (Ain, Aout, AtoB, BtoA); run transfer (Bin, Bout, BtoA, AtoB); } Ain!next(0); AtoB!err(0) }

21 Mutual Exclusion Ü Peterson’s solution to the mutual exclusion problem flag 0 =1 turn=0 flag 1 == 0 || turn == 1 flag 1 != 0 && turn != 1 flag 0 =0 Critical Section

22 Mutual Exclusion in SPIN flag 0 =1 turn=1 flag 1 == 0 || turn == 0 flag 1 != 0 && turn != 0 flag 0 =0 Critical Section bool turn; bool flag[2]; proctype mutex0() { again: flag[0] = 1; turn = 1; (flag[1] == 0 || turn == 0); /* critical section */ flag[0] = 0; goto again; }

23 Mutual Exclusion in SPIN bool turn, flag[2]; active [2] proctype user() { assert(_pid == 0 || __pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 || turn == _pid); /* critical section */ flag[_pid] = 0; goto again; } _pid: Identifier of the process assert: Checks that there are only at most two instances with identifiers 0 and 1

24 Mutual Exclusion in SPIN bool turn, flag[2]; byte ncrit; active [2] proctype user() { assert(_pid == 0 || __pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 || turn == _pid); ncrit++; assert(ncrit == 1); /* critical section */ ncrit--; flag[_pid] = 0; goto again; } ncrit: Counts the number of processes in the critical section assert: Checks that there is always at most one process in the critical section

25 Verification Ü Generate, compile and run the verifier  to check for deadlocks and other major problems: $ spin –a mutex $ cc –O pan pan.c $ pan full statespace search for: assertion violations and invalid endstates vector 20 bytes, depth reached 19, errors: 0 79 states, stored 0 states, linked 38 states, matchedtotal: 117 hash conflicts: 4 (resolved) (size s^18 states, stack frames: 3/0) unreached code _init (proc 0); reached all 3 states unreached code P (proc 1): reached all 12 states

26 Mutual Exclusion Ü Verifier: Assertion can be violated  Can use -t -p to find out the trace  Or use XSpin Ü Another way of catching the error  Have another monitor process ran in parallel  Allows all possible relative timings of the processes  Elegant way to check validity of system invariant

27 Mutual Exclusion in SPIN bool turn, flag[2]; byte ncrit; active [2] proctype user() { assert(_pid == 0 || __pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 || turn ==_pid); ncrit++; /* critical section */ ncrit--; flag[_pid] = 0; goto again; } active proctype monitor() {assert (ncrit == 0 || ncrit == 1) }

28 Finally, Ü Can specify an LTL formula and run the model- checker Example: #define p count <= 1  LTL claim: [] p Ü Note: all variables in LTL claims have to be global!  LTL claim gets translated into NEVER claim and stored either in.ltl file or at the end of model file  Only one LTL property can be verified at a time Ü Parameters can be set using XSpin  Depth of search, available memory, etc.

29 Mutual Exclusion in SPIN bool turn, flag[2]; bool critical[2]; active [2] proctype user() { assert(_pid == 0 || __pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 ||turn == _pid); critical[_pid] = 1; /* critical section */ critical[_pid] = 0; flag[_pid] = 0; goto again; } LTL Properties: [] (critial[0] || critical[1]) [] <> (critical[0]) [] <> (critical[1]) [] (critical[0] -> (critial[0] U (!critical[0] && ((!critical[0] && !critical[1]) U critical[1])))) [] (critical[1] -> (critial[1] U (!critical[1] && ((!critical[1] && !critical[0]) U critical[0])))) Note: critical[ ] is a global var!

30 Alternatively, #define p ncrit <= 1 #define q ncrit = 0 bool turn, flag[2]; byte ncrit; active [2] proctype user() { assert(_pid == 0 || __pid == 1); again: flag[_pid] = 1; turn = 1 - _pid; (flag[1 - _pid] == 0 || turn == _pid); ncrit++; /* critical section */ ncrit--; flag[_pid] = 0; goto again; } LTL Properties: [] (p) []<> (!q)

31 Command Line Tools Ü Spin  Generates the Promela code for the LTL formula $ spin –f “[]<>p”  The proposition in the formula must correspond to #defines  Generates the C source code $ spin –a source.pro  The property must be included in the source Ü Pan  Performs the verification  Has many compile time options to enable different features  Optimized for performance

32 Xspin Ü GUI for Spin

33 Simulator Ü Spin can also be used as a simulator  Simulated the Promela program Ü It is used as a simulator when a counterexample is generated  Steps through the trace  The trace itself is not “readable” Ü Can be used for random and manually guided simulation as well

A few examples Ü Alternating Bit Protocol Ü Leader Election

35 Alternating Bit Protocol Ü Two processes want to communicate Ü They want acknowledgement of received messages Ü Sending window of one message Ü Each message is identified by one bit Ü Alternating values of the identifier

36 Alternating Bit Protocol SenderReceiver msg0 ack0 msg1 ack1 msg0 ack0 msg1

37 Alternating Bit Protocol SenderReceiver msg0 ack1 msg0 ack0

38 Alternating Bit Protocol SenderReceiver msg0 ack0 msg1 ack1 msg0

39 Sender Process active proctype Sender() { do :: if :: receiver!msg0; :: skip fi; do :: sender?ack0 -> break :: sender?ack1 :: timeout -> if :: receiver!msg0; :: skip fi; od; :: if :: receiver!msg1; :: skip fi; do :: sender?ack1 -> break :: sender?ack0 :: timeout -> if :: receiver!msg1; :: skip fi; od; }

40 Receiver Process active proctype Receiver() { do :: do :: receiver?msg0 -> sender!ack0; break; :: receiver?msg1 -> server!ack1 od do :: receiver?msg1 -> sender!ack1; break; :: receiver?msg0 -> server!ack0 od } mtype = { msg0, msg1, ack0, ack1 } chan sender = [1] of { mtype }; chan receiver = [1] of { mtype };

41 Leader Election Ü Elect leader in unidirectional ring.  All processes participate in election  Cannot join after the execution started Ü Global property:  It should not be possible for more than one process to declare to be the leader of the ring LTL: [] (nr_leaders <= 1) Use assertion (line 57) assert (nr_leaders == 1) this is much more efficient!  Eventually a leader is elected  <> [] (nr_leaders == 1)

42 Verification of Leader Election 1 #define N 5 /* nr of processes */ 2 #define I 3 /* node given the smallest number */ 3 #define L 10 /* size of buffer (>= 2*N) */ 4 5 mtype = {one, two, winner}; /* symb. message names */ 6 chan q[N] = [L] of {mtype, byte} /* asynch channel */ 7 8 byte nr_leaders = 0; /* count the number of processes 9 that think they are leader of the ring */ 10 proctype node (chan in, out; byte mynumber) 11 { bit Active = 1, know_winner = 0; 12 byte nr, maximum = mynumber, neighbour; xr in; /* claim exclusive recv access to in */ 15 xs out; /* claims exclusive send access to out */ printf (“MSC: %d\n”, mynumber); 18 out!one(mynumber) /* send msg of type one */ 19 one: do 20 :: in?one(nr) -> /* receive msg of type one */

43 Verification of Leader Election 21 if 22 :: Active -> 23 if 24 :: nr != maximum -> out!two(nr); neighbour = nr; 25 :: else -> 26 /* max is the greatest number */ 27 assert (nr == N); 28 know_winner = 1; 29 out!winner(nr); 30 fi 33 :: else -> 34 out!one(nr) 35 fi :: in?two(nr) -> 38 if 39 :: Active -> 40 if

44 Verification of Leader Election 41 :: neighbour > nr && neighbour > maximum 42 maximum = neighbour; 43 out!one(neighbour) 44 :: else -> 45 Active = 0 46 fi 47 :: else -> out!two (nr) 48 fi 49 :: in?winner(nr) -> 50 if 51 :: nr != mynumber -> printf (“LOST\n”); 52 :: else -> 53 printf (“Leader \n”); 54 nr_leaders++; 55 assert(nr_leaders == 1); 56 fi 57 if 58 :: know_winner 59 :: else -> 60 out!winner(nr)

45 Verification of Leader Election 62 fi; 63 break 64 od 65 } init { 68 byte proc; 69 atomic { /* activate N copies of proc template */ 70proc = 1; 71do 72 :: proc 73 run node (q[proc-1], q[proc%N], 74 (N+I-proc)% N+1); 75 proc++ 76 :: proc > N -> break 77 od 78 } 79 }

46 Summary Ü Distinction between behavior and requirements on behavior  Which are checked for their internal and mutual consistency Ü After verification, can refine decisions towards a full system implementation  Promela is not a full programming language Ü Can simulate the design before verification starts

47 Comments Ü DFS does not necessarily find the shortest counterexample  There might be a very short counterexample but the verification might go out of memory  If we don’t finish, we might still have some sort of a result (coverage metrics)

48 On-The-Fly Ü System is the asynchronous composition of processes Ü The global transition relation is never build Ü For each state the successor states are enumerated using the transition relation of each process

49 Visited Set Ü Hash table  Efficient for testing even if the number of elements in it is very big (≥ 10 6 ) Ü Reduce memory usage  Compress each state Ü Reduce the number of states  Partial Order Reduction When a transition is executed only a limited part of the state is modified

50 SPIN and Bit-state Hashing Ü Command line:  cc –DBITSTATE –o run pan.c Ü Can specify amount of available (non-virtual) memory directly…  using –w N option, e.g., -w 7 means 128 Mb of memory $ run assertion violated … pan aborted … hash factor: (size 2^22 states, stack frames: 0/5) Ü Hash factor:  max number of states / actual number  Maximum number is 2 22 or about 32 million  Hash factor > 100 – coverage around 100%  Hash factor = 1 – coverage approaches 0%

51 State Representation Ü Global variables Ü Processes and local variables Ü Queues Global Variables Processes Queues

52 Compression Ü Each transition changes only a small part of the state Ü Assign a code to each element dynamically Ü Encoded states + basic elements use considerably less spaces than the uncompressed states

53 Compression i=0 j=0 P0 x=0 P0 x=0 P0 x=1 Q0 {1} P1 y=0 i=0 j=0 P0 x=0 P0 x=1 Q0 {1} P1 y=

54 00 P0 x=0 Q0 {1} Compression i=0 j=0 P0 x=0 P0 x=1 P0 x=1 Q0 {} P1 y=0 i=0 j=0 P0 x=0 P0 x=1 Q0 {1} P1 y= Q0 {} 11 q ? x

55 Hash Compaction Ü Uses a hashing function to store each state using only 2 bits Ü There is a non-zero probability that two states are mapped into the same bits Ü If the number of states is much smaller than the number of bits available there is a pretty good chance of not having conflicts Ü The result is not (always) 100% correct!

56 Minimized Automata Reduction Ü Turns the state into a sequence of integers Ü Constructs an automaton which accepts the states in the visited set Ü Works like a BDD but on non-binary variables (MDD)  The variables are the components of the state  The automaton is minimal  The automaton is updated efficiently

57 Partial Order Reduction Ü Optimal partial order reduction is as difficult as model checking! Ü Compute an approximation based on syntactical information  Independent  Invisible  Check (at run-time) for actions postponed at infinitum Access to local variables Receive on exclusive receive-access queues Send on exclusive send-access queues Not mentioned in the property So called stack proviso

58 References Ü Ü Design and Validation of Computer Protocols by Gerard Holzmann Ü The Spin Model Checker by Gerard Holzmann Ü An automata-theoretic approach to automatic program verification, by Moshe Y. Vardi, and Pierre Wolper Ü An analysis of bitstate hashing, by G.J. Holzmann Ü An Improvement in Formal Verification, by G.J. Holzmann and D. Peled Ü Simple on-the-fly automatic verification of linear temporal logic, by Rob Gerth, Doron Peled, Moshe Vardi, and Pierre Wolper Ü A Minimized automaton representation of reachable states, by A. Puri and G.J. Holzmann