Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

Evaluation Environment for
AUTOSAR–Autocode in Motor
Control Units
Robert BOSCH GmbH
DGS–EC/ESB
Diploma Thesis
Mike Gemünde
July, 2008
Supervised by
Prof. Dr. Klaus Schneider
Peter Bolz
Embedded Systems Group
Department of Computer Science
University of Kaiserslautern

Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und ohne fremde
Hilfe verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und
die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe.
Kaiserslautern, den 30. Juli 2008
Mike Gemünde
iii

Danksagung
An dieser Stelle möchte ich denjenigen danken, die mir diese Arbeit ermöglicht haben.
Zum einen möchte ich Herrn Prof. Dr. Schneider danken, der die Diplomarbeit von
der universitären Seite betreut hat. Zum anderen geht mein Dank auch an Herrn
Peter Bolz, für die Betreuung von Seiten der Firma BOSCH GmbH und für das sehr
angenehme Arbeitsklima.
v

Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 AUTOSAR 3
2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 AUTOSAR Software . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Basic Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 AUTOSAR basic approach . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 AUTOSAR Operating System . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3 Software Components . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.4 Internal Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.5 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Virtual Functional Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8.1 Configuration of the Example . . . . . . . . . . . . . . . . . . . 17
2.8.2 The Generated Source Code . . . . . . . . . . . . . . . . . . . . 19
2.8.3 Implementing the Runnables . . . . . . . . . . . . . . . . . . . 22
2.8.4 Conclusion of the Example . . . . . . . . . . . . . . . . . . . . 23
2.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 MEDC17 25
3.1 ERCOSEK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Basic Software and Application Software . . . . . . . . . . . . . . . . . 26
3.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Tasks and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vii

Contents
4 Goals 29
4.1 Background of the Topic . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 Differences of MEDC17 and AUTOSAR . . . . . . . . . . . . . 29
4.1.2 Integration of AUTOSAR Software in MEDC17 . . . . . . . . . 30
4.1.3 Development of RTE Generators . . . . . . . . . . . . . . . . . 32
4.1.4 Current Situation (before Diploma Thesis) . . . . . . . . . . . 32
4.2 Topic of the Diploma Thesis . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Main Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3 Available Resources and Tools . . . . . . . . . . . . . . . . . . 33
4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Analysis and Design 35
5.1 Test Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Components of the Environment . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 RTE Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.3 RTE Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.4 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.5 Test Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.6 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.7 Test Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.8 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Configuration of the Components . . . . . . . . . . . . . . . . . . . . . 42
5.4 Structure of the File System . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 The Directory “pool” . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.2 Resource Directory . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.3 Configuration Directory . . . . . . . . . . . . . . . . . . . . . . 46
5.4.4 The Directory “perform” and Test Directories . . . . . . . . . . 46
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Implementation of the Test Environment 49
6.1 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . 49
6.1.2 Java and SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.3 XML Files for Storing the Configurations . . . . . . . . . . . . 49
6.1.4 Perl for Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 The Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1 RTE Generator Configuration View . . . . . . . . . . . . . . . 52
6.2.2 Test Template Configuration View . . . . . . . . . . . . . . . . 52
6.2.3 Perform View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 Implementation of the GUI with Java . . . . . . . . . . . . . . . . . . 56
6.3.1 Logging for the Application . . . . . . . . . . . . . . . . . . . . 56
6.3.2 Basic Data Structures . . . . . . . . . . . . . . . . . . . . . . . 57
viii

Contents
6.3.3 Perform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.4 Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.3.5 Configuration Widgets . . . . . . . . . . . . . . . . . . . . . . . 63
6.3.6 Perform Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Implementing Tests with Perl . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.1 Utilities for Test Scripts . . . . . . . . . . . . . . . . . . . . . . 68
6.4.2 Scripts for the Test Types . . . . . . . . . . . . . . . . . . . . . 69
6.5 XML Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6 Launching the Test Environment . . . . . . . . . . . . . . . . . . . . . 71
6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7 Test Cases 75
7.1 Creating Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1.1 Tests to Accept or Reject . . . . . . . . . . . . . . . . . . . . . 75
7.1.2 Code Review of Tests . . . . . . . . . . . . . . . . . . . . . . . 76
7.1.3 Tests for the PC–OS . . . . . . . . . . . . . . . . . . . . . . . . 76
7.1.4 Tests for Integration in MEDC17 . . . . . . . . . . . . . . . . . 77
7.2 Example: Mode Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2.1 Configuration of the Mode Example . . . . . . . . . . . . . . . 79
7.2.2 Implementation of the Mode Example . . . . . . . . . . . . . . 80
7.2.3 Modification of this Example . . . . . . . . . . . . . . . . . . . 84
7.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.3 Example: DataReceivedEvent in MEDC17 . . . . . . . . . . . . . . . . 85
7.3.1 Configuration of the MEDC17 Example . . . . . . . . . . . . . 85
7.3.2 Implementation of the MEDC17 Example . . . . . . . . . . . . 86
7.3.3 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 Found RTE Generator Bugs . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4.1 Implicit API buffers copied twice . . . . . . . . . . . . . . . . . 88
7.4.2 DataReceivedEvent without DataReceivedEvent . . . . . . . . 89
7.4.3 Header Files for Composition not created . . . . . . . . . . . . 90
7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8 Conclusion 91
8.1 Reached Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.2 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.3 Impressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A Example 93
B Requirements of the Functional Specification 99
B.1 Main Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.3 Layout and Organization . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.4 Provided Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ix

Contents
Abbreviations 105
Bibliography 107
x

Chapter 1
Introduction
1.1 Motivation
The increasing complexity of embedded systems found the way into automotive development
some years ago. The number of electronic control units (ECU) has increased
to about 70 and they are connected by about 5 system buses per car [11]. However,
not every component comes from the same manufacture, instead the whole hardware
and software system of a car is composed from different suppliers.
The increasing complexity has to be handled together with the needs to be compatible
with other manufactures to keep the development effort down. To achieve
these goals there was still an attempt to standardize software done with OSEK/VDX
[13]. These first reached goals are now continued by the Automotive Open System
Architecture (AUTOSAR) [9].
However, the migration to such a standard has to be done and since there is a lot
of existing software, which should not be discarded, a way must be found, to do such
a migration in little steps.
1.2 Related Work
For embedded system, automatic code generators play a significant role. They provide
the creation of code from a configuration or a model and prevents errors from hand–
written code. However, it is required, that the code generators contain no errors and
produce correct code, which reflects the configuration.
For developing software for embedded devices the modeling tools ASCET[20] and
MATLAB/Simulink/Stateflow[21] exist. ASCET provides its own code generator to
create source code from the model. The software TargetLink[23] from dSPACE is
typically used to generate code from MATLAB/Simulink/Stateflow models.
The tool MTest[22, 17], which is also provided from dSPACE, is used to test the
models in different development phases. Other works deal with the testing of the code
generators itself[24, 26, 25]. However, these works assume that the semantic is defined
and the behavior of the generated code can be compared to that of the model. The
works also do not handle the aspect of integration of the generated code into another
enviroment.
Another tool for testing embedded software, which is also based on XML configurations,
is described in [18, 10]. However, it handles testing of source code and does
1

Chapter 1 Introduction
not allow to call a code generator before the test execution.
1.3 Outline
This work starts with an introduction to AUTOSAR in chapter 2. There is an overview
given and relevant mechanism and features for this work are described. Chapter 3
gives a short overview of MEDC17, which is the currently used platform of BOSCH
for software development. Together with these preliminary explanations, the actual
topic of this diploma thesis is described in detail in chapter 4.
Afterwards the real work of this diploma thesis is explained. An evaluation environment
is created and it is in principle divided by an test environment and test
cases. The behavior and structure of the test environment is described in chapter 5.
The implementation, which is used to achieve this behavior, is explained in chapter 6.
The test cases itself together with some guidelines for creating tests are addressed in
chapter 7. A conclusion of the work is given in chapter 8.
2

Chapter 2
AUTOSAR
Automotive Open System Architecture (AUTOSAR) is a consortium of automotive
manufactures including BOSCH, which tends to establish a standard 1 for automotive
software engineering. The first discussions were done in 2002 and the partnership was
signed in 2003. One idea behind AUTOSAR is “Cooperate on standards, compete on
implementation”[8] and it is aimed to solve some principal goals:
• decoupling of software from underlying hardware
• development of software without dependency of the system structure
• sharing of software between manufactures
• relocating of software to a different Electronic Control Unit (ECU) in a vehicle
• better tool support for the development process and even compatible tooling
between the manufactures
• replaceability of hardware components without much effort to customize the
software
This is achieved with the standardization of all major system functions and exchange
formats. Additionally some parts of the hardware and the software are encapsulated to
provide high reusability, scalability and flexibility. The standardization is done stepwise
by publishing different releases. The first release with number 1.0 was published
in 2005.
Not every detail of AUTOSAR is of interest for this work and a complete description
would go beyond the scope. The next sections give an overview of the architecture
and the basic approach and it is based on [8]. The for this work significant parts are
described in more detail in the following sections. This description is based on the
AUTOSAR release 2.1, which is mainly used in this whole work. The newer release
3.0 is already published, but there doesn’t exist enough tools yet, which supports this
release.
1 Currently AUTOSAR is just a de–facto standard
3

Chapter 2 AUTOSAR
2.1 Architecture
Basically AUTOSAR is a global approach to the software development of a whole
vehicle, but this section just describes the software architecture for one ECU 2 . The
overall view is described later. The architecture is shown in figure 2.1 and it covers
the relations between all software running on one ECU. At the bottom of this diagram
the ECU with the complete hardware is located. The other big layer is the Runtime
Environment (RTE), which is arranged at a higher level. Everything between the RTE
and the hardware is called Basic Software (BSW) and this is the infrastructural basis
to run other applications. The AUTOSAR software is arranged above the RTE layer
and contributes the functional part of the software.
Application Software
Component
AUTOSAR Interface
Standardized
Interface
Operating
System
Standardized
Interface
Actuator Software
Component
AUTOSAR Interface
Standardized
AUTOSAR Interface
Services
Standardized
Interface
2.1.1 AUTOSAR Software
Sensor Software
Component
AUTOSAR Interface
Runtime Environment (RTE)
Basic Software
Standardized
Interface
Communication
Standardized
Interface
ECU Hardware
AUTOSAR
Software
AUTOSAR Interface
ECU Abstraction
Standardized
Interface
Standardized
Interface
Microcontroller
Abstraction Layer
Figure 2.1: AUTOSAR architecture diagram
Application Software
Component
AUTOSAR Interface
AUTOSAR Interface
Complex Device
Drivers
The AUTOSAR Software is realized by several Software Components (SWCs), which
provide the functional behavior of the system. The communication between SWCs
and other components or with parts of the BSW is done through the RTE 3 . In the
diagram is a distinction of two kinds of SWCs made:
2
An ECU is not just a microcontroller, it additionally consists of peripherals as e.g. flash–ROM,
controller for bus systems or ASICs.
3
This also implies communications with components on other ECUs
4

2.2 AUTOSAR basic approach
AUTOSAR Software Component The AUTOSAR Software Component is independent
from the underlying hardware. That is done with the abstraction through
the RTE and BSW.
Sensor / Actuator Software Component This component depends on sensors
and actuators which are available at the ECU. Due to performance such a component
runs on the ECU to which the sensors and actuators are physically connected. Besides
it is as independent as an AUTOSAR Software Component.
2.1.2 Basic Software
The BSW only provides infrastructural functionality to run the SWCs. In the following
is an overview of the several parts of the BSW given.
Services This provides some basic services like e.g. memory and flash management
and diagnostic protocols.
Communication This are Communication stacks for inter-ECU communication like
e.g. Controller Area Network (CAN) ([12]), Local Interconnect Network (LIN) ([2]),
FlexRay ([1]), etc.
Operating System The operating system provides priority based scheduling of
tasks and protection mechanisms. It is described in section 2.3 in more detail.
Microcontroller Abstraction Layer (MCAL) To make the higher software layers
independent from the microcontroller the MCAL is used. It avoids direct access
to registers from higher–level software and abstracts features like e.g. digital I/O, or
A/D converters. It is aimed to replace the microcontroller with another one without
changing anything at higher–level software. This assumes that a MCAL is available
for the substituting controller.
ECU abstraction Since the MCAL just abstracts the microcontroller the ECU
abstraction does the same for the whole ECU.
Complex Device Drivers Due to performance reasons the complex device drivers
directly access the hardware.
2.2 AUTOSAR basic approach
After the architecture is clarified, this section takes a look at the basic approach of
AUTOSAR for bringing software to ECUs. In AUTOSAR this is done in multiple
steps. The approach shown in figure 2.2 handles the whole view of the complete system
with multiple ECUs. The SWCs are developed using well defined interfaces and
they are connected through the Virtual Functional Bus (VFB). This is an abstract
connection, that makes it possible for the components to interact. It does not yet
say something about the later location of the SWC in the whole system and hides
5

Chapter 2 AUTOSAR
the hardware dependency and the topology of the different ECUs and communication
buses. To specify the requirements of SWCs on the hardware and infrastructure an
XML–based configuration is used, which says what operations with which data elements
are possible and what requirements to the infrastructure (in form of functions
and resources) are needed to run this SWC. It is also described, whether the SWC is
available as source code or as object code.
SWC1 SWC2 SWC3
ECU descriptions
SWC1
ECU1
RTE
BSW
SWC3
Tool supporting
deployment of SWC
ECU2
SWC2
RTE
BSW
. . .
SWCn
Virtual Functional Bus
. . .
System constraints
ECUm
SWCn
RTE
BSW
Figure 2.2: Basic AUTOSAR approach
Together with the SWC description, a description for the system and for the ECUs
must exist. The system description specifies the structure and constraints of the whole
system. The ECU description defines the resources and functions of every ECU. Together
with this descriptions it is possible to map the SWCs to several ECUs, at
which the RTE encapsulates the SWCs from everything else. This means that the
RTE provides the implementation of the VFB and hides the implementation of the
communication for the SWCs. The components don’t get noticed about the communication,
especially if it is an intra– or inter–ECU communication. The BSW at the
bottom of each ECU provides the infrastructural functionality, as seen in the previous
section.
The idea is that the SWCs can be developed independent from the hardware and
from other components as long as they use the standardized interface and the description
of the components is provided. With the VFB a complete separation of the
applications and the infrastructure is provided. The SWCs can then be exchanged
or integrated from other suppliers. The generation of the RTE is tool supported and
6

2.3 AUTOSAR Operating System
will be done automatically. A tool called the RTE generator is used, which is the
main focus of this work. Such tools are not provided by the AUTOSAR consortium
itself, but they are provided by tool–suppliers. Several different implementations of
AUTOSAR tools, especially of RTE generators exist, but they shall all be compliant
with the AUTOSAR standard.
2.3 AUTOSAR Operating System
In terms of a normal personal computer, the whole BSW would be called the operating
system. However, for automotive architectures a strict distinction is done. The operating
system is just a lightweight system, which provides scheduling of tasks, event
mechanisms and resource mechanisms. The resource mechanisms are used for the handling
of mutual exclusive execution in critical sections and they have nothing to do
with physical resources.
AUTOSAR defines a standard for an operating system [4], which is based on the
OSEK–OS standard [14]. One main attribute of this operating system is, that it is
statically configured and typically the operating system is compiled and linked with all
other software. The configuration is done with the OSEK Implementation Language
(OIL), which is described in [15], until release 2.1. For release 3.0 this configuration
has changed to an XML format [5] and so XML based descriptions are used for the
whole AUTOSAR standard. Some basic features of the operating system are described
in [4]. These are:
• statical configuration
• real–time performance
• runs on low–end microcontroller without external resources
• priority based scheduling of tasks
• protection mechanisms for memory access and timing
The AUTOSAR specification for the operating system just mainly describes differences
to OSEK–OS. So the following explanations are based on the OSEK–OS specification
([14]).
2.3.1 Tasks
Like other operating systems, OSEK–OS supports multitasking. The scheduler of the
operating system provides a priority–based scheduling of tasks. A task defines an
execution of instructions, which are done in a sequential order. The different tasks
are executed concurrent and asynchronous by the scheduler. OSEK–OS differentiates
between two kinds of tasks, which are explained in the following.
7

Chapter 2 AUTOSAR
Basic task Basic tasks release the processor, only if they terminate, the scheduler
switches to a task with a higher priority or an interrupt arises and an interrupt service
routine is called.
Extended task The extended tasks provide in addition to the basic tasks the possibility
to release the processor without termination and wait for an event. After the
event occurs, the extended task can be waked up by the scheduler again. This is
called a wait–point and can be used to synchronize tasks. Basic tasks can just be
synchronized on the start or the end.
ready
start
activate
release
suspend
start
preempt
wait
terminate
wait
Figure 2.3: States of a Task
The scheduler works priority–based and a task can reach the states, which are shown
in figure 2.3. The state “wait” can only be reached by an extended task. Only one
task can be in state “run” at a time. “start” and “preempt” are the transitions, which
are performed by the scheduler to start or defer a task. The “terminate” and “wait”
transitions are done by the task itself. The “release” transition for an extended task
is done by the operating system, if the event, which the task waits for, arises. The
“activate” transition can be done in several ways. The operating system can switch
the state of the task, if it is configured to be triggered by an operating system event
and the event occurs. However, the transition can also be done with the operating
system functions ActivateTask() or ChainTask(). These functions can be called from
every routine including the task itself.
Due to the wait–points the scheduling and handling of an extended task takes more
resources.
2.3.2 Events
Extended tasks can own one or more events. This are the events, the extended task
can wait for. An event can be set from every other routine and it has to be cleared
8
run

2.4 Basic Concepts
by the owning task. If the task waits for an event and the event is set from another
routine, the task will switch into the state “ready”. At the beginning of an extended
task, that means at the transition from “suspended” to “ready”, all events of this task
will be cleared from the operating system.
2.3.3 Resources
The resources of the operating system provide mutual exclusive access of tasks with
different priorities to shared resources. If a task occupies a resource, no other task can
do the same. So the task have to wait until the resource is released. That this waiting
cannot only be done in an extended task, the priority ceiling protocol is used. This
protocol increases the priority of the task that occupies a resource. This is done during
the time, the resource is accessed. The priority is increased to the highest priority of
all tasks that can also access this resource. So it is prevented that another task, which
can also access the resource, runs during this time.
2.4 Basic Concepts
Some basic concepts and terms are now described in more detail. They are necessary
for this work and to understand the RTE and the generating of the RTE. This description
is based on the documents [6, 7, 3]. The second document is a specification
of the VFB for release 3.0, because a version of this document for 2.1 does not exist.
However, it contains the same mechanisms as release 2.1 and something more that is
not used here.
2.4.1 Types
To use data types in the software and especially with AUTOSAR mechanisms like the
communication, this data types have to be specified. The simplest types that can be
specified are the primitive types, which can be integers, strings, characters or Boolean
types. This types are additionally specified with a range (or a length for strings), that
says which values are possible. Existing types can be combined to composite data
types, which are an array or a record.
2.4.2 Ports
Ports are the mechanism of software components to communicate between each other.
They define interaction points of a SWC. Several kinds of ports are distinguished. A
port is either a required port or a provided port. A provided port offers data elements
or services, a required port is the counterpart, which uses the data elements or services.
This distinction describes the direction of the communication. Another classification is
the kind of the communication, which is divided into sender–receiver and client–server
9

