Modbus TCP vs. RTU: Was ist Modbus TCP und was ist der Unterschied?

Du stehst vor einem Zähler mit zwei grünen Klemmen, beschriftet mit A und B, und die Software, die seine Werte lesen soll, fragt nach einer IP-Adresse und Port 502. Spätestens in diesem Moment wird die Frage Modbus TCP vs. RTU ganz praktisch. Die kurze Antwort: Modbus TCP und Modbus RTU sprechen dieselbe Sprache, also dieselben Funktionscodes und dieselben Register, verpacken sie aber unterschiedlich. RTU schickt kompakte Telegramme mit Prüfsumme über eine serielle Leitung, meist RS485. Modbus TCP schickt dieselben Anfragen mit einem eigenen Kopfteil über ein Ethernet- oder IP-Netz.

Aus diesem einen Unterschied folgt fast alles andere: wie Geräte adressiert werden, wie lang Leitungen sein dürfen, wie viele Programme gleichzeitig Werte abfragen können und warum ein einfaches Adapterkabel zwischen beiden Welten nicht funktioniert. Wer das weiß, kann eine bestehende RS485-Anlage gezielt um Netzwerkzugriff erweitern, statt funktionierende Geräte auf Verdacht zu tauschen.

Was ist Modbus TCP?

Modbus entstand 1979 bei Modicon als serielles Protokoll für speicherprogrammierbare Steuerungen. Ende der 1990er Jahre kam Modbus TCP dazu, die Variante für TCP/IP-Netze. Heute pflegt die Modbus Organization die Spezifikation, und das Modbus Protocol ist dort bewusst in zwei Ebenen getrennt. Die obere Ebene ist die eigentliche Nachricht, die Protocol Data Unit (PDU): ein Funktionscode und die zugehörigen Daten. Diese Ebene ist bei RTU und TCP identisch. Die untere Ebene ist die Verpackung für den Transport, und genau dort unterscheiden sich die Varianten.

Das Datenmodell bleibt in beiden Fällen gleich. Es gibt Coils und Discrete Inputs für einzelne Bits sowie Input Register und Holding Register mit je 16 Bit. Mit Funktionscode 03 liest ein Client Holding Register, mit 04 Input Register, mit 06 schreibt er ein einzelnes Register und mit 16 mehrere am Stück.

Die Rollen heißen in der aktuellen Spezifikation Client und Server, in älteren Handbüchern Master und Slave. Der Client stellt Anfragen, der Server beantwortet sie, und ungefragt sendet ein Gerät nichts. Bei Modbus TCP ist der Server das Feldgerät mit eigener IP-Adresse, und der Client ist zum Beispiel ein Leitsystem, ein Energiemanagement oder ein Skript auf einem Rechner. Weil nur IP vorausgesetzt wird, läuft Modbus TCP auch über WLAN oder einen VPN-Tunnel, solange die Latenz für die Anwendung passt.

Modbus TCP Port 502: Wie läuft die Verbindung ab?

Für Modbus TCP ist bei der IANA der TCP-Port 502 reserviert. Der Ablauf ist überschaubar: Der Client baut eine TCP-Verbindung zur IP-Adresse des Servers auf Port 502 auf. Danach schickt er seine Anfrage, bestehend aus dem MBAP-Header und der PDU. Der Server antwortet über dieselbe Verbindung und kopiert dabei die Transaction ID aus der Anfrage, damit der Client Frage und Antwort einander zuordnen kann.

Die Verbindung bleibt normalerweise für eine Anfrage nach der anderen offen. Für jede Abfrage neu zu verbinden kostet Zeit und kann Geräte überlasten, die nur wenige Sockets verwalten. Viele Server schließen untätige Verbindungen, deshalb verbindet sich ein robuster Client neu, statt mit einem Fehler stehen zu bleiben.

Eine offene Verbindung heißt noch nicht, dass die Daten stimmen. Die Abfrage eines Registers, das es nicht gibt, beantwortet der Server mit einer Exception: Der Funktionscode kommt mit gesetztem höchsten Bit zurück (0x83 statt 0x03), gefolgt von einem Fehlercode wie 02 für eine ungültige Datenadresse. Ein erfolgreicher Ping beweist nur, dass das Netz funktioniert.

