Manutenção Preditiva com Machine Learning: Quando Vale a Pena e Quando é Só um Alarme Caro | Blog

# Manutenção Preditiva com Machine Learning: Quando Vale a Pena e Quando é Só um Alarme Caro

TL;DR: Sem histórico de falhas rotulado — e a maioria das operações em Angola não o tem — não há modelo supervisionado de manutenção preditiva que se sustente; a alternativa realista é deteção de anomalias sobre vibração e outros sinais de condição, e mesmo essa só compensa quando bate uma linha de base estatística simples e não satura a equipa de manutenção com falsos alarmes.

O termo que se tornou vago demais

"Manutenção preditiva com machine learning" passou a ser usado para descrever coisas muito diferentes: um sensor de vibração sem fio que compara uma leitura contra um limite fixo da norma ISO 20816-3, um modelo estatístico que deteta desvios face ao comportamento normal de uma bomba, e — mais raramente do que a promessa comercial sugere — um modelo supervisionado treinado com anos de historial de falhas reais que estima dias até à avaria (remaining useful life, RUL).

São três níveis de maturidade diferentes, com pré-requisitos de dados completamente diferentes. Confundi-los é a razão pela qual tantos projetos de "IA para manutenção" em ambiente industrial acabam por gerar mais ruído do que valor. Vamos a cada um.

Nível 1: monitorização de condição baseada em limites físicos

É o ponto de partida honesto e o que a maior parte do parque de bombas e compressores em Angola ainda não tem de forma sistemática. A norma internacional ISO 20816-3 (que consolidou a antiga ISO 10816-3) define zonas de severidade de vibração — A, B, C e D — a partir da velocidade RMS medida na carcaça do rolamento, para máquinas acima de 15 kW. Zona A é uma máquina recém-comissionada; Zona D é vibração já suficiente para causar dano e justificar paragem.

Isto não é machine learning. É física instrumentada com um sensor e uma tabela de limites. E é, na prática, onde a maioria das plantas deveria começar antes de comprar qualquer coisa rotulada como "IA preditiva": se ainda não existe recolha consistente de vibração, temperatura de rolamento e corrente do motor em cadência regular, não existe matéria-prima para nenhum modelo, simples ou complexo.

Fornecedores como a SKF (Enlight Collect) e a Bently Nevada da Baker Hughes (System 1) vendem exatamente esta camada — sensores sem fio ou cablados, mais um limite de alarme configurável — e é uma base sólida mesmo sem nenhuma componente estatística mais sofisticada por cima.

Nível 2: deteção de anomalias — a alternativa realista quando não há falhas rotuladas

Aqui é onde a maioria dos projetos de ML industrial deveria efetivamente aterrar, e onde a maioria não o faz porque "deteção de anomalias" soa menos impressionante em PowerPoint do que "IA prevê falhas".

O problema de fundo é simples de enunciar e incómodo de aceitar: um modelo supervisionado de previsão de falha precisa de exemplos rotulados de falha — vibração, temperatura, pressão, corrente, tudo alinhado no tempo até ao momento exato da avaria, repetido dezenas de vezes por tipo de equipamento para o modelo generalizar. Mesmo em ambiente de laboratório controlado, isto é raro: o conjunto de dados de referência da indústria para este tipo de trabalho, o IMS Bearing Dataset do repositório de prognóstico da NASA/PHM Society, foi obtido correndo rolamentos até à destruição física, de propósito, num banco de ensaio — e mesmo assim cobre um punhado de rolamentos, não uma frota. É esse o custo real de uma etiqueta de vida útil remanescente.

Numa refinaria, num terminal ou numa plataforma real, ninguém deixa uma bomba de processo correr até à destruição para gerar dados de treino. As falhas são eventos raros, censurados (a manutenção intervém antes do colapso total) e específicos de cada máquina, fundação e regime de carga. Isto quer dizer, sem rodeios: se a sua operação não tem anos de histórico de falhas rotulado e alinhado a sinais de sensor, não tem os dados para treinar um modelo supervisionado de previsão de falha — e comprar uma plataforma que promete isso sem esse histórico está a comprar um modelo genérico calibrado nos dados de outra pessoa, não nos seus ativos.

