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

Обеспечение секретности в советское время в режимных НИИ и КБ осуществлялось с помощью системы пропусков. Пропуск представлял собой бланк (помещавшийся в нагрудный карман пиджака) с наклеенной фотографией, вписанной от руки фамилией, именем, отчеством и рядом служебных отметок для прохода в ту или иную зону, корпус, цех и т.п. Новое, это хорошо забытое старое. Пропуска превратились в проксимити–карты с нанесенными на них фотографиями, но уже цветными; служебные отметки стали уровнями доступа.

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

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

Идеология унификации контроллеров

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

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

Создается единое программное обеспечение (ПО), состоящее из отдельных унифицированных программных модулей. Параллельно разрабатывается и выпускается унифицированная платформа в виде какого–то электронного устройства. В зависимости от того, какой в неё «заливается» программный модуль на выходе получается контроллер, выполняющий различные функции систем безопасности. Это могут быть:

• контроллеры СКУД, имеющие конкретную специализацию – управление различными типами турникетов, шлюзами, лифтами, шлагбаумами и т.д.;

• контроллеры охранной и пожарной сигнализации (ОПС), с функциями присущими приемно–контрольным приборам ОПС;

• контроллеры пожаротушения, т.е. устройства в составе АСУ ПЗ (Ав-томатизированной системы управления противопожарной защитой), осуществляющие управление системами пожаротушения.

• контроллеры управления автоматикой (климат, освещение, подогрев полов, вентиляция и др.).

Используя эту идеологию ЗАО «Легос» разработало и серийно выпускает ряды унифицированных контроллеров серий L3, L6 и L8.

Унифицированный контроллер представляет собой универсальное системное электронное устройство с «залитой» в него конкретной модульной программой протокола ПО Legos. На базе подобных контроллеров можно создавать уникальные по своей структуре и назначению интегрированные системы безопасности любой категории сложности.

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

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

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

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

Техническая реализация унифицированных контроллеров

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

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

1. Производитель выпускает электронные устройства, в которые в своих заводских условиях «закачивает» конкретные модульные программы унифицированного протокола ПО, после чего эти устройства превращаются в унифицированные ряды контроллеров с заданными функциями и техническими параметрами. Потребитель, зная параметры и функциональные возможности приобретает у производителя необходимые ему контроллеры и соответствующее ПО, выполняющее инсталляционные, информационные и эксплуатационные функции.

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

3. Производитель выпускает электронные устройства. В заводских условиях «закачивает» усеченную программу унифицированного протокола. Передает заказчику контроллеры и протокол ПО. У заказчика появляется универсальная платформа бренда, в которую он может записывать самостоятельно необходимые драйвера, видоизменять ПО. Позиционировать и реализовывать как самостоятельный продукт под своим брендом. Использовать в качестве «полуфабриката» для систем безопасности, куда будет прописываться дополнительное ПО с целью согласования между собой систем безопасности различных производителей и создания единого интегрированного комплекса.

4. Производитель под своим брендом, или брендом заказчика выпускает электронные устройства, которые без какого-либо ПО передаются заказчику. Заказчик, являющийся производителем, в своих заводских условиях «закачивает» в контроллеры свои программы. Выпускает контроллеры и ПО, которые объявляет и реализует как свой бренд. 

Картинка: