Проектирование операторского интерфейса производственной линии: этапы, принципы и критерии качества

Операторский интерфейс (HMI — Human Machine Interface) — это не просто «экран с кнопками», а единственная точка принятия решений человеком в автоматизированном производстве. От качества его проектирования зависят скорость реакции на аварии, частота ошибок оператора, время наладки смены продукции и, в конечном счёте, OEE (общая эффективность оборудования). Статья описывает полный цикл проектирования: от анализа задач оператора до валидации на стенде и вводной эксплуатации.

От чего начинается проектирование: анализ контекста и ролей

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

• Линейный оператор — следит за ходом процесса, реагирует на отклонения, выполняет ручные режимы, смену форматов, запуск/останов. Нужен обзорный экран с ключевыми параметрами и быстрый доступ к управлению.
• Наладчик/технолог — настраивает уставки, калибрует датчики, диагностирует причины остановок. Требует доступ к трендам, истории событий, расширенным меню настройки (часто под паролем).
• Диспетчер/мастер смены — оценивает выполнение плана, анализирует потери, формирует отчёты. Ему нужны сводные дашборды, KPI, архивы смен.

Параллельно собираются физические ограничения: расстояние от глаз до экрана (панель на пульте, стенд, планшет), освещённость цеха (яркий солнечный свет или тёмный угол), наличие перчаток, вибрация, защита IP65/IP69K, температурный диапазон. Эти параметры диктуют диагональ, разрешение, яркость, тип сенсора (резистивный/ёмкостный) и жесткость крепления.

Стандарты, на которые опирается проектирование

Профессиональное проектирование не основано на вкусе дизайнера, а на инженерных стандартах. Ключевые документы:

• ISA-101.01 / IEC 62682 — основной стандарт проектирования HMI для процессных и дискретных производств. Определяет уровни навигации (уровень 1 — обзор, уровень 2 — область, уровень 3 — деталь, уровень 4 — поддержка), принципы кодирования цвета, формы, анимации, управление тревогами.
• ISO 9241-210 — эргономика взаимодействия человек-система, пользовательский подход.
• IEC 61131-3 — языки программирования ПЛК; влияет на структуру тегов и именование переменных, которые «всплывают» в HMI.
• Корпоративные стандарты заказчика — часто строже международных: единая палитра, библиотека лицевых панелей, правила именования тегов, требования к аудиту изменений.

Игнорирование ISA-101 приводит к самым частым проблемам: «рождественская ёлка» из тревог, где оператор не видит критические; навигация в 5–6 кликов до нужного параметра; отсутствие контекста при переходе между экранами.

Информационная архитектура: иерархия экранов и навигация

Согласно ISA-101, навигация строится по уровням:

1. Уровень 1 — Обзор процесса (Process Overview). Один экран на всю линию или цех. Только ключевые KPI: текущая скорость, цель смены, OEE, статус линии (работа/останов/авария), топ-3 активные тревоги. Никаких кнопок управления — только переходы.
2. Уровень 2 — Область/Ячейка (Area/Cell). Группа оборудования, объединённая технологически (например, «Наполнение», «Упаковка», «Паллетизация»). Показывает состояния станков, буферов, основные уставки, активные тревоги этой зоны.
3. Уровень 3 — Деталь оборудования (Equipment Detail). Полноценный экран единицы: все датчики, приводы, режимы (Авто/Ручной/Наладка), интерлоки, ручное управление, тренды ключевых параметров за последние 15–30 минут.
4. Уровень 4 — Поддержка (Support/Diagnostic). Настройка ПИД, калибровка, логика интерлоков, расширенные тренды (часы/дни), экспорт данных, служебные меню. Доступ по ролевой модели.

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

Визуальное кодирование: цвет, форма, анимация

Цвет в HMI — не декор, а семантический канал. ISA-101 жёстко регламентирует:

• Красный — только для аварийных тревог (требуют немедленного действия). Не используйте красный для кнопок «Стоп», фона заголовков или индикации «выключено».
• Жёлтый/Оранжевый — предупреждения (превышение уставки, قريب к лимиту, необходимость обслуживания).
• Зелёный — нормальное состояние процесса (работа в пределах нормы). Не используйте зелёный для кнопок «Пуск» — это путает с состоянием.
• Синий — ручной режим, наладка, информационные сообщения.
• Белый/Светло-серый — нейтральный фон, числовые значения в норме.
• Тёмно-серый/Чёрный — отключенное оборудование, неактивные элементы, фон (для тёмной темы в цехах с низкой освещённостью).

