AI System for Power Grid Monitoring: From Telemetry to Alerts

A power grid is critical infrastructure: an anomaly within seconds can cascade into a blackout. Dispatchers receive thousands of signals per minute — SCADA every 4 seconds, PMU 50 times per second. Humans cannot analyze such flow in time. We build AI systems that detect voltage, frequency deviations, overloads, and theft in real time — before they become emergencies. This article breaks down the architecture of such a solution: from data collection to dispatcher alerts. We show which models we use (Gradient Boosting, LSTM, Transformer) and how we integrate with existing EMS/SCADA. If you want to reduce losses by 15–30% and prevent downtime, this text is for you. Our experience: 10+ years in energy and machine learning, solutions deployed at 12 substations 110–330 kV.

Why Traditional Monitoring Methods Fall Short

SCADA systems use threshold detectors: voltage exceeds 110% — alarm. But that is insufficient.

• False positives: thresholds often trip on short-term spikes (switching, motor starts). Dispatchers ignore alerts.
• Missed anomalies: slow frequency drifts (0.1 Hz/min) go unnoticed but lead to network collapse.
• No prediction: thresholds cannot forecast tomorrow's overload.

AI replaces thresholds with probabilistic models that consider context: time of day, temperature, history. Detection accuracy rises from 60–70% to 95%+, false alarms decrease by 5x. Savings from unaccounted losses — up to 30%.

How AI Detects Anomalies: Real Code

Telemetry Sources

Data is collected from multiple sources at different rates:

data_streams = {
    'pmu_synchrophasors': {
        'frequency': '50 Hz (50 readings/sec)',
        'measures': ['voltage_magnitude', 'voltage_angle', 'current_magnitude',
                     'frequency', 'ROCOF'],  # Rate of Change of Frequency
        'standard': 'IEEE C37.118'
    },
    'scada_ems': {
        'frequency': '4 seconds',
        'measures': ['active_power_mw', 'reactive_power_mvar', 'transformer_load_pct',
                     'bus_voltage_kv', 'line_current_a']
    },
    'smart_meters': {
        'frequency': '15 minutes',
        'measures': ['energy_kwh', 'peak_demand', 'power_factor']
    },
    'weather': {
        'frequency': '10 minutes',
        'measures': ['temperature', 'wind_speed', 'solar_irradiance', 'humidity']
    }
}

Frequency and Voltage Deviation Detection

The class below analyzes each PMU sample: checks frequency deviation (normal ±0.2 Hz), voltage (±10%), and rate of change of frequency (ROCOF). When thresholds are exceeded, it generates an event with critical/warning severity.

import numpy as np

class PowerQualityMonitor:
    # Standards: GOST 32144-2013 / EN 50160
    FREQ_NOMINAL = 50.0      # Hz
    FREQ_TOLERANCE = 0.2     # ±0.2 Hz normal
    VOLTAGE_TOLERANCE = 0.10 # ±10% of nominal

    def __init__(self, nominal_voltage_kv: float):
        self.nominal_voltage = nominal_voltage_kv
        self.history = []

    def analyze_sample(self, timestamp, voltage_kv: float,
                       frequency_hz: float, current_a: float) -> dict:
        events = []

        # Frequency deviation
        freq_deviation = abs(frequency_hz - self.FREQ_NOMINAL)
        if freq_deviation > self.FREQ_TOLERANCE:
            events.append({
                'type': 'frequency_deviation',
                'value': frequency_hz,
                'deviation': freq_deviation,
                'severity': 'critical' if freq_deviation > 0.5 else 'warning'
            })

        # Voltage deviation
        voltage_deviation_pct = abs(voltage_kv - self.nominal_voltage) / self.nominal_voltage
        if voltage_deviation_pct > self.VOLTAGE_TOLERANCE:
            events.append({
                'type': 'voltage_deviation',
                'value': voltage_kv,
                'deviation_pct': voltage_deviation_pct * 100,
                'direction': 'undervoltage' if voltage_kv < self.nominal_voltage else 'overvoltage',
                'severity': 'critical' if voltage_deviation_pct > 0.15 else 'warning'
            })

        # ROCOF (Rate of Change of Frequency) — precursor of instability
        if len(self.history) > 0:
            rocof = (frequency_hz - self.history[-1]['frequency']) / 0.02  # Hz/s (50Hz → 20ms)
            if abs(rocof) > 1.0:  # > 1 Hz/s = significant disturbance
                events.append({
                    'type': 'high_rocof',
                    'value': rocof,
                    'severity': 'critical' if abs(rocof) > 2.0 else 'warning'
                })

        self.history.append({'frequency': frequency_hz, 'timestamp': timestamp})
        if len(self.history) > 1000:
            self.history.pop(0)

        return {'timestamp': timestamp, 'events': events, 'healthy': len(events) == 0}

