Redundanz im Split-Betrieb
Es gibt die Möglichkeit bei redundanten Systemen in den sogenannten Split-Betrieb zu wechseln. Im Split-Betrieb wird das redundante Serverpaar in zwei Einzelsysteme aufgespaltet. Ein System arbeitet "aktiv" im Betrieb weiter, kommuniziert mit der Peripherie, leitet Wertänderungen weiter, etc. Das andere System kann für den Test neuer Konfigurationen und Parametrierungen verwendet werden ohne störend in den laufenden Betrieb einzugreifen. Für die Verwendung des Split Betriebs muss der Split Manager innerhalb des Projektes gestartet sein.
Nachdem die Tests mit neuen Konfigurationen abgeschlossen sind, erfolgt eine automatische Rückführung zur Redundanz auf Basis eines der beiden Server (beibehalten der ursprünglichen Konfiguration oder Etablierung der neuen Konfiguration) erfolgen.
Im Split-Betrieb gibt es hinsichtlich der Telegrammlauflogik in Melde- und Befehlsrichtung wesentliche Unterschiede zum Redundanzmodus. Auf dieser Seite wird Ihnen die Funktionalität und Umgang mit dem Split-Betrieb näher gebracht.
Der Wechsel in den Split-Betrieb erfolgt durch Klick auf die Schaltfläche Split-Betrieb im Systemübersichtspanel (siehe auch Panel Systemübersicht bei Redundanz).
Die Abbildung zeigt in einfacher Form die Funktionalität des Split-Betriebs. Wie bereits erwähnt, wird das redundante System entkoppelt. Durch die Trennung entsteht somit ein "aktives" und ein Testsystem. Das aktive System arbeitet normal weiter und versorgt die Bedienstationen. Die Event-Manager beider Systeme sind im Unterschied zur Redundanz aktiv. Die UIs haben Verbindung zu beiden Event-Managern.
Der Split-Manager läuft während des Split-Betriebs (der Redu-Manager ist währenddessen im Stand-by) und tauscht vordefinierte Daten zwischen den Systemen aus. Welche Daten ausgetauscht werden sollen, kann über die Datenpunktgruppen SplitGet[_2] und SplitConnect[_2] eingestellt werden. SplitGet[_2] ist der Defaultname der Gruppe an Datenpunkten, welche beim Übergang in den Splitmodus (wenn beide Splitmanager die Verbindung bekommen) kopiert werden. Das ist ein einmaliger Abgleich. Wenn sich die Splitmanager verbinden, machen die ein dpGet() auf diese Datenpunkte und übertragen die Werte an den anderen Splitmanager.
SplitConnect[_2] ist der Defaultname der Gruppe an Datenpunkten, welche im Splitmodus bei jeder Änderung übertragen werden. Das heißt, wenn sich die Splitmanager verbinden, machen sie ein dpConnect auf diese DPs und übertragen die Änderungen an den anderen Splitmanager.
Mehr zu DP-Gruppen erfahren Sie im Kapitel Grundlagen Datenpunktgruppen. Standardmäßig werden interne Systemzustände zwischen den Rechnern ausgetauscht (in den beiden DP-Gruppen sind DPEs enthalten, die für Verbindungsstati, Festplattenplatz, Arbeitsspeicher, Überwachung des redundanten Netzwerkes, etc. zuständig sind). Um projektspezifische Datenpunktelemente zwischen den beiden Systemen im Split-Betrieb auszutauschen, müssen die vorhandenen DP-Gruppen erweitert werden.
Durch verschiedene Parametrierungen am Testsystem (Anlegen/Löschen von Datenpunkten) ergeben sich verschiedene Datenbestände auf beiden Systemen, die einen wesentlichen Einfluss auf die Funktionalität und Handhabung im Split-Betrieb hinsichtlich Melde- und Befehlsrichtung bewirken.
So arbeiten Sie mit dem Split-Betrieb
- Schalten Sie im Systemübersichtspanel den Server, der normal im Betrieb weiterarbeiten soll aktiv (Klick auf die Schaltfläche Vorzugslage - ACHTUNG: kann nur durchgeführt werden, wenn auf beiden Rechnern der gleiche Fehlerstatus vorliegt).
- Wechseln Sie in den Split-Betrieb (Klick auf die Schaltfläche Split-Betrieb im Systemübersichtspanel).
Anmerkung: Beim Umschalten in den Splitmode und beim Umschalten der Treiber wird die Umschaltung für das lokale UI (auf dem die Umschaltung stattgefunden hat) für 30 Sekunden disabled. D.h. die Schaltfläche "Aktive Treiber" wird ausgegraut.
- Der Treiber auf jenem System, das normal im Betrieb weiterarbeitet, bleibt aktiv (Schaltfläche Aktive Treiber).
- Starten Sie ein weiteres User Interface mit der Kommandozeilenoption "-data hostname[:port]" und "-event hostname[:port]", das sich auf des Testsystem verbindet oder öffnen Sie das ASCII-Manager Panel.
- Führen Sie Änderungen an der Konfiguration (DPs anlegen/löschen) am Testsystem mit dem gestarteten UI durch. Bei Änderungen mit Hilfe des ASCII-Manager Panels muss unbedingt der richtige Hostname bei der Verbindung im Panel angezeigt werden, damit die Änderungen am richtigen Rechner und in der richtigen Datenbank durchgeführt werden. Mit der Schaltfläche Umschalten im ASCII-Manager Panel können Sie den richtigen Rechner (Testsystem), wo die Änderungen durchgeführt werden sollen wählen (siehe auch ASCII-Panel). Legen Sie am Testsystem z.B. den Datenpunkt "TestDP_split" vom Typ "ExampleDP_Float" an.
- Testen Sie die geänderte Konfiguration am Testsystem.
- Wenn die vorgenommenen Änderungen zufriedenstellend sind, schalten Sie den Treiber am Testsystem aktiv, um die neue Konfiguration an die Peripherie anzubinden.
Anmerkung:
Für das Aktivsetzen des Treibers am Testsystem muss die SPS bereits an die neue Konfiguration angepasst sein, damit neu angelegte DPs mit der SPS verwendet werden können!
- Während dieser ganzen Zeit bleiben alle anderen UIs bedienbar.
- Wechseln Sie wieder in den Redundanz-Betrieb (Klick auf die Schaltfläche Redundanz). Als Basis für den Redundanz-Betrieb wird z.B. der Rechner mit der geänderten Konfiguration (= Testsystem) herangezogen, der andere Rechner startet neu und übernimmt die neue Konfiguration durch das automatische Recovery beim Hochlauf.
- Ein UI wird über die Console gestartet (ohne Kommandozeilenoptionen), welches sich zu beiden Rechnern verbindet und bekommt eine Nummer vom Data-Manager (Aktiver sowie Passiver) zugewiesen (z.B. Nummer 1).
- Anschließend wird ein UI mit den Optionen "-data hostname[:port]" und "-event hostname[:port]" über die Console gestartet und bekommt eine Nummer vom jeweiligen Data-Manager, zu dem die Verbindung aufgebaut wird, zugewiesen (z.B. Nummer 2).
- Ein weiteres UI wird über die Console gestartet (ohne Kommandozeilenoptionen), welches sich erneut zu beiden Rechnern verbindet und bekommt vom Data-Manager am ersten Rechner die Nummer 3 (da Nummer 1 und 2 von diesem Data-Manager bereits vergeben sind), vom Data-Manager des zweiten Rechners die Nummer 2 (da dieser Data-Manager bisher nur Nummer 1 vergeben hat) zugewiesen.
In diesem Fall beendet sich das dritte UI mit einer Fehlermeldung.
Telegramme in Melderichtung
Mit Hilfe der nachfolgenden Grafiken soll der Lauf der Telegramme im Split-Betrieb veranschaulicht werden. In den Grafiken ist die linke Seite immer als aktives und die rechte Seite immer als Testsystem anzusehen. Weiters muss man unterscheiden für welchen Datenraum (entweder für einen DP, der nur im aktiven System oder nur am Testsystem oder auf beiden Rechnern existiert) der Wert, der von der Peripherie gemeldet wird, bestimmt ist.
Die erste Abbildung zeigt die Telegrammlauflogik für den Fall, dass der Wert, der von der Peripherie hochgemeldet wird, auf ein Element im aktiven System abgebildet wird. Das UI muss auf den aktiven Rechner geschaltet werden. Die Umschaltung der UIs zwischen den Rechnern erfolgt im Kontextmenü für die UIs, das aus im Systemübersichtspanel aufgeschaltet wird.
Mit dem Eintrag UI Umschaltung zu eiwrk017 bzw. UI Umschaltung zu eiwrk028 schalten Sie ein UI auf den Event-Manager des aktiven bzw. auf den Event-Manager des Testsystems. Hierbei wird definiert, von welchem Server die Daten empfangen werden (die Daten des anderen Servers werden verworfen, siehe Beschreibung unterhalb). Es ist jedoch zu beachten, dass Befehle weiterhin an beide Systeme gesendet werden, unabhängig der Auswahl durch die UI Umschaltung.
Die Abbildung (siehe Abbildung "Telegramm in Melderichtung") zeigt die Telegrammlauflogik für den Fall, dass der Wert, der von der Peripherie hochgemeldet wird, auf ein Element abgebildet wird, das auf beiden Systemen existiert. Hierbei ist es egal auf welchem Rechner das UI geschaltet ist. Die Treiber auf beiden Systemen verarbeiten den Wert von der Peripherie und leiten diesen an die Event-Manager weiter. Beide Event-Manager leiten wiederum den Wert an das UI weiter. Schließlich entscheidet das UI von welchem Event es den Wert akzeptiert, der andere wird verworfen.
Befindet sich das Element am Testsystem (wie im Beispiel der neu angelegte Datenpunkt "TestDP_split"), muss das UI auf der rechten Seite "hängen". Dieser Fall wird in der dritten Abbildung gezeigt.
Telegramme in Befehlsrichtung
Für Telegramme in Befehlsrichtung wird wiederum mit Hilfe von Grafiken die Telegrammlauflogik erklärt. Das linke System ist als Aktives das rechte System als Testsystem anzusehen.
Die erste Abbildung zeigt die Telegrammlauflogik für den Fall, dass der Wert, der an die Peripherie geschickt wird, nur auf einem Datenpunktelement im aktiven System gesetzt wird. Das UI muss beim Setzen des Wertes auf den aktiven Rechner geschaltet sein. Die Umschaltung der UIs zwischen den Rechnern erfolgt im Kontextmenü für die UIs, das aus dem Systemübersichtspanel aufgeschaltet wird. Zusätzlich muss der Treiber auf jenem System aktiv sein, das auch das Element aufweist, dessen Wert an die Peripherie übergeben wird (in der Abbildung oben ist der aktive Treiber orange hinterlegt). Die Umschaltung der aktiven Treiber erfolgt im Systemübersichtspanel mit der gleichnamigen Schaltfläche.
Die zweite Abbildung zeigt die Telegrammlauflogik für den Fall, dass der Wert, der an die Peripherie geschickt wird, auf einem Element gesetzt wird, das auf beiden Systemen existiert. Hierbei ist es egal, auf welchem Rechner das UI geschaltet ist bzw. welcher Treiber aktiv ist. Das UI schickt den Wert an beide Events, diese wiederum an die Treiber und der aktive Treiber schickt den Wert weiter an die Peripherie. Der andere Treiber verwirft den Wert.
In der dritten Abbildung befindet sich das Element am Testsystem (wie im Beispiel der neu angelegte Datenpunkt "TestDP_split") und das UI muss somit auf der rechten Seite "hängen". Der Treiber muss in diesem Fall auf der rechten Seite (Testsystem) aktiv sein.
Im Split-Betrieb sieht das Systemübersichtspanel wie in der folgenden Abbildung aus:
Im Übersichtspanel ist das System mit dem aktiven Treiber ersichtlich (in diesem Fall ist der Treiber am Rechner eiwrk017 aktiviert, bei eiwrk028 ist die Tabelle "Treiber" ausgegraut). Mit der Schaltfläche Aktive Treiber schalten Sie den Treiber am gewünschten System aktiv, am anderen System wird die Tabelle "Treiber" grau hinterlegt.
Wird das redundante Projekt zusätzlich verteilt betrieben (d.h. das redundante System ist zu weiteren WinCC OA Systemen verbunden), finden Sie im Split-Betrieb unter Aktive Treiber zwei weitere Schaltflächen mit Namen Aktiver Dist und Aktiver Event. Mit der Schaltfläche "Aktiver Dist" bestimmen Sie welcher Dist-Manager aktiv sein soll. Da in einem verteilten System die Kommunikation zwischen den Einzelsystemen über die Dist-Manager aufrecht erhalten wird und der Dist-Manager immer den aktiven Event-Manager kontaktiert, muss im Split-Betrieb der aktive Dist bestimmt werden (da in diesem Fall beide Event-Manager aktiv sind).
Mit Aktiver Event wird nicht der Event selbst aktiv geschaltet (Wie bereits erwähnt müssen beide Event-Manager aktiv sein, um erhaltene Messages zu verarbeiten), sondern SplitActive wird aktiviert/deaktiviert.
Obwohl im Splitmodus beide Events aktiv sind, darf nur ein Event die erhaltenen Messages an das andere System weiterleiten (nur ein Event darf dpSets an fremde Systeme weiterleiten, da ansonsten Befehle im fremden System zweimal ausgeführt werden würden). Da beide Event-Manager aber aktiv sind, wird ein weiteres Flag zur Steuerung benötigt - das _ReduManager.SplitActive.
Das ReduManager-Datenpunktelement SplitActive ist TRUE für die aktive Event-Seite. Sinnvollerweise sollten alle drei Managertypen auf der gleichen Seite aktiviert bzw. deaktiviert werden, es ist aber auch getrennt möglich.
Das ReduManager-Datenpunktelement SplitMode enthält die Information, ob Splitbetrieb aktiviert ist.
In der Statuszeile des Systemübersichtspanel sehen Sie zusätzlich zu den bereits beschriebenen Einträgen (siehe Panel Systemübersicht bei Redundanz) den Rechnernamen, auf dem das UI "hängt" (... - Eiwrk028). Mit der Schaltfläche Redundanz erfolgt eine Rückführung in den Redundanz-Betrieb. Vor der Rückführung erfolgt eine Abfrage wie weitergearbeitet werden soll. Wählen Sie in diesem Dialogfenster den Rechner mit dessen Konfiguration Sie die Redundanz weiterführen möchten. Das Projekt am anderen Rechner wird dadurch neu gestartet.
Während das Projekt am redundanten Partner neu gestartet wird, wird dieser im Systemübersichtspanel ausgeblendet, was in der folgenden Abbildung gezeigt wird.
