Как мы научили ML предсказывать смерть насоса за 60 дней и выяснили, что все время чинили не то (часть 1)

История о том, как мы боролись с «цифровой слепотой», разрозненными данными и недоверием к ML, чтобы построить систему предиктивной аналитики для реального нефтеперерабатывающего завода. Часть 1 из 2.

Привет, Хабр! Меня зовут Сергей Михайлов, я эксперт по промышленности в команде вендора Data Sapience. Моя работа состоит на стыке двух миров: я перевожу «хотелки» промышленности на язык Data Science и обратно, а потому вижу, как рождаются и развиваются проекты по предиктивной аналитике.
Это первая из двух статей о том, как мы строили систему предиктивной аналитики для реального НПЗ. Оговорюсь сразу: сам кейс мы собирали во многом «руками» и на кастомных коннекторах, а в ходе работы стало понятно, какой инструмент здесь действительно нужен. Весь описанный функционал сегодня закрывает наша платформа Industrial Ocean, и по ходу текста я буду показывать, где именно она снимает ту или иную боль. Поехали.

Вместо вступления: разговор в диспетчерской

— Насос снова встал. В третий раз за полгода.

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

— Мы тут подумали, — говорю я. — Дайте нам доступ к архивам тегов за последние два года. Мы попробуем найти закономерности.

В ответ лишь скептический взгляд. Такие обещания на заводе слышали уже не раз. Были (и есть) и системы вибромониторинга, и попытки внедрить «умное» обслуживание. Но все это сводилось к одному: датчик показывал, что вибрация выросла, но объяснить причину никто не мог. Технологи разводили руками, ремонтники меняли подшипники, и через три месяца все повторялось.

Но доступ к данным все равно не дали. Слишком сложно. Слишком много систем. Слишком много бюрократии.

Знакомая история? Добро пожаловать в мир, где промышленность пытается подружиться с Data Science.

Четыре всадника апокалипсиса в мире промышленного ML

Когда мы в Data Sapience начали погружаться в задачи предиктивной аналитики для нефтегазохимии, мы столкнулись с фундаментальными проблемами, которые повторялись от завода к заводу, от компании к компании.

Первый всадник – Мор (симптомы болезни расползаются по источникам)
Данные с датчиков АСУ ТП живут в одном мире (OPC-серверы, SCADA), оперативные задачи MES — в другом, а экономические показатели из ERP — в третьем. Нет единой картины. Технолог не может увидеть, как качество сырья влияет на вибрацию насоса через три часа работы. Механик не понимает, что изменение давления в одном контуре сигнализирует о проблемах в соседнем. Каждый смотрит на свой фрагмент пазла.

На одном из объектов мы насчитали 149 тегов, относящихся к одному компрессору. Но они были разбросаны по разным системам. Одна часть находится в PI System, другая — в SCADA, третья — в Excel-таблицах у технологов. Некоторые теги имели странные наименования, которые понимал только один ушедший в прошлом году инженер. А часть тегов вообще не собиралась: их просто не вывели в единую систему.

Второй всадник – Война (с авариями) Производственная культура часто строится на принципе «тушения пожаров». Поломка случилась — сразу вызвали ремонтников. Выпустили некондицию — разбираемся постфактум. Простой установки может обходиться в сотни тысяч рублей в час. Но вместо предотвращения инцидентов лишь хроническое устранение последствий. Проблема здесь не в нежелании предотвращать аварии, а в отсутствии инструментов, которые заранее покажут: «Слушай, через 60 дней у тебя упадет насос. Причина вот в этих уплотнениях. Займись сейчас, и все будет хорошо».

Третий всадник – Голод (данные под замком, а добудешь — сырые) Дата-сайентисты приходят на завод и говорят: «Дайте нам данные, и мы предскажем все». Начинается бюрократический ад. Доступ к тегам – через пять согласований. Протоколы OPC UA/HDA «открытые», но спецификации не выгрузить. А когда доступ все-таки получаешь, выясняется, что данные сырые, несвязанные, с пропусками и шумами.

Четвертый всадник – Смерть (ручная настройка убивает масштаб)
Большинство систем цифровой диагностики построены по принципу «ручной настройки под каждую единицу оборудования». Пользователь или внедренец должен подобрать настройки алгоритма для каждого насоса, компрессора или турбины индивидуально. Это линейно масштабируемая работа, а значит,  дорого на масштабе. На крупном заводе с сотнями единиц оборудования такой подход становится экономически нецелесообразным. Кроме того, типовые решения ограничены в обработке и хранении данных. Они не предоставляют пользователю-диагносту исчерпывающую информацию в момент принятия решения: нельзя сравнить текущий сигнал с историей, найти аналоги поведения оборудования, гибко провести визуальный анализ. А уверенность в корректности диагностики напрямую зависит от возможности такого сравнения.

Все описанное — это классический конфликт двух миров: Data Science и промышленности. Именно из таких проектов и выросло понимание, каким должен быть инструмент: способным работать в реальных, «грязных» условиях промышленности и масштабироваться без экспоненциального роста затрат. Этот функционал мы и собрали в платформе Industrial Ocean — дальше буду отмечать, где она закрывает конкретные проблемы кейса.

