Как спроектировать дашборд для системы промышленного мониторинга

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

Поэтому промышленный дашборд — не просто экран с красивыми графиками. Это рабочий интерфейс, который должен за несколько секунд помочь ответить на несколько вопросов: есть ли проблема, где она возникла, насколько она критична и какие данные нужно изучить подробнее.

Разберём, как спроектировать такой дашборд: какие показатели вывести на первый экран, как расставить приоритеты, показать аварии и пропуски данных и не превратить интерфейс в панель управления космическим кораблём.

Чем промышленный дашборд отличается от обычного

Аналитический дашборд интернет-магазина или CRM обычно помогает изучать результаты за определённый период: сравнивать продажи, конверсии, количество заказов. Пользователь сам решает, когда открыть отчёт и на какие показатели посмотреть.

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

Представим систему из 80 насосных станций. На 79 всё работает штатно, а на одной давление вышло за установленный предел. Если оператору приходится по очереди открывать карточки всех станций, интерфейс не выполняет свою основную задачу.

Хороший дашборд сразу показывает, что проблема одна, указывает объект и помогает перейти к подробностям.

Есть ещё несколько особенностей промышленного мониторинга.

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

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

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

Сначала определить пользователя и сценарии работы

Проектирование промышленного дашборда стоит начинать не с цветов, виджетов или выбора библиотеки графиков.

Сначала нужно понять, кто и зачем будет пользоваться системой.

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

До начала работы над макетом полезно ответить на несколько вопросов:

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

После этого можно описать основные пользовательские сценарии.

Например:

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

Дальше нужно проверить, насколько легко интерфейс позволяет пройти этот путь.

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

Определить иерархию данных

Одна из распространённых ошибок — показать пользователю всё, что система умеет собирать.

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

Для инженера некоторые из них полезны при диагностике. Но это не значит, что все 30 показателей должны находиться на главном экране.

Информацию удобнее разделить минимум на три уровня.

Первый уровень — вся система. Здесь пользователь видит общее состояние: сколько объектов работает штатно, сколько находятся в аварийном состоянии, а с какими нет связи.

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

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

Получается простой маршрут:

Система → объект → параметр.

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

Так пользователь сначала получает информацию для принятия решения и только после этого — подробности.

Что разместить на главном экране

Универсального набора виджетов для промышленного дашборда нет. Главный экран системы мониторинга скважин и интерфейс учёта электроэнергии будут различаться.

Но принцип у них общий: первый экран должен отвечать на вопрос «Где сейчас требуется моё внимание?»

Обычно на нём полезно показать:

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

Приоритет должен быть у исключений, а не у нормы.

Представим, что система контролирует 150 объектов. На 145 всё работает штатно, три требуют внимания, ещё два перестали передавать данные. Нет смысла занимать почти весь экран 145 одинаковыми зелёными карточками. Полезнее сразу показать пять объектов, которые отличаются от нормального состояния.

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

Главный экран в этом случае работает как навигатор: показывает картину целиком и помогает быстро выбрать место, которое нужно изучить подробнее.

Как показывать норму, предупреждение и аварию

Цвет помогает быстро распознавать состояние, но не должен быть единственным способом его определить.

Если зелёная карточка означает норму, жёлтая — предупреждение, красная — аварию, пользователь должен понимать это и без цвета.

Например:

Норма · 72 °C

Предупреждение · 88 °C

Авария · 104 °C

Нет данных · последнее обновление в 14:32

Здесь состояние передают сразу несколько элементов: цвет, текстовая подпись и значение.

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

Не стоит заливать зелёным всё исправное оборудование. Если в системе 100 объектов и 98 из них находятся в норме, десятки ярких зелёных блоков конкурируют за внимание с двумя действительно важными.

Нормальное состояние можно оформить нейтральнее, а предупреждения и аварии сделать заметнее.

Отдельное состояние понадобится для отсутствующих данных. Показание 0 бар и сообщение «Нет данных с 14:32» означают принципиально разные вещи. Интерфейс не должен превращать отсутствие измерения в нулевое значение.

Как проектировать графики телеметрии

График нужен не потому, что на дашборде принято размещать графики.

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

Допустим, оператор анализирует температуру оборудования. Для примера возьмём условные пороги:

• нормальное значение — до 80 °C;
• предупреждение — выше 80 °C;
• авария — выше 100 °C.

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

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

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

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

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

Нужно отдельно продумать пропуски данных.

Допустим, датчик передал значение в 11:00, потом три часа не выходил на связь и снова отправил измерение в 14:00. Если просто соединить две точки линией, интерфейс визуально сообщит, будто система знает, что происходило между ними.

Лучше показать разрыв.

Принцип простой: нет измерения — нет линии.

Как показывать проблемы со связью

Если система не получила очередное значение, причина не обязательно находится в самом датчике.

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

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

Рядом можно показать:

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

Например:

Нет связи

Последние данные: 18 августа, 16:24
Нет новых показаний: 2 ч 17 мин

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

На удалённых объектах данные, например, могут передаваться через gprs модем. Поэтому отсутствие свежих показаний ещё не доказывает неисправность измерительного устройства: сначала нужно понять, на каком участке перестали поступать данные.

В интерфейсе эти состояния лучше разделять. «Параметр превысил порог» и «параметр неизвестен» — разные события и требуют разной реакции.

Карта или список: как показывать много объектов

Карта выглядит эффектно, но нужна далеко не каждому промышленному интерфейсу.

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

