Сценарий 'Потеря питания контроллера': состояние выходов

Урок 3 · Введение в протоколы автоматизации · 30 мин · theory

Проблема неопределенного состояния выходов

> 🔗 Связанный материал: Данный урок является логическим продолжением урока "Концепция 'Safe-State': что это и зачем нужно". Для полного понимания материала настоятельно рекомендуется предварительно изучить его.

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

Предсказуемость поведения системы в момент сбоя — это не просто удобство, а фундаментальное требование к безопасности и эффективности любого объекта автоматизации. Когда контроллер перезапускается, его операционная система и среда выполнения Node-RED загружаются с нуля. Потоки сценариев, которые управляли оборудованием, еще не запущены. В этот промежуток времени состояние реле, диммеров, клапанов и приводов может оказаться хаотичным.

Рассмотрим риски, связанные с неконтролируемым состоянием выходов после перезагрузки контроллера:

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

Насосное оборудование: В системе водоснабжения или дренажа случайное включение насоса может привести к переполнению емкости, затоплению подвала или работе насоса "на сухую", что неизбежно выведет его из строя. Если насос, наоборот, не включится в нужный момент (например, дренажный насос во время ливня), последствия могут быть катастрофическими.

Системы освещения: Критически важно, чтобы аварийное и эвакуационное освещение переходило в заранее определенное, безопасное состояние. Если после сбоя питания оно останется выключенным, это создаст прямую угрозу безопасности людей. В то же время, если все освещение на объекте (например, в гостинице) включится на 100%, это приведет к огромным счетам за электроэнергию.

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

Все эти примеры наглядно демонстрируют, почему концепция 'Safe-State', рассмотренная нами ранее, имеет первостепенное значение. Система должна быть спроектирована таким образом, чтобы при любом сбое, включая потерю питания контроллера, все исполнительные устройства переходили в заранее определенное, безопасное для людей, оборудования и объекта в целом состояние. Этот урок посвящен практическим методам достижения такого поведения.

---

Аппаратные 'Defaults' и их роль

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

> ⚠️ Внимание: Всегда проверяйте даташит (datasheet) конкретного модуля расширения! Поведение выходов при потере питания может отличаться у разных производителей и даже у разных серий одного и того же устройства. Аппаратный 'default' — это ваш последний рубеж обороны.

Основным инструментом для построения безопасных систем на аппаратном уровне является правильный выбор между типами контактов реле: нормально разомкнутый (Normally Open - NO) и нормально замкнутый (Normally Closed - NC).

📋 Ключевые понятия:

Normally Open (NO): В обесточенном состоянии (когда на катушку реле не подано напряжение) электрическая цепь разомкнута. Ток не протекает. Для замыкания цепи на катушку реле необходимо подать управляющее напряжение.
Normally Closed (NC): В обесточенном состоянии цепь замкнута. Ток протекает. Для размыкания цепи на катушку реле необходимо подать управляющее напряжение.

Большинство универсальных релейных модулей, например, используемых с нашим контроллером, предоставляют оба типа контактов (а также общий контакт `COM`). Это дает инженеру гибкость в проектировании безопасного состояния.

Как использовать NO и NC для построения безопасных систем

Выбор типа контакта напрямую зависит от функции нагрузки. Задайте себе вопрос: "Что должно произойти с этой нагрузкой, если контроллер полностью выйдет из строя?".

| Тип нагрузки | Рекомендуемый контакт | Обоснование |

| --------------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |

| Отопительное оборудование | NO (Нормально разомкнутый) | Критически важно, чтобы котел, конвекторы или теплые полы были выключены при сбое. Их случайная работа ведет к перегреву и пожару. |

| Насосы (водоснабжение, полив) | NO (Нормально разомкнутый) | Насос должен быть выключен во избежание работы "всухую" или переполнения емкостей. |

| Розеточные группы (общие) | NO (Нормально разомкнутый) | Большинство бытовых приборов безопаснее оставить выключенными при сбое. |

| Приводы ворот, шлагбаумов | NO (Нормально разомкнутый) | Движение должно быть прекращено при потере управления во избежание повреждений и травм. |

| Аварийное освещение (DC) | NC (Нормально замкнутый) | Светильник должен включиться, когда контроллер теряет питание. Питание на светильник подается постоянно, а реле разрывает цепь. |

