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 [email protected]
> 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