Розробка 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%. Це принесло замовнику значну економію за рахунок скорочення позапланових простоїв. В середньому за нашими проектами економія є значною на один критичний актив.

Як обрати поріг прийняття рішень?

Враховуємо вартість помилок: пропуск відмови — 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% витрат на ремонт). Замовте консультацію, щоб дізнатися, як наш підхід працює на вашому обладнанні.