Подготовка к сертификации CERT-INSTALLER

Введение в сертификацию CERT-INSTALLER

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

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

Обзор проверяемых компетенций

Экзамен CERT-INSTALLER комплексно проверяет знания в следующих ключевых областях:

• Электротехника и безопасность: Глубокое понимание принципов работы защитной автоматики, правильный выбор сечений кабеля, знание процедур проверки УЗО и заземления, которые были подробно рассмотрены в предыдущих уроках этого модуля.
• Физическое развертывание: Практические навыки монтажа оборудования в щите, прокладки и заделки кабелей, корректного подключения датчиков и исполнительных устройств к клеммам контроллера HI. Применяются стандарты, описанные в уроке `Стандарты схем подключения`.
• Протоколы и шины данных:

* MQTT: Понимание архитектуры "брокер-клиент", структуры топиков, уровней качества обслуживания (QoS) и механизма `retained-сообщений`.

* 1-Wire, DALI, CAN: Базовые знания о топологии, подключении и принципах работы этих шин.

• Платформа HI и Node-RED: Уверенное владение интерфейсом Node-RED, умение создавать потоки для решения типовых задач, использовать базовые узлы (`Inject`, `Debug`, `Switch`, `Change`, `Function`), работать с контекстными переменными и применять паттерны проектирования, включая "Контракт сообщения" и "Обработку ошибок".
• Основы Linux: Способность работать в командной строке контроллера для базовой диагностики сети, проверки статуса служб и просмотра логов.

Структура экзамена

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

| Компонент | Формат | Длительность | Проходной балл | Ключевые критерии оценки |

| ----------------------- | -------------------------------------------------------------------------------------- | ------------ | -------------- | -------------------------------------------------------------------------------------------------------------------- |

| Теоретический экзамен | Компьютерный тест: вопросы с выбором одного/нескольких ответов, "верно/неверно". | 60 минут | 80% | Знание протоколов, архитектуры платформы, правил безопасности, методологии диагностики. |

| Практический экзамен | Выполнение заданий на реальном или виртуальном стенде, имитирующем объект автоматизации. | 120 минут | 90% | Корректность настройки оборудования, работоспособность созданной логики, чистота кода, следование стандартам. |

Требования к кандидату

Для успешной сдачи экзамена кандидат должен обладать не только теоретическими знаниями, полученными в рамках курсов уровня Foundation и Installer, но и реальным практическим опытом. Рекомендуется перед записью на экзамен:

---

Теоретическая часть: Формат и примеры вопросов

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

> 💡 Подсказка: Обратите особое внимание на вопросы, связанные с отладкой. Например, 'Почему `msg.payload` не доходит до следующей ноды?' или 'Какая команда Linux покажет открытые порты?'. Экзамен проверяет не только знание "как сделать", но и понимание "почему не работает".

Разбор типовых форматов вопросов

• Multiple-choice (один правильный ответ): Классический вопрос с 4-5 вариантами, из которых верным является только один.
• Multiple-response (несколько правильных ответов): Вопрос, где необходимо отметить все верные утверждения.
• True/False (верно/неверно): Утверждение, которое нужно оценить как истинное или ложное.
• Matching (сопоставление): Задания на установление соответствия между элементами двух списков (например, "протокол - стандартный порт").

Примеры вопросов по MQTT

* A) Ничего, сообщение уже устарело.

* B) Клиент немедленно получит сообщение с `payload="ON"`.

* C) Брокер отправит ошибку, так как флаг `retained` используется только с QoS 2.

* D) Клиент получит сообщение, только если исходный издатель все еще в сети.

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

* [ ] QoS 0 (At most once)

* [ ] QoS 1 (At least once)

* [ ] QoS 2 (Exactly once)

Правильные ответы: B, C

Примеры вопросов по Node-RED

    {

      "topic": "sensor/temp/room1",
      "payload": 25.5
    }
    

В узле `Function` выполняется следующий код:

    msg.payload = {

        value: msg.payload,
        ts: Date.now()
    };
    msg.topic = "telemetry/temperature";
    return msg;
    

Какова будет структура `msg.payload` на выходе из узла?

* A) `25.5`

* B) `{"value": 25.5}`

* C) `{"value": 25.5, "ts": 1678886400000}` (с реальной временной меткой)

* D) Произойдет ошибка, так как `msg.topic` нельзя изменять.

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

* A) Для перехвата только сообщений с определенным `msg.topic`.

* B) Для перехвата и обработки ошибок, возникающих в других узлах на той же вкладке.

* C) Для сохранения сообщений в кэше.

* D) Для запуска потоков по расписанию.

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

Примеры вопросов по Modbus

* A) Адрес: 101, FC: 4 (Read Input Registers)

* B) Адрес: 40101, FC: 3 (Read Holding Registers)

* C) Адрес: 100, FC: 3 (Read Holding Registers)

* D) Адрес: 100, FC: 1 (Read Coils)

Правильный ответ: C (Адресация с 0, поэтому 40101 -> 100. Holding Registers читаются функцией 3)

* A) Modbus RTU использует TCP/IP, а Modbus TCP - последовательный порт.

