EVS26

Los Angeles, California, May 6 - 9, 2012

Early Simulation and Testing of Virtual ECUs for Electric

Vehicles
Lars Stockmann, Dominik Holler, Dr. Dirk Spenneberg
dSPACE GmbH, Rathenaustraße 26, 33102 Paderborn, [email protected]

Abstract
Testing new concepts in the field of closed-loop control is an important matter to the automotive in-
dustry. Especially in the domain of electric vehicles, there is a lot of ECU functionality targeting en-
ergy management and engine controlling that has to be developed and evaluated. Over the last decade,
hardware-in-the-loop simulation has successfully been used to test new ECUs. However, in early stages
of development, the target hardware is often not known and only parts of the final implementation is
available. Furthermore, there are different domains involved in the development process, from an early
behavioral model to the final integration into an ECU.
In our project we propose a methodology and tool chain that uses the simulation of virtual ECUs across
multiple domains. Virtual ECUs enable testing the functionality together with hardware-independent
non-application relevant aspects (e.g. some parts of the basic software or the run-time environment),
which effectively postpones the need for a close-to-production ECU prototype.
In this paper, we compare different levels of ECU abstractions regarding their convergence to a real ECU
and certain requirements that are imposed when developing electric vehicles. Here, we specifically aim
at finding the best suitable level for the early stages of development, where many aspects of the final
ECU are still not known and a HIL setup is not feasible. Nevertheless, one major goal of our project is to
experiment and test the virtual ECU in the same tool environment that is commonly used in HIL setups
to provide a certain reusability. In this context, this paper also presents current approaches for the reuse
of tests across domains, which will be addressed further as our project advances.

Keywords: control system, hardware-in-the-loop (HIL), modeling, optimization, simulation

