A Coordination Layer for Time Synchronization in Level-4 Multi-vECU Simulation

Abstract

In automotive software development, testing and validation workloads are often concentrated at the end of the development cycle, leading to delays and late-stage issue discovery. To address this, virtual Electronic Control Units (vECUs) have gained attention for enabling earlier-stage verification. In our previous work, we developed a Level-4 vECU using a hardware-level emulator. However, when simulating multiple vECUs with independent clocks across distributed emulators, we observed poor timing reproducibility due to the lack of explicit synchronization. To solve this, we implemented an integration layer compliant with the functional mock-up interface (FMI), a widely used standard for simulation tool interoperability. The layer enables synchronized simulation between a centralized simulation master and independently running vECUs. We also developed a virtual CAN bus model to simulate message arbitration and validate inter-vECU communication behavior. Simulation results show that our framework correctly reproduces CAN arbitration logic and significantly improves timing reproducibility compared to conventional Linux-based interfaces. To improve simulation performance, the FMI master algorithm was parallelized, resulting in up to 85.2% reduction in simulation time with eight vECUs. These contributions offer a practical solution for synchronizing distributed Level-4 vECUs and lay the groundwork for future cloud-native simulation of automotive systems.

1. Introduction

As vehicle technology advances, the volume of in-vehicle software is expanding at an accelerating pace [1]. Modern vehicles are evolving beyond mere transportation tools. They now integrate various functions such as autonomous driving, advanced driver-assistance systems (ADASs), vehicle-to-vehicle (V2V) communication, and infotainment systems, contributing to a more intelligent and interconnected driving experience. As these functions are added, the complexity of software interactions and system integration requirements increases significantly. To effectively manage and verify this growing complexity, the role of virtual electronic control units (vECUs) has become increasingly important [2].

Figure 1 illustrates how testing workloads are distributed throughout the vehicle development process, comparing cases with and without vECUs. In traditional V-model development, most testing occurs only after hardware is available, resulting in a testing bottleneck in the later stages of development [3]. This approach requires physical hardware preparation, which is both costly and time-consuming. Moreover, unexpected issues discovered late in the process can significantly delay development. In contrast, vECU-based development allows early-stage validation, even before hardware is available. vECUs enable early testing of various scenarios, helping to distribute the testing workload more uniformly across the development process. This approach facilitates early error detection, thereby reducing overall development time and costs. Furthermore, it supports a staged development process, incorporating model-in-the-loop (MIL) [4], software-in-the-loop (SIL) [5], and hardware-in-the-loop (HIL) [6] approaches. This ensures software reliability and stability before hardware integration.

The automotive open system architecture (AUTOSAR) is a standardized software platform designed to improve the modularity, portability, and reusability of vehicle software by structuring it into three layers: application software (ASW), the runtime environment (RTE), and basic software (BSW) [7]. ASW implements vehicle applications, while RTE manages interactions between ASW and BSW, and BSW abstracts hardware-level services to ensure platform independence. vECUs are simulation entities that replicate ECUs to varying degrees depending on their abstraction level [8]. Level-0 vECUs validate control algorithms at the model level (MIL), Level-1 and Level-2 introduce production code and simulated BSW for SIL testing, and Level-3 includes the full software stack in a hardware-independent configuration. Level-4 vECUs emulate actual hardware execution environments, making them suitable for high-fidelity system validation prior to physical prototype availability.

In our previous research, we acknowledged the significance of vECUs and developed a Level-4 vECU compatible with AUTOSAR based on the Renode open-source emulator [9]. This research showed that a single vECU was capable of verifying the functionality of AUTOSAR-based software without requiring hardware, significantly improving validation efficiency in the early development stages. However, modern vehicles rely on multiple ECUs that exchange data and operate cooperatively through communication channels [10]. This communication is a key factor in ensuring the smooth execution of essential vehicle functions, making reliable inter-ECU data exchange crucial. Therefore, vECUs must go beyond verifying individual ECU functionality and accurately simulate and validate inter-ECU communication and interactions to achieve effectiveness.

Although commercial solutions such as dSPACE VEOS [11] provide integrated vECU testing environments, they are typically based on a centralized simulation architecture in which multiple software modules are loaded into a single simulation process. This approach ensures time consistency across modules since all components share the same internal simulation clock. However, these tools are not designed to coordinate vECUs that are executed independently in separate emulation environments or across multiple hosts. As automotive systems continue to adopt high-performance computing platforms and zonal architectures [12], the demand for scalable and distributed simulation environments will increase. Despite this trend, existing research rarely addresses the problem of time synchronization between independently running Level-4 vECUs. Most previous work focuses on MIL-level simulation or centralized SIL platforms [13,14]. And information about synchronization strategies in commercial tools is not publicly available. Furthermore, as the automotive industry increasingly embraces containerized deployments and cloud-native development practices, simulation frameworks must evolve to support modular and distributed execution across cloud infrastructure. These limitations highlight the need for a modular and extensible coordination layer that enables time-aligned execution of multiple vECUs in distributed simulation settings.

In conventional emulation methods, vECUs operate on independent time domains, making precise timing coordination between multiple ECUs challenging. As a result, precisely triggering events or accurately managing data exchange between vECUs may be difficult. For example, the engine control ECU and transmission control ECU must periodically exchange state information to synchronize acceleration and gear shifting. Even slight timing mismatches can cause engine torque requests and shift commands to be delivered at incorrect moments. In a real vehicle, precise coordination between the engine and transmission ensures smooth acceleration and gear shifting. However, in a virtual environment, such timing misalignments can cause delayed throttle response, harsh shifting, or engine load imbalance. These timing discrepancies degrade the accuracy of vECU interactions, making precise control command execution and system validation difficult. This is a fundamental requirement for a reliable vECU simulation.

In this study, we propose a method to ensure time synchronization among vECUs in a multi-vECU simulation. The proposed approach guarantees that Level-4 vECUs operate on a unified simulation timeline, enabling more accurate modeling of interactions in multi-vECU environments and ensuring consistency in simulation results. In conventional multi-vECU simulation environments, each vECU runs independently, leading to potential discrepancies in execution timing. This lack of synchronization degrades simulation reproducibility and makes reliable validation more challenging. To address this issue, we designed the vECU-functional mock-up interface (FMI) coordination layer (vFCL) to synchronize vECU execution. vFCL serves as an interface between the FMI master algorithm and vECUs, ensuring that all vECUs share the same simulation timeline when the master algorithm issues execution commands. As a result, execution timing remains consistent across vECUs, allowing communication and control commands to be executed at their expected time points.

To accurately replicate controller area network (CAN) [15] communication in multi-vECU simulations, we configured each vECU with a CAN peripheral, enabling CAN message transmission and reception in a virtual environment. Additionally, we designed a CAN bus model in Simulink [16] and converted it into a functional mock-up unit (FMU) for integration into the simulation. This setup allows data exchange between vECUs under conditions similar to real vehicle CAN communication. Furthermore, in a simulation environment with multiple vECUs, not only time synchronization, but also the execution speed of the simulation is a critical factor. The conventional FMI [17] master algorithm executes slaves sequentially, which can lead to a significant increase in execution time as the number of vECUs grows, creating a performance bottleneck. To address this issue, we parallelized the master algorithm to optimize multi-vECU execution and maintain high performance even in large-scale simulation environments. As a result, this study demonstrates that time synchronization in multi-vECU simulations enhances reliability and reproducibility, enabling more precise validation.

To validate the proposed method, we constructed a multi-vECU simulation environment. In this study, we built a project that includes CAN communication using the Hyundai Autoever Mobilgene classic platform for R4.0.3 (Hyundai Autoever, Seoul, South Korea) [18] and generated an executable file. The built executable targets the NXP S32K148 (NXP Semiconductors, Eindhoven, The Netherlands) [19] and was validated using an S32K148 vECU running on the Renode 1.15.2 emulator (Antmicro, Krakow, Poland) [20]. Additionally, MATLAB Simulink 24.2 (MathWorks, Natick, MA, USA) was used to implement the vFCL and CAN Bus FMU, both of which were custom-developed for this study.

