For a better experience on, enable JavaScript in your browser. Thank you!

The technology of virtual validation means:

  • Running PC-based simulations to validate, verify and test ECU software in the form of V-ECUs
  • No additional hardware needed
  • Preparing and frontloading HIL tests and scenarios on a PC
  • Reusing V-ECUs in real-time simulation scenarios
  • Using V-ECUs during function development: verifying new control algorithms in the context of existing ECU software


By using virtual validation, you can perform development, verification and validation tasks much earlier, and also reduce the number of necessary additional test systems and ECU prototypes. This answers the need for early simulation that the automotive and aerospace industries are currently experiencing.

dSPACE tools cover all your virtual validation requirements: SystemDesk® for generating virtual ECUs (V-ECUs) from the ECU software architecture, VEOS® for PC-based simulation, and SCALEXIO and MicroAutoBox for real-time simulation.


Key Benefits

  • You can develop and test complex new functions in a totally virtual environment, instead of on expensive test benches.
  • You can simulate a whole ECU on a PC before a prototype is available, by combining the operating system and the ECU’s basic software components to create a virtual ECU.
  • You can prepare simulation models and test libraries on a developer PC, thus reducing your preparation time on the HIL simulator.
  • After you run simulations on your PC, you can reuse the models and V-ECUs on a HIL system; you can also use the experiment software for instrumenting and controlling the HIL simulation to run PC-based simulation.

A virtual ECU (V-ECU) is software that emulates a real ECU in a simulation scenario. The V-ECU contains components from the application and the basic software, and provides functionalities comparable to those of a real ECU. Unlike a soft ECU, which uses only a simplified Simulink®/Stateflow® model, a V-ECU usually has the same software components as the finished ECU. There is no strict dividing line between a soft ECU and a V-ECU, but a V-ECU generally represents the real ECU more realistically.


The abstraction level of a V-ECU depends on its application case:

  • V-ECU for developing a single ECU function (contains selected parts of the application software; the RTE and necessary parts of the basic software are provided automatically)
  • V-ECU at application level (application software components, the RTE, operating system)
  • V-ECU for including parts of basic software (application software components, the RTE, operating system, hardware-independent basic software such as DEM, NVRAM, ECU state manager, and COM)


Generation of a V-ECU

There are two ways to create a V-ECU, depending on the starting point and project needs, and on whether the development is based on AUTOSAR.

Function and software developers who just have single components can create a V-ECU directly with Simulink® or TargetLink®. The result is a simple V-ECU with only a selected part of the application layer of the ECU software. It enables basic function tests.

Software integrators who want to test a more complex network of functions can combine software components, functions or just legacy code from different sources in SystemDesk to create the ECU’s software architecture. Then they use the SystemDesk V-ECU Generation Module to make a full V-ECU. This contains the run-time environment (RTE) and optional basic software in addition to the application layer. The V-ECUs can be reused throughout the whole ECU development process for PC-based simulation with VEOS and for real-time simulation scenarios.


VEOS can easily be integrated in your existing tool chain, as it supports automotive standards. So when you add VEOS to your rapid control prototyping (RCP) or HIL tool chain to perform PC-based simulation, you can keep your existing tools. By deciding to use dSPACE software and hardware, you gain high flexibility and investment protection for new projects and challenges.


In July 2009, ASAM (Association for Standardisation of Automation and Measuring Systems) released the new XIL API standard, defining an interface to connect test automation tools like AutomationDesk with any simulation platform, such as VEOS or SCALEXIO. The standard enables truly platform-independent test development.

The AUTOSAR Standard

AUTOSAR (AUTomotive Open System ARchitecture) is a de-facto open industry standard for automotive electric/electronic (E/E) architectures. For example, it defines the interfaces of the ECU software, enabling the seamless use of V-ECUs with different simulation platforms. dSPACE joined the AUTOSAR partnership as a Premium Member in April 2004 and is active in defining and developing parts of the architecture and its specifications.

Functional Mock-up Interface (FMI)

The Functional Mock-up Interface (FMI) is an open standard for the exchange and integration of plant models provided by different tool vendors. dSPACE has signed the Codex of PLM Openness and works actively in the ProSTEP Smart Systems Engineering project, Modelica Association’s FMI project to further develop the FMI standard, and Modelica Association’s System Structure and Parameterization of Components for Virtual System Design (SSP) project. Through these activities dSPACE gathers the necessary knowledge and insights for supporting our customers in projects that use FMI.


If you have any questions, please contact us directly. We are glad to help:

Further Information Product Information