The Model Checker SPIN The model checker SPIN

The Model Checker SPIN The model checker SPIN

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 SPIN

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 software systems. • Developed in Bell Laboratories. The model checker SPIN

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 SPIN

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 SPIN

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 to. S=… chan to. R=… bool flag; proctype Sender(){ … process body… } proctype Receiver(){ … process body… } init{ … } The model checker SPIN

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 SPIN

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 The model checker SPIN proctype Foo(byte x){ … } init{ int pid 2=run Foo(2); run Foo(22); } active [. . . ] proctype Pippo(){ … }

Example proctype Sender(chan in; chan out){ bit snd. B, rcv. B; do : : out ! MSG, snd. B -> in ? ACK, rcv. B; if : : snd. B == rcv. B -> snd. B= 1 -snd. B : : else -> skip fi od } The model checker SPIN

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 f 1; byte f 2; } The model checker SPIN

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 SPIN

Variables and Types (3) • mtype: a way to introduce symbolic constant values – mtype declaration (up to 255 names): mtype = { msg 0, ack 0, msg 1, ack 1 } • pid 0. . 255 • Communication channel – chan 0… 255 The model checker SPIN

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 SPIN

Communication (1) The model checker SPIN 14

Communication (2) • Communication between processes is via channels: – message passing – rendez-vous synchronisation (handshake) • Both are defined as channels: chan <name> = [<dim>] of {<t 1>, <t 2>, … <tn>}; – t 1…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 to. R = [2] of {mtype, bit}; – chan line[2] = [1] of {mtype, Record}; array of channels The model checker SPIN

Communication (3) • channel = FIFO-buffer (for dim>0) • ! Sending - putting a message into a channel ch ! <expr 1>, <expr 2>, … <exprn>; – The values of <expri> 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 ? <var 1>, <var 2>, … <varn>; 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 <vari>s. ch ? <const 1>, <const 2>, … <constn>; message testing – If the channel is not empty and the message at the front of the channel evaluates to the individual <consti>, the statement is executable and the message is removed from the channel. The model checker SPIN

Communication (4) • Rendez-vous communication <dim> == 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 SPIN

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 SPIN

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 SPIN

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(<expr>); – The assert-statement is always executable. – If <expr> evaluates to zero, SPIN will exit with an error, as the <expr> “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 SPIN

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 SPIN

if-statement If : : choice 1 -> option 1 : : choice 2 -> option 2 : : else -> option 3 /* optional */ fi • Cases need not be exhaustive or mutually exclusive • Non-deterministic selection The model checker SPIN

do-statement do : : choice 1 -> option 1; ………. : : choice 1 -> option 1; 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 SPIN

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

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 SPIN

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

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 SPIN

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 SPIN

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

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 SPIN

atomic { stat 1; stat 2; . . . 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 stat 1 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 SPIN

d_step { stat 1; stat 2; . . . 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 SPIN 32

proctype P 1(){t 1 a; t 1 b; t 1 c} proctype P 2(){t 2 a; t 2 b; t 2 c} init{run P 1(); run P 2()} 0 0 t 2 a t 1 a 1 1 t 2 b t 1 b 2 2 t 2 c t 1 c 3 No Atomicity 3 The model checker SPIN 33

proctype P 1(){atomic{t 1 a; t 1 b; t 1 c}} proctype P 2(){t 2 a; t 2 b; t 2 c} init{run P 1(); run P 2()} Atomicity It is as P 1 has only one transition, but if one P 1’s transitions blocks, these transition may be executed The model checker SPIN 34

proctype P 1(){d_step{t 1 a; t 1 b; t 1 c}} proctype P 2(){t 2 a; t 2 b; t 2 c} init{run P 1(); run P 2()} The model checker SPIN d_step 35

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 SPIN

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 : : Chunk. Timeout? SHAKE -> if : : (rc < MAX) -> rc++; F!(i==1), (i==n), ab, d[i]; goto wait_ack : : (rc >= MAX) -> goto error fi fi; The model checker SPIN

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

never { stmnt 1; stmnt 2; … 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 SPIN

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

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 SPIN

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

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 SPIN

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 SPIN

The model checker SPIN 45

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 SPIN

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 SPIN

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 SPIN

Promela code The model checker SPIN

Global Variables • #define N • #define I 5 /*# of processes*/ 3 /*process with the smallest identifier*/ • #define L 10 /*size of buffer*/ • chan q[N] = [L] of {byte} The model checker SPIN

Initialization The model checker SPIN

Simulation run in Spin The model checker SPIN

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

Automaton generated by Spin The model checker SPIN

Property Verification The model checker SPIN

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. The model checker SPIN