Распределенные системы видеонаблюдения

Статья подготовлена совместно с информационно аналитическим журналом RUБЕЖ.

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

Тему построения распределённых систем мы уже затрагивали в вебинаре «Проектирование крупной системы видеонаблюдения», в статье "Особенности проектирования крупной системы видеонаблюдения" и, как говорится, «по многочисленным просьбам трудящихся»...

Что такое распределённая система?

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

• суммарный видеопоток со всех видеокамер больше, чем может обработать современная одно-, двух-, четырёхпроцессорная платформа;

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

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

• объекты географически распределены и сетевая инфраструктура не позволяет свести весь трафик на один сервер. Например, когда существует сеть объектов в рамках города, или даже страны. Либо, когда по соображениям надёжности и отказоустойчивости на каждом объекте необходимо установить свой сервер;

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

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

В качестве примеров мы возьмём наиболее известные марки ПО: Интеллект, Axxon Next, Macroscop и Milestone xProtect. Специально выделять какой-то конкретный вариант исполнения ПО (например, Professional+ или Corporate у того же Milestone) не видим смысла, т.к. технически все эти варианты не отличаются друг от друга (о чём говорит тот факт, что для установки используются одни и те же дистрибутивы). Поэтому при упоминании ПО, будем считать, что речь идёт о том варианте исполнения, который сам производитель рекомендует именно для территориально-распределённых систем.

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

1. Администрирование
2. Единый протокол событий
3. Единый пост наблюдения
4. Межсерверная автоматика
5. Видеостена
6. Видеоаналитика
7. Интеллектуальный поиск
8. Резервирование

Итак, по порядку.

1. Администрирование

Поясним, что под администрированием понимаем удалённое администрирование программного обеспечения — как на видеосерверах, так и на УРМ. Кому-то может показаться, что речь сейчас о наименее интересном аспекте. Разумеется, что установленное на видеосерверах ПО надо как-то администрировать – и понятно, что это точно реализовано у всех. Что тут может быть особенного?

Для проектировщика, пожалуй, ничего особенного быть не может. Ему чаще всего вообще нет повода задумываться об администрировании. В крайнем случае – если по заданию требуется предусмотреть выделенное рабочее место администратора системы — в проект закладываются дополнительные компьютер/ИБП/монитор/линия связи и, при необходимости, дополнительная лицензия на устанавливаемое ПО. И больше действительно ничего.

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

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

• администрирование удалённых рабочих мест.

Здесь два важных аспекта. Первый - настройка пользовательского интерфейса. Пользовательский интерфейс, расположение окон, состав камер в окнах, определяется либо администратором с консоли управления системой, либо пользователем на локальном рабочем месте. Если настройка пользовательского интерфейса осуществляется централизованно администратором, то есть определенные неудобства в случае необходимости оперативной перенастройки на конкретном РМ оператора - нужно звать администратора. Но зато есть возможность удаленно добавить или удалить камеру и в режиме реального времени применить изменения. Если в программном продукте предусмотрена только локальная настройка рабочего места, то для перенастройки придётся идти на пост охраны, чтобы что-то поменять.

Второй важный аспект - работа с раскладками камер на мониторе. Имеется в виду фактическое расположение камер на экране монитора. Реализаций может быть несколько. Это либо создание для каждого УРМ собственной, зафиксированной на нём раскладки, либо создание неких общих наборов раскладок (иногда говорят «шаблонов»), которые затем могут использоваться на любом УРМ. Часто привязка раскладки осуществляется к конкретному пользователю. Во всех случаях это может выполняться: удалённо, с видеосервера или рабочего места администратора системы.

Варианты реализации в разном ПО мы будем приводить в таблицах в конце каждого раздела.

• администрирование отключённого или недоступного по сети станционного оборудования.

Да, как ни удивительно, существует ПО, в котором можно настраивать не подключённое оборудование. Даже не просто временно отключённое, но даже ещё не привезённое и не изготовленное производителем. Это возможно благодаря использованию в таких ПО общей, единой базы данных, в которой хранятся сведения сразу о всех без исключения компонентах, настройках и даже событиях всей системы. Работая с таким ПО, инсталлятор может в офисе на любом компьютере создать требуемую конфигурацию, сохранить на «флешку» и затем «развернуть» на объекте.

Если же смотреть глазами заказчиков, то выбор должен определяться спецификой наблюдаемого объекта. Нередко постоянное изменение параметров системы – неизбежное следствие динамики жизни охраняемого объекта (перестройка помещений, изменение структуры организации могут порождать изменения требований и задач наблюдения) — и возможность администрирования отключенных устройств окажется весьма полезной; её следует расценивать как необходимость и заносить в техническое задание. А если кроме серверов территориально распределены и УРМ — то стоит добавить и требование удаленного администрирования УРМ.

