СКУД: архитектура и классификация

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

С момента появления первых систем контроля и управления доступом (СКУД) на отечественном рынке прошел не один десяток лет. Последняя версия стандарта на эту тему, а именно ГОСТ Р 51241–2008, датируется, как видно из номера, 2008 г. В настоящих реалиях развития данного технического направления это уже не просто древность, это, как писал незабвенный Александр Сергеевич, "дела давно минувших дней, преданья старины глубокой…". Я не про то, что стандарт плох, просто он безумно устарел. В соответствии с принципом "свято место пусто не бывает" в прессе, Интернете и просто в разговорах специалистов неизбежно появляются новые понятия, названия, определения и попытки классификации новых технологий, устройств, систем и пр. Некоторые из них я бы осторожно назвал "не совсем удачными" с самого начала, другие иногда трансформируются, уйдя в народ, и возвращаются обратно с искаженным смыслом. Плохо в этом то, что в процессе обсуждения СКУД заинтересованные стороны – заказчик, инсталлятор, разработчик, дистрибьютор, проектировщик, интегратор (недостающее вставить), оперируя в разговоре одинаковыми терминами и определениями, вкладывают в них порою разный смысл. Иногда сталкиваюсь с ситуацией, когда удачное и точное определение, название или классификация начинают использоваться всеми кому не лень просто по причине интереса со стороны заказчика. И вот уже "фотонные отражатели", встроенные в контроллеры, начинают бороздить "просторы Большого театра". Проблема серьезная и быстро не решается, но делать давно что-то надо. Предлагаю по крайней мере начать ее обсуждать. В качестве "затравки" представляю вам свое видение классификации архитектур сетевых СКУД (в терминах ГОСТа согласно п. 4.2.2) масштаба от среднего и выше.

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

Сухим языком ГОСТа

Чтобы избежать возможного непонимания, сделаем отступление для уточнения некоторых терминов, используемых ниже. Существующий ГОСТ Р 51241–2008 "Средства и системы контроля и управления доступом", который устанавливает классификацию, общие технические требования и методы испытаний, подразделяет СКУД по:

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

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

Контроллеры СКУД

Распределенная архитектура СКУД (одноранговая)

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

Рис. 1. Распределенная архитектура СКУД (одноранговая)

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

Однако всю базу данных вышедшего из строя контроллера мы потеряем. Наиболее часто в системах с распределенной архитектурой один контроллер управляет проходом в две–четыре двери. При большем количестве дверей возникает проблема прокладки коммуникаций, поскольку к каждому замку надо проложить свою линию, подключить отдельно каждый считыватель (если используем Wiegand), протянуть свои линии к датчику двери и кнопке выхода. Больше проводов – выше затраты. Cледует также помнить: чем больше коммуникаций выходит за пределы охраняемого помещения, тем выше вероятность внешнего вмешательства. Лет 15 назад в таких системах часто использовались интерфейсы RS-485 и токовая петля 20-мА, сегодня "правит бал", безусловно, LAN, но и проверенный RS-485 не теряет своей актуальности.

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

Достоинства:

• простота конфигурации;
• одно устройство в ЗИП;
• при выходе из строя контроллера теряем не всю базу, а только часть.

Недостатки:

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

Централизованная архитектура СКУД (многоранговая)

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

Рис. 2. Централизованная архитектура СКУД (многоранговая)

Функции управления дверями, другими внешними устройствами (в соответствии с ГОСТом "Устройства преграждающие управляемые – УПУ") выполняют внешние дверные модули и релейные блоки. Именно они устанавливаются недалеко от объектов управления (двери, охранные шлейфы и др.). Для обмена информацией между центральным контроллером и дверными модулями обычно используются интерфейсы RS-485 или LAN.

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

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

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

Достоинства:

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

Недостатки:

• высокая стоимость для небольших систем;
• выход из строя центрального контроллера или нарушение связи с дверными модулями приведет к остановке системы и потере базы на аппаратном уровне.

Многоуровневая архитектура СКУД (многоранговая)

Обычно такие системы (рис. 3) получаются из СКУД с централизованной архитектурой путем добавления специализированных считывателей/контроллеров или дверных контроллеров с собственным буфером памяти идентификаторов и событий – "интеллектуальных интерфейсных модулей". Можно сказать, что каждый такой модуль/контроллер фактически является дверным контроллером СКУД, сравнимым с контроллером в распределенной (одноранговой) системе. Благодаря использованию такого технического решения достигается избыточное резервирование функций, резко повышающее степень безопасности и отказоустойчивости системы. Поскольку контроллер в СКУД с централизованной архитектурой управляет значительным количеством дверей, повреждение линии связи между ним и интерфейсными модулями управления оконечными устройствами способно привести к блокированию значительной части или даже всей системы. Локальный считыватель/контроллер или промежуточный дверной контроллер многоуровневой СКУД, обладающий встроенным буфером памяти, в этом случае переходит в автономный режим управления доступом (на своем участке). Системы, построенные с использованием такой архитектуры, обладают высокой степенью безопасности и исключительной надежностью функционирования. Наличие в таких системах дверных контроллеров с возможностью подключения к центральному контроллеру по LAN-интерфейсу добавляет системе полезные свойства. При наличии развитых сетевых коммуникаций на территории объекта дверные контроллеры с LAN устанавливаются в удаленных зданиях, что придает системе дополнительную гибкость и позволяет экономить значительные средства. Суммируя сказанное, можно сделать вывод, что смешанная система – это властная вертикаль или пирамида с возможностью передачи части функций управления на более низкий уровень в случае наступления экстренной ситуации. Наверху этой пирамиды контроллер-"начальник", который руководит, анализирует и хранит информацию, внизу дверные контроллеры-"прорабы", которые выполняют команды, но также могут самостоятельно действовать на своем участке даже тогда, когда "начальник" отсутствует, выполняя на своем участке его функции.