Chapter 2 AUTOSAR
communications. These are described in the following along with their symbols 4 to
draw such a connection. The symbols are shown in figure 2.4.
sender receiver client server
Figure 2.4: Symbols for ports
sender–receiver The sender distributes data to every receiver. Additionally, a
mode manager can notify mode switches to the receivers. The direction of the communication
is given through the arrow. Connections of the form 1 : N and N : 1 are
possible. M : N connections are explicitly not allowed because of the complexity of
the implementation. One sender port can send multiple data elements and multiple
modes. The sender is in this case the provided port, the receiver is the required port.
client–server The server provides an operation which can be invoked by the client.
So the server is accessed via the provided port for this case, whereas the client is called
via the required port. The client can send values and the server can return values.
Here only connections of the form N : 1 are possible. One server port can provide
multiple operations. An operation receives multiple values, does a calculation and
then it can return multiple results.
In both cases a required port, this is a receiver or a client, has to be connected. On
the other hand a provided port, this means analogous a server or sender, can be left
unconnected.
The data elements and modes or the operations that are provided via a port are
specified by the interface of this port. They may be used to create multiple ports with
the same interface for one or different SWCs.
Ports with the same or a compatible interface can be connected. Compatible means
that the provided port at least provides the operations or data types as for the required
port specified. The provided port can provide more data or operations, which is not
used by the required port.
2.4.3 Software Components
The SWCs are the applications which run on an AUTOSAR infrastructure. They
interact only through ports with other components. Thus, they can be developed
independent from the hardware or from other components.
4 To come back to the release discussion, the introduced symbols are specified in release 3.0. The
older release 2.1 uses other symbols, but the newer are much easier to draw and the meaning is
clearer
10

Atomic Software Components
2.4 Basic Concepts
An atomic Software Components is a basic component, which provides an own behavior.
The behavior is given with the later described internal behavior. An atomic
Software Component can provide ports to allow communications with other components.
Compositions
Composition
SWC1
SWC2
SWC3
Figure 2.5: Composition of SWCs
Compositions are another form of a SWC which consists of other components. The
components are aggregated to create a new component. Figure 2.5 shows such a
composition of three SWCs. The ports from the components can be connected between
each other or with ports of the composition. A connection between components inside
the composition is called an assembly connector. A connection from a contained
component to a port of the composition is called a delegation connector.
A composition of components just provides the behavior that results by the connections
of the contained components. It does not add an own implementation or own
functionality.
2.4.4 Internal Behavior
A component can not only provide ports, there also have to be some functionality
behind it. This is done by specifying an internal behavior for an atomic Software
Component. The internal behavior consists of several parts.
Runnable Entities
The functionality of an atomic Software Component is implemented in the form of
runnable entities or in short runnables. Runnables are executed when a special event
arises and they are implemented in form of a C or C ++ function. A runnable can
access the ports of the SWC. The description for this is done with different points or
accesses.
DataSendPoint It describes an access to a sender port and a concrete data element
of that port. The value, which is written to the port, is directly available.
11

Chapter 2 AUTOSAR
DataReceivePoint It describes an access to a client port and a concrete data element
of that port. The value, which is returned, is the current value.
DataWriteAccess It describes an implicit access to a sender port and a concrete
data element of that port. The runnable can access the port multiple times, but just
the last written value will be available at the port after termination of the runnable.
DataReadAccess It describes an implicit access to a receiver port and a concrete
data element of that port. The runnable can access the port multiple times during
one execution and will get the same value every time.
AsynchronousServerCallPoint A runnable calls a server with an asynchronous
call through a client port. It has to be specified, which client port and which provided
operation is used. An asynchronous call returns directly for the invoking runnable.
The result is not available by now, instead it has to be fetched later by another call
when the operation is finished.
SynchronousServerCallPoint A runnable calls a server with an synchronous call
through a client port. It has to be specified, which client port and which provided
operation is used. A synchronous call returns not until the operation is finished and
the result is available.
WaitPoint A special item in this enumeration is the WaitPoint. All other items
refers to a port and a special data element or operation of the port. Instead of that
a WaitPoint refers an RTE event for which can be waited. The call does not return
until the event or a specified timeout occurs.
It can be seen in this enumeration, that the accesses are described in very detail. So
e.g. a runnable can read a data element of a port directly and another data element
of the same port with an implicit access.
RTE Events
For the RTE some events can be specified. An event can either trigger a runnable or
wake up a WaitPoint. The following events are defined by AUTOSAR.
TimingEvent For this event an interval and an offset has to be specified. So the
points in time are given at which the event occurs.
DataReceivedEvent This event is specified for a receiver port and for a concrete
data element of the port. It occurs when new data is received.
DataReceivedErrorEvent This event is also specified for a receiver port and for
a concrete data element of the port. But it occurs when data is invalidated for a
communication.
DataSendCompletedEvent The DataSendCompletedEvent have to be specified
for a sender port and a DataSendPoint. It occurs when the sending of a data element
is completed.
12

2.4 Basic Concepts
OperationInvokedEvent This event is called when an operation for a server port
is invoked. The event is specified with the port and with the operation for which it
should occur.
AsynchronousServerCallReturnsEvent If an asynchronous call is used to invoke
an operation on a server, the result of the server call can be fetched at later time. This
event shows, that the server is finished and the result is available. It is specified for a
client port and an operation, which is called by the client.
ModeSwitchEvent For this event a mode and an action “entry” or “exit” has to
be specified. The event arises when the specified mode is entered or exited, depending
on which action is specified.
Every event can trigger a runnable, but not every event can wake up a WaitPoint.
The events, which can wake up a WaitPoint, are DataReceivedEvents, DataSendCompletedEvents
and AsynchronousServerCallReturnsEvents.
Inter Runnable Variable
Ports define the interaction between SWCs, or more precise the interaction between
the runnables of the SWCs. For runnables of one SWC another mechanism for internal
communication exists. These are the Inter Runnable Variables (IRVs), which can be
accessed by the runnables. Runnables could also use global variables for this internal
communication, but with IRVs protection mechanism are provided by the RTE for
concurrency.
Exclusive Area
Exclusive Area are a similar mechanism to the operating system resources described in
section 2.3.3. Exclusive areas just provide mutual exclusive access for the runnables of
one SWC, but not for the whole task. Exclusive areas can be implemented with operating
system resources, but this is no requirement. There can be other implementation
possibilities specified like e.g. interrupt–disabling.
2.4.5 Modes
Modes have the simple purpose that components can provide a different behavior
depending on which mode is active. The mode can be distributed from a component
through ports to other components. Typical modes for a motor control unit are
“Start”, “Drive” and “Stop”.
A mode has to be distributed through a port, because there must be the possibility
to provide modes to other ECUs. RTE Events can be disabled in a mode. Then
the event is prevented, if a special mode is active. This makes it possible to execute
runnables just in one mode. A ModeSwitchEvent responds directly to a mode switch.
It triggers a runnable if a special mode is entered or left. These runnables can be used
to clean up the old mode or prepare the new mode.
13

Chapter 2 AUTOSAR
mode
A
mode
dependent
runnables
mode
switch
indication
OnExit
runnables
OnEntry
runnables
transisiton
mode independent runnables
time
Figure 2.6: Sequence of a mode switch
mode
dependent
runnables
mode
B
The AUTOSAR specification defines a concrete sequence for a mode switch. This
sequence is shown in figure 2.6 with a switch from mode “A” to mode “B”. If a mode
switch is indicated, first all runnables that depend on the active mode have to be
finished. After that, the OnExit runnables for mode “A” are executed. Then the
OnEntry runnables for mode “B” are executed. Afterwards the new mode “B” is
reached and the runnables depending on this mode can be executed. However, this
depends on the events, triggering these runnables. Runnables that do not depend on
a mode are not affected from the mode switch.
In the diagram it can be seen, that after the mode switch indication it has to be
waited for the termination of all mode depending runnables that depend on mode “A”.
For this reason the AUTOSAR specification prohibits that a runnable, which depends
on a mode, can have a WaitPoint.
2.5 Virtual Functional Bus
An abstract mechanism for connecting SWCs called the VFB has been introduced
in the section 2.2. It allows to develop SWCs independent from other hardware and
software by providing a defined interface. For this interface, the ports are defined and
can be used from the functions in the component. At the VFB level, this ports can
be used to connect components by connecting compatible ports.
In figure 2.7 is a connection of some components shown. This represents the functional
part of the system, independent from the architecture or infrastructure which
is needed to execute this system.
14

SWC1 SWC2 SWC3
2.6 Configuration Files
. . .
Figure 2.7: VFB diagram
SWCn
Virtual Functional Bus
2.6 Configuration Files
To do the mapping to the ECUs, which is described in section 2.2, it is necessary to
know a lot of information about every part of the AUTOSAR system. This means
the precise description of a SWC for each mechanism described in section 2.4 and
the configuration of the ECUs and the system. This configuration is done in an
XML format for a defined XML scheme. The concrete XML scheme depends on the
AUTOSAR release. For one release some different scheme versions can exist, as a
result of bug fixes and updates.
AUTOSAR distinguishes two cases of specifications. The specification of a SWC
together with its internal behavior is called a SWC description. Everything that goes
beyond the scope of a single component is called a configuration. Together with a
SWC description it is possible to deliver the component to suppliers.
AUTOSAR does not specify, which information has to be put in which files. Instead
the structure of the files is flexible that the whole configuration can be put in one file
or every object can have its own file. To reference an object in an XML file a unique
path is used, which consists of the package names that have to traversed in the XML
tree to reach this object. An example is given in section 2.8.
2.7 Runtime Environment
The RTE is the implementation of the VFB for one specific ECU. It provides the
environment which is needed for the SWCs to run on that ECU and communicate with
other SWCs. The RTE encapsulates the communication between the components, so
that they don’t know were the counterpart of the communication is located. This
means, that the communication with a component on the same ECU is done directly,
whereas the communication with a component, which is located elsewhere, is done
through a communication mechanism like CAN or LIN. But the RTE does more than
just provide the connections of the VFB. It additionally ensures that runnables of a
SWC are triggered through the configured events, provides consistency for IRVs and
ensures the effect of exclusive areas. Or in short, it provides the functions for all the
configured mechanisms.
As earlier described the RTE is auto generated from the RTE generator but this is
15

Chapter 2 AUTOSAR
not absolutely true. Some parts of the RTE are fixed and have not to be generated
every time. This files are called the RTE library. However they are delivered with the
RTE generator to cooperate with the generated code.
The RTE generator shall provide two different phases, which can be used in different
development stages. This two phases can be split into two tools, but they are very
similar and the currently known generators support both.
Contract phase In the contract phase an RTE generator shall produce the header
files for the SWCs to allow compiling the components. It is not necessary to define
the whole system in this case, but just the SWCs for which the header files should
be generated. The header files just contain the Application Programming Interface
(API), which can be used from the SWCs.
Generating phase In this phase the generator shall produce the whole RTE for one
ECU. The generated RTE also consists of header files for the SWCs and these have to
be compliant with those generated in the contract phase.
Together with that, the RTE generator normally works in a mode called the “compatibility
mode”. It can additionally support an optional mode, which is called the
“vendor mode”. A description of both is given in the following.
Compatibility mode The RTE generator produces well–defined data structures
and types in this mode. That means, that not only the API for the SWCs is defined,
but also a lot of the implementation behind this API. There are e.g. structures to
provide access to the current values of a sender–receiver communication. This mode
has its main focus on the sharing of object code between different suppliers.
Vendor mode This is an optional mode, in which the RTE generator can assume
that the RTE is created only with that one generator (or maybe compatible generators
from the same vendor). So it does not have to create that well–defined implementation
of the API from compatibility mode and it can produce more efficient code and do
optimizations.
The source code in the contract phase also have to contain the tasks, which are specified
in the configuration and in which context the runnables are executed. The code
for the tasks have to provide calls for the runnables, because they shall be executed
if the configured events occur. Additionally the RTE generator shall output a part
of the configuration for the operating system. This is necessary, that the operating
system gets noticed about the tasks and how they should be executed. The example
in the next section also addresses this point.
2.8 Example
This is a short example to clarify the concepts and proceedings described in this
chapter. It especially focuses the view of the implementation and the generating of
16

2.8 Example
the RTE and should clarify how components can be implemented and how the API
can be used.
2.8.1 Configuration of the Example
The example is based on a system with two SWCs, which are shown in figure 2.8. This
section just contains an extract of the configuration and some parts of the source code
for SWC1. To whole configuration of the system can be found in appendix A. The
configuration of the ECU is not shown.
SWC1
run11 run12
SWC2
run21 run22
Virtual Functional Bus
Figure 2.8: Visualization of the example
Task1
Task2
Every SWC uses two ports and has two runnables, which are shown as boxes inside
of the components. The lines to the ports show an access to this ports. The runnable
run11 is triggered by a timing event which occurs every 100ms. Runnable run12 is
triggered by another timing event which occurs every 50ms. The two runnables of
SWC1 are mapped to the same task Task1. In more detail the events triggering a
runnable are mapped to a task, but here every runnable is just triggered by one event
and so they only run in the context of one Task. The runnable run22 of SWC2 is
also triggered by an timing event every 50ms and runs in the context of Task2. The
other runnable run21 is triggered by the invocation of a server call at the server port.
This runnable is not mapped to a task, but is has the option set, that it can be
invoked concurrently. This is one special case, where an event must not be mapped
to a task. Instead a direct call to the runnable should be performed to provide a
better performance. Both SWCs are mapped to the same ECU. All this information
is reflected by the configuration files.
Listing 2.1 shows the definition of the data elements which are used for this example.
The first is the integer type Int16 with a specified range of valid values. The second
type is a string type, which has a length of 8 characters and the symbol String8. To
reference a type, the names of the packages have to be used as path. This means for
the integer type, that it can be referenced by the path /types/Int16.
The description of the interface of the sender–receiver port used in the example is
shown in listing 2.2. The interface SR Int16 consists of two data elements intValue1
and intValue2, which are both of type Int16, and it provides a not queued communication.
Here it is shown, how the reference to the data types are used multiple times.
The package names specified in the listings are arbitrary. There is no need to call
17

Chapter 2 AUTOSAR
1
types
Int16
-32768
10 32767
String8
utf8
8
20
Listing 2.1: Example description of data types
1
interfaces
SR Int16
false
10
intValue1
/types/Int16
false
intValue2
/types/Int16
false
20
18
Listing 2.2: Example description of port interfaces

2.8 Example
them “types” or “ interfaces ”. Additionally, it is not needed to have different names
for these packages.
1
swc root
swc1
10
pport1
/interfaces/SR Int16
rport1
/interfaces/CS string to int
20
Listing 2.3: Example description of SWC1
To describe the component SWC1, the code of listing 2.3 is used. Here are the two
ports of SWC1 specified. Listing 2.4 shows the internal behavior of SWC1. There are
the runnables and the ports, which are accessed by the runnables, described. This is
needed to generate the API and to provide consistency for the communication. The
access is specified with DataSendPoints and a SynchronousServerCallPoint. Runnable
run11 writes both values to the sender port pport11, whereas run12 only writes the
value intValue1.
The runnables are triggered by the specified timing events. One runnable can be
triggered by more than one event, but this case is not shown here.
At this point it can be seen that every part is very flexible handled with references. It
is also permitted to have more than one internal behavior for one Software Component
specified, but just one can be used. This is done by the instantiation of the SWC, which
is part of the system description and not shown here. So it is e.g. possible to reuse a
definition of a Software Component and reuse it with different internal behaviors. As
also can be seen in the configuration, it is possible for an internal behavior to support
multiple instantiation, which should also not be considered here, because it does not
contribute to the understanding and would just complicate the example.
2.8.2 The Generated Source Code
After calling the RTE generator with that configuration, it should produce the auto
generated part of the RTE. This part contains the API for the SWCs. The interesting
extract for SWC1 is shown in listing 2.5. In the last two lines the functions for the
runnables are declared. These functions are called when a runnable is executed. This
means for this example that the functions are called when the timing events occur. So
19

Chapter 2 AUTOSAR
1
swc root
intBehSwc1
/swc root/swc1
10
Time100ms
/swc root/intBehSwc1/run11
0.1
Time50ms
/swc root/intBehSwc1/run12
0.05
20
run11
false
dwa1
30 /swc root/swc1/pport1
/interfaces/SR Int16/intValue1
dwa2
/swc root/swc1/pport1
40
/interfaces/SR Int16/intValue2
run11
run12
50 false
dwa2
/swc root/swc1/pport1
/interfaces/SR Int16/intValue1
60
sscp
/swc root/swc1/rport1
70
/interfaces/CS string to int/parse
run12
80 false
20
Listing 2.4: Example description of internal behavior of SWC1

1 #define RTE E CS string to int overflow (42)
#define RTE E CS string to int underflow (43)
2.8 Example
#define Rte Call rport1 parse(array, sum) (Rte Call swc1 rport1 parse(array, sum))
FUNC(Std ReturnType, RTE CODE) Rte Call swc1 rport1 parse(CONSTP2VAR(String8, �
AUTOMATIC, RTE APPL DATA), CONSTP2VAR(Int16, AUTOMATIC, RTE APPL DATA));
/∗ Inline Write optimization; Rte Write pport1 intValue2 to direct access ∗/
extern VAR(Int16, RTE DATA) Rte RxBuf 1;
10 #define Rte Write pport1 intValue2(data) ( �
Rte WriteHook swc1 pport1 intValue2 Start(data), (Rte RxBuf 1 = data), �
Rte WriteHook swc1 pport1 intValue2 Return(data), RTE E OK )
/∗ Inline Write optimization; Rte Write pport1 intValue1 to direct access ∗/
extern VAR(Int16, RTE DATA) Rte RxBuf 0;
#define Rte Write pport1 intValue1(data) ( �
Rte WriteHook swc1 pport1 intValue1 Start(data), (Rte RxBuf 0 = data), �
Rte WriteHook swc1 pport1 intValue1 Return(data), RTE E OK )
FUNC(void, RTE APPL CODE) run11(void);
FUNC(void, RTE APPL CODE) run12(void);
Listing 2.5: Example header file for SWC1 (Rte swc1.h)
to implement a functional behavior for the Software Component, this functions have
to be implemented. Within these functions, the values of the ports can be accessed, if
it is configured for the SWC.
For an access to a sender port with a DataSendPoint, the API is specified within
AUTOSAR to be of the form Rte Write (data). Whereas is the name
of the port and is the name of the data element which is accessed. The value,
which is passed to the call with the parameter data, is written to the port.
As mentioned before, the both components are mapped to the same ECU and so
there is no need to use any inter–ECU communication mechanism. Instead the communication
can be done directly. It can be seen in the example that the API is
implemented with #define directives, which directly accesses the global variables
Rte RxBuf 1 and Rte RxBuf 2. The API for SWC2 is not shown here, but it has to
access the same variables to establish the communication.
To invoke an operation at the server, a function call is necessary. For the runnable
run12 is a SynchronousServerCallPoint specified. So the function does not return
until the operation on the server is finished and the return values are available. In
the special case mentioned above, the runnable, which implements the server, is not
mapped to a task and can be invoked concurrently. This runnable is then executed in
the context of the current task and therewith no other task has to be started.
For the SynchronousServerCallPoint, the API Rte Call rport1 parse( string , value)
is expected and created by the RTE generator. The operation parse takes one string
as argument and returns one integer value. This API is implemented using a #define
directive to a function. This function is implemented in the also generated file Rte.c.
21

