A Novel Heuristic Algorithm for Mapping AUTOSAR Runnables to

Tasks

Fouad Khenfri

1,2

, Khaled Chaaban

and Maryline Chetto

S2ET, ESTACA, Rue Georges Charpak, 53061 Laval, France

IRCCyN, University of Nantes, 1 Rue de la Noe, 44321 Nantes, France

Keywords:

Optimization, Real-time scheduling, AUTOSAR.

Abstract:

This paper describes a novel algorithm that permits to automate the process to map runnables to tasks in

any AUTOSAR architecture. This enables to boost system performance by reducing the number of tasks

to be implemented and while preserving system schedulability. Our algorithm uses some properties related

to the activation offset for mapping runnables with distinct periods to the same task. We consider periodic,

independent and ﬁxed-priority tasks running on a single processor. The results of an experimental study are

reported. First, they show that our algorithm reduces signiﬁcantly the number of tasks with distinct periods

while preserving system schedulability. And second, the system schedulability bound is increased by 34%

compared to the typical periodic solution and the average response time of tasks is reduced by 30% related to

ohers solutions.

1 INTRODUCTION

AUTOSAR (AUTomotive Open System ARchitec-

ture) development partnership has been created by

automotive manufacturers, suppliers and tool devel-

opers in order to establish an open industry standard

for automotive E/E (Electrical/Electronic) architec-

tures (Partnership, 2011). AUTOSAR provides a set

of concepts and deﬁnes a methodology for the auto-

motive software development process. Some key fea-

tures of this standard are modularity and conﬁgura-

bility of automotive architectures. AUTOSAR per-

mits functional reuse of software modules from differ-

ent suppliers and guarantees interoperability of these

modules through standardized interfaces.

In AUTOSAR, runnables represent the internal

behavior of each SoftWare Component (SWC) and

are the smallest pieces of code to be scheduled. Each

SWC contains at least one runnable. All runnables

are triggered in response to an event such as a tim-

ing event (for periodic runnables), data receiving, or

operation invoking of runnables. If no event is spec-

iﬁed for the runnable, it will never be activated. Fur-

thermore, runnables can be executed only if they are

mapped to tasks. The process of mapping runnable to

task is illustrated in Figure 1.

Developing an automotive application which is

compliant to the AUTOSAR standard needs the ini-

Assigning

runnables to tasks

Sequencing

runnables

Application Description

(SW architecture)

Task 1

ISR 1

Task1

(1,10,0) r

(1,15,0) r

(1,30,5)

Task y

ISR z

SWC1

SWC2

Figure 1: Runnable mapping process in AUTOSAR.

tialization of many parameters. They are mainly re-

lated to SWCs, allocation of SWCs to the hardware

architecture, and ﬁnally conﬁguration of each Elec-

tronic Control Unit (ECU). In the ECU conﬁguration

phase, mapping runnables to OS (Operating System)

tasks is crucial since it may impact system perfor-

mance and its real-time behavior signiﬁcantly. Sev-

eral design decisions have to be considered including:

• How many tasks are needed to implement the en-

tire set of runnables?

• How to specify priorities of tasks?

• How to deﬁne the execution order and activation

offset of runnables which are mapped to the same

task?

There are mainly three ways to address this prob-

lem as shown in Figure 2.

239

Khenfri F., Chaaban K. and Chetto M..

A Novel Heuristic Algorithm for Mapping AUTOSAR Runnables to Tasks.

DOI: 10.5220/0005234202390246

In Proceedings of the 5th International Conference on Pervasive and Embedded Computing and Communication Systems (PECCS-2015), pages

239-246

ISBN: 978-989-758-084-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

sásrár N

sáswár N

sátrár N

sáurár

First solution: Periodic Solution (PS)

Second solution: Multiple Periodic Solution (MPS)

Third solution: Arbitrary Periodic Solution (APS)

S?APá LANEK@á KBBOAP ã

Figure 2: Solutions to map runnables to different tasks.

The ﬁrst and simplest solution is to map runnables

with same period to one task. In this Periodic Solution

(PS), the worst-case execution time (WCET) of the

task is the sum of WCET of all runnables mapped to

it. Hence, the number of tasks is equal to the number

of the different periods assuming that a task WCET is

less or equal than its period. However, tasks priorities

are assigned according to the rate monotonic priority

assignment (RMPA) or the deadline monotonic prior-

