Konfigurationsdateien für die Redundanz

Config-Datei

Config-Einträge sind erforderlich,um ein redundantes System aufzusetzen. Im Folgenden werden die erforderlichen Einträge beschrieben, die beim Anlegen eines redundanten Projektes automatisch generiert werden (siehe auch Anlegen eines redundanten Systems). Die Einträge erfolgen in der Config-Datei <proj_path>/config/config. Für die Redundanz muss die Config-Datei auf beiden Rechnern folgende Einträge aufweisen:

Config Einträge - Redundanz (Optional)

Diese optionalen Config Einträge erlauben eine weitere Konfiguration des Redundanz Features.

Config Einträge - Split Betrieb

Die folgenden Config-Einträge erlauben eine erweiterte Konfiguration für den Split-Betrieb. Fügen Sie die Einträge in die [split] -Sektion der Config-Datei. (Siehe auch Kapitel Redundanz im Split-Betrieb)

[split] splitPort

Zusätzlich müssen Sie Parametrierungen für die Fehlergewichtung im Übersichtspanel der Redundanz vornehmen. Mehr zum Systemübersichtspanel erfahren Sie im Kapitel Panel Systemübersicht bei Redundanz.

config.redu-Datei

Es gibt auch Einträge in der config.redu Datei im Verzeichnis

<
wincc_oa_path
>/config/

. Für projektspezifische Einstellungen verwenden Sie eine gleichnamige Datei im Projektverzeichnis. Diese Datei wird automatisch nach der Projekt config-Datei, config.level- und config.[platform]-Dateien eingelesen. Die config.level, config.platform und config.redu-Dateien werden zuerst aus dem Versionsverzeichnis, aus dem Subprojekt-Verzeichnis und danach aus dem Projektverzeichnis gelesen, siehe Reihenfolge des Einlesens unterhalb.

Lesereihenfolge Config Dateien

PROJ_PATH/config
wincc_oa_path /config.level
SUB_PROJ_PATH/config.level
PROJ_PATH/config.level
wincc_oa_path /config.platform
SUB_PROJ_PATH/config.platform
PROJ_PATH/config.platform
wincc_oa_path /config.redu
SUB_PROJ_PATH/config.redu
PROJ_PATH/config.redu

Anmerkung: Eine config-level-Datei im Projektverzeichnis ersetzt nicht eine config-level-Datei im Versionsverzeichnis,sondern die Dateien werden zusammengeführt.

Die config.redu Konfigurationsdatei enthält die Einstellungen bezüglich Forward und Copy DPs, welche für die Redundanz relevant sind (eine Beschreibung der Forward und Copy DPs in dieser Konfigurationsdatei finden Sie auch auf der Seite Prinzip und Funktionsweise).

Die Datei enthält zusätzlich noch die Einstellungen für connectRetries und connectDelay. Der Eintrag "connectRetries" definiert die Anzahl der Verbindungsversuche zu einem anderen Manager. Zwischen den Versuchen wird "connectDelay" lang pausiert. Diese Einträge werden beim Kopieren der Datenbank benötigt.

fwdDP

Mit dem Schlüsselwort fwdDp (= Forward Datenpunkte) werden Änderungen der Originalattribute des angegebenen DP-Elements vom Event-Manager automatisch an den redundanten Event-Manager weitergeleitet (egal ob der Wert am aktiven oder passiven Event gesetzt wird). Handelt es sich beim DP-Element um einen Knoten, so gilt dies für alle darunterliegenden Blätter. Um verschiedene Elemente weiterzuleiten, kann dieses Schlüsselwort auch mehrfach angegeben werden. Das Weiterleiten dient dazu Änderungen, welche nur auf einem der beiden Rechner auftreten können (z.B. Platte voll, Verbindungsstatus zur Peripherie), auch dem jeweils anderen Rechner im Redundanzfall mitzuteilen. Siehe auch [event] fwdDP

fwdDpType

