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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

82 Chapter 6 Implementation of the Test Environment 1 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" <xs:simpletype name="four-digit-number"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{4}" /> </xs:restriction> </xs:simpletype> 10 <xs:simpletype name="non-empty-string"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:complextype name="variable"> <xs:all> <xs:element name="name" type="xs:string" /> <xs:element name="value" type="xs:string" /> 20 </xs:all> </xs:complextype> <xs:complextype name="resource"> <xs:sequence> <xs:element name="path" type="xs:string" /> </xs:sequence> </xs:complextype> <!-- the root element --> 30 <xs:element name="definitions"> <xs:complextype> <xs:all> <!-- basic properties --> <xs:element name="name" type="non-empty-string" /> <xs:element name="number" type="four-digit-number" /> <xs:element name="description" type="xs:string" minoccurs="0" /> <xs:element name="test-type" type="xs:string" minoccurs="0" /> <xs:element name="rte-library-to-use" type="xs:string" /> 40 <xs:element name="rte-options" type="xs:string" minoccurs="0" /> 50 <!-- a list of variables --> <xs:element name="variables" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="variable" type="variable" maxoccurs="unbounded" minoccurs="0"></xs:element> </xs:sequence> </xs:complextype> </xs:element> <!-- the resources to use --> <xs:element name="resources" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="resource" type="resource" maxoccurs="unbounded" minoccurs="0"></xs:element> </xs:sequence> </xs:complextype> </xs:element> 60 </xs:all> </xs:complextype> </xs:element> </xs:schema> Listing 6.2: XML scheme for the test templates 72

83 6.7 Summary 1 <?xml version="1.0" encoding="utf-8"?> <definitions> <name>mode Test</name> <number>0300</number> <test-type>run RTA-OSEK5.0 for PC</test-type> <variables> <variable> <name>ecu AUTOSAR PATH</name> <value>/system root/system/system topology instance /ecu</value> 10 </variable> <variable> <name>ecu NAME</name> <value>ecu</value> </variable> </variables> <resources> <resource> <path>ecu/0300 mode test</path> </resource> 20 <resource> <path>global configs/interfaces</path> </resource> <resource> <path>global configs/types</path> </resource> <resource> <path>system/0300 mode test</path> </resource> </resources> 30 <description/> <rte-library-to-use>original</rte-library-to-use> <rte-options>$(atomic ASSIGN TYPES)</rte-options> </definitions> Listing 6.3: XML example for a test template section 6.3 and the XML schemes described in section 6.5. The SWT library for the GUI is not contained in this file. It is located in the file swt.jar in the same directory. The environment have to be started with the command java j a r RteEvaluation. j a r and the file swt.jar has to be in the same directory. Normally this call is done automatically by the operating system, if a file with the extension.jar is started. If not, the file RteEvaluation.bat provides the same call. 6.7 Summary In this chapter first some implementation decisions are addressed. Afterwards some screenshots of the GUI are shown and explained. Then an overview of the implementation of the GUI is given. Some class diagrams show a first introduction to the source code and these should be the first destination for extending the application. Then an introduction of the Perl files is given and it is shown, how the test types are implemented. The XML scheme for storing the configurations is explained and it is also described, how the application can be started. 73

84 Chapter 6 Implementation of the Test Environment 74

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

