AI Predictive Maintenance System for Power Grids

Power equipment — transformers, cables, circuit breakers — fails with signs of wear weeks to months before an accident. Switching from preventive to predictive maintenance reduces costs by 20-30% and eliminates unplanned outages. On a site with 10 transformers, maintenance budget savings reach 4 million rubles per year, and the system payback period is less than 12 months.

An unplanned outage of a 110 kV transformer leads to fines, production downtime, and reputational losses. According to statistics, 70% of power transformer failures are related to insulation defects. These defects manifest 3-6 months before failure. Traditional diagnostic methods — periodic DGA (Dissolved Gas Analysis) measurements once a year — often miss rapid deterioration. Our AI system monitors DGA, partial discharges, and thermal regimes in real time, predicting failure with up to 90% accuracy.

Based on our project data, AI prediction reduces emergency outages by a factor of 4 compared to planned maintenance. At the same time, the system payback period is less than a year.

How AI Predicts Transformer Failure

DGA is the main indicator of oil condition. We use thresholds and gas ratios per the IEEE C57.104 standard to classify defects. Here's an example diagnostic code:

import numpy as np

dga_thresholds = {
    'hydrogen_H2': {'warning': 150, 'alarm': 500},
    'methane_CH4': {'warning': 75, 'alarm': 200},
    'ethylene_C2H4': {'warning': 60, 'alarm': 150},
    'ethane_C2H6': {'warning': 100, 'alarm': 200},
    'acetylene_C2H2': {'warning': 2, 'alarm': 30},
    'carbon_monoxide_CO': {'warning': 700, 'alarm': 1500},
    'carbon_dioxide_CO2': {'warning': 10000, 'alarm': 15000}
}

def diagnose_transformer_dga(gas_ppm: dict) -> dict:
    alarm_gases = []
    for gas, value in gas_ppm.items():
        if gas in dga_thresholds:
            if value > dga_thresholds[gas]['alarm']:
                alarm_gases.append({'gas': gas, 'value': value, 'level': 'alarm'})
            elif value > dga_thresholds[gas]['warning']:
                alarm_gases.append({'gas': gas, 'value': value, 'level': 'warning'})

    ch4_h2 = gas_ppm.get('methane_CH4', 0) / (gas_ppm.get('hydrogen_H2', 1) + 1e-9)
    c2h4_c2h6 = gas_ppm.get('ethylene_C2H4', 0) / (gas_ppm.get('ethane_C2H6', 1) + 1e-9)
    c2h2_c2h4 = gas_ppm.get('acetylene_C2H2', 0) / (gas_ppm.get('ethylene_C2H4', 1) + 1e-9)

    fault_type = 'normal'
    if gas_ppm.get('acetylene_C2H2', 0) > 5:
        fault_type = 'arc_discharge'
    elif c2h4_c2h6 > 1.0 and ch4_h2 > 0.1:
        fault_type = 'thermal_fault_high'
    elif ch4_h2 > 0.1 and c2h4_c2h6 < 1.0:
        fault_type = 'thermal_fault_medium'
    elif gas_ppm.get('hydrogen_H2', 0) > 200 and c2h4_c2h6 < 0.1:
        fault_type = 'partial_discharge'

    urgency = {
        'arc_discharge': 'immediate_shutdown',
        'thermal_fault_high': 'urgent_inspection',
        'thermal_fault_medium': 'schedule_maintenance',
        'partial_discharge': 'enhanced_monitoring',
        'normal': 'routine'
    }

    return {
        'fault_type': fault_type,
        'urgency': urgency[fault_type],
        'alarm_gases': alarm_gases,
        'rogers_ratios': {'CH4/H2': round(ch4_h2, 3), 'C2H4/C2H6': round(c2h4_c2h6, 3), 'C2H2/C2H4': round(c2h2_c2h4, 3)}
    }

Gas trends predict degradation. Linear regression on log concentration detects defect acceleration:

from sklearn.linear_model import LinearRegression
import pandas as pd

def forecast_gas_trend(dga_history: pd.DataFrame, gas: str, forecast_days: int = 30) -> dict:
    data = dga_history[['days_ago', gas]].dropna()
    data = data[data[gas] > 0]
    if len(data) < 3:
        return {'status': 'insufficient_data'}
    X = data['days_ago'].values.reshape(-1, 1)
    y = np.log(data[gas].values)
    model = LinearRegression()
    model.fit(X, y)
    future_x = np.array([[-forecast_days]])
    predicted_log = model.predict(future_x)[0]
    predicted_concentration = np.exp(predicted_log)
    doubling_time = np.log(2) / abs(model.coef_[0]) if model.coef_[0] > 0 else None
    return {
        'current': data[gas].iloc[-1],
        f'forecast_{forecast_days}d': round(predicted_concentration, 1),
        'growth_rate_per_day': model.coef_[0],
        'doubling_time_days': round(doubling_time, 0) if doubling_time else None,
        'threshold_breach_days': estimate_days_to_threshold(data[gas].iloc[-1], predicted_concentration, dga_thresholds.get(gas, {}).get('alarm', float('inf')), forecast_days)
    }

