Modbus hat jede große Veränderung in der industriellen Netzwerktechnik überstanden – von serieller Punkt-zu-Mehrpunkt-Verkabelung bis hin zu Switched Ethernet. Seine Langlebigkeit wird häufig seiner Einfachheit zugeschrieben, doch diese Beschreibung kann Ingenieure in die Irre führen: Das Protokoll ist kompakt, aber eine zuverlässige Installation hängt weiterhin von einer disziplinierten Adressierung, Zeitplanung, Verkabelung und Dateninterpretation ab.

Bei einem Modernisierungsprojekt lautet die entscheidende Frage selten, ob ein Gerät „Modbus unterstützt“. Entscheidend ist vielmehr, ob zwei Geräte sich über das Übertragungsmedium, die Geräteidentität, die Registerbedeutung, die Byte-Reihenfolge, die Abfragerate und das Verhalten im Fehlerfall einig sind. Diese Details entscheiden darüber, ob die Inbetriebnahme eine Stunde oder eine Woche dauert.

Eine Modbus-Verbindung überträgt Anfragen und Antworten, doch der Systemintegrator muss festlegen, welche Bedeutung jede Adresse im Prozess hat.

Ein Datenmodell, mehrere Übertragungsmedien

Das klassische Modbus organisiert Gerätedaten in Spulen, diskreten Eingängen, Eingangsregistern und Halteregistern. Spulen und diskrete Eingänge repräsentieren Einzelbit-Zustände; Eingangs- und Halteregister sind 16-Bit-Wörter. Ob Daten nur gelesen oder auch geschrieben werden können, wird durch den Objekttyp und die Geräteimplementierung bestimmt.

Modbus RTU verpackt die Protokolldateneinheit in einen seriellen Rahmen mit einer Geräteadresse und einer CRC-Fehlerprüfung. Modbus TCP überträgt dasselbe grundlegende Funktionscode-Modell über TCP/IP und ergänzt einen MBAP-Header. Ethernet beseitigt damit Einschränkungen der seriellen Rahmenbildung, löst jedoch nicht automatisch Unklarheiten in der Registerzuordnung oder eine mangelhafte Abfrageplanung.

Warum die Adressnotation Fehler bei der Inbetriebnahme verursacht

In der Dokumentation kann das erste Halteregister als 40001 bezeichnet sein, während die Nachricht selbst einen nullbasierten Offset von 0 verwendet. Manche Software erwartet die dokumentierte Referenz, andere den rohen Offset. Testen Sie vor einer Codeänderung einen bekannten Wert und dokumentieren Sie, ob der Treiber die Konvention „4xxxx“ intern anwendet.

Die Byte-Reihenfolge verdient dieselbe Aufmerksamkeit. Ein einzelnes 16-Bit-Register wird mit dem höchstwertigen Byte zuerst definiert, doch 32-Bit-Ganzzahlen und Gleitkommawerte erstrecken sich über mehrere Register. Hersteller können die beiden Wörter vertauschen. Ein plausibler, aber falscher Wert ist gefährlicher als ein offensichtlicher Kommunikationsfehler. Überprüfen Sie daher Skalierung und Wortreihenfolge anhand eines bekannten Prozesszustands.

RTU und TCP verwenden verwandte Funktionscodes, doch ihre Übertragungsheader, Fehlerprüfungen und Zeitregeln unterscheiden sich.

Die Netzwerkleistung ist ein Zeitbudget

In einem RS-485-Strang bestimmen Baudrate, Nachrichtenlänge, Antwortverzögerung, Anzahl der Wiederholungsversuche und Knotenzahl die Aktualisierungszeit. Das Abfragen jedes Registers mit maximal möglicher Geschwindigkeit erhöht nach marginalen Verkabelungsereignissen die Kollisionen und lässt weniger Zeit für die Wiederherstellung. Fassen Sie zusammenhängende Werte zu effizienten Lesevorgängen zusammen und weisen Sie Temperaturen, Zählern und Konfigurationsdaten, die keine Aktualisierung im Millisekundenbereich benötigen, langsamere Raten zu.

Modbus TCP kann mehr gleichzeitigen Datenverkehr unterstützen, doch ein Gateway zu einem seriellen Segment bleibt durch den nachgelagerten Bus begrenzt. Zehn Ethernet-Clients, die ein Gateway abfragen, schaffen nicht die zehnfache serielle Kapazität. Sie erzeugen eine Warteschlange, und schlecht gewählte Zeitüberschreitungen können aus einer normalen Warteschlangenbildung wiederholte Übertragungsversuche machen.

Ingenieure, die Controller oder Gateways auswählen, sollten daher Verbindungsgrenzen, unterstützte Funktionscodes, die maximale Registeranzahl pro Anfrage, die Ausnahmebehandlung und die Diagnosemöglichkeiten prüfen. SPS- und PAC-Optionen für diese Architekturen können in der Kollektion für SPS- und PAC-Systeme geprüft werden, während die Schnittstellenhardware in eine durchdachte Kommunikations- und Netzwerkplanung gehört.

Für Fehler auslegen, nicht nur für erfolgreiche Lesevorgänge

Ein robuster Controller unterscheidet veraltete Daten von einer gültigen Null. Er protokolliert die letzte erfolgreiche Aktualisierung, stellt Ausnahme-Codes bereit, begrenzt Wiederholungsversuche und definiert für jede Prozessvariable einen sicheren Zustand. Eine Zeitüberschreitung darf einen alten Befehl oder Messwert nicht unbegrenzt stillschweigend beibehalten.

Bei RS-485 sollte die Topologie vor der Software überprüft werden: Verwenden Sie eine Daisy-Chain statt einer Sternstruktur, terminieren Sie die beiden physikalischen Enden, steuern Sie die Vorspannung, achten Sie auf die Polarität und verlegen Sie das Kabel abseits von Leitungen mit energiereichen Schaltvorgängen. Bei TCP sollten Sie doppelte IP-Adressen, Switch-Fehler, die Auslastung des Gateways und häufige Verbindungswechsel überwachen.

Wo Modbus weiterhin seine Berechtigung hat

Modbus bleibt eine gute Wahl für Zähler, Antriebe, dezentrale I/O, Umgebungsmesstechnik und Brownfield-Integrationen, wenn der Datensatz überschaubar ist und die eindeutige Zuständigkeit für die Abfrage feststeht. Weniger attraktiv ist es, wenn eine Anwendung integrierte Semantik, ereignisgesteuerte Veröffentlichung, umfassende Diagnosefunktionen, koordinierte Bewegungen oder native Sicherheitsfunktionen benötigt.

Meinung des Autors: Modbus sollte als transparenter Übertragungsvertrag betrachtet werden, nicht als Garantie für eine Plug-and-Play-Integration. Seine Offenheit ist gerade deshalb wertvoll, weil Ingenieure jede Anfrage prüfen können – dieser Wert kommt jedoch nur dann zum Tragen, wenn die Registerzuordnung, die zeitlichen Annahmen und die Fehlerreaktionen als Teil des Steuerungskonzepts dokumentiert sind.