IoT в здравоохранении: от концепции к практической реализации на платформе HI

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

COURSE-16-M05-L02 — IoT в здравоохранении: от концепции к практической реализации на платформе HI

Введение в IoMT (Internet of Medical Things)

Интернет медицинских вещей (Internet of Medical Things, IoMT) — это специализированное направление IoT, сфокусированное на применении сетевых технологий для связи и обмена данными между медицинскими устройствами, пациентами и клиническими системами. Основная цель IoMT — трансформация традиционной модели здравоохранения в проактивную, персонализированную и высокоэффективную систему. На платформе HI, благодаря гибкости контроллера и поддержке промышленных протоколов, инженеры могут создавать надежные локальные IoMT-решения, обеспечивающие сбор данных, автоматизацию и оперативное реагирование без обязательной зависимости от внешних облачных сервисов.

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

Ключевые области применения IoMT

Вместо абстрактных компонентов, рассмотрим конкретные инженерные задачи, решаемые с помощью IoMT на базе контроллера HI.

Удаленный мониторинг пациентов (Remote Patient Monitoring, RPM): Сбор жизненно важных показателей (температура тела, активность, положение) с носимых или стационарных датчиков в палате. Данные агрегируются на контроллере HI и могут быть переданы в локальную систему управления пациентами (например, через MQTT или запись в MySQL) для анализа медперсоналом.
Контроль среды в медицинских учреждениях: Автоматизация поддержания критически важных параметров в помещениях — температуры и влажности в процедурных кабинетах, складах с медикаментами, операционных. Контроллер HI напрямую управляет климатическим оборудованием (вентиляция, кондиционирование) через свои релейные выходы, основываясь на показаниях датчиков.
Системы «Умная палата»: Интеграция управления освещением (включая циркадное), положением кровати, вызовом медсестры и контролем доступа в единую систему. Контроллер HI выступает в роли центрального узла, объединяющего устройства DALI, Modbus и дискретные сигналы от кнопок.
Управление доступом и отслеживание активов: Контроль доступа в служебные помещения с помощью считывателей, подключенных по RS-485. Отслеживание перемещения дорогостоящего мобильного оборудования (например, инфузоматов) с помощью Bluetooth-меток.

Практическая реализация: Система мониторинга микроклимата в процедурном кабинете

Рассмотрим типовую задачу: обеспечить непрерывный контроль температуры и влажности в кабинете, где хранятся термочувствительные препараты. Система должна оповещать персонал при выходе параметров за допустимые пределы и автоматически включать вентиляцию.

Оборудование:

Контроллер HI (Debian, Node-RED).

Датчик температуры и влажности с интерфейсом RS-485 Modbus RTU.

Датчик открытия двери (магнитоконтактный, "сухой контакт").

Вытяжной вентилятор, управляемый через реле контроллера (AC 230V).

Шаг 1: Проектирование и схема подключения

Создание надежной схемы подключения — первый и самый важный этап.

ID Схемы: `WIRING-HEALTH-001`

Легенда:

* `CTRL:HI-Core` — Контроллер HI

* `SENS-TH-01` — Датчик температуры/влажности (Modbus, Slave ID=15)

* `SENS-DOOR-01` — Датчик открытия двери (геркон)

* `ACT-FAN-01` — Вытяжной вентилятор

ASCII-схема:

//========= WIRING-HEALTH-001: Climate Monitoring, Procedure Room =========

// AC Power Supply
  Щит АВР      [CTRL:HI-Core]
   ~L~ --------- L
   ~N~ --------- N
   ~PE~ -------- PE

// Modbus RTU Bus (RS-485)
                 [CTRL:HI-Core]                (SENS-TH-01)
                   (RS485-1)
Клемма Шина     Цвет       Клемма
   A   ---A------ (Зеленый) ---- A
   B   ---B------ (Белый) ----- B
  GND  ---GND---- (Черный) ----- GND
(Экран кабеля)--- GND (только со стороны контроллера)

// Dry Contact Input (Door Sensor)
(SENS-DOOR-01)   [CTRL:HI-Core]
  COM --------- UI-01 (GND)
  NO  --------- UI-02

// Relay Output (Fan Control)
     [CTRL:HI-Core]
   L   --- ~L~ ---+-- C (RL-01)
                 \-- NO (RL-01) --- ~L~ --- L (Fan)
   N   --- ~N~ ----------------------------- N (Fan)

📋 Чек-лист монтажа:

[x] Кабель для шины RS-485 — экранированная витая пара.
[x] Экран кабеля подключен к GND только со стороны контроллера.
[x] На датчике `SENS-TH-01` (если он последний на шине) активирован терминатор 120 Ом.
[x] Силовые цепи вентилятора проложены отдельно от сигнальных линий.

