See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/257281387

Function and software development for ECUs

Article in ATZelektronik worldwide · November 2008

DOI: 10.1007/BF03242195

CITATIONS READS

6 3,330

2 authors, including:

Ulrich Lauff
Vector Informatik GmbH
39 PUBLICATIONS 108 CITATIONS

SEE PROFILE

All content following this page was uploaded by Ulrich Lauff on 20 September 2016.

The user has requested enhancement of the downloaded file.

COVEr STOry Autosar

Function and Software

Development for ECUs
Mechatronic systems comprise a substantial segment of the feature and function set of modern automobiles. The
cost efficient implementation of intelligent functions, both within and beyond the domains of powertrain, chassis,
and body, is accomplished with the aid of electrics, electronics, and software. Autosar supports the reuse of soft-
ware indigenous to these systems. Besides providing an overview of the system levels that determine the behavior
of complex vehicle functions, this article by Etas also discusses the deployment of methods and tools in the inter-
working development of ECU functions and software.

10 ATZelektronik 06I2008 Volume 3

1 Introduction and generator, transmission and energy The Authors
consumption are simultaneously inter-
As a function of the rising demands on linked and jointly controlled [2].
modern automobiles’ convenience, safety, Dr. Matthias Klauda
and environmental compatibility, the is CEO of Etas
number and complexity of electronically 3 ECU Software – Major Trends and GmbH in Stuttgart
implemented vehicle functions, are stead- Challenges (Germany).
ily increasing. Today’s midsize cars fea-
ture some 40 electronic control units In its function as a central system compo-
(EUs), all of which are interconnected by nent, ECU software must be of high qual-
onboard data buses. Modern engine con- ity, and – concurrent with a system’s life- Dr. Ulrich Lauff
trol modules process up to 250 MIPS (mil- cycle – it must be upgradeable over a is Technical Editor-in-
lion instructions per second); these may long period of time. The software must Chief for Software En-
contain upwards of 20,000 function pa- be adaptable to various system variants gineering, Measuring,
rameters required for adjusting engine and vehicle types. To this end, software Calibration, and ECU
management functions. The same magni- functions are parameterized in such a Diagnostics in the
tude applies to the volume of code on- manner that the greatest possible Marketing Department
board the ECU, the logical core of all con- number of software applications can be of Etas GmbH in Stutt-
trol functions. This, in turn, increases the facilitated by virtue of the adaptation (or gart (Germany).
software’s share in the overall vehicle calibration) of characteristic values. To
price. This makes automotive software a master the sheer number, scope, and
product of strategic significance for both variants of these functions, ECU software
automakers and system vendors [1]. is divided into logical components that
lend themselves to being reused due to
quality and efficiency considerations.
2 Vehicle Systems Frequently, the development of new
functions and their attendant ECU soft-
Automobiles and their internal systems ware is an effort shared by workgroups
are characterized by high reliability, low coming from different domains and be-
manufacturing costs, and long product longing to different companies. The in-
lifecycles. At the same time, the most di- creasing workload distribution and
verse vehicle types and model variants, globalization of development processes
ranging from luxury class vehicles to calls for standardized software architec-
mini-compacts, are concurrently devel- tures and methods, as well as powerful
oped and distributed. The main objective tools and processes.
of platform strategies devised by manu-
facturers and system vendors is the high-
est possible degree of reusability of sys- 4 Autosar – a New Standard
tems or system components in a variety of for Software
vehicle models. The way in which elec-
tronic controls are developed depends on In 2003, industry efforts aimed at stand-
functional demands on the one hand, ardizing the software for electronic con-
and on commercial and technical specifi- trol systems under the motto “cooperate
cations – including the availability of in- on standards, compete on innovation”
stallation space – on the other. Additional led to the founding of the Autosar devel-
functions can be implemented through opment partnership (www.autosar.org).
system networking. In the case of predic- Its more than 100 members are jointly
tive brake assist (PBA), for “EXAM” ple, the working toward defining a uniform soft-
distance from the preceding vehicle is ware architecture for electronic control
measured by the radar sensor of an adap- units, and toward standardizing a con-
tive cruise control. This data is evaluated sistent development methodology.
by the braking system, enabling it to pre- Within the three layer architecture,
pare for emergency braking in case of the application software – containing
danger. There is also a growing trend to- the open-loop/closed-loop and diagnostic
ward the deployment of central system algorithms – is encapsulated in separate
controls in previously independent do- components that communicate through
mains. In a hybrid vehicle, for “EXAM” Autosar conformant interfaces. All com-
ple, IC engine and electric motor, brake munications between software comnents

