Gegenwart und Zukunft von Entwicklungs-Tools

Embedded-/Edge-KI, das Software-Defined Vehicle (SDV), Security-by-Design und immer vielschichtigere Embedded-SoCs mit integrierter KI-Verarbeitung: All diese Trends wirken sich auf die Entwicklungstools aus. Doch was ändert sich bei den Tools konkret, und was folgt daraus für Embedded-Entwickler?

Drei Experten dreier verschiedener Toolhersteller informieren.

Markt&Technik: Welche Trends zeigen sich derzeit bei Entwicklungstools?

Jörg Stender, Managing Director bei Hitex: Wir sehen vor allem einen starken »Shift Left« in die frühen Entwicklungsphasen. Die Möglichkeiten zur Simulation werden deutlich besser, entsprechend verschiebt sich auch das Debugging nach vorne. Damit einher geht die wachsende Bedeutung von Testtools – sie werden mächtiger und sind früher im Prozess gefragt.

KI muss wohl genannt werden, ist aber bereits kein Trend mehr, sondern Grundvoraussetzung. Wer sie nicht nutzt, beim Codieren, beim Erstellen von Requirements, beim Support oder beim Aufspüren von Bugs und fehlerhaften Konfigurationen, der ist schlicht zu langsam.

Hinzu kommt der zunehmende Einsatz von Open-Source-Software, wobei man hier gerade bei Safety- und Security-kritischen Applikationen sehr aufmerksam sein muss.

Und schließlich der Trend zu integrierten Plattformen: In der Entwicklung will man nicht mehr zehn Einzeltools mühsam integrieren, sondern eine funktionale Umgebung haben. Infineons DriveCores etwa bündeln verschiedene Toolketten für Automotive-Mikrocontroller in einem fertigen Paket. Ähnliches leistet Visual Studio Code, das Tools wie Arm Keil Studio nahtlos integriert.

Holger Lohn, Produktmanager für Debug- und Trace-Tools bei Lauterbach: Generell wird die Tool-Landschaft breiter, weil die rechtlichen und technischen Anforderungen stetig wachsen, beispielhaft seien hier der Cyber Resilience Act (CRA) der EU und das SDV genannt. Daher werden Kollaborationen in der Tool-Industrie noch wichtiger.

Wenn man speziell die Autoindustrie anschaut, erleben wir durch die sogenannte »China Speed«, d.h. hohe Innovationsgeschwindigkeit und die Bereitschaft, neue Technologien schnell in die Produktion zu überführen, Veränderungen im Entwicklungsprozess.

Dies startet mit Evaluationspackages, in denen komplexe Software-Stacks vom Chiphersteller pre-integriert und pre-validiert sind, etwa CoreRide von NXP oder DriveCore von Infineon. Weitere Trends sind zentrale Testlabore mit Hardware-as-a-Service-Angeboten, die Entwicklung auf virtuellen Targets in der Cloud lange vor dem ersten Silizium-Chip, Testautomatisierung mittels CI/CD-Pipelines und die Unterstützung des gesamten Produktlebenszyklus vom Emulator bis ins Feld.

Und last but not least: »Everybody wants to do AI«. Wir bei Lauterbach haben unsere »TRACE32«-Toolchain frühzeitig auf diese Veränderungen vorbereitet und können die veränderten und gewachsenen Anforderungen im Entwicklungsprozess abdecken.

Jens Braunes, Product Marketing Manager bei PLS: SoC werden nach wie vor immer komplexer, vereinen immer mehr Cores und Peripherie in einem Chip, übernehmen immer mehr Funktionen. Die grundsätzliche Herausforderung für Debug- und Trace-Tool-Hersteller besteht darin, dafür zu sorgen, dass Systementwickler diese enorm vielfältigen technischen Möglichkeiten und Fähigkeiten auch in Zukunft noch vollumfänglich nutzen können. Dies erfordert auf der Toolseite für jede neue Architektur und jede neue Chipgeneration jedes einzelnen Halbleiterherstellers nach wie vor viel individuelle Optimierungsarbeit. Gerade bei den Automotive-Controllern zeigt sich der Trend zu immer mehr Kernen in einem Chip und dabei auch Heterogenität in den Core-Architekturen. Vor allem diese Konstellation ist hinsichtlich der Chipanpassung besonders herausfordernd. So muss beispielsweise das synchrone Run-Control der UDE (Universal Debug Engine) von PLS für die heterogenen Cores auf die hardwareseitig vorgegebenen On-Chip-Debug-Systeme abgestimmt werden. Gerade bei der Unterstützung der Automotive-Controller, wie etwa dem Infineon Aurix oder den Bausteinen der S32 Automotive Processing Platform von NXP, ist PLS hervorragend aufgestellt.

