Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 66 2009-10-13
66 Model-Based Design for Embedded Systems
in the application binary. Depending on the current cache state and the
execution history, cache misses may occur at different points in time. How-
ever, formal methods are able to identify for each basic block the maximum
number of cache misses that may occur during the execution [46]. The con-
trol flow graph can be annotated with this information, making the longest
path analyses feasible again.
Depending on the actual system configuration, the upper bound on the
number of transactions per task execution may not be sufficiently accurate.
In a formal model, this could translate into an assumed burst of requests
that may not occur in practice. This can be addressed with a more detailed
analysis of the task control flow, as is done in [1,39], which provides bounds
on the minimum distances between any n requests of an activation of that
task. This pattern will then repeat with each task activation.
This procedure allows to conservatively derive the shared resource
request bound functions ˜η
+
τ
(w) and ˜η
−
τ
(w) that represent the transaction traf-
fic that each task τ in the system can produce within a given time window
of size w. Requesting tasks that share the same processor may be executed in
alternation, resulting in a combined request traffic for the complete proces-
sor. This again can be expressed as an event model. For example, a straight-
forward approach is to approximate the processor’s request event model (in
a given time window) with the aggregation of the request event models of
each individual task executing on that processor. Obviously, this is an over-
estimation, as the tasks will not be executed at the same time, but rather the

both tasks execute in the local memory (Scenario 3.5a), the low-priority task
is kept from executing by three invocations of the high-priority tasks. Local
memory accesses are not explicitly shown, as they can be considered to be
part of the execution time. When both tasks access the same remote mem-
ory (Scenario 3.5b), the finishing time of the lower-priority task increases,
because it itself fetches data from the remote memory, and also because of
the prolonged preemptions by the higher-priority task (as its request also
stalls the processor). The execution of the low-priority task in the example
is now stretched such that it suffers from an additional preemption of the
other task. Finally, Scenario 3.5c shows the effect of a task on another core
CPUb that is also accessing the same shared memory, in this case, periodi-
cally. Whenever the memory is also used by a task on CPUb, CPUa is stalled
for a longer time, again increasing the task response times, possibly leading
to the violation of a given deadline. As the busy wait adds to the execution
t
(a)
Preemption
Stalling
CPU
Memory
CPU
(b)
Memory
CPUa
CPUb
(c)
FIGURE 3.5
Tasks on different processors accessing a shared memory. (a and b) Single
processor case and (c) conflicts from another CPU.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 68 2009-10-13

CPUa. A “worst-case memory access” will experience this delay, but of all
accesses from CPUb, this happens maximally three times in this example.
Thus, accounting this interference for every single memory access leads to
very unsatisfactory results—which has previously prevented the use of con-
servative methods in this context.
The key idea is instead to consider all requests that are processed during
the lifetime of a task jointly. We therefore introduce the worst-case accumu-
lated busy time, defined as the total amount of time, during which at least one
request is issued but is not finished. Multiple requests in a certain amount of
time can in total only be delayed by a certain amount of interference, which
is expressed by the aggregate busy time.
This aggregate busy time can be efficiently calculated (e.g., for a shared
bus): a set of requests is issued from different processors that may interfere
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 69 2009-10-13
Formal Performance Analysis 69
with each other. The exact individual request times are unknown and their
actual latency is highly dynamic. Extracting detailed timing information
(e.g., when a specific cache miss occurs) is virtually impossible and consid-
ering such details in a conservative analysis yields exponential complexity.
Consequently, we disregard such details and focus on bounding the aggre-
gate busy time. Given a certain level of dynamism in the system, this con-
sideration will not result in excessive overestimations. Interestingly, even in
multithreaded multicore architectures, the conservatism is moderate, sum-
ming up to less than a total of 25% of the overestimated response time, as
shown in practical experiments [42].
Without bus access prioritization, it has to be assumed that it is possi-
ble for every transaction issued by any processor during the lifetime of a
task activation i that it will disturb the transactions issued by i. Usually, the
interference is then given by the transactions issued by the other concur-
rently active tasks on the other processors, as well as the tasks on the same

70 Model-Based Design for Embedded Systems
T
a
T
c
T
d
T
b
ECU1 Bus
C
1
C
2
ECU2
FIGURE 3.6
Traditional model.
ES
a
HES
a,b
ES
b
ECU1 Bus ECU2
T
c
T
d
T
b