Despite the growing adoption of vECU-based simulation frameworks, most prior studies focus on MIL- or SIL-level configurations within centralized execution environments. These approaches do not address the challenges of synchronizing multiple Level-4 vECUs, each operating on separate emulators with independent clocks. As a result, time consistency and simulation reproducibility are difficult to ensure in such distributed settings. To address this gap, this study introduces a coordinated integration framework based on the FMI standard that explicitly synchronizes independently running vECUs and enhances simulation reliability. The main contributions of this paper are as follows:

• Design and implementation of an FMI-based coordination layer that enables time-aligned co-simulation of Level-4 vECUs with independent clocks.
• Demonstration of improved timing reproducibility in CAN communication simulation compared to conventional asynchronous SocketCAN-based methods.
• Parallelization of the FMI master algorithm to reduce wall-clock simulation time and enhance execution performance in multi-vECU simulation environments.

The remainder of this paper is structured as follows. Section 2 provides background information and discusses related work. Section 3 describes the proposed vFCL and the key components of the multi-vECU simulation environment. Section 4 outlines the simulation execution flow. Section 5 presents the experimental results on CAN communication accuracy, timing reproducibility in multi-vECU simulations, and performance improvements achieved through simulation optimization. Finally, Section 6 concludes the paper and discusses future research directions.

2. Background

2.1. Simulation and Emulation

In modern automotive development environments, simulation [21] and emulation [22] play a key role in virtually testing and verifying vehicle systems. While these two concepts are often considered similar, they differ significantly in scalability, time accuracy, and time synchronization. This section analyzes the differences between simulation and emulation across these three criteria and discusses the corresponding characteristics of vECUs.

2.1.1. Scalability

Simulation abstracts system operations and interactions, allowing the evaluation of an entire system without precisely replicating the detailed operations or physical characteristics of hardware. This abstraction enables simulation to flexibly integrate and scale system components while consuming fewer computational resources. For instance, software-based simulations can model multiple ECUs simultaneously without relying on hardware-specific characteristics, making them particularly valuable in the early stages of system development. In contrast, emulation aims to replicate hardware behavior precisely, which imposes scalability constraints. Since emulation aims to replicate hardware behavior precisely, it demands significantly higher computational resources and high-resolution clocks to maintain accuracy. As system complexity increases, the scalability of emulation becomes further limited. Consequently, in terms of scalability, simulation is more advantageous than emulation.

2.1.2. Time Accuracy

Emulation requires high time accuracy to precisely replicate hardware operations. Since hardware operates within very short time intervals, emulators maintain high timing precision by mimicking the actual hardware clock. This characteristic allows emulation to ensure accurate timing behavior in both real-time data processing and event-driven operations. In contrast, simulation typically uses larger time steps to model the overall pattern of system behavior. While this approach sacrifices some time accuracy, it is advantageous for evaluating the system at a macroscopic level. Therefore, in terms of time accuracy, emulation provides higher precision than simulation.

2.1.3. Time Synchronization

Simulation and emulation exhibit fundamental differences in how they maintain time synchronization in environments with multiple nodes. In simulation environments, systems are abstracted as mathematical models, typically operating based on differential equations, allowing all components to share a common global time variable. This enables relatively easy time synchronization between individual nodes and facilitates time alignment in multi-ECU environments. Additionally, simulation allows centralized control over simulation time, providing flexibility to pause specific nodes or adjust simulation speed as needed. In contrast, emulation replicates actual hardware behavior, where individual components operate using independent timers and rely on their own local clocks. While this approach accurately reproduces real-world system behavior, it presents challenges in maintaining global time synchronization across multi-hardware emulation environments. Specifically, in many real-world hardware systems, each unit maintains its own clock, and a centralized clock synchronization mechanism is often absent. As a result, individual timers may gradually drift out of alignment, leading to inconsistencies in time-sensitive operations. Therefore, achieving precise time synchronization across multiple hardware units requires additional hardware-based clock synchronization techniques or software-based correction algorithms, both of which introduce extra computational overhead.

2.1.4. Characteristics of Virtual ECU

In Figure 2a, we categorize vECUs based on three key aspects: time accuracy, scalability, and time synchronization. These characteristics are visualized in a three-dimensional space to depict how simulation and emulation compare in these aspects. This graph visually represents the differences between simulation and emulation and shows the relative positioning of different vECU levels based on their characteristics. Simulation typically operates with a shared global clock, making time synchronization relatively straightforward, whereas emulation relies on independent clocks for each component, making time synchronization more challenging. Additionally, simulation offers high scalability but lower time accuracy, while emulation ensures high time accuracy but has limited scalability.

Level-0 to Level-2 vECUs are more aligned with simulation, offering high scalability. On the other hand, Level-3 vECUs include the MCAL but do not directly emulate physical hardware; instead, they operate using the host PC’s MCAL implementation. As a result, Level-3 vECUs are not entirely hardware-dependent, yet they exhibit a stronger reliance on hardware interfaces compared to purely software-based simulation models. Therefore, Figure 2a positions Level-3 vECUs closer to emulation than to simulation. At the same time, Level-4 vECUs provide the highest time accuracy but have limited time synchronization.

Figure 2b illustrates the enhancement of Level-4 vECUs with improved time synchronization, represented by their shift along the time synchronization axis. Compared to Figure 2a, this modification reflects an increase in time synchronization while maintaining the existing level of time accuracy. With this improvement, Level-4 vECUs are now capable of stable execution not only in single ECU verification but also in multi-ECU interaction scenarios. This advancement enables more consistent and reproducible validation across various testing environments, allowing vECUs to retain the flexibility of simulation while achieving a level of precision comparable to real hardware.

2.2. Functional Mock-Up Interface

The FMI is a standardized interface designed to facilitate interoperability between different simulation tools, enabling seamless integration in system-level validation. In the development of complex systems such as automotive applications, various components—including mechanical dynamics, electrical systems, and software—are often modeled and tested using different simulation tools optimized for their specific domains. However, incompatibilities between these tools make it challenging to integrate them into a unified simulation environment. To address this issue, FMI provides a common standard that allows different simulation tools to exchange data and interact within a single framework, regardless of their original platforms. By utilizing FMI, models developed in heterogeneous environments can be integrated into a unified simulation, ensuring more precise validation of complex system interactions. This enhances consistency across multi-domain simulations and improves the accuracy of system-level testing.

FMI encapsulates models into independent packages called Functional Mock-up Units (FMUs), which contain all necessary data, configuration files, and executable binaries required for simulation. FMUs enable seamless sharing and integration of models across different simulation tools, allowing different simulation environments to load, exchange, and execute them seamlessly. An FMU consists of three main components:

• Model Description File: An XML file containing essential metadata about the FMU, including its behavior, inputs, outputs, and variables. Simulation tools parse this file to determine how to interact with the model.
• Binary Files: Precompiled executables or shared libraries (e.g., DLL, SO) that contain the compiled model for execution in different simulation environments.
• Additional Resources: This may include metadata, supporting scripts, and optionally source code, depending on the FMU’s configuration.