Chapter 2 AUTOSAR
1 TASK(Task1)
{
Rte RECount Task1 divby2 0−−;
if ( Rte RECount Task1 divby2 0 == 0 )
{
run11();
}
{
run12();
10 }
if ( Rte RECount Task1 divby2 0 == 0 )
{
Rte RECount Task1 divby2 0 = 2;
}
TerminateTask();
}
Listing 2.6: Example code for Task1
The RTE generator also creates the source code for the tasks. The extract for Task1
is shown in listing 2.6. Here it can be seen that the runnable run11 is triggered every
100ms and runnable run12 every 50ms. This is done by activating the task every
50ms and executing the runnable run11 just any second call. The activation of the
task every 50ms is done in the configuration of the operating system, which is also
created from the generator.
2.8.3 Implementing the Runnables
At the end listing, 2.7 shows how the runnable run12 can be implemented. The created
API can be used to access the ports. Here it is just necessary to write the correct API
to the source code. This code can then be compiled with the generated header file.
Instead of the global variables for the sender–receiver communication shown in this
example, also a function call can be used. The runnable would not get noticed about
it.
1 FUNC(void, RTE APPL CODE) run12(void)
{
String8 val1;
Int16 val2;
...
6 Rte Call rport1 parse(val1, &val2);
...
8 Rte Write pport1 intValue1(val2);
...
10 }
Listing 2.7: Example code for run12
This also shows the first problem for sharing object code. If a component is compiled
against such a header file with global variables, it is expected that a generator, which
creates the whole API, does not create the same global variable. So the object code
22

2.9 Summary
cannot be used. Therefore function calls have to be created for sharing object code.
But this causes an overhead for the function invocation when accessing a port.
2.8.4 Conclusion of the Example
This simple example shows some basic mechanisms defined in AUTOSAR. It presents
the complexity of the XML configuration which is already reached by such a simple
case. But it should help to understand, how the mechanisms described in this chapter
are implemented in the source code.
2.9 Summary
In summary AUTOSAR allows a strict distinction between functional parts (SWCs)
of software and infrastructural parts (BSW), which just provides the necessary basis
to run the SWCs. The functional components are developed independent with respect
to AUTOSAR compliant interfaces and descriptions, which specify in a formal and
detailed way, what resources are necessary to run a component. Additionally, it has
to be specified, which conditions are provided by the hardware and the topology of
the system. Then, the RTE generator creates automatically the RTE, which brings
the two parts (SWCs and BSW) together.
With the standardization of the BSW and the interfaces between each part of the
BSW, the replaceability of parts increases and even with the MCAL it is possible
to exchange microcontrollers with others, if there are AUTOSAR compliant MCALs
available for the new controllers.
23

Chapter 2 AUTOSAR
24

Chapter 3
MEDC17
AUTOSAR is a new standard, which is described in the previous chapter. The currently
from BOSCH developed and used environment for software of motor control
units is called MEDC17. It is not a standard as AUTOSAR, but just an environment
consisting of a software architecture and application software together with a build
environment. The control unit, which is fabricated from BOSCH and for which the
software is developed, has the same name. If it is not explicitly said, in this work with
“MEDC17” is only the software part meant.
MEDC17 provides another approach than AUTOSAR. First MEDC17 just provides
support for the architecture and development of software for one control unit. It does
not handle so much features, which can be used by the Application Software (ASW),
than AUTOSAR. However, on the other hand MEDC17 supports the development
process of BOSCH with some mechanisms like e.g. the automatically generation of
documentation. This mechanisms have no counterpart within the AUTOSAR standard.
Due to secrecy, this chapter just takes a facile overview about what is necessary to
understand the later described work. Some comparisons to AUTOSAR are made in
this chapter, but even if MEDC17 is described after AUTOSAR, MEDC17 is the older
one.
3.1 ERCOSEK
MEDC17 is based on the embedded operating system ERCOSEK, which was developed
and distributed by ETAS. ERCOSEK is an OSEK–OS compliant operating system.
Some mechanisms of OSEK–OS are described in section 2.3.
The OSEK standard specifies extended tasks, but they are optional for an OSEK
compliant operating system. ERCOSEK is one of these, which do not support extended
tasks. So just basic tasks can be used. On the other hand extended task are also
undesired because of the resource overhead they cause.
Not every feature of ERCOSEK is used in MEDC17. Additionally, MEDC17 has a
fixed configured operating system and it is very unusual to change the configuration,
especially for every auto build.
25

Chapter 3 MEDC17
3.2 Basic Software and Application Software
Similar to the AUTOSAR architecture, MEDC17 is split into BSW and ASW. One part
of the Basic Software, the operating system, was mentioned in the previous section.
But some other parts like a communication stack and device drivers exist here, too.
However, they do not fit to the interfaces specified by AUTOSAR. The BSW provides
the infrastructure to run the ASW, whereas the Application Software is the functional
part of the software.
3.3 Communication
The current development of motor control software does not care about other ECUs,
instead it just handles the one motor control unit. So MEDC17 does not share the
inter–ECU approach from AUTOSAR. Every part that is developed and compiled
with MEDC17 runs on the same ECU. Nevertheless, MEDC17 provides access to
communication over CAN or other buses.
The intra–ECU communication is here done with so called messages. These messages
have to be configured for MEDC17 and than for each message one or more global
variables are created during the auto build. The application software uses an API to
access the global variable. This API is typically a #define directive, that maps the
access to the correct variable.
3.4 Tasks and Processes
The counterpart to a runnable in AUTOSAR is called a process in the terms of
MEDC17. Here there are not so much mechanisms for a process than for a runnable
in AUTOSAR.
For MEDC17 some tasks are configured, which are time triggered. The periods
of this tasks are from 1ms up to 1s. The source code of the tasks of MEDC17 is
also auto generated from some configuration files, but it does not provide so much
flexibility. The configuration of the tasks consist of a list of processes for each task,
which is transformed into source code. The processes are called within a task in the
same sequential order as they are defined in the configuration. There is no handling
of events that triggers the one or the other process like it is shown in the AUTOSAR
example in section 2.8, where two runnables with different timings are executed in the
same task.
So all processes are time triggered and for a process it has to be decided, in which
interval it should be executed. Then the process is mapped to the task with the
corresponding timing. Due to dependencies between processes, they have to be mapped
in the correct order. Because e.g. one process can determine a value and another
process uses this value, but the value have to be up to date for a special timing. So
these processes have to be executed in the correct order and there is no mechanism to
determine this order automatically.
26

3.5 Summary
On the other hand the processes that run in a task do not necessarily have a dependency
or fulfill the same job. They are just mapped to that task, so that they are
executed in the correct interval. The term “task” does here not imply the meaning of
achieving the same function.
3.5 Summary
MEDC17 provides the current architecture of software development for one ECU for
BOSCH. It has not to handle so much possibilities as AUTOSAR, since it has not to be
supported by any other manufacture. It is very static configured and the application
software has to deal with the existing architecture. So processes have to deal with
the existing tasks and it is very unusual that a new task is created. AUTOSAR uses
another way where the BSW and especially the operating system is configured to fit
the application software and this configuration can change with every call of the RTE
generator.
27

Chapter 3 MEDC17
28

Chapter 4
Goals
This chapter first describes the background for this diploma thesis. Afterwards, it
discusses the idea, why this diploma thesis was arisen and then it addresses the topic
and the requirements.
4.1 Background of the Topic
Chapter 2 gives a short introduction to AUTOSAR, a new standard which is becoming
more important for automotive software development. On the other hand, there is
a lot of existing and not AUTOSAR compliant software in form of the MEDC17
environment, which should not be discarded. But their are two requirements for
supporting AUTOSAR:
• suppliers deliver AUTOSAR compliant software, which should be integrated in
several projects
• a conversion to AUTOSAR should be performed step by step
So the first step, which is agreeable with both, is to integrate AUTOSAR compliant
software in MEDC17. With this, a new follow–up platform for MEDC17 can be
developed according to AUTOSAR and the old can be kept for current projects. So
the migration to AUTOSAR can be done stepwise.
4.1.1 Differences of MEDC17 and AUTOSAR
AUTOSAR and MEDC17 differ in a lot of cases. Here are described some points,
which cause issues by using MEDC17 and AUTOSAR together. This enumeration is
not complete, because not all are identified yet.
Extended tasks
In section 3.1 the operating system ERCOSEK is described, on which the BOSCH
architecture MEDC17 is based. It does not support the from OSEK–OS defined extended
tasks. However, there exist some mechanisms of AUTOSAR, which result in an
extended task after generating the RTE. E.g. a runnable can explicitly use a WaitPoint
to wait for an RTE event. This causes the usage of an extended task.
29

Chapter 4 Goals
Communication
The communication for MEDC17 is done with global variables. In case of AUTOSAR,
ports are used to communicate between SWCs. The RTE generator often implements
the intra-ECU sender–receiver communication with global variables, but it does not
have to, especially not for components which are delivered in form of object code.
Nevertheless, if the communication is implemented with global variables, the RTE
generator creates some #define directives, which map the call to a direct access
to global variables. But the identifiers of the directives differ from AUTOSAR to
MEDC17 and the names of the global variables, too.
Top–down Approach
AUTOSAR uses a top–down approach in the way, that the BSW, especially the operating
system, is configured for the needs of the ASW. In the case of MEDC17 the
configuration is fixed and it is changed in very few cases. Instead, the ASW is adjusted
to work with this premises.
Ignorance
From view of the RTE generator, it creates the RTE for all software, that runs on an
ECU. The generated RTE provides data consistency for the communication and the
specified behavior of e.g. the correct triggering of runnables by events. It does not
know, that there is other software, which is not AUTOSAR compliant, but which runs
additionally on the same ECU. This is not really a difference, but an important item
for using not AUTOSAR compliant software.
4.1.2 Integration of AUTOSAR Software in MEDC17
For AUTOSAR compliant Software Components the RTE provides the connection
to the BSW and between the components itself. So to integrate such components
somewhere else it is necessary to integrate the RTE. Figure 4.1 shows the architecture
of MEDC17 together with the integrated RTE. Of interest is especially the vertical
part of the RTE layer, which adapts the old software to establish communications to
the AUTOSAR software. However, adapters must exist to fit the old software.
From the view of MEDC17 the RTE is just a new MEDC17 Application Software,
which runs on it. But the RTE has some other requirements than a normal component
and this requirements have to be provided from MEDC17. E.g. the RTE generator
creates its own configuration for the operating system and the features and mechanisms
specified in this configuration are needed to execute the generated RTE. So the
operating system of MEDC17 have to be adjusted to provide this mechanisms. This
could be e.g. a task or a special timing triggering a task.
On the other hand not only MEDC17, but also the RTE can be changed, to get by
the existing mechanisms. However the RTE is auto generated from the RTE generator,
so this changes have to be done for every new configuration of a system. The other
30

AUTOSAR
Application
Software
Runtime Environment (RTE)
Adapter
Adapter
MEDC17 Basic Software
MEDC17 Hardware
4.1 Background of the Topic
MEDC17
Application
Software
Figure 4.1: Integration of AUTOSAR in MEDC17
way is to change the RTE generator itself, that it prefers mechanisms in the created
source code, which are easier to handle for MEDC17. As described in chapter 2, the
RTE does not only consist of generated code, but also of some fix source code which is
called the RTE library. This RTE library can be customized once to fit into MEDC17.
With this changes to the RTE library and the RTE generator and its output, it
has to be assured, that the semantic of the configured system hasn’t changed. Because
for delivered SWCs, the supplier has developed the components according to
the AUTOSAR standard and this expected behavior has to be obtained. However, it
is possible, to inform the supplier about AUTOSAR features, which can’t be integrated
and therefore shouldn’t be used in delivered software.
So there remain the following questions:
• Which features can be integrated?
• Which features can’t be integrated?
• What should be changed on the RTE generator?
• What should be changed on MEDC17?
Since the RTE depends on the configuration of the system, to get answers for these
questions, different configuration have to be checked. The result should be an interpretation,
if the features can be integrated or what has to be changed to do it. If the
feature cannot be integrated with adequate effort, this is also a result of the check.
31

Chapter 4 Goals
4.1.3 Development of RTE Generators
Some tool suppliers develop different RTE generators. BOSCH uses an RTE generator,
which is developed and distributed from ETAS. For every AUTOSAR release exists an
own version of the generator. However, not only new generators for new AUTOSAR
releases have to be developed, but also existing versions for existing AUTOSAR releases
remain under further development. Reasons for this are:
• XML–scheme updates for an AUTOSAR release
• RTE generator optimizations
• fixing of bugs
• adjustments to MEDC17 integration (desired from BOSCH)
The generator must produce correct AUTOSAR compliant source code. But this
work and former tests have detected some bugs. This is an outcome of the mass
of combination possibilities of the features and configurations, which should be all
handled correctly. So the tests should also check some basic functionality of the RTE
generators, because they should be used in production and so they have to work
correctly and produce functional correct and AUTOSAR compliant code.
4.1.4 Current Situation (before Diploma Thesis)
Before this diploma thesis started, the evaluation was still in progress. The proceeding
lacks of structure, reusability and concepts. This means concretely:
• the used tests didn’t cover all the features, which are expected to be integrated
in MEDC17 in the future
• every test is performed on its own and just for one RTE generator
• it takes a high effort to analyze a test result
• many tests are performed in separate environments
This leads to the task of the diploma thesis, to bring structure to the whole process
and give a proceeding to perform the evaluation.
4.2 Topic of the Diploma Thesis
With the explanations in the previous section it is now easy to describe the topic.
32

4.2.1 Main Task
4.2 Topic of the Diploma Thesis
The purpose of this diploma thesis is to design and create an environment to test and
evaluate RTE generators. It shall help to perform tests with an RTE generator and
rate its quality. A major focus of these test shall be the integration in MEDC17 and
results shall state the needs for changes to the generator and MEDC17. Additionally
a proceeding to evaluate a new version of an RTE generator shall be developed. This
leads to the following steps:
• breakdown of the required features
• decide which features shall be tested
• decide how the result should be interpreted
• build an environment to provide the tests
• create test cases
• create evaluation guidance
The term “environment” does not say how this shall be realized. From the topic it
isn’t defined which form the environment should have. Supposable are e.g. a graphical
user interface or just a description of a concrete proceeding.
4.2.2 Requirements
At the begin of the diploma thesis, a functional specification was worked out. It
contains a lot of requirements for this work. Because the requirements also cover some
implementation and analysis aspects, they does not fit in this chapter. So they are
shown in appendix B.
4.2.3 Available Resources and Tools
There are some resources and tools available to do this diploma thesis. They are
described in the following listing.
RTE generators from ETAS ETAS has developed different versions of RTE generators
for AUTOSAR release 2.0 and 2.1, which are available for this work. These
versions already fulfill some special requirements from BOSCH. These generators are
the main test objects of the whole environment, because these are the generators which
will be used from BOSCH.
GEENSYS AUTOSAR Builder The AUTOSAR Builder allows to edit the XML
descriptions and XML configurations on a higher level than just editing the plain text
files. It helps creating descriptions and configurations by showing the available tags
for the XML structure. It also provides help for using the references in the XML file.
The complete program is split into several tools, which provides generating the XML
33

Chapter 4 Goals
files for special parts. Two of them are used to create the test cases for this work.
This are the AUTOSAR Authoring Tool (AAT) and the Generic ECU Configuration
Editor (GCE). The first one allows to create the description for the components and
the compositions and to configure the system. The second one is used to configure the
ECU parameters for the available ECUs.
MEDC17 environment A checkout of the MEDC17 environment is called a PST 1 .
Such a PST is available to test the integration of AUTOSAR files.
MEDC17 control unit To do functional tests with a debugger a control unit is
needed.
Universal Debug Engine The Universal Debug Engine (UDE) from pls consists
of a software front end and a Universal Access Device to establish the connection to
the controller. It is used to program and debug the MEDC17 control unit.
HighTec–GNU Compiler Suite To compile the MEDC17 environment to an executable
file this compiler is necessary. Some other build tools are integrated in
MEDC17.
RTA–OSEK PC–Port This is a PC–Port of the OSEK operating system for embedded
devices. This operating system port is also compliant to the AUTOSAR OS
1.0 specification [4] and it provides a virtual environment to execute OSEK compliant
software directly on a PC.
MinGW Compiler Suite Is a minimal port of the GNU Compiler Collection for
Windows. This is necessary to compile software for the PC–OS port.
4.3 Summary
Some differences of AUTOSAR and MEDC17 are addressed in this chapter and it is
shown, why there is a need for bringing AUTOSAR compliant software to MEDC17.
And it is also shown that it is needed to adjust both to reach this goal. The solution
to derive adjustments is to do tests with software and try to integrate it in MEDC17.
But also just basic tests are necessary to ensure correct functionality of the RTE
generators and these tests do not depend on MEDC17. To do this an environment
should be created, which is described in the following chapters.
1 PST is an abbreviation for the German word “Programmstand”.
34

Chapter 5
Analysis and Design
The evaluation environment is divided into two parts. The one is the test environment,
which helps to perform tests. The other are the test cases itself, because just with the
test cases the environment can be used for evaluation. The structure and behavior of
the test environment are explained in this chapter, the implementation is described in
the next one. Chapter 7 deals with the test cases itself.
The outline of this chapter is the following. In section 5.1 first an evaluation flow is
described. It should provide the idea of the classification of the components, which is
made in section 5.2. Section 5.3 describes, how these components are configured and
section 5.4 describes how they are stored in the file system of the environment.
This chapter also provides some aspects of the implementation of the environment,
which are explained in the next chapter. This are e.g. the use of Perl files to implement
test types or the use of XML files to store configurations.
The term “components” is used in this chapter to address the in section 5.2 explained
components of the environment. There are not the AUTOSAR software components
meant.
5.1 Test Data Flow
This section provides the idea of the made classification and structuring of the later
environment. The diagram in figure 5.1 shows a simple proceeding of doing a test with
an RTE generator. MEDC17 is not considered in this diagram. The test case consists
of some AUTOSAR XML files, which are fed into the generator to create the RTE.
The RTE not only consists of the auto generated part, but also of the RTE library,
which is fix for one generator. The test case provides source files, which implement
the SWCs that are described in the AUTOSAR XML files. The test case also consists
of some documentation files, which describe the aim of the test in an informal way.
The generator creates OIL files for the configuration of the operating system, but
this is not the whole configuration. So there are some additional files needed. From
this configuration the source code for the operating system can be generated. This is
not considered here in detail, but just displayed in the diagram.
Some additional source files, which e.g. contain the main() function, are also required.
All source files can now be compiled and linked together. The created binary
file then can be executed at a control unit or with the OSEK–OS PC–Port, depending
on for which target the binary is built.
35

