Einheitliche Hardware-Plattformen für alle Autofunktionen

Einst waren es rein mechanische Maschinen, hingegen basieren heutige Autos bereits zu großen Teilen auf elektronischen Komponenten samt der dazugehörigen Software, und der Trend zum autonomen Fahren wird diese Entwicklung zweifellos noch verstärken. Das Auto der Zukunft wird noch mehr Elektronik und Rechenleistung benötigen – einerseits, um mithilfe von Fahrerassistenzsystemen die Sicherheit zu erhöhen und andererseits, um den Anforderungen der Passagiere nach Komfort, Unterhaltung und Kommunikation zu entsprechen. Das Internet of Things (IoT), das Geräten innerhalb des Fahrzeugs die dafür notwendige Konnektivität verleiht, bringt dabei erhebliche neue Herausforderungen an die Sicherheit mit sich. Sicherheitsaspekte bestimmen daher zunehmend das Software-Design und Zertifizierungsstandards werden im Automobilbau bald eine ähnlich wichtige Rolle spielen wie heute in der Flugzeugindustrie.

Hard- und Softwaresysteme in Automobilen sind historisch fragmentiert. Die Einführung elektronischer Systeme erfolgte in der Regel völlig unabhängig von anderen, was zu einem Wildwuchs bei CPUs und Controllern und erst recht bei der Software führte. In heutigen Fahrzeugen kontrollieren zwischen 60 und 100 unterschiedliche CPUs mit ihren jeweils eigenen Software-Applikationen die unterschiedlichen Funktionen wie Motorsteuerung, Beleuchtung oder Bremsen. Diese CPUs sind zudem über bis zu sieben unterschiedliche Busse miteinander verbunden. Eine solche Komplexität erhöht die Entwicklungs- und Fertigungskosten und macht auch die Wartung nicht einfacher. So erfordern multiple Hardware-Plattformen auch unterschiedliche Entwicklungsumgebungen und Software-Entwickler mit der jeweiligen Expertise, was ein erheblicher Kostenfaktor sein kann. Zudem ist es natürlich das Bestreben eines jeden Herstellers, die Hardwarekosten zu reduzieren und die Funktionalität zunehmend in die Software zu verlagern (Software Defined Car). Eines der wesentlichen Ziele bei der Entwicklung des Autos der Zukunft ist daher die Einführung einer einheitlichen Plattform, die sämtliche Autofunktionen steuert.

Bei allen Problemen, die der Wildwuchs von CPUs mit sich bringt, hat er doch einen großen Vorteil: Er trennt die einzelnen Funktionen, sodass kein System von Fehlern in einem anderen beeinträchtigt werden kann. So kann in heutigen Fahrzeugen das Audiosystem keinesfalls auf die Bremsen einwirken, da beide von strikt getrennten Systemen kontrolliert werden. Migriert man solch unterschiedliche Systeme auf eine einheitliche Hardware-Plattform, ist diese Trennung nicht mehr von vornherein gewährleistet und muss in diesem Fall also auf anderen Wegen erreicht werden. Im Flugzeug- und im Eisenbahnbau ist dieses Problem heute bereits weitgehend gelöst, und die dort verwendeten Ansätze lassen sich auch auf die Automobilindustrie übertragen.

Hypervisoren trennen Applikationen

Viele Software-Anbieter verwenden Hypervisor-Technologien, um die Ausführung mehrerer Betriebssysteme auf nur einer Hardwareplattform zu ermöglichen. Dabei handelt es sich um eine Virtualisierungstechnik, die Hardwarefunktionen nutzt, um Gast-Betriebssysteme gleichzeitig zu betreiben. Jedes dieser Gast-Betriebssysteme bekommt dabei eine von allen anderen strikt getrennte Partition, auch Container genannt, in der es unabhängig von allen anderen arbeitet.

Eine solche Architektur ist offensichtlich geeignet, dem Ziel einer Vereinheitlichung der Hardwareplattformen näher zu kommen. Der Hypervisor kann in mehreren Partitionen unterschiedliche Funktionen hosten, die bisher separate CPUs erforderten. Allerdings muss dabei absolut sichergestellt sein, dass die Software, die die Hypervisor-Funktionalität zur Verfügung stellt, tatsächlich eine strikte Trennung zwischen den Partitionen garantiert. Ansonsten hat man zwar eine einheitliche Hardwareplattform, aber möglicherweise Interaktionen zwischen kritischen und nicht kritischen Anwendungen wie im Beispiel mit dem Audiosystem und den Bremsen. An dieser Stelle kommen dann die Sicherheits-Zertifizierungen wie SIL 4 und ISO 26262 ins Spiel. Derart zertifizierte Hypervisor-Technologien geben die Sicherheit, dass Funktionen in unterschiedlichen Partitionen tatsächlich so voneinander getrennt sind, als liefen sie auf unterschiedlichen CPUs.

Multicore-CPUs

