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

net/publication/215499194

Interface Design for Hardware-in-the-Loop Simulation

Conference Paper · July 2006

DOI: 10.1109/ISIE.2006.295703

CITATIONS READS
26 1,138

3 authors, including:

Wilfried Elmenreich
Alpen-Adria-Universität Klagenfurt
303 PUBLICATIONS 5,046 CITATIONS

SEE PROFILE

All content following this page was uploaded by Wilfried Elmenreich on 26 May 2014.

The user has requested enhancement of the downloaded file.

© IEEE, 2006. This is the author's version of the work. Personal use of this material is permitted. However, permission to reprint/republish
this material for advertising or promotional purpose or for creating new collective works for resale or redistribution to servers or lists, or to
reuse any copyrighted component of this work in other works must be obtained from the IEEE. The definite version is published in Proc.
IEEE Symp. on Industrial Informatics (ISIE'06), Montreal, Canada, 2006.

Interface Design for Hardware-in-the-Loop Simulation

Martin Schlager Wilfried Elmenreich Ingomar Wenzel
Vienna University of Technology Vienna University of Technology Vienna University of Technology
Vienna, Austria Vienna, Austria Vienna, Austria
[email protected] [email protected] [email protected]

Abstract – This paper presents a scalable approach to inter- • It is possible to develop a control system and to perform
face between a time-triggered distributed hardware-in-the- tests, even if the environment, i.e., the controlled object, is
loop (HIL) simulator and the system under test (SUT) via not accessible during development.
Smart Virtual Transducers (SVTs). An SVT is an element
of an HIL simulator and implements two interfaces – a stan- • It is possible to test the behavior of a control system in haz-
dardized digital interface to a time-triggered transducer net- ardous situations. In the real environment it could be very
work and a transducer-specific interface. costly (e.g., crash test) or even not feasible/acceptable (e.g.,
The main contribution of the approach is a separation of the emergency actions of an aircraft during flight) to guide the
execution of the simulation model and the deterministic in- system into such situations.
teraction via an arbitrary transducer interface. The benefit
of such separation is the temporal decoupling between sim- This paper presents concepts for establishing the interface be-
ulation model execution and interaction with the SUT. Fur- tween the SUT and a time-triggered hardware-in-the-loop (HIL)
thermore, the approach leads to a reduction of complexity of simulator. One approach involves the concept of a smart vir-
the simulation setup. tual transducer (SVT) that replaces the physical transducers of
The application of the approach is shown by an SVT proto- the SUT without probe effect [2]. If the SUT uses a transducer
type that is used to simulate a temperature sensor. network to access its transducers, we propose a gateway that per-
forms a cluster simulation of the replaced smart transducers. A
I. INTRODUCTION third approach to be mentioned is the physical emulation of the
Embedded applications tend to grow in size and complexity and SUT’s environment, however this approach is elaborate and not
require sophisticated test methods. One of these methods is always feasible. We present a case study that implements the
Hardware-in-the-loop (HIL) simulation, an approach that has first two approaches.
been introduced by the aerospace and defense industries in the The remainder of the paper is structured as follows: Subsequent
1950s [1]. At this time, the high costs of HIL technology could to this introduction, section II. describes general principles of
only be argued for systems, where human life or very expensive HIL simulation and specifically investigates on the coupling be-
prototypes would have to be put at risk. In the past decade, the tween an HIL simulator and the SUT. Section III. starts with a
tremendous advances of semiconductor industry, the subsequent short overview of a smart transducer (ST) and thereafter elabo-
easy accessability of powerful computing resource to virtually rates the concept of a smart virtual transducer (SVT). Section IV.
every engineer and the decreasing prices of simulation hardware presents a case study with a distributed SUT and an SVT proto-
led to further adoption of HIL simulation to domains like indus- type. Section V. includes a short summary of the paper.
trial control applications or automotive systems. II. HARDWARE-IN-THE-LOOP (HIL) SIMULATION
The role of HIL simulation and its benefits for the development
of real-time control systems is manifold. Potential benefits are: Hardware-in-the-Loop (HIL) simulation is a non-intrusive test
mechanism where the environment of an (embedded) SUT is
• Testing of early system prototypes in a simulated environ- simulated in order to perform tests on the SUT. In the litera-
ment becomes possible. ture, the SUT is often implemented on a single microcontroller.
However, HIL simulation is not restricted to testing only a single
• An ”artificial” environmental situation can be set-up that is device, but also a larger, distributed system. Figure 1 gives an
in accordance to a defined test scenario. overview of the basic parts of an HIL simulation. The outputs
• Effective monitoring is possible, because control values of a so called HIL simulator are used as inputs to the SUT. The
that would be invisible for bus monitoring facilities in the outputs of the SUT are used as inputs to the HIL simulator.
system-under-test (SUT) are received by the environmental With HIL simulation, the SUT is usually regarded as a black
simulator (and can be further processed, logged, etc.). box. Thus, only the interfaces of the SUT to its environment
are relevant. The HIL simulator provides simulation values to
• Once a simulation is set-up, it is possible to perform a large the SUT and monitors the reaction of the SUT, i. e., receives the
number of tests with no significant cost implications. outputs of the SUT.
 • The HIL simulation should be scalable and open.

• The HIL simulation should be of reasonable cost in terms

of HW/SW components and development time.

In the following we will elaborate the concept of an SVT that

supports the above mentioned considerations.
C. Coupling of HIL simulation and SUT
The SUT would normally interface its environment by means
Fig. 1: Basic parts of HIL simulation
of transducers, i. e., sensors and actuators. Inputs of the SUT
would be captured by sensors, outputs of the SUT would drive
In a pure software simulation which is sometimes also referred actuators. Thus, the coupling between the HIL simulator and
to as software-in-the-loop (SIL), no embedded hardware of the the SUT can either be established by emulating the transducer
SUT is involved. In contrast to a pure software simulation, HIL interface (i. e., the interface between SUT and transducer) or by
simulation allows to observe the actual influence of the hard- direct interaction with the physical transducers of the SUT.
ware characteristics of the SUT which includes the physical be- Figure 2 depicts three possibilities of interfacing the SUT. In
havior of hardware signals and the execution of the SUT in real- case a), the interfaces to the physical sensors or actuators are
time. Thus, testing with an HIL simulation is closer to the real emulated by an SVT. The X over the transducers of the SUT
application than a pure software simulation. Furthermore, HIL indicate, that these are not present in the HIL configuration. In
simulation can be applied in cases where protected intellectual many cases, the SVT has to generate or consume analog signals
property (IP) is involved. For instance, continuing changes of (in value and/or time domain), which affects the reproducibility
control algorithms in present traffic controllers and the need for of a test run. On the other hand, this approach affords minimal
manufacturers to maintain propriety is mentioned in [3] as a key intervention with the SUT and thus avoids probe effects at the
benefit for HIL simulation in the transportation systems domain. SUT.
There are many different examples of transducer-specific inter-
A. Open loop vs. closed loop HIL simulation facing schemes like for instance the range of an analog signal
We can distinguish between the two following approaches for that represents the measurement of an infrared sensor, the re-
HIL simulation: sponse behavior of an ultrasonic sensor, or a PWM signal for
an electrical motor. For coupling via transducer-specific inter-
Open loop HIL simulation: When HIL simulation is per- faces, different approaches can be found in literature. These
formed in an open loop, the generation of simulation data range from specific examples that are tailored to a certain class
by the HIL simulator is independent of the previous output of transducers to generic reconfigurable devices like for instance
data of the SUT. The output of the SUT is only captured the PXI-7831R FPGA I/O board from National Instruments [4].
for future evaluation purposes but has no influence on the In Figure 2 b), we assume that the SUT accesses its transducers
simulation data. Therefore, in an open loop scenario, the via a digital transducer network interface. In this case, we use
input data for the SUT can also be calculated off-line. a gateway node that emulates the smart transducers of the SUT
that are not present in the HIL configuration. If the interface
Closed loop HIL simulation: In a closed loop scenario, the between SUT and transducers is a predictable digital real-time
previous output of the SUT directly influences the calcu- network, the reproducibility of test runs is guaranteed. Thus,
lation of subsequent input data. Thus, the simulation data this approach is preferable over variant a), however it requires
must be calculated by the HIL simulator during runtime, that the SUT has an appropriate transducer network interface,
i. e., in real-time. thus being less flexible than a).
B. Aspects to be considered for an HIL simulation An example for coupling an HIL simulator with the SUT via the
OMG standardized smart transducer interface (OMG STI [5]) is
When setting up an HIL simulation, several aspects have to be given in [6].
taken into consideration. In [4] five key factors are mentioned Approaches a) and b) are usually chosen, when the physical
which are: transducer is not available or a certain test scenario can not be
established by interfacing the transducer. For example, if a fault
• The HIL simulation should accept a variety of SUT config- injection campaign involves transducers to exhibit a particular
urations. erroneous behavior, the use of real transducers is problematic.
• A small change in the SUT must not require complete re- Figure 2 c) depicts a configuration, where the SUT physically
design of the HIL simulation. keeps its transducers. In case of a sensor, the HIL simulator has
to drive an actuator that physically interacts with the sensor of
• The HIL simulation should be able to perform both open the SUT. In case of an actuator, the HIL simulator has to measure
and closed-loop testing. the actions of the actuator via a sensor that is connected to the
 of design principles for smart transducers as well as the com-
