MTBF und MTTR berechnen: Formeln, Beispiele und automatische Erfassung mit MQTT

MTBF und MTTR zu berechnen ist die Grundlage jeder Zuverlässigkeitsdiskussion im Werk: Wie oft fällt diese Maschine aus, und wie lange brauchen wir, bis sie wieder läuft? Dieser Leitfaden erklärt beide Formeln, rechnet ein vollständiges Beispiel durch, zeigt die Definitionsfallen, die Kennzahlen unvergleichbar machen, und beschreibt, wie Sie die Werte automatisch aus Ausfall- und Reparaturereignissen berechnen, die per MQTT erfasst werden.

Was MTBF und MTTR messen

MTBF (Mean Time Between Failures, mittlere Betriebsdauer zwischen Ausfällen) ist die durchschnittliche Betriebszeit zwischen einem Ausfall und dem nächsten bei einer reparierbaren Anlage. Höher ist besser. Sie beschreibt die Zuverlässigkeit: wie lange die Maschine typischerweise läuft, bevor etwas kaputtgeht.

MTTR (Mean Time To Repair, mittlere Reparaturdauer) ist die durchschnittliche Zeit vom Moment, in dem ein Ausfall die Maschine stoppt, bis zur Wiederinbetriebnahme. Niedriger ist besser. Sie beschreibt die Instandhaltbarkeit und die Wirksamkeit Ihrer Reaktion: Erkennung, Anfahrt, Diagnose, Warten auf Ersatzteile, Reparatur und Test.

Gemeinsam bestimmen sie, wie viel der Zeit eine Maschine verfügbar ist, und sie verweisen auf unterschiedliche Verbesserungshebel. Eine niedrige MTBF verlangt nach einer besseren Instandhaltungsstrategie, konstruktiven Änderungen oder Zustandsüberwachung. Eine hohe MTTR verlangt nach schnellerer Erkennung, besserem Ersatzteilmanagement, klareren Abläufen und Schulung.

Die Formeln

Betriebszeit bedeutet die Zeit, in der die Anlage laufen sollte und tatsächlich lief. Sie schließt geplante Stillstände wie Wochenenden, geplante Wartung und Rüstvorgänge aus, ebenso die ausfallbedingte Stillstandszeit selbst. Bei diesem Nenner gehen die meisten Berechnungen schief.

Durchgerechnetes Beispiel: MTBF und MTTR berechnen

Nehmen wir eine Verpackungsmaschine über einen Zeitraum von vier Wochen. Sie ist für zwei Schichten zu je 8 Stunden an fünf Tagen pro Woche eingeplant, das ergibt 20 Tage x 16 Stunden = 320 geplante Stunden. In diesem Zeitraum treten vier Ausfälle auf:

Schritt für Schritt:

1. Gesamte ausfallbedingte Stillstandszeit = 0,5 + 3,0 + 1,0 + 1,5 = 6,0 Stunden.
2. Betriebszeit = 320 geplante Stunden - 6,0 Stunden ausfallbedingter Stillstand = 314 Stunden.
3. MTBF = 314 / 4 = 78,5 Stunden.
4. MTTR = 6,0 / 4 = 1,5 Stunden.
5. Inhärente Verfügbarkeit = 78,5 / (78,5 + 1,5) = 98,1 Prozent.
6. Ausfallrate = 4 / 314 = etwa 0,0127 Ausfälle pro Betriebsstunde.

Dieselben Daten zeigen auch, wo Sie ansetzen sollten. Zwei der vier Ausfälle waren Staus im Einlauf, eine einzige Maßnahme dort könnte die Ausfallzahl also halbieren. Der Riemenausfall dominiert dagegen die MTTR und legt nahe zu prüfen, ob Ersatzriemen an der Linie vorrätig sind.

Definitionsfallen, die Sie vermeiden sollten

Kennzahlen sind nur nützlich, wenn alle sie gleich berechnen. Vereinbaren Sie diese Regeln, bevor Sie die erste Zahl veröffentlichen:

