Роль дополнительного ARM32-процессора

Урок 4 · Основы умного дома · 30 мин · theory

Введение: Архитектура «Основной CPU + Микроконтроллер»

В современных системах автоматизации, от умного дома до промышленных объектов, часто возникает конфликт между необходимостью выполнять сложные, ресурсоемкие задачи и требованием мгновенной, предсказуемой реакции на физические события. Системы, построенные на базе одного мощного процессора под управлением операционной системы общего назначения (например, Linux на Raspberry Pi), сталкиваются с фундаментальным ограничением: недетерминированностью. Это означает, что ОС не может гарантировать выполнение конкретной операции в строго определенный временной интервал. Для веб-сервера или базы данных задержка в несколько десятков миллисекунд незаметна, но для управления диммером или обработки сигнала с датчика протечки такая задержка может быть критичной.

Для решения этой проблемы в профессиональных контроллерах, включая платформу HI, применяется двухкомпонентная архитектура, известная как архитектура «CPU + MCU».

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

Основной CPU (Central Processing Unit): Мощный процессор (в нашем случае 4-ядерный ARM), работающий под управлением полноценной ОС Linux (Debian). Он отвечает за высокоуровневую логику: исполнение сценариев Node-RED, работу с базами данных (MySQL), сетевое взаимодействие (MQTT, HTTP), обслуживание пользовательских интерфейсов.
Микроконтроллер (MCU - Microcontroller Unit): Дополнительный, менее производительный, но высокоспециализированный процессор (в нашем случае ARM32). Он работает без тяжелой ОС (или под управлением ОС реального времени) и напрямую подключен к физическим входам и выходам (I/O) контроллера. Его задача — выполнение операций, критичных ко времени, с гарантированной скоростью и точностью.

Эта концепция разделения задач является стандартом де-факто в промышленной автоматизации и позволяет достичь лучшего из двух миров:

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

Надежность и предсказуемость MCU: Гарантированное время реакции на события, стабильная работа I/O независимо от загрузки основного CPU.

Механизм взаимодействия

Основной процессор и микроконтроллер на плате контроллера HI общаются между собой по внутреннему высокоскоростному последовательному интерфейсу, такому как UART или SPI. С точки зрения Linux и Node-RED, микроконтроллер и вся подключенная к нему периферия (реле, входы, порты) выглядят как единое виртуальное устройство.

Основной CPU не занимается "дёрганьем ножек" — он отправляет микроконтроллеру высокоуровневые команды. Например:

Вместо сложной логики генерации ШИМ-сигнала, CPU отправляет команду: `"Установить на выходе 5 яркость 75%"`.
Вместо постоянного опроса состояния "сухого контакта", CPU подписывается на события от MCU, который сам отслеживает изменение и отправляет уведомление.

Таким образом, MCU выступает в роли аппаратного «драйвера» или слоя абстракции аппаратных I/O. Он скрывает от основной операционной системы всю низкоуровневую сложность работы с физическим оборудованием, предоставляя ей простой и надежный интерфейс для управления и получения данных.

---

Повышение надёжности I/O и работа в реальном времени

Главная проблема операционных систем общего назначения, таких как Linux, — это работа планировщика задач. Планировщик — это компонент ядра ОС, который распределяет процессорное время между множеством запущенных процессов (Node-RED, веб-сервер, служба MQTT и т.д.). Его цель — обеспечить "честное" разделение ресурсов и отзывчивость системы в целом. Однако это означает, что выполнение вашего скрипта может быть в любой момент прервано на десятки или даже сотни миллисекунд для выполнения другой, более приоритетной с точки зрения ОС, задачи.

Этот эффект, называемый недетерминированностью, делает невозможной надежную реализацию некоторых функций на уровне основного CPU:

ШИМ-управление (PWM): Для плавного диммирования света требуется генерировать сигнал с частотой в сотни или тысячи Герц и очень точным изменением скважности. Программная реализация в Node-RED будет страдать от "дрожания" яркости из-за задержек планировщика.
Подсчет быстрых импульсов: При считывании данных с импульсных счетчиков воды или электроэнергии, а также с энкодеров, пропуск даже одного короткого импульса из-за задержки ОС приводит к накоплению ошибки.
Низкоуровневые протоколы: Реализация протоколов типа 1-Wire или прием/передача данных по RS-485 требует соблюдения строгих таймингов. Любая задержка может привести к срыву обмена данными.

Делегирование задач на MCU

Архитектура «CPU + MCU» решает эту проблему путем делегирования всех критичных ко времени операций на микроконтроллер. MCU не имеет сложного планировщика и выполняет свою прошивку циклически, с предсказуемой скоростью. Это и есть обработка в реальном времени (real-time processing).

| Задача | Ненадежная реализация (только CPU) | Надежная реализация (CPU + MCU) |

| :--- | :--- | :--- |

| Управление диммером | Скрипт в Node-RED пытается генерировать ШИМ, используя `setTimeout`. Яркость мерцает при нагрузке на CPU. | Node-RED отправляет MQTT-сообщение `{"brightness": 50}`. MCU получает команду и его аппаратный таймер начинает генерировать идеальный ШИМ-сигнал. |

| Считывание показаний счетчика воды | Скрипт постоянно опрашивает GPIO-вход. При высокой загрузке CPU возможен пропуск импульсов. | MCU настроен на работу со входом в режиме счетчика импульсов. Он аппаратно считает каждый фронт сигнала и хранит значение. Node-RED считывает это значение по запросу или получает по событию. |

| Работа с шиной RS-485 | Программный драйвер в Linux формирует пакеты Modbus. Задержки ОС могут нарушить тайминги и привести к ошибкам CRC. | Node-RED отправляет данные для пакета Modbus в MCU. MCU самостоятельно формирует пакет с точными временными интервалами и управляет приемопередатчиком RS-485. |

> 💡 Подсказка: Для задач, где требуется точность до миллисекунд, таких как управление диммированием по фазе (leading/trailing edge) или подсчет импульсов с энкодера, всегда используйте аппаратные возможности MCU, а не пытайтесь реализовать это на уровне скриптов в Node-RED. Это гарантирует стабильность и предсказуемость работы.

🔗 Связанный материал: Эта концепция тесно связана с тем, что мы обсуждали в уроке "Функция ПЛК и Safe-State". MCU фактически реализует нижний, аппаратный уровень логики ПЛК, обеспечивая детерминизм и предсказуемость, характерные для промышленных контроллеров.

---

Практика: Взаимодействие с MCU через MQTT-сообщения

На контроллере HI взаимодействие между основной ОС (и Node-RED) и микроконтроллером стандартизировано и происходит через протокол MQTT. Специальная системная служба (аналогичная `wb-mqtt-serial` в контроллерах Wirenboard) выступает в роли моста. Она общается с MCU по внутреннему порту и представляет все его аппаратные ресурсы в виде иерархии MQTT-топиков.

Принцип представления ресурсов в MQTT:

Каждое реле, каждый вход, каждый порт имеет свой уникальный путь в MQTT-брокере.
Для управления устройством нужно отправить сообщение в топик с суффиксом `/on`.
Для получения текущего состояния нужно подписаться на топик без этого суффикса.

Структура топиков (типовой пример):

`/devices/hi_mcu/controls/Relay_1` — топик состояния реле 1 (сообщения `0` или `1`).
`/devices/hi_mcu/controls/Relay_1/on` — топик для управления реле 1 (принимает `0` или `1`).
`/devices/hi_mcu/controls/Input_3` — топик состояния дискретного входа 3.
`/devices/hi_mcu/controls/Input_3/meta/type` — топик для конфигурации входа (например, `switch`, `pushbutton`).

Пример: Управление светом по нажатию кнопки

