Networking and Integration of Active and Passive

Safety Systems
Andreas Raith, Kathrin Sattler, Rudolf Ertlmeier, Thomas Brandmeier
Field of Expertise: Automotive Mechatronics
Institute for Applied Research (IAF)
Ingolstadt University of Applied Sciences
Email: {andreas.raith, kathrin.sattler, rudolf.ertlmeier, thomas.brandmeier}@haw-ingolstadt.de

AbstractEvery two minutes a car occupant was involved in an

accident, every two hours a road death happened, every 13 hours
a pedestrian was killed and every 19 hours a cyclist died - these
were the tragic statistic of accidents on Germanys roads in 2009
[10]. Networking and integrating active as well as passive vehicle
safety systems constitutes an important approach to reduce the
number of road deaths to zero (Vision Zero campaign [13]).
Therefore special tools for developing and testing such integrated
and networked automotive safety systems have to be devised.
This paper points out one attempt at a solution: developing an
integrated tool environment consisting of a Model-in-the-Loop,
a Software-in-the-Loop and a real-time Hardware-in-the-Loop
system containing a crash simulation based on real and simulated
crash data as well as vehicle simulation. It also includes a fail-safe
tester to be able to test the physical errors. With such a system,
the development and test of new integrated safety systems will
be facilitated and missed failures can be diminished. This paper
describes the challenges in developing such a highly integrated
and complex tool.

I. I NTRODUCTION
For a long time safety systems for automotive applications
were built on three distinct pillars: driver assistant systems
(e.g. adaptive cruise control and lane change assistant), active
safety systems (e.g. the braking control systems anti-lock braking system and electronic stability control) and passive safety
systems (e.g. the restraint systems airbag and safety belt).
Therefore separated approaches have been developed. In most
cases there was a split between the process of development
of the function and of the control unit. Nowadays there is
an evolution to network different safety systems in order to
increase the safety for vehicle occupants and pedestrians and to
come closer to the aim of zero accidents (see Fig. 1). Today the
security architecture of a modern vehicle consists of different
systems which interact and rely on each other. Therefore the
testing of such an interconnected and networked system is
very complicated for there are many possibilities of input and
output combinations. The problem here is that currently the
test systems for driver assistant systems and active and passive
safety systems are still considered in isolation. To ensure the
accurate interaction of the single systems an overall view of
networked systems is indispensible. Therefore there is the need
for a test system with special requirements.
To test for example the safety control unit (SCU) of a

see

hear

Integrative Safety System

feel

communicate

Fig. 1. Different systems are communicating with each other within an

integrated safety system: By the extension of the environment detection
different sensor strategies like radar, lidar or ultrasound are being pursued
(see). Measuring the structure vibrations makes the structure-borne sound
audible (hear). Also the vehicle dynamics (feel) and Car2Car communications
via mobile or wireless networks (communicate) are part of it.

vehicle, which controls e.g. the airbags and an emergency

brake assistant in combination with a reversible belt tensioner
[1], there exists a desire for combining a vehicle dynamics simulation with input of real or simulated crash data.
This paper describes the challenges in developing such a
highly integrated and complex tool. It is important to ensure
that a tool which covers the full life cycle of the software
and hardware of an electrical control unit (ECU) is being
used: software design (Model-in-the-Loop, MiL), software
implementation (Software-in-the-Loop, SiL) and software and
hardware integration tests (Hardware-in-the-Loop, HiL) which
represent the test methods during the software and hardware
development (see Fig. 2) have to be covered. MiL means that
during the development of the algorithm a model is being
created which has to be evaluated. Here a vehicle dynamics
simulation with feed of crash data is an very efficient approach.
SiL represents the software code which was obtained from
the model. In this phase also vehicle dynamics simulation in
combination with crash data feed shall be used. Furthermore
it is also necessary to already test the intercommunication

Start of
Production

ECU

n
sig
De

ig
Des

ign
Des

T e s
t

Prototypes

Te s
t

Model

T e s
t

Kick-off

Code
Code
Code

MiL

HiL / Trials /
Test Drives

SiL / HiL