1 Introduction mathematical models of the functionality (e.g. a

M ATLAB R /Simulink R model) to the full-fledged
ECU software, including the operating system
Today’s automotive industry faces many chal- and bus communications. Many of these tests are
lenges when developing zero emission cars that performed using closed-loop simulations that use
use hydrogen fuel cells or battery-based solu- environment models to generate the proper feed-
tions. Even though both fields benefit from the back. Furthermore, modern standards emerge
industry’s well-established methodologies and that address the growing complexity of automo-
know-how, it is especially in the area of closed- tive software. The AUTomotive Open System
loop control where many aspects require new ARchitecture or AUTOSAR for short provides a
concepts and approaches. One example is the in- standardized automotive software architecture. It
tegration of new, highly efficient energy manage- facilitates the exchangeability of ECU software
ment solutions. and hardware [1].
To meet the high safety requirements of the ve- In early phases, functional models are developed
hicle industry, all electric control units (ECUs) and tested using model-in-the-loop (MIL) sim-
must undergo a long series of tests, from the early

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 1
ulation. In a next step, a software developer can be done in less time, only depending on
uses the functional model as a specification and the speed of the underlying PC. Also, it allows
implements the C code or an implementation pausing the simulation at any time for debugging
model. In the latter case, an ECU autocoding tool purposes. However, it is also the reason why
like dSPACE TargetLink uses this implementa- such a simulation will never replace the later
tion model to generate the C code. This appli- HIL tests, because there are hardware-dependent
cation code is then tested with software-in-the- aspects of the ECU software that need the ECU
loop (SIL) or, if an evaluation board is available, prototype and the real-time capabilities of a HIL
with processor-in-the loop (PIL) simulation (e.g. simulator. If anything, such a model can be seen
to verify that a target compiler produces correct as a link between the pure application software
code). The results of this simulation are com- and the ECU prototype. If, for example, the
pared to the former MIL simulation. Tests us- simulation of the ECU model is sufficiently
ing SIL/PIL simulation in this context allow to close to the real behavior and allows the use
find issues that are induced by integer arithmetic of the typical experimentation and test tools
(as opposed to floating-point arithmetic in a MIL used with a real HIL simulator, it would be
simulation) like integer overflow or quantization possible for the HIL tester to implement and
errors. It should be noted though, that the soft- execute his/her tests for the later HIL simulation
ware components are tested individually. Errors beforehand. Ideally, tests (especially functional
that result from interacting with other compo- tests) could be reused on the HIL setup. This
nents remain undiscovered. would significantly reduce the time needed for
Until that point, the code can be tested on off-the- later HIL test preparation.
shelf personal computers (if the target hardware
is known, an evaluation board can be used). Af- There are a number of approaches provid-
terwards, the tested code is passed to the software ing different levels of abstraction: i.e. the virtual
integrator who integrates it with non-application- ECU (V-ECU) that appeared in 2007 [21] and,
related code (often named basic software, e.g. during the last years, has become an established
operating system, diagnostic event manager, I/O, means for virtual simulation-based validation
bus drivers), and produces flashable code for the and verification [15]. A V-ECU emulates the
real hardware-target. This basic software layer behavior of the later ECU based on software that
is often also referred to as hardware-dependent already exists in early stages (i.e. parts of the
software [8], which can be misleading as this pa- application software, and certain basic software
per shows that not all aspects of this layer might configurations). This enables testing the ECU
actually depend on the final hardware. software on a higher integration level (compared
Beyond that, in modern architectures like to the individual simulation of application code)
AUTOSAR a run-time environment is imple- before it is implemented on a real target (front-
mented as a middleware between the application loading of tests). Thus, errors can be found early
layer and basic software layer. The AUTOSAR in the development process and development
Runtime Environment (RTE) abstracts inter- and costs can be reduced.
intra-ECU communication of the application The question is whether this approach can be also
software. Thus, the application software does not used in the context of electric vehicles, where
need to be aware of the communication specifica- new control concepts are developed from the start
tion, which can be configured independently. and time-to-market pressure is high. Also, com-
pared to fuel-based cars, the whole topology of
The integrated ECU code together with a first the electric control units may have to be realized
version of the ECU hardware must now be differently due to the special need for weight re-
tested using hardware-in-the-loop (HIL) simula- duction and a more compact design. These are
tion. HIL simulation has become a firmly estab- only two use cases typical for developing elec-
lished means for the late phase of development tric vehicles. Of course many other use cases are
[22, 24]. inherited from conventional automotive develop-
However, such tests need expensive ECU pro- ment. Therefore we want to investigate:
totypes that often are not available at an early
phase of development. Moreover, basic software • which level of abstraction is actually re-
modules might not yet be implemented or ready quired in the early development stages of
for integration. Still, it would be interesting to electric vehicles
know, how the software components interact
with each other and/or with an already config- • how such a model of an ECU can be used in
ured basic software module like a diagnostic a methodology and tooling for simulation-
event manager. Thus, it would be great benefit based testing
if the simulation of the application software
in combination with available aspects of basic • and finally, how such an approach can be
software would be possible even when a real advanced, especially regarding the reuse of
ECU prototype is not at hand. This needs a models (e.g. environment models) and ide-
model of an ECU that adequately abstracts ally automated tests throughout the whole
its hardware and the missing basic software development process.
components. With such a model of an ECU it is
possible to use conventional PCs as simulation a For this purpose, the “Simulation-based De-
platform. A key difference to a HIL simulation velopment for Electric Vehicles” (in German:
is that the simulation is usually not done in Simulationsgestützter Entwurf für Elektro-
real-time. This means that a whole simulation ”fahrzeuge“ [Shortname E-Mobil“]) project was
”

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 2
set up. On the one hand it aims at finding the abstraction 1a 1b 2 3 4a 4b 5
most suitable ECU abstraction. On the other level
hand, we want to establish a proper tooling
that best fits the needs of the early development SWC p p p p p p s
stages. A recuperation scenario, which is a RTE p p p (s) s s
common test scenario in the electric vehicle BSW p p p (s) s
domain, is used for evaluation. This paper
presents our current research and the first results OS p p s (s)
(the project runs until October 2013). MCAL p p s
ISA s s
The following section will start with an
overview of how ECUs can be abstracted on the µ-arch. s
architecture level.
Table 1: The table shows if aspects are not considered
(empty), simulated (s) or if the production (p) imple-
2 State of the Art mentation is used in different levels of the architecture
abstraction of AUTOSAR ECUs.
2.1 ECU Architecture Abstraction
In section 1 it was already suggested that specific aspects. This is classified as the fifth
V-ECUs can be used to test both the application level of abstraction, which is depicted in the last
software and some of the non-application-related column of table 1. The software component
code without using the actual ECU hardware. (SWC) is simulated, but the model uses means
Therefore, the V-ECU must adequately abstract of computation that are different from the later
an ECU. The first question is to which degree the production code (e.g. it uses floating-point math
ECU can be abstracted. The second question is as opposed to integer math).
if a certain level of abstraction can be considered An example for a level five ECU abstraction is a
‘adequate’ for early stages of development. model of a controller in M ATLAB R /Simulink R ,
There is a trade off between a minimized level of which specifies the desired functional behavior
abstraction and the ability to simulate even if an of an ECU.
in-depth knowledge of the final hardware as well
as the final production code is not available. E.g., The simplest approach to analyze the func-
if the basic software is to be simulated on the tional correctness of the implementation of
lowest possible level of abstraction, the produc- the hardware-independent application software
tion basic software must be available as binary under test (SUT) is to execute it on the host CPU
object code. The most accurate simulation for of a standard PC running a common desktop
this would be a cycle-accurate simulation of operating system. Thus, platform-specific
the microarchitecture. This makes little sense if properties, such as computation time, can not be
the target hardware is not known and if not the considered.
whole ECU production code (the basic software For an open-loop unit test, it is enough to trigger
alone would not be enough) is available. If, on the application SWC and to access signals or
the other hand, the application software C code at least the elements of its interface. However,
is to be tested in combination with just one the typical purpose of an embedded system is
aspect of the basic software, like a diagnostic its interaction with an environment. Thus, to
event manager (DEM) on configuration level, a analyze the dynamic behavior of the application
much higher level of abstraction is needed. software, it is necessary to connect it to an
In a first step, we analyzed different levels environment model. Solutions exist that help to
of ECU abstraction. This section presents our connect the application software to environment
findings in the form of a classification. Two models. They also provide an interface to
things should be noted. First, we concentrate on access signals and to trigger the execution of the
abstracting AUTOSAR ECUs, which is required application software as well as the environment
in our project. Second, we remain on the model.
architecture level. Lower levels like the digital The standardization of application software
logic, circuit and physical implementation are components by AUTOSAR allows the for-
not considered, because they have no influence mal description of the software components’
on the development of the software. interfaces. Based on this software compo-
Each ECU abstraction is modeled on a certain
platform. In this context, a platform is charac- nent description and additional information1 ,
terized by an execution environment that offers the AUTOSAR methodology [2] enables the
an interface which hides implementation-specific automatic generation of glue code, which en-
details of the platform to the model (adapted closes the application software components. In
from [17]). For example, M ATLAB R /Simulink R AUTOSAR the glue code is called the Runtime
as a platform allows modeling functional behav- Environment (RTE). Besides generating code,
ior, using a graphical block diagram. In model- 1
based development, the analysis of the functional The RTE is generated based on the ECU configuration
behavior is done using a specification model, ide- description, which references the used software component
ally without the impact of any implementation descriptions.

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 3
tools like dSPACE TargetLink use the software the operating system is emulated by a model
component description to create an adapter to of a real-time operating system that has been
the execution platform automatically (level 4b designed in SystemC as well.
in table 1). This mechanism is used to embed
the software-in-the-loop-simulation of dSPACE [7] presents an approach to simulate only
TargetLink in M ATLAB R /Simulink R . In this the hardware, especially the microprocessor, of
SIL simulation the environment model is still an ECU (level 1 in table 1). This can be achieved
in M ATLAB R /Simulink R , while TargetLink in two different ways. One is the Instruction
generates a wrapper to embed the implemen- Set Simulation (ISS) where the instruction set
tation in M ATLAB R /Simulink R . If software architecture (ISA) of the target microprocessor
components depend on AUTOSAR services, is simulated (level 1b in table 1). The ISA
e.g. on the AUTOSAR NVRAM Manager includes native data types, instructions, registers,
to access non-volatile data, it is necessary to addressing modes, interrupts, exception handling
provide a simulation of the needed standardized and external I/O. The simulator is able to execute
AUTOSAR services (level 4a in table 1). How- the production binary object code of the ECU
ever, the triggering of the runnables is different software, including the operating system.
from the one of the target system, because there A Cycle Accurate Simulation (CAS) even simu-
is no simulation of the operating system on this lates the microarchitecture of the target process-
level. ing unit. This, as already mentioned in the intro-
To analyze the interaction of multiple runnables, ductory example, is the lowest level of abstrac-
a more precise triggering is required. This is tion (level 1a in table 1) that we consider in this
achieved by simulating the operating system classification. The CAS respects the exact tim-
of the ECU on top of a PC running a common ing behavior of the ECU, because it includes the
desktop operating system (level 3 in table 1). simulation of caches, pipelines, branch predic-
Operating systems of ECUs are standardized by tion and other details of the microprocessor.
the OSEK-OS [19] specification. The operating All of the presented levels of ECU abstraction
system module of AUTOSAR [3] is based on can be used for simulation-based testing. To act
OSEK-OS. Furthermore, there are solutions that as a link between early simulation of pure appli-
extend the simulation of the operating system cation software simulation and HIL simulation,
with I/O, especially automotive networks. This it would be advantageous, if the tests that are de-
is necessary to connect the ECU model to an veloped for early behavioral simulations, could
environment model. be reused across the different levels of abstrac-
tion. This ideally includes ‘level 0’ (the ECU
The following approach aims at emulating prototype) that is used later in the development
the hardware-specific layers (level 2 in table process. The next section gives an overview of
1), which is the operating system and the the current research situation on this matter be-
hardware-dependent microcontroller abstraction fore section 3.1 uses the presented classification
layer (MCAL) of the AUTOSAR basic soft- to find the most suitable ECU abstraction for our
ware. Here, the production code of all hardware- purpose. This essentially boils down to the ques-
independent basic software modules is used for tion, which of these levels are relevant for the
simulation. This means that the simulated early phases of electric vehicle development.
AUTOSAR basic software very much resembles
that of the real ECU.
Note that before the simulation can be run, it 2.2 Reuse of Tests Across Domains
is necessary to configure the whole AUTOSAR
basic software using valid parameters. In ex- To increase the benefit of using abstract mod-
change, this approach enables analyzing basic els of ECUs for early simulation-based testing,
software modules and their configuration in it is one major goal of our project to find ways
combination with the application software. This of modeling tests that can be used through dif-
approach can be realized both on consumer ferent levels of ECU abstraction (from the be-
desktop PCs and on a real-time prototyping havior specification to a real ECU) seamlessly.
platform to connect the I/O of the ECU model to This chapter presents some research that will
the real environment. help us to develop our own approach later in the
project. As a first step, we had a look at stan-
Other approaches simulate parts of the basic dardized ways of software testing. The interna-
software and hardware, particularly automotive tional standard ISTQB, for example, formulates
networks, in system-level design languages, like seven principles. Principle three suggests that
SystemC. In [14] the mapping of the AUTOSAR testing should be started as early as possible [6].
architecture on SystemC is described. This This supports our claim of frontloading tests us-
work is focused on modeling the timing of a ing ECU abstractions.
communication connection. [5] concentrates on The model with the highest level of abstraction
modeling the timing of a single ECU. The execu- (level 5 in table 1) is the first testable model
tion times were measured using a real evaluation in the development process. Here, the set of
board and then used in the simulation. In [4] possible faults is the smallest. Generally, it
the dynamic execution times are estimated by holds that the lower the level of abstraction, the
more information is required. This information
an extension of QEMU2 . In all this approaches, may not be defined in an early stage of the
development process. For example, an ECU
2
http://qemu.org/ of abstraction level 2 requires an in-depth

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 4
 representation of the values, e.g. a scaled integer
