Manutenção Preditiva com Machine Learning: Features, Rótulos e Modelos

A manutenção preditiva com machine learning usa dados de condição das máquinas para estimar se uma falha está a caminho, de modo que a manutenção possa ser planejada antes de uma quebra, e não depois dela. Neste guia você vai aprender a coletar os sinais certos via MQTT, transformá-los em features e rótulos, escolher um primeiro modelo e validá-lo de uma forma que reflita como ele vai se comportar no chão de fábrica.

O que o machine learning acrescenta à manutenção

A maioria das plantas já faz algum tipo de monitoramento de condição: um alarme de vibração em um nível fixo, um limite de temperatura em um mancal. Esses limiares estáticos funcionam para falhas óbvias, mas deixam passar degradações lentas que envolvem vários sinais e muitas vezes disparam tarde. O machine learning acrescenta duas coisas. Ele consegue combinar vários sinais fracos em um indicador mais forte e consegue aprender como é o "normal" de cada máquina sob diferentes cargas, em vez de aplicar um único limite a todas.

Também vale deixar claros os limites. Um modelo só aprende padrões de falha que estão presentes nos seus dados. Se um tipo de máquina falhou duas vezes em cinco anos, um classificador supervisionado de falhas não vai aprender muita coisa; uma abordagem de detecção de anomalias ou de tendência de degradação se encaixa melhor. Enquadrar o problema corretamente importa mais do que escolher o algoritmo.

Enquadrando o problema

Muitas equipes começam com detecção de anomalias porque ela não precisa de rótulos e passam para a classificação depois de coletar eventos rotulados suficientes. O artigo sobre detecção de anomalias em IoT cobre esse primeiro passo, e o de previsão de vida útil remanescente cobre o enquadramento por regressão.

Coletando dados de condição via MQTT

Os sinais devem acompanhar os modos de falha que importam para você. Para equipamentos rotativos, como as bombas de uma estação de saneamento ou os transportadores de uma mineradora, o conjunto usual é features de vibração, temperatura de mancal ou de enrolamento, corrente do motor e velocidade. Para sistemas hidráulicos e pneumáticos, pressão, vazão e tempos de ciclo. Inclua sempre o contexto de operação, como carga, setpoint de velocidade e produto, porque um modelo que não conhece a carga vai confundir um lote pesado com uma falha em desenvolvimento.

Um layout MQTT prático publica as features por ativo sob uma hierarquia, com timestamps de origem:

connectmq/plant1/line2/pump3/condition   {"ts":..., "vib_rms":..., "vib_peak":..., "bearing_temp":..., "current":..., "load":...}
connectmq/plant1/line2/pump3/events      {"ts":..., "type":"maintenance", "action":"bearing replaced"}

Calcule as features de vibração na borda em vez de transmitir formas de onda em kHz. Uma janela de um segundo gera RMS, pico, fator de crista e algumas energias de bandas espectrais, o que é pequeno o bastante para publicar a cada poucos segundos. O topic de eventos é tão importante quanto a telemetria; sem as ações de manutenção e as falhas registradas, não há como construir rótulos. O guia de rotulagem de dados de sensores em séries temporais mostra como capturar esses eventos a partir dos operadores.

Engenharia de features para manutenção preditiva com machine learning

Leituras brutas raramente são as melhores entradas para um modelo. A degradação aparece como mudanças de nível, variabilidade e tendência ao longo do tempo, por isso as features costumam ser calculadas sobre janelas móveis.

• Features de nível: média móvel do RMS de vibração, da temperatura, da corrente.
• Features de variabilidade: desvio padrão móvel, pico a pico, fator de crista.
• Features de tendência: inclinação de um ajuste linear sobre as últimas horas ou dias.
• Features relativas: elevação de temperatura acima da ambiente, corrente por unidade de carga, vibração comparada com a linha de base da própria máquina.
• Features espectrais: energia em bandas ligadas às frequências de defeito de rolamentos ou a desbalanceamento.
• Contexto de operação: carga, velocidade, horas de operação desde a última manutenção.

