The model checker SPIN1 The Model Checker SPIN

The model checker SPIN2 SPIN & Promela SPIN(=Simple Promela Interpreter) –tool for analyzing the logical consistency of concurrent systems –concurrent systems are described in the modeling language called Promela Promela(=Protocol/Process Meta Language) –dynamic creation of concurrent processes –communication via message channels –specification language to model finite-state model –C like

The model checker SPIN3 What is SPIN? (1) “Press on the button” model-checker, based on automata theory A popular open-source software tool that can be used for the formal verification of asynchronous and distributed asynchronous and distributed software systems. Developed in Bell Laboratories.

The model checker SPIN4 What is SPIN? (2) Spin can be used in 2 basic modes : –as a simulator to get a quick impression of the types of the behaviour captured by the system model: guided simulation random and interactive simulation –as a verifier generator: when a counterexample is generated, it uses simulation to step through the trace

The model checker SPIN5 Promela Non-deterministic, guarded command language for specifying the possible system behaviours in a distributed system design –Systems of interacting, asynchronous threads of execution It brings ideas from: –CSP process algebra by Hoare for input/output –C language in some of the syntax and notational conventions –a non-deterministic guarded command language (without msg passing primitives) by Dijkstra

The model checker SPIN6 Promela Model Promela model consists of –type declaration –channel declarations –variable declarations –process declarations –[init process] A Promela model corresponds with a FSM, so: –no unbounded data –no unbounded channels –no unbounded processes –no unbounded process creation mytype = {MSG, ACK}; chan toS=… chan toR=… bool flag; proctype Sender(){ … process body… } proctype Receiver(){ … process body… } init{ … }

The model checker SPIN7 Processes A process type consists of –a name –a list of formal parameters –local variable declarations –body A process executes concurrently with all other processes, independent of speed of behaviour There may be several processes of the same type Each process has its own local state (process counter, local variables)

The model checker SPIN8 Process instantiation Processes are created using the run statement (it returns the process id) and start executing after it Processes can be created at any point in the execution Processes can also be activate by adding in front of the proctype declaration proctype Foo(byte x){ … } init{ int pid2=run Foo(2); run Foo(22); } active [...] proctype Pippo(){ … }

The model checker SPIN9 Example proctype Sender(chan in; chan out){ bit sndB, rcvB; do :: out ! MSG, sndB -> in ? ACK, rcvB; if :: sndB == rcvB -> sndB= 1-sndB :: else -> skip fi od }

The model checker SPIN10 Variables and Types (1) Basic integer types: bit, bool, byte, short, int, unsigned Arrays: fixed size byte a[27]; bit flags[4]; Records typedef Record{ short f1; byte f2; }

The model checker SPIN11 Variables and Types (2) Variables should be declared int ii, bb; Variables can be given a value by –assignment bb=1; Rercord f; f.bb=1; –argument passing –message passing

The model checker SPIN12 Variables and Types (3) mtype: a way to introduce symbolic constant values –mtype declaration (up to 255 names): mtype = { msg0, ack0, msg1, ack1 } pid Communication channel –chan 0…255

The model checker SPIN13 Predefined Variables else –value=true iff no statement in the current process is executable timeout –value=true iff no statement in the model is executable _ –write-only scratch variable, does not store a value _pid –the current process’s instantiation number _nr_pr –the number of active processes _last –the pid of process that executed last

The model checker SPIN14 Communication (1)

The model checker SPIN15 Communication (2) Communication between processes is via channels: –message passing –rendez-vous synchronisation (handshake) Both are defined as channels: chan = [ ] of {,, … }; –t1…tn = type of the elements that will be transmitted over the channel –dim = number of elements in the channel [dim==0 is special case: rendez-vous] Examples: –chan c = [1] of {bit}; –chan toR = [2] of {mtype, bit}; –chan line[2] = [1] of {mtype, Record}; array of channels

The model checker SPIN16 Communication (3) channel = FIFO-buffer (for dim>0) ! Sending - putting a message into a channel ch !,, … ; –The values of should correspond with the types of the channel declaration. –A send-statement is executable if the channel is not full. ? Receiving - getting a message out of a channel ch ?,, … ; message passing –If the channel is not empty, the message is fetched from the channel and the individual parts of the message are stored into the s. ch ?,, … ;message testing –If the channel is not empty and the message at the front of the channel evaluates to the individual, the statement is executable and the message is removed from the channel.

The model checker SPIN17 Communication (4) Rendez-vous communication == 0 The number of elements in the channel is now zero. –If send ch! is enabled and if there is a corresponding receive ch? that can be executed simultaneously and the constants match, then both statements are enabled. –Both statements will “handshake” and together take the transition. Example: chan ch = [0] of {bit, byte}; –P wants to do ch ! 1, 3+7 –Q wants to do ch ? 1, x –Then after the communication, x will have the value 10.

