Multi-source software on multicore automotiveECUs - Combining runnable sequencing with task

schedulingAurélien Monot, Nicolas Navet, Bernard Bavoux and Françoise Simonot-Lion

Abstract—As the demand for computing power isquickly increasing in the automotive domain, car manu-facturers and tier-one suppliers are gradually introducingmulticore ECUs in their electronic architectures. Addi-tionally, these multicore ECUs offer new features suchas higher levels of parallelism which ease the compliancewith safety requirements such as the ISO 26262 andthe implementation of other automotive use-cases. Thesenew features involve greater complexity in the design,development and verification of the software applications.Hence, car manufacturers and suppliers will require newtools and methodologies for deployment and validation. Inthis paper, we address the problem of sequencing numer-ous elementary software modules, called runnables, on alimited set of identical cores. We show how this problemcan be addressed as two sub-problems, partitioning the setof runnables and building the sequencing of the runnableson each core, which problems cannot be solved optimallydue to their algorithmic complexity. We then present lowcomplexity heuristics to partition and build sequencertasks that execute the runnable set on each core. Finally,we address the scheduling problem globally, at the ECUlevel, by discussing how to extend this approach in the casewhere other OS tasks are scheduled on the same cores asthe sequencer tasks.

I. INTRODUCTION

Multi-source software running on the same ECU(Electronic Control Unit) is becoming increasinglywidespread in the automotive industry. One of the mainreasons being that car manufacturers want to reduce the

A. Monot is with LORIA/INPL and PSA Peugeot-Citroën, 615rue du Jardin Botanique, 54600 Vandoeuvre, France, e-mail: aure-lien.monot@inria.fr.

N. Navet is with INRIA and RealTime-at-Work (RTaW), 615rue du Jardin Botanique, 54600 Vandoeuvre, France, e-mail: nico-las.navet@inria.fr.

B. Bavoux is with PSA Peugeot-Citroën, route de Gisy, 78 943Vélizy-Villacoublay, France, e-mail: bernard.bavoux@mpsa.com.

F. Simonot-Lion is with LORIA/INPL, 615 rue du JardinBotanique, 54600 Vandoeuvre, France, e-mail: simonot@loria.fr.

Copyright (c) 2012 IEEE. Personal use of this material is permitted.However, permission to use this material for any other purposesmust be obtained from the IEEE by sending a request to pubs-permissions@ieee.org.

number of ECUs which grew up above 70 for high-endcars. One major outcome of the AUTOSAR initiative,and more specifically of its operating system, is to helpcar manufacturers shift from the “one function per ECU”paradigm to more centralized architecture designs byproviding appropriate protection mechanisms.

Another crucial evolution in the automotive industryis that chip manufacturers are reaching the point wherethey can no longer cost-effectively meet the increas-ing performance requirements through frequency scalingalone. This is one reason why multicore ECUs are beinggradually introduced in the automotive domain. Thehigher level of performance provided by multicore ar-chitectures may help to simplify in-vehicle architecturesby executing on multiple cores the software previouslyrun on multiple ECUs. This possible evolution towardsmore centralized architectures is also an opportunity forcar manufacturers to decrease the number of networkconnections and buses. As a result, parts of the com-plexity will be transferred from the electrical/electronicarchitecture to the hardware and software architecture ofthe ECUs. However, static cyclic scheduling makes iteasy to add functions to an existing ECU. In practice,important architectural shifts are hindered by the carry-over of ECUs and existing sub-networks which is widelyused by generalist car manufacturers. The extent towhich more centralized architectures will be adoptedremains thus unsure.

Multicore ECUs are also helpful for other usecases. For instance, they bring major improvementsfor some applications requiring high performance suchas high-end engine controllers, electric and hybridpowertrains[1], [2], advanced driver assistance sys-tems [3] sometimes involving real-time image process-ing [4]. Those multicore platforms offer also additionalbenefits, such as higher level of parallelism allowingfor more segregation, which may help to meet therequirements of the upcoming ISO 26262 that concernsfunctional safety for road vehicles. Furthermore, in mul-ticore architectures, some core can be dedicated to aspecialized usage such as handling low-level services.

Now, the challenge is to adapt existing design methodsto the new multicore constraints. The scheduling of thesoftware components is one of the key issues in thatregard and it has to be revamped.

Introduction of multi-source and multicore will inducedrastic changes in the software architecture of automo-tive ECUs. The section II of this paper introduces themost likely scheduling choices as well as the literaturerelevant to the task scheduling in multiprocessor automo-tive ECUs. Then, section III presents solutions for thescheduling of numerous software modules when only afew OS tasks are allowed. This paper builds on the studypublished in [5] where it was assumed that only onesequencer task was running on each core of the ECU toschedule the runnables. Here, we consider in section Vhow to build several sequencer tasks while possiblyscheduling other tasks on the same core and discuss howto analyze the schedulability of such systems globally.

From now on, for the sake of clarity, we refer to“sequencing” when talking about the scheduling ofrunnables while “scheduling” is solely used for tasks.

II. SCHEDULING IN THE AUTOMOTIVE DOMAIN

A. Scheduling design choices for multicore ECUs

In this section, we explain and justify, especially inthe light of predictability requirements, the multicorescheduling approach that is, to the best of our knowledge,the most widely considered in the automotive industry.

1) Partitioning scheduling scheme: In a multicoresystem, the tasks are either statically allocated to thecores or they can be distributed dynamically at run-time to balance the workload or migrate functions toincrease availability. The later approach involves com-plex task and resource interactions which are difficult topredict and validate. For this reason, approaches relyingon static allocation (i.e., partitioning) and deterministicmechanisms such as periodic cyclic scheduling are morelikely to be used in the automotive context and thisis the option taken within the AUTOSAR consortium.Scheduling tasks on a multi-processor systems under thestatic partitioning approach has been well studied for along time, see for instance [6] and [7], [8], [9]. However,the works we are aware of deal with online algorithmssuch as FPP or EDF, and do not consider the static cyclicscheduling of tasks.

