Smart Mobility Schlanker Hypervisor für unterwegs

Agile Software-Entwicklung bedingt bei sicherheitskritischen Funktionen eine strikte Trennung der Softwaremodule. Im gegenläufigen Hardwaretrend trägt ein zentrales Steuergerät immer mehr Funktionen. Die Auflösung dieses Widerspruchs mit einem Hypervisor muss spezielle Anforderungen berücksichtigen.

Im Automotive-Bereich sind softwaregesteuerte Features, wie Tempomat oder Parkhilfen, heutzutage Standard. Nachträgliche Funktionsupgrades und zukünftig fortlaufende (Over-the-Air-)Updates einer Funktion dürfen keinesfalls Auswirkungen auf andere Softwaremodule haben. Doch wie lässt sich das gewähr­leisten, wenn der Trend gleichzeitig zur Konzentration von immer mehr miteinander vernetzten Funktionen auf wenigen, zentralen Steuergeräten geht? Ist es in einem solchen Umfeld überhaupt möglich, vorab mit Tests die funktionale Sicherheit des Gesamtsystems nach den Upgrades und Updates zu validieren und zu verifizieren?

Schon diese beiden Fragestellungen zeigen, dass es gelingen muss, Softwarefunktionen sicher voneinander zu entkoppeln.
 

Praktikable Partitionierung

Nicht nur unter dem Aspekt der funktionalen Sicherheit ist diese Entkopplung gefragt. Sie vereinfacht auch die Workflows in der Entwicklung, wenn Software unterschiedlicher Hersteller auf einem einzigen Steuergerät betrieben wird. Zudem sorgt die Trennung dafür, dass Steuergeräte in Zeiten zunehmender Cyberkriminalität schwieriger angreifbar sind. Hat sich ein Hacker Zugang zu einer Funktion verschafft, stellt der Hypervisor eine weitere Hürde dar.

Um die Entkopplung zu realisieren, sind verschiedene Ansätze denkbar. So könnte man Softwarefunk­tionen strikt auf jeweils eigene Steuerungshardware verteilen. Doch sowohl die Hardwarekosten als auch die Systemkomplexität sprechen dagegen.

Handhabbarer ist dagegen eine auf Autosar basierende Architektur mit definierten Partitionierungs- und Separierungskonzepten. Auf dieser Basis ist es möglich, Upgrades einzelner Funktionen zu realisieren und dabei die Beeinträch­tigung weiterer Funktionen auszuschließen. So ist gewährleistet, dass die Modifikation einer Funktion keine umfassende Neuvalidierung sämtlicher Software auf dem betreffenden Steuergerät erfordert. Um die Autosar-Konzepte umzusetzen, sind jedoch Erweiterungen notwendig.

Fortsetzung mit dem Hypervisor

Eine gangbare Erweiterung ist der Einsatz eines Hypervisors. Er partitioniert ein einzelnes Steuergerät in diverse virtuelle Maschinen (VM). Obwohl die Funktionen faktisch auf demselben Steuergerät laufen, wähnt sich die jeweilige Software in einem Zustand, in dem es für jede Funktion eine eigene Hardware gibt.

Die Funktionen sind so strikt entkoppelt, dass sie ohne komplette Neuvalidierung einzeln modifiziert werden können – und ihre verschiedenen Hersteller schon in der Entwicklung des Steuergeräts unabhängig von allen anderen arbeiten können.

Softwarefehler oder böswillige Eindringlinge bleiben lokal auf eine einzelne virtuelle Maschine begrenzt. Darüber hinaus kann Software mit verschiedenen ASIL-Sicherheitseinstufungen (Automotive Safety Integrity Level) von der niedrigsten Stufe QM bis zur höchsten Anforderung ASIL D auf einem einzigen Steuergerät laufen. Bei allen Vorteilen kommt es bei einer Hypervisor-Lösung jedoch auf die Umsetzung an. Ohne Anpassung an die spezifische Fahrzeugumgebung droht Ungemach. So benötigt ein Hypervisor üblicherweise ein eigenes Speichermanagement sowie einen sogenannten Hypervisor-Privilege-Modus, der die Zugriffs­berech­tigungen regelt.

Dieser ist bei klassischen Ausführungen dreistufig: der Hypervisor selbst, die Basissoftware und die Applikationsfunktionen. Doch sowohl das entsprechende Speichermanagement als auch der dreistufige Privilege-Modus werden von generischen Fahrzeug-Mikrocontrollern nicht unter­stützt. Dies stand dem breiten Einsatz der Hypervisor-Technologie im Automobil bisher entgegen.

Zur Entschärfung der genannten Problemfelder hat Bosch Automotive Electronics – Body Electronics (AE-BE) in einem OEM-Projekt den Etas Lightweight Hypervisor (RTA-LWHVR) verwendet. Der optimierte Automotive-Hypervisor hat nur noch einen Speicherbedarf von 5 Kilobyte (kB) und die Zugriffszeiten konnten in unterschiedlichen Anwendungsfällen um Faktor vier bis fünf verbessert werden. Bei diesem Hypervisor ist eine Beeinflussungen zwischen den virtuellen Maschinen ausgeschlossen. Im  konkreten Projekt war ein zentrales Body-Steuergerät in elf virtuelle Maschinen partitioniert, die jeweils für Software von unterschiedlichen Zulieferern reserviert waren. Die ASIL-Einstufung reichte dabei von QM bis B.