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 незапланированных остановки по $40k каждая. Экономия после внедрения — $120k за полгода (отчёт о пилоте на объекте клиента).

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

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

• 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-мониторинге. Получите консультацию — расскажем, как решить вашу задачу.