Virtualisierte ECUs im Fahrzeug

Mittlerweile bieten moderne Embedded-Prozessoren ausreichend Leistung für die meisten klassischen Anwendungen im Fahrzeug. Neue Funktionen wie Bildverarbeitung und natürlich wirkende HMIs (Human Machine Interfaces) stellen hingegen immer höhere Anforderungen im Bereich des zukunftssicheren und (teil-) autonomen Fahrens. Selbst scheinbar anspruchslosere Systeme wie ein Warntongenerator generieren durch neue HMI-Konzepte wie beispielsweise die räumliche Ortung der Gefahrenquelle technisch komplexe Anforderungen an bisher eher einfache ECUs (Electric Control Units). Bild- und Spracherkennungsalgorithmen setzen auf neuronale Netze und Deep Learning, was noch vor kurzem eine Domäne der Supercomputer war. Es ist oft nicht einmal die reine Rechenleistung, die neue Konzepte erfordert, sondern die schiere Größe der gemeinsamen Datenbasen verschiedener ECUs. Netzwerke wie CAN waren nie für die gemeinsame Nutzung von Kamera- oder Mikrofondaten vorgesehen und Mikrocontroller mit ausschließlich integrierten Speichern sind schnell ausgelastet. Erweiterte Diagnosefunktionen leisten ein Übriges, dass einzelne ECUs eine relativ einfache Grundfunktion mit immer höherem Speicher- und Kommunikationsaufwand verbinden.

Andererseits ist es zunehmend schwieriger, Kostensenkungen im Halbleiterbereich durch reine Technologiefortschritte zu erreichen. Auch wenn Halbleiterhersteller wie Renesas mit R-Car eine weit skalierbare SoC-Familie (System-on-Chip) anbieten, sind bestimmte Mindestkosten für eine einzelne ECU kaum zu unterschreiten. Schließlich braucht man immer ein Gehäuse mit Steckern, Stromversorgung und Platine, und um in Zukunft wie gewohnt mehr Funktionalität für das gleiche Geld zu erhalten, ist ein Umdenken nötig.

Die Wiederkehr der zentralen Server-ECU-Idee

Ein Lösungsansatz besteht darin, standardisierte leistungsfähige Hardware zu entwickeln, auf der man verschiedene Steuergeräte lediglich in Software abbildet. Die Verwendung solcher virtualisierter ECUs erlaubt zum einen eine kostengünstigere Gesamtarchitektur, da ganze Geräte inklusive Verkabelung wegfallen können. Zum anderen sind solche Systeme viel einfacher um neue Funktionen zu erweitern. Ansatzweise ist das schon heute mit den zentralen Body-Steuergeräten realisiert, die verschiedene, auch optionale Funktionen in einer ECU integrieren.

Konsequent zu Ende gedacht kann auf einer ECU auch Software verschiedener Lieferanten für unterschiedliche Aufgaben laufen. Ein prominenter Vertreter einer solchen Konvergenz ist das Infotainmentsystem, welches das klassische Kombiinstrument integriert. Natürlich lassen sich die Ein- und Ausgabeeinheiten wie Bildschirme im Fahrzeug getrennt anordnen, die Ansteuerung erfolgt aber durch nur eine ECU.

Gemeinsam genutzte Ressourcen senken die ECU-Kosten. Renesas

Diese Integration wirft eine Vielzahl neuer Fragen auf: Können klassische Lieferanten ihr Geschäftsmodell auf eine reine Softwarelösung umstellen? Wer trägt die Verantwortung für das integrierte Produkt? Und wie kapselt man diese virtuellen Geräte gegeneinander, um die verschiedenen Sicherheitsaspekte wie Safety und Security zu berücksichtigen?

Robuste Kapselung virtualisierter ECUs

Der technische Lösungsansatz von Renesas im R-Car ist eine umfangreiche Hardware-Virtualisierungsunterstützung, die weit über das hinausgeht, was bei klassischen PCs für virtuelle Maschinen zum Einsatz kommt, die hauptsächlich den benutzten Speicher für die jeweiligen Anwendungen virtualisieren. Das heißt, ein Programm greift auf eine Speicheradresse zu, die dann eine spezielle Hardware in die physikalische Adresse übersetzt. Diese Übersetzungseinheit befindet sich unter der Kontrolle eines Betriebssystems, auch als Hypervisor bezeichnet, das genau die Zugriffsrechte des jeweiligen Programms kennt.

