Building Virtual ECus QuiCkly and EConomiCally

Developing transmission software for mass production requires high quality

standards for software functions and implementing them in source code. To achieve

these standards, comprehensive verification and validation is needed. While it is essential

for a dedicated test team to test the resultant software, the developers also need to conduct function

tests. Beside HiL-systems developers use Software-in-the-Loop (SiL). The tool Silver runs tests of this kind on the

developer’s PC without additional hardware and permits source-code debugging if access to the source code is

available. IAV describes, how to build a virtual ECU required for such SiL simulations quickly and economically.

48

Development SofTWArE

eCU Software

Basic software in an ECU serves as an abstraction layer between function software and ECU hardware, ❶. The basic software contains the real-time operating system (RTOS) and its services as well as a driver layer for accessing the ECU hardware and connected bus systems.

Apart from providing hardware access through appropriate driver layers, an embedded operating system (OS) has the main purpose of executing software functions, so-called tasks, either following a fixed rhythm or whenever a given event is detected. Deadlocks caused by wrongly timed access to certain resources must be prevented. Other services, like boot loader, reset on excep-tions and Eeprom access, are also implemented by the OS.

OEMs still use a diverse range of systems from various suppliers despite intensive attempts to standardise embedded software [1]. A trend toward assigning sole responsibility for basic software to the ECU supplier and sole responsibility for the function software to the OEM has been noticeable for a number of years now.

the virtUal eCU anD Silver BaSiC Software

A clear distinction between function software and basic software makes it possible to exchange the basic software and simulate the underlying hardware, ❷. The foundation for this is produced by virtualising the ECU, thus creating a development platform on the laptop for the function and software developer. Moving development and test tasks into the virtual environment provides a number of methodological advantages: : decoupling and parallelising large development teams across

departments or even organisations : duplicating and backing up a specific development status

simply and inexpensively

Dr. anDreaS JUnghannSis Managing Director of QTronic

GmbH in Berlin (Germany).

rolanD Serway is Head of the Algorithms and

Software Department in the Transmission and Hybrid Systems

Division at IAV in Berlin (Germany).

Dr. thomaS lieBezeitis Algorithm Developer at IAV

in Berlin (Germany).

mirCo Boninis Algorithm Developer at IAV

in Gifhorn (Germany).

AUTHorS

Function software

Basic software

ECU

RTOSRTOSservice

Processor

RAM Eeprom

Har

dwar

eS

oftw

are

Drivers

Input/Output CANPowersupply

❶ real ECU and basic software in car

4903I2012 Volume 7

: separately validating individual changes to the software without the influences of other often independent changes by other developers

: using efficient methods of desktop debugging for embedded software,

to name just the most important points.Virtualising function software has been

one of QTronic GmbH’s business activities for a number of years now. Virtual ECUs are produced that are linked on the Silver co-simulation platform with complex plant models to create closed-loop systems that provide the basis for performing typical engineering tasks. Silver provides the capa-bility of flashing a virtual ECU of this type with production parameter sets, measuring and calibrating with CCP/XCP-based MCD tools (such as Inca, CANape or CALDesk), stimulating with field data and much more besides [2].

Repeated virtualisation of function soft-ware has led to a large set of re-usable libraries now largely available to QTronic customers in the form of Silver Basic Soft-ware (SBS): as part of Silver, documented and including examples.

implementation of a virtUal eCU

These general SBS libraries provide the basis for virtualising an ECU. SBS func-tions are used to replace function calls from the function software into the origi-nal basic software or to implement hard-ware aspects of the ECU with a few lines of C code, ❸.

Using SBS, a distinction is drawn between two main phases: configuration and use. SBS is configured during runtime unlike generative approaches that generate, compile and link off-line and only then run. This provides the user with the capa-bility (but not the necessity) at the start of runtime of significantly influencing the behaviour and even the interfaces of an SBS-based virtual ECU from run to run without the need for recompilation. Inter-face descriptions and other configuration data are interpreted while such a flexible virtual ECU is running. A run-time config-urable ECU of this type has a longer life expectancy than ones generated off-line and reduces communication necessary between development partners.

Reduced to a minimum, the following example illustrates how to virtualise func-tion software using SBS. It is based on a

software-in-the-loop simulation of trans-mission function software for a dual-clutch transmission IAV developed for a customer [3]. The example has been drastically simplified to aid understanding and is far from reflecting the complexity of IAV's customers’ ECUs. All statements made, however, also apply to real-life configurations.

❹ and ❺ illustrate implementation of the virtual ECU using the source code written by the SiL engineer. The sources are structured as: SBS configuration, the Silver compute function, which is exe-cuted once per macro step, and simula-tion of the Bios functions.