Если расположение почти не влияет на работу, таблица или список часто удобнее.

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

Для больших списков стоит предусмотреть поиск и фильтрацию. Например, можно оставить только:

• аварийные объекты;
• объекты с предупреждениями;
• устройства без связи;
• определённый тип оборудования;
• конкретный участок или группу.

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

Поэтому вопрос должен звучать не «что нагляднее — карта или таблица», а «какое представление быстрее решает задачу пользователя».

Иногда нужны оба варианта с возможностью переключения.

Не путать «нет данных» с «оборудование сломалось»

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

Например:

56 °C — норма.

87 °C — превышен порог предупреждения.

104 °C — превышен аварийный порог.

Нет данных — устройство не передаёт показания.

Ошибка данных — система получила значение, которое не может корректно обработать.

Данные устарели — последнее измерение получено слишком давно.

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

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

Причины пропусков телеметрии тоже могут различаться. Если объект использует мобильную связь, на передачу данных может влиять не только состояние модема или сети, но и установленная gprs антенна. Для интерфейса причина вторична: главное — не маскировать отсутствие актуального измерения под нормальное числовое значение.

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

Как не перегрузить интерфейс

Промышленная система может собирать много данных. Но вместить их на один экран — не цель дизайнера.

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

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

Информационная иерархия должна делать часть этой работы за него.

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

Так же стоит обращаться с визуальными элементами.

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

Каждый блок должен отвечать на конкретный вопрос.

Например:

«Есть ли аварии?» — блок статусов.

«Где проблема?» — список объектов.

«Что произошло с параметром?» — график.

«Когда последний раз приходили данные?» — отметка времени.

Если назначение элемента невозможно сформулировать одним предложением, стоит проверить, нужен ли он на этом экране.

Нужно ли адаптировать промышленный дашборд под смартфон

Адаптивная версия нужна не ради соответствия модному подходу mobile first, а под конкретный сценарий работы.

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

На планшете инженер может открывать карточку оборудования непосредственно на объекте.

На смартфоне сценарий обычно ещё уже: получить уведомление, проверить состояние объекта, посмотреть основной показатель и понять, нужно ли действовать.

Необязательно помещать на телефон уменьшенную копию десктопного дашборда.

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

Полезнее проектировать не одинаковые экраны, а одинаково понятный путь к нужной информации.

Типичные ошибки при проектировании промышленного дашборда

1. Вывести на главный экран все доступные параметры. В результате критичные данные теряются среди служебных. Нужно определить минимальный набор показателей для первого уровня, а остальные перенести в карточку объекта.
2. Передавать состояние только цветом. Красная и зелёная карточки без подписей заставляют пользователя помнить легенду и хуже работают при нарушениях цветовосприятия. Цвет лучше дополнять статусом, иконкой или текстом.
3. Сделать все элементы одинаково заметными. Если серийный номер устройства и аварийное давление оформлены одинаково, интерфейс не показывает приоритет. Визуальный вес должен соответствовать важности информации для текущей задачи.
4. Не показывать время обновления. Значение «72 °C» само по себе ничего не говорит об актуальности. Это может быть измерение минутной или трёхдневной давности. Для мониторинга время последнего получения данных — часть показателя.
5. Считать отсутствие данных нулём. Ноль — это измерение. Отсутствие данных — состояние системы. Их нельзя подменять друг другом.
6. Перегрузить экран графиками. Пять графиков не всегда информативнее одного. На первом уровне лучше показывать только визуализации, необходимые для оценки состояния, а подробную аналитику оставлять внутри объекта.
7. Использовать карту там, где удобнее таблица. Если пользователю нужно сравнивать значения и сортировать объекты, карта может только замедлить работу. Географическая визуализация оправдана тогда, когда местоположение влияет на решение.
8. Спрятать аварии среди обычных уведомлений. Сообщение о превышении критического порога не должно конкурировать с информацией об успешном входе пользователя или плановом обновлении системы. События стоит разделять по приоритету.
9. Проектировать интерфейс без рабочих сценариев. Можно нарисовать аккуратный дашборд и обнаружить, что диспетчеру требуется семь действий, чтобы найти причину аварии. Проверять нужно не отдельные экраны, а последовательность действий пользователя.

Чек-лист перед передачей дашборда в разработку

Перед финализацией макета полезно пройти основной рабочий сценарий и проверить интерфейс.

1. За несколько секунд понятно, в каком состоянии находится система.
2. Аварии и предупреждения заметны среди штатных объектов.
3. Авария отличается от отсутствия связи и отсутствия данных.
4. Видно, когда информация обновлялась последний раз.
5. У всех числовых показателей указаны понятные единицы измерения.
6. Пользователь понимает допустимый диапазон там, где он важен.
7. Из общего состояния можно быстро перейти к проблемному объекту.
8. Критичная информация не теряется среди служебных параметров.
9. Статусы можно распознать не только по цвету.
10. Пропуски телеметрии корректно отображаются на графиках.
11. С большим количеством объектов можно работать через поиск, фильтры или сортировку.
12. Основные сценарии проверены на тех устройствах, которыми будут пользоваться сотрудники.

Если на несколько пунктов приходится отвечать «формально да, но пользователю нужно разобраться», интерфейс стоит упростить до передачи в разработку.

Главное

Хороший промышленный дашборд — не тот, на котором удалось разместить максимум телеметрии.

Его задача — помочь быстро перейти от общего состояния системы к конкретной проблеме и данным, необходимым для решения.

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

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