IoT-Anomalieerkennung bedeutet, Sensorwerte oder Muster, die nicht zum normalen Verhalten passen, automatisch und früh genug zu erkennen, um handeln zu können. Dieser Leitfaden vergleicht die wichtigsten Detektorfamilien, zeigt, wo jede von ihnen relativ zu Ihrem MQTT-Broker laufen sollte, und liefert eine Referenzarchitektur für die Veröffentlichung von Anomalieereignissen, denen Dashboards und Menschen vertrauen können.
Was in IoT-Daten als Anomalie gilt
Nicht alle Anomalien sehen gleich aus, und der Typ, um den es Ihnen geht, bestimmt die Methode.
- Punktanomalien. Ein einzelner Messwert weit außerhalb des normalen Bereichs: 140 Grad an einem Sensor, der nie über 80 steigt.
- Kontextuelle Anomalien. Ein Wert, der in einem Kontext normal und in einem anderen auffällig ist: 30 Grad sind im Sommer zur Mittagszeit in Ordnung, um 3 Uhr nachts in einem Kühlraum dagegen verdächtig.
- Kollektive Anomalien. Ein Muster über die Zeit: Schwingungen, die bei jedem Messwert innerhalb der Grenzen liegen, deren Spektrum sich aber langsam in Richtung einer Lagerschadenfrequenz verschiebt.
- Multivariate Anomalien. Jedes Signal ist für sich normal, die Kombination aber nicht: hoher Motorstrom bei geringem Durchfluss deutet auf eine blockierte Pumpe hin.
Es gibt außerdem eine Kategorie, die gar nichts mit dem Prozess zu tun hat: Datenqualitätsanomalien wie ein Sensor mit Nulllinie, ein eingefrorener Wert, ein plötzlicher Einheitenwechsel oder Zeitstempel in falscher Reihenfolge. In der Praxis gehören sie zu den häufigsten Alarmen, und wenn Sie sie zuerst abfangen, verhindern Sie Fehlalarme Ihrer Prozessdetektoren.
Methodenfamilien der IoT-Anomalieerkennung
| Familie | Beispiele | Gut geeignet für | Benötigt Trainingsdaten | Läuft auf Mikrocontroller |
|---|---|---|---|---|
| Regeln und Schwellenwerte | Feste Grenzen, Grenzen für Änderungsraten | Bekannte Fehlerbilder, Sicherheitsgrenzen | Nein | Ja |
| Statistisch | Z-Score, IQR, EWMA, gleitende Fenster | Einzelsignale mit stabiler Basislinie | Eine kurze Historie | Ja |
| Klassisches Machine Learning | Isolation Forest, One-Class SVM, Local Outlier Factor | Multivariate tabellarische Merkmale | Normaldaten, ungelabelt | Manchmal |
| Deep Learning | Autoencoder, LSTM- oder 1D-CNN-Prädiktoren | Wellenformen, Spektren, komplexe Zeitmuster | Großer Normaldatensatz | Nur kleine Modelle |
| Prognoseresiduum | Saisonale Modelle, Gradient-Boosting-Prognosen | Saisonale Signale wie Energielast | Historie mit Jahreszeiten | Selten |
Statistische Detektoren
Beginnen Sie hier. Ein gleitender Mittelwert mit Standardabweichung oder ein Median mit Interquartilsabstand erfassen einen überraschend großen Anteil realer Probleme mit nahezu keinem Entwicklungsaufwand. EWMA (exponentiell gewichteter gleitender Mittelwert) passt sich langsamer Drift an, ohne ein Fenster zu speichern. Diese Methoden sind erklärbar, günstig und leicht abzustimmen. Details und Code finden Sie unter Ausreißererkennung in Sensordaten mit Z-Score, IQR und EWMA.
Machine-Learning-Detektoren
Verbergen sich Anomalien in der Beziehung zwischen Signalen, trainieren Sie ein unüberwachtes Modell auf Normalbetrieb. Isolation Forest ist ein praxistauglicher Standard: schnell zu trainieren, robust gegenüber irrelevanten Merkmalen und ohne Labels nutzbar. Sie berechnen Merkmale pro Fenster (Mittelwert, RMS, Spitzenwert, Steigung pro Signal), und das Modell bewertet, wie isoliert jedes Fenster ist. Eine vollständige Anleitung finden Sie unter Isolation Forest für Sensordaten.
Deep-Learning-Detektoren
Bei rohen Wellenformen wie Schwingungen und Schall lernen Autoencoder, normale Muster zu rekonstruieren; ein hoher Rekonstruktionsfehler weist auf etwas Neues hin. Sie benötigen mehr Daten und Rechenleistung und sind schwerer zu erklären. Setzen Sie sie daher ein, wenn einfachere Merkmale tatsächlich versagen. Maschinengeräusche sind ein gutes Beispiel, behandelt in Audio-Anomalieerkennung für Maschinen.
Wo Detektoren relativ zum Broker laufen
MQTT sorgt für eine saubere Trennung: Geräte veröffentlichen Daten, Detektoren abonnieren sie und veröffentlichen ihre Ergebnisse als neue Nachrichten. Der MQTT-Broker sitzt in der Mitte und muss nicht wissen, was ein Detektor tut. Daraus ergeben sich drei Platzierungsoptionen.
Auf dem Gerät
Führen Sie Schwellenwerte, Prüfungen der Änderungsrate und winzige Modelle direkt auf dem Sensorknoten aus. Vorteile: sofortige Reaktion, keine Abhängigkeit von der Verbindung, und Sie können statt hochfrequenter Rohdaten nur Zusammenfassungen und Anomalieereignisse senden. Grenzen: kleine Modelle, schwierigere Updates und kein geräteübergreifender Kontext.
Am Edge-Gateway
Ein Gateway oder Industrie-PC abonniert die lokalen Maschinen, führt umfangreichere Modelle wie Isolation Forest oder Autoencoder aus und veröffentlicht Scores. Das ist der ideale Ort für multivariate Erkennung innerhalb einer Maschine oder Linie, etwa als Vorstufe für Predictive Maintenance, und hochfrequente Daten bleiben am Standort.
In der Cloud
Ein Cloud-Dienst abonniert viele Standorte gleichzeitig. Er kann ähnliche Maschinen werksübergreifend vergleichen, aufwendige Modelle ausführen und Prozessdaten mit geschäftlichem Kontext kombinieren. Die Latenz ist höher, und er hängt von der Uplink-Verbindung ab – für alles Sicherheitsrelevante ist er daher der falsche Ort.
Die meisten realen Systeme kombinieren alle drei: Grenzwerte auf dem Gerät, ML an der Edge, Flottenvergleiche in der Cloud, alle verbunden über Topics.
Eine Referenzarchitektur für Topics
connectmq/site1/area2/line1/pump3/telemetry raw or aggregated readings
connectmq/site1/area2/line1/pump3/anomaly detector output per asset
connectmq/site1/alerts confirmed alerts for people
connectmq/site1/area2/line1/pump3/detector/status retained: model, version, health
Die Topics folgen der ISA-95-Hierarchie aus Standort, Bereich, Linie und Anlage und sind damit Teil eines Unified Namespace (UNS). In einem deutschen Werk sähe der Pfad etwa so aus: acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Der Vorteil für die Anomalieerkennung: Ein Detektor kann eine ganze Linie per Wildcard abonnieren, und seine Ergebnisse landen direkt neben der Telemetrie derselben Anlage, wo MES, Instandhaltung und Dashboards sie ohne zusätzliches Mapping finden. Wie Sparkplug-B-Daten in diesen Namespace gelangen, beschreibt Sparkplug B und der Unified Namespace.
Eine Ausgabenachricht eines Detektors sollte selbsterklärend sein:
{
"ts": "2026-10-16T09:12:30Z",
"asset": "pump3",
"detector": "iforest-v3",
"score": 0.71,
"threshold": 0.62,
"isAnomaly": true,
"features": {"currentA": 18.4, "flowLpm": 41.0},
"reason": "high current with low flow"
}
Wenn Schwellenwert, Detektorversion und die wichtigsten beitragenden Merkmale enthalten sind, wird aus einer undurchsichtigen roten Lampe etwas, das ein Techniker überprüfen kann.
Eine minimale Detektorschleife
Der Kern jedes Streaming-Detektors passt in wenige Zeilen. Dieser Scorer mit gleitendem Z-Score ist das Muster, das das vollständige Tutorial Echtzeit-Anomalieerkennung in Python zu einem kompletten MQTT-Dienst ausbaut:
from collections import deque
import statistics
window = deque(maxlen=120)
def score(value, k=3.5):
if len(window) < 30:
window.append(value)
return None
mean = statistics.fmean(window)
std = statistics.pstdev(window) or 1e-9
z = (value - mean) / std
if abs(z) < k:
window.append(value) # nur aus normalen Werten lernen
return z
Beachten Sie das letzte Detail: Anomale Werte fließen nicht in die Basislinie ein, sodass eine lang andauernde Störung nicht allmählich zum neuen Normalzustand wird.
Fehlalarme reduzieren
Fehlalarme bringen Projekte zur Anomalieerkennung schneller zu Fall als verpasste Erkennungen, weil die Bediener irgendwann nicht mehr hinsehen. Eine hilfreiche Checkliste:
- Zuerst die Datenqualität filtern. Markieren Sie eingefrorene, fehlende und unplausible Werte getrennt von Prozessanomalien.
- Kontext nutzen. Ignorieren Sie Messwerte während Anlauf, Reinigung und Produktwechsel, die Sie über ein Zustands-Topic erkennen können.
- Persistenz verlangen. Lösen Sie einen Alarm erst nach N anomalen Fenstern von M aus, nicht bei einem einzelnen Messwert.
- Hysterese einbauen. Setzen Sie den Alarm bei einem niedrigeren Schwellenwert zurück als dem, der ihn ausgelöst hat, um Flattern zu vermeiden.
- Score und Alarm trennen. Veröffentlichen Sie Roh-Scores kontinuierlich und entscheiden Sie über die Alarmierung in einem separaten, abstimmbaren Schritt.
- Wöchentlich prüfen. Kennzeichnen Sie jeden Alarm als nützlich oder als Rauschen und passen Sie Schwellenwerte anhand dieses Protokolls an.
- Detektoren versionieren. Nehmen Sie die Detektorversion in jede Nachricht auf, damit Sie den Zustand vor und nach einer Änderung vergleichen können.
Die Messaging-Schicht betreiben
Detektoren, Dashboards, Historians und Alarmierungswerkzeuge hängen alle am selben Broker, daher ist seine Zuverlässigkeit entscheidend. Für Experimente genügt der kostenlose öffentliche MQTT-Broker, den ConnectMQ unter broker.connectmq.com betreibt, um in wenigen Minuten einen Simulator, einen Detektor und ein Dashboard zu verbinden; er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Für echte Anlagendaten brauchen Sie einen privaten, TLS-gesicherten Cloud-MQTT-Broker mit gerätespezifischen Zugangsdaten.
ConnectMQ stellt genau diese Schicht bereit: MQTT 3.1.1 und 5.0 über TLS und sicheres WebSocket, eine nach ISA-95-Ebenen gegliederte Geräteansicht, die zu einem UNS passt, einen Live-Topic-Explorer, um Scores in Echtzeit zu verfolgen, sowie Schwellenwert-Alarmregeln mit Alarmprotokoll für einfache numerische Grenzen. Die Erkennungsmodelle selbst laufen in Ihren Diensten, sodass Sie jede beliebige Bibliothek verwenden können.
Wie Anomalieerkennung mit Prognosen, Computer Vision und LLM-Assistenten zusammenspielt, lesen Sie im Leitfaden zu KI und IoT.
Bauen Sie Ihre Anomalie-Pipeline mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen Broker im kostenlosen Serverless-Tarif, ganz ohne Kreditkarte, veröffentlichen Sie simulierte Messwerte und betreiben Sie einen Detektor, der Scores zurückveröffentlicht. Innerhalb weniger Minuten sehen Sie Rohwerte und Anomalieereignisse nebeneinander im Topic-Explorer.
Häufig gestellte Fragen
Mit welcher Methode zur Anomalieerkennung sollte ich beginnen?
Beginnen Sie mit Schwellenwerten und einem gleitenden Z-Score oder EWMA für jedes wichtige Signal. Wechseln Sie erst dann zu Isolation Forest oder Autoencodern, wenn Belege dafür vorliegen, dass die Anomalien in den Beziehungen zwischen Signalen oder in Wellenformen stecken.
Brauche ich gelabelte Ausfalldaten?
Nein. Die meiste IoT-Anomalieerkennung ist unüberwacht: Modelle lernen normales Verhalten und markieren Abweichungen. Labels werden später wertvoll, um Alarme zu bewerten und abzustimmen.
Sollte die Anomalieerkennung an der Edge oder in der Cloud laufen?
Führen Sie schnelle, sicherheitsrelevante Prüfungen auf dem Gerät oder an der Edge aus und flottenweite Vergleiche in der Cloud. Mit MQTT können Sie einen Detektor zwischen diesen Orten verschieben, ohne die Geräte zu ändern.
Wie veröffentliche ich Ergebnisse der Anomalieerkennung?
Veröffentlichen Sie pro Anlage eine JSON-Nachricht auf einem eigenen Anomalie-Topic mit Score, Schwellenwert, Detektorversion und beitragenden Merkmalen. Bestätigte Alarme für Menschen gehören auf ein separates Topic.
