www.dspace.

com

Hardware-in-the-Loop:
The Technology for Testing Electronic
Controls in Vehicle Engineering

Dr. Peter Waeltermann

dSPACE Inc.
50131 Pontiac Trail Wixom,
MI 48393-2020 USA
Tel. +1 (248) 295-4700
Abstract
Hardware-in-the-loop simulation
(HIL) is an integral component in the
electronic development process for
testing control functions. HIL simula-
tion involves operat-ing mechatronic
systems, particularly electronic con-
trol units (ECUs), in a closed loop
with components that are simulated
in real time to test them intensively
in this virtual environment. This
paper provides an introduction to
the subject of HIL simulation. First,
the essential hardware and software
components will be present-ed, in-
cluding the dynamic models. Then,
the most important HIL applications
will be described, such as the engine,
vehicle dynamics, and electric drives.
This paper will also take a look at
network simulators (testing ECU net-
works) and some spe-cial solutions.
Key Words
mechatronics, hardware-in-the-loop,
simulation, automotive technology,
vehicle electronics
1 Introduction
The importance of electronics and
software has grown considerably in
all areas of everyday life over the last
several years. This trend can clearly
be seen in mechani-cal engineering
(mechatronics), as well as in auto-
motive, aerospace, commercial &
off-highway vehicles, electric drives,
medical engineering, robotics, and
home en-tertainment, where today‘s
smart phones, televisions and games
consoles have more computing
power than the Apollo rockets 45
years ago.
Virtually all innovations in the field
of automotive engineering are now
based on new or further developed
electronics. This applies to the latest
engine technologies such as start-
stop and hybrid drives, as well as
2 HIL Overview 03/2016
Figure 1: Seamless development from control design in TargetLink and Simulink to rapid
control prototyping and testing of the complete AUTOSAR application software on dSPACE
MicroAutoBox II.
passive and active safety systems
(airbags, ESP, pre-crash), driver as-
sistance systems (ACC, lane keeping
systems, night vision), and infotain-
ment systems.
Today‘s top-of-the-range cars in-
clude up to 100 ECUs that are con-
nected with one another via various
bus systems. The ECUs communicate
with each other, and par-ticipate in
vehicle-to-vehicle and vehicle-to-in-
frastructure (V2X) communications.
The complexity of this networked
structure of functions, combined
with an enormous number of dif-
ferent vehicle versions and variants
(different engines and transmissions,
different options, country-specific
versions, etc.), is a major chal-lenge
in terms of developing and testing
vehicle ECUs.
Hence, intensive work is currently
being done to define manufacturer-
independent standards for function
modules and architectures, with the
goal of separating the hardware, the
operating system, and the applica-
tion layers (AUTOSAR, JASPAR, etc.).
Hardware-in-the-Loop technology
(HIL) has become an integral part of
the elec-tronics development process
of vehicle manufacturers and suppli-
ers for testing single ECUs, as well
as ECU networks. This technology is
described in detail be-low.
1.1 Definition and Context
Hardware-in-the-Loop simulation
is a method used in the product
development cycle in which one or
more real components interact with
components that are simulated in
real time (dynamic models).
The part of the system that is not
simulated can consist of real de-
vices, machines, or mechanical test
benches. Nowadays, however, the
term is mainly used to refer to a
real system that consists of one or
more ECUs, controllers, or intelligent
mechatronic components for which
a virtual environment is simulated
electrically and dynamically.
The interactions between the real
and the simulated subsystems make
tough real-time demands on the lat-
 ECU
Electronical
interface
Controller
Signal
conditioning
Electrical Electrical
interface interface
Sensors
Vehicle process
Figure 2: Signal flows in a real system and in HIL simulation.
1)
Step sizes of approx. 500µs – 2 ms are typical, but can sometimes be considerably smaller.
ter. The simulated subsystem has to
perform the following actions within
one simulation step:
 Read in the measurement signals
(actuator control by the ECU)
 Calculate and perform numeric
