In-vehicle driving tests for evaluating the performance and diagnostic functionalities of engine control systems are often time consuming, expensive, and not reproducible. Using a hardware-in-the-loop (HIL) simulation approach, new control strategies and diagnostic functions on a controller area network (CAN) line can be easily tested in real time, in order to reduce the effort and the cost of the testing phase. Nowadays, spark ignition engines are controlled by an electronic control unit (ECU) with a large number of embedded sensors and actuators. In order to meet the rising demand of lower emissions and fuel consumption, an increasing number of control functions are added into such a unit. This work aims at presenting a portable electronic environment system, suited for HIL simulations, in order to test the engine control software and the diagnostic functionality on a CAN line, respectively, through non-regression and diagnostic tests. The performances of the proposed electronic device, called a micro hardware-in-the-loop system, are presented through the testing of the engine management system software of a 1.6 l Fiat gasoline engine with variable valve actuation for the ECU development version.

1. ISA Transactions 51 (2012) 229–236
Contents lists available at SciVerse ScienceDirect
ISA Transactions
journal homepage: www.elsevier.com/locate/isatrans
A portable hardware-in-the-loop (HIL) device for automotive diagnostic
control systems
A. Palladinoa,∗
, G. Fiengoa
, D. Lanzob
a
Engineering Department, Università degli Studi del Sannio, Piazza Roma 21, 82100 Benevento, Italy
b
Automotive Center, MediaMotive, Centro Direzionale, Isola A2, 80143 Napoli, Italy
a r t i c l e i n f o
Article history:
Received 22 April 2010
Received in revised form
14 September 2011
Accepted 5 October 2011
Available online 8 November 2011
Keywords:
Hardware-in-the-loop (HIL) simulations
Electronic control unit (ECU)
Diagnostic test
Regression test
Testing software
a b s t r a c t
In-vehicle driving tests for evaluating the performance and diagnostic functionalities of engine control
systems are often time consuming, expensive, and not reproducible. Using a hardware-in-the-loop (HIL)
simulation approach, new control strategies and diagnostic functions on a controller area network (CAN)
line can be easily tested in real time, in order to reduce the effort and the cost of the testing phase.
Nowadays, spark ignition engines are controlled by an electronic control unit (ECU) with a large number
of embedded sensors and actuators. In order to meet the rising demand of lower emissions and fuel
consumption, an increasing number of control functions are added into such a unit.
This work aims at presenting a portable electronic environment system, suited for HIL simulations,
in order to test the engine control software and the diagnostic functionality on a CAN line, respectively,
through non-regression and diagnostic tests. The performances of the proposed electronic device, called a
micro hardware-in-the-loop system, are presented through the testing of the engine management system
software of a 1.6 l Fiat gasoline engine with variable valve actuation for the ECU development version.
© 2011 ISA. Published by Elsevier Ltd. All rights reserved.
Contents
1. Introduction.................................................................................................................................................................................................................... 229
2. Background and motivation .......................................................................................................................................................................................... 230
3. MHIL test system............................................................................................................................................................................................................ 231
4. Diagnostic functionality testing .................................................................................................................................................................................... 232
5. Experimental software validation................................................................................................................................................................................. 232
6. Conclusions..................................................................................................................................................................................................................... 235
Acknowledgments ......................................................................................................................................................................................................... 235
References....................................................................................................................................................................................................................... 235
1. Introduction
Hardware-in-the-loop (HIL) simulation methodology is recog-
nized as an useful and effective approach in testing automotive
control strategies and diagnostic functionalities. Nowadays, the re-
quirements of an electronic control unit (ECU) are hard to obtain
due to the increasingly stringent emission normative and ambi-
tious performance in terms of fuel consumption and power re-
quirements. On the other hand, the high competitiveness among
car makers is creating a continuous reduction of time to mar-
ket and development costs. Therefore, the need for more efficient
∗ Corresponding author. Tel.: +39 0824 305585; fax: +39 0824 325246.
E-mail addresses: angelo.palladino@unisannio.it (A. Palladino),
gifiengo@unisannio.it (G. Fiengo), domenico.lanzo@mediamotive.it (D. Lanzo).
methodologies arises, aimed at extensive testing of the hardware
and software components of the ECU [1,2]. For this purpose, the HIL
simulation approach is widely adopted thanks to its compatibil-
ity in replacing significant portions of test procedures for different
control systems. It incorporates hardware components in a numer-
ical simulation environment, yielding results with better credibil-
ity than pure numerical simulations. HIL experiments run in real
time and also make possible test procedures that are difficult or
even impossible with real systems. This procedure, based on the
HIL approach, has been widely studied and successfully applied
in different engineering fields. In [3,4], an efficient real-time HIL
testing approach for control design in power electronics applica-
tions has been proposed. In particular, in [3], the authors have
developed a digital power controller for aerospace applications,
validated through hardware-in-the-loop testing using a virtual test
bed real-time (VTB-RT) approach, whereas in [4] the environment
system, realized with HIL configuration, has been applied in two
0019-0578/$ – see front matter © 2011 ISA. Published by Elsevier Ltd. All rights reserved.
doi:10.1016/j.isatra.2011.10.009

