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

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

1. Умные контроллеры

В основе современной системы контроля доступа находятся контроллеры, которые должны быть самодостаточными, или, как говорят, “умными”. Это понятие включает в себя несколько факторов.

Во-первых, контроллер должен обеспечивать полнофункциональную работу при отсутствии связи с сервером системы – то есть он должен держать в своей памяти список лиц, имеющих права доступа. Здесь мы имеем в виду именно лица, а не идентификаторы. Так как идентификаторов может быть много, но принадлежать они могут одному и тому же человеку. Контроллер должен помнить все права доступа данного человека, и сохранять в памяти все произошедшие события.

Для связи контроллеров с другими контроллерами, серверами и клиентами должен применяться интерфейс Ethernet. Для этого есть несколько причин, среди которых широкое распространение, простота администрирования, возможность применения на любом расстоянии штатными средствами и исполнителями. Для построения локальной сети и обеспечения ее безопасности также можно использовать Internet посредством VPN. Также контроллер должен поддерживать протокол обмена в формате Full Rest API и уметь принимать и передавать данные разным клиентам - серверам и другим контроллерам. Они могут включать информацию об изменении данных и необходимости синхронизации. Это позволяет строить системы с распределенными центрами принятия решений и точками ввода информации.

Далее, контроллер должен уметь принимать решения, основанные не только на том, известен ли ему данный идентификатор и легитимны ли время и место для разрешения прохода. Способности контроллера должны включать умение строить цепочки доступа на основании дополнительных данных. Например, контроллер может разрешить проход только в случае, если после предъявления идентификатора последовательно сработали несколько входов с подключенными к ним устройствами, после чего от определенного IP адреса была получена команда “ОК”. В качестве устройств, подключенных к входам, могут выступать пирометр и алкотестер. Итоговое разрешение может быть получено, например, от системы рентген-контроля.

2. Системные серверы

В первую очередь, серверы системы контроля доступа должны быть универсальными и способными работать под разными операционными системами. Желательно наличие сертификатов для специфических операционных систем, например, Роса или Астра.

Сервер должен быть способным адаптироваться под различные ресурсы, среди которых выделенный сервер, облачный сервер или, в случае с небольшими системами, контроллер.

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

База данных сервера должна быть масштабируемой – например, MySQL, MSSQL, PostgreSQL.

Как и контроллер, сервер должен поддерживать протокол обмена в формате Full Rest API. При этом этот протокол должен использоваться как для обмена со штатным клиентом, так и для любого другого ПО. Он должен быть единым, что позволяет как снизить затраты на поддержку отдельного SDK, так и исключить различия в коде реализации и наличие ошибок.

Протоколы обмена сервера системы и контроллеров должны быть открытыми. В этом случае любой разработчик может добавить тот или иной функционал для решения задач каждого клиента.

Система должна поддерживать работу в формате распределенных серверов. Это необходимо не только для крупных заказчиков, но и для систем, когда контроллеров немного, но они распределены по городу или стране, и заказчик хочет видеть их все в одной системе.

3. Клиенты системы

В первую очередь, в современной системе контроля доступа должна быть реализована возможность работы с самыми различными клиентами. Это может быть WEB клиент или мобильное приложение. Все они должны работать под любой операционной системой.

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

За счет поддержки открытого протокола обмена в формате REST API на уровне контроллеров и серверов клиенты могут быть разработаны под нужды каждого заказчика. Также важно, чтобы производитель предоставлял примеры реализации функционала.

Заключение

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