ity assignment (DMPA) in order to guarantee system

schedulability.

Another solution consists in mapping runnables

with multiple periods to the same task. In this Multi-

ple Periodic Solution (MPS), the period of the task is

the shortest period among different runnables mapped

to it. Its maximum WCET is the sum of the WCET

of all these runnables. The number of tasks in this so-

lution is less than the ﬁrst one when considering the

same assumptions.

However, in order to obtain a minimal number of

tasks, the best solution is to map the runnables with

different periods to the same task using their activa-

tion offset. In this Arbitrary Periodic solution (APS),

the period of a task is the greatest common divisor

(GCD) of all runnables periods mapped to it. Task

WCET in this case must be less than the task period.

The advantages of this solution are multiple, namely

the minimization of time overhead due to task context

switch and the minimization of stack memory usage

by minimizing the number of tasks.

For MPS and APS, system schedulability may be

guaranteed using RMPA or DMPA by assuming that

the task deadline is less than its period. Otherwise,

if the deadline is arbitrary (i.e. the deadline may

be higher than the period), the Audsley’s algorithm

(Audsley, 1991) may be used to assign tasks priori-

ties. Nevertheless, the issue here is how to determine

the set of runnables that can be mapped to the same

task in order to guarantee system schedulability.

Currently and in industrial practices, system de-

signers use the ﬁrst two solutions (PS and MPS) and

their best knowledge of the system in order to con-

ﬁgure empirically ECU software. Nevertheless, this

may reveal to be an error-prone and time-consuming

process. Thus, an optimization approach appears to

be necessary to realize this conﬁguration phase.

The aim of the work presented in this paper is

to propose an efﬁcient algorithm, based on APS, for

mapping runnables to tasks while preserving system

schedulability. This algorithm allows determining

simultaneously, the number of OS tasks needed to

schedule the set of runnables, the priorities of tasks,

and the sequencing of the different runnables inside

tasks.

The paper is organized as follows: section 2

presents relevant related works. Section 3 describes

the system model. Section 4 details our proposed so-

lution to solve the mapping problem. Section 5 re-

ports and discusses experimental results before we

conclude the paper in section 6.

2 RELATED WORKS

In the context of AUTOSAR, there are many works

that address the problem of mapping runnables to

tasks (Rongshen et al., )(Haibo and Di Natale, )(Zeng

et al., 2012)(Monot et al., 2012)(Navet et al., 2010).

In (Rongshen et al., ), the authors discuss several rules

for mapping runnables to tasks based on intra-ECU

communication (communication between runnables

located on the same ECU), but there is no speciﬁed

optimization method. Further, this work does not con-

sider system schedulability. In (Haibo and Di Na-

tale, ), a MILP (Mixed Integer Linear Programming)

method is applied to solve an optimization problem.

This method chooses between protection mechanisms

to ensure data consistency. It considers that runnables

are already mapped to tasks and task priority assign-

ment is given.

In (Zeng et al., 2012), a simulated annealing

method is applied to ﬁnd the optimal mapping and

tasks priorities assignment using MPS so as to op-

timize stack memory usage. After each transition

of the optimization loop, execution order and pre-

emption threshold of runnables are computed using

a heuristic method. Authors of (Monot et al., 2012;

Navet et al., 2010) developed two heuristics for multi-

core architectures. The ﬁrst one distributes runnables

to different cores in order to uniformize core loads.

The second one maps runnables from the same core

to one sequencer task using the activation offset of

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

240

runnables. This heuristic assumes that the WCET of

runnales is much smaller than their periods since it

considers only one sequencer task per core. In (Ming

and Zonghua, ), a genetic algorithm is used to se-

lect protection mechanisms in order to guarantee data

consistency of each ECU with the objective of mini-

mizing the memory size. The authors use PS to map

runnables to tasks. In (Wozniak et al., 2013), the au-

thors propose a method using genetic algorithm for

the synthesis of AUTOSAR architecture (to solve the

SWCs to ECUs mapping problem, runnables to tasks

mapping problem and data elements to bus frame

mapping problem). In their work, MPS is used to map

runnables to tasks.

To the best of our knowledge, there is no work

uses the APS for mapping runnables to many tasks.

By the following, we detail the system model con-

sidered in this study and the proposed optimization

approach.

3 SYSTEM MODEL

This section describes the system model for both

