Software-definierte Architekturen im Nutzfahrzeug

Die klassische verteilte Architektur aus vielen einzelnen Steuergeräten (Electronic Control Unit, kurz: ECU) bremst Innovationen im Fahrzeug. Wegen der Vielzahl an vernetzten ECUs und ihrer Software sind solche Architekturen derart komplex, dass sie beschleunigte Entwicklungszyklen nicht mehr unterstützen können. Die Lösung liegt in einer stärker zentralisierten elektrischen/elektronischen Architektur (E/E-Architektur) mit wenigen leistungsstarken Hochleistungsrechnern (High-Performance Computer, kurz: HPC), die als Host für Hardware-unabhängige Software dienen, Natürlich setzt dieser Architekturwechsel geeignete neue Hardware voraus.

Ein HPC für eine Software-definierte Architektur muss ganz andere Anforderungen erfüllen als eine dedizierte ECU mit einer Embedded-Lösung. Als zentraler Bestandteil einer Software-definierten Architektur aus HPC – also dem Server – und Zonen-Steuergeräten hosten HPCs die Fülle an Funktionssoftware, und sorgen für die zentrale Datenverarbeitung. Sie ermöglichen Over-the-Air (OTA)-Updates und -Upgrades, die Vernetzung und Kommunikation des Fahrzeugs mit der Cloud sowie die Cybersecurity. Ist diese Hardware einmal installiert, kann Innovation in Form von Software erfolgen, ohne dass die Hardware erneut „angefasst“ werden muss. Völlig neue Lösungen und Anwendungen lassen sich dann ausschließlich durch Software verwirklichen, die zum Teil im Fahrzeug läuft und/oder im Backend (Bild 1).

Auch im Nutzfahrzeug stößt die bisherige E/E Architektur an ihre Grenzen. Um schneller zu werden und sich von den bisher üblichen langen Hardware-Zyklen zu lösen, wollen Truckhersteller mit einer konsequenten Trennung von Hardware und Software neue Einsparpotenziale im Nutzfahrzeug eröffnen. Beim Übergang zum Software-definierten Fahrzeug (Software-defined Vehicle, kurz: SDV) geht es Nutzfahrzeugherstellern klar um Wirtschaftlichkeit.

Wie steigern Software-definierte Architekturen die Wirtschaftlichkeit?

Nutzfahrzeuge, etwa das Segment der Transportfahrzeuge aller Größenklassen, sind bereits hocheffizient im Hinblick auf den Kraftstoffverbrauch und CO₂-Ausstoß. Quantensprünge auf Ebene des einzelnen Fahrzeugs sind in diesem Bereich deshalb nicht mehr zu erwarten. Ganz anders sieht es aus, wenn man die Perspektive größer zieht und den Lkw als einen Bestandteil einer umfassenden Logistikkette betrachtet (Bild 2).

In dieser Gesamtschau liegt noch erhebliches Optimierungs- und damit Einsparpotenzial. Für eine möglichst effiziente Logistikkette werden laufend aktuelle Daten aus dem Fahrzeug benötigt, die von Systemen – und damit von Software – im Backend der Flottenbetreiber ausgewertet und zur Planung genutzt werden. Eine bidirektionale Verbindung zwischen Fahrzeug und Backend spielt also eine Schlüsselrolle. Allerdings muss das Nutzfahrzeug zunächst einmal dafür ertüchtigt werden, benötigte Daten aus Teilsystemen (über Domänengrenzen hinweg) überhaupt zur Verfügung stellen und teilen bzw. Daten annehmen und verarbeiten zu können. Höhere Effizienz verlangt also nach Software sowie Vernetzung von der Cloud bis zum Sensor im Truck.

Ein SDV mit einer service-orientierten Architektur macht es beispielsweise möglich, einen Digital Twin des Trucks zu erzeugen, diesen laufend mit aktuellen (Sensor-)Daten zu befüllen und dieses virtuelle Modell des physischen Fahrzeugs für die vorausschauende Wartung zu nutzen. Mit der frühzeitigen Planung von Reparaturen lassen sich Stillstandzeiten verkürzen, die sonst durch wirtschaftlich problematische Liegenbleiber entstehen können.