2) Static cyclic scheduling: Static cyclic schedulingof elementary software modules, or runnables, is com-mon because there are usually many more runnables thanthe maximum number of tasks allowed by automotiveoperating systems such as OSEK/VDX or AUTOSAROS. For this reason, runnables must be grouped together

and scheduled within a sequencer task (also calleddispatcher task). In this paper, we focus on how tosequence large runnable sets on multicore platformsusing a static partitioning approach. Indeed, the statictask partitioning scheme is very likely to be adopted atleast in a first step because it is conceptually simple andprovides a better predictability for the ECU designers bycomparison with a global scheduling approach. We aimto develop practical algorithms, whose performances canbe guaranteed, to build the dispatcher tasks on each coreand to schedule the runnables within these dispatchertasks so as to respect sampling constraints and, as far aspossible, uniformize the CPU load over time. This latterobjective is of course important to minimize the hard-ware cost and to facilitate the addition of new functions,as typically done in the incremental design process ofcar manufacturers. This is achieved by desynchronizingthe runnable release dates. Precisely, the first releasedate of each runnable, termed its offset, is determinedso as to spread the CPU demand uniformly over time.The configuration algorithms developed in this paper areclosely related to [10] (mono-processor scheduling oftasks with offsets) and [11] (scheduling of frames withoffsets) but it is applied to multi-core and goes beyondas we provide lower-bounds on the performances. Asthe problem is of practical interest in the industry, thereare in-house tools at the car manufacturers as well ascommercial tools, such as RealTime-at-Work’s RTaW-ECU [12], that have been developed for configuring thescheduling. However, the proprietary algorithms used inthese tools can usually not be disclosed and they aresometimes specialized for some specific usage.

B. Model description

In this study, we consider a large set of n periodicelementary software modules, also called runnables, thatare to be allocated on an ECU consisting in m identicalcores. In practice, a runnable can be implemented as afunction called, whenever appropriate, within the bodyof an OS task.

1) Runnable characteristics: The ith runnable is de-noted by Ri = (Ci, Ti, Oi, {R}, Pi). Quantities Ci,Ti and Oi correspond respectively to the Worst-CaseExecution Time (WCET), the period (i.e., the exact timebetween two successive releases) and the offset of theRi. As shown in Figure 1, the offset of a runnable isthe release date of the first instance of that runnable,subsequent instances are then released periodically. Thechoice made for the offset values has a direct influenceon the repartition of the workload over time.

A set of inter-runnable dependencies is denoted by{R}. Indeed, due to specific design requirements, such

Oi0 Oi+Ti Oi+2.Ti

Oi Ti Ci

Figure 1. Model of the runnables. After its release, an instance of arunnable has to be executed before the next instance is released (i.e.,the deadline is set to the period).

as shared variables, some runnables may have to beallocated on the same core and the set {R} is usedto capture those constraints. In addition, some specificfeatures, as I/O ports being located on a given core, mayrequire a runnable to be allocated onto a specific core.This locality constraint is expressed by Pi.

2) Dispatcher task: Runnables are scheduled on theirdesignated core using a dispatcher task, or “sequencertask”, that stores the runnable activation times in a tableand releases them at the right points in time. A dispatchertask is characterized by the duration of the dispatch tableTcycle that is executed in a cyclic manner, and by aquantum Ttic which is the duration of a slot in the table.Typically, one may have for instance Tcycle = 1000msand Ttic = 5ms. It should be noted that Tcycle must bea multiple of the greatest common divisor (gcd) of therunnable periods and the least common multiple (lcm) ofthese periods must be a multiple of Ttic. As a result, adispatch table holds Tcycle/Ttic slots.

3) Assumptions: In this paper, we place a set ofworking assumptions, which, in our experience, can mostoften be met in today’s automotive applications:• Each runnable is executed strictly periodically. As a

result, the whole trajectory of the system is definedby the first activation times of the runnables (i.e.,their offsets).

• The runnables are assumed to be offset-free, in thesense that the initial offset of a runnable can befreely chosen in the limit of its period (see [10]).Those offsets will be assigned during the construc-tion of the dispatch table with the objective touniformize the CPU load over a scheduling cycle.

• The worst case execution times of the runnablesare assumed to be small compared to Ttic. Typicalvalues for the case we consider would be 5ms forTtic and Ci ≤ 300µs.

• All cores are identical regarding their processingspeed.

• There are no dependencies between runnables al-located on different cores. Therefore, all cores canbe scheduled independently. This assumption is inline with the choices made by AUTOSAR regardingmulticore architecture [13].

This last assumption allows to divide the overall probleminto two independent sub-problems. A first part of theproblem consists in allocating all of the n runnables ontothe m cores with respect to their constraints with the aimof balancing the CPU load of the m resulting partitions(see §III-A). The second part of the problem consists inbuilding the dispatch table for each core (see §III-B).

4) Schedulability condition: Assuming that we onlyconsider runnable scheduling, the system is schedulable,and thus can be safely deployed, if and only if on eachcore:

1) The runnables are executed strictly periodically.2) The initial offset of each runnable is smaller than

its period.3) The sum of the WCET of the runnables allocated

in each slot does not exceed a given threshold,which is typically chosen as the duration of theslot, i.e. Ttic.

III. RUNNABLE SEQUENCING ALGORITHMS FOR

MULTICORE ECUS

In this section we present algorithms, and when pos-sible derive lower bounds on their efficiency, to schedulelarge numbers of runnables on multicore ECUs.

