FMU-Based Interaction Layer (FIL) Node for Time-Synchronized Level-4 Multi-vECU Simulation

1. Introduction

Advanced driver-assistance systems (ADAS) and automated-driving functions are rapidly increasing the number and complexity of software features deployed in modern vehicles. This growth is accelerating the architectural shift from a traditional “one ECU per function” design to integrated platforms built around high-performance computing (HPC) units and zonal controllers, where multiple functions and distributed electronic control units (ECUs) must be validated as an interacting system. As complexity rises, late-stage integration defects become more expensive and more difficult to diagnose, making earlier and more rigorous verification a central requirement for schedule adherence and software quality.

Hardware-in-the-Loop (HIL) simulation is widely adopted to address these needs because it enables closed-loop validation of ECU software while replacing the real plant with real-time plant models, thereby reducing the dependence on costly prototypes and shortening development iterations [1,2]. However, in practical projects, the expected efficiency gains are often limited by the extensive preparation effort required before tests are executed. This preparation includes plant-model integration, physical I/O configuration, wiring and signal conditioning, communication protocol configuration (e.g., CAN/LIN), and automated test environment construction.

In small enterprises and academic laboratories that frequently handle multi-ECU distributed systems, these steps still rely heavily on manual, project-specific procedures, which are time-consuming and error-prone. Consequently, early integration is repeatedly delayed by configuration failures and rework, forming a dominant schedule bottleneck as illustrated in Figure 1. Recent studies on FMI-based virtual validation and time-synchronized multi-vECU co-simulation further highlight the need for coordinated time management and standardized co-simulation interfaces in such environments [3,4]. These challenges motivate the development of virtual HIL methodologies that shift integration and network validation earlier in the development cycle without sacrificing timing fidelity or reproducibility.

Automotive embedded software development commonly follows the V-model, progressing from requirements and design to Model-/Software-/Processor-in-the-Loop (MIL/SIL/PIL) stages and ultimately to Hardware-in-the-Loop (HIL) testing. While project constraints may omit certain stages, preparation effort and integration complexity typically increase toward the right side of the V-model. In particular, HIL testing represents the most preparation-intensive stage, as it simultaneously requires physical ECU availability, deterministic real-time execution, and complete integration of plant models, I/O interfaces, and in-vehicle communication networks [5,6]. Table 1 summarizes the evolution of the Unit Under Test (UUT) and the dominant sources of complexity across XIL levels [7]. While earlier stages primarily focus on model fidelity and software integration, HIL introduces additional challenges related to real-time constraints, hardware dependencies, and network-level interactions. As a result, delays and failures at this stage often undermine the intended efficiency gains of model-based development.

A closer examination of recurring delays in conventional HIL setup reveals three major contributors:

• (1) Dependence on physical ECU prototypes and bring-up delays. HIL testing begins only after physical ECU availability, directly coupling verification schedules to prototype delivery. Even after prototype arrival, initialization tasks (boot, memory configuration, flashing, and communication link verification) require substantial manual effort, and hardware-specific issues (e.g., wiring faults or connector problems) further increase delay.
• (2) Non-standardized interfaces and project-specific custom development. HIL must integrate analog/digital I/O for sensor/actuator emulation as well as bus interfaces such as CAN and LIN. Conventional solutions often employ custom fault injection, signal conditioning, and interface hardware tailored to each project, which increases setup and maintenance cost while amplifying the probability of configuration errors.
• (3) High configuration cost for in-vehicle networks and manual mapping. In multi-ECU systems, network traffic must be reproduced faithfully in the test environment. Message and signal definitions (commonly specified via CAN DBC files) are frequently mapped manually to simulator variables and I/O channels. Minor mistakes (e.g., scaling, endianness, cycle time, or identifier mismatches) can cause system-wide integration failure, leading to long debugging cycles and delaying the first executable test.

These challenges collectively motivate a shift toward configuration-driven and software-defined HIL (SD-HIL) approaches that aim to reduce manual setup effort while preserving deterministic timing behavior [8]. However, a key open question remains: to what extent can network and interface automation be applied without compromising timing fidelity, determinism, and behavioral equivalence to real ECU interactions. Addressing this question is central to enabling earlier, scalable, and reproducible system-level verification in modern automotive development.