integration (simulate the entire
dynamic model of a real system)
 Output the results (sensor simula-
tion for the ECU).
The result is a closed loop between
the real controller and the simulated
plant. Failure to meet real-time con-
ditions can result in unstable simu-
lation and even damage to the real
technical device.
Figure 2 shows a signal flow that
illustrates this structure. In the real
system, the real ECU is integrated in
the real vehicle (left); in HIL simula-
tion, it is connected to the HIL simu-
lator via electrical interfaces (center
and right).
1.2 Importance and Benefits,
Requirements
The major aims of HIL simulation
are to enhance product quality, to
HIL Overview 03/2016
1) ECU
Electronical Electronical
interface interface
Controller
Output Signal
drivers conditioning
Electrical
interface
Sensor
Actuators
simulation
Model of
the vehicle
process
Real-time simulation
master com-plexity, and to reduce
development costs. This last aim is
achieved by moving function tests
and diagnostics tests from tests
drives or test bench experiments to
the HIL laboratory. The result is that
the number of expensive prototype
vehicles and time spent at the test
bench are considerably reduced.
HIL tests can be reproduced as often
as required and also automated. It
is now common practice to com-
pletely automatically run, evaluate,
and document tests overnight or
on weekends. This allows the test
operators to concentrate on as-
sessing tests, implementing new
tests or test scripts, and adjusting
tests that failed (for example, due to
ECU errors). Automation provides far
greater test coverage than manual
tests, and this enhances quality and
maturity.
Frequently, HIL simulators are also
used to perform tests that would not
be possi-ble at all on a real system
(for example, because no prototype
vehicles are available yet), or that
ECU
Electronical
interface
Output
drivers
Electrical Electrical Electrical
interface interface interface
Actuator
simulation
Real-time simulation
would be critical for the components
(danger of damaging or destroy-ing
prototypes) or even dangerous for
the test driver (for example, if there
is a sen-sor error at top speed on a
sharp bend).
Thus, HIL simulation makes it pos-
sible to give an ECU an environment
that is so realistic that the ECU’s di-
agnostics system does not detect any
inconsistencies in the electrical signal
quality or the dynamic behavior of
the plant (no fault memory entry by
the diagnostics). In this situation,
any tests that would typically be per-
formed in or with the vehicle (or on
a test bench) can also be performed
on the HIL simulator. This is the
basis for inducing error situations
intentionally. Diagnostic functions
(with short circuits, functional faults
or communication errors), fail-safe
levels and limp-home mode can be
tested in this way.
1.3 Structure of the Paper
The next section of this paper begins
by presenting the essential hardware
3
and software components of HIL sys-
tems, including the dynamic models.
Then a few HIL applications will be
described in detail, such as test sys-
tems for the engine, vehicle dynam-
ics, and electric drives. Then we will
take a look at network simula-tors
(testing ECU networks) and a few
special solutions.
2 HIL Systems:
Basics and Components
HIL systems can vary considerably
from application to application. Even
so, it is possible to identify numer-
ous components that are always
present in a similar form. These are
shown for a single ECU in figure 3
and explained in greater detail in the
following chapters (see [SPD+01]
and [WR06]).
2.1 Hardware Components
of the HIL System
Host PC: An off-the-shelf Windows®
PC is generally used as the user
User interface
Experiment control
Test automation
Diagnostics
ECU
under test
Electric failure
simulation
Optional components
Figure 3: Components of an HIL system (according to [WR06]).
4 HIL Overview 03/2016
interface to the real-time processor
(experiment software) and for ex-
ecuting the modeling and implemen-
tation software (see section 2.2.1).
To ensure high data rates and low
la-tencies in communication with the
real-time hardware, specially opti-
mized inter-face cards are used, and
sometimes also Gigabit Ethernet.
Real-time processor system: Stan-
dard server PCs with a real-time
operating sys-tem have now almost
caught up with special real-time
processor boards in terms of pure
processor performance, which is
particularly important for model
calculation However, connection to
the I/O cards is problematic, as server
PCs are frequently not optimized for
this. Thus, processor boards with
optimized I/O interfaces are used for
high-end applications to achieve an
optimum overall system consisting
of a processor and I/O.
I/O boards and signal conditioning:
HIL applications for vehicles require
Real-time processor
I/O
Signal conditioning
Instrument
Load
simulation
Real loads
Real sensors
Real hydraulics
Real
mechanical
components
boards for simple analog and digital
signals, and also special boards for
fast, engine-angle-synchronous sig-
nals (see section 3.1.1) for fast sen-
sor simulation (wheel speeds, knock
signals) or actuator measurement.
Some of these I/O boards already
possess the necessary protection
circuits and signal adaptations to
specific electri-cal system voltages
(12 V, 24 V, 48V, etc.); otherwise,
separate signal condition-ing is used
(e.g. for current interfaces, lambda
probes, etc.).
Bus systems: The ECUs form net-
works and communicate via various
bus systems in the vehicle (CAN,
LIN, FlexRay, MOST). When parts of
the network are oper-ated in HIL,
the bus behavior of all the missing
ECUs has to be appropriately sim-
ulated. Thus, the HIL simulator must
be able to generate messages (this
is called restbus simulation) and to
read all the messages coming from
the ECU. Here too, special I/O boards
are used, frequently with intelligent
subprocessors or FPGAs and suitable
bus transceivers.
Electrical loads and load simulation:
ECUs control electrical actuators
(called loads), e.g. valves, electric
motors, relays, current-controlled
actuators and piezo injectors. Either
the real loads or electrically equiva-
lent circuits can be used in an HIL
system. The ECU’s diagnostic system
cluster monitors these actuators so that it
can take appropriate action if a fault
occurs (short circuit, open circuit)
or at least in-form the driver. Quite
often, it is sufficient to connect a
substitute resistance to the ECU
as a load. However, if the load itself
has dynamic behavior (variable re-sis-
tance such as in a headlamp) and the
ECU performs diagnostics on this,
either a real load is integrated into
the HIL system or an electronic (=
dynamic) load simu-lation controlled for function develop-ment. It is combined a configuration environ-
by the real-time system is used. also, therefore, natural to use this ment is nec-essary to help with
Electrical fault simulation: To gener- environment to describe dynamic connection of signals, definition
ate the electrical fault states men- be-havior of the plant. In lack of of tasks, interrupt handling, IO
tioned above, failure simulation standards for exchanging models hardware connections, and auto-
units are often integrated into the among various simulation tools, generation and compiling of code.
HIL system. These can simulate hard Simulink S-function was the proven Interactive operation of the HIL
short circuits and open circuits, and method. However, now with FMI system requires configurable GUIs
also leakage resistance and loose standards, the exchange of dynamic with a wide range of different views
contacts. Relays or semiconductor plant models is much more feasible (figure 5), which can be adapted
switches are used for this depending for HIL simulation. flexibly to specific pro-jects. In
on re-quirements. The failure system As plant dynamics sub-models are addition, 3-D visualization is in-
is programmed and activated either
interactively or via test automation.
Real components: To treat ECUs Soft ECU
realistically, real components are
often neces-sary. These might be
loads that are not easy to simulate,
or that can only be simu-lated with a
lot of effort, and sometimes smaller
setups or even complex test benches
(see section 3.3) are used. Engine
Power supply: Simulating the vehicle
electrical system and the battery
vehicle al-so requires power supplies
whose voltages can be specified
dynamically by the simulator. This is
especially important for undervolt-
Actuator signals from ECU