База данных в такой системе хранится не только в центральном контроллере, она также распределена по дверным контроллерам в соответствии с зоной ответственности каждого.

Рис. 3. Многоуровневая архитектура СКУД (многоранговая)

Фактически многоуровневые СКУД аккумулируют достоинства систем с распределенной и централизованной архитектурой и имеют один недостаток – более высокую стоимость.

Достоинства:

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

Недостатки:

• высокая стоимость;
• ориентация на СКУД с емкостью от средней и выше.

Кластерная архитектура СКУД

СКУД с кластерной архитектурой (рис. 4) являются, пожалуй, наиболее продвинутым и современным вариантом в сравнении с указанными выше. В классическом варианте это одноранговые системы, их основное отличие – наличие прямого взаимодействия P2P (Peer-to-Peer) между входящими в них контроллерами. Однако распространенным решением является также вариант, когда выделяется master-контроллер, через который осуществляется управление системой (всеми остальными slave-контроллерами кластера). Такое решение позволяет организовать единую точку для входа в аппаратную часть системы (шлюз), что является более безопасным вариантом, чем индивидуальная связь с каждым контроллером. Типичная кластерная СКУД представляет собой группу одинаковых контроллеров, объединенных по сети, которая может рассматриваться как единый аппаратный ресурс. Эти контроллеры объединяются логически и могут обрабатывать идентичные запросы. Кластерные контроллеры обладают продвинутой и мощной аппаратной подсистемой встроенной автоматизации и позволяют программировать сложную логику работы на уровне всего кластера без участия управляющих компьютеров. В этом состоит их главное преимущество.

Рис. 4. Кластерная архитектура СКУД

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

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

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

Достоинства:

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

Недостатки:

• стоимость.

Смешанные и гибридные архитектуры СКУД

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

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

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

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

Рис. 5. Смешанные и гибридные архитектуры СКУД

Варианты развертывания ПО для СКУД

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

Малая изолированная система

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

Рис. 6. Малая изолированная система

Достоинства:

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

Недостатки:

• Зависимость работы оборудования от действий оператора.

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

• Администрирование системы (в том числе добавление пользователей и выдача им пропусков) возможно только на данном компьютере.
• Необходимость подключения всего управляемого оборудования к данному компьютеру. Это может быть не всегда удобно, особенно в случае значительной территориальной распределенности объекта.

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

Рекомендации:

Данная конфигурация хорошо подходит для построения СКУД небольшого масштаба.

Централизованная многопользовательская система

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

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

Рис. 7. Централизованная многопользовательская система

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

Достоинства:

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

Недостатки:

• Необходимость подключения всего оборудования к одному компьютеру не всегда удобна.
• Медленная реакция комплекса на события и команды оператора при увеличении нагрузки на компьютер.

Рекомендации:

Данная конфигурация хорошо подходит для построения СКУД среднего размера.

Крупная распределенная система

В такой системе (рис. 8) сервер управления базой данных и ядро работают на центральном сервере, а драйверы оборудования и логики распределены по всей сети. Запуск управляющих консолей возможен на любом компьютере сети, что делает управление более гибким.

Рис. 8. Крупная распределенная система

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

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

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

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

Достоинства:

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

Недостатки:

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

Рекомендации

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

Многофилиальная система

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

Рис. 9. Многофилиальная система

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

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

ACaaS – облачная СКУД

Облачные технологии прочно обосновались в нашей жизни. Неважно, что мы делаем: пользуемся удобными банковскими сервисами на своем смартфоне или вместе с коллегами храним основную информацию на облачном сервере, – все это объединяется понятием "облачные технологии". Системы контроля и управления доступом не являются в этом плане исключением, хотя консерватизм не всегда сдает свои позиции. Не так давно появился даже термин ACaaS (Access Control as a Service, или СКУД как услуга). С развитием облачных технологий появились различные варианты их реализации, и, как следствие, специалисты выделяют несколько ключевых типов (классификация моделей). Общим в классификации является окончание аббревиатуры на "…as a Service", означающее "как услуга". Это следующие модели (подробнее в журнале "Системы безопасности" № 4/2021 г., стр. 60):

• IaaS (Infrastructure as a Service) – инфраструктура как услуга;
• PaaS (Platform as a Service) – платформа как услуга;
• SaaS (Software as a Service) – программное обеспечение как услуга. Пожалуй, наиболее известный вариант. Многие крупнейшие разработчики ПО переходят на эту модель работы с потребителями. При этом используется готовое ПО, управляемое через веб-браузер. Разработчик берет на себя все заботы по поддержке и обновлению данного ПО, а также следит за инфраструктурой и ОС;
• MaaS (Monitoring as a Service) – мониторинг как услуга;
• CaaS (Communication as a Service) – коммуникации как услуга;
• XaaS (Anything as a Service) – все что угодно как услуга.

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

Опубликовано в журнале "Системы безопасности" № 5/2022

Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>

Источник фото: zabor.bz