To reduce the hardware dependence and move integration earlier in the development cycle, virtual HIL (vHIL) has been proposed as an intermediate validation stage between PIL and physical HIL [9,10]. vHIL executes a virtual ECU (vECU) that executes the same target binary as the physical ECU, enabling earlier closed-loop testing without requiring physical prototypes.

Prior work by Kim, Kwak, and Cho [9] demonstrated the feasibility of a Level-4 vECU that executes an unmodified AUTOSAR binary with instruction-accurate behavior, establishing a foundation for target-binary verification in virtual environments.

Despite these advances, existing vHIL approaches largely inherit the manual network-configuration workflows of conventional HIL environments: as highlighted in prior FMI-based vECU validation work, users must still manually handle inter-FMU communication and virtual bus configuration [3]. In multi-ECU scenarios, in-vehicle communication networks are still constructed through manual or semi-automated mapping of DBC-defined messages and signals to simulator variables and execution logic.

As a result, network setup remains a dominant source of test readiness delay and configuration errors, limiting the practical scalability and repeatability of vHIL-based validation. This paper addresses this gap by proposing a configuration-driven vHIL architecture that automates network construction and integration for distributed ECU systems. The core idea is to decouple network behavior from individual ECU implementations by introducing FMU-based Interaction Layer nodes (FIL Nodes) that encapsulate communication semantics derived directly from CAN DBC specifications.

These FIL Nodes are automatically generated through a DBC-driven pipeline and coupled with Renode-based vECUs using FMI co-simulation, enabling deterministic, step-synchronized execution of multi-ECU networks without manual signal mapping. This approach differs from commercial DBC-based toolchains such as Vector CANoe or Simulink CAN blocks in three key respects: (1) FIL Nodes are FMI 2.0-compliant FMUs that integrate directly into any FMI-compatible co-simulation master without vendor-specific licenses—in contrast to tools such as the CANoe Interaction Layer, which is OEM-specific; (2) FIL Nodes are generated as role-specific behavioral surrogates for named ECU nodes rather than generic bus-level models, preserving per-node transmit/receive semantics derived from the DBC—not just decoding message payloads as tools such as CANoe or Simulink CAN blocks do, but also encoding the transmission scheduling, event-trigger rules, and ECU-level send/receive roles defined in the DBC; and (3) the pipeline couples FIL Nodes with instruction-accurate Renode vECUs executing unmodified target binaries, enabling a level of binary fidelity not achievable with model-based CAN blocks alone.

By shifting integration and debugging to a pre-hardware stage, vHIL improves not only testing efficiency but also overall quality assurance, because early defects can be filtered before scarce physical HIL resources are consumed [11,12,13]. Figure 2 visualizes this shift-left rationale: the proposed approach removes dominant sources of bring-up delay and reduces late-stage validation rework.

The main contributions of this work can be summarized as follows:

1.

Configuration-driven generation of FMU-based network interaction nodes. A DBC-driven automation pipeline is introduced to generate FIL Nodes that encapsulate network I/O structures and communication logic as FMI-compliant models, substantially reducing repetitive and error-prone manual mapping tasks in HIL and vHIL setups.

2.

Improved repeatability and scalability of multi-ECU vHIL integration. By automating signal scaling, byte ordering, scheduling attributes, and DBC-to-FMU mapping, the proposed approach minimizes human-induced configuration errors and enables reproducible construction of distributed ECU networks in a virtual environment.

3.

Reduction of test readiness effort while preserving timing fidelity. By eliminating manual DBC-to-simulator signal mapping, the proposed pipeline removes the dominant recurring configuration steps (identifier assignment, scaling, endianness, and cycle-time setup) that otherwise require per-project manual effort. Experimental validation confirms that the resulting vHIL environment maintains timing behavior equivalent to physical ECU measurements, with a maximum relative error of 0.171% across all evaluated step sizes.

The remainder of this paper is organized as follows. Section 2 reviews related work on HIL and vHIL validation, FMI-based co-simulation, and existing DBC-driven network modeling approaches. Section 3 presents the proposed configuration-driven FIL Node methodology, including the modeling of network interaction logic and timing behavior. Section 4 describes the automated generation pipeline and the overall vHIL co-simulation architecture integrating FIL Nodes with Renode-based vECUs. Section 5 reports experimental validation results, focusing on timing fidelity and scalability under different simulation configurations. Finally, Section 6 concludes the paper and discusses limitations and directions for future work.

