Verification by Model Checking
Formal Methods Laboratory
University of Tehran
Based on the chapter 3 of “Logic in Computer Science”,
Huth & Ryan
Verification by Model Checking
1
Part 1 : Motivation
Verification by Model Checking
2
Introduction
 Verification: verifying the correctness of
computer systems
 hardware, software or combination
 It is most obvious in
 safety-critical systems
 commercially critical
 mission critical
Verification by Model Checking
3
Verification 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
Verification by Model Checking
4
Classification
 Approaches to verification can be classified in
several ways:




Proof-based vs. model-based
Degree of automation
Full- vs. property- verification
Intended domain of application
 hardware-software, sequential-concurrent, reactiveterminating, …
 Pre- vs. post- development
Verification by Model Checking
5
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
Verification by Model Checking
6
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
Verification by Model Checking
7
Degree of automation
 From fully automated to fully manual
Verification by Model Checking
8
Full- vs. property-verification
 The specification may describe a single property
of the system, or it may describe its full behavior
(expensive).
Verification by Model Checking
9
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)
Verification by Model Checking
10
Pre- vs. post-development
 Verification is of greater advantage if introduced
early in system development
Verification by Model Checking
11
Model checking
 Model checking is an automatic, model-based,
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
 Concurrency bugs
 non reproducible
 not covered by test cases
Verification by Model Checking
12
Temporal Logic
 The idea is that a formula is not statically true or
false in a model
 The models of temporal logic contain several
states
 a formula can be true in some and false in the others
 The static notion of truth is replaced by a dynamic
one
 the formulas may change their truth values
as the system evolves from state to state
Verification by Model Checking
13
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 φ
Verification by Model Checking
14
Model checker
p →F q
yes
φ
Model
Checker
no
Error Trace
M
Verification by Model Checking
15
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
Verification by Model Checking
16
Linear vs. Branching (cont.)
 Linear Time
 Branching Time
 Every moment has a
unique successor
 Infinite sequences
(words)
 Linear Time Temporal
Logic (LTL)
 Every moment has
several successors
 Infinite tree
 Computation Tree
Logic (CTL)
Verification by Model Checking
17
CTL
 Branching time
Verification by Model Checking
18
Computational tree logic
 Syntax:
::= F | T | p | (~) |
( /\ ) | (\/) | ( -> ) |
AX | EX | A[U] | E[U] |
AG | EG | AF | EF
Where p ranges over atomic formulas/descriptions.
Verification by Model Checking
19
 AX, EX, AG, EG, AU, AF, EF : temporal connectives
 The first of the pair
 A means “ along All paths”
 E means “ along at least (there Exist) one path”
 The second one of the pair




X means “ neXt state”
F means “some Future state”
G means “ all future states (Globally)”
U means “ Until”
Verification by Model Checking
20
 Convention
 Binding priorities
 Unary connectives: ~, AG, EG, AF, EF,AX, EX
 /\ , \/
 -> , AU, EU
Verification by Model Checking
21
 Well-formed CTL formulas:
 EGr
 AG(q -> EGr)
different from AGq -> EGr , which is
(AGq) -> (EGr)
 A[p U EFr]
 EF EG p -> AFr
 Page 153: some well-formed and some not wellformed
Verification by Model Checking
22
 EF(rUq) ??
 U can only be paired with an A or an E
 EF E[rUq] or EF A[rUq]
 AF[(rUq) /\ (pUr)] ??
 Boolean connective (/\) cannot be directly inside A[] or
E[]
Verification by Model Checking
23
Example
 The parse tree of A[AX ~p U E[EX(p/\q)U ~p]]
according to precedence rules
 Fig. 3.1, page 155
Verification by Model Checking
24
Transition System
 A model M = (S, →, L) for CTL is
 S: a finite set of states
 → : a binary relation on S, such that every s  S has
some s '  S with s → s '
 L : a labeling function L: S → P( Atoms)
 P( Atoms) means the power set of Atoms
 The interpretation of the labeling function is that
each state s has a set of atomic propositions L(s)
which are true at that particular state
Verification by Model Checking
25
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}
Verification by Model Checking
26
Deadlock
 We will call the transition systems simply models
