Neue Herausforderungen für Entwickler
»SDV ready« – Was müssen Entwicklungstools für SDVs können?
Mit dem Übergang von traditionellen domänenbasierten Elektrik/Elektronik-Fahrzeugarchitekturen zum Software-Defined Vehicle (SDV) steigen die Anforderungen an Entwicklungswerkzeuge.
Neue heterogene Multicore-High-Performance-Chips und ein hochkomplexer Software-Stack in einer virtualisierten Umgebung schränken die Auswahl geeigneter Debug- und Trace-Tools ein. Aber schon heute gibt es geeignete »SDV ready«-Lösungen für diese komplexen Architekturen.
Der Begriff »Software-definiertes Fahrzeug« (SDV) beschreibt ein Fahrzeug, dessen Eigenschaften und Funktionen hauptsächlich durch Software ermöglicht werden. Dies ist das Ergebnis der fortschreitenden Umwandlung des Automobils von einem hauptsächlich hardwarebasierten Produkt zu einem softwarezentrierten elektronischen Gerät auf Rädern.
Premium-Fahrzeuge enthalten heutzutage bis zu 150 Millionen Zeilen Software-Code, verteilt auf bis zu 100 elektronische Steuergeräte (ECU, Electronic Control Units), und eine wachsende Zahl von Sensoren, Kameras, Radar- und Lidar-Geräten. Massenmarktfahrzeuge sind nicht weit davon entfernt. Drei starke Trends – Elektrifizierung, Automatisierung und Connectivity – verändern die Kundenerwartungen und veranlassen die Hersteller, zunehmend auf Software zu setzen, um sie zu erfüllen.
In der Vergangenheit unterschieden sich die Fahrzeughersteller durch mechanische Merkmale wie Leistung und Drehmoment. Heutzutage suchen die Verbraucher zunehmend nach softwaredefinierten Merkmalen wie Fahrerassistenzfunktionen, Infotainment-Innovationen und intelligenten Connectivity-Lösungen.
In demselben Maße, in dem Fahrerassistenzfunktionen in Richtung automatisiertes und vollständig autonomes Fahren wachsen, steigt auch der Bedarf an mehr Software. Weil die Verbraucher umfangreichere Inhalte in ihren Infotainment-Systemen erwarten, wächst die Menge der digitalen Inhalte, die das Fahrzeug verwalten muss. Und da Fahrzeuge Teil des Internet of Things (IoT) werden und große Datenmengen in die und aus der Cloud übertragen, wird Software für die Verarbeitung, Verwaltung und Verteilung all dieser Daten benötigt.
Das softwaredefinierte Fahrzeug bietet nicht nur neue Sicherheits-, Komfort- und Bequemlichkeitsfunktionen, sondern hat gegenüber seinem hardwaredefinierten Vorgänger noch eine Reihe weiterer Vorteile.
Jobangebote+ passend zum Thema
Heutzutage erfordern Software-Upgrades für Infotainment-, Telematik- oder Fahrzeugdiagnose-Systeme eine Fahrt zum Autohaus. Für ein softwaredefiniertes Fahrzeug können Kunden nicht nur Over-the-Air-Updates (OTA) erhalten, die Sicherheits-Patches, Infotainment-Verbesserungen sowie die Überwachung und Abstimmung von Kernfunktionen des Fahrzeugs wie Antriebsstrang und Fahrdynamik umfassen, sondern auch aus einem App-Store neue Features herunterladen.
Steuergeräte werden riesige Datenmengen an und von Sensoren und Aktoren senden und empfangen, die Fahrzeugherstellern Einblicke in jeden Aspekt eines Fahrzeugs, dessen Leistung und seinen Platz im vernetzten Ecosystem gewähren. Dies gibt ihnen die Möglichkeit, das Lebenszyklusmanagement zu verbessern und umsatzsteigernde Funktionen zu entwickeln – all dies wird zu tieferen, stärker vernetzten Beziehungen mit den Kunden führen.
Von der Hardware zur Software
Bild 1 zeigt eine traditionelle domänenbasierte Fahrzeugarchitektur. Sie unterteilt das Fahrzeug hinsichtlich Struktur und Hierarchie in unterschiedliche Domänen. Darin werden ähnliche Funktionen für Fahrgestell, Antriebsstrang, Karosserie oder Infotainment zusammengefasst. Kommt anschließend beispielsweise ADAS hinzu, muss eine neue Domäne geschaffen und deren Steuergerät mit dem zentralen Gateway verbunden werden. Jedes Feature beziehungsweise jede Funktion wird durch eine eigene ECU abgebildet. Der Mikrocontroller der ECU wird exakt für die diese Funktion abbildende Software ausgewählt, und gemeinsam mit der Hardware wird das Steuergerät für diese Funktion aufgebaut, als »ECU für elektrische Fensterheber« oder »ECU für Airbag-Auslösung« oder was auch immer. Entsprechend der begrenzten Funktionalität halten sich Rechenleistungsbedarf und Speicherausstattung der Mikrocontroller im Vergleich zu SoCs (System-on-a-Chip), die man beispielsweise in Smartphones findet, in engen Grenzen.
Im SDV findet eine Konsolidierung der Features und Funktionen auf weniger, aber dafür deutlich performantere Chips statt. Bild 2 zeigt beispielhaft einen Vorschlag für den stufenweisen Übergang von der domänenbasierten zur Zentralcomputer-Architektur. Obwohl es bis heute noch keine einheitliche Definition »der« SDV-Architektur gibt, herrscht generell Einigkeit über die Art der Hardware und des Software-Stacks, wie man ihn in SDVs vorfinden wird.
Bild 3 zeigt einen Vorschlag, der neben immer noch zahlreichen Endpoint-MCUs an den Sensoren und Aktoren vier sogenannte Zonen-Controller enthält. Dies sind leistungsfähigere Chips, die jeweils einen bestimmten Bereich des Autos steuern (hier: vorn links, vorn rechts, hinten links und hinten rechts) und mehrere Funktionen integrieren. Es gibt auch alternative Vorschläge mit sechs Zonen-Controllern, wobei die Längsachse des Autos dann in »Vorn«, »Mitte« und »Hinten« aufgeteilt ist. An der Spitze der Hardware stehen in Bild 3 drei High-Performance-SoCs. Es handelt sich dabei um High-End-Chips wie Qualcomms Snapdragon, Nvidias Drive Orin/Thor, NXPs S32N55 Super Vehicle Integration Processor oder Renesas R-Car der 5. Generation.
Andere Halbleiterhersteller arbeiten ebenfalls an HPC-SoCs. Hier finden sich massive Multicore-Architekturen mit den performantesten Cortex-A/R-Cores, die Arm derzeit anbietet, sowie weiteren Cores für die Beschleunigung spezieller Aufgaben, zum Beispiel Hexagon-DSPs bei Snapdragon, CEVA-X DSP bei bestimmten R-Car-Derivaten.
Hardwareseitige Anforderungen an Debug- und Trace-Tools
Es klingt banal, aber natürlich muss ein Debug- und Trace-Tool im ersten Schritt alle im SDV verbauten Chips unterstützen, wobei primär das effektive Multicore-Debugging gemeint ist, besonders für heterogene Chip-Architekturen mit einer Vielzahl unterschiedlicher Cores. Diese sogenannten AMP-Systeme haben mehrere Kerne, von denen jeder eine eigene Aufgabe erfüllt.
Lauterbachs »Trace32«-PowerView-Software bietet eine konsistente Benutzeroberfläche und einen einheitlichen Funktionsumfang für jede beliebige Mischung von Core-Architekturen. Man kann alle Arten von Multicore-Konfigurationen mit bis zu 16 synchronisierten PowerView-Instanzen über eine einzige Debug-Probe debuggen [1]. Innerhalb des Systems kann jeder Core seine eigenen Core-Architekturen, Speichermodelle, Betriebssysteme, Adressübersetzungen und Debug-Symbole sowie seinen eigenen physikalischen Adressraum haben. Man kann sogar mehrere separate Multicore-SoCs zum Debuggen über eine Daisy-Chain (JTAG), eine Sterntopologie (cJTAG/SWD) oder unter Verwendung von zwei Whiskern mit einer Trace32 CombiProbe kombinieren.
Bevor man sich somit für einen Debugger in einem SDV-Projekt entscheidet, sind Fragen wie »Unterstützt das Tool alle Chips einschließlich HPC-SoCs?« und »Kann ich alle Cores einschließlich Beschleunigern debuggen, beispielsweise den Hexagon-DSP auf Qualcomms Snapdragon?« mehr als wichtig.
Softwareseitige Anforderungen an Debug- und Trace-Tools
Auf Seite des SDV-Softwarestacks erleben wir einen fast noch stärkeren Paradigmenwechsel als bei der Hardware. Es haben sich mehrere Konsortien gebildet, um dafür eine Standardisierung zu erarbeiten. Laut einer Studie der Analysefirma WardsAuto hat das von Arm gegründete SOAFEE-Konsortium die besten Aussichten, dabei erfolgreich zu sein [2].
Bild 4 zeigt den hochkomplexen Software-Stack, wie ihn sich das SOAFEE-Konsortium (www.soafee.io) vorstellt. Ziel ist es, die bisherige Co-Entwicklung von Hard- und Software wesentlich zu entkoppeln. Die Komponenten werden unabhängig voneinander entwickelt. Die Integration aller Module, die früher beim OEM durchgeführt wurde, übernimmt jetzt das Auto im Betrieb selbst.
Dabei sind vor allem zwei Punkte entscheidend: Erstens wird die Umgebung virtualisiert, wie man es heute beispielsweise aus Rechenzentren kennt. Mithilfe von Hypervisors werden Virtual Machines (VMs) aufgesetzt, in denen jede für sich strikt getrennt von anderen VMs nicht nur Anwendungen, sondern eigene Betriebssysteme laufen. Zweitens lassen sich mittels der Container-Technologie neue Anwendungen aus der Cloud installieren, ohne bestehende Workloads zu beeinflussen.
Was bedeutet dies für Debug- und Trace-Tools? Als Erstes müssen sie eine breite Hypervisor- und OS-Awareness bieten. Dies bedeutet, dass Anwender den gesamten Software-Stack von der Benutzeranwendung bis zum Gerätetreiber debuggen und dabei alle Betriebssystemobjekte wie Threads und Nachrichtenwarteschlangen abfragen und anzeigen können. In virtualisierten Systemen müssen alle VMs und ihre Anwendungen gleichzeitig debugbar sein, um vollständige Transparenz herstellen zu können.
Auf virtualisierten Systemen, bei denen mehrere Betriebssysteme von einem Hypervisor gesteuert werden, ermöglicht Lauterbachs Trace32 Hypervisor-aware Debugging die gleichzeitige Durchführung von OS-aware Debugging für jedes Gastbetriebssystem bzw. jede VM und die Anzeige einer Übersicht über das Gesamtsystem. Zusätzlich zu statischen Hypervisors werden darüber hinaus dynamische Hypervisors unterstützt, die den VMs dynamisch Speicherressourcen und Cores zuweisen – ein in der gesamten Embedded-Industrie einzigartiges Trace32-Feature [3].
Die Trace32 OS Awareness ist für mehr als 80 Embedded-Betriebssysteme aller Art verfügbar. Sie unterstützt sowohl Rich OSe als auch RTOSe sowie alle gängigen Open-Source- und kommerziellen Betriebssysteme, die in Embedded-Anwendungen eingesetzt werden.
Hier sollte man sich somit vor einem SDV-Projekt beispielsweise fragen: »Unterstützt das Tool alle Hypervisors und OSe inklusive aller AUTOSAR-compliant OSe für mein Projekt?«, »Kann ich in virtualisierten Umgebungen alle aktiven und nicht aktiven VMs gleichzeitig debuggen und die Speicherumsetzung per MMU (Memory Management Unit) von virtuellen auf physikalische Adressen nachvollziehen?« und »Kann ich Anwendungen in Containern wie Docker debuggen?«. Lautet die Antwort »nein«, dürfte es im Verlauf eines SDV-Entwicklungsprojekts irgendwann schwierig werden.
Last but not least: Entwicklung in der Cloud dank »Shift Left«
Um möglichst frühzeitig mit der Software-Entwicklung beginnen zu können, bevor reale Chips (in hinreichender Anzahl) verfügbar sind, beginnt man mit der Entwicklung immer häufiger auf virtuellen Targets in der Cloud. Anbieter wie Corellium, Synopsys, ASTC und andere bieten dazu ganze Chips oder Automotive-Plattformen »in Software« an. In einem Standard-Whitepaper [4] aus dem Jahr 2020 werden fünf Level von virtuellen und realen Steuergeräten beschrieben, bei denen man sich mit aufsteigendem Level immer mehr der realen Produktions-Umgebung annähert.
Aus Kundensicht ist es selbstverständlich wünschenswert, mit einer Toolchain und einer GUI alle Level einer ECU debuggen zu können, um keinen Bruch im Entwicklungsprozess zu haben. Lauterbachs Trace32 unterstützt den »Shift-Left«-Ansatz, indem es nicht nur reale Chips in Silizium unterstützt, sondern auch über unterschiedliche Schnittstellen virtuelle Targets und Emulatoren verschiedener Partneranbieter, auf denen Softwareentwicklung bereits möglich ist, wenn keine realen Chips in Silizium verfügbar sind (Bild 5). Die Funktionen und die GUI der Trace32-PowerView-Software unterscheidet sich nicht von realen Targets, sodass man während des gesamten Entwicklungszyklus die gleiche Benutzererfahrung hat.
Arm hat vor einiger Zeit unter dem Namen RD-1AE eine vielbeachtete Automotive-Referenzplattform für SDVs vorgestellt (Bild 6), die mehrere CPU-Cluster mit Neoverse-V3-, Cortex-R82A- sowie Cortex-M55-Cores implementiert und die passende Open-Source-Software wie den Xen-Hypervisor und das RTOS Zephyr OS gleich mitliefert. Corellium hat diese Referenzplattform in die Cloud gebracht [5]. Ausschließlich mit Lauterbachs Trace32 können Automotive-Entwickler sowohl reale Hardware als auch die Corellium-Implementierung der RD-1AE-Plattform in der Cloud debuggen.
Zusammengefasst ist es vor Beginn eines SDV-Projekts darum sinnvoll, Fragen zu stellen wie: »Unterstützt mein Tool virtuelle Targets von allen für mein Projekt relevanten Chips?« und »Kann ich alle Skripte während des gesamten Produktlebenszyklus wiederverwenden, und bleiben die Benutzeroberfläche und die Skriptbefehle von den Simulationen bis zum Einsatz im Feld gleich?«
Fazit: »SDV ready« Tools erleichtern das Entwicklerleben
Zusammenfassend lässt sich sagen, dass die Welt für Automotive-Entwickler von SDV-Architekturen komplexer als beim traditionellen Ansatz. Nicht alle Tools unterstützen alle neuen Herausforderungen, beginnend mit hochkomplexen Multicore-SoCs bis hin zu virtualisierten Umgebungen, Containern und virtuellen Targets. Lauterbachs Trace32-Debug- und Trace-Tools sind schon heute »SDV ready«: Mit Trace32 können Entwickler ihren gesamten SDV-Software-Stack auf allen heutigen und zukünftigen Automotive-SoCs und über den gesamten Lebenszyklus vom virtuellen Steuergerät bis zum realen Silizium debuggen. ak
Lauterbach auf der embedded world: Halle 4, Stand 210
Literatur
[1] Unlimitiertes Multicore-Debugging mit Lauterbach Trace32: https://www.lauterbach.com/features/multicore-debugging-and-tracing
[2] Studie »Unveiling Tomorrow’s Ride: A Deep Dive Into Software-Defined Vehicles«, Seite 19
[3] Hypervisor- und OS-Aware-Debugging mit Lauterbach Trace32: https://www.lauterbach.com/features/ os-awareness
[4] Requirements for the Standardization of Virtual Electronic Control Units (V-ECUs): https://www.ps-ent-2023.de/fileadmin/prod-download/ WhitePaper_V-ECU_2020_05_04-EN.pdf
[5] Corellium Arm Virtual Hardware RD1-AE: https://www.corellium.com/blog/introducing-rd-1ae
Lesen Sie mehr zum Thema
