TinyML und LoRaWAN Edge AI für die Industrie: Modelle direkt am Sensor betreiben

TinyML verlagert kleine Machine-Learning-Modelle auf Mikrocontroller direkt am Sensor. Dort können sie Vibrationsfenster, Stromverläufe, Geräusche oder andere Signale auswerten, ohne Rohdaten dauerhaft in eine Cloud zu senden. LoRaWAN überträgt anschließend nur Ergebnis und Kontext: Anomaliescore, Klasse, Kennwerte, Zeit, Batterie und Modellversion. Diese Aufgabenteilung passt zur niedrigen Datenrate, verlangt aber einen sauberen Modell- und Gerätebetrieb.

Edge AI ist nicht automatisch besser als eine physikalische Schwelle. Ein TinyML-Modell lohnt sich, wenn das Muster komplex genug ist, ausreichend repräsentative Daten vorliegen und der Zusatznutzen im Feld nachgewiesen werden kann. Für einfache Temperaturgrenzen oder eindeutige Druckabfälle bleibt transparente Regeltechnik oft robuster.

Kurz zusammengefasst: TinyML verarbeitet datenreiche Sensorsignale lokal, LoRaWAN transportiert kompakte Entscheidungen und Diagnosen. Der industrielle Nutzen hängt an repräsentativen Trainingsdaten, dokumentierten Features, Modellüberwachung, sicherem Update und einer verständlichen Rückfallebene.

Was TinyML technisch bedeutet

Das offizielle Projekt TensorFlow Lite for Microcontrollers beschreibt eine Laufzeit für Machine-Learning-Modelle auf ressourcenbegrenzten Mikrocontrollern und DSPs. Die Google-Anleitung für LiteRT auf Mikrocontrollern zeigt den typischen Ablauf aus Training, Konvertierung und Inferenz in eingebettetem C++. Das Training findet meist außerhalb des Endgeräts statt; im Feld führt der Knoten das fertige Modell aus.

Arm ordnet in seiner TinyML-Einführung On-Device-Inferenz als Möglichkeit ein, Latenz, Energie und Datenübertragung zu reduzieren. Für Industrieanlagen ist das besonders interessant, wenn ein Sensor hochfrequent misst, aber nur selten ein relevantes Ereignis erkennt.

Stufe	Aufgabe am Edge-Knoten	LoRaWAN-Nachricht	Prüffrage
Erfassung	Vibration, Strom, Audio oder Prozesssignal abtasten	Noch keine	Ist Sensorposition stabil?
Vorverarbeitung	Filtern, normalisieren, Fenster bilden	Diagnosestatus	Ist die Implementierung identisch zum Training?
Feature/Modell	Merkmale oder Inferenz berechnen	Score, Klasse, Kennwerte	Gilt das Modell für den Betriebsmodus?
Ereignis	Schwelle, Hysterese und lokale Speicherung	Alarm plus Kontext	Wie werden Fehlalarme behandelt?
Lernen/Betrieb	Rohfenster stichprobenartig sichern	Modellversion und Driftindikator	Wie wird das Modell überwacht?

Die sinnvolle Datenpipeline

Ein Vibrationsknoten kann beispielsweise fünf Sekunden mit hoher Rate messen, das Signal filtern, spektrale Merkmale berechnen und ein Modell ausführen. Bei normalem Verhalten sendet er nur einen periodischen Gesundheitsdatensatz. Bei einer Auffälligkeit speichert er das Rohfenster lokal und sendet Score, Merkmal, Betriebsmodus und Speicherhinweis.

Diese Pipeline reduziert Funklast, aber sie verschiebt Verantwortung in die Firmware. Fensterlänge, Filter, Quantisierung, Normalisierung und Sensortakt müssen mit der Trainingspipeline übereinstimmen. Schon eine kleine Änderung kann Modellresultate verschieben, ohne dass der Binärcode abstürzt.

Zu jedem Edge-Ergebnis gehören

• Sensor- und Asset-ID sowie Betriebszustand
• Modell-, Feature- und Firmwareversion
• Score oder Klasse mit nachvollziehbarer Schwelle
• Datenqualität, Batterie, Temperatur und Rechenfehlerstatus
• Hinweis auf lokal gespeicherte Rohdaten und deren Zeitfenster

Warum LoRaWAN gut zu Edge AI passt

Die LoRa Alliance beschreibt LoRaWAN als energiearme Kommunikation für kleine Datenmengen. TinyML reduziert ein großes lokales Signal auf wenige aussagekräftige Werte. Dadurch kann ein batteriebetriebener Knoten lange arbeiten, ohne Audio-, Strom- oder Vibrationsrohdaten permanent zu übertragen.

