Как программировать Siemens HMI: проект в TIA Portal, экраны, теги, тревоги и обмен с PLC

1) Введение

Под “программированием Siemens HMI” обычно понимают не написание кода в классическом смысле, а разработку человеко-машинного интерфейса: экранов, навигации, привязок к тегам PLC, событий, сообщений (alarms), трендов, рецептов, пользователей и прав. Код (скрипты) может использоваться, но в большинстве проектов основной объём работ — это конфигурация и проектирование.

Типовой контур выглядит так:

• PLC (S7-1200/S7-1500 и др.) исполняет технологическую логику.

• HMI (панель Basic/Comfort/Unified или WinCC Runtime на ПК) отображает состояние и позволяет оператору вводить команды/уставки.

• Связь (обычно PROFINET/Ethernet) передаёт значения тегов между PLC и HMI.

2) Линейки Siemens HMI и что меняется для разработчика

Siemens HMI в рамках экосистемы TIA Portal чаще всего встречается в трёх “семействах” устройств/рантаймов:

• Basic Panels / WinCC Basic

• Comfort Panels / WinCC Comfort (и WinCC Advanced на ПК)

• Unified Panels / WinCC Unified (и Unified Runtime на ПК)

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

Таблица: ориентиры по отличиям (концептуально)

Вывод для практики: планируйте архитектуру HMI исходя из требований (аварии, тренды, рецепты, права, аудит, интеграции), а уже затем выбирайте семейство устройств.

3) Инструменты и структура HMI-проекта в TIA Portal

3.1. TIA Portal как основная среда

В TIA Portal проект HMI обычно ведётся рядом с PLC-проектом. Это важно: связь, теги и структуры данных удобно “тянуть” из PLC, а изменения проще синхронизировать.

3.2. Типовая структура HMI-проекта

Внутри HMI-устройства (панели/рантайма) вы обычно настраиваете:

• Connections (соединения с PLC)

• HMI Tags (теги: PLC tags, internal tags, system tags)

• Screens (экраны, всплывающие окна)

• Templates (шаблоны/общие области: header/footer)

• Alarms (сообщения и тревоги)

• Trends / Archives (тренды, архивы)

• Recipes (рецептурные данные, если используются)

• Users / Roles (пользователи, роли, права)

• Scripts / Events (события, скрипты — по возможностям платформы)

3.3. Минимальная дисциплина проекта

Чтобы проект не деградировал со временем, полезно сразу закрепить:

• правила именования тегов и экранов;

• структуру папок (screens, popups, faceplates, alarms, recipes);

• единый подход к цветам статусов и пиктограммам (даже если без “дизайна”, нужен стандарт);

• правило: критическая технологическая логика — в PLC, HMI — для интерфейса и валидации.

4) Создание проекта: добавление HMI и связка с PLC

Ниже — базовая последовательность в TIA Portal (названия пунктов могут отличаться по версии, логика остаётся одинаковой).

4.1. Добавление PLC и HMI в проект

1. Откройте TIA Portal → Create new project (или Open project).

2. В дереве проекта выберите Add new device.

3. Добавьте PLC (например, S7-1200/S7-1500):

   • Controllers → выберите модель → Add.

4. Добавьте HMI:

   • HMI → выберите панель (Basic/Comfort/Unified) или Runtime → Add.

4.2. Настройка сетевого соединения (PROFINET/Ethernet)

1. Перейдите в Devices & networks.

2. Выберите PLC → задайте IP-адрес (в свойствах интерфейса PROFINET).

3. Выберите HMI → задайте IP-адрес в той же подсети.

4. Соедините устройства в сетевом окне (drag-and-drop на одну сеть, если требуется).

5. Проверьте, что интерфейсы находятся в одной логической сети и адреса не конфликтуют.

4.3. Создание HMI Connection к PLC

1. Откройте HMI-устройство → раздел Connections.

2. Нажмите Add (добавить соединение).

3. В поле Partner выберите PLC из проекта.

4. Проверьте тип соединения (обычно S7 connection) и интерфейс.

5. Сохраните настройки.

4.4. Быстрая проверка связи (до разработки экранов)

До того как строить интерфейс, убедитесь, что базовая связность корректна:

• адреса PLC/HMI в одной подсети;

• в Online & diagnostics устройство доступно;

• HMI может обращаться к PLC по созданному connection.

Ошибки на этом этапе дешевле, чем “почему теги не читаются” уже в конце.

5) Теги и адресация: основа обмена HMI ↔ PLC

5.1. Типы тегов в HMI

1. PLC tags — значения, читаемые/записываемые из PLC через connection.