2. Related Work and Technical Background

2.1. Xil Verification Framework and Virtual ECU Technology

X-in-the-Loop (XIL) verification provides a systematic framework for validating embedded control software by progressively introducing implementation realism through MIL, SIL, PIL, vHIL, and HIL stages [14,15]. While earlier stages focus on functional correctness and code integration, HIL introduces real-time execution, physical I/O, and full network interaction, making it the most resource-intensive phase. Virtual HIL (vHIL) has been proposed to bridge the gap between PIL (or SIL) and physical HIL by replacing physical ECUs with virtual ECUs (vECUs) that execute the same target binary, enabling closed-loop testing without hardware prototypes.

Automotive ECU software commonly follows the AUTOSAR Classic Platform (CP) architecture, which achieves hardware abstraction through a layered structure—Application Layer, Runtime Environment (RTE), and Basic Software (BSW)—enabling portability across physical and virtual targets [16,17]. Recent work demonstrated that unmodified AUTOSAR binaries can be executed with instruction-level accuracy on Renode-based vECUs, forming the basis for binary-faithful vHIL [9]. However, existing vHIL approaches largely inherit the manual network-configuration workflows of conventional HIL setups, leaving multi-ECU communication integration as a persistent bottleneck in scalable and reproducible virtual validation. The proposed FIL Node addresses this gap by introducing a role-specific, auto-generated FMI component that carries the full transmit/receive semantics of a named ECU node—a structural separation not provided by generic CAN-FMU models or the binary-execution layer of Renode itself.

2.2. Fmi-Based Co-Simulation and the Renode Platform

The Functional Mock-up Interface (FMI) provides a standardized, tool-independent mechanism for integrating heterogeneous simulation components [18,19]. FMI 2.0 Co-Simulation (CS) mode, in which each Functional Mock-up Unit (FMU) encapsulates its own solver and a master algorithm coordinates time advancement and data exchange, is well suited to vHIL environments requiring deterministic, step-synchronized execution across vECUs, plant models, and network models. Prior work applied FMI-based co-simulation to automotive ECU validation [3] and time management [4]; however, communication semantics were typically modeled at a coarse abstraction level or required manually constructed components, limiting scalability and reproducibility in multi-ECU scenarios.

Renode is an open-source virtual development framework that supports execution and debugging of unmodified embedded software across diverse processor architectures [20]. Virtual hardware is described through text-based REPL platform files specifying CPU types, memory maps, and peripheral interfaces, enabling instruction-accurate AUTOSAR binary execution on a host PC. Commercial virtual platform tools such as ARM Fixed Virtual Platforms (FVP) and Fast Models provide instruction-accurate execution for ARM-based targets, but are architecture-specific and require proprietary licenses. Moreover, peripheral modeling in FVP and Fast Models typically relies on vendor-supplied templates with limited customizability, whereas Renode allows user-defined peripheral implementations directly in C# or Python, making it straightforward to model ECU-specific peripherals such as custom timer and CAN controllers. Renode was therefore selected in this work as an open-source, multi-architecture, and peripherally extensible alternative. In the proposed vHIL architecture, Renode-based vECUs provide binary-level execution fidelity, while FMI-based FIL Nodes supply the explicit interaction layer for network timing and message handling—a separation that is not inherently provided by Renode alone.

3. Design of the FMU-Based Interaction Layer (FIL) Node

Conventional HIL and vHIL approaches require engineers to manually construct network interaction nodes from DBC files and design specifications, resulting in extensive configuration effort and high susceptibility to parameterization and mapping errors. These limitations are particularly pronounced in distributed multi-ECU scenarios, where network complexity scales rapidly with the number of nodes and messages.

To address this problem, this paper introduces a configuration-driven methodology for constructing CAN-based FMU Interaction Layer (FIL) Nodes. It is important to distinguish the FIL Node from a generic CAN-FMU. A CAN-FMU is any FMU that implements some form of CAN bus communication, typically constructed manually or with tool-specific utilities, and does not carry structural knowledge of message scheduling, signal scaling, or ECU transmit/receive roles. By contrast, a FIL Node is a role-specific FMU generated automatically for a named ECU node: it encodes that node’s complete Input–Logic–Output behavior—cyclic transmission schedules, event-trigger rules, signal decapsulation and scaling—derived by static analysis of the DBC. The FIL Node therefore acts as a drop-in behavioral surrogate—a lightweight substitute model that replicates the communication behavior of a physical ECU’s network stack far more efficiently than executing the full binary—rather than merely serving as a bus-level communication channel. This distinction is what enables automatic construction of a complete multi-node virtual CAN network from a single DBC file without any manual signal mapping.

