Disaster Recovery System

Systemarchitektur

Die Funktionalität des Disaster Recovery Systems baut auf zwei WinCC OA Standardfunktionen auf. Dies sind " WinCC OA Hot-Standby-Redundanz" und die von WinCC OA unterstützen " Verteilten Systeme", welche zwischen dem PSS und dem SSS genutzt werden.

Verbindung

Alle Server des PSS und SSS sind mittels LAN oder WAN verbunden (TCP/IP Protokoll).

Normalbetrieb

Im Normalbetrieb hält das PSS System die Verbindung zu den Feldgeräten (oder Kopfrechner mit OPC UA Anschluss) und überträgt alle Werte mittels Control-Manager zum SSS.

Auf dem Bedienrechner gibt es zwei Möglichkeiten:

• Es werden zwei WinCC OA User Interfaces gestartet. Eines hat Verbindung zum PSS und das andere zum SSS. Das UI des betriebsführenden Systems läuft im Vordergrund. Alle Panelumschaltungen von diesem UI werden automatisch auf das andere UI übertragen (dieses ist für den Benutzer nur sichtbar, wenn die Verbindung zum PSS verloren geht), sodass beide WinCC OA User Interfaces immer das gleiche Bild aufgeschaltet haben.

• Es wird ein WinCC OA User Interface gestartet, welches die Verbindung zum PSS hält oder es wird ein WinCC OA User Interface gestartet, welches die Verbindung zum SSS hält. Die Entscheidung trifft der Benutzer nach dem Verbindungsverlust zum aktiven System. Der Benutzer erhält eine Meldung, wenn das System wieder passiv wird und dann das User Interface mit der Verbindung zum anderen System aufgeschaltet werden muss.

PSS (primäres Serversystem)

Das PSS besteht aus einem redundanten WinCC OA Projekt, in welchem diverse Treiber und Control-Managerbetrieben werden und somit die aktuellen Daten der Feldgeräte (oder z.B. Kopfrechner mit OPC UA-Anschluss) erhalten und weiterverarbeiten. Zwischen den beiden Servern innerhalb des primären Serversystems herrscht das Hot-Standby-Konzept. Nähere Informationen zur WinCC OA Redundanz finden Sie im Kapitel Grundlagen Redundanz.

SSS (sekundäres Serversystem)

Das SSS ist für die Betriebsführung im Falle eines Komplettausfalls des PSS oder Wartungsarbeiten am PSS gedacht. Es handelt sich dabei auch um ein redundantes WinCC OA Projekt, welches die gleichen Treiber und Control-Managerparametriert hat wie das PSS. Aus einfacher Sicht betrachtet, handelt es sich bei dem SSS um eine Spiegelung des PSS.

Im Normalfall hat das SSS keine Verbindung zu den Feldgeräten (Kopfrechnern) und führt auch keine Berechnungsvorgänge (außer WinCC OA interne Berechnungen wie Fehlergewichtung, Verdichtungen, usw.) durch. Dennoch sind die Prozessdaten mit einer sehr geringen Verzögerung ebenso auf diesem System verfügbar, da die Werte der Datenpunkte und der Alarmstatus kontinuierlich vom PSS mit dem Mechanismus der verteilten WinCC OA Systeme übertragen werden.

Wenn beide Rechner des PSS ausfallen, übernehmen die Server des SSS die komplette Überwachung und Steuerung des Projektes. Für den Benutzer bedeutet dies lediglich eine kurze Unterbrechung in der Bedienung der Applikation, bevor das SSS die Kontrolle übernimmt, dann die Verbindung zu den Feldgeräten (oder Kopfrechnern) aufbaut und dem Benutzer die aktuellen Werte zur Verfügung stellt.

