02291: System Integration

Week 11

Hubert Baumeister
[email protected]

DTU Compute
Technical University of Denmark

Spring 2018
Contents

Model checking

Course Summary

Remaining parts of the course

Railway crossing example

No accidents should happen

Railway crossing example

Train 1:

[t1=enroute] [t1=onBridge]

[s1=green]
[t1=atSignal]

Train 2

[t2=enroute] [t2=onBridge]

[s2=green]
[t2=atSignal]
Railway crossing example

Signal 1
[t1=atSignal & (t2=enroute | t2=atSignal)]

[s1=green] [s1=red]

Signal 2
[t2=atSignal & t1=enroute]

[s2=green] [s2=red]
Railway Crossing

I Can accidents happen?

I Tests
I Show presence of bugs (Dijkstra)
I Verification
IShow the absence of bugs
→ It never happens that both trains are at the same time on
the bridge
Model checking

I Express collision freeness in a formal language

ϕ = Trains t1 and t2 are never on the bridge at the same time

I Express the model (M) in a formal language

I Prove
M |= ϕ
Model checking

I Models (Kripke structures)

I Software
I Hardware controller
I Models, like UML state machines
I Formulas (Computational Tree Logic = CTL)
I A certain state of the system will be reached
I A certain state will be never reached
I Proving: Model checking
Model checking

I Models (Kripke structures)

I Software
I Hardware controller
I Models, like UML state machines
I Formulas (Computational Tree Logic = CTL)
I A certain state of the system will be reached
I A certain state will be never reached
I Proving: Model checking
I Possible answers:
I M |= φ
I M 6|= φ plus counter example
I none: out of memory or time limit is exceeded
Example of a Kripke structure

The Kripke structure of the railroad crossing system has 36

states (2 × 2 × 3 × 3)

1 2 3 4 5 10
[s1=red [s1=red [s1=green [s1=green [s1=red [s1=red
s2=red s2=red s2=red s2=red s2=red s2=red
t1=enroute t1=atSignal t1=atSignal t1=onBridge t1=onBridge t1=onBridge
t2=enroute] t2=enroute] t2=enroute] t2=enroute] t2=enroute] t2=onBridge]

.... ....
.... 17
6 7 8 9
[s1=red
[s1=red [s1=green [s1=green [s1=red s2=green
s2=red s2=red s2=red s2=red
t1=onBridge
t1=atSignal t1=atSignal t1=onBridge t1=onBridge
t2=onBridge]
t2=atSignal] t2=atSignal] t2=atSignal] t2=atSignal]

11 12 13 14 15 16
[s1=red [s1=red [s1=red [s1=red [s1=green [s1=green
s2=red s2=green s2=green s2=red s2=red s2=green
t1=enroute t1=enroute t1=enroute t1=enroute t1=onBridge t1=onBridge
t2=onBridge] t2=onBridge] t2=atSignal] t2=atSignal] t2=onBridge] t2=onBridge]
Kripke structure: Definition

M |= φ

Kripke structure (nondeterministic finite state machine)

A Kripke structure M = (S, I, R, λ):
I Set of states S = {1, 2, . . . , 36}
I Initial states I = {1} ⊆ S
I Transition relation R = {(1, 2), . . .} ⊆ S × S
I Propositions V = {s1 is red, s1 is green, s2 is red, s2 is green,
t1 is on bridge, t1 is at signal, t1 is enroute,
t2 is on bridge, t2 is at signal, t2 is enroute}
I Set of true propositions in a state λ : S → 2V
λ(1) = {s1 is red, s2 is red, t1 is on bridge, t2 is on bridge}
λ(2) = {s1 is red, s2 is red, t1 is at signal, t2 is on bridge}
...
Computation Tree

Unfolding of a Kripke structure

Computation Tree

Unfolding of a Kripke structure

Computation Tree

Unfolding of a Kripke structure

Computation Tree

Unfolding of a Kripke structure

Computation Tree

Unfolding of a Kripke structure

Logical formulae: CTL
M |= φ
Satisfaction
I M |= φ: the formula φ holds starting from all initial states,
i.e. ∀s0 ∈ I : M, s0 |= φ
I M, s0 |= φ: the formula φ holds starting from state s0

CTL: Computation Tree Logic formulae (1/4)

I p ∈ V: p is a basic proposition
I ¬φ, φ ∧ ψ, φ =⇒ ψ, . . . : the usual boolean connectors
...

Satisfaction: simple formulae

I M, s0 |= p iff p ∈ λ(s0 )
I M, s0 |= φ ∧ ψ iff M, s0 |= φ and M, s0 |= ψ . . .
Example

1 2 3 4 5 10
[s1=red [s1=red [s1=green [s1=green [s1=red [s1=red
s2=red s2=red s2=red s2=red s2=red s2=red
t1=enroute t1=atSignal t1=atSignal t1=onBridge t1=onBridge t1=onBridge
t2=enroute] t2=enroute] t2=enroute] t2=enroute] t2=enroute] t2=onBridge]

.... ....
.... 17
6 7 8 9
[s1=red
[s1=red [s1=green [s1=green [s1=red
s2=green
s2=red s2=red s2=red s2=red
t1=onBridge
t1=atSignal t1=atSignal t1=onBridge t1=onBridge
t2=onBridge]
t2=atSignal] t2=atSignal] t2=atSignal] t2=atSignal]

11 12 13 14 15 16
[s1=red [s1=red [s1=red [s1=red [s1=green [s1=green
s2=red s2=green s2=green s2=red s2=red s2=green
t1=enroute t1=enroute t1=enroute t1=enroute t1=onBridge t1=onBridge
t2=onBridge] t2=onBridge] t2=atSignal] t2=atSignal] t2=onBridge] t2=onBridge]

M, 1 |= s1 = red
M, 5 6|= s1 = green
M, 3 |= s1 = green ∧ t1 = atSignal
Logical formulae: CTL
M, s0 |= QT φ

I Q: for all paths (A), or there exists one path (E)

I T : for the next state of one path (X), for some state of one
path (F), for all states on one path (G)

CTL: Computation Tree Logic (2/4)

...
I EX φ,AX φ: formula φ holds in one successor state or in all successor
states
...
Logical formulae: CTL

CTL: Computation Tree Logic (3/4)

...
I EF φ, AF φ: formula φ holds eventually in one state in one path or
eventually in one state in all paths
I EG φ, AG φ: formula φ holds in every state of one path or in every state
of every path
...
Logical formulae: CTL

CTL: Computation Tree Logic (4/4)

...
I φ EU ψ, φ AU ψ: formula φ holds in every state of one path or in every
state of every path until ψ holds
CTL example
Railway crossing example

I Safety property: Both trains are not at the same time on

the bridge
I The following states are not reachable:
Railway crossing example

I Safety property: Both trains are not at the same time on

the bridge
I The following states are not reachable:

[s1=?
s2=?
t1=onBridge
t2=onBridge]
Railway crossing example

I Safety property: Both trains are not at the same time on

the bridge
I The following states are not reachable:

[s1=?
s2=?
t1=onBridge
t2=onBridge]

I CTL formula: AG ¬(t1 = onBridge ∧ t2 = onBridge)

Model Checking

Compute
[|φ|] = {s | M, s |= φ}
Then
M |= φ if and only if I ⊆ [|φ|]
How to compute [|φ|]?

Minimal set of operators

CTL formulae can be reduced to
a. p, ¬φ, φ ∨ ψ
b. EX φ
c. EG φ
d. φ EU ψ
For example
I AG φ can be expressed as ¬EF ¬φ
I Or EF φ as true EU φ
How to compute [|φ|]?

a [|p|] = {s | p ∈ λ(s)} for basic propositions p ∈ V

b [|¬φ|] = S \ [|φ|]
c [|EX φ|] = R −1 ([|φ|]) = {s | ∃t : (s, t) ∈ R and t ∈ [|φ|]}
d [|EG φ|] = [|φ|] ∩ R −1 ([|EG φ|])
I EG φ ⇔ φ ∧ EX EG φ
I We are looking for the greatest fixpoint of this equation
I Kleene’s fixpoint theorem allows to compute the greatest
fixpoint by
1 π0 = S
2 π 1 = [|φ|] ∩ R −1 (π 0 )
...
n π n = [|φ|] ∩ R −1 (π n−1 )
→ π m is the greatest fixpoint if π m = π m−1
e [|φ EU ψ|] = [|ψ|] ∪ ([|φ|] ∩ R −1 ([|φ EU ψ|]))
I Here we are looking for the least fixpoint!
I Start the iteration from the empty set ∅
Greatest fixpoint

∃S ⊆ N : S = S ∩ {3}
Least Fixpoint