2. 230 A. Palladino et al. / ISA Transactions 51 (2012) 229–236
power electronic application examples, a boost converter and an
H-bridge inverter.
Moreover, modeling and simulation through the HIL approach
has been adopted for improving wind energy system control
strategies. In [5], it is exploited how a newly established real-time
HIL test facility can be utilized for wind energy research. The test
site uses two dynamometers and a variable voltage and frequency
converter to emulate a realistic dynamic environment, from both
a mechanical and an electrical point of view. In wind energy
research, in [6,7], an experimental failure diagnosis system based
on FPGA-in-the-loop hardware prototyping has been discussed
for verifying the performances of a fault-tolerant wind energy
conversion system.
In this paper, the authors address their attention to a car
engine control system to test the new control strategies and the
diagnostic functions. Engine control tasks, that were classically
solved mechanically, are now being replaced by electronic control
systems, and the design and implementation of control and
diagnostic algorithms is a crucial element in the development of
automotive engine control systems [8,9]. Furthermore, the engine
system and its components must be constantly monitored in
order to comply with the exhaust emissions limit specified by
international regulations in all driving situations. So, in recent
years, car makers have intensified their actions on innovative
functionalities and diagnosis to respect and monitor the emissions
related to the components and the whole system. In particular,
the development and calibration of ECU functions require a more
accurate tuning within the imposed constraints of costs and time to
market. Among the simulation methods, HIL testing represents the
most common procedure: a computer with a real-time simulation
model of the engine or vehicle system is connected to a real ECU in
order to test the final embedded software [10–12].
The advantages of adopting an HIL system are evident and have
been described above, where the main characteristics have been
highlighted. On the other hand, the main drawback is the necessity
to use accurate engine models for real-time simulations [13–15]
in order to be able to describe the dynamics of the system com-
ponents and their interactions. Moreover, the hardware necessary
to run appropriate simulations is complex to set up and extremely
expensive, requiring specific know-how of the personnel involved
in the tests.
In this scenario, the proposed device, called a micro HIL (MHIL)
system, has been developed to perform those experiments where
the commercial HIL simulator is unproductive in terms of time to
set up the experiments and costs of the devices. Therefore, the
main advantages of the MHIL technique are the simplicity of use
and portability [16].
The paper is organized as follows. First, an overview of the
background of an HIL system and the motivation for developing
a new system are detailed. The proposed electronic system is
then described in Section 3. Experimental results relating to the
diagnostic functionalities and software validation are discussed,
respectively, finally, in Sections 4 and 5, our conclusions end the
paper.
2. Background and motivation
A typical hardware-in-the-loop (HIL) system is shown in Fig. 1.
Here, the engine is modeled using Matlab/Simulink software and
it is simulated through a dedicated real-time hardware simulator.
This provides all electrical signals to fully exercise a real electronic
control unit (ECU), connected to the simulator, where the control
strategies are running.
The use of dSPACE devices is commonly adopted for HIL ap-
plications (see, among others, [17,18]). Fig. 1 shows the dSPACE
full-size simulator. The simulator is equipped with a real-time
Fig. 1. Typical hardware-in-the-loop system from dSPACE.
processor board and I/O unit. The processor is a DS1006 Board,
equipped with an AMD Opteron Processor at 2.2 GHz. This board
computes the model components for engine dynamics simulation.
To handle the simulator inputs and outputs, a DS2211 HIL I/O board
is used. This is the standard board for dSPACE HIL applications,
providing the entire I/O signals for the simulation of a typical eight-
cylinder engine, i.e. crankshaft angle synchronous signals, con-
troller area network (CAN) communication, and analog, digital, and
PWM I/O, including the necessary signal conditioning. Moreover,
a rack where, at the bottom, there is a remote-controlled power
supply unit simulates the battery and allows one to vary the volt-
age during the real-time simulation (undervoltage and overvoltage
tests, voltage drops during engine start, etc.).
The HIL approach is used by design and test engineers to
evaluate and validate components during development of new
control systems [19]. Rather than utilizing them in test bench
experiments, the HIL system allows the testing of new components
and prototypes while communicating with software models that
are simulating the rest of the system. This results in a significant
reduction of the costs and time to set up the experiments, and
increases the flexibility and efficiency of the testing phase.
In the literature, several HIL applications can be found to prove
the effectiveness of the methodology [20,21]. As an example,
in [22], an HIL system has been developed to test a commercial
antilock braking system (ABS) and electronic stability program
(ESP) ECU. Using the developed HIL system, the performances
of commercial brake ECUs were evaluated for a virtual vehicle
under various driving conditions. The system has been built in a
laboratory, providing convenient and reliable means for testing
multiple ABS and ESP modules.
The benefits of using an HIL system are evident both for
time saving, and as a consequence for cost saving, and for the
performance that it is possible to reach. But, on the other hand,
the drawback is the high cost of the hardware simulator and
the high level of skill and know-how necessary to configure
and run the complex simulations, including the need to use
mathematical models that are sufficiently accurate for the kind
of experiments required. Therefore, since the majority of the
experiments are simple tests regarding the validation of ECU
software, i.e. regression tests and diagnosis functionalities, this
makes the HIL system unsuited for this kind of experiments.
Regression tests are aimed at ensuring that any modified con-
trol software still meets the specifications. To this end, a basic

