AI-система мониторинга оборудования по вибрации и температуре

Проектируем и внедряем системы искусственного интеллекта: от прототипа до production-ready решения. Наша команда объединяет экспертизу в машинном обучении, дата-инжиниринге и MLOps, чтобы AI работал не в лаборатории, а в реальном бизнесе.
Показано 1 из 1Все 1564 услуг
AI-система мониторинга оборудования по вибрации и температуре
Средний
~1-2 недели
Часто задаваемые вопросы

Направления AI-разработки

Этапы разработки AI-решения

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1348
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    949
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1183
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    921

Разработка 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 с) — для подшипников, термопары — для горячих точек, тепловизор — при периодических обходах.

Тип датчика Точность Применение Время реакции
PT100 / PT1000 ±0.1°C Подшипники, корпуса <2 с
Термопара (K-тип) ±1.5°C Высокотемпературные зоны <0.5 с
Инфракрасный пирометр ±1°C Периодический контроль Мгновенно
Тепловизор ±2°C Инспекция горячих пятен 1 с/изм.

Обработка вибрационного сигнала

Используем классификацию по стандарту 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+ объектах.

Параметр Пороговый контроль AI-диагностика
Точность обнаружения 60% 95%
Время упреждения 2 дня 2-4 недели
Ложные тревоги 30% 5%

Как мы строим модель машинного обучения?

Для 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 для первых гипотез
Autoencoder Изображения, временные ряды, логи Средняя Неструктурированные данные
LSTM-AE Многомерные временные ряды Низкая Промышленная телеметрия
PyOD (ансамбль) Табличные Высокая Быстрое сравнение 40+ методов

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 незапланированных остановки по $40k каждая. Экономия после внедрения — $120k за полгода (отчёт о пилоте на объекте клиента).

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

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

  • 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: снизилось ли количество пропущенных инцидентов / ложных тревог после внедрения
Техническая деталь: настройка адаптивного порога

Порог вычисляется как mean(errors) + k * std(errors) на скользящем окне 7 дней. Коэффициент k подбирается на validation set с синтетическими аномалиями для достижения FPR < 0.1%. При дрейфе признаков окно автоматически сдвигается.

Процесс работы

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