С трех точек зрения

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

«ПЯТЫЙ ЭЛЕМЕНТ» АППАРАТНЫХ СИСТЕМ

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

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

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

АДМИНИСТРИРОВАНИЕ РАСПРЕДЕЛЕННЫХ СИСТЕМ

Под администрированием в данном случае следует понимать удаленное администрирование программного обеспечения — как на видеосерверах, так и на удаленных рабочих местах (УРМ).

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

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

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

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

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

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

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

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

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

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

ЕДИНЫЙ ПРОТОКОЛ СОБЫТИЙ

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

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

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

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

ЕДИНЫЙ ПОСТ НАБЛЮДЕНИЯ

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

МЕЖСЕРВЕРНАЯ АВТОМАТИКА

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

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

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

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

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

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

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

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

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

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

ВИДЕОСТЕНА

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

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

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

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

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

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

ВИДЕОАНАЛИТИКА

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

Краеугольный вопрос: можно ли разместить модуль видеоаналитики на одном видеосервере, видеоканалы брать с другого, а команды выполнять на третьем?

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

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

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

Для инсталлятора подход «каждой аналитике — свой видеосервер» также предпочтительнее: хотя бы потому, что проще и привычнее в настройке. Заказчику такой подход также должен понравиться больше, как наиболее надежно и быстро работающий.

МНОГОКАНАЛЬНЫЙ ИНТЕЛЛЕКТУАЛЬНЫЙ ПОИСК

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

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

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

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

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

РЕЗЕРВИРОВАНИЕ

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

Резервирование — способ повышения отказоустойчивости путем переноса функционала с отказавшего видеосервера на исправный. Есть два принципа резервирования: резервирование отдельных устройств (камер) и резервирование серверов в целом.

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

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

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

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

ВЫВОДЫ И РЕКОМЕНДАЦИИ

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

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

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