1. 1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level modules are instantiated (call by reference like) Download from NuSMV homepage: http://nusmv.fbk.eu/

2. 2 MODULE main -- ontology VAR req1 : boolean; req2 : boolean; ack1 : boolean; ack2 : boolean; -- program ASSIGN ack1 := req1; ASSIGN ack2 := req2 & !req1; -- properties LTLSPEC NAME mutex : = G!(ack1 & ack2); LTLSPEC NAME serve1 := G(req1 -> F(ack1)); LTLSPEC NAME respond1 := ack1 -> req1; LTLSPEC NAME respond2 := ack2 -> req2; NuSMV Specification Example

3. 3 VAR : ;… FROZENVAR : ;… -- can be only initialized but used as desired CONSTANT ;… DEFINE := ;… -- macros Types: Boolean: GateOpen : boolean; Enumeration: Light : {red, yellow, green}; Integer: X: integer Subrange: count : 0..7; Arrays: : array.. of ; ready_table : array 1..8 of boolean; matrix : array 0..1 of array 0..2 of boolean; Variables Declaration

4. 4 INIT x := constant;…. ASSIGN ;… where x := exp ; init(x) := constant; next(x) := exp; Single assignment rule:  either x := exp; every step  or initially init(x):=const and then every step next(x):=exp, but not both !!!! Program alternative The program is executed iteratively – fixed period tick (each iteration is a synchronous step). Program considered a system of simultaneous equations, with where the unknowns are the declared variables. At each iteration we need that a solution exists, hence rules for assignments are:  single assignment – at each step, each variable may be assigned only once.  no circular dependency - a program may not have ``cycles'‘ in its dependency graph that are not broken by delays.

5. 5 var_id | TRUE | FALSE | ! exp | exp rel exp -- rel  {&, |, xor, ->,, =, !=,, =} | - exp | exp op exp -- op  {+, -, *, /, mod} | set-exp | set-exp union set-exp | set-exp in set-exp | cond ? exp1 : exp2 -- if-then-else expression | case (exp: exp;)+ esac -- case expression req2 & ~req1, x + y, c ? y : 0 case state=ready & request : busy; state=busy & ack : ready; TRUE : {ready,busy}; esac; Expressions set-exp – {enumeration | subrange}

6. 6 x := y + z;  x depends on y and z. x := exp ;  ``zero delay dependencies'' next(x) := exp;  ``unit delay dependencies''. Combinational loop - cycle of dependencies whose total delay is zero (unbroken by delays). x := y; y := x; No fixed order of computation: x depends on y, and vice versa. Combinational loops are illegal in NuSMV. Circular Dependency rule (I)

7. 7 Combinational loops are defined only in terms of syntactic dependencies !!! Hence, x := c ? y : 0; y := !c ? x : 1; has a solution, If c is false, first evaluate x, x = 0, then y, y = 0. If c is true, first evaluate y, y = 1, then x, x = 1. Also, x := c ? y : 0; has a solution if c and d are not True y := d ? x : 1; simultaneously However, still combinational loops therefore are also illegal. Circular Dependency rule (II)

8. 8 MODULE main VAR start : boolean; done : boolean; state : {idle, cyc1, cyc2}; ASSIGN init(state):= idle; next(state) := case state=idle : start ? cyc1 : idle; state=cyc1 : cyc2; state=cyc2 : idle; esac; done := (state = cyc2); Example: State Machine (I)

9. 9 TRANS next_expr -- a set of current state/next state pairs defined by the Boolean expression ‘next_expr’ (not part of ASSIGN section). MODULE main VAR start : boolean; done : boolean; state : {idle,cyc1,cyc2}; INIT state=idle; TRANS case state=idle & start : next(state) = cyc1; state=idle & !start : next(state) = cyc1; state=cyc1 : next(state) = cyc2; state=cyc2 : next(state) = idle; esac ASSIGN done := (state = cyc2); State Machine : TRANS Assignments

10. 10 MODULE main VAR c: integer ASSIGN init(c) := 0; next(c) := c + 1; INVAR c < 100; LTLSPEC F (c = 100) INVAR - Program Constraints INVAR state-exp – constraints program actions not to falsify state-exp May lead to deadlock if no alternatives are specified

11. 11 Let, p: Boolean, v:{d 1,..,d n }, f, g: LTL formulae p, v~d i -- ~  { =, !=,, = } !f, f & g, f | g, f xor g, f -> g, f g X f  O f G f  f F f   f f U g -- as usual Y f   f f S g -- as usual LTL Expressions

12. 12 LTLSPEC ltl_exp ; LTLSPEC NAME name := ltl_exp ; Property Declaration MODULE main -- ontology VAR req : boolean; ack : boolean; busy : boolean; -- program ASSIGN ack := req; busy := ack; -- properties LTLSPEC NAME serve := G(req -> F(ack)); LTLSPEC NAME respond := G(req -> (busy)U(ack));

13. 13 INVARSPEC exp  LTLSPEC G(exp); JUSTICE f :Exp; -- Assumption!!! -- assumed to be true infinitely often in all the fair paths.  LTLSPEC GF( f ); COMPASSION (f :Exp, g :Exp ) [;] -- Assumption!!! -- if f is true i.o. then g has to be true i.o.  LTLSPEC GF( f ) -> GF( g ); Additional Properties’ Specifications

