Author name: Paramveer Sahoo

Home About Us Offerings Products and Services Advanced Technologies Success Stories Partners Infineon PDH Hitex miniHIL SafeTpal Blog Contact Us X Smarter Test Automation with CaGe in miniHIL Published April 2026 — 3 min read Smarter Test Automation with CaGe in miniHIL A domain-specific language for defining, composing, and automatically generating ECU test cases — from basic functional checks to comprehensive state-transition coverage. Written By KR KEERTHI REDDY Lead Software Engineer Share This 🔗 Copy link X in Writing test cases manually for complex embedded systems is slow, error-prone, and doesn’t scale. CaGe — the Case Generator language built into miniHIL — is designed to solve exactly that. CaGe is a domain-specific language developed by PROTOS Software for modelling test logic inside miniHIL. It integrates directly with eTrice, shares the same actor-based runtime as the simulation layer, and outputs xUnit-compatible XML — a natural fit for CI/CD pipelines. The Core Building Blocks Step (Foundational): The leaf node of every test. A Step defines one or more pairs of action and reaction — stimulating the SUT and asserting its response. Steps cannot call other Steps. Sequence (Composable): Composes Steps and other Sequences into reusable test procedures. Like a function call in C or Java — parameterised, nestable, and independently executable. TestSuite (Structure): The root container for test cases. Direct children of a TestSuite are treated as independent test cases — if one fails, the next continues. Results map to xUnit XML. TestCase (Structure): An alias for Sequence at the top level of a TestSuite. Semantically identical, but signals intent clearly: this is a named, independent unit of validation. CaGe — Step with action and reaction Step setOn: // protect test from running forever timeout 100 ms action motor.start() reaction expect motor.running == true ; TestSuite MotorTests: setOn // called as a test case ; Action and Reaction — Stimulate and Observe Every Step is built from action and reaction blocks. Actions send stimuli to the SUT. Reactions define expected responses using two temporal operators: expect next (matches the immediately next message — fails if data doesn’t match) and expect finally (waits for a matching message, ignoring intermediate ones — useful for periodic or asynchronous signals). State Transition Testing — Exhaustive Coverage, Automatically For complex ECU behaviours with many states, manually writing every test case is impractical. CaGe’s StateTransitionGraph eliminates this by generating test cases automatically from a graph model. Engineers define states and transitions, annotating each with the Steps that implement the test logic. CaGe derives test paths and generates a complete TestSuite automatically. CaGe — ATM-style state transition graph (simplified) StateTransitionGraph ATM: State InsertCard: => EnterPin [ insertCard ] ; State EnterPin: => WithdrawMoney [ inputCorrectPin ] => EnterPin2 [ inputBadPin ] => ReleaseCard [ exit ] ; State WithdrawMoney: => ReleaseCard [ checkMoney ] ; State End ; ; TestSuite ATMTestSuite: generate ATM n-switch = 0 ; The n-switch argument controls coverage depth: n-switch 0 visits each transition at least once; n-switch 1 covers all consecutive transition pairs; n-switch 2 is appropriate for safety-critical certification requirements. Advanced Features Parameterised Sequences and Graphs: Steps and Sequences accept typed parameters, enabling combinatorial test variants from a single definition. Runtime test recording with PlantUML: CaGe records actions and reactions at runtime and renders them as PlantUML sequence diagrams — invaluable for debugging failures without re-running the system. Deep C/C++ integration: Target code can be embedded directly inside Steps and Sequences using backtick syntax. Includes, defines, and complex data comparisons in native C integrate seamlessly with CaGe logic. The miniHIL + eTrice + CaGe Stack CaGe is the test authoring layer of a cohesive three-tier stack: miniHIL provides the hardware interface, eTrice provides the environment modeling framework, and CaGe provides the test language that drives validation. All three share the same runtime — no protocol translation, no timing gaps. For ECU validation teams, this means a single, consistent toolchain from simulation model to CI report, running on a workbench unit every developer can own.