Задача: Подключить к универсальному входу `UI-5` настенный выключатель (кнопку без фиксации), а к релейному выходу `RL-2` — лампу. Реализовать в Node-RED логику: каждое нажатие кнопки инвертирует состояние лампы (вкл -> выкл, выкл -> вкл). Физическое подключение:

Выключатель подключается к клеммам `UI-5` и `GND`.

Лампа подключается через нормально открытый контакт реле `RL-2`.

Логика в Node-RED:

           +-----------+    +---------------+    +-----------+    +----------+
[mqtt in]--+->[function:     ]--+->[change:   ]----+->[mqtt out]
           |  (UI-5 State) |   (Toggle State)|    (Set RL-2) |    (RL-2/on) |
           +-----------+    +---------------+    +-----------+    +----------+

Настройка MCU:

Сначала необходимо настроить вход `UI-5` на работу в режиме кнопки. Для этого один раз отправляем в MQTT топик `/devices/hi_mcu/controls/Input_5/meta/type` значение `pushbutton`. Это сохраняется в энергонезависимой памяти MCU.

Узел `mqtt in` (Получение сигнала от кнопки):

* Topic: `/devices/hi_mcu/controls/Input_5`

* Output: `a parsed JSON object`

* Этот узел будет получать сообщение `1` каждый раз, когда MCU фиксирует нажатие на кнопку. Важно: MCU сам обрабатывает дребезг контактов и присылает одно чистое событие.

Узел `function` (Логика переключения):

* Name: "Toggle State"

* Код:

    // Получаем текущее состояние реле из контекста потока.
    // Предполагаем, что оно было сохранено ранее.
    let currentState = flow.get("relay_2_state") || 0;

    // Инвертируем состояние
    let newState = (currentState === 0) ? 1 : 0;

    // Сохраняем новое состояние в контекст для следующего нажатия
    flow.set("relay_2_state", newState);

    // Передаем новое состояние дальше
    msg.payload = newState;

    node.status({ text: "New state: " + newState });
    return msg;

Узел `mqtt out` (Отправка команды реле):

* Topic: `/devices/hi_mcu/controls/Relay_2/on`

* `msg.payload` из предыдущего узла (`0` или `1`) будет отправлен в этот топик, и MCU мгновенно изменит состояние реле `RL-2`.

Контракты сообщений:

Сообщение от MCU о нажатии кнопки:

// topic: /devices/hi_mcu/controls/Input_5 // msg.payload: 1

Сообщение от Node-RED для управления реле:

// topic: /devices/hi_mcu/controls/Relay_2/on // msg.payload: 1 // или 0

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

---

Роль Watchdog и реализация «Safe-State»

Самое слабое звено в архитектуре «CPU + MCU» — это основной процессор с его сложной операционной системой. Он может "зависнуть" из-за ошибки в программе, исчерпания оперативной памяти или критического сбоя ядра. Если это произойдет, вся высокоуровневая логика в Node-RED остановится. Как в такой ситуации обеспечить безопасность и базовую функциональность объекта?

Здесь в игру вступает аппаратный Watchdog Timer (сторожевой таймер). Это одна из важнейших функций, реализуемых на уровне MCU.

Принцип работы Watchdog:

Heartbeat ("Сигнал жизни"): На основном CPU запускается специальный системный процесс, который с заданной периодичностью (например, раз в 5 секунд) отправляет по внутреннему каналу в MCU короткое сообщение — "heartbeat". Это сигнал о том, что основной CPU работает штатно.

Ожидание в MCU: Микроконтроллер, в свою очередь, постоянно ожидает этот сигнал. У него запущен внутренний таймер, настроенный на чуть больший интервал (например, 15 секунд).

Срабатывание: Если в течение 15 секунд от основного CPU не приходит ни одного "heartbeat", MCU делает вывод, что основная система "зависла".

Действие: После срабатывания таймера MCU может выполнить одно из двух действий:

* Перезагрузка: Подать сигнал на аппаратный сброс (Reset) основного CPU, принудительно его перезагрузив. Это самый простой способ восстановления.

