01 IntroductionWCETdffdf

Systems Engineering II
Introduction, Worst Case Execution Time

Outline
Introduction to Real-Time Systems

Defining Real-Time Systems
Examples: Obstacle Avoidance System, Occupant Protection System
Terms and Definitions
Worst Case Execution Time
Worst-Case Execution Time (WCET)
WCET Analysis, Software Behavior, Hardware Timing
Timing by Measurements, Timing by Static Analysis
Tools: AVR Profiler, Bound-T
Assignments
Appendix A: Position, velocity, and acceleration
Appendix B: Numerical integration
References
MC 516 Systems Engineering II Page 2
Introduction

System
A system is a mapping of a set of inputs into a set of outputs.
Response Time
The response time is defined as the time between the presentation of a set
of inputs (stimulus) and the realization of the required output (response).
In real-time systems the constraints on the response time are important.

Introduction

Categorizing computer systems
Batch. I don’t mind when the computer results arrive, within reason (the
time may be hours or even days in such systems).
Interactive on-line. I would like the results within a fairly short time,
typically a few seconds.
Real-time. I need the results within definite timescales, otherwise the
system just won’t work properly.
IEEE Standard 610.12-1990
Real-time. Pertaining to a system or mode of operation in which
computation is performed during the actual time that an external
process occurs, in order that the computation results can be used to
control, monitor, or respond in a timely manner to the external process.

Introduction

Some other definitions.
A real-time system is a system that must satisfy explicit (bounded)
response-time constraints or risk severe consequences, including
failure; a failed system is a system that cannot satisfy one or more of the
requirements stipulated in the formal system specification.
A real-time system is one whose logical correctness is based on both the
correctness of the outputs and their timeliness.
Soft and hard real-time systems.
A soft real-time system is one in which performance is degraded but not
destroyed by failure to meet response-time constraints (all practical
systems minimally represent soft real-time systems).
A hard real-time system is one in which failure to meet a single deadline
may lead to complete and catastrophic system failure.

Introduction

Real-time system categorization – Time and Criticality.
Time → Slow Fast
Criticality ↓
Soft Machine condition monitoring Man-machine interface
Hard Missile point defense system Airbag control system
Attributes of real-time systems.

Attribute → Execution Deadlines Software Software
Category ↓ Time Size Complexity
Hard-Fast **** **** * * Focus in MC 516.
Hard-Slow * **** * → *** * → ****

Soft-Fast **** ** * → *** * → ***
Soft-Slow ** ** * → **** * → ****
* Low weighting
**** High weighting

Introduction

Hard Real-Time Systems
Missing a deadline may have catastrophic consequences.
Deadlines have to be met.
Response time < deadline.
Distribution
Deadline
Response Time
Best case Worst case

Introduction

Soft Real-Time Systems
Missing a deadline causes a performance degradation but does not
jeopardize the correct system behavior.
Deadlines often specified in probabilistic terms – e. g., a sequence must
complete in no more than 10 seconds for 95 % of the time and in no more
than 20 seconds for 99.95 % of the time.
Small average response time and high throughput often more important.
Distribution
Deadline
Response Time
Best case Worst case

Introduction
Obstacle Avoidance System

Wheel-vehicle equipped with range sensors that has to operate in a certain
environment running within a maximum given speed.
Automatic braking system for stopping motion in emergency situations.

Introduction

Brake Control Unit (BCU)
is responsible for acquiring a pair of range sensors,
computing the distance of the obstacle (if any),
reading the state variables of the vehicle from instruments on the
dashboard, and deciding whether an emergency stop has to be
superimposed.
Given the criticality of the braking action, this task has to be periodically
executed on the BCU. Let T be its period.
What is a safe value for T ? (or, “how often do we have to sample the
range sensors and process the readings?”)

Introduction

A safe value for T
The maximum latency from the time at which an obstacle appears and the
time at which the vehicle reaches a complete stop is less than the time to
impact.
The distance D of the obstacle from the vehicle must always be greater than
the minimum space L needed for a complete stop.
Braking duration Δb: interval
needed for a complete stop,
Detection delay: interval between depends on the wheel-road friction
the time at which an obstacle coefficient (μ) and gravity (g).
appears and the time at which the
obstacle is detected by the BCU.
This interval is at most equal to the Transmission delay Δt: interval
period T of the sensor acquisition between the time at which the stop
task. command is activated by the BCU
and the stop command starts to be
actuated by the brakes; depends on
the brake hardware, e. g. 250 ms.
Velocity during brake.

