Introduction to

Model Checking
Debdeep Mukhopadhyay
IIT Madras

How good can you fight bugs?

Comprising of three parts

Formal Verification techniques consist of

three parts:
1. A framework for modeling systems
some kind of specification language

2. A specification language
for describing the properties to be verified

3. A verification method
for establishing if the description of the
system satisfies the specification

Proof-based verification
The system description is a set of formula
in a suitable logic
The specification is another formula
The verification method is finding a proof
that
means deduction

It typically needs the user guidance and

expertise

Model-based verification
The system is represented by a model M
for an appropriate logic
The specification is again represented by
a formula
The verification method consist of
computing whether a model M satisfies
M satisfies : M

The computation is usually automatic for

finite models

Degree of automation
From fully automated to fully manual

Full- vs. property-verification

The specification may describe a single
property of the system, or it may describe
its full behavior (expensive).

Intended domain of application

Hardware, software
Sequential, concurrent
Reactive , terminating
Reactive: reacts to its environment, and is not
meant to terminate (e.g. operating systems,
embedded systems, computer hardware)

Pre- vs. post-development

Verification is of greater advantage if
introduced early in system development

Model checking
Model checking is an automatic, modelbased, property-verification approach
It is intended to be used for concurrent
and reactive systems
The purpose of a reactive system is not
necessarily to obtain a final result, but to
maintain some interaction with its
environment

Temporal Logic (cont.)

In model checking:
The models M are transition systems
The properties are formulas in temporal
logic

Model checking steps:

1. Model the system using the description
language of a model checker : M
2. Code the property using the specification
language of the model checker :
3. Run the model checker with the inputs M
and

Model checker based on

satisfaction
p F q

yes

Model
Checker

no

Error Trace

Linear vs. Branching

Linear-time logics think of time as a set of paths
path is a sequence of time instances
Branching time logics represent time as a tree
it is rooted at the present moment and branches out
into the future
Many logics were suggested during last years that fit into
one of above categories
We study LTL in linear time logics and CTL in branching
time logics

Linear vs. Branching (cont.)

Linear Time
Every moment has a
unique successor
Infinite sequences
(words)
Linear Time Temporal
Logic (LTL)

Branching Time
Every moment has
several successors
Infinite tree
Computation Tree
Logic (CTL)

Propositional Linear Temporal

Logic
Express properties of Reactive Systems
interactive, nonterminating

For PLTL, a model is an infinite state

sequence
= s0 , s1 , s2

Temporal operators
Globally:
p p

G p at t iff p for all t t.

p p

p p p p p p p...
G p...

Temporal operators...

Future:
p p
F p...

Until:

F p at t iff p for some t t.

p p

p p

p U q at t iff

q for some t t and

p in the range [ t, t )
p p

p p

p p p p p q
p U q...

Next-time:

X p at t iff p at t+1

Examples
Liveness: if input, then eventually output
G (input F output)
atomic props

Strong fairness: infinitely send implies

infinitely recv.
GF send GF recv
infinitely often

Recap: What is a model?

Atoms: Atomic formulas (such as p. q, r,
).
These atoms stand for atomic facts which
may be true for a system.
e,g
Printer crypto-6 is working
Process encipher is suspended
Content of the register key is the integer
value 6

Model
A Model is a transition system.
A transition system M=(S,,L) is a set of
states S endowed with a transition relation
(a binary relation on S), such that every
state s from S, has some successor state
s which is also from S. Thus ss
Also associated with each state is a set of
atomic propositions which are true at that
state, described by a labeling function, L

Example
S = {s0, s1, s2}
s0

transitions = s0 s1 ,
s1 s1 , s2 s1 , s2
s0 , s0 s2

p,q

q
s1

q,r
s2

L(s0) = {p,q}
L(s1) = {q}
L(s2) = {q,r}

Example
N1,N2
turn=0

PATH

T1,N2
turn=1
C1,N2
turn=1

N1,T2
turn=2
T1,T2
turn=1

T1,T2
turn=2

C1,T2
turn=1

N = noncritical, T = trying, C = critical

N1,C2
turn=2
T1,C2
turn=2

Propositional temporal logic

In Negation Normal Form
AP a set of atomic propositions
Temporal operators:
Gp
Fp
Xp
pUq
Path quantifiers: A for all path
E there exists a path

Not Until (pUq)

Whenever q occurs there must be a nonoccurrence of p before.
p p

p p

p p p p p q
p U q...

p p

p p

p p p p p q
(p U q)

Explanation
p q := i[( |= q ) (j < i, |= p )]
i

( p q ) := i[( |= q ) (j < i, |= p )]
i

:=i[( i |= q ) (j < i, j |= p)]

Some Finer Points on p U q

Until demands that q does hold in some future
state i,e Fq
It does not say anything about what happens
after q occurs
contrary to English Language: I smoked until 22
Means p=I smoke was true till q=I am 22 became
true.
Also after q=I am 22, p=I smoke does not occur
In LTL, means p U (Gp q)

Two more terms

Weak Until (pWq): Like pUq except q
need not occur.
Release (pRq): p is released by q. It
means that q occurs entirely or it occurs till
p occurs. Note than unlike until q occurs
also at the time instant when p is asserted.

Operator precedence
Unary operators including negation have strongest
precedence
p U q is parsed as (p) U q rather than (p U q)
Temporal binary operators have stronger precedence
than non-temporal binary operators
p q U r is parsed as: p (q U r)
The precedence over propositional logic is as usual
First do the AND
then the ORs and XORs
finally the IMPLIES and EQUIVALENCEs.

Example
The parse tree of Fp Gq p W r
according to precedence rules

More of Until
What is not pUq?
We have seen that.
Here is another expression for that.

( p q ) = q (p q ) Gq

Intuitive Explanation
( p q ) = (q (p q )) Fq

Fq is straight-forward
Let q occur => Fq
t1

t2

q=1

p=0

t3
q=1

q=0
Let t3 be the first time interval when q is true.
Let us contradict the equation, that is pUq does not hold.
Then, there is a time instant t=t2, when p=0. Obviously q=0, as t2<t3
But by RHS, if

(q (p q ))

then at time t=t1, q=0 => q=1

But, t1<t3 and hence we have a violation that t3 is the first time when q=1.
Thus, there is a contradiction and pUq does hold. The equivalence follows.

