Predicción de la vida útil remanente (RUL) explicada

La predicción de la vida útil remanente estima cuánto tiempo puede seguir funcionando un componente o una máquina antes de alcanzar una condición de fallo. En lugar de preguntar "¿hay algo mal?", pregunta "¿cuánto tiempo nos queda?", que es la pregunta que de verdad necesitan responder los planificadores de mantenimiento. Este artículo explica las principales familias de modelos RUL, el histórico de datos que cada una requiere de los activos conectados por MQTT y cómo calcular y publicar una estimación con una incertidumbre honesta.

Qué significa vida útil remanente

La vida útil remanente (RUL, por sus siglas en inglés) es el tiempo, los ciclos o las horas de funcionamiento que le quedan a un activo hasta cruzar un umbral de fallo definido. Tres partes de esa definición merecen atención:

La unidad. El tiempo de calendario es fácil de comunicar, pero engañoso cuando el uso varía. Las horas de funcionamiento, los ciclos, las carreras o las unidades producidas suelen seguir mejor el desgaste.
El umbral de fallo. La RUL necesita un punto final definido: un nivel de vibración al que se sustituye un rodamiento, una caída de presión en un filtro a partir de la cual el caudal se vuelve inaceptable, una capacidad a la que se retira una batería. Sin él, no hay nada que predecir.
La incertidumbre. Un número único como "212 horas" oculta la confianza del modelo. Una estimación de RUL útil siempre viene acompañada de un rango.

La predicción de RUL es uno de los planteamientos del mantenimiento predictivo con machine learning. Encaja con activos que se degradan de forma gradual y repetible, como rodamientos, filtros, herramientas de corte, baterías, correas y juntas. Encaja mal con los fallos repentinos, como los fallos electrónicos.

Familias de modelos para la predicción de la vida útil remanente

Enfoque	Idea	Datos necesarios	Ventaja	Inconveniente
Estadística de fiabilidad (Weibull)	Ajustar una distribución de vida a partir de los tiempos de fallo pasados	Solo fechas de fallo y sustitución	No requiere sensores	Ignora la condición de esta unidad concreta
Modelos de tendencia de degradación	Seguir un indicador de salud y extrapolarlo hasta un umbral	Histórico de condición de la unidad actual y un umbral	Intuitivo, funciona con pocos fallos	Supone que la forma de la tendencia no cambia
Modelos basados en similitud	Comparar la trayectoria actual con trayectorias pasadas hasta el fallo	Varios históricos completos hasta el fallo	Captura trayectorias realistas	Necesita unidades históricas comparables
Regresión directa con ML	Aprender la RUL a partir de características (gradient boosting, LSTM, CNN)	Muchos históricos etiquetados hasta el fallo	Puede captar patrones complejos	Exige muchos datos y es más difícil de explicar
Modelos basados en la física	Modelar los mecanismos de desgaste (crecimiento de grietas, envejecimiento térmico)	Conocimiento de ingeniería, parámetros de materiales	Funciona antes de que existan datos	Costoso de construir por tipo de activo

La mayoría de los proyectos prácticos empiezan con un modelo de tendencia de degradación porque solo necesita el histórico de una unidad y un umbral. Los métodos de similitud y de ML llegan después, cuando la organización ha registrado suficientes ciclos de vida completos.

El histórico de datos que necesitan los modelos RUL

La predicción de RUL es más exigente con el histórico que la detección de anomalías. Planifica estos flujos de datos desde el principio, porque no se pueden reconstruir después.

Señales de condición durante toda la vida de cada unidad, no solo las últimas semanas. Características como el RMS de vibración, el incremento de temperatura o la caída de presión, muestreadas de forma coherente.
Contadores de uso como horas de funcionamiento, ciclos o producción, para que la RUL pueda expresarse en la unidad que provoca el desgaste.
Contexto de operación como la carga, la velocidad y la temperatura ambiente, para separar la degradación de los cambios de condiciones.
Eventos del ciclo de vida: instalación, sustitución, reparación y fallo, cada uno con un timestamp y el número de serie del componente. Definen dónde termina una vida y empieza la siguiente.
Definiciones de fallo: qué condición cuenta como fin de vida, por escrito y por tipo de componente.