1. Was als Ausfall zählt. Eine gängige Regel ist jeder ungeplante Stopp über einer Schwelle, zum Beispiel fünf Minuten, der einen Eingriff erfordert. Kurzstopps unter der Schwelle gehören zum Leistungsverlust, nicht zur MTBF. Halten Sie die Schwelle schriftlich fest.
2. Betriebszeit statt Kalenderzeit. Kalenderstunden blähen die MTBF bei Maschinen auf, die nur in einer Schicht laufen. Verwenden Sie die geplante Laufzeit abzüglich der ausfallbedingten Stillstandszeit.
3. Wo die MTTR beginnt und endet. Beginnen Sie in dem Moment, in dem die Maschine stoppte, nicht wenn der Techniker eintraf. Enden Sie, wenn die Maschine wieder an die Produktion übergeben wird, nicht wenn der Auftrag im Büro geschlossen wird. Die Reaktionszeit ist Teil des Problems, das Sie messen wollen.
4. MTBF vs. MTTF. Die MTTF (Mean Time To Failure) gilt für nicht reparierbare Teile wie eine Glühbirne oder ein gekapseltes Lager. Für Maschinen, die Sie reparieren, verwenden Sie die MTBF.
5. Kleine Stichproben. Bei zwei Ausfällen pro Jahr schwankt die MTBF stark. Geben Sie sie zusammen mit der Anzahl der Ausfälle an und verwenden Sie bei sehr zuverlässigen Anlagen längere Zeitfenster.
6. MTBF ist keine Lebensdauer. Eine MTBF von 1.000 Stunden bedeutet nicht, dass die Maschine 1.000 Stunden läuft und dann ausfällt. Es ist eine mittlere Rate; Ausfälle können und werden auch früh auftreten.

Warum manuelle Erfassung scheitert

In vielen Werken werden MTBF und MTTR einmal im Monat aus den Aufträgen im CMMS berechnet. Das bringt drei Probleme mit sich. Aufträge werden verspätet angelegt, der erfasste Ausfallbeginn ist also falsch. Kurze Ausfälle, die das Bedienpersonal selbst behebt, bekommen nie einen Auftrag, die Ausfallzahlen sind also zu niedrig. Und wenn der Monatsbericht eintrifft, ist das Muster hinter den Ausfällen bereits Wochen alt.

Ausfall- und Reparaturereignisse direkt an der Maschine und bei den Menschen zu erfassen, die sie beheben, löst alle drei Probleme. Die Maschine weiß genau, wann sie stoppte und wieder anlief. Ein Bedienpanel, ein digitales Andon-System oder das Smartphone eines Technikers kann die Ursache ergänzen. MQTT ist ein natürlicher Transport für diese Ereignisse, weil dieselben Ereignisse auch die Stillstandserfassung und OEE-Dashboards speisen.

Ereignisdesign für die automatische Erfassung

Verwenden Sie ein Topic pro Anlage für Instandhaltungsereignisse und eine kleine Menge von Ereignistypen:

acme/plant1/packaging/line2/cartoner1/maintenance/event

{"event": "failure_start", "ts": "2026-10-16T08:12:40Z", "reason": "infeed_jam", "id": "f-0193"}
{"event": "repair_end", "ts": "2026-10-16T08:41:05Z", "id": "f-0193", "technician": "T07"}
{"event": "planned_stop_start", "ts": "2026-10-16T14:00:00Z"}
{"event": "planned_stop_end", "ts": "2026-10-16T14:30:00Z"}

Der Topic-Pfad folgt der ISA-95-Hierarchie (Enterprise, Site, Area, Line, Cell) und fügt sich damit direkt in einen Unified Namespace (UNS) ein, in dem Instandhaltungsereignisse neben Maschinenzuständen und Stückzahlen derselben Anlage liegen. Publizieren Sie diese Ereignisse mit QoS 1, damit sie mindestens einmal zugestellt werden, und geben Sie jedem Ausfall eine ID, damit eine doppelte Zustellung nicht zweimal zählt. Wie der Leitfaden zu den MQTT-QoS-Stufen erklärt, ist QoS 1 für solche Ereignisdaten der richtige Kompromiss.

