Prozessortechnologien, die softwaredefinierte Fahrzeuge realisieren

Seit den 1970er Jahren haben Mikroprozessoren Einzug in die Automobilindustrie gehalten. Damals begannen die Automobilhersteller (OEMs) damit, elektronische Kraftstoffeinspritzsysteme (EFI, electronic fuel injection) und bordeigene Diagnosesysteme zu integrieren. Jahr für Jahr haben sie mehr zur Sicherheit, Effizienz und zum Komfort des Fahrzeugs beigetragen, indem ein oder mehrere Mikroprozessoren in jedes der immer zahlreicheren elektronischen Steuergeräte (ECU) eingebaut wurden. Das Ergebnis ist eine flache Vernetzungsarchitektur und wenig Spielraum für Funktionserweiterungen, nachdem das Fahrzeug einmal fertiggestellt ist. Sowohl Sensorik als auch Aktuatoren für eine Funktion waren mit einem einzigen Steuergerät verbunden. Üblicherweise kommunizierten diese Steuergeräte über einen CAN-Bus mit zentralen Systemen zur Steuerung, Programmierung und Diagnose. Einmal implementiert, wurde die Software nur dann aktualisiert, wenn ein Problem erkannt wurde – ein Prozess, der erheblichen Aufwand, Tests und oft eine Fahrzeugrückrufaktion erforderte.

Wie Smartphones die Automobilindustrie beeinflussen

Doch die Generation der Smartphone-Nutzer beeinflusst heute die Erwartungen an das Produkterlebnis. Verbraucher erwarten nicht länger nur ein fertiges Produkt. Sie suchen vielmehr nach flexiblen Plattformen, die sie auch nach dem Kauf an ihre individuellen Bedürfnisse, Anforderungen und Lebensstile anpassen können. Der traditionelle starre Ansatz des Fahrzeugdesigns von gestern passt nicht zu diesem Anspruch. Die Automobilindustrie sieht sich gezwungen, ihre Herangehensweise an die Fahrzeugelektronik und die Software, die einen Großteil der Funktionen implementiert, zu überdenken.

Derzeit gibt es zwei E/E-Architekturen, die beide dazu dienen, die Anzahl der Steuergeräte zu reduzieren, den Kabelbaum und die Vernetzung zu vereinfachen und Over-the-Air-Updates (OTA) zu ermöglichen. Diese Architekturen bieten auch die notwendige Struktur, um Funktionen wie Sitzheizung ähnlich wie bei einer Smartphone-App nachträglich zu erwerben, lange nachdem das Fahrzeug konfiguriert und an den Kunden ausgeliefert wurde.

Eine dieser Architekturen sind die Domänenarchitekturen, die den heutigen Bezeichnungen für die verschiedenen Domänen des Fahrzeugs folgen. Dazu gehören zum Beispiel Antriebsstrang, Fahrwerk, Bremsen und Karosserie, um nur einige zu nennen (Bild 1).

Eine Funktion, die früher in einem einzigen Steuergerät implementiert war, wird nun gemeinsam mit vielen anderen Domänenfunktionen in einem einzigen Steuergerät mit einem leistungsstarken Multicore-Prozessor integriert (Bild 2).

Die andere Herangehensweise ist eine zonale Architektur. Hierbei spielt die Position der Steuergeräte eine größere Rolle, da eine begrenzte Anzahl von Hardware-Boxen im Fahrzeug jeweils in der Nähe der installierten Sensoren und Aktuatoren platziert ist. Auch in diesem Fall sind die Steuergeräte mit leistungsstarken Multicore-Prozessoren ausgestattet, die über redundante Highspeed-Vernetzung verfügen und somit für Echtzeitsteuerung geeignet sind. Sie tauschen Daten mit anderen zonalen Steuergeräten aus. Eine Schlüsselrolle spielen dabei ein Hochleistungsrechner (HPC, high-performance computer) sowie ein Telematik-Gateway, das die Internet-Konnektivität bereitstellt.

