Industrial automation · HIL test benches
HIL test benches: hardware-in-the-loop testing for your controller
A HIL test bench connects your real controller to a simulated environment: sensors, motors, comms and faults, so firmware is tested automatically on every change, before field trials. We build them for R&D teams in Israel and abroad.
Remote collaboration with R&D teams abroad, in English, alongside our work in Israel
- For
- R&D and test leads at hardware, robotics and controls companies, and startups, in Israel or abroad
- What you get
- A HIL bench with simulation, fault injection and tests that run automatically in CI
- First step
- A call with an engineer about your controller, its interfaces and the bugs reaching the field today
What HIL is
What is HIL, and when does it pay off?
HIL pays off when field testing is expensive, risky or slow, when the code changes often, and when a bug that reaches a customer costs more than the bench. Here's how it compares with other ways of testing.
- Software in the loop (SIL)
- The code runs against a model, with no hardware. Fast and cheap to run on every change, but it misses timing, driver and real-hardware problems.
- Manual bench testing
- An engineer wires up a power supply, a signal generator and a scope and tests by hand. Good for early development, but hard to repeat the same way and impossible to run on every change.
- HIL: the real controller against a simulation
- The real controller and firmware against simulated sensors, actuators and comms. Repeatable, automated tests, including faults that are dangerous or impossible to create in the field.
- Field testing
- The full system in its real environment. Nothing replaces it for final sign-off, but it is expensive and slow, and a bug found there costs the most. HIL reduces what reaches the field.
What it's made of
What is a HIL test bench built from?
Six building blocks. We start with the minimum that runs one test and add what the tests need.
I/O and communications
Analogue and digital I/O cards, and comms such as CAN bus, FDCAN, EtherCAT, RS-485 or Modbus, simulating what the controller sees on the machine.
Output: Interface list and bench wiring
Fault injection
A disconnected sensor, a short, low voltage, a delayed or corrupted message. You test how the controller handles faults without risking the machine.
Output: Fault catalogue and injection hardware on the bench
Plant model
A simulation of what the controller drives: a motor, an axis, sensors, a load or a process, at the level of detail the tests need, and no more.
Output: A simulation model that runs in real time
Test runner
Software that runs scenarios, measures and compares against the expected result, usually in Python with a standard test framework.
Output: An automated test suite and the test code
CI integration
Every code change flashes the firmware to the controller on the bench and runs the test suite, and the result goes back to developers before merge.
Output: A CI pipeline that drives the bench
Reports and logs
A result for every test and every version, with logs and recorded signals, so you can see what failed without reproducing it by hand.
Output: A report per run and history by version
Continuous testing
HIL in CI: tests that run on every change
The real value of HIL comes when it runs on its own, on every code change, not just before a release.
When the HIL bench is connected to CI, every firmware change goes through the same test suite: the code is built, flashed to the controller on the bench, the tests run against the simulation, and the result goes back to the developer. A regression that would have surfaced in a field trial, or at a customer, shows up on the day the code was written.
Making that work in practice takes more than a bench:
- A stable bench that resets itself to a known state before every run
- Tests that give the same result on every run, so the team trusts them
- A run queue, when several developers share the same bench
- Reports and logs that let you understand a failure without sitting next to the bench
Our HIL work is led by an engineer who has built automated HIL test pipelines in CI.
When the firmware itself is still in development: Firmware and embedded software development
HIL test benches are one part of our industrial automation work. All industrial automation services
In stages
How do you build a HIL bench in stages?
Four stages, and each one already pays its way: you don't need the full bench to start catching bugs. We estimate each stage's duration after the initial evaluation.
01
Minimal bench
The controller, a power supply, the key interfaces and a simple model, enough to run one test end to end and prove the approach works.
Output: A first bench and one test running automatically
Gate: The first test runs and gives a repeatable result
02
Coverage
We add interfaces, scenarios and fault injection, driven by your requirements and by the failures you've already seen in the field.
Output: Test suite and coverage matrix
Gate: You approve the list of scenarios
03
Automation
The bench resets itself, the tests run unattended, and the results are stored in a report for every version.
Output: An automated nightly run with a report
Gate: Repeated runs give the same result
04
CI integration
Every code change runs the tests, and the result goes back to developers before merge. From here you expand as needed.
Output: A CI pipeline and bench documentation
Interfaces and tools
Which interfaces and tools do we work with?
These are the interfaces and tools we actually work with. Others are checked on the first call.
Comms and fieldbuses
- EtherCAT
- CAN bus
- FDCAN
- RS-485
- RS-232
- Modbus
Testing and software
- HIL
- CI/CD
- Python
- C/C++
- Real-time Linux
HIL test benches: FAQ
How much does a HIL test bench cost?
It depends mainly on the controller and on what you want to test, so we start with a minimal bench and expand in stages, with a proposal for each stage. The main cost drivers:
- The number and type of interfaces, and whether you need real-time comms such as EtherCAT
- How detailed the plant model needs to be
- The scope of fault injection
- How many benches you need, for example one per team and one for CI
- The connection to your CI tools and reporting systems
A minimal bench that already catches real regressions is usually the right place to start.
Which interfaces and comms do you work with?
We work with CAN bus and FDCAN, EtherCAT, RS-485, RS-232 and Modbus, as well as analogue and digital I/O. If your controller uses another interface, we check it on the first call and tell you plainly whether it fits.
Can we reuse the test equipment we already have?
Yes, and it usually makes sense. Existing power supplies, data-acquisition cards, comms interfaces and test fixtures can become part of the HIL bench, as long as they can be controlled from software. At the start we go through your equipment and decide what to reuse and what's missing. Existing scripts for manual tests are also a good basis for the automated ones.
Is HIL right for a startup, or only for a large company?
Both, at a different scale. A startup starts with a minimal bench on the desk that runs the key tests on every change and stops regressions before a demo or a first shipment. In a larger company the bench joins the existing CI process, with several benches and reports for several teams.
We work with companies and startups abroad as well as in Israel: remote collaboration, English-speaking engineering, and partnerships welcome.
Who owns the test code and the bench?
Ownership of the test code, the model and the bench drawings is agreed in the contract for each project. We sign an NDA on request when the project calls for it, which is common in HIL projects because the tests reveal the product design.
Tell us about your controller, and we'll propose a minimal HIL bench
Tell us what the controller does, which interfaces it uses and which bugs reach the field or customers today. We work remotely with teams abroad, in English. An engineer will reply.
Usually a reply within 3 working hours, by email or phone