Rollen-Design für die Verbindung von CompactLogix mit DeltaV über Modbus RTU

Eine CompactLogix-zu-DeltaV-Modbus-RTU-Verbindung kann nur einige Dutzend Werte austauschen und dennoch zu einer der am wenigsten vorhersehbaren Schnittstellen in einer Anlage werden. Das Protokoll ist einfach, die technische Abgrenzung jedoch nicht. Die meisten Fehler beginnen bereits vor der Verdrahtung, wenn kein Team festlegt, wer Anfragen sendet, wer Befehle besitzt, wie Adressen dargestellt werden oder wie eines der beiden Systeme mit veralteten Daten umgehen soll.

Eine stabile serielle Integration benötigt einen einzigen Initiator für Anfragen, einen abgestimmten Registervertrag, eindeutig definierte Qualitätszustände und ein korrekt aufgebautes RS-485-Segment.

Die erste Designentscheidung betrifft die Architektur. DeltaV kann über eine serielle Schnittstelle kommunizieren, während CompactLogix üblicherweise ein Kommunikationsmodul im Chassis oder ein externes Gateway benötigt. Das Datenblatt zur DeltaV-M-Serien-Schnittstelle von Emerson dokumentiert die Unterstützung von Modbus RTU und Modbus ASCII. Die genaue Modulrevision, Controller-Firmware, Gateway-Firmware und unterstützte Topologie müssen dennoch für das installierte System bestätigt werden.

Einen Initiator für Anfragen pro seriellem Segment festlegen

In der traditionellen Modbus-Terminologie wurden die Begriffe Master und Slave verwendet. In aktueller Dokumentation finden sich häufig die Bezeichnungen Client und Server. In einem Modbus-RTU-Segment initiiert ein Client die Transaktionen, und Server beantworten an sie adressierte Anfragen. Zwei unabhängige Clients können sich nicht sicher denselben Zweidraht-Stamm teilen, da keiner von beiden die Nachrichtenübertragung des anderen zeitlich koordiniert.

Wenn DeltaV der Client ist, muss die CompactLogix-Seite Daten über eine Modbus-Server-Schnittstelle bereitstellen. Das SPS-Programm schreibt freigegebene Werte in einen Datenbereich des Gateways; das Gateway antwortet auf die Abfragen von DeltaV. Wenn die SPS Lese- und Schreibvorgänge initiieren muss, verwenden Sie einen separaten Port oder Gateway-Pfad. Gehen Sie nicht davon aus, dass ein Gerät mit der Beschreibung „Modbus-fähig“ beide Rollen gleichzeitig übernehmen kann.

Die Spezifikationsseite der Modbus Organization unterscheidet zwischen dem aktuellen Leitfaden zur seriellen Implementierung und dem veralteten Dokument von 1996. Diese Unterscheidung ist wichtig, wenn eine Projektspezifikation lediglich „Modbus verwenden“ vorgibt, ohne die physikalische Schicht und die Implementierungsregeln zu benennen.

Die Registertabelle als Schnittstellenvertrag behandeln

Eine nützliche Registertabelle ist mehr als eine Liste von 4xxxx-Referenzen. Für jeden Punkt sollten der Protokolloffset, die angezeigte Referenz, der Funktionscode, der Datentyp, die Wortreihenfolge, die Byte-Reihenfolge, die Skalierung, die technische Einheit, die Lese- oder Schreibrichtung, der gültige Bereich, das Aktualisierungsintervall, der verantwortliche Datenlieferant und das Verhalten bei Ausfällen festgelegt werden. Fügen Sie eine Revisionsnummer und einen Freigabenachweis hinzu, damit beide Systeme dieselbe Tabelle implementieren.

Die Adressierung verdient eine eigene Prüfung. Einige Konfigurationstools zeigen das Holding-Register 40001 an, übertragen jedoch Offset null. Andere erwarten direkt Offsets auf Basis null. Eine Tabelle, in der beide Formen erfasst sind, verhindert die bekannte Verschiebung um ein Register. Testen Sie ein eindeutig erkennbares Muster, bevor Sie Produktionswerte laden.

Werte über mehrere Register erfordern ebenso eindeutige Vorgaben. Ein 32-Bit-REAL belegt zwei 16-Bit-Register, doch die Produkte unterscheiden sich bei der Registerreihenfolge. Testen Sie bekannte Bitmuster, statt sich auf Bezeichnungen wie „Big-Endian“ zu verlassen, die von Teams manchmal unterschiedlich verwendet werden. Auch für vorzeichenbehaftete Ganzzahlen, vorzeichenlose Ganzzahlen, die Boolesche Packung und skalierte Ganzzahlwerte müssen Konvertierungsregeln dokumentiert werden.

Befehle, Status und Quittierung trennen

Lassen Sie niemals einen DCS-Schreibvorgang direkt auf einen physischen Ausgang zugreifen. Schreiben Sie Befehle in einen Bereitstellungsbereich innerhalb von CompactLogix. Die SPS sollte Betriebsart, Freigaben, Bereich, Sequenz, Aktualität und Zuständigkeit prüfen, bevor sie den gesteuerten Zustand ändert. Anschließend sollte sie einen akzeptierten Status, einen abgelehnten Status oder einen Fehlercode zurückgeben.