Chapter 5 Analysis and Design
test case
test
conf.
src /
obj
test
doc.
test object
RTE
generator
RTE
lib.
oil
src /
hdr
compiler
binary
file
Figure 5.1: Procedure of a test case
src /
rta build oil
hdr
src /
hdr
additional
files
The documentation describes the aim of the test and it has to be clarified, if this
aim is reached. This can be done in several ways. Depending on the expected test
behavior the source code has to be compiled and the resulting binary can be executed
to check it. However, for some other cases it is sufficient to look at the generated
source code and take a decision.
So this simple diagram should show some variation possibilities and some components
can be derived, which should be part of the environment to provide flexible
testing for the RTE generators.
Test case The test case can be substituted with another one. This makes sense,
because different features should be tested and it is not possible to cover all with just
one case. Especially not, if different combinations of features should be tested and
evaluated.
RTE generator As described in chapter 4 it is necessary to evaluate different RTE
generators, especially different versions from ETAS. Additionally the evaluation should
be done for new versions, which contain special changes. So the evaluation has to be
done with such a new version, to ensure that the changes are implemented and that
they work in the expected way.
RTE library As also described in chapter 4, the RTE library has to be customized
to integrate the RTE in MEDC17. Since OSEK–OS is compatible with AUTOSAR
36

5.2 Components of the Environment
OS, the original RTE library should work with the RTA–OSEK PC–Port. Maybe
for a newer generator version a customization of the library for MEDC17 won’t be
necessary, but for the current versions it is and so there have to be at least two library
versions for one generator handled, the standard and the customized for MEDC17.
Test type The result can be obtained in some phases of the shown process. For
some cases a code look up after the generation can be enough to take a decision of the
result. The diagram just shows a simple flow and does not take care about MEDC17.
For a test, which addresses RTE code integration in MEDC17, this diagram would
look different. So even some other proceedings are necessary for tests.
Typically an RTE generator supports just one AUTOSAR release. The XML scheme
of the AUTOSAR configuration files and also the features differ a lot between the
different AUTOSAR releases. So a test case also belongs just to one AUTOSAR
release.
5.2 Components of the Environment
The components, which are described in the previous section, are the main objects of
the environment. These components are shown with their relations in figure 5.2. There
are more components than in the previous section described. Option, test, variable
and resource are introduced to provide a better reusability and flexibility.
The test case from the previous section is called test template in the environment.
A test template defines the requirements of a test, but the test can only be performed
with a generator. So a test consists of an RTE generator and a test template.
The diagram can be treated as a diagram for one AUTOSAR release, because there
are no major dependencies between the components for different releases. Only the
test types can be used globally. The components of this diagram are described in this
section first, the next section deals with the configuration of this components.
5.2.1 RTE Generator
The RTE generators are the main test objects of the environment and of the evaluation.
Every RTE generator has a specific name and version, which identifies a generator.
For the environment it is necessary to know, how the RTE generator is called and how
the AUTOSAR XML files are passed to the generator. This is done by the executable,
which contains the path to the generator itself, and by the command line, which
declares how the options and files are passed to the generator.
5.2.2 Options
An RTE generator also provides options, which can be passed through the command
line. The options are treated separately to provide a better flexibility and to take care
about different parameters for different generators. An RTE generator can provide an
parameter for each option, but it does not have to. The test template then can specify
37

Chapter 5 Analysis and Design
38
name
description
comandline
resource
parameter
name
number
description
doc. file
name files
executable
provide
option
RTE generator
test template
version
variable
name
provide
RTE library
define define
define
defines
value
description
name
implementation
require
name
result
default value
define
test type
require
consist
test
consist
Figure 5.2: Entity relationship diagram for the components
file
description
perl file
name

5.2 Components of the Environment
which options are used for the test. If the test is performed, the concrete parameter
for the used RTE generator is substituted. An option has a description that explains
the purpose of the option.
5.2.3 RTE Library
Similar to the options, the libraries are treated. An RTE generator provides normally
the library which is delivered with it. This library is called “Original” in the environment.
However, there can be other libraries, which are customized to take care about
special needs of e.g. MEDC17. This library is called “Mx17Erco” in the environment.
These two libraries are the only, which are currently used. The test template specifies
a library to be used and a generator can provide an implementation for this library,
or not.
5.2.4 Resource
Resources are the basis of the tests. Typically they consist of AUTOSAR XML and
source files. The XML files are normally fed into the generator and the source files
implements the SWCs, which are configured in the XML files. The resources are
handled separately to provide a better access with external tools and reusability for
multiple test templates.
5.2.5 Test Type
The test types specify how a test should be performed and how the result is obtained.
A test type consists of a name, which identifies the type. The description is a short
characterization of what the test type does. The Perl file implements the concrete
behavior of the type and it is explained in section 6.4. It is used to perform the test
type automatically.
In section 5.1 it is described, that for compiling the source code the RTE generator
has to accept the configuration and create the RTE. Thus, compiling of the source
code depends on whether the RTE generator accepts or rejects the configuration.
Furthermore, for a test it could be enough to know, if the generator accepts or rejects
a configuration. So there can be some test types like “accept”, “reject”, “compile”
imagined. To keep the effort down, the test for compiling a generated RTE can revert
to the test “accept”, which obviously has to be finished successfully before. This leads
to the dependencies between test types.
In section 5.1 it is also described, that for the operating system configuration additional
OIL files and for compiling additional source files are needed. So a test type
also has to provide some files that are needed for performing this type.
The types, which are used in the environment, are shown in figure 5.3 together with
their dependencies. The test types in the blue boxes can be performed automatically
without an interaction of the user. The result can be obtained from return values of
the executed programs. The blue boxes show the tests, which are performed by the
39

Chapter 5 Analysis and Design
configuration
reject configuration accept configuration
copy to Mx17 PST
compile Mx17 PST
run Mx17 PST
compile RTA–OSEK
5.0 for PC
run RTA–OSEK 5.0
for PC
Figure 5.3: Dependencies of the test types
code review
user and for which the user determines the result. The types are described in the
following.
accept configuration This type calls the RTE generator with the XML configuration
files. If the generator creates the RTE, the type is correctly finished. This type
needs the AUTOSAR XML path of the ECU, for which the RTE should be created.
This path is passed to the RTE generator.
reject configuration Instead of the type “accept configuration”, this type is finished
correctly, if the generator does not create the RTE and rejects the configuration.
It also requires the AUTOSAR XML path of the ECU, for which the RTE should be
tried to create. This path is passed to the RTE generator.
code review The review of the source code is based on a generated RTE. The user
reviews the code to obtain the result of the test.
compile OSEK–OS 5.0 for PC After generating the RTE the source code for the
operating system is created. Then all source files are compiled and linked to a binary
file, which can be executed on the PC–Port of the operating system. This type also
requires some variables. It needs the name of the binary that should be created and
the paths to the compiler and linker. These variables are all predefined with default
values. The test type also provides some files which are used to perform the test.
These are OIL files for the operating system configuration and source files for starting
the RTE.
40

5.2 Components of the Environment
run OSEK–OS 5.0 for PC This type executes the binary file for the PC–Port.
The binary is executed for a specific time. During this time the binary can make some
outputs to the standard output. If there is an output, that starts with the string
“ERROR”, this type is adopted as “failed”. Otherwise it is finished correctly. As a
variable this type requires a period of time that specifies how long the binary shall be
executed.
copy to Mx17 PST Since a complete built of MEDC17 has a size about 650MB,
it is not workable to copy it for every test. So the sources of the test are copied
to the MEDC17 directory, to integrate the test. So just one checkout is used for the
whole environment. The names of the copied files are stored in the MEDC17 directory
to delete the files before files of another test are copied to MEDC17. The test type
requires also some variables. These are the location of the PST and the names of the
subdirectories, in which the files shall be copied.
compile Mx17 PST The compilation of MEDC17 is not integrated in the environment.
It has to be performed with other build tools, which have to be started
manually.
run on control unit Here again, the flashing of the compiled MEDC17 to the control
unit and the debugging of the control unit, have to be done by the user. This
is done with the graphical debugger Universal Debug Engine, which is the debugger
used at BOSCH.
With this description it is clear that the test type “code review” does not need a
Perl script, because everything, which can be done automatically is done by an test
type that is executed before. So a test type, which is performed by the user, does not
have a Perl file.
5.2.6 Variables
To keep the test types configurable for a test template, variables are introduced. The
types e.g. need the name of the ECU in the configuration files, for which the RTE shall
be created, or a period of time for which a compiled binary shall be executed. Such
variables are defined by the test type and can be used in the Perl files. The variables,
which are required by the different test types, are already mentioned in the previous
section. Typically the variables are set by the test templates, but a test type can also
provide a “default value”, which is used, if no other is specified. A variable without
a “default value” has to be set from a test template that uses this test type. A test
type additionally sets a description for the variable. The description should explain
the purpose of the variable.
5.2.7 Test Template
A test template consists of a number with four digits and a name. The template is
unique identified by the number. The number is also used to sort the templates and
41

Chapter 5 Analysis and Design
group related templates together. A template has a description of what is expected
to test. The description can contain some proceedings for the user, which helps to
interpret the result or even to perform the test. This is especially needed for tests,
which cannot be performed automatically. The test template has also to define the
resources, which should be used for the test.
A template also has to specify the test type. It must set the variables that are
required by the test type. Due to the dependencies between the test types, the variables
for all types that are performed have to be set.
5.2.8 Test
A test brings a test template and an RTE generator together. Not every combination
of a template and a generator is a valid test. If the template specifies an RTE library,
for which no implementation is provided by the generator, this combination is not a
valid test.
A test additionally has of a result, which shows the success of the test. For test types,
which can only be performed with interaction of the user, the user has to determine
the result.
5.3 Configuration of the Components
The structure, which is explained in the previous section, provides a flexible basis to
create tests and reuse a lot of components for these tests. This structure could be
stored in a database. However, this is not done, because some of the files should be
edited with external tools. Therefor a file system structure, which is explained in
the next section, is used for storing the components. This section deals with some
simplifications. So not every part described have to be stored separately. Instead
some components are stored implicitly with the others.
The attributes and relations of test templates, RTE generators and test types are
stored in XML files, which are described in section 6.5. The resources in principle only
consist of files and they are just stored in a directory and the directory name is used
as name for the resource. The RTE libraries also consist of files and they are also just
stored in a directory.
The tests itself have not to be configured. Every test evolves from an RTE generator
and a test template. Everything, which is defined by these two components is used
for the test.
Variables and options are not stored separately. The test type also defines the
required variables together with a description, for what this variable is used. The test
templates defines also values for the variables. The options are just set by the RTE
generators and the same names are used by the test templates. The description of the
options is stored in a global configuration of the environment.
The options, which are required by the test template, and the command lines for
the RTE generators are handled in a special way. This is described in the following.
42

Command Line
5.4 Structure of the File System
Variables can be used in the command line of the RTE generator. To use a variable,
the variable have to be written as “$(variable name)” in the command line and it
is substituted at the execution with the value. For the command line the following
variables are currently used.
RTE GEN OPTIONS This variable is set by the test template with the required
options for the RTE generator and it is substituted with the concrete values for the
generator. This is a special variable, which is defined by the test templates.
ECU AUTOSAR PATH This is the AUTOSAR path in the XML files for the
ECU for which the RTE should be created.
TEST CONF This variable is substituted with the AUTOSAR XML configuration
files, which have to be passed to the generator.
In principle every variable, which is set by a test template or a test type, can be
used. Currently no other than the here described are necessary. The command line
for the RTE generators from ETAS is the following:
$(RTE GEN OPTIONS) −r $(ECU AUTOSAR PATH) $(TEST CONF)
The path to the ECU is passed with the option “-r”, the other options are defined by
the template and the configuration files are appended at the command line.
Options
The options are defined by RTE generators with the concrete parameters. The variable
RTE GEN OPTIONS is set by the test templates, to complete the command line.
The variable RTE GEN OPTIONS is set for the test templates in the same way,
as the command line for the RTE generators. The string “$(option name)” can be
used to define an option. An example string of options as they are typically used for
MEDC17 is:
$(OS HDR AUTOSAR H) $(ATOMIC ASSIGN TYPES) $(OS ERCOSEK) �
$(TASK AS FUNCTION ENABLE)
The purpose of this options is described in section 7.3 with the example for MEDC17.
5.4 Structure of the File System
The whole environment is stored in the file system. This is especially needed to store
the AUTOSAR XML files and the source files and to edit them with other tools, which
are not part of the environment. The basic structure of the file system is shown in
figure 5.4.
Every test template, test type and RTE generator is stored in a directory called
“configuration directory” in the diagram. The resources are stored in a “resource
43

Chapter 5 Analysis and Design
directory” and the tests are stored and performed in a “test directory”. RTE libraries
are also stored in directories, which have the same form as the “resource directories”,
but they are not part of the environment itself. Instead they are stored anywhere else
in the file system, because they are also used for other purpose. The content of these
directories is described later.
The file configuration.xml contains global preferences for the whole environment.
The files RteEvaluation.jar, RteEvaluation.bat and swt.jar are part of the implementation
and described in section 6.6.
root
pool
Autosar Release 2.0
resources
Ecu
0010 Ecu1
0020 Ecu2
. . .
nnnn Ecun
global types
interfaces
types
System
0010 System1
0020 System2
. . .
mmmm Systemm
rte generators
generator name1 version1
. . .
generator nameo versiono
test templates
0010 template name1
. . .
pppp template namep
Autosar Release 2.1
. . .
perform
Autosar Release 2.0
generator name1 version1
0010 template name1
. . .
pppp template namep
. . .
generator nameo versiono
. . .
Autosar Release 2.1
. . .
types
name1
. . .
nameq
configuration.xml
RteEvaluation.bat
RteEvaluation.jar
swt.jar
Figure 5.4: Structure of the file system
normal directory
resource directory
configuration directory
test directory
file
The test types are independent from the AUTOSAR release and they are stored in a
subdirectory of the directory “types”. The name of the subdirectory is the name of the
test type. Everything which is needed to configure the tests is stored in the directory
“pool” and the tests itself are stored and performed in the directory “perform”.
5.4.1 The Directory “pool”
The directory “pool” stores everything, which is needed to configure the tests. It is first
divided by the AUTOSAR releases. Inside of a release directory the RTE generators,
test templates and resources, which belong to this release, are stored.
A configuration for an RTE generator is stored in a subdirectory of “rte generators”.
This subdirectory is named with the name and version of the generator. Test templates
44

5.4 Structure of the File System
are stored inside the directory “test templates” and the subdirectories are named with
the number and name of the templates.
The resources are stored in the directory “resources”, but there is a division with
other subdirectories done. These subdirectories group resources and are described in
the following.
global types This directory just stores the resources “types” and “interfaces”. They
contain AUTOSAR XML descriptions of data types and port interfaces. They are
separately stored to be reused in every test.
System The residual part of the XML configuration is divided into the system and
the ECU description. The whole system is contained in the directory “System”. This
is the part, which can be edited with the AUTOSAR Authoring Tool (AAT) from the
GEENSYS AUTOSAR Builder.
Ecu The ECU specific configuration is contained as a resource in this directory. This
is the part, which can be edited with the Generic ECU Configuration Editor (GCE)
tool from the GEENSYS AUTOSAR Builder.
The whole AUTOSAR XML configuration for a test template normally consists of
the “types” and “interfaces” and one resource contained in “System” and one contained
in “Ecu”.
A resource is typically named similar to the test template with a number and name.
An exception are the resources stored in the directory “global types”. These belong
to nearly every template and have no number.
5.4.2 Resource Directory
The resource directories store files, which are needed and used for tests. These files
are contained in subdirectories of the resource directory to group related files together.
This provides a clearer view to such a directory. Additionally, files from external tools,
like e.g. a project configuration for the GEENSYS AUTOSAR Builder, are ignored,
because they are not contained in such a subdirectory. The following subdirectories
are possible 1 , but not all have to be used at a time.
Conf The AUTOSAR XML files are stored in this subdirectory.
Hdr This directory should contain include files.
Oil Files for the operating system configuration are stored in this directory.
Src This subdirectory contains the source files.
XML XML files for the MEDC17 configuration are contained in this directory.
Doc This directory can contain additional documentation files.
1 This is stored in the file configuration.xml and can be changed in the environment.
45

Chapter 5 Analysis and Design
The structure of the resource directories are also used to store the RTE libraries in
the external location.
5.4.3 Configuration Directory
A configuration directory is in principle based on the structure of the resource directories
and can contain the same subdirectories, but there also exists an XML file,
which stores a configuration. For a test type there is also the Perl script stored in this
directory. This script has to be called test type.pm. The XML files have a different
name for every configuration. For a test template it is e.g. called test template.xml.
The whole structure of the three configuration directories is shown in figure 5.5. Only
the subdirectories are displayed, which are really used in the environment, but it is
possible to use all the subdirectories described in the previous section.
rte generator.xml
RTE generator
Conf
Hdr
Oil
Src
XML
test type.pm
test type.xml
test type
Doc
doc1
. . .
docn
test template.xml
test template
Figure 5.5: Structure of the configuration directories
An RTE generator is stored anyway else in the file system, so there is just the configuration
needed. For test types, maybe some other files are necessary to perform the
test. This can be e.g. additional source or configuration files needed for the operating
system. The Perl script is also needed for a test type. A test template just consists of
the configuration and a subdirectory “Doc”, which stores additional files to describe
the test.
5.4.4 The Directory “perform” and Test Directories
This directory is to store and perform the tests. It is also first divided by the
AUTOSAR release. Inside such a release directory, the tests are identified with a
path consisting of two directory names. Since a test consists of an RTE generator and
a test template the origin directory names of these both are used to identify a test.
A test is stored in a separate directory to perform it independent from anything else.
An overview is shown in figure 5.6. Everything, which is needed to perform the test,
is copied to this directory. These are mainly the resources defined by the components.
The test template defines some resources with AUTOSAR configurations and source
files, the RTE generator provides the RTE library and every test type can provide
some additional files for performing the type. The configuration of the test itself is
stored in the file test.conf. It contains the variables, which are set for this test, and
46

test directory
TestConf
TestSrc
TestDoc
RteGenOutput
RteGenSrc
RteGenHdr
. . .
test.conf
test.log
test.result
Figure 5.6: Structure of a test directory
5.5 Summary
the options for the RTE generator. The file test.result contains the result of every
performed test type. Together with the result a comment from the user can be added.
The file test.log contains the log of the execution of the test.
The resources, which are copied to a test directory, are not just stored in the same
subdirectories than before. Instead a prefix is added, which indicates the origin of
this resource. So the new directory name is , where is
the name of the origin subdirectory. The value is set by the object which
provides this resource. The prefix “Test” is used for the test templates and “RteGen”
for RTE generators. Since the test types depend on each other, every test type specifies
its own prefix. E.g. The test type “compile RTA-OSEK 5.0 for PC” has the prefix
“PcOs” and the test type “copy to Mx17 PST” has the prefix “Mx17”.
So e.g. the in the diagram shown directory “TestConf” contains all configuration
files from resources specified by the test template. The directory “RteGenSrc” contains
the source files of resources specified by the RTE generator. The RTE generator just
provides the RTE library, so the source files of the RTE library are stored in this
directory.
5.5 Summary
In this chapter the structure and behavior of the environment is described. It is shown,
what components are used to provide a configurable and flexible test environment, and
how tests are created out of this structure by combining a test template and an RTE
generator. It is also shown, how the environment is sectioned by the file system. The
next chapter deals with the concrete implementation of the environment to achieve
this behavior.
47

Chapter 5 Analysis and Design
48

