Архитектура СКУД: прошлое, настоящее, будущее

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

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

Первые системы СКУД

Экспоненциальное развитие

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

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

Мультисерверные СКУД

Ethernet

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

Архитектура современных СКУД находится как раз примерно на этом уровне.

Архитектура СКУД с Ethernet

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

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

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

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

Архитектура будущего

Качественный скачок

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

Почему сервер системы не может быть установлен в самом контроллере? Может, если тот обладает соответствующими ресурсами.

Что это даст? Простоту запуска: после установки контроллера достаточно одному из них сказать, что он теперь выполняет роль сервера (мастера), и указать, с какими контроллерами он будет работать. Все, система готова.

"ACaaS: парадигма сервисных моделей в СКУД" читать >>>

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

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

К чему мы должны прийти?

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

1. Турникет + контроллер (или электронную проходную).
2. Карты доступа (отпечатки).

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

Что можно предложить ему, пойдя по предложенному пути развития?

1. Турникет + контроллер (или электронную проходную).
2. Карты доступа (отпечатки).

И — записать IP-адрес, логин и пароль, чтобы просматривать, как работают сотрудники. А другой логин и пароль — для отдела кадров, приема сотрудников и выдачи пропусков. С доступом через любой браузер. Все!

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

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

Что будет дальше?

В дальнейшей перспективе возможности контроллеров будут расти и каждый из них будет этаким стандартным умным "кирпичом".

Перспективы развития архитектуры СКУД

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

Для этого нужно, чтобы стандартизация протоколов, не только на уровне взаимодействия с контролером (например, поддержка ONVIF профиля А и С), но и на уровне взаимодействия систем была поддержана всеми игроками рынка. Пусть даже разработка всеобщего стандарта — дело далекого будущего (если это вообще возможно). Но хотя бы стандартизация взаимодействия на основе REST API и доступ к информации через браузер должны быть реализованы.

Фото: ru.freepik.com