in our discussions
 According to the definition of a model, for each
s  S there is at least one s'  S
 No state of a system may be deadlocked
 If a system has a deadlock, we always add an
extra state sd representing the deadlock
Verification by Model Checking
27
Deadlock state
s0
s1
s0
s2
s2
s3
s3
s1
sd
s3 doesn’t have any
further transitions
adding a deadlock
state sd
Verification by Model Checking
28
Unwinding
 We can unwind the transition system to obtain an
infinite computation tree
 The execution paths of a model M are explicitly
represented in the tree obtained by unwinding the
tree
Verification by Model Checking
29
Unwinding: example
s0
an arbitrary
path
p,q
s1
s2
s0
q,r
p,q
q
s0
s2
q
s1
q,r
q,r
s2
q,r
p,q
q
p,q
s0
s2
s1
q,r
Verification by Model Checking
s1
s1
s2
q
q
30
Formal Semantics


Let M = (S, →, L) be a model and п = s1 →…
be a path in M
Whether п satisfies an CTL formula is defined
by the satisfaction relation ╞ as follows:
1
2
3
4
Verification by Model Checking
31
1.
2.
3.
4.
5.
6.
M,s|= T and M,s|≠F for all s ∈S
M,s |= p iff p ∈L(s)
M,s |= ~ iff M,s |≠ 
M,s |= 1 /\ 2 iff M,s |= 1 and M,s |= 2
M,s |= 1 \/ 2 iff M,s |= 1 or M,s |= 2
M,s |= 1 -> 2 iff M,s |≠ 1 or M,s |= 2
Verification by Model Checking
32
Next
 7. M,s |= AX iff for all s1 such that
s->s1 we have M,s|= .
Thus, AX says “in every next state”
 8. M,s |= EX iff for some s1 such that s->s1 we
have M,s|= .
Thus, EX says “in some next state”
Verification by Model Checking
33
Globally
 9. M,s |= AG holds iff for all paths
s1->s2->s3-> … where s1 equals s, and for all si
along the path, we have M,si |= .
For all computation paths beginning in s the
property  holds Globally (including the initial
state).
Verification by Model Checking
34
 10. M,s |= EG holds iff there is a path s1->s2>s3-> … where s1 equals s, and for all si along
the path, we have M,si |= .
There exist a path beginning in s such that the
property  holds Globally (including the initial
state).
Verification by Model Checking
35
Finally
 11. M,s |= AF holds iff for all paths
s1->s2->s3-> … where s1 equals s, there is some si
along the path, such that we have M,si |= .
For all computation paths beginning in s there will
be some Future state where  holds.
Verification by Model Checking
36
 12. M,s |= EF holds iff there is a path s1->s2>s3-> … where s1 equals s, and for some si along
the path, we have M,si |= .
There exist a path beginning in s such that the
property  holds in some Future state.
Verification by Model Checking
37
Until
 13. M,s |= A[1 U 2] holds iff for all paths
s1 -> s2 -> s3 -> … where s1 equals s, that path
satisfies 1 U 2 , i.e. there is some si along the
path, such that we have M,si |= 2, and, for each
j<i, we have M,sj |= 1.
 14. M,s |= E[1 U 2] …
Verification by Model Checking
38
A note for Until
 Until says nothing about what happens after the
Until has been realized
 This can be different from natural English
speaking
 For example:
 “She continued working until she married”
 We may interpret the sentence as she discontinued
working after marriage
 The above understanding is related to this formula
 working U ( marriage  G ⌐working)
Verification by Model Checking
39
 P.160: EF, EG
 P.161: AF, AG
 P.162: Until
Verification by Model Checking
40
Some practical patterns
 It is possible to get to a state where started holds,
but ready does not hold
 EF (started  ⌐ready)
 For any state, if a request occurs, then it will
eventually be acknowledged
 AG (requested → AF acknowledged)
 Whatever happens, a certain process will
eventually be permanently deadlocked
 AF (AG deadlock)
Verification by Model Checking
41
Some practical patterns (cont.)
 A certain process is enabled infinitely often on