in a logical communication data unit, like a
binary CAN frame.
level 5 level 4 level 3 level 2 level 1 real ECU Finally, the real ECU is interfaced with real
analog or digital ports that are vulnerable to
physical effects such as electrical disturbances.
The diversity of platforms requires that the
reusable test has to be modeled in a way
granularity which is platform-independent. This platform-
independent specification of a test is called an
Figure 1: The granularity of abstraction different lev- abstract model of an test. Early approaches to
els of ECUs. model tests on a high abstraction level can be
found in [20] and [12]. In [20] test descriptions
are generated from a formal test specification,
with the focus on data abstraction.
knowledge of the configuration of the basic To execute these tests, they have to be mapped
software to enable the simulation of a concrete on a concrete platform. One way of describing
implementation. In exchange, a platform that such a mapping is given by [12]. This standard
models a low ECU abstraction level enables the defines the “Tree and Tabular Combined Nota-
detection of many more faults. These include tion”, which models data formats, behavior and
the faults that are introduced through adding interfaces on a high abstraction level and handles
more detail, but also those of higher levels of the mapping of interfaces to real systems.
abstraction. Figure 1 visualizes this relation.
Different platforms are suitable to analyze and One technique to model a test on a high
test different aspects of the target software. abstraction level in an platform neutral way is
presented by [9]. They use the unified model-
The transition to a model with a lower level of ing language (UML) to describe tests, which
ECU abstraction is an enrichment of details. To are used as a basis for generating a concrete
ensure the correctness of the additional details, implementation (e.g.JUnit tests). In a model
back-to-back testing is used. Back-to-back driven architecture (MDA), which is described in
testing means testing the model of higher the MDA Guide ([17]) a platform-independent
abstraction level and then testing the model of model (PIM) is described. This model focuses
lower abstraction level using the same test cases on the application behavior, which is platform-
and scenarios, including the same environment independent. The platform-specific model
model, and comparing the results. ISO 26262 (PSM) maps the PIM on a concrete platform. It
[13] recommends back-to-back tests for all auto- is furthermore the input for the generation of the
motive safety integrity levels (ASILs). dSPACE platform code. [25] combines the ideas of the
TargetLink already provides back-to-back tests abstract test modeling using UML ([9]) with the
of the model (level 5) and the application imple- philosophy of model-driven architecture. Here
mentation (level 4b). It is necessary to ensure they refer to an older approach presented by
that the implementation (level < 5) adequately [23]. Therefor, they introduce two different test
approximates the specification model (level models: the platform-independent test design
5). Remember that it may now be triggered model (PIT) and a platform-specific test design
by an operating system (level ≤ 3) or relies model (PST). Furthermore, they describe the
on input data provided by other components associated transformations. The basic idea is to
such as communication (level ≤ 4a). Finally, transfer a methodology, which is established in
it is necessary to test on the real hardware too, software development, to the development of
because there is currently no ECU abstracting tests.
model that represents all aspects of a real ECU.
Another approach is to formulate a test for
An ideal test system is able to apply the different levels of abstraction using a designated
same test to the behavioral model, to any other language. [10] presents such a test language
level of ECU abstraction and to the real ECU. called TestML. The goal was to exchange
If feedback from the output of the tested artifact testing systems between the behavioral model
through an environment model is needed, this (level 5), the implementation (level 4) and
means that the same environment model must the real ECU. They proved that a test case
be used in all test scenarios. For back-to-back formulated in that language could be run on
testing it is a further requirement that the tests a M ATLAB R /Simulink R model. There was no
can be reused on different platforms. This proof in this work that other platforms can be
increases the quality and flexibility of the test supported as well. However, we think that
case and reduces the costs of recreating them. this approach is promising. This is because
Each level of abstraction (table 1) uses its the language is formulated on an abstract test
own representation of values. The level of the system. They define this abstract test system to
behavioral model (level 5) uses physical values, consist of “a combination of test components
which are often normalized, but independent that [they] consider minimally necessary re-
of their technical representation. The software garding the exchange of test descriptions.” The
implementation levels use a concrete technical system is separated into three components: the

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 5
 Test Behavior