Normalize por ativo quando as máquinas forem diferentes. Uma bomba que sempre vibrou um pouco mais que as vizinhas não está necessariamente se degradando; o que importa é a mudança em relação ao seu próprio histórico.

Construindo rótulos sem vazamento

Em um enquadramento de classificação, um rótulo comum é "vai falhar nas próximas H horas". Você pega cada timestamp de falha e marca como positivas as janelas dentro do horizonte anterior a ela, e todo o resto como negativo. Três regras mantêm os rótulos honestos:

1. Exclua por um curto período o intervalo logo após a manutenção, porque as leituras durante o amaciamento não são representativas.
2. Descarte as janelas que contêm a própria falha, senão o modelo aprende a reconhecer uma máquina parada.
3. Nunca calcule features com dados posteriores ao timestamp da janela. Janelas móveis centralizadas são uma fonte clássica de vazamento.

Um exemplo funcional em Python

O script abaixo gera dados de condição simulados para várias bombas com degradação ocasional, publica-os no servidor MQTT público (adequado para testes e protótipos, não para dados de produção), coleta-os de volta com um assinante e treina um classificador gradient boosting avaliado em bombas que ele nunca viu durante o treinamento. Na prática, o coletor leria do seu historiador.

import json
import random
import time
import uuid

import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.metrics import classification_report

BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1"
rows = []


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    p["asset"] = msg.topic.split("/")[-2]
    rows.append(p)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe(f"{PREFIX}/+/condition", qos=1)
client.loop_start()
time.sleep(1)

# Simula 6 bombas x 600 passos; algumas se degradam até a falha no final
for asset in range(6):
    fails = asset % 2 == 0
    for step in range(600):
        wear = max(0, step - 400) / 200 if fails else 0
        body = {
            "step": step,
            "vib_rms": round(1.0 + 1.5 * wear ** 2 + random.gauss(0, 0.08), 3),
            "bearing_temp": round(55 + 12 * wear + random.gauss(0, 0.5), 2),
            "current": round(14 + 1.5 * wear + random.gauss(0, 0.2), 2),
            "load": round(random.uniform(0.6, 1.0), 2),
            "failed_at": 600 if fails else None,
        }
        client.publish(f"{PREFIX}/pump{asset}/condition", json.dumps(body), qos=0)
        time.sleep(0.11)  # fica abaixo do limite de 10 msg/s por cliente do broker público

time.sleep(3)
client.loop_stop()

df = pd.DataFrame(rows).sort_values(["asset", "step"])
HORIZON = 100
df["label"] = ((df["failed_at"].notna()) & (df["failed_at"] - df["step"] <= HORIZON)).astype(int)

feats = []
for col in ["vib_rms", "bearing_temp", "current"]:
    g = df.groupby("asset")[col]
    df[f"{col}_mean20"] = g.transform(lambda s: s.rolling(20, min_periods=5).mean())
    df[f"{col}_std20"] = g.transform(lambda s: s.rolling(20, min_periods=5).std())
    df[f"{col}_slope50"] = g.transform(lambda s: s.diff(50) / 50)
    feats += [f"{col}_mean20", f"{col}_std20", f"{col}_slope50"]
feats.append("load")
df = df.dropna(subset=feats)

# Divisão por ativo: treina nas bombas 0-3, testa nas bombas 4-5, que o modelo nunca viu
train, test = df[~df["asset"].isin(["pump4", "pump5"])], df[df["asset"].isin(["pump4", "pump5"])]
model = HistGradientBoostingClassifier(max_iter=200, learning_rate=0.05)
model.fit(train[feats], train["label"])
print(classification_report(test["label"], model.predict(test[feats]), digits=3))