Sensor signals to ECU

age and overvoltage tests (e.g. in Drivetrain

jumpstarts by trucks) and for simu-

lating voltage drops when starting
the engine.

2.2 Software
Components
of the HIL System Vehicle Dynamics

The software components for an HIL

system are subdivided into the op-
erating software (PC), the real-time
software (real-time system) and the
dynamic plant model.
Environment
2.2.1 Operating Software
(Implementation and
Experiment Software)
Graphical programming of control
functions using simulation envi-
ronments like MATLAB ®/Simulink ®
is established as a quasi-standard Figure 4: Complex complete vehicle model described in MATLAB/Simulink

HIL Overview 03/2016 5

 dispensable, especially for vehicle
dynam-ics applications, as complex
driving maneuvers cannot be suitably
evaluated by recorded time behav-
iors alone. However, the greatest
benefit is derived from HIL systems
if test runs are not in-teractive but
automated. HIL tests frequently run
overnight or on weekends, and all
that the operators need to do during
the day is to examine the generated
test reports, repeat failed tests, and
implement new tests. The time saved
by automa-tion means that when
used systematically, HIL systems pay
for themselves in only a short time,
typically less than a year.
Script languages such as VBA, MAT-
LAB and Python are frequently used Figure 5: Configuration Environment for Plant Models, Hardware I/O and Signals
for au-tomation. However, there are
also test tools on the market that al- simulation (different step sizes within to be controlled. The model quality
low test imple-mentation to be per- the model) and multiprocessor sys- must be so good that the ECU does
formed in graphical form (figure 6). tems must also be supported. These not detect any inconsistencies or
As in Simulink, the test creator can requirements are often fulfilled only implausibility. The real-time capabil-
put together a test from single test by special real-time kernels. How- ity of the model is another decisive
steps or whole test sequences from ever, it is now also possible to set up criterion for HIL use. Very detailed
libraries, and "program" parallel as simple HIL systems based on standard models (includ-ing FEM approaches
well as serial test sequences real-time oper-ating systems such as and 3-D flow simulation) are often
QNX and LINUX-RT. used in engine and chas-sis devel-
2.2.2 Real-Time Software opment, and such models are far
To meet HIL simulation’s tough real- 2.2.3 Dynamic Models from being real-time-capable. For
time requirements, real-time operat- To close the control loop between the HIL operation, therefore, specific
ing sys-tems (or operating system ECU and simulator inputs/outputs, models and model approaches are
kernels) designed for maximum I/O dynamic plant models are needed. often used that are real-time-capable
throughput and minimum I/O latency These must provide a sufficiently and sufficiently precise with regard
are used. Multitasking, multi-rate good representation of the system to the ECUs’ sensors.

