Сдача проекта: Тестирование, Оптимизация и Документирование

Урок 2 · Основы Интернета вещей и практическое применение · theory

COURSE-16-M07-LAB04 — Сдача проекта: Тестирование, Оптимизация и Документирование

Введение

Данный урок является завершающим этапом в цикле разработки IoT-проекта. На предыдущих этапах была спроектирована архитектура, реализована базовая логика и настроено взаимодействие с оборудованием. Теперь фокус смещается на критически важные инженерные практики: обеспечение производительности, стабильности и подготовку системы к сдаче-приемке. Проект считается завершенным не тогда, когда он "просто работает", а когда его надежность, эффективность и качество документации соответствуют промышленным стандартам.

Цель этого модуля — преобразовать работающий прототип в готовое к эксплуатации решение. Вы научитесь применять методики тестирования, оптимизировать потоки в Node-RED для снижения нагрузки на контроллер HI и формировать полный комплект исполнительной документации, достаточный для передачи системы в эксплуатацию или для дальнейшей поддержки другим инженером.

Цели урока

Применить методы оптимизации потоков Node-RED для снижения нагрузки на CPU и RAM контроллера.
Оптимизировать циклы опроса устройств (Modbus, 1-Wire) для обеспечения баланса между актуальностью данных и нагрузкой на шину.
Разработать и выполнить план тестирования (Test Plan) для проверки функциональных и нефункциональных требований проекта.
Провести тестирование на отказ (Failure Testing) для проверки реакции системы на сбои оборудования и связи.
Сформировать комплект исполнительной документации, включая паспорт проекта, схемы подключений и руководство по эксплуатации.
Подготовить и провести презентацию (защиту) проекта, демонстрирующую его техническую состоятельность и решенную задачу.

Шаг 1: Оптимизация производительности и надежности

Оптимизация — это не преждевременное усложнение, а осознанное улучшение системы на основе анализа ее работы. На платформе HI с контроллером на базе Debian и Node-RED, основные точки оптимизации — это потоки данных и использование системных ресурсов.

Оптимизация потоков (Flows) в Node-RED

💡 Совет: Перед началом оптимизации используйте стандартные утилиты Linux (`top`, `htop`) для замера текущей нагрузки на CPU и потребления памяти процессом Node-RED. Это даст вам базовые метрики для сравнения.

Рефакторинг "спагетти-потоков":

* Проблема: Длинные, запутанные потоки с множеством пересекающихся связей ("лапша") сложно отлаживать и поддерживать.

* Решение: Используйте узлы `Link In` / `Link Out` для создания логических "беспроводных" соединений между разными частями потока. Группируйте узлы по функциональному признаку (`Group`) и добавляйте комментарии (`Comment`).

Создание переиспользуемых компонентов (Subflows):

* Проблема: Дублирование одинаковых блоков логики (например, чтение датчика, валидация, отправка в MQTT) в разных местах проекта.

* Решение: Вынесите повторяющуюся логику в субпоток (`Subflow`). Это соответствует паттерну "Переиспользуемый компонент". Например, создайте субпоток `FLOW-SENS-TEMP-001` для обработки показаний датчика температуры. Он должен принимать на вход ID датчика и выдавать на выход стандартизированное сообщение по "Контракту сообщения".

Оптимизация узлов `Function`:

* Проблема: Сложные, ресурсоемкие вычисления или блокирующие операции внутри узла `Function` могут "заморозить" весь поток Node-RED.

* Решение: Избегайте циклов, которые могут выполняться долго. Если требуется сложная обработка, рассмотрите возможность выноса ее в отдельный скрипт (например, на Python), который можно запустить через узел `Exec`.

Оптимизация опроса устройств и использования ресурсов

Оптимизация опроса по шинам (Modbus, 1-Wire):

* Проблема: Слишком частый опрос устройств (например, каждые 100 мс) перегружает шину RS-485/1-Wire и CPU контроллера, не принося реальной пользы.

* Решение: Установите адекватную частоту опроса. Для температуры в помещении достаточно 1 раза в 30-60 секунд. Для состояния реле — по событию или 1 раз в секунду. Группируйте чтение регистров Modbus: чтение 10 регистров одним запросом эффективнее, чем 10 запросов по одному.

Управление состоянием и персистентность:

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

* Решение: Используйте `flow` контекст. Для сохранения состояний между перезагрузками настройте `contextStorage` в файле `settings.js` на использование файловой системы. Это гарантирует восстановление состояния системы после сбоя питания. Это реализация паттерна "Конечный автомат" (FSM) с персистентностью.

    // Пример настройки в settings.js для сохранения контекста в файлах
    contextStorage: {
        default: { module: "memory" },
        persistent: { module: "localfilesystem" }
    },

Оптимизация сетевого взаимодействия (MQTT)

