Insufficient testing is one of the costliest risks in industrial embedded systems, leading to failures, returns, safety issues, and uncertain performance.
Hardware-in-the-Loop (HIL) testing addresses this risk, but many enterprises don’t fully use its full capabilities. They often choose to rely on traditional HIL platforms that are easy to get started with but costly. For custom HIL testing setups, companies view them as expensive lab experiments rather than as investments that deliver greater flexibility and long-term value.
This perception is no longer true, says Pavlo Matiieshyn, the Head of Embedded Development. And here are several reasons for this:
First, custom HIL setups built on software frameworks like Zephyr and Twister cost significantly less than turnkey lab solutions from dSPACE or National Instruments. This makes them accessible even for manufacturers of relatively simple products such as sensors, valves, or compact controllers.
Second, enterprises that can show automated test results on real target hardware earn greater trust. For large industry buyers, this level of evidence signals maturity, reliability, and lower delivery risk.
Finally, once established, a custom HIL framework can be reused across entire device families without rebuilding the test setup.
For example, while building a custom HIL environment, we integrated Zephyr Z-test with Robot Framework so OS-level and hardware-level tests could run in one automated workflow. This decision allowed manufacturers of relatively simple products to reuse test logic across projects rather than rebuild tests from scratch.
Read this HIL testing tutorial to further learn why HIL testing has become a strategic asset for industrial enterprises, figure out the nuances of designing custom HIL infrastructure in practice, and dive deeper into what hardware-in-the-loop testing is from tech and business perspectives. We also share hands-on experience building a software-driven HIL setup for industrial embedded systems using STM32 hardware.
What is HIL testing
Hardware-in-the-loop (HIL) is a testing and validating technique used to test embedded system software. It places a real hardware component (Hardware Under Test, HUT) into a simulated environment of the physical system, enabling complex test scenarios to be safely and cost-effectively executed without requiring the full physical system. HIL simulation helps verify the real-time behavior of electronics and hardware under realistic dynamic conditions before deployment.
From a business perspective, HIL answers one key question: Will this system/device behave correctly under real operating conditions before it reaches production or customer sites?
Hardware-in-the-loop testing bridges the gap between pure software testing and physical prototypes, ensuring algorithms work correctly under realistic conditions. At the same time, HIL can detect hardware timing issues, signal-level faults, or the interface's actual behavior.
Why HIL system testing is a strategic asset for industrial enterprises
After leading a custom HIL validation project for industrial controllers, Slavic Voitovych shares:
HIL is not about better tests. It’s about fewer business surprises.
HIL testing and validation are critical whenever real systems are unavailable during development or when control errors could lead to costly downtime, equipment damage, regulatory non-compliance, or safety risks. In sectors such as manufacturing, medical technology, aerospace, logistics, agriculture, and others, HIL testing ensures proper feature validation on target hardware, reduces integration risk, and enables more predictable development and deployment cycles.
Cost-effectiveness
First, defects found after release cost 10–30× more to fix than those detected during development. Embedded HIL shifts defect discovery earlier, when fixes are much cheaper, without risking certification or customer trust. Furthermore, drawing on his project experience, Slavic Voitovych points to a practical benefit that became especially evident:
HIL systems can simulate expensive physical components, reducing the need for expensive prototypes, specialized test equipment, and field tests. This significantly reduces development and validation costs.
Shorter time-to-market
Second, by enabling faster identification and resolution of design flaws early in the development cycle, HIL testing prevents late-stage rework and repeated delays. As development progresses, teams can validate control logic, interfaces, and failure scenarios in parallel with mechanical and electrical design, rather than waiting for physical prototypes. Consequently, the overall development timeline is shortened, allowing enterprises to bring products to market sooner with fewer disruptions.
Safety & risk
Finally, HIL testing allows engineers to safely test the control system under extreme or dangerous fault conditions without risking people, equipment, or live operations. Test scenarios such as sensor failures, overloads, or conflicting control commands are common across safety-critical and regulated domains, yet are often impractical to reproduce on real systems. By simulating these conditions, HIL testing enables thorough verification of safety-critical behavior while protecting personnel, assets, and operations.
Reproducibility
With HIL validation, any defect can be reproduced hundreds or even thousands of times under identical conditions. This removes uncertainty from debugging, enables consistent root-cause analysis, and allows teams to verify fixes with confidence. Unlike field tests, where environmental factors, hardware tolerances, or operator behavior vary, HIL allows teams to fully control inputs, timing, and system states.
Types of HIL testing: Finding the right fit
HIL testing is not a cookie-cutter solution. The right HIL setup depends on what needs to be validated, at which stage of development, and how closely the test environment must reflect real operating conditions. Industrial teams typically choose among different levels of HIL. These include full-system simulations, embedded/controller-level, and fully custom HIL testing setups.
The table below outlines the common types of HIL testing used in industrial embedded development and when each one makes sense.
Common types of HIL testing | ||||
|---|---|---|---|---|
| HIL Type | What is tested | Use cases | Advantages | Trade-offs |
| Full-scale HIL | Complete system (controller + I/O + simulated plant) | Validation of system behavior under near-real operating conditions and reducing risk before field deployment | High accuracy, validates full system behavior | High setup and maintenance costs, complex modeling effort, longer lead time to adapt tests when system architecture changes |
| Controller-level HIL | MCU or ECU (e.g., STM32) with simulated inputs/outputs | Early firmware validation, automated regression testing, and integration into CI/CD pipelines, where speed and repeatability matter most | Fast feedback, automation-friendly, scalable | Limited visibility into full system interactions, may miss issues that only appear at the system integration or commissioning stage |
| Custom HIL | Tailored combination of hardware, models, and tooling | Non-standard architectures, cases when teams need precise control over timing, signals, or test automation across multiple product variants | Exact fit to product and constraints | Requires upfront engineering effort, long-term ownership, and maintenance |
The main components of the HIL testing infrastructure
Most industrial enterprises build HIL infrastructure to support repeated, long-term testing across products and projects, not as a one-time setup. In general terms, Pavlo Matiieshyn, outlines it this way:
- Hardware Under Test (HUT) – the real industrial system/device (PLC, embedded ECU/MCU, safety controller) running the same logic intended for production.
- Real-time processor – “engine” of the HIL test system that runs time-critical tasks such as hardware I/O communication, data logging, stimulus generation, and model execution to provide an accurate hardware-in-the-loop-simulation of the system’s parts that are not physically present as part of the test.
- I/O interfaces – analog, digital, and bus signals that connect the hardware under test to the simulation (CAN, FlexRay, Ethernet, PWM signals, ADC/DAC, GPIOs, etc). They generate input signals, capture outputs for logging and analysis, and replicate the behavior of real sensors and actuators between the controller and the virtual environment.
- Operator interface – connects to the real-time processor to control test execution and visualize system behavior. It often handles test configuration, automation, result analysis, and reporting.
The architecture of custom HIL testing software
The real value of HIL is the combination of hardware and software, with the latter turning hardware signals into repeatable, automated evidence of system behavior. A modern HIL testing software should function like an automated CI/CD pipeline: tests are defined as code, executed, and produce clear results. To support this approach, a custom HIL infrastructure relies on a well-structured software stack, with each layer playing a specific role in automating, executing, and scaling tests.
Test Framework (Ztest)
A test framework makes HIL systematic. With Ztest, teams can define clear test cases to verify that the firmware behaves as expected. This includes, for example, how it handles inputs, errors, and edge cases. The benefit is repeatability: the same test can be executed hundreds or thousands of times under identical conditions, turning intermittent bugs into reproducible scenarios and enabling confident verification after fixes.
Robot Framework
Robot Framework acts as the layer that runs and coordinates tests in a custom HIL testing software setup. It lets teams describe test scenarios clearly and automate test execution across hardware, firmware, and simulation components. In the overall architecture, Robot Framework usually sits between low-level test code and higher-level CI/CD or test management tools. Its role is to control when and how tests run, not to handle hardware logic or device communication.
Orchestrator (Twister)
An orchestrator is what makes the system scalable. Twister automates building, flashing, running, and reporting tests across targets and configurations. It allows teams to trigger suites automatically, manage multiple boards and configurations, and generate consistent reports for review by engineering, QA, and project stakeholders.
How to develop your custom HIL testing infrastructure: a practical use case
Having designed HIL setups for industrial projects, Slavic Voitovych notes: for large industrial enterprises, standard HIL solutions often cannot keep up with the scale, complexity, and quality expectations of their systems. Product diversity, long lifecycles, strict quality gates, and deep integration with internal toolchains require more than a generic setup. Enterprises expect HIL infrastructure to seamlessly integrate into existing engineering workflows and scale across teams and product lines. In this context, a custom HIL setup becomes a competitive advantage rather than a testing accessory.
For our clients, we designed and implemented a custom HIL testing infrastructure for industrial embedded systems, aligned with enterprise-grade quality standards. The setup combined a universal automation framework (Robot Framework), a Lauterbach debugger, and target hardware based on an STM32 Discovery board, forming a flexible, extensible testing foundation.
Beyond building the infrastructure, we delivered reusable test scripts and developed several practical reference tests that demonstrated how the HIL infrastructure can be used in hands-on implementations.
One example validated real-time system behavior by reading hardware input states directly through the debugger, serving as a clear blueprint for building and extending HIL tests. In addition, we integrated Zephyr OS testing by connecting Z-test with Robot Framework. It was a challenging task that required aligning system-level and OS-level testing within a single automated workflow. Together, these examples showed how the infrastructure supports low-level validation while remaining accessible and reusable for engineering teams.
Value of HIL testing for system integrators and businesses
In embedded software development, a custom HIL infrastructure is an investment in stability. It allows manufacturers to verify every firmware change before release, prevent regressions, and maintain consistent behavior across product variants. Instead of reacting to failures in the field, teams can catch issues early and provide documented proof of quality to customers and partners.
Furthermore, by adopting a specific business-oriented HIL testing approach built on Zephyr, Twister, and Robot Framework, manufacturers gain greater flexibility. Tests can evolve with the product, scale across entire device families, and integrate naturally into existing development workflows.
