Transcript FMuOS: Formal verification of critical program parts NuSMV system Prepared by: Alan Jović, Ph.D. Acad.

FMuOS: Formal verification of
critical program parts
NuSMV system
Prepared by: Alan Jović, Ph.D.
Acad. year: 2014/2015
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.
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

NuSMV system
Language for model
description
Property specification
in CTL or LTL
Algorithm for model
checking
EXIT
Introduction
System input:
◦ Textual description of programs in NuSMV language – system model
◦ Specification of properties in CTL or LTL logics (also in RTCTL (RealTime 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)

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
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)
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
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

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 ")"
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};

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
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
CTLSPEC
CTLSPEC
CTLSPEC
AG AF state=start
EF n>=40
E [ b=TRUE U state=busy ]
AG (state=request -> AF state=busy)
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
Initial
and
next
values
of request
variable
arepossible
not determined
in the
System
state
S is
generally
defined–based
on
all
variable
values:
Variable
status
is
partially
specified:
initially
ittohas
the
FSM
is
comprised
of four
states
each
state
corresponds
possible
•request
- variable
ofbecomes
type
boolean,
or
FALSEis TRUE.
program.
In
this
way,
the
of
environment
is modeled
value
ofof
ready,
and
busy
if the
request
Otherwise, if
values
System
variables:
two
binary
v1
:(boolean)
T1; influence
v2
: T2;
variables
...TRUE
vn
: Tn;
(NuSMV
assign
to ready
that variable).
•status
-system
is
variable
become
or busy
request
isenumerated
FALSE,
is values
not
determined.
System state
S: can
T1 ×then
T2
×the
. .arbitrary
.value
×that
Tn can

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
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
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;
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

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
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

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)
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

MUTEX protocol example in
NuSMV (2/3)
...
MODULE proc(other-st, turn, myturn)
VAR
st process
a– process
internal
is is
state
in in
state
non-critical
state
of the
t, (critical
c
t,
and
process
and
the
section,
the
section),
other
other
process
it process
may
thenstay
itis is
st: {n, t, c}; If
in [n]on-critical
also
can
it or
non-critical
stay
in go
that
ininto
that
state,
section
state
then
t (trying
or
, the
then
leave
the
– in
critical
process
first
which
process
section
itmay
wants
(by
–state
process
isfirst
not
in
critical
section
ASSIGN
to enter
may
enter
going
enter
its
into
critical
critical
state
the critical
section)
section
n). section
(by going
(by going
into state
into c)
state
init(st) := n; [t]rying – process tries to enter critical section
c)
only
if it is
its turn (turn=myturn)
[c]ritical
–
process
is in critical section
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;
...
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).

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

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.
FSM for the MUTEX example
•Starting 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 1
•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)
ASSIGN
init(a) := FALSE;
init(b) := FALSE;
next(a) :=
case
(b = FALSE) : a;
TRUE : !a;
esac;
...
...
next(b) :=
case
TRUE : !b;
esac;
Example 1 - solution
S0
S1
ab
ab
S2
ab
ab
S3
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}

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 S2
S0
S1
S0 = {req=FALSE, stat=FALSE}
S1 = {req=FALSE, stat=TRUE}
S2 = {req=TRUE, stat=FALSE}
S3 = {req=TRUE, stat=TRUE}
S3
S2
Example 2 – solution (1/2)
1. define the module, variables and
variable types
S0
S1
S3
S2
MODULE main
VAR
req : boolean;
stat : boolean;
S0 = {req=FALSE, stat=FALSE}
2. determine the initial states
S1 = {req=FALSE, stat=TRUE}
ASSIGN
S2 = {req=TRUE, stat=FALSE}
init (req) := {FALSE,TRUE};
S3 = {req=TRUE, stat=TRUE}
init (stat) := FALSE;
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 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

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:
[email protected] , room D340