Российские контроллеры СКУД: функционал не уступает оборудованию зарубежных производителей

Одна из основных задач для крупнейших заказчиков – поиск и выбор отечественных контроллеров систем контроля и управления доступом (СКУД). Эксперты ДИАМАНТ ГРУПП, PERCo, АРМО-Системы, Делетрон, НВП "Болид", Компания Семь печатей, Равелин и АЛГОНТ рассказали, как выбрать архитектуру СКУД в зависимости от задач и объекта, на какие технологии в отечественных СКУД стоит обратить внимание и какие функции помогут облегчить жизнь инсталляторам и пользователям.

авторы1

авторы (1)-1

авторы (2)-1

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

Леонид Стасенко, ДИАМАНТ ГРУПП

Выбор архитектур не так уж и велик. Всегда это, как правило, некая сетевая структура, а основных типов коммуникационных интерфейсов всего два – это Ethernet во всех его ипостасях и старый добрый RS-485. У последнего остается неубиенной его возможность работать на дальностях до километра и более, чего никак не может обеспечить Ethernet (если только не говорить об оптике вместо меди). Вторая проблема Ethernet – необходимость к каждому контроллеру тянуть отдельный кабель, что делает монтаж более дорогим. Однако ввиду того, что сейчас нет объектов, на которых изначально бы не имелась развитая сетевая инфраструктура, на этот недостаток часто не обращают внимания.

С RS-485 можно на один кабель в линеечку повесить десятки контроллеров, что, правда, ухудшает время реакции системы за счет последовательного опроса всех контроллеров на линии.

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

Еще одна, возможно, перспективная топология связана с появлением контроллеров с Linux на борту – это уже нормальный компьютер с громадными ресурсами, позволяющими "тянуть" до нескольких десятков точек прохода. Но поскольку на плате такого контроллера невозможно разместить разъемы для такого количества периферии, напрашивается топология с "глупыми" дверными модулями, подключаемыми по все тому же RS-485, например с тем же протоколом OSDP.

Игорь Ядрихинский, PERCo

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

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

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

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

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

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

Вячеслав Петин, АРМО-Системы

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

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

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

Евгений Золотарев, Делетрон

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

Максим Горяченков, Болид

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

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

Аркадий Гамбург, Семь печатей

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

Евгений Кондратьев, Равелин

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

Поэтому приведу пункт ГОСТа, который, думаю, ближе всего касается данной темы обсуждения: "П. 4.2.2 По способу управления СКУД подразделяют на:

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

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

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

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

Евгений Белкин, АЛГОНТ

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

СКУД локального объекта может быть составной частью СКУД территориально распределенного объекта.

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

В качестве линий связи в сетях контроллеров чаще всего используется витая пара с интерфейсом RS-485. Это связано с достаточно высокой дальностью связи до 1,5 км по этому интерфейсу и невысокой стоимостью его реализации. Однако при высокой интенсивности работы контроллеров, например в составе проходных предприятий, скорость передачи информации по интерфейсу RS-485 может оказаться недостаточно высокой. в этом случае используют контроллеры с интерфейсами Ethernet или CAN. Ethernet имеет преимущества по скорости передачи информации в сравнении с CAN. CAN, в свою очередь, имеет преимущества по дальности связи и стоимости реализации.

Подключение считывателей по Wiegand или OSDP (RS-485): что лучше, в каких случаях и почему?

Леонид Стасенко, ДИАМАНТ ГРУПП

Тут даже выбирать не из чего: безусловно, OSDP, являясь достаточно продвинутым протоколом, обеспечивает неоспоримые преимущества плюс большая дальность. А Wiegand просто вынужденно используется в двух случаях: когда контроллеры не поддерживают OSDP (а таких еще на рынке немало), а также когда в систему ставятся дешевые (чаще всего китайские) считыватели, работающие только по Wiegand. Однако, я надеюсь, в скором времени эта ситуация постепенно исправится.

Игорь Ядрихинский, PERCo

OSDP (RS-485) является более современным протоколом и позволяет передавать данные на большие расстояния (до 1 200 м) и с большей скоростью. OSDP также позволяет транслировать данные сразу в двух направлениях, в отличие от Wiegand. То есть контроллер способен проводить проверку работоспособности считывателей, управлять индикаторами считывателей и многое другое. OSDP позволяет размещать несколько считывателей в цепочку на одном кабеле, при этом сохраняется информация о том, какие данные контроллер получает от какого из считывателей.

Wiegand используется в основном для передачи данных на короткие расстояния (до 100 м) – обычно этого расстояния достаточно для подключения считывателей.

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

Вячеслав Петин, АРМО-Системы