parison of two smart transducer interface standards, i. e., IEEE
1451.2 and OMG STI, is presented in [9].

Fig. 3: Smart Transducer (Atmel 4433 microcontroller and Sharp IR distance

sensor, scale in cm)

Fig. 2: Interfaces between HIL simulator and SUT B. Smart Virtual Transducer
In contrast to a smart transducer (ST), a smart virtual transducer
HIL simulator. The benefit of interfacing the SUT via a physical (SVT) does not contain a physical sensor or actuator element.
transducer is that no behavioral model of the physical transducer Instead, an SVT is used to emulate a sensor or actuator element.
is required. Thus, the coupling via the physical transducer is the Thus, an SVT consists of a processing unit, a communication
preferred approach, when it is infeasible (technically or econom- interface, and a transducer specific interface.
ically) to set up a sufficiently accurate model of the transducer. An SVT is either used to emulate the behavior of a physical sen-
In [7], an HIL simulator for an aerospace application (autopilot) sor or to emulate the behavior of a physical actuator. Thus, an
is mentioned that physically interfaces the SUT via an elevator SVT acts either as a virtual sensor or as a virtual actuator.
servo. Instead of modeling the internal physical behavior of the The concept of an SVT is not specifically tailored to a certain
elevator servo, the deflection of the physical servo is read from target system and can thus connect to any ”black box” without
a feedback potentiometer. having knowledge about the internal design of the ”black box”.
III. CONCEPT OF SMART VIRTUAL TRANSDUCER This ”black box” can e. g., be a smart transducer (without trans-
ducer element) as depicted in figure 4 or an arbitrary electronic
Smart virtual transducers (SVTs) are dedicated to an HIL simu- control unit (ECU). From the perspective of an SVT, only the
lation setup where the coupling between the HIL simulator and transducer interface is relevant. The possibility to connect to
the SUT is established via different transducer-specific inter- any kind of target system hardware allows a wide variety of SVT
faces (as represented by figure 2 a)). The concept of a smart simulation scenarios.
virtual transducer is closely linked to the concept of a smart An SVT that emulates a sensor must be provided with simula-
transducer. Thus, we will start with a brief explanation of smart tion data by a dedicated simulation host (refer to figure 2), an
transducers. SVT that emulates an actuator provides actuator data to the sim-
ulation host. The simulation host can either be implemented as
A. Smart Transducer
a transducer node and participate in the transducer network, or it
An intelligent or smart transducer is the integration of an ana- can be implemented as a more complex and powerful hardware
log or digital sensor or actuator element, a processing unit, and unit that is connected to the transducer network via a gateway
a communication interface. In case of a sensor, the smart trans- node.
ducer transforms the raw sensor signal to a standardized digital Communication between SVTs and the simulation host is han-
representation, checks and calibrates the signal, and transmits dled via the standardized transducer communication interface
this digital signal to its users via a standardized communication OMG STI [5]. The OMG STI allows deterministic communica-
protocol [8]. tion, with a predefined update rate of transmitted data between
Figure 3 depicts a smart transducer with an Atmel 4433 micro- the simulation host and the SVTs.
controller as processing and communication unit and a Sharp IR Communication between the SVT and the SUT via the trans-
distance sensor as physical sensor element. A closer description ducer interface of the virtual transducer requires more sophisti-
 However, we must take assumptions on the maximum change
