Реализация на ARM32/ПЛК для критичных сценариев

Урок 5 · Сценарии умного дома: режимы, состояния, приоритеты · 30 мин · theory

Введение: Отказоустойчивость и роль ПЛК в критичных сценариях

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

> ⚠️ Внимание: Реализация логики безопасности, такой как перекрытие воды или отключение газа, исключительно на высокоуровневых системах без аппаратного резервирования, создает единую точку отказа и не соответствует индустриальным стандартам надежности.

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

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

| Характеристика | Soft Logic (Программная логика) | Hardened Logic (Упрочненная логика) |

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

| Среда выполнения | Операционная система общего назначения (Linux, Windows) на стандартном оборудовании (ПК, Raspberry Pi). | Специализированный микроконтроллер или Программируемый Логический Контроллер (ПЛК). |

| Пример на платформе HI | Сценарии, выполняемые в среде Node-RED на основном процессоре. | Логика, выполняемая на выделенном ARM32-ядре контроллера с функцией ПЛК. |

| Детерминизм | Низкий. Время реакции зависит от общей загрузки ОС, наличия фоновых процессов, обновлений. | Высокий. Гарантированное время цикла выполнения программы (например, <10 мс). |

| Надежность | Уязвима к сбоям ОС, ошибкам в стороннем ПО, нехватке ресурсов (RAM, CPU). | Максимальная. Работает независимо от основной ОС, имеет сторожевой таймер (watchdog). |

| Сохранение состояния | Зависит от программных механизмов (сохранение в файл, БД). | Часто использует энергонезависимую память (EEPROM, FRAM) для мгновенного сохранения. |

| Типичные задачи | Управление освещением, климатом (некритичные аспекты), мультимедиа, сбор статистики. | Защита от протечек, утечек газа, пожарная тревога, управление критичными приводами. |

Необходимость выноса критической логики на отдельные, более надежные устройства обусловлена управлением рисками. Система, работающая под управлением Linux, какой бы надежной она ни была, подвержена множеству потенциальных сбоев: неудачное обновление пакета, исчерпание дискового пространства из-за логов, kernel panic, сбой SD-карты, или просто высокая загрузка процессора сценарием мониторинга, которая помешает вовремя отреагировать на сигнал от датчика протечки.

Контроллер HI спроектирован с учетом этих рисков. Наличие дополнительного ARM32-ядра, работающего в режиме ПЛК, позволяет реализовать "hardened logic" внутри того же физического устройства, но на полностью изолированном аппаратном уровне. Эта подсистема выполняет свою программу циклически и детерминированно, напрямую работая с входами и выходами. Она не зависит от состояния Node-RED или основной ОС Debian. Это обеспечивает надежность промышленного уровня для самых ответственных задач, при этом сохраняя гибкость Node-RED для всего остального.

---

Архитектурные паттерны: ПЛК + Node-RED

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

Паттерн "Автономный модуль" (Рекомендуемый)

Это наиболее надежный и отказоустойчивый паттерн. Его суть заключается в полной автономии ПЛК в выполнении критической задачи.

Логика: Вся цепочка `Датчик -> Логика -> Исполнительное устройство` реализуется непосредственно на ПЛК. Например, датчик протечки подключен к дискретному входу ПЛК, а шаровой кран — к его релейному выходу. Логика "если сработал датчик, то закрыть кран" запрограммирована внутри ПЛК и не зависит ни от каких внешних систем.
Роль Node-RED: Система верхнего уровня (Node-RED) выступает в роли монитора и диспетчера уведомлений. ПЛК лишь информирует Node-RED о своем состоянии через MQTT-сообщения (например, `статус: 'OK'` или `статус: 'ALARM'`). Node-RED, получив сообщение об аварии, запускает второстепенные сценарии: отправляет push-уведомления, включает сирену, отображает алерт на панели управления.
Преимущества:

* Максимальная отказоустойчивость: Защита от протечки сработает, даже если основной контроллер с Node-RED полностью выйдет из строя (например, из-за сбоя питания или зависания ПО).

* Разделение ответственности: ПЛК отвечает за безопасность, Node-RED — за комфорт и информирование.

* Простота отладки: Критическая логика проста, детерминирована и легко проверяется.

       ┌────────────────────────┐
       │     ПЛК (Hardened)     │
       │                        │
