Monitoreo de Condición
Mantenimiento predictivo ISO 13374 end-to-end: del sensor al pronóstico, con un solo inbox de alertas consolidadas y un índice de salud que combina 5 señales.
Monitoreo de Condición
El Monitoreo de Condición es el sistema de mantenimiento predictivo de Rela AI. Va más allá de las alarmas de umbral simple: aprende cómo se comporta normalmente cada equipo, monitorea su salud en el tiempo, detecta anomalías con modelos de ML, estima cuándo podría fallar, y consolida todas esas señales en un único inbox de alertas para que el operador vea una fila por activo, no tres por el mismo evento físico.
Resumen ejecutivo
El cambio de juego: dejar de reaccionar, empezar a anticipar. Antes, tres sistemas independientes gritaban lo mismo y nadie sabía qué acción tomar. Hoy, un único inbox unificado consolida detecciones mecánicas, energéticas y de vida útil en una sola alerta por activo, con severidad canónica A/B/C/D/F y recomendaciones accionables.
Antes vs Después
| Dimensión | Antes (reactivo) | Después (Rela AI predictivo) |
|---|---|---|
| Detección de fallas | El equipo falla → operador llama → técnico acude | 18–72 h de anticipación con RUL estimado |
| Inbox del operador | 3 alertas del mismo pico (anomalía + energía + RUL) | 1 fila consolidada por activo, severidad = max |
| Decisión de mantenimiento | Calendario fijo o reactivo | Condición real + confianza + umbrales por tenant |
| Señal temprana ML | Ignorada hasta que disparaba una alarma ISA-18.2 | anomaly_pressure ya afecta el AHI desde el primer evento |
| Drift silencioso | Motor pierde 0.5%/semana por meses sin ser detectado | Page-Hinkley lo captura a los 20 samples |
| Auditoría | "¿Qué umbral había cuando esto se calificó A?" sin respuesta | Cada snapshot lleva config_version trazable |
¿Para qué sirve?
El mantenimiento reactivo (esperar la falla) y el mantenimiento preventivo por calendario (cambiar el aceite cada 3 meses, sin importar el estado real del equipo) son los dos extremos del mantenimiento industrial. El mantenimiento predictivo es el punto óptimo: intervenir exactamente cuando el equipo lo necesita, basándose en su condición real.
El Monitoreo de Condición permite:
- Detectar deterioro gradual semanas antes de que cause una falla.
- Estimar la vida útil remanente de un componente (¿cuántos días más puede operar?).
- Priorizar el mantenimiento en los equipos que más lo necesitan, no en los que tienen la fecha más cercana en el calendario.
- Reducir paradas no programadas — la causa más costosa de pérdida de producción.
- Consolidar el ruido de múltiples sistemas de detección en un inbox accionable.
Pipeline end-to-end
flowchart LR
S[Sensores / PLC / SCADA] --> I[Ingesta MQTT / OPC UA / Modbus / S7 / EtherNet-IP / HTTP]
I --> F[Field mapping + normalización]
F --> T[Tendencias + baselines]
T --> A1[Detección ML<br/>IsolationForest + LOF]
T --> A2[Residuales de energía<br/>z-score + Page-Hinkley]
T --> H[Asset Health Index<br/>5 sub-índices]
H --> P[Pronósticos RUL<br/>+ CBM triggers]
A1 --> AG[Alert Aggregator<br/>dedup por asset]
A2 --> AG
P --> AG
AG --> INBOX[Inbox unificado<br/>1 fila por activo]
INBOX --> TASK[Orden de trabajo]
INBOX --> CMMS[CMMS sync]
INBOX --> NOTIF[WhatsApp / Email]Cada bloque es documentable, observable y configurable por tenant:
- Ingesta: ver Protocolos industriales y Machine Events.
- Tendencias y baselines: ver Análisis de Tendencias y Líneas Base.
- Detección ML: ver Detección de Anomalías.
- Energía: ver Monitoreo de Energía.
- Salud + Pronóstico: secciones a continuación y Pronósticos.
- Consolidación: ver Alert Aggregator.
¿Cómo funciona? — Los 6 niveles ISO 13374
Rela AI implementa el estándar internacional ISO 13374 de monitoreo de condición, que organiza el proceso en 6 niveles que se alimentan entre sí:
Nivel 1: Adquisición de Datos
Los datos crudos de sensores, PLCs y sistemas SCADA llegan al sistema a través de los protocolos soportados nativamente: HTTP, MQTT, OPC UA (incluido Reverse Connect), Modbus TCP, S7comm y EtherNet/IP (CIP). Se almacenan con su timestamp original y se normalizan para que todos los datos hablen el mismo idioma, sin importar de qué equipo vengan. Ver Protocolos industriales.
Nivel 2: Análisis de Tendencias
Los datos crudos se procesan para extraer información útil: promedios móviles, máximos y mínimos, tasas de cambio, desviaciones estándar. Aquí es donde los datos sueltos se convierten en tendencias legibles — puedes ver si la temperatura del motor ha estado subiendo lentamente durante las últimas 2 semanas.
Nivel 3: Detección de Estado
El sistema ejecuta dos flujos complementarios:
- Condición vs línea base — compara datos actuales contra baselines aprendidos.
- Detección de anomalías ML — un ensemble de IsolationForest + LocalOutlierFactor asigna un score 0–1 a cada lectura; lo que supera 0.7 entra al inbox. Ver Detección de Anomalías.
Cada detección se traduce a una severidad canónica (info, warning, high, critical) que es el idioma común de todo el sistema: anomalías mecánicas, picos de energía, RUL crítico — todos hablan la misma escala.
Nivel 4: Evaluación de Salud
Combina cinco sub-índices en un único Índice de Salud del Activo (AHI) — un número de 0 a 100 que resume el estado general del equipo.
| Sub-índice | Peso default | Qué mide |
|---|---|---|
condition | 0.35 | Estado instantáneo vs baselines |
alarm_health | 0.20 | Horas-alarma acumuladas (ISA-18.2), con cap por alarma |
maintenance_compliance | 0.15 | Cumplimiento de planes preventivos vencidos |
trend_stability | 0.10 | Dirección + r² de tendencias de 24h |
anomaly_pressure | 0.20 | Densidad de detecciones ML recientes (7d), por severidad |
Los pesos se pueden ajustar por tenant y por asset_type (una bomba crítica puede ponderar anomaly_pressure más alto que un compresor tolerante). Ver Configuración Predictiva.
El AHI se traduce a una calificación de grados:
| Grado | AHI | Estado del equipo |
|---|---|---|
| A | 90-100 | Excelente — sin problemas detectados |
| B | 70-89 | Bueno — monitorear normalmente |
| C | 50-69 | Aceptable — investigar en próxima ronda |
| D | 30-49 | Insatisfactorio — programar intervención |
| F | 0-29 | Crítico — riesgo de falla inminente |
Los umbrales A/B/C/D también son configurables por tenant (ahi_grades).
Nivel 5: Pronósticos
Basándose en la tendencia histórica del AHI, el sistema estima:
- RUL (Remaining Useful Life) en horas, con intervalo de confianza bootstrap.
- Tasa de degradación en puntos de AHI por día.
- CBM trigger — métricas que cruzan
cbm_trigger_multiplier × baseline. - Probabilidad de falla — función del AHI y los breakpoints
critical_ahi,high_ahi,normal_ahi.
Ver Pronósticos.
Nivel 6: Recomendaciones + Inbox consolidado
La inteligencia artificial genera recomendaciones en lenguaje natural. Cada detección se publica al Alert Aggregator, que consolida las señales de los tres sistemas (anomalía ML, energía, pronóstico) en una fila por activo y propaga a WhatsApp, email, CMMS o tareas.
Niveles de Madurez Predictiva
Cada equipo progresa automáticamente por 4 niveles a medida que acumula datos:
| Nivel | Nombre | Requisitos | Capacidades |
|---|---|---|---|
| 0 | Monitoreo | Sin datos suficientes | Alertas básicas |
| 1 | Seguimiento de Salud | 10+ snapshots | AHI activo, tendencias visibles |
| 2 | Predicción | 30+ snapshots + 1 falla registrada | RUL confiable, recomendaciones |
| 3 | Optimizado | 30+ snapshots + 3 fallas + confianza > 70% | Automatización completa, auto-CBM |
La progresión es automática — el sistema evalúa los requisitos después de cada snapshot y promueve al activo sin intervención manual. Los umbrales (snapshots mínimos, fallas requeridas, confianza mínima) son configurables por tenant.
Trazabilidad: config_version
Cada snapshot de salud y cada prognóstico lleva un campo config_version con el número de la configuración predictiva que estuvo activa en el momento del cálculo. Si un tenant ajusta ahi_grades o rul_thresholds, las alertas anteriores no se reescriben: conservan su versión original. Una auditoría puede reconstruir exactamente qué umbrales produjeron cada calificación.
Casos de uso con impacto medible
Caso 1 — Bomba pre-falla detectada 18h antes. Compresor C-03 con AHI histórico 87 (B). En 3 semanas baja a 65 (C). Pronóstico estima 9 días para alcanzar F si sigue la tendencia. El sistema crea tarea urgente; el técnico encuentra filtro de aceite obstruido. Reemplazo + AHI sube a 83 en 2 días. Falla evitada, 4 horas de parada no ocurrida.
Caso 2 — Motor con drift silencioso. Motor de extrusora con consumo dentro de ±2σ durante 4 meses, pero derivando +0.3% por semana. El z-score nunca dispara. Page-Hinkley sobre los residuales de consumo detecta el cambio de régimen a los 20 samples. Mantenimiento alinea el acople y el consumo vuelve a la baseline. Ahorro estimado por el propio sistema: valor monetario proyectado sobre el delta mensual de consumo.
Caso 3 — Inbox unificado sin ruido. Un pico real de vibración en la bomba B-07 dispara simultáneamente anomaly_detection, energy_service y prognostics. Antes: 3 alertas críticas abiertas, el operador dudaba cuál atender. Después: 1 fila en _alerts con source_systems = [anomaly, energy, prognostics], severidad critical, count = 3. Una sola acción cierra las tres.
¿Cómo activar el monitoreo de condición?
El sistema se activa progresivamente — no necesitas configurar todos los niveles de una vez:
Fase 1 — Recopilación y tendencias (Niveles 1-2):
- Conecta las fuentes de datos de tus equipos críticos (Fuentes de Eventos).
- Deja que el sistema acumule al menos 7-14 días de datos.
- Revisa los gráficos de tendencia para familiarizarte con el comportamiento de los equipos.
Fase 2 — Líneas base, anomalías y salud (Niveles 3-4):
- Con 30+ días de datos, calcula las líneas base de cada equipo.
- Entrena los modelos de anomalía ML por tenant.
- Activa la evaluación de salud — el AHI empieza a calcularse automáticamente.
- Configura umbrales de alerta por grado de salud.
Fase 3 — Predicción, recomendaciones y consolidación (Niveles 5-6):
- Con suficiente historial, activa los pronósticos de vida útil.
- Ajusta la ventana de dedup del aggregator (
alert_dedup_window_minutes, default 60). - Integra las recomendaciones con tu flujo de mantenimiento.
Beneficios clave
- Del reactivo al predictivo: intervenir antes de la falla, con días de anticipación.
- Índice de salud con 5 señales — incluye la señal ML temprana (
anomaly_pressure) que no depende de alarmas ISA. - Un solo inbox — consolidación cross-sistema con severidad
maxy trail de sources por alerta. - Umbrales por tenant y por tipo de activo — sin tocar código.
- Trazabilidad completa vía
config_versionpara auditoría. - Detección de drift gradual (Page-Hinkley) que los z-scores tradicionales no ven.
- Estándar ISO 13374 internacionalmente reconocido.
KPIs Predictivos
Metricas de valor del mantenimiento predictivo incluyendo tiempo anomalia-a-OT, tasa de falsos positivos, porcentaje de OT auto-creadas, downtime no planeado y precision de RUL.
Líneas Base y Estado de Condición
Las líneas base registran cómo se comporta un equipo cuando está bien. El sistema compara cada nueva medición contra esa referencia para detectar automáticamente cuándo algo cambia.