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 USATel. +1 (248) 295-4700

HIL Overview 03/20162

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.

AbstractHardware-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 Wordsmechatronics, hardware-in-the-loop, simulation, automotive technology, vehicle electronics

1 IntroductionThe 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

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 ContextHardware-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-

HIL Overview 03/2016 3

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

ECU

Controller

Signalconditioning

Electronicalinterface

Electronicalinterface

Electricalinterface

Electricalinterface

Outputdrivers

Sensors Actuators

ECU

Real-time simulation

Controller

Signalconditioning

Electronicalinterface

Electronicalinterface

Electricalinterface

Electricalinterface

Outputdrivers

Sensorsimulation

Actuatorsimulation

Model of the vehicle

process

Vehicle process

Electricalinterface

Electricalinterface

Real-time simulation

ECU

Real-time simulation

Figure 2: Signal fl ows 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.

1)

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

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 PaperThe next section of this paper begins by presenting the essential hardware

HIL Overview 03/20164

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 SystemHost PC: An off-the-shelf Windows® PC is generally used as the user

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

User interfaceExperiment control

Test automation

ECU under test

Diagnostics

Real-time processor

Load simulation

I/O

Signal conditioning

Electric failure simulation

Instrument cluster

ECU

Optional components

Real loads

Real sensors

Real hydraulics

Real mechanical components

Figure 3: Components of an HIL system (according to [WR06]).

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 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 (=

HIL Overview 03/2016 5

dynamic) load simu-lation controlled by the real-time system is used. Electrical fault simulation: To gener-ate the electrical fault states men-tioned above, failure simulation units are often integrated into the HIL system. These can simulate hard short circuits and open circuits, and also leakage resistance and loose contacts. Relays or semiconductor switches are used for this depending on re-quirements. The failure system is programmed and activated either interactively or via test automation. Real components: To treat ECUs 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. 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-age and overvoltage tests (e.g. in jumpstarts by trucks) and for simu-lating voltage drops when starting the engine.

2.2 Software Components of the HIL SystemThe 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.

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

for function develop-ment. It is also, therefore, natural to use this environment to describe dynamic be-havior of the plant. In lack of standards for exchanging models among various simulation tools, Simulink S-function was the proven method. However, now with FMI standards, the exchange of dynamic plant models is much more feasible for HIL simulation. As plant dynamics sub-models are

Soft ECU

Engine

Drivetrain

Environment

Act

uat

or

sig

nal

s fr

om

EC

U

Sen

sor

sig

nal

s to

EC

U

Vehicle Dynamics

combined a configuration environ-ment is nec-essary to help with connection of signals, definition of tasks, interrupt handling, IO hardware connections, and auto-generation and compiling of code.Interactive operation of the HIL system requires configurable GUIs with a wide range of different views (figure 5), which can be adapted flexibly to specif ic pro-jects. In addition, 3-D visualization is in-

Figure 4: Complex complete vehicle model described in MATLAB/Simulink

HIL Overview 03/20166

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 for au-tomation. However, there are also test tools on the market that al-low test imple-mentation to be per-formed in graphical form (figure 6). As in Simulink, the test creator can put together a test from single test steps or whole test sequences from libraries, and "program" parallel as well as serial test sequences

2.2.2 Real-Time SoftwareTo meet HIL simulation’s tough real-time requirements, real-time operat-ing sys-tems (or operating system kernels) designed for maximum I/O throughput and minimum I/O latency are used. Multitasking, multi-rate

Figure 5: Configuration Environment for Plant Models, Hardware I/O and Signals

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

simulation (different step sizes within the model) and multiprocessor sys-tems must also be supported. These requirements are often fulfilled only by special real-time kernels. How-ever, it is now also possible to set up simple HIL systems based on standard real-time oper-ating systems such as QNX and LINUX-RT.

2.2.3 Dynamic ModelsTo close the control loop between the ECU and simulator inputs/outputs, dynamic plant models are needed. These must provide a sufficiently good representation of the system

to be controlled. The model quality must be so good that the ECU does not detect any inconsistencies or implausibility. The real-time capabil-ity of the model is another decisive criterion for HIL use. Very detailed models (includ-ing FEM approaches and 3-D flow simulation) are often used in engine and chas-sis devel-opment, and such models are far from being real-time-capable. For HIL operation, therefore, specific models and model approaches are often used that are real-time-capable and sufficiently precise with regard to the ECUs’ sensors.

HIL Overview 03/2016 7

Act

uat

or

sig

nal

s fr

om

EC

UA

ctu

ato

rsi

gn

als

fro

mEC

Soft ECU

Engine

