No Detour Needed: Getting to AUTOSAR via OSEK

Author(s): Jochen Schoof and David Wybo

Source: SAE Transactions, Vol. 115, SECTION 7: JOURNAL OF PASSENGER CARS:
ELECTRONIC AND ELECTRICAL SYSTEMS (2006), pp. 50-56
Published by: SAE International
Stable URL: https://www.jstor.org/stable/44700023
Accessed: 23-08-2022 20:24 UTC

JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide
range of content in a trusted digital archive. We use information technology and tools to increase productivity and
facilitate new forms of scholarship. For more information about JSTOR, please contact support@jstor.org.

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
https://about.jstor.org/terms

SAE International is collaborating with JSTOR to digitize, preserve and extend access to SAE
Transactions

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
 2006-01-0168

No Detour Needed: Getting to AUTOSAR via

Jochen Schoof
3SOFT GmbH

David Wybo
Elektrobit, Inc.

Copyright © 2006 SAE International

ABSTRACT suggestions on what would be a good approach to

implementing a standardized software architecture.
While the significance of basic software standardization
is widely agreed on, many automotive companies A are
SHORT HISTORY OF SOFTWARE
still not sure how to introduce it into their processes.
STANDARDS IN CARS
With the appearance of AUTOSAR, many also wonder
whether a solution based on established standards such Today, there is no doubt that one key factor in desig
as OSEK is still reasonable or if a direct move to and implementing reliable software for a car's electr
AUTOSAR is the better solution. We present control units (ECUs) is the availability of standardiz
experiences with both approaches to help facilitate a software modules. Ideally these are already pre-
choice. We suggest that the best approach is, at the integrated to facilitate the suppliers' work to get a stable
very least, to implement the existing OSEK standards base for the application itself. This permits the
and that the path from OSEK to AUTOSAR is application developers to concentrate on their individual
straightforward. core competencies instead of spending time integrating
standard software.
INTRODUCTION
CAN AS A FIRST STANDARDIZATION DRIVER
The international AUTOSAR initiative has made
significant progress since becoming public in late 2003.
The result is a collection of specifications for standard
software components to be used in the software of
electronic control units (ECUs) as well as various XML
based formats for configuration files describing individual
adaptations of these components. As a result of the
number of specifications within AUTOSAR, some users
might feel that the step from their current solutions to a
complete AUTOSAR solution is a very large and
complex one. Many companies have recently started to
consider insisting that their suppliers use standard
components like an OSEK conforming operating system.
They might ask themselves whether this is still
reasonable given the recent developments with
AUTOSAR and what can be expected from this new set
of standards.

Figure 1- Application with standardized CAN driver

In this paper we will take a short look at the history of
standardizations for in-car software to learn what has
The first standard software components were introduc
changed in the last ten to twelve years. We will then take
to the automotive industry with the introduction of t
a first look at what AUTOSAR adds to the existingCAN communication bus into cars. The basic idea was
solutions and what the implementation of these new
to make communication between ECUs possible, which
standards means for a software provider. A user's view
was achieved by connecting these ECUs via CAN. Bu
of AUTOSAR will be followed by some initial
this was just the hardware part. To really have the ECU
experiences from both the implementation and use of
communicate with one another, compatible driver
the AUTOSAR standards. We will conclude with some
software was needed to insure that CAN input and

50

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
output messages were the same. So users of CAN a vehicle as complex as this was no longer possible
communications were also required to standardize the without standardized software. They also stated that the
software driver. use of standard software has already paid off in this first
car platform.
OSEK BASED STANDARD PLATFORMS
THE HIS I/O LIBRARY
It turned out that the integration of a CAN driver into
existing software was not always easy, because certain
Further standardization steps were taken when
timing demands had to be met (e.g. calling a routine DaimlerChrysler,
in a in addition to introducing OSEK
defined interval). In addition, it became clearconforming
that a modules into their software development,
certain communication policy would help to better also required standardized access to on-chip
exploit
the bandwidth of the CAN bus. Up to that point any peripherals.
ECU The result of this was the definition of th
that had something to send simply did so, which waslibrary, which was adopted by a number of oth
HIS I/O
acceptable when there were only a few participants manufacturers.
in For example, it became an important
the communications. But with the demand for more part of Volkswagen's Standard Software Core. For the
ECUs communicating over CAN, this approach was first time, the complete abstraction of the hardware
susceptible to wasting a large portion of the available
seemed possible, permitting truly portable applications
bandwidth on network collisions.

