И верно и неверно. Элементы всяких скад тянутся из 80-х, когда их рисовали просто чтобы хоть что-то отобразить. Нет никакой стандартизации. У каждого производителя свои элементы и варианты их отображения.
У нас в своё время была создана собственная библиотека всех элементов, используемых в экранных формах. Было утилитарно, ровно, красиво, эстетично, без свистоперделок.
На скриншоте же статьи какая-то поделка с пережатыми шрифтами, разными отступами, отсутствующей стандартизацией элементов и никакой эстетикой.
Можно даже взять это как граничные условия для задачи с параметром: во сколько раз надо увеличить поверхность СД по сравнению с поверхностью звезды, при таком-то потоке теплового излучения от нее и такой-то пропускной способности ИК-радиаторов, чтобы хотя бы сами конструкции не поплавились.
Фигня вопрос. Делаем сферу из элементов Пельтье, получаем огромный морозильник )))
Я не отделял UI АСУ ТП от UI других информационных систем.
В этом и кроется ошибка. Если почитать The High Performance HMI от Rockwell, то можно увидеть, что основной упор в интерфейсах делается на внимание к граничным и аварийным значениям. Если всё в порядке, то картинка максимально серая и невзрачная. И это оправдано, т.к. обычно диспетчеры круглые сутки смотрят в монитор, и всякие свистоперделки просто сведут с ума к концу смены.
Основная задача визуализации АСУТП это дать информацию о состоянии техпроцесса. Всякое 3D увеличивает визуальную нагрузку и мешает восприятию. У меня как-то был экран с 24 резервуарами и примерно 300 задвижками с нарисованным трубопроводом. Куда там 3D засунуть и зачем?
Я не работал на мелких предприятиях. У нас было всё по серьезному. Человек сначала несколько месяцев проходил обучение, потом экзамены, потом стажировка под присмотром и опять экзамены, и только потом самостоятельная работа. И никаких идиотских картинок.
Но если погуглить SCADA по картинкам, то там прям всё печально в 100% случаев.
Смотрится интересно, но есть минус — не видно технологии. Оператору придётся держать распечатку рядом с рабочим местом. Но это опять же зависит от заказчика.
А если ткнуть на значение откроется окно параметра с возможностью вывода графика и просмотра уставок?
п.с. Автоматизация очистных сооружений была у меня дипломным проектом :)
ЗЫ. Элеси вроде ставила свою Инфитити, а Графворкс относится к Дженезис.
Всё верно, но изначально у них не было своей HMI и они использовали GraphWorx в качестве верхнего уровня. До сих пор все диспетчерские схемы во всей ТН реализованы на GraphWorx. Собственный HMI используется на уровне НПС.
Я с продуктами Элеси работал с 2000 по 2017 годы, когда еще их продукт Infinity не назывался :)
Но даже на транспорте нефтепродуктов можно еще как накосячить
По официальной версии, причиной инцидента стала разгерметизация одного из резервуаров из-за проседания свай фундамента.
Ну, как бы, причем тут действия оператора/диспетчера? Вся автоматика в ТН (да и просто грамотная автоматика) реализуется так, чтобы отсутствие визуальных данных у оператора/диспетчера (сервер скады сломался, например) никаким образом не влияло на техпроцесс. Все защиты реализованы в ПЛК., всё сработает само, если надо. Даже если специально запустить агрегат на закрытую задвижку, то сработает датчик давления и датчик тока на агрегате. Перелить резервуар тоже не получится, всё в датчиках, и т.д. Если только намеренно отключить защиты, но это уже другой вопрос.
Я говорю не про операторные на станциях, а про диспетчерские на уровне управлений, там другой гайд — РД-35.240.60-КТН-029-15. А в операторных, конечно, полный трэш, может стоять решение от Элеси на GraphWorx и от них же на их HMI, а рядом противопожарка от Болид. Упомянутый вами документ распространяется только на вновь вводимые системы, старые никто не переделывает, поэтому если не было реконструкций, то этот зоопарк так и стоит. Пройдет еще с десяток лет, пока на уровне НПС (ЛПДС) всё не станет однотипным.
А педали путали не раз как операторы, так и диспетчеры. Останавливали не тот агрегат по запаре, например. Но ТН это же не переработка, а транспорт, там из-за неверных действий оператора ничего страшного не произойдёт, кроме снижения объемов перекачки.
Моя тема. Несколько лет рисовал картинки в Транснефти. У них существует приличный гайд по описанию всего — цвета, расположения, состава, шрифтов, слоёв и т.д. Это дало то, что в любой дочке ТН в любом месте были одинаковые интерфейсы на уровне диспетчерских отделов.
Выше правильно написали, что интерфейсы бывают разными. В один заглядывают только при наличии проблем, а в другой смотрят круглосуточно. Оба должны по-разному реализовываться.
А вообще тема избитая, есть, например, HMI Design Workbook от Siemens, или The High Performance HMI от Rockwell, или можно поучиться вот у этих ребят — hmi-project.com
Согласен. Не заметил)
Слегка доколупался.
Нужно просто делать эстетично, а не это вот всё :)
И верно и неверно. Элементы всяких скад тянутся из 80-х, когда их рисовали просто чтобы хоть что-то отобразить. Нет никакой стандартизации. У каждого производителя свои элементы и варианты их отображения.
У нас в своё время была создана собственная библиотека всех элементов, используемых в экранных формах. Было утилитарно, ровно, красиво, эстетично, без свистоперделок.
На скриншоте же статьи какая-то поделка с пережатыми шрифтами, разными отступами, отсутствующей стандартизацией элементов и никакой эстетикой.
Интерфейс скады прям из 80-х.
Фигня вопрос. Делаем сферу из элементов Пельтье, получаем огромный морозильник )))
В этом и кроется ошибка. Если почитать The High Performance HMI от Rockwell, то можно увидеть, что основной упор в интерфейсах делается на внимание к граничным и аварийным значениям. Если всё в порядке, то картинка максимально серая и невзрачная. И это оправдано, т.к. обычно диспетчеры круглые сутки смотрят в монитор, и всякие свистоперделки просто сведут с ума к концу смены.
Но если погуглить SCADA по картинкам, то там прям всё печально в 100% случаев.
А если ткнуть на значение откроется окно параметра с возможностью вывода графика и просмотра уставок?
п.с. Автоматизация очистных сооружений была у меня дипломным проектом :)
Всё верно, но изначально у них не было своей HMI и они использовали GraphWorx в качестве верхнего уровня. До сих пор все диспетчерские схемы во всей ТН реализованы на GraphWorx. Собственный HMI используется на уровне НПС.
Я с продуктами Элеси работал с 2000 по 2017 годы, когда еще их продукт Infinity не назывался :)
По официальной версии, причиной инцидента стала разгерметизация одного из резервуаров из-за проседания свай фундамента.
Ну, как бы, причем тут действия оператора/диспетчера? Вся автоматика в ТН (да и просто грамотная автоматика) реализуется так, чтобы отсутствие визуальных данных у оператора/диспетчера (сервер скады сломался, например) никаким образом не влияло на техпроцесс. Все защиты реализованы в ПЛК., всё сработает само, если надо. Даже если специально запустить агрегат на закрытую задвижку, то сработает датчик давления и датчик тока на агрегате. Перелить резервуар тоже не получится, всё в датчиках, и т.д. Если только намеренно отключить защиты, но это уже другой вопрос.
А педали путали не раз как операторы, так и диспетчеры. Останавливали не тот агрегат по запаре, например. Но ТН это же не переработка, а транспорт, там из-за неверных действий оператора ничего страшного не произойдёт, кроме снижения объемов перекачки.
Выше правильно написали, что интерфейсы бывают разными. В один заглядывают только при наличии проблем, а в другой смотрят круглосуточно. Оба должны по-разному реализовываться.
А вообще тема избитая, есть, например, HMI Design Workbook от Siemens, или The High Performance HMI от Rockwell, или можно поучиться вот у этих ребят — hmi-project.com