Was ist Modbus?

Was ist Modbus?

Das Modbus-Kommunikationsprotokoll bietet die Möglichkeit, Daten zwischen Geräten in der Industrie zu übertragen. Bei den Kommunikationsteilnehmern kann es sich z.B. um speicherprogrammierbare Steuerungen, Sensoren, Aktoren und Energiezähler, aber auch Human Machine Interfaces (HMI), Supervisory Control and Data Acquisition (SCADA) oder Gebäudeautomatisierungssysteme handeln.

Modbus wurde 1979 von dem Unternehmen Modicon für die Kommunikation mit speicherprogrammierbaren Steuerungen entwickelt. Heute ist Modbus ein vollständig offener Standard, der von der Modbus Organization weiterentwickelt wird, einem Zusammenschluss aus Herstellern und Nutzern von Automatisierungsgeräten.

Vor allem in der Industrie hat sich Modbus weltweit als einer der wichtigsten Kommunikationsstandards auf der Feld-, Steuerungs- und Prozessleitebene etabliert. Grund dafür ist neben der Offenheit des Standards auch die vergleichsweise einfache und kostengünstige Implementierung auf Herstellerebene, die zu einem breiten Angebot an Modbus-kompatiblen Geräten geführt hat. Anwender dagegen profitieren von Interoperabilität und einer flexiblen Integration unterschiedlicher Geräte in vorhandene Infrastrukturen.

Wie funktioniert die Modbus-Kommunikation?

Modbus basiert auf einer Client-Server-Architektur.

Als Client (früher: Master) werden Geräte bezeichnet, die Anfragen senden und die Kommunikation initiieren, beispielsweise eine speicherprogrammierbare Steuerung (SPS) oder ein Prozessleitsystem.

Die Server (früher: Slaves) sind Geräte, die auf die Anfragen eines Clients reagieren, indem sie Daten bereitstellen oder Befehle ausführen, etwa Sensoren, Aktoren oder Frequenzumrichter.

Damit weist Modbus eine klare Rollenverteilung auf, in der die Clients die Kontrolle über die Kommunikation behalten, während die Server rein passiv agieren.

Ein Client initiiert die Kommunikation, indem er eine Nachricht an einen oder mehrere Server sendet. Diese enthält unter anderem die Adresse des Servers, die auszuführende Funktion (Lesen/Schreiben), die Daten (welche Register werden gelesen/beschrieben) und eine Prüfsumme zur Integritätsprüfung der Daten. Sofern kein Fehler auftritt, führt der Server die Funktion aus und antwortet mit den entsprechenden Daten.

Ablauf einer beispielhaften Modbus-Transaktion zwischen Client und Server

Ein SCADA-System (Modbus-Client) möchte die möchte die aktuelle Temperatur eines Sensors auslesen. Dieser ist an eine speicherprogrammierbare Steuerung angeschlossen, die als Modbus-Server Daten bereitstellt.

1) Der Client sendet eine Anfrage an den Server. Diese enthält einen Funktionscode (hier: 03), der angibt, dass Register gelesen werden sollen. Außerdem wird die Adresse des ersten Registers und die Zahl der zu lesenden Register übermittelt.

2) Der Server erhält die Anfrage, liest den Funktionscode und ermittelt den Temperaturwert, der in dem zu lesenden Register gespeichert ist.

3) Der Server sendet eine Antwort zurück an den Client, die den gleichen Funktionscode und den ausgelesenen Temperaturwert enthält.

4) Der Client erhält die Antwort des Servers, womit die Transaktion abgeschlossen ist.

Falls bei der Verarbeitung der Anfrage ein Fehler aufgetreten wäre (z.B. eine ungültige Startadresse), hätte der Server stattdessen mit einem Exception-Code (z.B. 02 für „Illegal Data Address“) geantwortet.

Modbus-Datentypen

Modbus definiert vier Datentypen, die von einem Server implementiert und von einem Client adressiert werden können.

Diese Datenstrukturen dienen als standardisierte Speicherbereiche und können genutzt werden, um Daten auf einem Gerät zu lesen oder zu schreiben.

1) Discrete Inputs sind schreibgeschützte digitale Eingänge. Ein Modbus-Client kann nur den Zustand des Eingangs (0 oder 1) auslesen.

2) Coils sind digitale Ausgänge, die sowohl gelesen als beschrieben werden können. Ein Modbus-Client kann den Zustand des Ausgangs (0 oder 1) auslesen oder setzen.

