miniHIL Environment Modeling with ROOM and eTrice
Published April 2026 — 3 min read

miniHIL Environment Modeling with ROOM and eTrice

Firmware validation without hardware requires a deterministic and accurate representation of its runtime environment. This is how miniHIL achieves it.

miniHIL Modeling Hero Image

In miniHIL, the Device Under Test doesn't interact with physical hardware — it interacts with a deterministic, real-time executable model. That model must be structured, believable, and fully synchronised with the firmware's expectations.

miniHIL relies on eTrice and the ROOM modeling methodology to make this structured and reproducible. ROOM defines software systems across three core dimensions:

The Foundation: ROOM Modeling

eTrice provides an implementation of Real-Time Object-Oriented Modeling (ROOM) — an actor-based approach with graphical editors, C/C++ code generation, and runtime support designed for reactive embedded systems.

  • Structure: Hierarchical actors forming systems and subsystems — how components relate and are composed.
  • Behaviour: State machines defining event-driven logic — how each actor responds to the messages it receives.
  • Communication: Message exchange via ports, protocols, and bindings — how actors send and receive typed signals.

Together, these dimensions give engineers a complete, graphical picture of the simulated environment before a single piece of production hardware is available.

ROOM Dimensions Modeling

Actor-Based Execution: Determinism by Design

ROOM execution is event-driven and strictly sequential — messages are handled one at a time, each fully processed before the next begins. This deterministic model is what makes miniHIL reliable: the same sequence of inputs always produces the same sequence of outputs, which is essential for automated regression testing.

Layered Architectures with SAP and SPP

Real embedded systems are layered. ROOM supports this through Service Access Points (SAP) and Service Provision Points (SPP), enabling actors in higher layers to request services from lower layers without direct coupling. In practice, a motor controller simulation, a CAN bus adapter, and a battery model can all operate as independent, reusable actors — connected through defined interfaces, not hardwired dependencies.

Why ROOM Makes a Difference for miniHIL

  • Reusable components through well-defined protocols. A CAN bus or sensor model built once can be dropped into any future miniHIL project.
  • Clear system understanding via graphical modeling. Actors, ports, and state machines are visualisable in eTrice before code is generated.
  • Faster development through code generation. Engineers model behaviour graphically; eTrice generates the C/C++ runtime automatically.
Model Execution Process

From Model to Executable Simulation

Developers describe the environment — sensors, actuators, protocols, and their behaviours — as ROOM actors in eTrice. Once the model is complete, eTrice generates C/C++ code that is compiled and deployed to the miniHIL's STM32H7 simulation processor. The Device Under Test connects via the patch panel and from that moment, every test stimulus is grounded in the explicitly modelled system architecture.

"miniHIL becomes more than a simulator — it's a structured, executable virtual environment where architecture, behaviour, and communication are explicitly modelled before final hardware integration. CaGe test actors and simulation actors coexist in the same runtime, enabling complete test cycles every 5 to 60 minutes — fast enough for every firmware commit."

— The Result

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top