SUCHEN
AKTUELL KONTAKT IMPRESSUM
 
HOME TRAINING TECHNOLOGIE WISSENSWERTES AKTUELL KONTAKT
   
 
Beratung Planung Ausführung Service Produkte
   
> BUSSYSTEME
  LON
  EIB/KNX
  BACnet
  MODBUS/TCP
   
> STEUERUNGEN
  Simatic S5 / S7
  Wago-I/O-System
   
   
   

Technologie -> MODBUS/TCP

Ethernet TCP/IP ist heute unstrittig die tragende Säule in der Kommunikationstechnik – in der Bürowelt ebenso wie in der industriellen Kommunikation. Es stellt mit den Schichten 1 bis 4 im OSI-Modell den soliden Mittelbau für die Kommunikation dar.
Bleibt noch die Frage, wie Automatisierungsgeräte sich auf der Anwendungsschicht – der Schicht 7 des OSI-Modells – miteinander verständigen. MODBUS / TCP bietet als De-Facto-Industriestandard interessante Ansätze. Das Protokoll wird von der Organisation MODBUS.ORG unterstützt und weiterentwickelt. Auf der Website www.modbus.org sind alle Informationen zu MODBUS und MODBUS/TCP frei erhältlich. MODBUS/TCP ist für den Anwender leicht zu handhaben und ermöglicht ihm eine effiziente Kommunikation - vom Austausch von Punkt-zu-Punkt-Nachrichten bis hin zum E/A-Scanning. Eine zunehmende Anzahl von Geräteherstellern schätzt die schnelle und einfache Implementierung und die Skalierbarkeit des Protokolls, bei der nur die Teile der Spezifikation tatsächlich implementiert werden, die ein Gerät benötigt.

Prinzipieller Aufbau

MODBUS/TCP ist ein Client/Server-Protokoll: der Server bearbeitet eine Anfrage des Clients (Request) und quittiert die Anfrage mit einer Erfolgsmeldung (Response), der gegebenenfalls Ergebnisse der Bearbeitung mitgegeben werden bzw. mit einer Fehlermeldung, die Informationen über die Fehlerursache enthält. Die Bearbeitung dieser Anfrage läuft für den Anwender völlig transparent im Hintergrund ab. Bei üblichen Implementationen ist kein Applikationsprogramm auf der Client-Seite erforderlich. Bild 1 zeigt den Aufbau des Protokoll-Stacks, abgebildet auf das OSI-Modell. Hier sind auch alle verwendeten Standards und Spezifikationen für die einzelnen Schichten erläutert.

Den prinzipiellen Aufbau eines MODBUS/TCP-Rahmens zeigt Bild 2. Die Länge des eigentlichen MODBUS-Telegramms beträgt zur Zeit 249 Byte. Es beginnt – unabhängig davon, ob es sich um eine Anfrage oder eine Rückmeldung handelt immer mit einem Funktionscode (Länge: 1 Byte), von dem der weitere Aufbau des folgenden Datenbereichs abhängig ist. Auf die Datensicherung, bei der seriellen Implementierung durch eine CRC-Prüfsumme sichergestellt, wird bei MODBUS/TCP verzichtet, da diese bereits von der TCP-Schicht geleistet wird.

Daten, die mit MODBUS/TCP übertragen werden, können Bit- und Wortinformationen enthalten (Tabelle 1). Über die geräteinterne Organisation dieser Daten ist damit nichts ausgesagt. Ein Gerätehersteller kann, abhängig von der Funktionalität, völlig voneinander getrennte bzw. überlappende Speicherbereiche hierfür vorsehen. Informationen, die länger als ein Byte sind (z. B. ein 16 Bit-Wort), werden so in ein MODBUS-Telegramm eingetragen, dass die höchstwertigen Bytes zuerst gesendet werden. Bei Bitketten wird das höchstwertige Bit zuerst gesendet, d. h. es steht innerhalb eines Wortes links.

