Тестирование аварийных сценариев при сдаче объекта

Методология и регламент тестирования

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

> ⚠️ Внимание: Никогда не приступайте к имитации аварийных сценариев без предварительного согласования с заказчиком и отключения оборудования, которое может быть повреждено в процессе теста (например, дорогостоящая насосная станция, серверное оборудование или прецизионные станки).

Основой для проведения испытаний служит заранее разработанный протокол испытаний (или чек-лист). Это не просто список тестов, а структурированный документ, который регламентирует весь процесс.

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

• Протокол испытаний: Формальный документ, описывающий последовательность тестов, методы имитации событий, ожидаемые результаты и критерии оценки. Каждый пункт протокола соответствует конкретному требованию технического задания.
• Техника безопасности: Перед началом тестов на объекте необходимо провести инструктаж для всех присутствующих лиц. Люди должны быть осведомлены о том, что сейчас будет имитироваться, например, пожарная тревога, и что отключение вентиляции или розеток является частью запланированного теста, а не реальной аварией.
• Разграничение ролей: Эффективное тестирование требует четкого распределения обязанностей между участниками процесса.

| Роль | Задачи и ответственность |

| :--- | :--- |

| Инженер-инсталлятор | Физически выполняет действия на объекте: замыкает тестовые контакты, нажимает кнопки, визуально контролирует срабатывание исполнительных механизмов (закрытие кранов, остановка вентиляторов). |

| Программист автоматизации | Находится у компьютера или с планшетом. В реальном времени отслеживает состояние системы: анализирует логи в консоли контроллера, наблюдает за потоками сообщений в MQTT Explorer, проверяет статусы узлов в Node-RED. |

| Представитель заказчика | Наблюдает за процессом, подтверждает соответствие фактических результатов ожиданиям и требованиям. В конце процесса ставит свою подпись в протоколе, формально принимая работу. |

Разработка протокола начинается на этапе проектирования. Для каждого определенного в системе аварийного сценария (пожар, протечка, потеря связи, сбой питания) создается отдельный раздел в чек-листе.

Пример структуры пункта в протоколе испытаний:

ID теста: `T-SAFETY-01`

Наименование сценария: Пожарная тревога.

Метод имитации: Замыкание контактов на универсальном входе UI-05 контроллера, имитирующее сигнал от пожарного шлейфа.

Ожидаемые результаты:

* Отключение реле RL-01 (Вентиляция).

* Отключение реле RL-02, RL-03, RL-04 (Группы розеток).

* Закрытие электромагнитного клапана приточной вентиляции.

* Отправка PUSH-уведомления "ПОЖАРНАЯ ТРЕВОГА!" на телефоны пользователей.

* Запись события в `audit_log` базы данных MySQL.

Критерий прохождения: Все ожидаемые результаты достигнуты в течение 5 секунд после имитации сигнала.

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

---

Практикум: Имитация сценария «Пожарная тревога»

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

> 🔗 Связанный материал: Логика обработки данного сценария, включая построение потока `FLOW-SAFETY-001` и управление группами устройств, подробно разобрана в уроке COURSE-06-M07-L02 «Сценарий 'Пожарная тревога'».

Для имитации можно использовать два основных метода: программный и физический.

Методы имитации

Программная имитация (через MQTT): Этот метод идеален для предварительной отладки логики без физического доступа к оборудованию. Он заключается в отправке сообщения в MQTT-топик, который слушает ваш поток Node-RED, имитируя сигнал от датчика.

* Преимущества: Быстро, не требует физических манипуляций, можно выполнять удаленно.

* Недостатки: Не тестирует физическую цепь от датчика до входа контроллера.

Физическая имитация (замыкание «сухого контакта»): Наиболее полный метод, так как тестирует всю цепочку: от клемм контроллера до срабатывания исполнительных устройств.

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

* Недостатки: Требует физического доступа к шкафу автоматизации.

Пошаговый протокол испытаний (SCN-SAFETY-001)

Шаг 1: Подготовка

Уведомите всех присутствующих о начале теста «Пожарная тревога».

Программист автоматизации открывает на своем ноутбуке:

* MQTT Explorer или аналогичный клиент, подписанный на топики состояния целевых реле (например, `hi/devices/relay_module_1/controls/+/on`).

* SSH-сессию с контроллером для мониторинга логов Node-RED в реальном времени (`journalctl -f -u nodered.service`).

* Веб-интерфейс Node-RED для визуального контроля статусов узлов.

Шаг 2: Имитация события (программный метод)

Инженер отправляет MQTT-сообщение с помощью утилиты `mosquitto_pub` или через клиент. Предположим, система ожидает сигнал от пожарного шлейфа в топике `hi/devices/fire_alarm/controls/dry_contact_1`.

# Имитируем срабатывание (замыкание контакта)
mosquitto_pub -h localhost -t "hi/devices/fire_alarm/controls/dry_contact_1" -m "1"

