Вступление

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

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

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

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

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

Исследовательский анализ данных - как выглядит проблема?

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

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

Чтобы сделать более подробное вскрытие, давайте посмотрим на предысторию этого события в виде таблицы.

Мы видим череду ПРЕДУПРЕЖДЕНИЙ, за которой следует череда НЕИСПРАВНОСТЕЙ, а затем машина отключается на 20 минут. Согласно аннотации оператора, это произошло из-за «смены инструмента (внеплановой) :: сверление \ n \ nброс».

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

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

Если посмотреть на аннотации операторов, сложная часть проблемы состоит в том, чтобы связать простые, однозначные значения времени простоя со строками текста, которые вводят операторы. Как и ожидалось, даже для одной и той же проблемы с машиной ввод текста в наш планшет сильно различается в зависимости от индивидуальных клиентов, отдельных операторов и отдельных событий. (Обратите внимание на кажущиеся произвольными разрывы строк в строке «Drill \ n \ nbroke.»). Проще говоря, разные люди вводят аннотации по-разному из-за различий в знаниях предметной области, комфорта с технологиями и желания использовать систему MachineMetrics.

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

Исследовательский анализ данных - дополнительная информация о сигналах тревоги и аннотациях

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

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

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

Следующий шаг - выяснить, на какие машины смотреть. Различные производители машин и типы адаптеров эффективно говорят на разных языках аварийных сигналов, и каждый из них необходимо изучать отдельно. Мы начинаем с выбора марки / типа, которая дает нам наибольшее количество четко классифицированных простоев для изучения. Это Okumas, работающие на их адаптере MTConnect, представляющие более сотни отдельных машин и около 3000 простоев, отнесенных к трем вышеупомянутым категориям.

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

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

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

Чтобы определить подходящий временной интервал для разделения последовательностей, рассмотрите распределение интервалов между соседними сигналами тревоги. (Обратите внимание на логарифмическую шкалу времени на графике и минимально определенный промежуток в 1 мс, чтобы избежать log (0).)

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

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

Вы можете заметить какие-нибудь закономерности?

Простая модель «мешка с тревогами»

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

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

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

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

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

Для справки, идеальной моделью здесь была бы просто единичная матрица (единицы на диагонали, в противном случае - 0). Случайное угадывание было бы матрицей, равномерно заполненной 0,3333…. Ясно, что мы находимся где-то посередине. И похоже, что некоторые каналы путаницы практически отсутствуют. (Например, поломку и смазку очень редко путают друг с другом.) Неплохо для наивной, более или менее готовой модели!

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

Следующие шаги

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

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

Следите за новостями!