Диспетчеризация

В этой статье хочу рассказать и поделиться своим мнением насчет пользовательских интерфейсов scada-систем и систем диспетчеризации в целом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Топология

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

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

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

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

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

Цвета и темы

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

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

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

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

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

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

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

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

Некоторые свежие наработки конца 2020 года.

Заключение

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

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

В прошлом году сделали пилотный проект по облачной диспетчеризации для одной из сети АЗС.

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

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

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

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

Получилась примерно такая картина из систем АЗС:

• освещение внешнее

• освещение внутреннее

• отопление радиаторное: электрическое, внутреннее

• тепловая завеса на входе (спойлер очень энергозатратная)

• вентиляция

• кондиционирование

• промышленный холод: холодильники для продуктов глубокой заморозки

• технологии приготовления пищи: оборудование для фастфуда, микроволновки

• технологии заправки (отдельная история на сладкое)

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

Чтобы не увеличивать расходы, мы предложили не только выстроить работу всех систем, но и использовать облачную диспетчеризацию. Это и есть основная фишка проекта. Суть её в том, что не нужно помещение, колл-центр, серверное оборудование и собственно диспетчер. Вместо этого есть Облако КРОК (привет, коллеги!), специализированная цифровая платформа и веб-интерфейс, к которому заказчик получает доступ с любого рабочего места. Никакого капекса: компания покупает услугу облачной диспетчеризации по подписке и ежемесячно по тарифу оплачивает услугу. За это она получает не только инфраструктуру, но и сервисную поддержку по решению.

Настройка систем

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

В случае с внутренним освещением сделали автоматическое включение и выключение света от датчика присутствия во всех технических зонах и помещениях с непостоянным присутствием персонала. Есть, например, кабинет менеджера АЗС. 60% времени менеджер проводит вне его стен. А так как это небольшая тёмная комната без окон, то человек, выходя, часто забывает свет погасить. Знакомо? Теперь свет отключается автоматически по датчику.

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

Согласовали режимы систем вентиляции, отопления, кондиционирования. Настроили так, чтобы их работа не пересекалась и не было задвоения. В аппаратах, которые готовят еду, выставили режимы в зависимости от времени суток и количества посетителей на заправке. Логика простая: ночью гонять аппарат, который греет сосиски для хот-догов, нет смысла. И, конечно, в обычной ситуации никакой оператор или диспетчер не будет следить, чтобы в определённое время эта самая сосикогрейка отключилась.

Вот еще парочка слайдов:

Кастомный подход

В проектах по автоматизации всегда важно, каким образом алгоритмы взаимодействия выражены в железе, в реальных датчиках и исполнительных устройствах на площадке. Мы взяли за основу технологию KNX. Это коммуникационная шина, которая используется для автоматизации зданий. Для конфигурирования сетей KNX основной программный продукт ETS. Но в нём нет кастомного программирования, это всегда делается внутри программируемого логического контроллера (ПЛК). Нашли подходящий для наших задач контроллер и добавили егов уже существующую на АЗС систему автоматизации.

ПЛК выполняет несколько функций:

• облачный шлюз;

• шлюз, в котором можно загрузить локальную диспетчеризацию и через приложение управлять конкретной АЗС в случае, если связь с облаком нарушится. Например, выставлять уставку по любому из помещений;

• накопление статистики по работе и последующее усовершенствование алгоритмов взаимодействия.

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

И вот тут самое время сказать про ту самую изюминку в проекте топливную автоматику. Штука для АЗС нужная, многие заправки её используют, да и нам самим было действительно интересно её сделать. Честно, это оказалось мегасложной задачей. В комплектную топливную автоматику (систему управления, поставляемую вместе с топливной системой АЗС) зашито более 1000 параметров, которые мы научились вытаскивать, с кодами ошибок и онлайн-результатами, самодиагностикой сбоев.

Вот как это выглядело в интерфейсе:

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

Минус 20%