Figure 3 illustrates the interaction between the FMI master algorithm and slave FMUs. The master algorithm controls the overall simulation process and issues commands such as fmi2Instantiate(), fmi2SetupExperiment(), fmi2DoStep(), and fmi2Terminate() to the slave FMUs during the simulation. In the initialization phase, the master algorithm calls fmi2Instantiate() and fmi2SetupExperiment() to initialize all FMUs and configure the simulation environment. It then transitions the FMUs into initialization mode using fmi2EnterInitializationMode() and finalizes the setup with fmi2ExitInitializationMode(). During each simulation step, the master algorithm sends input data to the FMU using fmi2SetXXX(), where XXX represents the corresponding data type (e.g., Integer, Double). The fmi2DoStep() command is then executed, allowing the FMU to simulate for a specified time step. After computation, the FMU returns its output data, which the master algorithm retrieves using fmi2GetXXX(). This output is subsequently used as input for other FMUs in the next simulation step. This iterative process continues until the simulation reaches the predefined end time. Finally, the master algorithm issues fmi2Terminate() to finalize the FMU execution and clean up the simulation environment. Through this process, the master algorithm coordinates time synchronization and data exchange between FMUs, ensuring accurate and reliable co-simulation.

FMI operates in two main modes: model exchange (ME) and co-simulation (CS). In the ME mode, the mathematical model is defined and solved by the simulation tool’s internal solver. The tool interprets the model’s differential equations, controls the time steps, and manages the entire simulation process. In contrast, the CS mode allows each FMU to operate independently by including its own solver. Each FMU advances its own simulation time within the constraints set by the master algorithm, which coordinates time synchronization and data exchange. This mode is particularly advantageous for handling complex interactions, such as multi-ECU communication.

In this study, we introduce a wrapper FMU, called the vECU controller, to integrate Level-4 vECUs into the FMI co-simulation environment. Unlike conventional FMUs, which operate based on mathematical models, the proposed wrapper FMU is specifically designed to bridge independently operating vECUs with the integrated simulation framework. Since Level-4 vECUs emulate specific hardware, directly incorporating them as mathematical model-based FMUs presents integration challenges. The wrapper FMU serves as an intermediary, receiving commands from the master algorithm and forwarding them to the vECU via socket communication. For instance, when the master algorithm issues a fmi2DoStep() command, the wrapper FMU transmits this command to the vECU, ensuring that the appropriate simulation step is executed. This mechanism enables vECUs to function under the master’s control while maintaining synchronized execution with other FMUs in the simulation environment. As a result, vECUs interact seamlessly with other components while preserving accurate timing coordination within the system.

2.3. Renode

Renode is an open-source framework designed for emulating various embedded systems, enabling testing and validation of complex hardware and software interactions in a virtual environment. It supports a wide range of microcontrollers and allows users to extend the system by adding necessary peripherals. This enables software development and verification in an environment closely resembling real hardware.

Renode enables the configuration of virtual systems through Renode platform (REPL) description files, which define connections between modules, memory mapping, and peripheral settings. These files facilitate the modeling of complex hardware systems in a virtual environment. Additionally, Renode script files (RESC) define command sequences necessary for system operation. These scripts can load the environment defined in the REPL file and specify additional execution commands, enabling more flexible control over the simulation process. Renode includes a monitor interface that allows users to observe and control the execution state of the virtual system in real time. The monitor enables developers to read hardware states, pause and resume simulations, and execute commands, supporting effective testing and validation of system behavior under specific conditions or hardware events. These features of Renode simplify the setup and control of virtual systems integrating complex hardware and software, facilitating software development and debugging in an environment closely resembling real hardware.

2.4. Related Works

2.4.1. Time Synchronization in Heterogeneous Simulation Environments

Maintaining precise time synchronization in a multi-vECU simulation environment is crucial, especially for Level-4 vECUs that operate based on independent hardware clocks. Because Level-4 vECUs emulate hardware behavior, their execution timing is inherently asynchronous, making it difficult to maintain consistent time alignment among multiple vECUs. Therefore, existing studies on time synchronization in heterogeneous simulation environments were reviewed to assess their applicability in multi-vECU environments.

Various studies have explored time synchronization in heterogeneous simulation environments. Hasan et al. [23] proposed a synchronization method that integrates OPNET (an event-driven simulation tool) with MATLAB/Simulink (a time-driven simulation tool). Their approach involved executing MATLAB simulations up to the event occurrence time in OPNET, ensuring consistent time alignment between the two simulation environments. Similarly, Heimlich et al. [24] improved synchronization accuracy by using MATLAB as the master and controlling ns-2 (an event-driven network simulation tool). While these studies successfully addressed the synchronization challenges between network and continuous-time simulation, they did not focus on addressing the challenges of synchronizing multiple emulators with independent hardware timers.

To improve synchronization between emulation and simulation, Babu and Nicol [25] proposed the Titan platform, which utilized virtual time to synchronize emulated components with network simulations. Their approach implemented a Lookahead technique to minimize synchronization overhead and enhance performance. However, Titan primarily aimed to synchronize interactions between network simulations and emulated devices rather than tackling the complexities of multiple emulators with independent hardware clocks.

From a systems-level perspective, Elsheikh et al. [26] investigated methods to enhance interoperability in large-scale simulation environments by integrating FMI with tools such as GridLAB-D and TRNSYS. While their study highlighted the benefits of FMI-based co-simulation for complex system integration, it did not focus on resolving time synchronization challenges in multi-emulator environments.

Prior studies have explored various approaches to improving time synchronization in co-simulation environments; however, they do not comprehensively address the challenges of synchronizing multiple Level-4 vECUs. This study presents an alternative approach to enhancing time synchronization in multi-vECU environments that include hardware emulation. By integrating vECUs into a unified simulation environment, this research aims to improve the accuracy of multi-ECU interactions and ensure higher reproducibility and precision within co-simulation frameworks.

2.4.2. Research on vECU Simulation Frameworks

The structure of vECU simulation frameworks has evolved in various directions depending on the architecture level of the vECUs being simulated, the communication structure among them, and the approach to simulation integration. This section provides an overview of studies that address vECU integration and simulation, including but not limited to FMI-based approaches, and discusses their relevance to the present work.

Baumann et al. [27] proposed a multi-vECU simulation framework in which multiple vECUs are implemented as FMUs and communicate over a virtual CAN bus. Although the vECUs are based on simplified Level-2 architectures and do not incorporate precise time synchronization, the study presents a structured integration method and a CAN communication simulation architecture that shares conceptual similarity with this work. Notably, the framework illustrates a practical and industrially applicable example of consolidated verification involving multiple vECUs.

Safar et al. [28] developed a Level-4 vECU on a virtual platform (VP) constructed using mentor graphics vista architect. Their VP architecture incorporates a full AUTOSAR BSW stack and RTE, and is implemented with QEMU and SystemC TLM to provide high-level hardware abstraction. The simulation environment supports communication with peripheral devices including CAN controllers. However, the simulation operates under a loosely-coupled time coordination scheme, where VPs run asynchronously and synchronize only at message exchange points. As such, the study focuses on functional consistency rather than precise time synchronization between vECUs.

Amringer et al. [29] proposed a hypervisor-based framework for integrating vECUs in a consolidated simulation environment. Their approach utilizes a VIRTIO-based communication interface to support high-speed data exchange while achieving standardized data transfer and hardware resource separation. The framework emphasizes communication performance and deterministic partitioning of hardware resources, offering benefits in terms of communication stability and system-level integration. However, unlike the present work, it does not directly address the challenges of high-precision time synchronization between Level-4 vECUs.

Park et al. [30] implemented a closed-loop test environment using the COSYM platform, where a fuel cell control vECU was constructed and verified with plant models and virtual CAN communication. The vECU includes AUTOSAR software components but does not run as an independently compiled binary. Instead, it operates within an integrated PC-based simulation environment, thus classifying it as a Level-3 vECU. Despite the lack of target-level execution, the study serves as a meaningful example of recent industry adoption of vECU simulation practices, particularly in terms of platform integration and functional testing.

