Monitoreo de Energía

El consumo eléctrico es uno de los mayores costos operacionales en plantas industriales — y también uno de los más difíciles de controlar sin granularidad. El módulo de Monitoreo de Energía de Rela AI captura los datos de consumo de cada activo, establece baselines por tipo de equipo, y detecta tanto los picos súbitos (anomalías z-score) como la deriva silenciosa (Page-Hinkley sobre residuales) antes de que ambos se reflejen en la factura.

¿Cómo funciona?

Consumo normalizado por turno + detección z-score (picos) y Page-Hinkley (drift sostenido). Alertas enrutadas al alert_aggregator con severidad canónica según magnitud.

Resumen ejecutivo

Un motor que pierde 0.5% de eficiencia por semana se queda meses dentro del rango aceptable de cualquier alarma z-score clásica. Para cuando el consumo es visiblemente anómalo, ya llevas un trimestre pagando de más. Page-Hinkley detecta esa deriva a los 20 samples.

A diferencia de simplemente ver el total mensual de energía, este módulo responde:

• ¿Qué equipo está consumiendo más de lo normal AHORA?
• ¿Cuándo empezó la anomalía?
• ¿Es un pico puntual o un drift gradual?
• ¿Cuánto me está costando mientras no actuemos?

Esa granularidad transforma el monitoreo de energía de un reporte mensual en una palanca activa de gestión de costos.

¿Para qué sirve?

• Detectar equipos con consumo anormal antes de que generen paros o daños.
• Identificar drift silencioso de eficiencia — el caso que el z-score no ve.
• Establecer benchmarks por tipo de equipo para comparar flota.
• Calcular el costo monetario de las ineficiencias en tiempo real.
• Alimentar el Inbox Unificado para que picos de energía se consoliden con otras detecciones del mismo activo.
• Generar reportes para compliance y auditorías energéticas.

Los dos motores de detección

1. Detección por z-score — picos inmediatos

Un algoritmo compara el consumo actual contra el baseline estadístico del equipo. Cuándo la desviación supera el umbral configurado, genera una anomalía clasificada por severidad canónica:

| |z| | Severidad canónica | |---|---| | ≥ 4.0 | critical | | ≥ 3.0 | high | | ≥ 2.0 | warning | | < 2.0 | info (descartada) |

La severidad la comparten los otros detectores del sistema (ver Monitoreo de Condición), lo cual habilita la consolidación en el inbox.

Lo que el z-score NO ve: un drift gradual. Si un motor pierde 0.5% de eficiencia por semana, cada lectura sigue estando dentro de ±2σ durante meses. El z-score nunca dispara.

2. Page-Hinkley — drift silencioso

Page-Hinkley es un test estadístico de cambio de media que detecta cambios de régimen en un stream de residuales (lectura − baseline). Se ejecuta periódicamente sobre el histórico de cada (asset, metric) y detecta el momento preciso en que el consumo empezó a desviarse sistemáticamente.

flowchart LR
  R[_energy_readings<br/>últimos 60 días] --> B[Resta baseline]
  B --> S[Stream de residuales]
  S --> PH[Page-Hinkley test<br/>δ=0.005, λ=50]
  PH -->|Drift detectado| E[_drift_events<br/>detector=page_hinkley_energy]
  E --> AG[Alert Aggregator]

Cuándo entra en acción:

• Al menos 20 samples en la ventana (menos sería estadísticamente inseguro).
• Ventana de lookback: 60 días configurable.
• Sweep cross-tenant agendable vía Cloud Scheduler.

Qué produce:

• Un documento en _drift_events con detector = "page_hinkley_energy", source = "energy", ph_stat, samples, mean_residual, baseline_mean.
• Un evento publicado al Alert Aggregator para consolidación.

Ejemplo concreto: motor de extrusora con consumo avg 45 kWh/h, std 2 kWh/h. A partir de la semana 8, los residuales ya no oscilan alrededor de 0 sino de +0.6. Ningún pico individual supera 2σ, pero el test Page-Hinkley acumula el sesgo y salta al sample 22. El técnico alinea el acople del reductor, el consumo vuelve a su baseline. Ahorro anualizado estimado sobre el delta del drift.