Mit dem Schlüsselwort fwdDpType (= Forward Datenpunkttyp) werden analog zu fwdDp alle Änderungen des angegebenen DP-Elements vom Event-Manager automatisch an den redundanten Event-Manager weitergeleitet. Im Unterschied zu fwdDp wird nicht ein DP-Element eines existierenden Datenpunktes angegeben, sondern das Element eines DP-Typs in der Form "Typ.Element" (z.B. "ExampleDP_Bit." für das Rootelement des DP-Typs ExampleDP_Bit). Es werden also die entsprechenden Elemente aller Datenpunkte von diesem Typ, unabhängig ob sie beim Start des Event-Managers schon existieren oder nicht, weitergeleitet. Handelt es sich beim DP-Element um einen Knoten, so gilt dies für alle darunter liegenden Blätter. Um verschiedene Elemente weiterzuleiten, kann dieses Schlüsselwort auch mehrfach angegeben werden. Siehe auch [event[ fwdDpType

VORSICHT: Neue Forward-Datenpunkttypen (fwdDpType) und Forwarddatenpunkte (fwdDp) werden zur Laufzeit nicht automatisch erkannt. Starten Sie den EVENT-Manager in der WinCC OA-Konsole neu, damit die neuen fwdDpTypen und fwdDatenpunkte erkannt werden.

dpSet mit vielen Elementen mit fwdDP und ohne fwdDP

Werden in einem dpSet-Aufruf (CTRL-Manager) dpSets mit vielen Elementen gleichzeitig ausgeführt und dabei Elemente mit fwdDP und ohne fwdDP in einem dpSet-Aufruf gemeinsam verwendet gilt folgende Regel:

Für ALLE DPE im dpSet wird die fwdDP-Einstellung des ersten Elements in der dpSet-Liste verwendet.

Ist also das 1. Element ein fwdDP, dann werden alle Elemente des dpSet-Aufrufs auf der passiven Seite geschrieben und auf die aktive Seite übertragen. Ist hingegen das 1. Element kein fwdDP, wird keines der Elemente übertragen.

copyDp

Mittels des Eintrages copyDp wird festgelegt, dass die Werte eines Datenpunktelmentes (Quell-Datenpunktelement) auf ein zweites Datenpunktelement (Ziel-Datenpunktelement) kopiert werden. Änderungen der Originalattribute des Quell-Datenpunktelementes werden vom Event-Manager automatisch auch für das Ziel-Datenpunktelement durchgeführt. Der Ziel-Datenpunkt muss den gleichen Datenpunkttyp aufweisen wie der Quell-Datenpunkt! Handelt es sich bei dem Quell-Datenpunktelement um einen Knoten, so werden alle darunter liegenden Blätter ebenfalls kopiert. Um mehrere Elemente zu kopieren kann der Eintrag copyDp auch mehrfach angegeben werden. Copy DPs sind Elemente, die auf beiden Rechnern im Normalfall gleich sind, wie z.B. Parametrierungen oder das Auslösen von Befehlen (GA, Archivsatzwechsel). Siehe auch [event] copyDp

copyDpType

Mittels des Eintrags copyDpTypes werden die Werte des Originalattributes eines Datenpunktelements (Quell-Datenpunktelement) bei Änderungen automatisch durch den Event-Manager auf die Elemente des angegebenen Datenpunkttypes kopiert (analog zu copyDp). Siehe auch [event] copyDpType

Wenn zwei Datenpunkte dieses Typs die Namen <DP-Name> und <DP-Name>_2 haben, wird das <DP-Name>.<Element> automatisch auf <DP-Name>_2.<Element> kopiert.

Syntax:

[event]
copyDpType = "<Datenpunkttyp>.<Datenpunktelement>"

Achtung

<DP-Name> darf nicht mit "_2" enden, da diese in diesem Fall nicht kopiert werden, z.B.: Die Datenpunkte Iec_2 und Iec_2_2 werden nicht mit copyDpType kopiert.

Beispiel

Wenn ein Datenpunkt in WinCC OA erstellt wird, der mit einem in den Config-Einträgen copyDP, copDpType, fwdDp oder fwdDpType definierten übereinstimmt, wird dieser automatisch weitergeleitet/kopiert, ohne dass das Projekt neu gestartet werden muss.

Die Einträge für Forward und Copy DPs erfolgen in der [event]-Sektion der config.redu Datei, z.B.:

# Message- und Configs-Statistik Informationen
[event]
copyDp = "_Stat_Configs_Refresh.SecsToRefresh" "_Stat_2_Configs_Refresh"
copyDp = "_Stat_Connections_Refresh.SecsToRefresh" "_Stat_2_Connections_Refresh"
fwdDpType = "_Statistics_Connections."
fwdDpType = "_Statistics_DataConfigs."
fwdDpType = "_Statistics_DriverConfigs."
fwdDpType = "_Statistics_EventConfigs."
# DNP3 driver settings
[event]
fwdDpType = "_Dnp3Station.State"
copyDpType = "_Dnp3Station.Configuration"
copyDpType = "_Dnp3Station.Command"

In einem redundanten System werden für Treiber in der Regel unterschiedliche Datenpunkte für das rechte und das linke System verwendet. Dies ist notwendig, da verschiedene Statusinformationen auf den beiden Systemen getrennt dargestellt werden müssen (z.B. linkes System _Dnp3StationA und rechtes System _Dnp3StationA_2).

Der fwdDpType-Eintrag ist notwendig, damit ein Datenpunkt auch am passiven System gesetzt werden darf (Z.B. muss auch der passive Treiber seinen Verbindungszustand zur Station setzen können.).

Der copyDpType Eintrag vereinfacht die Parametrierung, da er automatisch die DPE Werte auf den *_2 Datenpunkt kopiert und somit die Konfigurations-DPEs synchron hält.

Es gibt aber auch weitere Redundanz spezifische Einträge in anderen Sektionen wie [general], [data], usw. Die in der Datei in Klammer angeführten Einträge "$host1" und "$host2" bei diesen spezifischen Einstellungen werden automatisch durch den Hostnamen des linken ($host1) und durch den Hostnamen des rechten Rechners ($host2) ersetzt.

Alle wesentlichen Einträge für die Redundanz sind in dieser Datei standardmäßig vordefiniert. Der Parametrierer muss lediglich für sein Projekt spezifische Einstellungen vornehmen (z.B. Einstellungen für die verwendeten Treiber). Pro Treiber sind die möglichen Einstellungen in der config.redu erklärt und außerdem finden Sie bei jedem Treiber einen Abschnitt, der als Vorlage für die eigenen projektspezifischen Einstellungen verwendet werden kann. Ein Beispiel wie Sie die config.redu Datei an ein Projekt anpassen (Parametrierung für den S7-Treiber im Redundanzfall) finden Sie auf der Seite Prinzip und Funktionsweise.

Anmerkung: Für redundante Systeme ist der Config Eintrag [event] redOldNewComp standardmäßig aktiviert. Dadurch wird verhindert, dass im Falle einer GA nach einer Redundanz-Umschaltung alle Werte zurückgeliefert werden. Dies würde zu einer großen Anzahl an übertragenden Daten führen und eine Verzögerung verursachen.

VORSICHT: Projektspezifische Einträge müssen in der config.redu-Datei des Projektverzeichnisses gemacht werden!

VORSICHT:

Wenn bei einem redundanten Projekt die maximale Zeit, die für das Kopieren der Datenbank verwendet werden soll, erreicht wird, wird folgende Fehlermeldung ausgegeben:

(0), 2004.06.25 17:00:56.396, REDU, WARNING, 54, Unexpected state, DataManager, recoveryTimeoutExpired, Recovery timeout expired, aborting recovery and starting active

Die maximale Zeit, die für das Kopieren verwendet werden darf, muss in der config.redu-Datei mit dem Eintrag passiveRecoveryTimeout definiert werden. z.B. passiveRecoveryTimeout = 10

Nach Ablauf des Recovery Timeouts versucht der Data Manager automatisch das Recovery erneut auszuführen.

Beispiele für Config-Einträge bei verschiedenen Konfigurationen

Beispiel

Die Einträge für ein redundantes System bestehend aus zwei Hosts (Hostnamen Host1 und Host2) werden wie angeführt definiert:

Host1:

[general]
data   = "Host1-1,Host1-2$Host2-1,Host2-2"
event  = "Host1-1,Host1-2$Host2-1,Host2-2"

Host2:

Am Host2 müssen die gleichen Einträge wie am Host1 definiert werden.

Beispiel

Ein redundant verteiltes System bestehend aus drei verschiedenen Systemen (zwei redundante und ein zusätzliches Single System), welche alle miteinander verbunden sind:

Verteiltes System1 (Hostnamen System1_host1 und System1_host2)

System1 verbindet sich zu System2 und System3:

[general]
data   = "System1_host1-1,System1_host1-2$System1_host2-1,System1_host2-2"
event  = "System1_host1-1,System1_host1-2$System1_host2-1,System1_host2-2"
distributed = 1
[dist]
distPeer = "System2_host1$System2_host2" 2
#Baue Verbindung zu beiden Hosts
#mit der Systemnummer 2 auf
distPeer = "System3_host" 3
#Baue Verbindung zu System 3 auf

Hinweis

Bitte beachten Sie, dass es für die"[dist] distPeer Verbindung kein redundantes Netzwerk verwendet wird.

Verteiltes System2 (Hostnamen System2_host1 und System2_host2)

System2 verbindet sich zu System1 und System3:

[general]
data   = "System2_host1-1,System2_host1-2$System2_host2-1,System2_host2-2"
event  = "System2_host1-1,System2_host1-2$System2_host2-1,System2_host2-2"
distributed = 1
[dist]
distPeer = "System3_host"
#Baue Verbindung System 3 auf

Verteiltes System3 (Hostname System3_host)

System3 ist Server für System1 und System2 und benötigt aus diesem Grund keinen distPeer-Eintrag:

[general]
distributed = 1

Anmerkung:

Die Reihenfolge, in der die Hosts in der Config-Datei eingetragen werden, muss immer die gleiche sein. Das bedeutet, dass, wenn z.B. im Config-Eintrag data die Hosts folgendermaßen eingetragen wurden:

data = "host1-1,host1-2$host2-1,host2-2"

im distPeer Config-Eintrag diese in der gleichen Reihenfolge eingetragen werden müssen:

distPeer = "host1[:port1][$host2[:port2]]" Systemnummer

Eine andere Reihenfolge (distPeer = "host2[:port1][$host1[:port2]]" Systemnummer) verursacht Verbindungsfehler.

Mehr zu verteilten Systemen erfahren Sie auch im Kapitel Grundlagen verteilte Systeme. Auf der Seite Beispiel für ein redundant verteiltes System finden Sie eine schrittweise Anleitung für das Aufsetzen eines redundant verteilten Systems.