Bis heute basiert die dezentralisierte Architektur im Nutzfahrzeug auf dem Prinzip „eine Funktion, eine ECU“. Eine solche E/E-Architektur ist starr, denn neue Funktionen lassen sich hier ja nur durch Hinzufügen einer neuen ECU oder Austausch einer alten integrieren. Das aber ist aufwändiges Stückwerk und bleibt im Nutzfahrzeug den Plattformwechseln alle sieben bis acht Jahre vorbehalten. Die herkömmliche E/E-Architektur kann die schnellen Innovationszyklen der Software nicht einmal näherungsweise mitgehen. Es ist heute kaum machbar, neue Funktionen mit der Aussicht auf eine wirtschaftlichere Nutzung des Nutzfahrzeugs zeitnah ins Fahrzeug zu bringen. Damit droht das Nutzfahrzeug vom Fortschritt abgehängt zu werden. „Code to Road“ ist aktuell noch eine Vision. Abhilfe schafft nur die Software-definierte Architektur.

Auch für komplexe, hochautomatisierte Fahrfunktionen hat eine Software-definierte Architektur mit HPC, Vollvernetzung und großer Rechenpower viele Vorteile, etwa eine erhöhte Ausfallsicherheit bzw. eine optimierte Systemperformance. Aus technischer Sicht spricht also auch bei Trucks viel für das SDV. Continental bereitet mit seinem Partner Aurora für US-Trucks ein kommerziell skalierbares autonomes Lkw-System vor. Die gesamte Hardware und das Rückfallsystem des „Aurora Driver“ sind von Continental.

Eine service-orientierte Architektur schafft die Voraussetzung dafür, im Nutzfahrzeug wirtschaftlicher zu werden. Diese Migration kann schrittweise erfolgen, um die Aufwände in Grenzen zu halten. Die Ausgangssituation für die Migration zum SDV war nie günstiger: Mit dem modularen Continental Automotive Edge (CAEdge)-Framework steht Entwicklerinnen und Entwicklern eine automatisierte und effiziente Umgebung für softwareintensive Fahrzeugarchitekturen zur Verfügung, mit der Softwareprojekte schneller als bisher umgesetzt werden können. So lässt sich beispielsweise ein virtueller HPC in einer Cloud-Umgebung nutzen, um Software in einer frühen Phase vor dem Einsatz auf der physischen Hardware zu testen (Bild 3). Durch die Automatisierung von Testfunktionen sinkt gleichzeitig die Entwicklungszeit. Diese bewährte Technologie aus der Migration zu Software-definierte Architekturen im Pkw bedeutet für die Migration im Nutzfahrzeug einen wertvollen Vorsprung.

Die erfolgreiche Umstellung auf eine solche Architektur beginnt idealerweise mit einer sehr frühen gemeinschaftlichen Entwicklung, bei der Truck-OEMs und Architekturentwickler ebenfalls möglichst früh ein Proof-of-Concept erstellen. Dabei helfen HPC Development Kits, Funktionen und Software mit Automotive-grade Hardware und Software zu validieren. Alle Beteiligten arbeiten dabei gemeinsam in einem strukturierten Prozess unter Anwendung von etablierten Entwicklungsmethoden wie Continuous Integration und Continuous Delivery (CI/CD) innerhalb eines Agile Frameworks.

Standardisierung und Re-Use: Schlüssel für kosteneffiziente Migration

Im Hinblick auf die verhältnismäßig kleinen Stückzahlen bei Nutzfahrzeugen und deren Vielfalt bei Fahrzeug- und Aufbauvarianten entscheidet die Frage nach sinnvollen Standardisierungen und einem effizienten Re-Use über die Wirtschaftlichkeit der Migration. Ein entscheidender Erfolgsfaktor bei der Umstellung auf eine Software-definierte Architektur im Truck sind einheitliche Schnittstellen (Application Programming Interfaces, kurz: APIs), siehe Bild 4. Mit ihnen können Programmierer unabhängig von der Hardware und anderer Software Funktionen entwickeln, und es eröffnen sich gleichzeitig neue Entwicklungsmodelle und Wertschöpfungsketten für das Nutzfahrzeug.

Wo immer möglich, senkt ein Re-Use auf Hardware-Ebene die Kosten. Ein Pkw-HPC lässt sich durchaus mit geringfügiger Anpassung an Truck-OEM-Anforderungen anpassen. Dieser Prozess läuft bereits. Ähnliches gilt für das Thema Wärmemanagement (siehe unten). Ein großer Vorteil der Umstellung auf HPCs liegt darin, dass mit der Separation von Hardware und Software die bisherige Vielfalt an Nutzfahrzeugstandards und Protokollen auf der Ebene der Hochleistungsrechner gelöst wird. So haben HPCs beispielsweise keine I/O mehr. Solche Heritage-Fragen lassen sich eine Schicht tiefer lösen.

