0% found this document useful (0 votes)
9 views59 pages

5 TA Modelling

The document discusses the importance of timing in real-time systems, emphasizing that correctness depends not only on logical outcomes but also on timing constraints. It introduces timed automata as a formalism for modeling time-critical systems, detailing their structure, semantics, and the use of tools like UPPAAL for verification. The document also covers various examples and applications of timed automata in real-world scenarios.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views59 pages

5 TA Modelling

The document discusses the importance of timing in real-time systems, emphasizing that correctness depends not only on logical outcomes but also on timing constraints. It introduces timed automata as a formalism for modeling time-critical systems, detailing their structure, semantics, and the use of tools like UPPAAL for verification. The document also covers various examples and applications of timed automata in real-world scenarios.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 59

5.

Real-time models: Timed Automata

José Proença
System Verification (CC4084) 2024/2025
CISTER – U.Porto, Porto, Portugal https://fm-dcc.github.io/sv2425
Motivation
Motivation

Specifying an airbag saying that in a car crash the airbag eventually inflates maybe not enough,
but:

in a car crash the airbag eventually inflates within 20ms

Correctness in time-critical systems not only depends on the logical result of the com-
putation, but also on the time at which the results are produced

[Baier & Katoen, 2008]

System Verification 2024/25 @ FCUP Motivation 2 / 48


Examples of time-critical systems

Lip-synchronization protocol
Synchronizes the separate video and audio sources bounding on the amount of time
mediating the presentation of a video frame and the corresponding audio frame. Humans
tolerate less than 160 ms.

Bounded retransmission protocol


Controls communication of large files over infrared channel between a remote control unit
and a video/audio equipment. Correctness depends crucially on
• transmission and synchronization delays
• time-out values for times at sender and receiver

And many others...


• medical instruments
• hybrid systems (eg for controlling industrial plants)
System Verification 2024/25 @ FCUP Motivation 3 / 48
Syllabus

• Introduction to model-checking • Timed Automata


• CCS: a simple language for • Syntax
concurrency • Semantics (composition, Zeno)
• Syntax • Equivalence
• Semantics • UPPAAL: modelling
• Equivalence • Temporal logics (LTL/CTL)
• mCRL2: modelling • Syntax
• Dynamic logic • Semantics
• Syntax • UPPAAL: verification
• Semantics • Probabilistic and stochastic systems
• Relation with equivalence • Going probabilistic
• mCRL2: verification • UPPAAL: monte-carlo

System Verification 2024/25 @ FCUP Motivation 4 / 48


Table of contents

1. Motivation

2. Timed Automata

3. Semantics

4. Modelling in Uppaal

System Verification 2024/25 @ FCUP Motivation 5 / 48


Motivation

• timed transition systems, timed Petri nets, timed IO automata, timed process algebras
and other formalisms associate lower and upper bounds to transitions, but no time
constraints to transverse the automaton.
• Expressive power is often somehow limited and infinite-state LTS (introduced to express
dense time models) are difficult to handle in practice

System Verification 2024/25 @ FCUP Motivation 6 / 48


Motivation

Example
Typical process algebra tools are unable to express a system which has one action a which
can only occur at time point 5 with the effect of moving the system to its initial state.

This example has, however, a simple description in terms of time measured by a stopwatch:

1. Set the stopwatch to 0


2. When the stopwatch measures 5, action a can occur. If a occurs go to 1., if not idle
forever.

System Verification 2024/25 @ FCUP Motivation 7 / 48


Motivation

This suggests resorting to an automaton-based formalism with an explicit notion of clock


(stopwatch) to control availability of transitions.

Timed Automata [Alur & Dill, 90]

• emphasis on decidability of the reachability problem and corresponding practically efficient


algorithms
• infinite underlying timed transition systems are converted to finitely large symbolic
transition systems where reachability becomes decidable (region or zone graphs)

Associated tools

