dspace-virtualisierung-bild-3-lr-folgt-als-tif-ins-censhare.jpg

Für die erfolgreiche Implementierung von Fahrzeugfunktionen in elektronischen Steuergeräten steht eine Vielzahl von Methoden zum Entwurf und zur Absicherung zur Verfügung, welche in den zurückliegenden Jahren eingeführt worden sind. Dazu gehören insbesondere der modellbasierte Entwurf und die modellbasierte Verifikation einzelner Fahrzeugfunktionen. Durch den Autosar-Standard und die darin beschriebene Software-Architektur ergeben sich darüber hinaus zusätzliche Möglichkeiten, eine frühe Verifikation nicht nur für einzelne Komponenten durchzuführen, sondern die gesamte Anwendungssoftware multipler Steuergeräte im Zusammenspiel mit der Basissoftware früh zu validieren. Mithilfe der Virtualisierung lassen sich bereits ohne reale Steuergeräte-Hardware detailgetreue und umfangreiche Tests durchführen.

Praxiserprobt: Modellbasierte Entwicklung

Virtualisierte ECU(s) und Autosar

Virtualisierte ECU(s) und AutosardSPACE

Die Entwicklung einzelner Autosar-Software-Komponenten (SWC) durch die etablierten Techniken des modellbasierten Entwurfs kommt seit einigen Jahren erfolgreich zum Einsatz. De facto passen autosar-konforme Entwicklung und modellbasiertes Design sehr gut zusammen, weil Modelle sich als Single-Source nicht nur zur Generierung des eigentlichen Komponenten-Codes nutzen lassen sondern auch zur Erzeugung sonstiger Artefakte, wie zum Beispiel der benötigten Autosar-Austauschformate.

Bild 1: Austausch von Spezifikationen zwischen Architektur- und Verhaltensmodellierung und Integration der Autosar-Software in eine virtuelle ECU.

Bild 1: Austausch von Spezifikationen zwischen Architektur- und Verhaltensmodellierung und Integration der Autosar-Software in eine virtuelle ECU.dSPACE

In der Praxis setzten die Verantwortlichen meist auf einen architekturgetriebenen Top-Down-Ansatz zur Komponentenentwicklung. Hierbei erfolgt die Festlegung der Schnittstellen einer Komponente vorab in einem Autosar-Architekturwerkzeug wie SystemDesk von dSPACE, wobei der Komponentenentwickler dann gegen diese Schnittstellen implementieren muss (Bild 1 oben). Der Ansatz ist auch deshalb so attraktiv, weil die Schnittstellen-Spezifikationen unmittelbar zur Generierung eines Autosar-Rahmenmodells nutzbar sind, das die erforderlichen Ports bereits enthält. Somit ist automatisch sichergestellt, dass der Komponentenmodellierer gegen die vordefinierten Schnittstellen implementiert und dass sich die Komponenten später einfach integrieren lassen. Die gewünschte algorithmische Funktionalität kann dann einfach in das Autosar-Rahmenmodell eingefügt werden. Als Folge entsteht in kurzer Zeit ein erstes Design der Autosar-Software-Komponente, für das unmittelbar autosar-konformer Code generiert werden kann. Durch den beschriebenen Ansatz muss der Komponentenentwickler kein wirklicher Autosar-Experte sein; er kann sich vielmehr (ganz) auf seine jeweilige Fachdomäne konzentrieren.

Bild 2:  Modellbasiertes Design für Autosar-Software-Komponenten mit TargetLink.

Bild 2: Modellbasiertes Design für Autosar-Software-Komponenten mit TargetLink.dSPACE

