Continental_Virtualization-w-DigitalTwins_v003.00_02_40_06.Still025.jpg

Die hohe Kunst des Entwickelns

Testen und optimieren ganz ohne Ziel-Hardware

Wie testet man elektronische Systeme und Software für ein Auto, das es noch gar nicht gibt? Wie bekommt man ein System marktreif, ohne erst einmal Millionen Testkilometer zu fahren? Continental macht es möglich - mit Virtualisierung.

Software braucht scharfsinnige Lösungen

Im Volksmund nennt man so etwas „Henne-Ei-Problem“. Es geht dabei um die Frage, was von beiden zuerst da war und womit man beginnen muss, bei der Henne oder beim Ei, um zum Ziel zu gelangen. Wie kommt man beispielsweise zur Henne, ohne ein Ei zu haben? Obwohl man es nicht vermuten mag, kennt auch die Autotechnik dieses Problem. Wir sind es heute gewohnt, dass uns unsere Fahrzeuge einen stetig wachsenden Komfort bieten, exzellente Fahrerunterstützung in alltäglichen sowie kritischen Situationen. Und alles muss absolut zuverlässig sein. Der Schlüssel dazu liegt in der Sensorik und vor allem in der Software. Deshalb läuft in einem modernen Fahrzeug mehr Software als in jedem anderen mobilen System. Und ein Ende beim Wachstum der Codezeilen ist nicht absehbar.  

Inzwischen hat die Software im Auto eine Bedeutung erlangt, die dazu führt, dass man die Fahrzeugelektronik (die Hardware) nach den Bedürfnissen der Software ausrichtet. Die Software bestimmt heute, wo es lang geht. Dazu wird die elektrische und elektronische Architektur der Fahrzeuge komplett umgekrempelt – die Rede ist nun vom Software-defined Vehicle (SDV). Der wichtigste Schritt dabei ist, die Software von der Hardware unabhängig zu machen. Diese Entkoppelung – Fachleute sprechen von Separation – ermöglicht es, Software nur einmal zu entwickeln und dann auf unterschiedlicher Hardware laufen zu lassen – sie also wiederzuverwenden. Außerdem erlaubt die Trennung es, die unterschiedlichen Entwicklungszyklen bei Software und Hardware einzuhalten. So erfolgt die Aktualisierung von Software in der Regel deutlich schneller als die der Hardware.  

Um die Masse an Software zu hosten (sie muss ja schließlich irgendwo „laufen“) werden Hochleistungsrechner im Auto benötigt. So entsteht gerade die neue Geräteklasse der High-Performance Computer (HPC). Sie bilden das Zuhause für die immense Menge an Software im Auto. Der „kleine Haken“ bei dieser Sache: Die schiere Menge an Software und der Vernetzungsgrad der Systeme untereinander plus die Vielzahl der Beteiligten an Softwareprojekten macht die Programmierung derart komplex, dass Softwareentwicklung fürs Auto zu den anspruchsvollsten Aufgaben gehört, die es für Ingenieure zu meistern gilt. Automobile Softwareentwicklung funktioniert nur mit bis ins letzte Detail ausgefeilten und abgesicherten Hilfswerkzeugen, Prozessen, automatisierten Routinen sowie testen, testen und nochmals testen. Denn im „Endprodukt“ Auto muss die Software ohne Wenn und Aber sicher funktionieren.

Womit wir wieder bei unserem Henne-Ei-Problem wären: De facto ist es heute so, dass Hardware-Muster begrenzt verfügbar sind. Außerdem stehen diese Muster erst spät im Entwicklungsprozess zur Verfügung, während gleichzeitig die Entwicklungszyklen kürzer und schneller werden. Für die Entwicklung bleibt damit weniger Zeit und für das Testen neuer Software erst recht. Was also tun?

Das HPC als „Super-Hirn“