Since automotive OSs can only handle a limitedamount of OS-tasks, the sequencing of runnables hasto be done within dispatcher tasks. A first step ofthe approach is to partition the runnable sets onto thedifferent cores. The next and last step is to determinethe offsets between the runnables allocated on each coreso as to balance the load over time.

A. Building tasks as a bin-packing problem

It is assumed that the number of cores is fixed.We first distribute all the runnables on the cores. As-signing n tasks to m cores is like subdividing a setof n elements into m non-empty subsets. By defi-nition, the number of possibilities for this problemis given by the Stirling number of the second kind(see [14]): 1

m!

∑mi=0(−1)(m−i) (mi ) in. Considering that

the runnables may have core allocation constraints, thecores should be distinguished. Thus, the m! combina-tions of cores must be considered. As a result, onehas at most

∑mi=0(−1)(m−i) (mi ) in different possibilities

for the partitioning problem alone. Such a complexityprevents us from an exhaustive search. For instance, withn = 30 and m = 2, the search space holds more thanone billion possibilities.

Considering this complexity, to balance as evenly aspossible the utilization of processor cores, we propose aheuristic based on the bin-packing decreasing worst-fit

scheme for a fixed number of bins (where “bins” here areprocessor cores). The heuristic is given in Algorithm 1.

Algorithm 1 Partitioning of the runnable set.input: runnable set {Ri}, number of cores m(1) Group inter-dependent runnables into runnable clus-ters. Independent runnables become clusters of size 1.(2) Allocate the runnable clusters which have a localityconstraint to the corresponding cores.(3) Sort the runnables clusters by decreasing order ofCPU utilization rate ρ =

∑iCi

Ti.

(4) Iterate over the sorted clusters(a) Find the least loaded core,(b) Assign the current cluster to this core.

Step (1) runs in O(n). Step (2) runs in O(n) but all therunnables allocated in (2) will not have to go through thesteps (3) and (4) that are algorithmically more complex.Step (3) runs in O(n · log n). Finally step (4) runs inO(n ·m). As a conclusion, algorithm 1 runs in O(n(m+log n)) which does not raise any issue in practical cases.

It is worth pointing out that m ≥⌈∑m

i=1Ci

Ti

⌉is a

necessary schedulability condition which can be used torule out configurations with too few processor cores.

B. Strategies for sequencing runnables

The next stage consists in building the dispatch tablefor the set of runnables. In a first step, it is assumedthat there are no precedence constraints between therunnables and that a single sequencer table is neededper core. This latter assumption can be easily relaxed asdone in section V.

1) Least-loaded algorithm: Considering a runnableRi of period Ti, there are Ti

Tticpossibilities for allocating