Taken together, these studies illustrate the diverse directions in which vECU simulation frameworks have evolved in recent years, spanning a variety of vECU levels, communication models, and integration strategies. While many of the prior works focus on functional validation, platform-level integration, or communication performance, they largely assume loosely coupled execution models and do not explicitly address synchronization accuracy. In particular, none of the existing studies investigate the challenges of achieving precise time alignment among independently executing Level-4 vECUs—each running on separate emulators with individual hardware clocks. Addressing this gap, the present work introduces a novel coordination framework that integrates distributed Level-4 vECUs through the Functional Mock-up Interface (FMI), enabling time-aligned execution and improving reproducibility in multi-vECU simulation environments. This contribution extends the state of the art by tackling a critical but underexplored challenge in high-fidelity automotive system simulation.

3. System Architecture and Implementation

3.1. Overall System Architecture

This system is designed to simulate an in-vehicle environment where multiple ECUs exchange data primarily via a CAN network. Figure 4 illustrates the structure of the proposed simulation framework. The system is divided into two main environments: the FMI CS environment and the emulation environment. The FMI CS environment consists of the CAN bus FMU and multiple vECU controller FMUs, whereas the emulation environment includes the FMI handler and vECUs. The vFCL consists of the vECU controller FMU and the FMI handler.

The FMI CS environment in this system utilizes MasterSim [31] for implementation, an open-source program that supports FMI 2.0 CS. MasterSim enables the import of FMUs and configuration of connections through a graphical user interface. Key simulation parameters—such as connection settings, simulation time range, and step size—are stored in a script, which is then used to execute the entire simulation. After the simulation, the exchanged data at each port are logged in a CSV file with corresponding time points, allowing users to analyze the results effectively.

The CAN bus FMU is a component designed to mimic essential functions of a physical CAN network, such as message transmission, arbitration, and transmission delay handling. The primary functions of the CAN bus FMU include handling arbitration and calculating transmission delay. Rather than employing bit-level physical arbitration, this FMU utilizes a priority queue to ensure that the highest-priority message among all incoming messages is transmitted first. The transmission delay is calculated based on the message bit length and CAN bit timing parameters, ensuring that messages are sent at the appropriate time.

The vFCL acts as an interface to seamlessly integrate the FMI CS environment with each vECU. It is composed of two primary modules. First, the vECU controller FMU receives FMI commands from the FMI CS environment, processes them, and converts them into corresponding vECU commands. The translated commands are then sent to the FMI handler over a socket connection. After executing a simulation step, the vECU controller FMU receives the execution results and, if a CAN message is generated, forwards it to the CAN bus FMU. The second module, the FMI handler, receives commands from the vECU controller, executes the specified vECU operations, and transmits the execution results back to the vECU controller at the end of each step. This layer ensures precise control over vECU execution flow, maintaining synchronization across the system and facilitating accurate interaction with the CAN bus FMU.

To simplify the implementation in a local development environment, the communication between the vECU controller FMU and the FMI handler was implemented using socket-based communication over localhost. This configuration was chosen to focus on validating the time synchronization mechanism of the vFCL without introducing additional complexity related to communication protocols. Since the system is expected to scale toward containerized vECU deployments and cloud-native simulation environments in future work, more efficient communication methods such as gRPC [32] or DDS [33] may be considered depending on the architectural requirements. Therefore, this study prioritizes verifying the structural validity of the synchronization mechanism under controlled local conditions rather than optimizing communication performance for specific network scenarios.

A vECU is a software-based module designed to emulate the behavior of a real ECU, incorporating CAN peripherals and an AUTOSAR-compliant software stack, similar to an actual vehicle ECU. Each vECU interacts with the FMI handler to receive simulation commands and exchanges data with other vECUs via the CAN bus FMU. This architecture facilitates multi-ECU communication and coordinated execution within the simulation environment.

3.2. AUTOSAR CAN

To enable CAN communication in the vECU, the required software components were configured based on the AUTOSAR standard. In an AUTOSAR environment, the proper configuration of both ASW and BSW modules is required. Figure 5 depicts the data flow across key BSW modules involved in CAN communication, including the communication manager (Com), protocol data unit router (PduR), CAN interface (CanIf), CAN transport (CanTp), and CAN driver. A correct configuration of these modules is crucial for ensuring reliable CAN message transmission and reception.

In an AUTOSAR environment, data are processed in Protocol Data Units (PDUs), which act as intermediaries between communication layers. PDUs are categorized into interaction layer PDU (I-PDU), network layer PDU (N-PDU), and link layer PDU (L-PDU), each serving a distinct role:

• I-PDU: Used in the Com module, where it aggregates signals from the RTE into structured data for transmission.
• N-PDU: Used in PduR, CanTp, and CanIf, adapting I-PDU data for network layer transmission and management.
• L-PDU: Used by the CAN driver, corresponding to the physical frame transmitted over the CAN network.

The Com module constructs I-PDUs by aggregating signals received from the RTE and manages the mapping between signals and PDUs. It serves as the interface between the RTE and PduR, facilitating data transfer between software components. The PduR module determines the transmission and reception paths of PDUs and routes data between communication layers using an internal routing table, ensuring proper data delivery. The CanTp module manages segmentation and reassembly of large data packets due to the limited maximum payload size in CAN frames. During transmission, large data packets are segmented, while received segmented data are reassembled before being forwarded to the upper layers. The CanIf module serves as an interface between the upper and lower layers of CAN communication, handling hardware mapping for transmitted and received data. CAN IDs and data lengths are used to map hardware objects, and the hardware object handle maps the appropriate CAN controller and transceiver. The CAN driver interacts with the physical CAN controller, executing the transmission and reception of CAN frames over the physical CAN network.

Most CAN communication signals follow the DBC file format developed by Vector [34]. The DBC file defines messages and signals in a CAN network, specifying essential configurations such as signal ID, data length, and transmission cycle. This standardized format ensures consistent management of all signals and messages in CAN communication. Mobilgene provides functionality for importing DBC files and harmonizing the imported settings with the project-wide BSW configuration, ensuring consistency in CAN-related module parameters.

After the DBC file was imported and the harmonization process was completed, we configured interfaces enabling the ASW’s Software Component (SWC) to interact with CAN communication ports. Once the SWC was created, we used the generated CAN interfaces to define provided ports and received ports, allowing CAN message transmission and reception. A Runnable Entity (RE) was then added to the SWC, with a timing event configured for periodic CAN message transmission and a data reception event set to trigger execution upon receiving a CAN message. Next, we developed the source code corresponding to the RE, ensuring that the defined functions execute whenever an event occurs. Once the SWC configuration was completed, it was mapped to the ECU, and the extracted information was used to reconstruct the RTE. During this process, the RTE was adapted to facilitate CAN message transmission and reception between the SWC and the underlying communication stack. Finally, the SWC’s timing event and data received event were mapped to OS tasks, followed by building and generating the executable file.

3.3. CAN Peripheral Setup

To implement CAN communication in the vECU, we added CAN peripheral support. The Renode open-source emulator, which is used for vECU implementation, defines peripherals using C#. Following this convention, the CAN peripheral was implemented in C# based on the S32K148 board reference manual. Although FlexCAN provides various functionalities, we focused on implementing only the core features necessary for CAN message transmission and reception, ensuring efficiency while maintaining focus on the research objectives. Figure 6 shows the structure of the CAN peripheral, which consists of four main modules: message buffer, message transmitter, message receiver, and register manager.

The message buffer consists of 32 buffers that handle both transmission and reception. This module manages the transmission readiness of CAN messages and temporarily stores received data. During transmission, it prepares data to be forwarded to the message transmitter module, while during reception, it temporarily holds incoming data from the network until they are processed in the next stage. This buffering mechanism is essential for ensuring the efficiency of CAN communication and maintaining the orderly transmission and reception of data.

