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