Schneller am Markt mit weniger Aufwand
»Shift Left«: Elektronik-Entwicklung mit digitalen Zwillingen
Der Wandel der Automobilindustrie von der analogen hin zur digitalisierten Mobilitätswelt und zu Software-Defined Vehicles (SDV) führt zu wachsenden Anforderungen an Qualität, Geschwindigkeit und Flexibilität in der Fahrzeugentwicklung.
Der Shift-Left-Ansatz etabliert sich dabei auch für Hersteller von Entwicklungstools als Schlüsselelement für nachhaltige Wettbewerbsfähigkeit und Innovationskraft.
Der Begriff »Shift Left« stammt aus der Softwareentwicklung. Er bezeichnet das Platzieren von Qualitätssicherungsaufgaben und Testaktivitäten möglichst früh im Entwicklungsprozess. Ziel ist, Fehler nicht erst am Projektende, sondern schon in der Entwurfs- und Codephase zu erkennen und zu beheben. Traditionelle Vorgehensweisen sahen typischerweise einen sequenziellen Ablauf vor: Planung, Entwicklung, Test und anschließende Produktion. Hierbei wurden Fehler oft erst spät und kostenintensiv entdeckt.
In modernen Fahrzeugen, besonders in SDV, wächst der Software- und Elektronikanteil rapide. Funktionen wie Fahrerassistenz, Infotainment oder autonomes Fahren erfordern komplexe Test- und Validierungsverfahren. Die Automobilindustrie greift daher verstärkt auf Methoden wie Simulation, virtuelle Prototypen und Continuous-Integration/Continuous-Delivery (CI/CD) zurück, um Fehler so früh wie möglich zu finden – und so das klassische »Test-last-Prinzip« abzulösen.
Virtuelle Prototypen und der Einsatz von Digital Twins ermöglichen die Früherkennung von Fehlfunktionen, bevor physische Prototypen gebaut werden müssen. Mit Software-in-the-Loop (SiL) und Hardware-in-the-Loop (HiL) werden Softwaremodule, Steuergeräte und Fahrfunktionen frühzeitig und automatisiert getestet. Simulationsumgebungen ermöglichen Tests unter verschiedensten Bedingungen – so lassen sich Entwicklungszyklen verkürzen und Risiken für teure Nacharbeiten minimieren.
Entwicklung in virtuellen Steuergeräten
Die zunehmende Komplexität von Steuergeräten in Fahrzeugen, Maschinen und Anlagen führt dazu, dass klassische Entwicklungs- und Testmethoden an ihre Grenzen stoßen. Früher wurden Softwarefunktionen erst in einem späten Stadium in realer Hardware getestet, was zu langen Entwicklungszeiten und hohen Kosten führte. Virtuelle Steuergeräte (vECUs – virtual Electronic Control Units) verändern diesen Prozess grundlegend.
Ein virtuelles Steuergerät ist ein softwarebasiertes Modell eines realen Steuergeräts. Es bildet dessen Prozessor, Speicher, Peripherie und Kommunikationsschnittstellen so nach, dass die Originalsoftware – etwa Motorsteuerungs-, Bremssystem- oder Komfortfunktionen – auf diesem virtuellen Abbild lauffähig ist. Dadurch lässt sich das Verhalten des Steuergeräts vollständig in einem PC oder in einer Cloud-Umgebung simulieren, ohne physische Hardware bereitzustellen.
Jobangebote+ passend zum Thema
Der virtuelle Einsatz ermöglicht umfangreiche Testszenarien, die mit physischer Hardware kaum realisierbar wären. Beispielweise lassen sich in einer Simulationsumgebung Millionen von Fahrzyklen automatisiert durchlaufen, inklusive Randbedingungen, die in realen Tests gefährlich oder teuer wären. So können auch Sicherheits- und Diagnosestrategien intensiver überprüft werden.
Virtuelle Steuergeräte beruhen auf Modellen, die auf verschiedenen Detailstufen aufgebaut sein können. »Black-box«-Modelle bilden nur die äußere Funktion ab, während »White-box«-Modelle das Innenleben eines Steuergeräts vollständig simulieren – inklusive Befehlssatz, Echtzeitverhalten und Buskommunikation. Je nach Entwicklungsphase kommen unterschiedliche Abstraktionsniveaus zum Einsatz. In einem Standard-Whitepaper zum Thema vECUs [1] wurden fünf Level definiert, die sich bezüglich Anwendung, Basis-Software und Treibern/Hardwarezugriffen unterscheiden (Tabelle 1). Diese Beschreibung der Software-Schichten und der vECU-Schichten beruht auf der AUTOSAR Classic Platform. Bild 1 zeigt eine vereinfachte Version der AUTOSAR-Basissoftware als Referenz für die Definition der vECU-Typen.
Shift Left und vECUs für Development Tools: Von der Cloud zum realen Chip
Der Einsatz eines Entwicklungs-Tools wie etwa eines Debuggers zieht sich durch den gesamten Produktlebenszyklus von der Entwicklung im Emulator über das Testen auf dem realen Chip bis hin zum Einsatz im Feld und bringt jeweils spezifische Vorteile und Herausforderungen mit sich. Bild 1 zeigt die einzelnen Entwicklungsphasen beim Einsatz von Lauterbachs TRACE32-Software und deren Anbindung an die unterschiedlichen Zielplattformen.
Zu Beginn kommt meist ein Software-Simulator oder Emulator zum Einsatz, der unabhängig von der Zielhardware ist und es ermöglicht, den Programmfluss zu verfolgen und systematisch Fehler zu entdecken.
Entwickler können die internen Signale untersuchen, Variablen verändern und Schritt-für-Schritt den Programmverlauf analysieren, ohne Rücksicht auf reale Hardware-Einschränkungen nehmen zu müssen. Diese Phase ist ideal für frühes Debugging, schnelle Iterationen und das Auffinden logischer Fehler im Design. Über die von Lauterbach entwickelte GTL-Schnittstelle lassen sich alle wichtigen Emulatoren etwa von Siemens, Cadence oder Synopsys anbinden.
Simulatoren und virtuelle Targets können in Remote-PCs oder auch in der Cloud laufen. Hier werden ganz konkrete Chips nachgebildet, so dass Entwickler Zugang zu Hardware- und Software-Elementen bekommen und beim Debugging beispielsweise Breakpoints und Variablen-Überwachung direkt anwenden können. Mit einer Vielzahl unterstützter Schnittstellen kann TRACE32 nicht nur an weit verbreitete virtuelle Targets wie etwa die bekannten Synopsys-VDKs andocken, sondern auch an Speziallösungen wie den Qualcomm-Hexagon-Simulator für die in Snapdragon-SoCs verbauten proprietären DSP-Cores oder Arm Virtual Hardware (AVH) von Corellium, die in nativen Arm-Server-Prozessoren läuft und damit erhebliche Geschwindigkeitsvorteile erzielt [2].
Eine cloud-basierte virtuelle Plattform kann beispielsweise eine Amazon-EC2-Instanz (Elastic Compute Cloud) sein, die mit allen Softwarepaketen und Tools vorkonfiguriert wird, die etwa für ein Synopsys-VDK erforderlich sind. Darüber hinaus lässt sich dort auch die TRACE32-Software installieren.
Für alle unterstützten Mikroarchitekturen - insgesamt über 150 - ist in der TRACE32-Software ein Instruction Set Simulator (ISS) inkludiert, der die Ausführung der Maschinenbefehle eines Prozessors nachbildet, ohne dass die echte Hardware vorhanden sein muss. Er simuliert dafür das Ausführen einzelner Instruktionen und verwaltet virtuelle Register, Programmzähler und weiteren Prozessorzustand.
Dass dies nicht nur Theorie, sondern gelebte Praxis ist, zeigt beispielsweise Infineons Automotive Virtual Prototype für seine zukünftigen RISC-V-basierten Mikrocontroller, der es ermöglicht, schon heute mit der Softwareentwicklung zu beginnen, auch wenn es noch gar kein Silizium gibt. Lauterbach hat dies schon mehrfach demonstriert, etwa auf der RISC-V Automotive Conference der IAA Mobility 2025 und auf zahlreichen anderen Events in aller Welt.
Und auch Texas Instruments stellte erst vor wenigen Wochen sein neuestes, TDA5 genanntes Automotive SoC auf der CES-Messe 2026 in Las Vegas vor, ohne dass es nur ein Stückchen Silizium gäbe – dafür aber ein VDK von Synopsys, auf dem schon heute mit Hilfe von TRACE32 mit der Entwicklung begonnen werden kann. Eine entsprechende Demo konnten CES-Besucher auf TIs Partner-Wall sehen.
Im finalen Schritt, nach Auslieferung der Hardware, ermöglichen dann Hardware-Module wie Lauterbachs TRACE32 PowerDebug und TRACE32 PowerTrace den direkten Zugriff auf die Register, Speicher und Peripherie des Mikrocontrollers oder Prozessors. Fehlerinjektion, Timing-Analysen, Codeabdeckungsmessungen (Code Coverage) und Trace-Funktionen stehen zur Verfügung, um Systemreaktionen und das Verhalten bei Ausnahmefällen präzise zu prüfen. Dies ist besonders relevant im Hinblick auf funktionale Sicherheit, Performance und die finale Überprüfung unter produktionsnahen Bedingungen. Über XCP- und USB-Schnittstellen lassen sich Steuergeräte später sogar im Feld analysieren.
Abgebildet in Tabelle 1 und Bild 2 sieht der Workflow aus Sicht von TRACE32 wie in Bild 3 dargestellt aus. Während in den ersten vier vECU-Schichten ausschließlich die Software zum Einsatz kommt, werden für Level 5, also den realen Chip, Hardware-Module eingesetzt, welche an die üblichen Debug-Schnittstellen wie JTAG oder DAP für Infineon AURIX bzw. Trace-Schnittstellen wie etwa HSSTP andocken.
Nahtloser Übergang von einer Entwicklungsphase zur nächsten
Ein entscheidender Punkt für die generelle Brauchbarkeit eines Entwicklungstools bei »Shift Left« besteht in der Frage, ob ein nahtloser Übergang von einer Entwicklungsphase zur nächsten gesichert ist. Was bedeutet das konkret?
Die noch einfachste Anforderung ist eine einheitliche GUI. Des Weiteren müssen alle Scripte etwa zur Testautomatisierung, die in frühen Entwicklungsphasen geschrieben wurden, später 1:1 wiederverwertbar sein, um doppelten Aufwand zu vermeiden. Die wichtigste Anforderung betrifft aber das Feature-Set, wobei hier als erstes das Multicore-Debugging von immer mehr heterogenen CPU-Cores wichtig ist. Ein Renesas-X5H-SoC der fünften R-Car-Generation beispielsweise implementiert insgesamt über 100 Arm-Cortex-Cores unterschiedlicher Art und Nicht-Arm-KI-Beschleuniger in einem AMP-Szenario.
Des Weiteren ist die speziell für SDVs wichtige Awareness für Hypervisor und Betriebssysteme zu nennen. Viele Halbleiterhersteller liefern ihren Kunden in der immer komplexeren Welt vorintegrierte und vorgetestete Software-Stacks mit, exemplarisch soll hier GreenVIP von NXP genannt werden. Bild 4 zeigt GreenVIP für das S32Z27-SoC.
Wie man unschwer erkennen kann, gibt es hier neben dem L4Re-Hypervisor von der Kernkonzept GmbH auch noch zwei weitere Echtzeitbetriebssysteme mit Zephyr und FreeRTOS sowie ein von NXP selbst entwickeltes, AUTOSAR-konformes RTOS.
Um ein solches Software-Paket inklusive seiner Anwendungen debuggen und/oder profilen zu können, muss die Software entsprechende Unterstützung liefern, die sogenannte Hypervisor- und OS-Awareness für alle entsprechenden Produkte [3]. OS-Awareness in TRACE32 bezeichnet eine Erweiterung der Software, die das zugrunde liegende Betriebssystem versteht und dessen Objekte direkt im Debugger sichtbar und auswertbar macht. Damit debuggt man nicht mehr nur »rohen« Code und Speicher, sondern sieht Tasks/Threads, ihre Zustände und weitere Kernel-Ressourcen in einer OS-spezifischen Sicht. Dies alles muss sowohl in der virtuellen als auch in der realen Chip-Welt identisch funktionieren, um einen nahtlosen Übergang sicherstellen zu können.
Neue Geschäftsmodelle für Chiphersteller: TRACE32 und Entwicklungsboards als »Hardware as a Service«
Nicht nur für die Automobilindustrie, also die Kunden der Chip-Hersteller, sondern auch für die Chip-Hersteller selbst bietet »Shift Left« die Möglichkeit, neue Geschäftsmodelle zu entwickeln.
Als Beispiel sei hier das Angebot von »Hardware as a Service« zu nennen. Bild 5 zeigt exemplarisch ein solches Szenario für den Chip-Hersteller NXP und dessen S32 Designstudio im Zusammenspiel mit einem virtuellen Target von Synopsys (VDK) und Lauterbach TRACE32 in einer AWS-Cloud. Die Idee hier besteht darin, die virtuelle Welt zu einem späteren Zeitpunkt nahtlos in die reale Chip-Welt zu transferieren.
Dazu wird den Kunden ein Cloud-Lab mit vorinstallierten Entwicklungsboards mit unterschiedlichen SoCs und daran angebundenen, vorkonfigurierten TRACE32-Tools angeboten, mit denen sie sich über das Internet verbinden und dort ihre Debugging- und/oder Profiling-Workloads abarbeiten können. Die TRACE32-GUI läuft dabei wie schon in dem virtuellen Szenario in einem Browser und lässt sich 24/7 von überall auf der Welt nutzen, solange eine Internet-Verbindung existiert. Bild 6 zeigt ein - vielleicht für die tägliche Arbeit nicht ganz realistisches, aber lauffähiges - Extrem-Szenario, bei dem die TRACE32-GUI sogar in einem Smartphone-Browser läuft.
Der Vorteil aus Kundensicht ist natürlich sofort ersichtlich: Global verteilte Entwicklungsteams haben Zugriff auf alle für sie relevanten Chips, solange der Chip-Hersteller diese im Cloud-Lab bereitstellt. Gerade in frühen Phasen, wo es nur eine limitierte Anzahl von Boards gibt, ist das ein riesiger Vorteil, abgesehen davon, dass man nicht mehr abhängig von der Anzahl der Entwicklungsstandorte identische Boards mehrfach vorhalten muss. Ein weiterer Vorteil: Wenn es Updates auf neue Board-Versionen oder auch nur eine neue Firmware gibt, wird dies zeitnah vom Chiphersteller bereitgestellt und muss nicht im Zweifel mehrfach in der ganzen Welt verteilt werden.
Folgerichtig werden derartige Ideen nicht nur von NXP, sondern auch von allen anderen wichtigen Chip-Herstellern für die Automobil-Industrie entwickelt. Es bleibt abzuwarten, wann welcher Hersteller mit welchem konkreten Angebot auf den Markt kommt.
Fazit
Der Shift-Left-Ansatz ist für die Automobilindustrie nicht mehr optional, sondern ein Muss zur Bewältigung wachsender technischer und regulatorischer Anforderungen. Durch frühe Integration von Qualitätssicherung, Simulation und Testautomatisierung profitieren OEMs und Zulieferer von schnelleren, zuverlässigeren Entwicklungszyklen und höherer Produktqualität. Lauterbach trägt dieser Entwicklung mit seinen »SDV-Ready«-TRACE32-Lösungen [4] schon heute Rechnung – durch einen nahtlosen Übergang vom Emulator bis hin ins Feld sowie die Unterstützung sämtlicher, noch so komplexer Automotive-SoCs aller einschlägigen Chip-Hersteller für SDVs. Auf der embedded world 2026 (Halle 4, Stand 210) können sich nicht nur Elektronik-Leser live am Lauterbach-Stand über unterschiedliche Cloud-Lösungen informieren.
Der Autor
Dipl.-Ing. Frank Riemenschneider studierte Elektrotechnik mit Schwerpunkt Mikroelektronik an der Leibniz-Universität in Hannover, während dem er zahlreiche Bücher und Fachartikel über Assembler-Programmierung von diversen CPUs veröffentlichte. Als Senior Marketing Engineer bei Lauterbach ist er für Online- und Print-Veröffentlichungen interner und externer Dokumente des Unternehmens auf allen Kommunikations-Kanälen verantwortlich.
Lauterbach auf der embedded world 2026: Halle 4, Stand 210
Literatur
[1] Smart Systems Engineering - Requirements for the Standardization of Virtual Electronic Control Units (V-ECUs): [2] Die breiteste Unterstützung der Industrie für Emulatoren, Simulatoren und virtuelle Targets: [3] Hypervisor- und OS-Awareness in TRACE32:
[4] »SDV Ready« TRACE32 für Software Defined Vehicles
Lesen Sie mehr zum Thema