this runnable (see schedulability condition #2 in §II-B4).As a result there are

∏ni=1

Ti

Tticalternative schedules for

the n runnables and, given the cost function, we arenot aware of any ways to find the optimal solutionwith an algorithm that does not have an exponentialcomplexity. Considering a realistic case of 50 runnableshaving their period as least twice as large as Ttic, itwould be needed to evaluate a minimum of 250 possiblesolutions. Once again, given the complexity, we haveto resort to a heuristic. Here, we adapt to the problemof sequencing runnables the “Least-loaded” algorithmproposed by Grenier et al. in [11] for the frame offsetallocation on a CAN network.

The intuition behind the heuristic is simple: at eachstep, we assign the next runnable to the least loaded slot,as described in Algorithm 2. The load of a slot is thesum of the Ci of the runnables {Ri} already assigned to

this slot. This algorithm is further referred to as “Leastloaded” or LL for short.

Algorithm 2 Assigning runnables to slots: the “Least-loaded” heuristic.input: runnable set {Ri}, Ttic, Tcycle(1) Sort runnables Ri such that Ttic ≤ T1 ≤ . . . ≤ Tn ≤Tcycle.(2) For i = 1 . . . n

(a) Look for the least loaded slot in the Ti

Tticfirst slots,

(b) Allocate Ri in every Ti

Tticslot starting from this

slot.

Step (1) runs in O(n · log n). Step (2) iterates n timesover steps (2a) and (2b) which run respectively in Ti

Ttic≤

Tcycle

Tticand Tcycle

Ti≤ Tcycle

Ttic. As a result, this algorithm

runs in O(n(log n+ maxi{Ti}Ttic

+ Tcycle

mini{Ti}) ≤ O(n(log n+2Tcycle

Ttic).

For practical applications, ties at step (1) are brokenusing highest WCET first and ties at step (2a) bychoosing the central slot of the longest sequence ofconsecutive slots having the minimum load. Althoughthe latter rule for breaking ties does not have any impacton the theoretical results that will be derived next, ithelps to separate load peaks, which is important fromthe ECU designer point of view. As an illustration,applying the least-loaded heuristic to the set of runnablesRi(Ti, Ci): R1(10, 2), R2(10, 1), R3(20, 4), R4(20, 2)leads to the dispatch table shown in Figure 2. Theresulting distribution of the load is shown in Table I.

R1 R1 R1 R1R

2

R

2

R

2

R

2R3 R3R4 R4

0 5 10 15 20 25 30 35 40

Figure 2. Example of dispatch table.

Slot 1 2 3 4 5 6 7 8Load 2 4 2 3 2 4 2 3

Table ILOAD REPARTITION CORRESPONDING TO THE DISPATCH TABLE IN

FIGURE 2.

We consider two main metrics to evaluate the qualityof a dispatch table. The first important criterion is tohave the lowest maximum load in the cycle since thiswill determine the feasibility of the schedule and thepossibility to add further functions later in the lifetimeof the system. The maximum load over all slots is alsoreferred to as the peak load. In a second step, a morefine-grained assessment of the uniformity of the load

balancing can be given by the standard deviation of theload distribution over all the slots.

2) Upper bound on the peak load: Here we derivean upper bound on the peak load which holds forrunnable sets with harmonic periods (i.e., each period ismultiple of all smaller periods). From it, we consequentlyderive a closed-form sufficient schedulability condition.In this perspective, we first point out that the slots inwhich a runnable Ri will be periodically assigned areof equal load -which is the rationale behind step (2a) ofalgorithm 2.

Lemma 1. Before the allocation of a runnable Ri,the slot allocation induced by the previously allocatedrunnables repeats with a period Ti

Ttic.

Proof: This is proved by induction. The propertyholds for R0 as all slots are empty. Assuming that theproperty holds for Ri, this runnable will be periodicallyallocated in every Ti

Tticslots. Therefore, the slot allocation

will still repeat with a period Ti

Tticafter its allocation

in the least loaded slot. Since runnables are sorted byincreasing periods and that their periods are harmonic,Ti+1 = k · Ti with k ∈ N∗ and the slot allocation alsorepeats with a period k · Ti

Ttic= Ti+1

Tticbefore the allocation

of Ri+1.Therefore, the least loaded slot in the first Ti

Tticslots

is the least loaded over the whole dispatch table andone does not need to look farther. As a second step, weshow that the highest load in the slot where a runnableis going to be allocated arises when the load is equal inevery slot.

Lemma 2. The maximum load in the least loaded slot isobtained for a perfect load balancing, which correspondsto a constant load throughout the cycle.

Proof: Reasoning with a constant allocated load,anything else than a perfect load balancing will resultin a load below the average load per slot in some slotwhich will be eventually chosen to allocate the runnableunder consideration.

As a result, the highest peak a runnable can createhappens in the case of a perfect load balancing. Now,let us define ρk =

∑i∈{R}k

Ci

Tithe total utilization of

core k where {R}k is the set of runnables allocated tocore k and card{R}k the cardinality of {R}k.

Theorem 3. On processor k, an upper bound on thepeak load of a slot allocation is

PLk = maxi∈{R}k

{Ci + ρkTtic −card{R}k∑

j=i

CjTjTtic} (1)

Proof: In the case of a perfect load balancing, beforethe allocation of Ri, the load of a slot is given by:∑

allocated runnableswcet ·number of allocation slotstotal number of slots , i.e.

i−1∑j∈{R}k

Cj ·TcycleTj· TticTcycle

(2)

After the allocation of Ri, the load in thecorresponding slot is

Ci +

i−1∑j∈{R}k

Cj ·TticTj

(3)

Moreover:∑i−1

j∈{R}kCj

Tj= ρk −

∑card{R}kj=i

Cj

Tj

Consequently, the worst-case peak load on processorcore k resulting of the allocation of Ri in a slot is

PLik = Ci + ρkTtic −card{R}k∑

j=i

CjTjTtic (4)

Taking the max for all the runnables gives equation 1.

If the worst case peak load is below Ttic for allrunnables, then the solution given by the algorithm isschedulable. Hence the following corollary:

Corollary 1. From theorem 1, we derive the followingsufficient schedulability condition:

ρk ≤ 1 +CminTmax

− CmaxTtic

(5)

with Cmax = maxi∈{R}k{Ci}, Tmax = maxi∈{R}k{Ti}and Tmin = mini∈{R}k{Ti}

Proof: ∀i, Ci ≤ Cmax and ∀i,∑card{R}k

j=iCj

Tj≥

Cmin

Tmaxgives :

∀i, PLik ≤ Cmax + ρkTtic −CminTmax

Ttic (6)

The scheduling condition 3 in §II-B4 (i.e., PLik ≤Ttic) leads to the result.

This bound is achievable for n · k identical runnableswith period equal to k · Ttic and load equal to C and alast runnable Rn·k+1 of period Tmax and load C. Withthis setup, Cmin = Cmax = C and the allocation ofn · k first runnable results in a perfect load balancingof constant load ρk · Ttic − C · Ttic/Tmax. As a result,allocating the last runnables induces the load ρk · Ttic −Cmin · Ttic/Tmax + Cmax in some slots.

3) Lower bound on the allocatable load: We intro-duce here a lower bound on the capacity of the corealgorithm 2 guarantees to be able to use given a har-monic runnable set. This is referred to as the harmonicschedulability bound.

Theorem 4. The harmonic schedulability bound is equalto (1− Cmax

Ttic) of the capacity of each core.

Proof: Reasoning as done for Corollary 1, theworst case peak load is given by allocating a runnableR = (Cmax, Tmax = Ttic) in a slot allocation with aperfect balance load. In the worst case, the system isstill schedulable when this average slot load is equal toTtic − Cmax. In other words, when the system becomesno longer schedulable, every slot has an allocated loadgreater or equal to Ttic − Cmax. As a consequence, atleast (1 − Cmax

Ttic) of the capacity of the considered core

can been used by our algorithm.For example, with Ttic = 5ms and Cmax = 300µs,

at least 94% of the CPU is guaranteed to be usable. Inpractice, when Cmax is small, this bound is very useful.Considering the problem of scheduling a given harmonicrunnable set on a multicore ECU with an infinite numberof cores using as few cores as possible, the followingcorollary gives a bound of the maximum number re-quired by this algorithm.

Corollary 2. Defining P =∑

iCi

Tithe total load to

allocate for a runnable set with harmonic periods andmmin the number of core required by the “Least-loaded”algorithm to schedule it, theorem 2 gives

mmin ≤⌈

P

1− Cmax/Ttic

⌉(7)

4) Dealing with non harmonic runnable sets: Usually,in practice, runnable sets do not have strictly harmonicperiods. As a consequence, lemma 1 and lemma 2 do nothold anymore and equations 1 and 5 cannot be appliedto provide bounds. In particular, placing a runnable inthe least loaded slot of the dispatch table could inducepeaks because of the runnable periodicity. Take the fol-lowing runnable set for instance: R1(10, 2), R2(20, 3),R3(20, 1), R4(50, 2) with Ttic = 5 and Tcycle = 100.Figure 3 shows the dispatch table before the allocationof R4. The resulting distribution of the load is shown inTable II.

