System Design&Methodologies
Fö 7- 1
Timed & Hybrid Automata
System Design&Methodologies
Fö 7- 2
Restrictions/Assumptions with synchronous FSMs
• FSMs react to inputs and generate, as response, outputs.
1. Restrictions of the synchronous FSM model
• The inputs are either present or absent; when inputs are present,
the FSM reacts and generates outputs.
2. Timed automata
• Between the time instants when inputs are present, nothing
interesting occurs; at each instant when inputs occur, a reaction
(outputs) is computed instantly by the FSM.
3. Timed automata as a particular case of hybrid automata
• FSMs operate in a sequence of discrete reactions.
4. Hybrid automata
• The clock can be explicitly modelled as a FSM delivering ticks for
the whole system; all transitions in the system are synchronised
on this clock tick. Time (non-negative integer) is captured counting
these clock ticks  discrete time model.
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 3
System Design&Methodologies
Example FSM: Thermostat
• Input event {temperature}
- Signal temperature is received
at certain instants of time from
a sensor;
- When input temperature is
received and the guard on the
transition is true, the system
generates an output.
• Outputs {heat_on, heat_off}
• States {S0, S1}
- S0: system cools (heating off)
- S1: system is heating
Petru Eles, IDA, LiTH
Fö 7- 4
Timed Automata
☞ For modeling real-time asynchronous systems, continuous time
models are the natural representation.
initial state
temperature≤18/heat_on
S0
S1
temperature≥22/heat_off
☞ We want to keep the temperature
close to 20°;
☞ To avoid chattering (turning on and
off rapidly, all the time), we allow
the temperature to be inside a
band (technique called hysteresis).
☞ Real-time systems require measuring the passage of (continuous)
time and performing actions at specific times.
☞ In timed automata time is considered a continuous quantity. No
global synchronisation, in the sense of a unique clock, is assumed.
☞ Timed automata are an extension of the FSM model which allows
modelling of certain real-time systems and formal reasoning.
• A timed automaton is a finite automaton (similar to a FSM)
augmented with a finite set of real-valued clocks.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 5
System Design&Methodologies
Example: Thermostat with Timed Automata
Fö 7- 6
Example: Thermostat with Timed Automata (cont’d)
A simulation of the timed automata model of the thermostat:
initial state
x:=
• Outputs {heat_on, heat_off}
• States {S0, S1}
- S0: system cools (heating off)
- S1: system is heating
input
S1
S0
20
0
on
off
on
0
on
time
t
time
t
x
T
0
Petru Eles, IDA, LiTH
Fö 7- 7
System Design&Methodologies
Example: Gate Control System with Timed Automata
Example: Gate Control System with Timed Automata (cont’d)
Train
Specification:
x<5
S0 app!, x:=0
out!, x≤5
• When the train approaches, it sends signal app at least 2 minutes
before it enters the crossing; after leaving the crossing it sends the
signal out; it leaves the crossing maximum 5 minutes after
signalling app.
2
S2
• When the controller gets signal app it closes the gate, which takes
at least 1 minute, but less than 2; then it waits for signal out; when
out arrives it opens the gate within maximum 1 minute.
Fö 7- 8
x≤5
≤
x
<
5
S1
R0
Gate controller
x, y: clocks
app?, y:=0
S0: train far away
S1: train approaching
S2: train crossing
opened!, y≤1
Petru Eles, IDA, LiTH
System Design&Methodologies
off
output
We use a single temperature threshold - the desired level of 20°;
To avoid chattering, the heater has to remain on/off for a minimum
required time T.
Petru Eles, IDA, LiTH
t
time
temperature≥20 & x≥Τ, heat_off!, x:=0
clock
☞
temperature≤20 & x≥Τ, heat_on!, x:=0
T
y≤1 R3
R1 y<2
closed!,1≤y<2
• Input {temperature}
temperature
• Clock x
out?, y:=0
R2
R0: controller waiting
R1: train approaching
R2: gate is down
R3: train has left
☞ Once the above model is realised, one can formally verify (e.g. using
model checking tools) properties such as: the train will only be in
state S2 (crossing) when, simultaneously, the gate is in R2 (down).
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 9
System Design&Methodologies
Timed Automata: Rules/Properties
Timed Automata: Rules/Properties (cont’d)
• Transitions are instantaneous; time elapses when the automaton
is in a certain state.
• When a transition occurs, some of the clocks can be reset; at any
moment, the value of a clock is equal to the time elapsed since the
last time it has been reset.
• Time passes at the same rate for all clocks.
• When a transition occurs, signals (events) can be generated.
• Transitions can have associated guards expressed as conditions
on clock values; the transition can be taken only if the current
values of the clocks satisfy the guard.
• Transitions can have input signals (events) associated; when the
signal arrives and the associated guard is satisfied, the transition
will be taken.
• States can have associated invariants, expressed as conditions
on the clocks; the automaton can stay in that state only as long as
the invariant is true.
Petru Eles, IDA, LiTH
☞ Like FSMs, timed automata can be extended with variables.
• Actions on variables can be associated to transitions.
• Guards expressed as conditions on the variables can be
associated to transitions
☞ Timed automata are, by definition, infinite state models: At any time
moment, the state of the system is defined not only by the actual
state in the state machine (e.g. S0, S1, etc.), but also by the current
values of the clocks!
However, for verification, timed automata admit finite state
representations (by exploiting equivalence relations on certain
portions of the state space)!
• Model checking techniques can be used to prove properties of
timed automata.
• The state explosion problem is more severe than for
synchronous concurrent FSMs!
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 11
System Design&Methodologies
Hybrid Automata
☞
Fö 7- 10
Fö 7- 12
The Thermostat as a Hybrid Automaton
initial state
Timed automata are FSMs with addition of clocks.
x:=
☞
A clock is a continuous variable whose value can be described by
the differential equation: x· (t) = 1 .
☞
Timed automata are, in fact, the simplest form of hybrid automata.
☞
Hybrid automata are FSMs combined with a finite set of
continuous variables whose values are described by a set of
ordinary differential equations.
Petru Eles, IDA, LiTH
temperature≤20 & x(t)≥Τ, heat_on!, x(t):=0
T
S0
x· (t) = 1
S1
x· (t) = 1
temperature≥20 & x(t)≥Τ, heat_off!, x(t):=0
☞
In the above model, the equation describing the continuous
variable representing clock x is made explicit. This model is
completely equivalent with the one on slide 5.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 13
System Design&Methodologies
Fö 7- 14
Hybrid Automata: Rules/Properties
Example: Water Tank
• A Hybrid Automaton associates with each state of an FSM a
dynamic behavior.
ρ
• Each tank is leaking at constant
rate r1 (r2).
• Water is added at a constant rate ρ.
• One tank is filled at a time; filling
switches from one tank to the other
in zero time.
• The goal is to keep the water
volume above v1 and v2
respectively.
• The current water volume is x1 (x2).
• The dynamic behavior in each state is specified by a state
refinement; a state refinement describes the dynamic behavior of
the outputs (and other additional continuous state variables) as a
function of the inputs (and possible state variables).
• State refinements are specified as ordinary differential equations.
• Transitions can have associated guards, assignments to variables,
outputs, etc.
v1
r1
r2
• Hybrid automata are extremely strong in their expressive power;
they combine discrete and continuous behavior in one single
model.
Petru Eles, IDA, LiTH
x1
x2
v2
Petru Eles, IDA, LiTH
Fö 7- 15
System Design&Methodologies
Fö 7- 16
Example: Water Tank (cont’d)
&x
• Outputs {fill1, fill2}
2 (0)
x2(t) ≤ v2, fill2!
≥v
2
S1
S2
x· 1(t) = ρ – r 1
x· (t) = – r
2
x· 1(t) = – r 1
x· 2(t) = ρ – r 2
2
x1(t) ≤ v1, fill1!
0.8
Ta
nk
_2
The system above might reach a situation (when the water level
comes very close to the target) in which the number of switches
per time unit is continuously increasing (Zeno system).
Petru Eles, IDA, LiTH
This is a simulation considering:
• Leaking rates: r1=r2= 0.5
• Water inflow rate: ρ= 0.75
• Keep the water above v1=v2=0
• Initial level: x1(0)=0, x2(0)=1
Ta
nk
_1
0.6
0.4
0.2
0
1
2
3
4
...
time
fill2
• States {S1, S2}
- S1: tank 1 is filled
- S2: tank 2 is filled
1.0
0
Petru Eles, IDA, LiTH
time
fill2
fill1
v1
• Inputs {x1, x2}
☞
Example: Water Tank (cont’d)
initial state
volume
x1 (
0)≥
fill1
System Design&Methodologies
☞ Since ρ < r1+r2, both tanks will,
eventually, become empty.
☞ As the tanks come close to the 0
level, the number of switches per
time unit increases.
☞ With such a Hybrid Automata
model, one can use formal
verification to answer questions
like: will tank_1 become empty
before time 7? You cannot ask
this with a simple timed automata
t
model (since the flow equations
are not part of the model).
System Design&Methodologies
Fö 7- 17
System Design&Methodologies
Hybrid Automata: Final Comments
Example: Water Tank (cont’d)
☞
x1 (
In order to avoid Zeno behaviour one possible solution is to
introduce intermediate states in which the system spends an
amount of time τ (no tank is filled in that interval).
initial state
0)≥
v
1
&x
2 (0)
t)
x 2(
, s(
≤ v2
S3
)≥
x· 1(t) = – r 1
x· 2(t) = – r 2
s·(t) = 1
≥v
2
S1
x· 1(t) = ρ – r 1
x· 2(t) = – r 2
s(t)
≥
s (t
0
t):=
τ , fi
ll1 !
S4
x· 1(t) = – r 1
x· 2(t) = – r 2
s·(t) = 1
☞ Hybrid automata models can be used for simulation and formal
verification.
τ, f
ill
2!
S2
x· 1(t) = – r 1
·x (t) = ρ – r
2
2
t)
x 1(
,
≤ v1
s(t
) :=
0
Petru Eles, IDA, LiTH
☞ Hybrid automata, like timed automata, are, by definition, infinite
state models. However, they admit a finite state representation (by
exploiting equivalence relations on certain portions of the state
space)!
• Model checking techniques can be used to prove properties of
hybrid automata.
• The state explosion problem is more severe than for timed
automata!
☞
Available frameworks/tools: Ptolemy II, HyTech.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 19
System Design&Methodologies
• It depends on what you intend to do with the model:
- simulation
- formal verification
- automatic synthesis
- -----------------• It depends on what tools you have available and which approach
you (or your company or your boss!) prefer.
Fö 7- 20
What Modeling Approach to Choose?
What Modeling Approach to Choose?
• It depends on the characteristics of the system:
- control or data flow dominated (e.g. DSP application or
reactive system);
- synchronous or asynchronous; centralised or distributed;
- how large?
- what aspects related to timing are we interested in?
- ------------------
Petru Eles, IDA, LiTH
Fö 7- 18
☞ Don’t use the “strongest”! Go for exactly that expressive power you
need; not more.
Remember Fö 3, slide 9:
• Large expressive power: imperative model (e.g. unrestricted
use of C or Java):
- Can specify “anything”.
- No formal reasoning possible (or extremely complex).
• Limited expressive power, based on well chosen computation
model (e.g. Esterel):
- Only particular systems can be specified.
- Formal reasoning is possible.
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 21
System Design&Methodologies
Fö 7- 22
Modeling Languages
What Modeling Approach to Choose?
Large embedded systems are heterogeneous  mixture of models:
Specification
imperative
FSMs
dataflow
discrete
event
☞ The choice of a modeling language is, to a large extent, connected
to the choice of the modeling approach.
This, because certain modeling languages are strongly connected
to a particular model of computation:
partitioning
Refinement
compiling
softw. synth
SW
processor
model
SW
processor
model
HLS
LS
- Communicating asynchronous state machines: SDL, Lotos
- Synchronous systems: Esterel, StateCharts;
Lower level
of abstraction
- Dataflow and continuous computation: Matlab, Lustre, Silage
ASIC
glue logic
Petru Eles, IDA, LiTH
Petru Eles, IDA, LiTH
System Design&Methodologies
Fö 7- 23
System Design&Methodologies
Modeling Languages (cont’d)
Fö 7- 24
Modeling Languages (cont’d)
☞ Some languages do not support particular models of computation
• General purpose programming languages:
- imperative: C, C++, Java, Ada
- functional: Lisp, Scheme, Haskell
- logic: Prolog
• Hardware description languages:
- VHDL, Verilog, SystemC: imperative, Discrete Event
☞ When used according to certain restrictions and programming
guide-lines, models based on particular models of computation can
be realised in these languages too.
Petru Eles, IDA, LiTH
☞ Different parts of the specification can be realised in different
languages.
• Will we ever get “THE” System Modeling Language?
• Will multi-language specification become the standard?
Petru Eles, IDA, LiTH