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

Енергетичне обладнання — трансформатори, кабелі, вимикачі — виходить з ладу з сигналами зносу за тижні та місяці до аварії. Перехід від планово-попереджувального ТО до предиктивного знижує витрати на 20-30% та виключає незаплановані відключення. На об'єкті з 10 трансформаторами економія бюджету ТО досягає 4 млн грн на рік, а строк окупності системи — менше 12 місяців.

Незаплановане відключення трансформатора 110 кВ тягне штрафи, простий виробництва та репутаційні втрати. За статистикою, 70% відмов силових трансформаторів пов'язані з дефектами ізоляції. Ці дефекти проявляються за 3-6 місяців до аварії. Традиційні методи діагностики — періодичні виміри DGA (Dissolved Gas Analysis) раз на рік — часто пропускають різке погіршення. Наша AI-система моніторить DGA, часткові розряди та теплові режими в реальному часі, передбачаючи відмову з точністю до 90%.

За даними наших проектів, AI-прогноз знижує кількість аварійних відключень у 4 рази порівняно з плановим ТО. При цьому строк окупності системи становить менше року.

Як AI передбачає відмову трансформатора?

DGA — головний індикатор стану масла. Ми використовуємо пороги та відношення газів за стандартом IEEE C57.104 для класифікації дефектів. Ось приклад коду для діагностики:

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)}
    }

Тренд газів — прогноз деградації. Лінійна регресія на логарифмі концентрації виявляє прискорення дефекту:

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)
    }

Чому предиктивне обслуговування знижує витрати на 30%?

Порівняйте: планове ТО замінює масло кожні 12 місяців незалежно від стану — це зайві 40% витрат. Наша AI-система аналізує тренд газів і призначає заміну тільки при перевищенні порогу. Аналогічно з кабелями — моніторинг часткових розрядів замінює щорічні випробування високою напругою.

Предиктивне обслуговування скорочує витрати на ТО в 1.5 рази порівняно з плановим. Для кабельних ліній вигода — в 1.3 рази.

Моніторинг кабельних ліній

Часткові розряди в кабелі — ранній індикатор дефекту ізоляції. Система аналізує пікову величину розряду (pC) та швидкість повторення (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}

На одному з проектів ми запобігли каскадній відмові 8 кабелів 110 кВ за 3 місяці до очікуваного пошкодження.

Прогнозування провисання проводу

Нагрів проводу струмом та сонцем веде до провисання. Теплова модель (IEEE 738) розраховує температуру провідника та фактичну стрілу провесу:

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)}

Як ми інтегруємо AI з SAP PM?

Дані про ризики передаються в SAP PM через REST API. Система автоматично створює наряди на ремонт при перевищенні порогів. Для генерації звітів використовуємо RAG-модуль на основі LlamaIndex з LLM, який витягує релевантні фрагменти з корпоративної документації. RAG-модуль прискорює формування звітів у 3 рази. Для адаптації мовної моделі під специфіку підприємства застосовуємо LoRA fine-tuning — це дозволяє отримувати точні відповіді без перенавчання всієї моделі. LoRA fine-tuning в 5 разів швидший за повне перенавчання.

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

• Діагностика парку обладнання (1-2 дні) — збір даних, аналіз поточного стану, виявлення критичних вузлів.
• Розробка ML-моделей DGA, часткових розрядів, теплових розрахунків (4-5 тижнів).
• Збірка дашборду та алертів (2 тижні) — Grafana, Telegram/Slack сповіщення.
• Інтеграція з SAP PM / Maximo (3-4 місяці) — автоматичне створення нарядів по тригерах.
• Пілотування та навчання персоналу (1 місяць) — коригування порогів, передача документації.
• Технічна підтримка на етапі експлуатації.

Як ми плануємо ТО на основі ризику?

Ризик-матриця: ймовірність відмови × наслідки (кВт·год недоотпуску × штрафи). Об'єкти ранжуються за очікуваними втратами. ML-алгоритм оптимізує графік ремонтів, скорочуючи час простоїв.

Замовте пілотний проект для одного трансформатора і переконайтеся в ефективності. Отримайте консультацію щодо впровадження предиктивного обслуговування на вашому об'єкті — наші інженери оцінять поточний парк і запропонують оптимальне рішення за один день.

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