∃S ⊆ N : S = S ∪ {3}
Example: EG y

π0 = S
Example: EG y : 1. Iteration

π 1 = [|y |] ∩ R −1 (π 0 )
Example: EG y : 1. Iteration

π 1 = [|y |] ∩ R −1 (π 0 )
Example: EG y : 1. Iteration

π 1 = [|y |] ∩ R −1 (π 0 )
Example: EG y : 1. Iteration

π 1 = [|y |] ∩ R −1 (π 0 )
Example: EG y : 2. Iteration

π 2 = [|y |] ∩ R −1 (π 1 )
Example: EG y : 2. Iteration

π 2 = [|y |] ∩ R −1 (π 1 )
Example: EG y : 2. Iteration

π 2 = [|y |] ∩ R −1 (π 1 )
Example: EG y : 2. Iteration

π 2 = [|y |] ∩ R −1 (π 1 )
Example: EG y : 3. Iteration

π 3 = [|y |] ∩ R −1 (π 2 )
Example: EG y : 3. Iteration

π 3 = [|y |] ∩ R −1 (π 2 )
Example: EG y : 3. Iteration

π 3 = [|y |] ∩ R −1 (π 2 )
Example: EG y : 3. Iteration

π 3 = [|y |] ∩ R −1 (π 2 )
Example: EG y : Conclusion

I π 3 = π 2 is the greatest fixpoint

I [|EG y|] = {s0 , s2 , s4 }, i.e., EG y holds for states s0 , s2 ,
and s4
I M 6|= EG y because I = {s0 , s1 } 6⊆ [|EG y |]
Model checking

I Press button technology

I Spin, Upaal, . . .
I Problems
I Finite state space
I State explosion
I UML and Model checking
I State machines 6= Kripke structures
Advanced reading
I Kenneth L. McMillan’s thesis on ”Symbolic Model
Checking” http://www.kenmcmil.com/thesis.html
1999
I E. Clarke, O. Grumberg, D. Peled ”Model Checking” MIT
Press1999
I EM Clarke, BH Schlingloff ”Model Checking” Chapter 21 in
Handbook of Automated Reasoning - Elsevier Science
Publishers BV, Amsterdam, The Netherlands, 2000
http://www2.informatik.hu-berlin.de/˜hs/
Publikationen/2000_
Handbook-of-Automated-Reasoning_
Clarke-Schlingloff_Model-Checking.ps
I St. Merz ”Model Checking: A Tutorial Overview” http:
//www.loria.fr/˜merz/papers/mc-tutorial.pdf
2001
Model checker

I For model checking UML state machines and UML

collaborations
I Hugo/RT http://www.pst.ifi.lmu.de/Forschung/
projekte/hugo/index.html
I UMC http://fmt.isti.cnr.it/umc
I General model checker
I nuSMV http://nusmv.fbk.eu/
I Spin http://netlib.bell-labs.com/netlib/spin/
whatispin.html
I Uppaal http://www.uppaal.com/
I Links to other model checkers
http://en.wikipedia.org/wiki/Model_checking
Contents

Model checking

Course Summary

Remaining parts of the course

What you have learned

I Modelling notations
I One system, several views: Use case realizations
I Views: Component-, Class-, State-Machine-, Use Case-,
Activity-, and Sequence diagram; OCL constraints
I Requirements
I Use cases: use case diagrams, detailed use cases, user
stories, glossary
I Design
I CRC cards, High cohesion/low coupling, layered
architecture, object-orientation
I Development Process
I Agile modeling, agile project planning, MDA
I Verification / Validation
I Test, Model checking
Tips

I Don’t look at each diagram type in isolation

I Look at how all the diagram types work together to make a
use case (scenario) possible
I For each use case scenario
IExtend (CRC cards:) How the components talk to each other
IExtend Components, ports, and interfaces
I Extend Protocol state machines
I Extend (CRC cards:) Implementing components

subcomponents or classes
→ Classes implement provided interfaces of ports and use
required interfaces of ports
I Extend OCL constraints / object life cycle state machines of

classes
I Check that the use case scenario can be realized with your

system
→ Report structure is not the same as the structure of the
development process
Contents

Model checking

Course Summary

Remaining parts of the course

Remaining parts of the course

I Next week and the week after: exercises 8:15—10:00

I The week after next week: exam project delivery date
I Remember to take part in the evaluation of the course