Ihr Wegweiser für
industrielle Netzwerke

Modbus-TCP – Architektur und Protokoll

Client-/Server-Architektur

Modbus TCP/IP ist ein Client/Server-Protokoll für den verbindungsorientierten gesicherten Austausch von Prozessdaten. Dies bietet ein hohes Maß an Flexibilität für dezentrale Automatisierungsarchitekturen: Die Rollen des Clients und der Servers sind nicht fest zugeordnet. Jedes Gerät im Netzwerk kann beide Rollen spielen. Somit können Zugriffe auf Daten – lesend oder schreibend – flexibel den jeweiligen Aufgabenstellungen angepasst werden.

Der Server bearbeitet eine Anfrage des Clients – den so genannten Request – und quittiert die Anfrage mit einer Erfolgsmeldung (Response), der gegebenenfalls angefragte Daten oder Statusinformationen 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 Implementierungen ist kein Applikationsprogramm auf der Client-Seite erforderlich.

Interner Speicherbereich Objekttyp Zugriffsart Bemerkung
Eingänge Einzelne Bits Nur Lesen Daten, die beispielsweise von den E/A eines Geräts kommen
Interne Bits ("Coils" Einzelne Bits Lesen / Schreiben Bitinformationen, die durch das Anwenderprogramm änderbar sind
Eingangsregister 16 Bit-Worte Nur Lesen Daten, die beispielsweise von den E/A eines Geräts kommen
Interne Register 16 Bit-Worte Lesen / Schreiben Interne Wortvariablen, vom Anwenderprogramm änderbar

Modbus-Datentypen

Daten, die mit Modbus/TCP übertragen werden, können Bit- und Wortinformationen enthalten. Ü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.

Modbus als ethernet-basierter Feldbus

Modbus/TCP kann als Ethernet-basierter Feldbus für dezentrale E/A-Systeme eingesetzt werden. Dazu wird in einem Ethernet-Schnittstellenmodul einer SPS ein so genannter E/A-Scanner genutzt. Solche Schnittstellen sind beispielsweise in den SPS-Familien Quantum, Premium und M340 von Schneider Electric verfügbar. Bei der Konfiguration einer solchen Lösung kann der Anwender neben den üblicherweise eingesetzten E/A-Inseln auch Steuerungen, Controller und beliebige Peripheriegeräte mit Modbus/TCP-Schnittstelle als E/A konfigurieren. Dabei ist in diesem Fall die Steuerung mit E/A-Scanner der Client, die als E/A konfigurierten Geräte sind die Server, die dem Client auf Anfrage Daten liefern.

Die Buszykluszeiten eines solchen Systems sind mit denen herkömmlicher Feldbuslösungen vergleichbar. Der große Vorteil der Lösung mit Modbus/TCP besteht darin, dass die Länge der Datenblöcke, die in jedem Zyklus übertragen werden, erheblich über der der Feldbus-Klassiker liegt. Insofern kann eine E/A-Lösung mit Modbus/TCP als erheblich leistungsfähiger angesehen werden.  

Protokollgrundlagen

Die Länge eines Datenblocks, der in einem Modbus-Telegramm übertragen werden kann, beträgt 252 Bytes. Diese Restriktion geht auf die ursprüngliche Definition des Modbus-Protokolls zurück, bei der die Maximallänge eines Telegramms auf 256 Bytes festgelegt wurde. In diesem Telegramm sind folgende Bestandteile enthalten:

  • Geräteadresse: 1 Byte
  • Function Code: 1 Byte. Mit diesem Function Code wird festgelegt, welche Operation auf
    Grund eines Requests durch den Server ausgeführt werden soll.
  • Datensicherung mit CRC: 2 Bytes

Aus dieser Betrachtung ergibt sich die Länge des Nutzdatenblocks von 252 Bytes, die auch bei Modbus/TCP erhalten geblieben ist. Als Folge hieraus lassen sich Modbus-Requests mit minimalem Aufwand von seriellen Übertragungsstrecken über ein Gateway auf Ethernet umsetzen. Die Art und Weise des Zugriffs auf Gerätedaten wird über 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). Für Gerätehersteller, die Funktionscodes in ihren Geräten implementieren, besteht die Möglichkeit eines Konformitätstests, mit dem sie die Einhaltung der Spezifikation testen und zertifizieren lassen können.

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.