Проблема: Неэффективное использование MQTT создает лишний трафик и нагрузку на брокер.
Решение:

* QoS (Quality of Service): Для команд управления (включить свет) используйте `QoS=1` или `QoS=2`. Для телеметрии (температура) достаточно `QoS=0`.

* Retain Flag: Устанавливайте флаг `Retain=true` только для сообщений о состоянии (`state`), чтобы новые подписчики сразу получали актуальное значение. Не используйте `Retain` для команд (`command`).

* Размер Payload: Придерживайтесь "Контракта сообщения" и не включайте в `msg.payload` избыточную информацию.

Шаг 2: Разработка и проведение комплексного тестирования

Тестирование — это формализованный процесс проверки соответствия системы требованиям. Для сдачи проекта необходимо подготовить и выполнить тест-план.

Разработка Тест-плана (Test Plan)

Тест-план — это документ, описывающий, что, как и с каким ожидаемым результатом будет проверяться.

📋 Шаблон Тест-плана:

Объект тестирования: Проект "Система мониторинга микроклимата в офисе". Контроллер HI-Core, датчики температуры/влажности (Modbus), датчики CO2 (аналоговые), управление вентиляцией (реле).

Цели тестирования: Проверить корректность сбора данных, выполнение сценариев автоматизации, стабильность работы в течение 8 часов, реакцию на сбои.

Виды тестирования:

* Функциональное тестирование (Functional Testing): Проверка выполнения основных функций.

* Тестирование на отказ и восстановление (Failure & Recovery Testing): Проверка реакции системы на нештатные ситуации.

* Нагрузочное тестирование (Load Testing): Проверка работы системы при пиковых нагрузках.

Проведение тестирования

1. Функциональное тестирование:

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

| FT-01 | Считать показания с Modbus-датчика температуры (ID=5). | В топике `telemetry/office/temp` появляется JSON с корректным значением (например, `{"value": 22.5}`). | | |

| FT-02 | Подать команду `ON` в MQTT-топик `commands/office/ventilation/set`. | Срабатывает реле №5 на контроллере. В топике `state/office/ventilation` появляется сообщение `ON`. | | |

| FT-03 | Превышение порога CO2 (800 ppm) по данным с аналогового входа UI-10. | Автоматически выполняется сценарий FT-02 (включается вентиляция). | | |

2. Тестирование на отказ и восстановление:

⚠️ Важно: Это самый главный вид тестирования для реальных объектов. Система должна быть предсказуемой даже при сбоях.

| FRT-01 | Физически отключить кабель RS-485 от Modbus-датчика. | Узел `Modbus-Read` переходит в статус "Error: Timeout". В системный лог (MySQL/файл) записывается ошибка. Система переходит в безопасный режим (например, выключает автоуправление). | | |

| FRT-02 | Перезагрузить контроллер HI по питанию. | После загрузки система восстанавливает последнее известное состояние (вентиляция остается включенной, если была включена). Это проверяет работу `contextStorage`. | | |

| FRT-03 | Отправить в MQTT-топик некорректное сообщение (например, строку вместо JSON). | Сообщение игнорируется и логируется как невалидное. Поток не "падает". Это проверяет работу узла валидации на входе. | | |

Шаг 3: Подготовка исполнительной документации

Исполнительная документация — это паспорт вашего проекта. Она необходима для того, чтобы любой другой инженер мог понять, как устроена система, как ее обслуживать и модифицировать.

Структура комплекта документации:

Паспорт проекта (Project Datasheet):

* Название, цель и краткое описание решаемой задачи.

* Автор, дата сдачи.

* Ключевые функциональные возможности.

Спецификация оборудования и схемы подключений:

* Перечень всего оборудования: контроллер, датчики, исполнительные устройства с указанием моделей.

* Обязательно: ASCII-схемы подключений, выполненные по стандарту Академии (например, `WIRING-SENS-004`, `WIRING-LIGHT-015`). Должны быть указаны цвета проводов, номера клемм, маркировка кабелей.

Архитектура ПО и описание потоков Node-RED:

* Общая логическая схема системы (диаграмма).

* Описание ключевых потоков (`FLOW-AUTO-CLIMATE-001`, `FLOW-INTEG-MQTT-008`) с их идентификаторами.

* Описание "Контракта сообщения" — стандартной структуры `msg.payload` для обмена данными.

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

Протокол испытаний (Test Report):

* Заполненный тест-план с фактическими результатами, скриншотами, логами и датами проведения тестов.

Руководство по эксплуатации и обслуживанию (Mini-Runbook):

* Краткая инструкция для конечного пользователя (если применимо).

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

Шаг 4: Презентация и защита проекта

Презентация — это демонстрация не только работающего устройства, но и вашего инженерного подхода.

Структура презентации (10-12 слайдов):