the timings of signal arrivals can only be bound with a large overestimation.
To adequately consider such effects of modern communication stacks in
the system analysis, two elements must be determined:
1. The activation timings of the frames
2. The timings of signals transmitted within these frames arriving at the
receiving side
To cope with both the challenges, we introduce hierarchical event streams
(HESs) modeled by a HEM, which determines the activating function of the
frame and also captures the timings of the signals assignedtothat frame, and,
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 71 2009-10-13
Formal Performance Analysis 71
most importantly, defines how the effects on the frame timings influence the
timings of the transmitted signals. The latter allows to unpack the signals
on the receiving side, giving tighter bounds for the activations of those tasks
receiving the signals.
The general idea is that a HES has one outer representation in the form
of an event stream ES
outer
, and each combined event stream has one inner
representation, also in the form of an event stream ES

i
, where i denotes the
task to which the event stream corresponds. The relation between the outer
event stream and the inner event stream depends on the hierarchical stream
constructor (HSC) that combined the event streams. Each of the involved
event streams is defined by functions δ
−
(n) and δ
+

, and the worst-case
HES
a,b
ES
outer
HSC
Distances between total message releases
Distances between
messages containing a
new signal from T
b
Distances between
messages containing a
new signal from T
b
δ(n)
δ(n)
δ(n)
δ
–
(n)
δ
–
(n)δ
–
(n)
23456
23456
23456
n

response time, R
max
, are obtained. Based on the outer event stream, ES
outer
,
of the hierarchical input stream, we obtain the outer event stream, ES

outer
,of
the hierarchical output stream by using the following equations:
δ

−
outer
(n) = max{δ
−
outer
(n) − J
resp
, δ

−
outer
(n − 1) + d
min
} (3.2)
δ

+
outer

−
outer
(n) and δ

+
outer
(n),
becomes the outer stream of the output model.
To obtain the inner event streams, ES

i
, of the hierarchical output stream,
we adapt the inner event streams, ES

i
, of the hierarchical input stream
according to the changes applied to the outer stream. For the adaptation,
we consider the two changes mentioned above separately. First, consider
that the minimum distance between n messages decreases by J
resp
. Then,
the minimum distance between k messages that contain the data of a spe-
cific task decreases by J
resp
. Second, we must consider that two consecu-
tive messages become separated by a minimum distance d
min
. Figure 3.9a
illustrates a sequence of events consisting of two different event types,
a and b. Assume that this event sequence models the message timing, where

δ
–
b

(2)
δ
+
b
(2)
d

min
a
b
a
a
b b t΄
δ
–
b

(2)
FIGURE 3.9
(a) The event sequence before applying the minimum distance and (b) the
event sequence after considering the minimum distance d
min
.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 73 2009-10-13
Formal Performance Analysis 73
minimum (maximum) distance between events that can occur because of the


−
i
(n − 1) + d
min
},
δ

+
i
(n) = δ

+
i
(n) + J
resp
+D
max
To determine the activation timings of the receiving tasks, T
c
and T
d
,we
now have not only the arrival times of messages, but also the timings of
exactly those messages that contain new data from a certain sending task,
given by the corresponding inner stream. Assuming that the task T
c
is only
activated every time a new signal from the task T
a

74 Model-Based Design for Embedded Systems
transition to a specific internal state requiring an SC. Depending on the task
behavior across an SC, three types of tasks are defined:
• Unchanged task: An unchanged task belongs to both task sets of the ini-
tial (old) and the new scenario. It remains unchanged and continues
executing normally after the SCR.
• Completed task: A completed task only belongs to the old scenario task
set. However, to preserve data-consistency, completed task jobs acti-
vated before the SC are allowed to complete their execution after the
SCR. Then the task terminates.
• Added task: An added task only belongs to the new scenario task set.
It is initially activated after the SCR. Each added task is assigned an
offset value, φ, that denotes its earliest activation time after the SCR.
During an SC, executions of completed, unchanged, and added tasks may
interfere with one another, leading to a transient overload on the resource.
Since the timing requirements in the system have to be met at any time dur-
ing the system execution, it is necessary to verify if task deadlines could be
missed because of an SC.
Methods analyzing the timing behavior across an SC under static-priority
preemptive scheduling already exist [32,45,47]. However, they are limited
to independent tasks mapped on single resources. Under such an assump-
tion, the worst-case response time for an SC for a given task under analysis
is proved to be obtained within the busy window during which the SCR
occurs, called the transition busy window. These approaches can however
not be applied to distributed systems because of the so-called echo effect.
The echo effect is explained in the following section using the system exam-
ple in Figure 3.11.
3.5.1 Echo Effect
The system used in the experiments of Section 3.8 (depicted in Figure 3.11)
represents a hypothetical automotive system consisting of two IP compo-

