Как фактически измеряется конечная польза от системы видеонаблюдения?

Началось закономерное развитие возможностей видеосистем

Одна из осей, по которой они стали развиваться – количественная ось. Росло количество камер и количество точек наблюдения, с которых можно было вести работу с этими камерами. 
К слову, развитие систем IP-видеонаблюдения – это следование количественной оси. Потому что IP-видеонаблюдение позволяет включить камеры и рабочие станции, где могут работать операторы, в любые места сети и в любом количестве.

Одновременно с этим развитие систем шло по другой оси – качественной. В рамках него компании-разработчики (и мы, и наши коллеги) предлагали интеллектуальные модули видеоаналитики. Компании разрабатывали модули трекинга объектов, распознавания лиц, распознавания автомобильных номеров, детектора дыма и огня и т.д. Вместо простого наблюдения и записи видеосистемы выходили на некий новый качественный уровень функциональности.

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

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

Переход в трехмерную систему координат

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

Развитие функционала интеллектуального видеонаблюдения исходило из технологических трендов, технологического фундамента. На самом деле компании-разработчики всегда предлагали то, что они могли технически сделать. Развитие шло не по пути ориентации на реальную задачу и реальную полезность, а по пути того, что можно сделать технологически.  И по факту результаты работы часто оказывались такими, что реальную пользу реальным пользователям на реальном объекте модули видеоанализа не несли.

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

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

Спросить пользователя, чего ему не хватает

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

В наибольшей степени всем этим требованиям сегодня в Macroscop отвечает функция межкамерного трекинга.

Когда мы пришли к пользователям, выяснилось, что у большинства из них повторялась одна и та же проблема: в ситуации, когда какой-то человек появился в поле зрения какой-то камеры на 5 секунд, потом из него вышел, как быстро узнать, куда он пошел дальше? Если в непосредственной близости никаких камер нет, то как понять, а под какой камерой и когда он появился в следующий раз? Люди сказали, что сталкиваются с этой задачей довольно часто, для ее решения они вынуждены вручную просматривать каждую камеру в отдельности или включать синхронный просмотр архива, отмечать на бумаге время и камеру и т.д. С удивлением для себя мы обнаружили, что эта проблема: понять, откуда человек пришел, куда пошел, как перемещался по объекту, - встречается очень часто на совершенно разных объектах. Услышав об этом, мы начали работать над решением, которое в дальнейшем получило название функции межкамерного трекинга. Функция выглядит следующим образом: в режиме просмотра видео оператор кликает на изображение объекта, которого он хочет отследить, система ищет людей с теми же либо сходными приметами одежды на близких камерах в близкие моменты времени и выводит оператору эту объекты, отсортировав их по степени соответствия. Оператору необходимо вручную подтвердить, какие из этих выведенных объектов являются его искомым. Подтверждение необходимо потому, что в одинаковой одежде могут ходить разные люди. 
В итоге оператор получает ролик, состоящий из видеофрагментов с разных камер, и понимает, как человек перемещался по объекту. А также если камеры были привязаны к плану, траекторию перемещения на этом плане. Это то, к чему мы пришли в рамках своей работы по выявлению и воплощению реально полезного и применимого решения задач пользователей.

Справедливости ради отметим: наши исследования показывают, что есть еще две функции, которые в гораздо меньшей степени, но все-таки отвечают требованиям полезности, применимости на большом количестве камер и функциональности нового уровня. Это модули подсчета посетителей и распознавания автономеров.

Как разрабатывать с учетом трех осей развития?

Мы поняли, что любые наши идеи – это не более чем гипотезы, и мы не можем просто начать без разбора их реализовывать. Мы должны отвалидировать их на реальных пользователях. Поэтому прежде чем запустить какую-то функцию в разработку, мы идем на объекты к реальным пользователям и пытаемся понять, а есть ли у них та проблема, которую мы пытаемся решить. На этапе валидации 99% наших идей отбрасываются. 
Далее мы делаем прототипы, снова идем к пользователям и предлагаем их применить. В 8 из 10 случаев оказывается, что наш прототип сделан неправильно. И когда мы наконец реализуем в виде конечного результата то, что пытались сделать в прототипе, мы снова идем на реальные объекты и тестируем силами пользователей этот конечный результат.

Только при таком подходе есть шанс, что нам удастся найти что-то такое, что будет реально полезно нашим конечным пользователям.

Артем Разумков,
генеральный директор Macroscop