27.06.2022

Расширенная аналитика определения аномалий в индустриальном DWH

Максим Хлупнов, архитектор облачных решений Yandex Cloud

Использование моделей машинного обучения для предиктивного обслуживания промышленного оборудования является непростой задачей, существенным образом завязанной на внутренние детали реализации оборудования. Традиционно ее решение возлагалось на системы АСУТП и SCADA, как правило, иностранного производства. В новой реальности со стороны индустрии возник запрос на создание отечественных решений расширенной аналитики промышленной телеметрии, которые могли бы встроиться в контур сбора данных индустриальных хранилищ.

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

В статье демонстрируются варианты архитектуры решения задачи поиска аномалий в работе оборудования на основе анализа потоков его телеметрии несколькими способами: на основе статистического анализа и методами машинного обучения (далее ML).

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

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

Определение аномалий в работе оборудования

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

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

В условиях необходимости создать собственную систему индустриального DWH для проекта технической трансформации предприятия интеграция с такими модулями (если они еще существуют) бывает невозможна. Поэтому для реализации сценария выбирается традиционный IT-подход.

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

Мы наблюдаем тренд на создание проектов индустриальных хранилищ данных. В процессе их реализации будет решаться задача подключения к промышленному оборудованию, SCADA или промышленным шинам для сбора индустриальных данных и их передачи в индустриальные DWH для хранения и дальнейшей обработки.

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

Рисунок 1. Вариант реализации инфраструктуры индустриального DWH

Сложности при создании системы определения аномалий

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

  • Необходимость реализации конвейера потоковой обработки телеметрии
    Важной ценностью определения аномалий является максимально оперативная реакция. Ценность принятия операторских и управленческих решений существенно снижается с течением времени. Соответственно, система в контуре должна работать в режиме, максимально приближенном к режиму реального времени. А это влечет за собой реализацию потоковой обработки данных.
    Потоковая обработка данных традиционно считается более сложной по сравнению с привычной всем пакетной обработкой. Это связано с использованием специфических алгоритмов и технологий для обработки потоков.
  • Сложность получения значений физических величин
    Предполагается, что параметров технологического процесса очень много. Во многих холдингах SCADA системы передают в Historian десятки тысяч тегов. Значения, которые передаются в теге, часто не имеют понятной связи с физическим показателем.
    Так, например, выглядят настройки для преобразования значений из регистров ModBus в физические величины для электрического двигателя ABB ACS

Рисунок 2. Пересчет параметров регистров ModBus в физические величины

Чтобы знать, какие арифметические действия нужно выполнить для каждого регистра ModBus или тега SCADA, нужно изучить документацию к устройству и промежуточному стеку управления, знать номиналы установленных электродвигателей и т.д.
В реальности даже отделы, отвечающие за обслуживание систем АСУТП, не всегда владеют информацией о всех тегах, в алгоритмы внутри SCADA уже заложен расчет уставок, и проблема возникает только при попытках решить интеграционные задачи.

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

  • Необходимость реализации контура обратной связи

Если система определила проблему, но эта информация не была доведена до людей, которые принимают решения, — мы не выполнили свою основную задачу. В связи с этим возникает вопрос об интеграции с системой уведомления и диспетчеризации.

Выбор математического аппарата для оценки аномалий

Определение аномалии

Чаще всего аномалиями считаются следующие изменения в телеметрии:

  • Пики и провалы
  • Медленные восходящие или нисходящие тренды
  • Изменение тренда
  • Изменение уровня сигнала

Рисунок 3. Примеры аномалий. Слева: изменения уровня, выбросы и провалы. Справа: медленный восходящий тренд с изменениями

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

Достоинством данного метода является возможность использования алгоритмов, которые обучаются на данных, собранных в процессе нормальной работы оборудования. Фактически мы накапливаем достаточный объем статистики нормальной работы, а в дальнейшем применяем алгоритмы, которые ищут в структурах данных телеметрии отличия, т.е. аномалии. Метод основывается на предположении, что появление нетипичной телеметрии в работе установки свидетельствует о ее технической неисправности и требует от обслуживающего персонала внимания.

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

Это тем более актуально в связи с необходимостью обеспечить быструю оценку большего числа параметров. В условиях реального проекта у разработчиков системы расширенной аналитики может отсутствовать доступа к документации или экспертам прикладной области, которые могут определить алгоритмы преобразования параметров из значений системы АСУТП в физические величины, при этом результат необходимо продемонстрировать в сжатые сроки.

Параметрические методы определения аномалий

Существующий статистический аппарат может успешно справляться с большим числом практических задач. При этом он отличается высокой скоростью работы, гибкостью и отсутствием необходимости строить ML- модель. Правда, нам всё равно придется подготовить эталонную выборку. Параметрические методы названы так потому, что основываются на оценке параметров выборочного распределения и текущей телеметрии. Ниже мы будем использовать t-критерий Стюдента.