Chapter 6
Implementation of the Test
Environment
The previous chapter describes the structure and behavior of the environment to fulfill
the requirements. This chapter deals with the implementation and thus how this
behavior is achieved. First are some design decisions explained and the user interface
is shown with some screenshots. Afterwards, the implementation of the created user
interface is described. Then the Perl files of the test types and the XML files for
storing the configurations are explained.
6.1 Design Decisions
6.1.1 Graphical User Interface
The first idea was to just use some configuration files together with the file system
structure to configure the tests. The execution should be done by some scripts. In the
previous chapter the structuring of the environment is explained and a lot of variation
possibilities are shown. These variations are the reason, why the configuration files
seamed very confusing for the user and lead to some error sources. So the decision
was taken to create a Graphical User Interface (GUI) to access, configure and perform
the tests and to provide a clearer view for the user.
6.1.2 Java and SWT
Java [16] is used as programming language to implement the GUI. The choice for java
is mainly based on the availability of development tools for BOSCH.
As the toolkit for the GUI the Standard Widget Toolkit (SWT) [27] is used. It is
faster and fits better to the existing look–and–feel than other GUI toolkits for Java,
because it directly uses the libraries of the underlying system.
6.1.3 XML Files for Storing the Configurations
Java provides some library classes that parse, store and check XML [29] files against
a scheme [28]. If another format would be used for storing the configurations, the
parser would have to be reimplemented for this format. For XML it is just necessary
to provide the XML scheme. The functional code behind is implemented and well
49

Chapter 6 Implementation of the Test Environment
tested. By checking the files against a scheme, some semantic things can be checked,
which have not to be reconsidered in the later application. E.g. the number of a test
template, which consists of four digits.
6.1.4 Perl for Tests
But not everything of the environment is implemented using Java. Every test type
needs its own functionality, which has to be executed. This is e.g. an execution of
the RTE generator or the compilation of the source files. This functionality has to
be implemented for every test type and since a test type is just a component of the
environment, it should be possible to add and edit types. But for editing a type, no
change of the code and especially no rebuild of the GUI shall be necessary. So the
functionality of a test is not implemented as a Java class. Instead it is implemented
as a script, which is executed, when the test is performed. And so the type can be
edited or new types can be added without setting up a build environment for Java.
As language for the scripts Perl [19] was chosen, because it is available at the BOSCH
computers and used in MEDC17. So there exists some knowledge about Perl.
6.2 The Graphical User Interface
This section gives an overview of the graphical user interface. Some screenshots are
shown and the functions of the GUI elements are explained.
After starting the application a dialog, which is shown in figure 6.1, occurs. The
user have to choose the AUTOSAR release, which should be used in the environment.
Since there are no dependencies between the components and tests of different releases,
this is a reasonable distinction. Afterwards, the application window is shown for the
chosen release.
Figure 6.1: AUTOSAR release dialog
The application window mainly consists of different views for different purposes.
There is a view for configuring the RTE generators, for configuring the test templates
and one for performing the tests. An additional view shows the log of the application.
The views, except of the log view, are described in the following.
50

2
3
Figure 6.2: RTE generator configuration view
6.2 The Graphical User Interface
6
4
5
1
51

Chapter 6 Implementation of the Test Environment
6.2.1 RTE Generator Configuration View
The view used for configuring the RTE generators is shown in figure 6.2. The several
parts are now described.
1. The buttons at the upper right allow to change the view of the window.
2. The “preferences” button shows a dialog for editing the global preferences of
the environment. The test types can be configured in this dialog, because the
test types are the same for every release and they are normally not changed. It
allows also to set the path of the Perl interpreter and to edit the subdirectories
of the resource directories.
3. The RTE generator, which should be configured, is selected in the list at the
left side. The buttons at the top of the list allow to copy or delete an existing
generator or create a new one.
The right part of the window contains widgets for configuring the several parts of
the chosen generator. If there is a problem with the configuration, the widgets show
the corresponding part with red color. These widgets are now described.
4. The main attributes of an RTE generator are the executable, the command line
and the directory, which contains the RTE libraries. The attributes can be set
in this widget for configuring the generators.
5. The options of a generator can be edited, added or deleted. The table shows the
name of the options in the environment together with the concrete parameters
for the selected RTE generator. The options are edited with a dialog, which also
shows the description of the option.
6. In addition to the variables of the test templates and the test types, variables
can be specified for an RTE generator. This could be useful in some special
cases. E.g. The variable FLEXLM BATCH has to be set for RTE generators
from ETAS for AUTOSAR release 2.0 to use them in a batch.
6.2.2 Test Template Configuration View
The view used for configuring the test templates is shown in figure 6.3. This view
also consists of some widgets for configuring the several parts of the test templates.
If there is a problem with the configuration, the widgets also show the corresponding
part with red color. All parts are described in the following.
52
1. The list shows the test templates. With the buttons at the top of the list existing
templates can be copied or deleted or new templates can be created. The selected
template can be configured with the widgets a the right side.

1
Figure 6.3: Test template configuration view
6.2 The Graphical User Interface
2
3
4
5
53

Chapter 6 Implementation of the Test Environment
2. This part is to edit the description of the test template. Additional documentation
files can be added to the list at the right via drag’n’drop. These files are
stored in the subdirectory “Doc” of the test templates and they are useful for
further description of the test.
3. The main options of a test template can be edited with this part. The RTE
library, which shall be used, the test type and the options for the RTE generator
can be set.
4. This widget shows the resources, which are configured for the selected test template.
Resources can be added or deleted. If a configured resource does not exist,
it is colored red.
5. The variables of the template can be set with this widget. The variables, which
are defined by the used test type and all required types, are also shown. For
editing the variables a dialog is used. This dialog shows the description of the
variable, if the variable is required by a test type. So the usage of the variable
should be clear for the user.
6.2.3 Perform View
The view, which is shown in figure 6.4, is used to perform the tests. The several parts
are now described.
54
1. The RTE generator, for which the tests shall be performed, is chosen with this
box.
2. The list shows all available tests. If a test cannot be performed, it is colored gray.
This is the case, if the corresponding template has errors in the configuration or
if it requires an RTE library that is not provided by the selected generator. If
the selected RTE generator has errors in the configuration, all tests are shown
with gray color. A tooltip, which occurs if the mouse pointer rests over an item,
shows the reason, why it cannot be performed. The checkbox of every item in
the list is used to choose some tests for performing them at once.
3. These buttons are used for special purposes. The “select automatic” button
selects all checkboxes of the tests in the list, which can be performed without
interaction of the user and are not colored gray. The “select none” button cancels
the done selection. The “export results” button is used for exporting the results
of all tests, of which the checkbox is selected. The export is done in an Excel
file and the concrete target file can be chosen by a dialog.
4. This panel shows the log of the currently selected test. There is the output of
the executed programs shown. Additionally, it shows some information from the
environment like e.g. which test type is started and how it is finished.

2
1
3
7
4
Figure 6.4: Perform view
6.2 The Graphical User Interface
8
5
6
55

Chapter 6 Implementation of the Test Environment
5. The test types, which shall be performed for the selected test, are shown at the
right side. For every test type a box is shown, where the type can be started or
stopped. It is also possible to add a comment for the test type. The first box is
used to create or delete the test. If the test isn’t created, only the first box is
shown and the test have to be created first. If a test type cannot be performed
automatically, the button “start” cannot be used. Instead the result has to be
determined by the user and added with the “edit” button. The dialog for editing
the result also shows the description of the corresponding test template. So the
user knows what is expected and how the result is determined.
6. The file browser at the right side shows the test directory. All files of the test
can be viewed. This is especially useful for test types with user interaction.
There is another file shown, which is not described in the last chapter. The file
“test report excel.xls” is an Excel file, which contains the results and comments
for this one test. It is generated automatically after a change at the test and it
is useful to send a test with a bug to the RTE generator producer.
7. The “start” button is used to perform all tests in the list, of which the checkbox
is selected.
8. The “clear log” button clears the log of the currently selected test.
6.3 Implementation of the GUI with Java
The GUI to access the file system structure and configure and perform the tests is
implemented with Java and SWT. This section gives an overview of some implemented
Java classes and their functionality. Only the major classes are described. There are
also some simple classes like rte .evaluation.SortedList or some dialog classes, which
are not essential for basic functionality of the application. For further information the
source code and the source documentation should be consulted.
The class diagrams shown in this section do not visualize the dependencies to SWT
classes. Because they would only add superfluous complexity to the diagrams and they
just displays what widgets are used. This can easily be seen, if it should be necessary,
in the source code. A good start for programming with the SWT is [27].
6.3.1 Logging for the Application
To provide logging for the application the class LOG together with the interface ILog
is used. Objects that implements this interface can be added to the class LOG, which
just provides static methods. If a write is done to the class LOG, it is distributed to
all added objects.
This is used to distribute the output during a test execution to the Test object itself
and to the GUI. It is additionally used to provide a global log for the application,
which shows issues while parsing the XML files.
56

6.3.2 Basic Data Structures
MainConfiguration
∗ ◭ uses ∗
rte.evaluation
1
XMLParser
∗
IPoolChangeListener
1
IConfigurationChange
Listener
rte.evaluation.resource
6.3 Implementation of the GUI with Java
ConfigurationPool
TestTypePool TestTemplatePool RteGeneratorPool
∗
∗ ◭ creates 1
∗ ∗
◭ notifies
∗ ∗
◭ creates
1
∗ ◭ creates 1
TestType TestTemplate RteGenerator
1 ∗
◭ uses
∗ ∗
◭ notifies
∗ ∗
1
◭ uses
ConfigurationStore
∗
1
∗
ResourcePool Resource
1
∗
1
1
∗
creates ◮ ∗
Figure 6.5: Class diagram rte .evaluation. configuration
The package rte .evaluation. configuration provides the basic configuration classes,
which represents the components of the environment. The class diagram of this package
is shown in figure 6.5. The dependencies to other packages are also shown. The
configuration is stored using XML files.
The classes RteGenerator, TestTemplate and TestType are used to store and access
the configuration of the components. They provide an adapter to the configuration
directories described in section 5.4.3. The structure of the used XML schemes are described
in section 6.5. The schemes are very similar for the different components. The
superclass ConfigurationStore provides a lot of methods to access this XML structure,
which are used in the subclasses. So the subclasses have not to deal with the XML
structure itself.
∗
1
1
∗
∗ ◭ creates 1
∗ ∗
57

Chapter 6 Implementation of the Test Environment
To manage all the components of the environment, the classes RteGeneratorPool,
TestTemplatePool and TestTypePool are introduced. The class RteGeneratorPool e.g.
can be seen as an adapter of the base directory for all generator configurations.
The classes provide the functionality to create or delete components. Additionally
there are some methods to check for consistency. This means that there are no objects
with the same name or the same number in case of a test template. The classes have
also a lot of similarities, which are outsourced to the superclass ConfigurationPool.
To access a resource directory, the class Resource is used. The ResourcePool handles
all resources of the environment and additional the RTE libraries in the external
locations. The several classes are separately described in the following.
ConfigurationStore This is an abstract class, which provides access to the XML
configuration files. An XML file stores the properties of an object and it is checked
against an XML scheme. Derived classes have to provide an XMLParser object for
checking the XML files. Then some methods can be used by derived classes to access
special elements in the XML structure and so derived classes have not to deal with
the XML structure itself. IConfigurationChangeListener can be added to an object of
the class ConfigurationStore. The listeners are used as a callback and their method
configurationChanged() is called, if a property is changed. Every ConfigurationStore
contains one resource, which is used to access the subdirectories of the directory, in
which the configuration is stored.
RteGenerator This class represents a type for RTE generators. It provides an
XML parser and methods to get and set the properties of an RTE generator. The
RTE libraries are also handled as objects of the class Resource.
TestType This class represents a type for test types. It provides an XML parser
and methods to get and set the properties of a test type. The Perl file of the test type
can also be accessed.
TestTemplate This class represents a type for test templates. It provides an XML
parser and methods to get and set the properties of a test template. The for the test
template configured AUTOSAR XML configurations are handled as objects of the
class Resource.
IConfigurationChangeListener Objects which implements this interface can be
added to ConfigurationStore objects to get notified about changes of the configuration.
The interface just provides one single method configurationChanged().
ConfigurationPool This class provides some basic behavior which is the same for
the classes RteGeneratorPool, TestTemplatePool and TestTypePool. These are the
management of a set of ConfigurationStore objects and methods to delete and create
these objects. Objects of IPoolChangeListener, which are added to an object of this
class, are notified if the pool is changed. This means, if a configuration is added or
deleted.
58

6.3 Implementation of the GUI with Java
RteGeneratorPool This class extends the class ConfigurationPool to provide additional
functionality for a set of RteGenerator objects. These are methods to get the
union of all options and RTE libraries provided by the generators.
TestTypePool This class extends the class ConfigurationPool, but it does not add
really some new functionality. It has to be derived to implement some abstract methods
for TestType objects.
TestTemplatePool This class extends the class ConfigurationPool, but it does not
add really some new functionality. It has to be derived to implement some abstract
methods for TestTemplate objects.
IPoolChangeListener Objects, which implement this interface, can be added to
objects of the class ConfigurationPool to get notified about changes. The interface
just provides one single method poolChanged(), which is called, if a configuration is
added or deleted.
MainConfiguration This class does not depend on the other classes of this packages,
but it provides properties which are globally for the whole application. Like
the properties of the class ConfigurationStore, the global properties are also stored
using an XML file. The class MainConfiguration provides get and set methods for the
path of the Perl interpreter, the names of the subdirectories which are considered for
resources and the descriptions of the RTE generator options.
The package rte .evaluation.resource is completely described with all contained
classes in this diagram. These classes and the class XMLParser are now described.
Resource This class represents a resource of the environment. Resources are typically
stored in a directory with subdirectories, which contain the files for this resource.
An object of this class provides access to a resource directory as described in section
5.4.2. It just considers the subdirectories.
ResourcePool This class provides access to all resources of the environment. A
Resource object can be created with a relative or an absolute path. This class ensures,
that every Resource object, which is needed, is just created once. It additionally
handles external resources like the RTE libraries.
XMLParser This class provides methods to parse and write XML files. It additionally
provides methods to check the files against an XML scheme and to create empty
XML documents. It encapsulates some classes of the Java class library to provide a
simple interface for XML access.
6.3.3 Perform
The main purpose of the environment is to perform tests. This is done by the package
rte .evaluation.perform, which is shown in figure 6.6. A test is represented by the class
Test. Creating and performing a test needs a lot of accesses to the file system and
59

Chapter 6 Implementation of the Test Environment
60
rte.evaluation
java.lang
writes log ◮
Log ILog
XMLParser
∗ writes log ◮ 1
TestPerformer
1
1 ∗
∗
◭ notifies
Thread
∗
∗
1
1
performs ◮
◭ writes log
notifies ◮
ITestPerformer
Callback
1
1
Test
1 ∗
1
TestType
∗
rte.evaluation.configuration
creates, uses ◮
1
IRunnerCallback
1
1
1 ◭ creates
1
TestTemplate
RteGenerator
◭ notifies
Figure 6.6: Class diagram rte .evaluation.perform
1
LogCatcher
1
TestCreator
∗
1 ◭ uses
1 ◭ uses
1 creates ◮ 1
1

6.3 Implementation of the GUI with Java
other tools like the RTE generator. So creating a test is done by the class TestCreator
and performing by the class TestPerformer. Both extend the class java.lang.Thread,
that they can be executed concurrently to the other classes.
Test This class represents a test for the application. The configuration of the test
and the results are saved in the files test.conf and test.result, which are accessed using
an XMLParser. The file test.log is stored in a simple text format. So it is easier to
send the complete test to the RTE generator producer and he can also read the log,
without using this environment. The class provides an adapter to a test directory
described in section 5.4.4. This class also implements the interface ILog, to get the
output of the executed test.
TestCreator A TestCreator object creates a Test object for the application, but also
the required directory in the file system with the content. It needs an object of the
class RteGenerator and TestTemplate to create the test. It writes the configuration
files and additionally copies the needed files to the test directory depending on the
needs described in section 5.4.4. It notifies an IRunnerCallback about the created test.
TestPerformer The test performer performs a given test. It sets the variables of the
environment and executes the Perl files of the defined test types in the test directory.
The result is got from the success of the Perl files. It notifies an IRunnerCallback
about the finished execution. An ITestPerformerCallback is notified if a new test type
is started or finished.
IRunnerCallback This interface is used as a callback to get notified when an operation
is finished.
ITestPerformerCallback This interface is used as a callback. It is notified by
an object of the class TestPerformer about every single test type, that is started or
finished.
6.3.4 Main Window
The package rte .evaluation.ui provides the classes for the main window of the application.
The window is implemented by the class EvaluationWindow. It also contains the
main() method for the application. The whole package is shown in the class diagram
of figure 6.7.
The window is parted into a left sidebar and a greater content pane, which is located
at the right. The content of the window can be changed by buttons, which are located
at the upper right of the window. Each view that can be shown in the window have to
be an object implementing the interface IEvaluationContentProvider of the package
rte .evaluation.ui.content.
AEvaluationWindow This abstract class implements the behavior for showing the
views and switching between different views. It shows a button to edit the preferences
at the upper left of the window. The GUI part of the main window is outsourced to
this class.
61

Chapter 6 Implementation of the Test Environment
62
PreferencesDialog
rte.evaluation.ui.dialogs rte.evaluation.ui.content
rte.evaluation.configure
AEvaluationWindow
IEvaluationWindow
ContentProvider
ComboChooseDialog EvaluationWindow
LogPanel
1 ◭ creates, uses 1
1 creates ◮ 1
RteGeneratorPool
TestTemplatePool
TestTypePool
1 ◭ creates, uses 1
1 ◭ creates
1 ◭ creates
1 ◭ creates
1
1
1
creates ◮
creates ◮
creates ◮
Figure 6.7: Class diagram rte .evaluation.ui
∗
1
1
RteGeneratorPanel
TestTemplatePanel
rte.evaluation.ui.content.configure
1
TestPerformPanel
rte.evaluation.ui.content.perform

6.3 Implementation of the GUI with Java
EvaluationWindow This class implements the main window for the application.
The behavior for switching the content and displaying the GUI is inherited from the
abstract superclass AEvaluationWindow. The class shows the dialog for choosing the
AUTOSAR release version at the beginning. Depending on this choice, the classes
TestTypePool, RteGeneratorPool and TestTemplatePool will be instantiated. Then
the classes, which implement the views of the window, are instantiated.
6.3.5 Configuration Widgets
The configuration of the test templates and RTE generators is done by the classes
RteGeneratorPanel and TestTemplatePanel. Due to the structure of the configuration
classes as it is shown in section 6.3.2 this two classes typically share a lot of code,
which is outsourced to the abstract class AConfigurationContentProvider. The whole
package overview is shown in figure 6.8.
The class AConfigurationContentProvider provides a view for the window, which
shows a table with all elements of a given ConfigurationPool at the left sidebar. The
right content is filled with objects, which shows the selected configuration. These
objects are of the type AConfigurationContentGroup. If a selection is done at the
table, the selected configuration will be set to all content groups at the right side.
The interface IConfigurationChanged is used to get notified about a change of a
configuration, which is only done in the application by the content groups. The interface
IPoolChanged is not used, because the class AConfigurationContentProvider
is the only one, which initiates creation or deletion of configurations for a pool and
so it has not to get notified about the change. For creating a new configuration,
the RteGeneratorPanel and TestTemplatePanel displays a dialog for getting the new
name.
AConfigurationContentProvider This class provides a view for the main window
to show a ConfigurationPool and to show and edit each ConfigurationStore of the pool.
The widgets to edit the configurations are of the type AConfigurationContentGroup
and instantiated by subclasses.
RteGeneratorPanel It is derived from AConfigurationContentProvider and sets
the RteGeneratorPool to the parent. It instantiates objects of OptionsContentGroup,
RteGeneratorContentGroup and VariablesContentGroup for editing the RTE generator
configurations.
TestTemplatePanel It is derived from AConfigurationContentProvider, sets the
TestTemplatePool to the parent and instantiates objects of ResourcesContentGroup,
DescriptionContentGroup, TestTemplateContentGroup and VariablesContentGroup
for editing the test template configurations.
To configure the test templates and RTE generators a set of widgets is used. Every
widget provides some special parts of the configuration. Each widget is derived
from the abstract class AConfigurationContentGroup, which is shown by the
63

