Full system simulators, often called Virtual Platforms (VPs), have become an essential tool in modern system development. They allow early software design for System-on-Chip (SoC) or microcontroller units (MCUs) without requiring physical hardware, help uncover both hardware and software defects, and scale easily to fit complex co-design workflows. The result is faster development cycles, lower costs, and higher-quality products — which explains why VPs are now widely adopted across industries.

Yet, an SoC is rarely an isolated component. It typically functions as part of a broader ecosystem, interacting with sensors, actuators, mechanical elements, or even other SoCs. Consider the example of a modern car: hundreds of mechanical components are orchestrated by dozens of electronic control units (ECUs), while countless sensors continuously collect data. For such a system to operate safely and reliably, flawless interaction between all parts is critical. Any malfunction could cause severe financial loss or, worse, threaten human safety.

That is why, in early design stages when real hardware is unavailable and VPs are the main option, it is essential to model the entire system as accurately as possible. Doing so ensures early detection of costly issues. This is exactly where co-simulation becomes vital.

Co-Simulation and Its Role

Co-simulation links different simulators—often from separate vendors—into a unified simulation environment. In an earlier blog post, we introduced this idea with Vector SIL Kit, an open-source library for Software-in-the-Loop integration. We showed how MachineWare’s VPs connect seamlessly with other tools through this interface. But SIL Kit is not the only option.

A particularly well-established and widely supported standard is the Functional Mock-Up Interface (FMI) [1]. Created under the Modelica Association, FMI is backed by major players such as Bosch, Dassault Systèmes, and dSPACE. MachineWare’s VPs fully support FMI, including advanced functions such as networked simulation. In this article, we explore how our VPs use FMI to enable multi-VM co-simulation

and integration with a broad ecosystem of FMI-compliant tools

.

Figure 1: FMI Workflow

FMI in a Nutshell

At its foundation, FMI specifies how simulators are packaged and exchanged. A compliant simulator is called a Functional Mock-Up Unit (FMU). Multiple FMUs can interact through a standardized interface. Exporting tools generate FMUs, while importing tools assemble and run them.

MachineWare provides an exporting tool that generates FMUs from our VPs, offering several advantages:

–Lightweight and efficient – FMUs use minimal resources, speeding up simulation.

–Distributed performance – Workloads from multiple VPs can run across clusters of machines, allowing optimal use of available compute power. For example, Arm VPs can run directly on Arm hosts, maximizing performance through Arm-on-Arm simulation [2].

Figure 2 illustrates a scenario combining two VPs and an external FMU.

Starting with FMI 3.0, new “Layered Standards” expand the base specification. One key extension, supported by MachineWare, is the FMI LS-BUS standard for network communication. This enables simulation of CAN, Ethernet, FlexRay, and LIN protocols, making large-scale system-level simulations much easier.

Example 1: Single VP with FMPy

Our first demonstration uses FMPy [3], an open-source FMI importing tool. Here, an Arm VP boots a Linux system and runs a program to monitor a virtual temperature sensor. When the sensor crosses a defined threshold, a GPIO pin is set or unset to act as a trigger.

The FMU is configured to expose the VP’s variables, then loaded by FMPy. The results (see Screenshot 1) confirm the VP’s correct behavior: as the simulated temperature rises above 50 °C, the GPIO pin is set, and it resets when the temperature falls below 30 °C. This simple example validates the Schmitt-trigger functionality.

Screenshot 1: Simulation a VP with FMPy

Example 2: Networked VPs with FMI-LS-BUS and dSPACE VEOS

To demonstrate more advanced capabilities, we use dSPACE VEOS to connect two Arm VPs over a virtual CAN bus via FMI-LS-BUS [5]. One VP emulates a rain sensor, while the other acts as a windshield wiper vECU. The sensor continuously sends rainfall data, and the wiper VP adjusts its speed accordingly.

ControlDesk is integrated to monitor CAN traffic in real time (Screenshot 3), giving developers precise visibility into system behavior, helping with debugging, and validating protocol communication under load conditions

.

Screenshot 2: Output of both VPs during simulation

Screenshot 3: Virtual CAN Bus monitoring with ControlDesk

Conclusion

The FMI standard provides a unified way to connect and orchestrate simulators across industries. By supporting FMI, MachineWare’s VPs allow developers to create accurate, efficient, and scalable simulations for early-stage software testing. With target software running unmodified on VPs, teams can analyze its system-level impact long before physical hardware exists. The result is earlier bug detection, safer and more reliable software, and ultimately, stronger final products.