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

Was sind virtuelle Steuergeräte?

Veröffentlicht: 22.08.2018

Sven Flake, Product Engineer Virtual Validation, dSPACE GmbH

Das hochautomatisierte und autonome Fahren ist ein allgegenwärtiges Thema, für dessen Absicherung sich eine neue Bewertung etabliert hat: die Anzahl der gefahrenen Kilometer oder Meilen während der Testfahrten. Das geht los mit den von Google häufig zitierten 8 Millionen Meilen, die täglich allein in Simulationen gefahren werden (siehe Inside Waymo's Secret World for Training Self-Driving Cars) und endet vermutlich nicht mit den unter anderem von der RAND Corporation berechneten Zahlen. Um die Zahl der unfallbedingten Todesfälle um 20 Prozent zu senken, müssten wir laut einer Studie von 2016 für jedes Auto 5 Milliarden (!) Meilen in Tests zurücklegen (siehe Why It's Nearly Impossible to Prove Self-Driving Cars' Safety Without a New Approach).

Natürlich kann niemand diese Strecke mit Versuchsfahrzeugen bewältigen oder gar die schiere Anzahl von Testfahrten in Echtzeit simulieren. Dies wird an einem einfachen Beispiel deutlich. Angenommen Sie wollen eine Probefahrt im Stadtgebiet mit einer Höchstgeschwindigkeit von 50 km/h machen, und die Strecke, die Sie abfahren wollen, ist etwa einen halben Kilometer lang. Das ist etwa eine halbe Minute (36 s) „reines Fahren“; also müsste man länger als eine Woche rund um die Uhr simulieren, um eine Million Kilometer (200 Stunden oder 8 Tage und 8 Stunden) zurückzulegen. Dabei reden wir von reiner Simulationszeit ohne Zusatzaufwand wie Vorbereitung oder Ergebnisanalyse.

Sie könnten also einfach ein Dutzend voll ausgestattete Hardware-in-the-Loop (HIL)-Systeme kaufen und die Simulation am Wochenende ausführen, richtig? Leider ist es in der Realität nicht so einfach wie in dem mathematischen Beispiel. Hier kommt die Software-in-the-Loop (SIL)-Simulation ins Spiel. Diese verbessert die Code-Qualität so weit wie möglich, bevor Sie die kostbare Zeit des HIL-Systems in Anspruch nehmen. In der Software-in-the-Loop-Simulation haben sich in den letzten 18 Monaten zunehmend virtuelle Steuergeräte (V-ECUs) als Testgeräte bei SIL-Experten etabliert.

Meiner Erfahrung nach lösen V-ECUs viele Probleme, wenn man bei null mit einem Whiteboard als Entwicklungsumgebung anfängt. Die Frage ist: Was können sie eigentlich genau tun?

Genauer gesagt, möchte ich diese Frage in drei unterteilen und eine nach der anderen beantworten:

  1. Was ist ein virtuelles Steuergerät?
  2. Warum ist es nützlich?
  3. Wie bekomme ich eins?

Was ist ein virtuelles Steuergerät?

Die kurze Antwort lautet: Jede Software-Funktionalität, die ohne Hardware ausgeführt werden kann.

Das stimmt natürlich nicht ganz, wie jeder weiß, der an Model-in-the-Loop (MIL)-Tests beteiligt ist.

Es gibt eine Schlüsselqualität von V-ECUs, die sie von herkömmlichen MIL-Tests unterscheidet: Sie enthalten den unveränderten Seriencode, genau wie das finale Steuergerät. Es gibt mehrere Möglichkeiten, Ihren Seriencode in einer SIL-Simulationsumgebung auszuführen. V-ECUs sind jedoch so realitätsnah wie möglich, ohne die Ziele der einfachen Prozessintegration und der schnellen und deterministischen Simulation zu gefährden. Und mit schnell meine ich schneller als in Echtzeit.

Die wichtigsten Bestandteile virtueller Steuergeräte:

  • Ein realistisches Planungsverhalten basierend auf den für die Funktionalitäten definierten Zeit- und Trigger-Informationen. Dazu gehört die Simulation eines Betriebssystems, das sowohl in der Lage ist, den Code in verschiedenen Zyklen und mit unterschiedlichen Prioritäten zu triggern als auch genau das erwartete Verhalten zu zeigen: Priorisierung, Unterbrechung, egal was.
  • Die Integration von mehr als nur Ihrer Software-Funktionalität in eine Software-Architektur. Zu diesem Zeitpunkt sind Sie bereits in der Lage, die Schnittstellenkompatibilität zu prüfen, fehlende oder abweichende Daten bei der Software-Funktionalität Ihres Kollegen zu finden und bei Bedarf die AUTOSAR-Konformität sicherzustellen.
  • Schließlich werden Steuergeräte auf Busebene verbunden, und es gibt keinen Grund, warum V-ECUs nicht an einen simulierten Bus angeschlossen werden sollten. Und wenn Sie sich nicht nur zum Testen mit einem COM-Stack beschäftigen wollen, sollte es möglich sein, den realen Stack zu generieren oder zu ersetzen.

Für Entwickler, die die AUTOSAR Classic Plattform nutzen: Eine V-ECU enthält mindestens die Anwendungsschicht und stellt die AUTOSAR Runtime Environment (RTE) sowie ein Betriebssystem (OS) selbst zur Verfügung. Alles andere wie Basissoftware-Module (BSWs) ist optional, aber es muss möglich sein, die BSWs zu Simulationszwecken zu integrieren oder sogar zu generieren.

Warum ist ein virtuelles Steuergerät sinnvoll?

Wenn mir jemand diese Frage stellt, lautet meine Gegenfrage: „Woran arbeitest du?“ Der Nutzen hängt immer von Ihren Aufgaben ab.

Das Gute an V-ECUs ist, dass es mehr als einen Weg gibt, davon zu profitieren.

Vergleicht man virtuelle Steuergeräte mit Hardware-Steuergeräten, sind virtuelle Integrationstests ein Testaufbau, der massiv von V-ECUs profitiert. Der Grund ist offensichtlich. In den meisten Fällen wird der Integrationstest durch einen Ausfall der Steuergeräte-Kommunikation blockiert, entweder wegen einfacher Schnittstellenprobleme oder weil die Buskommunikation nicht in allen beteiligten Steuergeräten auf dem neuesten Stand ist.

Mit V-ECUs lassen sich genau diese Probleme frühzeitig erkennen. Durch den Einsatz eines SIL-basierten Integrationsaufbaus sowie V-ECUs und eines simulierten Busses anstelle von echter Hardware kann die Gesamtintegration ohne Einsatz von HIL-Ressourcen auf eine funktionierende Entwicklungsversion gebracht werden. Auf diese Weise kann sich der HIL-basierte Integrationstest auf Fehler konzentrieren, die schwerer zu finden sind, anstatt sich immer wieder mit derselben Art von Problemen zu beschäftigen.

Betrachten Sie V-ECUs auch aus der Sicht eines Funktionsentwicklers. V-ECUs können wachsen: Nehmen Sie den gerade programmierten Code, generieren Sie automatisch eine einfache Laufzeitumgebung und ein Betriebssystem und integrieren Sie diese V-ECU in eine kleine SIL-Umgebung. Verbinden Sie es mit Streckenmodellen, die in der HIL-Umgebung verwendet werden, erstellen Sie eine Integration mit anderen einfach V-ECUs oder generieren Sie sogar einen COM-Stack, um die V-ECU direkt mit einem simulierten Bus zu verbinden.

Jetzt höre ich Sie immer noch die Frage stellen: „Warum sollte ich ein zusätzliches Test-Artefakt verwenden? Ich nutze seit Jahren Unit-Tests oder Back-to-Back-Tests."

Stimmt. Aber sind Sie in der Lage, das zu testende Gerät einfach mit anderen V-ECUs zu integrieren? Wahrscheinlich nicht.

Ein Simulator für V-ECUs, zum Beispiel dSPACE VEOS, integriert nicht nur V-ECUs, sondern auch Anlagen- und Umgebungsmodelle wie Motormodelle, Fahrdynamikmodelle oder vollwertige Fahrszenarien. Das sind übrigens dieselben Modelle, die Sie auch auf einem SCALEXIO-System einsetzen würden. Zusätzlich können Sie mit dem PC-basierten Simulator dieselben Werkzeuge – und damit dieselben Tests – wie auf einem HIL-Prüfstand verwenden.

Aber da ich selbst Informatiker bin, schätze ich vor allem zwei Eigenschaften:

  • Am Ende teste ich den Quellcode: Ich kann die V-ECUs und den gesamten Simulationsaufbau jederzeit stoppen und debuggen. Ich füge einfach den Debugger meiner Wahl hinzu, füge einen Breakpoint ein und lege los. Ich benutze automatisierte Tests und Code-Abdeckungsanalysen, aber sind wir ehrlich: Am Ende ist ein Debugger das wertvollste Werkzeug, wenn man einem Problem auf den Grund gehen will.
  • V-ECUs und SIL-Simulationen sind nur Software. Zunächst wird die Zeit simuliert (und damit eine Illusion, zumindest für eine V-ECU), und die simulierte Zeit verläuft typischerweise viel schneller als in Echtzeit, und Sie können sie sogar beeinflussen. Verwenden Sie einfach normale leistungsstarke Hardware anstelle des fünf Jahre alten Laptops, der in der untersten Schublade Ihres Schreibtisches ruht. Der reine Software-Ansatz eignet sich hervorragend für automatisierte Tests, und wenn der von der Qualitätssicherung geforderte Testdurchsatz steigt, können Sie einfach Kopien des gesamten Simulationsaufbaus verwenden oder ihn vollständig auf Cloud-Systeme übertragen. Wie gesagt, es ist nur Software, richtig?

Wie bekomme ich ein virtuelles Steuergerät?

Bleibt noch die letzte Frage: Wie erstelle ich eine V-ECU? Während ich diesen Blog-Beitrag schreibe, sind V-ECUs (noch) nicht standardisiert, daher hängt ihre Erstellung von Ihrer SIL-Werkzeugkette ab.

Wir bei dSPACE empfehlen immer eine modulare Werkzeugkette, daher setzen wir bei V-ECUs nach Möglichkeit auf Standards. Werfen wir einen Blick auf den Inhalt einer V-ECU. Es gibt bereits eine Lösung, die automotive Software modular und austauschbar macht: Der AUTOSAR- Standard.

Wenn ich Software nach AUTOSAR entwickle (und mit einer ARXML-Datei spezifiziere), kann ich sie direkt in ein AUTOSAR-Authoring-Tool importieren. In unserem Fall ist das dSPACE SystemDesk. Aber auch wenn ich nicht mit AUTOSAR arbeite, spezifiziere ich Schnittstellen für die Software, sei es in Excel-Tabellen oder in XML-Dateien, die von anderen Tools bereitgestellt werden. Ich verwende dann SystemDesk, um einen AUTOSAR-Wrapper zu erstellen, indem ich das Excel-Tabellenblatt als Spezifikation für die entsprechende AUTOSAR-Beschreibung verwende. Und wenn ich sage, dass ich SystemDesk verwende, dann meine ich, dass mein Python-Skript die Excel-Tabelle verarbeitet und SystemDesk automatisiert.

Das bedeutet, dass unabhängig davon, ob ich AUTOSAR zur Entwicklung von Software einsetze oder nicht, ich am Ende eine automatisch generierte AUTOSAR-Software-Architektur in SystemDesk habe, die ich entweder durch den Import einer ARXML-Datei oder durch das Scripting meiner eigenen Excel-Tabelle erhalten habe.

Und wenn mir meine Kollegen eine brandneue V-ECU auf Basis der AUTOSAR Adaptive Platform übergeben, die die neuesten Funktionen für autonomes Fahren enthält, verwende ich SystemDesk, um sie sauber in ein VEOS-konformes Dateiformat zu packen.

Ich habe den Begriff „Scripting“ verwendet, denn was immer ich tue, um wiederverwendbare Artefakte zu erzeugen, ich möchte es automatisieren. Nur so können die Artefakte immer wieder neu generiert werden, wenn ich den Quellcode aktualisiere. Denn – genau! Kontinuierliche Integration und Lieferung.

Unabhängig von der Ausgangsform des Quellcodes und der Beschreibung ist das Ergebnis eine V-ECU-Implementierung. Es kann zur Simulation direkt in dSPACE VEOS importiert oder mit anderen V-ECUs und Umgebungsmodellen verbunden werden.

Zusammenfassung

V-ECUs sind nicht so geheimnisvoll, wie man denkt: Am Ende läuft es darauf hinaus, den Code, AUTOSAR oder nicht, mit einer automatisch generierten Laufzeitumgebung und einem Betriebssystem anzureichern, um ihn in einer Software-in-the-Loop-Umgebung zu verwenden. Dort geht es dann schnell – es sei denn, es kommt ein Breakpoint für das Debugging. Die Simulation selbst hängt nicht von der Hardware ab, so dass Sie sie nach einmaliger Einrichtung entweder durch Kopieren oder durch Verschieben auf Cloud-Systeme skalieren können.

Und virtuelle Steuergeräte sind flexibel. Ich folge gerne dem Grundsatz von John Gall und fange immer mit einem kleinen an, das nur wenig von dem Code enthält, den ich schreibe. Von dort aus richte ich meine Testumgebung ein. Danach lasse ich die V-ECU wachsen, fügte mehr Funktionalität hinzu und übergebe sie an meine Kollegen. Gerne ersetzen sie die Restbussysteme oder Funktionsmodelle in ihren SIL-Integrationsaufbauten durch den echten Seriencode meiner V-ECU.

Letztlich ist es der Seriencode, der mit virtuellen Steuergeräten getestet wird. Um die Qualität zu erhöhen und die Millionen von Kilometern der Testfahrten allein durch Simulation zu bewältigen.

Weiterführende Informationen Produktinformationen