* B) Modbus RTU работает поверх физического уровня RS-485/RS-232, а Modbus TCP - поверх сетей Ethernet (TCP/IP).

* C) В Modbus RTU нет проверки целостности данных, в отличие от Modbus TCP.

* D) Modbus TCP не требует указания адреса устройства (Unit ID).

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

---

Практическая часть: типовые задания на стенде

Практический экзамен — это симуляция реальной пусконаладки на объекте. Вам будет предоставлен доступ к контроллеру HI и набору периферийного оборудования (либо их эмуляторам). Ваша задача — за ограниченное время выполнить несколько заданий, продемонстрировав умение "оживить" систему.

> ⚠️ Внимание: Частая ошибка на практическом экзамене — неверная настройка сетевых интерфейсов в Linux или неправильное терминирование шины RS-485. Всегда проверяйте физическое подключение и базовые сетевые настройки перед тем, как искать ошибку в Node-RED.

Описание типового экзаменационного стенда

• Контроллер: Платформа HI (Linux Debian, Node-RED, 4 ядра, 4 ГБ RAM).
• Исполнительные устройства: Модуль с 4 реле, подключенными к контроллеру, для управления нагрузками (лампы, небольшой двигатель).
• Устройства Modbus RTU: Счетчик электроэнергии (например, Меркурий 206) и датчик температуры/влажности, подключенные к шине RS-485.
• Устройства Modbus TCP: IP-реле или шлюз с несколькими выходами.
• Датчики: Датчик движения с выходом "сухой контакт" и кнопка, подключенные к универсальным входам контроллера.

Задание 1 (пример): Настроить опрос Modbus RTU устройства и передать показания по MQTT

* Использовать узел `Inject` для запуска опроса каждые 30 секунд.

* Добавить узел `Modbus-Getter`. Настроить его на `Slave ID = 50`, `FC 4: Read Input Registers`, адрес `272` (0x0110) и количество `2`.

* Добавить узел `Function` для обработки ответа. В нем:

* Проверить, что ответ получен (`msg.payload.data` существует и является массивом).

* Собрать 32-битное число из двух 16-битных регистров с учетом порядка байт `little-endian`.

* Сформировать `msg.payload` в соответствии с паттерном "Контракт сообщения".

        // Пример кода для узла Function

        if (!msg.payload.data || msg.payload.data.length < 2) {
            node.error("Неполный ответ от счетчика", msg);
            return null;
        }

        // буфер из Modbus-узла приходит в big-endian
        const buffer = Buffer.from(msg.payload.buffer);
        // Читаем как Unsigned Integer, Little Endian, 32-bit
        const energy_wh = buffer.readUInt32LE(0); 

        msg.topic = "premise/1/powermeter/energy";
        msg.payload = {
            value: energy_wh,
            unit: "Wh",
            source: "powermeter-mercury-206",
            ts: Date.now()
        };
        return msg;
        

* Подключить выход узла `Function` к узлу `mqtt out` с настроенным топиком.

* Настроить узел `Catch` для логирования ошибок связи.

Задание 2 (пример): Реализовать логику управления освещением через MQTT-шлюз

// Включение
{ "target": "light_group_main", "command": "ON" }
// Выключение
{ "target": "light_group_main", "command": "OFF" }

* Использовать узел `mqtt in`, подписанный на топик `remote/1/command`. Установить `Output: a parsed JSON object`.

* Добавить узел `Switch` для фильтрации сообщений по `msg.payload.target == "light_group_main"`.

* К выходу узла `Switch` подключить еще один `Switch`, который будет маршрутизировать поток в зависимости от `msg.payload.command` ("ON" или "OFF").

* К выходу "ON" подключить два узла `Change`, которые устанавливают `msg.payload` в `true`.

* К выходу "OFF" подключить два узла `Change`, которые устанавливают `msg.payload` в `false`.

* От каждого узла `Change` направить поток на соответствующий узел управления реле (например, `rpi gpio out`, настроенный на реле 3 и 4).

* Усложнение/бонусный балл: реализовать отправку ответного сообщения в топик `remote/1/command/result` о статусе выполнения команды.

Задание 3 (пример): Написать bash-скрипт для мониторинга доступности IP-шлюза

    #!/bin/bash


    GATEWAY_IP="192.168.1.100"
    CHAT_ID=""
    BOT_TOKEN=""
    MESSAGE="Внимание! Шлюз по адресу $GATEWAY_IP недоступен."
    URL="https://api.telegram.org/bot$BOT_TOKEN/sendMessage"

    # Проверяем доступность устройства, отправляя один ICMP-пакет
    # с таймаутом в 2 секунды. Вывод команды подавляем.
    ping -c 1 -W 2 $GATEWAY_IP > /dev/null 2>&1

    # Проверяем код возврата команды ping
    # 0 - успех, любое другое значение - ошибка
    if [ $? -ne 0 ]; then
        # Если шлюз недоступен, отправляем сообщение в Telegram через curl
        curl -s -X POST $URL -d chat_id=$CHAT_ID -d text="$MESSAGE" > /dev/null
    fi