Der »Shift-Left«-Ansatz verlagert Qualitätssicherung und Test in ein möglichst frühes Stadium des Entwicklungsprozesses und legt auf einen nahtlosen Übergang zwischen virtuellen und physischen Umgebungen Wert. Ein weiterer Trend ist Entwicklung in der Cloud.
Curt Hillier, Fellow, Vehicle Systems Engineering, NXP Semiconductors, und Rudi Dienstbeck, Lead Architect Automotive, Lauterbach Engineering, erläutern die Hintergründe.
Elektronik: Was bedeutet »Shift Left« bei der Entwicklung von SDV und anderen Anwendungen in Bezug auf die Toolchain?
Curt Hillier: Dank »environmental parity« ist die Toolchain in der »Shift-Left«-Umgebung dieselbe wie in der »Stretch-Right«-Phase. Das Ziel ist es, nahtlos zwischen virtuellen und physischen Umgebungen wechseln zu können, um die Entwicklung für die Anwender zu beschleunigen.
Rudi Dienstbeck: Nahtloser Übergang bedeutet beispielsweise eine einheitliche GUI, 1:1-Wiederverwendbarkeit aller Skripte, etwa für die Testautomatisierung, und den Funktionsumfang, wobei das Multicore-Debugging zunehmend heterogener CPU-Kerne der wichtigste Faktor für SDVs ist. Darüber hinaus sollte auch die für SDVs besonders wichtige Awareness von Hypervisors und Betriebssystemen erwähnt werden. In einer zunehmend komplexen Welt liefern viele Halbleiterhersteller ihren Kunden vorintegrierte und vorab getestete Software-Stacks. Ein Beispiel ist der Stack »GreenVIP« von NXP, der neben dem L4Re-Hypervisor der Kernkonzept GmbH auch zwei weitere Echtzeitbetriebssysteme, Zephyr und FreeRTOS, sowie ein von NXP selbst entwickeltes AUTOSAR-konformes RTOS enthält. OS-Awareness in TRACE32 bezieht sich auf eine Erweiterung der Software, die die zugrunde liegenden Betriebssysteme versteht und deren Objekte direkt im Debugger sichtbar und auswertbar macht. Das bedeutet, dass Anwender nicht mehr nur »rohen« Code und Speicher debuggen, sondern Tasks/Threads, deren Zustände und andere Kernel-Ressourcen in einer betriebssystemspezifischen Ansicht sehen können. All dies muss sowohl in der virtuellen als auch in der realen Chip-Welt identisch funktionieren, um den oben erwähnten nahtlosen Übergang zu gewährleisten.
Was bedeutet »Entwicklung in der Cloud«?
Curt Hillier: Wir nutzen Rechenzentrums-Technologien (Cloud-Technologien), um eine flexible Skalierbarkeit, Portabilität und eine hochwertige, reproduzierbare Entwicklungsumgebung zu bieten. Eine Entwicklungsumgebung umfasst ein Host-Betriebssystem (wie Linux oder Windows), Compiler, Debugging-Software, AUTOSAR-Stacks und Konfigurationstools. Sie kann auch virtuelle Prototypen und Verbindungen zu Hardware-Board-Farms umfassen. Stellen Sie sich einen »Laptop« in der Cloud vor, bei dem sich die Entwicklungsumgebung auf Basis automatisierter Regressionstests und der Anforderungen der Entwickler dynamisch nach oben oder unten skalieren lässt.
Rudi Dienstbeck: Das Bild zeigt eine beispielhafte Konfiguration unserer TRACE32-PowerView-Software mit NXPs Cloud Studio und einem NXP-S32-VDK von Synopsys. Wir werden dies in einer Präsentation auf der embedded world Conference näher erläutern.
Wie funktioniert die Entwicklung in der Cloud? Wie gehen Entwickler vor?
Curt Hillier: Die Benutzer greifen mit ihren Anmeldedaten auf die cloudbasierte Entwicklungs-Workbench zu. Nach der Anmeldung steht den Entwicklern eine vorkonfigurierte Workbench mit Debugging-Software, integrierter Entwicklungsumgebung (Frontend), Compilern, Backend und zugehörigen Tools wie etwa KI/ML-Software, modellbasierter Design-Software und Git-Repository-Zugriff zur Verfügung. Die Entwickler haben außerdem eine Auswahl an Testzielen, darunter virtuelle Prototypen und Hardware-Steuergeräte (ECUs) und/oder Evaluierungsboards (EVBs) von Zulieferern.
Rudi Dienstbeck: In Social Media wird oft ein Szenario für Remote-Arbeit gezeigt, in dem jemand irgendwo in der Karibik unter Palmen sitzt, eine Sonnenbrille auf der Nase und einen Laptop vor sich. Mit einer stabilen Internetverbindung und unserer TRACE32-PowerView-Software-Schnittstelle in einem Webbrowser können Entwickler tatsächlich vom Strand aus debuggen, theoretisch sogar am Smartphone, obwohl zugegebenermaßen die Benutzerfreundlichkeit des kleinen Smartphone-Bildschirms für solche Tätigkeiten nicht wirklich optimal ist.
Welche Toolchain wird für die Entwicklung in der Cloud benötigt, und was leisten die einzelnen Tools?
Curt Hillier: Die Toolchain umfasst in ihrer einfachsten Form einen Texteditor, einen Compiler (z.B. GCC), einen Debugger und eine Konsolenoberfläche zur Überwachung der Zielaktivität sowie ein Testziel (physische Platine oder virtueller Prototyp). In ihrer komplexeren Form umfasst die Toolchain unter anderem physische Stimuli wie etwa CAN-Testschnittstellen, eine Ethernet-Testschnittstelle, Machine Learning SDK und modellbasierte Design-Software.
Rudi Dienstbeck: Wie bei echten Chips müssen die Tools natürlich auch die digitalen Zwillinge in Bezug auf ihren Funktionsumfang vollständig unterstützen. In dieser Hinsicht gibt es für uns keinen Unterschied.
Was sind die Vorteile der Entwicklung in der Cloud gegenüber herkömmlichen Entwicklungsmethoden?
Curt Hillier: Die Hauptvorteile sind Geschwindigkeit, Skalierbarkeit und Synchronisation. Die höhere Geschwindigkeit führt dazu, dass jeder Entwickler die Toolchain nicht mehr mühsam in seiner eigenen Entwicklungsumgebung installieren und konfigurieren muss. Skalierbarkeit bedeutet, dass Sie die cloudbasierten Arbeitsumgebungen je nach Bedarf auf der Grundlage von Regressionstests und den Entwicklungsanforderungen von Menschen und KI replizieren können. Synchronisation bedeutet, dass Ihr gesamtes Entwicklungsteam und Ihre Regressionstests von einer standardisierten Entwicklungsumgebung profitieren, wodurch das Problem »Auf meinem Rechner funktioniert es« beseitigt wird.
Inwieweit kann die Entwicklung in der Cloud die Komplexität reduzieren?
Curt Hillier: Wenn es richtig gemacht wird, entfällt für Entwickler die Komplexität der Installation, Konfiguration, Lizenzierung und Fehlerbehebung der Toolchain. Außerdem können Entwickler so Workbenches für ein gesamtes, weltweit verteiltes Team freigeben.
Wie unterscheiden sich Entwicklungsprozesse in der Cloud je nach dem im Zielsystem verwendeten SoC?
Curt Hillier: Die Grundlagen der Prozesse sind in Bezug auf Tools, Compiler und Debugger identisch - sie unterstützen die DevOps-Methodik für Build, Test und Deployment. Die Prozesse können sich unterscheiden, wenn es um Multicore-SoCs geht (hier sind komplexere Debugging- und Konfigurationstools erforderlich). Das Ziel ist es, einheitliche Tools für alle SoC-Produktfamilien zu verwenden, damit Kunden bewährte Methoden, Regressionstests und Flash-Programmierskripte über alle SoC-Familien hinweg wiederverwenden können.
Rudi Dienstbeck: Weil unsere TRACE32-Software alle SoCs aller relevanten Automobilchip-Hersteller unterstützt, unabhängig von ihrer Komplexität, können unsere Kunden problemlos von einem Chip zum anderen wechseln, ohne jedes Mal von vorne beginnen zu müssen. Dies gilt sowohl für digitale Zwillinge als auch für echte Chips. Weitere Informationen hierzu sind unter www.lauterbach.com/sdv zu finden.
Last but not least: SDVs verändern die Welt der Software-Entwicklung. Angesichts von über 2 Milliarden US-Dollar an entgangenen Gewinnen aufgrund von Software-Rückrufen im Jahr 2025 ist die Wahl klar: Entweder man ist Teil der Lösung oder Teil des Problems. Die Zusammenarbeit zwischen dem Automobilhalbleiter-Lieferanten NXP und dem Tool-Anbieter Lauterbach ist Teil der Lösung. Auf der embedded world 2026 demonstrieren wir am Lauterbach-Stand 210 in Halle 4 die Cloud-Entwicklung mittels eines virtuellen S32-SoC von NXP und den nahtlosen Übergang zum realen Chip.
Lauterbach: Halle 4, Stand 210
NXP: Halle 4A, Stand 222; Halle 3A, Stand 128