MTBF und MTTR aus MQTT-Ereignissen berechnen

Der folgende Python-Dienst abonniert die Instandhaltungsereignisse aller Anlagen unter einem Präfix, speichert sie in SQLite und berechnet jede Minute MTBF und MTTR über ein gleitendes 30-Tage-Fenster neu. Die Ergebnisse publiziert er als retained messages, sodass jedes Dashboard die aktuellen Werte sieht, sobald es abonniert. Er nutzt paho-mqtt 2.x und den Öffentlichen MQTT-Broker von ConnectMQ; ersetzen Sie das Präfix durch Ihr eigenes.

import json
import sqlite3
import time
from datetime import datetime, timedelta, timezone
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/d27e5b"
WINDOW_DAYS = 30
db = sqlite3.connect("maintenance.db", check_same_thread=False)
db.execute("""CREATE TABLE IF NOT EXISTS events (
    asset TEXT, event TEXT, ts TEXT, fid TEXT,
    UNIQUE(asset, event, ts))""")

def parse(ts):
    return datetime.fromisoformat(ts.replace("Z", "+00:00"))

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/maintenance/event", qos=1)

def on_message(client, userdata, msg):
    asset = msg.topic.split("/")[3]
    e = json.loads(msg.payload)
    db.execute("INSERT OR IGNORE INTO events VALUES (?,?,?,?)",
               (asset, e["event"], e["ts"], e.get("id")))
    db.commit()

def metrics(asset, now):
    start = now - timedelta(days=WINDOW_DAYS)
    rows = db.execute("SELECT event, ts FROM events WHERE asset=? ORDER BY ts", (asset,)).fetchall()
    failures, repair_s, planned_s = 0, 0.0, 0.0
    open_fail = open_plan = None
    for event, ts in rows:
        t = max(parse(ts), start)
        if event == "failure_start":
            open_fail = t
            if parse(ts) >= start:
                failures += 1
        elif event == "repair_end" and open_fail:
            repair_s += (t - open_fail).total_seconds()
            open_fail = None
        elif event == "planned_stop_start":
            open_plan = t
        elif event == "planned_stop_end" and open_plan:
            planned_s += (t - open_plan).total_seconds()
            open_plan = None
    if open_fail:
        repair_s += (now - open_fail).total_seconds()
    operating_h = (WINDOW_DAYS * 86400 - planned_s - repair_s) / 3600
    mtbf = operating_h / failures if failures else None
    mttr = repair_s / 3600 / failures if failures else None
    avail = mtbf / (mtbf + mttr) if failures else 1.0
    return {"window_days": WINDOW_DAYS, "failures": failures,
            "operating_h": round(operating_h, 1),
            "mtbf_h": round(mtbf, 1) if mtbf else None,
            "mttr_h": round(mttr, 2) if mttr else None,
            "inherent_availability": round(avail, 4)}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="reliability-d27e5b")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

while True:
    time.sleep(60)
    now = datetime.now(timezone.utc)
    for (asset,) in db.execute("SELECT DISTINCT asset FROM events").fetchall():
        result = metrics(asset, now)
        client.publish(f"{PREFIX}/{asset}/maintenance/kpi", json.dumps(result), qos=1, retain=True)
        print(asset, result)

Simulieren Sie einen Ausfall über die Kommandozeile und beobachten Sie, wie sich die Kennzahl innerhalb einer Minute aktualisiert:

mosquitto_pub -h broker.connectmq.com -p 1883 -i sim-d27e5b -q 1 \
  -t "connectmq/demo/d27e5b/cartoner1/maintenance/event" \
  -m '{"event":"failure_start","ts":"2026-10-16T08:12:40Z","id":"f-0001"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i sim-d27e5b -q 1 \
  -t "connectmq/demo/d27e5b/cartoner1/maintenance/event" \
  -m '{"event":"repair_end","ts":"2026-10-16T08:41:05Z","id":"f-0001"}'