Introduction

A safe value for T
Static friction, no sliding
– FD … normal force (mg)
– FR … force of friction
– µ … friction coefficient, property of the contacting materials
– FR = µ FD
FR
FD

Introduction

A safe value for T
Maximum braking force for a vehicle
– Wheels are barely turning, no sliding  maximum friction maximum
deceleration
– FD = 𝑚𝑔
– FR = 𝜇FD = 𝜇𝑚𝑔
– 𝒂 = F𝑚R = 𝜇𝑚𝑔
𝑚
= 𝝁𝒈; for rubber/dry concrete µ is 0,8..1,0  a = 9 m/s2
v is the actual velocity of the vehicle, µ is the wheel-road friction coefficient
– Since 𝑡 = 𝑎𝑣 , the breaking duration ∆𝑏 is given by ∆𝑏 = 𝜇𝑔
𝑣
and 𝑠 =
𝑣𝑡
2
𝑣 𝑣 𝑣2
(acceleration!), the resulting brake space 𝑥𝑏 is 𝑥𝑏 = ∙ =
2 𝜇𝑔 2𝜇𝑔
– Therefore, the total length L needed for a stop is

Introduction

A safe value for T
By imposing D > L, we obtain the relation that must be satisfied among the
variables to avoid a collision:
If we assume that obstacles are fixed and are always detected at a distance
D from the vehicle, the maximum value that can be assigned to period T is
given by
Example: D = 100m, µ = 0.5, Δt = 250 ms, v =30 m/s, g = 9.8 m/s2 
Sampling period T (and all the processing and decision making) must be
less than 20 ms.

Introduction
Occupant Protection Systems

Safety belts and pretensioners (tightener) – restrain the occupants of a
vehicle in their seats when the vehicle hits an obstacle.
Airbags – Protect the driver and the front passenger against head and chest
injuries in a vehicle impact with a solid obstacle.
Belt slack, belt stretch, delayed effect of

the belt retractor ("film-reel effect") 
belt needs to be tightened.
A pretensioner alone cannot prevent the
head from hitting the steering wheel in
response to severe impact  air bag.
Occupant protection systems with belt tighteners and front airbags

1 Belt tightener, 2 Front airbag for passenger, 3 Front airbag for driver, 4 ECU (Electronic Control Unit).

Introduction

Electronic Control Unit (ECU)
Casing Printed Circuit Board (PCB)

Introduction

Block diagram of a simplified airbag system
Vehicle positive ECU
Backup power circuit
(capacitors)
Front airbag left

e. g., 16/32 bit Microcontroller
Satellite Front airbag right
accelerometer 128 KB Flash Firing circuits
(optional) 4 KB EEPROM Pretensioner left
SPI, CAN, ADC, Timer, …
Pretensioner right
CAN interface
Central accelerometer
Vehicle ground

Introduction

Accelerometer
Monitors the acceleration (or, deceleration) forces that accompany an
impact.
In automotive applications usually based on capacitive sensors.
Capacitor in measurement applications
𝜀⋅𝐴
𝐶=
𝑑
– 𝜀 can be changed (e. g. moisture).

– 𝑑 can be changed  change in 𝐶: used in accelerometers.
Introduction

Accelerometer
How is the capacitance being measured?
1
– 𝑋𝐶 = 𝑗𝑤𝐶
– Operated with AC, a capacitor looks very much like a resistor.
– Voltage divider circuits can be then used (RC or CC), usually RC.
– AC has to be converted to DC.

Introduction

Accelerometer

Introduction

Accelerometer
Sensor Bandwidth
– The amount of times per second you can take a reliable acceleration
reading, i. e. how often a reliable reading can be taken.
– Bandwidth usually in the range of 50 Hz – several hundred Hz, Example
Freescale MMA626xQ
– Constraint on real-time software: accelerometer is sampled with e. g.

