MQTT vs. HTTP vs. Modbus TCP vs. OPC UA für industrielle IoT-Gateways

Dieselben Sensordaten können auf unterschiedliche Weise bereitgestellt werden

Ein Sensor bestimmt nicht die endgültige Cloud oder das SCADA-Protokoll. RS485 Modbus RTU wird häufig auf der Feldebene verwendet, während das Gateway diese Daten für die Anwendungsebene übersetzt oder neu verpackt. Das richtige Upstream-Protokoll hängt davon ab, wer die Kommunikation initiiert, wo die Daten gespeichert werden, ob Befehle an das Gerät zurückgesendet werden müssen und welche Software der Kunde bereits betreibt.

MQTT: Am besten für Cloud-orientierte Publish/Subscribe-Systeme geeignet

MQTT trennt Sender und Empfänger über einen Broker. Das Gateway veröffentlicht Sensordaten zu einem Thema, während eine oder mehrere Anwendungen dieses Thema abonnieren. Dies ist für verteilte Überwachungsstandorte nützlich, da das Gateway nicht jeden Endverbraucher der Daten kennen muss.

Eine korrekte MQTT-Konfiguration umfasst normalerweise Brokeradresse, Port, Client-ID, Authentifizierung und Themenregeln. Ein häufiger Fehler besteht darin, anzunehmen, dass „Gerät online“ gleichbedeutend ist mit „Daten angekommen“. Der MQTT-Verbindungsstatus beweist lediglich, dass eine Sitzung eingerichtet wurde. Das Gateway veröffentlicht möglicherweise immer noch im falschen Thema, der Server abonniert möglicherweise ein anderes Thema oder die Sensorerfassungsschicht verfügt möglicherweise über keine gültigen Daten.

Veröffentlichen und Abonnieren dürfen nicht verwechselt werden

Das Veröffentlichungsthema ist der Ort, an den das Gerät Telemetriedaten sendet. Das Abonnementthema wird normalerweise für Befehle oder Nachrichten verwendet, die von der Plattform zurück an das Gerät gesendet werden. Wenn ein Server Messungen empfangen möchte, sollte er das Gateway-Veröffentlichungsthema abonnieren. Die Verwendung desselben Veröffentlichungs- und Abonnementthemas kann in einigen Implementierungen zu unerwünschten Schleifen führen und sollte nicht als Standardkonfiguration behandelt werden.

MQTTS und Port 8883

MQTTS bedeutet normalerweise MQTT über TLS. Port 8883 ist ein gängiger TLS-Port, die erfolgreiche Nutzung hängt jedoch nicht nur von der Portnummer ab. Die TLS-Bibliothek, die CA-Validierungsmethode, das Serverzertifikat, das optionale Client-Zertifikat und die MQTT-Version müssen kompatibel sein. Bei echten Cloud-Tests von Drittanbietern kann ein Gateway manchmal eine Verbindung zu einem TLS-Broker herstellen, bei einem anderen jedoch scheitern, bis die Firmware aktualisiert wird.

Testen Sie bei Produktionsprojekten den genauen Broker, den Zertifikatsmodus und die Firmware, bevor Sie eine große Charge versenden. Zertifikate sollten vom Kundenserver oder der Cloud-Plattform stammen oder mit diesem übereinstimmen; Es handelt sich nicht um generische Dateien, die ein Gateway-Hersteller unabhängig vom Server erfinden kann.

HTTP POST: Am besten, wenn der Kunde einen Web-Endpunkt besitzt

HTTP ist oft die einfachste Option, wenn der Kunde über eine Serveranwendung verfügt, die POST-Anfragen empfangen kann. Das Gateway kann als HTTP-Client konfiguriert werden und regelmäßig JSON an eine Ziel-URL senden. Dies eignet sich für benutzerdefinierte Web-Backends und Umgebungen, in denen das Softwareteam die direkte Bearbeitung von Anfragen/Antworten bevorzugt, anstatt einen MQTT-Broker zu betreiben.

Eine typische Nutzlast kann einen Zeitstempel, eine Stations-ID und ein Parameterobjekt mit Sensorwerten enthalten. Die genauen Feldnamen sind eine Projektkonvention. Der wichtige Schritt besteht darin, sich vor der Bereitstellung auf Datentypen, Einheiten, Verhalten bei fehlenden Daten und Serverreaktion zu einigen.

Modbus TCP: Am besten, wenn SCADA oder PLC die Daten abfragen sollen

Modbus TCP überträgt das bekannte Registermodell Modbus über Ethernet. Es eignet sich oft, wenn ein PLC-, HMI- oder SCADA-System bereits als Modbus-Master konzipiert ist. Das Gateway kann RS485 Modbus RTU-Geräte mit der Ethernet-Seite verbinden oder erfasste Werte über eine definierte Registerzuordnung offenlegen.

Wenn der Kunde sagt: „Geben Sie uns eine IP-Adresse und sagen Sie uns, wo jedes Signal gespeichert ist; unser System wird es lesen“, ist Modbus TCP normalerweise näher an der erforderlichen Architektur als MQTT oder HTTP.

OPC UA: Am besten für eine umfassendere industrielle Integration

OPC UA wird häufig in Industriesoftware verwendet, da es Daten als benannte Tags oder Knoten mit Struktur und Metadaten anstelle nur numerischer Registeradressen darstellen kann. Es eignet sich gut für SCADA, industrielle Middleware und PC-Anwendungen, die ein standardisiertes Erkennungs- und Abonnementverhalten erfordern.

