Predictive Maintenance mit Machine Learning nutzt Zustandsdaten von Maschinen, um abzuschätzen, ob ein Ausfall bevorsteht, sodass die Instandhaltung vor einem Stillstand geplant werden kann statt danach. In diesem Leitfaden erfahren Sie, wie Sie die richtigen Signale über MQTT erfassen, daraus Features und Labels machen, ein erstes Modell wählen und es so validieren, dass es widerspiegelt, wie es sich auf dem Shopfloor verhalten wird.
Was Machine Learning der Instandhaltung bringt
Die meisten Werke betreiben bereits eine Form der Zustandsüberwachung: einen Schwingungsalarm bei einem festen Grenzwert, ein Temperaturlimit an einem Lager. Diese statischen Schwellwerte funktionieren bei offensichtlichen Fehlern, übersehen aber langsame Degradation über mehrere Signale und lösen oft zu spät aus. Machine Learning bringt zwei Dinge mit. Es kann mehrere schwache Signale zu einem stärkeren Indikator kombinieren, und es kann lernen, wie „normal“ für jede Maschine unter verschiedenen Lasten aussieht, statt ein Limit auf alle anzuwenden.
Ebenso klar sollte man die Grenzen benennen. Ein Modell kann nur Ausfallmuster lernen, die in seinen Daten vorkommen. Wenn ein Maschinentyp in fünf Jahren zweimal ausgefallen ist, lernt ein überwachter Ausfallklassifikator nicht viel; ein Ansatz mit Anomalieerkennung oder Degradationstrend passt besser. Die richtige Problemformulierung ist wichtiger als die Wahl des Algorithmus.
Das Problem formulieren
| Formulierung | Beantwortete Frage | Voraussetzungen | Gute erste Wahl, wenn |
|---|---|---|---|
| Anomalieerkennung | Verhält sich diese Maschine ungewöhnlich? | Nur Daten aus dem Normalbetrieb | Ausfälle selten oder schlecht dokumentiert sind |
| Ausfallklassifikation | Fällt diese Maschine in den nächsten N Tagen aus? | Gelabelte Ausfallhistorie | Ausfälle häufig sind und protokolliert werden |
| Regression der Restlebensdauer | Wie lange bis zum Ausfall? | Run-to-Failure-Verläufe | Die Degradation allmählich und wiederholbar ist |
| Klassifikation des Fehlermodus | Welcher Fehler entwickelt sich? | Gelabelte Fehlertypen | Instandhaltungsberichte die Grundursachen benennen |
Viele Teams beginnen mit Anomalieerkennung, weil sie keine Labels braucht, und wechseln zur Klassifikation, sobald sie genügend gelabelte Ereignisse gesammelt haben. Der Artikel zur IoT-Anomalieerkennung behandelt diesen ersten Schritt, und Vorhersage der Restlebensdauer behandelt die Regressionsformulierung.
Zustandsdaten über MQTT erfassen
Die Signale sollten sich an den Fehlermodi orientieren, die Ihnen wichtig sind. Für rotierende Anlagen sind das üblicherweise Schwingungsmerkmale, Lager- oder Wicklungstemperatur, Motorstrom und Drehzahl. Für Hydraulik- und Pneumatiksysteme Druck, Durchfluss und Zykluszeiten. Nehmen Sie immer den Betriebskontext wie Last, Drehzahlsollwert und Produkt mit auf, denn ein Modell, das die Last nicht kennt, hält eine schwere Charge für einen sich entwickelnden Fehler.
Ein praxistaugliches MQTT-Layout publiziert Features pro Asset unter einer Hierarchie, mit Quellzeitstempeln. Am besten ist diese Hierarchie Teil eines Unified Namespace (UNS), dessen Topic-Struktur der ISA-95-Anlagenhierarchie folgt (Enterprise → Site → Area → Line → Cell), etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Dann finden Modell, Historian, MES und Instandhaltungssystem dieselben Zustandsdaten am selben Ort:
connectmq/plant1/line2/pump3/condition {"ts":..., "vib_rms":..., "vib_peak":..., "bearing_temp":..., "current":..., "load":...}
connectmq/plant1/line2/pump3/events {"ts":..., "type":"maintenance", "action":"bearing replaced"}
Berechnen Sie Schwingungsmerkmale an der Edge, statt kHz-Wellenformen zu streamen. Ein Fenster von einer Sekunde liefert RMS, Spitzenwert, Crest-Faktor und einige spektrale Bandenergien – klein genug, um alle paar Sekunden publiziert zu werden. Mehr zur Topic-Struktur eines UNS lesen Sie im Artikel zu Sparkplug B und Unified Namespace. Das Events-Topic ist genauso wichtig wie die Telemetrie; ohne aufgezeichnete Instandhaltungsmaßnahmen und Ausfälle können Sie keine Labels bilden. Der Leitfaden zum Labeln von Zeitreihen-Sensordaten zeigt, wie Sie diese Ereignisse von Bedienern erfassen.
Feature Engineering für Predictive Maintenance mit Machine Learning
Rohwerte sind selten die besten Modelleingaben. Degradation zeigt sich als Veränderung von Niveau, Variabilität und Trend über die Zeit, daher werden Features typischerweise über gleitende Fenster berechnet.
- Niveau-Features: gleitender Mittelwert von RMS-Schwingung, Temperatur, Strom.
- Variabilitäts-Features: gleitende Standardabweichung, Spitze-Spitze-Wert, Crest-Faktor.
- Trend-Features: Steigung einer linearen Anpassung über die letzten Stunden oder Tage.
- Relative Features: Temperaturanstieg gegenüber der Umgebung, Strom pro Lasteinheit, Schwingung im Vergleich zur Baseline derselben Maschine.
- Spektrale Features: Energie in Frequenzbändern, die mit Lagerschadensfrequenzen oder Unwucht zusammenhängen.
- Betriebskontext: Last, Drehzahl, Betriebsstunden seit der letzten Wartung.
Normalisieren Sie pro Asset, wo sich Maschinen unterscheiden. Eine Pumpe, die schon immer etwas stärker vibriert als ihre Nachbarn, degradiert nicht zwingend; entscheidend ist die Veränderung relativ zu ihrer eigenen Historie.
Labels ohne Leakage bilden
Für eine Klassifikationsformulierung ist ein gängiges Label „fällt innerhalb der nächsten H Stunden aus“. Sie nehmen jeden Ausfallzeitpunkt und markieren die Fenster innerhalb des Horizonts davor als positiv, alles andere als negativ. Drei Regeln halten die Labels ehrlich:
- Schließen Sie den Zeitraum direkt nach einer Wartung für kurze Zeit aus, weil Messwerte während des Einlaufens nicht repräsentativ sind.
- Verwerfen Sie Fenster, die den Ausfall selbst enthalten, sonst lernt das Modell, eine stehende Maschine zu erkennen.
- Berechnen Sie Features nie mit Daten, die nach dem Zeitstempel des Fensters liegen. Zentrierte gleitende Fenster sind eine klassische Quelle für Leakage.
Ein lauffähiges Beispiel in Python
Das folgende Skript erzeugt simulierte Zustandsdaten für mehrere Pumpen mit gelegentlicher Degradation, publiziert sie an den öffentlichen MQTT-Broker (nur für Tests, niemals für echte Maschinendaten), sammelt sie mit einem Subscriber wieder ein und trainiert einen Gradient-Boosting-Klassifikator, der auf Pumpen evaluiert wird, die er im Training nie gesehen hat. In der Praxis würde der Collector stattdessen aus Ihrem Historian lesen.
import json
import random
import time
import uuid
import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.metrics import classification_report
BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1"
rows = []
def on_message(client, userdata, msg):
p = json.loads(msg.payload)
p["asset"] = msg.topic.split("/")[-2]
rows.append(p)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe(f"{PREFIX}/+/condition", qos=1)
client.loop_start()
time.sleep(1)
# 6 Pumpen x 600 Schritte simulieren; einige degradieren gegen Ende bis zum Ausfall
for asset in range(6):
fails = asset % 2 == 0
for step in range(600):
wear = max(0, step - 400) / 200 if fails else 0
body = {
"step": step,
"vib_rms": round(1.0 + 1.5 * wear ** 2 + random.gauss(0, 0.08), 3),
"bearing_temp": round(55 + 12 * wear + random.gauss(0, 0.5), 2),
"current": round(14 + 1.5 * wear + random.gauss(0, 0.2), 2),
"load": round(random.uniform(0.6, 1.0), 2),
"failed_at": 600 if fails else None,
}
client.publish(f"{PREFIX}/pump{asset}/condition", json.dumps(body), qos=0)
time.sleep(0.11) # unter dem Limit des öffentlichen Brokers von 10 msg/s pro Client bleiben
time.sleep(3)
client.loop_stop()
df = pd.DataFrame(rows).sort_values(["asset", "step"])
HORIZON = 100
df["label"] = ((df["failed_at"].notna()) & (df["failed_at"] - df["step"] <= HORIZON)).astype(int)
feats = []
for col in ["vib_rms", "bearing_temp", "current"]:
g = df.groupby("asset")[col]
df[f"{col}_mean20"] = g.transform(lambda s: s.rolling(20, min_periods=5).mean())
df[f"{col}_std20"] = g.transform(lambda s: s.rolling(20, min_periods=5).std())
df[f"{col}_slope50"] = g.transform(lambda s: s.diff(50) / 50)
feats += [f"{col}_mean20", f"{col}_std20", f"{col}_slope50"]
feats.append("load")
df = df.dropna(subset=feats)
# Aufteilung nach Asset: Training auf Pumpen 0-3, Test auf Pumpen 4-5, die das Modell nie gesehen hat
train, test = df[~df["asset"].isin(["pump4", "pump5"])], df[df["asset"].isin(["pump4", "pump5"])]
model = HistGradientBoostingClassifier(max_iter=200, learning_rate=0.05)
model.fit(train[feats], train["label"])
print(classification_report(test["label"], model.predict(test[feats]), digits=3))
Installieren Sie die Abhängigkeiten mit pip install paho-mqtt pandas numpy scikit-learn. Der Durchlauf dauert mehrere Minuten, weil der Simulator das Ratenlimit des öffentlichen Brokers einhält. Mit Ihrem eigenen ConnectMQ-Broker und YOUR_USERNAME, YOUR_PASSWORD und YOUR_CLIENT_ID über Port 8883 können Sie von vielen Geräten parallel publizieren.
Ein erstes Modell wählen
- Gradient Boosted Trees (scikit-learn, XGBoost, LightGBM) sind der Standard für tabellarische Features. Sie kommen mit unterschiedlichen Skalen zurecht, brauchen wenig Tuning und liefern Feature-Importances, über die Instandhaltungsingenieure diskutieren können.
- Logistische Regression ist eine nützliche Baseline und leicht zu erklären.
- Isolation Forest oder Autoencoder für die Anomalieformulierung, wenn Labels knapp sind.
- Sequenzmodelle (LSTM, 1D-CNN, Transformer) erst, wenn Sie viel Historie haben und einfache Modelle ein Plateau erreicht haben.
Validieren wie in der Produktion
Zufällige Train-Test-Splits überschätzen die Leistung bei Zeitreihen, weil benachbarte Fenster nahezu identisch sind. Verwenden Sie einen zeitbasierten Split und halten Sie idealerweise ganze Assets zurück, um zu prüfen, ob das Modell auf Maschinen generalisiert, die es nicht gesehen hat. Berichten Sie Precision und Recall bei dem Alarmschwellwert, den Sie verwenden wollen, und übersetzen Sie sie in betriebliche Größen: wie viele Fehlalarme pro Woche und wie viele Ausfälle mit welcher Vorlaufzeit erkannt werden. Das sind die Zahlen, die für einen Instandhaltungsplaner zählen.
Bereitstellen und den Kreis schließen
Ein bereitgestelltes Modell ist einfach ein weiterer MQTT-Client. Es abonniert Zustands-Topics, bewertet jedes neue Fenster und publiziert einen Risiko-Score:
connectmq/plant1/line2/pump3/health {"ts":..., "risk":0.82, "model":"pdm-gbt-1.4"}
Dashboards, CMMS-Connectoren, MES und Alarmierungstools abonnieren dieses Topic; im UNS liegt der Risiko-Score damit direkt neben den Zustandsdaten desselben Assets. Im ConnectMQ-Portal können Sie zudem Schwellwert-Alarmregeln auf den publizierten Risikowert definieren, sodass ein Score oberhalb Ihres gewählten Limits ohne zusätzlichen Code im Alarmprotokoll erscheint. Erfassen Sie das Ergebnis jedes Alarms als Ereignis, führen Sie es in die Labels zurück und trainieren Sie regelmäßig neu; der Artikel zu IoT-MLOps behandelt diesen Lebenszyklus.
Für das Gesamtbild, wie Modelle und Geräte zusammenarbeiten, siehe den Leitfaden zu KI und IoT. Eine Digital-Twin-Perspektive auf dasselbe Problem bietet Predictive Maintenance mit digitalem Zwilling, der den datengetriebenen Ansatz um physikalischen Kontext ergänzt.
Starten Sie mit ConnectMQ
Beginnen Sie noch heute mit der Erfassung von Zustandsdaten: Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, und verbinden Sie Ihre Edge-Geräte mit den generierten Zugangsdaten. ConnectMQ bietet Ihnen einen verwalteten MQTT-Broker mit TLS, Live-Topic-Explorer und Schwellwert-Alarmen, damit Sie sich auf Features und Modelle konzentrieren können statt auf den Broker-Betrieb. Wenn Sie später mehr Verbindungen oder Isolation brauchen, ziehen dieselben Topics in einen Cloud-MQTT-Broker-Plan mit mehr Kapazität um.
Häufig gestellte Fragen
Wie viele Daten brauche ich für Predictive Maintenance mit Machine Learning?
Für überwachte Ausfallvorhersage brauchen Sie mehrere aufgezeichnete Ausfälle pro Fehlermodus sowie Zustandsdaten vor jedem davon. Wenn Sie nur wenige Ausfälle haben, beginnen Sie mit Anomalieerkennung auf Normaldaten und sammeln Sie unterwegs gelabelte Ereignisse.
Welcher Algorithmus ist für Predictive Maintenance am besten?
Gradient Boosted Trees auf gut entwickelten gleitenden Features sind für die meisten Zustandsdaten ein starker Ausgangspunkt. Tiefe Sequenzmodelle können bei großen Historien helfen, schlagen gute Features bei kleinen Datensätzen aber selten.
Warum wirkt mein Modell im Test genau, versagt aber in der Produktion?
Die häufigsten Ursachen sind zufällige Splits, die nahezu identische Fenster in die Testmenge durchsickern lassen, Features, die mit zukünftigen Daten berechnet wurden, und fehlender Betriebskontext. Verwenden Sie zeit- oder assetbasierte Splits und prüfen Sie die Feature-Fenster sorgfältig.
Kann der MQTT-Broker das Modell ausführen?
Nein, der Broker routet Nachrichten. Führen Sie das Modell als separaten MQTT-Client an der Edge oder in der Cloud aus, der Zustands-Topics abonniert und Scores zurück an den Broker publiziert.
