Контроль доступа (скд, скуд)

СКУД на основе локальной сети с комплексной IP-периферией

Журнал ТЗ №2 2009

Объединение через существующую сеть систем, отвечающих за контроль здания, жизнеобеспечения, общее управление предприятием, решающих задачи менеджмента, кадровой службы и т. д., в единую систему и глобализация в этом направлении приводят к тому, что ТСБ как таковые рассматривать в разрезе конкретного предприятия со временем будет все сложнее и сложнее. Видимо, не так уж и далек тот день, когда ТСБ будут являться лишь одной из составляющих общей информационно-управленческой системы объекта. Очень важной с точки зрения решаемых ее задач. Но изначально конечный пользователь будет рассматривать ТСБ как одну из многих систем, и не более того. И это, я считаю, неплохо.
Главная тенденция в аппаратной реализации новых решений прежде всего в области СКУД – это разработка новых контроллеров, в которых в аппаратную часть интегрируются необходимые для работы с Ethernet-сетями интерфейсы. То есть речь идет о популярных протоколах Ethernet, таких как Ethernet (TCP/IP) и HTTP, и различных способах защиты этих протоколов. Прежде всего стоит отметить возможность установки между контроллером и сервером VPN-соединений через защищенный SSL-протокол. Речь идет не о возможной модернизации существующих контроллеров путем установки на них необходимых чипов и интерфейсов для создания, например, виртуального com-порта, а о полноценной интеграции контроллеров доступа в сеть путем реализации программной и аппаратной части на стороне контроллера для интеграции контроллера в сеть как полноценного IP-устройства. Кроме того, неотъемлемой частью IP-СКУД (это понятие аналогично IP CCTV употребляется все чаще и чаще, что тоже характерно) будут являться вэб-браузеры, реализованные на стороне контроллеров. Это позволит использовать в системе технологию так называемого тонкого клиента, что, в свою очередь, дает возможность получать информацию, просматривать сообщения, события, конфигурацию любого контроллера, выходя в сеть через стандартный вэб-браузер с любого мобильного устройства. Нет необходимости ставить стационарное рабочее место, защищенное аппаратным ключом, достаточно, например, через ручной коммуникатор войти в сеть, набрать необходимый код и в зависимости от имеющихся у вас полномочий получить возможность просматривать работу того или иного контроллера.
Сразу скажу, всё это не является научно-технической фантазией. В ряде имеющихся на рынке систем эти возможности реализованы и с успехом используются. Еще одна инновация на рынке – организации одноранговых peer-to-peer-соединений между контроллерами СКУД, находящимися в сети. Безусловно, для этого необходим соответствующий программный инструментарий как на сервере, так и на контроллере. Причем на контроллере, скорее всего, должно быть установлено специализированное ПО под ОС Linux. Наличие такого инструментария позволяет контроллерам после предварительного программирования общаться между собой и взаимодействовать вне зависимости от того, есть ли связь с сервером. Все необходимые предустановленные конфигурации, варианты поведения, реакции системы на то или иное внешнее воздействие будут отрабатываться и сохраняться даже при отсутствии связи с центральным сервером. При восстановлении связи информация, накопленная на локальных контроллерах, будет синхронизироваться с сервером. Но на уровень защищенности системы, на ее работоспособность наличие или отсутствие в системе сервера влиять никоим образом не будет.
Технология эта пока не особенно распространена по ряду причин. Одна из них, на мой взгляд, заключается в общей инертности рынка ТСБ как такового. В настоящий момент в системах безопасности доминируют IP-решения в охранном телевидении. Основной задачей в них является односторонняя связь в системе (конечно, без учета телеметрии), то есть получение информации с IP-камеры, к примеру, на видеорегистратор, дальнейшая обработка и просмотр полученной информации. Вопрос плотного взаимодействия камер между собой не ставится. Проблематика защиты объекта с точки зрения СКУД выглядит несколько иначе. При наличии тревожных сигналов в одной части системы, особенно это актуально, если система – территориально распределенная, основная задача состоит в том, чтобы правильно отреагировала другая ее часть. Самый простой пример: при возникновении тревоги, скажем пожарной, система должна подать в другие помещения или здания сигнал разблокировки дверей, турникетов и т. д. В настоящее время в большинстве распределенных сетевых систем диспетчером взаимодействия контроллеров является компьютер, т. е. центральный сервер. Получая информацию о тревожной ситуации, он анализирует ее и посылает в контроллер, отвечающий за работу с нужными турникетами или дверями, соответствующий сигнал о разблокировке. Правильная организация работы по сети позволяет убрать как самое ненадежное звено компьютер (сервер), заранее запрограммировав в контроллерах необходимые реакции После этого самое главное, чтобы между контроллерами была связь по сети. В таком случае при любом состоянии сервера все запрограммированные сценарии будут четко отработаны.
Это решение нельзя назвать каким-то очень серьезным прорывом. Будем справедливы: первый прорыв сделали те, кто начал заниматься IP-видеонаблюдением. Это лишь грамотная оптимизация новых сетевых технологий под задачи СКУД.
Речь идет о том, что современная ТСБ должна поддерживать индустриальные сетевые стандарты, поддерживаемые производителями не только систем безопасности, но и сетевого оборудования. Наличие стандартизованных сетевых протоколов, общепринятых стандартов будет позволять вне зависимости от наличия сервера на любом объекте грамотно организовывать взаимодействие различных IP-устройств. Уже сейчас это практикуется в серьезных системах. На «интеллектуальном уровне» самих этих устройств. То есть без участия сервера контроллер обращается к камере, включает ее, поворачивает, принимает от датчика тревожный сигнал, открывает турникет. Сам по себе подобный функционал реализован сегодня во многих СКУД. Но зачастую только в пределах некого закрытого интерфейса конкретного производителя, естественно, со своим собственным протоколом. Если же речь идет о координации работы офисов в разных странах, да хотя бы на разных улицах в одном городе, то работа по протоколу Ethernet, работа с LAN и WAN сетями – шаг к глобализации услуг по обеспечению работы здания. Не исключено, что следующим шагом будет так называемая большая кнопка или единый пульт, который так любят в системах типа «умный дом», где для заказчика в качестве основной части его системы позиционируется панель, где он может нажимать кнопки. Все остальное система делает сама, без какого-либо участия пользователя.
Все идет к тому, что создатели большинства систем (будь то системы безопасности, управления предприятием и инженерией здания, жизнеобеспечения и т. д.), пользуясь базовыми сетевыми протоколами, будут идти навстречу друг другу, чтобы, в конце концов, создать универсальные модули, из которых грамотный инженер сможет, как из кубиков, быстро построить эффективную информационно-управленческую систему для обслуживания всего здания.
Победит тот, кто правильно оценит свои возможности по реализации новых программных и аппаратных продуктов и вовремя поймет, в какую сторону движется рынок промышленных сетевых стандартов. Это – естественный путь развития. Как переход от автомобильных карбюраторов к прямому впрыску.
Это – качественно новый уровень СКУД. Еще одно свидетельство наступления на рынок безопасности рынка IT.
Преимущества, которые дают подобные решения, совершенно очевидны. Это прежде всего сокращение затрат на инсталляцию. Изначально проложив на объекте сетевую трассу, вы решаете вопрос возможности необходимого распределения оборудования СКУД по вашему объекту больше. Далее – есть возможность интеграции с другими системами, работающими в сети на предприятии. Кроме того, работа по сети Ethernet позволяет при наличии необходимой программно-аппаратной базы оперативно реконфигурировать систему при каких-то изменениях на объекте: смене режима и тактики охраны, перестройке объекта.