ATZelektronik 06I2008 Volume 3 11

C ove r sto r y Autosar

Figure 1: Analysis, specification, implementation, and integration of functions and software in vehicle electronics

– whether within the ECU or ECU net- implementation of ECU software, is describes and analyzes vehicle electron-
work, or with sensors and actuators – is based on the definition of functions to ics and software functions subsequent
handled on the central layer, the so- be implemented in the software. Func- Autosar conformant implementation.
called runtime environment (RTE). The tion development normally occurs in The implementation of system require-
RTE serves as the interface to the basic three steps: Following Step One – an ments in terms of features, reciprocal
software, which provides communica- analysis of the requirements for an ap- effects, and variants can thus be tracked
tion and diagnostic protocols, drivers, plication, such as an engine control across the various levels [3]. The devel-
the microcontroller’s operating system unit, Step Two specifies the individual opment of functions and ECU software
(OS), as well as system services in the open-loop/closed-loop control and diag- avails itself of tools offered by tool ven-
form of software modules with standard- nostic functions, such as injection or dors such as Etas. While the discussion
ized interfaces. ignition. Step Three consists of map- below makes reference to applications
Autosar uses this basic architecture to ping individual function algorithms, of Etas tools, no claims of exclusivity or
define methods for the ECU independent like the load dependent calculation of completeness of descriptions given are
design of software components at a logi- the firing angle, Figure 1. The software expressed or implied.
cal abstraction level, the so-called virtual integration process converts and en- The “ASCET” function and software
function bus (VFB), as well as the assign- capsulates an application’s algorithms development environment is capable of
ment of components to the individual in software components. The ECU soft- displaying functions either graphically,
ECUs of an overall system. The most re- ware – for instance, that of the engine in the form of block diagrams or state
cent Autosar releases provide the basic control unit – is then assembled from machines, or in text form with the aid of
specifications for the production specific software components and basic soft- the control specific description language
deployment of ECUs running Autosar ware and subsequently integrated in termed ESDL (Embedded System Descrip-
conformant software. The releases define the ECU, Figure 1. tion Language) [4]. The behavior of the
the interfaces of both basic software As part of the ongoing update of the algorithms implementing the specified
modules and RTE, the exchange formats Autosar precursor project East-EEA, the functions can be simulated on the PC
and templates for the design and distri- East architecture description language and validated in the real-world environ-
bution of software components, plus an was further developed within the scope ment with the aid of a real-time experi-
initial selection of standardized applica- of the publicly funded Atesst initiative mentation system that augments or re-
tion software interfaces. (Advancing Traffic Efficiency and Safe- places the target ECU (Rapid Prototyping;
ty through Software Technology, www. [5, 6, 7, 8]; Figure 2, Step 1 and Step 2). By
atesst.org), itself an initiative of the exploiting the computing power of a PC
5 Function Development and ECU Sixth Framework Programme (FP6) or experimentation system, and with the
Software Implementation within the EU’s “IST” (Information So- primary focus on the “physical” closed-/
ciety Technologies). Based on applica- open-loop control behavior, the function
The principal subject of the Autosar ble engineering specifications, the do- algorithms are implemented in floating
standard, namely, the description and main specific “East-ADL2” language point arithmetic.

12 ATZelektronik 06I2008 Volume 3

 Once the function algorithms meet function bus on the PC [12], which is then el, www.timmo.org) are aimed at discuss-
