FMuOS: Formal FMuOS: Formal verification of critical verification of critical program partsprogram parts

NuSMV system

Prepared by: Alan Jović, Ph.D.Acad. year: 2014/2015

IntroductionIntroduction

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.

IntroductionIntroduction 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

IntroductionIntroduction

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)

NuNuSMVSMV input language 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

NuNuSMV SMV programsprogramsNuSMV 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)

VariableVariabless (1/2)(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

VariableVariabless (2/2)(2/2)

Some examples of declarations:VARa : 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

Assignments (1/2)Assignments (1/2)

Assignments provide variables with◦ Initial value – init◦ Next value (based on momentary values of

program variable values) - nextAssigning values to variables:

decl :: "ASSIGN"dest1 ":=" expr1 ";"dest2 ":=" expr2 ";"

...dest :: atom| "init" "(" atom ")"| "next" "(" atom ")"

AssignmentsAssignments (2/2)(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 valuesIn 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:ASSIGNa := n mod 2;init(switch) := off;next(state) := {busy, stop};

Property specificationProperty specification (1/2)(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

Property specification Property specification (2/2)(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=startCTLSPEC EF n>=40CTLSPEC E [ b=TRUE U state=busy ]CTLSPEC AG (state=request -> AF state=busy)

SMV primjer 1.SMV primjer 1.MODULE mainVAR

request : boolean;status : {ready,busy};

ASSIGNinit(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) variablesSystem 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

Non-deterministic valuesNon-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

ModulModuleses inin NuNuSMVSMV

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

NuNuSMV SMV exampleexample: : TThree-bithree-bit countercounter

MODULE mainVAR

bit0 : counter_cell(TRUE);bit1 : counter_cell(bit0.carry_out);bit2 : counter_cell(bit1.carry_out);

CTLSPECAG AF bit2.carry_out

MODULE counter_cell(carry_in)VAR

value : boolean;ASSIGN

init(value) := FALSE;next(value) := value xor carry_in;

DEFINEcarry_out := value & carry_in;

NuNuSMV SMV exampleexample:: Three-bit counterThree-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

SSynchronousynchronous andand asasynchronous execution in ynchronous execution in NuNuSMVSMVSynchronous 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

MMutual exclusion (MUTEX) utual exclusion (MUTEX) protocolprotocol

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

MUTEX protoMUTEX protocol properties – col properties – IMPORTANT!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)

MUTEX protoMUTEX protocol example incol example in NuNuSMVSMV (1/3) (1/3)

MODULE mainVARpr1: process proc(pr2.st, turn, FALSE);pr2: process proc(pr1.st, turn, TRUE);turn: boolean;

ASSIGNinit(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

MUTEX protoMUTEX protocol example incol example in NuNuSMVSMV (2/3) (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).

MUTEX protoMUTEX protocol example incol example in NuNuSMVSMV (3/3) (3/3)...next(turn) :=case

turn = myturn & st = c : !turn;TRUE : turn;

esac;JUSTICE runningJUSTICE !(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).

FFairnessairness in in NuNuSMVSMVFairness 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

Fairness in theFairness in the MUTEX MUTEX exampleexample

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.

FSM FSM for thefor the MUTEX MUTEX exampleexample

•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 <path_to_file.smv>• 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 <path_to_file.smv>• In the homework, you will learn to use both ways, but only basic

functionalities of the interactive way.

Example 1Example 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)

Example 1 - solutionExample 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({S0})={S1}, where !a & b is true in {S1}

ab

ba

ba

ba

S0 S1

S2 S3

Example 2Example 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 S2

S0 S1

S3 S2

S0 = {req=FALSE, stat=FALSE}

S1 = {req=FALSE, stat=TRUE}

S2 = {req=TRUE, stat=FALSE}

S3 = {req=TRUE, stat=TRUE}

Example 2 – solution (1/2)Example 2 – solution (1/2)1. define the module, variables

and variable types

MODULE main

VAR

req : boolean;

stat : boolean;

2. determine the initial statesASSIGN

init (req) := {FALSE,TRUE};

init (stat) := FALSE;

S0 S1

S3 S2

S0 = {req=FALSE, stat=FALSE}

S1 = {req=FALSE, stat=TRUE}

S2 = {req=TRUE, stat=FALSE}

S3 = {req=TRUE, stat=TRUE}

Example 2 – solution (2/2)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)

About the first homework About the first homework and the first short examand 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.

homeworkThe 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

From which materials to From which materials to study?study?This presentationNuSMV 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