3. A. Palladino et al. / ISA Transactions 51 (2012) 229–236 231
approach consists of using the modified program during selected
maneuvers and monitoring that it preserves the validated perfor-
mance, comparing its output with a baseline. Conversely, a selec-
tive approach is based on the choice of a subset of the test pool that
can provide sufficient confidence of the system [23,24]: a test case
will be selected if and only if it executes at least one of the modified
functions that influences the behavior of the program [25,26]. [27]
gives an overview of the major issues involved in software regres-
sion testing, an analysis of the state of the research and the state
of the practice in regression testing in both academia and industry,
and a discussion of the main open challenges for regression testing
software.
Regarding the automotive embedded system, a crucial aspect
for engine development is to avoid regression of new ECU software
versions compared with previous ones, i.e. the absence of any
undesirable impact of new requirements on the part of the
software that is unchanged. This consideration is particularly true
for engine control systems, where the complexity is increasing and
the time to market is decreasing.
Similarly, regarding the diagnosis, the automotive industry has
to provide on-board health monitoring capabilities to meet leg-
islated diagnostic requirements for engine management systems.
Actually, there is an exhaustive literature about the diagnosis prob-
lem, which is analyzed from different points of view [28–30].
In particular, the real-time diagnostic functionalities of engine
management systems are devoted to monitoring the performance
of the electronic throttle body, variable valve timing, injectors
and ignition control systems, and to detect and identify a suite of
anomalies.
So there is a need to use a device that is able to automatically
perform this kind of test. Again, this device should be easy to
use and fast to set up. Consequently, it must not be based on
mathematical models but rather then on measurements so as to
generate the correct signals to provide to the ECU in order to verify
the embedded algorithm.
Finally, the solution proposed in this paper cannot replace an
expensive and complex HIL simulator, as those described above,
but it is a low-cost alternative for common and more simple
applications, such as regressive tests and diagnostic functionality
tests.
3. MHIL test system
The models for HIL simulation have an important role when
there is the need to close the control loop. In the new testing
device, presented here, the key aspect is that the experiments to
perform are open-loop tests, and consequently they do not require
models. MHIL has been thought as a system that is able to generate
input signals to an ECU and analyze the outputs. Starting from
data collected at a test bench or, alternatively, at an HIL during
selected maneuvers, these can be regenerated by the KBOX (a
purposely designed signal generator) to stimulate the ECU under
test. Then, the signals generated by the KBOX are elaborated by the
ECU control algorithms producing the commands for the engine
actuators, i.e. valves, injectors, and so on. Finally, these commands
are acquired and compared with a benchmark in order to verify
the correct functioning of the control algorithms performed by
the ECU. If any variation occurs, it can be attributed to a different
firmware version of the ECU or to unpredicted side effects due to
some modifications of the control algorithms.
A prototype of MHIL is shown in Fig. 2. It is formed by
two different hardware components: the core of the system,
KBOX, devoted to signal generation, and a console containing the
actuators (external loads; see Fig. 3) to be connected to the ECU.
The console is equipped with a power supply, to connect the
MHIL to the electric commercial network; a suited console with
Fig. 2. The MHIL hardware components: a console containing the actuators
(external loads), the ECU under test, and the signal generator (KBOX).
Fig. 3. External loads.
led and interruptors to simulate different vehicle status such as
key-on/key-off, clutch inserted/not inserted; a throttle valve; and
injectors, lambda probes, and electro-hydraulic valves. Moreover,
the MHIL console is equipped with a fan coil to reduce the heat
increase in the console, an RS232 port interface, and an ethernet
port to link the MHIL to the host computer.
The KBOX characteristics have been designed to make the
testing of engine control system flexible and suitable. In order to
stimulate all kinds of ECU input, such as pressure and temperature
sensors, crankshaft and camshaft sensors, and both inductive and
Hall effects [8], the KBOX is composed as follows.
• 16 analog outputs with a range between 0 and 5 V (maximum
10 mA);
• 16 digital outputs (maximum 100 mA);
• 8 output frequencies, such as camshaft/crankshaft signals,
configurable as VRS type (i.e. waveform square +/ − 12 V with
zero crossing) or Hall effect type (0/12 V);
• 2 outputs for knock signal (for variable setting of frequency and
width)
• 2 outputs for lambda probe UEGO;
• 2 CAN bus 2.0.
The user interface has been developed in a Matlab environment.
Fig. 4 shows the main panel. Here, the first step is to choose the
maneuver to run and upload the relative time history, i.e. the
collection of signals to generate, to the KBOX. Then it is possible
to configure the analog and digital channels to match the KBOX
outputs with the ECU inputs, and run the experiments. Finally, the
data can be collected and analyzed by means of the no regression
test (NRT) module.

