Every embedded team that runs a HIL bench has the same conversation at some point. A regression slips into the firmware. The team lead asks why it wasn’t caught on the bench. The answer is some version of “the bench was down,” or “only Marcus knows how to run that test,” or “the test suite hasn’t been updated since the last hardware revision.”
Marcus is on holiday. The test suite is six months stale. The bench is in the corner.
The bench has failed.
Here is the unpopular position this article defends: a HIL rig that requires a specialist to operate is not a HIL rig — it is a piece of lab equipment that occasionally catches bugs. The two are different things, and most embedded teams encountered on engagements own the second while believing the first.
The Test That Defines a Working HIL Rig
The test is simple. A junior engineer joins the team on Monday. By Friday, that engineer can:
- Run the full HIL test suite against a release-candidate firmware
- Read the output, distinguishing real failures from infrastructure flakes
- Add a new test case for a bug just fixed
- Restore the bench to a known-good state after a hardware swap
If a junior cannot do all four within a week, the bench has failed its job. It is institutional knowledge dressed up in instruments.
This is uncomfortable to hear after two years of building a bench. Some of the benches behind this article would not have passed the test either. The reason to write it down now: the benches that passed delivered ten times the value of the ones that did not, and the difference between them was never the instruments.
What the Failed Benches Have in Common
After enough engagements, the failure modes are repeatable.
The bench depends on undocumented setup steps. Power on instrument A before instrument B or the SCPI handshake fails silently. Press the reset on the DUT before pressing the trigger on the scope. The senior engineer who built it knows. Nobody else does.
Test cases live in a notebook on one laptop. Some are scripts. Some are LabVIEW VIs. Some are oscilloscope screenshot comparisons that require human judgment. None are in version control. The corpus exists in one engineer’s head and one laptop’s filesystem.
The bench shape does not survive hardware revisions. A new board variant arrives. The fixturing was designed for revision A. Revision B has a connector in a different place, so half the tests cannot run. The refactor stays on the backlog. Permanently.
There is no answer to “is the bench healthy?” When tests pass, nobody checks whether the instruments are calibrated. When tests fail, nobody knows whether the failure is real or whether the bench has drifted. The signal-to-noise ratio degrades over months until the team stops trusting any output.
Adding a test requires writing instrument-control code. Every new test case is an engineering project. The marginal cost of catching a new bug class is high enough that most bugs never get test coverage. The bench enforces its own neglect.
If any two of these are true on a bench, the bench has failed. If three or more are true, the bench is theatre — it produces reports but does not catch what it was built to catch.
A bench that matches any of this can be refactored.
Existing HIL benches are refactored into infrastructure that survives team changes, hardware revisions, and the departure of the engineer who built them. Talk to a HIL Engineer →
What the Working Benches Have in Common
The same engagements reveal what works. Five practices show up consistently in the benches that earn their cost.
Tests are code in version control. Every test is a script. Every script lives in the same git repo as the firmware. A new engineer learns the bench by reading the test directory. Tests are reviewed in PRs. Test changes are signed off by someone other than the author.
Instrument abstraction is one layer thick. A test does not call tek_oscilloscope_set_trigger_voltage(3.3). It calls dut.measure_voltage_at("VBUS"). The abstraction layer between the test and the instrument is documented, replaceable, and the same shape regardless of which instrument the test uses. When the team replaces a Tektronix scope with a Keysight, no tests change.
The bench has a self-test that runs first. Before any DUT test runs, the bench runs against a golden reference — a known-good board permanently wired in. If the self-test fails, no DUT tests run and the bench reports its own failure. This single practice catches the majority of the bench-induced false results, both false passes and false fails, that the failed benches accumulate.
Fixturing is designed for change. Pogo pins, not soldered connections. Board adapters, not custom-cabled harnesses. A new hardware revision means a new adapter, not a new bench. The fixturing budget at design time is higher; the fixturing budget at year three is lower.
The bench produces machine-readable output. Pass/fail per test, with structured failure data: which test, which input, what was expected, what was observed, and when. The output feeds into CI dashboards. Trends are visible. Regressions surface as deltas, not as a senior engineer’s recollection.
The expensive part of building a bench like this is not the instruments. A Joulescope, a basic logic analyser, a programmable supply, a relay matrix, and a Linux host comes in under €5,000 for most product profiles. The expensive part is the discipline to write the abstraction layer, version-control the tests, and design fixturing that survives the next hardware revision.
Why This Matters More in 2026
Three forces are converging that make the “one engineer who knows the bench” model untenable.
AI-assisted firmware development is producing more code per week. Validation has to scale with productivity. A bench that gates on one specialist is the bottleneck that quietly negates the speed gain.
The Cyber Resilience Act requires manufacturers to demonstrate ongoing security validation, which is far easier to evidence when results are machine-readable and version-controlled. A bench whose results live in one engineer’s notebook does not produce defensible compliance evidence.
Hardware revisions are coming faster. Connected product cycles are compressing. A bench that takes six weeks to adapt to a new board revision is a bench that misses one product cycle in three.
Three fixes compound: version-controlled tests, instrument abstraction, and fixturing designed for change. A team that makes all three gets a multiplier on every other engineering investment. A team that does not, accumulates bench debt that compounds instead.
The Hard Conversation
The hardest part of fixing a failed bench is not the technical work. It is the conversation with the engineer who built it.
That engineer is usually senior, usually proud of the build, and usually correct that the bench does catch bugs when operated by its builder. The argument is not that the engineer failed. The argument is that what was built does not survive the builder’s absence, and the team’s job is to build infrastructure that does.
In every engagement refactoring a failed bench, the engineer who built it is the one most worth involving. That engineer knows what the bench was supposed to do, which corners were cut, and which tests matter. The refactor takes one engineer’s knowledge and makes it the team’s knowledge.
For anyone whose bench this describes: this is not an accusation. It is the next stage of the work.
The refactor, scoped.
From “one specialist can run it” to “any engineer can run it” typically takes four to eight weeks for a mid-complexity bench, including version-control migration, the abstraction layer, the self-test, and fixturing redesign. Scope a HIL Bench Refactor →
Frequently Asked Questions
Why should a HIL bench be operable by a junior engineer? Because a bench that requires a specialist becomes a single point of failure for the team’s entire validation pipeline. When the specialist is unavailable, on holiday, or has left, the bench produces no value. The benches that return ten times the value of their instrument cost are the ones any engineer on the team can run.
Does this mean buying a commercial HIL platform? No. Commercial HIL platforms solve different problems. A self-hosted bench with disciplined practices — version-controlled tests, an instrument abstraction layer, a self-test routine, and fixturing designed for change — outperforms most commercial platforms at a fraction of the cost. The platform-selection decision is covered in detail in How to Choose a Continuous Validation Platform.
How much does a working HIL bench cost? The same hardware listed above — a Joulescope, logic analyser, programmable supply, relay matrix, and Linux host — comes in under €5,000 for most product profiles. The expensive part is the engineering discipline to build the abstraction layer, version-control the tests, and design fixturing that survives hardware revisions. That work is typically four to eight weeks of focused effort.
What is the first thing to fix on an existing bench? Get the tests into version control. Every other improvement compounds from there. A bench whose tests live on one laptop in a notebook cannot be improved incrementally; it can only be rebuilt.
Join other engineering leaders receiving our monthly insights, or reach out to discuss how Better Devices can help your team ship faster.
