Restlebensdauer-Vorhersage (RUL) einfach erklärt

Die Restlebensdauer-Vorhersage schätzt, wie lange eine Komponente oder Maschine noch betrieben werden kann, bevor sie einen Ausfallzustand erreicht. Statt zu fragen „Stimmt etwas nicht?“, fragt sie „Wie viel Zeit bleibt uns?“ – genau die Frage, die Instandhaltungsplaner tatsächlich beantwortet haben möchten. Dieser Artikel erklärt die wichtigsten RUL-Modellfamilien, die Datenhistorie, die jede von MQTT-angebundenen Assets benötigt, und wie Sie eine Schätzung mit ehrlicher Unsicherheit berechnen und publizieren.

Was Restlebensdauer bedeutet

Die Restlebensdauer (Remaining Useful Life, RUL) ist die Zeit, Zyklenzahl oder Betriebsstundenzahl, die bleibt, bis ein Asset eine definierte Ausfallschwelle überschreitet. Drei Teile dieser Definition verdienen Aufmerksamkeit:

Die Einheit. Kalenderzeit ist leicht zu kommunizieren, aber irreführend, wenn die Nutzung schwankt. Betriebsstunden, Zyklen, Hübe oder produzierte Einheiten bilden den Verschleiß oft besser ab.
Die Ausfallschwelle. RUL braucht einen definierten Endpunkt: ein Schwingungsniveau, bei dem ein Lager getauscht wird, einen Druckabfall am Filter, ab dem der Durchfluss inakzeptabel wird, eine Kapazität, bei der eine Batterie ausgemustert wird. Ohne einen solchen Endpunkt gibt es nichts vorherzusagen.
Die Unsicherheit. Eine einzelne Zahl wie „212 Stunden“ verbirgt, wie sicher sich das Modell ist. Eine nützliche RUL-Schätzung kommt immer mit einer Spanne.

Die RUL-Vorhersage ist eine Formulierung von Predictive Maintenance mit Machine Learning. Sie eignet sich für Assets, die allmählich und wiederholbar degradieren, etwa Lager, Filter, Schneidwerkzeuge, Batterien, Riemen und Dichtungen, also genau die Verschleißteile, die in Werkzeugmaschinen, Pumpen und Lüftern im Maschinenbau ungeplante Stillstände verursachen. Für plötzliche Ausfälle wie Elektronikfehler eignet sie sich schlecht.

Modellfamilien für die Restlebensdauer-Vorhersage

Ansatz	Idee	Benötigte Daten	Stärke	Schwäche
Zuverlässigkeitsstatistik (Weibull)	Eine Lebensdauerverteilung aus vergangenen Ausfallzeiten anpassen	Nur Ausfall- und Austauschdaten	Keine Sensoren nötig	Ignoriert den Zustand dieser konkreten Einheit
Degradationstrend-Modelle	Einen Health-Indikator verfolgen und bis zu einer Schwelle extrapolieren	Zustandshistorie der aktuellen Einheit und eine Schwelle	Intuitiv, funktioniert mit wenigen Ausfällen	Setzt voraus, dass die Trendform gleich bleibt
Ähnlichkeitsbasierte Modelle	Den aktuellen Verlauf mit früheren Run-to-Failure-Verläufen vergleichen	Mehrere vollständige Run-to-Failure-Historien	Bildet realistische Verläufe ab	Braucht vergleichbare historische Einheiten
Direkte ML-Regression	RUL aus Features lernen (Gradient Boosting, LSTM, CNN)	Viele gelabelte Run-to-Failure-Historien	Kann komplexe Muster erfassen	Datenhungrig, schwerer zu erklären
Physikbasierte Modelle	Verschleißmechanismen modellieren (Risswachstum, thermische Alterung)	Ingenieurwissen, Materialparameter	Funktioniert, bevor Daten existieren	Pro Asset-Typ aufwendig zu erstellen

Die meisten praktischen Projekte beginnen mit einem Degradationstrend-Modell, weil es nur die Historie einer Einheit und eine Schwelle benötigt. Ähnlichkeits- und ML-Methoden kommen später, sobald die Organisation genügend vollständige Lebenszyklen aufgezeichnet hat.

Die Datenhistorie, die RUL-Modelle brauchen

Die RUL-Vorhersage stellt höhere Anforderungen an die Historie als die Anomalieerkennung. Planen Sie diese Datenströme von Anfang an ein, denn sie lassen sich später nicht rekonstruieren.

Zustandssignale über die gesamte Lebensdauer jeder Einheit, nicht nur die letzten Wochen. Features wie Schwingungs-RMS, Temperaturanstieg oder Druckabfall, konsistent abgetastet.
Nutzungszähler wie Betriebsstunden, Zyklen oder Durchsatz, damit RUL in der Einheit ausgedrückt werden kann, die den Verschleiß treibt.
Betriebskontext wie Last, Drehzahl und Umgebungstemperatur, um Degradation von wechselnden Bedingungen zu trennen.
Lebenszyklusereignisse: Einbau, Austausch, Reparatur und Ausfall, jeweils mit Zeitstempel und Seriennummer der Komponente. Diese definieren, wo ein Leben endet und das nächste beginnt.
Ausfalldefinitionen: welcher Zustand als Lebensende gilt, schriftlich festgehalten pro Komponententyp.