The model checker SPIN18 Communication (5) len(q) : returns the number of messages in q empty(q) : true when q is currently empty full(q) : true when q is filled to capacity nempty(q) : added to support optimization nfull(q) : added to support optimization

The model checker SPIN19 Statements (1) The body of a process consists of a sequence of statements. A statement is either –executable: the statement can be executed immediately. –blocked: the statement cannot be executed. An assignment is always executable. An expression is also a statement; it is executable if it evaluates to non-zero. –2 < 3 always executable –x < 27 only executable if value of x is smaller 27 –3 + x executable if x is not equal to –3

The model checker SPIN20 Statements (2) The skip statement is always executable. –“does nothing”, only changes process’ process counter A run statement is only executable if a new process can be created (remember: the number of processes is bounded). A printf (printm) statement is always executable (but is not evaluated during verification, of course). assert( ); –The assert-statement is always executable. –If evaluates to zero, SPIN will exit with an error, as the “has been violated”. –The assert-statement is often used within Promela models, to check whether certain properties are valid in a state.

The model checker SPIN21 Interleaving Semantics Promela processes execute concurrently. Non-deterministic scheduling of the processes. Processes are interleaved (statements of different processes do not occur at the same time). –exception: rendez-vous communication. All statements are atomic; each statement is executed without interleaving with other processes. Each process may have several different possible actions enabled at each point of execution. –only one choice is made, non-deterministically.

The model checker SPIN22 if-statement If :: choice1 -> option1 :: choice2 -> option2 :: else -> option3/* optional */ fi Cases need not be exhaustive or mutually exclusive Non-deterministic selection

The model checker SPIN23 do-statement do :: choice1 -> option1; ………. :: choice1 -> option1; od; With respect to the choices, a do-statement behaves in the same way as an if-statement. However, instead of ending the statement at the end of the choosen list of statements, a do-statement repeats the choice selection. The (always executable) break statement exits a do-loop statement and transfers control to the end of the loop.

The model checker SPIN24 Example proctype counter() { do :: (count != 0) -> if :: count = count + 1 :: count = count – 1 fi :: (count == 0) -> break od }

The model checker SPIN25 Delimitors Semi-colon is used a statement separator not a statement terminator –Last statement does not need semi-colon –Often replaced by -> to indicate causality between two successive statements –(a == b); c = c + 1 –(a == b) -> c = c + 1

The model checker SPIN26 Variable scoping Similar to C –globals, locals, parameters byte foo, bar, baz; proctype A(byte foo) { byte bar; baz = foo + bar; }

The model checker SPIN27 Send and Receive Executability Send is executable only when the channel is not full Receive is executable only when the channel is not empty Optionally some arguments of receive can be constants –qname?RECV,var,10 –Value of constant fields must match value of corresponding fields of message at the head of channel queue

The model checker SPIN28 Composite conditions Invalid in Promela –(qname?var == 0) –(a > b && qname!123) –Either send/receive or pure expression Can evaluate receives –qname?[ack,var]

The model checker SPIN29 Promela statements skip always executable assert( ) always executable expression executable if not zero assignment always executable if executable if at least one guard is executable do executable if at least one guard is executable break always executable (exits do-statement) send (ch!) executable if channel ch is not full receive (ch?) executable if channel ch is not empty

The model checker SPIN30 assert assert(any_boolean_condition) –pure expression If condition holds -> no effect If condition does not hold -> error report during verification with Spin

The model checker SPIN31 atomic atomic { stat1; stat2;... statn } can be used to group statements into an atomic sequence; all statements are executed in a single step (no interleaving with statements of other processes) is executable if stat1 is executable if a stati (with i>1) is blocked, the “atomicity token” is (temporarily) lost and other processes may do a step no pure atomicity

The model checker SPIN32 d_step d_step { stat1; stat2;... statn } more efficient version of atomic: no intermediate states are generated and stored may only contain deterministic steps it is a run-time error if stati (i>1) blocks. d_step is especially useful to perform intermediate computations in a single transition

The model checker SPIN33 proctype P1(){t1a; t1b;t1c} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()} t1c t1b t1a t2c t2b t2a No Atomicity

The model checker SPIN34 proctype P1(){atomic{t1a; t1b;t1c}} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()} It is as P1 has only one transition, but if one P1’s transitions blocks, these transition may be executed Atomicity

The model checker SPIN35 d_step proctype P1(){d_step{t1a; t1b;t1c}} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()}

