IA na manutenção: o que a preditiva exige antes de existir

Nenhum tema do chão de fábrica é vendido com tanta facilidade quanto IA na manutenção preditiva. A promessa cabe em uma frase, a demonstração impressiona, e a proposta comercial chega antes de alguém perguntar se a planta tem o dado que o modelo precisa.

A pergunta incômoda é simples: quantas falhas rotuladas existem no seu histórico, por ativo e por modo de falha? Na maioria das plantas, a resposta é um número de um dígito. Com um dígito não se treina classificador nenhum, e nenhum fornecedor de plataforma resolve isso.

Este artigo trata o assunto pelo pré-requisito. Os quatro tipos de manutenção e onde a IA entra em cada um, o que a preditiva com modelo exige de sensor e de histórico, por que o dado de falha é sempre desbalanceado e por que acurácia alta pode não significar nada.

Depois vêm as partes práticas: o que funciona hoje sem modelo, o ganho rápido de usar IA para ler ordem de serviço em texto livre, o custo do falso alarme e do alarme perdido, uma tabela de MTBF e MTTR com as contas abertas, um cálculo de retorno que dá negativo e o roteiro de maturidade em quatro etapas.

Os números deste artigo foram montados para ele, no formato dos kits da Voitto. São ilustrativos, não descrevem uma empresa real, e servem para mostrar a mecânica de decisão. Todas as contas de MTBF, MTTR, disponibilidade, desbalanceamento e retorno foram conferidas em Python e fecham entre si.

Por que a preditiva é o caso mais vendido e o menos pronto

A manutenção preditiva é o primeiro slide de quase toda apresentação de indústria 4.0. A promessa é limpa e verdadeira: o modelo avisa antes, a equipe intervém em janela programada, a parada não acontece. O problema nunca foi a promessa. É o pré-requisito que a apresentação não menciona.

Um modelo preditivo é um classificador. Ele aprende a separar duas situações, vai falhar nas próximas horas e não vai, olhando exemplos rotulados das duas. Se a planta não tem exemplos rotulados da primeira situação, não existe o que aprender. A demonstração comercial contorna isso rodando em dataset público de rolamento com falha induzida em bancada, onde há centenas de falhas em condição controlada.

A planta real é o oposto disso. Os ativos mais críticos são justamente os que falham menos, o registro de falha está em texto livre digitado às pressas, e o sensor instalado mede o que era barato medir, não o que antecipa o modo de falha.

Isso não é argumento contra a manutenção preditiva nem contra o uso de IA em melhoria contínua. É argumento a favor de começar onde o dado já existe, e de saber dizer em qual ativo o modelo é viável e em qual ele é conversa.

Os quatro tipos de manutenção e onde a IA entra em cada um

Antes de decidir onde colocar modelo, vale recolocar os quatro tipos na mesa. A IA não substitui nenhum deles: ela muda o custo de operar cada um.

Repare na última coluna. O ganho mais rápido está na linha de cima, onde a exigência de dado é a menor: a IA lendo o que a equipe já escreve. O ganho mais vendido está na terceira linha, onde a exigência é a maior.

A manutenção preventiva continua sendo o regime dominante na maioria das plantas, e o primeiro uso honesto de modelo é afinar o intervalo dela, não aposentá-la.

O que a preditiva com modelo exige de verdade

Três condições precisam valer ao mesmo tempo para um ativo específico. Nenhuma delas é software, e todas são verificáveis antes de contratar qualquer coisa.

• Sensor com amostragem adequada ao modo de falha. O sinal precisa conter a informação, e a taxa de leitura precisa preservá-la.
• Histórico de falha rotulado. Dezenas de eventos datados, com modo de falha identificado e hora de início do desvio, não apenas hora do desligamento.
• Modo de falha com sinal antecipado. A degradação precisa ser gradual e observável. Falha súbita por sobrecarga não dá aviso para nenhum modelo.

