towards predictability in real-time embedded system design lorentz-artist workshop embedded systems...
Post on 15-Dec-2015
218 Views
Preview:
TRANSCRIPT
Towards predictability in real-
time embedded system design
Lorentz-ARTIST Workshop Embedded Systems
November 22, 2005 Jeroen Voeten, Jinfeng Huang, Oana Florescu,
Bart Theelen and Henk CorporaalES Group, Eindhoven University of Technology
Embedded Systems Institute
2
RT Embedded Software: ”Integration Hell”
•Complexity • many hardware/software components
• verified and tested in isolation…
•Integration• system does not work
• difficult to locate cause of problem
• modifications introduce unexpected new problems
•Prediction• difficult to predict properties in advance
•Correctness/performance • can only be checked late in design cycle
• through extensive testing
3
A Toy Example: Railroad Crossing
•Trains run independently at different velocities
•Velocities are constant
•Avoid collisions
StationStation
Station
B
AA D
D
A
Critical zone
Crossingarea
Station
B CB
C
4
Current Practice: Objects and Threads
Train A(Active Object)
Crossing(Passive Object)
Train B(Active Object)
Start_Motor(“A”, “Right”);Wait(SensorA);Delay(DistanceToCrossing/Velocity);if (!Crossing.getAccess(no_block)) { Stop_Motor(“A”); Crossing.getAccess(block); Start_Motor(“A”);}Delay(CrossingSize/Velocity);}Crossing.Release();Wait(SensorD);Stop_Motor(“A”);
class Crossing{Semaphore Sem;
void Crossing(){ Sem=CreateSem(1)}
bool getAccess(bool block){ return Wait(Sem, block);}
void Release(){ Signal(Sem);}}
5
Timing Property
•Between D and D+ seconds after Train A has passed Sensor A, check the Crossing and if it is occupied stop the train (D=DistanceToCrossing/Velocity)
•Execution trace:
1+2 ?
SensorA signaled T
Delay D
T+DCheck Crossing
T+D+1Stop motor T+D+1+2
6
Timing Property - Add Components
•Add new active objects to the software system (e.g. to control another railroad crossing)
•Execution trace:
+1+2 BOOM !!!
SensorA signaled T
Delay D
T++DCheck Crossing
T++D+1
Stop motor T++D+1+2
other active object running
T+
7
A multithreaded code fragment
char x=0, y=0, z=0, w=0;thread 1: x=1; y=1; z=1 ;thread 2: w=1;
•Works fine … probably … until platform is changedWorks fine … probably … until platform is changed
•POSIX threads on Intel® Itanium®POSIX threads on Intel® Itanium®
•Any variable may be zero after both threads finish!
•Multicore and hyperthreading platforms will make such problems happen more often in future…
8
Property Prediction is Difficult!
•Execution semantics of component: All possible execution traces a component can be involved in
•A component satisfies a property if it is satisfied for each execution trace
•Execution semantics is context-dependent:• processor platform
• RTOS
• compiler
• other software components in the system
•Property prediction requires component context• properties cannot be predicted from component description
alone
• if context changes component properties change
• ‘prediction’ typically done through testing on target platform
9
Predictable Approach: Principles
Compositional Modeling Language• context-independent semantics: all possible traces the
component can be engaged in irrespective of context– compositionality: properties of composite deducible from
properties of constituent
– composability: properties of a component are preserved when context changes
• expressive (concurrency, time, succinct models, …)
• executable
Predictable Mapping• automatic mapping onto target hardware platform
• predict properties of the realization from model properties
10
Summary-Traditional versus Predictable
Bottom-up & Code-driven Top-down & Model-driven
“Here is the code – let’s see how it executes”
“This is the model – execute it according its semantics”
“Heisenberg Testing Principle” “Tests do not influence rest”
“Integration heaven”“Integration hell”
Model & implementation consistency? Prediction?
Model & implementation are consistent in case of feasible
mapping. Prediction!
11
Active Objects and Compositionality?
•Then for each (active) object we need to: •Assume potentially unbounded execution times
•Interpret Delay(T) as ‘delay at least T’
•Suspect interference with any other object at any time
•Result•Impossible to establish any real-time properties
•Difficult to establish other properties (such as invariants)
•Conclusion: active objects do not encourage a compositional way of working
12
Component-based Approaches
•Active objects cannot protect themselves well against unwanted interactions with environment• yielding a tremendous amount of non-determinism
• semaphores/monitors/locks help, but are difficult to work with …
•Component-based approaches address this by• strong encapsulation
• component interaction only via well-defined interfaces
• interaction often based on message passing
• component can decide at any time not to accepts message
•Examples:• Kahn Process Networks (not for control, untimed)
• SDL
• Rose-RT (ROOM)
• POOSL
13
SDL’96
•Tool: Cinderella
•Model has context-dependent timing semantics•simulation results depend on platform
•simulation results depend on other processes in system
•No automatic code generation
Compositional Modeling Language Predictable Mapping
14
SDL’96: Clock Example
•Expected: n-th tm:=tm+1 action to be issued at time n
•Reality: 31st tm:=tm+1 issued around 52nd second
•Reason: time in model is based on physical time
15
ROOM
•Tool: Rose-RT (IBM)
•Model has context-dependent timing semantics•simulation results depend on platform
•simulation results depend on other processes in system
•Automatic code generation
•Real-time properties of realization cannot be predicted from model
Compositional Modeling Language Predictable Mapping
16
SDL’2000
•Tool: Tau Generation 2 (Telelogic)
•Model has compositional (timing) semantics•established by virtual (model) time concept
•predictability support during modeling
•Automatic code generation
•Neither timing nor event ordering can be predicted from model
Compositional Modeling Language Predictable Mapping
17
SDL’2000: Code Generation – Time Error
0 200 400 600 800 1000 1200 1400 1600 18000.0
0.2
0.4
0.6
0.8
1.0
1.2
1.4
1.6
1.8
2.0
2.2
2.4
2.6
2.8
3.0
Tim
ing E
rror
(seco
nds)
Virtual Time (seconds)
Cumulative Tim
ing Error o
n Target
Platform
18
SDL’2000: Code Generation – Event Order Error
pwait
reply_signal ptimer
Process P
syn_signal
Charstring wout=“wrong” ;Charstring cout=“correct” ;Timer ptimer()
set(ptimer, now+3)
out_signal(cout) out_signal(wout)
reset(ptimer)
reply_signal
qwait
qtimer
qstart
syn_signal
qstart
Process Q
Timer qtimer()
set(qtimer, now+2.99)
19
POOSL
•Parallel Object-Oriented Specification language
•Expressive and executable •asynchronous concurrency
•synchronous message passing
•object-oriented data
•real-time and stochasticity
•dynamic process creation
•Formal (compositional) semantics•two-phase execution model (X.Nicollin, J.Sifakis ‘91)
•Tools: SHESim and Rotalumis (RT)
Source: X.Nicollin, J.Sifakis ’91
20
POOSL: Semantics
POOSLModel
FormalSemanticsTimed ProbabilisticLabelled Transition
System(Segala Model)
SimulationProcess Execution Trees
Formal Verification
Model Checking
Performance Analysis
Worst/Best-CaseAverage-Case based on
Markov Chain
Predictable Code
Generation
ε-hypothesis
21
Code Generation: the -hypothesis
•Generate timed trace from transition system• Process Execution Trees, no RTOS, no threads
• ordering of events is kept
•Run-time synchronization upto of virtual time with physical time
•Epsilon-hypothesis• if an action happens at virtual time t in the model it must happen in
physical time interval (t-/2,t+/2) in implementation
•In case hypothesis is satisfied every (MTL) formula in model is preserved upto in realization
•Epsilon can be determined by modeling/analysis or measurement
Compositional Modeling Language Predictable Mapping
22
Demo: The Railroad Crossing
StationStation
Station
B
AA D
D
A
Critical zone
Crossingarea
Station
B CB
C
- 100 - 50 50 100 cm
- 100
50
100
•Velocity TrainA: 40 cm/s
•Velocity TrainB: 90 cm/s
Analysis Model
Synthesis Model
Rapid analysis
Realization
24
Comparison: the Java CubbyHole
Sender CubbyHole(1-place buf)
Receiver
empty full(v)
?get(v)
!put(v)
25
Readability: the Java CubbyHole
public class CubbyHole {
private int contents;
private boolean available = false;
public synchronized int get() {
while (available == false) {
try {
wait();
} catch
(InterruptedException e) {}
}
available = false;
notifyAll();
return contents;
}
public synchronized void put(int value) {
while (available == true) {
try {
wait();
} catch (InterruptedException e) {}
}
contents = value;
available = true;
notifyAll();
}
}
empty()() in?get(v);full(v)()
full(v:Object)() out!put(v);empty()()
CubbyHolein out
26
Efficiency: the Java CubbyHole
Sender CubbyHole(1-place buf)
Receiver
Language/ToolLanguage/Tool com/com/secsec
cycles/cycles/comcom
SHESim (full POOSL,SHESim (full POOSL,)) 25002500 13800001380000
Java (Java ()) 222000222000 81008100
C (Pthreads,Cygwin,C (Pthreads,Cygwin,)) 325000325000 55005500
Rotalumis (full POOSL,Rotalumis (full POOSL,)) 500000500000 36003600
C++ (POOSL fragment,C++ (POOSL fragment,)) 67000067000000
269269
27
Open Issues and Current Work
•Multi-processor platforms•Predictable mapping
•globally asynchronous time; different clocks with different clock drifts
•Efficiency•reduce run-time scheduling overhead (partial-order
reduction)
•reduce PET overhead (static unfolding of transition system)
•Streaming•dealing with time-intensive actions
•use of abstraction, factor out equivalence
top related