Wenn Embedded-Entwicklung zu langsam, teuer oder schwer beherrschbar wird

Moderne Embedded-Projekte scheitern selten daran, dass ein Team nicht programmieren kann.

Die Schwierigkeiten beginnen dort, wo Software auf die reale Plattform trifft:

Hardware ist teuer oder noch nicht verfügbar.
Tests benötigen Laboraufbauten und lassen sich nur begrenzt parallelisieren.
Produktionszyklen laufen über viele Jahre.
BSP, Betriebssystem, Interrupts, Speicherarchitektur und Hardwareabhängigkeiten sind oft nur teilweise verstanden oder dokumentiert.

Gleichzeitig sollen bestehende Systeme weiterentwickelt, auf neue Plattformen migriert und zunehmend mit KI-Unterstützung bearbeitet werden.

Genau an dieser Stelle unterstütze ich.

Hardware muss nicht der Flaschenhals sein

Für Firmwaretests ist reale Hardware häufig die knappste Ressource.

Ein Testsystem steht im Labor. Ein Fehler tritt nur unter bestimmten Zuständen auf. Mehrere Entwickler benötigen gleichzeitig Zugriff. CI/CD endet dort, wo physische Hardware erforderlich wird.

Ich entwickle virtuelle Embedded-Plattformen, auf denen reale Firmware und BSPs ausgeführt werden können.

Dabei geht es nicht nur um eine CPU-Simulation, sondern bei Bedarf um das für die Software relevante Gesamtsystem: Speicher, Interrupts, Peripherie, Busse, Kommunikationswege und externe Komponenten.

Eine solche virtuelle Plattform kann anschließend automatisiert gestartet, zurückgesetzt, manipuliert und getestet werden.

Damit werden Dinge möglich, die mit realer Hardware schwierig oder teuer sind:

1. reproduzierbare Fehlerzustände,
2. parallele Tests,
3. automatisierte Regressionen,
4. Fault Injection
5. und CI/CD bis tief in die Firmware hinein.

Reale Hardware bleibt wichtig – aber sie muss nicht mehr für jeden Entwicklungsschritt zur Verfügung stehen.

Wenn das Problem unterhalb der Applikation liegt

Viele sehr gute Softwareteams arbeiten hervorragend auf Applikationsebene.

Schwierig wird es, wenn ein Problem tiefer sitzt:

im BSP, im RTOS, im Startup-Code, in der Speicherabbildung, im Interrupt-System, in der ABI, im Compiler oder in den Eigenschaften der Hardwareplattform.

Gerade bei Migrationen reicht es dann nicht, Quellcode von einem System auf ein anderes zu übertragen.

Man muss verstehen, welche Annahmen die bestehende Software über ihre Umgebung macht.

Wie wird Speicher initialisiert?
Welche Teile hängen vom Compiler oder der Runtime ab?
Welche Interrupt- und Scheduling-Semantik wird vorausgesetzt?
Welche Hardwarezustände erwartet die Software?
Welche Abhängigkeiten sind im BSP versteckt?

Ich kann diese Ebene analysieren, modellieren und in eine kontrollierte Testumgebung überführen.

Das ist besonders hilfreich, wenn ein Team fachlich stark ist, aber für eine bestimmte Migration oder Plattform nicht dauerhaft eigene Spezialisten für Compiler, Betriebssysteme und Low-Level-Architektur vorhalten möchte.

Migration ohne Blindflug

Bei langlebigen Embedded-Produkten besteht häufig ein unangenehmer Zielkonflikt:

Die bestehende Software funktioniert – aber Toolchain, Hardware oder Entwicklungsumgebung sollen ersetzt werden.

Eine komplette Neuentwicklung ist riskant. Eine einfache Portierung reicht oft nicht aus.

Ich unterstütze solche Migrationen, indem bestehendes Verhalten zunächst reproduzierbar gemacht wird.

Die alte und die neue Umgebung können dadurch gegeneinander getestet werden.

So wird aus einer Migration kein einmaliger großer Sprung, sondern ein überprüfbarer Prozess:

Verstehen → Modellieren → Migrieren → Ausführen → Vergleichen → Verifizieren

Das gilt für klassische C/C++-Systeme ebenso wie für Ada-basierte Embedded-Software und spezielle Compiler- oder Runtime-Umgebungen.

KI hilft erst dann wirklich, wenn sie das System versteht

Auch beim Einsatz von LLMs entsteht in technischen Projekten schnell ein neues Kostenproblem.

Ein Modell bekommt ein Reference Manual, einige Source-Dateien und Compiler-Dokumentation.

Bei der nächsten Aufgabe werden dieselben Dateien erneut gelesen.

