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

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

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

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

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

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

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

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

    Это моя любимая
    Это моя любимая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Топология

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

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

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

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

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

    Цвета и темы

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

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

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

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

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

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

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

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

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

    Заключение

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

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 103

      +7
      Когда мне говорят про хорошие современные интерфейсы — я хватаюсь за пистолет (почти (ц)).
        +6
        хотел бы сказать, что я не являюсь дизайнером и не получал такого образования, в моей команде тоже нет дизайнеров
        возможно, с этого и надо было начинать, чтобы такой серьезный текст можно было сразу воспринимать немного более критически.
          +4
          мы хорошие инженеры, программисты и проектировщики
          Если Вы используете SCADA системы, основная цель которых избавиться от программистов, то какую роль в Вашей команде выполняют программисты, тем более хорошие? Или это просто эникейщики? Предвосхищая взрыв негодования и снисходительного объяснения «для человека не в теме» — 20 лет назад я, уже будучи программистом с более чем 10-летним опытом, имел несчастье вляпаться в АСУТП и познать кого там принято называть «программистом». Те несколько лет, что я варился в этой области, я считаю самым бездарно потраченным отрезком своей жизни в профессиональном плане.
            0
            фреймворков не хватало :)?
              +1
              Именно так. Если уж к созданию верхнего уровня АСУТП привлекаются программисты, то им нужен именно фреймворк с полностью открытым исходным кодом, а не глючная закрытая поделка, которую представляет собой SCADA.
                +1
                Так самому приходится разрабатывать, правда комьюнити у скада разрабов поменьше, отсюда и сложности в реализации некоторых фич. Да и публиковать тоже не всё хочется, какими костылями приходится решать некоторые проблемы :) Например — в FactoryTalk SE как выводить «всплывающие сообщения»)) Как правило — это VBA внутри какой-то объектной модели — программируй — не хочу, почти все объекты доступны. Документировано обычно сносно, с примерами кода.
                Factorytalk, к примеру, хают больше сименсовской WinCC, зато контроллеры сименс — полная фигня по сравнению с американскими.
                Ну и скада — это тоже интерфейс между контроллером и системой аналитики, отчётов. В общем — любую задачу можно решить, но документации порой мало, и времени на её изучение не даётся, а пока разрабатываешь под старой системой — выходит новая версия, и костыли уже нужны совсем другие.
                  +1
                  И кстати, VBA позволяет подгрузить любую DLL и работать с функциями. Хотите — матрицы считайте через самописную либу, хотите — грузите код на DSP процессоры какой-нибудь платы в ПК, на котором скада. Но обычно всё ограничивается каким-нить коннектором SQL и парой несложных join (типа статистических данных по замесам по щелчку по календарю).
                  А так — хоть телеграм ботов прикручивайте, или машин лёрнинг)
                +3
                Можно развернуть проблему?
                  +1
                  Scada не призвана избавиться от программистов, это инструмент для программиста. Внутри нижнего и верхнего уровня много работы для программиста. Бывают сложные алгоритмы со многими сценариями, которые все нужно предусмотреть, не нужно еще и забывать про ответственность. Если скрипт будет написано не правильно и в ТЦ погаснет вдруг весь свет вечером, то может хорошо так прилететь. В АСУТП тем более, можно по ошибке остановить производственный процесс, остановка которого может стоить миллионы в час. Поэтому, да, у нас программисты и мы очень трепетно относимся к работе.
                    +1
                    Ни какой это не инструмент программиста, а именно попытка избавиться от программистов и заменить квалифицированный труд на менее квалифицированный. Если бы это изначально было ориентировано на программистов, то это была бы не закрытая SCADA система, а некий фреймворк и обязательно с полностью открытым исходным кодом.

                    По поводу ответственности я с Вами полностью согласен, но именно связывание программиста по рукам и ногам SCADA системой лишает разработчика принять на себя всю эту ответственность. О какой вообще ответственности может идти речь, когда какой-нибудь условный InTouch выбрасывает окно с сообщением «Error XXX in file YYY.cpp line ZZZ», а что именно содержится в строке ZZZ файла YYY.cpp известно только разработчикам SCADA? И дальше вместо нормальной работы начинается поиск обхода чужого косяка на ощупь методом тыка, попутно переписываясь с авторами сего поделия в надежде, что к следующей версией они это может быть исправят (попутно внеся новые ошибки).
                      0
                      … то это была бы не закрытая SCADA система…


                      OpenSCADA, RapidSCADA, CoreSCADA…

                      Мало? Напишите свой «фреймвёрк», все протоколы строго стандартизованы, интерфейсы детально документированы.

                      Не относитесь пренебрежительно к специалистам в тех областях, смысл которых лично Вам непонятен. Поверьте — они имеют полное право презирать Вас точно так же.
                        +1
                        В большинстве случаев выбор SCADA ограничен заказчиком — либо они с чем то уже работали и не хотят ничего незнакомого, либо «корпоративный стандарт» и т.д.
                        все протоколы строго стандартизованы
                        только далеко не все открыты.
                        Не относитесь пренебрежительно к специалистам в тех областях, смысл которых лично Вам непонятен. Поверьте — они имеют полное право презирать Вас точно так же.
                        это отношение не к специалистам, а к сложившейся в отрасли практике. И Вы правы, мне никогда не будет понятно стремление называть вещи не своими именами.
                          0
                          Мало? Напишите свой «фреймвёрк»
                          Во многих конторах с этого все и начиналось. Но потом пришли «эффективные менеджеры», и с тем же неистовством, с которым они сейчас вопят о «импортозамещении», тогда, в двухтысячных, они вопили «хочу SCADA, причем непременно от фирмы Siemens, Wonderware и т.д. (смотря кто им проплатил), потому что это — корпоративный стандарт». Именно тогда из отрасли настоящие программисты и побежали косяками, а на их место пришли эникейщики. Потом, правда, оказалось, что не все так красиво, как показано в презентациях, где благодаря магическому слову SCADA все задачи можно решить, посадив «девочку», научившуюся мышкой перетаскивать квадратики.
                        +1

                        Вообще-то это инструмент из-за которого программисты возникли как класс. Почитайте историю. Программирование вообще возникло как весьма примитивная программа управления ткацкими станками, где полёта фантазии вообще нет. Да есть легаси, потому что именно промышленность оказалась первой сферой готовой тратить средства на программистов. Да эта сфера не особо терпит всего нового, модного, молодёжного. Потому как надёжность — гораздо, гораздо дороже. Если думаете, что это проблема АСУТП и SCADA, то глубоко ошибаетесь. Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов. Я такое встречал как в АСУТП, так и в написании ПО для Medical Devices, авионике, морской навигации, даже в мега-портале юридической направленности. А всё потому что "красота" там спонсируется в последний момент. Средства скорее потратят на 5 лишних туров тестирования, чем на перерисовку. Потому что за "не красивый" интерфейс — максимум напишут просьбу улучшить. А за прокол в функционале, либо посадят, либо потребуют много денег. Именно поэтому в Enterprise и той же SCADA крайне мало OpenSource. Заказчик не хочет OpenSource по одной причине, если что-то случится по вине 3rd party библиотеки за которую заплатили деньги, отвечать будет разработчик той библиотеки, а в случае OpenSource — тот кто разрешил ее использовать в своём продукте. Никто не хочет неcти ответственность за то что сам не делал. Именно по этой причине данные отрасли так "нетерпимы" к OpenSource.
                        Если вам такое не по душе, лучше смотреть на IoT, web/mobile/application, game dev. Не даром эти отрасли являются локомотивами новых технологий.

                          +1
                          Вообще-то это инструмент из-за которого программисты возникли как класс.
                          здесь Вы путаете инструмент и область, в которой он используется. На заре автоматизации не было никаких SCADA систем в современном понимании. И когда появилась аббревиатура SCADA, она первоначально обозначала не инструмент, а саму систему (Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных). Специализированные инструменты появились много позже и переняли давно уже существующие название.
                          Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов. Я такое встречал как в АСУТП, так и в написании ПО для Medical Devices, авионике, морской навигации, даже в мега-портале юридической направленности.
                          Я не знаю, какие инструменты используются для юридических порталов, но в действительно ответственных применениях доминирует MISRA C, и только АСУТП пошло по пути создания своих недоязыков программирования.
                          Если вам такое не по душе, лучше смотреть на IoT
                          я в общем-то к чему-то подобному и пришел, только еще до того, как аббревиатура IoT стала широко использоваться, во всяком случае у нас.
                            0

                            АСУТП пошло путем создания своих языков, потому что все остальные языки программирования возникли позже. Тут смысл был дать возможность программировать технологам и инженерам, потому что слова программист тогда еще даже толком небыло. А когда появилось, таких людей было крайне мало, чтобы обслужить всю промышленность. Как должен был данный инструмент быть создан для людей которых еще не существовало?
                            SCADA тут конечно несколько сбоку, но отрасль накладывает свой отпечаток. Изначально для отображения использовались картонно-деревянные стенды с лампочками и цифровыми блоками. Вероятно, они были даже более читаемые, менее вредные для зрения, и даже возможно красивее интерфейсов особенно на первых дисплеях. Когда производство дисплеев стало дешевле, чем работа напильником по дереву, стали ставить дисплеи и изобрели SCADA системы для отрисовки всего того с чем прекрасно справлялись стенды из картона или дерева с лампочками. Собственно инструмент создавался для людей которые уже работали на производстве и создан намеренно просто, чтобы не требовалось дорогостоящее переобучение персонала. Вероятно сейчас стоит пересмотреть данную парадигму, потому как программисты уже не такой дефицит и скорее инженеров способных разобраться в релейных схемах или хорошо оперирующих элементами Буллевой логики найти будет посложнее.

                              0
                              АСУТП пошло путем создания своих языков, потому что все остальные языки программирования возникли позже.

                              Самый первый вариант МЭК 61131-3, на котором основываются все современные среды программирования ПЛК, был выпущен в 1993 году, когда всевозможных языков программирования существовало уже много десятков.

                                0
                                Первый не вариант, а стандарт!
                                А сами языки существовали, ну где то с 1959 года.

                                В 1979 вышел Simatic S5 уже с близким к этому стандарту видом программ.
                                  +1

                                  Ну вот язык Structured Text из стандарта МЭК явно во многом скопирован из классического Паскаля. Который появился только в 1970 году.

                                    0
                                    Да, он появился позже. Первыми были IL, LD, FBD
                                0
                                схемы с лампочками вполне существуют и работают параллельно с большими экранами скад, для них отдельные remote io даже ставят в проектах, а на скадах кнопку «тест ламп» делают.
                                а АСУТП на уровне плк — машина состояний, конечный автомат. Представляете, если светофор изза бага зависнет. Верхний уровень может быть каким угодно, хоть на сях. Нижний уровень — это rtos(часто vxworx), надстройки для обслуживания io и машины состояний + интерфейс к другим получателям или источникам данных.
                                Это как сравнивать операционную систему на процессоре и ПЛИС.
                                0
                                почему же только асутп, ещё есть ПЛИС, забыли про их недоязыки))
                                Наверное порекомендую инженерам АСУТП попробовать ПЛИС, как продолжение карьеры, у них и ЗП выше обычных программистских.
                                +1
                                Прекрасное замечание!

                                Как дополнительную иллюстрацию в аспекте КритическиВажных систем можно также привести пример с Бураном. При разработке бортового ПО был весьма успешно применён комплекс, в котором «недопрограммисты» (в терминах Сергея) «двигают мышкой квадратики по экрану». Можно сколь угодно смеяться над фанатичной увлечённостью Паронлданова и «идиотскими» названиями сущностей (например, «икона» вместо «программный модуль») — но в системе Дракон программированием пилотажного комплекса занимались специалисты в своих профессиональных областях: АСУ-шники, баллистики, аэродинамики, гидравлики. И все вот эти «недопрограммисты» «двигая иконы мышью» в кратчайший срок и почти без косяков создали сложнейший программный комплекс. Лично я не знаю ни одного «тру-программера», который при этом прекрасно разбирался бы в АСУ или гидравлике.
                                  +1
                                  Лично я не знаю ни одного «тру-программера», который при этом прекрасно разбирался бы в АСУ или гидравлике.
                                  Лично я не знаю ни одного технолога или гидравлика, который хорошо бы действительно хорошо программировал (хотя почти каждый из них кто это делает уверен в обратном). Серьезно, в том же асу, даже у людей с многолетним опытом, очень часто можно встретить такой код, что из глаз кровь течет и работает он исключительно из-за правильного положения звёзд на небе. Но снобизма при этом выше крыши. На Хабре о подобном уже писали не раз и не два.
                                  Так-то в этом нет ничего странного и страшного, когда каждый занимается всё-таки своим делом и делает это хорошо, но при этом понимает, что в смежных областях типа программирования совсем не является экспертом и использует специальные инструменты, облегчающие работу и предотвращающие ошибки. Для этого и придумали всякие абстракции, типа того же Дракона, МЭКовских языков, и т.д.
                                  Но рано или поздно абстракции всё-таки протекают и снова начинается цирк с конями, о чем и говорил Сергей в своем комментарии.
                                    0
                                    Продолжая дискуссию (мне нравится конфуцианская её сдержанность): лично я знаю лишь нескольких людей, которых могу с чистой совестью назвать «тру-программерами». Большинство моих знакомых «программистов» совершенно не владеют ни математическими, ни алгебраическим основами — и, хуже того!-- они в большинстве своём ужасно некультурны. Элементарно не могут найти общий язык с заказчиком (владельцем бизнеса).

                                    Именно это большая проблема.

                                    Касательно Сергея: в своих комментариях (он не единичен, Сергей оставил около десяти) уважаемый оппонент раз ра разом подтверждал лишь единый тезис: опытный программист, оказавшийся в не то время не на том месте и (извините, Сергей!) не удосужившийся получить качественное «высшее образование».
                                      +1
                                      Продолжая дискуссию (мне нравится конфуцианская её сдержанность): лично я знаю лишь нескольких людей, которых могу с чистой совестью назвать «тру-программерами». Большинство моих знакомых «программистов» совершенно не владеют ни математическими, ни алгебраическим основами.
                                      То есть по-вашему «тру» от «не-тру» отличается владением математическими и алгебраическими основами? Довольно странное суждение. В 60-70х годах так оно и было. А сегодня, в наши дни, специализаций и предметных областей у разрабочтиков ПО бесчетное множество. Для программистов важно аналитическое и абстрактное мышление, способность к построению длинных логических цепочек, умение глубоко разбираться в незнакомом ранее и используемых инструментах. Нюанс в том, что матеатические и алгебраические основы не являются для этого ни необходимыми, ни достаточными.
                                      Впоминаю одну из предыдущих команд, которая занималась разработкой программно-аппаратного комплекса для довольно непростых задач.
                                      В ней были:
                                      1. Программист-железячник, который писал BSP, драйвера и делал адаптацию RTOS для платы, которая была основой прибора.
                                      2. Программист-железячник, который разрабатывал код, работающий с кучей внешних подключаемых устройств и датчиков в разных форматах и по разным протоколам, собирал с них сырые данные и обеспечивал их передачу дальше на компьютер по сети.
                                      3. Программист, писавший код обработки этих сигналов на ПК (фильтрация, нормализация, демодуляция).
                                      4. Программист, писавший код отвечающий за анализ и моделирование процессов на основе полученных данных.
                                      5. Программист, отвечавший за хранение и визуализацию для оператора того, что было посчитано и смоделировано в результате всего этого (приложение на Qt).
                                      И вот в этой пестрой компании требования к знаниям и навыкам были очень даже различны. №3 и №4 отлично знали математику (выпукники физмата как-никак), и использовали ее во все тяжкие, от матанализа для DSP до вообще каких-то замудренных вещей при моделировании. Чел №1 глубоко рубил в железе, архитектуре использумой SoC и всем с этим связанным, но математики для его работы было достаточно на уровне 11 класса школы плюс дискретка (которая на самом деле не представляет собой никакой рокет-сайнс и до подавляющего большинства вещей в ней можно допереть просто интуитивно). №4 и №5 — примерно то же самое, а когда (очень редко) нужно было что-то большее, обращались за консультациями к №2 и №3. В свою очередь, когда у №3 и №4 возникли проблемы с нехваткой ресурсов (которые они уже не могли решить улучшением алгоритмов расчетов), №2 помогал решать им эту проблему, потому что глубоко знал C++, работу подсистем ядра используемой ОС и техники низкоуровневых оптимизаций кода.
                                      минутка юмора
                                      А еще один раз кто-то из этих кадров-математиков простейшую задачу «определить количество подряд идущих бит в числе и их смещение» решил в коде через логарифмы, что через какое-то время стало локальным мемом и поводом для шуток во всей компании :)
                                      И вот по вашим критериям, 1, 2 и 5 тут совсем «не тру». Хотя 3 и 4 без них бы с задачей не справились вообще.
                                      Вообще, конечно, дискуссия забавно выродилась: топикстартей делил разработчиков на «тру» и «не тру» по использованию инструментов, а вы — по знанию математики :)
                                      лирическое отступление
                                      В принципе, спор «насколько программистам нужна математика» идет уже десятки лет, причем как показывает практика, сторонники что того, что другого лагеря совершенно невосприимчивы к каким угодно аргументам, так что это уже напоминает религиозные срачи и участвовать в них откровенно скучно.
                                      Вот так оно и в жизни: есть огромное количество задач и предметных областей, где на первом месте из в первую очередь необходимых знаний и умений будет не математика, а другие вещи. Так что вы с Сергеем, скорее всего, мыслите просто в разных категориях. См. Не путайте разработку ПО и программирование.
                                      они в большинстве своём ужасно некультурны

                                      У вас есть какие-нибудь статистические данные, на сколько отличается % культурных и некультурных людей среди программистов в сравнении с другими работниками интеллектуального труда, например, инженерами-конструкторами, инженерами-строителями, маркетологами, бухгалтерами? :)
                                      Элементарно не могут найти общий язык с заказчиком (владельцем бизнеса).
                                      Опять же, это не всегда обязательно необходмый навык. В огромном количестве компаний программисты не общаются с заказчиками напрямую, это задача менеджера проекта или бизнес-аналитика. И вовсе не потому что «не могут», а потому что каждый должны заниматься своим делом.
                                      качественное «высшее образование».
                                      Проблема тут в слове «качественное». Подавляющее большинство образования, что у нас дается в вузах, особененно провинциальных, и даже в том числе весьма именитых, «качественным» назвать можно с очень большой натяжкой. А того, что осталось, на всех делающих явно не хватит.
                                        +1
                                        Мне кажется, это распространённое заблуждение, что программист — это профессия, требующая высшего образования. В странах, до которых девальвация высшего образования пока не дошла в полной мере (Германия, Австрия) программистов обучают в техникумах — это трёхлетнее среднее специальное образование.

                                        Если проводить аналогии с более старыми профессиями, есть рабочая профессия «сварщик», которой обучаются три года в училище/техникуме/колледже. Они имеют представление о физике/математике, отлично сваривают детали, особенно если известно какую к какой нужно приварить. Есть инженеры, которых обучают в ВУЗах 5-6 лет. Они разрабатывают технологические процессы, поэтому им нужно глубокое понимание физики, владение мат. аппаратом, но сваривать средний инженер всё равно будет хуже среднего сварщика.
                                        Все (надеюсь) любят сварщиков за их прямоту, остроумие и владение матом, и никто не будет упрекать хорошего сварщика в том, что он не удосужился получить высшее образование.
                                        Так и к программистам, как мне кажется, не нужно предъявлять повышенные требования только лишь на том основании, что работают они не в спецовке.
                                          0
                                          Сильно отхожу от темы, но если уж речь пошла о сварщиках, то я знал одного аж с двумя высшими образованиями.
                                            +1
                                            Мне кажется, по нынешним временам в России это довольно распространённое явление. Высококвалифицированный непьющий сварщик зарабатывает как правило в разы (а то и на порядок) больше среднего клерка с высшим образованием.
                                            Что, собственно, гармонично продолжает аналогию с программистами :)
                                              0
                                              Нет, это я не про нынешние времена, а про 80-е прошлого века.
                                    0
                                    Вообще-то это инструмент из-за которого программисты возникли как класс… промышленность оказалась первой сферой готовой тратить средства на программистов.
                                    Но со временем пришли к тому, что «каждая кухарка может управлять государством» в целях экономии. Мэковские LD и FBD придумали как раз для того, чтобы программы для промышленных контроллеров могли писать и модифицировать не программисты, а электрики и электроники.
                                    Бывает и наоборот. Возьмите Scadapack от Schneider. Они поддерживают как LD, так и C и C++, причем их C Tools (который вполне поворачивается язык назвать «фреймворком») умеет там и в многопроцессность с обменом сообщениями между процессами, и в примитивы синхронизации, и в кастомные обработчики IO протоколов, и в файловую систему, и в BSD-сокеты…
                                    Про какие-нибудь Advantech и ICP DAS я вообще молчу :)
                                    Да эта сфера не особо терпит всего нового, модного, молодёжного.
                                    Консервативизм — это хорошо, но не всегда. В мире разработки ПО VCS известны и используются уже лет так 30, но SCADA-системы или средства разработки для ПЛК, где есть приличная VCS или нормальная интеграция с существующими (хотя бы просто для версионирования и совместной работы) можно пересчитать по пальцам. В основном же наоборот, про подобное там даже и не слышали, а форматы файлов — бинарные и проприетарные, что лишает смысла даже просто класть их в Git. И это не имеет никакого отношения к «надежности», это именно дремучесть.

                                    Или возьмите, например, такую «молодежную» тему как инфобезопасность. Почитайте отчеты исследовательской группы SCADA Strangelove, такие детские дыры, как находят в SCADA и контроллерах очень именитых производителей и проектах известных интеграторов, нормально было бы встретить лет 20-30 назад, но уж точно не в наши дни. Тоже, наверное, ради «надежности» :)

                                    Этот отпечаток несут все Safety Critical сферы, где можно кого-то зашибить ненароком или подвисание программы выльется в милионы долларов
                                    Я несколько лет работал в компании, занимающейся софтом для авиации, и соседняя команда писала софт для работы авиадиспетчеров (тоже с очень серьезными требованиями к надежности и безопасности). И писали они его не на псевдоязыках или не на чем-то из 80-х, а на вполне современном для того времени C++11 с вполне современными Qt и OpenGL под вполне современный дистрибутив Linux. Были строгие стандарты кодирования (типа упомянутой выше MISRA, но для C++), тщательная проработка low-level и high-level требований и тестирование их выполнения, но без маразма :)
                                +3

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

                                  +1
                                  Так в том и проблема, что создаются примитивные средства разработки в расчете, что ими должны пользоваться не программисты, а специалисты в прикладной области (технологи и т.д.). Но последние умудряются и в таких игрушечных средствах косячить. И тогда раздается вопль «тут нужен программист», но нормальный программист тоже не может эффективно работать из-за примитивности инструмента.
                                  … поведение программы должно хорошо представляться и проигрываться в голове
                                  … не усложняй, не абстрагируй, проверяй, перепроверяй
                                  Если решаемая задача достаточно сложная, то только хорошее разложение по уровням абстракции может дать понятное, а значит надежно работающее решение. Если инструмент разработки этого не позволяет (или позволяет, но превращает разработку в борьбу с инструментом), то это никак не способствует правильному решению поставленной задачи.
                                    0
                                    Вот и получается, что ты хочешь сделать красивый, удобный, понятный и простой интерфейс, а тк редактор делается не для программиста, а для людей, которым соединить 3 алгоблока = программирование — не выходит из-за ограничений самого редактора. Иногда даже суровая реальность упирается в казалось бы очевидные вещи, например, некоторые примеры сделаны на ПО, в котором использовать шаблоны было невозможно до недавнего времени, как следствие — при массовом копировании каждого тега в каждом окне где-то всплывают незаметные глазу, но заметные при сравнении смещения и прочие шероховатости.

                                    Но всё же следует очень четко разделять АСУ ТП и BMS, также как и «орган принимающий решение» (будь то ПЛК/сервер/релейная схема) и индикацию = информирование о работе системы, а то мне очень не хочется, чтобы у меня была очень красивая машина, которая может взять и не поехать неизвестно почему.
                                      +1

                                      Непременно нужно именно написание кода в UI части? Предполагаются какие-то динамические действия, которые нужно описывать именно как алгоритмы, причём настолько уникальные от объекта к объекту, что их не заложить готовыми в библиотеку самой SCADA?
                                      Так то и в обсуждаемой статье ни слова о программировании, она больше о дизайне, и где-то там основная проблема и кроется — дизайн UI возлагают на тех же людей, кто программировал PLC ("они ж лучше знают что там внутри"), а им после месяцев глядения в технологическую схему ничего другого уже не видится — получаем "чёрно-зелёную консоль всевластия".


                                      Насчёт разделения управления и индикации — обеими руками за. Периодически общаемся с другом детства, ушедшим в "умные дома" — постоянно мат и жалобы на нестабильность работы новомодных "хабов", по сути совмещающих в себе PLC и web UI (да ещё и в виде какой-нибудь Raspberry внутри DIN-коробочки) — ребята, извините, но у Honeywell и для "гражданских" зданий PLC выглядели как нечто на RTOS, с интерфейсными цепями на керамике, и работало оно так, что на очередном техобслуживании разблокируешь панель и видишь то самое подменю, в котором оставил систему квартал назад. А на отдельном SCADA PC скучающие операторы тем временем втихаря от начальства в Doom играть могли.

                                    0
                                    В мелких конторах таким «программистом» считается инженер-электронщик, который умеет программировать, он же там и дизайнер, и конструктор, и даже иногда монтажник. Времени на красивый дизайн не остаётся. Для маленьких проектов где-нибудь на заводе такого человека хватает, особенно если учесть, что он работает за еду зарплату инженера-электронщика.
                                    +1
                                    мы знаем, как должны работать системы и как их нужно эксплуатировать, опираясь на это, хотим сделать максимально удобный для человека пользовательский интерфейс

                                    Очень хочется верить в это (без сарказма). Как по мне, и старые, и новые интерфейсы выглядят вполне неплохо с точки зрения UI, а вот с UX у меня опыта работы тут нет, так что оценить и сравнить не могу.


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

                                      0
                                      www.instagram.com/p/BryD9rzli34
                                      www.instagram.com/p/BqAxT-rlKvv
                                      В инстаграме были «до» и «после»
                                        0

                                        Спасибо за дополнительные примеры, интересно посмотреть. Первое "до" выглядит приемлемо (по мне), а второе — и правда жуть.

                                      –1

                                      А чем SCADA-системы отличаются от открытых систем домашней автоматизации? Например, Home Assistant.

                                        +7
                                        Примерно тем же, чем офисный центр — от двухкомнатной квартиры садового домика.
                                        0
                                        Добавлю, что графические интерфейсы SCADA могут и должны быть разными. Для АСУ в крупных зданиях (не «домашняя автоматизация») похожие «устаревшие» картинки не являются самым большим грехом. Диспетчер в здании не так часто и не продолжительно смотрит на дисплеи. Его задача быстро найти проблемную область и быстро принять меры. Ваш дизайн, подход к компоновке экранов мне понравился. Я видел несколько десятков подобных систем в крупнейших зданиях Москвы от различных интеграторов: российских и зарубежных. Помимо графики, у вас хорошо скомпонованы элементы управления и контроля, без перегрузки, все самое важное: четко и понятно. В 200-е годы в Москве это редко встречалось. Также важно, какие готовые элементы SCADA предоставляет сам производитель, чтобы интегратору не требовалось выдумывать велосипеды. У больших производителей типа Siemens, Honewewell, JCI дисплеи SCADA собираются, как правило, из готовых графических блоков, места для фантазии там остается мало.
                                        И таки нашел, что можно улучшить: положение клапанов, температуру подачи и(или) обратки теплоносителя в обвязке калориферов вентустановок лучше показывать сразу на мнемосхеме с вентустановкой. Ясно, что общий дизайн несколько страдает, но эксплуатация скажет только спасибо. Кстати, на «устаревших» примерах это есть.
                                          0
                                          Спасибо за отзыв.
                                          у вас хорошо скомпонованы элементы управления и контроля, без перегрузки, все самое важное: четко и понятно.
                                          стараемся следовать именно этому.
                                          у вас хорошо скомпонованы элементы управления и контроля, без перегрузки, все самое важное: четко и понятно.
                                          там где ТЦ, там разместили под калорифером, а вот на последнем примере убрал в меню. С замечанием согласен.
                                          +3
                                          Я не настоящий сварщик и UX/UI не занимаюсь, но курсы проходил.

                                          Что бы из этого я применил

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

                                          2. Про использование множества цветов. Хитрый момент в том, что если мы возьмем модель HSL и возьмем разные цвета по H, то это будут действительно разные цвета и выглядеть будет пёстро. Но если мы рамках одного H меняем S и L, то это будут вариации одного цвета.

                                          От себя рекомендую посмотреть блог Эрика Кеннеди на предмет UX/UI (Erik Kennedy).
                                            +1
                                            Спасибо за отзыв, полезная информация.
                                            +2
                                            Картинки из примеров в статье — самоделки и/или без опыта. Пытаться по этому экстраполировать на всю область — глупо.
                                              +1
                                              Мне чаще такие встречаются. Тем более по запросу «скада» в яндекс картинках, будут именно такие схемы
                                                +2
                                                «по запросу в яндекс» это очень плохой пример поиска образцов. Лучше брать из «историй успеха» топовых вендоров в данной области, например Honeywell Home, Andover Controls, Siemens SBT — всех на память не вспомню…
                                              0

                                              А какая причина была уйти от 3D? Сложно перерисовывать?
                                              Считаю, что объёмные варианты — самые естественные, а в этих иконках ещё разобраться надо что они имитируют.

                                                +2
                                                От части прорисовки тоже касается. С вентиляцией и тепловым пунктом понятно, там можно отрисовать набор качественных картинок. Но когда дело касается других процессов, то тут ступор. Как отрисовать в 3Д флотатор или обезвоживатель? Холодильный центр, тоже уже проблемно.
                                                Но мне в целом 3Д не кажется оптимальным вариантом. Картинки места много занимают а полезной информации не несут. Но это мое мнение на основе моего опыта, я могу ошибаться.
                                                  +1
                                                  Операторы вполне привыкли работать с технологическими схемами и им никакое 3D вообще не нужно, им важна информативность. 3D в основном используется для произведения хорошего впечатления при демонстрации «достижений» высокопоставленному руководству.
                                                    0
                                                    Тут как обычно два конца.
                                                    Если оператор — человек с улицы, ему надо чтобы задвижка на экране выглядела так же как и в живую, а труба была в виде объёмной трубы, иначе он не поймёт что там за линии и что за
                                                    треугольники бабочкой. Обучать человека с улицы чтению схем, ради того чтобы он мог включить/выключить вентилятор?
                                                    Однако если это серьёзное производство, велика вероятность что там есть технически грамотные специалисты и схемы коммуникаций, по госту, они в работе используют чертежи и привыкли читать чертежи, а когда они видят эту 3D красоту, возникают сложности с пониманием, что нафантазировал себе художник изображая осушитель по картинкам в интернете.
                                                      0
                                                      Брать на работу оператора без знания технологии процесса, а значит и знания схем — ну такое себе.
                                                        0
                                                        Брать на работу человека без знаний — нестареющая классика, любимое развлечение руководителей всех уровней в погоне за экономией. Поэтому в некоторых интерфейсах приходится рисовать картинки для идиотов, с краном в виде крана и вентилятора с анимированными вращающимися лопастями.
                                                          0
                                                          Я не работал на мелких предприятиях. У нас было всё по серьезному. Человек сначала несколько месяцев проходил обучение, потом экзамены, потом стажировка под присмотром и опять экзамены, и только потом самостоятельная работа. И никаких идиотских картинок.
                                                          Но если погуглить SCADA по картинкам, то там прям всё печально в 100% случаев.
                                                    +1
                                                    Общее замечание — в интерфейсах много где используется выделение важной информации цветом, при этом цвета используются одинаковой светлоты (например, на закладке вентиляция явно что-то не так с П2В2, П8В8 и совсем плохо с П1В1 и т.п.). Судя по всему сделано это умышленно (значения L в HSL палитре полностью совпадают) и наверное для красоты. Но в плане юзабилити это довольно опасно.
                                                    Во-первых, многие люди не различают некоторые цвета (причём, многие об этом не догадываются) и они просто не считают предупреждение. Во-вторых, чтобы эти сообщения перестали распознаваться, нужно просто достаточно устать от монотонной работы (попробуйте просто прищуриться, например). Наиболее наглядно видно как исчезает информация, если перевести картинку в ЧБ.
                                                    Вообще, есть хороший трик, которому обучают иллюстраторов — перед тем как начать работать с цветом, нужно набросать ограниченное количество цветов в оттенках серого так, чтобы картинка всё равно читалась, и при подборе цветов менять только тон и насыщенность.

                                                    В остальном смотрится классно и даже примерно понятно что происходит.
                                                      0
                                                      Спасибо. Про оттенки серого полезная информация.
                                                      явно что-то не так с П2В2, П8В8 и совсем плохо с П1В1
                                                      ткните пальцем, не очень понял где
                                                        0
                                                        Первая картинка в разделе «Подробнее о создании интерфейса диспетчеризации» и далее.
                                                        Явно задача жёлтого и красного цветов сообщить какую-то информацию оператору (жёлтый — требует внимания, красный — критический).
                                                          0
                                                          Проблема в одинаковой светлоте? Ярче должны быть они?
                                                            +2
                                                            Зависит от назначения. Если это просто для общей информации, можно оставить маркировку цветом, но разной яркости (значение L в HSL коде). Вообще, лучше исходить из того, что цвета одной яркости — один и тот же цвет в плане передачи информации. Проверить свою палитру можно, например, на coolors.co, там же можно и посмотреть как будут видеть цвета люди с различными отклонениями в восприятии цвета.

                                                            Если же требуется реакция оператора, на мой взгляд, лучше только на цвет не полагаться — либо добавить всплывающий символ, либо увеличивать размер надписи, либо сделать по принципу светофора (дополнительная кодировка расположением вверху/внизу). Как и во всём особо ответственном, нужно дублирование функции. Проще говоря — нужно иметь возможность считать важную информацию в ЧБ без особых затруднений.
                                                              0
                                                              Очень часто добавляют мигание на аварии, но она несколько раздражает, нужно учитывать, что аварию можно и не сбросить сразу, будет на экране мерцать разные значения, не очень приятная штука. Мы в диспетчерской очень много времени провели) и когда заходишь и окидываешь взглядом мониторы, то информация сейчас хорошо воспринимается. По поводу HSL, нужно понимать еще, что моники все разные, цветопередача очень разбегается.
                                                                0
                                                                Да, по-моему, одной из причин катастрофы Boeing 727 в Далласе в 1988-м году было то, что пилоты либо систематически отключали раздражающую систему предупреждения о невыпущенных закрылках, либо просто настолько привыкали к её, что игнорировали, т.к. она постоянно срабатывала на рулёжке.

                                                                Поэтому я тоже против миганий и любых раздражающих предупреждений. Но я это и не предлагал. Речь только о том, что если хочется передать какую-то информацию цветом, нужно зашифровывать её прежде всего в яркости и уже вторично в тоне (как например в редактора расписания вытяжек или у зелёных стрелок клапанов). К слову, это же и на разных мониторах будет лучше работать. В разных мониторах особо страдает тон, в то время как яркий пиксель ярче тёмного на всех мониторах.
                                                      0
                                                      Для меня самое жесткое, что есть в SCADA — это анимации) Нет, конечно взять и показать, что всё красиво работает, это одно, а сидеть на месте оператора и сутки смотреть на всю эту крутящуюся анимацию затея не очень. На самом деле еще не хватает некой, так сказать стандартизации — грубо говоря у меня на последнем из объектов возникла мини проблема — визуализация на веб сервере ПЛК (которую видит оператор удаленно с рабочего компьютера) и визуализация в средстве разработки для панели с разными исходными элементами, соответственно свести воедино получилось только набрав отдельно картинки элементов. Тут мне нравится в целом подходы гугла и эйпл в попытке создать единый дизайн для элементов)
                                                        0
                                                        Нет, конечно взять и показать, что всё красиво работает, это одно, а сидеть на месте оператора и сутки смотреть на всю эту крутящуюся анимацию затея не очень.
                                                        В особых случаях делают 2 варианта экранов — «красивый» с цветами и анимацией, чтобы показать заказчику и «удобный» — для оператора)
                                                        ПС: Ниже такую тему уже отметили.
                                                        +2
                                                        С интересом прочитал статью. Для начала, Вы сильно льстите современным интерфейсам, описывая их как «удобные». Приведенные в начале примеры, в-общем, тоже не образец удобства, так делали в начале 90-х. В Вашем подходе я вижу плюс в том, что его легче сдать некомпетентному человеку, который не заглядывал в проект и не разбирается в функциональных схемах. Операторы же люди подневольные, они и с упрощенными схемами научатся работать. Как они будут называть разработчика, никто не услышит.

                                                        Некоторые замечания: десятые доли процентов только мешают, а оборудование не имеет такой точности регулирования. На последней мнемосхеме яркие заголовки не дают быстро увидеть состояния систем, отвлекают. Надеюсь, пусконаладочные параметры вентсистем не постоянно висят на экране, они же не нужны для эксплуатации. Не видно, есть ли графическое отображение аварий прямо возле агрегата и индикация ручного управления для каждого элемента. Чтобы ввести символ градуса (°), нажмите левый Alt, наберите 248 на цифровой клавиатуре, отпустите Alt. «С» — это не "°С"

                                                        Когда Segnetics попытался сделать «дизайнерский» интерфейс на своих графических панелях управления, это отвратило меня от них окончательно. По-моему, не стоит придумывать новые обозначения для широко используемых компонентов. Я в реализуемых проектах делаю так, чтобы мнемосхема была похожа на проектную функциональную схему или отражала реальное расположение оборудования. Для большого количества однотипных объектов — списки с выделением цветом, как у Вас.
                                                          +2
                                                          Спасибо за отзыв.
                                                          десятые доли процентов только мешают
                                                          Отчасти согласен, но в некоторых местах они нужны. Например процент открытия клапана и важные температуры, при изменение уставок так проще смотреть как реагирует привод и как настроен ПИД. Если десятых нет, то очень долго ждать изменений.
                                                          Надеюсь, пусконаладочные параметры вентсистем не постоянно висят на экране
                                                          О каких именно речь идет?
                                                          есть ли графическое отображение аварий прямо возле агрегата
                                                          нету, пока, но это важный момент, будем реализовывать ее обязательно.
                                                          и индикация ручного управления
                                                          в этих примерах нету, но на других объектах где это есть, обязательно показываем.
                                                          Когда Segnetics попытался сделать «дизайнерский» интерфейс
                                                          Мне лично нравится то, что делает Сегнетикс. И дизайн интерфейсов и дизайн оборудования.
                                                          +2
                                                          Несколько лет проработал в КИП на пищевом предприятии. Занимался автоматизацией всего чего угодно. Меня изменил момент, когда операторы попросили сделать интерфейс без свистелко-перделок:«так чтобы только цифры, надписи и кнопки».
                                                          Оказывается ребята очень страдали от красивых картинок. Они загромождали рабочий стол и в одночасье можно было видеть только часть процесса. После таких замечаний, я делал два интерфейса: первый для начальства — красивый и с картинками, а второй для операторов.
                                                            0
                                                            Да, это почти везде так. Мы стараемся как раз этому и следовать, убирать максимум красивых и не красивых картинок, но тем не менее, информацию нужно как-то структурировать для удобства и ориентации, поэтому все 3Д, крутилки, мигание и мерцание убираем, оставляем прямоугольники согласно схеме и переменные и подсказки.
                                                              0
                                                              «После таких замечаний, я делал два интерфейса: первый для начальства — красивый и с картинками, а второй для операторов.»

                                                              Отличная идея! Очень правильная во всех смыслах.

                                                              Я так всегда с сайтами и мелкими своими программками делаю. Началось всё ещё в эпоху WAP (кто-то ещё помнит, что это за штука? :-) ); закономерно продолжилось с появлением планшетов/смартфонов (масштабируемые дизайны и всё это вот) и — естественным способом транслировалось в общую идею «один интерфейс чтобы запудрить глаза покупателю; второй — чтобы пользователю было реально удобно».
                                                              +3
                                                              Моя тема. Несколько лет рисовал картинки в Транснефти. У них существует приличный гайд по описанию всего — цвета, расположения, состава, шрифтов, слоёв и т.д. Это дало то, что в любой дочке ТН в любом месте были одинаковые интерфейсы на уровне диспетчерских отделов.
                                                              Выше правильно написали, что интерфейсы бывают разными. В один заглядывают только при наличии проблем, а в другой смотрят круглосуточно. Оба должны по-разному реализовываться.
                                                              А вообще тема избитая, есть, например, HMI Design Workbook от Siemens, или The High Performance HMI от Rockwell, или можно поучиться вот у этих ребят — hmi-project.com
                                                                0
                                                                По ссылкам нашел очень много полезного, спасибо.
                                                                  0
                                                                  У Транснефти не гайд, а документ ТПР (типовые программные решения, часть 5), страниц эдак на 1000 — чтобы интерфейсы от разных производителей управлялись и ощущались одинаково (алгоритмы так же унифицированы).

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

                                                                  В противовес скажу, что технологии у ТН простейшие, а для более сложных процессов можно и утомиться собирать наименьший общий делитель для алгоритмов и интерфейсов. Но опять же, Major PCS vendors это стараются делать
                                                                    +1
                                                                    Я говорю не про операторные на станциях, а про диспетчерские на уровне управлений, там другой гайд — РД-35.240.60-КТН-029-15. А в операторных, конечно, полный трэш, может стоять решение от Элеси на GraphWorx и от них же на их HMI, а рядом противопожарка от Болид. Упомянутый вами документ распространяется только на вновь вводимые системы, старые никто не переделывает, поэтому если не было реконструкций, то этот зоопарк так и стоит. Пройдет еще с десяток лет, пока на уровне НПС (ЛПДС) всё не станет однотипным.
                                                                    А педали путали не раз как операторы, так и диспетчеры. Останавливали не тот агрегат по запаре, например. Но ТН это же не переработка, а транспорт, там из-за неверных действий оператора ничего страшного не произойдёт, кроме снижения объемов перекачки.
                                                                      0
                                                                      Я ТН не ругаю, скорее наоборот. В противовес статье.

                                                                      Но даже на транспорте нефтепродуктов можно еще как накосячить

                                                                      ЗЫ. Элеси вроде ставила свою Инфитити, а Графворкс относится к Дженезис.
                                                                        0
                                                                        ЗЫ. Элеси вроде ставила свою Инфитити, а Графворкс относится к Дженезис.

                                                                        Всё верно, но изначально у них не было своей HMI и они использовали GraphWorx в качестве верхнего уровня. До сих пор все диспетчерские схемы во всей ТН реализованы на GraphWorx. Собственный HMI используется на уровне НПС.
                                                                        Я с продуктами Элеси работал с 2000 по 2017 годы, когда еще их продукт Infinity не назывался :)
                                                                        Но даже на транспорте нефтепродуктов можно еще как накосячить

                                                                        По официальной версии, причиной инцидента стала разгерметизация одного из резервуаров из-за проседания свай фундамента.
                                                                        Ну, как бы, причем тут действия оператора/диспетчера? Вся автоматика в ТН (да и просто грамотная автоматика) реализуется так, чтобы отсутствие визуальных данных у оператора/диспетчера (сервер скады сломался, например) никаким образом не влияло на техпроцесс. Все защиты реализованы в ПЛК., всё сработает само, если надо. Даже если специально запустить агрегат на закрытую задвижку, то сработает датчик давления и датчик тока на агрегате. Перелить резервуар тоже не получится, всё в датчиках, и т.д. Если только намеренно отключить защиты, но это уже другой вопрос.
                                                                  0
                                                                  каждый производитель системы предоставляет свои наборы готовых библиотек,… чаще всего эти библиотеки не отличаются качеством своего исполнения.

                                                                  Немного смутил такой явно критический тон, во первых SCADA системы предоставляют элементарные средства для разработки, все остальное зависит от вашего профессионализма. Почему только элементарное, вы же сами и ответили «призванные упростить и ускорить работу программиста».
                                                                  На просторах интернета полным полно готовых графических наработок под популярные SCADA системы.
                                                                  Опять же смутило, что дизайнер — это дорого, но как я понял Вы нанимали для данного проекта дизайнера.
                                                                  Дизайн действительно качественный, проработанный, интуитивно понятный. Но опять же, прикладное программное обеспечение, точнее визуализация, очень привязана к технологии. Насколько вы корректно, понятно, прозрачно отобразите технологию на столько она и будет хороша, не только качественная графика (конечно так же необходима).
                                                                  Черный фон не использую, т.к. большой контраст между другими цветами (белый, красный желтый), использую серый фон наиболее щадящий для глаз. Немного странно было читать про спящих операторов и черный цвет что бы их не разбудить. Ну разве что у вас все таки диспетчеризация а не управляющая система реального времени.
                                                                  Ну и я явно не увидел главный посыл статьи- создание модулируемых графических объектов с возможностью дальнейшего применения, как я понял нет, графика на дизайнере на каждый скрин своя. Т.е. для следующего объекта вам нужно нанимать дизайнера и заново все прорисовывать почти с 0. А это деньги и время (=деньги)
                                                                  Прошу прощения за может излишнюю критичность, т.к. на вкус и цвет все фломастеры разные.
                                                                    0
                                                                    Спасибо за отзыв!)
                                                                    как я понял Вы нанимали для данного проекта дизайнера
                                                                    нанимал дизайнера на первый свой серьезный проект, так как опыта была очень мало. Дальше, все что мы делали, делали уже сами.
                                                                    Черный фон не использую
                                                                    Строго черный цвет будет жутко для глаз, у нас он чуть в серый и синий уходит.
                                                                    Немного странно было читать про спящих операторов
                                                                    Скорее не операторов, а персонал в диспетчерской, на разных объектах, разный состав в диспетчерской, охрана, операторы и тд, некоторые ночуют в диспетчерской.
                                                                    создание модулируемых графических объектов
                                                                    Ну мы практически к этому пришли. Спевра убрали все 3Д, которое сложно унифицировать, а потом сделали прямоугольники с информацией. Логика в том, чтобы структурировать процесс по разным элементам, один элемент это прямоугольник с основной информацией внутри. Прямоугольники немного меняются у нас от объекта к объекту, углы, тени, обводки, но смысл остается. Такая логика позволяет сделать однотипными систему вентиляции, котельную, хладоцентр, очистные, и тд.
                                                                      +1
                                                                      image
                                                                      Вот следуя такой логике реализовали очистные сооружения
                                                                        0
                                                                        Смотрится интересно, но есть минус — не видно технологии. Оператору придётся держать распечатку рядом с рабочим местом. Но это опять же зависит от заказчика.
                                                                        А если ткнуть на значение откроется окно параметра с возможностью вывода графика и просмотра уставок?

                                                                        п.с. Автоматизация очистных сооружений была у меня дипломным проектом :)
                                                                          0
                                                                          Верно замечено. Технологии необходимо как правило несколько больше. Т.е. к очистным, насосным установкам добавить информацию по обслуживаемым частям зданий, технологических подсистемам. Как правильно заметили, чтобы эксплуатация экономила время на работу с документацией. Пришла авария по КНС, видим сразу в какой части технологии возникла проблема, т.е. куда бежим, что проверяем, закрываем и т.п.
                                                                          +1
                                                                          image
                                                                          image
                                                                            0
                                                                            Вентиляторы тут, а не насосы)) И вообще странно, что н1, а не Н1, всё же аббревиатура
                                                                        0
                                                                        В конце концов, сейчас у всех в руках смартфоны с современными ОС и приложениями — люди давно уже привыкли к хорошим качественным интерфейсам, а мы заставляем их возвращаться в прошлое во времена Windows 98.
                                                                        Принципы проектирования UI Win95.
                                                                        Возвращать нас в те времена кажется уже некому…
                                                                          +1
                                                                          Зачастую у людей, заказывающих АСУ ТП уже есть опыт использования таких систем. И это опыт из 90-х, начала 00-х. Соответственно, они им привычней, удобней видеть интерфейс из того-же времени и плевать они хотели на современные стандарты и тенденции.
                                                                            0
                                                                            А приведите пример современных стандартов и тенденций в части визуализации АСУТП?
                                                                              0
                                                                              Я не отделял UI АСУ ТП от UI других информационных систем. А примеры привёл автор статьи. Думаю, вы сами, если посмотрите вокруг вполне в состоянии увидеть, какие пользовательские интерфейсы создаются в 2020 году.
                                                                                0
                                                                                Я не отделял UI АСУ ТП от UI других информационных систем.

                                                                                В этом и кроется ошибка. Если почитать The High Performance HMI от Rockwell, то можно увидеть, что основной упор в интерфейсах делается на внимание к граничным и аварийным значениям. Если всё в порядке, то картинка максимально серая и невзрачная. И это оправдано, т.к. обычно диспетчеры круглые сутки смотрят в монитор, и всякие свистоперделки просто сведут с ума к концу смены.
                                                                                  +2
                                                                                  а кто говорил про свистелки и перделки? я даже больше скажу. доморощенные мнемосхемы скада-систем порой представляют из себя даже не кашу, а настоящий борщ из условных гостовских обозначений, вырезанных или нарисованных в паинте картинок, похожих на какое-то оборудование, не несущее никакой полезной информации, бессмысленной анимации. И всё это в ядрёно-кислотных расцветках.
                                                                            +1
                                                                            С точки зрения UX стоит всё-таки ответить сначала на вопрос «зачем нужна эта система?» Не стоит забывать, что в отличие от многого другого ПО SCADA обычно вещь вторичная относительно техпроцесса, который ею обслуживается.

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

                                                                            В первом случае нет определённого фокуса и система может отображать избыточную или общую информацию. Режим «всего понемногу, вдруг что-то будет любопытно».

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

                                                                            Ещё один аспект это иерархия, децентрализация системы и локальный контроль. На большом объекте можно иметь диспетчерскую со стеной из экранов, но те, кто работают в процессе производства должны иметь возможность принять решение на месте вместо того, что бы звонить диспетчерам. Это может означать появление отдельных устройств контроля-управления с уменьшенным функционалом. Это не всегда должны быть экраны и тач-скрин с цветами, шрифтами и иконками. Иногда проще и доступнее светофором, сиреной или АЗ/SCRAM с топором. Один из наглядных примеров — система управления нагрузкой на парковке. Датчик занятого места имеет локальный простой «выход» в виде красного/зелёного фонаря и он так же отчитывается «наверх» в систему, которая подсчитывает и выводит на экраны в проездах число свободных мест.
                                                                              0
                                                                              Сделанная визуализация не так сильно зависит от Scada системы. Ну то-есть как повторить интерфейс с самых нижних картинок в той же мастерскаде (картинка в самом начале, над Везой и под Круг-2000) — я вполне себе представляю, это вполне себе работающая система.

                                                                              Зачем пишу — Мне интересно как Вы реализовываете (планируете/могли бы спланировать) к примеру
                                                                              Диспетчеризацию Наличия напряжения у конкретного магазина в торговом центре. с учетом постоянного изменения «нарезки». (ну допустим если брать не счётчики для технического учета, которые не всегда возможно ставить, а допустим приставки контактные)
                                                                                0
                                                                                не очень понял вопроса, можете чуть подробнее, можно в личку
                                                                                  0
                                                                                  Имею ввиду диспетчеризацию в торговом центре к примеру наличия напряжения в конкретной палатке\магазине.

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

                                                                                  То-есть как постоянное изменение мнемосхемы нарезки на участки.
                                                                                    +1
                                                                                    Понял. Ну в этом случае нет смысла делать планировку, тут проще табличную форму сделать с редактируемыми комментариями. Вообще с планировкой не очень просто, это хорошо если все одноэтажное, можно только несущими стенами обозначить планировку, они не изменятся. Слишком много второстепенных стен, перегородок, подписей создадут кашу. На последних примерах здание 5-этажное, его сделали в профиль, но и тут есть нюансы, на разных этажах разное кол-во систем. На одном объекте очень много система АВК, дренаж, кнс, протечки и тд, и все только на -1 этаже. Поэтому это дело только опытным путем решается, иногда много времени очень на это уходит
                                                                                0
                                                                                ну и как то совсем безличностно, почему не описали железо и софт на котором все сделано…
                                                                                  0
                                                                                  Simple-Scada сейчас у нас везде используется. В примере был объект на К2 МЗТА, подписал его. Из железа МЗТА, Сегнетикс, Сименс, Ваго. Статья больше про разработку интерфейса, которая в нашем случае от скады мало зависит.
                                                                                  0
                                                                                  Да и в целом темная тема проще для восприятия и меньше нагружает глаза, тем более при длительном использовании


                                                                                  Субъективно все это. Лично я от темных тем везде отказался, надоели, уже года два как наверное. И даже в автокаде у меня уже лет 10 фон белый, а не черный. Лично для меня — удобнее.

                                                                                  Что касается конкретно SCADA и других диспетчерских систем, на белом экране желтые и красные аварии видно сразу и издалека, даже если ты по коридору мимо проходил и заглянул.
                                                                                    +1
                                                                                    Довольно спорное утверждение, при прочих равных условиях красная «кнопка» на дисплее контрастирует с черным фоном лучше, чем с белым. Это ведь очевидно.
                                                                                    0
                                                                                    Участвовал в разработке подобных систем отображения, основная и самая серьезная проблема не техническая, а психологическая. Т.к. у лиц ответственных за решения сильно различаются вкусы и представления о дизайне. И часто приходилось об колено ломать неплохие решения, потому что "ну вот не понравилось потому что кнопки слева"…

                                                                                      +1
                                                                                      3d интерфейсы были бы куда полезнее и понятнее
                                                                                        +3
                                                                                        Основная задача визуализации АСУТП это дать информацию о состоянии техпроцесса. Всякое 3D увеличивает визуальную нагрузку и мешает восприятию. У меня как-то был экран с 24 резервуарами и примерно 300 задвижками с нарисованным трубопроводом. Куда там 3D засунуть и зачем?
                                                                                        0
                                                                                        В свое время занимался проектами реконструкции информационных систем на БЩУ АЭС. Есть два примера для сравнения. Возможно не совсем справедливо сравнивать коммерческую систему от фирмы AdAstra с небольшой самодельной SCADA от компании Ракурс. Но тут все дело в архитектуре и подходах. С одной стороны довольно сложная, местами избыточно, система от AdAstra с совершенно примитивным и не надёжным протоколом резервирования, которая периодически подвисала и падала. Опять же графический дизайн там оставлял желать много лучшего. для сравнения был знаком с интерфейсами SCADA на Финской Ловизе или Норвежской IFE. Очень приятное впечатление осталось и с точки зрения эргономики и архитектуры и надёжности. Так вот работая с хорошими парнями из Ракурс, я сделал интересный вывод, хочешь надёжно и красиво — пиши свою SCADA. Особенно, если речь идет о блоках АЭС. Если дёшево и приемлемо, но не очень надёжно (долгие звонки в техподдержку и постоянные заплатки) купи что то вроде TraceMode. Информация у меня 10 летней давности, прошу прощения, если за это время данный софт сильно улучшился и эволюционировал.
                                                                                          0
                                                                                          Треймоуд, к слову не развивающийся уже лет 10, никак не тянет на образец, ЛОЛ.

                                                                                          А самоделки еще хуже.

                                                                                          А дизайн — любая нормальная СКАДА позволяет делать _любой_ дизайн — делай себе библиотеку кастомных объектов. Лично я могу это утверждать на 100% про FactoryTalk, iFix, WinCC.

                                                                                            0

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

                                                                                        Only users with full accounts can post comments. Log in, please.