rate of the environment variables consumed and manipulated by
the SUT, since the SVT must be fast enough to keep up with
changes in the environment. The environment variables must be
communicated to the SVTs at least with the Nyquist rate [10],
while the SVT performs a local filtering and extrapolation of the
data to be fed to the SUT.
C. Temporal decoupling of SVT elements
The requirement of independence (temporal decoupling) be-
tween the virtual transducer with its interface to the target sys-
tem and the remaining parts of the SVT leads to the following
partitioning within an SVT:

SVT logic with communication interface: The digital com-

munication interface is responsible for deterministic ex-
change of messages within the HIL simulator. In case the
SVT is configured to act as a virtual sensor, the SVT logic
receives simulated sensor values and regularly adjusts the
virtual sensor. In case the SVT is configured to act as a vir-
tual actuator, the SVT logic reads the actuation parameters
of the virtual actuator and forwards the values to the HIL
simulator.
Virtual transducer with VT interface: The transducer inter-
face of the virtual transducer shall resemble the inter-
face between the target system and a particular transducer,
Fig. 4: Elements of a Smart Virtual Transducer (SVT) which would be expected by the target system. Thereby, the
value domain as well as the time domain must be consid-
ered. Especially for applications that use the response time
cated inspection. Requests from the target system to perform a of a sensor for the calculation of a measurement (e. g., ul-
sensor reading of a virtual sensor or to set a virtual actuator are trasonic sensor), the timeliness of the virtual transducer re-
not under control of the SVT. Such a request can e. g., be the sponse is important.
reading of a D/A value (virtual IR sensor), measuring the delay
of a response (virtual ultrasonic sensor), setting a PWM signal D. Types of SVTs
(virtual PWM actuator). We distinguish between two types of SVTs: (a) SVTs that mimic
Regarding predictability of the occurrence of requests from the the behavior of a sensor, i. e., smart virtual sensor and (b) SVTs
target system, we have to distinguish between two different that mimic the behavior of an actuator, i. e., smart virtual actua-
cases: tor.
Physical sensor devices can offer sensor data in the value and/or
Synchronized: The HIL simulator, i. e., the SVT network, is
in the time domain. Both kinds of sensors must be reflected by
synchronized to the SUT and has a priori knowledge about
a smart virtual sensor. An example of a sensor that delivers sen-
the instants when the SUT reads its sensors or updates its
sor data in the value domain is an infrared distance sensor. The
actuators. In order to achieve this, the design of the SUT
processing unit that interfaces the IR distance sensor receives an
has to be known to the extend of the timing of all possible
analog signal from the sensor that reflects the last measured dis-
task activations of tasks that access the transducers.
tance. An example of a sensor that delivers sensor data in the
Unsynchronized: The SUT is handled as a black box; we as- time domain is an ultrasonic sensor. An ultrasonic sensor is trig-
sume that the SUT can access a virtual transducer at any gered by a processing unit to send out an acoustic signal. As
point in time. Therefore, the SVT has to provide a valid soon as the acoustic signal is echoed back to the sensor, the sen-
sensor value at any instant and, respectively, has to log new sor informs the processing unit about the reception of the acous-
actuator settings instantly. tic signal. The processing unit calculates the time from sending
the signal until the reception of the signal in order to get a dis-
While the synchronized approach eases the design of the SVT tance measurement.
and supports replicable results at least in the time domain, the Similar to sensor devices, physical actuator devices require dis-
unsynchronized approach is more flexible since it supports any tinguishing between value and time domain. There are many
SUT without requiring knowledge about its internal timing. different devices that can be operated by setting an analog
 Fig. 5: Case study with a distributed SUT

