COMP6004 Formal Design of Systems

Corina Cîrstea
Outline

Administrative Info

Introduction to Model Checking

Modelling with Kripke Structures

Administrative Info

I Module team:
I Robert Walters (rjw1@ecs.soton.ac.uk)
I Corina Cîrstea (cc2@ecs.soton.ac.uk)

I Timetable:
I Lectures: Mondays (16:00-17:00, 58/1009)
Tuesdays (15:00-16:00)
I Tutorial: Tursdays (9:00-10:00)

Note: This week, only the Monday and Thursday slots will be
used (both for lectures).
Plan of Lectures

I ≈ 4 weeks on Theory of model checking

I models
I temporal logics (LTL, CTL)
I algorithms

I ≈ 4 weeks on Promela and the SPIN model checker

I coursework: use of SPIN

I ≈ 3 weeks on other formal verification technologies

Course Materials

I slides (mostly self-contained)

I weakly tutorial exercises on both theory and SPIN
I slides and tutorial exercises available from module webpage
I module wiki: use it to discuss the lecture material
I study group?
Assessment

I 20 point module

I 50% exam

I 50% coursework (on Promela and SPIN model checker)

I set in week 4
I due in week 9
Coursework and Academic Integrity

Make sure you know what constitutes acceptable academic practice!

I We expect to see original work from students
I Cite your sources
I You may collaborate with others but:
I you must explicitly state this is what you have done
I expect the work to be marked more stringently

I Don’t copy
Reading List for the Theory Part

I M. Huth and M. Ryan, Logic in Computer Science – Modelling

and Reasoning about Systems (second edition), Cambridge
University Press, 2004.
(Chapter 3)
I E.M. Clarke, O. Grumberg, and D.A. Peled, Model Checking,
MIT Press, 1999.
(Chapters 1-4)
I D.A. Peled, Software Reliability Methods, Springer, 2001.
(Chapter 6)
Model Checking - Motivation
I ultra-high dependability requirements (e.g. Ariane 5)
⇒ need for ensuring correctness of design/code (at the
earliest possible stage)
I traditional approaches to validating designs/code:
I simulation:
I performed on abstractions, or models, of systems
I only offers partial validation, as only some system behaviours
are explored
I testing:
I effective in the early stages of debugging but becomes
time-consuming in later stages
I does not scale up
I difficult for concurrent and distributed systems
I only offers partial validation, as not all scenarios are explored
Model Checking - Motivation

I formal verification offers correctness guarantees:

I deductive verification (proof):
I both the system description and the correctness properties are
sets of formulas
I axioms and proof rules are used to prove correctness (e.g.
invariant properties)
I theorem prover technology is hard and not fully automatic
I works for infinite state systems
I model checking:
I involves checking properties of models
I performs exhaustive exploration of all possible behaviours
I typically works on finite models only
I fully automatic
Model Checking

I technique for automatically verifying correctness properties of

finite-state systems;
I useful for verifying hardware systems and
(concurrent/distributed) software systems
I requires:
1. modelling approach: for modelling systems
2. specification language: for formalising correctness properties
3. model checker: automated tool for exhaustively checking
properties on models.
Model Checking - the Process

I modelling: build abstraction of the system being analysed, as a

mathematical model understandable to a model checker
(e.g. Kripke structures)
I possibly perform simulations to validate model

I specification: specify desired properties of the model in a

suitable formalism (e.g. temporal logic)
I verification with a model checker:
I performs exhaustive exploration of all possible behaviours, to
verify that specified properties hold in the model
I a counterexample (error trace) is produced whenever the
model does not satisfy the specification ⇒ revise model and/or
specification
Model Checking - Advantages and Disadvantages

I advantages:
I fully automatic process (unlike theorem proving)
I can be used to perform partial verification (only certain
features are modelled, only certain properties are verified)
I terminates with yes/no answer
I error traces are informative
I logics used for specification can express a large class of
(usually temporal) correctness properties of systems

I disadvantages:
I state space explosion problem (when the system being verified
has many interacting components, or data structures with
many possible values)
I traditionally only works for finite state systems
Hardware/Software Model Checking

Classical approach  Modern approach




initial design 

abstraction 
 
verification model o / Model Checker
 o / verification model
 O
refinement  abstraction
 
implementation implementation
Kripke Structures, Informally
I mathematical models used to describe the behaviour of
systems
I graphs with nodes representing states and edges modelling
atomic state changes
I e.g. states described by colours of a traffic light, transitions
model switching from one colour to another:

s1 (red , amber )
o7 PPP
ooooo PPP
PPP
oo PP'
ooo
s0 (red ) s2 (green)
gOOO
OOO ooo
OOO ooooo
OO o
w oo
o
s3 (amber )
Kripke Structures, Formally

A Kripke structure M over a set Prop of atomic propositions is

given by:
I a finite set S of states
I a subset S0 ⊆ S of initial states
I a transition relation R ⊆ S × S between states
I a valuation V giving, for each state s ∈ S, the atomic
propositions which are true in that state: V (s) ⊆ Prop

Think of S as modelling the states of a system, of R as modelling

atomic computation steps, and of V as describing basic properties
of states.
Paths through the Kripke structure then correspond to possible
system executions !
Kripke Structures - an Example

4 @ABC
GFED
!
a b @s0
@@
@@
GFED
@ABC / 89:;
?>=<
y @
b c c s2
s1 H