Klassisches Modbus TCP kennt weder Anmeldung noch Verschlüsselung: Wer Port 502 erreicht, kann lesen und, sofern das Gerät es zulässt, auch schreiben. Die Spezifikation Modbus/TCP Security ergänzt TLS auf Port 802, wird von einfachen Feldgeräten aber selten unterstützt. Modbus-Geräte gehören deshalb in ein eigenes Netzsegment, mit Zugriff von außen über ein VPN, nie über eine Portfreigabe ins Internet.

Modbus TCP vs. RTU: Wie unterscheiden sich die Telegramme?

Am deutlichsten wird der Unterschied an einem echten Telegramm. Angenommen, du willst von Gerät 1 zwei Holding Register ab Adresse 0 lesen. Über RTU sieht die Anfrage in Hex so aus: 01 03 00 00 00 02 C4 0B. Das erste Byte ist die Geräteadresse, dann folgen Funktionscode, Startadresse und Anzahl der Register, am Ende zwei Byte CRC-Prüfsumme. Über Modbus TCP lautet dieselbe Anfrage 00 01 00 00 00 06 01 03 00 00 00 02. Die PDU in der Mitte ist identisch, aber vorne steht der MBAP-Header, und die Prüfsumme fehlt.

Der MBAP-Header ist sieben Byte lang: zwei Byte Transaction ID, zwei Byte Protocol ID, die bei Modbus immer 0 ist, zwei Byte Längenangabe für den Rest des Telegramms und ein Byte Unit ID. Die Unit ID übernimmt die Rolle der RTU-Geräteadresse. Eine eigene CRC braucht TCP nicht, weil TCP und Ethernet die Übertragung bereits selbst absichern. Die Tabelle stellt beide Formate gegenüber.

RTU erkennt das Ende eines Telegramms an einer Pause von rund 4 Millisekunden bei 9600 Baud (oberhalb von 19200 Baud empfiehlt die Spezifikation feste 1,75 Millisekunden), deshalb kann alles, was Bytes puffert oder verzögert, Telegramme zerreißen. Und weil RTU nur eine offene Anfrage zur Zeit kennt, arbeitet ein Bus streng nacheinander, während TCP über die Transaction ID mehrere Anfragen gleichzeitig unterwegs haben kann, sofern das Gerät das unterstützt.

Modbus RTU zu TCP: Wie funktioniert die Umsetzung?

Zwischen einem TCP-Client und RTU-Geräten sitzt ein aktives Gateway. Auf der Netzwerkseite ist es ein Modbus-TCP-Server auf Port 502, auf der seriellen Seite der einzige Master am RS485-Bus. Kommt eine Anfrage an, liest das Gateway die Unit ID und verwendet sie als RTU-Geräteadresse. Es entfernt den MBAP-Header, hängt die CRC an und sendet das Telegramm auf den Bus. Dann wartet es auf die Antwort, prüft deren CRC, baut einen neuen MBAP-Header mit derselben Transaction ID und schickt das Ergebnis zurück an den Client.

Antwortet das Zielgerät nicht, meldet ein sauber implementiertes Gateway das mit eigenen Exception-Codes: 0x0B, wenn das Zielgerät nicht reagiert, und 0x0A, wenn kein Weg zum Ziel konfiguriert ist. Sie zeigen sofort, ob das Problem im Netzwerk oder auf dem Bus liegt.

Die häufigsten Fehler sind banal. Der Client schickt Unit ID 255 oder 0, weil das seine Voreinstellung ist, und das Gateway kann damit kein bestimmtes Gerät am Bus erreichen. Baudrate, Parität und Stoppbits passen nicht zu den Feldgeräten. Die Spezifikation sieht 19200 Baud mit gerader Parität vor, viele Geräte sind ab Werk aber auf 9600 Baud ohne Parität eingestellt, und ohne Parität verlangt die Spezifikation zwei Stoppbits. Oder der Bus ist nicht an beiden Enden mit 120 Ohm abgeschlossen. Ein Gateway übersetzt nur, es repariert keine Verkabelung.

