Разработка AI-системы прогнозирования отказов оборудования

Неожиданный отказ компрессора в три часа ночи — внеплановый простой, потери миллионов, срыв поставок. Традиционный пороговый мониторинг фиксирует отклонение уже после выхода за границы, когда ремонт неизбежен. Система прогнозирования отказов (Failure Prediction) строит временную модель деградации и предупреждает за 7–30 дней, улавливая скрытые паттерны во временных рядах сенсоров и вычисляя остаточный ресурс (RUL).

Мы разрабатываем такие системы под ключ: от сбора и разметки данных до интеграции с CMMS и автоматического назначения ТО. В основе — деградационные модели, оценка RUL и машинное обучение с калибровкой вероятностей, чтобы алерты были точными, а не шумом.

Какие проблемы решаем

Дисбаланс классов. Типичное соотношение: 1 отказ на 50–200 дней нормальной работы. Без специальных методов модель будет предсказывать «всё хорошо», игнорируя редкие события. Мы используем взвешенные функции потерь (scale_pos_weight в XGBoost), синтетическую аугментацию (SMOTE-Tomek) и cost-sensitive learning с матрицей, где пропуск отказа в 20 раз дороже ложной тревоги.

Выбор горизонта прогноза. Слишком короткий горизонт (1–3 дня) не даёт времени на реакцию; слишком длинный (60+ дней) — высокая неопределённость. Мы подбираем горизонт по ROC-анализу на исторических данных: обычно 7–30 дней — оптимум для промышленного оборудования.

Калибровка вероятностей. XGBoost и нейросети часто выдают некалиброванные вероятности. Модель может говорить «вероятность отказа 70%», а на практике отказ случается лишь в 30% таких случаев. Мы применяем Isotonic Regression (Platt Scaling реже) на отложенной выборке — это снижает false alarm rate на 30–50%.

Как мы строим систему Failure Prediction

Деградационная модель и RUL Estimator

Моделируем процесс ухудшения состояния через регрессию на days_to_failure или выживаемостный анализ. Ключевой приём — обучать модель только на окне 90 дней до отказа, исключая длительные периоды нормальной работы.

import pandas as pd import numpy as np from sklearn.model_selection import TimeSeriesSplit from xgboost import XGBRegressor def train_rul_model(features_df, target_col='days_to_failure'): train_data = features_df[features_df[target_col] <= 90].dropna(subset=[target_col]) X = train_data.drop(columns=[target_col, 'label', 'timestamp', 'asset_id']) y = np.log1p(train_data[target_col]) tscv = TimeSeriesSplit(n_splits=5) model = XGBRegressor(n_estimators=300, learning_rate=0.05, max_depth=6, subsample=0.8) model.fit(X, y) return model 

Для учёта цензурированных данных (актив ещё работает) используем Weibull AFT из библиотеки lifelines — он корректно обрабатывает такие случаи и даёт интервальные прогнозы.

Многозадачная LSTM с attention

Отметим: когда накоплено достаточно истории (10+ циклов на актив), переходим к LSTM. Одна модель одновременно предсказывает RUL, вероятность отказа на горизонтах 7/14/30 дней и стадию деградации (норма, начало, прогрессивная, критическая). Для LSTM прогнозирования отказов используем архитектуру с механизмом внимания.

import torch.nn as nn class FailurePredictionLSTM(nn.Module): def __init__(self, input_dim, hidden_dim=128, num_layers=2): super().__init__() self.lstm = nn.LSTM(input_dim, hidden_dim, num_layers, batch_first=True, dropout=0.2) self.attention = nn.MultiheadAttention(hidden_dim, num_heads=4, batch_first=True) self.rul_head = nn.Sequential(nn.Linear(hidden_dim, 64), nn.ReLU(), nn.Linear(64, 1)) self.failure_head = nn.Sequential(nn.Linear(hidden_dim, 64), nn.ReLU(), nn.Linear(64, 3), nn.Sigmoid()) self.stage_head = nn.Linear(hidden_dim, 4) def forward(self, x): lstm_out, _ = self.lstm(x) attn_out, _ = self.attention(lstm_out, lstm_out, lstm_out) pooled = attn_out.mean(dim=1) return {'rul': self.rul_head(pooled), 'failure_prob': self.failure_head(pooled), 'stage': self.stage_head(pooled)} 

XGBoost vs LSTM: на практике XGBoost с временными окнами даёт Precision@7 = 0.75–0.85, LSTM — 0.80–0.90, но требует в 3–5 раз больше данных. XGBoost быстрее в 5–7 раз в обучении, что делает его предпочтительным для старта. LSTM внедряем на втором этапе, когда накоплен достаточный объём истории.

Почему калибровка вероятностей критична?

Некорректированные вероятности ведут к лавине ложных срабатываний или пропущенным отказам. Ниже — итоговая калибровка через Isotonic Regression:

from sklearn.isotonic import IsotonicRegression def calibrate_probabilities(raw_probs, true_labels): calibrator = IsotonicRegression(out_of_bounds='clip') calibrator.fit(raw_probs, true_labels) return calibrator 

В реальном проекте для компрессорной станции калибровка снизила false alarm rate с 12 до 4 событий на актив в месяц, а coverage (доля предсказанных отказов) выросла с 60% до 87%. Экономия для заказчика составила $11k–16k в первый год за счёт сокращения внеплановых простоев. В среднем по нашим проектам экономия составляет около $14k–20k в год на один критический актив.

Как выбрать порог принятия решений?

Учитываем стоимость ошибок: пропуск отказа — 100 условных единиц, лишняя проверка — 5. Порог смещается вниз, делая модель более чувствительной. Оптимальный порог находим на валидации по минимальной суммарной стоимости.

def find_optimal_threshold(probs, labels, cost_fn=100, cost_fp=5): thresholds = np.arange(0.05, 0.95, 0.01) best = 0.5 min_cost = float('inf') for t in thresholds: preds = (probs >= t).astype(int) total = np.sum((preds == 0) & (labels == 1)) * cost_fn + np.sum((preds == 1) & (labels == 0)) * cost_fp if total < min_cost: min_cost = total best = t return best 

Процесс внедрения

1. Анализ данных: размечаем отказы, строим временные окна — датасет с метками и признаками.
2. Baseline: XGBoost Failure Classifier + базовый RUL — точность 70–80%.
3. Улучшение: LSTM, калибровка, оптимизация порогов — точность 85–95%.
4. Интеграция: Webhook в CMMS, дашборд алертов — автоматическое расписание ТО.
5. Мониторинг: Drift detection, переобучение — система работает стабильно.

Сравнение методов прогнозирования

Сроки и что вы получите

• Failure Classifier + базовый RUL + алерты — 4–5 недель.
• LSTM, выживаемостный анализ, полная интеграция с расписанием ТО — 3–4 месяца.

Отметим: что входит: обученная модель, API для интеграции, веб-дашборд с алертами и метриками, документация, обучение команды, поддержка 3 месяца после запуска.

Наш опыт: 5+ лет в промышленном ML, 20+ проектов по predictive maintenance, инженеры с сертификатами по MLflow и Kubernetes. Мы гарантируем качество — каждый этап закрывается чек-листом.

Свяжитесь с нами для предварительного анализа ваших данных — подберём архитектуру и оценим потенциальную экономию (до 30% затрат на ремонт). Закажите консультацию, чтобы узнать, как наш подход работает на вашем оборудовании.