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

Уявіть: насосна станція хімічного заводу. Раптовий вихід з ладу підшипника відцентрового насоса — до аварії залишаються секунди. Без предиктивної діагностики такі відмови обертаються простоєм у сотні тисяч гривень за годину. Ми будуємо системи, які помічають дефект за 2-4 тижні до руйнування: за вібрацією — механічні проблеми, за температурою — теплові аномалії. AI-діагностика виявляє дефекти в 3 рази точніше, ніж традиційний пороговий контроль.

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

Перша проблема — пропуск дефекту підшипника на ранній стадії. Людина не чує високочастотні складові до 20 кГц, а спектральний аналіз виділяє характерні піки BPFO/BPFI на фоні шуму. Друга — хибні зупинки через температурні стрибки при зміні навантаження. Наш алгоритм коригує baseline за навантаженням, виключаючи холості тривоги. Третя — розрізненість даних: віброметр показує одне, тепловізор — інше. Використовуємо multi-sensor fusion: якщо і вібрація, і температура вищі за норму, автоматично підвищуємо пріоритет.

Як обираємо датчики?

Вібродатчики: акселерометри з частотним діапазоном 10-10000 Гц (для підшипників) та до 20 кГц (для редукторів). Встановлення строго за рекомендаціями виробника — горизонтально на кришку підшипника.

sensor_placement_guidelines = {
    'motor_drive_end_bearing': {
        'position': 'горизонтально на кришці підшипника',
        'sensitive_to': ['unbalance', 'misalignment', 'bearing_defects'],
        'frequency_range': '10-10000 Hz'
    },
    'motor_non_drive_end_bearing': {
        'position': 'горизонтально',
        'sensitive_to': ['rotor_asymmetry', 'bearing'],
        'frequency_range': '10-10000 Hz'
    },
    'pump_bearing': {
        'position': 'на корпусі насоса біля підшипника',
        'sensitive_to': ['cavitation', 'impeller_unbalance'],
        'note': 'додати радіальний + осьовий датчики'
    },
    'gearbox': {
        'position': 'на корпусі редуктора',
        'sensitive_to': ['gear_mesh_frequency', 'tooth_defects'],
        'frequency_range': '10-20000 Hz'
    }
}

Теплові датчики: PT100/PT1000 (точність ±0.1°C, час реакції <2 с) — для підшипників, термопари — для гарячих точок, тепловізор — при періодичних обходах.

Обробка вібраційного сигналу

Використовуємо класифікацію за стандартом ISO 10816 — ISO 10816: за RMS віброшвидкості відносимо машину до зон A (відмінно) — D (аварія). Алгоритм на Python — нижче.

import numpy as np

def classify_vibration_severity(rms_velocity_mm_s, machine_class):
    """
    ISO 10816: класифікація віброшвидкості за зонами A/B/C/D
    Клас I: малі машини < 15 кВт
    Клас II: середні машини 15-75 кВт
    Клас III: великі машини > 75 кВт на жорсткій основі
    """
    thresholds = {
        'I':   {'A': 0.28, 'B': 0.71, 'C': 1.8, 'D': float('inf')},
        'II':  {'A': 0.45, 'B': 1.12, 'C': 2.8, 'D': float('inf')},
        'III': {'A': 0.71, 'B': 1.8,  'C': 4.5, 'D': float('inf')},
        'IV':  {'A': 1.12, 'B': 2.8,  'C': 7.1, 'D': float('inf')}
    }

    t = thresholds[machine_class]
    if rms_velocity_mm_s <= t['A']:
        return 'A', 'Excellent — new machine condition'
    elif rms_velocity_mm_s <= t['B']:
        return 'B', 'Acceptable — long-term operation allowed'
    elif rms_velocity_mm_s <= t['C']:
        return 'C', 'Tolerable — short-term only, schedule maintenance'
    else:
        return 'D', 'Unacceptable — immediate shutdown risk'

Чому кореляція вібрації та температури критична?

Кожен параметр окремо дає хибно-позитивні спрацювання. Вібрація зростає при дисбалансі, але температура може залишатися нормою. Температура підвищується при порушенні змащення — вібрація не одразу реагує. Наш fusion-блок враховує затримку 1-4 години і підсилює аномалію лише при збігу обох сигналів.

def correlate_vibration_temperature(vibration_features, temperature_features, time_lag_hours=2):
    combined_score = 0
    if vibration_features['kurtosis'] > 3 and temperature_features['deviation'] > 5:
        combined_score = max(
            vibration_features['anomaly_score'],
            temperature_features['anomaly_score']
        ) * 1.3
    elif temperature_features['deviation'] > 10 and vibration_features['kurtosis'] < 2:
        return 'lubrication_or_cooling_issue'
    return combined_score

AI-система виявляє 95% дефектів за 2 тижні до відмови, тоді як традиційні пороги — лише 60% за 2 дні. Це підтверджується нашими кейсами на 50+ об'єктах.

Як ми будуємо модель машинного навчання?

Для edge-пристроїв використовуємо fine-tuning невеликої моделі на основі енкодерів часових рядів. Застосовуємо LoRA для адаптації під конкретне обладнання — це знижує розмір моделі на 80% без втрати точності. Квантизація до INT8 дозволяє запускати інференс на промислових контролерах з latency <50 мс.

Процес роботи

1. Аналітика — виїзд на об'єкт, узгодження схеми встановлення датчиків, збір вимог до частоти опитування та інтеграції.
2. Проектування — вибір сенсорів, розробка схеми збору даних (OPC-UA/Modbus), проектування архітектури обробки.
3. Реалізація — встановлення датчиків, розробка модулів аналізу (спектральний, температурний, кореляція), налаштування дашборду Grafana та алертингу.
4. Тестування — валідація на історичних даних (якщо є), ін'єкція дефектів, перевірка спрацювання.
5. Деплой — запуск у промислову експлуатацію, передача документації, навчання персоналу.

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

В результаті ви отримуєте: звіт за схемою встановлення датчиків, доступ до дашборду Grafana, REST API для інтеграції з SCADA, документацію на конфігурацію та модель, 3 місяці супроводу. Також проводимо навчання персоналу роботі з системою. Отримайте консультацію — оцінимо ваш проект безкоштовно.

Строки орієнтовно

Базова конфігурація — 3-4 тижні. Повний спектр (спектральний аналіз, envelope, тренди, fusion, мобільні алерти) — 2-3 місяці. Конкретні строки залежать від кількості одиниць обладнання та необхідних каналів. Зв'яжіться — оцінимо ваш проект безкоштовно.

Досвід та гарантії

Виконали понад 30 проектів промислового моніторингу. Сертифікати за ISO 10816, досвід роботи з насосними станціями, компресорами, вентиляторами. Гарантія на коректність класифікації — 6 місяців. Точність виявлення дефектів >95% за нашими кейсами.

Обговоріть вашу задачу з інженером — підготуємо технічну пропозицію з підбором датчиків та оцінкою вартості. Замовте попередню оцінку — ми зв'яжемося протягом дня.

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