The message transmitter module includes an arbitrator, which determines message priority by comparing the ID values of CAN messages stored in each message buffer. In CAN communication, message priority is determined by the message ID, where lower ID values indicate higher priority. The arbitrator’s behavior is controlled by the lowestBufferTransmittedFirst field in the register. When this field is enabled, the arbitrator ignores message priority and transmits messages in ascending buffer index order. When disabled, the arbitrator compares message IDs and selects the message with the lowest ID value for transmission. This priority-based arbitration ensures that high-priority messages are transmitted quickly, even in congested network conditions, allowing critical data to be delivered first. Consequently, this mechanism minimizes unnecessary delays and enhances overall communication efficiency.

The message receiver module is responsible for handling incoming CAN messages from the CAN network. Received messages are stored in the message buffer, and the message receiver then triggers a receive interrupt to notify the upper-layer module that the reception is complete. This receive interrupt operates based on the message buffer index. For the first 16 message buffers, it generates the first interrupt request (IRQ0), while for the remaining 16 buffers, it generates the second interrupt request (IRQ1). This interrupt structure assigns the message buffer groups to interrupt line, preventing congestion when multiple messages are received in specific buffers. This approach ensures efficient reception processing and timely delivery of incoming CAN messages to the upper module.

The register manager module manages the register configurations necessary for CAN communication in the vECU. In CAN communication, each register value directly influences the operation of the message transmitter and message receiver. For example, during reception, the interrupt enable and flag settings for each message buffer manage the status of received data, while the communication status register controls the overall activation of the CAN module. The register manager module handles read and write requests to the memory region, updating register values and immediately executing necessary actions based on register changes. For instance, when a transmission configuration register is updated, the message transmitter switches to a ready state. Similarly, when a receive interrupt is activated, the message receiver prepares for data reception. By dynamically applying register configurations during simulation, the register manager ensures smooth operation of the CAN communication module. Additionally, the efficient management of CAN communication settings ensures continuous and stable message transmission and reception. It enhances communication reliability in the CAN network by promptly updating buffer states and handling interrupts efficiently.

3.4. vECU-FMI Coordination Layer

We designed vFCL to facilitate the integration between the FMI CS environment and vECUs while ensuring synchronized execution in vECU simulations. This layer consists of two main components: the vECU controller FMU and the FMI handler, which collectively manage the execution flow of vECUs and coordinate data exchange with the CAN Bus FMU. Figure 7 provides an overview of this structure, depicting the vECU controller FMU and FMI handler along with their internal modules and interactions. This structured approach enhances the reliability and accuracy of multi-vECU simulations, facilitating seamless multi-vECU interactions. To enhance clarity, the following paragraphs are annotated with step numbers that correspond to the execution flow illustrated in Figure 7.

The vECU controller FMU is designed to control vECU operations and manage CAN message transmission and reception based on a Simulink model. As shown on left side of Figure 7, this FMU consists of four main modules, each handling a distinct role: initialization, command transmission, response processing, and termination. It is implemented using C caller and C function blocks, enabling the creation of Simulink blocks with C programming [35,36]. By leveraging TCP/IP sockets, the model facilitates stable communication between the vECU and the FMI CS environment, ensuring seamless data exchange.

The initializer module is responsible for handling initialization tasks at the start of an FMI simulation (step 0). It calls the socket initialization function through a C caller block, creating a socket and establishing a connection with the vECU on a specified port. The port number is defined using a constant block in Simulink and can be manually assigned by the user after the FMU is exported, allowing for flexibility in configuration. Once the initialization process is complete, the initializer module sends an init command to verify that the connected vECU has been properly initialized.

The command dispatcher module manages the simulation flow by periodically sending dostep and can commands to the vECU. It is implemented using a C caller block and determines the appropriate command to send based on the step size and string-type CAN messages received from the CAN bus FMU (step1). The step size is determined by the solver settings during FMU export and is passed along with each dostep or can command. In model-based simulation, a simulation output is always produced at each step, ensuring that the connected CAN bus FMU receives messages at each simulation step. The SOF field of the CAN message is checked for validity. If valid, a can command is sent with the message and step size; otherwise, a dostep command is transmitted (step 2).

The response processor module handles messages received from the vECU. Upon successful execution, the vECU sends a complete message. If the response includes a CAN message, this module processes the message and forwards it to the CAN bus FMU (step 9). To ensure proper termination, the terminator module manages the shutdown process at the end of the simulation. It calls the socket deinitialization function via a C Function block, sends a quit command, and closes the socket connection to properly release system resources.

The FMI handler, as shown on right side of Figure 7, is a key component that facilitates data exchange between the vECU and the FMI CS environment, enabling external control over vECU operations within the simulation. We developed this module and integrated it into the Renode open-source emulator to ensure that the vECU operates under the FMI handler’s control rather than running autonomously. It comprises four main modules that collectively manage vECU-FMI communication.

The communication manager facilitates direct communication between the vECU and the FMI CS environment, ensuring efficient data exchange and control. It establishes and maintains a TCP/IP socket connection with the vECU controller FMU, which serves as a socket server to support continuous communication. The communication manager periodically receives commands from the command dispatcher (step 3), and then forwards them to the command parser (step 8). After each vECU simulation step, it sends a completion message to the response processor (step 6). If a CAN message is generated during a simulation step, it is stored in the CAN message buffer (step 7), and any pending CAN messages in the buffer are dequeued and delivered to the response processor along with the completion message. This process ensures that messages remain synchronized with simulation time, preventing communication loss during execution.

The command parser interprets commands received from the communication manager (step 4) and dispatches them to the vECU manager. The supported command types and their parameters are summarized in

Table 1. Supported command types and parameters in vFCL.

Command Type	Description
init	Loads and initializes the vECU settings from the RESC file.
dostep	Runs the simulation for the specified step size.
can	Converts a string-type CAN message into a structured CAN object and triggers a CAN reception event.
quit	Terminates the simulation and shuts down the vECU.

. The vECU manager then executes the received commands (step 5), managing vECU operations and handling CAN message transmission and reception. Upon receiving an init command, it loads and initializes the vECU settings defined in the RESC file. If a dostep command is received along with a simulation step size, the vECU runs the simulation for the specified duration. When a can command is received, the system converts the string-type CAN message into a structured CAN message object and subsequently triggers a CAN reception event. The simulation then continues for the specified step size. Finally, upon receiving a quit command, the simulation terminates, and the vECU shuts down.

To support FMI-based execution of the vECU, we added two execution options in Renode: fmi and resc. The fmi option configures the vECU in FMI mode and accepts a port number as a parameter, enabling communication with FMI CS via a socket connection. The resc option takes the file path of a RESC script as a parameter to perform initial configuration. In conventional implementations, users had to manually input commands through the monitor interface. However, in FMI mode, execution is controlled entirely by the FMI master algorithm, making manual command entry via the monitor interface impossible. To overcome this limitation, the RESC file path is provided as an argument when executing the vECU, allowing FMI CS to initialize the system using the specified RESC file at startup.

3.5. CAN Bus FMU

The CAN protocol enables multiple ECUs to share a single CAN bus for data transmission and reception. However, when multiple ECUs attempt to transmit data simultaneously, transmission conflicts may occur. To prevent this, CAN employs an ID-based arbitration mechanism that prioritizes messages based on their ID values [37]. Each CAN message has a unique ID, where lower ID values indicate higher priority. In actual hardware, bitwise comparison is used for arbitration. When two or more ECUs transmit at the same time, the node with the higher ID (lower priority) automatically loses arbitration and defers its transmission until the bus becomes available. This arbitration mechanism not only minimizes transmission conflicts but also ensures deterministic real-time communication, enhancing overall network efficiency.

We modeled the CAN Bus FMU in Simulink to simulate CAN communication between vECUs and exported it as an FMU. Instead of replicating the complex arbitration process of actual CAN communication, our approach focuses on determining the transmission order. Figure 8 illustrates the structure of the Simulink-based CAN Bus FMU model, which consists of initializer, frame decoder, arbitrator, transmitter, and frame encoder blocks. These blocks work together to emulate CAN bus communication in a co-simulation environment.