Je nach Ausgangsarchitektur erfordert eine Migration zum SDV bei Nutzfahrzeugen unterschiedliche Umfänge an Unterstützung und Bedarf, je nachdem, wie die spezifischen Ziele und Strategien des OEM aussehen. Dabei spielt eine Rolle, wie umfangreich die Kompetenz für die Software-Entwicklung beim OEM ist, bzw. in welchem Umfang eher Bedarf nach Off-the-shelf-Lösungen besteht. Continental bringt in einem Migrationsprojekt bewährte Strukturen und Tools für verschiedene Formen der Kollaboration mit unterschiedlich großem Teilnehmerkreis mit, von der partnerschaftlichen Entwicklung mit dem OEM über die Einbindung von Drittanbietern bis hin zu einem größeren Kreis einschließlich Trailer-Herstellern. Die Zusammenarbeit und der Austausch technischer Informationen auf Architekturebene erfolgen dabei strukturiert und mit klaren Verantwortlichkeiten.

Die Rolle der Hardware im SDV

Auch wenn die größten Aufwände beim SDV in der Software eingesetzt werden, behält die Hardware als Enabler eine Schlüsselrolle. HPCs fungieren in einem SDV als Server, die Software und damit Funktionen bzw. Dienste hosten. Um diese Rolle übernehmen zu können, verfügen HPCs über erhebliche Rechenleistungen und sorgen mit Hypervisor-Technologie für die Virtualisierung, die es erlaubt, mehrere Betriebssysteme (etwa AUTOSAR Classic/Adaptive, Linux, Android, QNX) mit unterschiedlichen Anforderungen an die funktionale Sicherheit parallel auf mehreren Kernels laufen zu lassen. Der HPC stellt Hochgeschwindigkeits-Datenschnittstellen bereit, und seine Kommunikationsarchitektur ist für die Dienste-Orientierung ausgelegt.

Der HPC übernimmt außerdem die Koordination der Anbindung an die Cloud oder ein Backend und dort verfügbare Anwendungen. Die vom HPC gewährleistete Fähigkeit zu OTA-Updates ist entscheidend für eine kurze Time-to-Market bei neuen Anwendungen. Im Hinblick auf künftige Anwendungen wie das automatisierte Fahren ist der HPC bereits für die Fusion von Sensordaten ausgelegt. Im Pkw ist der Continental-HPC bereits in mehreren konventionellen sowie elektrifizierten Fahrzeugen in Serie.

Wärmemanagement: Herausforderung und Lösungen für High-Performance-Rechner

Zu den Herausforderungen bei der Umstellung auf eine Software-definierte (SD) Architektur gehört das Wärmemanagement, denn die Konzentration von Rechenleistung mit dem Ziel der funktionalen Integration führt auch zu erheblicher Verlustwärme. Zu einer SD-Architektur gehört deshalb zwingend die geeignete Kühlstrategie. Auch hier ist Continental mit neuen Ansätzen technisch ein Innovator. Ob sich bei einer Software-definierten Architektur auf lange Sicht die in der Kabine des Nutzfahrzeugs ungeliebte Flüssigkühlung wird vermeiden lassen, hängt wesentlich von der nötigen Rechenleistung ab. Sollte eine Flüssigkühlung in der Kabine erforderlich werden, bietet Continental die Möglichkeit, seine HPCs (einzeln, als Stack aus zwei HPCs sowie als Rack mit bis zu vier Einschüben und leistungsstarker Backplane) an eine Flüssigkühlung anzuschließen bzw. hinzuzufügen oder zu tauschen, ohne dafür den Kühlmittelkreislauf zu öffnen (Bild 5).

Es ist nicht der Komfort, der im Nutzfahrzeug die Pläne zu Software-definierten Architekturen vorantreibt, sondern der Zwang zu mehr Wirtschaftlichkeit im Betrieb. Hochleistungsrechner ermöglichen gänzlich neue Funktionen im Fahrzeug, bei denen Daten auch über bisherige Domänengrenzen hinaus verarbeitet werden. Im Laufe des Fahrzeuglebens können immer wieder neue Funktionen hinzugefügt, bzw. bestehende Funktionen erweitert oder optimiert werden, ohne die Hardware zu verändern. Auf diese Weise wird es möglich, Fahrzeuge an veränderte Anforderungen anzupassen oder aufzuwerten. Die Fähigkeit zu OTA-Updates ist der Schlüssel dazu, neue Software zur Optimierung der Logistikkette schnell – und ohne Werkstattaufenthalt – in ein Fahrzeug zu integrieren. Mit der Trennung von Hardware und Software wird das Nutzfahrzeug auch zu einem attraktiven Feld für neue Anbieter, die neue Ideen und Funktionen anbieten möchten. (na)