Detección de Anomalías

El sistema de detección de anomalías es la vanguardia de Rela AI: encuentra patrones extraños en los datos de tus equipos antes de que una alarma ISA-18.2 dispare, antes de que una tendencia sea visible a ojo, y antes de que el equipo falle. No usa umbrales fijos — aprende de tus datos qué es "normal" y señala todo lo que no encaja.

¿Para qué sirve?

Las alarmas tradicionales solo funcionan cuando un valor cruza un límite fijo: "temperatura > 80°C". Pero muchos problemas industriales no cruzan un umbral hasta que ya es tarde. Un rodamiento con desgaste incipiente genera vibraciones un 12% por encima de lo habitual — dentro del rango "normal" para cualquier alarma, pero claramente anómalo si el equipo solía estar en otro régimen.

La detección de anomalías ML captura exactamente ese caso. Entrenada con el histórico del propio activo, distingue entre variación normal y comportamiento genuinamente inusual.

Beneficios concretos:

• Ventana de anticipación ampliada: detecta degradación semanas antes que las alarmas clásicas.
• Adapta a cada equipo: lo que es normal para la bomba A puede ser anómalo para la B; el modelo es per-activo + per-métrica.
• Se integra al AHI: cada detección drena puntos de anomaly_pressure, bajando el grado del activo incluso sin alarmas ISA disparadas (ver Monitoreo de Condición).
• Alimenta el inbox unificado: las detecciones warning+ llegan al Alert Aggregator con severidad canónica.

¿Cómo funciona? — ensemble IsolationForest + LOF

flowchart LR
  H[Histórico de lecturas<br/>por asset + métrica] --> E[Extracción de features<br/>valor, media, std, rate-of-change]
  E --> M1[IsolationForest<br/>aísla outliers globales]
  E --> M2[LocalOutlierFactor<br/>detecta outliers locales]
  M1 --> B[Boost por criticalidad<br/>del activo]
  M2 --> B
  B --> S{Score ≥ 0.7?}
  S -- No --> X[Descartar]
  S -- Sí --> D[Persistir detección<br/>con severidad canónica]
  D --> AG[Alert Aggregator]
  D --> AHI[anomaly_pressure<br/>del AHI]

IsolationForest: construye árboles aleatorios que aíslan puntos "raros" con pocas particiones. Bueno para detectar outliers globales (picos extremos, valores imposibles).

LocalOutlierFactor (LOF): compara la densidad local de un punto contra la de sus vecinos. Bueno para detectar cambios de régimen — valores que hubieran sido normales antes pero que hoy están fuera del vecindario habitual.

Ensemble: combinar ambos cubre los dos modos de falla más comunes. Un score final entre 0 y 1 resume el nivel de anomalía.

Boost por criticalidad del activo

No todos los activos son iguales. Una anomalía en un compresor crítico pesa más que la misma en un extractor de baja prioridad. El asset_criticality del activo boostea el score: un anomaly_score = 0.75 sobre un activo crítico puede equivaler a 0.85 final y cruzar el umbral high en la escala canónica.

Severidad canónica

El score × boost final se traduce al idioma común de severidad:

La misma escala la usan prognostics (sobre RUL) y energy (sobre z-score). Eso permite que el Alert Aggregator colapse las 3 señales en una sola fila por activo.

Integración con anomaly_pressure del AHI

Cada detección persistida cuenta para el cálculo de anomaly_pressure, uno de los 5 sub-índices del AHI:

• critical → −8 puntos
• high → −4 puntos
• warning → −1.5 puntos
• info → 0

La ventana de conteo son 7 días y hay un piso de 10 puntos (aunque un activo esté inundado de criticos, su AHI no cae a 0 por este solo factor — los otros sub-índices siguen teniendo voz).

Estrategia de entrenamiento

El modelo aprende del cliente

Rela AI no trae modelos pre-entrenados genéricos. Cada tenant entrena sus modelos con sus propios datos históricos, porque lo que es normal en una planta de cemento no lo es en una planta de alimentos.