* Переход в Safe-State: Инициировать выполнение заранее запрограммированной последовательности действий для перевода объекта в безопасное состояние (Safe-State).

Логика "Безопасного Состояния" (Safe-State)

Логика Safe-State — это заранее определенный сценарий, который MCU выполняет автономно, без участия основного CPU. Этот сценарий и его параметры хранятся в энергонезависимой памяти самого микроконтроллера (EEPROM), что гарантирует его сохранность даже при полном отключении питания.

> ⚠️ Внимание: Неправильная настройка watchdog-таймера (слишком короткий интервал) может привести к ложным срабатываниям и циклическим перезагрузкам контроллера при пиковых нагрузках на CPU. Всегда тестируйте логику Safe-State в лабораторных условиях перед внедрением на реальном объекте.

Примеры правил для сценария Safe-State:

Безопасность:

* `IF watchdog_triggered THEN set Relay_5 to 0` (отключить группу розеток в детской).

* `IF watchdog_triggered THEN set Relay_8 to 1` (включить дежурное/аварийное освещение в коридоре).

* `IF watchdog_triggered AND Input_10=1 (датчик протечки) THEN set Relay_12 to 0` (закрыть главный кран подачи воды).

Поддержание жизнеобеспечения:

* `IF watchdog_triggered THEN set AnalogOutput_1 to 5.0` (установить привод клапана отопления в положение 50%, чтобы предотвратить замерзание или перегрев).

* `IF watchdog_triggered THEN set Relay_15 to 0` (отключить систему вентиляции для экономии энергии).

🔗 Связанный материал: Как мы обсуждали в уроке "Роль EEPROM для надёжного хранения", именно использование энергонезависимой памяти внутри MCU позволяет сделать логику Safe-State по-настоящему надежной и независимой от состояния основного CPU и его файловой системы.

---

Резюме: Место ARM32-процессора в иерархии надёжности

Дополнительный ARM32-микроконтроллер не является просто "расширителем портов". Это фундаментальный компонент, который выводит надежность и отказоустойчивость системы автоматизации на качественно новый уровень, приближая ее к стандартам промышленной автоматизации (АСУ ТП).

Ключевые преимущества архитектуры с MCU:

Отказоустойчивость: Благодаря watchdog-таймеру и логике Safe-State, система способна адекватно реагировать на зависание основного ПО, переводя объект в безопасный режим или выполняя автоматическую перезагрузку.
Работа в реальном времени: Критичные ко времени задачи (управление светом, подсчет импульсов) выполняются детерминированно и не зависят от нагрузки на основной CPU.
Разгрузка основного процессора: MCU берет на себя всю рутинную низкоуровневую работу с I/O, освобождая ресурсы CPU для выполнения сложных сценариев, анализа данных и взаимодействия с пользователем.

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

Итоговое сравнение подходов:

| Характеристика | Система на базе одного CPU | Система с архитектурой «CPU + MCU» |

| :--- | :--- | :--- |

| Работа с I/O в реальном времени | Ненадежна, подвержена задержкам ОС. Функции диммирования и счета импульсов нестабильны. | Надежна и детерминирована. Все критичные ко времени задачи выполняются на MCU. |

| Реакция на "зависание" ОС | Система полностью выходит из строя. Требуется внешнее вмешательство (перезагрузка по питанию). | Автоматическое восстановление. MCU обнаруживает сбой через Watchdog и либо перезагружает CPU, либо активирует Safe-State. |

| Нагрузка на CPU от I/O | Высокая. Опрос датчиков и управление выходами потребляет ресурсы, которые могли бы использоваться для логики. | Минимальная. MCU обрабатывает I/O автономно, CPU получает только готовые данные или отправляет высокоуровневые команды. |

| Общий уровень надежности | Зависит исключительно от стабильности ПО и операционной системы. | Значительно выше. Надежность обеспечивается на двух уровнях: программном (Linux) и аппаратном (MCU). |

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

Что дальше

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