Статьи рынка безопасности

События

  • Выставка Securika Moscow 16/04/2024

    Москва, МВЦ «Крокус Экспо», павильон 3

Интеграция в СКУД

  • 25.12.2014
  • 3682

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

Вместо введения

Многие хорошо помнят, что лет этак 15–20 тому назад тема интеграции уже активно обсуждалась (правда, больше в кругах специалистов), однако возможностей для реальной полномасштабной интеграции было совсем немного. Разнородное и не всегда богатое функционалом оборудование, отсутствие многих ставших сегодня привычными стандартов, особенно в части коммуникаций, отсутствие ставших сегодня привычными технологий (например, распознавание автомобильных номеров, IP-видеонаблюдение и видеоаналитика) – все это сводило возможности интеграции к взаимодействию на уровне «сухих контактов» и управлению поворотными камерами по интерфейсу RS-485. 

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

Кто главнее

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

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

С другой стороны...

Но сегодня существует и имеет полное право на существование и другая концепция – построение распределенной системы с равными возможностями и информационным обменом в соответствии со стоящими перед интегрированной системой задачами. Такой подход хорош с различных точек зрения:

  • Наличие трех серверов (по одному для каждой подсистемы) повышает надежность работы системы в целом: отказ, например, видеосервера не скажется на работе СКУД и охранно-пожарной сигнализации (ОПС).
  • В каждой из областей (видео, СКУД, ОПС) у интеграторов и конечных пользователей могут быть свои устоявшиеся предпочтения, основанные как на характеристиках подсистемы, так и на собственном опыте монтажа или эксплуатации.
  • Чем комплекснее система, тем больше в ней потенциальных «дырок» и узких мест.

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

Как интегрироваться?

После эпохи «сухих контактов» пришла эпоха SDK – специализированных комплектов разработчика, дающих доступ к внутреннему функционалу системы. Как правило, это некоторые динамические библиотеки с набором функций и их описанием, интегратор (например, разработчик СКУД) с помощью SDK мог в свою систему интегрировать функционал, например, подсистемы видеонаблюдения либо наоборот. 

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

О пользе стандартов

Описанная выше ситуация решается единственным способом: разработкой отраслевых стандартов на обмен информацией, как это, например, делается уже не одно десятилетие в системах управления производственными процессами – SCADA системах. В области безопасности такие стандарты тоже уже пытались разрабатывать, однако до полной победы еще далеко. Если в области того же видеонаблюдения некоторые стандарты появились и прижились (за счет чего, например, IP-камеры разных производителей имеют неплохую взаимную совместимость), есть несколько стандартов для обмена информацией с оборудованием ОПС, то о СКУД такого сказать нельзя. Именно многогранность СКУД как системы мешает выработать стандарт, который приняли бы большинство игроков рынка. 

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

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

Что нужно в СКУД

И немного по теме, вынесенной в заголовок статьи, а именно: что из интеграционных сервисов от других систем требуется для СКУД? На самом деле не так уж и много. Практика эксплуатации интегрированных систем показала, что, например, не надо забирать всю мощь отображения картинок с камер от интегрируемой подсистемы видеонаблюдения. Функции наблюдения за камерами закрепляют за отдельным оператором (или операторами, если система крупная), при этом контроль за СКУД в функции этих людей не входит.

А для реализации такой функции, как видеоверификация, когда при проходе человека через точку прохода требуется сравнить изображение с камеры с изображением из базы данных и сохранить вместе с событием СКУД один или несколько снимков с точки прохода, сегодня достаточно практически любой IP-камеры и готового решения для показа и сохранения картинки из любого из открытых (open source) проекта. Реализация максимально проста при высоком качестве решения. 

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

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

Поделиться:

Все права защищены
© ООО АДВ Секьюрити,
2003—2024
Яндекс.Метрика
Метрика cайта: новости: 8220 (+2) | компании: 528 | бренды: 423 | статьи: 1150

О проекте / Контакты / Политика конфиденциальности и защиты информации

Techportal.ru в соц. сетях