Статья описывает концепцию информативного интерфейса SCADA, основанную на книге «The High Performance HMI Handbook» и опыте Citect SCADA. Приведены примеры реализации иерархических экранов с плитками, цветовой индикации и автоматической компоновки через JSON.
- Интерфейс SCADA должен доносить максимум информации о состоянии системы, избегая фотореалистичных изображений, анимации и мигания.
- При нормальной работе ничего не должно привлекать внимание пользователя, статичные элементы отображаются чёрным, меняющиеся — синим, зелёным или красным.
- Активное оборудование выделяется зелёным цветом, чтобы пользователи могли быстро понять, осталось ли что-то включённым.
- Вместо мнемосхем используется иерархия экранов с прямоугольными плитками, описывающими объекты или программные модули.
- Структура интерфейса задаётся в JSON-файле, сервис Web-UI автоматически компонует экраны и плитки.
- Виртуальные датчики среднего и дельты рассчитываются на основе физических датчиков, большая дельта может указывать на проблемы.
- SCADA
- The High Performance HMI Handbook
- Citect SCADA
- JSON
- Web-UI
- модуль автоуправления климатом
- датчик среднего значения
- датчик максимальной разницы значений (дельта)
Кому полезно: Инженеры АСУ ТП, разработчики SCADA и специалисты по автоматизации
Первоисточник: habr.com
Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.
- Часть 1: Вводная
- Часть 2: Информативный интерфейс SCADA – вы читаете эту статью
В этой статье я хочу поделиться своим видением того, каким должен быть удобный и информативный интерфейс SCADA системы.
Все иллюстрации в статье – это скриншоты, сделанные с разработанной мной SCADA системы, которая уже несколько лет работает на объектах заказчиков. Это не фантазии на тему как должно быть и не картинки из презентации.
При разработке я опирался на известную книгу «The High Performance HMI Handbook» (Hollifield, Oliver, Nimmo, Habibi), а также на интерфейс Citect SCADA.
Введение
Интерфейс SCADA системы предназначен для контроля за состоянием и управления оборудованием объекта. Все отображаемые графические элементы, символы, пиктограммы и их цвет, должны служить только одной цели – доносить пользователю максимум информации о состоянии системы. Всё что не несёт информации, а служит только целям дизайна и другим украшательствам, должно быть отброшено т.к. вносит дополнительный шум и распыляет внимание пользователя.
Особенно нужно избегать добавления каких-либо фотореалистичных изображений объекта и оборудования. Также недопустима любая анимация или мигание, особенно при нормальной работе оборудования. Всё это вносит визуальный шум, перетягивает внимание пользователя на себя и мешает считыванию другой информации.
К сожалению, в разных отраслях есть собственные стандарты, которые жёстко регламентируют способ отображения информации и могут помешать созданию интерфейса по описываемой концепции. Например, в энергетике есть стандарт «Правила отображения технологической информации» утверждённый системным оператором единой энергетической системы, который задаёт в том числе цветовую маркировку, где красный, жёлтый и другие яркие цвета используются для индикации нормального состояния объекта.
Основная концепция
Если всё работает нормально, то ничего не должно привлекать внимание пользователя. При этом пользователь не должен тратить время и читать все цифровые или текстовые значения чтобы понять, что всё работает нормально. Это можно описать как «взгляду не за что зацепиться».
Все статичные (неизменяемые) элементы отображаются чёрным цветом, а меняющиеся со временем значения синим, зелёным или красным.
Условные обозначения

Пример – всё нормально

Если посмотреть более внимательно, то пользователь заметит:
- Секция 2: Увлажнители выведены из работы.
- Система: Вентилятор шкафа находится в ручном режиме управления.
Пример – всё нормально и некоторое оборудование активно

