Mind Map для задач видеонаблюдения

Идея как то классифицировать задачи, решаемые видеонаблюдением у меня зародилась давно. Первый выпуск моего подкаста был посвящен как раз этой теме ещё в 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 для задач видеонаблюдения
Классификация задач видеонаблюдения

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

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

Выводы

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

2 коментария к публикации “Какие задачи может решить видеонаблюдение?

  1. По п.1 есть комментарий или скорее наблюдение, почему не обсуждаются задачи видеонаблюдения до выбора технического решения.
    У боле-менее крупного заказчика обычно существуют некие бизнес-процедуры, в которых формированием ТЗ занимаются его специалисты. Или не специалисты. Или специалисты, но в других областях.
    И СБ тщательно следит чтобы до опубликования ТЗ никто из потенциальных подрядчиков не пронюхал о готовящейся работе, ведь это даст ему преимущество.
    В результате заказчик выдает ТЗ в котором собственно задачи и не описаны, а написано «взять столько вот таких видеокамер и поставить туда, туда и вот сюда»
    И от подрядчика требуется только сделать это как можно дешевле…

    1. Я как то разговаривал на эту тему с известным по своей книге «Библия видеонаблюдения» Владо Дамьяновски. Мне было интересно, как устроен рынок «у них». И ключевая разница, которую я обнаружил в ходе беседы — это наличие независимых экспертов, объединенных в местный аналог нашего СРО, только если у нас СРО — это зачастую формальность, то у них — это серьезная организация, за членство в которой люди «трясутся». Смысл этого консультанта — провести заказчика «за ручку» от этапа когда он для себя решил — система нужна, до сдачи системы в эксплуатацию. Т.е. консультант помогает сформировать те самые эксплуатационные требования, он же выполняет все необходимые проектные расчеты и формирует документацию. Он может участвовать в процедуре оценки тендерных предложений интеграторов / монтажников. Он же контролирует ход монтажа и наладки на соответствие проектным решениям. Он же участвует в приемке системы в эксплуатацию.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован.