Resource Management in Multicore Automotive ... - IRCCyN

Resource Management in Multicore Automotive Embedded Systems ∗
Sylvain Cotard
LUNAM Université, Université de Nantes and Renault S.A.S.
IRCCyN UMR CNRS 6597 (Institut de recherche en Communications et Cybernétique de Nantes)
1, rue de la Noë BP 91101
F-44321 Nantes, France
sylvain.cotard@irccyn.ec-nantes.fr
Abstract
AUTOSAR (AUTomotive Open System ARchitecture) is
an international development partnership created in 2003
between car manufacturers, suppliers and companies specialised
in electronics and information technology. It aims
at developing and establishing an open standardised architecture
for E/E (Electrical/Electronic) development.
Nowadays, car manufacturers have to cope with the increase
of heterogeneous functionalities while ensuring the
dependability of time-critical systems. In order to make
sure that all critical services will be able to start and finish
within constrained time windows, their real-time behaviours
have to be understood and some analysing techniques
have to be introduced.
In this paper, we propose to analyse the AUTOSAR
multicore OS specification from a real-time analysis point
of view.
1. Introduction
AUTOSAR (AUTomotive Open System ARchitecture)
[4] is an international development partnership created in
2003 between car manufacturers, suppliers and companies
of electronics and information technology. It aims at developing
and establishing an open standardised architecture
for E/E (Electrical/Electronic) systems.
During the past 15 years, the increasing number of services
provided in vehicles caused the evolution of E/E
systems from federated architectures (one function per
Electronic Control Unit (ECU)) to integrated architectures
(several functions per ECU). The new organisation proposed
by AUTOSAR illustrate this trend. In order to
pursue this evolution, multicore ECU architectures (composed
by two or more cores on the spare die) appear to
be the best trade-off between price, performance and ability
to develop time-critical systems. However, we have to
cope with new challenges concerning the development of
∗ This work has been supported by Renault S.A.S., 1 Avenue du Golf,
78280 Guyancourt - France
such systems. For example, car manufacturers need to be
able to perform real-time analysis in order to make sure
that critical subsystems (e.g. X-by wire) will always execute
correctly within their timing requirements.
Our work aims at understanding and mastering the AU-
TOSAR multicore OS specification. More precisely, this
paper focuses on the predictability of such system with a
focus on the real-time behaviour.
Other works are already available. In [1], it is shown
how AUTOSAR can be analysed with scheduling theory
techniques using the MAST tools. The work deals with
distributed applications but does not take multicore concept
into consideration. In [7], it is shown that the global
scheduling problem in AUTOSAR multicore OS can be
divided into two independent sub-problems: partitioning
a set of runnables, and then building the schedule on each
core. The authors propose a set of algorithms in order to
directly find a schedulable scheme whereas we are interested
here in the analysis of a given configuration. Finally,
[6] presents the adequacy of AUTOSAR OS specification
with real-time scheduling theory in uniprocessor systems.
The outline of the paper is as follows. Section 2 gives
an overview of the AUTOSAR multicore OS specification.
Section 3 describes a schedulability analysis for AU-
TOSAR multicore OS applications. Finally, section 4 concludes
the paper.
2. The AUTOSAR multicore OS specification
The AUTOSAR OS specification [2] is based on the
OSEK/VDX operating system v2.2.2 [8]. The AUTOSAR
multicore OS specification (release 4.0) [3], used in order
to perform the work presented in this section, is derived
from the existing AUTOSAR OS specification.
In the AUTOSAR software architecture, the OS (either
uniprocessor or multicore) is mainly responsible for
scheduling tasks and ISRs (Interrupt Service Routines)
hosted by an ECU.
According to AUTOSAR multicore OS, all cores shall
use the same instruction set and provide access to a shared
memory. The number of cores that can be controlled by

