HMI для промышленного источника
бесперебойного питания

Задача и ограничения

Новое оборудование, которое меняется
прямо во время разработки

Раньше ИБП закупали у сторонних производителей. Компания решила сделать свой — и сразу под реальные объекты заказчиков.

Задача

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

Ограничения

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

Моя роль

Между инженерной логикой и оператором

Я работал в отделе разработки проектов и один вёл всё направление ИБП: от программной логики до интерфейса. Параллельно создавалось четыре проекта под разные требования заказчиков, поэтому я взял в подчинение двух junior-разработчиков: обучал их, принимал решения в спорных моментах и следил за ходом их проектов. Логику и HMI этой системы я делал сам.

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

• Логика и алгоритмы. Режимы, переходы, блокировки, аварийные сценарии — вместе с главным инженером проекта.
• Оборудование. Внутренняя логика и работа плат инвертора и байпаса — со схемотехниками; таблицы сигналов и состав модулей — с отделом технического конструирования; драйверы связи с инвертором и сторонними устройствами — с драйверистами.
• HMI. Информационная архитектура, навигация, главный экран, состояния элементов и обратная связь.
• Испытания. Все внутренние проверки вместе с испытателями и стендовые испытания с заказчиком.

Рабочий процесс

Сначала понять систему, потом рисовать экраны

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

1. 01

   Декомпозиция системы

   Разложил ИБП на функциональные узлы и сигналы.

2. 02

   Модель состояний

   Описал режимы, допустимые переходы и условия.

3. 03

   Алгоритмы

   Блок-схемы автоматического и ручного управления.

4. 04

   Аварии и уставки

   Определил возможные аварии и уставки, составил таблицы сигнализации.

5. 05

   Архитектура HMI

   Приоритеты информации и уровни экранов.

6. 06

   Экраны и состояния

   Мнемосхема, индикация, блокировки, подтверждения.

7. 07

   Испытания

   Внутренние проверки и стендовые испытания с заказчиком.

На практике шаги шли не строго по порядку. После испытаний менялись схемы, платы и сигналы — я возвращался к модели состояний и алгоритмам, дорабатывал проект и экраны.

Система ИБП

Из чего состоит система

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

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

Режимы и переходы

Шесть режимов — одна модель состояний

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

Как ИБП переходит между режимами

Всего в ИБП 17 переходов, и у каждого есть конкретное условие. Других путей нет: например, из аварийного останова ИБП возвращается в работу только через режим «Отключён». Ниже — по одному переходу в каждый режим, остальные раскрываются по кнопке.

Алгоритмы

Алгоритмы как часть проектирования поведения

Для каждого сценария — запуск, переход на АКБ, байпас, авария — я описал последовательность шагов, условия и блокировки. Фактически это проектирование взаимодействия на уровне системы: что происходит, когда оператор нажимает кнопку, и что — когда он ничего не делает.

Пример: запуск ИБП в режим «Работа»

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

Защиты системы

Защиты системы

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

Один датчик — несколько порогов

Для одного и того же датчика задаётся несколько порогов. Оператор узнаёт о проблеме заранее, а не в момент, когда что-то уже отключилось.

Главный экран

Всё, что выше, — на одном экране

Главный экран — мнемосхема. За секунду она отвечает на три вопроса: откуда идёт питание, какой режим активен и есть ли проблема. Цвет и положение элементов повторяют физическую схему, поэтому оператор узнаёт её сразу.

1 2 3 4 5 6 7 8

1. Режим ИБП — первое, что читается. Цвет фона повторяет тон режима.
2. Строка статуса — одна на всю панель: нет аварий, есть неквитированная авария или нет связи.
3. Связь с модулями — 7/7. Если ответили не все, индикатор становится жёлтым.
4. Подчёркнутое открывает экран. Ввод, инвертор, ЗВУ, АКБ ведут на свою страницу в «Модулях».
5. Плата байпаса — устанавливаем приоритетный ввод и видим, куда сейчас идёт нагрузка.
6. Ремонтный байпас заблокирован, и это должно быть хорошо видно.
7. Холодный старт — возможность запустить ИБП от батарей при нужных условиях.
8. Время работы от АКБ — сколько ИБП проработает под нагрузкой.

Больше тысячи сигналов за одним экраном

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

Пример: пропали оба ввода

ИБП перешёл на батареи. Вот что увидит оператор в этот момент.

1 2 3 4 5 6 7 8

1. Режим «Работа от АКБ» — оба ввода без питания, система продолжает работу.
2. Строка статуса — самая свежая неквитированная сигнализация и её время.
3. Вводы «Нет напряжения» — напряжение на всех трёх фазах обоих вводов ниже порога.
4. Инвертор «В работе» и путь под напряжением через него — инвертор запущен и продолжает преобразовывать напряжение.
5. Напряжение шины постоянного тока — показывается прямо на линии.
6. Ключи QF71–QF73 и «Разряд» на АКБ — положения автоматов групп и направление тока батареи.
7. ≈ 38 мин — сколько ИБП сможет питать нагрузку, рассчитывается из заряда и тока батареи.
8. Активные сигнализации — три предупредительных сигнализации, с временем и квитированием.

Один экран — все режимы

Строка режима и статуса меняется вместе с системой. Ниже — три основных состояния, остальные раскрываются по кнопке.

Архитектура HMI

Разделы панели

В панели пять разделов: Главная, Модули, Климат, Журнал и Управление. В шапке всегда видны основное меню, статус системы, пользователь и связь с модулями. Строка статуса закреплена вместе с шапкой, поэтому последняя неквитированная авария видна на любом экране.

ГлавнаяМодулиКлиматЖурналУправление

Каждый элемент на схеме — интерактивный

Нажатие на любой элемент на Главной сразу открывает его экран с параметрами. Например, «Инвертор» ведёт в «Модули» на мастер-инвертор, без поиска по дереву.

Модули

Слева — дерево узлов системы в порядке установки шкафов, справа — параметры узла. У однотипных узлов одинаковый шаблон, чтобы оператор быстрее считывал состояние системы. То, что нужно редко, убрано в «Дополнительные параметры».

Безопасность действий

Защита от ошибочных действий

Ошибка оператора может оставить нагрузку без питания. Поэтому интерфейс не даёт выполнить команду, если для неё нет условий, а перед критическими действиями показывает, что произойдёт. Если что-то пошло не так — команда отклонена, авария или пропала связь, — интерфейс говорит об этом прямо.

ПраваПредусловияПодтверждениеОшибка командыАварииНет связи

Состояния и обратная связь

Единый язык состояний

Цвет на панели везде значит одно и то же: в шапке, на карточке шкафа, в журнале и в списке сигнализаций. Палитра взята из соглашений, привычных для промышленной автоматики, поэтому её не нужно заучивать. Цвет всегда дублируется словом — «Норма», «Предупреждение», «Авария».

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

Журнал Квитирование Климат

Экраны панели

Все экраны

Панель 1366×768 стоит в двери шкафа управления. Здесь все 50 экранов и состояний, по разделам: от штатной работы до аварии, ручного режима и входа в систему.

Попробовать прототип

Кликабельный прототип панели: экраны, команды, окна подтверждения. Режимы оборудования (авария, работа от АКБ, байпас) переключаются в полноэкранной версии.

Испытания и запуск

Проверено на реальном оборудовании

Сначала логику и интерфейс проверили у себя, затем на стенде вместе с заказчиком. Прогнали:

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

6 мес.

от старта до запуска

4

системы прошли испытания и уехали на объекты

1

в эксплуатации на КС Чикшинская, три ждут ввода

Итоги

Что показывает этот кейс

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