Bild 2 zeigt, wie sich ein mögliches modellbasiertes Design einer Autosar-Software-Komponente in Simulink/TargetLink darstellt. In dem Seriencode-Generator TargetLink von dSPACE ist die Autosar-Unterstützung nativ verankert, was sich zum Beispiel in expliziten Autosar-Optimierungen für hocheffizienten Autosar-Code bemerkbar macht. Spezielle Autosar-Blockdialoge dienen zur Visualisierung und Editierung von Autosar-Spezifikationen, die zwecks besseren Austausches mit Autosar-Autorenwerkzeugen in einem Data-Dictionary abgelegt sind. Dieser Ansatz unterstützt Autosar-Engineering-Round-Trips sowie den Umgang mit Änderungen besonders gut, da unterschiedliche Datenstände verglichen, zusammengeführt und mit einem bestimmten Autosar-Modell synchronisiert werden können.

Modellbasierte Tests für einzelne SWCs

Seit vielen Jahren dienen modellbasierte Komponententests erfolgreich zur Verifikation automotiver Seriensoftware. Grundlegend hierfür sind die Konzepte der MIL- (Model-in-the-Loop), SIL- (Software-in-the-Loop) und PIL-Simulation (Processor-in-the-Loop), bei denen Tests direkt in der Simulink/TargetLink-Umgebung erfolgen. Die Testfälle können hierbei sowohl auf dem eigentlichen Blockschaltbild (MIL) als auch auf dem Host-PC (SIL) oder einem Evaluation-Board mit dem Target-Prozessor (PIL) ausgeführt und in sogenannten Back-to-Back-Tests auf Unterschiede überprüft werden.

Virtuelle Entwicklung

Modellbasierte Komponententests haben sich bewährt bei der Verifikation automotiver Seriensoftware per MIL- (Model-in-the-Loop), SIL- (Software-in-the-Loop) und PIL-Simulation (Processor-in-the-Loop). Wenn zu Beginn von Neuentwicklungen noch keine Hardware-Prototypen verfügbar sind, kommt analog zur Komponenten-Simulation im Rahmen einer Virtualisierung eine virtuelle ECU (V-ECU) – beispielsweise auf Basis der Simulationsplattform VEOS zur PC-basierten Offline-Simulation – zum Einsatz.

Die bestehenden Konzepte und Methoden lassen sich praktisch vollständig auf den Test einzelner Autosar-Software-Komponenten übertragen. Zu berücksichtigen ist lediglich, dass zur Verifikation des Komponenten-Codes einzelne Dateien der RTE (Runtime Environment) erforderlich sind, um den Build-Prozess für SIL/PIL-Tests zu ermöglichen. TargetLink unterstützt hierzu die Generierung einer Stub- beziehungsweise Simulations-RTE, wofür Kernfunktionalitäten von SystemDesk zum Einsatz kommen. Die hierbei für die Komponente erzeugten Object-Dateien werden dann in SIL- und PIL-Tests ausgeführt. TargetLink unterstützt auch die Generierung von Object-Dateien im sogenannten Autosar-Compatibility-Mode, wodurch Software-Komponenten nicht nur als Source-Code- sondern auch als Object-Code-Dateien weitergegeben werden können, was insbesondere aus IP-Schutz-Gründen relevant ist. Auch die Ermittlung von Abdeckungsmaßen für den generierten Code (Code Coverage), wie sie nach ISO 26262 für sicherheitskritische Komponenten vorgeschrieben ist, lässt sich im Rahmen der SIL/PIL-Simulation durchführen. Hierbei empfiehlt es sich, TargetLink in Verbindung mit speziellen Testwerkzeugen wie dem BTC Embedded-Tester, einzusetzen, um Testfälle effizient erstellen und die entsprechenden Abdeckungsmetriken ermitteln zu können. Insgesamt lassen sich damit alle Testaktivitäten für eine einzelne isolierte Autosar-Software-Komponente vollständig in der Simulink/TargetLink-Umgebung virtualisiert durchführen, ohne dass ein reales Exemplar eines Steuergerätes vorhanden ist.

Virtuelle ECUs zur frühestmöglichen Verifikation von Software