Figure 6: ControlDesk for interactive operation of the HIL systems (left) and MotionDesk for 3-D visualization of
driving experiments (right).

6 HIL Overview 03/2016

Combustion models: With engine
simulators, mean value models are
often used. These are usually generic
and are parameterized by means of
test bench measure-ments made for
the specific engine. Static internal
engine relationships are fre-quently
approximated by using look-up
tables. Either the engine models are
oper-ated in test bench mode (the
engine speed is held constant by
means of a simulat-ed load machine)
or drive cycles are run via a drivetrain
model (e.g. EUDC, FTP75). For an
overview of engine models, refer to
[SWS07]. Development work recent-
ly started on engines with in-cylinder Figure 7: Graphical programming of HIL tests in AutomationDesk.
pressure measure-ment, and this has
made greater model precision neces- The tire models, drivetrain and steering Environment models: As well as the
sary for HIL operation. Models that system are also extremely important. actual vehicle models, virtual test
describe inlet and outlet behavior
and combustion very precisely are
therefore being used more and more. Soft ECU
Soft ECU

However, these models are far more - ECU models

complex to parameterize and also

require smaller step sizes (typically
100 µs) [SWS07]. Another current
major development issue is the Engine
Engine model
suitable simulation of the exhaust -simple, mean-value or
detailed in-cylinder-models
system with a particulate filter, an
oxidation catalytic converter or even
selective catalytic reduction (SCR).
ECU

Vehicle dynamics models: ESP ECUs

Actuator signals from EC

Sensor signals to ECU

Drivetrain

are very safety-critical systems. Sen- Drivetrain models

-Front-, rear-, and four-wheel drive
sor signals are therefore monitored -Manual and automatic transmission
-Elastic drivetrain
very precisely (e.g. by defined initial-
ization se-quences for each single
sensor) and checked for plausibility Vehicle Dynamics
toward one another by means such Vehicle dynamics model
-Vehicle motion, tires
as internal observer models. This -Wheel suspension, steering,
-Aerodynamics, brake system
results in tough demands on vehicle (ASMBrakeHydraulics)

dynamics models. In HIL systems for

vehicle dynamics control systems
Environment
(ASB, ESP), the essential masses Environment model
-Driver, road and maneuver control
(vehicle body and wheel mass) are -Traffic simulation (ASM Traffic)

simulated, and the wheel suspen-

sions (interaction between the body
and wheel) are represented by mul-
tidimensional look-up tables. Figure 8: Structure of a vehicle dynamics model in MATLAB/Simulink.

HIL Overview 03/2016 7

drives also require environment mod-
Real-Time Processor
els such as a driver model, a road
description and a ma-neuver control Engine Position Crankshaft
(figure 7). All these components Speed Phase Signal Generator
Accumulator (Wavetables)
have now become standard in com-

Engine Position Bus (4 MHz)

mercial vehicle dynamics models.
Cam 2/4 x Crankshaft
An overview of vehicle dynamics HIL

Adder
Phase
Signal Gen.
sys-tems is provided in [SW05]. 8 Channels
Intake (Wavetables)
Window Ignition
At the moment, driver assistance
PHS-Bus

Fifo
Spark
Event
systems (ACC, lane change/lane Advance Capture Signal Cond. Ignition
and Complex Signals
keeping/parking assistants, environ-
Comparator
ment detection, etc.) are an impor- 8 Channels
Intake
Window Injection Signal Cond.
tant focus in the development of Injection
Fifo

Fuel
Event and Complex
automotive and commercial vehicle Capture Signals
Amount Comparator
electronics. Not only models of the Slave DSP
main vehicle are required for these, Knock

DPRAM
Param. Knock 4 Knock
but also models of the environment, Processor Signals

in other words traffic simulation that