These were two of the issues that led to founding the

OSEK initiative in the early 1990s. Its goal was the
definition of standards for a real-time operating system
(OSEK-OS), a communication system (OSEK-COM) and
a network management system (OSEK-NM). Additional
standards were defined to facilitate working with the
individual systems. One example is the OSEK
implementation language (OIL) defined to describe
configurations of OSEK in a standardized human
readable way.

Figure 3 - OSEK and HIS based software platform

OSEK based standard software platforms are under

wide use these days, particularly in Europe and Japan.
Many OEMs, as well as suppliers, have in-house
solutions available to their subcontractors. These
solutions have proven to be stable and reliable over
last few years. For today's production use, they are
state of the art. However, some tailoring to individ
requirements is needed, to make sure that custome
requirements are met.

Figure 2 - OSEK based software platform AUTOSAR AT A GLANCE

The first automotive manufacturer to introduce software

While OSEK-based software platforms as described
components conforming to the OSEK specifications in a above usually differ between different manufacturers
large number of ECUs was BMW. To adapt the OSEK and suppliers, the aim of the AUTOSAR initiative is to
specifications to their individual requirements, they define one universal standard that no longer requires
developed the BMW standard core starting 1997. This tailoring for individual variations. In practice, individual
standard core software added even more modules than flavours of similar solutions are both more difficult and
specified in the OSEK specifications, and provided a more expensive to maintain. Even the exchangeability of
fully integrated software platform for their suppliers. The applications is often not as good as necessary. As an
BMW seven series, introduced in 2001, used this example, consider the case of a supplier who delivers
standard core in nearly all ECUs connected to the the very same ECU to two different OEMs with different
vehicle's CAN bus. It was considered a demonstration of
software platforms. This supplier is required to develop,
what standard software could enable. Furthermore, implement and maintain two software versions, with no
BMW has repeatedly stated that they believe developing added benefit. Time has shown that this can be handled,

51

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
but using the same software for both customers would acquired. The details describing the source of all this
be the better solution, reducing cost and complexity, and information is configured into the RTE, which can thus
thereby gaining higher reliability. easily handle situations where the sources of information
change during development. This is the basis for being
AUTOSAR was initiated by manufacturers and suppliers, able to move functionality between ECUs in the in-car
the core members, in early 2003, and became public in network - one of the main long term goals of AUTOSAR.
the fall of 2003. Since then, various companies have
joined the initiative as either premium or development Currently, AUTOSAR specifications for release 1.0 have
members. The core and premium members co-operated been completed and the first implementations of single
in defining the standards, not only for single software AUTOSAR compliant modules, as well as a complete
modules, but also for the information required to set of components, are in progress. Initial versions have
configure these modules, as well as the framework already found their way to manufacturers and suppliers
necessary to integrate these modules into a software
in order to allow them to evaluate the implementation of
platform. The differences between AUTOSAR and the specifications. The intention of AUTOSAR release
OSEK can be likened to the comparison between 1.0 is to get feedback in order to mature the
Windows and MS-DOS: AUTOSAR incorporates OSEK,specifications. There are companies considering the use
but also provides solutions for problems OSEK was of these modules in production as well.
never intended to address.
In addition to defining standard software modules,
Almost all of the OSEK specifications have made their
AUTOSAR also specifies a complete workflow, ranging
way into AUTOSAR, including the operating system, the
from system definition and constraints to the final source
communication system and the network management. code API of the standard core modules. This workflow
Even some OSEK configuration formats are currently involves the different participants in automotive ECU and
included. The same is true for the concepts of the HIS
network development. This approach works with the
I/O library. They form the foundations for whatestablished working schemes between manufacturer
AUTOSAR calls the microcontroller abstraction layer
and supplier, but also opens the door for new scenarios
(MCAL). But AUTOSAR goes much further in that it alsosuch as the purchase of hardware and software
defines communication drivers for CAN, LIN and separately from different suppliers, or the integration of
FlexRay as well as dedicated MCU drivers, diagnostic software from several suppliers into a single ECU.
routines, and base services such as CRC.
AN IMPLEMENTER'S VIEW OF AUTOSAR

