1 / 56

The Model Checker SPIN

The Model Checker SPIN. SPIN & Promela. SPIN(= S imple P romela In terpreter) tool for analyzing the logical consistency of concurrent systems concurrent systems are described in the modeling language called Promela Promela(= Pr otocol/ Pr ocess Me ta La nguage)

airell
Download Presentation

The Model Checker SPIN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Model Checker SPIN The model checker SPIN

  2. 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

  3. 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 SPIN

  4. 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

  5. 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

  6. Promela Model mytype = {MSG, ACK}; chan toS=… chan toR=… bool flag; proctype Sender(){ … process body… } proctype Receiver(){ … process body… } init{ … } • 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 The model checker SPIN

  7. 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

  8. Process instantiation proctype Foo(byte x){ … } init{ int pid2=run Foo(2); run Foo(22); } active [...] proctype Pippo(){ … } • 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

  9. 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 SPIN

  10. 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 SPIN

  11. 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

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

  13. 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

  14. Communication (1) The model checker SPIN

  15. Communication (2) • Communication between processes is via channels: • message passing • rendez-vous synchronisation (handshake) • Both are defined as channels: chan <name> = [<dim>] of {<t1>,<t2>, … <tn>}; • 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 SPIN

  16. Communication (3) • channel = FIFO-buffer (for dim>0) • ! Sending - putting a message into a channel ch ! <expr1>, <expr2>, … <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 ? <var1>, <var2>, … <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 ? <const1>, <const2>, … <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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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 SPIN

  23. do-statement do :: choice1 -> option1; :: 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 SPIN

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

  25. 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

  26. 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

  27. 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

  28. 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

  29. Promela statements • skip always executable • assert(<expr>) always executable • expressionexecutable if not zero • assignmentalways 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 SPIN

  30. 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

  31. 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 SPIN

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

  33. proctype P1(){t1a; t1b;t1c} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()} No Atomicity 0 0 t2a t1a 1 1 t2b t1b 2 2 t2c t1c 3 3 The model checker SPIN

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

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

  36. 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

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

  38. 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 MicroProcessor() { { ... /* execute normal instructions */ } unless { port ? INTERRUPT; ... } } The model checker SPIN

  39. 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 SPIN

  40. 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 SPIN

  41. 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

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

  43. 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

  44. 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

  45. The model checker SPIN

  46. 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

  47. 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

  48. 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

  49. Promela code The model checker SPIN

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

More Related