Программные комплексы СКУД для крупных объектов

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

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

Понятие размера объекта

Что же такое "крупный объект" и чем он отличается от иных объектов? Четко сформулированных критериев классификации пока нет - она производится, как правило, на основе эмпирических и интуитивных представлений. Размер объекта традиционно определяется через совокупность следующих параметров: количество рабочих мест в системе; количество активных держателей карт СКУД в системе; количество считывателей, охранных датчиков. Например, система, включающая в себя до 5 рабочих мест и до 100 считывателей, может считаться малой; а имеющая от 5 до 20 рабочих мест и до 500 считывателей - среднегабаритной. Также немаловажным параметром является географические размеры (площадь) объекта и фактор распределенности.

Рассмотрим ниже влияние этих параметров на функционирование ПК СКУД.

Количественные показатели

Количество активных держателей карт

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

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

Количество рабочих мест

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

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

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

Географические показатели

Помимо прямых количественных характеристик существуют так называемые географические показатели, вносящие свою специфику в построение СКУД на крупных объектах.

Площадь объекта

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

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

В систему могут входить два и более ядра, каждое из которых запускается на отдельном компьютере. В начальный момент времени, когда система считается нормально функционирующей, работу комплекса обеспечивает только одно активное ядро. Остальные ядра отслеживают его наличие и находятся в "спящем" режиме. Как только активное ядро перестает функционировать (при выходе из строя компьютера данного ядра), одно из резервных ядер автоматически становится активным и обеспечивает дальнейшее функционирование системы. В том случае, если произошел обрыв ЛВС, повлекший распад системы на несвязанные сегменты, резервные ядра обеспечат функционирование тех сегментов, к которым принадлежат их компьютеры. Таким образом, система распадется на автономные, но функционирующие сегменты. В обоих случаях после устранения причины отказа система продолжает работать в нормальном режиме, при этом информация, накопленная в резервных ядрах, пересылается в центральное ядро.

Распределенность объекта

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

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

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

Многофилиальная система - это не просто репликация данных между базами. В случае нормального соединения филиалы функционируют как единая система - можно из любой точки изменять конфигурацию объектов филиалов, управлять аппаратурой филиалов, отслеживать их состояние; в филиале могут отрабатываться реакции по событиям из другого филиала. При использовании механизма репликации такие функции не могут быть реализованы.

Масштабируемость - ключ к построению эффективной СКУД

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

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

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

Различают функциональную масштабируемость и масштабируемость по мощности.

Функциональная масштабируемость означает возможность при необходимости внедрить дополнительные функциональные модули, которые не были изначально заложены в систему (как правило, это бизнес-логика процессов, специфичных для конкретного объекта). Эти модули должны быть совместимы друг с другом и с теми модулями, которые были внедрены ранее.

Масштабируемость по мощности означает полное сохранение работоспособности и выполнение всех функций системой при изменении размеров системы.

Обеспечение производительности при росте системы

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

Приведенный выше вариант позволяет снизить время взаимодействия ПК с аппаратурой СКУД: загрузку карт и конфигурации, получение сообщений. Однако это не решает проблему "узких мест" самого ПК, связанных со скоростью обработки поступающих сообщений. Рассмотрим типичный пример: завод оборудован проходными. Каждая проходная оснащена рабочим местом сотрудника службы безопасности, на котором в режиме реального времени отображаются фотографии людей, регистрирующихся на считывателях проходной. Очевидно, что лицо проходящего должно отображаться с минимальной задержкой, чтобы сотрудник службы безопасности мог сверить его с хранящейся в БД фотографией держателя карты. Как правило, все ПК хранят фотографии в БД на сервере системы. Это означает, что в часы пик с рабочих мест проходных будут производиться параллельные обращения в базу, причем с высокой интенсивностью. Если предположить, что на заводе имеются 5 проходных, в каждой из которых оборудованы 4 точки прохода, то при одном рабочем месте на проходную в часы пик к базе будет поступать 20 обращений в секунду. Соответственно с увеличением количества рабочих мест, проходных или точек прохода количество обращений будет расти. Начиная с определенного момента сервер перестанет справляться и начнет выдавать фотографии с неприемлемой задержкой по времени.

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

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

Открытость программного комплекса

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

На крупных объектах распространено использование информационных систем (ИС) различного назначения. Такие И С могут содержать в себе модули управления персоналом, заказа гостевых пропусков. В этом случае логично желание заказчика интегрировать имеющуюся информационную систему со СКУД, чтобы не вводить раздельно в каждую систему одни и те же данные о сотрудниках или гостях. Если организация оказывает платные услуги, заказчику может потребоваться интеграция со СКУД в контексте ограничения доступа в зависимости от состояния счета или пакета предоплаченных услуг.

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

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

Ряд функций не является обязательным на небольших объектах, однако для крупных объектов их наличие имеет существенное значение.

Средства быстрой регистрации посетителей

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

Основная задача средств быстрой регистрации - обеспечить за счет максимальной автоматизации необходимую скорость регистрации посетителей. Поскольку наиболее трудоемким в данной процедуре является ручной ввод данных (паспортные данные, номер карты), его необходимо исключить из процесса. Этого можно добиться такими средствами, как:

  • ввод личных данных с помощью системы распознавания документов;
  • автоматический поиск личных данных посетителя в БД с фамилиями, именами и отчествами посетителей, предотвращающий повторный ввод информации;
  • захват фотографии напрямую у источника видеосигнала (цифрового фотоаппарата или платы видеоввода);
  • заблаговременное определение количества мест посещения и связь каждого из них с разрешением на проход через определенную группу считывателей;
  • ввод номера карты с помощью считывателя, подключенного к АРМ;
  • изъятие и деактивация гостевых карт автоматически через картоприемник.

Определение местонахождения человека

На крупных или географически распределенных объектах нередко возникает задача определения местонахождения человека. Очень часто требуется информация о том, пришел ли уже пользователь N на работу, в каком филиале/корпусе/кабинете он сейчас находится и т.п.

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

Глобальный контроль повторного входа

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

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

Заключение

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

Источник: Каталог "СКУД. Антитерроризм"-2009
Автор: Д. А. Шестаков
 

Картинка: 
СКУД