THE AUTOSAR BASIC SOFTWARE

The complete standard core as defined by AUTOSAR

Figure 4 - AUTOSAR standard core modules
Possibly the greatest feature of AUTOSAR is the run-
time environment (RTE), which provides the interface to
the user application. The concept of RTE is to offer a
virtual function bus (VFB) which allows the application to
makes requests for any input data, without knowing its
actual source. The application software no longer needs
to know where certain pieces of information are coming
from, but simply requests them from the RTE. The actual
source of the requested information may be a physical
input pin of the ECU, or it may be a computed value or
one that is retrieved in a CAN message from another
ECU. The RTE provides the data regardless of how it is
52
consists of 34 different modules (see figure 4). With few
exceptions, they can each be individually configured by
the user. The challenges for the implementer of a
complete AUTOSAR software platform are various. In
addition to the obvious challenges of writing and testing
such a large amount of new software, each module must
be tested in each of its possible configurations. In
addition, since it is possible that each module could be
used independent of the rest, as well as together in a
bundled system, each of the modules must be
thoroughly tested on its own. Also, configuration tools for
each module or - preferably - one single unified
configuration tool must be developed and adapted to
support the requirements of the different modules.
Possibly the greatest challenge is the optimization of the
source code that is produced by the configuration tools.
Optimization must be performed in two stages. Any
single module needs to be optimized in both code size
and execution performance. The same type of
optimization is then needed for the collection of modules
to be used. Since it is desirable to be able to integrate
AUTOSAR modules from different software providers,
the quality of optimization will depend on the number of
individual modules contained in one software package
(e.g. CAN driver optimization). The best optimization
results will obviously be achieved if the copying of data

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
between all the software layers of a given package can well as to maintain, update and support them. Our
be reduced to a minimum. However, this requires experiences from the past suggest that users are
knowledge about the internals of the other modules, dissatisfied when each module comes with its own
which may not be possible if they are provided by configuration tool. It will be interesting to see the
competing vendors. The best optimization therefore, is concepts designed to improve the situation.
likely only to be achieved if the complete package
comes from one supplier source. The above only reflects the challenges for the develo
of the AUTOSAR basic software modules and
As mentioned previously, some parts of AUTOSAR are configuration tools, and does not even address t
direct successors of existing solutions, such as the complex attributes of AUTOSAR. More work is
AUTOSAR operating system. It is based on the to develop the tools for system design and c
successful OSEK operating system specification but
determination. These can be realized as either stand-
adds additional features. The most prominent ones arealone tools or solutions integrated with the configurati
tools.
time and memory monitoring, both of which facilitate the
integration of third party software into an application.
Using these services, it is possible to check whether aUSING AUTOSAR AND HOW TO GET THERE
single task or group of tasks consume too much
execution time or access memory areas they should not. What does working with AUTOSAR mean to the
Time monitoring is performed using time budgets which, developer of automotive ECUs? Let us first take a look
compared to traditional deadline monitoring techniques, at the final vision of software development from an
insure the cause of the problem, i.e. the task which ran AUTOSAR perspective. Following that, we will describe
out of time, can be determined. Memory monitoring, or to what extent this is already possible.
protection, guarantees that accesses from one task to
another task's memory can be detected. Memory THE AUTOSAR VISION
protection does require the availability of additional
hardware resources, namely an MMU. Both time AUTOSAR takes the OSEK philosophy of statically
monitoring and memory protection are configuration configuring the basic software one step further b
options. This allows the AUTOSAR OS to be used on extending this paradigm to a much larger share of
microcontrollers without an MMU, and also allows users software. It is no longer applies to only five modules
to scale the size of the operating system. in the case of OSEK, but to more than thirty. Using th
approach of static configuration is essential for
On the other hand, there are portions of AUTOSAR AUTOSAR because it is still the best approach for
which may sound familiar but that have been completely getting highly optimized code.
redefined. The new microcontroller abstraction layer, or
MCAL, only has its basic concept, but no implementation Fortunately, much of the configuration work will be done
details, in common with the HIS I/O library mentioned ahead of time, and will not be the responsibility of the
earlier. As another example, AUTOSAR COM adds applications developer. The AUTOSAR compliant
many new features to what is defined in OSEK COM. software manufacturer will provide the software
Finally, the AUTOSAR RTE is something that does not component descriptions and system constraints. Then
have any similar predecessor in OSEK, and needs to be the available ECUs will be defined in an ECU
developed from scratch. This provides a sense of how description. The next step is a mapping between the
much work is necessary to develop a software platform software component descriptions and the ECU
compliant to the AUTOSAR specifications. A complete descriptions. This will determine which functions will run
AUTOSAR implementation, including all defined on which ECUs. The resulting ECU configuration
modules, now competes in functionality with largerdescription can then be used to generate the separate
operating systems already available in the market. The ECU configuration files for the AUTOSAR modules.
development costs for the provider are also comparable
- and so the resulting products will have comparable Among the ECU configuration files, the configuration of
prices. the RTE is of special importance. Since the RTE
includes the API for all the software modules in
AUTOSAR CONFIGURATION
AUTOSAR, its configuration can influence the
configuration of all of the others. It contains information
As mentioned earlier, an AUTOSAR software supplier about data available over the network as well as locally.
must provide a configuration tool that is able to Whenever
handle this information changes, the RTE
the configuration of each of the software modules. Due
configuration file for any involved ECU will change. This
to the large number of software packages in AUTOSAR, will necessitate the propagation of these changes to
it is important that this tool support the complete other local modules like e.g. the CAN driver, which might
configuration of all modules as much as possible, while then need to be configured to receive different CAN
at the same time being easy to use. In principle it is frames.
possible to provide a collection of configuration tools, but
there are significant drawbacks to this approach. It is What the applications developer will need to do in the
difficult to achieve consistency across multiple tools, as way of configuration is primarily to make very specific
53

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
application dependent decisions such as which PWM
channel to use for what purpose, and so on. The major
portion of general configuration assignments will already
have taken place when the developer begins their
implementation effort.
than will be possible in the future. It is agreed that for
quite a while it will be necessary to examine the
generated configuration files quite closely. In the future
this will not be required, but anyone who starts with
AUTOSAR today will have the knowledge to continue to
do this if desired.

