Журнал ТЗ № 2 2014 | Интеграция в СКУД
  бюро находок  
  Где искать        
наши издания
наши анонсы






2014
№ 2
статьи



Журнал ТЗ № 2 2014



Раздел: КОНТРОЛЬ ДОСТУПА
Тема: СКУД (системы контроля и управления доступом)
Автор:

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

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

Леонид Стасенко, президент НПО «Релвест»

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

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

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


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

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


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




Внимание! Копирование материалов, размещенных на данном сайте допускается только со ссылкой на ресурс http://www.tzmagazine.ru

Рады сообщить нашим читателям, что теперь нашем сайте работает модуль обратной связи. Нам важна ваша оценка наших публикаций! Также вы можете задавать свои вопросы.Наши авторы обязательно ответят на них.
Ждем ваших оценок, вопросов и комментариев!

Комментарии:
Добавить комментарий или задать вопрос

Правила комментирования статей

Версия для печати

Средняя оценка этой статьи: 0  (голосов: 0)
Ваша оценка:

назад
|

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



Новинка от компании IDIS: 5Мп IP-видеокамера DC-T3533HRX
Тенденции развития индустрии IP-видеонаблюдения демонстрируют погоню производителей за увеличением разрешающей способности видеокамер. При этом часто оказывается так, что озвучиваемые цифры в 4, 9, 12 и даже 20 мегапикселей оказываются несопоставимыми с физическими размерами сенсоров, используемых в этих камерах. Поэтому подобные разрешения реализуются лишь на уровне соответствующих цифр в настройках камеры и не приводят к какому-либо улучшению изображения.



IBM меняет представление о передаче и хранении видео. Впервые на All-over-IP 2017!
Сравните ваш взгляд на интеллектуальное видеонаблюдение с мнением руководителей корпорации IBM на 10-м форуме All-over-IP 2017.



Реклама
Подписка на новости
Имя
E-mail
Анти-спам код
Copyright © 2008 —2017 «Технологии защиты».