СКУД: Если гора не идет к Магомету.
Проблемы интеграции СКУД в системы автоматизации здания
Преамбула
Дотошный читатель сразу может спросить: почему проблемы интеграции именно СКУД, а не систем безопасности? Ведь СКУД является неотъемлемой составляющей интегрированной системы безопасности, и говорить надо об интеграции систем безопасности с тем, что нередко называют «умным домом», а на языке специалистов – home automation. Частично эта статья посвящена именно разъяснению данного противоречия, а если, забегая вперед, пытаться проводить аналогии, то история может повториться…
… а воз и ныне там
Много в последние годы говорится о проблемах интеграции технических средств жизнеобеспечения зданий, и если в части интеграции подсистем безопасности есть определенный прогресс, то в вопросе более комплексной интеграции с остальными подсистемами (освещение, кондиционирование и так далее) проблемы реально существуют, и прогресс значительно меньше. Пытаясь анализировать причины такого положения дел, нельзя не сказать о ведомственных барьерах. До сих пор на абсолютном большинстве объектов за систему безопасности в целом и подсистему доступа в частности отвечают службы безопасности, а за всё то, что связано с автоматизацией здания, куда мы относим вентиляцию, кондиционирование, освещение, отопление и так далее, отвечает служба эксплуатации здания. Последняя, как правило, обладает немалыми полномочиями, более многочисленна, а, главное, абсолютно не мотивирована к поиску коротких и эффективных путей интеграции с техническими системами безопасности. Служба безопасности, в свою очередь, в стремлении максимально закрыть работу технических средств безопасности (ТСБ) зачастую и слышать не хочет об интеграции с другими системами жизнеобеспечения здания.
Подобные ведомственные конфликты отнюдь не являются чисто российской прерогативой. Примерно такая же картина наблюдается и за рубежом. И это – один из камней преткновения. Об этом говорят и пишут практически непрерывно на протяжении ряда лет, но по сей день данная проблема до конца не решена.
Вторая проблема – больше исторического плана. Связана она с тем, что принципиально сами интеграционные решения разрабатывались разными компаниями с использованием принципиально разных подходов. И на сегодняшний день стыковать эти достаточно сложные комплексы, сделанные на разнородной основе, очень сложно.
Если посмотреть на нижний уровень систем автоматизации зданий для понимания того, с чем предстоит интегрировать системы безопасности, то мы увидим многообразие так называемых «полевых шин». Это LONWORKS, CAN, Profibus, Modbus EIB и некоторые другие. Соответствующие этим шинам стандарты простираются вверх до уровня так называемых прикладных профилей, которые жестко стандартизируют сетевое взаимодействие простых по логике и принципам работы устройств – выключателей, реле, датчиков и прочих элементов, реализующих в конечном итоге систему промышленной автоматизации или автоматизации здания. Практически во всех стандартах исповедуется идеология распределенного интеллекта, когда центральный узел (например, сервер системы на основе ПК), в основном, служит средством программирования и сбора результатов работы системы для последующего анализа, а иногда и для принятия каких-то управляющих решений. В этой архитектуре все устройства принципиально равноправны, соответственно, есть правила, по которым они общаются между собой, есть правила настройки и адресации этих устройств.
Например, выключатель является источником сигнала в такую сеть, а при лампочке может стоять, соответственно, маленькая плата или коробочка, которая является приёмником. Такой приёмник может по сети независимо принимать команды, которые идут от выключателя, от датчика освещённости, или от системы сигнализации. То есть, во всех случаях, лампочка есть лампочка, у неё есть адрес в системе, она способна принимать команды. А кто-то другой способен эти команды выдавать. Бывают и комбинированные устройства, которые могут что-то принимать, что-то выдавать, а в промежутках ещё и производить какие-то вычисления. Например, существуют некие блоки, которые являются связующим элементом между той же самой лампочкой и фотодатчиком. Они могут находиться, например, в плате, которая обслуживает фотодатчик, являясь одновременно приёмником и передатчиком. Принимает информацию от фотодатчика напрямую или по сети, и передаёт её лампочке. Всё это базируется на жёсткой стандартизации, все эти протоколы взаимосвязи источников управляющих воздействий и исполнительных устройств давно и хорошо проработаны.
Корень проблемы
Почему же все-таки даже технически в части интеграции остаются проблемы и чем так уж отличается СКУД от остальных рассматриваемых систем автоматизации? Ведь мы можем себе представить считыватель, который умеет выдать в сеть код прочитанной карты, и замок, оборудованный платой, которая по сети может принять сигнал и открыть замок. Есть гипотеза, что причина в людях. Не в тех, кто создает системы или эксплуатируют их, сидя за мониторами, а в тех, что ходят через двери. Пользователи СКУД являются неотъемлемым элементом системы с огромным многообразием специфических свойств и правил обработки их действий. Как мне кажется, именно это придает системам СКУД ту многомерность, которой нет в простых сетевых топологиях систем автоматизации. И именно реализация функционала, связанного с людьми как элементами системы, и вызывает проблемы при попытке уложить все в простую схему «датчик – исполнительное устройство».
Если вернуться к рассмотрению текущей ситуации, то надо заметить, что попытки скрестить системы безопасности и автоматизации, конечно же, были. Например, в CAN Open года четыре назад был разработан 416 профиль для устройств сигнализации и управления дверями, который пошёл несколько глубже конкурирующих стандартов: в нем закреплено взаимодействие устройств, являющихся компонентами именно систем безопасности — датчиков охранной сигнализации, пожарных датчиков, электрозамков. Более того, в этом профиле описаны процедуры их конфигурирования и настройки. Таким образом, уже существует платформа в ранге стандарта для почти полной интеграции. Слово «почти» использовано потому, что опять же именно люди как элементы системы даже этим самым, на наш взгляд, продвинутым стандартом пока не учтены.
СКУД и SCADA
Любая СКУД, как и любая система автоматизации – это еще и управляющее программное обеспечение, имеющее ярко выраженную прикладную специфику. Разработанные для систем автоматизации так называемые SCADA – системы (это именно верхний уровень, представляющий собой аналог ПО систем безопасности) хороши только для простых устройств. SCADA – систему можно использовать для функций охранной и пожарной сигнализации, но попытки ее средствами реализовать и полный функционал СКУД приводит к тому, что приходится «приспосабливать» к облику и внутреннему устройству SCADА почти все ПО систем доступа – встроенными средствами SCADА требуемый функционал реализовать не получается. Система доступа среди всех систем безопасности является самой интеллектуальной, многообразие её вариантов конфигураций и алгоритмов работы столь широко, что проблема стандартизации всех этих вещей будет решена очень нескоро. Для того чтобы все это стало стандартом, должны договориться хотя бы ключевые игроки этого рынка и производители оборудования. Поэтому, если говорить сейчас об интеграции доступа в систему жизнеобеспечения здания, то можно констатировать всего лишь частичную реальную интеграцию – использование исполнительных устройств (кнопок, замков, датчиков), функционирующих в рамках нижнего транспортного уровня сети. Но сам базовый функционал системы доступа с принятием решений при организации сложных алгоритмов управления точками прохода, построения отчетов вплоть до учета рабочего пока ни в какие рамки стандартизации не ложится.
SCADA-система – вещь достаточно зрелая, хорошо стандартизованная, имеет, вроде бы, достаточно богатый интерфейс, возможность конструирования графических динамически изменяющихся под воздействием чего-то происходящего в системе объектов, то есть, различные анимированные планы. Но опять-таки, её функционал и структура баз данных, характерных для SCADA, не охватывает всех потребностей систем доступа. В это и заключается основная проблема. Поэтому сейчас, говоря об интеграции, приходится довольствоваться какими-то частичными решениями. То есть, система автоматизации здания может использовать некие воздействия в качестве управляющих от СКУД. Для этого достаточно на стандартном контроллере от любого производителя запрограммировать на какое-то событие обычный релейный выход, это реле использовать в качестве контактного датчика уже для системы автоматизации. И на основе этого принимать решения, каким-то образом связанные с действиями системы доступа. Например, с фактором правомерного прохода, неправомерного прохода – в зависимости от того, кому что нужно. Более глубокая интеграция в обозримом будущем пока что не предвидится.
И что же дальше?
Мы нарисовали грустную картину, попытавшись объяснить, почему пока что никто не хочет или не может произвести полномасштабную интеграцию всей электронной инфраструктуры современного здания. И все-таки это не тупик – ведь, как гласит старая пословица: «Если гора не идет к Магомету, Магомет идет к горе». Сегодня уже проявляется тенденция решений, в которых предусмотрено не вхождение системы доступа как составной компоненты в систему автоматизации здания, а наоборот, «подстыковка» системы автоматизации здания к системе управления доступом. Происходить это может очень просто: система безопасности, особенно СКУД, если касаться программного обеспечения, на сегодняшний день является развитой системой с очень богатым функционалом, в том числе и со встроенными механизмами создания программируемых реакций на любые комбинации событий. Сейчас в любой серьёзный софт встраиваются те или иные макроязыки, за счет чего такой софт становится необычайно гибким, превращаясь отчасти в инструмент для создания ПО с новыми свойствами, не заложенными на этапе проектирования. Макроязык фактически представляет собой простой язык программирования системы, когда функционал системы может задавать любой мало-мальски квалифицированный пользователь.
Примером области применения макроязыков в СКУД является формирование сложных точек прохода – тех же шлюзов, которые требуются в центрах эмиссии карт по требованиям VISA и MasterCard. Требования эти достаточно сложные. Шлюз должен в обязательном порядке пропускать только по одному человеку, идентификация производится более чем по одному признаку. Но что такое шлюз? Это дверь номер один и дверь номер два, это датчики, обеспечивающие не только фиксацию присутствия человека внутри шлюза, но и более-менее достоверную проверку того, что человек находится там один. В нашей практике был случай изготовления для одного из банков шлюза с весовой платформой, когда из базы данных системы доступа для человека, поднесшего карту, «вытаскивается» его вес и сравнивается с измеренным с учётом допусков. Допуск по весу учитывает сезонные колебания – по весу одежды, и, кроме того, воздействие естественных для человека похуданий или прибавок в весе. Сейчас сбросить за полгода-год пять килограммов довольно модно. Для полугода такое изменение веса нормально, а вот для недели довольно необычно. Система отслеживает вес сотрудника каждый день, и, соответственно, вносит корректировки в личные данные среднего веса по базе данных. Организация всей этой сложной логики работы кнопок, датчиков, весовой платформы, датчиков дверей, инфракрасных датчиков и так далее, может решаться двумя способами. Можно написать специализированный софт, который будет с учётом его отладки стоить немалых денег, а реализовано это будет в одном- двух или трёх экземплярах. У нас не на каждом углу занимаются эмиссией банковских карт, и реализация подобных шлюзов – это уникальная, штучная работа. За десять лет работы не встречал двух одинаковых заказов с повторяющимися требованиями по логике работы шлюза. Так вот, всё это взаимодействие можно реализовать, используя те самые встроенные макроязыки программирования. Как в Word или Excel есть Visual Basic, который позволяет делать с хорошо известными программами потрясающие вещи – просто мало кто этим пользуется. А позволяет он автоматизировать всё, что поддаётся автоматизации. Именно за счёт встроенного языка программирования, который взаимодействует со средой – с редактором и с таблицей Excel. По аналогии с этим встроенные в ПО систем безопасности макроязыки позволяют реализовать любые алгоритмы взаимодействия между любыми входными и выходными воздействиями. Практически любой современный контроллер СКУД имеет несколько дополнительных входов и выходов, сигналы с них можно интерпретировать, писать на макроязыке правила обработки воздействий в зависимости от дополнительных условий (например, от времени суток), и формировать выходные воздействия не только для управления замком, но и дополнительными выходами контроллера. Если ещё при этом обеспечить аппаратную совместимость контроллеров со стандартными полевыми шинами, результат может получиться еще более впечатляющим.
А почему – бы и не СКУД?Почему мы так подробно остановились на вопросе встроенных языков программирования систем безопасности? Потому, что это и есть путь для интеграции с системами автоматизации. Обеспечив стыковку с «полевыми» шинами (а это не очень сложная работа), мы получаем возможность использовать всю циркулирующую в ней информацию и самим управлять подключенными к шине устройствами. Думается, что в этом направлении интеграционный процесс не только между компонентами системы безопасности, но и со всеми системами жизнеобеспечения, пойдёт быстрее. В связи с тем, что выработка единых стандартов для очень сложных алгоритмов, присутствующих в системе доступа, в обозримом будущем маловероятна, а проблему решать надо, то нам кажется, что дополнительный функционал будет вводиться скорее в ПО системы безопасности. Если посмотреть на решения программных комплексов современных систем безопасности вообще, и СКУД в частности, то во многих из них мы увидим частичную реализацию того, что нужно для полной интеграции с системами автоматизации зданий. На интуитивном уровне к ней уже многие подошли. Более того, ряд производителей систем безопасности уже сегодня явно декларируют для своих систем функционал Home Automation.
И поскольку сегодня заставить пересматривать концепцию жизнеобеспечения зданий при наличии устоявшихся стандартов и сотен производителей оборудования, совместимого с этими стандартами – нереальная задача, нам остаётся с ними только дружить. И это вполне естественный ход событий.
Замки NAPCO Trilogy для контроля доступа с сигнализацией
Как пандемия изменила потребности в контроле доступа
Новые ориентиры в биометрии контроля доступа
SmartBadge | переносной многорежимный трекер | Смарт-бейдж
HID обьявили лидером в отрасли биометрической аутентификации