Con MQTT, esto suele traducirse en un topic de condición, un topic de uso y un topic de eventos por activo, todos con timestamps de origen y almacenados por un suscriptor historian. La guía sobre etiquetado de datos de sensores en series temporales muestra cómo capturar los eventos del ciclo de vida y las aportaciones de los operadores junto a la telemetría para que los registros hasta el fallo estén completos.

Construir un índice de salud

La mayoría de los métodos RUL trabajan con un único indicador de salud en lugar de con muchas señales brutas. Un índice de salud (HI) combina las características en un número que cambia de forma monótona a medida que el activo se degrada. Formas habituales de construirlo:

Usar una característica con significado físico, como el RMS de vibración del rodamiento o la presión diferencial del filtro.
Combinar características normalizadas con pesos elegidos por los ingenieros.
Usar el error de reconstrucción de un modelo entrenado con datos sanos.
Usar el primer componente principal de las características a lo largo de históricos de sano a fallado.

Los buenos índices de salud comparten tres propiedades: son monótonos (rara vez retroceden), son pronosticables (el fallo ocurre en un nivel de HI coherente) y su tendencia aparece lo bastante pronto como para ser útil.

Un ejemplo de tendencia de degradación en Python

El script siguiente se suscribe a un topic de índice de salud, ajusta un modelo de degradación exponencial al histórico reciente, lo extrapola hasta un umbral de fallo, estima una banda de incertidumbre mediante bootstrap y publica la RUL de vuelta en MQTT. Un simulador integrado publica el índice de salud para que puedas ejecutarlo de extremo a extremo contra el servidor MQTT público gratuito, pensado para pruebas y no para datos de producción.

import json
import math
import random
import threading
import time
import uuid

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

BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1/fan2"
THRESHOLD = 4.0        # valor de HI definido como fin de vida (p. ej., RMS de vibración en mm/s)
MIN_POINTS = 30
history = []           # (horas_de_funcionamiento, hi)


def fit_rul(hours, hi):
    # Ajusta ln(hi - baseline) = a + b * t y despeja el cruce del umbral
    baseline = 0.9 * min(hi)
    y = np.log(np.maximum(np.array(hi) - baseline, 1e-6))
    b, a = np.polyfit(hours, y, 1)
    if b <= 0:
        return None
    t_fail = (math.log(THRESHOLD - baseline) - a) / b
    return t_fail - hours[-1]


def estimate():
    hours = np.array([h for h, _ in history[-120:]])
    hi = np.array([v for _, v in history[-120:]])
    point = fit_rul(hours, hi)
    if point is None:
        return None
    boots = []
    for _ in range(200):
        idx = np.sort(np.random.choice(len(hours), len(hours), replace=True))
        r = fit_rul(hours[idx], hi[idx])
        if r is not None:
            boots.append(r)
    low, high = np.percentile(boots, [10, 90])
    return {"rul_h": round(point, 1), "p10_h": round(low, 1), "p90_h": round(high, 1)}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/health", qos=1)


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    history.append((p["op_hours"], p["hi"]))
    if len(history) >= MIN_POINTS:
        est = estimate()
        if est:
            est.update({"ts": p["ts"], "threshold": THRESHOLD, "method": "exp-trend-v1"})
            client.publish(f"{BASE}/rul", json.dumps(est), qos=1, retain=True)
            print(est)


def simulate(pub):
    for step in range(400):
        hours = step * 5.0
        hi = 1.0 + 0.05 * math.exp(hours / 600) + random.gauss(0, 0.04)
        body = {"ts": int(time.time() * 1000), "op_hours": hours, "hi": round(hi, 3)}
        pub.publish(f"{BASE}/health", json.dumps(body), qos=0)
        time.sleep(0.5)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="rul-" + uuid.uuid4().hex[:8])
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
threading.Thread(target=simulate, args=(client,), daemon=True).start()
client.loop_forever()