Eine Befehlshandshake ist besonders für Start-, Stopp-, Sollwert- und Rücksetzbefehle hilfreich. Eine Sequenznummer oder ein umgeschaltetes Anforderungsbit ermöglicht es dem Empfänger, eine neue Anfrage von einem in einem Register verbliebenen Wert zu unterscheiden. Die Quittierung sollte die verarbeitete Sequenz und den daraus resultierenden Zustand angeben. Dadurch wird verhindert, dass nach der Wiederherstellung der Kommunikation ein alter Befehl erneut ausgeführt wird.

Die RS-485-Schicht für die tatsächliche Anlage aufbauen

Verwenden Sie statt einer Sternstruktur einen durchgeschleiften Stamm. Terminieren Sie nur die beiden physikalischen Enden, halten Sie Stichleitungen kurz, achten Sie auf die Leiterpolarität und setzen Sie die Vorspannung gemäß den Gerätehandbüchern an einer einzigen kontrollierten Stelle. Die Schirmerdung muss dem Erdungskonzept des Standorts und den Geräteanweisungen folgen; improvisierte Verbindungen können Gleichtaktprobleme verursachen, statt sie zu beheben.

Jeder Knoten muss dieselbe Baudrate, Parität, Anzahl der Stoppbits und denselben Rahmenmodus verwenden. Modbus RTU und Modbus ASCII können nicht auf demselben Segment koexistieren. Ebenso kann DF1 nicht einfach in einen Modbus-Stamm integriert werden. Ein Protokollkonvertierungs-Gateway erzeugt zwei getrennte Netzwerke mit jeweils eigener Zeitsteuerung, Diagnose und Zuständigkeit.

Die Abfragezeiten benötigen ein Budget. Berücksichtigen Sie die Länge der Anfrage, die erwartete Antwortlänge, die Baudrate, die Verarbeitungszeit des Servers, die Pause zwischen Rahmen, Wiederholungen und das Timeout. Fassen Sie zusammenhängende Register nach Möglichkeit zusammen. Ein stummer Server sollte nicht dazu führen, dass jeder funktionierende Punkt mehrere lange Wiederholungen abwarten muss. Erfassen Sie die Zykluszeit unter normalen Bedingungen sowie bei einem getrennten Server.

Die Qualität zusammen mit jedem Werteblock übertragen

Eine glaubwürdig wirkende Zahl kann gefährlicher sein als ein offensichtlicher Fehler. Jeder ausgetauschte Block sollte den Kommunikationszustand, den Zeitpunkt des letzten erfolgreichen Austauschs, das Datenalter und eine klar definierte Schwelle für veraltete Daten enthalten. Verbraucher müssen erkennen können, ob der Wert aktuell, beibehalten, ersetzt oder ungültig ist.

Das Ausfallverhalten hängt vom Prozessrisiko ab. Einige Statuswerte können bei Kommunikationsverlust gelöscht werden. Andere Messwerte können zur Information des Bedieners beibehalten, aber für die automatische Regelung gesperrt werden. Befehle müssen möglicherweise in einen sicheren Zustand wechseln, eingefroren werden oder an die lokale Bedienung übergeben werden. Diese Entscheidungen gehören in die Gefährdungsanalyse, nicht in eine Gateway-Standardeinstellung.

Von der Leitung bis zur Prozessaktion in Betrieb nehmen

Beginnen Sie mit einem vom Produktionsbetrieb getrennten Netzwerk ohne Produktionsbefehle. Prüfen Sie Polarität, Terminierung, Vorspannung und serielle Einstellungen. Lesen Sie zunächst einen kleinen Diagnoseblock und testen Sie anschließend bekannte Ganzzahl- und Gleitkommamuster. Bestätigen Sie die Adressausrichtung und die Wortreihenfolge. Messen Sie die normale Zykluszeit, erzwingen Sie Timeouts und stellen Sie sicher, dass der Status veralteter Daten dort sichtbar wird, wo Bediener und Logik ihn erkennen können.

Testen Sie anschließend jeden Befehl über den vollständigen Pfad: DCS-Anfrage, Gateway-Übertragung, SPS-Validierung, Ausgangsaktion, Rückmeldung und Quittierung. Beziehen Sie abgelehnte Anfragen, Werte außerhalb des zulässigen Bereichs, Kommunikationsverlust während einer Transaktion, Aus- und Wiedereinschalten sowie die Wiederherstellung ein. Ein erfolgreicher Lesevorgang mit Live-Daten ist noch keine Abnahme der Steuerschnittstelle.

Passende Schnittstellenhardware ist in der ProSoft-Kollektion zusammengefasst. Weitere Geräte für Host-Systeme finden Sie unter DCS- und Steuerungssysteme. Die Auswahl sollte sich an den Anforderungen an unterstützten Controller, Firmware, Port, galvanische Trennung und Umgebung orientieren – nicht allein am Protokollnamen.

Perspektive der Planung

Modbus RTU bleibt für den begrenzten Austausch langsam veränderlicher Daten nützlich. Seine Schwäche ist das Fehlen eines integrierten semantischen Kontexts. Das Protokoll kann dem Empfänger nicht mitteilen, dass ein Register veraltet, ein Befehl unsicher oder eine Skalierung nach einer Wartung geändert wurde. Diese Schutzmechanismen müssen in den Registervertrag und die Anwendungslogik integriert werden.

Die beste Schnittstelle ist daher nicht die mit der größten Tabelle. Es ist diejenige, deren Zuständigkeit, Zeitverhalten, Qualität, Ausfallverhalten und Testnachweise auch Jahre später verständlich bleiben. Das macht aus einer einfachen seriellen Verbindung eine wartbare Grenze zwischen Steuerungssystemen.