Модуль p.5 · Урок 5
Урок 5: Предиктивное ТО горной техники — от вибродатчиков до SLR-обзоров
Содержание
- Чему вы научитесь
- На каком оборудовании PdM в ГМК имеет смысл первым номером
- Что говорит академический обзор 2025 года
- Типовая архитектура PdM для горной техники и фабрики
- Какие модели брать первыми
- Публичные кейсы: что брать, а что читать осторожно
- Какие данные нужны до первой модели
- Интеграция с российским контуром ТОиР
- Когда PdM не работает
- Как запускать PdM без самообмана
- Что делать дальше
Чему вы научитесь
- Понимать, где PdM в ГМК реально окупается, а где лучше не тратить время и бюджет
- Различать архитектуру для самосвалов, конвейеров, дробилок и фабричного оборудования
- Выбирать между supervised-подходом, one-class anomaly detection и простым rule-based baseline
- Связывать IIoT, time-series стек, модель и EAM/ТОиР-контур в один production-процесс
- Ловить ранние признаки того, что PdM-пилот идёт в PoC-ад и не даст эффекта
Predictive maintenance в горной и металлургической отрасли продают легче, чем внедряют. Причина простая: идея звучит идеально — поймаем отказ заранее и избежим простоя. Но это работает только там, где есть три вещи одновременно: дорогой простой, нормальные данные и реальный action path для службы ТОиР. Если хотя бы одного элемента нет, проект превращается в бесконечный поток тревог без управленческого эффекта.
На каком оборудовании PdM в ГМК имеет смысл первым номером
| Класс оборудования | Почему это хороший кандидат | Что обычно мониторят |
|---|---|---|
| Карьерные самосвалы и экскаваторы | Высокая цена простоя и дорогие узлы | Вибрация, температура, давление, циклы нагрузки, телеметрия двигателя |
| Конвейеры и ролики | Частые отказные сценарии и понятная кинематика | Температура подшипников, вибрация, ток, смещение ленты |
| Дробилки и мельницы | Критичный bottleneck на фабрике | Акустика, вибрация, ток, температура, грансостав на входе |
| Насосы, вентиляторы, гидросистемы | Хорошо описываются базовыми PdM-признаками | Вибрация, расход, давление, температура, энергопотребление |
| Малый парк вспомогательной техники | Обычно слабый кандидат | Слишком мало повторяющихся отказов и статистики |
Что говорит академический обзор 2025 года
Систематический обзор AI-Driven Predictive Maintenance in Mining собрал 166 исследований из Scopus и Web of Science и даёт хороший чек-лист зрелости: fault detection, digital twins, IoT-monitoring, explainability и real-time deployment. Обзор отдельно подчёркивает, что mining-среда тяжела для моделей из-за экстремальных условий, нехватки стандартизованных датасетов и проблем интероперабельности между сенсорами и системами (MDPI Applied Sciences, опубликовано 19.03.2025).
Для производства из этого следует не академический, а очень практический вывод: хорошая модель ещё не означает хорошую промышленную систему. PdM в ГМК всегда упирается в данные и интеграцию сильнее, чем в выбор алгоритма.
Типовая архитектура PdM для горной техники и фабрики
flowchart LR
A[Вибрация температура oil analysis акустика телеметрия] --> B[Edge collector / OPC UA / MQTT]
B --> C[Broker and streaming]
C --> D[TimescaleDB / data lake]
D --> E[Feature engineering]
E --> F[Baseline model / anomaly model / supervised model]
F --> G[Alert scoring and prioritization]
G --> H[EAM / 1С:ТОиР / Naumen / Service Desk]
H --> I[Факт отказа и обратная связь в модель]Если этот путь рвётся посередине — например, алерты приходят в Telegram и там умирают — у вас не PdM, а noisy analytics.
Какие модели брать первыми
| Ситуация | Что брать | Почему |
|---|---|---|
| Есть размеченная история отказов | Random Forest, XGBoost, LSTM/temporal models | Можно предсказывать конкретный тип отказа или remaining useful life |
| Размеченных отказов мало или почти нет | One-class anomaly detection, autoencoders, Isolation Forest | Реалистичный путь для новых площадок и редких аварий |
| Нужен быстрый baseline | Простые правила по температуре, трендам вибрации, отклонению от собственной нормы | Часто даёт первый эффект быстрее, чем сложная ML-модель |
| Нужно объяснение инженеру | Интерпретируемые модели и понятные правила | Иначе служба ремонта не будет доверять системе |
Это хорошо стыкуется с логикой p.2/07: сначала специализированная модель и базовая статистика, потом усложнение. LLM здесь не ядро, а максимум интерфейс для объяснения алерта и подготовки карточки работ.
Публичные кейсы: что брать, а что читать осторожно
| Кейс | Что заявлено | Как использовать |
|---|---|---|
| BHP | 5,5 млн $ экономии на одной шахте за счёт ML по обслуживанию самосвалов (BestPracticeAI) | Использовать как ориентир масштаба эффекта, но помнить, что это вторичный кейс — нужна проверка |
| ArcelorMittal Sentinel | 100% предсказанных отказов в пилотах Канады и Франции по вторичным описаниям (AIX Network) | Годится как ориентир зрелости in-house платформы, но цифру надо перепроверять по первичному материалу |
| MDPI SLR 2025 | 166 исследований, ключевые направления — conveyors, crushers, mills, digital twins, explainability (MDPI) | Это лучший источник, чтобы строить архитектуру и ожидания без маркетинга |
Какие данные нужны до первой модели
| Данные | Minimum viable уровень | Что обычно отсутствует |
|---|---|---|
| Телеметрия с датчиков | Стабильный поток без дыр и понятная частота съёма | История хранится фрагментами в разных системах |
| История ремонтов и отказов | Нужны даты, тип отказа, фактические действия, not only free text | Служба ремонта пишет комментарии в произвольной форме |
| Контекст эксплуатации | Нагрузка, смена, тип руды, температура среды, режим работы | Модель не знает, в каком контексте произошёл отказ |
| Маршрут до действия | Кто получает алерт и как он превращается в работу | Система шлёт тревоги, но никто не обязан на них реагировать |
По учебной отраслевой эвристике supervised-PdM обычно требует хотя бы 6–12 месяцев истории с отказами, а one-class подход — тысячи часов нормальной работы без отказов. Но это не норматив, а грубый ориентир, который нужно проверять по конкретному парку техники — нужна проверка.
Интеграция с российским контуром ТОиР
В реальном проекте модель должна разговаривать не только с data lake, но и с системой ремонта. На российском предприятии это часто означает интеграцию в 1С:ТОиР, Naumen Service Desk или другой EAM/ITSM-контур. Если такой интеграции нет, эффекта на простой не будет: вы просто добавите ещё один экран с тревогами.
С технической стороны open-source стек уже разобран в p.9/05: OPC UA, MQTT, Kafka, TimescaleDB, Grafana. Для большинства металлургических и горных PdM-проектов этого хватает для первой production-версии.
Когда PdM не работает
Это самая полезная часть урока.
- парк техники слишком мал, и статистики отказов просто нет;
- датчики живут хуже, чем оборудование, которое вы пытаетесь мониторить;
- служба ремонта не доверяет алертам и не меняет процесс;
- цена простоя низкая, а стоимость инфраструктуры и аналитики — высокая;
- нет права или возможности выполнить превентивное действие, даже если риск обнаружен.
Как запускать PdM без самообмана
Выберите один критичный узел. Не «весь парк», а конкретный тип оборудования с дорогим простоем и понятным failure mode.
Сначала соберите baseline-правила. Часто это даёт быстрый эффект и показывает, что датчики вообще живые.
Сведите ремонтную историю к нормальной таксономии. Без этого вы не сможете ни обучать supervised-модель, ни честно измерять эффект.
Подключите EAM до запуска модели. Alert без владельца не имеет смысла.
Фиксируйте эффект как avoided downtime. Иначе вы утонете в спорах о том, «помогла ли модель».
Что делать дальше
Если вам нужен open-source IIoT-стек под такой проект, идите в p.9/05. Если нужен закупочный фильтр по коммерческим PdM-платформам, смотрите p.10/04. Если задача упирается в экономику и окупаемость, возвращайтесь к p.4/02.