[Датчик]─> In ─>[Логика]─> Out ─>[Испол. устр-во]
       │            │            │
       └────────────┼────────────┘
                    │ (Статус: 'ALARM' / 'OK')
                    │
               MQTT │
                    ▼
       ┌────────────────────────┐
       │   Node-RED (Soft)      │
       │                        │
       │ [Мониторинг] [Уведомления]
       │                        │
       └────────────────────────┘

Паттерн "Низкоуровневый процессор" (Не рекомендуется для крит. задач)

В этом паттерне ПЛК используется лишь как "удлинитель" входов/выходов для основного контроллера.

Логика: Датчики и исполнительные устройства подключены к ПЛК, но сам ПЛК не содержит никакой логики. Node-RED по шине (например, Modbus TCP) постоянно опрашивает состояние входов ПЛК, обрабатывает его в своих потоках и отправляет команды на выходы ПЛК.
Роль Node-RED: Является "мозгом" системы, выполняя всю, в том числе и критическую, логику.
Недостатки:

* Единая точка отказа: Сбой в Node-RED, обрыв сети между ним и ПЛК или высокая задержка в опросе приведут к невыполнению критического сценария.

* Сложность и задержки: Постоянный опрос по сети создает трафик и вносит задержку (latency) между событием и реакцией.

* Потеря преимуществ ПЛК: Все достоинства детерминизма и надежности "hardened" ядра теряются, так как оно не принимает решений.

Протоколы взаимодействия на платформе HI

Для реализации надежной гибридной архитектуры используются стандартные протоколы:

MQTT: Идеально подходит для асинхронной передачи статусов от ПЛК к Node-RED. ПЛК публикует сообщение в MQTT-топик только при изменении своего состояния (или для Heartbeat). Это эффективно и не создает лишней нагрузки.

Modbus TCP/RTU: Может использоваться для вспомогательных задач. Например, Node-RED может периодически считывать с ПЛК диагностическую информацию (счетчики срабатываний, время работы) или изменять некритичные уставки (например, порог срабатывания датчика). Но этот канал не должен быть основным для критической логики.

В рамках платформы HI, где ПЛК-ядро и Node-RED находятся в одном корпусе, паттерн "Автономный модуль" является стандартом де-факто для всех сценариев безопасности.

---

Практика: Сценарий 'Защита от протечки' на ПЛК (SCN-SAFETY-001)

Рассмотрим, как на практике реализуется сценарий `SCN-SAFETY-001` с использованием правильной гибридной архитектуры на контроллере HI.

> 💡 Подсказка: Используйте флаг `retain` при отправке MQTT-сообщений о состоянии с ПЛК. Это гарантирует, что Node-RED немедленно получит актуальный статус системы (например, `ALARM` или `OK`) после перезагрузки или переподключения.

Шаг 1: Физическое подключение и логика на ПЛК

Подключение:

* Датчик протечки воды (например, HW-KP) подключается к одному из универсальных входов контроллера, настроенному как дискретный вход (`DI-01`).

* Шаровой кран с электроприводом (220В) подключается к одной из релейных групп (`RL-01`). Питание на привод подается через реле.

Логика на ПЛК (концептуально):

На уровне прошивки ARM32-ядра закладывается простейшая и самая надежная логика. Её можно представить в виде псевдокода:

PROGRAM WaterLeakProtection: VAR Leak_Sensor AT %I0.1 : BOOL; // Физический вход DI-01 Water_Valve AT %Q0.1 : BOOL; // Физический выход RL-01 System_Status : STRING; END_VAR // Основной цикл, выполняется каждые 10 мс IF Leak_Sensor = TRUE THEN Water_Valve := TRUE; // Подать напряжение на кран для закрытия System_Status := 'ALARM'; ELSE Water_Valve := FALSE; // Кран в нормальном положении System_Status := 'OK'; END_IF; // Публикация изменения статуса в MQTT (только если статус изменился) IF System_Status CHANGED THEN PUBLISH_MQTT('hi/plc/water/status', System_Status, RETAIN=TRUE); END_IF; END_PROGRAM.

Эта логика автономна и сработает всегда, пока на контроллер подано питание.

Шаг 2: Настройка публикации статусов (контракт сообщения)

ПЛК должен сообщать о своем состоянии в понятном для Node-RED формате. Мы будем использовать JSON как стандарт.

Топик: `hi/plc/water/status`
Сообщение при тревоге (с флагом Retain):

{ "state": "ALARM", "timestamp": 1678886400000, "source_id": "DI-01", "source_name": "LeakSensor_Bathroom" }

