Evaluation Environment for AUTOSAR Autocode in Motor Control Units

Transcription

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

2

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

4

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

6

7 Contents 1 Introduction Motivation Related Work Outline AUTOSAR Architecture AUTOSAR Software Basic Software AUTOSAR basic approach AUTOSAR Operating System Tasks Events Resources Basic Concepts Types Ports Software Components Internal Behavior Modes Virtual Functional Bus Configuration Files Runtime Environment Example Configuration of the Example The Generated Source Code Implementing the Runnables Conclusion of the Example Summary MEDC ERCOSEK Basic Software and Application Software Communication Tasks and Processes Summary vii

8 Contents 4 Goals Background of the Topic Differences of MEDC17 and AUTOSAR Integration of AUTOSAR Software in MEDC Development of RTE Generators Current Situation (before Diploma Thesis) Topic of the Diploma Thesis Main Task Requirements Available Resources and Tools Summary Analysis and Design Test Data Flow Components of the Environment RTE Generator Options RTE Library Resource Test Type Variables Test Template Test Configuration of the Components Structure of the File System The Directory pool Resource Directory Configuration Directory The Directory perform and Test Directories Summary Implementation of the Test Environment Design Decisions Graphical User Interface Java and SWT XML Files for Storing the Configurations Perl for Tests The Graphical User Interface RTE Generator Configuration View Test Template Configuration View Perform View Implementation of the GUI with Java Logging for the Application Basic Data Structures viii

9 Contents Perform Main Window Configuration Widgets Perform Widgets Implementing Tests with Perl Utilities for Test Scripts Scripts for the Test Types XML Scheme Launching the Test Environment Summary Test Cases Creating Test Cases Tests to Accept or Reject Code Review of Tests Tests for the PC OS Tests for Integration in MEDC Example: Mode Test Configuration of the Mode Example Implementation of the Mode Example Modification of this Example Conclusion Example: DataReceivedEvent in MEDC Configuration of the MEDC17 Example Implementation of the MEDC17 Example Execution Found RTE Generator Bugs Implicit API buffers copied twice DataReceivedEvent without DataReceivedEvent Header Files for Composition not created Summary Conclusion Reached Goals Perspective Impressions A Example 93 B Requirements of the Functional Specification 99 B.1 Main Requirements B.2 User Interface B.3 Layout and Organization B.4 Provided Tests ix

10 Contents Abbreviations 105 Bibliography 107 x

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28 Chapter 2 AUTOSAR 1 <?xml version="1.0" encoding="utf-8"?> <AUTOSAR xmlns=" <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 1 <?xml version="1.0" encoding="utf-8"?> <AUTOSAR xmlns=" <TOP-LEVEL-PACKAGES> <AR-PACKAGE> <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> <SHORT-NAME>intValue2</SHORT-NAME> <TYPE-TREF DEST="INTEGER-TYPE">/types/Int16</TYPE-TREF> <IS-QUEUED>false</IS-QUEUED> 20 </DATA-ELEMENT-PROTOTYPE> </DATA-ELEMENTS> </SENDER-RECEIVER-INTERFACE> </ELEMENTS> </AR-PACKAGE> </TOP-LEVEL-PACKAGES> </AUTOSAR> Listing 2.2: Example description of port interfaces 18

29 2.8 Example them types or interfaces. Additionally, it is not needed to have different names for these packages. 1 <?xml version="1.0" encoding="utf-8"?> <AUTOSAR xmlns=" <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 DEST="SENDER-RECEIVER-INTERFACE">/interfaces/SR Int16</PROVIDED-INTERFACE-TREF> </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> 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 two ports of SWC1 specified. Listing 2.4 shows the internal behavior of SWC1. There are the runnables and the ports, which are accessed by the runnables, described. This is needed to generate the API and to provide consistency for the communication. The access is specified with DataSendPoints and a SynchronousServerCallPoint. Runnable run11 writes both values to the sender port pport11, whereas run12 only writes the value intvalue1. The runnables are triggered by the specified timing events. One runnable can be triggered by more than one event, but this case is not shown here. At this point it can be seen that every part is very flexible handled with references. It is also permitted to have more than one internal behavior for one Software Component specified, but just one can be used. This is done by the instantiation of the SWC, which is part of the system description and not shown here. So it is e.g. possible to reuse a definition of a Software Component and reuse it with different internal behaviors. As also can be seen in the configuration, it is possible for an internal behavior to support multiple instantiation, which should also not be considered here, because it does not contribute to the understanding and would just complicate the example The Generated Source Code After calling the RTE generator with that configuration, it should produce the auto generated part of the RTE. This part contains the API for the SWCs. The interesting extract for SWC1 is shown in listing 2.5. In the last two lines the functions for the runnables are declared. These functions are called when a runnable is executed. This means for this example that the functions are called when the timing events occur. So 19

30 Chapter 2 AUTOSAR 1 <?xml version="1.0" encoding="utf-8"?> <AUTOSAR xmlns=" <TOP-LEVEL-PACKAGES> <AR-PACKAGE> <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> <SHORT-NAME>Time50ms</SHORT-NAME> <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intbehswc1/run12</start-on-event-ref> <PERIOD>0.05</PERIOD> 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"> /interfaces/sr Int16/intValue1 </DATA-ELEMENT-PROTOTYPE-REF> </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

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

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

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

34 Chapter 2 AUTOSAR 24

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

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

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

38 Chapter 3 MEDC17 28

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

54 Chapter 5 Analysis and Design directory and the tests are stored and performed in a test directory. RTE libraries are also stored in directories, which have the same form as the resource directories, but they are not part of the environment itself. Instead they are stored anywhere else in the file system, because they are also used for other purpose. The content of these directories is described later. The file configuration.xml contains global preferences for the whole environment. The files RteEvaluation.jar, RteEvaluation.bat and swt.jar are part of the implementation and described in section 6.6. root pool Autosar Release 2.0 resources Ecu 0010 Ecu Ecu 2... nnnn Ecu n global types interfaces types System 0010 System System 2... mmmm System m rte generators generator name 1 version 1... generator name o version o test templates 0010 template name 1... pppp template name p Autosar Release perform Autosar Release 2.0 generator name 1 version template name 1... pppp template name p... generator name o version o... Autosar Release types name 1... name q configuration.xml RteEvaluation.bat RteEvaluation.jar swt.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 a subdirectory of the directory types. The name of the subdirectory is the name of the test type. Everything which is needed to configure the tests is stored in the directory pool and the tests itself are stored and performed in the directory perform The Directory pool The directory pool stores everything, which is needed to configure the tests. It is first divided by the AUTOSAR releases. Inside of a release directory the RTE generators, test templates and resources, which belong to this release, are stored. A configuration for an RTE generator is stored in a subdirectory of rte generators. This subdirectory is named with the name and version of the generator. Test templates 44

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

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

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

58 Chapter 5 Analysis and Design 48

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

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

61 6.2 The Graphical User Interface Figure 6.2: RTE generator configuration view 51

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

63 6.2 The Graphical User Interface Figure 6.3: Test template configuration view 53

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

65 6.2 The Graphical User Interface Figure 6.4: Perform view 55