• Uppaal [Behrmann, David, Larsen, 04] • Prism [Parker, Kwiatkowska, 00]


• Imitator [André, 09] • Kronos [Bozga, 98]
System Verification 2024/25 @ FCUP Motivation 8 / 48
Motivation

UPPAAL = (Uppsala University + Aalborg University) [1995]

• A toolbox for modeling, simulation and verification of real-time systems


• where systems are modeled as networks of timed automata enriched with integer
variables, structured data types, channel syncronisations and urgency annotations
• Properties are specified in a subset of CTL

www.uppaal.org

System Verification 2024/25 @ FCUP Motivation 9 / 48


Timed Automata
Timed automata

Finite-state machine equipped with a finite set of real-valued clock variables (clocks)

Clocks

• dense-time model
• clocks can only be inspected or
• reset to zero, after which they start increasing their value implicitly as time progresses
• the value of a clock corresponds to time elapsed since its last reset
• all clocks proceed synchronously (at the same rate)

System Verification 2024/25 @ FCUP Timed Automata 10 / 48


Timed automata Definition

⟨L, L0 , Act, C, Tr, Inv⟩


where
• L is a set of locations, and L0 ⊆ L the set of initial locations
• Act is a set of actions and C a set of clocks
• Tr ⊆ L × C(C ) × Act × P(C ) × L is the transition relation
g,a,U
ℓ1 −−−! ℓ2

denotes a transition from location ℓ1 to ℓ2 , labelled by a, enabled if guard g is valid,


which, when performed, resets the set U of clocks
• Inv : L −! C(C ) is the assignment of invariants to locations

where C(C ) denotes the set of clock constraints over a set C of clock variables
System Verification 2024/25 @ FCUP Timed Automata 11 / 48
Example: the lamp interrupt

(extracted from Uppaal)

Lamp Lamp Lamp

Ex. 5.1: Define ⟨L, L0 , Act, C , Tr , Inv ⟩.

System Verification 2024/25 @ FCUP Timed Automata 12 / 48


Clock constraints

C(C ) denotes the set of clock constraints over a set C of clock variables. Each constraint is
formed according to
g ::= x □ n | x − y □ n | g ∧ g | true
where x , y ∈ C , n ∈ N and □ ∈ {<, ≤, >, ≥, =}
used in

• transitions as guards (enabling conditions)


a transition cannot occur if its guard is invalid
• locations as invariants (safety specifications)
a location must be left before its invariant becomes invalid

Note
Invariants are the only way to force transitions to occur

System Verification 2024/25 @ FCUP Timed Automata 13 / 48


Guards, updates & invariants

System Verification 2024/25 @ FCUP Timed Automata 14 / 48


Transition guards & location invariants

Demo (in Uppaal)


Process 1 Process 2 Process 3

System Verification 2024/25 @ FCUP Timed Automata 15 / 48


Parallel composition of timed automata

• Action labels as channel identifiers


• Communication by forced handshacking over a subset of common actions
• Is defined as an automaton construction over a finite set of timed automata originating a
so-called network of timed automata

System Verification 2024/25 @ FCUP Timed Automata 16 / 48


Parallel composition of timed automata

Let H ⊆ (Act1 ∩ Act2 ) − {τ }. The parallel composition of ta1 and ta2 synchronizing on H is
the timed automata

ta1 ∥H ta2 := ⟨L1 × L2 , L0,1 × L0,2 , Act∥H , C1 ∪ C2 , Tr∥H , Inv∥H ⟩

where

• Act∥H = ((Act1 ∪ Act2 ) − H) ∪ {τ }