Сообщение в нормальном состоянии (с флагом Retain):

{ "state": "OK", "timestamp": 1678886500000, "source_id": null }

Шаг 3: Обработка статуса в Node-RED

Теперь создадим в Node-RED поток, который будет слушать эти сообщения и реагировать на них, запуская некритичные действия.

ASCII-схема потока:

[mqtt in: hi/plc/water/status] -> [json] -> [switch: msg.payload.state] --+-- ('ALARM') -> [function: "Формат уведомления"] -> [call service: notify]
                                                                          |
                                                                          +-- ('OK') -> [function: "Формат 'Все ОК'"] -> [call service: notify]

Описание узлов:

`mqtt in` (Получение статуса):

* Подписывается на топик `hi/plc/water/status`.

* Сервер настроен на локальный MQTT-брокер контроллера.

* Выход: `a parsed JSON object`.

`switch` (Проверка состояния):

* Проверяет значение поля `msg.payload.state`.

* Правило 1: Если `== "ALARM"`, сообщение идет на первый выход.

* Правило 2: Если `== "OK"`, сообщение идет на второй выход.

`function` (Формат уведомления при тревоге):

* Получает сообщение с данными о тревоге.

* Формирует человекочитаемый текст для отправки пользователю.

* Код:

        // msg.payload = { "state": "ALARM", "timestamp": ..., "source_name": "LeakSensor_Bathroom" }
        const sensor = msg.payload.source_name || "Неизвестный датчик";
        const time = new Date(msg.payload.timestamp).toLocaleString();

        msg.payload = {
            "title": "🚨 ВНИМАНИЕ! ПРОТЕЧКА ВОДЫ!",
            "message": `Обнаружена протечка в ${sensor} в ${time}. Вода перекрыта автоматически.`,
            "priority": "high"
        };
        return msg;

`call service: notify` (Узел отправки уведомлений):

* Это может быть любой узел для отправки сообщений: Telegram, email, push-уведомление через мобильное приложение. Он получает на вход отформатированное сообщение от `function`-узла и отправляет его адресату.

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

---

Интеграция с другими системами: Аварийное освещение и оповещение

Прелесть гибридной архитектуры в том, что один надежный триггер от ПЛК может запустить целый каскад скоординированных действий на верхнем уровне в Node-RED. Это позволяет создавать сложные комплексные сценарии без ущерба для базовой безопасности.

Рассмотрим пример с пожарной тревогой, комбинируя сценарии `SCN-SAFETY-003` (Контроль датчиков дыма/газа) и `SCN-SAFETY-015` (Аварийное освещение).

Обнаружение на уровне ПЛК:

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

* Топик: `hi/plc/alarm/state`

* Сообщение (с флагом Retain):

{ "type": "fire", "state": "active", "location": "kitchen", "timestamp": 1678887000000 }

> ℹ️ Информация: Использование обобщенного топика `hi/plc/alarm/state` позволяет создать единую точку входа в Node-RED для всех типов аварийных ситуаций (пожар, утечка газа, взлом). Тип тревоги передается внутри `msg.payload`.

Оркестрация в Node-RED:

Единственный поток в Node-RED подписывается на этот топик и, в зависимости от типа тревоги, запускает целую цепочку действий.

ASCII-схема потока оркестрации:

                               +-> [DALI: Включить свет в коридоре 100%] -> [SCN-SAFETY-015]
                              /
[mqtt in: hi/plc/alarm/state] -- (type=='fire') -> [switch] --+-> [Modbus: Включить сирену]
                              \
                               +-> [MQTT: Отключить вентиляцию]
                                \
                                 +-> [Notify: Отправить SMS/Push]

Описание работы потока:

Узел `mqtt in` получает сообщение о пожарной тревоге.
Узел `switch` проверяет `msg.payload.type`. Если это `'fire'`, он передает сообщение дальше.
Сообщение разветвляется на несколько параллельных веток:

* Аварийное освещение (SCN-SAFETY-015): Посылается DALI-команда `Broadcast -> Go to Max Level` для включения всего аварийного освещения на путях эвакуации.

* Звуковое оповещение: Через узел `Modbus-Write` подается команда на релейный модуль, подключенный к сирене.

* Отключение вентиляции: Публикуется MQTT-сообщение в топик `cmnd/ventilation/power` со значением `OFF` для предотвращения распространения дыма.

* Уведомление: Запускается узел отправки уведомлений пользователям и, возможно, на пульт охраны.

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

---