103 Appendix A Example This is the whole configuration of the example from section 2.8, but it does not provide the ECU configuration, which have to be also provided create the RTE. But the file shows the complexity of the XML configuration for such a simple example. With the extract of the configuration given in section 2.8 it additionally shows in which way the configuration can be put in one file. 1 <?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> <AR-PACKAGE> 20 <SHORT-NAME>interfaces</SHORT-NAME> <ELEMENTS> <SENDER-RECEIVER-INTERFACE> <SHORT-NAME>SR Int16</SHORT-NAME> <IS-SERVICE>false</IS-SERVICE> <DATA-ELEMENTS> <DATA-ELEMENT-PROTOTYPE> <SHORT-NAME>intValue1</SHORT-NAME> <TYPE-TREF DEST="INTEGER-TYPE">/types/Int16</TYPE-TREF> <IS-QUEUED>false</IS-QUEUED> 30 </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> </DATA-ELEMENT-PROTOTYPE> </DATA-ELEMENTS> </SENDER-RECEIVER-INTERFACE> <CLIENT-SERVER-INTERFACE> <SHORT-NAME>CS string to int</short-name> 40 <IS-SERVICE>false</IS-SERVICE> <OPERATIONS> <OPERATION-PROTOTYPE> <SHORT-NAME>parse</SHORT-NAME> <ARGUMENTS> <ARGUMENT-PROTOTYPE> <SHORT-NAME>string</SHORT-NAME> <TYPE-TREF DEST="ARRAY-TYPE">/types/String8</TYPE-TREF> <DIRECTION>IN</DIRECTION> </ARGUMENT-PROTOTYPE> 50 <ARGUMENT-PROTOTYPE> <SHORT-NAME>value</SHORT-NAME> <TYPE-TREF DEST="INTEGER-TYPE">/types/Int16</TYPE-TREF> <DIRECTION>OUT</DIRECTION> </ARGUMENT-PROTOTYPE> </ARGUMENTS> <POSSIBLE-ERROR-REFS> 93

104 Appendix A Example <POSSIBLE-ERROR-REF DEST="APPLICATION-ERROR"> /interfaces/cs string to int/overflow </POSSIBLE-ERROR-REF> 60 <POSSIBLE-ERROR-REF DEST="APPLICATION-ERROR"> /interfaces/cs string to int/underflow </POSSIBLE-ERROR-REF> </POSSIBLE-ERROR-REFS> </OPERATION-PROTOTYPE> </OPERATIONS> <POSSIBLE-ERRORS> <APPLICATION-ERROR> <SHORT-NAME>overflow</SHORT-NAME> <ERROR-CODE>42</ERROR-CODE> 70 </APPLICATION-ERROR> <APPLICATION-ERROR> <SHORT-NAME>underflow</SHORT-NAME> <ERROR-CODE>43</ERROR-CODE> </APPLICATION-ERROR> </POSSIBLE-ERRORS> </CLIENT-SERVER-INTERFACE> </ELEMENTS> </AR-PACKAGE> <AR-PACKAGE> 80 <SHORT-NAME>swc root</short-name> <ELEMENTS> <ATOMIC-SOFTWARE-COMPONENT-TYPE> <SHORT-NAME>swc1</SHORT-NAME> <PORTS> <P-PORT-PROTOTYPE> <SHORT-NAME>pport1</SHORT-NAME> <PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"> /interfaces/sr Int16 </PROVIDED-INTERFACE-TREF> 90 </P-PORT-PROTOTYPE> <R-PORT-PROTOTYPE> <SHORT-NAME>rport1</SHORT-NAME> <REQUIRED-INTERFACE-TREF DEST="CLIENT-SERVER-INTERFACE"> /interfaces/cs string to int </REQUIRED-INTERFACE-TREF> </R-PORT-PROTOTYPE> </PORTS> </ATOMIC-SOFTWARE-COMPONENT-TYPE> <ATOMIC-SOFTWARE-COMPONENT-TYPE> 100 <SHORT-NAME>swc2</SHORT-NAME> <PORTS> <P-PORT-PROTOTYPE> <SHORT-NAME>pport1</SHORT-NAME> <PROVIDED-INTERFACE-TREF DEST="CLIENT-SERVER-INTERFACE"> /interfaces/cs string to int </PROVIDED-INTERFACE-TREF> </P-PORT-PROTOTYPE> <R-PORT-PROTOTYPE> <SHORT-NAME>rport1</SHORT-NAME> 110 <REQUIRED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE"> /interfaces/sr Int16 </REQUIRED-INTERFACE-TREF> </R-PORT-PROTOTYPE> </PORTS> </ATOMIC-SOFTWARE-COMPONENT-TYPE> <INTERNAL-BEHAVIOR> <SHORT-NAME>intBehSwc1</SHORT-NAME> <COMPONENT-REF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc1</component-ref> <EVENTS> 120 <TIMING-EVENT> <SHORT-NAME>Time100ms</SHORT-NAME> <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intbehswc1/run11</start-on-event-ref> <PERIOD>0.1</PERIOD> </TIMING-EVENT> <TIMING-EVENT> <SHORT-NAME>Time50ms</SHORT-NAME> <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intbehswc1/run12</start-on-event-ref> <PERIOD>0.05</PERIOD> </TIMING-EVENT> 130 </EVENTS> <RUNNABLES> <RUNNABLE-ENTITY> <SHORT-NAME>run11</SHORT-NAME> <CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY> <DATA-SEND-POINTS> <DATA-SEND-POINT> <SHORT-NAME>dwa1</SHORT-NAME> <DATA-ELEMENT-IREF> <P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</p-port-prototype-ref> 140 <DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE"> 94

105 /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> <DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE"> 150 /interfaces/sr Int16/intValue2 </DATA-ELEMENT-PROTOTYPE-REF> </DATA-ELEMENT-IREF> </DATA-SEND-POINT> </DATA-SEND-POINTS> <SYMBOL>run11</SYMBOL> </RUNNABLE-ENTITY> <RUNNABLE-ENTITY> <SHORT-NAME>run12</SHORT-NAME> <CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY> 160 <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> </DATA-SEND-POINT> 170 </DATA-SEND-POINTS> <SERVER-CALL-POINTS> <SYNCHRONOUS-SERVER-CALL-POINT> <SHORT-NAME>sscp</SHORT-NAME> <OPERATION-IREFS> <OPERATION-IREF> <R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE"> /swc root/swc1/rport1 </R-PORT-PROTOTYPE-REF> <OPERATION-PROTOTYPE-REF DEST="OPERATION-PROTOTYPE"> 180 /interfaces/cs string to int/parse </OPERATION-PROTOTYPE-REF> </OPERATION-IREF> </OPERATION-IREFS> </SYNCHRONOUS-SERVER-CALL-POINT> </SERVER-CALL-POINTS> <SYMBOL>run12</SYMBOL> </RUNNABLE-ENTITY> </RUNNABLES> <SUPPORTS-MULTIPLE-INSTANTIATION>false</SUPPORTS-MULTIPLE-INSTANTIATION> 190 </INTERNAL-BEHAVIOR> <INTERNAL-BEHAVIOR> <SHORT-NAME>intBehSwc2</SHORT-NAME> <COMPONENT-REF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc2</component-ref> <EVENTS> <TIMING-EVENT> <SHORT-NAME>Time50ms</SHORT-NAME> <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intbehswc2/run22</start-on-event-ref> <PERIOD>0.05</PERIOD> </TIMING-EVENT> 200 <OPERATION-INVOKED-EVENT> <SHORT-NAME>operationInvoke</SHORT-NAME> <START-ON-EVENT-REF DEST="RUNNABLE-ENTITY">/swc root/intbehswc2/run21</start-on-event-ref> <OPERATION-IREF> <P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc2/pport1</p-port-prototype-ref> <OPERATION-PROTOTYPE-REF DEST="OPERATION-PROTOTYPE"> /interfaces/cs string to int/parse </OPERATION-PROTOTYPE-REF> </OPERATION-IREF> </OPERATION-INVOKED-EVENT> 210 </EVENTS> <RUNNABLES> <RUNNABLE-ENTITY> <SHORT-NAME>run21</SHORT-NAME> <CAN-BE-INVOKED-CONCURRENTLY>true</CAN-BE-INVOKED-CONCURRENTLY> <SYMBOL>run21</SYMBOL> </RUNNABLE-ENTITY> <RUNNABLE-ENTITY> <SHORT-NAME>run22</SHORT-NAME> <CAN-BE-INVOKED-CONCURRENTLY>false</CAN-BE-INVOKED-CONCURRENTLY> 220 <DATA-RECEIVE-POINTS> <DATA-RECEIVE-POINT> <SHORT-NAME>dra1</SHORT-NAME> <DATA-ELEMENT-IREF> <R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc2/rport1</r-port-prototype-ref> 95

