Дизайн
Evgeny Chestnov
7130

Что не так с интерфейсами SCADA-систем

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

В закладки

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

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

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

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

​Пример интерфейса, собранного из готовых библиотек
​Пример интерфейса диспетчеризации теплового пункта

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

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

Для начала посмотрим, какие интерфейсы наши коллеги делают для «умных» домов:

​Пример интерфейса, с сайта iridiummobile

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

Интерфейсы «умных» домов разнообразны: они могут нравиться или нет, могут устареть через пару лет или сохранять актуальность годами, быть выполненными в дизайне iOS или Android, могут быть удобными или неудобными, но вне зависимости от всего этого — они прорабатываются и на них тратятся ресурсы и время.

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

​Анализатор качества электроэнергии

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

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

Компании нужно максимально быстро предъявить свою работу и подписать акты, чтобы получить деньги — для этого вентилятор должен крутиться, а зеленая лампочка гореть. Тут уже не до красоты, на нее нет времени, никакой заказчик не станет срывать сроки, чтобы лампочку сделать красивее.

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

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

В-третьих, широко распространено мнение: «Мы делаем скаду для техника, а ему нужна большая зеленая кнопка и большая красная лампочка, красивые картинки ему не нужны».

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

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

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

Немного резюмируя

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

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

Что будем делать?

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

Один из объектов 2016 года. Панель оператора станции водоподготовки. Здесь много лишних ужасных рисунков, переменные неочевидные и теряются в синей обводке, лампочки взяты как раз из стандартной библиотеки

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

​Панель оператора системы приточно-вытяжной вентиляции. 2017 год. 7 дюймов разрешение 800 х 480

Цвета подобрали из палитры material design, отрисовали заново все иконки, сделали ровные и кратные отступы, подобрали шрифт и его размер. Тогда мы еще использовали трехмерные картинки и анимацию.

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

Сейчас мы уже делаем по-другому, абсолютно вся статика создается в Photoshop и подгружается единой картинкой, поверх которой отображаются все переменные и динамические объекты. Так мы можем ровно сделать верстку и снизить нагрузку на систему, так как панель будет подгружать один файл, а не десятки картинок.

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

Та же панель, но уже в актуальном дизайне, 2020г год

Подложка, подготовленная в фотошопе, осталось только разместить переменные.

А вот так выглядит мнемосхема диспетчеризации. На общем плане здания расположены все инженерные системы: вентиляция административных блоков, вентиляция склада, ВРУ, установки компенсации реактивной мощности, котельная, температурное картирование, септики, энергоучет.

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

​Рабочее место инженера, монитор 27 дюймов, разрешение 1920 х 1080
​Развернутое окно с настройками системы вентиляции

Здесь диспетчеризация развернута на базе российского производителя К2 от МЗТА. Тумблеры и уставки сделаны штатными средствами, так как пока нет поддержки сторонней графики, пришлось максимально адаптировать их в интерфейс.

Подробнее о создании интерфейса диспетчеризации

Еще один очень значимый проект для меня мы реализовали в 2018 году — это крупный ТРЦ в Московской области. На примере этого проекта поделюсь своим опытом и знаниями, надеюсь, кому-то это будет полезно.

Главное окно системы диспетчеризации вентиляции

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

Топология

Главное окно вентиляции у нас содержит план ТРЦ, вид сверху, обозначения секций и расположенные на нем вентиляционные установки, привязанные к венткамерам и их фактическому расположению. Так как информации очень много, нам нужно вывести на главное окно только самую необходимую.

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

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

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

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

Цвета и тема

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

Да и в целом темная тема проще для восприятия и меньше нагружает глаза, тем более при длительном использовании, тем более в темном помещение.

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

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

Шрифт и отступы

Тут все проще, используем GothamPro, только двух размеров: для подписей и статики 14 рх Medium, а для переменных 18 рх Bold.

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

Еще несколько окон с этого объекта.

Заключение

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

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

Ссылка на проект логистического центра:

Ссылка на проект торгового центра:

На сайте можете посмотреть другие наши работы.

Наша группа специалистов по автоматизации и электрике в Telegram.

