Проектирование аварийного режима (fail-safe): что делать, если датчик отказал?

Урок 5 · Датчики и входы: нормализация сигналов · 30 мин · theory

Введение в Fail-Safe: Зачем нужен план "Б"?

В предыдущих уроках этого модуля (COURSE-04-M07-L03 - L05) мы подробно рассмотрели, как реализовать watchdog-сценарий для обнаружения "мёртвых" датчиков. Мы научились добавлять временные метки к сообщениям, периодически проверять их актуальность с помощью узла `Trigger` и генерировать оповещения об отказе. Однако обнаружение проблемы — это лишь половина дела. Вторая, не менее важная половина — это правильная реакция на нее.

Fail-Safe (дословно "безопасный при отказе"), или аварийный режим, — это заранее спроектированное и реализованное поведение системы автоматизации в ответ на отказ одного из ее компонентов, чаще всего датчика или канала связи. Цель fail-safe — предотвратить опасные или нежелательные последствия, которые могут возникнуть, если система продолжит работать на основе устаревших или некорректных данных.

Важность fail-safe стратегии невозможно переоценить, поскольку она напрямую влияет на ключевые аспекты работы объекта:

Безопасность. Отказ датчика протечки, CO, или температуры в системе антиобледенения может привести к материальному ущербу или даже угрозе для жизни. Fail-safe сценарий в этих случаях должен быть безусловным и решительным (например, немедленно перекрыть клапан на выходе реле `RL-10` или включить принудительную вентиляцию).

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

Целостность оборудования. Представим систему поддержания давления в контуре отопления. Если датчик давления "завис" на нормальном значении, а в системе произошла утечка, подпиточный насос не включится. Это может привести к завоздушиванию системы и выходу из строя циркуляционного насоса. Fail-safe режим должен предотвращать такие ситуации.

При проектировании аварийного режима мы сталкиваемся с двумя основными типами отказов, которые требуют разных подходов к обработке:

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

| Датчик "офлайн" (Offline) | Датчик или канал связи полностью неработоспособны. Контроллер HI не получает от него никаких сообщений в течение определенного времени (тайм-аут). | Датчик температуры Modbus на шине RS-485 был физически отключен, или произошел обрыв кабеля. Watchdog-таймер сработал по истечении 60 секунд. | Watchdog-сценарий, как рассмотрено ранее. |

| Некорректные данные (Bad Data) | Датчик функционирует, отправляет данные, и они проходят по формату (например, являются числом), но сами значения выходят за рамки физически возможных. | Неисправный датчик температуры DS18B20 начинает присылать значение `-127` или `+85` градусов. Сообщение приходит, но данные бессмысленны. | Логическая валидация на входе потока. |

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

---

Стратегия 1: Замена на значения по умолчанию (Default Values)

Самая простая, надежная и распространенная fail-safe стратегия — это принудительная установка заранее определенного, безопасного значения для отказавшего параметра. Как только watchdog-сценарий фиксирует отказ датчика, система перестает доверять последнему полученному значению и вместо этого использует "значение по умолчанию".

> 💡 Подсказка: Значение по умолчанию — это не всегда "выключено" или "ноль". Для датчика CO2 в системе вентиляции лучшим fail-safe решением может быть не полное отключение, а перевод в циклический режим работы (например, 15 минут каждый час), чтобы обеспечить минимальный базовый воздухообмен. Для системы отопления безопасным значением будет не отключение котла зимой, а поддержание минимальной температуры теплоносителя, предотвращающей замерзание труб.

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

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

Практическая реализация в Node-RED

Рассмотрим классический пример: датчик протечки воды, подключенный к универсальному входу `UI-05` контроллера. Логика watchdog уже настроена и при отказе датчика (например, обрыве провода) отправляет в поток сообщение с сигналом тревоги. Наша задача — реализовать fail-safe логику, которая гарантированно закроет запорные клапаны на реле `RL-01` и `RL-02`.

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

// Вход - сообщение от watchdog-сценария
// Пример msg: { "payload": { "status": "FAILURE", "sensor_id": "leak-detector-kitchen" }}
[Link In: from_watchdog] --> [Switch: 'Is Failure?'] --+--> [Function: Set Fail-Safe Valve Command] --> [Link Out: to_valve_control]
                                                       |
                                                       +--> [Debug: 'Sensor OK'] (выход для штатных сообщений)

Логика работы:

`Link In`: Получает сообщение от watchdog-сценария.

`Switch`: Проверяет, является ли сообщение сигналом об отказе.

* `Property`: `msg.payload.status`

* `Rule`: `==` (string) `FAILURE`

* Все остальные сообщения идут на второй выход (штатная работа).

`Function` (Set Fail-Safe Valve Command): Это ядро нашей стратегии. Вместо простого `Change`-узла, мы используем `Function` для большей гибкости, логирования и установки статуса.

// Получаем ID отказавшего датчика из входящего сообщения
const failedSensorId = msg.payload.sensor_id;

