Контроллеры для средних и крупных СКУД должны быть мощными, защищенными и универсальными

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

Не менее важна качественная защищенность. Я подразумеваю под этим криптозащиту линий связи с компьютером и с другими контроллерами – шифрация трафика позволяет исключить возможность интеллектуального взлома. В контексте защищенности линии связи со считывателями наиболее актуальным является использование протокола OSDP (Open Supervised Device Protocol), реализованного на физической основе RS-485, в линии связи "считыватель – контроллер". OSDP – это современный открытый промышленный протокол для безопасного обмена данными, выгодно отличающийся от привычного в СКУД Wiegand своей защищенностью, универсальностью и двунаправленностью. Если считыватель будет выведен из строя, оператор тут же получит сообщение об этом.

Следующий параметр – универсальность. В идеале универсальный контроллер позволяет строить системы с разной архитектурой – распределенной, централизованной, смешанной, кластерной. Если пойти еще дальше, то для заказчика идеальный вариант – когда один контроллер конфигурируется под различные задачи и может выполнять не только задачи СКУД, но и, к примеру, базовые охранные функции. Представьте, что у вас на складе только один тип контроллера, который можно сконфигурировать под текущие задачи, и не надо держать у себя десяток специализированных дорогих устройств. Некоторые коллеги могут сказать, что иногда специализированные контроллеры и охранные панели могут оказаться очень даже полезными. Так никто и не возражает: что мешает иметь в линейке один универсальный контроллер для решения 90% типовых задач на объекте и некоторое количество специализированных модулей для решения оставшихся 10% специфических, нужных не всем?

СКУД с сегментами разной архитектуры на одном общем контроллере

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

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

Оптимальная архитектура СКУД зависит от характера и топологии объекта

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

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

Приоритетные требования к системе

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

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

Способы и средства обеспечения безопасности

Для каждого объекта набор средства обеспечения безопасности будет индивидуален. Я бы еще раз упомянул OSDP. Протокол 2-го поколения позволяет передавать данные между считывателем и контроллером в защищенном виде, с шифрованием по алгоритму AES-128. При подключении считывателей по OSDP контроллер СКУД получает информацию о статусах устройств в режиме реального времени. Важно также, что по OSDP можно подключать не только считыватели, но и модули расширения входов/выходов, защищать линии связи с исполнительными устройствами СКУД и др. Что касается программной части, главное, чтобы разработчик был отечественным, опытным и доступным для взаимодействия.