the AUTOSAR OS shall be configured offline and it is
forbidden to either restart cores or insert additional ones.
2.1 Task scheduling approach
AUTOSAR OS defines an OS-Application as a collection
of OS entities forming a cohesive functional unit.
Mainly, this includes tasks, ISRs, alarms, hooks and
schedule tables. All OS objects within the same OS-
Application can access each other using dedicated APIs
(e.g. it is mandatory to use synchronisation mechanism
to handle inter-core communication). In order to comply
with the specification, an OS Application is statically assigned
to a core what leads to a partitioned system.
The scheduling strategy defined in AUTOSAR OS applies
independently for each individual core. A fixed priority
is assigned to each task off-line. When the scheduler
is invoked, it checks among all the ready tasks and selects
to one with the highest priority for execution. If more than
one task share the same priority, FIFO is used as a second
criterion to break ties. It is also possible to choose if the
preemption of a task is allowed or not. This leads to a
mixed preemptive policy.
2.2 Synchronization strategy
In uniprocessor AUTOSAR systems, shared resources
management is handled by the IPCP protocol (Immediate
Priority Ceiling Protocol) [6] what limits the blocking
time due to execution of lower priority tasks. When a task
gets a shared resource, its priority is immediately raised
to the resource ceiling priority. The ceiling priority of the
resource must be greater than the base priority of all tasks
that can access this resource so that the scheduling policy
enforces mutual exclusion.
For multicore systems, AUTOSAR allows the sharing
of resources among cores but IPCP is not efficient in this
context. To illustrate the inefficiency of IPCP, let us consider
the case of a resource shared by two tasks on different
cores. The first one enters its critical section and its
priority is raised to the resource ceiling priority. However,
this will not prevent the other task from entering its critical
section because schedulers on both cores are independent.
In multicore AUTOSAR systems, synchronization is
done using the spinlock mechanism. Spinlock refers to
a busy waiting technique that polls a shared lock variable
until it becomes available. Usually, this technique relies
on HW facilities such as test-and-set or compare-&-swap
instructions but it can also be implemented in software using
for instance the Dekker algorithm [5] or the Peterson
algorithm [9].
As synchronization based on spinlock has not been designed
for time critical systems, we can observe deadlock
and starvation situations as discussed in section 3.1. To
face these problems, other protocols such as MPCP or
MSRP (Multicore extension of Priority Ceiling Protocol
and Stack Resource Policy) can be used as proposed in
[11].
3. Schedulability Analysis of AUTOSAR multicore
OS applications
3.1 Recommendation for using spinlocks
Let us consider the case where five tasks are distributed
on two cores as illustrated in Figure 1(a). τ 1 1 , τ 1 2 , τ 2 1 , τ 2 2 ,
share the resource R, whereas τ 1 3 never takes R. A task
has a priority π i (π i > π j denotes τ i has a higher priority
than τ j ).
Scenario leading to a deadlock (Figure 1(b)): On core
one, τ 1 1 enters its critical section. Then, it is preempted
by τ 1 2 that has a higher priority. During its execution, τ 1 2
tries to enter its critical section. This leads to a deadlock
situation on core 1.
Scenario leading to a starvation (Figure 1(c)): On core
2, τ 2 2 is executing and enters its critical section. Then, τ 1 1
starts its execution on core 1 and tries to enter its critical
section. As the resource is locked, τ 1 1 enters a busy
waiting state. Then, τ 1 1 is preempted by τ 1 3 . During that
time, τ 2 2 releases the resource. τ 2 1 is scheduled and enters
its critical section. So, when τ 1 1 is scheduled again,
it stays in the busy waiting state. Starvation occurs when
this scheme repeats indefinitely.
As presented in [3], another problematic situation corresponds
to the use of nested spinlocks. In this document,
it is even recommended never to use nested spinlocks.
A partial solution could be to disable all interruptions
before getting the spinlock. This solution prevents deadlock
but cannot prevent all starvation situations mainly in
multicore architectures composed of more than two cores.
First, let us consider the case of two cores. If a task is
busy-waiting to enter a critical section, it will automatically
win the lock as soon as it is released. Indeed, any
other task of the same core cannot take the lock (interrupts
are disabled, and no other task can be scheduled) and no
task of the other core will try to get the lock immediately
after it has been released (a context switch, which is not
instantaneous, is required before a task on the other core
can try to get the lock) Let us consider now two tasks on
two cores trying to lock a resource taken by a third task on
another core. In that case, we cannot predict exactly which
of the two waiting tasks will enter its critical section when
the resource will be freed. Thus, the execution scheme
cannot guarantee that starvation will not occur. This leads
to a non-deterministic behavior.
3.2 Classical response time analysis (RTA)
The purpose of schedulability analysis is to make sure
that no time constraint will be violated during all the entire
life of the system. In other words, it must be guaranteed
that each task will always complete itself within
its deadline. In order to do that, an off-line analysis has
to be performed during the application design stage. The
RTA technique can be used for that purpose. This technique
consists in computing the worst case response time
of each task and comparing this value with its deadline.
More formally, a system is composed of a set of tasks
2