The FIL Node generation process is based on static analysis of CAN network definitions and test specifications. A DBC file is parsed to extract message attributes, including transmission modes, periods, trigger conditions, transmitter–receiver relationships, signal grouping, physical units, and scaling parameters. These attributes are systematically mapped to the input and output variables of the FIL Node, allowing the automatic construction of a baseline execution skeleton that reproduces the temporal and logical characteristics of an in-vehicle CAN network without manual signal mapping.

Messages handled by a CAN-based FIL Node are classified according to their transmission semantics. Cyclic messages are processed at fixed periods defined in the DBC and follow a deterministic processing pipeline comprising physical-to-raw scaling, message encapsulation, and insertion into an internal transmission queue. Event-triggered messages are activated when predefined trigger conditions are satisfied, such as internal state changes or the reception of external messages. For these messages, the FIL Node executes a sequence of decapsulation, scaling, internal logic evaluation, re-encapsulation, and queue insertion.

Both cyclic and event-triggered messages are scheduled from the internal queue according to CAN arbitration rules, where lower message identifiers have higher priority. To prevent unrealistically instantaneous message propagation in PC-based simulation environments, the FIL Node applies a deterministic transmission delay derived from message length and bus baud rate. This delay approximates the temporal behavior of a physical CAN bus while remaining compatible with discrete-time FMI-based co-simulation.

To approximate the CAN transmission time in a deterministic manner, we model the frame-level delay as the ideal serialization time over the bus. Let $R_b$ denote the CAN baud rate (bit/s) and D the payload length in bytes ($0\le D\le 8$). For example, using a standard format length without Data field of 44 bits for SOF, arbitration, control, CRC, ACK, and EOF, the transmission delay is

$$T_{\mathrm{tx}}\left(D\right)={\displaystyle \frac{44+8D}{R_b}}.$$

(1)

For $R_b=1$ Mbps and $D=8$, this yields $T_{\mathrm{tx}}=108\mu$s. This model intentionally captures deterministic serialization delay; arbitration-induced jitter, bit stuffing, and host or driver buffering effects are not included and are discussed as limitations. If the frame is extended format, Id field became 29bit and some additional bits.

Figure 3 summarizes the resulting Input–Logic–Output structure of the FIL Node. Incoming messages are decapsulated and scaled at the input stage, processed by internal logic blocks, and re-encapsulated at the output stage before transmission scheduling. This tripartite structure allows test-specific logic to be modified or extended without altering the auto-generated communication skeleton.

Overall, the proposed FIL Node design provides a structural advantage over manual and semi-automated CAN modeling approaches by eliminating repetitive configuration tasks and reducing human-induced errors. By separating network interaction behavior into an explicit, auto-generated layer, the method supports scalable integration with automated model and code generation pipelines and enables rapid instantiation of closed-loop vHIL environments directly from DBC-defined communication specifications.

4. Auto Generator for FIL Node

4.1. Overview of the Auto Generator Framework

To operationalize the FIL Node design methodology introduced in Section 3, this section presents the Auto Generator: an automated pipeline that transforms CAN network specifications directly into executable FIL Node FMUs. The pipeline ensures that network interaction logic is generated in a consistent, reproducible, and scalable manner—eliminating the manual translation step that remains a primary source of configuration errors in conventional workflows.

As illustrated in Figure 4, the framework takes a CAN DBC file as the primary input and produces FMI 2.0—compliant FIL Node FMUs through a structured, multi-stage process. While DBC files encode essential network information such as message definitions, signal layouts, scaling rules, and ECU relationships, their syntax is optimized for human readability rather than direct structural interpretation. Consequently, a dedicated preprocessing stage is required to enable systematic and unambiguous extraction of network semantics.

4.2. Dbc Preprocessing and Intermediate Representation

