Validating code for electronic control units (ECUs) by means of a software-in-the-loop (SIL) simulation has become an integral part of ECU development in the automotive sector. Whereas a few years ago it was more common to test subsystems, today the simulation of the entire system is becoming increasingly important. One reason for this is the increasing level of networking and the associated dependencies between the ECUs. Overall simulations are particularly important for original equipment manufacturers (OEMs) – suppliers typically provide the virtual ECUs (V-ECUs) required for this. When it comes to collaboration, OEMs are often faced with the question: What do I have to do to get the right V-ECU for the overall simulation from the supplier?

The Solution: A Standard for V-ECUs
The freely accessible Functional Mock-up Interface (FMI) standard is published by the Swedish non-profit organization Modelica Association and defines a standardized interface for the exchange of dynamic simulation models. It is also suitable for exchanging simple V-ECUs.

The Solution: A Standard for V-ECUs

The Functional Mock-up Interface (FMI) standard is available for exchanging simple V-ECUs in early development phases. For more complex V-ECUs, however, this standard is not sufficient, especially if these include a bus interface. That is why the FMI Layered Standard Network Communication project is working intensively on a new standard that enables efficient exchange between partners for such V-ECUs. The advantages for validation are obvious:

  • Lower integration costs thanks to better interoperability of tools and test platforms
  • More efficient collaboration thanks to significantly reduced coordination effort between OEMs and suppliers

Read all about the current development status of the standard and how dSPACE will support it in the future.

Would you like to know more about the standard or are you interested in a cooperation? Just contact us.

FMI 3.0 and the Layered Standard Concept

The FMI standard is already widely used in the field of simulation models and makes collaboration between OEMs and suppliers much easier. In version 3.0, a number of features have been added to create the basis for using it for more complex V-ECUs in the future, including:

  • Clock variables that enable the triggering of events
  • Terminals which allow for grouping input/output variables
  • The Layered Standard Concept

The latter allows new features to be added to the existing FMI standard without changing the original standard.

FMI Layered Standard Network Communication
In the future, the new layered standard will support all relevant automotive bus systems. dSPACE contributes its many years of experience in bus simulation.

FMI Layered Standard Network Communication

Since mid-2022, dSPACE has been significantly supporting the activities related to FMI Layered Standard Network Communication and contributing its many years of experience in the field of bus simulation. The focus is always on acceptance of the new standard by all parties involved, i.e., OEMs, suppliers, and tool vendors.

The project recently reached a first important milestone: the "alpha" release, the first version of the standard for CAN bus simulation. This step was so important because V-ECUs can now be tested and exchanged between the development partners on this basis. Work is underway on other buses such as LIN, Ethernet, and FlexRay, so the first versions will also be available here shortly.

The work results are transparent and can be viewed online by everyone.

The Right Interface for Every V-ECU
V-ECU levels according to prostep ivip, an international, independent association that develops innovative approaches to solving problems and modern standards for product data management and virtual product creation.

The Right Interface for Every V-ECU

A prerequisite for the acceptance of a standard is its applicability for relevant use cases. These can vary greatly for V-ECUs and typically depend on the level of the V-ECU. If the V-ECU levels are classified from 0 to 4 as in the prostep ivip white paper Requirements for the Standardization of V-ECUs, a bus interface becomes relevant from level 2, for example.

While level 0 and level 1 V-ECUs could already be created and exchanged on the basis of FMI, the new standard FMI Layered Standard Network Communication is required from level 2 onwards. To sum it up: No matter what type of V-ECUs with bus interface you want to create or exchange – the new standard will provide a suitable, standardized interface.

Good to Know

The level of a V-ECU provides information about its development status. When it comes to simulation, the following applies: The further the development of the V-ECU progresses, the more details have to be taken into account.

  • Level 0 and level 1: In the early phases of development, the focus is on validating individual application components. The exact type of signal transmission between V-ECUs is secondary and is usually not yet fully specified.
  • From level 2: Bus communication and the integration of the V-ECU into an overall simulation are becoming increasingly important. From here, basic software for bus communication must be integrated into the V-ECU. For easier integration and faster creation of the V-ECU, simplified basic software that only includes the communication (COM) module is usually used in earlier development phases.
  • Level 3: These V-ECUs come very close to the real ECU and ideally only differ in terms of the hardware-dependent driver modules. All basic software located above these modules is part of the test object here and is therefore fully integrated into the V-ECU.

Physical Signal Abstraction

If simplified basic software, which only includes the communication (COM) module, is used for level 2 V-ECUs, this is colloquially referred to as high cut, as only the upper layer of the software is included in the V-ECU. The FMI Layered Standard Network Communication provides the so-called Physical Signal Abstraction as an interface for the creation of such V-ECUs. This interface focuses on the transmission of the individual bus signals and the time of the transmission.

