Главная → Академия → Основы умного дома → Шаблон 3: Multi-controller (Иерархия)

Шаблон 3: Multi-controller (Иерархия)

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

Введение в шаблон "Multi-controller (Иерархия)"

Шаблон Multi-controller, также известный как иерархическая или Master/Edge архитектура, представляет собой продвинутую модель построения систем автоматизации для крупных и распределенных объектов. В отличие от более простых шаблонов, где все задачи выполняет один контроллер, здесь система строится на взаимодействии двух или более уровней контроллеров, каждый из которых выполняет свою четко определенную роль.

> 🔗 Связанный материал: Для полного понимания эволюции архитектурных решений рекомендуется ознакомиться с уроками, посвященными предыдущим шаблонам: Шаблон 1: Standalone (Автономный контроллер) и Шаблон 2: Edge + MQTT Broker.

Основная идея этого шаблона заключается в децентрализации исполнительной логики и централизации управления и сбора данных. Это достигается за счет введения двух типов контроллеров:

Ключевые предпосылки для применения

Переход к иерархической архитектуре оправдан при наличии одного или нескольких следующих факторов:

  • Большие площади и физическая распределенность: Объект состоит из нескольких зданий, этажей или удаленных друг от друга технологических зон (например, главный дом, гостевой дом, баня). Прокладка всех шин управления в одну точку (к одному контроллеру) становится нецелесообразной или физически невозможной.
  • Высокие требования к надежности: Критически важно, чтобы базовые функции (управление освещением, климатом, безопасностью) на отдельном этаже или в здании продолжали работать даже в случае отказа центрального сервера или потери связи с ним.
  • Масштабируемость: Проект предполагает поэтапное расширение. Иерархическая архитектура позволяет легко добавлять новые подсистемы (например, новый этаж или здание), просто устанавливая дополнительный Edge-контроллер, без необходимости перестраивать всю существующую систему.
  • Большое количество устройств: Когда число конечных точек (датчиков, реле, приводов) превышает несколько сотен, один контроллер может не справиться с нагрузкой по опросу, обработке данных и выполнению сценариев. Распределение этой нагрузки на Edge-контроллеры решает проблему производительности.

    • Сравнение архитектурных шаблонов

    Для лучшего понимания места шаблона "Multi-controller" рассмотрим его эволюцию и отличия от ранее изученных архитектур.

    | Критерий | Шаблон "Standalone" | Шаблон "Edge + MQTT Broker" | Шаблон "Multi-controller (Иерархия)" |

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

    | Структура | Один контроллер делает всё. | Один контроллер + внешний MQTT брокер для связи с приложениями. | Иерархия: один Master-контроллер и множество Edge-контроллеров. |

    | Надежность | Низкая. Отказ контроллера = отказ всей системы. | Низкая/Средняя. Логика по-прежнему в одной точке. | Высокая. Отказ Master не влияет на локальную работу Edge. |

    | Масштабируемость | Низкая. Ограничена ресурсами одного контроллера. | Низкая. Расширение упирается в тот же единственный контроллер. | Высокая. Система растет добавлением новых Edge-контроллеров. |

    | Сложность | Низкая. Простота настройки. | Средняя. Требуется настройка MQTT брокера. | Высокая. Требует проектирования сети и логики взаимодействия. |

    | Применимость | Квартиры, небольшие дома, офисы (до 50-70 устройств). | Объекты, где нужен удаленный доступ и интеграция с моб. приложениями. | Крупные коттеджи, гостиницы, офисные центры, промышленные объекты. |

    Таким образом, шаблон "Multi-controller" является логическим развитием и масштабированием идей, заложенных в более простых архитектурах, и предназначен для решения задач промышленного уровня сложности и надежности.

    ---

    Роль и задачи центрального (Master) контроллера

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

    > 💡 Подсказка: В качестве Master-контроллера выбирайте более производительное решение (например, промышленный ПК или сервер на базе Debian), так как на него ложится нагрузка по сбору, обработке и хранению данных со всего объекта. Платформа с 4 ядрами CPU и 4 ГБ RAM является хорошей отправной точкой, но для крупных объектов (сотни Edge-устройств) может потребоваться более мощный сервер.

    Рассмотрим ключевые функции, которые реализуются на Master-контроллере.

    Централизация глобальной логики

    Если сценарий автоматизации затрагивает несколько зон ответственности, которые управляются разными Edge-контроллерами, его логика должна быть реализована на Master-уровне.

    Агрегация и хранение данных

    Edge-контроллеры собирают огромные объемы сырых данных. Отправлять их все в облако или хранить локально на каждом устройстве неэффективно. Master-контроллер выступает в роли центрального хранилища и агрегатора.

  • Сбор телеметрии: Он подписывается на MQTT-топики всех Edge-контроллеров и получает от них обработанную информацию (например, среднюю температуру за минуту, а не показания каждые 2 секунды).
  • Долгосрочное хранение: Данные складываются в локальную базу данных (например, MySQL, установленную на том же сервере, что и Master). Это позволяет строить исторические графики потребления ресурсов (электричество, вода, тепло), анализировать работу оборудования и выявлять аномалии.
  • Централизованное логирование: Все важные события (срабатывание датчиков, выполнение команд) и ошибки со всех Edge-контроллеров стекаются на Master и записываются в единый аудит-журнал (audit log). Это критически упрощает диагностику проблем.

    • Верхнеуровневый интерфейс

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

    Безопасность и удаленный доступ

    Предоставлять удаленный доступ к каждому Edge-контроллеру по отдельности — это не только неудобно, но и небезопасно. Master-контроллер становится единственным "шлюзом" для доступа в систему извне.

    ---

    Edge-контроллеры: локальная логика и отказоустойчивость

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

    Обеспечение автономности

    Главный принцип проектирования систем на базе шаблона "Multi-controller" — Edge-контроллер должен на 100% выполнять свои локальные функции даже при полном отсутствии связи с Master-контроллером.

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

    Эта автономность достигается благодаря тому, что Edge-контроллер, как и в `Standalone` шаблоне, обладает всеми необходимыми интерфейсами и вычислительной мощностью для локальных задач.

    Локальная обработка протоколов

    Edge-контроллеры выступают в роли шлюзов между низкоуровневыми промышленными протоколами и общесистемной шиной данных на базе MQTT.

    Протокол связи с "центром"

    Стандартом де-факто для связи между Edge и Master-контроллерами является протокол MQTT. Он идеально подходит для этой задачи по нескольким причинам:

    Снижение нагрузки на сеть

    Edge-контроллер выполняет предварительную обработку и фильтрацию данных перед отправкой на Master-уровень. Это значительно снижает трафик и нагрузку на центральный сервер.

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

    ---

    Практика: Настройка связи между контроллерами по MQTT

    Рассмотрим практический пример настройки двусторонней связи между Edge-контроллером (на базе нашей платформы) и Master-контроллером.

    Задача: Edge-контроллер, установленный на первом этаже, опрашивает по Modbus RTU датчик температуры и влажности. Он должен публиковать эти данные в MQTT. Master-контроллер подписывается на эти данные и может отправить команду на тот же Edge-контроллер, чтобы включить реле №5 (например, для управления увлажнителем).

    > ⚠️ Внимание: Неправильно спроектированная структура топиков или логика публикации может привести к "MQTT-шторму" — лавинообразному росту сообщений, парализующему сеть. Всегда используйте фильтрацию и публикуйте данные по изменению (RBE), а не по слепому интервалу.

    1. Проектирование иерархической структуры топиков

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

    `проект/местоположение/устройство/параметр`

    * `myhome/floor1/climate/temperature`

    * `myhome/floor1/climate/humidity`

    * `myhome/floor1/relays/relay5/state` (будет публиковать `ON` или `OFF`) * `myhome/floor1/relays/relay5/set` (сюда Master будет отправлять команды `ON` или `OFF`)

    2. Поток на Edge-контроллере (Отправка телеметрии и обработка команд)

    На контроллере первого этажа создаем поток, который выполняет две задачи:

    a) Читает Modbus-датчик и отправляет данные в MQTT.

    b) Подписывается на топик команд и управляет реле.

    ASCII-схема потока: 
    // === Часть A: Отправка телеметрии ===

    [Inject: 30s] -> [Modbus-Getter] -> [Function: Format] -> [RBE] -> [mqtt out]
    

                                                                            ^
    

    // === Часть B: Прием команд ===                                        |
    

    [mqtt in] -> [Switch: ON/OFF] -> [Function: Control Relay] -> [Relay Out] -> [Function: State to MQTT]
    Код узла `Function: Format` (Часть А): 
    // Входящий msg от modbus-getter: msg.payload = [255, 451] (температура10, влажность10)

    let temp = msg.payload[0] / 10.0;
    

    let humidity = msg.payload[1] / 10.0;
    


    // Создаем два сообщения для отправки в разные топики
    

    let msg_temp = {
    

        topic: "myhome/floor1/climate/temperature",
    

        payload: {
    

            value: temp,
    

            unit: "°C",
    

            source: "modbus-sensor-th-01",
    

            ts: Date.now()
    

        }
    

    };
    


    let msg_hum = {
    

        topic: "myhome/floor1/climate/humidity",
    

        payload: {
    

            value: humidity,
    

            unit: "%",
    

            source: "modbus-sensor-th-01",
    

            ts: Date.now()
    

        }
    

    };
    


    // node.send() может принимать массив сообщений
    

    // Каждое сообщение будет обработано узлом RBE и отправлено в MQTT независимо
    

    // Важно: узел RBE будет работать корректно, т.к. он отслеживает сообщения по msg.topic
    

    return [[msg_temp, msg_hum]];
    Настройка узлов (Часть B):
  • `mqtt in`:

    • * `Topic`: `myhome/floor1/relays/relay5/set`

    * `Broker`: ваш центральный MQTT-брокер

  • `Function: State to MQTT`:

    • * Этот узел получает на вход состояние после срабатывания реле (например `true`) и формирует сообщение для обратной связи.

    * Код:

            let state = msg.payload ? "ON" : "OFF";
    

            msg.topic = "myhome/floor1/relays/relay5/state";
    

            msg.payload = state;
    

            // Включаем флаг retain, чтобы Master сразу получил состояние
    

            msg.retain = true; 
    

            return msg;

    3. Поток на Master-контроллере (Прием данных и отправка команд)

    На центральном контроллере поток еще проще. Он подписывается на данные и предоставляет элементы для ручного управления.

    ASCII-схема потока: 
    // === Прием и отображение данных ===

    [mqtt in] -> [Switch by topic] --+--> [Dashboard: Gauge Temp]
    

              (myhome/floor1/#)     +--> [Dashboard: Gauge Hum]
    

                                    +--> [Dashboard: Light State]
    


    // === Отправка ручной команды ===
    

    [Dashboard: Button] -> [Change: set Topic] -> [mqtt out]
    Настройка узлов:
  • `mqtt in`:

    • * `Topic`: `myhome/floor1/#`. Символ `#` является wildcard и означает "подписаться на все топики, начинающиеся с `myhome/floor1/`". Это позволяет одним узлом получать и температуру, и влажность, и состояние реле.

    * `Broker`: тот же центральный MQTT-брокер.

  • `Switch by topic`:

    • * Этот узел используется для маршрутизации сообщений в зависимости от `msg.topic` на соответствующие элементы дашборда.

    * `Property`: `msg.topic`

    * Правило 1: `ends with` `temperature` -> выход 1

    * Правило 2: `ends with` `humidity` -> выход 2

    * Правило 3: `ends with` `relay5/state` -> выход 3

  • `Dashboard: Button` + `Change`:

    • * Кнопка на дашборде будет отправлять `ON` или `OFF`.

    * Узел `Change` устанавливает `msg.topic` в `myhome/floor1/relays/relay5/set` перед отправкой в узел `mqtt out`.

    4. Использование флага 'retain' для синхронизации

    Обратите внимание на строку `msg.retain = true;` в коде на Edge-контроллере. Что она делает?

    Когда Edge-контроллер публикует состояние реле (`ON` или `OFF`) с флагом retain, MQTT-брокер не просто рассылает это сообщение всем текущим подписчикам, но и сохраняет его у себя.

    Если Master-контроллер был перезагружен или временно терял связь, то в момент, когда он заново подпишется на топик `myhome/floor1/relays/relay5/state`, брокер немедленно отправит ему последнее сохраненное (`retained`) сообщение. Благодаря этому Master-интерфейс всегда будет отображать актуальное состояние реле, а не ждать, пока оно изменится в следующий раз. Это критически важный механизм для построения надежных пользовательских интерфейсов.

    ---

    Резюме и критерии выбора шаблона

    Мы рассмотрели иерархический шаблон "Multi-controller", который является мощным инструментом для создания больших, надежных и масштабируемых систем автоматизации. Его суть — в разделении обязанностей между центральным "мозгом" (Master) и автономными исполнителями "на местах" (Edge).

    Ключевые преимущества и недостатки

    * Высокая отказоустойчивость: Локальные подсистемы продолжают работать автономно при отказе центра.

    * Отличная масштабируемость: Систему можно неограниченно расширять, добавляя новые Edge-контроллеры, без изменения существующей архитектуры.

    * Четкое разделение логики: Упрощается разработка и отладка. Локальные проблемы решаются на уровне Edge, глобальные — на уровне Master.

    * Оптимизация сетевого трафика: Наверх передаются только агрегированные и значимые данные.

    * Повышенная сложность: Требуется тщательное проектирование сетевой инфраструктуры, структуры MQTT-топиков и логики взаимодействия контроллеров.

    * Более высокая стоимость внедрения: Необходимо закупать несколько контроллеров вместо одного.

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

    Чек-лист для принятия решения

    Когда вашему проекту действительно нужен шаблон "Multi-controller"? Ответьте на эти вопросы:

  • [ ] Физические размеры: Объект состоит из нескольких зданий, этажей или отдельно стоящих сооружений (например, дом + гараж + баня)?
  • [ ] Количество устройств: Общее число конечных точек (реле, датчиков, диммеров) превышает 100-150?
  • [ ] Требования к надежности: Существуют ли подсистемы (например, климат-контроль этажа, управление котельной), которые должны работать на 100% автономно, независимо от состояния центрального сервера?
  • [ ] Планы по расширению: Предполагается ли в будущем значительное расширение системы (добавление новых помещений, функций)?
  • [ ] Разнообразие протоколов: На объекте присутствует большое количество устройств, работающих по разным физическим протоколам (Modbus, DALI, KNX, CAN), которые нужно "собрать" в единую систему?

    • Если вы ответили "Да" на два или более вопроса, иерархическая архитектура — ваш наиболее вероятный и правильный выбор.

    Что дальше?

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