Fig. 2. The development and test process of a safety system from Kick-off
to Start of Production.

with other components here. Finally when also the hardware

development is concluded the validation is done by HiL. Real
and simulated peripherals have to be included and preferably
all fatal errors which can be internal, in intercommunication
or physical have to be covered. For this purpose a real-time
computer in combination with required interfaces and a failsafe tester is used.
Throughout the whole development process a common base
and tool chain is needed. In this case a test case specification
is created which is used in all the different steps inside
the process. Another important point in setting up such a
test system is the use of innovative testing methods like
evolutionary testing. Here intelligent algorithms are used to
detect critical test cases and to increase test coverage.
II. C ONCEPT OF THE TEST SYSTEM
Conventional safety and assistant systems, which work
autonomously and independently, can be distinguished by their
temporally working field. While driver assistant systems help
drivers to handle normal driving situations in traffic scenarios, active safety systems can avoid accidents in dangerous
PreCrash phases by, for instance, brake interventions. If the
crash is unavoidable, passive safety systems, like airbags and
belt tensioners, reduce the severity of the accidents during
the InCrash phase (Fig. 3). Therefore, there are different
approaches for development and application of the different
systems.

-2,0s

-0,5s

-100ms t0

10-30ms

Normal Driving

PreCrash

InCrash

Driver Assistant Systems

Active Safety Systems

Passive Safety Systems

Fig. 3. Working schedule of different safety systems: In normal situation

driver assistant systems support the driver. If the situation becomes dangerous,
active safety systems tries to avoid an accident during the PreCrash phase.
In the InCrash phase passive safety systems reduces the severity of an
unavoidible accident.

A. Methods for driver assistant and active safety systems

For the developing, application and testing of driver assistant and active safety systems, like e.g. an electronic stability
control system, real test drives play an important role. Usually
the system supplier and the vehicle manufacturer define a
maneuver catalogue and benchmark criteria for each test. Such
a catalogue, e.g. for an ESC system, consists among other
things in test maneuvers like:
braking on -split [11]
double lane change [12]
Sine with dwell [3]
These experiments are done again and again until the system
meets all defined requirements. Because the product life cycle
time of modern vehicles decreases while the diversity of
variants rises, it is important to shorten the development times
and reduce costs for testing. Therefore multi body simulation
tools, which simulate the vehicle dynamics, become more
and more important. By using of driving dynamic simulation
tools like CarMakerr [5] within a real time computer, it
is possible to test the control unit on all the functions in
the laboratory. This results in reduced real testing effort and
shortened application time. In [14] e.g. it is described that it
is possible to apply an ESC system for trucks in a virtual test
bench. Only some master variants out of 33 total truck/trailer
variants were tested on a real test track for validation of the
simulation. Even the homologation works with this procedure.
B. Methods for passive safety systems
Algorithms for the deployment of passive safety systems
like airbags and belt tensioners are usually developed and
applied by using of crash test data. To get this data, the
vehicle manufacturer has to perform different crash tests. Most
of these crash tests are specified by consumer organizations
like the international New Car Assessment Program (NCAP)
e.g. [6], which rates vehicle safety systems, or insurance
companies [8], which are interested in lowering repair costs.
For frontal crash systems, for instance for the U.S. market, the
most important specified crash tests are:
Offset Deformable Barrier (ODB) [4]
RCAR bumper test [8]

Wall 0 [6]
For these tests very expensive prototypes are crashed. Therefore, to reduce costs finite elements methods (FEM) crash
simulation tools are increasingly used to design cars and
develop passive safety systems. To test the behavior of the
airbag control unit in a laboratory, usually the crash data
gained by simulation or testing are fed into the embedded
system.
C. Combination of methods for integrated safety systems
In order to test networked active and passive safety functions, e.g. an emergency brake assist in combination with a
reversible belt tensioner as described in [1], it is necessary
to combine the development and application methods of the

