Hardware-in-the-loop (HIL) testing connects a real embedded controller to a real-time computer simulation of the machine, vehicle or process it controls. The controller reads simulated sensor signals and drives simulated actuators exactly as it would in service, so its hardware and software can be tested against realistic, repeatable and even dangerous scenarios without building or risking the real system.
HIL is one of the test methods covered in our complete guide to automated test equipment (ATE). This article explains how a HIL rig works, where it fits in development, how fast the simulation has to run, and when HIL pays for itself.
How hardware-in-the-loop testing works
In normal operation an embedded controller, such as an engine ECU, a battery management system or a motor drive, sits in a closed loop with the physical system: it reads sensors, computes, and commands actuators, and the physical system responds. HIL replaces the physical system with a mathematical model, called the plant model, running on a real-time target computer.
Every simulation step, the target computer reads the controller’s outputs, advances the plant model by one time step and writes new sensor values back. Because the loop runs in real time, the controller cannot tell it is not connected to the real machine. A host PC runs automated test sequences on top: it sets scenarios, injects faults, records signals and judges pass or fail.
Where HIL fits: MIL, SIL, PIL and HIL
HIL is the last of several “in-the-loop” stages in model-based development. Each stage puts more of the real product into the loop:
| Stage | What is real | What is simulated | Typical use |
|---|---|---|---|
| Model-in-the-loop (MIL) | Nothing; control algorithm as a model | Controller and plant | Design and tune the control algorithm |
| Software-in-the-loop (SIL) | Production source code, compiled for a PC | Plant and processor | Verify generated or hand-written code against the model |
| Processor-in-the-loop (PIL) | Code running on the target processor | Plant and I/O | Check timing, fixed-point behavior and compiler effects |
| Hardware-in-the-loop (HIL) | The complete controller: processor, I/O, power, firmware | The plant (machine, vehicle, process) | Integration, regression, fault and safety testing |
| Vehicle or system test | Everything | Nothing | Final validation and calibration |
Components of a HIL test rig
- Real-time target. A computer running a real-time operating system or an FPGA that executes the plant model at a fixed, deterministic step, with no missed deadlines.
- I/O hardware. Analog inputs and outputs, digital I/O, PWM capture and generation, encoder and resolver simulation, and bus interfaces such as CAN, CAN FD, LIN, FlexRay, EtherCAT or ARINC 429.
- Signal conditioning and loads. Level shifting, simulated sensor impedances, and real or electronic loads where the controller must drive actual current, such as injectors, solenoids or motor phases.
- Fault insertion. Relays that open a wire, short it to ground or to supply, or connect pins together, so diagnostics can be tested without damaging hardware.
- Programmable power. A supply that simulates battery voltage, cranking dips, load dumps and slow brown-outs.
- Plant model. Usually built in a modeling and simulation tool, or in LabVIEW, then compiled for the target; fidelity is chosen to match what the test needs to prove.
- Test automation and data. Scripted test cases, requirements tracing, signal logging and reports, ideally runnable unattended overnight for regression.
How fast does a HIL simulation have to run?
The plant model has to step fast enough that the controller sees smooth, realistic signals. A common rule is to run the model step 5 to 10 times faster than the fastest control loop it interacts with, and to keep total I/O latency small compared with that step.
Worked example: CPU or FPGA?
Vehicle body or thermal controller. The controller task runs every 10 ms (100 Hz). A model step of 1 ms, 10 times faster, is easy for a standard real-time processor.
Motor drive current loop. The controller samples phase current at 10 kHz, every 100 µs. A model 5 to 10 times faster needs a step of 10 to 20 µs, including reading PWM and writing the current signals. That is beyond most CPU-based targets, so the electrical part of the motor model runs on an FPGA, while slower mechanical and vehicle dynamics stay on the CPU.
Getting this wrong shows up as instability or oscillation in the loop that would not happen on the real machine, which wastes debugging time chasing problems in the rig instead of the controller.
What HIL testing is used for
| Industry | Controllers tested | Typical HIL scenarios |
|---|---|---|
| Automotive and EV | Engine and transmission ECUs, battery management systems, ADAS, body controllers | Drive cycles, cell faults and thermal runaway conditions, sensor failures, network errors |
| Aerospace and defense | Flight control computers, engine controllers (FADEC), actuator controllers | Flight envelopes, failure modes, redundancy switchover |
| Power electronics and energy | Inverters, converters, grid-tied and microgrid controllers | Grid faults, voltage sags, islanding, harmonic conditions |
| Industrial machinery | Motion controllers, drives, PLC-based machine control | Axis limits, jams, emergency stops, encoder faults |
| Medical devices | Infusion pumps, ventilators, surgical device controllers | Occlusions, sensor drift, alarm handling |
In automotive work, HIL is widely used to produce verification evidence for functional safety under ISO 26262, because it lets engineers inject faults and prove the safety mechanisms respond correctly, repeatably and on every software release.
When HIL pays off, and when it does not
HIL is worth the investment when one or more of these is true:
- The real system is expensive, scarce or not built yet, such as a prototype vehicle or aircraft.
- Key tests are dangerous or destructive on real hardware: battery faults, overspeed, loss of control.
- Scenarios must be exactly repeatable, for example to compare two software builds.
- Software changes often, so you need automated regression on every build, overnight, without a test driver or pilot.
- Rare edge cases must be covered that would take months to encounter in field testing.
HIL is less useful when the plant cannot be modeled accurately enough, when the controller is simple and cheap to test on the real machine, or when the question is mechanical durability rather than control behavior. It also does not replace production testing: a HIL rig validates a design, while an end-of-line tester proves each manufactured unit. Some production ECU testers borrow HIL ideas, using a simplified plant simulation to exercise the controller at end of line.
Building a HIL rig: off-the-shelf or custom?
Commercial HIL platforms, such as NI’s real-time and FPGA-based systems programmed with LabVIEW, provide real-time targets, I/O and modeling tool chains. They are the fastest route when a project fits their standard I/O. Custom HIL rigs make sense when the controller has unusual signals, needs high-current or high-voltage loads, must integrate legacy equipment, or when the rig doubles as a production or depot tester. Either way, most of the effort lies in the plant model, the fault insertion and the test automation software, not the computer.
Planning a HIL or controller test rig?
Sciotex builds custom automated test systems with real-time I/O, fault insertion and test software, from validation rigs to production testers, built and supported in the US since 1997.
Frequently asked questions
Hardware-in-the-loop (HIL) testing connects a real embedded controller to a real-time simulation of the system it controls, so the controller can be tested against realistic and repeatable scenarios without the actual machine or vehicle.
Software-in-the-loop (SIL) runs the controller code on a PC against a simulated plant, with no real hardware. Hardware-in-the-loop (HIL) uses the actual controller hardware, with its processor, I/O and power, connected to a plant model running on a real-time computer.
It lets engineers test dangerous, rare or expensive scenarios safely, repeat them exactly, inject faults without damaging hardware and run automated regression tests on every software release before a prototype exists.
The plant model is the mathematical simulation of the system the controller operates, such as a motor, battery or vehicle. It runs in real time and returns simulated sensor signals in response to the controller’s commands.
A HIL rig is a specialized kind of automated test system used mainly for design validation. Production ATE, such as end-of-line testers, checks each manufactured unit; HIL proves the controller design and software behave correctly.
Related articles
- What Is Automated Test Equipment (ATE)? The Complete Guide
- Automated Test Software: Test Executives, TestStand, LabVIEW and Python
- End-of-Line Testing: How EOL Test Systems Work and How to Specify One
- Automated Test Equipment Use Cases: Semiconductor, Automotive, Aerospace and More
- In-Circuit Test vs Functional Test: ICT, Flying Probe, Boundary Scan and FCT Compared
- 7 Measurements to Automate with an ATE System (and How to Get Them Right)
