Modbus → MQTT/REST для диспетчеризации: границы ПНР, шлюзы и offline

1. Зачем мост Modbus → MQTT / REST
2. Границы ответственности ПНР
3. Архитектура шлюза: что должно быть в проекте
4. MQTT: топики, QoS, retain, Last Will
5. REST: опрос, запись, коды ответа
6. Offline, буфер и качество данных
7. Приёмочные сценарии
8. Чек-лист ПНР шлюза Modbus–MQTT/REST

Диспетчеризация часто забирает данные с полевых устройств Modbus RTU/TCP через шлюз в MQTT-брокер или REST API верхнего уровня (SCADA, облако, IoT-платформа). Инженер ПНР должен чётко понимать, где заканчивается полевая шина и где начинается IT-интеграция: иначе «не видит MQTT» лечат перестановкой A/B на RS-485, а обрыв брокера маскируют как неисправность счётчика. Ниже — границы ПНР, типовые проверки шлюза и сценарии offline.

1. Зачем мост Modbus → MQTT / REST

• MQTT — лёгкий publish/subscribe поверх TCP; удобен для потоковой телеметрии и событий.
• REST — запрос/ответ по HTTP(S); удобен для чтения среза точек, записи уставок, интеграции с системами без MQTT-клиента.
• Шлюз скрывает адреса slave и карты регистров за единым информационным контрактом (топики / JSON-ресурсы).

На объекте оба интерфейса могут сосуществовать: MQTT для трендов, REST для команд и отчётов — строго по проекту.

2. Границы ответственности ПНР

3. Архитектура шлюза: что должно быть в проекте

• Таблица точек: slave ID / IP, function code, адрес регистра, тип данных, масштаб, единица, имя топика или REST path.
• Период опроса и таймаут; приоритет критичных точек.
• Параметры брокера: host, port, clientId, TLS да/нет, QoS.
• Политика записи (write): разрешённые уставки, роли, подтверждение.
• Поведение offline: буфер, retain, флаг качества / stale.

Без таблицы точек приёмка превращается в спор «а этот JSON что значит».

4. MQTT: топики, QoS, retain, Last Will

• Топики — иерархия по проекту (объект/зона/устройство/параметр); не плодите «test/123» в проде.
• QoS 0/1/2 — по ТЗ; для телеметрии часто QoS 0 или 1; не поднимайте QoS «на всякий» без оценки нагрузки.
• Retain — последний снимок для поздних подписчиков; согласуйте, нужен ли для аварийных флагов.
• Last Will (LWT) — сообщение при обрыве клиента шлюза; удобно для аварии «шлюз offline» в SCADA.

5. REST: опрос, запись, коды ответа

• GET среза точек / одной точки — сверка значения с локальным опросом Modbus.
• PUT/POST уставки — только разрешённые; проверка, что значение дошло до регистра устройства.
• Коды 401/403/404/503 — ожидаемое поведение при ошибках auth / отсутствия точки / перегруза; зафиксируйте в протоколе.
• HTTPS и токены — по политике ИБ; ПНР не хранит пароли в открытых отчётах.

6. Offline, буфер и качество данных

Три разных offline:

1. Поле недоступно — шлюз не читает slave; в MQTT/REST должен быть явный bad/stale/quality, а не «застывшее хорошее» значение без метки времени.
2. Брокер недоступен — шлюз буферизует (если заложено) или теряет телеметрию по политике ТЗ; LWT/авария связи.
3. Потребитель отписался — publish идёт, но SCADA не подписана; это конфиг верхнего уровня.

На ПНР обязательно прогоните сценарий обрыва Ethernet к брокеру и обрыва RS-485/TCP к полю — с фиксацией отображаемого качества.

7. Приёмочные сценарии

1. Выборка точек: изменение на поле → обновление в MQTT/REST с допустимой задержкой ТЗ.
2. Запись уставки (если разрешена) → подтверждение чтением регистра.
3. Kill link к slave → quality bad / авария.
4. Kill link к брокеру → LWT / буфер / авария шлюза по ТЗ.
5. Восстановление связи → данные актуальны, нет «залипших» retain-аварий без причины (по методике очистки).
6. Резервная копия конфига шлюза передана заказчику.

8. Чек-лист ПНР шлюза Modbus–MQTT/REST

Шлюз сдают как цепочку поле→маппинг→транспорт с явным качеством данных. Разделяйте неисправность RS-485, конфиг шлюза и доступность MQTT-брокера — иначе ПНР затягивается в чужую IT-зону без результата.