Detaillierte Erklärung des Modbus-Protokolls: Von Hintergrund, Entwicklung, Prinzipien bis zur Konfiguration in der Praxis

23. Nov. 2025

25 Min. Lesezeit

Aktualisiert: 12. Okt.

Detaillierte Erklärung des Modbus-Protokolls: Von Hintergrund, Entwicklung, Prinzipien bis zur Konfiguration in der Praxis

Einleitung: Warum wird Modbus noch immer eingesetzt?

Modbus wird seit seiner Einführung durch Modicon im Jahr 1979 in der industriellen Kommunikation eingesetzt. Sein Anfrage-/Antwortmodell ist weiterhin nützlich, um Messwerte, Gerätestatus und Steuerregister in Energieversorgung, Wasserwirtschaft, Prozessindustrie und Fertigung auszulesen. Die fortdauernde Nutzung erklärt sich eher durch installierte Geräte, zugängliche Spezifikationen und eine einfache Implementierung als durch unbelegte Marktanteils- oder Gerätezahlenschätzungen.

Modbus konzentriert sich auf den Austausch einer kleinen Menge Gerätedaten über definierte Funktionscodes. Diese Einfachheit kann Implementierungs- und Integrationsaufwand verringern, sofern der Ingenieur auch die physische Schnittstelle, die Registerzuordnung des Geräts und die Anwendungsanforderungen prüft. Zu den praktischen Stärken gehören:

Einfaches Kommunikationsmodell: Ein serieller Client plant Anfragen, ein Server antwortet; TCP nutzt dasselbe Anwendungsmodell über eine Netzwerkverbindung.
Öffentliche Spezifikationen: Implementierer können die Protokolldokumente bei der Modbus Organization beziehen. Eine offene Spezifikation ist von der Lizenz eines bestimmten Software-Stacks oder Produkts zu unterscheiden.
Breite Auswahl an Implementierungen: Steuerungen, Messgeräte und Gateways verschiedener Hersteller können Daten austauschen, wenn ihre unterstützten Funktionen und gerätespezifischen Zuordnungen übereinstimmen.
Geringe Anforderungen an die Implementierung: Kleine eingebettete Geräte können die benötigten Funktionen implementieren; tatsächlicher Speicherbedarf, Energieverbrauch und Bauteilkosten hängen vom Design ab.
Praktische RS-485-Busverdrahtung: Mehrere adressierte Geräte können sich einen sachgerecht ausgelegten Bus teilen. Auf seriellem Modbus sind die Adressen 1–247 verfügbar; elektrische Last, Topologie und Timing bestimmen jedoch, wie viele Geräte ein Segment unterstützen kann.
Etablierte installierte Basis: Der Austausch funktionierender Feldgeräte kann erheblichen Integrationsaufwand verursachen. Gateways können vorhandene Modbus-Daten für neuere Leitsysteme verfügbar machen.

Ein Gateway, das ausdrücklich Protokollumsetzung oder Datenerfassung unterstützt, kann Modbus-Geräte abfragen und ausgewählte Werte per MQTT, HTTP oder OPC UA bereitstellen. Registerzuordnung, Einheiten, Aktualisierungsintervall und unterstützte Gateway-Funktionen müssen konfiguriert werden; eine gewöhnliche IP-Verbindung stellt sie nicht automatisch bereit. Dieser Leitfaden behandelt Modbus von Hintergrund und Datenmodell über Rahmen bis zu Einsatz und Konfiguration und kann zusammen mit den Handbüchern der konkreten Geräte verwendet werden.

Modbus ist ein Client/Server-Kommunikationsprotokoll zum Lesen und Schreiben von Coils und Registern. RTU und ASCII verwenden serielle Nachrichtenrahmen; Modbus TCP nutzt TCP/IP. Prüfen Sie vor der Konfiguration die Registerliste des Geräts und die Adresskonvention des Clients.

Bei der Nachrüstung spricht eine Steuerung möglicherweise Modbus RTU über eine serielle Leitung, während das übergeordnete System Modbus TCP erwartet. Der gemeinsame Name „Modbus“ sagt weder aus, ob ein Gateway die Nachrichten umsetzt, noch welche Adresse zu einer Registerbezeichnung gehört.

Dieser Leitfaden trennt Datenmodell, Übertragungsweg und Nachrichtenrahmen. Er vergleicht RTU, ASCII und TCP und zeigt, warum eine Referenz wie 40001 nicht immer die Adresse ist, die ein Client erwartet. Eine kleine Zuordnungstabelle unterstützt die Inbetriebnahme.

Historischer Hintergrund und Entwicklung von Modbus

Entstehungshintergrund

Mit der Verbreitung speicherprogrammierbarer Steuerungen benötigten Steuerungen und Feldgeräte eine praktische Möglichkeit, Messwerte und Befehle auszutauschen. Herstellerspezifische Schnittstellen erschwerten die Integration. Modbus entstand bei Modicon in diesem Umfeld als Anfrage-/Antwortprotokoll für Industrieanlagen; das Protokoll macht nicht jede Gerätezuordnung und elektrische Schnittstelle austauschbar.

Modicon führte Modbus 1979 ein. Ein Client sendet einen Funktionscode und Anfragedaten; der adressierte Server gibt die angeforderten Daten zurück oder eine Ausnahme, wenn er die Anfrage nicht verarbeiten kann. Auf einem seriellen Bus steuert der Client den Austausch. Dieses wiederverwendbare Modell ermöglicht Steuerungen und Messgeräten, definierte Operationen auszutauschen, während die konkrete Gerätezuordnung dem Hersteller überlassen bleibt.

Entwicklungsgeschichte

Die wichtigste Entwicklung ist die Wiederverwendung eines gemeinsamen Anwendungsprotokolls für serielle und TCP/IP-Kommunikation. Die folgenden Meilensteine unterscheiden den Protokollursprung, dokumentierte Spezifikationsfassungen und heutige Integrationspraxis:

Zeitraum / Dokumentdatum	Meilenstein	Bedeutung für die Technik
1979	Modicon führt Modbus ein	Anfrage-/Antwortprotokoll für industrielle Steuerungen und Geräte.
Serielle Implementierungen	RTU- und ASCII-Rahmung	Ein gemeinsames Anwendungsmodell kann kompakte binäre RTU-Rahmen oder ASCII-kodierte serielle Rahmen verwenden.
Ethernet-Integration	Modbus TCP/IP	Die Anwendungs-PDU wird über eine TCP-Verbindung mit MBAP-Header übertragen; es handelt sich nicht um einen unverändert übermittelten RTU-Rahmen.
24. Oktober 2006	TCP/IP Implementation Guide V1.0b	Dokumentiert Client/Server-Kommunikation und die Integration über TCP/IP- und Gateway-Systeme.
20. Dezember 2006	Serial Line Guide V1.02	Dokumentiert serielle Adressierung, Rahmung, Timing und Implementierungsanforderungen.
26. April 2012	Application Protocol Specification V1.1b3	Definiert das Datenmodell, die Adressierung, Funktionscodes und das Ausnahmeverhalten in diesem Leitfaden.
Heutige Integrationspraxis	Polling und Protokoll-Gateways	Ausgewählte Gerätewerte können MQTT oder OPC UA zugeordnet werden, wenn Gateway und Anwendung diese Funktionen ausdrücklich unterstützen.

Diese Entwicklungen ermöglichen es bestehenden Feldgeräten, an neueren Systemen teilzunehmen, ohne die Bedeutung der Anwendungsanfragen zu ändern. Transport, Gateway-Verhalten und Registerinterpretation müssen weiterhin unabhängig geprüft werden.

Warum wurde Modbus nicht abgelöst?

Modbus bleibt nützlich, wenn Geräte bereits eine bekannte Registerzuordnung bereitstellen und die Anwendung einfache Datenerfassung oder Steuerung benötigt. Ein Ersatz dieser Geräte kann Änderungen an der Verdrahtung, Validierung und Softwareintegration erfordern. Ressourcenbedarf und Migrationskosten hängen von der konkreten Implementierung ab; pauschale Aussagen zu Codegröße, Anteil älterer Geräte und Kostenverhältnissen sind keine verlässliche Grundlage für die Auswahl.

Modbus kann MQTT oder OPC UA in einer IIoT-Architektur ergänzen. Ein Gateway kann einen Zähler per Modbus abfragen, dessen Register interpretieren und die resultierenden Messwerte einer Leitebene oder Cloud-Anwendung bereitstellen. Diese Protokolle haben unterschiedliche Kommunikations- und Informationsmodelle; eine solche Zuordnung ist eine Anwendungsfunktion und keine automatische Funktion von Modbus.