Шаг 2: Разработка потока в Node-RED

Логика системы реализуется в Node-RED с применением стандартных паттернов Академии.

ID Потока: `FLOW-HEALTH-MON-001`

ASCII-схема потока:

//========= FLOW-HEALTH-MON-001: Climate Logic, Procedure Room =========

// --- 1. Сбор данных ---
[Inject: 10s] -> [Modbus-Getter: Temp/Hum] -> [Function: "Валидация и контракт"] -> [Link Out: "telemetry"]

[GPIO In: Door] -> [Function: "Контракт для двери"] -> [Link Out: "telemetry"]


// --- 2. Обработка и логика ---
[Link In: "telemetry"] -> [Switch: "Маршрутизация по источнику"] --+-- (Температура) -> [Function: "Логика тревог"] -> [Link Out: "alerts"]
                                                                  |
                                                                  +-- (Дверь) -> [Function: "Логика двери"] -> [Link Out: "actions"]


// --- 3. Оповещения и действия ---
[Link In: "alerts"] -> [Switch: "Уровень тревоги"] --+-- (NORMAL) -> [Status: "OK"]
                                                    |
                                                    +-- (WARNING) -> [MQTT Out: "Notify Staff"]
                                                    |
                                                    +-- (CRITICAL) -> [Function: "Включить вентилятор"] -> [GPIO Out: Fan Relay]


// --- 4. Обработка ошибок ---
[Catch: All Nodes] -> [Function: "Форматировать ошибку"] -> [MySQL: "audit_log"]

Шаг 3: Реализация ключевых узлов

1. Узел `Function: "Валидация и контракт"`

Этот узел применяет паттерн "Контракт сообщения" и "Визуальный статус".

// Вход: msg.payload от Modbus-Getter, например { data: [255, 450], ... }
// где 255 = 25.5°C, 450 = 45.0% RH

const temp = msg.payload.data[0] / 10.0;
const humidity = msg.payload.data[1] / 10.0;

// Валидация
if (isNaN(temp) || temp < 0 || temp > 50) {
    node.status({ fill: "red", shape: "dot", text: "Ошибка данных температуры!" });
    node.error("Некорректное значение температуры: " + temp, msg);
    return null;
}

// Формирование сообщения по контракту
const output = {
    payload: {
        value: temp,
        unit: "°C",
        source: "SENS-TH-01-TEMP",
        ts: Date.now()
    },
    topic: "telemetry/procedure_room_1/temperature"
};

const output_hum = {
    payload: {
        value: humidity,
        unit: "%",
        source: "SENS-TH-01-HUM",
        ts: Date.now()
    },
    topic: "telemetry/procedure_room_1/humidity"
};

// Визуальный статус
node.status({ fill: "green", shape: "dot", text: `T: ${temp}°C, H: ${humidity}%` });

// Возвращаем два сообщения для дальнейшей обработки
return [output, output_hum];

2. Узел `Function: "Логика тревог"`

Этот узел реализует паттерн "Конечный автомат" (FSM) в упрощенном виде.

// Вход: сообщение с контрактом от датчика температуры
const temp = msg.payload.value;
const NORMAL_MAX = 25.0;
const WARNING_MAX = 27.0;

let alert_level = "NORMAL";
let alert_message = `Температура в норме: ${temp}°C`;

if (temp > WARNING_MAX) {
    alert_level = "CRITICAL";
    alert_message = `КРИТИЧЕСКОЕ ПРЕВЫШЕНИЕ! Температура: ${temp}°C. Включена вентиляция.`;
} else if (temp > NORMAL_MAX) {
    alert_level = "WARNING";
    alert_message = `Внимание! Температура повышена: ${temp}°C.`;
}

// Сохраняем состояние в контексте потока
flow.set("room1_alert_state", alert_level);

// Формируем сообщение для системы оповещений
msg.payload = {
    level: alert_level,
    message: alert_message,
    source: "FLOW-HEALTH-MON-001",
    ts: Date.now()
};
msg.topic = "alerts/procedure_room_1/temperature";

return msg;

3. Узел `Function: "Включить вентилятор"`

Простой узел, который формирует команду для реле.

// Этот узел получает сообщение только при CRITICAL уровне
msg.payload = 1; // Команда "включить" для узла rpi-gpio out
return msg;

Вызовы IoMT и их решение на платформе HI

Оригинальный урок правильно выделял проблемы. Рассмотрим, как архитектура HI помогает их решать.

Безопасность и конфиденциальность данных:

