ERTS 2014 - Embedded Real Time Software and Systems, Toulouse, 05 - 07.02.

2014

Faster Development of
AUTOSAR compliant ECUs through simulation
Andreas Junghanns, Jakob Mauss
QTronic GmbH
Alt-Moabit 92, D-10559 Berlin

Michael Seibt
Dassault Systèmes Deutschland GmbH
Joseph-Wild-Str.20, D-81829 München

Abstract - Virtualization allows the simulation of in AUTOSAR Builder, selected software components
automotive ECUs on a Windows PC executing in a or compositions can be exported including an
closed-loop with a vehicle simulation model. This AUTOSAR OS (Operating System) and RTE (Run-
approach enables moving many development tasks Time Environment) as an FMU (Functional Mockup
from road or test rigs and HiL (Hardware in the loop) Unit). FMU [4] is a new exchange format for models
to PCs, where they can often be performed faster and that has been developed in the EU-funded
cheaper. Technical challenge: How to port ECU tasks MODELISAR project (2008 - 2011) and since then
and basic software to Windows PC with reasonable gained considerable acceptance across multiple
effort, so that key development tasks can be performed industries and tools. The FMU can then be imported
on a PC, without the need of accessing real hardware into the virtual ECU tool Silver (QTronic), where it
such as vehicle prototypes, test rigs or HiL facilities. can be co-simulated with vehicle models originating
This paper presents a new solution for the use case of from a wide range of simulation tools, including
ECUs developed within the emerging AUTOSAR Dymola, SimulationX, MapleSim and AMESim.
standard: First, the AUTOSAR authoring tool Vehicle models are again provided as FMUs, or via
AUTOSAR Builder (Dassault Systèmes) is used to proprietary binary export formats, typically Windows
design the application software and system aspects of DLLs. Tools for measurement and calibration such as
a single ECU or an distributed embedded system CANape (Vector Informatik) or INCA (ETAS) can
which is then stored as AUTOSAR XML descriptions. then be connected to the virtual ECU running on PC,
The application code can either be developed in the to directly measure or tune its parameters, like an
AUTOSAR Builder environment or auto-generated by engineer would do in a real car. Virtual ECUs are also
tools such as Embedded Coder (MathWorks), used to move testing activities from test rigs and HiLs
TargetLink (dSPACE) or Ascet (ETAS). Once tested to Windows PC.

Fig 1: Development of automotive ECUs

1
ERTS 2014 - Embedded Real Time Software and Systems, Toulouse, 05 - 07.02.2014

1. Introduction within 5 minutes after modification of a software

Software for automotive ECUs is jointly developed by module, thanks to incremental build, and test drive
OEMs and their suppliers as shown in Fig. 1. the result in a simulated environment. This helps
Typically, a team of function developers uses a model- detecting problems early on the developer's PC,
based tool chain to develop a model of the ECU and to and decreases the number of problems that show
generate C code from that. The resulting C code is up late, when integrating all modules. As
then compiled for the target processor, and the experience shows, such early checks speed up
resulting ECU is validated and tested using test rigs, development.
HiL systems, and road tests. Test and validation • Independence of real time simulation: A virtual
results are fed back to the developers, which closes the ECU might run on PC many times faster than in
development cycle. See [10] for details and typical real time. When used in combination with test
numbers. automation, a simple PC gives a higher test
This process, although standard in the automotive throughput than a considerable more expensive
industry today, has two major drawbacks: HiL test system. S. Gloss et. al. [1] reports how
• a single iteration takes days or weeks, that is, this effect is exploited to test 200 variants of a
feedback reaches developers late transmission controller.
• the process depends on prototype vehicles and test
rigs. These are typically rare resources during Other points that illustrate the benefit of virtual ECUs:
development. Their limited availability causes • On a PC, an engineer can easily "freeze time", i. e.
additional delays during development. stop simulation and inspect the call stack and all
This paper presents a tool chain that supports an variables of a virtual (i. e. simulated) ECU without
improved development process. The key idea is to bandwidth limitation and repeat a simulation
provide development engineers with virtual ECUs, deterministically as often as needed. In contrast, a
which enables them to move many development tasks real ECU being used in a HiL environment or test
from test rigs and HiLs to Windows PC. As rig must run in real time. Stopping and stepping is
experience shows,this helps to shorten development impossible then, or requires considerable extra
cycles (down to 5 minutes for an incremental build) effort, e. g. based on the JTAG debug interface.
and to reduce the critical dependency to real hardware. Exact reproduction of experiments is difficult or
We focus here on AUTOSAR projects, although the impossible on a HiL or test rig, due to non-
method does not depend on the framework (hand deterministic effects.
coded, model-based, AUTOSAR) used to develop the • Having a PC-based solution, a calibration tool like
ECU. INCA (ETAS) or CANape (Vector) can be
connected to a virtual ECU via XCP to measure
The remaining paper is structured as follows: In the into a running simulation and to tune
next section, we summarize various benefits of a characteristics online. In this way, many
virtual ECU for automotive development, with parameters of an ECU can be tuned using a
references to real applications. Section 3 explains how relatively cheap and highly available PC platform,
to build a virtual ECU for development projects that without blocking rare and more expensive
use the emerging AUTOSAR framework and section 4 resources like physical prototypes and test rigs.
demonstrates how to use the resulting virtual ECU on • A virtual ECU runs independent from real time
Windows PC to speed up development. and can hence also easily be coupled with very
time consuming simulations, such as combustion
2. Virtual ECUs in the development simulation. This is impossible for test rigs or HiL
systems, where all parts of the simulation must run
process
in real-time.
Simulation has great potential to improve the
development process for ECUs. It helps to move
development tasks to PC, where they can often be To exploit these and other benefits when developing
performed faster, cheaper or better in many respects. an ECU, the ECU must first be ported to a PC. This is
In general, the speed-up generated with virtual ECUs typically done based on the C code of the ECU, which
is the product of three independent factors is either hand-coded, or generated by tools such as
Ascet (ETAS), TargetLink (dSPACE) or Embedded
• Parallelization: Virtual ECUs help to split Coder (MathWorks). For example, QTronic's virtual
development into parallel threads. With virtual
ECU tool Silver [2] provides a framework to
ECUs, many development tasks can be moved
from shared resources (vehicles, test rigs, HiL) to • Compile given ECU tasks for Windows PC,
PC, where engineers can work in parallel, without • Emulate the underlying RTOS and other services
blocking each other. (CAN, XCP),
• Faster feedback on system level: On a PC, a • Execute the resulting virtual ECU in a closed-loop
development engineer can rebuild the entire ECU with a simulated vehicle.