The first stage of the framework converts the DBC into a message-oriented intermediate representation expressed in JSON format. In a raw DBC, information is distributed across multiple constructs (e.g., BO, SG, BA_DEF)(Figure 5), which complicates automated analysis and often necessitates proprietary editors. The proposed preprocessing consolidates these scattered elements into a unified, message-centric JSON structure. For each message, the representation captures three categories of information: network topology (transmitter and receiver ECU assignments), protocol parameters (identifier, data length code, and transmission mode), and per-signal attributes (definitions, physical units, scaling and offset, and endianness).

This JSON file is then used as the common input for all subsequent pipeline stages—model skeleton generation, code generation, and FMU export—so that any change to the DBC requires only a re-run of the preprocessing step rather than manual updates across multiple stages.

4.3. Node-Level Structuring and Transmission Semantics

From the intermediate representation, the framework derives node-level specifications by grouping messages according to transmitting and receiving ECUs. Messages are further classified into cyclic and event-triggered categories based on their transmission semantics. Because standard DBC files do not explicitly encode event-trigger conditions, the framework derives a default trigger from the DBC itself. Specifically, the DBC records which ECU transmits each cyclic message; the framework selects the cyclic message of the transmitting ECU associated with the event-triggered message as its default trigger. In the four-ECU experimental scenario, for example, ECU1’s event message 0x200 is triggered by the reception of 0x103, which is the cyclic message sent by the ECU listed as the transmitter of 0x103 in the DBC. This default is therefore grounded in the DBC-defined network topology rather than an arbitrary assumption. Once the Simulink model skeleton is generated, users can replace this default trigger logic with application-specific conditions (e.g., a signal threshold or a state-machine transition) by modifying the designated Logic Layer block; the change is then applied to the FMU in the subsequent code-generation and export stages, without altering any other part of the auto-generated skeleton.

When cyclic traffic follows fixed nominal periods—as in the 100 ms scenario evaluated here—the DBC-derived default trigger closely matches physical ECU behavior, and deviating from this assumption introduces negligible behavioral change. For more complex cases involving multi-condition event logic, a real ECU’s OS scheduler absorbs any computation-induced response delay without disturbing other cyclic messages; the FIL Node does not capture such computation-induced transmission delays, so they must be explicitly added via the Logic Layer block if behavioral equivalence is required.

The resulting node-level specification defines the complete set of communication responsibilities for each FIL Node and provides the structural foundation for constructing the Input–Logic–Output layers described in Section 3.

4.4. Model Skeleton and Code Generation

Using the node-level specification, the framework generates both a model skeleton and corresponding C/H source code. The model skeleton organizes CAN communication behavior into modular processing stages, including decapsulation with bit-level extraction and scaling, internal logic execution, encapsulation of outgoing frames, and queueing and scheduling based on CAN identifier priority.

DBC-dependent elements—such as message identifiers, payload layouts, scaling rules, and periodic attributes—are generated automatically, while reusable runtime components (e.g., schedulers, encapsulation routines, and FMI interfaces) are incorporated from predefined templates. This separation enables regeneration of FIL Nodes when DBC files change, without duplicating or manually modifying shared logic.

4.5. Fmu Export and Deterministic Timing Configuration

In the final stage, the generated model skeleton and source code are packaged as an FMI 2.0 Co-Simulation FMU. This process includes model description generation, compilation, resource organization, and FMU packaging. Key simulation parameters—such as bus baud rate, fixed step size, and transmission-delay settings—are configured during export and embedded into the FMU timing model.

By explicitly parameterizing these timing attributes, the framework ensures deterministic message transmission behavior compatible with master-controlled, step-synchronized co-simulation. Determinism across the full co-simulation is maintained as follows: (i) MasterSim advances all FMUs—including FIL Nodes and the bus FMU—in lock-step, so no FMU observes inputs from a future step; (ii) Renode-based vECUs synchronize with MasterSim via a blocking socket handshake at each step boundary, ensuring that the vECU’s simulated time does not advance until MasterSim grants permission; (iii) within each step, the FMU execution order is fixed by the MasterSim connection graph, eliminating data-race conditions. It is important to note that this determinism applies to simulation time: wall-clock execution time is subject to host OS scheduling and socket latency, which affect only throughput (how long a step takes to complete) and not the logical correctness of the time sequence seen by any FMU. Under normal host conditions (idle system, no resource contention), this OS scheduling and socket overhead manifests only as wall-clock jitter—a run-to-run variation in how long each step takes to execute on the host, not a deviation in the logical simulation time sequence. Because MasterSim’s fixed-step master clock is unaffected by wall-clock jitter, the simulated timestamps seen by all FMUs remain identical across runs. Empirically, inter-run wall-clock variation was below 3% across all five repeated runs, confirming that this jitter is negligible in practice.