different disciplines. That means, that for the algorithm application not only the InCrash phase but also at least the PreCrash
phase has to be considered. For laboratory testing of the
control unit behavior, the combination of conventional multi
body based driving dynamic simulation with data based crash
data fed in testing as shown in Fig. 4 is a good possibility to
develop and test networked safety systems. During the normal
driving and PreCrash phase the whole scenario is simulated
by multi body simulation as long as the ego vehicle does not
touch any other obstacle. If the ego vehicle touches any other
obstacle, the crash database is triggered. Then the recorded
crash data appropriate to the simulated scenario is replayed
and fed into the simulation and the control unit. This approach
enables the reuse of standardized test methods for active safety
systems as well as for passive safety systems and closes the
gap and enables a consistence testing.
HiL (real time system)
software
vehicle &
environment
simulation

hardware
sensor signals

environment sensors
chassis sensors
car2X communication
GPS/navigation

laboratory crashes
simulated crashes
other relevant
situations (Misuses)

trigger

interfaces (e.g. bus systems)

SCU signals

crash
database

SCU
(safety control unit)
algorithms
(with vehicle dynamics,
object properties, )

SCU signals
actuators
(e.g. airbags,
belt tensioners)

Fig. 4. Concept for a hardware-in-the-loop (HiL) test system for a safety

control unit.

III. C RASH DATA

For testing of interconnected and networked systems from
active and passive safety systems, a lot of crash data are
needed. There are two different types of crash data, simulated
and real data.
For reasons of cost, the former are often calculated by numerical simulation, the finite element method (FEM). Therefore
the boundary conditions of the simulation have to be adapted
manually to the desired accident scenario. As the simulation
takes a lot of time because of the high costs of computation,
simulated crash data are only occasionally used for testing of
networked systems. Usually, real data are mainly used. These
are obtained by standardized crash tests by car manufacturers
and their suppliers by measuring the relevant data sources such
as pressure or acceleration values in the vehicle. A well known
example of these standardized crash tests is the US NCAP Insurance Institute for Highway Safety (IIHS) frontal offset
crash [4]. In this test configuration, the vehicle is accelerated
to 64km/h. At that speed, it collides head-on into an immobile
deformable barrier. The barrier and the car overlap 40%. In
the process, all crash-relevant signals of the sensors mounted

in the vehicle are recorded.

All these data are stored in a database, which is included in
the testing system. The selection of the required crash data
is based on various criteria, the so-called crash parameters:
crash type, nature of the obstacle, vehicle type and impact
configuration (for example impact angle, coverage of the
vehicle with the obstacle, etc.). These Parameters are extracted
from the vehicle dynamics simulation of the PreCrash phase at
the collision time t0 of the vehicle to the obstacle. For vehicle
dynamics simulation CarMakerr is used. To replay all crashrelevant data exactly at the collision time t0 , a crash trigger
is implemented in the simulation tool. The trigger consists
of several driver assistance sensors (DA - sensors) which
are mounted around the vehicle. The sensors are installed on
the car shell and parameterized so that they look exclusively
towards the interior of the vehicle; however, they cover the
shell completely. This means that the virtually installed sensors
do not recognize any traffic obstacles as long as the obstacles
are outside the vehicle boundaries. A traffic obstacle is only
recognized by the sensors if it touches the vehicle shell or
penetrates the car. These conditions are the same as the conditions found in accidents. The point an obstacle is recognized
by at least one DA - sensor corresponds to the collision time
t0 and is used as trigger signal. If this appears during the
simulation of a driving situation, all crash relevant parameters
of the car and the traffic obstacle involved in the accident
are immediately stored. The simulation is terminated. From
the stored data the required crash parameter can be calculated
and transferred to the database as search criteria.
Since it is possible to reconstruct any number of crash scenarios, it is impossible to have an actual data base for all possible
scenarios. Therefore, the result of the search in the data base
has to be the data set which most fittingly can be applied to the
accident parameters which have been calculated. The fitting is
influenced by fixed weighting factors for each single crash
parameter. For this purpose an error value E is calculated for
each dataset from the database
n
X
2
E=
wi (pireal pisim )
(1)
i=1

using the crash parameters p of the real and simulated data:

velocity, coverage, impact angle, the nature of the obstacle
(rigid or deformable) etc. w is the fixed weighting factor.
The dataset whose error value is the smallest fits best to
the simulated crash scenario. So this one is the result of the
search and fed into the developed testing system.
But to test the safety control unit exactly in the simulated
scenario, two possibilities are available to generate the required
crash data. As described above, the accident can be calculated
by FEM - simulation. In this case the boundary conditions of
the numerical simulation have to be adapted to the vehicle dynamics simulation. Because it is so time-consuming, the finite
element method simulation is not suitable for the developed
testing system.
In contrast, the second method to generate the required data,

the so called crash data scaling is suitable for the testing

system. In this connection a new dataset which contains the
required crash parameter is generated out of two already
existing crash data sets. For this purpose two crash data sets
are selected from the data base, which enclose the required
parameter values. This means in the example of the crash
velocity, that one of the selected data sets from the data base
must have a higher velocity and the other a lower one. The
other parameters must fit to the requirement. From these two
data sets a new one is scaled with the desired crash velocity
vscale .
Fig. 5 shows two real driven crash signals with 33km/h (a) and
51km/h (b) in addition to the result of scaling these signals
(c) with a crash velocity of 42km/h.
In simplified terms, scaling of crash signals includes three
real crash data with v1 = 33km/h

acceleration [g]

a)
0

testing interconnected and networked systems from active and

passive safety systems excellently.
IV. E XAMPLE
Using a CarMakerr -simulated crash scenario the following
section shows how the system and the methods work. The
scenario is a front-end collision where the ego car bumps into
another car waiting in front of a traffic light. Until the impact
the simulation is used and afterwards the crash data are fed
into the system.
A. Scenario description
The ego vehicle containing an SCU, which includes an
emergency brake assistant in combination with a reversible
belt tensioner as described in [1] and of course airbags, is
driving steady at a velocity of 60km/h. In the chosen scenario,
the car is driving towards a vehicle which is standing still and
is waiting in front of a traffic light (see Fig. 6). The driver is

-20
-40
0

10

20

30

40

50

60

70

time [ms]

real crash data with v2 = 51km/h

acceleration [g]

b)
0
-20

t-3 = -2s
v-3 = 60km/h

-40

belt tensioner emercency brake

10

20

30

40

50

60

t0 = 0s
v0 40km/h
airbag

70

time [ms]

Normal Driving

PreCrash

InCrash

resulting signal of scaling with vscale = 42km/h

c)
acceleration [g]

t-2 -0,8s
t-1 -0,75s
v-2 = 60km/h v-1 = 60km/h

Fig. 6. Overview of the simulated crash scenario with the different phases
of the accident and the moments when safety systems get actuated.

-20
-40
0

10

20

30

40

50

60

70

time [ms]

Fig. 5. The two real driven input signals with the crash velocities a) v1 =
33km/h and b) v2 = 51km/h. The result of scaling the two input signals a)
and b) to the desired velocity vscale = 42km/h is shown in diagram c).

fundamental calculation steps. First, the given signals get

stretched or compressed over time according to the desired
crash velocity. For
v1,2 > vscale
(2)
the signal gets stretched, because from the beginning to the
end a crash with a higher velocity does not take as much time
as one with lower speed. Corresponding to that, for
v1,2 < vscale

(3)

the signal gets compressed. This is followed by a weighting

of the originated signals. The weighting depends at the ratio
of v1,2 and vscale . At the end of signal scaling the new signal
with the crash velocity vscale is generated by interpolating the
two weighted ones. This signal can now be used for testing
the function of the safety control unit. In contrast to the finite
element method simulation scaling is non-time-critical. Thus
this method is suited for the use in the developed system for

inattentive, but the environment sensors register the stationary