Титульный слайд: Название проекта, ваше имя, ID курса.

Постановка задачи: Какую проблему решает ваш проект? (Например, "Снижение расходов на электроэнергию в офисе за счет автоматического управления освещением и климатом").

Архитектура решения: Общая схема: контроллер HI, датчики, исполнительные устройства, сеть, облако/база данных.

Физическая реализация: Фотография собранного стенда/щита. ASCII-схема ключевого подключения (например, Modbus-шины).

Логика работы: Демонстрация самого интересного потока в Node-RED. Объяснение, как работает ключевой сценарий автоматизации.

Демонстрация работы: Короткое видео (1-2 минуты) или живая демонстрация работы системы.

Результаты тестирования: Показать самый интересный результат теста, особенно теста на отказ. "Мы отключили датчик, и система корректно перешла в безопасный режим, отправив уведомление".

Выполненная оптимизация: "Изначально CPU был загружен на 40%, после оптимизации частоты опроса и выноса логики в субпотоки нагрузка снизилась до 15%".

Выводы: Кратко о достигнутых результатах.

Пути развития: Что можно улучшить в будущем? (Например, "Добавить предиктивную аналитику на основе собранных данных", "Интегрировать с системой контроля доступа").

Q&A: Ответы на вопросы.

---

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

COURSE-16-M07-LAB01: Профилирование и оптимизация потока Node-RED

Задача: Вам предоставлен неэффективный поток `FLOW-UNOPT-ENERGY-MON-001`, который считывает данные с 3-х Modbus-счетчиков электроэнергии и отправляет их в MQTT. Ваша задача — оптимизировать его. Скелет потока (предоставляется):

Три узла `Inject`, каждый срабатывает раз в 500 мс.
Три цепочки `Modbus-Read` -> `Function` (с неоптимальным кодом парсинга) -> `MQTT Out`.
Логика дублируется трижды.

Задание:

Запустите утилиту `htop` и замерьте базовую нагрузку на CPU от этого потока.

Оптимизируйте поток:

* Объедините запуск в один `Inject` (например, раз в 5 секунд).

* Используйте узел `Trigger` или `Delay` для поочередного опроса счетчиков с задержкой в 200 мс, чтобы не перегружать шину RS-485.

* Вынесите логику парсинга и отправки в MQTT в один переиспользуемый субпоток `SUBFLOW-MODBUS-PARSER-001`.

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

Снова замерьте нагрузку на CPU и сравните с первоначальной.

Предоставьте скриншоты "до" и "после" и экспортированный JSON оптимизированного потока.

COURSE-16-M07-LAB02: Разработка тест-плана и проведение испытаний на отказ

Задача: Для вашего финального проекта разработать и частично выполнить тест-план, сфокусировавшись на тестах на отказ. Задание:

На основе шаблона из урока создайте документ `Тест-план` для вашего проекта. Заполните разделы "Объект тестирования" и "Цели".

Опишите минимум 3 функциональных теста (FT) и 3 теста на отказ и восстановление (FRT), применимых к вашему проекту.

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

Подготовьте отчет:

* Приложите разработанный тест-план.

* Подробно опишите шаги выполненного теста на отказ.

* Приложите доказательства реакции системы: скриншот статуса узла в Node-RED, выдержку из лог-файла или таблицы MySQL, скриншот уведомления.

* Сделайте вывод, соответствует ли реакция системы ожидаемой.

Квиз по модулю (COURSE-16-M07-QUIZ)

Какая утилита в Debian Linux позволяет в реальном времени отслеживать нагрузку на CPU по каждому процессу?

a) `ls`

b) `netstat`

c) `htop`

d) `ping`

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

a) Конечный автомат (FSM)

b) Субпоток (Subflow)

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

d) Визуальный статус

При опросе Modbus-устройств на одной шине RS-485, какая стратегия является наиболее эффективной?

a) Опрашивать все устройства одновременно каждые 100 мс.

b) Опрашивать устройства поочередно с небольшой задержкой между запросами.

c) Опрашивать каждое устройство в отдельном потоке Node-RED.

d) Использовать максимально возможную скорость шины (Baud Rate).

Для сохранения состояния системы (например, `flow.state`) между перезагрузками контроллера необходимо:

a) Использовать глобальный контекст (`global`).

b) Настроить `contextStorage` на использование файловой системы (`localfilesystem`).

c) Записывать состояние в `msg.payload`.

d) Увеличить RAM контроллера.

Тестирование, проверяющее реакцию системы на обрыв связи с датчиком, называется:

a) Функциональное тестирование.

b) Юнит-тестирование.

c) Тестирование на отказ и восстановление.

d) Нагрузочное тестирование.

Какой флаг в MQTT используется, чтобы новый подписчик немедленно получил последнее опубликованное сообщение в топике?

a) `QoS`

