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

Уявіть: завод із тисячами електродвигунів, насосів та компресорів. Одна раптова відмова може призвести до тривалої зупинки та значних збитків. Більшість підприємств живуть за регламентом заміни «через 1000 годин роботи», хоча реальний стан агрегатів — загадка до останнього. Ми будуємо AI-систему предиктивного обслуговування (PdM), яка знімає невизначеність.

Використовуємо дані з датчиків вібрації, струму, температури. Навчаємо моделі розпізнавати зароджувані дефекти за 2-6 тижнів до відмови. Підключаємо до CMMS, щоб Work Order створювався автоматично. Замовник отримує Health Index для кожного активу, рекомендації щодо часу ТО та прозорий ROI. Наш досвід — 5+ років у промисловому AI, десятки впроваджених систем. PdM скорочує позапланові простої в 3-5 разів порівняно з плановим обслуговуванням.

Які проблеми вирішує AI-система предиктивного обслуговування?

• Несподівані простої: традиційне ТО — за регламентом або після відмови. Ми прогнозуємо залишковий ресурс (RUL) і виставляємо точну дату ТО.
• Неоптимальна частота обслуговування: занадто часто — перевитрата, занадто рідко — ризик. Оптимізуємо на основі FMEA та економічної моделі.
• Хибні тривоги: стандартні порогові методи дають 30-60% хибних спрацювань. Ансамбль ML-моделей знижує FP до 5%.

Як ми будуємо систему: платформенна архітектура

Система охоплює всі рівні від датчиків до бізнес-KPI:

Рівень 0: Edge (на обладнанні)
    Модулі: vibration sensor, temperature sensor, current meter
    Протокол: Modbus RTU / OPC-UA
    Edge gateway: Raspberry Pi / Industrial PC

Рівень 1: Fog (цеховий рівень)
    OPC-UA Server → MQTT broker → Edge computing node
    Локальне зберігання та первинна обробка

Рівень 2: Cloud (корпоративний рівень)
    Kafka → TimescaleDB / InfluxDB
    ML Training Pipeline (Airflow + MLflow)
    Inference Service (FastAPI)

Рівень 3: Business
    CMMS / ERP інтеграція
    KPI Dashboard (Grafana / Tableau)
    Mobile app для техніків

Для кожного активу заводиться запис в Asset Registry:

@dataclass
class Asset:
    asset_id: str
    name: str
    type: AssetType  # motor, pump, compressor, conveyor, gearbox
    manufacturer: str
    model: str
    install_date: datetime
    rated_power_kw: float
    location: dict  # plant, line, cell
    criticality: int  # 1-5 (5 = most critical)
    sensors: list[SensorConfig]
    maintenance_history: list[WorkOrder]
    failure_modes: list[FailureMode]  # з FMEA документу

FMEA-driven аналіз відмов: основа прогнозу — розробка AI системи

Замість чорного ящика ми використовуємо FMEA — документуємо кожну очікувану відмову, її ознаки та типовий час розвитку. Приклад для електродвигуна:

failure_modes_motor = [
    FailureMode(
        name='bearing_outer_race_defect',
        detection_method='vibration_envelope_bpfo',
        leading_indicators=['kurtosis > 3', 'bpfo_amplitude_rise'],
        typical_development_days=30,
        severity=4
    ),
    FailureMode(
        name='stator_winding_degradation',
        detection_method='motor_current_signature_mcsa',
        leading_indicators=['current_imbalance > 5%', 'sideband_frequencies'],
        typical_development_days=60,
        severity=5
    ),
    FailureMode(
        name='misalignment',
        detection_method='vibration_1x_2x',
        leading_indicators=['high_1x_radial', '2x_axial_component'],
        typical_development_days=14,
        severity=3
    )
]

Ієрархічний Health Index: від датчика до заводу

Health Index — від 0 (відмова) до 1 (ідеально). Розраховується на кожному рівні: датчик → актив → лінія → цех. Для кожного failure mode своя ML-модель, результат агрегується з вагою за severity:

class AssetHealthEnsemble:
    def __init__(self, failure_modes, weights=None):
        self.failure_modes = failure_modes
        self.models = {fm.name: load_model(fm) for fm in failure_modes}
        self.weights = weights or {fm.name: fm.severity for fm in failure_modes}

    def compute_health(self, sensor_data):
        fm_scores = {}
        for fm_name, model in self.models.items():
            features = extract_features_for_fm(sensor_data, fm_name)
            failure_prob = model.predict_proba([features])[0][1]
            fm_scores[fm_name] = 1.0 - failure_prob
        weighted_health = sum(score * self.weights[name] for name, score in fm_scores.items()) / sum(self.weights.values())
        min_score = min(fm_scores.values())
        if min_score < 0.3:
            weighted_health = min(weighted_health, min_score * 1.5)
        return weighted_health, fm_scores

Здоров'я всього заводу — зважене середнє за критичністю активів. Критичний дефект на одному агрегаті знижує загальний індекс.

Оптимізація часу ТО: баланс витрат і ризику

Шукаємо баланс між вартістю ТО та ризиком відмови. Модель використовує розподіл залишкового ресурсу (RUL) і вирішує задачу мінімізації очікуваних витрат:

from scipy.optimize import minimize_scalar

def optimal_maintenance_time(rul_distribution, maintenance_cost, failure_cost, holding_cost_per_day):
    def expected_cost(t_maintenance):
        p_failure_before_maintenance = rul_distribution.cdf(t_maintenance)
        cost_if_maintain = maintenance_cost + t_maintenance * holding_cost_per_day
        cost_if_fail = failure_cost * p_failure_before_maintenance
        return cost_if_maintain * (1 - p_failure_before_maintenance) + cost_if_fail

    result = minimize_scalar(expected_cost, bounds=(1, 180), method='bounded')
    return result.x  # оптимальна кількість днів до ТО

Результат — Work Order з конкретним терміном та пріоритетом. На одному цементному заводі такий алгоритм передбачив відмову підшипника млина за 18 днів, що дозволило провести заміну в плановий простій і уникнути аварійної зупинки. ROI системи склав 400% за перший рік.

Порівняння підходів до обслуговування

Що дає предиктивне обслуговування на практиці?

Типові результати через 6 місяців після впровадження: зниження позапланових простоїв на 70-80%, збільшення міжремонтного інтервалу на 30%, скорочення витрат на ТО на 20%. Система автоматично генерує Work Order в CMMS (SAP, 1С) на основі прогнозу, без участі людини.

Що входить в роботу

• Аудит обладнання та збір даних (архів SCADA, логи, схема)
• Проектування архітектури IoT-мережі та edge-пристроїв
• Створення Asset Registry та FMEA-моделі
• Розробка ML-моделей (вібрація, струм, температура) та ансамблю
• Деплой моделі на edge/cloud з inference сервісом
• Інтеграція з CMMS (SAP, 1С, власні системи)
• Dashboard Health Index та KPIs (Grafana / Tableau)
• Навчання техніків роботі з системою
• Підтримка протягом 6 місяців після запуску

Які гарантії ми даємо?

Наша команда — 5+ років у промисловому AI та IoT. 10+ впроваджень на заводах України та СНД. Гарантуємо якість: якщо система не підтвердить свою ефективність протягом 3 місяців — доопрацюємо безкоштовно.

Строки та вартість

Базове рішення (до 10 активів) — 8-10 тижнів. Повномасштабна система (100+ активів) — 5-8 місяців. Вартість розраховується індивідуально. Зв'яжіться з нами для оцінки вашого проекту — отримайте консультацію інженера.

Отримайте розрахунок для вашого заводу. Замовте попередній аудит.

Виявлення аномалій: автоенкодери, 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 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

Фрод-детекція: специфіка фінансових даних

Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:

• 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-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.