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






2014
№ 4
статьи



Журнал ТЗ № 4 2014



Раздел: КОНТРОЛЬ ДОСТУПА
Тема: СКУД (системы контроля и управления доступом)
Автор: Вячеслав ТЕСАКОВ, генеральный директор компании «Равелин»

Варианты протоколов для интеграции со сторонними системами в современных системах контроля доступа

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

Наиболее распространенным примером такой интеграции является организация взаимодействия между системой контроля доступа и системой видеонаблюдения. На практике интеграцию можно реализовать, например, и с помощью установки дополнительных реле либо использовать имеющиеся дополнительные входы/выходы в контроллерах и видеокамерах. Однако это дает очень ограниченные возможности. Основным способом, безусловно, является реализация программного взаимодействия между подсистемами. Производители СКУД стараются создавать различные средства, позволяющие программистам разрабатывать собственные приложения, удобные для использования конечными пользователями интегрированной системы. Но разнообразие выпускаемого оборудования очень большое, и на сегодня типовых решений по интеграции или стандартных протоколов организации подобного взаимодействия пока нет. Каждый спасается, как может. Данная статья посвящена обзору существующего положения на рынке и тем трендам, которые существуют.
Существуют два подхода для интеграции СКУД в состав системы безопасности. В первом случае реализуется алгоритм прямого управления непосредственно аппаратными средствами. Во втором организуется взаимодействие между программными средствами подсистем безопасности. Оба пути развиваются независимо, у обоих есть свои преимущества и недостатки.
Первый подход реализуется тогда, когда интегратор хочет получить наиболее широкие возможности по управлению оборудованием и получению данных. Для реализации данного подхода необходимо организовать непосредственное управление «железом» по протоколам, предоставленным производителем СКУД. Сделать это возможно в случае, если производитель передал свой протокол разработчику программных средств на основании какого-либо договора, либо производитель сам позаботился и создал контроллер с универсальным интерфейсом. С помощью этой методики любой желающий, имеющий описание протокола и структур данных, может самостоятельно разработать программное обеспечение, позволяющее решать вопросы интеграции.
Но у данного подхода есть и недостатки. Прежде всего это необходимость постоянно следить за изменениями протоколов, хорошо понимать работу аппаратных средств, следить за расширением предоставляемых возможностей и т. п. То есть такая интеграция требует постоянных трудозатрат с чьей-либо стороны – либо производителя, либо разработчика программного обеспечения (ПО). Это не очень удобно, так как отнимает дополнительное время у программистов. Практически разработка не заканчивается никогда. Наш опыт подобных интеграций показал, что для поддержания эффективности интеграции производитель должен фактически вести список сделанных изменений и постоянно оповещать о них. Таких интеграций может быть несколько десятков, и требуется оповещать всех разработчиков ПО, следить за качеством выполненных доработок, проводить тестирование и т. д.
Если же производитель создал собственный контроллер с универсальным открытым протоколом (интерфейсом), то в случае выпуска нового исполнения контроллера либо расширения функций существующего должна быть соблюдена преемственность – старая версия прибора должна работать с новым протоколом и наоборот, что исключит постоянную доработку ПО сторонними производителями.
Именно поэтому основным вариантом на сегодня является организация интегрированных решений на базе взаимодействия программных модулей. Данный вариант более универсален. Но здесь тоже нет одного решения, так как программные средства и требования клиентов постоянно растут и изменяются.
Естественным развитием первого описанного подхода к интеграции стала разработка многочисленных SDK. SDK – комплект средств разработки, используемый разработчиками программного обеспечения для управления аппаратными средствами. В состав этого комплекта входит набор полезных утилит, исходные коды и библиотеки, предназначенные для создания приложений, тестирования программ и просто ускорения процесса разработки. Использование исходных кодов налагает ограничение на выбор языка программирования – интегратор должен либо использовать тот же язык программирования, что и создатель SDK, либо создать подключаемую библиотеку (DLL), реализующую методы SDK. При таком подходе повышаются и требования к квалификации разработчика-интегратора, и ответственность создателя SDK. Требуется практически постоянно создавать обновления, что достаточно трудоемко, поэтому не все производители оборудования и разработчики выбирают такой способ интеграции.
Следующий вариант программной интеграции – реализация производителем некоего набора программных запросов (методов или точек входа), позволяющих взаимодействовать с программными и аппаратными средствами в формализованном виде, – API (API, англ. application programming interface – интерфейс программирования приложений). Фактически это набор готовых процедур (библиотек, функций), предоставляемых для использования во внешних программных продуктах, легко подключаемых и используемых с любым современным языком программирования. API – универсальное средство, при его реализации сложные аспекты взаимодействия с оборудованием и протоколы обмена, структуры данных скрыты от интегратора и упрощены разработчиком API. Обмен информацией происходит посредством вызова неких функций, что позволяет организовать динамический обмен данными между приложениями. К сожалению, практика использования подобного рода интерфейсов показывает, что они не всегда могут быть корректно использованы из-за недостаточного понимания порядка работы интегрируемых систем и аппаратных средств со стороны разработчиков ПО. Из-за этого могут возникать непредсказуемые ошибки в работе ПО.
Еще одним известным вариантом создания условий для интеграции является принцип взаимодействия через единую базу данных. В этом случае разрабатывается общая объектная модель – единый цифровой формат названий полей данных, записей таблиц и их взаимосвязей при организации базы данных интегрированной системы. Это позволяет записывать данные о работе системы в единую базу данных и выполнять их анализ. Запросы в эту базу создаются специально разработанными приложениями и разрабатываются одним разработчиком. Информация о конфигурации системы в целом и отдельных подсистем тоже хранится в централизованной базе данных. Недостатки у этого варианта аналогичны уже описанным в данной статье при рассмотрении первого подхода к интеграции.
Все вышеописанное не ново, и организация взаимодействия программных средств обычно базируется на технологии клиент – сервер. Суть этой технологии в том, что клиент может вызвать сервер, а обратный вызов невозможен. Данная технология повсеместно используется в процессах автоматизации чего-либо (бизнес-процессов, производства и т. п.). Она развивается много лет, и здесь имеются наработанные методики, являющиеся стандартом в сфере разработки программного обеспечения для систем безопасности. В то же время производители аппаратных средств ищут новые подходы и стараются предоставить такие средства для интеграции, которые были бы понятны широкому кругу программистов и не требовали бы глубокого понимания порядка их работы. Одним из них является организация взаимодействия с помощью несложных текстовых протоколов. Например, использование таких известных текстовых форматов, предназначенных для обмена данными, как XML-RPC, SOAP и JSON. Использование данных форматов удобно для большинства программистов, занимающихся разработкой программных приложений, поэтому написание новой программы для интеграции новых аппаратных средств не требует от них больших усилий и времени. В то же время они оптимальным образом подходят для реализации новых трендов рынка – web-сервисов, а также мобильных и web-приложений.
Относительно новым требованием рынка, предъявляемым к программному обеспечению для систем безопасности, в том числе и СКУД, стала поддержка web-сервисов. Эта задача заставила производителей подняться на новый уровень, позволяя обеспечивать взаимодействие со своими средствами в распределенных сетях. Использование старых подходов в этом случае затруднено из-за сложности описания путей поступления информации от сервера СКУД к клиенту. Этот процесс включает в себя несколько этапов: отправка запроса web-сервису, получение ответа, контроль формирования и получения запросов, а также многое другое. Одной из основных задач сервера в этой архитектуре является предоставление клиентам доступа к ресурсам (базе данных) по их идентификаторам. Уже существует большое количество наработанных методик и стандартов. Одним из них является стандарт SOAP, вторым – REST. Условно SOAP есть эволюция XML-формата, с натяжкой конечно. SOAP – простой протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур, сейчас протокол используется для обмена произвольными сообщениями. Методы REST более просты, чем SOAP, и предназначены для построения распределенного приложения. В REST используются XML и JSON, при этом вызов удаленной процедуры представляет собой обычный HTTP-запрос, а необходимые данные передаются в качестве параметров запроса. REST и SOAP являются стандартами, на которых базируются технологии создания web-сервисов и широко используются при разработке приложений для средств автоматизации.
Неоднородность подходов и вариантов интеграции СКУД на рынке систем безопасности можно объяснить тем, что компании предлагают продукты, в которых реализуется только часть задач интеграции, никто пока не поставляет полностью оптимального решения. Связано это с тем, что для таких систем, как СКУД, не создано универсальных протоколов. Мешает этому большое количество разнообразных обрабатываемых данных. Попытки разработки таких протоколов, например ONVIF-C (основанный на SOAP), очень скромно описывают перечень передаваемых данных, поэтому их использование пока не оправданно, необходимо развивать его дальше. Другим предлагаемым вариантом является разработка производителями специализированных контроллеров-преобразователей со стандартизированным протоколом обмена типа «запрос – ответ». Это предложение тоже находится на рассмотрении у производителей. Но надо учитывать, что, согласно прогнозам аналитиков, рынок услуг в области СКУД является очень перспективным и растущим сегментом рынка систем безопасности. Потребность в интеграционных решениях постоянно растет. По независимым оценкам, ожидается устойчивый рост поступлений от реализации данного вида программного обеспечения. Все это требует совместных усилий от производителей СКУД с целью создания универсальных методик, позволяющих широкому кругу программистов использовать выпускаемые аппаратные средства.


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

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

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

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

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

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