{ "author_name": "Evgeny Chestnov", "author_type": "self", "tags": [], "comments": 45, "likes": 10, "favorites": 44, "is_advertisement": false, "subsite_label": "design", "id": 116964, "is_wide": true, "is_ugc": true, "date": "Thu, 02 Apr 2020 17:08:15 +0300", "is_special": false }
Объявление на vc.ru
0
45 комментариев
Популярные
По порядку
Написать комментарий...
1

Когда то сделал HMI в модном стиле glass . Сейчас смотрю и ужасаюсь. Под аля 90-е гораздо лучше смотрятся поекты. ( хорошое красиво стареет). Думается темная тема уже года через три будет ужасом дизайна.

Ответить
1

Согласен, чем необычнее формы, цвета, тена, линии- тем быстрее это все превратится в прошлогодний ужас)). Темная тема обусловлена не столько модностью, сколько уровнем освещенности помещения. Для панели это часто бывает очень актуально, в венткамере может сумрак стоять, а панель яркая, еще и белый фон будет слепить.
У нас был проект в том году, мы сделали два интерфейса, темный и светлый, сменяемый. Светлый мне больше нравится.

Ответить
0

Классно, современно, отличный продакшн. Почти авионика 🙂. А общяя мнемосхема на другой эйчэмайке?

Ответить
1

это бортовой компьютер яхты, единая панель управления всеми системами у капитана. Панель Weintek 12 дюймов, 1024х768. Напишу отдельную статью об этом проекте, там много чего интересного)

Ответить
0

Только обязательно напишите)

Ответить
0

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

Ответить
1

охотно верю, занимаюсь HMI/UI для безопасности мореплавания, та же фигня. но материалом весьма порадовали, у меня вся команда сидит читает)

Ответить
0

Рад, что материал полезен. На сайте есть еще объекты интересные, так же, если нужны будут какие-то иконки или наброски, пишите, поделюсь без проблем

Ответить
1

Редкий, на мой взгляд,  случай - не только профессиональное понимание сути предмета, но и технически грамотный русский язык + творческое отношение к тому, чем занимаешься. Мы работаем "рядом" в разработке системы категории CAFM/IWMS для управления корпоративной недвижимостью. Встречаемся с Вашими коллегами по BMS не на презентациях, а на земле - в основном творческого подхода не наблюдаем, куют план и сокращают издержки за счет всегда недовольного дошираком песонала. Может быть даже интересно было бы попробовать "спариться" для получения исчерпывающей интегрированной системы управления корпоративной недвижимостью  BMS+IWMS. Люди "на земле" практически всегда спрашивают о возможности обработки BMS-сигналов  с контроллеров в нашей системе управления работами ValMaster FM/FSM. Мы отвечаем - давайте Ваши контроллеры от Ваших подрядчиков к  нам на учет и мы будем автоматически формированть системные заявки и наряд-заказы с назначением исполнителй если надо, но практически все ничем и заканчивается - бытие определяет сознание, за пределы того что умеют не заступают, и то что надо клиенту предложить не могут - а клиенты не всегда имеют профессиональное понимание сущности и масштаба задач будущего управления недвижимостью.

Ответить
0

Я суть основную понял, но для какой-то конкретики нужно сидеть разбираться и обсуждать, идея интересная

Ответить
0

вдогонку вопрос - если в какой-то инженерной системе вместо одого насоса решили поставит два (уже после запуска BMS) - все соответствующие экраны надо перерисовывать в фотошопе единой картинкой - пользователь сам может скорретировать схему?

Ответить
1

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

Ответить
0

Понятно. А кроме Вас эту корретировку никто не может сделать из параллельных миров? Наверное Вы что-то говорите по этому поводу заказчикам на их обычный вопрос - "а если....."

Ответить
1

За исключением очень редких случаев, все исходники передаются заказчику, точно так же как и права на интеллектуальную собственность. Имея все исходники заказчик может привлечь кого захочет, или может сам сделать работу если захочет в этом разбираться. Если исходников нету, то да, это большая проблема, почти все нужно будет делать заново.

Ответить
0