SUT

Stimulation Unit
Evaluation
Capture Unit Unit

Figure 2: Abstract test system as used in [10].

test itself, the system under test (SUT) and the inputs and outputs and using this information to
evaluation unit. Figure 2 shows an illustration of create a model in SysML. This representation of
their abstract test system. The stimulation unit the requirement creates a formal model in the
generates stimuli, but it does not yet contain any CIM. This could probably be used as reference
link to an environment model. The test behavior model to describe mappings of interfaces across
is described by hybrid automata that have been all levels of ECU abstraction and the real ECU.
described by [16]. They are able to model However, further research is required here.
timed applications and systems with discrete Fortunately, this section has shown that the
and continuous behavior. The capture unit is reusability of tests does not depend on the ECU
responsible for recording the system reaction model. Thus, there is no need for a special
and the stimuli. The verdict is provided by the requirement regarding the choice of a suitable
evaluation unit. level ECU abstraction in the next section.
Anyway, the key is the description of the inter-
faces between these components. They abstract
the necessary link between the SUT and the other
components. This means that every platform 3 Our Approach
only needs a mapping for the interfaces and not
necessarily the whole system. Thus, although 3.1 A Suitable ECU Model
the work did not mention any other supported
platform besides M ATLAB R /Simulink R , it Before we can answer the question of which of
seems that not much effort is required to extend the ECU abstraction levels presented in section
the support to other platforms. However, in 2.1 is most suitable for our purposes, we have
our project it is explicitly required to reuse to reflect upon the requirements we have to sat-
the environment model on different platforms. isfy. Our primary goal in the ‘E-Mobil’ project is
The TestML approach was not specifically to enable the simulation of application code be-
designed for in-the-loop tests. Here, it would havior under real ECU conditions in early devel-
be necessary to enhance the stimulation unit so opment phases. This first and foremost requires
it can hold an environment model. That is why a separation of the application-related and the
we intend to combine the platform-independent non-application related software running on the
approach of [10] with the model-based idea of ECU. Imagine the developer works in the appli-
[25] mentioned earlier. With such a system it cation layer. Ideally, it should not be necessary to
would be possible to reuse tests on all levels of care about lower layers like the operating system
ECU abstraction as well as on the real ECU. or network communication protocols. In early
However, the origin of such a test has not been stages of development, the developer has no or
addressed yet. The test is usually derived from only a little knowledge of those. In spite of that,
a textual representation of the corresponding the application software should be able to use ser-
requirement. The MDA Guide refers to this vices of lower layers as if they were already im-
as computation independent model (CIM) – “a plemented. This way, a high level of integration
view of a system from the computation indepen- can be achieved without the need for the final ba-
dent viewpoint.”[17]. These requirements are sic software. Furthermore, interaction between
usually managed in tools like IBM Doors. [11] several application software components should
shows, that it is possible to create a formal model be possible.
(SysML model) just from textual requirements. Another typical use case is that some configu-
Therefore the requirements must be given in a rations of the system architecture (e.g. a BSW
language that is natural but also restricted in module or a communication behavior) are al-
terms of vocabulary and grammar. This is com- ready known (but not fully implemented). It
monly known as controlled natural language. In should be possible that the application software
this special case a language called ‘requirement can be simulated in an environment that emulates
patterns’ is used. A requirement formulated these aspects.
in that language can be analyzed by extracting In both cases, there have to be well-defined inter-
a subsystem and function hierarchy including faces between the application software and the

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 6
non-application relevant software. 3 solution is sufficient here. Level 2 and level 1
The AUTOSAR standard [1] defines those inter- seem to be too close to the real ECU prototype,
faces. They are called basic software (BSW). as they assume a comprehensive knowledge of
Furthermore, AUTOSAR defines a layered and the final hardware and that a full configuration of
modular software architecture for ECUs. Re- the basic software is available.
garding section 2, this enables the simulation of Anyway, it appears that the virtual ECU (V-ECU)
the ECU on different levels of abstraction. presented by [21] satisfies our requirements. It
For closed-loop simulations, the ECU model allows a simulation of the application software
must provide means to connect to an environ- without the need to care about basic software.
ment model. However, if the developer is interested in real-
To use the simulation for testing, measurement istic task behavior and task triggering, he/she is
and calibration support is obligatory. This ap- able to configure the operating system and the
plies for both, the environment model and the RTE. Furthermore, the V-ECU provides an im-
ECU model. Here, the variable measurement of plementation of the AUTOSAR communication
the ECU model should be as close to that of the layer (COM) and services of an AUTOSAR basic
later ECU prototype as possible. software like a diagnostic event manager (DEM)
In summary the requirements can be formulated and an ECU state manager (ECUM), too.
as follows: In our opinion the V-ECU can act as a link
between the pure application software and the
• The ECU model should be able to include ECU prototype, between simulating the applica-
and simulate AUTOSAR application soft- tion code individually and a HIL simulation. To-
ware components (SWCs), so the model gether with the functional model, this results in
of the ECU must have an abstraction level four concrete model characteristics that an ECU
lower or equal than 4b. runs through. These are depicted in Figure 3.
One can see which aspects of the ECU can be
• It should be possible to simulate multiple tested on which model characteristic and what
SWCs on a virtual functional bus (VFB) type of simulation is used.
level. This requires an RTE simulation
which is able to connect multiple SWCs.
• To simulate the effects of communication 9174 81291 
5 5
between different application software com- 01234 01234 5123 8113
567879
0
ponents, an RTE implementation must ex- 38 9
ist that abstracts intra- as well as inter-ECU
communication. 471 0   
 32
