An analysis of the AUTOSAR OS timing protection mechanism∗

Dominique Bertrand, Sébastien Faucou, Yvon Trinquet

IRCCyN / Université de Nantes
1 rue de la Noë BP 92101
F-44321 Nantes, France
Firstname.Name@univ-nantes.fr

Abstract from each other in the space (access to memories and de-
vices) and time (access to the CPU) domains.
The in-vehicle embedded system market is evolving to- The operating system kernel specified in the AU-
ward a large improvement of the industrialization of the TOSAR OS standard [2] extends the set of services pro-
embedded software. One of the technical consequences vided by the OSEK/VDX OS standard (widely used in the
of this evolution is the mandatory integration of protec- automotive domain) with several protection mechanisms.
tion mechanisms in the embedded operating system ker- We have realized an evaluation of this mechanism and re-
nels to support the design of multi-suppliers multi-critical port our main conclusions in this paper.
component-based embedded software. In this paper, we The paper is organized as follow: in section 2, we de-
evaluate such a mechanism: the timing protection mecha- scribe the kind of faults that the mechanism shall be able
nism proposed in the AUTOSAR OS standard. This eval- to detect and confine; in section 3, we briefly describe
uation shows that the present version of the mechanism is similar mechanisms used in comparable RTOS; in section
not fully adapted to multi-critical systems because it does 4, we describe the mechanism; in section 5, we compare
not handle soft/non real-time applications. the mechanism with the other proposals; in section 6, we
summarizes the results of a set of simulation that high-
light some limitations of the mechanism ; in section 7, we
1. Introduction propose and evaluate two techniques for configuring the
mechanism; in section 8, we conclude.
Two emerging families of standards are deeply impact-
ing the in-vehicle embedded system market: AUTOSAR 2. Fault, error and failure in the time domain
and ISO 26262.
The AUTOSAR (AUTomotive Open System ARchi- A timing protection mechanism is useful because faults
tecture) family of standards specify the organization of (occurring at design time or at run time) introduce latent
modern in-vehicle embedded software systems so as to errors in the system, some of which can result in failures
ease up the design of multi-supplier systems, leverage the in the time domain. We adopt the following definition of
re-use of standardized off the shelf components and in- a failure in the time domain: a service fails in the time
crease the overall flexibility of the design process of these domain if its response time exceeds its deadline.
systems. Several faults can be sources of failures in the time do-
The ISO26262 family of standards define the de- main.
pendability requirements of in-vehicle embedded systems A first category consists of the faults that occur at run-
through the concept of Automotive Safety Integrity Level time and target hardware components. Let us take some
(ASIL, ranging from A, the least critical, to D, the most exemples. A failing sensor can adopt a babbling idiot be-
critical). havior and continuously send interruption requests to the
These on-going works illustrate the evolution of the CPU. As a consequence, the associated interrupt service
in-vehicle embedded system market toward the industri- routine is activated at a higher frequency than expected.
alization of the software. Modern embedded software are A bit flip hitting the program counter or the instruction
made up of components designed by different suppliers, register or a variable involved in the control structure of
involved in functions of different criticality levels. This the running program can lead the active job to execute an
evolution has important technical consequences on the ba- unwanted sequence of instructions (among other effects).
sic software components, especially the operating system As a consequence, the execution time of the job targeted
kernel that must be able to insulate the components one by the fault can exceed its expected WCET. Usually, faults
∗ Work partly supported by project SCARLET financed by ANR of this category produce errors in several domain (for in-
(Agence National de la Recherche, programme PREDIT). stance, a corruption of the instruction register could also

978-1-4244-2728-4/09/$25.00 ©2009 IEEE

raise an illegal opcode exception, or a memory access ex- tive partition is performed by a local scheduler, using for
ception). Thus, most of the times, their consequences are instance the FPP (Fixed Priority Preemptive) policy. This
detected and potentially recovered before to impact the mechanism prevents the propagation of fault between par-
time domain. However, an ECU hosting software compo- titions, but does not provide protection inside partitions.
nents involved in ASIL C or D functions shall be protected The DECOS Core OS (COS) from TTTech [16] is also
against these faults. based on a static cyclic partition scheduler. This RTOS
A second category consists of the faults that occur at has been designed to allow the safe integration of different
design time and target software components. In this cate- subsystems on a single embedded hardware. Each subsys-
gory, the main fault is the under estimation of the WCET tem is mapped onto a partition. At runtime, the COS ker-
of the jobs. This fault can be accidental (failure of a static nel ensures a strict separation of the partitions in the time
analysis tool used to compute WCET for instance), but it and space domain. To ease up the integration of subsys-
is more likely to be intentional, at least for low critical- tems with different dynamics, a partition can have more
ity jobs. We agree with Vestal in [17]: “[...] the higher than one time slot in the cyclic schedule.
the degree of assurance required that actual task execu- The DEOS kernel (avionics domain) [7] of Honeywell
tion times will never exceed the WCET parameters used uses a multi-rate FPP scheduling of partitions. Each par-
for analysis, the larger and more conservative the latter tition is triggered periodically. When it is triggered, a
values become in practice. For example, at low critical- watchdog is set. When the watchdog expires, the parti-
ities the worst time observed during tests of normal op- tion is preempted. According to the FPP policy, it can also
erational scenarios can be used. [...] At highest criti- be preempted by the activation of a higher priority parti-
cality, some code flow analysis and worst-case instruction tion. In this case, the watchdog of the preempted partition
cycle counting can be done”. The work of Vestal deals is paused. It is resumed when the higher priority partition
with multi-critical systems in the avionics domain. We ar- has consumed its slot. This mechanism is accompanied by
gue that its conjecture shall be considered for upcoming a slack stealer [14] to enhance the responsiveness of non
multi-critical in-vehicle embedded software systems and critical jobs while ensuring the timeliness of critical ones.
we propose to evaluate the performances of AUTOSAR The OASIS kernel (nuclear domain) [10] of CEA uses
OS timing protection mechanism in this context. a multitask preemptive scheduler. Contrary to the previ-
ous examples, it does not provide hierarchical scheduling.
3. Timing protection in RTOS An OASIS system is composed of a set of not-neccessary
periodic communicating tasks. Each task executes a se-
In a RTOS equipped with a timing protection mecha- quence of actions. Each action is insulated in the time
nism, the scheduler is capable to insulate the jobs to pre- domain: it is time-triggered and preempted if its watch-
vent the propagation of faults in the time domain. Each dog expires. Built on top of this fine grain time protection
job is associated with a set of parameters that capture its mechanism, OASIS supports a fully deterministic inter-
real-time requirements. These parameters are used to test agents communication model.
the schedulability of the system (off-line in the automo-
tive domain). If the test is passed successfully, the job is 4. Timing protection in AUTOSAR OS
accepted in the system. If the behavior of the job con-
forms to the parameters, it will receive enough CPU time 4.1. AUTOSAR OS Scheduler
to complete within its deadline, regardless of the behavior AUTOSAR OS [2] proposes two concepts to manipu-
of the concurrent jobs. If the behavior of the job deviates late control flows: tasks and OsIsr (interrupt service rou-
from the parameters, an error handling action is engaged tines). Tasks are used for control flows triggered by inter-
(the job is paused, killed, etc.). nal (software) requests ; OsIsr are used for control flows
In the following, we highlight some existing RTOS triggered by external (hardware) requests. Each task and
equipped with a timing protection mechanism. We restrict each OsIsr is statically associated with a program. When
our list to RTOS using a static cyclic scheduling policy or a program execution request is accepted by the system, an
a fixed priority preemptive scheduling policy which are instance of the corresponding task or OsIsr is created.
the most commonly used policies for in-vehicle embed- Two types of task exist: basic task and extended task.
ded systems. The program of a basic task has to follow a run-to-
The ARINC 653 standard [1] for real-time avionics completion semantics, whereas the program of an ex-
system ensure timing protection by using a static cyclic tended task is allowed to use the AUTOSAR OS event ser-
scheduling of partitions. Each application is associated vice. This difference is illustrated by the graph of the task
with a partition. Each partition is active (owns the CPU) state automata (fig. 1): the dashed part of the graph is ac-
periodically, for the duration of a time slot. Thus, the cessible only by instances of extended tasks (the meaning
scheduling is independent of the actual execution times of constants and stopwatch variables labeling the graph
of the jobs in the system. The period of the system, as are explained below). Multiple instances of a basic task
well as the duration of the different time slots, are defined can be active at the same time. In this case they are sched-
off-line. The scheduling of the concurrent jobs of the ac- uled FIFO. Only one instance of an extended task can be
 systems. Before the publication of AUTOSAR OS, two at-