0 10 20 30 40 50 60 70 80 90 100

R2R1R3 R1 R2R1R3 R1 R2R1R3 R1 R2R1R3 R1 R2R1R3 R1

Figure 3. Dispatch table before the insertion of R4.

Slot 1 2 3 4 5 6 7 8 9 10 11 12 ...Load 1 2 4 2 1 2 4 2 1 2 4 2 ...

Table IILOAD REPARTITION CORRESPONDING TO THE DISPATCH TABLE IN

FIGURE 3.

At that point, choosing one of the least loaded slots inthe dispatch table with make the schedule fail becauseR4 will also have to be allocated in a slot with thehighest load because of its periodicity. For example, ifthe first instance of R4 is allocated in slot 1, the nextinstance will be placed in slot 11 and make the systemunschedulable. However, allocating R4 in any even slotis safe.

In order to deal with non-harmonic runnable sets, weneed to go through a larger window of slots for thechoice of the offsets. In the following, variable Twindowis equal to the lcm of the periods of the runnables alreadyscheduled at the current state of the algorithm. Insteadof looking for the least loaded slot in the first Ti/Tticslots, we try to create the lowest peak over Twindow,knowing that the schedule repeats in cycle afterwards.This algorithm is further referred to as “Lowest peak”or LP for short.

Algorithm 3 “Lowest peak” heuristic.input: runnable set {Ri}, Ttic, Tcycle(1) Sort runnables Ri such that Ttic ≤ T1 ≤ . . . ≤ Tn ≤Tcycle.(2) Twindow = Ttic.(3) For i = 1 . . . n

(a) Twindow = lcm(Twindow, Ti),(b) In the first Ti

Tticslots, look for the slot such that

the highest load in the slots where Ri is periodicallyallocated in the Twindow

Tticfirst slots is the lowest,

(c) Allocate Ri in every Ti

Tticslot starting from this

slot.

Step (1) of algorithm 3 runs in O(n · log n). Step (3a)runs in O(log Tcycle). Step (3b) and (3c) respectivelyrun in O(nTwindow

Ttic) ≤ O(nTcycle

Ttic) and O(nTcycle

Ti) ≤

O(nTcycle

Ttic). As a result, the whole algorithm runs in

O(n(log n+ 2Tcycle

Ti+ log Tcycle)).

5) Improvement: placing outliers first: The algo-rithms described in sections III-A and III-B constructthe sequencing of runnables with arbitrary periods andpossibly with locality and inter-runnable constraints.Experiments show that these algorithms sometimes donot always perform well with runnable sets where a fewrunnables with a low frequency have a very large WCETcompared to the other runnables.

In practice, runnables with a large WCET tend to havea large period. As a result, runnables with large WCETare usually processed late in the runnable allocationprocess which explains the load peaks. In order to reducethose peaks, the scheduling algorithm is improved byprocessing some runnables with a large WCET first1.

We define the WCET threshold Ccritic = µ + k · σwith µ and σ denoting respectively the average and thestandard deviation of the distribution of {Ci} and k aninteger value. The runnables with Ci larger than Ccriticare allocated first. Then, the rest of the runnables areprocessed as done in algorithm 3. This new version ofthe load-balancing algorithm is referred to as LowestPeak k-sigma, or LPkσ for short.

IV. EXPERIMENTATIONS

Here we evaluate the ability of the algorithms touniformize the CPU load over time and to keep onproviding feasible solutions at very high load level. Forthis purpose, the algorithms LL, LP, and LPkσ, describedrespectively in §III-B1, §III-B4 and §III-B5, have beenimplemented in the freely available software RTaW-ECU [12].

A. Balancing performance

We applied the algorithms to sets of runnables that arerealistic in the sense that their characteristics (i.e., period,WCET) are drawn at random from distributions derivedfrom an existing PSA body gateway ECU with about200 runnables whose periods are close to harmonic (onlyabout 5% of the runnables have non-harmonic periods).

In the experiments of the paper, the duration of theslot, Ttic, is set to 5ms, the largest WCET is 30xthe smallest and the periods are non-harmonic chosenin {10, 20, 25, 40, 50, 100, 200, 250, 500, 1000ms}. Ran-dom dependencies between runnables are also introducedthrough the following parameters:• Interdependency ratio, that is the percentage of

runnables that are dependent and thus must beexecuted on the same core, chosen equal to 30%.

• Maximum size of the clusters of dependentrunnables is equal to 4.

• Core locality constraint ratio: percentage ofrunnables that are pre-allocated to a given core,chosen equal to 30%.

The following additional parameters are used for thisexperimentation Cmax = 300µs, Ttic = 5ms, Tcycle =1s and there are over 4000 runnables to schedule on 3

1Allocating the runnables by decreasing order of WCET provesnot to be an efficient approach in our experiments.

cores inducing an average load of 95% of the capacityof the ECU. The parameters have been set so that theproblem is challenging as we are above the harmonicschedulability bound which would be here 94%.

The distribution of the load obtained with the LowestPeak and Lowest Peak 1-sigma (LP1σ) algorithms areshown in figure 4. In the two sub-graphics, the X axisis the time-line and the Y axis is the load of the slotsin percentage. The left-hand graphic shows that LP failsto provide a feasible schedule since the load is slightlyabove 100% in some slots (e.g., slots 29, 30 of core 1).The few load peaks (corresponding to around 5 % ofthe core capacity) are due to runnables having a largeWCET with a large period, and thus having been placedlate in the allocation process. On the other hand, LP1σ