Форма дублирует смысл цвета (для дальтоников и при плохом свете):

• Круг — индикатор состояния (работа/останов/авария).
• Квадрат/Прямоугольник — кнопка управления.
• Треугольник (заостренный вверх) — предупреждение.
• Восьмиугольник (знак Stop) — аварийная остановка.

Анимация — только для привлечения внимания к аномалии: мигание 1–2 Гц для активной неквитированной тревоги. Постоянное мигание оборудования в нормальном режиме запрещено — вызывает «слепоту к миганию».

Управление тревогами (Alarm Management) — отдельная дисциплина

Плохо спроектированная система тревог — главная причина потери ситуационной осведомлённости. Принципы (ISA-18.2 / IEC 62682):

• Каждая тревога требует действия оператора. Если действие не нужно — это не тревога, а событие (лог/журнал).
• Приоритезация: Критическая (красная, звук), Высокая (красная), Средняя (жёлтая), Низкая (жёлтая/синяя), Информационная (серая/синяя). Не более 5–10% тревог должны быть критическими.
• Подавление (Suppression) и приоритизация при каскадных сбоях: при аварии подачи сырья не нужно засыпать оператора тревогами «нет бутылки на наполнителе», «нет крышки на закаточнике» и т.д. Корневая причина — одна, остальные — следствие.
• Deadband и задержка срабатывания для аналоговых сигналов — исключают «дребезг» тревог на границе уставки.
• Квитирование с контекстом: при нажатии «Подтвердить» оператор должен видеть: что случилось, когда, текущее значение, уставку, рекомендуемое действие (если задано в конфигурации).
• Аудит и KPI тревог: частота срабатываний (не более 1 в 10 минут в среднем), процент «частых летающих» (bad actors), время реакции оператора. Эти метрики настраиваются на этапе пусконаладки и пересматриваются ежеквартально.

Выбор аппаратной платформы и ПО

Решение принимается на стыке требований процесса, ИТ-безопасности и бюджета. Основные классы:

Класс	Типовые сценарии	Ограничения
Панельные HMI (Panel PC, Thin Client)	Постоянные рабочие места оператора, суровые условия, необходимость 24/7 без перезагрузок	Высокая стоимость, привязка к вендору (Siemens, Rockwell, Schneider, Weintek, Owen и др.), ограниченная производительность для сложной визуализации
Industrial PC + SCADA/HMI runtime	Сложные линии, множественные экраны, интеграция с MES/ERP, веб-клиенты, историан	Требует администрирования ОС (Windows/Linux), обновлений безопасности, резервирования дисков
Веб-клиенты (HTML5) на планшетах/панелях	Мобильные операторы, наладчики, удалённый доступ, единая кодовая база	Зависимость от сети Wi-Fi/проводной, задержки рендеринга, ограничения браузера (WebGL, работа с COM-портами), кибербезопасность

Ключевые технические требования к железу (проверяются до закупки):

• Разрешение и соотношение сторон под макет экранов (обычно 16:9, 1920×1080 или 1280×800).
• Яркость ≥ 400 кд/м² для цехов, ≥ 800 кд/м² для уличных/освещённых зон.
• Время отклика сенсора < 20 мс, работа в перчатках (резистивный или проекционно-ёмкостный с поддержкой перчаток).
• MTBF подсветки ≥ 50 000 часов.
• Отсутствие вентиляторов (пассивное охлаждение) — исключает забивание пылью и отказ подшипников.
• Поддержка требуемых протоколов: OPC UA, Modbus TCP, PROFINET, EtherNet/IP, MQTT.

Проектирование экранных форм: от вайрфрейма к стилю

Работа ведётся итеративно:

1. Сценарии использования (Use Cases): для каждой роли перечислить типовые задачи — «запуск линии после смены формата», «реагирование на затор в зоне упаковки», «проверка уставок перед сменой».
2. Вайрфреймы (low-fidelity): схематичное размещение зон — навигация, заголовок с контекстом (где я, режим линии), рабочая область, панель тревог, статусная строка (время, пользователь, связь с ПЛК). Согласовываются с технологистами и операторами до прорисовки графики.
3. Библиотека символов (Symbol Library): единые графические примитивы для насосов, клапанов, конвейеров, датчиков, двигателей. Состояния: работа, останов, авария, ручной, отключён, симуляция. Библиотека версионируется и хранится в репозитории проекта.
4. Шаблоны экранов (Templates): базовые компоновки для уровней 1–4. Заголовок, навигация, панель тревог — неизменны. Меняется только рабочая область.
5. Стиль (High-fidelity): применение корпоративной палитры, шрифтов (моноширинный для значений, без засечек для подписей), минимальный размер шрифта — 14 пт для значений, 12 пт для подписей (при расстоянии 60–70 см). Контрастность ≥ 4.5:1 (WCAG AA).