14. 14 NuSMV does not provide for Assumption-Requirement classification unless a property has the form of JUSTICE or COMPASSION Hence, properties must take the form (proof-rule): LTLSPEC (A1 & A2 &…&An) -> R where A1,A2,..,An, are LTL properties that express assumptions and R expresses a requirement. Any of the assertions A1,A2,..,An may be a requirement in which case take care to formulate a corresponding proof rule and verify.  Similarly, definition of an abstract variable, say R:  Declare the variable R of type Boolean.  Don't use R in the program.  Define an assumption A= G(R ltl_exp) -- used as above In Practice,….

15. 15 Running NuSMV Interactively Activation: directly enters: NuSMV > NuSMV > read model [-i model-file] -- reads a NuSMV file into NuSMV. NuSMV > go [-f] -- Initializes the system for verification. -f :: forces the model construction even when COI is enable NuSMV > check_fsm Checks if the transition relation is total. If the transition relation is not total then a potential deadlock state is shown. NuSMV > process_model [-f] [-i model-file] Reads the model, compiles it into BDD and performs the model checking of all the specification contained in it. Also, the set of reachable states is computed. -f :: forces the model construction even when COI is enabled. -i model-file :: reads the model from file model-file. NuSMV> reset -- removes current model & properties DB NuSMV> quit -- exits NuSMV For all commands the option [-h ] prints out the command usage

16. 16 NuSMV Lights Example A lights signal controls cars traffic by Green (pass) and Red (stop) lights. The signal is also equipped with button available to pedestrians. Initially, the signal should show Green. Whenever, the pedestrians button is pushed the signal shall turn to show Red for 3 seconds. If the button has been pushed again while the lights show Red then the system shall restart counting the 3 seconds ‘red’ period.

17. 17 NuSMV Lights Model MODULE main VAR P_req : boolean; Lights_cmd : {Green, Red }; Red_count : 0..3; ASSIGN init(Red_count) := 0; init(Lights_cmd) := Green; TRANS (Lights_cmd=Green & P_req) -> (next(Lights_cmd)=Red & next(Red_count)=1); TRANS (Lights_cmd=Green & !P_req) -> (next(Lights_cmd)=Green & next(Red_count)=Red_count); TRANS (Lights_cmd=Red & P_req) -> (next(Red_count)=1 & next(Lights_cmd)=Red); TRANS (Lights_cmd=Red & !P_req) -> Red_count=3? (next(Lights_cmd)=Green & next(Red_count)=0) :(next(Red_count)=Red_count+1 & next(Lights_cmd)=Red); -- Requirements LTLSPEC NAME Red_Duration := G (P_req -> (X(Lights_cmd=Red) & X(X(Lights_cmd=Red))& X(X(X(Lights_cmd=Red))))); LTLSPEC NAME Finally_Green := G F (Lights_cmd=Green);

18. 18 Simple Lights Verification

19. 19 Running NuSMV Interactively (II) NuSMV >check _ltlspec [-n #num | -P "name" ] Performs fair LTL model checking. -n #num :: Checks the LTL property with index number #num. -P "name" :: checks the LTL property “name”. NuSMV >show_property [ -P "name"] [-f | -t | -u] Shows the properties currently stored in the list of properties. Displays: (identifier, name, formula, type, status, counter-example). -P "name" :: prints out the property named ”name” -u/ -t/ -f :: prints only unchecked/ found to be true/ found to be false

20. 20 Model Simulation NuSMV>pick state [-v] [-r | -i [-a]] Picks a state from the set of initial states, and makes it the current state. -v :: prints out chosen state -r/-i :: randomly/interactively (-a displays all state and frozen variables; otherwise only changed). NuSMV>simulate [-p | -v] [-r | -i [-a]] [-k steps] Generates a sequence of at most steps states, starting from the current state. The current state must be set via the pick_state or goto state commands. -p :: prints current generated trace (only changed variables). -v :: prints generated trace (changed + unchanged variables). -r :: picks a state from a set of possible future states, randomly. -i :: user interactively chooses the states, step by step ; -k steps :: maximum length of the simulation path.

21. 21 Simple Lights Simulation

22. 22 NuSMV Lights Example – Adding Assumption -- Assumption --**** LTLSPEC G (F !(P_req | X(P_req) | X(X(P_req)))); -- Requirements LTLSPEC NAME Red_Duration := G (P_req -> (X(Lights_cmd=Red) & X(X(Lights_cmd=Red))& X(X(X(Lights_cmd=Red))))); LTLSPEC NAME Finally_Green := G ( P_req -> F !(P_req | X(P_req) | X(X(P_req)) ) ) -> G F (Lights_cmd=Green);

23. 23 NuSMV Lights Example – Adding Abstract Variable -- Specification -- Assumption --** abstract variable definition --**** LTLSPEC G(IsRed ( Y(P_req) | (Y(IsRed)&(Red_count>0 ) ) ) ); --**** LTLSPEC G (F !(P_req | X(P_req) | X(X(P_req)) ) ); -- Requirements LTLSPEC NAME Red_Duration := G (P_req -> (X(Lights_cmd=Red) & X(X(Lights_cmd=Red))& X(X(X(Lights_cmd=Red))))); LTLSPEC NAME Finally_Green := G ( F !(P_req | X(P_req) | X(X(P_req)) ) ) -> G F (Lights_cmd=Green); LTLSPEC NAME LightRed := G(IsRed (Y(P_req) | (Y(IsRed)&(Red_count>0)))) -> G(IsRed ->(Lights_cmd=Red));

24. 24 Satisfiability - Tautology Checker MODULE main VAR a: boolean; b: boolean; c: boolean; LTLSPEC G(((a & b) -> c) (a -> (b -> c))) --A propositional tautologies formula to be checked