MTBF ve MTTR Hesaplama: Formüller, Örnekler ve MQTT ile Otomatik Takip

MTBF MTTR hesaplama, bir fabrikadaki her güvenilirlik konuşmasının temelidir: Bu makine ne sıklıkla arızalanıyor ve onu yeniden çalışır hale getirmek ne kadar sürüyor? Bu rehber her iki formülü açıklıyor, eksiksiz bir örneği adım adım çözüyor, sayıları karşılaştırılamaz hale getiren tanım tuzaklarını vurguluyor ve metriklerin MQTT üzerinden yakalanan arıza ve onarım olaylarından otomatik olarak nasıl hesaplanacağını gösteriyor.

MTBF ve MTTR Neyi Ölçer?

MTBF (Mean Time Between Failures, Arızalar Arası Ortalama Süre), onarılabilir bir varlık için bir arızayla bir sonraki arıza arasındaki ortalama çalışma süresidir. Yüksek olması daha iyidir. Güvenilirliği tanımlar: makinenin bir şey bozulmadan önce tipik olarak ne kadar çalıştığını.

MTTR (Mean Time To Repair, Ortalama Onarım Süresi), bir arızanın makineyi durdurduğu andan makinenin yeniden hizmete alınmasına kadar geçen ortalama süredir. Düşük olması daha iyidir. Bakım yapılabilirliği ve müdahalenizin etkinliğini tanımlar: tespit, sahaya ulaşma, teşhis, parça bekleme, onarım ve test.

Birlikte, bir makinenin zamanın ne kadarında kullanılabilir olduğunu belirlerler ve farklı iyileştirme kaldıraçlarına işaret ederler. Düşük MTBF daha iyi bir bakım stratejisi, tasarım değişiklikleri ya da durum izleme gerektirir. Yüksek MTTR ise daha hızlı tespit, daha iyi yedek parça yönetimi, daha net prosedürler ve eğitim gerektirir.

Formüller

Çalışma süresi, varlığın çalışması gereken ve gerçekten çalıştığı süre demektir. Hafta sonları, planlı bakım ve ürün değişimleri gibi planlı duruşları ve arıza duruşunun kendisini hariç tutar. Hesaplamaların çoğu bu paydayı doğru belirlemede hata yapar.

Adım Adım MTBF MTTR Hesaplama Örneği

Dört haftalık bir dönem boyunca bir paketleme makinesini ele alalım. Makine haftada beş gün, 8 saatlik iki vardiya için planlanmıştır; bu da 20 gün x 16 saat = 320 planlı saat eder. Bu dönemde dört arıza kaydedilir:

Adım adım:

1. Arızalardan kaynaklanan toplam duruş = 0,5 + 3,0 + 1,0 + 1,5 = 6,0 saat.
2. Çalışma süresi = 320 planlı saat - 6,0 saat arıza duruşu = 314 saat.
3. MTBF = 314 / 4 = 78,5 saat.
4. MTTR = 6,0 / 4 = 1,5 saat.
5. İçsel kullanılabilirlik = 78,5 / (78,5 + 1,5) = yüzde 98,1.
6. Arıza oranı = 4 / 314 = çalışma saati başına yaklaşık 0,0127 arıza.

Aynı veri nereye bakmanız gerektiğini de söyler. Dört arızanın ikisi besleme sıkışmasıydı; yani oradaki tek bir düzeltme arıza sayısını yarıya indirebilir. Kayış arızası ise MTTR'ye hakimdir ve hatta yedek kayış bulundurulup bulundurulmadığının kontrol edilmesi gerektiğini gösterir.

Kaçınılması Gereken Tanım Tuzakları

Metrikler ancak herkes onları aynı şekilde hesaplarsa faydalıdır. Tek bir sayı yayınlamadan önce bu kurallar üzerinde anlaşın:

1. Neyin arıza sayılacağı. Yaygın bir kural, müdahale gerektiren ve belirli bir eşikten, örneğin beş dakikadan uzun süren her plansız duruştur. Eşiğin altındaki mikro duruşlar MTBF'ye değil, performans kaybına aittir. Eşiği yazılı hale getirin.
2. Çalışma süresi ve takvim süresi. Takvim saatlerini kullanmak, yalnızca tek vardiya çalışan makinelerin MTBF'sini şişirir. Planlı çalışma süresinden arıza duruşunu çıkarın.
3. MTTR'nin nerede başlayıp bittiği. Teknisyenin geldiği andan değil, makinenin durduğu andan başlatın. İş emrinin ofiste kapatıldığı anda değil, makinenin üretime geri teslim edildiği anda bitirin. Müdahale süresi, ölçmeye çalıştığınız sorunun bir parçasıdır.
4. MTBF ve MTTF. MTTF (Mean Time To Failure, Arızaya Kadar Ortalama Süre), bir ampul ya da kapalı bir rulman gibi onarılamayan parçalar için geçerlidir. Onardığınız makineler için MTBF kullanın.
5. Küçük örneklemler. Yılda iki arızayla MTBF çılgınca dalgalanır. Onu arıza sayısıyla birlikte raporlayın ve çok güvenilir varlıklar için daha uzun pencereler kullanın.
6. MTBF bir ömür değildir. 1.000 saatlik bir MTBF, makinenin 1.000 saat çalışıp sonra bozulacağı anlamına gelmez. Bu bir ortalama orandır; arızalar erken de olabilir ve olur.

Manuel Takip Neden Başarısız Olur?