Мониторинг доступности ПЛК: механизм 'Heartbeat'

"Кто будет сторожить самих сторожей?" Этот древний вопрос как нельзя лучше описывает проблему мониторинга систем безопасности. Если ПЛК, отвечающий за защиту от протечек, выйдет из строя (например, из-за неисправности блока питания), то и вся система защиты станет бесполезной. Поэтому контроль работоспособности самого ПЛК является обязательным элементом надежной архитектуры.

Для этой цели используется простой и эффективный механизм — Heartbeat (сердцебиение).

Реализация 'Heartbeat'

На стороне ПЛК:

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

* Топик: `hi/plc/heartbeat`

* Сообщение: Может быть простым, но полезно включать в него какую-либо диагностическую информацию.

{ "timestamp": 1678888000000, "uptime_sec": 7200, "load_avg": 0.05 }

На стороне Node-RED:

Создается поток, который отслеживает поступление этих сообщений. Ключевым элементом здесь является узел `trigger`.

ASCII-схема потока мониторинга:

    [mqtt in: hi/plc/heartbeat] -> [trigger: 90s] -- (нет сообщения) --> [function: "Тревога: ПЛК не в сети"] -> [call service: notify_admin]

Настройка узлов:

`mqtt in`: Подписывается на топик `hi/plc/heartbeat`.

`trigger` (Важнейший узел):

* Send: `nothing` (изначально ничего не отправляет).

* then wait for: `90` seconds (задержка должна быть больше периода Heartbeat, обычно в 2-3 раза).

* then send: `{"error": "PLC is offline"}` (сообщение, которое отправится, если таймер не будет сброшен).

* Handling: `extend delay if new message arrives`.

* Принцип работы: Каждый раз, когда от ПЛК приходит `heartbeat`-сообщение, оно "сбрасывает" 90-секундный таймер в узле `trigger`. Если же в течение 90 секунд ни одного сообщения не пришло (что означает, что ПЛК либо завис, либо обесточен), узел `trigger` отправит на свой выход собственное сообщение о тревоге.

`function` (Формат тревоги):

Формирует сообщение для администратора системы.

    msg.payload = {
        "title": "🔴 КРИТИЧЕСКИЙ СБОЙ СИСТЕМЫ",
        "message": "Модуль безопасности (ПЛК) не отвечает более 90 секунд. Возможен отказ критически важных функций. Требуется немедленная проверка оборудования!",
        "priority": "emergency"
    };
    return msg;

`call service: notify_admin`: Отправляет это экстренное сообщение администратору по всем доступным каналам (SMS, звонок, email).

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

---

Резюме и ключевые выводы

езюме и ключевые выводы

В этом уроке мы рассмотрели фундаментальный принцип построения отказоустойчивых систем автоматизации: разделение ответственности между гибкой программной логикой (`soft logic`) и надежной аппаратной логикой (`hardened logic`). Такой подход является единственно верным при реализации сценариев, от которых зависит безопасность людей и сохранность имущества.

> 🔗 Связанный материал: Подробные сведения о настройке Modbus и MQTT узлов в Node-RED, а также о работе с JSON-форматом, рассмотрены в модуле по протоколам и интеграциям в уроке COURSE-04-M02-L01.

Ключевые тезисы, которые необходимо усвоить:

Критические функции — на ПЛК: Все сценарии, представляющие угрозу (протечки, газ, пожар), должны быть реализованы на отказоустойчивых "упрочненных" устройствах. На платформе HI для этого используется выделенное ARM32-ядро с функцией ПЛК.

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

Роль Node-RED: В гибридной архитектуре Node-RED выступает в роли центра мониторинга, диспетчеризации уведомлений и оркестрации второстепенных, некритичных сценариев, которые запускаются по сигналу от ПЛК.

Контроль — обязателен: Недостаточно просто реализовать защиту. Необходимо постоянно контролировать работоспособность самого защитного модуля с помощью механизмов вроде `Heartbeat`. Система должна сообщать не только об авариях, но и о собственных сбоях.

Что дальше?

Освоив принципы построения отказоустойчивых систем для аварийных ситуаций в рамках урока `COURSE-07-M07-L01`, в следующем модуле мы перейдем к более сложным комплексным сценариям, которые объединяют безопасность, управление климатом и освещением в единые режимы работы объекта, такие как "Я дома", "Отпуск" или "Вечеринка". Мы научимся управлять состояниями всей системы и выстраивать приоритеты между различными сценариями.