vehicle as an obstacle. Therefore, about 800ms before the
impact, the reversible belt tensioner is released. Approximately
750ms before the accident, the emergency brake assistant is
triggered and the car decelerates. So the impact velocity is
40km/h. Typically 25 - 30ms after the crash start time t0 , the
airbags are deployed.
B. Test procedure
The chosen scenario has to be assembled in CarMakerr
which means that the maneuver, the road, the obstacles and
the ego car have to be defined in the tool. The SCU considered
here has to be included either by model (MiL), software (SiL)
or ECU (HiL). In the simulation run, the maneuver is executed
until the collision time t0 and afterwards the crash data are
fed into the system (see Fig. 7). For fault-free operation, a
rest bus simulation runs during the simulation if necessary.
Other needed signals e.g. vehicle dynamic signals like wheel
speed signals, lateral and longitudinal acceleration and yaw
rate or environment sensor signals like radar or lidar which
depend on the maneuver are inserted by CarMakerr . Using
the information of those signals at time t2 the reversible
belt tensioner fires and at t1 the emergency brake assistant
decelerates the car. At t0 the crash trigger in CarMakerr

rel. velocity [km/h]

a)
0
emercency brake t-1

-20
-40

collision time t0

reversible
belt tensioner t-2

airbag
-60
-1.2

-1

-0.8

-0.6

-0.4
-0.2
time [s]

0.2

0.4

0.6

long. accel. [m/s]

b)
0
-50
-100
-150
-200

ax
-1.2

-1

-0.8

-0.6

-0.4
-0.2
time [s]

0.2

0.4

In the future new methods shall be integrated into the test

system. One approach is the usage of evolutionary algorithm
testing [7] which makes it possible to optimize parameters of
a test case to a desired characteristic. For example, in a lateral
test case, e.g. double lane change, one interesting attempt
could be to maximize the yaw rate of the vehicle. So the
parameters of the test case are varied, the test is executed with
the new parameters and afterwards the fitness of the desired
characteristics is compared. Reruns will be done with newly
combined parameters until they are deemed to be sufficiently
suitable. Finally, a test case is designed which best fits the
target (see also Fig. 8).
Since with evolutionary algorithm testing, the test parameters

0.6

Fig. 7. Signal behavior of the simulated crash scenario. a) the velocity of

the ego vehicle relative to the still standig car in km/h and b) the longitudinal
acceleration of the ego vehicle in sm2 . In a) the important moments are marked:
t2 the reversible belt tensioner is released, t1 the emergency brake assistant
is triggerd, t0 the collision time and shortly afterwards the moment, when the
airbags are deployed.

Replacement
Mutation

Individuals
(test data)
Test case
generation

Evaluation

Test
execution

detects and classifies the accident and the feeding of the crash
data is started. Depending on the crash data the airbags are
deployed about 25 - 30ms after collision time t0 .
The SCU algorithm is in the same environment as in a
real vehicle and is not different from a real test drive. So
the test results from the simulation with crash data feeding
are comparable to trials. This means that very early in the
development process of an algorithm, it is possible to conduct
tests as if a real test drive were being done.

Recombination
Test
evaluation

Fitness
calculation

Termination?
Selection

Test results

Fig. 8. The procedure of evolutionary algorithm testing to create a fitted test

case [7].

V. C ONCLUSION AND FUTURE WORK

The test system described here which uses vehicle dynamics
simulation and feeding of crash data for the first time makes
it possible to test efficiently and continuously. Throughout the
whole development cycle of an ECU the desired functionalities
can be tested with the help of MiL, SiL and HiL. In the
future, it will become more and more important to handle
the function and networking complexity of safety systems.
Because of the continuous reuse of test cases for the gradual
software development from model to software to ECU, failure
sources can be specifically pinpointed and eliminated. The
creation of the test cases with a simulation software facilitates
a wide diversity of variants of test scenarios which enables a
coverage of almost all real crash relevant situations. Because
of the networking of single systems, synergy effects arise.
One point is that redundant sensors can be removed (cost
reduction) and another point is that new functions of the
safety system are feasible (performance optimization). The
networking of safety systems leads to a new safety concept
which is not divided anymore into driver assistant systems,
active and passive safety. In fact the reduction of the effects
of a crash by early collision detection reduces the number
of road deaths drastically and contributes one step to Vision
Zero.