Der Autosar-Standard liefert mit seinen wohldefinierten Software-Schnittstellen und der standardisierten Architektur die Basis für frühe virtuelle Absicherungsmaßnahmen der Software, die einen hohen Grad an Realitätstreue aufweisen können. Dies ist insbesondere deshalb vorteilhaft, weil gerade bei neuen Entwicklungen Hardware-Prototypen oftmals zu Beginn nicht verfügbar sind. Die Validierung und der Test der Software erfolgen dann durch Ausführung sogenannter virtueller ECUs (V-ECUs) mit hohem Detailierungsgrad ohne die reale Hardware.

Unter einem virtuellen Steuergerät versteht man im Allgemeinen Software, die in einem Simulationsszenario (Echtzeit oder Simulationszeit) ein reales Steuergerät emuliert, wobei sich der Detailreichtum der Emulation im Einzelnen unterschiedlich darstellen kann. Ein Vorteil dieser Vorgehensweise besteht nicht nur in der frühen Validierung, sondern auch darin, dass bei späterer Verfügbarkeit der realen Steuergeräte-Hardware die Möglichkeit besteht, viele zuvor entwickelte Artefakte wie Testprozeduren unmittelbar wiederzuverwenden.

Eine virtuelle Autosar-ECU enthält insbesondere die folgenden Software-Anteile (Bild 1 unten):

  • Die eigentliche Applikationssoftware in Form von Autosar-Komponenten, entweder in ihrer Gesamtheit oder einer selektierten Teilmenge daraus.
  • Eine für das virtuelle Steuergerät erzeugte RTE, um die Kommunikation zwischen Anwendungskomponenten und Basissoftware zu realisieren und Betriebssystem-Tasks zu instanziieren.
  • Hardware-unabhängige Basissoftware-Komponenten, etwa ein Autosar-Betriebssystem sowie einzelne Autosar-Services, beispielsweise für das NVRAM-Management.

Insgesamt folgt die virtuelle Autosar-ECU damit dem Schichtenmodell der Autosar-Software-Architektur, um die Software auf dem realen Steuergerät möglichst realitätsnah emulieren zu können.

Erzeugung virtueller Autosar-Steuergeräte

Die Generierung virtueller Steuergeräte in der Autosar-Werkzeugkette von dSPACE erfolgt mithilfe des Architektur- und Integrationswerkzeugs SystemDesk (Bild 1 unten). Hierzu spezifiziert der Anwender eine ECU inklusive der darauf befindlichen Anwendungskomponenten, konfiguriert RTE sowie Betriebssystem und lässt sich anschließend durch SystemDesk eine virtuelle Autosar-ECU erzeugen. Für eine einfache VFB-Simulation (VFB: Virtual Functional Bus) besteht die Möglichkeit, die Konfiguration von RTE und ECU im Wesentlichen durch einen von SystemDesk geleiteten Ablauf auf Knopfdruck zu erstellen. Dies liegt daran, dass bei der VFB-Simulation die Interaktion von Software-Komponenten der Applikationsebene im Vordergrund steht, wobei völlig von der konkreten ECU und Netzwerkkonfiguration abstrahiert wird. Die benötigten Anteile der zu emulierenden Basissoftware für Autosar-Services fügt das System beim Bauen der virtuellen ECU automatisch hinzu. Soll hingegen eine Simulation konkreter ECU- und Bussysteme erfolgen, dann kann ein Anwender die entsprechenden Konfigurationen vornehmen und dafür durch SystemDesk eine virtuelle ECU erstellen lassen.

Bild 3: Ausführen von virtuellen ECUs in VEOS unter Nutzung von ControlDesk.

Bild 3: Ausführen von virtuellen ECUs in VEOS unter Nutzung von ControlDesk.dSPACE