Protokollarchitektur von Modbus

Modbus ist ein Protokoll der Anwendungsschicht im Client/Server-Modell, das auf Anfragen und Antworten basiert. Auf einer seriellen Verbindung initiiert der Client (traditionell Master genannt) Transaktionen, während der adressierte Server (Slave) antwortet. Ein gemeinsam genutzter serieller Bus hat normalerweise einen Client. Modbus TCP kann mehrere Clientverbindungen innerhalb der vom Server unterstützten Grenzen zulassen. Keine der beiden Varianten garantiert eine feste Antwortzeit; Abfragezeit, Verbindungsgeschwindigkeit, Verarbeitung, Zeitüberschreitungen und Netzwerklast sind relevant.

Grundlegende Architektur

Client (PLC / gateway / HMI)  -- request -->  Server (instrument / controller)
Client                        <-- response --  Server

Serial bus: one client schedules transactions.
TCP: client connections depend on the server implementation.

Client: initiiert Anfragen und plant Abfragen sowie Wiederholungen. Mehrere unabhängige serielle Clients dürfen nicht ohne eigens ausgelegtes Koordinierungssystem auf denselben Bus senden.
Serieller Server: verwendet eine individuelle Adresse von 1 bis 247. Adresse 0 ist für unterstützte Broadcast-Schreibvorgänge reserviert; Server antworten nicht auf Broadcasts.
Kommunikationspfad: RTU- oder ASCII-Rahmung auf einer unterstützten seriellen Schnittstelle oder die Modbus-Anwendungs-PDU über TCP/IP.

Datenmodell

Modbus abstrahiert Geräte als "Registerkarte":

Bitgruppen: Coils sind Einzelbitwerte, die gelesen und geschrieben werden können; diskrete Eingänge sind Einzelbitwerte, die der Client ausliest.
Registergruppen: Holding Register sind 16-Bit-Wörter, die gelesen und geschrieben werden können; Input Register sind 16-Bit-Wörter, die der Client ausliest. Ein Gerät kann unterstützte Operationen und Zugriffsmöglichkeiten einschränken.

Trennen Sie die Anwendungsnachricht von ihrer Rahmung und der physischen Verbindung:

Anwendung: Die Protokolldateneinheit (PDU) enthält einen Funktionscode und dessen Daten.
Serielle Rahmung: Adresse und Prüffeld umgeben die PDU; RTU und ASCII kodieren und begrenzen den Rahmen unterschiedlich.
TCP/IP-Rahmung: Der MBAP-Header steht im TCP-Bytestrom vor der PDU. Ethernet ist eine gängige zugrunde liegende Netzwerkverbindung; RS-485 eine gängige elektrische Schnittstelle für serielle Verbindungen.

Die Anwendungs-PDU ist auf 253 Byte begrenzt. Eine RTU-ADU kann einschließlich ihrer Rahmung höchstens 256 Byte, eine TCP-ADU höchstens 260 Byte umfassen. Die tatsächliche Länge von Anfrage und Antwort hängt von Funktion und Menge ab. Diese Größenbegrenzungen garantieren weder eine bestimmte Zustellrate noch einen bestimmten Zuverlässigkeitsprozentsatz.

Modbus beschreibt Anfragen und Antworten zwischen Client und Server. Das Anwendungsprotokoll gliedert die Daten in vier Gruppen:

Datengruppe	Einheit	Typischer Zugriff
Coils	Einzelne Bits	Lesen und Schreiben
Discrete Inputs	Einzelne Bits	Lesen
Input Registers	16-Bit-Wörter	Lesen
Holding Registers	16-Bit-Wörter	Lesen und Schreiben

Funktionscodes legen Vorgänge wie das Lesen von Coils oder Registern und das Schreiben von Werten fest. Ein Gerät muss nicht jeden Funktionscode unterstützen. Sein Handbuch enthält die gerätespezifische Registertabelle: unterstützte Funktionen, Bedeutung der Adressen, Schreibrechte und Kodierung der Werte.

Auch ein 16-Bit-Register erklärt den technischen Wert nicht allein.

Eine größere Zahl kann mehrere Register belegen. Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Einheit müssen aus dem Gerätehandbuch übernommen und zusammen mit der Registerreferenz dokumentiert werden.

Die Modbus Application Protocol Specification definiert Datenmodell und Funktionscodes, jedoch keine Registertabelle für ein bestimmtes Produkt.

Lese- und Schreibfunktionscodes unterscheiden

Die Modbus-Anwendungsspezifikation ordnet 0x01 und 0x02 dem Lesen von Coils und diskreten Eingängen zu, 0x03 und 0x04 dem Lesen von Holding- und Eingangsregistern. Schreiben nutzt andere Funktionen, darunter 0x05 für ein Coil, 0x06 für ein Register, 0x0F für mehrere Coils und 0x10 für mehrere Register. Ein Gerät kann nur einen Teil unterstützen. Wählen Sie den im Gerätehandbuch für den Datenpunkt angegebenen Code und prüfen Sie die Schreibberechtigung, bevor ein Client einen Schreibzugriff erhält.

Eine erfolgreiche Antwort zeigt, dass die Anfrage verarbeitet wurde, bestätigt aber nicht automatisch den angezeigten technischen Wert. Die vier Datengruppen beschreiben die Adressierung; Vorzeichen, Skalierung, Einheit und Wortreihenfolge bei Werten über mehrere Register sind gerätespezifisch. Lesen Sie zunächst einen bekannten, schreibgeschützten Wert. Bei einer Modbus-Exception prüfen Sie Funktion und Adresse, bevor Sie Verkabelung oder IP-Routen ändern.

Modbus drei Hauptversionen: RTU / ASCII / TCP

RTU, ASCII und TCP verwenden dasselbe Modbus-Anwendungsdatenmodell, unterscheiden sich jedoch in Nachrichtenrahmung und Verhalten der Verbindung. Wählen Sie die Variante, die von den konkreten Geräten und dem Integrationspfad unterstützt wird, statt einen bestimmten Marktanteil oder eine allgemeine Produktunterstützung anzunehmen.

Modbus RTU (Klassisch & Häufigst)

Betriebsumgebung: eine vom Gerät unterstützte serielle Verbindung. Der Serial Line Guide beschreibt RS-485-Schnittstellen; manche Geräte bieten zusätzlich RS-232 oder andere ausdrücklich dokumentierte serielle Schnittstellen. Halbduplex und differentieller Betrieb sind für zweiadriges RS-485 typisch, jedoch keine Eigenschaften jeder seriellen Schnittstelle.

Merkmale:

Binärübertragung: Adresse, Funktion und Daten sind Binärbytes. RTU-Rahmen sind durch mindestens 3,5 Zeichenzeiten getrennt; oberhalb von 19.200 bit/s empfiehlt der Serial Line Guide feste Timerwerte.
Fehlererkennung: Der RTU-Rahmen endet mit einer 16-Bit-CRC. Sie erkennt Übertragungsfehler; sie authentifiziert den Absender nicht und garantiert keine fehlerfreie Zustellung.
Serielle Einstellungen: Verwenden Sie die in den Handbüchern unterstützte Baudrate, Parität und Anzahl der Stoppbits. Alle kommunizierenden Geräte müssen übereinstimmen; nehmen Sie keinen universellen Standardwert an.
Reichweite und Buslast: Kabeltyp, Baudrate, Transceiver, Unit Loads, Abschluss und Topologie bestimmen das zulässige Segment. Die 247 seriellen Adressen garantieren keine Segmentkapazität der elektrischen Schnittstelle.
Vorteile: kompakte Rahmen und einfache Feldbusintegration, wenn die Geräte bereits dieselbe serielle Schnittstelle unterstützen.
Einschränkungen: Abfragen auf einem gemeinsam genutzten Bus und serielle Timing-Anforderungen begrenzen den Durchsatz; zur Diagnose können Frame-Mitschnitte und geeignete serielle Werkzeuge erforderlich sein.

Typische Topologie:

RS-485 trunk (termination at the two physical ends, as specified):
[Client] =======+==========+==========+======= [end]
               |          |          |
           [Server 1] [Server 2] [Server 3]

Keep device drops short and follow the equipment wiring guide.
Match documented signal polarity; A/B labels vary between vendors.

Anwendbar: Altsysteme, Fernüberwachung.

Modbus ASCII (Frühe Version)

Betriebsumgebung: eine unterstützte serielle Verbindung. Jedes Binärbyte in Adresse, Funktion und Daten wird durch zwei hexadezimale ASCII-Zeichen dargestellt (0–9 und A–F).

Merkmale:

Fehlererkennung: ASCII verwendet eine Längsparitätsprüfung (LRC) statt der RTU-CRC.
Rahmenbegrenzung: Ein Doppelpunkt beginnt den Rahmen, CR/LF beendet ihn.
Kodierungsaufwand: Zwei Zeichen stellen jedes kodierte Byte dar; für dieselbe Anwendungsnutzlast werden daher mehr Zeichen als bei RTU übertragen.
Inspektion: Der Strom hexadezimaler Zeichen lässt sich in einem seriellen Mitschnitt untersuchen; zur Interpretation der Daten wird weiterhin eine Geräte-Registerzuordnung benötigt.
Kompatibilität: Wählen Sie ASCII nur, wenn beide Endpunkte es ausdrücklich unterstützen und entsprechend konfiguriert sind.

Geeignet für: Wartung oder Integration von Geräten, die Modbus ASCII erfordern. Auch ein Lehr- oder Testaufbau kann es verwenden; die Unterstützung muss jedoch geprüft und darf nicht allein aus der Bezeichnung Modbus abgeleitet werden.

Modbus TCP (Ethernet-Version)

Betriebsumgebung: ein verbindungsorientiertes TCP/IP-Netzwerk. Modbus TCP verwendet üblicherweise Server-Port 502; bestätigen Sie den konfigurierten Port und die unterstützten Client-/Serverrollen.

MBAP-Header: sieben Byte mit Transaction Identifier, Protocol Identifier, Length und Unit Identifier.
Rahmung: Die Modbus-TCP-ADU enthält keine serielle RTU-CRC. Prüfungen und Wiederholungen des TCP-Transports sind von der Validierung auf Anwendungsebene getrennt.
Netzwerkdesign: Verbindungsgeschwindigkeit und Reichweite hängen von Ethernet oder anderen Netzwerkmedien und dem gesamten gerouteten Pfad ab; sie sind keine Modbus-Garantien für Durchsatz oder Latenz.
Gleichzeitige Verbindungen: Geräte können mehrere TCP-Clients unterstützen, doch Verbindungsgrenzen, Anfrageplanung und Transaktionsbehandlung hängen von der Implementierung ab. Eine UDP-basierte Variante ist nicht der hier beschriebene TCP-Transport.
Vorteile: lässt sich in bestehende IP-Netze integrieren und kann Leitsystem-Clients mit Gateways oder nativen TCP-Servern verbinden.
Sicherheit: Einfaches Modbus TCP bietet weder Benutzerauthentifizierung noch Verschlüsselung. Verwenden Sie einen geeigneten geschützten Netzwerkpfad und eine Zugriffspolitik; TLS lässt sich nicht auf einem Endpunkt aktivieren, der es nicht implementiert.

Ein Protokoll-Gateway kann zwischen unterstützten RTU- und TCP-Transaktionen übersetzen. Prüfen Sie Betriebsmodus, nachgelagerte Adressierung und Einschränkungen; ein Ethernet-Anschluss allein belegt keine Unterstützung der Protokollumsetzung.

RTU und ASCII sind serielle Nachrichtenformate. Modbus TCP transportiert die Anwendungsanfrage über TCP/IP und verwendet einen anderen Header. RS-485 ist eine häufige physikalische Schnittstelle für serielles Modbus, aber selbst kein Modbus-Nachrichtenformat.

Modbus RTU: Binärer serieller Rahmen mit Geräteadresse, Funktionscode, Daten und CRC; Serielle Schnittstelle, Geräteadresse, Baudrate, Parität, Stoppbits und Zeitvorgaben des Geräts

Modbus ASCII: Serieller Rahmen mit hexadezimalen Daten als ASCII-Zeichen, Startzeichen, LRC und Zeilenende; Ob das Gerät ASCII tatsächlich unterstützt und welche seriellen Einstellungen gelten

Modbus TCP: Anwendungsanfrage in einer TCP-Nachricht mit MBAP-Header; Server-IP, TCP-Port, Client-/Server-Rolle und gegebenenfalls Verwendung des Unit Identifier für ein nachgeschaltetes Gerät

Der Leitfaden für serielle Modbus-Leitungen beschreibt RTU- und ASCII-Rahmen. Der Modbus-TCP/IP-Leitfaden beschreibt den MBAP-Header. TCP-Port 502 ist verbreitet; maßgeblich ist der am Gerät konfigurierte Port.

Funktionscodes und Datenmodell können bei den Varianten gleich erscheinen, die Rahmen sind aber nicht austauschbar. Ein serieller Client kann einen RTU-Rahmen nicht einfach an einen TCP-Server senden. Dafür braucht es ein Gateway oder einen ausdrücklich vorgesehenen Betriebsmodus.

Vor der Nutzlast den Nachrichtenrahmen prüfen

Ein serieller RTU-Rahmen enthält Geräteadresse, Funktion und Daten, gefolgt von einer CRC. ASCII bildet Hexadezimaldaten als Zeichen ab, beginnt mit einer Startmarkierung und nutzt LRC sowie Zeilenende. Modbus TCP setzt die Anwendungsanfrage hinter einen MBAP-Header mit unter anderem Transaktionskennung, Protokollkennung, Länge und Unit Identifier. Der RTU-CRC wird nicht in den TCP-Rahmen übernommen. Die Unterscheidung bestimmt, welches Mitschnittwerkzeug und welcher Gateway-Modus passen.

Für serielle Verbindungen stimmen Port, Verdrahtung und Einstellungen beider Seiten überein: Geräteadresse, Baudrate, Parität, Stoppbits und gerätespezifisches Timing. Ein RS-485-Bus benötigt zudem eine zur Hardware passende Topologie und Terminierung. Bei TCP prüfen Sie Serveradresse und Port, Listener, Route und Firewall. Port 502 ist üblich; ein antwortender TCP-Socket beweist aber keinen vorhandenen Modbus-Datenpunkt.

Nachrichtenstruktur und Funktionscodes im Detail

Das "Herz" von Modbus ist sein Frame, Standardisierung gewährleistet Interoperabilität. Alle Versionen teilen sich die PDU (Anwendungsdaten), unterschiedliche Kapselung.

Modbus RTU Nachrichtenstruktur

Eine RTU-ADU enthält ein Adressbyte, die Anwendungs-PDU und zwei CRC-Bytes; sie umfasst höchstens 256 Byte. Die Datenlänge variiert je nach Funktion. Rahmen müssen durch mindestens 3,5 Zeichenzeiten getrennt sein. Oberhalb von 19.200 bit/s empfiehlt der Serial Line Guide eine feste Zwischenrahmenverzögerung von 1,750 ms; dieser Wert darf nicht als Berechnung der Zeichenzeit bei 9.600 bit/s dargestellt werden.

Feld	Byte	Bedeutung	Beispiel einer 0x03-Anfrage
Serveradresse	1	Serielles Ziel 1–247; 0 ist Broadcast für unterstützte Schreibvorgänge	01
Funktionscode	1	Operation auf Anwendungsebene; 0x03 liest Holding Register	03
Daten	Funktionsabhängig; höchstens 252	Diese Anfrage verwendet zwei Byte für die Startadresse und zwei Byte für die Menge	00 0A 00 01
CRC	2	RTU-Prüffeld; zuerst niederwertiges, dann höherwertiges Byte	<CRC low> <CRC high>

Beispielanfrage: Server 1, Funktion 0x03, nullbasierte Startadresse 10, Menge 1: 01 03 00 0A 00 01 <CRC low> <CRC high>. Eine beispielhafte normale Antwort mit dem vorzeichenlosen Wert 100 lautet 01 03 02 00 64 <CRC low> <CRC high>. Die CRC-Felder sind absichtlich Platzhalter; diese Zeichenfolgen sind daher keine vollständigen, direkt sendbaren Testframes.

Eine Ausnahmerückmeldung setzt das höchste Bit des angefragten Funktionscodes, zum Beispiel wird aus 0x03 der Code 0x83, und enthält einen Ausnahmecode. Häufige Beispiele sind 0x01 (Illegal Function), 0x02 (Illegal Data Address) und 0x03 (Illegal Data Value). Ein serieller Rahmen, der wegen eines Übertragungsfehlers verworfen wird, kann ganz ohne Antwort bleiben.

Modbus TCP Nachrichtenstruktur

Modbus TCP stellt der Anwendungs-PDU den sieben Byte langen MBAP-Header voran. Die Gesamtlänge hängt von Funktion und Antwort ab; eine normale 0x03-Anfrage für ein Register umfasst 12 Byte, die normale Antwort 11 Byte. 12 Byte sind kein allgemeingültiger Mindestwert.