appropriately simulates the behavior
of other vehicles and the signals
from radar sensors, ultrasonic sen-
sors, and cameras, and feeds them
to the ECUs.
Other development issues include
all kinds of electric drives and their
peripherals (vehicle electrical system,
battery systems, DC-DC converters,
etc.).
3 HIL Application Areas
HIL systems are employed for test-
ing single ECUs (see section 3.1)
and ECU networks. Single ECUs are
frequently tested thoroughly by their
suppliers before they are delivered
to the vehicle maker - the original
equipment manufacturer (OEM) - for
integration. The OEM then performs
comprehensive network tests on all
the ECUs together (see section 3.2).
Some special solutions involving test
bench integration are described at the
end of this chapter.
3.1 Testing Single ECUs
This section pays particular attention
to engine and vehicle dynamics ECUs
and ECUs for electric drives used in hy-
brid vehicles, electric steering systems,
2)
A precision of 0.1° crank angle is typically required. This corresponds to 2.8 µs at 6,000 min-1, and in Formula One approx. 0.9 µs at 19,000 min-1.
next DS2211 (<8 cyl.)
Figure 9: for the crank-angle-synchronous generation of crankshaft/camshaft sig-nals and
knock signals and for capturing injection and ignition signals. The APU is based on FPGA
technology and has a sampling rate of 4 MHz.
etc. It is not possible to cover all the mode, or it is even impossi-ble to start
details in this article, so references to the engine in the simulation. For de-
the relevant lit-erature are provided. tailed information on engine simula-
tions and engine models, please refer
3.1.1 Combustion to [HP07].
Engine ECUs
ECUs for combustion engines gener- 3.1.2 Vehicle Dynamics ECUs
ally have time-based and crank-angle- Electronic stability program (ESP)
based functions and subsystems. The perform selective braking on single
main task of engine control consists wheels to ensure that the slip angle
in high-precision 2) capture of the is reduced, thereby stabilizing the ve-
engine angle (reading crankshaft and hicle in critical driving situations such
camshaft signals) and the output of as wet or icy roads. The driver’s inten-
injection and ignition signals. tion is detected by means of the steer-
While the ECU’s normal I/O can be ing wheel angle. Sensors for the yaw
simulated sufficiently well with a rate (rotation around the vertical axis),
typical sam-pling rate of 1 ms, spe- lateral acceleration and wheel speed
cial fast subsystems are used for the are used to determine the vehicle’s
crankshaft-synchronous signals (figure motion. In addition, relevant variables
8). As already mentioned in section are estimated by means of an internal
2.2.3, engine ECUs make very high vehicle model (observer) [WR06]. An
demands on the models. All the sen- ESP is a safety-critical system. Sensors
sor signals for these must have good and actuators are monitored very
representations in the model, because precisely (by initialization and plausi-
otherwise the ECU goes into fail-safe bility checks), so (for example) active,

8 HIL Overview 03/2016

 ing pump needs energy only when it
Valve signal actually has to support steering. The
ESP ECU 12 x Valve signals
detection unit
basic structure of an electrical machine
in a vehicle is shown in figure 10. The
controller itself, with its current con-
troller, sends pulse-width-modulated
control signals to the power stages,
which then switch the real voltages
Brake pressure sensor and currents for the electric motor.
This generates torques on a vehicle
4 x wheel speed component via mechanical shafts.
Steering wheel angle
Rotational speed For control, motor currents and the
Lateral acceleration motor position are usually returned.
A basic difference between electric
Figure 10: HIL control loop for vehicle dynamics control systems: 12 measured valve control machines and other vehicle compo-
signals and the pump control are read in by the HIL system and used in models of the brake
hydraulics and the vehicle. Sensor signals for the brake pressure, wheel speeds, steering
angle and vehicle motion are returned to the ESP system.

intelligent wheel speed sensors with 3.1.3 Electric Drives and

disturbance-proof current interfaces
are used. ESP test systems have to
fulfill the requirements on signal type
(current sources and sinks for the
wheel speed, suitable valve signal
detection, etc.) and on model quality
very precisely. Figure 9 shows the basic
structure of the HIL control loop and
explains the interactions. For further
information, please refer to [SW05].
Hybrid Vehicles
Electrical drives are becoming more
and more important in modern ve-
hicles, whether they are in the drive
train (e.g. hybrid drives) or in the area
of the chassis and the steering system.
For example, in conventional power
steering, the pump is driven continu- Figure 12: Generic FPGA board for the
ously by the combustion engine via a measurement, simulation and generation
belt or a chain, while an elec-tric steer- of signals in the sub-µs range.