b) `Retain`

c) `Clean Session`

d) `Payload`

Что является основной целью создания "Контракта сообщения"?

a) Уменьшить размер сообщений.

b) Обеспечить предсказуемость и стандартизацию структуры данных между узлами.

c) Зашифровать передаваемые данные.

d) Увеличить скорость передачи по MQTT.

В исполнительной документации ASCII-схема `WIRING-SENS-004` относится к разделу:

a) Паспорт проекта.

b) Протокол испытаний.

c) Спецификация оборудования и схемы подключений.

d) Руководство по эксплуатации.

Какой узел Node-RED является основным инструментом для централизованного перехвата ошибок в потоках?

a) `Debug`

b) `Status`

c) `Catch`

d) `Switch`

При оптимизации потока вы заметили, что один узел `Function` выполняет сложный расчет в течение 2 секунд. Что это вызовет?

a) Увеличение потребления RAM.

b) Блокировку всего потока Node-RED на время выполнения.

c) Ошибку компиляции.

d) Ничего, Node-RED многопоточный.

---

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

| Проблема | Возможная причина и что проверить - |

| Нагрузка на CPU контроллера постоянно выше 80-90%. | 1. Слишком частый опрос: Проверьте интервалы в узлах `Inject`. Для инертных процессов (температура) увеличьте интервал до 30-60с.

2. Неэффективный код: Проверьте узлы `Function` на наличие сложных циклов.

3. "Шторм" сообщений: Проверьте, нет ли в системе логической петли, где сообщения гоняются по кругу. Используйте `Debug` для отслеживания потока. |

| Система не восстанавливает свое состояние после перезагрузки. | 1. Контекст не сохраняется: Убедитесь, что вы используете `flow` или `global` контекст с настроенным `contextStorage` в `settings.js` для записи в файловую систему.

2. Неправильное использование контекста: Проверьте, что вы используете `flow.set("var", value, "persistent")` для сохранения в настроенное хранилище. |

| Сообщения от Modbus-устройства приходят, но они некорректны (мусор). | 1. Неправильный парсинг: Проверьте код в узле `Function` после `Modbus-Read`. Возможно, вы неверно интерпретируете порядок байт (endianness) или формат данных (float, int32).

2. Ошибка "Off-by-one": Убедитесь, что адрес регистра в узле `Modbus-Read` указан верно (часто нужно вычитать 1 из номера в документации). |

| Система "зависает" при отправке команды на исполнительное устройство. | 1. Нет обработки ошибок: Узел, отправляющий команду (например, `Modbus-Write`), не может связаться с устройством и "ждет" ответа, блокируя поток.

2. Решение: Всегда обрабатывайте второй (ошибочный) выход у узлов ввода-вывода. Используйте узел `Catch` для перехвата таймаутов и других исключений. |

Рубрика оценивания финального проекта

| Оптимизация и надежность (10) | Потоки не оптимизированы, нагрузка на CPU высокая. Отсутствует обработка ошибок и сохранение состояния. | Применены базовые техники оптимизации (частота опроса). Обработка ошибок реализована частично. | Потоки хорошо структурированы, используется `Link Out`. Присутствует обработка ошибок через `Catch`. Состояние сохраняется. | Применены все паттерны: Subflows, FSM, Message Contract, Error Handling, Visual Status. Нагрузка на CPU минимальна. Система восстанавливается после сбоев. - |

| Тестирование (10) | Тестирование не проводилось или проводилось формально, без тест-плана. | Составлен простой тест-план, выполнены только базовые функциональные тесты. | Составлен подробный тест-план. Проведены функциональные тесты и как минимум один тест на отказ. Результаты задокументированы. | Разработан комплексный тест-план, включающий функциональные, нагрузочные тесты и тесты на отказ. Все тесты выполнены, результаты детально задокументированы с логами и скриншотами. - |

| Исполнительная документация (10) | Документация отсутствует или содержит только описание проекта. | Присутствует спецификация оборудования и базовое описание логики. Схемы отсутствуют или не соответствуют стандарту. | Подготовлен полный комплект документации, но есть недочеты (например, не все схемы выполнены в ASCII, нет руководства по эксплуатации). | Представлен полный, профессионально оформленный комплект исполнительной документации, включая паспорт, все схемы по стандарту (`WIRING-XXX`), описание потоков (`FLOW-XXX`) и мини-runbook. - |

| Презентация и защита проекта (10) | Презентация не подготовлена. Демонстрация не работает. | Презентация содержит только описание. Докладчик не может ответить на технические вопросы. | Проект продемонстрирован, презентация структурирована. Докладчик уверенно отвечает на большинство вопросов. | Проведена профессиональная презентация с живой демонстрацией, анализом результатов и четким изложением инженерных решений. Докладчик демонстрирует глубокое понимание проекта. |