Multikernel-OS Ein Automotive-Betriebssystem für neue Herausforderungen

Anbieter zum Thema

eSOL

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Zukünftige Fahrzeugsysteme müssen harte Echtzeitfähigkeit mit hoher Rechenleistung kombinieren. Das erfordert eine wesentliche Änderung auf der Betriebssystemebene.

Vernetzte, autonome und nachhaltige Mobilität ist eine verlockende Vision, die alle Automobil-Innovatoren stark unter Druck setzt. Bordsysteme kommender Fahrzeuge müssen hohe Rechenleistung erbringen und gleichzeitig harte Echtzeitfähigkeit zur Verfügung stellen. Dies kann durch die Hardware trotz performanter Mehrkernprozessoren nur teilweise erfüllt werden. Damit ein Automotive-Betriebssystem eine verteilte Mikrokernel-Architektur ordentlich unterstützen kann, ist eine grundlegende Änderung des OS Betriebssystems nötig.

Disruptive Entwicklungen im Automobilmarkt wie Konnektivität, autonomes und automatisiertes Fahren, Mobilität als Dienstleistung und Elektrifizierung des Antriebsstrangs stellen Hochleistungsanforderungen an die großen Fahrzeugrechner, die aber gleichzeitig stromsparend sein müssen. Diese Hochleistungsrechner müssen mit einer Anzahl kleinerer Steuergeräte koexistieren, die die traditionellen Karosserie-, Chassis-, Antriebs- und andere elektrische Systeme des Fahrzeugs steuern. In der Vergangenheit gab es Premium-Autos mit bis zu 100 Steuergeräten, die jeweils für eine bestimmte Funktion optimiert waren.

Diese elektrische/elektronische (E/E) Architektur der Fahrzeuge ändert sich gerade, da immer umfangreichere Funktionen eingeführt werden. Verteilte Steuergeräte verschmelzen zu größeren Domänencontrollern, um die Komplexität der Fahrzeugverkabelung, das Gewicht und vor allem rapide steigenden Entwicklungskosten zu kompensieren. Zunehmend aggregieren zentralisierte Hochleistungsrechner mehrere Steuergeräte über Domänengrenzen hinweg. Dies wiederum führt zu einer neuen Kategorie von Prozessoren, die mit vielen, heterogenen Kernen die leistungsfähigste und energiesparendste Lösung darstellen, um gleichzeitig die alten, bereits vorhandenen Funktionen zu integrierten und die neuen, sehr rechenintensiven Aufgaben, zur bewältigen.

Zusätzlich erhöhen insbesondere Konnektivität und das automatisierte Fahren die Nachfrage nach neuen Sicherheitsstandards. Mittlerweile ist es eine Frage der nationalen Sicherheit, kriminelle Angreifer daran zu hindern autonome Fahrzeuge zu hacken. Etablierte Sicherheitsstandards wie ISO 26262 reichen für neue Anwendungsfälle, wie z.B. dem autonome Fahren, nicht aus. Es werden gerade neue Standards wie SOTIF (Safety Of The Intended Functionality) und UL4600 entwickelt, um diesen Anwendungen gerecht zu werden.

Um die Dinge noch schwieriger zu machen, erfordert die öffentliche Akzeptanz zum Thema „sicheres autonomes Fahren“, eine Diskussion über die Begriffe „Festgelegten Betriebsbereich“ (Operational Design Domain, ODD) und „Überwachung des Verkehrsgeschehens und der Fahrzeugsteuerung“ (Object Event Detection and Response, OEDR) von autonomem Fahrsystemen (Automated Driving Systems, ADS). Diese Diskussion ist aber sehr OEM-spezifisch und eng an dessen zukünftiger Fahrzeugspezifikation gebunden und wird deswegen von allen OEMs nicht öffentlich geführt.

Um den verschärften Sicherheitsherausforderungen gerecht zu werden, benötigen OEMs und Zulieferer komplette Hardware- und Software-Architekturen, die ihnen bei der Überwindung dieser Hürden helfen. Diese Architekturen müssen hoch skalierbar sein damit differenzierte Modellreihen gefertigt werden können. In der Automobilproduktion großer OEMs kann die Unterscheidung zwischen einem A-Segment- und einem F-Segment-Modell nicht nur durch einen Softwareschalter umgesetzt werden. Um die Kosten bei großen Modellfamilien unter Kontrolle zu halten, muss die Hardware und Software der E/E-Architektur skalierbar sein.

