Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Это, наверное, холивар, но:
Всё что не несёт информации, а служит только целям дизайна и другим украшательствам, должно быть отброшено т.к. вносит дополнительный шум и распыляет внимание пользователя.
Категорически не согласен. Цель дизайна в таких системах именно помогать пользователю быстро находить нужные параметры. Если для этого нужен силуэт домика(=хранилище), это лучше чем плитки. Картинка вентилятора привлекает внимание легче, чем поиск группы параметров " слева, где-то посередине окно".
Особенно нужно избегать добавления каких-либо фотореалистичных изображений объекта и оборудования. Также недопустима любая анимация или мигание, особенно при нормальной работе оборудования.
Анимация и мигание может как раз служить индикацией нормального состояния системы (watchdog!).
И оператор редко пялится в экран круглосуточно.
Действительно, тема хорошего UI холиварна, как и любого дизайна.
Если для этого нужен силуэт домика(=хранилище), это лучше чем плитки. Картинка вентилятора привлекает внимание легче, чем поиск группы параметров " слева, где-то посередине окно".
Возможно, при условии что кто-то будет каждый раз перерисовывать этот силуэт и картинки под конкретный объект.
На практике, обычно если есть картинки в интерфейсе, то имеются жёсткие ограничения на состав и количество оборудования, например, поддерживается до 6 вентиляторов канала и до 8 датчиков температуры продукта.
Более того, часто в этом случае в интерфейсе показывается даже физически отсутствующее оборудование т.к. оно захардкожено в картинках, т.е. если на объекте вместо 6 вентиляторов только 2, то отображаются 6.
У нас нет никаких ограничений. Возможно где-то приходится чем-то жертвовать, но мы всегда очень стараемся скомпоновать удобный интерфейс под конкретный объект.
Также на мобильных устройствах этими картинками неудобно пользоваться.
Анимация и мигание может как раз служить индикацией нормального состояния системы (watchdog!).
Моя концепция и подход, описанный в книге «The High Performance HMI Handbook» (Hollifield, Oliver, Nimmo, Habibi), прямо противоречит этому)))
Примеры:
Пропала связь со всем оборудованием (в секции 2 уважнитель 1 выведен из работы, поэтому нет рамки):
Пропала связь сервиса UI с сервисом ядра SCADA
Мне кажется это намного нагляднее, чем следить за какой-то анимацией, означающей нормальную работу системы.
И оператор редко пялится в экран круглосуточно.
Да, поэтому обычно настраиваем SMS оповещение о самых важных событиях.
Ну вообще-то, "картинка" - это несколько слоев и уровней детализации. Те же устройства не рисуются на картинке хардкодом, а накладываются в виде иконки поверх изображения.
И да, в БД конфигурации есть привязки каждого устройства к объекту где оно расположено.
Анимация тут не нужна. Но понимать что и где у вас расположено очень помогает.
В обычной работе все эти цифры на экране постоянно не нужны. Нужно лишь понимать с первого взгляда - норма или нет. Ну иметь возможность посмотреть текущее состояние по конкретному устройству.
Я думаю что мы говорим о разных порядках стоимости внедрения системы. Я о примерно 1-5 млн. руб. за всю автоматику, включая наши устройства, датчики, шкаф с электроустановочными компонентами (автоматы, контакторы, реле), но без учёта силового оборудования (вентиляторы, клапана и т.д.).
Как дела обстоят на практике в интерфейсах с картинками в овощехранилищах, я описал в комментарии выше.
Для технологических линий предприятий да, иногда очень хорошо всё отрисовывают, с множеством экранов для каждого технологического процесса и т.д., но там и бюджет в 10, а скорее в 100 и более раз выше.
Но всё равно, мне ближе подход «взгляду не за что зацепиться» при нормальной работе, описанный в книге «The High Performance HMI Handbook».
Мы работали с ЖКХ, а там бюджеты...
Когда мы начинали (1993-й, на минуточку, год), "заказчику" вообще ничего не надо было "и так все хорошо". Приходилось убеждать, пилотные версии вообще за свой счет ставили (с условием что мы потом будет обслуживать и з это уже деньги получать плюс чтобы иметь работающие объекты).
Софт весь был наш, железо тоже наше (контроллеры - "домовые" + УСО - Устройство Сопряжения с Объектом - то, к чему, собственно, подключаются устройство). Только конечные устройства те, что стояли уже на объектах. Все протоколы связи сами писали. Разрабатывали формальную классификацию устройств для горячего подключения.
В конечных версиях были инструменты для создания карт-подложек (из яндекса или 2ГИС), "редактор объектов" где можно было размещать устройства на карте.
Там много чего было. В конечной версии вообще был "клиент-сервер" - микроядро, обеспечивающее работу с контроллерами и подключаемые к нему интерфейсные клиенты разного типа и назначения (для диспетчера, для администратора, для аварийных бригад, монитор разработчика, позволяющий трейсить все, что происходит в микроядре удаленно в реальном времени...)
Все это было распределенное - УСО к домовому котроллеру по RS485 подключалось, дальше уже домовые с микроядром по UDP. Интерфейсные клиенты к микроядру по TCP подключались.
В каком оно сейчас состоянии не знаю - в 17-м году ушел оттуда, там административные заморочки начались неприятные. Хотя был одним из немногих (4-5 человек), что был в проекте с самого начала.
И все это силами очень небольшой команды - "координатор", один человек на разработке контроллеров, один на разработке аналоговых частей системы (блоки питания, модули ГГС - громкоговорящей связи), на софте верхнего уровня сначала я один был, потом еще один человек пришел - я занимался микроядром и парой-тройкой служебных утилит, второй человек делал интерфейсные клиенты. Ну и плюс был участок сборщиков и монтажников. Но в разработке всего 5-6 человек на все - и софт и железо.
Но в Лифтопедии до сих пор есть :-)
Крайне неинформативно. Когда все нормально, никто не будет сидеть и пялиться в экран. А вот когда ненормально, должна быть полная информация - где? что? когда случилось?
Если у вас будет не оно хранилище, а, к примеру, 10 - все это на экран не влезет. Секция 1, секция 2 - где это? Что это вообще?
В своей время делали систему мониторинга инженерного оборудования зданий для ЖКХ (система диспетчеризации). Там лифты, охрана служебных помещений и много чего еще. Обслуживало оно достаточно много объектов разбросанных не только в пределах одного района, но по всему городу. Были объекты, где одних лифтов было по 300-500 штук подключено.
В основе интерфейса - карта на которой выделены обслуживаемые дома. Можно ткнуть на дом и получить его подробную схему - что где на нем расположено. Там же можно посмотреть текущее состояние любого устройства, его историю (что с ним происходило, архив событий и т.п.)
Если на доме "что-то не так", он подсвечивается отдельно.
Второй обязательный элемент - список аварийных сообщений куда выводятся события. Опять с полной расшифровкой на нормальном языке типа "ул. Строителей, д. 35, подъезд 2, грузовой лифт - двери шахты открыты".
Ведется полный лог - когда, где что случилось + реакция диспетчера (когда и что было сделано) - каждое аварийное событие требует "обработки" - реакции диспетчера.
Основы этого интерфейса закладывались еще в 93-94-м годах (мы были первыми в РФ кто начал работать в этом направлении) и получилось настолько удачно, что последующие разработки конкурентов в той или иной степени шли по тому же пути уже.
Диспетчеры зачастую - женщины среднего возраста, уровень среднего пользователя ПК. Осваивали интерфейс очень быстро - настолько там все было просто и интуитивно понятно.
Журнал событий и аварий есть, с поддержкой квитирования, просто в данном случае он в интерфейс не выведен, т.к. конкретному заказчику не нужен (настроено SMS оповещение на важные события).
Мы ведём разработку функций только если они нужны какому-нибудь заказчику. К сожалению, нет ресурсов разрабатывать универсальную систему. Само ядро SCADA с тегами универсальное, позволяет описать всё что угодно. Но на его базе нужно создавать оборудование с тегами, логические функции для их работы, компоненты UI. Всё это создаётся когда нехватает уже реализованных компонентов.
Карты (геоподложки) нет - пока никому из заказчиков не было нужно.
Конкретно ваш случай с лифтами - не вижу проблем в реализации на основе плиток. На домашней странице делаем плитки по районам города, в них выводим какую-то сводную информацию, например мы можем сделать расчётные теги, в которых бы выводилось сколько всего лифтов на районе, сколько с проблемами, сколько в аварии, сколько ремонтных бригад выехало на инциденты и т.д. Также рамка плитки может окрашиваться в красный цвет, если внутри иерархии есть аварийный статус тега, а на саму плитку этот тег не выведен.
Я вообще не уверен что в вашем случае с лифтами основой интерфейса должна быть карта города. И плитки наверное ненужны. Диспетчеру достаточно вывести журнал событий с квитированием, в карточке события будет адрес дома и ссылка на карту (Яндекс.Карты, 2 Гис и т.д.), в ней сразу интерфейс назначения ремонтной бригады сделать и т.д. Понятно что придётся написать отдельный модуль такого журнала для максимального удобства, но всё это возможно сделать на базе нашей системы.
Было бы интересно узнать как реализован механизм восстановления потерянных данных после восстановления связи верхнего уровня со средним уровнем. У вас же опрос приборов идёт 1 раз в секунду.
Не совсем понял, про какой верхний и средний уровень идёт речь. В статье описана иерархия уровней (экранов, окон) интерфейса пользователя (UI).
Обычно оба сервиса (ядро SCADA и UI) запущены на одном компьютере и общаются между собой по TCP через 127.0.0.1. Ядро опрашивает все устройства обычно 1 раз в секунду и хранит в памяти все текущие значения тегов, а также пишет изменившиеся значения в архив на диск. Если соединение между сервисами прервётся, то сервис UI периодически будет пытаться переподключиться к ядру.
Технически, каждая плитка выступает в роли ссылки и может ссылаться на любой URL где запущен сервис UI, в том числе эти сервисы UI могут быть подключены к своему ядру SCADA. Т.е. за плитками верхней (домашней) страницы может скрываться множество отдельных компьютеров со своими сервисами ядра и UI на разных объектах заказчиков, но обычно все плитки, по которым можно прокликать - это всё таки один объект заказчика (например, овощехранилище, состоящее из нескольких расположенных рядом складов-секций).
Архитектура системы (подробнее https://habr.com/ru/articles/1001024/):
Основные уровни в системе автоматизации (сверху вниз):
Верхний уровень (Уровень SCADA/HMI/Диспетчерский):
Функции: Визуализация процессов (мнемосхемы, графики, тренды), диспетчерское управление, архивирование данных, формирование отчетов аварийная сигнализация.
Компоненты: Рабочие станции операторов (HMI), серверы SCADA, HISTORIAN-серверы.
Средний уровень (Уровень управления / Контроллерный):
Функции: Логическое управлениевыполнение алгоритмов регулирования (ПЛК-программы), сбор данных от полевых устройств.
Компоненты: Программируемые логические контроллеры (ПЛК/PLC), распределенные системы управления (РСУ/DCS), удаленные терминалы (RTU).
Нижний уровень (Полевой уровень / Уровень оборудования):
Функции: Непосредственное взаимодействие с техпроцессом: измерение параметров и исполнение команд.
Компоненты: Датчики (сенсоры)исполнительные механизмы (приводы, клапаны, двигатели).
Теперь понял про что вы. У меня просто в статье есть главы "1. Верхний уровень – домашняя страница" и "2. Средний уровень – секция".
Тогда верхний и средний уровни из вашего перечня реализованы в сервисе ядра SCADA и сервисе UI (HMI).
Ядро напрямую общается с устройствами к которым подключены реле и датчики. У плат управления реле есть конфигурируемая настройка, что делать при пропаже связи с ядром, т.е. если ядро их не опрашивает, то что нужно им делать: ничего или всё отключить.
что-то напомнило вот это:
А где, собственно, интерфейс?
Решение подобных задач это круто.
Но как интерфейс это очень плохо, прежде всего тем, что очень большая когнитивная нагрузках в попытках считать:
из-за отсутсвия вёрстки, хотя бы банального выравнивания элементов цифр, независимость его от -/+ значений
красные рамки частично прилипают к именованиям объектов, отчего те не читаемы до конца
плохо просматривается или отсутствует иерархия объектов и их значений
на примере со слайдером не понятен ни шаг, ни границы значений
Про то, что утилитарное не должно быть уродливым, упомяну, но в отличии от вышеописанного, согласен обозвать вкусовщиной.
Средней руки дизайнер, пожелавший вникнуть в проблему способен очень сильно улучшить функциональность вашего продукта.
Даже чисто текстовыми средствами достигнуть можно шикарнейших результатов.
Согласен, очень много чего не доделано и есть много что можно улучшить, особенно в части интерфейса.
Основной упор при разработке системы был сделан на ядро системы и оптимальный алгоритм автоуправления климатом (3 раза практически заново переписывался). Но повторю, все доработки только за счёт новых заказов, а с этим в последнее время проблемы. Также вся разработка ведётся одним человеком в свободное от основной работы время.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы овощехранилище автоматизировали, разработали свою SCADA и железо. Часть 2: Информативный интерфейс SCADA