3) Input Register sind schreibegschützte 16-Bit-Register, die z.B. Messwerte enthalten können.

4) Holding Register sind 16-Bit-Register, die sowohl gelesen als auch beschrieben werden können. Sie können z.B. Steuerdaten enthalten.

Modbus-Funktionscodes

Modbus-Funktionscodes legen die Datenoperationen fest, die ein Client auf einem Gerät ausführen kann. Dazu zählen u.a. Lese- und Schreiboperationen für einzelne Datenfelder und Register.

Funktionscodes werden durch Zahlen von 1-255 repräsentiert, wobei 128-255 für Exception Responses genutzt werden

Im Folgenden stellen wir die wichtigsten Funktionscodes vor.

Basis-Leseoperationen

Die Funktionscodes 01 – 04 werden für das Lesen von Discrete Inputs, Coils und Registern verwendet:

Read Coils (01):
Lesen ein oder mehrerer binärer Eingangswerte

Read Discrete Inputs (02):
Lesen ein oder mehrerer binärer Ausgangswerte

Read Holding Registers (03): 
Lesen ein oder mehrerer 16-Bit-Ausgangsregister

Read Input Registers (04):
Lesen ein oder mehrerer 16-Bit-Eingangsregister

Basis-Schreiboperationen

Die Funktionscodes 05, 06, 15 und 16 werden für das Schreiben von Coils und Holding Registers verwendet:

Write Single Coil (05):
Setzen eines binären Ausgangswerts

Write Single Holding Register (06):
Schreiben eines 16-Bit-Ausgangsregisters

Write Multiple Coils (15):
Setzen mehrerer binärer Ausgangswerte

Write Multiple Holding Registers (16):
Schreiben mehrerer 16-Bit-Ausgangsregister

Diagnose und erweiterte Funktionen

Weitere Funktionscodes werden zur Fehlerdiagnose, für spezielle Lese- und Schreiboperationen oder zur Einbindung anderer Protokolle in die Modbus-Kommunikation verwendet.

Read Exception Status (07):
Liest den Status von Exception-Fehlern auf dem Server.

Diagnostics (08):
Führt eine Reihe an Diagnosefunktionen (Tests) durch.

Read File Record (20):
Liest Daten aus einem Dateiobjekt.

Write File Record (21):
Schreibt Daten in ein Dateiobjekt.

Mask Write Register (22):
Ändert ausgewählte Bits in einem Register.

Read/Write Multiple Registers (23):
Liest und schreibt gleichzeitig mehrere Holding Registers.

Read FIFO Queue (24):
Liest Daten aus einer FIFO-Warteschlange (First-In-First-Out) im Server.

Encapsulated Interface Transport (43):
Bietet Unterstützung für Operationen und Methodenaufrufe anderer Protokolle innerhalb von Modbus-Requests (Tunneling).

Modbus-Exception Codes

Wenn eine Modbus-Anfrage von einem Server erfolgreich erhalten wurde, aber nicht verarbeitet werden kann, sendet der Server eine Exception-Antwort zurück an den Client.

Während eine normale Server-Antwort den gleichen Funktionscode wie die Anfrage des Clients enthält, wird bei einer Exception-Antwort der Funktionscode modifiziert, indem das höchste Bit auf 1 gesetzt wird.

Zusätzlich antwortet der Server mit einem Exception Code, der Aufschluss über die Art des aufgetretenen Problems geben kann.

Modbus definiert folgende Exception Codes:

Illegal Function (01):
Der Server unterstützt die vom Client angefragte Funktion nicht.

Illegal Data Address (02):
Die angefragte Zugriffsadresse existiert nicht oder liegt außerhalb des gültigen Speicherbereichs.

Illegal Data Value (03):
Die Anfrage enthält einen ungültigen Wert.

Slave Device Failure (04):
Bei der Bearbeitung der Anfrage durch den Server ist ein Fehler aufgetreten und die Anfrage konnte nicht durchgeführt werden.

Acknowledge (05):
Die Anfrage wurde vom Server akzeptiert, aber die Bearbeitung dauert länger.

Slave Device Busy (06):
Der Server ist aktuell beschäftigt und kann die Anfrage nicht bearbeiten.

Negative Acknowledge (07):
Die Anfrage ist gültig, aber der Server kann sie aus besonderen Gründen nicht durchführen.

Memory Parity Error (08):
Beim Lesen von Daten durch den Server ist ein Speicherfehler aufgetreten.

Gateway Path Unavailable (10):
Ein Gateway konnte den Datenpfad nicht weiterleiten.