4. 232 A. Palladino et al. / ISA Transactions 51 (2012) 229–236
Fig. 4. MHIL user interface.
4. Diagnostic functionality testing
The increased use of electronics in automobiles and the in-
creased complexity of modern fuel injection and emission systems
place high demands on the diagnostic problems, though the mon-
itoring of the vehicle during all operations. Commonly, diagnos-
tic functions are included in the ECU as standard components in
the electronic engine management system. In fact, during normal
functioning, a diagnosis of sensors and actuators connected to the
ECU operates. The diagnosis can be electrical and logical. Regard-
ing the latter, the ECU checks only the correctness of the incoming
signals; in contrast, for the electrical diagnosis, the ECU controls
also the electrical load scheduled at its extremities for that device.
Therefore, in order to prevent the ECU going into an alarm state
and, hence, stopping the experiment, the MHIL has to provide both
the correct signals and loads to overcome the diagnosis. To this
aim, external loads, connected directly to the ECU, are foreseen for
those sensors and actuators performing the electrical diagnosis.
For the other sensors, the signals are simulated by the KBOX.
In particular, crankshaft and camshaft position sensor signals are
created offline. The crank and camshaft sensor waveforms are
fixed (except for noise effects) as a function of crankshaft angle.
These two waveforms are created and stored before the real-time
simulation. A separate program, with a graphical user interface, has
been designed to create these two signals. This program also allows
the user to create crank and camshaft signals with a variety of
faults, using a different frequency channel for differential and Hall
effect sensor waveforms. Possible faults which can be created by
the program include missing peaks in the crank or camshaft sensor,
changes in width or height of chosen parts of the signal (usually the
peaks), and the addition of sensor noise. It is also possible to inject
these faults while the real-time simulation is running. Any errors
or faults detected are stored in the ECU memory, and stored fault
information can be read via a serial interface.
Moreover, the communication with other ECUs present in the
vehicle (as an example the electronic stability program, ESP-ECU) is
performed, over the controller area network (CAN) bus. The benefit
is that the CAN protocol contains a control mechanism to detect
malfunctions, with the result that transmission errors are even
detectable by the CAN module. Since the majority of CAN messages
are sent at regular intervals by the individual ECU, the failure of a
CAN controller is detectable by testing at regular intervals.
A CAN is one of the communication standards defined both
in European and American OBD standards. From 2008, the CAN
protocol will be the only permitted interface for OBD II diagnostics
in the USA.
The CAN bus allows multiple devices to be linked together. A
typical vehicle architecture is illustrated in Fig. 5. The communi-
cation protocol shows several advantages for car makers. Firstly,
ABS Module
Airbag Module
Engine
Management
Module
Active
Suspension
Module
Transmission
Control Module
CANLo
CANHi
CANLo
CANHi
CAN Hi
CAN LoDiagnostic
connector
Diagnostic port
gateway
Body Control
Module
Climate Control
Module
Driver Seat
Module
Passenger Seat
Module
Fig. 5. Typical vehicle architecture.
the CAN uses a two-wire solution (CAN Hi and CAN Lo); this en-
ables higher data rate than a solution with a single wire, such as a
K-Line, which is a common serial communication standard. In fact,
the EOBD specifies a maximum CAN data rate of 500,000 bit/s com-
pared with the K-Line data rate of 10,400 bit/s. Secondly, a CAN has
extensive error checking built into the format of each packet com-
posing the message.
Conventional tests nowadays performed can evaluate the
network management, gateway functionality, and CAN physical
level, but unfortunately there are many restrictions: the tests
can only be performed manually and they are not reproducible;
there is no automatic test report generation; and test coverage
is incomplete, so the CAN communication cannot be checked
thoroughly.
Now, considering that new vehicles generally use a CAN to
provide EOBD diagnosis, a key issue of the proposed MHIL is
the capability to communicate with the ECU under test through
the CAN bus. In this way, the device can fulfill the following
requirements necessary to test the diagnosis functionalities:
• read all pertinent ECU power drivers and signal outputs;
• log all CAN messages;
• interface to the diagnostic serial line;
• test for both development and production ECUs.
Fig. 6 reports an experiment in order to validate the diagnostic
functionalities provided by MHIL. In particular, Fig. 6 shows the
monitoring panel of the DIanalyzer, a diagnostic software tool
of the Fiat group, where two errors are present, due to the
lambda probe and electro-valve of the canister being disconnected.
This kind of experiment is necessary both to check hardware
functionalities and to evidence eventual bugs during the code
generation process on different hardware.
5. Experimental software validation
In engine control system development, the final software
release is the result of a sequence of releases, each one introducing