Über MQTT bedeutet das meist ein Zustands-Topic, ein Nutzungs-Topic und ein Events-Topic pro Asset, alle mit Quellzeitstempeln und von einem Historian-Subscriber gespeichert. Am besten liegen diese Topics in einem Unified Namespace (UNS), dessen Struktur der ISA-95-Hierarchie folgt (Enterprise → Site → Area → Line → Cell), etwa acme/werk-augsburg/lackiererei/linie-1/luefter-2/health. So findet jedes Modell, jedes Dashboard und das Instandhaltungsmodul im ERP die Daten eines Assets am gleichen, eindeutigen Ort, und eine neue Maschine fügt sich ohne Sonderlogik ein. Mehr dazu im Beitrag Sparkplug B und Unified Namespace. Der Leitfaden zum Labeln von Zeitreihen-Sensordaten zeigt, wie Sie Lebenszyklusereignisse und Bedienereingaben neben der Telemetrie erfassen, damit die Run-to-Failure-Aufzeichnungen vollständig sind.

Einen Health Index aufbauen

Die meisten RUL-Methoden arbeiten mit einem einzigen Health-Indikator statt mit vielen Rohsignalen. Ein Health Index (HI) fasst Features zu einer Zahl zusammen, die sich monoton ändert, während das Asset degradiert. Gängige Wege, ihn zu bilden:

Ein einzelnes physikalisch aussagekräftiges Feature verwenden, etwa Lagerschwingungs-RMS oder Filter-Differenzdruck.
Normalisierte Features mit von Ingenieuren gewählten Gewichten kombinieren.
Den Rekonstruktionsfehler eines auf gesunden Daten trainierten Modells verwenden.
Die erste Hauptkomponente der Features über Verläufe von gesund bis ausgefallen verwenden.

Gute Health Indizes haben drei Eigenschaften gemeinsam: Sie sind monoton (bewegen sich selten rückwärts), prognostizierbar (der Ausfall tritt bei einem konsistenten HI-Niveau ein) und zeigen früh genug einen Trend, um nützlich zu sein.

Ein Degradationstrend-Beispiel in Python

Das folgende Skript abonniert ein Health-Index-Topic, passt ein exponentielles Degradationsmodell an die jüngste Historie an, extrapoliert bis zu einer Ausfallschwelle, schätzt per Bootstrap ein Unsicherheitsband und publiziert die RUL zurück an MQTT. Ein eingebauter Simulator publiziert den Health Index, sodass Sie das Ganze durchgängig gegen den kostenlosen öffentlichen MQTT-Broker ausführen können.

import json
import math
import random
import threading
import time
import uuid

import numpy as np
import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1/fan2"
THRESHOLD = 4.0        # HI-Wert, der als Lebensende definiert ist (z. B. Schwingungs-RMS in mm/s)
MIN_POINTS = 30
history = []           # (Betriebsstunden, HI)


def fit_rul(hours, hi):
    # ln(hi - baseline) = a + b * t anpassen, dann nach dem Schwellwertdurchgang auflösen
    baseline = 0.9 * min(hi)
    y = np.log(np.maximum(np.array(hi) - baseline, 1e-6))
    b, a = np.polyfit(hours, y, 1)
    if b <= 0:
        return None
    t_fail = (math.log(THRESHOLD - baseline) - a) / b
    return t_fail - hours[-1]


def estimate():
    hours = np.array([h for h, _ in history[-120:]])
    hi = np.array([v for _, v in history[-120:]])
    point = fit_rul(hours, hi)
    if point is None:
        return None
    boots = []
    for _ in range(200):
        idx = np.sort(np.random.choice(len(hours), len(hours), replace=True))
        r = fit_rul(hours[idx], hi[idx])
        if r is not None:
            boots.append(r)
    low, high = np.percentile(boots, [10, 90])
    return {"rul_h": round(point, 1), "p10_h": round(low, 1), "p90_h": round(high, 1)}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/health", qos=1)


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    history.append((p["op_hours"], p["hi"]))
    if len(history) >= MIN_POINTS:
        est = estimate()
        if est:
            est.update({"ts": p["ts"], "threshold": THRESHOLD, "method": "exp-trend-v1"})
            client.publish(f"{BASE}/rul", json.dumps(est), qos=1, retain=True)
            print(est)


def simulate(pub):
    for step in range(400):
        hours = step * 5.0
        hi = 1.0 + 0.05 * math.exp(hours / 600) + random.gauss(0, 0.04)
        body = {"ts": int(time.time() * 1000), "op_hours": hours, "hi": round(hi, 3)}
        pub.publish(f"{BASE}/health", json.dumps(body), qos=0)
        time.sleep(0.5)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="rul-" + uuid.uuid4().hex[:8])
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
threading.Thread(target=simulate, args=(client,), daemon=True).start()
client.loop_forever()