Home About Us Offerings Products and Services Advanced Technologies Success Stories Partners Infineon PDH Hitex miniHIL SafeTpal Blog Contact Us X 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. Written By KR KEERTHI REDDY Lead Software Engineer Share This 🔗 Copy link X in 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. 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. 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

Home About Us Offerings Products and Services Advanced Technologies Success Stories Partners Infineon PDH Hitex miniHIL SafeTpal Blog Contact Us X What Is miniHIL — and Why Does It Matter? Published April 2026 — 3 min read What Is miniHIL — and Why Does It Matter? Early validation of embedded software is essential. miniHIL brings this capability directly into the developer workflow. Written By KR KEERTHI REDDY Lead Software Engineer Share This Copy link X in A bug found during implementation costs a few lines of code. The same bug found after release can cost millions — and in safety-critical systems, far more than money. Meaningful hardware-level testing is routinely deferred because the tools are expensive, shared, and arrive late in the project cycle. miniHIL was built to break that pattern. Developed by PROTOS Software, it is a compact Hardware-in-the-Loop (HIL) system designed to sit on every developer’s workbench and run tests after every code change — even before production ECU hardware exists. miniHIL: Hardware-in-the-Loop for Every Developer miniHIL is a complete HIL solution in an A4-sheet footprint. The hardware board interfaces the Device Under Test with a powerful STM32H7 simulation processor. A central patch panel connects the target microcontroller’s physical pins to software models of the surrounding environment — sensors, actuators, and bus protocols running in real time. From the firmware’s perspective, it is receiving genuine sensor signals and actuator responses. It cannot distinguish simulated inputs from physical ones. “The PROTOS miniHIL’s purpose is to provide the tools necessary to perform HIL tests directly to developers, so that comprehensive testing can be performed at all stages of development.” — PROTOS miniHIL User Guide Key Advantages at a Glance Compact and cost-efficient: With an A4 footprint, it is priced for per-developer deployment rather than shared lab use. Broad protocol coverage: CAN, SPI, I²C, UART, GPIO, Ethernet, and LIN are fully supported out of the box. Automated regression testing: Test suites run automatically after every build, catching regressions the exact moment they appear. CI-ready architecture: Native CI server licensing enables seamless pipeline integration triggered by every firmware commit. Getting Started in Four Steps Time is of the essence in embedded environments. miniHIL’s streamlined process accelerates project timelines without compromising on quality: Connect your evaluation board: Plug in the eval board as the system-under-test. Firmware runs on your actual target microcontroller. Wire the interfaces: Connect the target microcontroller’s I/O to the miniHIL via the patch panel. Add the optional FPGA board for timing-critical signals. Build environment simulations: Model sensors, actuators, and bus protocols using Eclipse eTrice and ROOM. Code is auto-generated and deployed directly to the STM32H7. Write and run tests with CaGe: Define test suites using the CaGe DSL. Tests execute automatically and CI triggers the next run on every commit.

