Экосистема для разработки и применения Computer Vision (CV) в промышленности

Статья написана 2мя авторами: Иваном Мигалем и Юрием Кацером.

На сегодняшний день компьютерное зрение (CV — computer vision) активно применяется в промышленности и уже стало привычной технологией для многих производств. Наиболее частыми примерами являются кейсы с охраной труда и промышленной безопасностью (ОТиПБ). Другими популярными кейсами, больше связанными с самим технологическим процессом, являются:

• Гранулометрия

• Анализ характеристик пены и динамики пеносъема на флотации

• Контроль качества продукции

• И др. кейсы, которые можно поискать в этом репозитории.

При этом большая часть кейсов разрабатывается и внедряется не в виде коробочных решений, а в виде кастомизированных сервисов или в составе других продуктов (часто CV помогает в решении задач автоматического управления оборудованием, дополняя состояние системы и признаковое пространство данными, полученными с видеокамер). Да и процесс разработки продуктов с моделями CV часто кастомизирован. Мы в Rocket Control прошли путь от кастомного решения для виртуальных датчиков на основе характеристики пены на флотации до полноценного CV продукта. Но в этой статье мы хотим поделиться опытом разработки экосистемы (если есть слово поудачнее, то обязательно поделитесь в комментариях) сервисов для упрощения процесса разработки моделей и решений по CV (часть CV продукта). Идея написать статью укрепилась после того как мы пообщались со специалистами из разных промышленных компаний и поняли, что опыт у всех довольно разный, а средний уровень зрелости еще не такой высокий.

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

Так зачем нам экосистема?

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

Начнем немного с того, какие роли есть в наших проектах (список не полный, но достаточный для данной статьи):

• Инженеры по контролю за техпроцессом. Данные специалисты не обладают навыками разработки и пониманием ML-процессов, но умеют работать со внутренней платформой и ее компонентами (low-code/no-code). Также разбираются в техпроцессе и понимают доменную область, занимаются проектной деятельностью.

• ML-специалисты, DS’ы или Датасайентисты. Специалисты проводят анализ данных, разрабатывают модели, конфигурируют управляющие контроллеры и обвязку, а также занимаются интеграцией и инженерией данных. Также они глубоко разбираются в техпроцессе, формулируют и решают задачи оптимизации производств. Занимаются проектной деятельностью.

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

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

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

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

Архитектура

Архитектура представлена на рис 3. Формально выделяют следующие компоненты:

–cv-mdk – библиотека модулей работы с изображениями, видео, компонентами пайплайнов для разработки решений

–cv-product – репозиторий, где собирается решение и передается на прод

–cv-toolbox/cv-ecosystem – streamlit-приложение, которое реализует набор инструментов для работы с данными (нарезка видеокадров, авторазметка), моделями (валидации моделей детекции и трекера), а также инструменты для работы с аутсорс-подрядчиками (передача кадров с разметкой и приемка)

А вот как выглядит стартовая страница приложения:

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

Пример

Приведем пример использования cv-ecosystem для решения задачи по процессу из рис 1. Представим, что мы решаем задачу оценки динамики пеносъема. Данную задачу мы решаем как задачу отслеживания объектов (Multiple Object Tracking).

1. Сбор данных

Сбор данных осуществляется посредством записи видео либо с помощью SDK производителей камер или специальных приложений для записи видео, либо с помощью нашего внутреннего приложения. Мы разработали свое приложение, чтобы взаимодействовать с разными камерами/кодеками и конфигурировать процесс записи удобным образом. Полученные видеофайлы сохраняются в blob хранилище для дальнейшей разметки. Процесс регламентирован и передан Инженерам по управлению техпроцессом. Инженеры понимают, какие моменты техпроцесса нужны и сколько данных примерно нужно, поэтому ML-специалисты в этом процессе участвуют для консультаций и поддержки, что составляет до 5% их рабочего времени.

2. Разметка данных

Разметка данных осуществляется в два (или три) этапа:

• (если применимо) Разметка режимов технологического процесса на видео (сегментация видео)

• Поиск интересных сегментов (промежутков) в видео и нарезка кадров

• Разметка объектов на кадрах

Что мы называем “интересными сегментами” зависит от этапа проекта:

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

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

Для разметки режимов на видео мы разработали страницу streamlit-приложения make markup. Часть интерфейса можно увидеть на рис 5. Здесь:

• Пользователь выбрал видео

• Появился видеоплеер

• После просмотра пользователь заносит информацию, какие отрезки видео имеют выраженный класс пены и потока

• Пользователь cохраняет данные

После того, как участки видео размечены (сегментированы), пользователь с помощью make frame tasks выполняет:

• Нарезку кадров

• Создание разметки с помощью SAM

• Создание задачи в CVAT для ручной коррекции разметки

• Создание задачи в таск трекере и привязка к задаче в CVAT

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

• outsource archive — для отправки кадров на разметку (рис 6-7)

• outsource upload — для приемки разметки (рис 8)

На странице outsource archive:

• Пользователь видит, какие кадры еще не размечены

• Может выбрать, какие надо отправить на аутсорс-разметку

• Предварительно посмотреть кадры

• Сформировать архив для передачи