Ein Gateway hebt außerdem die Grenzen des Busses nicht auf: Fragen drei TCP-Clients gleichzeitig an, stellt es die Anfragen in eine Warteschlange. Und nicht jedes Gerät mit RS485-Anschluss ist ein Gateway. Der Milesight UC100 zum Beispiel ist Master an einem RS485-Bus, fragt die angeschlossenen RTU-Geräte selbst ab und schickt die Werte per LoRaWAN weiter. Einen Modbus-TCP-Server bietet er nicht, die Werte landen also als Funknachrichten beim Netzwerkserver, nicht als Register auf Port 502.

Was ist Modbus RTU over TCP?

Hinter dem ähnlich klingenden Begriff steckt etwas anderes. Bei Modbus RTU over TCP wird das komplette RTU-Telegramm, inklusive Geräteadresse und CRC, unverändert in einen TCP-Datenstrom gelegt. Einen MBAP-Header gibt es nicht. Typisch ist das bei seriellen Geräteservern im transparenten Modus, die Bytes zwischen Netzwerk und RS485 weiterleiten, ohne Modbus zu verstehen. Der Port ist dabei oft frei konfiguriert und nicht zwingend 502.

Die Folge: Ein normaler Modbus-TCP-Client kann mit so einem Server nicht sprechen. Er schickt einen MBAP-Header, den der Geräteserver unverändert auf den Bus gibt, wo die Geräte ein unbrauchbares Telegramm sehen. Das typische Symptom: eine offene Verbindung mit lauter Timeouts. Funktionieren kann es nur, wenn die Client-Software ausdrücklich eine Option für RTU over TCP oder gekapseltes RTU anbietet.

Diese Betriebsart ist keine eigene Variante der Modbus-Spezifikation, sondern eine verbreitete Praxis. Der Umsetzer bleibt einfach und die CRC erhalten, aber Netzwerklatenz und Pufferung können die Pausen zwischen Telegrammen verwischen. Wenn du die Wahl hast, ist ein echtes Gateway mit Umsetzung auf Modbus TCP meist die robustere Lösung.

Wann ist Modbus RTU die bessere Wahl?

RTU spielt seine Stärken aus, wo viele einfache Geräte über eine Strecke verteilt sind. Eine verdrillte Zweidrahtleitung verbindet sie nacheinander, und bei niedriger Baudrate sind Leitungslängen bis etwa 1200 Meter möglich. Ein Ethernet-Kupfersegment endet dagegen nach 100 Metern am nächsten Switch. Ein RS485-Segment trägt ohne Repeater 32 Standardlasten, und die Adressierung erlaubt bis zu 247 Geräte. Für Zähler und Sensoren mit einer Handvoll Register ist das eine günstige, bewährte Infrastruktur.

Viele Feldgeräte gibt es zudem nur mit RS485, und wenn deine Anlage bereits eine funktionierende Busleitung mit dokumentierten Adressen hat, bringt ein Wechsel zu TCP allein wegen des moderneren Namens wenig.

Die Grenzen solltest du durchrechnen. Eine Abfrage von zehn Registern umfasst 8 Byte Anfrage und 25 Byte Antwort. Bei 9600 Baud und 11 Bit pro Zeichen dauert allein die Übertragung rund 38 Millisekunden, plus Sendepausen und Bearbeitungszeit im Gerät. Bei 20 Geräten ist ein Zyklus damit schnell bei einer Sekunde. Fällt ein Gerät aus und wartet der Master jedes Mal eine Sekunde auf den Timeout, verlängert dieses eine Gerät den ganzen Zyklus spürbar. Und an einem RTU-Bus gibt es nur einen Master, zwei Programme können ihn also nicht unabhängig abfragen.

Wann lohnt sich Modbus TCP?

Modbus TCP lohnt sich, wenn ein betreutes Netzwerk die Geräte ohnehin erreicht und mehrere Systeme auf dieselben Daten zugreifen sollen. Ein Leitsystem, eine Energieauswertung und ein Wartungslaptop können sich gleichzeitig mit einem TCP-Gerät verbinden, solange das Gerät genug Verbindungen zulässt.

Auch bei der Übertragungszeit hat TCP Vorteile. Bei 100 Mbit/s dauert die Übertragung eines Telegramms nur Mikrosekunden, und die Antwortzeit hängt praktisch nur noch vom Gerät selbst ab. Zur Fehlersuche taugen außerdem gewohnte Werkzeuge wie Switch-Port-Status, Netzwerkmitschnitte und Ping.