| Электромагнитные замки (fail-safe) | NC (Нормально замкнутый) | Замок должен разблокироваться при сбое питания для обеспечения эвакуации. Реле в рабочем состоянии удерживает замок закрытым. |

Почему нельзя полагаться только на аппаратные 'defaults'

Несмотря на важность правильного выбора контактов NO/NC, одного этого недостаточно. Этот механизм срабатывает только при полном обесточивании самого релейного модуля. Однако существует сценарий, когда сам модуль запитан, а контроллер, который им управляет по шине (например, RS-485), перезагружается или теряет связь.

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

Анализ документации на релейный модуль, диммер или любой другой модуль вывода — это обязательный шаг проектирования. В даташите вы найдете не только типы контактов, но и информацию о поведении устройства при потере связи с мастером шины, что позволяет перейти к следующему этапу настройки.

---

Настройка 'Safe State' в wb-mqtt-serial

Второй, программный уровень обеспечения безопасности реализуется на уровне драйвера, который осуществляет связь между логикой контроллера и физическими устройствами на шине Modbus. На нашей платформе на базе Debian эту роль выполняет сервис wb-mqtt-serial.

Принцип работы wb-mqtt-serial:

Это служба (демон), которая постоянно опрашивает Modbus-устройства, подключенные к последовательным портам контроллера (например, `/dev/ttyRS485-1`). Данные с устройств (состояние реле, показания датчиков) она публикует в MQTT-топики. В свою очередь, получая сообщения в специальных `.../on` топиках, служба отправляет Modbus-команды на запись в устройства. Таким образом, `wb-mqtt-serial` — это мост между миром Modbus и миром MQTT.

Ключевой для нашей задачи является возможность этого драйвера контролировать состояние выходов Modbus-устройств в случае, если связь с MQTT-брокером (а значит, и со всей логикой Node-RED) потеряна. Это настраивается через параметр `safe_state` в конфигурационном файле `/etc/wb-mqtt-serial.conf`.

Конфигурация параметра 'safe_state'

Файл `/etc/wb-mqtt-serial.conf` имеет формат JSON и описывает все устройства, подключенные к портам. Для каждого канала (например, отдельного реле) можно задать параметр `safe_state`.

`safe_state` определяет, в какое состояние должен перейти канал устройства, если драйвер `wb-mqtt-serial` в течение заданного таймаута не может связаться с MQTT-брокером.

Доступные значения для `safe_state`:

`0`: при сбое связи установить значение канала в 0 (выключено). Это самый частый и безопасный выбор для большинства нагрузок.
`1`: при сбое связи установить значение канала в 1 (включено). Используется редко, например, для включения сигнальной лампы или сирены.
`-1`: не изменять состояние. Канал останется в том же положении, в котором он был до сбоя. Это поведение по умолчанию, и оно является небезопасным для критических нагрузок.

Практический пример конфигурации

Предположим, у нас есть релейный модуль на 6 выходов, подключенный по Modbus (адрес 10). Нам нужно настроить безопасное состояние для каждой нагрузки.

# Открываем файл конфигурации для редактирования
sudo nano /etc/wb-mqtt-serial.conf

Добавляем или редактируем секцию `devices`, чтобы она выглядела следующим образом:

{
    "path": "/dev/ttyRS485-1",
    "baud_rate": 9600,
    "parity": "N",
    "data_bits": 8,
    "stop_bits": 1,
    "devices": [
        {
            "name": "Relay_Module_1",
            "id": 10,
            "enabled": true,
            "channels": [
                {
                    "name": "Relay 1 - Living Room Light",
                    "reg_type": "coil",
                    "address": 0,
                    "safe_state": 0
                },
                {
                    "name": "Relay 2 - Kitchen Sockets",
                    "reg_type": "coil",
                    "address": 1,
                    "safe_state": 0
                },
                {
                    "name": "Relay 3 - Water Heater",
                    "reg_type": "coil",
                    "address": 2,
                    "safe_state": 0
                },
                {
                    "name": "Relay 4 - Garage Door",
                    "reg_type": "coil",
                    "address": 3,
                    "safe_state": 0
                },
                {
                    "name": "Relay 5 - Alarm Siren",
                    "reg_type": "coil",
                    "address": 4,
                    "safe_state": 1
                },
                {
                    "name": "Relay 6 - Non-critical load",
                    "reg_type": "coil",
                    "address": 5,
                    "safe_state": -1
                }
            ]
        }
    ]
}