The Things Network nennt in den LoRaWAN-Limitierungen geringe Bandbreite und begrenzte Downlinks. Genau deshalb sollte ein Edge-AI-System nicht versuchen, jedes Rohfenster oder häufige Modellpakete über LoRaWAN zu bewegen. Uplinks bleiben klein; umfangreiche Diagnose und Training nutzen Wartungszugang, lokales Kabel, WLAN oder einen anderen geeigneten Kanal.

Features vor neuronaler Größe

Auf Mikrocontrollern sind Flash, RAM, Rechenzeit und Energie begrenzt. Ein kleineres Modell ist nicht automatisch schlechter, wenn die Eingangsmerkmale gut gewählt sind. Bei rotierenden Maschinen können Drehzahlbezug, Bandenergie oder Hüllkurvenmerkmale mehr Nutzen bringen als ein großes Netz auf unnormalisierten Rohdaten.

Quantisierung reduziert Speicher und Rechenlast, kann aber Genauigkeit verändern. Deshalb wird nicht nur das Trainingsmodell am PC geprüft, sondern exakt die eingebettete, quantisierte Variante auf Zielhardware. Laufzeit, maximaler Speicherbedarf und Energie pro Inferenz gehören zu den Abnahmekriterien.

• Flash- und RAM-Budget vor der Modellauswahl festlegen
• Worst-Case-Laufzeit unter realer Sensor- und Funklast messen
• quantisiertes Zielmodell gegen unabhängige Testdaten prüfen
• Überlauf, fehlende Samples und Sensorfehler gezielt simulieren
• Strombedarf aus Messung, Inferenz, Speicherung und Uplink bilanzieren

Training braucht repräsentative Betriebszustände

Industriesignale hängen von Last, Drehzahl, Produkt, Werkzeug, Montage und Umgebung ab. Ein Modell, das nur an einer Maschine bei einer Last trainiert wurde, kann an einer baugleichen Anlage falsche Alarme erzeugen. Trainings- und Testdaten müssen die vorgesehenen Anlagenfamilien und Betriebsmodi abdecken.

Besonders wertvoll sind bestätigte Fehlerbefunde. Eine Anomalie ist zunächst nur anders. Erst Wartungsbefund, Prozesswissen und Wiederholung zeigen, ob sie relevant ist. Datenaufteilung sollte außerdem zeitlich und anlagenbezogen sauber erfolgen, damit nahezu identische Fenster nicht gleichzeitig in Training und Test landen.

Anomalieerkennung und Klassifikation trennen

Anomalieerkennung lernt typisches Verhalten und meldet Abweichung. Sie eignet sich, wenn wenige Fehlerbeispiele vorliegen, sagt aber nicht automatisch, was defekt ist. Klassifikation unterscheidet bekannte Klassen, benötigt dafür repräsentative und korrekt beschriftete Beispiele. Beide Verfahren können kombiniert werden, sollten im Ergebnis aber klar bezeichnet sein.

Ein verständlicher Uplink könnte lauten: Anomaliescore 0,82 bei Betriebsmodus Volllast, dominantes Frequenzband erhöht, Modell M12, Rohfenster lokal gespeichert. Die Ausgabe Lagerausfall in drei Tagen wäre nur zulässig, wenn genau diese Prognose mit ausreichenden Daten validiert wurde.

KI-Regel: Das Modell darf nur behaupten, was Trainingsziel, Testdaten und Feldvalidierung tragen. Unbekannt ist eine fachlich wertvolle Ausgabe.

Modell- und Konzeptdrift im Feld

Maschinen verschleißen, werden überholt oder anders betrieben. Sensoren werden ersetzt, Befestigungen ändern sich und neue Produkte verändern Lastprofile. Dadurch kann sich die Datenverteilung verschieben. Ein Modell muss deshalb nach Deployment überwacht werden: Scoreverteilung, Fehlalarmquote, unbekannte Zustände und Übereinstimmung mit Befunden.

Das NIST AI Risk Management Framework stellt kontinuierliches Risikomanagement über den Lebenszyklus in den Mittelpunkt. Für TinyML bedeutet das eine klare Governance: Wer darf Modelle freigeben, wie werden Tests dokumentiert, wann erfolgt Rollback und wer bewertet Auswirkungen auf Betrieb und Sicherheit?

Updates über LoRaWAN sind möglich, aber nicht trivial

Die technische Empfehlung zum LoRaWAN FUOTA Process beschreibt Bausteine für Firmware Updates Over the Air auf Anwendungsebene. Ein Modell kann Teil der Firmware oder ein separates Datenpaket sein. In beiden Fällen braucht der Knoten genügend Speicher, Integritäts- und Authentizitätsprüfung, einen sicheren Aktivierungsprozess und eine funktionierende Rückfallversion.

FUOTA verbraucht Downlinkkapazität und Energie. Eine große Flotte wird deshalb in Wellen aktualisiert, überwacht und bei Problemen gestoppt. Ein Modell sollte nicht häufiger gewechselt werden, als es fachlich nötig ist. Für schwer erreichbare oder sicherheitsnahe Geräte kann ein kontrolliertes Wartungsupdate trotz höherem Aufwand die bessere Wahl sein.

Security vom Sensor bis zum Modell

Geräteidentität und LoRaWAN-Schlüssel schützen den Transport, reichen aber nicht für den gesamten AI-Lebenszyklus. Modellartefakte, Trainingsdaten, Featurecode und Freigaben brauchen Zugriffsschutz und Versionierung. Ein Angreifer oder versehentlicher Prozessfehler darf nicht unbemerkt ein anderes Modell aktivieren.

Auch Datenschutz kann relevant sein. Audio- oder Prozessrohdaten bleiben idealerweise lokal und werden nur für definierte Diagnosefälle ausgelesen. Wenn sie Personen oder vertrauliche Produktionsabläufe erkennen lassen, gelten zusätzliche Zugriffs- und Löschregeln. Edge-Verarbeitung reduziert Übertragung, beseitigt aber nicht automatisch jedes Datenschutzrisiko.

Fallback und sichere Wirkung

Ein Modell kann hängen, abstürzen oder unplausible Ergebnisse liefern. Der Knoten braucht Watchdog, Selbsttest und einen definierten Degradationsmodus. Bei Modellfehler kann er auf transparente Kennwerte oder konservative Schwellen zurückfallen und den Zustand melden.

TinyML sollte keine sicherheitsgerichtete Abschaltung übernehmen, wenn Hardware, Software und Gesamtfunktion dafür nicht nachgewiesen sind. In vielen Projekten ist die richtige Wirkung eine Wartungsinformation. Lokale Maschinen- und Personenschutzfunktionen bleiben in den zugelassenen Steuerungen.

Pilotierung vom Notebook bis zur Werkhalle

1. klaren Entscheidungsnutzen und zulässige Fehlerraten definieren
2. repräsentative Daten mit Betriebsmodus und Befund sammeln
3. einfache Regeln als Baseline gegen das ML-Modell vergleichen
4. quantisiertes Modell auf Zielhardware verifizieren
5. Funk, Energie, Speicher und Ausfallmodi gemeinsam testen
6. Shadow Mode ohne automatische Wirkung im Feld betreiben
7. Befunde zurückführen und Modellüberwachung etablieren
8. Update, Rollback und Außerbetriebnahme vor Skalierung üben

Im Shadow Mode erzeugt das Modell Meldungen, ohne den Arbeitsprozess automatisch zu verändern. Fachleute vergleichen sie mit realen Befunden. So werden Schwellen, unbekannte Betriebszustände und Fehlalarme sichtbar, bevor ein Modell Aufträge oder Eskalationen auslöst.

Verbindung zur Predictive Maintenance

Die Predictive Maintenance in schwerer Fertigung liefert den betrieblichen Rahmen: Asset, Fehlermechanismus, Arbeitsauftrag und Befund. TinyML ist darin eine Auswertekomponente. Ohne diesen Rückkanal kann das Modell zwar Scores senden, aber kaum lernen, welche Meldung nützlich war.

Auch bei prädiktiver Wartung von Bergbaumaschinen oder Offshore-Plattform-Monitoring kann Edge AI Funklast reduzieren. Die Modelle müssen jedoch an Umgebung, Maschine und Datenqualität angepasst werden.

Kennzahlen für TinyML plus LoRaWAN

Modellseitig zählen Precision, Recall oder andere zur Aufgabe passende Metriken, getrennt nach Anlage und Betriebsmodus. Im Feld zählen bestätigte Treffer, Fehlalarme, unbekannte Zustände, Drift und Zeit bis zur Rückmeldung. Embedded-seitig zählen Inferenzzeit, RAM, Flash, Energie und Abstürze.

