Redundanz

Die OPC UA Spezifikation definiert zwei Arten der Server-Redundanz: transparente und nicht-transparente Redundanz. Bei der transparenten Redundanz ist die Übertragung der Funktionen von einem Server zum anderen transparent für den Client, d.h. dieser weiß nicht, dass ein Failover-Vorgang stattgefunden hat und hat dementsprechend auch keinerlei Kontrolle über das Failover-Verhalten. Des Weiteren muss der Client keine Aktionen durchführen, um weiterhin Daten zu senden oder zu empfangen. Bei der nicht-transparenten Redundanz wird der Failover-Vorgang von einem Server zum anderen und die Aktionen zum weiteren Senden oder Empfangen von Daten vom Client durchgeführt. Der Client muss hierbei die Redundanzkonfiguration des Servers kennen und die erforderlichen Aktionen durchführen, um im Falle eines Failovers von der Server-Redundanz zu profitieren. Die nicht-transparente Redundanz definiert verschiedene Failover-Modi, welche unter Anderem angeben, wie viele Server aktiv an der Kommunikation beteiligt sind, oder als reine Passivsysteme für den Failover-Fall bereitstehen.

Der TwinCAT OPC UA Server unterstützt die nicht-transparente Redundanz mit den Betriebsmodi „cold“, „warm“ und „hot“. Die Unterschiede in diesen drei Betriebsmodi werden weiter unten erläutert.

Redundanz 1:

Für die nicht-transparente Redundanz stellt OPC UA die Datenstrukturen zur Verfügung, die es dem Client ermöglichen, zu erkennen, welche Server in der redundanten Servergruppe verfügbar sind, sowie Serverinformationen, die dem Client mitteilen, welche Failover-Modi der Server unterstützt. Anhand dieser Informationen kann der Client feststellen, welche Maßnahmen er ergreifen muss, um Failover zu erreichen. Im Adressraum des Servers existiert hierfür das sogenannte ServerRedundancy Objekt, welches den vom Server unterstützten Redundanz-Modus und das Redundanz-Set, d.h. alle Server die Bestandteil der Redundanzkonfiguration sind, anzeigt.

Redundanz 2:
Redundanz 3:

Failover-Modi

Die folgende Tabelle listet alle unterstützten Failover-Modi für die nicht-transparente Redundanz auf.

Modus

Beschreibung

Cold

Im Cold-Failover-Modus kann jeweils nur ein Server aktiv sein. Dies kann bedeuten, dass redundante Server nicht verfügbar sind (nicht eingeschaltet) oder zwar verfügbar sind, aber nicht laufen (der PC läuft, aber die Anwendung ist nicht gestartet).

Warm

Im Modus „Warm Failover“ können die Backup-Server aktiv sein, aber keine Verbindung zu den tatsächlichen Datenpunkten herstellen (typischerweise ein System, bei dem die zugrunde liegenden Geräte auf eine einzige Verbindung beschränkt sind). Die zugrundeliegenden Geräte, wie z. B. die SPS, verfügen möglicherweise über begrenzte Ressourcen, die nur eine einzige Serververbindung zulassen. Daher ist nur ein einziger Server in der Lage, Daten abzurufen.

Hot

Im Hot-Failover-Modus sind alle Server eingeschaltet und betriebsbereit. In Szenarien, in denen Server Daten von einem nachgeschalteten Gerät, z. B. einer SPS, abrufen, sind ein oder mehrere Server aktiv und parallel mit dem/den nachgeschalteten Gerät(en) verbunden. Diese Server haben nur minimale Kenntnis von den anderen Servern in ihrer Gruppe und arbeiten unabhängig. Wenn ein Server ausfällt oder ein schwerwiegendes Problem auftritt, sinkt sein ServiceLevel (siehe unten). Nach der Wiederherstellung kehrt der Server mit einem geeigneten ServiceLevel zum Redundant Server Set zurück, um anzuzeigen, dass er verfügbar ist.

ServiceLevel

Der ServiceLevel liefert einem Client Informationen über den Zustand eines Servers und dessen Fähigkeit, Daten zu liefern. Der ServiceLevel ist eine Node vom Datentyp Byte mit einem Wertebereich von 0 bis 255. Der TwinCAT OPC UA Server setzt den ServiceLevel aktuell statisch auf den Wert 255. Der Grund hierfür ist, dass der Server in der Lage ist, Daten von mehr als einer unterlagerten SPS-Steuerung abzurufen. Der ServiceLevel kann hierbei also ausschließlich den Zustand der Serveranwendung an sich, aber nicht der unterlagerten SPS-Steuerungen anzeigen. Für letzteres steht in den jeweiligen SPS-Adressräumen das DeviceState Objekt zur Verfügung.

Konfiguration

Die Konfiguration der Server-Redundanz lässt sich mit Hilfe des TwinCAT OPC UA Configurator durchführen. Hierzu sind zwei Schritte notwendig:

Konfiguration der Redundanz

Bei der Konfiguration der Server-Redundanz wird definiert, welchen Failover-Modus der Server bereitstellt und welche anderen Server Bestandteil der Redundanz-Konfiguration sein sollen. Diese Server werden über deren ServerURI identifiziert. Der Failover-Modus, sowie eine Liste der ServerURIs werden dann vom Server in dessen ServerRedundancy-Objekt (s.o.) hinterlegt.

Redundanz 4:

Die Konfiguration dieser Einstellungen kann über den TwinCAT OPC UA Configurator in der Registerkarte „Server Settings“ erfolgen, z.B.:

Redundanz 5:

Da die ServerURI an sich noch keine Verbindungsinformationen (z.B. die Server- bzw. Discovery-URL) beinhalten, müssen diese Informationen dem Client an anderer Stelle zur Verfügung gestellt werden. Dies erfolgt über die sogenannte AdditionalServerEntry Konfiguration. Hierdurch kann ein Client durch einen FindServers-Aufruf alle erforderlichen Informationen vom Server abfragen und die Verbindungsinformationen für eine bestimmte ServerURI identifizieren. Dieser Konfigurationsschritt wird im Folgenden erläutert.

Hinzufügen der Server aus dem Redundanz-Set als AdditionalServerEntry

Bei der AdditionalServerEntry-Konfiguration werden Informationen von anderen TwinCAT OPC UA Servern zum FindServers Aufruf eines Servers hinzugefügt. Ein Client hat hierdurch die Möglichkeit, alle Server aus der Redundanz-Konfiguration aufzufinden und sich mit diesen zu verbinden. Der folgende Screenshot zeigt einen exemplarischen FindServers-Aufruf auf dem lokalen TwinCAT OPC UA Server. Der Aufruf returniert drei TwinCAT OPC UA Server, welche auch Bestandteil einer Redundanz-Konfiguration sind.

Redundanz 6:

Zur Identifikation eines Servers verwendet der Client die ServerURI aus der Redundanz-Konfiguration.

Die Konfiguration der AdditionalServerEntries kann über den TwinCAT OPC UA Configurator in der Registerkarte Server Settings erfolgen, z.B.:

Redundanz 7:

Beim Hinzufügen eines neuen Eintrags, werden bestimmte Felder schon mit einer Vorlage ausgefüllt. Bitte passen Sie diese Einträge entsprechend Ihrer Konfiguration an.

Redundanz 8:

Die konkreten Werte für ProductUri, ApplicationName, ApplicationUri und ApplicationType können Sie dem OnlinePanel des TwinCAT OPC UA Configurator entnehmen:

Redundanz 9:

Die DiscoveryURL entspricht der ServerURL, welche Sie üblicherweise für den Verbindungsaufbau mit dem jeweiligen Server verwenden.