Неочікувана відмова компресора о третій ночі — позаплановий простій, втрати мільйонів, зрив поставок. Традиційний пороговий моніторинг фіксує відхилення вже після виходу за межі, коли ремонт неминучий. Система прогнозування відмов (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%. Це принесло замовнику значну економію за рахунок скорочення позапланових простоїв. В середньому за нашими проектами економія є значною на один критичний актив.
Як обрати поріг прийняття рішень?
Враховуємо вартість помилок: пропуск відмови — 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% витрат на ремонт). Замовте консультацію, щоб дізнатися, як наш підхід працює на вашому обладнанні.