5. A. Palladino et al. / ISA Transactions 51 (2012) 229–236 233
Fig. 6. Diagnostic analysis.
Fig. 7. Step sequence of the no regression test.
new requirements. The testing phase of the final release can be
divided into three main steps.
• Testing module: this phase consists of verifying and validating
the software ECU implementation. It is useful when auto-
code generation tools are used (i.e. a Simulink model can be
used with a Target Link auto-code generator). In this case a
comparison between the algorithm model simulation results
and signals coming from the engine management system (EMS)
can be easily and quickly performed.
• Integration testing: the target is to verify that the single tested
module is correctly integrated in the overall software architec-
ture. This kind of test has the objective of verifying that the new
algorithms or modifications to the existing ones do not undesir-
ably affect the behavior of other modules. A part of this activity
is the verification that the software is not regressed compared
with the previous version (NRT).
• Functional testing: this is the final testing activity, also called
validation phase, and it has the target of validating the algo-
rithms with respect to functional requirements. It has to be car-
ried out after the calibration phase.
The no regression test is part of integration testing and it
consists of the steps shown in the flowchart in Fig. 7.
Considering a sequence of software releases, if the final release
software stresses undesirable effects of new requirements on the
part of the software that is unchanged, it is important to select a
benchmark software to use as reference, and then a no regression
test will be executed for remaining releases, in order to know
the release that is responsible for the undesirable behavior and to
restore the correct functionality.
In order to verify the performance of MHIL as a testing system
experimentally, two kinds of experiment have been conducted
to evaluate the MHIL ability to correctly reproduce the engine
signals acquired in a vehicle and sent to the ECU as input signals,
and to perform a comparison of ECU outputs in order to evaluate
the differences of control software for two different releases.
The first experiment compares the engine signals acquired in
a vehicle through environmentally dedicated hardware by ETAS
with simulation signals reproduced by MHIL and sent to the ECU
as input variables. The second experiment compares the variables
of two different software releases, related to a 1.6 l, four-cylinder
spark injection Fiat engine equipped with variable valve actuation
(VVA) system and turbocompressor.
To this aim, the first step is to collect data during a selected
maneuver in order to obtain the time history (TH) for the MHIL
device. Fig. 8 shows the comparison between vehicle acquisitions
(used to do the TH) and MHIL signal generation, respectively,
for the engine speed, torque signal, pedal position, and manifold
pressure during the cycle. Here, the authors show a comparison of
the rpm signals during the two acquisitions, the first in the vehicle
and the second after the MHIL generation, in order to show that the
ECU is always excited by the same input data set (Fig. 9).
The crankshaft position sensor generates 60 peaks per revolu-
tion, meaning a resolution of 6°/peak. For indexing purposes, two
of these peaks are empty, resulting in 58 peaks and 2 null out-
puts for revolution. The camshaft position sensor voltage output
has four peaks, corresponding to the four cylinders. Both signals
are first created offline as a function of crankshaft angle and after-
wards they are downloaded onto the KBOX system.
Once the data are collected and the maneuver has been
uploaded on the KBOX, it is possible to run the experiment
stimulating the ECU under test and monitoring its outputs. Finally,
a specific software tool has been purposely designed to perform
the NRT on the set of data previously obtained: the measured
signals are first synchronized and then compared simply by
superimposing them. The tool allows one to choose, for each signal,
the acceptable range of the error and the error type (i.e. for the
torque it can be 5 N m or 5%, while for spark advance is can be 1°

6. 234 A. Palladino et al. / ISA Transactions 51 (2012) 229–236
0
-5000-4000-3000-2000-1000010003000400050002000
50
Time s
100150200
CMEEETKC:1
RPMETKC:1
250300350400450
500100015002000
PREETKC:1
POSPDLA1ETKC:1
2500300035004000
-2000-1500-500-10000100015005002500300035002000
Time s
a b
50 100 150 200
50 100 150 200
A C
A C
Fig. 8. (a) The first plot compares experimental data (dotted red line) of the engine speed [rpm] and simulated results (solid green line); the second plot reproduces
experimental data of the torque signal [N m] and simulated results, (b) the first plot compares experimental data (dotted red line) of the pedal position [mV] and simulated
results (solid green line); the second plot reproduces experimental data of the manifold pressure [mbar] and simulated results. (For interpretation of the references to colour
in this figure legend, the reader is referred to the web version of this article.)
0.5
01
GLAMLAMETKC:1
2
0.550.60.650.70.75
TEMPCOOLACQ_DIAGETKC:1
0.80.850.90.9511.05
0123
ETASPETKC:1
QACOBJETKC:1
a b
Time s
A C C E50 100 150 200
Time s
50 100 150 200
-700-600-500-400-300-200-1000100200300400500600
Fig. 9. (a) The first plot compares experimental data (dotted red line) of the air/fuel ratio [−]and simulated results (solid green line); the second plot reproduces experimental
data of the water temperature [C] and simulated results, (b) the first plot compares experimental data (dotted red line) of the air mass flow [mg/cc] and simulated results
(solid green line); the second plot reproduces experimental data of the intake efficiency [−] and simulated results. (For interpretation of the references to colour in this
figure legend, the reader is referred to the web version of this article.)
of absolute error). The result of the post-processing is a picture, in
which different colors highlight if the variables under examination
differ more than the selected error thresholds. In particular, the
tool also takes into account the error quality, pointing out with
different colors the errors that are inside the allowed threshold. For
each plot, the NRT tool underlines in red the differences between
the two compared channels while the matching parts are in green.
The plot is yellow if the channels are out of alignment.
The results of the two experiments are reported from Figs. 10–
13. Figs. 10 and 11 show the results of the first experiment, i.e. a
comparison of signals acquired in the vehicle and signals acquired
on the MHIL system through ETAS ES591, an environmental device
customized to measure signals from an automotive electronic
control unit; in particular, the engine torque variable and
the volumetric efficiency variable have been analyzed. In this
experiment, both signals, inner variables calculated by the ECU, are
very similar, with an error lower then 5%; therefore it is possible to
affirm that MHIL has a good ability to reproduce the engine signals.
Conversely, Figs. 12 and 13, showing again the engine torque
and volumetric efficiency during the second experiment (different
software releases, implemented on the same ECU), show a good
coherence between signals. This means that regression is not
present and, as a consequence, the test confirms the equality for
the two different software releases. Details of the data are omitted
for confidential reasons.
Enginetorque[NM]
Comparison for Engine torque
250
200
150
100
50
0
0 20 40 60 80 100 120 140 160 180
Time s
Fig. 10. First experiment. Engine torque: comparison between data acquired from
the same ECU but with two different control software versions.
Finally, in this study, it is evident that the performances
obtained with both the MHIL and the tradition HIL system [31]
regarding the NRT procedure on several software releases are
similar. The real advantages of the new device are its cost (its
price is a tenth of that of a traditional HIL simulator), portability