Всё оборудование, состояние которого отображается зелёным цветом, включено или находится в движении.
Первая версия интерфейса не выделяла активное оборудование зелёным цветом, всё отображалось синим. Но при внедрении системы я обнаружил, что обязательно нужно как-то выделять активное оборудование. Дело в том, что наши пользователи часто управляют оборудованием вручную, даже при наличии модуля автоматического управления климатом. И им необходимо быстро понимать, осталось ли какое-то оборудование во включенном состоянии, чтобы не забыть его отключить.
Пример – есть проблемы
- Секция 1: Нет связи с датчиком температуры канала. Обрыв линии связи или датчик вышел из строя.
- Секция 2:
- Температура продукта меньше или равна заданной пользователем нижней аварийной границы.
- Вентилятор 2 – оборудование отключено и находится в состоянии аварии. Например, сработало тепловое реле защиты электродвигателя. Возможно, двигатель заклинил, изношены подшипники и т.д.
- Секция 3: Температура канала больше или равна аданной пользователем верхней предупредительной границы.
- Улица (метеостанция): Датчик температуры возвращает некорректное значение. Помехи на линии связи или система самодиагностики датчика фиксирует отклонения в его работе.
Иерархическая организация экранов интерфейса
При разработке системы было решено отказаться от формирования интерфейса в виде экранов и мнемосхем со схематичным изображением помещений и оборудования объекта.
Даже похожие по назначению объекты заказчиков очень сильно различаются по структуре и составу оборудования. Например, в одном овощехранилище может быть 2 секции (помещения), а в другом 10. В каждой секции состав и количество оборудования может отличаться на порядок.
Я видел на объектах, как в других системах, нарисовав один раз изображение какого-то «усреднённого» хранилища, пытаются разместить поверх него большое количество оборудования, в итоге интерфейс превращается в бесконечный массив из картинок электродвигателей, датчиков и кнопок управления. При таком подходе, для каждого объекта надо полностью перерисовывать мнемосхему, для большинства объектов вообще нужна иерархия из экранов и мнемосхем. Но создание такого интерфейса затратный по времени (=деньгам) процесс, поэтому в реальности так никто не делает – у наших заказчиков просто нет соответствующих бюджетов.
Также наша SCADA имеет web-интерфейс, который должен автоматически адаптироваться под экраны мобильных устройств. Любые схематичные изображения или мнемосхемы невозможно автоматически масштабировать, чтобы ими было удобно пользоваться на маленьких экранах – для них придётся создавать отдельное представление интерфейса.
Поэтому решено было реализовать интерфейс из экранов с прямоугольными плитками, плитка – это представление отдельного физического объекта (здание, помещение и т.д.) или программного модуля системы (модуль автоуправления климатом, SMS оповещения, графиков и т.д.). Каждая плитка выступает в роли ссылки на описываемый объект.
Такой подход позволяет описать любой объект в виде иерархической структуры с неограниченной вложенностью. На экранах верхнего уровня в плитках выводится наиболее значимая информация о нижележащем объекте. На экранах самого нижнего уровня находятся не плитки, а уникальные компоненты для управления и настройки оборудования.
Структура интерфейса объекта оп сывается в JSON файле. Сервис Web-UI при старте читает этот файл и выполняет автоматическую компоновку всех экранов и плиток.
Реализована отдельная утилита, которая позволяет удобно формировать интерфейс для каждого объекта заказчика и сохранять его в JSON файл. Этот код находится в отдельном проекте и просто служит для удобства формирования файла JSON, можно вручную всё в файле JSON описать используя любой текстовый редактор.
Пример кода на C# для формирования интерфейса
public static ModelStorage Create(API.Model model)
{
ModelBuilderContext builderContext =
new ModelBuilderContext(model)
.CreateHomePage()
.CreateWeatherPage()
.CreateSystemPage();
for (int sectionId = 1; sectionId <= 3; sectionId++)
{
builderContext
.CreateSectionPage(sectionId)
.CreateSectionEquipmentPage(sectionId)
.CreateSectionSensorsPage(sectionId)
.CreateSectionRoomSensorsPage(sectionId)
.CreateSectionSensorsProductPage(sectionId)
.CreateSectionClimateControlPage(sectionId);
}
builderContext
.AddChartTags(
new ChartTag(builderContext.GetTagId("Секция 1 - Датчик температуры бурта Среднее", "SensorInput"), "Секция 1"),
new ChartTag(builderContext.GetTagId("Секция 2 - Датчик температуры бурта Среднее", "SensorInput"), "Секция 2"),
new ChartTag(builderContext.GetTagId("Секция 3 - Датчик температуры бурта Среднее", "SensorInput"), "Секция 3"));
return builderContext.GetModel();
}
static ModelBuilderContext CreateHomePage(this ModelBuilderContext builderContext)
{
UIPage page = new()
{
Id = "home",
ParentId = null,
Header = "Хранилище",
GroupBoxes = new List<UIGroupBox>()
};
page.GroupBoxes.Add(
new UIGroupBox()
{
PageId = "weather",
Header = "Улица",
Items = new List<UIGroupBoxItem>()
{
new UIGroupBoxItem()
{
Name = "T",
TagId = builderContext.GetTagId($"Метеостанция - Датчик температуры улицы", "SensorInput"),
},
new UIGroupBoxItem()
{
Name = "RH",
TagId = builderContext.GetTagId($"Метеостанция - Датчик влажности улицы", "SensorInput"),
},
}
});
// ...
return builderContext.AddPages(page);
}
static ModelBuilderContext CreateWeatherPage(this ModelBuilderContext builderContext)
{
UIPage page = new()
{
Id = "weather",
ParentId = "home",
Header = "Улица",
EquipmentItems = new List<UIEquipmentItem>()
{
new UIEquipmentItem()
{
Name = "T",
TagGroupId = $"Метеостанция - Датчик температуры улицы",
ComponentType = UIComponentType.Sensor
},
new UIEquipmentItem()
{
Name = "RH",
TagGroupId = $"Метеостанция - Датчик влажности улицы",
ComponentType = UIComponentType.Sensor
},
}
};
return builderContext.AddPages(page);
}
1. Верхний уровень – домашняя страница
Общая сводная информация о объекте. В плитках только самая важная информация о нижележащем объекте.

