HIL is a scarcity workaround

Hardware-in-the-loop testing is not a methodology somebody chose on merit. It's what you build when there is one bench and forty engineers.

I want to be careful here, because this is the kind of claim that reads as an attack on an industry that isn't wrong about very much. HIL vendors know exactly what their product is for. Their own documentation is more honest about the limits than most of the people quoting it. The argument in this post is not that HIL is fake. It's that the allocation is historical. A large share of the tests sitting in a bench queue right now are there because, when somebody wrote them, a physical rig was the only thing that could run them. That's a supply constraint wearing the costume of a standard.

Sort a HIL vendor's own list and the pattern shows up immediately

OPAL-RT published a post called "7 advantages of HIL testing."¹ They make real-time simulators, they've been at this for decades, and the list is a fair summary of why teams buy benches. Read it as a list of reasons, though, and it splits into two very different piles.

Advantage 1: catch defects "before hardware builds." Advantage 2: shorten validation "before prototype availability," because "you don't have to wait for the motor, grid interface, hydraulic rig, or vehicle mule to be available." Advantage 5: nightly builds can hit a bench instead of waiting for manual setup. Advantage 7: "fewer physical prototypes reduce validation cost," and a supplier with several controller variants "can run common validation suites on one simulator instead of preparing separate physical rigs for each new configuration."

Four of the seven are scarcity. Not scarcity as a metaphor. Scarcity as in the physical thing does not exist yet, or costs too much to duplicate, or there's one of it and a queue behind it.

Advantage 4 is stranger. It says repeatability is a HIL advantage because "physical setups drift as temperatures shift, components age, and operators make small adjustments." That's not an argument for hardware. That's an argument that physical setups are worse, and simulation is better, which is a point I'd have been called a shill for making.

That leaves two that are actually about physics: safe fault injection with real electrical I/O, and high-fidelity plant models where "safety limits and certification evidence depend on responses measured in milliseconds."

None of that is a gotcha. It's a vendor describing their product accurately. The interesting part is what happens once you notice that the scarcity pile and the physics pile have completely different futures. The physics pile is permanent. The scarcity pile is a function of what your tooling could do the year the test was written.

HIL already conceded the argument it's used to win

Here's the part that I think gets skipped.

HIL is itself a simulation compromise. OPAL-RT's definition: it "puts the actual controller into a closed loop with a real-time plant model."² The plant is fake. The motor is fake. The battery pack, the grid, the airframe, all fake. Nobody in this industry argues that you need a real dyno to validate a torque loop, and nobody calls that a loss of rigor.

So the boundary between real and modeled has already moved once, and it moved a long way. The line currently sits at the connector on the controller, and it sits there because that's where modeling capability ran out when benches were designed. Everything on the plant side was tractable to model. The controller was not, so it stayed physical.

That's the whole thing. The line is drawn at the edge of what could be simulated, and it gets redrawn every time that edge moves. People who cite HIL as proof that "you need real hardware" are citing the previous round of exactly the argument they're making against.

And the edge has moved on the controller side. Register-accurate peripheral models, real interrupt priority and preemption, DMA that actually contends for the bus, timers that count in the right units. A decade ago "simulate the MCU" meant a CPU core and a UART that printed strings. That was genuinely not good enough to take work off a bench. It's a different question now, and "we tried simulation in 2014" is not an answer to it.

What actually survives

The remainder is real and it isn't going to zero. OPAL-RT's own framing is the best definition of it I've read: "HIL fits systems where timing errors can damage hardware, break safety logic, or hide integration faults that software-only tests will miss."²

Read that as a scope statement rather than a sales pitch and it's a precise description of the last mile:

Real analog behavior. Sensor saturation during a transient, bus ripple, a resolver offset, a channel mis-scaled by a volt. OPAL-RT puts interface fidelity ahead of model detail for exactly this reason, because the controller "only reacts to sampled inputs, output loading, and transport delays." Their line is "poor I/O design will ruin a brilliant plant model." Analog is not a software problem and pretending otherwise is how you ship a protection routine that only works on the bench.

Real RF and EMI. Nobody is modeling the coupling between a switching inverter and a CAN transceiver well enough to bet a recall on it.

