Plug and Play Solution for AUTOSAR Software Components

Plug and Play Solution for AUTOSAR Software Components The interfaces defined in the AUTOSAR standard enable an easier assembly of the ECU application out of components from different suppliers. However, the process of software development is delayed, because an additional step is required to combine the individual components into the overall software. The use of exchangeable software components reduces the number of these overall integrations, because it is possible to exchange individual software components in flash memory without linking the entire project. This accelerates software development at each of the individual suppliers. The AUTOSAR ECU software is subdivided into three areas: basic software, runtime environment and application (Figure 1). The basic software (BSW) is the basic framework that provides the application with the resources of the microcontroller by means of drivers and abstraction layers. The Runtime Environment (RTE) serves as the interconnecting layer between the application and the basic software. The RTE abstracts the communication between application sections and thereby enables transparent data exchange beyond ECU boundaries as well. For this purpose the RTE provides interfaces to the application and the basic software. In contrast to the BSW, whose static modules can be used unchanged in different ECUs, the RTE is individually generated for each ECU and only supplies the interfaces that are actually needed. The application consists of software components (SWCs), which implement ECU functionality in the form of what are known as Runnables. Distributed software development The modular AUTOSAR architecture makes it easier for software suppliers to specialize in specific applications and components, e.g. basic software, vehicle dynamics, engine management, etc. As a result, it is not unusual for an ECU s software to consist of modules and components from different suppliers. The individual parts are supplied as either source code or pre-compiled binary files, and they are combined into complete, executable ECU software at the responsible ECU producer during an overall integration. In turn, all SWC suppliers get the resulting software image for their further development steps. However, this method is very time-consuming, and it slows down software development. On the one hand, the ECU producer must perform a tedious overall integration for each new version of an SWC. On the other, the SWC supplier must wait for the 1

integration results to be able to test its application in interaction with the other ECU software. The frequent waiting periods lead to considerable extra effort, particularly in early development phases. Post-build: software adaptations after linking AUTOSAR defines a post-build method for the basic software that makes it possible to modify the behavior of certain BSW modules after compiling and linking. This involves storing the configuration data in flash memory, separate from the BSW module code. This means that the data can be replaced at runtime without having to recompile and link the ECU software. The AUTOSAR standard does not define any comparable postbuild method for the SWCs of the application software, and so every modification even to just one SWC requires compiling and linking of the entire ECU software. However, there is a way to reduce the number of complete integrations. In the following, we present how an SWC supplier can exchange individual SWCs of the application software directly in flash memory, which reduces integration overhead. the binary of it at the correct location in the overall software image, and they can then begin to test their SWC right away. To prevent the SWC versions from drifting apart excessively, the overall integrator generates new ECU software images at regular intervals with updated versions of all SWCs. There are no limitations with regard to which SWCs may be exchanged. However, the decision about this must be made during the ECU planning phase, because special considerations must be observed in implementation and memory distribution. Reserving memory for exchangeable SWCs In today s software development, overall integration typically involves linking the SWC program code without specifying memory mapping parameters. In the case of exchangeable SWCs, the SWC supplier must perform linking based on specific memory mappings. During linking, both the RTE and the SWC expect one another s What is the procedure for exchanging SWCs? When exchanging an SWC, the existing SWC is replaced by an updated version directly in the ECU s memory. This process does not impair the remaining ECU software. This is done either online on the ECU using a flash bootloader, or offline using a suitable HEX editor with subsequent transfer into the ECU (Figure 2). SWC exchanging is normally performed by the SWC supplier, but it can also be performed by the overall integrator. By saving in overall integration effort, suppliers can realize shorter development cycles: Coding Exchanging Testing Optimizing (Figure 3). The overall integrator initially generates a software image of the entire ECU and makes it available to the SWC suppliers. Then, the suppliers only need to create a new version of their SWC, place Figure 2: The exchangeable SWC is released in the memory image (above) and is transferred to the ECU s flash memory. Figure 1: AUTOSAR layers model 2

interfaces at the addresses stored in the ECU memory. To assure this, the ECU memory is subdivided into multiple partitions that are exclusively reserved to the individual SWCs. To determine the partition sizes, an estimate is made of how much memory the SWC s individual runnables are expected to require. Initially, this increases the memory requirements for the application. However, this only applies to the development period. Partitioning can be omitted in the final software for production use to reduce memory requirements. Generally, only complete flash pages can be erased, in the simplest case one or more complete flash pages are reserved for each SWC. However, if the SWC is significantly smaller than one flash page, and the resulting fragmenting is unacceptable, multiple SWCs may be assigned to one flash page. In this case, however, it must be assured that the rest of the flash page content is not changed during the exchange of the SWC with the flash bootloader or HEX editor. Software environment for compiling and linking an SWC To compile and link their SWCs, suppliers need a software environment that resolves all SWC dependencies to the called interfaces. Ideally, this environment would be the entire, runnable ECU software including the BSW and application which is also used in the overall integration. In its basic methodology, this variant represents a complete integration; however, the integration takes place at the SWC supplier. The set-up of such a software environment usually takes much effort, and is not always possible. Therefore, the SWC supplier can independently create a minimal environment as an alternative. This environment only needs to service the interfaces called by the SWC (Figure 4). In both of these variants, after compiling and linking the SWC supplier obtains a binary file which, along with the SWC, also contains the code for the software environment. This additional code is irrelevant for the later exchange of an SWC and is removed. This results in a binary file of the SWC to be tested, in which the jump targets are already stored at the correct memory addresses. How does exchanging of SWCs work? After updating an SWC in flash memory, it must still be possible for the RTE or other runnables to call the runnables contained in the SWC. During compiling in a complete integration, the linker replaces the symbolic jump targets stored in the RTE by the actual (real) addresses of the runnables within the SWC. Because these addresses remain unchanged within the RTE when an SWC is exchanged, it must be guaranteed that the runnables of an exchangeable SWC are always stored at these memory addresses for every compiling and linking operation. This condition can be satisfied by suitable compiler and linker instructions that allocate fixed, manually assigned addresses to the individual runnables, for example. However, it is very likely that the memory requirement of the runnables will grow over the course of ECU development. For this reason, a memory area must be reserved within the SWC. To set up this reserve, the SWC supplier uses compiler instructions to subdivide the SWC into a static area and a changeable area. Figure 3: Exchanging of SWCs accelerates an SWC supplier s software development. Fig ure 4: With exchanging SWCs, a minimal software environment is used for linking instead of the entire software environment. 3