A terceira condição é a que elimina mais candidatos. Um FMEA do ativo responde isso sem custo: para cada modo de falha listado, pergunte se existe um período de degradação detectável entre o início do desvio e a perda de função. Onde esse período é de minutos, o modelo chega tarde por construção.

Amostragem: o requisito que quase ninguém confere

Esta é a falha silenciosa de projeto mais comum. Instala-se sensor de vibração, contrata-se plataforma, e o dado que chega não contém o fenômeno.

Um defeito em pista interna de rolamento aparece em uma frequência característica que depende da geometria e da rotação. Suponha que ela caia em 160 Hz e que a leitura útil exija três harmônicos, ou seja, conteúdo até 480 Hz. A taxa de aquisição precisa ser de pelo menos 2,56 vezes esse valor, o que dá 1.228,8 Hz. Um sensor que entrega um valor de RMS por minuto não vê nada disso: ele entrega uma média que já jogou fora a assinatura.

O erro se repete em temperatura e corrente. A pergunta a fazer ao fornecedor não é qual a precisão do sensor, e sim qual a taxa de aquisição, qual a banda de frequência preservada e se o dado bruto fica disponível ou se só o agregado sobe para a nuvem. Sem dado bruto, nenhum modelo futuro poderá ser retreinado com outro recorte.

Histórico rotulado: por que três falhas em cinco anos não treinam nada

Modelo supervisionado precisa de exemplos da classe rara. Quantos, depende do sinal, mas a ordem de grandeza é dezenas de eventos por modo de falha, não unidades.

Considere uma ponte rolante que registrou três falhas em cinco anos. Com três eventos não existe divisão entre treino e teste: se você usa dois para treinar, sobra um para validar, e o desempenho medido em um único caso não é medida de nada. Se você usa os três para treinar, não tem validação. Qualquer número apresentado como acurácia nessa situação é ruído apresentado como resultado.

Há ainda o rótulo em si. A data do desligamento está no sistema; o instante em que o desvio começou, quase nunca. Sem esse instante, você não sabe qual janela de dado anterior à falha marcar como pré-falha, e o modelo aprende a fronteira errada.

A saída para o ativo raro não é modelo. É preventiva bem dimensionada, inspeção detectiva e regra de condição com limiar fixo.

MTBF, MTTR e disponibilidade: a foto que decide onde começar

A escolha do ativo piloto não é opinião. Ela sai de uma tabela que a maioria das plantas consegue montar em uma tarde, com a janela de cinco anos e as horas programadas do período. O exemplo abaixo usa 30.000 horas programadas por ativo.

As contas: MTBF é o tempo em operação dividido pelo número de falhas, e tempo em operação é 30.000 menos as horas de parada. MTTR é horas de parada divididas por falhas. Disponibilidade é MTBF dividido pela soma de MTBF e MTTR, o que equivale a tempo em operação sobre horas programadas. Na extrusora: 30.000 menos 262,5 dá 29.737,5; dividido por 75 dá 396,5 h de MTBF; 262,5 dividido por 75 dá 3,50 h de MTTR; 29.737,5 sobre 30.000 dá 99,12%.

Essa mesma tabela é a base de leitura de MTBF e MTTR e alimenta o cálculo de OEE pelo fator disponibilidade. Para a decisão de piloto, ela responde duas coisas: quem tem evento suficiente para treinar (envasadora e compressor) e quem custa caro por evento (extrusora).

O dado desbalanceado e a acurácia que engana

Suponha a envasadora instrumentada com uma leitura por minuto ao longo dos cinco anos: 30.000 horas vezes 60 dá 1.800.000 leituras. Marcando como pré-falha as quatro horas anteriores a cada um dos 210 eventos, você rotula 210 vezes 240, ou seja, 50.400 leituras.

Isso é 2,80% do total. A consequência é direta: um classificador que responde normal para toda leitura acerta 97,20% das vezes. Se o relatório do fornecedor abre com acurácia acima de 97%, ele pode não estar dizendo absolutamente nada.

