Monitoraggio Energia

Il consumo elettrico è uno dei maggiori costi operativi nelle plant industriali — e uno dei più difficili da controllare senza granularità. Il modulo Monitoraggio Energia di Rela AI cattura i dati di consumo per asset, stabilisce baseline per tipo di attrezzatura e rileva sia picchi improvvisi (anomalie z-score) sia deriva silenziosa (Page-Hinkley sui residui) prima che entrambi appaiano in bolletta.

Come funziona

Consumo normalizzato per turno + rilevamento z-score (picchi) e Page-Hinkley (drift sostenuto). Gli alert sono instradati all'alert_aggregator con severità canonica in base alla magnitudo.

Riepilogo esecutivo

Un motore che perde lo 0,5% di efficienza a settimana resta mesi dentro il range accettabile di qualsiasi allarme z-score classico. Quando il consumo è visibilmente anomalo, hai già pagato in più per un trimestre. Page-Hinkley cattura quella deriva entro 20 campioni.

Invece di vedere solo il totale mensile, questo modulo risponde:

• Quale asset sta consumando più del normale ADESSO?
• Quando è iniziata l'anomalia?
• È un picco puntuale o deriva graduale?
• Quanto sta costando mentre non agiamo?

Quella granularità trasforma il monitoraggio energia da reportistica mensile a leva attiva di gestione costi.

A cosa serve

• Rilevare asset con consumo anormale prima che causino fermi o danni.
• Identificare deriva silenziosa di efficienza — il caso che lo z-score non vede.
• Stabilire benchmark per tipo di attrezzatura.
• Calcolare costo monetario delle inefficienze in tempo reale.
• Alimentare l'Inbox Unificato.
• Generare report per compliance e audit energetici.

I due motori di rilevamento

1. Rilevamento via z-score — picchi immediati

Confronta consumo attuale vs baseline statistica. Quando la deviazione supera la soglia, genera un'anomalia classificata per severità canonica:

| |z| | Severità canonica | |---|---| | ≥ 4.0 | critical | | ≥ 3.0 | high | | ≥ 2.0 | warning | | < 2.0 | info (scartato) |

Ciò che lo z-score NON vede: deriva graduale. Un motore che perde 0,5% efficienza/settimana resta entro ±2σ per mesi.

2. Page-Hinkley — deriva silenziosa

Test statistico di cambio di media sui residui (lettura − baseline). Rileva il momento in cui il consumo ha iniziato a derivare sistematicamente.

flowchart LR
  R[_energy_readings<br/>ultimi 60 giorni] --> B[Sottrai baseline]
  B --> S[Stream di residui]
  S --> PH[Test Page-Hinkley<br/>δ=0.005, λ=50]
  PH -->|Drift rilevato| E[_drift_events<br/>detector=page_hinkley_energy]
  E --> AG[Alert Aggregator]

Quando entra in azione:

• Almeno 20 campioni nella finestra.
• Finestra di lookback: 60 giorni configurabile.
• Sweep cross-tenant pianificabile via Cloud Scheduler.

Output:

• Documento in _drift_events con detector = "page_hinkley_energy", source = "energy", ph_stat, samples.
• Evento pubblicato all'Alert Aggregator.

Esempio concreto: motore estrusore consumo medio 45 kWh/h, std 2. Dalla settimana 8 i residui oscillano intorno a +0,6 invece di 0. Nessun picco supera 2σ, ma Page-Hinkley accumula il bias e scatta al campione 22. Tecnico riallinea il riduttore, consumo torna alla baseline.

Soppressione sensori stale

Un sensore di corrente morto che invia 0 costante produrrebbe anomalie critiche false. sensor_watchdog marca la sorgente come stale. Mentre è stale:

• Anomalie energia di quella sorgente soppresse.
• sensor_stale riportato come alert di salute sensore.
• Quando la sorgente torna, sensor_stale si auto-risolve.

Protegge l'AHI dal cadere per hardware morto.

Baseline e benchmark

Calcolo baseline: analizza consumo in condizioni normali e calcola media + std per metrica. Si aggiorna periodicamente.

Parametri baseline:

• training_mode — rolling o fixed.
• training_days — finestra di training (default 30).
• seasonality — day-of-week + hour-of-day.
• direction — up / down / both.

Benchmark per tipo: raggruppa asset dello stesso tipo e calcola la media del gruppo.

Come usarlo

Dashboard

Asset → Monitoraggio Energia:

• Panoramica: consumo totale real-time, costo stimato, lista asset.
• Per asset: curva consumo, baseline, anomalie z-score, drift events.
• Benchmark: tabelle comparative per tipo, area, turno.
• Eventi drift: lista asset con drift rilevato, ph_stat e timestamp.

Configurazione

Per asset:

• Soglia z-score (default 2.0).
• Direzione (up/down/both).
• Finestra di training.
• Attiva/disattiva Page-Hinkley.

Notifiche

Anomalie energia warning+ alimentano l'Alert Aggregator.

Prima / Dopo

Prima

• Report mensile: la plant ha consumato 3% in più del mese scorso.
• Nessuno sa quale asset.
• Deriva motore iniziata 6 mesi fa — scoperta per caso in audit annuale.

Dopo

• z-score cattura picchi >2σ in tempo reale (minuti).
• Page-Hinkley cattura drift al campione 20–40 (giorni).
• Ogni alert porta asset_id, metric, ph_stat o z_score, estimated_waste_kwh.
• Consolidato nell'Inbox Unificato.

Limitazioni

• Page-Hinkley richiede una finestra stabile prima del drift. Mitigazione: attivare seasonality.
• Deriva negativa rilevata anche. Un motore che consuma inaspettatamente meno può indicare carico perso.
• Costo monetario usa la tariffa nella config del tenant.
• Drift events e anomalie z-score sono ortogonali — l'aggregator consolida.

Benefici chiave

• Due motori complementari: z-score per picchi, Page-Hinkley per drift.
• Severità canonica compatibile con anomaly_detection e prognostics.
• Soppressione intelligente sensori stale.
• Costo monetario per anomalia.
• Consolidamento automatico nell'Inbox Unificato.
• Benchmark di flotta per tipo.