Why Predictive Maintenance Reduces Costs by 30%

Compare: planned maintenance replaces oil every 12 months regardless of condition — that's an extra 40% cost. Our AI system analyzes the gas trend and schedules replacement only when thresholds are exceeded. Similarly with cables — partial discharge monitoring replaces annual high-voltage testing.

Predictive maintenance reduces maintenance costs by 1.5 times compared to planned maintenance. For cable lines, the benefit is 1.3 times.

Monitoring Cable Lines

Partial discharges in cables are an early indicator of insulation defects. The system analyzes peak discharge magnitude (pC) and repetition rate (PDIV):

def analyze_partial_discharge(pd_measurements: dict) -> dict:
    max_pd_pc = pd_measurements.get('max_pd_magnitude_pc', 0)
    pd_rate_per_minute = pd_measurements.get('pd_pulse_rate', 0)
    pd_location_m = pd_measurements.get('pd_location_tdr_m', None)
    if max_pd_pc > 1000:
        severity = 'critical'
        action = 'immediate_cable_replacement'
    elif max_pd_pc > 300:
        severity = 'major'
        action = 'schedule_replacement_3months'
    elif max_pd_pc > 100:
        severity = 'minor'
        action = 'enhanced_monitoring'
    else:
        severity = 'normal'
        action = 'routine_monitoring'
    return {'max_pd_pc': max_pd_pc, 'pd_rate': pd_rate_per_minute, 'pd_location_m': pd_location_m, 'severity': severity, 'action': action}

On one project, we prevented a cascading failure of 8 110 kV cables 3 months before expected damage.

Predicting Conductor Sag

Conductor heating from current and sun leads to sagging. The thermal model (IEEE 738) calculates conductor temperature and actual sag:

def calculate_sag_risk(weather_data: dict, line_parameters: dict) -> dict:
    I_amps = line_parameters['current_a']
    R_ohm_per_km = line_parameters['resistance_ohm_per_km']
    length_km = line_parameters['length_km']
    ambient_temp = weather_data['temperature_c']
    wind_speed = weather_data['wind_speed_ms']
    solar_radiation = weather_data.get('solar_irradiance_wm2', 0)
    joule_heating = I_amps**2 * R_ohm_per_km / 1000
    convective_cooling = (0.7 + 0.5 * wind_speed) * (80 - ambient_temp)
    solar_heating = solar_radiation * 0.015
    conductor_temp = ambient_temp + (joule_heating + solar_heating) / (convective_cooling + 1)
    base_sag_m = line_parameters.get('design_sag_m', 5.0)
    thermal_expansion = 0.023e-3 * (conductor_temp - 20) * length_km * 1000
    actual_sag_m = base_sag_m + thermal_expansion * 0.5
    clearance_violation = actual_sag_m > line_parameters.get('max_sag_m', 7.0)
    return {'conductor_temp_c': round(conductor_temp, 1), 'actual_sag_m': round(actual_sag_m, 2), 'clearance_violation': clearance_violation, 'thermal_limit_pct': min(100, conductor_temp / 90 * 100)}

How We Integrate AI with SAP PM

Risk data is transferred to SAP PM via REST API. The system automatically creates work orders when thresholds are exceeded. For report generation, we use a RAG module based on LlamaIndex with an LLM that extracts relevant fragments from corporate documentation. The RAG module accelerates report generation by 3 times. For adapting the language model to the enterprise specifics, we apply LoRA fine-tuning — this yields accurate responses without retraining the full model. LoRA fine-tuning is 5 times faster than full retraining.

What's Included in the Scope

• Equipment fleet diagnostics (1-2 days) — data collection, current state analysis, identification of critical nodes.
• Development of ML models for DGA, partial discharges, thermal calculations (4-5 weeks).
• Dashboard and alert setup (2 weeks) — Grafana, Telegram/Slack notifications.
• Integration with SAP PM / Maximo (3-4 months) — automatic work order creation by triggers.
• Pilot and staff training (1 month) — threshold adjustment, documentation handover.
• Technical support during operation.

How We Plan Risk-Based Maintenance

Risk matrix: failure probability × consequences (MWh undelivered × fines). Assets are ranked by expected losses. An ML algorithm optimizes the repair schedule, reducing downtime.

Order a pilot project for one transformer and see the effectiveness. Get a consultation on implementing predictive maintenance on your site — our engineers will assess your current fleet and propose an optimal solution within one day.

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.