Hard- und Software in Elektrofahrzeugen

Bei Elektrofahrzeugen sind erhebliche Veränderungen bei Hard- und Software erforderlich. (Bild: Shutterstock)

Der Übergang auf Elektrofahrzeuge stellt immer höhere Anforderungen an die elektrische Infrastruktur von Fahrzeugen. Mit der zunehmenden Zentralisierung und dem Zusammenlegen von Funktionen, die von einzelnen Steuergeräten (ECUs) übernommen wurden, werden Multi-/Manycore-CPUs eingesetzt, um eine ausgewogene Mischung aus niedrigem Stromverbrauch, High-Performance-Computing und Energieeffizienz zu erzielen. Die Herausforderung ist, dass diese Aspekte von herkömmlichen Betriebssystemen nicht mehr optimal bedient werden und Entwickler die Bedeutung der Auswahl des richtigen Betriebssystems erkennen müssen. Sie sollten ein Multikernel RTOS in Betracht ziehen, wenn sie die volle Multi-/Manycore-Leistung in den Fahrzeugen von morgen ausschöpfen wollen.

Viele Länder erkennen, dass der Klimawandel ein wichtiges Thema ist, und sehen die breite Einführung von Elektrofahrzeugen als eine Möglichkeit, die Umweltverschmutzung zu reduzieren. Einige Länder haben bereits signalisiert, dass der Verkauf neuer Fahrzeuge mit Verbrennungsmotor in naher Zukunft verboten werden soll.

Dies stellt eine große Herausforderung bei der Entwicklung der elektrischen Infrastruktur von Fahrzeugen dar, da – in Ermangelung eines Antriebsstrangs, der auf einem Verbrennungsmotor basiert – neue Wege gefunden werden müssen, um Generatoren/Lichtmaschinen und Fahrzeugheizungen zu betreiben sowie Infotainment-Systeme zu managen etc.

Der revolutionäre Übergang im Fahrzeugantrieb vom Verbrennungs- hin zum Elektromotor, verbunden mit den Anforderungen des autonomen Fahrens, hat auch zu einer überfälligen Aufrüstung der gesamten elektrisch/elektronischen (E/E) Architektur und dem Aufkommen softwaredefinierter Architekturen (SDA) geführt.

Ein neuer Ansatz für die Entwicklung elektrischer Infrastrukturen

Bei der Entwicklung einer elektrischen Infrastruktur für EVs ergeben sich zahlreiche neue Herausforderungen. Dazu gehören eine optimale Effizienz der elektrischen Energie im gesamten Fahrzeug und ein sicheres Batteriemanagement für maximale Langlebigkeit und Leistungsfähigkeit. So ist es wichtiger denn je, den Zustand einer Batterie zu überwachen, einschließlich Zellenausgleich und Innentemperatur. Sicherheit wird bei EV-Batterien noch wichtiger, da sie mit höheren Spannungen arbeiten als eine 12-V-Blei-Säure-Batterie.

Zentrale elektrische Infrastruktur

Die Elektrifizierung des Antriebsstrangs erfordert ein größeres Augenmerk auf die zentralen elektrischen Infrastrukturen im Fahrzeug. Gleiches gilt für andere Faktoren wie den Trend zum autonomen Fahren und die Einführung einer V2X-Anbindung (Vehicle to Everything). Die Zentralisierung verringert die Zahl separat erforderlicher elektronischer Steuergeräte (ECUs) im gesamten Fahrzeug. Zudem verbessert sich das Leistungs-, Qualitäts- und Kostenverhältnis, da Fahrzeuge zunehmend softwaredefinierter werden. Bei EVs ermöglicht diese Aggregation und Integration von zuvor mehreren Domänen, die Komplexität und das Gewicht der Bordverkabelung zu reduzieren und gleichzeitig Batterieenergie zu sparen. Das Ergebnis ist eine höhere Reichweite.

Diese Entwicklung hin zu einer zentralen Steuerung anspruchsvoller Fahrzeugsysteme hat den Markt für stromsparende Hochleistungsrechner vorangetrieben. Dies führt wiederum zur Entwicklung hocheffizienter, heterogener Prozessoren mit vielen Cores (Manycore), die in der Lage sind, derart unterschiedlich Workloads zu bewältigen.

Skalierbarkeit und Flexibilität

Gleichzeitig sind Skalierbarkeit und Flexibilität in der elektrischen Infrastruktur eines Fahrzeugs wichtiger denn je. OEMs wissen um diese Bedeutung, wenn sie differenzierte Fahrzeugserien kosteneffektiv entwickeln möchten, indem sie eine Vielzahl von Anwendungen und Funktionen auf verschiedenen EV-Modellen ausführen, verschiedene Hardwareplattformen für ihre Produktpalette verwenden und neue Modelle innerhalb kürzester Zeit auf den Markt bringen möchten. Aufgrund der neuen softwarebasierten Entwicklungsstrategie, müssen OEMs permanent Software-Updates over the Air (OTA) – also per Mobilfunk-Datenübertragung – bereitstellen. Da funkbasierte Netzwerke jedoch eine große Angriffsfläche für Hacker bieten, wird die Cybersicherheit zu einem immer wichtigeren Thema. Mit der zunehmenden Autonomie und Datenvernetzung der Fahrzeuge steigt auch das Potenzial für Hackerangriffe, die die Sicherheit des Einzelnen bedrohen und sogar die nationale Sicherheit gefährden.

Bestehende Standards wie ISO 26262 reichen beim autonomen Fahren möglicherweise nicht mehr aus, weshalb neue Standards wie SOTIF (Safety of the Intended Functionality) und UL4600 geschaffen wurden. OEMs und Tier-1-Zulieferer benötigen daher Hard- und Softwarearchitekturen, denen sie vertrauen können, um die vielen Herausforderungen zu meistern, die der neue EV-Markt mit sich bringt.

Die Rolle des Betriebssystems

Während Änderungen an der Hardware eine Sache sind, auf die sich Entwickler konzentrieren müssen, ist die Softwareplattform, die die Hardware und letztendlich das Fahrzeug antreibt, eine andere Sache, die ebenso wichtig ist. Die Architektur des Betriebssystems (OS) ist das Bindeglied zwischen den verschiedenen Funktionselementen eines Fahrzeugs.

Automotive-Softwareplattform, die auf der Autosar Adaptive Platform (Autosar AP) basiert.
Bild 1: Die Softwareplattform der Zukunft muss Sicherheit, Skalierbarkeit und Echtzeit-Determinismus unterstützen. (Bild: eSOL)

Bild 1 beschreibt eine Automotive-Softwareplattform, die auf der Autosar Adaptive Platform (Autosar AP) basiert. Diese Plattform wurde mit Blick auf die Anforderungen moderner E/E-Architekturen in EVs entwickelt und ist für den Einsatz in Systemen vorgesehen, die nach ISO 26262 ASIL-D zertifiziert sind. Durch die Standardisierung der Foundation-Layer-Software und die Umsetzung „geplanter Dynamik“ ermöglicht Autosar AP eine große Anpassungsfähigkeit, ohne Kompromisse bei der Verwaltung sicherheitskritischer Prozesse eingehen zu müssen. Um die geplante Dynamik zu erreichen, muss sichergestellt sein, dass alle Prozesse während der Systemintegration registriert und Berechtigungen zum Starten von Prozessen eingeschränkt werden. Außerdem überwacht Autosar AP die gesamte Kommunikation zwischen Anwendungsprozessen und externer Einheiten nach strengen Richtlinien, die durch die Systemintegration festgelegt werden.

Die serviceorientierte Architektur (SOA) bietet Flexibilität und Transparenz

Die dargestellte Plattform basiert auf einer serviceorientierten Architektur (SOA), die sich besonders für zentralisierte und zonenbasierte elektrische Architekturen eignet, wie sie in EVs zum Einsatz kommen. Die SOA bietet Flexibilität und Transparenz in Bezug auf die Umsetzung und der Hardwarenutzung, da sie verteiltes Rechnen ermöglicht. Dabei wird sichergestellt, dass die Hardware des Software-Servers, der den Dienst bereitstellt, unabhängig von seiner Nutzung ist. Darüber hinaus liefert die Transparenz eine solide Grundlage für Freedom From Interference (FFI) – eines der entscheidenden Merkmale für funktionale Sicherheit. FFI erfordert jedoch physische Mechanismen, wie die Memory Management Unit (MMU) eines Prozessors. Das Betriebssystem bietet durch seine „OS-Prozesse“ eine virtuelle Entsprechung zu diesem Mechanismus um die Dienste und Anwendungen auf eine sichere Art voneinander zu trennen und ihren indirekten Einfluss aufeinander zu entkoppeln.

