Развитие ПО для систем контроля доступа. Современные тенденции

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

  • не так обязательна, как охранно-пожарная сигнализация. В случае выхода из строя компьютера с программным обеспечением аппаратура имеет свой автономный режим, а уж если и она сломалась, то можно перейти либо на ручной режим управления, либо просто открыть двери механически;
  • не так популярна и не так раскручена, как очень привлекательное внешне CCTV;
  • оперирует большим объемом данных (сотрудники, карты, события, отчеты);
  • зачастую "контактирует" с другими ИT-реше-ниями предприятия: кадрами, бухгалтерией, решениями типа "столовые".

Общие характеристики рынка ПО для СКУД/ОПС/CCTV

Сам по себе рынок весьма небольшой, чтобы заинтересовать крупные софтверные компании. Фактически на сегодня каждая компания-разработчик контроллеров самостоятельно пишет поддерживающее ПО. Стоит также отметить, что на данный момент практически не развиты стандарты на функции той или иной аппаратуры (единственное исключение – CCTV, где есть попытки стандартизации протоколов). Отдельно стоит отметить общее отношении к ПО: заказчики гораздо охотнее готовы платить за реальное изделие (камеру, контроллер, считыватель), чем за "виртуальное ПО", к тому же немалой стоимости. Еще меньше развита культура покупки ПО в нашей стране. В результате разработка ПО остается "дотационной" на средства от продажи "железа".

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

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

Тренд интегрированности ПО

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

С одной стороны, идея смотрится очень привлекательно – все под управлением одного софта, все обращения, если что, к одному производителю. Нет проблем с рассинхронизацией внутренних интерфейсов.

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

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

Какая интеграция реально нужна?

Под интеграцией можно понимать довольно разные подходы. Вопрос: какая интеграция должна быть самой оптимальной?

С одной стороны, ответ прост – все должно быть под управлением одного софта и работать как надо. С другой стороны, есть моменты, которые было бы неплохо рассмотреть/уточнить.

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

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

Единый разработчик
Хорошие моменты единого разработчика мы уже рассмотрели – если что, обращаемся к одной компании, не сможет сказать "а это не из-за нашей части, а из-за чужого оборудования/софта". Но также могут быть и отрицательные моменты:

  1. Единый поставщик практически никогда не имеет одинаково сильных позиций по всем направлениям систем безопасности.
  2. Используя решение "все от одного поставщика", вы остаетесь очень сильно привязанными к нему. Гораздо сложнее будет перейти полностью или частично на решения других производителей.
  3. Ограниченный ассортимент – возможно, в случае использования интегрированных решений у компании-поставщика может не оказаться продуктов с нужными функциями.
  4. Дополнительные функции в интегрированном решении могут стоить больше, чем в аналогичных, но не интегрированных решениях.

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

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

Тренд "все через IP"

С точки зрения контроля доступа IP по большому счету является всего лишь еще одним возможным транспортным уровнем. Интересной новой возможностью, которую добавляет использование IP, является построение взаимодействия контроллеров "каждый с каждым". Семейства протоколов 485/232 обычно строятся по принципу "главный – подчиненные", поэтому в устройствах на этих протоколах такие взаимодействия сделать было невозможно.

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

Такая архитектура имеет несколько моментов:

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

Контроллер доступа становится "небольшим компьютером"

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

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

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

К тому же скорее всего более продвинутой и мощной станет подсистема внутренней аппаратной автоматизации, работающей в самих контроллерах.

Еще одним интересным бонусом становится возможность запуска в контроллере небольшого HTML-сервера, который позволит довольно просто производить базовые операции администрирования и настройки контроллера без использования внешнего ПО – только при помощи стандартного Web-клиента. Это, конечно же, значительно упростит обслуживание систем.

Тренды и пути развития ПО для СКУД

Внутри собственно ПО для СКУД можно отметить следующие тенденции.

  1. Если первоначально решения разрабатывались как монолитные приложения, одновременно опрашивающие панели и реализующие интерфейс пользователя, то современные средства уже гораздо надежнее, имеют выделенный сервер и клиентские приложения.
  2. Комплексы второго поколения также обычно уже имеют архитектурно-выделенные объекты ядра и драйверов оборудования. Таким образом, с помощью гибкого конфигурирования комплекса под определенного заказчика возможна относительно простая разработка других драйверов без вмешательства в ядро.
  3. Конечно же, серьезные решения не могут обойтись без серьезной системы разграничения прав на объекты оборудования, документы. Основная проверка прав должна осуществляться на сервере, при поступлении клиентских запросов. Другая часть проверки прав зачастую требуется дополнительно для ограничения клиентских команд оператора.
  4. Безусловно, система проверки прав должна дополняться настройкой аудита действий операторов с возможностью дальнейшего построения отчетов (кто куда пытался залезть или что выполнить).
  5. В более продвинутых системах права и аудит можно настроить не только для физических операторов комплекса, но и для драйверов, которые обслуживают оборудование. Это будет дополнительной защитой от возможного некорректного поведения драйверов.

Развитие удобства использования

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

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

Современное ПО стало "самообслуживаемым" – умеет автоматически удалять старые сообщения/видеофрагменты из базы, поддерживая стабильный размер файла базы данных, улучшая производительность серверов SQL. В случае различных тревог или нестандартных ситуаций ПО позволяет отсылать уведомления администратору по электронной почте. Если требуется получать определенные отчеты на регулярной основе, то такая функция может быть однажды сконфигурирована, и в дальнейшем нужные отчеты будут высылаться нужным адресатам по заданному расписанию.

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

Открытость для интеграции

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

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

Источник: Журнал "Системы безопасности" #5, 2010

Картинка: 
ПО