Интерес к облачной диспетчеризации множится, когда заказчик имеет не один объект, а много объектов, причем распределённых, в разных районах или регионах. При чем объектов достаточно небольших и простых, чтобы было экономически невыгодно создавать на каждом из них отдельную систему диспетчеризации. Ситуация: звонит оператор заправки, сообщает о проблеме жарко в помещении. Туда выезжает сервисная бригада, смотрит, что случилось, надо ли кондиционер настроить. А оказывается, что дело в вентиляции. Нужен электрик, который с ней разберётся. Это второй выезд. А так как заправки раскиданы по региону, то и расстояния значительные. В конечном итоге это все складывается в эксплуатационные затраты. А наша система позволяет увидеть и определить, вообще в кондиционере дело или нет?.. Значит, заказчик сразу может понять, какой мастер нужен на той или или иной АЗС.

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

А теперь главные цифры. По факту за счет автоматизации нам удалось увеличить энергоэффективность на 20%, по сравнению с обычной, неумной, АЗС. Кстати, по первоначальным расчетам, экономия на электроэнергии для одной конкретной заправки должна была составить не менее 12%. Но поскольку проект пилотный, и мы действительно заморочились тонкими настройками, процент существенно вырос. Расчетный период окупаемости проекта 3-3,5 года. Ну а если представить, что подписка на облачную диспетчеризацию есть на 10-20-30 заправках, легко понять, что экономия будет ощутимой. Ну и имидж энергоэффективного предприятия еще никому не помешал.

Фотопруф для наглядности:

Продолжение следует

Проект этот у нас продолжается, кстати. Сейчас работаем с АЗС той же сети, но уже в другом регионе. Заправки не идентичны, и на втором объекте мы подключились на этапе проектирования. Постарались максимально все предусмотреть в проекте.

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

Моя почта - ITsarev@croc.ru. Если остались вопросы, пишите - обсудим.

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

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

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

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

Лонгрид!

2014

Это индивидуальный тепловой пункт одного из павильонов ВДНХ в Москве, первый самостоятельный объект, где можно было проявить творческий подход. В помещении ИТП на шкафу управления установлена 7 дюймовая сенсорная панель для локального управления и облачная система диспетчеризации. Несмотря на то, что в этом интерфейсе довольно все криво и сыро, здесь есть много элементов и правил, которым мы придерживаемся до сих пор.

С самого первого объекта я начал применять темный интерфейс. У специализированных программ (AutoCad, Photoshop), был темно-серый интерфейс, в нем было комфортно работать долгое время и я решил придерживаться их идеологии. К тому же, помещение ИТП было без освещения и очень темным, делать яркий светлый фон на панеле просто издевательство над эксплуатацией. Хотя сейчас у нас в портфолио есть кейсы со светлой темой, все равно, на сегодняшний день предпочтение отдается именно темной.

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

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

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

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

2015

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

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

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

2016

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

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

Структура меню не изменилась, изменился немного дизайн. Добавились иконки в пунктах меню. Иконки декоративные, какой-то пользы они не несут, скорее просто иконки ради иконок. Здесь они крупные, выполнены в стиле Flat, занимают прилично место на экране. В дальнейшем от иконок мы не отказывались, они стали меньше и аккуратнее и лучше вписываются в общую стилистику. Стоит применять иконки или нет в пунктах меню ответить однозначно сложно. Думаю, что так же как и с 3Д картинками, не под все пункты меню можно подобрать подходящие по стилю и смыслу иконки. Если есть возможность добавить аккуратные иконки, не уменьшая полезную площадь подписей, то лучше их добавить, они разбавят табличную структуру меню.

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

2017

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

2018

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

Основное отличие подхода к разработке этого интерфейса от предыдущих, это то, как рисуется вся статика. До этого интерфейс собирался по частям в среде разработки для панелей и в Scada системе, это очень усложняет процесс, особенно, выравнивание объектов. Здесь же вся статика делается в графическом редакторе и подгружается одной картинкой PNG на экран. Сверху накладываются только переменные и анимация. Это сразу убивает несколько зайцев: выравнивать и делать отступы можно с большой точностью, скорость загрузки страниц увеличивается, так как нужно меньше информации подгружать из памяти, уменьшается нагрузка на процессор.