В 21 веке рисовать интерфейс "пересобираемой" системы в Фотошопе это просто верх деградации отрасли.
Я не про автора и его попытки сделать хорошо и удобно.
Интересно, почему при огромном количестве программистов незнающих чем заняться, не рождаются новые современные СКАДы, но плодятся фреймворки для онлайн магазинов?

Ответить
1

потому что для рождения новой системы уровня  СКАДы нужен широкий и глубокий технический кругозор и аналитика того, что уже есть, нужна профессиональна постановка задачи (местный инженер АСУ постановку задачи сделает только в меру своего понимания работы котельной), наконец нужны гибкие и обученные нестандартно думать мозги, чтобы правильно вставленными руками эту задачу решать. А для магазина достаточно ЕГЭ и пулеметных 3-месячных курсов по веб-программированию, ну или 3 курса любого ВУЗа с созвучными специальностями.
Точно такой же вопрос можно тиражировать практически на все сервисные отрасли (а эксплуатация - это сервис) - возьмите ЖКХ, все что появляется весьма примитивно и убого, рассчитано на эмоции потребителей телефоного трафика, а по управленческой и экономической  сути - унылое говно для печати счетов и сбора показаний счетчиков. И чт интересно - именно они захватили практически весь рынок - очевидно потомсу, что заказчики тоже по жизни с багажом ЕГЭ топают.
Ну а те, кто все еще могут и умеют и руки имеют, те не хотят связываться с геморроем новой разработки без уверенности ее востребованности рынком. Вот так - круг замыкается. И разорвать его могут только форейторы прогресса, пусть и пока с не всегда достаточным того что надо - это придет, если долбить в одну точку.. Но имено они будут двигать все, что отличается от тупой  бухгалтерии , пока их готовые решения не купят те, кто может только интегрировать,  но не разрабатывать - это обычный ЖЦ  любого продукта, но развитой капиталистическо экономике.

Ответить
0

Вырвиглазный вид делается потому, что
1. Требования стандарта цветовой политики компании, в которой внедряется продукт. Понятно, что у торговых центров и т.п. такого нет и можно самому выбирать нормальные цвета, шрифты и прочее, а в больших конторах типа Газпром и Роснефть есть свои стандарты расцветки.
2. С заскорузлостью самой отрасли АСУТП и SCADA-пакетов как следствие. Это просто отдельный мир, ортогональный современной разработке софта. Эти монструозные среды разработки от больших контор (шнайдер, сименс). Даже при взгляде на них ощущаешь боль. Эти недоделанные, криво выглядящие пакеты более игроков помельче. Вот это вот всё наводит тоску. Особенно удручают отечественные разработчики тип MasterScada и TraceMode - это просто два филиала ада на Земле. В замен, так сказать, почте и сбербанку.

А автору успехов!

Ответить
1

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

Ответить
0

Это simple-scada.com !?

Ответить
0

Да, она, торговый центр на ней сделан

Ответить
0

Сразу видно по дизайну. Хороший дизайн у simple-scada, выделяется среди всех.  

Ответить
0

Тут от интерфейса симпл скады только верхушки окон остались) все отрисовывается в фотошопе. Но в целом, симпл-скада сама по себе очень симпатичная, это пока лучшее с чем мы работали

Ответить
0

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

Ответить
0

Очень понравилась. В частности техподдержка, всегда помогает. 

Ответить

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

0

Покидайте примеров образцовых зарубежных скад. Я таких не встречал. Ну и с чего решили что мы криворукие?

Ответить
0

Чувство прекрасного это хорошо. Работаю в компании которая занимается автоматизацией для крупных промышленных комплексов. Зачастую стандартных библиотек просто не хватает в скадах, либо же они не подходят под наши критерии и приходится создавать самим. 
Как раз на текущий момент хочу заняться стандартизацией объектов, дабы каждый разработчик не колхозил на скорую руку свое. Да и понятие юзабилити хочется так же внедрить, во избежание каши на каждой мнемосхеме. На это всегда нужно время что бы ещё и описать, т.к. приходят новые люди в фирму и объяснять на пальцах как, что и почему мы делаем зачастую просто нет времени из за сроков.
Понимаю отрисовку подложек для оптимизации, но у нас такого к сожалению не получается. На ПНР это отнимает очень много времени.

