Есть распространённый стереотип, будто на заводах надо каски детектировать или даже огонь. Но ведь идея в том, чтобы стремиться не допустить огня и всяких происшествий, а не фотографировать их. Поэтому на практике мы стараемся детектировать то, что происходит до того, как что-то подтечёт, задымится, загорится или пойдёт не по плану.
Меня зовут Щемелинин Вадим, я четыре года работаю в сфере цифровизации промышленности в компании «СИБУР Диджитал». Моя основная задача — развитие Индустрии 4.0 в холдинге. Одним из продуктов моего направления является видеоаналитика. Сегодня я расскажу про сложности, с которым сталкиваются Python-разработчики, внедряя машинное зрение в нефтехимическую индустрию.
Введение
Есть два важных аспекта, которые стоит держать в голове, говоря о видеоаналитике в СИБУРе.
Во-первых, СИБУР ничего не добывает, у нас нет своих нефтяных скважин. Мы покупаем то, что раньше активно сжигали при добыче нефти и газа, и дальше перерабатываем — производим полиэтилен, полипропилен, каучуки и т.д.
Во-вторых, «СИБУР» — это не один большой комбинат. У нас много предприятий: свыше 20 производственных площадок. Они разбросаны по обширной территории нашей страны и не только.
При этом одно предприятие может иметь площадь более 700 футбольных полей, как, например, ЗапСибНефтехим.
На заводах стоит много сложного оборудования, обеспечивающего необходимые химические реакции для производства продукции. При этом используемое сырьё часто является взрывоопасным, а температуры при реакциях могут быть в несколько сотен градусов.
Предприятие выглядит примерно так:
Это ЗапСибНефтехим. А оборудование предприятий управляется как-то так:
Это бункер, в котором сидят люди (технологи, аппаратчики, операторы) и ведут технологический процесс. У них много мониторов, на которых выведена вся актуальная информация о производственном процессе, в том числе и картинки с камер видеонаблюдения.
Вот, например, камеры, выводимые в операторной полипропилена ТомскНефтеХима:
Тут не самое большое количество камер, которые выводятся на одного сотрудника. Были случаи, когда на один монитор выводилось более 50 камер..
Изначальная задача звучала так: “Нужно, чтобы камеры выводились оператору только тогда, когда требуется его внимание”. После её реализации предыдущий экран с камерами стал выглядеть примерно так:
Здесь на верхней правой камере явно видно, что забито вибросито. Это говорит о том, что производится не тот продукт, то есть брак. Чтобы этого не случилось, нужно детектировать такие моменты на ранних этапах. Когда всё хорошо, камеры оператору не выводятся.
Всего на всех предприятиях работают три с лишним тысячи камер технологического видеонаблюдения, разбросанных на очень большой площади и наблюдающих за совершенно разными технологическими процессами. И это только камеры наблюдения за производственным процессом, а есть ещё и охранные камеры.
Чтобы справиться со всем этим, очевидно, нужно делать разные модели под разные камеры, и всё это автоматизировано развернуть и мониторить на предмет деградации моделей.
Ограничения
Исходя из условий задачи, мы с командой сформулировали следующие ограничения для нашего решения.
Во-первых, свести видеопотоки в одно место (в Москву, например) для дальнейшего анализа не получится. Не хватит канала связи.
Во-вторых, время на полную обработку должно составлять менее 5 секунд. То есть за 5 секунд с момента, когда физически что-то произошло, мы должны забрать видеосигнал, проанализировать его и вернуть оператору уведомление, чтобы тот ещё успел на него среагировать. Эта цифра появилась немножко эфемерно, исходя из анализа того, сколько в реальности времени занимает у оператора принятие решения, если он смотрит в экран 24 на 7, не отвлекается и распознаёт события “вручную”.
И в-третьих, мы не хотим превратиться из команды разработки в команду техподдержки. Для этого нужно эффективно управлять процессом внедрения разных моделей и следить за качеством их работы, чтобы своевременно выявлять деградацию точности.
Решение
Учитывая данные ограничения, мы решили сделать децентрализованную систему, которая основана на микросервисах. Архитектура выглядит страшненько:
Тут важно, что в блоке с аналитикой (зелёный прямоугольник) крутится модель, которая подключена к конкретному и ограниченному количеству видеопотоков. Один экземпляр системы развёрнут на одном конкретном участке производства, максимально близко к конкретным видео камерам. Таких инстансов много по предприятиям. А в Москве, где собираются метрики и ключевые события от инстансов, находится только блок управления моделями, админка, и дашборды. Звучит вроде неплохо, но скажу честно: проблемы есть.
Например, с обновлением версий моделей не всё так радужно, как хотелось бы. Так как забрать сигнал в Москву не получится, а тестовая выборка очень подвержена влиянию внешних факторов, необходимо проводить тестирование на реальном потоке с реальной вариативностью, то есть тестировать модели не только на записанных датасетах, но и обязательно на online-данных с камеры на заводе.
Для этого в компании есть dev-test-prod подход. Dev-сегмент - песочница, в которой можно копаться и использовать практически всё что угодно для разработки и тестирования. Далее проверенные образы нам необходимо развернуть в Test, а затем и Prod-контурах. В случае с видеоаналитикой и тестовый, и продуктовый контуры находятся на разных заводах и практически полностью изолированы от корпоративной сети офиса в Москве.
В целом, система со своей работой справляется неплохо, уже покрыто 70% камер. Важно понимать, что не для всех камер необходимо находить специфичные детекторы. Есть и штатные модели в самих камерах и системе видеонаблюдения, основанные на детекторе движения. Настраивая зоны, мы можем получить нужный нам результат.
Но, конечно, простыми готовыми алгоритмами не всегда можно решить нашу задачу. При принятии решения о том, внедрять специфичную модель или оставить камеру выводиться оператору, всегда важным аспектом является оценка: зачем нам нужно делать эту модель, для чего она вообще нужна? Тут мы переходим к вопросу о том, что мы контролируем, когда говорим про видеоаналитику.
Области применения
С помощью видеоаналитики мы контролируем сразу несколько сквозных процессов в компании:
Maintenance-to-Fix — контроль за работой оборудования, ремонтами, чтобы завод дольше проработал без остановок на ремонт.
Plan-to-Produce — производство продукции в соответствии с потребностью рынка, контроль брака, то есть следим за тем, что производится та марка, которая была запланирована, и в том качестве, которое от нас ждёт потребитель.
Логистика и любимая многими ОТиПБ. Здесь мы говорим не столько про контроль за нарушениями в виде отсутствующей каски, сколько в целом про контроль за процессами, в которые активно вовлечены сотрудники подрядных организаций.
IT блок — связан с управлением уже существующими камерами. Нам часто приходится участвовать в диалоге вида:
– Зачем вам эта камера?
– Смотрим, когда дождь пойдет.
Понятно, что тратить деньги компании на такую камеру нет никакого смысла, и в процессе внедрения видеоаналитики мы смотрим, что нужно детектировать, распознавать, как часто что-то происходит. Так мы получаем фактуру для диалога с производством на предмет необходимости камеры и возможности её использования в другом месте.
Разрабатываемые модели
Разберём на примере одного кейса. Задача — автоматически определять, когда заклинивают толкатели на компрессоре ТНХ.
Это компрессор ~70-х годов. На нем завязано много технологических процессов. Если он встанет, то это критично для производства мономеров.
За чем нужно следить? На картинке выше приведена лубрикаторная секция. В этом компрессоре их несколько.
Важно не пропустить два момента:
Уровень масла. Это в теории можно контролировать датчиками. Но не всегда это возможно на практике. В данном случае задача решается через видеоаналитику.
“Залипание” поршня, который снизу создаёт давление для подачи масла дальше. Если поршень “залипает”, масло не поступает в компрессор, в результате чего он встаёт, хоть и не сразу, но достаточно быстро. Нужно отследить момент, когда любой из поршней “залип”, для того, чтобы аппаратчик пришёл и отрегулировал оборудование. Подобный контроль оптимальнее всего решается через видеоаналитику.
В чём сложность? Это закрытый цех с естественным освещением. В нём постоянно что-то бликует, большая вибрация на оборудовании и стенах, камеры периодически съезжают куда-то не туда. Как итог не получается чётко закрепить зоны (ROI).
Таким образом, на первом шаге нужно детектить зону c поршнем. На втором шаге производим преобразования кропа, а на третьем — бинарную классификацию. Работает неплохо. Модель в принципе несложная, если сравнивать с распознаванием лиц на iPhone. Но задачу нельзя решить классическими методами компьютерного зрения, нужна сеточка.
Компрессор большой, секций много, поэтому вылезает ещё один вопрос — про железо и/или оптимизацию.
Оптимизация
Когда мы спрашивали у коллег из других компаний: «Как вы оптимизируете модельки?», умные люди всегда отвечали: «Квантуйте! Зачем вы вообще делаете под CPU, делайте под GPU, используйте облака, как все нормальные парни».
Однако облака СИБУР использовать не может, потому что речь идёт про завод, а значит — закрытый периметр. Выгружать из него ничего нельзя. Серверное железо, которое стоит на заводе, тоже должно быть типовое, потому что, если что-то выходит из строя, его нужно быстро заменить. То есть железо расширять можно, но достаточно ограничено. GPU есть в dev во время обучения, а в инференсе под наши задачи их, скорее всего, в ближайшее время и не будет, в первую очередь из-за сложностей с обслуживанием на предприятии.
Решение, которое мы с командой взяли на вооружение — это OpenVINO.
OpenVINO на наших моделях дал прирост в среднем в 10 раз, что позволило даже легкие модельки запихивать на ещё более маленькие виртуалки и решать проблемы.
Детекция загрязнений на реакторах
Другой задачей было детектировать загрязнения реактора при его чистке. При этом параллельно выделять трещины и внешние зашумления.
В данном случае это колонна реактора высотой 50 м. Камера опускается вниз вместо эндоскопа, и в процессе опускания и подъёма происходит аналитика того, насколько хорошо подрядчики очистили стенки реактора. Реализация модели базово тоже достаточно простая, но пришлось много поработать над фильтрацией шумов.
Другой пример с использованием U-net относится к контролю продукции, а не оборудования. Продукция СИБУРа очень сыпучая. Как пример, гранулы полипропилена могут комковаться и быть разных размеров. Для их фильтрации на соответствие целевой марке используются виброклассификаторы:
Но в случае забивки ячеек сита гранулами классификация нарушается. В зависимости от продукции это либо просто очень плохо, либо критично и требует оперативного воздействия на технологический процесс во избежание выхода оборудования из строя.
Задача модели: детектировать степень заполненности поверхности вибросита агломератами.
Сита разные и опять же есть внешняя вариативность. Поэтому сделать что-то простое и одновременно общее для всех не получится.
Например, на верхней картинке — бункер. Мы думали, что там искусственное освещение, потому ничего не будет меняться. Заточились под освещение, и потом летом увидели, что что-то не так. Выяснилось, что парни на заводе открыли выше этажом дверь для того, чтобы было не очень жарко. Из-за открытой двери поменялось освещение, и модель начала работать хуже. Много таких нетиповых моментов, которые не увидишь сразу, выгружая датасет для обучения и тестирования. Хотя изначально казалось, какая уж тут вариативность - бункер ведь! Поэтому и есть острая необходимость тестироваться непосредственно на реальном видеопотоке.
Итоговое решение выглядит так:
Разметка и вариативность
Разметка — это отдельная боль…
В предыдущем кейсе любой человек мог разметить, если на сите что-то лежит или это просто фон. Однако вот ещё один кейс. Была задача детектировать состояние продукта (крошки) в окошках ёмкостей на этапе дегазации каучука (нормальный/ненормальный). Где тут хорошо, а где плохо?
На самом деле ответ такой:
Левая нижняя картинка — это плохо.
Правая нижняя — хорошо: установка просто стоит и ничего не происходит.
Левая верхняя — это хорошо.
Правая верхняя — вроде ничего, рано бить тревогу, но надо последить.
Размечать такие данные в принципе нереально без технолога, который понимает, что именно варится, а варятся там разные марки продукции, и “нормальное” их состояние выглядит по-разному. Для решения этой задачи мы сначала начали использовать полуавтоматическую разметку: в принципе убираем фон, выделяем то, что нам интересно, и дальше пытаемся работать с этим; а затем выстроили организационные процессы совместно с технологами, с учётом информации о том, какая марка идёт в данный момент.
В данном кейсе уже недостаточно смотреть на кадр в отдельности. Поэтому ключевое отличие этой модели в том, что она анализирует последовательность кадров для того, чтобы понимать, что происходит с течением времени. Для этого мы используем LSTM.
На выходе классификатор выдаёт несколько классов: «хороший», «хороший-плохой», «плохой», «ничего не происходит».
Ещё один пример с использованием последовательностей кадров, но уже про понимание сцены. Задача заключалась в том, что нужно детектировать смену этапов (начало и конец) при проведении сливоналивных работ.
В чем подвох? Есть сливная/наливная эстакада, куда приезжают вагоны, и их должны обслужить сотрудники нашей компании для того, чтобы забрать или налить продукт. Однако помимо сотрудников нашей компании есть ещё сотрудники подрядной организации, которые должны подготовить вагон-цистерну. Чаще всего всё работает как часы, но бывают ситуации, например, в субботу в три часа ночи, когда процесс даёт сбой. Выглядит это так: стоит вагон-цистерна, к ней вообще никто не подходит, потому что одни пришли, что-то сделали, но не сообщили, а другие не поинтересовались, не пора ли приступать к следующему этапу.
Мы стали думать, как решать этот момент. Через камеры, которые изначально ставились для того, чтобы контролировать наличие страховочной привязи на человеке, решили посмотреть, сможем ли мы распознавать различные шаги процесса. Кроме этого часть этапов мы видим по значению скорости потока продукции в сливоналивном устройстве.
Таким образом у нас идёт распознавание не просто какого-то события, а последовательности разных действий, которые могут меняться, если что-то идёт не по плану. Например, поставили вагоны, потом поняли, что в один из вагонов заливать продукт нельзя, часть вагонов укатили, прикатили новые. Нам во всём этом нужно выдавать устойчивую картинку подобных изменений операторам, чтобы вовремя подсветить: «Человек, у тебя что-то не так, вмешайся в процесс!».
Решали эту задачку тоже через LSTM с распознаванием различных сцен.
Выводы
Изначально мы хотели сократить количество камер, которые одновременно выводятся оператору, и привести всё к тому, чтобы изображение появлялось на мониторе, только если что-то идет не так. В 2020 году удалось покрыть 30% от общего числа камер — увидели, что все идет здорово, преодолели пандемийный кризис с его сокращениями бюджетов на проекты, доказали свою эффективность.
Сейчас мы на этапе, когда мы должны покрыть 90% стационарных камер и завершить интеграции с разными уже существующими системами. Параллельно начинаем смотреть в мобильные камеры, AR-очки. Задумка в том, чтобы распознавать действия человека с AR-очков, когда он выполняет определенные регламентные операции.
Про этот наш эксперимент я буду рассказывать на ближайшем хайлоаде 25 ноября, приходите послушать.
Но кроме успехов есть и нерешённые на данный момент задачи. Одна из них про решение проблемы с серверными мощностями и большим количеством моделей, которые мы деплоим, — уйти в EDGE и работать с небольшими вычислителями, на которых стабильная версия модели будет работать прямо рядом с камерой. Если честно, я еще ни у кого из коллег по цеху пока такого не видел, но, может, вы сталкивались — поделитесь в комментариях :)