Drivetrain

Environment

Sen

sor

sig

nal

s to

EC

U

Vehicle Dynamics

Soft ECU

- ECU models

Environment model

-Driver, road and maneuver control-Traffic simulation (ASM Traffic)

Engine model

-simple, mean-value or detailed in-cylinder-models

Drivetrain models

-Front-, rear-, and four-wheel drive-Manual and automatic transmission-Elastic drivetrain

Vehicle dynamics model

-Vehicle motion, tires-Wheel suspension, steering,-Aerodynamics, brake system(ASMBrakeHydraulics)

Figure 7: Graphical programming of HIL tests in AutomationDesk.

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 pressure measure-ment, and this has made greater model precision neces-sary for HIL operation. Models that describe inlet and outlet behavior and combustion very precisely are therefore being used more and more. However, these models are far more complex to parameterize and also require smaller step sizes (typically 100 µs) [SWS07]. Another current major development issue is the suitable simulation of the exhaust system with a particulate filter, an oxidation catalytic converter or even selective catalytic reduction (SCR).Vehicle dynamics models: ESP ECUs are very safety-critical systems. Sen-sor signals are therefore monitored very precisely (e.g. by defined initial-ization se-quences for each single sensor) and checked for plausibility toward one another by means such as internal observer models. This results in tough demands on vehicle dynamics models. In HIL systems for vehicle dynamics control systems (ASB, ESP), the essential masses (vehicle body and wheel mass) are simulated, and the wheel suspen-sions (interaction between the body and wheel) are represented by mul-tidimensional look-up tables.

The tire models, drivetrain and steering system are also extremely important.

Environment models: As well as the actual vehicle models, virtual test

Figure 8: Structure of a vehicle dynamics model in MATLAB/Simulink.

HIL Overview 03/20168

drives also require environment mod-els such as a driver model, a road description and a ma-neuver control (figure 7). All these components have now become standard in com-mercial vehicle dynamics models. An overview of vehicle dynamics HIL sys-tems is provided in [SW05]. At the moment, driver assistance systems (ACC, lane change/lane keeping/parking assistants, environ-ment detection, etc.) are an impor-tant focus in the development of automotive and commercial vehicle electronics. Not only models of the main vehicle are required for these, but also models of the environment, 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 AreasHIL 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 ECUsThis section pays particular attention to engine and vehicle dynamics ECUs and ECUs for electric drives used in hy-brid vehicles, electric steering systems,

etc. It is not possible to cover all the details in this article, so references to the relevant lit-erature are provided.

3.1.1 Combustion Engine ECUsECUs for combustion engines gener-ally have time-based and crank-angle-based functions and subsystems. The main task of engine control consists in high-precision2) capture of the engine angle (reading crankshaft and camshaft signals) and the output of injection and ignition signals.While the ECU’s normal I/O can be simulated sufficiently well with a typical sam-pling rate of 1 ms, spe-cial fast subsystems are used for the crankshaft-synchronous signals (figure 8). As already mentioned in section 2.2.3, engine ECUs make very high demands on the models. All the sen-sor signals for these must have good representations in the model, because otherwise the ECU goes into fail-safe

Speed

CamPhase

IntakeWindow

Fifo

Fifo

SparkAdvance Ignition

Signals

InjectionSignals

4 KnockSignals

Slave DSP

DPR

AM

IntakeWindow

FuelAmount

KnockParam.

next DS2211 (<8 cyl.)

Engine PositionPhase

Accumulator

CrankshaftSignal Generator

(Wavetables)

2/4 x CrankshaftSignal Gen.(Wavetables)

Signal Cond.and ComplexComparator

Signal Cond.and ComplexComparator

KnockProcessor

IgnitionEvent

Capture

InjectionEvent

Capture

8 Channels

8 Channels Engi

ne P

ositi

on B

us (4

MH

z)

Add

er

Real-Time Processor

PHS-

Bus

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.

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.

mode, or it is even impossi-ble to start the engine in the simulation. For de-tailed information on engine simula-tions and engine models, please refer to [HP07].

3.1.2 Vehicle Dynamics ECUsElectronic stability program (ESP) perform selective braking on single wheels to ensure that the slip angle is reduced, thereby stabilizing the ve-hicle in critical driving situations such as wet or icy roads. The driver’s inten-tion is detected by means of the steer-ing wheel angle. Sensors for the yaw rate (rotation around the vertical axis), lateral acceleration and wheel speed are used to determine the vehicle’s motion. In addition, relevant variables are estimated by means of an internal vehicle model (observer) [WR06]. An ESP is a safety-critical system. Sensors and actuators are monitored very precisely (by initialization and plausi-bility checks), so (for example) active,

