Entwicklungsplattformen für SDVs

»Unsere Entwicklungs-Tools sind SDV-Ready«

11. März 2025, 15:30 Uhr | Andreas Knoll
Rudi Dienstbeck, Lauterbach: »Wir gehen davon aus, dass die einschlägigen Halbleiterhersteller auch auf der embedded world das Thema SDV ganz oben auf ihrer Agenda platzieren.«
© Lauterbach

Der Übergang von herkömmlichen Elektrik/Elektronik-Fahrzeugarchitekturen zum Software-Defined Vehicle (SDV) bringt einige Veränderungen im Entwicklungsprozess mit sich. Lauterbach, Marktführer bei Debug- und Trace-Tools, sieht darin Chancen für Autohersteller, Chip-Lieferanten und auch sich selbst.

Diesen Artikel anhören

Dipl.-Ing. Rudi Dienstbeck, Lead Architect Automotive bei Lauterbach, erläutert dies im Interview.


Markt&Technik: Was sind die Hardware-Voraussetzungen für SDV-Architekturen?

Rudi Dienstbeck: Im SDV finden sich neben Endpunkt-ECUs (Electronic Control Units) und Zonal-Controllern auch HPC-SoCs (High-Performance Computing), die massive Multicore-Architekturen mit High-End-Cores aufweisen, in denen mehrere Anwendungen parallel laufen können. Beispiele für HPC-SoCs sind die S32N55-Familie von NXP, das neue R-Car Gen.5 von Renesas, aber auch Drive Orin/Thor von Nvidia und Snapdragon Automotive von Qualcomm. Es gibt durch die Konsolidierung im SDV somit deutlich weniger Steuergeräte als in herkömmlichen Fahrzeugarchitekturen, dafür aber High-End-SoCs ergänzend zu den üblichen Automotive-Mikrocontrollern.


Worin unterscheidet sich der Entwicklungsprozess für die Hardware-/Software-Entwicklung von SDVs von dem Prozess, wie wir ihn bisher kennen?

Weil jede Komponente im SDV meist mehrere verschiedene Aufgaben zu bearbeiten hat, eventuell auch mit unterschiedlichen Sicherheitsstufen, müssen nicht nur die Chips, sondern auch die Software-Architektur darauf abgestimmt werden.

Wenn man sich den Software-Stack anschaut, den beispielsweise das SOAFEE-Konsortium für SDVs definiert hat, stellt man fest, dass Elemente wie Virtualisierung und Containerisierung, die man bislang eher aus Rechenzentren kannte, plötzlich auch ins Auto wandern. Dies bedeutet den Einzug von Hypervisors und multiplen Betriebssystemen vom RTOS bis hin zu Linux-Derivaten in Automobil-SoCs und dazu die Installation neuer Software-Pakete über Container.

Die bisherige Co-Entwicklung von Hardware und Software wird dadurch wesentlich entkoppelt. 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.


Welche Software-Tools sind für den Entwicklungsprozess notwendig?

passend zum Thema

Vorschlag einer SDV-Fahrzeugarchitektur.
Vorschlag einer SDV-Fahrzeugarchitektur.
© Lauterbach

Die Entwicklung der Software-Komponenten ist nicht viel unterschiedlicher als bisher. Lediglich zur Integration und zum Deployment müssen entsprechende Tools neu eingeführt werden. Allerdings wird der Test auf System-Ebene natürlich viel komplexer, wenn man gleichzeitig mehrere Anwendungen in mehreren Cores in einer virtualisierten Umgebung debuggen muss. Für vollständige Transparenz sind sogenannte Hypervisor- und OS-Awareness erforderlich, und diese Features bieten nur sehr wenige Tools wie unsere »TRACE32«-Toolchain.


Können Sie unseren Lesern das Thema Awareness noch etwas näherbringen? Was bedeutet das konkret?

Eines der wichtigsten Merkmale von SDV-Architekturen ist die Virtualisierung. Ein Hypervisor isoliert die Ressourcen von Virtual Machines (VMs) und ermöglicht die Erstellung und Verwaltung dieser VMs. Mehrere verschiedene Betriebssysteme können nebeneinander laufen und dieselben virtualisierten Hardware-Ressourcen mit einem Hypervisor teilen. Mit unserer »TRACE32«-Hypervisor-Awareness können Sie das Gesamtsystem einschließlich mehrerer Betriebssysteme gleichzeitig und nahtlos debuggen. Dies gilt sogar für inaktive VMs und die Speicherumsetzung per MMU (Memory Management Unit) von virtuellen auf physikalische Adressen.


Welche Herausforderungen bestehen für den Entwicklungsprozess und die Entwickler der Software-Tools jetzt und in absehbarer Zukunft?

Durch den komplexeren Software-Stack und die High-Performance-Chips werden natürlich nicht nur die Fehlersuche, sondern auch das System-Profiling deutlich herausfordernder und aufwändiger. Denken Sie nur mal an die Messung einer Worst-Case-Execution-Time in einer virtualisierten Multicore-Umgebung mit Out-of-Order-Prozessoren, wo Sie überhaupt nicht vorhersagen können, wann und wie lange welcher Task läuft, welche Daten in welchen Caches verfügbar sind oder nicht und wie lange die Umsetzung von virtuellen in physikalische Speicheradressen dauert. Und dann natürlich die Datenmengen, die ein mit GHz getakteter Multicore-Prozessor generiert und die Sie im Zweifel auswerten müssen.


Welche Herausforderungen bestehen für Lauterbach als Entwickler der Software-Tools?

