{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

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

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

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

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

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

1. Подход Wonderware Situational Awareness

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

Цвет

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

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

Задача HMI

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

2. Выбор мнемосхемы для переработки

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

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

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

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

Исходная мнемосхема

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

3. Для кого мнемосхема?

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

Вопрос 2

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

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

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

4. Требования к интерфейсу

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

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

5. Элементы мнемосхем

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

Виды элементов:

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

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

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

Состояния элементов:

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

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

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

4. Авария

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

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

6. Структурирование элементов

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

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

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

  • Блок «Главное меню»
  • Параметры двигателя
  • Параметры генератора
  • Подача газа
  • Вентиляция
  • Контур охлаждающей жидкости
  • Контур охлаждения масла
  • Бак масла
  • Управление

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

7. Цветовая система проекта

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

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

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

Доступность

Для людей с отклонениями по зрению необходимо соблюдать Рекомендации по обеспечению доступности веб-контента (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 соответственно.

Развитие тональности от Grey 10 до Grey 20

8. Оформление

Выбор шрифта

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

Выбранный шрифт

Меню

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

Меню исходной мнемосхемы

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

Экран с меню

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

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

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

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

9. Оформление блоков систем

Далее оформим модули систем, которые мы определили в 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.

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

Оформление блоков

Поля ввода числовых значений

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

Оформление поля ввода значений

Пиктограммы

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

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

Блок "Вентиляция" на исходной мнемосхеме

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

Блок "Вентиляция" переработанный

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

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

Блок "Бак масла" на исходной мнемосхеме

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

Блок "Бак масла" переработанный

Кнопки "Пуск" и "Стоп"

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

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

Кнопки управления

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

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

Блок "Управление"

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

Блок "Управление"

10. Конечная компоновка блоков

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

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

Полный экран переработанной мнемосхемы

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

11. Система локализации аварий и предупреждений

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

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

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

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

Отображение аварии на пункте меню

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

Отображение аварии в блоке системы

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

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

Отображение предупреждений в меню и в системе "Бак масла"

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

Вид блока с предупрежден

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

12. Что в итоге?

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

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

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

13. Для каких HMI подходит данный метод?

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

P.S.

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

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

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

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

Исходная мнемосхема
Владимир Бойков
Авария блока Владимир Бойков
Темная тема интерфейса Бойков Владимир
Темная тема с состоянием аварии Бойков Владимир
Темная тема с состоянием предупреждения Бойков Владимир
Спецификация Бойков Владимир

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

0
11 комментариев
Написать комментарий...
Alexander Sudalin

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

Ответить
Развернуть ветку
Alexey K.

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

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

Ответить
Развернуть ветку
Владимир Бойков
Автор

Да, с мнемосхемой интерфейс выглядит нагляднее, но в данном примере схема простая. А они бывают очень сложные и возле каждого прибора, в основном, нужно разместить еще поле с параметром мелким шрифтом (иначе не влезет в экран, а заказчику нужно чтобы это было в одном экране). В плане мониторинга оператору бывает не просто все это контролировать. Вот тогда и возникает вопрос — а нужны ли здесь трубы, баки и другие статичные изображения? Или лучше использовать занимаемое ими пространство для комфортного отображения значений параметров? Однозначного ответа здесь нет! Нужно тестирование персоналом. Что касается замечания – "просто взглянув на экран, не сразу поймешь что управляешь установкой ГПА, а не котлом, если не вчитываться в заголовок.." — я думаю, что оператор не будет в слепую перебирать пункты меню ориентируясь только по картинкам.
Далее "Мало того, я вижу что статусы клапанов и насосов (в контуре охлаждения масла) на оригинальной мнемосхеме не перенесены на новый экран" — они перенесены, но показаны в виде стрелок, согласен, решение спорное и в реальных проектах данные пункты обсуждаются с заказчиком.
"Ну и в конце-концов: вызывают специалиста, которому говорят что-то там не работает, он приходит и спрашивает, а что не работает, а ему даже показать не могут, где искать насос, или задвижку - в тексте не все так очевидно." — На моем счету много сделаных мнемосхем и из своего опыта я знаю, что каждый прибор имеет свое уникальное обозначение на схеме. При локализации аварии интерфейс должен подсвечивать аварийный прибор или параметр, и оператор сообщает наладчику его номер. Наладчик, в свою очередь, находит данный узел в проектной документации и принимает решение. С проектной документацией наладчику нужно работать. Не всегда получается впихнуть в мнемосхему все что нужно наладчику. Если схема небольшая то да, можно сделать все красиво и для оператора и для наладчика, но в больших проектах так не получается. Конечно, везде свои условия и разная организация службы поддержки и на этапе прототипирования я это учитываю. Шаблонных решений увы нет! И вы это знаете луче меня.

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

Ответить
Развернуть ветку
Alexey K.

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

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

А по поводу насоса в линии подачи охлаждающей жидкости, то стрелкой это не совсем очевидно, как вы и сами заметили. И к тому же в обратке в оригинале насоса нет, а у вас на схеме стоит тоже стрелочка. Просто обратил внимание на нестыковки.

Ну и напоследок еще раз про мнемосхему. Как вы знаете кроме UI есть и UX - операторы такие же люди как и инженера и уже привыкли хоть и к страшным 3D и всяким прочим, но схемам - так гораздо понятнее. Поэтому мне лично было бы интересно увидеть то же самое, но уже со схемой, поэтому я бы даже был не против еще одной статьи)

PS а что насчет расширяемости? Новый датчик или клапан можно будет подсунуть в такую красивую схему, без полной ее переработки?)