Анализ конфигурации:

Реле 1-4, управляющие светом, розетками, бойлером и воротами, принудительно выключатся (`"safe_state": 0`).
Реле 5, управляющее сиреной, наоборот, включится (`"safe_state": 1`), сигнализируя о проблеме с контроллером.
Реле 6 оставит свое состояние неизменным (`"safe_state": -1`), так как нагрузка не является критичной.

Проверка применения настроек

После сохранения файла `/etc/wb-mqtt-serial.conf` необходимо перезапустить службу, чтобы изменения вступили в силу.

# Перезапускаем драйвер
sudo systemctl restart wb-mqtt-serial

# Проверяем статус службы, чтобы убедиться, что она запустилась без ошибок
sudo systemctl status wb-mqtt-serial

Чтобы проверить срабатывание `safe_state`, можно сымитировать сбой. Самый простой способ — остановить службу MQTT-брокера на контроллере.

# Останавливаем брокер Mosquitto
sudo systemctl stop mosquitto

Через несколько секунд драйвер `wb-mqtt-serial` обнаружит потерю связи и переведет выходы релейного модуля в сконфигурированные безопасные состояния. Вы должны услышать щелчки реле и увидеть, что бойлер выключился, а сирена включилась. После этого не забудьте запустить брокер обратно: `sudo systemctl start mosquitto`.

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

---

Использование MQTT Retain флага

Третий уровень управления состоянием системы после перезагрузки находится на логическом уровне и связан с особенностями протокола MQTT. Это флаг Retain (удержание).

> 💡 Подсказка: Используйте утилиту `MQTT Explorer` или команду `mosquitto_sub` с флагом `-c` для отладки и просмотра 'retained' сообщений на вашем брокере. Это поможет быстро выявить, какие топики сохраняют свое состояние.

Что такое 'retained' сообщение в MQTT?

Когда сообщение публикуется в топик с установленным флагом `retain=true`, MQTT-брокер не просто доставляет его текущим подписчикам, но и сохраняет его у себя. Когда новый клиент подписывается на этот топик, брокер немедленно отправляет ему это последнее сохраненное сообщение. Фактически, это "липкое" сообщение, которое хранит последнее известное состояние топика.

В Node-RED этот флаг устанавливается галочкой "Retain" в настройках узла `mqtt out`.

(Предполагается, что здесь будет изображение узла mqtt out с выделенной опцией retain)

При перезагрузке контроллера и запуске Node-RED узлы `mqtt in` подписываются на свои топики. Если на брокере для этих топиков есть `retained`-сообщения, они немедленно придут в Node-RED и инициируют выполнение потоков. Это позволяет восстановить состояние системы до того, каким оно было перед перезагрузкой. Но в этом кроется как удобство, так и серьезный риск.

Сценарии использования Retain флага

Использование `retain` флага должно быть осознанным решением.

✅ Оправданное использование (некритичные нагрузки):

Состояние освещения: Пользователь включил свет в гостиной. Команда `{"value": true}` была отправлена в топик `.../light/set` с `retain=true`. После перезагрузки Node-RED сразу получает это состояние и может корректно отобразить его в интерфейсе. Если свет физически включен, логика не нарушится.
Выбранный режим работы: Сценарий "Я дома" был активирован. Сообщение `{"mode": "home"}` было отправлено с `retain=true`. После перезагрузки система знает, какой режим был активен, и может восстановить соответствующую логику.
Последние показания датчиков: Публикация температуры или влажности с `retain=true` полезна, так как любой новый клиент (например, мобильное приложение) сразу получит актуальные данные, не дожидаясь следующего опроса.

❌ Рискованное и недопустимое использование (критические нагрузки):