Chapter 6 Implementation of the Test Environment
64
rte.evaluation.configuration
notifies ◮
∗
∗
∗
∗
IConfiguration
ChangeListener
ConfigurationPool
∗ 1
ConfigurationStore
∗
1 ◭ shows
∗ ◭ shows
◭ shows, edits
◭ shows, edits
◭ shows, edits
rte.evaluation.ui.content
1
∗
IEvaluationWindow
ContentProvider
AConfiguration
ContentProvider
∗ 1
AConfiguration
ContentGroup
∗
∗
∗
TestTemplate
ContentGroup
. . .
Variable
ContentGroup
. . .
RteGenerator
ContentGroup
rte.evaluation.ui.content.configure.widgets
rte.evaluation.ui.dialogs
RteGenerator
NameEditDialog
TestTemplate
NameEditDialog
RteGeneratorPanel
TestTemplatePanel
1
1 ◭ creates
1 ◭ creates
1 ◭ creates
Figure 6.8: Class diagram rte .evaluation.ui.content.configure
creates, uses ◮
1
1
1
creates, uses ◮
1
1
1

te.evaluation.configuration
∗
◭ shows ∗
∗
TestTemplate
ConfigurationStore
RteGenerator
∗
◭ shows, edits
◭ shows, edits
◭ shows, edits
AConfiguration
ContentGroup
∗ ◭ shows, edits ∗
∗ ◭ shows, edits ∗
◭ shows, edits
∗
∗
∗
∗
TestTemplate
ContentGroup
Description
ContentGroup
Resources
ContentGroup
ATableContentGroup
Variable
ContentGroup
Options
ContentGroup
RteGenerator
ContentGroup
6.3 Implementation of the GUI with Java
1 creates, uses ◮ 1
1 creates, uses ◮ 1
1 creates, uses ◮ 1
1 creates, uses ◮ 1
1 creates, uses ◮ 1
1 creates, uses ◮ 1
TemplateName
EditDialog
TextEditDialog
ResourceChoose
Dialog
VariableEditDialog
OptionEditDialog
RteGeneratorName
EditDialog
rte.evaluation.ui.dialogs
Figure 6.9: Class diagram rte .evaluation.ui.content.configure .widgets
65

Chapter 6 Implementation of the Test Environment
AConfigurationContentProvider. The widgets normally show, if there is an error with
the configuration. This is done by coloring some parts of the GUI red. All widgets are
contained in the package rte .evaluation.ui.content.configure .widgets, which is shown
in figure 6.9.
AConfigurationContentGroup This class provides some functionality of a widget,
that can be added to AConfigurationContentProvider to show and edit configurations.
The behavior for showing and editing special parts of the configuration has
to be implemented in the subclasses.
ATableContentGroup This widget shows a table in the content group and buttons
to edit, add and remove entries. This is used in some subclasses.
VariablesContentGroup An object of this class shows the variables of a configuration.
The variables can be edited or removed. New variables can be added. If a
TestTemplate is shown, variables, which are required by the test types and which are
not set, are colored red.
OptionsContentGroup It shows the Options of an RTE generator. Like for the
variables, the options can be edited, removed or new options can be added.
DescriptionContentGroup This widget shows the description of a test template.
This description consists of a string and some description files. The description can
be edited and new description files can be added.
ResourcesContentGroup This widget provides access to the configured resources
for a test template. Resources can be added or removed. If a shown resource cannot
be resolved, it is colored red.
TestTemplateContentGroup It allows to configure special needs for test templates.
This is the choice of the used RTE library, the used test type and the options,
that are used for calling the generator. If the test type, which is shown, does not exist,
or if it has errors in the configuration, it is colored red.
RteGeneratorContentGroup It allows to configure special needs for RTE generators.
This is the choice of the executable, the command line and the path, where the
RTE libraries are located. If the executable or the directory with the RTE libraries
cannot be resolved, they are colored red.
6.3.6 Perform Widgets
The package rte .evaluation.ui.perform provides the classes for performing the test
via GUI. The class diagram of this package is shown in figure 6.10.
Since the execution of a test is done in a separate thread, these GUI classes has also
to deal with threads. A change at a SWT widget can only be done in the SWT thread,
but the callback from the TestPerformer and the TestCreator is done in another thread.
So it has to be switched to the SWT thread, to update the user interface. This is done
66

te.evaluation.configuration
rte.evaluation.perform
6.3 Implementation of the GUI with Java
rte.evaluation.perform rte.evaluation.ui.content
java.lang
LogPanel FileBrowser
1
TestTemplatePool
1
1
RteGeneratorPool
1
Test
◭ uses 1
◭ uses 1
◭ creates, shows
1
1
TestPerformPanel
∗
1
IRunnerCallback
1
1
◭ creates
IEvaluationWindow
ContentProvider
TestStepPerformPanel
∗
∗
∗
creates, uses ◮ 1
TestPerformer
TestCreator
Figure 6.10: Class diagram rte .evaluation.ui.perform
∗
1
Runnable
PerformComponent
rte.evaluation.ui.dialogs
TestEditDialog
ITestPerformer
Callback
67

Chapter 6 Implementation of the Test Environment
with the interface java.lang.Runnable, which is executed in the SWT thread. So all
classes of this package additionally implements this interface.
There are two ways to create an object of the class Test. The test directory can
still exist and the object is created from TestPerformPanel. If the test does not exist,
the TestCreator has to copy all files to this directory first. Then the object is created
from the TestCreator.
The several classes of the package rte .evaluation.ui.perform are now described.
TestPerformPanel To fit into the main window, this class implements the interface
IEvaluationWindowContentProvider. It displays a sidebar at the left, where the tests
and RTE generators can be chosen. Therefor the objects of TestTemplatePool and
RteGeneratorPool are needed. In the middle of the window is a LogPanel displayed to
show the log of the test. At the right side is a TestStepPerformPanel and a FileBrowser
shown. The first is to perform every test type separately. The second is to access the
test directory directly from the GUI.
TestStepPerformPanel This widget displays some PerformComponents to access
every test type separately. It implements the interface ITestPerformerCallback to get
notified about the execution of the several test types. So the PerformComponents are
updated to show the current state of the execution.
PerformComponent This class provides two buttons to start a test type or edit
the result of it. The result is also displayed.
6.4 Implementing Tests with Perl
The test types are implemented using Perl scripts, that are executed, if the test type
is performed. This section explains, how these Perl scripts are implemented.
If a test type is performed for a test, the Perl script is executed in the test directory.
The variables, that are specified for a test will be set as variables of the environment 1 ,
so that the script can access them.
Some functions are typically used in several scripts, which belong to the special
requirements of the execution context of the script. These functions are outsourced to
another Perl file, to use them in all scripts.
6.4.1 Utilities for Test Scripts
There are some functions, which are used in the scripts of several test types. These
functions are outsourced to the file utils.pm to use them in the other scripts and they
are described in the following.
1 The global environment, in which the Perl script is executed, is meant and not the evaluation
68
environment.

6.4 Implementing Tests with Perl
substitute (string) This function substitutes occurrences of “$(variable)” with the
value of the variable. The substitution is also done for the substituted values. This
function is normally just called by the function get value.
get value (variable, std value) It returns the value of the given variable. Substitutions
with substitute () are already done. The second argument is used to set a
standard value, which is returned if the variable is not defined. This function is typically
used to get the values for the variables, which are defined by the environment.
trim (string) This function cuts off the leading and trailing whitespaces of a string.
execute (executable, command line, proceed if fail) This function executes a
given file with the given command line as argument. If the executed command returns
a value, which is not 0, the script is exited with this return value. This can be
invalidated by setting the last argument. Then the function returns in every case after
the execution of the command and the return value of the function is the return value
of the command.
execute in dir (dir, executable, command line, proceed if fail) If it is necessary
to execute a command not in the current directory, this function can be used.
It does nearly the same than the function execute(), but a directory can be specified,
in which the execution should be proceeded. So the directory is changed before the
command is executed and it is changed back after the execution.
The following functions operate on arrays. They are typically used in the scripts to
process an array of file names.
prefix (prefix, array) This function adds the given prefix to every value in the
array.
suffix (suffix, string) This function adds the given suffix to every value in the
array.
uniq (string) This function sorts the array and it removes duplicates from the array.
So every value is in the resulting array just contained once.
6.4.2 Scripts for the Test Types
This section should show how the scripts for the test types can be implemented and
how the functions from the previous section can be used. As an example is the test
type “accept configuration” used. The Perl script is shown in listing 6.1.
First the module utils.pm from the previous section is included. IO::Handle is used
to set the autoflush for the standard output and the error output. This is needed that
the output is directly written and it is not lost, if the script terminates too fast.
The directory in which the output of the RTE generator is stored has the name
“RteGenOutput”. This directory is created and a warning is printed, if the directory
still exists. Then the array @autosar files is created, which contains all AUTOSAR
69

Chapter 6 Implementation of the Test Environment
1 use strict;
use utils;
use IO::Handle;
autoflush STDOUT 1;
autoflush STDERR 1;
my $output path = "RteGenOutput";
10 unless (−d $output path) {
mkpath ($output path, 0);
} else {
print "directory $output path still exists\n"
}
my @autosar files = (
glob ("TestConf/∗.arxml"),
glob ("TestConf/∗.xml"),
glob ("TestConf/∗.epc"),
20 );
$ENV{TEST CONF} = join (" ", prefix ("../", @autosar files));
execute in dir (
$output path,
get value ("RTE EXECUTABLE"),
get value ("RTE COMMAND LINE")
);
30 exit 0;
70
Listing 6.1: Perl file for the test type “accept configuration”

6.5 XML Scheme
configuration files. This are the files with the extensions “.arxml”, “.epc”, “.xml” in
the directory “TestConf”. Normally the extension, which is specified by AUTOSAR,
is “.arxml”. However, the other extensions are used by the GEENSYS AUTOSAR
Builder and so they are used here, too.
With the use of the function prefix the prefix “../” is added to every file in the array
added, because the RTE generator should be called from the directory “RteGenOutput”
and therefor the relative paths of the files have to be adjusted. The resulting
array is composed to a single string that the files can be passed via command line.
This string is set to the environment variable “TEST CONF”, which is used in the
command line of the generator. Then the RTE generator is called in the directory
“RteGenOutput”. For the execution the path to the generator and the command line
is got with the function get value(), which does also the substitution of the variables
in the command line and in the options.
It is just necessary to exit the script with success, because, if the generation of the
RTE fails, the function execute in dir exits the script with an error.
6.5 XML Scheme
To use the XML parser from Java to check the configurations, XML schemes are used.
This allows to parse the configuration and use them without doing a lot of checks
first. In section 6.3 is the class XMLParser used multiple times and there exist some
different XML schemes like e.g. for test templates, RTE generators and test results.
However, only the scheme for the test templates is explained in this section in detail.
It is shown in listing 6.2.
First are some definitions done, which are also used in the other schemes. Then
a root element is defined with “definitions”. This root element contains the other
configurations. The tag means, that the type of this element is
composed by others. The tag defines some other elements, which occurs at
most once and in an arbitrary sequence. So the order of the elements in the XML file
can be changed.
The “number” and “name” tag have to exist and so they are always set. The others
are optional, but the environment handles e.g. an empty test type in the same way as
a wrong test type and displays an configuration error.
The files are mainly parted in two kinds of elements. The one are simple values
like “name”, “description” or “number”. The others are lists of elements. The class
ConfigurationStore, which is described in section 6.3.2, provides methods for the access
of the XML structure. These methods are to access these two kinds of elements.
An example of a configuration for a test template is shown in listing 6.3.
6.6 Launching the Test Environment
The Java implementation is packed to the file RteEvaluation.jar, which is located
in the base directory of the environment. This file contains the classes described in
71

Chapter 6 Implementation of the Test Environment
1
10
20
30
40
50
60
72
Listing 6.2: XML scheme for the test templates

1
Mode Test
0300
run RTA-OSEK5.0 for PC
ECU AUTOSAR PATH
/system root/system/system topology instance∗/ecu
10
ECU NAME
ecu
Ecu/0300 mode test
20
global configs/interfaces
global configs/types
System/0300 mode test
30
Original
$(ATOMIC ASSIGN TYPES)
Listing 6.3: XML example for a test template
6.7 Summary
section 6.3 and the XML schemes described in section 6.5. The SWT library for the
GUI is not contained in this file. It is located in the file swt.jar in the same directory.
The environment have to be started with the command
java −j a r RteEvaluation . j a r
and the file swt.jar has to be in the same directory. Normally this call is done automatically
by the operating system, if a file with the extension “.jar” is started. If not,
the file RteEvaluation.bat provides the same call.
6.7 Summary
In this chapter first some implementation decisions are addressed. Afterwards some
screenshots of the GUI are shown and explained. Then an overview of the implementation
of the GUI is given. Some class diagrams show a first introduction to the source
code and these should be the first destination for extending the application.
Then an introduction of the Perl files is given and it is shown, how the test types
are implemented. The XML scheme for storing the configurations is explained and it
is also described, how the application can be started.
73

Chapter 6 Implementation of the Test Environment
74

Chapter 7
Test Cases
The environment would be very useless without test cases. So this chapter first deals
with some explanations for creating test cases. After that some test cases, which are
created during this work, are explained in detail.
7.1 Creating Test Cases
For creating a test, first it has to be decided what feature or what combination of
features should be tested. With the test cases, which were created during this work,
several bugs were found. Need for changes for MEDC17 were not derived during this
work. Some little things for MEDC17 are described in section 7.1.4, but some of them
were known before this work started. The bulk of the found bugs belongs to the RTE
generator and it turned out that before an integration test for MEDC17 is created
and performed, the same combination of features should be tested with the PC–OS.
So it can be ensured, that the feature works for a natively AUTOSAR environment.
After that an integration in MEDC17 can be considered. This section gives some
information and hints for creating tests for the different types.
7.1.1 Tests to Accept or Reject
The test cases, which shall be rejected from the RTE generators, are typically configurations
which are explicitly marked as not valid in the AUTOSAR specification. Here
are some examples for this.
• A configuration with a SWC which has a required port that is not connected to
a provided port is an invalid configuration and has to be rejected.
• A SWC, which has a server port, has to provide a runnable for each operation,
which is specified by the interface of the port. The runnables are triggered with
an OperationInvokedEvent. If a component does not provide a runnable for an
operation, this configuration is invalid and shall be rejected.
• All OnEntry and OnExit triggered runnables for a mode switch, shall be mapped
to the same task. If this is not the case, the configuration shall be rejected by
the RTE generator.
75

Chapter 7 Test Cases
These examples show, that such tests can be really small. It makes no sense to
combine the tests, because each invalid configuration shall be rejected and not just
the combination of some invalid features.
Configurations that should just be accepted and nothing else like compiling or reviewing
the code should be done are really rare. Because typically for an accepted test
something else should be checked. Here is one example of a test that is just done by
accepting the configuration.
• For a SWC with a provided and a required port of the same interface it is allowed
that these two ports can be connected. This is a case, the generator shall accept
and create the RTE.
Here can also the functionality of this port be tested, but in this form it fits to some
other test cases, which handles some invalid connections.
7.1.2 Code Review of Tests
The test type for code review is typically used to check an efficient implementation.
To do this automatically would cost a lot of effort, but to just take a short look at the
code is much easier.
Typically, it is not a priori expected for a configuration that this should be tested
with a code review. However, typically an inefficient implementation is found by
creating a test for other things. Then the configuration can be used to create such a
test out of this. This test can be used to check newer versions of the RTE generator
to ensure that the inefficiency is fixed.
7.1.3 Tests for the PC–OS
To create a test for the PC–OS, some preconditions should be followed. The behavior
of the SWCs has to be implemented in such a way, that the tested issues really occur
and that the result can be obtained by the components itself. The components can
then create an output to figure out the result of the test.
As described in section 5.2.5 an error can be communicated to the environment by
creating an output, that starts with the string “ERROR”. So the behavior have to be
checked by the components and if something goes wrong, an error output should be
created. The function printf (const char∗,...) of the C standard library can be used
by the runnables to create the output.
Typically tests for systems that are split into several tasks are setup to test data
consistency. The data consistency is often vulnerable, if one task interrupts another
task. So it is often necessary to provoke such an interruption of tasks. It is really
hard to do this with TimingEvents and to ensure that the interruption really takes
place. So it turned out that DataReceivedEvents are a good mechanism to ensure an
interruption at a defined position. The data has to be sent from a runnable through a
port to another runnable, which is triggered by a DataReceivedEvent. The receiving
76

7.1 Creating Test Cases
runnable has to be executed with a higher priority than the sending runnable. So it
can be ensured that the current execution is really interrupted.
To check the consistency, some global variables can be used to communicate between
the components without using the RTE. It has to be ensured that this global variables
cannot contain wrong values.
7.1.4 Tests for Integration in MEDC17
The integration in MEDC17 is more complex than a test for the PC–OS. In chapter
3 it is described that the tasks of MEDC17 are mainly based on a periodic execution
and that the whole application software also uses this timings. For integration of
AUTOSAR code in MEDC17, not only TimingEvents should be considered, but this
is the first approach.
The RTE is just another piece of application software that runs on MEDC17. To
initialize the RTE a call of Rte Start() has to be done. The RTE generators from
ETAS are extended with an option supporting the integration of AUTOSAR tasks in
MEDC17. This option is called “−−task−as−function” and leads to the generation
of functions instead of tasks in the generated code from the RTE generator.
100ms
100ms
OS Drv 100ms (AUTOSAR task)
run1 run2 . . . runn
OS Drv 100ms (MEDC17 task)
Rte Task OS Drv 100ms
(Function)
p1 p2 . . . pm
TASK( OS Drv 100ms )
{
. . .
TerminateTask ( ) ;
}
FUNC( void , RTE APPL CODE)
Rte Task OS Drv 100ms ( void )
{
. . .
}
Figure 7.1: Visualization of the Task as Function Method
The example in figure 7.1 shows how this option can be used to bring a AUTOSAR
task to MEDC17. The existing MEDC17 task is time triggered. The RTE generator
creates an AUTOSAR task, which is also time triggered by the same period.
Instead of changing the operating system configuration of MEDC17 to schedule the
AUTOSAR task, this task can easily be used as a MEDC17 process. The task body
of the AUTOSAR task OS Drv 100ms is changed to a function body of the function
Rte Task OS Drv 100ms by using the option. This function is added to the processes
of the MEDC17 task with the same name. So the AUTOSAR runnables are executed
in the same timing as before. However, to do this some conditions have to be satisfied.
77

