1. FMuOS: Formal verification of critical program parts NuSMV system Prepared by: Alan Jović, Ph.D. Acad. year: 2014/2015

2. Introduction NuSMV ◦ system for symbolic model checking ◦ extended and upgraded version of the original SMV system (therefore this Nu [new] ) Original SMV (Symbolic Model Verifier) ◦ Developed by K. McMillan, CMU, as PhD thesis in 1992.

3. Introduction NuSMV is a program with which one checks whether: M |= φ, (implementation M logically satisfies specification φ ), where M is the Kripke structure, φ is CTL or LTL logical property (specification) Verilog: description and verification of hardware NuSMV: verification of program parts Property specification in CTL or LTL Language for model description Algorithm for model checking NuSMV system EXIT

4. Introduction System input: ◦ Textual description of programs in NuSMV language – system model ◦ Specification of properties in CTL or LTL logics (also in RTCTL (Real- Time CTL) and PSL - Property Specification Language) ◦ Within this course in laboratory exercises we will use only the CTL logic when specifying and checking properties System output: ◦ ‘TRUE‘ – if the specification is satisfied for all model starting states ◦ ‘FALSE‘ - else + trace that shows why the specification is not satisfied in the model described by the SMV program Algorithm for model checking ◦ Based on simbolic state and transition representation using BDDs (the topic of last lectures of this course) ◦ It is possible to explicitly choose to use SAT solver for CTL and LTL, that are normally used for bounded model checking of specification (not done in these laboratory exercises)

5. NuSMV input language Motivation during modeling ◦ description of system control and parts in interaction ◦ especially used for modeling of critical sections The intention of the input language: description of transition relation of the finite Kripke structure ◦ Using NuSMV system one can describe communicating finite state machines (FSMs). ◦ NuSMV language does not support complex data structures (lists, trees, maps...) Similar to hardware description languages, but that is not its purpose

6. NuSMV programs NuSMV programs are composed of one or more modules ◦ The only special module is module main (similar to C, Java,... ) Each module is usually composed of: ◦ Variable declarations ◦ Assigning values to variables ◦ Specifications (properties) that need to be checked (mostly in the main module)

7. Variables (1/2) Variables in NuSMV represent state variables of the model and instances of individual modules (e.g. if one wants to model a system consisting of five equal processors then one makes a module processor and five variables of type processor) Variable declaration: decl :: "VAR" atom1 ":" type1 ";" atom2 ":" type2 ";"... Variable type ( type1, type2...) can be: ◦ boolean ◦ word (bit vector of predetermined length) ◦ enumerated type ◦ integer (with the possibility of defining a finite subset) ◦ user-defined module (module instance), ◦ an array of previously mentioned types

8. Variables (2/2) Some examples of declarations: VAR a : boolean; w : word[7]; switch : {on, off}; state : {start, request, busy, stop}; n : 1..10000; server6 : Server(req, stateClient); producerWG : process Producer(); arr : array 1..20 of {start, busy, stop}; Type boolean can adopt values of FALSE or TRUE (attention: NuSMV v2.5.1 and above does not support boolean values 0 and 1) The keyword process before module name defines asynchronous execution mode

9. Assignments (1/2) Assignments provide variables with ◦ Initial value – init ◦ Next value (based on momentary values of program variable values) - next Assigning values to variables: decl :: "ASSIGN" dest1 ":=" expr1 ";" dest2 ":=" expr2 ";"... dest :: atom | "init" "(" atom ")" | "next" "(" atom ")"

10. Assignments (2/2) On the left side of an assignment - ◦ atom signifies momentary value of a variable, ◦ init(atom) signifies starting value of a variable, ◦ next(atom) signifies a value of a variable in the next state The right side of an assignment can be evaluated into: ◦ Integer value or symbolic constant ◦ A set of values In the first case, the left side simply becomes the right side, while in the second case the left side becomes one of the elements from the right side (non-determinism) Assignment example: ASSIGN a := n mod 2; init(switch) := off; next(state) := {busy, stop};