HIL Overview 03/2016 9

intelligent wheel speed sensors with disturbance-proof current interfaces are used. ESP test systems have to fulfi ll 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].

Figure 10: HIL control loop for vehicle dynamics control systems: 12 measured valve control 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.

3.1.3 Electric Drives and Hybrid VehiclesElectrical 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-ously by the combustion engine via a belt or a chain, while an elec-tric steer-

CurrentController

Current Signal

Position Signal

3 Phase Voltages

VehicleApplication

Transmission

Controller Power Stage Electric Motor Mechanics

Signal Level Electric Power Level Mechanical Level

ApplicationController Sensor Signals

ECU

ing pump needs energy only when it actually has to support steering. The basic structure of an electrical machine in a vehicle is shown in fi gure 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 and currents for the electric motor. This generates torques on a vehicle component via mechanical shafts. For control, motor currents and the motor position are usually returned. A basic difference between electric machines and other vehicle compo-

Figure 11: Basic structure of electric drives in vehicles and the three possible inter-faces to an HIL system.

nents is that the machine is controlled at a very high clock rate (typ. 10-20 KHz). This makes high demands on the HIL simulation. I/O sampling rates in the millisecond range and mean value models, which are used for combus-tion engines, are not suffi cient for fast current and position control. Special FPGA-based hardware is needed for this. Figure 11 shows a generic FPGA board that can be equipped with applica-tion-specific modules, e.g. for measuring the PWM control signal or for simulating incremental encoders or resolvers (clock rate 40 MHz). Moreover, small model parts can be simulated directly on the FPGA to achieve simulation step sizes in the sub-µs range.

Figure 12: Generic FPGA board for the measurement, simulation and generation of signals in the sub-µs range.

Brake pressure sensor

12 x Valve signals

4 x wheel speedSteering wheel angleRotational speedLateral acceleration

ESP ECUValve signal detection unit

HIL Overview 03/201610

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 defi ned 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 NetworkThe 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

Figure 13: Typical ECU architecture of a top-of-the-range vehicle.

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-

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 reconfi guration 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.

Figure 14: Network simulator for testing of large heavy duty trucks.

HIL Overview 03/2016 11

3.3 Special HIL Solutions

3.3.1 Integrated Sensors and ActuatorsAs already shown in fi gure 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 fi gure 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-ture sensors by controlled hot plates.

ECU ECU

Real-time simulation Real-time simulation

Signalconditioning

Electricalinterface

Electricalinterface

Electricalinterface

Electricalinterface

Electricalinterface

Electricalinterface

Electricalinterface

Electricalinterface

Electricalinterface

Physicalinterface

Physicalinterface

Control of stimulus actuator

Feedback

Model of thevehicle process

Integratedsensor

Stimulusactuator

Signalconditioning

Controller

Outputdriver

Actuatorsimulation

Sensorsimulation

Model of thevehicle process

IntegratedActuator

Sensors

Controller

Outputdriver

a) HIL structure with integrated sensors b) HIL structure with integrated actuators

Figure 15: Integrated sensors and actuators: electrical interfaces are replaced by physical interfaces [LW00].

ESP ECUs also require special mea-surement equipment, as the coils for controlling the twelve ESP valves are housed in the same enclosure as the ESP controller, so only the effect of the control (i.e. the magnetic fi eld) can be captured by Hall sen-sors (see the valve signal detection on the left of fi gure 9).The stimulation of internal sensors can even mean that to stimulate internal accel-eration and yaw rate sensors, the entire ESP ECU, includ-ing valve signal detec-tion, has to be mounted on a rotatable 3-D motion platform that is connected with the actual HIL simulator via a multichannel slip ring system (fi gure 16) [FPS09]. 3.3.2 Test Bench Integra-tion

Figure 16: 3-D motion platform with ESP ECU and valve signal detection unit for stimulating integrated acceleration and yaw rate sensors.

HIL Overview 03/201612

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 mechanical axle test benches for function devel-opment and verifica-tion for active chassis has also been published.

4 SummaryThis paper provides an overview of hardware-in-the-loop technology. The differ-ent HIL components were presented and some application fields from automotive engineering were described. Although the ex-amples largely come from the field of passenger vehicles, it should be added that HIL is also widely used in the com-mercial vehicle and construction equipment industries, as well as in motor racing. Outside automotive engineering, HIL is being employed successfully in aerospace and defense, in ship engineering and in industrial automation.There are many topics that could only be mentioned briefly in this article, or which had to be left out completely, such as driver assistance systems, as well as test methods and processes. These are described in detail in the reference literature (especially [S08] and [WR06]).

