MQTT против HTTP против Modbus TCP против OPC UA для промышленных IoT-шлюзов

Быстрый ответ

Одни и те же данные датчиков могут быть доставлены разными способами

Датчик не определяет окончательное облако или протокол SCADA. RS485 Modbus RTU обычно используется на полевом уровне, в то время как шлюз преобразует или переупаковывает эти данные для прикладного уровня. Правильный восходящий протокол зависит от того, кто инициирует связь, где хранятся данные, должны ли команды возвращаться на устройство и какое программное обеспечение уже использует клиент.

MQTT: лучший вариант для облачных систем публикации/подписки

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

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

Публикация и подписка не должны путаться

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

MQTTS и порт 8883

MQTTS обычно означает MQTT поверх TLS. Порт 8883 — это обычный порт TLS, но успешное использование зависит не только от номера порта. Библиотека TLS, метод проверки ЦС, сертификат сервера, дополнительный сертификат клиента и версия MQTT должны быть совместимы. При реальном тестировании в стороннем облаке шлюз может иногда подключаться к одному брокеру TLS, но не работать с другим, пока не будет обновлено встроенное ПО.

Для производственных проектов перед отправкой большой партии проверьте конкретного брокера, режим сертификата и встроенное ПО. Сертификаты должны исходить от сервера клиента или облачной платформы или соответствовать им; это не общие файлы, которые производитель шлюза может создать независимо от сервера.

HTTP POST: лучше всего, когда у клиента есть конечная веб-точка

HTTP часто является самым простым вариантом, когда у клиента есть серверное приложение, которое может получать запросы POST. Шлюз можно настроить как HTTP-клиент и периодически отправлять JSON на целевой URL-адрес. Это подходит для пользовательских веб-серверов и сред, где команда разработчиков программного обеспечения предпочитает прямую обработку запросов/ответов вместо использования брокера MQTT.

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

Modbus TCP: лучше всего, когда SCADA или PLC должны опрашивать данные

Modbus TCP использует знакомую модель регистров Modbus через Ethernet. Это часто подходит, когда система PLC, HMI или SCADA уже спроектирована как ведущее устройство Modbus. Шлюз может соединять устройства RS485 Modbus RTU со стороной Ethernet или предоставлять собранные значения через определенную карту регистров.

Если клиент говорит: «Дайте нам IP-адрес и сообщите, где хранится каждый сигнал; наша система его прочитает», Modbus TCP обычно ближе к требуемой архитектуре, чем MQTT или HTTP.

OPC UA: лучшее решение для более глубокой промышленной интеграции

OPC UA широко используется в промышленном программном обеспечении, поскольку он может представлять данные в виде именованных тегов или узлов со структурой и метаданными, а не только в виде числовых адресов регистров. Он может хорошо подойти для SCADA, промышленного промежуточного программного обеспечения и приложений ПК, которым требуется стандартизированное поведение обнаружения и подписки.

Не каждый шлюз поддерживает OPC UA в одной и той же роли, поэтому проверьте, действует ли он как сервер OPC UA, клиент или и то, и другое. В проектах NiuBoL предпочтительны более функциональные пограничные шлюзы, когда OPC UA является основным требованием.

Какой протокол выбрать?

Не путайте полевой протокол и восходящий протокол

Система может одновременно использовать RS485 Modbus RTU от датчиков к шлюзу и MQTT от шлюза к облаку. Он также может использовать датчики 4–20 мА в шлюзе ADC, а затем передавать эти значения через Modbus TCP или OPC UA. Полевой интерфейс и протокол приложения представляют собой отдельные уровни проектирования.

Устранение неполадок: MQTT подключен, но нет данных

1. Убедитесь, что уровень датчика действительно генерирует данные внутри шлюза.
2. Проверьте интервал загрузки и убедитесь, что шлюз публикует данные, а не только подключен.
3. Точно проверьте тему публикации, включая начальные косые черты и чувствительность к регистру, если брокер/платформа обрабатывает их по-разному.
4. Используйте независимый клиент MQTT, чтобы подписаться на ту же тему и изолировать шлюз от бизнес-платформы.
5. Проверьте аутентификацию, конфликты идентификаторов клиентов и использует ли другой клиент те же учетные данные.
6. Для TLS проверьте совместимость сертификатов CA/сервера и библиотек встроенного ПО.
7. Используйте журналы шлюза и, при необходимости, захват сети, чтобы определить, покидают ли устройство пакеты и как на это реагирует сервер.

Устранение неполадок: HTTP-сервер ничего не получает

Первое отдельное получение от загрузки. Если в журнале шлюза указано, что нижнее устройство не отвечает, исправьте уровень связи датчика перед отладкой сервера. Затем проверьте целевой URL-адрес, порт, доступность DNS/сети, тип контента, формат JSON и требования HTTPS. Функция HTTP шлюза в этой архитектуре — это клиент, который активно отправляет данные POST; он не является автоматически HTTP-сервером для просмотра клиентом.

FAQ

Вопрос 1. MQTT лучше HTTP для IoT?

А1. Ни то, ни другое не лучше в целом. MQTT хорош для групп публикации/подписки; HTTP прост, если у клиента уже есть конечная точка веб-приема.

В2. Означает ли MQTT «онлайн» что платформа получила данные датчиков?

А2. Нет. Статус онлайн только подтверждает соединение. Тема, публикация, подписка и получение датчиков по-прежнему должны быть проверены.

Вопрос 3. В чем разница между темами публикации и подписки MQTT?

А3. Публикация — это место, куда шлюз отправляет телеметрию; подписка — это место, где шлюз прослушивает сообщения или команды между сервером и устройством.

Вопрос 4. Может ли IoT-шлюз отправлять JSON по HTTP POST?

А4. Да, на шлюзах/прошивке, поддерживающих загрузку HTTP-клиента. Согласуйте точную структуру JSON и обработку ответов с командой сервера.

Вопрос 5. Всегда ли порт 8883 поддерживается для MQTTS?

А5. 8883 является общим, но микропрограмма шлюза и режим сертификата TLS должны быть совместимы с целевым брокером.

Вопрос 6. Когда мне следует использовать Modbus TCP вместо MQTT?

А6. Используйте Modbus TCP, когда промышленное ведущее устройство, такое как PLC или SCADA, должно активно опрашивать регистры через Ethernet.

Вопрос 7. Когда OPC UA предпочтительнее?

А7. Используйте OPC UA, когда промышленное программное обеспечение получает преимущества от стандартизированных тегов/узлов, метаданных и более широкой совместимости.

Вопрос 8. Может ли один шлюз использовать более одного протокола передачи данных?

А8. Многие пограничные шлюзы могут это сделать, но одновременное поведение нескольких адресатов должно быть проверено для конкретной прошивки и проекта.