Gateway Target Device Failed to Respond (11):
Das über ein Gateway angesprochene Zielgerät hat nicht geantwortet.

Modbus-Versionen (RTU, ASCII, TCP)

Im Hinblick auf die physische und logische Datenübertragung sowie die zugrunde liegenden Kommunikationsmechanismen kann zwischen verschiedenen Versionen des Modbus-Protokolls unterschieden werden.

Modbus RTU (Remote Terminal Unit) und Modbus ASCII nutzen serielle Schnittstellen wie RS-232 oder RS-485 für die physische Übertragung von Daten. Datenframes werden nacheinander übertragen.

Im Gegensatz dazu basiert Modbus TCP auf Ethernet-Kommunikation und verwendet das TCP/IP-Protokoll, wodurch die physische Übertragung über Netzwerkkabel (z. B. CAT5/CAT6) erfolgt und eine parallele, paketorientierte Datenkommunikation ermöglicht wird. Dadurch unterscheiden sich auch Übertragungsgeschwindigkeit, Reichweite und Netzwerkarchitektur.

Modbus RTU

Modbus RTU ist die am häufigsten eingesetzte Modbus-Implementierung.

Hier werden Daten in einem binären Format und über serielle Schnittstellen (RS-232, RS-485 oder RS-422) übertragen.

RS-485 (auch: EIA-485) ist ein serieller Standard für die physische Datenübertragung, bei dem Daten über zwei Leitungen übertragen werden, um Störungen und elektromagnetische Einflüsse zu minimieren. Die maximale Distanz liegt bei bis zu 1200 Metern bei niedrigen Übertragungsgeschwindigkeiten. Geeignet für die Datenübertragung über längere Distanzen und Multi-Point-Verbindungen.

RS-232 (auch: EIA-232) ist ein älterer Standard für die physische Datenübertragung, bei dem Daten über eine serielle Verbindung mit nur einer Leitung pro Signal übertragen werden, was sich vor allem für Punkt-zu-Punkt-Kommunikation zwischen zwei Geräten eignet. Die maximale Distanz liegt bei 15 Metern bei einer Übertragungsgeschwindigkeit von 19,2 kbit/s.

Bei der Datenübertragung über den seriellen Standard RS-232 handelt es sich um Punkt-zu-Punkt-Verbindungen zwischen zwei Geräten.

Bei der Modbus-Kommunikation über RS-485 können dagegen bis zu 32 Geräte über einen Bus adressiert werden.

Dank binärer Datenübertragung und kompakten Datenframes zeichnet sich Modbus RTU durch hohe Effizienz, schnelle Datenverarbeitung und geringe Latenz aus. Die maximale Übertragungsgeschwindigkeit liegt bei bis zu 115,2 kbps.

Ein Modbus RTU-Datenframe ist folgendermaßen aufgebaut:

Modbus RTU verwendet Zeitlücken zur Trennung von Frames. Zwischen zwei Frames muss eine Sendepause von mindestens 3,5 Zeichen eingebaut werden, damit diese korrekt als solche erkannt werden.

Modbus ASCII

Bei Modbus ASCII werden Daten ebenfalls seriell und im textbasierten ASCII-Format übertragen. Damit sind sie für Menschen lesbar, was die Fehlerbehebung erleichtert. Gleichzeitig steigt jedoch die Menge übertragenen Daten (doppelte Datenmenge für Adresse, Funktionscode und Daten, da jeder 8 Bit-Wert als zwei ASCII-Zeichen codiert wird).

Modbus ASCII ist älter als Modbus RTU und kommt seltener zum Einsatz, wird jedoch noch immer von einigen älteren Systemen genutzt.

Ein Modbus ASCII-Frame ist folgendermaßen aufgebaut:

Im Modbus ASCII-Modus können Zeichenpausen von bis zu einer Sekunde zwischen einzelnen Zeichen auftreten, ohne dass dies als Übertragungsfehler interpretiert wird. Dies ist ein wesentlicher Unterschied zu Modbus RTU, wo eine zu lange Pause als Frame-Ende gewertet wird. Dadurch ist Modbus ASCII robuster bei langsamen oder unregelmäßigen Übertragungen.

Modbus TCP

Seit der Einführung von Modbus TCP im Jahr 1999 ist auch eine Modbus-Kommunikation über Ethernet-Netzwerke möglich. Daten können damit in IP-basierten Netzwerken (WLAN, WAN, Internet) übertragen werden.

Modbus TCP verwendet Port 502.

