Контакты
Подписка
МЕНЮ
Контакты
Подписка

ПО для управления ИСБ: развитие в направлении интеграционных платформ

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

ИСБ
ПО СКУД
ИНТЕГРАЦИОННАЯ ПЛАТФОРМА

ПО для управления ИСБ: развитие в направлении интеграционных платформ

Современное программное обеспечение (ПО) для СКУД все чаще расширяет свой функционал, стремясь предоставить пользователям все больше различных полезных функций, в том числе функций на стыке с другими производителями ПО и оборудования. Такие системы имеют возможности вырасти в более крупный класс, объединяющий сразу несколько областей системы безопасности, – в ИСБ
Алексей Новик
Руководитель проекта LyriX компании "ААМ Системз"

На рынке представлено не так мало интегрированных систем безопасности (ИСБ), так как работа "в одном окне" имеет очевидные преимущества: пользователь учится действовать в одном ПО и привыкает к нему. Рассмотрим несколько отличительных особенностей современных ИСБ, которые представляются как минимум желанными для достижения оптимальных результатов пользователями.

Унификация поддерживаемого оборудования

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

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

Автоматизация

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

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

Произвольные отчеты

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

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


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

Широкие возможности SDK

На данный момент ни одна система ИСБ не покрывает (пожалуй, и не должна) всех требований к системе автоматизации работы предприятия. Например, на большинстве предприятий используются различные ERP-системы, такие как 1С, "БОСС-Кадровик", SAP и др. В них удобно вести картотеку, управлять человеческими ресурсами, вести учет рабочего времени, финансов и многое другое.

ERP-системы

Пользователи ERP-систем могут просматривать информацию в своем ПО, тогда как специалистам по безопасности удобнее использовать ИСБ. Эта задача решается очень просто: производителям ПО для ИСБ необходимо иметь интеграцию с наиболее распространенными на целевом рынке ERP-системами. Необходимо отметить, что одна и та же ERP-система может значительно отличаться на разных предприятиях ввиду различной настройки, а значит, необходима и гибкая настройка интеграции ПО для ИСБ с такими системами.

Использование API

Помимо ERP-систем, развернутых почти на всех предприятиях, существует множество других систем, функционал которых, как правило, недоступен в современных ИСБ: системы алкотестирования и медицинского освидетельствования, учета различного оборудования, используемого персоналом предприятия, системы ячеек хранения и т.д. Их разнообразие не позволяет поставщикам ПО интегрировать все их возможности в свое ПО, и они предоставляют сторонним разработчикам интегрироваться со своей системой посредством использования API (интерфейс разработчика). Последний может иметь различные формы, но наиболее удобным является API в виде Web-сервера, в идеале RESTful. Такой интерфейс позволяет сторонним разработчикам использовать языки программирования и фреймворки на свое усмотрение без каких-либо дополнительных посредников. Предоставление, например, библиотек DLL (Dynamic Link Library) всегда ограничивает разработчиков либо одним из нескольких языков, либо необходимостью использования каких-либо посредников (для использования DLL в среде Java необходимо использовать JNI, JNR или подобные).

Рассмотрим основные возможности API, которые помогут сторонним разработчикам интегрироваться с ПО.

  1. В интерфейсе разработчика необходимо предоставлять функции (CRUD) для работы с базой пользователей, что позволит синхронизировать пользователей между приложениями. Такая синхронизация, как правило, удобна для работы с ERP-системами, особенно если последние существовали до введения ПО для СКУД.
  2. Практически всегда является удобной возможность создавать заявки и пропуска, что позволит интегрировать существующий и привычный для пользователей интерфейс в систему СКУД.
  3. Очень важной функцией является возможность получения сообщений о событиях, происходящих в системе СКУД, – это позволит зарегистрировать произошедшее событие во внешней по отношению к ИСБ системе и выполнить в ней произвольную логику. Здесь отдельно стоит отметить, что желательна способность получать сообщения в реальном времени, а не обычная синхронизация событий, например по расписанию.

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

Работа с большими объемами данных предполагает длительное время обработки. Для минимизации времени ожидания пользователя необходимо применять высокопроизводительные СУБД, ориентированные на подобные задачи, но и этого недостаточно: с учетом большого разнообразия данных часть обработки должна находиться в самом приложении и быть в достаточной степени оптимизирована

Реализация дополнительных функций ИСБ

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

Выводы

В современном мире основными приоритетами любого ПО являются удобство работы пользователя и автоматизация существующих процессов. Для достижения этих целей необходимо выполнение следующих условий:

  1. ПО для ИСБ должно развиваться в сторону унифицированной интеграции наиболее распространенного оборудования, поддержки возможностей интеграции со сторонним ПО и сторонними разработчиками.
  2. Хорошим подспорьем будет команда высококвалифицированных разработчиков, которые станут постоянно поддерживать все новые виды оборудования и ПО.
  3. Ядро системы должно быть достаточно мощным и надежным для решения обширного круга задач.

Опубликовано: Каталог "СКУД. Антитерроризм"-2017
Посещений: 3924

  Автор

Алексей Новик

Алексей Новик

Руководитель проекта LyriX ООО "Компания "ААМ Системз"

Всего статей:  3

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций