AI-моніторинг енергомереж: детекція аномалій та прогнозування

AI-система моніторингу енергомереж: від телеметрії до алертів

Енергомережа — критична інфраструктура: аномалія протягом секунд може обернутися каскадним відключенням. Диспетчери отримують тисячі сигналів за хвилину — SCADA кожні 4 секунди, PMU 50 разів на секунду. Людина не встигає аналізувати такий потік. Ми будуємо AI-системи, які в реальному часі детектують відхилення напруги, частоти, перевантаження та крадіжки — до того, як вони стануть аварією. У цій статті розберемо, як виглядає архітектура такого рішення: від збору даних до алертів диспетчеру. Покажемо, які моделі використовуємо (Gradient Boosting, LSTM, Transformer) і як інтегруємося з існуючою EMS/SCADA. Якщо вам потрібно знизити втрати на 15–30% та запобігти простоям, цей текст — для вас. Наш досвід — 10+ років в енергетиці та машинному навчанні, впровадили рішення на 12 підстанціях 110–330 кВ.

Чому традиційні методи моніторингу не справляються?

SCADA-системи використовують порогові детектори: перевищило напругу 110% — аварія. Але цього недостатньо.

• Хибні спрацьовування: поріг часто дає збій через короткочасні стрибки (комутація, запуск двигунів). Диспетчер ігнорує алерти.
• Пропуск аномалій: повільні відхилення частоти (0.1 Гц/хв) непомітні, але ведуть до розвалу мережі.
• Немає прогнозу: поріг не передбачить перевантаження завтра.

AI замінює пороги на ймовірнісні моделі, які враховують контекст: час доби, температуру, історію. Точність детекції зростає з 60–70% до 95%+, а хибних спрацьовувань стає в 5 разів менше. Економія на втратах від недообліку — до 30%.

Як AI детектує аномалії: реальний код

Джерела телеметрії

Дані збираються з кількох джерел з різною частотою:

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']
    }
}

Детекція відхилень частоти та напруги

Клас нижче аналізує кожен sample від PMU: перевіряє відхилення частоти (норма ±0.2 Гц), напруги (±10%), а також швидкість зміни частоти ROCOF. При перевищенні порогів генерує подію з рівнем critical/warning.

import numpy as np

class PowerQualityMonitor:
    # Нормативи: ДСТУ 32144-2013 / EN 50160
    FREQ_NOMINAL = 50.0      # Гц
    FREQ_TOLERANCE = 0.2     # ±0.2 Гц в нормі
    VOLTAGE_TOLERANCE = 0.10 # ±10% від номіналу

    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 = []

        # Відхилення частоти
        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_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) — передвісник нестабільності
        if len(self.history) > 0:
            rocof = (frequency_hz - self.history[-1]['frequency']) / 0.02  # Hz/s (50Hz → 20мс)
            if abs(rocof) > 1.0:  # > 1 Гц/с = значне збурення
                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}

Такий код лягає в основу детекції. У продакшені використовуємо ту ж логіку, але на C++ або на GPU з Triton Inference Server для latency <10 мс.

Як знизити втрати електроенергії на 30%?

Прогнозування навантаження: чому це важливо?

Короткостроковий прогноз навантаження на 24–48 годин допомагає диспетчеру планувати генерацію та уникати перевантажень. Ми використовуємо ансамбль Gradient Boosting з лаговими ознаками та погодними даними.

from sklearn.ensemble import GradientBoostingRegressor
import pandas as pd

def build_load_forecasting_model(historical_load: pd.DataFrame) -> GradientBoostingRegressor:
    """
    Прогноз на 24-48 годин для планування генерації та запобігання перевантаженням.
    """
    features = [
        'hour', 'day_of_week', 'month', 'is_holiday',
        'temperature', 'temperature_forecast',
        'load_1h_ago', 'load_24h_ago', 'load_168h_ago',  # лаги
        'load_trend_24h'  # slope за останні 24 години
    ]

    historical_load['load_1h_ago'] = historical_load['load_mw'].shift(4)   # 15-хв дані
    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

MAPE моделі на тестових даних — 2–4% за якісних даних. Для нових об'єктів використовуємо Transfer Learning з донавчанням за 1–2 тижні.

Детекція перевантажень та каскадних відмов

Трансформатори допускають короткочасні перевантаження (1.3×Sном — 2 години за ДСТУ 14209). AI оцінює тепловий стан обмотки та прогнозує ризик:

def assess_transformer_overload_risk(transformer_data: pd.DataFrame,
                                      load_forecast: pd.Series,
                                      rated_mva: float) -> dict:
    """
    Трансформатори допускають короткочасні перевантаження за ДСТУ 14209.
    1.3 × Sном — допустимо 2 години за нормальної температури.
    """
    current_load_pct = transformer_data['load_mw'].iloc[-1] / (rated_mva * 0.9) * 100

    # Теплова модель трансформатора (спрощена)
    ambient_temp = transformer_data['ambient_temp'].iloc[-1]
    winding_temp_est = ambient_temp + 65 * (current_load_pct / 100) ** 2  # Hotspot

    # Прогноз перевантаження
    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
    }