is able to successfully schedule the runnable sets on thethree cores with a well balanced distribution of load. Inaddition, around 5% of the capacity of each core remainsavailable most of the time, which means that some morerunnables can be added in future evolutions of the ECU.

B. Schedulability performances and robustness on auto-motive ECUs

The goal is to assess the extent to which the schedula-bility bound, even if it has been derived in the harmoniccase, can provide guidelines for the non-harmonic case.Precisely, we measure the success rate of the algorithmsin the non-harmonic case at load levels such that feasibil-ity would be ensured in the harmonic case. In the existingbody gateway ECU, the set of task periods is close tobe harmonic since withdrawing only a few runnablesensures the harmonic property. To test the algorithmsin a more difficult context, we build a “hard” non-harmonic case with more departure from the harmonicproperty. Precisely the periods are now chosen in the set{10, 20, 25, 40, 50, 100, 125, 200, 125, 500, 1000ms}.

max WCET (µs) 150 300 900Schedulability boundin the harmonic case 97% 94% 82%

Success % of LL in the“hard” non-harmonic case 96% 96% 92%

Success % of LP in the“hard” non-harmonic case 100% 100% 100%

Table IIIPERFORMANCES OF THE SCHEDULING ALGORITHMS IN THE

NON-HARMONIC CASE WHEN THE LOAD IS CLOSE TO THEHARMONIC SCHEDULABILITY BOUND. STATISTICS COLLECTEDON 1000 RANDOM CONFIGURATIONS FOR EACH MAX. WCET

VALUE. THE SCHEDULABILITY BOUND IS DERIVED FROMTHEOREM 2.

As can be seen in Table III, when the load is close tothe harmonic schedulability bound the algorithms remain

Figure 4. Distribution of the load percentage over time. The left-hand graphic shows the result of the “Lowest Peak” algorithm whileright-hand graphic shows the result of the “Lowest Peak 1-sigma” algorithm. Only the first 30 slots are shown in the graphics but they arerepresentative of the whole 200 slots of the sequencer tasks. The algorithms of this study have been implemented as plugins of RealTime-at-Work’s RTaW-ECU [12] software.

efficient, in particular the LP which was able to success-fully schedule the 1000 random configurations of thetest. This suggests to us that the harmonic schedulabilitybound is a good dimensioning criterion also in the non-harmonic case.

Table IV presents the results obtained at higher loads,i.e. above the harmonic schedulability bound. Preciselysets of runnables with max. WCET equal to 300µsand 900µs and CPU loads equal to 95% and 97% arescheduled with LL, LP and LP1σ.

CPU load 95% 97% 95% 97%Schedulability boundin the harmonic case

94%WCET=300µs

82%WCET=900µs

Success % of LL 64% 18% 12% 1%Success % of LP 94% 94% 30% 5%

Success % of LP1σ 100% 100% 97% 76%

Table IVPERFORMANCES OF THE SCHEDULING ALGORITHMS IN THE

NON-HARMONIC CASE WHEN THE LOAD IS GREATER THAN THEHARMONIC SCHEDULABILITY BOUND. STATISTICS COLLECTEDON 1000 RANDOM CONFIGURATIONS FOR EACH MAX. WCET

VALUE.

As it was expected, the lower the schedulability bound,the harder it is to schedule the runnables (comparefor instance the 97% columns). The second lesson isthat LP1σ clearly outperforms all the other contendersespecially when the WCETs are large.

V. COMBINING RUNNABLE SEQUENCING WITH TASK

SCHEDULING

In this section, we address the global scheduling at theOS-level in an approach combining sequencer tasks withother OS tasks. We assume that the different tasks are

scheduled by a fixed priority preemptive scheduler as itis the case in AUTOSAR ECUs. In the next subsections,two cases are distinguished: synchronized tasks and nonsynchronized tasks. In the first case, the initial offsetsbetween tasks are known and the tasks are scheduledusing a single clock. In the second case, the differentsequencer tasks may be driven by different clocks. Thislatter case arises, for instance, in engine controllers inwhich some runnables are driven by the microcontrollerclock while others are driven on the basis of the engineRPM which varies over time. For each case, we discusshow to build the slot allocation of the sequencer tasksso as to maximize the schedulability of the task set,before addressing how to verify the schedulability of theresulting solution.

A. Problem description

In this section, the focus is set at the core level andthe assumption that only one sequencer task is scheduledon each core is relaxed. Now, it is assumed that onecan have several sequencer tasks on a same core. Thiscase arises when memory protection across runnablesis needed. Indeed, memory protection, such as providedby AUTOSAR OS, cannot be ensured at the runnablelevel but at the task (or ISR and OS-application) level.Then, we are given now an extra set of periodic tasks thatneeds to be scheduled on the same core and described asusual by Ti = (Ci, Ti, Di, Ji). Quantities Ci, Ti, Di andJi correspond respectively to the Worst-Case ExecutionTime (WCET), the period, the relative deadline and therelease jitter of the task Ti .

In the context of this problem, the runnables havealready been allocated onto a set of sequencer tasks Sj ,described such as in II-B2, according to their source and

memory protection requirement but the slot allocationremains to be done. The schedulability condition 3of II-B4 is also relaxed: it is too stringent for the casewhere one has multiple sequencer tasks per core sincehigher priority tasks may preempt the sequencer tasksduring a whole slot duration. As of now, we only requirerunnables to have a single instance active at each pointin time, which corresponds to the classical case wheredeadlines are equal to periods. Finally, though it canbe handled in our framework, it is assumed that therelease jitter of a sequencer task is negligible becauseits activations are usually driven by a high priority OSservice. Given these hypotheses, the problem is to find astrategy to build the slot allocation of all the sequencertasks in order to increase the schedulability of the systemconsisting in a task set and some runnable sets that arescheduled on the same core.

B. Synchronized tasks