To ensure repeatability and controlled regeneration, the auto-generation process is organized as a three-stage pipeline, summarized in Table 2. Stage 1 performs DBC-to-JSON conversion, Stage 2 derives node-level workspace structures, and Stage 3 instantiates the model skeleton, generates C/H code, and exports the FMU. Each stage can be executed independently, enabling partial regeneration when network definitions or test requirements change. This structured pipeline supports systematic experimentation and large-scale vHIL deployment, where consistent regeneration of network nodes is essential for scalability and reproducibility.

In summary, the proposed auto-generation framework extends configuration-driven FIL Node design into an end-to-end methodology for constructing executable network interaction models. By automating DBC preprocessing, node-level structuring, model and code generation, and FMU export, the framework eliminates manual network configuration bottlenecks while preserving deterministic timing behavior. This approach enables scalable and reproducible construction of multi-ECU vHIL environments directly from communication specifications.

5. Experimental Validation

5.1. Validation Objectives and Experimental Scope

This section validates the proposed configuration-driven vHIL environment with respect to two complementary aspects: (i) timing fidelity of CAN communication relative to physical ECU measurements, and (ii) scalability of the co-simulation under varying node compositions and simulation step sizes. The experiments are designed to assess whether automatically generated FIL Nodes can faithfully reproduce cyclic and event-triggered CAN traffic while enabling scalable multi-node simulation in a virtual environment.

An experimental matrix comprising 28 configurations was constructed by varying two factors: simulation step size (7 levels: 10, 20, 50, 100, 200, 500, and 1000 $\mu$s) and node composition within a fixed four-node network (vECU: FIL Node = 4:0, 3:1, 2:2, 1:3). To improve robustness, each configuration was executed five times, and both aggregated 3D views and factor-isolated 2D analyses are reported to clarify the individual influence of step size and node composition.

5.2. Co-Simulation Environment and Reference Setup

The vHIL experiments were conducted using an FMI-based co-simulation environment orchestrated by MasterSim, which coordinates time advancement and data exchange among Renode-based vECUs, auto-generated FIL Node FMUs, and a CAN bus FMU (Figure 6). FIL Nodes communicate with vECU controllers through the bus FMU, while each vECU executes the target ECU binary on the Renode platform.

To establish reference data for timing fidelity, an equivalent network configuration was implemented on physical ECUs, as shown in Figure 7. In this setup, the same target binary was executed on real ECU hardware, and CAN traffic was recorded using CANoe. These measurements serve as the baseline against which the vHIL results are compared.

5.3. Network Configuration and Test Scenario

The experimental CAN network consists of four ECUs (ECU1–ECU4) that exchange both cyclic and event-triggered messages. Each ECU transmits periodic messages with a nominal cycle time of 100 ms. Upon reception of a periodic message, a corresponding event-triggered message is transmitted, forming a closed-loop interaction pattern representative of distributed ECU coordination.

Table 3 summarizes the assigned cyclic and event-triggered message identifiers for each ECU. This configuration allows validation of both time-triggered and event-driven communication semantics generated automatically from the DBC file, ensuring consistency with the behavior observed on the physical ECU network.

5.4. Measurement Procedure and Reproducibility

For each configuration in the experimental matrix, CAN messages were logged for a duration of 5 s. To account for run-to-run variability, each experiment was repeated five times. The recorded logs include message identifiers, timestamps, and inter-arrival intervals, enabling detailed analysis of timing behavior.

In the vHIL environment, timestamps are derived from the master-controlled simulation clock (MasterSim fixed-step master), ensuring fully deterministic time progression independent of host OS scheduling. In the physical ECU setup, timestamps recorded by Vector CANoe (hardware timestamp resolution: 1 $\mu$s) are used as the reference. Reported results are presented as averages across the five repeated runs; run-to-run variation is discussed in the results.

The software environment used in this study is summarized in Table 4.

5.5. Evaluation Metrics

