Архитектура современных систем объектовой видеоаналитики. Процесс становления или укоренившиеся со временем изъяны?

Текущий год – это ралли среди различных систем распознавания и детекции объектов от различных вендоров. Новые устройства для исполнения нейронных сетей: FPGA, VPU, многоядерные процессоры с VNNI и многое другое предлагается от разработчиков аппаратной части. Параллельно наблюдается рост числа доступных топологий, а также готовых предобученных сеток. Детекция инцидентов, ДТП, подсчет пассажиропотоков, построение половозрастных портретов, распознавание эмоций и многое другое сегодня доступно для разработчиков. И все было бы хорошо, если бы не замысловатый «Time to market» (быстрее, быстрее на тот самый рынок, где деньги и если не мы первые, то точно не успеем), следствием которого мы видим на выходе слабо (читай – сложно, дорого) поддерживаемые монструозные системы All-in-one. А ведь параллельно существуют архитекторы (люди), виртуализация (подходы), способы автоматизации процессов, системы контроля состояний и параметров устройства или их множества. Но ввиду сжатых сроков, это опускается и появляются те самые, описанные выше, монстры. И да, задача «быстрее в рынок», часто бывает достигнутой. Но основная ошибка на начальном этапе заключается в том, что после достижения первичных целей сегодня, требования к скорости дополнения и развития решений будут только усугубляться. Рынок-то растущий, система несовершенна и требует развития, а не шага назад и переработки proof of concept в промышленное решение. И на этом этапе проверка гипотезы уходит в продакшн.

image

Чем это чревато и кто пострадает?


Для разработчика можно отметить следующие последствия:

  1. Сложность поддержки и продолжения разработки. Ввиду отсутствия системного подхода и архитектуры огромное количество копипаста будет требовать или исправления ранее допущенных ошибок, а это время, или их последовательного накопления, а это тупик в будущем.
  2. Сложность расширения команды и отсутствие возможности делегирования конкретных задач аутсорсерам или другим отделам внутри компании.
  3. Чем больше система, тем сложнее ее поддерживать. Сложнее – это дольше, дольше – это дороже. А там где есть плохое дорогое решение, рано или поздно, появится хорошее, построенное по правильной модели изначально и, как следствие, значительно более дешевое в развитии и поддержке.
  4. Часто, отсутствие наследования, репозиториев и веток в разработке не даёт технической возможности создавать и проверять альтернативные гипотезы по схожим решениям. Например, веткой объектовой видеоаналитики на х86 архитектуре является портирование на ARM для работы в непосредственной близости от источника данных (камеры) и/или напрямую в камеру. Далее, от ветки порта системы в камеру могут быть различные вендоры, под которых делается адаптация (например, интерфейса и иных частей). При отсутствии структуры каждая из этих веток, которые должны быть в четкой иерархии, делается путем копирования текущего состояния проекта. Дальше появляется разрозненное развитие множества проектов и параллельное решение одних и тех же задач. Параллельное решение одного и того же – зря потраченное время и деньги.
  5. Сложности в локализации продуктов и решений. Отсутствие локализации тормозит процесс выхода на иные рынки, где решение может быть больше востребовано, чем на текущем.

Для владельца решения (иногда одно лицо с разработчиком, но это не важно):

  1. Бесконечный рост стоимости проекта.
  2. Отсутствие возможностей для прогнозирования и бюджетирования проекта.
  3. Постоянно растущий со временем риск начать работать в минус себе.
  4. Усложнение и удорожание процессов развития проекта с течением времени и чем дальше будет рефакторинг, тем дороже и дольше он получится.

