HMI после пуска: Какие экраны нужно переделывать по жалобам смены

Первые недели после пуска почти всегда честнее любого FAT. На приемке экран может выглядеть аккуратно: кнопки на месте, аварии приходят, тренды рисуются, ручной режим включается, уставки защищены паролем. Но как только линия начинает жить в сменном режиме, выясняется другое. Оператор не понимает, почему агрегат остановился. Аварий столько, что важная теряется среди второстепенных. Уставка есть, но спрятана так глубоко, что ее ищут по памяти. Тренд вроде бы открыт, но не помогает понять, что было до остановки. Ручной режим есть, но непонятно, что именно он разрешает. Кнопки похожи, контекста по оборудованию мало, а в разговоре со сменой появляется фраза: “мы этим экраном почти не пользуемся”.

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

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

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

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

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

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

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

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

Главное, чтобы оператор не собирал ответ из пяти экранов. Если причина остановки известна ПЛК или SCADA, HMI должен показать ее там, где человек принимает решение.

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

Здесь не помогает совет “пусть внимательнее читает”. Если экран аварий засыпает смену одинаково яркими строками, человек быстро перестает воспринимать его как источник истины. Он начинает искать причину по косвенным признакам: по звуку, по местным лампам, по привычной последовательности действий. Так появляется тот самый обход HMI, о котором мы уже говорили в статье “Почему оператор обходит HMI: человеческий фактор”.

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

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

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

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

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

Особенно важно связать уставки с журналом. Если параметр менялся после пуска, это должно быть видно не из разговоров, а из записи: кто изменил, старое значение, новое значение, время и рабочее место. Подробнее про это есть отдельный материал “Журнал действий оператора в SCADA: что писать, чтобы потом разобраться”. Для HMI после пуска журнал становится не отчетностью, а источником требований к переделке экранов.

Тренд на HMI часто добавляют как доказательство “у нас есть диагностика”. Но смене нужен не сам график, а ответ на вопрос: что изменилось перед событием? Если на тренде только одна красивая линия без уставки, состояния оборудования и команд, он может быть почти бесполезен.

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

После пуска стоит разбирать тренды не в вакууме, а по реальным остановкам. Берется событие из журнала, открывается период до и после него, затем проверяется: видны ли на одном экране фактическое значение, уставка, команда, состояние исполнительного механизма, режим Auto/Manual, аварийный порог и ключевые дискретные условия. Если для ответа нужно открыть три разных тренда и помнить время события наизусть, экран надо дорабатывать.

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

Ручной режим после пуска почти всегда становится источником вопросов. На экране написано “ручной”, но непонятно, что именно переведено: весь узел, один привод, клапан, насос, регулятор, задвижка, рецепт, последовательность? Можно ли при этом запускать автомат? Вернется ли объект сам в автомат после сброса? Кто включил ручной режим и зачем?

Если HMI показывает ручной режим маленькой надписью в углу, смена быстро перестает воспринимать его как важное состояние. А потом начинается классика: один насос оставили в ручном после наладки, последовательность не стартует, оператор видит запрет, но не понимает, откуда он взялся.

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

Важно, чтобы переходы Auto/Manual попадали в журнал. Иначе через неделю после пуска команда будет спорить, “оно само так стало” или “кто-то оставил после проверки”. HMI должен снижать такие споры, а не создавать их.

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

Жалоба “кнопки похожи” должна проверяться на сценариях, а не на вкусе. Где именно путают? Пуск и сброс? Квитирование и устранение? Ручной и автомат? Открыть и закрыть? Команду на узел и команду на отдельный механизм? Если ошибка уже была или оператор несколько раз останавливался перед нажатием, экран нужно исправлять.

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

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

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

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

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

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

Хороший вопрос звучит не “что вам не нравится в HMI?”, а “в какой момент вы перестали понимать, что делать дальше?”. Еще лучше - разобрать конкретную остановку по времени: вот 02:14, пришла авария; вот 02:15, вы квитировали; вот 02:17, включили ручной режим; вот 02:20, позвали электрика. Где экран помог, а где нет?

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

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

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

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

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