Professional Articles

Einst waren es nur mechanische Maschinen. Heutige Autos basieren jedoch bereits zu einem großen Teil auf elektronischen Komponenten und der dazugehörigen Software, und der Trend zum autonomen Fahren wird diese Entwicklung zweifelsohne noch verstärken. Das Auto der Zukunft wird noch mehr Elektronik und Rechenleistung benötigen, um einerseits die Sicherheit mit Hilfe von Fahrerassistenzsystemen zu erhöhen und andererseits die Komfort-, Unterhaltungs- und Kommunikationsbedürfnisse der Fahrgäste zu erfüllen. Das Internet der Dinge (IoT), das den Geräten im Fahrzeug die dafür notwendige Konnektivität verleiht, bringt erhebliche neue Herausforderungen für die funktionale Sicherheit mit sich. Die Sicherheitsaspekte bestimmen daher zunehmend das Softwaredesign, und die Zertifizierungsstandards werden im Automobilbau bald eine ähnlich wichtige Rolle spielen, wie sie es heute schon in der Luftfahrtindustrie tun.

Abbildung 1: Auf der Grundlage des PikeOS-Mikrokerns können verschiedene Betriebssysteme und Anwendungen mit strikter Trennung ausgeführt werden

Hardware- und Softwaresysteme in Fahrzeugen sind historisch bedingt fragmentiert. Die Einführung elektronischer Systeme erfolgte in der Regel völlig unabhängig von anderen Systemen, was zu einem Wildwuchs bei CPUs und Controllern und vor allem bei der Software führte. In den heutigen Fahrzeugen steuern zwischen 60 und 100 verschiedene CPUs mit ihren eigenen Softwareanwendungen verschiedene Funktionen wie Motorsteuerung, Beleuchtung und Bremsen. Diese CPUs sind zudem über bis zu sieben verschiedene Busse miteinander verbunden. Eine solche Komplexität erhöht die Entwicklungs- und Produktionskosten und macht auch die Wartung nicht einfacher.

Mehrere Hardwareplattformen erfordern daher auch unterschiedliche Entwicklungsumgebungen und Softwareentwickler mit entsprechendem Know-how, was einen erheblichen Kostenfaktor darstellen kann. Darüber hinaus ist es natürlich das Bestreben eines jeden Herstellers, die Hardwarekosten zu senken und die Funktionalität zunehmend in die Software zu verlagern (d.h. das Software Defined Car). Eines der Hauptziele bei der Entwicklung des Autos der Zukunft ist daher die Einführung einer einheitlichen Plattform, die alle Fahrzeugfunktionen steuert.

Trotz aller Probleme, die der Wildwuchs an CPUs mit sich bringt, hat sie einen großen Vorteil: Sie trennt die einzelnen Funktionen, so dass kein System durch Fehler in einem anderen System beeinträchtigt werden kann. In heutigen Autos kann das Audiosystem unter keinen Umständen die Bremsen beeinflussen, da beide von streng getrennten Systemen gesteuert werden. Werden solche unterschiedlichen Systeme auf eine einheitliche Hardwareplattform migriert, ist diese Trennung nicht mehr von vornherein gewährleistet und muss daher auf andere Weise erreicht werden. Im Flugzeug- und Eisenbahnbau ist dieses Problem bereits weitgehend gelöst, und die dort verwendeten Ansätze lassen sich auch auf die Automobilindustrie übertragen.

Hypervisoren trennen Anwendungen

Viele Softwareanbieter nutzen Hypervisor-Technologien, um mehrere Betriebssysteme auf einer einzigen Hardwareplattform laufen zu lassen. Dabei handelt es sich um eine Virtualisierungstechnik, bei der Hardwarefunktionen zum gleichzeitigen Betrieb von Gastbetriebssystemen genutzt werden. Jedes dieser Gastbetriebssysteme verfügt über eine von allen anderen Betriebssystemen strikt getrennte Partition, auch Container genannt, in der es unabhängig von allen anderen Systemen arbeitet.

Eine solche Architektur ist offensichtlich geeignet, um dem Ziel der Vereinheitlichung der Hardware-Plattformen näher zu kommen. In mehreren Partitionen kann der Hypervisor diverse Funktionen hosten, die bisher getrennte CPUs erforderten. Es muss jedoch unbedingt sichergestellt werden, dass die Software, die die Hypervisor-Funktionalität bereitstellt, auch tatsächlich eine strikte Trennung zwischen den Partitionen gewährleistet. Andernfalls kann es trotz einheitlicher Hardware-Plattform zu Wechselwirkungen zwischen kritischen und unkritischen Anwendungen kommen, wie im Beispiel mit dem Audiosystem und den Bremsen. An dieser Stelle kommen dann die Sicherheitszertifizierungen wie SIL 4 und ISO 26262 ins Spiel. Solche zertifizierten Hypervisor-Technologien geben die Gewissheit, dass die Funktionen in verschiedenen Partitionen wirklich voneinander getrennt sind, als ob sie auf verschiedenen CPUs laufen würden.

Multi-Core-CPUs