Und bei der nächsten wieder.

Das kostet Kontext, Tokens und Zeit – und trotzdem fehlt häufig die Verbindung zwischen den Informationen.

Ich verwende deshalb Knowledge Graphs und GraphRAG.

Technisches Wissen wird einmal strukturiert extrahiert und miteinander verknüpft.

Zum Beispiel:

Source Code → Funktion → Register → Peripheral → Hardwareverhalten → Requirement → Test

oder:

Ada Source → Sprachsemantik → Compiler → Runtime → generierter Code → Test

Ein Modell muss dadurch nicht immer wieder hunderte oder tausende Seiten Dokumentation durchsuchen.

Es erhält gezielt den Teil des Wissens, der für die aktuelle Aufgabe relevant ist.

Das reduziert Tokenverbrauch und macht KI-Unterstützung gleichzeitig präziser und nachvollziehbarer.

Für große Dokumentations- und Codebestände betreibe ich dafür eine lokale Infrastruktur, mit der technische Informationen massiv parallel extrahiert und in strukturierte Wissensbasen überführt werden können.

KI bekommt nicht nur Dokumente – sondern Werkzeuge

Der nächste Schritt besteht darin, das Modell nicht nur lesen zu lassen.

Über MCP kann ein Modell kontrollierten Zugriff auf Entwicklungswerkzeuge erhalten.

Es kann beispielsweise:

• Firmware analysieren,
• Informationen aus dem Knowledge Graph abrufen,
• Tests erzeugen oder starten,
• einen Emulator bedienen,
• Speicher- und Registerzustände untersuchen,
• Compilerergebnisse vergleichen
• und Fehler systematisch eingrenzen.

Damit verändert sich die Rolle der KI.

Sie produziert nicht einfach möglichst plausiblen Code.

Sie arbeitet innerhalb einer Engineering-Umgebung, in der ihre Ergebnisse überprüft werden können.

Von der KI-generierten Idee zum verifizierten Ergebnis

Für mich ist ein von einem Modell erzeugter Patch noch kein Ergebnis.

Erst wenn er kompiliert, ausgeführt und getestet wurde, wird daraus Engineering.

Deshalb verbinde ich KI-Unterstützung mit ausführbaren Systemmodellen und automatisierter Testtechnik.

Meine Testumgebung kann unter anderem Firmware auf virtuellen Zielsystemen ausführen, Speicher- und Hardwarezustände beeinflussen, Fehler injizieren, mehrere Geräte miteinander verbinden und Testergebnisse mit Requirements verknüpfen.

So entsteht ein geschlossener Prozess:

Dokumentation → strukturiertes Wissen → Analyse → Implementierung → Ausführung → Test → Verifikation

Wo ich sinnvoll unterstützen kann

Meine Arbeit ist besonders dann sinnvoll, wenn Sie vor einem Problem stehen, für das normale Applikationsentwicklung allein nicht mehr ausreicht.

Zum Beispiel:

Eine neue Embedded-Plattform soll entwickelt werden, während die Hardware noch nicht vollständig verfügbar ist.

Eine bestehende Firmware soll auf eine andere Hardware, Toolchain oder Entwicklungsumgebung migriert werden.

Ein Team benötigt Unterstützung bei BSP, RTOS, Speicherarchitektur, Interrupts oder anderen Low-Level-Themen.

Tests sind heute zu stark an physische Geräte und Laboraufbauten gebunden.

Ein komplexes Embedded-System soll in CI/CD integriert werden.

Ein großer Bestand technischer Dokumentation soll für KI effizient nutzbar gemacht werden.

LLMs verursachen hohe Kosten, weil dieselben technischen Quellen immer wieder in den Kontext geladen werden.

Oder eine bestehende Codebasis ist so groß und spezialisiert, dass Entwickler und KI zunächst eine gemeinsame, strukturierte Wissensbasis benötigen.

Engineering-Unterstützung dort, wo Software auf das System trifft

Ich arbeite an der Grenze zwischen Software, Compiler, Betriebssystem und Hardware.

Dazu gehören moderne ARM-Systeme von Cortex-M/Thumb-2 bis Cortex-A ebenso wie PowerPC/VLE-basierte Plattformen.

Die konkrete Architektur ist dabei nicht das Produkt.

Entscheidend ist die Fähigkeit, ein reales technisches System so weit zu verstehen und zu modellieren, dass Software darauf entwickelt, migriert, getestet und mit KI-Unterstützung analysiert werden kann.

Wenn Hardware, Toolchain, Betriebssystem, Firmware und Dokumentation gemeinsam betrachtet werden müssen, kann ich genau an dieser Stelle unterstützen.