Parallel zur immer noch großen Dominanz von Arm Cortex hält im Automotive- und Industrial-Sektor in immer mehr Anwendungen auch RISC-V Einzug, weshalb PLS die umfangreichen Debug-, Trace- und Systemanalyse-Funktionen der UDE seit geraumer Zeit auch für diese Controller bereitstellt. Beispielsweise integriert gerade Infineon die RISC-V-Architektur in seine Mikrocontroller, und PLS bietet schon jetzt Unterstützung für den virtuellen Prototypen. Damit können Entwickler bereits jetzt mit der Softwareentwicklung beginnen, lange bevor sie reales »Silizium« auf dem Tisch haben.

Auch am Thema KI kommt inzwischen kein Debug- und Trace-Tool-Hersteller mehr vorbei. Aktuell arbeiten wir bei PLS gerade daran, durch die Kopplung unseres Tools mit KI-Funktionen das Debugging im Entwickleralltag nochmals deutlich zu vereinfachen und noch effizienter zu gestalten. KI spielt zunehmend aber auch in Embedded-Systemen unserer Kunden eine große Rolle. Wir reden hier beispielsweise von Beschleunigerkernen mit hoher Datenparallelität, spezialisiert für KI-Algorithmen, integriert in heterogenen SoCs. Aktuelle Tools wie die UDE bieten inzwischen natürlich auch für solche neuen technischen Features optimierte Debug-Funktionen.

Welche Rolle spielen die Themen Functional Safety und Cybersecurity für Entwicklungstools?

Jörg Stender, Hitex: Eine signifikante. Gerade bei Cybersecurity kommen mit KI ja ständig neue Angriffsmöglichkeiten dazu. Dazu rücken Fuzzing und Penetrationstests stärker in den Fokus. Treiber ist unter anderem der Cyber Resilience Act, der Security by Design explizit vorschreibt und Konzepte wie Root of Trust und Secure Boot in den Vordergrund rückt. Konsequenterweise gewinnt dabei der DevSecOps-Ansatz an Bedeutung: Security muss von Anfang an in die CI/CD-Pipeline integriert sein. Testtools für Security werden damit genauso wichtig wie die für Safety, die wir schon lange kennen. Um dennoch schnell und zugleich sicher auf den Markt zu kommen, hilft in der Produktentwicklung der Einsatz vorqualifizierter Softwarekomponenten, etwa Treiber aus Safety- und Security-Suites wie unserem SafeTpal, die sich direkt im Produktiveinsatz verwenden lassen.

Holger Lohn, Lauterbach: Functional Safety war und ist für alle sicherheitskritischen Industrien, in den wir uns bewegen, natürlich essenziell. Unsere TRACE32-Tools sind für alle wichtigen Normen vorqualifiziert, um den Kunden die Zertifizierung so einfach wie möglich zu machen. Hinzu kommt die Integration mit allen wichtigen Test-Tools unserer Partner beispielsweise für Timing-Analysen und Code-Coverage-Messungen, exemplarisch seien an dieser Stelle nur Rapita, Vector, LDRA, Gliwa, Parasoft und MathWorks genannt.

