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

Was steckt hinter der Technologie der virtuellen Absicherung:

  • Durchführen PC-basierter Simulationen zum Validieren, Absichern und Testen von Steuergeräte-Software in Form von V-ECUs ohne zusätzliche Hardware
  • Keine zusätzliche Hardware notwendig
  • Vorbereiten und Vorverlagern von Hardware-in-the-Loop (HIL)-Tests und -Szenarien am PC
  • Einsatz von V-ECUs in der Funktionsentwicklung: Absichern neuer Regelalgorithmen im Kontext bestehender Steuergeräte-Software

Mit der virtuellen Absicherung können Sie Ihre Entwicklungs-, Verifizierungs- und Validierungsaufgaben deutlich früher durchführen und zudem die Anzahl zusätzlicher Testsysteme und Steuergeräte-Prototypen reduzieren. Damit reagiert dSPACE auf den Bedarf an frühzeitiger Simulation, der sowohl in der Automobil- als auch in der Luft- und Raumfahrtindustrie besteht.

dSPACE Werkzeuge decken alle Anforderungen an die virtuelle Absicherung ab: SystemDesk® zur Generierung virtueller Steuergeräte (V-ECUs) aus Steuergeräte-Software-Architekturen, VEOS® für die PC-basierte Simulation sowie Software für Experimente, Visualisierung und Testautomatisierung.

 

Vorteile

  • Anstatt auf kostspieligen Prüfständen können Sie neue Funktionen in einer komplett virtuellen Umgebung entwickeln und testen.
  • Sie können ein komplettes Steuergerät auf einem PC simulieren, bevor ein Prototyp verfügbar ist.
  • Sie können Simulationsmodelle und Testbibliotheken auf einem Entwickler-PC vorbereiten, um die Vorbereitungszeit auf dem HIL-Simulator zu reduzieren.
  • Sie können die Experimentier-Software zum Instrumentieren und Steuern der HIL-Simulation bei der Simulation auf Ihrem PC wiederverwenden.

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 lässt sich leicht in Ihre bestehende Werkzeugkette integrieren, da es automotive Standards unterstützt. Sie können also weiterhin mit den Ihnen vertrauten Werkzeugen arbeiten, wenn Sie VEOS in Ihre Werkzeugkette für Rapid Control Prototyping oder HIL integrieren, um PC-basiert zu simulieren. Wenn Sie sich für Software und Hardware von dSPACE entscheiden, gewinnen Sie ein hohes Maß an Flexibilität und Investitionssicherheit für neue Projekte und Herausforderungen.

ASAM

Im Juli 2009 veröffentlichte ASAM (Association for Standardisation of Automation and Measuring Systems) den neuen XIL-API-Standard und definierte damit eine Schnittstelle für den Anschluss eines Testautomatisierungswerkzeugs wie AutomationDesk an jede beliebige Simulationsplattform, zum Beispiel VEOS oder SCALEXIO. Der Standard ermöglicht die plattformunabhängige Spezifikation von Tests.

AUTOSAR

AUTOSAR (AUTomotive Open System ARchitecture) ist ein offener De-facto-Industriestandard für automotive Elektrik/Elektronik (E/E)-Architekturen. dSPACE ist seit April 2004 Premium Member der AUTOSAR-Partnerschaft und beteiligt sich aktiv an Definition und Entwicklung von Architekturteilen und ihren Spezifikationen.

Functional Mock-up Interface (FMI)

Functional Mock-up Interface (FMI) ist ein offener Standard für den Austausch und die Integration von Streckenmodellen unterschiedlicher Werkzeuganbieter. dSPACE hat den Codex of PLM Openness unterschrieben und arbeitet aktiv an folgenden Projekten mit, um den FMI-Standard weiterzuentwickeln: ProSTEP Smart Systems Engineering, dem FMI-Projekt der Modelica Association, sowie System Structure and Parameterization of Components for Virtual System Design (SSP), ebenfalls von der Modelica Association.

    

Weiterführende Informationen Produktinformationen