11. Property specification (1/2) Specification of system behavior is given by an expression in CTL time logic CTL expression in the NuSMV system: decl :: “CTLSPEC" ctlform –-instead of CTLSPEC you can also write SPEC ctlform :: expr ;; Boolean formula | "!" ctlform ;; logical negation | ctlform1 "&" ctlform2 ;; logical ‘and’ | ctlform1 "|" ctlform2 ;; logical ‘or’ | ctlform1 "->" ctlform2 ;; logical implication | ctlform1 " " ctlform2 ;; logical equivalence | "E" pathform ;; existential quantifier of a path | "A" pathform ;; universal quantifier of a path

12. Property specification (2/2) CTL expression in the NuSMV system (continued): pathform :: "X" ctlform- next state operator | "F" ctlform - operator of a final arrival in state | "G" ctlform- operator of the whole path | "[" ctlform1 "U" ctlform2 "]" – operator by which on the whole path ctlform1 is valid until ctlform2 is valid Each CTL expresion is definied by a new CTLSPEC specification. Specification examples: CTLSPEC AG AF state=start CTLSPEC EF n>=40 CTLSPEC E [ b=TRUE U state=busy ] CTLSPEC AG (state=request -> AF state=busy)

13. SMV primjer 1. MODULE main VAR request : boolean; status : {ready,busy}; ASSIGN init(status) := ready; next(status) := case request : busy; TRUE : {ready,busy}; esac; CTLSPEC AG (request -> AF status = busy) Variables request - variable of type boolean, TRUE or FALSE status - is enumerated variable that can become ready or busy Initial and next values of request variable are not determined in the program. In this way, the influence of the environment is modeled (NuSMV system can assign arbitrary values to that variable). Variable status is partially specified: initially it has the value of ready, and becomes busy if request is TRUE. Otherwise, if request is FALSE, then the value is not determined. FSM is comprised of four states – each state corresponds to possible values of two binary (boolean) variables System state S is generally defined based on all possible variable values: System variables: v1 : T1; v2 : T2;... vn : Tn; System state S: T1 × T2 ×... × Tn

14. Non-deterministic values Variable can non-deterministically obtain its values in two basic ways: ◦ Implicitly – variable is not assigned with any value (input variable) ◦ Explicitly – by non-deterministic assignments: variable is assigned with a set of values (variable obtains a single value from the set non-deterministically (randomly)) NuSMV example: ◦ The influence of the variable request is an example of implicit non-determinism An example of explicit non-deteminism: ◦ next(status) := case TRUE : {ready, busy}; Non-deterministic assignments – used for modeling the environment, incomplete implementations or for forming abstractions of complicated protocols, where an exact state variable value can not be determined

15. Modules in NuSMV NuSMV supports system description by dividing the code into several modules (which enables verification of interaction properties between system parts) Module is instantiated so that a variable is declarated which type is the name of the module The access to variables within the module is performed by the dot operator: "." ◦ For example: m.v - variable v within module m is being accessed

16. NuSMV example: Three-bit counter MODULE main VAR bit0 : counter_cell(TRUE); bit1 : counter_cell(bit0.carry_out); bit2 : counter_cell(bit1.carry_out); CTLSPEC AG AF bit2.carry_out MODULE counter_cell(carry_in) VAR value : boolean; ASSIGN init(value) := FALSE; next(value) := value xor carry_in; DEFINE carry_out := value & carry_in;

17. NuSMV example: Three-bit counter This NuSMV program describes a counter that repeatedly counts from 000 to 111 Three-bit counter is described using three simple one-bit counters: ◦ Module counter_cell is instantiated three times: bit0, bit1 and bit2. ◦ Each module has a single formal parameter: carry_in ◦ Modules are interconnected so that carry_in of module bit1 is also carry_out of module bit0 (the same goes for bit2 and bit1 ) Keyword DEFINE is used as a macro for assigning the value of expression value & carry_in to the simbol carry_out This means that wherever carry_out is used, it will be replaced with the expression value & carry_in Keyword DEFINE does not expand state space DEFINE can not work with non-deterministic values

