Do you use hardware-in-the-loop simulation?

Wednesday, November 16th, 2011 by Robert Cravotta

While working on some complex control systems for aerospace projects, I had the opportunity to build and use hardware-in-the-loop (HIL or HWIL) simulations. A HIL simulation is a platform where you can swap different portions of the system between simulation models and real hardware. The ability to mix simulated and real components provides a mechanism to test and characterize the behavior and interactions between components. This is especially valuable when building closed-loop control systems that will perform in conditions that you do not fully understand yet (due to a lack of experience with the operating scenario).

Building a HIL simulation is an extensive effort. The simulation must be able to not only emulate electrical signals for sensors and actuators, but it may also need to be able to provide predictable and repeatable physical conditions, such as moving the system around on six degrees of freedom based on real or simulated sensor or actuator outputs. As a result, HIL can be cost prohibitive for many projects; in fact, to date the only people I have met that have used HIL worked on aircraft, spacecraft, automotive, and high-end networking equipment.

I suspect though with the introduction of more sensors and/or actuators in consumer level products, that HIL concepts are being used in new types of projects. For example, tablet devices and smartphones increasingly are aware of gravity. To date, being able to detect gravity is being used to set the orientation on the display, but I have seen lab work where these same sensors are being used to detect deliberate motions made by the user, such as shaking, lowering, or raising  the device. At that point, HIL concepts provide a mechanism for developers to isolate and examine reality versus their assumptions about how sets of sensors and/or actuators interact under the variation that can occur under each of these use scenarios.

In my own experience, I have used HIL simulation to characterize and understand how to successfully use small rocket engines to move and hover a vehicle in the air. The HIL simulation allowed us to switch between real and simulated engines that moved the system. This kind of visibility was especially useful because operating the vehicle was dangerous and expensive. Another HIL simulation allowed us to work with the real camera sensor and physically simulate the motion that the camera would experience in a usage scenario. In each of these simulation setups, we were able to discover important discrepancies between our simulation models and how the real world behaved.

Are HIL simulation concepts moving into “simpler” designs? Are you using HIL simulation in your own projects? Is it sufficient to work with only real hardware, say in the case of a smartphone, or are you finding additional value in being able to simulate specific portions of the system on demand? Are you using HIL in a different way than described here? Is HIL too esoteric a topic for most development?

Tags: , , ,

4 Responses to “Do you use hardware-in-the-loop simulation?”

  1. John says:

    Hi Robert,

    Marine Cybernetics is currently developing HiL systems for maritime Dynamic Positioning Systems, Power Management Systems, and for oilfield Drilling Packages.


  2. Hi Robert,

    At MathWorks, we have customers using xPC Target to perform hardware-in-the-loop simulation and real-time rapid control prototyping on a wide variety of applications. Usage is very strong in Aerospace and Automotive areas, but we also see customers emerging in other application areas who are now conducting real-time testing, such as wind turbines, solar power inverters, medical devices, office equipment, and industrial robotics. All of these applications increasingly require embedded systems to control and monitor these systems. Using HIL Simulation is a great way to do a full range of testing in the lab, even conducting tests that would be at the edge of the operating envelope or difficult to do on actual hardware in the field.

    - Brian

  3. J. @ LI says:

    We develop industrial controllers that must communicate with several fieldbus networks simultaneously, in adittion to handling several ADC and sensor streams. The instruments may have user interfaces through serial port terminals or fieldbus HMI panels, and must attend to possibly smultaneous control loops over the fieldbus networks.

    To test and verify the design, we use a layered test strategy. At the lowest level, static analysis and simulaton are employed, to validate algorithms and local functional behavior. This is done by the developer, using a software simulator on pieces of the compiled code, to catch basic design flaws and complex detailed interrupt and low-level behavior.
    After this level, the system is tested directly in hardware.

    As you said, hardware-in-the-loop simulation and testing is a very ad-hoc and broad field.
    We use several automated simulation engines, made in-house, to exercise and simulate complex scenarios on the fieldbus ports. These tests use PLCs programmed with command test sequences, with capability to perform random sequences and detect and capture unexpected responses. Usually these are performed on the complete system, sometimes with realtime capture of hardware signals using a Mixed Signal Oscilloscope with serial/parallel bus protocol decoding to detect problems under heavy processing loads.
    All these tests need to be non-intrusive, so the simulation involves generating real-life conditions and having the real system perform under observable conditions. Using an MSO oscilloscope is invaluable to analyse and verify behavior in real-time.

    Another approach we use is unit testing using subsystem isolation and wrappers at selected points of the interface. This unit testing allows a broader range of test vectors to be done in layers of the logic that are not accessible in normal operation, and can be done using HIL also. The test vectors can create impossible scenarios to exercise fault handling and meta stable conditions to explore logic vulnerabilities. The tools we use for that are also designed internally, using C++ in a Windows platform as the test vector driver/logger. Sometimes, the HIL setup is actually embedded in the instrument itself, and run as another task in the target processor. This approach allows deep access to function interfaces while a subsystem is running.

    We do not use “traditional” HIL modelling, using MATLAB/SIMULINK, for example. The control models involved in our systems are either too simple to require this level of modelling, or complex enough to require real circuit evaluation, instead of an idealized model.

    - Jonny

  4. saurabh says:

    Hi all

    Actually we do have a client requirement of designing a Hardware-in-the-loop simulator. the Client is a market giant in the mineral ore drilling industryand they want the “HWIL” simulator for their drill Rigs. They do have a Linux based DAS( drill Rig Automation System) with all the I/os controlled by the same. Our challenge is to develop a “HWIL” simulation application and hook it up with their DAS.

    CAn any one help me in understanding the different s/w packages which can be used for the purpose, we are considering the Math works Simulink kind of softwares but have a very limited knowledge about the same. so can any one help us out in understanding like how to use different software packages available to serve the purpose.

Leave a Reply