IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
375
A Synchronization Protocol for Temporal Isolation of
Software Components in Vehicular Systems
Thomas Nolte, Member, IEEE, Insik Shin, Member, IEEE, Moris Behnam, Student Member, IEEE, and
Mikael Sjödin
Abstract—We present a method that allows for integration of
individually developed functions of software components into a
predictable real-time system. The method has been designed to
provide a lightweight mechanism that gives temporal firewalls
between functions, preventing unpredictable side effects during
function integration. The method maps well to the AUTOSAR
(AUTomotive Open System ARchitecture) software component
model and can thus be used to facilitate seamless and predictable
integration and isolation of AUTOSAR components that have
been developed by different manufacturers.
Specifically, this paper presents a protocol for synchronization in
a hierarchical real-time scheduling framework. Using our protocol,
a software component does not need to know, and is not dependent
on, the timing behavior of software components belonging to other
functions; even though they share mutually exclusive resources. In
this paper, we also prove the correctness of our approach and evaluate its efficiency and cost in terms of system load in a vehicular
context.
Index Terms—Automotive, automotive open system architecture
(AUTOSAR), hierarchical scheduling, operating system, real-time
systems, scheduling, subsystem integration and resource allocation
policy (SIRAP), synchronization.
I. INTRODUCTION
T
HIS paper presents methods and analysis techniques that
allow integration of multiple, semi-independent, software
components, preserving their real-time properties, onto a single
CPU. The proposed methodology maps well to the industrial
standard (automotive open system architecture’s) AUTOSAR’s
software component model. Thus, the proposed methodology
can substantially aid in decreasing integration costs and effort
for automotive software functions.
Integration of the many functions present in a modern vehicle is a daunting task. Contemporary integration techniques
are mostly bus-oriented, in the sense that integration of software
Manuscript received April 05, 2009; revised July 05, 2009 and September
02, 2009; accepted September 03, 2009. First published October 13, 2009; current version published November 06, 2009. This work was supported in part
by the Swedish Foundation for Strategic Research (SSF) via the Research Program PROGRESS, IT R&D Program of MKE/KEIT of Korea [2009-F-039-01],
the National Research Foundation of Korea (2009-0086964), and KAIST ICC,
KIDCS, KMCC, and OLEV grants. This paper was presented in part at the Seventh ACM and IEEE International Conference on Embedded Software (EMSOFT’07), Salzburg, Austria. Paper no. TII-09-04-0046.R2.
T. Nolte, M. Behnam, and M. Sjödin are with the MRTC/Mälardalen
University, Västerås SE-72123 Sweden (e-mail: [email protected];
[email protected]; [email protected]).
I. Shin is with the Department of Computer Science, Korea Advanced Institute of Science and Technology (KAIST), Daejeon, Korea 305-701 (e-mail:
[email protected]).
Digital Object Identifier 10.1109/TII.2009.2033267
from different vendors is done over a shared communications
bus. Typically, each electronic control unit (ECU, i.e., a node
in the vehicular network) is developed in isolation by some supplier, and is, at late stages of the vehicle development, integrated
with other ECUs provided by (potentially) other suppliers. The
ECUs, and thereby the functions, communicate via messages
over the communications busses in the vehicle.
This approach to integration has been developed for good
reasons (beyond the scope of this paper to account for), but
has today reached its limits. The major drawback of the approach is the bloat in number of ECUs caused. Since a large
amount of functions is to be realized by a high number of suppliers the number of ECUs in a vehicle has grown tremendously
over the last decade. Top-line cars today can have close to 100
ECUs connected over a handful of busses. Needless to say, the
sheer number of ECUs and networks causes significant problems, including manufacturing costs, weight, increased power
consumption, and decreased reliability and serviceability.
To combat the limitations of this integration technique, the
automotive industry has developed the standard AUTOSAR [2].
AUTOSAR allows specification of components that implement
complex, potentially distributed, functions in a vehicle. Components have formally defined interfaces, and thus functional
integration of components is functionally predictable. Components contain compositions of software components, which are
atomic (i.e., not distributed) pieces of functionality, that can be
deployed to the physical nodes in the vehicle system. Components and software components allow for vehicle manufacturers
to structure the functions of a vehicle and to partition the labor
required to implement the functions.
However, vehicle functions are often real-time functions,
meaning that their correct behavior is not only dependent on
their functional correctness but also their temporal correctness.
That is, the right values (or right actions) have to be delivered
(taken) at the right time.
In AUTOSAR, functions are developed and constructed using
software components. These components are then, in turn, executed as tasks, predictably scheduled by the AUTOSAR OS
task scheduler. However, in guaranteeing that timing requirements of functions (and thereby also software components) is
met, complete knowledge of an ECU’s all task properties is required. Complete knowledge is not possible to achieve without
having all functions at hand, including specification of their
detailed internal composition of software components, when
performing real-time analysis (schedulability testing). This requirement may lead to unexpected problems when integrating
multiple functions on a single ECU. Functions that work well
when executed on an exclusive ECU (alone) may work incorrectly when they have to share an ECU with other functions. In
1551-3203/$26.00 © 2009 IEEE
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
376
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
fact, the timing behavior of a software function may change in
unpredictable ways when adding or removing any other software component to/from an ECU. This may, in turn, lead to
time consuming and costly error tracing during the integration
phase. Since the integration phase occurs late in the development process for a vehicle, any disturbances and delays in this
phase may be very costly, e.g., in delayed time to market for the
product or in delays in production lines.
To remedy late integration problems, we propose the use of
server-based scheduling techniques in AUTOSAR. The servertechnology is provided by a Hierarchical Scheduling Framework
(HSF), implemented as a layer between the AUTOSAR OS and
the AUTOSAR Runtime Environment (RTE).1 A server is an
operating-system level object that is allocated a fraction of the
total CPU-capacity. By allocating a software component (or set
of components) to one server the function is guaranteed its allocated share of computing resources, regardless the computational need of any other functions in the system. Using servers,
functions’ computational resource will not change when other
components or functions are added or removed from the system.
Thus, servers provide “temporal firewalls” between functions of
components and in this way allows the temporal behavior of a
software function to be preserved regardless of the context it is
integrated in.
In order to use server-based scheduling for AUTOSAR software components the server-technology needs to support:
• Fixed-Priority Scheduling (FPS) of tasks. Software components are executed as OSEK-tasks [3], and OSEK-tasks
are scheduled with the FPS discipline.
• Resource-sharing between servers. Since the functions in
different servers are only semi-independent,2 they may
share resources. Thus, the server-technology must gracefully handle cases when one server holds a resource lock
while its allocated time is expired.
• Independency between timing-parameters. That is, the parameters of one server should not be dependent on the
parameters, or behavior, of other servers in the system.
Specifically, with respect to resource sharing, the parameters of a server should not be dependent on the resource
holding time of components in other servers.
In this paper, we present a server-technology that supports
the above requirements. Thus, it facilitates independent development and testing of AUTOSAR software functions and
late-stage timely integration of multiple software functions on
a single ECU.
Problem Description: A vehicle ECU (system) consists
of one or more servers to be executed on one single processor.
, in turn, is hosting functionality constructed
Each server
from one or more software components; each software component containing a set of tasks. Functions can be developed independently and they have their own local scheduler (resident in
the server, scheduling the tasks of the software components in
the function). This approach by isolation of tasks and software
1AUTOSAR allows for the inclusion of proprietary OSs, as long as they can
be abstracted to an AUTOSAR OS.
2The notion of semi-independent components means that they are intended
to be independent, but for various reasons they are required to synchronize
on common shared global resources. This synchronization introduces a dependency between the independent components, thereby classifying them as semiindependent.
components within functions, and allowing for their own local
scheduler, has several advantages [4]. For example, by keeping
a function isolated from other functions, and by having a server
local (exclusive) scheduler, it is possible to reuse a complete
function in a different vehicle ECU from where it was originally developed.
However, as functions are likely to share logical resources
(such as message queues, shared variables, or the AUTOSAR
Virtual Function Bus), an appropriate synchronization protocol
must be used. For a function developer, in facilitating independent function development, using this protocol should not require information from other functions in the system. It should
be enough with only the information regarding the functions
under development in isolation.
Hence, the first challenge addressed in this paper is inherent
in the development of a synchronization protocol. Then, the
second challenge is to derive appropriate timing abstractions
and analysis to allow for independent development and validation of functions.
Contributions: The contribution of this paper is threefold.
• The presentation of SIRAP, a pragmatic approach to software-component integration in the AUTOSAR architecture. SIRAP was originally presented in [1], and in this
paper SIRAP has been tailored to operate in the context
of an AUTOSAR (OSEK) compliant environment.
• The deduction of bounds on the timing behavior of SIRAP.
• The cost of using SIRAP is evaluated in a vehicular setting.
Specifically, the cost is investigated as a function of various
parameters including: cost as a function of the length of
critical sections, cost depending on the priority of the task
sharing a resource, and cost depending on the periodicity
of the function’s server.
Organization of this Paper: Section II presents related
work on server-based scheduling, hierarchical scheduling and
synchronization. Then, the system model used throughout
this paper is presented in Section III. SIRAP is presented in
Section IV. In Section V, schedulability analysis is presented,
and SIRAP is evaluated in Section VI. Finally, this paper is
summarized in Section VII.
II. RELATED WORK
This section presents related work in the areas of server-based
scheduling, HSFs as well as synchronization protocols.
A. Server-Based Scheduling
A number of server-based schedulers have been developed
for FPS systems, with the simplest one being the Polling Server
(PS) [5], [6]. A PS allocates a share of the CPU to the tasks using
(resident in) the server. This share is defined by the server’s
period and capacity. A server mediates the right to execute for
its tasks, if some of them have requested to use the server’s
capacity. Otherwise, the server’s capacity will be left unused
for that server period.
Other server-based schedulers for FPS systems include the
Deferrable Server (DS) [5], [7] and the Sporadic Server (SS)
[6]. The difference between PS, DS, and SS is that the latter
two preserve their capacity and they give better response times
when serving single requests.
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
NOLTE et al.: A SYNCHRONIZATION PROTOCOL FOR TEMPORAL ISOLATION OF SOFTWARE COMPONENTS IN VEHICULAR SYSTEMS
The server-based scheduler used in this paper is a variant of
the PS which does not release all server capacity in case no
server-internal tasks are ready to execute once the PS becomes
scheduled for execution. Instead, if no server-internal task is
ready to execute, the PS is using its capacity to either execute
other non real-time tasks, e.g., background scheduling, or, if
no such tasks are available for execution, the server will consume its capacity being busy-idle. In this way, the PS will be
able to serve server-internal tasks that become activated at any
time within the server period as long as there still remains some
unused server capacity. This approach is chosen due to its efficiency in a hierarchical setting, and it has a low implementation
complexity.
B. Hierarchical Scheduling
The HSF for real-time systems, originating in open environments [8] in the late 1990s, has been receiving an increasing research attention. Since Deng and Liu [8] introduced a two-level
HSF, its schedulability has been analyzed under fixed-priority
global scheduling [9] and under Earliest Deadline First (EDF)based global scheduling [10]. Mok et al. [11], [12] proposed
the bounded-delay virtual processor model to achieve a clean
separation in a multilevel HSF. In addition, Shin and Lee [13]
introduced the periodic virtual processor model (to characterize
the periodic CPU allocation behavior), and many studies have
been proposed on schedulability analysis with this model under
fixed-priority scheduling [14]–[16] and under EDF scheduling
[13], [17]. More recently, Easwaran et al. [18] introduced Explicit Deadline Periodic (EDP) virtual processor model. However, a common assumption shared by all above studies is that
tasks are independent.
C. Synchronization
Many synchronization protocols have been introduced for arbitrating accesses to shared logical resources addressing the priority inversion problem, including Priority Inheritance Protocol
(PIP) [19], Priority Ceiling Protocol (PCP) [20], and Stack Resource Policy (SRP) [21].
When using SRP, a task may not preempt any other tasks
until its priority is the highest among all tasks that are ready to
run, and its preemption level is higher than the system ceiling.
The preemption level of a task is a static parameter assigned
to the task at its creation, and associated with all instances of
that task. A task can only preempt another task if its preemption
level is higher than the task that it is to preempt. Each resource
in the system is associated with a resource ceiling and based
on these resource ceilings, a system ceiling can be calculated.
The system ceiling is a dynamic parameter that changes during
system execution.
There have been studies on supporting resource sharing
within servers [9], [14] in HSFs. For supporting global resource
sharing across servers, some protocols [22], [23] have been
proposed. The Hierarchical Stack Resource Policy (HSRP)
[22] extends SRP for global resource sharing on the basis of
an overrun mechanism. The Bandwidth Inheritance Protocol
(BWI) [24] and the Bounded-Delay Resource Open Environment (BROE) [23] both extend the Constant Bandwidth Server
(CBS) [25] to support global resource sharing on the basis of
377
PIP and SRP, respectively. While BWI and BROE are applicable only to systems with EDF global scheduling, HSRP and
our proposed protocol SIRAP can also be applied to systems
with FPS global scheduling, which is much more commonly
used in vehicular systems. For a comparison of BROE, HSRP
and SIRAP, interested readers are referred to [26].
The main difference between these protocols is how they
prevent expiration of the server budget while locking a global
shared resource, to bound the waiting time of tasks from different servers that want to access the same shared resource.
Looking at the context of vehicular systems, HSRP and SIRAP
are interesting due to their applicability for FPS scheduled systems. Here, solving the problem of budget expiry inside a critical section is based on one of, or a combination of, the two approaches: A) The overrun mechanism—adding extra resources
to the budget of each server to prevent the budget expiration
inside a critical section (applied by HSRP). B) The skipping
mechanism—preventing a task from locking a shared resource
by skipping its execution if its server does not have enough remaining budget at the time when the task tries to lock the resource (applied by SIRAP).
HSRP is based on an overrun mechanism which extends the
SRP protocol to be appropriate for HSFs with tasks that access
globally shared logical resources. HSRP works as follows: when
the budget of a server expires and the server has a task that is still
locking a global shared resource, the task continues its execution
until it releases the locked resource. When a task is accessing
a global shared resource its priority is increased to the highest
local priority, preventing any preemption during the access of a
shared resource from other tasks that belong to the same server.
SRP is used at the global level to synchronize the execution of
servers that have tasks accessing global shared resources. Each
global shared resource has a ceiling equal to the maximum priority of servers that have a task accessing that resource. Two versions of overrun mechanisms have been presented; 1) In the first
version (with payback): whenever overrun happens in a server,
the budget of the server will, in its next execution instant, be
decreased by the amount of the overrun time. 2) In the second
version (without payback), no further actions will be taken after
the event of an overrun. Selecting which of these two mechanisms that gives better results in terms of task response times in
the general case is not decidable, as it depends on the particular
system parameters.
SIRAP is based on the skipping mechanism. The protocol
supports server integration in the presence of globally shared
logical resources, and SIRAP can be used in open environment
systems (i.e., independent development of servers). It uses a
periodic resource model to abstract the timing requirements of
each server. Each server is characterized by its period, budget
and resource holding time, and it is implemented as a variant of
the PS (a periodic server). SIRAP uses the SRP protocol to synchronize the access to global shared resources in both local and
global scheduling. SIRAP applies a skipping approach to prevent the budget expiration inside critical section problem. The
mechanism works as follows; when a job wants to enter a critical section, it enters the critical section at the earliest instant
such that it can complete the critical section execution before the
server budget expires. This can be achieved by checking the remaining budget before granting the access to the globally shared
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
378
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
system that has a different global level scheduler for scheduling
servers.
B. Shared Resources
Fig. 1. System model: Two-level HSF with global resource sharing
requirements.
resources; if there is sufficient remaining budget then the job
enters the critical section, and if there is insufficient remaining
budget, the local scheduler delays the critical section entering of
the job until the next server budget replenishment (i.e., the task
that wants to enter the critical section will be blocked internally
inside its server until the next server budget replenishment).
Due to its applicability in open systems, where functions may
be developed independently and in parallel, SIRAP, among the
above, is the more applicable approach to enable synchronization between software components resident in different functions. The details of SIRAP are presented in Section IV.
III. SYSTEM MODEL
A. Hierarchical Scheduling Framework (HSF)
A HSF has been introduced to support CPU time sharing
among functions (servers) under different scheduling services.
In this paper we propose the use of a HSF to support time
sharing between, and with SIRAP seamless integration of, AUTOSAR software-components. Here, a system consists of one
. The HSF can be generally represented
or more servers
as a two-level tree, where each child node represents a server
with (potentially) its own local scheduler for scheduling internal
tasks, and CPU time is allocated from the parent node to the
child nodes (i.e. from the global scheduler to the servers), as illustrated in Fig. 1.
The HSF provides partitioning of the CPU between different
servers. Thus, servers, and thereby components, can be isolated
from each other for, e.g., fault containment, compositional verification, validation and certification and unit testing.
The HSF is especially useful in the domain of open environments [8], where functions may be developed and validated independently in different environments, which is typical in the
automotive domain. For example, the HSF allows a function
to be developed with its own scheduling algorithm internal to
the server containing the function, and then later included in a
A critical section is a piece of code that accesses a shared
resource in a mutually exclusive manner. That is, the critical
section should be accessed by at most one task at any time. In
general, a task first obtains a lock (e.g., semaphore) in order to
access a shared resource, and it release the lock later when it
finishes its access to the resource.
A shared resource is said to be local if it is accessed by
the tasks within a single server, or global if it is accessed by
tasks across servers (as depicted in Fig. 1). Management of
local shared resources can be done by the use of traditional synchronization protocols such as PIP, PCP, and SRP, and therefore this paper focuses on the management of global shared resources. Hereinafter, we simply refer to global shared resources
as shared resources.
C. Virtual Processor Model
The notion of real-time virtual processor (resource) model
was first introduced by Mok et al. [11] to characterize the CPU
allocations that a parent node provides to a child node in a
HSF. The CPU supply of a virtual processor model refers to the
amounts of CPU allocations that the virtual processor model can
provide. The supply bound function of a virtual processor model
calculates the minimum possible CPU supply of the virtual processor model for a time interval length .
Shin and Lee [13] proposed the periodic virtual processor
, where is a period
and is a pemodel
. The capacity
of a periodic allocation time
is defined as
. The
riodic virtual processor model
is defined to characperiodic virtual processor model
terize the following property:
(1)
computes the
where the supply function
amount of CPU allocations that the virtual processor model
provides during the interval
.
, its supply bound function
For the periodic model
is defined to compute the minimum possible CPU
supply for every interval of length as shown in the equation at
.
the bottom of the page, where
Here, we first note that an interval of length may not begin
synchronously with the beginning of period . That is, as
shown in Fig. 2, the interval of length can start in the middle
. We also note that
of the period of a periodic model
the intuition of in (2) basically indicates how many periods
of a periodic model can overlap the interval of length , more
. Fig. 2
precisely speaking, the interval of length
if
otherwise
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
(2)
NOLTE et al.: A SYNCHRONIZATION PROTOCOL FOR TEMPORAL ISOLATION OF SOFTWARE COMPONENTS IN VEHICULAR SYSTEMS
379
Fig. 3. Shared resource access time.
Fig. 2. The supply bound function of a periodic virtual processor model
0(5; 2) for k = 3.
illustrates the intuition of
is defined for
and how the supply bound function
.
D. Server Model
, where is the whole system of servers, conA server
sists of a function and a scheduler. The scheduler in the server
schedules the tasks contained in the software components of the
is
server’s function (as illustrated in Fig. 1). Each server
associated with a periodic virtual processor model abstraction
, where
and
are the server period and budget,
is supposed to specify
respectively. This abstraction
the collective temporal requirements of a server, in the presence
of global resource sharing.
For each server, we assume that the server period is selected
, where
is the task with the shortest
such that
will
period. The motivation for this assumption is that higher
require more CPU resources [27]. In addition, this assumption
).
simplifies the presentation of the paper (evaluating
Task Model: We consider a periodic task model
, where and
represent the task’s period and
is
Worst-Case Execution Time (WCET), respectively, and
the set of WCETs within critical sections belonging to . Each
element
in
represents the WCET of a particular critical
includes all
.
section executed by . Note that
The set of critical sections cover for the following two cases
of multiple critical sections within one task:
contains the
1) sequential critical sections, where
WCETs of all sequential critical sections, i.e.,
, where
is the number of sequential
shared resources that task may lock during its execution;
being the length
2) nested critical sections, where
of the outer critical section.
rather than
Note that in the remaining paper, we use
for simplicity when it is not necessary to indicate .
Scheduler: In this paper we deal with vehicular applications
which are commonly developed for OSEK compatible operating
systems. Hence, we assume that each server has a FPS preemptive scheduler for scheduling its internal tasks. We also assume
that the system has the FPS global scheduler to schedule servers.
IV. THE SIRAP PROTOCOL
The subject of this paper is to develop a synchronization protocol that can address global resource sharing in hierarchical
real-time scheduling frameworks, while aiming at supporting
independent server development and validation. This section describes our proposed synchronization protocol, SIRAP.
A. Terminology
Before describing the SIRAP protocol, we define the terminology (also depicted in Fig. 3) that are related to hierarchical
resource sharing.
• Semaphore request instant: an instant at which a task tries
to enter a critical section guarded by a semaphore.
• Critical section entering (exiting) instant: an instant at
which a task enters (exits) a critical section.
• Waiting time: a duration from a semaphore request time to
a critical section entering time.
• Resource holding time: a duration from a critical section
entering instant to a critical section exiting instant. Let
denote the resource holding time of a critical section of task
.
• (Shared) resource access time: a duration from a
semaphore request instant to a critical section exiting
time.
In addition, a context switch is referred to as task-level context
switch if it happens between tasks within a server, or as serverlevel context switch if it happens between servers.
B. SIRAP Protocol Description
This section presents the description of our proposed SIRAP
protocol.
Assumption: SIRAP relies on the following assumption.
• The system’s global scheduler schedules servers ac.
cording to their periodic server parameters
The server budget is consumed every time when an internal task within a server executes, and the budget is
every server period
. Similar to trareplenished to
ditional server-based scheduling methods [28], the system
provides a runtime mechanism such that each server is
able to figure out at any time how much its remaining
server budget
is, which will be denoted as
in the
remaining of this section.
The above assumption is necessary to allow runtime checking
whether or not a task can potentially enter and execute a whole
critical section before its server’s budget expires. This is useful
particularly for supporting independent abstraction of server’s
temporal behavior in the presence of global resource accesses.
In addition to supporting independent server development,
SIRAP also aims at minimizing the resource holding time and
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
380
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
bounding the waiting time at the same time. To achieve this goal,
the protocol has two key rules as follows.
R1: When a task enters a critical section, preemptions from
other tasks within the same server should be bounded to
keep its resource holding time as small as possible.
R2: When a task wants to enter a critical section, it enters
the critical section at the earliest instant such that it can
complete the critical section before its server’s budget expires. Hence, a task can only enter the critical section if it
can complete that critical section before the server’s budget
expires. Otherwise, it will enter the critical section once the
server’s capacity is replenished.
The first rule R1 aims at minimizing a resource holding time
so that the waiting time of other tasks, which want to lock the
same resource, can be minimized as well. The second rule R2
from entering a critical section
at any
prevents a task
. This rule guarantees that when the
time when
budget of a server expires, no task within the server locks a
global shared resource.
SIRAP: Preemption Management: SRP [21] is used to
enforce the first rule R1. Each server will have its own system
ceiling and resource ceiling according to its tasks that share
global resources. According to SRP, whenever a task locks
a resource, other tasks within the same server can preempt
it if the tasks have higher preemption levels than the locked
resource ceiling, so as to bound the blocking time of higher
priority tasks. However, such task-level preemptions generally
increase resource holding times and can potentially increase
is to allow
server utilization. One approach to minimize
no task-level preemptions, by assigning the ceiling of global
resource equal to the maximum preemption level. However,
increasing the resource ceiling to the maximum preemption
level may affect the schedulability of a server. A good approach
is presented in [29], which increases the ceiling of shared global
resources as much as possible while keeping the schedulability
of the server.
SIRAP: Self-Blocking: When a task tries to enter a critical
section, SIRAP requires each local scheduler to perform the following action. Let denote the semaphore request instant of
and
denote the server’s budget at time .
, the local scheduler executes the task .
• If
The task enters a critical section at time .
, the local scheduler de• Otherwise, i.e., if
lays the critical section entering of the task
until the
next server budget replenishment. This is defined as selfblocking. Note that the system ceiling will be equal to resource ceiling at time , which means that only the tasks
that have preemption level greater than system ceiling can
execute during the self blocking interval. This guarantees
that when the server of receives the next resource allocation, the server-budget will be enough to execute task
inside the critical section.
V. SCHEDULABILITY ANALYSIS
In this section, two schedulability tests are presented for local
and global scheduling, respectively. It should be noted that it
is possible that the worst-case scenario used as basis for these
tests does not necessarily correspond to a feasible execution of
a real-system. However, at the cost of being pessimistic, both
tests are sufficient schedulability tests.
A. Local Schedulability Analysis
that consists of a periodic task set and
Consider a server
a fixed-priority scheduler and receives CPU allocations from
. According to [13], this
a virtual processor model
server is schedulable if
(3)
where
represents the minimum CPU allocation that
a task requires during an interval of length , in order to satisfy its timing constraints in the presence of interference from
its higher priority tasks. Typically, however, for each task , it
is sufficient to investigate a limited number of points in the in[30].
terval
The goal of this section is to develop the demand bound funccalculation for the SIRAP protocol. We can
tion
with the following factors:
compute
(4)
is the maximum self blocking
where is the WCET of ,
for ,
is the maximum possible interference imposed
by a set of higher priority tasks to a task during an interval
is the maximum possible interference imof length , and
posed by a set of lower priority tasks that share resources with
preemption level (ceiling) greater than or equal to the priority
of task .
The following lemmas shows some intuitions behind how to
,
and
.
compute
Lemma 1: Self-blocking imposes to a task an extra proif a task access multiple
cessor demand of at most
shared resources.
Proof: When the task self-blocks itself, it consumes the
units being idle. If the task access
processor of at most
shared resources then the worst case will happen when the task
block itself whenever it tries to enter a critical section.
Lemma 2: A task can be interfered by a higher priority task
that access shared resources, at time units for a duration of
time units.
at most
Proof: Similar to classical response-time analysis [31], we
to
which is the worst-case self blocking from
add
higher priority tasks, the lemma follows.
Lemma 3: A task can be interfered by only one lower pri, where
.
ority task by at most
Proof: A higher priority task can be interfered by a lower
priority task . This occurs only if is released after tries
to enter a critical section but before exits the critical section.
When is released, only one task can try to enter or be inside
a critical section. That is, a higher priority task can then be
interfered by at most a single lower priority task. The processor
demand of during a critical section period is bounded by
for the worst case, where one
is due to
is due to the execution of
self blocking and the other
the critical section. The lemma follows.
From Lemma 1, the self-blocking
is given by
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
(5)
NOLTE et al.: A SYNCHRONIZATION PROTOCOL FOR TEMPORAL ISOLATION OF SOFTWARE COMPONENTS IN VEHICULAR SYSTEMS
According to Lemma 2, and taking into account the interferis computed as follows:
ence from higher priority tasks,
(6)
hp
is the set of task with priority higher than that of
where
task .
The maximum interference from lower priority tasks can be
evaluated according to Lemma 3 according to
(7)
lp
is the set of task with priority lower than that of
where
task .
Based on (5)–(7), the processor demand bound function is
given by (4).
of a task that access a global
The resource holding time
resource is evaluated as the maximum critical section execution
time
from the tasks that have
preemption level greater than the ceiling of the logical resource
. Since we assume that
,
during the execution
then all tasks that are allowed to preempt while accesses a
will be activated at most one time from the
shared resource
time that self blocking happens until the end of the next subcan be computed as follows:
system period. Then,
(8)
hp
381
to the maximum preemption level among all servers. Then, for
the global scheduling, it is enough to provide periodic server paand the maximum resource holding times
rameters
for
among all global resources
each server , i.e., it is possible to develop and verify each function (server or set of servers) in isolation and then at integration
stage only provide these high level parameters for the global
schedulability test. On the other hand, assigning the ceiling of
all global resources to the maximum preemption level of the
server that access these resources is not as efficient as using the
original SRP protocol, since we may have resources with lower
ceiling which permit more preemptions from the higher preemption level servers.
Under global FPS scheduling, we present the server load
bound function as follows:
(9)
where
(10)
HPS
where
is the set of servers with priority higher than that
of server . Let
denote the maximum blocking imposed to
a server , when it is blocked by lower priority servers
(11)
is the set of servers with priority lower than that
where
of server .
A global schedulability condition under FPS is then
where
is the ceiling of the shared resource accessed
, and is the maximum ceiling
within the critical section
within the server.
(12)
C. Local Resource Sharing
B. Global Schedulability Analysis
Here, issues for global scheduling of multiple servers are
dealt with. For a server , it is possible to derive a periodic
that guarantees the scheduvirtual processor model
according to (3). Then, the server
lability of the server
uses
as its periodic server parameters.
The requirements for the global scheduler, are as follows: i)
it should schedule all servers according to their periodic server
and ii) it should be able to bound the
parameters
waiting time of a task in any server that wants to access global
resource.
To achieve those global scheduling requirements, a suitable
solution is the usage of a preemptive FPS scheduler together
with Rate Monotonic (RM) priority assignment and the usage
of SRP [21] to resolve synchronization issues. So when a server
locks a global resource, it will not be preempted by other servers
that have preemption level less than or equal to the locked resource ceiling. Each server, for all global resources accessed by
tasks within a server, should specify a list of pairs of all those
global resources and their maximum resource holding times
, where is the number of global resources in the system. However, it is possible to minimize the
required information that should be provided for each server by
assuming that all global resources have the same ceiling equal
So far, only the problem of sharing global resources between
servers has been considered. However, many real-time applications may have local resource sharing within a server as well.
Almeida and Pedreiras [14] showed that some traditional synchronization protocols such as PCP and SRP can be used for
supporting local resource sharing in a hierarchical scheduling
framework by including the effect of local resource sharing in
. That is, to combine SRP/PCP and
the calculation of
the SIRAP protocol for synchronizing both local and global resources sharing, (7) should be modified to
lp
(13)
where is the maximum duration for which a task can be
blocked by its lower priority tasks in critical sections from local
resource sharing.
VI. PROTOCOL EVALUATION
In this section, the cost of using SIRAP is investigated in
terms of extra CPU utilization required to guarantee server
schedulability. Supporting global resource sharing is expected
depends
to increase server utilizations . This increment in
on many factors such as the maximum WCET within a critical
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
382
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
For the remaining figures [Fig. 5(a) and (b)], simulations are
performed as follows. We randomly generate 100 task sets,3
each containing five tasks. Each task set has a utilization of 25%,
and the period of the generated tasks range from 40 to 1000. For
each task set, a single task is accessing a global shared resource,
and its priority is either the highest, a medium, or the lowest. For
each task set, we use 11 different values of ranging from 10%
to 50% of the server period.
B. Impact of the Task Priority
Fig. 4. Server utilization (U ) as a function of the length of the critical section
x for two different task sets.
section
, the priority of the task sharing a global resource,
. Note that, to limit the number of
and the server period
parameters to study, we will in the evaluation generate systems
such that all global resource ceilings are equal to the maximum preemption level, which means that no tasks within a
server preempt a task inside a critical section, and therefore
. The reason for this simplifying assumption is that
the feature of allowing preemption inside critical sections is out
of the scope of this paper. Rather, we are interested in the cost
of the protocol, while varying a number of protocol and system
parameters. The assumption clarifies the experiments and their
interpretations in this section.
Sections VI-A–VI-C investigate the effect of those factors
under the assumption that task accesses a single critical section. In Section VI-D, the assumption of single critical section
access is relaxed in investigating the effect of the number of critical sections on the demand bound function. In Section VI-E, the
SIRAP protocol is evaluated using the notion of system load.
Finally, Section VI-F illustrates SIRAP applied in a realistic vehicular example.
A. Impact of the Length of Critical Sections
One of the main factors that affect the cost of using SIRAP
, i.e., the length of critical sections. It is clear
is the value of
(which equals to
) increases,
from (5)–(7) that whenever
will increase as well, potentially causing
to increase
in order to satisfy the condition in (3). Fig. 4 shows the effect of
increasing on two different task sets, where only their lowest
priority tasks access a shared resource, respectively. Each task
set contain five tasks, and their task utilization is 0.25. Task set 1
has its subsystem period set to 40, and a minimum task period of
50. Task set 2 has its subsystem period set to 40, and a minimum
task period of 180. Task set 1 is sensitive for small changes in ,
while task set 2 can tolerate the given range of without ending
up with a big change in . The reason behind the difference is
while the
that task set 1 has a task with period very close to
by more than
smallest task period in task set 2 is greater than
four times. Hence, SIRAP can be more or less sensitive to
depending on the ratio between task and server period. A good
rule of thumb is to set the server period no greater than half of
the task period of the server’s tasks.
From (5)–(7), looking how tasks sharing global logical resources affect the calculations of
, it is clear that task priority for these tasks is of importance. The contribution of low
is fixed to a specific value of [see (7)],
priority tasks on
while the increase in
by higher priority tasks depends on
many terms such as higher priority task period and execution
[see (6)]. It is fairly easy to estimate the behavior of a
time
server when lower priority tasks share global resources; on one
hand, if the smallest task period in a server is close to ,
will be significantly increased even for small values of . As the
is small for time intervals close to , the server
value of
needs a lot of extra resources in order to fulfil server schedulability. On the other hand, if the smallest task period is much
will only be affected for large values of
larger than , then
, as shown in Fig. 4.
Fig. 5(a) shows
as a function of when only a single task
within a server accesses a global shared resource with different
. In the figure, the task accessing the
priorities, where
shared resource has either the highest priority than other tasks
with lower priorities. This observation is expected as the interference from higher priority task is larger than the interference
from lower priority tasks [see (6) and (7)]. However, note that
stays within the
in the figure this is true for the case where
range of [0, 5]. If the value of is larger than 5, then
keeps
increasing rapidly without any difference among the priorities
of tasks accessing the shared resource. The reason why it happens is as follows: When using SIRAP, the server budget
should be no smaller than to enforce the second rule (R2) in
,
must be increased to
Section IV-B. Therefore, when
accommodate the desired critical section, i.e., set greater than 5
according to the R2 rule. Since server period is fixed to 15, this
with the speed of
essentially results in a rapid increase of
.
C. Impact of the Server Period
The server period is one of the most important parameters,
both in the context of global scheduling and the calculation of
the supply bound function
for a server. As
is used in
calculation,
will have a significant effect on
[see
the
(3)].
Fig. 5(b) compares average server utilization for different
and
) for
values of server period (i.e., for
the same task set. Here, only the highest priority task accesses
a global shared resource, a configuration which has shown to
have greater impact on the server’s required utilization (see
Section VI-B). It is interesting to see that a lower value of ,
, results in a lower server utilization when
is
i.e.,
3In experiments, we have run 10, 25, 50, and 100 task sets, and the difference
in their results are only visible as smoothness in the trends of Fig. 5(a) and (b).
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
NOLTE et al.: A SYNCHRONIZATION PROTOCOL FOR TEMPORAL ISOLATION OF SOFTWARE COMPONENTS IN VEHICULAR SYSTEMS
383
Fig. 5. Average server utilization looking at 100 task sets, plotting their respective server utilization value as a function of the length of corresponding critical
sections x . (a) Impact of priority of task accessing a shared resource (5 = 15). (b) Impact of server period (between 5 = 20 and 5 = 40).
small, i.e.,
, and then a higher server utilization when
increases, starting at
. That is,
and
are not
dominating factors one to another, but they collectively affect
the server utilization. It is also interesting to see in Fig. 5(b)
behaves in a similar way
that the server utilization of
.
by increasing rapidly from
Hence, in general,
should be less than the smallest task period in a server. As in hierarchical scheduling without resource
gives better results (needs
sharing [27], a lower value of
less utilization). However, in the presence of global resources
sharing, the selection of the server period also depends on the
maximum value of resident in the server, i.e., it is not resource
below ; in fact there is a tradeoff beefficient to decrease
tween server period, task period, length of critical sections, and
context switch overhead.
E. Evaluation of System Load
dication of the amount of extra CPU required when running a
HSF in the presence of shared resources. We look at the extra
CPU resources needed when using a HSF itself, both with (i.e.,
when using SIRAP) and without synchronization, and we look
at the CPU resources needed when running the system using a
non-hierarchical approach. The evaluation is done by means of
simulation experiments. We start by describing the setup of our
experiments, which is followed by the results.
1) Experiment Definition: The simulation study is performed
by applying the SIRAP protocol on 1000 different randomly
generated systems using the schedulability analysis presented
in Section V, where each system consists of five subsystems4
and, in turn, each subsystem contains eight tasks. The internal
resource ceiling of the globally shared resources is assumed to
be equal to the highest task priority in each subsystem. Two to
six tasks access globally shared resources in each subsystem.
is
The worst-case critical section execution time of a task
and
. A task is assumed to
set to a value between
access at most one globally shared resource. For each system,
the number of global shared resources is two and all subsystems
have at least two internal tasks that access both global shared
resources. For each simulation study, the following settings are
changed and a new 1000 systems is generated.
1) System utilization–the system utilization, i.e., the summation of the utilization of all tasks in the system, is specified
to a desired value.
2) Subsystem period–the subsystem period is specified as a
range with a lower and upper bound. The simulation program generates a subsystem period randomly within the
specified range, following a uniform distribution.
3) Task period–the task period is specified and generated in
the same way as the period of a subsystem.
The system utilization is divided randomly among the subsystems and the assigned utilization to each subsystem is, in turn,
divided randomly to the tasks that belong to that subsystem.
Since the task period is generated to a value within the interval
as specified, the execution time is derived from the desired task
utilization. All randomized system parameters are generated following uniform distributions.
In this section, we evaluate the use of the SIRAP protocol
using the notion of system load [32], since it provides an in-
4We have tested several scenarios and the number of subsystems does not
appear to have a significant impact on the system load.
D. Impact of the Number of Critical Sections
Here, we compare the case when a task accesses multiple
critical sections, denoted MCS, with the case when a task
accesses a single critical section, denoted SCS, within dura. The comparison is done by investigating
tion
(5)–(7), needed to evaluate the demand bound function, (4). The
following shows the effect of a task’s accessing MCS or SCS on
its higher and lower priority tasks and on itself:
• On higher priority tasks, the effect from higher priority
tasks accessing MCS or SCS can be evaluated by (6). Here,
will be the same for both cases.
for MCS is less
• On lower priority tasks, (7) shows that
than for the SCS case because in the MCS case the maxwill be less than , which is used for the SCS
imum of
case.
• On the task itself. (5) shows that both accessing MCS and
SCS by a task gives the same result.
Therefore, we can see that the required server utilization for
the case of MCS will be always less than or equal to that for the
, which means that our proposed
case of SCS, if
protocol is scalable in terms of the number of critical sections.
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
384
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
FOUR STUDIES OF CORRESPONDING
TABLE I
WHEN RUNNING HSF AND SIRAP, HSF WITHOUT SYNCHRONIZATION, OR A FLAT SYSTEM WITH SRP
2) Simulation Results: Table I shows the results of the four
different simulation studies performed.
• Study 1 is specified having a task utilization of 15%, task
periods between 400 and 1000, and subsystem periods between 50 and 200.
• Study 2 decrease task periods (compared to Study 1) to
(a task will
the interval of 400–450, and therefore also
have the same utilization compare to Study 1 and since its
period is lower then its execution time becomes lower).
• Study 3 decrease subsystem periods (compared to Study
1) to the interval of 50–60.
• Study 4 increase task utilization (compared to Study 1) to
(a task utilization will be higher
30%, and therefore also
and that increases its execution time).
In each of these studies, 1000 systems are randomly generated, and for each generated system the SIRAP protocol is apis calculated.
plied, and, in turn, for each case the
is defined as the minimum amount of CPU allocations necessary to guarantee the schedulability of the system . Under FPS
is defined as
global scheduling
(14)
where
(15)
values allow for deKeeping track of all calculated
termining min, max and average of the set of 1000 systems.
For reference, apart from—SIRAP—two other values are given
when using HSF
as well: 1) HSF–the corresponding
without sharing any global resources (to indicate the cost of running the SIRAP protocol), and 2) SRP–running a flat system
with the SRP protocol for synchronization (to indicate the cost
of using a hierarchical approach).
Looking at Table I, the results from Study 1 shows the extra
CPU resources required by SIRAP in order to enable synchronization between tasks, compared with running a HSF without
resource sharing or running a flat system and SRP.
Comparing the results of Study 1 and Study 2, the system
load values for the SIRAP and HSF studies are almost the same.
are decreased in Study 2 and that
Note that the values of
should decrease the required CPU resource (according to the results of Section VI-A). However, the task period range is also decreased, which make the task periods closer to the subsystem period than in Study 1 which increase the CPU resource required
(see Section VI-C). So the effect of decreasing task periods is
. This effect is not visible when
compensated by decreasing
running a flat system and SRP, hence Study 2 results in a lower
system load compared to Study 1 as is smaller.
The results of Study 3 are better for SIRAP compared to the
results of Study 1, and the reason for this is that the subsystem
periods’ range is decreased which makes the subsystem period
much smaller than the tasks’ periods, compared with the setting
of Study 1. Looking at the SRP case, in Study 3 the task set
is not modified and hence there is no difference compared to
Study 1. Finally, we show the effect of increasing the task set
and makes the overutilization in Study 4 which increases
head of using SIRAP higher. The same affect is seen across all
three approaches.
Note that the cost of using HSF and SIRAP is much higher
than running a flat system with SRP. This is expected as having
a hierarchical scheduler introduce overhead which results in less
efficient usage of the CPU resource. The motivation for using a
HSF and SIRAP is due to its properties of isolation, where the
contents of one server are not allowed to affect the contents of
another server. Running a flat system, i.e., without a HSF, interference is present between all tasks, and guaranteeing timeliness
of one task is dependent on the availability of all task details of
all tasks in the system. The usage of SIRAP allows for synchronization across servers while maintaining the property of isolation, hence simplifying the integration of functions that need
mutual exclusive access to shared logical resources.
F. Vehicular Example
In the previous sections, we have shown the individual effect
of various parameters on the cost of using SIRAP. In this section, the system used for experiments is constructed looking at
the characteristics of an example given in [33] from which example parameters were derived from a wheel-loader application
by Volvo Construction Equipment. The example system consists
of 250 tasks, with periods selected from {10, 20, 25, 50, 100},
such that the total system utilization is approximately 60%. The
execution time of each task is randomly selected (since we did
not have access to true execution times), and all tasks are divided
, representing five software functions.
into five servers
1) Server-Level Cost: For the purpose of showing the impact of server period configuration on the cost of using SIRAP
on server level, we consider two different configurations. One is
the identical-period configuration (configuration A), where all
. The other
servers have the same period set such that
is the different-period configuration (configuration B) where all
servers have different periods, with periods selected from {1, 2,
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
NOLTE et al.: A SYNCHRONIZATION PROTOCOL FOR TEMPORAL ISOLATION OF SOFTWARE COMPONENTS IN VEHICULAR SYSTEMS
385
TABLE II
PARAMETERS OF THE VEHICULAR EXAMPLE SYSTEM CONSISTING OF 250 TASKS PARTITIONED IN FIVE SERVERS
TABLE III
CORRESPONDING SYSTEM LOAD WHEN RUNNING THE VEHICULAR EXAMPLE IN FOUR DIFFERENT SETTINGS
2.5, 4, 5}. All system parameters and resulting server utilizations under the two configurations are shown in Table II. The
table shows, for each server :
–the number of internal tasks;
•
–the number of internal tasks accessing global shared
•
resources;
•
–the maximum length of corresponding critical
sections;
–the utilization of the task set by itself;
•
and
–the server periods for configuration A and B,
•
respectively;
and
–the utilization required by the server in con•
figuration A and B, respectively;
and
–the absolute (to ) overhead
•
for each server under the two configurations, respectively;
•
and
–the relative (to ) overhead
for each server under the two configurations, respectively.
In this example, a number of properties of SIRAP are visible. First, it can be seen that, in general, a smaller server period results in a smaller server utilization, as investigated in
Section VI-C. Second, the longer the critical section, the more
overhead it induces. For example, and have the larger critical sections in the example and they both require more CPU resources compared with the other three servers. On average, each
server requires an additional 2.12% (configuration A) or 1.70%
(configuration B) of the CPU resource, i.e., each server’s required CPU resource increase with 15.37% (configuration A) or
13.11% (configuration B). In the example, a total of 10.6% (configuration A) or 8.5% (configuration B) is consumed as CPU
overhead due to running SIRAP, i.e., the CPU resources required
to execute the tasks increase with 15.92% (configuration A) or
13.18% (configuration B) compared with running them standalone without servers and critical sections.
2) System-Level Cost: Table III shows the system load
for different settings. The first setting in the table indicates
a situation where all tasks in the systems are scheduled in a
nonhierarchical manner. We consider this setting as a base
case. In the second setting, assuming there is no global resource
sharing, the system is scheduled under HSF with server periods
selected from {1, 2, 2.5, 4, 5}. This setting shows how much
more system load is required by the use of HSF (even without
using SIRAP). In this example, the use of HSF imposes 3.2%
more system load, i.e., in this example, 5.41% of the CPU
resource consumed by the system is due to the HSF itself.
In the third and fourth settings, the system is scheduled with
HSF and SIRAP together, when server periods are determined
according to the identical-period and different-period configurations, respectively. Table III shows that the use of SIRAP
increases system load to 11%–14% depending on server period
configurations (servers having different server periods, or all
servers having the same server period), i.e., the usage of SIRAP
is causing an overhead of 7.8%–10.8% given the two configurations; an increase in overhead of 11.64%–15.43% compared
with running the HSF without SIRAP.
It is also seen that a smaller system load is imposed by the
identical-period configuration than by the other configuration.
This is because servers do not get blocked by other servers when
they have the same periods (i.e., the load bound function
thereby becomes smaller in (9) with
). Hence, even
though the server utilization of individual servers are smaller
in the different-period configuration (as shown in Table II), the
overall system load becomes smaller in the identical-period configuration. That is, the identical-period configuration is a very
effective way to reduce the overhead when using SIRAP.
Typically, timing critical vehicular systems are today engineered to have a maximum load much lower than 100%, to ensure and preserve timeliness. However, due to economical reasons, load levels are continuously being pushed towards the
maximum in order to fully exploit the processing power. In
some cases ECUs are known to have loads up to 80%–90%,
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
386
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 5, NO. 4, NOVEMBER 2009
e.g., engine control software executed on a tailored architecture.
Considering that the use of SIRAP may allow 100% system load
without jeopardizing timeliness, we conclude that SIRAP can
be a valuable technique to achieve both higher system load and
more predictable integration of semi-independent functions.
uC/OS (which is OSEK compatible), and we are doing some experiments with Linux. The choices of operating systems is typically related to our industrial and academic partners. The next
step is to do experiments with another OSEK compatible OS,
the OSE from Enea.
VII. CONCLUSION
In this paper, we have presented our work on a synchronization protocol for temporal isolation of software components
in vehicular systems. Specifically, we have presented the Subsystem Integration and Resource Allocation Policy (SIRAP),
which provides predictable timing of servers that access global
shared resources. We have proposed the use of such servers
to schedule AUTOSAR software components, to provide predictable integration of multiple software functions on a single
ECU. Using SIRAP, a set of functions allocated to a server can
be developed, tested and analyzed without knowledge of the
temporal behavior of other software functions and components
in the system. Hence, integration of functions and components
in the later phases of product development will be smooth and
seamless.
SIRAP alleviates many of the problems that stem from temporal side-effects when integrating many software components
onto a single ECU. Without servers, components that work perfectly fine when unit-tested (which typically means that they
have the ECU dedicated to themselves) often start to exhibit failures when integrated with other components. A large portion of
these failures comes from the changed temporal behavior and
from unpredictable (or at least unanticipated) delays when accessing shared resources.
We have presented key features of SIRAP such as bounds
on delays for accessing shared resources. Further, we have provided schedulability analysis for tasks executing in the servers;
allowing for use of hard real-time application within the SIRAP
framework.
The flexibility and predictability offered by SIRAP comes
with some costs in terms of overhead, and we have evaluated this
overhead through a simulation study. From the study, we can see
that the server period should be chosen sufficiently smaller than
the smallest task period in a server and take into account the
(resource holding time) in the server to
maximum value of
prevent having high server utilization. Inherent in the tradeoff
between the server period and the resulting overhead imposed
by SIRAP, setting the server period smaller than half of the
shortest period task ensures an efficient SIRAP configuration.
In addition, having the same server periods across all servers is
a good strategy to further reduce overheads.
When studying a realistic example from an actual vehicle we
see that the system load increases with about 10%–15% compared to not using servers and SIRAP. Considering that the use
of SIRAP may allow 100% system load without jeopardizing
timeliness we conclude that SIRAP can be a valuable technique
to achieve both higher system load and more predictable integration of semi-independent functions.
In ongoing work, we have implemented the HSF for VxWorks
[34], and we are currently implementing the SIRAP protocol on
top of this implementation in order to investigate implementation overheads. Furthermore, we are doing implementations for
REFERENCES
[1] M. Behnam, I. Shin, T. Nolte, and M. Nolin, “SIRAP: A synchronization protocol for hierarchical resource sharing in real-time open systems,” in Proc. 7th ACM and IEEE Int. Conf. Embedded Software (EMSOFT’07), Oct. 2007, pp. 279–288.
[2] AUTOSAR, Automotive open system architecture (AUTOSAR), [Online]. Available: http://www.autosar.org/
[3] O. Group, OSEK/VDX Operating System Specification 2.2.1. [Online]. Available: http://www.osek-vdx.org/
[4] G. Lipari, P. Gai, M. Trimarchi, G. Guidi, and P. Ancilotti, “A
hierarchical framework for component-based real-time systems,”
in Component-Based Software Engineering. Berlin, Germany:
Springer-Verlag, May 2005, vol. LNCS-3054/2004, pp. 253–266.
[5] J. P. Lehoczky, L. Sha, and J. K. Strosnider, “Enhanced aperiodic responsiveness in hard real-time environments,” in Proc. 8th IEEE Int.
Real-Time Syst. Symp. (RTSS’87), Dec. 1987, pp. 261–270.
[6] B. Sprunt, L. Sha, and J. P. Lehoczky, “Aperiodic task scheduling for
hard real-time systems,” Real-Time Syst., vol. 1, no. 1, pp. 27–60, Jun.
1989.
[7] J. K. Strosnider, J. P. Lehoczky, and L. Sha, “The deferrable server
algorithm for enhanced aperiodic responsiveness in hard real-time environments,” IEEE Trans. Computers, vol. 44, no. 1, pp. 73–91, Jan.
1995.
[8] Z. Deng and J.-S. Liu, “Scheduling real-time applications in an
open environment,” in Proc. 18th IEEE Int. Real-Time Syst. Symp.
(RTSS’97), Dec. 1997, pp. 191–199.
[9] T.-W. Kuo and C.-H. Li, “A fixed-priority-driven open environment for
real-time applications,” in Proc. 20th IEEE Int. Real-Time Syst. Symp.
(RTSS’99), Dec. 1999, pp. 256–267.
[10] G. Lipari and S. K. Baruah, “Efficient scheduling of real-time multitask applications in dynamic systems,” in Proc. 6th IEEE Real-Time
Technol. Appl. Symp. (RTAS’00), May–Jun. 2000, pp. 166–175.
[11] A. Mok, X. Feng, and D. Chen, “Resource partition for real-time systems,” in Proc. 7th IEEE Real-Time Technol. Appl. Symp. (RTAS’01),
May 2001, pp. 75–84.
[12] X. Feng and A. Mok, “A model of hierarchical real-time virtual resources,” in Proc. 23th IEEE Int. Real-Time Syst. Symp. (RTSS’02),
Dec. 2002, pp. 26–35.
[13] I. Shin and I. Lee, “Periodic resource model for compositional real-time
guarantees,” in Proc. 24th IEEE Int. Real-Time Syst. Symp. (RTSS’03),
Dec. 2003, pp. 2–13.
[14] L. Almeida and P. Pedreiras, “Scheduling within temporal partitions:
Response-time analysis and server design,” in Proc. 4th ACM Int. Conf.
Embedded Softw. (EMSOFT’04), Sep. 2004, pp. 95–103.
[15] G. Lipari and E. Bini, “Resource partitioning among real-time applications,” in Proc. 15th Euromicro Conf. Real-Time Syst. (ECRTS’03),
Jul. 2003, pp. 151–158.
[16] R. I. Davis and A. Burns, “Hierarchical fixed priority pre-emptive
scheduling,” in Proc. 26th IEEE Int. Real-Time Syst. Symp. (RTSS’05),
Dec. 2005, pp. 289–398.
[17] F. Zhang and A. Burns, “Analysis of hierarchical EDF pre-emptive
scheduling,” in Proc. 28th IEEE Int. Real-Time Syst. Symp. (RTSS’07),
Dec. 2007, pp. 423–434.
[18] A. Easwaran, M. Anand, and I. Lee, “Compositional analysis framework using EDP resource models,” in Proc. 28th IEEE Int. Real-Time
Syst. Symp. (RTSS’07), Dec. 2007, pp. 129–138.
[19] L. Sha, J. P. Lehoczky, and R. Rajkumar, “Task scheduling in distributed real-time systems,” in Proc. Int. Conf. Ind. Electron., Control,
Instrum. (IECON’87), Nov. 1987, pp. 909–916.
[20] R. Rajkumar, L. Sha, and J. P. Lehoczky, “Real-time synchronization
protocols for multiprocessors,” in Proc. 9th IEEE Int. Real-Time Syst.
Symp. (RTSS’88), Dec. 1988, pp. 259–269.
[21] T. P. Baker, “Stack-based scheduling of realtime processes,” Real-Time
Syst., vol. 3, no. 1, pp. 67–99, Mar. 1991.
[22] R. I. Davis and A. Burns, “Resource sharing in hierarchical fixed priority pre-emptive systems,” in Proc. 27th IEEE Int. Real-Time Syst.
Symp. (RTSS’06), Dec. 2006, pp. 389–398.
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.
NOLTE et al.: A SYNCHRONIZATION PROTOCOL FOR TEMPORAL ISOLATION OF SOFTWARE COMPONENTS IN VEHICULAR SYSTEMS
[23] N. Fisher, M. Bertogna, and S. Baruah, “The design of an EDF-scheduled resource-sharing open environment,” in Proc. 28th IEEE Int. RealTime Syst. Symp. (RTSS’07), Dec. 2007, pp. 83–92.
[24] G. Lipari, G. Lamastra, and L. Abeni, “Task synchronization’ in reservation-based real-time systems,” IEEE Trans. Computers, vol. 53, no.
12, pp. 1591–1601, Dec. 2004.
[25] L. Abeni and G. Buttazzo, “Integrating multimedia applications in
hard real-time systems,” in Proc. 19th IEEE Int. Real-Time Syst. Symp.
(RTSS’98), Dec. 1998, pp. 4–13.
[26] M. Behnam, T. Nolte, M. Åsberg, and I. Shin, “Synchronization
protocols for hierarchical real-time scheduling frameworks,” in Proc.
1st Workshop on Compositional Theory and Technology for Real-Time
Embedded Systems (CRTS’08) in Conjunction With the 29th IEEE Int.
Real-Time Systems Symp. (RTSS’08), Nov. 2008, pp. 53–60.
[27] I. Shin and I. Lee, “Compositional real-time scheduling framework
with periodic model,” ACM Trans. Embedded Comput. Syst., vol. 7,
no. 3, pp. 1–39, Apr. 2008.
[28] M. Caccamo and L. Sha, “Aperiodic servers with resource constraints,”
in Proc. IEEE Int. Real-Time Syst. Symp. (RTSS’01), Dec. 2001, pp.
161–170.
[29] M. Bertogna, N. Fisher, and S. Baruah, “Static-priority scheduling and
resource hold times,” in Proc. 15th Int. Workshop on Parallel and Distributed Real-Time Systems (WPDRTS’07), Mar. 2007, pp. 1–8.
[30] G. Lipari and E. Bini, “A methodology for designing hierarchical
scheduling systems,” J. Embedded Comput., vol. 1, no. 2, pp. 257–269,
2005.
[31] M. Joseph and P. Pandya, “Finding response times in a real-time
system,” Comput. J. (British Computer Society), vol. 29, no. 5, pp.
390–395, Oct. 1986.
[32] M. Behnam, I. Shin, T. Nolte, and M. Nolin, “Scheduling of semi-independent real-time components: Overrun methods and resource
holding times,” in Proc. 13th IEEE Int. Conf. Emerging Technol.
Factory Autom. (ETFA’08), Sep. 2008, pp. 575–582.
[33] K. Hänninen, J. Mäki-Turja, M. Bohlin, J. Carlson, and M. Nolin, “Determining maximum stack usage in preemptive shared stack systems,”
in Proc. 27th IEEE Int. Real-Time Syst. Symp. (RTSS’06), Dec. 2006,
pp. 445–453.
[34] M. Behnam, T. Nolte, I. Shin, M. Åsberg, and R. Bril, “Towards hierarchical scheduling on top of VxWorks,” in Proc. 4th Workshop on
Operating Systems Platforms for Embedded Real-Time Applications
(OSPERT’08), Jul. 2008, pp. 63–72.
Thomas Nolte (S’01–M’07) received the B.Eng.,
M.Sc., Licentiate, and Ph.D. degrees in computer
engineering from Mälardalen University (MDH),
Västerås, Sweden, in 2001, 2002, 2003, and 2006,
respectively.
He has been a Visiting Researcher at the University
of California, Irvine (UCI), Los Angeles, in 2002, and
a Visiting Researcher at the University of Catania,
Catania, Italy, in 2005. He has been a Postdoctoral
Researcher at the University of Catania in 2006, and
at MDH in 2006 to 2007. He became an Assistant
Professor at MDH in 2008. He has been an Associate Professor of Computer
Science at MDH since 2009. His research interests include predictable execution of embedded systems, design, modeling and analysis of real-time systems,
multicore systems, distributed embedded real-time systems.
Prof. Nolte is Program Leader of the PROGRESS National Strategic Research
Centre, President of The Swedish National Real-Time Association (SNART),
and Co-Chair of the IEEE IES TCFA Real-Time Fault Tolerant Systems Subcommittee. He is a Member of the Editorial Board of Elsevier’s Journal of Systems Architecture: Embedded Software Design, since 2009, Guest Editor of the
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, 2008 and 2009, Co-Organizer of international events including the International Workshop on Compositional Theory and Technology for Real-Time Embedded Systems (CRTS), 2008,
2009, and 2010, and Program Co-Chair of the IEEE International Conference
on Emerging Technologies and Factory Automation (ETFA), the Real-Time and
(Networked) Embedded Systems Track, 2008, and the IEEE International Workshop on Factory Communication Systems (WFCS), the Work-in-Progress (WIP)
Track, 2008 and 2009.
387
Insik Shin (M’07) received the B.S. degree in
computer science from Korea University, Seoul,
the M.Sc. degree in computer science from Stanford University, Stanford, CA, in 1994 and 1998,
respectively, and the Ph.D. degree on compositional
schedulability analysis in real-time embedded
systems from the University of Pennsylvania,
Philadelphia, in 2006.
He has been a Postdoctoral Research Fellow
at Mälardalen University, Sweden, and a Visiting
Scholar at the University of Illinois at Urbana–Champaign until 2008. He is currently an Assistant Professor in the Department of
Computer Science, KAIST, since 2008. His research interests lie in cyber-physical systems and real-time embedded systems.
Prof. Shin received the Best Paper Award from the IEEE Real-Time Systems
Symposium (RTSS) in 2003. He has been a Co-Organizer of the International
Workshop on Compositional Theory and Technology for Real-Time Embedded
Systems (CRTS), 2008 and 2009 (co-located with the IEEE International RealTime Systems Symposium (RTSS), 2008 and 2009). He also served various
program committees in real-time embedded systems.
Moris Behnam (S’06) received the B.Eng. and
M.Sc. degrees in computer and control engineering
from the University of Technology, Iraq, and the
M.Sc. and Licentiate degrees in real-time systems
from Mälardalen University (MDH), Västerås,
Sweden, in 1995, 1998, 2005, and 2008, respectively. He is currently working towards the Ph.D.
degree at MDH.
He was a Visiting Researcher at Wayne State University in 2009. His research interests include realtime hierarchical scheduling, synchronization protocols, multiprocessor/multicore systems, and real-time control systems.
Mikael Sjödin received the M.Sc. and Ph.D. degrees
from Uppsala University, Uppsala, Sweden, in 1995
and 2000, respectively.
Since 2002, he has been pursuing research in distributed embedded systems at Mälardalen Real-Time
Research Centre (MRTC). In 2007, he joined the faculty as a Professor of Computer Science with special focus in real-time systems and vehicular software
technology. He has since 2000 also worked full-time
and part-time in industry asa software engineer in the
vehicular sector. Currently, the focus of his research
is towards analysis of nonfunctional properties, predictable execution, and efficient design of correct software.
Authorized licensed use limited to: Korea Advanced Institute of Science and Technology. Downloaded on November 18, 2009 at 00:06 from IEEE Xplore. Restrictions apply.