Gemelo digital para mantenimiento predictivo: guía

El mantenimiento predictivo con gemelo digital consiste en usar un modelo vivo de una máquina para prever cuándo fallará, en lugar de esperar a la avería o sustituir piezas según un calendario fijo. En este artículo verás cómo encajan los datos de estado, el modelo y la ruta de datos MQTT, y construirás un pequeño ejemplo funcional que detecta la deriva de un motor simulado.

De reactivo a predictivo: dónde encajan los gemelos

Las estrategias de mantenimiento suelen evolucionar por etapas:

Estrategia	Desencadenante	Fortaleza	Debilidad
Reactiva	La máquina se avería	Sin coste de monitorización	Paradas no planificadas, daños secundarios
Preventiva	Calendario u horas de funcionamiento	Fácil de planificar	Sustituye piezas sanas y aun así no detecta fallos tempranos
Basada en la condición	Un valor medido supera un límite	Actúa según el estado real	Los límites son estáticos y a menudo saltan tarde
Predictiva	Un modelo prevé la degradación	Planifica el trabajo antes del fallo	Requiere histórico de datos y esfuerzo de modelado

Un gemelo digital es el lugar natural para el mantenimiento predictivo porque ya contiene el estado en vivo de la máquina, su configuración y su contexto (carga, velocidad, producto, condiciones ambientales). Un valor de vibración aislado dice poco. Una vibración que aumenta mientras la carga es constante y la temperatura del rodamiento sube cuenta una historia. El gemelo aporta ese contexto; el modelo interpreta la historia. Para una introducción a los conceptos de gemelo, consulta la guía de tecnología de gemelo digital.

Los tres ingredientes del mantenimiento predictivo con gemelo digital

1. Datos de estado

Las señales dependen de los modos de fallo que te interesen:

Equipos rotativos (motores, bombas, ventiladores, husillos): vibración (RMS, pico, bandas espectrales), temperatura de rodamientos, corriente del motor
Hidráulica y neumática: presión, caudal, tasa de fugas, tiempos de ciclo
Procesos térmicos (hornos, intercambiadores de calor): temperaturas, potencia de calentamiento, tiempo hasta alcanzar la consigna
Herramientas de corte: carga del husillo, número de ciclos, emisión acústica

Parte de un análisis modal de fallos y efectos (AMFE) del activo. Si un modo de fallo no se puede observar en ninguna señal que puedas medir, ningún modelo lo predecirá.

2. Contexto operativo

El mismo nivel de vibración puede ser normal a plena velocidad y alarmante en vacío. El gemelo debe conocer el estado operativo, la velocidad, la carga y el tipo de producto para que los modelos comparen situaciones equivalentes. Por eso los datos de estado y el estado de producción deben compartir la misma columna vertebral de datos.

3. El modelo

Los modelos van de lo sencillo a lo sofisticado:

Líneas base estadísticas: una media y una desviación típica móviles por estado operativo, con alarma ante desviaciones sostenidas
Extrapolación de tendencias: ajustar una tendencia a un indicador de degradación y estimar cuándo cruzará un umbral de fallo (una estimación básica de la vida útil remanente)
Modelos físicos: frecuencias de defectos de rodamientos, modelos térmicos, ecuaciones de desgaste
Machine learning: detección de anomalías o clasificación de fallos entrenadas con datos históricos, que se trata con más detalle en gemelos digitales con IA

La mayoría de los equipos obtienen valor real de las dos primeras opciones mucho antes de necesitar machine learning.

Arquitectura: transmitir datos de estado por MQTT

Una arquitectura práctica mantiene débilmente acoplados el edge, el transporte y la analítica:

Edge: los sensores o gateways calculan características localmente (RMS de vibración en un segundo en lugar de formas de onda brutas a 10 kHz) y las publican por MQTT. Las formas de onda brutas se pueden capturar bajo demanda y almacenar en el edge.
Broker: un broker MQTT central distribuye el flujo de características. Un broker MQTT gestionado mantiene disponible esta columna vertebral sin que tu equipo tenga que operar servidores.
Servicios del gemelo y de modelos: suscriptores que mantienen el estado del activo, ejecutan los modelos y publican los resultados (índice de salud, indicador de anomalía, vida remanente estimada) de vuelta en MQTT en topics separados.
Histórico: un suscriptor escribe las características y las salidas de los modelos en una base de datos de series temporales para entrenamiento y auditorías.
Acción: los paneles, el visor del gemelo digital 3D y tu GMAO (sistema de gestión del mantenimiento asistido por ordenador) consumen los topics de salud. La integración con el GMAO es un pequeño suscriptor que crea órdenes de trabajo a través de su API.

Una estructura de topics que sigue la jerarquía de equipos mantiene todo ordenado:

connectmq/plant1/machining/line2/spindle3/condition    características desde el edge
connectmq/plant1/machining/line2/spindle3/state        en marcha, en espera, velocidad, carga
connectmq/plant1/machining/line2/spindle3/health       salida del modelo

Publicar la salida del modelo en MQTT, en lugar de limitarse a escribirla en una base de datos, significa que todos los consumidores (visor del gemelo, servicio de alertas, puente con el GMAO) ven los cambios de salud en tiempo real. Usa QoS 1 en los topics de salud y alarmas para que no se pierdan sin aviso; el artículo sobre niveles de QoS de MQTT explica las ventajas e inconvenientes.

Práctica: detectar la deriva de un motor simulado

El siguiente ejemplo en Python se ejecuta contra el servidor MQTT público gratuito en broker.connectmq.com. Un script simula un motor cuya vibración se degrada lentamente; el segundo actúa como modelo de salud del gemelo, calculando una línea base móvil y una sencilla estimación del tiempo hasta el umbral. Usa solo datos simulados, ya que el servidor público es legible por todos y es solo para pruebas y prototipos.

El simulador:

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = "pdm-7f3a"  # cámbialo por tu propio id único
TOPIC = f"connectmq/demo/{RUN_ID}/plant1/line2/motor1/condition"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"motor-sim-{uuid.uuid4().hex[:6]}")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

wear = 0.0
while True:
    wear += random.uniform(0.0005, 0.002)  # degradación lenta
    rms = 1.2 + wear + random.gauss(0, 0.05)
    temp = 45 + wear * 8 + random.gauss(0, 0.3)
    client.publish(TOPIC, json.dumps({"vibRmsMmS": round(rms, 3), "bearingTempC": round(temp, 2), "ts": time.time()}))
    time.sleep(1)

El modelo de salud:

import json
import time
import uuid
from collections import deque

import paho.mqtt.client as mqtt

RUN_ID = "pdm-7f3a"
BASE = f"connectmq/demo/{RUN_ID}/plant1/line2/motor1"
ALARM_RMS = 2.8   # mm/s, límite ilustrativo para este ejemplo
WINDOW = 120      # muestras usadas para la tendencia

history = deque(maxlen=WINDOW)


def slope(points):
    n = len(points)
    xs = [p[0] for p in points]
    ys = [p[1] for p in points]
    mx, my = sum(xs) / n, sum(ys) / n
    den = sum((x - mx) ** 2 for x in xs)
    return 0.0 if den == 0 else sum((x - mx) * (y - my) for x, y in zip(xs, ys)) / den


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/condition", qos=1)
    print("Health model subscribed:", reason_code)


