102/2012

Technical Article

Plug and Play Solution for AUTOSAR Software Components

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 imple-

ment 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 mod-

ules 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

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.

2

Technical Article

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 post-

build 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 inte-

gration overhead.

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

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 over-

all integrator generates new ECU software images at regular inter-

vals 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

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

302/2012

Technical Article

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 replac-

es the symbolic jump targets stored in the RTE by the actual (real)

addresses of the runnables within the SWC. Because these address-

es 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. How-

ever, 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.

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 increas-

es 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 sim-

plest 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 environ-

ment that resolves all SWC dependencies to the called interfaces.

Ideally, this environment would be the entire, runnable ECU soft-

ware – including the BSW and application – which is also used in

the overall integration. In its basic methodology, this variant rep-

resents 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 con-

tains the code for the software environment. This additional code

is irrelevant for the later exchange of an SWC and is removed. This

Fig ure 4: With exchanging SWCs, a minimal software environment is used for linking instead of the entire soft-ware environment.

Figure 3: Exchanging of SWCs accelerates an SWC supplier’s software development.

4

Technical Article

The static area contains the area for jumps into the SWC. This

always remains the same, even if the implementation of the func-

tionality 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 tar-

gets of the runnables are replaced by the actual addresses or off-

sets. Therefore, the RTE does not need to know the actual address-

es 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 pro-

vided 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.

Fig ure 5: By subdividing the SWC into a static area and a change-able 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.

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.

502/2012

Technical Article

>> Your Contact:

Germany and all countries, not named belowVector Informatik GmbH, Stuttgart, Germany, www.vector.com

France, Belgium, Luxembourg Vector France, Paris, France, www.vector-france.com

Sweden, Denmark, Norway, Finland, IcelandVecScan AB, Göteborg, Sweden, www.vector-scandinavia.com

Great BritainVector GB Ltd., Birmingham, United Kingdom, www.vector-gb.co.uk

USA, Canada, MexicoVector CANtech, Inc., Detroit, USA, www.vector-cantech.com

JapanVector Japan Co., Ltd., Tokyo, Japan, www.vector-japan.co.jp

KoreaVector Korea IT Inc., Seoul, Republic of Korea, www.vector.kr

ChinaVector Automotive Technology Co., Ltd., www.vector-china.com

IndiaVector Informatik India Prv. Ltd., Pune, India, www.vector.in

E-Mail Contactinfo@vector.com

> 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.

Outlook

The application example presented here – with multiple SWC sup-

pliers 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, prepara-

tion of an SWC and memory mapping still needs to be performed

manually. However, there are plans to automate much of this pro-

cess 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 GmbHFigure 0 & 2-6: Vector Informatik GmbH

Alexander Zeeb, VectorM.Sc. is Software Development Engineer in Concept Development for Embedded Soft-ware at Vector Informatik GmbH in Stuttgart