every computation path
 AG (AF 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
Verification by Model Checking
42
Part 2 : LTL
Amir Pnueli
The Weizmann
Institute of Science
Verification by Model Checking
43
LTL
 LTL : Linear-time Temporal Logic
 It has some connectives for referring to the future
 It models time as a sequence of states, extending
infinitely to future
 computation path
 The future is not determined, we should consider
several paths for different futures
 Any one of the paths can be the actual path that is
realized
Verification by Model Checking
44
Atoms
 We work with a fixed set of atomic formulas (like
p, q, r,…)
 They stands for atomic facts which hold for a
system
 Process 897 is blocked
 The variable x2 is zero
 The content of register R1 is 01010
Verification by Model Checking
45
Syntax of LTL
 The syntax of LTL in BNF is:
 where p is any propositional atom from some set
Atoms
 X, F, G, U, R, W : temporal connectives
Verification by Model Checking
46
Temporal Connectives






X : neXt state
F : some Future state ( eventually)
G : all future states (Globally)
U : Until
R : Release
W : Weak-until
Verification by Model Checking
47
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.
Verification by Model Checking
48
Example
 The parse tree of Fp  Gq →p W r according to
precedence rules
→

W
F
G
p
q
p
Verification by Model Checking
r
49
Transition System
 A transition system is a structure M = (S, →, L)
where
 S: a finite set of states
 → : a binary relation on S, such that every s  S has
some s '  S with s → s '
 L : a labeling function L: S → P( Atoms)
 P( Atoms) means the power set of Atoms
 The interpretation of the labeling function is that
each state s has a set of atomic propositions L(s)
which are true at that particular state
Verification by Model Checking
50
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}
Verification by Model Checking
51
Deadlock
 We will call the transition systems simply models
in our discussions
 According to the definition of a model, for each
s  S there is at least one s'  S
 No state of a system may be deadlocked
 If a system has a deadlock, we always add an
extra state sd representing the deadlock
Verification by Model Checking
52
Deadlock state
s0
s1
s0
s2
s2
s3
s3
s1
sd
s3 doesn’t have any
further transitions
adding a deadlock
state sd
Verification by Model Checking
53
Paths
 A path in a model M = (S, →, L) is an infinite
sequence of states s1, s2, s3,…in S such that, for
each i  1, si → si+1.
 We write paths as s1 → s2 → s3 → …
 Each arbitrary path ( e.g. п = s1 → s2 →…)
represents a possible future of the system
 first it is in s1, then s2 and so on
 We write пi for the suffix starting at si
 п2 is s2 → s3 →…
Verification by Model Checking
54
Unwinding
 We can unwind the transition system to obtain an
infinite computation tree
 The execution paths of a model M are explicitly
represented in the tree obtained by unwinding the
tree
Verification by Model Checking
55
Unwinding: example
s0
an arbitrary
path
p,q
s1
s2
s0
q,r
p,q
q
s0
s2
q
s1
q,r
q,r
s2
q,r
p,q
q
p,q
s0
s2
s1
q,r
Verification by Model Checking
s1
s1
s2
q
q
56
Informal semantics
 Globally p : G p
 G p is true in a state if p holds at all points of time
(along the path) starting from that state
p=
Suppose G p holds in the initial state
0
1
2
3
Verification by Model Checking
57
Informal semantics (cont.)
 Eventually p : F p
 F p is true in a state if p holds at some points in
the future, stating from the state
p=
Suppose F p holds in the initial state
0
1
2
3
Verification by Model Checking
58
Informal semantics (cont.)
 Next p : X p
 X p is true along a path starting in a state if p
holds in the next state
p=
Suppose X p holds in state at t=2
0
1
2
3
Verification by Model Checking
59
Informal semantics (cont.)
 p Until q : p U q
 p U q is true in state s if
 q is true in some state reachable from s
 p is true in all states from s until q holds
p=
q=
Suppose p U q holds in the initial state
0
1
2
3
Verification by Model Checking
60
A note for Until
 Until says nothing about what happens after the
Until has been realized
 This can be different from natural English
speaking
 For example:
 “She continued working until she married”
 We may interpret the sentence as she discontinued
working after marriage
 The above understanding is related to this formula
 working U ( marriage  G ⌐working)
Verification by Model Checking
61
Formal Semantics