• For the inter-ECU communication a bus
simulation as well as the simulation of the 9174+367*18
responsible BSW modules (COM Stack)
must exist. BSW modules are considered )3$38076
)512351*387$3
in abstraction levels lower or equal than 4a. 67 )51438
973
• To simulate realistic task behavior and task 3 32 )1!783,8963983
)782 783-1141$
triggering, the V-ECU must include an ).318/51971
AUTOSAR OS implementation, which re- 782 783
!!39 "#$#
quires an abstraction level not higher than 38638%&%
3'79$(
three.
• For open- and closed-loop simulation, the Figure 3: The virtual ECU in the context of
model must provide interfaces to an envi-
ronment model. These interfaces should be simulation-based testing.
either bus interfaces or signal interfaces that
mimic the later I/O of the real ECU.
The next section presents a suitable tool chain
• Services for experimentation, debug and that integrates these characteristics except the
test support should be included. The most ECU prototype and their corresponding simula-
important service is the XCP service that tion types.
complies with the ASAM MCD-1 MC stan-
dard.
3.2 Requirements for a Tooling
• It should be possible to analyze and simu-
late the application software with aspects of The main benefit of using V-ECUs in the con-
basic software that only require some con- text of developing electric vehicles lies in early
figuration (and no final implementation). simulation-based testing. Compared to a HIL
simulator that requires a close-to-production
ECU prototype, the virtual ECU allows for sim-
With these requirements in mind, it was obvious ulation even if many aspects of the production
that we need an ECU model that spreads across ECU are still unknown. This, as already men-
several levels of ECU abstraction (see section tioned in section 1, is especially beneficial for the
2.1). Yet, we found that on the lower end, a level development of electric vehicles.

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 7
However, both modeling and simulating the dif- sides. This bears a risk of tool gaps which
ferent levels of ECU abstraction (see section 2) must be bypassed.
when developing an ECU from scratch, as well as
the architecture and first non-functional aspects • The tool chain should allow for model-
demand a good tooling. Our observation is that based or at least model-driven design and
although the application field of many commer- development. This, despite the fact that
cially available tools is expanding continuously, there is still plenty of hand-written code
there will not be a single tool handling all these even in recent ECUs, is imposed by the
aspects adequately in the foreseeable future. In- growing complexity of automotive software
stead, there is always quite a number of special- paired with high safety standards. Further-
ized tools that form a dedicated tool chain. These more, it enables changes on a prototyping
tools’ capabilities are employed by the domain basis.
they are used in. We see domains as separate
groups of developers that, due to their particu- • The tool chain should assist handling
lar task in the development process, are special- the general problem of how true univer-
ized in different areas and therefore have differ- sal tests that originate from requirement
ent technical knowledge and orientations. For the management tools (e.g. DOORS) can
early stages of development we consider mainly be used across domains. This means
three domains involved: The function developer that one test can be performed on a
domain, the software architect domain and the M ATLAB R /Simulink R model, on a V-ECU
tester domain. A function developer usually has and ideally even on a real ECU, for exam-
a very different background than a software ar- ple.
chitect. The former focuses on mathematical
modeling of control algorithms whereas the latter The next section shows how we plan to satisfy
is specialized in software development. Hence, these requirements. Therefore, we use state-
our goal is to establish a methodology across of-the-art tools within a tool chain that extends
the named domains and an adequate simulation- across multiple domains.
based tool chain that is particularly well suited to
design, implement and test software for electric
vehicles in early development stages. As a con- 3.3 The V-ECU Simulation Tool Chain
sequence, we impose certain requirements:
In order to meet the requirements presented in
section 3.2 we first established a basic tool chain
• Every domain should be able to use sim- that will be continuously enhanced throughout
ulation. This ranges from open-loop sim- the project. For this purpose, it is going to be
ulation using simple stimulation to in-the- used by us and our project partners to implement
loop simulation using a designated environ- a scenario, that is characteristic for electric
ment model as a means for validation, test- vehicles. We chose a recuperation scenario as
ing and/or optimization. In this context it is recuperation is a key feature of electric vehicles.
important to note that an environment model Our project partners will represent the members
can be (re-)used across multiple domains of the different domains. This allows us to
(and therefore across different tools). evaluate the tool chain, especially regarding
unexpected use patterns and tool gaps. In the
• The tool chain should provide means for ex- following it is explained how this tool chain can
perimenting and testing these early artifacts be used and how we plan to further enhance it.
in an environment that is commonly used in
HIL scenarios. This allows frontloading of In the beginning the function developer designs
tests as described in section 1. the first behavioral models as a specification us-
ing M ATLAB R /Simulink R , which can be seen in
• The tool chain must handle AUTOSAR- the upper third of figure 4. He or she uses model
compliant software. AUTOSAR facilitates in-the-loop (MIL) simulation for validation (also
the exchange of the software components compare with the first column of figure 3 in
between tools and domains and furthermore section 1). Therefore an environment model has
separates the functional aspects (application to be created. Our environment models are based
software) from the non-application relevant on the dSPACE Automotive Simulation Models
aspects (RTE and basic software). (ASMs). These already include a multi-body
system of a car, customizable maneuvers, roads
• The tool chain should feature tool-assisted and ready-to-use models of electric components.
transitions beyond tool boundaries and be- Due to the fact that these models are actually
tween the three domains mentioned above. intended for real-time simulations in a HIL con-
This includes the reuse of artifacts across text, they offer good performance. Another big
multiple domains (e.g. the plant model) advantage is that they can be easily parametrized
as well as an appropriate model conver- using the GUI-based parametrization environ-
sion/import/export. For example, between ment ModelDesk. Furthermore, it is possible to
the function developer and the system ar- add own models to the ASMs and parametrize
chitect there is a point of contact where them in ModelDesk as well.
the controller functionality gets integrated
into the AUTOSAR-compliant architecture. After the behavior and the environment have
Here, we have domain-specific tools on both been modeled, the former must be transformed

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 8
 0123456289
