Mantenimiento predictivo con IoT: guía práctica del sensor al modelo

Los proyectos de mantenimiento predictivo IoT triunfan o fracasan por detalles poco vistosos: el sensor correcto en el activo correcto, features sensatas calculadas en el edge y un flujo de datos que siga funcionando durante años. Esta guía recorre cada capa, desde la elección de sensores hasta el transporte de los datos de condición por MQTT y la construcción de modelos que avisan antes de una falla. Terminarás con una arquitectura de referencia, código de edge funcional y un plan paso a paso para tu primer activo.

Qué significa realmente el mantenimiento predictivo

Las estrategias de mantenimiento forman un espectro. El mantenimiento reactivo repara cuando algo se rompe. El preventivo sustituye piezas según un calendario fijo, las necesiten o no. El mantenimiento basado en condición actúa cuando un valor medido supera un límite. El predictivo va un paso más allá: usa tendencias y patrones en los datos de condición para estimar que una falla se está gestando, idealmente con la antelación suficiente para planificar la reparación en una parada programada.

El valor está en el momento. Un rodamiento sustituido durante una parada planificada de fin de semana cuesta una pieza y unas horas. Ese mismo rodamiento fallando en plena producción cuesta la pieza, la parada no planificada, posiblemente el eje o el motor, y el scrap producido mientras la máquina se degradaba. La diferencia entre monitoreo de condición y predicción se explica con más detalle en monitoreo de condición frente a mantenimiento predictivo.

Elige primero los activos y los modos de falla

No empieces por los sensores. Empieza por una lista corta de activos cuya falla inesperada duela y, para cada uno, anota cómo falla. El modo de falla determina la medición.

Los equipos rotativos con modos de falla sensibles a la vibración suelen ser el mejor primer objetivo: motores, bombas, ventiladores y reductores. Consulta sensores de monitoreo de vibraciones para elegir acelerómetros y monitoreo de corriente de motores para las firmas eléctricas.

La arquitectura IoT de mantenimiento predictivo

Una arquitectura fiable tiene cuatro capas:

1. Sensado. Acelerómetros, sondas de temperatura y sensores de corriente montados en el activo, más el contexto operativo del PLC (velocidad, carga, estado de marcha).
2. Procesamiento en el edge. Un gateway o microcontrolador muestrea las señales brutas a alta frecuencia y las reduce a features: velocidad RMS, aceleración pico, factor de cresta, curtosis, energías por banda, temperatura. Las formas de onda de vibración en bruto son grandes; las features ocupan unos cientos de bytes.
3. Transporte. Las features y el contexto se publican por MQTT en un broker. La analítica, los historiadores, los dashboards y las alertas se suscriben cada uno por su cuenta.
4. Analítica. Un servicio almacena las series temporales, establece líneas base, detecta anomalías y estima tendencias. Los resultados vuelven por MQTT como índices de salud y alertas.

El broker en el centro es lo que hace extensible el sistema. Puedes empezar con una simple comprobación de umbrales y añadir más adelante un servicio de machine learning sin tocar los sensores. Si el papel del broker te resulta nuevo, empieza por qué hace un broker MQTT.

Features en el edge: calcula localmente, publica resúmenes