Home About Us Offerings Products and Services Advanced Technologies Success Stories Partners Infineon PDH Hitex Blog Contact Us X Vehicle Diagnostics – Part 1: The Foundation of Modern Automotive Intelligence Vehicle diagnostics involves using electronic tools and software to monitor, detect, and report problems within a vehicle’s various systems from the engine and transmission to the brakes and emissions control units. By constantly analyzing data from multiple sensors, these diagnostic systems help technicians (and sometimes drivers) identify potential issues before they escalate into costly repairs. There are two main types of diagnostics used today: 1. On-Board Diagnostics (OBD): Built into the vehicle, OBD continuously monitors performance, emissions, and other critical parameters while the vehicle is running. 2. Off-Board Diagnostics: Conducted externally using advanced diagnostic equipment, these tests are often performed in service centers or during vehicle development for deeper fault analysis. Together, they form a powerful combination that keeps modern vehicles safe, efficient, and compliant with environmental standards. Why Is Vehicle Diagnostics Necessary? Imagine diagnosing a car without sensors, warning lights, or digital scanning tools. That was the reality for early mechanics. In the past, technicians relied purely on experience and intuition listening for unusual noises, watching for smoke, or feeling for vibrations. It was a hands-on and highly personal process, but also prone to error and inconsistency. As vehicles became more complex, this manual approach could no longer keep up. The rise of electronics, computerized engines, and emission regulations demanded a more systematic, data-driven approach to vehicle maintenance. That’s where modern diagnostics came in turning guesswork into precision. The Evolution of Vehicle Diagnostics Over time, diagnostic systems evolved alongside automotive technology. What started as simple emission monitoring has grown into a sophisticated ecosystem of interconnected protocols, sensors, and control units. Each generation of diagnostics improved data accuracy, speed, and communication between systems, paving the way for advanced vehicle intelligence and automation. Key Diagnostic Protocols The development of communication protocols has been the backbone of modern vehicle diagnostics. These protocols define how data is exchanged between a vehicle’s control units and diagnostic tools. Here’s a quick overview of the major protocols that have shaped the field: Protocol Standard Notes OBD (OBD-I) Manufacturer-specific The first on-board diagnostic system, limited to basic emission and fault monitoring. KWP2000 ISO 14230 Keyword Protocol over K-line or CAN, widely used in earlier vehicles. CAN ISO 11898 Core in-vehicle network, the backbone of ECU communication. OBD-II SAE J1979 / ISO 15031 Standardized diagnostics focused on emissions; used globally since 1996. EOBD ISO 15031 European version of OBD-II, mandatory in petrol cars from around 2001. SAE J1939 SAE J1939 CAN-based diagnostics for heavy-duty vehicles like trucks and buses. LIN ISO 17987 Low-cost communication for body electronics such as windows and seats. DoCAN (Diagnostics on CAN) ISO 15765-2 CAN Transport Protocol for advanced diagnostic data transfer. UDS (Unified Diagnostic Services) ISO 14229 Modern diagnostic standard for programming, routines, and DTC management. WWH-OBD ISO 27145 A globally harmonized emission diagnostics standard based on UDS. DoIP (Diagnostics over IP) ISO 13400 Ethernet-based diagnostics enabling high-speed and remote communication. SOVD (Service-Oriented Vehicle Diagnostics) ASAM SOVD Cloud-native, service-oriented diagnostics supporting over-the-air (OTA) updates. From the earliest OBD systems to modern cloud-enabled standards like SOVD, diagnostics have continually evolved to meet the demands of increasingly connected vehicles. Looking Ahead Vehicle diagnostics is no longer just about identifying faults it’s about predicting and preventing them. With advancements in connectivity, cloud computing, and AI, diagnostics are rapidly moving toward a future of real-time, remote, and self-correcting systems. In the next part of this series, we’ll dive deeper into OBD-I and OBD-II, exploring how these systems standardized vehicle health monitoring and transformed the way we understand automotive performance. Follow Crevavi for more insights on automotive technology:www.mobility.crevavi.comwww.crevavi.com