The first lines of the example show how to configure SBS scheduling by using two tasks with cyclic calls of 10 ms each. Both are started at a 0 to 1 change in an enabler Silver variable signal, one immediately, the other after a 5 ms delay. This methodology

can be used for configuring even complex scheduling algorithms quickly and easily.

Input and output variables are config-ured using a similar SBS function that links Silver variables with global variables in the function software. Such a link ensures that SBS copies variable values from Silver into the function software variable or vice versa at the right time, with correct scaling using gain and offset, possibly specified, manually or reused from an A2L file. That means: a single line of source code is sufficient to connect a function variable correctly with the rest of the simulation in Silver.

SBS furthermore emulates a standard CAN stack. CAN messages can be defined as individual messages or entire DBC. In the latter case, specifying the name of the network node declares exactly which messages are received or sent. This is yet another example of how to reduce the

Silv

er c

onfig

urat

ion

Environment model

Silver

Virtual ECU

Function software❷ function software in SiL simulation using Silver

Function software

Silver

Environment model

Silver basic software

Virtual ECU

Scheduler IO

Eeprom

Virt

ual h

ardw

are

Sof

twar

e

CAN MCD

Input/Output CAN Power supply

❸ Virtual ECU and Silver Basic Software in SiL simulation

Development SofTWArE

50

con�guration overhead drastically by reusing existing �les with declaration information.

The CAN is connected to the function software by simulating the relevant Bios functions (Bios_RX_CAN). Individual CAN signals are accessed in the substi-tute BIOS methods, once again using SBS functionality [4].

ECU resets are emulated using SBS_EXEC_Reset that can be triggered by evaluating the terminal signals provided as Silver variables. In this project, this function is called when speci�c environment signals from Silver indicate absent battery voltage. A few lines of C-code make it possible to test the function software’s resetting robustness (e.g. in the event of a fault).

When building a virtual ECU, the user is never forced to use SBS functions only. In our application case, the Eeprom was accessed using a text �le because SBS does not yet support access to non-volatile memory. However, custom implementa-tions of this type usually require more effort than using SBS functions.

Silver comes with a specialised, easily con�gurable build program (cbuild) that supports users in creating a virtual ECU as a Silver module DLL from extensive source code and library bases by search-ing directory structures, compiling C �les and linking all objects and libraries found.

The resultant DLL then contains the function software as well as the virtual ECU. Silver also provides the capability of patching the target A2L �le to �t it to the Silver module DLL. Using the patched A2L, ASAP/MCD-based tools can then measure and calibrate the virtual ECU in just the same way as can be done in the vehicle or on the HiL.

The ECU is virtualised only once for each project. Changes in the function software can usually be compiled with the same virtual ECU. The SBS con�guration must only be changed once SiL-relevant modi�cations are made at the interface to the basic software. This also means that creating virtual ECUs ideally falls within the responsibility of a software developer. Function developers then use the result-ant build process for their everyday work.

CONCLUSIONS AND OUTLOOK

SBS gives years of development experi-ence to users of Silver and provides an

ef�cient and elegant basis for linking function software with a virtual ECU. Adding plant models from a wide range of simulation tools also brings system responses to life and provides the means for testing such. The IAV example shows that Silver users can virtualise their ECU code on their own with little effort.

This means SBS helps to improve the cost-bene�t ratio for SiL-based development tasks even further. This approach meets the understandable wish to achieve a capability of further front-loading testing and validation for closed-loop systems in an economical way.

QTronic is planning to integrate more Bios services into SBS, e.g. Eeprom access and error-code handling, helping to simplify virtualisation even more. IAV

will use these improvements for the bene�t of its customers by giving them an early and ef�cient means to validate the ECU functions they develop.

REFERENCES[1] Chrisofakis, E.; et. al.: Simulation-based development of automotive control software with Modelica. 8th International Modelica Conference, 20-22.03.2011, Dresden, Germany[2] Liebezeit, J.; Bonin, B.; Serway, R.; Bräuer, A: Virtual ECUs for developing automotive transmis-sion software: 10th CTI Symposium Innovative Fahrzeug-Getriebe Hybrid- und Elektro-Antriebe, 5.-8.12.2011, Berlin, Germany[3] Liebezeit, J.; Bonin, B.; Serway, R.: Software-in-the-Loop using virtual CAN busses. Current solutions and challenges, 5. Tagung Simulation und Test, 10-11.05.2012, Berlin, Germany[4] Liebezeit, J.; Serway, B.: Software-in-the-Loop using virtual CAN busses. Current solutions and challenges, 5th Simulation and Testing symposium, 10-11.05.2012, Berlin, Germany

❺ C code of virtual ECU (continued)

❹ C code of virtual ECU

5103I2012 Volume 7