runnables and tasks. AUTOSAR OS is based on the

industry standard OSEK OS. It is responsible for ex-

ecuting real-time tasks and ISRs (Interrupt Service

Routines). It provides a ﬁxed-priority scheduling

policy. Each task is assigned a static priority and

higher priorities are given to ISRs. During execu-

tion time, the scheduler decides which ready task is

to be executed next, based on its priority. However,

AUTOSAR does not specify the priority assignment

scheme. Rate Monotonic or Deadline Monotonic

schemes can be used within its context. The conﬁgu-

ration of AUTOSAR OS is done statically. All the ob-

jects of the OS and their parameters have to be deﬁned

before the deployment of the software. Moreover,

let’s recall that two types of tasks/runnables exist in

AUTOSAR: time-triggered and event-triggered. In

this work we assume that all tasks/runnables are time-

triggered and periodic. Dealing with non-periodic

tasks/runnables may be more difﬁcult because of the

non-deterministic release times. Hence, we start by

developing a solution for periodic tasks/runnables

which can be later extended to cover non-periodic

ones.

3.1 Runnables

Any runnable, say r

, is the basic element to be exe-

cuted in the context of any task, say τ

, with priority

. r

is characterized by four timing parameters O

, T

, D

and position parameter k

• O

, activation offset, i.e. triggering instant of the

execution request.

• C

, worst-case execution time (WCET), with 0 ≤

≤ D

≤ T

• T

, period.

• D

, relative deadline, i.e. the maximum acceptable

delay for its processing.

• k

, execution order in task τ

The two parameters O

and k

can be tuned to sat-

isfy system schedulability.

3.2 Tasks

Let us denote by ∆ = {r

,...,r

}, the set of

runnables mapped to the same task τ

. An execution

order i (where 1 is the ﬁrst execution order and n is

the last) is assigned to each runnable r

In order to map runnables with distinct periods to

the same task, we need to determine the activation off-

set of each runnable. This task is called dispatcher

(or sequencer) task which stores the runnables offsets

in a scheduling table and releases them at the right

points in time (Monot et al., 2012). The period of the

dispatcher task (micro-cycle) T

tic

is deﬁned by the

greatest common divisor (GCD) of all runnables peri-

ods mapped to it. Moreover, the dispatcher task exe-

cutes these runnables in a cyclic manner (major-cycle)

cycle

, which is the least common multiple (LCM) of

all runnables mapped to it (see Fig. 1). The WCET of

dispatcher tasks C

= {C

,...,C

N−1

}, is a

vector, where N = T

cycle

tic

is the number of slots.

The WCET C

of the s

slot is given by:

∑

i=1

(s) ∗C

(1)

where the function x

(s) indicates the presence or

not of the i

runnable in the s

slot. This function is

given by:

(s) =



1 i f a

(s) = s

0 i f a

(s) ̸= s

(2)

with,

(s) =





+ δ

(3)

where a

(s) is the release time position of the i

runnable in the s

slot (see example 1). γ

= T

tic

and δ

= O

tic

represent respectively the repetition

factor and the ﬁrst position of the i

runnable in the

slots .

ANovelHeuristicAlgorithmforMappingAUTOSARRunnablestoTasks

241

Proposition 1. The relative deadline D

of dis-

patcher task τ

guarantees the timing requirements of

all runnables mapped to it if, and only if, the worst

case response time of τ

is less than or equal to D

given by:

= min

s=0...N−1

} (4)

with,

max

s=0...N−1

} ≤ D

≤ T

cycle

(5)



min

k∈R(s)



∑

i=k+1

(s).C



i f R(s) ̸=

∞ i f R(s) =

(6)

NOTE: R(s) denotes the set of runnables posi-

tioned in the slot s.

Proof. Let us consider that a set of runnables

∆ = {r

,...,r

} is mapped to the same task

. Each runnable r

is assigned an execution order k

(where 1 is the ﬁrst execution order and n is the last)

and a deadline D

. When all runnables are mapped in

the ﬁrst slot (i.e., ∀k, x

(s) = 1 with s=0), the deadline

of dispatcher task (4) is rewritten as follows:

= min

k=1...n−1



∑

i=k+1



(7)

To verify timing constraints for all runnables, we

need to ﬁnd the deadline of dispatcher task which re-

spects the following inequalities:

≤ D

−C

≤ D

n−1

− (C

+ ... +C

k+1

) ≤ D