Home About Us Offerings Products and Services Advanced Technologies Success Stories Partners Infineon PDH Hitex Blog Contact Us X Vehicle Diagnostics – Part 2: Understanding OBD-I and OBD-II Modern cars are far more than just mechanical systems. They are intelligent, data-driven machines capable of self-diagnosing problems and maintaining optimal performance. Behind this smart technology lies a critical system known as On-Board Diagnostics, or OBD. If you’ve ever seen the “Check Engine” light appear on your dashboard, you’ve already interacted with this technology. In this article, we’ll explore what OBD really is, how it evolved from OBD-I to OBD-II, and why it plays such an important role in vehicle health and emissions control. The Two Types of Vehicle Diagnostics Vehicle diagnostics can be broadly divided into two categories: On-Board Diagnostics (OBD):This system is built directly into the vehicle. It continuously monitors performance, emissions, and key components while you drive. Off-Board Diagnostics:These are external systems or tools used at service centers or by OEMs to run deeper, more specialized diagnostics on a vehicle.Together, these two systems form the foundation of modern automotive maintenance, helping technicians quickly identify and resolve faults before they turn into major issues. What is On-Board Diagnostics? On-Board Diagnostics (OBD) is essentially the vehicle’s internal health monitoring system. A network of sensors spread across the car sends data to the Engine Control Unit (ECU), which continuously checks for irregularities in performance. If something goes wrong for example, a misfire or a faulty oxygen sensor the ECU records a Diagnostic Trouble Code (DTC) and triggers the familiar “Check Engine” light. This alert doesn’t tell you the exact issue, but it’s the vehicle’s way of saying, “Something’s not right, let’s get it checked.” From there, technicians use diagnostic tools to read the stored DTC and pinpoint the problem. A Short History of OBD Pre-OBD Era (Before the 1980s) Before electronic diagnostics, mechanics relied on experience, sound, and trial-and-error to identify problems. There were no automated systems to analyze engine performance. OBD-I (1980s–1995) Introduced by General Motors with the ALDL (Assembly Line Diagnostic Link) protocol. Mandated by the California Air Resources Board (CARB) in 1988 for emission monitoring. Each manufacturer used proprietary connectors and protocols, leading to inconsistency and tool dependency. OBD-II (1996–Present) Standardized by the Society of Automotive Engineers (SAE) and mandated by the Environmental Protection Agency (EPA) for all U.S. vehicles from 1996 onward. Introduced a universal 16-pin connector, standardized Diagnostic Trouble Codes (DTCs), and real-time data access. Enabled consistent emission monitoring and fault detection across manufacturers. From Limitations to Advancements: OBD-I vs. OBD-II Feature OBD-I OBD-II Standardization Proprietary connectors & protocols Universal 16-pin connector Data Access Limited, basic emission faults Real-time sensor data & detailed DTCs Tools Manufacturer-specific Works with any OBD-II scanner Emission Monitoring Minimal Continuous monitoring with readiness flags Ease of Use Complex & inconsistent Simplified, cross-compatible OBD-II revolutionized vehicle diagnostics by introducing universal standards, live data streaming, and user-friendly access benefiting both technicians and car owners. How OBD-II Works Here’s what happens when your car’s OBD-II system detects a problem: Sensors throughout the vehicle monitor key systems like the engine, fuel, and emissions. The ECU constantly analyzes this data for inconsistencies. If it detects a fault, it saves a specific Diagnostic Trouble Code (DTC) and turns on the “Check Engine” light. A technician connects a scan tool to the OBD-II port, usually located under the dashboard. The scan tool sends a request to the ECU, which responds with live data and stored codes. The technician then uses this information to identify, analyze, and repair the issue. This process allows faults to be diagnosed quickly and accurately without needing to dismantle the vehicle a huge leap forward from the pre-OBD era. The OBD-II Connector The OBD-II system uses a universal 16-pin connector, which is typically found beneath the dashboard on the driver’s side. It’s the physical gateway between the car’s internal systems and diagnostic devices. Through this connector, scan tools can access real-time performance data, read stored fault codes, and even clear them after repairs are made. The Future: Off-Board Diagnostics While OBD-II remains the global standard for in-vehicle diagnostics, the future is rapidly moving toward Off-Board Diagnostics systems that use cloud connectivity and AI to monitor vehicles remotely. This next evolution will allow for predictive maintenance, real-time health tracking, and data-driven decision-making for fleets and manufacturers alike. Stay tuned for the next part of this series, where we’ll explore how Off-Board Diagnostics is shaping the future of connected mobility. Follow Crevavi for more insights on automotive technology:www.mobility.crevavi.comwww.crevavi.com