IoT-Dossier

Modbus TCP zur Cloud – Überwachung über Ethernet, 4G und MQTT

Überwachen Sie Ihre Modbus-TCP/IP-Geräte über Ethernet oder 4G, lesen Sie die Holding-/Input-/Coil-Register aus und senden Sie die Daten an AWS IoT.

Kurz gesagt
Eine Brücke Modbus TCP zur Cloud lässt sich über Ethernet (oder WLAN) mit Ihren Geräten verbinden Modbus TCP/IP, fragt deren Register „Holding“, „Input“ und „Coil“ ab und veröffentlicht die Werte anschließend über MQTT TLS zu AWS IoT Core, Azure IoT Hub oder Eziwan Cloud. Die Cloud-Verbindung erfolgt über festes Ethernet oder 4G LTE je nach Netzwerkverfügbarkeit am Standort.

Modbus TCP: Das Ethernet-Protokoll für die Industrie

Modbus TCP/IP ist die 1999 standardisierte Ethernet-Variante des Modbus-Protokolls. Es behält das Master/Slave-Modell und die Registerstruktur (Holding, Input, Coil, Discrete Input) von Modbus RTU bei, überträgt diese jedoch über den TCP/IP-Port 502. Das Ergebnis: Modbus TCP lässt sich nahtlos in die IT-Netzwerke von Unternehmen integrieren und ist gleichzeitig mit dem bestehenden Modbus-Ökosystem kompatibel.

Seine Vorteile gegenüber Modbus RTU:

  • Geschwindigkeit: 100 Mbit/s gegenüber maximal 115 kbps bei RS485
  • Freie Topologie: keine Begrenzung auf 32 Knoten an einem linearen Bus
  • Multi-Master: Mehrere Clients können denselben Slave abfragen
  • Reichweite: Standard-Ethernet bis zu 100 m, Glasfaser für große Entfernungen

Verbindungsarchitektur Modbus TCP → Cloud

Das Gateway fungiert gegenüber den lokalen Geräten als Modbus-TCP-Client (Master) und gegenüber der Cloud als MQTT-Client. Es ist zwischen dem OT-Netzwerk und dem Cloud-Netzwerk geschaltet.

EbeneAusrüstung / Protokoll
Feld (Geräte)Steuerungen, Frequenzumrichter, Zähler mit Ethernet-Anschluss
Industrielles LANEthernet-Switch, OT-VLAN
GatewayEziwan Gateway (Modbus-TCP-Client + MQTT-Client)
Cloud-ÜbertragungMQTT über TLS 1.3 / 4G LTE oder Ethernet-WAN
CloudAWS IoT Core, Azure IoT Hub, Eziwan Cloud
AnwendungDashboard, Warnmeldungen, REST-API, Berichterstellung

Auslesen von Modbus-TCP-Registern: Unterstützte Datentypen

Das Gateway fragt alle in der Norm definierten Arten von Modbus-TCP-Registern ab:

16-Bit-Register:

  • Holding-Register (FC03) – Lesen/Schreiben, Prozesswerte (Sollwerte, Parameter)
  • Eingangsregister (FC04) – nur Lesen, Echtzeitmesswerte (Strom, Spannung, Durchfluss)

Diskrete Bits:

  • Spulen (FC01/FC05) – Lesen/Schreiben, Logikausgänge (Relais, Steuerungen)
  • Diskrete Eingänge (FC02) – nur Lesen, Logikeingänge (Zustände, Fehler)

Kodierte Datentypen:

  • INT16, UINT16 (1 Register)
  • INT32, UINT32, FLOAT32 IEEE 754 (2 Register, Big Endian oder Little Endian)
  • INT64, DOUBLE (4 Register)
  • ASCII-Zeichenkette

MQTT-Übertragung an AWS IoT, Azure IoT Hub oder Eziwan

Sobald die Register ausgelesen wurden, veröffentlicht das Gateway die Messwerte beim Ziel-MQTT-Broker. Die drei wichtigsten Plattformen werden unterstützt:

AWS IoT Core

  • Verbindung über MQTT über TLS, Port 8883
  • Authentifizierung über ein AWS-x509-Zertifikat
  • IoT-Regeln für DynamoDB, S3, Lambda oder QuickSight

Azure IoT Hub

  • Verbindung über AMQP oder MQTT TLS
  • Device Twin für die Fernkonfiguration
  • Stream Analytics für die Echtzeitverarbeitung

Eziwan Cloud

  • Zero-Touch-Konfiguration, keine Infrastrukturverwaltung erforderlich
  • Vorkonfiguriertes Dashboard mit Industrieeinheiten
  • SMS-/E-Mail-Benachrichtigungen in weniger als 30 Sekunden

Abfrage und Optimierung der Erfassungsfrequenz

Die Wahl der Abfragefrequenz wirkt sich sowohl auf die Aktualität der Daten als auch auf den Mobilfunkdatenverbrauch aus.

MessartEmpfohlene Messfrequenz
Elektrische Größen (P, Q, I, U)1 bis 10 s
Prozesstemperaturen30 s bis 5 min
Füllstände, Durchflussmengen1 bis 5 min
Diskrete Zustände (Alarme)1 bis 5 s
Zähler (Energie, Volumen)5 bis 15 min

Das Gateway kann auch im on-change-Modus konfiguriert werden: Ein Wert wird nur dann übertragen, wenn er sich um einen konfigurierbaren Wert (Deadband) ändert, wodurch das Datenvolumen erheblich reduziert wird.

standortübergreifende Überwachung: die zentralisierte Architektur

Bei einem Verbund aus mehreren Industriestandorten wiederholt sich dieselbe Architektur:

  1. Ein Gateway pro Standort, wobei jedes seine lokalen Modbus-TCP-Geräte abfragt
  2. Alle Gateways senden Daten an denselben MQTT-Cloud-Broker (oder an standortbezogene Themen)
  3. Eine einzige Überwachungsoberfläche bündelt alle Standorte
  4. Die Warnmeldungen werden global konfiguriert und lassen sich standortbezogen eskalieren

Diese zentralisierte Architektur mit lokalen Gateways ist der Standard für die industrielle Fernüberwachung an mehreren Standorten.

Häufig gestellte Fragen

Das könnte Sie auch interessieren