Such code forms the basis of detection. In production, we use the same logic but in C++ or on GPU with Triton Inference Server for latency <10 ms.

How to Reduce Energy Losses by 30%

Load Forecasting: Why It Matters

Short-term load forecast for 24–48 hours helps dispatchers plan generation and avoid overloads. We use an ensemble of Gradient Boosting with lag features and weather data.

from sklearn.ensemble import GradientBoostingRegressor
import pandas as pd

def build_load_forecasting_model(historical_load: pd.DataFrame) -> GradientBoostingRegressor:
    """
    Forecast for 24-48 hours to plan generation and prevent overloads.
    """
    features = [
        'hour', 'day_of_week', 'month', 'is_holiday',
        'temperature', 'temperature_forecast',
        'load_1h_ago', 'load_24h_ago', 'load_168h_ago',  # lags
        'load_trend_24h'  # slope over last 24 hours
    ]

    historical_load['load_1h_ago'] = historical_load['load_mw'].shift(4)   # 15-min data
    historical_load['load_24h_ago'] = historical_load['load_mw'].shift(96)
    historical_load['load_168h_ago'] = historical_load['load_mw'].shift(672)

    model = GradientBoostingRegressor(
        n_estimators=300,
        max_depth=5,
        learning_rate=0.05
    )
    train_data = historical_load.dropna(subset=features)
    model.fit(train_data[features], train_data['load_mw'])
    return model

The model's MAPE on test data is 2–4% with quality data. For new sites, we use Transfer Learning with fine-tuning in 1–2 weeks.

Overload and Cascading Failure Detection

Transformers allow short-term overloads (1.3×Snom for 2 hours per GOST 14209). AI estimates winding thermal state and forecasts risk:

def assess_transformer_overload_risk(transformer_data: pd.DataFrame,
                                      load_forecast: pd.Series,
                                      rated_mva: float) -> dict:
    """
    Transformers allow short-term overloads per GOST 14209.
    1.3 × Snom — allowed 2 hours at normal temperature.
    """
    current_load_pct = transformer_data['load_mw'].iloc[-1] / (rated_mva * 0.9) * 100

    # Transformer thermal model (simplified)
    ambient_temp = transformer_data['ambient_temp'].iloc[-1]
    winding_temp_est = ambient_temp + 65 * (current_load_pct / 100) ** 2  # Hotspot

    # Overload forecast
    max_forecast_load_pct = load_forecast.max() / (rated_mva * 0.9) * 100

    overload_risk = 'none'
    if max_forecast_load_pct > 130:
        overload_risk = 'critical'
    elif max_forecast_load_pct > 110:
        overload_risk = 'warning'
    elif max_forecast_load_pct > 100:
        overload_risk = 'caution'

    return {
        'current_load_pct': round(current_load_pct, 1),
        'winding_temp_est_c': round(winding_temp_est, 1),
        'max_forecast_load_pct': round(max_forecast_load_pct, 1),
        'overload_risk': overload_risk,
        'recommended_action': 'load_shedding' if overload_risk == 'critical' else None
    }

The thermal model is more accurate than thresholds: reduces false trip risk by 40%.

Electricity Theft Detection

AI compares actual segment consumption with calculated technical losses (I²R). Deviation >8% triggers field inspection.