Network Abstraction

With level 3 V-ECUs, the entire basic software above the Controller Area Network (CAN) driver module is usually integrated into the V-ECU. The cut in the software is therefore at a very low level, usually in the hardware-dependent driver modules, which is referred to as a low cut. The new layered standard also defines a suitable interface for this with the Network Abstraction. Here, the transmission does not take place at bus signal level, but on the basis of the associated frames/PDUs (protocol data units).

The Network Abstraction develops its full potential in conjunction with an additional bus simulation. This makes it possible to include the timing and prioritization of bus messages as well as error states during the transmission of frames/PDUs in the simulation. The integrated basic software can thus be tested very realistically.

In this context, it is particularly convenient for the user, if the simulation platform provides the bus simulation directly as an integrated feature. This is where VEOS comes into play: The dSPACE platform for PC-based simulation already includes the required bus simulation, making it much easier for users to set up the simulation system.

Basic software modules that are typically used in conjunction with bus communication on an ECU. The illustration shows a typical software architecture according to AUTOSAR, using CAN as an example. With the so-called high cut, only the upper layer of the software is included in the V-ECU; with the low cut, the entire basic software down to the hardware-dependent CAN driver is usually included.
Which interface is the right one for my use case?

A bus simulation at the Physical Signal Abstraction layer is particularly suitable in these cases:

  • Level 2 V-ECUs in early phases
  • The other simulation participants provide network signals exclusively in the form of physical signals.
  • A cut within the V-ECU at the level of the communication (COM) module is possible and the granularity of the simulation is acceptable.

In a bus simulation at the Network Abstraction layer, network signals are exchanged on the basis of the associated frames. The basic software can therefore be cut starting from the PDU Router (PduR) module level down to the hardware level. This layer is thus suitable in the following cases:

  • Level 2 and level 3 V-ECUs that contain basic software below the COM module
  • Other simulation participants, e.g., restbus models, provide bus messages based on frames/PDUs.
  • Simulation of the bus behavior is desired or necessary.

Creation and Simulation of V-ECUs with dSPACE

The new layered standard also plays a key role at dSPACE, especially in the area of SIL simulation. Support for the standard is currently being implemented step by step in the dSPACE tools – initially for SystemDesk, the dSPACE tool for generating V-ECUs, and for VEOS, the platform for PC-based simulation.

Users who already work with the tools can continue to use them in their usual form and enjoy these additional features:


MCAL modules for the bus drivers can also be integrated into V-ECUs in future if they subsequently need to be exported as FMUs (*.fmu). Until now, this was only possible with V-ECUs in conjunction with the dSPACE-proprietary *.vecu format. This means that V-ECUs can be created on the basis of FMI3 and the Network Abstraction of the layered standard.


The simulation platform will automatically recognize FMUs with FMI Layered Standard Network Communication based on Network Abstraction during import. In this context, VEOS does not display bus terminals as variables or ports, but as bus controllers as usual. Restbus simulations in the form of bus simulation containers (BSC) can still be connected directly to V-ECUs. VEOS will also support the simulation of bus behavior as usual.

What will be the next steps?

With the alpha release of the layered standard for CAN, the FMI working group has reached a first important milestone. In addition to the actual specification, first demos, a C-API, and How To documentation for creating FMUs with CAN bus are already available and publicly accessible. Cross-checks are currently being carried out to ensure interchangeability between tool manufacturers and to eliminate any final inconsistencies in the specification. 

At the same time, the group is working on the specification for other buses such as FlexRay. A first draft is already available for LIN. As the basic principles are the same for all bus types, the working group can draw on the findings from the CAN specification, which speeds up the process considerably. dSPACE will also continue to be heavily involved in this area.

As far as the dSPACE tools are concerned, the implementation and support of the layered standard is in full swing: SystemDesk and VEOS will start with CAN, other dSPACE tools and support for other buses will follow.

Would you like to ask questions or get involved already? Just contact us.

About the Authors

Markus Süvern

Markus Süvern

Team Lead, Production Software & SIL Simulation, dSPACE GmbH

Christian Becker

Christian Becker

Product Manager, Production Software & SIL Simulation, dSPACE GmbH

Basic Information

  • Functional Mock-Up Interface
    Functional Mock-Up Interface

    dSPACE supports the open FMI standard for easy integration of simulation models from various sources

  • SIL测试


Product Information

  • SystemDesk

    系统架构建模并生成虚拟 ECU

  • VEOS

    基于 PC 的仿真平台



Enable form call

At this point, an input form from Click Dimensions is integrated. This enables us to process your newsletter subscription. The form is currently hidden due to your privacy settings for our website.

External input form

By activating the input form, you consent to personal data being transmitted to Click Dimensions within the EU, in the USA, Canada or Australia. More on this in our privacy policy.