evaluation environment for autosar-autocode in motor control units

Evaluation Environment forAUTOSAR–Autocode in Motor

Control Units

Mike Gemunde

Diploma Thesis

Supervised byProf. Dr. Klaus Schneider

Peter Bolz

July, 2008

Embedded Systems GroupDepartment of Computer Science

University of Kaiserslautern

Robert BOSCH GmbHDGS–EC/ESB

Erklarung

Hiermit erklare ich, dass ich die vorliegende Arbeit selbststandig und ohne fremdeHilfe verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt unddie aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe.

Kaiserslautern, den 30. Juli 2008

Mike Gemunde

iii

Danksagung

An dieser Stelle mochte ich denjenigen danken, die mir diese Arbeit ermoglicht haben.Zum einen mochte ich Herrn Prof. Dr. Schneider danken, der die Diplomarbeit vonder universitaren Seite betreut hat. Zum anderen geht mein Dank auch an HerrnPeter Bolz, fur die Betreuung von Seiten der Firma BOSCH GmbH und fur das sehrangenehme Arbeitsklima.

v

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 AUTOSAR 32.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 AUTOSAR Software . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Basic Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 AUTOSAR basic approach . . . . . . . . . . . . . . . . . . . . . . . . 52.3 AUTOSAR Operating System . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.3 Software Components . . . . . . . . . . . . . . . . . . . . . . . 102.4.4 Internal Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.5 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Virtual Functional Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7 Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.8.1 Configuration of the Example . . . . . . . . . . . . . . . . . . . 172.8.2 The Generated Source Code . . . . . . . . . . . . . . . . . . . . 192.8.3 Implementing the Runnables . . . . . . . . . . . . . . . . . . . 222.8.4 Conclusion of the Example . . . . . . . . . . . . . . . . . . . . 23

2.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 MEDC17 253.1 ERCOSEK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Basic Software and Application Software . . . . . . . . . . . . . . . . . 263.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Tasks and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vii

Contents

4 Goals 294.1 Background of the Topic . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Differences of MEDC17 and AUTOSAR . . . . . . . . . . . . . 294.1.2 Integration of AUTOSAR Software in MEDC17 . . . . . . . . . 304.1.3 Development of RTE Generators . . . . . . . . . . . . . . . . . 324.1.4 Current Situation (before Diploma Thesis) . . . . . . . . . . . 32

4.2 Topic of the Diploma Thesis . . . . . . . . . . . . . . . . . . . . . . . . 324.2.1 Main Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.3 Available Resources and Tools . . . . . . . . . . . . . . . . . . 33

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Analysis and Design 355.1 Test Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Components of the Environment . . . . . . . . . . . . . . . . . . . . . 37

5.2.1 RTE Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.3 RTE Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.4 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.5 Test Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.6 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.7 Test Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.8 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Configuration of the Components . . . . . . . . . . . . . . . . . . . . . 425.4 Structure of the File System . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4.1 The Directory “pool” . . . . . . . . . . . . . . . . . . . . . . . 445.4.2 Resource Directory . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.3 Configuration Directory . . . . . . . . . . . . . . . . . . . . . . 465.4.4 The Directory “perform” and Test Directories . . . . . . . . . . 46

5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Implementation of the Test Environment 496.1 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . 496.1.2 Java and SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.1.3 XML Files for Storing the Configurations . . . . . . . . . . . . 496.1.4 Perl for Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2 The Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . 506.2.1 RTE Generator Configuration View . . . . . . . . . . . . . . . 526.2.2 Test Template Configuration View . . . . . . . . . . . . . . . . 526.2.3 Perform View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.3 Implementation of the GUI with Java . . . . . . . . . . . . . . . . . . 566.3.1 Logging for the Application . . . . . . . . . . . . . . . . . . . . 566.3.2 Basic Data Structures . . . . . . . . . . . . . . . . . . . . . . . 57

viii

Contents

6.3.3 Perform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.4 Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.3.5 Configuration Widgets . . . . . . . . . . . . . . . . . . . . . . . 636.3.6 Perform Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4 Implementing Tests with Perl . . . . . . . . . . . . . . . . . . . . . . . 686.4.1 Utilities for Test Scripts . . . . . . . . . . . . . . . . . . . . . . 686.4.2 Scripts for the Test Types . . . . . . . . . . . . . . . . . . . . . 69

6.5 XML Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.6 Launching the Test Environment . . . . . . . . . . . . . . . . . . . . . 716.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7 Test Cases 757.1 Creating Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.1.1 Tests to Accept or Reject . . . . . . . . . . . . . . . . . . . . . 757.1.2 Code Review of Tests . . . . . . . . . . . . . . . . . . . . . . . 767.1.3 Tests for the PC–OS . . . . . . . . . . . . . . . . . . . . . . . . 767.1.4 Tests for Integration in MEDC17 . . . . . . . . . . . . . . . . . 77

7.2 Example: Mode Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.2.1 Configuration of the Mode Example . . . . . . . . . . . . . . . 797.2.2 Implementation of the Mode Example . . . . . . . . . . . . . . 807.2.3 Modification of this Example . . . . . . . . . . . . . . . . . . . 847.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.3 Example: DataReceivedEvent in MEDC17 . . . . . . . . . . . . . . . . 857.3.1 Configuration of the MEDC17 Example . . . . . . . . . . . . . 857.3.2 Implementation of the MEDC17 Example . . . . . . . . . . . . 867.3.3 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.4 Found RTE Generator Bugs . . . . . . . . . . . . . . . . . . . . . . . . 887.4.1 Implicit API buffers copied twice . . . . . . . . . . . . . . . . . 887.4.2 DataReceivedEvent without DataReceivedEvent . . . . . . . . 897.4.3 Header Files for Composition not created . . . . . . . . . . . . 90

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8 Conclusion 918.1 Reached Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.3 Impressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A Example 93

B Requirements of the Functional Specification 99B.1 Main Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99B.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99B.3 Layout and Organization . . . . . . . . . . . . . . . . . . . . . . . . . 100B.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 devel-opment some years ago. The number of electronic control units (ECU) has increasedto 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 hardwareand software system of a car is composed from different suppliers.

The increasing complexity has to be handled together with the needs to be com-patible with other manufactures to keep the development effort down. To achievethese 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 SystemArchitecture (AUTOSAR) [9].

However, the migration to such a standard has to be done and since there is a lotof existing software, which should not be discarded, a way must be found, to do sucha migration in little steps.

1.2 Related Work

For embedded system, automatic code generators play a significant role. They providethe 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 andproduce correct code, which reflects the configuration.

For developing software for embedded devices the modeling tools ASCET[20] andMATLAB/Simulink/Stateflow[21] exist. ASCET provides its own code generator tocreate source code from the model. The software TargetLink[23] from dSPACE istypically used to generate code from MATLAB/Simulink/Stateflow models.

The tool MTest[22, 17], which is also provided from dSPACE, is used to test themodels in different development phases. Other works deal with the testing of the codegenerators itself[24, 26, 25]. However, these works assume that the semantic is definedand the behavior of the generated code can be compared to that of the model. Theworks also do not handle the aspect of integration of the generated code into anotherenviroment.

Another tool for testing embedded software, which is also based on XML configu-rations, 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 overviewgiven and relevant mechanism and features for this work are described. Chapter 3gives a short overview of MEDC17, which is the currently used platform of BOSCHfor software development. Together with these preliminary explanations, the actualtopic of this diploma thesis is described in detail in chapter 4.

Afterwards the real work of this diploma thesis is explained. An evaluation en-vironment is created and it is in principle divided by an test environment and testcases. 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 inchapter 7. A conclusion of the work is given in chapter 8.

2

Chapter 2

AUTOSAR

