Manutenção Preditiva com IoT: Guia Prático do Sensor ao Modelo

Projetos de manutenção preditiva com IoT dão certo ou errado por detalhes nada glamorosos: o sensor certo no ativo certo, features sensatas calculadas na borda e um fluxo de dados que continue funcionando por anos. Este guia percorre cada camada, da escolha dos sensores ao transporte dos dados de condição via MQTT e à construção de modelos que avisam antes de uma falha. Ao final você terá uma arquitetura de referência, código de borda funcional e um plano passo a passo para o seu primeiro ativo.

O que manutenção preditiva realmente significa

As estratégias de manutenção formam um espectro. A manutenção corretiva conserta as coisas quando quebram. A manutenção preventiva troca peças em um cronograma fixo, precisem ou não. A manutenção baseada em condição age quando um valor medido ultrapassa um limite. A manutenção preditiva vai um passo além: usa tendências e padrões nos dados de condição para estimar que uma falha está se desenvolvendo, idealmente cedo o bastante para encaixar o reparo em uma parada programada.

O valor vem do momento certo. Um rolamento trocado em uma parada planejada de fim de semana custa uma peça e algumas horas. O mesmo rolamento falhando durante a produção custa a peça, a parada não planejada, possivelmente o eixo ou o motor, e o refugo produzido enquanto a máquina se degradava. A diferença entre monitoramento de condição e predição é explicada em detalhes em monitoramento de condição vs. manutenção preditiva.

Escolha primeiro os ativos e os modos de falha

Não comece pelos sensores. Comece por uma lista curta de ativos em que uma falha inesperada dói e, para cada um, anote como ele falha. O modo de falha determina a medição.

Equipamentos rotativos com modos de falha sensíveis à vibração costumam ser o melhor primeiro alvo: motores, bombas, ventiladores e redutores. Veja sensores de monitoramento de vibração para escolher acelerômetros e monitoramento de corrente de motores para assinaturas elétricas.

A arquitetura de manutenção preditiva com IoT

Uma arquitetura confiável tem quatro camadas:

1. Sensoriamento. Acelerômetros, sondas de temperatura e sensores de corrente montados no ativo, mais o contexto operacional do CLP (velocidade, carga, estado de operação).
2. Processamento na borda. Um gateway ou microcontrolador amostra os sinais brutos em alta taxa e os reduz a features: velocidade RMS, aceleração de pico, fator de crista, curtose, energias por banda, temperatura. Formas de onda brutas de vibração são grandes; features ocupam algumas centenas de bytes.
3. Transporte. Features e contexto são publicados via MQTT em um broker. Análise, historiadores, dashboards e alertas assinam cada um de forma independente.
4. Análise. Um serviço armazena as séries temporais, estabelece linhas de base, detecta anomalias e estima tendências. Os resultados voltam via MQTT como índices de saúde e alertas.

O broker no meio é o que torna isso extensível. Você pode começar com uma verificação simples de limite e adicionar um serviço de machine learning depois, sem mexer nos sensores. Se o papel do broker não for familiar, comece por o que um broker MQTT faz.

Features na borda: calcule localmente, publique resumos

Enviar vibração bruta a 10 kHz pela rede o dia inteiro raramente é necessário. Calcule features na borda em um cronograma fixo, por exemplo uma captura de um segundo a cada minuto, e publique o resumo. O script abaixo roda em um Raspberry Pi ou PC industrial com uma função de leitura do acelerômetro fornecida por você. Ele usa NumPy para a matemática.

import json
import time

import numpy as np
import paho.mqtt.client as mqtt

TOPIC = "connectmq/demo/v4c9e2/plant1/utilities/pump03/condition"
SAMPLE_RATE = 10_000   # Hz
CAPTURE_SECONDS = 1.0


def read_accelerometer(n_samples):
    """Replace with your ADC / sensor driver. Returns acceleration in g."""
    t = np.arange(n_samples) / SAMPLE_RATE
    signal = 0.3 * np.sin(2 * np.pi * 49.5 * t) + 0.05 * np.random.randn(n_samples)
    return signal