Dieses Beispiel behandelt alle Zeit außerhalb geplanter Stopps und Reparaturen als Betriebszeit, was für durchgehend laufende Anlagen passt. Bei Maschinen, die nur in einigen Schichten laufen, publizieren Sie planned_stop_start und planned_stop_end für produktionsfreie Zeiten oder speisen den Schichtkalender aus Ihrem MES ein. Der Broker transportiert nur Ereignisse; die SQLite-Datei (oder Ihr Historian) ist das führende System, denn ein Broker ist keine Datenbank. Der öffentliche MQTT-Broker ist nur für Tests gedacht. In Produktion richten Sie den Dienst auf Ihren privaten ConnectMQ-Broker mit dem im Portal generierten Benutzernamen, Passwort und der Client-ID aus und verwenden TLS auf Port 8883.

Die Zahlen nutzen

• Anlagen zuerst nach Ausfallzahl ordnen, dann nach MTTR. Die Anlage mit vielen kurzen Ausfällen braucht eine Zuverlässigkeitsmaßnahme; die mit wenigen langen Ausfällen eine Maßnahme zur Instandhaltbarkeit.
• Nach Ursachencode aufschlüsseln. Die MTBF je Ausfallursache zeigt, welche Maßnahmen die Kennzahl am stärksten bewegen würden.
• Trends verfolgen, nicht Momentaufnahmen. Eine gleitende MTBF über 30 oder 90 Tage, die nach Einführung der Zustandsüberwachung steigt, ist der klarste Beleg, dass sich Investitionen in Zustandsüberwachung vs. Predictive Maintenance auszahlen.
• Die Bestandteile der MTTR beobachten. Ist die Erkennung langsam, ergänzen Sie Alarme; dauern Ersatzteile zu lange, überprüfen Sie die Bevorratung; ist die Diagnose langsam, verbessern Sie die Abläufe.

Für das größere Bild der Werkskennzahlen und wie Zuverlässigkeit mit OEE zusammenhängt, siehe den Leitfaden zu Smart Manufacturing.

Zuverlässigkeitskennzahlen mit ConnectMQ erfassen

ConnectMQ ist ein verwalteter MQTT-Broker mit MQTT 5, QoS 1 und 2, retained messages, TLS und einem Live-Topic-Explorer, sodass Ausfallereignisse, Reparaturereignisse und berechnete Kennzahlen über ein einziges privates Rückgrat fließen. Erstellen Sie Ihren Broker im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, oder testen Sie zuerst auf dem Öffentlichen MQTT-Broker.

Häufig gestellte Fragen

Wie berechnet man die MTBF?

Teilen Sie die gesamte Betriebszeit durch die Anzahl der Ausfälle im selben Zeitraum. Die Betriebszeit schließt geplante Stillstände und die durch die Ausfälle selbst verursachte Stillstandszeit aus.

Wie berechnet man die MTTR?

Teilen Sie die gesamte Zeit für die Wiederherstellung ausgefallener Anlagen durch die Anzahl der Reparaturen. Messen Sie vom Moment des Maschinenstopps bis zur Übergabe zurück an die Produktion.

Wie hängen MTBF, MTTR und Verfügbarkeit zusammen?

Die inhärente Verfügbarkeit ist die MTBF geteilt durch die Summe aus MTBF und MTTR. Eine höhere MTBF und eine niedrigere MTTR verbessern beide die Verfügbarkeit.

Was ist der Unterschied zwischen MTBF und MTTF?

Die MTBF gilt für reparierbare Anlagen, die nach einem Ausfall wieder in Betrieb gehen. Die MTTF gilt für nicht reparierbare Teile, die bei einem Ausfall ersetzt werden.