Professorship Computer Engineering

Automotive Software Engineering Praktikum

Prof. Dr. Wolfram Hardt, Norbert Englisch, Felix Hnchen,
Owes Khan
WT 2015/2016

Experiment 4
AUTOSAR

08.12.2015

Content
1.

2.

Basics ............................................................................................................................................... 1
1.1.

The Application Layer .............................................................................................................. 2

1.2.

The Runtime Environment ...................................................................................................... 3

1.3.

The Basic Software .................................................................................................................. 4

1.4.

Methodology ........................................................................................................................... 6

Tool chain ........................................................................................................................................ 7

2.1. SystemDesk .................................................................................................................................. 7
2.2. tresos Studio ................................................................................................................................. 8
2.3. Wind River Compiler..................................................................................................................... 8

3.

Tasks ................................................................................................................................................ 9
3.1. Task 1 Preparation ..................................................................................................................... 9
3.2. Task 2 System Architecture ....................................................................................................... 9
3.3. Task 3 Implementation ............................................................................................................ 10
3.4. Task 4 Simulation ..................................................................................................................... 10

List of References .................................................................................................................................. 10

1. Basics
Before the year 2003 control units were mostly ordered at ancillary companies from the automobile
manufacturers. Often not only the software was ordered but the development of software and
hardware as a whole. Often a kind of basic software is provided by the automotive manufacturer to
the supplier on which the ordered functionality should set up. This situation caused that the
suppliers had to set up on different basic software for each OEM. Out of the view of the OEM it
needs a great effort to develop the basic software and they were forced to order the whole control
unit at an ancillary company. A split-up and a possible cost reduction were impossible. Furthermore it
was impossible to improve a stage of development at low costs, but it was required to order a
redevelopment.
AUTOSAR stands for Automotive Open System Architecture. It is a consolidation of automotive
manufacturer companies, their suppliers and tool manufacturers, which was founded in the year
2003. The partnership has the goal, to avoid regular redevelopment of equal or similar software
components with the help of standardization in the software development for control units, which
ASE Practical: Experiment 4
1

tackle the increasing complexity. To realize this aim, an open standard for the system architecture in
the automotive industry was defined. The system architecture includes a uniform and manufacturer
independent system platform, which shall provide a reduced development effort and for each
manufacturer a quality intensification.
Precondition therefore is the main focus on the following goals:

Modularity of software elements,

Scalability of functions,

Transferability,

Reusability of functions and

Standardized interfaces, to be able to guarantee exchange

An AUTOSAR control unit is divided into several layers (see figure 1):
The application layer, the runtime environment and the basic software. The basic software consists
again of three horizontal layers the service layer, the ECU abstraction layer and the microcontroller
abstraction layer. The following chapters shall deal with the layers in greater detail.

Figure 1: Schematic display of an AUTOSAR control unit (Source: autosar.org)

1.1.The Application Layer

The application layer contains the implemented customer-functionality. In this layer the layer-model
differs to a component-model. The application layer consists of software components, which are
defined by two characteristics:

Description of a software component: The description of a software component is called

software component description and is an xml file which contains amongst others details
of the communication-connections and the interfaces, the body and the internal structure,
time response and of the necessary hardware-resources.
Implementation of the software component: The implementation can be provided as source
code or as object code.

ASE Practical: Experiment 4

2

A software component communicates with its environment via ports, which are defined as
interaction-points from software components. Ports, which have compatible interfaces, can
communicate with each other.
By this strict division between implementation and communication it is possible to build the RTE
independent from its actual functionality. At the generation of the RTE the connection between the
interfaces of the basic software and the interfaces of the software components is build.
Software components are classified in AUTOSAR. It is differentiated between atomic software
components and composition. A composition is simply a logic aggregation of different components,
which can be distributes over several control units. The atomic software components are again
divided into application software component and sensor respectively actuator software component.
The communication between software components can be reduced to two different models:

sender-receiver
client-server

At the sender-receiver communication the information transmission is mostly asynchronous where

