Cálculo de MTBF y MTTR: fórmulas, ejemplos y seguimiento automático con MQTT

El cálculo de MTBF y MTTR es la base de cualquier conversación sobre confiabilidad en una planta: ¿con qué frecuencia falla esta máquina y cuánto tardamos en volver a ponerla en marcha? Esta guía explica ambas fórmulas, resuelve un ejemplo completo, señala las trampas de definición que hacen que los números no sean comparables y muestra cómo calcular las métricas automáticamente a partir de eventos de falla y reparación capturados por MQTT.

Qué miden el MTBF y el MTTR

MTBF (Mean Time Between Failures, tiempo medio entre fallas) es el tiempo medio de operación entre una falla y la siguiente en un activo reparable. Cuanto más alto, mejor. Describe la confiabilidad: cuánto tiempo suele funcionar la máquina antes de que algo se rompa.

MTTR (Mean Time To Repair, tiempo medio de reparación) es el tiempo medio desde el momento en que una falla detiene la máquina hasta que se restablece el servicio. Cuanto más bajo, mejor. Describe la mantenibilidad y la eficacia de tu respuesta: detección, desplazamiento, diagnóstico, espera de repuestos, reparación y pruebas.

Juntos determinan durante qué proporción del tiempo está disponible una máquina, y apuntan a palancas de mejora distintas. Un MTBF bajo exige una mejor estrategia de mantenimiento, cambios de diseño o monitorización de condición. Un MTTR alto exige una detección más rápida, una mejor gestión de repuestos, procedimientos más claros y formación.

Las fórmulas

El tiempo de operación es el tiempo durante el cual el activo debía funcionar y funcionó realmente. Excluye las paradas planificadas, como fines de semana, mantenimiento planificado y cambios de formato, y excluye también el propio tiempo de parada por falla. Acertar con este denominador es donde fallan la mayoría de los cálculos.

Ejemplo resuelto de cálculo de MTBF y MTTR

Toma una máquina de envasado durante un periodo de cuatro semanas. Está programada para dos turnos de 8 horas, cinco días a la semana, lo que da 20 días x 16 horas = 320 horas programadas. Durante ese periodo registra cuatro fallas:

Paso a paso:

1. Tiempo total de parada por fallas = 0,5 + 3,0 + 1,0 + 1,5 = 6,0 horas.
2. Tiempo de operación = 320 horas programadas - 6,0 horas de parada por fallas = 314 horas.
3. MTBF = 314 / 4 = 78,5 horas.
4. MTTR = 6,0 / 4 = 1,5 horas.
5. Disponibilidad inherente = 78,5 / (78,5 + 1,5) = 98,1 por ciento.
6. Tasa de fallas = 4 / 314 = aproximadamente 0,0127 fallas por hora de operación.

Los mismos datos te indican también dónde mirar. Dos de las cuatro fallas fueron atascos en la alimentación, así que una sola corrección allí podría reducir a la mitad el número de fallas, mientras que la rotura de la correa domina el MTTR y sugiere comprobar si hay correas de repuesto disponibles en la línea.

Trampas de definición que conviene evitar

Las métricas solo son útiles si todo el mundo las calcula de la misma forma. Acuerda estas reglas antes de publicar un solo número:

1. Qué cuenta como falla. Una regla habitual es cualquier parada no planificada más larga que un umbral, por ejemplo cinco minutos, que requiera intervención. Las microparadas por debajo del umbral pertenecen a la pérdida de rendimiento, no al MTBF. Deja el umbral por escrito.
2. Tiempo de operación frente a tiempo de calendario. Usar horas de calendario infla el MTBF de las máquinas que solo trabajan un turno. Usa el tiempo de marcha programado menos el tiempo de parada por fallas.
3. Dónde empieza y termina el MTTR. Empieza en el momento en que la máquina se detuvo, no cuando llegó el técnico. Termina cuando la máquina se devuelve a producción, no cuando se cierra la orden de trabajo en la oficina. El tiempo de respuesta forma parte del problema que intentas medir.
4. MTBF frente a MTTF. El MTTF (Mean Time To Failure, tiempo medio hasta la falla) se aplica a elementos no reparables, como una bombilla o un rodamiento sellado. Para las máquinas que reparas, usa el MTBF.
5. Muestras pequeñas. Con dos fallas al año, el MTBF oscila muchísimo. Infórmalo junto con el número de fallas y usa ventanas más largas para los activos muy confiables.
6. El MTBF no es una vida útil. Un MTBF de 1.000 horas no significa que la máquina funcione 1.000 horas y luego se rompa. Es una tasa media; las fallas pueden producirse antes, y se producen.

Por qué falla el seguimiento manual