Für uns bei Lauterbach gibt es keine neuen strukturellen Herausforderungen, weil unsere »TRACE32«-Tools schon seit vielen Jahren »SDV-Ready« sind: Sie können Container debuggen, geben Anwendern eine vollständige Systemsicht einschließlich Hypervisors und aller denkbaren Betriebssysteme auf Multicore-, Manycore- und sogar Multi-Chip-Architekturen - und das auf den meisten unterschiedlichen Mikroarchitekturen und unterschiedlichen Chips in der Tool-Industrie. Anders formuliert: Für unser Geschäft ist die Transition zum SDV ein Glücksfall, und wir denken, wegen unseres technischen Vorsprungs hier sehr gut positioniert zu sein. Wir sind der einzige Debugger-Hersteller auf der Welt, dessen Tools Sie für Zonal-Controller, kleine Endpoint-Mikrocontroller, aber eben auch für HPC-SoCs aller relevanten Hersteller im SDV einsetzen können. Die größte Herausforderung, die uns genauso wie die SDV-Entwickler trifft, ist die stetig zunehmende Komplexität und das »Schritthalten« mit den Implementierungen in den SoCs.


Welche Möglichkeiten bietet die Hardware-/Software-Entwicklung von SDVs in der Cloud jetzt und in absehbarer Zukunft?

Tatsächlich geht mit dem SDV ein weiterer Paradigmenwechsel einher, den man als »Shift Left« bezeichnet. Dies bedeutet, man verlegt wesentliche Teile von Entwicklung und Test in virtuelle Steuergeräte, die in der Cloud laufen und reale ECUs 1:1 nachbilden. Der Vorteil ist, Sie können die Entwicklung fast beliebig skalieren und mit der Entwicklung beginnen, bevor Chips überhaupt verfügbar sind.


Wie geht der Entwicklungsprozess in der Cloud vor sich?

Im Prinzip nicht anders als bei realen Chips; Tools wie »TRACE32« verbinden sich dann eben nicht direkt zur Zielhardware, sondern über das Internet zur virtuellen CPU in der Cloud. Natürlich stellt sich die Frage, wie performant virtuelle Targets sind, dafür können Sie natürlich per Script 24/7 testen. Am Ende müssen Sie ohnehin immer noch den Systemtest mit realer Hardware machen. Man hat sich auf ein fünfstufiges Schema für virtuelle Steuergeräte, sogenannte vECUs, geeinigt, das mit steigenden Levels Tests immer näher am Production-Code ermöglicht. Unsere »TRACE32«-GUI und Feature-Set sind aus Kundensicht über alle virtuellen Levels und die reale ECU-Hardware identisch, so dass hier ein nahtloser Übergang sichergestellt ist.


Welche Herausforderungen gibt es bei der Cloud-Entwicklung?

Die meisten Rechenzentren arbeiten mit x86-Prozessoren, während in der Embedded-Welt die RISC-Architekturen dominieren, besonders Arm. Das Problem ist, dass die Simulatoren in solchen Umgebungen die Arm-Instruktionen in x86-Befehle umsetzen müssen, was extrem zeitaufwendig ist. Der Anbieter Corellium lässt seine virtuellen Plattformen in echten Arm-Graviton-Prozessoren bei AWS laufen, was einen enormen Geschwindigkeitsvorteil bringt.


Die CES (Consumer Electronics Show) vom 7. bis 10. Januar in Las Vegas war stark vom Thema SDVs geprägt. Inwieweit ist das auch bei der embedded world der Fall?

Wir gehen davon aus, dass die einschlägigen Halbleiterhersteller auch in Nürnberg das Thema SDV ganz oben auf ihrer Agenda platzieren. NXP hat ja kürzlich TTTech Auto übernommen, um die SDV-Transition noch mehr zu beschleunigen. Dazu wurden mit eigenen Plattformen wie CoreRide von NXP oder der R-Car Open Access Platform von Renesas gleich ganze Ecosystems für die Entwicklung von SDVs bereitgestellt. Infineon hat Kooperationen mit relevanten Playern wie Continental ins Leben gerufen, um SDV-Plattformen zu entwickeln. Vector hat gar einen ganz eigenen SDV-Kongress aufgesetzt und eine SDV-Website live geschaltet. Dies sind nur einzelne Beispiele; das Thema ist in der ganzen Automobil-Wertschöpfungskette ganz oben auf der Agenda. Wir haben dazu quasi just in time unsere eigene SDV-Website www.lauterbach.com/sdv live geschaltet.


Inwieweit könnten die Krise der deutschen Automobilindustrie und die zunehmend schwierigen Geschäftsbedingungen in China die Business-Chancen für SDV-Entwicklungsplattformen einschränken?

Das Gegenteil ist der Fall; der Übergang zum SDV wird ja gerade in China quasi erzwungen. Oft steht in China ein Auto in einer Einkaufs-Mall und wird nach dem Kleidungs- und Schuhkauf auf Basis einer Feature-Liste gekauft oder eben auch nicht gekauft. Wichtig ist, nach dem Kauf Software-Updates zu bekommen oder neue Apps aus einem App-Store installieren zu können, die einen signifikanten funktionalen Mehrwert bringen. Kurz gesagt: Chinesinnen und Chinesen wünschen sich Smartphones auf Rädern und kein reines Fortbewegungsmittel aus Blech. Insofern ist das SDV auch für die deutsche Automobilindustrie eine riesige Chance, tolles deutsches Engineering zusammen mit Leading-Edge-Software-Features auf die Straße zu bringen. Und wir bei Lauterbach tun alles, damit die Software so großartig und fehlerfrei wie nur möglich wird.

Die Fragen stellte Andreas Knoll.

Lauterbach auf der Messe embedded world 2025: Halle 4, Stand 210


Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lauterbach GmbH

Weitere Artikel zu Embedded

Weitere Artikel zu Software/Entwicklung

Weitere Artikel zu Entwicklungswerkzeuge