Mantenimiento predictivo con machine learning: características, etiquetas y modelos

El mantenimiento predictivo con machine learning usa los datos de condición de las máquinas para estimar si se avecina un fallo, de modo que el mantenimiento pueda planificarse antes de una avería y no después. En esta guía aprenderás a recoger las señales adecuadas por MQTT, a convertirlas en características y etiquetas, a elegir un primer modelo y a validarlo de una forma que refleje cómo se comportará en planta.

Qué aporta el machine learning al mantenimiento

La mayoría de las plantas, sea una línea de embotellado en Querétaro o una acería en Bilbao, ya practican alguna forma de monitorización de condición: una alarma de vibración a un nivel fijo, un límite de temperatura en un rodamiento. Esos umbrales estáticos funcionan para los fallos evidentes, pero no detectan la degradación lenta y multiseñal, y a menudo saltan tarde. El machine learning aporta dos cosas. Puede combinar varias señales débiles en un indicador más fuerte, y puede aprender cómo es lo "normal" para cada máquina con distintas cargas, en lugar de aplicar un mismo límite a todas.

También conviene tener claros los límites. Un modelo solo puede aprender los patrones de fallo presentes en sus datos. Si un tipo de máquina ha fallado dos veces en cinco años, un clasificador supervisado de fallos no aprenderá gran cosa; un enfoque de detección de anomalías o de tendencia de degradación encaja mejor. Plantear bien el problema importa más que elegir el algoritmo.

Plantear el problema

Muchos equipos empiezan con la detección de anomalías porque no necesita etiquetas y pasan a la clasificación cuando han reunido suficientes eventos etiquetados. El artículo sobre detección de anomalías en IoT cubre ese primer paso, y el de predicción de la vida útil remanente cubre el planteamiento de regresión.

Recoger datos de condición por MQTT

Las señales deben seguir los modos de fallo que te interesan. Para equipos rotativos, el conjunto habitual son características de vibración, temperatura de rodamiento o de bobinado, corriente del motor y velocidad. Para sistemas hidráulicos y neumáticos, presión, caudal y tiempos de ciclo. Incluye siempre el contexto de operación, como la carga, la consigna de velocidad y el producto, porque un modelo que no conoce la carga confundirá un lote pesado con un fallo incipiente.

Una disposición MQTT práctica publica las características por activo bajo una jerarquía, con timestamps de origen:

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"}

Calcula las características de vibración en el edge en lugar de transmitir formas de onda de kHz. Una ventana de un segundo produce RMS, pico, factor de cresta y unas pocas energías por bandas espectrales, lo bastante pequeño como para publicarlo cada pocos segundos. El topic de eventos es tan importante como la telemetría; sin acciones de mantenimiento y fallos registrados, no puedes construir etiquetas. La guía sobre etiquetado de datos de sensores en series temporales muestra cómo capturar esos eventos a partir de los operadores.

Ingeniería de características para mantenimiento predictivo con machine learning

Las lecturas brutas rara vez son las mejores entradas para un modelo. La degradación se manifiesta como cambios de nivel, variabilidad y tendencia a lo largo del tiempo, así que las características suelen calcularse sobre ventanas móviles.

• Características de nivel: media móvil del RMS de vibración, la temperatura y la corriente.
• Características de variabilidad: desviación típica móvil, pico a pico, factor de cresta.
• Características de tendencia: pendiente de un ajuste lineal sobre las últimas horas o días.
• Características relativas: incremento de temperatura sobre la ambiente, corriente por unidad de carga, vibración comparada con la línea base de la propia máquina.
• Características espectrales: energía en las bandas asociadas a las frecuencias de defecto de rodamientos o al desequilibrio.
• Contexto de operación: carga, velocidad, horas de funcionamiento desde el último mantenimiento.

Normaliza por activo cuando las máquinas sean distintas. Una bomba que siempre ha vibrado algo más que sus vecinas no se está degradando necesariamente; lo que importa es el cambio respecto a su propio histórico.

Construir etiquetas sin fugas de información

Para un planteamiento de clasificación, una etiqueta habitual es "fallará en las próximas H horas". Tomas el timestamp de cada fallo y marcas como positivas las ventanas que caen dentro del horizonte anterior, y todo lo demás como negativo. Tres reglas mantienen honestas las etiquetas:

1. Excluye durante un breve periodo el tramo inmediatamente posterior al mantenimiento, porque las lecturas durante el rodaje no son representativas.
2. Descarta las ventanas que contienen el propio fallo; de lo contrario, el modelo aprende a reconocer una máquina parada.
3. Nunca calcules características con datos posteriores al timestamp de la ventana. Las ventanas móviles centradas son una fuente clásica de fugas.

Un ejemplo funcional en Python

