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

Прошлое


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

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



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



Настоящее


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

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



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

Дальнейшее развитие архитектуры СКУД


Контроллер как сервер

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

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



Один из контроллеров системы назначается сервером (или мастером, как когда-то), он получает указания, с какими контроллерами он будет работать. Все, система готова. Для работы с удаленными объектами контроллеру, назначенному сервером, дается «белый» IP, он указывается другим контроллерам, и они самостоятельно подключаются к нему. Для интеграции с 1С нужно просто передать в программу адрес контроллера. Для интеграции с системой распознавания номеров – указать в качестве номера пропуска номер автомобиля и IP-адрес камеры или системы, способной распознавать автомобильные номера.

СКУД как сервис

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

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

Будущее


Стандартизация как тренд

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



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

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

Комментарии (5)


  1. oldd
    30.09.2019 15:45

    Статься вызывает много вопросов к автору…

    Контроллер как сервер
    СКУД как сервис

    Вы примерно представляете, как должен работать скуд вкупе с остальными системами (охранка, пожарка, видео)? Например, по пожарным правилам, при пожаре должны быть автоматически открыты все двери на выхд, если человек поднёс карточку к считывателю и скуд определил возможность доступа, то помешение автоматически должно снятся с охраны. Таких мест сопряжения между системами не счесть и рассматривать скуд как что-то отдельное неправильно.
    Ну и как бы использовать wifi и облака просто нельзя, потому что охранка/пожарка/скуд по всем нормам должны быть локальной, чтобы обеспечить невзламываемость и работу 24/7

    Будущее
    Стандартизация как тренд


    Как вы думаете, почему такого до сих пор нет? Я работаю в разработке охранки и т.д более 26 лет, но НИКОГДА не удавалось ничего стандартизировать, ни контроллеры, ни датчики, ничего вообще? Потому что чрезвычайно жёсткие требования по питанию, по цене, жесткая конкуренция и поэтому малейшее ноу-хау может принести много денег и никто знаниями не делится. Состыковать две-три системы, чтобы прокидывать сообщения? На это идут почти все производители… Открыть протокол или начать работать в чужом протоколе? Только если это принесёт много денег и зароет конкурентов. Так что, господа, стандартизация в охранке пожарке /скуде просто невозможна


    1. bigbadmutuh
      01.10.2019 10:16

      ничто не мешает автономным контроллерам иметь ethernet-интерфейс, например. В чрезвычайной ситуации пропадет только связь, но аварийные сценарии работы будут выполняться.


      1. spc
        01.10.2019 11:12

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

        Другое дело, что странно измышления на тему «должно быть стандартизировано» слышать от тех, кто вообще-то должен быть паровозом. Ну раз уж у нас PERCo один из лидеров в СКУД.


        1. bigbadmutuh
          01.10.2019 12:05

          я с perco дела не имел и, наверное, неправильно выразился. Ethernet удобен для передачи конфигурации и сбора информации о состоянии системы. Но в случае пожара или отключения электричества СКУД и пожарная сигнализация должны продолжать автономно функционировать и связь между элементами этих систем должна обеспечиваться отдельными линиями связи, не зависящими от сетевого оборудования. А что касается стандартов, вроде бы же есть ONVIF Profile A.


          1. spc
            01.10.2019 12:21

            Если честно, я бы не удивился, если бы в PERCo про ONVIF в этом ключе вообще не знали.

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

            Вроде этого, наверное, получится
            image