Feld	Byte	Bedeutung
Transaction Identifier	2	Ordnet auf der Verbindung eine Antwort einer Anfrage zu
Protocol Identifier	2	0x0000 kennzeichnet das Modbus-Protokoll
Length	2	Anzahl der nachfolgenden Byte: Unit Identifier plus PDU
Unit Identifier	1	Kann über ein Gateway ein nachgelagertes serielles Gerät auswählen; beachten Sie das Gerätehandbuch
PDU	Bis zu 253	Funktionscode plus funktionsspezifische Anfrage-, normale Antwort- oder Ausnahmedaten

Bei derselben Anwendungsanfrage überträgt TCP Funktionscode und Daten nach dem MBAP-Header, statt die RTU-Adress-/CRC-Rahmung hinzuzufügen. Da TCP ein Bytestrom ist, entspricht ein Netzwerkpaket nicht garantiert genau einer Modbus-ADU; der Empfänger ermittelt die Nachrichtengrenze anhand der MBAP-Längenangabe.

Wichtige Funktionscodes (Wichtigstes Wissen)

Funktionscodes kennzeichnen Operationen. Die Spezifikation unterscheidet öffentliche, benutzerdefinierte und reservierte Bereiche für Funktionscodes. Das höchste Bit wird in Ausnahmerückmeldungen verwendet; die Codes 128–255 bilden keinen allgemeinen Bereich für private Funktionen. In der folgenden Tabelle zählen die Längen nur die funktionsspezifischen Daten nach dem ein Byte langen Funktionscode; RTU- oder MBAP-Rahmung ist nicht enthalten. N bezeichnet die angeforderte Anzahl von Bits oder Registern; ceil(N/8) ist die Zahl der Byte, die N Bits aufnehmen.

Dezimal	Hex	Funktion	Daten / Operation	Anfragedaten in Byte	Daten einer normalen Antwort in Byte	Beispielanwendung
1	0x01	Read Coils	Bitwerte lesen	4	1 + ceil(N/8)	Dokumentierte Coil-Zustände lesen
2	0x02	Read Discrete Inputs	Eingangs-Bitwerte lesen	4	1 + ceil(N/8)	Dokumentierten Eingangsstatus lesen
3	0x03	Read Holding Registers	16-Bit-Registerwörter lesen	4	1 + 2N	Einen dokumentierten Messwert lesen
4	0x04	Read Input Registers	Input-Registerwörter lesen	4	1 + 2N	Einen dokumentierten Eingangswert lesen
5	0x05	Write Single Coil	0xFF00 = EIN; 0x0000 = AUS	4	4 (Echo)	Einen genehmigten Steuerpunkt schreiben
6	0x06	Write Single Register	Ein 16-Bit-Wert	4	4 (Echo)	Einen genehmigten Sollwert schreiben
15	0x0F	Write Multiple Coils	Gepackte Bitwerte	5 + ceil(N/8)	4	Einen genehmigten Coil-Bereich schreiben
16	0x10	Write Multiple Registers	Mehrere 16-Bit-Wörter	5 + 2N	4	Einen genehmigten Registerbereich schreiben
17	0x11	Report Server ID	Servertyp, Betriebsanzeige und gerätespezifische Daten (seriell)	0	Variabel	Servertyp und Betriebsstatus lesen
43 / 14	0x2B / 0x0E	Read Device Identification	MEI-Typ, Read Code und Object Identifier	3	Variabel	Unterstützte Identifizierungsobjekte auslesen

Die funktionsspezifischen Grenzen unterscheiden sich: 0x01/0x02 können bis zu 2.000 Bits lesen; 0x03/0x04 bis zu 125 Register; 0x0F bis zu 1.968 Coils und 0x10 bis zu 123 Register schreiben. Geräte können niedrigere Grenzen festlegen. Der angeforderte Bereich muss vorhanden und die Operation unterstützt sein; siehe die jeweiligen Funktionsabschnitte und Exception Responses in der Anwendungsspezifikation.

Registeradress-Definitionstabelle (Wichtig)

Bezeichnungen wie 00001, 10001, 30001 und 40001 sind konventionelle Labels für getrennte Datengruppen. Das Gruppenpräfix wird nicht als Teil der PDU-Adresse übertragen. Eine Anfrage enthält innerhalb der ausgewählten Gruppe eine nullbasierte 16-Bit-Adresse; ein Clienttool kann den Benutzer jedoch nach einem Label, einer einsbasierten Nummer oder einem Offset fragen. Bestätigen Sie vor der Eingabe die Angaben im Handbuch und die Konvention des Clients.

Konventionelles Label	Datengruppe	Lese-Funktion	Typischer Zugriff	Erster Punkt in konventioneller Notation	Übertragene Adresse
0xxxx	Coils	0x01	Bit lesen/schreiben, sofern unterstützt	00001	0x0000
1xxxx	Discrete Inputs	0x02	Bit nur lesen	10001	0x0000
3xxxx	Input Registers	0x04	16-Bit-Wort nur lesen	30001	0x0000
4xxxx	Holding Registers	0x03	16-Bit-Wort lesen/schreiben, sofern unterstützt	40001	0x0000

Die Beispiele für den jeweils ersten Punkt setzen die in der Tabelle gezeigten konventionellen einsbasierten Labels voraus; sie sind keine universellen Gerätezuordnungen. Ein Temperaturwert kann an einem beliebigen dokumentierten Punkt liegen. Ein 32-Bit-FLOAT belegt im Allgemeinen zwei aufeinanderfolgende 16-Bit-Register; ein Client muss seine IEEE-754-Darstellung anhand der dokumentierten Byte- und Wortreihenfolge des Geräts dekodieren. Modbus überträgt das höherwertige Byte eines 16-Bit-Registers zuerst; Bedeutung und Reihenfolge von Werten über mehrere Register hinweg sind gerätespezifisch.

Handbücher und Engineering-Programme zeigen oft Referenzen wie 00001, 10001, 30001 und 40001. Solche Bezeichnungen kennzeichnen häufig Datengruppe und eine für Menschen lesbare Registernummer. Die Modbus-Anfrage enthält dagegen ein numerisches Adressfeld. Beide Angaben sind nicht automatisch identisch.

40001 bezeichnet häufig das erste Holding Register, dessen Anfrageadresse oft null ist. Das ist eine verbreitete Konvention, aber keine Regel für jedes Handbuch und jeden Treiber. Manche Programme erwarten die Referenznummer, andere einen nullbasierten Offset oder eine einsbasierte Adresse.

Vor dem ersten Leseversuch festhalten:

Datengruppe: Coil, Discrete Input, Input Register oder Holding Register.
Den vom Gerät benötigten Funktionscode.
Die genaue Registerbezeichnung im Gerätehandbuch.
Adresse oder Offset, den die Client-Software erwartet.
Datentyp, Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Einheit.

Nicht pauschal von jeder Nummer eins abziehen. Zuerst das Beispiel im Gerätehandbuch mit der Adresskonvention des Clients oder Gateways abgleichen, dann einen bekannten schreibgeschützten Wert lesen. Adressfeld und Funktionscodes sind in der Modbus-Spezifikation definiert.

Ein Registerbeispiel vollständig durchgehen

Angenommen, ein Handbuch bezeichnet einen Temperaturwert als Holding-Register 40001 und gibt 0,1 Einheit pro Zählschritt an. Viele Clients würden für das erste Holding-Register Funktion 0x03 mit Anfrageadresse null senden; andere Werkzeuge verlangen die angezeigte Referenz. Notieren Sie Handbuchbezeichnung und tatsächlich gesendete Adresse. Ein Rohwert 253 bedeutet nur dann 25,3 Einheiten, wenn das Handbuch Skalierung und angenommenen Zahlentyp bestätigt. Das ist ein Beispiel, keine allgemeine Gerätemap.

Bei 32-Bit-Werten über zwei 16-Bit-Register muss die Gerätebeschreibung außerdem Byte- und Wortreihenfolge festlegen. Eine plausible, aber falsche Zahl ist häufig ein Darstellungsproblem statt eines Netzwerkfehlers. Prüfen Sie Adresskonvention und Kodierung an einem schreibgeschützten Wert, der unabhängig gemessen werden kann, bevor Sie eine größere Registerliste auswerten.

Vergleichen Sie den Handbuchverweis, den Funktionscode und die tatsächlich übertragene Adresse gemeinsam; 40001 ist keine universelle Eingabe für Clienttools.

Technische Unterschiede zwischen Modbus RTU und TCP

Wählen Sie RTU oder TCP anhand der vorhandenen Geräteschnittstellen, Verdrahtung, Abfragelast, Netzwerkauslegung und Schutzanforderungen. Der folgende Vergleich beschreibt technische Aspekte, keine gemessene Benchmark von 2025 oder garantierten Leistungsgrenzen:

Aspekt	Modbus RTU	Modbus TCP	Auswahl / Validierung
Zugrunde liegende Verbindung	Unterstützte serielle Schnittstelle, häufig RS-485	TCP/IP, häufig über Ethernet	Prüfen Sie Geräteschnittstelle und Gateway-Modus.
Reichweite	Hängt von Kabel, Baudrate, Transceivern und Topologie ab	Hängt von Netzwerkmedien und geroutetem Pfad ab	Gerätespezifikationen verwenden; keine universelle Ende-zu-Ende-Reichweite.
Durchsatz	Serielle Rate plus Rahmenabstände und Abfrageaufwand	Netzwerk- und Serververarbeitung plus Anfrageplanung	Messen Sie den vollständigen Abfragezyklus unter erwarteter Last.
Störungen / Isolation	Verdrahtung, Erdung, Isolation und Abschluss sind relevant	Medien, Isolation, Schirmung und Installation sind relevant	Keine der Rahmenvarianten garantiert Störfestigkeit.
Anzahl der Geräte	Adressen 1–247; elektrische Segmentkapazität kann geringer sein	Begrenzt durch Verbindungen, Serverressourcen und Netzwerkauslegung	Prüfen Sie elektrische Last und Anwendungsgrenzen.
Konfiguration	Serielle Einstellungen, Verdrahtung, Adresse und Registerzuordnung	IP, Port, Rollen, Unit Identifier und Registerzuordnung	Ein erfolgreicher Ping oder offener Port ist kein Anwendungstest.
Energie / Kosten	Abhängig von Implementierung und Hardware	Abhängig von Implementierung und Hardware	Vergleichen Sie konkrete Gerätespezifikationen und Projektkosten.
Sicherheit	Keine native Benutzerauthentifizierung oder Verschlüsselung bei einfachem RTU	Keine native Benutzerauthentifizierung oder Verschlüsselung bei einfachem TCP	Verwenden Sie eine geschützte Architektur; prüfen Sie jede zusätzliche Sicherheitsimplementierung.
Antwortzeit	Geräteverarbeitung, serielle Rate, Abfragen und Wiederholungen	Geräteverarbeitung, Last, Netzwerklatenz und Parallelität	Keines der Verfahren garantiert harte Echtzeit.

Praktische Anwendungsszenarien in der Industrie

Modbus wird in vielen industriellen Umgebungen zur Datenerfassung und überwachten Steuerung eingesetzt. Die folgenden Beispiele zeigen mögliche Anwendungsmuster, keine verifizierten Kundeneinsätze oder allgemein gültigen Registerzuordnungen von Herstellern. Jede Adresse, Skalierung und zulässige Schreiboperation muss dem Handbuch des konkreten Geräts entnommen werden.

Energiewirtschaft

Zähler und Schaltanlagen: dokumentierte Spannungs-, Strom-, Energie- oder Statuspunkte über die unterstützten Lesefunktionen auslesen.
Schutz- und Steuergeräte: unterstützte Diagnosedaten erfassen; ein Reset oder ein anderer Schreibvorgang erfordert die dokumentierte Operation und die Freigabe des Prozessverantwortlichen.
Umgebungsüberwachung: dokumentierte Gas- oder Schaltschrankmesswerte und Alarmstatus auslesen. Eine Bezeichnung der Datengruppe allein definiert keinen Messwert.

Umwelt- und Wasserwirtschaft

Pumpen und Füllstandsmessgeräte: Füllstand und Betriebsstatus erfassen; Schreibzugriffe auf Drehzahl oder Steuerung hängen von der dokumentierten Schreibzuordnung des Geräts ab.
Druck- und Durchflussmessumformer: genaues Modell, Registeradresse, Datentyp, Skalierung und Einheit bestätigen. Eine allgemeine Druckzuordnung zu 40001 gilt nicht für alle Messumformer.
Ein möglicher Einsatz nutzt ein fachgerecht ausgelegtes RS-485-Segment und ein Protokoll-Gateway für einen SCADA-Client. Segmentkapazität und Umsetzungsfunktionen müssen für den konkreten Einsatz geprüft werden.

Erdöl-/Petrochemie

Prozessmessgeräte: unterstützte Messwerte über mehrere Register mit der dokumentierten FLOAT- oder Integer-Interpretation und Wortreihenfolge auslesen.
Leitsystemintegration: Ein Modbus-TCP-Server oder RTU/TCP-Gateway kann ausgewählte Punkte einem DCS- oder Leitsystem-Client bereitstellen, wenn Funktionen und Leistung überprüft wurden.
Steuerparameter: Massen-Schreibvorgänge wie 0x10 müssen einen genehmigten, dokumentierten Bereich und die erwartete Wirkung verwenden; das Prozessergebnis ist nach einem vereinbarten Verfahren zu prüfen.

Fabrikautomation

Gerätedatenerfassung: dokumentierte Zählerstände, Statuswerte und Messwerte von Steuerungen erfassen, die Modbus unterstützen, oder über ein geprüftes Schnittstellen-Gateway.
Die Integration in ein anderes industrielles Netzwerk erfordert eine Anwendung oder ein Gateway, das beide Protokolle implementiert und eine konfigurierte Zuordnung bereitstellt. Sie darf nicht aus einem gewöhnlichen Router oder einem ungeprüften Fabrikbeispiel abgeleitet werden.

Photovoltaik/Erneuerbare Energien

Wechselrichter und Generatoranschlusskästen: dokumentierte Betriebswerte und Alarme über die Modbus-Zuordnung des genauen Modells erfassen.
Umweltmessgeräte: Einstrahlungs-, Wetter- oder Alarmwerte anhand des Sensorhandbuchs zuordnen, statt eine allgemeine Registerzuweisung anzunehmen.
Eine mögliche Solarstandort-Architektur kombiniert lokale serielle Erfassung mit einem IP-verbundenen Gateway und einer Leitebene. Link-Budget, Aktualisierungsintervalle und unterstützte Cloud-Veröffentlichung müssen projektspezifisch geprüft werden.

Typische Bereitstellung von Modbus in Industriegateways/-routern

Ein Modbus-fähiges Industrie-Gateway kann serielle Feldgeräte mit einem IP-Leitsystem verbinden oder ausgewählte Register für eine andere Anwendung erfassen. Der Nutzen hängt von den Funktionen ab, die das genaue Modell und die Firmware implementieren. RTU/TCP-Umsetzung, transparenter serieller Transport, IP-Routing und MQTT-Veröffentlichung sind getrennte Funktionen mit jeweils eigenen Konfigurations- und Validierungsanforderungen.

Typische Architektur

[Serial field devices] -- RTU / RS-485 -- [RTU/TCP protocol gateway] -- Modbus TCP -- [Client]

Optional, only if supported and configured:
[Polling / data application] -- mapped MQTT data --> [Broker / cloud]
[Polling / data application] -- mapped OPC UA data --> [Supervisory system]

Protokollumsetzung: Ein RTU/TCP-Gateway ordnet TCP-Transaktionen und Unit Identifier dem seriellen Bus zu. Transparenter Serial-over-IP-Transport ist ein anderer Betriebsmodus.
IP-Routing: leitet IP-Verkehr zwischen Netzen weiter; es liest nicht von selbst Register aus und setzt RTU nicht in TCP um. Prüfen Sie Modbus-Filterung oder VPN-Funktionen anhand der Dokumentation des genauen Produkts.
Datenerfassung und Edge-Logik: Eine unterstützte Anwendung kann Register abfragen, Einheiten interpretieren, Daten veröffentlichen oder eine Alarmregel auswerten. Skriptsprachen, MQTT-Nutzdaten und unterstützte Operationen hängen vom Produkt ab.

Ein IP-Router leitet IP-Verkehr zwischen Netzschnittstellen weiter. Daraus folgt nicht, dass er Modbus-Register liest oder serielle RTU-Rahmen in Modbus-TCP-Anfragen umwandelt. Die Umsetzung findet auf Anwendungsebene statt und erfordert ein dafür ausgelegtes Gateway oder einen entsprechenden Gerätemodus. RFC 1812 beschreibt die Weiterleitungsaufgaben eines IPv4-Routers.

Das ist wichtig, wenn eine SPS seriell angeschlossen ist, der Monitoring-Client aber im IP-Netz sitzt. Ein Serial Device Server kann serielle Bytes über eine IP-Verbindung transportieren und das serielle Protokoll dabei unverändert lassen. Ein Protokoll-Gateway beendet dagegen eine Modbus-Variante und erzeugt Anfragen der anderen Variante.