- Секция 1-3 – это физические помещения хранилища.
- Улица – уличная метеостанция.
- Система – всё что относится к общему оборудованию. В данном случае подогрев клапанов всех секций подключен к одному реле, поэтому вынесен на эту плитку.
- График температуры продукта – программный модуль для отображения графиков по архивным значениям.
2. Средний уровень – секция
На этом уровне в плитках отображается всё оборудование секции.
Если оборудования очень много, то можно сделать ещё один или несколько дополнительных уровней иерархии. И наоборот, если оборудования очень мало, то этого уровня может вообще не быть.

3. Нижний уровень – управление и настройка оборудования
На экранах самого нижнего уровня находятся не плитки, а уникальные компоненты для управления и настройки оборудования.
Для доступа к настройкам нужно нажать кнопку «…».
3.1 Датчики

3.2 Датчики помещения

3.3 Температура продукта

Раскрыто меню настройки у датчика среднего:

Сверху отображаются виртуальные (программные) датчики среднего и дельты с расчётными значениями на основе 6 физических датчиков температуры.
Датчик среднего значения – среднее арифметическое значений группы датчиков.Среднее = Сумма всех значений / Количество значений
Датчик максимальной разницы значений (дельта) – среди значений группы датчиков определяется минимальное и максимальное значение, затем вычисляется модуль от разницы этих значений.Дельта = |Максимальное значение - Минимальное значение|
Это очень важное значение. Большая дельта температур может означать:
- Неравномерное перемешивание воздуха внутри хранилища.
- В хранимом продукте имеются очаги гниения.
- Промерзает стена хранилища.
3.4 Оборудование

Если представить страницу в виде таблицы со строками и колонками, то можно следующим образом описать колонки:
- Название.
- Текущее состояние.
- Заданное состояние (команда). Кнопка с активной командой имеет голубой фон. Если кнопки «бледные», то ручное управление заблокировано.
- Режим управления. Ручной – управление оборудованием осуществляется пользователем вручную, с помощью кнопок с командами. Авто – оборудование управляется автоматически программным модулем, например, модулем автоуправления климатом. Если оборудование не привязано к какому-либо модулю автоуправления, то у него нет кнопок выбора режима управления, т.е. оборудованием можно управлять только вручную.
- Кнопка «…» для отображения настроек оборудования.
Раскрыто меню настройки у клапана и увлажнителя 1:

3.5 Автоуправление климатом
Настройки программного модуля автоуправления климатом хранилища.
Этот модуль содержит множество настроек, поэтому у него всегда собственная плитка и отдельный экран настройки. У параметров имеется текстовое описание.

Всплывающее окно для изменения числового значения

Описание элементов окна:

У разных параметров шаг может отличаться. Например, у некоторых параметров маленький шаг = 0,1, а большой = 1, а у других маленький шаг = 1, а большой = 10.
У параметров (тегов) обычно заданы границы минимального и максимального значения, соответственно все элементы окна позволяют менять значение только в допустимом диапазоне.
Итог
Данный подход к созданию интерфейса хорошо себя зарекомендовал на объектах. Им удобно пользоваться как на сенсорном экране с диагональю 17 дюймов, так и на мобильных устройствах.
Также такой простой интерфейс без графики потребляет минимум интернет трафика, что особенно важно при использовании мобильных устройств в отдалённых местах за городом.
Принцип, когда при нормальной работе «взгляду не за что зацепиться» оказался удобным – можно не подходить близко к экрану, чтобы понять, есть какие-то проблемы в работе или нет.
Источник: https://habr.com/ru/articles/1004914/