Enviar vibración en bruto a 10 kHz por la red todo el día rara vez es necesario. Calcula las features en el edge con un calendario fijo, por ejemplo una captura de un segundo cada minuto, y publica el resumen. El script siguiente se ejecuta en una Raspberry Pi o un PC industrial con una función de lectura del acelerómetro que aportas tú. Usa NumPy para los cálculos.

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):
    """Sustituir por tu driver de ADC / sensor. Devuelve la aceleración en 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 qué estas features: el RMS sigue la energía global de vibración y responde al desbalanceo y a las holguras; la curtosis y el factor de cresta suben pronto con fallas de impacto, como los defectos de rodamientos; la banda alta capta la actividad de rodamientos y engranajes, mientras que la banda baja refleja los efectos de la velocidad de giro. Publica siempre el indicador running y el contexto de carga, porque la vibración en vacío y a plena carga no son comparables.

De los umbrales a los modelos

Sube la escalera paso a paso; cada peldaño necesita más datos y ofrece avisos más tempranos.

1. Límites absolutos. Usa como nivel de alarma inicial las recomendaciones de severidad de vibración de las normas aplicables o del fabricante del equipo. Es simple, explicable y detecta los problemas gruesos.
2. Desviación respecto a la línea base. Registra unas semanas de datos sanos por activo y estado operativo, y alerta cuando las features se alejen varias desviaciones estándar de esa línea base. Así se adapta a lo normal de cada máquina.
3. Detección multivariable de anomalías. Modelos como isolation forests o autoencoders analizan todas las features a la vez y señalan combinaciones inusuales aunque ningún valor aislado sea extremo. El artículo machine learning para mantenimiento predictivo los trata en profundidad.
4. Vida útil remanente. Con suficiente historial de operación hasta la falla, los modelos de regresión estiman el tiempo hasta que ocurra. Es el paso más valioso y el que más datos exige, y muchas plantas nunca lo necesitan.

Un suscriptor mínimo de línea base tiene este aspecto:

import json
import statistics
from collections import deque

import paho.mqtt.client as mqtt

TOPIC = "connectmq/demo/v4c9e2/plant1/utilities/+/condition"
baseline = {}  # activo -> deque de valores rms en marcha


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()

En producción, congela la línea base tras el periodo de aprendizaje en lugar de actualizarla continuamente; de lo contrario, la degradación lenta acabará absorbida como "normal".

Errores que hunden los proyectos de mantenimiento predictivo

• Montaje. Un imán sobre una carcasa pintada y curva da una mala respuesta en alta frecuencia. El montaje con espárrago o una superficie plana bien preparada importa más que el precio del sensor.
• Sin contexto operativo. Sin velocidad ni carga, un cambio de features causado por otro producto parece una falla.
• Sin ciclo de retroalimentación. Cada alerta debe terminar con un hallazgo de mantenimiento registrado. Sin eso, los modelos no pueden validarse ni mejorarse.
• Demasiados activos a la vez. Empieza con unos pocos activos críticos, demuestra una falla evitada y después escala.
• Ignorar la conectividad. Los gateways se desconectan. Usa mensajes Last Will de MQTT y monitorea la salud de los sensores, para que un sensor silencioso no se interprete como una máquina sana.

Plan paso a paso para el primer activo

1. Elige un activo rotativo crítico con un historial conocido de fallas.
2. Enumera sus modos de falla y elige los sensores en consecuencia.
3. Instala los sensores y un gateway de edge; publica features cada minuto en un topic de prueba del servidor MQTT público gratuito mientras validas la cadena de datos.
4. Pasa a un broker privado antes de conectar activos de producción.
5. Recoge de dos a cuatro semanas de datos de línea base con contexto operativo.
6. Activa las alertas de límites y de línea base y envíalas al equipo de mantenimiento.
7. Registra los hallazgos de cada alerta y revísalos mensualmente.
8. Amplía a activos similares y añade modelos más avanzados solo donde aporten tiempo de aviso.

El flujo de datos sobre ConnectMQ

Los datos de condición son un flujo de larga vida: los sensores publican durante años y aparecen nuevos consumidores a medida que el programa madura. Un broker MQTT gestionado de ConnectMQ se encarga de ese hub sin que tu equipo tenga que operar servidores. Los gateways se conectan por TLS en el puerto 8883 con credenciales emitidas, la vista de dispositivos agrupa los activos por nivel ISA-95 y las reglas de alerta por umbral del portal pueden cubrir los límites absolutos simples mientras tus propios servicios ejecutan líneas base y modelos. Las herramientas de analítica, los historiadores y los flujos de Node-RED se conectan como clientes MQTT normales. Para ver la salud de cada máquina en contexto, puedes llevar los índices a un gemelo digital 3D de la planta. Para el programa completo, lee la guía de manufactura inteligente.

Empieza con ConnectMQ

Regístrate en app.connectmq.com, crea un broker Serverless gratuito sin tarjeta de crédito, conecta un gateway de edge y empieza a construir la línea base de tu primer activo de mantenimiento predictivo.

Preguntas frecuentes

¿Cuál es el mejor primer sensor para mantenimiento predictivo?

Para equipos rotativos, un sensor de vibración (acelerómetro) ofrece el aviso más temprano ante las fallas mecánicas más comunes. Añade temperatura y corriente como señales de apoyo.

¿Debo enviar datos de vibración en bruto por MQTT?

Normalmente no. Calcula las features en el edge y publica resúmenes; captura las formas de onda en bruto solo bajo demanda o cuando se detecte una anomalía, y mantenlas dentro del límite de tamaño de mensaje de tu plan.

¿Cuánto historial necesito para que las predicciones funcionen?

La línea base y la detección de anomalías pueden empezar tras unas semanas de datos sanos. Los modelos de vida útil remanente necesitan historial de operación hasta la falla, que tarda mucho más en reunirse.

¿Puede funcionar el mantenimiento predictivo sin machine learning?

Sí. Unos límites bien elegidos y las alertas de desviación respecto a la línea base aportan gran parte del valor. El machine learning añade una detección más temprana y matizada una vez que lo básico está en marcha.