Synchronized means here that the initial offsets ofthe different tasks are known and that all the tasks arescheduled using the same time basis. As a consequence,the tasks’ phasings are known and can be used whenbuilding the slot allocation of the sequencer tasks. Asin the case where one has a single sequencer, this latterproblem cannot be solved optimally (see §III-B1) and aheuristic approach is required.

We propose a similar approach as done for the LPalgorithm but here one has to take into account theinterferences of higher priority tasks. When placing arunnable, we look for the slot that minimizes the highestresponse time of the runnable, throughout all the slotswhere it is allocated (until the schedule repeats itself).For that purpose, each slot is transformed in a task thatcaptures the execution requirements of all the runnablesallocated in the slot.

The response time needs to be calculated for each slotin the hyperperiod of the task set (possibly longer thanTcycle of the sequencer task). This can be done usingthe response time analysis for static priority tasks withoffsets and jitters introduced in [15] and applying itfor each slot to whom the runnable belongs. Integrat-ing sequencer tasks into Redell’s approach is done bytransforming the slot allocations into a task set. Each ofthe slots is translated into a single task with the properoffset and a period equal to Tcycle. This does not furthercomplexify Redell’s analysis since the number of taskinstances remains the same.

Though this approach is extremely computation inten-

sive2, usual automotive applications lead to small hyper-periods since the task sets have almost harmonic periods.Furthermore the schedulability analysis is conducted atthe same time as the sequencer tasks are built.

C. Non synchronized tasks

The previous approach cannot be applied to nonsynchronized tasks since their offset and time basisare not known. If the tasks are scheduled on differentand varying time bases (e.g, CPU clock and engineRPM), whatever the way a sequencer task is constructed,every higher priority task can interfere with any ofthe sequencer task’s slot, as all offset configurationsbetween them are possible at run-time. This means that,on the contrary to the synchronized case of §V-B, wecannot take advantage of the characteristics of the higherpriority tasks when building the slot allocation of asequencer task. The maximum robustness against all pos-sible asynchronisms between sequencer tasks is achievedby balancing the load of each of the tasks individually,as done in the basic use-case of the algorithms of §III-B.

Because of the possibly varying time bases, theschedulability of the slot allocation cannot be checkedas in the previous cases. However, if it is possible tobound the clock speed of each sequencer task, the multi-frame task model (i.e., periodic activations but varyingexecution times between instances [16]) can be used tocheck the feasibility of the schedule. The transformationof a sequencer task into a multi-frame task is loseless :the slots of a sequencer task become the task instanceswith their execution times depending on the runnablesactually scheduled in each slot. Then, assuming themaximum clock speeds, which lead to the worst-caseworkload arrival, a multiframe schedulability test can beapplied, for instance [17], [18] or [19] which integratesrelease jitters in the schedulability analysis.

VI. CONCLUSION

Multi-source software and multicore ECUs will dras-tically change the electrical/electronic architectures andshould enable more cost-effective and more flexibleautomotive embedded systems. In our view, the OSprotection mechanisms specified by AUTOSAR providea sound basis to develop appropriate safety mechanismsand policies, despite the growing complexity and crit-icality of software functions. However, today’s designmethodologies need to be adapted to this new contextand there is a wide range of technical problems to

2The problem of computing response times with offsets in thesynchronized case is conjectured to be NP-hard, though, to the bestof our knowledge, there is no proof in the literature.

be solved. Among these issues are the design of thesoftware architectures and the scheduling of the softwarecomponents, which have been considered in this paper.

The set of runnable sequencing algorithms proposedin this paper aims at uniformizing the load over time,and thus increase the maximum workload schedulableon the CPU. The algorithms also provide guaranteedperformance levels in some specific contexts. Experi-mentations on realistic case-studies have confirmed thealgorithms to be versatile and efficient in terms of CPUusage optimization.

We have presented practical solutions to scheduleactivities according to both the static cyclic and priority-driven paradigms, as it is becoming a need in automotivemulticore ECUs and other complex embedded systemswith dependability requirements such as are required inthe aerospace domain. Our ongoing work is to extendthis study to handle the constraints originating from thecommunication between runnables located on distinctECUs. This first requires the precise modeling of thedata exchanges and capture their timing constraints, forinstance using the TIMMO-2-USE methodology [20],then to extend the scheduling algorithms.

REFERENCES

[1] A. Emadi, Y. Lee, and K. Rajashekara, “Power electronics andmotor drives in electric, hybrid electric, and plug-in hybridelectric vehicles,” IEEE Trans. on Ind. Electronics, vol. 55,no. 6, pp. 2237–2245, june 2008.

[2] F. Mapelli, D. Tarsitano, and M. Mauri, “Plug-in hybrid electricvehicle: Modeling, prototype realization, and inverter losses re-duction analysis,” IEEE Trans.on Industrial Electronics, vol. 57,no. 2, pp. 598 –607, feb 2010.

[3] D.-J. Kim, K.-H. Park, and Z. Bien, “Hierarchical longitudinalcontroller for rear-end collision avoidance,” IEEE Trans. onIndustrial Electronics, vol. 54, no. 2, pp. 805 –817, april 2007.

[4] T. Bucher, C. Curio, J. Edelbrunner, C. Igel, D. Kastrup,I. Leefken, G. Lorenz, A. Steinhage, and W. von Seelen, “Imageprocessing and behavior planning for intelligent vehicles,” IEEETrans. on Industrial Electronics, vol. 50, no. 1, pp. 62 – 75, feb2003.

[5] N. Navet, A. Monot, B. Bavoux, and F. Simonot-Lion, “Multi-source and multicore automotive ECUs - OS protection mech-anisms and scheduling,” in IEEE International Symposium onIndustrial Electronics (ISIE), 2010.

