Condition Monitoring vs. Predictive Maintenance: Unterschiede, Reifegradpfad und MQTT-Datenflüsse

Condition Monitoring vs. Predictive Maintenance ist einer der am häufigsten verwechselten Vergleiche in der Instandhaltung, und Anbieter verwischen die Grenze oft absichtlich. Dieser Artikel trennt beides klar, zeigt den Reifegradpfad, der vom einen zum anderen führt, und skizziert für beide den MQTT-Datenfluss, den Sie aufbauen würden, damit Sie entscheiden können, wo Ihr Werk als Nächstes investieren sollte.

Die kurze Antwort

Condition Monitoring (Zustandsüberwachung) misst den Gesundheitszustand einer Anlage und meldet, wenn gerade jetzt etwas abnormal ist. Predictive Maintenance (vorausschauende Instandhaltung) nutzt dieselben Zustandsdaten plus Historie, um abzuschätzen, wann ein Ausfall wahrscheinlich wird, damit Sie die Reparatur zum besten Zeitpunkt planen können.

Condition Monitoring ist eine Fähigkeit. Predictive Maintenance ist eine Strategie, die darauf aufbaut. Ohne Condition Monitoring gibt es keine Predictive Maintenance, aber Sie können, und die meisten Werke sollten, Condition Monitoring lange betreiben, bevor Sie sich an Prognosen wagen.

Condition Monitoring vs. Predictive Maintenance im Überblick

Beide Ansätze stehen im Gegensatz zur reaktiven Instandhaltung (reparieren, wenn es kaputt ist) und zur präventiven Instandhaltung (nach Kalender oder Zähler warten, unabhängig vom Zustand). Das Ziel ist bei beiden dasselbe: keine gesunden Teile mehr tauschen und nicht mehr von ausfallenden überrascht werden.

Wie Condition Monitoring in der Praxis aussieht

Ein Condition-Monitoring-System misst kontinuierlich oder periodisch eine physikalische Größe, die den Zustand widerspiegelt:

• Schwingungen an Motoren, Pumpen, Ventilatoren und Getrieben
• Lager- und Wicklungstemperatur
• Motorstrom und Leistung
• Ölqualität, Druck und Durchfluss
• Schallemission und Ultraschall

Jeder Messwert wird mit einem Grenzwert verglichen. Wird der Grenzwert überschritten, wird jemand informiert. Das klingt einfach und ist es auch, und genau deshalb liefert es schnell Nutzen. Ein Schwingungssensor mit einem sinnvollen, auf die Baseline bezogenen Alarm erkennt einen lockeren Maschinenfuß oder ein ausfallendes Lager Tage oder Wochen, bevor es festfrisst. Das Tutorial zum Sensor für die Schwingungsüberwachung zeigt, wie Sie einen bauen.

Datenfluss des Condition Monitoring mit MQTT

Der Fluss ist kurz: Sensor zum Broker zur Alarmlogik zu den Menschen.

sensor/gateway --publish--> acme/plant1/press/line2/hydpump1/condition
                                    |
                     MQTT broker (e.g. ConnectMQ)
                         |                    |
             threshold alert rule      dashboard / topic explorer
                         |
             acme/plant1/press/line2/hydpump1/alert  (retained)

Die Topic-Struktur folgt der ISA-95-Hierarchie (Unternehmen → Werk → Bereich → Linie → Anlage) und bildet damit den Unified Namespace (UNS), in dem Zustandsdaten, Alarme und später auch Prognosen jeder Anlage an einem eindeutigen Ort liegen. Eine typische Payload enthält nur aktuelle Werte und Einheiten:

{
  "ts": "2026-10-16T08:15:00Z",
  "vib_rms_mm_s": 3.1,
  "bearing_temp_c": 58.4,
  "current_a": 21.7
}

Bei ConnectMQ können die Schwellenwert-Alarmregeln im Portal solche Felder überwachen und jede Überschreitung im Alarmprotokoll festhalten, was für ein erstes Pilotprojekt oft genügt. Feinere Logik, etwa auf die Baseline bezogene Grenzwerte oder die Anforderung mehrerer aufeinanderfolgender Verletzungen, gehört in einen kleinen Subscriber-Dienst.

Was Predictive Maintenance hinzufügt

Predictive Maintenance stellt eine schwierigere Frage: Wann erreicht dieses Signal, so wie es sich bisher entwickelt hat, den Punkt, an dem wir handeln müssen? Die Antwort erfordert drei Dinge, die Condition Monitoring nicht braucht:

1. Historie. Wochen oder Monate an Messwerten pro Anlage, gespeichert in einer Zeitreihendatenbank.
2. Ausfallwissen. Aufzeichnungen darüber, was wann ausgefallen ist und wie die Signale vorher aussahen. Ohne diese hat ein Modell nichts, woraus es lernen kann.
3. Ein Modell. Alles von einer linearen Trendextrapolation über eine physikbasierte Degradationskurve bis zu einem trainierten Machine-Learning-Modell. Der Artikel Predictive Maintenance mit Machine Learning behandelt die Data-Science-Seite.

Das Ergebnis ist kein Alarm, sondern eine Prognose: „Die Lagerschwingung von Pumpe 1 steigt um etwa 0,1 mm/s pro Tag und überschreitet den Alarmgrenzwert in rund 12 Tagen.“ Die Arbeitsvorbereitung kann den Lagerwechsel dann in einen bestehenden Stillstand einplanen, statt eine Schicht durch einen ungeplanten Ausfall zu verlieren.

Datenfluss der Predictive Maintenance mit MQTT

Der Broker bleibt das Transportmittel, doch es docken mehr Abnehmer an:

sensors/gateways --> MQTT broker --> historian subscriber --> time-series DB
                          |                                       |
                          |                              model / trend job
                          |                                       |
                          <------ publish prediction -------------+
                  acme/plant1/press/line2/hydpump1/prediction  (retained)
                          |
                 CMMS integration / planner dashboard

Die Prognose wird als retained Message an den Broker zurückveröffentlicht, sodass jedes Dashboard oder Instandhaltungssystem, das abonniert, sofort die neueste Vorhersage erhält:

{
  "ts": "2026-10-16T09:00:00Z",
  "signal": "vib_rms_mm_s",
  "current": 3.1,
  "alarm_limit": 4.5,
  "slope_per_day": 0.11,
  "days_to_limit": 12.7,
  "confidence": "medium"
}

Ein minimaler Schritt von der Überwachung zur Prognose

Für den ersten prädiktiven Schritt brauchen Sie kein Machine Learning. Eine gleitende lineare Regression auf einem Tagesaggregat liefert bereits eine brauchbare Schätzung der „Tage bis zum Grenzwert“. Der folgende Python-Job liest Tageswerte (aus Ihrem Historian, hier der Übersicht halber eine Liste) und veröffentlicht die Prognose mit paho-mqtt 2.x an den öffentlichen MQTT-Broker.

import json
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

ALARM_LIMIT = 4.5
TOPIC = "connectmq/demo/4c81d2/press/hydpump1/prediction"

# Tagesmedian der Schwingung (RMS) in mm/s, älteste zuerst (normalerweise aus dem Historian abgefragt)
daily = [2.1, 2.1, 2.2, 2.2, 2.3, 2.3, 2.5, 2.5, 2.6, 2.8, 2.8, 2.9, 3.0, 3.1]

def linear_fit(values):
    n = len(values)
    xs = range(n)
    mx, my = (n - 1) / 2, sum(values) / n
    sxx = sum((x - mx) ** 2 for x in xs)
    sxy = sum((x - mx) * (y - my) for x, y in zip(xs, values))
    slope = sxy / sxx
    return slope, my - slope * mx

slope, intercept = linear_fit(daily[-14:])
current = daily[-1]
days_to_limit = (ALARM_LIMIT - current) / slope if slope > 0 else None