Erweiterung der Software-Architektur

Im Grunde genommen haben die OEMs die Aufgabe, Systeme zu entwickeln, die eine noch nie dagewesene Kombination aus Hochleistung, Energieeffizienz, Echtzeit (Determinismus), Kosteneffizienz und Sicherheit bieten. Und als ob die Skalierung heterogener Steuergeräte nicht schon schwierig genug wäre, wird diese Herausforderung noch dadurch weiter verschärft, dass diese Systeme für die harten Anforderungen der automobilen Massenproduktion geeignet sein müssen.

Um alle diese Herausforderungen an die E/E-Architektur des Fahrzeugs zu bewältigen, kann man nicht nur die Hardware-Plattform verbessern, sondern muss auch die Software-Plattform mit einbeziehen. Dies gilt insbesondere für die Basis aller Softwarefunktionen, dem Betriebssystem, das die Anwendungssoftware mit der Hardware verbindet.

In der Automobilindustrie wird heute eine Vielzahl von Ansätzen und Software-Plattformen verwendet. Neben Plattformen, die wie AUTOSAR auf Automotive-Standards basieren, gibt es auch Open-Source-Software-Plattformen (OSS), z.B. Linux, sowie verschiedene proprietäre Plattformen, die von OEMs, Tier 1s und unabhängigen Anbietern entwickelt und gepflegt werden. Alle unterscheiden sich typischerweise in Bezug auf Softwareschichten und Funktionsbereiche, die sie abdecken.

Bild 1 beschreibt eine Softwareplattform für die Automobilindustrie, die auf einer serviceorientierten Architektur (SOA) basiert. Sie ist für den Einsatz in E/E-Architekturen mit Domänencontrollern oder den neuen zonenbasierten Architekturen geeignet.

Die SOA bietet eine flexible Plattform, um neue autonome Fahrfunktionen wie Fahrspurerkennung, Objekterkennung und Fahrerstatusüberwachung als Software­dienste bereitzustellen, auf die dann eine übergeordnete Softwareeben über Standardschnittstellen zugreifen kann. Darüber hinaus bietet die SOA Transparenz in Bezug auf die Zuordnung, da der Standort des Servers, der einen Dienst zur Verfügung stellt, unabhängig von dessen Nutzung ist. Dies ist der Schlüssel zur Anwendung des Modells des verteilten Rechnens. Außerdem sorgt die SOA für Transparenz bei der Implementierung, indem sie ein konsistentes Interface beibehält, unabhängig davon, wie der Service innerhalb des Servers umgesetzt wird.

Die gezeigte Architektur basiert auf dem AUTOSAR Adaptive Platform Standard (AUTOSAR AP), der die Software der unteren Schicht standardisiert und eine „geplante Dynamik“ ermöglicht. Im Gegensatz zu einer vollständig offenen SOA-Architektur, handelt es sich hierbei um ein Konzept, dass eine große Anpassungsfähigkeit erlaubt, ohne dabei die Handhabung sicherheitskritischer Prozesse zu beeinträchtigen. Geplante Dynamik wird durch verschiedene Maßnahmen erreicht, wie z.B. dass alle Prozesse während der Systemintegration registriert werden müssen und die Privilegien zum Starten von Prozessen eingeschränkt werden. Auch die Kommunikation zwischen Anwendungsprozessen und externen Entitäten wird nach strengen Richtlinien verwaltet, die bereits während der Systemintegration festgelegt werden. Mit Hilfe einer standardisierten Prozess- und Werkzeugkette muss das Softwareteam alle Prozesse, ihre Rechte, ihre Interaktionen (d.h. die Bereitstellung oder Nutzung eines Dienstes), ihre Sicherheitsrechte usw. beschreiben. Ein einfaches Beispiel: in einem Auto könnte es drei Fahrkonfigurationen wie „manuelles Fahren“, „autonomes Fahren“ und „automatisches Parken“ geben. In jeder dieser drei Konfigurationen dürfen jeweils unterschiedliche Anwendungen mit unterschiedlich aktiven Überwachungsdiensten laufen.

Störfreiheit und Interprozess-Kommunikationen

