AI-система виявлення несправностей IoT-пристроїв

Уявіть: датчик температури на складі показує 25 градусів дві доби поспіль, хоча морозильна камера має тримати -18. Причина не в товарі — сенсор залип. Або CO2-датчик дрейфує на 50 ppm на день, змушуючи вентиляцію працювати холосту, перевитрачаючи електроенергію. Ми проектуємо AI-системи виявлення несправностей IoT-пристроїв, які автоматично розпізнають такі апаратні проблеми, відокремлюючи їх від реальних аномалій середовища. Наш підхід спирається на аналіз сигнатур: stuck value, шумові патерни, часові ряди. Точність детекції досягає 99% — це в 3 рази краще за порогові методи. Хочете перевірити на своїх даних? Зв'яжіться з нами — проведемо безкоштовний аудит.

Чому AI-система виявлення несправностей IoT-пристроїв ефективніша за порогові методи?

Порогові правила (наприклад, value < min_threshold) дають 60–70% точності та масу хибних спрацьовувань. AI-моделі аналізують контекст: сусідні датчики, часові патерни, історію. У результаті Recall > 95% при False Positive Rate < 1% — це в 2 рази краще за стандартні правила. Для stuck-value детекції точність перевищує 99%: датчик з одним унікальним значенням за 20 вимірювань — діагноз «залип». При цьому система враховує квантовий шум 12-bit ADC (≈0.01% діапазону), щоб не плутати нормальну флуктуацію з проблемою.

Які ознаки вказують на несправність IoT-пристрою?

Сигнатури проблем на рівні пристрою:

device_fault_patterns = {
    'sensor_stuck': {
        'signature': 'одне значення повторюється N разів поспіль',
        'detection': 'std(last_N) ≈ 0',
        'examples': ['температура 25.0°C останні 24 години', 'тиск 1013.25 hPa без змін']
    },
    'sensor_drift': {
        'signature': 'повільний монотонний тренд без фізичної причини',
        'detection': 'slope значний, але інші датчики зони стабільні',
        'examples': ['CO2 датчик дрейфує на 50ppm/добу без людей у приміщенні']
    },
    'bit_flip': {
        'signature': 'поодинокі аномальні значення, потім повернення до норми',
        'detection': 'spike duration = 1 reading, isolation forest score',
        'examples': ['температура 127°C (0x7F) на 1 секунду']
    },
    'connectivity_issue': {
        'signature': 'пропуски в даних, регулярні або випадкові',
        'detection': 'gap analysis в timestamp послідовності',
        'examples': ['пакети втрачаються кожні N хвилин = CRON-джоб конфлікт']
    },
    'power_degradation': {
        'signature': 'наростаючі пропуски + збільшення часу відповіді',
        'detection': 'temporal pattern of gaps + RSSI зниження',
        'examples': ['батарейний датчик втрачає пакети при заряді < 20%']
    }
}

Як детектувати stuck-value та noise-floor?

import numpy as np
import pandas as pd

def detect_stuck_sensor(readings: pd.Series,
                         window: int = 20,
                         variance_threshold: float = 1e-6) -> dict:
    """
    Датчик завис: стандартне відхилення за останні N значень близьке до 0.
    Враховуємо допустимий шум (quantization noise): для 12-bit ADC ≈ 0.01% діапазону.
    """
    if len(readings) < window:
        return {'status': 'insufficient_data'}

    recent = readings.tail(window)
    variance = recent.var()
    unique_values = recent.nunique()

    stuck_by_variance = variance < variance_threshold
    stuck_by_unique = unique_values == 1

    # М'який критерій: < 3 унікальних значень за 20 вимірювань (квантування)
    low_variation = unique_values <= 2 and window >= 20

    return {
        'stuck_detected': stuck_by_variance or stuck_by_unique,
        'low_variation_warning': low_variation,
        'variance': float(variance),
        'unique_values_in_window': int(unique_values),
        'action': 'sensor_inspection' if stuck_by_variance else None
    }

def detect_noise_floor_anomaly(readings: pd.Series,
                                expected_noise_std: float) -> dict:
    """
    Занадто тихий датчик: шум нижче фізичного мінімуму = застиглий або згладжений.
    Занадто шумний: std різко зросла = деградація датчика або завади.
    """
    recent_std = readings.tail(60).std()
    noise_ratio = recent_std / (expected_noise_std + 1e-9)

    if noise_ratio < 0.1:
        return {'anomaly': 'too_quiet', 'noise_ratio': noise_ratio,
                'action': 'check_if_sensor_stuck_or_filtered'}
    elif noise_ratio > 10:
        return {'anomaly': 'too_noisy', 'noise_ratio': noise_ratio,
                'action': 'check_grounding_and_power_supply'}

    return {'anomaly': None, 'noise_ratio': round(noise_ratio, 2)}

Аналіз пропусків у даних: як відрізнити випадкові збої від закономірності?

Класифікація патернів відсутності даних:

from scipy.stats import chi2_contingency

