Разработка 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 мс.
Процесс работы
- Аналитика — выезд на объект, согласование схемы установки датчиков, сбор требований к частоте опроса и интеграции.
- Проектирование — выбор сенсоров, разработка схемы сбора данных (OPC-UA/Modbus), проектирование архитектуры обработки.
- Реализация — установка датчиков, разработка модулей анализа (спектральный, температурный, корреляция), настройка дашборда Grafana и алертинга.
- Тестирование — валидация на исторических данных (если есть), инжекция дефектов, проверка срабатывания.
- Деплой — запуск в промышленную эксплуатацию, передача документации, обучение персонала.
Что входит в работу
В результате вы получаете: отчёт по схеме установки датчиков, доступ к дашборду 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%. При дрейфе признаков окно автоматически сдвигается.
Процесс работы
-
Интервью с доменными экспертами — понимаем, что такое «нормальность» и какие инциденты уже были.
-
EDA и подготовка данных — очистка, создание признаков, временные окна.
-
Baseline (Isolation Forest) — быстрая валидация на известных инцидентах.
-
Выбор и кастомизация модели — Autoencoder / LSTM-AE / ансамбль.
-
Обучение, валидация с синтетическими аномалиями.
-
Развёртывание в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, мониторинг дрифта.
-
Post-deployment сопровождение — мониторинг метрик модели, обновление порогов.
Что входит в работу
- Аудит текущих данных и процессов
- Разработка и обучение моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
- Настройка адаптивных порогов и алертинга
- Панель мониторинга аномалий (Grafana / Streamlit)
- Документация model card и pipeline
- Обучение вашей команды (2–3 сессии)
- Гарантийная поддержка 3 месяца
Сроки: baseline-система с одним методом — 2–4 недели. Production-система с адаптивными порогами, алертингом и мониторингом — 2–5 месяцев. Стоимость рассчитывается индивидуально под ваш кейс.
Наша команда имеет 8+ лет опыта в промышленной аналитике и 15+ успешных проектов по детекции аномалий в телеметрии, финансах и IT-мониторинге. Получите консультацию — расскажем, как решить вашу задачу.