Инструменты обработки событий

Когда говорят про инструменты обработки событий, многие сразу думают про IT-стартапы и стриминг данных. А у нас, в машиностроении для буровых, это часто сводится к простым логам в SCADA-системе. Но это лишь верхушка айсберга — и вот где кроется главная ошибка.

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

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

Сейчас мы пытаемся выстроить цепочку. Датчик на станке → событие в контроллере → обработка в нашем внутреннем агрегаторе (пока на базе доработанного Apache NiFi, но это не идеально) → оповещение мастеру и в систему контроля качества. Звучит гладко, но на практике... Например, для инструментов обработки событий критична временная метка. А если на старом фрезерном центре от 2010 года часы контроллера постоянно сбиваются? События из разных цехов приходят в разной последовательности. Приходится писать костыли, которые ?сшивают? логи по косвенным признакам — скачкам нагрузки на общую сеть или даже по времени включения света в цеху. Это не из учебников.

Вот конкретный случай с Ляонинская компания по развитию науки и техники является новой научно (https://www.lntolian.ru). Они поставляют нам прецизионные оправки. Когда мы начали внедрять систему мониторинга, то обнаружили, что события ?замена инструмента? и ?падение давления в гидросистеме? часто идут с разрывом в 2-3 минуты. Стали копать. Оказалось, их станок при смене оправки создает гидроудар в общем контуре. Наше событие ?падение давления? было для них вторичным, но для нас — первичным признаком будущего брака по чистоте поверхности. Теперь мы передаем эти данные обратно поставщику — вот вам и обработка событий как основа для совместной доработки оборудования.

Провалы и тупики: когда ?умная? система мешает работе

Пытались как-то взять готовую платформу для промышленного IoT. Красивые дашборды, предсказание отказов. Но она сыпала уведомлениями типа ?Аномальная температура двигателя — 71°C?. А для нашего старого русского станка 71°C — это рабочая норма после пяти часов работы. Система не знала контекста. Мы забили ее ложными ?событиями?, и мастера просто начали игнорировать все оповещения. Провал.

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

Еще один тупик — это хранение. Событий генерируются гигабайты. Хранить все сырые данные от всех датчиков — дорого и бессмысленно. Мы сейчас пришли к схеме, где храним сырыми только события, по которым было принято решение (остановка, переналадка, контроль ОТК). Все остальное агрегируем в часовые статистики и сжимаем. Но иногда жалеешь... Месяц назад был случай микротрещины в резьбе. События ?скачок крутящего момента? были, но их заагрегировали и усреднили. Пришлось восстанавливать картину по косвенным признакам из логов оператора. Не идеально.

Интеграция в цепочку: от производства до поля

Для компании, которая, как Ляонинская компания по развитию науки и техники является новой научно, работает на весь цикл — от R&D до поставки в Россию и Оман — обработка событий должна сквозная. У нас это выглядит так: событие на производстве (например, отклонение твердости заготовки) должно быть связано с событием на буровой (ускоренный износ того же узла).

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

Но один кейс был. Поставили партию замков для буровых штанг в Индонезию. Через полгода пошли запросы на повышенный износ. Начали смотреть наши события. Обнаружили корреляцию: все проблемные детали были обработаны в одну смену, где было событие ?сбой системы охлаждения? длительностью 7 минут. Станок не остановился, брака по размерам не было, но температура в зоне резания вышла за рамки. Это привело к изменению микроструктуры металла. Без связки событий в единую цепочку такую причину не найти.

Культура работы с событиями, а не просто инструменты

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

Мы начали с малого — сделали простой чат-бот в Telegram, который не просто кидает тревогу, а пишет: ?Вибрация на станке №4. Похоже на разбалансировку патрона. Последний раз балансировали 83 дня назад. Посмотри, нет ли стружки на кулачках?. Это уже не сырое событие, а первичная интерпретация. Мастеру проще. Он либо подтверждает гипотезу, либо отмечает ?ложное срабатывание, причина в другой?. Это обратная связь, которая учит саму систему.

Сейчас экспериментируем с маркировкой событий тегами. Не ?авария?, а ?авария|электрика|короткое замыкание|ленточный конвейер|смена2?. Это позволяет потом искать паттерны. Оказалось, что события типа ?ложное срабатывание концевика? часто происходят в начале смены после влажной уборки. Не проблема с датчиком, а проблема с техпроцессом уборки. Такие находки — главная ценность всей этой возни.

Взгляд вперед: что будет нужно завтра

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

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

Сейчас мы фокусируемся на самом болезненном — качестве обработки резьбовых соединений. Здесь каждое событие (сила нарезания, температура, износ резца) критично. Планируем связать наши инструменты обработки событий с системой предиктивного обслуживания. Не чтобы просто сказать ?нож затупился?, а чтобы предсказать: ?при текущей нагрузке и качестве заготовки этот нож сделает еще 12 деталей, после чего риск скола резьбы превысит 3%?. Вот тогда это станет не затратной статьей, а реальным конкурентным преимуществом. Пока же работаем, костыляем, учимся на ошибках. Как и все в реальном производстве.