800 Hz (sampling more often is useless (because of the bandwidth),
sampling less often is not an option either since we should react fast (1 /
800 Hz = 1.25 ms between two samples, the decision whether to deploy
the airbag should be taken within 10 ms, see the next slides).
Introduction

Occupant forward displacement with/without restraint system/airbag at an
impact speed of 50 km/h
Timing constraint on the airbag

system: in this example, the airbag has
to be fully inflated at t = 40 ms.
Deceleration to standstill and forward displacement of an occupant at an impact speed of 50 km/h.

1 Impact, 2 Firing of belt tightener/airbag, 3 Belt tightened, 4 Airbag inflated. --- without/ – with restraint systems.

Introduction

Some Types of Crashes – influences deployment and deployment time
Frontal impact Car to Car Side Impact
Pole Side Impact

Introduction

The airbag deployment time depends on the crash type as well as the vehicle
speed.
Velocity Type of Crash Sensor Triggering Time
[mph] [ms]
Rough road, minor animal impact, braking No Triggering
< 14 Head-on collisions No Triggering
48 – 64 Vehicle to rigid barrier 10 – 20
48 – 64 Vehicle to angular rigid barrier 20 – 30
24 – 32 Vehicle to rigid barrier 30 – 50
24 – 32 Vehicle to pole 50 – 70
48 - 64 Vehicle to vehicle head-on collision 30 – 50

Introduction

Timing of Sensor Triggering
The sensing system must trigger in time to initiate the bag deployment so that
a sufficiently inflated bag is in place to cushion the occupant motion.
The faster the vehicle, the faster the airbag has to be deployed (otherwise
the occupant is very close to the air bag module when the deployment occurs
and the unfolding bag can exert considerable forces to inflict injuries to the
occupant).
The slower the vehicle, the later the airbag has to be deployed (otherwise
the airbag is deflated and can not provide a cushion to absorb the kinetic
energy of the occupant).
The air bag must not deploy too late and not too early.
The crash module is looking for a large, sudden, reduction in velocity: sudden
reduction of velocity is the only reliable indication of a crash – potholes can
generate lots of shock, but should not trigger an airbag.
Introduction

Timing of Sensor Triggering
The “125 mm minus 30 ms” criterion
– The required or latest sensor triggering time is determined by
subtracting 30 ms from the elapsed time when the occupant has
125 mm moved forward by a distance of 125 mm from the onset of a crash.
– This criterion can be reasoned by the following assumptions.
a) The estimated distance between a fully inflated bag and the
chest or head of the occupant in his original seating position at the
onset of the crash is 125 mm.
b) Once the inflator receives the firing signal, the time needed for the
bag to become fully inflated is 30 ms.

Introduction

Crash Sensing
Crash data of a 48-km/h vehicle-to-barrier collision
125 mm minus 30 ms:

Timing constraints on the airbag system:
in this example, the proper sensor
triggering time is about 18 ms.
125 mm
18 ms 48 ms
30 ms

Introduction

Crash Sensing
Crash data of a 15-km/h vehicle-to-barrier collision
125 mm minus 30 ms:

Timing constraints on the airbag system:
in this example, the proper sensor
triggering time is 50 ms.
125 mm
50 ms 80 ms
30 ms

Introduction

Crash Sensing
14-km/h vehicle-to-barrier and 26 km/h center pole crash
Pole crash has more swings in the

signal than a barrier crash.

Introduction

Crash Sensing – Characteristics
The task of crash sensing possesses the following characteristics.
– Predictive: Since an air bag requires a finite time span to inflate, the
sensing system must be predictive. Sensors must make a judgment
about crash severity at the early stage of a collision.
– Discriminative: It is essential that a sensing system be able to reliably
differentiate the circumstances of deployment and nondeployment.
Unnecessary deployments become a nuisance to the users and present
potential hazards.
– Real-time: Crash sensing is a real-time application, which means that
sensors must react immediately upon the received signal in a limited
window.

Introduction

Crash Sensing – Parameters
A number of parameters can be used to determine the severity of a crash
(and therefore deduce the time of airbag deployment)
– Accelerometer signal, 𝑎(𝑡), itself
– Change in vehicle velocity ∆𝑣 = 𝑎(𝑡) 𝑑𝑡
– Absolute value of 𝑎(𝑡), i. e., 𝑎(𝑡)
– Derivative of 𝑎(𝑡), i. e., 𝑑𝑎 𝑑𝑡
– Number of oscillations (swings) per time unit in 𝑎(𝑡)
Change in vehicle velocity is a good parameter to determine whether the
airbag should be fired in case of a frontal barrier crash. But, this parameter is
not good for making any decision during a polar or angular crash.
A parameter based on the number of swings is used for detecing pole
crashes.

Introduction