Vorteile von Modbus TCP gegenüber anderen Modbus-Versionen sind unter anderem schnelle Datenübertragung und die erhöhte Kompatibilität mit modernen Netzwerkstrukturen.

Auch bei Modbus TCP wird die Kommunikation durch einen Client gesteuert. Allerdings können in einem Modbus TCP-Netzwerk mehrere Clients vorhanden sein, wobei Geräte durch ihre IP eindeutig identifiziert werden können.

Ein Modbus TCP-Frame ist folgendermaßen aufgebaut:

Wo wird Modbus eingesetzt?

Modbus ist eines der am weitesten verbreiteten Protokolle in der Industrie. Die Anwendungen reichen von der Steuerung und Überwachung von Fertigungsprozessen bis hin zum Gebäude- und Energiemanagement.

Auch außerhalb der Industrie kommt Modbus in Bereichen wie der Landwirtschaft, Transport und Infrastruktur oder Abwassertechnik zum Einsatz.

In der Praxis können z.B. folgende Geräte und Anwendungen über Modbus kommunizieren:

• Speicherprogrammierbare Steuerungen (SPS)
• Sensoren
• Aktoren
• Frequenzumrichter
• Energiezähler
• SCADA-Systeme (Supervisory Control and Data Acquisition)
• Human-Machine Interfaces (HMI)
• I/O-Module
• Gateways und Protokollumwandler

Speicherprogrammierbare Steuerungen fragen beispielsweise als Modbus-Clients Daten verbundener Geräte (Energiezähler, Temperatursensoren, Frequenzumrichter, …) ab oder senden Steuerbefehle. So könnten z.B. Pumpen in einer Wasseraufbereitungsanlage basierend auf Füllstandsmessungen gesteuert werden, wobei die Datenübertragung zwischen Füllstandssensoren, SPS und Frequenzumrichtern über Modbus realisiert wird.

Auch zentrale Kontrollsysteme wie SCADA treten häufig als Modbus-Clients auf und sammeln Daten verschiedenster Geräte zur Visualisierung und Überwachung.

Modbus und OPC UA

OPC UA ist ein moderner Kommunikationsstandard, der eine zentrale Rolle in der industriellen Automatisierung spielt. Seit seiner Veröffentlichung im Jahr 2008 erfährt er weite Verbreitung in der Industrie und wird häufig im Zusammenhang mit Industrie 4.0 und der digitalen Transformation genannt.

Zwischen OPC UA und Modbus bestehen zentrale Unterschiede. In vielen Industrieumgebungen werden beide kombiniert, um den Datenaustausch zwischen verschiedensten Geräten und Softwaresystemen zu ermöglichen.

Während bei Modbus oft die Kommunikation zwischen Feldgeräten im Vordergrund steht, ermöglicht OPC UA den Datenaustausch zwischen OT (Feldebene) und IT (…), also zwischen Maschinen und übergeordneten Softwaresystemen wie Manufacturing Execution System (MES), Enterprise Resource Planning (ERP) oder Cloud-Plattformen.

Im Gegensatz zu Modbus unterstützt OPC UA komplexere Datenstrukturen und Sicherheitsfunktionen. Zudem ist der Standard plattformunabhängig – während Gerätehersteller selbst Modbus-Unterstützung implementieren, zielt OPC UA auf eine herstellerunabhängige Kommunikation ab.

Konvertierung von Modbus zu OPC UA

In der Praxis ist es oft notwendig, das Modbus-Protokoll mit dem OPC UA-Standard zu verbinden.

So könnten z.B. Feldgeräte wie SPS oder Energiezähler über Modbus kommunizieren, während eine Cloud-Anwendung Daten als OPC UA-Client abfragen soll.

In diesem Fall kann ein OPC UA Server als Gateway eingesetzt werden, der Modbus-Daten im OPC UA-Format bereitstellt.

Dazu implementiert die OPC UA Server-Software spezielle Treiber, die eine Einbindung in die Modbus-Kommunikation und die Konvertierung von Modbus-Daten in OPC UA-Variablen ermöglichen.

Der OPC UA Server von Kepware ermöglicht mit der Modbus Suite eine Einbindung verschiedenster Modbus-Geräte in die OPC UA-Kommunikation. Lesen Sie hier alles zu den unterstützten Schnittstellen und erweiterten Funktionen der Modbus Suite: OPC Server für Modbus

Weitere Informationen

Sie können den KEPServerEX kostenlos und unverbindlich testen. Fordern Sie noch heute Ihre persönliche Demo an.