Часть 2 из 2. В первой части серии мы предсказали отказ насоса за 60 дней и выяснили, что годами чинили не то. Увидели, что материал встретил вашу живую реакцию, поэтому возвращаемся по горячим следам со второй частью. В этом материале, как и обещали, погружаемся в технику. Расскажем, что было под капотом, как решалась судьба насоса и с какими сложностями мы столкнулись.

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

Эта статья для тех, кто сам пытался подружить ML с промышленностью: здесь и выбор алгоритмов, и feature engineering, и data engineering. И для тех, кто любит, когда технический текст перестает быть томным (привет всадникам апокалипсиса промышленного ML из первой части).

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

Блок 1. Data engineering: 80% работы, о которой не любят говорить

Работа с данными, а вернее их подготовкой, составляет до 80% от общего объема трудозатрат. Интеграция с промышленными системами (OPC, PI System, исторические БД) является одним из самых сложных этапов. На написание собственных коннекторов, агрегацию данных, создание маппингов уходит больше времени, чем на обучение моделей.

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

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

Тогда нам пришлось решать это самостоятельно. Сейчас ничего изобретать не нужно: этот функционал закрывает платформа Industrial Ocean – сбор данных по промышленным протоколам, включая OPC DA/UA, поддержка граничных узлов и надежная передача в технологический архив идут из коробки.

Та, что дает жребий (и выпал он на ушедшего инженера)
Названия были человеко-нечитаемыми: T54001, PS4004, D_F11022. К сожалению, часть смыслов жила только в голове инженера, ушедшего в прошлом году. Пришлось создавать маппинг, т.е. буквально «переводчик» с языка технологов на язык машинного обучения. Это заняло около двух недель плотной работы с главным механиком и технологом установки.

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

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

●      пропуски – дыры в рядах данных;

●      плоские сигналы (flat-line) – залипший на одном значении датчик;

●      выбросы и шум – некорректные значения.

Именно валидация определила, что реальный тренировочный период – последний год, а не заявленные «два года архива». Пропустив этот шаг, мы бы обучили модель на мусоре.

Однако и в моделировании нас ждали свои подводные камни.

Блок 2. Модели: как детектировать аномалии, когда поломок почти нет

Теперь пару слов про сам ML. У нас было 21 измерение с частотой 1 раз в секунду – за год примерно 650 миллионов точек. Далеко не все полезны: много шума, пропусков, выбросов. И два убийцы классического подхода:

●      Мы не знали, какие параметры действительно важны. Технологи говорили: «Давление, температура, вибрация». Но какие именно комбинации? Какие лаги между изменением одного параметра и реакцией другого?

●      В истории завода было всего три задокументированных случая поломки насоса. Трех точек для обучения модели, как правило, очень мало. Классический supervised learning здесь отпадал, оставалась детекция аномалий без учителя.

Сначала типология аномалий. Мы разделили их на два типа: активные – те, которые приводят к отказу и требуют мер; и неактивные – переходные процессы, остановки/пуски, краткосрочные выбросы, которые информативны, но не опасны. Различать их критично: иначе модель паникует на каждом штатном пуске.

Два кандидата: GPN и SOM

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

GPN (Gaussian Probability Network) вычисляет расстояние Махаланобиса между точкой и центром распределения «нормального» состояния. Он учитывает корреляции между датчиками и позволяет обнаруживать многомерные аномалии, которые не видны на отдельных трендах. Требует минимум 12 месяцев данных «нормы», но улавливает тонкие изменения в поведении оборудования. Именно он зафиксировал первые признаки аномалии за 60 дней до поломки.

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

Подводные камни на нашем пути

Камень №1: GPN утонул в ложных тревогах
Для насоса мы выбрали GPN как более чувствительный и способный улавливать скрытые корреляции. Но в процессе поняли важное правило: если оборудование работает в нескольких режимах (например, разные составы сырья), одна «усредненная» модель нормы начинает принимать штатный переход в другой режим за аномалию. Для многорежимного оборудования лучше использовать SOM либо разделять данные на логические периоды. Мы переписали пайплайн под разделение режимов.

Камень №2: одна большая группа датчиков = бесполезный сигнал
Мы создали небольшие группы датчиков по логическим подсистемам (маслосистема, вибрация, электродвигатель и т.д.), а не одну большую группу. Это упростило анализ: если срабатывал агент по маслосистеме, значит, проблема в масле, а не в вибрации.

Как мы обучали модель на «норме»

