Неожиданный отказ компрессора в три часа ночи — внеплановый простой, потери миллионов, срыв поставок. Традиционный пороговый мониторинг фиксирует отклонение уже после выхода за границы, когда ремонт неизбежен. Система прогнозирования отказов (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%. Экономия для заказчика составила 1,2 млн рублей в первый год за счёт сокращения внеплановых простоев. В среднем по нашим проектам экономия составляет около 1,5 млн рублей в год на один критический актив.
Как выбрать порог принятия решений?
Учитываем стоимость ошибок: пропуск отказа — 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
Процесс внедрения
- Анализ данных: размечаем отказы, строим временные окна — датасет с метками и признаками.
- Baseline: XGBoost Failure Classifier + базовый RUL — точность 70–80%.
- Улучшение: LSTM, калибровка, оптимизация порогов — точность 85–95%.
- Интеграция: Webhook в CMMS, дашборд алертов — автоматическое расписание ТО.
- Мониторинг: Drift detection, переобучение — система работает стабильно.
| Этап | Что делаем | Результат |
|---|---|---|
| 1. Анализ данных | Размечаем историю отказов, строим временные окна | Датасет с метками и признаками |
| 2. Baseline | XGBoost Failure Classifier + базовый RUL | Точность 70–80% |
| 3. Улучшение | LSTM, калибровка, оптимизация порогов | Точность 85–95% |
| 4. Интеграция | Webhook в CMMS, дашборд алертов | Автоматическое расписание ТО |
| 5. Мониторинг | Drift detection, переобучение | Система работает стабильно |
Сравнение методов прогнозирования
| Параметр | XGBoost | LSTM | Survival Analysis |
|---|---|---|---|
| Точность (Precision@7) | 0.75–0.85 | 0.80–0.90 | 0.65–0.75 |
| Требования к данным | 3–6 циклов | 10+ циклов | 20+ циклов |
| Скорость обучения | 5–15 мин | 1–4 часа | 10–30 мин |
| Устойчивость к шуму | Средняя | Высокая | Низкая |
Типичные ошибки при внедрении
- Использовать всю историю 1:1 — ухудшает качество. Нужно ограничивать окно до отказа.
- Не учитывать цензурирование — Survival Analysis вместо регрессии.
- Ставить единый порог для всего парка — настраиваем под критичность каждого актива.
- Забывать про калибровку — ведёт к недоверию операторов.
Сроки и что вы получите
- Failure Classifier + базовый RUL + алерты — 4–5 недель.
- LSTM, выживаемостный анализ, полная интеграция с расписанием ТО — 3–4 месяца.
Отметим: что входит: обученная модель, API для интеграции, веб-дашборд с алертами и метриками, документация, обучение команды, поддержка 3 месяца после запуска.
Наш опыт: 5+ лет в промышленном ML, 20+ проектов по predictive maintenance, инженеры с сертификатами по MLflow и Kubernetes. Мы гарантируем качество — каждый этап закрывается чек-листом.
Свяжитесь с нами для предварительного анализа ваших данных — подберём архитектуру и оценим потенциальную экономию (до 30% затрат на ремонт). Закажите консультацию, чтобы узнать, как наш подход работает на вашем оборудовании.