As métricas que importam são outras. Recall é a fração das falhas reais que o modelo antecipou. Precisão é a fração dos alarmes disparados que correspondiam a falha de verdade. Uma matriz de confusão com os quatro números absolutos, e não percentuais, é o mínimo aceitável em qualquer apresentação de resultado.

O mesmo raciocínio de sinal contra ruído já é familiar a quem usa carta de controle: o que separa evento de variação normal é um limiar justificado, não a impressão de quem olha o gráfico.

Monitoramento por condição com regra fixa: o que funciona hoje

Existe um degrau inteiro entre não medir nada e ter modelo. Ele se chama monitoramento por condição com limiar fixo, é conhecido há décadas, é barato e funciona sem uma linha de aprendizado de máquina.

• Vibração global em rolamento, com alerta e parada definidos por norma ou por linha de base do próprio ativo.
• Temperatura de mancal, com desvio medido contra o ativo gêmeo operando na mesma condição.
• Análise de óleo em intervalo fixo, com limite de partículas e viscosidade.
• Termografia periódica em painel elétrico, com delta de temperatura entre fases.
• Corrente do motor, com faixa esperada por regime de carga.

A regra fixa tem três vantagens que o modelo não tem: ela é explicável para o técnico que vai atender o alarme, ela funciona no primeiro dia sem histórico, e ela não degrada quando o processo muda. A desvantagem é que ela dispara tarde em degradação lenta e não combina múltiplos sinais.

Regra fixa contra modelo preditivo: quando vale trocar

A troca só se justifica quando a regra fixa já está implantada e sua limitação foi medida, não suposta.

A pergunta correta antes de contratar modelo é quantas das falhas do último ano a regra fixa teria pego com antecedência útil, se ela estivesse ligada. Esse número se calcula olhando o histórico de sinal contra as datas de falha, e é o único denominador que torna o ganho do modelo mensurável.

Onde começar sem sensor: a IA lendo ordem de serviço

Toda planta com manutenção corretiva tem um ativo de dado subaproveitado: a ordem de serviço em texto livre. É o campo onde o técnico escreve o que encontrou, com abreviação, erro de digitação e vocabulário próprio. É ilegível para consulta estruturada e perfeitamente legível para um modelo de linguagem.

Este é o ganho rápido e real. Suponha 1.680 ordens corretivas por ano na planta. Classificá-las por modo de falha, componente e sintoma custa algumas dezenas de reais de processamento e cerca de 40 horas de engenharia para montar a taxonomia e validar a amostra, algo próximo de R$ 4.800. Não exige sensor, não exige rotulagem de série temporal, não exige plataforma nova.

O retorno aparece na estratificação que ninguém fazia. No exemplo, 214 das 1.680 ordens, ou 12,74%, citam vazamento em conexão pneumática, espalhadas por 11 ativos diferentes. Nenhuma leitura ativo a ativo mostraria esse padrão. A 0,8 hora de média por ordem, são 171,2 horas de manutenção por ano concentradas em um problema de padrão de montagem.

Daí sai um plano de ação com dono e prazo, que é onde a leitura vira dinheiro. A IA aqui não prevê nada: ela agrupa.

Padronizar a descrição de falha antes de automatizar a leitura

A classificação automática funciona melhor quando a escrita melhora, e a escrita melhora com estrutura mínima no formulário, não com treinamento sobre redação.

• Campo fechado para componente, escolhido de uma lista curta do próprio ativo.
• Campo fechado para modo de falha, com as opções vindas do FMEA daquele equipamento.
• Campo aberto só para o contexto: o que o técnico viu, ouviu e mediu.
• Hora de início do desvio, separada da hora de parada da máquina.
• Ação executada e se ela foi paliativa ou definitiva.

Os dois últimos itens são os que mais faltam e os que mais valem. A hora de início do desvio é exatamente o rótulo que o modelo preditivo vai precisar depois. E a marcação de paliativo contra definitivo é o que permite achar reincidência, entrada natural para os 5 porquês e para uma análise de causa raiz bem feita.

Formalizar isso em um procedimento operacional padrão de abertura e fechamento de ordem custa uma reunião e melhora o dado de todos os anos seguintes.

MTBF e MTTR com apoio de modelo: o que dá para perguntar

Com as ordens classificadas, indicadores que antes eram um número por planta passam a ser cortáveis por modo de falha. Isso muda o tipo de pergunta que a reunião de manutenção consegue responder.

• Qual modo de falha responde pela maior parcela das horas de parada, e não pela maior contagem de ocorrências.
• Em quais ativos o MTTR de um mesmo modo de falha diverge, o que indica diferença de peça em estoque ou de habilidade de turno.
• Qual a fração de ordens reincidentes em até 30 dias no mesmo componente.
• Quanto do MTTR é espera de peça, espera de liberação e mão na máquina, três coisas com donos diferentes.

O último corte costuma ser o mais lucrativo e o menos glamouroso. Em muitas plantas, a maior parcela do MTTR é espera de peça, e nenhum modelo preditivo do mundo resolve estoque de sobressalente.

O falso alarme e o custo dele na confiança da equipe

Falso alarme tem dois custos. O contábil é fácil de estimar. O outro corrói o projeto e não aparece em planilha nenhuma.

No custo contábil, considere a extrusora do exemplo: cada verificação disparada por alarme consome 1,5 hora de parada para inspeção e 2 horas de técnico. Com margem de contribuição perdida de R$ 4.200 por hora parada e hora técnica de R$ 120, um alarme falso custa 1,5 vezes 4.200 mais 2 vezes 120, ou seja, R$ 6.540.

O custo invisível é o comportamento. Depois de três ou quatro deslocamentos que não acharam nada, o técnico passa a tratar o alerta como opcional. Quando o alarme verdadeiro chega, ele espera o fim do turno. O modelo continua com a mesma precisão estatística e perdeu toda a utilidade operacional, porque a ação que ele deveria disparar parou de acontecer.

Por isso a precisão, e não o recall, costuma ser a métrica a proteger no primeiro ano. Vale mais um modelo que avisa metade das falhas e quase nunca erra do que um que avisa quase todas e cria rotina de alarme ignorado.

O alarme perdido e o custo dele na parada

O erro simétrico é a falha que o modelo não viu. Ela custa a parada inteira, e o cálculo é o MTTR do ativo multiplicado pela margem perdida por hora, mais o custo direto do reparo emergencial e o prêmio de frete de peça.

Na extrusora, uma falha não antecipada custa 3,5 horas de parada, o que dá R$ 14.700 só de margem. Com 15 falhas por ano, a conta anual de corretiva nesse ativo é de 52,5 horas, ou R$ 220.500. Esse é o pote que o modelo disputa, e é bom conhecê-lo antes de negociar contrato.

Alarme perdido também precisa de tratamento, não só de registro. Toda falha que passou pelo modelo sem aviso merece análise de causa raiz com uma pergunta a mais que o normal: o sinal estava no dado e o modelo não viu, ou o sinal nunca esteve no dado? As duas respostas levam a ações opostas, retreino em um caso e mudança de instrumentação no outro.

Como medir se o modelo está ganhando dinheiro

Aqui está o cálculo que quase nunca é feito, com a extrusora L2 e um contrato típico. Premissas: 15 falhas por ano, MTTR corretivo de 3,5 h, intervenção planejada de 1,2 h, margem perdida de R$ 4.200 por hora, quatro pontos de sensor a R$ 3.500 amortizados em três anos, plataforma a R$ 1.800 por mês e 0,2 de um analista cujo custo total é R$ 14.000 por mês.

O ganho por parada evitada sai de 9 falhas vezes 2,3 horas economizadas vezes R$ 4.200. O custo anual do sistema soma R$ 4.667 de amortização, R$ 21.600 de plataforma e R$ 33.600 de pessoa. O cenário A, que é o desempenho real de muitos pilotos no primeiro ano, dá prejuízo de quase R$ 32 mil.