Подытожим этот раздел таблицей:

¹ возможность создания и настройки шаблонов, привязанных к конкретному УРМ.

² создание и настройка раскладок камер, доступных с любого УРМ системы.

2. Единый протокол событий

Рассказывать подробно что такое протокол событий и почему он должен быть единым, пожалуй, не стоит. Сразу на ум приходит некий список событий, происходивших в системе видеонаблюдения (срабатываний детекторов, создания записей и т.п.), и что все эти события удобно просматривать в одном окне, сразу со всех серверов. Вот только такое представление не совсем верно, потому что термин «единый» означает не только лишь одно окно вывода.

Как таковой единый протокол существует не у всех производителей. Нередко ПО каждого видеосервера хранит локально свой собственный протокол; операторы же системы при просмотре всех событий, получают в одном интерфейсном окне данные с разных серверов. Существует и другой подход – когда все события со всех серверов хранятся вместе, в одной базе. Разница между подходами становится заметна тогда, когда один или несколько серверов системы отключаются — и если протокол не хранится в общей единой базе, то доступ к событиям отключенных серверов становится невозможным. Здесь уместно вспомнить предыдущий раздел, в котором говорилось о преимуществах единой базы в плане администрирования.

За наличие самой возможности вывести все события в «одном окне» проектировщик должен быть спокоен: такая возможность есть у всех производителей ПО. Однако если в ТЗ присутствуют хоть какие-то определённые требования к надёжности хранения протокола событий или предусмотрена определённая регулярная работа персонала с протоколом, есть смысл выбирать ПО с возможностью хранения общего протокола либо сразу на всех серверах системы, либо даже на каком-то одном выделенном сервере.

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

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

3. Единый пост наблюдения

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

4. Межсерверная автоматика

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

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

• никакой межсерверной автоматики нет.

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

• скрытая межсерверная автоматика.

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

• межсерверная автоматика есть.

В этом случае «межсерверные» сценарии работы ПО мало отличаются от «односерверного исполнения» — просто при настройке алгоритма работы вместо камеры A с локального сервера выбирается камера B с удалённого.

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

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

Заказчику, думаем, всегда стоит исходить из того, что межсерверная автоматика точно потребуется и в полном объёме, даже если изначально не предусмотрено какой-то видеоаналитики, интеграции и прочего. Набор видеосерверов, работающих по принципу «сам по себе» никогда не будет по настоящему единой и цельной системой видеонаблюдения.

* реализуется через http-запросы между серверами (вариант скрытой межсерверной автоматики)

5. Видеостена

Понятие видеостены очень часто путают с простой мультимониторностью. Однако функция видеостены состоит не только в выводе разных камер на разные физические экраны. Главная особенность (вытекающая из назначения) – возможность удалённо менять выводимые операторам «раскладки» камер с удаленного рабочего места. Не с рабочего места, к которому подключена видеостена, а именно с удаленного! Способ реализации видеостены —аппаратный (через специализированные контроллеры) или программный (через соответствующие модули ПО) — в принципе не важен, т.к. принцип применения остаётся один и тот же. Для управления видеостеной всегда используется специальный модуль и интерфейс. Часто этот функционал платный и доступен в топовых продуктах линеек-производителей ПО видеонаблюдения.

Задача проектировщика здесь довольно сложная. Во-первых, он должен суметь «детектировать» необходимость в видеостене, и это непросто, т.к. явного указания может и не быть. Во-вторых, вариантов построения видеостены может быть несколько: либо один компьютер с десятком мониторов, либо десяток компьютеров по одному экрану на каждый, либо промежуточные варианты (зависит от многих факторов). И это сложнее, чем заложить несколько одинаковых типовых УРМ.

С точки зрения инсталлятора, лучше вообще обойтись без видеостены. Объяснение простое: пользоваться видеостеной (да и вообще системой) инсталлятор после сдачи объекта не будет, присутствие данной функции для него это всего лишь один из этапов настройки системы; грубо говоря — лишняя работа, пусть и не очень тяжёлая.

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

И снова давайте посмотрим, что и как предлагают производители ПО:

* Существует возможность удаленного управления интерфейсами одного АРМ с другого, но это требует знания программирования в ПО Интеллект, что далеко не тривиально, и не позволяет быстро и просто изменить алгоритмы.

6. Видеоаналитика

Уточним, что имеем в виду аналитику, работающую в режиме реального времени. Например, распознавание лиц или номеров. Согласно теме статьи, нас интересует работа в распределённом варианте. Проще говоря: можно ли разместить модуль видеоаналитики на одном видеосервере, видеоканалы брать с другого, а команды выполнять на третьем?