Crash Sensing – Assumptions for the following discussion
Only one accelerometer which is mounted in the non-crush zone in the
passenger compartment is used (no satellite sensors), no side airbags.
Frontal collision
– The airbag must be deployed if the collision force is equivalent to a frontal
collision with a stationary barrier at a speed of 14 mi/h or higher.
– The airbag must not be deployed if the collision force is equivalent to a barrier
crash at a speed of 8 mi/h or less.
– Deployment or nondeployment is equally acceptable: 8 mi/h < v < 14 mi/h.
Pole crash
– Gray zone (deployment or nondeployment ): 11 mi/h < v < 17 mi/h.
– A 17 mi/h pole crash is equivalent to that of a 14 mi/h barrier crash, or a 11
mi/h pole crash is equivalent to an 8 mi/h barrier crash.

Introduction

Crash Sensing
Change in velocity versus time after the crash
v is determined by integrating a, whenever v exceeds the threshold of

6.5 ft/s, the airbag is to be deployed. However, this works only for fast
barrier crashes (C3, C4), since would the same threshold be used for
the pole crashes (C5, C6), the airbag would be also deployed for the
8 mi/h barrier crashes (C1, C2), which must no happen according to
our previous assumptions (see next page).
C1, C2: 8 mi/h barrier crash: nondeployment

C3, C4: 14 mi/h barrier crash (lowest velocity crash with deployment)
C5, C6: 19 mi/h pole crash
C3, C4: 125 mm minus 30 ms. C5, C6: 125 mm minus 30 ms

Introduction

Crash Sensing
If ∆𝑣 is selected as a parameter for crash sensing, then a threshold can be
determined to make a decision whether or not the crash occurred:
∆𝑣𝑡ℎ = 6.5 ft/s in the previous figure.
If ∆𝑣 ≥ ∆𝑣𝑡ℎ within 35 ms after the crash occurred, then it is sure that the
crash occurred in the deployment zone and therefore the airbag must be
triggered (35 ms – lowest velocity, “faster” crashes need less time).
But it is not possible to select a threshold value of ∆𝑣 which can be used to
trigger the airbag within 60 ms after the occurrence of a 19 mi/h pole crash
(because, if such a threshold value is selected, then that threshold will also
trigger the airbag for an 8 mi/h barrier crash!).
Thus, ∆𝑣 can not be used to discriminate a 19 mi/h pole crash from an 8
mi/h barrier crash until it is too late to trigger the airbag for a 19 mi/h pole
crash.

Introduction

Crash Sensing
∆𝑣 is not enough to make a decision whether to or not the airbag is to be
triggered for all types of crashes.
However, ∆𝑣 can be used in the airbag control algorithm as follows:
if ∆𝑣 ≥ ∆𝑣𝑡ℎ within 35 ms after the crash then
crash occurred in the deployment zone no matter what
the type of the crash is
else
further parameter testing is necessary to determine
whether or not it is a pole or an angular barrier crash

Introduction

Crash Sensing – Differences between barrier and pole crashes
Barrier crash
– The entire bumper is affected, vehicle starts loosing energy at a higher
rate for a barrier crash, velocity decreases more rapidly than for a pole
crash.

Introduction

Crash Sensing – Differences between barrier and pole crashes
Pole crash
– Only part of the bumper is affected, a pole crash with deployment
normally breaks the bumper, the pole cuts through the bumper and hits
other solid objects (radiator, motor, etc.).
– When the pole hits a solid object, the vehicle deceleration increases
(slows down more rapidly); after that, if the pole breaks the solid object,
the vehicle will not slow down as rapidly as it was  more swings.

Introduction

Crash Sensing – Second Parameter
Quantitative measure of the swinging effect.
Function of the number of swings and the total amplitude of swings:
– Length L of the 𝑎(𝑡) curve.
Differential length:
The length of the curve from o to t:

Introduction

Crash Sensing – Second Parameter
Length of the 𝑎(𝑡) curve vs. time
A threshold based on L can be used,

e. g. 1200 to detect a deployment
pole crash.

Introduction

Crash Sensing – Development of the Airbag Control Algorithm
Both parameters (Δ𝑣 and 𝐿) are needed
– L may be large through a rough and bumpy road, Δ𝑣 will be small in that
case.
Threshold value of Δ𝑣1 which will discriminate a crash from driving through
a rough or bumpy road  we need to know how fast a vehicle can be
braked.
Assume that a vehicle moving with 60 mi/h can be stopped within 3s, the
average change in vehicle velocity over a period of T1 = 35 ms is

Introduction