I set of states: S = { s0 , s1 , s2 }
I set of initial states: { s0 }
I transition relation:
{ (s0 , s1 ) , (s0 , s2 ) , (s1 , s0 ) , (s1 , s2 ) , (s2 , s2 ) }
s0 −→ s2 s2 6−→ s0
I valuation V gives labelling of states with atomic propositions:
V (s0 ) = {a, b}
V (s1 ) = {b, c}
V (s2 ) = {c}
Example: Mutual Exclusion Protocol
bool turn;
P = m : cobegin P0 k P1 coend m0
P0 = n0 : while True do P1 = n1 : while True do
t0 : wait (turn = 0); t1 : wait (turn = 1);
c0 : use resource; turn := 1; c1 : use resource; turn := 0;
endwhile ; n00 endwhile ; n10

Note: wait (c) repeatedly tests c until it becomes true.

Extract a Kripke structure which models P0 k P1 :

I states are given by pairs of states of P0 and P1 (values of
process counters), together with the value of the shared
variable turn
I transitions correspond to atomic execution steps in either P0
or P1 (asynchronous system)
I Prop and V will depend on the properties we want to verify . . .
Mutual Exclusion: the Model

bool turn;
P = m : cobegin P0 k P1 coend m0
P0 = n0 : while True do P1 = n1 : while True do
t0 : wait (turn = 0); t1 : wait (turn = 1);
c0 : use resource; turn := 1; c1 : use resource; turn := 0;
endwhile ; n00 endwhile ; n10

 r , 
0, n0 , n1
pp NNN p
1, n0 , n1
p NNN
w pp
p NN' wppp NN'
Z NNN
0, n0 , t1
pp \ OOOOO
0, t0 , n1
oo B NNNNN
1, n0 , t1
pp Z
1, t0 , n1
NN' wpp p ' wooo ' wppp
D
0, t0 , t1
NNN oo
0, c0 , n1
OOO
1, n0 , c1
p D
1, t0 , t1
p
NN' wooo OO' wppp
Z
0, c0 , t1
Z
1, t0 , c1

(More on extracting Kripke structures from concurrent programs in

Chapter 2 of Clarke, Grumberg and Peled.)
Exercise

How would you model the possibility that a process does not
relinquish the shared resource after a finite amount of time?
Exercise

Construct the Kripke structure associated to the following mutual

exclusion algorithm:

bool turn;
bool flag 0 = 0, flag 1 = 0;
P = cobegin P0 k P1 coend
P0 = while True do
flag 0, turn := 1, 1;
wait ((flag 1 = 0) || (turn = 0));
use resource; flag 0 := 0;
endwhile ;
P1 = while True do
flag 1, turn := 1, 0;
wait ((flag 0 = 0) || (turn = 1));
use resource; flag 1 := 0;
endwhile ;
Fairness Assumptions: Example

A (semaphore-based) mutual exclusion algorithm:

/ 1, n , n o
0 1M
qqq MMM
q qq MMM
xq &
1, t0 , n1M o / 1, n , t
0 1M
qqq MMM qqq MMM
q MMM& q MMM
xqqq xqqq &
0, c0 , n1M 1, t0 , t1M 0, n0 , c1
MMM q MMM q
MMM q qqqq MMM qqqqq
& xq & xq
0, c0 , t1 0, t0 , c1

Is it fair that the second process has infinitely many possibilities to enter
the critical section, but never enters it?
Is it fair that the second process has infinitely many possibilities to enter
the critical section, but only enters it finitely many times?
Fairness Assumptions

I capture the idea that the scheduling of processes is fair

I each process gets its turn to run infinitely often

I this is assumed, not required:

I only fair executions are explored by the model checker

I typically needed to prove liveness properties

I often some executions (the unfair ones) refute liveness
properties
Fairness Assumptions (Cont’d)
I different degrees of fairness: a process gets its turn infinitely
often . . .
I . . . always ⇒ unconditional fairness
I . . . if it is enabled infinitely often ⇒ strong fairness
I . . . if it is continuously enabled from some point ⇒ weak
fairness

I which assumption is sufficient depends on the particular

example . . .
I in the previous example, strong fairness is needed

I . . . but the assumption must be satisfied by the scheduler !

I this is process-based fairness, we will also look at action-based

fairness later . . .
Some Problems in Concurrent/Distributed Systems

Competition for shared resources leading to:

I deadlock: two or more processes stop and wait for each other
I livelock: two or more processes continue to execute, but make
no progress towards the ultimate goal
I starvation: some process gets deferred forever/a particular
event is prevented from happening
Correctness Properties

I safety properties: nothing "bad" ever happens (along any

possible execution of the system)
I absence of deadlock: a process never enters a state it cannot
leave
I system invariants: some (desirable) property is true in all
future states

I liveness properties: something "good" eventually happens

(along every possible execution of the system)
I absence of livelock/starvation
I progress: a particular event happens eventually/infinitely often

I more complex temporal properties of systems

I responsiveness: every request is eventually followed by a reply
Mutual Exclusion: Safety Properties

I mutual exclusion: at most one process in critical section at any

time

Safety properties are violated in finite time.

That is, if an execution violates a safety property, then it has a

finite prefix which also violates the property.
(This is not true of liveness properties.)
Mutual Exclusion: Liveness Properties

I eventually: each process will eventually enter its critical section

I repeated eventually: each process will enter its critical section

infinitely often
I starvation freedom: each waiting process will eventually enter
its critical section

Liveness properties are violated in infinite time.

That is, a liveness property does not rule out any finite prefix of an
execution.
Mutual Exclusion: the Specification

Correctness properties:
I mutual exclusion (safety): at most one process in critical
section at any time
I starvation freedom (liveness): whenever a process tries to
enter its critical section, it will eventually succeed
I non-blocking (liveness): a process can always, at some point
in the future, request to enter its critical section
I no strict sequencing: processes need not enter their critical
section in strict sequence
Exercise

Consider the previous (models of) mutual exclusion protocols.

Check (by inspecting the models/protocols) whether the four
correctness properties hold in this model.
Does this depend on any fairness assumptions?