Nicht jedes Gateway unterstützt OPC UA in derselben Rolle. Überprüfen Sie daher, ob es als OPC UA-Server, Client oder beides fungiert. In NiuBoL-Projekten werden leistungsfähigere Edge-Gateways bevorzugt, wenn OPC UA eine Kernanforderung ist.

Welches Protokoll sollten Sie wählen?

Feldprotokoll und Upstream-Protokoll werden nicht verwechselt

Ein System kann gleichzeitig RS485 Modbus RTU von Sensoren zum Gateway und MQTT vom Gateway zur Cloud verwenden. Es kann auch 4–20-mA-Sensoren in einem ADC-Gateway verwenden und diese Werte dann über Modbus TCP oder OPC UA verfügbar machen. Die Feldschnittstelle und das Anwendungsprotokoll sind separate Designebenen.

Fehlerbehebung: MQTT verbunden, aber keine Daten

1. Bestätigen Sie, dass die Sensorebene tatsächlich Daten innerhalb des Gateways erzeugt.
2. Überprüfen Sie das Upload-Intervall und stellen Sie sicher, dass das Gateway veröffentlicht und nicht nur verbunden ist.
3. Überprüfen Sie das Veröffentlichungsthema genau, einschließlich führender Schrägstriche und Berücksichtigung der Groß-/Kleinschreibung, wenn der Broker/die Plattform sie unterschiedlich behandelt.
4. Verwenden Sie einen unabhängigen MQTT-Client, um dasselbe Thema zu abonnieren und das Gateway von der Geschäftsplattform zu isolieren.
5. Überprüfen Sie die Authentifizierung, Client-ID-Kollisionen und ob ein anderer Client dieselben Anmeldeinformationen verwendet.
6. Überprüfen Sie für TLS die Kompatibilität von CA-/Serverzertifikaten und Firmware-Bibliotheken.
7. Verwenden Sie Gateway-Protokolle und ggf. Netzwerkerfassung, um festzustellen, ob Pakete das Gerät verlassen und wie der Server reagiert.

Fehlerbehebung: HTTP-Server empfängt nichts

Erste separate Erfassung vom Upload. Wenn das Gateway-Protokoll besagt, dass das untere Gerät nicht antwortet, reparieren Sie die Sensorkommunikationsschicht, bevor Sie den Server debuggen. Überprüfen Sie dann Ziel-URL, Port, DNS-/Netzwerk-Erreichbarkeit, Inhaltstyp, JSON-Format und HTTPS-Anforderungen. Die Gateway-HTTP-Funktion in dieser Architektur ist ein Client, der Daten aktiv per POST sendet. Es handelt sich nicht automatisch um einen HTTP-Server, den der Kunde durchsuchen kann.

FAQ

Q1: Ist MQTT für IoT besser als HTTP?

A1: Keines von beiden ist allgemein besser. MQTT ist stark für Publish/Subscribe-Flotten; HTTP ist unkompliziert, wenn ein Kunde bereits über einen Web-Empfangsendpunkt verfügt.

Q2: Bedeutet MQTT „online“, dass die Plattform Sensordaten empfangen hat?

A2: Nein. Der Online-Status bestätigt nur eine Verbindung. Thema, Veröffentlichung, Abonnement und Sensorakquise müssen noch überprüft werden.

Q3: Was ist der Unterschied zwischen MQTT-Publishing- und Subscribe-Themen?

A3: Beim Veröffentlichen sendet das Gateway Telemetriedaten. Bei „Subscribe“ wartet das Gateway auf Server-zu-Gerät-Nachrichten oder -Befehle.

Q4: Kann ein IoT-Gateway JSON per HTTP POST senden?

A4: Ja, auf Gateways/Firmware, die HTTP-Client-Upload unterstützen. Vereinbaren Sie mit dem Serverteam die genaue JSON-Struktur und die Antwortverarbeitung.

Q5: Wird Port 8883 immer für MQTTS unterstützt?

A5: 8883 ist üblich, aber die Gateway-Firmware und der TLS-Zertifikatsmodus müssen mit dem Zielbroker kompatibel sein. Messstellenprotokoll für Sensor-Systemintegration: Dokumentieren Sie den vereinbarten Messbereich, die Alarmreaktion, die Schnittstellenprüfung und den Wartungsnachweis im Inbetriebnahme- oder Abnahmeprotokoll.

Q6: Wann sollte ich Modbus TCP anstelle von MQTT verwenden?

A6: Verwenden Sie Modbus TCP, wenn ein Industrie-Master wie PLC oder SCADA aktiv Register über Ethernet abfragen soll. Abnahmeprüfung für Sensor-Systemintegration: Dokumentieren Sie den vereinbarten Messbereich, die Alarmreaktion, die Schnittstellenprüfung und den Wartungsnachweis im Inbetriebnahme- oder Abnahmeprotokoll.

Q7: Wann ist OPC UA vorzuziehen?

A7: Nutzen Sie OPC UA, wenn die Industriesoftware von standardisierten Tags/Knoten, Metadaten und einer umfassenderen Interoperabilität profitiert.

Q8: Kann ein Gateway mehr als ein Upstream-Protokoll verwenden?

A8: Viele Edge-Gateways können dies, aber das gleichzeitige Verhalten mehrerer Ziele sollte für die genaue Firmware und das Projekt überprüft werden.

Zusammenfassung