def features(acc_g):
    acc = acc_g - acc_g.mean()
    rms = float(np.sqrt(np.mean(acc ** 2)))
    peak = float(np.max(np.abs(acc)))
    kurt = float(np.mean(acc ** 4) / (np.mean(acc ** 2) ** 2))
    spectrum = np.abs(np.fft.rfft(acc)) / len(acc)
    freqs = np.fft.rfftfreq(len(acc), 1 / SAMPLE_RATE)
    def band(lo, hi):
        mask = (freqs >= lo) & (freqs < hi)
        return float(np.sqrt(np.sum(spectrum[mask] ** 2)))
    return {
        "rms_g": round(rms, 4),
        "peak_g": round(peak, 4),
        "crest": round(peak / rms, 2) if rms else None,
        "kurtosis": round(kurt, 2),
        "band_10_1k": round(band(10, 1000), 4),
        "band_1k_5k": round(band(1000, 5000), 4),
        "dominant_hz": round(float(freqs[np.argmax(spectrum[1:]) + 1]), 1),
    }


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pump03-edge-v4c9e2")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

while True:
    acc = read_accelerometer(int(SAMPLE_RATE * CAPTURE_SECONDS))
    payload = features(acc)
    payload.update({"running": True, "temp_c": 41.8, "ts": int(time.time())})
    client.publish(TOPIC, json.dumps(payload), qos=1)
    time.sleep(60)

Por que essas features: o RMS acompanha a energia total de vibração e responde a desbalanceamento e folgas; curtose e fator de crista sobem cedo com falhas de impacto, como defeitos de rolamento; a banda alta capta a atividade de rolamentos e engrenagens, enquanto a banda baixa reflete efeitos da velocidade de rotação. Publique sempre a flag running e o contexto de carga, porque vibração em vazio e em carga plena não são comparáveis.

Dos limites aos modelos

Suba a escada degrau por degrau; cada etapa precisa de mais dados e entrega avisos mais cedo.

1. Limites absolutos. Use as orientações de severidade de vibração das normas aplicáveis ou do fabricante do equipamento como nível inicial de alarme. Simples, explicável e pega problemas grosseiros.
2. Desvio da linha de base. Registre algumas semanas de dados saudáveis por ativo e estado operacional e alerte quando as features se afastarem várias vezes o desvio-padrão dessa linha de base. Isso se adapta ao normal de cada máquina.
3. Detecção de anomalias multivariada. Modelos como isolation forests ou autoencoders olham todas as features juntas e sinalizam combinações incomuns mesmo quando nenhum valor isolado é extremo. O artigo sobre machine learning para manutenção preditiva cobre esses modelos em profundidade.
4. Vida útil remanescente. Com histórico suficiente de operação até a falha, modelos de regressão estimam o tempo até a falha. É a etapa mais valiosa e a que mais exige dados, e muitas plantas nunca precisam dela.

Um subscriber mínimo de linha de base fica assim:

import json
import statistics
from collections import deque

import paho.mqtt.client as mqtt

TOPIC = "connectmq/demo/v4c9e2/plant1/utilities/+/condition"
baseline = {}  # ativo -> deque de valores rms enquanto em operação


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(TOPIC, qos=1)


def on_message(client, userdata, msg):
    asset = msg.topic.split("/")[-2]
    data = json.loads(msg.payload)
    if not data.get("running"):
        return
    window = baseline.setdefault(asset, deque(maxlen=2000))
    if len(window) > 200:
        mean, sd = statistics.fmean(window), statistics.pstdev(window) or 1e-9
        z = (data["rms_g"] - mean) / sd
        if z > 4:
            alert = {"asset": asset, "feature": "rms_g", "value": data["rms_g"], "z": round(z, 1)}
            client.publish(msg.topic.replace("/condition", "/health"), json.dumps(alert), qos=1)
    window.append(data["rms_g"])


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pm-baseline-v4c9e2")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Em produção, congele a linha de base após o período de aprendizado em vez de atualizá-la continuamente, ou a degradação lenta será absorvida como "normal".