Fixando o recall em 0,60, o ponto de equilíbrio está em 4,14 alarmes falsos por ano, o que corresponde a precisão de 68,49%. Abaixo disso o projeto destrói valor mesmo acertando falhas. Esse número é o que deveria estar na cláusula de desempenho do contrato, no lugar de acurácia.

A manutenção autônoma do TPM e o que a IA não substitui

A manutenção autônoma é um dos 8 pilares do TPM e entrega, com custo próximo de zero, boa parte do que o sensor promete: o operador que limpa, inspeciona, lubrifica e reaperta identifica folga, vazamento e ruído novo antes de qualquer curva subir.

Esse ganho depende de condição visível, e condição visível depende de 5S efetivo. Máquina suja não deixa ver vazamento incipiente; painel desorganizado não deixa ver componente aquecido. Instalar sensor em ativo que ninguém limpa é pagar caro por uma informação que a rotina daria de graça.

O que a IA não substitui é o operador que escuta a máquina. Ele integra som, vibração na mão, cheiro e contexto do lote em uma inferência que nenhum sensor instalado capta, porque ninguém instrumentou o cheiro. O papel do modelo é cobrir o que o humano não alcança, como o turno da madrugada e a tendência lenta ao longo de semanas, e não disputar o que o humano faz melhor.

Roteiro de maturidade em quatro etapas

A ordem abaixo não é burocracia. Cada etapa produz o insumo da seguinte, e pular uma delas é o que transforma piloto em prejuízo.

1. Etapa 1, de um a três meses. Padronizar a ordem de serviço com campos fechados, registrar hora de início do desvio e montar a tabela de MTBF, MTTR e disponibilidade por ativo. Entregável: a foto que prioriza.
2. Etapa 2, de dois a quatro meses. Classificar o histórico de ordens com modelo de linguagem, estratificar por modo de falha e atacar os dois maiores blocos com plano de ação. Entregável: horas de parada reduzidas sem investir em sensor.
3. Etapa 3, de três a seis meses. Instalar monitoramento por condição com limiar fixo nos ativos que a etapa 1 elegeu, medir quantas falhas ele teria pego e guardar o dado bruto desde o primeiro dia. Entregável: linha de base e histórico de sinal.
4. Etapa 4, a partir de 18 meses de sinal. Treinar modelo apenas no ativo com evento suficiente, contratar por precisão mínima e comparar contra o desempenho medido da regra fixa. Entregável: decisão baseada em número próprio.

A etapa 4 é opcional, e essa é a parte desconfortável. Em boa parte das plantas, o retorno acumulado das três primeiras supera o que o modelo entregaria, por um custo de operação muito menor.

O protocolo

Para fechar em ações verificáveis, o roteiro de decisão cabe em sete passos.

1. Monte a tabela de falhas, MTBF, MTTR e disponibilidade dos seus 20 ativos principais em janela de cinco anos, com as contas abertas.
2. Elimine da lista de candidatos a modelo todo ativo com menos de algumas dezenas de falhas registradas por modo.
3. Para os que sobraram, confirme no FMEA que o modo de falha dominante tem degradação detectável, e não falha súbita.
4. Confirme com o fornecedor a taxa de aquisição, a banda preservada e o acesso ao dado bruto, por escrito.
5. Padronize a ordem de serviço e rode a classificação do histórico em texto antes de comprar qualquer sensor.
6. Implante regra fixa de condição e meça quantas falhas ela pegaria, para ter denominador.
7. Só então avalie modelo, com contrato que fixe precisão mínima calculada a partir do seu custo de alarme falso.

A conclusão prática sobre IA na manutenção preditiva é modesta e útil ao mesmo tempo. O modelo é a última etapa de uma cadeia, não a primeira, e a maior parte do dinheiro está antes dele: no registro que ninguém padroniza, na estratificação que ninguém faz e na regra simples que ninguém ligou.