El script siguiente genera datos de condición simulados para varias bombas con degradación ocasional, los publica en el servidor MQTT público gratuito (pensado para pruebas y prototipos, nunca para datos de producción), los recoge de vuelta con un suscriptor y entrena un clasificador de gradient boosting que se evalúa con bombas que nunca vio durante el entrenamiento. En la práctica, el recolector leería de tu historian.

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 pasos; algunas se degradan hacia el fallo al 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)  # se mantiene por debajo de los 10 msg/s por cliente del 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)

# División por activo: entrena con las bombas 0-3 y prueba con las 4-5, que el modelo nunca ha visto
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))

Instala las dependencias con pip install paho-mqtt pandas numpy scikit-learn. La ejecución tarda varios minutos porque el simulador respeta el límite de tasa del servidor público. Con tu propio broker MQTT gestionado de ConnectMQ, usando YOUR_USERNAME, YOUR_PASSWORD y YOUR_CLIENT_ID por el puerto 8883, puedes publicar desde muchos dispositivos en paralelo.

Elegir un primer modelo

• Los árboles con gradient boosting (scikit-learn, XGBoost, LightGBM) son la opción por defecto para características tabulares. Gestionan escalas mixtas, requieren poco ajuste y ofrecen importancias de características que los ingenieros de mantenimiento pueden discutir.
• La regresión logística es una línea base útil y fácil de explicar.
• Isolation Forest o autoencoders para el planteamiento de anomalías cuando escasean las etiquetas.
• Los modelos secuenciales (LSTM, CNN 1D, transformers) solo cuando tengas mucho histórico y los modelos sencillos se hayan estancado.

Validar como en producción

Las divisiones aleatorias entre entrenamiento y prueba sobrestiman el rendimiento en series temporales porque las ventanas contiguas son casi idénticas. Usa una división temporal e, idealmente, reserva activos completos para comprobar que el modelo generaliza a máquinas que no ha visto. Informa de la precisión y la exhaustividad (recall) en el umbral de alerta que piensas usar y tradúcelas a términos operativos: cuántas falsas alarmas por semana y cuántos fallos detectados con cuánta antelación. Esos son los números que le importan a un planificador de mantenimiento.

Desplegar y cerrar el ciclo

Un modelo desplegado es simplemente otro cliente MQTT. Se suscribe a los topics de condición, puntúa cada nueva ventana y publica una puntuación de riesgo:

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

Los dashboards, los conectores de GMAO (CMMS) y las herramientas de alertas se suscriben a ese topic. En el portal de ConnectMQ también puedes definir reglas de alerta por umbral sobre el valor de riesgo publicado, de modo que una puntuación por encima del límite elegido aparezca en el registro de alertas sin código adicional. Registra el resultado de cada alerta como un evento, incorpóralo a las etiquetas y vuelve a entrenar periódicamente; el artículo sobre MLOps para IoT cubre ese ciclo de vida.

Para una visión más amplia de modelos y dispositivos trabajando juntos, consulta la guía de IA e IoT. Para una perspectiva de gemelo digital sobre el mismo problema, mantenimiento predictivo con gemelo digital añade contexto físico al enfoque basado en datos. Si además quieres que el personal de planta vea la puntuación de riesgo sobre la propia máquina, un gemelo digital 3D puede colorear cada activo según su estado a partir del mismo topic health.

Empieza con ConnectMQ

Empieza hoy a recoger datos de condición: crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conecta tus dispositivos edge con las credenciales generadas. ConnectMQ te ofrece un broker MQTT gestionado con TLS, un explorador de topics en vivo y alertas por umbral, para que puedas centrarte en las características y los modelos y no en operar el broker. Si más adelante necesitas más conexiones o aislamiento, los mismos topics pasan a un plan de broker MQTT en la nube con más capacidad.

Preguntas frecuentes

¿Cuántos datos necesito para mantenimiento predictivo con machine learning?

Para la predicción supervisada de fallos necesitas varios fallos registrados por cada modo de fallo, junto con los datos de condición previos a cada uno. Si tienes pocos fallos, empieza con detección de anomalías sobre datos normales y ve recogiendo eventos etiquetados.

¿Qué algoritmo es el mejor para el mantenimiento predictivo?

Los árboles con gradient boosting sobre características móviles bien diseñadas son un punto de partida sólido para la mayoría de los datos de condición. Los modelos secuenciales profundos pueden ayudar con históricos grandes, pero rara vez superan a unas buenas características en conjuntos de datos pequeños.

¿Por qué mi modelo parece preciso en las pruebas pero falla en producción?

Las causas más comunes son las divisiones aleatorias que filtran ventanas casi idénticas al conjunto de prueba, las características calculadas con datos futuros y la falta de contexto de operación. Usa divisiones temporales o por activo y revisa con cuidado las ventanas de las características.

¿Puede el broker MQTT ejecutar el modelo?

No, el broker enruta mensajes. Ejecuta el modelo como un cliente MQTT independiente, en el edge o en la nube, que se suscribe a los topics de condición y publica las puntuaciones de vuelta en el broker.