The model checker SPIN36 timeout Promela does not have real-time features. –In Promela we can only specify functional behaviour. –Most protocols, however, use timers or a timeout mechanism to resend messages or acknowledgements. timeout –SPIN’s timeout becomes executable if there is no other process in the system which is executable –so, timeout models a global timeout –timeout provides an escape from deadlock states –beware of statements that are always executable… timeout can be replaced by skip

The model checker SPIN37 goto goto label transfers execution to label each Promela statement might be labelled quite useful in modelling communication protocols wait_ack: if :: B?ACK -> ab=1-ab ; goto success :: ChunkTimeout?SHAKE -> if :: (rc rc++; F!(i==1),(i==n),ab,d[i]; goto wait_ack :: (rc >= MAX) -> goto error fi fi;

The model checker SPIN38 unless { } unless { guard; } –Statements in are executed until the first statement ( guard) in the escape sequence becomes executable. –resembles exception handling in languages like Java Example: proctype MicroProcessor() { {... /* execute normal instructions */ } unless { port ? INTERRUPT;... } }

The model checker SPIN39 never never { stmnt1; stmnt2; … stmntn } –used to specify behavior that should never happen –the claim is defined as a series of propositions, or boolean expressions, on the system state that must become true in the sequence specified for the behavior of interest to be matched –a never claim can be used to match either finite or infinite behaviors (i.e., safety and liveness properties, and LTL formulae) –it can either be written by hand or they can be generated mechanically from LTL formula

The model checker SPIN40 LTL patterns Invariance[] (p) –Spin supports 7 ways to check for invariance Response[] ((p) -> (<> (q))) Precedence[] ((p) -> ((q) U (r))) Objective[] ((p) -> <>((q) || (r)))

The model checker SPIN41 Invariance Add the following monitor process to the Promela model: active proctype monitor() { assert(P); } Two variations: –monitor process is created first –monitor process is created last (the –end- transition will be executable after executing assert(P)) SPIN translates the LTL formula to an accepting never claim. never { ![]P TO_init: if :: (!P) -> goto accept_all :: (1) -> goto TO_init fi; accept_all: skip }

The model checker SPIN42 SPIN Architecture LTL Translator SPIN Counter example Simulator Verifier Generator C Program Checker Promela Model M XSPIN 

The model checker SPIN43 Spin capabilities Interactive simulation –For a particular path –For a random path Exhaustive verification –Generate C code for verifier –Compile the verifier and execute –Returns counter-example Lots of options for fine-tuning

The model checker SPIN44 State vector A state vector is the information to uniquely identify a system state; it contains: –global variables –contents of the channels –for each process in the system: local variables process counter of the process SPIN provides several algorithms to compress the state vector.

The model checker SPIN45

The model checker SPIN46 Reduction algorithms SPIN has several optimisation algorithms to make verification runs more effective: –partial order reduction: if in some global state, a process P can execute only “local” statements, then all other processes may be deferred until later –bitstate hashing: instead of storing each state explicitly, only one bit of memory are used to store a reachable state –minimised automaton encoding of states (not in a hashtable): states are stored in a dynamically changing, minimised DFA inserting/deleting a state changes the DFA close relationship with OBDDs –state vector compression: instead of storing a state explicitly, a compressed version of the state is stored in the state space –dataflow analysis –slicing algorithm: to get hints for possible reductions

The model checker SPIN47 Leader Election Protocol N processes in a ring topology connected by unbounded channels A process can only send messages in a clockwise manner Initially each process has a unique identifier assumed to be a natural number The purpose of a leader election protocol is to make sure that exactly one process will become the leader. The idea that the process with the highest identier should be elected as a leader

The model checker SPIN48 LEP Algorithm Active: d:=ident; do forever begin send(d); receive(e); if e= d then stop; (*process d is the leader*); send(e); receive(f); if e>=max(d,f) then d:=e else goto relay end relay: do forever begin receive(d); send(d); end

The model checker SPIN49 Promela code

The model checker SPIN50 Global Variables #define N5 /*# of processes*/ #define I3 /*process with the smallest identifier*/ #define L10 /*size of buffer*/ chan q[N] = [L] of {byte}

The model checker SPIN51 Initialization

The model checker SPIN52 Simulation run in Spin

The model checker SPIN53 [] p #define p (nr_leaders <=1) Nr_leaders++;

The model checker SPIN54 Automaton generated by Spin

The model checker SPIN55 Property Verification

The model checker SPIN56 Research trends Combine with theorem-proving (PVS). Parameterized verification. –Verify the n-component system for all n. –Pipelines with n stages. –Cache protocol with n memory units. –….. Infinite state systems Timed systems (TRIO Model Checker). Hybrid systems.