La comparación entre monitorización de condición y mantenimiento predictivo es una de las más confusas de la ingeniería de mantenimiento, y los proveedores a menudo la difuminan a propósito. Este artículo separa ambos conceptos con claridad, muestra la ruta de madurez que lleva de uno a otro y esboza el flujo de datos MQTT que construirías para cada uno, para que puedas decidir dónde debe invertir tu planta a continuación.
La respuesta corta
La monitorización de condición mide la salud de un activo y te dice cuándo algo es anómalo en este momento. El mantenimiento predictivo usa esos mismos datos de salud, más el historial, para estimar cuándo es probable que se produzca un fallo y poder planificar la reparación en el mejor momento.
La monitorización de condición es una capacidad. El mantenimiento predictivo es una estrategia construida sobre ella. No puedes hacer mantenimiento predictivo sin monitorización de condición, pero sí puedes, y la mayoría de las plantas deberían, aplicar la monitorización de condición mucho antes de intentar predicciones.
Monitorización de condición vs mantenimiento predictivo de un vistazo
| Aspecto | Monitorización de condición | Mantenimiento predictivo |
|---|---|---|
| Pregunta que responde | ¿Está sana esta máquina ahora? | ¿Cuándo necesitará intervención esta máquina? |
| Resultado típico | Alarma o estado de salud | Tiempo estimado hasta el umbral o vida útil remanente |
| Lógica | Umbrales, bandas, reglas | Tendencias, modelos de degradación, estadística o machine learning |
| Datos necesarios | Lecturas actuales y una línea base | Historial largo que incluya fallos pasados |
| Tiempo hasta el primer valor | De días a semanas | Meses, cuando existe suficiente historial |
| Quién actúa | El operario o el técnico responde a una alerta | El planificador programa el trabajo en la siguiente ventana adecuada |
| Riesgo principal | Fatiga de alarmas por umbrales mal definidos | Modelos en los que se confía antes de validarlos |
Ambos enfoques contrastan con el mantenimiento correctivo (reparar cuando se rompe) y el preventivo (intervenir según calendario o contador, independientemente del estado). El objetivo de ambos es el mismo: dejar de sustituir piezas sanas y dejar de llevarse sorpresas con las que fallan.
Cómo es la monitorización de condición en la práctica
Un sistema de monitorización de condición mide de forma continua o periódica una magnitud física que refleja la salud:
- Vibración en motores, bombas, ventiladores y reductores
- Temperatura de rodamientos y devanados
- Corriente y potencia del motor
- Calidad, presión y caudal del aceite
- Emisión acústica y ultrasonidos
Cada lectura se compara con un límite. Cuando se supera, se avisa a alguien. Parece sencillo, y lo es, y precisamente por eso aporta valor rápido. Un sensor de vibración con una alarma sensata relativa a la línea base detectará una pata floja o un rodamiento que falla días o semanas antes de que se agarrote. El tutorial del sensor de monitorización de vibraciones explica cómo construir uno.
Flujo de datos de monitorización de condición con MQTT
El flujo es corto: del sensor al broker, a la lógica de alertas y a las personas.
sensor/gateway --publish--> acme/plant1/press/line2/hydpump1/condition
|
MQTT broker (e.g. ConnectMQ)
| |
threshold alert rule dashboard / topic explorer
|
acme/plant1/press/line2/hydpump1/alert (retained)
Un payload típico solo lleva los valores actuales y sus unidades:
{
"ts": "2026-10-16T08:15:00Z",
"vib_rms_mm_s": 3.1,
"bearing_temp_c": 58.4,
"current_a": 21.7
}
En ConnectMQ, las reglas de alerta por umbral del portal pueden vigilar campos como estos y registrar cada superación en el registro de alertas, lo que a menudo basta para un primer piloto. La lógica más matizada, como límites relativos a la línea base o exigir varias superaciones consecutivas, se ejecuta en un pequeño servicio suscriptor.
Qué añade el mantenimiento predictivo
El mantenimiento predictivo plantea una pregunta más difícil: dada la evolución de esta señal, ¿cuándo llegará al punto en que debamos actuar? Responderla requiere tres cosas que la monitorización de condición no necesita:
- Historial. Semanas o meses de lecturas por activo, almacenadas en una base de datos de series temporales.
- Conocimiento de los fallos. Registros de qué falló, cuándo y cómo eran las señales antes. Sin esto, un modelo no tiene de qué aprender.
- Un modelo. Desde una extrapolación lineal de la tendencia hasta una curva de degradación basada en la física o un modelo de machine learning entrenado. El artículo de mantenimiento predictivo con machine learning cubre la parte de ciencia de datos.
El resultado no es una alarma sino una previsión: "La vibración del rodamiento de la bomba 1 sube unos 0,1 mm/s al día y superará el límite de alarma en unos 12 días". Un planificador puede entonces programar el cambio del rodamiento en una parada ya prevista en lugar de perder un turno por una avería no planificada.
Flujo de datos de mantenimiento predictivo con MQTT
El broker sigue siendo el transporte, pero se conectan más consumidores:
sensors/gateways --> MQTT broker --> historian subscriber --> time-series DB
| |
| model / trend job
| |
<------ publish prediction -------------+
acme/plant1/press/line2/hydpump1/prediction (retained)
|
CMMS integration / planner dashboard
La predicción se publica de vuelta en el broker como mensaje retenido, de modo que cualquier dashboard o sistema de mantenimiento que se suscriba recibe de inmediato la última previsión:
{
"ts": "2026-10-16T09:00:00Z",
"signal": "vib_rms_mm_s",
"current": 3.1,
"alarm_limit": 4.5,
"slope_per_day": 0.11,
"days_to_limit": 12.7,
"confidence": "medium"
}
Un paso mínimo de la monitorización a la predicción
No necesitas machine learning para dar el primer paso predictivo. Una regresión lineal móvil sobre un agregado diario ya da una estimación útil de "días hasta el límite". El job en Python siguiente lee valores diarios (de tu historiador; aquí una lista para mayor claridad) y publica la previsión con paho-mqtt 2.x en el servidor MQTT público gratuito, pensado para pruebas y no para datos de producción.
import json
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
ALARM_LIMIT = 4.5
TOPIC = "connectmq/demo/4c81d2/press/hydpump1/prediction"
# daily median vibration RMS in mm/s, oldest first (normally queried from your historian)
daily = [2.1, 2.1, 2.2, 2.2, 2.3, 2.3, 2.5, 2.5, 2.6, 2.8, 2.8, 2.9, 3.0, 3.1]
def linear_fit(values):
n = len(values)
xs = range(n)
mx, my = (n - 1) / 2, sum(values) / n
sxx = sum((x - mx) ** 2 for x in xs)
sxy = sum((x - mx) * (y - my) for x, y in zip(xs, values))
slope = sxy / sxx
return slope, my - slope * mx
slope, intercept = linear_fit(daily[-14:])
current = daily[-1]
days_to_limit = (ALARM_LIMIT - current) / slope if slope > 0 else None
forecast = {
"ts": datetime.now(timezone.utc).isoformat(timespec="seconds"),
"signal": "vib_rms_mm_s",
"current": current,
"alarm_limit": ALARM_LIMIT,
"slope_per_day": round(slope, 3),
"days_to_limit": round(days_to_limit, 1) if days_to_limit else None,
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-job-4c81d2")
client.connect("broker.connectmq.com", 1883)
client.loop_start()
client.publish(TOPIC, json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print(forecast)
Es deliberadamente sencillo. Supone que la degradación es aproximadamente lineal durante las dos últimas semanas, lo que suele bastar para fallos de desarrollo lento y es inútil para los repentinos. Esa limitación resume con honestidad el mantenimiento predictivo en general: amplía tu tiempo de aviso para los fallos graduales, mientras que la monitorización de condición sigue teniendo que detectar los abruptos.
La ruta de madurez del mantenimiento
La mayoría de las plantas atraviesan estas etapas en orden. Saltarse pasos es el motivo más habitual por el que se estancan los proyectos predictivos.
- Correctivo. Funcionar hasta el fallo. Sin datos.
- Preventivo. Tareas por tiempo o contador. Los datos viven en el GMAO como órdenes de trabajo.
- Conectado. Las máquinas publican estado y contadores básicos. Aquí suele aparecer una columna vertebral MQTT, a menudo primero para el seguimiento de paradas de máquinas.
- Monitorización de condición. Señales de salud en activos críticos con alertas. El valor llega en semanas.
- Mantenimiento basado en la condición. Las órdenes de trabajo se disparan por alertas de condición en lugar de por calendario en los activos que monitorizas.
- Mantenimiento predictivo. Las tendencias y los modelos programan el trabajo antes de que se superen los umbrales.
- Prescriptivo. El sistema también recomienda la acción y el mejor momento, teniendo en cuenta los planes de producción y los repuestos.
Mide el progreso con métricas de fiabilidad, no con el número de sensores instalados. El cálculo de MTBF y MTTR te da una línea base antes de empezar y una forma de demostrar la mejora después.
Dónde invertir
Empieza por la monitorización de condición cuando:
- Tienes activos críticos sin ningún dato de salud.
- Los fallos son caros, pero tienes pocos registros históricos de fallos.
- Necesitas resultados visibles en un trimestre.
Invierte en mantenimiento predictivo cuando:
- Se han recogido datos de condición de forma constante durante meses en los mismos activos.
- Tienes fallos documentados con su historial de sensores correspondiente.
- Existe flexibilidad de planificación, es decir, un aviso más temprano cambiaría realmente cuándo se hace el trabajo.
En ambos casos la decisión de infraestructura es la misma: lleva las señales una sola vez a una columna vertebral MQTT fiable y con nombres claros, y deja que la monitorización, los historiadores y los modelos se suscriban de forma independiente. Un broker MQTT en la nube hace que esa columna vertebral sea accesible desde la planta, desde un equipo de datos en otra ubicación y desde el portátil de un planificador de mantenimiento sin integraciones punto a punto a medida. La guía de fabricación inteligente describe en detalle esa columna vertebral y la estructura de topics ISA-95; sobre ella también puedes visualizar el estado de cada activo en un gemelo digital 3D.
Errores habituales
- Comprar predicción antes que monitorización. Un modelo entrenado con unas pocas semanas de datos y sin fallos registrados no predecirá nada útil.
- Umbrales fijos de catálogo. Cada máquina tiene su propia normalidad. Aprende líneas base por activo.
- Sin ciclo de retroalimentación. Los técnicos deben registrar lo que encontraron al responder a una alerta; de lo contrario nunca podrás validar ni mejorar la lógica.
- Datos en silos. Si el sistema de vibraciones, el GMAO y el historiador no pueden ver los datos de los demás, la predicción se queda en una diapositiva de una presentación.
- Ignorar los fallos repentinos. La predicción ayuda con el desgaste gradual. Mantén alarmas rápidas de condición para todo lo demás.
Construye tu columna vertebral de monitorización con ConnectMQ
ConnectMQ es un broker MQTT gestionado con MQTT 5, TLS, retained messages, un explorador de topics en directo y reglas de alerta por umbral integradas, para que puedas aplicar hoy la monitorización de condición y conectar más adelante historiadores y jobs de predicción como clientes MQTT normales. Crea un broker con el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito.
Preguntas frecuentes
¿La monitorización de condición es lo mismo que el mantenimiento predictivo?
No. La monitorización de condición detecta una salud anómala ahora, mientras que el mantenimiento predictivo usa los datos de condición y el historial para prever cuándo será necesaria una intervención. El mantenimiento predictivo depende de la monitorización de condición.
¿Qué debería implantar primero una planta?
La monitorización de condición. Aporta valor rápido y construye el historial de datos que cualquier enfoque predictivo necesitará después.
¿Necesito machine learning para el mantenimiento predictivo?
No necesariamente. La extrapolación de tendencias sobre señales bien elegidas ya da estimaciones útiles del tiempo hasta el límite para fallos graduales. El machine learning ayuda cuando tienes un historial rico y muchos fallos registrados.
¿Qué papel desempeña MQTT en cada enfoque?
MQTT es el transporte que mueve lecturas de sensores, alertas y predicciones entre dispositivos, dashboards, historiadores y sistemas de mantenimiento. Usar un único broker para todos ellos evita las integraciones punto a punto.
