Avionik als Vorbild für autonome Fahrzeuge

Das Thema selbstfahrende Autos bleibt spannend, auch wenn die kurzfristigen Perspektiven in einer Post-Corona-Wirtschaft schwierig aussehen. Damit dies gelingen kann, müssen autonome Fahrzeuge das überaus erfolgreiche Sicherheitsbewusstsein der Luftfahrt – in der auch nur ein Unfall inakzeptabel ist – mit der gleichermaßen außerordentlichen Flexibilität und Erschwinglichkeit des Automobils kombinieren.

Um die erforderliche Flexibilität zu erreichen, liegt ein Hauptaugenmerk darauf, Kosten, Gewicht und Umfang der Elektronik zu senken, die benötigt wird, um Menschen sicher von A nach B zu transportieren. Nach dem Motor selbst sind die Elektronik und die Kabelstränge die teuersten und schwersten Bestandteile eines Fahrzeugs.

Systemarichtekturen neu überdacht

Systemarchitekturen werden neu überdacht, um zehnfach verkürzte Verkabelungsstrecken von derzeit 1,5 Kilometern und mehr zu realisieren. Anstelle des herkömmlichen Ansatzes, verschiedene Domains für die diversen Datennetzwerkprotokolle einzurichten (von denen einige seit Jahrzehnten existieren), bildet sich eine zonale Architektur heraus, bei der Hochleistungscontroller eine Vielzahl unterschiedlicher Funktionen an einem Fahrzeugbereich verwalten. Folgen dieser Verschiebung sind:

• 

  Es ist wichtig, den Code in überschaubare Blöcke aufzuschlüsseln. Lynx Software Technologies

  Die Übernahme von Ethernet ins Fahrzeuginnere zum Zusammenschluss von Subsystemen. Einige werten sogar 10-GB-Technologie aus.

• Die Verarbeitungsfunktionen auf weniger, sehr leistungsstarke elektrische Steuerungen (ECUs) zu verdichten.

Zum Spektrum unterschiedlicher Netzwerke auf diesen Controllern gehören CAN (Controller Area Network), das sich um Powertrain und verwandte Funktionen kümmert, LIN (Local Interconnect Network) für Komfortfunktionen für Fahrer und Fahrgast wie Klimatisierung, Beleuchtung und Sitzverstellung, MOST (Media Oriented System Transport) für das Infotainment sowie Flexray für das Antiblockiersystem (ABS), die elektronische Servolenkung (EPS) und Funktionen für die Fahrzeugstabilität. Einer der positiven Nebeneffekte dieses Ansatzes besteht darin, dass sich durch die Verkleinerung der Angriffsoberfläche für potenzielle Hacker, die Fahrzeugsicherheit erhöhen dürfte. Die Angriffsoberfläche einer Softwareumgebung ist die Summe der verschiedenen Stellen, an denen ein unbefugter Nutzer eventuell Daten einfügen oder extrahieren kann.

In einem Szenario indes, in dem einfache Sensoren verschlüsselte Informationen an einen zentralen Knoten senden, konzentriert sich die Abschwächung von Sicherheit auf diesen einen Punkt. Es liegt auf der Hand, dass diese Knoten Daten mit sehr unterschiedlichen Anforderungen an das Antwortverhalten verarbeiten. Und diese Systeme müssen natürlich funktionieren und zwar immer. Menschenleben (und Firmenexistenzen) stehen auf dem Spiel. Die Herausforderung besteht darin, dies in einem Fahrzeug umzusetzen, in dem bestimmte Systeme missionskritisch sind und in Mikrosekunden angegangen werden müssen. Die selbstfahrenden Fahrzeuge auf heutigen Straßen sind de facto Server auf Rädern. Die in diesen Prototypen eingesetzten Intel-Xeon- und nVidia-Plattformen werden schlichtweg von Lösungen verdrängt, die erheblich geringeren Platz benötigen sowie weniger Kosten und Stromverbrauch verursachen. Es kommt zu einem Wettrennen zwischen einer ganzen Reihe von Unternehmen um den Marktanteils- und Profitabilitätssieg in diesem Segment.