Core 1
τ 1 3
τ 1 1
τ 1 2
τ 1 3
τ 1 1
Core 1
R
τ 1 2
τ 2 2
τ1
2 τ2
2
Core 2
(a) Tasks distribution
τ 1 1
Core 1
R is taken Busy waiting
(b) Deadlock Illustration
τ 2 1
Core 2
R is taken Busy waiting
(c) Starvation Illustration
Figure 1. Example of problematic situation observed using spinlock mechanism
S = {τ i } 1≤i≤s . For the sake of simplicity, we will consider
the following assumptions:
• All tasks are periodic, preemptive and activated for
the first time at system startup.
• Tasks on a same core can share resources whose accesses
are controlled via the IPCP protocol. Tasks
of different cores can share a same resource using
the spinlock mechanism. For this, as explained in
section 3.1, we will consider only two cores to have
a deterministic behavior. Moreover, we will assume
that interrupt are disabled (resp: enable) before (resp:
after) that the lock is taken (resp: freed). This is illustrated
by the programming scheme of Figure 2.
DisableAllInterrupt
GetSpinLock
ReleaseSpinLock
EnableAllInterrupt
Figure 2. Management of mixed resources
• Each task is assigned a fixed priority which is unique
relative to the core upon which it is executed. As
we use IPCP synchronization protocol for local resource,
the priority level of a task may vary during
its execution.
Every task will generate an infinite number of jobs
τ i (q). We define the response time of a job q as the amount
of time elapsed between the instant where the job is released
for execution and the instant of its completion. In
multicore environments where tasks share resources, we
need to consider all situations that involve a blocking time
in order to compute r i (q). The response time of the q th
job is:
r i (q) = C i + b l i(q) + b r i (q) + p i (q, r(q)) (1)
where :
• C i is the worst-case execution time (WCET) of τ i .
• b l i (q) is the local blocking time caused by tasks that
are located on the same core. This blocking time
represents the time during which a task can interfere
by executing a critical section of ceiling priority
greater than π i or a critical section protected by a
disable/enable interrupt.
• b r i (q) is the remote blocking time caused by tasks of
the other core when trying to get a global resource.
• p i (q, r(q)) is the interference due to preemption, i.e.
the amount of time a task can be delayed because
of the execution of higher priority tasks on the same
core.
The worst case response time R i of τ i is defined by the
maximum value of r i (q) among an infinite number of job
q. Consequently, the value of R i is:
R i = max {r i (q)} (2)
To detail the computation of R i , we will consider the
following task model (illustrated on Figure 3):
τ i = (T i , D i ≤ T i , π i , {C nc
i,j}, {[C c i,j, S i,j , Π i,j ]}) (3)
τ i
Resource S i,1 Resource S i,2
Π i,1 Π i,2
π i
Ci,1 nc Ci,1
c C nc Ci,2
c
i,2 Ci,3
nc
Figure 3. Task model considered for RTA
A job of a task τ i is defined as a set of critical and
non-critical sections. Each critical section corresponds to
a resource S i,j that can be shared either with tasks on the
same core only, or on either core. For local resources,
the ceiling priority is denoted Π i,j and corresponds to the
priority given by IPCP. For global resources, the ceiling
priority Π i,j corresponds to an "infinite" value (to capture
the effect of interrupt masking). The task τ i is periodic
of period T i and has a priority π i defined off-line (π i >
π j denotes τ i has a higher priority than τ j ). We denote
the execution time of critical and non-critical sections Ci,j
c
respectively. Finally c(i) and nc(i) respectively
denote the number of critical and non-critical sections in
τ i .
and C nc
i,j
T i
3