Timing fidelity is evaluated by comparing the inter-message intervals and transmission patterns observed in the vHIL environment with those measured on physical ECUs. The primary metric is the relative error between the average message period in vHIL and the physical reference.

Scalability is evaluated using wall-clock simulation time as a function of (i) the number of vECUs, (ii) the number of FIL Nodes, and (iii) the simulation step size. This metric captures the computational overhead introduced by different node compositions and highlights the performance impact of replacing vECUs with FIL Nodes in large-scale simulations.

In summary, the experimental setup combines physical ECU measurements with controlled vHIL simulations to evaluate both timing fidelity and scalability. By systematically varying simulation parameters and repeating measurements, the experiments provide a reproducible basis for assessing the effectiveness of the proposed FIL Node-based vHIL framework.

5.6. Fidelity Results

To assess timing fidelity, the same ECU binary was deployed on a Renode-based vECU and its CAN message transmission period was compared against a physical ECU measurement. The target binary is configured with a nominal cycle time of 100 ms; the physical ECU measured by CANoe yielded a steady-state interval of 100.010 ms, which serves as the sole reference data throughout the comparison.

Table 5 summarizes the results across seven simulation step sizes (10–1000 $\mu$s), each repeated five times. Two trends are evident. First, the relative error between the vHIL message interval and the physical reference remains below 0.2% across all configurations, ranging from 0.086% at 10 $\mu$s to 0.171% at 100 $\mu$s. Second, the error stabilizes beyond 100 $\mu$s (0.171% at both 100 $\mu$s and 200 $\mu$s), indicating that the step-size-induced timing quantization error saturates at this point and does not worsen with further increases in step size. In addition, run-to-run variation was less than 0.01 ms across all configurations, confirming that the fixed-step deterministic execution produces consistent results regardless of when the simulation is run.

These results demonstrate that the Renode-based vECU replicates binary-level ECU timing behavior with high fidelity across the full range of evaluated step sizes. This capability enables earlier defect detection in the virtual environment, without requiring physical hardware prototypes, directly supporting shift-left verification strategies.

5.7. Scalability Results

Wall-clock execution time was measured for a 5-second virtual-time simulation across all 28 configurations. Figure 8 presents a 3D surface plot of these results over the full step-size and node-composition space.

Three dominant trends are observed. First, wall-clock time increases nonlinearly as step size decreases, with the sharpest growth in the 10–20 $\mu$s range. This behavior reflects the increasing number of FMU synchronization steps and socket-level exchanges per unit virtual time, and can be approximated by the following approximation:

$$T_{\mathrm{wall}}=a+{\displaystyle \frac{q}{x^p}},x=\mathrm{step}\mathrm{size}$$

(2)

For the fully vECU-only configuration (four Renode vECUs), a 5-second simulation required approximately 10 minutes of wall-clock time at a 10 $\mu$s step size, making sub-20 $\mu$s operation impractical for multi-vECU scenarios.

Second, the impact of adding vECUs is disproportionately large at small step sizes. In the 10–20 $\mu$s region, each additional vECU introduces cumulative socket-communication and event-scheduling overhead per step. Incorporating a per-step communication term yields the following extended approximation:

$$T_{\mathrm{wall}}=a+t·{\displaystyle \frac{b}{x}}+{\displaystyle \frac{q}{x^p}},x=\mathrm{step}\mathrm{size}$$

(3)

where t is the fixed socket-communication cost incurred per vECU at each simulation step, and $b/x$ is the total number of simulation steps (b denotes the simulation duration in compatible units, so $b/x$ decreases as the step size x increases). At step sizes above 200 $\mu$s, the socket overhead per step becomes proportionally smaller relative to the total step budget, so increasing the number of vECUs does not significantly increase the total wall-clock time. The dominant component of t is the blocking synchronization handshake between each Renode vECU and MasterSim, which is architecturally required for simulation-time determinism; replacing the socket transport with shared-memory IPC would reduce data-transfer latency but would not eliminate this handshake, leaving the scalability limit largely unchanged.

Third, and most significantly for scalability, configurations that include FIL Nodes in place of one or more vECUs achieve substantially lower and more stable wall-clock times, as shown in Figure 9. Because FIL Nodes execute as self-contained FMUs without socket-based external synchronization, they do not contribute per-step communication overhead. As a result, replacing vECUs with FIL Nodes for network-communication processing removes the dominant scaling factor, enabling multi-node co-simulations to operate at finer step sizes without prohibitive runtime cost. Notably, this scalability benefit is most pronounced at small step sizes, where socket-synchronization overhead dominates; at larger step sizes, the benefit diminishes as the per-step overhead becomes a smaller fraction of the total simulation cost.