Domänenarchitekturen erlauben sozusagen eine schrittweise höhere Integration, während zonale Architekturen den traditionellen Ansatz der Softwareentwicklung umkehren. Dies liegt daran, dass Funktionen wie beispielsweise die Steuerung von Scheinwerfern und Blinkern über die zonalen Steuergeräte verteilt sind, anstatt in einem einzigen Gehäuse untergebracht zu sein. Diese Funktionen werden als virtuelle Steuergeräte auf leistungsstarken Multicore-Prozessoren implementiert.

Für sowohl Domänen- als auch Zonenarchitekturen bedeutet das auch, dass Software, die unterschiedliche Automotive Safety Integrity Levels (ISO 26262 ASIL) erfüllt, gleichzeitig auf demselben Prozessor arbeiten muss, ohne sich im Falle eines Fehlers gegenseitig zu beeinträchtigen. In der Automobilindustrie wird dies als „Interferenzfreiheit" bezeichnet. Unabhängig von der verwendeten Architektur wird deutlich, dass die Software im Zentrum der Definition der Fahrzeugfunktionen steht – und ein zentraler Aspekt dabei ist die Virtualisierung.

Virtualisierung hat entscheidend zum Erfolg des Cloud Computing beigetragen. Hierbei werden mehrere Betriebssysteme parallel auf einem einzigen Server ausgeführt, wodurch viele Nutzer dessen Ressourcen teilen können. Die sogenannte Bare-Metal-Virtualisierung erfolgt auf der untersten Ebene der Serverhardware. Dabei ist ein installiertes Gastbetriebssystem „unwissend“ darüber, dass es virtualisiert wird, Hardwareressourcen gemeinsam genutzt werden oder parallel andere Betriebssysteme laufen. Die Virtualisierungsplattform, die als Hypervisor bekannt ist, fängt im Wesentlichen die Aufrufe des Betriebssystems ab und übersetzt sie in das virtualisierte System, zum Beispiel für Zugriffe auf Festplatten und Speicher. Gleiches gilt für Hardware-Schnittstellen, wie Ethernet-Verbindungen.

Wie erwartet, geht die Virtualisierung mit einem gewissen Overhead einher, wenn sie Hardwarezugriffe verarbeitet. Um dem entgegenzuwirken, können Entwickler den alternativen Ansatz der Paravirtualisierung wählen. Dabei werden die Zugriffe auf die Hardwareressourcen in Software implementiert, ähnlich wie es bei nur einem Betriebssystem der Fall wäre. Dies führt zu einer höheren Leistung im Vergleich zur reinen Virtualisierung, aber der Nutzen variiert je nach Arbeitslast und erfordert eine entsprechende Anpassung der Betriebssysteme. Eine solche Varianz ist für die Echtzeit-Steuerung in der Automobilindustrie jedoch nicht akzeptabel.

Echtzeitprozessoren für virtualisierte Betriebssysteme

Prozessoren für Automobilanwendungen müssen solche Herausforderungen meistern. Ein Entwicklungsingenieur erwartet beispielsweise, dass die General Purpose I/O-Pins (GPIO) über eine Reihe von umfassenden Registern konfiguriert und gesteuert werden können. Jedes Bit in diesen Registern ist verantwortlich für Einstellungen wie Richtung, Verwendung von Pull-ups, Steuerung der Ausgänge und Übermittlung des Status der Eingänge. Jedes dieser Register hat eine eigene Speicheradresse. Daher können typische Speicherschutzmechanismen einzelne Bits eines Registers nicht einer bestimmten Betriebssysteminstanz zuordnen. Deshalb muss der Hypervisor diese Zuordnungsaufgabe in Software erledigen.

