Что такое Smoke Test и зачем он нужен

Урок · Монтаж и пусконаладка контроллера · 10 мин · theory

Введение в дымовое тестирование (Smoke Test)

> 💡 Подсказка: Термин 'smoke test' (дымовое тестирование) пришел из радиоэлектроники. Если после первой подачи питания на новую печатную плату из нее не пошел дым, базовый тест на жизнеспособность считался пройденным. В нашей сфере это метафора быстрой проверки системы на предмет грубых, очевидных ошибок.

Дымовое тестирование (Smoke Test) — это предварительная, быстрая процедура проверки, цель которой — убедиться, что самые важные, критические функции системы работают после сборки, установки или внесения изменений. Это неглубокий, но широкий тест, который не ставит своей задачей найти все ошибки. Его главная цель — дать ответ на один простой вопрос: «Система вообще жива? Можно ли продолжать с ней работать и переходить к более детальному тестированию?».

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

Давайте четко разграничим Smoke Test и другие виды тестирования:

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

| Smoke Test (Дымовое) | Убедиться, что система в принципе запускается и ключевые компоненты "на связи". | Поверхностная | "Смогу ли я включить свет в гостиной командой из Node-RED? Датчик температуры вообще отзывается?" |

| Функциональное тестирование | Проверить, что каждая функция работает в точности так, как описано в техническом задании. | Глубокая | "Работает ли диммирование света с 5% до 85% с шагом в 1%? Сохраняется ли уставка климата после перезагрузки контроллера?" |

| Регрессионное тестирование | Убедиться, что после добавления новой функции не "сломалось" то, что работало раньше. | Средняя и Глубокая | "После того как я добавил управление шторами, не перестал ли работать сценарий 'Я ушел', который выключает свет?" |

| Нагрузочное тестирование | Проверить, как система ведет себя под высокой нагрузкой. | Специфическая | "Что произойдет, если 100 Modbus-устройств начнут одновременно отправлять данные на контроллер?" |

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

---

Ключевая роль Smoke Test в экосистеме контроллеров HI

> ⚠️ Внимание: Пропуск этапа Smoke Test, особенно на крупных объектах со сложной логикой, может привести к каскадным сбоям. Поиск изначальной причины, когда вся система ведет себя непредсказуемо, может занять часы или даже дни. Не пренебрегайте этой быстрой, но критически важной проверкой.

Современные системы автоматизации, будь то умный дом, гостиница или небольшой промышленный объект, — это сложные комплексы, где одновременно взаимодействуют десятки технологий и устройств. Контроллер HI является сердцем такой системы, управляя оборудованием по множеству протоколов: Modbus RTU, DALI, CAN, 1-Wire, и обмениваясь данными по сети через MQTT и TCP/IP.

Цена ошибки и сложность систем:

Представьте себе сценарий: вы смонтировали систему управления освещением DALI на 64 светильника, климат-контроль на основе 15 Modbus-термостатов и систему безопасности с 30 датчиками. После завершения монтажа вы сразу приступаете к настройке сложного сценария "Вечеринка", который затрагивает все эти подсистемы. Сценарий не работает. В чем причина?

Неправильно подключен шлюз DALI?
Обрыв шины Modbus?
Ошибка в IP-адресе MQTT-брокера?
Простая опечатка в коде Node-RED?

Без предварительного Smoke Test каждой подсистемы вы оказываетесь в ситуации, когда нужно проверять все и сразу. Это огромная трата времени и денег. Проведение дымового теста позволило бы локализовать проблему на раннем этапе:

Проверили связь с DALI-шлюзом: не отвечает. Проблема найдена за 2 минуты.

Проверили связь с Modbus-устройствами: все отвечают. Подсистема климата исправна, идем дальше.

Проверили отправку MQTT-сообщения: сообщение уходит и приходит. Сетевая часть в порядке.

Роль контроллера HI как центрального узла:

Контроллер HI — это идеальная точка для проведения Smoke Test. С его помощью можно проверить базовую работоспособность практически любого подключенного компонента. Ключевые проверки включают:

