Intelligente Sensoren & TinyML auf Mikrocontrollern

Jeden rohen Sensorwert in die Cloud zu senden kostet Batterie, Bandbreite und Privatsphäre. TinyML lässt kleine, quantisierte Modelle (Kilobytes bis wenige Megabytes) auf Mikrocontrollern (MCUs) oder NPUs der MCU-Klasse direkt am Sensor laufen, sodass ein Knoten nur „Lageranomalie“ oder „Weckwort erkannt“ übermittelt statt eines Rohdatenstroms. Typische Vorteile: Batterielaufzeit von Jahren, Latenz im Millisekundenbereich, Offline-Betrieb und Daten, die das Gerät nie verlassen.

Problem & Nutzen

• Heute: Sensorknoten arbeiten entweder mit festen Schwellenwerten (viele Fehlalarme, übersehene schwache Fehler) oder senden Rohdaten an Gateways/Cloud (teurer Funk, Energie, Speicher, Latenz, Datenschutzrisiko).
• KI-Nutzen: Gelernte Detektoren für Vibration, Schall, Strom oder Bewegung finden Muster, die Schwellenwerte nicht erfassen, und lokale Inferenz reduziert die übertragenen Daten auf Ereignisse. Audio- und Kameradaten lassen sich auf dem Gerät auf Labels reduzieren.
• Warum jetzt: MCUs mit DSP-Erweiterungen und kleinen NPUs (Arm Cortex-M55/M85 mit Ethos-U55/U65, STM32N6 mit Neural-ART, Renesas RA8, Infineon PSOC Edge, Nordic nRF54/Axon-Klasse) machen Inferenz günstig, und ausgereifte Werkzeugketten nehmen den Großteil der Low-Level-Arbeit ab [1][2][3][4].
• Eine allgemeingültige Nutzenzahl gibt es nicht; messen Sie Batterielaufzeit, Genauigkeit und Stückliste stets auf Ihrem eigenen Gerät.

Varianten

• Knoten für vorausschauende Wartung: Anomalieerkennung bei Vibration/Strom an Motoren, Pumpen, Lüftern (siehe PRED-006, ANOM-005).
• Akustik & Schlüsselworterkennung: Überwachung von Maschinengeräuschen, Glasbruch, Weckwörter, Klassifikation von Husten/Schnarchen.
• Wearables & Bewegung: Gesten-, Aktivitäts- und Sturzerkennung; Exoskelett-/Gangsteuerung (ROBO-018).
• Landwirtschaft & Umwelt: Halsbänder für Nutztiere, Boden-/Schädlingssensorik, Tierstimmen in der Wildnis (PRED-044).
• Smart Home & Gebäude: Anwesenheit, Belegung, Gerätesignaturen (ROBO-012).
• Bauwerke & Infrastruktur: batteriebetriebene Dehnungs-/Neigungsknoten (PRED-046).
• Private Bastler: Arduino/ESP32-Projekte für Gesten oder Geräusche.

So funktioniert es

1. sensor (IMU / mic / ADC / camera)
2. DSP preprocessing on MCU (filtering, FFT, MFCC, windowing)
3. quantised NN (int8) or classical model (tree, k-means, anomaly)
4. decision / event (threshold, debouncing, state machine)
5. local action (actuator, wake main CPU) and/or compact uplink (LoRaWAN, BLE, Thread, NB-IoT, MQTT)
6. fleet backend: monitoring, retraining, OTA model update

• Modelltypen: kleine 1D-CNNs, tiefenweise separierbare CNNs, kleine RNN-/Transformer-Varianten, Autoencoder für Anomalieerkennung nur mit Normaldaten sowie klassisches ML (Random Forest, Isolation Forest), das bei tabellarischen Sensormerkmalen oft gewinnt.
• Kompression: Post-Training- oder quantisierungsbewusste Int8-Quantisierung, Pruning, Wissensdestillation, Operatorfusion; ein Modell muss neben der Firmware in RAM/Flash passen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Fachexperten beschriften Ereignisse und beurteilen Anomalie-Alarme; Schwellenwerte und Entscheidungen zum Nachtraining werden von Ingenieuren geprüft; Sicherheitsaktionen verlassen sich nie allein auf ein nicht validiertes Modell.

Datenaufbereitung

Die wichtigsten Daten sind beschriftete Sensor-Zeitreihen (Vibration, Strom, Temperatur, Audio, Bilder) vom realen Gerät oder der Maschine sowie Kontext wie Betriebszustand und Störungsprotokolle. In einem KMU liegen diese typischerweise in SPS-/SCADA-Historien, Wartungsprotokollen, CSV-Exporten, Excel-Tabellen und in den Köpfen der Servicetechniker.

Typische Lücken: keine beschrifteten Fehlerbeispiele (Fehler sind selten), uneinheitliche Abtastraten und Uhren, Sensordrift, Daten nur aus guten Zuständen, fehlende Labels oder Labels nur in Freitext-Wartungsnotizen und über Maschinen verstreute Daten.

Schritte der Aufbereitung: (1) festlegen, was erkannt werden soll, und die Label-Kategorien definieren (PREP-019); (2) eine kurze, strukturierte Aufzeichnungskampagne mit Normalzuständen und, wo möglich, gezielt herbeigeführten Fehlerzuständen durchführen; (3) Labels aus Wartungs- und Arbeitsauftragsdaten gewinnen (PREP-020); (4) Zeitreihen bereinigen, neu abtasten und in saubere Tabellen ausrichten (PREP-011); (5) mit Experten einen Auswertungssatz zurückhalten (PREP-018). Werkzeuge: Edge Impulse Data Forwarder, Python/pandas, einfache MQTT- oder serielle Logger.

Grober Aufwandsanteil: 30–40 Prozent, überwiegend Aufzeichnungskampagne und Beschriftung. Siehe auch PREP-005 zur Datenextraktion und GUIDE-003 zur Bereitschaftsprüfung.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg B — verwaltete TinyML-Plattformen (z. B. Edge Impulse) erlauben einem kleinen Team, Modelle ohne ML-Spezialisten zu trainieren und auf Standard-Mikrocontroller zu bringen.
• Großunternehmen: Weg C — eine gemeinsame Open-Source-Werkzeugkette (TensorFlow Lite Micro, eigenes MLOps) über viele Produkte hinweg vermeidet Lizenzkosten pro Gerät und hält Sensordaten im Haus.
• Entwickler: Weg C — Open-Source-Frameworks und offene Firmware sind der natürliche Stack für eingebettetes ML.

Weg A — Kaufen (Standardsoftware)

• Fertige intelligente Sensoren: Zustandsüberwachungssensoren mit integriertem ML von Industrieanbietern, z. B. Bosch (EU) XDK/Sensormodule, STMicroelectronics (EU) MEMS-Sensoren mit Machine Learning Core / Intelligent Sensor Processing Unit, Infineon (EU) XENSIV-Sensoren, Siemens (EU) und SKF (EU) Zustandsüberwachung sowie Bausteine der Klasse Syntiant, Aizip oder Nordic Edge AI.
• A wählen, wenn: die Messaufgabe Standard ist (Vibration an Motoren, Belegung, einfache Audioereignisse) und Sie weder Firmware noch ML selbst verantworten wollen.

Weg B — Auf Cloud-KI-Diensten aufbauen / Plattformen