Release
Release R is dual of U; that is:
p R q ( p U q)
p must remain true up to and including the
moment when q becomes true (if there is
one); p releases q
Thus, pRq= Gq V [q U (p q)]
= [F q (q U (p q)]
=[p U q]

Weak Until
W : Weak Until is related to the Until
with the difference that it does not require
that is eventually hold
Essentially W is a short form for
writing
U G

LTL satisfaction by a system

Suppose M = ( S, , L) is a model, s S,
and an LTL formula
We write M, s if for every execution
path of M starting at s, we have
Sometimes M, s is abbreviated as s

Example
1. M, s0 X q

s0
p,q
s1

s2
q,r

3. M, s1 G q

q
s0

s2
q,r

p,q

s1

s1

s2
q,r

4. M, s0 p U q

s1

p,q
s0

s2
q,r

2. M, s0 G (p r)

Practical patterns of specifications

It is impossible to get to a state where
started holds, but ready does not hold
G (started ready)

For any state, if a request occurs, then it

will eventually be acknowledged
G (requested F acknowledged)

Whatever happens, a certain process will

eventually be permanently deadlocked
F G deadlock

Some practical patterns (cont.)

A certain process is enabled infinitely often
on every computation path
G F enabled
In other words, in a path of the system there must
never be a point at which the condition enabled
becomes false and stays false forever

If a process is enabled infinitely often, then it

runs infinitely often
G F enabled G F running

Practical patterns(contd.)
An upwards travelling lift at the 2nd floor
does not change its direction when it has
passengers wishing to go to the 5th floor:
G(floor2 directionup ButtonPressed5
(directionup U floor5)

LTL weakness
The features which assert the existence of a
path are not (directly) expressible in LTL
This problem can be solved by: checking
whether all paths satisfy the negation of the
required property
A positive answer to this is a negative answer to
our original question and vice versa.
But properties which mix universal and
existential path quantifiers cannot in general be
expressed in LTL

LTL Weakness: Examples

LTL cannot express these features:
From any state it is possible to get to a restart state
(i.e., there is a path from all states to a state satisfying
restart)
The lift can remain idle on the third floor with its door
closed (i.e., from all states if there is path to a state in
which it is on the third floor, there is a path along
which it stays there)
LTL cannot assert these because existential and
universal logics are mixed.
However, CTL can express these properties

Model checking example:

Mutual exclusion
The mutual exclusion problem (mutex)
Avoiding the simultaneous access to some
kind of resources by the critical sections of
concurrent processes

The problem is to find a protocol for

determining which process is allowed to
enter its critical section

Expected Properties
Safety: Only one process is in its critical section
at any time.
Liveness: Whenever any process requests to
enter its critical section, it will eventually be
permitted to do so.
Non-blocking: A process can always request to
enter its critical section.
No strict sequencing: Processes need not
enter their critical section in strict sequence.

Modeling mutex
Consider each process to be either:
in its non-critical state n
trying to enter the critical section t
or in critical section c

Each individual process has this cycle:

ntcntcn

The processes phases are interleaved

2 process mutex
The processes are asynchronous interleaved
one of the processes makes a transition while the
other remains in its current state
s0

n1 n2
t1 n2

s5

s1

n1 t2

s3
s2

t1 t2

c1 n2

s4

c1 t2

n1 c2

t1 c2

s7

s6

Checking the properties

Safety: G (c1 c2)
This formula is satisfied in all states

Liveness: G (t1 F c1)

This formula is not satisfied in the initial state!
s0 s1 s3 s7 s1 s3 s7

Checking the properties

Non-blocking:
Consider process 1.
We wish to check the following property:
for every states satisfying n1 there exists a state
which satisfies t1

This property cannot be expressed in LTL

Checking the properties

No strict sequencing:
Processes should not enter their critical
section in a strict sequence.
There should be at least one path where strict
sequencing does not hold
But LTL cannot express the logic there exists.
Instead not of there exists is for all.
Thus we can say that the following property s:
in all paths there is a strict sequencing

If the answer is no there is no strict sequence.

No Strict Sequencing
c1 and c2 need not alternate
Desired scenario:
Process 1 acquires critical section (c1)
Process 1 releases the critical section (c1)
Process 2 does not enter the critical section
(c2)
Process 1 regains access to the critical
section (c1)

No Strict Sequencing
There exists at least one path with no strict sequencing:
c1

c1

c1

c1
c2

c2 c2

c1

Time
Or, in all paths there is strict sequencing:
Anytime we have
c1 state, the condn
persists, or it ends
with a non-c1 state
and in that case there
is no further c1
unless and until
we obtain a c2 state.

G[c1 c1W (c1 c1Wc2 )]

c1
c1

c1

c1

c1

c1 c1

c1
Time

c1 c1

c2

Evaluation of the Protocol

Safety property is satisfied.
c1 and c2 do not become
one at the same time in any
state.

Live-ness property is
violated. Follow the path
marked in red. Processor 1
tries to enter the critical
section but fails.

s0
n1 n2
t1 n2

s5

s1

n1 t2

s3
s2

t1 t2

c1 n2

s4

c1 t2

n1 c2

t1 c2

s7

s6

Evaluation of the Protocol

Non-blocking: Observe all
states where n1 is high.
All of them should
have at least one path where
t1 is high in the next clock
cycle.

t1 n2

The property thus have to

look for both for all and there
exists logic and thus cannot
be expressed in LTL.

s0
n1 n2

s5

s1

n1 t2

s3
s2

t1 t2

c1 n2

s4

c1 t2

n1 c2

t1 c2

s7

s6

No-strict sequencing
Path marked in red
shows that all paths are
sequencing is false.
Thus, no strict sequencing
is maintained.

Note that since we are

using LTL, we have negated
the property: there exists a
path with no strict sequencing

s0
n1 n2

t1 n2

s5

s1

n1 t2

s3
s2

t1 t2

c1 n2

s4

c1 t2

n1 c2

t1 c2

s7

s6

Solution
s0
n1 n2
t1 n2

s2

c1 n2

s4
All the four
properties
are
satisfied

c1 t2

s5

s1
s3

s3

t1 t2

t1 t2

n1 t2

n1 c2

t1 c2

s7

s3 and s3 now expresses which process was

requesting for the critical section early.
Thus the live-ness problem is solved.

s6

The SMV model checker

New Symbolic Model Verifier
Provides a language for describing the
models.
The properties are written as LTL (or CTL)
formulas.
It produces an output whether the
specifications hold true, or a trace to
show why the specification is false.