Начальные соображения

Несколько недель назад я опубликовал еще одну статью с почти таким же названием:



Машинное обучение - диагностика неисправностей в трекерах автопарка
Решение на основе данных для диагностики неисправностей в модулях слежения. todatascience.com



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

Введение

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

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

Неисправности - это недопустимое отклонение хотя бы одного свойства или определенного параметра системы [1]. Кроме того, есть три шага для диагностики неисправностей, а именно:

  1. Обнаружение неисправностей: это самая основная задача диагностики неисправностей, она используется для проверки неисправности или отказа в системе и определения момента возникновения неисправности;
  2. Изоляция отказов: изоляция служит для определения места отказа или неисправного компонента;
  3. Идентификация неисправности: идентификация используется для определения типа, формата и размера ошибки.

Обычно процесс идентификации неисправностей состоит только из обнаружения и устранения неисправностей (FDI). Это не отменяет полезности идентификации неисправностей. Однако этот процесс может быть несущественным, если не требуется никаких действий по реконфигурации [2].

Описание проблемы

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

Модули, установленные в автомобилях, отправляют данные в течение всего периода их работы. Компания предоставила 12586 реестров. Компания предоставила 12586 реестров. Реестр состоит из всех данных, передаваемых одним модулем за один день. В среднем каждый модуль отправляет 1116,67 балла в день. Каждая точка имеет восемь атрибутов:

  • Напряжение аккумулятора: плавающее значение напряжения аккумуляторной батареи автомобиля;
  • Долгота: плавающее значение долготы автомобиля;
  • Широта: плавающее значение широты автомобиля.
  • Зажигание: логическое значение, показывающее,
    включено ли зажигание;
  • Одометр: значение счетчика пробега транспортного средства;
  • Сигнал GPS: логическое значение, показывающее, действителен ли сигнал GPS
    ;
  • Скорость: плавающее значение скорости автомобиля.
  • Индекс памяти: целочисленное значение для позиции в памяти, в которой точка
    сохраняется в модуле.

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

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

  • Неисправность 1: установлен неправильный импульс;
  • Неисправность 2: одометр заблокирован;
  • Неисправность 3: GPS заблокирован;
  • Неисправность 4: отсоединен провод зажигания;
  • Неисправность 5: неисправен акселерометр;
  • Ошибка 6: неисправен буфер модуля;
  • Неисправность 7: GPS со скачками местоположения;

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

Разработка

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

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

Предварительная обработка данных

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

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

Учитывая, что реестры имеют переменную длину, было невозможно напрямую построить модели машинного обучения с этим набором данных. Таким образом, необходимо было установить размер по умолчанию для всех повторных попыток. Зная, что наибольшее количество точек, представленных в реестре, составляет 6410, среднее количество точек составляет 1116,67, а стандартное отклонение составляет 1155,75, реестры с меньшим объемом данных были заполнены «0» до тех пор, пока они не получат такой же объем данных, как и в самом большом реестре.

Могут быть применены различные подходы к установке размера реестра по умолчанию, такие как усечение объема данных из реестров выше среднего и заполнение «0» тех, которые ниже среднего, или усечение количества данных из всех реестров с помощью больше данных, чем реестр меньшего размера. Однако эти подходы были проверены и сочтены неосуществимыми из-за разногласий CNN.

Архитектура CNN

Сделал модель на базе ВГГ-16.

Используя 4 сверточных блока. Каждому нравится Конв. ›Сов.› Объединение. Затем два полностью связанных слоя.

Идея сверток состоит в том, чтобы заставить фильтры выбирать и изменять атрибуты. Для этого мы удалили каждый реестр с формой (8, 6410, 1). Таким образом, CNN угрожает данным как изображением. Чтобы более подробно изучить архитектуру, посетите мой GitHub (ссылка находится во введении и в заключении).

Используемый размер пакета был 1, скорость обучения 0,0001 и инициализатор he_uniform. Batch_size может быть больше. Однако из-за аппаратных ограничений для меня на три было больше.

Модельное обучение

Были обучены две модели: одна для обнаружения неисправностей, а другая - для обнаружения и изоляции неисправностей. Таким образом, были определены две структуры одного набора данных. Эти структуры описаны следующим образом:

  • Структура 1: использовалась в экспериментах для определения наличия неисправностей в системе. Он содержит 12586 записей, из которых 7480 ошибочные, а 5106 безупречные;
  • Структура 2: использовалась в экспериментах для обнаружения и локализации неисправностей. Он содержит 5106 безупречных записей, 2170 с ошибками 2, 1573 с ошибками 3, 1702 с ошибками 4 и 2035 с ошибками «Прочие», всего 12586 записей.

Все модели были написаны на Python 3.6 с Sk-learn 0.20.2 и работали в Ubuntu 18.04 с Intel i7–7700HQ, 16 Гб оперативной памяти, GTX 1050Ti.

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

Оценка модели

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

С 88,42 Precision и 87,96 Recall матрицу неточностей для обнаружения неисправностей можно увидеть ниже:

С 54.98 Precision и 52.57 Recall матрицу неточностей для обнаружения и изоляции неисправностей можно увидеть ниже:

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

Выводы

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

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

Как и в статье, кода не было, не стесняйтесь проверить его в моем репозитории GitHub.



lmeazzini / Tracker-fault-диагностика
Fault Diagnosis моделирует обнаружение и локализацию неисправностей в модулях слежения за автопарком. … github.com



использованная литература

[1] Д. ван Шрик, «Замечания по терминологии в области
надзора, обнаружения неисправностей и диагностики», Труды
IFAC, тома. 30, нет. 18. С. 959–964, 1997.

[2] Д. Ван и В. Т. Питер, «Прогнозирование шламовых насосов,
основанное на скользящем среднем индексе износа и общем
последовательном методе Монте-Карло», Механические системы и
Обработка сигналов , т. 56. С. 213–229, 2015.