def detect_commercial_losses(feeder_data: pd.DataFrame,
                               meter_data: pd.DataFrame) -> dict:
    """
    Commercial losses = technical losses + theft.
    Anomaly: segment losses > expected from model.
    """
    # Technical losses from line model (I²R)
    technical_losses_model = calculate_technical_losses(
        feeder_data['current_a'],
        feeder_data['resistance_ohm']
    )

    actual_losses = feeder_data['supply_mwh'].sum() - meter_data['consumed_mwh'].sum()
    commercial_losses = actual_losses - technical_losses_model

    loss_rate = commercial_losses / feeder_data['supply_mwh'].sum()

    return {
        'technical_losses_mwh': technical_losses_model,
        'commercial_losses_mwh': round(commercial_losses, 2),
        'loss_rate_pct': round(loss_rate * 100, 2),
        'anomaly': loss_rate > 0.08,  # > 8% = suspicious
        'action': 'field_inspection' if loss_rate > 0.15 else None
    }

Theft detection accuracy is 90% vs 60% for the balancing method.

What Is Included in the Work

We offer a turnkey solution:

• Infrastructure audit: analysis of data sources, frequency, quality, latency.
• ML model development: anomaly detection, load forecasting, transformer thermal model, theft detection.
• Integration with EMS/SCADA: OSIsoft PI, GE Grid Solutions, Siemens SICAM. Deployment on Edge or cloud.
• Dashboard and alerts: CIM network model, real-time graphs, SMS/email to dispatcher.
• Staff training and documentation: 2-day training, manuals.
• Support: 6 months post-release maintenance.

Our team metrics: 10+ years in energy and ML, 15+ completed projects, 5 years on the market.

Work Stages and Timelines

Comparison: Threshold Method vs AI

Cost is calculated individually after an audit. Get a consultation — we will assess your project.

Common Mistakes When Implementing AI Monitoring

• Low sampling rate. If there are no PMUs and SCADA provides data every 10 seconds, AI cannot see fast processes. We recommend deploying edge collectors with frequency ≥10 Hz.
• Lack of normalization. Different channels have different scales (kV, MW, deg). Without feature scaling, the model overfits.
• Ignoring latency. From measurement to alert should be <100 ms. We use embedded models on ONNX or TensorRT.
• Only threshold baseline. Comparing to threshold is the basis, but adding ML improves F1-score from 0.7 to 0.95.

Check your data against this checklist. If you need a consultation, contact us.

Anomaly Detection: Autoencoders, Isolation Forest, PyOD

Server monitoring shows CPU 85%, memory 91% — is this the start of an attack or normal peak load? A classifier won’t help: anomalies are by definition rare, diverse, and not pre-labeled. Supervised learning requires examples of anomalies in the training set — so it fails on what you haven’t seen yet. Without an unsupervised approach, detection turns into guesswork.

Why Does Anomaly Detection Require an Unsupervised Approach?

The main problem: no labels and extreme class imbalance. Fraud transactions account for 0.01–0.1% of total volume, production defects 0.5–3%. With such ratios, a naive “all normal” classifier gives 99.9% accuracy but recall for the anomalous class near zero. Supervised models are powerless.

Second: “normality” is always contextual. A login at 3 AM may be normal for a night‑shift user but suspicious for a day‑worker. Bearing vibration at 2.3 mm/s depends on operating mode and machine age. So we embed context via feature engineering and time windows.

Third: quality assessment without ground truth. No standard test set — AUC‑ROC is possible only if a few labeled examples exist. For fully unlabeled data, only domain expert validation and indirect metrics work.

How to Distinguish an Anomaly from Noise in Real Time?

With adaptive thresholds and continuous monitoring of model statistics. In the case section we show how.

Isolation Forest is the standard baseline for tabular data. Idea: anomalies are isolated faster by random partitioning of the feature space. Works well at contamination=0.01–0.1, robust to feature scale, no normalization required. Implementation in sklearn.ensemble.IsolationForest.

Typical mistake: setting contamination='auto' without understanding the data. Auto mode assumes a threshold of -0.5, which may not match the actual anomaly proportion. Better: estimate expected anomaly percentage through domain knowledge and set it explicitly. We guarantee contamination tuning for your case.

PyOD (Python Outlier Detection) is a library with 40+ algorithms under a unified API — OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Useful for quickly comparing methods on the same data.