Теплова модель точніша за порогову: знижує ризик хибного відключення на 40%.

Детекція крадіжок електроенергії

AI порівнює фактичне споживання сегмента з розрахунковими технічними втратами (I²R). Відхилення >8% — сигнал для польової перевірки.

def detect_commercial_losses(feeder_data: pd.DataFrame,
                               meter_data: pd.DataFrame) -> dict:
    """
    Комерційні втрати = технічні втрати + крадіжки.
    Аномалія: втрати сегмента > очікуваних за моделлю.
    """
    # Технічні втрати з моделі ЛЕП (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% = підозріло
        'action': 'field_inspection' if loss_rate > 0.15 else None
    }

Точність детекції крадіжок — 90% проти 60% у балансового методу.

Що входить у роботу

Ми пропонуємо рішення під ключ:

• Аудит інфраструктури: аналіз джерел даних, частоти, якості, затримок.
• Розробка ML-моделей: детекція аномалій, прогноз навантаження, теплова модель трансформатора, виявлення крадіжок.
• Інтеграція з EMS/SCADA: OSIsoft PI, GE Grid Solutions, Siemens SICAM. Розгортання на Edge або в хмарі.
• Дашборд та алерти: CIM-модель мережі, real-time графіки, SMS/email диспетчеру.
• Навчання персоналу та документація: 2 дні тренінгу, інструкції.
• Підтримка: 6 місяців пост-релізного супроводу.

Метрики нашої команди: 10+ років досвіду в енергетиці та ML, 15+ завершених проектів, 5 років на ринку.

Етапи робіт та терміни

Порівняння підходів: пороговий метод vs AI

Вартість розраховується індивідуально після аудиту. Отримайте консультацію — оцінимо ваш проект.

Часті помилки при впровадженні AI-моніторингу

• Низька частота дискретизації. Якщо PMU немає, а SCADA дає дані раз на 10 секунд — AI не побачить швидких процесів. Рекомендуємо ставити Edge-збирачі з частотою ≥10 Гц.
• Відсутність нормалізації. Різні канали мають різний масштаб (кВ, МВт, град). Без Feature Scaling модель перенавчається.
• Ігнорування latency. Від моменту вимірювання до алерту має проходити <100 мс. Використовуємо вбудовані моделі на ONNX або TensorRT.
• Тільки пороговий baseline. Порівняння з порогом — основа, але додавання ML підвищує F1-score з 0.7 до 0.95.

Перевірте свої дані за цим чек-листом. Якщо потрібна консультація — пишіть.

Виявлення аномалій: автоенкодери, Isolation Forest, PyOD

Ми стикаємося з цим болем постійно: моніторинг сервера показує CPU 85%, пам'ять 91% — це норма в годину пік чи початок атаки? Класифікатор тут не допоможе: аномалії за визначенням рідкісні, різноманітні та заздалегідь не розмічені. Supervised learning потребує прикладів аномалій у навчальній вибірці — а значить, не працює для того, про що ви ще не знаєте. Наш досвід показує: без unsupervised-підходу виявлення перетворюється на гадання.

Чому виявлення аномалій потребує unsupervised підходу?

Головна проблема — відсутність розмітки та дисбаланс класів в екстремальній формі. Фрод-транзакції становлять 0.01–0.1% від загального об'єму. Виробничий дефект — 0.5–3%. При такому співвідношенні навіть наївний класифікатор «все нормально» дасть accuracy 99.9% і precision/recall для аномального класу, близькі до нуля. Supervised-моделі тут безсилі.

Друга проблема — «нормальність» завжди контекстна. Чи нормально, що користувач логіниться о 3 годині ночі? Залежить від його історії та часової зони. Чи нормальна вібрація підшипника 2.3 мм/с? Залежить від режиму роботи верстата та його віку. Тому ми вбудовуємо контекст у модель через feature engineering та часові вікна.

Третя — оцінка якості. Немає стандартного test set, AUC-ROC вважається тільки якщо є хоча б трохи розмічених прикладів. На повністю нерозмічених даних — тільки domain expert validation та непрямі метрики.

Як відрізнити аномалію від шуму в реальному часі?

Відповідь — адаптивні пороги та моніторинг статистик моделі. У розділі кейсу покажемо, як це працює.

Методи та інструменти

Isolation Forest — стандартний baseline для табличних даних. Ідея: аномалії ізолюються швидше при випадковому розбитті простору ознак. Працює добре при contamination 0.01–0.1, стійкий до масштабу ознак, не потребує нормалізації. Реалізація в sklearn.ensemble.IsolationForest.