the sender distributes the information to one or several receiver. At an information distribution the
receiver decide for their own if they use or discard the offered information. At this kind of
communication the sender neither knows the number of receiver nor their identities. So the sender
cannot control the transmission. At the information transmission via the client-server model in
contrast the server waits for a request from the client, so the communication is initiated by the
client. After the initiation the server processes the requested service and returns the resulting
answer to the client. By knowing the clients the server can respect access rights.

1.2.The Runtime Environment

The Runtime Environment (RTE) forms the intermediate layer between application layer and basic
software. The RTE consists of generated C-code, which realizes the communication between the
software components and between software components and basic software. From the point of view
of a software component it does not matter if it is intra-ECU or inter-ECU communication. At the
inter-ECU communication the information is transmitted to the target device by the communicationstack of the basic software and an available bus system. The so implemented idea is that all software
components from all control units can communicate as if they were connected in one big control
unit. At the intra-ECU communication software components placed in one control unit share
information among themselves. This information exchange must not be direct - it has to be realized
by the RTE. So the outsourcing of one of the communicating software components into another
control unit does not mean any expenditure. Only timings have to be considered at this
reorganization because of differences in the runtime behavior of the software have to be expected
because of transmission delays.

ASE Practical: Experiment 4

3

1.3.The Basic Software

The basic software is an abstraction layer of the hardware and shall prevent the direct access of the
application layer onto the hardware. With the help of the basic software a reusability of the software
components in the application layer, which realize the functionality, is possible. The basic software
consists of several software modules, which have to be configured depending on the requirements of
the application layer and on the hardware preconditions.
The lowermost layer, the hardware level, is named Microcontroller Abstraction Layer (MCAL). This
layer is hardware-dependable and includes the microcontroller driver, the memory access control,
the communication and the I/O driver. The task of the MCAL is to make the layers above hardware
independent. Over the MCAL lays the abstraction layer of the control unit, the ECU abstraction layer.
In this layer all basic components arranged in a control unit are abstracted. Additionally the drivers
for external peripheral components are in this layer. This layer is for the most part hardware
independent. The upper most one is the services layer. Here different kinds of background services
as memory administration, network services or bus communication are provided. The services layer
is independent of the hardware. Due to the layer model of the basic software and the hardware
independency of the uppermost layer of the basic software the software components are
independent of the hardware platform. When changing the hardware platform the lowermost two
hardware dependent layers have to be exchanged but the basic software keeps its interface to the
application layer.
The software modules from the horizontal layers can be divided into the following six different
vertical areas (see Figure 2):

Figure 2:Vertical areas of the basic software of an AUTOSAR control unit

Operating System The operating system is an important basic element of the architecture
and serves as a central control unit for the software components and the basic software.

ASE Practical: Experiment 4

4

Services The term services accommodates diagnosis-, power up-, and power downbehavior as well as memory management.
Communication The term communication means network management and the
description of the communication via bus systems (CAN, FlexRay and LIN).
ECU Abstraction stands for providing a software interface for hardware specific values
from a control unit to uncouple higher situated software layers from hardware dependences.
Microcontroller Abstraction under this term modules are understood which are partial
hardware independent and which prepare the hardware independency for higher situated
modules.
Complex Device Driver A Complex Device Driver is a special function, which has
requirements to the system, which cannot be realized by AUTOSAR modules.

This cursory view onto the basic software can be refined. In Figure 3 the module view of basic
software is shown. In the figure all possible modules are displayed. According to the requirements
from the application layer only required modules are used and flashed to the control unit. Every basic
module can be assigned to horizontal layers.

Figure 3: Modulview of an AUTOSAR control unit

