Итоговый тест по Модулю 1: Введение в IoT

• Правильные ответы:

* 2-D: Универсальный вход используется для подключения оконечных устройств, таких как кнопки и датчики.

* 3-B: MQTT — это протокол обмена сообщениями по модели "издатель-подписчик".

* 4-A: Modbus RTU — это протокол для полевой шины RS-485.

• Оценка:

* 3 балла за 3 правильных сопоставления.

* 1 балл за 2 правильных сопоставления.

* 0 баллов за 1 или 0 правильных сопоставлений.

• Правильный ответ: C.
• Объяснение:

* Вариант B создаст "дребезг": вентиляция будет постоянно включаться и выключаться, как только уровень CO2 будет колебаться вокруг отметки 1000 ppm.

* Вариант C корректно реализует логику с гистерезисом (двумя порогами: 1000 ppm на включение и 800 ppm на выключение) и хранит текущее состояние системы. Это классический паттерн "Конечный автомат" (FSM), предотвращающий дребезг и обеспечивающий стабильную работу.

* Вариант D не содержит никакой логики, связанной с уровнем CO2.

• Оценка:

* 0 баллов за любой другой вариант.

• Правильные ответы:

2. датчиков / сенсоров / устройств ввода

3. исполнительными устройствами / нагрузками / актуаторами

4. Node-RED

• Оценка:

• Пример эталонного ответа:

1. Сценарий "Умное освещение": Автоматическое выключение света в помещениях (переговорные, коридоры) при отсутствии движения.

* Оборудование: Датчики движения (PIR), подключенные к универсальным входам (UI) контроллера. Группы освещения, подключенные к релейным выходам (RL).

* Логика: Если на входе UI нет сигнала от датчика движения в течение 10 минут, контроллер отключает соответствующий выход RL.

2. Сценарий "Контроль розеточных групп": Отключение питания розеток, к которым подключена некритичная офисная техника (мониторы, зарядные устройства), в нерабочее время (например, с 20:00 до 07:00 и по выходным).

* Оборудование: Розеточные группы, подключенные через контактор к релейному выходу (RL) контроллера.

* Логика: В Node-RED настраивается расписание (с помощью узла `Inject` или `cron-plus`), которое подает команду на отключение реле в 20:00 и включение в 07:00 в будние дни.

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

* Оборудование: Датчики присутствия (например, на базе PIR или CO2), подключенные к универсальным входам (UI) или по Modbus/MQTT. Управление климатическим оборудованием через релейные выходы (RL) (например, включение/выключение фанкойла) или по Modbus/DALI (для более точного управления).

* Логика: Если датчик присутствия не фиксирует активность в течение 30 минут, контроллер переводит систему климата в режим энергосбережения (например, снижает температуру на 2°C или отключает фанкойл).

• Критерии оценки:

* По 0.5 балла за каждое правильное указание задействованных входов/выходов.

* Максимум 4 балла.

* Снижение баллов: За неточности в описании, отсутствие привязки к оборудованию HI, нереалистичные сценарии.

• Пример эталонного ответа:

* msg.payload (JSON):

        {

            "value": 24.7,
            "unit": "°C",
            "source": "server_room_temp_sensor_ui01",
            "ts": 1678886400000 // Пример Unix timestamp в миллисекундах
        }
        

• Критерии оценки:

* 1 балл за наличие поля `value` с правильным типом данных.

* 1 балл за наличие поля `source` с уникальным идентификатором.

* 1 балл за наличие поля `ts` с корректным форматом Unix timestamp.

* Дополнительно (необязательно, но приветствуется): наличие поля `unit`.

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

• Пример эталонного ответа:

1. Причина: Неправильное физическое подключение RS-485. Перепутаны линии A/B, обрыв кабеля, плохой контакт.

* Диагностика: Визуальная проверка клемм A и B на контроллере и датчике. Проверка целостности кабеля мультиметром. Попытка поменять местами A и B на одной из сторон (это не повредит оборудованию, но часто решает проблему).

2. Причина: Несоответствие параметров COM-порта. Скорость (Baud Rate), четность (Parity), биты данных (Data Bits), стоп-биты (Stop Bits) на контроллере HI не совпадают с настройками датчика.

* Диагностика: Проверить документацию на датчик. Попробовать наиболее распространенные комбинации (например, 9600 8N1, 19200 8N1). Убедиться, что в Node-RED Modbus-Client настроен на правильный COM-порт (`/dev/ttyUSBx` или `/dev/ttySx`).

3. Причина: Неправильный Slave ID (Unit ID) датчика. В Node-RED указан ID, отличный от того, что настроен на датчике.

* Диагностика: Проверить Slave ID, установленный на датчике (DIP-переключатели, программная настройка). Убедиться, что этот же ID указан в узле `Modbus-Read` в Node-RED.

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

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

5. Причина: Отсутствие питания на датчике. Датчик не включен или не получает достаточного питания.

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

• Критерии оценки:

* Максимум 4 балла.

* Снижение баллов: За неточные или неполные описания, отсутствие методов диагностики.

• Пример эталонного ответа:

    // FLOW-LIGHT-BATH-001: Управление светом в ванной

    //
    // [rpi gpio in] - Узел для чтения состояния универсального входа UI-02
    // [Function]    - Узел для реализации логики переключения (триггер)
    // [rpi gpio out] - Узел для управления релейным выходом RL-01
    // [Debug]       - Узел для отладки и просмотра сообщений

    [rpi gpio in: UI-02] --(msg.payload: 1/0)--> [Function: Toggle Light] --(msg.payload: 1/0)--> [rpi gpio out: RL-01]
                                                                                                        |
                                                                                                        v
                                                                                                     [Debug]
    

Код для узла `Function: Toggle Light`:

    // Сохраняем текущее состояние света в контексте потока

    // Инициализируем состояние, если его нет (например, при первом запуске)
    let currentState = flow.get('bathroomLightState') || 0; // 0 = выключен, 1 = включен

    // Если пришло сообщение от выключателя (UI-02)
    if (msg.payload === 1) { // Предполагаем, что 1 - это нажатие/замыкание
        // Переключаем состояние
        currentState = 1 - currentState; // Если было 0, станет 1; если было 1, станет 0
        flow.set('bathroomLightState', currentState); // Сохраняем новое состояние

        // Отправляем команду на реле
        msg.payload = currentState;
        return msg;
    }
    // Если msg.payload не 1, игнорируем (например, отпускание кнопки)
    return null;
    

• Критерии оценки:

* 1 балл за использование узла `Function` для реализации логики переключения (toggle).

* 1 балл за корректное использование узла `rpi gpio out` для управления реле.

* 1 балл за общую логическую связность и читаемость схемы.

* Снижение баллов: За отсутствие узла `Function` (если логика реализована только через `Switch`, что менее эффективно для toggle), неверные типы узлов, отсутствие указания входов/выходов.