window. Rather, the activations within the successive busy windows need to
be considered.
3.5.2 Compositional Scenario-Aware Analysis
The previous example illustrates how difficult it is to predict the effect of
the recurrent transient overload after an SC in a distributed system. As a
consequence of this unpredictability, it turns to be very difficult to describe
the event timings at task outputs and therefore to describe the event tim-
ings at the inputs of the connected tasks, needed for the response time cal-
culation across the SC. To overcome this problem, we need to describe the
event timing at each task output, in a way that covers all its possible tim-
ing behaviors, even those resulting from the echo effect that might occur
afteranSC.
This calculation is performed by extending the compositional methodol-
ogy presented in Section 3.2 as follows. As usual, all external event models at
the system inputs are propagated along the system paths until an initial acti-
vating event model is available at each task input. Then, global system anal-
ysis is performed in the following way. In the first phase, two task response
time calculations are performed on each resource. First, for each task we cal-
culate its worst-case response time during the transition busy window. This
calculation is described in detail in [13]. Additionally, for each unchanged or
added task, using the classical analysis techniques we calculate its worst-case
response times assuming the exclusive execution of the new scenario. Then,
for each task, a response time interval is built into which all its observable
response times may fall (i.e., the maximum of its response time during the
transition busy window and its response time assuming the exclusive exe-
cution of the new scenario). The tasks’ best-case response times are given by
their minimum execution times in all scenarios.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 76 2009-10-13
76 Model-Based Design for Embedded Systems
Having determined a response time interval across the SC for each task,

3.6.1 Performance Characterization
This aspect investigates the behavior of the performance metrics when apply-
ing modifications of different system properties. Using the mathematical
properties of the functions describing the performance metrics, one can show
the dependency between the values of the system properties specified in the
input model and the values of the performance metrics. This is especially
important for system properties leading to a discontinuous behavior of the
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 77 2009-10-13
Formal Performance Analysis 77
performance metrics. The system designer can efficiently use this informa-
tion to apply the required modifications without critical consequences on
the system’s performance.
Of special interest is the characterization of system properties whose vari-
ation leads to a nonmonotonic behavior of the performance metrics, referred
to as timing anomalies. Such anomalies mostly occur because of inter-task
functional dependencies, which are directly translated into timing depen-
dencies in the corresponding performance model. The analyses of timing
anomalies become relevant in the later design phases, when the estimated
property values turn into concrete, fixed values. It is important for the system
designer to know the source of such anomalies and which of the property
values correspond to nonmonotonic system performance behavior. Since
it divides the nonmonotonic—performance unpredictable—design configu-
ration space into monotonic—performance predictable—subspaces, timing
anomaly analysis is an important element of the design space exploration
process.
3.6.2 Performance Slack
In addition to performance characterization, sensitivity analysis determines
the bound between feasible and infeasible property values. This bound is
called the sensitivity front. The maximum amount by which the initial value
of a system property can be modified without jeopardizing the system feasi-

• System robustness optimization: Based on the slack values, the designer
defines a set of robustness metrics to cover different possible design
scenarios. In order to maximize the system robustness at a given cost
level, the defined robustness metrics are used as optimization objec-
tives by automatic design space exploration and optimization tools
[12]. The scope is to obtain system configurations with less sensitivi-
ties to later design changes. More details are given in Section 3.7.
• System dimensioning: To reduce the global system cost, the system
designer can decide to use the performance slack for efficient system
dimensioning. In this case, instead of looking for system configurations
that can accommodate later changes, the performance slack is used to
optimize the system cost by selecting cheaper variants for processors,
communication resources, or memories. A sufficient slack may even
suggest the integration of the entire application on alternative plat-
forms, reducing the number of hardware components [30]. Note that
lower cost implies lower hardware costs on one side, and lower power
consumption and smaller size on the other.
The sensitivity analysis approach has been tailored differently in order to
achieve the previous design goals. Thus, to perform robustness optimization,
the sensitivity analysis was integrated into a global optimization framework.
For the evaluation of the robustness metrics it is not necessary to accurately
determine the sensitivity front. Instead, using stochastic analysis, the sensi-
tivity front can be approximated using two bounds for the sensitivity front:
the lower bound determines the minimum guaranteed robustness (MGR),
while the upper bound determines the maximum possible robustness (MPR).
The benefit of using a stochastic analysis instead of an exact analysis is the
nonexponential complexity with respect to the number of dimensions, which
makes it suitable for a large number of variable system properties. Details
about the implementation are given in [12].
For the second design scenario, the exact sensitivity front is required