• Inv∥H ⟨ℓ1 , ℓ2 ⟩ = Inv1 (ℓ1 ) ∧ Inv2 (ℓ2 )
• Tr∥H is given by:
g,a,U g,a,U
• ⟨ℓ1 , ℓ2 ⟩ −−−! ⟨ℓ′1 , ℓ2 ⟩ if a ̸∈ H ∧ ℓ1 −−−! ℓ′1
g,a,U g,a,U
• ⟨ℓ1 , ℓ2 ⟩ −−−! ⟨ℓ1 , ℓ′2 ⟩ if a ̸∈ H ∧ ℓ2 −−−! ℓ′2
g,τ,U g1 ,a,U1 g2 ,a,U2
• ⟨ℓ1 , ℓ2 ⟩ −−−! ⟨ℓ′1 , ℓ′2 ⟩ if a ∈ H ∧ ℓ1 −−−−! ℓ′1 ∧ ℓ2 −−−−! ℓ′2
with g = g1 ∧ g2 and U = U1 ∪ U2
System Verification 2024/25 @ FCUP Timed Automata 17 / 48
Example: the lamp interrupt as a closed system

Lamp Lamp Lamp

Uppaal:
• takes H = Act1 ∩ Act2 (actually as
complementary actions denoted by the ?
and ! annotations)

User
UserUser • only deals with closed systems

Ex. 5.2: Define the TA of the composition.

System Verification 2024/25 @ FCUP Timed Automata 18 / 48


Exercise: worker, hammer, nail

Worker
Worker Worker
Ex. 5.3: Define the TA of the composition.

Hammer
HammerHammer

Nail Nail Nail

System Verification 2024/25 @ FCUP Timed Automata 19 / 48


Semantics
Timed Labelled Transition Systems

Syntax Semantics
(How to write) (How to execute)
Process Languages LTS (Labelled Transition Systems)
Timed Automaton TLTS (Timed LTS)

System Verification 2024/25 @ FCUP Semantics 20 / 48


Timed Labelled Transition Systems

Syntax Semantics
(How to write) (How to execute)
Process Languages LTS (Labelled Transition Systems)
Timed Automaton TLTS (Timed LTS)

Timed LTS
Introduce delay transitions to capture the passage of time within a LTS:
a
s−
! s ′ for a ∈ Act, are ordinary transitions due to action occurrence
d
s−
! s ′ for d ∈ R0+ , are delay transitions

subject to a number of constraints, eg,

System Verification 2024/25 @ FCUP Semantics 20 / 48


Dealing with time in system models

Timed LTS
• time additivity
d d′ d−d ′
(s −
! s ′ ∧ 0 ≤ d ′ ≤ d) ⇒ s −! s ′′ −−−! s ′ for some state s ′′

• delay transitions are deterministic


d d
(s −
! s′ ∧ s −
! s ′′ ) ⇒ s ′ = s ′′

System Verification 2024/25 @ FCUP Semantics 21 / 48


Semantics of Timed Automata

Semantics of TA:
Every TA ta defines a TLTS
T (ta)
whose states are pairs
⟨location, clock valuation⟩
with infinitely, even uncountably many states, and infinite branching

System Verification 2024/25 @ FCUP Semantics 22 / 48


Clock valuations

Definition
A clock valuation η for a set of clocks C is a function

η : C −! R+
0

assigning to each clock x ∈ C its current value η x .

Satisfaction of clock constraints

η |= x □ n ⇔ η x □ n
η |= x − y □ n ⇔ (η x − η y ) □ n
η |= g1 ∧ g2 ⇔ η |= g1 ∧ η |= g2

System Verification 2024/25 @ FCUP Semantics 23 / 48


Operations on clock valuations

Delay
For each d ∈ R+
0 , valuation η + d is given by

(η + d) x = η x + d