2
ERTS 2014 - Embedded Real Time Software and Systems, Toulouse, 05 - 07.02.2014

Fig 2: Simulation of an AUTOSAR Software Component in Silver

Typical applications are [1,2,3,4], where a virtual description, consistency or design rule checks have to
ECU is used to develop the controller for an automatic be applied iteratively. Once this step has been passed,
transmission. For closed-loop simulation, vehicle unit-testing can be performed by simulating single
models can be imported from many simulation tools Software Components (SWCs) or even full
into Silver, including MATLAB/Simulink, Dymola, compositions (CSWCs) that also take a real
SimulationX and MapleSim, e.g. through the FMI AUTOSAR OS and RTE into account. The
(Functional Mockup Interface) format for model application code (which can be manually coded or
exchange [5]. auto-generated) needs to be provided as source or
C code is not always available for implementing a compiled. In addition the test vectors need to be
virtual ECU, for example when all or major parts of defined through a dedicated environment or can be
the ECU have been developed by a supplier and the imported. Everything else, including the OS and the
OEM that is interested in building a virtual ECU has RTE configuration and the Testbench is generated
therefore no access to the C source code. Silver automatically. Once the SWCs or CSWCs have passed
supports such cases with a chip simulator [6, 10]. The the tests in simulation, they can be exported as FMUs
chip simulator takes the binary code for the target including the AUTOSAR OS and RTE.
processor (currently TriCore or PowerPC) and
simulates the execution of the instructions by the
target processor on a Windows PC. Fig 3 shows a screen shot of AUTOSAR Builder, with
an AUTOSAR software component EGS1 (a simple
3. Designing and testing a Virtual ECU controller for a 6-speed automatic transmission)
with AUTOSAR Builder loaded. AUTOSAR Builder provides means to export
An AUTOSAR authoring tool such as AUTOSAR this controller as an FMU for Co-Simulation or Model
Builder allows the modeling of a single ECU or a Exchange [5].
distributed embedded system based on templates
defined by the AUTOSAR standard. To ensure the
validity and completeness of an AUTOSAR

3
ERTS 2014 - Embedded Real Time Software and Systems, Toulouse, 05 - 07.02.2014

Fig 3: AUTOSAR Builder in simulation mode

4. Running a simulation in Silver parameters during simulation. This approach

