What does HIL stand for?

Hardware-in-the-loop: the real hardware (the controller under test) sits inside a loop closed by a real-time simulation of the system it controls.

What is HIL and SIL testing?

Two levels of testing a controller against a simulated plant. SIL testing runs the compiled software on a PC, with no target hardware. HIL testing runs the production firmware on the real controller, connected to the plant model through real I/O. SIL is faster and comes first; HIL is closer to the product.

What is HIL testing in automotive?

Testing a real ECU against a real-time vehicle model, with simulated bus traffic and injected faults, before it goes into a car. It is a standard step in automotive development and in functional-safety (ISO 26262) work.

What is hardware-software integration testing?

Testing that the firmware and the board work together: the right pins, buses, addresses, timing and power behaviour. HIL is one way to do it on real hardware; board-level simulation does it before the hardware exists.

When should you use HIL testing?

When the device controls something costly or dangerous to test for real, when you need repeatable fault injection on the physical board, or when a standard requires hardware test evidence.

Can HIL testing be done without hardware?

Not strictly, since the hardware is what makes it HIL. The closest step before hardware is firmware-in-the-loop on a simulated board, which runs the same binary against a model of the schematic.

What is HIL testing? Hardware-in-the-loop, explained

Adam Szefer · Co-founder & CTOOctober 22, 2026

Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.

HIL testing (hardware-in-the-loop testing) runs a real controller against a simulated world. This is how it works, what a HIL test system is made of, how it compares with SIL testing, why automotive teams rely on it, and what to do in the months before there is hardware to put in the loop.

HIL testing in one paragraph

In HIL testing, the device under test (a real ECU, controller board or MCU) is wired to a test system that pretends to be everything around it. The test system simulates the plant (a motor, a vehicle, a battery, a sensor) in real time, drives the device's inputs with the signals that plant would produce and reads its outputs back. The device can't tell it isn't in the field, so you can test normal operation, edge cases and faults that would be dangerous or expensive to create for real.

How a HIL test system works

A HIL test system has three parts. The device under test runs its production firmware. A real-time computer runs the plant model at a fixed step, fast enough to keep up with the controller. Between them, I/O hardware turns model values into voltages, currents, PWM, CAN or sensor signals and back, often with fault-insertion units that can short, open or swap lines. Test scripts drive scenarios and check the device's response against its requirements.

HIL vs SIL testing

Model-in-the-loop (MIL) tests the control algorithm as a model. Software-in-the-loop (SIL) testing compiles the code and runs it on a PC against the plant model: fast and cheap to scale, but blind to the target hardware. Processor- or firmware-in-the-loop runs the real binary on the real MCU or a simulated one, so the compiler, timing and peripheral behaviour are included. HIL testing adds the real board and real I/O. Teams usually run SIL on every change and HIL on release candidates, because each step closer to the product is slower to set up and to repeat.

HIL testing in automotive

Automotive is where HIL testing became standard. An ECU for the powertrain, brakes, steering or a battery management system is tested against a real-time model of the vehicle, with CAN, LIN or automotive Ethernet traffic from the ECUs around it, and with faults injected that nobody would create on a test track. Functional-safety work under ISO 26262 needs repeatable evidence that the controller handles those faults, which is why automotive HIL test systems run large suites of scripted scenarios unattended.

What HIL costs and when it pays off

A HIL system means real-time hardware, I/O and signal conditioning, a plant model, fixtures for the board and someone to maintain it all, and one rig serves one bench at a time. It pays off when the plant is expensive or dangerous to test against (automotive, aerospace, power electronics, medical) and when certification needs the evidence. For a sensor node or a small controller, a full rig is often more than the risk warrants.

Testing before the board exists

HIL needs a board, so it starts after the first prototypes, and many integration bugs (a pin assigned twice, an address collision, a rail that comes up late) are found there, when a fix means a respin. A board-level simulation runs the same firmware against a model of the schematic, so those bugs show up while the design can still change. It doesn't replace HIL for analog accuracy, RF or certification; it takes the wiring and timing bugs out of the HIL schedule.

FAQ

What does HIL stand for?: Hardware-in-the-loop: the real hardware (the controller under test) sits inside a loop closed by a real-time simulation of the system it controls.
What is HIL and SIL testing?: Two levels of testing a controller against a simulated plant. SIL testing runs the compiled software on a PC, with no target hardware. HIL testing runs the production firmware on the real controller, connected to the plant model through real I/O. SIL is faster and comes first; HIL is closer to the product.
What is HIL testing in automotive?: Testing a real ECU against a real-time vehicle model, with simulated bus traffic and injected faults, before it goes into a car. It is a standard step in automotive development and in functional-safety (ISO 26262) work.
What is hardware-software integration testing?: Testing that the firmware and the board work together: the right pins, buses, addresses, timing and power behaviour. HIL is one way to do it on real hardware; board-level simulation does it before the hardware exists.
When should you use HIL testing?: When the device controls something costly or dangerous to test for real, when you need repeatable fault injection on the physical board, or when a standard requires hardware test evidence.
Can HIL testing be done without hardware?: Not strictly, since the hardware is what makes it HIL. The closest step before hardware is firmware-in-the-loop on a simulated board, which runs the same binary against a model of the schematic.

HardLabs

Send us your design. We'll send you a simulator.

We build a board simulator from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break.

A working simulator of your board, built from netlist, schematic, and BOM.
Peripheral models attached so your firmware can talk to the board.
A setup that runs your real firmware binary — no rewrite required.

Pilot details · App

HIL alternative before hardware
Need HIL-class coverage before PCBs exist? HardLabs runs unmodified firmware against a netlist-derived board model — a software HIL path for schematic freeze.
Firmware-in-the-loop
Firmware-in-the-loop against your netlist — not stubs. Run unmodified .elf images on MCU simulation with board-aware I²C/SPI models and CI assertions.
Firmware testing guide
Embedded firmware testing explained: unit tests to hardware-in-the-loop, the best tools, and how to test firmware before the board exists.
HW/SW co-simulation
Hardware–software co-simulation that sees the boundary: real MCU firmware plus board-aware peripheral models from your netlist.
HardLabs vs HIL rigs

HardLabsAll topics