Ответить
Развернуть ветку
Владимир Бойков
Автор

https://colorable.jxnblk.com/be0000/e5e8ee — Сервис определения контраста

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

На счет схем в интерфейсе! Ну конечно их никто не отменял! Я также предпочитаю видеть мнемосхему вместо дашбордов. Статья посвящена данному подходу построения интерфейса, мне он показался интересным и перспективным. Поэтому я сделал небольшой эксперимент о котором и написал. Но чтобы осуществить его в полной мере нужен реальный проект и заказчики готовые в этом по участвовать, потому что, как правильно заметил Alexander Sudalin "Т.е. надо рассматривать визуализацию не сточки зрения объектов и узлов, а с точки зрения процесса.", а для этого потребуется совместное решение и дизайнера, и проектировщика, и наладчика, и оператора.

Пока что рулят мнемосхемы и я проектирую интерфейсы с ними. Вот одна из моих работ. (Один из экранов системы вентиляции). Описание данного кейса — https://scada-disygn.ru/pages/ventilation.html

Ответить
Развернуть ветку
Yurii Dymytrov

Как боженька смолвил

Ответить
Развернуть ветку
Алексей

Владимир, вообще сама исходная статья, на которую Вы ссылаетесь, по-моему, какие-то рассуждения о прочитанном, притом поверхностные. Если сам подход заинтересовал, посмотрите "high performance hmi handbook" bill hollifield. Раз уж дизайном мнемосхем занимаетесь.

Ответить
Развернуть ветку
Владимир Бойков
Автор

Хорошо, спасибо за информацию!

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Evgeny Chestnov

Мне в целом нравится, но вот с чем не согласен. Идея что все серое а только аварии красные- это глобальная ошибка. Система управления серьезная, оборудование важное, если оно встает по аварии, то оператор должен об этом узнать очень быстро, звук, свет, смс, любое другое уведомление. Красный цвет на панельке он не должен увидеть первым, так как панель вообще не предназначена для того, чтобы человек в нее смотрел круглосуточно. Для этих целей есть диспетчеризация и АРМ, там стоят колонки и gsm модем, с дублированием всего и вся. Панель вообще используется как локальный орган управления, для контроля работы, изменения режимов и пнр. Хотя в вашем примере, судя по всему, панель это часть диспетчеризации. Короче нужно обязательно выделять помимо аварий и предупреждения и статусы и уставки, сейчас они абсолютно не считываются. Статус иконки лучше белая/зеленая, а не жирная и не жирная. Уставки синии, одинаковым шрифтом и размером и без фона. Предупреждения желтый или оранжевый. Попробуйте, интерфейс сразу приятнее и легче станет.

Ответить
Развернуть ветку
Nikolaev Ivan

Добрый день! Технический вопрос. Как в Вайнтеке сделать подчеркивание данных которые вводит оператор? У меня почему-то отсутствует такой пункт. Есть только для обычного текста, либо меток, а для данных нет

Ответить
Развернуть ветку
Владимир Бойков
Автор

Добрый день! Вайнтековскими библиотеками никак. Только использованием своей графики

Ответить
Развернуть ветку
8 комментариев
Раскрывать всегда