Предиктивная аналитика на НПЗ: 80% усилий уходит не на модель, а на борьбу с данными

Сергей Михайлов, эксперт по промышленности в команде вендора Data Sapience, опубликовал на Хабре вторую часть разбора проекта предиктивной аналитики для насосного оборудования. Первая часть описывала бизнес-результат: предсказание отказа и обнаружение ошибок в ремонтной стратегии. Вторая целиком посвящена технической кухне: как собирали данные, почему стандартные интерфейсы не справились и какие алгоритмы машинного обучения работают, когда задокументированных поломок всего три.

Ниже я собрал пошаговый маршрут по материалам Михайлова. Он полезен любому, кто пытается запустить предиктивную аналитику на промышленном объекте в России или СНГ и хочет заранее знать, где будет больно.

Что понадобится?

• Доступ к промышленному архиву данных: PI System (OSIsoft) или аналогичная историческая база. На российских заводах это самый распространённый источник
• Знание промышленных протоколов: OPC DA/UA (стандарты обмена данными между оборудованием и IT-системами, что-то вроде общего языка для датчиков и серверов)
• Язык программирования и ML-фреймворк: в кейсе использовали PI SDK (набор инструментов для прямой работы с архивом PI System) вместо стандартного JDBC-интерфейса (универсальный, но медленный способ подключения к базам данных)
• Экспертиза технолога или главного механика: без человека, который знает, что означает тег T54001, маппинг датчиков не построить
• Время: минимум две недели только на маппинг тегов, несколько месяцев на весь цикл от сбора данных до работающей модели

Пошаговая инструкция

1. Постройте интеграционный слой для сбора данных. Стандартный JDBC-интерфейс PI System слишком медленный для выгрузки исторических данных за год и более. В описанном кейсе пришлось использовать нативный PI SDK и написать шлюз, который выкачивал данные пачками и агрегировал по минутам. Без этого 50 миллионов агрегированных записей просто не удалось бы обработать.

2. Создайте маппинг тегов оборудования. Названия датчиков на российских НПЗ выглядят как T54001, PS4004, D_F11022. Часть расшифровок существует только в голове конкретного инженера, который мог уже уволиться. Маппинг (буквально «переводчик» с языка технологов на язык машинного обучения) в кейсе занял около двух недель совместной работы с главным механиком и технологом установки. Без него модель не поймёт, какой физический параметр стоит за каждым тегом.

3. Проведите автоматическую валидацию данных ДО моделирования. Проверяйте три типа дефектов:

4. Пропуски: дыры в рядах данных, когда датчик не передавал значения
5. Плоские сигналы (flat-line): датчик «залип» на одном значении и фактически мёртв
6. Выбросы и шум: некорректные значения, которые исказят обучение

В кейсе заявленный архив за два года после валидации сжался до одного года пригодных данных. Без этого шага модель обучилась бы на мусоре.

1. Выберите подход к детекции аномалий. При трёх задокументированных поломках классическое обучение с учителем (supervised learning, когда модели показывают примеры «нормы» и «поломки») не работает: слишком мало примеров отказов. Остаётся детекция аномалий без учителя (unsupervised), когда модель учится на данных нормальной работы и ловит отклонения. Два кандидата из кейса:
2. GPN (Gaussian Probability Network): вычисляет расстояние между текущим состоянием и «нормой», учитывая корреляции между датчиками. Требует минимум 12 месяцев данных нормальной работы. Именно GPN зафиксировал аномалию за 60 дней до поломки

3. SOM (Self-Organizing Map, самоорганизующаяся карта): проще в настройке, хорошо работает, когда оборудование переключается между несколькими режимами, но менее чувствителен к скрытым многомерным аномалиям

4. Разделите аномалии на активные и неактивные. Активные ведут к отказу и требуют действий. Неактивные возникают при штатных пусках, остановках и смене режима. Если не провести это разделение, модель будет паниковать при каждом плановом пуске оборудования.

5. Учтите многорежимность оборудования. Если насос работает на разных составах сырья, одна «усреднённая» модель нормы начинает принимать штатный режим за аномалию. GPN в кейсе утонул в ложных тревогах именно по этой причине. Решение: строить отдельные модели нормы для каждого операционного режима или использовать SOM, который лучше справляется с несколькими состояниями.

Что делать с этим прямо сейчас?

Инженерам и технологам на производстве. Начните с аудита своих данных, а не с выбора алгоритма. Проверьте, сколько из заявленного архива реально пригодно. Зафиксируйте маппинг тегов, пока носители знаний ещё доступны.

Руководителям и предпринимателям в промышленности. Предиктивная аналитика не начинается с покупки платформы. Она начинается с интеграционного слоя и валидации. Закладывайте 80% бюджета времени на данные, 20% на модели.

Авторам и копирайтерам, пишущим про промышленный ML. Этот кейс показывает, о чём на самом деле стоит писать: не про точность алгоритма, а про PI SDK вместо JDBC, про двухнедельный маппинг с главным механиком, про 650 миллионов точек, сжавшихся до одного года пригодных данных. Живые детали цепляют сильнее, чем абстрактные обещания «Industry 4.0».

Главный вывод из этого кейса прост и неудобен: если на вашем заводе нет зафиксированного маппинга тегов и не проведена валидация архива, никакой алгоритм не поможет. Начните с данных, модель подождёт.