Связь с реле: Подать команду на замыкание/размыкание каждого из 22 встроенных реле и визуально (или с помощью мультиметра) убедиться в их срабатывании.
Связь с датчиками на универсальных входах: Проверить получение сигнала от "сухого контакта" (нажать на кнопку, замкнуть геркон), увидеть изменение показаний температуры от датчика 1-Wire.
Связь по шинам данных: Отправить базовый запрос (например, чтение одного регистра) каждому устройству на шине Modbus/CAN/DALI и убедиться в получении ответа, а не ошибки таймаута.

Проверка среды исполнения Node-RED:

Поскольку вся логика автоматизации на контроллере HI строится в среде Node-RED, ее проверка является неотъемлемой частью Smoke Test. Необходимо убедиться что:

Потоки (flows) развернуты (deployed) без ошибок. После нажатия кнопки "Deploy" не появилось сообщений об ошибках.

Базовый обмен сообщениями (`msg`) функционирует. Простейший поток из узла `Inject` и `Debug` работает, и в панели отладки появляется объект сообщения.

Ключевые узлы-конфигурации находятся в рабочем состоянии. Узел MQTT-брокера имеет статус "connected", а узел Modbus-сервера не показывает ошибок подключения.

Успешно пройденный Smoke Test дает инженеру уверенность в том, что "фундамент" системы заложен правильно, и можно переходить к "возведению стен" — настройке сложной логики и сценариев.

---

Практика: Разработка базового плана Smoke Test

Для того чтобы Smoke Test был эффективным и быстрым, он должен проводиться не хаотично, а по заранее подготовленному плану — чек-листу. Создание такого чек-листа — один из первых шагов инженера на объекте.

Идентификация критически важных компонентов

Прежде всего, определите, какие подсистемы являются жизненно важными для функционирования объекта. Обычно они делятся на три категории:

Освещение: Базовая функция любого жилого или коммерческого помещения. Проверка должна включать как минимум по одной группе света в каждой ключевой зоне.
Климат: Управление отоплением, вентиляцией и кондиционированием. Неработоспособность этой системы может привести к некомфортным условиям или даже к авариям (протечка, перегрев).
Безопасность: Датчики протечки, дыма, движения, герконы на дверях и окнах. Их корректная работа — абсолютный приоритет.

Создание чек-листа для проверки

Чек-лист удобно представлять в виде таблицы. Он должен содержать три главных столбца: "Что проверяем", "Ожидаемый результат" и "Как проверить".

Вот пример базового чек-листа для Smoke Test на типовом объекте (умная квартира):

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

| 6 | Реле 1: Свет в гостиной | При подаче команды из Node-RED слышен щелчок реле, свет в гостиной включается/выключается. | Использовать поток с узлом `rpi gpio out`, нацеленным на нужное реле. Визуально проверить свет. | ✅/❌ |

| 8 | Шина RS-485: Связь с модулем реле | При отправке запроса на чтение статуса (Read Coils) Modbus-модуль возвращает ответ, а не ошибку таймаута. | Использовать узел `Modbus-Read` с правильным `unitid` и адресом. Смотреть вывод узла в `Debug`. | ✅/❌ |

| 9 | Шина 1-Wire: Датчик температуры | Узел `ds18b20` при опросе возвращает числовое значение температуры в адекватном диапазоне (например, от 15 до 30). | Использовать узел для работы с 1-Wire датчиками, подключить к `Debug`. | ✅/❌ |

Использование узла `Debug` для мониторинга

Узел `Debug` — это главный инструмент инженера во время Smoke Test. Он позволяет в реальном времени видеть, какие данные передаются между узлами.

> ℹ️ Информация: Чтобы увидеть все содержимое сообщения, а не только `msg.payload`, в настройках узла `Debug` измените `Output` на `complete message object`. Это крайне полезно для отладки, так как позволяет видеть `msg.topic`, `msg.error`, `msg.payload` и другие свойства одновременно.

При проведении Smoke Test вы постоянно будете подключать узел `Debug` к выходам других узлов (`Modbus-Read`, `mqtt in`, `rpi gpio in`) и анализировать полученные сообщения. Это позволяет подтвердить, что данные не просто приходят, а приходят в правильном формате и с корректным значением.

---

Пример: Smoke Test для группы освещения на Modbus-реле

> 🔗 Связанный материал: Подробная конфигурация узлов для работы с Modbus RTU/TCP разбирается в уроке COURCE-02-M04-L02: 'Подключение и настройка Modbus-устройств'.

