На рисунке 1.2.1 представлена общая схема интеграционного решения HtPassMonitor.
На каждом автоматизированном рабочем месте (АРМ) устанавливается Клиент и настраивается список считывателей, по которым должны отображаться события проходов на соответствующем АРМ.
Сервис подключается к СКУД и отправляет события проходов подключенным Клиентам.
Для работы Сервис использует программные модули-поставщики трех типов::
- Поставщик считывателей – обеспечивает получение списка считывателей. При запуске Сервис сохраняет список считывателей в локальную базу данных. При подключении Клиент запрашивает у Сервиса список считывателей.
- Поставщик персон – обеспечивает репликацию персон из базы данных СКУД в локальную базу данных Сервиса для быстрой выгрузки информации о персоне при возникновении события прохода.
- Поставщик событий – получает события проходов из источника событий СКУД. Полученные события Сервис рассылает подключенным Клиентам.
Каждый интеграционный модуль может являться поставщиком данных любого типа (персон, событий или считывателей). При этом источником данных одного типа могут выступать несколько разных интеграционных модулей. Пример работы поставщиков данных приведён на рисунке 1.2.2.
На рисунке 1.2.2 изображен пример, в котором в качестве поставщиков данных используется 3 интеграционных модуля, при этом у у двух модулей имеется поставщик событий.
Набор используемых интеграционных модулей и состав поставщиков данных указываются в файле настроек сервиса "_MainSettings.json". Подробнее о настройке поставщиков смотри раздел 3 Настройка.
Также в Сервисе имеется модуль CSV Readers. Этот модуль не относится конкретно к какому-либо модулю и является поставщиком считывателей. CSV Readers берёт данные о считывателях из файла "Readers.csv".
Принципы приоритизации поставщиков:
- Поставщики считывателей не должны поставлять считыватели с одинаковыми именами, иначе источник событий будет неопределённо. При этом CSV Readers всегда ниже в приоритете чем интеграционные модули, поэтому он может содержать считыватели с таким же названием, как и те что поставляются другими интеграционными модулями. В этом случае, данные о считывателях из файла "Readers.csv" будут замещены при наличии этих считывателей из других поставщиков. Пример замещения приведено на рисунке 1.2.3;
- При появлении события, проверяется принадлежность считывателя из события к модулю, от которого событие пришло. Если событие пришло по считывателю, который не принадлежит к какому либо модулю (то есть он описан только в файле "Readers.csv"), то такое событие будет обрабатываться всегда, вне зависимости от кого оно пришло. Если пришло событие, у которого название считывателя принадлежит другому интеграционному модулю, то такое событие фильтруется.
Общий алгоритм работы интеграционного решения:
- Сотрудник предприятия подходит к турникету и прикладывает свою карту к считывателю или же происходит автоматическое распознавание сотрудника «по лицу». В зависимости от этого программное обеспечение СКУД генерирует одно из двух событий: "Запрос доступа" или "Лицо распознано".
- Модуль Сервис получает информацию о событии и загружает данные о сотруднике (посетителе), совершающем проход.
- Полученная информация передаётся всем Клиентам, подключенным в данный момент к Сервису.
- Клиенты получают информацию о событии и отображают её на экранах АРМ сотрудников постов охраны.