Ein weiterer beliebter Ansatz zur Erreichung dieses Ziels ist der Einsatz von Multi-Core-CPUs. Obwohl solche CPUs in erster Linie aus Leistungsgründen eingesetzt werden, können sie auch die erforderliche Trennung der einzelnen Funktionen unterstützen. Allerdings ist die Zertifizierung von Multi-Core-Systemen sehr komplex, da viele zertifizierte Systeme tatsächlich nur einen Kern verwenden, was den eigentlichen Grund für den Einsatz von Multi-Core-CPUs, die Leistung, konterkariert. Darüber hinaus ist die Trennung der Funktionen somit nicht gewährleistet. Wenn verschiedene Funktionen in einem einzigen Stück Software gebündelt werden, das in einem Echtzeitbetriebssystem (RTOS) auf nur einem CPU-Kern läuft, kann es sehr leicht zu Interferenzen zwischen den Funktionen kommen. Die Auswirkung einer Anwendung auf das Laufzeitverhalten einer anderen Anwendung kann zu Sicherheitsproblemen führen, z. B. zur Überschreitung von Zeitlimits bei Echtzeitanwendungen. Ebenso können Timing-Effekte aufgrund der gemeinsamen Nutzung von Systemressourcen, z. B. Cache- und Speicherbussen, zu versteckten Informationskanälen führen, die die Vertraulichkeitsanforderungen der Anwendung verletzen. Wenn kritische Funktionen jedoch auf verschiedene Kerne verteilt sind, ist die erforderliche strikte Trennung gewährleistet.

Der Einsatz von Hypervisoren auf Multi-Core-Systemen ist grundsätzlich ein geeignetes Mittel, um den Herausforderungen beim Systemdesign zu begegnen. Allerdings ist der Einsatz von Hypervisoren allein keine Garantie für eine strikte Trennung der verschiedenen Funktionen. Die meisten Hypervisoren befinden sich auf einer RTOS-Plattform, die von ihrem eigenen Design her eine solche Trennung nicht unterstützt. Gerade bei sicherheitskritischen Anwendungen ist es jedoch wichtig, dass das RTOS bereits speziell für die getrennte Ausführung der verschiedenen Funktionen ausgelegt ist, d.h. es handelt sich vom Design her eher um einen Separationskernel als um ein einfaches RTOS.

Abbildung 2: Unterschiedliche Anwendungen auf einer Hardwareplattform und ein deterministischer Kommunikationskanal ermöglichen ein einfaches und sicheres Systemdesign

Separation als Design-Grundlage

Ein solcher Separationskern 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 durch eine zeitliche Partitionierung, wobei die CPU-Zeit bei der Konfiguration in Zeitpartitionen unterteilt wird. Die Dauer, Reihenfolge und Wiederholungsperiode (Hauptzeitrahmen) der Zeitpartitionen kann vom Integrator statisch als Zeitplan definiert werden. Ein Scheduler plant die Zeitabschnitte entsprechend dem statischen Zeitplan ein. Die Benutzeranwendungen sind einer oder mehreren solcher Zeitpartitionen zugeordnet und werden nur dann für die Einplanung berücksichtigt, wenn die betreffende Zeitpartition aktiv ist. Auf diese Weise ist das zeitliche Verhalten einer partitionierten Benutzeranwendung unabhängig vom Rest des Systems. Die räumliche Trennung erfolgt durch eine Ressourcenpartitionierung, bei der die Systemressourcen - wie Hauptspeicher, Dateien, Geräte, sichere Kommunikationskanäle und Kerne - partitioniert und statisch Containern, den sogenannten Ressourcenpartitionen, zugeordnet werden. Die Ausführung von Benutzeranwendungen findet im Kontext einer Ressourcenpartition statt. Während der Ausführung stellt der Separationskernel sicher, dass eine Anwendung garantierten Zugriff auf die ihr 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-Einheit

Eine Architektur, die auf einem separaten Kernel basiert, vereinfacht auch die Integration von Funktionen mit unterschiedlicher Kritikalität auf einer Hardware-Plattform. So können beispielsweise Android-basierte Infotainment-Funktionen und kritische Autosar-Applikationen, die unabhängig voneinander zertifiziert werden können - was die Zertifizierung deutlich beschleunigt und die Kosten für die Zertifizierung senkt -, in streng voneinander getrennten Partitionen laufen. Zudem müssen bei einer weiteren Konsolidierung nur noch die neuen zusätzlichen Anwendungen validiert werden, da sie die bisherigen nicht beeinflussen.

Kerndaten

Um dem Wildwuchs an CPUs, Steuergeräten und Software in den heutigen Fahrzeugen entgegenzuwirken, setzen die Hersteller verstärkt auf CPUs mit einem Separationskern, auf dem verschiedene Betriebssysteme laufen können und der eine räumliche und zeitliche Trennung der Anwendungen ermöglicht. Mit solchen Hypervisor-Technologien lassen sich einfache und sichere Systemdesigns realisieren.

Gerade in gemischten Umgebungen mit relativ schlecht abgesicherten Betriebssystemen, wie z.B. Android, kann ein Separationskernel auch die wichtige Sicherheitsfunktion erfüllen, Angriffe zu erschweren. Dieser Kernel, der als Hypervisor für die verschiedenen Gastbetriebssysteme fungiert, ist in der Lage, privilegierte Systemaufrufe der Gastsysteme abzufangen und vor der eigentlichen Ausführung zunächst auf die erforderlichen Berechtigungen zu prüfen. Während bei normalen Desktop-Betriebssystemen alle Gerätetreiber in den Kernel integriert sind, kann auf diese Weise eine Umgebung geschaffen werden, in der nur ein sehr kleiner Satz von Diensten im privilegierten Modus im Kernel läuft - zum Beispiel Scheduling, Kontextwechsel, Prozesskommunikation, Prozesssynchronisation und Interrupt-Handling. Gerätetreiber arbeiten dann ohne Privilegien im normalen Benutzermodus wie jeder andere Anwendungscode, was die Angriffsfläche des gesamten Systems erheblich reduziert.

Alle Rechte vorbehalten. Urheberrecht Automobil Elektronik