Введение в облачные технологии для IoT-систем
COURSE-16-M03-L03 — Введение в облачные технологии для IoT-систем
Роль облачных технологий в системах автоматизации
Облачные технологии — это модель предоставления вычислительных ресурсов (серверов, баз данных, программного обеспечения) через интернет по запросу. В контексте систем автоматизации на платформе HI, облако не заменяет контроллер, а расширяет его возможности.
Контроллер HI является граничным устройством (Edge Device). Он выполняет критически важные задачи локально:
- Обеспечивает детерминированную логику (функция ПЛК).
- Выполняет сценарии автоматизации в Node-RED.
- Напрямую взаимодействует с датчиками и исполнительными устройствами (Modbus, DALI, 1-Wire).
Облако, в свою очередь, используется для решения задач верхнего уровня:
- Централизованный сбор и долгосрочное хранение данных с десятков и сотен контроллеров.
- Удаленный мониторинг и управление объектами из единого интерфейса.
- Сложная аналитика и машинное обучение на основе больших данных.
- Предоставление доступа к данным для мобильных приложений и сторонних сервисов.
💡 Ключевая идея: Контроллер HI обеспечивает надежность и автономность на объекте, а облако — глобальную доступность и масштабируемость.
Модели облачных сервисов с точки зрения инженера HI
Для инженера автоматизации важно понимать, какой уровень ответственности предполагает та или иная модель облачного сервиса.
IaaS (Infrastructure as a Service — Инфраструктура как услуга)
Вы арендуете "голое железо": виртуальные серверы (VM), дисковое пространство, сетевые ресурсы.
- Что делаете вы: Устанавливаете операционную систему (например, Debian, как на контроллере), настраиваете сеть, устанавливаете и администрируете необходимое ПО (например, MQTT-брокер Mosquitto, базу данных MySQL или InfluxDB, саму Node-RED).
- Примеры провайдеров: Yandex Cloud (Compute Cloud), Amazon EC2, Microsoft Azure VMs.
- Когда использовать: Для крупных проектов, где требуется полный контроль над средой, кастомная конфигурация или развертывание специфического ПО. Требует глубоких навыков системного администрирования.
PaaS (Platform as a Service — Платформа как услуга)
Вы получаете готовую к использованию платформу, например, управляемую базу данных или готовый IoT-сервис.
- Что делаете вы: Используете сервис по его прямому назначению, не заботясь об операционной системе, обновлениях и обслуживании серверов. Вы просто получаете адрес, логин и пароль для подключения.
- Примеры для инженера HI:
* Управляемая база данных: Yandex Managed Service for PostgreSQL/MySQL.
* IoT-платформы: Yandex IoT Core, Azure IoT Hub.
- Когда использовать: В 90% проектов. Это идеальный баланс между гибкостью и простотой. Вы фокусируетесь на логике автоматизации, а не на администрировании серверов.
SaaS (Software as a Service — Программное обеспечение как услуга)
Вы получаете полностью готовый к использованию продукт, доступный через веб-интерфейс или API.
- Что делаете вы: Регистрируетесь, настраиваете дашборды, добавляете пользователей. Взаимодействие с контроллером HI сводится к отправке данных в определенном формате на заданный API-endpoint.
- Примеры для инженера HI: Grafana Cloud (для визуализации), ThingsBoard Cloud (комплексная IoT-платформа с дашбордами), облачные системы управления гостиницами (PMS).
- Когда использовать: Когда требуется быстрое развертывание типового решения с готовым пользовательским интерфейсом.
Типы облаков: выбор для вашего объекта
- Публичное облако (Public Cloud): Ресурсы провайдера (Yandex, AWS) используются множеством клиентов. Это стандартный выбор для большинства коммерческих проектов (умные дома, офисы, гостиницы).
- Приватное облако (Private Cloud): Инфраструктура развернута эксклюзивно для одной организации. Это может быть собственный серверный шкаф на объекте заказчика или выделенные мощности у провайдера. Используется для объектов с повышенными требованиями к безопасности (банки, промышленные предприятия, госучреждения). Контроллер HI подключается к такому облаку через VPN.
- Гибридное облако (Hybrid Cloud): Это наиболее распространенная и надежная модель для систем на базе HI.
* В облако отправляется: Телеметрия для анализа (температура, влажность, потребление энергии), события для уведомлений, данные для удаленного управления некритичными функциями.
⚠️ Золотое правило инженера HI: Система должна сохранять базовую функциональность (свет, безопасность, климат) даже при полном отсутствии интернет-соединения. Облако — это расширение, а не фундамент.
Практика: подключение контроллера HI к облаку через MQTT
MQTT — это легковесный протокол обмена сообщениями, ставший стандартом для IoT. Он идеально подходит для отправки данных с контроллера в облако.
Задача: Отправлять показания датчика температуры в облачную PaaS-платформу (например, HiveMQ Cloud). Архитектура:`[Датчик 1-Wire] -> [Контроллер HI (Node-RED)] --(MQTT через TCP/IP)--> [Интернет] --(TLS)--> [Облачный MQTT-брокер]`
Flow Diagram (ASCII): +---------------------+ +--------------------------+ +----------------------+
[Inject] -> | ds18b20 (1-Wire In) | -> | Function: Validate/Format| -> | mqtt out |
+---------------------+ +--------------------------+ +----------------------+
| | (status)
| (on error) v
v +----------------+
+---------------------+ | Status Node |
| Catch Node | -> [To Error Logger] +----------------+
+---------------------+
Шаг 1: Настройка узла `mqtt out`
* `Server`: Адрес брокера (например, `abcdef123.s1.eu.hivemq.cloud`).
* `Port`: Порт, который поддерживает TLS (обычно `8883`).
* `Enable secure (TLS) connection`: Обязательно включить! Создайте новую конфигурацию TLS, оставив поля пустыми (если не используются клиентские сертификаты).
* `Username`: Ваш логин от MQTT-брокера.
* `Password`: Ваш пароль.
Используйте узел `Function` перед узлом `mqtt out` для приведения данных к стандартному формату.
// Входящее сообщение от узла датчика: msg.payload = 24.7
let temp = parseFloat(msg.payload);
// 1. Валидация
if (isNaN(temp) || temp < -55 || temp > 125) {
node.status({fill:"red", shape:"dot", text:"Invalid reading"});
node.error("Некорректное значение температуры: " + msg.payload, msg);
return null; // Останавливаем поток
}
// 2. Формирование топика для маршрутизации в облаке
// Формат: project/object/controller_id/data_type
msg.topic = "myhome/livingroom/ctrl01/temperature";
// 3. Формирование полезной нагрузки (payload) по контракту
// Это гарантирует, что облачная платформа получит структурированные данные
msg.payload = {
"value": temp,
"source": "28-01234567abcd", // Уникальный ID датчика 1-Wire
"ts": Date.now(), // Временная метка в миллисекундах
"unit": "°C"
};
// 4. Преобразование объекта JSON в строку для отправки
msg.payload = JSON.stringify(msg.payload);
node.status({fill:"green", shape:"dot", text:"OK: " + temp + " °C"});
return msg;
Шаг 3: Обработка ошибок и мониторинг статуса
- Узел `Catch`: Добавьте на холст узел `Catch` и соедините его с узлом `Debug` или с вашим централизованным потоком логирования ошибок. Он поймает ошибку, если, например, узел `Function` получит некорректные данные.
- Узел `Status`: Добавьте узел `Status` и настройте его на отслеживание состояния узла `mqtt out`. Соедините его с узлом `Debug`. Вы будете видеть статусы: `connecting`, `connected`, `disconnected`.
💡 Практический сценарий: Если узел `Status` сообщает о `disconnected`, можно запустить сценарий, который временно сохраняет данные в локальную базу MySQL на контроллере, чтобы отправить их позже, когда соединение восстановится.
Безопасность при работе с облаком
Безопасность — это не опция, а требование.
- Шифрование канала: Всегда используйте TLS для подключения к облачным сервисам (например, порт `8883` для MQTT). Это защищает данные от перехвата в интернете.
- Аутентификация: Каждый контроллер должен иметь уникальные логин и пароль для доступа к облаку. Не используйте одни и те же учетные данные на всех объектах.
- Авторизация (ACL): Настройте на стороне MQTT-брокера списки контроля доступа (Access Control Lists). Контроллер `ctrl01` должен иметь право публиковать данные только в свой топик (`myhome/livingroom/ctrl01/#`) и не должен иметь возможности читать данные других контроллеров.
- Минимизация поверхности атаки: Отправляйте в облако только те данные, которые там действительно нужны. Не передавайте служебную информацию или отладочные сообщения.
---
Лабораторные работы
COURSE-16-M03-LAB05: Подключение к публичному MQTT-брокеру
Цель: Научиться настраивать MQTT-соединение в Node-RED и отправлять тестовые данные. Оборудование: Контроллер HI, доступ в интернет. Задание:- (3 балла) Соединение с брокером установлено и стабильно.
- (4 балла) Сообщения приходят в правильный топик и соответствуют JSON-контракту.
- (3 балла) В потоке присутствует узел `Status`, отслеживающий состояние `mqtt out` узла.
COURSE-16-M03-LAB06: Отправка реальных данных с локальной обработкой ошибок
Цель: Создать отказоустойчивый поток для отправки данных с физического датчика в облако. Оборудование: Контроллер HI, датчик температуры DS18B20, доступ в интернет. Задание:- (3 балла) Данные с реального датчика корректно считываются и отправляются в облако.
- (4 балла) При имитации обрыва связи (например, отключение интернет-кабеля) поток не генерирует ошибок, а сообщения перенаправляются на локальную обработку.
- (3 балла) В потоке используется узел `Catch` для перехвата возможных ошибок чтения датчика.
---
Тест для самопроверки (COURSE-16-M03-QUIZ)
a) SaaS
b) PaaS
c) IaaS
d) FaaS
a) SaaS
b) PaaS
c) IaaS
d) On-Premise
a) Использование двух облачных провайдеров одновременно.
b) Выполнение критичной логики на контроллере, а отправка телеметрии в публичное облако.
c) Хранение данных частично на SD-карте, частично в EEPROM.
d) Использование и Wi-Fi, и GSM для подключения к облаку.
a) Modbus TCP
b) HTTP
c) MQTT
d) CAN
a) 1883 без шифрования.
b) 8883 с TLS-шифрованием.
c) 502.
d) 80.
a) Скорость интернет-соединения.
b) Стандартная структура и формат данных (JSON) в `msg.payload`.
c) Физический способ подключения контроллера.
d) Юридический договор с облачным провайдером.
a) Все сценарии перестанут работать.
b) Контроллер перезагрузится.
c) Критически важные локальные сценарии продолжат работать автономно.
d) Данные за последний час будут безвозвратно утеряны.
a) Чтобы измерять скорость отправки сообщений.
b) Чтобы менять топик на лету.
c) Чтобы отслеживать состояние соединения (connected/disconnected) и реагировать на его изменение.
d) Чтобы видеть payload сообщения без узла `Debug`.
a) Advanced Connection Logic.
b) Access Control List — списки, определяющие, в какие топики клиент может публиковать и подписываться.
c) Asynchronous Communication Layer.
d) Audit and Control Log.
a) Использовать TLS-шифрование.
b) Настраивать ACL для каждого устройства.
c) Использовать один и тот же логин/пароль для всех контроллеров на всех объектах.
d) Генерировать уникальные учетные данные для каждого контроллера.
---
📋 Мини-runbook "Если не работает": MQTT-соединение с облаком
Если данные с контроллера не поступают в облако, последовательно проверьте следующие пункты:
* Статус узла `mqtt out`: Посмотрите на статус под узлом. Он `connected` (зеленый), `connecting` (желтый) или `disconnected` (красный)?
* Если `disconnected`:
* Проверьте правильность адреса сервера, порта (`8883` для TLS), логина и пароля. Одна опечатка — и ничего не заработает.
* Убедитесь, что в настройках включен TLS.
* Проверьте интернет-соединение на самом контроллере. Зайдите в терминал Linux и выполните команду `ping 8.8.8.8`. Если пинга нет — проблема в сети. Затем попробуйте `ping your-broker-address.com`. Если первый есть, а второго нет — проблема в DNS или файрволе.
* Если `connected`:
* Проверьте узел `Debug`, подключенный к выходу узла `Function`. Убедитесь, что `msg.payload` является строкой в формате JSON, а `msg.topic` задан корректно.
* Убедитесь, что узел `Inject` действительно отправляет сообщения.
* Подписка на правильный топик: Используйте MQTT Explorer или другой клиент для подписки на тот же топик, в который публикует контроллер. Убедитесь в отсутствии опечаток.
* Подписка на "wildcard" топик: Попробуйте подписаться на `project/object/controller_id/#` или даже на `#`, чтобы увидеть, приходят ли вообще какие-либо сообщения от вашего клиента. Возможно, вы ошиблись в названии конечного топика.
* Проверка ACL: Зайдите в панель управления вашего облачного брокера и проверьте правила ACL для пользователя, под которым подключается контроллер. Убедитесь, что у него есть права на `PUBLISH` в нужный топик.
* Блокировка портов: Убедитесь, что сетевой файрвол на объекте (в роутере) не блокирует исходящие соединения на порт `8883`. Это частая проблема в корпоративных сетях.