LoopCheck replaces building your own test infrastructure with a complete testing platform that we tailor to your application – based on a proven, adaptive hardware platform instead of a from-scratch development. What we tailor is only the interface to your device under test – the platform itself is finished, not newly developed. For regulated and safety-critical devices, your engineers start testing from day one.
Basics
What is Hardware-in-the-Loop?
Hardware-in-the-Loop (HIL) is a test method in which your real embedded controller runs against a simulated environment. The HIL test system feeds in sensor and fieldbus signals, reads the firmware’s responses back and checks them automatically against expected limits – reproducibly and without the real plant. That lets you exercise control algorithms, fault cases and edge conditions safely at your desk instead of on an expensive test rig.
LoopCheck covers the full range – from module tests of individual components to black-box system tests of the finished firmware. As a compact HIL for the developer workstation (desk HIL), it is small enough for any desk, integrated into CI/CD and driven with tests in C, C++ or Python – and a core part of our holistic test environments.
Where it fits
Not all HIL is the same
Desk HIL vs. rack HIL
Desk HIL sits on the developer’s desk and tests individual controllers early and often. Rack HIL are large cabinet systems for the full vehicle or plant – expensive, shared and rarely free. LoopCheck is desk HIL: there when you need it.
Signal HIL vs. power HIL
Signal HIL works at signal level – sensor values, bus signals, small currents and voltages – ideal for firmware and control testing. Power HIL switches real load currents and power. LoopCheck is a signal HIL: precise, safe and exactly right for embedded software.
Embedded testing shouldn’t be a project of its own
Most HIL systems are expensive and complex. Teams that build their own test infrastructure spend more time maintaining it than building their actual product: custom hardware development, hardware/software integration, sensor and peripheral simulation, logging, signal generation and the upkeep of a real-time HIL.
Before the first useful test even runs, an in-house build easily takes four to six engineer-months – research, hardware, software, testing. With LoopCheck we take on the test environment; once the hardware is with you, you write your first test case that same day instead of after months.
Your engineers should build products, not test infrastructure.
The internal cost of an in-house build is easiest to reckon in engineer-months – four to six of them against your own loaded rate. The tailoring to your test object takes four to eight weeks, and we agree the price for it per project.
The solution
What we handle for you
Hardware adoption
We adapt the test hardware to your device under test – no board bring-up on your side.
HW/SW integration
Firmware and adapter board are matched to your interfaces out of the box.
Communication interfaces
CAN, Ethernet, UART, RS485 and more – wired to your connectors.
Real-time execution
Deterministic, microsecond-level timing on a dedicated core.
Signal generation
Analog and digital stimuli, including sensor and peripheral simulation.
Automation & logging
A test API and CI/CD-ready workflow instead of manual bench work.
The payoff
What changes because of it
Test time that no longer accrues
A regression run that costs an engineer a day by hand runs through overnight. Not once, but on every commit. The saving isn’t in the setup, it’s every time afterwards.
Faults before they get expensive
The later a firmware fault shows up, the more it costs. In the field that means a recall, a service call or an update someone has to install at the customer’s site. HIL finds the cases you can barely produce on the real setup: sensor failure, bus load, limit values, fault reaction.
Release on evidence, not on gut feeling
Whoever releases a firmware owns the decision. With an automated test run, the release rests on a reproducible result with date, version and criterion. That changes the basis on which someone signs.
Verification is not optional
In regulated devices the verification evidence is a precondition for approval, not a quality measure on top. Without automated, repeatable tests it gets produced by hand, or not at all.
Tests in C, C++ or Python
Your engineers shouldn’t have to learn another proprietary ecosystem. With LoopCheck they simply write tests in the languages your team already uses – no proprietary scripting language, no forced IDE, no long training period.
Time-critical test logic and simulation models run in C on a dedicated processor core on the board, in real time – reached through a clean API instead of registers and pin numbers. From the host you drive that logic with an ordinary Python library: start sequences, set variables, read back timestamped results.
And because the tests are plain C, C++ and Python, an AI assistant can read, write and change them. With a proprietary scripting language it cannot – the choice of language decides whether AI can help with testing at all.
The platform
Adaptive hardware – configured by us per application
Your device under test speaks CAN, has an analog frontend and its own connector? That is exactly what we configure the platform for – you don’t get a kit to populate yourself, but a finished setup:
Adaptable docking shields
Screw terminals, coaxial analog frontends, power stages or a fully custom connector layout – on a proven base board.
Fieldbus & networking
CAN / CAN FD, Ethernet and serial interfaces (UART, RS485 / RS422) to wire up your device under test for real.
Analog & digital I/O
Precise analog inputs and outputs as well as digital signals – instead of simulation only.
Dedicated real-time core
A core of your own for your C code delivers deterministic, hard real-time behaviour.
Safety
Qualifiable for safety-critical systems
When your device has to be approved, it isn’t the test alone that counts but the evidence. LoopCheck is built to answer exactly the questions that come up in an audit:
“Show me the evidence for requirement 7.”
Requirement, test case and result are linked end to end – you present the chain in full instead of piecing it together during the audit.
“The firmware changed – does this still hold?”
The same test run executes again automatically and re-proves the new state – reproducibly, with no one checking by hand.
“How did this result come about?”
Every run leaves dependable evidence – not just a green checkmark, but the documented path to it.
“Does the tool count towards approval?”
We assist with qualifying LoopCheck and the test environment and with fitting it into your V-model process.
Automated, reproducible HIL tests map directly onto the verification side of the safety lifecycle. The evidence fits into processes under ISO 26262, EN 50128 / EN 50657, IEC 61508, IEC 62304 and DO-178C – the relevant standard and safety integrity level are agreed per project.
In detail: IEC 62304 (medical) and IEC 61508 (functional safety).
Why now
The test effort grows, the deadlines are running
The Cyber Resilience Act ties you to your device after it's sold
Since 11 September 2026 the reporting duty for actively exploited vulnerabilities applies: 24 hours to an early warning. From 11 December 2027, security by design, an SBOM and security updates across the entire support period are added. Every one of those updates is a firmware change on a device in the field – and every one of them has to be verified.
A kernel patch changes nothing in your application and yet everything
When a third-party component is updated, your own software is unchanged. The evidence for the device is not. Anyone who keeps that evidence by hand simply can’t afford security updates – and that is exactly what the deadlines are here for.
More code, in less time
AI-assisted development produces more features per sprint. They still have to be tested, and the test effort grows with them. The bottleneck shifts from writing to proving.
The requirements keep rising
Standards and market-access rules get stricter, not looser. Test infrastructure that barely suffices today won’t suffice in two years.
Manual steps
LoopCheck covers the signal side
When your test procedure also contains manual steps – a visual check, a manual action, a value read off a display – XPressRT runs both in the same record: LoopCheck’s HIL channels and the operator’s manual steps.
Start testing instead of building test infrastructure
All the technical detail – hardware configurations, the Python API, architecture and a complete worked example – is on the LoopCheck platform.
- Tests in C, C++ or Python – no proprietary ecosystem
- Integrated into CI/CD: automated regression and nightly tests
- Real, adaptive test hardware instead of simulation only
- Qualifiable for regulated, safety-critical devices
References
Proven in real projects
Multi-channel motor control
Regression test of the control loop on every commit – at real signal level, with simulated parasitic current effects against the real firmware, without a real motor or power stage.
Result: The regression run now executes automatically on every commit instead of rarely by hand – control robustness and security gaps under parasitic current effects surface in the nightly run, before a real motor or power stage is ever involved.
Medical laser controller
Laser control and safety-critical functions tested in a nightly black-box run on every commit – with deliberate fault injection, entirely without a real laser system.
Result: The safety-critical fault reactions are reproducibly evidenced at every firmware version – the verification evidence is produced in the nightly run instead of in manual rework.
SIL 3 safety sensor
Automated tests of the safety functions with a continuous feed of real field data – fast feedback and code-coverage evidence over the trace port.
Result: The code-coverage evidence for the safety functions is produced continuously from real field data – the basis a SIL 3 approval requires.
Frequently asked questions about HIL testing
What is Hardware-in-the-Loop (HIL)?
A test method in which the real embedded controller runs against a simulated environment: the HIL test system generates the sensor and bus signals, reads the firmware responses back and checks them automatically – reproducibly and without the real plant.
What is the difference between desk HIL and rack HIL?
Desk HIL sits on the developer workstation and tests individual controllers early and often. Rack HIL are large, expensive cabinet systems for the full assembly that are usually shared. LoopCheck is a desk HIL.
Signal HIL or power HIL – which is LoopCheck?
LoopCheck is a signal HIL: it simulates at signal level (sensor values, bus signals, small currents and voltages) and is ideal for firmware and control testing. Power HIL with real load currents is a different field.
Does LoopCheck support module tests and black-box tests?
Yes. LoopCheck covers module tests of individual components through to black-box system tests of the finished firmware – including deliberate fault injection. That is particularly relevant for medical technology under IEC 62304.
Is LoopCheck suitable for safety-critical and medical applications?
Yes. Reproducible, automated HIL tests provide verification evidence for standards such as IEC 62304 (medical), IEC 61508, ISO 26262, EN 50128/50657 and DO-178C. The relevant standard is agreed per project.
Which languages do I write tests in?
In C, C++ or Python – no proprietary ecosystem and no forced scripting language. Time-critical logic runs in C in real time on the board, driven from the host through a Python library.