Als Voraussetzung zur Generierung virtueller ECUs müssen die zu integrierenden Autosar-SWCs vorliegen. In SystemDesk als Autorenwerkzeug können solche Komponenten erstellt oder auf der Grundlage des Autosar-Austauschformats importiert werden. Dies gestattet es, Software-Komponenten vieler unterschiedlicher Bauarten zu integrieren, seien es handgeschriebene, mit Drittanbieterwerkzeugen erstellte oder modellbasiert mit TargetLink entwickelte. Letzteres ist besonders komfortabel, weil TargetLink die für den Austausch erforderlichen Autosar-Dateien neben dem Komponenten-Code automatisch mitgeneriert und diese auch in Form eines SWC-Containers für vereinfachte transparente Workflows zusammenfassen kann. Prinzipiell können Funktions- und Software-Entwickler, die nur für Einzelkomponenten zuständig sind, V-ECUs auch direkt mit Simulink oder TargetLink erstellen. Das Ergebnis ist eine einfache V-ECU, die entweder für Streckenmodelle zur Anwendung kommt oder nur aus einzelnen Komponenten der Anwendungsschicht besteht. Für das komplexe vernetzte Zusammenspiel einer Vielzahl von Komponenten einer virtuellen Autosar-ECU sollte diese jedoch aus SystemDesk erzeugt werden.

Ausführung von virtuellen ECUs

Neue, innovative Fahrzeugfunktionen verteilen sich oftmals über mehrere, unterschiedliche Steuergeräte und müssen mit zahlreichen Simulationsläufen abgesichert werden, bevor sie in einem Fahrzeug realisiert werden können. Daher ist eine leistungsfähige Simulationsumgebung erforderlich, die ein oder mehrere virtuelle Steuergeräte einschließlich der Datenübertragung zwischen diesen ECUs berücksichtigen kann. Die Simulationsumgebung muss die Hardware-abhängigen Anteile des Steuergerätes nachbilden und eine eigene Build-Funktionalität besitzen, um das virtuelle Steuergerät für die jeweilige Plattform ausführbar zu machen.

Zur PC-basierten Offline-Simulation bietet dSPACE die Simulationsplattform VEOS, die bereits in frühen Entwicklungsphasen, wenn noch kein Hardware-Prototyp des Steuergerätes verfügbar ist, eine Simulation einzelner oder vernetzter virtueller Steuergeräte erlaubt. VEOS vereinfacht insbesondere auch dynamische Untersuchungen unter Verwendung von Standard-Werkzeugen von dSPACE wie ControlDesk Next Generation zur Steuerung der Simulation, Aufzeichnung und Visualisierung von Signalen sowie der Parametrierung von einzelnen Kalibriergrößen (Bild 3).

Die Steuergeräte-Software lässt sich in Open-Loop-Simulationen stimulieren oder in Closed-Loop-Simulationen in Verbindung mit Streckenmodellen testen, wobei die Verantwortlichen nicht nur einzelne virtuelle Steuergeräte sondern einen kompletten Verbund berücksichtigen können. Das Konzept der virtuellen Steuergeräte bietet auch für die HIL-Simulation zusätzliche Vereinfachungen und Möglichkeiten. So lassen sich Layouts, Testprozeduren und sonstige Artefakte aus der Offline-Simulation mit VEOS in späteren Hardware-in-the-Loop-Simulationen wiederverwenden. Des Weiteren existiert die Möglichkeit, virtuelle Steuergeräte allein oder im Verbund mit realen Steuergeräten in der HIL-Simulation mit Scalexio von dSPACE auszuführen.

Auf die beschriebene Weise finden die neuen Technologien der virtuellen Absicherung durch V-ECUs Einzug in bestehende Verifikations- und Testprozesse für Steuergeräte-Software. dSPACE wird diese Integration weiter vorantreiben – und zwar mit dem Schwerpunkt auf der Wiederverwendbarkeit bestehender Hardware, Software und Modelle.

Dr. Ulrich Eisemann

ist Senior Product Manager für den Seriencode-Generator TargetLink bei dSPACE.

Joachim Stroop

ist Lead Product Manager für den Bereich System Architecture bei dSPACE.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

dSPACE GmbH

Rathenaustraße 26
33102 Paderborn
Germany