− (C

+ ... +C

) ≤ D

(8)

It can be observed that equation (7) satisﬁes the in-

equality above. When all runnables are positioned in

different slots, the relative deadline of dispatcher task

is the minimum of deadlines among all slots. These

deadlines are computed by equation (7) applied for

each slot given by (6).

Example 1: Figure 3 illustrates a dispatcher task

for a set of four periodic runnables r

(0,1,10, 8,1), r

(5,1,15, 10,2), r

(0,1,15, 12,3)

and r

(25,1,30, 20,4). The period of the dispatcher

task is GCD(10,15,15,30)=5ms, and its major cycle is

LCM(10,15,15,30)=30ms. Thus, the number of slots

is 6.

Figure 3: Illustration of activation offset for runnables with

position in task.

Table 1 displays values for an example to com-

pute the WCET C

of equation (1) and the deadline

of equation (6) of the s

slot. From equation (4), the

deadline of dispatcher task D

is 8 ms.

Table 1: Computation of WCET and deadline of s

slot.

slot a

(s) x

(s) C

0 0 1 0 5 1 0 1 0 2 9

1 0 1 0 5 0 1 0 0 1 10

2 2 1 0 5 1 0 0 0 1 8

3 2 4 3 5 0 0 1 0 1 12

4 4 4 3 5 1 1 0 0 2 9

5 4 4 3 5 0 0 0 1 1 20

Note: If T

cycle

= T

tic

, there is one slot where

all runnables are mapped to the same task τ

. Thus,

runnables are activated at the same instant and have

the same period. In this case, the dispatcher task

model comes close to the task model of Liu and Lay-

land τ

) (Liu and Layland, 1973). Fur-

ther, the task WCET equals to the sum of the WCET

of all runnables mapped to it, its period T

equals

to the period of its runnables, and its deadline D

given by (7).

Let us note that the Liu and Layland’s task model

) is a particular case of the dispatcher

task model τ

tic

cycle

In the following section, we introduce a new

heuristic that relies on the APS solution, inspired

by Audsley’s priority assignment approach (Audsley,

1991). A Least Loaded (LL) algorithm (Monot et al.,

2012) is adapted to ﬁnd the activation offset of every

periodic runnable that respects its execution order.

4 APS-BASED HEURISTIC

ALGORITHM

In this section, a heuristic is developed to solve the

next optimization problem:

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

242

Find: Runnables assigned to tasks,

Activation offset for runnables,

Execution order of runnables,

Tasks priorities.

Minimize: Number of tasks

Subject to: Schedulability of the task set

Our heuristic is inspired by Audsley’s priority as-

signment in order to establish a minimal set of tasks

τ = {τ

,...,τ

}. Furthermore, each task τ

is assigned

a priority j (where 1 is the lowest priority and m is

the highest). The cardinal number m represents the

number of tasks. The task τ

is built from a set of

runnables Π

which is a subset of the entire input set

of runnables ∆ to be mapped. The activation offset

and execution order parameters are speciﬁed to assign

each runnable set Π

to task τ

. Thus, for each prior-

ity level j (starting with the lowest priority) there are

the two following steps:

1. The ﬁrst step tries to ﬁnd an optimal set of

runnables Π

to assign it to the same task τ

. A

scheduling feasibility test is applied to ﬁnd Π

∆ as detailed in the next subsection (4.1).

2. The second step permits to specify activation off-

set and execution order of runnable set Π

, in or-

der to ovoid overload situation in the slots (i.e., the

max of WCET of dispatcher task is greater than its

period T

tic

or its deadline D

). Otherwise, a re-

ject set Λ

will contain the ﬁrst runnables leading

to overload situations.

At priority level j+1, a task τ

j+1

assigned to this

priority level is created of Π

j+1

, which is a subset of

(∆\Π

) ∪ Λ

. Hence, the set of tasks Γ = {τ

,...,τ

}

is set up until obtaining an empty set of ∆, where

∩ Π

,...,∩Π

is empty and Π

∪ Π

,...,∪Π

equal to ∆ (see Algorithm 1).

Algorithm 1: Heuristic for mapping runnables to

tasks.

Data: runnable set ∆

1 Γ ←

0 ;

2 Failed ← False ;

3 j ← 1 ;

/* index of lower priority */

4 while ((∆ ̸=

0)&&(Failed = False)) do

