Real-time Computations
• Concurrent - possibly distributed
• Shared resources (processor, memory,
communication channel)
TDDB47 Real-time Systems
Lecture 9: Design
Typical demand:
• Deterministic behaviour (nondeterministic environment)
Simin Nadjm-Tehrani
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping university
Undergraduate course on Real-time Systems
Linköping
40 pages
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
2 of 40
Autumn 2007
Basic approach
To ensure timeliness:
• define end-to-end deadlines
• define deadlines for individual tasks
• ascertain (worst case) execution
time for each task
• document assumptions/restrictions
• prove that implementation satisfies
requirements
Undergraduate course on Real-time Systems
Linköping
3 of 40
Autumn 2007
So what is so hard about this?
Undergraduate course on Real-time Systems
Linköping
4 of 40
Autumn 2007
Layers of design
Application modelling support
Programming environment support
Where should we look to find
design errors?
System software support (kernels)
Hardware support
Undergraduate course on Real-time Systems
Linköping
5 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
6 of 40
Autumn 2007
Historical snapshots
• Hardware design
– 1970´s
Dedicated hardware
– 1980´s
Micro computers & ASICS
– 1990´s
High performance Micro
computers, FPGAs, MEMs
– 2000 ’s
SoCware
Historical snapshots
• Scheduling
–1970´s
–1980´s
–1990´s
–2000´s
Software & hardware interchangeable!
Undergraduate course on Real-time Systems
Linköping
principles
Fixed priority scheduling
Multiprocessor, dynamic
Incorporating shared
resources
Load variations, time
!
only one dimension in ure
t
quality of service lec
S
Qo
7 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
Historical snapshots
• Programming environments
–1970´s ”High” level
programming
–1980´s Real-time specific: Ada
–1990´s OO languages,
languages with formal
semantics
–2000´s Built-in analysis,
Software components
Undergraduate course on Real-time Systems
Linköping
9 of 40
Autumn 2007
8 of 40
Autumn 2007
Layers of design
Application modelling support
Programming environment support
System software support (kernels)
Hardware support
Undergraduate course on Real-time Systems
Linköping
10 of 40
Autumn 2007
Frequency of faults
Engineers: Fool me once,
shame on you – fool me
twice, shame on me
Other
10%
7%
Code
Design
Requirements
56%
27%
[Jim Cooling 2003, cited from DeMarco78]
Undergraduate course on Real-time Systems
Linköping
11 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
12 of 40
Autumn 2007
Back to basics
Software developers: Fool me N
times, who cares, this is
complex and anyway no one
expects software to work...
• define end-to-end deadlines
– Model the environment!
• define deadlines for individual tasks
– Specify system decomposition!
• ascertain (worst case) execution time for
each task
– Assume hardware characteristics!
• document assumptions/restrictions
– Model, model, model!
• prove that implementation satisfies
requirements
– Analyse models!
Undergraduate course on Real-time Systems
Linköping
13 of 40
Autumn 2007
An engineering discipline
Undergraduate course on Real-time Systems
Linköping
14 of 40
Autumn 2007
Properties of interest?
• Functional properties
Using mathematics can never be wrong!
• Extra-functional properties
(Also called non-functional properties)
– Timeliness
– Availability
– Safety/Fault tolerance
–…
Undergraduate course on Real-time Systems
Linköping
15 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
Historical snapshots
• Mathematical models & verification tools
– 1970´s
Sequential systems
– 1980´s
Concurrent/distributed
systems
– 1990´s
Timed and Hybrid
systems
– 2000’s
Incorporation in
engineering tools, From
objects to components
Undergraduate course on Real-time Systems
Linköping
17 of 40
Autumn 2007
16 of 40
Autumn 2007
Today: UML
• … is a follow up of modelling techniques
suggested in early eighties
• For example: Ward & Mellor Diagrams
• Next two slides from an example
presented in [Heitmeyer and Mandrioli,
Wiley, 1996].
Undergraduate course on Real-time Systems
Linköping
18 of 40
Autumn 2007
Power plant
• Transformation schemata for functional
part, dynamic monitoring part
HighAlarm
Compute
OK
Restart
safety
Monitor
compute
power
prodn
ModerateAlarm
No Output
OK
ModerateAlarm
Restart
Alert
ShutDown
HighAlarm
Power request
Off
Power production
Undergraduate course on Real-time Systems
Linköping
19 of 40
Autumn 2007
Cool
HighAlarm
Restart
HighAlarm
No Output
Undergraduate course on Real-time Systems
Linköping
20 of 40
Autumn 2007
Hybrid models
Timed models
• Add timing
Design models,
Digital controller
Cool
ModerateAlarm
Continue
Coolant tank
ModerateAlarm
OK
Pressure
No Output
Normal
ShutDown
Cool
state
OK
ShutDown
Fuel tank
Temperature
Coolant
Monitor state machine
[l, u]
HW/SW
u
x
Environment
x = f ( x, u, d )
• Simplest version: synchronous/clocked
systems: l=u ticks of a clock
d
Undergraduate course on Real-time Systems
Linköping
21 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
22 of 40
Autumn 2007
Engineering practice
• Detailed models and simulations for
non-digital hardware
What do we do with models once we
create them?
Undergraduate course on Real-time Systems
Linköping
23 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
24 of 40
Autumn 2007
Non-digital hardware
Extensive simulations of coupled aircraft flight
dynamics and actuator dynamics
Engineering practice (trends)
• Detailed models and simulations for
non-digital hardware
• Design models for digital components
and functional analysis by
– Simulations
– (Formal verification)
– (Semi-automatic code generation)
[P. Krus, 2000]
Undergraduate course on Real-time Systems
Linköping
25 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
Simulations
26 of 40
Autumn 2007
Formal techniques
What do they show?
• Remove (design) faults that lead to
obvious bad things
• Prove that bad things never happen
Undergraduate course on Real-time Systems
Linköping
27 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
Hard problem!
• Let M be a model of a system
• Let S be the (temporal) logic formula
expressing the requirements
• Show that the design specification M
(the set of computations for M)
satisfies S
Undergraduate course on Real-time Systems
Linköping
29 of 40
Autumn 2007
28 of 40
Autumn 2007
State space search
• To check that M satisfies S, we
must check that no possible state
in M contradicts S.
• Consider a model M with n Boolean
state variables. This leads to a
potential state space of 2n.
Undergraduate course on Real-time Systems
Linköping
30 of 40
Autumn 2007
State space search
• With 55 variables, at 1 MHz, it would
take (in the worst case) over 1 billion
years to visit every state!
Undergraduate course on Real-time Systems
Linköping
• Smart data structures for efficient
representation of state space
• Smart deduction engines
(satisfiability checkers) that find
proofs fast
• Smart abstractions of the design to
capture the essential properties
Synchronous languages
31 of 40
Autumn 2007
Simple example in Lustre
node Stopwatch (start-stop, reset, hs: bool)
returns (time: int; running: bool);
let
time = 0 -> if hs and running
then pre(time) + 1
else if reset
then 0
else pre(time);
running = false -> if start-stop
then not pre(running)
else pre(running);
tel
Undergraduate course on Real-time Systems
Linköping
Advanced techniques
33 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
Some desirable properties
• Abstraction: do not fix time granularity
until very final stages of implementation
• Causality: an event should not be able
to trigger itself
• Consistency: transitions taken in a
step are not disabled by parallel
transitions
Undergraduate course on Real-time Systems
Linköping
What is desirable here?
UML state diagrams:
Not A
/B
B/A
Consistency...
Undergraduate course on Real-time Systems
Linköping
A/B
B/A
32 of 40
Autumn 2007
34 of 40
Autumn 2007
The bright side
✂✪ Causality, determinism, consistency:
dealt with by the compiler
✂✪ Connections to code optimisation and
formal verification tools
– efficient code generation in C, Ada or
VHDL
– Prover plugin or export to other
verification tools
Causality...
35 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
36 of 40
Autumn 2007
Properties of interest?
• Functional properties
To the client
Client request
Checkpointing
request
• Extra-functional properties
Logging
Application
Server
Server
Request
replies
– Timeliness
– Availability
– Safety/fault tolerance
–…
Undergraduate course on Real-time Systems
Linköping
Highly available servers
• Optimal checkpointing interval for D
Ph
achieving highest possible availability
B
S
RT
37 of 40
Autumn 2007
04
LA
Undergraduate course on Real-time Systems
Linköping
38 of 40
Autumn 2007
Properties of interest?
Safety properties
• Emerging trend in software systems
• Functional properties
C2
C1
• Extra-functional properties
C5
Interface
– Timeliness
– Availability
– Safety/fault tolerance
–…
C6
C4
C7
C3
• Problem: no component models
gp
n
i
address safety properties!
o
C´4
Undergraduate course on Real-time Systems
Linköping
20
39 of 40
Autumn 2007
Undergraduate course on Real-time Systems
Linköping
On
t
ec
j
ro
!
g
40 of 40
Autumn 2007