1 / 45

The SPIN Model Checker

The SPIN Model Checker. Frederico Araujo CS6362 – Fall 2010. Outline. What is model checking? Why model checking? SPIN Basic Concepts Promela Promela Model Correctness Claims JSpin Case Studies. What is model checking?.

nitara
Download Presentation

The SPIN Model Checker

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 SPIN Model Checker Frederico Araujo CS6362 – Fall 2010

  2. Outline • What is model checking? • Why model checking? • SPIN • Basic Concepts • Promela • Promela Model • Correctness Claims • JSpin • Case Studies

  3. What is model checking? “Model checking is an automated technique that, given a finite-state model of a system and a logical property, systematically checks whether this property holds for (a given initial state in) that model.” Clarke & Emerson 1981 A (S, S0,L,T,F) Model Checker Yes or No plus a system run violating the requirement Requirement 

  4. What is model checking? Verification Model • Abstraction of a design  simplification • Express assumptions about the environment and correctness properties (Initial) Design abstraction Abstract Verification Model Model Checker refinement Implementation

  5. Why model checking? • It serves to prove that the design principles are sound • Can predict wheter a model is valid or not before its implementation • Not expected to be part of the final implementation of a system • It anticipates design defects discovery • Potential to reduce costs related to rework and risks of failures in mission-critical systems

  6. SPIN Introduction • SPIN (Simple Promela Interpreter) is a popular open-source model checker that can be used for the formal verification of asynchronous and distributed softwaresystems. • Developed at Bell Labs, starting in 1980. • Free, since 1991 • All Spin software is written in ANSI standard C, and is portable across multiple platforms • SPIN homepage is www.spinroot.com • 2002 ACM software system award for 2001

  7. SPIN Introduction • Common flaws that occur in design of distributed software systems: • Deadlock • Livelock, starvation • Underspecification • Overspecification

  8. SPIN Basic Concepts • Spin can be used in 2 basic modes : • as a simulator to get a quick impression of the behavior captured by the system model: • guided simulation • random and interactive simulation • as a verifier: when a counterexample is generated, it uses simulation to step through the trace

  9. SPIN Basic Concepts • SPIN verification: prove correctness of process interactions • Processes refer to system components that communicate with each other • Communication • rendezvous primitives (synchronous) • buffered channels (asynchronous ) • shared variables

  10. SPIN Basic Concepts • SPIN provides: • An intuitive, C-like notation (Promela) for specifying the finite-state abstraction of a system unambiguously • A notation for expressing general correctness requirements as LTL (Linear Temporal Logic) formulae

  11. Promela Introduction • PROMELA (Process Meta-language), served as input to SPIN • Non-deterministic , guarded command language for specifying the system behavior of a distributed system • 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

  12. Promela Introduction • Behavior specicification (what is possible) • process behavior • variables, data types • message channels • Logical correctness properties (what is valid) • assertions • end-state, progress-state, and acceptance state labels • never claims (LTL formulae) • trace assertions • default properties: • absence of system deadlock • absence of unreachable code The properties define the real objectif of a verification

  13. Promela Model • Consists of • Process • Data objects • Message channels • Corresponds to a FSM • Every object is bounded • Process  255* • Message channels  255* • Data  data type dependent * For current versions of SPIN mytype = {MSG, ACK}; chantoS=… chantoR=… bool flag; active proctype Sender(){ …process body… } active proctype Receiver(){ …process body… }

  14. Promela Processes • Basic structure proctype Sender(chan in; chan out) { ... process body ... } • Process creation • init and active proctype You_run() { ... process body ... } init { run You_run(); } active proctypeYou_run() { ... process body ... } active [2] proctypeYou_run_b() { ... process body ... }

  15. Promela Processes • There can be more than one process inside a Promela model • A process executes concurrently with other processes. • A process also communicates with other processes by sending/receiving messages across channels by using shared (global) variables with other processes • Local state of a process is defined by process counter (defines the location of the process) and the values of the local variables of the process.

  16. Promela Data Objects • Variables can be local or global • Default initial value of both local and global variables is 0 • Variables can be assigned a value by an assignment, argument passing or message passing • Variables can be used in expressions which includes most arithmetic, relational and logical operators of C

  17. Promela Basic Types Basic Types Array Declaration Array Access Records type definition Record declaration Record Access Enumeration type for messages From Verification Techniques lecture notes, Uppsala Universitet, Sweden

  18. Promela Expressions Operators Conditional expressions Operations on channels identifiers From Verification Techniques lecture notes, Uppsala Universitet, Sweden

  19. Promela Message Channels • Communication between processes through channels • FIFO • Declared as arrays • There can be two types of communications: • Message-passing or asynchronous • Rendezvous or synchronous (channel of dimension 0)

  20. Promela Message Channels • Declaration chanqname = [16] of {short, byte, bool} • Sending message qname!expr1, expr2, expr3 • Receiving message qname?var1, var2, var3 constrained  qname?cons1,var2,var3 • To test if a send receive can be executable without side effect qname?[var1, var2, var3]

  21. Promela Message Channels • Asynchronous communication mtype = { msg0, msg1, ack0, ack1 }; chanto_sndr = [2] of { mtype }; chanto_rcvr = [2] of { mtype }; active proctype Sender(){ again: to_rcvr!msg1; to_sndr?ack1; to_rcvr!msg0; to_sndr?ack0; goto again } active proctype Receiver(){ again: to_rcvr?msg1; to_sndr!ack1; to_rcvr?msg0; to_sndr!ack0; goto again }

  22. Promela Message Channels • Synchronous communication (rendezvous) mtype = { msgtype }; chan name = [0] of { mtype, byte }; active proctype A(){ name!msgtype(124); name!msgtype(121) } active proctype B(){ byte state; name?msgtype(state) }

  23. Promela Message Channels • Synchronous communication (rendezvous) mtype = { msgtype }; chan glob = [0] of { chan }; active proctype A(){ chan loc = [0] of { mtype, byte }; glob!loc; loc?msgtype(121) } active proctype B(){ chan who; glob?who; who!msgtype(121) }

  24. Promela Statements • Statements are separated by a semi-colon • Assignments and expressions are statements • skip statement: does nothing, only changes the process counter • printf statement: not evaluated during verification • assert(expr): Assert statement is used to check if the property specified by the expression expr is valid within a state. If expr evaluates to 0, it implies that it is not valid and SPIN will exit with an error.

  25. Promela Statements • if statement if :: choice1 -> stat1.1; stat1.2; :: choice2 -> stat2.1; stat2.2; :: … :: choicen -> statn.1; statn.2; fi; • if statement is executable if there is at least one choice which is executable and is blocked if none of the choices are executable • If more than one choice is executable, SPIN non-deterministically chooses one of the executable choices

  26. Promela Statements • do statement do :: choice1 -> stat1.1; stat1.2; :: choice2 -> stat2.1; stat2.2; :: … :: choicen -> statn.1; statn.2; od; • do statement behaves in the same way as if statement in terms of choice selection but, executes the choice selection repeatedly • break statement can be used to come out of a do loop transferring control to the statement just outside the loop

  27. Promela Atomic operator • A process whose control is inside atomic{ } executes without being interrupted by other processes From Verification Techniques lecture notes, Uppsala Universitet, Sweden

  28. Promela Correcteness Claims • Basic assertions (checked during simulation run) • End-state labels • Progress-state labels • Accept-state labels checked during verification run • Never claims • Trace assertions

  29. Promela Correcteness Claims safety property “nothing bad ever happens” • invariant x is always less than 5 • deadlock freedom the system never reaches a state where no actions are possible • SPIN find a trace leading to the “bad” thing. If there is not such a trace, the property is satisfied. liveness property “something good will eventually happen” • termination the system will eventually terminate • response if action X occurs then eventually action Y will occur • SPIN find a (infinite) loop in which the “good” thing does not happen. If there is not such a loop, the property is satisfied.

  30. Promela Correcteness Claims Correctness properties can be expressed: • as properties of reachable states (generic safety properties) • as properties of sequences of states (generic livenessproperties) In Promela: assertions local process assertions system invariants end-state labels to define proper termination points of processes properties of states accept-state labels when looking for acceptance cycles progress-state labels when looking for non-progress cycles never claims (optionally derived from LTL formulae) trace assertions properties of sequences of states

  31. Promela Correcteness Claims • Assertion • byte state = 1; • active proctype A() • { • (state == 1) -> state++; • assert(state== 2) • } • active proctype B() • { • (state == 1) -> state--; • assert(state== 0) • } pan: assertion violated (state==2) (at depth 6) pan: wrote assertion-example.pml.trail (Spin Version 4.3.0 -- 22 June 2007) Warning: Search not completed + Partial Order Reduction Full statespace search for: never claim - (none specified) assertion violations + cycle checks - (disabled by -DSAFETY) invalid end states - (disabled by -E flag) State-vector 16 byte, depth reached 6, ••• errors: 1 ••• 10 states, stored 0 states, matched 10 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.302 memory usage (Mbyte)

  32. Promela Correcteness Claims • Assertion • byte state = 1; • active proctype A() • { • (state == 1) -> state++; • assert(state== 2) • } • active proctype B() • { • (state == 1) -> state--; • assert(state== 0) • } pan: assertion violated (state==2) (at depth 6) pan: wrote assertion-example.pml.trail (Spin Version 4.3.0 -- 22 June 2007) Warning: Search not completed + Partial Order Reduction Full statespace search for: never claim - (none specified) assertion violations + cycle checks - (disabled by -DSAFETY) invalid end states - (disabled by -E flag) State-vector 16 byte, depth reached 6, ••• errors: 1 ••• 10 states, stored 0 states, matched 10 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.302 memory usage (Mbyte) What is the problem with this model?

  33. Promela Correcteness Claims • Assertion byte state = 1; active proctype A() { atomic {(state == 1) -> state++; } assert(state== 2) } active proctype B() { atomic{(state == 1) -> state--;} assert(state== 0) } (Spin Version 4.3.0 -- 22 June 2007) + Partial Order Reduction Full statespace search for: never claim - (none specified) assertion violations + cycle checks - (disabled by -DSAFETY) invalid end states - (disabled by -E flag) State-vector 16 byte, depth reached 3,••• errors: 0 ••• 6 states, stored 0 states, matched 6 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.302 memory usage (Mbyte) unreached in proctype A (0 of 5 states) unreached in proctype B (0 of 5 states)

  34. Promela Correcteness Claims • End-state mtype= { p, v }; chansem= [0] of { mtype}; byte count; active proctype semaphore() { end: do :: sem!p-> sem?v od } active [5] proctype user() { end: do :: sem?p; count++; /* critical section */ count--; sem!v od } (Spin Version 4.3.0 -- 22 June 2007) + Partial Order Reduction Full statespace search for: never claim - (none specified) assertion violations + cycle checks - (disabled by -DSAFETY) invalid end states + State-vector 36 byte, depth reached 5, ••• errors: 0 ••• 16 states, stored 5 states, matched 21 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.302 memory usage (Mbyte) unreached in proctype semaphore line 9, state 6, "-end-" (1 of 6 states) unreached in proctype user line 19, state 8, "-end-" (1 of 8 states)

  35. Promela Correcteness Claims • Progress-state mtype= { p, v }; chansem= [0] of { mtype}; byte count; active proctype semaphore() { end: do :: sem!p-> progress: sem?v od } active [5] proctype user() { end: do :: sem?p; count++; /* critical section */ count--; sem!v od } (Spin Version 4.3.0 -- 22 June 2007) + Partial Order Reduction Full statespace search for: never claim + assertion violations + (if within scope of claim) non-progress cycles + (fairness disabled) invalid end states - (disabled by never claim) State-vector 44 byte, depth reached 9, ••• errors: 0 ••• 21 states, stored 5 states, matched 26 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.302 memory usage (Mbyte) unreached in proctype semaphore line 10, state 6, "-end-" (1 of 6 states) unreached in proctype user line 20, state 8, "-end-" (1 of 8 states) Non-progress verification

  36. Promela Correcteness Claims • SPIN’s automata for semaphore problem End: End: Progress:

  37. Promela Correcteness Claims Fairness  finite progress assumption when a process can make progress, it eventually will 1. weak fairness: if a statement is executable infinitely long, it will eventually be executed 2. strong fairness: if a statement is executable infinitely often, it will eventually be executed fairness can be applied to • non-deterministic statement selection within a process • non-deterministic statement selection between processes

  38. Promela Correcteness Claims • Accept-state mtype= { p, v }; chansem= [0] of { mtype}; byte count; active proctype semaphore() { do :: sem!p-> sem?v od } active [5] proctype user() { do :: sem?p-> accept: count++; /* critical section */ count--; sem!v od } pan: acceptance cycle (at depth 0) pan: wrote _accept-example.pml.trail (Spin Version 4.3.0 -- 22 June 2007) Warning: Search not completed + Partial Order Reduction Full statespace search for: never claim - (none specified) assertion violations + acceptance cycles + (fairness disabled) invalid end states + State-vector 40 byte, depth reached 5, ••• errors: 1 ••• 4 states, stored 0 states, matched 4 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) 2.302 memory usage (Mbyte) Acceptance verification

  39. Promela Correcteness Claims • SPIN’s counterexample for acceptance example Implicit meaning: there should not exist any executions that can pass through an accept-state infinitely often

  40. Promela Correcteness Claims • Linear Temporal Logic (LTL) and Buchi Automata • never { /* <>(p&&[]!q) */ • T0_init: • if • :: (! ((q)) && (p)) -> goto accept_S4 • :: (1) -> goto T0_init • fi; • accept_S4: • if • :: (! ((q))) -> goto accept_S4 • fi; • } From Verification Techniques lecture notes, Uppsala Universitet, Sweden • Temporal logic operators: •   eventually •   always

  41. Promela Correcteness Claims • Never claim • Needed capability for defining more precise checks • Implicit meaning: specifies finite or infinite behavior that should never occur Note: p and q need to be defined as macros: #define p (x>10) #define q (x<100) • never { /* <>(p&&[]!q) */ • T0_init: • if • :: (! ((q)) && (p)) -> goto accept_S4 • :: (1) -> goto T0_init • fi; • accept_S4: • if • :: (! ((q))) -> goto accept_S4 • fi; • }

  42. JSpin • It is a java based GUI for SPIN model checker JSpin • Adapted from Theo C. Ruys- SPIN Beginners' Tutorial

  43. Case Studies • peterson’s mutual exclusion algorithm • paper: Towards a Methodology for Formal Design and Analysis of Agent Interaction Protocols

  44. References • Gerard J. Holzmann.The SPIN model checker: primer and reference guide, Addison-Wesley, September 2003 • G. Holzmann, The Model Checker Spin ,IEEE Trans. on Software Engineering, Vol. 23, No. 5, May 1997, pp. 279-295 • SPIN page: http://spinroot.com • Theo C. Ruys. SPIN Beginners’ Tutorial, SPIN Workshop 2002, Grenoble, France, 2002 • Wei Jun, Cheung Shing-Chi, Wang Xul. Towards a Methodology for Formal Design and Analysis of Agent Interaction Protocols - An Investigation in Electronic Commerce, Wuhan University Journal of Natural Sciences Vol. 6 No. 1-2, 2001

  45. Questions?

More Related