18. Synchronous and asynchronous execution in NuSMV Synchronous execution – a global clock exists, and with each clock tick, each module (ASSIGN block) is performed in parallel Asynchronous execution – individual modules are run at different speeds and their execution is arbitrary intertwining (interleaving execution) ◦ In each clock tick, only one module is chosen arbitrary and it is executed ◦ Useful for description of communication protocols, asynchronous circuits and other systems that are not synchronized using a global clock ◦ If one wishes to execute a module in interleaved mode, one has to put the keyword process in front of the module name when declaring a module

19. Mutual exclusion (MUTEX) protocol If concurrent (parallel) processes share a given resource (a file on hard drive, a record in database, data in common memory) it can be shown that it is necessary to ensure that the processes can not access the resource simultaneously One has to define certain critical sections within each of the processes and ensure that only one process can be present in the critical section at a certain moment in time The problem lies in: finding the protocol with which one can establish when each of the processes can enter its own critical section

20. MUTEX protocol properties – IMPORTANT! Safety: ◦ Protocol ensures that only one process can be present in the critical section at a moment in time Liveness: ◦ Whenever a process wishes to enter the critical section, eventually (finally) the process will enter it Non-blocking: ◦ A process can always demand entrance to the critical section (other process must not hinder it) No strict sequencing: ◦ Processes can enter their critical sections in arbitrary sequence (there is no predetermined sequence for entering the critical section)

21. MUTEX protocol example in NuSMV (1/3) MODULE main VAR pr1: process proc(pr2.st, turn, FALSE); pr2: process proc(pr1.st, turn, TRUE); turn: boolean; ASSIGN init(turn) := FALSE;... MAIN modul Variable turn that determines which process may enter the critical section Two instances of module proc, which describes control aspects of concurrent processes

22. MUTEX protocol example in NuSMV (2/3)... MODULE proc(other-st, turn, myturn) VAR st: {n, t, c}; ASSIGN init(st) := n; next(st) := case (st = n) : {t,n}; (st = t) & (other-st = n) : c; (st = t) & (other-st = t) & (turn = myturn): c; (st = c) : {c,n}; TRUE : st; esac;... st – internal state of the process [n]on-critical – process is not in critical section [t]rying – process tries to enter critical section [c]ritical – process is in critical section If a process is in non-critical section, it may stay in it or go into state t (trying – in which it wants to enter critical section) If a process is in state t, and the other process is in non-critical section, then the first process may enter the critical section (by going into state c) If process is in state t, and the other process is also in that state, then the first process may enter its critical section (by going into state c) only if it is its turn (turn=myturn) If process is in state c (critical section), then it can stay in that state or leave critical section (by going into state n).

23. MUTEX protocol example in NuSMV (3/3)... next(turn) := case turn = myturn & st = c : !turn; TRUE : turn; esac; JUSTICE running JUSTICE !(st = c) If a process is in critical section and the variable turn has shown that it is its turn for execution, then the value of the variable turn is negated and the right to enter the critical section is given to the other process. Variable turn determines which process will enter the critical section if in a single moment both process wish to enter (st=t).

24. Fairness in NuSMV Fairness is an important feature of NuSMV: ◦ search can be restricted to only those paths of execution where a CTL property is true infinitely often (but not always) Usually these paths of execution model a fair approach to a particular resource. The fairness constraint is composed of: ◦ Keyword JUSTICE (also: FAIRNESS ) ◦ CTL expression f While checking a property, NuSMV will ignore any path on which the expression f does not hold infinitely often. JUSTICE running – means that a process is to be run infinitely often