the requirements for open-loop/closed- tested either directly on the PC [13] or un- ing concepts and methods to include a
loop controls, they are executed in fixed der real-world conditions [14], Figure 3 and structured means of including the con-
point notation in accordance with the Figure 4. sideration of timing behavior in the de-
ECU software specifications. For individu- sign of new vehicle systems.
al variables, this includes the definition On the tool side, harmonized solu-
of data types with a suitable resolution, 6 Timing Behavior tions facilitating the analysis of system
adaptation of the calculation routines, timing behavior were presented within
and the generation of conversion formu- Logical aspects notwithstanding, system the framework of the Interest (Integrat-
las for the physical representation. A pro- integration requires that the desired tim- ing European Embedded System Tools)
totyping experiment provides an easy ing behavior of an open-loop/closed-loop project. Thanks to a coupling of “ASCET”
means of verifying the fixed point version control be guaranteed. Timing behavior with AbsInt’s aiT Worst Case Execution
of a given software function through com- is largely determined by latencies occur- Time (WCET) analysis tools, the maxi-
parison with the physical model. The ring as a function of signal transfer and mum execution times of individual op-
function algorithms are then transferred computing tasks, whereby sensors and erations of software components can be
to software components, and the data actuators, as well as the communication determined by means of program code
structures and communication mecha- mechanisms of vehicle buses and ECUs, analysis. Similarly, the “SymTA/S” tool by
nisms for the component interfaces are may delay the transfer. In distributed sys- Symtavision permits the determination
specified. The final step consists of the au- tems in particular, bus communications of maximum signal runtimes between
tomatic generation of ECU code, Figure 2, markedly influence the timing behavior sensor input and output on the basis of
Step 3. “ASCET” developed Autosar soft- of electronic controls. To avoid transmis- analyzed WCET data as well as OS and
ware is already deployed in a variety of sion time fluctuations during signal vehicle bus schedules, facilitating the
production projects [10, 11]. Prototyping transfer, time controlled bus systems identification of time delaying factors
environments such as “INTECRIO” already such as Flexray (www.flexray.com) trans- within the system [15].
provide options for validating Autosar fer signals in predetermined time slices.
conformant applications either in a vir- Although the most recent Autosar speci-
tual environment or in the real-world sys- fications still ignore the time related 7 ECU Software Integration
tem, Figure 2, Step 1 and Step 2. Irrespec- characteristics of software and system
tive of the modeling environment, the architectures, efforts within the scope of The open-loop/closed-loop control and
“INTECRIO” integration platform can be Phase II of the Autosar project and the diagnostic functions are tested in a simu-
used to assemble interconnected Autosar EU sponsored Itea2 (Information Tech- lated environment in the laboratory (sys-
conformant software components to form nology for European Advancement) tem test, see Figure 2, Step 4). To this end,
an application by means of the virtual project designated Timmo (Timing Mod- ECUs are connected to actuators or dum-

Figure 2: Development and integration of functions, software and ECUs in virtual and physical environments

ATZelektronik 06I2008 Volume 3 13

C ove r sto r y Autosar

8 ECU Software Application

ECU software is parameterized in such

a manner that the behavior of open-
loop/closed-loop control and diagnos-
tic functions can be simply adapted to
a variety of system variants or vehicle
models by calibrating, or modifying,
the characteristic values of function
algorithms, without the need to
change calculation routines. Using
calibration tools such as “INCA” , char-
acteristic values can be calibrated on-
the-fly while at the same time acquir-
ing signals from ECU, vehicle buses,
and measuring devices. Calibration
tools support the standardized data
description formats as well as meas-
urement and calibration protocols de-
fined by the Association for Standardi-
zation and Automation of Measuring
Systems (www.asam.net). Diagnostic
Figure 3: Integration of software components and validation of functions on the PC functions and protocols can be de-
using “INTECRIO”; verification of the execution of function algorithms with “RTA-TRACE”; clared in a standardized form by
pre-calibration of function parameters on the PC with “INCA” means of the ODX (Open Diagnostic
Data Exchange Format, Asam AE MCD-
2D). When calibration procedures re-
quire a large number of variables to be
my loads on the hardware-in-the-loop tem is subjected to test bench or in-vehi- measured at the same time and/or in
(HiL) test bench. These are then net- cle trials with the deployment of appro- short intervals, development ECUs are
worked and stimulated with the aid of priate test instrumentation [20], Figure equipped with additional, powerful
recorded measurement data or a plant 2, Step 5. interfaces [6].
model simulating, besides the remain-
der of the system, also driver behavior,
vehicle, and environment. In this test,
the ECUs are electrically interconnected
with the simulation model through real-
time capable interface modules. The
presence of appropriate hardware facili-
tates the simulation of electrical faults,
such as short-circuits and wiring discon-
tinuity [16, 17, 18]. The attendant testing
of the increasingly complex open-loop/
closed-loop control and diagnostic func-
tions for ECUs is done with the aid of
more and more detailed plant simula-
tions. With its annual increase in com-
puting power, PC technology provides a
suitable platform for computation inten-
sive simulations. For ““EXAM” ” ple, to-
day’s Core 2 Quad processors permit the
execution of complex driving dynamics
models in real time on the PC – a feat
that would have been impossible only a
short while ago, despite the availability
of dedicated hardware for real-time sim- Figure 4: Early in-vehicle validation of function prototypes in the vehicle using
ulation [19]. Subsequent to the system “INTECRIO” and the rapid prototyping hardware ES910; integration of the prototype
integration, the entire mechatronic sys- in existing ECU networks through bypass and bus interfaces (CAN, ETK, Flexray)

14 ATZelektronik 06I2008 Volume 3

 9 Summary [5] Triess, B.; Müller, Ch.; Lauff, U.; Mößner, C.: Application of Standard PC Technologies in HiL
Entwicklung und Applikation von Motor- und Testing Systems). In: VDI-Berichte 2009 (Hrsg.),
Getriebesteuerungen mit der ETK-Steuergeräte- AUTOREG, Düsseldorf (2008), pp. 647-655
The results presented by Autosar to date
schnittstelle (Development and Calibration with [20] Lauff, U.; Lochau, S.: Kleine Ethernet-Module
provide an essential basis for interwork- the ETK ECU Interface). ATZ Automobiltechnische messen Signale in Sensornähe (Compact Ethernet
ing software development. The compo- Zeitschrift (109) Vol. 1, January 2007, pp. 32-39 Modules Measure Signals Close to Sensors).
nent based and standardized architecture [6] Kulzer, A.; Laubender, J.; Lauff, U.; Mößner, D.; ATZelektronik (1) Vol. 4, November 2006, pp. 50-55
simplifies system integration, scaling, Sieber, U.: Der Direktstart - Vom Modell zum
modification, and maintenance. In the Demonstrator (Direct Starting – From Model to
Demonstrator). MTZ Motortechnische Zeitschrift
ideal case, the underlying software devel- (67) Vol. 9, September 2006, pp. 636-644
opment process is consistent, transpar- [7] Gebhard, M.; Lauff, U.; Schnellbacher, K.: Operation
ent, and feedback driven. Standardized am offenen Herzen – Entwicklung und Test von
data formats and interfaces facilitate the Steuergerätefunktionen mit der Bypassmethode (Teil
exchange of artifacts and easy tool inte- 1) (Open Heart Surgery – Development and Testing
of ECU Functions with the Bypass Method, Part 1).
gration in the development process.
Elektronik Automotive (2008) Vol. 6, pp. 34-39
With the availability of suitable meth- [8] Dubitzky, W.; Eismann, W.; Schinagel, J.: Entwick-
ods and tools, function models can be- lung und Test von Steuergerätefunktionen mit der
come the basis for the development of Bypassmethode (Teil 2) (Development and Testing of
complex electronic vehicle functions. If ECU Functions with the Bypass Method, Part 2). To
models contain – besides ECU software be published in Elektronik Automotive (2008) Vol 8
[9] Freund, U.; Lauff, U.; Wolff, H.J.; Ziegenbein, D.:
architecture and interfaces – suitable in-
Modellbasierte Entwicklung von Autosar-Anwen-
formation from other architecture levels dungssoftware (Model Based Development of
both technological and logical, then Autosar Application Software). ATZelektronik (2),
complex system interactions, such as the Vol. 4, December 2007, pp. 12-16
timing behavior of distributed open- [10] Freund, U.; Lauff, U.; Siwy, R.; Wolff, H.J.;
loop/closed-loop control functions can be Ziegenbein, D.: Sauberer Schnitt – Modellbasierte
Entwicklung von Anwendungssoftware mit
figured into the design from the outset.
AUTOSAR-konformen Schnittstellen (Clean
As a result, model based development Cut – Model Based Development of Application
tools enable engineers to develop solu- Software with AUTOSAR Conformant Interfaces).
tions at the abstraction levels corre- Elektronik Automotive (2007) Vol. 9, pp. 51-55
sponding to their problem manifesta- [11] Schwerin, W.; Jenter, M.: AUTOSAR-Evaluierung
tion. The modular ECU software archi- bei BMW. RealTimes ETAS Group-Magazin (2007)
Vol. 2, pp. 12-13 (www.etas.com/realtimes)
tecture supports the calibration of indi-
[12] Lauff, U.: Offen für Autosar. Automobil Elektronik
vidual functions, which starts with a PC (2008) Vol. 1, pp. 26-28
based simulation and ends with the sys- [13] Critchely, O.; Tracey, N.: RTA-OSEK erweitert
tem integration in the vehicle, and which Support für virtuelle Entwicklung um Echtzeit.
is subject to ongoing refinement. Based RealTimes ETAS Group-Magazin (2008) Vol. 1,
on environment models and optimiza- pp. 38-39 (www.etas.com/realtimes)
[14] Stix, P.; Wagner, J.: Function Development for
tion methods, calibration procedures
FlexRay ECUs. Hanser automotive (2006), Special
can be automated to a large extent. Edition FlexRay, pp. 38-42
[15] Frey, P.; Freund, U.: Integrating Timing Aspects in
Model- and Component-based Embedded Control
References System Development for Automotive Applica-
[1] McKinsey (Hrsg.): HAWK 2015 – Knowledge-based tions. In: Giese, H.; Huhn, M.; Nickel, U.; Schätz,
Changes in the Automotive Value Chain. Germany B. (pub.) – Conference Minutes Dagstuhl-Work-
(2003) shop MBEES, Informatik-Bericht 2008-02, TU
[2] Bauer, R.; Raste, T.; Rieth, P. E.: Systemvernetzung Braunschweig
von Hybridantrieben (System Networking of Hybrid [16] Wolters, U.; Elbs, M.: New Methods and Practices
Drives). ATZelektronik (2) Vol. 4, December 2007, in Automated Testing of Automotive ECUs. In:
pp. 6-11 Grote, C.; Elster, R. (pub.), Design&Elektronik,
[3] Cuenot, P.; Frey, P.; Johansson, R.; Lönn, H.; Begleittexte zum Entwicklerforum Kfz-Elektronik
Törngren, M.; Sjöstedt, C.J.: Engineering Support und FlexRay Solution Day, Poing (2007),
for Automotive Embedded Systems – beyond pp. 165-174
AUTOSAR. Sprnger Automotive Media (/pub.), [17] Wittler, G.; Crepin, J.: Real-time and Performance
FISITA 2008 World Automotive Congress F 2008- Aspects of Hardware-in-the-Loop (HiL) Testing
05-053 Systems. ATZ online (www.atzonline.de), Special:
[4] Gupta, M.; Lauff, U.; Wolff, H. J.: Professionelle Simulation
Umgebung für die Entwicklung von Steuer­ [18] Bayerl, A.; Wandling, F.; Wolters, U.: FlexRay Residual
gerätesoftware - “ASCET” V6.0 (Professional De- Bus Simulation on HiL Testing Systems. Hanser auto-
velopment Environment for ECU Software – “AS- motive (2007), Special Edition FlexRay, pp. 6-9
CET” V6.0). Hanser automotive (2008) Vol. 10, pp. [19] Wittler, G.: PC-Standardtechnologien im
84-87 praktischen Einsatz für HiL-Testsysteme (Practical

ATZelektronik 06I2008 Volume 3 15

View publication stats