A virtual ECU exported from AUTOSAR Builder as allows the expertise of calibration engineers with
FMU can be loaded into the Silver runtime INCA or CANape to be also available in the PC
environment, which runs on Windows. Fig. 2 shows a environment.
screen shot of Silver with the transmission controller • Import a vehicle model from simulation tools such
EGS exported with AUTOSAR Builder loaded as as Dymola, SimulationX, MapleSim, AMESim,
virtual ECU. Besides the virtual ECU, also a vehicle Simulink, GT-Power, or axisuite.
model developed in Dymola / Modelica has been • Connect a test automation solution to Silver, to test
loaded into Silver, which enables closed-loop the ECU on a PC as shown in [1] and [11].
execution of the transmission controller. The tree • Connect Visual Studio Debugger to the virtual
shown on the left of the Silver window shows all ECU, define code or data breakpoint and debug the
loaded modules, and their input and output variables. virtual ECU at the code level, e.g. to fix problems
In real projects, this tree might contain hundred found by test automation. Virtual ECUs running in
thousands of scalar variables. Silver has been a fully simulated environment on PC are
optimized to efficiently deal with such large models. particularly attractive here, because the corres-
The top-right part of the Silver window contains the ponding step-debug functionality is much harder or
plotters, gauges, sliders, and push buttons configured impossible to achieve in a real-time environment.
by the development engineer to interact with the • Drive the virtual vehicle interactively on PC to
vehicle model. In the case shown here, the engineer explore behaviour of the virtual ECU, without
can start the engine, switch the PRND lever to any limitations of how much or what can be measured
position, accelerate and brake using sliders, and watch during simulation.
the temperatures of the transmission brakes and • Drive the simulation using measured data,
clutches, and other key variables of the vehicle. available as MDF, DAT or CSV file. This can be
used to implement open-loop tests of the virtual
Once loaded into Silver, the services shown in Fig. 4 ECU. In simple cases, this does not even require a
are available to implement various engineering tasks. vehicle model: the virtual ECU is then directly
Example uses cases are: driven by measurements.
• Connect INCA (ETAS) or CANape (Vector) to the • Drive the simulation using a Python script. Python
virtual ECU via the extended CAN calibration scripting can be used to implement reactive tests
protocol (XCP, an ASAM standard) to diagnose a (including e. g. 'do until' test steps) or an
running simulation and to tune software optimization loop that automatically calibrates
ECU software parameters using mathematical
optimization.

4
ERTS 2014 - Embedded Real Time Software and Systems, Toulouse, 05 - 07.02.2014

Fig 4: The Silver runtime environment for virtual ECUs

5. Conclusion Friedrichshafen, Germany, 30.06.-01-07.2009.

As demonstrated above, virtual ECUs help to move http://qtronic.de/doc/DCT_2009.pdf
development tasks to a PC, which speeds up [4] M. Tatar, R. Schaich, T. Breitinger: Automated
automotive embedded systems development test of the AMG Speedshift DCT control
tremendously. We have demonstrated a technical software. 9th International CTI Symposium
realization of virtual ECUs for the special case of Innovative Automotive Transmissions, Berlin,
AUTOSAR. Silver supports the same idea also for 2010. http://qtronic.de/doc/
ECUs that run software generated with non- TestWeaver_CTI_2010_paper.pdf
AUTOSAR tool chains. Use of virtual ECUs is
increasing but not yet wide-spread in the automotive [5] T. Blochwitz, M. Otter et. al.: Functional
industry today. We expect to see significant growth of Mockup Interface 2.0: The Standard for Tool
automotive applications in the coming years, mainly independent Exchange of Simulation Models.
driven by the speed up of development that can be 9th International Modelica Conference, Munich,
achieved as outlined in this paper. 2012. http://www.ep.liu.se/ecp/076/017/
ecp12076017.pdf
References [6] M. Simons, M. Feier, J. Mauss: Using Chip
Simulation to optimize Engine Control. 7th
[1] S. Gloss, M. Slezák, A. Patzer: Systematic Conference on Design of Experiments (DoE) in
validation of over 200 transmission variants. Engine Development, Berlin, 2013.
ATZ elektronik 4/2013. August 2013. http://qtronic.de/doc/
http://www.qtronic.de/doc/ doe2013_chip_simulation.pdf
ATZe_04_2013_en.pdf [7] http://www.autosar.org
[2] A. Junghanns, R. Serway, T. Liebezeit, M. [8] M. Seibt, A. Gauthier, Denis Laroudie: Start
Bonin: Building Virtual ECUs Quickly and “virtual” to make it “real”.
Economically, ATZ elektronik 03/2012, June Hanser Automotive, 02/2013
2012. http://www.qtronic.de/doc/
[9] http://www.3ds.com/products/catia/
ATZe_2012_en.pdf
portfolio/geensoft/autosar-builder/
[3] H. Brückmann, J. Strenkert, U. Keller, B. xtmc=autosar_builder&xtcr=3
Wiesner, A. Junghanns: Model-based
[10] J. Mauss: Chip simulation used to run
Development of a Dual-Clutch Transmission
automotive software on PC. ERTS-2014,
using Rapid Prototyping and SiL. International
Toulouse, 05 - 07.02.2014.
VDI Congress Transmissions in Vehicles 2009,
[11] M. Tatar, J. Mauss: Systematic Test and
Validation of Complex Embedded Systems,
ERTS-2014, Toulouse, 05 - 07.02.2014.