Threshold value of Δ𝑣
– For an 8 mi/h barrier crash the change in vehicle velocity over a period
of 35 ms is 2 – 4 ft/s
– A value of Δ𝑣1 can easily be selected for a given type of vehicle to
discriminate a crash (deployment of nondeployment crash) from other
types of slowing down conditions on the vehicle (e. g. Δ𝑣1 = 3 ft/s).
– If Δ𝑣 over a period of T1 is less than Δ𝑣1 , then the airbag must not be
fired no matter what the value of L is.
– If Δ𝑣 over a period of T1 is greater than Δ𝑣1 then it is understood that
some kind of crash has been detected. But whether or no the airbag
is to be fired will depend on the results of further testing.

Introduction

Threshold values of Δ𝑣2 , 𝐿𝑡ℎ
– Once a crash has been detected, another threshold value of 𝚫𝒗, say
Δ𝑣2 , is necessary to determine whether or not it is a deployment
barrier crash. For the crashes shown on page 27, a value of 6.5 ft/s
can be used to detect a frontal barrier crash.
– Similarly a threshold value of L, say 𝐿𝑡ℎ , is necessary to determine
whether or not it is a deployment pole crash. Let T2 be the firing time
for the minimum speed deployment crash. The value of L must then be
computed over a period of T2. For the crashes shown on page 33, a
value of 1200 can be used for L to detect a deployment pole crash.

Introduction

Computation of Δ𝑣 and L
– Since the firing time for the lowest speed barrier crash which requires
deployment is T1, the value of Δ𝑣 must be computed over a period of
T1. At any given time the value of Δ𝑣 can be computed by using the
accelerometer signal of the most recent T1 timing. A sliding window of
length T1 can be used for computing Δ𝑣. At any given time, whatever
part of a(t) is available within the window, only that part can be used to
determine Δ𝑣. Every time a new sample comes in, the window is moved
by one sample. This means that the least recent sample is moved out of
the window when a new sample moves into the window. Every time the
window is moved, the value of Δ𝑣 is recomputed.
– Similarly, another sliding window of length T2 can be used to determine
the value of L.

Introduction

Algorithm
/window1[] = 0;
window2[] = 0; Initialize
This means that a

crash has been
detected.
[deltaV > deltaV1] [deltaV >= deltaV2]

NormalMode StandBy Fire
[deltaV < deltaV1]

[L >= LThreshold]
This means that the

newSample/ crash does not require newSample/
slideWindow1(newSample); an airbag deployment. slideWindow1(newSample);
slideWindow2(newSample); slideWindow2(newSample);
deltaV = determineDeltaV(window1); deltaV = determineDeltaV(window1);
L = determineL(window2); L = determineL(window2);

Introduction

Timing requirements
From the airbag system itself
– 125mm – 30 ms rule (not too early, not too late), barrier- and pole crash
 window sizes T1, T2  depends on the correctness of the airbag
control algorithm and its correct implementation
Implementation
– Sampling of accelerometer, processing of new sample, sliding window,
calculation Δ𝑣 and L:is all of this finished before the next sample
arrives?  worst case execution time (WCET) analysis

Introduction

Task and Job
All software activities running in the CPU are modeled as a set of n real-
time tasks Τ = {τ1, τ2,…, τn}, where each task is a sequence of
instructions that is cyclically executed on different input data.
A task τi can be considered as an infinite sequence of jobs τij (j = 1, 2, ...)
each having a computation time ci,j, release time ri,j and deadline di,j.
In other words, a task is a set of related jobs which jointly provide some
system function. A job is a unit of work that is scheduled and executed by
the system.
In the rest of today’s lecture, we’ll focus on simple systems with just one
task, next week, we will cover systems with more tasks.

Introduction

Task and Job
Example, only one task τ1. Task: infinite sequence of
instructions that is cyclically
void T1() { executed.
int i, o;
while (1) {
newSample = readADC();
A job has an execution time ci,j. For simplicity,
slideWindow1(newSample); all jobs of the same task are assumed to have
the same worst case execution time (WCET).
// ... In this example, we assume the WCET to be
deltaV = determineDeltaV(window1); 0.25 ms.
if (deltaV > deltaV1) { /* ... */ }

sleep(1); 0.25 ms
} τ11 τ12 τ13 τ14

} t
Timing Diagram. c11 1.0 ms c12 ...

WCET Analysis
Example Distribution of Execution Time

Darker curves shows the distribution of execution time
Lower gray curve shows the set of actually observed and measured
execution times  measured times may overestimate BCET and
underestimate WCET

WCET Analysis
WCET analysis derives an estimate that should be

safe (conservative)
Value greater than or equal to WCET
tight
Little or no overestimation compared to the WCET
Avoids over allocation of system resources
Two main methods