• Dataset mínimo: al menos 200 lecturas por (asset, metric) — típicamente 2–3 semanas de captura.
• Retraining: los modelos se reentrenan automáticamente cuando hay drift del RUL (Page-Hinkley sobre residuales de prognostics) o cuando cierra un evento de falla (feedback loop).
• Persistencia: cada modelo se versiona y se asocia al asset_id y al metric_name (vibration, temperature, pressure, etc.).

Cold start

Mientras un activo no tiene suficientes datos, la detección ML está en reposo para ese activo. El sistema sigue calculando AHI sin anomaly_pressure (peso efectivo 0) hasta que el modelo esté listo. La progresión de Nivel de Madurez refleja ese estado.

¿Cómo usarlo?

Ver anomalías activas

Desde el dashboard:

1. Activos → lista — columna "Anomalías 7d" muestra el conteo por activo.
2. Activo → detalle — pestaña Anomalías con el scatter score vs tiempo, filtros por severidad, por tipo, por fuente.
3. Inbox — alertas consolidadas vía Alert Aggregator.

Ajustar la sensibilidad

Cada modelo permite ajustar:

• Umbral de score (default 0.7). Bajar = más sensibilidad + más ruido; subir = menos falsos positivos pero riesgo de perder señal temprana.
• Ventana de features (default 24h). Ventanas más cortas detectan cambios rápidos; más largas son más robustas al ruido.
• Asset criticality (low, medium, high, critical). Afecta el boost del score.

Desde la UI: Activo → Anomalías → Configurar.

Acciones automáticas por anomalía

Al configurar una regla, una anomalía crítica puede disparar:

• Crear una orden de trabajo en el kanban (con el contexto de la anomalía como descripción).
• Notificar por WhatsApp o email al responsable.
• Escalar a supervisor si no se reconoce en N minutos.
• Sincronizar con el CMMS externo (SAP PM, Maximo).

Ver Reglas de eventos.

Limitaciones y supuestos

• Los modelos son per-activo + per-métrica. No comparten parámetros entre activos similares; eso protege contra sobre-generalización pero exige datos por cada combinación.
• Datos escasos degradan la señal. Por debajo de ~200 puntos, la detección estará "en reposo" o producirá falsos positivos hasta converger.
• Sensor staleness. Si el sensor watchdog marca la fuente como stale, las anomalías de esa fuente se suprimen y no drenan AHI — un sensor muerto no debe tankear falsamente la salud del activo.
• No reemplaza el análisis causal. El sistema te dice qué es anómalo y cuándo, no siempre el por qué. La recomendación de IA ofrece hipótesis, pero la inspección física sigue siendo el paso final.

Casos de uso

Caso 1 — Rodamiento con desgaste temprano. Bomba B-07: vibration_rms promedio 2.1 mm/s con std 0.3. De repente, medidas consecutivas en 2.9 mm/s. Dentro del límite ISA (menor a 4 mm/s) — ninguna alarma. LOF lo detecta como cambio de régimen. Score 0.84 → high. El inbox lo marca, AHI baja 4 puntos, el técnico inspecciona y encuentra rodamiento trasero con desgaste incipiente.

Caso 2 — Válvula con fuga interna. Compresor C-03: pressure_avg normal, temperature_avg subiendo 0.3°C por día de forma correlacionada. IsolationForest flagea el punto combinado temperatura × tiempo como outlier global. Score 0.91 → critical. Investigación revela fuga interna en la válvula de descarga. Reparación antes de que el compresor fallara por sobrecalentamiento.

Caso 3 — Falso positivo útil. El sistema flagea un score 0.73 en extractor X-02 durante el turno nocturno. El técnico revisa: el ventilador estaba operando en modo reducido planificado (cambio de consigna sin documentar). No era una falla, pero el sistema detectó el cambio de régimen. El equipo de ingeniería añade la nueva consigna al registro de operación y el modelo la aprende en la próxima ventana de retraining.

Beneficios clave

• Detecta patrones que los umbrales fijos no ven — ventana de anticipación ampliada.
• Per-tenant, per-activo, per-métrica: el modelo habla el idioma de tu planta.
• Ensemble IsolationForest + LOF cubre outliers globales y cambios de régimen.
• Severidad canónica compatible con todo el resto del sistema.
• Alimenta anomaly_pressure del AHI — la salud cae antes que la alarma ISA dispare.
• Consolidación automática en el Alert Aggregator.