Instale as dependências com pip install paho-mqtt pandas numpy scikit-learn. A execução leva vários minutos porque o simulador respeita o limite de taxa do servidor MQTT público. Com o seu próprio broker ConnectMQ, usando YOUR_USERNAME, YOUR_PASSWORD e YOUR_CLIENT_ID na porta 8883, você pode publicar a partir de muitos dispositivos em paralelo.

Escolhendo um primeiro modelo

• Árvores com gradient boosting (scikit-learn, XGBoost, LightGBM) são o padrão para features tabulares. Lidam com escalas mistas, exigem pouco ajuste e fornecem importâncias de features que os engenheiros de manutenção conseguem discutir.
• Regressão logística é uma linha de base útil e fácil de explicar.
• Isolation Forest ou autoencoders para o enquadramento de anomalias quando há poucos rótulos.
• Modelos sequenciais (LSTM, CNN 1D, transformers) somente quando você tiver muito histórico e os modelos simples tiverem estagnado.

Validando como em produção

Divisões aleatórias entre treino e teste superestimam o desempenho em séries temporais, porque janelas vizinhas são quase idênticas. Use uma divisão por tempo e, idealmente, separe ativos inteiros para verificar se o modelo generaliza para máquinas que não viu. Reporte precisão e recall no limiar de alerta que pretende usar e traduza-os em termos operacionais: quantos alarmes falsos por semana e quantas falhas detectadas com quanto tempo de antecedência. São esses os números que importam para um planejador de manutenção.

Implantando e fechando o ciclo

Um modelo implantado é só mais um cliente MQTT. Ele assina os topics de condição, pontua cada nova janela e publica um score de risco:

connectmq/plant1/line2/pump3/health   {"ts":..., "risk":0.82, "model":"pdm-gbt-1.4"}

Dashboards, conectores de CMMS e ferramentas de alerta assinam esse topic. No portal do ConnectMQ você também pode definir regras de alerta por limite sobre o valor de risco publicado, de modo que um score acima do limite escolhido apareça no log de alertas sem código extra. Registre o resultado de cada alerta como um evento, realimente os rótulos com ele e retreine periodicamente; o artigo sobre MLOps para IoT cobre esse ciclo de vida.

Para o panorama mais amplo de modelos e dispositivos trabalhando juntos, veja o guia de IA e IoT. Para uma perspectiva de gêmeo digital sobre o mesmo problema, manutenção preditiva com gêmeo digital acrescenta contexto físico à abordagem orientada a dados.

Comece com o ConnectMQ

Comece a coletar dados de condição hoje: crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e conecte seus dispositivos de borda com as credenciais geradas. O ConnectMQ oferece um broker MQTT gerenciado com TLS, explorador de topics em tempo real e alertas por limite, para que você se concentre em features e modelos, e não na operação do broker. Se mais tarde precisar de mais conexões ou isolamento, os mesmos topics migram para um plano de broker MQTT na nuvem com mais capacidade.

Perguntas frequentes

De quantos dados preciso para manutenção preditiva com machine learning?

Para previsão supervisionada de falhas, você precisa de várias falhas registradas por modo de falha, junto com os dados de condição anteriores a cada uma. Se tiver poucas falhas, comece com detecção de anomalias sobre dados normais e vá coletando eventos rotulados ao longo do caminho.

Qual é o melhor algoritmo para manutenção preditiva?

Árvores com gradient boosting sobre features móveis bem construídas são um ponto de partida forte para a maioria dos dados de condição. Modelos sequenciais profundos podem ajudar com históricos grandes, mas raramente superam boas features em conjuntos de dados pequenos.

Por que meu modelo parece preciso nos testes, mas falha em produção?

As causas mais comuns são divisões aleatórias que vazam janelas quase idênticas para o conjunto de teste, features calculadas com dados futuros e falta de contexto de operação. Use divisões por tempo ou por ativo e confira as janelas das features com cuidado.

O broker MQTT pode executar o modelo?

Não, o broker roteia mensagens. Execute o modelo como um cliente MQTT separado, na borda ou na nuvem, que assina os topics de condição e publica os scores de volta no broker.