969 6899 5152  9452
952
)9
56
99244562 *689+
24689952
2468999244562
24689
012345625249 46 *5,9,+
49 354934 499 
6!4" 9 3549341 9 .%& 93 54562
# 8" 9666 
$94"6 612534562 689
%&62!51 4562
'%(929 4562

2!!5295146 .%& %29

5 2642

949 624 69 14645629

%-9 59244562 645629
0123456289)152
 94562286526!146453494
.515/4562

49-329*0!5956 419-6 4+6

24 6492!
!5295146 *4 43464+
91 9924335) 4562*.%&324+

Figure 4: The three main domains and the tool chain.

into actual code. The transformation into an domains is one major requirement for universal
implementation model can be done automat- tests. A more detailed analysis is given in section
ically by tools like TargetLink. Therefore, 2.2.
it converts the Simulink blocks into special
TargetLink blocks. It should be noted though Alongside the functional models, the sys-
that not all Simulink blocks can be converted, tem architecture is being designed or adapted to
as the code generation and production-capable facilitate the integration of the application code.
ECU code itself by nature imposes certain This is depicted in the middle of figure 4. Note
limits. Here, the function developer has to that no chronological order is implied here: e.g.
keep in mind that through this transformation, the function developer and the system architect
continuous models will be discretized with both can start at the same time.
regard to constants, interim results and signal The system architecture includes the software
data that are now represented as integers instead component frames (ports, interfaces), the config-
of floating-point numbers. Not to mention the uration of runnables and any (re-)configuration
fixed-step nature of the solving mechanism itself. of non-application-relevant aspects (RTE, basic
software, the network communication, ...). Note,
After the implementation model is gener- that we distinguish two use cases here: On the
ated, the software developer has to configure bit one hand the creation of a system architecture
widths and scalings. However, this normally de- from scratch which is used as a starting point for
pends on the target hardware (e.g. an 8-bit ECU the simulation of functional code together with
or a 16-bit ECU) which might not be known non-functional code, on the other hand the inte-
at that time. Hence, the software developer gration of new (or modified) function code into
could just use any configuration that sufficiently an existing V-ECU topology. Both use cases
approximates the functional model. are common for the early development stages of
With the generated production code, the electric vehicles and both appear to be complex
function/software developer can use software tasks. In our project we use SystemDesk to assist
in-the-loop (SIL) or, if a PIL device is available, the system architect in that matter. SystemDesk
processor-in-the-loop simulation, also seen in was created with system architectures in mind
the second column of figure 3 in section 1. The and is especially targeting AUTOSAR-compliant
new behavior is compared with the results from architectures. It supplies the user with the means
the earlier MIL simulations. Note, that the plant to compose AUTOSAR software components
model is not affected by the code generation. with ports and interfaces and the respective data
In fact, the plant model being available to all elements in a model-driven fashion.

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 9
The software components can be mapped on the Nevertheless, there are some challenges that
modeled ECUs. Then the OS as well as other ba- have yet to be addressed. When a system is
sic software (BSW) modules like the COM mod- created from scratch, many aspects of the ar-
ule can be configured. Furthermore, the network chitecture such as the actual interfaces between
communication (IPDUs and signal mapping) and software components are still unclear due to the
an automotive bus can be modeled. The code for fact that some requirements may change later.
the AUTOSAR Runtime Environment that acts The system architect then needs the function
as a communication center for inter- and intra- developer to adapt the models to the new inter-
ECU information exchange on a logical level can face to obtain an updated implementation. This
be generated automatically. presupposes that the architectural changes are
Out of this data SystemDesk generates the propagated into the M ATLAB R /Simulink R model
V-ECU executable, which can be simulated with as well.
the dSPACE Offline Simulator. The Offline Sim-
ulator can simulate several V-ECUs in combi- The last part of the tool chain are the ex-
nation with an environment model. The latter perimentation and testing tools, which can be
originates from M ATLAB R /Simulink R , where it seen on the lower third of figure 4. The V-ECU,
has automatically been converted into a simula- like a real ECU, supports measurement and
tion executable. The simulation is performed on calibration according to the ASAM MCD-1 MC
a standard PC. As already mentioned in section (XCP) standard. This means that ASAP2 files
1, the V-ECUs are not simulated in real-time but (according to ASAM MCD-2 MC standard)
as fast as possible on the underlying PC hard- are used to describe the mapping of the vari-
ware. Note that the simulation speed often only ables. This is important, as common HIL test
depends on the environment model, which usu- and experimentation tools need these variable
ally uses much more computation time compared descriptions. For measurement and calibration,
to the ECU code. ControlDesk Next Generation is used. Auto-
matic testing is done using AutomationDesk.
The Offline Simulator is depicted between the MotionDesk is used for plausibility tests as it
system architect domain and the tester domain renders the simulated ASM model as a 3-D
on figure 4. A detailed description of how tools animation. Furthermore, ControlDesk Next
like SystemDesk enable the user to integrate the Generation and AutomationDesk both support
existing software into a V-ECUand how they the Offline Simulator. The Offline Simulator
are simulated with the Offline Simulator can be in turn can simulate V-ECUsand models orig-
found in [18]. inating from M ATLAB R /Simulink R . Hence,
experimentation and testing across multiple
Certain questions that arise are: How can domains is possible.
the function developer create the ECU functions
according to the structure and interfaces that
are developed in the system architect’s domain?
How, on the other hand, can the system architect 4 First Results and Future Plans
be sure that the functional code will fit into the
prepared V-ECU? How does the environment The project is still quite at the beginning. In the
model get integrated into a simulation with a first stage of the project we mainly concentrated
V-ECU topology? A transition between both on the function developer domain. Together with
domains as mentioned in section 3.2 must be our project partners, the first behavior models for
realized. The answer is quite easy for the the recuperation scenario were created. At the
environment model. As mentioned earlier, it same time, after having established the method-
can be automatically converted into a simulation ology and requirements presented in section 3.2,
executable, which can be simulated with the some tool enhancements have been created.
Offline Simulator. Also, it is possible to connect Until now, the main focus laid on the transi-
the environment model with a designated port tion between the function developer and the
on a V-ECU. However, the transition of the system architect domain. There, we developed
system architecture is not that easy. A simple a concept and a prototype implementation
exchange of AUTOSAR files is not enough. The for an update functionality of the model gen-
function developer might lack a certain expertise erator that creates a TargetLink subsystem
when it comes to AUTOSAR. What he or she (M ATLAB R /Simulink R model blocks) from
needs is a representation of the SWC frame as an AUTOSAR description. Here we link the
a TargetLink frame that somehow includes the AUTOSAR data with the related TargetLink
necessary structures mapping to the correspond- blocks so that the implementation model is
ing sender/receiver or client/server data access ‘aware’ of its underlying AUTOSAR architec-
points. TargetLink offers a data dictionary that ture. One challenge here is, for example, to
imports and stores the AUTOSAR information. establish the link so that it is robust against
It provides mechanisms to create a frame of changes in both the TargetLink subsystem and
model blocks that already has the appropriate the AUTOSAR description. Furthermore, there
ports and signals set up. The function developer should be no need for additional files besides
only needs to put in the functionality for which the AUTOSAR description and the TargetLink
the code is to be generated. The code generation model that have to be transported across do-
of TargetLink implements the RTE calls accord- mains. We expect the update functionality to be
ing to the system description. This way it can frequently used (and therefore evaluated) during
easily be integrated by the system architect. the next months when the behavioral control

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 10
models (energy management, engine control, Last, but not least, we presented the first results
brake control) are transformed into V-ECUs. and provided a glimpse of our plans for the up-
Besides that, we have already started to develop coming project phase.
means to ease up the work of a system architect
and increase the value for offline simulation
by introducing first concepts of new ways to
analyze an AUTOSAR-based V-ECU topology. Acknowledgments
Simultaneously, further research will be done on
easing up the configuration of V-ECU topologies The presented work is funded by the Euro-
paired with a consequent use of model-driven pean Union and the state of Nordrhein-Westfalen
design principles. Our goal here is to reduce (grant No. 64.65.69-EM-1008A). The project is
the time needed to create configurations ready conducted together with the University of Pader-
for simulation that enables the development born and the DMecS GmbH.
and modification of V-ECU topologies on a
prototyping basis.
Furthermore, the field of reusability of tests References
across domains will be addressed in detail. The
final goal here is to allow for the definition of [1] AUTOSAR (automotive open system architec-
tests on a semantic basis that can be executed on ture). http://www.autosar.org/.
various platforms. Even though the requirements
that form these tests are expressed as natural [2] Autosar. AUTOSAR Methodology, 2008.
text, e.g. in DOORS, they are in the view of the
computation-independent model. We hope to use [3] Autosar. Specification of Operating System, Oc-
these findings to create links between test cases, tober 2010.
environments models, implementation artifacts
and requirements going beyond traceability. [4] Markus Becker, Henning Zabel, and Wolfgang
Finally, we plan to implement the means to Mueller. A Mixed Level Simulation Environ-
create reusable tests and enable our project ment for Stepwise RTOS Software Refinement.
partners to evaluate them. Technical report, University of Paderborn/C-
At the end of the project, together with our
project partners, we are going to have a run- LAB, 2010.
ning demonstrator for the recuperation scenario.
Here, the control functionality will be realized as [5] Markus Becker, Henning Zabel, Wolfgang
a V-ECU and will be simulated together with en- Müller, and Ulrich Kiffmeier. Integra-
vironment models from M ATLAB R /Simulink R in tion abstrakter RTOS-Simulation in den En-
an offline simulation environment. As stipulated twurf eingebetteter automobiler E/E-Systeme.
in section 3.2, HIL test tools will be used for In Methoden und Beschreibungssprachen zur
evaluation. Furthermore, we aim at testing some
of the control functionality on a prototype device Modellierung und Verifikation von Schaltungen
against a real test bench. und Systemen, Berlin, Germany, March 2009.
[6] International Software Testing Qualificytions
Board. Certified Tester - Foundation Level Syl-
5 Conclusions labus, 2011.
In this paper we presented our research regard- [7] Mikaël Briday, Jean-Luc Béchennec, and Yvon
ing the early simulation and testing of virtual Trinquet. Modelisation of a Distributed Hard-
ECUs for the development of electric vehicles.
We started with a brief presentation of the idea ware System for Accurate Simulation of Real
behind virtualizing ECUs and presented a classi- Time Applications. In Proceedings of 5th IFAC
fication of recent approaches. International Conference on Fieldbus Systems
We then formulated the requirements and as- and their Applications (FeT’03), july 2003.
sumptions on the V-ECU itself as well as on a
possible tool chain that allows frontloading of [8] Rainer Dömer, Andreas Gerstlauer, and Wolf-
tests which usually can only be performed in later gang Müller. Introduction to hardware-
HIL setups. We identified the domains involved dependent software design hardware-dependent
and their points of contact.
These considerations lead to the methodology software for multi- and many-core embedded
and tool chain described in section 3.3 that we systems. In Proceedings of the 2009 Asia and
use as basis for our project. Here we examined South Pacific Design Automation Conference,
where the tool chain can be further enhanced to ASP-DAC ’09, pages 290–292, Piscataway, NJ,
avoid tool gaps and to accelerate the development USA, 2009. IEEE Press.
process in early stages of development.
Particular attention was paid to reuse of tests [9] Hans-Gerhard Gross. Testing and the UML. A
across domains. It has been shown that there are
already promising approaches that we will fol- perfect fit. Technical report, Frauenhofer Institut
low to allow for the creation of tests for various für experimentelles Software Engineering, Oc-
platforms. tober 2003.

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 11
[10] Jürgen Grossmann, Ines Fey, Mirko Con- Dr. Ulrich Kiffmeier. Durchgehende Systemver-
rad, Alexander Krupp, Wolfgang Müuller, and ifikation im Entwicklungsprozess. ATZ - Auto-
Christian Wewetzer. TestML – A Test Ex- mobiltechnische Zeitschrif, 4:298–307, 2007.
change Language for Model-based Testing of
[22] Herbert Schuette and Peter Waeltermann.
Embedded Software. In Proceedings of Automo-
Hardware-in-the-Loop Testing of Vehicle Dy-
tive Software Workshop ’06, Oct. 2007, October
namics Controllers – a Technical Survey. In
2007.
2005 SAE World Congress, 2005.
[11] Jörg Holtmann, Jan Meyer, and Matthias Meyer. [23] Jon Siegel and Object Management Group. De-
A Seamless Model-Based Development Process veloping in OMG’s New Model-Driven Archi-
for Automotive Systems. In Software Engineer- tecture. 2001.
ing 2011 - Workshopband (inkl. Doktoranden-
symposium), 2011. [24] Peter Wältermann. Hardware-in-the-Loop : The
Technology for Testing Electronic Controls in
[12] ISO. Information technology – Open Systems Automotive Engineering. Translation of the 6th
Interconnection – Conformance testing method- Paderborn Workshop in Designing Mechatronic
ology and framework – Part 3: The Tree and Systems, 2009.
Tabular Combined Notation (TTCN), 1992.
[25] Justyna Zander, Zhen Ru Dai, Ina Schiefer-
[13] ISO. ISO 26262-6: Road vehicles – Functional decker, and George Din. From U2TP Models to
safety – Part 6: Product development at the soft- Executable Tests with TTCN-3 - An Approach
ware level, 2011. to Model Driven Testing. In TestCom2005,
[14] Matthias Krause, Oliver Bringmann, and Wolf- 2005.
gang Rosenstiel. Verification of AUTOSAR
Software by SystemC-Based Virtual Prototyp-
ing. In Rainer Dömer Wolfgang Ecker, Wolf-
Authors
gang Müller, editor, Hardware-dependent Soft- Lars Stockmann received his de-
ware - Principles and Practice. Springer, 2009. gree in computational visualistics
in the university of Magdeburg.
[15] Karsten Krügel and Klaus Lamberg. Virtuelle After that, he worked three years as
Steuergeräte als Grundlage einer frühzeitigen a developer of audio related appli-
Absicherungsstrategie. Contribution to the 2nd cations for mobile devices.
Workshop “Automotive Software Engineering: In 2011 he joined dSPACE and
Virtuelle Absicherung”, February 2011. since the beginning of 2012 works
[16] Eckard Lehmann. Time partition testing: sys- as technical project manager in the
tematischer Test des kontinuierlichen Verhal- research project “E-mobil”.
tens von eingebetteten Systemen. PhD thesis,
Dominik Holler received his de-
TU-Berlin, Berlin, 2004.
gree in computer science from the
[17] Joaquin Miller and Jishnu Mukerji. MDA Guide University of Kassel. Now he
Version 1.0.1. OMG, 2003. works as a concept software devel-
oper at dSPACE since 2011. His
[18] Oliver Niggemann, Anne Geburzi, and Joachim particular research interest is the
Stroop. Benefits of system simulation for auto- reuse of tests in the software devel-
motive applications. In Proceedings of the 2007 opment process.
International Dagstuhl conference on Model-
based engineering of embedded real-time sys- Dr. Dirk Spenneberg worked at
tems, MBEERTS’07, pages 329–336, Berlin, the dSPACE as project manager for
Heidelberg, 2010. Springer-Verlag. the AUTOSAR architecture tool
SystemDesk from 2008 till the end
[19] OSEK/VDX. Operating System, February of 2011. Furthermore, he was one
2005. of the initiators and leading coor-
[20] T. J. Ostrand and M. J. Balcer. The category- dinator of the research project “E-
partition method for specifying and generating Mobil”.
fuctional tests. Commun. ACM, 31:676–686, He now works as a project manager
June 1988. for Bombardier Transportation.

[21] Dr.-Ing. Rainer Otterbach, Dr. Oliver Nigge-

mann, Joachim Stroop, Dr. Axel Thümmler, and

EVS26 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 12