[6] A. Burchard, J. Liebeherr, Y. Oh, and S. H. Son, “New strategiesfor assigning real-time tasks to multiprocessor systems,” IEEETrans. on Computers, vol. 44, no. 12, pp. 1429–1442, Dec.1995.

[7] Y. Oh and S. Son, “Fixed-priority scheduling of periodic taskson multiprocessor systems,” Department of Computer Science,University of Virginia, Tech. Rep. CS-95-16, 1995.

[8] S. Lauzac, R. Melhem, and D. Mossé, “An improved rate-monotonic admission control and its applications,” IEEE Trans.on Computers, vol. 52, no. 3, pp. 337–350, 2003.

[9] A. Karrenbauer and T. Rothvoss, “An Average-Case Analysisfor Rate-Monotonic Multiprocessor Real-time Scheduling,” in17th Annual European Symposium on Algorithms (ESA), 2009.

[10] J. Goossens, “Scheduling of offset free systems,” Real-TimeSystems, vol. 24, no. 2, pp. 239–258, March 2003.

[11] M. Grenier, L. Havet, and N. Navet, “Pushing the limits of CAN- scheduling frames with offsets provides a major performanceboost,” in European Congress of Embedded Real-Time Software(ERTS), 2008.

[12] RealTime-at-Work, “RTaW-ECU: Static cyclic scheduling oftasks,” Available for download at http://www.realtimeatwork.com, 2011.

[13] AUTOSAR Consortium, “Specification of multi-core OS archi-tecture v1.0,” AUTOSAR Release 4.0, 2009.

[14] M. Abramowitz and I. Stegun, Handbook of MathematicalFunctions. Dover Publications (ISBN 0-486-61272-4), 1970.

[15] O. Redell and M. Törngren, “Calculating exact worst caseresponse times for static priority scheduled tasks with offsetsand jitter,” in Real-Time and Embedded Technology and Appli-cations Symposium (RTAS), 2002.

[16] A. Mok and D. Chen, “A multiframe model for real-time tasks,”IEEE Trans. on Software Engineering, vol. 23, pp. 635–645,1996.

[17] S. Baruah, D. Chen, and A. Mok, “Static-priority scheduling ofmultiframe tasks,” in 11th Euromicro Conference on Real-TimeSystems, 1999, pp. 38–45.

[18] A. Zuhily and A. Burns, “Exact response time schedulinganalysis of accumulatively monotonic multiframe real timetasks,” Real-Time Systems, vol. 43, no. 2, 2009.

[19] ——, “Exact scheduling analysis of non-accumulatively mono-tonic multiframe tasks,” in 16th International Conference onReal-Time and Networked Systems (RTNS), 2008.

[20] ITEA2 TIMMO-2-USE Consortium, “Masteringtiming tools, algorithms, and languages,” available athttp://www.timmo-2-use.org/overview.htm, 2011.

Aurélien Monot graduated from the engi-neering school Ecole des Mines de Nancy in2008, majoring in Computer Science. Afterspending 6 months at the IBM research lab inZürich, he started an industrial Ph.D at PSAPeugeot-Citroën co-supervised by the LORIAin Nancy on "end-to-end timing constraintsin the AutoSar context". He is now INRIAresearch engineer in the ITEA2 Timmo-2-Use

project. His main topics of interest are real-time embedded systemsand model-based design approaches.graduated from the engineeringschool Ecole des Mines de Nancy in 2008, majoring in ComputerScience. After spending 6 months at the IBM research lab inZürich, he started an industrial Ph.D at PSA Peugeot-Citroën andco-supervised by the LORIA in Nancy on the topic of "End-to-endreal Time constraints in the AutoSar context". He is now also involvedin the ITEA project Timmo-2-Use as a member of INRIA. His maintopic of interests are real-time embedded systems and model-baseddesign approaches.

Nicolas Navet is a researcher at INRIA (LO-RIA Lab, France) since 2000 and head of theINRIA TRIO project (Real-Time and Interop-erability). His research interests include real-time and embedded systems, communicationprotocols, fault tolerance and dependability as-sessment. For the last 17 years, he has workedon numerous projects with OEMs and suppli-ers in the automotive and avionics domains.

He is the founder of RealTime-at-Work, a company that helps systemdesigners build truly safe and optimized critical systems. He has aB.S. in Computer Science from the University of Berlin (1993) anda PhD in Computer Science from the Institut National Polytechniquede Lorraine (1999).

Bernard Bavoux is a 1984 Supélec gradu-ate engineer. He began his career developingembedded microcontroller and printed circuitsboards for spatial projects at Thales (formerlyThomson) during 5 years. Then he movedto the aeronautic domain at TEAM, a worldleader equipment supplier. There during 9years, he was in charge of the electronic designoffice, including research and development, for

analog and digital audio intercommunication systems. Since 14 yearshe has been working in the automotive industry: During 5 years atValeo, he managed an Electric and Electronic Architecture innovationteam and an embedded Electronic Control Units research team.Currently at PSA Peugeot Citroën, he is leading an advanced researchteam in the fields of Electricity, Electronics and Opto-electronics inconnection with the best research institutes in the world. Since 10years, he is recognized as a senior expert in this field.

Françoise SIMONOT-LION is Professor ofComputer Science at University of Lorraine(France). Between 1997 and 2010, she wasthe scientific leader of the Real Time and In-terOperability (TRIO) LORIA/INRIA researchteam and since 2010, head of the LORIA lab-oratory. Her research topics are modeling andanalysis of real time distributed systems. Sheis involved in several research collaborations

with automotive industry and was co-chair of the subcommittee“Automotive Electronic and Embedded Systems” of the IEEEIndustrial Electronic Society (IES) - TCFA. She coauthored morethan 100 technical papers in the area of real-time systems modelingand analysis and is associate editor of the IEEE Transactions onIndustrial Informatics.