Real electrical and mechanical faults. A stuck-high input on an actual pin, a harness that half-seats, a connector that fails after thermal cycling.

True timing under real silicon. Not the timing your model says the part has. The timing the part has, including the errata sheet, including the flash wait states nobody documented, including the one peripheral that behaves differently on the -A revision.

That set is legitimate, it's where the expensive bugs live, and it justifies every bench that exists. It's also, if you're honest with yourself, not where most of your bench hours go.

The honest counterweight: demand is growing anyway

I don't want this to land as "share is shrinking, therefore HIL is in decline," because the numbers point the other way.

Electric car sales passed 17 million in 2024.³ OPAL-RT cites that as evidence that "more software-heavy control systems now need closed-loop validation," and they're right.² Grid control is doing the same thing from a different direction: wind and solar supplied a record 13.4% of global electricity in 2023, which means power system benches now have to represent far more inverter-based behavior than they used to.⁴

More software-defined systems means more controllers, more safety logic, more certification evidence. A shrinking percentage of a much larger number is a bigger number. Bench demand can grow at the same time as bench dependence falls, and I expect both.

The chart has no numbers on it on purpose. I'm not going to invent a percentage for how much bench work is displaceable, because I don't have that data and neither does anyone who quotes one at you. The shape is a logical claim, not a measurement.

Where I stop making claims

Our own stack does not model any of the last mile. No analog. No RF. No EMI, no connector wear, no thermal drift. Chiplab runs firmware against modeled peripherals, and if you point it at something outside that boundary it will not warn you, it will just be wrong quietly. There's a whole post on what simulation can't catch, including our stack returning zeros for a cycle counter that doesn't exist on the virtual board.

So no, this isn't "buy simulation instead of a bench." If your failure mode is a saturating current sensor, a bench is the correct instrument and everything else is theater.

The question to actually ask

OPAL-RT says it plainly, in the middle of a guide selling HIL: "you don't need HIL for every function. Static calibration screens, reporting logic, and slow supervisory states are usually settled earlier with software tests and review." And: "HIL becomes important when the controller's timing is part of the requirement itself."²

That's a routing rule, and it's a good one. It's also not the rule most teams are following, because most teams never routed anything. Tests accumulated on the bench the way files accumulate in a home directory.

So go look at the queue. For each thing in it, ask which reason it's there for. Does it need real silicon, real analog, real timing under real errata? Keep it, and stop apologizing for the capex. Or is it there because in 2019 the bench was the only thing that could run a firmware image at all? That one is a candidate to move, and the fact that it's been on the bench for six years is not evidence either way.

The practical version of this argument, with an actual procedure for splitting the queue, is in simulation vs HIL: what belongs in CI and what belongs in the lab. If the acronyms are the blocker, MIL, SIL, PIL, HIL for firmware people sorts out the vocabulary first.

One more line from OPAL-RT, which I'd frame and hang on a wall: "most failed HIL efforts collapse under weak assumptions about plant scope, interface timing, or pass criteria rather than raw simulator limits."² The failure mode is never the simulator being too coarse. It's a team not knowing why a test is where it is. That cuts in both directions, and it's the actual point of this post.

HIL is a workaround, and it's a good one. Workarounds get smaller when the constraint they route around gets smaller. That's not an insult. That's just what a workaround is.

Sources

Footnotes

1. "7 advantages of HIL testing," OPAL-RT Technologies, June 16, 2026. https://www.opal-rt.com/blog/7-advantages-of-hil-testing ↩

2. "A Guide to hardware-in-the-loop (HIL) testing in 2026," OPAL-RT Technologies, May 13, 2025. https://www.opal-rt.com/blog/a-guide-to-hardware-in-the-loop-testing ↩ ↩² ↩³ ↩⁴ ↩⁵

3. International Energy Agency, "Global EV Outlook 2025," IEA, 2025. https://www.iea.org/reports/global-ev-outlook-2025 ↩

4. Ember, "Global Electricity Review 2024," Ember, May 2024. https://ember-energy.org/latest-insights/global-electricity-review-2024/ ↩