Какие задачи может решить видеонаблюдение?

Идея как то классифицировать задачи, решаемые видеонаблюдением у меня зародилась давно. Первый выпуск моего подкаста был посвящен как раз этой теме ещё в 2016 году. С тех пор прошло много времени — но проблема с формулированием цели, ради которой устанавливается система видеонаблюдения — по-прежнему актуальна. По непонятной причине людям гораздо интереснее погружаться в технические детали характеристик оборудования, но не в эксплуатационные требования к системе. Что в итоге приводит к неэффективному применению оборудования, решениям «для галочки».

Ещё в сентябре в своем канале Telegram Проектирование видеонаблюдения я начал набрасывать основу этой статьи. Потом были долгие обсуждения с моим приятелем — Валентином Поповым (канал Дядя Валя), в результате которого у него на канале вышел отличный ролик по этой теме (обязательно посмотрите):

Но разумеется формат ролика не позволяет обсудить всё. А вот статья — вполне. Так что усаживайтесь поудобнее — сегодня поговорим о том, как же правильно формулировать что вам нужно от видеонаблюдения. На что видеонаблюдение способно, а на что — нет. И главное — как не переплачивать за то, что вам не нужно, но при этом не сэкономить на столько, что система перестанет решать ваши задачи и станет той самой распространённой системой «для галочки».

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

Зачастую ведь на практике этого не происходит! Приходит заказчик — говорит мне нужно видеонаблюдение, камер поставьте 50, вот таких. Глубина архива — 30 суток. И чтоб мертвых зон не было! И выводите все камеры на видеостену — чтобы весь объект как на ладони!

Пару охранников — достаточно. Там правда ещё смены придется формировать — охрана нужна круглосуточная. Ещё и обслуживать кому то надо систему — мои балбесы не справятся)

Вот и все ТЗ. Что мы узнали из него о задаче заказчика? Ничего! Но можем ли мы по этому «заданию» сформировать ТКП? Конечно! Вообще нет проблем! И большинство коллег именно так и поступают — и по-своему правы. Они же не обманывают клиента, делают ровно то, что он от них требует.

В итоге мы получаем «театр безопасности» во всей своей неприглядной «красе».

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

А вот реальные проблемы той же транспортной безопасности — даже не пытаются решить! Сколько людей гибнет из-за несчастных случаев на переездах/пешеходных переходах? Сколько молодых людей «зацеперов» становятся инвалидами? Никто эти вопросы не обсуждает — это не интересно и не даёт того же эффекта, что «терроризм» — поэтому такую галочку закрывать не интересно — слишком много рутинной работы, слишком много нюансов — нельзя решить «взмахом волшебной палочки» — типа вот поставим мы везде интроскопы и рамки металлоискателей — и это спасет от теракта)

Обсуждение с заказчиком задач наблюдения — это защита от «театра безопасности«. Вот для этого мы эту тему и поднимаем.

Функции заказчика / функции подрядчика

Работая с партнёрами, курсантами Такир и студентами — я долго не мог понять, почему так сложно даётся задача составления задания на проектирование в целом, и формулировка задач наблюдения в частности. И вот недавно понял.

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

Основные технические решения (ОТР)

☑️ отвечают на вопрос «как«

☑️ опираются на расчеты

☑️ учитывают требования норм

☑️ ориентированы на монтаж / пусконаладку

☑️ оформляются в виде проектной / рабочей документации (в редких случаях — эскизного проекта и др.)

Эксплуатационные требования

☑️ отвечают на вопрос «зачем«

☑️ содержат критерии решения целевых задач наблюдения

☑️ опираются на планы дальнейшей эксплуатации, обслуживания, расширения, масштабирования и модернизации системы

☑️ ориентированы на эксплуатацию (в том числе процедуру приемки системы)

☑️ оформляются в виде концепции безопасности и задания на проектирование (пояснение ниже)

Эксплуатационные требования можно разделить на 2 уровня:

1 уровень раскрывает задачу заказчика и обосновывает применение конкретной системы (видеонаблюдения например) в сравнении с альтернативными вариантами (например охранной сигнализацией). Мало кто ставит простые вопросы перед внедрением:

✅ на сколько большая вероятность события?

✅ каковы его последствия?

✅ что и как будем делать при его наступлении?