Prüfen Sie den tatsächlichen Betriebsmodus, wo die Abfrage stattfindet und wie Gerätekennungen und Registerreferenzen zugeordnet werden. Aus „Industrierouter“ oder „Modbus-kompatibel“ allein lassen sich weder eine serielle Schnittstelle noch eine Umsetzungsfunktion ableiten. Entscheidend sind das konkrete Modell und seine Firmware-Dokumentation.

Die Gateway-Rolle zwischen seriell und IP festlegen

Ein serieller Server kann serielle Bytes über IP transportieren, ohne RTU-Anfragen in Modbus TCP umzusetzen. Ein Protokoll-Gateway beendet eine Seite und erzeugt Nachrichten für die andere. Seine Konfiguration muss Client-/Server-Rollen, nachgeschaltete Gerätekennung, Zeitüberschreitungen und Adresskonventionen zuordnen. Der Unit Identifier in Modbus TCP kann hinter einem Gateway ein serielles Gerät auswählen; seine Bedeutung bei einem direkten TCP-Server hängt vom Gerät ab. Maßgeblich ist der genaue Gerätemodus im Handbuch.

Liegt der Polling-Client im Zentralnetz, verfolgen Sie Client, IP-Route und Firewall, Gateway-Listener, seriellen Bus, Zielgerät und Rückantwort. Halten Sie fest, wo Polling stattfindet und wer Wiederholungen und Timeouts steuert. Die Verbindung kann aktiv sein, obwohl das Gateway eine falsche serielle Adresse oder einen ungeeigneten Registeroffset nutzt. Weder Ethernet-Port noch die Aufschrift „Modbus-kompatibel“ belegen eine Protokollumsetzung.

IP-Routing, transparenter serieller Transport und RTU/TCP-Protokollumsetzung sind getrennte Funktionen. Prüfen Sie den genauen Gateway-Modus.

Bereitstellungsschritte Überblick

Wählen Sie die Hardware nach den tatsächlichen seriellen Schnittstellen, Ethernet-Anforderungen, Umgebungsbedingungen, Montage- und Stromversorgungsanforderungen aus; Anzahl der seriellen Ports und Schutzart sind modellspezifisch.
Wählen Sie den richtigen Betriebsmodus und dokumentieren Sie Client-/Serverrollen, serielle Adressen, TCP-Unit-Identifier, Registerzuordnungen, Zeitüberschreitungen und Aktualisierungsintervalle.
Stellen Sie einen geeigneten geschützten Netzwerkpfad und eine Zugriffspolitik bereit. Einfaches Modbus ist keine AES-Sicherheitserweiterung; verwenden Sie Sicherheitsfunktionen nur, wenn sie von allen erforderlichen Endpunkten implementiert und korrekt konfiguriert sind.
Aktivieren Sie unterstützte Diagnoseprotokolle und Überwachung und prüfen Sie zunächst eine dokumentierte schreibgeschützte Transaktion, bevor Sie die Abfrageliste erweitern.

Dokumentieren Sie bei einem entfernten Feldeinsatz, welches Gerät die seriellen Messgeräte abfragt, welches System die Werte empfängt und wie der Rückweg geschützt wird. Ein Einsatzergebnis oder eine Wartungskosteneinsparung darf nur behauptet werden, wenn Messungen des jeweiligen Projekts dies belegen; diese beispielhafte Architektur behauptet keine solche Einsparung.

Vor der Konfiguration genügt zunächst eine Seite mit Geräten und den benötigten Datenpunkten:

Eintrag	Dokumentieren
Endpunkt	Gerätemodell, Firmware und Client- oder Server-Rolle
Variante	RTU, ASCII oder TCP
Verbindung	Serielle Parameter und Geräteadresse oder IP-Adresse und konfigurierter TCP-Port
Datenpunkt	Datengruppe, Funktionscode, Handbuchreferenz und Client-Adresse/-Offset
Interpretation	Datentyp, Vorzeichen, Byte-/Wortreihenfolge, Skalierung und Einheit
Zugriff	Schreibgeschützt oder beschreibbar laut Gerätehandbuch

Konfigurationsablauf (sehr detailliert)

Die Konfiguration beginnt mit den Handbüchern von Gerät und Client. Halten Sie vor dem Test die unterstützte Variante, elektrische Schnittstelle, seriellen oder IP-Einstellungen, Konvention für die Anfrageadresse und Dateninterpretation fest. Ein Simulator kann bei der Validierung einer Clientkonfiguration helfen; eine erfolgreiche Simulation beweist jedoch nicht, dass ein reales Gerät dieselbe Zuordnung oder dasselbe Verhalten hat.

Konfiguration Modbus RTU (RS485)

Schritt 1: Kommunikationsparameter bestimmen

Übernehmen Sie die folgenden Parameter aus dem Handbuch des genauen Servers und seinen konfigurierten Einstellungen. Die Werte unten sind Beispiele und keine universellen Standardwerte:

Parameter	Beispieleinstellung	Zu prüfen
Baudrate	9.600 bit/s	Die Rate wird unterstützt und stimmt bei den kommunizierenden Geräten überein.
Datenbits	8 bei RTU	RTU verwendet acht Datenbits pro Zeichen.
Parität	Gerade (Even)	Der Serial Line Guide nennt gerade Parität als Standard; Endpunkte können weitere konfigurierte Modi unterstützen.
Stoppbits	1 mit gerader/ungerader Parität; 2 ohne Parität	Der Modus ohne Parität im Serial Line Guide fügt ein Stoppbit hinzu. Wenn ein Gerät 8N1 dokumentiert, folgen Sie seiner unterstützten Implementierung und konfigurieren Sie beide Enden einheitlich.
Serveradresse	1–247; Beispiel 1	Verwenden Sie die konfigurierte eindeutige Adresse und keinen angenommenen Werksstandard.

Verwenden Sie einen seriellen Mitschnitt oder die Diagnoseoberfläche des Geräts, um die tatsächliche Rahmung und Antworten zu prüfen. Ein allgemeines Terminalprogramm ist nur dann hilfreich, wenn es das benötigte serielle Byteformat und Timing senden und anzeigen kann.

Schritt 2: Verkabelung & Hardware

Gleichen Sie Signalpolarität und Bezugspotential anhand der Handbücher beider Geräte ab. Die Bezeichnungen A/B sind herstellerübergreifend nicht einheitlich; behandeln Sie A+ und B− nicht als universelle Kennzeichnungen.
Verwenden Sie eine Bus-/Stammleitungstopologie mit kurzen Abzweigungen und Abschlüssen an den beiden physischen Enden, wie für Kabel und Geräte erforderlich. Legen Sie Biasing, Schirmung und Erdung gemäß Installationsdesign fest.
Prüfen Sie zuerst Durchgang, Kurzschlüsse, Versorgung und dokumentierte Isolation. Bewerten Sie die Signalqualität mit geeigneten Messgeräten; ein einzelner Grenzwert für die Leerlaufspannung validiert keine vollständige RS-485-Installation.

Schritt 3: Registertabelle eingeben

Erstellen Sie anhand der Herstellerdokumentation eine Projektzuordnung. Die folgenden erfundenen Punkte veranschaulichen die zu dokumentierenden Felder; sie sind keine verwendbare Zuordnung für ein genanntes Produkt:

Punkt	Handbuchreferenz	Anfrageadresse / Funktion	Typ / Wörter	Skalierung	Einheit
Temperatur	40001	0 / 0x03, wenn der Client nullbasierte Offsets verwendet	UINT16 / 1	Rohwert ÷ 10	°C
Luftfeuchtigkeit	40002	1 / 0x03, nach derselben Konvention	UINT16 / 1	Rohwert ÷ 10	% rF
Status	00001	0 / 0x01, nach derselben Konvention	Coil / 1 Bit	Dokumentierte Bitbedeutung	—

Schritt 4: Polling im Master konfigurieren

Wählen Sie einen SPS- oder Gateway-Client, der die benötigte Modbus-Variante unterstützt, und lesen Sie die Dokumentation des konkreten Funktionsbausteins oder der Anwendung.
Nur für die beispielhafte Zuordnung: serieller Server 1, Funktion 0x03, nullbasierte Startadresse 0, Menge 2. Wählen Sie ein anfängliches Intervall wie 1 s nur, wenn Geräteverarbeitungszeit und Buslast es zulassen.
Die allgemeine Anfrage unten zeigt die erforderlichen Konzepte; sie ist Pseudocode und weder ein Siemens-Funktionsbaustein-Aufruf noch eine validierte API einer Softwarebibliothek.

request = {
    variant: "RTU",
    server_address: 1,
    function_code: 0x03,
    start_address: 0,   // only for the illustrative map
    quantity: 2
}
response = modbus_client.read(request)
verify_normal_response(response, expected_registers=2)