Chapter 7 Test Cases
• The AUTOSAR task content has to be executed in the same timing. This is
obviously true for the shown example
• The code out of the AUTOSAR tasks shall not do any task handling. If there is
e.g. a call of ChainTask(OS Drv 100ms), then this call is added to the MEDC17
task. The MEDC17 task will be restarted after termination, but this also restarts
the original MEDC17 processes p1, . . . , pm and this will change the original
behavior.
• The MEDC17 tasks and the AUTOSAR tasks should have the same priority.
This is not necessary for only one task, but if the RTE generator does some optimizations,
which depends on the priority of all tasks and the tasks are executed
in MEDC17 with different priorities, this can cause an unexpected behavior.
This option cannot only be used to integrate time triggered AUTOSAR tasks into
MEDC17. Also other RTE events can be used, but this should be done in a different
task.
To handle other tasks, the operating system configuration has to be changed. This
configuration is strongly included in the whole toolchain and the code of the tasks
are typically auto generated at every build. So to use a task, which is generated
from the RTE generator, a big change at the toolchain has to be done. The option
“−−task−as−function” provides way out to simply integrate other tasks into
MEDC17.
The MEDC17 configuration has also be changed and tasks have to be added, but
the toolchain can be left unmodified. The new task should contain one process, which
will be the function, which is created from the RTE generator instead of the task.
This is shown in figure 7.2. So the MEDC17 task just calls the AUTOSAR task. If
the AUTOSAR task does some task handling like ChainTask() calls, there is no issue,
because the MEDC17 task will be scheduled, but it only consists of the AUTOSAR
task body.
Rte Task1 (MEDC17 task)
FUNC( void , RTE APPL CODE)
Rte Task Rte Task1 ( void )
{
. . .
ChainTask ( Rte Task1 ) ;
. . .
}
Figure 7.2: AUTOSAR task as only process in MEDC17 task
MEDC17 cannot use an output to show an error, but in principle the test cases
should be designed in the same way as for the PC–OS. The errors should be figured
out by the SWCs itself. Since no output can be created, a variable can be used, which
will be set if an error occurs. This variable can be observed with the debugger to
figure out, if the execution is done correctly or not. It tended to be useful, to use
78

7.2 Example: Mode Test
additional variables, which count the execution of the AUTOSAR runnables. This
helps to determine if the runnables are really executed and to find errors.
During this work, the configuration of the used MEDC17 PST was extended to
support the task Rte Task1 from figure 7.2. This task can be used in the described
way and an example is given in section 7.3.
For the integration in MEDC17 also a customized library has to be used. The
customization is not the focus of this work and therefor not described in detail. In
principle there are some operating system calls for accessing resources used. These
have to be substituted, because the used operating system resource does not exist
in MEDC17. Additionally, the include file “Os.h” is changed to “AutosarOs.h” to
prevent a clash with the ERCOSEK includes. Everything, which is really needed for
the RTE is put into the file “AutosarOs.h”.
However, the file “AutosarOs.h” have also be used in the generated files. For this
reason the option “−−os−hdr” is desired from BOSCH for the RTE generators from
ETAS, which changes the name of the include file “Os.h”.
7.2 Example: Mode Test
The first example 1 , which should be considered, handles some basic mode functionality
and uses the test type “run RTA–OSEK5.0 for PC”. Modes are introduced in section
2.4.5 and there is also a sequence described with figure 2.6, which have to be preserved
for a mode switch. This sequence should be tested with this case. In concrete the
following items are of interest:
• Mode dependent runnables shall only be executed, if the mode, on which they
are depend, is active.
• Runnables that are triggered by an OnExit event of the active mode shall not
be executed until all mode dependent runnables are finished.
• Runnables that are triggered by an OnExit or an OnEntry event shall be executed
in the correct order. This means that the runnables that are triggered
by OnExit events are executed before the runnables that are triggered by an
OnEntry event.
7.2.1 Configuration of the Mode Example
The configuration for this example is visualized in figure 7.3. It consists of three SWCs.
SWC1 provides the current mode through the sender port to the other components.
The mode group OnOffModeGroup, which is used in this example, consists of the two
modes “on” and “off”. SWC1 induces some mode switches to the other components
and run11 is triggered by an DataReceivedEvent.
The runnables of SWC2 are both triggered by a timing event every 100ms. The
event, which triggers the runnable run on, is disabled in mode “off” and the event,
1 This example has number 0300 in the environment.
79

Chapter 7 Test Cases
SWC1
run11
SWC2
run on run off
OnOffModeGroup
SWC3
on exit off entry off exit on entry
Virtual Functional Bus
Figure 7.3: VFB diagram for mode example
Task1
Priority 3
Task2
Priority 1
Task3
Priority 1
direct access
DataReceived
which triggers the runnable run off, is disabled in mode “on”. So that both runnables
are just active in one mode.
The runnables of SWC3 are triggered with OnExit and OnEntry events, according
to their names. So e.g. the runnable on exit is triggered, if the mode “on” is exited. In
comparison with figure 2.6, the runnables of SWC2 are the mode dependent runnables
and SWC3 contains the OnExit and OnEntry runnables.
For a test typically the interesting situations or collisions are provoked. For this
example it would be interesting to execute the runnables of SWC3 with a higher
priority than the runnables of SWC2. In this case, the runnables from SWC3 could
interrupt the runnables run on and run off. This has to be prevented and for a mode
switch, the RTE generator has to create code, in which the triggering of the runnables
in SWC3 is delayed while run on or run off is active.
However, this combination is not allowed by the AUTOSAR specification. Instead
the task, in which the runnables are executed with a ModeSwitchEvent, cannot have a
higher priority than any task, in which a mode dependent runnable is executed for the
same mode. This means for this example, that Task3 cannot have a higher priority
than Task2. So the least that can be done is to use the same priority for both tasks.
The AUTOSAR specification also prohibits that the runnables triggered by an
OnEntry event are mapped to a task before the runnables that are triggered by OnExit
events. This makes sense and avoids a source of error.
7.2.2 Implementation of the Mode Example
The source code for the components is shown in the listings 7.1, 7.2 and 7.3. The
header file in listing 7.4 contains some declarations that are used for all components.
There are some global variables used to indicate the current state of the system.
These variables are set and checked by the runnables itself to detect errors. The
runnable run11 is triggered with a DataReceivedEvent through the receiver port and
it requests a mode switch at every call.
The variable mode switch indicated is set by the runnable run11 to show that a
mode switch was indicated. If this variable is set, no mode dependent runnable should
80

10
1 #include
#include "Rte swc1.h"
#include "test.h"
int mode switch indicated = 0;
int runnable active = NO RUN;
int current mode = TEST MODE TRANSITION;
int activation count on = 0;
int activation count off = 0;
FUNC(void, RTE APPL CODE) run11(void)
{
mode switch indicated = 1;
}
7.2 Example: Mode Test
if (Rte Mode pport11 OnOffModePrototype() == RTE MODE OnOffModeGroup Off)
Rte Switch pport11 OnOffModePrototype (RTE MODE OnOffModeGroup On);
else
Rte Switch pport11 OnOffModePrototype (RTE MODE OnOffModeGroup Off);
Listing 7.1: Source code for SWC1 (swc1.c)
be started, but mode dependent runnables can be still active. At the begin of the
runnables run on and run off, this variable is checked. Additionally, it has to be ensured,
that run11 cannot interrupt these runnables before this check. This is done with
the DataReceivedEvent, which can only occur at defined positions in the runnables
run on and run off.
The runnables triggered by an OnExit event of SWC3 should only be executed,
if the variable mode switch indicated is set, because then a mode switch was really
requested. This is checked within these runnables and the variable is reset to use it
for the next switch.
The variable runnable active is set by the runnables run on and run off to show,
that one of these is still executed. During such an execution no runnable of SWC3
shall be started, because they are all triggered by a ModeSwitchEvent. This is also
checked within these runnables.
The runnables of SWC3 use the variable current mode to provide the currently
active mode of the application to the other components without using the RTE API.
This value should contain the right mode, because for every mode switch a runnable
of SWC3 shall be executed and this updates this variable.
Again, there shall be no inconsistency for this variable, because only one of the
runnables of SWC2 and SWC3 shall be active at a time. This assumption depend on
a correct behavior of the RTE, but if there is an error it should be found.
At least, there are two count variables. They are just used for every mode to count
the numbers of execution of run on and run off and to switch the mode at the fifth
call in every mode. This variables are reset if a mode is entered.
81