При этом в потоке Node-RED, который подписан на этот топик, узел `mqtt in` получит сообщение `msg.payload` со значением `"1"`.

Шаг 3: Проверка результатов

Программист:

* Наблюдает в MQTT Explorer, как топики состояния целевых реле `.../on` мгновенно получают значение `0`.

* Смотрит в лог Node-RED и видит сообщения, сгенерированные вашим потоком (например, "FIRE ALARM DETECTED! Executing safety protocol...").

* Визуально в Node-RED видит, как узлы `Status` под соответствующими реле меняют цвет на красный и показывают статус "OFF".

Инженер-инсталлятор:

* Слушает: Должен прекратиться шум от работы вентиляционных установок.

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

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

Представитель заказчика:

* Получает на свой смартфон PUSH-уведомление с текстом тревоги.

Шаг 4: Сброс тревоги и возврат в штатный режим

После успешной проверки всех пунктов необходимо вернуть систему в нормальное состояние. Это делается с помощью заранее предусмотренного механизма, например, отправкой другого MQTT-сообщения или нажатием кнопки «Сброс» в интерфейсе.

# Имитируем сброс тревоги (размыкание контакта)
mosquitto_pub -h localhost -t "hi/devices/fire_alarm/controls/dry_contact_1" -m "0"

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

Шаг 5: Документирование

Результаты заносятся в протокол испытаний с отметкой «Пройдено» и подписью ответственных лиц.

---

Практикум: Имитация сценария «Протечка воды»

Тестирование сценария защиты от протечек направлено на проверку двух ключевых аспектов: скорости реакции системы и надежности исполнительных механизмов (вводных кранов с электроприводом).

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

Цель теста — убедиться, что при обнаружении воды система немедленно перекрывает подачу воды и обесточивает опасные зоны.

Методы имитации

Использование тестовой кнопки на датчике: Большинство современных датчиков протечки (например, Ajax, Gidrolock) оснащены кнопкой `Тест`, нажатие которой полностью имитирует срабатывание. Это самый предпочтительный метод.

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

Программная имитация (MQTT): Аналогично пожарному сценарию, можно отправить сообщение в MQTT-топик, ассоциированный с датчиком протечки.

Пошаговый протокол испытаний (SCN-SAFETY-002)

Шаг 1: Подготовка

Инженер-инсталлятор находится рядом с вводными кранами и в зоне, где расположены датчики (например, в санузле или котельной).

Программист автоматизации контролирует MQTT-топики кранов (`hi/devices/water_valve_1/controls/state/on`), реле насосов и розеток в «мокрых» зонах.

Частично прикройте ручной вентиль на вводе воды в объект.

Шаг 2: Имитация события

Инженер нажимает кнопку «Тест» на датчике протечки, расположенном в санузле. Система должна отреагировать. Предположим, датчик отправляет следующее сообщение по MQTT:

{
  "value": true,
  "source": "leak_sensor_bathroom_1",
  "ts": 1678886400000,
  "meta": {
    "zone": "bathroom",
    "battery_level": 95
  }
}

Шаг 3: Проверка результатов

Инженер-инсталлятор:

* Слушает и смотрит: Немедленно после срабатывания датчика он должен услышать звук работающих сервоприводов на вводных кранах и визуально убедиться, что они перешли в положение «Закрыто».

* Проверяет насосы: Если в системе есть насосная станция повышения давления, она должна отключиться.

* Проверяет розетки: С помощью тестера проверяет отсутствие напряжения на розетках в ванной комнате и на кухне под мойкой.

Программист:

* Видит в MQTT Explorer, как топик состояния крана `.../state/on` меняется на `0`.

* Подтверждает получение `0` в топиках состояния реле, отвечающих за розетки в мокрых зонах.

* Проверяет статус в панели визуализации (например, iRidium). Иконка крана должна стать красной или перечеркнутой.

Представитель заказчика:

* Получает на свой смартфон PUSH/SMS/Telegram уведомление: «ПРОТЕЧКА ВОДЫ в санузле! Подача воды перекрыта.»

Шаг 4: Сброс тревоги

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

После нажатия кнопки «Сброс» в интерфейсе:

• Сервоприводы должны начать открывать краны.
• Питание на розетки и насосы должно вернуться.
• Уведомление о тревоге в интерфейсе должно исчезнуть.

Шаг 5: Документирование

Все шаги и их результаты фиксируются в протоколе испытаний. Особое внимание уделяется времени реакции системы — от момента срабатывания датчика до полного закрытия кранов (обычно не должно превышать 15-30 секунд в зависимости от привода).

---

Практикум: Имитация отказа контроллера и потери питания

Этот тип тестов проверяет отказоустойчивость системы и ее способность корректно восстанавливаться после критических сбоев. Главная задача — убедиться, что при внезапном обесточивании контроллера система перейдет в заранее определенное безопасное состояние (Safe-State), а после восстановления питания вернется в работоспособное состояние без потери критически важных данных.

