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

События

  • выставка 24/10/2018

    HI-TECH Building 2018г. Москва

  • выставка 21/11/2018

    All-over-IP 2018г. Москва

  • Конференция 06/11/2018

    LED Forumг. Москва

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

  • 27.01.2015
  • 2991
  • Время чтения: 8 минут

3612s.gif

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

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

Прямое управление аппаратными средствами

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

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

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

Взаимодействие программных модулей

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

Взаимодействие с помощью SDK

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

Взаимодействие через API

Следующий вариант программной интеграции – реализация производителем некоего набора программных запросов (методов или точек входа), позволяющих взаимодействовать с программными и аппаратными средствами в формализованном виде, – API (API, англ. application programming interface – интерфейс программирования приложений). Фактически это набор готовых процедур (библиотек, функций), предоставляемых для использования во внешних программных продуктах, легко подключаемых и используемых с любым современным языком программирования. API – универсальное средство, при его реализации сложные аспекты взаимодействия с оборудованием и протоколы обмена, структуры данных скрыты от интегратора и упрощены разработчиком API. Обмен информацией происходит посредством вызова неких функций, что позволяет организовать динамический обмен данными между приложениями. К сожалению, практика использования подобного рода интерфейсов показывает, что они не всегда могут быть корректно использованы из-за недостаточного понимания порядка работы интегрируемых систем и аппаратных средств со стороны разработчиков ПО. Из-за этого могут возникать непредсказуемые ошибки в работе ПО.

Взаимодействие через единую базу данных

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

Все вышеописанное не ново, и организация взаимодействия программных средств обычно базируется на технологии клиент – сервер. Суть этой технологии в том, что клиент может вызвать сервер, а обратный вызов невозможен. Данная технология повсеместно используется в процессах автоматизации чего-либо (бизнес-процессов, производства и т. п.). Она развивается много лет, и здесь имеются наработанные методики, являющиеся стандартом в сфере разработки программного обеспечения для систем безопасности. В то же время производители аппаратных средств ищут новые подходы и стараются предоставить такие средства для интеграции, которые были бы понятны широкому кругу программистов и не требовали бы глубокого понимания порядка их работы. Одним из них является организация взаимодействия с помощью несложных текстовых протоколов. Например, использование таких известных текстовых форматов, предназначенных для обмена данными, как XML-RPC, SOAP и JSON. Использование данных форматов удобно для большинства программистов, занимающихся разработкой программных приложений, поэтому написание новой программы для интеграции новых аппаратных средств не требует от них больших усилий и времени. В то же время они оптимальным образом подходят для реализации новых трендов рынка – web-сервисов, а также мобильных и web-приложений.

Поддержка web-сервисов

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

SOAP – простой протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур, сейчас протокол используется для обмена произвольными сообщениями. Методы REST более просты, чем SOAP, и предназначены для построения распределенного приложения. В REST используются XML и JSON, при этом вызов удаленной процедуры представляет собой обычный HTTP-запрос, а необходимые данные передаются в качестве параметров запроса. REST и SOAP являются стандартами, на которых базируются технологии создания web-сервисов и широко используются при разработке приложений для средств автоматизации.

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

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

Поделиться:

Медиаканал агентства
Маркетинговое агентство рынка безопасности - AdvSecurity.ru
Все права защищены
© ООО АДВ Секьюрити, 2003—2018
Яндекс.Метрика
Метрика cайта: новости: 6814 | компании: 513 | бренды: 406 | статьи:  

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

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