IoT в транспорте и логистике: от GPS-трекинга до контроля рефрижератора
COURSE-16-M05-L05 — IoT в транспорте и логистике: от GPS-трекинга до контроля рефрижератора
Введение в прикладные решения для транспорта
Интернет вещей (IoT) коренным образом меняет подходы к управлению в транспортной и логистической отраслях. Переход от пассивного наблюдения к активному, управляемому в реальном времени мониторингу позволяет достичь беспрецедентного уровня эффективности, безопасности и контроля. В рамках экосистемы HI, контроллер выступает в роли бортового телематического шлюза, способного не только собирать данные, но и автономно принимать решения, обеспечивая отказоустойчивость даже при потере связи с облаком.
Данный урок посвящен практическому применению контроллера HI для решения типовых задач в логистике: от простого GPS-трекинга до комплексного управления рефрижераторной установкой с соблюдением холодовой цепи.
Архитектура бортовой IoT-системы на платформе HI
Для решения задач в сфере транспорта и логистики стандартный контроллер HI используется как центральный узел, объединяющий различные периферийные устройства и протоколы. Его архитектура идеально подходит для суровых условий эксплуатации благодаря широкому набору интерфейсов и надежным компонентам.
- Центральный процессор (Linux, Node-RED): Основной мозг системы. Здесь выполняются потоки Node-RED, отвечающие за сбор данных, их обработку, агрегацию и отправку в облако. 4-ядерный процессор и 4 ГБ RAM обеспечивают достаточную производительность для одновременной работы с GPS, CAN, Modbus и другими протоколами.
- Резервный процессор (ARM32) и функция ПЛК: Критически важный компонент для обеспечения безопасности и надежности. На него выносится логика, которая должна работать детерминированно и безотказно, например, управление климатической установкой рефрижератора или блокировка двигателя. В случае сбоя основного процессора, ARM32 переводит систему в заранее определенное безопасное состояние (safe-state).
- Интерфейсы и протоколы:
* GPS/GLONASS модуль: Подключается через последовательный порт (RS-232/UART) или USB. Поставляет данные о местоположении, скорости и времени.
* CAN-шина: Позволяет напрямую подключаться к бортовой сети автомобиля для считывания сотен параметров: обороты двигателя, уровень топлива, температура охлаждающей жидкости, ошибки DTC и т.д.
* RS-485 (Modbus RTU): Используется для подключения промышленных датчиков: датчики уровня топлива (ДУТ), датчики температуры и влажности в кузове, считыватели RFID-меток.
* Универсальные входы (UI): Применяются для контроля дискретных событий: открытие/закрытие дверей фургона (геркон), работа исполнительных механизмов, нажатие тревожной кнопки.
* Релейные выходы (RELAY): Используются для управления исполнительными устройствами: блокировка стартера/бензонасоса, включение/выключение рефрижераторной установки, управление световой/звуковой сигнализацией.
- Локальное хранилище (MySQL, EEPROM): Встроенная база данных MySQL используется для кэширования данных при отсутствии связи (создание "черного ящика"). EEPROM используется для надежного хранения критически важных сценариев и настроек, которые не должны быть утеряны при сбое питания или программном сбое.
Практический сценарий: Комплексный мониторинг рефрижераторного фургона
Рассмотрим типовую задачу — обеспечение контроля за перевозкой скоропортящихся продуктов.
Задача: Оборудовать фургон-рефрижератор системой мониторинга, которая будет://================ WIRING-LOGISTICS-001: Reefer Van Monitoring =================
+------------------+
| [CTRL:HI-Core] |
+------------------+
| | | |
+---------------------------+ | | +---------------------------+
| (GSM/LTE) | | | (GPS/GLONASS)
| | | |
<-- Интернет --> [Modem] [CAN-шилд] [RS485-1] [GPS Module]
| | |
| +----A/B---- (SENS:Temp:Modbus-01)
| |
| +----A/B---- (SENS:Temp:Modbus-02)
|
|
(Бортовая сеть автомобиля) --CAN-H/L--+
|
|
(Дверной геркон) --"Сухой контакт"--> UI-01
|
|
(Рефрижератор) <-- ~230V/24VDC ------ RELAY-01
Реализация в Node-RED: Поток FLOW-LOGISTICS-REEFER-001
Для реализации этой задачи создается комплексный поток в Node-RED, который следует паттернам Академии HI.
ASCII-схема потока:// Вкладка 1: Сбор данных
[Inject: 10s] -> [CANbus In: Fuel] -> |
[Inject: 10s] -> [CANbus In: RPM] -> | -> [Function: "Join Data"] -> [Link Out: "To Aggregator"]
[Inject: 1s] -> [Serial In: GPS] -> |
[Inject: 30s] -> [Modbus-Getter] -> |
// Вкладка 2: Логика и Агрегация
[Link In: "From Collectors"] -> [Function: "Validate & Aggregate"] -> [MQTT Out: Telemetry]
|
+-> [Function: "Reefer Logic"] -> [Relay Out: Control]
|
+-> [MySQL Out: "Audit Log"]
// Вкладка 3: Обработка ошибок
[Catch: All Nodes] -> [Function: "Format Error"] -> [MQTT Out: Alerts]
|
+-> [MySQL Out: "Error Log"]
Шаг 1: Сбор и валидация данных
Каждый источник данных обрабатывается в своем под-потоке, который приводит сообщение к единому контракту.
Пример: Обработка данных с Modbus-датчика температуры (узел `Function` после `Modbus-Getter`)// Входящее сообщение от modbus-getter: msg.payload = { data: [215], ... }
let rawValue = msg.payload.data[0];
// 1. Валидация
if (rawValue < -500 || rawValue > 1000) { // -50.0°C to +100.0°C
node.status({fill:"red", shape:"dot", text:"Invalid temp: " + rawValue});
node.error("Некорректное значение температуры от датчика", msg);
return null; // Прерываем поток для этого сообщения
}
// 2. Приведение к контракту сообщения
let temperature = rawValue / 10.0;
msg.payload = {
value: temperature,
source: "temp-sensor-modbus-01", // Уникальный ID источника
ts: Date.now(),
unit: "°C"
};
node.status({fill:"green", shape:"dot", text: temperature + " °C"});
return msg;
Шаг 2: Агрегация и отправка телеметрии
Все обработанные данные собираются вместе в одном узле `Function` для формирования единого телеметрического пакета.
Контракт сообщения для MQTT (топик `telemetry/vehicle/VIN12345/data`):{
"ts": 1678886400000,
"gps": {
"lat": 55.7558,
"lon": 37.6173,
"speed": 62.5,
"valid": true
},
"can": {
"rpm": 2100,
"fuel_level": 75.5
},
"sensors": [
{ "id": "temp-sensor-modbus-01", "value": 4.5, "unit": "°C" },
{ "id": "temp-sensor-modbus-02", "value": 4.8, "unit": "°C" },
{ "id": "door-sensor-01", "value": false }
],
"reefer_state": "ON"
}
⚠️ Важно: Использование единого, хорошо структурированного JSON-сообщения вместо отправки каждого параметра отдельно значительно снижает трафик и нагрузку на MQTT-брокер.
Шаг 3: Логика управления рефрижератором (Паттерн "Конечный автомат")
Логика управления выносится в отдельный узел `Function`, который работает как конечный автомат (FSM).
// Уставки хранятся в flow-контексте, чтобы их можно было менять удаленно
let setpoint = flow.get("reeferSetpoint") || 5.0; // °C
let hysteresis = flow.get("reeferHysteresis") || 1.0; // °C
// Получаем среднюю температуру с датчиков
let avgTemp = (msg.payload.sensors[0].value + msg.payload.sensors[1].value) / 2;
// Получаем текущее состояние реле из контекста
let currentState = flow.get("reeferState") || "OFF";
let newState = currentState;
// Логика конечного автомата
if (currentState === "OFF" && avgTemp > setpoint + hysteresis) {
newState = "ON";
} else if (currentState === "ON" && avgTemp < setpoint) {
newState = "OFF";
}
// Если состояние изменилось, отправляем команду на реле
if (newState !== currentState) {
flow.set("reeferState", newState);
node.status({fill:"blue", shape:"dot", text:"Reefer: " + newState});
// Возвращаем сообщение для узла управления реле
return { payload: (newState === "ON") };
}
// Если состояние не изменилось, ничего не делаем
return null;
💡 Совет: Логику управления рефрижератором рекомендуется дублировать на резервном ARM32-процессоре с функцией ПЛК для максимальной надежности. Это гарантирует поддержание температуры даже в случае отказа основного ПО.
Риски и методы их минимизации на платформе HI
- Кибербезопасность:
* Решение HI: Используйте защищенное MQTT-соединение с TLS-шифрованием. Настройте на контроллере `iptables` (встроенный брандмауэр Linux) для блокировки всех портов, кроме необходимых (MQTT, NTP). Доступ по SSH — только по ключам.
- Потеря связи:
* Решение HI: Встроенная база данных MySQL на контроллере используется как буфер. При потере связи все телеметрические пакеты сохраняются локально с временной меткой. После восстановления связи накопленные данные отправляются на сервер.
- Физическая безопасность и надежность:
* Решение HI: Контроллер имеет промышленное исполнение. Используйте надежные винтовые клеммы и наконечники для проводов. Размещайте контроллер в защищенном от влаги и пыли месте в кабине.
- Интеграция с существующими системами:
* Решение HI: Гибкость Node-RED и наличие всех основных промышленных интерфейсов (CAN, RS-485, Ethernet) позволяют интегрироваться с 95% существующего оборудования. Для уникальных протоколов можно написать собственный парсер в узле `Function`.
---
Лабораторные работы
COURSE-16-M05-LAB09: Базовый GPS-трекинг и мониторинг температуры
Задача: Настроить контроллер HI для считывания NMEA-данных с GPS-модуля (подключенного к USB-порту `/dev/ttyUSB0`) и показаний с одного Modbus-датчика температуры. Вывести обработанные данные в консоль отладки Node-RED. Оборудование: Контроллер HI, GPS-модуль с USB-интерфейсом, Modbus-датчик температуры, блок питания. Чек-лист выполнения:COURSE-16-M05-LAB10: Комплексная система с управлением и отправкой в MQTT
Задача: Расширить предыдущую лабораторную работу. Добавить контроль открытия двери (через "сухой контакт" на входе UI-01), логику управления реле (RELAY-01) на основе показаний температуры и отправку агрегированного пакета данных на публичный MQTT-брокер. Оборудование: То же, что в LAB09, плюс кнопка (имитация геркона) и светодиод (имитация реле). Рубрика оценивания:- (30%) Данные с GPS и датчика температуры корректно собираются и форматируются.
- (30%) При замыкании входа UI-01 в телеметрическом пакете меняется флаг `door_open`.
- (30%) Реле RELAY-01 включается, когда температура превышает 25°C, и выключается, когда опускается ниже 23°C. Логика реализована через FSM в `flow context`.
- (10%) Каждые 10 секунд на MQTT-брокер `broker.hivemq.com` в топик `hi/academy/test/VIN123` отправляется единый JSON-пакет, соответствующий контракту сообщения.
---
Тест для самопроверки (COURSE-16-M05-QUIZ)
* a) Modbus RTU
* b) MQTT
* c) CAN
* d) 1-Wire
* a) Для ускорения обработки видео.
* b) Для выполнения критически важной логики (ПЛК) и обеспечения безопасного состояния.
* c) Для хранения лог-файлов.
* d) Для работы веб-интерфейса.
* a) Контракт сообщения
* b) Визуальный статус
* c) Конечный автомат (FSM)
* d) Переиспользуемый компонент (Subflow)
* a) Данные будут утеряны.
* b) Контроллер сохранит данные во встроенную MySQL базу и отправит их после восстановления связи.
* c) Контроллер отправит данные через спутниковую связь.
* d) Контроллер выключится для экономии энергии.
* a) В виде отдельных сообщений для каждого параметра.
* b) В виде CSV-строки.
* c) В виде единого, структурированного JSON-объекта.
* d) В виде бинарного массива.
* a) `Inject`
* b) `Switch`
* c) `Status`
* d) `Catch`
* a) Для подключения GPS-модуля.
* b) Для подключения промышленных датчиков температуры.
* c) Для связи с облаком.
* d) Для управления реле.
* a) Юридический документ.
* b) Стандартная, заранее определенная структура объекта `msg.payload`.
* c) Настройки MQTT-брокера.
* d) Лицензионное соглашение на использование узлов.
* a) Хранить в глобальной переменной Node-RED.
* b) Записать в текстовый файл на SD-карту.
* c) Использовать энергонезависимую память EEPROM.
* d) Отправлять на сервер при каждом запуске.
* a) Перезагрузить контроллер.
* b) Проверить настройки MQTT.
* c) Проверить физическое подключение: полярность A/B, наличие терминатора 120 Ом, уникальность адресов.
* d) Обновить Node-RED.
---
Мини-runbook «Если не работает»
📋 Проблема: Нет данных с GPS-модуля (в `Debug` не появляются координаты).
📋 Проблема: Неверные показания температуры с Modbus-датчика (например, -0.1 или 3276.7).
📋 Проблема: Данные не отправляются на MQTT-брокер.
* Правильность адреса брокера, порта, логина и пароля.
* Наличие интернет-соединения на контроллере (команда `ping 8.8.8.8` в консоли).
* Настройки TLS, если используется защищенное соединение.