SS 2017
Software Verification
Timed Automata
Prof. Dr. Holger Schlingloff 1,2
Dr. Esteban Pavese 1
(1) Institut für Informatik der Humboldt Universität
(2) Fraunhofer Institut für offene Kommunikationssysteme FOKUS
Recap
• What is a fixpoint?
• How is CTL model checking performed?
• What is a symbolic representation
• What are BDDs?
• How/why are BDDs used in model checking
(not only CTL)?
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 2
Back to roots
We use automata to model (abstracted) real world situations, and check properties
over these models
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 3
See the hidden problem?
This model is too abstract to capture some finer points of the real system...
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 4
The hidden problem
What is going on in this case?
Is there a way to “solve it”?
Maybe extra restrictions on the transitions? Do they make sense?
Maybe extra assumptions?
Are we being too abstract?
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 5
Re-thinking about the train
Some assumptions are not captured by the model
• The train has a maximum speed
•
•
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
 therefore there is a lower
bound on the time needed
from approach to enter
The gate does not take too long
to close the road
 an upper bound on the time it
takes exists
The controller will not take too
long (nor too short) a time to
signal the gate to lower
Slide 6
Refining the model
TRAIN
takes at least
2 minutes
approach
enter
exit
GATE
lower
CONTROLLER
raise
approach
takes at most
1 minute
lower
raise
exit
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
will signal
after 1
minute
Slide 7
Refining the model
TRAIN
takes at least
2 minutes
approach
exit
approach
enter
GATE
lower
CONTROLLER
will take at
most 2
minutes
raise
lower
takes at least
2 minutes
enter
approach
raise
takes at most
1 minute
lower
exit
will signal
after 1
minute
Makes sense! Now, if only these annotations were formal ...
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 8
First thing to note!
• This is easy for synchronous systems
• Every process moves at the same time
 There is a global clock that “ticks”
• So simply do
 define time resolution
 define how much time each action takes
 redefine each action with as many steps as
needed
• ... and use LTL / CTL as usual
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 9
Timed automata
• Timed automata are a proper extension of the
finite automata we know so far
• Timed automata = finite automata + finite
clocks
• Clocks are real valued variables
 but we can only read them, or reset them to zero
 all of them increase at the same rate
 like having many, many stopwatches
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 10
Timed automata
• We can establish conditions on clock values
• Clock conditions will be used as guards in
 transitions (enabling transition)
 states (triggering transition)
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 11
Second thing to note!
• If clocks were rational, this is easy
• Take all rational clock constraints
 find the smallest constant – this gives the time
resolution
 find the lcm of all denominators. Multiply all
constants (and also the time resolution) by this
number
 Everything is now an integer!
 Define variables instead of clocks, use LTL / CTL