Der NXP S32Z und der NXP S32E bieten eine Lösung, die auf diese Anforderung eingeht und die Core-to-Pin-Virtualisierung für beliebige Kombinationen von GPIO-Pins durch jedes Gastbetriebssystem unterstützt. Realisiert wird das durch zusätzliche Hardware, die während des Systemstarts die erforderlichen GPIO-Pins einem bestimmten Client-Betriebssystem oder einer Systempartition zuweist. Da die Zuweisung auf Hardware-Ebene umgesetzt wird, entfallen die mit der Virtualisierung typischerweise verbundenen Leistungseinbußen. Durch die Partitionierung auf Hardware-Ebene sieht jedes Betriebssystem im Wesentlichen nur seine eigenen GPIOs, wodurch eine Paravirtualisierung praktisch überflüssig wird.

Die ASIL-Zertifizierung wird auch durch die Unterstützung der Virtualisierung auf Hardwareebene vereinfacht. Hardwareausfälle betreffen nur das zugehörige Betriebssystem und seine Anwendung, sodass eine einzelne virtuelle Maschine sich selbst zurücksetzen oder neu starten kann, ohne andere Betriebssysteme oder Hardwarekonfigurationen auf dem Gerät zu beeinflussen. Abgestürzte Prozesse haben keine Auswirkungen auf andere Teile des Systems. Ein weiterer Aspekt der Lösung sind Mechanismen, um auch Bandbreite und Leistung der einzelnen Prozesse zu gewährleisten.

Der Core-to-Pin-Zugriff auf GPIO-Ressourcen ist nur eine der Funktionen der S32E- und S32Z-Familie von Echtzeitprozessoren, die speziell auf die Anforderungen softwaredefinierter Fahrzeuge zugeschnitten sind. Die 24 FlexCAN-FD-Netzwerkschnittstellen können gekennzeichnet und so bestimmten Gastbetriebssystemen zugewiesen werden, um den Software-Overhead zu minimieren. Doch das ist nicht alles. CAN-Netzwerke können besonders viele Interrupts generieren, was zu vielen Kontextwechseln führt und es schwierig macht, die Echtzeitanforderungen im restlichen Anwendungscode zu erfüllen.

Um die Echtzeitanforderungen zu gewährleisten, sind die CAN-Peripherieblöcke Teil eines dedizierten FlexLLCE mit zwei dedizierten Arm Cortex-M33 Lockstep Cores und 768 KB SRAM (Bild 3). Zusätzlich wird der neue CAN-XL-Standard im Connectivity/Interface-Block unterstützt. CAN-XL bietet Datenraten von bis zu 20 Mbits/s und ein größeres Datenfeld von 2048 Bytes. Der Standard ist sowohl interoperabel mit CAN-FD-Netzwerken als auch in der Lage, Protokolle höherer Schichten wie das Internetprotokoll (IP) zu tunneln. Diese Funktion wird vermehrt genutzt, da Automotive-Ethernet als Backbone in Fahrzeugen immer mehr Verwendung findet.

Außerdem beinhaltet die Automotive-Ethernet-Funktionalität zwei 10/100/1000Mbit-Schnittstellen und einen Ethernet-Switch, der in einen Ethernet Acceleration Block integriert ist. Künftig werden Prozesse, die Fahrzeugfunktionen steuern, über Ethernet Befehle an Softwareprozesse übermitteln, die entweder die Steuerung umsetzen oder Sensordaten liefern. Interessanterweise können diese Funktionen auf derselben Prozessorhardware, jedoch auf unterschiedlichen virtuellen Steuergeräten, ablaufen. Der integrierte Ethernet-Switch emöglicht auch den Datenaustausch zwischen virtuellen Steuergeräten auf demselben Prozessor. Das bedeutet, dass über Ethernet kommunizierende Softwarefunktionen entwickelt werden können, ohne die genaue Position der zugehörigen Software auf demselben Start1Prozessor oder auf einem anderen Zonalcontroller im Netzwerk zu berücksichtigen.

Software für das softwaredefinierte Fahrzeug entwickeln