The Initializer block configures the CAN communication environment, setting the CAN communication speed (bits per second, bps) and fixed step size as internal variables. These values are utilized by the transmitter block to calculate message transmission delay. The fixed step size follows Simulink’s solver settings and determines the discrete simulation time step, which is applied when exporting the model as an FMU CS.

In this simulation, the CAN frame structure is defined as SOF-ID-DLC-Data. The start of frame (SOF), originally used to indicate the beginning of a CAN message, is utilized in FMI-based simulation to validate messages, since FMUs generate outputs at every simulation step. The SOF field ensures that only valid CAN messages are processed. The ID field serves as a unique identifier that determines message priority, while the DLC (Data Length Code) specifies the data length in bytes. The Data field contains the actual transmitted information and is stored as a string rather than an integer, facilitating intuitive data logging and analysis.

The frame decoder and frame encoder blocks are essential components for CAN message processing in the CAN Bus FMU. The frame decoder parses incoming CAN messages, extracting SOF, ID, DLC, and Data fields, then forwarding them to the arbitrator block. Inside the arbitrator block, the frame struct builder converts the string-type data into a CAN frame struct, which is stored in a priority queue. The priority queue automatically places messages with lower ID values at the top of the tree, ensuring efficient arbitration. The highest-priority message is retrieved by the arbitrator and forwarded to the transmitter block. Conversely, the frame encoder reconstructs CAN messages by recombining individual parsed fields into a string-type CAN message, allowing independent processing of CAN message components while ensuring compatibility with CAN communication principles in the FMI simulation environment.

The transmitter block handles the transmission of CAN frames received from the arbitrator and operates in three states: idle, transmission, and intermission. In the idle state, no messages are available for transmission. When a CAN frame is received from the Arbitrator, the transmission delay is calculated by multiplying the CAN bit time by the total number of bits and dividing the result by the simulation step size to determine the transmission timing. If the calculated transmission time does not align with an integer number of simulation steps, the delay is rounded up by adding one additional step. After the transmission delay, the transmitter block transitions from idle to transmission, during which the Frame Encoder assembles and transmits the frame. Following transmission, the transmitter block enters the intermission state, a short waiting period defined by the CAN standard, typically lasting three bit times. At the end of this period, the transmitter block returns to the idle state, awaiting the next message.

This structured approach enables the CAN Bus FMU to streamline CAN message processing while maintaining the message prioritization mechanism. As a result, the model effectively emulates essential CAN functionalities within the simulation framework while ensuring efficient message transmission.

3.6. FMI Master Algorithm Parallelization

In conventional FMI co-simulation environments, FMU execution is generally not parallelized. This is because FMI was originally designed for numerical equation-based models, where each FMU independently performs numerical computations. Since traditional numerically solved FMUs operate based on input values and time variables with relatively low execution overhead, sufficient performance can be achieved without parallelization. However, vECU simulations present a different challenge. Particularly in Level-4 vECU architectures, the computational burden of each ECU increases significantly. Even executing fixed time steps incurs significant computational overhead. As fmi2DoStep() calls accumulate, the total simulation wall-clock time increases, leading to performance bottlenecks. To mitigate this issue, we parallelized the master algorithm to enable concurrent execution of vECUs, improving simulation efficiency.

To assess the potential for parallelizing the master algorithm, we analyzed three master algorithms provided by MasterSim: Gauss–Seidel, Gauss–Jacobi, and Newton [38,39]. The Gauss–Seidel method executes each fmi2DoStep() sequentially, where the output of an FMU is immediately used as the input for the next FMU within the same simulation step. This approach imposes strong data dependencies, hindering parallelization. Parallel execution may be feasible depending on the model’s connection structure, particularly when FMUs exhibit weak dependencies. However, in tightly coupled models, sequential execution remains unavoidable. In our Level-4 vECU simulation, since each vECU operates independently, the sequential nature of Gauss–Seidel could introduce a significant performance bottleneck.

In contrast, Newton’s method reformulates the relationships between FMUs as a system of equations and iteratively solves for convergence. During each iteration, a Newton matrix is computed using a difference quotient approximation, and after each fmi2DoStep(), additional correction calculations are performed to ensure numerical stability. While this method accelerates convergence, it imposes significant computational overhead and requires repeated iterations, making it less efficient for parallel execution.

The Gauss–Jacobi method, on the other hand, executes fmi2DoStep() independently for each FMU, enabling all FMUs to run concurrently within the same simulation step. Since no data exchange occurs between FMUs during execution, parallelization is straightforward. Our analysis using MasterSim confirmed that Gauss–Jacobi stores each FMU’s output in a dedicated buffer and updates the values only after the step is completed. This structure reduces synchronization overhead, as data exchange occurs exclusively between steps rather than during execution. Consequently, multicore processors can be utilized efficiently, maximizing parallel performance.

Based on this analysis, we selected Gauss–Jacobi and implemented parallelization to minimize overall simulation wall-clock time. We modified the execution of fmi2DoStep() for each vECU, ensuring that they run on separate threads while leveraging multicore processors for parallel execution. Experimental results with MasterSim demonstrated that parallelizing Gauss–Jacobi incurs minimal synchronization overhead while achieving performance improvements close to linear scaling compared to sequential execution. Additionally, as the number of vECUs increases, multicore utilization efficiency improves, effectively mitigating performance bottlenecks in traditional execution methods.

4. Simulation Setup and Flow

This section describes the simulation setup and overall flow necessary to synchronize the vFCL, the CAN Bus FMU, and the vECUs within an FMI CS environment. Section 4.1 details the configuration of the simulation environment, including the initialization process for each FMU. Section 4.2 describes the step-by-step execution flow of the simulation.

4.1. Simulation Setup

The simulation environment is configured using MasterSim. The required number of vECU controller FMUs, corresponding to the number of vECUs participating in the simulation, is loaded along with the CAN Bus FMU that manages the overall CAN network. Each FMU operates in synchronized steps controlled by the FMI master algorithm and communicates with vECUs in the emulation environment via socket connections.

Each FMU must be configured with appropriate parameters according to the simulation setup. First, the CAN Bus FMU requires the CAN speed and step size to calculate transmission delays. These parameters are essential for the Transmitter block to compute transmission delays prior to sending CAN messages. Next, the vECU controller FMU must be assigned a port number for socket communication with the FMI Handler, along with a step size that defines the vECU execution time. These parameters can be configured within the C Caller and C Function blocks of the Simulink-based FMU or directly specified in the MasterSim script.

In the Renode emulation environment, where the vECUs are executed, the fmi option enables FMI mode, and the resc option specifies the RESC script file to automate the initialization process. Renode parses the RESC script to configure the virtual machine, create peripheral devices, and load the ELF image. Meanwhile, MasterSim configures simulation parameters, including total simulation time, global step size, and FMU interconnections, using configuration files. Once the simulation starts, the master algorithm synchronizes simulation steps by invoking fmi2DoStep() for each FMU. During this process, the vECU controller FMU operates as a TCP/IP socket server, opening a port and awaiting connections from the FMI Handler module, which serves as a socket client on the vECU side. Once the FMU and vECU pre-configurations are complete, the simulation is ready to start.

4.2. Simulation Flow

When the simulation begins, the FMI master algorithm issues standard FMI function calls to all FMUs at each simulation step to ensure synchronized execution in the FMI CS environment. This process synchronizes the execution of the vECU emulator and the CAN Bus FMU so that they operate on a unified simulation timeline. The sequence diagram in Figure 9 summarizes the step-by-step interactions between these modules.