Ein anderer populärer Ansatz, dieses Ziel zu erreichen, ist der Einsatz von Multicore-CPUs. Primär verwendet man solche CPUs zwar aus Performance-Gründen, doch sie können auch die verlangte Trennung einzelner Funktionen unterstützen. Allerdings ist die Zertifizierung von Multicore-Systemen sehr komplex, und viele zertifizierte Systeme nutzen tatsächlich nur einen Kern, was den eigentlichen Grund für den Einsatz von Multicore-CPUs, die Performance, konterkariert. Zudem ist so die Trennung der Funktionen nicht gewährleistet. Wenn unterschiedliche Funktionen in einer einzelnen Software gebündelt sind, die unter einem Echtzeit-Betriebssystem (Real Time Operating System – RTOS) auf nur einem CPU-Kern laufen, können sehr leicht Interferenzen zwischen den Funktionen auftreten. So kann die Auswirkung einer Anwendung auf das Laufzeitverhalten einer anderen Anwendung zu Sicherheitsproblemen führen, etwa das Überschreiten von Fristen bei Echtzeitanwendungen. Auf ähnliche Weise können Timing-Effekte aufgrund der gemeinsamen Nutzung der Systemressourcen, wie beispielsweise Caches und Speicherbusse, zu verborgenen Informationskanälen führen, die gegen die Vertraulichkeitsanforderungen der Anwendung verstoßen. Verteilt man dagegen kritische Funktionen auf unterschiedliche Kerne, ist die geforderte strikte Trennung gewährleistet.

Der Einsatz von Hypervisoren auf Multicore-Systemen ist grundsätzlich eine geeignete Möglichkeit, den Herausforderungen beim Systemdesign zu begegnen. Allerdings ist der Einsatz von Hypervisoren allein noch keine Garantie für die strikte Trennung der unterschiedlichen Funktionen. Die meisten Hypervisoren sind auf ein RTOS aufgesetzt, das vom eigenen Design her eine solche Trennung nicht unterstützt. Gerade in sicherheitskritischen Anwendungen ist es aber wichtig, dass bereits das RTOS speziell für die getrennte Ausführung unterschiedlicher Funktionen ausgelegt ist, es also vom Design her eher ein Separation-Kernel ist als ein simples RTOS.

Unterschiedliche Anwendungen auf einer Hardwareplattform und ein deterministischer Kommunikationskanal ermöglichen ein einfaches, aber sicheres Systemdesign. Sysgo

Separation als Design-Grundlage

Ein solcher Separation-Kernel ermöglicht die räumliche und zeitliche Trennung zwischen Anwendungen und stellt die Partitionen für die Ausführung von Benutzeranwendungen bereit. Die zeitliche Trennung erfolgt dabei durch Zeitpartitionierung, bei der man die CPU-Zeit während der Konfiguration in Zeitpartitionen aufteilt. Die Dauer, Reihenfolge und Wiederholungsperiode (Hauptzeitrahmen) von Zeitpartitionen lassen sich dann statisch vom Integrator als Zeitplan definieren. Ein Scheduler terminiert die Zeitpartitionen entsprechend dem statischen Zeitplan. Benutzeranwendungen werden einer oder mehreren solcher Zeitpartitionen zugewiesen und nur dann für die Terminierung berücksichtigt, wenn die zugehörige Zeitpartition aktiv ist. Auf diese Weise ist das Zeitverhalten einer partitionierten Benutzeranwendung unabhängig vom Rest des Systems.

Räumliche Trennung erfolgt durch Ressourcenpartitionierung, bei der man die Systemressourcen wie Hauptspeicher, Dateien, Geräte, sichere Kommunikationskanäle und Kerne partitioniert und Containern, den sogenannten Ressourcenpartitionen, statisch zuweist. Die Ausführung von Benutzeranwendungen erfolgt im Kontext einer Ressourcenpartition. Während der Ausführung gewährleistet der Separation-Kernel, dass eine Anwendung garantierten Zugriff auf die zugewiesenen Ressourcen ihrer Ressourcenpartition hat und dass Anwendungen aus anderen Ressourcenpartitionen diese Ressourcen nicht nutzen können, es sei denn, die gemeinsame Nutzung ist explizit konfiguriert.

Android und Autosar auf einer Hardware

Eine Architektur auf Basis eines Separation-Kernels vereinfacht auch die Integration von Funktionen unterschiedlicher Kritikalität auf einer Hardwareplattform. So können in strikt voneinander getrennten Partitionen beispielsweise Android-basierte Infotainment-Funktionen und kritische Autosar-Anwendungen laufen, die sich auch unabhängig voneinander zertifizieren lassen, was die Zertifizierung deutlich beschleunigt und die Kosten dafür reduziert. Bei einer weiteren Konsolidierung sind zudem nur die neu hinzugekommenen Applikationen zu validieren, da sie die bisherigen nicht beeinflussen.

Gerade in gemischten Umgebungen mit relativ schlecht gesicherten Betriebssystemen wie Android kann ein Separation-Kernel auch eine wichtige Sicherheitsfunktion erfüllen, um Angriffe zu erschweren. Dieser Kernel, der als Hypervisor für die unterschiedlichen Gastbetriebssysteme agiert, ist in der Lage, privilegierte Systemaufrufe der Gastsysteme abzufangen und vor ihrer tatsächlichen Ausführung zunächst auf die erforderlichen Berechtigungen zu prüfen. Während übliche Desktop-Betriebssysteme alle Gerätetreiber im Kernel integriert haben, kann man so eine Umgebung schaffen, in der nur ein sehr kleines Set von Diensten im Priviledged Mode im Kernel abläuft – etwa Scheduling, Context Switching, Prozesskommunikation und -synchronisation und Interrupt-Handling. Gerätetreiber arbeiten dann ohne Privilegien im ganz normalen User-Modus wie jeder andere Anwendungscode, was die Angriffsfläche des gesamten Systems deutlich reduziert.

(pet)