Let M = (S, →, L) be a model and п = s1 →…
be a path in M
Whether п satisfies an LTL formula is defined
by the satisfaction relation ╞ as follows:
1
2
3
4
Verification by Model Checking
62
Formal Semantics (cont.)
5
6
7
8
9
10
Verification by Model Checking
63
Formal Semantics (cont.)
 Until and Release are dual : φ R  ≡ ⌐ (⌐φ U ⌐ )
11
12
Verification by Model Checking
64
Release
 Release R is dual of U; that is:
φ R  ≡ ⌐ (⌐φ U ⌐ )
 must remain true up to and including the
moment when φ becomes true (if there is one);
φ releases 
Verification by Model Checking
65
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φ
Verification by Model Checking
66
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╞ φ
Verification by Model Checking
67
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
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)
q
q
Verification by Model Checking
68
Some practical patterns
 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
Verification by Model Checking
69
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
Verification by Model Checking
70
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
Verification by Model Checking
71
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 the state in which it is on the third
floor, there is a path along which it stays there)
 LTL cannot assert these because it cannot directly
assert the existence of paths
 However, CTL can express these properties
Verification by Model Checking
72
Expressing Properties by CTL
 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)
 AG(EF restart)
 The lift can remain idle on the third floor with its door
closed (i.e., from the state in which it is on the third
floor, there is a path along which it stays there)
 AG (floor3 & idle & doorclosed → EG (floor3 & idle &
doorclosed))
Verification by Model Checking
73
Equivalence
 We say that two LTL formulas φ and  are
semantically equivalent φ ≡  if for all models M
and all paths п in M: п╞ φ iff п╞ 
 The equivalence of φ and means that φ and 
are semantically interchangeable
 F and G are duals of each other
 ⌐G φ ≡ F ⌐φ
⌐F φ ≡ G ⌐φ
 X is dual with itself
 ⌐X φ ≡ X ⌐φ
Verification by Model Checking
74
Equivalence (cont.)
 F distributes over  and G over 
 F (φ  ) ≡ Fφ  F
 G (φ  ) ≡ Gφ  F
 Note that the above formulas are dual
 But these equivalences do not hold
 F (φ  ) ≡ Fφ  F
 G (φ  ) ≡ Gφ  F
Verification by Model Checking
75
Equivalence (cont.)
 Expressing F and G by U and R
 F φ ≡ ┬U φ
 Gφ≡┴Rφ
 W and R work rather similarly
 φ W  ≡  R (φ  )
 φ R  ≡  W (φ  )
Verification by Model Checking
76
Adequate Sets
 Definition: A set of connectives is adequate if all
connectives can be expressed using it
 X cannot be derived from any combination of the
others
 Each of these sets is adequate for LTL
 {U,X}
 {R,X}
 {W,X}
Verification by Model Checking
77
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
 Some expected properties for a correct protocol:
Safety, Liveness, Non-blocking, No strict
sequencing
Verification by Model Checking
78
 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.
Verification by Model Checking
79
Modeling mutex
 Consider each process to be either in its noncritical state n, trying to enter the critical section t
or in it c
 Each individual process has this cycle:
 n→t→c→n→t→c→n…
 The processes phases are interleaved
Verification by Model Checking
80
2 process mutex
 The processes are asynchronous interleaved
 one of the processes makes a transition while the other remains
s0
in its current state
n1 n2
t1 n2
s5
s1
n1 t2
s3
s2
t1 t2
c1 n2
s4
c 1 t2
n1 c2
t1 c 2
Verification by Model Checking
s6
s7
81
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 → …
 … p.189
 Second attempt: page 191, fig. 3.8
Verification by Model Checking
82
 Safety: Only one process is in its critical section at any
time:
 G ⌐(c1  c2).
 Liveness: Whenever any process requests to enter its
critical section, it will eventually be permitted to do so:
 G (t1 → F c1).
 Non-blocking: A process can always request to enter its
critical section:
 (in CTL): AG(n1 → EX t1).
 No strict sequencing: Processes need not enter their
critical section in strict sequence:
 Expressing the negation in LTL: G(c1 → c1 W(~c1 & ~c1 W c2))
 (in CTL): EF(c1 & E[c1 U (~c1 & E[~c2 U c1])])
