Главная → Академия → Сценарии умного дома: режимы, состояния, приоритеты → Проведение 'учений': имитация аварийных ситуаций (протечка, пропажа сети)

Проведение 'учений': имитация аварийных ситуаций (протечка, пропажа сети)

Урок 3 · Сценарии умного дома: режимы, состояния, приоритеты · 30 мин · theory

Введение в стресс-тестирование: зачем имитировать "апокалипсис"

ведение в стресс-тестирование: зачем имитировать "апокалипсис"

Вы успешно спроектировали и внедрили сложную систему автоматизации. Все сценарии работают, свет включается по расписанию, климат поддерживает комфортную температуру. Но что произойдет, если в системе возникнет нештатная ситуация? Как поведет себя умный дом, если прорвет трубу, пропадет электричество или откажет интернет? Ответы на эти вопросы дает стресс-тестирование — финальный и самый важный этап проверки системы перед сдачей объекта клиенту.

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

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

Проведение таких «учений» преследует три главные цели:

  • Техническая верификация: Удостовериться, что сценарии экстренного реагирования, разработанные на этапе проектирования (например, `SCN-SAFETY-001`), работают так, как задумано, и физическое оборудование (краны, ИБП) отрабатывает команды корректно.
  • Повышение надежности: Выявить скрытые уязвимости, узкие места и логические ошибки, которые проявляются только при экстремальных нагрузках или сбоях.
  • Формирование доверия клиента: Наглядная демонстрация того, что система не просто «умная», но и «надежная», способна защитить имущество и обеспечить безопасность даже в форс-мажорных обстоятельствах. Отчет об успешно пройденных стресс-тестах — мощный аргумент при сдаче объекта.

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

    [ ] Физическое отключение сетевого кабеля/Wi-Fi точки доступа.*

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

    [ ] Генерация локального тревожного оповещения об обрыве связи.*

    Сценарий 'Потоп': имитация протечки и проверка реакции системы

    ценарий 'Потоп': имитация протечки и проверка реакции системы

    Сценарий 'протечка' — это классический пример теста, демонстрирующего реальную пользу умного дома. Цель — проверить, что при срабатывании датчика протечки система автоматически перекроет воду и уведомит владельца, предотвратив значительный ущерб.

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

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

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

  • Физическая имитация (предпочтительный метод):

    • * Проводной датчик: Используя перемычку, кратковременно замкните контакты на самом датчике или на клеммах `UI` (универсальный вход) и `GND` контроллера, к которым он подключен. Это полностью имитирует физическое замыкание контактов водой.

    * Беспроводной датчик (Zigbee/LoRaWAN): Если используется беспроводной датчик, самый простой способ — аккуратно намочить его контакты влажной тканью. Это тестирует всю цепочку, включая беспроводной протокол.

  • Программная имитация (для отладки логики):

    • Этот метод полезен на этапе разработки, когда физическое оборудование еще не смонтировано. Как мы рассматривали в уроке `COURSE-07-M09-L03`, можно отправить тестовое MQTT-сообщение, которое имитирует сигнал от датчика.

    Для этого подключитесь к MQTT-брокеру контроллера HI и отправьте в соответствующий топик сообщение, соответствующее "Контракту сообщения".

    Пример `msg.payload` для симуляции через MQTT:

        {
    

          "value": true,
    

          "source": "leak_sensor_bathroom_01_simulated",
    

          "ts": 1678886400000,
    

          "meta": {
    

            "test_id": "COURSE-07-M09-LAB-01"
    

          }
    

        }

    * Топик: `telemetry/sensors/leak/bathroom_01`

    * `value: true` сигнализирует о сработке (протечке).

    * `source` содержит идентификатор, указывающий, что это симуляция.

    Чек-лист: Ожидаемая цепочка событий и проверка реакции

    После имитации сработки датчика, вы должны в реальном времени отследить и задокументировать следующую последовательность действий системы по чек-листу:

    * Идентифицировать зону протечки.

    * Сформировать команду на закрытие соответствующих шаровых кранов с электроприводом.

    [ ] 3. Отправка команды на исполнительное устройство: Узел `Modbus-Write` отправляет команду на закрытие крана на вводе холодной и горячей воды. Адрес устройства и регистры должны соответствовать проекту. Например, для крана с адресом `15`, команда на закрытие может быть записью `1` в Holding Register `40100`.* * Физическое перекрытие воды: Подойдите к крану и визуально убедитесь, что он закрылся. Попробуйте открыть кран с горячей или холодной водой в ближайшем смесителе — вода течь не должна.

    * Отправка уведомлений: Проверьте свой смартфон. Вы должны получить push-уведомление (например, через Telegram) и SMS-сообщение (если настроен GSM-модем) с текстом вида: `«ВНИМАНИЕ! Протечка в санузле №1. Вода перекрыта.»`.

    * Запись в лог: Проверьте системный журнал (например, таблицу `audit_log` в MySQL на контроллере). Должна появиться запись с уровнем `CRITICAL`, содержащая информацию о событии, источнике и предпринятых действиях.

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

    Возврат в нормальное состояние (Снятие блокировки / Override)

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

  • Устранение причины: Уберите перемычку (или высушите контакты беспроводного датчика). Убедитесь, что сигнал в MQTT/Node-RED сменился на `value: false`.
  • Проверка блокировки авто-открытия: Система не должна автоматически открывать краны после высыхания датчика. Это грубое нарушение безопасности (труба могла лопнуть, и вода просто стекла, датчик высох).
  • Ручной сброс (Override аварии): Открытие кранов должно происходить только после явного и осознанного действия пользователя. Проверьте, что кнопка «Сброс аварии» в дашборде управления или физическая аппаратная кнопка на щите снимает программную блокировку, возвращая систему в дежурный режим и позволяя вновь открыть краны водоснабжения.

    • > ⚠️ Обратите внимание: Если любой из шагов чек-листа или процесса ручного сброса не выполнен штатно, тест считается проваленным. Необходимо немедленно перейти к диагностике, начиная с анализа логов Node-RED и статусов узлов внутри потока обработки аварии.

    Сценарий 'Blackout': тестирование перехода на резервное питание

    ценарий 'Blackout': тестирование перехода на резервное питание

    Сценарий 'отключение питания' (`Blackout`) — один из самых важных тестов, который проверяет "живучесть" всей системы в случае пропажи городского электроснабжения. Его цель — убедиться, что резервное питание (ИБП) включается корректно, а система автоматизации адекватно реагирует на это, отключая второстепенные нагрузки для экономии заряда батарей.

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

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

  • Подготовка: Предупредите клиента о предстоящем отключении. Убедитесь, что ИБП полностью заряжен и находится в рабочем состоянии. Подготовьте мультиметр для контроля напряжений.
  • Имитация отключения: В главном распределительном щите объекта найдите вводной автоматический выключатель, который отвечает за подачу питания от городской сети. Аккуратно переведите его в положение «Выкл.». Это полностью имитирует ситуацию "Blackout".
  • Мониторинг перехода на ИБП:

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

    * Критически важное оборудование (контроллер HI, роутер, коммутаторы, камеры видеонаблюдения), подключенное к ИБП, должно продолжить работать без перезагрузки.

    * Проверьте статус ИБП через интерфейс мониторинга. Если ИБП подключен к контроллеру по Modbus или SNMP, в Node-RED должен немедленно прийти сигнал об изменении его статуса (`On Battery`). Это событие является триггером для запуска сценария энергосбережения.

    Анализ работы логики энергосбережения (Чек-лист)

    Как только контроллер HI определил, что система перешла на питание от ИБП, он должен запустить специальный сценарий (`SCN-POWER-SAVE-001`), который выполняет следующие действия. Используйте этот чек-лист для проверки:

    * Системы электрического теплого пола.

    * Кондиционеры и системы вентиляции (кроме критически важных серверных/кроссовых).

    * Декоративная подсветка, ландшафтное освещение.

    * Бойлеры, полотенцесушители.

    * Розетки, питающие мультимедийное оборудование (телевизоры, аудиосистемы).

    * Контроллер автоматизации HI.

    * Сетевое оборудование (роутер, коммутаторы, точки доступа Wi-Fi).

    * Система безопасности (камеры, датчики движения, сирена, СКУД).

    * Аварийное освещение (обычно это 1-2 светильника в ключевых зонах, часто переведенные на минимальную яркость).

    * Приводы ворот и электронные замки.

    * Система должна определить появление городского напряжения.

    * ИБП должен перейти в штатный режим работы.

    * Контроллер HI должен вернуть все ранее отключенные нагрузки в состояние, которое было до теста (или в соответствии с текущими сценарными условиями и расписанием). Протоколируйте корректность этого этапа.

    Возможные ошибки при тестировании

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

    Сценарий 'Network Down': проверка автономности локальных сегментов

    ценарий 'Network Down': проверка автономности локальных сегментов

    Современный умный дом сильно зависит от сети: MQTT, Wi-Fi, Ethernet. Но что произойдет, если роутер "зависнет" или будет поврежден кабель? Цель теста 'Network Down' — проверить автономность сегментов системы и убедиться, что базовые функции продолжают работать даже при полном отказе центральной сетевой инфраструктуры.

    Способы имитации

    Выберите один из наиболее подходящих для вашего объекта способов имитации отказа сети:

  • Отключение WAN: Отключите кабель от интернет-провайдера от вашего роутера. Это самый "мягкий" тест, который проверяет реакцию системы на пропажу доступа в интернет. Облачные интеграции (голосовые ассистенты, погодные сервисы) должны перестать работать, но вся локальная автоматизация обязана функционировать.
  • Отключение контроллера от сети: Физически отключите Ethernet-кабель от контроллера HI. Это симулирует локальный сбой порта на коммутаторе или повреждение кабеля.
  • Отключение питания коммутатора/роутера: Это самый жесткий сценарий, имитирующий полный отказ центрального сетевого узла. Все Ethernet- и Wi-Fi-устройства теряют связь друг с другом.

    • Тестирование "живучести" прямых связей

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

    * Modbus RTU (RS-485): Попробуйте управлять конвектором или вентиляцией с локального настенного термостата, если они оба подключены к одной шине RS-485 на контроллере. Эта связка должна работать безупречно, так как обмен данными идет по выделенной физической линии.

    * DALI: Включите свет с настенного выключателя, подключенного к DALI-шине. Если выключатель и светильник находятся на одной шине, свет должен включиться.

    * 1-Wire: Данные с датчиков температуры должны продолжать считываться контроллером.

    * Нажмите на кнопку, подключенную к дискретному входу контроллера. Реле, подключенное к выходу этого же контроллера, должно сработать. Эта логика (In -> Logic -> Out) не требует сети и должна быть 100% автономной.

    Анализ деградации системы

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

    > 💡 Информация: Именно поэтому для критических уведомлений (протечка, пожар) необходимо дублирование через автономный канал, например, GSM-модем, установленный в контроллере HI.

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

    Чек-лист проверки при 'Network Down'

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

    Документирование 'учений': протокол испытаний и отчет для клиента

    окументирование 'учений': протокол испытаний и отчет для клиента

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

    > 🔗 Связанный материал: Подробный шаблон Тест-плана, который является основой для данного урока, рассмотрен в уроке «Разработка Тест-плана сдачи объекта». Используйте его как чек-лист для проведения учений.

    Сценарий Network Down и проверка Safe-State

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

    > 🔗 Связанный материал: Подробная настройка этого механизма разбиралась в уроке M04-L05 «Отказоустойчивость: аппаратные watchdog и Safe-state».

    В чек-лист проведения испытаний обязательно добавьте следующие пункты для стресс-теста Network Down:

    Формат протокола испытаний

    Для документирования результатов удобно использовать простую таблицу. Она может быть создана в Excel, Google Sheets или прямо в вашей системе управления проектами.

    | ID теста | Время начала/конца | Имитируемое событие | Ожидаемый результат | Фактический результат | Статус | Примечания |

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

    | ST-01 | 10:15 / 10:17 | Протечка в санузле №1 (физическое замыкание датчика) | 1.Краны ГВС/ХВС закрыты.
    2.Push-уведомление получено.
    3.SMS получено.
    4.Запись в логе `CRITICAL`. | 1.Краны закрылись (визуально и по факту).
    2.Push пришло через 5 сек.
    3.SMS пришло через 45 сек.
    4.Запись в `audit_log` присутствует. | OK | Задержка SMS связана с оператором связи. |

    | ST-02 | 10:30 / 10:40 | Отключение вводного автомата (Blackout) | 1.ИБП перешел на батареи.
    2.Теплые полы (3 зоны) отключились.
    3.Контроллер и роутер работают.
    4.Push-уведомление о сбое питания. | 1.ИБП перешел штатно.
    2.Полы отключились.
    3.Оборудование работает.
    4.Push не пришло. | NOK | Проблема с доступом в интернет после перехода на ИБП. Роутер получает питание, но не может установить сессию. |

    | ST-03 | 11:00 / 11:05 | Отключение питания сетевого коммутатора (Network Down) | 1.Свет (DALI) управляется с выключателей (KNX).
    2.Сценарий "ушел из дома" не работает.
    3.Мобильное приложение не подключается.
    4.Актуаторы переходят в Safe-State. | 1.Связка KNX-DALI работает.
    2.Сценарий не запустился.
    3.Приложение не работает.
    4.Клапаны отопления открылись на 15% (Safe-State). | OK | Автономность локального сегмента освещения подтверждена. Механизм Safe-State отработал корректно. |

    Формирование итогового отчета

    На основе заполненного протокола формируется итоговый отчет для клиента.

  • Резюме: Краткое описание проведенных тестов и общий вывод (например, "Система продемонстрировала высокую степень отказоустойчивости. Критические сценарии безопасности и жизнеобеспечения отработали штатно...").
  • Детальные результаты: Приложите заполненную таблицу протокола. Для всех тестов со статусом `NOK` (Not OK) обязательно добавьте раздел "План корректирующих действий" с описанием того, как и в какие сроки будет устранена выявленная проблема.
  • Демонстрация: Продемонстрируйте клиенту самые наглядные тесты (например, 'Потоп'). Это производит сильное впечатление и снимает многие вопросы о целесообразности вложений в качественную систему автоматизации.

    • Успешное прохождение комплекса стресс-тестов и предоставление подробного отчета — это финальный штрих, подтверждающий ваш профессионализм и качество выполненной работы.

    Что дальше?

    В этом уроке мы научились проверять систему на прочность, имитируя реальные аварийные ситуации. Мы убедились, что надежность — это не случайность, а результат тщательного проектирования и всестороннего тестирования. Теперь, вооружившись знаниями о проектировании сложных сценариев, их реализации и методах проверки отказоустойчивости, вы готовы к главному испытанию. В следующем уроке, Финальном проекте (Capstone Project), вам предстоит объединить все навыки, полученные в курсе, для создания комплексного проекта умного дома, который будет не только функциональным, но и по-настоящему надежным.