AUTOSAR Basic Software for Complex Control

Units

Dirk Diekhoff
Elektrobit Automotive
Erlangen, Germany

Abstract— Dirk Diekhoff, Elektrobit Automotive for the development of application software by different
manufacturers. Functions in the ECU network are easier to
"The development of complex control units requires mature and integrate and replace, making vehicle manufacturers more
reliable basic software as well as integration support particularly flexible in the use of ECU software. They can use individual
in early phases of the project. In this presentation Elektrobit functions on different platforms, model different variants and
Automotive will focus on new AUTOSAR basic software features equipment sets in the software architecture, and replace
such as multi core and functional safety. We will show how specific new features as needed. Software and hardware can be
integration and validation will be enhanced by diagnostic logging replaced and updated throughout the vehicle's lifetime.
and tracing functionalities."
III. CURRENT VERSION (RELEASE 3.1)
I. INTRODUCTION In the AUTOSAR architecture, application software, run-
For years, AUTOSAR (AUTomotive Open System time environment (RTE), basic software, and hardware are
Architecture) has been a de facto standard for software clearly separated from one another.
architecture in vehicle control systems.
A. AUTOSAR layered architecture
In the past few years, requirements for safety,
environmental protection, and comfort have grown
significantly in automotive development. Manufacturers in the
automobile industry are faced with increased requirements for
safety, environmental protection, and comfort with complex
vehicle electronics.
Up to 90 electronic control units (ECUs) are in use in a
high-end car. An entirely new challenge for OEMs and
suppliers is the high networking degree between functions and
devices. The growing number of functions and electrical
consumers means greater requirements for the on-board
communications and power network in all classes of vehicle.
In addition to more complex overall systems, the larger
number of control units in the vehicle also leads to increased
material requirements: to connect the individual ECUs, a total
of several kilometers of copper wire must be used, making the
cable harness larger and heavier. AUTOSAR specifies a layered architecture of basic
software (BSW) modules and application programmer
While the automobile industry is already using AUTOSAR interfaces (APIs):
release 3.1 in development and production, release 4.0 of the
standard has progressed even further in important points in 1) Application layer
order to meet the new requirements. This layer contains the functional applications of an ECU
network. The AUTOSAR standard refers to them as
II. GOALS OF AUTOSAR AUTOSAR Software Components.
The global AUTOSAR partnership has defined a standard
guaranteeing the efficient development of ECU software for 2) Microcontroller abstraction layer (MCAL)
the automotive industry. Functions and peripherals of the microcontrollers are
abstracted here. This makes the higher layers independent of
AUTOSAR supports the modular development of ECU- the specific microcontroller.
software. The standardized basic software forms the foundation

978-3-9810801-6-2/DATE10 © 2010 EDAA

 3) Electronic control unit (ECU) abstraction layer leads to more cost-efficient production and more energy-
In this layer, the design of the ECU is abstracted. efficient vehicles.
4) Service layer But how can architectures be efficiently implemented with
This layer provides basic services. These include the domain controllers? Here, too, AUTOSAR 4.0 and its
operating system, network services, storage management, and extensions to multi-core functionality provide important
bus communications services. solution approaches.

5) Run-time environment (RTE) If domain controllers handle the tasks of multiple individual
The run-time environment (RTE) connects the basic ECUs, they need more powerful microcontrollers. Higher clock
software with the application software. frequencies and larger packing density of the components in
the assemblies, however, lead to higher power consumption
and greater waste heat.
B. AUTOSAR Basic-Software
The release 3.1 of the standard consists of 47 defined BSW Multi-core solutions promise to cover the need for
modules, which includes an OSEK-based operating system and computing power. The use of multiple cores in one ECU is
five clusters: more cost-effective and more efficient. The architectures can
be scaled more easily and achieve better performance per watt,
• Mode Management as well as better data throughput.
• Diagnostic Multi-core architectures do not only lead to a more efficient
distribution of control functions, they also offer new
• Memory possibilities in the area of functional safety.
• Communication (including CAN, FlexRay and LIN)
• Firmware 2) Functional safety
Functional safety is becoming one of the most important
C. Modularization topics in automotive development. New functions in the area of
driver assistance and driving dynamics control, as well as
Modularization and the standardized interfaces make functions for passive safety, are usually implemented using
software development more flexible. The development of electronic control units. To ensure safety, these functions must
individual applications no longer depends on the basic software satisfy strict requirements. In vehicle technology, safety-
used. This makes replacement of individual components relevant functions are already subject to the standard by
throughout the product life cycle of the vehicle easier and more International Electrotechnical Commission, the IEC 61508.
efficient. The new ISO 26262 Automotive Safety Standard ("Road
vehicles – Functional safety") to be released in 2011 will
IV. NEW FEATURES IN AUTOSAR 4.0 present an industry-specific variation of that standard.
The basic concepts of the AUTOSAR standard have been Multi-core processor ECUs support different safety
stable since Release 2.1, and in release 3.1 had already reached architectures because they can operate redundantly as well as in
a high degree of maturity. a purely parallel mode with independent operation of the
processor cores. This allows them to guarantee an optimum
Release 4.0 adapts the standard to the new, more stringent
balance between safety and performance.
requirements and provides an important contribution to the
efficient use of resources in ECU development. In addition to hardware safety, the ECU-software has also
an impact on functional safety. The AUTOSAR consortium
Some of the new features will be highlighted below.
addresses the topic of ISO 26262 in the release 4.0 with a series
Specifically the topics of functional safety, multi-core
of new features that allow safety-relevant applications and non-
architectures, and functionality for diagnostic logging and
safety-relevant applications to operate on the same controller.
tracing will be presented in the following.
Support for multi-core architectures has also been added.
1) Multi-Core Architectures For example, software components can be partitioned at the
application software level and can also be executed on different
One possible solution for reducing the material costs in cores within an ECU. The new inter-core synchronization
automotive ECU networks is to use domain controllers. A feature ensures that the execution of partitions runs at the same
single domain controller can handle the functions for an entire speed.
area, for example the chassis or the engine. To increase the reliability of signal transmission between
Domain controllers are the central nodes of the domains, software components, the new AUTOSAR release provides
and are connected via a central gateway or a shared FlexRay end-to-end protection (e2e protection libraries). For example,
backbone. Each domain controller has a large number of signals can be assigned a serial number or a checksum for a
functions and uses sub-bus systems (e.g. CAN or LIN) to cyclical redundancy check (CRC).
connect additional ECUs for less frequently used functions, as 3) Memory protection
well as intelligent actuators and sensors. Clever use of ECUs
Extended memory protection permits the partitioning of the
can save material and weight during vehicle manufacture. This memory and assignment of access privileges to memory and
peripherals. In addition to the operating system, memory takes to correct it. Here, too, software tools are available to
protection now also applies to the run-time environment (RTE). help with real-time monitoring and diagnostic functionality for
basic software modules.
Not all of this newly introduced functionality must
necessarily be used. They can much rather be seen as parts in a
toolbox, from which the user can select items to match the
particular safety requirements.