Armadilhas que afundam projetos de manutenção preditiva

• Montagem. Um ímã sobre uma carcaça pintada e curva dá resposta ruim em alta frequência. Fixação por prisioneiro ou uma superfície plana bem preparada importa mais que o preço do sensor.
• Falta de contexto operacional. Sem velocidade e carga, uma mudança de feature causada por um produto diferente parece uma falha.
• Falta de ciclo de feedback. Todo alerta precisa terminar com uma constatação da manutenção registrada nele. Sem isso, os modelos não podem ser validados nem melhorados.
• Ativos demais de uma vez. Comece com alguns ativos críticos, comprove uma falha evitada e depois escale.
• Ignorar a conectividade. Gateways ficam offline. Use mensagens Last Will do MQTT e monitore a saúde dos sensores, para que um sensor silencioso não seja lido como uma máquina saudável.

Plano passo a passo para o primeiro ativo

1. Escolha um ativo rotativo crítico com histórico conhecido de falhas.
2. Liste os modos de falha e escolha os sensores de acordo.
3. Instale os sensores e um gateway de borda; publique features a cada minuto em um topic de teste no servidor MQTT público gratuito enquanto valida o pipeline.
4. Migre para um broker privado antes de conectar ativos de produção.
5. Colete de duas a quatro semanas de dados de linha de base com contexto operacional.
6. Ative alertas de limite e de linha de base; encaminhe-os para a equipe de manutenção.
7. Registre as constatações de cada alerta e revise mensalmente.
8. Expanda para ativos semelhantes e adicione modelos mais avançados apenas onde aumentarem o tempo de aviso.

Rodando o fluxo de dados no ConnectMQ

Dados de condição são um fluxo de longa duração: sensores publicam por anos, e novos consumidores aparecem conforme o programa amadurece. Um broker MQTT gerenciado do ConnectMQ cuida desse hub sem que sua equipe opere servidores. Os gateways conectam via TLS na porta 8883 com credenciais emitidas, a visão de dispositivos agrupa os ativos por nível ISA-95, e as regras de alerta por limite do portal podem cobrir os limites absolutos simples enquanto seus próprios serviços rodam linhas de base e modelos. Ferramentas de análise, historiadores, fluxos Node-RED e um gêmeo digital do ativo se conectam como clientes MQTT comuns. Para o programa mais amplo, leia o guia de manufatura inteligente.

Comece com o ConnectMQ

Cadastre-se em app.connectmq.com, crie um broker Serverless gratuito sem cartão de crédito, conecte um gateway de borda e comece a construir a linha de base do seu primeiro ativo de manutenção preditiva.

Perguntas frequentes

Qual é o melhor primeiro sensor para manutenção preditiva?

Para equipamentos rotativos, um sensor de vibração (acelerômetro) dá o aviso mais precoce para as falhas mecânicas mais comuns. Adicione temperatura e corrente como sinais complementares.

Devo enviar dados brutos de vibração via MQTT?

Geralmente não. Calcule features na borda e publique resumos; capture formas de onda brutas apenas sob demanda ou quando uma anomalia for detectada, e mantenha-as dentro do limite de tamanho de mensagem do seu plano.

Quanto histórico preciso antes de as predições funcionarem?

A linha de base e a detecção de anomalias podem começar após algumas semanas de dados saudáveis. Modelos de vida útil remanescente precisam de histórico de operação até a falha, que leva muito mais tempo para ser coletado.

A manutenção preditiva funciona sem machine learning?

Sim. Limites bem escolhidos e alertas de desvio da linha de base entregam boa parte do valor. O machine learning adiciona uma detecção mais precoce e refinada depois que o básico está implantado.