Платформы для IoT: от облака до контроллера

Урок 3 · COURSE-16: Основы Интернета Вещей и практическое применение · theory

COURSE-16-M03-L04 — Платформы для IoT: от облака до контроллера

Введение: Что такое IoT-платформа и её роль в системе

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

В экосистеме HI мы рассматриваем два основных типа платформ, которые часто работают совместно:

Edge-платформа (локальная): Это наш контроллер HI. Он выполняет сбор данных и управление в реальном времени непосредственно на объекте. Его ключевая задача — обеспечить автономность, низкую задержку и надёжность критически важных функций, даже при отсутствии связи с интернетом.

Cloud-платформа (облачная): Это глобальные сервисы, такие как AWS IoT, Microsoft Azure IoT или ThingsBoard. Их задача — агрегировать данные с сотен и тысяч объектов, обеспечивать долгосрочное хранение, сложную аналитику и предоставлять глобальный интерфейс для управления и мониторинга.

В этом уроке мы разберем ключевые функции IoT-платформ и на практике покажем, как контроллер HI реализует их на локальном уровне и как он интегрируется с облачными сервисами.

Ключевые функции IoT-платформы на примере контроллера HI

Рассмотрим основные компоненты любой IoT-платформы и как они реализованы в стеке технологий контроллера HI (Debian, Node-RED, MQTT, Modbus).

1. Подключение и управление устройствами (Device Connectivity & Management)

Это базовый уровень, отвечающий за "общение" с физическим миром.

Облачные платформы: Предоставляют MQTT-брокеры или HTTP API для приёма данных от устройств, способных выходить в интернет.
Реализация на контроллере HI:

* Проводные протоколы: Node-RED с помощью специализированных узлов (палитр) напрямую работает с промышленными и локальными шинами:

* `node-red-contrib-modbus`: для опроса счётчиков, датчиков и релейных модулей по шине RS-485.

* `node-red-contrib-dali`: для управления освещением по шине DALI.

* `node-red-contrib-canbus`: для взаимодействия с автомобильным или промышленным оборудованием по шине CAN.

* Встроенные I/O: Узлы `node-red-contrib-rpi-gpio` позволяют напрямую читать состояние универсальных входов (сухие контакты, датчики протечки) и управлять релейными выходами.

* Беспроводные протоколы: Через USB-модемы или встроенные модули контроллер может выступать шлюзом для Zigbee, Z-Wave или LoRaWAN.

* MQTT: Контроллер HI может одновременно быть клиентом облачного MQTT-брокера и содержать собственный локальный брокер (например, Mosquitto) для связи устройств внутри объекта.

💡 Совет: Всегда начинайте проектирование с локальных протоколов (Modbus, 1-Wire). Это обеспечивает максимальную надежность. MQTT используется как транспортный уровень для передачи уже собранных и обработанных данных.

2. Сбор, обработка и хранение данных (Data Ingestion, Processing & Storage)

Сырые данные с датчиков редко бывают полезны. Их нужно обработать, отфильтровать и сохранить.

Облачные платформы: Предлагают сервисы для обработки потоковых данных (AWS Kinesis, Azure Stream Analytics) и различные базы данных (NoSQL, Time-Series DB).
Реализация на контроллере HI:

* Обработка: Node-RED является мощнейшим инструментом для обработки данных "на лету". С помощью узлов `Function`, `Switch`, `Change` вы можете:

* Валидировать данные (например, отбрасывать нереалистичные показания температуры).

* Преобразовывать форматы (например, из сырого значения Modbus-регистра в градусы Цельсия).

* Обогащать данные (добавлять метки времени, ID источника, метаданные).

* Хранение: Контроллер HI оснащен локальной базой данных MySQL, доступной для Node-RED через палитру `node-red-node-mysql`. Это позволяет:

* Создавать журнал аудита (audit log): записывать все важные события и команды.

* Хранить исторические данные датчиков для построения локальных графиков.

* Сохранять состояние системы (например, уставки термостатов), чтобы восстановить их после перезагрузки.

* Надёжное хранение: Критически важные сценарии и уставки могут быть сохранены в EEPROM контроллера, что гарантирует их целостность даже при полном отказе основного накопителя.

3. Разработка и исполнение логики (Logic & Application Enablement)

