Unit tests have long run on every commit. The test on the real device often stays manual – and therefore rare. Hardware-in-the-Loop in CI/CD closes the gap: your firmware runs automatically against a simulated environment on real hardware, reproducibly and in minutes. LoopCheck is built for it.
In the pipeline
What HIL takes on in the pipeline
Regression on every commit
A regression run that costs a developer-day by hand runs automatically – on every commit or nightly, not only before a release.
Feedback in minutes
The HIL run is part of the pipeline. A fault in hardware-software integration shows up in minutes, not days.
Reproducible as evidence
Every run is bit-exact repeatable and leaves dependable evidence – not just a green tick.
Fault injection automated
Sensor, bus and timing faults are injected on purpose on every run – without endangering a real device.
Integration
How it fits into your pipeline
Build, flash, test on the device
LoopCheck programs the target with the fresh build, starts the run and reads the responses back – as one step in your pipeline.
Jenkins, GitLab CI, GitHub Actions
Driven from a plain Python library – no proprietary ecosystem and no forced scripting language.
Software and hardware tests layered
Fast software simulation catches algorithmic defects early, the HIL run on the device checks the whole behaviour – graded in one pipeline.
Result as evidence
Every run produces a reproducible report with date, firmware state and criterion – the basis for verification.
Why now
Every change has to be re-verified
Since the Cyber Resilience Act, every security update is a firmware change on a device in the field – and each one has to be verified. Even a kernel patch in a third-party component leaves your own software unchanged, but not the evidence for the device. Running that evidence by hand makes frequent updates unaffordable. HIL in the pipeline makes re-verification after every change affordable.
Regulated devices
The evidence stays valid, commit after commit
In regulated devices the verification evidence is a precondition for approval, not a quality measure on top. Because every HIL run is reproducible and evidenced per firmware state, the evidence stays valid after every change – matching processes to IEC 62304 and IEC 61508.
Frequently asked questions about HIL in CI/CD
Can Hardware-in-the-Loop be integrated into a CI/CD pipeline?
Yes. LoopCheck programs the target with the current build, runs the HIL test on the device and returns the result to the pipeline – driven from a Python library, in Jenkins, GitLab CI or GitHub Actions.
How often does the HIL test run?
As often as you want: on every commit, in a nightly, or only for release candidates. Because the run is automated and reproducible, an extra run costs no manual work.
Which CI systems are supported?
Any that allow a script or API call – Jenkins, GitLab CI, GitHub Actions and others. It is driven from a plain Python library, without a proprietary ecosystem.
How long does a HIL run take in the pipeline?
Usually minutes. A graded pipeline works best: fast unit and software tests first, the HIL run on the device for integration and release candidates.
What does HIL in CI add over unit tests and pure simulation?
HIL finds the faults in the interplay of firmware and real hardware – sensor loss, bus load, timing, fault reaction – that are hard to reproduce in unit tests or software simulation alone.
Bring HIL into your pipeline
LoopCheck is the compact HIL platform we tailor to your test object and connect to your CI/CD pipeline – reproducible regression and nightly tests on the real device. If you would rather have the whole test environment taken on, we do that as a project.