KI als integraler Software-Bestandteil Wenn Edge AI zur Physical AI wird

Anbieter zum Thema

IAR Systems GmbH

MicroConsult Academy GmbH

emlix GmbH

Wenn ein KI-System vom Datenerfasser zu Befehlsgeber wird, verändern sich die Anforderungen an die Embedded-Software-Entwicklung, insbesondere an die Architektur. Das muss besonders bei Safety-kritischen Systemen berücksichtigt werden.

Die Diskussion rund um Edge AI wird seit Jahren von Leistungskennzahlen dominiert: Alles dreht sich um kleinere Modelle, schnellere Inferenzen oder geringeren Energieverbrauch mit Benchmarks wie TOPS (Tera Operations Per Second) pro Milliwatt oder Latenzen im Mikrosekundenbereich. Künstliche Intelligenz auf ressourcenbeschränkte Hardware zu bringen, bedeutet tatsächlich eine enorme technische Herausforderung. Aber die Entwickler-Community hat hier bereits bemerkenswerte Fortschritte erzielt.

Doch es gibt eine Schwelle, die sich durch Leistungsmetriken allein nicht erfassen lässt: den Moment, wenn ein KI-System vom Datenerfasser zum Akteur wird. Wenn das Ergebnis der Inferenz nicht länger nur als Zahl auf einem Bildschirm erscheint, sondern ein Befehl an einen Motor, ein Ventil, eine Bremse oder ein chirurgisches Instrument geht. Genau dieser Moment markiert die Grenze zwischen Edge AI und Physical AI. Mit ihrem Überschreiten verändern sich die Anforderungen an die gesamte darunterliegende Softwarearchitektur grundlegend.

Wahrnehmung informiert, Aktuation handelt

Ein Vision-System, das Objekte auf einem Förderband erkennt und klassifiziert, ist eine klassische Edge-AI-Anwendung. Sobald dasselbe System jedoch direkt einen Roboterarm steuert, der diese Objekte sortiert, greift oder aussortiert, sprechen wir von Physical AI. Das Modell mag identisch bleiben, aber die Firmware darunter gehört jedoch plötzlich in eine völlig andere Risikoklasse.

Diese Unterscheidung ist extrem wichtig, denn die Embedded-Software-Community feilt seit Jahrzehnten an Frameworks für sicherheitskritische Systeme: IEC 61508 für industrielle Sicherheitsfunktionen, ISO 26262 für Automotive-Anwendungen oder IEC 62304 für Medizintechnik. Diese Standards existieren, weil Software, die physische Aktionen steuert, versagen kann und damit ein potenzielles Risiko darstellt, indem es Menschen verletzt, Sachschäden verursacht und damit Haftungsfolgen nach sich zieht, die sich in keinem Performance-Benchmark widerspiegeln.

Physical AI übernimmt genau diesen regulatorischen Kontext. Die KI-Schicht steht nicht außerhalb davon, sondern ist ein integraler Bestandteil.

Wo die Lücke entsteht

Die meisten Embedded-Teams, die heute Physical-AI-Systeme entwickeln, arbeiten an der Schnittstelle zweier Disziplinen, die früher kaum dieselbe Sprache gesprochen haben. Die Machine-Learning-Community konzentriert sich auf Modellgenauigkeit, Trainingspipelines und Inferenzoptimierung. Die Safety-Engineering-Welt denkt in ASIL-Stufen, Tool-Qualifizierung, statischer Analyse und deterministischer Ausführung.

Beide Perspektiven haben ihre Richtigkeit. Aber die Herausforderung liegt in ihrer Schnittmenge. Eine typische Physical-AI-Architektur besteht aus einem Mikrocontroller mit Regelkreis, einer Neural-Network-Inference-Engine zur Entscheidungsfindung und Aktuator-Treibern zur Echtzeitausführung dieser Entscheidungen. Die Modellgewichte liegen im Flash-Speicher. Die Host-Firmware – also Initialisierung, Speicherverwaltung, Interrupt-Handling sowie der Code, der die Inferenz-Engine aufruft und deren Ergebnisse an den Aktuator weitergibt – wird in C oder C++ geschrieben.

Genau dieser Host-Code unterliegt denselben Anforderungen wie jede andere sicherheitskritische Firmware: MISRA-Compliance, statische Analyse, Runtime-Verifikation, nachvollziehbare Tests und zertifizierte Toolchains.

Das Modell liefert die Intelligenz. Die Firmware bildet die Sicherheitsgrenze. Aber genau in diese Firmware investieren viele Physical-AI-Teams zu wenig, weil der Fokus primär auf der Modellqualität liegt.