Funkseitig zählen Nachrichtengröße, Sendehäufigkeit, Downlinkbedarf, Paketverlust und Batterierestlaufzeit. Der eigentliche Nutzen zeigt sich schließlich im Prozess: frühere Erkennung, besser vorbereitete Wartung und weniger unnötige Kontrollen. Keine einzelne Metrik ersetzt dieses Gesamtbild.

Wann eine einfache Regel besser ist

Wenn ein physikalischer Grenzwert stabil, verständlich und ausreichend ist, sollte er verwendet werden. Eine feste Übertemperatur, ein klarer Druckverlust oder ein Kontaktzustand braucht oft kein ML. Das spart Daten, Rechenleistung und Validierungsaufwand.

TinyML ist stark bei Mustern, die sich mit wenigen transparenten Kennwerten nicht gut trennen lassen. Die Entscheidung sollte ein Vergleich belegen: Regel, statistisches Verfahren und ML-Modell werden auf denselben unabhängigen Felddaten bewertet. So bleibt Edge AI ein Werkzeug und kein Selbstzweck.

Modellflotten beobachtbar und gestuft ausrollen

Bei hundert Edge-Knoten reicht es nicht zu wissen, welches Modell laut Planung installiert sein sollte. Jeder Gesundheitsdatensatz sollte die aktive Modell- und Firmwareversion, letzten erfolgreichen Selbsttest, Inferenzfehler und Zeitpunkt der Aktivierung enthalten. Eine Flottenansicht erkennt Geräte, die auf einer alten Version verbleiben, nach einem Neustart in die Rückfallversion gewechselt sind oder seit dem Update ungewöhnlich viele unbekannte Zustände melden.

Neue Modelle werden zunächst auf Laborgeräten, dann auf wenigen repräsentativen Feldknoten und erst danach in größeren Wellen aktiviert. Zwischen den Stufen liegen definierte Beobachtungszeiten und Abbruchkriterien. Eine Canary-Gruppe sollte verschiedene Anlagen, Funkbedingungen und Betriebsmodi enthalten, nicht nur die am leichtesten erreichbaren Geräte. Bei auffälliger Scoreverteilung, höherem Energiebedarf oder technischen Fehlern stoppt der Rollout, bevor die gesamte Flotte betroffen ist.

Gelabelte Befunde statt unkontrollierter Selbstbestätigung

Für die Weiterentwicklung werden Edge-Meldung, ausgewähltes Rohfenster, Betriebszustand und Wartungsbefund in einem kuratierten Datensatz verbunden. Das aktuelle Modell darf seine eigenen Vorhersagen nicht ungeprüft zu neuen Trainingslabels machen. Sonst verstärkt es frühere Fehler. Fachlich bestätigte Befunde, zufällige Normalstichproben und bewusst erfasste Grenzfälle ergeben eine belastbarere Grundlage für die nächste Version.

Die Datenfreigabe hält fest, aus welchen Anlagen und Zeiträumen Beispiele stammen, welche Personen Zugriff hatten und welche Ausschlüsse gelten. Vor einem Retraining wird geprüft, ob neue Daten echte Veränderungen oder nur einen Sensor- beziehungsweise Firmwarewechsel abbilden. Auf diese Weise bleibt die Modellverbesserung nachvollziehbar und kann bei schlechterer Feldleistung auf eine bekannte Version zurückgesetzt werden.

Häufige Fragen

Was ist TinyML?

TinyML bezeichnet kompakte Machine-Learning-Modelle, die direkt auf ressourcenbegrenzten Mikrocontrollern oder ähnlichen Edge-Geräten ausgeführt werden.

Warum passt TinyML zu LoRaWAN?

Das Modell verdichtet große lokale Sensorsignale zu kleinen Scores, Klassen und Kennwerten, die sich effizient per LoRaWAN senden lassen.

Werden Modelle direkt auf dem Sensor trainiert?

Meist findet das Training außerhalb des Endgeräts statt. Der Mikrocontroller führt anschließend das konvertierte und validierte Modell zur Inferenz aus.

Können TinyML-Modelle per LoRaWAN aktualisiert werden?

Grundsätzlich ja, etwa über FUOTA-Bausteine. Speicher, Integrität, Energie, Downlinkkapazität, gestufter Rollout und Rollback müssen dafür geplant sein.

Wann ist keine KI nötig?

Wenn eine transparente physikalische Schwelle oder ein einfacher Kennwert den Anwendungsfall zuverlässig löst, ist diese Lösung meist leichter zu validieren und zu betreiben.