• MLOps-Plattformen für eingebettetes ML: Edge Impulse (jetzt Teil von Qualcomm), Nota/Neuton/Imagimob Studio (Imagimob gehört zu Infineon, EU), STMicroelectronics ST Edge AI Developer Cloud und STM32Cube.AI / ST Edge AI Core (EU), Nordic Edge AI Lab, Renesas Reality AI. Sie decken Datenerfassung, Entwurf von DSP-Blöcken, Training, Quantisierung, Benchmarking auf Zielplatinen und Code-Export ab [1][2][5].
• Rolle der Cloud: beschriftete Felddaten sammeln, trainieren, Flottentelemetrie speichern (AWS IoT Core/Greengrass, Azure IoT Hub, EU-Regionen; in der EU gehostete Optionen wie Scaleway, OVHcloud, Open Telekom Cloud) und OTA-Updates verteilen (Memfault, Golioth, Mender).
• B wählen, wenn: Sie Embedded-Ingenieure haben, aber schnell iterieren wollen; die Standardwahl für die meisten KMU-Produktteams.

Weg C — Selbst betreiben (Open Source)

• Laufzeitumgebungen: LiteRT für Mikrocontroller (früher TensorFlow Lite Micro), ExecuTorch (PyTorch, unterstützt Arm-Ethos-U- und Cortex-M-Backends), microTVM/Apache TVM, Arm CMSIS-NN, emlearn (klassisches ML in C), ONNX-basierte Exporte, Zephyr RTOS und FreeRTOS als Betriebssystemschichten [3][4][6].
• Training: PyTorch/Keras/scikit-learn, Quantisierung mit Werkzeugen vom Typ Model Optimizer/AIMET, MLPerf Tiny als Benchmark-Suite [7].
• Hardware: Entwicklung auf einem Laptop/HW1-Klasse; Zielplatinen wie STM32, nRF, ESP32-S3, RP2350, Alif Ensemble (Cortex-M55 + Ethos-U55), Raspberry Pi Pico 2.
• Aufwand: Firmware- plus ML-Kenntnisse; vor allem Embedded-Engineering-Zeit.

Weg D — Eigenes Training

Die meisten realen Projekte enden hier: eigene gerätespezifische Daten sammeln (Sensorposition, Rauschen, Maschinenvarianten), Merkmale entwerfen, je Gerätefamilie trainieren und quantisieren. Erforderlich sind Hunderte bis Tausende beschrifteter Fenster für die Klassifikation; für Anomaliemodelle nur mit Normaldaten repräsentative Aufnahmen über Betriebszustände, Jahreszeiten und Verschleiß hinweg. Neuronale Architektursuche (z. B. nach Art von MCUNet) und Destillation lohnen sich bei knappen RAM-Budgets [8].

Stand der Technik (2026)