behaviors. It rather represents an intrinsic system property that depends on
the system organization (architecture, application mapping, etc.) and its con-
figuration (scheduling, etc.).
Accounting for property variations early during design is key, since even
small modifications in systems with complex performance dependencies can
have drastic nonintuitive impacts on the overall system behavior, and might
lead to severe performance degradation effects [29]. Since performance eval-
uation and exploration do not cover these effects, it is clear that the use of
these methods alone is insufficient to systematically control system perfor-
mance along the design flow and during system lifetime. Therefore, explicit
robustness evaluation and optimization techniques that build on top of per-
formance evaluation and exploration are needed. They enable the designer
to introduce robustness at critical positions in the design, and thus help to
avoid critical performance pitfalls.
3.7.1 Use-Cases for Design Robustness
In the following, we discuss situations and scenarios where robustness of
hardware and run-time system performance against property variations is
expected and is crucial to efficiently design complex embedded systems.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 80 2009-10-13
80 Model-Based Design for Embedded Systems
Unknown quality of performance data: First, robustness is desirable to account
for data quality issues in early design phases, where data that are required
for performance analysis (e.g., task execution times and data rates) are often
estimated or based on measurements. As a result of the unknown input data
quality, also the expressiveness and accuracy of performance analysis results
are unknown. Since even small deviations from estimated property values
can have severe consequences on the final system performance, it is obvious
that robustness against property variations leverages the applicability of for-
mal analysis techniques during design. Clearly, design risks can be consid-
erably reduced by identifying performance critical data and systematically

ness against input rate increases.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 81 2009-10-13
Formal Performance Analysis 81
In this chapter, sensitivity analysis is systematically utilized for general
robustness evaluation and optimization purposes. More precisely, instead
of consuming the available slack for system dimensioning, and thus cost
minimization, the slack is distributed so that the system’s capability of sup-
porting property variations is maximized. Using sensitivity analysis as a
basis for robustness evaluation and optimization has two important advan-
tages compared to previous approaches.
1. State-of-the-art modular sensitivity analysis techniques capture com-
plex global effects of local system property variations. This ensures the
applicability of the proposed robustness evaluation and optimization
techniques to realistic performance models, and increases the expres-
siveness of the results.
2. Rather than providing the system behavior for some isolated dis-
crete design points [4,7], sensitivity analysis characterizes continuous
design subspaces with identical system states. It thus covers all possible
system-property variation scenarios.
3.7.3 Robustness Metrics
In order to optimize robustness, we need, on the one hand, expressive robust-
ness metrics and, on the other hand, efficient optimization techniques. In
general, robustness metrics shall cover different design scenarios.
3.7.3.1 Static Design Robustness
The first considered design scenario assumes that system parameters are
fixed early during design and cannot be modified later (e.g., at late design
stages or after deployment) to compensate for system property modifica-
tions. This scenario is called static design robustness (SDR).
The SDR metric expresses the robustness of parameter configurations
with respect to the simultaneous modifications of several given system prop-

cific components ensuring their correct functioning in the global context. This
information efficiently facilitates feasibility and requirements analysis and
greatly assists the designer in pointing out critical components requiring spe-
cial focus during specification and implementation. Another use-case con-
cerns reconfigurable systems. The DDR metric can be used to maximize the
dynamic robustness headroom for crucial components. Obviously, by choos-
ing a system architecture offering a high DDR for crucial system parts early,
the designer can significantly increase system stability and maintainability.
Note that the DDR optimization yields multiple parameter configura-
tions, each possessing partially disjoint robustness properties. For instance,
one parameter configuration might exhibit high robustness for some sys-
tem properties, whereas different parameter configurations might offer more
robustness for other system properties.
Figure 3.10a and b visualize the conceptual difference between the notions
of the SDRand theDDR by meansof a simpleexample. Figure3.10a shows the
feasibleregionoftwopropertiesp
1
andp
2
,i.e.,theregioncontainingallfeasible
property value combinations, of a given parameter configuration. This corre-
sponds to the static robustness, where a single parameter configuration with
high robustness needs to be chosen. Figure 3.10b visualizes the dynamic
robustness. In the considered case, there exist two additional parameter
configurationsintheunderlyingreconfigurationspacewithinterestingrobust-
ness properties. Both new parameter configurations contain feasible regions
that are not covered by the first parameter configuration. The union of all
three feasible regions corresponds to the dynamic robustness.
3.8 Experiments
In this section, the formal methods presented in this chapter are applied