value (LEDs, simple electric motors, . . . ). However, also time- a certain point in time. Furthermore, monitoring of timing vi-
dependent signals must be taken into account. An application olations of the execution of a simulation model can be easily
could send for instance a PWM signal to drive an actuator. performed by an SVT.
For our prototype in section IV., we decided to build a smart Another aspect supported by the SVT approach is reusability.
virtual sensor that is capable to emulate sensors that operate in Since the implementation of a SVT mainly depends on the
the value domain. Support for sensors that operate in the time transducer that is replaced, an SVT can be reused in other ap-
domain is planned for a future implementation. plications whenever the same kind of transducer is employed.
Although features like the frequency of the update value and
E. Update Rate at Virtual Transducer Interface smoothing parameters depend on the control environment, these
The update rate of transducer data that is sent via the transducer functions can be generically implemented and parametrized for
interface of the virtual transducer can be greater than the update a particular application.
rate of transducer data that is transmitted via the communication The presented approach is scalable in the sense that it is not re-
interface of the SVT. In case it is not sufficient to take the last stricted to a certain amount of participating SVTs within an HIL
transmitted value, more sophisticated services can be realized by simulator. The use of a standardized interface for the communi-
the SVT logic. Examples for such services are interpolation or cation with the simulation host allows easy adaption of existing
extrapolation functions for a smart virtual sensor or the average simulation setups.
of several actuation values for a smart virtual actuator. The approach is open to any kind of ”black box”, i. e., any
transducer-specific interface can be implemented on an SVT.
F. Benefits of our approach Thus, integration tests, both open loop and closed loop, of a
wide variety of SUT configurations can be performed with our
The concept of SVT leads to a separation of concerns and thus approach.
to a reduction of the mental complexity when setting up an HIL The cost of the HW components of an HIL simulator with SVTs
simulation. The simulation model that is executed at the sim- is pretty low. The simulation host can be implemented on a stan-
ulation host is decoupled from the specific SVT elements that dard desktop computer and the SVT elements are inexpensive (a
interact with the SUT. Thus, it is not necessary to include the few euros per SVT).
behavior of a certain transducer element in the simulation model
at the simulation host. Changes of transducer elements (e. g., up-
IV. CASE STUDY
grade of a transducer to a newer model) do not directly influence
the simulation model because the behavior of the transducer is The case study involves a distributed SUT that consists of three
hidden by the SVT. A re-design of the simulation model can in nodes interconnected by a TTP/A fieldbus system [11].
general be avoided. Figure 5 depicts the components of the case study. The control
The separation of the execution of the simulation model and the node contains a PI controller and two analog sensor interfaces,
interaction between HIL simulator and SUT also leads to tem- one for the actual value and one for the setpoint value. The first
poral decoupling (temporal firewall), i. e., a simulated value is sensor interface is identical to the interface of a LM335Z tem-
required to be available within a certain time interval but not at perature sensor from National Semiconductor. The other sensor
interface is connected to a potentiometer that gives the setpoint The main contribution of the presented approach is the sepa-
value. The display node receives the actual value, the set value ration of the simulation model execution and the deterministic
and the setpoint value from the network and displays them at a interaction between the HIL simulator and the SUT via an ar-
7-segment display. Another node acts as TTP/A master, a nec- bitrary transducer interface – thus, reducing mental complexity
essary time source in TTP/A networks. The actual target system and achieving temporal decoupling between simulation model
would also have an actuator (heating element) with a TTP/A in- execution and interaction with the SUT.
terface, in our setup this node is omitted and replaced by a sim-
VI. ACKNOWLEDGMENTS
ulated node.
The TTP/A network is used to broadcast the actual value (8 bit), This work has been supported in part by the Austrian FWF
the setpoint value (8 bit) and the set value (16 bit) by the control project TTCAR under contract No. P18060-N04 and by
node. The display node receives all three values, the gateway of DOC [ DOKTORANDENPROGRAMM DER ÖSTERREICHISCHEN
the simulation requires only the set value. The communication AKADEMIE DER WISSENSCHAFTEN ].
bandwidth is 19200 bit/sec; the cycle time of the cluster is 16,25
ms. The simulation host does not influence the communication REFERENCES
behavior of the SUT, thus there is no probe effect on the system. [1] S. Nabi, M. Balike, J. Allen, and K. Rzemien. An overview of
The simulation host is connected to the SUT by two different hardware-in-the-loop testing systems at Visteon. SAE technical
ways: The temperate sensor interface is connected by an SVT paper series, SAE International, 400 Commonwealth Drive, War-
that emulates the physical electric interface of the LM335Z. Fur- rendale, PA 15096-0001 USA, March 2004.
thermore, the simulation host emulates an actuator node on the [2] C. E. McDowell and D. P. Helmbold. Debugging concurrent
bus that reads and executes the set value. programs. ACM Computing Surveys, 21(4):593–622, December
The simulation host simulates a simple control path whereas the 1989.
set value from the TTP/A bus acts as input to the control path [3] Z. Li, M. Kyte, and B. Johnson. Hardware-in-the-loop real-time
and the resulting value is converted into an analog signal and simulation interface software design. In Proceedings of the IEEE
forwarded to the control node. The simulation system has been Intelligent Transportation Systems Conference, pages 1012–1017,
implemented in a compact way on a node with a TTP/A network Washington, D.C., USA, October 2004.
interface, an Atmel AVR Atmega168 microcontroller node and [4] National Instruments. LabVIEW FPGA in hardware-in-the-loop
an AD5330 digital/analog converter from Analog Devices. Fig- simulation applications, 2003.
ure 6 depicts the hardware used for the simulation system. In [5] OMG. Smart Transducers Interface V1.0. Available Speci-
future applications this node will be used as an SVT within a fication document number formal/2003-01-01, Object Manage-
network of SVTs and a more powerful simulation host. ment Group, Needham, MA, U.S.A., January 2003. available at
http://doc.omg.org/formal/2003-01-01.
[6] M. Schlager. A simulation architecture for time-triggered trans-
ducer networks. In Proceedings of the First Workshop on Intelli-
gent Solutions for Embedded Systems (WISES’03), pages 39–49,
Vienna, Austria, June 2003.
[7] M. Gomez. Hardware-in-the-loop simulation. Available at
http://www.embedded.com, November 2001. Embedded Sys-
tems Programming, CMP Media LLC, 600 Harrison Street, San
Franzisco, CA, 94107.
[8] H. Kopetz, M. Holzmann, and W. Elmenreich. A universal smart
transducer interface: TTP/A. International Journal of Computer
Fig. 6: Prototype of a Smart Virtual Transducer with D/A Converter System Science & Engineering, 16(2):71–77, March 2001.
[9] W. Elmenreich and S. Pitzek. Smart transducers – principles,
V. CONCLUSION communications, and configuration. In Proceedings of the 7th
IEEE International Conference on Intelligent Engineering Sys-
In this paper, we presented an approach for the coupling of a tems, volume 2, pages 510–515, Assuit – Luxor, Egypt, March
hardware-in-the-loop (HIL) simulator and the respective system 2003.
under test (SUT) via so called smart virtual transducers (SVTs).
[10] H. Nyquist. Certain topics in telegraph transmission theory.
We started with a brief investigation on benefits and basic Transactions of the A.I.E.E., 47:617–644, February 1928.
concepts of HIL simulation. Focus was on the coupling between
[11] F. Skopik, M. Wihsböck, and W. Elmenreich. Anbindung einer
HIL simulator and SUT. Such coupling can be established
Regelstreckensimulation an ein zu prüfendes System mittels eines
via the transducer interface or via a physical transducer. The
Smart Inverted Transducers. Research Report 2/2006, Technische
concept of an SVT offers coupling of an HIL simulator with the Universität Wien, Institut für Technische Informatik, Treitlstr. 1-
SUT via an arbitrary transducer interface. We concluded the 3/182-1, 1040 Vienna, Austria, 2006.
paper with a case study that presented an SVT prototype.