Автор: Владимир СТАРОСТИН, директор дивизиона НИОКР компании Perco
Развитие архитектуры СКУД
Давайте сначала определимся, что мы вообще понимаем под определением «архитектура СКУД». ГОСТ предлагает такой вариант: «Архитектура системы контроля доступа – это принципиальная организация системы, воплощенная в ее элементах и их взаимодействии друг с другом и со средой, а также принципы, направляющие ее проектирование и эволюцию». То есть то, что мы закладываем в систему изначально, должно нам позволять развивать ее в дальнейшем в соответствии с развитием среды: IT-технологий, требований законодательства, рынка. Как решает эту задачу разработчик? Ведь именно он определяет архитектуру создаваемой системы, исходя из своих задач и технических решений, которые ему доступны. В идеальном случае при идеальном разработчике ограничивающий фактор только один – технические решения. Давайте попробуем вспомнить, как развивалась СКУд за последние 25-30 лет. Начало 90-х годов: был мастер-контроллер, который управлял всеми устройствам, хранил всю базу. Фактически вся архитектура строилась на нем. Да, был еще компьютер, но для чего он был нужен? Только для того, чтобы отобразить данные, полученные от мастер-контроллера и дать возможность задать какие-то параметры работы. Что произошло дальше? Дальше появились компьютерные сети. Они стали бурно развиваться, появилось огромное количество решений, основанных на сетевом взаимодействии между компьютерами. Все производители СКУД были вынуждены как-то реагировать на открывшиеся технические возможности. Создали локальные серверы, которые обеспечивали работу все с тем же мастер-контроллером. Появились интегрированные решения, которые взаимодействовали с ОПС, видеонаблюдением. Да, серверы взаимодействовали между собой на базе Ethernet, но взаимодействие с оборудование происходило по старому, доброму RS-232. Контроллеры никак не развивались. Что произошло дальше? Начали создаваться контроллеры с возможностью нормальной работы с Ethernet. Каждый контроллер стал относительно самостоятельным, чтобы принимать все необходимые для работы системы решения, ему не нужен мастер-контроллер. Он делает все сам. ПО можно было устанавливать практически на любом компьютере. Что нас ждет в будущем? Представьте, что сервер СКУД мы изъяли. Для чего вообще он нужен? Для того, чтобы выполнять какую-либо бизнес-логику – хранить и отображать данные. Представьте, что мы переместим эту логику в контроллер. Сейчас мощности для этого достаточно, ведь большинство микроконтроллеров превосходят по мощности те компьютеры, которые использовались в 90-е. То есть ничто не мешает размещать сервер внутри контроллера. Контроллеры в этом случае смогут между собой общаться и выполнять все бизнес-логики. Компьютеры используются только для отображения информации. С точки зрения организации системы все упрощается. Что нужно клиенту сейчас? Он должен сейчас приобрести контроллер, идентификаторы, исполнительные устройства и предоставить компьютер для сервера. Подумать, куда его поставить, кто его будет обслуживать. Новый же путь развития СКУД убирает из этой цепочки сервер, клиенту нужно будет просто указать, какой контроллер будет «главным», и сообщить его данные. Чтобы обслуживать такую СКУД, даже не надо ехать на объект, все можно сделать удаленно. Доступ к контроллеру-серверу осуществляется через веб-браузер или специальное приложение. Закономерно возникает вопрос: сможет ли такой контроллер обслужить систему, например, в 50 тысяч человек и 300 контроллеров? А сколько у нас таких систем? Да, текущий уровень развития контроллеров не позволит организовать стабильную систему. Но предлагаемая схема не исключает использования выделенного сервера. Большим компаниям в целом не так важен фактор сервера, можно использовать и его. А что будет дальше? Хотелось бы, чтобы все устройства в СКУД стали «умными». Чтобы для работы с ними не нужен был выделенный компьютер, чтобы контролеры могли общаться друг с другом, и не важно, кто их разработал и произвел. Тут возникает вопрос унификации, унифицированного протокола взаимодействия. Да, попытки предпринимаются, но пока это – очень медленный процесс. Я понимаю, что добиться какого-то глобального стандарта в области взаимодействия контроллеров будет сложно. Но хотя бы нужно добиться того, чтобы стандартом был Ethernet, чтобы стандартом было использование web-soсkets, то есть то, с чем работает любой системный программист и интегратор. И чтобы для каждого контроллера был доступен какой-то sdk. И этот sdk был оформлен в стандарте RSTP. Это уже давно стандартные вещи для IT, и всем было бы проще. Имея все это, любой программист или интегратор сможет собрать все «кирпичи» в единую систему, которая решала бы задачи именно этого объекта. Не нужны прослойки, которые что-то куда-то конвертируют и потом уже передают. В заключение хотелось бы сказать, что развитие архитектуры должно быть основано на развитии умных частей системы. Все ARM – это надстройки, нужные только для отображения информации. Цементировать эти «кирпичики» должен какой-то унифицированный протокол, общепонятный и признанный. По материалам конференции СКУД 2019. Редакция благодарит компанию Sigur за помощь в подготовке статьи.
Внимание! Копирование материалов, размещенных на данном сайте допускается только со ссылкой на ресурс http://www.tzmagazine.ru