106 Appendix A Example <DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE"> /interfaces/sr Int16/intValue1 </DATA-ELEMENT-PROTOTYPE-REF> </DATA-ELEMENT-IREF> </DATA-RECEIVE-POINT> 230 <DATA-RECEIVE-POINT> <SHORT-NAME>dra2</SHORT-NAME> <DATA-ELEMENT-IREF> <R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc2/rport1</r-port-prototype-ref> <DATA-ELEMENT-PROTOTYPE-REF DEST="DATA-ELEMENT-PROTOTYPE"> /interfaces/sr Int16/intValue2 </DATA-ELEMENT-PROTOTYPE-REF> </DATA-ELEMENT-IREF> </DATA-RECEIVE-POINT> </DATA-RECEIVE-POINTS> 240 <SYMBOL>run22</SYMBOL> </RUNNABLE-ENTITY> </RUNNABLES> <SUPPORTS-MULTIPLE-INSTANTIATION>false</SUPPORTS-MULTIPLE-INSTANTIATION> </INTERNAL-BEHAVIOR> <IMPLEMENTATION> <SHORT-NAME>implSwc1</SHORT-NAME> <BEHAVIOR-REF DEST="INTERNAL-BEHAVIOR">/swc root/intbehswc1</behavior-ref> <CODE-DESCRIPTOR> <SHORT-NAME>src</SHORT-NAME> 250 <TYPE>SRC</TYPE> </CODE-DESCRIPTOR> <PROGRAMMING-LANGUAGE>C</PROGRAMMING-LANGUAGE> </IMPLEMENTATION> <IMPLEMENTATION> <SHORT-NAME>implSwc2</SHORT-NAME> <BEHAVIOR-REF DEST="INTERNAL-BEHAVIOR">/swc root/intbehswc2</behavior-ref> <CODE-DESCRIPTOR> <SHORT-NAME>src</SHORT-NAME> <TYPE>SRC</TYPE> 260 </CODE-DESCRIPTOR> <PROGRAMMING-LANGUAGE>C</PROGRAMMING-LANGUAGE> </IMPLEMENTATION> </ELEMENTS> </AR-PACKAGE> <AR-PACKAGE> <SHORT-NAME>comp root</short-name> <ELEMENTS> <COMPOSITION-TYPE> <SHORT-NAME>comp</SHORT-NAME> 270 <PORTS /> <COMPONENTS> <COMPONENT-PROTOTYPE> <SHORT-NAME>swc1</SHORT-NAME> <TYPE-TREF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc1</type-tref> </COMPONENT-PROTOTYPE> <COMPONENT-PROTOTYPE> <SHORT-NAME>swc2</SHORT-NAME> <TYPE-TREF DEST="ATOMIC-SOFTWARE-COMPONENT-TYPE">/swc root/swc2</type-tref> </COMPONENT-PROTOTYPE> 280 </COMPONENTS> <CONNECTORS> <ASSEMBLY-CONNECTOR-PROTOTYPE> <SHORT-NAME>ac1 swc1pport1swc2rport1</short-name> <PROVIDER-IREF> <COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc1</component-prototype-ref> <P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc1/pport1</p-port-prototype-ref> </PROVIDER-IREF> <REQUESTER-IREF> <COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc2</component-prototype-ref> 290 <R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc2/rport1</r-port-prototype-ref> </REQUESTER-IREF> </ASSEMBLY-CONNECTOR-PROTOTYPE> <ASSEMBLY-CONNECTOR-PROTOTYPE> <SHORT-NAME>ac2 swc2pport1swc1rport1</short-name> <PROVIDER-IREF> <COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc2</component-prototype-ref> <P-PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">/swc root/swc2/pport1</p-port-prototype-ref> </PROVIDER-IREF> <REQUESTER-IREF> 300 <COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE">/comp root/comp/swc1</component-prototype-ref> <R-PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">/swc root/swc1/rport1</r-port-prototype-ref> </REQUESTER-IREF> </ASSEMBLY-CONNECTOR-PROTOTYPE> </CONNECTORS> 96