During the start initialization phase, the FMI master algorithm calls fmi2Instantiate(), fmi2SetupExperiment(), and fmi2EnterInitializationMode() for all FMUs. Meanwhile, the vECU controller FMU initializes a socket server and waits for a connection, while the FMI handler running on the emulator acts as a client and attempts to connect. Once connected, the vECU controller FMU sends an init command to the FMI handler. Upon receiving this command, the FMI handler executes the initialization commands defined in the RESC script, which involve loading the ELF image, configuring peripherals, and initializing logging settings.

Upon receiving an fmi2doStep() command, the vECU controller FMU forwards either a dostep command or a can command (if a CAN message needs to be sent) to the FMI handler. The FMI handler then instructs the vECU to simulate the defined step size. If a CAN event occurs during execution, it is processed within the same step. Inside the vECU, the AUTOSAR software stack runs, and any transmitted CAN messages are temporarily buffered by the FMI handler. Once the step is complete, the FMI handler sends a complete command to the vECU controller FMU, confirming its successful execution. If a CAN message was sent during this step, it is included in the response.

The vECU controller FMU forwards any received CAN messages to the CAN Bus FMU. After collecting CAN messages from all vECU controller FMUs for the current step, the CAN Bus FMU processes them using the Arbitrator block, which determines message priority. Following arbitration, the Transmitter block calculates the transmission delay based on the message size, after which the message is transmitted. Once the delay period has passed, the CAN message is forwarded to all connected vECU controller FMUs. If a vECU controller FMU receives a CAN message in this step, it may send a can command in the next step. This process continues iteratively until the simulation reaches its final time step. At the end of the simulation, the FMI master algorithm issues an fmi2Terminate() command to all FMUs, instructing them to shut down. The vECU controller FMU then sends a quit command to the FMI handler, which terminates the vECU emulation process.

5. Performance Evaluation

This section evaluates the performance of the proposed FMI-based vECU simulation environment. The evaluation metrics focus on CAN arbitration correctness, reproducibility in multi-vECU simulations, and the computational efficiency of the FMI CS master algorithm. In the CAN arbitration experiment, we analyze whether the proposed simulation environment correctly replicates the fundamental arbitration mechanism of a real CAN network. To evaluate timing reproducibility, we compare an asynchronous execution model using SocketCAN with the proposed vFCL-based synchronized execution to examine how time synchronization affects simulation reproducibility and execution consistency. Lastly, in the FMI CS performance experiment, we analyze the computational efficiency of the master algorithm as the number of nodes increases and evaluate the performance improvement achieved by parallel execution. Through these evaluations, we assess both the accuracy and efficiency of the proposed simulation environment.

5.1. Evaluation Environments

To evaluate the performance of our vFCL-integrated simulation environment, we conducted several experiments. Figure 10 illustrates the experimental setup. Figure 10a shows the MasterSim GUI, where the input–output connections between FMUs are represented by lines. Figure 10b shows the vECUs running in the FMI simulation environment.

The experiments, including the execution of vECUs and MasterSim, were performed on a server equipped with an AMD EPYC 9354 32-Core Processor. The system had 256 GB of DDR5 RAM and an 894 GB NVMe SSD as the primary storage. The operating system used was Ubuntu 22.04. Under these conditions, The experimental FMI CS environment was configured using MasterSim with the Gauss–Jacobi master algorithm. The simulation duration was set from 0 to 10 s, with a fixed time step size of 1 ms. To strictly enforce the simulation time constraint, the prevent overstepping over end time option was enabled.

Table 2. Experimental setup summary.

Parameter	Specification
Processor	AMD EPYC 9354, 32-Core
Memory	256 GB DDR5 RAM
Storage	894 GB NVMe SSD
Operating System	Ubuntu 22.04 LTS
Simulation Tool	MasterSim 0.9.7
Master Algorithm	Gauss-Jacobi Algorithm
Simulation Duration	0 to 10 s
Fixed Time Step	1 ms
FMU Overstep Handling	prevent overstepping over end time enabled

summarizes the specifications of the experimental environment used for all simulations in this study.

5.2. CAN Arbitration

This section verifies whether a higher-priority vECU node (i.e., a node with a lower CAN ID) is transmitted first as expected when five vECU nodes simultaneously send periodic CAN messages. This experiment evaluates whether the proposed simulation environment correctly reproduces the standard CAN arbitration process.

First, we generated a CAN DBC file, where we defined network nodes for each vECU and assigned transmitted and received CAN messages to each node. Each message was assigned a CAN ID matching its node number, with lower IDs having higher priority. After defining the messages, we generated CAN signals and mapped them to their corresponding messages.

Table 3. Experimental setup for CAN arbitration.

Node	CAN Transmission Interval (ms)	CAN ID (Priority)	Mapped vECU	Initial Transmission Time (ms)
Node1	10	0x 4	vECU1	100
Node2	20	0x2	vECU2	110
Node3	30	0x1	vECU3	120
Node4	50	0x3	vECU4	140
Node5	100	0x5	vECU5	190

summarizes the transmission interval, CAN ID, and initial transmission time for each node. Following this setup, these nodes’ CAN transmission runnable entities are first executed at 90 ms. However, since the CAN BSW configuration is not yet complete at that moment, the first transmission does not actually occur. After 90 ms, each node starts transmitting CAN frames according to its designated transmission period.

Log analysis confirmed that when multiple nodes transmitted simultaneously, the CAN Bus FMU compared message IDs and prioritized the frame with the lowest ID. Since Node3 (ID: 0x1) had the lowest CAN ID, it always won arbitration and transmitted first in case of a collision. On the other hand, Node1 (ID: 0x4), despite having the shortest transmission period (10 ms), lost arbitration due to its lower priority and was forced to retransmit in certain cases. When Node2 (ID: 0x2) and Node4 (ID: 0x3) collided, Node2 had a higher priority and transmitted first, while Node4 retransmitted after a delay. Additionally, Node5 (ID: 0x5) always lost arbitration and transmitted last. In hardware, retransmission is handled by the CAN controller. In our simulation, however, the CAN Bus FMU sequentially transmitted the remaining messages based on priority.

Table 4. Key timestamps of CAN transmission collision.

Timestamp (ms)	Competing Nodes	CAN ID (Priority)	Winner	Retransmitted Nodes
110	Node1, Node2	0x4, 0x2	Node2	Node1
120	Node1, Node3	0x4, 0x1	Node3	Node1
140	Node1, Node4	0x4, 0x3	Node4	Node1
150	Node1, Node2, Node3	0x4, 0x2, 0x1	Node3	Node1, Node2
190	Node1, Node2, Node4, Node5	0x4, 0x2, 0x3, 0x5	Node2	Node1, Node4, Node5

summarizes key collision points and the node that successfully transmitted in each case.

The results showed that frames with the lowest CAN ID were consistently transmitted first, and collisions and retransmissions were observed whenever nodes’ transmission cycles overlapped. This aligns with the bitwise priority arbitration mechanism used in hardware-level CAN arbitration, demonstrating that the proposed simulation environment effectively reproduces standard CAN communication behavior. Additionally, as the FMI Master synchronizes node execution times, developers can accurately predict and reproduce message collision points based on the configured transmission periods.

5.3. Timing Reproducibility

This experiment evaluates whether time synchronization in a multi-vECU simulation ensures consistent system behavior by comparing an existing simulation without time synchronization and the proposed simulation. The existing approach uses Linux SocketCAN [40] for communication between vECUs, whereas the proposed approach utilizes vFCL. We measured execution timing consistency using CAN communication between two vECUs. The vECU configurations are as follows:

• vECU1: Generates a timing event every 100 ms and periodically transmits a CAN message.
• vECU2: Receives the transmitted message from vECU1 and toggles an LED upon detecting a data received event.

