Подготовка к сертификации уровня Foundation: Комплексный обзор
COURSE-16-M07-L01 — Подготовка к сертификации уровня Foundation: Комплексный обзор
Добро пожаловать на завершающий урок курса "Основы IoT для инженеров". На протяжении предыдущих модулей вы получили фундаментальные знания и практические навыки для работы с платформой автоматизации HI. Этот урок систематизирует изученный материал и сфокусирует ваше внимание на ключевых компетенциях, которые будут проверяться на сертификационном экзамене уровня Foundation.
Цель этого урока — не просто повторить теорию, а продемонстрировать, как отдельные компоненты — оборудование, протоколы, программная логика и стандарты — объединяются в единую, надежную систему на реальном объекте.
1. Ключевые компоненты и архитектура системы на платформе HI
Любой IoT-проект, будь то умная квартира или система мониторинга в небольшом цеху, строится на четырех основных столпах. Давайте рассмотрим их в контексте нашей экосистемы.
- Устройства (Things): Это "глаза, уши и руки" вашей системы. На контроллере HI это:
* Выходы (Outputs): 22 релейных выхода для управления освещением, розетками, сервоприводами штор, клапанами отопления или вентиляции, контакторами для мощных нагрузок.
* Внешние устройства: Модули расширения, счетчики электроэнергии, панели управления, подключаемые по шинам RS-485 (Modbus), CAN, DALI; опции: LoRaWAN, Zigbee, Bluetooth, GSM.
- Шлюз (Gateway): Это "мозг" системы. В нашей архитектуре эту роль выполняет контроллер HI. Его задачи:
* Обработка и логика: Выполнение сценариев автоматизации, созданных в среде Node-RED.
* Связь: Взаимодействие с другими системами, облачными платформами и пользовательскими интерфейсами по протоколам MQTT, TCP/IP.
* Хранение: Запись критичных данных, состояний и логов в локальную базу данных MySQL.
* Критические сценарии: Выполнение детерминированной логики и поддержание safe-state на дополнительном ARM32 процессоре с хранением сценариев в EEPROM.
- Сеть и Облако (Network & Cloud): Это "нервная система", связывающая компоненты.
* MQTT-брокер: Центральный узел для обмена сообщениями. Может быть развернут как на самом контроллере HI, так и на внешнем сервере.
* База данных: MySQL на борту контроллера для надежного хранения истории показаний, логов событий и ошибок.
- Приложения (Applications): Это логика и интерфейсы, которые приносят пользу.
* Панели управления (Dashboard): Визуальные интерфейсы для мониторинга и управления, созданные, например, с помощью `node-red-dashboard`.
* Системы верхнего уровня: SCADA, BMS или мобильные приложения, которые взаимодействуют с контроллером через MQTT.
Архитектура типового объекта на платформе HI: [ Облако / Мобильное приложение ]
^
| (MQTT, TLS)
v
[ Интернет ] <---> [ Роутер ] <---------------------> [ Панель управления ]
^ ^
| (Ethernet) | (Ethernet/Wi-Fi)
v v
+-----------------------------------------------------------------------------+
| [ Контроллер HI (Debian, Node-RED, MQTT Broker, MySQL) ] |
| | | | | |
| | (Relay) | (1-Wire) | (RS-485) | (Dry Contact) |
| v v v v |
| <Освещение> (Датчик t°C) <Счетчик энергии> (Датчик движения) |
+-----------------------------------------------------------------------------+
2. Практическое применение протоколов: MQTT и Modbus
Протоколы — это язык, на котором общаются компоненты системы. На экзамене вам потребуется продемонстрировать уверенное владение двумя ключевыми протоколами.
MQTT: Стандарт для телеметрии и команд
MQTT (Message Queuing Telemetry Transport) — это легковесный протокол для обмена сообщениями по принципу "издатель-подписчик". В нашей экосистеме он используется для:
- Передачи данных с контроллера в системы верхнего уровня.
- Получения команд от пользовательских интерфейсов.
- Взаимодействия между несколькими контроллерами HI.
- Структура топиков (Topic Structure): Топики должны быть иерархическими и осмысленными. Стандарт Академии HI:
Пример: `hi/office_bld1/floor2/room205/temperature/value`
Пример: `hi/cottage1/living_room/main_light/command`
- Контракт сообщения (Message Contract): Все данные должны передаваться в стандартизированном формате JSON. Это критически важно для совместимости и отладки.
// Пример сообщения от датчика температуры
// Топик: hi/office_bld1/floor2/room205/temperature/value
{
"value": 23.5,
"unit": "°C",
"source": "1w-28-01234567abcd",
"ts": 1678886400000
}
- Качество обслуживания (QoS):
* `QoS 1`: "Доставлено как минимум один раз". Для команд управления (включить свет).
* `QoS 2`: "Доставлено ровно один раз". Для критичных транзакций (списание средств).
Modbus RTU: Стандарт для промышленного оборудования
Modbus — это протокол типа "Master-Slave" (или "Client-Server") для работы с промышленными датчиками и исполнительными устройствами по шине RS-485.
Ключевые концепции для экзамена:- Физическое подключение:
* Соблюдение полярности (A к A, B к B).
* Установка терминирующих резисторов (120 Ом) на концах шины.
* 📋 См. стандарт `WIRING-SENS-004`.
- Настройка в Node-RED (`node-red-contrib-modbus`):
* Использование узлов `Modbus-Read`, `Modbus-Write`, `Modbus-Getter` для выполнения операций.
* Указание правильного `Unit-ID` (адрес устройства на шине), `FC` (код функции) и `Address` (адрес регистра).
- Диагностика:
* Таймауты: Проблемы с подключением, неверный `Unit-ID` или параметры шины.
* CRC Error: Помехи на линии, отсутствие терминаторов, неверные параметры шины.
3. Стандарты разработки в Node-RED: От потока к надежной системе
Просто соединить узлы в Node-RED недостаточно. Профессиональный инженер создает потоки, которые надежны, читаемы и легко поддерживаются. На экзамене будет оцениваться ваше следование паттернам разработки Академии HI.
Краткое повторение ключевых паттернов:Пример задачи с экзамена и ее решение
Задача: Реализовать сценарий "умного освещения" для офисного помещения.- Входы: Датчик движения (дискретный вход `UI-05`), датчик освещенности (аналоговый вход `UI-06`, выдает 0-1023).
- Выход: Группа освещения (реле `RL-03`).
- Логика: Если обнаружено движение И уровень освещенности ниже порога (например, < 300), включить свет. Если движение отсутствует в течение 5 минут, свет выключить.
// Поток чтения датчиков
[Inject: 1s] -> [Analog In: UI-06] -> [Function: Format Light Sensor] -> [Change: Save to flow.context]
[Digital In: UI-05] -> [RBE] -> [Function: Format Motion Sensor] -> [Change: Save to flow.context]
// Основной поток логики
[Inject: 5s] -> [Function: Main Logic] -> [Switch: ON/OFF?] -> [Relay Out: RL-03]
|
+-> [Status Node]
// Поток обработки ошибок
[Catch: All Nodes] -> [Function: Format Error] -> [Link Out: To Global Error Logger]
// Получаем последние значения из контекста потока
const motion = flow.get("motion_detected") || false;
const lastMotionTime = flow.get("last_motion_ts") || 0;
const lightLevel = flow.get("light_level") || 1024;
const LIGHT_THRESHOLD = 300; // Порог освещенности
const TIMEOUT = 5 60 1000; // 5 минут в миллисекундах
let currentState = context.get("light_state") || "OFF";
let newState = currentState;
// 1. Паттерн "Конечный автомат" (FSM)
if (motion) {
// Если есть движение и темно, нужно включить свет
if (lightLevel < LIGHT_THRESHOLD) {
newState = "ON";
}
// Обновляем время последнего движения
flow.set("last_motion_ts", Date.now());
} else {
// Если нет движения, проверяем таймаут
if (Date.now() - lastMotionTime > TIMEOUT) {
newState = "OFF";
}
}
// Если состояние не изменилось, ничего не делаем
if (newState === currentState) {
// 3. Паттерн "Визуальный статус"
node.status({ fill: "grey", shape: "dot", text: `State: ${currentState}, Light: ${lightLevel}` });
return null;
}
// Сохраняем новое состояние
context.set("light_state", newState);
// 1. Паттерн "Контракт сообщения"
// Формируем команду для реле
if (newState === "ON") {
msg.payload = true;
} else {
msg.payload = false;
}
// 3. Паттерн "Визуальный статус"
node.status({ fill: "blue", shape: "dot", text: `Switching to ${newState}` });
// Формируем сообщение для аудита
msg.audit = {
source: "FLOW-AUTO-LIGHT-012",
action: `Light ${newState}`,
reason: motion ? "Motion detected" : "Timeout",
ts: Date.now()
};
return msg;
4. Диагностика и пусконаладка: Runbook инженера
На объекте не все идет по плану. Умение быстро находить и устранять неисправности — ключевой навык инженера.
📋 Мини-runbook "Если что-то пошло не так":
* Физика: Проверьте питание устройства. Проверьте полярность A/B. Убедитесь, что на концах шины есть терминаторы 120 Ом.
* Логика: Проверьте настройки COM-порта в Node-RED. Убедитесь, что `Unit-ID` в узле `Modbus-Getter` совпадает с адресом на устройстве. Проверьте адреса регистров (помните про "off-by-one").
* Отладка: Подключите узел `Debug` ко всем выходам интересующих вас узлов. Установите его в режим "complete message object".
* Статус: Посмотрите на статусы узлов. Красный цвет — ошибка. Желтый — подключение.
* Контракт: Убедитесь, что `msg.payload` на входе в узел соответствует тому, что узел ожидает.
* Логи: Проверьте центральный лог ошибок, куда пишет ваш узел `Catch`. Там будет информация об источнике ошибки и сообщении, которое ее вызвало.
* Связь: Убедитесь, что контроллер подключен к сети. Проверьте доступность MQTT-брокера (ping).
* Настройки: Проверьте IP-адрес и порт брокера в узле `mqtt out`.
* Авторизация: Проверьте логин/пароль и права доступа (ACL) на брокере.
* Топик: Убедитесь, что подписчик и издатель используют абсолютно одинаковый топик. `office/light` и `office/light/` — это разные топики.
---
Примеры практических заданий для самопроверки
Эти задания помогут вам подготовиться к практической части сертификационного экзамена. Они имитируют реальные задачи, с которыми вы столкнетесь на объекте.
EXAM-PRACTICE-01: Диагностика системы управления вентиляцией
Задача: Вам предоставлен экспорт потока Node-RED и схема подключения `WIRING-FAULT-001` для системы управления вентиляцией. Система не работает. Необходимо найти и исправить как минимум 3 ошибки (одну в схеме подключения, две в потоке Node-RED). Оборудование: Контроллер HI, Modbus-датчик CO2, реле для управления вентилятором. Критерии оценки:EXAM-PRACTICE-02: Проектирование отказоустойчивого сценария защиты от протечек
Задача: Спроектировать и реализовать в Node-RED сценарий управления водяным клапаном для защиты от протечек. Требования:Тест для самопроверки (COURSE-16-M07-QUIZ)
а) Звезда
б) Кольцо
в) Шина
г) Дерево
а) Для увеличения скорости передачи данных
б) Для предотвращения отражения сигнала и искажения данных
в) Для питания устройств на шине
г) Для ограничения тока в шине
а) 40101
б) 101
в) 100
г) 40100
а) QoS 0
б) QoS 1
в) QoS 2
г) QoS 3
а) `Debug`
б) `Status`
в) `Catch`
г) `Switch`
а) Простой текст
б) XML
в) JSON
г) Бинарный массив
а) Для отправки email-уведомлений об ошибках
б) Для быстрой диагностики состояния потока прямо в редакторе Node-RED
в) Для сохранения состояния между перезагрузками
г) Для отрисовки графиков на Dashboard
а) 1-Wire
б) Аналоговый 0-10В
в) "Сухой контакт" (Dry Contact)
г) Modbus
а) Использовать глобальный контекст (`global context`)
б) Использовать контекст потока (`flow context`) с настроенным сохранением в файл или БД
в) Записывать состояние в `msg.payload` и передавать по кругу
г) Хранить состояние в текстовом файле через узлы `file in`/`file out`
а) Только отображение данных на панели управления
б) Только хранение данных в облаке
в) Сбор данных с устройств, выполнение локальной логики и связь с внешним миром
г) Только обеспечение питания для датчиков