def analyze_data_gaps(timestamps: pd.DatetimeIndex,
                       expected_interval_seconds: int = 60) -> dict:
    """
    Пропуски можуть бути:
    - Випадкові: проблеми радіоканалу
    - Регулярні: конкретний час = ОС оновлюється, перегрів опівдні
    - Наростаючі: батарея сідає
    """
    actual_intervals = timestamps.to_series().diff().dt.total_seconds().dropna()

    # Пропуски = інтервал > 1.5 × expected
    gaps = actual_intervals[actual_intervals > expected_interval_seconds * 1.5]
    gap_ratio = len(gaps) / len(actual_intervals)

    # Тест на регулярність пропусків (по годинах доби)
    gap_timestamps = timestamps[actual_intervals[actual_intervals > expected_interval_seconds * 1.5].index]
    hours_of_gaps = gap_timestamps.hour

    # Chi-square: чи рівномірні пропуски по годинах?
    hour_counts = pd.Series(hours_of_gaps).value_counts().reindex(range(24), fill_value=0)
    _, p_value = chi2_contingency([hour_counts.values, np.full(24, len(gap_timestamps)/24)])[:2]

    periodic_gaps = p_value < 0.05  # пропуски сконцентровані в певний час

    # Тренд: чи наростають пропуски з часом?
    if len(gaps) > 5:
        x = np.arange(len(gaps))
        trend_slope = np.polyfit(x, gaps.values, 1)[0]
    else:
        trend_slope = 0.0

    return {
        'gap_ratio': round(gap_ratio, 3),
        'total_gaps': len(gaps),
        'periodic_gaps': periodic_gaps,
        'peak_gap_hours': hours_of_gaps.value_counts().head(3).index.tolist() if len(hours_of_gaps) > 0 else [],
        'increasing_trend': trend_slope > 5,  # пропуски наростають
        'fault_type': (
            'battery_degradation' if trend_slope > 10 else
            'periodic_interference' if periodic_gaps else
            'random_connectivity' if gap_ratio > 0.05 else
            'normal'
        )
    }

Багатопристрійна діагностика: як знайти несправний пристрій серед сотень?

Кластерний аналіз поведінки пристроїв за ISO 13374-1:2003:

from sklearn.ensemble import IsolationForest

def fleet_device_health_check(device_metrics: pd.DataFrame) -> pd.DataFrame:
    """
    Перевіряємо всі пристрої в групі — знаходимо аутсайдерів.
    Ознаки: gap_ratio, stuck_events_count, snr_avg, battery_level_trend.
    Пристрої з аномальною поведінкою відносно групи = кандидати на заміну.
    """
    feature_cols = [
        'gap_ratio_7d',
        'stuck_events_7d',
        'rssi_avg',
        'battery_decline_rate',   # % в день
        'error_frame_rate',
        'reading_frequency_deviation'  # відхилення частоти від expected
    ]

    X = device_metrics[feature_cols].fillna(0)
    model = IsolationForest(contamination=0.1, random_state=42)
    device_metrics['anomaly_score'] = -model.fit_predict(X)
    device_metrics['health_label'] = np.where(
        device_metrics['anomaly_score'] == -1, 'faulty_candidate', 'healthy'
    )

    return device_metrics.sort_values('anomaly_score', ascending=False)

Кейс із практики: для розподіленої мережі датчиків температури в центрі обробки даних модель на базі Isolation Forest виділила три пристрої з аномальним дрейфом — виявилося, що на них потрапив пил, погіршивши тепловідведення. Порогові методи пропустили б цю деградацію ще тиждень, а AI помітив тренд за першу добу.

Що робити при виявленні аномалії?

При діагностиці software fault ми автоматично ініціюємо OTA reboot або firmware update через AWS IoT Jobs або Azure Device Twins. Для hardware-проблем формуємо заявку в field service management (інтеграція з ServiceNow, Salesforce). Це знижує time-to-repair в середньому на 40%, а операційні витрати на обслуговування — на 30%.

Як ми це робимо: процес роботи

Повний цикл займає від 2 до 8 тижнів — все робимо під ключ. Замовте пілотний проект на одному флоті пристроїв і оцініть результат.

Порівняння підходів: AI vs правила

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

• Розроблені та навчені моделі (stuck, drift, gap, fleet)
• Дашборд здоров'я пристроїв з історією аномалій
• Інтеграція з вашим IoT-брокером (AWS IoT, Azure IoT Hub, власний MQTT)
• Механізм OTA-оновлень та алертів
• Документація та навчання команди
• Пост-релізна підтримка на місяць

Наш досвід та гарантії

У нас 7+ років досвіду в побудові AI/ML-систем для промислового IoT. Реалізували 45+ проектів для клієнтів з енергетики, логістики та розумних будівель. Гарантуємо точність детекції не менше 95% на ваших даних — результат підтверджуємо A/B-тестуванням. Працюємо з сертифікованим стеком (PyTorch, Hugging Face, Kubernetes) та ліцензійним ПЗ. Економія на ремонті та експлуатації досягає 40% за рахунок раннього виявлення несправностей.

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

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