Autonomes Fahren Entwickler autonomer Fahrzeuge können von der Avionik lernen

Autor / Redakteur: Ian Ferguson * / Dipl.-Ing. (FH) Thomas Kuther

Bei autonomen Fahrzeugen auf Level 4 übernimmt das System die Fahrzeugsteuerung auf bestimmten Teilstrecken dauerhaft. Hier ist es hilfreich, über die „Konvergenz“ zwischen Automotive-Systemen und Avionik nachzudenken.

Firmen zum Thema

Bild 1: Auf der Hypervisor-Technologie werden unterschiedliche Betriebssysteme und Anwendungen ausgeführt.
Bild 1: Auf der Hypervisor-Technologie werden unterschiedliche Betriebssysteme und Anwendungen ausgeführt.
(Bild: Lynx Software Technologies)

Das Thema selbstfahrende Autos bleibt spannend, auch wenn die kurzfristigen Perspektiven in einer Post-Corona-Wirtschaft schwierig aussehen. Innovative Entwicklungsarbeit ist im Gange, vor allem was die Autonomiestufe Level 4 betrifft, bei der die Fahrzeugsteuerung auf bestimmten Teilstrecken dauerhaft vom System übernommen wird.

Dieser Beitrag konzentriert sich auf die vollständig zentrale Software-Plattform, die sich enorm nicht nur auf die funktionale und datentechnische Sicherheit (Safety & Security) der kommenden Generation halbautonomer Fahrzeuge auswirken wird, sondern auch auf deren Größe, Gewicht und Leistung. Es ist hilfreich, über „Konvergenz“ zwischen Automotive-Systemen und Avionik nachzudenken.

Für ein Gelingen 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, da fast jeder sich irgendeine Art von Auto leisten und die Reise so gut wie überall beginnen und beenden kann.

Systemarchitekturen werden neu überdacht

Um die erforderliche Flexibilität zu erreichen, liegt ein Hauptaugenmerk darauf, die Kosten, Gewicht und Umfang der Elektronik zu senken, die benötigt wird, um Menschen sicher von A nach B zu transportieren.

Als ich einmal einen führenden Tier-1-Zulieferer besuchte, beeindruckte mich ein Entwickler, auf dessen Schreibtisch eine Haftnotiz klebte, auf der stand: „Was hast du heute getan, um Leistungsverbrauch und Gewicht zu reduzieren?“ Das war vor zehn Jahren: Dieser Entwickler war seiner Zeit weit voraus! Nach dem Motor selbst sind die Elektronik und die Kabelstränge die teuersten und schwersten Bestandteile eines Fahrzeugs.

Systemarchitekturen werden neu überdacht, um zehnfach verkürzte Verkabelungsstrecken von derzeit 1,5+ Kilometern 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:

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

• Eine Verdichtung von Verarbeitungsfunktionen auf weniger, sehr leistungsstarke elektrische Steuerungen (ECUs).

Zum Spektrum unterschiedlicher Netz­werke 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 ist, dass sich, durch Schrumpfung 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 … immer! Menschen­leben (und Firmen­existenzen) 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 Plattformen Intel Xeon und nVidia werden schlichtweg von Lösungen verdrängt, die erheblich geringeren Platzbedarf, Kosten und Stromverbrauch verursachen. Da gibt es ein Wettrennen zwischen einer ganzen Reihe von Unternehmen um den Marktanteils- und Profitabilitätssieg in diesem Segment.

Detailbetrachtung der Verarbeitungssysteme

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

Sehen wir uns jetzt eines dieser Verarbeitungssysteme genauer an. Es enthält heterogene Mehrkernprozessoren, in denen sich Allzweckprozessoren finden, 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.

Die Hypervisor-Ebene muss gleichzeitig 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.

In einigen derzeitigen Software-Komponenten ist deren breite Funktionalität so gestaltet, dass es sich, selbst wenn sie heterogen anmuten, in Wirklichkeit um separate Verarbeitungssysteme handelt, die unterschiedliche Software ausführen.

Der Wechsel hin zu einer dynamischeren Art und Weise, die Verarbeitungsprozesse unterschiedlichen Aufgabenstellungen zuzuteilen, verbunden mit dem Wunsch der Branche, die Bindung an einen bestimmten Anbieter zu verringern, bedeutet, dass diese Systeme zunehmend Hypervisor-Technologie einsetzen und auf ihnen unterschiedliche Betriebssysteme und Anwendungen ausführen.

Warum ein Separation Kernel erforderlich ist

Traditionelle Vorgehensweisen zur Erschaffung virtualisierter Embedded-Software-Architekturen haben 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 Zertifizierung.

Unser Ansatz ist wirklich die Einfachheit. LynxSecure setzt um, dass auf jedem CPU-Kern ausführbare, unabhängige Programme laufen. 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. Es gibt auch keine Speicheränderungen nach dem Hochfahrenmemo oder andere der virtuellen Maschine zugeteilten Arbeitsspeicherressourcen. Es gibt keinen einzigen zentralen Schwachpunkt (Single Point of Failure, SPoF).

Viele Märkte schwanken im Laufe der Jahre zwischen verteilten und zentralisierten Computing-Konzepten. Ich betrachte diesen Schub hin zur Minimierung der Sensorkosten und zur Verlagerung von mehr (nicht sämtlicher) Datenverarbeitung zurück in die lokalisierte Abwicklung als 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 nur minimale Verarbeitungsprozesse. Um sich am Cloud Computing ein Beispiel zu nehmen: Was wäre, wenn diese „Systeme aller Systeme“ (d.h. 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.

Die Normenkonformität ist äußerst wichtig

Die Einhaltung einschlägiger Sicherheitsnormen wie ISO26262 und (zunehmend) ISO21434 ist extrem wichtig, gleichgültig, 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 unserer 30-jährigen Erfahrung im Avionikbereich haben wir gelernt, dass es entscheidend ist, ausführliche Anforderungsspezifikationen aufzusetzen 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, Code aufzuspalten. Entscheidend ist, 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 unserem 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 sowie notwendigen Schutzfunktionen vor unangemessenen Eingriffen, wie sie anspruchsvollste Anwendungen erfordern.

Diesen Beitrag lesen Sie auch in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 3/2021 (Download PDF)

Eine schwierige, aber nicht unmögliche Herausforderung

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 die Entwicklungszeit, Kosten und die endgültigen Kosten an den Kunden bereitgestellt werden. Eine schwierige Herausforderung, aber keine unmögliche.

* Ian Ferguson ist Vice President, Marketing and Strategic Alliances, bei Lynx Software Technologies.

Artikelfiles und Artikellinks

(ID:47062893)