Реализацию подхода предлагается строить на периодической проверке гипотез о равенстве двух выборок телеметрии устройства или процесса — текущей и эталонной.  Для подготовки эталонной выборки нам необязательно иметь 100% значений телеметрии правильно работающего устройства или процесса за статистически значимый период (она может быть огромной). Обо всём наборе телеметрии мы будем судить по его части.

Если у устройства или процесса один режим работы – всё просто. Доказанный математический факт: если выборка взята случайным образом и в ней больше 30 элементов (значений телеметрии), то выборочные среднее и дисперсия близки к реальным среднему и дисперсии генеральной совокупности (всему набору значений телеметрии).

Если работа установки состоит из разных режимов, которые отражаются в различии телеметрии, — можно применить стратифицированные выборки. Чтобы отразить необходимые режимы работы в стратифицированной выборке, нужно взять пропорциональные случайные выборки из всех режимов работы, а потом соединить их между собой.

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

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

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

ML-методы определения аномалий

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

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

Классификации предполагают разделение выборки на обучающую, тестовую и проверочную с проведением разметки — бинарным признаком того, имеем ли мы нормальное значение телеметрии параметра или аномалию.

На графике это разделение можно визуализировать как кривую между нормальной телеметрией и аномальными выбросами (Рис. 4). Наиболее часто используют алгоритмы логистической регрессии, деревьев решений и другие методы классификаций.

Рисунок 4. Отделение аномальных значений от основной выборки на зависимости силы тока от скорости вращения электрического двигателя. Функция–разделитель для простоты представлена прямой линией

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

Обучение модели

Исходный код обучения моделей тривиален для специалистов Data Science, но приведем описание процесса для специалистов из других прикладных областей на примере оценки аномалий в работе электродвигателя с частотным преобразователем.

В процессе выполнения кода мы фактически прошли все стандартные циклы аналитической обработки:

  • Подготовку и очистку данных (как правило, данные поступают со значениями в строках, в то время как методы тренировки рассчитывают, что признаки будут находиться в столбцах);
  • Извлечение признаков, (в результате данные с целевым признаком ‘is_anomaly’ и признаки со значениями телеметрии оказались в разных массивах данных);
  • Формирование обучающей тестовой и вариационной выборки;
  • Обучение модели, оценка ее качества (точности, полноты, чувствительности).

Если модель нас устраивает, она может быть выгружена для дальнейшего применения, например, в виде pickle файла.

Это разовый процесс, после завершения обучения вычислительные мощности не требуются до следующей итерации, ставящей целью повысить качество. Результатом обучения является сохраненный файл модели (обычно файл Python pickle), содержащий исходный код программы на Python и состояние обученной модели.

Применение моделей (Inference)

Этот процесс выполняется постоянно для каждого сообщения с телеметрией установки на наличие аномалий. Он включает в себя загрузку в память pickle-файла модели и проверку телеметрии — выполнение классификации. Результатом является единственное значение — флаг Anomaly (true/false).

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

Выбор архитектуры решения определения аномалий

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

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

Причем сервисы могут выполняться как в публичном облаке, так и на ваших Edge-устройствах. При подобном подходе данные не покидают вашей внутренней компьютерной сети, что позволяет разгрузить внешние каналы и соответствовать требованиям безопасности, которые часто запрещают передавать промышленную телеметрию оборудования за пределы компании.

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

Заключение

Применение моделей поиска аномалий в работе оборудования и других методов машинного обучения является перспективным направлением, которое позволяет в режиме квазиреального времени получить информацию о сбоях в работе оборудования или появлении негативных трендов. Существует множество реализаций методов anomaly detection, существующих как в виде облачных сервисов, так и в виде библиотек для Python и других языков программирования. Применять облачные сервисы для анализа потоков телеметрии с промышленных устройств несложно, если воспользоваться решениями с открытым исходным кодом для создания шлюзов граничных вычислений и применять их как в облачной среде, так и on-prem, используя решения с открытым исходным кодом.

Подобные решения позволяют использовать свои собственные модели или загружать их из облака.

Демонстрационное решение

Описание работающего решения
https://github.com/MaxKhlupnov/SmartHive.AbbEdge
https://youtu.be/aWYEClNgQ8Q

 

Оставьте заявку и получите бюджет и план внедрения наших решений в ваш бизнес

    Заполняя форму, Вы соглашаетесь с правилами обработки персональных данных.

    Мы используем файлы cookies, чтобы получать статистику и делать наш сайт и другие сервисы удобными для вас. Продолжая дальнейшее использование сайта и/или его сервисов, вы соглашаетесь с этим. Более подробную информацию можно прочитать в «Политика обработки персональных данных» и в «Политика Cookies»