А для клиентов (или разработчиков на основе SDK вендоров) следствием являются:

  1. Чем дальше, тем поддержка становится все хуже и хуже.
  2. Со временем изменения и исправления ошибок делаются все дольше и дольше.
  3. Не поддерживаются новые протоколы, устройства, сетки или иные направления в развитии системы, хотя изначально, обычно, это предполагается и выделяется как преимущество.
  4. Отсутствие стабильности в работе систем.
  5. Отсутствие способов проверки состояния систем и/или устройств, на которых они работают и которые являются неотъемлемой частью общей инфраструктуры. Обычно, данное замечание касается гибридного инференса, где часть систем объектовой видеоаналитики работает «на краю», часть на серверах, а часть непосредственно в камерах. И конечный пользователь обладает подобным «огородом», работоспособность которого с учётом расширения инфраструктуры клиента должна оставаться, а получается с точностью до наоборот. Рост подобных систем без заложенных в них механизмов проверки, отладки и контроля, приводит к снижению их работоспособности во времени и усложнению процессов контроля работы их элементов.

А в чем, собственно, проблема?


Основная проблема кроется в подходе, все и сразу, и как можно быстрее. Архитектура, проектирование, прототипирование требуют времени. Мы же не дом строим, а всего лишь ИТ-решение, сервис или модуль. Зачем все это? И как только вы услышали эти слова, то пути назад уже нет.

image

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

Для начала рассмотрим, как строилась эта система изначально:

  1. Максимальное время и силы были уделены сеткам в основе: сегментации изображений, детектированию объектов по типам и качеству/скорости распознавания. Это – основа системы.
  2. Минимум времени было уделено обвязке, те архитектуре в целом, а не ее основному модулю. В итоге, в одном окружении оказались прием RTSP потока, его нарезка на фреймы, обработка фреймов под дальнейшие действия, сегментация, детекции, распознавание, тракторный анализ, контроль идентичности объекта в кадре для предотвращения фиксации дублей, СУБД, пост/предобработки, импорт/экспорт данных, веб-интерфейс, REST API и многое другое.
  3. Рынок требовал ещё и ещё. Вместо одной сетки, которая была в основе изначально, множества сеток. Ведь события, в принципе, универсальны и с точки зрения позиционирования систем – детектор различных событий: люди, лица, номера, не важно что. Но в основе системы – не множество сеток, а одна, конкретная.
  4. Расширение и доработка системы – ошибки. Общее окружения множества различных систем подсистем – это сложности в отладке, время. Потеря времени – потеря преимущества в выходе на рынок, потеря конкурсного преимущества.

А как могла бы выглядеть архитектура в первом приближении?


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

  • Вход и обработка входящего потока: gstreamer, ffmpeg + ffserver, valkka
  • Веб-интерфейс
  • REST API
  • Контейнер для инференса множества сетей
  • Постобработка фреймов и формирование исходящего RTSP потока с учётом нанесения данных о найденных объектах (по результатам обработки детектором)
  • СУБД и хранение данных: PostgreSQL, MySQL, NoSQL DB

image
Docker — построение правильной архитектуры

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

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

Результат


  1. Множество контейнеров с различными вариантами обработки входящих данных и их хранения в зависимости от требований в рамках конкретного внедрения.
  2. Унифицированная система хранения различных видов события.
  3. Унифицированная связка различных нейронных сетей и детекторов событий.
  4. Возможность расширения функционала путем добавления новых общедоступных сетей и детекторов для проверки гипотезы и с их дальнейшим дообучением для запуска продакшн версий.
  5. Встроенная система контроля состояний устройств и системы, в целом (zabbix, chronograf).
  6. Кроссплатформенность решения и возможность разворота на любом оборудовании.
  7. Простота развития продукта и возможность делегирования разработки отдельных частей различным группам, включая команды аутсорсеров.
  8. Простота отладки проблем в процессе эксплуатации (четкая идентификация места проблемы и возможность логирования внутри каждого контейнера).
  9. Возможность масштабирования системы и выполнения контейнеров как в рамках одной физической машины, так и в рамках множества

Главное, в процессе реализации не заиграться и правильно построить архитектура проекта, в целом. Работайте с профессионалами, итог – экономия времени, затрат, сил, ресурсов, денег. В противном случае, с Докером бывает и вот так:

image
Ехал Docker через Docker, видит Docker в Docker Docker...
Источник: habr.ru