2. HMI internal tags — внутренние переменные HMI (для экранной логики, временных состояний, флагов навигации).

3. System tags — системные переменные HMI (время, статус связи, пользователь, системные флаги и др.).

Практическое правило: всё, что относится к технологии и должно быть консистентно между устройствами, хранится в PLC; всё, что относится к UI-поведению (временная подсветка, локальная логика экрана), может быть internal tag.

5.2. Создание PLC-тегов в HMI

1. В HMI-проекте откройте HMI Tags.

2. Выберите папку (создайте, если нужно) → Add new tag.

3. В колонке Connection выберите связь с PLC.

4. В колонке Address укажите адрес PLC-переменной или выберите её из списка (если доступна интеграция с PLC tags).

5. Установите Data type (BOOL/INT/DINT/REAL/STRING и т.д.).

6. По необходимости задайте:

   • начальное значение (для internal);

   • ограничения (min/max) — чаще в элементах ввода, а не на уровне тега;

   • комментарий (обязательно для сопровождения).

5.3. Типы данных и частые ошибки

Наиболее типовые ошибки в HMI-проектах:

• несоответствие типов (например, PLC REAL, а HMI INT);

• неправильная адресация (не та область памяти или не та переменная);

• слишком частый опрос большого количества тегов (особенно на “тяжёлых” экранах);

• попытка работать со сложными структурами без понятной “витрины” данных.

Практический подход для стабильности:

• делайте “витринные” DB/структуры для HMI (чётко определённые поля, без лишнего);

• не используйте “всё подряд” из PLC — экспортируйте только нужное для экранов;

• группируйте теги логически (screen-based: теги конкретного экрана в одной папке).

5.4. Масштабирование и инженерные единицы

Для аналоговых значений заранее определите:

• инженерные единицы (bar, °C, rpm);

• диапазоны;

• формат отображения (кол-во знаков после запятой);

• поведение при ошибке датчика (NaN/ошибка канала).

Лучше держать технологическое масштабирование в PLC, а в HMI — только формат и ограничения ввода.

6) Проектирование интерфейса: экраны, шаблоны и навигация

6.1. Рекомендуемая архитектура экранов

Даже для небольшого проекта удобно иметь фиксированный “скелет”:

• Главный экран (обзор: режим, ключевые параметры, основные кнопки)

• Технологические экраны (по узлам/агрегатам)

• Аварии/Сообщения (алармы, квитирование, фильтры)

• Тренды (ключевые графики)

• Сервис/Настройки (уставки, калибровки, тесты I/O)

• Диагностика связи/оборудования (опционально, но полезно на пусконаладке)

6.2. Создание экрана и базовая разметка

1. Откройте Screens → Add new screen.

2. Задайте имя и назначение (например, SCR_Main, SCR_Alarms).

3. Разместите базовые области:

   • верхняя строка статуса (режим, дата/время, пользователь);

   • зона основного контента;

   • нижняя строка навигации (если используется).

6.3. Шаблоны (Templates) и общие области

Чтобы не копировать элементы на каждый экран:

1. Создайте Template (или используйте механизм общих областей, если доступен).

2. Разместите в шаблоне:

   • заголовок, дата/время;

   • кнопки навигации;

   • индикаторы связи/режима;

   • кнопки аварий/квитирования (если концепция подразумевает постоянную доступность).

3. Применяйте шаблон к экранам.

Практический эффект: изменения меню/статуса делаются в одном месте.

6.4. Навигация

Типовые элементы:

• кнопка “Домой”

• кнопки перехода на узлы

• всплывающие окна (Pop-up) для ввода уставки/подтверждения

• контекстные меню (если поддерживается)

Рекомендация: навигация должна быть предсказуемой, без “прыжков” и скрытых переходов.

7) Динамика объектов: привязки, ввод, блокировки

7.1. Привязка свойств к тегам

У большинства объектов HMI можно привязать свойства к тегам:

• видимость (Visible)

• доступность (Enabled)

• цвет/состояние

• текст/подписи

• значение (Value)

Практический паттерн:

• состояния оборудования (готов/работа/авария/блокировка) описываются в PLC отдельными флагами;

• HMI использует эти флаги для индикации и разрешения действий.

7.2. Ввод значений (уставки)

Для полей ввода задавайте:

• min/max диапазон;

• шаг (если применимо);

• формат;

• подтверждение (особенно для критических параметров);

• условие доступности (например, только при роли “Наладчик”).

Частая ошибка: разрешить ввод уставок без проверки режима (например, в “Авто” без блокировки). Если PLC защищает уставку — это хорошо, но HMI всё равно должен визуально предотвращать очевидно неправильные действия.

7.3. Подтверждения и межблокировки

