Disaster Recovery System

Hohe Verfügbarkeit und Ausfallsicherheit wird in der Automatisierungstechnik immer wichtiger. Schon ein kurzzeitiger Ausfall kann zu erheblichen Kosten und Sicherheitsrisiken führen. Dies soll mithilfe des WinCC OA Disaster Recovery Systems verhindert werden.

WinCC OA verfügt als Leitsystemsoftware über ein integriertes Hot-Standby-Redundanzkonzept. Mit diesem können die hohen Anforderungen von Anlagenerstellern und -betreibern an die Verfügbarkeit sowie die Prozess- und Datensicherheit abgedeckt werden. Die Ausfallsicherheit in einem redundanten System mit WinCC OA wird durch Hot-Standby realisiert. Es handelt sich dabei um ein Sicherheitskonzept, welches aus zwei miteinander verbundenen Servern besteht. Beide sind ständig in Betrieb und unterliegen der gleichen funktionsbedingten Beanspruchung. Es ist immer nur ein Server aktiv. Der zweite passive Server gleicht die Daten zur Laufzeit ab. Bei Ausfall einer Einheit erfolgt ein "fliegender Wechsel" und der bis dahin passive Server übernimmt den Führungsbetrieb.

Mit dem Disaster Recovery System wird das Redundanzkonzept um ein Warm-Standby-System erweitert, so dass die Bedienbarkeit der Anlage auch im Falle eines Komplettausfalls oder Komplettstilllegung im Zuge von z.B. Wartungsarbeiten beim ersten redundanten System trotzdem erhalten bleibt. Der Datenverlust und die Stillstandzeit werden so gering wie möglich gehalten. Dies wird dadurch erreicht, dass dem ersten redundanten Hot-Standby-System ( primäres Serversystem; PSS) ein zweites System, ein so genanntes sekundäres Serversystem(SSS), zugewiesen wird und zwischen den beiden Systemen ein " Warm-Standby" realisiert wird. Dies bedeutet, dass die Daten zwischen den Systemen in definierbaren Intervallen abgeglichen werden.

Dies hat zwei Vorteile:

  1. Im Falle eines Komplettausfalls eines Systems bleibt die Anlage bedienbar.

  2. Die historischen Daten können im Nachhinein wieder abgeglichen werden.

Die Hauptanforderung an das Disaster Recovery System ist es, den Datenverlust, die Unbedienbarkeit und die Stillstandzeit von der Seite des Leitsystems so gering wie möglich zu halten. Um dies zu gewährleisten, ist ein ständiger Abgleich der Online- und Parametrierdaten zwischen dem PSS (Primary Server System) und SSS (Secondary Server System) unumgänglich. Da die Menge dieser Daten aber sehr umfangreich ist und an die Größe des Projektes gebunden ist, ist es dem Anlagenbetreiber bzw. dem Integrator weitestgehend möglich den Umfang und die Abgleichintervalle zwischen den beiden Systemen selbst zu verwalten und zu definieren.

Folgende Funktionalitäten werden vom Disaster Recovery System zur Verfügung gestellt:

  • Abgleichder Online-Datenänderungenzwischen PSS und SSS zur Laufzeit. Beim Start werden nur Werte vom aktiven zum passiven System synchronisiert.

  • Abgleichdes Alarmstatus(Quittierstatus, Quittierzeit, Quittierbenutzer, Alarmkommentare) zwischen PSS und SSS zur Laufzeit.

  • Zyklischer Abgleich der Parametrieränderungen (Meldebehandlung, Datenpunktfunktionen, usw.) zwischen PSS und SSS.

  • Automatischer (zyklischer) oder manuell angestoßener Abgleichder Projektdateien(Paneldateien, Control-Skripts und -Libraries, Datenpunktlisten, Farbdatenbanken, Grafikdateien/Bilder, Textkataloge).

  • Synchronisation der historischen Daten (über Oracle Packages) bei Anstoß durch den Benutzer nach einem Systemausfall des SSS oder Verbindungsunterbruch zwischen PSS und SSS.

  • Abgleich der Benutzerverwaltung (Benutzerdaten).

  • Automatische Umschaltung zwischen PSS und SSS und automatische/manuelle Rückschaltung zwischen SSS und PSS.

  • Automatische Umschaltungam Client zwischen der Bedienoberfläche des PSS und SSS zum aktuell führenden System (zwei Bedienoberflächen parallel aktiv), wenn eine zweite UI-Lizenz vorhanden ist. Ansonsten ist ein manueller Start nach Ausfall des ersten Systems notwendig.

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.

Abbildung 1. Ausfall des primären Serversystems

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.

Abbildung 2. Verbindungsunterbruch zwischen dem primären und sekundären Serversystem

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

Kapitel Beschreibung
Grundlagen zum Disaster Recovery System Grundlegende Informationen zum Disaster Recovery System, dessen Funktionen, Systemarchitektur (PSS, SSS), Betrieb und Verhalten bei Ausfall eines Servers.
Voraussetzungen und Installation Voraussetzungen und Installation des Disaster Recovery Systems
Konfiguration und Einbinden des Disaster Recovery Systems Schrittweise Anleitung zum Einrichten eines Disaster Recovery Systems
Parametrierung des Disaster Recovery Systems
Parametrierung - Einführung Einführende Informationen zur Parametrierung des Disaster Recovery Systems
Parametrierung Beschreibung der verfügbaren Wizards zur allgemeinen Parametrierung des Disaster Recovery Systems (aufgeteilt auf 5 Schritte)
System Übersicht Beschreibung des Übersicht-Panels des eingerichteten Disaster Recovery Systems
Dateien Abgleich Beschreibung des Panels zur Parametrierung des Abgleichs von Projektdateien
Abgleich historischer Werte in der Datenbank Beschreibung des Panels zur Parametrierung eines historischen Datenbankabgleichs
Datenbank-Konfiguration
Voraussetzungen und Installation Voraussetzungen und Vorbereitung der Datenbank für einen historischen Datenbankabgleich
Abgleichvorgang Beschreibung des Vorgangs bei einem historischen Datenbankabgleich
Status des Abgleichs Beschreibung der möglichen Statuszustände beim historischen Datenbankabgleich
Steuerung des Client-Verhaltens Steuerung des Client-Verhaltens mithilfe eines Disaster Recovery System Referenzobjektes
Interne Datenpunkttypen des Disaster Recovery Systems Beschreibung der internen Datenpunkttypen _2x2_FileSync, _2x2_Redundancy und _2x2_DriverConnectionStates
Mögliche Config-Einträge Beschreibung der Config-Einträge des Disaster Recovery Systems
Debug-Flags des Disaster Recovery Systems Beschreibung der verfügbaren Debug-Flags.
Hinweise und Einschränkungen Hinweise und Einschränkungen, die bei der Verwendung des Disaster Recovery Systems beachtet werden sollten
Glossar Erklärungen zu den verwendeten Begriffen und Abkürzungen in der Hilfe zum Disaster Recovery System