Configuration of an early AUTOSAR standard core will

begin with a design phase in which the application will
be partitioned into separate tasks. Experience from
existing software platforms can easily be re-used. It
might even be possible to use at least parts of existing
configurations, e.g. the OIL file describing the OSEK
services needed.

Another advantage of this early phase is that it is

possible to use single AUTOSAR modules in existing
environments or to replace AUTOSAR modules which
are not yet available with other solutions. As an
example, since the AUTOSAR definition of LIN is still
unfinished, it would be possible to integrate an existing
LIN solution. This can be done very easily if the
Figure 5 - AUTOSAR Workflow (Source: AUTOSAR) configuration tool is capable of adding modules or
perhaps even provides alternative modules as an option.
The way in which an application is written will also
change because AUTOSAR provides one single API to An early start with AUTOSAR can help to take a much
the developer, namely the RTE. Any information the smoother approach to the final vision than waiting for the
application wishes to share with the AUTOSAR standard complete solution and introducing it in one step.
core is now achieved by sending or requesting
STARTING FROM SCRATCH OR FROM OSEK?
information through the RTE. For this reason the
application is split into several executable pieces of
code, called runables, which the RTE controls. Tasks as If no software platform is yet in use, one could start with
known from OSEK OS or other operating systems are an early AUTOSAR implementation that includes som
no longer part of the application code. The tasks are non-AUTOSAR or even self developed modules.
assembled below the RTE, incorporating these Currently, it is entirely possible to tailor the starting point
application runables, as well as the AUTOSAR software. to individual needs. Moving to an OSEK based software
platform is another viable alternative.
It is apparent that the AUTOSAR vision will influence the
complete development workflow significantly. This If OSEK or even a software platform is already in use, a
means that processes will need to be adapted to the possible approach is the stepwise replacement of single
new development philosophy. But with the stepwise modules by their AUTOSAR counterparts. The way of
specification and availability of AUTOSAR, it will not be doing this will be dictated by individual requirements. For
necessary to take an all-or-none approach. example a centralized handling of non-volatile memory
(EEPROM, flash, M-RAM etc.) as provided by the
AUTOSAR TODAY AUTOSAR NVR manager, may be useful for many
applications.
The current situation is quite different from the vision.
The step from OSEK to AUTOSAR OS is very easy
This is the case due to the fact that most of the tools for
the system design and function mapping are not yet because one of the main requirements for AUTOSAR
available. As a consequence, the seamless workflow OS was downward compatibility to OSEK OS 2.2.1.
does not yet exist. Currently, even the OIL configuration file format has
been accepted for the AUTOSAR OS, though this is
Working with AUTOSAR today is quite similar to working likely to change in the future.
with one of the traditional standard cores that are based
on OSEK. The developer must perform large parts of the So, in general, it may be best to start with an OSEK
configuration themselves. System issues are typicallybased solution and use single AUTOSAR modules in
only reflected in the configuration of the communicationthis new platform, especially if the target architecture is
module and some related functions. not yet supported by an AUTOSAR OS or if only single
modules are currently available.
This situation actually has an advantage. It provides the
opportunity to learn much more about AUTOSAR basics The important point here is not to wait for the complete
AUTOSAR specifications to be finalized. This will take
54

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
some time; time which is better spent making small and for that reason are not included in the first
steps towards a complete solution rather that attempting implementation. This is true for the RTE as well fo
to make the leap all at once. AUTOSAR workflow previously described. How
even this software will soon be completed with the
FIRST EXPERIENCES availability of the first implementations based on
AUTOSAR release 2.0 later this year.
IMPLEMENTING AUTOSAR
CONCLUSION
The task of developing an AUTOSAR based standard
core is a big challenge that requires a large number of AUTOSAR is a giant leap in standard software
developers with excellent skills. Only a few companies platforms, but it is not necessarily a leap that must be
will be able to provide such a solution. Previous made all at once. Depending on the users' targets even
experiences with similar projects seem to be a must in today starting with an OSEK based platform is an option
order to be successful. There are not many projects in worth consideration. As was the case when OSEK was
the automotive embedded software area that have had first introduced, the important first step is not simply to
comparable size. use the software, but more importantly, to understan
the philosophy behind it. This is especially true with th
AUTOSAR philosophy as it will likely significantly
The crucial part is that it is not a static piece of software
that is being developed but a collection of various change the workflow behind vehicle software
modules that can each take many forms, depending on development
the configuration. Thus, testing is a major portion of the
effort. With the intended wide-spread use of AUTOSAR, The user will have to think in communicating entities
high quality software is even more important an issue instead of tasks or even time slices. For example, the
than in the past. Defects in the implementation could operating system will be invisible to the application and
affect not only one single car model or brand but various must be accessed via the RTE. The same is true for
manufacturers using the same component. Testing drivers and all the software layers below the RTE. Th
tools, therefore, will also need to be developed, and will, may be unusual at first but will turn out to match
themselves, require a significant effort. Successful perfectly with well-known object-oriented software
experience with projects on a similar scale provides the concepts.
knowledge to handle these challenges.
Even so, familiarity with an operating system like OSEK
However, first results are available and getting to usable will be very beneficial for anyone working with
results in a reasonable time is possible if a company is AUTOSAR. This is especially true for early AUTOSAR
willing to take an early start. These early adopters will in adopters, as the user still has to directly work with the
particular help to stabilize the existing software - and operating system. Even with the availability of a final
they will be the first to benefit from this improved quality. AUTOSAR implementation, a better understanding of
what is going on beneath the AUTOSAR RTE and how
USING AUTOSAR the complete software package functions, will be
valuable knowledge. This is why the implementation of
Customers are now evaluating AUTOSAR an AUTOSAR application by first gaining experience
implementations and the first reactions are quite with OSEK is the recommended approach.
surprising. Far fewer problems have appeared than
might be expected from a software project of this size. On the one hand AUTOSAR may seem scary due to its
The similarity of the current solutions to existing software pure size and complexity. On the other hand AUTOSAR
platforms may have helped. will take reliability to new dimensions if it becomes the
standard it was designed to be. It will hopefully result in
A majority of the questions have had to do with the new the adoption of software standards by all OEMs and
concepts within AUTOSAR, like MCAL, while the use of suppliers, and will streamline the software development
the operating system seemed to work without problems, process for in-vehicle applications.
most likely because of its similarity to OSEK.
REFERENCES
Another key issue is the use of tools that provide a well-
known look-and-feel. It is extremely helpful if the user is 1. H. Heinecke, K.-P. Schnelle e.a. AUTOMOTIVE
familiar with the basic concepts of the configuration tool. OPEN SYSTEM ARCHITECTURE, Proceedings of
One possible way to achieve this is the extension of the 2004 international congress on transportation
existing tools for e.g. the configuration of OSEK electronics, 2004, Detroit, Ml, p. 325-332
operating systems to other modules. Doing so has 2. Jochen Schoof, Towards portable embedded
proven to improve the users' acceptance significantly. automotive applications, Embedded Control
Europe, November 2002, ICC Media 2002, S. 38-40
What can not yet be judged, of course, are those parts
of AUTOSAR that have not been completely specified