Für einen Automobilsystemzulieferer mit einer enormen Qualitätsverantwortung wie Continental Automotive sie trägt, ist diese Zwickmühle natürlich nicht neu. Sie ist Alltag. Die hohe Verantwortung, die das Unternehmen für seine Kundenprojekte trägt, sowie die Herausforderung, das ständig steigende Maß an Software- und Systemkomplexität zu beherrschen, lässt sich mit manuellen Prozessen nicht stemmen. Hier sind andere Lösungen gefordert, und Continental hat sie geschaffen. Ihre tiefsten Wurzeln hat diese Innovation in der Pionierleistung, als erster Tier 1 einen der neuartigen Hochleistungsrechner (HPC) samt Software für ein Fahrzeug erfolgreich in Serie gebracht zu haben.  

Wie man so etwas möglich macht? Testen, testen und nochmals testen… je früher, desto besser. Und schon wieder sind wir bei Henne und Ei, denn wie teste ich eine Software auf einer Hardware, die ich noch gar nicht habe? Stark verkürzt, lautet die Antwortet: Indem ich so tue, als hätte ich zum Beispiel den HPC für das spätere Fahrzeug schon. Statt zu warten, bis ein Hardware-Muster des HPC verfügbar ist und ihn dann mit Software zu bespielen, um diese zu testen, simuliere ich den kompletten HPC in der Cloud und lasse meine neu entwickelte Software auf diesem virtuellen Gerät probeweise laufen. Möglich wird das durch eine Lösung mit dem Namen virtual ECU Creator (kurz: vECU Creator), die Continental gemeinsam mit Amazon Web Services (AWS) entwickelt hat. Das Steuergerät (das kann zum Beispiel ein High-Performance Computer sein, ein HPC), welches ich damit simuliere, heißt folgerichtig virtual ECU, oder nur vECU. Mit dem vECU Creator lässt sich also ein sogenannter digitaler Zwilling noch nicht verfügbarer ECU-Hardware simulieren. Man kommt quasi zur Henne, bevor das Ei dafür überhaupt gelegt ist…

Millionen Testkilometer, ohne den Raum zu verlassen

Ein Softwareentwickler kann mit dem vECU Creator einen digitalen Zwilling eines HPC erzeugen, solange dieser HPC selbst noch in der Entwicklung ist. Dabei ist HPC nicht gleich HPC. Je nach Einsatzgebiet und Fahrzeugdomäne, für die das Gerät gedacht ist (zum Beispiel Cockpit), unterscheiden sich HPCs untereinander in Teilen, auch wenn der grundsätzliche Aufbau gleichbleibt. Mit einem solchen Digital Twin des physischen HPC nimmt der Entwickler eine Abkürzung: Statt zu warten, bis Hardware-Muster verfügbar sind, beginnt die Testphase der Software bereits, während der HPC noch entwickelt wird. Das Ganze sieht kompliziert aus – und ist es auch. Darin steckt ganz viel Erfahrung mit Software- und Hardwareprojekten, speziell im Bereich HPC.  

Figure 1: Digital twin of a physical high-performance computer (HPC)

Digitaler Zwilling eines physischen High-Performance  Computer (HPC)  

Mit der vECU lassen sich ca. 80 % der Softwareentwicklungsarbeit einschließlich Testen auf dem in der Cloud simulierten HPC abarbeiten. Nur noch rund 20 % erfordern dann tatsächlich Tests auf der realen Hardware. Diese 80 % bedeuten einen immensen Zeitvorteil, denn sie machen die Entwicklung unabhängig von Prototypen. Die Welle an Integrations- und Testarbeit, die sich normalerweise „auftürmt“, bis endlich Hardware zur Verfügung steht, flacht auf diese Weise deutlich ab und die Programmierung gelingt schneller und besser. Oder ganz konkret: Ich kann meine neue Software bei Bedarf pro Tag eine Million Kilometer über virtuelle Teststrecken schicken, ohne dass sie den Raum dazu verlässt. Ohne dass Kraftstoff verbrannt, CO2 ausgestoßen oder Reifen abgerieben werden.