We recorded the LED toggle time in vECU2 to analyze whether the initial CAN message reception time remained consistent across experiments. In the experiment using SocketCAN, the two vECUs were executed as independent processes. To minimize timing variations caused by manual execution, a shell script was used to automate the launch of each vECU. In contrast, in the proposed approach, both vECUs were executed with the fmi option enabled, operating under the MasterSim master algorithm and synchronized via vFCL. We conducted 100 experiments and recorded the time at which vECU2 first received a message in each trial. This allowed us to compare and analyze how consistently the timing was maintained between the asynchronous baseline method and the proposed vFCL-based synchronization method.

Figure 11 presents the experimental results. In the existing approach using SocketCAN, the initial reception time varied significantly across experiments. In contrast, with the proposed vFCL-based method, messages were received at the exact same timing in all trials. In the SocketCAN approach, the initial reception time averaged 0.348 s with a standard deviation of 0.164, indicating considerable variation in execution timing. This variation is attributed to execution start-time discrepancies arising from independent vECU process execution. Notably, in some experiments, the initial reception was delayed up to 0.595 s, which could undermine the reproducibility and reliability of multi-vECU simulations. In contrast, applying vFCL consistently resulted in an initial reception time of 0.245 s in all experiments, demonstrating that the simulation timeline remained consistent, ensuring stable results regardless of the execution environment.

These findings indicate that without time synchronization in a multi-vECU simulation, the initial message reception timing may vary depending on the execution environment. This variation makes it difficult to maintain identical simulation conditions across repeated experiments. Moreover, fluctuations in initial reception timing could introduce instability in the verification process for control logic with timing-dependent behavior. In conclusion, ensuring time synchronization in multi-vECU simulations is essential to eliminate execution variability among individual vECUs and maintain consistent initial conditions across repeated experiments.

5.4. Parallel Execution of the FMI Master Algorithm

In an integrated simulation environment, total execution time is a critical factor in determining simulation efficiency and scalability. In particular, Level-4 vECU-based simulations place significant computational demands on each vECU instance, resulting in prolonged execution times. This makes large-scale system simulations computationally expensive and, in some cases, impractical.

Figure 12 illustrates the wall-clock execution time as a function of the number of vECUs. In the sequential master algorithm, execution time exhibits a linear growth pattern as the number of vECUs increases. For instance, a 2-vECU simulation took 54.75 s, while an 8-vECU simulation required 338.79 s, demonstrating a substantial rise in execution time. This is because the traditional FMI master algorithm executes FMUs sequentially, increasing the computational overhead linearly with each additional vECU. In contrast, the parallelized master algorithm exhibited a much slower growth rate. A 2-vECU simulation took 40.42 s, and even with 8 vECUs, execution time was limited to 50.13 s. This efficiency gain results from parallel execution efficiently distributing the computational load across available processor cores.

This section quantifies the performance improvement of the parallelized FMI master algorithm, proposed in Section 3.6, compared to the sequential execution method. To evaluate its impact, we increased the number of vECUs from 2 to 8 and measured both the total wall-clock execution time and the execution times of individual FMUs. Each experiment was conducted 20 times to obtain statistically meaningful results, and the average execution time was calculated. In parallel execution, each vECU runs in an independent thread, with a dedicated thread managing the CAN Bus FMU. Consequently, the total number of threads used in the simulation is N + 1, where N is the number of vECUs.

The performance improvement achieved by parallel execution varies with the number of vECUs, as summarized in

Table 5. Performance improvement by parallel execution.

vECU Count	Conventional Master Algorithm Time (s)	Parallelized Master Algorithm Time (s)	Performance Improvement (%)
2	54.75	40.42	26.17
3	97.1	44.97	53.69
4	148.12	46.89	68.34
5	208.43	49.61	76.20
6	252.83	48.67	80.75
7	292.94	49.28	83.18
8	338.79	50.13	85.20

. For a small-scale simulation with 2 vECUs, execution time was reduced by 26.17%, while for an 8-vECU simulation, execution time was reduced by 85.20%. The improvement becomes more pronounced as the number of vECUs increases, reaching over 80% for simulations with 6 or more vECUs.

Wall-clock time measures the total simulation runtime, encompassing both the execution time of the master algorithm and the time required for output writing. Because the output writing time is identical for both cases, the observed reduction in wall-clock time primarily results from the faster execution of the master algorithm.

In the conventional master algorithm execution, the total execution time can be expressed as:

$$T_{\mathrm{seq}}=\sum _{i=1}^N{T}_{{\mathrm{vECU}}_i}+T_{\mathrm{CAN}}$$

(1)

where $T_{{\mathrm{vECU}}_i}$ represents the execution time of each vECU’s fmi2DoStep call, and $T_{\mathrm{CAN}}$ is the execution time of the CAN bus FMU.

In contrast, in the parallel execution model, the total execution time is bounded by the longest-running vECU and can be formulated as:

$$T_{\mathrm{par}}=max(T_{{\mathrm{vECU}}_1},T_{{\mathrm{vECU}}_2},\dots ,T_{{\mathrm{vECU}}_N})+T_{\mathrm{CAN}}+T_{\mathrm{overhead}}$$

(2)

where $T_{\mathrm{overhead}}$ accounts for thread management overhead.

These equations indicate that in the conventional master algorithm method, execution time increases linearly with the number of vECUs. In contrast, in the parallelized method, execution time is primarily determined by the longest-running FMU, leading to significantly lower execution times, as shown in the experimental results. This experiment demonstrates that applying parallelization effectively reduces computational overhead in FMI CS. More importantly, it enhances scalability for multi-vECU simulations, making large-scale system simulations computationally feasible within a reasonable timeframe.

6. Conclusions

In this study, we proposed the vFCL to improve time synchronization in a multi-vECU environment that includes Level-4 vECUs. Leveraging vFCL, we developed an FMI-based CS framework. Figure 4 illustrates the overall system architecture. The vFCL consists of the vECU controller FMU and the FMI handler, enabling seamless data exchange and control between the FMI CS environment and vECUs. Additionally, we developed a CAN bus FMU to simulate CAN communication between multiple vECUs, ensuring proper handling of message transmission, reception, and arbitration.

We conducted experiments on the proposed vFCL framework to evaluate CAN arbitration accuracy and simulation reproducibility. In the first experiment, we analyzed the CAN arbitration results presented in Table 4 and verified that when multiple vECUs simultaneously transmitted CAN messages, messages with lower priority were preempted and retransmitted according to the arbitration rules. In the second experiment, we repeatedly measured the reception time of the first CAN message to assess timing consistency and compared the variation with the conventional SocketCAN approach. As shown in Figure 11, the proposed method improved simulation reproducibility by ensuring consistent timing. Furthermore, we enhanced multi-vECU execution performance by parallelizing the FMI master algorithm. In the conventional sequential execution approach, the total execution time increased linearly with the number of vECUs, leading to performance bottlenecks. To address this issue, we applied parallelization by independently executing the fmi2DoStep() command for each vECU in a multi-threaded environment. Experimental results demonstrated that the parallel execution method improved performance by up to 85.2% compared to the sequential approach while mitigating the exponential increase in execution time as the number of vECUs increased (Figure 12, Table 5). These results confirm that parallel execution is an effective performance optimization technique for multi-vECU simulations.

Future research will focus on enhancing the scalability of Level-4 vECUs by optimizing computational efficiency and network integration. Since Level-4 vECUs replicate hardware functionality at a low abstraction level, they impose high computational demands per instance. To address this challenge, we plan to explore the deployment of vECUs in cloud environments using Docker containers, leveraging cloud-based resource allocation and scaling mechanisms [41]. In addition, future work will explore the selection and optimization of communication protocols suitable for distributed execution environments. While this study employed simple socket communication for local validation, scalable deployment across containers in cloud-native environments may require more efficient and robust messaging protocols such as gRPC, DDS, or other publish–subscribe mechanisms to ensure reliable data exchange under diverse network conditions. This approach will enable large-scale vECU simulations, facilitating comprehensive validation across complex ECU networks and diverse automotive environments.