Это "мозг" системы, который принимает решения на основе полученных данных.

Облачные платформы: Предоставляют бессерверные функции (AWS Lambda, Azure Functions) для написания кода логики.
Реализация на контроллере HI:

* Node-RED: Основной инструмент для создания сценариев автоматизации любой сложности — от простого "включить свет по датчику движения" до сложных алгоритмов управления климатом с использованием паттерна "Конечный автомат" (FSM).

* Функция ПЛК: Для задач, требующих детерминированного времени выполнения и гарантированного перехода в безопасное состояние (safe-state) при сбое, используется выделенный сопроцессор ARM32. Логика для него разрабатывается в специализированной среде и обеспечивает высочайший уровень надежности для критических процессов (например, управление котлом или системой антипротечки).

4. Безопасность (Security)

Защита данных и устройств от несанкционированного доступа.

Облачные платформы: Управляют сертификатами, аутентификацией, авторизацией на уровне облака.
Реализация на контроллере HI:

* Сетевая безопасность: Контроллер работает под управлением Debian Linux, что позволяет использовать стандартные инструменты защиты: файрвол (`iptables`), разделение сетевых интерфейсов, VPN-клиенты (OpenVPN, WireGuard) для безопасного удаленного доступа.

* Безопасность MQTT: При использовании локального или облачного брокера обязательно настраивать TLS-шифрование и Access Control Lists (ACL), чтобы устройство "датчик температуры" могло только публиковать данные в свой топик и не могло слушать команды для управления реле.

* Физическая безопасность: Контроллер является физическим устройством, установленным в электрощите на объекте, что само по себе является барьером для атак извне.

Архитектура IoT-решения: Облако vs. Edge (On-Premise)

Выбор архитектуры — одно из ключевых решений инженера. Контроллер HI может работать в любой из этих парадигм или совмещать их.

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

| Надежность | Высокая. Система полностью автономна. Критическая логика (свет, климат, безопасность) работает без интернета. | Низкая. При потере связи с интернетом объект становится "неуправляемым". | Очень высокая. Критическая логика работает локально, а облако используется для мониторинга и некритичного управления. |

| Задержка (Latency) | Минимальная (<100 мс). Реакция на события (нажатие кнопки) мгновенная. | Высокая (500 мс - 5 с). Зависит от качества интернет-канала и удаленности серверов. | Минимальная для локальных сценариев, высокая для команд из облака. |

| Стоимость | Низкие операционные расходы (нет абонентской платы за облако). | Высокие операционные расходы (оплата за трафик, хранение, вычисления). | Умеренные расходы. Трафик в облако можно оптимизировать, отправляя только агрегированные данные. |

| Масштабируемость | Ограничена ресурсами контроллера. Идеально для одного объекта. | Практически неограниченная. Подходит для управления тысячами объектов. | Лучшее из двух миров. Масштабируется на уровне объектов, данные с которых централизуются в облаке. |

| Типовая задача | Умный дом, офис, небольшой отель. Управление в реальном времени. | Мониторинг автопарка, сбор телеметрии с тысяч счетчиков. | Сеть магазинов, где каждый магазин автономен, а центральный офис видит общую аналитику. |

⚠️ Предупреждение: Никогда не проектируйте систему, в которой базовые функции (например, включение света с настенного выключателя) зависят от наличия интернет-соединения. Это грубейшая архитектурная ошибка.

Практический пример: Интеграция локального датчика с облачной платформой

Задача: Считывать показания с локального датчика температуры, подключенного к контроллеру HI по шине Modbus RS-485, и отправлять их в облако через протокол MQTT. 1. Схема подключения (ID: WIRING-SENS-MODBUS-001)

//========= WIRING-SENS-MODBUS-001: Temperature Sensor Connection =========
// Используется кабель "витая пара" UTP Cat5e

[CTRL:HI-Core]                (SENS:Temp:Room-01)
  (RS485-1)
    A   ---(Зеленый)--- A
    B   ---(Белый)---- B
   GND  ---(Черный)---- GND

2. Поток Node-RED (ID: FLOW-INTEG-MQTT-008)

           +-----------------+    +-----------------+    +---------------------------+    +--------------------+