* ⚠️ Проблема: Утечка медицинских данных — критический риск.

* 💡 Решение HI: Контроллер по умолчанию работает как локальный хаб. Вся логика (сбор, анализ, принятие решений) выполняется на устройстве, без отправки данных в публичное облако. Для удаленного доступа используется защищенное VPN-соединение, настраиваемое на уровне ОС Debian. Обмен данными между контроллерами или с сервером клиники осуществляется по MQTT с обязательным использованием TLS-шифрования.

Совместимость и интеграция устройств:

* ⚠️ Проблема: "Зоопарк" протоколов от разных производителей медицинского оборудования.

* 💡 Решение HI: Контроллер является мультипротокольным шлюзом. Он нативно поддерживает Modbus (RTU/TCP), CAN, DALI, 1-Wire, а также сетевые протоколы MQTT и TCP/IP. Это позволяет инженеру объединять в одной системе как промышленные датчики, так и специализированное оборудование, создавая для них единый уровень логики в Node-RED.

Надежность и отказоустойчивость:

* ⚠️ Проблема: Сбой системы мониторинга может привести к порче дорогостоящих препаратов или риску для пациента.

* 💡 Решение HI: Платформа обладает несколькими уровнями надежности:

1. EEPROM: Критически важные сценарии и уставки могут храниться в энергонезависимой памяти, гарантируя их сохранность при сбоях питания.

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

3. Safe-State: Релейные выходы могут быть настроены на переход в безопасное состояние (включено/выключено) при потере связи с управляющей логикой.

---

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

COURSE-16-M05-LAB01: Настройка сбора и публикации телеметрии

Цель: Настроить чтение данных с Modbus-датчика, привести их к стандартному контракту сообщения и опубликовать в MQTT. Оборудование: Контроллер HI, Modbus-датчик температуры/влажности, ПК с MQTT-клиентом (например, MQTT Explorer). Задачи:

Подключить датчик к контроллеру по схеме `WIRING-HEALTH-001`.

Настроить узел `Modbus-Getter` для опроса регистров температуры и влажности каждые 5 секунд.

Создать узел `Function` для валидации данных и преобразования их в JSON-формат согласно контракту Академии.

Настроить узел `MQTT Out` для публикации данных в топики `telemetry/lab/temperature` и `telemetry/lab/humidity`.

Проверить получение данных в MQTT Explorer.

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

(30%) Данные успешно считываются с Modbus-устройства.
(40%) Сообщение в MQTT имеет корректный JSON-формат и все обязательные поля (`value`, `unit`, `source`, `ts`).
(30%) Узел `Function` корректно обрабатывает невалидные данные (например, при отключении датчика) и выводит ошибку, не останавливая поток.

COURSE-16-M05-LAB02: Реализация логики тревог и управления исполнителем

Цель: Добавить к потоку из LAB01 логику для анализа температуры, отправки тревожных сообщений и управления реле. Оборудование: Стенд из LAB01, светодиодная лампа для имитации вентилятора. Задачи:

Добавить в поток узел `Function`, который анализирует температуру.

Реализовать три состояния: NORMAL (<25°C), WARNING (25-27°C), CRITICAL (>27°C).

При состоянии WARNING отправлять сообщение в MQTT-топик `alerts/lab/warning`.

При состоянии CRITICAL отправлять сообщение в `alerts/lab/critical` И включать реле `RL-01`, к которому подключена лампа.

Имитировать повышение температуры, передавая в поток тестовые данные с помощью узла `Inject`.

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

(40%) Тревожные сообщения корректно публикуются в соответствующие MQTT-топики в зависимости от температуры.
(40%) Реле `RL-01` (лампа) включается только при CRITICAL-уровне и выключается при возврате к WARNING или NORMAL.
(20%) В потоке используется узел `Status` для визуального отображения текущего уровня тревоги.

---

Тест модуля: COURSE-16-M05-QUIZ

Что является ключевым преимуществом использования контроллера HI для задач IoMT по сравнению с облачными решениями?

a) Более красивый интерфейс.

b) Возможность локальной обработки данных для повышения безопасности и надежности.

c) Более низкая стоимость оборудования.

d) Поддержка большего количества языков программирования.

Согласно схеме `WIRING-HEALTH-001`, как должен быть подключен экран кабеля шины RS-485?

a) К клемме GND на обоих концах линии.

b) К клемме PE.

c) К клемме GND только со стороны контроллера.

d) Экран не нужно подключать.

Какой паттерн Node-RED обязывает стандартизировать структуру `msg.payload` в виде JSON-объекта с полями `value`, `source`, `ts`?

a) Паттерн "Конечный автомат".

b) Паттерн "Обработка ошибок".

c) Паттерн "Контракт сообщения".

d) Паттерн "Визуальный статус".

В потоке `FLOW-HEALTH-MON-001` для чего используется узел `Link Out: "telemetry"`?

a) Для отправки данных в облако.

b) Для создания "беспроводного" соединения с другой частью потока на той же вкладке, чтобы избежать "лапши".

c) Для записи логов в MySQL.

d) Для управления реле.

Какая функция контроллера HI обеспечивает выполнение базовой логики безопасности даже при сбое основной операционной системы?

a) Поддержка MQTT.

b) Наличие 4 ГБ RAM.

c) Функция ПЛК на отдельном ядре ARM32.

d) Встроенный веб-сервер.

При реализации логики тревог (`Function: "Логика тревог"`) где рекомендуется хранить текущее состояние тревоги (`alert_level`)?

a) В глобальном контексте (`global context`).

b) В контексте потока (`flow context`).

c) Внутри `msg.payload`.

d) В файле на диске.

Какую команду должен получить узел `rpi-gpio out` для включения реле?

a) `msg.payload = "ON"`

b) `msg.payload = true`

c) `msg.payload = 1`

d) `msg.payload = { "command": "turn_on" }`

Что произойдет, если узел `Modbus-Getter` не сможет прочитать данные с датчика?

a) Весь контроллер перезагрузится.

b) Поток остановится и будет ждать восстановления связи.

c) Узел сгенерирует ошибку, которая может быть перехвачена узлом `Catch`.

d) Node-RED автоматически отправит email администратору.

Для чего в IoMT-системах используется протокол MQTT?

a) Для прямого управления реле.

b) Для обмена сообщениями между устройствами и системами в реальном времени по принципу "издатель-подписчик".

c) Для создания веб-интерфейсов.

d) Для чтения данных с датчиков 1-Wire.

Вы получили от Modbus-датчика значение `301`. Согласно документации, для получения реального значения его нужно разделить на 10. Какое значение будет записано в поле `value` контракта сообщения?

a) `301`

b) `30.1`

c) `"30.1"`

d) `3.01`

---

Мини-runbook "Если не работает"

| Симптом | Возможная причина | Шаги диагностики и решения -**|

| Нет данных от Modbus-датчика. Узел `Modbus-Getter` показывает ошибку "timeout". | 1. Физическое подключение: Обрыв линии, перепутаны A/B, нет питания на датчике.
2. Конфигурация: Неверный Slave ID, скорость или COM-порт.
3. Терминирование: Отсутствует резистор 120 Ом на конце шины. | 1. Проверить целостность кабеля и полярность A/B. Убедиться, что на датчик подается питание.
2. В Node-RED проверить настройки узла `Modbus-Getter` и конфигурации Modbus-клиента. Сверить с документацией на датчик.
3. Проверить наличие и правильность установки терминаторов. |

| Данные от датчика приходят, но они некорректны (например, температура -3276.8°C). | 1. Ошибка "Off-by-one": Неправильно указан адрес регистра (например, 1 вместо 0).
2. Неверный формат данных: Неправильная обработка знакового/беззнакового числа или порядка байт. | 1. Внимательно изучить карту регистров датчика. Попробовать указать адрес на единицу меньше.
2. Проверить код в узле `Function`. Возможно, требуется побитовая обработка буфера `msg.payload.buffer`, а не простое деление. |

| Вентилятор не включается при CRITICAL-тревоге. | 1. Логика в Node-RED: Ошибка в узле `Function: "Логика тревог"`, неверно заданы пороги.
2. Подключение реле: Ошибка в силовой цепи, реле неисправно.
3. Конфигурация GPIO: Неправильно указан номер пина в узле `rpi-gpio out`. | 1. Подключить узел `Debug` после узла логики и проверить, какое сообщение он генерирует.
2. Проверить схему `WIRING-HEALTH-001`. Подать управляющий сигнал на реле вручную через узел `Inject` и проверить, щелкает ли оно.
3. Убедиться, что номер пина в узле соответствует номеру клеммы `RL-01`. |

| Ложные срабатывания датчика открытия двери. | 1. Физическое подключение: Плохой контакт в клеммах, дребезг контактов геркона.
2. Наводки: Сигнальный кабель проложен рядом с силовым. | 1. Проверить затяжку винтов на клеммах `UI-01`, `UI-02`.
2. В Node-RED добавить узел `Delay` с опцией "rate limit" (например, 1 сообщение в 2 секунды) после узла `GPIO In` для фильтрации дребезга. |