Temos visto excelentes artigos técnicos e vídeos tratando de Indústria 4.0, IoT (Internet das Coisas), Machine Learning, Realidade Virtual — todos, de certa forma, relacionados. Estamos preparados para entrar nessa nova era da tecnologia e da gestão de ativos? Como estamos com o básico?
Você ainda usa o MTBF para subsidiar seu planejamento de manutenção? Você reporta Confiabilidade ou MTBF? É realmente complicado calcular a Confiabilidade sem admitir taxas de falha constantes?
Vamos apresentar um exemplo de como o uso do MTBF leva a erros — muitas vezes catastróficos — quando esse indicador (lag indicator) é usado sem uma análise que vá além do cálculo da média.
O caso das duas máquinas
Numa determinada indústria, o Gerente de Manutenção, Sr. Fernando, pediu ao seu Engenheiro de Confiabilidade, Sr. Alberto, que acompanhasse duas máquinas que estavam voltando de uma parada geral (overhauling), com vários componentes e peças substituídos e novos controles acrescentados. As máquinas voltaram como novas à operação. Ficou combinado que, após 10 falhas funcionais registradas, o engenheiro calcularia o MTBF de cada máquina e apresentaria os resultados.
A máquina nº 1 apresentou sua 10ª falha ao atingir 3.200 horas de operação. Os tempos de reparo foram muito curtos, sem efeito significativo sobre o tempo total do ensaio. A máquina nº 2 só chegou à 10ª falha com 2.993 horas de operação, valendo as mesmas restrições.
Como o engenheiro calculou o MTBF? Fazendo a média — o tempo total dividido pelo número de falhas:
MTBF1 = 3.200 / 10 = 320 horas
MTBF2 = 2.993 / 10 ≈ 299,3 horas
O gerente comentou:
“Alberto, a máquina 2 realmente me parece ter uma frequência de falhas mais distribuída no tempo. Muitas OSs têm sido emitidas para esse equipamento. Já a máquina 1, no início tivemos várias paradas, mas depois desse período problemático tenho visto poucas OSs — as falhas parecem mais espaçadas. Você pode me mostrar como essas falhas foram distribuídas no tempo até a 10ª falha?”
Os tempos para falhar (TTF)
Os dados que o engenheiro trouxe:
Máquina 1 — TTF (horas): 1, 9, 22, 60, 220, 728, 980, 1.310, 1.920, 3.200.
Máquina 2 — TTF (horas): 587, 870, 1.315, 1.501, 1.720, 2.445, 2.718, 2.725, 2.875, 2.993.
Fica evidente: a máquina 1 concentra falhas nas primeiras horas depois do overhauling (mortalidade infantil clássica), e depois se estabiliza. A máquina 2 mostra falhas cada vez mais próximas — comportamento típico de desgaste. Mesmo assim, o MTBF das duas é praticamente idêntico. Alguém pretende planejar a manutenção com base nesses dados?
Por que o MTBF engana
O indicador MTBF só é válido sob premissas específicas:
- A taxa de falha deve ser constante para que a média faça sentido — e aqui, claramente, não é o caso de nenhuma das duas máquinas.
- O MTBF só se aplica a itens reparáveis. Para itens não reparáveis (peças substituídas quando falham), usa-se o MTTF (Mean Time to Fail).
- Os tempos de parada para reparo devem ser insignificantes em relação ao tempo total de ensaio.
- MTBF não é probabilidade de sucesso (confiabilidade).
- MTBF não significa que uma falha ocorrerá a cada intervalo igual ao valor calculado. Se R(t) for calculado para t = MTBF, admitindo taxa constante, o resultado é 36,8% — não 50% (isso valeria apenas para uma distribuição Normal).
- MTBF não é tempo isento de falhas.
Cálculo da confiabilidade R(t) via MTBF (taxa constante)
Para a Máquina 1, admitindo taxa de falha constante:
λ1 = 1 / MTBF1 = 1 / 320 ≈ 0,0031 falha/hora.
Confiabilidade para 300 horas de operação:
R(t) = e−λ·t → R(300) = e−0,0031 × 300 ≈ 39,2%.
Ou seja: assumindo λ constante, a probabilidade de o equipamento falhar até 300 h seria de 60,8%. O mesmo cálculo aplicado à máquina 2 dá um resultado numericamente parecido — embora os perfis de falha sejam radicalmente diferentes. Planejar manutenção assim invariavelmente traz surpresas desagradáveis.
A saída: modelamento estatístico com Weibull
MTBF é o inverso da taxa de falha — não a confiabilidade do item em análise. A forma correta de determinar a confiabilidade e a taxa real de falha (chamada de taxa de risco, que pode variar no tempo) é modelar estatisticamente os Tempos Para Falhar. O modelamento mais usado é a Distribuição de Weibull.
Existem softwares dedicados (o mais conhecido é o Weibull++ da ReliaSoft), mas o bom e velho Excel, com suas built-in functions, resolve muitos casos práticos — quem não tem cão, caça com gato.
Do modelamento de Weibull extraímos dois parâmetros essenciais:
- β (fator de forma): indica o regime de falha.
- 0 < β < 1 → mortalidade infantil (taxa de falha decrescente);
- β = 1 → falha aleatória, taxa de falha constante;
- β > 1 → desgaste (taxa de falha crescente).
- η (vida característica): tempo correspondente a 63,2% de probabilidade de falha. Quando β = 1, η coincide com o MTTF.
Aplicando aos dados das duas máquinas
Rodando o modelamento de Weibull nos TTF apresentados:
- Máquina 1: β ≈ 0,41 e η ≈ 588 h — mortalidade infantil, exatamente como observado. Nesse regime, manutenção preventiva não é eficaz: é preciso atacar as causas dos defeitos de instalação, ajuste e componentes prematuros.
- Máquina 2: β ≈ 1,96 e η ≈ 2.291 h — desgaste. Aqui, a manutenção preditiva (monitoramento de condição) e a preventiva (restauração ou descarte de itens em desgaste) são apropriadas.
A taxa de risco h(t) confirma o quadro: decrescente na Máquina 1 e crescente na Máquina 2. Nenhuma das duas está sequer perto de uma taxa constante. Um plano de manutenção proativa fundamentado no MTBF trataria as duas máquinas como se fossem iguais — o que, além de ineficaz, pode agravar problemas.
Conclusão
MTBF é útil como referência histórica agregada, mas não deve ser confundido com confiabilidade nem usado isoladamente como base de planejamento. Comece a reportar R(t) obtido da distribuição observada dos TTF; conheça o β e o η do seu ativo e do modo de falha. É esse rigor que separa a manutenção reativa da confiabilidade gerenciada — e é o alicerce para as camadas de Indústria 4.0, IoT e Machine Learning entregarem valor de verdade.
William Thorlay — Senior Consultant in Reliability Engineering, R&D Thorlay e SQLBRASIL. Publicado originalmente no LinkedIn.