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 лет на рынке.
Этапы работ и сроки
| Этап | Длительность | Результат |
|---|---|---|
| Анализ и сбор данных | 1–2 недели | Отчёт по источникам, частоты, качество |
| Разработка прототипа (базовые модели) | 4–6 недель | Детекция аномалий + прогноз нагрузки, дашборд |
| Полное развёртывание (хищения, тепловая модель, интеграция) | 3–4 месяца | Продакшен-система, обучение, документация |
Сравнение подходов: пороговый метод vs AI
| Параметр | Пороговый метод | AI-метод |
|---|---|---|
| Точность детекции | 60–70% | 95%+ |
| Ложные срабатывания | ~30% | ~5% |
| Прогнозирование | нет | есть (MAPE 2–4%) |
| Адаптация к условиям | ручная настройка | автоматическая |
| Снижение потерь | до 5% | до 30% |
Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим ваш проект.
Частые ошибки при внедрении AI-мониторинга
- Низкая частота дискретизации. Если PMU нет, а SCADA даёт данные раз в 10 секунд — AI не увидит быстрых процессов. Рекомендуем ставить Edge-сборщики с частотой ≥10 Гц.
- Отсутствие нормализации. Разные каналы имеют разный масштаб (кВ, МВт, град). Без Feature Scaling модель переобучается.
- Игнорирование latency. От момента измерения до алерта должно проходить <100 мс. Используем встраиваемые модели на ONNX или TensorRT.
- Только пороговый baseline. Сравнение с порогом — основа, но добавление ML повышает F1-score с 0.7 до 0.95.
Проверьте свои данные по этому чек-листу. Если нужна консультация — пишите.