5 Π

← Algorithm2(∆) ;

6 if Pi

̸=

0 then

7 (Λ

,τ

) ← Algorithm3(Π

, j) ;

8 Γ ← τ

;

9 ∆ ← (∆\Π

) ∪ Λ

;

10 j ← j + 1 ;

11 end

12 Failed ← True ;

/* The system is unschedulable */

13 end

14 return Γ

4.1 Assignment of Runnables to Tasks

We detail here the ﬁrst step of Algorithm 1 whose ob-

jective is to ﬁnd, for each priority level j, an optimal

set of runnables Π

⊆ ∆ to be assigned to the same

dispatcher task τ

. The following proposition explains

how the set of runnables Π

is selected.

Proposition 2. Let us assume a set of runnables

= {r

,...,r

} of cardinality p. If each runnable

∈ Π

is schedulable by assigning r

to a lower pri-

ority level, where the rest of runnables (∆ − r

) are

assigned a higher priorities level, then all runnables

of Π

could be allocated to the same task.

By Proposition 2, Algorithm 2 ﬁnds the set of

runnables Π

⊆ ∆ which can be allocated to the same

task. Algorithm 2 is based on the feasibility test (9)

used by the Audsley’s algorithm:

∋ t

≤ t ≤ D

(t)

≤ 1 (9)

where,

(t) =

∑

j∈∆−r





(10)

Algorithm 2: Assignment of runnables to tasks.

Data: runnable sets ∆

1 Π

←

0 ;

2 t

←

∑

i∈∆

;

3 for r

in ∆ do

4 t ← t

;

5 continue ← True ;

6 while continue do

7 if



(t)

≤ 1



then

8 if (t ≤ D

) then

9 Π

← r

;

is schedulable */

10 end

11 continue ← False;

12 end

13 t= I

(t) + C

;

14 if (t > D

) then

15 continue ← False ;

is unschedulable */

16 end

17 end

18 end

19 return Π

4.2 Sequencing of Runnables

The second step of Algorithm 1 is described by Algo-

rithm 3 which builds the dispatcher task τ

using the

activation offsets between the runnables of Π

given

by Algorithm 2. For each runnable r

∈ Π

, we have

= T

tic

possibilities to deﬁne the ﬁrst position

of runnable r

, where 0 ≤ δ

≤ γ

− 1. Thus, the

ANovelHeuristicAlgorithmforMappingAUTOSARRunnablestoTasks

243

offset of the runnable r

is θ

= δ

∗ T

tic

, since the

max WCET of slots is lower than T

tic

. Our algo-

rithm adapts the Least Loaded (LL) heuristic devel-

oped by Monot et al in (Monot et al., 2012) so as to

integrate deadlines of runnables. These ones enable

us to ﬁnd the deadline of the task through equation

(4) with max

s=0...N−1

} ≤ D

≤ T

cycle

and the ex-

ecution order of runnables sorted in increasing order

of laxity. Laxity L

= D

− C

represents the maxi-

mum time during which a task can be delayed while

still completing before deadline.

Algorithm 3: Sequencing runnables inside task.

Data: Input : runnable set Π

& j

1 ∧

←

0 ;

2 T

tic

← GCD(Π

) ;

3 l ← 1 ;

/* index of the first runnable */

4 Sort Π

by increased laxity order ;

5 for i ← 1...

6 Look for δ

that represents the least loaded slot in the γ

ﬁrst

slot ;

7 Allocate r

in every γ

slot, starting from this slot δ

;

8 Calculate the vector of WCET C

by the equation (1) ;

9 if max(C

) > T

tic

or max(C

) > D

then

10 Reject the ﬁrst runnable ∧ ← r

;

11 l ← l + 1 ;

12 Update allocation for r

to r

in the slots using lines 7 & 8

;

13 end

14 end

15 Calculate the deadline D

by the equation (4) ;

16 return ∧

& τ

tic

)

5 EXPERIMENTATION

This section presents and discusses several experi-

mental results. Our study has been conducted in order

to evaluate the proposed approach and validate its ef-

ﬁciency. To correctly assess the different methods un-

der different execution scenarios, a set of runnables is

randomly generated according to a realistic distribu-

tion of WCETs and periods for covering typical auto-

motive applications.

5.1 Set Up

A system is characterized by the following parame-

ters: number of runnables n, processor utilization fac-