С точки зрения дизайна, тут появилось много нового. Появился не стандартный шрифт GothamPro, цвета теперь не рандомные, а подобраны из палитр Material Design, появились кратные отступы и сетка. Объекты теперь выровнены все относительны друг друга. Поля индикации и ввода значения уже стали существенно различаться, к этому быстро привыкаешь и пользоваться становится удобно.

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

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

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

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

Что касается главного экрана, то здесь реализован "карточный" интерфейс. Смысл его в том, чтобы структурировать информацию по системам, на каждую сделать свою карточку и разместить ее на схеме здания. Если систем много, можно разделить их по нескольким экранам, если не много, то можно все показать на одном экране и отделить разные схемы цветами. На карточке нужно отображать только самые основные параметры, которые влияют на работоспособность установки и которые можно сравнивать между собой. Для вентиляции наиболее важными параметрами являются: статус работы, наличие аварий, режим зима/лето, температура канала, помещения и обратной воды. Дополнительно стараемся отображать обороты вентилятора, процент открытия клапана и задание уставки температуры. Эти значения позволяют быстро оценить стабильность работы вентсистем и теплоснабжения установок, не переходя к схемам каждой системы отдельно. Очень удобно на одном экране сравнивать параметры работы разных систем. Если, например, наблюдается недогрев по многим системам, значит есть проблемы с теплоснабжением из котельной.

У нас есть объекты, которые имеют один этаж и там удобно все карточки систем размещать на планировке здания, привязывая к их реальному местоположению на плане. Есть объекты в 4-5 этажей, и здесь становится сложнее структурировать карточки. Можно разделить экран на 4 равных части и на каждом отобразить свой этаж с системами. Можно сделать 4 экрана, на каждом свой этаж с нанесенным на нем системами, но здесь могут быть нюансы, как правило, большая часть систем располагается на -1 этаже и на последнем или кровле, что приводит к сильному дисбалансу. Мы пробовали разные варианты, расскажу об этом чуть дальше в статье.

2019

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

Здесь мы опять решили пересмотреть дизайн интерфейса и внести что-то новое. Наконец-то полностью ушли от 3Д, теперь у нас все плоское. Идея была уйти от 3Д, тем самым убрать лишние не информативные элементы со схемы, освободить ценное место и структурировать информацию не по графическим элементам, а по карточкам. Раньше, чтобы показать информацию о теплоснабжение установки (работа насоса, клапана, температура обратной воды) нужно было нарисовать целый узел с трубами, насосом, перемычками и прочим, это занимает много места и несет мало информации. Теперь вся эта информация находится в карточке "нагрев", точно так же структурированы и другие карточки систем. Такая структура дает унификацию интерфейса, если появится система, например, с дополнительным увлажнением или ступенью нагрева, то мы просто добавим новую карточку с нужной информацией, при этом интерфейс будет выглядеть одинаково преемственно на разных устройствах и разрешениях. Точно так же легко унифицируются и различные системы, вентиляция, отопление, освещение, энергетика, водоснабжение и так далее, все это легко приводится к одному стандарту и упрощает взаимодействие пользователя.

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

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

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

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

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

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

Здесь очень удачно планировка ТЦ вписалась в разрешение Scada системы примерно 1920 х 980 рх., это позволило расположить максимум полезной информации с привязкой к физическому местоположению. Так как систем много (около 150 штук) то лучший вариант разбить их по венткамерам, где находятся щиты управления, отобразить системы как название и подкрашивать его в зависимости от состояния. Серый выведен из эксплуатации, белый стоянка, зеленая работает, желтая требует обслуживания, красный авария. Дальше архитектура строится так: при клике на венткамеру открывается табличный вид связанных систем с их основными параметрами. При клике на название системы уже откроется мнемосхема со всеми доступными параметрами и настройками.

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

2020

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

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

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

