Журнал "Системы Безопасности" № 1‘2023
С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 114 февраль – март 2023 www.secuteck.ru СПЕЦПРОЕКТ СКУД ДЛя КРУПНых ОБъЕКТОВ Алексей Гинце, ААМ Системз Наиболее перспективными представляются контроллеры, позволяющие использовать раз- ные варианты архитектур построения системы на конкретных объектах многофилиальных СКУД. Это прежде всего распределенная, мно- гоуровневая (многоранговая) и кластерная архитектуры, а также их смешанные варианты. Причина проста: в многофилиальных системах для разных объектов могут оказаться опти- мальными различные варианты аппаратной архитектуры. Не менее важной является возможность раз- вертывания управляющего ПО в различных модификациях, также соответствующих мас- штабу и требованиям отдельных филиалов. Если сказать проще – крупная, территориаль- но распределенная СКУД должна быть макси- мально гибкой как на программном, так и на аппаратном уровнях. И скорее всего, это будет уже не просто СКУД, а интегрированная систе- ма безопасности (ИСБ). Олег Тихонов, АРМО-Системы Выбор архитектуры крупной СКУД во многом зависит от того, как выстроены процессы на самом предприятии, и может быть востребо- ван как односерверный, так и мультисервер- ный вариант. При наличии надежных каналов связи зачастую достаточно одного централь- ного сервера, и тогда вся сеть функционирует практически как единый объект. Однако если в составе компании есть филиа- лы, которые обладают автономностью (имеют свою службу безопасности, бюро пропусков), то в этом случае для каждого из них придется развернуть свой собственный сервер. Такая система будет существенно дороже, ведь для ее работы необходимы большие компьютер- ные мощности и человеческие ресурсы. Основная рекомендация при выборе архитек- туры крупных СКУД – это соблюдение баланса между допустимыми затратами и необходи- мыми параметрами. Мультисерверный вари- ант всегда будет дороже при построении, внедрении и обслуживании, чем односервер- ный, поэтому если есть возможность обеспе- чить надежный канал связи, я бы в первую очередь обратил внимание на односерверный вариант. Аркадий Гамбург, Семь печатей Есть два варианта построения распределенной системы. Первый ничем не отличается от построения просто большой системы на одном объекте. Архитектура предельно простая: все контрол- леры СКУД вывешиваются в ЛВС, имеющую выход в Интернет, и подсоединяются к одному удаленному серверу, который, собственно, и управляет всей этой системой. Второй более сложный. На каждом из объ- ектов строится локальная СКУД со своим сер- вером. Для создания единой системы органи- зуют синхронизацию локальных серверов, которая позволяет вести общую базу сотруд- ников и событий. Что пользователю, по боль- шому счету, и нужно – редактировать список людей на объектах и формировать общие по всем объектам отчеты. Понятно, что первый вариант более простой, но менее надежный (поскольку управление идет через пространство Интернета). Второй – сложнее в построении и администрировании, но зато более надежный, поскольку управле- ние осуществляется в рамках ЛВС и разрыв связей с другими системами никак не скажет- ся на работоспособности локальной. Оба варианта предлагаются заказчику на выбор. Но при этом, естественно, архитектура предлагаемой СКУД должна уметь реализовы- вать оба сценария. Максим Горяченков, НВП "Болид" В практической эксплуатации главным достоинством распределенной системы будет отказоустойчивость ее отдельных сегментов. То есть при авариях линий связи между конт- роллерами и серверами или сбоях в работе ПО локальные точки доступа должны продол- жать работать: двери открываться, события накапливаться для дальнейшей передачи в базу данных. Если несколько контроллеров остаются без связи с сервером, но с работаю- щим каналом связи между ними, должны сохранять работоспособность режимы запрета повторного прохода. Если локальный ПК, к которому подключены приборы, теряет связь с сервером системы, у него должен сохранять- ся функционал фотоверификации и интегра- ции с другими системами. Ольга Жабрева, АВИКС ДЦ Крупные территориально распределенные системы, на мой взгляд, лучше строить на архитектуре "звезда". Каждый объект в такой топологии имеет свой сервер, функционирую- щий вне зависимости от наличия стабильного канала связи с центральным сервером. Это дает возможность СКУД надежно функциони- ровать на каждом отдельно взятом объекте, обмениваться данными с центральным серве- ром при наличии связи, не перегружать дан- ными каждый локальный сервер. Сергей Ефремов, дормакаба Евразия Для распределенных систем, как правило, хорошо подходит децентрализованная архи- тектура, в которой механизмы принятия реше- ний максимально отодвинуты от серверов в сторону контроллеров доступа. То есть в иде- альной системе сервер должен только обнов- лять мастер-данные в контроллере, а контрол- лер должен полностью управлять ситуацией в своей зоне ответственности и обязательно взаимодействовать с другими контроллерами на объекте, не задействуя при этом вышестоя- щее ПО. С точки зрения программного обес- печения важна возможность предоставления постоянного и надежного доступа к интерфей- су оператора, то есть архитектура серверной части должна поддерживать создание резерв- ных серверов приложений, на которые может быть вынесена часть функционала системы. Артем Старшинов, Sigur Для территориально распределенных систем мы рекомендуем СКУД с распределенной архитектурой для обеспечения максимальной автономности каждого из локальных объ- ектов. Однако программное обеспечение с каждым годом развивается и модернизируется, и уже сейчас клиент-серверная архитектура может закрывать большие территориально распреде- ленные объекты, которые еще пять-семь лет назад нельзя было покрыть без использования распределенной архитектуры ПО (многосер- верности). Самое главное – это автономное функциони- рование объекта. Если эта задача выполняется на аппаратном уровне, то дальнейшая про- граммная архитектура может быть любой. Сергей Сорокин, ТерраЛинк На мой взгляд, однозначного ответа нет. Мно- гое зависит от общей постановки задачи и от того, как на объекте заказчика организована сетевая инфраструктура, хранение и обработ- ка данных, есть ли интеграция СКУД с другими системами обеспечения безопасности, насколько необходима потребность в консо- лидированной информации. Следует учиты- вать также, какая организационная структура службы безопасности применяется у заказчи- ка, как организован процесс реагирования на события, как устроены процессы взаимодей- ствия между подразделениями безопасности (единый ситуационный центр, отдельная служба безопасности в каждом территориаль- но распределенном подразделении организа- ции и т.п.). Денис Иванов, Итриум СПб Устоявшейся терминологии для типов архитек- туры СКУД пока нет, я бы назвал рекомендуе- мую архитектуру смешанной: в рамках локаль- ного объекта (например, предприятия в соста- ве холдинга) она должна максимально стре- миться к "плоской", то есть все элементы должны быть практически равноправными и в высокой степени самодостаточными (конт- роллеры обеспечивают требуемую логику доступа и принятие решений самостоятельно, без участия сервера), при этом уже в рамках холдинга, безусловно, важна способность системы к централизации – нужны определен- ные центры мониторинга и управления, "более главные", чем все остальные. n СКУД с какой архитектурой наиболее подходит для построения крупных, территориально распределенных систем? На чем это основано? Ваше мнение и вопросы по статье направляйте на ss @groteck.ru
Made with FlippingBook
RkJQdWJsaXNoZXIy Mzk4NzYw