Вместо обучения на поломках мы научили модель понимать, что такое нормальная работа. На основе данных за первый год (когда поломок не было) мы построили модель «здорового поведения» насоса.

Процесс выглядел так:

1. Выбор тренировочного периода. Взяли 12 месяцев, исключив известные отказы, незапланированные остановки и периоды с плохими данными. Все остальное, включая переходные процессы и информативные аномалии, считалось «нормой»;

2. Feature Engineering. Создали производные признаки: скользящие средние значения датчиков за определенное время, разности между соседними точками, накопленные суммы отклонений, временные лаги (от 15 минут до 12 часов). Без учета корреляций с задержкой в 15 минут, час или 12 часов модель не видит причинно-следственных связей;

3. Обучение ансамбля моделей. Внедрили несколько моделей, каждая на своих группах датчиков и своих алгоритмах;

4. Агрегация. Каждый алгоритм давал свой «сигнал тревоги» в виде вероятности аномалии (от 0 до 1). Мы объединили их в единый индекс здоровья оборудования.

Интерпретируемость как условие внедрения. Модель дала не только «60 дней», но и вклад признаков (PS4004, PS4003 – давление затворной жидкости), которые и вывели нас на уплотнения вместо подшипников. Аналитика показала, на какие датчики смотреть, и без этого технолог не понял бы, почему ей доверять.

Что мы собрали по итогам таких проектов

Сам кейс с насосом, как и говорил вначале, мы во многом реализовали кастомно. Но именно из подобных проектов выросла платформа Industrial Ocean – единая среда для применения ML в задачах оптимизации технологического режима и мониторинга оборудования, куда заложен весь описанный выше функционал.

Хотим немного подробнее рассказать про платформу и ее возможности (работу с данными, масштабирование, ИИ-ассистента поверх ядра на Golang и т.д.), но если вам это неинтересно, то смело перелистывайте к техническим урокам, которые вынесли из кейса с насосом!

Industrial Ocean закрывает полный цикл работы с промышленными данными: сбор по любым протоколам, унифицированное хранение временных рядов любой глубины, обработку в реальном времени, применение ML-моделей и формирование аналитических отчетов. Архитектура открытая, с API для интеграции с существующими системами заказчика и достройки собственных модулей. Разворачивается и на локальном сервере цеха, и как распределенная система с узлами на заводах и центральным хранилищем в ЦОД или облаке.

Поверх ядра платформы, написанного на Go (Golang), мы развиваем отдельный модуль – ИИ-ассистента. Он позволяет инженеру или технологу спросить про данные на естественном языке, без сложных запросов и погружения в тонкости ML. Ассистент использует RAG-подход: обращается к базе знаний предприятия (внутренней документации, технологическим регламентам и историческим данным) и формирует ответ на основе найденного контекста. При этом он параллельно читает временны́е ряды платформы и сопоставляет регламент с реальными показаниями процесса, так что ответ подтвержден данными, а не только текстом.

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

Технические уроки, которые мы вынесли из проекта

Подводя итог, хотим собрать в одном месте то, что поняли для себя, и будем рады обсудить это с вами.

• Data engineering – это самый недооцененный этап, занимающий до 80% трудозатрат. Но без него дальнейшая работа невозможна;

• Если работаете с большими объемами данных, выбирайте нативный SDK вместо JDBC;

• Валидацию качества нужно проводить до моделирования, иначе есть риск обучить модели на мусоре и сломать весь проект;

• Маппинг тегов не автоматизируется, нужно закладывать достаточно времени и подключать живых экспертов;

• Обучение на «норме» – это рабочий подход, так как годовой трек оказался важнее нескольких поломок;

• Feature Engineering с лагами решает больше, чем выбор алгоритма;

• Ансамбль моделей, каждая на своих группах датчиков и со своим алгоритмом, работает стабильнее, чем одна общая модель;

• SOM – оптимальный вариант для многорежимного оборудования. Либо можно использовать разделение на периоды;

• Группировка датчиков по логическим подсистемам сильно упрощает анализ;

• Если данные остаются для клиента непонятными, а проект больше похож на «черный ящик», никто не захочет внедрять систему. Интерпретируемость в этом смысле критична.

P.S.

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

Спасибо, что дочитали нашу серию! Будем рады обсудить проект и тезисы в комментариях. Подписывайтесь на блог Data Sapience на Хабре, Telegram-канал и дайджест, чтобы узнавать о наших новостях первыми!