tor U, conﬁguration number, and deadline intervals.

In order to randomly generate the n runnables, we use

the UUnifast algorithm developed in (Bini and But-

tazzo, 2005). This algorithm distributes the total uti-

lization factor U to smaller utilization factor u

for n

runnables. For each runnable r

, we specify its WCET

by the following equation:

= T

× u

(11)

where T

is the period of the i

runnable randomly

chosen from a set of non-harmonic periods 1, 2, 3, 5,

8, 10, 15, 20, 25, 40, 50, 100, 150, 200, 250, 300, 500,

900, 1000 ms.

Deadline D

of the i

runnable is determined from

the following equation:

= (T

−C

) × rand(a,b) +C

(12)

Where rand(a,b) generates values from the uni-

form distribution on the interval [a, b] with 0 ≤ a ≤ b.

In the case of a=b=1, the deadline is equal to period.

5.2 Results and Discussion

This subsection reports experimental results obtained

by applying our approach using APS and compares it

to both PS and MPS solutions.

Overall, 304 systems have been generated using

the above method and corresponding to 16 cardinal-

ities of period sets and 19 deadline intervals. Each

generated system is composed of 100 runnables that

are generated randomly with a processor utilization

factor ﬁxed to 69%.

Figure 4 shows the evolution of number of schedu-

lable systems according to the range of runnable

deadlines. Using MPS and APS, we obtained 197

schedulable systems for an overall of 304 analyzed

systems. i.e., we have 64.80% of schedulable sys-

tems for both MPS and APS approaches. However,

using PS approach, we obtained 30.26% of schedula-

ble systems. Thus, our approach increases by 34.54%

the system schedulability compared to PS approach.

Moreover, APS outperforms both MPS and PS ap-

proaches regarding the number of tasks and the avear-

age response time as discussed thereafter.

[1,1] [0.8,1] [0.6,1] [0.4,1] [0.2,1] [0.1,0.9][0.1,0.7][0.1,0.5][0.1,0.3][0.1,0.1]

deadline [a,b]

Number of schedulable system

APS

MPS

Figure 4: Number of schedulable systems with PS, MPS

and APS.

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

244

From Figure 4, we could identify three different

zones based on the strictness of the deadline con-

straint: zone A corresponds to a system with slack

constraints of deadline’ interval [1,1] until [0.4,1],

where B corresponds to a system with tight con-

straints of deadline’ interval [0.5,1] until [0.1,0.5],

and zone C corresponds to systems with ﬁrm con-

straints of deadline’ interval [0.1,0.4] until [0.1,0.1].

In the following, we discuss the performance results

obtained by our APS approach for the three zones and

we compare it to PS and MPS. To do that, we deﬁne

for each period cardinality, two performance metrics:

• The maximum number of tasks among all dead-

lines intervals for a given zone,

• The beneﬁt percentage of the average response

time (ART) among deadlines intervals for a given

zone.

Zone A: in this zone, we note that APS approach

reduces by 1 to 16 the total tasks number compared to

PS and by 1 to 3 compared to MPS (see Figure 5(a)).

On the other side, Figure 5(b) shows the relative im-

provement (in beneﬁt %) of APS approach regarding

the average response time (ART). This improvement

increases with period cardinality.

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Cardinality of period sets

Maximum number of tasks

(a) Maximum number of task among all deadlines’ interval

APS

MPS

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Cardinality of period sets

Benefit in [%]

(b) Benefit percentage of avreage response time (ART)

Benefit APS/MPS

Benefit APS/PS

Figure 5: Performance results for zone A.

Zone B: in this part, the PS approach is unschedu-

lable and thus it is excluded from comparisons. Fig-

ure 6(a) shows the evaluation of the number of tasks.

We note that APS approach reduces by 3 to 9 the tasks

number compared to MPS. Moreover, APS approach

outperforms MPS approach regarding the improve-

ment (in beneﬁt %) of average response time (see Fig-

ure 6(b)).

Zone C: in this part, there is no system that can be

schedulable by any approach due to the tight deadline

constraints.

6 CONCLUSION

In the AUTOSAR software design methodology,

mapping runnables of software components to OS

tasks represents a central design decision. This may

impact system performance, real-time schedulability

and execution determinism of the application. Several

approaches have been proposed to solve this design

issue, ranging from the simplest solution that map to-

gether runnables with same periods (PS) or multiple

