OPC UA Client - Redundanz

WinCC OA-Redundanz

Beide UA-Clients in einem redundanten WinCC OA-System kommunizieren symmetrisch mit dem UA-Server. Beide stellen eine Verbindung her, erstellen die Subscriptions und die überwachten Elemente. Aus Sicht des Servers sind dies zwei unabhängige Clients.

Der tatsächliche Aktiv/Passiv-Mechanismus und das damit verbundene Verwerfen erfolgt innerhalb von WinCC OA. Um einen Datenverlust während der Umschaltung zu verhindern, ist eine Generalabfrage zu empfehlen (siehe autoGQ).

Der Vorteil dieser Redundanzvariante ist, dass der Server keinerlei Redundanzfähigkeiten unterstützen muss.

Die untere Abbildung skizziert die Architektur der Client-Redundanz in einem redundanten WinCC OA-System

OPC UA Server-Redundanz

Der UA-Client unterstützt die Kommunikation zu einem redundanten UA-Serverpaar.

Bezüglich der OPC UA Server-Redundanz unterstützen die UA-Clients gemäß der UA-Spezifikation zwei Betriebsmodi:

• Hot(b)-Redundanz
• HotAndMirrored (verfügbar ab WinCC OA Version 3.21).

Diese Modi werden in den nächsten Abschnitten beschrieben.

Hot(b)-Redundanz

Der Client ist immer mit beiden Servern verbunden. Die Subscriptions werden auf beiden Servern erstellt und aktiviert. Bezüglich der überwachten Items gibt es je nach Konfiguration (_OPCUAServer.Config.Flags Bit 2), zwei Möglichkeiten:

1. Die überwachten Elemente sind auf beiden Servern aktiviert, sodass beide Server Daten liefern.
2. Die überwachten Elemente werden nur auf dem Server mit dem höheren Servicelevel aktiviert, wenn beide Server verbunden sind.

   Sie können auch einen bevorzugten Eingang konfigurieren, wenn Daten über beide Verbindungen über das Datenpunktelement _OPCUAServer.Redu.InputMode empfangen werden.

   Wenn beide Verbindungen Daten übertragen, verwendet der Client den Zeitstempel des Werts, um doppelte Werte zu entfernen.

   Der Client sendet die Befehle immer an beide Server. Das redundante UA-Serverpaar muss diese "duplicate"-Befehle korrekt verarbeiten.

   Andere OPC UA-Dienste wie Browsing, die Konvertierung von BrowsePath auf NodeId oder historische Abfragen werden an den Server mit dem höheren Servicelevel gesendet. Wenn beide Server das gleiche Level haben, wird der erste Server verwendet.

HotAndMirrored-Redundanz

Die HotAndMirrored-Redundanz ist ein UA-Server-Redundanzmodus, bei dem die UA-Server im redundanten Verbund ihre internen Zustände spiegeln. Die Details sind in der OPC UA-Spezifikation beschrieben. Dieser Modus ist nicht sehr weit verbreitet, da die Implementierung auf der UA-Server-Seite sehr komplex ist. Um diesen Modus auf der Client-Seite zu nutzen, ist es erforderlich, dass der Server ihn unterstützt. Ein Beispiel für einen solchen UA-Server ist der S7-1500H PLC. Der Vorteil dieses Modus besteht darin, dass er weniger Ressourcen als der Hot-Modus benötigt, da nur eine UA-Session zum redundanten UA-Server aufgebaut wird. Das bedeutet, dass auch Subscriptions und überwachte Elemente nur einmal erstellt werden. Wenn die Verbindung zu diesem Server verloren geht, wird ein neuer Secure Channel zum anderen Server aufgebaut und die vorherige Session auf dieser neuen Verbindung aktiviert. Dies kann entscheidend für UA-Server mit einer begrenzten Anzahl von Subscriptions und überwachten Elementen sein, da im Hot-Modus doppelt so viele wie im HotAndMirrored-Modus verwendet werden. Im untenstehenden Screenshot ist die Konfiguration des HotAndMirrored-Modus dargestellt. Es ist wichtig zu beachten, dass Sie in diesem Fall nur für einen UA-Server eine Statusanzeige haben, da der zweite nicht verbunden ist.

Redundantes Netzwerk

Der OPC UA-Client unterstützt ebenfalls ein redundantes Netzwerk, wie in den schematischen Abbildungen unten gezeigt. Das Prinzip dieser redundanten Verbindung besteht darin, dass jeweils nur eine Verbindung gleichzeitig hergestellt wird. Wenn die bestehende Verbindung unterbrochen wird, versucht der Client, eine Verbindung zur anderen URL herzustellen. Ist dies erfolgreich, wird die OPC UA-Session der unterbrochenen Verbindung auf die neue Verbindung übertragen, was bedeutet, dass die gesamte Konfiguration (Subscriptions, überwachte Elemente) weiterhin verfügbar ist. In diesem Fall sind auch die Puffer der überwachten Elemente weiterhin verfügbar und es gehen keine Daten aus den Subscriptions verloren, sofern die Puffer für die Dauer des Verbindungsverlusts groß genug sind. Ob diese Übertragung reibungslos funktioniert, hängt von den Session- und Subscription-Timeouts ab. Diese Timeouts müssen länger sein als die für die Verbindung zur alternativen URL benötigte Zeit. Wenn die Session oder Subscriptions abgelaufen sind, bevor die neue Verbindung hergestellt werden kann, werden diese neu erstellt. In diesem Fall kann es zu Datenverlusten bei überwachten Elementen kommen.