55

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms
CONTACT ECU: Electronic Control Unit

Dr. Jochen Schoof received his M.Sc. ("Diplom") and

HIS: Hersteller-lniative Software (manufacturers'
Ph.D. in computer science from the University of
initiative for software)
Würzburg, Germany. Since 1998 he has held different
positions at 3SOFT and currently works as a product LIN: Local Interconnect Network
manager and director of sales. Besides this, he is still
giving lectures on operating systems at the University of
MCAL: Microcontroller Abstraction Layer
Würzburg. He can be contacted via email at
Jochen.Schoof@3SOFT.de.
MMU: Memory Management Unit
David Wybo received his B.S. In mathematics from
Northern Michigan University. He has worked in a OEM: Original Equipment Manufacturer
variety of embedded software environments, in the role
of applications developer as well as a field applications OSEK: Offene Systeme und deren Schnittstellen für die
engineer for embedded software vendors. He currently Elektronik in Kraftfahrzeugen (open systems and the
serves as Chief Software Engineer for Elektrobit Inc. the corresponding interface for electronics in cars)
parent company of 3Soft, in the Detroit Ml area. David
can be reached via email at david.wvbo@elektrobit.com PWM: Pulse Width Modulation

RTE: Run-Time Environment

DEFINITIONS, ACRONYMS, ABBREVIATIONS

AUTOSAR: AUTomotive Open System ARchitecture XML: extended Markup Language

CAN: Controller Area Network

56

This content downloaded from 147.233.250.200 on Tue, 23 Aug 2022 20:24:46 UTC
All use subject to https://about.jstor.org/terms