Оригинал публикации на сайте Планета САМ
От редакции Планета САМ: В заключительной части этой серии статей будут рассмотрены некоторые примеры аномалий, обнаруженные в среде механической обработки, а затем продемонстрировано, как специалисты компании MachineMetrics используют полученные данные на производстве.
Оригинал статьи читайте здесь.
Предварительные примеры
Мы определили пять различных категорий аномалий:
- Аномалия предшествует отказу станка/тревоге
- Аномалия возникает одновременно с тревогой
- Аномалия предупреждает нас о внутренних ошибках
- Аномалия возникает, когда происходит что-то интересное, но не катастрофическое
- Шумовые аномалии
Категория 1: Аномалия предшествует простою/аварии
Пример 1: предшествуя ошибке инструмента
Первоначальная цель такого подхода состоит в том, что мы предположили, что станки испытывают аномальное поведение непосредственно перед отказом. Мы записали несколько случаев — здесь мы кратко опишем пример одного из случаев.Аномалия была отмечена в 2:25 (ночью), а спустя 3 минуты в 2:28 произошла катастрофическая поломка инструмента.
Деталь, созданная в 2:25, была аномальной, за две детали до того, как на станке сломался инструмент
Уровень кластеризации
Я наблюдаю аномалию…
С 22 до 6 часов было изготовлено около 450 деталей. На графике выше показано относительное положение сигнатур деталей при проецировании на 2D-плоскость. Как мы видим, на уровне кластеризации явно наблюдается аномалия. Все остальные детали сгруппированы вместе, и DBSCAN легко изолирует аномалию, одиноко плавающую в космосе. Давайте переместимся на один уровень глубже.
Уровень временных рядов
Приведенный выше кластерный график создается из характеристик временных рядов, которые извлекаются из каждой сигнатуры детали. Давайте посмотрим, как расположены характеристики аномалии относительно всех остальных деталей (выделены фиолетовым цветом).
Уровень сигнатуры детали
Как выглядит эта сигнатура детали по сравнению со всем остальным? Ниже мы анимируем 50 сигнатур деталей вокруг аномальной детали. Довольно очевидно, какая из них является выбросом.
Создание сигнатуры детали ускорено в 100 раз по сравнению с реальной производственной средой
Пример 2: Обнаружение отсутствия СОЖ
На этом станке в 9:39 была обнаружена аномалия, и сразу же последовала тревога «нет СОЖ». Операторы были бы уведомлены непосредственно перед тем, как в станке закончилась охлаждающая жидкость.13 августа, 9:39. Охлаждающая жидкость кончается. Станок перестает работать
Дополнительным преимуществом здесь является то, что операторы не всегда внимательны к сигналам тревоги, часто обращая внимание на уведомления только после длительного периода простоя. Станок будет работать на холостом ходу, пока оператор не получит предупреждение, но вместо этого оператор может сократить общее время простоя станка, реагируя на текст аномалии.
Станок залит охлаждающей жидкостью. Охлаждающая жидкость имеет важное значение
Пример 3: предшествующие сигналы тревоги податчика прутка
В последнем примере этой категории оператор получил предупреждение примерно за 6 минут до «ОШИБКА ПОДАТЧИКА ПРУТКА», в 6:23.35. Давайте посмотрим на это на временном графике.
Категория 2: Аномалия возникает одновременно с тревогой
Неудивительно, что мы также обнаружили аномалии, отмеченные одновременно с тревогой. Производитель встраивает аварийные сигналы, чтобы предупредить операторов о чем-то необычном (как и наши оповещения об аномалиях, поэтому неудивительно, что они часто совпадают). Это может быть выгодно, так как, как уже упоминалось, клиенты не всегда обращают внимание на сигналы тревоги. Аварийный сигнал + аномалия может заслуживать большего внимания, особенно если каждый день появляются десятки ложных сигналов тревоги.Эти пары тревога-аномалия, которые указывают на то, что станок работает совершенно по-другому, также могут быть более серьезными, чем процедурные тревоги. В приведенном ниже примере аномалия была обнаружена в 11:29 и совпала с тревогой «время цикла податчика прутка истекло», которая случается, когда для барфидера заканчивается материал.
Аномалия предупреждает нас о сбое в установке, который произошел с обрабатываемой деталью. Деталь, возможно, так или иначе была смещена из правильного положения
Категория 3: Аномалия предупреждает нас о внутренних ошибках
В качестве бонусного побочного эффекта мы также обнаружили пару наших собственных внутренних ошибок, которые проявились как аномалии на наших станках. В приведенном ниже примере мы обнаружили странный случай, когда станок фактически был активным, хотя технически он был помечен как «неактивный». Это заставило станок записать аномалию для детали, созданной в 1:39.Это произошло потому, что мы считываем данные для обнаружения аномалий только когда станок активен, и мы инициировали аномалию, увидев усеченную сигнатуру детали. После подтверждения того, что станок действительно был активен в нашем потоке необработанных данных, мы смогли быстро выявить и устранить ошибку, заключающуюся в том, что наш конвейер данных время от времени отбрасывал наблюдения.
Станок был отмечен как неактивный в течение 3 мин 59 сек, когда он на самом деле производил обработку
Категория 4: Аномалия предупреждает операторов, когда происходит необычная деятельность (но не катастрофический отказ)
Не всем сбоям инструмента предшествуют аномалии, и не все аномалии совпадают или предшествуют сбоям инструмента. В этом случае срабатывает аварийный сигнал «разблокировка выключателя безопасности», потому что оператор не полностью закрыл дверь перед запуском станка, с сопровождающей его аномалией в 12:59. Станок оставался неактивным, пока это происходило в качестве автоматической меры предосторожности. Хотя это и не является препятствием для работы, мастер участка может захотеть узнать, когда это происходит (особенно, если это повторяется), чтобы поощрять более эффективные методы обеспечения безопасности.Оператор попытался запустить станок с открытой дверью, вызвав аномалию в 12:59
Категория 5: Аномалия отмечается из-за странного поведения, которое не подвергает станок опасности
Как всегда, есть крайние случаи, которые не попадают в рамки того, для чего мы разработали нашу систему. В приведенном ниже примере аномалия была отмечена в 2:49, по-видимому, без причины.Здесь, похоже, нет ничего плохого…
Пик нагрузки в 14:48.28
Как Waze, но для станков с ЧПУ
Продуктизация – Этап пилота
Для нашего пилота мы решили просто докернизировать R-скрипты, которые мы использовали для очистки данных и кластеризации. Эти скрипты выполняют всю тяжелую работу, описанную в частях 2 и 3 этого блога, и нам нужно было только обернуть их в контейнер и внести некоторые изменения в автоматизацию, чтобы они были полностью функциональными в производстве.Программа запрашивает данные за последние шесть часов, обнаруживая циклы деталей и устанавливая грубую область нормального поведения. После того как отдельные циклы определены, мы постоянно запрашиваем данные и выявляем аномалии в режиме реального времени. После обнаружения аномалии аномальная часть записывается и SMS отправляется оператору в дополнение к генерации инцидента на странице клиента.
Пример инцидента с аномалией, в котором указаны время, приоритет, достоверность и адресат. Клиенты могут определять приоритеты и адресатов, в то время как мы определяем уровень достоверности, основываясь на том, насколько далеко находится отклонение. Другие инциденты на этой странице инициируются определенной пользователем системой, основанной на правилах
В приведенном ниже примере деталь 262 является аномалией, выпадающей далеко за пределы основного облака. При обнаружении выброса немедленно запускается оповещение.
Визуализация того, что происходит во время обнаружения аномалий
Мы запускаем все это с помощью bash-скрипта, который принимает аргументы, которые изменяют параметры обнаружения аномалий. Это особенно полезно на экспериментальных этапах, поскольку настройку гиперпараметров в основном необходимо выполнять в реальных условиях. Мы имеем дело с уникальной проблемой, потому что трудно проверить аномалии с помощью исторических данных — клиенты часто не помнят, когда станок выходил из строя или испытывал странное поведение. У нас было несколько примеров, которые могли бы помочь нам в этом, но мы не собирали информацию о массовом отказе инструмента в прошлом.
Мы знаем, когда возникают аварийные сообщения на станках, и можем соотнести их с нашими аномалиями. Производители оборудования и клиенты определяют эти аварийные сигналы, которые возникают, когда станок выходит из строя, по соображениям безопасности или когда необходимо выдать предупреждение. Однако трудно распутать ситуацию, когда аварийные сигналы фактически приводят к простою из-за отсутствия стандартизации.
Для справки ниже приведена полная схема для тех, кто интересуется техническими подробностями (или если вам действительно нравятся блок-схемы).
Продуктизация – AWS Лямбда
По мере развития процесса наш план состоит в том, чтобы максимально снизить расходы при одновременном повышении надежности. Мы планируем заменить докеризованные R-скрипты функцией AWS Lambda, которая принимает данные непосредственно из нашего потока данных и выполняет всю их обработку. Там не будет необходимости оплачивать расходы на запрос или EC2; обработка будет быстрее, и будет меньше частей, которые могут потерпеть неудачу. Это также позволило бы нам развернуть это локально для объектов, которые не хотят отправлять свои данные в облако.Мы также добавили возможность сохранять информацию о состоянии станков и о станках, на которых мы хотим это запускать, в Redis.
Будет создан парк лямбд, причем каждая лямбда будет обнаруживать аномалии для небольшой группы станков. Как только лямбда завершает обработку микропартии, она сохраняет информацию о состоянии станка. После возобновления она может немедленно получить сведения о станках, на которые была назначена.
Подробнее о возможностях аналитической платформы MachineMetrics и её отличиях от других систем мониторинга оборудования читайте в статье: «Почему стартап, разрабатывающий аналитическую платформу для дискретного производства, стал новостным хедлайнером».