Automotive Open System Architecture (AUTOSAR) is a consortium of automotivemanufactures including BOSCH, which tends to establish a standard1 for automotivesoftware engineering. The first discussions were done in 2002 and the partnership wassigned in 2003. One idea behind AUTOSAR is “Cooperate on standards, compete onimplementation”[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 toolingbetween the manufactures

• replaceability of hardware components without much effort to customize thesoftware

This is achieved with the standardization of all major system functions and exchangeformats. Additionally some parts of the hardware and the software are encapsulated toprovide high reusability, scalability and flexibility. The standardization is done step-wise by publishing different releases. The first release with number 1.0 was publishedin 2005.

Not every detail of AUTOSAR is of interest for this work and a complete descriptionwould go beyond the scope. The next sections give an overview of the architectureand the basic approach and it is based on [8]. The for this work significant parts aredescribed in more detail in the following sections. This description is based on theAUTOSAR release 2.1, which is mainly used in this whole work. The newer release3.0 is already published, but there doesn’t exist enough tools yet, which supports thisrelease.

1Currently 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 wholevehicle, but this section just describes the software architecture for one ECU2. Theoverall view is described later. The architecture is shown in figure 2.1 and it coversthe relations between all software running on one ECU. At the bottom of this diagramthe ECU with the complete hardware is located. The other big layer is the RuntimeEnvironment (RTE), which is arranged at a higher level. Everything between the RTEand the hardware is called Basic Software (BSW) and this is the infrastructural basisto run other applications. The AUTOSAR software is arranged above the RTE layerand contributes the functional part of the software.

Application Soft-ware Component

AUTOSAR Interface

Actuator Soft-ware Component

AUTOSAR Interface

Sensor SoftwareComponent

AUTOSAR Interface

AUTOSARSoftware

Application Soft-ware Component

AUTOSAR Interface

Runtime Environment (RTE)

StandardizedInterface

OperatingSystem

StandardizedAUTOSAR Interface

Services



Communication


AUTOSAR Interface

ECU Abstraction


AUTOSAR Interface

Complex De-vice Drivers


MicrocontrollerAbstraction Layer

Sta

ndard

ized

Inte

rface

Basic Software

ECU Hardware

Figure 2.1: AUTOSAR architecture diagram

2.1.1 AUTOSAR Software

The AUTOSAR Software is realized by several Software Components (SWCs), whichprovide the functional behavior of the system. The communication between SWCsand other components or with parts of the BSW is done through the RTE3. In thediagram is a distinction of two kinds of SWCs made:

2An ECU is not just a microcontroller, it additionally consists of peripherals as e.g. flash–ROM,controller for bus systems or ASICs.

3This also implies communications with components on other ECUs

4

2.2 AUTOSAR basic approach

AUTOSAR Software Component The AUTOSAR Software Component is in-dependent from the underlying hardware. That is done with the abstraction throughthe RTE and BSW.

Sensor / Actuator Software Component This component depends on sensorsand actuators which are available at the ECU. Due to performance such a componentruns on the ECU to which the sensors and actuators are physically connected. Besidesit 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 followingis an overview of the several parts of the BSW given.

Services This provides some basic services like e.g. memory and flash managementand diagnostic protocols.

Communication This are Communication stacks for inter-ECU communication likee.g. Controller Area Network (CAN) ([12]), Local Interconnect Network (LIN) ([2]),FlexRay ([1]), etc.

Operating System The operating system provides priority based scheduling oftasks and protection mechanisms. It is described in section 2.3 in more detail.

Microcontroller Abstraction Layer (MCAL) To make the higher software lay-ers independent from the microcontroller the MCAL is used. It avoids direct accessto registers from higher–level software and abstracts features like e.g. digital I/O, orA/D converters. It is aimed to replace the microcontroller with another one withoutchanging anything at higher–level software. This assumes that a MCAL is availablefor the substituting controller.

ECU abstraction Since the MCAL just abstracts the microcontroller the ECUabstraction does the same for the whole ECU.

Complex Device Drivers Due to performance reasons the complex device driversdirectly access the hardware.

2.2 AUTOSAR basic approach

After the architecture is clarified, this section takes a look at the basic approach ofAUTOSAR for bringing software to ECUs. In AUTOSAR this is done in multiplesteps. The approach shown in figure 2.2 handles the whole view of the complete sys-tem with multiple ECUs. The SWCs are developed using well defined interfaces andthey are connected through the Virtual Functional Bus (VFB). This is an abstractconnection, that makes it possible for the components to interact. It does not yetsay 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 communicationbuses. To specify the requirements of SWCs on the hardware and infrastructure anXML–based configuration is used, which says what operations with which data ele-ments are possible and what requirements to the infrastructure (in form of functionsand resources) are needed to run this SWC. It is also described, whether the SWC isavailable as source code or as object code.

SWC1 SWC2 SWC3

. . .SWCn

Virtual Functional Bus

Tool supportingdeployment of SWC

ECU descriptionsSystem constraints

ECU1

BSW

RTE

SWC1 SWC3

ECU2

BSW

RTE

SWC2

. . .

ECUm

BSW

RTE

SWCn

Figure 2.2: Basic AUTOSAR approach

Together with the SWC description, a description for the system and for the ECUsmust exist. The system description specifies the structure and constraints of the wholesystem. The ECU description defines the resources and functions of every ECU. To-gether with this descriptions it is possible to map the SWCs to several ECUs, atwhich the RTE encapsulates the SWCs from everything else. This means that theRTE provides the implementation of the VFB and hides the implementation of thecommunication for the SWCs. The components don’t get noticed about the commu-nication, especially if it is an intra– or inter–ECU communication. The BSW at thebottom of each ECU provides the infrastructural functionality, as seen in the previoussection.

The idea is that the SWCs can be developed independent from the hardware andfrom other components as long as they use the standardized interface and the de-scription of the components is provided. With the VFB a complete separation of theapplications and the infrastructure is provided. The SWCs can then be exchangedor 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 themain focus of this work. Such tools are not provided by the AUTOSAR consortiumitself, but they are provided by tool–suppliers. Several different implementations ofAUTOSAR tools, especially of RTE generators exist, but they shall all be compliantwith the AUTOSAR standard.

2.3 AUTOSAR Operating System

In terms of a normal personal computer, the whole BSW would be called the operatingsystem. However, for automotive architectures a strict distinction is done. The op-erating system is just a lightweight system, which provides scheduling of tasks, eventmechanisms and resource mechanisms. The resource mechanisms are used for the han-dling of mutual exclusive execution in critical sections and they have nothing to dowith physical resources.

AUTOSAR defines a standard for an operating system [4], which is based on theOSEK–OS standard [14]. One main attribute of this operating system is, that it isstatically configured and typically the operating system is compiled and linked with allother 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 configurationhas changed to an XML format [5] and so XML based descriptions are used for thewhole AUTOSAR standard. Some basic features of the operating system are describedin [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 differencesto 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 theoperating system provides a priority–based scheduling of tasks. A task defines anexecution of instructions, which are done in a sequential order. The different tasksare executed concurrent and asynchronous by the scheduler. OSEK–OS differentiatesbetween 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 schedulerswitches to a task with a higher priority or an interrupt arises and an interrupt serviceroutine is called.

Extended task The extended tasks provide in addition to the basic tasks the pos-sibility to release the processor without termination and wait for an event. After theevent occurs, the extended task can be waked up by the scheduler again. This iscalled a wait–point and can be used to synchronize tasks. Basic tasks can just besynchronized on the start or the end.

suspendstart

runready

wait

activ

ate

start

preempt

terminate

wait

release

Figure 2.3: States of a Task

The scheduler works priority–based and a task can reach the states, which are shownin figure 2.3. The state “wait” can only be reached by an extended task. Only onetask can be in state “run” at a time. “start” and “preempt” are the transitions, whichare 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 taskis 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 switchthe state of the task, if it is configured to be triggered by an operating system eventand the event occurs. However, the transition can also be done with the operatingsystem functions ActivateTask() or ChainTask(). These functions can be called fromevery routine including the task itself.

Due to the wait–points the scheduling and handling of an extended task takes moreresources.

2.3.2 Events

Extended tasks can own one or more events. This are the events, the extended taskcan wait for. An event can be set from every other routine and it has to be cleared

8

2.4 Basic Concepts

by the owning task. If the task waits for an event and the event is set from anotherroutine, the task will switch into the state “ready”. At the beginning of an extendedtask, that means at the transition from “suspended” to “ready”, all events of this taskwill be cleared from the operating system.

2.3.3 Resources

The resources of the operating system provide mutual exclusive access of tasks withdifferent priorities to shared resources. If a task occupies a resource, no other task cando the same. So the task have to wait until the resource is released. That this waitingcannot only be done in an extended task, the priority ceiling protocol is used. Thisprotocol increases the priority of the task that occupies a resource. This is done duringthe time, the resource is accessed. The priority is increased to the highest priority ofall tasks that can also access this resource. So it is prevented that another task, whichcan 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 necessaryfor this work and to understand the RTE and the generating of the RTE. This de-scription is based on the documents [6, 7, 3]. The second document is a specificationof 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 isnot used here.

2.4.1 Types

To use data types in the software and especially with AUTOSAR mechanisms like thecommunication, this data types have to be specified. The simplest types that can bespecified are the primitive types, which can be integers, strings, characters or Booleantypes. This types are additionally specified with a range (or a length for strings), thatsays which values are possible. Existing types can be combined to composite datatypes, 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. Aport is either a required port or a provided port. A provided port offers data elementsor services, a required port is the counterpart, which uses the data elements or services.This distinction describes the direction of the communication. Another classification isthe 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 symbols4 todraw 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, amode manager can notify mode switches to the receivers. The direction of the com-munication is given through the arrow. Connections of the form 1 : N and N : 1 arepossible. M : N connections are explicitly not allowed because of the complexity ofthe implementation. One sender port can send multiple data elements and multiplemodes. 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 calledvia 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 providemultiple operations. An operation receives multiple values, does a calculation andthen it can return multiple results.

In both cases a required port, this is a receiver or a client, has to be connected. Onthe other hand a provided port, this means analogous a server or sender, can be leftunconnected.

The data elements and modes or the operations that are provided via a port arespecified by the interface of this port. They may be used to create multiple ports withthe same interface for one or different SWCs.

Ports with the same or a compatible interface can be connected. Compatible meansthat the provided port at least provides the operations or data types as for the requiredport specified. The provided port can provide more data or operations, which is notused by the required port.

2.4.3 Software Components

The SWCs are the applications which run on an AUTOSAR infrastructure. Theyinteract only through ports with other components. Thus, they can be developedindependent from the hardware or from other components.

4To come back to the release discussion, the introduced symbols are specified in release 3.0. Theolder release 2.1 uses other symbols, but the newer are much easier to draw and the meaning isclearer

10

2.4 Basic Concepts

Atomic Software Components

An atomic Software Components is a basic component, which provides an own be-havior. The behavior is given with the later described internal behavior. An atomicSoftware Component can provide ports to allow communications with other compo-nents.

Compositions

Composition

SWC1 SWC2

SWC3

Figure 2.5: Composition of SWCs

Compositions are another form of a SWC which consists of other components. Thecomponents are aggregated to create a new component. Figure 2.5 shows such acomposition of three SWCs. The ports from the components can be connected betweeneach other or with ports of the composition. A connection between components insidethe composition is called an assembly connector. A connection from a containedcomponent to a port of the composition is called a delegation connector.

A composition of components just provides the behavior that results by the connec-tions of the contained components. It does not add an own implementation or ownfunctionality.

2.4.4 Internal Behavior

A component can not only provide ports, there also have to be some functionalitybehind it. This is done by specifying an internal behavior for an atomic SoftwareComponent. The internal behavior consists of several parts.

Runnable Entities

The functionality of an atomic Software Component is implemented in the form ofrunnable entities or in short runnables. Runnables are executed when a special eventarises and they are implemented in form of a C or C++ function. A runnable canaccess the ports of the SWC. The description for this is done with different points oraccesses.

DataSendPoint It describes an access to a sender port and a concrete data elementof 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 ele-ment of that port. The value, which is returned, is the current value.

DataWriteAccess It describes an implicit access to a sender port and a concretedata element of that port. The runnable can access the port multiple times, but justthe 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 concretedata element of that port. The runnable can access the port multiple times duringone execution and will get the same value every time.

AsynchronousServerCallPoint A runnable calls a server with an asynchronouscall through a client port. It has to be specified, which client port and which providedoperation 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 callwhen the operation is finished.

SynchronousServerCallPoint A runnable calls a server with an synchronous callthrough a client port. It has to be specified, which client port and which providedoperation is used. A synchronous call returns not until the operation is finished andthe result is available.

WaitPoint A special item in this enumeration is the WaitPoint. All other itemsrefers to a port and a special data element or operation of the port. Instead of thata WaitPoint refers an RTE event for which can be waited. The call does not returnuntil the event or a specified timeout occurs.

It can be seen in this enumeration, that the accesses are described in very detail. Soe.g. a runnable can read a data element of a port directly and another data elementof the same port with an implicit access.

RTE Events

For the RTE some events can be specified. An event can either trigger a runnable orwake up a WaitPoint. The following events are defined by AUTOSAR.

TimingEvent For this event an interval and an offset has to be specified. So thepoints in time are given at which the event occurs.

DataReceivedEvent This event is specified for a receiver port and for a concretedata element of the port. It occurs when new data is received.

DataReceivedErrorEvent This event is also specified for a receiver port and fora concrete data element of the port. But it occurs when data is invalidated for acommunication.

DataSendCompletedEvent The DataSendCompletedEvent have to be specifiedfor a sender port and a DataSendPoint. It occurs when the sending of a data elementis completed.

12

2.4 Basic Concepts

OperationInvokedEvent This event is called when an operation for a server portis invoked. The event is specified with the port and with the operation for which itshould occur.

AsynchronousServerCallReturnsEvent If an asynchronous call is used to invokean operation on a server, the result of the server call can be fetched at later time. Thisevent shows, that the server is finished and the result is available. It is specified for aclient port and an operation, which is called by the client.

ModeSwitchEvent For this event a mode and an action “entry” or “exit” has tobe specified. The event arises when the specified mode is entered or exited, dependingon 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, DataSendCom-pletedEvents and AsynchronousServerCallReturnsEvents.

Inter Runnable Variable

Ports define the interaction between SWCs, or more precise the interaction betweenthe runnables of the SWCs. For runnables of one SWC another mechanism for internalcommunication exists. These are the Inter Runnable Variables (IRVs), which can beaccessed by the runnables. Runnables could also use global variables for this internalcommunication, but with IRVs protection mechanism are provided by the RTE forconcurrency.

Exclusive Area

Exclusive Area are a similar mechanism to the operating system resources described insection 2.3.3. Exclusive areas just provide mutual exclusive access for the runnables ofone SWC, but not for the whole task. Exclusive areas can be implemented with oper-ating system resources, but this is no requirement. There can be other implementationpossibilities specified like e.g. interrupt–disabling.

2.4.5 Modes

Modes have the simple purpose that components can provide a different behaviordepending on which mode is active. The mode can be distributed from a compo-nent 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 possibilityto provide modes to other ECUs. RTE Events can be disabled in a mode. Thenthe event is prevented, if a special mode is active. This makes it possible to executerunnables 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 usedto clean up the old mode or prepare the new mode.

13

Chapter 2 AUTOSAR

mode

A

mode

Btransisiton

modeswitch

indication

modedependentrunnables

OnExitrunnables

OnEntryrunnables

modedependentrunnables

mode independent runnables

time

Figure 2.6: Sequence of a mode switch

The AUTOSAR specification defines a concrete sequence for a mode switch. Thissequence is shown in figure 2.6 with a switch from mode “A” to mode “B”. If a modeswitch is indicated, first all runnables that depend on the active mode have to befinished. After that, the OnExit runnables for mode “A” are executed. Then theOnEntry runnables for mode “B” are executed. Afterwards the new mode “B” isreached and the runnables depending on this mode can be executed. However, thisdepends on the events, triggering these runnables. Runnables that do not depend ona mode are not affected from the mode switch.

In the diagram it can be seen, that after the mode switch indication it has to bewaited for the termination of all mode depending runnables that depend on mode “A”.For this reason the AUTOSAR specification prohibits that a runnable, which dependson a mode, can have a WaitPoint.

2.5 Virtual Functional Bus

An abstract mechanism for connecting SWCs called the VFB has been introducedin the section 2.2. It allows to develop SWCs independent from other hardware andsoftware by providing a defined interface. For this interface, the ports are defined andcan be used from the functions in the component. At the VFB level, this ports canbe used to connect components by connecting compatible ports.

In figure 2.7 is a connection of some components shown. This represents the func-tional part of the system, independent from the architecture or infrastructure whichis needed to execute this system.

14

2.6 Configuration Files

SWC1 SWC2 SWC3

. . .

SWCn


Figure 2.7: VFB diagram

2.6 Configuration Files

To do the mapping to the ECUs, which is described in section 2.2, it is necessary toknow a lot of information about every part of the AUTOSAR system. This meansthe precise description of a SWC for each mechanism described in section 2.4 andthe configuration of the ECUs and the system. This configuration is done in anXML format for a defined XML scheme. The concrete XML scheme depends on theAUTOSAR release. For one release some different scheme versions can exist, as aresult of bug fixes and updates.

AUTOSAR distinguishes two cases of specifications. The specification of a SWCtogether with its internal behavior is called a SWC description. Everything that goesbeyond the scope of a single component is called a configuration. Together with aSWC description it is possible to deliver the component to suppliers.

AUTOSAR does not specify, which information has to be put in which files. Insteadthe structure of the files is flexible that the whole configuration can be put in one fileor every object can have its own file. To reference an object in an XML file a uniquepath is used, which consists of the package names that have to traversed in the XMLtree 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 theenvironment which is needed for the SWCs to run on that ECU and communicate withother SWCs. The RTE encapsulates the communication between the components, sothat they don’t know were the counterpart of the communication is located. Thismeans, that the communication with a component on the same ECU is done directly,whereas the communication with a component, which is located elsewhere, is donethrough a communication mechanism like CAN or LIN. But the RTE does more thanjust provide the connections of the VFB. It additionally ensures that runnables of aSWC are triggered through the configured events, provides consistency for IRVs andensures the effect of exclusive areas. Or in short, it provides the functions for all theconfigured 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 generatedevery time. This files are called the RTE library. However they are delivered with theRTE generator to cooperate with the generated code.

The RTE generator shall provide two different phases, which can be used in differentdevelopment stages. This two phases can be split into two tools, but they are verysimilar and the currently known generators support both.

Contract phase In the contract phase an RTE generator shall produce the headerfiles for the SWCs to allow compiling the components. It is not necessary to definethe whole system in this case, but just the SWCs for which the header files shouldbe 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 oneECU. The generated RTE also consists of header files for the SWCs and these have tobe compliant with those generated in the contract phase.

Together with that, the RTE generator normally works in a mode called the “com-patibility 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 structuresand 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 toprovide access to the current values of a sender–receiver communication. This modehas 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 assumethat the RTE is created only with that one generator (or maybe compatible generatorsfrom the same vendor). So it does not have to create that well–defined implementationof the API from compatibility mode and it can produce more efficient code and dooptimizations.

The source code in the contract phase also have to contain the tasks, which are spec-ified in the configuration and in which context the runnables are executed. The codefor the tasks have to provide calls for the runnables, because they shall be executedif the configured events occur. Additionally the RTE generator shall output a partof the configuration for the operating system. This is necessary, that the operatingsystem gets noticed about the tasks and how they should be executed. The examplein the next section also addresses this point.

2.8 Example

This is a short example to clarify the concepts and proceedings described in thischapter. 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 APIcan 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. Thissection just contains an extract of the configuration and some parts of the source codefor SWC1. To whole configuration of the system can be found in appendix A. Theconfiguration of the ECU is not shown.

SWC1

run11 run12

SWC2

run21 run22


Task1

Task2

Figure 2.8: Visualization of the example

Every SWC uses two ports and has two runnables, which are shown as boxes insideof the components. The lines to the ports show an access to this ports. The runnablerun11 is triggered by a timing event which occurs every 100ms. Runnable run12 istriggered by another timing event which occurs every 50ms. The two runnables ofSWC1 are mapped to the same task Task1. In more detail the events triggering arunnable are mapped to a task, but here every runnable is just triggered by one eventand so they only run in the context of one Task. The runnable run22 of SWC2 isalso triggered by an timing event every 50ms and runs in the context of Task2. Theother 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 beinvoked concurrently. This is one special case, where an event must not be mappedto a task. Instead a direct call to the runnable should be performed to provide abetter performance. Both SWCs are mapped to the same ECU. All this informationis 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 secondtype is a string type, which has a length of 8 characters and the symbol String8. Toreference a type, the names of the packages have to be used as path. This means forthe 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 isshown in listing 2.2. The interface SR Int16 consists of two data elements intValue1and intValue2, which are both of type Int16, and it provides a not queued communi-cation. 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 <?xml version="1.0" encoding="UTF-8"?><AUTOSAR xmlns="http://autosar.org/2.1.2">

<TOP-LEVEL-PACKAGES><AR-PACKAGE>

<SHORT-NAME>types</SHORT-NAME><ELEMENTS>

<INTEGER-TYPE><SHORT-NAME>Int16</SHORT-NAME><LOWER-LIMIT INTERVAL-TYPE="CLOSED">-32768</LOWER-LIMIT>

10 <UPPER-LIMIT INTERVAL-TYPE="CLOSED">32767</UPPER-LIMIT></INTEGER-TYPE><STRING-TYPE><SHORT-NAME>String8</SHORT-NAME><ENCODING>utf8</ENCODING><MAX-NUMBER-OF-CHARS>8</MAX-NUMBER-OF-CHARS>

</STRING-TYPE></ELEMENTS>

</AR-PACKAGE></TOP-LEVEL-PACKAGES>

20 </AUTOSAR>

Listing 2.1: Example description of data types



<SHORT-NAME>interfaces</SHORT-NAME><ELEMENTS>

<SENDER-RECEIVER-INTERFACE><SHORT-NAME>SR Int16</SHORT-NAME><IS-SERVICE>false</IS-SERVICE>

10 <DATA-ELEMENTS><DATA-ELEMENT-PROTOTYPE>

<SHORT-NAME>intValue1</SHORT-NAME><TYPE-TREF DEST="INTEGER-TYPE">/types/Int16</TYPE-TREF><IS-QUEUED>false</IS-QUEUED>

</DATA-ELEMENT-PROTOTYPE><DATA-ELEMENT-PROTOTYPE>


20 </DATA-ELEMENT-PROTOTYPE></DATA-ELEMENTS>

</SENDER-RECEIVER-INTERFACE></ELEMENTS>


</AUTOSAR>

Listing 2.2: Example description of port interfaces

18

2.8 Example

them “types” or “ interfaces ”. Additionally, it is not needed to have different namesfor these packages.

1 <?xml version="1.0" encoding="UTF-8"?><AUTOSAR xmlns="http://autosar.org/2.1.2"><TOP-LEVEL-PACKAGES>

<AR-PACKAGE><SHORT-NAME>swc root</SHORT-NAME><ELEMENTS>

<ATOMIC-SOFTWARE-COMPONENT-TYPE><SHORT-NAME>swc1</SHORT-NAME><PORTS>

10 <P-PORT-PROTOTYPE><SHORT-NAME>pport1</SHORT-NAME><PROVIDED-INTERFACE-TREF y

DEST="SENDER-RECEIVER-INTERFACE">/interfaces/SR Int16</PROVIDED-INTERFACE-TREF></P-PORT-PROTOTYPE><R-PORT-PROTOTYPE>

<SHORT-NAME>rport1</SHORT-NAME><REQUIRED-INTERFACE-TREF y

DEST="CLIENT-SERVER-INTERFACE">/interfaces/CS string to int</REQUIRED-INTERFACE-TREF></R-PORT-PROTOTYPE>

</PORTS></ATOMIC-SOFTWARE-COMPONENT-TYPE>

20 </ELEMENTS></AR-PACKAGE>

</TOP-LEVEL-PACKAGES></AUTOSAR>

Listing 2.3: Example description of SWC1

To describe the component SWC1, the code of listing 2.3 is used. Here are the twoports of SWC1 specified. Listing 2.4 shows the internal behavior of SWC1. There arethe runnables and the ports, which are accessed by the runnables, described. This isneeded to generate the API and to provide consistency for the communication. Theaccess is specified with DataSendPoints and a SynchronousServerCallPoint. Runnablerun11 writes both values to the sender port pport11, whereas run12 only writes thevalue intValue1.

The runnables are triggered by the specified timing events. One runnable can betriggered 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. Itis also permitted to have more than one internal behavior for one Software Componentspecified, but just one can be used. This is done by the instantiation of the SWC, whichis part of the system description and not shown here. So it is e.g. possible to reuse adefinition of a Software Component and reuse it with different internal behaviors. Asalso can be seen in the configuration, it is possible for an internal behavior to supportmultiple instantiation, which should also not be considered here, because it does notcontribute 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 autogenerated part of the RTE. This part contains the API for the SWCs. The interestingextract for SWC1 is shown in listing 2.5. In the last two lines the functions for therunnables are declared. These functions are called when a runnable is executed. Thismeans for this example that the functions are called when the timing events occur. So

19

Chapter 2 AUTOSAR



<SHORT-NAME>swc root</SHORT-NAME><ELEMENTS>

<INTERNAL-BEHAVIOR><SHORT-NAME>intBehSwc1</SHORT-NAME><COMPONENT-REF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc1</COMPONENT-REF>

10 <EVENTS><TIMING-EVENT>

<SHORT-NAME>Time100ms</SHORT-NAME><START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intBehSwc1/run11</START-ON-EVENT-REF><PERIOD>0.1</PERIOD>

</TIMING-EVENT><TIMING-EVENT>


20 </TIMING-EVENT></EVENTS><RUNNABLES>

<RUNNABLE-ENTITY><SHORT-NAME>run11</SHORT-NAME><CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY><DATA-SEND-POINTS><DATA-SEND-POINT>

<SHORT-NAME>dwa1</SHORT-NAME><DATA-ELEMENT-IREF>

30 <P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF><DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">

/interfaces/SR Int16/intValue1</DATA-ELEMENT-PROTOTYPE-REF>

</DATA-ELEMENT-IREF></DATA-SEND-POINT><DATA-SEND-POINT>

<SHORT-NAME>dwa2</SHORT-NAME><DATA-ELEMENT-IREF><P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF>

40 <DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">/interfaces/SR Int16/intValue2

</DATA-ELEMENT-PROTOTYPE-REF></DATA-ELEMENT-IREF>

</DATA-SEND-POINT></DATA-SEND-POINTS><SYMBOL>run11</SYMBOL>

</RUNNABLE-ENTITY><RUNNABLE-ENTITY>

<SHORT-NAME>run12</SHORT-NAME>50 <CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY>

<DATA-SEND-POINTS><DATA-SEND-POINT>

<SHORT-NAME>dwa2</SHORT-NAME><DATA-ELEMENT-IREF><P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF><DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">


</DATA-ELEMENT-IREF>60 </DATA-SEND-POINT>

</DATA-SEND-POINTS><SERVER-CALL-POINTS><SYNCHRONOUS-SERVER-CALL-POINT>

<SHORT-NAME>sscp</SHORT-NAME><OPERATION-IREFS><OPERATION-IREF>

<R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc1/rport1

</R-PORT-PROTOTYPE-REF>70 <OPERATION-PROTOTYPE-REF DEST="OPERATION-PROTOTYPE">

/interfaces/CS string to int/parse</OPERATION-PROTOTYPE-REF>

</OPERATION-IREF></OPERATION-IREFS>

</SYNCHRONOUS-SERVER-CALL-POINT></SERVER-CALL-POINTS><SYMBOL>run12</SYMBOL>

</RUNNABLE-ENTITY></RUNNABLES>

80 <SUPPORTS-MULTIPLE-INSTANTIATION>false</SUPPORTS-MULTIPLE-INSTANTIATION></INTERNAL-BEHAVIOR>

</ELEMENTS></AR-PACKAGE>

</TOP-LEVEL-PACKAGES></AUTOSAR>

Listing 2.4: Example description of internal behavior of SWC1

20

2.8 Example

1 #define RTE E CS string to int overflow (42)#define RTE E CS string to int underflow (43)

#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, y

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) ( yRte WriteHook swc1 pport1 intValue2 Start(data), (Rte RxBuf 1 = data), yRte 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) ( y

Rte WriteHook swc1 pport1 intValue1 Start(data), (Rte RxBuf 0 = data), yRte 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 haveto be implemented. Within these functions, the values of the ports can be accessed, ifit is configured for the SWC.

For an access to a sender port with a DataSendPoint, the API is specified withinAUTOSAR to be of the form Rte Write <p> <o>(data). Whereas <p> is the nameof the port and <o> 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 sothere is no need to use any inter–ECU communication mechanism. Instead the com-munication can be done directly. It can be seen in the example that the API isimplemented with #define directives, which directly accesses the global variablesRte RxBuf 1 and Rte RxBuf 2. The API for SWC2 is not shown here, but it has toaccess the same variables to establish the communication.

To invoke an operation at the server, a function call is necessary. For the runnablerun12 is a SynchronousServerCallPoint specified. So the function does not returnuntil the operation on the server is finished and the return values are available. Inthe special case mentioned above, the runnable, which implements the server, is notmapped to a task and can be invoked concurrently. This runnable is then executed inthe 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 stringas argument and returns one integer value. This API is implemented using a #definedirective 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 Task1is shown in listing 2.6. Here it can be seen that the runnable run11 is triggered every100ms and runnable run12 every 50ms. This is done by activating the task every50ms and executing the runnable run11 just any second call. The activation of thetask every 50ms is done in the configuration of the operating system, which is alsocreated from the generator.

2.8.3 Implementing the Runnables

At the end listing, 2.7 shows how the runnable run12 can be implemented. The createdAPI can be used to access the ports. Here it is just necessary to write the correct APIto 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 thisexample, also a function call can be used. The runnable would not get noticed aboutit.

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 compiledagainst such a header file with global variables, it is expected that a generator, whichcreates 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 presentsthe complexity of the XML configuration which is already reached by such a simplecase. But it should help to understand, how the mechanisms described in this chapterare 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 basisto run the SWCs. The functional components are developed independent with respectto AUTOSAR compliant interfaces and descriptions, which specify in a formal anddetailed way, what resources are necessary to run a component. Additionally, it hasto be specified, which conditions are provided by the hardware and the topology ofthe system. Then, the RTE generator creates automatically the RTE, which bringsthe two parts (SWCs and BSW) together.

With the standardization of the BSW and the interfaces between each part of theBSW, the replaceability of parts increases and even with the MCAL it is possibleto exchange microcontrollers with others, if there are AUTOSAR compliant MCALsavailable 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 cur-rently from BOSCH developed and used environment for software of motor controlunits is called MEDC17. It is not a standard as AUTOSAR, but just an environmentconsisting of a software architecture and application software together with a buildenvironment. The control unit, which is fabricated from BOSCH and for which thesoftware 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 providessupport for the architecture and development of software for one control unit. It doesnot handle so much features, which can be used by the Application Software (ASW),than AUTOSAR. However, on the other hand MEDC17 supports the developmentprocess of BOSCH with some mechanisms like e.g. the automatically generation ofdocumentation. This mechanisms have no counterpart within the AUTOSAR stan-dard.

Due to secrecy, this chapter just takes a facile overview about what is necessary tounderstand the later described work. Some comparisons to AUTOSAR are made inthis chapter, but even if MEDC17 is described after AUTOSAR, MEDC17 is the olderone.

3.1 ERCOSEK

MEDC17 is based on the embedded operating system ERCOSEK, which was developedand 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 OSEKcompliant operating system. ERCOSEK is one of these, which do not support extendedtasks. So just basic tasks can be used. On the other hand extended task are alsoundesired because of the resource overhead they cause.

Not every feature of ERCOSEK is used in MEDC17. Additionally, MEDC17 has afixed 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 partof 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 providesthe infrastructure to run the ASW, whereas the Application Software is the functionalpart 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 theinter–ECU approach from AUTOSAR. Every part that is developed and compiledwith MEDC17 runs on the same ECU. Nevertheless, MEDC17 provides access tocommunication over CAN or other buses.

The intra–ECU communication is here done with so called messages. These messageshave to be configured for MEDC17 and than for each message one or more globalvariables are created during the auto build. The application software uses an API toaccess the global variable. This API is typically a #define directive, that maps theaccess to the correct variable.

3.4 Tasks and Processes

The counterpart to a runnable in AUTOSAR is called a process in the terms ofMEDC17. Here there are not so much mechanisms for a process than for a runnablein AUTOSAR.

For MEDC17 some tasks are configured, which are time triggered. The periodsof this tasks are from 1ms up to 1s. The source code of the tasks of MEDC17 isalso auto generated from some configuration files, but it does not provide so muchflexibility. 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 thesame sequential order as they are defined in the configuration. There is no handlingof events that triggers the one or the other process like it is shown in the AUTOSARexample in section 2.8, where two runnables with different timings are executed in thesame task.

So all processes are time triggered and for a process it has to be decided, in whichinterval it should be executed. Then the process is mapped to the task with thecorresponding timing. Due to dependencies between processes, they have to be mappedin the correct order. Because e.g. one process can determine a value and anotherprocess uses this value, but the value have to be up to date for a special timing. Sothese processes have to be executed in the correct order and there is no mechanism todetermine this order automatically.

26

3.5 Summary

On the other hand the processes that run in a task do not necessarily have a de-pendency or fulfill the same job. They are just mapped to that task, so that they areexecuted in the correct interval. The term “task” does here not imply the meaning ofachieving the same function.

3.5 Summary

MEDC17 provides the current architecture of software development for one ECU forBOSCH. It has not to handle so much possibilities as AUTOSAR, since it has not to besupported by any other manufacture. It is very static configured and the applicationsoftware has to deal with the existing architecture. So processes have to deal withthe existing tasks and it is very unusual that a new task is created. AUTOSAR usesanother way where the BSW and especially the operating system is configured to fitthe application software and this configuration can change with every call of the RTEgenerator.

27

Chapter 3 MEDC17

28

Chapter 4

Goals

This chapter first describes the background for this diploma thesis. Afterwards, itdiscusses the idea, why this diploma thesis was arisen and then it addresses the topicand the requirements.

4.1 Background of the Topic

Chapter 2 gives a short introduction to AUTOSAR, a new standard which is becomingmore important for automotive software development. On the other hand, there isa lot of existing and not AUTOSAR compliant software in form of the MEDC17environment, which should not be discarded. But their are two requirements forsupporting AUTOSAR:

• suppliers deliver AUTOSAR compliant software, which should be integrated inseveral projects

• a conversion to AUTOSAR should be performed step by step

So the first step, which is agreeable with both, is to integrate AUTOSAR compliantsoftware in MEDC17. With this, a new follow–up platform for MEDC17 can bedeveloped according to AUTOSAR and the old can be kept for current projects. Sothe 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 isnot complete, because not all are identified yet.

Extended tasks

In section 3.1 the operating system ERCOSEK is described, on which the BOSCHarchitecture MEDC17 is based. It does not support the from OSEK–OS defined ex-tended tasks. However, there exist some mechanisms of AUTOSAR, which result in anextended task after generating the RTE. E.g. a runnable can explicitly use a WaitPointto 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 implementsthe intra-ECU sender–receiver communication with global variables, but it does nothave to, especially not for components which are delivered in form of object code.

Nevertheless, if the communication is implemented with global variables, the RTEgenerator creates some #define directives, which map the call to a direct accessto global variables. But the identifiers of the directives differ from AUTOSAR toMEDC17 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 op-erating system, is configured for the needs of the ASW. In the case of MEDC17 theconfiguration is fixed and it is changed in very few cases. Instead, the ASW is adjustedto work with this premises.

Ignorance

From view of the RTE generator, it creates the RTE for all software, that runs on anECU. The generated RTE provides data consistency for the communication and thespecified behavior of e.g. the correct triggering of runnables by events. It does notknow, that there is other software, which is not AUTOSAR compliant, but which runsadditionally on the same ECU. This is not really a difference, but an important itemfor using not AUTOSAR compliant software.

4.1.2 Integration of AUTOSAR Software in MEDC17

For AUTOSAR compliant Software Components the RTE provides the connectionto the BSW and between the components itself. So to integrate such componentssomewhere else it is necessary to integrate the RTE. Figure 4.1 shows the architectureof MEDC17 together with the integrated RTE. Of interest is especially the verticalpart of the RTE layer, which adapts the old software to establish communications tothe 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 componentand this requirements have to be provided from MEDC17. E.g. the RTE generatorcreates its own configuration for the operating system and the features and mecha-nisms specified in this configuration are needed to execute the generated RTE. So theoperating system of MEDC17 have to be adjusted to provide this mechanisms. Thiscould 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 bythe 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

4.1 Background of the Topic

MEDC17 Basic Software

Runtime Environment (RTE)

Adapter

Adapte

r

AUTOSARApplication

Software

MEDC17Application

Software

MEDC17 Hardware

Figure 4.1: Integration of AUTOSAR in MEDC17

way is to change the RTE generator itself, that it prefers mechanisms in the createdsource code, which are easier to handle for MEDC17. As described in chapter 2, theRTE does not only consist of generated code, but also of some fix source code which iscalled 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, ithas to be assured, that the semantic of the configured system hasn’t changed. Be-cause for delivered SWCs, the supplier has developed the components according tothe AUTOSAR standard and this expected behavior has to be obtained. However, itis possible, to inform the supplier about AUTOSAR features, which can’t be integratedand 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 thesequestions, different configuration have to be checked. The result should be an inter-pretation, if the features can be integrated or what has to be changed to do it. If thefeature 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 anown version of the generator. However, not only new generators for new AUTOSARreleases have to be developed, but also existing versions for existing AUTOSAR re-leases 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 thiswork and former tests have detected some bugs. This is an outcome of the massof combination possibilities of the features and configurations, which should be allhandled correctly. So the tests should also check some basic functionality of the RTEgenerators, because they should be used in production and so they have to workcorrectly 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 proceedinglacks of structure, reusability and concepts. This means concretely:

• the used tests didn’t cover all the features, which are expected to be integratedin 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 processand 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 Topic of the Diploma Thesis

4.2.1 Main Task

The purpose of this diploma thesis is to design and create an environment to test andevaluate RTE generators. It shall help to perform tests with an RTE generator andrate its quality. A major focus of these test shall be the integration in MEDC17 andresults shall state the needs for changes to the generator and MEDC17. Additionallya proceeding to evaluate a new version of an RTE generator shall be developed. Thisleads 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 itisn’t defined which form the environment should have. Supposable are e.g. a graphicaluser 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. Itcontains a lot of requirements for this work. Because the requirements also cover someimplementation and analysis aspects, they does not fit in this chapter. So they areshown in appendix B.

4.2.3 Available Resources and Tools

There are some resources and tools available to do this diploma thesis. They aredescribed in the following listing.

RTE generators from ETAS ETAS has developed different versions of RTE gen-erators for AUTOSAR release 2.0 and 2.1, which are available for this work. Theseversions already fulfill some special requirements from BOSCH. These generators arethe main test objects of the whole environment, because these are the generators whichwill be used from BOSCH.

GEENSYS AUTOSAR Builder The AUTOSAR Builder allows to edit the XMLdescriptions and XML configurations on a higher level than just editing the plain textfiles. It helps creating descriptions and configurations by showing the available tagsfor 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 ConfigurationEditor (GCE). The first one allows to create the description for the components andthe compositions and to configure the system. The second one is used to configure theECU parameters for the available ECUs.

MEDC17 environment A checkout of the MEDC17 environment is called a PST1.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 isneeded.

Universal Debug Engine The Universal Debug Engine (UDE) from pls consistsof a software front end and a Universal Access Device to establish the connection tothe controller. It is used to program and debug the MEDC17 control unit.

HighTec–GNU Compiler Suite To compile the MEDC17 environment to an ex-ecutable file this compiler is necessary. Some other build tools are integrated inMEDC17.

RTA–OSEK PC–Port This is a PC–Port of the OSEK operating system for em-bedded devices. This operating system port is also compliant to the AUTOSAR OS1.0 specification [4] and it provides a virtual environment to execute OSEK compliantsoftware directly on a PC.

MinGW Compiler Suite Is a minimal port of the GNU Compiler Collection forWindows. 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 isshown, 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 solutionto 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 RTEgenerators and these tests do not depend on MEDC17. To do this an environmentshould be created, which is described in the following chapters.

1PST 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 thetest cases the environment can be used for evaluation. The structure and behavior ofthe test environment are explained in this chapter, the implementation is described inthe 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 isdescribed. It should provide the idea of the classification of the components, which ismade in section 5.2. Section 5.3 describes, how these components are configured andsection 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 implementtest 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 explainedcomponents of the environment. There are not the AUTOSAR software componentsmeant.

5.1 Test Data Flow

This section provides the idea of the made classification and structuring of the laterenvironment. The diagram in figure 5.1 shows a simple proceeding of doing a test withan RTE generator. MEDC17 is not considered in this diagram. The test case consistsof 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 implementthe SWCs that are described in the AUTOSAR XML files. The test case also consistsof 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, butthis is not the whole configuration. So there are some additional files needed. Fromthis configuration the source code for the operating system can be generated. This isnot considered here in detail, but just displayed in the diagram.

Some additional source files, which e.g. contain the main() function, are also re-quired. All source files can now be compiled and linked together. The created binaryfile then can be executed at a control unit or with the OSEK–OS PC–Port, dependingon for which target the binary is built.

35

Chapter 5 Analysis and Design

src /obj

testconf.

testdoc.

test case

RTEgenerator

RTElib.

test object

src /hdr

oilsrc /hdr

rta build oil

src /hdr

additionalfiles

compiler

binaryfile

Figure 5.1: Procedure of a test case

The documentation describes the aim of the test and it has to be clarified, if thisaim is reached. This can be done in several ways. Depending on the expected testbehavior the source code has to be compiled and the resulting binary can be executedto check it. However, for some other cases it is sufficient to look at the generatedsource code and take a decision.

So this simple diagram should show some variation possibilities and some compo-nents can be derived, which should be part of the environment to provide flexibletesting 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 justone case. Especially not, if different combinations of features should be tested andevaluated.

RTE generator As described in chapter 4 it is necessary to evaluate different RTEgenerators, especially different versions from ETAS. Additionally the evaluation shouldbe done for new versions, which contain special changes. So the evaluation has to bedone with such a new version, to ensure that the changes are implemented and thatthey work in the expected way.

RTE library As also described in chapter 4, the RTE library has to be customizedto 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. Maybefor a newer generator version a customization of the library for MEDC17 won’t benecessary, but for the current versions it is and so there have to be at least two libraryversions 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. Forsome cases a code look up after the generation can be enough to take a decision of theresult. 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 wouldlook different. So even some other proceedings are necessary for tests.

Typically an RTE generator supports just one AUTOSAR release. The XML schemeof the AUTOSAR configuration files and also the features differ a lot between thedifferent AUTOSAR releases. So a test case also belongs just to one AUTOSARrelease.


The components, which are described in the previous section, are the main objects ofthe environment. These components are shown with their relations in figure 5.2. Thereare more components than in the previous section described. Option, test, variableand 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 performedwith 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 thereare no major dependencies between the components for different releases. Only thetest types can be used globally. The components of this diagram are described in thissection 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 howthe 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, whichdeclares 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 commandline. The options are treated separately to provide a better flexibility and to take careabout different parameters for different generators. An RTE generator can provide anparameter for each option, but it does not have to. The test template then can specify

37


test template

name

number

description

doc. file

option

name

description

RTE library

name

RTE generator

nameversionexecutablecomandline

test type

name

perl file

description

file

variable

name

resource

name files

test

result

provide

parameter

provide

implementation

define define

consist

consist

define

define

require

default valuedescription

defines

value

require

Figure 5.2: Entity relationship diagram for the components

38


which options are used for the test. If the test is performed, the concrete parameterfor the used RTE generator is substituted. An option has a description that explainsthe purpose of the option.

5.2.3 RTE Library

Similar to the options, the libraries are treated. An RTE generator provides normallythe library which is delivered with it. This library is called “Original” in the environ-ment. However, there can be other libraries, which are customized to take care aboutspecial 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 specifiesa 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 andsource files. The XML files are normally fed into the generator and the source filesimplements the SWCs, which are configured in the XML files. The resources arehandled separately to provide a better access with external tools and reusability formultiple 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 shortcharacterization of what the test type does. The Perl file implements the concretebehavior of the type and it is explained in section 6.4. It is used to perform the testtype automatically.

In section 5.1 it is described, that for compiling the source code the RTE generatorhas to accept the configuration and create the RTE. Thus, compiling of the sourcecode 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 rejectsa 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 revertto the test “accept”, which obviously has to be finished successfully before. This leadsto the dependencies between test types.

In section 5.1 it is also described, that for the operating system configuration ad-ditional OIL files and for compiling additional source files are needed. So a test typealso 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 withtheir dependencies. The test types in the blue boxes can be performed automaticallywithout an interaction of the user. The result can be obtained from return values ofthe executed programs. The blue boxes show the tests, which are performed by the

39


configuration

reject configuration accept configuration

copy to Mx17 PST

compile Mx17 PST

run Mx17 PST

compile RTA–OSEK5.0 for PC

run RTA–OSEK 5.0for PC

code review

Figure 5.3: Dependencies of the test types

user and for which the user determines the result. The types are described in thefollowing.

accept configuration This type calls the RTE generator with the XML configura-tion files. If the generator creates the RTE, the type is correctly finished. This typeneeds 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 fin-ished 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 betried 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 userreviews the code to obtain the result of the test.

compile OSEK–OS 5.0 for PC After generating the RTE the source code for theoperating system is created. Then all source files are compiled and linked to a binaryfile, which can be executed on the PC–Port of the operating system. This type alsorequires some variables. It needs the name of the binary that should be created andthe paths to the compiler and linker. These variables are all predefined with defaultvalues. 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 startingthe RTE.

40


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 someoutputs 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 avariable this type requires a period of time that specifies how long the binary shall beexecuted.

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 copiedto the MEDC17 directory, to integrate the test. So just one checkout is used for thewhole environment. The names of the copied files are stored in the MEDC17 directoryto delete the files before files of another test are copied to MEDC17. The test typerequires also some variables. These are the location of the PST and the names of thesubdirectories, in which the files shall be copied.

compile Mx17 PST The compilation of MEDC17 is not integrated in the envi-ronment. It has to be performed with other build tools, which have to be startedmanually.

run on control unit Here again, the flashing of the compiled MEDC17 to the con-trol unit and the debugging of the control unit, have to be done by the user. Thisis done with the graphical debugger Universal Debug Engine, which is the debuggerused at BOSCH.

With this description it is clear that the test type “code review” does not need aPerl script, because everything, which can be done automatically is done by an testtype that is executed before. So a test type, which is performed by the user, does nothave a Perl file.

5.2.6 Variables

To keep the test types configurable for a test template, variables are introduced. Thetypes e.g. need the name of the ECU in the configuration files, for which the RTE shallbe created, or a period of time for which a compiled binary shall be executed. Suchvariables 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 previoussection. Typically the variables are set by the test templates, but a test type can alsoprovide a “default value”, which is used, if no other is specified. A variable withouta “default value” has to be set from a test template that uses this test type. A testtype additionally sets a description for the variable. The description should explainthe purpose of the variable.

5.2.7 Test Template

A test template consists of a number with four digits and a name. The template isunique identified by the number. The number is also used to sort the templates and

41


group related templates together. A template has a description of what is expectedto test. The description can contain some proceedings for the user, which helps tointerpret 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 theresources, which should be used for the test.

A template also has to specify the test type. It must set the variables that arerequired by the test type. Due to the dependencies between the test types, the variablesfor 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 combinationof 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 avalid 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 determinethe result.

5.3 Configuration of the Components

The structure, which is explained in the previous section, provides a flexible basis tocreate tests and reuse a lot of components for these tests. This structure could bestored in a database. However, this is not done, because some of the files should beedited with external tools. Therefor a file system structure, which is explained inthe next section, is used for storing the components. This section deals with somesimplifications. So not every part described have to be stored separately. Insteadsome components are stored implicitly with the others.

The attributes and relations of test templates, RTE generators and test types arestored in XML files, which are described in section 6.5. The resources in principle onlyconsist of files and they are just stored in a directory and the directory name is usedas name for the resource. The RTE libraries also consist of files and they are also juststored in a directory.

The tests itself have not to be configured. Every test evolves from an RTE generatorand a test template. Everything, which is defined by these two components is usedfor the test.

Variables and options are not stored separately. The test type also defines therequired variables together with a description, for what this variable is used. The testtemplates defines also values for the variables. The options are just set by the RTEgenerators and the same names are used by the test templates. The description of theoptions is stored in a global configuration of the environment.

The options, which are required by the test template, and the command lines forthe RTE generators are handled in a special way. This is described in the following.

42

5.4 Structure of the File System

Command Line

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 itis substituted at the execution with the value. For the command line the followingvariables are currently used.

RTE GEN OPTIONS This variable is set by the test template with the requiredoptions for the RTE generator and it is substituted with the concrete values for thegenerator. 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 theECU for which the RTE should be created.

TEST CONF This variable is substituted with the AUTOSAR XML configurationfiles, which have to be passed to the generator.

In principle every variable, which is set by a test template or a test type, can beused. Currently no other than the here described are necessary. The command linefor 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 bythe template and the configuration files are appended at the command line.

Options

The options are defined by RTE generators with the concrete parameters. The variableRTE 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 beused to define an option. An example string of options as they are typically used forMEDC17 is:

$(OS HDR AUTOSAR H) $(ATOMIC ASSIGN TYPES) $(OS ERCOSEK) y$(TASK AS FUNCTION ENABLE)

The purpose of this options is described in section 7.3 with the example for MEDC17.


The whole environment is stored in the file system. This is especially needed to storethe AUTOSAR XML files and the source files and to edit them with other tools, whichare not part of the environment. The basic structure of the file system is shown infigure 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


directory” and the tests are stored and performed in a “test directory”. RTE librariesare 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 elsein the file system, because they are also used for other purpose. The content of thesedirectories 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 implemen-tation and described in section 6.6.

rootpool

Autosar Release 2.0resources

Ecu0010 Ecu1

0020 Ecu2

. . .nnnn Ecun

global typesinterfacestypes

System0010 System1

0020 System2

. . .mmmm Systemm

rte generatorsgenerator name1 version1

. . .generator nameo versiono

test templates0010 template name1

. . .pppp template namep

Autosar Release 2.1. . .

performAutosar Release 2.0

generator name1 version1

0010 template name1

. . .pppp template namep

. . .generator nameo versiono

. . .Autosar Release 2.1

. . .types

name1

. . .nameq

configuration.xmlRteEvaluation.batRteEvaluation.jarswt.jar

normal directory

resource directory

configuration directory

test directory

file

Figure 5.4: Structure of the file system

The test types are independent from the AUTOSAR release and they are stored in asubdirectory of the directory “types”. The name of the subdirectory is the name of thetest 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 firstdivided 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


are stored inside the directory “test templates” and the subdirectories are named withthe number and name of the templates.

The resources are stored in the directory “resources”, but there is a division withother subdirectories done. These subdirectories group resources and are described inthe following.

global types This directory just stores the resources “types” and “interfaces”. Theycontain AUTOSAR XML descriptions of data types and port interfaces. They areseparately stored to be reused in every test.

System The residual part of the XML configuration is divided into the system andthe ECU description. The whole system is contained in the directory “System”. Thisis the part, which can be edited with the AUTOSAR Authoring Tool (AAT) from theGEENSYS AUTOSAR Builder.

Ecu The ECU specific configuration is contained as a resource in this directory. Thisis 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 ofthe “types” and “interfaces” and one resource contained in “System” and one containedin “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 belongto 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 filesare 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 subdirectoriesare possible1, 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.1This is stored in the file configuration.xml and can be changed in the environment.

45


The structure of the resource directories are also used to store the RTE libraries inthe external location.

5.4.3 Configuration Directory

A configuration directory is in principle based on the structure of the resource di-rectories 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 thisdirectory. This script has to be called test type.pm. The XML files have a differentname 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. Onlythe subdirectories are displayed, which are really used in the environment, but it ispossible to use all the subdirectories described in the previous section.

RTE generator

<name> <version>rte generator.xml

test type

<name>ConfHdrOilSrcXMLtest type.pmtest type.xml

test template

<number> <name>Doc

doc1

. . .docn

test template.xml

Figure 5.5: Structure of the configuration directories

An RTE generator is stored anyway else in the file system, so there is just the con-figuration needed. For test types, maybe some other files are necessary to perform thetest. This can be e.g. additional source or configuration files needed for the operatingsystem. The Perl script is also needed for a test type. A test template just consists ofthe configuration and a subdirectory “Doc”, which stores additional files to describethe 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 theAUTOSAR release. Inside such a release directory, the tests are identified with apath consisting of two directory names. Since a test consists of an RTE generator anda 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 sourcefiles, the RTE generator provides the RTE library and every test type can providesome additional files for performing the type. The configuration of the test itself isstored in the file test.conf. It contains the variables, which are set for this test, and

46

5.5 Summary

test directoryTestConfTestSrcTestDocRteGenOutputRteGenSrcRteGenHdr. . .test.conftest.logtest.result

Figure 5.6: Structure of a test directory

the options for the RTE generator. The file test.result contains the result of everyperformed 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 samesubdirectories than before. Instead a prefix is added, which indicates the origin ofthis resource. So the new directory name is <prefix><suffix>, where <suffix> isthe name of the origin subdirectory. The value <prefix> is set by the object whichprovides 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 specifiesits 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 configurationfiles from resources specified by the test template. The directory “RteGenSrc” containsthe source files of resources specified by the RTE generator. The RTE generator justprovides the RTE library, so the source files of the RTE library are stored in thisdirectory.

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, andhow tests are created out of this structure by combining a test template and an RTEgenerator. It is also shown, how the environment is sectioned by the file system. Thenext chapter deals with the concrete implementation of the environment to achievethis behavior.

47


48

Chapter 6

Implementation of the TestEnvironment

The previous chapter describes the structure and behavior of the environment to fulfillthe requirements. This chapter deals with the implementation and thus how thisbehavior is achieved. First are some design decisions explained and the user interfaceis shown with some screenshots. Afterwards, the implementation of the created userinterface is described. Then the Perl files of the test types and the XML files forstoring 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 systemstructure to configure the tests. The execution should be done by some scripts. In theprevious chapter the structuring of the environment is explained and a lot of variationpossibilities are shown. These variations are the reason, why the configuration filesseamed very confusing for the user and lead to some error sources. So the decisionwas taken to create a Graphical User Interface (GUI) to access, configure and performthe 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 javais 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 isfaster 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 againsta scheme [28]. If another format would be used for storing the configurations, theparser would have to be reimplemented for this format. For XML it is just necessaryto 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 testtemplate, which consists of four digits.

6.1.4 Perl for Tests

But not everything of the environment is implemented using Java. Every test typeneeds its own functionality, which has to be executed. This is e.g. an execution ofthe RTE generator or the compilation of the source files. This functionality has tobe implemented for every test type and since a test type is just a component of theenvironment, it should be possible to add and edit types. But for editing a type, nochange of the code and especially no rebuild of the GUI shall be necessary. So thefunctionality of a test is not implemented as a Java class. Instead it is implementedas a script, which is executed, when the test is performed. And so the type can beedited 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 BOSCHcomputers 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 areshown and the functions of the GUI elements are explained.

After starting the application a dialog, which is shown in figure 6.1, occurs. Theuser 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 thechosen 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 templatesand 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


12

3 4

5

6

Figure 6.2: RTE generator configuration view

51


6.2.1 RTE Generator Configuration View

The view used for configuring the RTE generators is shown in figure 6.2. The severalparts 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 ofthe environment. The test types can be configured in this dialog, because thetest types are the same for every release and they are normally not changed. Itallows also to set the path of the Perl interpreter and to edit the subdirectoriesof the resource directories.

3. The RTE generator, which should be configured, is selected in the list at theleft side. The buttons at the top of the list allow to copy or delete an existinggenerator or create a new one.

The right part of the window contains widgets for configuring the several parts ofthe chosen generator. If there is a problem with the configuration, the widgets showthe corresponding part with red color. These widgets are now described.

4. The main attributes of an RTE generator are the executable, the command lineand the directory, which contains the RTE libraries. The attributes can be setin this widget for configuring the generators.

5. The options of a generator can be edited, added or deleted. The table shows thename of the options in the environment together with the concrete parametersfor the selected RTE generator. The options are edited with a dialog, which alsoshows the description of the option.

6. In addition to the variables of the test templates and the test types, variablescan be specified for an RTE generator. This could be useful in some specialcases. E.g. The variable FLEXLM BATCH has to be set for RTE generatorsfrom 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 viewalso 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 correspondingpart with red color. All parts are described in the following.

1. The list shows the test templates. With the buttons at the top of the list existingtemplates can be copied or deleted or new templates can be created. The selectedtemplate can be configured with the widgets a the right side.

52


1

2

3

4

5

Figure 6.3: Test template configuration view

53


2. This part is to edit the description of the test template. Additional documen-tation files can be added to the list at the right via drag’n’drop. These files arestored in the subdirectory “Doc” of the test templates and they are useful forfurther description of the test.

3. The main options of a test template can be edited with this part. The RTElibrary, which shall be used, the test type and the options for the RTE generatorcan be set.

4. This widget shows the resources, which are configured for the selected test tem-plate. 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, whichare defined by the used test type and all required types, are also shown. Forediting the variables a dialog is used. This dialog shows the description of thevariable, if the variable is required by a test type. So the usage of the variableshould 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 partsare now described.

1. The RTE generator, for which the tests shall be performed, is chosen with thisbox.

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 orif it requires an RTE library that is not provided by the selected generator. Ifthe selected RTE generator has errors in the configuration, all tests are shownwith 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 inthe list is used to choose some tests for performing them at once.

3. These buttons are used for special purposes. The “select automatic” buttonselects all checkboxes of the tests in the list, which can be performed withoutinteraction of the user and are not colored gray. The “select none” button cancelsthe done selection. The “export results” button is used for exporting the resultsof all tests, of which the checkbox is selected. The export is done in an Excelfile 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 ofthe executed programs shown. Additionally, it shows some information from theenvironment like e.g. which test type is started and how it is finished.

54


1

2

3

4

5

6

78

Figure 6.4: Perform view

55


5. The test types, which shall be performed for the selected test, are shown at theright side. For every test type a box is shown, where the type can be started orstopped. It is also possible to add a comment for the test type. The first box isused to create or delete the test. If the test isn’t created, only the first box isshown and the test have to be created first. If a test type cannot be performedautomatically, the button “start” cannot be used. Instead the result has to bedetermined by the user and added with the “edit” button. The dialog for editingthe result also shows the description of the corresponding test template. So theuser 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 testcan 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 commentsfor this one test. It is generated automatically after a change at the test and itis 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 checkboxis 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 isimplemented with Java and SWT. This section gives an overview of some implementedJava classes and their functionality. Only the major classes are described. There arealso some simple classes like rte .evaluation.SortedList or some dialog classes, whichare not essential for basic functionality of the application. For further information thesource code and the source documentation should be consulted.

The class diagrams shown in this section do not visualize the dependencies to SWTclasses. Because they would only add superfluous complexity to the diagrams and theyjust 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 ILogis used. Objects that implements this interface can be added to the class LOG, whichjust provides static methods. If a write is done to the class LOG, it is distributed toall added objects.

This is used to distribute the output during a test execution to the Test object itselfand 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

rte.evaluation.resource

rte.evaluation

ConfigurationPool

TestTypePool TestTemplatePool RteGeneratorPool

TestType TestTemplate RteGenerator

ConfigurationStore

ResourcePool Resource

MainConfiguration

XMLParser

IPoolChangeListener

IConfigurationChangeListener

1

∗

1 ∗

∗∗

∗

∗

1

J creates

11

Jcre

ate

s

Jcre

ate

s

Jcre

ate

s

∗1

∗1

∗1

∗

1

1

J uses ∗

1

1

∗1

creates I ∗1

∗ ∗

J notifies∗ ∗

∗ ∗

J notifies∗ ∗

Juse

s∗

∗

∗

J uses

∗

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 pack-age is shown in figure 6.5. The dependencies to other packages are also shown. Theconfiguration is stored using XML files.

The classes RteGenerator, TestTemplate and TestType are used to store and accessthe configuration of the components. They provide an adapter to the configurationdirectories described in section 5.4.3. The structure of the used XML schemes are de-scribed in section 6.5. The schemes are very similar for the different components. Thesuperclass 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 XMLstructure itself.

57


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. Additionallythere are some methods to check for consistency. This means that there are no objectswith the same name or the same number in case of a test template. The classes havealso a lot of similarities, which are outsourced to the superclass ConfigurationPool.

To access a resource directory, the class Resource is used. The ResourcePool handlesall resources of the environment and additional the RTE libraries in the externallocations. The several classes are separately described in the following.

ConfigurationStore This is an abstract class, which provides access to the XMLconfiguration files. An XML file stores the properties of an object and it is checkedagainst an XML scheme. Derived classes have to provide an XMLParser object forchecking the XML files. Then some methods can be used by derived classes to accessspecial elements in the XML structure and so derived classes have not to deal withthe XML structure itself. IConfigurationChangeListener can be added to an object ofthe class ConfigurationStore. The listeners are used as a callback and their methodconfigurationChanged() is called, if a property is changed. Every ConfigurationStorecontains one resource, which is used to access the subdirectories of the directory, inwhich the configuration is stored.

RteGenerator This class represents a type for RTE generators. It provides anXML parser and methods to get and set the properties of an RTE generator. TheRTE libraries are also handled as objects of the class Resource.

TestType This class represents a type for test types. It provides an XML parserand methods to get and set the properties of a test type. The Perl file of the test typecan also be accessed.

TestTemplate This class represents a type for test templates. It provides an XMLparser and methods to get and set the properties of a test template. The for the testtemplate configured AUTOSAR XML configurations are handled as objects of theclass Resource.

IConfigurationChangeListener Objects which implements this interface can beadded 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 forthe classes RteGeneratorPool, TestTemplatePool and TestTypePool. These are themanagement of a set of ConfigurationStore objects and methods to delete and createthese objects. Objects of IPoolChangeListener, which are added to an object of thisclass, are notified if the pool is changed. This means, if a configuration is added ordeleted.

58


RteGeneratorPool This class extends the class ConfigurationPool to provide ad-ditional functionality for a set of RteGenerator objects. These are methods to get theunion of all options and RTE libraries provided by the generators.

TestTypePool This class extends the class ConfigurationPool, but it does not addreally some new functionality. It has to be derived to implement some abstract meth-ods for TestType objects.

TestTemplatePool This class extends the class ConfigurationPool, but it does notadd really some new functionality. It has to be derived to implement some abstractmethods for TestTemplate objects.

IPoolChangeListener Objects, which implement this interface, can be added toobjects of the class ConfigurationPool to get notified about changes. The interfacejust provides one single method poolChanged(), which is called, if a configuration isadded or deleted.

MainConfiguration This class does not depend on the other classes of this pack-ages, but it provides properties which are globally for the whole application. Likethe properties of the class ConfigurationStore, the global properties are also storedusing an XML file. The class MainConfiguration provides get and set methods for thepath of the Perl interpreter, the names of the subdirectories which are considered forresources and the descriptions of the RTE generator options.

The package rte .evaluation.resource is completely described with all containedclasses in this diagram. These classes and the class XMLParser are now described.

Resource This class represents a resource of the environment. Resources are typi-cally 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 section5.4.2. It just considers the subdirectories.

ResourcePool This class provides access to all resources of the environment. AResource 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 additionallyhandles external resources like the RTE libraries.

XMLParser This class provides methods to parse and write XML files. It addition-ally provides methods to check the files against an XML scheme and to create emptyXML documents. It encapsulates some classes of the Java class library to provide asimple interface for XML access.

6.3.3 Perform

The main purpose of the environment is to perform tests. This is done by the packagerte .evaluation.perform, which is shown in figure 6.6. A test is represented by the classTest. Creating and performing a test needs a lot of accesses to the file system and

59


rte.evaluation

rte.evaluation.configuration

java.lang

Test

TestTemplate

RteGenerator

TestCreatorTestPerformer

ILogLog XMLParserXMLParser

TestType

LogCatcher

Thread

ITestPerformerCallback

IRunnerCallback

∗J

noti

fies

1

∗

notifies I

1

∗

J notifies1

1

J writes log

∗

1cre

ate

sI

1

11

∗ 1writes log I

1∗

wri

tes

log

I

1

∗

1

1performs I

1∗

1

creates, uses I

1

11 J creates

1 J uses

1

1 J uses

Figure 6.6: Class diagram rte .evaluation.perform

60


other tools like the RTE generator. So creating a test is done by the class TestCreatorand 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 testand the results are saved in the files test.conf and test.result, which are accessed usingan XMLParser. The file test.log is stored in a simple text format. So it is easier tosend 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 directorydescribed in section 5.4.4. This class also implements the interface ILog, to get theoutput of the executed test.

TestCreator A TestCreator object creates a Test object for the application, but alsothe required directory in the file system with the content. It needs an object of theclass RteGenerator and TestTemplate to create the test. It writes the configurationfiles and additionally copies the needed files to the test directory depending on theneeds 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 theenvironment 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 IRunnerCallbackabout the finished execution. An ITestPerformerCallback is notified if a new test typeis started or finished.

IRunnerCallback This interface is used as a callback to get notified when an op-eration is finished.

ITestPerformerCallback This interface is used as a callback. It is notified byan object of the class TestPerformer about every single test type, that is started orfinished.

6.3.4 Main Window

The package rte .evaluation.ui provides the classes for the main window of the applica-tion. The window is implemented by the class EvaluationWindow. It also contains themain() method for the application. The whole package is shown in the class diagramof figure 6.7.

The window is parted into a left sidebar and a greater content pane, which is locatedat the right. The content of the window can be changed by buttons, which are locatedat the upper right of the window. Each view that can be shown in the window have tobe an object implementing the interface IEvaluationContentProvider of the packagerte .evaluation.ui .content.

AEvaluationWindow This abstract class implements the behavior for showing theviews and switching between different views. It shows a button to edit the preferencesat the upper left of the window. The GUI part of the main window is outsourced tothis class.

61


rte.evaluation.ui.dialogs rte.evaluation.ui.content

rte.evaluation.ui.content.configure

rte.evaluation.ui.content.perform

rte.evaluation.configure

AEvaluationWindow

EvaluationWindow

IEvaluationWindowContentProvider

PreferencesDialog

ComboChooseDialog LogPanel

RteGeneratorPanel

TestTemplatePanel

TestPerformPanel

RteGeneratorPool

TestTemplatePool

TestTypePool

∗111 J creates, uses

11 J creates, uses 1 1creates I

1creates I

1

1creates I

1creates I

1 J creates

1

1 J creates

1 J creates

Figure 6.7: Class diagram rte .evaluation.ui

62


EvaluationWindow This class implements the main window for the application.The behavior for switching the content and displaying the GUI is inherited from theabstract superclass AEvaluationWindow. The class shows the dialog for choosing theAUTOSAR release version at the beginning. Depending on this choice, the classesTestTypePool, RteGeneratorPool and TestTemplatePool will be instantiated. Thenthe 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 classesRteGeneratorPanel and TestTemplatePanel. Due to the structure of the configurationclasses 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 wholepackage overview is shown in figure 6.8.

The class AConfigurationContentProvider provides a view for the window, whichshows a table with all elements of a given ConfigurationPool at the left sidebar. Theright content is filled with objects, which shows the selected configuration. Theseobjects are of the type AConfigurationContentGroup. If a selection is done at thetable, 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 aconfiguration, which is only done in the application by the content groups. The in-terface IPoolChanged is not used, because the class AConfigurationContentProvideris the only one, which initiates creation or deletion of configurations for a pool andso it has not to get notified about the change. For creating a new configuration,the RteGeneratorPanel and TestTemplatePanel displays a dialog for getting the newname.

AConfigurationContentProvider This class provides a view for the main windowto show a ConfigurationPool and to show and edit each ConfigurationStore of the pool.The widgets to edit the configurations are of the type AConfigurationContentGroupand instantiated by subclasses.

RteGeneratorPanel It is derived from AConfigurationContentProvider and setsthe RteGeneratorPool to the parent. It instantiates objects of OptionsContentGroup,RteGeneratorContentGroup and VariablesContentGroup for editing the RTE genera-tor configurations.

TestTemplatePanel It is derived from AConfigurationContentProvider, sets theTestTemplatePool to the parent and instantiates objects of ResourcesContentGroup,DescriptionContentGroup, TestTemplateContentGroup and VariablesContentGroupfor editing the test template configurations.

To configure the test templates and RTE generators a set of widgets is used. Ev-ery widget provides some special parts of the configuration. Each widget is de-rived from the abstract class AConfigurationContentGroup, which is shown by the

63



rte.evaluation.ui.content.configure.widgets

rte.evaluation.ui.content

rte.evaluation.ui.dialogs

AConfigurationContentProvider

RteGeneratorPanel

TestTemplatePanel


IConfigurationChangeListener

TestTemplateNameEditDialog

RteGeneratorNameEditDialog

AConfigurationContentGroup

TestTemplateContentGroup

VariableContentGroup

RteGeneratorContentGroup

...

...

ConfigurationPool

ConfigurationStore

∗1

∗J shows, edits

∗

∗J shows, edits

∗

∗J shows, edits

∗

11

1 J creates

1

1 J creates

1

1 J creates

1

∗1

11 J shows

∗∗ J shows

∗

∗

∗

noti

fies

I

∗

1

cre

ate

s,use

sI

1

1

cre

ate

s,use

sI

1

Figure 6.8: Class diagram rte .evaluation.ui .content.configure

64


rte.e

valu

ati

on.c

onfi

gura

tion


AConfigurationContentGroup

TestTemplateContentGroup

DescriptionContentGroup

ResourcesContentGroup

ATableContentGroup

VariableContentGroup

OptionsContentGroup

RteGeneratorContentGroup

ConfigurationStore

RteGenerator

TestTemplate

RteGeneratorNameEditDialog

OptionEditDialog

VariableEditDialog

TemplateNameEditDialog

TextEditDialog

ResourceChooseDialog

1 creates, uses I 1

1 creates, uses I 1

1 creates, uses I 1

1 creates, uses I 1

1 creates, uses I 1

1 creates, uses I 1

∗

J shows ∗

J shows, edits ∗∗

J shows, edits ∗∗

∗J shows, edits

∗

∗J shows, edits

∗

∗J shows, edits

∗J shows, edits

Figure 6.9: Class diagram rte .evaluation.ui .content.configure .widgets

65


AConfigurationContentProvider. The widgets normally show, if there is an error withthe configuration. This is done by coloring some parts of the GUI red. All widgets arecontained in the package rte .evaluation.ui .content.configure .widgets, which is shownin figure 6.9.

AConfigurationContentGroup This class provides some functionality of a wid-get, that can be added to AConfigurationContentProvider to show and edit configu-rations. The behavior for showing and editing special parts of the configuration hasto be implemented in the subclasses.

ATableContentGroup This widget shows a table in the content group and buttonsto edit, add and remove entries. This is used in some subclasses.

VariablesContentGroup An object of this class shows the variables of a config-uration. The variables can be edited or removed. New variables can be added. If aTestTemplate is shown, variables, which are required by the test types and which arenot set, are colored red.

OptionsContentGroup It shows the Options of an RTE generator. Like for thevariables, 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 canbe edited and new description files can be added.

ResourcesContentGroup This widget provides access to the configured resourcesfor a test template. Resources can be added or removed. If a shown resource cannotbe resolved, it is colored red.

TestTemplateContentGroup It allows to configure special needs for test tem-plates. 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 gener-ators. This is the choice of the executable, the command line and the path, where theRTE libraries are located. If the executable or the directory with the RTE librariescannot be resolved, they are colored red.

6.3.6 Perform Widgets

The package rte .evaluation.ui .perform provides the classes for performing the testvia 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 alsoto 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



rte.evaluation.perform

rte.evaluation.perform java.lang


rte.evaluation.ui.content

TestPerformPanel


TestStepPerformPanel

PerformComponent

TestTemplatePool

RteGeneratorPool

TestPerformer

TestCreator

Test

TestEditDialog

LogPanel FileBrowser

IRunnerCallback

Runnable

ITestPerformerCallback

1 11

1creates, uses I

∗1

∗

Jcre

ate

s

∗

1

J creates, shows

∗

11

1∗J uses 1

1

J uses 1

1

Figure 6.10: Class diagram rte .evaluation.ui .perform

67


with the interface java.lang.Runnable, which is executed in the SWT thread. So allclasses of this package additionally implements this interface.

There are two ways to create an object of the class Test. The test directory canstill 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 createdfrom 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 interfaceIEvaluationWindowContentProvider. It displays a sidebar at the left, where the testsand RTE generators can be chosen. Therefor the objects of TestTemplatePool andRteGeneratorPool are needed. In the middle of the window is a LogPanel displayed toshow the log of the test. At the right side is a TestStepPerformPanel and a FileBrowsershown. The first is to perform every test type separately. The second is to access thetest directory directly from the GUI.

TestStepPerformPanel This widget displays some PerformComponents to accessevery test type separately. It implements the interface ITestPerformerCallback to getnotified about the execution of the several test types. So the PerformComponents areupdated to show the current state of the execution.

PerformComponent This class provides two buttons to start a test type or editthe 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 typeis 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 environment1,so that the script can access them.

Some functions are typically used in several scripts, which belong to the specialrequirements of the execution context of the script. These functions are outsourced toanother 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. Thesefunctions are outsourced to the file utils.pm to use them in the other scripts and theyare described in the following.

1The global environment, in which the Perl script is executed, is meant and not the evaluationenvironment.

68

6.4 Implementing Tests with Perl

substitute (string) This function substitutes occurrences of “$(variable)” with thevalue of the variable. The substitution is also done for the substituted values. Thisfunction is normally just called by the function get value.

get value (variable, std value) It returns the value of the given variable. Sub-stitutions with substitute () are already done. The second argument is used to set astandard value, which is returned if the variable is not defined. This function is typi-cally 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 agiven file with the given command line as argument. If the executed command returnsa value, which is not 0, the script is exited with this return value. This can beinvalidated by setting the last argument. Then the function returns in every case afterthe execution of the command and the return value of the function is the return valueof the command.

execute in dir (dir, executable, command line, proceed if fail) If it is nec-essary 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 thecommand is executed and it is changed back after the execution.

The following functions operate on arrays. They are typically used in the scripts toprocess an array of file names.

prefix (prefix, array) This function adds the given prefix to every value in thearray.

suffix (suffix, string) This function adds the given suffix to every value in thearray.

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 andhow the functions from the previous section can be used. As an example is the testtype “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 usedto set the autoflush for the standard output and the error output. This is needed thatthe 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 directorystill exists. Then the array @autosar files is created, which contains all AUTOSAR

69


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;

Listing 6.1: Perl file for the test type “accept configuration”

70

6.5 XML Scheme

configuration files. This are the files with the extensions “.arxml”, “.epc”, “.xml” inthe directory “TestConf”. Normally the extension, which is specified by AUTOSAR,is “.arxml”. However, the other extensions are used by the GEENSYS AUTOSARBuilder and so they are used here, too.

With the use of the function prefix the prefix “../” is added to every file in the arrayadded, because the RTE generator should be called from the directory “RteGenOut-put” and therefor the relative paths of the files have to be adjusted. The resultingarray 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 thecommand 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 lineis got with the function get value(), which does also the substitution of the variablesin the command line and in the options.

It is just necessary to exit the script with success, because, if the generation of theRTE 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 checksfirst. In section 6.3 is the class XMLParser used multiple times and there exist somedifferent 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. Thena root element is defined with “definitions”. This root element contains the otherconfigurations. The tag <xs:complexType> means, that the type of this element iscomposed by others. The tag <xs:all> defines some other elements, which occurs atmost once and in an arbitrary sequence. So the order of the elements in the XML filecan be changed.

The “number” and “name” tag have to exist and so they are always set. The othersare optional, but the environment handles e.g. an empty test type in the same way asa wrong test type and displays an configuration error.

The files are mainly parted in two kinds of elements. The one are simple valueslike “name”, “description” or “number”. The others are lists of elements. The classConfigurationStore, which is described in section 6.3.2, provides methods for the accessof 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 locatedin the base directory of the environment. This file contains the classes described in

71

1 <?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:simpleType name="four-digit-number"><xs:restriction base="xs:string">

<xs:pattern value="[0-9]{4}" /></xs:restriction>

</xs:simpleType>

10 <xs:simpleType name="non-empty-string"><xs:restriction base="xs:string">

<xs:minLength value="1" /></xs:restriction>

</xs:simpleType>

<xs:complexType name="variable"><xs:all>

<xs:element name="name" type="xs:string" /><xs:element name="value" type="xs:string" />

20 </xs:all></xs:complexType>

<xs:complexType name="resource"><xs:sequence>

<xs:element name="path" type="xs:string" /></xs:sequence>

</xs:complexType>

30 <xs:element name="definitions">

<xs:complexType><xs:all>

<xs:element name="name" type="non-empty-string" /><xs:element name="number" type="four-digit-number" /><xs:element name="description" type="xs:string" minOccurs="0" /><xs:element name="test-type" type="xs:string" minOccurs="0" /><xs:element name="rte-library-to-use" type="xs:string" />

40 <xs:element name="rte-options" type="xs:string" minOccurs="0" />

<xs:element name="variables" minOccurs="0"><xs:complexType>

<xs:sequence><xs:element name="variable" type="variable" maxOccurs="unbounded" minOccurs="0"></xs:element>

</xs:sequence></xs:complexType>

</xs:element>50

<xs:element name="resources" minOccurs="0"><xs:complexType>

<xs:sequence><xs:element name="resource" type="resource" maxOccurs="unbounded" minOccurs="0"></xs:element>

</xs:sequence></xs:complexType>

</xs:element>

60 </xs:all></xs:complexType>

</xs:element></xs:schema>

Listing 6.2: XML scheme for the test templates

72

6.7 Summary

1 <?xml version="1.0" encoding="UTF-8"?><definitions><name>Mode Test</name><number>0300</number><test-type>run RTA-OSEK5.0 for PC</test-type><variables>

<variable><name>ECU AUTOSAR PATH</name><value>/system root/system/system topology instance∗/ecu</value>

10 </variable><variable>

<name>ECU NAME</name><value>ecu</value>

</variable></variables><resources>

<resource><path>Ecu/0300 mode test</path>

</resource>20 <resource>

<path>global configs/interfaces</path></resource><resource>

<path>global configs/types</path></resource><resource>

<path>System/0300 mode test</path></resource>

</resources>30 <description/>

<rte-library-to-use>Original</rte-library-to-use><rte-options>$(ATOMIC ASSIGN TYPES)</rte-options>

</definitions>

Listing 6.3: XML example for a test template

section 6.3 and the XML schemes described in section 6.5. The SWT library for theGUI 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 auto-matically 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 somescreenshots of the GUI are shown and explained. Then an overview of the implemen-tation of the GUI is given. Some class diagrams show a first introduction to the sourcecode 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 typesare implemented. The XML scheme for storing the configurations is explained and itis also described, how the application can be started.

73


74

Chapter 7

Test Cases

The environment would be very useless without test cases. So this chapter first dealswith some explanations for creating test cases. After that some test cases, which arecreated 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 offeatures 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 thiswork. Some little things for MEDC17 are described in section 7.1.4, but some of themwere known before this work started. The bulk of the found bugs belongs to the RTEgenerator and it turned out that before an integration test for MEDC17 is createdand 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 someinformation 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 configu-rations which are explicitly marked as not valid in the AUTOSAR specification. Hereare some examples for this.

• A configuration with a SWC which has a required port that is not connected toa 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 withan OperationInvokedEvent. If a component does not provide a runnable for anoperation, this configuration is invalid and shall be rejected.

• All OnEntry and OnExit triggered runnables for a mode switch, shall be mappedto the same task. If this is not the case, the configuration shall be rejected bythe RTE generator.

75

Chapter 7 Test Cases

These examples show, that such tests can be really small. It makes no sense tocombine the tests, because each invalid configuration shall be rejected and not justthe combination of some invalid features.

Configurations that should just be accepted and nothing else like compiling or re-viewing the code should be done are really rare. Because typically for an accepted testsomething else should be checked. Here is one example of a test that is just done byaccepting the configuration.

• For a SWC with a provided and a required port of the same interface it is allowedthat these two ports can be connected. This is a case, the generator shall acceptand create the RTE.

Here can also the functionality of this port be tested, but in this form it fits to someother 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 thecode is much easier.

Typically, it is not a priori expected for a configuration that this should be testedwith a code review. However, typically an inefficient implementation is found bycreating a test for other things. Then the configuration can be used to create such atest out of this. This test can be used to check newer versions of the RTE generatorto 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 behaviorof the SWCs has to be implemented in such a way, that the tested issues really occurand that the result can be obtained by the components itself. The components canthen 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 bycreating an output, that starts with the string “ERROR”. So the behavior have to bechecked by the components and if something goes wrong, an error output should becreated. The function printf (const char∗,...) of the C standard library can be usedby the runnables to create the output.

Typically tests for systems that are split into several tasks are setup to test dataconsistency. The data consistency is often vulnerable, if one task interrupts anothertask. So it is often necessary to provoke such an interruption of tasks. It is reallyhard to do this with TimingEvents and to ensure that the interruption really takesplace. So it turned out that DataReceivedEvents are a good mechanism to ensure aninterruption at a defined position. The data has to be sent from a runnable through aport 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 itcan be ensured that the current execution is really interrupted.

To check the consistency, some global variables can be used to communicate betweenthe components without using the RTE. It has to be ensured that this global variablescannot 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 chapter3 it is described that the tasks of MEDC17 are mainly based on a periodic executionand that the whole application software also uses this timings. For integration ofAUTOSAR code in MEDC17, not only TimingEvents should be considered, but thisis the first approach.

The RTE is just another piece of application software that runs on MEDC17. Toinitialize the RTE a call of Rte Start() has to be done. The RTE generators fromETAS are extended with an option supporting the integration of AUTOSAR tasks inMEDC17. This option is called “−−task−as−function” and leads to the generationof functions instead of tasks in the generated code from the RTE generator.

run1 run2 . . . runn

p1 p2 . . . pm

Rte

Task

OS

Drv

100ms

(Function)

OS Drv 100ms (AUTOSAR task)

OS Drv 100ms (MEDC17 task)

100ms

100ms

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 AUTOSARtask to MEDC17. The existing MEDC17 task is time triggered. The RTE gener-ator creates an AUTOSAR task, which is also time triggered by the same period.Instead of changing the operating system configuration of MEDC17 to schedule theAUTOSAR task, this task can easily be used as a MEDC17 process. The task bodyof the AUTOSAR task OS Drv 100ms is changed to a function body of the functionRte Task OS Drv 100ms by using the option. This function is added to the processesof the MEDC17 task with the same name. So the AUTOSAR runnables are executedin the same timing as before. However, to do this some conditions have to be satisfied.

77


• The AUTOSAR task content has to be executed in the same timing. This isobviously true for the shown example

• The code out of the AUTOSAR tasks shall not do any task handling. If there ise.g. a call of ChainTask(OS Drv 100ms), then this call is added to the MEDC17task. The MEDC17 task will be restarted after termination, but this also restartsthe original MEDC17 processes p1, . . . , pm and this will change the originalbehavior.

• 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 opti-mizations, which depends on the priority of all tasks and the tasks are executedin MEDC17 with different priorities, this can cause an unexpected behavior.

This option cannot only be used to integrate time triggered AUTOSAR tasks intoMEDC17. Also other RTE events can be used, but this should be done in a differenttask.

To handle other tasks, the operating system configuration has to be changed. Thisconfiguration is strongly included in the whole toolchain and the code of the tasksare typically auto generated at every build. So to use a task, which is generatedfrom the RTE generator, a big change at the toolchain has to be done. The op-tion “−−task−as−function” provides way out to simply integrate other tasks intoMEDC17.

The MEDC17 configuration has also be changed and tasks have to be added, butthe toolchain can be left unmodified. The new task should contain one process, whichwill 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. Ifthe 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 AUTOSARtask 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 casesshould be designed in the same way as for the PC–OS. The errors should be figuredout by the SWCs itself. Since no output can be created, a variable can be used, whichwill be set if an error occurs. This variable can be observed with the debugger tofigure 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. Thishelps to determine if the runnables are really executed and to find errors.

During this work, the configuration of the used MEDC17 PST was extended tosupport the task Rte Task1 from figure 7.2. This task can be used in the describedway and an example is given in section 7.3.

For the integration in MEDC17 also a customized library has to be used. Thecustomization is not the focus of this work and therefor not described in detail. Inprinciple there are some operating system calls for accessing resources used. Thesehave to be substituted, because the used operating system resource does not existin MEDC17. Additionally, the include file “Os.h” is changed to “AutosarOs.h” toprevent a clash with the ERCOSEK includes. Everything, which is really needed forthe RTE is put into the file “AutosarOs.h”.

However, the file “AutosarOs.h” have also be used in the generated files. For thisreason the option “−−os−hdr” is desired from BOSCH for the RTE generators fromETAS, which changes the name of the include file “Os.h”.


The first example1, which should be considered, handles some basic mode functionalityand uses the test type “run RTA–OSEK5.0 for PC”. Modes are introduced in section2.4.5 and there is also a sequence described with figure 2.6, which have to be preservedfor a mode switch. This sequence should be tested with this case. In concrete thefollowing items are of interest:

• Mode dependent runnables shall only be executed, if the mode, on which theyare depend, is active.

• Runnables that are triggered by an OnExit event of the active mode shall notbe executed until all mode dependent runnables are finished.

• Runnables that are triggered by an OnExit or an OnEntry event shall be ex-ecuted in the correct order. This means that the runnables that are triggeredby OnExit events are executed before the runnables that are triggered by anOnEntry 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 twomodes “on” and “off”. SWC1 induces some mode switches to the other componentsand run11 is triggered by an DataReceivedEvent.

The runnables of SWC2 are both triggered by a timing event every 100ms. Theevent, which triggers the runnable run on, is disabled in mode “off” and the event,

1This example has number 0300 in the environment.

79


SWC1

run11

SWC2

run on run off

SWC3

on exit off entry off exit on entry

OnOffModeGroupVirtual Functional Bus

Task1Priority 3

Task2Priority 1

Task3Priority 1

direct access

DataReceived

Figure 7.3: VFB diagram for mode example

which triggers the runnable run off, is disabled in mode “on”. So that both runnablesare just active in one mode.

The runnables of SWC3 are triggered with OnExit and OnEntry events, accordingto their names. So e.g. the runnable on exit is triggered, if the mode “on” is exited. Incomparison with figure 2.6, the runnables of SWC2 are the mode dependent runnablesand SWC3 contains the OnExit and OnEntry runnables.

For a test typically the interesting situations or collisions are provoked. For thisexample it would be interesting to execute the runnables of SWC3 with a higherpriority than the runnables of SWC2. In this case, the runnables from SWC3 couldinterrupt the runnables run on and run off. This has to be prevented and for a modeswitch, the RTE generator has to create code, in which the triggering of the runnablesin SWC3 is delayed while run on or run off is active.

However, this combination is not allowed by the AUTOSAR specification. Insteadthe task, in which the runnables are executed with a ModeSwitchEvent, cannot have ahigher priority than any task, in which a mode dependent runnable is executed for thesame mode. This means for this example, that Task3 cannot have a higher prioritythan 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 anOnEntry event are mapped to a task before the runnables that are triggered by OnExitevents. 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. Theheader 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. Therunnable run11 is triggered with a DataReceivedEvent through the receiver port andit requests a mode switch at every call.

The variable mode switch indicated is set by the runnable run11 to show that amode switch was indicated. If this variable is set, no mode dependent runnable should

80


1 #include <stdio.h>#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;

10

FUNC(void, RTE APPL CODE) run11(void){

mode switch indicated = 1;

if (Rte Mode pport11 OnOffModePrototype() == RTE MODE OnOffModeGroup Off)Rte Switch pport11 OnOffModePrototype (RTE MODE OnOffModeGroup On);

elseRte 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 therunnables run on and run off, this variable is checked. Additionally, it has to be en-sured, that run11 cannot interrupt these runnables before this check. This is done withthe DataReceivedEvent, which can only occur at defined positions in the runnablesrun 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 reallyrequested. This is checked within these runnables and the variable is reset to use itfor 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 SWC3shall be started, because they are all triggered by a ModeSwitchEvent. This is alsochecked within these runnables.

The runnables of SWC3 use the variable current mode to provide the currentlyactive 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 runnableof SWC3 shall be executed and this updates this variable.

Again, there shall be no inconsistency for this variable, because only one of therunnables of SWC2 and SWC3 shall be active at a time. This assumption depend ona 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 countthe numbers of execution of run on and run off and to switch the mode at the fifthcall in every mode. This variables are reset if a mode is entered.

81



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 y

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;}

FUNC(void, RTE APPL CODE) run on(void){

runnable active = RUN ON;

if (mode switch indicated)printf ("ERROR mode switch was indicated, but a mode depending runnable is y

executed\n");30

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;40 }


82



FUNC(void, RTE APPL CODE) off entry(void){

if (runnable active != NO RUN)printf ("ERROR runnable off entry is executed, but mode dependent runnable y

is still active\n");

10 if (current mode != TEST MODE TRANSITION)printf ("ERROR runnable off entry is executed, but mode was not in y

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 y

is still active\n");

if (!mode switch indicated)printf ("ERROR runnable off exit executed without a mode switch y

indication\n");

if (current mode != TEST MODE OFF)printf ("ERROR runnable off exit is executed, but mode off was not y

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 }


83


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 twotasks for the runnables of SWC2 and SWC3, only one can be used for the runnablesof both components. This just requires another ECU specific configuration, thus thepart of the configuration, which is located in the “Ecu” directory of the resources. Thepart of the configuration, which is located in the resource directory “System”, can bereused.

If the runnables e.g. mapped to one task with the runnable to task mapping se-quence2

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 runnablerun on occurs, the following sequence3 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 thetask, which supports this execution and shall not execute off entry before on exit.This is obviously possible with an incorrect implementation and the used mappingsequence.

7.2.4 Conclusion

The mode example passes the test without an error. Nevertheless, by creating this testcase an error was found. The RTE generator from ETAS created a wrong identifier

2This is just the sequence in the task and not the sequence, in which the runnables are necessarilyexecuted. The execution can be prevented by some enclosing code like it is done with the timingevents in the example in section 2.8.

3Here 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 nameRTE MODE Off was created. This is no functional fault, but it prevents to compilethe 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.


A second example4 is a test case, which addresses the integration of AUTOSAR soft-ware in MEDC17. A test case is used, which does not only use TimingEvents fortriggering runnables, but also DataReceivedEvents, which are natively not used inMEDC17. This example does not really test some special behavior of the generatedcode. The aim is just get the DataReceivedEvents run in MEDC17.

7.3.1 Configuration of the MEDC17 Example

SWC1

run11 run12

SWC2

run21


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. Runnablerun11 is triggered by a timing event every 100ms and it is executed in the taskOS Drv 100ms Task. It sends a value through the port and triggers runnable run21with the DataReceivedEvent. The runnable run21 sends also a value and triggersrunnable run12. The priorities of the tasks are not of interest for this example, butthe sequence of the runnables run12 and run21 are of interest. Runnable run21 ismapped behind of run12 in the task Rte Task1. The aim is, that with the sent valuefrom 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 theoption “task–as–function” of the RTE generator. As described in section 7.1.4, theused 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 RTEgenerator created a call for ChainTask() at the end of the task. So a configuration wassearched, which explicitly forces the call of this function. It is expected that there areno problems, since this is just an operating system call.

4This example has number 0121 in the environment.

85


7.3.2 Implementation of the MEDC17 Example

The implementation of the components of this example is shown in the listings 7.5 and7.6. Runnable run11 counts a variable up to 50 and sends the current value throughthe sender port at every call. A global variable is set to indicate that a value wassent. The runnable run21 should be triggered with the sent data. It checks withthe 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 itwrites the received value to the sender port. The global variable data send pport21should indicate that really a value was sent through this port. This is checked bythe runnable run12, which is also triggered by DataReceivedEvent. The variableerror triggered without data rport21 is set, if runnable run12 is executed without sentdata.

1 #include <stdio.h>#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;

counter++;counter %=50;

15

data send pport11 = 1;

Rte Write pport11 intValue(counter);}

20


if (!data send pport21) {error triggered without data pport21 = 1;

}data send pport21 = 0;

Rte Read rport12 intValue(&received at rport12);30 }


So the variables received at rport12 and received at rport22 are set to the receivedvalues. These variables and the two variables that indicates an error should be watchedwith the debugger to ensure the correct functionality of this example.

86


1 #include <stdio.h>#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;

10


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

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) y$(TASK AS FUNCTION ENABLE)

The options are described in the following.

OS HDR AUTOSAR H This option effects, that the RTE generator uses theheader file “AutosarOs.h” instead of “Os.h” in the generated files. This option isdesired from BOSCH and available for the generators from ETAS.

ATOMIC ASSIGN TYPES This option specifies some data types as atomic. Sothe generator does not need to enclose an access to this data types with a lock in thegenerated code. In principle, this option is just used for performance reasons.

TASK AS FUNCTION ENABLE This option is described in section 7.1.4 andit is also desired from BOSCH for the generators from ETAS.

OS ERCOSEK This option addresses some special needs for ERCOSEK and is alsodesired from BOSCH for the ETAS RTE generators. It e.g. prevents the generatorfrom creating extended tasks. So, if it normally produces an extended task for a con-figuration, the RTE generator produces an error with this option, because ERCOSEKcannot handle extended tasks.

87


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 ) | | ( y

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 forthe function Rte Task Rte Task1 is shown in listing 7.7. The runnables are executedonly, if a DataReceivedEvent occurs. The function has to be added to the MEDC17task Rte Task1 as the only process. So the call of ChainTask (Rte Task1) at theend 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 itis expected by the RTE, is done without any side effect.

The auto built of MEDC17 succeeds and the resulting file can be downloaded to thecontrol unit. A debugging of the target results in the expected behavior. The variablesreceived 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. Theyshow exemplarily the problems coming up with the complexity of AUTOSAR. Thedescribed bugs are not explained in detail like the other examples.

One issue was already noted with the mode example, were the wrong API identifierswere created.

7.4.1 Implicit API buffers copied twice

The first issue that should be considered is an inefficient implementation for the im-plicit API. A runnable that accesses a port with a DataReadAccess can read the valuefrom the port multiple times during one execution and should every time get the sameresult. 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 tobe copied at the begin of the task for every runnable. If the same value is accessedfrom 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, y

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, ysizeof(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 codefor a task is shown in listing 7.8. There is one buffer used for every communicationand every buffer is copied at the begin of the task. However, two of the buffers arecopied twice, which takes not really an effect instead of being inefficient, especially forthe string, which is used in this example. Now the bug is fixed in an RTE generatorupdate.

7.4.2 DataReceivedEvent without DataReceivedEvent

This is a real bug, which causes wrong behavior for the execution and not just ineffi-ciency. 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. Thisimplies not that this data is really read from this port by the runnable. This have to beadditionally configured by a DataReceivePoint or a DataReadAccess. A configurationwith a runnable that is just triggered by a DataReceivedEvent but doesn’t read thevalue, was fed into the RTE generator. The resulting source code can be seen in listing

89


7.9. The source code for the task is created, but the runnable is not called there. Thisbug 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 testcase with a composition was also created and fed into the RTE generator. The wholetest case consists of four atomic software components. The components SWC3 andSWC4 are put into a composition. The components SWC1 and SWC2 communicatewith this composition.

The generated code contains the calls for the runnables of SWC3 and SWC4, butthe header files for this components are not created. Only header files for SWC1 andSWC2 were created.

This prevents from compiling the components, because in the header files are alsosome #define directives, which have to be used for the communication of the com-ponents.

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 AUTOSARmechanisms. Then two test cases are discussed in detail.

The mode example is executed with the OSEK–OS for PC operating system. Thiswas not possible before this work. So there is now a very good possibility to testAUTOSAR features without a control unit. Together with the found bugs, this seamsto be necessary to ensure the correct functionality first. Afterwards, a test at a controlunit can be considered.

The second example addresses a test at the control unit. It shows, how the in-tegration in MEDC17 can be done. The execution of only time triggered runnableswas possible with the option “−−task−as−function” from the RTE generator. Theintegration 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 wasimplemented to fulfill one part of this requirements. The others are achieved with thetest cases, which were created.

The environment supports creating and performing tests. They can be easily per-formed with another RTE generator and it can be performed in several ways. Morevariance, 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. Itwas integrated in the environment. This involves a great benefit for testing function-ality 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 demandedby the requirements are considered with tests. So for example testing the resourceconsumption, 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 theevaluation and this work.

8.2 Perspective

There are some ideas to extend the environment for further usage. From ETAS is aPC operating system announced, which is compliant to AUTOSAR release 3.0. Thisoperating system may be integrated with another test type in the environment.

If an RTE generator is available for the AUTOSAR release 3.0, the environmentshould 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 generatorat a time and there was no need to update the tests for older versions. So there wasno need for this feature. However, it is an extension, which may be added to theenvironment.

Another feature, which may be added is an import and export function for thetest 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 animported resource does not overwrite an existing one.

8.3 Impressions

The upcoming AUTOSAR standard specifies a lot of features and mechanisms andthere are a lot of car manufactures involved in creating this standard. It seams thatAUTOSAR is a superset of the mechanisms that all car manufactures use and thisleads to a huge complexity. Normally it is just necessary to support the mechanismused in the own software. Now it becomes necessary to support all mechanism ofAUTOSAR to provide software sharing.

With the found bugs of the RTE generators it can be seen that it is hard to handleso much combination possibilities. Maybe an approach, which defines less featuresand 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 goodway.

92

Appendix A

Example

This is the whole configuration of the example from section 2.8, but it does not providethe ECU configuration, which have to be also provided create the RTE. But the fileshows the complexity of the XML configuration for such a simple example. With theextract of the configuration given in section 2.8 it additionally shows in which way theconfiguration can be put in one file.

1 <?xml version="1.0" encoding="UTF-8"?><AUTOSAR xmlns="http://autosar.org/2.1.2"><TOP-LEVEL-PACKAGES>

<AR-PACKAGE><SHORT-NAME>types</SHORT-NAME><ELEMENTS>

<INTEGER-TYPE><SHORT-NAME>Int16</SHORT-NAME><LOWER-LIMIT INTERVAL-TYPE="CLOSED">-32768</LOWER-LIMIT>

10 <UPPER-LIMIT INTERVAL-TYPE="CLOSED">32767</UPPER-LIMIT></INTEGER-TYPE><STRING-TYPE><SHORT-NAME>String8</SHORT-NAME><ENCODING>utf8</ENCODING><MAX-NUMBER-OF-CHARS>8</MAX-NUMBER-OF-CHARS>

</STRING-TYPE></ELEMENTS>

</AR-PACKAGE><AR-PACKAGE>

20 <SHORT-NAME>interfaces</SHORT-NAME><ELEMENTS>

<SENDER-RECEIVER-INTERFACE><SHORT-NAME>SR Int16</SHORT-NAME><IS-SERVICE>false</IS-SERVICE><DATA-ELEMENTS><DATA-ELEMENT-PROTOTYPE>


30 </DATA-ELEMENT-PROTOTYPE><DATA-ELEMENT-PROTOTYPE>


</DATA-ELEMENT-PROTOTYPE></DATA-ELEMENTS>

</SENDER-RECEIVER-INTERFACE><CLIENT-SERVER-INTERFACE><SHORT-NAME>CS string to int</SHORT-NAME>

40 <IS-SERVICE>false</IS-SERVICE><OPERATIONS><OPERATION-PROTOTYPE>

<SHORT-NAME>parse</SHORT-NAME><ARGUMENTS><ARGUMENT-PROTOTYPE>

<SHORT-NAME>string</SHORT-NAME><TYPE-TREF DEST="ARRAY-TYPE">/types/String8</TYPE-TREF><DIRECTION>IN</DIRECTION>

</ARGUMENT-PROTOTYPE>50 <ARGUMENT-PROTOTYPE>

<SHORT-NAME>value</SHORT-NAME><TYPE-TREF DEST="INTEGER-TYPE">/types/Int16</TYPE-TREF><DIRECTION>OUT</DIRECTION>

</ARGUMENT-PROTOTYPE></ARGUMENTS><POSSIBLE-ERROR-REFS>

93

Appendix A Example

<POSSIBLE-ERROR-REF DEST="APPLICATION-ERROR">/interfaces/CS string to int/overflow

</POSSIBLE-ERROR-REF>60 <POSSIBLE-ERROR-REF DEST="APPLICATION-ERROR">

/interfaces/CS string to int/underflow</POSSIBLE-ERROR-REF>

</POSSIBLE-ERROR-REFS></OPERATION-PROTOTYPE>

</OPERATIONS><POSSIBLE-ERRORS>

<APPLICATION-ERROR><SHORT-NAME>overflow</SHORT-NAME><ERROR-CODE>42</ERROR-CODE>

70 </APPLICATION-ERROR><APPLICATION-ERROR>

<SHORT-NAME>underflow</SHORT-NAME><ERROR-CODE>43</ERROR-CODE>

</APPLICATION-ERROR></POSSIBLE-ERRORS>

</CLIENT-SERVER-INTERFACE></ELEMENTS>


80 <SHORT-NAME>swc root</SHORT-NAME><ELEMENTS>

<ATOMIC-SOFTWARE-COMPONENT-TYPE><SHORT-NAME>swc1</SHORT-NAME><PORTS>

<P-PORT-PROTOTYPE><SHORT-NAME>pport1</SHORT-NAME><PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">

/interfaces/SR Int16</PROVIDED-INTERFACE-TREF>

90 </P-PORT-PROTOTYPE><R-PORT-PROTOTYPE>

<SHORT-NAME>rport1</SHORT-NAME><REQUIRED-INTERFACE-TREF DEST="CLIENT-SERVER-INTERFACE">

/interfaces/CS string to int</REQUIRED-INTERFACE-TREF>

</R-PORT-PROTOTYPE></PORTS>

</ATOMIC-SOFTWARE-COMPONENT-TYPE><ATOMIC-SOFTWARE-COMPONENT-TYPE>

100 <SHORT-NAME>swc2</SHORT-NAME><PORTS>

<P-PORT-PROTOTYPE><SHORT-NAME>pport1</SHORT-NAME><PROVIDED-INTERFACE-TREF DEST="CLIENT-SERVER-INTERFACE">

/interfaces/CS string to int</PROVIDED-INTERFACE-TREF>

</P-PORT-PROTOTYPE><R-PORT-PROTOTYPE>

<SHORT-NAME>rport1</SHORT-NAME>110 <REQUIRED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">

/interfaces/SR Int16</REQUIRED-INTERFACE-TREF>

</R-PORT-PROTOTYPE></PORTS>

</ATOMIC-SOFTWARE-COMPONENT-TYPE><INTERNAL-BEHAVIOR><SHORT-NAME>intBehSwc1</SHORT-NAME><COMPONENT-REF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc1</COMPONENT-REF><EVENTS>

120 <TIMING-EVENT><SHORT-NAME>Time100ms</SHORT-NAME><START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intBehSwc1/run11</START-ON-EVENT-REF><PERIOD>0.1</PERIOD>

</TIMING-EVENT><TIMING-EVENT>


</TIMING-EVENT>130 </EVENTS>

<RUNNABLES><RUNNABLE-ENTITY>

<SHORT-NAME>run11</SHORT-NAME><CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY><DATA-SEND-POINTS><DATA-SEND-POINT>

<SHORT-NAME>dwa1</SHORT-NAME><DATA-ELEMENT-IREF><P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF>

140 <DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">

94


</DATA-ELEMENT-IREF></DATA-SEND-POINT><DATA-SEND-POINT>


<P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF><DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">

150 /interfaces/SR Int16/intValue2</DATA-ELEMENT-PROTOTYPE-REF>

</DATA-ELEMENT-IREF></DATA-SEND-POINT>

</DATA-SEND-POINTS><SYMBOL>run11</SYMBOL>


<SHORT-NAME>run12</SHORT-NAME><CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY>

160 <DATA-SEND-POINTS><DATA-SEND-POINT>


<P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF><DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">


</DATA-ELEMENT-IREF></DATA-SEND-POINT>

170 </DATA-SEND-POINTS><SERVER-CALL-POINTS><SYNCHRONOUS-SERVER-CALL-POINT>

<SHORT-NAME>sscp</SHORT-NAME><OPERATION-IREFS>

<OPERATION-IREF><R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">

/swc root/swc1/rport1</R-PORT-PROTOTYPE-REF><OPERATION-PROTOTYPE-REF DEST="OPERATION-PROTOTYPE">

180 /interfaces/CS string to int/parse</OPERATION-PROTOTYPE-REF>

</OPERATION-IREF></OPERATION-IREFS>

</SYNCHRONOUS-SERVER-CALL-POINT></SERVER-CALL-POINTS><SYMBOL>run12</SYMBOL>

</RUNNABLE-ENTITY></RUNNABLES><SUPPORTS-MULTIPLE-INSTANTIATION>false</SUPPORTS-MULTIPLE-INSTANTIATION>

190 </INTERNAL-BEHAVIOR><INTERNAL-BEHAVIOR><SHORT-NAME>intBehSwc2</SHORT-NAME><COMPONENT-REF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc2</COMPONENT-REF><EVENTS><TIMING-EVENT>


</TIMING-EVENT>200 <OPERATION-INVOKED-EVENT>

<SHORT-NAME>operationInvoke</SHORT-NAME><START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intBehSwc2/run21</START-ON-EVENT-REF><OPERATION-IREF><P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc2/pport1</P-PORT-PROTOTYPE-REF><OPERATION-PROTOTYPE-REF DEST="OPERATION-PROTOTYPE">

/interfaces/CS string to int/parse</OPERATION-PROTOTYPE-REF>

</OPERATION-IREF></OPERATION-INVOKED-EVENT>

210 </EVENTS><RUNNABLES><RUNNABLE-ENTITY>

<SHORT-NAME>run21</SHORT-NAME><CAN-BE-INVOKED-CONCURRENTLY>true</CAN-BE-INVOKED-CONCURRENTLY><SYMBOL>run21</SYMBOL>


<SHORT-NAME>run22</SHORT-NAME><CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY>

220 <DATA-RECEIVE-POINTS><DATA-RECEIVE-POINT>

<SHORT-NAME>dra1</SHORT-NAME><DATA-ELEMENT-IREF>

<R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc2/rport1</R-PORT-PROTOTYPE-REF>

95

Appendix A Example

<DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">/interfaces/SR Int16/intValue1

</DATA-ELEMENT-PROTOTYPE-REF></DATA-ELEMENT-IREF>

</DATA-RECEIVE-POINT>230 <DATA-RECEIVE-POINT>

<SHORT-NAME>dra2</SHORT-NAME><DATA-ELEMENT-IREF><R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc2/rport1</R-PORT-PROTOTYPE-REF><DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE">


</DATA-ELEMENT-IREF></DATA-RECEIVE-POINT>

</DATA-RECEIVE-POINTS>240 <SYMBOL>run22</SYMBOL>

</RUNNABLE-ENTITY></RUNNABLES><SUPPORTS-MULTIPLE-INSTANTIATION>false</SUPPORTS-MULTIPLE-INSTANTIATION>

</INTERNAL-BEHAVIOR><IMPLEMENTATION><SHORT-NAME>implSwc1</SHORT-NAME><BEHAVIOR-REF DEST="INTERNAL-BEHAVIOR">/swc root/intBehSwc1</BEHAVIOR-REF><CODE-DESCRIPTOR>

<SHORT-NAME>src</SHORT-NAME>250 <TYPE>SRC</TYPE>

</CODE-DESCRIPTOR><PROGRAMMING-LANGUAGE>C</PROGRAMMING-LANGUAGE>

</IMPLEMENTATION><IMPLEMENTATION><SHORT-NAME>implSwc2</SHORT-NAME><BEHAVIOR-REF DEST="INTERNAL-BEHAVIOR">/swc root/intBehSwc2</BEHAVIOR-REF><CODE-DESCRIPTOR>

<SHORT-NAME>src</SHORT-NAME><TYPE>SRC</TYPE>

260 </CODE-DESCRIPTOR><PROGRAMMING-LANGUAGE>C</PROGRAMMING-LANGUAGE>

</IMPLEMENTATION></ELEMENTS>


<SHORT-NAME>comp root</SHORT-NAME><ELEMENTS>

<COMPOSITION-TYPE><SHORT-NAME>comp</SHORT-NAME>

270 <PORTS /><COMPONENTS>

<COMPONENT-PROTOTYPE><SHORT-NAME>swc1</SHORT-NAME><TYPE-TREF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc1</TYPE-TREF>

</COMPONENT-PROTOTYPE><COMPONENT-PROTOTYPE>

<SHORT-NAME>swc2</SHORT-NAME><TYPE-TREF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc2</TYPE-TREF>

</COMPONENT-PROTOTYPE>280 </COMPONENTS>

<CONNECTORS><ASSEMBLY-CONNECTOR-PROTOTYPE>

<SHORT-NAME>ac1 swc1pport1swc2rport1</SHORT-NAME><PROVIDER-IREF><COMPONENT-PROTOTYPE-REF y

DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc1</COMPONENT-PROTOTYPE-REF><P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</P-PORT-PROTOTYPE-REF>

</PROVIDER-IREF><REQUESTER-IREF><COMPONENT-PROTOTYPE-REF y

DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc2</COMPONENT-PROTOTYPE-REF>290 <R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc2/rport1</R-PORT-PROTOTYPE-REF>

</REQUESTER-IREF></ASSEMBLY-CONNECTOR-PROTOTYPE><ASSEMBLY-CONNECTOR-PROTOTYPE>

<SHORT-NAME>ac2 swc2pport1swc1rport1</SHORT-NAME><PROVIDER-IREF><COMPONENT-PROTOTYPE-REF y

DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc2</COMPONENT-PROTOTYPE-REF><P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc2/pport1</P-PORT-PROTOTYPE-REF>

</PROVIDER-IREF><REQUESTER-IREF>

300 <COMPONENT-PROTOTYPE-REF yDEST="COMPONENT-PROTOTYPE">/comp root/comp/swc1</COMPONENT-PROTOTYPE-REF>

<R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc1/rport1</R-PORT-PROTOTYPE-REF></REQUESTER-IREF>

</ASSEMBLY-CONNECTOR-PROTOTYPE></CONNECTORS>

96

</COMPOSITION-TYPE></ELEMENTS>


<SHORT-NAME>system root</SHORT-NAME>310 <ELEMENTS>

<SYSTEM-TOPOLOGY-TYPE><SHORT-NAME>system topology</SHORT-NAME><COMMUNICATION-CLUSTERS /><TOPOLOGY-ELEMENTS><ECU-INSTANCE>

<SHORT-NAME>ecu</SHORT-NAME><COMM-PORTS /><ECU-TREF DEST="ECU">/ecu root/ecu</ECU-TREF><POWER-SUPPLY>BATTERY</POWER-SUPPLY>

320 <PROCESSING-UNIT-ENDIANNESS>MOST-SIGNIFICANT-BYTE-LAST</PROCESSING-UNIT-ENDIANNESS></ECU-INSTANCE>

</TOPOLOGY-ELEMENTS></SYSTEM-TOPOLOGY-TYPE><SYSTEM><SHORT-NAME>system</SHORT-NAME><COMMUNICATION><COMMUNICATION-MATRIXS />

</COMMUNICATION><MAPPING>

330 <SHORT-NAME>sys mapping</SHORT-NAME><DATA-MAPPINGS /><SW-MAPPINGS>

<SW-COMP-TO-ECU-MAPPING><SHORT-NAME>ecu instance</SHORT-NAME><COMPONENT-IREFS>

<COMPONENT-IREF><SOFTWARE-COMPOSITION-REF DEST="SOFTWARE-COMPOSITION">

/system root/system/comp instance</SOFTWARE-COMPOSITION-REF>

340 <TARGET-COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc1

</TARGET-COMPONENT-PROTOTYPE-REF></COMPONENT-IREF><COMPONENT-IREF>

<SOFTWARE-COMPOSITION-REF DEST="SOFTWARE-COMPOSITION">/system root/system/comp instance

</SOFTWARE-COMPOSITION-REF><TARGET-COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE">

/comp root/comp/swc2350 </TARGET-COMPONENT-PROTOTYPE-REF>

</COMPONENT-IREF></COMPONENT-IREFS><ECU-INSTANCE-IREF>

<SYSTEM-TOPOLOGY-INSTANCE-REF DEST="SYSTEM-TOPOLOGY-INSTANCE">/system root/system/system topology instance

</SYSTEM-TOPOLOGY-INSTANCE-REF><ECU-INSTANCE-REF DEST="ECU-INSTANCE">/system root/system topology/ecu</ECU-INSTANCE-REF>

</ECU-INSTANCE-IREF></SW-COMP-TO-ECU-MAPPING>

360 </SW-MAPPINGS></MAPPING><SOFTWARE-COMPOSITION><SHORT-NAME>comp instance</SHORT-NAME><SOFTWARE-COMPOSITION-TREF DEST="COMPOSITION-TYPE">/comp root/comp</SOFTWARE-COMPOSITION-TREF>

</SOFTWARE-COMPOSITION><TOPOLOGY><SHORT-NAME>system topology instance</SHORT-NAME><TOPOLOGY-TREF DEST="SYSTEM-TOPOLOGY-TYPE">/system root/system topology</TOPOLOGY-TREF>

</TOPOLOGY>370 </SYSTEM>

</ELEMENTS></AR-PACKAGE><AR-PACKAGE>

<SHORT-NAME>ecu root</SHORT-NAME><ELEMENTS>

<ECU><SHORT-NAME>ecu</SHORT-NAME><ECU-ABSTRACTION-REF DEST="COMPOSITION-TYPE">/comp root/comp</ECU-ABSTRACTION-REF>

</ECU>380 </ELEMENTS>


</AUTOSAR>

97

Appendix A Example

98

Appendix B

Requirements of the FunctionalSpecification

B.1 Main Requirements

REQ000 concrete proceeding for the useThe user shall have a concrete guidance to evaluate an RTE generator.

REQ010 perform evaluation of at least one RTE generatorWith the evaluation environment at least one RTE generator shall be tested andevaluated. The whole process should be documented.

B.2 User Interface

REQ100 simple user interfaceThe 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 itis harder to maintain a graphical solution. So a script based environment should be abetter solution. If there should be time left, this point can be reconsidered.

REQ110 perform tests for special RTE generatorsIt shall be possible to choose the RTE generator for which the tests shall be performed.

REQ120 perform multiple tests at onceTo start every test at its own isn’t very effizient. If possible, some tests shall beperformed at once for the same RTE generator.

REQ130 assistance for tests with human interactionFor some tests user interaction might be required. In this case the test suite shouldassist the user as good as possible. E.g. the test suite points out the source codepassage 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 generatorsfrom 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 simpleIt 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 couldbe a good agreement. Using a database instead, prevents the easy access for theuser. The user shall have the possibility to look at the tests, modify them orcreate 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 RTEgenerator 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 withoutperforming the tests again. This especially makes sense for tests which areperformed with human interaction.

REQ204 user can modify tests

The user must have the possibility to change the tests. So he or she can adjusttests 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 releasesA new release includes new features and maybe some old features are disposed. Sonot every test runs with every RTE generator or is conform with every release. So itmakes no sense to test such a combination.

REQ220 allow special test cases for special RTE generator versionsIt 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 concretetest case can belong to one or more of these types and maybe such types can dependon 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 caseswould be performed in the same way (feeding the RTE generator with the files andexpecting an error). The test suite has to provide some types of tests. In principle itdoesn’t take much work to add a new test case, but changing the test suite to provideanother test type takes more effort. So the test environment should provide a goodbase of types for testing the RTE generator.

REQ300 provide good base of test typesIn the following are some test types listed, which should be supported by the testenvironment.

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 systemdoesn’t provide extended tasks (see REQ305). So the RTE generator shouldreject configurations, which directly describes extended tasks, when it is calledwith 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 keeptrack about success.

REQ303 test functionality

The functionality of the generated code should be the functionality, which isspecified in the configuration files. This means, if e.g. in the configuration anindirect API is specified, than the generated code has to contain the indirectAPI and vice versa. To provide and execute this test, maybe a user interactionis 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. Es-pecially here, some cases with basic functionality can be created. It ensures,that this functionality is provided from the RTE-generator. This tests can beperformed automatically.

REQ305 test behavior with MEDC17

The generated code can be (hopefully) integrated and compiled with the Boschenvironment MEDC17 and than run on a control unit. It is estimated, that thesetests have to be done with human interaction. Here is the observation of somesignals by the user supposable.

101


REQ306 test resource consumption

One main aspect for embedded software are the needed resources. For autogen-erated 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 fewrepresentative 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 develop-ment that differ from the AUTOSAR specification. The integration of the RTEcode within the Bosch environment has to be tested.

REQ310 dependencies between testsMost of this tests have to be performed one after another. E.g. after creating theRTE (If the RTE is created, than the RTE generator accepted the configuration), thecode can be compiled for RTA-OSEK for PC or for MEDC17. On the other hand, nocode can be compiled, if none is created from the RTE generator. The tests can beperformed in the following chain:

configuration

rejectconfiguration

acceptconfiguration

compile withMED17

run on control unit

compare resources

compile withRTA-OSEK for PC

run on PC

Note, that the code has to be compiled for the target, at which the next test willbe performed. Additionally, a proceeding after RTE generation only makes sense, ifthe test case should be accepted from the RTE generator. A test configuration, whichshould be rejected, shouldn’t be compiled.

102

B.4 Provided Tests

REQ320 concrete test cases for every typeThe initial environment should include some test cases, which cover the current usedfunctionality of the RTE generator.

103


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 supportingmulti-paradigm views. In Computational Science and Its Applications – ICCSA2008, 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: trendsand challenges. In S.L. Min and W. Yi, editors, International Conference onEmbedded Software (EMSOFT), page 1, Seoul, Korea, 2006. ACM.

[12] ISO 11898. Road vehicles – Controller area network (CAN). International Orga-nization for Standardization (ISO), Genevan, Switzerland, 1 edition, 2006.

[13] ISO 17356-1. Road vehicles – Open interface for embedded automotive applica-tions – Part 1: General structure and terms, definitions and abbreviated terms.International Organization for Standardization (ISO), Genevan, Switzerland, 1edition, 2005.

[14] ISO 17356-3. Road vehicles – Open interface for embedded automotive applications– Part 3: OSEK/VDX Operating System (OS). International Organization forStandardization (ISO), Genevan, Switzerland, 1 edition, 2005.

[15] ISO 17356-6. Road vehicles – Open interface for embedded automotive appli-cations – Part 6: OSEK/VDX Implementation Language (OIL). InternationalOrganization 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 Con-rad, and Ines Fey. Model-based testing of embedded automotive software usingmtest. Detroit, US, 2004. SAE World Congress.

[18] Jongbae Moon, Donggyu Kwak, Yongyun Cho, Sangjoon Park, and JongchanLee. A xml script-based testing tool for embedded softwares. In ComputationalScience and Its Applications – ICCSA 2007, volume 4706/2007 of Lecture Notesin 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 Sturmer. Systematic Testing of Code Generation Tools - A Testsuite-Orientated Approach for Safeguarding Model-Based Code Generation. PhD thesis,Pro Business, 2006.

[25] Ingo Sturmer and Mirko Conrad. Test suite design for code generation tools. InASE, pages 286–290. IEEE Computer Society, 2003.

[26] Ingo Sturmer, Mirko Conrad, Heiko Dorr, and Peter Pepper. Systematic testingof 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.

evaluation environment for autosar-autocode in motor control units

Documents