Панель оператора HMI показывает состояние оборудования и позволяет выполнять предусмотренные команды: выбирать режим, вводить допустимую уставку, просматривать сообщения. Чтобы заказать удобный интерфейс, сначала описывают работу человека: что он должен увидеть, какое решение принять и как убедиться в результате. Список красивых мнемосхем без этих сценариев ещё не является техническим заданием.
Ниже — способ превратить задачи эксплуатации в перечень экранов и проверок. Он подходит для обсуждения локальной панели у установки. Конкретные возможности, права и ограничения зависят от панели, контроллера и проекта. Пример в статье учебный: это не экран выполненного нами объекта и не инструкция по управлению действующим оборудованием.
Какие задачи выполняет оператор
Начните с коротких рабочих историй. Например: «После прихода на смену человек проверяет, какие установки работают и есть ли неразобранные сообщения». Или: «При остановке вентилятора нужно увидеть причину запрета, а не только серую картинку двигателя». В истории должны быть исходная ситуация, нужные сведения и результат действий.
Отдельно опишите задачи наладчика. Ему может понадобиться диагностика входов и версии проекта, тогда как оператору эти сведения мешают на основном экране. Одно устройство могут использовать разные люди, но это не требует показывать всем одинаковые кнопки.
В руководстве Rockwell по HMI для распределённых систем задачи пользователей рассматриваются как основание для структуры интерфейса. Для своего ТЗ достаточно таблицы ролей и нескольких реальных сценариев. Количество экранов получится из них, а не из заранее выбранной цифры в предложении подрядчика.
Как разделить обзор и подробности
На обзорном экране полезно собрать состояние установки, текущий режим и признаки проблем, требующих внимания. На подробном — измерения и команды одного узла. Диагностика должна объяснять причины: откуда пришёл запрет, есть ли связь, какое подтверждение ожидается. Так человеку не приходится одновременно читать карту всей системы и длинный список служебных параметров.
Это деление не обязывает создавать четыре уровня для каждого небольшого шкафа. В Process HMI Style Guide Rockwell предложена иерархия от общего состояния к детальному разбору. Она служит примером организации информации; структуру конкретной панели выбирают по рабочим задачам и доступному месту.
Уже в черновом макете проверьте, видно ли на обзоре, какая именно установка остановлена. Надпись «Есть авария» без адреса вынуждает открывать каждую страницу по очереди. Хороший обзор даёт следующий понятный переход: к проблемному узлу или к сообщению с его обозначением.
Что записать в карту экранов
Карта экранов — небольшой перечень страниц и связей между ними. Она объясняет, где начинается сценарий и куда человек попадёт после выбора оборудования. Не нужно рисовать все датчики сразу: сначала опишите назначение каждой страницы.
| Экран | Задача человека | Нужные данные | Предусмотренное действие | Следующий переход |
|---|---|---|---|---|
| Обзор установки | Понять текущее состояние | Режим, работа, сообщения | Открыть узел | Вентилятор или список сообщений |
| Вентилятор | Разобраться в остановке | Запрос пуска, подтверждение, запрет | Просмотр доступных условий | Причина запрета |
| Настройки | Посмотреть рабочее задание | Значение, единица, пределы | Изменение по разрешённой роли | Результат ввода |
| Журнал | Восстановить последовательность | Время, объект, событие | Фильтрация и просмотр | Связанный узел |
В таблице важны одинаковые обозначения оборудования. Если на схеме «П1», в журнале «Вентиляция 1», а в настройках «AHU-A», пользователю приходится самостоятельно сопоставлять названия. В ТЗ можно завести словарь и потребовать его использования на всех страницах.
Чем команда отличается от подтверждения
Нажатая кнопка показывает намерение пользователя. Подтверждение показывает отдельное состояние, полученное от контроллера или оборудования. Между ними возможны отказ, задержка, запрет режима или отсутствие связи. Поэтому состояние «команда отправлена» нельзя рисовать как «оборудование работает».
Для каждой команды опишите полный путь: кто имеет право её запросить, в каком режиме она допускается, где виден ответ и как отображается невозможность выполнения. Если контроллер не предоставляет нужное подтверждение, это ограничение исходных данных, а не задача художника интерфейса.
В ТЗ полезно разделить четыре поля: запрос, разрешение, фактическое состояние и причина отказа. Например, при запросе пуска вентилятора оператор должен видеть действующий режим и предусмотренный сигнал работы. Если пуск запрещён, интерфейс показывает понятную причину вместо бесконечной анимации ожидания. Условия пуска и защиты определяются алгоритмом; панель не должна подменять их собственными декоративными состояниями.
Как показывать измерения и недостоверность
Число без единицы и контекста двусмысленно. «25» может означать температуру, процент команды или другую величину. В перечне данных для панели запишите обозначение точки, единицу, точность отображения и источник. Для уставки отдельно нужны допустимые пределы и правило ввода.
Заранее определите отображение недоступных данных. Если связь потеряна, последнее полученное значение может оставаться в памяти, но человеку нужно видеть, что оно больше не подтверждено текущим обменом. Ноль тоже является числом; его нельзя автоматически использовать как универсальный знак неисправности датчика.
Для показательного сценария макет должен содержать нормальные данные, выход за предусмотренный диапазон и отсутствие обновления. Это проверяет смысл отображения ещё до подключения оборудования. Если время последнего обновления неизвестно источнику, интерфейс не должен создавать вымышленную отметку измерения: можно показывать состояние обмена с контроллером и объяснять его границы.
Как различать сообщения и действия с ними
В сообщении нужны объект, событие, состояние и время, если оно доступно. Фраза «Неисправность» не объясняет, что требуется человеку. Лучше связать сообщение с конкретным узлом и предусмотренной реакцией эксплуатации. При этом текст не должен обещать точную причину там, где приходит только общий сигнал отказа.
Разведите просмотр сообщения, его квитирование и устранение неисправности. Квитирование может означать, что оператор увидел событие; само по себе оно не подтверждает восстановление оборудования. Если предусмотрен отдельный запрос сброса, его условия и результат должны быть описаны отдельно.
Полезно включить в макет несколько одновременно активных сообщений. Тогда становится видно, не перекрывает ли окно второстепенного предупреждения сведения о более важном состоянии. Приоритеты и действия задают для конкретного объекта. Не следует автоматически переносить цвета, классы аварий и правила сброса из чужого проекта только потому, что такой набор уже есть в библиотеке экранов.
Какие права и физические условия учесть
Матрица прав отвечает на конкретный вопрос: что может сделать каждая роль. Просмотр состояния, изменение задания и сервисная диагностика — разные действия. Скрытая кнопка не считается доказательством запрета: приёмка должна проверять фактическую возможность запрещённой операции в допустимой тестовой среде.
Для действий с существенными последствиями предусмотрите ясное подтверждение с названием объекта и смыслом команды. Окно «Вы уверены?» без контекста помогает меньше, чем «Запрос изменения режима установки П1». Однако такое окно не заменяет защитную логику и аппаратные средства безопасности.
Посмотрите на рабочее место: освещение, расстояние, способ касания, необходимость работы в перчатках, доступный размер дисплея. Эти условия определяют читаемость и расстояние между зонами нажатия. Проверять макет только на большом офисном мониторе недостаточно. Для выбранной панели нужно отдельное подтверждение пригодности сенсора и условий эксплуатации по её документации.
Учебный пример проверки одного сценария
Представим панель вентиляционной установки. На обзоре видны режим и состояние вентилятора. Пользователь открывает подробности остановленного узла, читает запрос пуска и причину запрета. В учебной модели причиной является неподтверждённое условие готовности, предусмотренное алгоритмом. Это пример структуры экрана, а не указание изменять готовность на работающей установке.
На стенде разработчик задаёт тестовые состояния. В первом запрос и подтверждение согласованы. Во втором запрос есть, но разрешение отсутствует. В третьем теряется обмен с контроллером. Для каждого состояния оператор должен объяснить, что известно, чего система не подтверждает и какой предусмотрен следующий шаг.
В протоколе сохраняют версию проекта, роль пользователя, тестовое состояние и фактическое отображение. Такой результат проверяем: видно, чем отличается запрет от отказа связи. Одна фотография красивой мнемосхемы этого не доказывает, даже если все кнопки на ней присутствуют.
Что включить в ТЗ и передаваемый комплект
К заданию приложите карту экранов, словарь оборудования, перечень данных, матрицу прав и сценарии проверки. Для трендов укажите вопрос, на который должен отвечать график, нужный период и место хранения истории. Не каждая локальная панель способна вести одинаковый архив; наличие функции проверяют для выбранной модели и комплектации.
В составе сдачи перечислите актуальный проект панели, его версию, зависимости, порядок восстановления и ограничения. Резервная копия и редактируемый проект могут решать разные задачи. Эта разница подробнее разобрана в материале что получить после программирования ПЛК.
Если ещё выбирается уровень операторской системы, пригодится сравнение SCADA и HMI. А для обсуждения разработки HMI достаточно принести исходную схему и несколько рабочих сценариев. Именно они позволяют проверить, что будущие экраны помогают человеку выполнять свою работу.