25. Fairness in the MUTEX example JUSTICE running ◦ If a module under consideration is declared using the keyword process, then in each execution moment, NuSMV will non-deterministically determine whether the process would be executed or not. In this case, only those execution paths in which the process will be selected infinitely often for execution will be considered. JUSTICE !(st = c) ◦ Only those paths in which the process is not endlessly stuck in the critical section are considered. Namely, in the model, it is possible (because of non-determinism) that a particular process stays in its critical section for as long as it wants. This is a trivial case for which the violation of the liveness property can happen.

26. FSM for the MUTEX example

27. Starting NuSMV systemStarting NuSMV system NuSMV can be started in two ways: common and interactive Common way: Checking all CTL properties at the same time, given in the input file, no possibility for adjustments Call syntax: > NuSMV Interactive (advanced) way: Enables verification algorithm parameter adjustments, model checking of finite automaton, simulation of transition through process states, checking one specification at a time... Call syntax: > NuSMV –int Loading model: > read_model –i In the homework, you will learn to use both ways, but only basic functionalities of the interactive way.

28. Example 1 ASSIGN init(a) := FALSE; init(b) := FALSE; next(a) := case (b = FALSE) : a; TRUE : !a; esac;... next(b) := case TRUE : !b; esac; For the given NuSMV model draw the Kripke structure and check the validity of the following CTL expressions: a) AG(AF(a & b)), b) EX(!a & !b)

29. Example 1 - solution a) AG(AF(a&b)) is true. In fact, there is only one way which forms a cycle, and one of the states on this cycle is a & b b) EX(!a&!b) is false, because EX({S 0 })={S 1 }, where !a & b is true in {S 1 } S0S0 S1S1 S2S2 S3S3

30. Example 2 For the given Kripke structure write down the complete NuSMV code. Using fairness properties ensure that the system is not endlessly found in state S 2 S0S0 S1S1 S3S3 S2S2 S 0 = {req=FALSE, stat=FALSE} S 1 = {req=FALSE, stat=TRUE} S 2 = {req=TRUE, stat=FALSE} S 3 = {req=TRUE, stat=TRUE}

31. Example 2 – solution (1/2) 1. define the module, variables and variable types MODULE main VAR req : boolean; stat : boolean; 2. determine the initial states ASSIGN init (req) := {FALSE,TRUE}; init (stat) := FALSE; S0S0 S1S1 S3S3 S2S2 S 0 = {req=FALSE, stat=FALSE} S 1 = {req=FALSE, stat=TRUE} S 2 = {req=TRUE, stat=FALSE} S 3 = {req=TRUE, stat=TRUE}

32. Example 2 – solution (2/2) 3. Determine for each state the transitions to the next state for each variable individually: next (req) := case (req=FALSE & stat=FALSE) : FALSE; (req=FALSE & stat=TRUE) : {FALSE,TRUE}; (req=TRUE & stat=FALSE) : FALSE; (req=TRUE & stat=TRUE) : FALSE; esac; next(stat) := case (req=FALSE & stat=FALSE) : TRUE; (req=FALSE & stat=TRUE) : {FALSE,TRUE}; (req=TRUE & stat=FALSE) : TRUE; (req=TRUE & stat=TRUE) : FALSE; esac; 4. In the end, write the requested fairness constraint: JUSTICE (req=TRUE & stat=FALSE)

33. About the first homework and the first short exam The first homework includes: ◦ Testing MUTEX properties on several different implementations using CTL specifications ◦ Testing the fairness of the same implementations ◦ Interactive use of NuSMV and model checking ◦ Several questions regarding the NuSMV system The exam includes: ◦ Several theoretical questions and tasks related to the NuSMV system ◦ Several practical questions regarding the 1. homework The instructions for the first homework are available from the course website (subfolder EN) Short exam of the first homework will take place on March 27, 2015 at 18:00 in room D1

34. From which materials to study? This presentation NuSMV user manual v2.5 (available at the course website) Consultations For any problems related to the NuSMV system and for consultations please send mail to: alan.jovic@fer.hr, room D340 alan.jovic@fer.hr