A alternativa que efetivamente funciona com os dados que a maioria das operações já tem — séries temporais de vibração, temperatura e corrente, sem rótulo de falha — é a deteção de anomalias não supervisionada: o modelo aprende o que é "normal" para aquela bomba ou compressor específico, em vez de aprender o aspeto de uma falha. Técnicas como Isolation Forest ou autoencoders são as mais usadas neste contexto; um estudo comparativo publicado na ScienceDirect sobre deteção de anomalias em dados de sensores no setor de óleo e gás usa exatamente estas duas técnicas — KNN e Isolation Forest — sobre dados rotulados por média móvel, precisamente porque rótulos de falha real não estavam disponíveis.

A vantagem desta abordagem: não precisa de exemplos de falha para arrancar. A desvantagem, que raramente é dita em proposta comercial: um desvio face ao "normal" não diz automaticamente qual é o modo de falha nem quantos dias faltam até à avaria. Diz "isto está diferente do que era" — e cabe a um engenheiro de fiabilidade interpretar se é desgaste de rolamento, desalinhamento, cavitação ou apenas uma mudança de regime operacional legítima.

O custo que ninguém desconta na proposta: falsos positivos

Um alarme de manutenção preditiva não é gratuito quando dispara. Alguém tem de ir ao campo, isolar o equipamento, inspecionar, e só depois voltar a colocá-lo em serviço — tempo de uma equipa de fiabilidade que já está subdimensionada face ao número de ativos, o padrão comum na maioria das operações no upstream angolano.

Um estudo peer-reviewed publicado na revista Sensors (MDPI), um caso de estudo em indústria pesada sobre manutenção preditiva baseada em sensores com redução de falsos alarmes, documenta exatamente este problema: o método proposto pelos autores reduziu falsos alarmes em 90,25% em relação a um detetor de outliers isolado, precisamente porque a versão sem essa camada adicional de correlação gerava alarmes a mais para serem tratados com credibilidade pela equipa de operação. O ponto central do artigo, e que vale a pena reter, não é o número em si — é o mecanismo: excesso de falsos positivos não é apenas desperdício de tempo, é o que leva uma equipa a começar a ignorar alarmes, incluindo o alarme verdadeiro que aparece três semanas depois escondido no meio de ruído.

Isto é fadiga de alarme, o mesmo fenómeno que a literatura clínica documenta em unidades de cuidados intensivos — e a sala de controlo de uma unidade de processo não é assim tão diferente de uma UTI nesse aspeto: quando a taxa de falsos positivos é alta, a resposta humana racional é começar a desconfiar do sistema, não do equipamento.

Porque é que a linha de base estatística simples ganha, com frequência

Isto é o argumento central deste artigo e a parte que a maioria dos fornecedores de "IA preditiva" prefere não discutir: um modelo de controlo estatístico de processo (SPC) — carta de controlo, média móvel exponencialmente ponderada (EWMA), limites baseados em desvio-padrão sobre a tendência de vibração — é frequentemente competitivo com, ou superior a, um modelo de machine learning mais complexo, quando os dados disponíveis são limitados, ruidosos ou têm poucos exemplos de degradação real.

Um capítulo académico de referência sobre a aplicação de métodos de controlo estatístico de qualidade em manutenção preditiva ("Predictive Maintenance 4.0") explora exatamente esta ideia: cartas de controlo SPC, incluindo EWMA — desenhadas há décadas para deteção de pequenos desvios de processo — aplicam-se diretamente à monitorização de condição, e a literatura mais recente tende para arquiteturas híbridas (SPC a montante, ML só onde adiciona valor comprovado), não para substituir uma pela outra.

A razão prática por trás disto é simples de explicar a um diretor financeiro: um modelo de machine learning com poucos parâmetros e uma carta de controlo bem calibrada tende a generalizar melhor com poucos dados do que uma rede neuronal ou um ensemble complexo, que precisa de muito mais exemplos para não ficar a aprender ruído específico do período de treino (overfitting). Quando o histórico disponível é de meses, não de anos, e quando cada bomba tem a sua própria assinatura de vibração "normal", a complexidade adicional de um modelo sofisticado frequentemente não se traduz em menos falsos positivos — traduz-se só em menos explicabilidade para a equipa de manutenção que tem de decidir se vai ou não a campo.

Uma checklist honesta antes de comprar

Pergunta	Se a resposta for "não"
Já existe recolha consistente de vibração/temperatura/corrente, com cadência regular, há pelo menos alguns meses?	Comece pelo Nível 1 (limites físicos, ISO 20816) antes de falar em ML
Existem registos de falha rotulados e alinhados no tempo com os dados de sensor, para múltiplos eventos do mesmo tipo de equipamento?	Não tem dados para um modelo supervisionado de previsão de falha — foque-se em deteção de anomalias
A equipa de fiabilidade tem capacidade para investigar todos os alarmes de um piloto, sem os ignorar por sobrecarga?	O primeiro projeto vai morrer por fadiga de alarme antes de provar valor
Já testou uma carta de controlo simples (EWMA, limites por desvio-padrão) sobre a mesma série temporal?	Faça esse teste primeiro — é dias de trabalho, não meses, e dá uma referência honesta contra a qual medir qualquer modelo mais complexo
O ativo é crítico e caro o suficiente para justificar o custo de engenharia de um pipeline de dados dedicado?	Uma bomba de reserva barata não justifica o mesmo investimento de engenharia que um compressor de exportação sem redundância

Onde isto realmente compensa

Não é um argumento contra machine learning em manutenção — é um argumento contra comprá-lo antes de ter a base de dados que o sustente. Faz sentido investir em modelos mais sofisticados quando: há uma frota de ativos semelhantes (várias bombas do mesmo modelo, várias unidades de compressão), o que permite aprender padrões de degradação partilhados mesmo com poucas falhas por unidade; existe já uma camada de recolha de dados madura e fiável (não uma prova de conceito de três meses); e há uma equipa de fiabilidade com capacidade de resposta e disciplina para tratar os alarmes gerados, incluindo os falsos, sem perder confiança no sistema.

A Wise Hustlers constrói e opera o módulo de manutenção e MRO do seu próprio ERP para operações de petróleo e gás — ordens de trabalho, histórico de ativos, planos de manutenção preventiva e o registo de eventos de campo que qualquer modelo de deteção de anomalias precisa como matéria-prima. A parte mais subestimada do projeto nunca é o algoritmo. É a canalização de dados: garantir que a leitura de vibração de um sensor sem fio chega limpa, com timestamp correto, associada ao ativo certo, e cruzada com a ordem de trabalho que confirma se algo realmente falhou naquele intervalo. Sem essa disciplina de dados, nenhum modelo — simples ou complexo — tem por onde aprender. É esse trabalho de engenharia de dados e integração de modelos com sistemas operacionais existentes que fazemos através do nosso serviço de machine learning, normalmente a começar pela deteção de anomalias sobre dados que a operação já recolhe, antes de qualquer conversa sobre modelos preditivos mais avançados.

Perguntas frequentes

Sem histórico de falhas, ainda vale a pena instalar sensores de vibração?

Sim — mas o objetivo imediato não é "prever falhas", é ter uma linha de base fiável de comportamento normal por ativo. Essa linha de base é o pré-requisito tanto para deteção de anomalias como para, mais tarde, qualquer modelo supervisionado, se e quando existir histórico de falhas suficiente.

Um modelo de deteção de anomalias substitui a análise de vibração feita por um técnico de fiabilidade experiente?

Não. Ele sinaliza que algo mudou; identificar o que mudou — desalinhamento, desgaste de rolamento, cavitação, folga — continua a exigir interpretação humana do espectro de vibração, ou uma camada de diagnóstico adicional treinada especificamente para isso.

Quanto tempo de histórico é preciso antes de um projeto destes fazer sentido?

Depende do ciclo natural de degradação do equipamento, mas como referência prática: menos de alguns meses de dados consistentes normalmente não chega nem para uma carta de controlo robusta, quanto mais para um modelo de anomalias fiável. Comece a recolher agora, mesmo que o projeto de ML só arranque depois.

Vale a pena comparar plataformas como Augury, SKF ou System 1 da Baker Hughes com uma solução construída à medida?

Depende da escala e da homogeneidade da frota. Plataformas como a Augury (entretanto também integrada na oferta System 1 da Baker Hughes) ou a SKF Enlight trazem sensores, infraestrutura e modelos já calibrados sobre milhares de máquinas de fabricantes semelhantes — vantagem real para equipamento standard. Uma solução à medida compensa quando o equipamento, o regime operacional ou a integração com o ERP e as ordens de trabalho existentes são específicos o suficiente para que um modelo genérico não sirva bem.