Eines der zentralen Konzepte der funktionalen Sicherheit ist die „zeitliche Störfreiheit“ (Freedom from interference, FFI). Die AUTOSAR Adaptive Plattform bietet eine gute Grundlage für eine SOA-Architektur, die insbesondere FFI abdeckt, da verschiedene Funktionalitäten einer Plattform in meist unabhängige Services aufgeteilt und wiederum von meist unabhängigen Anwendungen genutzt werden. Das bietet zwar eine gute logische Software-Architektur, aber die eigentliche Garantie für FFI muss durch Hardware-Mechanismen wie die Memory Management Unit (MMU) des Prozessors gewährleistet werden. Das Betriebssystem virtualisiert diesen Mechanismus in Form von Betriebssystemprozessen, die die Instanzen der Dienste und Anwendungen darstellen. Die FFI ist für die Sicherheit unerlässlich.

Wie man in Bild 1 sehen kann, laufen viele der Komponenten als Prozesse. Diese müssen tatsächlich sehr häufig miteinander interagieren. Wenn z.B. ein Anwendungsprozess einen Service nutzen will, der als separater Prozess läuft, müssen das beide vorher miteinander kommunizieren. Das Betriebssystem stellt für diese Interaktionen besondere Funktionen zur Interprozess-Kommunikationen (inter-process communication, IPC) zur Verfügung. Allerdings müssen zwei Prozesse, die ursprünglich aus Sicherheitsgründen voneinander isoliert wurden, diese Sicherheitsgrenze nun überschreiten, um miteinander Daten austauschen zu können. Das benötigt jetzt deutlich mehr Verarbeitungszyklen als eine prozessinterne Kommunikation. Und das entwickelt sich schnell zu einem erheblichen Problem für die Systemleistung, wenn die gesamte Software auf einem Steuergerät integriert wird.

Durch den rapide zunehmenden Einsatz von Mehrkernprozessoren, wird die schnelle Kommunikation zwischen den Kernen immer wichtiger. Auf Chip-Ebene haben sich bereits Hochgeschwindigkeits-Netzwerke (high-speed network-on-chip, NoC) durchgesetzt, die eine schnelle und latenzarme Kommunikation zwischen den Kernen unterstützen. So führen all diese Aspekte bei Hochleistungsrechner im Fahrzeug zu einer Nachfrage von schnellen IPCs, bei der die gesamte Software auf einer großen Anzahl von miteinander kommunizierenden Prozessorkernen arbeiten kann. Hier werden die traditionellen Single-Core-Betriebssysteme immer weniger in der Lage sein, alle Teile des Systems angemessen zu unterstützen, um die benötigte Leistung zur Verfügung zu stellen.

Multikernel-OS für Multicore-Hardware

Eine Multikernel-Betriebssystem-Architektur, auch als verteiltes Mikrokernel-Betriebssystem bezeichnet (untere Schicht von Bild 1), ist am besten dazu geeignet, eine große Anzahl miteinander verbundener Kerne und Prozesse zu bedienen. Da sich die Fahrzeugarchitekturen immer weiter entwickeln werden, hat eSOL ein solches Multikernel-Betriebssystem mit dem Namen eMCOS (embedded multi-core OS) entwickelt, um die erforderliche Leistung und Skalierbarkeit zu bieten.

Zusätzlich zur Skalierbarkeit für kleine oder große Funktionsgruppen, bietet dieses verteilte Mikrokernel-Betriebssystem auch schnelle und deterministische Reaktionen für Echtzeitsteuerungsanwendungen, wie z.B. für die verschiedene Stufen des autonomen Fahrens. Das Betriebssystem kann auf vielfältige Weise skaliert werden: Anwendungen können zwischen den Mikrokernels verbunden werden und Entwickler können die Anwendungsprogrammierungsschicht an ihren jeweiligen Zweck anpassen.

Das Multikernel OS (verteiltes Mikrokernel OS) unterscheidet sich von herkömmlichen Mikrokernel OSes. Da keine globalen Kernel-Blockierungen mehr notwendig sind, um die Echtzeitfähigkeit während der IPCs zu gewährleisten, stellt diese Architektur sicher, dass die Parallelität und damit die maximale Leistungsfähigkeit erhalten bleibt.

eMCOS ermöglicht durch einen besonderen Zeitplanungsmechanismus auf zwei Ebenen sowohl einen harten Echtzeit-Determinismus als auch Hochleistungsperformanz auf Basis von Lastverteilung zwischen den Kernen. Vergleichstests zeigen, dass diese Architektur auf Multi-Core- oder Multi-Chip-Hardware viel mehr Leistung bringt als bestehende Betriebssystem Architekturen, die auf Techniken wie SMP, AMP und deren Mischkonfiguration setzen.

