Предиктивное обслуживание на НПЗ: как 21 датчик предсказывает поломку за 60 дней

Кейс описан Сергеем Михайловым, экспертом по промышленности в команде вендора Data Sapience, в первой из двух частей материала на Хабре. Компания строила систему предиктивной аналитики для НПЗ, где центробежный насос выходил из строя каждые три месяца. Минимальный простой составлял 12 часов, и стандартный подход «сломалось, чиним» обходился дороже, чем плановое обслуживание всего цеха за год.

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

• Доступ к данным датчиков оборудования. На практике это архивы тегов из АСУ ТП (автоматизированная система управления технологическим процессом, по сути мозг завода, который собирает показания со всех датчиков). В описанном кейсе насос был окружён 21 датчиком. На одном компрессоре того же завода команда насчитала 149 тегов, разбросанных по разным системам.
• Инструмент для работы с данными. Команда Data Sapience собирала кейс вручную и на кастомных коннекторах. Позже функционал упаковали в платформу Industrial Ocean. Для учебного старта подойдёт Python с библиотеками pandas, scikit-learn или любая ML-платформа (машинное обучение, machine learning, то есть алгоритмы, которые сами находят закономерности в данных).
• Доступ к историческим архивам. Команда запросила архивы тегов минимум за два года, чтобы модель увидела повторяющиеся паттерны отказов.
• Время. Основная часть работы, это не обучение модели, а сбор, очистка и связывание данных из разных источников. По описанию кейса, именно этот этап занимает большую часть проекта.

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

1. Получите доступ к архивам тегов оборудования. Это первый и самый сложный шаг. В кейсе Data Sapience доступ к данным не дали сразу: «слишком сложно, слишком много систем, слишком много бюрократии». Данные с датчиков АСУ ТП хранятся на OPC-серверах и в SCADA (системах диспетчерского управления), оперативные задачи живут в MES, экономика в ERP. Готовьтесь к пяти и более согласованиям.

2. Соберите данные в единое хранилище. Проблема, которую Михайлов называет «цифровой слепотой»: теги разбросаны по PI System, SCADA и Excel-таблицам у технологов. Часть тегов имеет названия, понятные только одному инженеру, который уже уволился. Часть вообще не выведена в единую систему. Задача этого шага: собрать все теги, относящиеся к единице оборудования, в одном месте.

3. Очистите данные от пропусков и шума. Промышленные данные, как правило, сырые. Пропуски, выбросы, дублирующиеся записи. Без очистки любая модель машинного обучения будет выдавать галлюцинации (когда алгоритм уверенно показывает закономерность, которой не существует).

4. Найдите косвенные связи между датчиками. Ключевая идея предиктивного обслуживания из этого кейса: не просто мониторить вибрацию (датчик и так покажет, что она выросла), а искать скрытые закономерности во ВСЕХ датчиках, косвенно связанных с работой оборудования. Технолог не видит, как качество сырья влияет на вибрацию насоса через три часа работы. Механик не понимает, что изменение давления в одном контуре сигнализирует о проблемах в соседнем. ML-модель способна увидеть эти связи.

5. Обучите модель на исторических данных. Используйте архив за два года, включая периоды, когда оборудование работало нормально, и периоды перед отказами. Цель: научить модель отличать «здоровое» поведение от предвестников поломки.

6. Настройте предупреждения с горизонтом прогноза. В идеале система должна говорить: «через 60 дней у тебя упадёт насос, причина в этих уплотнениях, займись сейчас». Именно такой горизонт, 60 дней до отказа, описан как целевой в кейсе Data Sapience.

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

Автору на Дзене. Предиктивное обслуживание, это тема, которая отлично ложится в формат кейсов и практических разборов. Напишите, как ML применяется в вашей отрасли: аудитория ценит истории «было сломано, починили данными», а не абстрактные рассуждения про будущее ИИ.

Маркетологу. Если ваш продукт связан с промышленностью, IoT или аналитикой, кейсы предиктивного обслуживания дают понятный ROI (возврат инвестиций): часы простоя переводятся в рубли. Это аргумент, который закрывает возражения.

Предпринимателю в РФ. Кейс Data Sapience ценен тем, что описан для российского НПЗ, с российской бюрократией и реальными системами АСУ ТП. Платформа Industrial Ocean, о которой пишет автор, доступна в России. Из альтернатив: «Цифра» (Zyfra) предлагает аналогичные решения для промышленности. Начните с пилота на одной единице оборудования с наибольшим числом отказов.

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