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