// Проверяем, относится ли отказ к системе защиты от протечек
if (failedSensorId && failedSensorId.startsWith("leak-detector")) {

    // 1. Устанавливаем статус для визуальной диагностики
    node.status({
        fill: "red",
        shape: "dot",
        text: `FAIL-SAFE ACTIVE: Closing valves due to ${failedSensorId} failure`
    });

    // 2. Формируем сообщение по "Контракту сообщения" для управления клапаном
    // В данном случае, мы отправляем команду на закрытие (value: true)
    msg.payload = {
        value: true, // Команда на закрытие клапана
        source: "fail-safe-logic-M07-L01", // Источник - наша fail-safe логика
        ts: Date.now(),
        reason: `Failure of sensor ${failedSensorId}`
    };

    // 3. Устанавливаем топик для дальнейшей маршрутизации (если используется)
    // Например, для централизованного управления всеми клапанами
    msg.topic = "commands/valves/set_all";

    // 4. Отправляем сообщение на исполнение
    return msg;

} else {
    // Если это отказ другого датчика, игнорируем и не передаем сообщение дальше
    node.status({
        fill: "yellow",
        shape: "ring",
        text: `Ignoring failure of ${failedSensorId}`
    });
    return null;
}

Этот поток, будучи подключенным к выходу вашего watchdog-сценария, надежно реализует стратегию "Значение по умолчанию". В случае отказа датчика протечки, он не будет полагаться на его последнее состояние (которое могло быть "сухо"), а принудительно сформирует команду на закрытие клапанов, обеспечивая максимальную безопасность.

---

Стратегия 2: Резервирование и логика отката (Redundancy & Fallback)

В более критичных системах простой переход к значению по умолчанию может быть недостаточным. Например, в серверной или в инкубаторе требуется поддерживать температуру в узком диапазоне. Отказ датчика температуры и переход к "безопасному" значению (например, +18°C) может быть так же губителен, как и перегрев. Здесь на помощь приходит стратегия резервирования — использования альтернативного источника данных при отказе основного.

Существует два типа резервирования:

| Тип резервирования | Описание | Пример на платформе HI |

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

| Физическое резервирование | В одной точке устанавливаются два или более идентичных датчика, подключенных к разным входам контроллера. При отказе основного датчика система автоматически переключается на показания резервного. | В серверной устанавливаются два датчика температуры DS18B20. `TEMP-SRV-01` подключен к `UI-07`, `TEMP-SRV-02` — к `UI-08`. Система постоянно сравнивает их показания и при отказе одного из них, полностью доверяет второму. |

| Логическое резервирование (Fallback) | В качестве резервного источника используются данные другого типа или из другого места. Этот источник может быть менее точным, но его достаточно для поддержания базовой функциональности системы. | Уличный датчик температуры (Modbus) отказал. Система автоматизации отопления (погодозависимая) в качестве резерва начинает использовать данные о температуре, полученные от публичного онлайн-сервиса погоды через HTTP-запрос. |

Реализация иерархии источников данных

Для реализации логики отката нам необходим механизм, который будет хранить "приоритет" источников и текущие значения от них. Идеальным инструментом для этого является контекст Node-RED (`flow context`).

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

Источники данных по приоритету:

Основной: Уличный датчик Modbus (`outdoor_temp_modbus`).

Резервный: Онлайн-сервис погоды (`outdoor_temp_api`).

Алгоритм работы логики управления:

Два независимых потока постоянно опрашивают свои источники (Modbus и API) и сохраняют последние полученные значения в `flow.context`.

Watchdog-сценарии отслеживают оба этих источника. При отказе одного из них они устанавливают соответствующий флаг в `flow.context` (например, `flow.set('outdoor_temp_modbus_ok', false)`).

Основной поток управления климатом (который запускается, например, каждые 5 минут) не читает данные напрямую, а вызывает специальную `function`-ноду "Выбрать актуальную температуру".

Код для `function`-ноды "Выбрать актуальную температуру":

// Получаем статусы и значения из контекста потока
const isModbusOk = flow.get('outdoor_temp_modbus_ok') || false;
const isApiOk = flow.get('outdoor_temp_api_ok') || false;

let selectedTemp;
let source;

// Иерархия выбора:
// 1. Пытаемся использовать основной датчик Modbus
if (isModbusOk) {
    selectedTemp = flow.get('outdoor_temp_modbus');
    source = 'modbus';
} 
// 2. Если основной недоступен, пытаемся использовать резервный API
else if (isApiOk) {
    selectedTemp = flow.get('outdoor_temp_api');
    source = 'fallback_api';
} 
// 3. Если оба недоступны, используем крайнее безопасное значение
else {
    selectedTemp = 5; // Например, +5°C, чтобы не заморозить систему
    source = 'fail_safe_default';
}

// Проверяем, что значение корректно
if (typeof selectedTemp === 'number') {
    node.status({
        fill: "green",
        shape: "dot",
        text: `Using temp: ${selectedTemp}°C from ${source}`
    });

    // Формируем сообщение для дальнейшей логики управления отоплением
    msg.payload = {
        value: selectedTemp,
        unit: '°C',
        source: source,
        ts: Date.now()
    };
    return msg;

} else {
    // Критическая ситуация - нет никаких данных
    node.error("CRITICAL: No valid temperature source available!", msg);
    node.status({ fill: "red", shape: "dot", text: "No temp source!" });
    // Здесь может быть логика отправки SMS/Push администратору
    return null;
}

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