Supresión de sensores stale

Un sensor de corriente que muere y envía 0 constantes produciría una anomalía crítica falsa en muchos sistemas. El sensor_watchdog marca la fuente como stale cuando pasa demasiado tiempo sin datos válidos. Mientras una fuente esté stale:

• Las anomalías de energía de esa fuente se suprimen (no se persisten).
• sensor_stale se reporta como alerta de salud del sensor en lugar de anomalía energética.
• Cuándo la fuente vuelve, la alerta sensor_stale se auto-resuelve.

Esto protege el AHI de caer por hardware muerto en lugar de equipo degradado.

Baselines y benchmarks

Cálculo de baseline: el sistema analiza el histórico de consumo de cada activo en condiciones normales de operación y calcula la media y desviación estándar por métrica. El baseline se actualiza periódicamente para adaptarse a cambios de producción o estacionalidad.

Parámetros del baseline:

• training_mode — rolling (ventana deslizante) o fixed (snapshot).
• training_days — ventana de entrenamiento (default 30).
• seasonality — day-of-week + hour-of-day si está activado.
• direction — up / down / both; filtra desviaciones en la dirección que importa (un motor que consume menos también es anomalía).

Benchmarks por tipo: el sistema agrupa activos del mismo tipo (todos los compresores de 50 HP, todas las bombas centrífugas) y calcula el consumo promedio del grupo. Identifica cuáles unidades consumen más que sus pares — frecuentemente señal de desgaste.

¿Cómo usarlo?

Dashboard

Activos → Monitoreo de Energía:

• Vista general: consumo total en tiempo real, costo estimado del período, lista de activos ordenada por consumo.
• Vista por activo: curva de consumo, baseline, anomalías z-score marcadas, drift events marcados, filtros por métrica.
• Benchmarks: tablas comparativas por tipo, área, turno.
• Drift eventos: lista de activos con drift detectado, con ph_stat y momento de detección.

Configuración

Desde la UI de configuración per-activo:

• Umbral z-score (default 2.0).
• Dirección (up/down/both).
• Ventana de entrenamiento.
• Activar/desactivar Page-Hinkley.

Notificaciones

Anomalías de energía warning+ alimentan el Alert Aggregator. Un pico de z-score que coincide con una anomalía ML mecánica y un RUL crítico colapsa en una sola fila del inbox — no tres.

Caso de uso: before/after

Antes

• Reporte mensual muestra que la planta consumió 3% más que el mes anterior.
• Nadie sabe qué equipo fue el responsable.
• Hace 6 meses que un motor empezó a derivar — descubrimiento casual en auditoría anual.

Después

• Z-score detecta picos > 2σ en tiempo real (minutos).
• Page-Hinkley detecta drift al sample 20–40 (días).
• Cada alerta lleva asset_id, metric, ph_stat o z_score, y estimated_waste_kwh.
• Consolidada con anomaly_detection + prognostics en Inbox Unificado.

Limitaciones y supuestos

• Page-Hinkley necesita ventana estable antes del drift — si el baseline cambia por producción estacional legítima, el test puede disparar. Mitigación: activar seasonality en el baseline.
• Drift negativos también son detectables — un motor que inesperadamente consume menos podría indicar carga perdida o embrague suelto; el sistema los reporta igual.
• El cálculo de costo monetario usa la tarifa registrada en la configuración del tenant. Si la tarifa cambia, solo las anomalías futuras reflejan el nuevo costo.
• Los drift events y las anomalías z-score son ortogonales — pueden coexistir sobre el mismo activo. El aggregator se encarga de consolidarlos.

Beneficios clave

• Dos motores complementarios: z-score para picos, Page-Hinkley para drift.
• Severidad canónica compatible con anomaly_detection y prognostics.
• Supresión inteligente de sensores stale — no cuenta hardware muerto como falla.
• Costo monetario calculado por anomalía.
• Consolidación automática en Inbox Unificado.
• Benchmarks de flota por tipo de equipo.