forecast = {
    "ts": datetime.now(timezone.utc).isoformat(timespec="seconds"),
    "signal": "vib_rms_mm_s",
    "current": current,
    "alarm_limit": ALARM_LIMIT,
    "slope_per_day": round(slope, 3),
    "days_to_limit": round(days_to_limit, 1) if days_to_limit else None,
}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-job-4c81d2")
client.connect("broker.connectmq.com", 1883)
client.loop_start()
client.publish(TOPIC, json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print(forecast)

Das ist bewusst einfach gehalten. Es nimmt an, dass die Degradation über die letzten zwei Wochen ungefähr linear verläuft, was für sich langsam entwickelnde Fehler oft ausreicht und für plötzliche nutzlos ist. Diese Einschränkung ist die ehrliche Zusammenfassung von Predictive Maintenance im Allgemeinen: Sie verlängert die Vorwarnzeit bei schleichenden Ausfällen, während Condition Monitoring weiterhin die abrupten erkennen muss.

Der Reifegradpfad der Instandhaltung

Die meisten Werke durchlaufen diese Stufen der Reihe nach. Das Überspringen von Stufen ist der häufigste Grund, warum prädiktive Projekte ins Stocken geraten.

1. Reaktiv. Betrieb bis zum Ausfall. Keine Daten.
2. Präventiv. Zeit- oder zählerbasierte Aufgaben. Die Daten liegen als Arbeitsaufträge im CMMS.
3. Vernetzt. Maschinen veröffentlichen grundlegende Zustände und Zähler. Hier entsteht meist ein MQTT-Backbone, oft zuerst für die Erfassung von Maschinenstillständen.
4. Condition Monitoring. Zustandssignale an kritischen Anlagen mit Alarmen. Der Nutzen stellt sich innerhalb von Wochen ein.
5. Zustandsorientierte Instandhaltung. Für die überwachten Anlagen werden Arbeitsaufträge durch Zustandsalarme statt durch den Kalender ausgelöst.
6. Predictive Maintenance. Ergebnisse von Trends und Modellen planen Arbeiten, bevor Grenzwerte überschritten werden.
7. Präskriptiv. Das System empfiehlt zusätzlich Maßnahme und besten Zeitpunkt unter Berücksichtigung von Produktionsplänen und Ersatzteilen.

Messen Sie den Fortschritt mit Zuverlässigkeitskennzahlen statt mit der Zahl installierter Sensoren. Die MTBF- und MTTR-Berechnung liefert eine Ausgangsbasis vor dem Start und einen Weg, die Verbesserung danach nachzuweisen.

Wo investieren?

Beginnen Sie mit Condition Monitoring, wenn:

• Sie kritische Anlagen ganz ohne Zustandsdaten haben.
• Ausfälle teuer sind, Sie aber wenige historische Ausfallaufzeichnungen besitzen.
• Sie innerhalb eines Quartals sichtbare Ergebnisse brauchen.

Investieren Sie in Predictive Maintenance, wenn:

• Zustandsdaten seit Monaten konsistent an denselben Anlagen erfasst werden.
• Sie dokumentierte Ausfälle mit passender Sensorhistorie haben.
• Planungsspielraum vorhanden ist, eine frühere Warnung also tatsächlich ändern würde, wann gearbeitet wird.

In beiden Fällen ist die Infrastrukturentscheidung dieselbe: Bringen Sie die Signale einmal auf ein zuverlässiges, sauber benanntes MQTT-Backbone und lassen Sie Überwachung, Historians und Modelle unabhängig voneinander abonnieren. Ein Cloud-MQTT-Broker macht dieses Backbone aus dem Werk, für ein Datenteam an einem anderen Standort und vom Laptop der Arbeitsvorbereitung aus erreichbar, ohne individuelle Punkt-zu-Punkt-Integrationen. Der Smart-Manufacturing-Leitfaden beschreibt dieses Backbone und die ISA-95-Topic-Struktur im Detail.

Häufige Fallstricke

1. Prognose vor Überwachung kaufen. Ein Modell, das mit wenigen Wochen Daten ohne aufgezeichnete Ausfälle trainiert wurde, sagt nichts Brauchbares voraus.
2. Feste Schwellenwerte aus Katalogen. Jede Maschine hat ihr eigenes Normal. Lernen Sie Baselines pro Anlage.
3. Keine Rückmeldeschleife. Techniker müssen festhalten, was sie bei der Reaktion auf einen Alarm vorgefunden haben, sonst können Sie die Logik nie validieren oder verbessern.
4. Datensilos. Wenn Schwingungssystem, CMMS und Historian die Daten der jeweils anderen nicht sehen, bleibt die Prognose eine Folie in einer Präsentation.
5. Plötzliche Ausfälle ignorieren. Prognosen helfen bei schleichendem Verschleiß. Behalten Sie für alles andere schnelle Zustandsalarme bei.

Bauen Sie Ihr Überwachungs-Backbone auf ConnectMQ

ConnectMQ ist ein vollständig verwalteter MQTT-Broker mit MQTT 5, TLS, retained Messages, einem Live-Topic-Explorer und integrierten Schwellenwert-Alarmregeln. So können Sie heute mit Condition Monitoring starten und Historians und Prognose-Jobs später als gewöhnliche MQTT-Clients anbinden. Erstellen Sie unter app.connectmq.com einen Broker im kostenlosen Serverless-Plan, ganz ohne Kreditkarte.

Häufig gestellte Fragen

Ist Condition Monitoring dasselbe wie Predictive Maintenance?

Nein. Condition Monitoring erkennt einen abnormalen Zustand im Hier und Jetzt, während Predictive Maintenance Zustandsdaten und Historie nutzt, um vorherzusagen, wann ein Eingriff nötig wird. Predictive Maintenance hängt von Condition Monitoring ab.

Was sollte ein Werk zuerst einführen?

Condition Monitoring. Es liefert schnell Nutzen und baut die Datenhistorie auf, die jeder prädiktive Ansatz später benötigt.

Brauche ich Machine Learning für Predictive Maintenance?

Nicht unbedingt. Eine Trendextrapolation auf gut gewählten Signalen liefert bei schleichenden Ausfällen bereits brauchbare Schätzungen der Zeit bis zum Grenzwert. Machine Learning hilft, wenn Sie eine umfangreiche Historie und viele aufgezeichnete Ausfälle haben.

Welche Rolle spielt MQTT bei beiden Ansätzen?

MQTT ist das Transportmittel, das Sensorwerte, Alarme und Prognosen zwischen Geräten, Dashboards, Historians und Instandhaltungssystemen bewegt. Ein Broker für alle vermeidet Punkt-zu-Punkt-Integrationen.