---

Стратегия 3: Ручное управление и информирование пользователя

В некоторых случаях, особенно для некритичных систем комфорта (управление светом, мультимедиа, шторами), лучшим и самым честным fail-safe решением является полное отключение автоматики и передача управления человеку. Попытка "угадать" правильное поведение может принести больше раздражения, чем пользы.

> ⚠️ Внимание: Отключая автоматизацию, убедитесь, что у пользователя остается простой и очевидный способ ручного управления. Если автоматика управляла реле `RL-15`, которое не подключено к физическому настенному выключателю, а управляется только по MQTT, то при отключении автоматики пользователь окажется в тупике. Fail-safe не должен создавать новые проблемы.

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

Практическая реализация в Node-RED

Рассмотрим отказ датчика освещенности в гостиной. По нему автоматически включался/выключался свет и закрывались шторы.

Алгоритм fail-safe:

Watchdog-сценарий фиксирует отказ датчика освещенности.

Запускается fail-safe поток, который устанавливает глобальный флаг: `global.set('automation.living_room.enabled', false)`.

Этот же поток отправляет push-уведомление (через MQTT на мобильное приложение) и email администратору с текстом: "Автоматическое управление светом и шторами в гостиной отключено. Датчик освещенности не отвечает более 5 минут."

Логика управления светом и шторами перед выполнением любого автоматического действия теперь обязана проверять состояние этого глобального флага.

ASCII-схема потока установки флага:

[Link In: from_watchdog_lux] --> [Switch: 'Is Failure?'] --> [Function: Set Global Flag & Notify] --+--> [MQTT Out: Push Notify]
                                                                                                  |
                                                                                                  +--> [Email Out: Admin Notify]

Код для `Function`-узла "Set Global Flag & Notify":

// Используем глобальный контекст, т.к. этот флаг может понадобиться
// нескольким разным потокам (управление светом, шторами и т.д.)
global.set('automation.living_room.enabled', false);

// Записываем причину и время отказа для диагностики
global.set('automation.living_room.fail_reason', 'Lux sensor timeout');
global.set('automation.living_room.fail_ts', Date.now());

// Устанавливаем статус для визуальной диагностики в Node-RED
node.status({
    fill: "red",
    shape: "dot",
    text: "Automation DISABLED for Living Room"
});

// Формируем сообщение для отправки пользователю
msg.payload = {
    user: "user_id_123",
    title: "Система автоматизации HI",
    message: "Автоматическое управление светом и шторами в гостиной отключено. Датчик освещенности не отвечает.",
    priority: 1 // Высокий приоритет уведомления
};

// Возвращаем сообщение для дальнейшей отправки
return msg;

Проверка флага в потоке управления светом:

Теперь поток, который раньше просто реагировал на уровень освещенности, усложняется.

Старый поток: `[Lux Sensor Data]` -> `[Logic]` -> `[Light Relay]` Новый, отказоустойчивый поток: `[Lux Sensor Data]` -> `[Switch: 'Is Automation Enabled?']` -> `[Logic]` -> `[Light Relay]`

Узел `Switch` настраивается на проверку глобальной переменной:

`Property`: `global.automation.living_room.enabled`
`Rule`: `is true`

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

---

Итоги: Проектирование отказоустойчивых систем

Fail-safe — это не дополнительная опция, а обязательная, неотъемлемая часть любого профессионального проекта автоматизации. Система, в которой не продуманы сценарии отказа, является неполной и потенциально опасной.

При проектировании аварийных режимов помните ключевые принципы:

Выбор стратегии диктуется критичностью. Чем выше риски, связанные с отказом, тем сложнее и надежнее должна быть fail-safe стратегия (от простого "значения по умолчанию" до полного физического резервирования).
Комбинированный подход. В рамках одного проекта для разных подсистем могут и должны применяться разные стратегии. Защита от протечек требует одной логики, а управление декоративной подсветкой — совершенно другой.
Информирование — ключ к успеху. Любое отклонение от штатного режима работы должно быть зафиксировано и доведено до сведения пользователя или администратора. Система не должна "молча" переходить в аварийный режим.

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

| Значение по умолчанию | При отказе принудительно устанавливается одно, заранее известное, безопасное значение. | Системы с четко определенным безопасным состоянием (клапаны, замки). | Низкая |

| Резервирование и откат | При отказе основного источника данных система переключается на резервный (физический или логический). | Критически важные системы, где требуется непрерывная работа (климат в серверной, медицинское оборудование). | Средняя / Высокая |

| Ручное управление и информирование | Автоматика полностью отключается, управление передается человеку, система отправляет уведомление. | Системы комфорта, где неверное автоматическое действие хуже, чем его отсутствие (свет, мультимедиа, шторы). | Средняя |

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

> 🔗 Связанный материал: В следующем модуле (COURSE-04-M08) мы рассмотрим процедуры восстановления системы после срабатывания аварийного режима и автоматического или ручного возврата к штатной работе после устранения неисправности.