tempts had been made to alleviate this weakness: OSEK-
time and HiS OSEK. Both attempts proposed to use dead-
line monitoring to ensure the detection of deadline over-
runs. Deadline monitoring allows to trigger a recovery
action when a failure is detected, but it does not prevent
the propagation of faults between jobs. For this reason, it
has not been considered for inclusion in AUTOSAR OS.
A fault detection and confinement mechanism has been
preferred. This mechanism consists in:

• controlling the inter-arrival time of the jobs coming

from a same task;
Figure 1. Description of a part of the tim- • controlling the execution time of the jobs coming
ing protection mechanism: inter-arrival rate from a same task;
and execution time
• controlling the locking time the jobs coming from a
same task can impose to jobs with greater priority.
active at a given time.
Two categories of OsIsr exist: category 1 and category The configuration of the mechanism is realized off-line
2. As the execution of category 1 OsIsr instances cannot by defining a set of constants described in table 1. At run-
be controlled by the kernel, we restrict our study to sys- time, the constants are used by the kernel to set watchdogs
tem containing no category 1 OsIsr. From the scheduler whose expiration enables (control of minimal inter-arrival
and timing protection point-of-view, category 2 OsIsr are time) or disables (control of maximal execution time or
similar to basic task. Thus, from now on, we will only maximal locking time) possible behavior of the jobs of a
deal with tasks. task. These watchdogs are attached to a hardware timer
To abstract away from these different types of schedu- that periodically raises a non maskable interrupt.
lable objects, we use from now on the concept of job. A If a job tries to adopt a forbidden behavior, the job
job is created when a task instance crosses the Activate is terminated by the kernel and all its resources are un-
or Release transition. It is completed when the same in- locked. A user-provided error handling functions is also
stance crosses the Wait or Terminate transition. Thus, a executed. This function can command the termination or
basic task instance creates only one job, whereas an ex- re-initialization of the application owning the job, or the
tended task instance creates one or more jobs. Each job shutdown of the OS.
has a response time, defined as the difference between its The stopwatch automata of figure 1 describes the de-
completion date and its creation date. sired behavior of the watchdogs used to control the inter-
Each time it is invoked, the scheduler selects the oldest arrival time and the execution time of jobs. Transition la-
job among the jobs with the highest priority among the ac- bels conform to the pattern Event: guard/substitution.
tive jobs (FPP/FIFO policy: fixed priority preemptive with State labels are composed of 3 lines: state name, state
first in first out as a secondary criterion to break ties). This dynamics (rate of stopwatch variables in this state) and
job is dispatched to the CPU for execution until the next state invariant. Constants F (TIMEFRAME in table 1) and
invocation of the scheduler. When a job is created, its pri- watchdog f (resp. C (EXECUTIONBUDGET in table 1)
ority is set to the static priority of its task. When the job and c) control the inter-arrival rate (resp. the execution
enters a critical section, its priority is raised to the ceil- time) of jobs. When the execution of a job does not con-
ing priority of this section. When the job leaves a critical form to this model, a fault is detected.
section, its priority is set back to its former priority. Ceil- The behavior of watchdogs for locking times can be
ing priorities of critical sections are set according to the easily described in natural language: when a job enters
Immediate Priority Ceiling Protocol [8]. The scheduler is a critical section (takes a resource or masks some or all
invoked each time a job is created and each time the run- the interrupts), the watchdog is set. When the job leaves
ning job leaves a critical section. the critical section (releases a resource or unmasks the
More details on AUTOSAR OS scheduling policy can masked interrupts) it is reset. If it expires, a fault is de-
be found in [2] and [11]. tected.