Wenn die ausgefallenen Server des PSS den Betrieb wieder aufnehmen, sorgt das Disaster Recovery System für die umgekehrte Datenmigration. Während einer solchen Fallback-Umschaltung werden am PSS die WinCC OA Manager wieder gestartet und die Daten werden mit den aktuellen Daten des SSS synchronisiert. Zudem können im Zuge des Fallback-Vorgangs auch die historischen Daten abgeglichen werden. Dadurch wird sichergestellt, dass alle nach dem Failover aufgetretenen Änderungen auch am PSS verfügbar sind.

Wenn die Verbindung zwischen PSS und SSS ausfällt, werden beide Systeme aktiv geschaltet, da angenommen wird, dass das jeweils andere System ausgefallen ist. Dabei wird ein Alarm für den Verbindungsverlust des DIST-Managers ausgelöst. Es kann von beiden Systemen der Betrieb übernommen werden und beide Systeme stellen die Verbindung zu den Feldgeräten her.

Das Disaster Recovery System kann mit beiden Fällen umgehen. Der Daten-Abgleich nach einer Verbindungsunterbrechung zwischen PSS und SSS erfolgt beim nächsten Abgleichzyklus automatisch oder kann nach Auslösen des Abgleichalarms über die Bedienoberfläche wiederholt manuell angestoßen werden. Der Datenabgleich nach dem Verbindungsaufbau erfolgt immer vom PSS (Master) zum SSS (Slave).

Zusätzliche Funktionalitäten

1. Die Synchronisation der Treiberkonfiguration umfasst per Default den IEC, OPC, OPC UA, S7 und Modbus Treiber.

2. Splitmodus wird vom Disaster Recovery System unterstützt. Wenn der Splitbetrieb aufgehoben wird, erfolgt eine Synchronisation vom Parametriersystem auf den aktiven Rechner, sodass die Änderungen des Parametriersystems übernommen werden. Optional ist auch ein Verwerfen der Änderungen möglich.

Datenabgleich zwischen PSS und SSS

Im Normalbetrieb hat nur das PSS eine Verbindung zu den Feldgeräten (Kopfrechner mit OPC UA Anschluss) und die Treiber laufen nur am PSS. Die Synchronisation der Online-Daten (Prozessdaten) zwischen PSS und SSS wird von einem speziellen Control-Manager und dem Mechanismus der verteilten Systeme durchgeführt, welcher die Daten mit Hilfe des WinCC OA DIST-Managers vom PSS zum SSS überträgt und somit die WinCC OA Letztwert-Datenbanken identisch hält. Alle Datenpunkte bzw. Datenpunkttypen, deren Werte zwischen den beiden Systemen abgeglichen werden, müssen mit Hilfe des entsprechenden Parametrierpanels (siehe Parametrierung - Einführung) parametriert werden. Voraussetzung dafür ist, dass beide verteilten Systeme die gleichen Datenpunkte enthalten. Dies wird im laufenden Betrieb durch die Synchronisation der Datenpunkt-Parametrierung erreicht.

Dieser Abgleich der (Datenpunkt-)Parametrierung ist einerseits durch die Verwendung von WinCC OA Control-Funktionen (Timed Functions) und dem WinCC OA ASCII Manager realisiert. In einem frei definierbaren Intervall (Defaultwert ist 60 Minuten) werden die geänderten Parametrierdaten vom primären System ausgespielt und am sekundären System importiert. Dieser Abgleich kann auch deaktiviert werden, wenn die Parametrierdaten vom PSS nicht periodisch in das SSS übertragen werden sollen, oder nach der ersten automatischen Übertragung keine weiteren Parametrierdaten übertragen werden sollen, weil keine Parametrieränderungen am System zu erwarten sind.

Die Synchronisation der historischen Daten wird über die Verwendung von Oracle-Funktionen gelöst. Diese Synchronisation wird benötigt, um die Systeme nach einem Fallback wieder komplett abzugleichen, so dass auch historische Abfragen an die Datenbanken auf beiden Systemen das gleiche Ergebnis liefern.

