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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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