Birçok fabrikada MTBF ve MTTR, ayda bir kez CMMS iş emirlerinden hesaplanır. Bu üç sorun doğurur. İş emirleri geç oluşturulur, bu yüzden kaydedilen arıza başlangıcı yanlıştır. Operatörlerin giderdiği kısa arızalar hiç iş emri almaz, bu yüzden arıza sayıları olduğundan düşüktür. Ve aylık rapor geldiğinde, arızalara neden olan desen haftalar öncesine aittir.

Arıza ve onarım olaylarını doğrudan makineden ve onu onaran kişilerden yakalamak bu üç sorunu da çözer. Makine tam olarak ne zaman durduğunu ve yeniden başladığını bilir. Bir operatör paneli, bir dijital andon sistemi ya da bir teknisyenin telefonu nedeni ekleyebilir. MQTT bu olaylar için doğal bir taşıma katmanıdır, çünkü aynı olaylar makine duruş takibini ve OEE panolarını da besler.

Otomatik Takip için Olay Tasarımı

Bakım olayları için varlık başına bir topic ve küçük bir olay türü kümesi kullanın:

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"}

Bu olayları en az bir kez teslim edilmeleri için QoS 1 ile yayınlayın ve her arızaya bir kimlik verin ki yinelenen bir teslimat iki kez sayılmasın. MQTT QoS seviyeleri rehberinin açıkladığı gibi, bu tür olay verileri için doğru denge QoS 1'dir.

MQTT Olaylarından MTBF ve MTTR Hesaplamak

Aşağıdaki Python servisi bir ön ek altındaki tüm varlıkların bakım olaylarına abone olur, bunları SQLite'ta saklar ve her dakika kayan 30 günlük bir pencerede MTBF ve MTTR'yi yeniden hesaplar. Sonuçları retained message olarak yayınlar; böylece her pano abone olduğu anda güncel değerleri görür. paho-mqtt 2.x ve ConnectMQ herkese açık test broker'ını kullanır; ön eki kendinizinkiyle değiştirin.

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)

Komut satırından bir arıza simüle edin ve KPI'ın bir dakika içinde güncellenmesini izleyin:

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"}'

Bu örnek, planlı duruşlar ve onarımlar dışındaki tüm süreyi çalışma süresi olarak kabul eder; bu, sürekli çalışan varlıklar için uygundur. Yalnızca bazı vardiyalarda çalışan makineler için üretim dışı dönemlerde planned_stop_start ve planned_stop_end yayınlayın ya da vardiya takvimini MES'inizden besleyin. Broker yalnızca olayları taşır; kayıt sistemi SQLite dosyası (ya da historian'ınız) olur, çünkü bir broker veritabanı değildir. Üretimde servisi, portalda üretilen kullanıcı adı, parola ve client ID ile özel ConnectMQ broker'ınıza yönlendirin ve 8883 portunda TLS kullanın.

Sayıları Kullanmak

• Varlıkları önce arıza sayısına, sonra MTTR'ye göre sıralayın. Çok sayıda kısa arızası olan varlık bir güvenilirlik düzeltmesine, az sayıda uzun arızası olan ise bir bakım yapılabilirlik düzeltmesine ihtiyaç duyar.
• Neden koduna göre ayırın. Arıza nedeni başına MTBF, hangi düzeltmelerin metriği en çok iyileştireceğini gösterir.
• Anlık görüntüleri değil, trendleri izleyin. Durum izlemeyi devreye aldıktan sonra yükselen kayan 30 ya da 90 günlük bir MTBF, durum izleme ve kestirimci bakım yatırımlarının karşılığını verdiğinin en net kanıtıdır.
• MTTR bileşenlerini izleyin. Tespit yavaşsa uyarılar ekleyin; parçalar geç geliyorsa yedekleri gözden geçirin; teşhis yavaşsa prosedürleri iyileştirin.

Fabrika metriklerinin büyük resmi ve güvenilirliğin OEE ile bağlantısı için akıllı üretim rehberine bakın.

Güvenilirlik KPI'larını ConnectMQ ile Takip Edin

ConnectMQ; MQTT 5, QoS 1 ve 2, retained message'lar, TLS ve canlı topic gezgini sunan barındırılan bir MQTT broker'dır; böylece arıza olayları, onarım olayları ve hesaplanan KPI'lar tek bir özel omurga üzerinden akar. Broker'ınızı app.connectmq.com adresinde kredi kartı gerektirmeyen ücretsiz Serverless planında oluşturun ya da önce herkese açık MQTT test broker'ında deneyin.

Sık Sorulan Sorular

MTBF nasıl hesaplanır?

Toplam çalışma süresini aynı dönemdeki arıza sayısına bölün. Çalışma süresi, planlı duruşları ve arızaların kendisinin neden olduğu duruşları hariç tutar.

MTTR nasıl hesaplanır?

Arızalı ekipmanı yeniden çalışır hale getirmek için harcanan toplam süreyi onarım sayısına bölün. Makinenin durduğu andan üretime geri teslim edildiği ana kadar ölçün.

MTBF, MTTR ve kullanılabilirlik arasındaki ilişki nedir?

İçsel kullanılabilirlik, MTBF'nin MTBF ile MTTR toplamına bölünmesine eşittir. MTBF'yi artırmak da MTTR'yi düşürmek de kullanılabilirliği iyileştirir.

MTBF ile MTTF arasındaki fark nedir?

MTBF, bir arızadan sonra hizmete dönen onarılabilir varlıklar için geçerlidir. MTTF ise arızalandığında değiştirilen, onarılamayan parçalar için geçerlidir.