Die Art und Weise des Zugriffs auf Gerätedaten wird über die bereits erwähnten Funktionscodes gesteuert. Hierbei wird zwischen öffentlichen und anwenderdefinierten Funktionscodes unterschieden. Öffentliche Funktionscodes (Codes 1 bis 64, 73 bis 99 und 111 bis 255) sind fest und eindeutig definiert und öffentlich dokumentiert (z. B. als Bestandteil des MODBUS-RFC, Status: Initial, der bei der IETF eingereicht worden ist). Darüber hinaus existiert für diese Funktionscodes die Möglichkeit eines Konformitätstests, mit dem ein Hersteller die Einhaltung der Spezifikation testen und zertifizieren lassen kann. Demgegenüber werden anwenderdefinierte Funktionscodes (Codes 65 bis 72 und 100 bis 110) vom Gerätehersteller selbst definiert und müssen nicht zwangsläufig eindeutig sein. Eine Übersicht der öffentlichen Funktionscodes gibt Tabelle 2.

MODBUS/TCP in der Praxis

Nichts ist so grau wie die Theorie – deswegen hier nun ein Beispiel für den Aufbau von Request und Response für den Funktionscode 03 Lesen von internen Registern. In Tabelle 3 ist der prinzipielle Aufbau von Request, Response und Fehlermeldung erläutert. Die Exception Codes in der Fehlermeldung bedeuten folgendes:

  • 01 – Ungültiger Funktionscode
  • 02 – Ungültige Datenadresse
  • 03 – Ungültiger Datenwert
  • 04 – Gerätefehler im Server

Weitere Exceptions sind in der MODBUS-Protokollspezifikation definiert.

Als Beispiel für die Verwendung des oben erläuterten Funktionscodes sollen nun die Register 108 (Inhalt 555 dezimal bzw. 0x022B), 109 (Inhalt 0 bzw. 0x000) und 110 (Inhalt 100 bzw. 0x0064) ausgelesen werden. Den Aufbau für Request und Response gibt Tabelle 4 wieder. Hierzu sei angemerkt, dass dieses Beispiel in erster Linie der Erläuterung des prinzipiellen Aufbaus von MODBUS/TCP-Transaktionen dient. Für den Anwender ist die Verwendung abhängig von der Implementierung des Protokolls vielfach transparent, d. h. er muss oft nur vom Gerätehersteller vordefinierte Funktionsbausteine parametrieren, um einen Request an einen Server auszulösen.

Die detaillierte Beschreibung des MODBUS-Protokolls (sowohl auf TCP/IP als auch für serielle Übertragung) inklusive aller öffentlichen Funktionscodes können der oben erwähnten MODBUS-Protokollspezifikation entnommen werden. Die Website www.modbus.org bietet darüber hinaus Codebeispiele für die Implementierung des Protokolls in Geräten, eine „Developers Corner“ und ein Diskussionsforen, in dem alle Fragen rund um MODBUS behandelt werden.

Fernweh

Bleibt noch anzumerken, dass MODBUS/TCP – ähnlich wie andere auf TCP/IP basierende Protokolle auch – nicht nur auf Ethernet beschränkt ist. Es lässt sich im Internet oder in Intranets ohne Einschränkung verwenden, wobei neben Ethernet auch Wählverbindungen im Telefonnetz und drahtlose Übertragungsstrecken zum Einsatz kommen können. Und auch die Konfiguration von Firewalls ist ohne weiteres möglich, da für MODBUS/TCP von der IANA einer der so genannten „well known“ Ports (Port 502) zugewiesen worden ist. Damit ist MODBUS/TCP nicht nur für den Einsatz in lokalen Automatisierungsnetzwerken bestens gerüstet.

Zum Vergrößern anklicken
Bild 1. Der MODBUS-Protokollstack im OSI-Modell
Zum Vergrößern anklicken
Bild 2. Prinzipieller Aufbau eines MODBUS/TCP-Frames
Zum Vergrößern anklicken
Tabelle 1. MODBUS Datentypen
Zum Vergrößern anklicken
Tabelle 2. Öffentliche Funktionscodes
Zum Vergrößern anklicken
Tabelle 3. Der Funktionscode 03 „Lesen von Registern“ im Detail
Zum Vergrößern anklicken
Tabelle 4. Einfaches Beispiel für den Request „Lesen von Registern“