Reset
For each R ⊆ C , valuation η[R] is given by
(
η[R] x = η x ⇐ x ̸∈ R
η[R] x = 0 ⇐x ∈R

System Verification 2024/25 @ FCUP Semantics 24 / 48


From ta to T (ta)

Let ta = ⟨L, L0 , Act, C , Tr , Inv ⟩

T (ta) = ⟨S, S0 ⊆ S, N, T ⟩

where

• S = {⟨l, η⟩ ∈ L × (R+ C
0 ) | η |= Inv (l)}

• S0 = {⟨ℓ0 , η⟩ | ℓ0 ∈ L0 ∧ η x = 0 for all x ∈ C }


• N = Act ∪ R+
0 (ie, transitions can be labelled by actions or delays)

• T ⊆ S × N × S is given by:

a
⟨l, η⟩ −
! ⟨l ′ , η ′ ⟩ ⇐ ∃ η |= g ∧ η ′ = η[U] ∧ η ′ |= Inv (l ′ )
l −−−!l ′ ∈Tr
g,a,U

d
⟨l, η⟩ −
! ⟨l, η + d⟩ ⇐ ∃d∈R+0 η + d |= Inv (l)

System Verification 2024/25 @ FCUP Semantics 25 / 48


Example: the simple switch

Switch Switch Switch

Ex. 5.4: Define T (SwitchA)

S=

System Verification 2024/25 @ FCUP Semantics 26 / 48


Example: the simple switch

Switch Switch Switch

Ex. 5.4: Define T (SwitchA)

S = {⟨off , t⟩ | t ∈ R+
0 } ∪ {⟨on, t⟩ | 0 ≤ t ≤ 2}

where t is a shorthand for η such that η x = t

System Verification 2024/25 @ FCUP Semantics 26 / 48


Example: the simple switch

Switch Switch Switch

Ex. 5.4: Define T (SwitchA)

T = ...

System Verification 2024/25 @ FCUP Semantics 27 / 48


Example: the simple switch

Switch Switch Switch

Ex. 5.4: Define T (SwitchA)


d
⟨off , t⟩ −
! ⟨off , t + d⟩ for all t, d ≥ 0
in
⟨off , t⟩ −
! ⟨on, 0⟩ for all t ≥ 0
d
⟨on, t⟩ −
! ⟨on, t + d⟩ for all t, d ≥ 0 and t + d ≤ 2
out
⟨on, t⟩ −−! ⟨off , t⟩ for all 1 ≤ t ≤ 2

System Verification 2024/25 @ FCUP Semantics 27 / 48


Note

• The elapse of time in timed automata only takes place in locations:


• ... actions take place instantaneously
• Thus, several actions may take place at a single time unit

System Verification 2024/25 @ FCUP Semantics 28 / 48


Behaviours

• Paths in T (ta) are discrete representations of continuous-time behaviours in ta


• ... at least they indicate the states immediately before and after the execution of an action
• However, as interval delays may be realised in uncountably many different ways, different
paths may represent the same behaviour

System Verification 2024/25 @ FCUP Semantics 29 / 48


Behaviours

• Paths in T (ta) are discrete representations of continuous-time behaviours in ta


• ... at least they indicate the states immediately before and after the execution of an action
• However, as interval delays may be realised in uncountably many different ways, different
paths may represent the same behaviour
• ... but not all paths correspond to valid (realistic) behaviours:

undesirable paths:
• time-convergent paths
• timelock paths
• zeno paths

System Verification 2024/25 @ FCUP Semantics 29 / 48


Time-convergent paths

d d d d
⟨l, η⟩ −!
1
⟨l, η + d1 ⟩ −!
2
⟨l, η + d1 + d2 ⟩ −!
3
⟨l, η + d1 + d2 + d3 ⟩ −!
4
···
such that X
∀i∈N . di > 0 ∧ di = d
i∈N

ie, the infinite sequence of delays converges toward d

• Time-convergent path are counterintuitive; as their existence cannot be avoided, they are
simply ignored in the semantics of Timed Automata
• Time-divergent paths are the ones in which time always progresses

System Verification 2024/25 @ FCUP Semantics 30 / 48


Time-convergent paths

Definition
δ δ
An infinite path fragment ρ = s0 −!
0
s1 −!
1
. . . is time-divergent if ExecTime(ρ) = ∞
Otherwise is time-convergent.

where
X
ExecTime(ρ) = ExecTime(δi )
i=0..∞
(
0 ⇐ δ ∈ Act
ExecTime(δ) =
δ ⇐ δ ∈ R+
0

for ρ a path and δ a label in T (ta)

System Verification 2024/25 @ FCUP Semantics 31 / 48


Timelock paths

Definition
A path is timelock if it contains a state with a timelock, ie, a state from which there is not
any time-divergent path

A timelock represents a situation that causes time progress to halt (e.g. when it is impossible
to leave a location before its invariant becomes invalid)

• any terminal state (̸= terminal location) in T (ta) contains a timelock


• ... but not all timelocks arise as terminal states in T (ta)

System Verification 2024/25 @ FCUP Semantics 32 / 48


Timelock paths

Terminal Terminal Terminal

State ⟨on, 2⟩ . . .

System Verification 2024/25 @ FCUP Semantics 33 / 48


Timelock paths

Terminal Terminal Terminal

State ⟨on, 2⟩ is reachable through path


s−on 2
⟨off , 0⟩ −−−! ⟨on, 0⟩ −
! ⟨on, 2⟩

and is terminal

System Verification 2024/25 @ FCUP Semantics 33 / 48


Timelock paths

Timelock
Timelock
Timelock
- NotTerminal
- NotTerminal
- NotTerminal

State ⟨on, 2⟩ . . .

System Verification 2024/25 @ FCUP Semantics 34 / 48


Timelock paths

Timelock
Timelock
Timelock
- NotTerminal
- NotTerminal
- NotTerminal

State ⟨on, 2⟩ is not terminal but has a convergent path:

⟨on, 2⟩⟨on, 2.9⟩⟨on, 2.99⟩⟨on, 2.999⟩...

System Verification 2024/25 @ FCUP Semantics 34 / 48


Zeno

In a Timed Automaton
• The elapse of time only takes place at locations
• Actions occur instantaneously: at a single time instant several actions may take place

... it may perform infinitely many actions in a finite time interval


(non realizable because it would require infinitely fast processors)

System Verification 2024/25 @ FCUP Semantics 35 / 48


Zeno

In a Timed Automaton
• The elapse of time only takes place at locations
• Actions occur instantaneously: at a single time instant several actions may take place

... it may perform infinitely many actions in a finite time interval


(non realizable because it would require infinitely fast processors)

Definition
An infinite path fragment ρ is zeno if it is time-convergent and infinitely many actions occur
along it
A timed automaton ta is non-zeno if there is not an initial zeno path in T (ta)

System Verification 2024/25 @ FCUP Semantics 35 / 48


Zeno

Example
Suppose the user can press the in button when the light is on in

Zeno Zeno Zeno

In doing so clock x is reset to 0 and light stays on for more 2 time units (unless the button is
pushed again ...)

System Verification 2024/25 @ FCUP Semantics 36 / 48


Zeno

Example
Typical paths: The user presses in infinitely fast:
in in in in in
⟨off , 0⟩ −
! ⟨on, 0⟩ −
! ⟨on, 0⟩ −
! ⟨on, 0⟩ −
! ⟨on, 0⟩ −
! ···

The user presses in faster and faster:


in 0.5 in 0.25 in 0.125
⟨off , 0⟩ −
! ⟨on, 0⟩ −−! ⟨on, 0.5⟩ −
! ⟨on, 0⟩ −−! ⟨on, 0.25⟩ −
! ⟨on, 0⟩ −−−! · · ·

How can this be fixed?

Time shall pass!

System Verification 2024/25 @ FCUP Semantics 37 / 48


Exercise

Ex. 5.5: Recall our lamp


Lamp Lamp Lamp

y<=3600

1. Describe a time-divergent path, if it exists.


2. Describe a time-convergent path, if it exists.
3. Describe a timelock path, if it exists.
4. Is this automata non-zeno? Justify.

System Verification 2024/25 @ FCUP Semantics 38 / 48


Zeno

Sufficient criterion for nonzenoness


A timed automaton is nonzeno if on any of its control cycles time advances with at least
some constant amount (≥ 0). Formally, if for every control cycle
g0 ,a0 ,U0 g1 ,a1 ,U1 gn ,an ,Un
ℓ0 −−−−−! ℓ1 −−−−−! · · · −−−−−! ℓ0

there exists a clock x ∈ C such that

1. x ∈ Ui (for 0 ≤ i ≤ n)
2. for all clock valuations η, there is a c ∈ N>0 such that

η(x ) < c ⇒ ((η ̸|= gj ) ∨ ¬Inv (ℓj )) for some 0 ≤ j ≤ n

System Verification 2024/25 @ FCUP Semantics 39 / 48


Warning

Both

• timelocks
• zenoness

are modelling flaws and need to be avoided.


Example
In the example above, it is enough to impose a non zero minimal delay between successive
button pushings.

System Verification 2024/25 @ FCUP Semantics 40 / 48


Modelling in Uppaal
Uppaal

... an editor, simulator and model-checker for TA with extensions ...


Editor.
• Templates and instantiations
• Global and local declarations
• System definition

Simulator.
• Viewers: automata animator and message sequence chart
• Control (eg, trace management)
• Variable view: shows values of the integer variables and the clock constraints defining
symbolic states

Verifier.
• (see next session)
System Verification 2024/25 @ FCUP Modelling in Uppaal 41 / 48
Extensions (modelling view)

• templates with parameters and an instantiation mechanism


• data expressions over bounded integer variables (eg, int[2..45] x) allowed in guards,
assigments and invariants
• rich set of operators over integer and booleans, including bitwise operations, arrays,
initializers ... in general a whole subset of C is available
• non-standard types of synchronization
• non-standard types of locations

System Verification 2024/25 @ FCUP Modelling in Uppaal 42 / 48


Extension: broadcast synchronization

• A sender can synchronize with an arbitrary number of receivers


• Any receiver than can synchronize in the current state must do so
• Broadcast sending is never blocking (the send action can occur even with no receivers).

System Verification 2024/25 @ FCUP Modelling in Uppaal 43 / 48


Extension: urgent synchronization

Channel a is declared urgent chan a if both edges are to be


taken as soon as they are ready (simultaneously in locations ℓ1
and s1 ).
Note the problem can not be solved with invariants because
locations ℓ1 and s1 can be reached at different moments
• No delay allowed if a synchronization transition on an urgent
channel is enabled
• Edges using urgent channels for synchronization cannot have
time constraints (ie, clock guards)

System Verification 2024/25 @ FCUP Modelling in Uppaal 44 / 48


Extension: urgent location

• Time does not progress but interleaving with normal location


is allowed
• Both models are equivalent: no delay at an urgent location
• but the use of urgent locations reduces the number of clocks
in a model and simplifies analysis

System Verification 2024/25 @ FCUP Modelling in Uppaal 45 / 48


Extension: committed location

• delay is not allowed and the committed transition must be


left in the next instant (or one of them if there are several),
i.e., next transition must involve an outgoing edge of at least
one of the committed locations
• Our aim is to pass the value k to variable j (via global
variable t)
• Location n is committed to ensure that no other automata
can assign j before the assignment j := t

System Verification 2024/25 @ FCUP Modelling in Uppaal 46 / 48


The train-gate example

Train(id) Train(id) Train(id)

• Events model approach/leave, order to stop/go


• A train cannot be stopped or restart instantly
• After approaching it has 10m to receive a stop.
• After that it takes further 10m to reach the cross
• After restarting takes 7 to 15m to reach the cross and
3-5m to cross

System Verification 2024/25 @ FCUP Modelling in Uppaal 47 / 48


The train-gate example

Gate Gate Gate

• Note the use of parameters and the select clause on transitions


• C-like program under the hood
System Verification 2024/25 @ FCUP Modelling in Uppaal 48 / 48

You might also like