nents is that the machine is controlled

ECU
at a very high clock rate (typ. 10-20
KHz). This makes high demands on the
Current 3 Phase HIL simulation. I/O sampling rates in
Controller Voltages
Vehicle the millisecond range and mean value
Application
models, which are used for combus-
tion engines, are not sufficient for fast
Current Signal current and position control. Special
FPGA-based hardware is needed
Application Position Signal
Controller
Transmission for this. Figure 11 shows a generic
Sensor Signals
FPGA board that can be equipped
with applica-tion-specific modules,
Controller Power Stage Electric Motor Mechanics
e.g. for measuring the PWM control
signal or for simulating incremental
encoders or resolvers (clock rate 40
Signal Level Electric Power Level Mechanical Level
MHz). Moreover, small model parts
Figure 11: Basic structure of electric drives in vehicles and the three possible inter-faces to can be simulated directly on the FPGA
an HIL system. to achieve simulation step sizes in the
sub-µs range.

HIL Overview 03/2016 9


Figure 13: Typical ECU architecture of a top-of-the-range vehicle.
Figure 10 shows the possible inter-
faces between an HIL system and the
electrical machine’s ECU. Depending
on the application and the modeling
depth, the inter-faces can be defined
and implemented either on the me-
chanical level (e.g. with mechanical
load motors), on the electrical power
level (by means of electronic load
simulation), or on the signal level
(without relevant power). HIL solu-
tions for all these cases have been
published and are available on the
market [WSW+07].
3.2 Testing the ECU Network
The vehicle manufacturers are re-
sponsible for the vehicle as an over-
all system, and for ensuring that
ECUs from different suppliers work
together. Thus, network testing on
all the ECUs is of major importance
in vehicle development. Figure 13
shows a typical ECU network with
different buses and gateway ECUs
[WSD04].
Among the buses implemented in
vehicles, the CAN bus continues to
10
be predomi-nant. However, the less
expensive serial LIN bus is frequently
used for simple tasks, while FlexRay
(chassis area) and MOST (infotain-
ment) are preferred for high-speed
applications. Additionally, different
versions of Automotive Ethernet are
becoming more and more important
for new vehicle generations.
The objective of network tests on an
HIL system is often to verify multi-
ECU functions and bus communica-
Figure 14: Network simulator for testing of large heavy duty trucks.
tion, e.g. drivetrain coordination; the
central locking system; the light and
indicator control; or even the entire
operating actions taken by the driver.
Other tests cover network manage-
ment: If the interior ECUs are not
needed for some time, they have to
switch to stand-by mode to reduce
current consumption. If this does
not happen, the battery goes fl at,
and after a lengthy stationary period
it is impossible to open or start the
vehicle. Thus, measuring sleep mode
current is a very important part of HIL
testing, and special current measure-
ment boards in the µA range are used
for this. Another problem in testing
an ECU network is the large number
of vehicle vari-ants. The number of
possible vehicle model variants and
country variants for one platform
is now so large that only a fraction
of vehicle variants are available as
genuine prototypes. The network
HIL simulator makes it possible to
switch ECUs in and out very quickly
by means of test automation, so
reconfiguration from one variant to
another can take just a few seconds.
This increases test depth and en-sures
that the ECUs reach a higher maturity
at an earlier stage.
HIL Overview 03/2016
 ECU ECU ESP ECUs also require special mea-
Electrical Electrical Electrical Electrical
interface interface interface interface surement equipment, as the coils for
Controller Controller
controlling the twelve ESP valves are
housed in the same enclosure as the
Signal Output Signal Output
conditioning driver conditioning driver ESP controller, so only the effect of
Electrical Electrical
the control (i.e. the magnetic field)
interface interface can be captured by Hall sen-sors (see
Integrated Electrical
interface
Electrical
interface
Integrated the valve signal detection on the left
sensor Actuator
of figure 9).
Physical Physical The stimulation of internal sensors
interface Actuator Sensor interface
Stimulus simulation simulation can even mean that to stimulate
Sensors
actuator internal accel-eration and yaw rate
Feedback
sensors, the entire ESP ECU, includ-
ing valve signal detec-tion, has to
Model of the
vehicle process
Model of the
vehicle process
be mounted on a rotatable 3-D
Control of Electrical
motion platform that is connected
stimulus actuator
Real-time simulation Real-time simulation
interface
with the actual HIL simulator via a
a) HIL structure with integrated sensors b) HIL structure with integrated actuators
multichannel slip ring system (figure
16) [FPS09]. 3.3.2 Test Bench Integra-
tion
Figure 15: Integrated sensors and actuators: electrical interfaces are replaced by physical
interfaces [LW00].

3.3 Special HIL Solutions

3.3.1 Integrated Sensors

and Actuators
As already shown in figure 2, there
is generally an electrical interface
between the ECU and the (simu-
lated) actuators and sensors. In this
case the wiring harness can simply
be opened up and connected to the
simulator. However, if the ECU has
in-tegrated sensors or actuators, the
interfaces between the ECU and the
HIL system are at different locations
(see figure 15).
Integrated sensors and actuators are
frequently used in transmission ECUs
that are installed directly in the au-
tomatic transmission. For HIL simula-
tion, the integrated sensors must be
stimulated physically, e.g. inductive
speed sensors are stimulated by con-
trolled coils, pressure membranes by
strong lifting magnets, and tempera- Figure 16: 3-D motion platform with ESP ECU and valve signal detection unit for stimulating
ture sensors by controlled hot plates. integrated acceleration and yaw rate sensors.

HIL Overview 03/2016 11

 For some users, it is important to
test an entire mechatronic subsystem
such as a steering system or a chas-
sis on the HIL simulator in addition
to performing pure electronics tests.
Thus, fatigue tests have to be per-
formed in addition to function test-
ing. Classic mechanical test benches
are coupled with HIL simulators for
this. Figure 17 shows such a test
bench for a steering system. Test
benches have also been coupled for
testing a part of the drivetrain; for ex-
ample, a real Formula One transmis-
sion was connected to a simulated
engine and a simulated drivetrain.
The coupling of HIL simulation with Figure 17: Example of an HIL simulator for testing electrical steering systems. The mechanical loads
mechanical axle test benches for that are applied to the steering system on the test bench are the same as those that occur in the
function devel-opment and verifica- vehicle.
tion for active chassis has also been
published. Literature3) zeugtechnik. 2. Tagung
[AS09] AUTOSAR, Automotive „Mecha-tronik im Auto-
4 Summary Open System Architecture. mobil”, Haus der Technik,
This paper provides an overview of www.autosar.org, 2009. München, November
hardware-in-the-loop technology. [C09] CONTINENTAL AUTOMO- 15-16, 2000.
The differ-ent HIL components were TIVE: Integrated Control [MB01] MICHALSKY, T.; BÜDEN-
presented and some application Unit for Double-Clutch BENDER, M.: Testing
fields from automotive engineering Transmission (DCT). www. transmission ECUs with
were described. Although the ex- conti-online.com, 2009. in-tegrated Sensors. Au-
amples largely come from the field [FPS09] FILGERDAMM, A.; toTechnology, Vol. No. 1,
of passenger vehicles, it should be PLÖGER, M; SCHULTE, T.: June 2001.
added that HIL is also widely used HIL-Simulation für me- [S08] SAX, E. (Hrsg.): Automa-
in the com-mercial vehicle and chatro-nische automotive tisiertes Testen einge-
construction equipment industries, Steuergeräte. Elektronik betteter Systeme in der
as well as in motor racing. Outside Automotive, 3/2009. Auto-mobilindustrie.
automotive engineering, HIL is being [HP07] SCHÜTTE, H.; PLÖGER, Carl Hanser Verlag,
employed successfully in aerospace M.: Hardware-in-the-Loop München, 2008.
and defense, in ship engineering and Testing of Engine Control [SPD+01] SCHÜTTE, H.; PLÖGER,
in industrial automation. Units – A Technical Survey. M.; DIEKSTALL, K.; WAEL-
There are many topics that could only SAE Paper No. 2007-01- TERMANN, P.;
be mentioned briefly in this article, or 0500, www.sae.org, SAE MI-CHALSKY, T.: Testsys-
which had to be left out completely, Global Congress, Detroit, teme im Steuergeräte-
such as driver assistance systems, as 2007. Entwicklungsprozess.
well as test methods and processes. [LW00] LAMBERG, K.; WAELTER- ATZ/MTZ-Sonderheft
These are described in detail in the MANN, P.: Einsatz der Automotive Electronics,
reference literature (especially [S08] HIL-Simulation zum Test March 2001.
and [WR06]). von Mechatronik-Kom- [SW05] SCHÜTTE, H.; WAELTER-
ponenten in der Fahr­ MANN, P.: Hardware-in-
3)
For more literature please see www.dspaceinc.com/go/hil-literature