Weiterhin machen wir unsere Tools selbstredend auch cyber-sicher. Der bereits genannte CRA ist die erste europäische Verordnung, die Cybersicherheit für alle vernetzten Produkte festlegt, wozu natürlich auch unsere Debugger gehören. Was die Kundenprojekte angeht, schaffen unsere Tools überhaupt erst die Möglichkeit, Funktionalität auf Cybersicherheit und auf funktionale Sicherheit zu testen, konkret bei Penetrationstests. Diese dienen als proaktive, offensive Maßnahme, um Sicherheitslücken zu identifizieren und zu beheben, bevor Angreifer sie ausnutzen können. Penetrationstests kann man mit unseren TRACE32-Tools durchführen. Wir kooperieren dafür auch mit einschlägigen Technologieführern, etwa der Firma Schutzwerk (www.schutzwerk.com).

Im Kontext von Fahrzeugsystemen zielen Penetrationstests auf eingebettete Komponenten wie Steuergeräte, Gateways und Telematikeinheiten sowie auf verbundene mobile Apps und die Backend-Cloud-Infrastruktur ab. Das primäre Ziel solcher Tests besteht nicht nur darin, Schwachstellen zu finden, sondern zu verstehen, wie diese miteinander verkettet werden könnten, um die Fahrzeugsicherheit, die Datenintegrität oder die Fernfunktionalität zu gefährden. Dafür spielen unsere TRACE32-Tools eine entscheidende Rolle.

Jens Braunes, PLS: Anders als beim Compiler, dessen Output sich direkt im Endprodukt wiederfindet, hat das Debug- und -Trace-Tool selbst hinsichtlich Functional Safety oder Cybersecurity keinen direkten Impact in die Applikation. Nichtsdestotrotz trägt der Debugger als wichtiges Werkzeug für den Test und die Behebung etwaiger Fehler wesentlich zur Softwarequalität der Endprodukte unserer Kunden bei.

Welche Rolle spielt das Software-Defined Vehicle (SDV) für Entwicklungstools?

Jörg Stender, Hitex: Die Anforderungen steigen massiv. Vieles, was früher durch physikalische Sicherheitsmechanismen im Fahrzeug gewährleistet wurde, muss heute von Software übernommen werden. Damit wird die Absicherung im Vorfeld zwingend notwendig. Functional Safety für Software bekommt dadurch noch mehr Gewicht. Hier helfen wieder standardisierte und qualifizierte Komponenten weiter. Gleichzeitig steigt die Softwarekomplexität erheblich: Multicore- und Multiprozessor-Architekturen ebenso wie Zonencontroller erfordern leistungsfähigere Entwicklungs- und Testtools sowie Experten in der Entwicklung, die mit dieser Komplexität umgehen können.

Holger Lohn, Lauterbach: Im SDV kommen Konzepte zum Einsatz, die man bislang im Automobilbereich noch nicht kannte: High-Performance Computing (HPC), Virtualisierte Systeme unter Kontrolle eines Hypervisors, heterogene Multicore-SoCs, komplexe Software-Stacks mit mehreren Betriebssystemen, Container für Over-the-Air-Updates - und vieles mehr.

Ein Entwicklungstool für SDVs muss dies alles unterstützen; es reicht nicht mehr, einige wenige Automotive-typische Mikrocontroller mit einheitlicher CPU-Architektur und vielleicht noch einem RTOS zu berücksichtigen. TRACE32 ist »SDV Ready«, weil alle genannten Konzepte einschließlich neuer, hochkomplexer Manycore-SoCs unterstützt werden, etwa Qualcomm Snapdragon oder Nvidia Drive, die von Mercedes, BMW, der VW-Gruppe, Hyundai und anderen OEMs, die das nicht öffentlich kommuniziert haben, eingesetzt werden.

Jens Braunes, PLS: Auch beim SDV muss die Software nach wie vor in einer CPU bzw. mehreren CPUs ausgeführt werden. Allerdings ändert sich die E/E-Architektur (Elektrik/Elektronik) grundlegend. So werden die vielen dezentralen Steuergeräte mit kleinen Mikrocontrollern durch wenige, zentrale Domänen- oder Zonen-Controller mit entsprechend leistungsfähigen Multicore-SoCs ersetzt. Für das Debug-Tool bedeutet das, dass gleichzeitig alle in diesen SoCs integrierten Cores und darüber hinaus das SoC als solches mit seinem On-Chip Debug- und Trace-System unterstützt werden müssen. In Echtzeit wohlgemerkt, eine Aufgabe, die viel Know-how beim Toolhersteller erfordert.

