Cálculo de MTBF e MTTR: fórmulas, exemplos e acompanhamento automático com MQTT

O cálculo de MTBF e MTTR é a base de toda conversa sobre confiabilidade em uma planta: com que frequência esta máquina falha e quanto tempo levamos para colocá-la de volta em operação? Este guia explica as duas fórmulas, resolve um exemplo completo, destaca as armadilhas de definição que tornam os números incomparáveis e mostra como calcular as métricas automaticamente a partir de eventos de falha e reparo capturados via MQTT.

O que MTBF e MTTR medem

MTBF (Mean Time Between Failures, tempo médio entre falhas) é o tempo médio de operação entre uma falha e a seguinte para um ativo reparável. Quanto maior, melhor. Ele descreve a confiabilidade: quanto tempo a máquina normalmente funciona antes de algo quebrar.

MTTR (Mean Time To Repair, tempo médio de reparo) é o tempo médio desde o momento em que uma falha para a máquina até ela voltar a operar. Quanto menor, melhor. Ele descreve a manutenibilidade e a eficácia da sua resposta: detecção, deslocamento, diagnóstico, espera por peças, reparo e testes.

Juntos, eles determinam por quanto tempo a máquina fica disponível, e apontam para alavancas de melhoria diferentes. MTBF baixo pede uma estratégia de manutenção melhor, mudanças de projeto ou monitoramento de condição. MTTR alto pede detecção mais rápida, melhor gestão de sobressalentes, procedimentos mais claros e treinamento.

As fórmulas

Tempo de operação significa o tempo em que o ativo deveria funcionar e de fato funcionou. Ele exclui paradas planejadas, como fins de semana, manutenção planejada e setups, e exclui a própria parada por falha. Acertar esse denominador é onde a maioria dos cálculos erra.

Exemplo resolvido de cálculo de MTBF e MTTR

Pegue uma máquina de embalagem ao longo de quatro semanas. Ela está programada para dois turnos de 8 horas, cinco dias por semana, o que dá 20 dias x 16 horas = 320 horas programadas. Nesse período, ela registra quatro falhas:

Passo a passo:

1. Tempo total parado por falhas = 0,5 + 3,0 + 1,0 + 1,5 = 6,0 horas.
2. Tempo de operação = 320 horas programadas - 6,0 horas paradas por falha = 314 horas.
3. MTBF = 314 / 4 = 78,5 horas.
4. MTTR = 6,0 / 4 = 1,5 hora.
5. Disponibilidade inerente = 78,5 / (78,5 + 1,5) = 98,1 por cento.
6. Taxa de falhas = 4 / 314 = cerca de 0,0127 falha por hora de operação.

Os mesmos dados também dizem onde procurar. Duas das quatro falhas foram travamentos na alimentação, então uma única correção ali poderia reduzir pela metade o número de falhas, enquanto a falha da correia domina o MTTR e sugere verificar se há correias sobressalentes estocadas junto à linha.

Armadilhas de definição a evitar

As métricas só são úteis se todos as calcularem da mesma forma. Combine estas regras antes de publicar qualquer número:

1. O que conta como falha. Uma regra comum é qualquer parada não planejada mais longa que um limite, por exemplo cinco minutos, que exija intervenção. Microparadas abaixo do limite entram como perda de desempenho, não no MTBF. Registre esse limite por escrito.
2. Tempo de operação versus tempo de calendário. Usar horas de calendário infla o MTBF de máquinas que rodam só um turno. Use o tempo programado de operação menos o tempo parado por falha.
3. Onde o MTTR começa e termina. Comece no momento em que a máquina parou, não quando o técnico chegou. Termine quando a máquina for liberada de volta para a produção, não quando a ordem de serviço for encerrada no escritório. O tempo de resposta faz parte do problema que você está tentando medir.
4. MTBF versus MTTF. O MTTF (Mean Time To Failure, tempo médio até a falha) se aplica a itens não reparáveis, como uma lâmpada ou um rolamento selado. Para máquinas que você conserta, use MTBF.
5. Amostras pequenas. Com duas falhas por ano, o MTBF oscila muito. Reporte-o junto com o número de falhas e use janelas mais longas para ativos muito confiáveis.
6. MTBF não é vida útil. Um MTBF de 1.000 horas não significa que a máquina funciona 1.000 horas e depois quebra. É uma taxa média; falhas podem acontecer cedo, e acontecem.

Por que o acompanhamento manual falha

