VIII Международная студенческая научная конференция Студенческий научный форум - 2016

В процессе реализации систем мониторинга и оповещения возникают задачи визуализировать получаемую информацию на центральном пульте.

Для того чтобы понять в каком виде стоит представить данные на экране необходимо понять, как вообще должна отображаться информация для её читаемости без потери качества и скорости восприятия.

Существует довольно много принципов построения графических интерфейсов (GUI), рассмотрим лишь несколько, наиболее подходящих к нашей ситуации:1. Принцип KISS — от английского Keep It Simple, Stupid — графический интерфейс должен быть простым и интуитивно понятным. Не стоит загромождать свой интерфейс.

2. В хорошем GUI необходимо отказаться от действий, которые могут заставить пользователя потратить время на обдумывание

3. Соотношение сигнал/шум — необходимо концентрироваться на сигналах (важных элементах интерфейса) и избегать шумов (ненужных и маловажных элементов для конкретной задачи)

4. Пользователи не любят читать большие объемы текстов, не стоит заставлять их это делать

5. Кошелек Миллера — не стоит перегружать функциональные блоки, 5-7 элементов вполне достаточно, иначе пользователю тяжело извлекать нужную информацию

6. Все важные и необходимые элементы интерфейса должны быть на виду и выделены каким либо образом.

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

Табличная визуализация с подробным отображением

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

 

Рисунок 1

 

Эта информация не занимает много места и может просматриваться без скролла страницы.

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

Визуализация в виде карт и схем

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

 

Рисунок 2

 

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

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

Отображение данных в виде пиктограмм с расширенным функционалом

А как быть когда в одном месте сосредоточенно несколько наблюдаемых объектов? Будь то жилой дом с несколькими наблюдаемыми лифтами, серверное помещение с серверами, офисное здание с отдельными офисами.

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

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

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

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

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

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

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

В нашем случае вся система выглядит так:

 

Рисунок 3

 

Заключение

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

Библиографический список

1. Жарков С. Shareware: профессиональная разработка и продвижение программ / С.Жарков - БХВ-Петербург, 2003: 320с.

2. Правительство РФ СН 512-78 Технические требования к зданиям и помещениям для установки средств вычислительной техники п. 6.5

Код для цитирования: Скопировать