Measurements
“building a bridge and testing it by running heavy trucks across it”
Suitable for less time-critical software, (average case is of interest)
Static analysis
“determining the stability of a bridge by investigating its design”
Commercial tools produce estimates within a few percent of the WCET
Software Behavior
Software behavior
Contributes a large part of the execution time variability of a program.
Often dominating the effect of local hardware timing variability.
Example
Loop iterates a variable number of times depending on the input data.

Conditional statements where one branch takes longer than the other branch.

Hardware Timing
Introduction
The main complexity is the behavior of the processor itself, along with its
memory system.
IO, networks, sensor, and actuator have less impact. They usually dictate
when a program is executed in response to external stimuli, but do not affect
the instruction-level execution time.
Pipelining and caching
Improve the average case
Span between best case and worst case increases
Worst case typically gets worse
Timing becomes more dependent on the execution history

Hardware Timing
Memory Access
Different memory technologies  different memory access times
RAM technology uses a variety of techniques to take advantage of locality to
improve performance
Burst mode: time to setup up the RAM to deliver 32 or 64 bits has to be
expended only once, subsequent words can be fetched without supplying
the address.
Precise sequence of addresses of memory accesses becomes important

Hardware Timing
Pipelines
Example
IF=instruction fetch, EX=execution, M=memory, F=float (not used)

Pipeline improves execution time (5 clocks (a) instead of 7 (b))

Hardware Timing
Pipelines
Long Timing Effects (LTE)
LTE: interactions occur between instructions that are not adjacent.

WCET analysis tool has to consider LTE (if necessary, ARM7 has no LTE).
Hardware Timing
Caches
Normally improve average access time to data and instruction
Usually make worst-case access time worse. This occurs for a number of reasons,
including:
Delay before the system determines a cache miss and starts the main memory
access
a whole cache line is loaded from main memory, not just the data requested by
the processor.
Cache lockdown is a feature of some memory systems
Critical code and data (such as high-priority interrupt routines and the data they
access) is loaded into the cache in such way that the cache-lines containing
them are not subsequently re-allocated
Ensures that all subsequent accesses to the code and data are cache hits and
therefore complete quickly

Hardware Timing
Branch Prediction
Tries to predict which way a particular branch instruction will go, long before the
branch has actually be resolved in the processor pipeline
Above 75% accuracy is possible today
Branch predictors typically have complicated worst-case behavior:
there are examples of cases where executing more iterations of an inner loop
takes less time than iterating fewer iterations
Timing Anomalies
Cases where a local worst case does not entail the global worst case, for example:
a cache hit for a particular instruction causes a longer execution time for a
program than a cache miss.
a miss in a cache might create a better cache state for later code, causing the
overall execution to speed up.

Timing by Measurements
Classic Method
Execute the program many times with different input data, and then
measure the execution time for each test run.
Finding the input that causes the WCET to occur is very difficult in the
general case, and guaranteeing that it has been found is basically
impossible without some form of static analysis.
Nevertheless, measurements are often the only means immediately at the
disposal of a programmer and are useful when the average case timing
behavior of the program is of interest.

Measurement Techniques
Probe effect
Measuring a system might cause the timing to change. This is especially
common when the program is instrumented or extended with
measurement support.
Resolution
Executing code can take a very short time, and the resolution of the timing
system has to be fine enough to accurately capture the variations that
occur. Typically, you want microseconds or better resolution.
Interruptions
The program under measurement might be interrupted by hardware or OS
scheduling intervals. This will lead to intermittent large increases in the
end-to-end execution time of a program, and this effect needs to be
identified and compensated for.

Measurement Techniques
Oscilloscopes, logic analyzers: oscilloscope-based measurements typically
involves toggling a GPIO, logic analyzers needs access to the busses (not
always the case with caches).
Hardware traces: hardware that is built-in, examples Nexus, JTAG.
High resolution timers: code has to be added, timer is started and stopped.
Performance counters: special registers inside the CPU.
Profilers: can use periodic interrupts (which does not provide for very precise
measurements), or instrument the code (creates a probe effect).
OS facilities: need hardware support, OS observes the longest execution
time for a task.
Emulator: special-purpose hardware that behaves like a real processor but
with better debug and inspection capabilities.
Simulator: in practice, very few simulators are guaranteed to be totally
accurate.
Example
IAR Embedded Workbench for Atmel AVR, Simulator

Static Analysis
Phases in static WCET analysis

Static Analysis
Phases in static WCET analysis

Flow analysis
Derive bounds on the possible execution paths
Which functions get called, bounds on loop iterations, …
Low-level analysis
Determine and bound the possible timing of instructions (given the
architectural features of the target hardware)
Requires access to the actual binary code
For modern processors it is important to analyze the effects of pipelines,
caches, branch predictors, …
Calculation
Combine the flow and timing information derived in the preceding phases

Static Analysis
Path-based calculation
Calculating times for different paths in parts of a program
The time for the longest path is combined with the loop bound flow.

Static Analysis
WCET analysis tool layout

Static Analysis
Example
Bound-T vs. Profiling

Static Analysis
Example
Bound-T vs. Profiling

Assignments
Assignment 1
Read the paper “S. M. Mahmud, A. Alrabady. A New Decision Making
Algorithm for Airbag Control. IEEE Transactions on Vehicular Technology. Vol.
44, No. 3, August 1995” (see elearning) and implement the described
algorithm in C (IAR Embedded Workbench for Atmel AVR). Of course, you
don’t have to consider real accelerometer values, filtering, etc., focus on the
algorithm itself (sliding window, determination of v and L, comparison with
thresholds, etc.). Don’t use floating point numbers and OO features.
Execute the algorithm in the IAR Simulator to estimate the WCET,
use Bound-T to determine the WCET and discuss and compare both
results. Read the boundt documentation (user guide, Chapter 5: Writing
Analysable Programs) and consider that in your implementation.
Use the Windows XP VMWare Image with pre-installed free evaluation
version of both tools (IAR: 4KB Kickstart version, Bound-T: limited to 1024
instructions)

Appendix A
Motion with constant velocity

s
v
t
Distance vs. time graph

s[m]
s 9 m
10 ∆s = 9m v   0.6 m/s
t 15 s
∆t =15m
0
0 10 20 30 40 t [s]

Appendix A
Motion with changing velocity

s1 12 m
s[m]
v1    3 m/s s2 1.5 m
t1 4s ∆s2 = 1.5 m v2    0.125 m/s
∆t2 =12 s
t2 12 s
10
∆s1 = 12 m
∆t1 =4 s
0
0 10 20 30 40 t [s]
Velocity is the slope of the tangent line through the relevant point on its
distance vs. time graph.
ds
Slope is usually calculated with the derivative of a function: v 
dt
a 2
Example: s  t
2
a
s  v  2t  at
2

Appendix A
Motion with changing velocity

v[m/s]
v = const. = 0.6 m/s
0.5
0
0 10 20 30 40 t [s]
Area under the curve in the velocity vs. time graph shows the covered
distance (s = vt)
From t = 10s to t = 20s the object covered 0.6 m/s ∙10 m = 6 m

ds
v and therefore s  vdt
dt
20s
s   vdt   0.6 m/s dt 
10s
F (20s)  F (10s)  0.6 m/s  20 s  0.6 m/s 10 s  12 m  6 m  6 m

Appendix A
Acceleration: change in velocity over time

v dv
a or a 
t dt d2s
Acceleration is therefore the second derivate of the position: a  2
dt
Velocity vs. time graph, constant acceleration (a = const.):
v[m/s]
∆v = 2 m/s
v 2 m/s
2
a   2 m/s 2
∆t = 1 s t 1s
0 1 2 3 4 t [s]

Appendix A
Acceleration vs. time

a[m/s2]
0 1 2 3 4 t [s]
The area under the curve in the acceleration vs. time graph shows the
velocity (v = at)
dv
a
dt
v   adt
3
v   2 m / s 2 dt  F (3s)  F (0s)  (2 m/s 2  3 s)  (2 m/s 2  0 s)  6 m/s
0

Appendix A
Position, velocity, and acceleration
Position
ds
v s   vdt
dt
Velocity
(rate of change of position)
d2s dv
a 2
dt
a
dt v   adt
Acceleration
(rate of change of velocity)

Appendix B
Numerical Integration – Example Waveforms

a[m/s2] U[steps]
2 255
191
1 127
63
0 10 20 30 40 t [ms] 0 10 20 30 40 t [ms]
a U(t)
u[mV]
100
50
0 10 20 30 40 t [ms]
u(t)
Appendix B
Numerical Integration – Approximation with rectangles

U[steps] Area errors
b n
 f ( x)dx  lim  f ( x )x