Installieren Sie die Abhängigkeiten mit pip install paho-mqtt numpy. Zu Beginn des Laufs ist das Band zwischen p10_h und p90_h breit; sobald der Health Index nach oben abknickt, stabilisiert sich die Schätzung und das Band wird schmaler. Dieses Verhalten ist normal und wichtig zu kommunizieren: RUL-Schätzungen werden erst dann vertrauenswürdig, wenn die Degradation deutlich sichtbar ist.

RUL-Schätzungen publizieren, die andere nutzen können

Publizieren Sie die Schätzung als Retained Message auf einem eigenen Topic pro Asset, etwa .../fan2/rul, also direkt neben den Zustandsdaten des Assets im UNS, damit Dashboards, MES- und CMMS-Connectoren beim Abonnieren sofort den aktuellen Wert erhalten. Geben Sie Methode und Version, die verwendete Schwelle und die Unsicherheitsspanne mit an. Im ConnectMQ-Portal können Sie das Topic im Live-Topic-Explorer beobachten und eine Schwellwert-Alarmregel hinzufügen, zum Beispiel wenn p10_h unter ein Planungsfenster fällt, sodass die untere Grenze statt der Punktschätzung den Alarm auslöst.

Häufige Fehler in RUL-Projekten

Kalendertage für nutzungsgetriebenen Verschleiß vorhersagen. Rechnen Sie zuerst in Betriebsstunden oder Zyklen um.
Lebenszyklen vermischen. Wird ein Komponententausch nicht erfasst, verschmelzen zwei Lebenszyklen zu einem verwirrenden Verlauf.
Unsicherheit ignorieren. Ein Planer, der nur eine Punktschätzung sieht, wird ihr entweder zu sehr vertrauen oder sie ignorieren.
ML-Modelle mit einer Handvoll Ausfälle trainieren. Beginnen Sie mit Trend- oder Ähnlichkeitsmodellen und steigen Sie auf ML um, wenn die Historie es erlaubt.
Regimewechsel vergessen. Laständerungen können den Health Index ohne jede Degradation verschieben; normalisieren Sie nach Betriebskontext.

Wo RUL in Ihren Stack passt

Die RUL-Schätzung setzt auf zuverlässigen Zustandsdaten auf, die wiederum von einer stabilen Messaging-Schicht abhängen. ConnectMQ stellt diese Schicht als verwalteter MQTT-Broker bereit, während die Modelle als Ihre eigenen Clients laufen. Prognoseverfahren, die die Trendextrapolation ergänzen, finden Sie unter IoT-Zeitreihenprognose, und das Gesamtbild von Modellen im Zusammenspiel mit vernetzten Geräten im Leitfaden zu KI und IoT.

Beginnen Sie mit der Erfassung von Lebenszyklusdaten auf ConnectMQ

RUL-Modelle sind nur so gut wie die Historie dahinter, daher ist jetzt der beste Zeitpunkt, mit der Aufzeichnung zu beginnen. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, verbinden Sie Ihre Assets mit dem generierten Benutzernamen, Passwort und der Client ID und beginnen Sie, Zustands-, Nutzungs- und Lebenszyklusereignisse über einen Historian-Subscriber zu speichern. Wenn Ihre Flotte wächst, bietet Ihnen ein Cloud-MQTT-Broker-Plan mehr Verbindungen und Isolation, ohne dass sich Ihre Topics ändern.

Häufig gestellte Fragen

Was ist eine Restlebensdauer-Vorhersage?

Sie ist die Schätzung, wie viel Betriebszeit, Zyklen oder Nutzung einem Asset bleibt, bevor es einen definierten Ausfallzustand erreicht, meist auf Basis seiner Zustandsdaten und des Verhaltens ähnlicher Assets.

Wie viele Ausfälle brauche ich, um die RUL vorherzusagen?

Degradationstrend-Modelle können mit der Historie einer einzigen Einheit und einer technischen Schwelle arbeiten. Ähnlichkeitsbasierte und Machine-Learning-Modelle brauchen mehrere bis viele vollständige Run-to-Failure-Historien pro Komponententyp.

Warum schwankt die RUL-Schätzung am Anfang so stark?

Bevor die Degradation sichtbar wird, dominiert Rauschen den Trend, und die Extrapolation ist instabil. Geben Sie eine Unsicherheitsspanne an und verlassen Sie sich auf die Schätzung, sobald sich die Spanne verengt.

Sollte die RUL in Tagen oder Betriebsstunden angegeben werden?

Verwenden Sie die Einheit, die den Verschleiß treibt, typischerweise Betriebsstunden, Zyklen oder Durchsatz, und rechnen Sie nur für die Planung anhand der erwarteten Auslastung in Kalenderdaten um.