Управление насосом: Таймер включил насос для полива на 30 минут. Команда `{"value": true}` была отправлена с `retain=true`. Через 5 минут происходит сбой питания. После перезагрузки Node-RED подписывается на топик, получает сохраненное `{"value": true}` и снова включает насос, но уже без таймера, который бы его выключил. Результат: насос будет работать бесконечно или пока его не отключат вручную.
Управление бойлером: Термостат включил нагрев воды. Команда `{"value": true}` отправлена с `retain=true`. После перезагрузки контроллера Node-RED запускает отопление, даже если температура в помещении уже достигла уставки, так как логика термостата еще не успела отработать.

Главное правило: Никогда не используйте `retain=true` для топиков, которые инициируют действие, связанное с потенциально опасными или энергозатратными нагрузками. Используйте его только для топиков, которые сообщают состояние.

Взаимодействие с Node-RED:

При запуске потока узел `mqtt in`, подписанный на топик с `retained` сообщением, сгенерирует `msg` точно так же, как если бы это сообщение пришло в реальном времени. Это инициирует всю цепочку узлов, подключенных после него. Если вы не уверены в безопасности этого поведения, всегда отключайте флаг `retain` для управляющих топиков. Состояние лучше запросить принудительно после стабилизации системы, чем восстанавливать его из потенциально устаревших и опасных сохраненных данных.

---

Резюме и чек-лист проектировщика

Мы рассмотрели три уровня обеспечения безопасного и предсказуемого состояния выходов при потере питания контроллера. Профессиональный подход к проектированию систем автоматизации подразумевает обязательное использование всех трех.

📋 Три уровня обеспечения безопасности:

Аппаратный уровень (физика): Выбор правильного типа контактов реле (`NO` или `NC`). Это базовая, самая надежная защита, работающая даже при полном отказе всей электроники. Нагрузки, которые должны быть обесточены при сбое (котлы, насосы, розетки), подключаются через нормально разомкнутые (NO) контакты.

Уровень драйвера (прошивка): Настройка параметра `safe_state` в конфигурации драйвера `wb-mqtt-serial`. Это защищает систему от сбоев связи между контроллером и модулями на шине (например, при перезагрузке Node-RED или MQTT-брокера). Для большинства нагрузок устанавливается `safe_state: 0` (выключить).

Логический уровень (приложение): Осторожное и осознанное использование флага `MQTT retain`. Флаг используется только для сохранения состояния некритичных систем (статус света, режим работы), но никогда — для команд, управляющих потенциально опасными нагрузками.

Алгоритм проектирования безопасного состояния

При подключении любой новой нагрузки инженер должен последовательно выполнить следующие шаги:

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

Выбрать тип контакта: Подключить нагрузку к соответствующей клемме реле (`NO` или `NC`).

Сконфигурировать драйвер: Прописать в `/etc/wb-mqtt-serial.conf` для данного канала соответствующее значение `safe_state` (обычно `0`).

Настроить логику: При отправке команд в MQTT-топик управления этой нагрузкой из Node-RED убедиться, что флаг `retain` в узле `mqtt out` не установлен.

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

Чек-лист отказоустойчивости к потере питания

[ ] Нагревательное оборудование (котлы, ТЭНы): Подключено через NO-контакт. `safe_state` установлен в `0`. `MQTT retain` для команды включения не используется.

[ ] Насосное оборудование: Подключено через NO-контакт. `safe_state` установлен в `0`. `MQTT retain` для команды включения не используется.

[ ] Розеточные группы: Подключены через NO-контакт. `safe_state` установлен в `0`. `MQTT retain` не используется.

[ ] Приводы (ворота, шторы): Подключены через NO-контакт. `safe_state` установлен в `0`. `MQTT retain` не используется.

[ ] Аварийное освещение / Системы оповещения: Подключены через NC-контакт. `safe_state` установлен в `1` (если требуется активное включение при сбое логики). `MQTT retain` не используется.

[ ] Все потоки Node-RED, управляющие критическими нагрузками: Проверены на отсутствие флага `retain` в узлах `mqtt out`.

Что дальше

В этом уроке мы заложили фундамент для создания систем, устойчивых к сбоям питания. Однако простая перезагрузка и восстановление безопасного состояния — это только половина задачи. В следующем уроке мы рассмотрим стратегии "грациозного" запуска системы после сбоя. Мы научимся использовать отложенный запуск сложных сценариев в Node-RED, чтобы дать системе время на стабилизацию, опрос всех датчиков и предотвращение "гонки состояний", когда логика пытается работать с еще не определившимися данными.