• MCU-NPUs sind Mainstream: Int8-Inferenz für Bildverarbeitung bei niedriger Auflösung, Schlüsselworterkennung und Anomalieerkennung läuft im Milliwatt-Bereich; Ethos-U, Neural-ART und ähnliche Beschleuniger bringen große Beschleunigungen gegenüber reinen Cortex-M-Kernen. Transformer-artige Lasten und kleine VLMs bleiben meist außerhalb der Reichweite von MCUs; sie zielen auf Edge-Linux-/NPU-Platinen (HW1-Klasse wie Jetson Orin Nano, Hailo).
• Werkzeugketten wachsen zusammen: ExecuTorch und LiteRT ersetzen handgeschriebene C-Inferenz; Herstellerwerkzeuge messen Latenz, RAM und Energie je Schicht auf echten Platinen; MLPerf Tiny standardisiert den Vergleich [6][7].
• Trend: datenzentrierte Abläufe (synthetische Augmentierung, automatische Beschriftung mit größeren Cloud-Modellen und anschließende Destillation auf die MCU), laufende Kalibrierung auf dem Gerät und kleine Zeitreihen-Encoder im Foundation-Stil für Anpassung mit wenigen Beispielen.
• Grenzen und Fehlerbilder: Verteilungsverschiebung (neue Maschine, neue Montage, Rauschen) verschlechtert die Genauigkeit unbemerkt; Int8-Quantisierung kann die Genauigkeit mindern; unüberwachte Anomaliedetektoren erzeugen ohne Referenzwahrheit Fehlalarme; winziger RAM begrenzt die Kontextlänge; OTA-Updates und Secure Boot verursachen Aufwand; Energieangaben aus Datenblättern weichen von der Batterielaufzeit im Feld ab.

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Fähigkeiten: Edge-Runtime-, Zeitreihen- und Anomalieerkennungs-Pipelines werden in PRED-006 (vorausschauende Wartung), ANOM-005 (Prozessanomalien), PRED-014 (Softsensoren), PRED-044 (Nutztiere) und PRED-046 (Bauwerksüberwachung) wiederverwendet.
• Kombinationen: TinyML als Auslöser der ersten Stufe, der ein größeres Edge-Modell oder Gateway weckt (ROBO-016 Sicherheitssensorik an Maschinen, ROBO-012 Smart-Home-Hubs); Wearables für ROBO-018.
• Gemeinsame Infrastruktur: MQTT-/LoRaWAN-Gateways, OTA- und Flottenmanagement-Dienst, ein Speicher für beschriftete Daten und eine Cloud-Trainingsumgebung bedienen viele Gerätetypen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen bis zum Einsatz; Hardware pro Sensor plus optionales Abonnement.
• Weg B: typischerweise 2–6 Monate für einen ersten produktreifen Knoten (Datenerhebung, Modell, Firmware, OTA); Plattformlizenzen oder kostenlose Stufen; die Kosten bestehen überwiegend aus Engineering und Felddatenerhebung.
• Weg C/D: länger, mit Embedded- und ML-Spezialisten; Einsparungen bei der Stückliste pro Einheit zahlen sich bei hohen Stückzahlen aus.
• Kennzahlen: Precision/Recall pro Ereignis, Fehlalarme pro Gerät und Woche, Inferenz-Latenz, RAM-/Flash-Bedarf, Energie pro Inferenz und Batterielaufzeit, Anteil nicht übertragener Daten, OTA-Erfolgsquote, flottenweite Drift-Indikatoren.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung für den Business Case ein, die Abteilungsleitung (Instandhaltung oder Produktmanagement) als Verantwortliche, IT und IT-Sicherheit für Geräteupdates und Konnektivität sowie die Datenverantwortlichen für SPS- und Wartungsdaten. Servicetechniker sind die Experten, die Labels validieren; beziehen Sie sie daher von Anfang an ein.

Betriebsrat: abhängig vom Einzelfall. Sensoren an Maschinen sind meist unkritisch, doch Daten mit Bezug zu einem Maschinenbediener, einer Schicht oder individueller Leistung können geeignet sein, Verhalten zu überwachen (§ 87 Abs. 1 Nr. 6 BetrVG, objektive Eignung genügt). Unterrichten Sie den Betriebsrat rechtzeitig (§ 90 Abs. 1 Nr. 3) und vereinbaren Sie, dass die Daten nur für den Maschinenzustand verwendet werden. Bei reiner Verbraucher- oder Produktnutzung (Embedded) ist kein Betriebsrat beteiligt.

Eine DSFA ist bei Maschinendaten ohne Personenbezug in der Regel nicht nötig; ziehen Sie die Datenschutzbeauftragte hinzu, wenn Audio- oder Kamerasensoren Personen erfassen können. Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) durch kurze Schulungen für Techniker dazu, was Alarme bedeuten und wie hoch ihre Fehlalarmquoten sind. Starten Sie mit einem Pilotprojekt an ein bis zwei Maschinen mit einem motivierten Instandhaltungsteam, kommunizieren Sie, dass der Sensor deren Urteil unterstützt statt es zu ersetzen, und gehen Sie auf Ängste vor Überwachung ein. Alarme geben Empfehlungen, Menschen entscheiden über Wartungsmaßnahmen.