Der Preis ist die Infrastruktur: Jedes Gerät braucht eine IP-Adresse, einen Switch-Port und Strom, und das Netz muss gegen unbefugte Zugriffe abgesichert sein. Wo das gut organisiert ist, passt Modbus TCP hervorragend, wo nicht, ist der zusätzliche Aufwand oft größer als der Nutzen.

Können Modbus TCP und RTU Geräte in einer Anlage zusammenarbeiten?

Ja, und oft ist genau das die Regel. Ein häufiges Muster ist ein Ethernet-Netz als Rückgrat, an dem in jedem Verteiler oder Technikraum ein Gateway eine RS485-Insel mit mehreren RTU-Geräten anbindet. Der Client spricht alle Geräte über Modbus TCP an und unterscheidet die seriellen Teilnehmer über ihre Unit ID. Weil das Datenmodell identisch ist, ändern sich die Registertabellen der Geräte dabei nicht.

Für die Planung lohnt sich eine einfache Liste: jedes Gerät mit Schnittstelle, Adresse, Baudrate, Parität und Registertabelle. Zwei Stolperfallen treten dabei bei beiden Varianten ständig auf. Viele Handbücher nummerieren Register ab 40001, während im Telegramm Adresse 0 steht. Und 32-Bit-Werte wie Gleitkommazahlen verteilen sich auf zwei Register, deren Reihenfolge je nach Hersteller unterschiedlich ist.

Wo kein Kabel eine RS485-Insel erreicht, kann ein Konverter wie der UC100 ihre RTU-Werte stattdessen per LoRaWAN senden. Sie kommen dann als dekodierte Messwerte hinter dem Netzwerkserver an statt als Modbus-TCP-Register, was für Monitoring im Minutentakt passt, für schnelle Steuerungsaufgaben aber nicht.

Modbus Geräte kaufen: Worauf solltest du achten?

Beginne beim Feldgerät und prüfe, welche Variante es wirklich spricht: RTU über RS485, Modbus TCP über Ethernet oder beides. Kläre bei RTU-Geräten Baudrate, Parität, Adressbereich und ob die Registertabelle vollständig dokumentiert ist, inklusive Registerzählung und Wortreihenfolge. Entscheide danach den Weg ins Netz. Ein echtes Gateway setzt auf Modbus TCP um und verlangt eine saubere Zuordnung der Unit IDs. Ein serieller Geräteserver im transparenten Modus braucht einen Client mit RTU over TCP. Ein LoRaWAN-Konverter liefert Messwerte per Funk statt Register über Port 502. Rechne außerdem die Zykluszeit deines Busses durch und plane die Netzsicherheit vorab.

Wenn du für die serielle Seite deiner Anlage passende Geräte suchst, ob sie später über Modbus TCP oder per Funk angebunden wird, findest du unsere Modelle in der Kategorie Modbus.

FAQ zu Modbus TCP und RTU

Ist Modbus TCP schneller als Modbus RTU?

Auf der Leitung ja, und zwar deutlich. Ein Telegramm, das bei 9600 Baud rund 38 Millisekunden braucht, ist bei 100 Mbit/s in Mikrosekunden übertragen. Ob Messwerte dadurch aktueller werden, hängt vom Gerät ab: Aktualisiert ein Sensor nur einmal pro Sekunde, bringt schnelleres Abfragen keine neuen Daten.

Braucht Modbus TCP eine feste IP-Adresse?

Der Client muss den Server unter einer bekannten Adresse erreichen, denn Modbus TCP hat keine eigene Gerätesuche. Eine feste IP-Adresse oder eine DHCP-Reservierung für das Gerät ist deshalb der übliche Weg. Manche Clients können auch einen Hostnamen auflösen, das setzt aber einen funktionierenden DNS-Eintrag voraus.

Wie viele Clients können sich mit einem Modbus TCP Gerät verbinden?

Das legt der Hersteller fest, nicht die Spezifikation. Manche einfachen Geräte erlauben nur eine einzige gleichzeitige Verbindung, andere mehrere. Den genauen Wert nennt das Datenblatt, und bei mehreren Clients zählt auch die gesamte Abfragelast.