Model Checking
Ahmed Rezine
IDA, Linköpings Universitet
Höstermin 2016
Outline
Overview
Introducing model checking
Approaches and tools
Outline
Overview
Introducing model checking
Approaches and tools
Program verification
We often want to answer whether a program is correct or not (i.e.,
has some bad behaviors or not):
Correct Program
Incorrect Program
Model checking
I Model checking is (aims to be) a push button verification
I
approach
Given:
I a model M of the system to be verified, and
I a correctness property Φ to be checked: absence of deadlocks,
livelocks, starvation, under/over specification, violations of
constraints/assertions, etc
I The model checking tool returns:
I a counter example in case M does not model Φ, or
I a mathematical guaranty that M does model Φ
Used both for Verification and debugging
I Model checking tools are used both:
I To establish correctness of a model M with respect to a
correctness property Φ
I More importantly, to find bugs and errors in M
In this lecture
We will briefly:
I Introduce model checking, models and properties
I Give examples of tools and what they are used for
Outline
Overview
Introducing model checking
Approaches and tools
Model Checking
Model Checking in Practice
Traditional model checkers:
More recent model checkers:
M as a Kripke structure
Assume a set of atomic propositions AP. A Kripke structure M is a
tuple (S ; S0 ; R ; L) where:
1. S is a finite set of states
S is the set of initial states
R S S is the transition relation s.t. for any s 2 S, R(s s 0 )
holds for some s 0 2 S
L : S ! 2AP labels each state with the atomic propositions
2. S0
3.
4.
;
that hold on it.
Programs as Kripke structures
1
int x = 0;
2
3
4
5
6
void thread (){
int v = x ;
x = v + 1;
}
7
8
9
10
11
12
13
14
void main (){
fork ( thread );
int u = x ;
x = u + 1;
join ( thread );
assert ( x == 2);
}
Synchronous circuits as Kripke structures
v00
=
v10
=
v20
=
:v0
v0 v1
(v0 ^ v1 ) v2
(1)
(2)
(3)
Synchronous circuits as Kripke structures
v00
=
v10
=
v20
=
:v0
v0 v1
(v0 ^ v1 ) v2
(1)
(2)
(3)
Asynchronous circuits handled using a disjunctive R instead of a
conjunctive one like for synchronous circuits.
Temporal Logics
I Temporal logics are formalisms to describe sequences of
transitions
I Time is not mentioned explicitly (but for some other logics ...)
I Instead, temporal operators are used to express that certain
states are:
I never reached
I eventually reached
I more complex combinations of those
Linear Temporal Logic (LTL)
Consider all “runs” (capturing “executions” of the program) of the
Kripke structure.
I (ab) ! (c) ! (c) ! (c) ! : : :
I (ab) ! (bc) ! (c) ! (c) ! : : :
I (ab) ! (bc) ! (ab) ! (bc) ! : : :
I AP g eventually holds: F(g )
I AP g globbaly appear: G(g )
I AP g holds in the next state: X(g )
I Combinations: GF(g ), FG(g ),
G(g
) F(q)), GF(g ) ) GF(q) . . .
Computation Tree Logic (CTL)
Computation trees are obtained by unwinding the Kripke structure
Computation Tree Logic (CTL)
M ; s0 j= EF g
M ; s0 j= AF g
M ; s0 j= EG g
M ; s0 j= AG g
Computation Tree Logic (CTL)
Computation trees are obtained by unwinding the Kripke structure
I can express reset: AGEFg
I but not stability: FGg
Outline
Overview
Introducing model checking
Approaches and tools
Explicit model checking: SPIN
http://spinroot.com/spin/whatispin.html
I a model checker for tracing logical errors in designs of
I
distributed and concurrent systems:
I data communication protocols,
I switching systems,
I concurrent algorithms,
I railway signaling protocols,
I control software for spacecrafts, nuclear power plants etc.
concurrent systems are described in the Promela modelling
language. Given a model, SPIN reports on:
I deadlocks,
I starvation
I race conditions,
I unwarranted assumptions about the the speed of the processes
Promela:Protocol, Process Meta Language
I dynamic creation of concurrent processes
I processes communicate by message passing in:
I synchronous channels (rendez vous)
I asynchronous (using buffers)
I resembles C, models finite-state systems
SPIN descriptions
I
I
I
I
I
embedded C can be used as part of model specifications
SPIN works on the fly, allowing to handle larger systems
Correctness properties can be expressed in LTL
SPIN supports random, interactive and guided simulation
verification can be exhaustive or partial, it can use depth-first,
breadth-first and bounded context-switching
Symbolic model checking
http://nusmv.fbk.eu
I Represent values symbolically (using predicates) instead of
explicitely
I Use SAT solvers to check satisfiability of large boolean
formulas
I Use Binary Decision Diagrams (BDDs) to efficiently represent
such formulas
Symbolic model checking: BDDs Canonicity
Symbolic model checking: NuSMV
I
I
I
I
I
NuSMV is an open source symbolic model checker
It uses both BDD and SAT representations
Performs CTL and LTL model checking
Can capture (A)Synchronous finite models
allows for interactive and random simulation
Timed System: UPPAAL
http://www.uppaal.org/
I
I
I
I
The Kripke structures we looked at were finite
Many systems exhibit an infinite state space
One way is to abstract into a finite state system
Analyse the abstract system to deduce properties of the
original
Timed Systems
I Continous time is one source of infinity
I Discretizing it does not capture all possible behaviours
I Several models were proposed, timed automata by Alur,
Courcoubetis and Dill are the most adopted ones.
Timed Systems
Timed Systems: UPPAAL
Counter Example Guided Abstraction Refinement: Satabs
http://www.cprover.org/satabs/
I Remove irrelevant details using abstraction
I Automatically generate small enough models for model
checking
I Use as few predicates as possible to symbollically represent
many states
Counter Example Guided Abstraction Refinement: Satabs
1. Given a C program
2. Compute an abstraction
3. Model Check the abstraction,
I If no error, return program correct
4. Check feasibility of the run
I If feasible, return the witness run
5. Refine predicates, goto 2