[Inject] -> | Modbus-Getter   | -> | Function:       | -> | Switch: Check if valid    | -> | mqtt out           |
(every 30s)| (Read Temp Reg) |    | Validate/Format |    | (msg.payload !== null)    |    | (to cloud broker)  |
           +-----------------+    +-----------------+    +---------------------------+    +--------------------+
                   | (on error)            | (on error)
                   v                       v
           +-----------------+    +--------------------------+
           | Catch           | -> | Function: Format Error   | -> [To Audit Log (MySQL)]
           +-----------------+    +--------------------------+

3. Контракт сообщения (Message Contract)

Все данные, отправляемые в облако, должны соответствовать единому формату JSON. Это упрощает их дальнейшую обработку.

{
  "value": 23.5,
  "unit": "C",
  "source": "modbus-sensor-room1-temp",
  "ts": 1678886400000,
  "meta": {
    "objectId": "Office-Building-A",
    "location": "Floor 2, Room 201"
  }
}

4. Код узла `Function: Validate/Format`

Этот узел — сердце логики. Он преобразует сырые данные от Modbus в стандартизированное сообщение.

// Вход: msg.payload от узла Modbus-Getter, например: { data: [235], buffer: <...> }
// Предполагаем, что датчик отдает температуру, умноженную на 10.

// 1. Извлечение и валидация данных
let rawValue = msg.payload.data[0];
if (rawValue === undefined || rawValue < -500 || rawValue > 1200) { // Диапазон от -50.0 до 120.0 C
    node.status({fill:"red", shape:"dot", text:"Invalid data: " + rawValue});
    node.error("Некорректное значение от датчика Modbus", msg);
    return null; // Останавливаем поток для этого сообщения
}

// 2. Преобразование в физическую величину
let temperature = rawValue / 10.0;

// 3. Формирование сообщения по контракту
msg.payload = {
    value: temperature,
    unit: "C",
    source: "modbus-sensor-room1-temp", // Уникальный ID источника
    ts: Date.now(),
    meta: {
        objectId: "Office-Building-A",
        location: "Floor 2, Room 201"
    }
};

// 4. Установка топика для отправки в облако
msg.topic = "telemetry/Office-A/F2/R201/temperature";

// 5. Обновление визуального статуса узла
node.status({fill:"green", shape:"dot", text:"OK: " + temperature + " °C"});

return msg;

---

Лабораторные работы

COURSE-16-M03-LAB01: Локальный мониторинг через Dashboard

Цель: Научиться считывать данные с входа контроллера и отображать их на локальной панели мониторинга (Node-RED Dashboard).
Задание:

1. Создайте поток, который каждые 5 секунд считывает состояние одного из универсальных входов (UI), настроенного как "сухой контакт". Для симуляции можно использовать кнопку на макете или просто замыкать вход на GND.

2. Используя узел `Switch`, определите, замкнут контакт (`0`) или разомкнут (`1`).

3. Выведите на панель Node-RED Dashboard (узел `ui_text`) текстовое сообщение: "Дверь открыта" или "Дверь закрыта".

4. Добавьте узел `ui_led`, который будет гореть зеленым, если дверь закрыта, и красным, если открыта.

Рубрика оценивания:

* (3 балла) Поток корректно считывает состояние входа.

* (3 балла) Текстовый статус на Dashboard меняется в соответствии с состоянием входа.

* (4 балла) Цвет светодиода на Dashboard меняется корректно.

COURSE-16-M03-LAB02: Управление реле через облачный MQTT

Цель: Реализовать сценарий удаленного управления исполнительным устройством через облачную платформу.
Задание:

1. Настройте узел `mqtt in` для подписки на топик `commands/myhome/livingroom/light/set`. Используйте публичный MQTT-брокер (например, `broker.hivemq.com`).

2. Входящие сообщения могут быть строками `"ON"` или `"OFF"`. С помощью узла `Switch` разделите поток на две ветки.

3. В зависимости от команды, управляйте одним из релейных выходов контроллера (`rpi gpio out`), включая или выключая его.

4. После успешного выполнения команды отправьте сообщение о текущем состоянии (`"ON"` или `"OFF"`) в топик `status/myhome/livingroom/light` с помощью узла `mqtt out`.

5. Используйте любой MQTT-клиент (например, MQTT Explorer) для отправки команд и проверки статуса.

Рубрика оценивания:

* (3 балла) Поток успешно подписывается на топик и принимает команды.

* (4 балла) Реле корректно включается и выключается по командам `"ON"` и `"OFF"`.

* (3 балла) После выполнения команды в топик статуса отправляется корректное ответное сообщение.

Тест для самопроверки (COURSE-16-M03-QUIZ)

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

* a) Cloud-архитектура

* b) Edge-архитектура

* c) Гибридная, но с основной логикой в облаке

Какой узел Node-RED используется для взаимодействия с устройствами по шине RS-485?

* a) `mqtt in`

* b) `rpi gpio in`

* c) `modbus-getter`

Что такое "контракт сообщения"?

* a) Юридический документ между заказчиком и исполнителем.

* b) Стандартизированный формат данных (например, JSON), используемый для обмена между узлами.

* c) Настройки MQTT-брокера.

Для чего в контроллере HI используется локальная база данных MySQL?

* a) Только для хранения прошивки контроллера.

* b) Для ведения журнала аудита, хранения истории показаний и состояний системы.

* c) Для кэширования веб-страниц.

В гибридной архитектуре (контроллер HI + облако) за что отвечает контроллер?

* a) Только за отображение графиков.

* b) За выполнение критически важной логики в реальном времени и первичный сбор данных.

* c) Только за отправку данных в облако.

(Да/Нет) Можно ли использовать узел `Catch` для перехвата ошибок связи с Modbus-устройством?

Какую информацию должен содержать `msg.payload` согласно рекомендованному контракту сообщения?

* a) Только числовое значение.

* b) Объект JSON, включающий `value`, `source`, `ts` и опционально `unit`.

* c) Строку с HTML-кодом.

Что произойдет с системой, построенной на Edge-архитектуре, при отключении интернета?

* a) Система полностью перестанет работать.

* b) Продолжит работать в штатном режиме, но потеряет связь с облаком.

* c) Перезагрузится.

Какой узел Node-RED используется для отправки данных в облачную IoT-платформу?

* a) `http request`

* b) `mqtt out`

* c) `tcp out`

Зачем нужен визуальный статус узла (`node.status`)?

* a) Для быстрой диагностики состояния узла без использования `Debug`.

* b) Для изменения цвета интерфейса Node-RED.

* c) Для отправки SMS-сообщений.

(Ответы: 1-b, 2-c, 3-b, 4-b, 5-b, 6-Да, 7-b, 8-b, 9-b, 10-a)

Мини-Runbook: "Если не работает..."

📋 Чек-лист быстрой диагностики при интеграции с платформой:

Данные не приходят от локального устройства (Modbus, 1-Wire):

* Физика: Проверьте схему подключения (`WIRING-XXX`). Не перепутаны ли линии A/B для RS-485? Есть ли питание на датчике?

* Конфигурация: В узле Node-RED (например, `Modbus-Getter`) проверьте Slave ID, адрес регистра, скорость порта. Совпадают ли они с настройками устройства?

* Статус: Посмотрите на визуальный статус узла в Node-RED. Он показывает ошибку "Timeout" или "CRC error"?

Данные не отправляются в облако (MQTT):

* Связь: Проверьте, есть ли у контроллера доступ в интернет (`ping 8.8.8.8`).

* Конфигурация MQTT: В узле `mqtt out` проверьте адрес брокера, порт, логин/пароль и использование TLS. Узел показывает статус "connected"?

* Топик и Payload: Убедитесь, что `msg.topic` не пустой, а `msg.payload` имеет корректный формат (не `undefined` или `null`). Используйте узел `Debug` перед узлом `mqtt out`.

Команды из облака не исполняются:

* Подписка: Узел `mqtt in` показывает статус "connected"? Правильно ли указан топик для подписки (проверьте на опечатки, включая `wildcards` #/+)?

* Формат команды: Используйте узел `Debug` сразу после `mqtt in`. Какой `payload` приходит? Соответствует ли он тому, что ожидает ваша логика (например, строка `"ON"`, а не JSON `{"command":"ON"}`)?

* Логика: Проверьте работу узла `Switch`. Корректно ли он обрабатывает входящие значения?