✅ точно ли мне поможет видеонаблюдение?

✅ может есть другие пути — более дешевые и действенные (например — дополнительное освещение, сигнализация, инженерное заграждение).

2 уровень раскрывает требования к эксплуатации системы, аспектам ее менеджмента, обслуживания, модернизации и т.д. Эксплуатационные требования 2 уровня — помогают выявить все возможные нюансы применения видеонаблюдения для задач, отобранных на уровне 1. Мы должны задать себе ряд вопросов:

✅ целевые задачи наблюдения и критерии их решения

✅ кто, когда, откуда наблюдает и что с этой информацией делает?

✅ требования к записи и живому отображению

✅ обслуживание, ремонт, модернизация и масштабирование

В условиях России очень условно можно соотнести эксплуатационные требования первого рода с Концепцией безопасности, а второго рода — с заданием на проектирование.

Почему задача «смотреть ВСЕ без мертвых зон» — не та задача, которую нужно решать системой видеонаблюдения

Правильная постановка задачи — ключевой момент при планировании любой системы. Я за свою карьеру видел и составлял сам огромное число «ТЗ» и заданий на проектирование видеонаблюдения — и могу сказать следующее. Почти все эти бумажки совершенно никуда не годятся. Потому что или не формулируют задачу заказчика вообще, или формулируют ее очевидно не верно.

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

Наиболее часто на вопрос «что хотите видеть?» клиент отвечает что то типа «не знаю, давайте ВСЕ без мертвых зон, а там разберемся». Для «перекрытия» объектов «без мертвых зон» используют камеры с широкоугольными объективами, которые предназначены для решения задач обнаружения и обзора. Но которые не подходят для сбора более детальной информации — распознавания автомобильных номеров (ГРЗ), лиц, номеров вагонов, купюр и т.п.

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

Какие же задачи нужно ставить системе видеонаблюдения?

Общаясь с клиентами я выясняю всегда два важных аспекта:

☑️ из какого сегмента заказчик (DIY, ритейл, B2B, B2C, производство, логистика и т.п.)

☑️ тип объекта заказчика (офисное здание, линейный объект, сеть мелких объектов, периметр, складское здание и т.п.)

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

1️⃣ ведение базы данных идентифицированных по некоторому признаку объектов или событий

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

• ведение «белых» и/или «черных» списков идентификационных признаков объектов (лиц, гос. регистрационных знаков авто — ГРЗ, других номеров)

Пример «черного» списка — база покупателей магазина, в отношении которых ведется расследование на предмет причастности к кражам.

Пример «белого» списка — VIP-покупатели, о которых необходимо автоматически сообщать персоналу при появлении в магазине.

Данная задача решается с применением технологий распознавания или вручную, но в любом случае — решение о «зачислении» идентификационного признака в тот или иной список принимает сам заказчик по результату анализа записей.

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

Пример сбора такого рода событий — фиксация нарушений ПДД, когда в БД фиксируется время события, место, распознанный номер и суть нарушения.

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

2️⃣ расследование инцидентов

Это понятная и востребованная задача. Иногда нам не требуется ведение базы данных — мы и так знаем всех «героев» в лицо, но нужны записи для «разбора полетов«. Это актуально для многих кейсов как самостоятельная задача, так и как одна из задач наблюдения.

• инциденты на производстве / складах
• соблюдение регламентов
• соблюдение техники безопасности
• сбор доказательной базы
• сбор данных о факте события (время, детали и т.п.)
• разбор действий охраны при ЧП

3️⃣ верификация событий

Задача, как правило, применяется для ситуационного наблюдения, но может быть полезна и в записи. Суть — подтвердить визуально или алгоритмически проанализировать поток с камеры, который должен подтвердить или опровергнуть данные от другой, сторонней системы (от СКУД, СОТС, АУПС, СОУЭ, диспетчеризации, автоматики, POS системы, SCADA системы и т.п.).

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

4️⃣ «машинное зрение»

Речь о применении алгоритмов, позволяющих с заранее известной вероятностью выделять событие из видеопотока без участия оператора наблюдения. Данные события используются для передачи в сторонние системы — систему контроля и управления доступом (СКУД), систему охранной и тревожной сигнализации (СОТС), автоматическую систему пожарной сигнализации (АУПС), систему оповещения и управления эвакуацией (СОУЭ), диспетчеризации, автоматики, POS системы, SCADA системы и т.п. — для запуска реакций и сценариев, либо для дальнейшего анализа. Примеры:

• пропуск авто из «белого списка» при распознавании ГРЗ на территорию предприятия
• распознавание лица — как идектификационного признака посетителя в системе контроля и управления доступом (СКУД)
• учет и индикация заполненности закрытой автостоянки
• логирование подсчета посетителей в магазине для анализа эффективности маркетинговых акций в ТРЦ
• логирование и сигнализация о превышении допустимой длины очереди в кассу в магазине
• автоматическое слежение поворотной PTZ-камерой за целями в пределах определенной зоны и по заранее заданному алгоритму переключения между целями
• логирование и сигнализация о нарушении сотрудниками регламента применения средств индивидуальной защиты (СИЗ)
• подсчет товара на конвейере
• определение и подсчет нестандартных целей наблюдения (например — подсчет числа свиней перед взвешиванием на свиноферме)

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

Матрица задач видеонаблюдения

Есть два ключевых признака, по которым задачи видеонаблюдения можно отчасти разделить:

☑️ нужен ли для решения задачи оператор или администратор? Или задача решается полностью автономно — например используя алгоритмы видеоаналитики?

☑️ нужно ли для решения задачи обмениваться данными / командами с другими системами? Или достаточно исключительно системы видеонаблюдения?

Некоторые задачи все равно не хотят умещаться в получившиеся 4 «квадратика» — но это тема другая. Тут важно именно то, что классификация закрывает 90% всех задач и с ней удобно раскладывать по полочкам проблемы заказчика. А главное — данная классификация позволяет наглядно увидеть отличие в решениях одной и той же задачи — в зависимости от бюджета заказчика и технических компетенций исполнителя.

В итоге я создал Mind Map — Задачи видеонаблюдения — чтобы можно было удобно добавлять новые задачи видеонаблюдения к данной классификации. Пока он выглядит вот так:

Автономность системы / интеграция с другими системами, также как и применение видеоаналитики или решения задачи силами оператора — это зачастую баланс между ценой и вероятностью решения задачи. Интегрированные системы с применением видеоаналитики — это почти всегда использование платного софта и дорогостоящих видеосерверов. Автономные системы с использованием ручного труда оператора (без значимой автоматизации) — могут быть альтернативой дорогим системам. Но нужно учитывать, что чем крупнее система, чем ответственнее защищаемый объект и выше цена ошибки — тем меньше стоит смотреть на цену решения и больше — на вероятность решения поставленной задачи. Также при оценке — не стоит забывать, что большие затраты «на старте» могут привести к значительной экономии денег при эксплуатации. Ведь ручной непроизводительный труд — это очень дорого в перспективе всего срока службы системы.

Обязательно пишите в комментариях — какие задачи и как вы пытались решить с помощью системы видеонаблюдения и какие результаты в итоге получили. Я в свою очередь обязуюсь добавлять в публичный Mind Map все интересные кейсы — для общего доступа к такой своеобразной «базе знаний».

Выводы

1. Задачи видеонаблюдения необходимо обсуждать ДО выбора технического решения — это позволит избежать ситуации «театра безопасности»
2. Задачи наблюдения и критерии их решения — это ключевые исходные данные для подбора основных технических решений будущей системы
3. Задачи наблюдения — это эксплуатационные требования заказчика, они в идеале должны прописываться в «концепции безопасности» объекта в роли эксплуатационных требований 1-го уровня (согласно Руководства по составлению эксплуатационных требований к системам видеонаблюдения. Версия 5.0 авторства подразделения научных разработок МВД Великобритании)
4. Критерии решения целевых задач наблюдения — прописываются в задании на проектирование — в роли эксплуатационных требований 2-го уровня
5. Одна и та же задача может быть решена как бюджетным способом — без интеграции с другими инженерными системами объекта, без автоматизации с применением видеоаналитики, так и более дорогим, но и более эффективным. Чем крупнее и ответственнее система — тем меньше смысла экономить. Но даже для менее отвественных задач при выборе «квадрата» в приведенной выше «матрице задач» — стоит считать не только затраты на создание, но и общие затраты на весь жизненный цикл — включая эксплуатацию и дальнейшую модернизацию или расширение системы.

---

---