Если вы дочитали до этого места, то скорее всего обратили внимание, что впервые появился светлый интерфейс =). Появилась очень интересная идея сделать универсальный интерфейс с темной и светлой темой и переключать его либо автоматически от времени суток, либо вручную. Реализовали эту идею так: подложки на 95 процентов прозрачные с небольшим оттенком серого, статические элементы имеют цвета не сильно контрастирующие на темном и светлом фоне, переменные имеют подобранный серый цвет, больше контрастирующий на темном и светлом фоне. По сути, мы только меняем цвет фона с белого на темно серый, а все элементы остаются без изменения. С точки зрения работы Scada системы процесс максимально простой, подмена одного фона на другой, без замены других элементов, это не перегружает процесс работы и отрисовки. У такого решения есть минус, сложно подобрать цвета одинаково правильно отображающиеся тут и там, от этого переменные немного теряются на общем фоне. Есть вариант вместе с фоном менять скриптами и цвета переменных и других элементов, но не понятно насколько это может загрузить процесс отрисовки.

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

2021

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

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

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

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

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

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

2022

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

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

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

Клиент: крупный логистический центр в Московской Области, с которым мы работаем с 2016 года. За это время мы провели уже много работ по диспетчеризации инженерных систем, вывели в единую BMS вентиляцию, котельную, энергетику, отопление, энергоучет и много чего еще. А в этом году решили добавить еще и диспетчеризацию освещения в общую систему.

Что имеем? Установлен силовой шкаф управления освещением на 45 линий: складские ряды, коридоры, мезонин. На каждой линии установлен автомат защиты и модульный контактор. Помимо силового щита есть щит управления с ручным и автоматическим управлением. Автоматическое управление подразумевает включение и выключение линии по датчику движения, которые установлены в рядах, где двигается техника. Некоторые линии находятся в ручной режиме и постоянно включены, а некоторые, наоборот выключены. Задачу нам поставили следующую: отслеживать работу каждой линии, отслеживать залипание контакторов, оповещать о неисправностях и получать аналитику по наработке. Можно было бы полностью заменить шкафы, сделать дистанционное управление, расписание и много чего еще, но это было бы очень сильное удорожание проекта, а нас попросили именно вписаться в небольшой бюджет не меняя того, что и так работает стабильно.

Задача поставлена, начинаем реализацию. Есть несколько способов отследить работу линии освещения. Самый простой способ это использовать свободный или дополнительный контакт модульного контактора. Но конкретно в нашем случае эта схема не сработает, так как питание катушки контактора идет от общего автомата и возможна ситуация, когда на линии освещения контактор будет замкнут, а автомат выключен и питания на линии не будет. Этот способ будет работать только если питание катушки контактора идет из под автомата этого же контактора. Можно было бы поставить дополнительные контакты положения и сработки к автоматам, это даст более полную картину, но в нашем случае места в шкафу не было от слова совсем и раздвинуть автоматы для дополнительных контактов просто не было возможности. Решили пойти самым надежным путем, взять непосредственно фазу, идущую на питание линии и завести ее на контроллер. Так как у нас большая часть автоматики на объекте сделана на отечественных Контарах, то мы просто взяли модули расширения, которые воспринимают 220 вольт на входе. Это не частая опция у контроллеров, поэтому, если бы стоял другой производитель, пришлось бы ставить 45 промежуточных реле. Получился аккуратный и не большой шкаф диспетчеризации, мы повесили его рядом с силовым шкафом и обвязали все аккуратно многожильным кабелем. Расключение шкафа и отключение света согласовали заранее, а на все работы ушло около 1,5 часов.

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

Дальше разрабатываем интерфейс пользователя.

Здесь 46 линий разбитые на 2 экрана. Порядковый номер, состояние линии (включена, выключена, неисправна) и комментарий. Внизу есть оперативный график, можно посмотреть, как менялось состояние линии за последний час. Линии можно переключать, на скриншоте выбрана 16 линия.

На этом экране можно получить оперативную информацию о состоянии освещения. Есть отдельные окна трендов и настроек.

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

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

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

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

Вторая страница отчета выводит ту же информацию, но в виде диаграмм.

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