V. CONFIGURING THE BASIC SOFTWARE EFFICIENTLY

The foundation of the basic software is defined in the
specification. However, that isn't enough for efficient
configuration of the software. AUTOSAR consists of nearly 50
modules of vastly different levels of complexity. That means
that a large number of parameters must be configured. There
are about 90,000 to 100,000 configuration parameters, with up
to five selection possibilities for each parameter. To cope with
the complexity of configuration, there must ways and means of
supporting this process.
EB, with their EB tresos Studio, provides an open, Eclipse-
based graphical development environment in which customer-
specific extensions can also be integrated. Each basic software As of AUTOSAR 4.0, a debugging module new to the basic
component of an ECU is configured, validated, and generated software stack allows signals and raw data to be recorded in the
in the same environment. controller's memory and be transmitted over standard bus
systems like CAN, FlexRay, or Ethernet.
A. Tool support Hardware interfaces like EB's own EB 61x0 are then used
A good tool for the configuration of AUTOSAR modules to read this data on a host PC. Using software tools, the signals
must not only enable the user to configure the individual and data can be displayed graphically, analyzed, and
modules, but also provide some guidance in selecting suitable interpreted in order to localize errors.
parameters. Since there are clear dependencies between the
module configurations, the developer can be guided through 1) Development error trace
the configuration process without him having to know the The Development Error Tracer (Det) is a system service
whole AUTOSAR specification by heart. Taking the located in the service layer. In the debugging module, one can
parameters already configured into consideration, a tool can configure which data should be collected and transmitted to the
make a preliminary selection and only offer the configurations host PC. The EB tresos Inspector can then show not only the
that are valid in combination with the AUTOSAR error number, but also an error description.
specification. At any time during development, it is therefore 2) Run-time environment (RTE) trace
ensured that the resulting basic software is error-free and In the application layer, the communications between
optimized. applications can be checked for errors by monitoring the
If only error-free configurations are permitted right from transmitted and received signals passing through the RTE. The
the start of development, this represents an enormous gain in signals to be monitored must first be configured in the
efficiency. Erroneous configurations need not be laboriously debugging module. For this purpose, EB provides a
cleaned up, and communication between individual modules configuration wizard integrated into EB tresos Studio.
can work correctly because they all comply with the same These signals are displayed on the host PC with their signal
specification. values (EB-specific) and a time stamp.
An optimized setup of the basic software is not only about
avoiding errors, but also about keeping the code size of the 3) Operating system (OS) trace
basic software as small as possible. Not all the parts specified Monitoring in the OS module includes task switches, OS
in AUTOSAR are necessary or practical in every use case. A API and hook calls, and interrupts (EB-specific). In the
tool can help in using only the code the software really needs, software tool, in addition to a task list, statistical data can be
thus consuming less memory and resources. shown on task execution times, periods, and deviations.
4) Future analysis topics
VI. DIAGNOSTICS AND TROUBLESHOOTING Other interesting topics for analysis have also been
identified:
In practice, it is always the case that an error-free module
configuration is not enough. Conflicts often arise during the • Start-up times (EB-specific)
integration and commissioning of the basic software modules
and application software, as well. • Signal propagation delay (EB-specific)
The efficient creation of AUTOSAR-compliant ECU • Online status of the basic software modules (EB-
software also includes the quick detection and correction of specific)
such conflicts. The earlier an error is found, the less effort it
 However, analysis is just the first step; the error must also software and to be able to concentrate their resources on unique
be corrected. That is quickest when the result of the analysis selling points.
can be annotated directly back into the configuration
environment for error correction. The adapted software can While the already existing AUTOSAR releases are going to
then be tested directly on the ECU again. remain under maintenance, the development partnership is
already working to advance the standard. Particular focus is
given to the selective extensions, greater maturity, support for
new hardware mechanisms and the further development of the
VII. CONCLUSION AUTOSAR system. Thanks to the efforts of the development
partners, the standard is guaranteed to stay on top of
AUTOSAR's victory lap can't be stopped. In the future, the technological developments and to adapt to changing
automotive industry and suppliers will increasingly rely on this requirements.
standard to remain flexible in the development and use of ECU