7. A. Palladino et al. / ISA Transactions 51 (2012) 229–236 235
2
1.8
1.6
1.4
1.2
Volumetricefficiency[-]
Comparison for Volumetric efficiency
1
0.8
0.6
0.4
0.2
0
0 20 40 60 80 100
Time [s]
120 140 160 180 200
Fig. 11. First experiment. Volumetric efficiency: comparison between data
acquired from the same ECU but with two different control software versions.
160
140
120
100
80
Enginetorque[NM]
Comparison for Engine torque
60
40
20
0
-20
0 5 10 15
Time [s]
20 25 30 35
Fig. 12. Second experiment. Engine torque: comparison between data acquired
from the same ECU but with two different control software releases.
1.5
Comparison for Volumetric efficiency
1
0.5
Volumetricefficiency[-]
Time [s]
0
0 5 10 15 20 25 30 35 40
Fig. 13. Second experiment. Volumetric efficiency: comparison between data
acquired from the same ECU but with two different control software releases.
(it weighs nine kilos and has the dimension of a little bag, as shown
in Fig. 14), and its easy set-up. The cost of the MHIL, equipped with
load platform and independent power supply is a tenth of that of
the traditional system, the MHIL is portable so as to guarantee test
executions on desks in different laboratories, and the easy set-up
allows the control testing phase to be done by personnel who do
not have to be particularly skilled.
6. Conclusions
A portable electronic environment system, suited for HIL sim-
ulations, has been presented. The performances of the proposed
electronic device, called a micro hardware-in-the-loop system,
Fig. 14. Micro HIL system bag.
have been described through two kinds of non-regression test, con-
ducted to evaluate the differences in control software for devel-
opment ECUs. The first compares two different software releases,
related to a 1.6 l, four-cylinder spark injection Fiat engine equipped
with a variable valve timing (VVT) system and turbocompressor.
The second is performed for the same software release on two de-
velopment ECUs with different processors, having different hard-
ware characteristics. Moreover, with respect to previous work, in
this paper we present other results of tests on diagnostic function-
alities that are possible to execute with the MHIL system, showing
the same degree of accuracy obtained for the non-regression test.
The proposed device has been developed to perform those experi-
ments since the commercial HIL simulator is unproductive in terms
of time to set up the experiments and costs of the devices. There-
fore, the main advantages of the MHIL are the simplicity of use and
portability.
Acknowledgments
The authors would like to thank Media Motive, a consulting
company in automotive fields, for funding this work, and Elasis-
FPT, a research company of the Fiat group, for providing the
experimental data.
References
[1] Raman S, Sivashankar N, Milam W, Stuart W, Nabi S. Design and implemen-
tation of hil simulators for powertrain control system software development.
In: Proceeding of the American control conference. 1999.
[2] Lee W, Yoon M, Sunwoo M. A cost- and time-effective hardware-in-the-loop
simulation platform for automotive engine control systems. In: Proceedings
of the institution of mechanical engineers, Part D. Journal of Automobile
Engineering 2003;217(1):41–52.
[3] Jiang Z, Dougal R, Leonard R, Figueroa H, Monti A. 2006. Hardware-in-the-
loop testing of digital power controllers. In: IEEE applied power electronics
conference and exposition. Art. no. 1620645, pp. 901–906.
[4] Lu B, Wu X, Figueroa H, Monti A. A low-cost real-time hardware-in-the-loop
testing approach of power electronics controls. IEEE Transactions on Industrial
Electronics 2007;54(2):919–31.
[5] Li H, Steurer M, Shi K, Woodruff S, Zhang D. Development of a unified design,
test, and research platform for wind energy systems based on hardware-
in-the-loop real-time simulation. IEEE Transactions on Industrial Electronics
2006;55(4):1144–51.
[6] Karimi S, Gaillard A, Poure P, Saadate S. Fpga-based realtime power converter
failure diagnosis for wind energy conversion systems. IEEE Transactions on
Industrial Electronics 2008;55(12):4299–308.
[7] Lpez O, lvarez J, Doval-Gandoy J, Freijedo F, Nogueiras A, Lago A, et al.
Comparison of the fpga implementation of two multilevel space vector pwm
algorithms. IEEE Transactions on Industrial Electronics 2008;55(4):1537–47.
[8] Palladino A, Fiengo G, De Cristofaro F, Casavola A, Glielmo L. In cylinder
air charge prediction for vva system: experimental validation. In: Multi-
conference on systems and control. 2008.
[9] Oh SC. Evaluation of motor characteristics for hybrid electric vehicles using
the hardware-in-the-loop concept. IEEE Transactions on Vehicular Technology
2005;54(3):817–24.
[10] Ren W, Steurer M, Baldwin T. Improve the stability and the accuracy of
power hardware-in-the-loop simulation by selecting appropriate interface
algorithms. IEEE Transactions on Industry Applications 2008;44(4):1286–94.