Wiegand – довольно старая технология, но из-за своей дешевизны и простоты она до сих пор актуальна и используется на объектах от малых до крупных, хотя и имеет определенные ограничения. Например, при использовании Wiegand длина кабеля ограничивается 150 м, а OSDP обеспечивает расстояние подключения порядка 1 000 м, так как использует интерфейс RS-485. В отличие от Wiegand, OSDP обеспечивает двустороннюю связь, высокую скорость передачи данных между считывателем и контроллером, а также позволяет выполнять такие задачи, как шифрование данных, передача биометрических шаблонов от считывателя к контроллеру, контроль состояния считывателя и др.

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

Максим Горяченков, НВП "Болид"

Главными достоинствами считывателей, работающих по интерфейсу Wiegand, остаются их низкая цена и распространенность. Большинство считывателей на российском рынке относятся именно к этому виду, поэтому подобрать подходящий дизайн при их использовании значительно проще.

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

Главными недостатками решений на OSDP пока остаются более высокая цена считывателей и отсутствие поддержки этого интерфейса в самых распространенных контроллерах на рынке.

Аркадий Гамбург, Семь печатей

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

Благодаря распространенности Wiegand-устройств пользователь имеет большую возможность выбора, в том числе и при замене старых карточных считывателей на биометрические терминалы.

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

Евгений Кондратьев, Равелин

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

Если очень кратко: конечно, OSDP лучше, чем Wiegand, как улица с двусторонним движением по сравнению с односторонним. Да и это еще не все: двунаправленность интересна не сама по себе, а как возможность получения дополнительных функциональных возможностей и по защите интерфейса, и по настройкам считывателей. Однако давайте не будем лукавить. Я пришел в сферу СКУД 14 лет назад, но этот тезис уже тогда был известен на рынке, и даже ранее. Что показывает практика продаж и номенклатура рынка данной сферы? Приборы с OSDP занимали и занимают на рынке долю от 3 до 10%. Это не только мое мнение, я его слышу и от представителей брендов СКУД, у которых есть такая номенклатура. Таким образом, при всех плюсах OSDP сам рынок пока голосует за старый и банальный интерфейс Wiegand. Почему? Это проще и дешевле, и тут добавить больше нечего.

Евгений Белкин, АЛГОНТ

Для идентификации личности в современных СКУД обычно используются идентификационные карточки, брелоки, электронные ключи Touch Memory и устройства биометрического контроля. Наибольшее распространение в связи с невысокой стоимостью, простотой и надежностью работы получили идентификационные карточки. Популярные в РФ считыватели идентификационных карт обычно позволяют работать с контроллером СКУД по четырем типам интерфейсов: Wiegand, Touch Memory, Parsec и RS-485 с протоколом OSDP. Интерфейс Wiegand наиболее старой разработки и к настоящему времени морально устарел. Основные его недостатки – отсутствие двустороннего обмена информацией и большое число проводников.

Наиболее перспективным на текущий момент является интерфейс RS-485 с протоколом OSDP. Он обеспечивает двусторонний обмен информацией со считывателями на расстоянии до 1 200 м и расширенные функциональные возможности по организации защищенного режима и управления индикацией считывателя. Однако контроллеры с интерфейсом Wiegand все еще могут быть востребованы при модернизации существующих СКУД с целью экономии средств за счет сохранения установленных ранее и исправно работающих считывателей идентификационных карт.

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

Леонид Стасенко, ДИАМАНТ ГРУПП

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

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

Игорь Ядрихинский, PERCo

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

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

Вячеслав Петин, АРМО-Системы

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

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

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

Евгений Золотарев, Делетрон

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

Максим Горяченков, НВП "Болид"

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

Аркадий Гамбург, Семь печатей

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

Евгений Кондратьев, Равелин

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

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

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

Евгений Белкин, АЛГОНТ

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

Какие решения есть в отечественных контроллерах СКУД по механизмам внутренних реакций (на аппаратном уровне)? Какие из них наиболее соответствуют современным запросам заказчиков?

Леонид Стасенко, ДИАМАНТ ГРУПП

В вопросе кроется некоторая неопределенность: что считать "механизмами внутренних реакций"? Само по себе решение о допуске или недопуске пользователя уже есть внутренняя реакция.

Уже довольно давно используются механизмы Antipassback, блокировка проходов по внутренним точкам доступа до пересечения периметральной точки (например, до входа на территорию предприятия).

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

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

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

Игорь Ядрихинский, PERCo

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

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

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

Вячеслав Петин, АРМО-Системы

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

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

Евгений Золотарев, Делетрон

Самое простое и самое востребованное – это реакция системы на "пожарный" вход.

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

Максим Горяченков, НВП "Болид"

На сегодняшний день отечественные контроллеры обладают всеми необходимыми внутренними алгоритмами:

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

Аркадий Гамбург, Семь печатей

СКУД – весьма консервативная система. Ее задача, как и тысячи лет назад, – пропускать тех, кто имеет на это право. А прочих – "не пущать".

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

Евгений Кондратьев, Равелин

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

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

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

Евгений Белк