Die Art und Weise, wie im Automobilbereich Software entwickelt wird, muss sich ebenfalls ändern. Besonders deutlich wird dieser Bruch mit der Tradition bei den Fahrzeug-OEMs. Es gilt sicherzustellen, dass die benötigten Funktionen präzise definiert sind und dass die gewählte Prozessor-Hardware die erforderliche Leistung bietet, um die heutigen und künftigen Erwartungen der Fahrer während der gesamten Lebensdauer des Fahrzeugs zu erfüllen (Bild 4).

Tier-1-Zulieferer werden ebenfalls eine große Rolle spielen, da sie ein umfassendes Verständnis der verschiedenen Fahrzeugdomänen und ihrer bisherigen Implementierung haben. Weiter unten in der Lieferkette ist es wahrscheinlicher, dass die Tier 2/3-Zulieferer weniger Veränderungen feststellen werden als der Übergang zur Entwicklung von Software für virtuelle Steuergeräte anstelle von Hardware-Steuergeräten. Sie werden Zugriff auf ein Betriebssystem und Peripheriegeräte haben, ohne genau zu wissen, welche anderen Anwendungen auf der selben Hardware laufen. Es könnte sein, dass solche Entscheidungen noch gar nicht endgültig getroffen wurden, wenn die Zulieferer eingebunden werden. Das verdeutlicht die Flexibilität des softwaredefinierten Ansatzes.

Entscheidend ist, dass die gewählten Prozessoren sowohl ausreichend Leistung für heute bieten als auch Spielraum für zukünftige Entwicklungen lassen und darüber hinaus sichere OTA-Updates unterstützen können. Der S32E und der S32Z verfügen über acht Arm Cortex-R52-Kerne, die mit bis zu 1 GHz arbeiten und im 16-nm-Herstellungsprozess gefertigt werden – mit einer geplanten Roadmap zum 5-nm-Prozess. Diese Kerne können flexibel als Einzel- oder Lockstep-Configurations eingerichtet werden, um die Sicherheitsanforderungen der ausgeführten Funktionen zu erfüllen. Zusätzlich gibt es einen 25 GFLOPS DSP/Machine-Learning-Prozessor, um Advanced Driver Assistance Systems (ADAS) und autonome Fahrfunktionen zu unterstützen.

Eine Hardware Security Engine (HSE), die gemäß ISO 21434 zertifiziert ist, bietet kryptografische Beschleuniger für sichere Kommunikation und digital signierte Software-Updates, die über eine Public Key Infrastructure (PKI) gemeinsam genutzt werden.

Von außen betrachtet bleiben Autos nach wie vor mechanische Meisterwerke – von ihrem Design und ihrer Form bis hin zu ihren Sitzen und ihrer Motorisierung. Aber alles andere, von der Fortbewegung bis hin zu den Funktionen, die den Insassen geboten werden, wird von Software gesteuert, die mit unsichtbarer Elektronik gekoppelt ist. Die Automobilbranche war schon immer ein herausfordernder Markt, der mehr verlangt als nur die schnellsten Prozessoren, die die Halbleiterindustrie bereitstellen kann. Hier sind Produkte gefragt, die umfassende Zuverlässigkeits- und Sicherheitsanforderungen erfüllen.

Eine neue Art von Echtzeitprozessoren ist nötig, da die für das softwaredefinierte Fahrzeug erforderlichen Systemarchitekturen auf Ansätzen basieren, die typischerweise mit Cloud Computing in Verbindung gebracht werden (z. B. Virtualisierung). Bausteine wie die S32E- und S32Z-Familien, die eine granulare Hardware-Zuweisung von Core zu Pin und somit virtualisierte Steuergeräte unterstützen, werden grundlegenden Bestandteilen der neuen E/E-Architekturen im Automobilbereich. Dadurch können OEMs ihre Hardware konsolidieren und Smartphone-ähnliche Funktionen, Apps und OTA-Updates anbieten, ohne dabei die Zuverlässigkeit und Sicherheit zu beeinträchtigen, auf der ihre Marken aufbauen. (na)