Das Verarbeitungssystem

Wenden wir uns nun dem Aspekt Safety & Security zu. Autonome Fahrzeuge verlangen, wie Flugzeuge, nach Softwareplattformen, die von Grund auf in Hinblick auf ihre Sicherheit entwickelt wurden („Secure by Design“). Doch muss dies ohne den hohen Entwicklungsaufwand bewerkstelligt werden, der gute Flugzeugtechnik so teuer macht.

Im Folgenden soll eines dieser Verarbeitungssysteme genauer betrachtet werden. Es enthält heterogene Mehrkernprozessoren, in denen sich Allzweckprozessoren befinden, aber möglicherweise auch grafische Koprozessoren (GPGPUs, Allzweck-GPUs auf High-End-Grafikkarten), programmierbare Logik oder spezialisierte Echtzeitkern-Hardwarebeschleuniger. Aus Software-Perspektive ergibt sich die Notwendigkeit, funktionsreiche Betriebssysteme (typischerweise Linux) zu kombinieren, auf denen vielseitige Einsatzmöglichkeiten nahezu sofort bereitgestellt werden können, bei garantiertem Echtzeit-Determinismus für bestimmte Funktionen.

Gleichzeitig muss die Hypervisor-Ebene sicherheitskritische Anwendungen bis ISO 26262 ASIL D hosten, „Nicht-Echtzeitbetriebssysteme“ (wie Android und Linux) unterstützen sowie Autosar-Kernel (AUTomotive Open Systems ARchitecture) und Bare-Metal-Anwendungen.

Die breite Funktionalität in einigen aktuellen Software-Komponenten wird realisiert mit separaten Verarbeitungssystemen, die unterschiedliche Software ausführen. Jedoch besteht das Bestreben darin, die Verarbeitungsprozesse dynamischer den unterschiedlichen Aufgabenstellungen zuzuteilen und von bestimmten Anbietern unabhängiger zu sein. Dies hat zur Folge, dass diese Systeme zunehmend Hypervisor-Technologie einsetzen und auf ihnen unterschiedliche Betriebssysteme und Anwendungen ausführen (Bild 1).

Warum ein Separation-Kernel erforderlich ist

Traditionell wurden bei virtualisierten Embedded-Software-Architekturen viele der Lasten auf einen Hypervisor und/oder ein Betriebssystem gelegt. Das kann zu Plattformabhängigkeiten führen, die sich infolge zusätzlicher Kopien und Kontextwechseln auf die Leistung auswirken, aber auch eine Reihe von Herausforderungen an die Architektur hervorrufen:

• freigegebener Adressraum
• gemeinsam genutztes Vorrecht auf die CPU
• gemeinsame Arbitration Points
• globale Ressourcenpools
• zusammensetzen von Code-Verzweigungen
• zusammensetzen von Zeitverhalten
• große Abhängigkeit hinsichtlich der Zertifizierung

Der Ansatz Lynxsecure ist hingegen sehr einfach: Auf jedem CPU-Kern laufen ausführbare, unabhängige Programme. Der Separation-Kernel partitioniert Plattformressourcen in isolierte virtuelle Maschinen (VM). Zusätzliche Funktionalitäten erfolgen schichtweise mittels „Subjekten“ und „Gästen“. Jede Zusatzschicht unterliegt der spezifischen VM-Definition. Der Separation-Kernel definiert präzise die VM für jeden Gast, wie Hardware-Rechte und Privilegien, Kommunikationspfade und Hypercall-Berechtigungen. Ingenieure definieren ihre Systeme selbst. Es gibt kein Master-, Trusted-, Root-, Helper- oder Service-RTOS. Auch gibt es keine Speicheränderungen nach dem Hochfahrenmemo oder andere der virtuellen Maschine zugeteilten Arbeitsspeicherressourcen. Einen zentralen Schwachpunkt (Single Point of Failure, SPoF) gibt es ebenfalls nicht.