Von eMCOS werden standardmäßig Multi-Prozess-POSIX- und AUTOSAR-Programmierschnittstellen unterstützt, und es gibt spezielle APIs für Funktionen wie Distributed Shared Memory (DSM), Fast-Messaging, NUMA-Speicherverwaltung, Thread-Pool und andere, die nicht im Rahmen dieses Artikels behandelt werden können.

Bild 2 zeigt ein Beispiel wie die verteilte Mikrokernel-Architektur ein heterogenes Hardwaresystem aus GPGPU, FPGA, Many-Core und sogar MCU unterstützt. Ein solches SOA System unterscheidet nicht, ob die Software auf einem einzigen Chip läuft oder durch die Kommunikation von mehreren Chips realisiert wurde. Es spielt auch keine Rolle ob die Chips dabei über ein Netzwerk zwischen verschiedenen ECUs kommunizieren.

Unterstützung von Manycore-Hardware

Zusätzlich zu den vielen Varianten von MCU-Architekturen, Arm-basierten Mehrkernprozessoren, Dual-Cores bis hin zu Octa-Cores wird eMCOS auch in sogenannten Manycore-Prozessoren eingesetzt. Ein Beispiel dafür sind die neuesten Coolidge MPPA Chips (Massively Parallel Processor Array) von Kalray. Diese Chips besitzen 80 Kerne und können sowohl in den neuen E/E-Architekturen als auch in den schnell wachsenden Bereichen des Edge-Computings und der KI eingesetzt werden: moderne Rechenzentren, Netzwerke (5G), Luft- und Raumfahrt, Gesundheitsausrüstung, Industry 4.0, Drohnen und Roboter.

Das eMCOS Betriebssystem lässt auf dem Coolidge Chip gleichzeitig AUTOSAR Classic Platform (CP) und AUTOSAR Adaptive Platform (AP) laufen (Bild 3), wodurch Anwendungen hohe Geschwindigkeit und Echtzeit-Determinismus mit geringem Stromverbrauch kombinieren können. Auf den äußeren I/O-Clustern laufen mehrere eMCOS AUTOSAR und AUTOSAR CP Instanzen, während auf den zentralen Rechenclustern eine Instanz von AUTOSAR AP auf eMCOS POSIX läuft. Die CP- und AP-Instanzen kommunizieren über die schnelle eMCOS IPC Schnittstelle.

In Zukunft werden neue Chiptechnologien die Hardware noch weiter in Richtung heterogener Manycore-Computer verändern. Aussichtsreiche Kandidaten sind hier 3D-Stapel-Chiplets. Hierbei werden mehrere Chips übereinandergestapelt und durch schnelle Durchkontaktierungen aus Silizium verbunden, um immer mehr Rechenleistung zur Verfügung zu stellen und dabei gleichzeitig die Kosten zu reduzieren.

Die Wahl der OS-Plattform ist entscheidend für die Zukunft

Konnektivität, autonomes Fahren, Mobilitätsdienste und Elektrofahrzeuge sind wichtige Automobiltrends, die die Erwartungen an fahrzeuginterne Hochleistungsrechner und verbesserte E/E-Architekturen erhöhen. Gleichzeitig kommen zusätzliche Sicherheitsherausforderungen auf uns zu.

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

OEMs brauchen jede Hilfe, um mit diesen gestiegenen Anforderungen umgehen zu können und gleichzeitig noch eine akzeptable Markteinführungszeit für neue Features und Modelle zu erreichen. Die Software-Plattform ist ein entscheidendes Element, um alle diese Herausforderungen zu bewältigen. Skalierbarkeit ist unerlässlich und Software, die auf einer serviceorientierten Architektur (SOA) basiert, ist dabei der bewährteste Ansatz. Ein Multikernel OS (verteiltes Microkernel OS) ist am besten geeignet, um zukünftige Hardwarearchitekturen auf Basis von Multicore-Prozessoren zu unterstützen und gleichzeitig eine SOA mit einer sehr schnellen Nachrichtenübermittlung zwischen den CPU-Kernen oder Steuergeräten zu unterstützen.

„Klein UND groß“: Moderne Anforderungen an ein Embedded OS

Manycore-RTOS und smartes Scheduling für IoT-Anwendungen

* Masaki Gondo ist CTO und Vice President bei eSol.

(ID:47074509)