Das software-definierte Fahrzeug ermöglicht es Autoherstellern ihre Software bereits zu einem früheren Zeitpunkt im Entwicklungszyklus fertigzustellen und auch noch lange nach dem Verkauf immer weiter anzupassen. (Bild: NXP Semiconductors)
Bei eingebetteten Systemen sind Software und Hardware eng miteinander verbunden. Um eine einwandfreie Integration beider Elemente zu gewährleisten, sind zahlreiche Tests direkt am Fahrzeug erforderlich. Die SoftwareentwicklerInnen stehen hier jedoch aufgrund begrenzter Ressourcen und enger Zeitvorgaben oft unter großem Druck.
Schnelle Produktentwicklungszyklen bleiben damit für Autohersteller unerreichbar und auch Geschäftsmodelle rund um neue Serviceleistungen bleiben vorerst auf der Strecke. Aus diesem Grund setzen Automobilhersteller zunehmend auf das softwaredefinierte Fahrzeug - das Software-Defined Vehicle (SDV). Statt nur punktuelle Firmware-Updates oder Security-Patches bereitzustellen, die nur im Rahmen der Wartung durchgeführt werden können, ist es mit SDVs möglich, Fahrzeuge über ihren gesamten Lebenszyklus hinweg weiterzuentwickeln und zu verbessern.
Um die Vision des softwaredefinierten Fahrzeugs zu verwirklichen, ist jedoch ein Plattformansatz erforderlich. Durch die Entkopplung von Hardware und Software können Anwendungen und Architekturen flexibler gestaltet und zusätzliche Funktionen im Laufe der Zeit implementiert werden. Außerdem kann die gleiche Software in verschiedenen Fahrzeugmodellen verwendet werden, ohne, dass viele Anpassungen zwischen den verwendeten Plattformen vorgenommen werden müssen. Nicht zuletzt profitieren FahrzeugbesitzerInnen von einer höheren Sicherheit und Zuverlässigkeit ihrer Fahrzeuge sowie einem geringeren Energieverbrauch.
Shift left and stretch right
Das SDV wird die Softwareentwicklung für Fahrzeuge grundlegend verändern und wir werden einen "Shift Left" - einen Ruck nach links - erleben. Dies bedeutet, dass die Software zu einem früheren Zeitpunkt im Entwicklungszyklus fertiggestellt werden kann, auch wenn noch keine Hardware-Prototypen verfügbar sind. Die Industrie wird auch einen "Stretch Right" - eine Ausdehnung nach rechts - erleben. Das bedeutet, dass Software-Updates in die Zeit nach dem Verkauf "hineinreichen". Dies bietet den Automobilherstellern die Möglichkeit, neue Einnahmequellen aus Cloud-basierten Diensten zu erschließen und Fahrzeuge über mehrere Besitzer hinweg zu unterstützen, indem Over-the-Air-Updates genutzt werden, um während der gesamten Lebensdauer eines Fahrzeugs neue Funktionen hinzuzufügen.
Das Konzept der kontinuierlichen Integration und der kontinuierlichen bzw. quasi-kontinuierlichen Bereitstellung wird im Unternehmensbereich seit Jahren erfolgreich eingesetzt. "Shift Left" und "Stretch Right" sind daher die nächsten beiden logischen Schritte für Automobilhersteller. Glücklicherweise sind die Erfolgsbedingungen in diesen Bereichen weitgehend deckungsgleich - vorausgesetzt, die Entwicklungsteams wenden die richtigen Softwareentwicklungsmethoden an.
Softwaredefinierte Fahrzeuge unterscheiden sich nicht grundsätzlich von anderen eingebetteten Systemen. Daher können bewährte Technologien wie Virtualisierung und die Verwendung von Software-Containern eingesetzt werden, um Softwaremodule zu isolieren und getrennt von der Hardware zu verarbeiten. Dies erleichtert die Integration in Cloud-basierte Prozesse. Dadurch werden neue Funktionen möglich, die auf der Kombination von Kfz-Kernfunktionen mit künstlicher Intelligenz (KI) und Cloud-basierter Analyse basieren.
Die wichtigste Änderung für eingebettete Systeme besteht darin, die Notwendigkeit von Tests direkt an der Hardware zu reduzieren oder so weit zu minimieren, dass die Annahmen über das Timing und das Verhalten der Hardware realistisch sind. Dies erfordert jedoch eine weitere Komponente.
Wie Virtualisierung und Simulationen die Entwicklung weiter vorantreiben
Die Containerisierung ist ein wichtiger Faktor bei der Einführung kontinuierlicher Integrations- und Bereitstellungsmethoden in der Cloud-Umgebung, da sie eine größere Unabhängigkeit von der Hardware ermöglicht: Anwendungen können zusammen mit den unterstützenden Bibliotheken und Gerätetreibern, mit denen sie getestet wurden, in Containern abgelegt und vom zugrunde liegenden Betriebssystem isoliert werden. Für den Einsatz in eingebetteten Systemen ist jedoch eine zusätzliche Schutzschicht erforderlich. Diese wird durch Virtualisierung geschaffen. Dabei ordnet ein Hypervisor die I/O-Nachrichten der zugrunde liegenden Hardware zu und trägt zusätzlich dazu bei, funktional unabhängige Tasks auf demselben Prozessor voneinander zu isolieren.
Insgesamt macht die Containerisierung die Automobilhersteller flexibler und unterstützt sie bei der Bereitstellung von Updates. Dies ist besonders vorteilhaft bei Komponenten wie Infotainment-Modulen, bei denen häufig mit Over-the-Air-Updates zu rechnen ist. Auch wenn die SoftwareentwicklerInnen unabhängiger von der Hardware werden, bleiben einige Abhängigkeiten bestehen, die für die Funktionalität der Echtzeit-Steuerungs- und Sicherheitssysteme des Fahrzeugs von entscheidender Bedeutung sind. Die EntwicklerInnen müssen daher darauf achten, wie sich Änderungen an der Hardware auf ihre Software auswirken. Dabei kann der "Digitale Zwilling" helfen.
Ein digitaler Zwilling ist ein virtuelles Modell, das das Verhalten von Hardware und Firmware simuliert. Bei der Verwendung eines digitalen Zwillings müssen SoftwareentwicklerInnen für die meisten Tests keinen physischen Zugang zur Hardware haben. Der digitale Zwilling kann in Desktop-Tools oder Cloud-basierten Containern entweder im interaktiven Debug-Modus oder als hoch automatisierte Regressionstest-Suite ausgeführt werden. Regressionstests führen eine Vielzahl von Tests durch und beschleunigen so die Qualitätskontrolle bei jeder Änderung. Darüber hinaus nutzen Entwicklerteams zunehmend Technologien des maschinellen Lernens, um die Fehlersuche zu beschleunigen.
Software-Updates können mit Hilfe eines digitalen Zwillings an allen betroffenen Code-Modulen oder Subsystemen getestet werden. Dies ist wichtig, um zu überprüfen, ob Änderungen zu unerwünschten Nebeneffekten führen. Dennoch ersetzt der digitale Zwilling die Hardware im Projekt nicht vollständig. Traditionelle Hardware-in-the-Loop-Tests sind weiterhin erforderlich, um das simulierte Verhalten des digitalen Zwillings mit der Realität abzugleichen. Sobald ein digitaler Zwilling jedoch unter realen Bedingungen getestet wurde, kann er umfassend für die Qualitätssicherung von Mid-Life-Updates eingesetzt werden. Pre-Hardware-Tests können in der Cloud auf mehreren Servern gleichzeitig und mit hoher Geschwindigkeit durchgeführt werden. Dies ermöglicht es den Automobilherstellern, neue Funktionen zeitnah per Over-the-Air-Update bereitzustellen.
Die Nutzung hochdetaillierter Modelle
Die Genauigkeit der Modelle ist oft entscheidend, auch wenn viele Tests keine Modelle mit genauer Zeitsteuerung erfordern. Das Problem mit detaillierten Modellen ist jedoch, dass sie in der Regel langsamer laufen als Leistungsmodelle, die speziell für die Analyse von Befehlen auf der Architektur des Zielprozessors optimiert sind. Die Lösung des Problems besteht darin, Partitionen zu erstellen und Simulationen mit detaillierten Modellen nur für die Komponenten oder Subsysteme durchzuführen, für die sie benötigt werden.
Obwohl digitale Zwillinge auch von Automobilherstellern und Zulieferern erstellt werden können, ist es von großem Vorteil, Partnerschaften mit erfahrenen Chipherstellern einzugehen. Zulieferer wie NXP Semiconductors haben sich zu einer Entwicklungszeit von bis zu einem Jahr für die Modelle ihrer Chipsysteme (SoC) verpflichtet, bevor sie diese an die Automobilhersteller zum Einbau in Prototypen und Endprodukte liefern.
Digitale Modelle können Automobilherstellern und ihren Zulieferern auch helfen zu verstehen, wie Innovationen in der Systemarchitektur den Zielanwendungen zugute kommen. Ein gutes Beispiel ist der magnetoresistive Arbeitsspeicher (MRAM), der eine leistungsfähigere Alternative zum Flash-Speicher darstellt und die Einschränkungen der flüchtigen Speicher DRAM und SRAM für persistente Daten umgeht. Ein einfaches Modell geht davon aus, dass nichtflüchtige Speicher wie Flash und MRAM in Bezug auf Latenz und Bandbreite identisch sind. Genauere Modelle berücksichtigen jedoch Unterschiede in den Schreib- und Lesezeiten sowie andere Faktoren.
Diese Leistungsunterschiede können in der Codebasis berücksichtigt werden, um die Vorteile aller verfügbaren Technologien voll auszuschöpfen. Durch die Verwendung digitaler Modelle während der Softwareentwicklung können Softwareteams dazu beitragen, die Genauigkeit zukünftiger Hardwareimplementierungen zu verbessern und somit die Leistung über Modellgenerationen hinweg zu steigern.
Kontinuierliche Verbesserungen
Ansätze, die "Stretch Right" zugrunde liegen, ermöglichen Autobauern die Qualität ihrer Produkte kontinuierlich zu verbessern und die Einnahmen durch Serviceleistungen zu steigern. Neben Over-the-Air-Updates für Fahrzeuge können Automobilhersteller Sensordaten in Echtzeit erfassen und für zahlreiche Anwendungen des maschinellen Lernens nutzen. Die gesammelten Daten können gefiltert und für digitale Zwillinge verwendet werden, um deren Leistung mit der Realität zu vergleichen.
Dies wiederum ermöglicht es, neue Funktionen in einer präzisen Regressionstestumgebung zu testen, bevor sie in einem neuen Over-the-Air-Update bereitgestellt werden. Die daraus resultierende kürzere Zeitspanne zwischen Entwicklung und Bereitstellung führt zu einem wesentlich schnelleren Produktentwicklungszyklus für neue Funktionen. Darüber hinaus kann auf diese Weise die bestehende Hardware verbessert und ein "Shift Left" für neue Produktgenerationen durchgeführt werden. All dies zeigt, dass ein ganzheitlicher Ansatz in der Softwareentwicklung, der Continuous Integration und digitale Zwillinge einbezieht, die Effizienz des Produktdesigns und der Softwareunterstützung erheblich steigern kann.
Sie möchten gerne weiterlesen?
Dieser Beitrag wird präsentiert von:
