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

Требования к современным программным комплексам управления ИСБ (Часть 2)

В рубрику "Комплексные системы безопасности" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Требования к современным программным комплексам управления ИСБ (Часть 2)

Д.А. Шестаков
Руководитель проекта компании "ААМ Системз"

В первой части статьи (см. СБ № 1, 2007 г.) были рассмотрены требования, предъявляемые к программным комплексам (ПК). Эти требования - надежность, защищенность от НСД и масштабируемость - представляют собой минимальный набор и не гарантируют эффективного взаимодействия пользователя с системой. Во второй части статьи рассматриваются вопросы, связанные с эргономикой и необязательными требованиями к ПК

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

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

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

1. Администратор системы. В обязанности данного пользователя входит:

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

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

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

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

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

4. Сотрудник отдела кадров. Ведет базу данных сотрудников организации. Отвечает за:

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

5. Сотрудник бюро пропусков. Обеспечивает регистрацию посетителей и выдачу им гостевых пропусков. Его основные задачи:

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

Реализация пользовательских приложений
При анализе существующих на рынке ПК для управления ИСБ можно выделить 2 подхода к реализации пользовательских приложений:
1. Для каждой роли или для каждой более или менее крупной пользовательской функции реализуется отдельное приложение (например, "Генератор отчетов", "Учет рабочего времени", "Дежурный режим" - такого рода приложения можно увидеть во многих ПК).
2. Реализуется одно универсальное пользовательское приложение с настраиваемым внешним видом. Пользователь может сам определять состав визуальных компонентов и их расположение на экране; каждая визуальная компонента по отдельности или в совокупности обеспечивает ту или иную пользовательскую функцию (например, список сообщений, дерево конфигурации и т.д.). Первый подход использовался изначально при зарождении программных продуктов для ИСБ. Недостатком данного подхода является то, что оператору приходится обращаться к разным приложениям при изменении решаемых задач, а это требует определенного времени. При такой реализации тяжело обеспечить индивидуальные потребности заказчика, так как в данной ситуации необходимо либо создавать новое пользовательское приложение, либо модифицировать существующее и поставлять его всем остальным пользователям. Второй подход позволяет гибко настраивать пользовательские приложения для решения задач, выполняемых на конкретном рабочем месте. Как правило, визуальные настройки привязываются либо к конкретному рабочему месту, либо к оператору. Если существующие визуаль-ные компоненты не в полной мере удовлетворя-ют потребности заказчика, то разработка новых компонентов не вызовет трудностей. Согласно указанным ролям опишем пользовательский функционал для соответствующих АРМ:

1) АРМ администратора. Для эффективного решения задач администратора АРМ должно обеспечивать:

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

2) АРМ оперативного дежурного. Основное требование к пользовательскому интерфейсу данного АРМ - отображение информации о наступившем событии таким образом, чтобы оператору не нужно было бы производить лишних действий для получения дополнительной информации:

  • в списке планов должна быть возможность автоматического показа графического плана, содержащего аппаратный объект, от которого пришло сообщение (причем после отображения плана объект - источник сообщения -должен находиться в поле видимости оператора и быть выделен);
  • в списке сообщений пришедшее новое сообщение должно попадать в поле видимости;
  • аппаратные элементы, размещаемые на плане, должны иметь пиктограммы, отображающие реальное состояние соответствующей аппаратуры;
  • если в состав ИСБ входит подсистема видеонаблюдения, то при наступлении тревожных событий на соответствующем АРМ должны автоматически выводиться изображения с камер, размещенных в районе возникновения тревоги.

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

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

Далее, поскольку область видимости ограничена размером монитора, а система может быть большого размера как по занимаемой площади, так и по количеству оборудования, необходимо наличие возможности вывода на данном АРМ только значимой для оператора информации:

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

3) АРМ службы безопасности. Для данного АРМ требуется наличие средств получения отчета по различным событиям, зарегистрированным в системе, а также средства для поиска записанных видеофрагментов. При этом необходима реализация следующих возможностей поиска записанных видеофрагментов:

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

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

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

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

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

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

Открытость
Под открытостью понимается возможность расширения функционала программного комплекса путем внедрения новых модулей, реализованных как силами заказчика, так и силами третьих сторон. Такая возможность значима для организаций, имеющих в своем составе IT-подразделение. В этом случае программный комплекс может быть сравнительно быстро и недорого модифицирован разработчиками ПО данной организации. Ограничения по расширению функционала зависят от архитектуры комплекса и возможностей, которые предлагает для интеграции сам разработчик комплекса. Если ПК имеет модульную архитектуру, строился на стандартной технологии с открытым интерфейсом (типа COM, NET, CORBA, J2EE, OPC и т.д.), то это позволяет разработать полноценный функциональный модуль для данной системы (новый драйвер оборудования, специализированное рабочее место и т.д.). Другой вариант, когда разработчик строил комплекс по закрытому принципу, а для интеграции предусмотрел так называемый "программный шлюз", через который можно осуществить интеграцию с комплексом. В этом случае возможности по взаимодействию с комплексом извне, как правило, ограничиваются получением/передачей сообщений, команд управления и вычиткой конфигурации системы. Такого функционала до-статочно, чтобы организовать интеграцию комплекса, например, с информационной системой на объекте, имеющей в своем составе модуль учета рабочего времени. Этот модуль будет рассчитывать время пребывания сотрудников и начислять им заработную плату по данным от си-стемы контроля доступа, полученным через шлюз. Однако внедрить в комплекс дополнительную бизнес-логику вряд ли удастся.

Переносимость (межплатформенность)
Переносимость - это возможность запуска комплекса на разных платформах (Intel, SUN SPARK) и операционных системах (ОС) - Windows, Linux, Unix, Solaris и т.д. Она позволяет использовать комплекс в гетерогенных сетях. Например, если в соответствии с политикой организации для серверов запрещено использование ОС Windows (по соображениям надежности, безопасности), то в этом случае серверная часть комплекса работает под управлением любой другой поддерживаемой операционной системы, а для пользовательских станций может также применяться ОС семейства Windows. Если ПК обладает переносимостью, то возможны 2 варианта реализации:
1) для каждой поддерживаемой ОС существует своя реализация;
2) Общая для всех ОС реализация (например, комплекс написан на Java).
Второй вариант с точки зрения поддержки комплекса и исправления в нем ошибок более предпочтителен: если в логике функционирования комплекса была допущена ошибка, то в случае одной реализации она будет поправлена быстрее, а значит, быстрее устранена у заказчика. В случае существования отдельных реализаций заказчику придется ждать, пока дойдет очередь до исправления ошибки его ОС.

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

  • Надежность:
      - резервирование узких мест в структуре комплекса;
      - обязательное резервирование базы данных комплекса.
  • Защита от НСД:
      - контроль прав операторов на действия в системе;
      - протоколирование действий операторов;
      - контроль целостности системы;
      - защита информационных потоков.
  • Масштабируемость:
      - функциональная и по мощности в рамках системы одного класса.
  • Эргономичность:
      - гибкая настройка внешнего вида пользовательских приложений на рабочих местах;
      - максимальная автоматизация ввода, обработки и представления данных.

Опубликовано: Журнал "Системы безопасности" #2, 2007
Посещений: 10191

  Автор

 

Шестаков М. Ю.

Технический директор SHS-co

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

В рубрику "Комплексные системы безопасности" | К списку рубрик  |  К списку авторов  |  К списку публикаций