Ein weiterer Aspekt beim SDV sind die Software-Updates. Diese erfolgen »Over-the-Air« und werden durch Hardware-Unterstützung in den Domänen- oder Zonen-Controllern abgesichert. Auch hierfür bedarf es geeigneter Tools zur Konfiguration. In der UDE bzw. in der darin integrierten Programmierkomponente UDE Memtool sind hierfür spezielle Funktionen vorgesehen.

Welche Bedeutung haben neue Embedded-Prozessoren/-SoCs mit GPU, NPU/KI-Beschleuniger und Secure Element für Entwicklungstools?

Jörg Stender, Hitex: Durch KI-Beschleunigung, GPUs, NPUs und Secure Elements werden Chips immer komplexer. Das lässt die Anforderungen an die Tools kontinuierlich steigen. Komplexere Chips bedeuten eben auch komplexere Software, und beides muss in der Entwicklung beherrscht werden. Eine sinnvolle Strategie ist es, in einzelnen Projektphasen externe Spezialisten hinzuzuziehen. Diese haben durch ihre Partnerschaften oft früher Zugriff auf neue Prozessor-Generationen und Neuerungen bei Entwicklungstools und können ihre Expertise direkt ins Projekt einbringen – gerade bei neuen Prozessorstandards wie RISC-V ein echter Vorteil.

Holger Lohn, Lauterbach: Neue Prozessoren sind für Lauterbach »daily business«, SoCs werden immer komplexer, und die Aufgabe besteht darin, Kunden den Zugang zu allen Prozessor-Varianten zu gewährleisten.

Was das Thema KI angeht, gibt es zwei Ausprägungen: Zum einen die Implementierung von KI in Software, ein weiterer Trend seit etwa drei bis vier Jahren. Hierfür werden auf CPU-Ebene Vector-Erweiterungen genutzt, die KI-Modelle boosten und die man mit TRACE32 klassisch debuggen kann. Daneben gibt es aber auch hochspezialisierte NPUs, die herkömmlich nicht debugbar sind. Wichtig ist aber auch hier, feststellen zu können, welche Datenströme hinein- und hinausgehen, etwa bei den zahlreichen KI-Beschleuniger-Cores in den neuen R-Car-5-SoCs von Renesas, die Manycore-Support des Tools erfordern.

Jens Braunes, PLS: Wie bereits gesagt, spielt in den aktuellen SoC-Generationen Heterogenität eine große Rolle. Infolgedessen ist es für den Debugger unerlässlich, alle jeweiligen Core-Architekturen zu unterstützen und auch das Zusammenspiel der Cores untereinander hinsichtlich des On-Chip-Debug-Systems zu beherrschen. Ein wesentlicher Aspekt ist dabei die konfigurierbare Debug-Synchronisierung, beispielsweise am Breakpoint. Dieses Feature ist essenziell, um einerseits einen konsistenten Zustand des Gesamtsystems zu gewährleisten, andererseits aber gleichzeitig das Laufzeitverhalten nicht unnötig durch den Debugger zu beeinflussen. Denn meist arbeiten solche applikationsspezifischen Spezial-Kerne sehr lose gekoppelt und weitestgehend unabhängig vom sogenannten Mikrocontrollerteil des SoC.

Was bedeutet »Shift Left« bei der Embedded-Entwicklung?

Jörg Stender, Hitex: »Shift Left« heißt, dass mehr Validierung und Absicherung in frühere Phasen verlagert wird – und zwar auch schon ohne Hardware. Bereits in der Spezifikationsphase werden die Testfälle mitdefiniert und im Idealfall direkt in der Simulation ausgeführt. Das Ziel: schneller sein und Fehler vermeiden, bevor sie teuer werden.

Holger Lohn, Lauterbach: Dank der »Umgebungsparität« ist die Toolchain in der »Shifted-Left«-Umgebung dieselbe wie in der »Stretch-Right«-Phase. Das Ziel besteht darin, nahtlos zwischen virtuellen und physischen Umgebungen wechseln zu können, um die Entwicklung für Anwender zu beschleunigen.

Nahtloser Übergang bedeutet beispielsweise eine einheitliche Benutzeroberfläche, die 1:1-Wiederverwendbarkeit aller Skripte beispielsweise für die Testautomatisierung, sowie einen Funktionsumfang entsprechend den oben genannten Themen heterogenes Multicore-Debugging oder OS- und AUTOSAR-Awareness, um die zugrunde liegenden Betriebssysteme zu verstehen und deren Objekte direkt im Debugger sichtbar und auswertbar machen zu 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.

Weitere Details zum Thema »Shift Left« sind in einem Doppelinterview von Lauterbach und NXP in der Markt&Technik-Ausgabe 8/2026 ab Seite 40 zu finden.

Jens Braunes, PLS: Vereinfacht gesagt bedeutet »Shift Left«, die Software-Entwicklung und auch den Test so früh wie möglich zu beginnen, auch wenn die verwendete Hardware-Plattform noch nicht real verfügbar ist. Pre-Silicon-Entwicklung auf virtuellen Prototypen trägt heutzutage entscheidend zur signifikanten Verkürzung der Time-to-Market bei.

In den letzten Jahren haben sich durch diesen Trend auch die Anforderungen an die jeweils zum Einsatz kommenden Debug-Tools verändert. Lange Zeit wurde der sogenannte JTAG-Debugger mit der Debug-Probe immer für das Cross-Debugging auf einem realen Target genutzt, dem Mikrocontroller oder Embedded-Prozessor. Mittlerweile wird das reale Target immer häufiger durch ein virtuelles Target – typischerweise einen Simulator – ersetzt. Dabei gibt es zwei unterschiedliche Ansätze. Entweder wird das Gesamtsystem simuliert, was auch wegen der meist sehr teuren virtuellen Prototypen und Simulatoren entsprechend aufwändig ist, oder es reicht aus, auf einen Instruction-Set-Simulator zurückzugreifen. Letzteres funktioniert ganz gut, solange man kleine, in sich abgeschlossene Module entwickelt und testet.

Welche Rolle spielen KI-Werkzeuge/-Copilots/-Agenten, App-Frameworks und andere neue Hilfsmittel bei der und für die Entwicklung?

Jörg Stender, Hitex: KI-basierte Tools für Embedded-Entwicklung und -Validierung machen uns schneller und produktiver. Wie gesagt: Wer KI nicht einsetzt, ist zu langsam. Diese Tools werden immer mehr Prozessschritte und auch Menschen unterstützen und dabei Kapazitäten für anspruchsvollere Aufgaben freisetzen. Allerdings gewinnt dadurch die Validierung noch mehr an Bedeutung. Man hat es quasi mit einem nicht menschlichen Teammitglied zu tun, zu dem keine gewachsene Vertrauensbasis besteht. Man muss prüfen, was da geliefert wird. Auch beim Einsatz von KI in der Validierung selbst braucht es daher Experten, die nicht nur die Embedded-Entwicklung verstehen, sondern auch die Arbeitsweise und Grenzen der KI-Tools kennen.

Holger Lohn, Lauterbach: Entwickler wollen sich von KI-Agenten helfen lassen; ein großer Trend ist beispielsweise, dass die KI Code liefert. Man muss das Ergebnis trotzdem überprüfen, d.h. Debugger werden auch weiterhin benötigt. Die Anforderung hier ist, dass KI den Debug-Prozess unterstützt, etwa durch eine Spracheingabe, im nächsten Schritt mehr auf High-Level, etwa »finde heraus, welche Funktion welche Variable verändert«, und am Ende wird dann irgendwann das Thema »Bugs selbstständig finden« stehen. Das bedeutet, dass bei einer fortschreitenden Evolution von KI-Systemen das Debugging dann letztendlich von einer KI selbstständig erledigt wird. Ein Entwickler wird dann sagen: »Schreib mir einen Code abc, der auf dem Target xyz fehlerfrei läuft«. Unsere Tools wird es weiterhin geben, weil die KI ja auf die Hardware und den Debugger zugreifen können muss. Der Debugger wird nur nicht mehr aktiv vom Entwickler angesteuert, sondern von der KI im Hintergrund.