Рассмотрим практический сценарий. Вы смонтировали в щите 16-канальный модуль реле с интерфейсом Modbus RTU (RS-485) для управления освещением в офисе. Адрес устройства (Unit ID) — `5`. Реле, отвечающее за свет над рабочими столами, имеет адрес `0` (Coil 0). Ваша задача — провести Smoke Test этой конкретной группы света.

Шаг 1: Физическая проверка

Прежде чем касаться Node-RED, убедитесь, что:

На модуль реле подано питание (обычно 12V или 24V DC).
Шина RS-485 (провода A и B) подключена к соответствующим клеммам на контроллере HI и на самом модуле. Полярность не перепутана.
Силовая линия (230V) подключена к реле, а от него — к светильникам.

Шаг 2: Создание тестового потока в Node-RED

Создайте на отдельной вкладке простой поток для отправки команды. Он будет состоять из двух узлов `Inject`, одного узла `Function` и одного `Modbus-Write`.

[Inject: ON] ---+
                +--> [Function: Create Command] --> [Modbus-Write] --> [Debug: Result]
[Inject: OFF] --+

Шаг 3: Формирование команды (`msg.payload`)

Узел `Modbus-Write` ожидает на вход `msg.payload` со значением для записи (`true`/`false`) и объектом `msg.payload.functionCode` для указания параметров команды. Нам нужно использовать функцию `FC 5: Force Single Coil`.

Настройте узел `Function` "Create Command" следующим образом:

// Этот узел получает сообщение от одного из двух Inject'ов.
// В Inject "ON" мы устанавливаем msg.payload = true,
// а в Inject "OFF" - msg.payload = false.

let command = msg.payload; // true или false

// Модифицируем объект msg, добавляя параметры для Modbus
msg.payload = {
    'value': command,          // Что записываем: true (вкл) или false (выкл)
    'fc': 5,                   // Код функции: 5 (запись одного Coil)
    'unitid': 5,               // Адрес Modbus-устройства на шине
    'address': 0,              // Адрес регистра (Coil 0)
    'quantity': 1              // Количество регистров для записи (всегда 1 для FC5)
};

return msg;

> 📋 Ключевые понятия:

> * `value`: Данные для записи. Для `Coil` это `true` или `false`.

> * `fc`: Function Code. `5` для записи одного `Coil`, `15` для записи нескольких.

> * `unitid`: Уникальный адрес устройства на шине Modbus.

> * `address`: Адрес регистра, с которого начинается операция.

Шаг 4: Выполнение теста и анализ результата

Разверните поток, нажав "Deploy".

Нажмите на узел `Inject: ON`.

Проверьте физический результат: свет над столами должен был включиться. Вы могли услышать щелчок реле.

Проверьте ответ в панели Debug: если все прошло успешно, узел `Modbus-Write` вернет на выход исходное сообщение, которое вы отправили. Это подтверждает, что команда была отправлена без ошибок связи.

Пример успешного ответа в панели `Debug`:

{ "value": true, "fc": 5, "unitid": 5, "address": 0, "quantity": 1 }

Нажмите `Inject: OFF`. Свет должен погаснуть, а в `Debug` появится аналогичное сообщение со `value: false`.

Что если тест провален?

Если свет не включился, посмотрите в `Debug`. Скорее всего, вы увидите сообщение об ошибке, перехваченное узлом `Catch` или выданное вторым выходом узла `Modbus-Write`:

{
    "name": "PortNotOpenError",
    "message": "Port Not Open",
    "...": "..."
}

Это говорит о проблеме с COM-портом.

{
    "name": "TransactionTimedOutError",
    "message": "Timed out",
    "...": "..."
}

Это — ошибка таймаута. Самая частая причина: неверный `unitid`, обрыв шины, отсутствие питания на устройстве или неправильные настройки скорости порта.

Таким образом, за 5 минут вы полностью проверили всю цепочку: `Node-RED -> Шина RS-485 -> Modbus-модуль -> Реле -> Светильник`. Smoke Test пройден.

---

Автоматизация Smoke тестов в среде Node-RED

> 💡 Подсказка: Держите тестовые потоки на отдельной, специально названной вкладке (например, `00_TESTS`). Это упрощает навигацию, позволяет быстро запускать проверки и легко отключать или удалять их перед сдачей проекта заказчику.