Die Zertifizierungsfrage, die in der Demo-Phase niemand stellt

In der Prototypenphase werden Physical-AI-Systeme vor allem anhand ihrer Fähigkeiten bewertet: Vermeidet der Roboterarm Hindernisse? Erkennt das Predictive-Maintenance-System Abweichungen von der Norm? Reagiert die Prothesensteuerung in weniger als zehn Millisekunden? Das sind die richtigen Fragen für einen Prototypen. Es sind aber nicht die entscheidenden Fragen für ein Produkt.

Denn die zentrale Frage für regulierte Märkte lautet: Kann nachgewiesen werden, dass die Software in einem kontrollierten und dokumentierten Entwicklungsprozess entstanden ist? Wurde sie mit einer qualifizierten Toolchain erstellt, anhand definierter Coding-Standards analysiert und mit nachvollziehbarer Testabdeckung geprüft? Lässt sich im Audit der Weg vom Quellcode bis zur ausgelieferten Binärdatei vollständig rekonstruieren?

Das ist keine regulatorische Formalität, sondern stellt die operative Trennlinie zwischen einem Physical-AI-Demonstrator und einem marktfähigen Physical-AI-Produkt dar. Teams, die Compliance erst nach erfolgreichem Funktionsnachweis prüfen, stellen regelmäßig fest, dass frühere Entwicklungsentscheidungen problematisch werden: ungeeignete Toolchains, Analyse-Lücken oder ungetestete Ausführungspfade im Inference-Wrapper-Code.

Je später diese Erkenntnis kommt, desto höher werden die Kosten.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Was sich im Entwicklungsprozess verändert

Die Anpassung bestehender Embedded-Entwicklungsprozesse für Physical AI bedeutet nicht, etablierte Safety-Praktiken aufzugeben. Vielmehr müssen diese konsequent auf die Bereiche ausgeweitet werden, die mit dem KI-Modell interagieren.

Die Host-Firmware rund um die Inference-Engine sollte von Beginn an wie eine sicherheitskritische Komponente behandelt werden. Dazu gehören statische Analysen bei jedem Commit sowie MISRA-C/C++-, CERT-C/C++- und CWE-Prüfungen direkt im Build-Prozess und nicht erst als nachgelagerter Audit-Schritt.

Außerdem ist es notwendig, eine Runtime-Verifikation während der Tests durchzuführen, um Fehlerklassen zu erkennen, die statische Analysen nicht erfassen können: Speicherzugriffsverletzungen während der Modellausführung, Stack-Überläufe unter maximaler Inferenzlast oder undefiniertes Verhalten im Kontrollpfad zwischen Inferenz-Ausgabe und Aktuatorbefehl.

Hinzu kommt eine Testabdeckung, die tatsächlich alle relevanten Ausführungspfade berücksichtigt, einschließlich jener Fehlerbehandlungszweige, die Entwickler häufig im Testing vernachlässigen, weil sie davon ausgehen, dass das Modell keine fehlerhaften Ergebnisse erzeugt. Doch genau das kann passieren.

Außerdem muss die Toolchain über den gesamten Produktlebenszyklus stabil bleiben. Ein Physical-AI-Produkt, das 2026 ausgeliefert wird, kann 2033 noch in einer Produktionsanlage laufen. Firmware-Wartung, Security-Patches und Safety-Updates müssen deshalb in einer Umgebung erstellt werden, die konsistent ist mit der ursprünglich zertifizierten Konfiguration. Eine langlebige Toolchain ist daher keine reine Beschaffungsfrage, sondern eine strategische Lifecycle-Entscheidung.

Skalierung verändert die Gleichung

Zu erkennen, was notwendig ist, ist der einfache Teil. Die eigentliche Herausforderung besteht darin, diese Prozesse konsistent über alle Entwicklungsteams hinweg umzusetzen. Dies gilt insbesondere bei steigender Entwicklungsgeschwindigkeit und zunehmend komplexeren Physical-AI-Architekturen.

Genau hier wird CI/CD von einer DevOps-Komfortfunktion zu einer Safety-relevanten Infrastrukturkomponente. Wenn jeder Commit automatisch Builds auslöst, statische Analysen ausführt, Tests macht und strukturierte Compliance-Artefakte erzeugt, ist Qualitätssicherung nicht mehr von individueller Disziplin abhängig. Die Nachweise für spätere Audits entstehen dann kontinuierlich ab dem ersten Commit.

