Часть 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 дюймов, так и на мобильных устройствах.
Также такой простой интерфейс без графики потребляет минимум интернет трафика, что особенно важно при использовании мобильных устройств в отдалённых местах за городом.
Принцип, когда при нормальной работе «взгляду не за что зацепиться» оказался удобным – можно не подходить близко к экрану, чтобы понять, есть какие-то проблемы в работе или нет.
Комментарии (23)
SpiderEkb
02.03.2026 06:30Крайне неинформативно. Когда все нормально, никто не будет сидеть и пялиться в экран. А вот когда ненормально, должна быть полная информация - где? что? когда случилось?
Если у вас будет не оно хранилище, а, к примеру, 10 - все это на экран не влезет. Секция 1, секция 2 - где это? Что это вообще?
В своей время делали систему мониторинга инженерного оборудования зданий для ЖКХ (система диспетчеризации). Там лифты, охрана служебных помещений и много чего еще. Обслуживало оно достаточно много объектов разбросанных не только в пределах одного района, но по всему городу. Были объекты, где одних лифтов было по 300-500 штук подключено.
В основе интерфейса - карта на которой выделены обслуживаемые дома. Можно ткнуть на дом и получить его подробную схему - что где на нем расположено. Там же можно посмотреть текущее состояние любого устройства, его историю (что с ним происходило, архив событий и т.п.)
Если на доме "что-то не так", он подсвечивается отдельно.
Второй обязательный элемент - список аварийных сообщений куда выводятся события. Опять с полной расшифровкой на нормальном языке типа "ул. Строителей, д. 35, подъезд 2, грузовой лифт - двери шахты открыты".
Ведется полный лог - когда, где что случилось + реакция диспетчера (когда и что было сделано) - каждое аварийное событие требует "обработки" - реакции диспетчера.
Основы этого интерфейса закладывались еще в 93-94-м годах (мы были первыми в РФ кто начал работать в этом направлении) и получилось настолько удачно, что последующие разработки конкурентов в той или иной степени шли по тому же пути уже.
Диспетчеры зачастую - женщины среднего возраста, уровень среднего пользователя ПК. Осваивали интерфейс очень быстро - настолько там все было просто и интуитивно понятно.
maiorovx Автор
02.03.2026 06:30Журнал событий и аварий есть, с поддержкой квитирования, просто в данном случае он в интерфейс не выведен, т.к. конкретному заказчику не нужен (настроено SMS оповещение на важные события).
Мы ведём разработку функций только если они нужны какому-нибудь заказчику. К сожалению, нет ресурсов разрабатывать универсальную систему. Само ядро SCADA с тегами универсальное, позволяет описать всё что угодно. Но на его базе нужно создавать оборудование с тегами, логические функции для их работы, компоненты UI. Всё это создаётся когда нехватает уже реализованных компонентов.
Карты (геоподложки) нет - пока никому из заказчиков не было нужно.
Конкретно ваш случай с лифтами - не вижу проблем в реализации на основе плиток. На домашней странице делаем плитки по районам города, в них выводим какую-то сводную информацию, например мы можем сделать расчётные теги, в которых бы выводилось сколько всего лифтов на районе, сколько с проблемами, сколько в аварии, сколько ремонтных бригад выехало на инциденты и т.д. Также рамка плитки может окрашиваться в красный цвет, если внутри иерархии есть аварийный статус тега, а на саму плитку этот тег не выведен.
Я вообще не уверен что в вашем случае с лифтами основой интерфейса должна быть карта города. И плитки наверное ненужны. Диспетчеру достаточно вывести журнал событий с квитированием, в карточке события будет адрес дома и ссылка на карту (Яндекс.Карты, 2 Гис и т.д.), в ней сразу интерфейс назначения ремонтной бригады сделать и т.д. Понятно что придётся написать отдельный модуль такого журнала для максимального удобства, но всё это возможно сделать на базе нашей системы.
safer
02.03.2026 06:30Было бы интересно узнать как реализован механизм восстановления потерянных данных после восстановления связи верхнего уровня со средним уровнем. У вас же опрос приборов идёт 1 раз в секунду.
maiorovx Автор
02.03.2026 06:30Не совсем понял, про какой верхний и средний уровень идёт речь. В статье описана иерархия уровней (экранов, окон) интерфейса пользователя (UI).
Обычно оба сервиса (ядро SCADA и UI) запущены на одном компьютере и общаются между собой по TCP через 127.0.0.1. Ядро опрашивает все устройства обычно 1 раз в секунду и хранит в памяти все текущие значения тегов, а также пишет изменившиеся значения в архив на диск. Если соединение между сервисами прервётся, то сервис UI периодически будет пытаться переподключиться к ядру.
Технически, каждая плитка выступает в роли ссылки и может ссылаться на любой URL где запущен сервис UI, в том числе эти сервисы UI могут быть подключены к своему ядру SCADA. Т.е. за плитками верхней (домашней) страницы может скрываться множество отдельных компьютеров со своими сервисами ядра и UI на разных объектах заказчиков, но обычно все плитки, по которым можно прокликать - это всё таки один объект заказчика (например, овощехранилище, состоящее из нескольких расположенных рядом складов-секций).
Архитектура системы (подробнее https://habr.com/ru/articles/1001024/):
safer
02.03.2026 06:30Основные уровни в системе автоматизации (сверху вниз):
-
Верхний уровень (Уровень SCADA/HMI/Диспетчерский):
Функции: Визуализация процессов (мнемосхемы, графики, тренды), диспетчерское управление, архивирование данных, формирование отчетов аварийная сигнализация.
Компоненты: Рабочие станции операторов (HMI), серверы SCADA, HISTORIAN-серверы.
-
Средний уровень (Уровень управления / Контроллерный):
Функции: Логическое управлениевыполнение алгоритмов регулирования (ПЛК-программы), сбор данных от полевых устройств.
Компоненты: Программируемые логические контроллеры (ПЛК/PLC), распределенные системы управления (РСУ/DCS), удаленные терминалы (RTU).
-
Нижний уровень (Полевой уровень / Уровень оборудования):
Функции: Непосредственное взаимодействие с техпроцессом: измерение параметров и исполнение команд.
Компоненты: Датчики (сенсоры)исполнительные механизмы (приводы, клапаны, двигатели).
maiorovx Автор
02.03.2026 06:30Теперь понял про что вы. У меня просто в статье есть главы "1. Верхний уровень – домашняя страница" и "2. Средний уровень – секция".
Тогда верхний и средний уровни из вашего перечня реализованы в сервисе ядра SCADA и сервисе UI (HMI).
Ядро напрямую общается с устройствами к которым подключены реле и датчики. У плат управления реле есть конфигурируемая настройка, что делать при пропаже связи с ядром, т.е. если ядро их не опрашивает, то что нужно им делать: ничего или всё отключить.
-
babysas
02.03.2026 06:30Решение подобных задач это круто.
Но как интерфейс это очень плохо, прежде всего тем, что очень большая когнитивная нагрузках в попытках считать:
из-за отсутсвия вёрстки, хотя бы банального выравнивания элементов цифр, независимость его от -/+ значений
красные рамки частично прилипают к именованиям объектов, отчего те не читаемы до конца
плохо просматривается или отсутствует иерархия объектов и их значений
на примере со слайдером не понятен ни шаг, ни границы значений
Про то, что утилитарное не должно быть уродливым, упомяну, но в отличии от вышеописанного, согласен обозвать вкусовщиной.
Средней руки дизайнер, пожелавший вникнуть в проблему способен очень сильно улучшить функциональность вашего продукта.
Даже чисто текстовыми средствами достигнуть можно шикарнейших результатов.
maiorovx Автор
02.03.2026 06:30Согласен, очень много чего не доделано и есть много что можно улучшить, особенно в части интерфейса.
Основной упор при разработке системы был сделан на ядро системы и оптимальный алгоритм автоуправления климатом (3 раза практически заново переписывался). Но повторю, все доработки только за счёт новых заказов, а с этим в последнее время проблемы. Также вся разработка ведётся одним человеком в свободное от основной работы время.
babysas
02.03.2026 06:30Исследование пользовательского опыта часть моей работы. В специфических проектах, когда точка 0 - не было автоматизации, точка 1 - есть автоматизация, мало кто пиняет на интерфейс :)
Не мне вам рассказывать скриптики "для себя" обходятся вовсе без него годами.Делать сразу чуть лучше и учитывать базовое помогает насмотренность и прочесть что-то по проектированию интерфейсов - условно "как не надо делать" уже даёт хорошее понимание.
Есть базовые вещи:
вёрстка табличных данных
иерархия объектов
групировка объектов
цветовое кодирование и подсветка
как наш взгляд сканирует интерфейсы
К сожалению прям конкретные материалы не вспоминаются. Если вспомню - напишу.
sergej_pipets
02.03.2026 06:30Климатом SCADA не должна управлять. Это всего лишь интерфейс между хуманом и управляющими контроллерами. Управлять, регулировать должны местные контроллеры. И они уже выдавать текущие параметры в СКАДу. Ваша система без SCADA неработоспособна.
maiorovx Автор
02.03.2026 06:30У нас в SCADA реализованы все алгоритмы управления оборудованием и сбора данных с датчиков. Больше на объекте нет никаких контроллеров ПЛК. Этот микрокомпьютер на базе Raspberry Pi 4 с Linux и запущенными сервисами (приложениями) ядра SCADA и Web-UI выступает в роли единственного контроллера и находится прямо на объекте, обычно прямо в шкафу с электроустановочными изделиями (контакторы, реле и т.д.), куда подключено всё силовое электрооборудование. На дверце этого шкафа ещё расположен сенсорный экран - подключен кабелем HDMI напрямую к микрокомпьютеру.
Можете считать это одним контроллером (ПЛК), просто у которого все входы вынесены на отдельные платы и мозги которого общаются с этими платами через Ethernet (там кабель - витая пара длиной 50 сантиметров, т.е. это Ethernet внутри одного электрошкафа, все платы управления реле в нём, вынесены только датчики).
Ядро напрямую общается с устройствами к которым подключены реле и датчики. У плат управления реле есть конфигурируемая настройка, что делать при пропаже связи с ядром, т.е. если ядро их не опрашивает, то что нужно им делать: ничего или всё отключить.
Я сейчас специально перечитал ещё раз определение SCADA и не нашёл противоречий, почему наш софт не может называться SCADA если не общается ещё с какими-то контроллерами.
sergej_pipets
02.03.2026 06:30Просто у вас система мелкая. По сути - один контроллер со своим междумордием. Сколько точек данных? Сотня имеется?
maiorovx Автор
02.03.2026 06:30Сколько точек данных? Сотня имеется?
Сейчас посмотрел - у хранилища на 10 секций 250 адресов (каналов) для получения и отправки данных, причём с интервалом опроса всех каждые 250 мсек (4 раза в секунду). Я кстати незнаю зачем такой частый опрос мы у заказчика сделали, похоже тестировали и зыбыли на стандартный 1 раз в секунду поменять)))
Но это не предел - я тестировал на эмуляторе 5000 адресов, я думаю он даже на Raspberry Pi 4 без тормозов работать будет, если не хватит производительности, можно запустить нашу систему на полноценном серверном компьютере (поддерживаются операционные системы Linux и Windows). Я вам по секрету скажу, это ядро по скорости возможно превзойдёт многие DCS сервера в очень больших SCADA системах.
Yukr
Это, наверное, холивар, но:
Категорически не согласен. Цель дизайна в таких системах именно помогать пользователю быстро находить нужные параметры. Если для этого нужен силуэт домика(=хранилище), это лучше чем плитки. Картинка вентилятора привлекает внимание легче, чем поиск группы параметров " слева, где-то посередине окно".
Анимация и мигание может как раз служить индикацией нормального состояния системы (watchdog!).
И оператор редко пялится в экран круглосуточно.
maiorovx Автор
Действительно, тема хорошего UI холиварна, как и любого дизайна.
Возможно, при условии что кто-то будет каждый раз перерисовывать этот силуэт и картинки под конкретный объект.
На практике, обычно если есть картинки в интерфейсе, то имеются жёсткие ограничения на состав и количество оборудования, например, поддерживается до 6 вентиляторов канала и до 8 датчиков температуры продукта.
Более того, часто в этом случае в интерфейсе показывается даже физически отсутствующее оборудование т.к. оно захардкожено в картинках, т.е. если на объекте вместо 6 вентиляторов только 2, то отображаются 6.
У нас нет никаких ограничений. Возможно где-то приходится чем-то жертвовать, но мы всегда очень стараемся скомпоновать удобный интерфейс под конкретный объект.
Также на мобильных устройствах этими картинками неудобно пользоваться.
Моя концепция и подход, описанный в книге «The High Performance HMI Handbook» (Hollifield, Oliver, Nimmo, Habibi), прямо противоречит этому)))
Примеры:
Пропала связь со всем оборудованием (в секции 2 уважнитель 1 выведен из работы, поэтому нет рамки):
Пропала связь сервиса UI с сервисом ядра SCADA
Мне кажется это намного нагляднее, чем следить за какой-то анимацией, означающей нормальную работу системы.
Да, поэтому обычно настраиваем SMS оповещение о самых важных событиях.
SpiderEkb
Ну вообще-то, "картинка" - это несколько слоев и уровней детализации. Те же устройства не рисуются на картинке хардкодом, а накладываются в виде иконки поверх изображения.
И да, в БД конфигурации есть привязки каждого устройства к объекту где оно расположено.
Анимация тут не нужна. Но понимать что и где у вас расположено очень помогает.
В обычной работе все эти цифры на экране постоянно не нужны. Нужно лишь понимать с первого взгляда - норма или нет. Ну иметь возможность посмотреть текущее состояние по конкретному устройству.
maiorovx Автор
Я думаю что мы говорим о разных порядках стоимости внедрения системы. Я о примерно 1-5 млн. руб. за всю автоматику, включая наши устройства, датчики, шкаф с электроустановочными компонентами (автоматы, контакторы, реле), но без учёта силового оборудования (вентиляторы, клапана и т.д.).
Как дела обстоят на практике в интерфейсах с картинками в овощехранилищах, я описал в комментарии выше.
Для технологических линий предприятий да, иногда очень хорошо всё отрисовывают, с множеством экранов для каждого технологического процесса и т.д., но там и бюджет в 10, а скорее в 100 и более раз выше.
Но всё равно, мне ближе подход «взгляду не за что зацепиться» при нормальной работе, описанный в книге «The High Performance HMI Handbook».
SpiderEkb
Мы работали с ЖКХ, а там бюджеты...
Когда мы начинали (1993-й, на минуточку, год), "заказчику" вообще ничего не надо было "и так все хорошо". Приходилось убеждать, пилотные версии вообще за свой счет ставили (с условием что мы потом будет обслуживать и з это уже деньги получать плюс чтобы иметь работающие объекты).
Софт весь был наш, железо тоже наше (контроллеры - "домовые" + УСО - Устройство Сопряжения с Объектом - то, к чему, собственно, подключаются устройство). Только конечные устройства те, что стояли уже на объектах. Все протоколы связи сами писали. Разрабатывали формальную классификацию устройств для горячего подключения.
В конечных версиях были инструменты для создания карт-подложек (из яндекса или 2ГИС), "редактор объектов" где можно было размещать устройства на карте.
Там много чего было. В конечной версии вообще был "клиент-сервер" - микроядро, обеспечивающее работу с контроллерами и подключаемые к нему интерфейсные клиенты разного типа и назначения (для диспетчера, для администратора, для аварийных бригад, монитор разработчика, позволяющий трейсить все, что происходит в микроядре удаленно в реальном времени...)
Все это было распределенное - УСО к домовому котроллеру по RS485 подключалось, дальше уже домовые с микроядром по UDP. Интерфейсные клиенты к микроядру по TCP подключались.
В каком оно сейчас состоянии не знаю - в 17-м году ушел оттуда, там административные заморочки начались неприятные. Хотя был одним из немногих (4-5 человек), что был в проекте с самого начала.
И все это силами очень небольшой команды - "координатор", один человек на разработке контроллеров, один на разработке аналоговых частей системы (блоки питания, модули ГГС - громкоговорящей связи), на софте верхнего уровня сначала я один был, потом еще один человек пришел - я занимался микроядром и парой-тройкой служебных утилит, второй человек делал интерфейсные клиенты. Ну и плюс был участок сборщиков и монтажников. Но в разработке всего 5-6 человек на все - и софт и железо.
Но в Лифтопедии до сих пор есть :-)