12 HIL Overview 03/2016

 the-Loop Testing of Vehicle
Dynamics Controllers – A
Technical Survey. SAE
Paper No. 2005-01-1660,
www.sae.org, SAE Global
Congress, Detroit, 2005.
[SWS07] SCHULZE, T; WIEDEMEIER,
M.; SCHÜTTE, H.: Crank
Angle-Based Engine
Modeling for Hardware- Dr. Peter Waeltermann
has a Master’s degree (Dipl.-Ing.)
in-the-Loop Applications
in Mechanical Engi-neering / Mecha-
with In-Cylinder Pressure
tronics and a Dr.-Ing. (Ph.D.) degree
Sensors. SAE Paper No. from the University of Pa-derborn,
2007-01-1303, Germany. He worked with dSPACE
www.sae.org, SAE Global GmbH in Paderborn, Germany,
Congress, Detroit, 2007. since 1999, where he held different
[WR06] WALLENTOWITZ, H.; REIF, management positions in the area of
K. (Hrsg.): Handbuch hard-ware-in-the-loop (HIL) simulation
Kraftfahrzeugelektronik – and project engineering.
In the summer of 2014, he moved
Grundlagen, Komponent-
to dSPACE Inc. (USA) to take over a
en, Systeme, Anwend-
position as Business Direc-tor.
ungen. Vieweg Verlag, On October 1, 2014, Peter became the
Wiesbaden, 2006. President of dSPACE Inc.
[WS07] WILHELMI, S.; SCHMIDT,
A.: Elektrik und Elektronik
– Komfortsysteme und
Leistungsverteilung.
ATZ Sonderheft: Die neue
C-Klasse, 04/2007.
[WSD04] WAELTERMANN, P.;
SCHÜTTE, H.; DIEKSTALL,
K.: Hardware-in-the-Loop-
Test verteilter Kfz-Elek-
troniksysteme,
ATZ 05/2004.
[WSW+07] WAGENER, A.; SCHULTE,
T.; WAELTERMANN, P;
SCHÜTTE, H.: Hardware-
in-the-Loop Test Systems
for Electric Motors in
Advanced Powertrain
Applica-tions. SAE Paper
No. 2007-01-498,
www.sae.org, SAE Global
Congress, Detroit, 2007.

HIL Overview 03/2016 13

 www.dspace.com

© Copyright 2016 by dSPACE GmbH.

All rights reserved. Written permission is required for reproduction of all or parts of this publication. The source must
be stated in any such reproduction. dSPACE is continually improving its products and reserves the right to alter
the specifications of the products at any time without notice. "CalDesk", "ConfigurationDesk", "ControlDesk",
"dSPACE", "Embedded Success dSPACE", "Green Success", "MicroAutoBox", "ProMINT", "SCALEXIO", "SYNECT",
"SystemDesk", "TargetLink", and "VEOS" are trademarks or registered trademarks of dSPACE GmbH in the United
States of America or in other countries or both. Other brand names or product names are trademarks or registered
trademarks of their respective companies or organizations.

Germany United Kingdom France

dSPACE GmbH dSPACE Ltd. dSPACE SARL
Rathenaustraße 26 Unit B7 . Beech House 7 Parc Burospace
33102 Paderborn Melbourn Science Park Route de Gisy
Tel.: +49 5251 1638-0 Melbourn 91573 Bièvres Cedex
Fax: +49 5251 16198-0 Hertfordshire . SG8 6HB Tel.: +33 169 355 060
info@dspace.de Tel.: +44 1763 269 020 Fax: +33 169 355 061
Fax: +44 1763 269 021 info@dspace.fr
info@dspace.co.uk

China Japan USA and Canada

dSPACE Mechatronic Control dSPACE Japan K.K. dSPACE Inc.
Technology (Shanghai) Co., Ltd. 10F Gotenyama Trust Tower 50131 Pontiac Trail
Unit 1101-1105, 11F/L 4-7-35 Kitashinagawa Wixom . MI 48393-2020
Middle Xizang Rd. 18 Shinagawa-ku Tel.: +1 248 295 4700
Harbour Ring Plaza Tokyo 140-0001 Fax: +1 248 295 2950
200001 Shanghai Tel.: +81 3 5798 5460 info@dspaceinc.com
Tel.: +86 21 6391 7666 Fax: +81 3 5798 5464
Fax: +86 21 6391 7445 info@dspace.jp
infochina@dspace.com

04/2016