We can use the definition given in [10] for the definition
of the critical instant of τ i : when τ i and tasks of
higher priority on the same core are activated at the same
time and the task that contributes to the maximum local
blocking time has just started its execution. The remote
blocking is taking into account in the local blocking time
(section 3.2.1).
3.2.1 Local blocking
τ 1 2
τ 1 1
critical section
remote spinning
Core 1
Figure 4. Local blocking situation
As shown in Figure 4, a task can be delayed by a critical
section of a task of lower priority on the same core if the
resource ceiling priority is higher than π i (filled section).
This critical section can also be delayed by another one,
protected by a disable/enable interrupt (shaded section).
This can occur only once, between the task release and the
instant it starts. This reduces to the following equation:
max
l:1≤l≤c(k)
Π k,l ≥π i
⎛
⎜
⎝Ck,l c +
∀q > 0, b l i(q) ≤
max
3.2.2 Remote spinning blocking
max
max
k:π k 0, b r i (q) ≤
3.2.3 Interference
∑
max
k:core k ≠core i 1≤l≤c(k)
1≤j≤c(i)
(4)
max Ck,l c (5)
S k,l =S i,l
The interference term due to preemptions by higher priority
tasks on the same core is given by:
∑
⌈ ⌉
ri (q)
∀q > 0, p i (q) ≤
∗ C k ′ (6)
T k
k:π k >π i
core k =core i
with :
C ′ k = C k +
∑
max max
m:core m≠core k 1≤n≤c(m)
1≤l≤c(k)
S m,n=S k,l
C c m,n (7)
In (7), we have to take into consideration the WCET of
higher priority task including the impact of busy waiting
period.
4. Conclusion
The goal of this paper was to give some results concerning
the real-time analysis for systems using AU-
TOSAR multicore OS specification.
The analysis does not assume strong hypothesis on the
application. Therefore, it is very pessimistic. Indeed, for
global resources, we always considered the worst case by
taking the maximal value of the remote blocking time (in
equations 4,5,6). In a real scenario, we cannot determine
if this pessimistic case will be encountered. To overcome
this limitation, our future work will be to find how the
AUTOSAR specifications could be used in a predictable
way.
In order to limit the non-determinism induced by spinlock,
we had to define some restrictions on the HW by
considering only two cores. For now, only dual-core architectures
are available but in the future, we will use dies
with more cores. In those cases, we will have to study
other protocols such as MSRP or MPCP [11].
References
[1] S. Anssi, S. Tucci-Piergiovanni, S. Kuntz, S. Gérard,
and F. Terrier. Enabling scheduling analysis for autosar
systems. In 14th IEEE International Symposium
on Object/Component/Service-Oriented Real Time Distributed
Computing, pages 152–159, 2011.
[2] AUTOSAR. AUTOSAR - Specification of operating system.
Technical Report v4.0, AUTOSAR GbR, 2011.
[3] AUTOSAR. AUTOSAR - Specification of operating system
for multicore. Technical Report v4.0, AUTOSAR
GbR, 2011.
[4] AUTOSAR. http://www.autosar.org. Technical report,
AUTOSAR GbR, June 2011.
[5] E. W. Dijkstra. Solution of a problem in concurrent programming
control. Commun. ACM, 8(9):569, 1965.
[6] P.-E. Hladik, A.-M. Deplanche, S. Faucou, and Y. Trinquet.
Adequacy between autosar os specification and realtime
scheduling theory. In International Symposium on
Industrial Embedded Systems, 2003.
[7] N. Navet, A. Monot, B. Bavoux, and F. Simonot-Lion.
Multi-source and multicore automotive ecus - os protection
mechanisms and scheduling. In International Symposium
on Industrial Electronics - ISIE, 2010.
[8] OSEK/VDX. OSEK/VDX - Operating system. Technical
Report v2.2.3, OSEK Group, 2005.
[9] G. L. Peterson. Myths about the mutual exclusion problem.
Inf. Process. Lett., 12(3):115–116, 1981.
[10] Y. Wang and M. Saksena. Scheduling fixed-priority tasks
with preemption threshold. In Proceedings of the Sixth International
Conference on Real-Time Computing Systems
and Applications, 1999.
[11] H. Zeng and M. Di Natale. Mechanisms for guaranteeing
data consistency and flow preservation in autosar software
on multi-core platforms. In 6th IEEE International Symposium
on Industrial Embedded Systems, 2011.
4