Ответить
0

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

Ответить
0

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

Ответить
0

Посмотрите вот этот проект https://autonomnoe.ru/proektyi/avtomatizacia/ochistnye-sooruzheniya
это тот случай, когда картинок подходящих не существует в природе. Если нужны наши наработки, могу скинуть исходники в PSD 

Ответить
0

Спасибо, обязательно посмотрю.

Ответить
0

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

Ответить
0

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

Ответить
0

Добрый день, тоже сейчас будем работать с мастерскадой. А Вам под под какием системы картинки? 

Ответить
0

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

Ответить
0

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

Ответить
0

На мой взгляд главное, что затронуто в статье - это совсем не цвет фона и принцип отображения железок. Главное - это попытка представить огромный массив информации так, чтобы его можно было одним взглядом просканировать и оценить ситуацию - где плохо, где нормально. Для всех систем с множеством совершенно различных и динамично меняющихся параметров - это то самое юзабилити, которое хорошо получается в интернет-магазинах и прочей торговле, но фактически терра инкогнито в системах, перегруженных данными. Для случая BMS ситуация может быть несколько упрощенной, так как присутствуют только технические параметры и количество их невелико. Но если добавить экономических, организационных, контрольных, человеческих и прочих параметров - получается то, что стандартно решается пока на многих закладках. Но например, руководителю того же крупного ТЦ надо утром мазать бутерброд и одновременно получить всю картину работы его хояйства - от среднего чека и посещаемости до количества заявок от арендаторов и стоимости устранения отказов ключевого оборудования - фактически в  фоновом режиме. Сами мы пытаемся решить эту задачу, которая еще усложняется тем, что этот руководитель редко когда инженер и сплошной массив букв и цифр вряд ли воспримет лояльно. Нельзя назвать удачными и практики всяких видов диаграмм с несколькими параметрами - так как на них надо не просто посмотрть, а еще и врубиться - что и откуда. Так что опыт представленный в статье - весьма интересен имено с этой точки зрения.
А что скажут по теме интегрального представления данных присутствующие коллеги?

Ответить
0

Хорошая визуализация. Кто заинтеросовался может почитать про ситуацтонную осведомленность в HMI:
https://www.maxplant.ru/article/situational_awareness.php
А так же не плохо написано в этом цикле статей:
http://cleverhouse.club/software/dispatch/sozdanie-hmi-kotoryiy-rabotaet-chast-1.html

Ответить
0

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

Ответить
0

Делаем, но не часто, несколько комментов выше выложил интерфейс панельки, там вверху строка событий

Ответить
0

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

Ответить
0

У одного известного технологического гиганта есть такая технология TGML. Расшифровывается Tac graphic markup language. Где Tac название славной почившей под колёсами гиганта фирмы-создателя стандарта . Этот язык продолжает идеи xml, html с поддержкой js. Очень просто и удачно реализовано, и у такого подхода намного больше перспектив ввиду гибкости и возможности писать скрипты, и главное - обмениваться ими с сообществом. Если бы нашёлся энтузиаст, который сделал бы opensource интерпретатор, и графический редактор, это будет прорыв и новое слово в bms и industrial графике. Благо мощные инструменты есть и популярны - я имею ввиду vue, react и пр. Применяя такой подход вы сможете не просто рисовать подложку и на ней цифру, а полностью с помощью скрипта управлять сложным графическим объектом с десятками элементов, изменяя в его внешнем виде и поведении что угодно на ваш вкус, либо,  благодаря ооп подходу можете даже не интересоваться как там у него внутри все устроено, а просто пользоваться готовым. 

Ответить
0

А почему сразу не использовать html с js? Почему сразу не взять Vue или React?

Вообще главная проблема в АСУТП (мое ИМХО) - это то, что стандарты вроде бы и есть, но их по факту нет - все тянут одеяло не себя. Любая, даже самая малая контора пилит свой очередной "модбас-подобный" протокол.

Ответить

Прямой эфир