Практическое правило: на экране уровня 3 (деталь) не более 50–70 индикаторов/элементов управления. Если больше — разбивайте на функциональные вкладки (Приводы, Датчики, Интерлоки, Тренды).

Интеграция с ПЛК: именование, структуры данных, производительность

HMI не должно «думать» за ПЛК. Логика процесса — в контроллере, HMI — только визуализация и команды.

• Единое именование тегов: префикс области + тип оборудования + функция + суффикс (например, FILL_PUMP_01_RunFB, CAP_FEED_03_PosAct). Запрещены аббревиатуры, понятные только одному программисту.
• Структуры (UDT/Struct): группируйте связанные теги в структуры — MotorSts (Run, Fault, Speed, Current, Hours), ValveSts (OpenFB, CloseFB, Fault, Mode). Это упрощает адресацию в HMI и снижает трафик.
• Циклический опрос vs подписка (Report by Exception): для критичных сигналов (тревоги, режимы) используйте подписку/события (OPC UA Subscription, MQTT), для трендов и архивов — циклический опрос с разумным периодом (500 мс – 2 с).
• Команды с подтверждением: любое управление (пуск, стоп, открытие клапана, сброс аварии) — двухстадийное: «Запрос» → «Подтверждение» (диалог с указанием последствий) → «Исполнение» → «Обратная связь от ПЛК». Никаких прямых записей в коил по нажатию.
• Версионирование конфигурации HMI: каждый релиз тегируется (Git/Subversion), совместимость с версией ПЛК фиксируется в матрице совместимости.

Безопасность и кибербезопасность (OT Security)

Современный HMI — узел в сети OT, доступный для атак. Минимальный базовый набор (IEC 62443, корпоративные политики):

• Разделение сети: DMZ между IT и OT, HMI в зоне OT, доступ к веб-клиентам только через VPN/Zero Trust шлюз.
• Ролевая модель доступа (RBAC): Оператор / Наладчик / Технолог / Администратор HMI. Пароли — сложные, сменяемые, блокировка после 3 неудач.
• Аудит действий: кто, когда, что нажал, какое значение записал. Логи неудаляемы, выгружаются в SIEM.
• Подпись кода/проекта HMI (code signing) — защита от подмены runtime-файлов.
• Отключение неиспользуемых сервисов (RDP, VNC, FTP, браузер на панели), кэширование только разрешённых доменов.
• Резервное копирование проекта и рецептов по расписанию, проверка восстановления раз в квартал.

Тестирование и валидация: от стенда к цеху

Этапы приёмки, которые экономят недели пусконаладки:

1. FAT (Factory Acceptance Test) на стенде интегратора: ПЛК + HMI + симулятор процесса (SoftPLC или тестовый стенд). Проверяются: все сценарии Use Cases, навигация, тревоги, интерлоки, рецепты, тренды, безопасность, производительность (FPS, загрузка CPU, задержка обновления < 200 мс).
2. SAT (Site Acceptance Test) на объекте: подключение к реальному оборудованию. Проверка адресации тегов, калибровки аналоговых каналов, работы интерлоков с реальной механикой, времени реакции аварийных цепей (E-stop должен работать аппаратно, независимо от HMI).
3. Usability-тестирование с операторами: 2–3 опытных оператора выполняют типовые сценарии по сценарию, засекается время, фиксируются ошибки, вопросы, неудобства. Метод «Think Aloud» — оператор проговаривает действия. Результаты — список правок до серийной эксплуатации.
4. Период вводной эксплуатации (2–4 недели): сбор метрик тревог (ISA-18.2 KPI), время реакции, частота обращений к наладчикам «где найти…», анализ логов действий. По итогам — релиз 1.1 с исправлениями эргономики.

Типичные ошибки и как их избежать