Insbesondere für Physical AI bedeuten containerisierte Build-Umgebungen eine weitere Absicherung. Werden Toolchain, Compiler-Konfiguration und Analysetools in versionierten Container-Images gekapselt, läuft jede Pipeline in einer identischen Umgebung, unabhängig davon, ob lokal beim Entwickler, in der Cloud oder einem On-Premises-CI-Server.

Die Grenzen der zertifizierten Toolchain sind klar und fest definiert. Wenn eine Aufsichtsbehörde fragt, welche Tool-Version eine bestimmte Binärdatei unter welcher Konfiguration erzeugt hat, findet sich die Antwort im Container-Image und muss nicht aus dem Gedächtnis rekonstruiert werden.

Damit wird auch eine der eher praktischen Herausforderungen angegangen, mit denen sich Teams im Bereich Physical AI konfrontiert sehen: die Koordination der Firmware-Entwicklung über verschiedene Hardware-Varianten und Prozessorarchitekturen hinweg. Eine einzige containerisierte Pipeline für Arm Cortex-M-, RISC-V- und Renesas-Architekturen, darunter RA, RX, RZ, RH850, RL78 und RZ/Five gewährleistet eine einheitliche Compliance-Situation, selbst wenn sich die Hardware unterscheidet. Die Reproduzierbarkeit der Builds, die die Grundlage für die Zertifizierung bildet, wird zu einer Eigenschaft der Pipeline und ist nicht länger eine manuelle Aufgabe zum Zeitpunkt der Release.

Die entscheidende Schicht für Physical AI

Genau für diesen Workflow wurde die IAR Plattform entwickelt. Sie beinhaltet eine TÜV-SÜD-zertifizierte Toolchain, qualifiziert nach IEC 61508, ISO 26262 und IEC 62304. Dadurch entfällt die Notwendigkeit, das Verhalten der Werkzeuge während eines Audits selbst validieren zu müssen. Die IAR Build Tools arbeiten Headless und integrieren sich in gängige CI-Plattformen wie GitHub Actions, GitLab CI und Jenkins. Damit bleibt der Build-Prozess in CI über jede Pipeline-Ausführung hinweg identisch zum lokalen Entwickler-Build.

C-STAT führt statische Analysen nach MISRA C/C++, CERT C/C++ und CWE direkt im Build-Schritt aus und erkennt Verstöße bereits beim Commit statt erst im Integrationsreview. C-RUN erweitert diese Abdeckung um Laufzeitverhalten während der Tests und erkennt dynamische Fehler, die unter realen Bedingungen auf ressourcenbeschränkter Hardware entstehen: Speicherzugriffsverletzungen, Stack-Probleme unter hoher Inferenzlast oder undefiniertes Verhalten im Aktuationspfad, das rein statische Analysen nicht erfassen können.

Für Physical-AI-Systeme mit zusätzlichen Security-Anforderungen, die praktisch jedes vernetzte System im Kontext von CRA und UN R155 betreffen, integriert IAR Embedded Trust Firmware-Signing und Secure Boot direkt in dieselbe Pipeline, statt Security als eine Aufgabe zu betrachten, die erst nach dem Build kommt.

Long-Term-Support-Versionen gewährleisten zudem, dass sich die Build-Umgebung auch Jahre nach der Erstzertifizierung reproduzieren lässt. So kann selbst ein Patch im sechsten Betriebsjahr eines Geräts eindeutig derselben qualifizierten Toolchain-Konfiguration zugeordnet werden wie die ursprüngliche Produktversion.

Nichts davon ersetzt das KI-Modell. Aber all das ist notwendig, bevor ein Modell in einem regulierten Produkt überhaupt legal einen Aktuator ansteuern darf.

Künstliche Intelligenz

Embedded-KI: Aktuelle Trends und Herausforderungen

Die entscheidende Grenze

Edge AI und Physical AI teilen sich dieselbe Infrastruktur, aber nicht dasselbe Risikoprofil. Sobald ein Inferenz-Ergebnis einen Aktuator steuert, ist der Software-Stack unterhalb des Modells nicht mehr nur eine Leistungsgrundlage, sondern eine Sicherheitskomponente.

Die Embedded-Teams, die heute erfolgreiche Physical-AI-Produkte entwickeln, erkennen diese Grenzen frühzeitig und passen ihre Entwicklungsprozesse an, schon lange bevor der Auditor Rückfragen stellt. Das KI-Modell sorgt vielleicht für die Schlagzeilen. Die Zulassung verdankt sie aber der Toolchain.  (sg)

* Rafael Taubinger ist Product Marketing Manager bei IAR.

(ID:50867970)