UNICOS
Der Treiber kann gleichzeitig für Modbus/TCP oder UNICOS (empfohlen) eingesetzt werden. Für die Masterseite ist UNICOS identisch mit dem Standard Modbus Protokoll.
Beim Slave-Einsatz entscheidet der Treiber ob ein UNICOS Frame oder Modbus Frame verwendet wird, indem er die Referenznummer des Modbus Frames betrachtet. Die Referenznummer für einen UNICOS Frame ist defaultmäßig 0xFFFF. Das bedeutet, dass im Standard Modbus die Referenznummer 0xFFFF nicht vorkommen darf. Die Referenznummer kann über einen Config-Eintrag gesetzt werden - siehe auch Details zum Treiber Modbus/TCP.
Das UNICOS Protokoll unterscheidet bei der Information zwischen:
-
Binär Status
-
Analog Status
-
Events
-
Requests
Frames
Für UNICOS gibt es einen zusätzlichen Subfunktionscode im Modbus Frame. Dieser Code wird im ersten Byte der Daten des Modbus Frame übermittelt. Der Wert für Binär und Analog Status ist 0x01 (1), für Events 0x12 (18) und für 32 Bit Events 0x11 (19). Dabei unterscheiden sich Binär und Analog Status
nicht, daher muss die Entscheidung welche Daten empfangen werden durch die Definition des DPE Typs für die zugehörige Adresse festgelegt werden. Die maximale Größe eines UNICOS Frames ist 253 Bytes.
-
Event Report Frame
Im Falle eines Event Frames muss der Event Offset (die Referenznummer) verwendet werden, um den Wert einem bestimmen DPE zuzuordnen.
-
Request Frame
Der Request Frame ist ein Standard Modbus Frame und besteht aus einem oder mehreren 16 Bit Wörtern.
Peripherieadresse
Die Adresse ist der Modbusadresse sehr ähnlich. Der einzige Unterschied besteht darin, dass für Eingangsdaten der Subfunktionscode den Funktionscode ersetzt. Um die Adresse korrekt zu interpretieren muss bei der Typeangabe UNICOS gewählt sein:
Beispiel
U.4.1.100
U steht dabei für UNICOS Adresstyp, 4 für SPS 4, 1 (0x01) für eine binäre oder analoge Statusnachricht und 100 für die Bitnummer oder analoge Statusadresse (Offset, Referenznummer).
Master und Slave
Der WinCC OA Treiber muss beim UNICOS Protokoll gleichzeitig Master und Slave sein:
-
Die Statusdaten und die Events werden nur spontan gesendet, ein Polling ist nicht erforderlich. Für diese Daten muss der Treiber ein Modbus Slave sein (TCP Server).
-
Requests werden vom Treiber als Modbus Master gesendet (TCP Client).
Bei UNICOS werden sowohl Binär- als auch Analogdaten in Tabellen zusammengefasst. Eine Tabelle umfasst 96 16-bit Wörter. Wenn sich etwas in der Tabelle ändert wird die ganze Tabelle geschickt. Sie werden höchstens alle 50 ms geschickt.
Die Event Tabelle enthält die Änderungen des Bitstatus mit einer Auflösung von 10 ms. Die Tabelle wird entweder geschickt wenn sie voll ist oder aber nach 2 Sekunden.
Da die Daten in den Events den Binär Status Daten entsprechen, müssen eigene Datenpunkte verwendet werden, da der Zeitstempel der Event Daten älter sein kann als der, der zuvor geschickte, reguläre Bitstatus.
Folgende Abbildung zeigt den Datenfluss für ein UNICOS Protokoll. Im Unterschied zu Modbus/TCP werden hier nur Write Request verwendet.
Der Treiber interne Alivemechanismus ist wie beim Eintrag aliveTimeout in der Config-Datei beschrieben (siehe Details zum Treiber Modbus/TCP).
Redundanzkonzept
Folgende Abbildung zeigt das Redundanzkonzept. Sowohl das Leitsystem ( WinCC OA ) als auch die SPS sind redundant:
Der Datenfluss zwischen Treiber und den SPSen ist in der Abbildung nur für die Request Richtung dargestellt. Die dünnen Pfeillinien stellen die Kommunikationswege im Falle einer Redundanzumschaltung dar (werden in einem aktuellen Aktiv-/Passivzustand nicht verwendet).
Der aktive Treiber sendet die Requests an beide, die aktive und passive SPS. Beide, die aktive und passive SPS, müssen antworten. Aber nur die aktive SPS sendet Status Informationen und Event Reports an beide WinCC OA Treiber.