Instálalo con pip install paho-mqtt numpy. Al principio de la ejecución, la banda entre p10_h y p90_h es amplia; a medida que el índice de salud se curva hacia arriba, la estimación se estabiliza y la banda se estrecha. Ese comportamiento es normal y es importante comunicarlo: las estimaciones de RUL solo son fiables cuando la degradación es claramente visible.

Publicar estimaciones de RUL que otros puedan usar

Publica la estimación como retained message en un topic dedicado por activo, como .../fan2/rul, para que los dashboards y los conectores de GMAO (CMMS) reciban el último valor en cuanto se suscriban; ese mismo topic puede colorear cada activo en un gemelo digital 3D de la planta según su RUL. Incluye el método y su versión, el umbral utilizado y el rango de incertidumbre. En el portal de ConnectMQ puedes observar el topic en el explorador de topics en vivo y añadir una regla de alerta por umbral, por ejemplo cuando p10_h cae por debajo de una ventana de planificación, de modo que sea el límite inferior y no la estimación puntual lo que dispare la alerta.

Errores comunes en los proyectos de RUL

Predecir días de calendario para un desgaste que depende del uso. Convierte primero a horas de funcionamiento o ciclos.
Mezclar vidas. Si no se registra la sustitución de un componente, dos vidas se funden en una trayectoria confusa.
Ignorar la incertidumbre. Un planificador que solo ve una estimación puntual confiará en exceso o la ignorará.
Entrenar modelos de ML con un puñado de fallos. Empieza con modelos de tendencia o de similitud y pasa a ML cuando el histórico lo permita.
Olvidar los cambios de régimen. Los cambios de carga pueden desplazar el índice de salud sin que haya degradación; normaliza según el contexto de operación.

Dónde encaja la RUL en tu stack

La estimación de RUL se apoya en datos de condición fiables, que a su vez dependen de una capa de mensajería estable. ConnectMQ proporciona esa capa como broker MQTT gestionado, mientras que los modelos se ejecutan como tus propios clientes. Para técnicas de previsión que complementan la extrapolación de tendencias, consulta predicción de series temporales IoT, y para la visión general de los modelos trabajando con dispositivos conectados, la guía de IA e IoT.

Empieza a recoger datos del ciclo de vida en ConnectMQ

Los modelos RUL son tan buenos como el histórico que los respalda, así que el mejor momento para empezar a registrar es ahora. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, conecta tus activos con el nombre de usuario, la contraseña y el client ID generados y empieza a almacenar los eventos de condición, uso y ciclo de vida mediante un suscriptor historian. Cuando tu flota crezca, un plan de broker MQTT en la nube te dará más conexiones y aislamiento sin cambiar tus topics.

Preguntas frecuentes

¿Qué es la predicción de la vida útil remanente?

Es la estimación de cuánto tiempo de funcionamiento, ciclos o uso le quedan a un activo antes de alcanzar una condición de fallo definida, normalmente a partir de sus datos de condición y del comportamiento de activos similares.

¿Cuántos fallos necesito para predecir la RUL?

Los modelos de tendencia de degradación pueden funcionar con el histórico de una sola unidad y un umbral de ingeniería. Los modelos basados en similitud y los de machine learning necesitan entre varios y muchos históricos completos hasta el fallo para cada tipo de componente.

¿Por qué la estimación de RUL cambia tanto al principio?

Antes de que la degradación sea visible, la tendencia está dominada por el ruido y la extrapolación es inestable. Informa de un rango de incertidumbre y confía en la estimación cuando ese rango se estreche.

¿La RUL debe expresarse en días o en horas de funcionamiento?

Usa la unidad que provoca el desgaste, normalmente horas de funcionamiento, ciclos o producción, y convierte a fechas de calendario solo para planificar, usando la utilización prevista.