Wie Sie Predictive Maintenance zuverlässig in die Produktion bringen: Datenaufnahme über MQTT, Zeitreihenspeicher, Feature Engineering, Modelltraining, MLflow-Tracking, API-Deployment in Docker sowie Monitoring, Dashboards und Alerting.
Predictive Maintenance scheitert selten am ersten Modell – sondern daran, das Modell zuverlässig, nachvollziehbar und wartbar in den Betrieb zu bringen. Genau hier setzt MLOps an: Es verbindet Datenpipeline, Modelltraining, Deployment und Monitoring zu einem belastbaren Gesamtsystem.
In diesem Artikel zeigen wir das CASE-MLOps-Konzept für Predictive Maintenance: vom Sensor bis zur Alarmierung – inklusive Datenaufnahme über MQTT, Zeitreihenspeicher, Feature Engineering, MLflow-Tracking und einem API-Deployment mit FastAPI + Docker.
Was „gute“ MLOps in Predictive Maintenance bedeutet
- Zuverlässigkeit: stabile Datenaufnahme, reproduzierbares Training, sichere Deployments und klare Rollback-Pfade.
- Nachvollziehbarkeit: Sie können beantworten: „Welches Modell hat das entschieden?“, „mit welchen Daten?“, „mit welchen Parametern?“.
- Business-Integration: Vorhersagen werden zu Aktionen (Alerts, MES-Events, Tickets) – nicht nur zu Charts.
Referenz-Architektur: 8 Schritte vom Sensor zur Alarmierung
Die folgenden Bausteine bilden eine bewährte End-to-End-Pipeline. Entscheidend ist nicht ein einzelnes Tool, sondern die klare Verantwortlichkeit je Schritt.
1) MQTT Broker (HiveMQ)
Sensoren (z. B. Vibration, Temperatur, Strom) senden Messwerte als MQTT-Nachrichten an einen zentralen Broker.
2) Ingestion (Telegraf)
Telegraf hört auf dem Broker mit, normalisiert Payloads, ergänzt Zeitstempel und leitet strukturierte Time-Series-Events weiter.
3) Storage (TimescaleDB)
Ein Zeitreihenspeicher ermöglicht schnelle Abfragen, lange Historien, Trendanalysen und eine stabile Basis fürs ML.
4) Processing (Python)
Feature Engineering macht aus Rohsignalen aussagekräftige Kennzahlen (RMS, Peaks, FFT-Bänder, Rolling Stats, Trends).
5) Training (ML)
Je nach Reifegrad trainieren Sie Anomalie-Erkennung (ohne Labels) oder überwachte Modelle (mit Labels).
6) Tracking & Registry (MLflow)
Experimente, Parameter, Metriken und Versionen werden getrackt; Modelle werden für kontrollierte Releases und Rollbacks registriert.
7) Serving (FastAPI + Docker)
Das Modell wird hinter einer API bereitgestellt, per Docker containerisiert und reproduzierbar ausgerollt.
8) Observability (Grafana + Alerts)
Dashboards zeigen Signale, Anomalie-Score und Zustand; Alerts gehen an Teams/E-Mail/Webhooks (z. B. MES/Tickets).
Deep Dive: Warum jeder Schritt wichtig ist
1–3) Data Ingestion & Storage: „ohne Daten kein Lernen“
In Predictive Maintenance ist die „harte“ Arbeit selten ein fancy Modell – sondern konsistente, vertrauenswürdige Daten. MQTT liefert eine schlanke Transportebene vom Shopfloor; Telegraf macht daraus strukturierte Records; TimescaleDB speichert Historie, damit Sie Trends berechnen, Zeiträume vergleichen und Trainingsdaten aufbauen können.
Praxis-Tipp: Datenvertrag (Data Contract) früh definieren
Definieren Sie früh die Payload-Struktur (machineId, sensorType, value, unit, timestamp, quality flags). Das verhindert stille Breaking Changes, macht Ingestion testbar und reduziert Reibung zwischen Teams.
- Zeit-Synchronisation: Entscheiden Sie, ob Zeitstempel vom Edge, vom Broker oder von der Ingestion kommen.
- Einheiten: Normalisieren Sie Einheiten (°C, mm/s, A), um nicht auf gemischten Skalen zu trainieren.
- Qualität: Behandeln Sie „missing / out-of-range / sensor fault“ als First-Class-Signale.
4) Python Processing: von Rohdaten zu Features
Rohdatenströme können massiv sein (z. B. Vibration mit Tausenden Samples pro Sekunde). Feature Engineering verdichtet das zu informativen Kennzahlen: Rolling Means, Steigungen, RMS, Peak-to-Peak, Kurtosis und Frequenzbänder (FFT). Gute Features erhöhen Stabilität und Interpretierbarkeit – und senken oft die Inferenz-Latenz.
5) Training: zwei Wege – abhängig von Label-Reife
Track A — Ohne Labels (häufig am Anfang)
Das Modell lernt „Normalbetrieb“ und markiert Abweichungen als Anomalien.
- Typische Modelle: Isolation Forest, One-Class SVM, Autoencoder.
- Outputs: Anomalie-Score, Schwellenwert, Schweregrad (grün/gelb/rot).
- Ziel: schnelle Time-to-Value, während Labels parallel aufgebaut werden.
Track B — Mit Labels (höhere Reife)
Das Modell lernt Muster, die zu konkreten Fehlern führen (z. B. Lagerverschleiß, Überhitzung, Stillstand).
- Typische Modelle: XGBoost, LightGBM, zeitbasierte Klassifikatoren/Regressoren.
- Outputs: Ausfallrisiko, RUL-Signale, Wahrscheinlichkeiten je Fehlerart.
- Ziel: präzisere Alerts und bessere Priorisierung für Instandhaltungsteams.
6) MLflow: Ordnung statt Chaos
MLflow ist wie ein Lab-Notebook plus Model Registry. Es speichert, was trainiert wurde – inklusive Daten-Version, Parametern und Metriken. So können Sie Modelle vergleichen, Ergebnisse reproduzieren und kontrolliert in Produktion bringen (oder bei Bedarf zurückrollen).
7) FastAPI + Docker: Serving in der Praxis
Training ist „Schule“, Serving ist „Job“. Ein FastAPI-Service mit Docker-Container sorgt für konsistente Deployments. Die Anlage fragt „Bin ich gesund?“ – der Service antwortet mit Score, Status und Kontext, damit Entscheidungen unterstützt werden.
8) Grafana + Alerts: Ergebnisse handlungsfähig machen
Dashboards sollten (1) Sensortrends, (2) abgeleitete Features, (3) Anomalie-Score/Risiko und (4) Maschinenzustand zeigen. Alerts brauchen Routing (Teams, E-Mail, Webhook), Deduplizierung und Eskalationsregeln. Das Modell empfiehlt – der Mensch entscheidet.
Labeling & Feedback Loop: Wie das System besser wird
Viele Projekte starten ohne Labels. Der schnellste Weg zu höherer Präzision ist eine Feedback-Schleife, die Betriebswissen in Trainingsdaten übersetzt.
Label-Quellen (bewährte Optionen)
- Shopfloor-Systeme: MES-Events (machine_state=STOP, alarm_code), SPS/PLC-Alarme, Instandhaltung/Ticket-Notizen.
- Dashboard-UI ("Ereignis markieren"): Ereignisart wählen, Start/Ende (oder Zeitpunkt) setzen, Kommentar hinzufügen, optional Foto/Attachment.