In einem hochintegrierten SoC wie dem R-Car gibt es aber viel mehr Hardware, die selbstständig auf den Arbeitsspeicher zugreifen kann. Beispielsweise kann ein Videoeingang den gesamten Programmarbeitsspeicher manipulieren, wenn man keinen Schutzmechanismus vorsieht. Auch Videodecoder und Audio-DSPs haben ähnliche Möglichkeiten, und ein Videoausgang kann sämtliche Geheimnisse im Arbeitsspeicher einfach über ein HDM-Interface ausgeben, wenn eine Schadsoftware sich die Rechte zur Manipulierung der Ausgabeadressen verschafft.

Abhilfe schafft ein mehrstufiges Speicherschutzkonzept im R-Car. Zum einen gibt es globale Zugriffsrechte für die jeweiligen Hardwarebeschleuniger, und zum anderen lässt sich jedes dieser Module gleichfalls in einen virtuellen Adressraum verschieben. In diesem steht es unter der Kontrolle einer System-MMU, die analog der CPU-MMU die Speicheranfragen in den physikalischen Adressraum übersetzt. Dabei greifen die gleichen Zugriffsrechte wie schon bei der CPU-basierenden Software, und die System-MMU wird vollständig durch das sichere Betriebssystem kontrolliert. In Verbindung mit einem umfassenden Secure-Boot-Konzept sind nachträgliche Manipulationen dieses Betriebssystems praktisch unmöglich.

Speicherschutz auch für GPUs

Eine systemweite MMU erlaubt auch Speicherschutz für die GPU und andere Beschleuniger. Renesas

Dennoch wäre ein reiner Speicherschutz zu kurz gegriffen. Die verschiedenen gekapselten Programme brauchen dennoch Zugriff auf die Hardwarebeschleuniger im R-Car. Zum Beispiel wollen sowohl die Infotainmentapplikation als auch das Kombiinstrument 3D-Grafik auf ihrem individuellen Display darstellen. Da aber die leistungsfähige 3D-GPU die mit Abstand größte Baugruppe auf dem SoC ist, kann man sie nicht einfach verdoppeln oder jeder Applikation etwa eine halbe GPU anbieten. Das Eine wird zu teuer, das Andere ist uneffektiv, falls nicht beide Teile exakt die gleichen Performanceanforderungen haben. Und was, wenn eine dritte Applikation die GPU benötigt?

Reine Softwarevirtualisierungen der GPU sind möglich, kosten aber Grafikleistung. Und davon kann man nie genug haben. Auch ist ein wirklicher Speicherschutz nicht gegeben. Daher hat Renesas zusammen mit Imagination Technologies ein neues GPU-Hardwarevirtualisierungskonzept umgesetzt. Dieses bietet den verschiedenen Programmen bis zu acht virtuelle GPUs. Nachdem das zentrale Betriebssystem die Ressourcenverteilung und Priorisierung bestimmt hat, verwaltet die Hardware diese GPUs vollständig. Dieser Ansatz hat eine Reihe von Vorteilen, denn erstens generiert er nahezu keinerlei Leistungseinbußen gegenüber einem nicht virtualisierten Einzelsystem, und zweitens lassen sich alle Prozesse unabhängig voneinander und ohne Einfluss auf die anderen abbrechen. Diese Unabhängigkeit erlaubt garantierte Leistungsverteilungen, sodass ein Kombiinstrument unter allen Umständen seine Inhalte sicher darstellen kann. Dies ist auch dann der Fall, wenn beispielsweise der Webbrowser des Infotainmentsystems nicht mehr reagiert und neu gestartet werden muss.

Genauso ist es der GPU möglich, nach einer definierten Wartezeit böswillige oder schadhafte Software zu erkennen und zu beenden, wie zum Beispiel sogenannte Shader Bombs, die die GPU sonst zu 100 Prozent auslasten könnten. Und schlussendlich verwendet jede virtualisierte Software ihren eigenen Grafiktreiber, der nicht an ein bestimmtes Betriebssystem gebunden ist. Jeder Lieferant einer virtualisierten Steuergerätesoftware kann das passende Betriebssystem für seine Anwendung wählen, wie beispielsweise ein quelloffenes Linux für das Infotainmentsystem und ein ISO26262-zertifiziertes O/S für die sicherheitskritische Applikation.