Ошибка	Последствие	Правильная практика
Экраны перегружены деталями: все датчики на одном виде	Оператор не видит суть, время поиска параметра > 30 с	Строгая иерархия уровней ISA-101, правило 50–70 элементов на деталь
Цвет используется для декора (красные заголовки, зелёные кнопки Пуск)	Потеря семантики цвета, игнорирование настоящих тревог	Цвет только по ISA-101: красный = авария, зелёный = норма процесса
Тревог 1000+, 90% — низкий приоритет, нет подавления каскадов	«Слепота к тревогам», пропуск критики, стресс оператора	Рационализация тревог на этапе проектирования, deadband, подавление, KPI < 1/10 мин
Навигация через глубокие меню (5+ уровней)	Потеря контекста, ошибки при смене формата	Плоская навигация: табы уровней 1–4 всегда видны, хлебные крошки
Управление однокликовое, без подтверждения	Случайный пуск/останов, запись неверной уставки	Двухстадийные команды с диалогом подтверждения и контекстом
Шрифты 10–11 пт, низкий контраст, серый на сером	Нечитаемость в перчатках, при плохом свете, у операторов 45+	Мин. 14 пт для значений, контраст ≥ 4.5:1, тестирование на стенде в цехе
Нет версионирования проекта HMI и матрицы совместимости с ПЛК	Рассинхрон после обновления ПЛК, потере рецептов, даунтайм	Git/SVN для проекта, теги релизов, матрица совместимости в документации
Веб-клиент открыт в интернете без VPN/Zero Trust	Инцидент кибербезопасности, останов производства	Сегментация сети, RBAC, MFA, аудит, подпись кода

Сценарии выбора подхода: от задачи к решению

Не существует универсального «лучшего» HMI. Выбор зависит от контекста:

• Малосерийное производство, частая смена форматов, высокие требования к трассируемости → SCADA на IPC + веб-клиенты для наладчиков + интеграция с MES/ERP через OPC UA/MQTT. Рецепты версионируются, загружаются из MES.
• Серийное производство, стабильный ассортимент, суровые условия, минимум ИТ-ресурсов → Панельные HMI (Thin Client) с жестким runtime, проекты в памяти панели, резервирование по горячему резерву (Dual HMI).
• Распределённые объекты (нефтегаз, водоканал, энергетика) → Веб-клиенты на планшетах/панелях + центральный SCADA-сервер + защищённые каналы связи (LTE/VPN), кэширование трендов локально.
• Высокие требования функциональной безопасности (SIL/PL) → HMI не выполняет функции безопасности. Аварийная остановка — только аппаратная цепь. HMI только информирует и логирует. Разделение Safety и Non-Safety зон на экране (разный фон, значок щита).

Документация, которая реально работает

Объём документации должен быть оправдан сложностью линии. Минимальный набор:

• Функциональная спецификация HMI (HMI FDS): список экранов, навигация, матрица ролей/прав, список тревог с приоритетами и действиями, рецептуры, тренды, отчёты.
• Style Guide / Symbol Library Specification: палитра, шрифты, библиотека символов, правила именования тегов в HMI.
• Матрица тегов (Tag Cross-Reference): тег ПЛК ↔ тег HMI ↔ описание ↔ адрес ↔ тип данных ↔ масштабирование.
• Протоколы FAT/SAT: чек-листы сценариев, результаты замеров производительности, подписи заказчика.
• Операторское руководство (Quick Reference Card): ламинированная карта А4/A3 — основные экраны, горячие клавиши, процедура квитирования тревог, контакты дежурного автоматизатора. Висит на пульте.
• Руководство по обслуживанию HMI: бэкап, восстановление, обновление runtime/ОС, замена панели, проверка дисков/SSD, ротация логов.

Практический следующий шаг

Если вы начинаете проект с нуля или перерабатываете существующий интерфейс:

1. Соберите кросс-функциональную команду: технологист, ведущий оператор, автоматизатор ПЛК, инженер HMI/SCADA, ИТ-безопасность, мастер смены.
2. Проведите сессию сбора Use Cases для каждой роли (2–3 часа). Зафиксируйте сценарии, боль, текущие обходные пути.
3. Определите целевую архитектуру: уровни навигации (ISA-101), классы оборудования, приоритеты тревог.
4. Выберите 3–5 ключевых экранов для прототипа (вайрфрейм в Figma/Draw.io/PowerPoint). Согласуйте с операторами до написания кода.
5. Зафиксируйте Style Guide и Symbol Library как живые документы в репозитории.
6. Планируйте FAT с симулятором процесса — это дешевле, чем искать ошибки на объекте.

Качественный операторский интерфейс не делается «на коленке» за неделю перед сдачей объекта. Это инженерный продукт с собственным циклом жизни: требования → архитектура → прототип → валидация → сериальная эксплуатация → непрерывное улучшение по метрикам. Инвестиции в проектирование на ранних этапах возвращаются за счёт снижения времени реакции на аварии, уменьшения брака при смене форматов, снижения когнитивной нагрузки на персонал и отсутствия штрафов за инциденты кибербезопасности.

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