10
8
6
4
2
0
Property p
1
Property p
2
0 2 4 6 8 10 12 1614
FIGURE 3.10
Conceptual difference between the SDR and the DDR for two considered
system properties subject to maximization.
Shared memory
HW
IP1 IP2
SigOut
ECU1
eval1ctrl1
eval2ctrl2
calc
ctrl3
exec2
exec1
mon2
mon3
mon1
Multicore ECU
ECU4

In the following, we will assume that these two applications are running
mutually exclusive. For example, as soon as the driver shifts into the reverse
gear, the parking-assistant application (Scenario 2) becomes active, and the
ESP (Scenario 1) is deactivated.
The tasks on ECU1 are scheduled according to a round-robin scheduling
policy, while all other ECUs implement a static-priority preemptive schedul-
ing policy. Core execution and communication times, and the scheduling
parameters (priority and time slot size) of all tasks in the system are specified
in Table 3.1. Additionally, for tasks on the multicore ECU, the memory access
time is explicitly given for each task, to allow considering the contention
on the shared memory. (On single-core ECUs, the memory access time is
contained in the core execution time.) For the communication, we assume
that the transmission mode of the communication layers is direct and that
TABLE 3.1
Core Execution/Communication Time and Memory Access Time
Per Task
Task Exec./Comm. Memory Access Scheduling
HW Name Time (in ms) Time Parameter
Multicore ECU ctrl1 [10:22] [0:2] Prio: High
ctrl2 [20:20] [0:1] Prio: Low
eval1 [12:14] [0:4] Prio: High
eval2 [26:26] [0:6] Prio: Low
ECU1 exec1 [20:20] — Time Slot size: 5
exec2 [30:30] — Time Slot size: 10
ECU2 mon1 [10:15] — Prio: High
mon2 [12:18] — Prio: Low
ECU3 mon3 [20:20] — Prio: High
ECU4 calc [1:1] — Prio: High
ctrl3 [20:20] — Prio: Low
CAN Bus C1 [6:6] — Prio: Highest

12
10
8
6
4
2
0
0 71 142 213 284 355
Time interval
Event number
426 497 568 639 710
η
+
-frame arrivals
η
+
-signals_ctrl1 η
+
-signals_ctrl2
FIGURE 3.12
Message arrivals at ECU1 vs. signal arrivals.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 86 2009-10-13
86 Model-Based Design for Embedded Systems
messages that can arrive at ECU1. Using flat event models, we could only
assume that every message contains a new signal for both receiving tasks,
which results in a load of 91.58% of ECU1. With the HEM, we also obtain the
maximum number of messages that contain a signal that was sent by task
ctrl1 (marked by squares), and the maximum number of messages contain-
ing a signal from ctrl2 (marked by triangles). If we now use the timings of
signal arrivals as activation timings of the receiving tasks, we obtain a much

mum latency of 39 ms for the path IP1 → IP2 and 131 ms for the parking-
assistant application path. Thus, we notice that there is an improvement in
the calculated maximum latencies of the constrained application paths. How-
ever, the path IP1 → IP2 slightly exceeds its constraint.
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 87 2009-10-13
Formal Performance Analysis 87
1
0.8
0.6
0.4
0.2
0
Initial value Slack
BUS ECU1 ECU2 ECU3 ECU4
FIGURE 3.13
One-dimensional slack of the resource speeds.
3.8.4 Optimizing Design
As the design is not feasible in its current configuration, we need to optimize
the critical path IP1 → IP2 latency. For this, we can explore the priority
configuration of the communication tasks on the CAN bus. This can be per-
formed automatically on the basis of genetic algorithms (refer to [11] for
details). A feasible configuration is obtained for the following priority order:
C1 > C2 > C5 > C3 > C4. The obtained maximum path IP1 → IP2 latency
is equal to 29. Even though the maximum latency of the parking-assistant
applicationincreasedfrom131to138,thisisstilllessthantheimposedconstraint.
3.8.5 System Dimensioning
According to Section 3.6, the performance slack of the system components
can be efficiently used in order to select hardware components that are opti-
mal with respect to cost. The diagram presented in Figure 3.13 shows the
minimum speed of the CAN bus and the single-core ECUs. The presented