In der in Bild 1 dargestellten Architektur arbeiten viele Komponenten als Prozesse, und eine häufige Interaktion zwischen ihnen ist unerlässlich, wenn z.B. ein Anwendungsprozess einen Dienst nutzen muss, der als anderer Prozess ausgeführt wird. Während die funktionale Sicherheit traditionell darauf basiert, Prozesse voneinander zu isolieren, schafft Autosar AP als OS-Feature Vertrauen in die Inter-Prozess-Kommunikation. Verglichen mit einer reinen Intra-Prozess-Kommunikation könnte dies aber zu einer schlechteren Leistungsfähigkeit führen und nach Abschluss der Software-Integration auch zu einem erheblichen Leistungsproblem für das System werden.

SDA: Softwaredefinierte Architekturen
Bild 2: Aufbau von modernen softwaredefinierten Architekturen (SDA). (Bild: eSOL)

Multikernel RTOS (verteilte Microkernel) für die Multi-/Manycore-Verarbeitung

Es zeigt sich, dass herkömmliche Betriebssysteme nicht das erforderliche Maß an Funktionalität bieten, um alle Teile einer zentralisierten Hardwarearchitektur zu bedienen und die von EVs geforderte Leistungsfähigkeit aufrechtzuerhalten. Sie sind einfach nicht in der Lage, den Bedarf an ungehinderter Kommunikation zwischen den Prozessen oder die Anzahl der miteinander kommunizierenden Prozessor-Cores in Multi-/Manycore-CPUs zu bewältigen.

Im Gegensatz zu herkömmlichen Systemen ist ein Multikernel RTOS (verteilte Mikrokernel) ideal, um eine große Anzahl miteinander vernetzter Cores und Prozesse zu bedienen. Ein solches System gewährleistet eine schnelle und deterministische Reaktion, die bei Echtzeit-Steuerungsanwendungen in Bereichen wie dem Antriebsstrang unerlässlich ist. Was ein Multikernel RTOS von einem Mikrokernel-RTOS unterscheidet, ist die Beseitigung von Core-übergreifenden Kernel-Sperren, die gleichzeitige Zugriffe verhindern und die Leistungsfähigkeit beeinträchtigen. Eine dezentrale Architektur sorgt dafür, dass die Parallelität gewahrt bleibt.

elektrisch/elektronische Architektur
Bild 3: Aufbau der Hardware für eine elektrisch/elektronische (E/E) Architektur. (Bild: eSOL)

eSOL hat mit eMCOS ein Multikernel RTOS entwickelt, das die Anforderungen der Automotive-Branche an Sicherheit, Skalierbarkeit, Leistungsfähigkeit und Echtzeit-Determinismus erfüllt. Mit diesem Multikernel RTOS lässt sich auf vielfältige Weise skalieren, um kleine oder große Funktionsmengen zu handhaben. Anwendungen können zwischen den Mikrokerneln verbunden werden und Nutzer können die Anpassungsebene an ihre eigenen Anforderungen anpassen. Es eignet sich ideal für den Einsatz mit modernsten Multi-/Manycore-Prozessoren. Es ermöglicht die Ausführung von dynamischem Autosar AP und statischem Autosar CP (Classic Platform) auf demselben Chip, indem Inter-Cluster Message Passing unterstützt wird.

Gleichzeitig liefert ein mehrschichtiger Scheduling-Mechanismus harten Echtzeit-Determinismus und parallel dazu Berechnungen mit hohem Durchsatz auf Basis von Load-Balancing. Standardmäßig werden Multiprozess-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 etc. (na/neu)

Autor

Rolland Dudemaine, Vice President Engineering, eSOL Europe

Kostenlose Registrierung

Bleiben Sie stets zu allen wichtigen Themen und Trends informiert.
Das Passwort muss mindestens acht Zeichen lang sein.
*

Ich habe die AGB, die Hinweise zum Widerrufsrecht und zum Datenschutz gelesen und akzeptiere diese.

*) Pflichtfeld

Sie sind bereits registriert?