Verification by Model Checking
83
s0
n1 n2
t1 n2
s5
s1
n1 t2
s3
s2
t1
c1 n2
s4
c 1 t2
t2
n1 c2
t1 c 2
Verification by Model Checking
s6
s7
84
CTL* and the expressive powers of
LTL and CTL
 CTL over LTL: CTL allows explicit quantification
over paths
 LTL over CTL: CTL does not allow one to select
a range of paths by describing them with a
formula, as LTL does.
 In LTL: all paths which have a p along them also have
a q along them: Fp → Fq
 In CTL none of these are the same: AF p → AF q
 Or AG (p → AF q)
Verification by Model Checking
85
CTL*
 Drop the CTL constraint that every …
 The syntax of CTL* involves two classes of
formulas:
 State formula, which are evaluated in states
 Path formulas, which are evaluated along paths
Verification by Model Checking
86
Fairness

Fairness:


Fairness is a subtle subject
There are several popular definitions of Fairness, such as weak
fairness, strong fairness, …
1. Weak (Buchi) fairness: an action cannot be enabled
forever without being taken

FG (enabled   taken ) = GF (enabled → taken)
2. Strong (Streett) fairness: an action cannot be enabled
infinitely often without being taken

(GF enabled ) → (GF taken )
(Thomas A. Henzinger, Four Lectures on Model Checking)
Verification by Model Checking
87
The properties
 Strong fairness makes model checking more
difficult
 We consider only weak fairness for our example
 Weak Fairness: GF ( t1 → c1)
 This constraint is also violated in the cycle
 s0 → s1 → s3 → s7 → s1 → s3 → s7 → …
Verification by Model Checking
88
Part 3 : Model Checking
with Spin
Verification by Model Checking
89
Practical or Theoretical
 Model checking, despite its theoretical
appearance is also a practical subject
 An outstanding symposium:
“The International SPIN Workshop on Practical
Aspects of Model Checking”
 Many hardware design companies, including Intel,
have adopted model checking as part of their basic
design method
 Some model checking systems such as NuSMV or
SPIN have shown great capability
Verification by Model Checking
90
Plan for this part
 In this part of the lecture, we will model a well
known problem in the computer science
 The mutual exclusion problem
 We will study the modeling approach in the Spin
model checker
 To get familiar with this tool, you have to model
some more problems yourself
Verification by Model Checking
91
Spin
 SPIN (Simple Promela Interpreter)
[Holzmann 1991]
Gerard J. Holzmann
NASA JPL Laboratory
for Reliable Software
 Spin is the state-of-the-art model checker
 More than two decades of research
 12 workshops so far
 Concurrent systems are described in a modeling
language called Promela
Verification by Model Checking
92
Spin (cont.)
 It was the winner of the 2001 ACM Software System
Award
 Some other Software System Award winners:





1983 UNIX
1986 TeX
1987 SMALLTALK
1991 TCP/IP
2002 Java
 The award citation:
"For SPIN, a highly successful and widely used software modelchecking system based on "formal methods" from Computer Science. It
has made advanced theoretical verification methods applicable to large
and highly complex software systems."
Verification by Model Checking
93
Promela
 Protocol/Process Meta Language
 Specification language to model finite-state
systems
 Loosely based on CSP
 dynamic creation of concurrent processes
 communication via message channels can be
synchronous (i.e. rendezvous), or asynchronous (i.e.
buffered)
 Features from Dijkstra’s guarded command
language
Verification by Model Checking
94
Promela models

A Promela model consist of:
1. type declarations
2. channel declarations
3. global variable
declarations
4. process declarations
5. [init process]
mtype, constants,
typedefs (records)
chan ch = [dim] of {type, …}
asynchronous: dim > 0
rendezvous:
dim == 0
- simple vars
- structured vars
- vars can be accessed
by all processes
behaviour of the processes:
local variables + statements
initialises variables and
starts processes
Verification by Model Checking
95
Promela Model (cont.)
 It corresponds to a finite transition system
 no unbounded: {data, channels, processes, process
creations}
mtype = {MSG, ACK} ;
chan toS = ...
bool flag ;
proctype Sender ( bool a) {
....
}
init {
...
}
Process
body
Create
Processes
Verification by Model Checking
96
Process
 A process is defined by a proctype definition
 executes concurrently with all other processes,