Кейс: центробежный насос, который ломался каждые три месяца

Наш первый серьезный проект, где случился открывающий диалог, стартовал на одном из нефтеперерабатывающих заводов. Каждый простой насоса составлял минимум 12 часов. Каждый час простоя приводил к миллионным потерям.

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

Результат: 60 дней упреждения, но инсайт был не в этом

Модель начала выдавать аномалии за 60 дней до того, как производственный персонал заметил проблему и остановил насос.

Но главный инсайт был не в том, что модель предсказала время. Она показала, какие параметры внесли наибольший вклад в отклонение. Анализ вклада признаков указал на четыре ключевых параметра:

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

Этот инсайт стал переломным. Впервые у заказчика появилось не просто предсказание «когда», а аргументированная и подтвержденная гипотеза «почему».

Почему модель — это только 20% успеха

А теперь то, из-за чего технически исправные проекты все равно умирают. Проект по внедрению предиктивной аналитики включает не только разработку моделей. Это также затрагивает организационные изменения и вводит четкий процесс (регламент) работы с оповещениями. Можно построить идеальную модель, которая ловит аномалию за 60 дней, и все равно провалить проект, потому что модель — это только сигнал. Все решают вопросы: кто получает оповещение? как его анализировать? как закрывать? Люди должны знать, что делать с информацией от ML-моделей.

Мы выстроили трехуровневую систему реакции:

1. Уровень 1: операторы и механики установки. Получают оповещения, просматривают тренды и вклад датчиков, принимают первичное решение.

2. Уровень 2: инженеры-механики и технологи. Проводят углубленный анализ, подтверждают или опровергают аномалию.

3. Уровень 3: продвинутые пользователи. Переобучают модели, добавляют новые сценарии.

Процесс работы с оповещением выглядит так:

• Система отправляет оповещение (по электронной почте или через веб-интерфейс);

• Оператор открывает веб-интерфейс и просматривает тренды датчиков, анализирует вклад параметров в аномалию;

• Оператор должен закрыть оповещение с указанием причины.

Ключевой механизм — оповещение нельзя просто закрыть. От выбора оператора зависит поведение модели:

Эта система обратной связи позволяет моделям постоянно совершенствоваться. Каждое закрытое оповещение становится либо новым знанием для модели (если это была «новая норма»), либо новым паттерном отказа (если это был подтвержденный отказ).

Побочный эффект, который оказался главным

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

По сути, предиктивная аналитика стала не «системой мониторинга», а поводом для кросс-функционального разговора, которого раньше просто не было. И тут важна коммуникация на языке цеха: механики и технологи не data scientist'ы, им не нужно объяснять, что такое градиентный бустинг. Им нужно сказать: «Слушай, через 60 дней у тебя будет проблема вот здесь. Вот причина. Вот что сделать». Это работает, потому что дает время на взвешенное решение вместо аврала.

Организационно этот процесс можно полностью перенести в инструмент. Так, в Industrial Ocean система, а сейчас ИИ-ассистент (расскажем об этом во второй части) работает с оборудованием через единый интерфейс: поднимает данные за любой исторический период, сравнивает текущий сигнал с историей, создает правило контроля состояния и настраивает уведомление инженерных служб, чтобы у специалиста был полный набор данных для решения, например, об остановке на внеплановый ремонт.

Сухой остаток

●      Ремонт был проведен по факту обнаружения аномалии, а не по факту поломки;

●      Время на подготовку к ремонту сократилось на 70% (вместо срочной «пожарной» закупки — плановая поставка);

●      Простой технологической установки был исключен;

●      Затраты на обслуживание сократились на 15–20% на одном активе.

После демонстрации результатов пилота было принято решение о выводе под онлайн-мониторинг более 50 единиц оборудования. На один компрессор, например, развернули 8 моделей аномального состояния (маслосистема, система уплотнительного газа, мультипликатор, вибрация компрессора, вибрация электродвигателя, электродвигатель, состояние газа на всасе/нагнетании, подшипники), а также завершили интеграцию с EAM для автоматического создания заказ-нарядов.

Главное — изменилась производственная культура. Механики больше не гадают, что сломалось. Технологи видят точные рекомендации. Плановики получают точные сроки. А директор по производству знает, что его завод переходит от «тушения пожаров» к управляемому, предсказуемому процессу.

P.S. и что дальше

Это был взгляд «сверху»: бизнес, результат и люди. Во второй части ныряем под капот: 650 млн точек, выбор между GPN и SOM, обучение на «норме», а также самый недооцененный этап – добыча и очистка данных из PI System, на которую уходит до 80% времени.

А вы сталкивались с подобными вызовами? Если вы — инженер, технолог или Data Scientist, который пытался подружить ML с промышленностью, поделитесь в комментариях, с какими нестандартными проблемами сталкивались и как их решали.

Подписывайтесь на блог Data Sapience на Хабре, чтобы не пропустить продолжение, и наш Telegram-канал.