Jens Braunes, PLS: Es ist schwer zu beantworten, wie dieses Thema im Einzelfall bei unseren Kunden gehandhabt wird, aber dass KI generell zunehmend auch in der Entwicklung Einzug hält, steht inzwischen außer Frage. Schon heute können KI-Werkzeuge einen deutlichen Mehrwert bei der Entwicklung bieten. Als Beispiel sei nur die automatische Generierung von Testfällen für bereits bestehenden Code genannt. Das ist ein deutlicher Zugewinn im Hinblick auf die Softwarequalität und -stabilität. In anderen Bereichen stößt die Unterstützung durch KI-Tools aus eigener Erfahrung derzeit aber noch an ihre Grenzen. Rein technisch gesehen kann die KI zwar »coden«, an der Softwarearchitektur selbst scheitert sie aber (noch).

Wie wirkt sich der Trend zu Embedded-/Edge-KI auf die Entwicklungstools aus?

Jörg Stender, Hitex: Die Tools müssen sich anpassen. Zum einen braucht es Werkzeuge, die mit den großen Datenmengen umgehen können, die bei KI anfallen. Zum anderen sind Tools erforderlich, die die spezifischen Anforderungen von Edge-KI abbilden, etwa beim Debugging von KI-Beschleunigern oder bei der Optimierung für ressourcenbeschränkte Systeme.

Edge-KI bringt klare Vorteile: niedrige Latenz ohne Server-Roundtrip, Datenschutz durch lokale Verarbeitung, Funktionsfähigkeit ohne Netzwerkanbindung und Effizienz durch kompakte, stromsparende Designs.

Interessant ist auch: Mit immer leistungsfähigeren Controllern wird KI direkt im Gerät möglich. Das macht Security wieder etwas leichter kontrollierbar, weil die Daten nicht mehr nach außen müssen.

Holger Lohn, Lauterbach: Die Verifikation wird immer wichtiger, neben dem »Shift Left« im Entwicklungsprozess wird es für den Tooleinsatz auch ein »Shift Right« geben, um zu prüfen, ob das KI-Modell genau das tut, was man sich vorstellt. Dies bedeutet konkret, dass das KI-Modell anhand echter Daten überprüft werden muss. Tools werden also mehr im Testbereich eingesetzt, müssen Stimuli setzen können und schauen, was dabei herauskommt (Continuous Testing). Dieser Trend ist schon da und verstärkt sich aktuell. Das Entwicklungstool muss auch hierfür bereits sein; mit TRACE32 sind wir bei Lauterbach schon heute gut aufgestellt.

Jens Braunes, PLS: Wie gesagt, ergänzen inzwischen spezielle KI-Beschleunigerkerne die Standard-Cores der Controller. Der Debugger kann die KI-Kerne zunächst einmal über das On-Chip-Debug-System kontrollieren. Allerdings sind sie in ihrer Architektur nicht immer an der gewohnten sequenziellen Abarbeitung orientiert. Beispielsweise hat Bosch für Automotive-Applikationen eine Datenfluss-Architektur entwickelt, auf der sich hervorragend KI-Algorithmen abbilden lassen, und das mit hoher Performance bei gleichzeitig geringer Leistungsaufnahme und benötigter Chipfläche. Wir haben dafür spezielle Funktionen entwickelt und in die UDE integriert, die das Debuggen, die Laufzeitbeobachtung und auch die Validierung solcher Algorithmen erst möglich machen.

Die Fragen stellte Andreas Knoll.

Jobangebote+ passend zum Thema

Sales Manager / Vertriebsmitarbeiter (m/w/d)

Verifysoft Technology GmbH, Offenburg

---

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Lesen Sie mehr zum Thema