Hardware-in-the-Loop Testing: The Front Line of Defence for Edge, IoT & MedTech Devices

If Your Demo Doesn’t Survive HIL, It Won’t Survive the Market

Embedded solutions today require a mix of complex hardware and feature-rich software. In textbooks, hardware development typically occurs first, followed by software development. In real projects, this rarely works. Hardware arrives late, or in a single fragile prototype, or it comes in a revision that does not match the expected behavior or requirements. Yet, software teams still have deadlines. The time-to-market factor only gets more aggressive each year, especially for companies preparing for EWNA, MWC, CES or another major launch. Whoever ships first gains attention, and this is all that matters.

Even when hardware does exist, teams might not be able to use it. Edge AI processors, radar front-ends, medical sensors, and industrial IoT modules are often too expensive, delicate, not certified for shipping, or locked in a lab. Sometimes only one board exists, and everyone waits in line for it.

So, teams fall back to Software-in-the-Loop (SIL). It is fine for early logic, but modern embedded systems rely on peripherals that SIL simply cannot imitate. Contemporary devices include high-speed sensors like LiDAR and UWB radar, neuromorphic processors, tiny AI accelerators, motor controllers, and some very custom mixed-signal circuits. You cannot get the realistic behavior of these components in a software-only model. SIL gives you a start, but eventually your team hits a wall and needs real hardware behavior.

This is where Hardware-in-the-Loop (HIL) becomes the practical option. It lets engineers run firmware as if the product was already built, even when it’s not.

HIL in a Nutshell

HIL is basically a testbed that pretends to be a thing out of the real world. The firmware runs on actual silicon (or something close to it), while another board or module simulates sensors, actuators, signals, and timing. The device under test (DUT) talks to it as if it were talking to production hardware.

A simple HIL setup can be as tiny as two MCU dev boards wired together. Messy cables, few scripts, and suddenly you can run dozens of automated tests. It is enough to catch a surprising number of issues and can be wired into CI without too much trouble.

On the other end of the spectrum, complex devices need industrial-grade solutions. Automotive ECUs, medical equipment, robotic platforms, and high-speed sensing systems often rely on advanced HIL platforms. National Instruments PXI, Vector VT, Typhoon HIL, Speedgoat – each fits a different niche. These systems cost more, but they can handle scenarios where timing accuracy, analog fidelity or electrical behavior makes or breaks the product.

What all of them have in common is that “ready-to-use” rarely means ready on day one. Every HIL system ends up customized because every device behaves differently.

Real Project Example

One of our clients in the construction tools domain needed firmware for a new MCU-based device, but hardware simply did not exist yet. They had a hint of requirements and a sketch. That was it. But the release date was fixed, so waiting was not an option.

Our team built a custom HIL setup. It included a baseboard for wiring, an MCU board acting as the simulation engine and an FPGA for the tricky parts. The device had buttons, low-speed sensors and a DC motor. Simulating the motor turned out to be the hardest piece. The firmware didn’t just need to spin it. It needed realistic feedback: current draw, back EMF, changes in RPM and all the weirdness of real motor behavior. That took time. Weeks, in fact.

Once the basics were simulated, software development moved forward normally. By the time hardware prototypes finally arrived, only small calibration changes were needed. The software was basically ready. The customer launched on schedule instead of slipping by months.

If You are Doing HIL, Do not Skip These

1. Look closely at the signals before deciding how “serious” the setup needs to be.
   Some products really can live with two dev boards wired together. If you are only dealing with GPIOs, buttons or slow I²C sensors, that is usually enough. But once SPI climbs into double-digit MHz, or you have motor drivers, synchronized sensors or anything timing-sensitive, the simple setup stops being helpful. That is usually the point where interference, jitter and missed edges become a bigger problem than the firmware itself.
2. Simulate the parts the firmware reacts to and leave the rest alone.
   A model is worth building only if getting it wrong breaks behavior on the real device. For example, you do not need a physics-grade brushless DC motor model unless your control loop depends on the back-EMF shape. You do not need a perfect LiDAR model if the firmware only checks whether a frame arrived. Simulate the signals that change logic. Skip the noise.
3. Keep a pin map once the wiring grows past a handful of lines.
   As soon as SPI, UART, PWM, ADC or multiplexed signals appear, nobody remembers the exact wiring. When the simulation “suddenly” behaves differently after a merge or after someone moves the setup, the pin map is usually the first place you find the answer. Most HIL failures come from cabling, not code.
4. Treat wiring as part of the test environment, not as background.
   High-speed buses and mixed-signal interfaces react to cable length, shielding and routing. Random glitches, unstable results or “it worked yesterday” behavior often come from electrical reality, not faulty logic. If you want stable tests, keep high-speed lines short and shielded, and document the wiring rationale even when it looks obvious. It saves a surprising amount of time.
5. Add an FPGA when timing accuracy becomes the whole problem.
   If the firmware expects something to happen every few microseconds, an MCU acting as the simulator will not stay precise. Examples that almost always need an FPGA: BLDC feedback, encoder signals, synchronized sensor streams, and high-speed SPI with edge-sensitive behavior. If timing drifts even a little, the DUT behaves differently, and your tests stop being meaningful.

Summary

HIL is not easy. It takes real engineering work and usually some iterations. But the payoff appears every time a team avoids waiting for hardware or discovers a critical issue months earlier than they would have otherwise.

Here’s the part most articles skip. Many failures only show up under real electrical and timing conditions. They do not appear in unit tests, and SIL will not expose them. HIL catches these problems at the point where they are affordable to fix.

For edge AI systems, ADAS components, IoT devices and medical equipment, HIL is not optional anymore. It is the method that turns a controlled demo into a real, deployable product. And if a device cannot survive HIL testing before your next big launch, it probably will not survive customer usage after it.