For a better experience on dSPACE.com, 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
  • 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 additional test systems and ECU prototypes needed. 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, as well as software for experiments, visualization, and test automation.

 

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
  • You can prepare simulation models and test libraries on a developer PC, which reduces your preparation time on the HIL simulator.
  • You can reuse the experiment software for instrumenting and controlling the HIL simulation when you run simulations on your PC.

A V-ECU is software that emulates a real ECU in a simulation. The V-ECU can contain components of 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 consists of real production code. 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 at the application level (contains selected parts of the application software, the operating system, the RTE and necessary parts of the basic software typically provided by dSPACE)
  • V-ECU including application software and parts of the production basic software, such as Dem, NvM, and COM
  • V-ECUs including the complete application software and hardware-independent production software, except modules for the Microcontroller Abstraction Layer (MCAL)

 

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 functional 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. They then 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 are used for PC-based simulation with VEOS.

 

V-ECUs Based on Non-AUTOSAR Code

If your ECU software is based on non-AUTOSAR code, SystemDesk also lets you generate V-ECUs. For this, you need the code of the functionalities to be included in the V-ECU and a list of tasks as well as functions to be called in these tasks. If variables have to be measured or calibrated, the corresponding A2L files have to be provided as well. SystemDesk generates a V-ECU with realistic behavior, e.g., realistic scheduling.

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 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.

ASAM

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.

AUTOSAR

AUTOSAR (AUTomotive Open System ARchitecture) is a de-facto open industry standard for automotive electric/electronic (E/E) architectures. 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, the Modelica Association FMI project to further develop the FMI standard, and the Modelica Association project for System Structure and Parameterization of Components for Virtual System Design (SSP).

    

Further Information Product Information