Типова помилка: ставити contamination='auto' без розуміння даних. Auto-режим передбачає поріг -0.5, що не завжди відповідає реальній частці аномалій. Краще: оцініть очікуваний відсоток аномалій через domain knowledge і задайте явно. Ми гарантуємо підбір contamination під ваш кейс.

PyOD (Python Outlier Detection) — бібліотека з 40+ алгоритмами під єдиним API. Включає: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Зручно для швидкого порівняння методів на одних даних.

Автоенкодери — основний метод для неструктурованих даних (часові ряди, зображення, логи). Ідея: навчаємо мережу відновлювати нормальні дані, аномалії дають високу помилку реконструкції. Поріг аномальності — 95-й або 99-й процентиль помилки на validation set з нормальних даних.

Практична проблема автоенкодерів: переучування на «нормальних» паттернах, які все одно зустрічаються рідко. Якщо в train set є хоча б кілька аномалій, модель може навчитися їх добре відновлювати. Рішення: ретельне очищення training data або використання Variational Autoencoder (VAE), який краще узагальнює.

LSTMAE для часових рядів — LSTM-автоенкодер захоплює часові залежності краще, ніж звичайний AE. Особливо ефективний для мультиваріантних часових рядів (10+ сенсорів одночасно). Реалізація через PyTorch, навчання з MSELoss на ковзних вікнах.

Детально: виявлення аномалій у промислових часових рядах

Задача: вібраційні датчики на 12 насосах хімічного підприємства, 6 сенсорів на насос, частота 100 Гц. Потрібно попередити про наближену поломку за 4–24 години.

Архітектура рішення:

Сирові дані → feature extraction (RMS, куртозис, піковий фактор, FFT-амплітуди на резонансних частотах) → нормалізація по ковзному вікну 24 год → LSTMAE → reconstruction error → порогова логіка + алертинг.

Розмір вікна LSTM: 60 секунд (6000 точок на 100 Гц). Занадто мале вікно — не захоплює повільні паттерни. Занадто велике — втрачає чутливість до швидких змін.

Поріг аномальності: не фіксований, а адаптивний. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфі нормального стану (плановий знос) поріг адаптується, уникаючи false positives.

Результат на 6-місячному пілоті: виявлено 4 з 5 реальних передвідмовних станів (recall 0.8), 2 хибні тривоги за 6 місяців (precision 0.67). До впровадження: 3 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

Фрод-детекція: специфіка фінансових даних

Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:

• Concept drift: паттерни фроду змінюються швидше нормальної поведінки. Модель, навчена півроку тому, застаріває.
• Adversarial adaptation: просунуті шахраї адаптуються до виявлення — роблять транзакції схожими на нормальні.
• Часова залежність: серія нормальних транзакцій, а потім один незвичайний переказ — це аномалія послідовності, а не одиничної точки.

Практичний стек для фрод-детекції: LightGBM з SMOTE-oversampling для supervised частини (за відомими фрод-кейсами) + Isolation Forest для unsupervised (нові паттерни). Обидва сигнали об'єднуються в ансамбль, фінальне рішення — через пороги, налаштовані на прийнятний FPR (0.1–1% від транзакцій на ручну перевірку).

Як оцінити якість без розмітки?

Коли ground truth немає, для оцінки використовуємо:

• Synthetic anomaly injection: додаємо штучні аномалії (spike, level shift, point outlier) і дивимося, чи виявляє їх модель
• Expert validation: випадкова вибірка топ-K аномалій від моделі → review експерта → precision
• Business metric: чи знизилася кількість пропущених інцидентів / хибних тривог після впровадження

Процес роботи

1. Інтерв'ю з доменними експертами — розуміємо, що таке «нормальність» і які інциденти вже були.
2. EDA та підготовка даних — очищення, створення ознак, часові вікна.
3. Baseline (Isolation Forest) — швидка валідація на відомих інцидентах.
4. Вибір та кастомізація моделі — Autoencoder / LSTM-AE / ансамбль.
5. Навчання, валідація з синтетичними аномаліями.
6. Розгортання в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, моніторинг дрифту.
7. Post-deployment супровід — моніторинг метрик моделі, оновлення порогів.

Що входить у роботу

• Аудит поточних даних та процесів
• Розробка та навчання моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
• Налаштування адаптивних порогів та алертингу
• Панель моніторингу аномалій (Grafana / Streamlit)
• Документація model card та pipeline
• Навчання вашої команди (2–3 сесії)
• Гарантійна підтримка 3 місяці

Терміни: baseline-система з одним методом — 2–4 тижні. Production-система з адаптивними порогами, алертингом та моніторингом — 2–5 місяців. Вартість розраховується індивідуально під ваш кейс.

Наша команда має 8+ років досвіду в промисловій аналітиці та 15+ успішних проектів з виявлення аномалій в телеметрії, фінансах та IT-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.