Автор: Стасенко Л. А., президент компании
Тема интеграции подсистем технических средств безопасности ой — как не нова, однако с течением времени меняются подходы и понимания в области интеграционных решений, появляются и закрепляются в жизни новые технологии и решения, поэтому тема эта, как нам представляется, всегда сохраняет актуальность.
Многие хорошо помнят, что лет этак 15...20 тому назад тема интеграции уже активно обсуждалась (правда, больше в кругах специалистов), однако возможностей для реальной полномасштабной интеграции было совсем немного. Разнородное и не всегда богатое функционалом оборудование, отсутствие многих ставших сегодня привычными стандартов, особенно в части коммуникаций, отсутствие ставших сегодня привычными технологий (например, распознавание автомобильных номеров, IP-видеонаблюдение и видеоаналитика) — все это сводило возможности интеграции к взаимодействию на уровне «сухих контактов» и управлению поворотными камерами по интерфейсу RS-485.
Сегодня возможности для интеграции выросли многократно, позволяя создавать реально комплексные решения, затрагивающие не только сферу безопасности, но и системы жизнеобеспечения зданий и управления бизнес — процессами.
Сколько лет идут разговоры и работы по интеграции, столько же лет не могут прийти к однозначному решению: кто, какая подсистема должна стоять во главе, то есть быть ядром интегрированной системы. Разработчики видеосистем «тянут одеяло» на себя, занимающиеся охранными системами пытаются тоже что-то делать, и так каждый.
Наше мнение уже на протяжении многих лет однозначно: если это только система безопасности, то больше всего шансов стать основой интегрированной системы у систем контроля и управления доступом (СКУД). Не только и не столько потому, что этот кусок пирога нам ближе всего, сколько в силу большего «интеллекта» СКУД по сравнению с видеонаблюдением и охранно — пожарной сигнализацией. Естественно, при сравнении «интеллектов» подсистем мы не имеем в виду ту же видеоаналитику — речь о внутренней «мощности» подсистемы с точки зрения коммуникационных возможностей, баз данных, набора уже имеющихся функций и так далее.
Но сегодня существует и имеет полное право на существование и другая концепция — построение распределенной системы с равными возможностями и информационным обменом в соответствии со стоящими перед интегрированной системой задачами. Такой подход хорош с различных точек зрения:
После эпохи «сухих контактов» пришла эпоха SDK — специализированных комплектов разработчика, дающих доступ к внутреннему функционалу системы. Как правило, это некоторые динамические библиотеки с набором функций и их описанием, интегратор (например, разработчик СКУД) с помощью SDK мог в свою систему интегрировать функционал, например, подсистемы видеонаблюдения, либо наоборот.
Все было бы хорошо, если бы не одно «но», которое уже много лет портит жизнь разработчикам: при выпуске очередной версии своей системы разработчики забывают (или не успевают) привести SDK в соответствие со своей новой версией, и пользователь интегрированной системы не получает возможности обновить свою систему целиком, а должен довольствоваться устаревшей версией смежника, которая еще иногда и перестает поддерживаться. Кто из разработчиков не сталкивался в жизни с подобной ситуацией?
Описанная выше ситуация решается единственным способом: разработкой отраслевых стандартов на обмен информацией, как это, например, делается уже не одно десятилетие в системах управления производственными процессами — SCADA системах. В области безопасности такие стандарты тоже уже пытались разрабатывать, однако до полной победы еще далеко. Если в области того же видеонаблюдения некоторые стандарты появились и прижились (за счет чего, например, IP – камеры разных производителей имеют неплохую взаимную совместимость), есть несколько стандартов для обмена информацией с оборудованием ОПС, то о СКУД такого сказать нельзя. Именно многогранность СКУД как системы мешает выработать стандарт, который приняли бы большинство игроков рынка.
Будем надеяться, что данная ситуация все — таки изменится. По крайней мере, для не самого быстрого обмена информацией (а кроме видеопотоков с камер в системе безопасности остальные потоки для современных сетей проблем не представляют), можно за основу стандартизации взять протокол XML, который на сегодня хорошо отработан, достаточно распространен в компьютерных системах, и при этом позволяет передавать данные с любой структурой. Еще один протокол сетевого взаимодействия, который может претендовать на основу для интеграции — это SOAP, используемый некоторыми разработчиками систем безопасности.
В любом случае, если этот текст читает кто — то из разработчиков — большая просьба: при введении нового функционала и выпуске обновленного SDK сохраняйте старые функции нетронутыми. Например, если в новой функции вместо трех используются четыре параметра, то для совместимости оставьте и струю функцию с тремя. Современный компьютер при его ресурсах это спокойно «переварит».
И немного по теме, вынесенной в заголовок статьи, а именно: что из интеграционных сервисов от других систем требуется для СКУД? На самом деле, не так уж и много. Практика эксплуатации интегрированных систем показала, что, например, не надо забирать всю мощь отображения картинок с камер от интегрируемой подсистемы видеонаблюдения. Функции наблюдения за камерами закрепляют за отдельным оператором (или операторами, если система крупная), при этом контроль за СКУД в функции этих людей не входит.
А для реализации такой функции, как видеоверификация, когда при проходе человека через точку прохода требуется сравнить изображение с камеры с изображением из базы данных и сохранить вместе с событием СКУД один или несколько снимков с точки прохода сегодня достаточно практически любой IP — камеры и готового решения для показа и сохранения картинки из любого из открытых (open source) проекта. Реализация максимально проста при высоком качестве решения.
Если продолжить аналогичные доводы и далее, то мы придем к выводу, что для реализации реально востребованного функционала интегрированной системы достаточно довольно простого обмена данными между подсистемами. Для СКУД это, в первую очередь, тревоги от подсистемы ОПС для отображения на комплексном графическом плане, информация с системы распознавания автомобильных номеров для транспортных проходных, несколько картинок с IP — камер (для той же видеоверификации).
В свою очередь, СКУД для других подсистем, включая не только безопасность, но и комплексы управления бизнес — процессами, должна предоставлять возможность работы с персоналом (добавление — удаление — редактирование) и возможность получения событий из СКУД в реальном времени (например, для работы ОПС или видеонаблюдения).