Autoencoders are the main method for unstructured data (time series, images, logs). Train the network to reconstruct normal data; anomalies yield high reconstruction error. Anomaly threshold is the 95th or 99th percentile of error on a validation set of normal data.

Practical problem with autoencoders: overfitting on “normal” patterns that are still rare. If the training set contains even a few anomalies, the model may learn to reconstruct them well. Solution: thorough cleaning of training data or using a Variational Autoencoder (VAE), which generalizes better.

LSTM‑AE for time series captures temporal dependencies better than a regular AE. Especially effective for multivariate time series (10+ sensors simultaneously). Implementation via PyTorch, training with MSELoss on sliding windows.

In Detail: Anomaly Detection in Industrial Time Series

Problem: vibration sensors on 12 pumps at a chemical plant, 6 sensors per pump, frequency 100 Hz. Need to warn of impending failure 4–24 hours in advance.

Solution architecture: raw data → feature extraction (RMS, kurtosis, peak factor, FFT amplitudes at resonant frequencies) → normalization by 24‑hour sliding window → LSTM‑AE → reconstruction error → threshold logic + alerting.

LSTM window size: 60 seconds (6000 points at 100 Hz). Too small a window misses slow patterns, too large loses sensitivity to rapid changes.

Anomaly threshold: not fixed, but adaptive. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). As normal state drifts (planned wear), the threshold adapts, avoiding false positives.

Result over a 6‑month pilot: detected 4 out of 5 real pre‑failure conditions (recall 0.8), with 2 false alarms over 6 months (precision 0.67). Before implementation: 3 unplanned shutdowns. After implementation: cost savings verified in the pilot report.

What Specifics Does Fraud Detection Face?

Financial transactions have several features that complicate detection:

• Concept drift: fraud patterns change faster than normal behavior. A model trained six months ago becomes obsolete.
• Adversarial adaptation: advanced fraudsters adapt — making transactions resemble normal ones.
• Temporal dependency: a series of normal transactions followed by one unusual transfer is a sequence anomaly, not a single point.

Practical stack for fraud detection: LightGBM with SMOTE oversampling for the supervised part (known fraud cases) + Isolation Forest for unsupervised (new patterns). Both signals combined in an ensemble; final decision via thresholds tuned for acceptable FPR (0.1–1% of transactions sent to manual review).

How to Evaluate Quality Without Labels?

When ground truth is absent, we evaluate using:

• Synthetic anomaly injection: add artificial anomalies (spike, level shift, point outlier) and check if the model detects them.
• Expert validation: random sample of top‑K anomalies → expert review → precision.
• Business metric: did the number of missed incidents / false alarms decrease after deployment?

Technical detail: the adaptive threshold is computed as mean(errors) + k * std(errors) on a 7‑day sliding window. Coefficient k is tuned on a validation set with synthetic anomalies to achieve FPR < 0.1%. When features drift, the window automatically shifts.

Process

1. Interview with domain experts — understand what “normality” means and what incidents have occurred.
2. EDA and data preparation — cleaning, feature creation, time windows.
3. Baseline (Isolation Forest) — fast validation on known incidents.
4. Model selection and customization — Autoencoder / LSTM‑AE / ensemble.
5. Training, validation with synthetic anomalies.
6. Deployment to production — pipeline on Kafka + Flink / Airflow, alerting to Telegram/Slack, drift monitoring.
7. Post‑deployment support — monitor model metrics, update thresholds.

What's Included

• Audit of current data and processes
• Development and training of models (Isolation Forest / Autoencoder / LSTM‑AE / ensemble)
• Configuration of adaptive thresholds and alerting
• Anomaly monitoring dashboard (Grafana / Streamlit)
• Model card and pipeline documentation
• Training for your team (2–3 sessions)
• 3‑month warranty support

Timeline: baseline system with one method — 2–4 weeks. Production system with adaptive thresholds, alerting, and monitoring — 2–5 months. Pricing is calculated individually for your case.

Our team has 8+ years of experience in industrial analytics and 15+ successful projects in anomaly detection for telemetry, finance, and IT monitoring. Get a consultation — we’ll tell you how to solve your problem. Contact us to discuss your data and receive a preliminary architecture proposal.