Failover-Vorgang oder manueller Umschaltvorgang zwischen PSS und SSS

Wenn die Verbindung zwischen SSS und PSS verloren geht bzw. wenn das betriebsführende System komplett ausfällt, werden alle Treiber und Control-Manager am aktuell sekundären Serversystem gestaffelt gestartet, welches somit betriebsführend wird. Die Wartezeit zwischen den einzelnen Schritten ist über den Konfigurations-Wizard konfigurierbar. Zusätzlich wird eine Generalabfrage der Treiber angestoßen.

Auf dem Bedienrechner wird:

• Bei 2 UIs -> das WinCC OA User Interface des aktiv werdenden (sekundären) Systems in den Vordergrund geschaltet, sodass die Bedienung der Anlage weiterhin ohne großen Unterbruch möglich bleibt.

• Bei einem UI -> das WinCC OA User Interface des primären Systems verliert bei Totalausfall die Verbindung und der Benutzer startet über einen zweiten Programmaufruf das User Interface des sekundären Systems. Der Benutzer wird mittels eines Dialoges darüber informiert, dass nur das User Interface des sekundären Systems aktiv ist.

Die gleichen Aktionen werden auch durchgeführt, wenn manuell vom PSS auf das SSS umgeschaltet wird.

Fallback-Vorgang

Nimmt das ausgefallene System den Normalbetrieb wieder auf, wird ein kompletter Abgleich der Online-Daten und des Alarmstatus zwischen den beiden Systemen durchgeführt.

Verhalten des Disaster Recovery Systems bei einem Ausfall eines oder mehrerer Server

Die folgenden Unterkapitel zeigen das Verhalten des Disaster Recovery Systems in diversen Fehlerszenarien.

Die Serverbezeichnungen A, B, C, D entsprechen den Serverbezeichnungen in den Abbildungen weiter oben.

Ausfall des Servers A. Server B, C und D sind in Betrieb.

Dieser Fehlerfall wird von der standardmäßigen WinCC OA Redundanz behandelt. In diesem Fall gibt es eine Redundanzumschaltung und der passive Server des PSS wird aktiv und übernimmt alle Aufgaben und die Kommunikation mit den Feldgeräten (oder Kopfrechnern mit OPC UA Anschluss).

Ausfall des Servers B. Server A, C und D sind in Betrieb.

Wenn der passive Server des PSS ausfällt, hat dies keine Auswirkung auf den Betrieb der Anlage.

Ausfall der Server A und B. Server C und D sind in Betrieb.

Wenn beide Rechner des PSS ausfallen, übernimmt das SSS die Führung, startet die Control-Manager und Treiber, baut die Verbindung/Kommunikation zu den Feldgeräten (oder Kopfrechner mit OPC UA Anschluss) auf und bearbeitet die Daten. Das Starten der Control-Manager und Treiber findet gestaffelt statt, wobei die Zeit zwischen den einzelnen Schritten konfigurierbar ist.

Ausfall der Server A und C. Server B und D sind in Betrieb.

Dies hat keine Auswirkung auf den Betrieb der Anlage, da jeweils ein Rechner beider Systeme noch läuft. Generell gleiches Verhalten wie im ersten Fall beschrieben, obwohl die Standard Hot-Standby Redundanz am PSS auf den Server B umschaltet.

Ausfall der Server B und D. Server A und C sind in Betrieb.

Dies hat keine Auswirkung auf den Betrieb der Anlage, da jeweils ein Rechner beider Systeme noch läuft. Generell gleiches Verhalten wie im zweiten Fall beschrieben.

Ausfall der Servers A, B und C. Server D ist in Betrieb.

Wenn beide Server des PSS und der aktive Rechner des SSS ausfallen, verhält sich das System sehr ähnlich wie im dritten beschriebenen Fall. Der einzige Unterschied ist, dass jetzt der Standby-Server des SSS alle Aufgaben übernimmt.

Kapitelübersicht