Entwickler können ihre virtuelle ECU aus einer ganzen Bandbreite an bereits fix und fertig virtualisierter Hardware auswählen. Das können typische Steuergeräte auf Mikrocontroller-Grundlage ebenso sein wie HPCs oder sogenannte Zone Controller. Nach der Auswahl des gewünschten Chip-Sets und der Middleware, wird die vECU in der Entwicklungsumgebung des Programmierers erzeugt und er oder sie kann direkt mit dem Code-Testen beginnen. Jede ECU auf der Basis der verbreiteten Betriebssysteme AUTOSAR Classic, AUTOSAR Adaptive, QNX, Linux und Android kann mit dem vECU Creator zu Testzwecken nachgebildet werden. Diese unterschiedlichen Betriebssysteme laufen voneinander unabhängig in sogenannten Partitionen, ohne sich gegenseitig zu stören. Auch die Anschlüsse für die jeweilige Peripherie (etwa ein Display, ein CAN-Bus, oder ein Audio-Ein/Ausgang) werden simuliert. Die einzelnen Partitionen verarbeiten Daten in derselben Geschwindigkeit wie die echte Hardware und kommunizieren in Echtzeit untereinander sowie mit ihrer Peripherie – und all das in der Cloud ohne Limitierung durch fehlende Hardware!

Neudeutsch heißt dieses ganze Vorgehen „Shift Left“. Gemeint ist damit, dass man durch paralleles Entwickeln von Hardware und Software den Beginn der Testphase zeitlich vorzieht – also auf dem typischen Zeitstrahl eines Entwicklungsprojektes nach links verschiebt. Dieser „Shift Left“ mit kontinuierlichem Testen während der Entwicklung setzt sich derzeit in der Branche durch.    

Das große Ganze

Eingebunden ist der vECU Creator in das Continental Automotive Edge Framework, abgekürzt CAEdge. Der gerade beschriebene Teil für die Virtualisierung eines HPC dient dazu, zu überprüfen, ob die Software ihren Zweck erfüllt und dabei frühzeitig Fehler (Bugs) auszumerzen. Statt auf der Straße, läuft diese frühzeitige Überprüfung und Optimierung in der Cloud nach dem Motto „from road to cloud ”.

Figure 2: Time savings through the use of hardware virtualization

Zeitersparnis durch Einsatz von Hardware-Virtualisierung       

Neue Funktionen/Anwendungen, die auf Software beruhen, lassen sich so sicherer und schneller entwickeln. Die Markteinführung wird beschleunigt. Das ist für die Automobilbranche wichtig, weil die Entwicklungszyklen bei Software viel kürzer und schneller sind als der Produktlebenszyklus eines Autos. Um diese Kluft zu überbrücken, stellt das CAEdge Framework eine komplette Umgebung bereit, in der alles enthalten ist, was Entwickler für das simulierte Entwickeln und Testen von neuer Software benötigen. Dieses Ökosystem für Entwickler unterstützt Software-defined Vehicle Projekte vom ersten Architekturkonzept bis zur Integration der Software auf der Zielhardware.  

Das komplette CAEdge Framework ist in der Cloud, so dass Entwickler aus aller Welt darauf zugreifen und die Simulationswerkzeuge nutzen können. Auch die virtuelle Hardware (vECU) ist für alle mit einem Zugang zum Framework auf demselben technischen Stand zugänglich. Damit lassen sich verteilte Entwicklungsprojekte – wie sie heute Gang und gäbe sind – optimal organisieren. Auf dem Framework kann man neue Anwendungen binnen weniger Tage in einem Fahrzeug zum Laufen bringen, sie mit vielen virtuellen Testkilometern überprüfen, die Software mit anderen teilen und sie in Summe viel schneller als bisher in den Markt bringen – beispielsweise Continental’s Smart Cockpit HPC in 18 Monaten ab dem Projektstart – statt wie früher üblich nach drei bis vier Jahren! Das Thema Henne und Ei ist somit durch.