8. 236 A. Palladino et al. / ISA Transactions 51 (2012) 229–236
[11] Bouscayrol A. Different types of hardware-in-the-loop simulation for electric
drives, in: IEEE international symposium on industrial electronics, Art. no.
4677304. 2008. p. 2146–51.
[12] Gawthrop P, Virden D, Neild S, Wagg D. Emulator-based control for actuator-
based hardware-in-the-loop testing. Control Engineering Practice 2008;16(8):
897–908.
[13] Ayasun S, Fischl R, Vallieu S, Braun J, Cadirli D. Modeling and stability analysis
of a simulation-stimulation interface for hardware-in-the-loop applications.
Simulation Modelling Practice and Theory 2007;15(6):734–46.
[14] Yoon M, Lee W, Sunwoo M. Development and implementation of distributed
hardware-in-the-loop simulator for automotive engine control systems.
International Journal of Automotive Technology 2005;6(2):107–17.
[15] Zhu W, Pekarek S, Jatskevich J, Wasynczuk O, Delisle D. A model-in-the-loop
interface to emulate source dynamics in a zonal dc distribution system. IEEE
Transactions on Power Electronics 2005;20(2):438–45.
[16] Palladino A, Fiengo G, Giovagnini F, Lanzo D. A micro hardware-in-the-loop
test system, in: IEEE European Control Conference. 2009.
[17] Costanzo F, De Manes M, Di Mare G, Ferrara F, Montieri A. Testing networked
ecus in a virtual car environment, SAE 2004-01- 1724. 2004.
[18] Schuette H, Waeltermann P. Hardware-in-the-loop testing of vehicle dynam-
ics controllers a technical survey, SAE paper 2005- 01-1660. 2005.
[19] Baronti F, Lenzi F, Roncella R, Saletti R, Tanna OD. Electronic control of
a motorcycle suspension for preload self-adjustment. IEEE Transactions on
Industrial Electronics 2008;55(7):2832–7.
[20] Du J, Wang W, Yang C, Wang H. Hardware-in-the-loop simulation approach to
testing controller of sequential turbocharging system. In: Proceedings of the
IEEE international conference on automation and logistics. 2007.
[21] Cebi A, Guvenc L, Demirci M, Karadeniz C, Kanar K, Guraslan E. A low cost,
portable engine electronic control unit hardware-in-the-loop test system. In:
Proceedings of the IEEE international symposium on industrial electronics.
2005.
[22] Hwang T, Rohl J, Park K, Hwang J, Lee KH, Lee K. et al. Development of hils
systems for active brake control systems. In: SICE–ICASE international joint
conference. 2006.
[23] Ali A, Nadeem A, Iqbal MZZ, Usman M. Regression testing based on uml
design models. In: IEEE international symposium on pacific rim dependable
computing. 2007.
[24] Korel B, Koutsogiannakis G, Tahat L. Application of system models in regre-
ssion test suite prioritization. In: IEEE international conference on software
maintenance, Art. no. 4658073. 2008. p. 247–56.
[25] Wu Y, Kao M-HCH. Regression testing on object-oriented programs. In:
Symposium on software reliability engineering. 1999.
[26] Elbaum S, Chin H, Dwyer M, Jorde M. Carving and replaying differential unit
test cases from system test cases. IEEE Transactions on Software Engineering
2009;35(1):29–45.
[27] Harrold M, Orso A. Retesting software during development and maintenance,
Proceedings of the 2008 frontiers of software maintenance, FoSM, Art. no.
4659253. 2008. p. 99–108.
[28] Rizzoni G, Min P. Detection of sensor failures in automotive engines. IEEE
Transactions on Vehicular Technology 1991.
[29] Conatsera R, Wagner J, Gantab S, Walkerb I. Diagnosis of automotive electronic
throttle control systems. Control Engineering Practice 2004;12(1):23–30.
[30] Butt Q, Bhatti A. Estimation of gasoline-engine parameters using higher order
sliding mode. IEEE Transactions on Industrial Electronics 2008;55(11):3891–8.
[31] Riegel A, De Cristofaro F, Montaldo I. Interactive optimization methodology for
robust base engine calibration. In: European automotive congress. 2007.