periods (MPS) to the same task, up to a more ad-

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Cardinality of period sets

Maximum number of tasks

(a) Maximum number of task among all deadlines’ interval

APS

MPS

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Cardinality of period sets

Benefit in [%]

(b) Benefit percentage of avreage response time (ART)

Benefit APS/MPS

Figure 6: Performance results for zone B.

ANovelHeuristicAlgorithmforMappingAUTOSARRunnablestoTasks

245

vanced solution based on task sequencer with arbi-

trary periods (APS). However, to our knowledge no

efﬁcient solution has been proposed to optimize both

the number of tasks and system schedulability.

In this paper, a novel method has been proposed

for mapping runnables to tasks based upon the APS

approach. This method uses the activation offset

property of runnables in order to minimize the re-

sulting number of tasks. Experimental results show

that the number of tasks is reduced signiﬁcantly. Fur-

thermore, our method increases by 34% the system

schedulability bound in comparison to PS approach.

It can be outlined that the PS approach exhibits a

better performance in terms of system response time

compared to the MPS approach but this is in the

detriment of the tasks number. Simulations demon-

strate that our APS approach outperforms both PS and

MPS ones regarding both the number of tasks and

the system response time. We aim also to investi-

gate the experiments setup by extending it to cover

more complex system conﬁguration. In particular,

we would like to measure the performance of our ap-

proach when varying both utilization factor and tasks

deadline. Further, a work in progress has been started

to test our approach on a real board (NEC V850) with

AUTOSAR 3.2. The preliminary obtained results are

satisfactory but have to be also investigated to cover

more system conﬁguration.

Precedence and shared resources constraints will

be also considered in the ongoing work. Finally, we

plan to apply this heuristic to multi-cores architec-

tures in a short future.

REFERENCES

Audsley, N. (1991). Optimal Priority Assignment and Fea-

sibility of Static Priority Tasks with Arbitrary Start

Times. Technical report. University of York, Depart-

ment of Computer Science.

Bini, E. and Buttazzo, G. C. (2005). Measuring the per-

formance of schedulability tests. Real-Time Systems,

30(1-2):129–154.

Haibo, Z. and Di Natale, M. Efﬁcient implementation of

autosar components with minimal memory usage. In

Industrial Embedded Systems (SIES), 2012 7th IEEE

International Symposium on, pages 130–137.

Liu, C. L. and Layland, J. W. (1973). Scheduling algo-

rithms for multiprogramming in a hard-real-time en-

vironment. Journal of the ACM (JACM), 20(1):46–61.

Ming, Z. and Zonghua, G. Optimization issues in mapping

autosar components to distributed multithreaded im-

plementations. In Rapid System Prototyping (RSP),

2011 22nd IEEE International Symposium on, pages

23–29.

Monot, A., Navet, N., Bavoux, B., and Simonot-Lion, F.

(2012). Multisource software on multicore automo-

tive ecus: Combining runnable sequencing with task

scheduling. Industrial Electronics, IEEE Transactions

on, 59(10):3934–3942.

Navet, N., Monot, A., Bavoux, B., and Simonot-Lion, F.

(2010). Multi-source and multicore automotive ecus

- os protection mechanisms and scheduling. In In-

dustrial Electronics (ISIE), 2010 IEEE International

Symposium on, pages 3734–3741.

Partnership, A. (2011). Technical overview.

http://www.autosar.org/, V2.2.2 R3.2 Rev 1.

Rongshen, L., Hong, L., Wei, P., Yi, Z., and Minde, Z. An

approach to optimize intra-ecu communication based

on mapping of autosar runnable entities. In Embedded

Software and Systems, 2009. ICESS ’09. International

Conference on, pages 138–143.

Wozniak, E., Mehiaoui, A., Mraidha, C., Piergiovanni,

S. T., and Gerard, S. (2013). An optimization ap-

proach for the synthesis of AUTOSAR architectures.

In Proceedings of 2013 IEEE 18th Conference on

Emerging Technologies & Factory Automation, ETFA

2013, Cagliari, Italy, September 10-13, 2013, pages

1–10.

Zeng, H., Di Natale, M., and Zhu, Q. (2012). Optimiz-

ing stack memory requirements for real-time embed-

ded applications. In Emerging Technologies & Fac-

tory Automation (ETFA), 2012 IEEE 17th Conference

on, pages 1–8. IEEE.

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

246