Процесс приемки выстроился таким образом, что от подрядчиков мы принимаем архивы с отдельными кадрами, а не все кадры сразу. Поэтому на странице outsource upload:

• Пользователь загружает архив с кадром и разметкой

• Система определяет, что это за кадр в CVAT/таск трекере

• Пользователь через интерфейс смотрит на качество разметки

На рис 8 можно явно увидеть, что есть неразмеченные полосы. Это связано с тем, что такие кадры тяжело размечать подрядчику, поэтому он разбивает их на части, размечает их отдельно и перед отправкой склеивает обратно. Такие артефакты мы обрабатываем своими силами с помощью CVAT (рис 9). Также есть места вне этих полос, где стоит разметить пузыри. В этом случае мы возвращаем подрядчику кадр на доразметку, если видим систематическое отклонение от техзадания.

3. Обучение модели

Обучение модели проводим через Openmmlab экосистему:

• Настраиваем конфигурационный файл (выбор данных, выбор модели, конфигурирование архитектуры, препроцессинга, постпроцессинга, метрик)

• Запускаем обучение

• Мониторим метрики обучения в Tensorboard

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

4. Валидация модели

Валидация частично проходит на этапе 3, здесь расскажем про визуальную часть. Для этого реализованы страницы detector validation и tracker validation. На этих этапах мы:

• Загружаем модель

• Выбираем картинку, батч картинок или видео файл

• Смотрим на результат (метрики, нанесенную разметку детекций и трекинга)

По рис 10-11 пользователь может визуально оценить качество работы моделей и принять решение: допускать модель к работе или дообучить ее. Например, на рис 10 можно отметить, что модель детекции практически все пузыри определяет правильно, доля ложных срабатываний (поток с желоба, часть пузырей на трубе слева и пр) есть, но такой произвола в рабочих зонах (камеры и стенки желоба) при детальном просмотре заметить сложно. Есть боксы, которые не полностью покрывают пузырь, но таких случаев очень мало.

Также для пользователя интерфейс показывает расчеты признаков по рабочим зонам, что является еще одним показателем работы трекера. На рис 13 мы можем видеть, что число пузырей неправильной формы в рабочей зоны камеры порядка 40% от всего числа определенных пузырей, что, в целом, соответствует действительности. Однако сомнительно, что число пузырей так сильно меняется между кадрами. Возможны две ситуации:

1. Пузыри лопнули и вместо них выплыли новые. Тогда это естественный процесс и мы на него не можем влиять

2. Трекер периодически теряет и восстанавливает треклеты. Тогда надо настроить его чувствительность, возможно он теряет пузыри между кадрами.

5. Оборачивание в сервис

На этом этапе мы создаем конфигурационный json-файл решения, которое будет запускаться на проде. Один из шагов в создании — определить рабочие зоны, где решение будет смотреть на пеносъем и вычислять признаки. Для этого создана страница draw polygon, которая позволяет делать это очень быстро.

Все, что нужно сделать, это:

1. Загрузить картинку

2. Придумать имя рабочей зоны (в примере — “YOUR_POLYGON”)

3. С помощью мыши нарисовать рабочую зону на картинке

4. Повторить пп. 1-3

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

6. Деплой

Выпуск решения проходит через CI/CD процесс и согласован с информационной безопасностью (ИБ) клиента. До передачи мы:

• Выполняем набор unit/integrated/e2e-тестов

• Создаем релиз

• Собираем образ

• Делаем уведомление в нашем внутреннем мессенджере

• Проектная команда берет артефакты и передает на прод по построенному с ИБ процессу с блэкджеком и проверками.

Процесс от сборки до уведомления автоматизирован на стороне Gitlab CI/CD, это выполняет разработчик продукта.

После процедуры переноса на прод Инженеры по инструкции запускают решение на платформе в контуре заказчика, после чего выполняется ряд sanity-check’ов.

7. Диагностика решения

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

Итого получается следующая схема разработки ML-решения:

Итог и эффекты

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

• Переход на Django

• Автоматизация сегментации режимов на видео

• Улучшение процесса валидации качества моделей и движение в сторону интерпретации результатов, чтобы лучше понимать, почему модель выдала такой результат

• Улучшение тестирования решений для приближение к продовым сценариям

• Добавление поддержки видеостриминга с камер в экосистему

• Повышение качества синтетической разметки

• И др.

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

Еще раз про то, что мы получили от используемого нами подхода (хотя эффекты от платформенности/экосистемности довольно типовые):

• Снижении порога входа для разработки моделей CV.

• Снятие узкого места в виде ресурса Дата-сайентистов и Разработчиков, возможность масштабировать проекты с CV, возможность сократить сроки проектов за счет привлечения дополнительных ресурсов Инженеров.

• Ускорение ttm новых моделей. Получилось ускорить процесс от получения данных с фабрики до доставки новой модели в продакшн с недель до дней (сильно зависит от объема разметки).

• Повышение прозрачности в трекинге задач, ответственных за задачи, статусе работ.

• Воспроизводимость экспериментов и логирование всех изменений.

• Облегчение поддержки.

• Упрощение и ускорение работы с подрядчиками, занимающимися разметкой за счет стандартизации подходов и требований к результатам разметки и данным.

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