Пример распределения аналитических функций ПО видеонаблюдения.

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

С этой точки зрения, проектировщик не должен специально стремиться использовать распределённую видеоаналитику. Лучше подобрать количество и конфигурацию системы так, чтобы аналитические задачи решались каждая на своём сервере. Если это всё-таки невозможно, то однозначным выбором должно стать ПО с полноценной межсерверной автоматикой, т.к. прикладные задачи аналитики строятся именно на её основе.

Для инсталлятора подход «каждой аналитике – свой видеосервер» также предпочтительнее. Ну хотя бы потому, что проще и привычнее в настройке.

И заказчику этот подход должен понравиться больше, как наиболее надёжно и быстро работающий.

* ограниченно; реализуется через http-запросы между серверами.

7. Интеллектуальный поиск

Теперь поговорим о функциях интеллектуального поиска в архиве. То есть возможность искать видеозаписи по каким-либо критериям сразу по всем камерам.

Следует понимать, что поиск по некоторым критериям вообще возможен только для одной камеры. Например, невозможно реализовать многокамерный поиск по пересечению линии — ведь у каждой камеры своя наблюдаемая зона, со своими объектами и геометрией. Поэтому речь пойдёт о поиске по некоторым универсальным критериям, которые в принципе можно использовать для поиска сразу на нескольких камерах. Сюда относятся:

• номера транспортных средств;

• цвет объекта;

• лица (если используется распознавание лиц);

• размеры объекта (точнее – размер участка, в котором было обнаружено движение);

• текстовые атрибуты, (при использовании какой-либо бизнес аналитики).

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

Задача инсталлятора несколько проще: ему не нужно заниматься изысканиями, достаточно следовать инструкции и советам техподдержки производителя.

Заказчику же многоканальный интеллектуальный поиск может не понравиться, разве что высокой ценой. Но в распределённой системе полезность поиска может с лихвой окупить вложения, т.к. в разы сокращает время и усилия по разбору какого-либо инцидента.

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

*сомнительная возможность искать по размеру объекты на камерах с разными углами обзора и местами установки

8. Резервирование

Вопрос резервирования можно считать разновидностью вопроса межсерверной автоматики. Но это не совсем верно, т.к. существующие механизмы резервирования не связаны напрямую с возможностью взаимодействия серверов друг с другом.

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

С точки зрения проектировщика, принцип выбора между этими способами очевиден. Если нужно зарезервировать лишь часть видеоканалов, то ПО с резервированием устройств выглядит предпочтительнее. Главное — заложить видеосерверы с запасом производительности, который потребуется при «взятии на себя» камер отключённого видеосервера. Ну и, разумеется, не забыть про лицензии на соответствующие программные модули. А вот если резервировать нужно все видеоканалы системы, то очевиден выбор ПО с резервированием видеосервера целиком. Опять же не забываем про соответствующие лицензии.

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

А вот выбор заказчика будет нелёгок. С одной стороны, понятная и логичная схема: вот серверы, вот УРМ, а вот специальный «ящик», который в случае чего-либо подменит собой любой отключённый видеосервер; у каждого оборудования своя цена и чёткое назначение. С другой стороны, вариант с резервированием устройств кажется более выгодным: нет лишнего «ящика», все видеосерверы при деле, нет переплаты за большей частью простаивающее оборудование. Что же всё-таки предпочесть? С нашей точки зрения, оба варианта хороши, но есть нюансы — и в этом случае стоит следовать рекомендациям профессионалов: проектировщиков или производителей ПО. Разумеется, с учётом требований ТЗ.

* по факту используется модуль резервирования серверов, с возможностью выбора конкретных устройств.

Подробно о резервировании серверов в различном ПО видеонаблюдения в нашем видео:

Заключение

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

1. Распространённое мнение, что «Разные ПО устроены одинаково» оказывается неверным — разница в устройстве, в идеологии и принципиальных возможностях между ПО разных производителей есть и весьма существенная. 
2. Особенности того или иного ПО очевидны не всегда и не всем. Нельзя получить полное представление о «софте» только лишь из рекламных проспектов или документации. 
3. Точки зрения инсталлятора, заказчика и проектировщика совпадают отнюдь не всегда (как, впрочем, и по многим другим вопросам). 
4. В общем случае ПО с единой базой данных предпочтительнее других, в т.ч. в удобстве управления и использования. 

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

Инсталлятору рекомендовать что-то сложно, т.к. что проектировщик с заказчиком определит, то и придётся настраивать на объекте. Если опыта работы с выбранным продуктом нет, то полезным будет заранее познакомиться с ПО видеонаблюдения, попробовать реализовать и отработать ключевые функции системы на стенде. 

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