Reading material
• Chapter 2 of Burns & Wellings
TDDB47 Real-time Systems
Lecture 5: Design
• To see a concrete case/language for
design of real-time systems:
Simin Nadjm-Tehrani
Laboratory for Real-time Systems
Department of Computer and Information Science
Linköping university
Undergraduate course on Real-time Systems
Linköping
35 pages
Autumn 2005
– Chapter 5 of ”Software Specification and
Design, A Disciplined approach for Real-time
Systems”, Shumate and Keller, Wiley, 1992.
Your assistant has reference copies!
– article by Halwbach et al.
Undergraduate course on Real-time Systems
Linköping
2 of 35
Autumn 2005
Real-time Computations
• Concurrent - possibly distributed
• Shared resources (processor, memory,
communication channel)
Typical demand:
• Deterministic behaviour (nondeterministic environment)
Undergraduate course on Real-time Systems
Linköping
3 of 35
Autumn 2005
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
4 of 35
Autumn 2005
Layers of design
Application modelling support
Programming environment support
So what is so hard about this?
System software support (kernels)
Hardware support
Undergraduate course on Real-time Systems
Linköping
5 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
6 of 35
Autumn 2005
Historical snapshots
• Hardware design
– 1970´s
Dedicated hardware
– 1980´s
Micro computers & ASICS
– 1990´s
High performance Micro
computers, FPGAs, MEMs
– 2000 ’s
SoCware
Where should we look to find
design errors?
Software & hardware interchangeable!
Undergraduate course on Real-time Systems
Linköping
7 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
Historical snapshots
• Scheduling
–1970´s
–1980´s
–1990´s
–2000´s
principles
Fixed priority scheduling
Multiprocessor, dynamic
Incorporating shared
resources
Load variations, time
!
only one dimension in ure
t
quality of service lec
S
Qo
Undergraduate course on Real-time Systems
Linköping
9 of 35
Autumn 2005
8 of 35
Autumn 2005
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
Layers of design
10 of 35
Autumn 2005
Frequency of faults
Other
10%
Application modelling support
7%
Code
Design
Requirements
Programming environment support
56%
System software support (kernels)
27%
Hardware support
[Jim Cooling 2003, cited from DeMarco78]
Undergraduate course on Real-time Systems
Linköping
11 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
12 of 35
Autumn 2005
Back to basics
An engineering discipline
• define end-to-end deadlines
– Model the environment!
Using mathematics can never be wrong!
• 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 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
14 of 35
Autumn 2005
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
15 of 35
Autumn 2005
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
Power plant
• Transformation schemata for functional
dynamic monitoring part
HighAlarm
Compute
OK
Restart
safety
Monitor
compute
power
prodn
ModerateAlarm
Coolant tank
OK
Cool
ModerateAlarm
Restart
Alert
17 of 35
Autumn 2005
Cool
HighAlarm
ShutDown
Restart
HighAlarm
Power request
Off
Power production
Undergraduate course on Real-time Systems
Linköping
ModerateAlarm
No Output
ModerateAlarm
Continue
HighAlarm
No Output
Normal
OK
Pressure
state
OK
ShutDown
ShutDown
Cool
Coolant
Monitor state machine
Fuel tank
Temperature
16 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
No Output
18 of 35
Autumn 2005
System level properties
• Add timing
Design models,
Digital controller
x
Timed models
[l, u]
HW/SW
u
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
19 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
20 of 35
Autumn 2005
Engineering practice (trends)
• 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
21 of 35
Autumn 2005
Non-digital hardware
Extensive simulations of coupled aircraft flight
dynamics and actuator dynamics
Undergraduate course on Real-time Systems
Linköping
22 of 35
Autumn 2005
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
23 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
24 of 35
Autumn 2005
Simulations
What do they show?
Formal techniques
• With a goal to:
– Avoid/remove (design) faults that
lead to obvious bad things
– Analyse behaviour in presence of
selected combinations of potential
external faults
Undergraduate course on Real-time Systems
Linköping
25 of 35
Autumn 2005
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
27 of 35
Autumn 2005
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
State space search
28 of 35
Autumn 2005
Advanced techniques
• 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
• 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
26 of 35
Autumn 2005
29 of 35
Autumn 2005
Undergraduate course on Real-time Systems
Linköping
30 of 35
Autumn 2005
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
31 of 35
Autumn 2005
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...
The bright side
☺ Causality, determinism,
A/B
B/A
Causality...
Undergraduate course on Real-time Systems
Linköping
33 of 35
Autumn 2005
Formal techniques
• The least we can do:
– Avoid/remove (design) faults that
lead to obvious bad things
– Analyse behaviour in presence of
selected combinations of potential
external faults
PhD courses: safety-critical
systems, Fault tolerance
Undergraduate course on Real-time Systems
Linköping
32 of 35
Autumn 2005
35 of 35
Autumn 2005
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
D
D
T
Undergraduate course on Real-time Systems
Linköping
5
0
C
34 of 35
Autumn 2005