Четких границ между малыми, средними и крупными системами нет
Антон Сердюков, 19/03/21
Количество постоянных идентификаторов, поток посетителей через бюро пропусков и количество рабочих станций, с которых производится взаимодействие с системой, – важные параметры СКУД, влияющие на выбор решений. Однако устоявшимся параметром, описывающим размер системы, является количество точек доступа – дверей, турникетов, автовъездов и т.д. в зависимости от архитектуры и особенностей реализации конкретной системы количество контроллеров может быть равно количеству точек доступа, а может быть и в несколько раз меньше. Тем не менее именно количество точек доступа определяет масштаб системы.
Провести четкую границу между малыми, средними и крупными системами нельзя. Полагаю, системы до 50 точек прохода можно считать малыми, от 50 до 100 – средними, от 100 до 500 – крупными, а свыше 500 точек доступа – особо крупными.
Примечательно, что главное различие между системами разного масштаба – не количество точек доступа, хотя именно этот параметр мы выбрали основным в оценке размеров системы.
Как показывает практика, требования к функционалу, интегрируемости и "кастомизации" коррелируют с размером системы. Если для малых систем подойдет условно любая современная СКУД, то в случае с особо крупными объектами можно смело утверждать, что не подойдет ни одна. набор требований в этих проектах такой, что любая система, которую бы ни выбрал заказчик, будет подвергнута серьезной доработке на стороне производителя, расширена уникальными интеграциями, "доработана напильником" в ходе внедрения инсталлятором и затем будет бесконечно модифицироваться силами собственного ИТ-отдела заказчика на протяжении всего жизненного цикла. Таким образом, к крупным и особо крупным относятся системы емкостью более 100 точек доступа, которые, как правило, характеризуются широким функционалом, наличием бюро пропусков, сложными алгоритмами доступа, применением двух и более стандартов идентификаторов одновременно, интеграцией с внешними системами безопасности и бизнес-приложениями, нетривиальными механизмами учета рабочего времени и управления трудовой дисциплиной.
Идентификаторы и их комбинации – самая дискуссионная тема в каждом проекте
Опишу наиболее типовую ситуацию с технологиями идентификации на крупных и особо крупных объектах. на руках у сотрудников большое количество давно выданных низкочастотных карт HID и/или EM-Marin. При этом в рамках проекта расширения или модернизации СКУД принято решение постепенно переходить на MIFARE и смежные высокочастотные технологии. Часть сотрудников использует в качестве идентификатора собственные смартфоны. Если на объекте есть автомобильные въезды, то там применяется распознавание автомобильных номеров, UHF-идентификаторы или дальняя идентификация на активных метках. Существует порядка 5–15% особых точек прохода с повышенными требованиями к строгости доступа, где применяются биометрические признаки в качестве идентифицирующего или верифицирующего фактора – отпечатки пальцев, рисунок вен ладони, рисунок радужной оболочки глаза, распознавание лиц. на проходных могут быть применены технологии измерения температуры тела и алкотестирования. в бюро пропусков могут использоваться дешевые одноразовые идентификаторы – MIFARE Light на бумажной основе, QR-коды или штрихкоды. в итоге у каждого сотрудника может быть 2–3 или даже более идентификаторов, которые он применяет в зависимости от точки доступа. и это мы еще не коснулись распределенных объектов с десятками локаций, разными применяемыми идентификаторами и командировочной миграцией персонала.
Архитектура СКУД определяется подходом к хранению данных
Говоря о крупных объектах, применение распределенной клиент-серверной архитектуры видится наиболее оптимальным, если критерием оптимизации считать надежность и устойчивость системы. Такая архитектура подразумевает хранение данных и в памяти контроллеров, и в локальных БД АРМов, и в БД сервера. Этот подход применим и к построению территориально распределенных, но при этом централизованных систем: локальные копии БД, хранящиеся на серверах оборудования в каждой локации, снижают риски потери связи между филиалами и повышают устойчивость системы.
Если же система внедряется на крупный распределенный и децентрализованный объект (слабосвязанные холдинговые структуры, франшизные сети и т.д.), то лучшим решением будет применение многосерверной архитектуры. в этом случае мастер-сервер задает общие политики, правила, расписания и др., но при этом каждый сегмент системы управляется собственным сервером, а доступ к внешним субъектам из других сегментов предоставляется через "публичные" группы доступа.
К крупным и особо крупным относятся системы емкостью более 100 точек доступа, которые характеризуются широким функционалом, наличием бюро пропусков, сложными алгоритмами доступа, применением двух и более стандартов идентификаторов одновременно, интеграцией с внешними системами безопасности и т.д.
Требования под задачу
Чтобы сформулировать требования к контроллерам СКУД, нужно сперва сформулировать задачу. Попробую это сделать. Много удаленных друг от друга локаций в разных городах, много точек доступа, много контроллеров. Требуется надежность, под которой будем понимать минимизацию времени простоя точек доступа. из такой постановки задачи легко сформулировать требования:
- взаимозаменяемость контроллеров разных моделей и/или версий;
- быстрая замена в случае выхода из строя;
- простота коммутации и настройки, "защита от дурака", возможность найти монтажников в любом регионе.
Аналогично формулируются рекомендации по выбору исполнительных устройств для СКУД большого масштаба:
- взаимозаменяемость;
- простота;
- защита от ошибки;
- невысокие требования к уровню компетенций исполнителей работ.
"Распознавание лиц обречено на успех" читать статью >>
Тонкости ПО
Основное требование к ПО СКУД для крупных и особо крупных объектов – надежность. из этого требования вытекают и подходы к распределенному хранению данных, и поддержка технологий кластеризации, и динамическое перераспределение нагрузки на серверы оборудования и т.д. Заказчиком также может быть предъявлено требование удаленной настройки и конфигурирования оборудования, управления персоналом и прочими сущностями СКУД. в этом случае такой функционал должен поддерживаться в ПО. Если учет рабочего времени средствами СКУД предполагается применять не просто "для галочки", а в качестве реального бизнес-инструмента, на основе которого будут приниматься управленческие и организационные решения, то нужно очень внимательно сформулировать требования к корректной работе с часовыми поясами, а также к учету командировок и фиксации рабочего времени сотрудника в ходе его нахождения в филиалах.