def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    history.append((data["ts"], data["vibRmsMmS"]))
    if len(history) < 30:
        return
    current = sum(v for _, v in list(history)[-10:]) / 10
    rate = slope(history)  # mm/s por segundo
    hours_left = None
    if rate > 0 and current < ALARM_RMS:
        hours_left = round((ALARM_RMS - current) / rate / 3600, 2)
    status = "alarm" if current >= ALARM_RMS else "warning" if hours_left is not None and hours_left < 0.5 else "ok"
    health = {"status": status, "vibRmsAvg": round(current, 3), "hoursToLimit": hours_left, "ts": time.time()}
    client.publish(f"{BASE}/health", json.dumps(health), qos=1, retain=True)
    print(health)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"health-model-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Como el simulador se degrada rápido, verás cómo la estimación del tiempo hasta el límite baja en pocos minutos. En una planta real, la misma lógica se ejecuta a lo largo de días o semanas, con límites tomados de normas, recomendaciones del fabricante o tu propio histórico de fallos. El mensaje de salud retenido hace que un visor del gemelo abierto más tarde muestre de inmediato el último diagnóstico.

Lista de comprobación para el despliegue

Elige un número reducido de activos críticos en los que las paradas no planificadas salgan caras.
Enumera sus modos de fallo y las señales que revelan cada uno.
Calcula las características en el edge; publica características, no formas de onda brutas, por MQTT.
Publica el estado operativo junto a los datos de condición para que los modelos puedan segmentar por estado.
Empieza con líneas base y estimaciones de tendencia; registra cada intervención de mantenimiento para entrenar modelos más adelante.
Publica la salida de los modelos en topics de salud dedicados con QoS 1 y estado retenido.
Conecta los topics de salud con las personas que actúan: visor del gemelo, alertas y GMAO.
Revisa las falsas alarmas cada mes y ajusta los límites antes de añadir complejidad.

Como primera capa rápida de protección, las reglas de alerta por umbral y el registro de alertas del portal de ConnectMQ pueden señalar un valor que supera un límite fijo mientras tus modelos maduran. La previsión en sí se ejecuta en tus propios servicios, que se conectan a ConnectMQ como clientes MQTT normales.

Errores habituales

Sin histórico de fallos. El machine learning necesita ejemplos de fallos. Empieza con física y tendencias y registra con cuidado cada reparación.
Ignorar el estado operativo. Comparar la vibración en vacío con la de plena carga produce falsas alarmas constantes.
Enviar datos brutos de alta frecuencia a la nube. Es caro e innecesario para la mayoría de los modelos. Extrae las características en el edge.
Alertas sin responsable. Una predicción sin un proceso de órdenes de trabajo no cambia nada.

El mantenimiento predictivo encaja de forma natural con el gemelo digital de fábrica, donde el estado de salud puede mostrarse en cada máquina de la vista de línea.

Empieza a transmitir datos de salud de máquinas con ConnectMQ

Pasa del servidor público gratuito a un broker privado cuando intervengan equipos reales. ConnectMQ ofrece una columna vertebral MQTT segura sobre TLS con funcionalidades de MQTT 5 como la caducidad de mensajes y, en los planes Serverless de pago, las suscripciones compartidas. Crea tu broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conecta tu primer gateway de monitorización de condición.

Preguntas frecuentes

¿Qué es el mantenimiento predictivo con gemelo digital?

Es el uso de un modelo digital vivo de un activo, alimentado con datos de estado y de operación, para prever su degradación y programar el mantenimiento antes de que se produzca un fallo.

¿Necesito machine learning para el mantenimiento predictivo?

Al principio no. Las líneas base estadísticas y la extrapolación de tendencias suelen detectar los patrones de degradación más comunes. El machine learning resulta útil cuando dispones de suficiente histórico etiquetado.

¿Debo enviar formas de onda de vibración brutas por MQTT?

Normalmente no de forma continua. Calcula en el edge características como el RMS y las energías por banda y publícalas, capturando las formas de onda brutas solo bajo demanda para el diagnóstico.

¿Dónde se ejecutan los modelos predictivos?

En tus propios servicios, en el edge o en la nube, que se suscriben a los topics de condición del broker y publican sus resultados de vuelta como topics de salud.

Gemelo digital para mantenimiento predictivo: anticipar fallos con datos en vivo