4.2. Timing protection 5. Comparison with other RTOS

The AUTOSAR OS standard is the descendant of the
OSEK/VDX OS standard, that does not include any pro- Let us compare the timing protection mechanism de-
tection mechanism (neither in the space nor in the time scribed above with the related services provided by the
domain). Therefore, it shall not be used to operate critical RTOS listed in section 3.
 For each task
TIMEFRAME minimal time between two creations of job by the task
EXECUTIONBUDGET maximal execution time of a job of the task
MAXALLINTERRUPTLOCKTIME maximal time for which a job of the task is allowed to lock all interrupts
MAXOSINTERRUPTLOCKTIME maximal time for which a job of the task is allowed to lock cat 2 interrupts
For each task, for each resource
RESOURCELOCKTIME maximal time for which a job of the task is allowed to lock the resource
Table 1. Constants for the configuration of the timing protection mechanism

First, the timing protection mechanism of AUTOSAR n ≤ 18, all tasks have different periods). The possible
OS prevents the propagation of faults in the time domain, values are chosen with an algorithm based on [12] (in our
in the sense that a misbehaving job cannot lengthen the re- study T = 2u2 × 3u3 × 5u5 with u2 , u3 ∈ {0, 1, 2} and
sponse time of other jobs in the system more than an off- u5 ∈ {0, 1} in order to obtain a sufficient and representa-
line computed bound (see for instance [3] or [13] to find tive diversity of values). The WCET is set by one of the
algorithms that compute upper bounds on the response three algorithms presented in [4] (UScaling, UFitting and
times of the jobs in a system scheduled according to AU- UUniFast). The deadlines are set so that the ratio Di /Ti
TOSAR OS scheduling policy based on the knowledge of is constant. The priorities are set according to the dead-
their minimal inter-arrival time, their maximal execution line monotonic algorithm (known to be optimal for this
time and their worst-case locking time). As highlighted type of system as long as Di /Ti ≤ 1). Thus, the be-
in [15] and contrary to the RTOS cited in section 3, this havior of the generator is controlled by setting three pa-
does not provide a true insulation of jobs in the time do- rameters: n (number of tasks), U (system utilization, i.e.
n
main: the behavior of a job still interfere with the behavior i=1 Ci /Ti ) and D/T (hardness of the real-time con-
P
of the other jobs in the system. straints).
Second, in the case of the activation of an error in the Table 2 shows the maximal value, minimal value, mean
time domain (over-activation or over-run), an AUTOSAR value and standard deviation obtained for Ci and Ci /Di
OS kernel kills the faulty job. The solution is rather strict, on 50 runs of the generator configured with n = 10, U =
especially when it targets non hard real-time applications. 0.9 and Di /Ti ∈ {1, 0.75, 0.67}.
On the contrary, RTOS based on partition scheduling (AR-
INC 653, COS or DEOS for instance) offer a better sup- Di /Ti max min m σ
port: when the execution time of a job exceeds its ex- Ti * 180 1 34,35 49,09
pected limit, the reaction is local to the partition, i.e. the
application. A hard real-time application will certainly 1 0.3300 0.0004 0.0889 0.0721
Ci /Di 0.75 0.4400 0.0006 0.1185 0.0961
kill the job and trigger a recovery function, whereas a
0.67 0.4925 0.0007 0.1327 0.1076
soft or non real-time application can give the job a sec-
ond chance to complete (this is especially efficient if the
Table 2. Behavior of the generator config-
RTOS is capable of exploiting the slack time existing in
ured with n = 10, U = 0.9 and Di /Ti ∈
the schedule as in DEOS). This feature may cause prob-
{1, 0.75, 0.67}.
lems in the emerging use-case of multi-ASIL ECU. In the
follow-up, we investigate this problem. We first show that
a naïve configuration of the timing protection mechanism
The simulator is based on the TrueTime Mat-
can lead to an important decrease of the QoS of the system lab/Simulink toolbox [9], with a few modifications to im-
in some circumstances. Then, we propose and evaluate plement the simulation of the timing protection mecha-
some alternative solutions. nism. Concerning the simulation of faults, we have cho-
sen to only consider WCET underestimation because this
6. Evaluation of the mechanism type of fault is the most likely to happen (in the context
of the automotive domain). It is impossible to simulate
The mechanism is implemented in a simulation tool. the system in its real lifetime, thus the apparition rate of
The tool has two parts : the architecture generator and the fault has to be artificially augmented. As we want to stress
simulator. the timing protection mechanism, we also have to increase
The architecture generator generates task sets. Each the importance of the fault (i.e. the difference between the
set is composed of n tasks where each task τi is charac- estimated WCET and the effective WCET). Thus, the ex-
terized by four parameters: its period Ti , its WCET Ci , ecution time of each job of task τi is chosen in an inter-
its deadline Di and its priority Pi . Every Ti time units, val [cmin Ci , cmax Ci ] according to a uniform distribution
the task creates a job that must access the CPU during (where cmin and cmax are parameters of the simulation).
Ci time units within the next Di time units. The period Other distributions have been tested but the results were
of each task is randomly chosen in a list of 18 values (if less significant and the uniform distribution is more sim-
ple to handle. 7. Improvements
In the first experiment, the generator is configured with
n = 10, U = 0.9 and Di /Ti = 0.67. The simulator is The timing protection mechanism proposed by AU-
configured with cmin = 0.95 and cmax = 1.15: actual TOSAR OS does not use a slack stealing mechanism.
execution times can be lower or greater than the estimated Thus, it cannot use dynamic slack time, i.e. time reserved
WCET. Each simulation is stopped after the execution of for some critical jobs but not used. Nevertheless, if prop-
5000 jobs. 50 architectures have been generated and simu- erly configured, it can use static slack time, i.e. time not
lated with and without timing protection. The timing pro- reserved by critical jobs. In this section, we expose how
tection mechanism is configured with TIMEFRAME=Ti this can be achieved by using the results of Bini and co-
and EXECUTIONBUDGET=Ci (we consider indepen- authors on sensitivity analysis of fixed priority preemptive
dant tasks, thus we are not interested in the locking time systems [6], and we measure by simulation the benefits
budgets). When the timing protection is active, we mea- obtained from this approach.
sure the number of jobs killed before their termination.
When the timing protection is inactive, we measure the 7.1. C-space computation for fixed priority preemptive
number of response time violation. The results are given systems
on figure 2. The number of jobs killed in each run is plot- In [5], Bini and co-authors give a necessary and suf-
ted with the circle line (left scale). The number of job ficient schedulability condition for fixed priority preemp-
missing their deadline is plotted with the solid line (right tive systems where tasks are independent and jobs release
scale). The dashed lines represent the mean values. The times are unknown (the notation assumes that tasks are
results show that the vast majority of the faults does not in- ordered by decreasing priority) :
duce a failure. More precisely, the mean number of dead-
line violation per simulation is 1.48, whereas the mean Theorem 1 [5] A periodic independent task set T is
number of overrun is 3887. Most of the time, there is schedulable on a FPP scheduling if and only if
enough slack time available in the system to cancel these i−1  
faults. Table 3 summarizes the results obtained for differ- X t
∀i ∈ [1, n], ∃t ∈ schedPi , Ci + Cj ≤ t
ent values of Di /Ti . As expected, the number of deadline Tj
j=1
violation decreases when the constraint is relaxed.
where schedPi is a set of scheduling points defined as
schedPi = Pi−1 (Di ), and Pi is defined as follows
(
P0 (t) = {t} j k 
Pi (t) = Pi−1 Tti Ti ∪ Pi−1 (t)

Le us take the example of a system composed of two

independent periodic tasks T = {τ1 , τ2 }. The tasks have
the following characteristics: T1 = D1 = 9.5 and T2 =
D2 = 21. For the first task τ1 , schedP1 = {D1 } and the
schedulability condition is (C1 ≤ D1 ). For the second
task τ2 , schedP2 = {2.T1 , D2 } and the schedulability
conditions are (C2 +2C1 ≤ 2T1 ) for 2T1 and (C2 +3C1 ≤
D2 ) for D2 . These equations allows to define the C-space
of the system, i.e. the domain of values of C1 and C2 for
Figure 2. Number of jobs killed (circle line, which the system is schedulable.
right scale) vs. number of deadlines missed
(solid line, left scale)

C1 ≤ D1
(C2 + 2C1 ≤ 2T1 ) ∨ (C2 + 3C1 ≤ D2 )

A graphical representation of this domain is given on

D/T max min m σ figure 3.
Overruns * 4034 3709 3887 86
1 2 0 0.04 0.28 7.2. Proportional distribution of the static slack time
Dead. miss 0.75 11 0 1.28 2.69 The knowledge of the C-space can be very useful to
0.67 13 0 1.48 2.89 increase the execution budgets of the tasks. If we con-
sider a system with an estimated WCET vector C =
Table 3. Overruns and deadlines missed for {Ci }i=1,...,n we can express the execution budget vector
the case D/T = {1, 0.75, 0.67} B = {Bi }i=1,...,n as

B = (1 + λ) . C (1)
 Di /Ti max min m σ
1 2566 752 1650 536
Overruns 0.75 3361 1544 2380 400
0.67 3378 1644 2420 86
1 2 0 0.04 0.28
Dead. miss 0.75 11 0 1.28 2.69
0.67 13 0 1.48 2.89

Table 4. Overruns and deadline missed for

the case D/T = {1, 0.75, 0.67}
Figure 3. Example of C-space

where λ ≥ 0 is a factor which increase the execution observe as expected that the better results are obtained for
budget of each task proportionally to its WCET. the higher values of Di /Ti , because these configurations
have more static slack time available. When Di /Ti = 1,
The factor λ can be computed as follow [6]: the average number of overruns drops to 1650 instead of
t − ni . C i 3887 with implicit budgets.
λ = min max (2)
i=1,...,n t∈schedPi ni . C i
l m l m l m  7.3. Multi-critical systems
where ni = t t t
and The benefits obtained from the proportional distribu-
T1 , T2 , . . . , Ti−1 , 1
Ci = {Cj }j=1,...,i . tion of static slack times into tasks budgets come to the
cost of a delay in the detection of faults that cannot be can-
Let us apply this approach to our example. The esti- celled naturally by the system (e.g. hardware faults). For
mated WCET are C1 = 4 and C2 = 6 (point S4 on fig 3). the most critical tasks whose WCET estimation is safe,
We obtain λ = 5/14. Thus B1 and B2 can be chosen re- this is a problem. To alleviate this problem, we propose to
spectively equal to 5.43 and 8.14. The budget of each task take into account the ASIL level of each task in the com-
integrates a part of the static slack time that can be used to putation of λ.
cancel overrun without jeopardizing the system. On the one hand, the WCET estimations for non
We have run again our simulations with the same pa- critical tasks are not safe, thus their execution budgets
rameters, but this time, the EXECUTIONBUDGET pa- shall be large, to allow cancellation of overruns. On
rameters are set as exposed above, so as to integrate a part the other hand, the WCET estimations for critical tasks
of the static slack time. The results are given in figure 4 are safe, thus their execution budgets shall stick to the
and table 4. estimation, to allow the fault detection and recovery
mechanism to be triggered as early as possible. To reflect
this situation, each task τi is associated with a weight wi
used to compute the execution budget (the more critical
the task, the smaller the weight). The sensitivity analysis
can be reformulated to take this new parameter into
account [6].

B = (In + λc .W) . C (3)

where In is the n × n identity matrix, W = diag(wi ) is
the n× n diagonal matrix composed by the weight of each
task and λc ≥ 0 is the factor which is computed as follow
:
t − ni · Ci
λc = min max (4)
i=1,...,N t∈schedPi ni · Ciw

Figure 4. Timing protection configuration where ∀i ∈ {1, . . . , n}, Ciw = Ci ∗ wi .

using proportional distribution of the static
slack time. To evaluate the impact of this strategy, we have run new
simulations. To reflect the ISO26262 standards, we used 4
criticality levels C.L. = {A, B, C, D} ordered in increas-
The Overruns raw of table 4 is split in 3 because the ing criticality. For the tasks with level C and D we assume
number of overruns depends on the value of λ, which in that they cannot overrun and their execution times are be-
turns depends on the deadlines and periods of the tasks. tween 0.95C and C. For the tasks with level B we assume
As can be seen, the number of overruns decreases. We that their execution time values are between 0.95C and
1.15C. For the tasks with level A we assume that their are in [0.95C, C].
execution time values are between 0.95C and 1.25C. We
affect a weight of 0 for the critical task (C.L. = {C, D}), C.L. max min m σ
a weight of 1 for the task with C.L. = B and a weight of C-D 0 0 0 0
2 for the task with C.L. = A. Figures 5 and 6 represents Overruns “i” B 2666 93 1094 818
the results obtained for 50 systems of 10 tasks with a total A 3559 127 1761 981
processor utilization processor of 0.9 and Di /Ti = 0.67. C-D 0 0 0 0
Overruns “p” B 1966 51 624 519
A 3356 101 1398 854
C-D 0 0 0 0
Overruns “c” B 1966 15 682 818
A 2630 73 956 721
D 8 0 0.28 1.23
Dead. miss C 5 0 0.16 0..82
B 11 0 0.66 2.19
A 17 0 1.62 3.76

Table 5. Overruns vs. deadlines miss for the

case of multi-critical systems, with different
configuration strategies (“i”: implicit bud-
get, “p”: proportional budget, “c”:criticality
aware budget).
Figure 5. Number of deadline violations by
ASIL. Table 5 summarizes the results for the different config-
uration strategies of the timing protection mechanism con-
Figure 5 shows the number of deadline violations for sidered in this paper. As expected, the number of overruns
each level. The legend is : C.L. = D → ×, C.L. = C → of jobs with ASIL A decreases with the last strategy, be-
2, C.L. = B → + and C.L. = A → ◦. For levels C and cause they have access to a greater part of the static slack
D, even if the jobs cannot overrun, we observe that some time. The number of overruns of jobs with ASIL B is
jobs can violate their deadline: when no timing protection greater with the last strategy than with the proportional
is used, faults propagates from levels A and B to levels C distribution strategy because their weight is smaller. Of
and D. course, the weight can be tweaked so as to find an equilib-
rium between the speed and the sensitivity of the timing
protection mechanism.

8. Conclusions

The AUTOSAR OS timing protection mechanism ful-

fill its main requirements: it avoids the propagation of
faults in the time domain between the concurrent jobs of
the system. However, we have shown through simulations
that it has very bad performances when some jobs have
their WCET underestimated. This type of fault can be
found for instance in multi-critical systems (the quality of
design of low criticality applications does not ensure that
WCET are safely estimated [17]).
We have shown that a smart configuration of the mech-
Figure 6. Number of jobs killed. Timing pro- anism allows to alleviate part of this weakness. By us-
tection configuration takes into account the ing state-of-the-art results on the sensitivity analysis of
ASIL of tasks. fixed priority preemptive real-time systems, it is possible
to safely allocate the static slack time among the tasks the
WCET of which might be underestimated. The prelimi-
Figure 6 shows the number of overruns for each level nary results presented in this paper are promising. Possi-
when the timing protection is configured with the method ble extensions of our work include the search for an op-
presented above. The same legend as 5 is used. For levels timal configuration of the mechanism (optimal weighting
C and D, there is no overrun because the execution times of the tasks), the case of dependent tasks sharing non pre-
emptable resources, the case of tasks with known release TrueTime. IEEE Control Systems Magazine, 23(3):16–30,
dates. June 2003.
However, we believe that the AUTOSAR OS specifi- [10] V. David, C. Aussaguès, J. Delcoigne, and M. Aji. Seeking
cation shall be improved so as to integrate some of the a deterministic multitask framework for safety critical sys-
tems: the OASIS project. In International Topical Meeting
features used in comparable RTOS. For instance, the re-
on Nuclear Plant Instrumentation, Controls and Human-
sponsiveness of low criticality jobs could be improved by
Machine Interface Technologies (NPIC-HMIT), Washing-
reclaiming the dynamic slack time through the use of an ton, DC, USA, November 2000.
approximate slack stealer as in DEOS (algorithms used to [11] S. Faucou, P.-E. Hladik, A.-M. Déplanche, and Y. Trin-
compute the exact slack are too complex to be used at run- quet. Overview of microkernel standards for real-time
time). Moreover, when a soft/non real-time job exhausts in-vehicle embedded systems. In Taiwanese-French Con-
its execution budget, it should be given the possibility to ference on Information Technology (TFIT), pages 28–39,
be paused and resumed when its budget is replenished (in- Taipei, Taiwan, March 2008. National Taiwan University.
stead of being killed). [12] J. Goossens and C. Macq. Limitation of the hyper-period
Another extension on the wish list is the possibility to in real-time periodic task set generation. In Real-Time and
Embedded System (RTS), pages 133–148, Paris, France,
transform the timing protection mechanism so that it pro-
March 2001. Teknea.
vides a a true insulation of applications in the time do- [13] P.-E. Hladik, A.-M. Déplanche, S. Faucou, and Y. Trin-
main, as in ARINC 653, COS or OASIS. This would be an quet. Adequacy between AUTOSAR OS specification and
interesting feature in the AUTOSAR context as it would real-time scheduling theory. In IEEE International Sympo-
allow to easily change the implementation of a compo- sium on Industrial Embedded Systems (SIES), pages 225–
nent in a system without impacting the real-time behavior 233, Lisbon, Portugal, July 2007. IEEE Industrial Elec-
of all the system. To do so, the mixed event-triggered / tronics Society.
time-triggered paradigm used today should be replaced by [14] J. Lehoczky and S. Ramos-Thuel. An optimal algorithm
a fully time-triggered paradigm. for scheduling soft-aperiodic tasks in fixed-priority pre-
emptive systems. In IEEE Real-Time Systems Symposium
(RTSS), pages 110–123, Phoenix, AZ, USA, December
References 1992. IEEE Computer Society.
[15] B. Leiner, M. Schlager, R. Obermaisser, and B. Huber.
[1] AEEC. Avionics application software standard interface: A comparions of partitioning operating systems for inte-
required services. Technical report, Aeronautical Radio, grated systems. In Conference on Computer Safety, Relia-
Inc., 2006. bility and Security (SAFECOMP), volume 4680 of LNCS,
[2] AUTOSAR. Specification of Operating System. Technical pages 342–355, Nuremberg, Germany, September 2007.
Report v3.0.1, AUTOSAR GbR, 2008. Springer Berlin / Heidelberg.
[3] F. Bimbard and L. George. FP/FIFO feasibility con- [16] M. Schlager, W. Herzner, A. Wolf, O. Gründonner,
ditions with kernel overheads for periodic tasks on an M. Rosenblattl, and E. Erkinger. Encapsulating applica-
event driven OSEK system. In IEEE International Sym- tion subsystems using the DECOS Core OS. In Confer-
posium on Object-Oriented Real-Time Distributed Com- ence on Computer Safety, Reliability and Security (SAFE-
puting (ISORC), pages 566–574, Gyeongju, Korea, april COMP), volume 4166 of LNCS, pages 386–397, Gdansk,
2006. IEEE Computer Society. Poland, September 2006. Springer Berlin / Heidelberg.
[4] E. Bini and G. C. Buttazzo. Biasing effects in schedulabil- [17] S. Vestal. Preemptive scheduling of multi-criticality sys-
ity measures. In Euromicro Conference on Real-Time Sys- tems with varying degrees of execution time assurance. In
tems (ECRTS), pages 196–203, Catania, Italia, July 2004. IEEE Real-Time Systems Symposium (RTSS), pages 239–
IEEE Computer Society. 243, Tucson, AZ, USA, December 2007. IEEE Computer
[5] E. Bini and G. C. Buttazzo. Schedulability analysis of pe- Society.
riodic fixed priority systems. IEEE Transactions on Com-
puters, 53(11):1462–1473, 2004.
[6] E. Bini, M. D. Natale, and G. C. Buttazzo. Sensitivity
analysis for fixed-priority real-time systems. In Euromicro
Conference on Real-Time Systems (ECRTS), pages 13–22.
IEEE Computer Society, July 2006.
[7] P. Binns. A robust high-performance time partitioning al-
gorithm: the digital engine operating system (DEOS) ap-
proach. In Digital Avionics Systems Conference (DASC),
pages 1B6/1 – 1B6/12, Daytona Beach, FL, USA, October
2001.
[8] A. Burns and A. J. Wellings. Real-Time Systems and Pro-
gramming Languages: Ada 95, Real-Time Java and Real-
Time POSIX - 3rd edition. Addison-Wesley – Pearson Ed-
ucation, 2001.
[9] A. Cervin, D. Henriksson, B. Lincoln, J. Eker, and K.-
E. Årzén. How does control timing affect performance?
Analysis and simulation of timing using Jitterbug and