(Source: http://www.eb-tresos-blog.com/solutions/tresos/autosar-basic-software/)

The basic software modules have to be configured accordant to the requirements of the application
layer.

ASE Practical: Experiment 4

5

1.4.Methodology
AUTOSAR provides a general technical approach to be able to develop a system. This approach is
called the AUTOSAR methodology. AUTOSAR does not want to predefine a complete process
description, because of roles and responsibilities are not defined. Rather, the methodology is
described as a work-product flow, which defines the dependencies of activities on work results.

Figure 4: Methodology

The first step is to specify the design or the architecture of the system being developed. That means
to select the target hardware and the software components. Also system restrictions have to be
defined. In the workflow this step is visualized as System Configuration. The following activity is
called Configure System. That means to map the components by regarding timings and resources
onto control devices. The result is a System Configuration Description, which contains the
complete system information as bus-mapping, topology and mapping of software components on
control units. The following steps are processed for each control unit for its own, thus no longer for
the complete system. The activity Extract ECU-Specific Information extracts the information from
the system configuration description, which is required by a specific control unit. This specific
information is stored in an ECU Extract of System Configuration. The following activity Configure
ECU feeds all the necessary information, task scheduling, necessary basic software modules,
configuration of the basic software and allocation from runnables to tasks, to the control unit. This
information is stored in an ECU Configuration Description. In the last step Generate Executable a
flashable file, which contains the basic software, the RTE code and the software components of the
application layer, is generated on the basis of the former generated ECU Configuration Description.
The basic process of an AUTOSAR-compliant software development requires that first one software
component is developed. After specifying on which control unit this software component shall be
processed, the basic software and the necessary modules are integrated and configured
corresponding to the requirements of the software component. After repeating this step for all
software components of the control unit, the RTE is generated on the basis of the interfaces of the
software components and the interfaces of the basic software modules which communicate with the
RTE.

ASE Practical: Experiment 4

6

2. Tool chain
At the professorship Computer Engineering a tool chain exists for the development of software for
AUTOSAR-control units. This tool chain consists of 3 tools (see figure 5):

SystemDesk from the company dSpace

tresos Studio from the company Elektrobit
diab compiler from the company Wind River
DBC-File

dSpace SystemDesk

Basic software

EB tresos Studio

Wind River diab compiler

Figure 5: Tool chain for the development of AUTOSAR control units

2.1. SystemDesk
The program SystemDesk from the company dSpace is a software-architecture tool to support the
development of distributed automotive electric-/ electronic systems. SystemDesk allows a model
based development of control unit-software and displays their components and communication
graphically. The modeling system is built up corresponding to the AUTOSAR standard. Beside the
integration of control unit code RTE code can be generated by SystemDesk also (in the experiments
we do not use this RTE generator). To detect error sources in an early development stadium
individual software components or a control unit interlocking as well can be simulated and tested.
Apart from a graphic user interface SystemDesk can be controlled by an API.
We use SystemDesk to generate AUTOSAR-compliant interfaces for software components. After
defining the interfaces of a software component, they can be exported as XML-files. These XML-files
have to be imported into tresos Studio.
Figure 6 shows a screenshot from SystemDesk. Three system components (TurnSwitchSensor,
WarnLightSensor und ForntLeftActuator) and composition (Indicator) can be seen. The applications
communicate via ports, symbolized by the triangles at the components. The triangles stand for
communication as sender / receiver.

ASE Practical: Experiment 4

7

Figure 6: Screenshot of SystemDesk

2.2. tresos Studio

The EB tresos Studio from the company Elektrobit belongs to the EB tresos product family, in
which tools for the development of AUTOSAR-software are grouped. The EB tresos Studio is an
eclipse-based application for the configuration and generation of the basic software components of
the EB trsos AutoCore. This tool follows the AUTOSAR standard.
We use the tresos Studio to configure the basic software modules for the DEMO-board S12XEP100.
By the import of the XML files out of the SystemDesk, a large part of the extensive configuration is
done automatically. After the remaining configuration steps are finished the RTE is made by the RTEgenerator from the tresos. Afterwards the application, the RTE and the basic software are compiled
and provided as an ELF-file. This elf-file can be flashed onto the DEMO-board by the CodeWarrior.

Figure 7: Screenshot of tresos Studio

In figure 7 the tresos studio is shown. In the left area there is the project list. In each project is one
ECU in which all the imported basic software modules are shown. With double-click on a module it
can be configured (right area).

2.3. Wind River Compiler

The Wind River diab compiler is used as compiler as in former experiments.

ASE Practical: Experiment 4

8

3. Tasks
In this experiment, the basics of AUTOSAR are to be understood. This gives an overview of the inner
AUTOSAR-context. It includes the definition of system components as well as the coordination of
application and basic software with the operating system.
Aim of the experiment is to build an easy example, which is similar to the former units/experiments.
But in contrast to the former ones this one should be AUTOSAR-compliant. Thereby the significant
differences between AUTOSAR-compliant and not-standard-compliant implementations should be
made aware.
A simple light control has to be implemented in this unit. It consists of two software components
which exchange data. Depending on a light value and a light switch a specific output should be
generated.

3.1. Task 1 Preparation

Read and understand the provided SystemDesk tutorial. You need this knowledge to complete all
tasks.

3.2. Task 2 System Architecture

Create a system architecture which contains two software components. All components should be
mapped to one ECU. Name the components ExtLiMgr (Exterior Light Manager) and LiAdpAut
(Autolight Adapter).
The Autolight Adapter is notified about the position of the light switch and processes the outside
light value when the light switch is located at the Auto position. Depending on the light switch or
the light value the Autolight Adapter controls the daytime running light and the low beam. The
LiAdpAut-Component should have 3 RPorts and 2 PPorts. One RPort is used to receive a signal
when the light switch is located at the Auto position. Another RPort is used to signalize that the
switch is located at the low beam position. Both ports receive 1 bit where a logical 1 stands for the
activation of the specific functionality. Beside these two RPorts the last RPort is used to get an 8 bit
light value. The PPorts provide the activation signals for the low beam and the daytime running light.
Each PPort sends 1 bit where a logical 1 activates the daytime running light or the low beam.
Beside the Autolight Adapter the Exterior Light Manager has to be created. The ExtLiMgrComponent needs 3 RPorts and 3 PPorts. Two of the RPorts should be connected to the PPorts of the
Autolight Adapter. The last PPort is left unconnected and receives the operation mode of the car.
Depending on the operation mode the car lights should be turned on or off. The operation mode is
represented by 1 bit which indicates, if the car is switched on (logical 1) or switched off (logical 0).
The PPorts activate the low beam, the daytime running light and the low beam indication which is
displayed in the instrument cluster. These ports stay unconnected.
Every software component should contain one runnable. Thereby the runnables have to be triggered
every 10 ms.
Note: Think about the interfaces to be used. Two connected ports must use the same interface.

ASE Practical: Experiment 4

9

3.3. Task 3 Implementation

Implement the created architecture. For the implementation a short behavioral description is given
below.
If the car is switched off no lights may be turned on. So the light switch mustnt have any effect on
the lights. If the car is operating the activated light depends on the light switch position and the light
sensor value. Whenever the light switch is located at the Auto position the light sensor is used to
switch on the lights. If the light value falls below 100 the low beam should be switched on. In case
of a light value greater than 100 the daytime running light should be activated. When the light
switch stands on low beam the low beam has to be turned on regardless of the light value. The
daytime running light and the low beam mustnt be activated at the same time. Last if the light
switch is neither on the low beam position nor on the Auto position all lights should be switched
off.

3.4. Task 4 Simulation

Simulate your architecture with SystemDesk. To simulate the architecture a test environment is
given. Import the provided osa-file to your simulation setup and connect all unassigned ports of the
architecture to the test environment. After setting up the test environment run the simulation. If all
test cases are successfully passed, the architecture is correctly implemented. Otherwise the
implementation must be edited.

List of References
(1) JRG SCHUFFELE, THOMAS ZURAWKA: Automotive Software Engineering, 2010
(2) NORBERT ENGLISCH: Methode zur Absicherung der Basissoftware von AUTOSAR
Steuergerten, 2009
(3) OLAF KINDEL, MARIO FRIEDRICH: Softwareentwicklung mit AUTOSAR: Grundlagen,
Engineering, Management in der Praxis, 2009

ASE Practical: Experiment 4

10