independently of speed or behavior
 communicates with other processes
 using global (shared) variables
 using channels
 There may be several processes of the same type.
 Each process has its own local state:
 process counter (location within the proctype)
 contents of the local variables
Verification by Model Checking
97
Process (cont.)
 A process type (proctype) consist of




a name
a list of formal parameters
local variable declarations
formal parameters
body
name
proctype Sender(chan in; chan out) {
bit sndB, rcvB;
do
local
:: out ! MSG, sndB ->
variables
in ? ACK, rcvB;
if
body
:: sndB == rcvB -> sndB = 1-sndB
:: else -> skip
fi
The body consist of a
od
sequence of statements.
}
Verification by Model Checking
98
Process (cont.)
proctype Foo(byte x) {
...
}
 Process are created using
the run statement (which
returns the process id).
init {
int pid2 = run Foo(2);
 Processes can be created at
run Foo(27);
any point in the execution
}
number of procs. (opt.)
(within any process).
 Processes start executing
active[3] proctype Bar() {
...
after the run statement.
}
parameters will be
 Processes can also be
initialised to 0
created by adding active
in front of the proctype
Verification by Model Checking
99
declaration.
Variables and Types
 Five different (integer)
basic types.
 Arrays
Basic types
bit
bool
byte
short
int
turn=1;
flag;
counter;
s;
msg;
 Records (structs)
Arrays
 Type conflicts are detected
at runtime
Typedef (records)
 Default initial value of
basic variables (local and
global) is 0
byte a[27];
bit flags[4];
typedef Record {
short f1;
byte f2;
}
Record rr;
rr.f1 = ..
Verification by Model Checking
[0..1]
[0..1]
[0..255]
[-215.. 215 –1]
[-231.. 231 –1]
array indexing
start at 0
variable
declaration
100
Variables and Types (cont.)
 Variables should be
declared.
 Variables can be given a
value by:




initialization
assignment
argument passing
message passing
 Variables can be used in
expressions.
int ii;
bit bb;
bb=1;
ii=2;
short s=-1;
typedef Foo {
bit bb;
int ii;
};
Foo f;
f.bb = 0;
f.ii = -2;
assignment =
declaration &
initialization
equality test ==
ii*s+27 == 23;
printf(“value: %d”, s*s);
Verification by Model Checking
101
Statements
 A statement is either
 Executable : if evaluates to non-zero
 Blocked : if evaluates to zero
 An assignment statement is always executable
 Examples :





1
0
2<3
X < 10
5+Y
always executable
always blocked (halt)
always executable
executable, if X is less than 10
executable, if Y is not equal to -5
Verification by Model Checking
102
Statements (cont.)
 Skip always executable (does nothing !)
 Run is only executable if a new process can be
created ( number of processes is bounded).
 Printf always executable
 Are separated by ( ; ) or by ( -> ), arrow is
sometimes also used to show causal relation
between successive statements
Verification by Model Checking
103
if-statement
 If there is at least one choice executable, if
statement is executable
 One of the executable choices is nondeterministically chosen
 If no choice is executable, the if-statement is
blocked until it becomes executable
if
:: choice1 -> stat1.1; stat1.2; stat1.3; …
:: choice2 -> stat2.1; stat2.2; stat2.3; …
:: …
:: choicen -> statn.1; statn.2; statn.3; …
fi
Verification by Model Checking
104
do-statement
 Behaves in the same way as if-statement with
respect to choices
 The only difference is it repeats
 break ( always executable ) exits a do-loop
do
:: choice1 -> stat1.1; stat1.2; stat1.3; …
:: choice2 -> stat2.1; stat2.2; stat2.3; …
:: …
:: choicen -> statn.1; statn.2; statn.3; …
od
Verification by Model Checking
105
Interleaving semantics
 Promela processes execute concurrently.
 Non-deterministic scheduling of processes.
 Processes are interleaved, not statements within a
single process.
 Statements of different processes do not occur at
the same time.
 All statements are atomic.
Verification by Model Checking
106
Any question?
Verification by Model Checking
107