These findings have two practical implications. First, step size is the dominant parameter governing computational cost in vHIL simulation, and single-vECU configurations can be operated at step sizes as fine as 10 $\mu$s without excessive runtime. Second, FIL Nodes act as a structural scalability buffer: by offloading CAN communication into independent FMUs, they extend the practical operating range of the vHIL environment toward finer step sizes and larger node counts. This structural advantage is independent of DBC content and applies to any network configuration generated by the Auto Generator pipeline.

6. Conclusions

This paper presented a configuration-driven virtual HIL (vHIL) methodology that integrates DBC-based FMU Interaction Layer (FIL) Nodes, an automated generation framework, and Renode-based virtual ECUs to reduce network-configuration effort and early integration delays in conventional HIL workflows. As automotive systems increasingly adopt multi-ECU and network-centric architectures, manual mapping of DBC-defined messages and signals remains a major contributor to test-readiness time and integration errors. The proposed approach directly addresses this bottleneck by externalizing network interaction behavior into automatically generated, FMI-compliant components.

A key contribution of this work is the design of the FIL Node as an explicit interaction layer that decouples CAN communication semantics from ECU execution. By statically analyzing DBC files and test specifications, the proposed methodology constructs a reusable Input–Logic–Output communication skeleton that supports both cyclic and event-triggered traffic without manual configuration. This design is operationalized through an Auto Generator framework that converts DBC files into a message-oriented intermediate representation, derives node-level transmission behavior, generates model skeletons and C/H source code, and exports FIL Node FMUs in a consistent and reproducible manner.

Experimental validation confirmed that the proposed vHIL environment preserves timing fidelity relative to physical ECU measurements. The Renode-based vECU reproduced the physical ECU message transmission period (reference: 100.010 ms) with a maximum relative error of 0.171% across all evaluated step sizes and a minimum of 0.086% at 10 $\mu$s, confirming binary-level timing retention. Run-to-run variation across five repeated measurements was below 0.01 ms for all configurations, demonstrating high reproducibility. Scalability experiments showed that the fully vECU-only configuration required approximately 10 minutes of wall-clock time to simulate 5 seconds at a 10 $\mu$s step, while replacing three of four vECUs with FIL Nodes reduced this to approximately 6 minutes 44 seconds (a 33% reduction) and stabilized execution time across node counts—confirming that FIL Nodes function as a structural scalability buffer that removes the dominant socket-synchronization bottleneck.

The current study has several limitations. The experimental scenarios were restricted to a single CAN network with up to four ECU nodes and simplified plant models. Realistic vehicle systems involve multiple communication technologies—such as LIN and Automotive Ethernet—as well as gateway routing, diagnostics (UDS), and security mechanisms not yet covered by the Auto Generator pipeline.

Architecturally, extending the framework to additional bus types such as LIN or Automotive Ethernet would require two parallel lines of work: (i) adding a protocol-specific peripheral interface in Renode (e.g., a LIN controller or an Ethernet MAC model) and a corresponding bus FMU in MasterSim, and (ii) adapting the Auto Generator preprocessing stage to parse the relevant network description format (e.g., LDF for LIN, or ARXML for Ethernet). The core Input–Logic–Output structure of the FIL Node and the three-stage build pipeline would remain applicable, as they are not CAN-specific; only the message-format parsing and bus-delay modeling components would need to be replaced. However, developing and validating the required interfaces for each additional bus type is a substantial undertaking in itself—comparable in scope to the CAN-focused work presented in this paper—and is therefore deferred to future work. The evaluation was also limited to single-host execution; extending the framework to distributed co-simulation and CI/CD integration remains an additional direction for future work.

Despite these limitations, the proposed configuration-driven FIL Node methodology demonstrates that network-level automation can be incorporated into vHIL environments without sacrificing timing fidelity or determinism. By eliminating repetitive manual signal mapping and enabling earlier, reproducible multi-ECU integration testing, the approach strengthens shift-left verification and provides a scalable foundation for virtual validation of increasingly complex automotive ECU networks.