the IEEE Real-Time and Embedded Technology and Applications Symposium
(RTAS), San Jose, CA, April 2006.
5. J. L. Boudec and P. Thiran. Network Calculus: A Theory of Deterministic
Queuing Systems for the Internet. Springer, Berlin, 2001.
6. S. Chakraborty, S. Künzli, and L. Thiele. A general framework
for analysing system properties in platform-based embedded system
designs. In Proceedings of the IEEE/ACM Design, Automation and Test in
Europe Conference (DATE), Munich, Germany, 2003.
7. P. Emberson and I. Bate. Minimising task migration and priority changes
in mode transitions. In Proceedings of the IEEE Real-Time and Embedded
Technology and Applications Symposium (RTAS), Seatlle, WA, April 2007.
8. J. Filipiak. Real Time Network Management. North-Holland, Amsterdam,
the Netherlands, 1991.
9. O. Gonzalez, H. Shrikumar, J. Stankovic, and K. Ramamritham. Adap-
tive fault tolerance and graceful degradation under dynamic hard
Nicolescu/Model-Based Design for Embedded Systems 67842_C003 Finals Page 89 2009-10-13
Formal Performance Analysis 89
real-time scheduling. In Proceedings of the IEEE International
Real-Time Systems Symposium (RTSS), San Francisco, CA, December
1997.
10. W. Haid and L. Thiele. Complex task activation schemes in system level
performance analysis. In Proceedings of the IEEE/ACM International Con-
ference on HW/SW Codesign and System Synthesis (CODES-ISSS), Salzburg,
Austria, September 2007.
11. A. Hamann, M. Jersak, K. Richter, and R. Ernst. Design space explo-
ration and system optimization with SymTA/S-symbolic timing analysis
for systems. In Proceedings 25th International Real-Time Systems Symposium
(RTSS04), Lisbon, Portugal, December 2004.
12. A. Hamann, R. Racu, and R. Ernst. A formal approach to robustness max-
imization of complex heterogeneous embedded systems. In Proceedings

embedded hardware and software systems. Journal of Circuits Systems and
Computers, 12(3):231–260, 2003.
22. P. Lee, T. Anderson, J. Laprie, A. Avizienis, and H. Kopetz. Fault Toler-
ance: Principles and Practice. Springer Verlag, Secaucus, NJ, 1990.
23. J. Lehoczky. Fixed priority scheduling of periodic task sets with arbitrary
deadlines. In Proceedings of the IEEE Real-Time Systems Symposium (RTSS),
Lake Buena Vista, FL, 1990.
24. J. Lemieux. Programming in the OSEK/VDX Environment. CMP Books,
Lawrence, KS, 2001.
25. C. Lu, J. Stankovic, S. Son, and G. Tao. Feedback control real-time
scheduling: Framework, modeling, and algorithms. Real-Time Systems
Journal, 23(1–2):85–126, 2002.
26. A. Maxiaguine, S. Künzli, S. Chakraborty, and L. Thiele. Rate analysis for
streaming applications with on-chip buffer constraints. In Proceedings of
the IEEE/ACM Asia and South Pacific Design Automation Conference (ASP-
DAC), Yokohama, Japan, pp. 131–136, January 2004.
27. M. Negrean, S. Schliecker, and R. Ernst. Response-time analysis of arbi-
trarily activated tasks in multiprocessor systems with shared resources.
In Proceedings of Design, Automation and Test in Europe (DATE 2009),Nice,
France, April 2009.
28. K. Poulsen, P. Pop, V. Izosimov, and P. Eles. Scheduling and voltage
scaling for energy/reliability trade-offs in fault-tolerant time-triggered
embedded systems. In Proceedings of the IEEE/ACM International Confer-
ence on HW/SW Codesign and System Synthesis (CODES-ISSS), Salzburg,
Austria, October 2007.
29. R. Racu and R. Ernst. Scheduling anomaly detection and optimization for
distributed systems with preemptive task-sets. In 12th IEEE Real-Time and
Embedded Technology and Applications Symposium (RTAS),SanJose,CA,
April 2006.
30. R. Racu, A. Hamann, and R. Ernst. Automotive system optimization