as usual
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 12
Timed automata
Formally
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 13
Timed automata
R ✓ S ⇥ CC ⇥ A ⇥ 2C ⇥ S
source
state
action
label
transition
condition
destination
state
clocks to
reset
I nv : S ! CC
source
state
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
how long
can we stay
here?
Slide 14
Transition conditions and invariants
• Transitions conditions control when a
transition is enabled
• Invariants control when a transition must
beAut om
T imed
taken
4
value
of x
ℓ
x 2: τ
reset(x)
2
2
4
6
8
10
time
H. Schlingloff, (a)
E. Pavese SS2017: Software-Verifikation
(b)
Slide 15
T imed Aut om
Transition conditions and invariants
4
value
of x
• Transitions
conditions control when a
ℓ
x 2:τ
reset(x)
2
transition is enabled
2
4
6
8
10
• Invariants control when a transition time
must be
(a)
(b)
taken
4
ℓ
x
3
x 2: τ
reset(x)
value
of x 3
2
2
4
6
8
10
time
(c)
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
(d)
Slide 16
(a)
(b)
Transition conditions and invariants
4
value
of x 3
2
ℓ
• Transitions
conditions control when a
x 3
x 2: τ
reset(x)
transition is enabled
2
4
6
8
10
• Invariants control when a transition must
time be
(c)
(d)
taken
4
2 x
reset(x)
ℓ
value
of x 3
2
3: τ
2
4
6
8
10
time
(e)
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
(f)
Slide 17
Train/Gate/Controller redesigned
TRAIN
approach
reset(x)
takes at least
2 minutes
x<
5
GATE
enter
x>2
exit
lower
reset(z)
z<=1
z<=
1
z<=
1
CONTROLLER
approach
reset(y)
z<=1
raise
reset(z)
y<=
1
raise
y=1
exit
reset(y)
takes at most
1 minute
lower
y=1
y<=
1
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
will signal
after 1
minute
Slide 18
A i = (Loci , Act i , Ci , →i , Loc0,i , I nvi , APi , L i ), i = 1, 2 be t imed aut omat a wit
ct 1 ∩ Act 2, C1 ∩ C2 = ∅ and AP1 ∩ AP2 = ∅ . T he t imed aut omat on TA 1 ∥H TA
ned as
Parallel composition
(Loc1 × Loc2, Act 1 ∪ Act 2, C1 ∪ C2, →, Loc0,1 × Loc0,2, I nv, AP1 ∪ AP2, L )
•
L ( ⟨ℓ 1, ℓ 2⟩) = L 1(ℓ 1) ∪ L 2(ℓ 2) and I nv( ⟨ℓ 1 , ℓ 2 ⟩) = I nv1(ℓ 1 ) ∧ I nv2 (ℓ 2). T he t ransit ion
As with finite automata, it makes sense to
n → is defined by t he following rules:
model different concerns separately
or •
α ∈Parallel
H:
composition
still
synchronizes
on
g :α,D
g
:α,D
ℓ 1 →1 ℓ ′1 ∧ ℓ 2 →2 ℓ ′2
labels, but now must
take clocks
into
account
g ∧ g :α,D ∪D
⟨ℓ 1, ℓ 2⟩ → ⟨ℓ ′1, ℓ ′2⟩
• Non-shared rule is easy:
1
1
2
1
2
1
2
2
or α ̸∈ H :
ℓ1
⟨ ℓ 1, ℓ 2 ⟩
g:α ,D
→1 ℓ ′1
g:α ,D
→ ⟨ℓ ′1 , ℓ 2⟩
g:α ,D
and
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
ℓ 2 →2 ℓ ′2
g:α,D
⟨ℓ 1, ℓ 2⟩ → ⟨ℓ 1, ℓ ′2⟩
Slide 19
Loc2, Act 1 ∪ Act 2, C1 ∪ C2, →, Loc0,1 × Loc0,2, I nv, AP1 ∪ AP2, L
Parallel composition
= L 1(ℓ 1) ∪ L 2(ℓ 2) and I nv( ⟨ℓ 1, ℓ 2 ⟩) = I nv1(ℓ 1) ∧ I nv2 (ℓ 2). T he
efined by t he following rules:
• Shared rule is slightly more involved
g1 :α ,D 1
g2 :α ,D 2
′
ℓ 1 →1 ℓ 1 ∧ ℓ 2 →2 ℓ ′2
g1 ∧ g2 :α ,D 1 ∪D 2
⟨ℓ 1, ℓ 2⟩ → ⟨ℓ ′1, ℓ ′2⟩
• Note that a conjunction of constraints is still a
valid constraint
g:α ,D
g:α ,D
′
′
ℓ
→
ℓ
ℓ
→
ℓ
1 invariant
1 1of a composite state
2
2 the
2
• The
is also
and
g:α ,D
g:α ,D
′
⟨ℓ 1conjunction
, ℓ 2⟩ → of
⟨ℓ 1 ,both
ℓ 2⟩ invariants
⟨ℓ 1, ℓ 2⟩ → ⟨ℓ 1, ℓ ′2⟩
 Again, still a valid constraint. This will be
important later on.
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 20
Semantics
• The semantics of a TA are given by
 current discrete state (also called location)
 clock values
• This is now an infinite state machine!
 Worse, uncountably infinite!
• The trace semantics of a TA are successions
of <action,clock valuation>
• The branching semantics is an infinitely
branching tree
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 21
Transitions
• There exist then two types of transitions
• Location transitions, where location changes
through an action label
 location transitions take zero time
• Delay transitions, where clocks advance a
time d, remaining in the same location
 ...as long as the location invariant holds
