Если попробовать выделить типовые задачи интеграции СКУД с другими подсистемами безопасности, то выделяются следующие классы задач:
Обычно всё сводится к тому, что надо загрузить субъекты доступа в СКУД из внешней системы, например, кадровой программы, или же произвести обратную синхронизацию (при создании человека в СКУД, загрузить его в Active Directory). Возможно, также требуется разрешить/запретить доступ в СКУД для определенных лиц, например, при увольнении сотрудника в кадровой программе ему автоматически запрещается доступ в СКУД.
Данные задачи успешно решаются с помощью получения доступа к БД системы или же с помощью специальных программных компонентов, например web-сервисов, которые создают программную прослойку (SDK) для работы с объектами СКУД. Второй вариант предпочтительнее, так как разработчик не привязан к структуре базы, которая может быть изменена производителем и имеет больше возможностей для интеграции (не все параметры можно изменить через БД).
SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ.
Здесь самые частые задачи — интеграция с системой распознавания номеров, возможность просмотра живого видео и архива в рамках пользовательского интерфейса СКУД и возможность привязки к событиям СКУД записей из архива системы видеонаблюдения.
Системы видеонаблюдения обычно предоставляют ActiveX-компоненты для просмотра видео в сторонних приложениях и доступа к видеоархиву. Для других функций разработчики систем видеонаблюдения также предоставляют сторонним разработчикам SDK.
В этом случае необходимо в реальном времени получать статусы оборудования (например, для СКУД это будет статус реле контроллера или статус входа датчика проворота турникета и т.д.) и/или события, формируемые оборудованием. Также частый запрос от интеграторов — это возможность управления оборудованием сторонней системы. Например, нужно проверить текущее состояние охранной области или текущий режим работы контроллера СКУД, получить в режиме online из системы ОПС или СКУД тревожное событие, зафиксировать его в БД и отобразить на графическом плане, включить реле контроллера, поставить область на охрану, получить вес с тензо-датчика весовой платформы и т.д.
Решается данная задача либо путём поддержки в системе протокола обмена стороннего оборудования низкого уровня, либо с помощью стандартных интеграционных механизмов систем промышленной автоматики, которые часто предлагают своим клиентам производители систем безопасности. Производители некоторых систем используют в своём оборудовании стандартные протоколы промышленной автоматизации типа Modbus, Profibus или LonWorks, некоторые системы включают в свой состав устройства или программные модули-конвертеры из закрытого протокола в стандартный. Но, наверное, самый распространённый путь, по которому идут производители систем безопасности, это разработка OPC-сервера поверх используемого в системе протокола (промышленного либо собственного). Подробно на стандарте OPC мы остановимся дальше в этой статье.
Протоколы обмена низкого уровня являются обычно закрытой информацией и это правильно, так как открытие протокола — потенциальная дыра в безопасности системы. Поэтому протоколы предоставляются производителями далеко не всегда. Плюсы использования протокола обмена низкого уровня — получение прямого, скоростного, полнофункционального доступа к оборудованию сторонней системы. Минусы часто перевешивают — это большое время на разработку решения, проблемы с технической поддержкой (найти «крайнего» в случае проблем затруднительно, так как процесс локализации возможных ошибок — дело непростое), проблемы с недостаточной полнотой документации, а также потенциальная необходимость доработок при внесении производителем изменений в протоколы низкого уровня.
Промышленные протоколы и стандарт OPC позволяют разработчикам получить надёжную и скоростную точку входа в чужую систему, в известной степени абстрагироваться от особенностей функционирования конкретной системы/оборудования и сосредоточиться на реализации стандарта.
Данная задача решается с помощью создания OPC-сервера, к которому подключается OPC-клиент, реализованный в SCADA-системе.
SCADA (аббр. от англ. supervisory control and data acquisition, диспетчерское управление и сбор данных) — программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. большинство систем автоматизации функционирует с участием человека (оператора, диспетчера). интерфейс между человеком и системой называют человеко-машинным интерфейсом (ЧМИ), в зарубежной литературе — HMI (human-machinery interface) или MMI (man-machinery interface). В частном случае, когда чми предназначен для взаимодействия человека с автоматизированным технологическим процессом, его и называют SCADA-системой. SCADA может являться частью АСУ ТП, АСКУЭ, системы экологического мониторинга, научного эксперимента, автоматизации здания и т.д. SCADA-системы используются во всех отраслях хозяйства, где требуется обеспечивать операторский контроль за технологическими процессами в реальном времени. Данное программное обеспечение устанавливается на компьютеры и, для связи с объектом, использует драйверы ввода-вывода или OPC/DDE серверы.
Стандарт OPC (ole for process control) разработан международной некоммерческой организацией OPC Foundation, членами которой являются более 400 фирм, работающих в области средств автоматизации и измерительной техники. Основателями организации являются фирмы Fisher-Rosemount, Rockwell Software, Opto 22, Intellution и Intuitive Technology. Первая версия OPC стандарта была выпущена в 1998 г. [OLE]. В совет директоров OPC Foundation в 2008 году входили представители Siemens AG, Emerson Process Management, Yokogawa, Honeywell, Rockwell Automation, Iconics.
Главной целью стандарта ОРС явилось обеспечение возможности совместной работы средств автоматизации, функционирующих на разных аппаратных платформах, в разных промышленных сетях и производимых разными фирмами. До разработки ОРС стандарта SCADA пакет нужно было адаптировать к каждому новому оборудованию индивидуально. Существовали длинные списки «поддерживаемого оборудования», очень сложной была техническая поддержка. При модификации оборудования нужно было вносить изменения во все драйверы, каждый из которых поддерживал протокол обмена только с одной клиентской программой. Число таких драйверов доходило до сотен.
Применение ОРС сервера при разработке заказных программ и интеграционных решений позволяет скрыть от разработчика всю сложность общения с аппаратурой, представляя довольно простой и удобный метод доступа к аппаратуре через стандартные технологии.
Стандарт ОРС состоит из нескольких частей, но наиболее часто используемыми являются две из них:
Сервер OPC DA является наиболее широко используемым в промышленной автоматизации. Он обеспечивает обмен данными (запись и чтение) между клиентской программой и физическими устройствами. Все данные состоят из трех полей: значение, качество и временная метка. Параметр качества данных позволяет передать от устройства клиентской программе информацию о выходе измеряемой величины за границы динамического диапазона, об отсутствии данных, ошибке связи и другие. Наиболее широко используемая версия этого стандарта: Version 2.05a.
Существует четыре стандартных режима чтения данных из ОРС сервера:
В каждом из этих режимов данные могут читаться либо из кэша ОРС сервера, либо непосредственно из физического устройства. Чтение из кэша выполняется гораздо быстрее, но данные к моменту чтения могут устареть. Поэтому сервер должен периодически освежать данные с максимально возможной частотой. Для уменьшения загрузки процессора используют параметр частоты обновления, которая может быть установлена для каждой группы тегов индивидуально. Кроме того, некоторые теги можно сделать пассивными, тогда их значения не будут обновляться данными из физического устройства.
Запись данных в физическое устройство может быть выполнена только двумя методами: синхронным и асинхронным, и выполняется сразу в устройство, без промежуточной буферизации. В синхронном режиме функция записи выполняется до тех пор, пока из физического устройства не поступит подтверждение, что запись выполнена. Этот процесс может занимать много времени, в течение которого клиент находится в состоянии ожидания завершения функции и не может продолжать выполнение своей работы. При асинхронной записи клиент отправляет данные серверу и сразу продолжает свою работу. После окончания записи сервер отправляет клиенту соответствующее уведомление.
ОРС DA сервер может иметь (не обязательно) пользовательский интерфейс, который позволяет выполнять любые вспомогательные функции для облегчения работы с оборудованием.
Целью OPC HDA сервера (сервера предыстории процесса) является предоставление клиентской программе единого интерфейса для обмена данными с любыми хранилищами данных, в качестве которых может выступать нестандартный файл с данными, стандартная СУБД, OPC DA сервер или другой ОРС HDA сервер. Стандарт распространяется только на интерфейсы для взаимодействия HDA сервера с клиентскими программами и не устанавливает способов получения или хранения данных.
Спецификация OPC HDA устанавливает стандарт на интерфейсы СОМ объекта и методы его использования. Структура сервера и методы взаимодействия с клиентами полностью аналогичны общей идеологии ОРС и описанному выше OPC DA в частности. Например, ОРС клиент может подсоединяться к нескольким OPC HDA серверам разных производителей и быть установлен на разных компьютерах в сети Ethernet.
Существует два типа HDA серверов:
Работа с данными заключается в чтении, записи или изменении данных.
В случае необходимости интеграции СКУД с другими системами, конечно же, всё зависит от решаемой задачи, поэтому универсальных решений здесь быть не может, главное, чтобы выбранный инструмент соответствовал задаче, был достаточно надёжным и достаточно производительным для решения нужных функций, и его можно было поддерживать в рабочем состоянии.
Мне лично близок девиз компании OPC Foundation: «Открытые коммуникации по открытым протоколам» в связке с неписаным правилом: «Протокол обмена СКУД низкого уровня должен быть закрытым».