Ручной запуск тестов — это хорошо, но на больших объектах хочется иметь возможность проверить все критические системы одной кнопкой. Node-RED предоставляет для этого все инструменты.

Создание тестовой вкладки

Создайте в своем проекте Node-RED новую вкладку (flow) и назовите ее, например, "00_SMOKE_TESTS". Префикс `00_` гарантирует, что она всегда будет первой в списке. На этой вкладке вы будете собирать все свои тестовые сценарии.

Использование узла `Inject` для запуска

Узел `Inject` — это ваша "тестовая кнопка". Для каждой проверки создайте свой `Inject`:

`Inject` с названием "Test: Living Room Light ON"
`Inject` с названием "Test: Read Kitchen Temp"
`Inject` с названием "Test: Check Boiler Status"

Эти узлы могут быть соединены с потоками основной логики через узлы `Link Out` и `Link In`, эмулируя реальные события, или запускать отдельные, чисто тестовые цепочки, как в примере с Modbus-реле.

Применение узлов `Status` и `Catch` для пассивного мониторинга

Дымовое тестирование может быть не только активным (когда вы что-то нажимаете), но и пассивным. Узлы `Status` и `Catch` идеально подходят для непрерывного мониторинга "здоровья" системы.

Узел `Catch`: Разместите на каждой вкладке проекта один узел `Catch`, настроенный на перехват ошибок со всех узлов (`all nodes on this flow`). Соедините все эти узлы `Catch` через узел `Link Out` с одним центральным потоком на вашей тестовой вкладке. Этот поток может просто выводить ошибку в `Debug` с пометкой `[CRITICAL ERROR]` и отправлять уведомление (например, в Telegram). Если за час работы в эту точку не пришло ни одного сообщения, это хороший знак.
Узел `Status`: Подключите узел `Status` к узлам-конфигурациям, отвечающим за связь (`mqtt-broker`, `modbus-client`). Он будет генерировать сообщения при изменении их состояния (например, `connected` -> `disconnected`). Вы можете отловить это событие и немедленно получить сигнал о проблеме.

Продвинутый уровень: Панель для визуализации тестов

Для проектов, требующих частой проверки, можно пойти дальше и создать простейшую визуальную панель с помощью `node-red-dashboard`.

Установите палитру `node-red-dashboard`.

На тестовой вкладке создайте поток, который по кнопке `Inject` запускает серию проверок (например, опрос всех Modbus-устройств).

Результат каждой проверки (успех/неудача) направляйте на узел `ui_text` или `ui_button`.

Настройте цвет текста или кнопки в зависимости от результата: зеленый для "OK", красный для "FAIL".

В результате вы получите простую веб-страницу по адресу `http://:1880/ui`, на которой будет наглядно видно состояние всех ключевых систем. Это крайне удобно для демонстрации работоспособности системы заказчику.

---

Итоги и лучшие практики

Smoke Test (Дымовое тестирование) — это не формальность, а ключевой навык эффективного инженера-инсталлятора. Это быстрый, высокоуровневый аудит здоровья системы, который экономит часы и даже дни работы на этапе пусконаладки. Ключевые выводы и лучшие практики:

Всегда выполняйте Smoke Test первым. Делайте это после первоначального монтажа, после внесения изменений в схему подключений или после развертывания нового кода в Node-RED.
Составляйте чек-лист. Работа по плану всегда эффективнее хаотичных действий. Чек-лист помогает ничего не забыть и структурирует процесс проверки.
Сохраняйте простоту. Цель Smoke Test — скорость и уверенность, а не 100% покрытие всех функций. Проверяйте только самое критичное: "включается ли?", "отвечает ли?".
Используйте инструменты Node-RED. Узлы `Debug`, `Inject`, `Catch` и `Status` — ваши лучшие друзья в процессе тестирования.
Автоматизируйте рутину. Выносите тестовые сценарии на отдельную вкладку, чтобы иметь возможность быстро проверить всю систему по одному клику.
Помните об ограничениях. Успешный Smoke Test не гарантирует, что в системе нет ошибок. Он лишь подтверждает, что "скелет" системы собран правильно, основные органы "живы", и можно переходить к детальной настройке и функциональному тестированию.

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