Hinweise und Empfehlungen

Dieses Kapitel gibt zusätzliche Hinweise und Empfehlungen für die Konfiguration eines redundanten Systems.

Erkennung Redundanz Umschaltung - Zeitoptimierung

In einem redundanten System gibt es folgende Auslöser für eine Aktiv/Passiv Redundanz Umschaltung:

  1. Manuelle Statusänderung ausgelöst durch den Benutzer ("Vorzugslage")
  2. Manuell ausgelöste Umschaltung ("Aktiv erzwingen")
  3. Unterschiedlicher Fehlerstatus berechnet durch die automatische Fehlerstatusberechnung
  4. Netzwerkfehler mit Verbindungsverlust zum redundanten Server oder ein kompletter Ausfall eines Servers

Die Zeit für die Erkennung einer automatischen Redundanzumschaltung ist abhängig von der Konfiguration der Fehlerstatusberechnung und den konfigurierten Timeouts für die Alive Überwachung der Managerverbindungen.

Die Information welche Art Redundanzumschaltung ausgeführt wurde, wird auf die internen Datenpunkte _ReduManager und _ReduManager_2 geschrieben.

Um die Zeit für die Erkennung eines neu berechneten Fehlerstatus oder einer Netzwerk/Hardware bezogenen Umschaltung zu reduzieren können folgende Maßnahmen getroffen werden:

Automatische Fehlerstatusberechnung.

Um eine schnelle Rückmeldung und eine verkürzte Zeit für die Erkennung eines veränderten Fehlerstatus zu erreichen sollten folgende Regeln beachtet werden:

  • Konfigurieren Sie alle relevanten Parameter für die Fehlerstatusberechnung in einem spezifischen Projekt, z.B. Treiberverbindungen, SPS Verbindungen, Verbindungen zu verteilten System, etc.
  • Verwenden Sie angemessene Timeouts für die Alive Überwachung der Verbindungen zwischen Treiber und SPS.

Die meisten Treiber haben die Möglichkeit einen Timeout für die Verbindung an die SPS oder die Kommunikationspartner (OPC Server <--> OPC Client) zu konfigurieren.

Für mache Treiber muss beachtet werden, dass es nötig sein kann zusätzliche Einstellungen anzupassen wenn ein Parameter verändert wurde, welcher sich auch auf diese Einstellungen auswirkt.

Wenn die Standardwerte eines Timeouts angepasst werden muss sichergestellt werden, dass die veränderten Werte keinen negativen Einfluss auf die Funktionsfähigkeit ihres Systems haben. Dies muss durch entsprechende Tests verifiziert werden.

z.B. Wenn die Netzwerkstabilität sehr niedrig ist und/oder die Latenzzeiten sehr hoch sind, kann ein zu kurzer Timeout einen Verlust der Verbindung aufzeigen obwohl das Netzwerk noch verfügbar ist.

Um mehr Informationen über die Treiber Ihres Projektes zu erhalten lesen Sie bitte das jeweilige Kapitel innerhalb der Dokumentation.

Verbindungsverlust / Serverausfall

Zwischen dem redundanten Server Paar werden Alive Nachrichten für die Event und Redundanz Manager gesendet/empfangen.

Der Standardwert für Timeouts der Manager ist: [all sections] aliveTimeout = -10

Bei der Verwendung eines negativen Wertes für den Timeout der Alive Nachrichten werden diese nur an Manager gesendet, welche nicht auf der gleichen Maschine laufen.

Ein WinCC OA Manager erkennt einen Verbindungsverlust durch:

  • Erreichen des aliveTimeouts
  • Erhalt der Informationen durch den TCP Stack (Betriebssystem), dass die Verbindung verloren wurde

Welcher dieser Fälle zuerst eintritt hängt von der Situation und der Position des Netzwerkfehlers ab, z.B. wenn ein Kabel zu einem Server getrennt wurde, wird der Manager dieses Servers zuerst die Information über den Verbindungsverlust in den meisten Fällen durch den TCP Stack erhalten. Der Partner Manager auf dem redundanten Server wird wiederrum zuerst die Information durch den Timeout der Alive Nachricht erhalten.

Welcher dieser Fälle zutrifft kann auf der jeweiligen Maschine innerhalb der PVSS_II.log Datei nachgelesen werden, in welche eine entsprechende Log Nachricht geschrieben wird.

Um eine schnellere Rückmeldung bei einem Verlust der Netzwerkverbindung zu erreichen, kann der Wert für den aliveTimeout reduziert werden. Der empfohlene Minimalwert ist 3 Sekunden (aliveTimeout = -3).

In diesem Fall muss auf die Zuverlässigkeit der Netzwerkverbindung zwischen den beiden Redundanz Partnern geachtet werden. Nach der Anpassung der Konfiguration muss sichergestellt werden, dass kein negativer Einfluss auf die Funktionsfähigkeit des redundanten Systems besteht.