are varied, the crash data which are used have to be varied
as well. As described in section III, first attempts at creating
new crash data out of existing data have already been accomplished. Now other parameters apart from crash velocity, e.g.
impact angle or coverage of the ego car to the obstacle, shall be
considered. The aim is to generate crash data which are very
realistic and accurate when compared with real crash data without the effort of crash tests or FEM-simulation.
ACKNOWLEDGMENT
This research is being
funded
by
the
Federal
Ministry of Economics and
Technology (Grant Number
KF2122303RA9) based on
a decision of the German
Bundestag.
We would like to thank our
partners Berner & Mattner
Systemtechnik GmbH, IPG
Automotive GmbH, Continental Automotive GmbH and
Otto-von-Guericke-University Magdeburg.

R EFERENCES
[1] R. Bachmann, M. Fehring, M. Paurevic, The impact of dynamic driving
situations on the safety potential of occupant restraint systems, in:
Airbag 2010 - International Symposium & Exhibition on Sophisticated
Car Occupant Safety Systems, Vol. 10
[2] T. Brandmeier, R. Ertlmeier, A. Raith and K. Sattler, Vernetzung und
Integration von Sicherheitssystemen der Aktiven und Passiven Sicherheit (VISAPS), Forschungsbericht 2010 - Hochschule fr angewandte
Wissenschaften FH Ingolstadt, Januar 2011
[3] Department of Transportation, National Highway Traffic Safety Administration, Docket No. NHTSA-2006-25801, RIN: 2127-AJ77, Federal
Motor Vehicle Safety Standards,Electronic Stability Control Systems,
2006
[4] Insurance Institute For Highway Safety, Frontal Offset Crashworthiness Evaluation Offset Barrier Crash Test Protocol (Version XIII),
http://www.iihs.org/ratings/protocols, May 2008
[5] IPG Automotive GmbH, Karlsruhe, Germany. www.ipg.de, CarMaker
3.5 (2011)
[6] OFFICE OF VEHICLE SAFETY RESEARCH, UPDATED
REVIEW OF POTENTIAL TEST PROCEDURES FOR FMVSS
NO. 208, http://www.nhtsa.gov/DOT/NHTSA/NRD/Multimedia/PDFs/
Crashworthiness/Air\%20Bags/FMVSS_208_II.pdf, October 2009
[7] J. Reiner and J. Meyer, Evolutionres Testen von Steuergerten, Elektronik automotive, September 2010.

[8] Research Council for Automobil Repairs, RCAR Bumper Test, http:
//www.rcar.org/Papers/Procedures/BumperTestProcedure.pdf, September
2010
[9] P. Spannaus and R. Ertlmeier, Expanding design process of the Airbag
Control Unit ACU - Connection of active and passive safety by using
vehicles dynamics for rollover and side crash detection, Sixth Workshop
on Intelligent Solutions in Embedded Systems - University of Applied
Sciences Regensburg, July 2008.
[10] Statistisches Bundesamt Deutschland, Statistisches Jahrbuch 2010,
http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/
Navigation/Publikationen/Querschnittsveroeffentlichungen/Jahrbuch.
psml, 2010.
[11] SS-ISO 14512 : Passenger cars - Straight-ahead braking on split coefficient of friction surfaces - Open-loop test procedures, Aktualisierung:
U - Ausgabedatum: 2000-03-03, Lndercode: SE, Bezugsquelle: SIS
Publishing
[12] SS-ISO 3888-2 : Passenger cars - Test track for a severe lane-change
manoeuvre - Part 2: Obstacle avoidance, Aktualisierung: U - Ausgabedatum: 2002-12-13, Lndercode: SE, Bezugsquelle: SIS Publishing
Electronic Stability Control Systems, 2006
[13] VCD Verkehrsclub Deutschland, VCD Masterplan Vision Zero.
http://www.vcd.org/visionzero.html, 2009.
[14] U. Wurster, M. Ortlechner, B. Schick, E. Drenth, J. Crawley First
ECE 13/11 Homologation of Electronic Stability Control (ESC) by
Vehicle Dynamics Simulation - Challenges, Innovations and Benefits,
chassis.tech plus 2010, Juni 2010.