255
191 i
n 
a i 1
ba
127
63 x 
0
n
0 10 20 30 40 t [ms]
a n=8 b
For efficiency reasons (floating point operations), the multiplication should be

performed after the summation.
Area error can be minimized by increasing the sampling frequency.

Appendix B
First order approximation with trapezoids

U[steps]
Area of a trapezoid :
h
255
1
191 A  h( a  b) a b
2
127
63
0
0 10 20 30 40 t [ms]
a n=8
n 1
f ( xi )  f ( xi 1 )
b
 f ( x)dx  lim   x
n  2
a i 1
ba
x 
n
∆x
References
References
R. Bosch GmbH. Automotive Handbook. Wiley. 2007.
P. A. Laplante. Real-Time Systems Design and Analysis: An Engineer’s
Handbook. Third Edition. Wiley. 2004.
J. W. S. Liu. Real-Time Systems. Prentice Hall. 2000.
J. Cooling. Software Engineering for Real-Time Systems. Addison-Wesley.
2003.
IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering
Terminology
http://www.euroncap.com
C. Chan. A Treatise on Crash Sensing for Automotive Air Bag System.
IEEE/ASME Transactions on Mechatronics. Vol. 7, No.2, June 2002.
S. M. Mahmud, A. Alrabady. A New Decision Making Algorithm for Airbag
Control. IEEE Transactions on Vehicular Technology. Vol. 44, No. 3, August
1995.
References
References
C. Chan. On the Detection of Vehicular Crashes – System Characteristics
and Architecture. IEEE Transactions on Vehicular Technology. Vol. 51, No. 1,
January 2002.
D. Seal. ARM Architecture Reference Manual. Second Edition. Addison-
Wesley. 2001.
A. Ermedahl, J. Engblohm. Execution Time Analysis for Embedded-Real-
Time-Systems. Handbook of Real-Time and Embedded Systems. Chapman
& Hall/CRC. 2008.
J. S. Wilson. Sensor Technology Handbook. Elsevier 2005.
G. C. Buttazzo. Hard Real-Time Computing Systems. Third Edition. Springer
2011.

01 IntroductionWCETdffdf

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01 IntroductionWCETdffdf

Uploaded by

Copyright:

Available Formats

Systems Engineering II

Introduction, Worst Case Execution Time

Introduction to Real-Time Systems

Defining Real-Time Systems

MC 516 Systems Engineering II Page 3

Defining Real-Time Systems

MC 516 Systems Engineering II Page 4

Defining Real-Time Systems

MC 516 Systems Engineering II Page 5

Defining Real-Time Systems

Attributes of real-time systems.

Hard-Slow * **** * → *** * → ****

MC 516 Systems Engineering II Page 6

Defining Real-Time Systems

Best case Worst case

MC 516 Systems Engineering II Page 7

Defining Real-Time Systems

Best case Worst case

MC 516 Systems Engineering II Page 8

Obstacle Avoidance System

MC 516 Systems Engineering II Page 9

Obstacle Avoidance System

MC 516 Systems Engineering II Page 10

Obstacle Avoidance System

Velocity during brake.

MC 516 Systems Engineering II Page 11

Obstacle Avoidance System

MC 516 Systems Engineering II Page 12

Obstacle Avoidance System

MC 516 Systems Engineering II Page 13

Obstacle Avoidance System

MC 516 Systems Engineering II Page 14

Occupant Protection Systems

Belt slack, belt stretch, delayed effect of

Occupant protection systems with belt tighteners and front airbags

MC 516 Systems Engineering II Page 15

Occupant Protection Systems

Casing Printed Circuit Board (PCB)

MC 516 Systems Engineering II Page 16

Occupant Protection Systems

Front airbag left

MC 516 Systems Engineering II Page 17

Occupant Protection Systems

– 𝜀 can be changed (e. g. moisture).

Occupant Protection Systems

MC 516 Systems Engineering II Page 19

Occupant Protection Systems

MC 516 Systems Engineering II Page 20

Occupant Protection Systems

– Constraint on real-time software: accelerometer is sampled with e. g.

Occupant Protection Systems

Timing constraint on the airbag

Deceleration to standstill and forward displacement of an occupant at an impact speed of 50 km/h.

MC 516 Systems Engineering II Page 22

Occupant Protection Systems

Pole Side Impact

MC 516 Systems Engineering II Page 23

Occupant Protection Systems

MC 516 Systems Engineering II Page 24

Occupant Protection Systems

Occupant Protection Systems

MC 516 Systems Engineering II Page 26

Occupant Protection Systems