Figure 17: Example of an HIL simulator for testing electrical steering systems. The mechanical loads that are applied to the steering system on the test bench are the same as those that occur in the vehicle.

Literature3)

[AS09] AUTOSAR, Automotive Open System Architecture. www.autosar.org, 2009.

[C09] CONTINENTAL AUTOMO-TIVE: Integrated Control Unit for Double-Clutch Transmission (DCT). www.conti-online.com, 2009.

[FPS09] FILGERDAMM, A.; PLÖGER, M; SCHULTE, T.: HIL-Simulation für me-chatro-nische automotive Steuergeräte. Elektronik Automotive, 3/2009.

[HP07] SCHÜTTE, H.; PLÖGER, M.: Hardware-in-the-Loop Testing of Engine Control Units – A Technical Survey. SAE Paper No. 2007-01-0500, www.sae.org, SAE Global Congress, Detroit, 2007.

[LW00] LAMBERG, K.; WAELTER-MANN, P.: Einsatz der HIL-Simulation zum Test von Mechatronik-Kom-ponenten in der Fahr-

zeugtechnik. 2. Tagung „Mecha-tronik im Auto-mobil”, Haus der Technik, München, November 15-16, 2000.

[MB01] MICHALSKY, T.; BÜDEN-BENDER, M.: Testing transmission ECUs with in-tegrated Sensors. Au-toTechnology, Vol. No. 1, June 2001.

[S08] SAX, E. (Hrsg.): Automa-tisiertes Testen einge-betteter Systeme in der Auto-mobilindustrie. Carl Hanser Verlag, München, 2008.

[SPD+01] SCHÜTTE, H.; PLÖGER, M.; DIEKSTALL, K.; WAEL-TERMANN, P.; MI-CHALSKY, T.: Testsys-teme im Steuergeräte-Entwicklungsprozess. ATZ/MTZ-Sonderheft Automotive Electronics, March 2001.

[SW05] SCHÜTTE, H.; WAELTER- MANN, P.: Hardware-in-

3) For more literature please see www.dspaceinc.com/go/hil-literature

HIL Overview 03/2016 13

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-in-the-Loop Applications with In-Cylinder Pressure Sensors. SAE Paper No. 2007-01-1303, www.sae.org, SAE Global Congress, Detroit, 2007.

[WR06] WALLENTOWITZ, H.; REIF, K. (Hrsg.): Handbuch Kraftfahrzeugelektronik – Grundlagen, Komponent-en, Systeme, Anwend-ungen. Vieweg Verlag, Wiesbaden, 2006.

[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.

Dr. Peter Waeltermann has a Master’s degree (Dipl.-Ing.)

in Mechanical Engi-neering / Mecha-tronics and a Dr.-Ing. (Ph.D.) degree from the University of Pa-derborn, Germany. He worked with dSPACE

GmbH in Paderborn, Germany, since 1999, where he held different

management positions in the area of hard-ware-in-the-loop (HIL) simulation

and project engineering. In the summer of 2014, he moved

to dSPACE Inc. (USA) to take over a position as Business Direc-tor.

On October 1, 2014, Peter became the President of dSPACE Inc.

www.dspace.com

Germany

dSPACE GmbHRathenaustraße 2633102 PaderbornTel.: +49 5251 1638-0 Fax: +49 5251 16198-0 info@dspace.de

China

dSPACE Mechatronic Control Technology (Shanghai) Co., Ltd. Unit 1101-1105, 11F/LMiddle Xizang Rd. 18 Harbour Ring Plaza200001 ShanghaiTel.: +86 21 6391 7666 Fax: +86 21 6391 7445 infochina@dspace.com

United Kingdom

dSPACE Ltd.Unit B7 . Beech HouseMelbourn Science ParkMelbourn Hertfordshire . SG8 6HBTel.: +44 1763 269 020Fax: +44 1763 269 021info@dspace.co.uk

Japan

dSPACE Japan K.K.10F Gotenyama Trust Tower4-7-35 KitashinagawaShinagawa-kuTokyo 140-0001Tel.: +81 3 5798 5460Fax: +81 3 5798 5464info@dspace.jp

France

dSPACE SARL7 Parc Burospace Route de Gisy91573 Bièvres CedexTel.: +33 169 355 060Fax: +33 169 355 061info@dspace.fr

USA and Canada

dSPACE Inc.50131 Pontiac TrailWixom . MI 48393-2020Tel.: +1 248 295 4700Fax: +1 248 295 2950info@dspaceinc.com

04/2016

© 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.