En muchas plantas, el MTBF y el MTTR se calculan una vez al mes a partir de las órdenes de trabajo del CMMS. Eso introduce tres problemas. Las órdenes de trabajo se crean tarde, así que el inicio de la falla registrado es incorrecto. Las fallas breves que resuelven los operadores nunca generan una orden de trabajo, así que el número de fallas es demasiado bajo. Y cuando llega el informe mensual, el patrón que causó las fallas tiene semanas de antigüedad.

Capturar los eventos de falla y reparación directamente desde la máquina y desde las personas que la reparan resuelve los tres. La máquina sabe exactamente cuándo se detuvo y cuándo volvió a arrancar. Un panel de operador, un sistema andon digital o el teléfono de un técnico pueden añadir el motivo. MQTT es un transporte natural para esos eventos, porque los mismos eventos alimentan también el seguimiento de paradas de máquina y los dashboards de OEE.

Diseño de eventos para el seguimiento automático

Usa un topic por activo para los eventos de mantenimiento y un conjunto reducido de tipos de evento:

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

Publica estos eventos con QoS 1 para que se entreguen al menos una vez, y asigna un ID a cada falla para que una entrega duplicada no se cuente dos veces. Como explica la guía de niveles de QoS de MQTT, QoS 1 es el equilibrio adecuado para datos de eventos como estos.

Calcular el MTBF y el MTTR a partir de eventos MQTT

El servicio en Python de abajo se suscribe a los eventos de mantenimiento de todos los activos bajo un prefijo, los guarda en SQLite y cada minuto recalcula el MTBF y el MTTR sobre una ventana móvil de 30 días. Publica los resultados como retained messages para que cualquier dashboard vea los valores actuales en el momento en que se suscribe. Usa paho-mqtt 2.x y el servidor MQTT público gratuito de ConnectMQ; sustituye el prefijo por el tuyo.

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)

Simula una falla desde la línea de comandos y observa cómo se actualiza el KPI en menos de un minuto:

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

Este ejemplo trata como tiempo de operación todo el tiempo fuera de paradas planificadas y reparaciones, lo que encaja con activos que funcionan de forma continua. Para máquinas que solo trabajan algunos turnos, publica planned_stop_start y planned_stop_end para los periodos sin producción, o alimenta el calendario de turnos desde tu MES. El broker solo transporta eventos; el archivo SQLite (o tu historiador) es el sistema de registro, porque un broker no es una base de datos. El servidor público es solo para pruebas y prototipos: en producción, apunta el servicio a tu broker privado de ConnectMQ con el username, la password y el client ID generados en el portal, y usa TLS en el puerto 8883.

Cómo usar los números

• Ordena los activos primero por número de fallas y después por MTTR. El activo con muchas fallas cortas necesita una mejora de confiabilidad; el que tiene pocas fallas largas necesita una mejora de mantenibilidad.
• Desglosa por código de motivo. El MTBF por motivo de falla muestra qué correcciones moverían más la métrica.
• Sigue tendencias, no instantáneas. Un MTBF móvil de 30 o 90 días que sube tras introducir la monitorización de condición es la prueba más clara de que las inversiones en monitorización de condición frente a mantenimiento predictivo están dando resultado.
• Vigila los componentes del MTTR. Si la detección es lenta, añade alertas; si los repuestos tardan, revisa el stock; si el diagnóstico es lento, mejora los procedimientos.

Para una visión más amplia de las métricas de planta y de cómo se relaciona la confiabilidad con el OEE, consulta la guía de manufactura inteligente.

Sigue tus KPIs de confiabilidad con ConnectMQ

ConnectMQ es un broker MQTT gestionado con MQTT 5, QoS 1 y 2, retained messages, TLS y un explorador de topics en vivo, de modo que los eventos de falla, los eventos de reparación y los KPIs calculados fluyen por una única columna vertebral privada. Crea tu broker en el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito, o prueba primero en el servidor MQTT público gratuito.

Preguntas frecuentes

¿Cómo se calcula el MTBF?

Divide el tiempo total de operación entre el número de fallas del mismo periodo. El tiempo de operación excluye las paradas planificadas y el tiempo de parada causado por las propias fallas.

¿Cómo se calcula el MTTR?

Divide el tiempo total dedicado a restablecer los equipos averiados entre el número de reparaciones. Mide desde el momento en que la máquina se detuvo hasta que se devuelve a producción.

¿Qué relación hay entre MTBF, MTTR y disponibilidad?

La disponibilidad inherente es igual al MTBF dividido entre la suma de MTBF y MTTR. Aumentar el MTBF o reducir el MTTR mejoran la disponibilidad.

¿Cuál es la diferencia entre MTBF y MTTF?

El MTBF se aplica a activos reparables que vuelven al servicio tras una falla. El MTTF se aplica a elementos no reparables que se sustituyen cuando fallan.