Chapter 7 Test Cases
1 #include
#include "Rte swc2.h"
#include "test.h"
FUNC(void, RTE APPL CODE) run off(void)
{
runnable active = RUN OFF;
if (mode switch indicated)
10 printf ("ERROR mode switch was indicated, but a mode depending runnable is �
executed\n");
if (current mode != TEST MODE OFF)
printf ("ERROR runnable run off activated, but mode off is not active\n");
activation count off++;
if (activation count off > 5)
Rte Write pport21 intValue (1);
20 runnable active = NO RUN;
}
30
40 }
FUNC(void, RTE APPL CODE) run on(void)
{
runnable active = RUN ON;
82
if (mode switch indicated)
printf ("ERROR mode switch was indicated, but a mode depending runnable is �
executed\n");
if (current mode != TEST MODE ON)
printf ("ERROR runnable run on activated, but mode on is not active\n");
activation count on++;
if (activation count on > 5)
Rte Write pport21 intValue (2);
runnable active = NO RUN;
Listing 7.2: Source code for SWC2 (swc2.c)

1 #include
#include "Rte swc3.h"
#include "test.h"
7.2 Example: Mode Test
FUNC(void, RTE APPL CODE) off entry(void)
{
if (runnable active != NO RUN)
printf ("ERROR runnable off entry is executed, but mode dependent runnable �
is still active\n");
10 if (current mode != TEST MODE TRANSITION)
printf ("ERROR runnable off entry is executed, but mode was not in �
transition.\n");
}
activation count off = 0;
current mode = TEST MODE OFF;
FUNC(void, RTE APPL CODE) off exit(void)
20 {
if (runnable active != NO RUN)
printf ("ERROR runnable off exit is executed, but mode dependent runnable �
is still active\n");
if (!mode switch indicated)
printf ("ERROR runnable off exit executed without a mode switch �
indication\n");
if (current mode != TEST MODE OFF)
printf ("ERROR runnable off exit is executed, but mode off was not �
active.\n");
30 mode switch indicated = 0;
current mode = TEST MODE TRANSITION;
}
FUNC(void, RTE APPL CODE) on entry(void)
{
...
38 }
40
FUNC(void, RTE APPL CODE) on exit(void)
{
...
44 }
Listing 7.3: Source code for SWC3 (swc3.c)
83

Chapter 7 Test Cases
1 #ifndef TEST H
#define TEST H TEST H
#define TEST MODE ON (1)
#define TEST MODE OFF (2)
#define TEST MODE TRANSITION (3)
#define RUN ON (1)
#define RUN OFF (2)
10 #define NO RUN (0)
extern int current mode;
extern int activation count on;
extern int activation count off;
extern int mode switch indicated;
extern int runnable active;
#endif /∗ TEST H ∗/
Listing 7.4: Shared header file for the components of the example (test .h)
7.2.3 Modification of this Example
From this example easily some other test cases can be derived. Instead of using two
tasks for the runnables of SWC2 and SWC3, only one can be used for the runnables
of both components. This just requires another ECU specific configuration, thus the
part of the configuration, which is located in the “Ecu” directory of the resources. The
part of the configuration, which is located in the resource directory “System”, can be
reused.
If the runnables e.g. mapped to one task with the runnable to task mapping sequence
2
on exit − off exit − run on − run off − on entry − off entry
and a mode switch from mode “on” to mode “off” during an execution of runnable
run on occurs, the following sequence 3 shall be executed from the RTE
run on → on exit → off entry
to reach mode “off” correctly. The RTE generator has to create source code for the
task, which supports this execution and shall not execute off entry before on exit.
This is obviously possible with an incorrect implementation and the used mapping
sequence.
7.2.4 Conclusion
The mode example passes the test without an error. Nevertheless, by creating this test
case an error was found. The RTE generator from ETAS created a wrong identifier
2 This is just the sequence in the task and not the sequence, in which the runnables are necessarily
executed. The execution can be prevented by some enclosing code like it is done with the timing
events in the example in section 2.8.
3 Here the real execution sequence is meant.
84

7.3 Example: DataReceivedEvent in MEDC17
for the API. Instead of the identifier RTE MODE OnOffModeGroup Off, the name
RTE MODE Off was created. This is no functional fault, but it prevents to compile
the example in the original form and it does not fulfill the AUTOSAR specification.
Now, this bug is fixed in an current version of the generator.
7.3 Example: DataReceivedEvent in MEDC17
A second example 4 is a test case, which addresses the integration of AUTOSAR software
in MEDC17. A test case is used, which does not only use TimingEvents for
triggering runnables, but also DataReceivedEvents, which are natively not used in
MEDC17. This example does not really test some special behavior of the generated
code. The aim is just get the DataReceivedEvents run in MEDC17.
7.3.1 Configuration of the MEDC17 Example
SWC1
run11 run12
SWC2
run21
Virtual Functional Bus
OS Drv 100ms Task
Rte Task1
direct access
DataReceived
Figure 7.4: VFB diagram for MEDC17 integration example
This example is visualized in figure 7.4. There are just two SWCs used. Runnable
run11 is triggered by a timing event every 100ms and it is executed in the task
OS Drv 100ms Task. It sends a value through the port and triggers runnable run21
with the DataReceivedEvent. The runnable run21 sends also a value and triggers
runnable run12. The priorities of the tasks are not of interest for this example, but
the sequence of the runnables run12 and run21 are of interest. Runnable run21 is
mapped behind of run12 in the task Rte Task1. The aim is, that with the sent value
from run21 the task has to be restarted to trigger run12 after.
The names of the tasks are the same as in MEDC17. This is needed to use the
option “task–as–function” of the RTE generator. As described in section 7.1.4, the
used MEDC17 PST is extended to support also the task Rte Task1.
This case is evolved after a similar test case and a look at the source code. The RTE
generator created a call for ChainTask() at the end of the task. So a configuration was
searched, which explicitly forces the call of this function. It is expected that there are
no problems, since this is just an operating system call.
4 This example has number 0121 in the environment.
85

Chapter 7 Test Cases
7.3.2 Implementation of the MEDC17 Example
The implementation of the components of this example is shown in the listings 7.5 and
7.6. Runnable run11 counts a variable up to 50 and sends the current value through
the sender port at every call. A global variable is set to indicate that a value was
sent. The runnable run21 should be triggered with the sent data. It checks with
the global variable data send pport11 if really a value was sent. If no data was sent,
the variable error triggered without data rport21 is set to indicate an error. Then it
writes the received value to the sender port. The global variable data send pport21
should indicate that really a value was sent through this port. This is checked by
the runnable run12, which is also triggered by DataReceivedEvent. The variable
error triggered without data rport21 is set, if runnable run12 is executed without sent
data.
1 #include
#include "Rte swc1.h"
Int32 received at rport12 = 0;
Int32 data send pport11 = 0;
Int32 data send pport21 = 0;
Int32 error triggered without data pport21 = 0;
FUNC(void, RTE APPL CODE) run11(void)
10 {
static Int32 counter = 0;
15
20
}
30 }
counter++;
counter %=50;
data send pport11 = 1;
Rte Write pport11 intValue(counter);
FUNC(void, RTE APPL CODE) run12(void)
{
if (!data send pport21) {
error triggered without data pport21 = 1;
}
data send pport21 = 0;
Rte Read rport12 intValue(&received at rport12);
Listing 7.5: Source code for SWC1 (swc1.c)
So the variables received at rport12 and received at rport22 are set to the received
values. These variables and the two variables that indicates an error should be watched
with the debugger to ensure the correct functionality of this example.
86

10
1 #include
#include "Rte swc2.h"
Int32 received at rport22 = 0;
Int32 error triggered without data pport11 = 0;
extern Int32 data send pport11;
extern Int32 data send pport21;
FUNC(void, RTE APPL CODE) run21(void)
{
if (!data send pport11) {
error triggered without data pport11 = 1;
}
data send pport11 = 0;
Rte Read rport22 intValue(&received at rport22);
20 data send pport21 = 1;
Rte Write pport21 intValue(received at rport22);
}
7.3.3 Execution
7.3 Example: DataReceivedEvent in MEDC17
Listing 7.6: Source code for SWC2 (swc2.c)
For the integration in MEDC17 some special RTE generator options are necessary.
The test template is configured with the following options:
$(OS HDR AUTOSAR H) $(ATOMIC ASSIGN TYPES) $(OS ERCOSEK) �
$(TASK AS FUNCTION ENABLE)
The options are described in the following.
OS HDR AUTOSAR H This option effects, that the RTE generator uses the
header file “AutosarOs.h” instead of “Os.h” in the generated files. This option is
desired from BOSCH and available for the generators from ETAS.
ATOMIC ASSIGN TYPES This option specifies some data types as atomic. So
the generator does not need to enclose an access to this data types with a lock in the
generated code. In principle, this option is just used for performance reasons.
TASK AS FUNCTION ENABLE This option is described in section 7.1.4 and
it is also desired from BOSCH for the generators from ETAS.
OS ERCOSEK This option addresses some special needs for ERCOSEK and is also
desired from BOSCH for the ETAS RTE generators. It e.g. prevents the generator
from creating extended tasks. So, if it normally produces an extended task for a configuration,
the RTE generator produces an error with this option, because ERCOSEK
cannot handle extended tasks.
87

Chapter 7 Test Cases
1 FUNC(void, RTE CODE)
Rte task Rte Task1(void)
{
if ( Rte ActCount SWCI0 DataReceived != FALSE )
{
Rte ActCount SWCI0 DataReceived = FALSE;
run12();
}
if ( Rte ActCount SWCI1 DataReceived != FALSE )
10 {
Rte ActCount SWCI1 DataReceived = FALSE;
run21();
}
if ( ( Rte ActCount SWCI0 DataReceived != FALSE ) | | ( �
Rte ActCount SWCI1 DataReceived != FALSE ) )
{
ChainTask(Rte Task1);
}
}
Listing 7.7: Source code for Task1 as function (Task1.c)
The RTE generator creates functions instead of a tasks. The generated code for
the function Rte Task Rte Task1 is shown in listing 7.7. The runnables are executed
only, if a DataReceivedEvent occurs. The function has to be added to the MEDC17
task Rte Task1 as the only process. So the call of ChainTask (Rte Task1) at the
end of the function causes a restart of the MEDC17 task and there only one process
(Rte Task Rte Task1) is executed. Therewith a restart of the AUTOSAR task, as it
is expected by the RTE, is done without any side effect.
The auto built of MEDC17 succeeds and the resulting file can be downloaded to the
control unit. A debugging of the target results in the expected behavior. The variables
received at rport12 and received at rport22 counts nearly simultaneously up to 50.
The variables, which indicate an error, keep the value 0 during the whole execution.
7.4 Found RTE Generator Bugs
In this section, some of the bugs, which were found during this work, are listed. They
show exemplarily the problems coming up with the complexity of AUTOSAR. The
described bugs are not explained in detail like the other examples.
One issue was already noted with the mode example, were the wrong API identifiers
were created.
7.4.1 Implicit API buffers copied twice
The first issue that should be considered is an inefficient implementation for the implicit
API. A runnable that accesses a port with a DataReadAccess can read the value
from the port multiple times during one execution and should every time get the same
result. The requirements for the implementation of the implicit API describes more.
88

7.4 Found RTE Generator Bugs
The values which are accessed with the implicit API during a task execution have to
be copied at the begin of the task for every runnable. If the same value is accessed
from different runnables, the same buffer shall be used for the runnables.
1 TASK(Task1)
{
...
4
Rte GetResource();
Rte ImplicitBufs.o1. Task1.sbuf0.value = Rte RxBuf 2;
Rte memcpy(&Rte ImplicitBufs.o1. Task1.sbuf1.value, &Rte RxBuf 0, �
sizeof(String8));
Rte ImplicitBufs.o1. Task1.sbuf2.value = Rte RxBuf 1;
Rte ImplicitBufs.o1. Task1.sbuf2.value = Rte RxBuf 1;
10 Rte memcpy(&Rte ImplicitBufs.o1. Task1.sbuf1.value, &Rte RxBuf 0, �
sizeof(String8));
Rte ReleaseResource();
14
}
...
TerminateTask();
Listing 7.8: Source code for Task1 of the inefficient handling of the implicit API
(task1.c)
An example with that API was fed into the RTE generator. The generated code
for a task is shown in listing 7.8. There is one buffer used for every communication
and every buffer is copied at the begin of the task. However, two of the buffers are
copied twice, which takes not really an effect instead of being inefficient, especially for
the string, which is used in this example. Now the bug is fixed in an RTE generator
update.
7.4.2 DataReceivedEvent without DataReceivedEvent
This is a real bug, which causes wrong behavior for the execution and not just inefficiency.
The bug is trivial and it appeared completely unexpected.
1 TASK(Task1)
{
TerminateTask();
}
Listing 7.9: Source code for Task1 of the wrong DataReceivedEvent handling (task1.c)
With a DataReceivedEvent, a runnable is triggered, if data is received at a port. This
implies not that this data is really read from this port by the runnable. This have to be
additionally configured by a DataReceivePoint or a DataReadAccess. A configuration
with a runnable that is just triggered by a DataReceivedEvent but doesn’t read the
value, was fed into the RTE generator. The resulting source code can be seen in listing
89

Chapter 7 Test Cases
7.9. The source code for the task is created, but the runnable is not called there. This
bug has been also fixed in a current version of the RTE generator.
7.4.3 Header Files for Composition not created
The composition of atomic software components is described in section 2.4.3. A test
case with a composition was also created and fed into the RTE generator. The whole
test case consists of four atomic software components. The components SWC3 and
SWC4 are put into a composition. The components SWC1 and SWC2 communicate
with this composition.
The generated code contains the calls for the runnables of SWC3 and SWC4, but
the header files for this components are not created. Only header files for SWC1 and
SWC2 were created.
This prevents from compiling the components, because in the header files are also
some #define directives, which have to be used for the communication of the components.
7.5 Summary
In this chapter first some hints for creating test cases are described. It is also explained,
how an integration in MEDC17 can be done with little effort for some AUTOSAR
mechanisms. Then two test cases are discussed in detail.
The mode example is executed with the OSEK–OS for PC operating system. This
was not possible before this work. So there is now a very good possibility to test
AUTOSAR features without a control unit. Together with the found bugs, this seams
to be necessary to ensure the correct functionality first. Afterwards, a test at a control
unit can be considered.
The second example addresses a test at the control unit. It shows, how the integration
in MEDC17 can be done. The execution of only time triggered runnables
was possible with the option “−−task−as−function” from the RTE generator. The
integration of a DataReceivedEvent into MEDC17 was first done in this work.
Some bugs, which were found during this work, are also shown in this chapter.
90

Chapter 8
Conclusion
8.1 Reached Goals
During this work, the requirements were worked out and a test environment was
implemented to fulfill one part of this requirements. The others are achieved with the
test cases, which were created.
The environment supports creating and performing tests. They can be easily performed
with another RTE generator and it can be performed in several ways. More
variance, than estimated at the beginning, had to be handled by the environment.
The idea to use the OSEK–OS for PC operating system evolves during this work. It
was integrated in the environment. This involves a great benefit for testing functionality
without a control unit and extends the possibility for automatic test execution.
The created tests cover some of the basic functionality of AUTOSAR release 2.1.
The implementation of the GUI takes a lot of effort and not all features demanded
by the requirements are considered with tests. So for example testing the resource
consumption, which belongs to the requirements REQ306 and REQ307, wasn’t done.
Nevertheless some bugs of the RTE generators were found, which is a benefit for the
evaluation and this work.
8.2 Perspective
There are some ideas to extend the environment for further usage. From ETAS is a
PC operating system announced, which is compliant to AUTOSAR release 3.0. This
operating system may be integrated with another test type in the environment.
If an RTE generator is available for the AUTOSAR release 3.0, the environment
should also be extended with tests for this new release.
For this work it was not necessary to keep track about changes for test templates.
So if a test is performed with a generator and after that the test template is changed,
it is not recognized. The main work was done with the latest version of the generator
at a time and there was no need to update the tests for older versions. So there was
no need for this feature. However, it is an extension, which may be added to the
environment.
Another feature, which may be added is an import and export function for the
test templates. This makes it easier to migrate tests from one computer to another.
91

Chapter 8 Conclusion
Since a template typically requires different resources, a way should be found, that an
imported resource does not overwrite an existing one.
8.3 Impressions
The upcoming AUTOSAR standard specifies a lot of features and mechanisms and
there are a lot of car manufactures involved in creating this standard. It seams that
AUTOSAR is a superset of the mechanisms that all car manufactures use and this
leads to a huge complexity. Normally it is just necessary to support the mechanism
used in the own software. Now it becomes necessary to support all mechanism of
AUTOSAR to provide software sharing.
With the found bugs of the RTE generators it can be seen that it is hard to handle
so much combination possibilities. Maybe an approach, which defines less features
and mechanisms and first takes care about the tool support, would be the better one.
Nevertheless, defining a standard, which is supported by all manufactures, is a good
way.
92

Appendix A
Example
This is the whole configuration of the example from section 2.8, but it does not provide
the ECU configuration, which have to be also provided create the RTE. But the file
shows the complexity of the XML configuration for such a simple example. With the
extract of the configuration given in section 2.8 it additionally shows in which way the
configuration can be put in one file.
1
types
Int16
-32768
10 32767
String8
utf8
8
20 interfaces
SR Int16
false
intValue1
/types/Int16
false
30
intValue2
/types/Int16
false
CS string to int
40 false
parse
string
/types/String8
IN
50
value
/types/Int16
OUT
93

Appendix A Example
/interfaces/CS string to int/overflow
60
/interfaces/CS string to int/underflow
overflow
42
70
underflow
43
80 swc root
swc1
pport1
/interfaces/SR Int16
90
rport1
/interfaces/CS string to int
100 swc2
pport1
/interfaces/CS string to int
rport1
110
/interfaces/SR Int16
intBehSwc1
/swc root/swc1
120
Time100ms
/swc root/intBehSwc1/run11
0.1
Time50ms
/swc root/intBehSwc1/run12
0.05
130
run11
false
dwa1
/swc root/swc1/pport1
140
94

interfaces/SR Int16/intValue1
dwa2
/swc root/swc1/pport1
150 /interfaces/SR Int16/intValue2
run11
run12
false
160
dwa2
/swc root/swc1/pport1
/interfaces/SR Int16/intValue1
170
sscp
/swc root/swc1/rport1
180 /interfaces/CS string to int/parse
run12
false
190
intBehSwc2
/swc root/swc2
Time50ms
/swc root/intBehSwc2/run22
0.05
200
operationInvoke
/swc root/intBehSwc2/run21
/swc root/swc2/pport1
/interfaces/CS string to int/parse
210
run21
true
run21
run22
false
220
dra1
/swc root/swc2/rport1
95

Appendix A Example
/interfaces/SR Int16/intValue1
230
dra2
/swc root/swc2/rport1
/interfaces/SR Int16/intValue2
240 run22
false
implSwc1
/swc root/intBehSwc1
src
250 SRC
C
implSwc2
/swc root/intBehSwc2
src
SRC
260
C
comp root
comp
270
swc1
/swc root/swc1
swc2
/swc root/swc2
280
ac1 swc1pport1swc2rport1
/comp root/comp/swc1
/swc root/swc1/pport1
/comp root/comp/swc2
290 /swc root/swc2/rport1
ac2 swc2pport1swc1rport1
/comp root/comp/swc2
/swc root/swc2/pport1
300 /comp root/comp/swc1
/swc root/swc1/rport1
96

system root
310
system topology
ecu
/ecu root/ecu
BATTERY
320 MOST-SIGNIFICANT-BYTE-LAST
system
330 sys mapping
ecu instance
/system root/system/comp instance
340
/comp root/comp/swc1
/system root/system/comp instance
/comp root/comp/swc2
350
/system root/system/system topology instance
/system root/system topology/ecu
360
comp instance
/comp root/comp
system topology instance
/system root/system topology
370
ecu root
ecu
/comp root/comp
380
97

Appendix A Example
98

Appendix B
Requirements of the Functional
Specification
B.1 Main Requirements
REQ000 concrete proceeding for the use
The user shall have a concrete guidance to evaluate an RTE generator.
REQ010 perform evaluation of at least one RTE generator
With the evaluation environment at least one RTE generator shall be tested and
evaluated. The whole process should be documented.
B.2 User Interface
REQ100 simple user interface
The user should have a simple interface to perform the tests and view the results.
REQ101 implementation of the user interface (recommended)
It takes much effort to implement a graphical user interface and on the other hand it
is harder to maintain a graphical solution. So a script based environment should be a
better solution. If there should be time left, this point can be reconsidered.
REQ110 perform tests for special RTE generators
It shall be possible to choose the RTE generator for which the tests shall be performed.
REQ120 perform multiple tests at once
To start every test at its own isn’t very effizient. If possible, some tests shall be
performed at once for the same RTE generator.
REQ130 assistance for tests with human interaction
For some tests user interaction might be required. In this case the test suite should
assist the user as good as possible. E.g. the test suite points out the source code
passage and the user just have to look at it and answer some questions about it.
Maybe this is not practicable for all tests or doesn’t work with all RTE generators
from different suppliers. Then the user has to do more work.
99

Appendix B Requirements of the Functional Specification
B.3 Layout and Organization
REQ200 organize tests and results simple
It shall be easy to access the tests and the results also without using the user interface
(see REQ100). In the following is this requirement refined.
REQ201 store test cases in directory structure (recommended)
The tests shall be organized in a simple way. For this a directory structure could
be a good agreement. Using a database instead, prevents the easy access for the
user. The user shall have the possibility to look at the tests, modify them or
create new ones (see REQ204, REQ205).
REQ202 store RTE generator output for each version and test
The test shall be performed in a separate directory. So the execution of the RTE
generator can’t change or overwrite the original files.
REQ203 store test results for each RTE generator and test
Storing the results makes it possible to compare different RTE generators without
performing the tests again. This especially makes sense for tests which are
performed with human interaction.
REQ204 user can modify tests
The user must have the possibility to change the tests. So he or she can adjust
tests e.g. for new AUTOSAR releases.
REQ205 adding new tests
It should be possible for the user to add new tests to the test suite.
REQ210 distinguish between tests for different AUTOSAR releases
A new release includes new features and maybe some old features are disposed. So
not every test runs with every RTE generator or is conform with every release. So it
makes no sense to test such a combination.
REQ220 allow special test cases for special RTE generator versions
It shall be possible to test special features of special RTE generator versions.
B.4 Provided Tests
Some different types of tests are possible for testing autogenerated code. One concrete
test case can belong to one or more of these types and maybe such types can depend
on each other. A test type mainly describes the way the test can be performed.
For example, if it’s required that invalid configurations are rejected from the RTE
100

B.4 Provided Tests
generator, a lot of test cases with wrong configuration files are possible, but all cases
would be performed in the same way (feeding the RTE generator with the files and
expecting an error). The test suite has to provide some types of tests. In principle it
doesn’t take much work to add a new test case, but changing the test suite to provide
another test type takes more effort. So the test environment should provide a good
base of types for testing the RTE generator.
REQ300 provide good base of test types
In the following are some test types listed, which should be supported by the test
environment.
REQ301 test valid/invalid configuration
The RTE generator shall accept valid and reject invalid input configurations.
The test environment shall provide this. E.g. the ERCOSEK operating system
doesn’t provide extended tasks (see REQ305). So the RTE generator should
reject configurations, which directly describes extended tasks, when it is called
with the option to create ERCOSEK specific code.
REQ302 test ability to be compiled
Test case specific it shall be possible to compile the generated code and keep
track about success.
REQ303 test functionality
The functionality of the generated code should be the functionality, which is
specified in the configuration files. This means, if e.g. in the configuration an
indirect API is specified, than the generated code has to contain the indirect
API and vice versa. To provide and execute this test, maybe a user interaction
is needed. Maybe some parts of this can be done automatically.
REQ304 test behaviour with RTA-OSEK for PC
Some functional tests with the generated code can be done on a PC with RTA-
OSEK for PC. But the code has to be compiled for this operating system. Especially
here, some cases with basic functionality can be created. It ensures,
that this functionality is provided from the RTE-generator. This tests can be
performed automatically.
REQ305 test behavior with MEDC17
The generated code can be (hopefully) integrated and compiled with the Bosch
environment MEDC17 and than run on a control unit. It is estimated, that these
tests have to be done with human interaction. Here is the observation of some
signals by the user supposable.
101

Appendix B Requirements of the Functional Specification
REQ306 test resource consumption
One main aspect for embedded software are the needed resources. For autogenerated
code an overhead in comparisen to (good) hand-written code is expected.
A way has to be found, to compare the resource consumption for one or a few
representative examples.
REQ307 classification number for resource consumption
At least one resource classification number shall be defined.
REQ308 test Bosch specific features
The existing Bosch software environment uses some other features for development
that differ from the AUTOSAR specification. The integration of the RTE
code within the Bosch environment has to be tested.
REQ310 dependencies between tests
Most of this tests have to be performed one after another. E.g. after creating the
RTE (If the RTE is created, than the RTE generator accepted the configuration), the
code can be compiled for RTA-OSEK for PC or for MEDC17. On the other hand, no
code can be compiled, if none is created from the RTE generator. The tests can be
performed in the following chain:
reject
configuration
configuration
compile with
MED17
run on control unit
compare resources
accept
configuration
compile with
RTA-OSEK for PC
run on PC
Note, that the code has to be compiled for the target, at which the next test will
be performed. Additionally, a proceeding after RTE generation only makes sense, if
the test case should be accepted from the RTE generator. A test configuration, which
should be rejected, shouldn’t be compiled.
102

B.4 Provided Tests
REQ320 concrete test cases for every type
The initial environment should include some test cases, which cover the current used
functionality of the RTE generator.
103

Appendix B Requirements of the Functional Specification
104

Abbreviations
API Application Programming Interface
ASW Application Software
AUTOSAR Automotive Open System Architecture
BSW Basic Software
CAN Controller Area Network
ECU Electronic Control Unit
GUI Graphical User Interface
IRV Inter Runnable Variable
LIN Local Interconnect Network
MCAL Microcontroller Abstraction Layer
MEDC17 The from BOSCH used platform for motor control units.
OIL OSEK Implementation Language
OSEK Open Systems and the Corresponding Interfaces for Automotive Electronics
RTE Runtime Environment
SWC Software Component
SWT Standard Widget Toolkit
VDX Vehicle Distributed eXecutive
VFB Virtual Functional Bus
XML Extensible Markup Language
105

Bibliography
[1] FlexRay Protocol Specification V2.1 Rev.A.
[2] LIN Specification Package Revision 2.0, 3 edition, 2005.
[3] AUTOSAR. Software Component Template, v2.0.1, 2006.
[4] AUTOSAR. Specification of Operating System, v2.1.0, 2007.
[5] AUTOSAR. Specification of Operating System, v3.0.0, 2007.
[6] AUTOSAR. Specification of RTE, v1.1.1, 2007.
[7] AUTOSAR. Specification of the Virtual Functional Bus, v1.0.0, 2007.
[8] AUTOSAR. Technical Overview, v2.1.0, 2007.
[9] Automotive Open System Architecture (AUTOSAR). http://www.autosar.org/.
[10] Yongyun Cho and Jaeyoung Choi. An embedded software testing tool supporting
multi-paradigm views. In Computational Science and Its Applications – ICCSA
2008, volume 5072/2008 of Lecture Notes in Computer Science, pages 780–789.
Springer Berlin / Heidelberg, 2008.
[11] W. Damm. Embedded system development for automotive applications: trends
and challenges. In S.L. Min and W. Yi, editors, International Conference on
Embedded Software (EMSOFT), page 1, Seoul, Korea, 2006. ACM.
[12] ISO 11898. Road vehicles – Controller area network (CAN). International Organization
for Standardization (ISO), Genevan, Switzerland, 1 edition, 2006.
[13] ISO 17356-1. Road vehicles – Open interface for embedded automotive applications
– Part 1: General structure and terms, definitions and abbreviated terms.
International Organization for Standardization (ISO), Genevan, Switzerland, 1
edition, 2005.
[14] ISO 17356-3. Road vehicles – Open interface for embedded automotive applications
– Part 3: OSEK/VDX Operating System (OS). International Organization for
Standardization (ISO), Genevan, Switzerland, 1 edition, 2005.
[15] ISO 17356-6. Road vehicles – Open interface for embedded automotive applications
– Part 6: OSEK/VDX Implementation Language (OIL). International
Organization for Standardization (ISO), Genevan, Switzerland, 1 edition, 2005.
107

[16] Java. http://java.sun.com/.
[17] Klaus Lamberg, Michael Beine, Mario Eschmann, Rainer Otterbach, Mirko Conrad,
and Ines Fey. Model-based testing of embedded automotive software using
mtest. Detroit, US, 2004. SAE World Congress.
[18] Jongbae Moon, Donggyu Kwak, Yongyun Cho, Sangjoon Park, and Jongchan
Lee. A xml script-based testing tool for embedded softwares. In Computational
Science and Its Applications – ICCSA 2007, volume 4706/2007 of Lecture Notes
in Computer Science, pages 818–828. Springer Berlin / Heidelberg, 2007.
[19] Perl. http://www.perl.org/.
[20] ASCET product information. http://www.etas.com/.
[21] MATLAB/Simulink/Stateflow product information. http://www.mathworks.de/.
[22] MTest product information. http://www.dspaceinc.com/.
[23] TargetLink product information. http://www.dspaceinc.com/.
[24] Ingo Stürmer. Systematic Testing of Code Generation Tools - A Testsuite-
Orientated Approach for Safeguarding Model-Based Code Generation. PhD thesis,
Pro Business, 2006.
[25] Ingo Stürmer and Mirko Conrad. Test suite design for code generation tools. In
ASE, pages 286–290. IEEE Computer Society, 2003.
[26] Ingo Stürmer, Mirko Conrad, Heiko Dörr, and Peter Pepper. Systematic testing
of model-based code generators. IEEE Trans. Software Eng., 33(9):622–634, 2007.
[27] Standard Widget Toolkit (SWT). http://www.eclipse.org/swt/.
[28] World Wide Web Consortium (W3C). XML Schema Part 0-3, 2 edition, 2004.
http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/.
[29] World Wide Web Consortium (W3C). Extensible Markup Language (XML) 1.0,
4 edition, 2006. http://www.w3.org/TR/2006/REC-xml-20060816.