OPC Modbus

Datenaustausch mit Modbus-Geräten über OPC

Von allen Industrieprotokollen, die es zurzeit gibt, ist Modbus sicherlich eines der beliebtesten. Seine offene Architektur, seine einfache Implementierung und die aufs Wesentliche beschränkte Funktionsauswahl machen es zu einem besonders gerne verwendeten Protokoll. Hier wird die Vorgehensweise zur Verbindung von Modbus mit OPC und die Unterschiede zwischen einfacher Kommunikation und technisch anspruchsvollerer, telemetrischer Kommunikation zwischen Modbus und OPC beschrieben.

Basis Hilfsmittel:

Weitere Verbindungsmöglichkeiten:

Protokolle:

Register
In Modbus werden Daten in Registern abgelegt.

• 0x: Lese-/Schreib-Tags, die EIN oder AUSsein können. Diese werden manchmal auch als „Coils“, „Digitals“, „Relays“ oder „Boolesche Werte“ bezeichnet. Adressbereich: 00001 bis 09999.
• 1x: Nur-Lese-Tags, die EIN oder AUSsein können. Diese werden manchmal auch als „Coils“, „Digitals“, „Relays“ oder „Boolesche Werte“ bezeichnet. Adressbereich: 10001 bis 19999.
• 3x: Nur-Lese-Tags. Länge: immer 16 Bit. Auch als „Input Registers“ bezeichnet.
• 4x: Lese-/Schreib-Tags. Länge: immer 16 Bit. Auch als „Holding Registers“ bezeichnet.

Interpretation unterschiedlicher Register
Was geschieht bei Verwendung von Fließkommawerten, 32 Bit langen Registern, Ganzzahlen ohne Vorzeichen, vertauschten Wortreihenfolgen, ASCII-Zeichenfolgen usw.? Bei solchen Registern bieten die meisten OPC-Server vorangestellte Buchstaben oder andere Möglichkeiten an, um mitzuteilen, dass der OPC-Server den betreffenden Tag anders behandeln muss. Beim Matrikon OPC Server für Modbus könnte ein gepaartes Register für einen reellen 32-Bit-Fließkommawert als OPC-Tag beispielsweise so aussehen: TestChannel.TestDevice.4:34P

Master/Slave-Steuerung
Allgemein bekannt ist, dass OPC-Clients üblicherweise in Anwendungen eingebettet werden, die volle Kontrolle über den Datenaustausch benötigen. OPC-Server werden in aller Regel für Anwendungen entwickelt, die keine Kontrolle über den Datenaustausch benötigen. Auch viele gängige Protokolle, z. B. Modbus, folgen dieser Philosophie. Modbus ist Master/Slave-orientiert, so wie OPC Client/Server-orientiert ist. Normalerweise soll der OPC-Server als Modbus-Master agieren und als Zwischenstation den Datenverkehr auf der Leitung steuern. Es sind aber auch Situationen denkbar, in denen das Gerät eine größere Kontrolle über den Datenaustausch haben muss, z. B. wenn es im Falle eines Alarmzustands eine entsprechende Rückmeldung absetzen soll. In solchen Fällen muss der OPC-Server als Modbus-Slave agieren. Die meisten OPC-Server unterstützen keinen Slave-Modus; sollte dieser benötigt werden, ist eine Rückfrage beim Anbieter unerlässlich.

Telemetrie
Bei technisch besonders komplexen Verbindungen stellt sich das Problem, dass OPC-Server lediglich als passive Übersetzer fungieren. In einer komplexen Telemetrie-Umgebung, in der zahlreiche RTUs oder SPS über Datenbrücken mit hoher Latenz, niedriger Bandbreite und mehreren Teilnehmern gleichzeitig kommunizieren, benötigt man einen OPC-Server mit etwas mehr „Grips“. Darunter sind erweiterte Timing- und Abrufoptionen zu verstehen. Ein guter SCADA OPC-Server für Telemetrie sollte Ringabrufe und Interrupt/Demand-Abrufe beherrschen und über zahlreiche erweiterte Timing-Parameter verfügen, um mit unterschiedlichen Verzögerungen oder Abrufzeiten zurechtzukommen.

Mehrere Master
Einer der Unterschiede zwischen den beiden Systemen besteht darin, dass zwar ein OPC-Client mit jedem vorhandenen OPC-Server verbunden sein kann, die gleichzeitige Kommunikation zwischen zwei Modbus-Master-Modulen und ein und demselben Modbus-Slave-Modul in der Regel jedoch nicht wünschenswert ist. Das kann zu einem Problem werden, wenn man redundante OPC-Server oder multible Master-Applikationen nutzt. Sprechen Sie mit dem Anbieter darüber, wie Sie solche Konflikte in Ihrer Anwendung entschärfen können, wenn sie in der Praxis tatsächlich zu Problemen führen.

Weitere Informationen zu Modbus finden Sie bei der Modbus-IDA auf modbus.org.