• The elapsed time of a trace (or trace
fragment) is the sum of all its delays
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 22
Semantics
• The trace semantics of a TA are successions
of <location,clock valuation>
• The branching semantics is an infinitely
branching tree of <location,clock valuation>
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 23
Semantics
omat aConsider the simple example of a light switch
x
1
switch off
off
x
on
2
switch on
reset (x)
9.11: A simple
light
ch.
Can Figure
you describe
some of
itsswit
traces?
Can you describe all reachable states?
ion syst em T S(Switch) has t he st at e space
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 24
Deadlock was bad enough? Timelock and other issues
• The addition of time and clocks causes some
traces to not be acceptable
689
x
1
switch off
off
x
on
2
switch on
reset (x)
Figure 9.11: A simple light swit ch.
S(Switch) has t he st at e space
Any fragment of this trace (even infinite!) take a finite amount of time...
{ ⟨off , t ⟩ | t ∈ IR
0}
∪ { ⟨on, t ⟩ | t ∈ IR
0}
or t he clock evaluat ion η wit h η(x) = t. Uncount ably many
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 25
Time convergence and divergence
• An infinite trace fragment is said to be time
divergent if its elapsed time is infinite
• On the contrary, an infinite path fragment
with finite elapsed time is said to be time
convergent
• Time convergent traces are unrealistic, and
therefore we do not consider them
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 26
Timelock
• A state from
which no
divergent traces
originate is said to
be in timelock
• In timelock, time either cannot carry on
• Or, it can do so only up to a bound
• If no traces can escape this bound, the state
is
unrealistic
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 27
Timelock
1
x< 2
693
switch off
off
1
x< 2
switch off
off
switch on
x
on
2
switch on
reset (x)
on
x 2
Figure 9.12: T imed aut omaton Switch1 .
reset (x)
1
Figure 9.12: T imed aut omaton Switch1 .
1
off
switch on
switch off
off
x< 2
switch off
x< 2
on
x< 3
switch on
on
reset (x)
x< 3
Figure 9.13: T imed aut omaton Switch2 .
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 28
Zenoness
• An execution trace is said to be zeno if
 It is time convergent, and
 It contains an infinite number of location
Aut omattransitions,
a
that is, infinite actions are taken in a
finite time
x
1 : switch off
off
x
on
2
switch on
reset (x)
switch on
reset (x)
Figure 9.14: T imed aut omaton Switch3 .
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 29
Zenoness
• A timed automaton is said to be zeno if it
contains at least one zeno trace from its initial
state
• Zeno automata are unrealistic – they require
an infinitely fast processor!
• Zeno automata are a design flaw. We need
only non-zeno automata
• Checking for non-zenoness is hard
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 30
(Approximate) non-zeno check
• Instead, it is easy to check for sufficient conditions for non•
•
zenoness
It suffices to check that in every control cycle (location cycle),
time increases
Formally, for every control cycle there exists a clock x such
that
 x is reset in the cycle
 For every clock valuation v, a natural number c and a position j in the
cycle exist such that if v(x) < c, then either
- the location invariant at j is not satisfied; or
- the guard for the transition at j is not satisfied
 that is, at point j the clock x must be larger than c
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 31
on
switch on
reset (x)
(Approximate)
non-zeno check
switch on
off
x
2
reset (x)
Figure 9.14: T imed aut omaton Switch3 .
x
100 : switch off
off
x
on
200
x
1 : switch on
reset (x)
switch on
reset (x)
Figure
T imed aut omaton
• The condition
is 9.15:
also compositional
. Switch4.
• If two TAs A and B satisfy the condition, then their
or c > composition
0. Note t hat A||B
c should
a nat
ural number.
In order t o model a mini
will be
also
satisfy
it
1
e 0 < c < 1 where c is rat ional, say c = 100
all t ime const raint s in t he t im
• Exercise: check the condition on the, Train,
Gate and
on Switch3 need t o be rescaled (see Figure 9.15). Essent ially, t he t imed aut oma
Controller models
comput es wit h a modified t ime unit : one t ime unit for x in Switch4 correspo
minut
Slide 32
H. es.
Schlingloff, E. Pavese SS2017: Software-Verifikation
Timed CTL
• In order to reason about TAs we use the logic
TCTL
• TCTL is an extension of CTL
• We change the U operator by enriching it with
a time interval – UI
• A path satisfies
if is true along the
path, until becomes true and, additionally, it
takes a time t I for the latter to be true
H. Schlingloff, E. Pavese SS2017: Software-Verifikation
Slide 33