107 </COMPOSITION-TYPE> </ELEMENTS> </AR-PACKAGE> <AR-PACKAGE> <SHORT-NAME>system root</short-name> 310 <ELEMENTS> <SYSTEM-TOPOLOGY-TYPE> <SHORT-NAME>system topology</short-name> <COMMUNICATION-CLUSTERS /> <TOPOLOGY-ELEMENTS> <ECU-INSTANCE> <SHORT-NAME>ecu</SHORT-NAME> <COMM-PORTS /> <ECU-TREF DEST="ECU">/ecu root/ecu</ecu-tref> <POWER-SUPPLY>BATTERY</POWER-SUPPLY> 320 <PROCESSING-UNIT-ENDIANNESS>MOST-SIGNIFICANT-BYTE-LAST</PROCESSING-UNIT-ENDIANNESS> </ECU-INSTANCE> </TOPOLOGY-ELEMENTS> </SYSTEM-TOPOLOGY-TYPE> <SYSTEM> <SHORT-NAME>system</SHORT-NAME> <COMMUNICATION> <COMMUNICATION-MATRIXS /> </COMMUNICATION> <MAPPING> 330 <SHORT-NAME>sys mapping</short-name> <DATA-MAPPINGS /> <SW-MAPPINGS> <SW-COMP-TO-ECU-MAPPING> <SHORT-NAME>ecu instance</short-name> <COMPONENT-IREFS> <COMPONENT-IREF> <SOFTWARE-COMPOSITION-REF DEST="SOFTWARE-COMPOSITION"> /system root/system/comp instance </SOFTWARE-COMPOSITION-REF> 340 <TARGET-COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE"> /comp root/comp/swc1 </TARGET-COMPONENT-PROTOTYPE-REF> </COMPONENT-IREF> <COMPONENT-IREF> <SOFTWARE-COMPOSITION-REF DEST="SOFTWARE-COMPOSITION"> /system root/system/comp instance </SOFTWARE-COMPOSITION-REF> <TARGET-COMPONENT-PROTOTYPE-REF DEST="COMPONENT-PROTOTYPE"> /comp root/comp/swc2 350 </TARGET-COMPONENT-PROTOTYPE-REF> </COMPONENT-IREF> </COMPONENT-IREFS> <ECU-INSTANCE-IREF> <SYSTEM-TOPOLOGY-INSTANCE-REF DEST="SYSTEM-TOPOLOGY-INSTANCE"> /system root/system/system topology instance </SYSTEM-TOPOLOGY-INSTANCE-REF> <ECU-INSTANCE-REF DEST="ECU-INSTANCE">/system root/system topology/ecu</ecu-instance-ref> </ECU-INSTANCE-IREF> </SW-COMP-TO-ECU-MAPPING> 360 </SW-MAPPINGS> </MAPPING> <SOFTWARE-COMPOSITION> <SHORT-NAME>comp instance</short-name> <SOFTWARE-COMPOSITION-TREF DEST="COMPOSITION-TYPE">/comp root/comp</software-composition-tref> </SOFTWARE-COMPOSITION> <TOPOLOGY> <SHORT-NAME>system topology instance</short-name> <TOPOLOGY-TREF DEST="SYSTEM-TOPOLOGY-TYPE">/system root/system topology</topology-tref> </TOPOLOGY> 370 </SYSTEM> </ELEMENTS> </AR-PACKAGE> <AR-PACKAGE> <SHORT-NAME>ecu root</short-name> <ELEMENTS> <ECU> <SHORT-NAME>ecu</SHORT-NAME> <ECU-ABSTRACTION-REF DEST="COMPOSITION-TYPE">/comp root/comp</ecu-abstraction-ref> </ECU> 380 </ELEMENTS> </AR-PACKAGE> </TOP-LEVEL-PACKAGES> </AUTOSAR> 97

108 Appendix A Example 98

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

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

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

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

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

114 Appendix B Requirements of the Functional Specification 104

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

116

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

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