Energy Monitoring

Electric consumption is one of the biggest operational costs in industrial plants — and one of the hardest to control without granularity. Rela AI's Energy Monitoring module captures per-asset consumption data, establishes baselines by equipment type, and detects both sudden spikes (z-score anomalies) and silent drift (Page-Hinkley over residuals) before either shows up on the bill.

What is it for?

• Detect hidden consumption spikes that inflate the bill.
• Alert on sustained drift before month-end reconciliation.
• Attribute consumption by asset, shift, and product.

How it works

Shift-normalized consumption + z-score detection (spikes) and Page-Hinkley (sustained drift). Alerts route to alert_aggregator with canonical severity based on magnitude.

Executive summary

A motor losing 0.5% of efficiency per week stays months inside the acceptable range of any classical z-score alarm. By the time consumption is visibly anomalous, you've been overpaying for a quarter. Page-Hinkley catches that drift within 20 samples.

Unlike just looking at monthly energy totals, this module answers:

• Which asset is consuming more than normal RIGHT NOW?
• When did the anomaly start?
• Is it a one-off spike or gradual drift?
• How much is it costing while we don't act?

That granularity turns energy monitoring from a monthly report into an active cost-management lever.

What it's for

• Detect assets with abnormal consumption before they cause stoppages or damage.
• Identify silent efficiency drift — the case z-scores don't see.
• Establish benchmarks by equipment type for fleet comparison.
• Calculate real-time monetary cost of inefficiencies.
• Feed the Unified Inbox so energy spikes consolidate with other detections on the same asset.
• Generate reports for compliance and energy audits.

The two detection engines

1. z-score detection — immediate spikes

Algorithm compares current consumption against the asset's statistical baseline. When deviation exceeds the configured threshold, an anomaly fires, classified by canonical severity:

| |z| | Canonical severity | |---|---| | ≥ 4.0 | critical | | ≥ 3.0 | high | | ≥ 2.0 | warning | | < 2.0 | info (discarded) |

Severity is shared with other detectors (see Condition Monitoring), enabling inbox consolidation.

What z-score can't see: gradual drift. A motor losing 0.5% efficiency per week stays within ±2σ for months. z-score never fires.

2. Page-Hinkley — silent drift

Page-Hinkley is a statistical change-of-mean test detecting regime shifts in a stream of residuals (reading − baseline). Runs periodically over each (asset, metric) history and pinpoints when consumption started systematically drifting.

flowchart LR
  R[_energy_readings<br/>last 60 days] --> B[Subtract baseline]
  B --> S[Residual stream]
  S --> PH[Page-Hinkley test<br/>δ=0.005, λ=50]
  PH -->|Drift detected| E[_drift_events<br/>detector=page_hinkley_energy]
  E --> AG[Alert Aggregator]

When it kicks in:

• At least 20 samples in the window.
• Lookback window: 60 days configurable.
• Cross-tenant sweep schedulable via Cloud Scheduler.

Output:

• A _drift_events document with detector = "page_hinkley_energy", source = "energy", ph_stat, samples, mean_residual, baseline_mean.
• An event published to the Alert Aggregator.

Concrete example: extruder motor consuming avg 45 kWh/h, std 2 kWh/h. From week 8, residuals no longer oscillate around 0 but around +0.6. No individual spike exceeds 2σ, but Page-Hinkley accumulates the bias and fires at sample 22. Tech realigns the gearbox coupling; consumption returns to baseline.

Stale sensor suppression

A dead current sensor sending constant 0 would produce false critical anomalies in many systems. sensor_watchdog marks the source as stale after too long without valid data. While a source is stale:

• Energy anomalies from that source are suppressed (not persisted).
• sensor_stale gets reported as a sensor health alert instead of an energy anomaly.
• When the source comes back, the sensor_stale alert auto-resolves.

This protects AHI from dropping due to dead hardware instead of degraded equipment.

Baselines and benchmarks

Baseline calculation: system analyzes consumption history during normal operation and computes mean + std per metric. Baselines update periodically to adapt to production changes or seasonality.

Baseline parameters:

• training_mode — rolling (sliding window) or fixed (snapshot).
• training_days — training window (default 30).
• seasonality — day-of-week + hour-of-day toggles.
• direction — up / down / both; filters deviations in the direction that matters.

Type benchmarks: system groups assets of the same type (all 50 HP compressors, all centrifugal pumps) and computes group average. Identifies units consuming more than peers — often a sign of wear.

How to use it

Dashboard

Assets → Energy Monitoring:

• Overview: real-time total consumption, period cost estimate, asset list sorted by consumption.
• Per-asset: consumption curve, baseline, z-score anomalies marked, drift events marked.
• Benchmarks: comparative tables by type, area, shift.
• Drift events: list of assets with detected drift, with ph_stat and detection timestamp.

Configuration

Per-asset UI:

• z-score threshold (default 2.0).
• Direction (up/down/both).
• Training window.
• Enable/disable Page-Hinkley.

Notifications

Energy anomalies warning+ feed the Alert Aggregator. A z-score spike coinciding with a mechanical ML anomaly and critical RUL collapses into a single inbox row.

Before / After

Before

• Monthly report shows plant consumed 3% more than last month.
• Nobody knows which asset was responsible.
• Motor drift started 6 months ago — discovered by chance in annual audit.

After

• z-score catches >2σ spikes in real time (minutes).
• Page-Hinkley catches drift at sample 20–40 (days).
• Each alert carries asset_id, metric, ph_stat or z_score, and estimated_waste_kwh.
• Consolidated with anomaly_detection + prognostics in the Unified Inbox.

Limitations & assumptions

• Page-Hinkley needs a stable window before drift — if baseline changes due to legitimate seasonal production, the test can fire. Mitigation: enable seasonality on the baseline.
• Negative drift is also detected — a motor unexpectedly consuming less may indicate lost load or slipped clutch.
• Monetary cost uses the tariff in tenant config. If tariff changes, only future anomalies reflect the new cost.
• Drift events and z-score anomalies are orthogonal — both can coexist on the same asset. The aggregator consolidates them.

Key benefits

• Two complementary engines: z-score for spikes, Page-Hinkley for drift.
• Canonical severity compatible with anomaly_detection and prognostics.
• Smart stale-sensor suppression — doesn't count dead hardware as fault.
• Monetary cost per anomaly.
• Automatic consolidation in the Unified Inbox.
• Fleet benchmarks by equipment type.