Viele Märkte schwankten im Laufe der Jahre zwischen verteilten und zentralisierten Computing-Konzepten. Dieser Schub hin zur Minimierung der Sensorkosten und zur Verlagerung von mehr (nicht sämtlicher) Datenverarbeitung zurück in die lokalisierte Abwicklung ist eine Umkehr zu wieder mehr zentralisierter Funktionalität. Dies könnte noch vorangetrieben werden, um Kosten und Leistungsverbrauch weiter zu verringern.

Viele Fahrzeugsysteme benötigen die meiste Zeit über minimale Verarbeitungsprozesse. Um sich am Cloud Computing ein Beispiel zu nehmen: Was wäre, wenn diese „Systeme aller Systeme“ (das heißt mehrere im Fahrzeug miteinander verbundene ECUs) die Verarbeitungsleistung je nach Bedarf zuteilen könnten? Anders als Cloud Computing müsste die Zeit, um ein Ausweichmanöver einzuleiten, Mikrosekunden statt Minuten betragen. Mit steigenden Netzwerkbandbreiten und zeitkritischen Netzwerkprotokollen ließen sich jedoch erhebliche Einsparungen erzielen.

Normenkonformität

Die Einhaltung einschlägiger Sicherheitsnormen wie ISO26262 und (zunehmend) ISO21434 ist extrem wichtig, ob es sich um die Entwicklung herkömmlicher Automotive-Komponenten wie tatsächliche physische Komponenten oder – wie im Fall von Lynx – um virtuelle wie Hypervisoren handelt. Aus der 30-jährigen Erfahrung im Avionikbereich hat sich gezeigt, dass es entscheidend ist, ausführliche Anforderungss­pezifikationen zu erstellen und eine detaillierte Rückverfolgbarkeit bis in die feinsten Hardwarefunktionen sicherzustellen. Dies erleichtert die Verifikation. Angesichts wachsender Code-Grundlagen im Automobil ist der einzig mögliche Weg, den Code aufzuspalten. Entscheidend ist dabei, den Code in überschaubare Blöcke aufzuschlüsseln, nachzuweisen, dass die Ausführung einer Codebasis isoliert von einer anderen erfolgt, und dann durch das Zurückführen auf andere Artefakte zu zeigen, dass die Anforderungen erfüllt wurden.

In dem hier beschriebenen Beispiel erzielt dies die Nutzung einer vollständig Autosar-konformen Laufzeitplattform, in diesem Fall von Etas, die aus RTA-OS (Betriebssystem für tief eingebettete ECUs), RTA-RTE (Autosar-Laufzeitumgebungsgenerator) und RTA-BSW (Autosar-konforme Basissoftware) besteht. Existierende Autosar-Software lässt sich in eine leistungsstarke ECU integrieren und sorgt gleichzeitig für die nötige Safety & Security und bietet die notwendigen Schutzfunktionen vor unangemessenen Eingriffen, wie sie anspruchsvollste Anwendungen erfordern.

Fazit

Eine eher allmähliche Evolution dieser außerordentlich sicherheitskritischen Entwicklung ist wahrscheinlich keine schlechte Sache und gibt Unternehmen die Gelegenheit, die erheblichen Herausforderungen vor allem bei der Erstellung der Softwareplattform abzuarbeiten. Umfang, Gewicht, Leistungsstärke sowie Safety & Security sind für die Avionik ebenso kritisch wie für ADAS. Nur müssen diese Merkmale in einem weitaus engeren Kontext bereitgestellt werden, was  Entwicklungszeit und Kosten betrifft. Eine schwierige Herausforderung, aber keine unmögliche.

(neu)