R-Car bietet eine Grafikvirtualisierung mit vollständiger Hardwarekontrolle. Renesas

Die Verwaltung der Hardwareressourcen und die Konfiguration der Sicherheitsmechanismen übernimmt in solch einem System der Hypervisor, der eine Art einfaches Betriebssystem mit höchsten Zugriffsrechten darstellt. Hier gibt es verschiedene Ansätze auf dem Markt, die individuelle Vorteile bieten. Renesas unterstützt seine Partner bei der Portierung ihres Hypervisors auf den R-Car, sodass Kunden ihre favorisierte Lösung auswählen können.

Klare Spielregeln von Anfang an

Neben der 3D-Grafik muss ein virtuelles Steuergerät noch weiteren Zugriff auf einzelne physikalisch vorhandene Ein- und Ausgabeeinheiten haben, wodurch mehrere Applikationen miteinander in Konflikt geraten können. Der ECU-Architekt hat die Ressourcen auf die verschiedenen virtualisierten Geräte zu verteilen. Dabei ist es von Vorteil, wenn das gewählte SoC mehrere Einheiten für die gleiche Aufgabe oder auch unabhängige Datenpfade bieten kann. In jedem R-Car gibt es ausreichend Standardinterfaces wie UARTs oder USB, sodass hier eine statische Ressourcenallokation die bequemste Variante ist. Andere Beschleuniger wie beispielsweise Videodecoder sollte man hingegen für maximale Flexibilität in einem Zeitmultiplex nutzen. Videoausgänge bieten unabhängige Darstellungsebenen, die sich verschiedenen virtualisierten Geräten zuordnen und dann zentral zu einem Bild zusammenfügen lassen.

All das muss man von Anfang an zwischen den Lieferanten der Teilsysteme abstimmen. Zudem ist es wichtig, dass der Zulieferer der Hardwaretreiber dieses Konzept ebenfalls unterstützt. Zum Beispiel können zwar verschiedene Videodarstellungsebenen die Datenpfade untereinander isolieren, aber es kann nur einen zentralen Treiber geben, der das Setup des Videoausgangs sicherstellt. Im Falle des R-Car liefert der Hersteller die nötigen Gerätetreiber, die diese Aufteilung unterstützen.

Da nun verschiedene Teilsysteme in einer ECU vereint sind, verlagern sich deren Integrationstests ebenfalls in die ECU. Arbeiten, die traditionell beim Autohersteller am Ende der Fahrzeugentwicklung stattfinden, sind nun vom ECU-Architekten zu betreuen. Es ist spannend zu sehen, wie die Beteiligten mit dieser Herausforderung in Zukunft umgehen, ohne dass sich die langen Entwicklungszyklen weiter verlängern. Zukünftig ist der SoC-Hersteller verstärkt von Anfang an in diesen Prozess einzubinden, denn reine Übernahmen von Produkten aus der Consumerwelt werden den hohen Entwicklungsstandards der Automobilindustrie im Hinblick auf Sicherheit nicht gerecht.

Der Lohn: Zukunftssicherheit

Wer diese Herausforderungen meistert, gewinnt ganz neue Freiheitsgrade. Im Falle des integrierten Cockpits kann der HMI-Designer nun Informationen vom Infotainmentbildschirm auf das zentrale Fahrerdisplay verschieben, wenn die Situation es erfordert. Damit lässt sich die rechenintensive Navigationskarte auf einer gemeinsamen Hardware generieren und bei einer Routenplanung im Fahrersichtfeld temporär anzeigen, was in getrennten Systemen doppelt ausgelegt sein müsste. Heutige Verkabelungen zwischen den Geräten entfallen und Leistungsreserven müssen nur einmal vorgehalten werden. Sie lassen sich auch gleichmäßiger je nach Anwendungsfall abrufen. Virtuelle Steuergeräte auf zentralen leistungsfähigen Servern bieten also ein erhebliches Einsparpotenzial, das es zu nutzen gilt. Der Lohn dieser Investition in zentrale Server-ECUs ist eine preisgünstige Leistungsreserve für zukünftige, heute noch ungeplante Funktionserweiterungen. Diese kann der Kunde auch während der Fahrzeuglebensdauer als Over-the-Air Update bekommen.

(pet)