Schritt 5: Datentypen interpretieren

Beispiel für Skalierung: Der Rohwert 256 bedeutet nur dann 25,6 °C, wenn die dokumentierte Skalierung Rohwert ÷ 10 lautet.
Werte über mehrere Register: Stellen Sie die dokumentierte Bytefolge wieder her und dekodieren Sie den angegebenen Datentyp. Eine Bitverschiebung mit ODER-Verknüpfung erzeugt ein Integer-Bitmuster, aber für sich genommen keine FLOAT-Umwandlung.
Der folgende schreibgeschützte Pseudocode vermeidet die Annahme einer bestimmten Bibliotheksversion. Produktivcode muss Verbindungsfehler, Ausnahmen, Antwortlänge und Freigabe von Ressourcen behandeln.

Beispielhafter Pseudocode:

response = serial_client.read_holding_registers(
    server_address=1, start_address=0, quantity=1
)
if response.is_normal and len(response.registers) == 1:
    temperature_c = response.registers[0] / 10.0  # illustrative scale
else:
    record_error(response)

Konfiguration Modbus TCP

Eine erfolgreiche TCP-Verbindung zu Port 502 belegt weder eine gültige Modbus-Transaktion noch einen korrekt interpretierten Messwert.

Schritt 1: Slave-IP bestätigen

Bestätigen Sie die konfigurierte IP-Adresse und Subnetzmaske des Servers, zum Beispiel 192.168.1.10/24. Ein Standard-Gateway wird für Verkehr außerhalb des Subnetzes benötigt und muss zur tatsächlichen Netzwerkauslegung passen.
Bestätigen Sie den konfigurierten Modbus-TCP-Listener und erlauben Sie nur den vorgesehenen Clientpfad durch die Firewall; Port 502 ist üblich.
Ein Ping- oder TCP-Verbindungstest prüft nur einen Teil des Pfads. Senden Sie eine dokumentierte schreibgeschützte Modbus-Anfrage, um die Anwendung zu verifizieren.

Schritt 2: Verbindungsparameter setzen

Legen Sie Zeitüberschreitungen, Wiederholungen, Abfrageintervalle und zulässige Verbindungszahlen innerhalb der Client- und Servergrenzen fest und validieren Sie sie unter erwarteter Last.
TCP-Keep-Alive kann helfen, eine ausgefallene Verbindung zu erkennen, bietet aber keine Anwendungsauthentifizierung. Einfaches Modbus TCP erhält nicht dadurch TLS, dass eine allgemeine Clientoption gesetzt wird; verwenden Sie einen unterstützten sicheren Endpunkt oder einen geschützten Netzwerkpfad.

Schritt 3: Registerlesen konfigurieren

Verwenden Sie dieselbe dokumentierte Funktion und Registerinterpretation wie beim Server, soweit passend; konfigurieren Sie außerdem dessen TCP-Endpunkt und den vom Endpunkt oder Gateway benötigten Unit Identifier. Dies ist konzeptioneller Pseudocode und keine Python-API für eine bestimmte Version:

Beispielhafter Pseudocode:

client = tcp_modbus_client(host="192.168.1.10", port=502)
response = client.read_holding_registers(
    unit_identifier=1, start_address=0, quantity=1
)
verify_normal_response(response, expected_registers=1)
client.close()
# Address 0 and Unit Identifier 1 are illustrative, not universal settings.

Beispiel: Konfigurationsfallbeispiel für Modbus RTU/TCP vor Ort in der Automatisierungstechnik

Beispielszenario: Eine Wasseraufbereitungsanlage erfasst Temperatur- und pH-Messwerte von einem seriellen Gerät und stellt die zugeordneten Werte einer autorisierten MQTT-Anwendung bereit. Ein optionaler Modbus-TCP-Pfad bedient einen Leitsystem-Client. Ziel ist die Validierung der gesamten Erfassungs- und Interpretationskette; es handelt sich nicht um einen gemessenen Kundeneinsatz.

Geräte:

Feldgerät: ein Messgerät, für das die Unterstützung der benötigten Modbus-RTU-Punkte dokumentiert ist; beispielhaft Adresse 5, 9.600 bit/s, 8E1. Prüfen Sie tatsächliche Schnittstelle und Einstellungen anhand des Handbuchs.
Gateway oder Edge-Controller: unterstützt ausdrücklich RTU-Abfragen, die erforderliche Dateninterpretation und MQTT-Veröffentlichung; optionale RTU/TCP-Umsetzung oder ein TCP-Server müssen separat geprüft werden.
Anwendungsendpunkt: ein autorisierter MQTT-Broker und Subscriber mit für den Einsatz geeigneter Netzanbindung und Transportabsicherung.

Detaillierter Ablauf:

Verbinden Sie das Feldgerät mit den dokumentierten seriellen Anschlüssen des Gateways und dessen Ethernet-Schnittstelle mit dem vorgesehenen Netz. Beachten Sie Polarität, Abschluss, Bezugspotential und Isolationsanforderungen.
Konfigurieren Sie den seriellen Port passend zum Gerät; verwenden Sie 9.600 bit/s, 8E1 und Serveradresse 5 nur dann als Beispiel, wenn das Handbuch diese Einstellungen zulässt.
Richten Sie eine schreibgeschützte Abfrageaufgabe für die dokumentierte Registerzuordnung ein. Für eine beispielhafte nullbasierte Zuordnung lesen Funktion 0x03, Startadresse 0 und Menge 2 die Temperatur- und pH-Wörter aus. Bestätigen Sie die tatsächliche Zuordnung und das unterstützte Intervall, bevor Sie einen Zeitplan von 5 s verwenden.
Dekodieren Sie die beispielhaften UINT16-Werte mit dokumentierter Skalierung: Temperatur = erstes Wort ÷ 10 und pH = zweites Wort ÷ 100. Prüfen Sie einen bekannten physikalischen Wert unabhängig.
Konfigurieren Sie Broker, Zugangsdaten, Transport und Topic in der Anwendung, die MQTT tatsächlich unterstützt. Ordnen Sie Messwerte mit Namen und, sofern verfügbar, einem gültigen Erfassungszeitstempel einer Nutzlast zu; nehmen Sie nicht an, dass jedes RTU/TCP-Gateway MQTT veröffentlicht.
Falls erforderlich und unterstützt, richten Sie die separate Modbus-TCP-Freigabe mit dokumentiertem Unit Identifier und Registerzuordnung ein. Beschränken Sie den Zugriff und validieren Sie das schreibgeschützte Verhalten vor genehmigten Schreibvorgängen.
Testen Sie serielle Antworten, zugeordnete Werte, MQTT-Zustellung und die Interpretation durch den Subscriber. Bewerten Sie beobachtete Zeitüberschreitungen und Übertragungsfehler anhand der Projekt-Abnahmekriterien statt eines erfundenen universellen Fehlerquotenziels.

Ausgabebeispiel (MQTT-Nachricht):

Beispielhafte JSON-Nutzlast:

{
  "device": "PH001",
  "temperature_c": 23.6,
  "ph": 7.12,
  "status": "OK"
}

Häufige Fehler und Lösungsansätze

Gehen Sie bei der Fehlersuche vom beobachteten Ergebnis und nicht von angenommenen Fehlerwahrscheinlichkeiten aus. Die Tabelle trennt Pfadfehler, Übertragungsfehler, Ausnahmen auf Anwendungsebene und die Interpretation von Werten. Halten Sie nach Möglichkeit die genaue Anfrage, Antwort und Gerätekonfiguration fest:

Symptom	Mögliche Ursachen	Prüfung / Maßnahme	Hilfreiche Nachweise
Keine Antwort / Zeitüberschreitung	Falscher Endpunkt oder serielle Adresse; Verdrahtung, serielle Einstellungen, Listener, Route oder Firewall	Prüfen Sie den relevanten Pfad und die dokumentierten Einstellungen. Prüfen Sie bei RS-485 die Polarität anhand der Handbücher, bevor Sie die Verdrahtung ändern.	Gerätediagnose, Anfrage-Mitschnitt, Netzwerk-/serieller Trace
CRC-/LRC-Fehler	Beschädigte oder gestörte serielle Verbindung, falsche Rahmung, Abschluss- oder Biasing-Problem	Prüfen Sie Baudrate, Parität, Stoppbits, Verkabelung, Topologie und Isolation. Verwenden Sie Abschluss und Erdung gemäß Geräteanforderung.	Serieller Mitschnitt, bei Bedarf Oszilloskop
Modbus-Ausnahme	Nicht unterstützte Funktion, nicht vorhandener Adressbereich oder ungültiger Anfragewert	Interpretieren Sie die Ausnahme und prüfen Sie Funktion, Bereich und Zugriffsrechte anhand des Handbuchs, bevor Sie das Netzwerk ändern.	Ausnahmecode, angefragte PDU, Geräte-Registerzuordnung
Falscher oder verschobener Wert	Adresskonvention, Vorzeichen, Skalierung, Einheiten oder Reihenfolge mehrerer Register	Lesen Sie einen bekannten Punkt aus; vergleichen Sie übertragene Adresse und dokumentierte Interpretation.	Rohwörter, Handbuch, unabhängig bekannter Messwert
Sporadischer Ausfall oder veralteter Wert	Last, Abfrage-/Wiederholungsverhalten, Stromversorgung, Anwendungscache oder Instabilität der physischen Verbindung	Zeitstempel und Fehler korrelieren, Aktualisierungsintervalle und Last prüfen und anschließend die fehlerhafte Stufe isolieren.	Gateway-Protokolle, Serverlast, Erfassungszeitstempel
Keine Broadcast-Antwort	Es wurde fälschlich eine Antwort für die serielle Adresse 0 erwartet	Unterstützte serielle Broadcast-Schreibvorgänge geben keine Antwort zurück; verwenden Sie Broadcast weder zum Lesen noch für erste Tests.	Spezifikation der seriellen Leitung und Gerätedokumentation

Erfassen Sie lokale rohe Anfragen und Antworten, sofern die Geräte dies unterstützen. Halten Sie Funktionscode, serielle Adresse oder Unit Identifier, Anfrageadresse, zurückgegebene Daten und relevantes Timing zusammen fest. Verwenden Sie vertrauenswürdige Diagnosewerkzeuge und die offiziellen Rahmendefinitionen; ein plausibel angezeigter Wert allein validiert die Transaktion nicht.

Beginnen Sie mit einem dokumentierten schreibgeschützten Punkt. Prüfen Sie Antwort und interpretierten Wert, bevor Sie weitere Punkte hinzufügen oder Schreibzugriffe zulassen. Trifft eine Antwort ein, aber der angezeigte Wert stimmt nicht, prüfen Sie zuerst Registerzuordnung und Datenformat, bevor Sie den Netzwerkpfad ändern.

Wenn ein SPS-, Antriebs- oder SCADA-Wert ausbleibt oder veraltet ist, hilft der separate Leitfaden zur PLC-/Modbus-Fehlersuche.

Nach beobachtetem Fehlerbild diagnostizieren

Bei keiner Antwort prüfen Sie Ziel, Listener, Route und Firewall für TCP oder Verdrahtung, serielle Einstellungen und Geräteadresse für RTU. Eine Exception bedeutet, dass ein Modbus-Endpunkt antwortete; kontrollieren Sie Funktion, Bereich und Zugriffsrecht. Ein falscher Wert verweist auf Adresskonvention, Vorzeichen, Skalierung oder Byte-/Wortreihenfolge. Ein veralteter Wert kann aus Polling-Intervall, Anwendungscache oder einem unveränderten Gerätewert stammen. Diese Fälle sollten getrennt bearbeitet werden.

Beginnen Sie die Inbetriebnahme mit einem dokumentierten schreibgeschützten Punkt und sichern Sie Anfrage und Antwort, falls die Hardware einen Mitschnitt erlaubt. Ergänzen Sie Punkte in kleinen Gruppen und bewahren Sie Registermap, Einheiten und getestete Client-Einstellungen auf. Schreibfunktionen erhalten erst nach Freigabe des Prozessverantwortlichen einen bekannten Zielpunkt und eine sichere Rückkehrmöglichkeit. Für Fernzugriff über nicht vertrauenswürdige Netze sind Transportschutz, Firewall und Benutzerberechtigung getrennt zu planen; einfaches Modbus liefert sie nicht.

Beginnen Sie mit einem dokumentierten schreibgeschützten Punkt. Prüfen Sie Antwort und Interpretation, bevor Sie die Abfrageliste erweitern oder einen genehmigten Schreibvorgang zulassen.

Zusammenfassung

Modbus wird seit seinem Ursprung 1979 weiter genutzt, weil es ein einfaches Anfrage-/Antwortdatenmodell bietet und von etablierter Industrieausrüstung unterstützt wird. Seine praktische Stärke ist kein allgemeiner Zuverlässigkeitsprozentsatz: Dokumentierte Punkte lassen sich austauschen, wenn Gerätezuordnung, Schnittstelle und Clientverhalten verstanden und geprüft sind.

Gateways können eine bestehende Modbus-Installation in eine IP-, Leitsystem- oder Cloud-Anwendung einbinden, wenn die erforderliche Umsetzung und Datenfunktion unterstützt werden. Schnellere Netze oder eine 5G-Verbindung verleihen Modbus weder eine garantierte Abfragezeit noch synchronisierte Zeitstempel oder TSN-Verhalten. Bewerten Sie für die Anwendung den vollständigen Erfassungspfad, die Interpretation und die Schutzanforderungen.

Verwenden Sie diesen Leitfaden zusammen mit den Anwendungs-, Serial-Line- und TCP/IP-Spezifikationen der Modbus Organization sowie den Handbüchern der konkreten Geräte. Beginnen Sie mit einem dokumentierten schreibgeschützten Punkt, prüfen Sie die tatsächliche Antwort und den technischen Messwert und erweitern Sie anschließend die Konfiguration. Eine klare Registerzuordnung und geprüfte Einstellungen sind hilfreicher als eine vermeintlich universelle Anleitung.

Häufige Fragen

Sind Modbus RTU und Modbus TCP dasselbe Protokoll?

Sie verwenden verwandte Modbus-Anwendungsdaten und Funktionscodes, unterscheiden sich aber in Rahmen und Übertragung. RTU verwendet einen seriellen Rahmen; Modbus TCP ergänzt einen MBAP-Header und läuft über TCP/IP.

Bedeutet Register 40001 immer Anfrageadresse null?

Nein. 40001 steht oft für das erste Holding Register, dessen Anfrageadresse häufig null ist. Handbücher, Treiber und Gateways können Adressen unterschiedlich darstellen oder erwarten. Die Konvention beider Enden muss geprüft werden.

Kann ein gewöhnlicher Industrierouter Modbus RTU in Modbus TCP umsetzen?

Nicht automatisch. IP-Routing und Modbus-Umsetzung sind unterschiedliche Funktionen. Das konkrete Gerät muss einen Gateway- oder Umsetzungsmodus bereitstellen; sein Handbuch muss die Zuordnung von seriellem Gerät und Registeranfragen erklären.

Welche Angaben werden für die Fehlersuche gebraucht?

Gerät und Firmware, RTU-/ASCII-/TCP-Modus, Client-/Server-Rollen, serielle oder IP-Einstellungen, Gerätekennung, Registertabelle, angefragter Funktionscode, Adresskonvention und Wertkodierung. Falls verfügbar, hilft ein kurzer Mitschnitt von Anfrage und Antwort.

Beweist eine Verbindung zu TCP-Port 502, dass Modbus bereit ist?

Nein. Sie zeigt nur einen erreichbaren TCP-Pfad und Listener. Senden Sie eine dokumentierte schreibgeschützte Modbus-Anfrage und prüfen Sie Funktion, gegebenenfalls Unit Identifier, Adresse und interpretierten Wert.

Was bedeutet eine Modbus-Exception?

Die Nachricht hat einen Modbus-Endpunkt erreicht. Prüfen Sie Exception, angefragte Funktion und Adressbereich, bevor Sie Routen ändern. Welche Funktionen und Datenpunkte vorhanden sind, bestimmt das Gerätehandbuch.

Darf ich bei der Inbetriebnahme mit einer Schreibfunktion testen?

Lesen Sie zuerst einen dokumentierten schreibgeschützten Punkt. Schreiben kann einen laufenden Prozess verändern und gehört nur zu einem vom Prozessverantwortlichen freigegebenen Test mit bekanntem Ziel, Ergebnisprüfung und sicherer Rückkehr.

Referenzen

MODBUS Application Protocol Specification V1.1b3 — Datenmodell, Adressierung, Formate der Funktionscodes, Mengenbegrenzungen und Ausnahmeantworten.

MODBUS over Serial Line Specification and Implementation Guide V1.02 — Serielle Adressierung, RTU-/ASCII-Rahmung, Timing, Parität, Stoppbits und physische Implementierung.

MODBUS Messaging on TCP/IP Implementation Guide V1.0b — MBAP-Header, TCP-Client/Server-Austausch und Gateway-Integration.