> 🔗 Связанный материал: Принципы настройки энергонезависимого контекста для сохранения состояний при перезагрузке с использованием файловой системы или MySQL, а также возможности встроенного в контроллер EEPROM, были рассмотрены в уроке COURSE-06-M07-L05.

Тест 1: «Hard Reboot» — Проверка поведения при внезапном отключении

Этот тест имитирует наиболее жесткий сценарий — полное и внезапное прекращение подачи питания на контроллер.

Порядок выполнения:

Фиксация состояния: Перед тестом зафиксируйте в протоколе текущее состояние всех ключевых выходов (реле): какие включены, какие выключены. Например, свет в гостиной включен, отопление работает, розетки активны.

Отключение питания: Инженер-инсталлятор физически отключает автоматический выключатель, питающий контроллер, или отсоединяет разъем питания 24V DC. Использование команды `sudo reboot` не подходит, так как она инициирует корректное завершение работы ОС.

Проверка Safe-State: Сразу после отключения питания необходимо проверить состояние выходов. В соответствии с концепцией fail-safe, разобранной ранее, большинство реле должны перейти в выключенное состояние.

* Что должно отключиться: Освещение, розеточные группы, отопительные приборы, вентиляция. Это обеспечивается использованием реле с нормально-разомкнутыми контактами (NO), которые размыкают цепь при пропадании питания на катушке.

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

Тест 2: «Cold Start» — Проверка восстановления после сбоя

Этот тест является продолжением предыдущего и проверяет, как система «оживает» после восстановления питания.

Порядок выполнения:

Восстановление питания: Инженер включает питание контроллера.

Наблюдение за загрузкой: Программист наблюдает за процессом загрузки через SSH-консоль. Главная задача — отследить ошибки. Важнейшей является проверка логов сервиса Node-RED.

    # Подключиться к логу Node-RED и следить за новыми записями

    sudo journalctl -f -u nodered.service
    

Ищите строки с пометками `[error]` или `[warn]`. Ошибки на этом этапе могут указывать на проблемы с доступом к файловой системе, базе данных MySQL или неправильно сконфигурированные узлы.

Проверка восстановления контекста: После полной загрузки Node-RED (в логе появится строка `[info] Started flows`), проверьте, восстановила ли система свои состояния.

* Пример: Если до отключения был активен сценарий «Отпуск», то после загрузки он должен остаться активным. Данные об этом должны были быть считаны из энергонезависимого контекста (файла или базы данных MySQL), как это было настроено в `settings.js`.

* Пример: Уставки термостатов, режимы работы оборудования — все, что было сохранено в `flow` или `global` контексте, должно восстановиться.

Проверка состояния выходов: Сравните текущее состояние реле с тем, что было до отключения. Система должна либо восстановить предыдущее состояние (если это предусмотрено логикой), либо перейти в некое начальное безопасное состояние (например, все освещение выключено). Это поведение определяется вашими потоками Node-RED, которые запускаются при старте.

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

---

Итоги: Документирование результатов и сдача работ

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

> ℹ️ Информация: Правильно составленный и подписанный обеими сторонами протокол испытаний — это не просто формальность. Это юридически значимый документ, который защищает инженера и компанию-интегратора, подтверждая, что на момент сдачи все системы функционировали в полном соответствии с проектными требованиями.

Финальный этап сдачи работ включает в себя три ключевых шага:

1. Формирование финального отчета (протокола испытаний)

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

Пример финальной таблицы в протоколе:

| ID Теста | Тестируемый сценарий | Метод имитации | Ожидаемый результат | Фактический результат | Статус |

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

| T-SF-01 | Пожарная тревога | Замыкание UI-05 | Откл. вент., розеток; PUSH | Все системы откл., PUSH получен | Пройдено |

| T-SF-02 | Протечка воды (С/У) | Кнопка «Тест» | Закрытие кранов; откл. розеток | Краны закрыты за 18с. | Пройдено |

| T-SF-03 | Отказ контроллера | Откл. питания | Реле RL01-15 в "OFF" | Все целевые реле в "OFF" | Пройдено |

| T-SF-04 | Восстановление | Вкл. питания | Загрузка без ошибок; `flow.vacation`=true | Система восстановлена, ошибок нет | Пройдено |

Статус «Требует доработки» означает, что работа не может быть принята до устранения выявленных недостатков и проведения повторного тестирования данного пункта.

2. Подписание акта сдачи-приемки работ

После того как все пункты протокола испытаний получили статус «Пройдено», и заказчик удовлетворен результатами, подписывается акт сдачи-приемки работ по системе автоматизации. Этот документ формально завершает проект и, как правило, является основанием для финальной оплаты. К акту в качестве приложения обязательно прикладывается подписанный протокол испытаний.

3. Передача документации и инструктаж заказчика

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

• «Что делать, если пришло уведомление о протечке?»
• «Как вручную отменить тревогу?»
• «Кому звонить, если что-то не работает?»

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

Что дальше

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