Em muitas plantas, MTBF e MTTR são calculados uma vez por mês a partir das ordens de serviço do CMMS. Isso cria três problemas. As ordens de serviço são abertas com atraso, então o início registrado da falha está errado. Falhas curtas resolvidas pelos operadores nunca geram ordem de serviço, então a contagem de falhas fica baixa demais. E quando o relatório mensal chega, o padrão que causou as falhas já tem semanas.

Capturar os eventos de falha e reparo diretamente da máquina e das pessoas que a consertam resolve os três. A máquina sabe exatamente quando parou e quando voltou. Um painel do operador, um sistema andon digital ou o celular do técnico pode acrescentar o motivo. O MQTT é um transporte natural para esses eventos, porque os mesmos eventos também alimentam o apontamento de paradas de máquina e os dashboards de OEE.

Modelagem de eventos para acompanhamento automático

Use um topic por ativo para os eventos de manutenção e um pequeno conjunto 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"}

Publique esses eventos com QoS 1 para que sejam entregues pelo menos uma vez e dê a cada falha um ID, para que uma entrega duplicada não conte duas vezes. Como explica o guia de níveis de QoS do MQTT, QoS 1 é o equilíbrio certo para dados de evento como esses.

Calculando MTBF e MTTR a partir de eventos MQTT

O serviço Python abaixo assina os eventos de manutenção de todos os ativos sob um prefixo, armazena-os em SQLite e, a cada minuto, recalcula MTBF e MTTR em uma janela móvel de 30 dias. Ele publica os resultados como retained messages, para que qualquer dashboard veja os valores atuais no momento em que assina. Ele usa paho-mqtt 2.x e o servidor MQTT público do ConnectMQ; substitua o prefixo pelo seu.

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)

Simule uma falha pela linha de comando e veja o KPI atualizar em até um 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 exemplo trata todo o tempo fora de paradas planejadas e reparos como tempo de operação, o que serve para ativos de operação contínua. Para máquinas que rodam só alguns turnos, publique planned_stop_start e planned_stop_end para os períodos sem produção, ou alimente o calendário de turnos a partir do seu MES. O broker apenas transporta os eventos; o arquivo SQLite (ou o seu historiador) é o sistema de registro, porque um broker não é um banco de dados. Lembre-se de que o servidor público serve para testes e protótipos, não para dados de produção. Em produção, aponte o serviço para o seu broker ConnectMQ privado com o username, o password e o client ID gerados no portal e use TLS na porta 8883.

Usando os números

• Classifique os ativos primeiro pelo número de falhas, depois pelo MTTR. O ativo com muitas falhas curtas precisa de uma correção de confiabilidade; o que tem poucas falhas longas precisa de uma correção de manutenibilidade.
• Separe por código de motivo. O MTBF por motivo de falha mostra quais correções mais mexeriam na métrica.
• Acompanhe tendências, não fotografias. Um MTBF móvel de 30 ou 90 dias que sobe depois que você introduz monitoramento de condição é a prova mais clara de que os investimentos discutidos em monitoramento de condição vs manutenção preditiva estão dando retorno.
• Observe os componentes do MTTR. Se a detecção é lenta, adicione alertas; se as peças demoram, revise os sobressalentes; se o diagnóstico é lento, melhore os procedimentos.

Para a visão mais ampla dos indicadores da planta e de como a confiabilidade se conecta ao OEE, veja o guia de manufatura inteligente.

Acompanhe KPIs de confiabilidade com o ConnectMQ

O ConnectMQ é um broker MQTT gerenciado com MQTT 5, QoS 1 e 2, retained messages, TLS e explorador de topics ao vivo, para que eventos de falha, eventos de reparo e KPIs calculados passem todos por uma única espinha dorsal privada. Crie seu broker no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, ou teste antes no servidor MQTT público.

Perguntas frequentes

Como se calcula o MTBF?

Divida o tempo total de operação pelo número de falhas no mesmo período. O tempo de operação exclui as paradas planejadas e o tempo parado causado pelas próprias falhas.

Como se calcula o MTTR?

Divida o tempo total gasto para restabelecer os equipamentos que falharam pelo número de reparos. Meça desde o momento em que a máquina parou até ela ser liberada de volta para a produção.

Qual é a relação entre MTBF, MTTR e disponibilidade?

A disponibilidade inerente é igual ao MTBF dividido pela soma de MTBF e MTTR. Aumentar o MTBF ou reduzir o MTTR melhora a disponibilidade.

Qual é a diferença entre MTBF e MTTF?

O MTBF se aplica a ativos reparáveis que voltam a operar depois de uma falha. O MTTF se aplica a itens não reparáveis, que são substituídos quando falham.