Критические команды (старт, стоп, сброс аварий, сервисные тесты) лучше делать с подтверждением:

• кнопка → Pop-up “Подтвердить действие”

• запись команды в PLC (импульс/бит)

• PLC подтверждает исполнение (feedback)

Такой цикл резко снижает риск случайных нажатий и облегчает расследование инцидентов.

8) События и скрипты: где допустима логика на HMI

8.1. Обработчики событий

Типовые события:

• Press/Release (нажатие/отпускание кнопки)

• Value changed (изменение тега/поля)

• Screen open/close (открытие/закрытие экрана)

• Cyclic action (циклические действия — использовать осторожно)

Через события обычно реализуют:

• переходы между экранами;

• подтверждения;

• запись командных битов;

• локальные расчёты UI (если необходимо).

8.2. Скрипты (в зависимости от платформы)

В разных средах Siemens HMI скриптинг отличается (например, VBScript встречается в классических HMI-подходах, а в Unified часто применяется JavaScript-ориентация). Важно не “каким языком”, а зачем:

• форматирование строк и составных сообщений;

• дополнительная валидация ввода;

• расчёты UI-уровня (не критические для технологии);

• сервисные функции, не влияющие на безопасность процесса.

8.3. Практическое правило: что держать в PLC, а что можно оставить на HMI

В PLC:

• межблокировки и безопасность;

• алгоритмы управления;

• защита от неправильных команд;

• состояния оборудования и разрешения.

В HMI:

• визуализация и навигация;

• удобство ввода, подтверждения;

• форматирование и подсказки;

• локальные “косметические” вычисления.

Причина: PLC — источник истины и работает детерминированно; HMI может перезагрузиться, потерять связь, зависеть от пользовательского ввода.

9) Сообщения и аварии (Alarms): как сделать их полезными

9.1. Типы тревог

• Дискретные (битовые): авария/предупреждение по флагу.

• Аналоговые: выход параметра за пределы (Hi/HiHi/Lo/LoLo), иногда с гистерезисом.

9.2. Настройка аварий: минимальный стандарт качества

Хорошее сообщение должно отвечать на 4 вопроса:

1. Что случилось (событие)

2. Где случилось (узел/агрегат)

3. Почему могло случиться (причина/контекст)

4. Что делать оператору (действие)

Это оформляется текстом, приоритетом и, при необходимости, связанным “экраном помощи”.

9.3. Приоритеты, классы, квитирование

Рекомендуется разделять:

• аварии, требующие немедленного действия (высокий приоритет);

• предупреждения;

• информационные события (режимы, запуск/останов).

Квитирование (acknowledge) должно быть осмысленным:

• оператор квитирует факт ознакомления;

• сброс аварии (reset) — отдельное действие, если технологически требуется.

9.4. Журнал событий

Даже на панели полезно иметь:

• список активных тревог;

• список архивных (с фильтрами по времени/типу);

• поиск/фильтрацию по узлу.

10) Тренды, рецепты, архивирование

10.1. Тренды

Типовые ошибки трендов:

• слишком высокая частота записи “всё подряд”;

• попытка трендировать сотни параметров;

• отсутствие ключевых “контрольных” величин.

Практический подход:

• определить 10–30 ключевых параметров для диагностики;

• задать разумную частоту (от задачи: быстрые процессы требуют чаще, медленные — реже);

• хранить достаточно истории для анализа инцидентов.

10.2. Рецепты

Рецепты применяют, когда требуется:

• набор уставок под “продукт/партию/режим”;

• быстрое переключение параметров по шаблону.

Риски рецептов:

• отсутствие контроля прав на загрузку;

• загрузка в неправильном режиме оборудования;

• отсутствие подтверждения и протоколирования.

Хорошая практика:

• загрузка рецепта только при разрешающем состоянии (PLC подтверждает);

• протоколирование загрузки (кто, когда, какой рецепт).

10.3. Архивирование: что хранить где

Если панель ограничена по ресурсам, целесообразно:

• хранить критически важные короткие архивы на панели;

• длительные архивы и отчёты — на сервере/SCADA/историке (если архитектура предусматривает).

11) Пользователи, роли и безопасность

11.1. Матрица ролей

Минимальный набор ролей для производства:

• Оператор: просмотр, базовые команды

• Наладчик: уставки, сервисные функции

• Инженер: расширенные настройки, диагностика

• Администратор: пользователи, роли, обслуживание HMI

11.2. Ограничение действий по ролям

Контролируйте как минимум:

• доступ к экрану “Сервис”;

• возможность менять уставки;

• возможность квитировать/сбрасывать аварии (по политике);

• возможность запускать тестовые режимы.

Технически это делается через:

• права на экраны/объекты;

• привязку свойства Enabled/Visible к системным тегам пользователя/роли;

• подтверждения.

11.3. Принцип минимально необходимых прав

Даже если в PLC есть защита, на HMI не стоит показывать лишние кнопки “всем”. В реальных пусках ошибки чаще происходят от непреднамеренных действий.

12) Обмен данными и интеграции

12.1. Базовый обмен HMI ↔ S7

Основа — корректные:

• connection,

• адресация тегов,

• согласование типов,

• частоты обновления.

12.2. Подключение сторонних устройств (концептуально)

В зависимости от платформы и проекта встречаются:

• шлюзы протоколов (когда у оборудования не Siemens-протокол);

• обмен через промежуточные сервисы (сервер, брокер сообщений);

• интеграция по API (если HMI-среда это поддерживает).

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

13) Тестирование, симуляция и отладка

13.1. Что проверять в первую очередь

1. Связь HMI-PLC (онлайн-статусы, чтение/запись ключевых тегов)

2. Навигация: все переходы, pop-up, возвраты

3. Ввод уставок: диапазоны, подтверждения, права

4. Аварии: генерация, приоритеты, квитирование, очистка

5. Тренды: отображение, запись, масштаб осей, сохранение истории

13.2. Типовые проблемы на пусконаладке

• “Теги не обновляются” — связь/адресация/тип данных/оптимизация опроса

• “Панель тормозит” — тяжёлые экраны, слишком много динамики, высокая частота опроса

• “Аварии не появляются” — неверная привязка, класс сообщений, условия формирования, квитирование

• “Рецепт грузится, но оборудование не реагирует” — PLC не принимает в текущем режиме, нет подтверждения/фидбэка

14) Оптимизация производительности и надёжности

14.1. Частота опроса и количество тегов

Чем больше тегов и чем чаще они обновляются, тем выше нагрузка:

• на CPU панели/рантайма;

• на сеть;

• на PLC (в части коммуникаций).

Практические меры:

• обновлять часто только то, что действительно требуется в реальном времени;

• на “сервисных” экранах загружать данные по событию (открыли экран → начали обновлять; закрыли → остановили);

• избегать циклических скриптов, если можно сделать событие по изменению.

14.2. “Тяжёлые” объекты и динамика

Проблемы создают:

• большие таблицы с постоянной перерисовкой;

• множество объектов с динамической видимостью/цветом;

• сложная графика на каждом экране.

Подход:

• выносить повторяющиеся элементы в шаблоны/faceplates;

• минимизировать количество одновременно активных анимаций;

• не “держать открытым” сложный pop-up, если он не нужен.

14.3. Надёжность: связь и диагностика

На HMI стоит явно показывать:

• статус связи с PLC;

• текущий режим (Auto/Manual/Service);

• активные блокировки, если они влияют на команды.

Это снижает ложные обращения “ничего не работает” и ускоряет диагностику.

15) Плюсы и минусы подхода “логика в HMI vs логика в PLC”

Плюсы

• Разгрузка PLC от UI-деталей, если часть логики перенести на HMI (валидации, подсказки, форматирование).

• Быстрая доработка интерфейсных сценариев без изменения технологической программы.

• Удобные пользовательские функции (подсветка, контекстные окна) проще реализуются на HMI.

Минусы

• Логика на HMI менее надёжна: зависит от связи, состояния панели, прав, перезагрузок.

• Риск расхождения поведения: PLC “думает одно”, HMI “показывает другое”, если нет чёткой модели состояний.

• Сложнее сопровождать, если технологически важные решения разбросаны между PLC и HMI.

• Больше точек отказа: при смене панели/версии рантайма логика может потребовать адаптации.

16) FAQ

Что выбирать: Comfort или Unified?

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

Где правильнее делать валидацию и блокировки?

Валидацию ввода (диапазоны, подтверждения) удобно дублировать на HMI для удобства оператора, но блокировки и безопасность должны быть в PLC, чтобы исключить опасные действия при любых сбоях интерфейса.

Как организовать аварии, чтобы они реально помогали?

Каждой тревоге нужен понятный текст, привязка к узлу, приоритет и рекомендуемое действие оператора. Полезно иметь фильтры и историю, а также разделять “аварию”, “предупреждение” и “инфо-событие”.

Почему экран “тормозит” и с чего начать?

Сначала проверяют: количество обновляемых тегов, частоту опроса, объём динамики, таблицы/списки, циклические события. Часто проблема решается снижением обновления “всего подряд” и разделением данных по экранам.

Как безопасно дать доступ наладчику без риска для процесса?

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