Соавторы Анураг Бхатия, Саурабх

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

Разнообразие наборов данных

В этом разделе мы разбили наборы данных по типу анализа возможных сущностей.

Анализ датчика. При анализе поведения датчика необходимо учитывать следующие факторы:

Общее количество датчиков

Импликация:

  • Можем ли мы построить модели для конкретных датчиков?

Сопоставление датчиков с определенными местами (например, проблемами/группами)

Подразумеваемое:

  • Если количество датчиков слишком велико, подумайте о том, чтобы сосредоточиться на групповом моделировании.
  • Если количество групп также велико, подумайте о групповом смещении (т. е. отдайте приоритет тем группам, которые более подвержены сбоям).

Являются ли датчики цифровыми или аналоговыми по своей природе?

Подразумеваемое:

  • Переходы и задержка важны для цифровых датчиков, тогда как анализ тенденций и временных рядов может быть более актуальным для аналоговых датчиков.
  • Для цифровых датчиков каждый переход от 0 к 1 и наоборот может использоваться для выделения признаков.

Какие датчики в каждом месте должны быть синхронизированы друг с другом?

Импликация:

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

Продолжают ли датчики излучать и отправлять данные, даже когда машина не работает (например, ночью, когда фабрика закрыта)?

Подразумеваемое:

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

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

Какова долгосрочная тенденция простоев (т. е. простоев)? Растет ли количество простоев вверх/вниз или постоянно остается в определенном диапазоне? Это слишком изменчиво?

Есть ли сезонность в данных (например, ежемесячно, ежеквартально и т. д.)?

Пример сезонности: снимок

Импликация:

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

Можем ли мы установить, с чего начиналось каждое время простоя? Можно ли было это предотвратить? Или это было связано с внешними факторами, не зависящими от нас (например, с погодой)?

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

Распространены ли простои повсюду? Или они сконцентрированы в каких-то «карманах» (т. е. группах), которые кажутся более уязвимыми, чем другие (например, более частые простои)?

Машинный пример часов, потерянных в ремонте:

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

Какова степень перерыва в работе для различных типов простоев (например, работа на машине возобновляется через ‹ 10 минут для некоторых проблем, а ремонт занимает > 3 часа в случае другого набора проблем)?

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

Моментальный снимок графика распределения времени простоя (ось x) (т. е. различные времена безотказной работы, потерянные из-за сбоев)

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

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

Частота отправляемых сообщений (например, обычное количество сообщений, отправляемых каждый час, пока машина работает)

Частота отправленных телеметрических сообщений:

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

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

Какова природа данных телеметрии?

Вывод: можно ли использовать НЛП или показатели сходства текста для анализа текста в данных телеметрии?

Какие модели мы можем построить

Статистическая модель (процентиль)

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

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

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

Модель классификации (XGBoost)

Следуя документации от XGBoost, это оптимизированная распределенная библиотека повышения градиента, разработанная, чтобы быть высокоэффективной, гибкой и переносимой. Он реализует алгоритмы машинного обучения в рамках фреймворка Gradient Boosting. XGBoost обеспечивает параллельное повышение дерева (также известное как GBDT, GBM), которое быстро и точно решает многие проблемы науки о данных. Один и тот же код работает в основных распределенных средах (например, Hadoop, SGE, MPI) и может решать проблемы, число которых превышает миллиарды примеров.

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

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

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

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

Модель обнаружения аномалий (FB Prophet)

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

В случае тематических исследований профилактического обслуживания модель может быть построена на двух функциях для каждого датчика: одна — это отметка даты и времени [дс], а другая — выходные данные датчика по агрегированным переходам. Мы подгоняем модель, создавая экземпляр нового объекта. Любые настройки процедуры прогнозирования передаются в конструктор как таковые (например, daily_seasonality=True, weekly_seasonality=True, yearly_seasonality=True). Затем вы вызываете его метод и передаете исторический фрейм данных. Примерка должна занять 1–5 минут.

Модель обнаружения аномалий (автоэнкодер)

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

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

Сводка

Таким образом, большинство наборов данных состоит из переходов датчика (например, включение/выключение или телеметрия датчика и журнал обслуживания), и наиболее успешный способ решения для оповещения основан на обнаружении аномалий.

Что осталось?

Последний раздел будет полезен для завершения создания возможностей профилактического обслуживания.

[Часть 3] Как ИИ меняет прогнозное обслуживание на основе Интернета вещей: вывод, оценка и оптимизация