Von der Datenaufzeichnung zum Modell auf dem Gerät: die komplette Embedded-KI-Pipeline
SERIE - Teil 1
Warum KI-Projekte selten am Modell scheitern und was zwischen einer funktionierenden Demo und einem serienreifen Embedded System wirklich passiert.
Verfasst von Nico Teringl, MSc | CEO Danube Dynamics und Elias Geissler, MSc | Team Lead Embedded AI Danube Dynamics
ca. 20 Minuten Lesezeit
Einen KI-Prototyp auf dem Entwicklungsrechner zu bauen, ist heute erstaunlich einfach geworden. Ein vortrainiertes Modell laden, mit ein paar hundert Bildern nachtrainieren, auf dem Laptop eine überzeugende Genauigkeit zeigen: Das gelingt oft in wenigen Tagen. Hier entsteht allerdings ein gefährliches Missverständnis:
Die Demo wird mit dem Produkt verwechselt.
In der Praxis scheitern Embedded-KI-Projekte fast nie am Modell selbst. Sie scheitern an der Kette davor und danach: an unstrukturiert aufgezeichneten Daten, an einer Modellwahl, die das Ressourcenbudget der Zielhardware ignoriert, an einer Optimierung, die die Genauigkeit unkontrolliert einbrechen lässt, und an einem Deployment, das keine Updates, keine Nachvollziehbarkeit und kein definiertes Verhalten im Fehlerfall kennt.
Dieser Beitrag beschreibt die vollständige Pipeline, von der ersten Datenaufzeichnung bis zum wartbaren Modell im Feld. Einzelne Abschnitte (Datenqualität, Quantisierung, Monitoring im Feld, Beschleunigerwahl) verdienen jeweils eine eigene, tiefere Betrachtung. Zu diesen Themen folgen in den kommenden Wochen eigene Artikel, die den hier skizzierten Rahmen im Detail ausleuchten. Hier geht es zunächst um das Gesamtbild und darum, an welchen Stellen aus einer Machbarkeitsstudie ein Produkt wird.
Das erwartet Sie in diesem Beitrag:
- Warum ist Embedded-KI eine eigene Disziplin?
- Phase 1: Datenaufzeichnung und Datenqualität
- Phase 2: Modellauswahl
- Phase 3: Training
- Phase 4: Embedded-Optimierung
- Phase 5: Format und Toolchain
- Phase 6: Zielhardware und Beschleuniger
- Phase 7: Deployment und Lifecycle
- Zwei Projekte aus der Praxis
- Fazit: Die Pipeline ist die eigentliche Kompetenz
- FAQ: Die fünf häufigsten Fragen
Warum ist Embedded-KI eine eigene Disziplin?
Embedded-KI unterliegt harten Grenzen bei Speicher, Energie, Determinismus und Lebensdauer, die es von KI im Rechenzentrum grundlegend unterscheiden
KI im Rechenzentrum und KI auf einem Gerät im Feld haben die Modellarchitektur gemeinsam und sonst wenig. Im Rechenzentrum sind Speicher, Rechenleistung und Energie faktisch unbegrenzt. Modelle lassen sich jederzeit austauschen und ein fehlgeschlagener Aufruf wird einfach wiederholt. Auf einem Embedded-System gilt das Gegenteil. Die entscheidenden Randbedingungen sind:
Speicher und Rechenleistung sind hart begrenzt.
Von einem Mikrocontroller mit wenigen hundert Kilobyte RAM bis zu einem Edge-SoC mit dedizierter NPU.
Energie und Thermik setzen Grenzen.
Ein Modell, das das Gerät thermisch drosselt oder die Batterie leert, ist im Dauerbetrieb wertlos.
Determinismus ist oft eine Anforderung.
In sicherheits- oder qualitätsrelevanten Produkten muss die Inferenzzeit vorhersagbar sein.
Lebenszyklus
Das Gerät läuft oft Jahre im Feld, häufig ohne dauerhafte Internetverbindung, hinter Firewalls, in schwer zugänglichen Umgebungen.
Diese Randbedingungen sind keine nachgelagerte Optimierungsfrage.
Sie bestimmen von der ersten Zeile Code an, welche Daten man erhebt, welches Modell überhaupt in Frage kommt und wie man es später aktualisiert.Wer sie erst am Ende betrachtet, baut die Pipeline zweimal.
Abb. 1: Die sieben Phasen der Embedded-KI-Pipeline: von der Datenaufzeichnung bis zum Betrieb im Feld. Data Drift schließt den Kreis zurück zur Datenaufzeichnung; Zielhardware-Bewusstsein, Reproduzierbarkeit und Nachvollziehbarkeit ziehen sich durch alle Phasen.
Phase 1: Datenaufzeichnung und Datenqualität
Fehler bei den Daten sind die teuersten, weil jede spätere Phase auf ihnen aufbaut und sie meist erst in der Serie sichtbar werden. Im Feld sehen die Daten anders aus als im Labor.
1. Entscheidend ist die Repräsentativität.
Wurden die Trainingsdaten unter denselben Bedingungen aufgezeichnet, unter denen das Gerät später arbeitet? Andere Beleuchtung, andere Sensorik-Toleranzen, andere Umgebungstemperaturen, andere Betriebszustände: Jede Abweichung zwischen Aufzeichnungs- und Einsatzbedingungen wird sich später als unerklärlicher Genauigkeitsverlust im Feld rächen. Gerade die seltenen, aber kritischen Randfälle (Edge Cases) entscheiden über die Serientauglichkeit und sind in spontan gesammelten Datensätzen fast immer unterrepräsentiert.
2. Genauso wichtig ist die Datenerfassung als reproduzierbarer Prozess.
In der Praxis heißt das: definierte Aufzeichnungspipelines direkt auf oder nahe der Zielhardware, konsistentes und überprüfbares Labeling, und, häufig unterschätzt, die Versionierung der Datensätze selbst. Ein Datensatz ist ein Artefakt wie Code: Ohne die Information, welche Datenversion zu welchem Modell geführt hat, ist ein Ergebnis nicht reproduzierbar und ein Fehler im Feld nicht analysierbar.
3. Die Datenverteilung ist nicht statisch.
Sensoren altern, Umgebungen verändern sich, neue Produktvarianten kommen dazu. Datenaufzeichnung ist deshalb keine einmalige Aufgabe zu Projektbeginn, sondern ein Kanal, der über den gesamten Lebenszyklus offen bleiben sollte, als Grundlage für späteres Nachtraining und für die Erkennung von Drift.
Ein kleineres Modell auf sauberen, repräsentativen, versionierten Daten schlägt in der Serie fast immer das größere Modell auf einem schnell zusammengestellten Datensatz.
Phase 2: Modellauswahl
Die Modellauswahl ist in Embedded-Projekten keine reine Genauigkeitsfrage. Sie ist eine Optimierung unter Nebenbedingungen: die höchste Genauigkeit, die im gegebenen Speicher-, Rechen- und Energiebudget der Zielhardware zuverlässig läuft.
Das führt zu einer anderen Denkweise als im Rechenzentrum. Nicht das größte, sondern das passende Modell gewinnt. Für viele Embedded-Aufgaben (Klassifikation, Objekterkennung, Anomalieerkennung, Keyword-Spotting) sind kompakte, für mobile und eingebettete Zielsysteme entworfene Architekturen die richtige Wahl. Auch kompakte Transformer-Varianten sind auf leistungsfähigeren Edge-SoCs inzwischen realistisch, wenn Speicher und Beschleuniger es hergeben.
Die eigentliche Disziplin liegt darin, die richtigen Metriken zu bewerten. Genauigkeit allein sagt nichts über Serientauglichkeit. Latenz auf der realen Zielhardware, Speicherbedarf für Gewichte und Aktivierungen, Energieverbrauch pro Inferenz und Robustheit gegenüber untrainierten Eingaben gehören genauso auf die Liste. Wie schnell diese Kennzahlen eine auf dem Laptop überzeugende Wahl kippen können, zeigt sich am folgenden Beispiel.
YOLOv8s oder YOLOv8n?
Wie das in der Praxis aussieht, lässt sich an einer typischen Objekterkennungsaufgabe zeigen, etwa an der Erkennung von Objekten auf einem Förderband oder vor einem Fahrzeug. Die naheliegende Wahl fällt auf eine YOLO-Familie, und dort stehen mehrere Größenvarianten zur Verfügung. Zwei davon in der Gegenüberstellung:
Quellen: Ultralytics Docs – "Explore Ultralytics YOLOv8" (mAP-Werte) und Ultralytics GitHub – yolov8.yaml Modellkonfiguration (Parameter/GFLOPs)
Der erste Reflex ist fast immer YOLOv8s.
Der Use Case verlangt schließlich zuverlässige Erkennung, und 7,6 Prozentpunkte mehr mAP sind kein Rundungsfehler. Gerade bei kleinen oder teilverdeckten Objekten macht das einen spürbaren Unterschied. Auf dem Entwicklungsrechner mit GPU bestätigt sich das. Das Modell läuft flüssig und die Ergebnisse überzeugen.
Der Blick auf die Metriken der Zielhardware dreht das Bild.
Denn die relevanten Zahlen sind nicht Genauigkeit und Parameterzahl, sondern das, was das Gerät tatsächlich leisten kann. Rechnet man das Ressourcenbudget durch, zeigt sich das eigentliche Problem. YOLOv8s bringt rund die dreifache Parameterzahl und mehr als die dreifache Rechenlast mit. Auf einem Edge-SoC mit begrenztem Speicher und einer Anforderung von, sagen wir, 15 Bildern pro Sekunde bedeutet das konkret:
X
Das Speicherbudget wird nicht nur von den Gewichten belegt, sondern auch von den Aktivierungen zur Laufzeit:
Bei YOLOv8s reicht der verfügbare Arbeitsspeicher unter Umständen schlicht nicht, sobald Kamera-Pipeline und Applikation parallel laufen.
X
Die Latenz überschreitet das Zeitbudget pro Frame.
Ein Modell, das 90 ms braucht, wo 66 ms erlaubt sind, ist nicht „etwas zu langsam“, es erfüllt die Anforderung nicht.
X
Wird ein Operator auf der NPU nicht unterstützt, greift der Fallback auf die CPU, vervielfacht sich die Latenz zusätzlich und der Energieverbrauch steigt mit.
YOLOv8n hingegen passt mit deutlichem Abstand ins Budget, nach int8-Quantisierung* noch komfortabler.
Die Genauigkeitslücke lässt sich zudem meist deutlich verkleinern. Die Benchmarkwerte oben stammen von COCO, einem generischen Datensatz mit 80 Klassen. Eine reale industrielle Aufgabe erkennt oft nur eine Handvoll klar definierter Objektklassen unter kontrollierten Bedingungen. Wird YOLOv8n auf genau diese eigene, repräsentative Datenbasis feinjustiert, liegt seine Genauigkeit im tatsächlichen Use Case regelmäßig weit über dem generischen COCO-Wert und häufig nah genug an der größeren Variante, um die Anforderung zu erfüllen.
*Mehr zur Quantisierung im Abschnitt Phase 4.
Exkurs:
Und dann ist da noch die Lizenz:
Technische Eignung ist nur die halbe Entscheidung. Die zweite, oft übersehene Auswahldimension ist die Lizenz, und die kann sehr schnell teuer werden, besonders bei lizenzwidriger Nutzung. Man sollte hier von Anfang an genau hinsehen, denn ein falsch gewähltes Modell lässt sich später nur mit erheblichem Aufwand austauschen.
Gerade am YOLO-Beispiel wird das konkret:
Die weit verbreiteten Ultralytics-Modelle (darunter YOLOv5, YOLOv8 und YOLO11) stehen standardmäßig unter der AGPL-3.0. Diese Lizenz ist quelloffen, aber stark „ansteckend" (Copyleft): Wer ein AGPL-Modell in einem Produkt einsetzt, muss das gesamte abgeleitete Werk offenlegen, inklusive der umgebenden Applikation, der Konfigurationen und sogar bei reiner Netz- oder SaaS-Nutzung.
Entscheidend und leicht zu übersehen:
Auch ein auf eigenen Daten feinjustiertes Modell bleibt AGPL. Für ein proprietäres, kommerzielles Embedded-Produkt bedeutet das faktisch: Entweder man legt seinen kompletten Quellcode offen, oder man erwirbt eine kostenpflichtige kommerzielle (Enterprise-)Lizenz. Eine „einfach einsetzen und später klären"-Haltung ist riskant: Lizenzwidrige kommerzielle Nutzung kann zu Nachlizenzierungsforderungen, rechtlichen Auseinandersetzungen und im Extremfall zur erzwungenen Offenlegung des eigenen Codes führen.
Für kommerzielle Produkte sind deshalb permissive Lizenzen meist die bessere Wahl:
Apache-2.0, MIT oder BSD erlauben kommerzielle Nutzung und Veränderung, ohne den eigenen Code offenlegen zu müssen; Apache-2.0 regelt zusätzlich Patentfragen sauber. Wer eine YOLO-ähnliche Objekterkennung ohne AGPLBindung sucht, findet etwa in YOLOX (Apache-2.0) einen etablierten, anchor-freien Echtzeit-Detektor; ebenfalls permissiv lizenziert sind Modelle der PaddleDetection-Familie wie PP-YOLOE.
(Dies ist keine Rechtsberatung; die konkreten Pflichten ergeben sich aus dem jeweiligen Lizenztext und sollten im Zweifel juristisch geprüft werden.)
Die Konsequenz für die Modellauswahl:
Die Modellwahl wird nicht durch den Benchmark entschieden, sondern durch das Ressourcenbudget der Zielhardware und die Anforderung des konkreten Use Cases. Die Lizenz gehört gleichberechtigt neben Genauigkeit, Speicher und Latenz auf die Prüfliste, nicht ans Ende des Projekts.
Phase 3: Training
Reproduzierbar ist ein Training erst, wenn Datenversion, Code, Hyperparameter und Umgebung dokumentiert sind.
Das Training ist der Teil, den die meisten Teams beherrschen, und trotzdem entstehen hier die Reproduzierbarkeitsprobleme, die später teuer werden.
In der Praxis führt selten ein Training von null zum Ziel.
Transfer Learning:
Ein auf großen Datenmengen vortrainiertes Modell mit den eigenen, feldnahen Daten nachzutrainieren, ist der Standardweg, weil er mit weniger Daten auskommt und stabilere Ergebnisse liefert. Der Aufwand verlagert sich damit weg vom Modell und hin zur sauberen Datenpipeline und einer disziplinierten Durchführung.
Genau diese Disziplin entscheidet über die Serientauglichkeit.
Ein trainiertes Modell ist nur dann ein belastbares Artefakt, wenn nachvollziehbar ist, aus welcher Kombination es entstanden ist.
Was reproduzierbar dokumentiert sein muss:
- Datenversion
- Code
- Hyperparameter
- Trainingsumgebung
Ohne diese Nachvollziehbarkeit lässt sich ein Ergebnis nicht reproduzieren, ein Regressionsfehler nicht eingrenzen und eine spätere Modellversion nicht sauber gegen die vorherige vergleichen. Was in der Softwareentwicklung selbstverständlich ist (Versionierung, automatisierte Builds, reproduzierbare Ergebnisse), gilt für KI-Modelle genauso, wird aber häufig vernachlässigt. Hier lohnt sich der Aufbau von MLOps-Praktiken, die Training, Datensatz und Modell versionieren und an die CI/CD-Pipeline anbinden.
Weichenstellung:
Bereits im Training fällt zudem eine Weichenstellung für die spätere Optimierung:
Soll das Modell schon quantisierungsbewusst trainiert werden (Quantization-Aware Training)? Diese Frage führt direkt in die eigentliche Embedded-Disziplin.
Phase 4: Embedded-Optimierung
Quantisierung, Pruning und Distillation verkleinern das Modell. Wie viel Genauigkeit das kostet, zeigt nur der Test auf der Zielhardware.
Hier trennt sich Embedded-KI von generischer KI. Ein trainiertes Modell in voller Präzision passt selten unverändert auf ein eingebettetes Ziel. Die Optimierung reduziert Größe und Rechenlast, ohne die Genauigkeit unkontrolliert zu opfern. Drei Techniken sind zentral, meist in Kombination.
Quantisierung
Quantisierung ist der wirkungsvollste Hebel. Statt Gewichte und Aktivierungen in 32-Bit-Gleitkomma zu rechnen, werden sie auf 8-Bit-Ganzzahl (int8) oder in aggressiveren Fällen auf 4 Bit abgebildet. Das reduziert den Speicherbedarf drastisch und erlaubt es, die Ganzzahl-Recheneinheiten von NPUs und DSPs überhaupt erst zu nutzen.
Man unterscheidet zwei Wege. Die Wahl ist immer eine Ingenieursentscheidung, keine Formsache.
Post-Training-Quantisierung (PTQ):
ist schnell und wird nach dem Training angewendet, kann aber je nach Modell Genauigkeit kosten.
Quantization-Aware Training (QAT)
simuliert die Quantisierung bereits im Training und liefert bei empfindlichen Modellen deutlich bessere Ergebnisse – zu höherem Aufwand.
Pruning
Pruning entfernt Teile des Netzes, die wenig zur Ausgabe beitragen. Beim strukturierten Pruning fallen ganze Kanäle oder Filter weg, was direkt Rechenzeit spart; beim unstrukturierten Pruning werden einzelne Gewichte genullt, was ohne passende Hardware-Unterstützung weniger reale Beschleunigung bringt. Pruning und Quantisierung ergänzen sich.
Knowledge Distillation
Knowledge Distillation trainiert ein kleines „Schüler"-Modell darauf, das Verhalten eines großen „Lehrer"-Modells nachzubilden. So lässt sich ein Teil der Leistungsfähigkeit eines großen Modells in eine deutlich kompaktere Architektur überführen.
Der entscheidende Punkt bei allen drei Techniken:
Messen statt raten.
Jeder Optimierungsschritt verändert das Verhalten des Modells, und der Genauigkeitsverlust ist nicht linear vorhersehbar. Nur der Abgleich der optimierten Variante gegen einen belastbaren Testdatensatz – idealerweise auf der realen Zielhardware – zeigt, ob der Kompromiss tragfähig ist.
Ein Modell, das nach der Quantisierung 2 Prozent Genauigkeit verliert, kann akzeptabel sein; eines, das bei einer sicherheitsrelevanten Klasse einbricht, ist es nicht. Diese Bewertung gehört automatisiert in die Pipeline, nicht in eine einmalige manuelle Prüfung.
Abb.2: Quantisierung, Pruning und Knowledge Distillation reduzieren die Modellgröße, aber erst die Validierung auf der realen Zielhardware entscheidet über die Freigabe.
Bricht die Genauigkeit ein, geht es zurück in die Optimierung.
Phase 5: Format und Toolchain
ONNX, LiteRT und ExecuTorch sind die drei tragenden Wege auf das Gerät. Die Wahl folgt dem Ökosystem und der Zielhardware.
Ist das Modell optimiert, muss es in ein Format überführt werden, das eine effiziente Inferenz-Runtime auf dem Gerät ausführen kann. Die Landschaft hat sich in den letzten Jahren spürbar konsolidiert und gleichzeitig verschoben. Ein Grund, hier den aktuellen Stand zu kennen statt auf ältere Annahmen zu bauen.
LiteRT*
Bestehende .tflite-Modelle bleiben kompatibel; für ressourcenärmste Ziele existiert LiteRT for Microcontrollers, der frühere TensorFlow Lite Micro. LiteRT deckt CPU, GPU und NPU über eine einheitliche Schnittstelle ab.
*Nachfolger von TensorFlow Lite, die Umbenennung erfolgte Ende 2024, mit der Reifung zum produktiven Standard 2026. Quelle: Google AI Edge Team: „TensorFlow Lite is now LiteRT", Google Developers Blog
ONNX / ONNX Runtime
ist der etablierte, framework-übergreifende Austauschweg. ONNX dient als gemeinsames Zwischenformat, ONNX Runtime als portable Inferenz-Engine über viele Plattformen hinweg.
ExecuTorch
ExecuTorch ist der PyTorch-native Weg (seit Version 1.0 allgemein verfügbar).
Er exportiert Modelle direkt aus PyTorch auf das Gerät, vom Mikrocontroller bis zum SoC, ohne den Umweg über ein Zwischenformat, mit sehr kleinem Laufzeit-Fußabdruck und Backends für gängige Beschleuniger.
TVM und
ähnliche Compiler-Ansätze
bleiben relevant, wenn maximale Kontrolle über die Codegenerierung für spezifische Hardware gebraucht wird.
Die Zielhardware, laufendes Betriebs-Ökosystem und die verfügbaren Beschleuniger Backends bestimmen die Wahl des Formats und der Toolchain.
Was in allen Fällen gilt:
X numerische Abweichungen zwischen dem Modell im Training und dem konvertierten Modell auf dem Gerät
X nicht unterstützte Operatoren
X unerwartete Fallbacks auf die langsame CPU
All das tritt real auf und muss nach jeder Konvertierung durch Tests auf der Zielhardware verifiziert werden.
Ein Modell, das nach der Konvertierung „läuft", liefert nicht automatisch dieselben Ergebnisse wie vor der Konvertierung bzw. wie nach dem Training.
Phase 6: Zielhardware und Beschleuniger
Mikrocontroller, NPU, GPU oder dedizierter Beschleuniger: Die Recheneinheit prägt die gesamte Embedded-KI-Pipeline und muss vor der Modellauswahl feststehen.
Jede Klasse stellt andere Anforderungen an Modellgröße, Quantisierung und unterstützte Operatoren. Wer die Zielhardware erst nach der Modellentwicklung festlegt, riskiert ein fertiges Modell, das weder ins Speicherbudget noch in die Latenzanforderung passt. Grob lassen sich vier Klassen unterscheiden:
Mikrocontroller (Cortex-M und ähnlich)
Für einfachere Aufgaben mit wenigen Kilobyte bis Megabyte Speicher. Beschleunigung erfolgt über optimierte Bibliotheken (etwa CMSIS-NN auf Arm). Hier zählt jedes Byte.
Dedizierte KI-Beschleuniger
als eigene Bausteine neben dem Hauptprozessor, wenn Vision-Workloads mit hoher Bildrate im Vordergrund stehen.
NPUs (Neural Processing Units)
Dedizierte Beschleuniger für neuronale Netze, zunehmend in Edge-SoCs integriert – von Arm-Ethos-U-Klassen im IoT-Bereich bis zu leistungsfähigen NPUs in mobilen SoCs. Sie liefern hohe Effizienz, verlangen aber quantisierte Modelle und passende Operatoren.
GPUs und DSPs:
Für parallele bzw. signalnahe Verarbeitung, oft als Fallback oder Ergänzung zur NPU.
Das verbindende Prinzip moderner Runtimes ist das Delegate- bzw. Backend-Konzept: Dieselbe Modellbeschreibung wird zur Laufzeit an den bestmöglichen verfügbaren Beschleuniger delegiert, mit definiertem Rückfall auf GPU oder CPU, falls ein Operator nicht unterstützt wird. Das ist bequem und zugleich eine Falle, denn ein stiller Fallback auf die CPU kann die sorgfältig kalkulierte Latenz unbemerkt vervielfachen. Was auf welchem Beschleuniger tatsächlich läuft, gehört gemessen, nicht angenommen.
Die praktische Konsequenz: Hardware-Software-Co-Design.
Die Zielhardware sollte früh feststehen und in Modellauswahl, Optimierung und Formatwahl einfließen. Der umgekehrte Weg, ein Modell zu bauen und erst danach zu fragen, worauf es laufen soll, ist einer der häufigsten und teuersten Fehler.
Phase 7: Deployment und Lifecycle
Ein Modell wird erst zum Produkt, wenn es sich signiert ausrollen, überwachen und per Rollback zurücksetzen lässt. Und das über den gesamten Lebenszyklus.
Ein optimiertes, konvertiertes, für die Zielhardware validiertes Modell ist noch kein Produkt. Es wird erst dann eines, wenn es sich sicher ausrollen, überwachen und aktualisieren lässt. Genau hier verbindet sich Embedded-KI mit dem übrigen Lebenszyklus eines vernetzten Geräts.
Ein Modell als versioniertes Artefakt
Ein Modell sollte über dieselbe abgesicherte Update-Infrastruktur ausgerollt werden wie Betriebssystem und Applikationen:
kryptografisch signierte Update-Bundles
kontrollierte Verteilung
Möglichkeit eines definierten Rollbacks, wenn eine neue Modellversion sich im Feld schlechter verhält als erwartet.
Weil sich Sensorik, Umgebung und Produktvarianten über Jahre verändern, verschiebt sich auch die Datenverteilung im Feld. Ein KI-Modell, das nur einmalig aufgespielt und danach nie wieder aktualisiert werden kann, hält einem mehrjährigen Produktlebenszyklus deshalb nicht stand.
Monitoring im Feld
Weil sich die reale Datenverteilung über die Zeit verschiebt (Data Drift), verliert ein Modell schleichend an Genauigkeit, ohne dass sich am Code etwas ändert. Ohne Telemetrie über das tatsächliche Verhalten (Konfidenzwerte, Auffälligkeiten, Plausibilitätsverletzungen) bemerkt man das erst, wenn es Ausfälle verursacht. Industrielle KI braucht deshalb definierte Schranken und ein festgelegtes Verhalten im Zweifelsfall, nicht nur einen guten Testlauf zur Abnahme.
REGULATORIK
Nachvollziehbarkeit
Welches Modell lief zu welchem Zeitpunkt auf welchem Gerät?
Die Frage ist nicht nur für die Fehleranalyse zentral, sondern zunehmend regulatorisch relevant. Der Cyber Resilience Act (CRA) verpflichtet Hersteller, Komponenten und Schwachstellen ihrer Produkte zu dokumentieren, einschließlich einer maschinenlesbaren Software-Stückliste (SBOM) [1]. Die NIS2-Richtlinie adressiert nicht Produkte, sondern Betreiber, wirkt für Gerätehersteller aber über die Lieferkette: NIS2-pflichtige Kunden müssen die Sicherheitspraktiken ihrer Lieferanten bewerten [2].
Wer den Softwarestand seiner Geräte, inklusive der KI-Modelle, nicht lückenlos dokumentieren kann, hat im Feldbetrieb ein Transparenz- und ein Compliance-Problem.
[1] VO (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil II Nr. 1.
[2] RL (EU) 2022/2555 (NIS2), Art. 21 Abs. 2 lit. d.
Die zentrale Erfassung von Ist- und Soll-Zuständen, wie sie ein Fleet-Management-Ansatz leistet, schließt hier den Kreis zwischen KI und Betrieb.
Zwei Projekte aus der Praxis
Die beschriebene Methodik ist kein Lehrbuchmodell. Sie ist der Weg, den wir in realen Industrieprojekten gehen.
Zwei anonymisierte Beispiele zeigen, wie dieselben sieben Phasen in unterschiedlichen Domänen zum Tragen kommen.
Beide Projekte eint dasselbe Muster: Nicht das Modell war die eigentliche Leistung, sondern die
durchgängige, wartbare Kette von der Datenaufzeichnung im Feld bis zum überwachten Betrieb über Jahre.
Beispiel 1: Der virtuelle Sensor im Heizsystem
Ein europäischer Hersteller von Heizsystemen stand vor einem klassischen Zielkonflikt. Sein Gerät nutzte mehrere physische Sensoren zur Regelung des Verbrennungsprozesses. Diese Sensoren sind teuer, unterliegen im Betrieb Verschleiß, und ihr Ausfall zieht einen Serviceeinsatz und Stillstand nach sich, ein Kosten- und Zuverlässigkeitsproblem, das sich über hohe Stückzahlen vervielfacht.
Der Lösungsweg folgte exakt der Pipeline:
PHASE 1
In Phase 1 zeichneten wir Sensor- und Betriebsdaten unter realen Feldbedingungen auf, über verschiedene Geräte, Lastzustände und Nutzungsmuster hinweg, um die Randfälle abzudecken, die im Labor fehlen.
PHASE 2 + 3
In Phase 2 und 3 fiel die Wahl bewusst auf ein kompaktes Modell, das sich in das Speicher- und Rechenbudget des vorhandenen Gerätecontrollers einfügt, und wurde reproduzierbar trainiert.
PHASE 4
In Phase 4 wurde es per int8-Quantisierung so weit verdichtet, dass es ohne zusätzliche Hardware auf dem bestehenden Controller läuft.
PHASE 7
Über Phase 7 wird es wie Betriebssystem und Applikation per signiertem Update gepflegt und im Feld überwacht.
Das Ergebnis ist ein virtueller Sensor:
Das Modell rekonstruiert den Messwert eines physischen Sensors aus den übrigen Signalen und Betriebsdaten.
Abb. 3: Aus mehreren physischen Sensoren und Betriebsdaten lernt ein kompaktes Edge-Modell einen virtuellen Sensor.
Er reduziert die benötigte Hardware und schafft zugleich Redundanz für den Ausfallfall.
Redundanz:
Fällt der physische Sensor aus, übernimmt der virtuelle Sensor und hält das Gerät betriebsfähig. Weil das Modell zugleich Nutzungsmuster lernt, lässt sich das ideale Wartungsfenster zwei bis drei Wochen im Voraus prognostizieren.
Ersatz:
Der virtuelle Sensor ersetzt einen physischen Sensor und senkt so die Materialkosten pro Gerät, im Projekt um rund 8 Euro, was bei Serienstückzahlen unmittelbar durchschlägt.
-60%
sensorbedingte Feldausfälle
-35%
ungeplante Serviceeinsätze
< 15ms
Inferenz auf Bestandscontroller
< 200 KB
quantisiertes Modell
Beispiel 2: Das selbstlernende Netzteil
Ein Hersteller industrieller Stromversorgungen wollte seine DIN-Schienen-Netzteile von einem robusten, aber „stummen" Bauteil zu einem intelligenten, differenzierenden Produkt weiterentwickeln.
Drei Anforderungen standen im Raum:
Aufwändige Inbetriebnahme beim Endkunden vereinfachen.
Den Betrieb Energetisch optimieren.
Gefährliche Lichtbögen zuverlässig erkennen.
Auch hier trug die Methodik:
PHASE 1
In Phase 1 wurden elektrische Signalverläufe im Feld erfasst; die Erkennung von Lichtbögen ist im Kern eine Echtzeit-Klassifikationsaufgabe.
PHASE 2
Weil sie sicherheitsrelevant ist, standen in Phase 2 Determinismus und vorhersagbare Latenz gleichrangig neben der Genauigkeit.
PHASE 4
In Phase 4 kam quantisierungsbewusstes Training (QAT) zum Einsatz, um die Genauigkeit trotz aggressiver Verdichtung zu halten.
Das Modell läuft direkt auf der Recheneinheit des Netzteils. Über die Flotte hinweg werden Betriebsmuster gelernt und verteilt, ein selbstlernendes Verhalten, das die manuelle Parametrierung bei der Inbetriebnahme weitgehend überflüssig macht.
-80%
Inbetriebnahmezeit
< 5ms
Lichtbogenerkennung, >99%
< 0,5%
Fehlauslösungen
-12%
Energieverluste (Teillast)
Die Inbetriebnahmezeit sank um 80 Prozent, weil sich das Netzteil seine Parameter selbst erschließt, statt sie manuell einstellen zu lassen. Lichtbögen werden in unter 5 Millisekunden erkannt und abgeschaltet, bei einer Erkennungsrate von über 99 Prozent und Fehlauslösungen unter 0,5 Prozent. Die kontinuierliche Optimierung senkte die Energieverluste im Teillastbetrieb um rund 12 Prozent. Modell-Updates werden über dieselbe abgesicherte Update-Infrastruktur ausgerollt und im Feld überwacht wie Betriebssystem und Applikation
Fazit: Die Pipeline ist die eigentliche Kompetenz
Ein gutes Modell zu trainieren, ist heute die einfachste Etappe. Die eigentliche Ingenieursleistung liegt in der durchgängigen Kette:
- repräsentative, versionierte Daten
- eine Modellwahl, die die Zielhardware kennt
- eine Optimierung, deren Genauigkeitskompromisse gemessen statt geraten werden
- eine saubere Konvertierung mit verifiziertem Verhalten auf dem Gerät
- die richtige Recheneinheit im Co-Design
- und ein Deployment, das Updates, Monitoring und Nachvollziehbarkeit über Jahre trägt.
Wer die Kette als reproduzierbare, wartbare Fähigkeit begreift, baut ein Produkt.
Wer diese Kette einmalig als Projekt aufsetzt und danach vergisst, baut einen beeindruckenden Prototyp. Wer sie als reproduzierbare, wartbare Fähigkeit begreift, baut ein Produkt. Der Unterschied zwischen beidem entscheidet sich nicht am Tag der Demo, sondern über den gesamten Lebenszyklus im Feld, und genau dort zeigt sich, ob industrielle KI serienreif ist.
Über die Autoren
Elias Geissler, MSc
Team Lead Embedded AI I Danube Dynamics
Studierter Informatiker mit Master-Abschluss im Bereich „Embedded Systems Engineering" (FH Hagenberg). Seit 2020 arbeitet er bei Danube Dynamics an innovativen Embedded-KI-Systemen und verantwortet dort die durchgängige Skalierung, Wartung und Weiterentwicklung der Modelle und Systeme. An der in diesem Artikel beschriebenen Pipeline hat er maßgeblich mitgewirkt.
Nico Teringl, MSc
CEO I Danube Dynamics
Als CEO verantwortet er Strategie und Geschäftsentwicklung und bringt die regulatorische Einordnung industrieller KI ein, von den Anforderungen des CRA und der NIS2-Richtlinie bis zur Verantwortung für Serienüberführung und Betrieb über den gesamten Produktlebenszyklus.
Die fünf häufigsten Fragen zu Embedded AI
Nein. Viele Aufgaben (Anomalieerkennung auf Sensordaten, einfache Klassifikation, virtuelle Sensoren) laufen nach konsequenter Optimierung (int8-Quantisierung, kompakte Architektur) auf dem bereits vorhandenen Mikrocontroller oder Applikationsprozessor; in einem unserer Heizsystem-Projekte lief das Modell ohne jede Zusatzhardware auf dem bestehenden Controller. Eine NPU wird dann sinnvoll, wenn rechenintensive Workloads wie Kamera-Vision mit hoher Bildrate oder mehrere Modelle parallel gefordert sind. Die richtige Reihenfolge ist: erst das Ressourcenbudget der Aufgabe verstehen, dann über Hardware entscheiden, nicht umgekehrt.
Weniger, als die meisten vermuten, aber die richtigen. Durch Transfer Learning auf vortrainierten Modellen reichen für viele industrielle Aufgaben einige hundert bis wenige tausend gut gelabelte, repräsentative Beispiele. Entscheidend ist nicht die Menge, sondern ob die Daten die realen Feldbedingungen und die kritischen Randfälle abdecken. Ein pragmatischer Start: früh eine saubere Aufzeichnungspipeline auf der Zielhardware aufsetzen und Daten strukturiert sammeln, noch bevor das Modellprojekt offiziell beginnt.
Bei den meisten Modellen erstaunlich wenig, typischerweise im Bereich von unter einem bis wenige Prozentpunkte, bei manchen Architekturen praktisch nichts. Es gibt aber keine Garantie: Einzelne Modelle oder einzelne Klassen können empfindlich reagieren. Deshalb gilt „messen statt raten": Die quantisierte Variante wird gegen einen belastbaren Testdatensatz auf der realen Zielhardware validiert. Reicht Post-Training-Quantisierung nicht, holt quantisierungsbewusstes Training (QAT) die verlorene Genauigkeit in der Regel zurück.
Nachlassende Genauigkeit im Feld ist der Normalfall über einen mehrjährigen Lebenszyklus, kein Ausnahmefall: Sensoren altern, Umgebungen und Nutzungsmuster verschieben sich (Data Drift). Die Antwort ist keine einmalige, sondern eine architektonische: Monitoring im Feld (Konfidenzwerte, Plausibilitätsschranken, definiertes Fallback-Verhalten), ein offener Datenkanal für Nachschulung und ein Update-Mechanismus, der neue Modellversionen signiert ausrollt und bei Problemen zurückrollen kann. Wer das von Anfang an einplant, behandelt Drift als Routinevorgang statt als Krise.
Die Dauer hängt stark von Datenlage und Zielhardware ab. Als grobe Orientierung: eine belastbare Machbarkeitsbewertung ist oft in wenigen Wochen möglich, ein serienreifes System realistisch ein Projekt von mehreren Monaten. Der größte Zeitfresser ist fast nie das Training, sondern nachgelagerte Überraschungen: Daten, die neu erhoben werden müssen, oder eine Zielhardware, die zu spät feststand. Genau deshalb lohnt eine frühe, ehrliche Einschätzung vor dem Projektstart.
Sie haben ein konkretes Projektvorhaben?
Kostenlosen Ersttermin mit unseren Technikern buchen: erste Einschaetzung zu Machbarkeit und Kostenindikation. Unverbindlich.