Leitfäden: GUIDE-009, GUIDE-008, GUIDE-004.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): meist minimales Risiko (KI-Kompetenz, Art. 4). Sie wird hochriskant, wenn die Sensor-KI ein Sicherheitsbauteil eines Produkts nach Anhang-I-Rechtsvorschriften ist (Maschinen, Medizinprodukte; die Pflichten nach Anhang I gelten ab 2. Aug. 2028 gemäß Digital Omnibus VO (EU) 2026/1744; Funkanlagen mit Sicherheitsfunktion, Spielzeug) oder in Bereichen nach Anhang III; biometrische Identifizierung, Emotionserkennung am Arbeitsplatz/in der Schule und ähnliche Verwendungen sind nach Art. 5 eingeschränkt oder verboten, daher dürfen Audio-/Vision-Knoten nicht in diese Zwecke abgleiten [9].
• DSGVO: Mikrofone, Kameras, Wearables und Anwesenheitssensoren können personenbezogene Daten verarbeiten (Beschäftigte, Bewohner, Gesundheitsdaten). Lokale Inferenz, bei der nur Labels das Gerät verlassen, unterstützt Datensparsamkeit und Datenschutz durch Technikgestaltung, doch das Gerät kann weiterhin personenbezogene Daten verarbeiten; dokumentieren Sie den Zweck, führen Sie bei Bedarf eine DSFA durch und beteiligen Sie bei Arbeitsplätzen den Betriebsrat.
• Produktrecht: Cyber Resilience Act (sichere Updates, Umgang mit Schwachstellen), Cybersicherheitsanforderungen der Funkanlagenrichtlinie, neue Maschinenverordnung 2023/1230 für Sicherheitsfunktionen, MDR für medizinische Wearables [10].
• Technische Risiken: Modelldiebstahl/-manipulation auf dem Gerät (Secure Boot, verschlüsselten Speicher nutzen), gegnerische Geräusche/Signale, unbemerkte Drift. Gegenmaßnahmen: Überwachung, schrittweise Canary-Rollouts, Rollback und Rückfallebenen auf herkömmliche Schwellenwerte.

Erste Schritte

1. Wählen Sie ein messbares Ereignis (z. B. Lagerverschleiß, Weckwort) und legen Sie Ziel-Recall, Fehlalarmrate und Batterielaufzeit fest.
2. Kaufen Sie ein Entwicklungskit mit der Ziel-MCU und dem Sensor; zeichnen Sie 1–2 Wochen reale Daten mit Referenzwahrheit auf.
3. Erstellen Sie einen Prototyp in Edge Impulse oder ST Edge AI; vergleichen Sie ein klassisches Modell mit einem kleinen CNN.
4. Quantisieren Sie auf Int8, messen Sie RAM/Latenz/Energie auf der Platine und integrieren Sie dann in die Firmware mit einer Rückfallebene auf Schwellenwerte.
5. Pilotieren Sie auf 10–50 Geräten mit OTA und Drift-Protokollierung, bevor Sie skalieren.

Quellen

1. Edge Impulse documentation — https://docs.edgeimpulse.com/
2. STMicroelectronics — ST Edge AI Suite — https://stm32ai.st.com/
3. LiteRT for Microcontrollers (Google AI Edge) — https://ai.google.dev/edge/litert/microcontrollers/overview
4. Arm — Ethos-U NPU and CMSIS-NN — https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-u55
5. Nordic Semiconductor — Edge AI (nRF54LM20B with Axon NPU, Nordic Edge AI Lab; 6 Jan 2026) — https://www.nordicsemi.com/Nordic-news/2026/01/nRF54L-Series-SoC-with-NPU-and-Nordic-Edge-AI-Lab-make-on-device-intelligence-easily-accessible
6. ExecuTorch (PyTorch) — https://pytorch.org/executorch/
7. MLCommons — MLPerf Tiny benchmark — https://mlcommons.org/benchmarks/inference-tiny/
8. Lin et al. — MCUNet: Tiny Deep Learning on IoT Devices (NeurIPS 2020) — https://arxiv.org/abs/2007.10319
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
10. Regulation (EU) 2024/2847 (Cyber Resilience Act) — https://eur-lex.europa.eu/eli/reg/2024/2847/oj