The static area contains the area for jumps into the SWC. This always remains the same, even if the implementation of the functionality changes. The SWC s runnables are modified to achieve this. They no longer contain the specific application code, rather just a function call. The so-called runnable functions that are called here are located in the SWC s changeable area and contain the actual functional code of the runnables (Figure 5). As a result, this code may be changed as desired, without shifting the addresses of the runnables in the static area. Whenever an SWC is compiled and linked, the symbolic jump targets of the runnables are replaced by the actual addresses or offsets. Therefore, the RTE does not need to know the actual addresses of the runnable functions. Calling port interfaces from an SWC Analogous to the call of the runnables by the RTE, in the opposite direction the runnable functions must call the port interfaces provided by the RTE. If the SWC supplier uses a complete software environment with BSW and RTE from the complete integration (See section Software environment for compiling and linking an SWC ), no further measures are required, because all jump targets are known at the linking time. However, if a minimal software environment is used, the port interfaces of the RTE are located at other addresses than those of the overall integration when the SWC is created. This results in incorrect addresses being stored when linking the SWC. To ensure that calling of port interfaces from the SWCs operates correctly, two AUTOSAR features are used with exchangeable SWCs: Object Code and Multiple Instantiation. With this combination, the RTE passes the so-called Instance Handle as a parameter to each runnable at runtime. This handle points to an indirection structure of the RTE, the so-called Component Data Structure (Figure 6). Stored in this structure are the addresses of all port interfaces of the SWC. Therefore, the SWC does not need to know the addresses of the RTE port interfaces. The Component Data Structure is described in the Contract Phase Header file of each SWC. Constraints for exchanging an SWC To make it possible to exchange SWCs as described here, certain constraints must be satisfied. > > During the process of replacing an SWC, port interfaces must not be added or removed. However, additional port interfaces may be allocated in the RTE generation for future extensions. > > The number of runnables must not change within an SWC, because the RTE can call all runnables known at the time of RTE generation. If runnables are removed during development, or if new ones are added, the RTE must be modified accordingly, and an overall integration must be executed. Fig ure 5: By subdividing the SWC into a static area and a changeable area, the runnables lie at fixed addresses and can be called without re-linking the RTE. Fig ure 6: An instance handle is passed to the runnables when they are called. This gives the runnable functions access to the port interfaces of the RTE. 4

> > In the planning phase, it is already necessary to define which requirements the individual SWCs will place on the ECU. This relates to hardware resources, on the one hand, but also to the additional mathematical libraries needed and scheduling of individual runnables. > > The tool chains of individual suppliers must be coordinated to prevent incompatibilities due to different compiler versions and options. Alexander Zeeb, Vector M.Sc. is Software Development Engineer in Concept Development for Embedded Software at Vector Informatik GmbH in Stuttgart Outlook The application example presented here with multiple SWC suppliers and one overall integrator is not the only conceivable application case. Exchangeable SWCs can also simplify bypassing of SWCs, because the instrumentation necessary for bypassing can be conveniently applied to the ECU by a exchangeable SWC. If the SWC will then actually be tested on the ECU, the instrumentation can be replaced once again by the non-instrumented SWC. Exchangeable SWCs represent a powerful tool that can support and accelerate the development of ECU software. So far, preparation of an SWC and memory mapping still needs to be performed manually. However, there are plans to automate much of this process by configuration. Translation of a German publication in ATZ elektronik, issue 1-2/2012 Figures: Figure 1: AUTOSAR development cooperation with extensions by Vector Informatik GmbH Figure 0 & 2-6: Vector Informatik GmbH >> Your Contact: Germany and all countries, not named below Vector Informatik GmbH, Stuttgart, Germany, www.vector.com France, Belgium, Luxembourg Vector France, Paris, France, www.vector-france.com Sweden, Denmark, Norway, Finland, Iceland VecScan AB, Göteborg, Sweden, www.vector-scandinavia.com Great Britain Vector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk USA, Canada, Mexico Vector CANtech, Inc., Detroit, USA, www.vector-cantech.com Japan Vector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp Korea Vector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr China Vector Automotive Technology Co., Ltd., www.vector-china.com India Vector Informatik India Prv. Ltd., Pune, India, www.vector.in E-Mail Contact info@vector.com 5