Дизайн HMI для АСУ ТП с подходом WSA

“В случае с HMI фраза «Красота спасет мир» не работает”

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

Здравствуйте! Меня зовут Владимир Бойков, я UX/UI-дизайнер, разработчик интерфейсов для АСУ ТП. Мой сайт (https://scada-disygn.ru).

Я поэтапно опишу процесс разработки, приводя цитаты из статьи и применяя их на практике.

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

“Если экран в серых тонах — значит, всё хорошо, появился другой цвет — это авария, которая требует реакции оператора.

Цвета используются только для привлечения внимания к аварийным ситуациям, а не для визуализации нормального состояния оборудования (клапан открыт/закрыт, двигатель включен/выключен и т. п.).”

“Чем быстрее оператор локализует аварию, тем лучше операторский интерфейс.”

В качестве ТЗ (технического задания) выберу мнемосхему в Яндекс картинках по запросу «Мнемосхемы для АСУ ТП» и переработаю ее, используя вышеуказанные подходы для панели оператора Weintek с разрешением экрана 1024х768px, поскольку это сенсорная панель, при разработке кликабельных элементов будем это учитывать.

Итак, заходим в Яндекс, вводим наш поисковый запрос и смотрим выдачу.

Здесь мы увидим много разных схем с буйством красок и библиотечными 3D-элементами из SCADA.

Немного полистав вниз, выбираю эту мнемосхему:

Она несложная, поэтому отлично подойдет в качестве демонстрации.

Главный вопрос при разработке интерфейса — кто будет с ним работать? (Варианты: оператор, наладчик, инженер). Получив на него ответ, (в нашем случае - это оператор или диспетчер), переходим к вопросу номер 2.

Вопрос 2

Какие задачи должен решать оператор, взаимодействуя с интерфейсом? Наиболее очевидные ответы:

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

На основании подхода Wonderware Situational Awareness сформулируем требования к интерфейсу для оператора:

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

1. Статичные (фон, заголовки, названия параметров, изображения узлов, агрегатов);

2. Динамичные (переменные, анимированные изображения, графики, информационные сообщения);

3. Элементы управления (кнопки, поля ввода значений, ссылки, тумблеры, переключатели).

1. Остановлен

2. Нормальная работа

3. Предупреждение

4. Авария

5. Активен (при клике выполняется команда. Относится к элементам управления);

6. Неактивен (при клике не происходит ни каких действий).

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

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

Проделав данную работу, получаем следующие блоки

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

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

Давайте разбираться.

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

Для людей с отклонениями по зрению необходимо соблюдать Рекомендации по обеспечению доступности веб-контента (WCAG) 2.0 и целевой уровень AA из раздела 1.4.3, чтобы визуальное представление текста и изображений с текстом имело коэффициент контрастности не менее 4,5 : 1.

Это позволит с уверенностью использовать систему и улучшит юзабилити продукта.

Для этого важно использовать стандарт создания тона, например, цветовую модель HSL.

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

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

Находим оттенок серого, который даст нам одинаковую контрастность (4,5 : 1) как на белом, так и на черном фоне. Это соответствует уровню AA стандартов доступности WCAG для минимального контраста, и таким оттенком является #757575.

Теперь с помощью специального сервиса мы получим остальные 8 тонов в сторону белого и черного цветов, с шагом 20%. Но перед этим кое-что изменим: к выбранному оттенку серого добавим немного синего цвета. Из своего опыта знаю, что интерфейсы, сделанные в чисто серых тонах, смотрятся грязно и мрачновато, присутствие синего сделает цвет чище и свежее.

Вот так они выглядят, для сравнения. Цвет #81858В имеет ту же контрастность по отношению к черному и белому, что и #757575.

Получаем шкалу тонов

Тон, который мы взяли за основу, находится по центру нашей шкалы.

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

Шкала имеет 11 тонов от 00 (белый) до 100 (черный) между ними получим 9 оттенков серого. Используя стандартный подход, дадим им название от Grey 10 до Grey 90. Для лучшей наглядности и удобства в работе, сделаем небольшую спецификацию для нашей шкалы, где укажем название тона, его значение в шестнадцатиричной системе, а также минимальный по доступности к нему тон (стандарт АА, с контрастностью 4,5:1).

Проделаем это для каждого элемента шкалы и получим такую спецификацию.

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

Итак, нахожу оттенок красного, который имеет одинаковый контраст по отношению к черному и белому, это#EE0000

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

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

Как упоминалось выше, в дальнейшей разработке мы окажемся в ситуации, когда тонов основной шкалы будет недостаточно. Далее опишу, почему и как нужно расширить систему в определенном диапазоне. Снова обращаемся к web-севису по работе с цветом и задаем в настройках генерации палитры крайние значения Grey 10 и Grey 20 с шагом 20%. Получив результат в виде 4-х промежуточных тонов, проводим их именование по нашей схеме Grey 12, 14, 16 и 18 соответственно.

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

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

Напомню, что в нашем случае используется панель оператора Weintek разрешением 1024х768рх и сенсорным управлением. Она имеет меньшее пространство экрана, чем экран исходника, к тому же, элементы управления для сенсорных панелей должны иметь минимальный размер 30х30рх, комфортным считается 40х40рх. Полагаю, что в рамках данного проекта, боковое расположение меню будет более удобным и рациональным с точки зрения использования пространства. Учитывая все выше сказанное, получаем экран с разметкой под меню.

Ширина меню 210рх, размеры кнопок 140х50рх. Дату и время размещаю в верхней части блока и добавляю к ним иконки, чтобы визуально отделить их от пунктов меню и улучшить восприятие.

Я использую светлую тему, как показывает практика, ее предпочитают большее количество пользователей.

Основным оттенком фона будет Grey 10, он более приятен для глаз, чем чисто белый. Блок меню сделаем оттенком Grey 80, чтобы выделить его на фоне основного экрана. Активный пункт меню будет также Grey 10, это делает навигацию более понятной и не требует использования дополнительного тона.

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

Далее оформим модули систем, которые мы определили в 6 разделе.

Для того, чтобы выделить модуль системы как отдельный элемент экрана и сгруппировать его параметры вместе, определим для него отдельное пространство и зададим ему фон. Тон фона возьмем из развития тональности от Grey 10 до Grey 20, и этим тоном будет Grey 14. Данный оттенок хорошо виден на основном фоне и, в то же время имеет небольшой контраст, а значит, не будет брать на себя много внимания. Это очень важно в визуальной работе блока.

Каждый модуль имеет свое название. Для названия мы сделаем отдельный фон, не только для того, чтобы подчеркнуть его иерархию, но и как элемент сигнализации в определении аварий. Тон фона для заголовка возьмем Grey 20, соответственно тон текста для него берем из спецификации Grey 70. Для придания заголовку более высокой иерархии, сделаем его заглавными буквами с межбуквенным расстоянием 10% и размером шрифта 14рх Medium.

Размер текста для данного элемента выберем 13рх, тон также возьмем из спецификации Grey 60. Название параметра — это элемент, который должен быть хорошо виден, но, в то же время, оно не должно привлекать к себе внимание. Его назначение — комментировать параметр, поэтому шрифт и контрастность минимально–допустимые.

Данный элемент должен привлекать к себе максимум внимания, для этого он должен быть предельно контрастным по отношению к другим элементам интерфейса. Для фона Grey 14 максимальный контраст даст черный цвет #000000, коэффициент контрастности составит 17:1 AAA. Размер шрифта 20рх Regular.

Применив описанные выше правила, получаем такой результат.

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

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

Так блок выглядит на исходной схеме

Я переработал его в такой вид

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

То же самое будет использоваться в блоке "Бак масла"

После переработки блок имеет такой вид.

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

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

Кнопка "Пуск" при работе установки имеет минимальный контраст, это говорит о том, что в данный момент она не активна. Если агрегат остановлен и готов к пуску, то состояние кнопок будет следующим.

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

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

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

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

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

"Чем быстрее оператор локализует аварию, тем лучше операторский интерфейс."

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

Алгоритм индикации аварии следующий:

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

В данный момент, глядя на главное меню, мы видим, что в схеме Деаэратора произошла авария. Допустим, что мы находимся на другом экране интерфейса, в схеме ГПА1 произошла авария (пункт меню подсветился красным маркером), переходим на данный экран и видим ,где именно произошел отказ.

Думаю, что здесь все ясно. Авария произошла в системе «Вентиляция» , отказ вытяжки и, как следствие, повышенная температура в помещении (параметр помечен маркером).

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

Как видно из иллюстрации, на главном меню предупреждения оповещаются маркером с тоном Grey 10. В схеме блок заголовка системы принимает тон Grey 80, а текст, для большего контраста, чисто белый. Напротив тревожного параметра, также устанавливаем темный маркер.

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

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

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

Красоты и изящества здесь нет, выглядит мнемосхема скучно, но именно этим она помогает решать оператору поставленные задачи быстро и с наименьшими усилиями.

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

За время чтения статьи, наверняка вы успели заметить, что дизайн интерфейсов — это такое же проектирование, как написание программ, разработка шкафов управления автоматикой, конструирование механических узлов и агрегатов. Многие сравнивают дизайнера с художником или музыкантом. Нет, друзья, дизайнер HMI – это такой же проектировщик, как и другие разработчики АСУ ТП. В рамках одной статьи всего не опишешь, и многое осталось за кадром, такое, как работа с пространством, компоновка, типографика, прототипирование и еще многие мелочи. В реальном проекте добавится еще больше этапов, таких, как согласование с программистом и с самим заказчиком, интеграция в среду разработки, тестирование пользователями (не всегда, но бывает).

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

Если вам интересно узнать о других проектах, можете посмотреть их на моем сайте в разделе «Портфолио»

Ну и в конце вся графика проекта

Спасибо за внимание!