WinCC OA Redundante Systeme DE PDF

WinCC OA Redundanz
Folien, Beispiele und Kommentare
Inhalt
3 Voraussetzungen / Inhalte
4
Redundanz
Erforderliche Komponenten
Aufgaben von Redundanz in WinCC OA
Kommunikation in WinCC OA
Voraussetzungen fr Hot-Standby
Redundantes WinCC OA-System im Detail
11 Redu-Umschaltung im Detail
17
Redundante LAN-Verbindungen
18 Ausfallverhalten bei redundanten LAN-Verbindungen

19 Prioritten bei System-Umschaltung
20 Telegrammlauflogik: Melderichtung
22 Telegrammlauflogik: Befehlsrichtung
24 Splitbetrieb
27 bungsteil 1
Redundantes Projekt anlegen
43 bungsteil 2
Fehlergewichtungen einstellen
53 bungsteil 3
config.redu anpassen
59 bungsteil 4
Splitbetrieb
66
Redundanzumschaltungen
bungsteil 5
71 bungsteil 6
ETM professional control GmbH
Dateiabgleich
WinCC OA Redundanz
2
Voraussetzungen / Ziele
Schulungsmodul aufbauend auf:

WinCC OA Basisschulung
Eventuell Linux-Schulung
Schulungsziel:
Einfhrung in die Grundlagen der Redundanz
Kennen lernen der Redundanz in WinCC OA
Aufsetzten und konfigurieren eines redundanten Systems
Siemens AG 2010. Alle Rechte vorbehalten.
Definition:
Redundanz ist das Vorhandensein von mehr funktionsfhigen Mitteln in einer Einheit, als fr die
Erfllung der geforderten Funktion notwendig sind.
Es wird unterschieden:
Hot Standby Redundanz : Das zustzliche technische Mittel ist stndig in Betrieb
und unterliegt funktionsbedingter Beanspruchung, d. h. der gleichen
Beanspruchung wie die Primreinheit.
Warm Standby Redundanz: Das Redundanzmittel ist bis zum Ausfall der
arbeitenden Einheit oder bis zu seinem eigenen Ausfall einer kleineren Belastung
ausgesetzt.
Cold Standby Redundanz (Standby-, unbelastete Redundanz): Das zustzliche
technische Mittel ist bis zum Ausfall der arbeitenden Einheit keiner Belastung
ausgesetzt.
Bei hochverfgbaren Systemen wird Redundanz dazu eingesetzt, die Funktion auch bei Ausfall
einer Einheit aufrecht zu erhalten. Bei nicht funktionsbeteiligter Redundanz (kalte und teilweise
auch warme Redundanz) wird eine ausgefallene Einheit durch eine redundante Funktionseinheit
ersetzt. Bei funktionsbeteiligter Redundanz (heie und zum Teil auch warme Redundanz) wird die
Funktion gleichzeitig von allen intakten Funktionseinheiten erbracht.
Bei sicherheitsgerichteten Anwendungen wird Redundanz dazu genutzt, da bei Ausfall einer
Einheit ein nicht sicherheitsgefhrdender Systemzustand eintritt.
Bei sicherheitsorientierten Systemen gilt das Bestreben, das System in einem sicheren Zustand
zu halten bzw. in einen sicheren Zustand zu berfhren.
Failsafe nennt man die Eigenschaft eines Systems, welches durch geeignete organisatorische und
technische Manahmen entweder deterministisch Gefahrenmomente verhindert oder sie auf ein
tolerierbares Ma reduziert.
WinCC OA Redundanz
3
Redundanz
Motivation:
Erhhen der Datensicherheit durch doppelte Datenhaltung in zwei getrennten
Datenbanken
Gewhren der bestmglichen Anlagensicherheit durch Vermeidung von
Betriebsunterbrechungen
Lsungsansatz:
Erweiterung des Event- und Data-Managers um speziellen Funktionen zum
Datenabgleich zwischen den Systemen sowie Integration sogenannter ReduManager zum Austausch der Systemstati.
Benutzte Schnittstellen:
TCP/IP
Anmerkung:
Verfgbarkeit
Proze A hat z.B. eine Verfgbarkeit von 0,90
A
A
Zwei parallele Prozesse A (redundantes System) haben dann

eine Verfgbarkeit von A v A=1-(1-0,9).(1-0,9)=0,99
In der Praxis zeigt sich jedoch, dass die Redundanz als Mechanismus fr sich eine zustzliche
Fehlerquelle in sich birgt. Es ist also in Bezug auf obiges Beispiel mit einer geringeren
Verfgbarkeit (ca. 0,96 bis 0,98) zu rechnen.
Anmerkung:
Obiges Beispiel dient nur zur Illustration der prinzipiellen Funktionsweise eines redundanten
Systems und stellt nicht die tatschlichen Verfgbarkeitszahlen von WinCC OAII dar.
WinCC OA Redundanz
4
Erforderliche Komponenten
WinCC OA:
Entsprechende Lizenz (Shield-File)
Hardware Anforderungen:
1 Netzwerkkarte
optional: 2 Netzwerkkarten fr redundante LAN-Verbindung
Anmerkung:
Fr Redundanz sind mindestens 2 Rechner mit gleichem Betriebsystem und identischer WinCC
OA-Version (inkl. Patches) notwendig.
Zustzlich mssen die Pfade des WinCC OA-Projektes auf den beiden Systeme ident sein.
WinCC OA Redundanz
5
Aufgaben der Redundanz in WinCC OA
Ausfallsicherheit durch Hot-Standby

Abgleich der dynamischen Daten zur Laufzeit
Abgleich der Daten beim Hochlauf (Recovery)
Interpretation der Systemstati und Verwaltung der Aktiv/Passiv-Level
Erlauben von multiplen Verbindungen zu redundanten Doppeleinheiten
(z.B. 1 UI-Manager zu 2 Systemen)
Fr das UI unmerkliche Umschaltung
WinCC OA Redundanz
6
Kommunikation in WinCC OA
UIM
UIM
Ctrl
DM
UIM
API
Verarbeitungsebene
Kommunikationsund Speicherebene
EV
Userinterface Ebene
Treiberebene
Anmerkung:
Client-Server -Konzept
Der Event-Manager (EV) und der Datenbank-Manager (DM) verhalten sich wie Server; die anderen
Manager wie Clients. Die Verbindung untereinander erfolgt ber TCP/IP.
Alle Mitteilungen, die die Manager untereinander austauschen mssen/wollen, werden anhand von
sog. Messages durchgefhrt. Der Aufbau einer Message ist genau durch das API festgelegt. Die
Frage - Antwort Mechanismen sind ebenfalls genau festgelegt.
Einzelne Manager (EV, T, DM) besitzen jeweils eigene Parametrierungen (= Konfigs).
Der EV beinhaltet das gesamte aktuelle Prozeabbild = die Werte = Originalwert, Quellzeit und
Statusbits.
Bei einer Datenanforderung der einzelnen Manager bekommen diese eine Antwort vom EV wenn
sich die Datenanforderung auf aktuelle Daten bezieht, und Antwort vom DM, wenn sich die
Datenanforderung auf historische Daten bezieht.
WinCC OA Redundanz
7
Voraussetzungen fr Hot Standby

Abgesetztes
UI
UI
System
API
DM
System
Ctrl
Ctrl
EV
EV
Peripherie
API
DM
Anmerkung:
Die Voraussetzungen fr eine vollstndige eindeutige Hot Standby Redundanz lauten:
Gewhrleistung einer getrennten und doppelten Datenhaltung.
Kommunikation von WinCC OA-Managern zwischen den beiden Systemen sicherstellen.
Eventuell redundante Ausfhrung der UIs (= Bedienstationen). Im Normalfall werden keine
redundanten UIs, sondern nur eine abgesetzte Arbeitsstation verwendet, auf der das
redundante System berwacht und bedient wird.
Sicherstellung, da die Peripherie nur vom aktiven System Befehle erhlt
Definition der genauen Vorschriften und Ablufe fr den Fall einer Kommunikationsunterbrechung zwischen den beiden redundanten Systemen.
WinCC OA Redundanz
8
Redundantes WinCC OA-System im Detail

Abgesetztes
UI
System
(aktiv)
UI
Ctrl
DM
Ctrl
System
(passiv)
DM
EV
4
EV
2
Redu
Split
Split
Redu
Peripherie
Anmerkung:
Funktionsweise der Redundanz in WinCC OA:
Redundanzfhigkeit ist eine Managereigenschaft, die alle WinCC OA-Manager von Haus aus
untersttzen.
Wird WinCC OA redundant betrieben, dann laufen auf 2 verschiedenen, aber untereinander
verbundenen Systemen, dieselben Manager (Art und Anzahl). Die Userinterface-Manager
werden in der Regel nicht redundant ausgefhrt, sondern als einfache abgesetzte
Bedienstationen betrieben.
Der jeweils aktive Event-Manager gleicht bei Wertnderungen sein lokales Prozessabbild ab und
schickt dann die Nachrichten, die zu den Wertnderungen gefhrt haben, an den passiven EventManager weiter. Dieser fhrt dann die gleichen nderungen bei seinem Prozessabbild durch. Die
beiden EV-Manager sind auch fr das dynamische Umschalten des Aktiv-Passiv-Zustandes
verantwortlich. Zur Steuerung der Aktiv-Passiv-Umschaltung stehen dem EV-Manager ein
spezieller Redundanz-Manager, ein spezielles Control-Script und spezielle interne Datenpunkte
zur Verfgung.
Die UI-Manager folgen automatisch dem jeweiligen aktiven System und stellen somit immer das
aktuelle Prozessabbild dar.
Redundanzstatus:
Der Redundanzstatus wird von den Redu-Managern bestimmt und vorgegeben, da diese alle
primren Informationen (Fehler-, Redundanz- und Alive-Stati) von sich und ihrem redundanten
Partner halten. Diese Stati werden zu einem Gesamtfehlerstatus pro System zusammengefat,
die dann miteinander verglichen werden. Das System mit dem besseren Gesamtfehlerstatus wird
automatisch zum aktiven System. Das Bestimmen der Fehlerstati wird mit Hilfe eines Ctrl-Scripts
(calculateState.ctl) durchgefhrt.
Fehlerstati:
Fr das Bestimmen des Gesamtfehlerstatus eines Systems flieen in die Berechnung die am
lokalen System angemeldeten Manager, deren jeweiliger Verbindungsstatus, Werte von etwaigen
ETM
professional
control GmbH
andere
(Trigger-)DPs,
die anzuwendenden Gewichtungen bei Verbindungsausfall oder erreichen
eines Trigger-Wertes, sowie der aktuelle Speicherverbrauch des Systems ein.
WinCC OA Redundanz
9
Redu-Umschaltung im Detail (1 - 3)
Abgesetztes
UI
System
DM
UI
Ctrl
calculateState.ctl
calculateState.ctl
EV
EV
Ctrl
_ReduManager
_ReduManager_2
System
DM
_ReduManager
_ReduManager_2
Redu
Redu
T
Peripherie
Anmerkung:
Das UI ist zwar zu beiden Systemen verbunden, akzeptiert aber nur vom aktiven System (hier
das linke) Nachrichten ber nderungen im Prozeabbild. Nachdem das UI zu beiden
Systemen verbunden ist, werden Befehle aus dem UI auch an beide Systeme versendet; dass
passive System (hier das rechte) verwirft aber solche Nachrichten.
Die Redu-Manager bauen untereinander eine direkte logische Verbindung auf um sich ber die
etwaig durchzufhrenden Aktiv/Passiv-Umschaltungen austauschen zu knnen.
1. Die calculateState- Skripts ermitteln jeweils gesondert fr ihr System die jeweiligen
Gesamtfehlerstati auf Grund der auf der vorigen Seite angefhrten Randbedingungen.
2. Die Endergebnisse werden auf Bltter des lokalen Datenpunktes _ReduManager (am
aktiven System) bzw. _ReduManager_2 (am passiven System) geschrieben
3. und mit Hilfe der fwdDP Anweisung in der config.redu auf den _ReduManager_2
bzw. den _ReduManager Datenpunkt des jeweils anderen Systems weitergeleitet.
WinCC OA Redundanz
10
Abgesetztes
UI
System
UI
Ctrl
Ctrl
DM
_ReduManager
_ReduManager_2
DM
EV
EV
4
System
_ReduManager
_ReduManager_2
4
Redu
Redu
T
Peripherie
Anmerkung:
4. Die Redu-Manager lesen von ihren internen Datenpunkten die Fehlerstati und ermitteln unter
Bercksichtigung von weiteren Randbedingungen (siehe vorige Seite) den aktuellen
Redundanzstatus.
5. Stellen die Redu-Manager fest, da die Redundanzlage zu ndern ist, dann tauschen sie
gegenseitig Informationen ber das anstehende Vorhaben aus.
WinCC OA Redundanz
11
Abgesetztes
UI
System
UI
Ctrl
Ctrl
DM
7
_ReduManager
_ReduManager_2
EV
EV
6
System
DM
7
_ReduManager
_ReduManager_2
6
Redu
Redu
T
Peripherie
Anmerkung:
6. Sind sich die Redu-Manager einig, da der Redundanzstatus zu ndern ist, dann wird den
(lokalen) EVs mitgeteilt dies zu tun und eine Umschaltung durchfhren.
7. Die Event-Manager setzen ihrerseits in den _ReduManager- Datenpunkten entsprechende
Werte. Diese sind im wesentlichen die Soll/Ist-Vorgaben fr die derzeitige/einzunehmende
Redundanzlage. Die nderung der Werte stt die Redu-Umschaltung an.
WinCC OA Redundanz
12

Abgesetztes
UI
10
System
UI
Ctrl
Ctrl
10
DM
System
EV
EV
_ReduManager
_ReduManager_2
DM
_ReduManager
_ReduManager_2
Redu
Redu
T
Peripherie
Anmerkung:
8. Die EVs versenden eine so genannte System-Message die jeweils sinngem besagt ich bin
jetzt passiv oder ich bin jetzt aktiv. Das Erhalten der Nachrichten wird von den EVs per
Handshake-Mechanismus besttigt,
9. danach die Soll/Ist-Vorgaben in den _ReduManager-DPs angepasst und
10. die Redundanzumschaltung durchgefhrt.
WinCC OA Redundanz
13
Redu-Umschaltung im Detail (11)

11
Abgesetztes
UI
System
UI
Ctrl
Ctrl
DM
System
DM
EV
EV
Redu
Redu
T
Peripherie
Anmerkung:
11. Das UI erhlt ebenfalls die System-Message vom EV und schaltet darauf selbstndig auf das jetzt neu aktive
gewordenen System um.
Dieser Umschaltvorgang geschieht fr den Bediener nicht sichtbar.
Durch aufrufen des Redundanzbersichts-Panels oder durch setzen der Manageroption
report dispatch kann die aktuelle Aktiv-/Passiv-Lage angezeigt, bzw. die Umschaltvorgnge belauscht werden.
Hinweis:
Ausfall der LAN-Verbindung
- Ohne Verbindung zueinander werden beide Systeme aktiv, weil Sie annehmen mssen, dass das jeweils andere
System ausgefallen ist.
-
Nach Wiederaufbau der Verbindung wird das System mit dem geringeren Fehlerstatus zum aktiven erklrt. Das
passive System wird neu gestartet und fhrt dabei ein DB-Recovery durch (siehe bungsteil 1).
Hinweis fr abgesetzten UIs bei Redundanz :

Bitte beachten Sie, da die aufzuschaltenden Panels im physikalischen Zugriff des UIs sein mssen!!
Man knnte zwar die Panels auf den redundanten Hosts platzieren. Fllt aber die
Verbindung schon zu einem der beiden Hosts aus, dann kann am abgesetzten Arbeitsplatz kein UI gestartet, bzw.
bei bereits laufenden UI kein Bildwechsel durchgefhrt werden, obwohl das Projekt selbst noch voll funktionsfhig
ist!
Muster-Config Datei eines abgesetzten UIs bei Redundanz
[general]
pvss_path = "<nstallationsPfad>"
proj_path = "<projektPfad>"
proj_path = "<lokalerProjektPfad>"
# hier liegt der Rest des Projekts

# hier liegen die Projekt-Panels
.
.
.
Managernummern fr Bedien- UIs bei Redundanz :

Bitte beachten Sie, dass fr UIs, die als Bedienstationen vorgesehen sind, fixe Managernummern zwischen 1 und 6
verwendet werden sollen. Lokal an einem der beiden redundanten Hosts laufende UIs werden per Default mit
Nummern ab 7 gestartet. Diese abgesetzten" Nummern werden automatisch und dynamisch vergeben. Die
Schwelle fr die abgesetzte" UI-Nummern lt sich mit dem Config-Eintrag lowestAutoManNumUI beeinflussen.
In der
Regel wird die
Konfiguration
ETM
professional
control
GmbH der Manager in der Praxis so sein, da in der Leitwarte eine bestimmte Anzahl von
(abgesetzten) UI-Managern auf bestimmten Arbeitspltzen fix aufgeschalten sind. Und auf weiteren Arbeitspltzen
(z.B.: Parametrierarbeitsplatz) werden je nach Bedarf weitere UIs nur nach Erfordernis aufgeschalten.
WinCC OA Redundanz
14
Redundante LAN-Verbindungen
Abgesetztes
UI
System
UI
Ctrl
DM
Ctrl
DM
EV
EV
System
Redu
Redu
T
Peripherie
Hinweis:
Um eine bessere Fehlertoleranz zu erreichen, knnen WinCC OA-Manager andere Manager, die
auf anderen Rechner laufen, ber redundante Netzwerkverbindungen kontaktieren.
Die beteiligten Rechner sind mit 2 Netzwerkkarten ausgestattet und so knnen zwei von einander
unabhngige Netzwerke aufgebaut werden.
ber beide Netzwerke werden die selben Messages verschickt. Das bedeutet, da jede
Message einen Zwilling hat. Trifft bei einem Manager eine Message ein, dann wird sofort die
Message-ID als eingegangen erklrt und somit alle anderen Messages mit dieser (und allen
kleineren) IDs fr ungltig erklrt.
Fllt ein Netzwerk aus, dann mssen keine Umschaltvorgnge angestoen werden, da ja ber
das zweite Netzwerk der gleiche Nachrichtenverkehr gesendet wird (siehe nchste Folie).
WinCC OA Redundanz
15
Ausfallverhalten bei redundanter LAN-Verbindung

Umschaltung nach
Fehlererkennung
Rechner
Normalbetrieb
A
NIC 1
NIC 2
Rechner
Rechner
NIC 1
LAN 1
1. Normalbetrieb
Echte Netzwerkredundanz
(WinCC OA)
NIC 2
NIC 1
NIC 2
aktiv
NIC 1
LAN 1
Switch 1
NIC 1
? B??
Rechner
NIC 2
NIC 1
LAN 1
NIC 2
Rechner
NIC 1
NIC 1
LAN 1
passiv
NIC 1
NIC 2
3. Betrieb mit
Fehler
Rechner
Rechner
NIC 1
NIC 2
defekt
LAN 1
Switch 1
LAN 2
defekt
aktiv
Switch 2
Ersatzbetrieb
NIC 2
Switch 1
LAN 2
Switch 2
Rechner
NIC 2
defekt
LAN 2
Rechner
Ersatzbetrieb
Switch 1
2. Fehlerfall
aktiv
Switch 2
Fehlererkennung
aktiv
LAN 2
Switch 2
Rechner
NIC 2
Switch 1
passiv
LAN 2
Rechner
Normalbetrieb
NIC 1
Rechner
Ersatzbetrieb
NIC 2
B
NIC 1
LAN 1
NIC 2
defekt
Switch 1
aktiv
Switch 2
LAN
Local Area Network (PC Netzwerk / Ethernet)
NIC
Network Interface Card (Netzwerkkarte)
2
aktiv
Siemens AG LAN
2010.
Alle
vorbehalten.
SwitchRechte
2
Hinweis:
Bei redundanten LAN-Verbindungen ist IP-Forwarding zu deaktivieren, sonst versucht das
Betriebssystem Messages, die ber die ausgefallene Netzwerkverbindung zu leiten wren, ber die
noch intakte Netzwerkverbindung zu schicken.
Das Suchen von Ersatzwegen kann aber das Betriebssystem fr lngere Zeit blockieren, so dass
der Betrieb von WinCC OA beeintrchtigt wird. Wurde ein Ersatzweg gefunden, dann werden vom
OS beide (!) Netzwerkverbindungen als aktiv und ok gewertet, was das Aufspren von
Netzwerkausfllen erheblich erschwert..
WinCC OA Redundanz
16
Prioritten bei System-Umschaltung
Prioritt 1: Rechnerausfall, keine Notumschaltung mglich

Komplettausfall eines Rechners oder Unterbrechung der LAN-Verbindung(en).
Hndische Umschaltung nicht mglich da ja zweites System nicht erreichbar.
Prioritt 2: Hndisch erzwungene Umschaltung (Aktiv erzwingen)
Erzwungene Umschaltung trotz anliegen einer Umschaltung mit einer untergeordneten
Prioritt. Wird durchgefhrt, sofern es hard- und softwaremig mglich ist.
Prioritt 3: Automatische Umschaltung aufgrund Fehlerstatus
Wird ausgelst durch Kommunikationsausflle zu den Datenerfassungen, oder Teilausfall
eines Rechners (Hardware oder Software).
Prioritt 4: Normalumschaltung durch den Benutzer (Vorzugslage)
Beide Systeme fehlerfrei bzw. gleicher Fehlerstatus
Anmerkung:
Die Redundanz arbeitet autark und ist nicht von Benutzereingaben und -reaktionen abhngig.
Trotzdem werden bestimmte Vorgaben vom Benutzer akzeptiert:
Bestimmen einer Vorzugslage (bei gleichem Fehlerstatus der beiden Systeme
kann der passive Rechner jederzeit aktiv gesetzt werden).
Unbedingte Umschaltung im Notfall durch Benutzervorgabe (eigener Rechner
wird aktiv)
Notumschaltung verlassen
ber die Vorzugslage kann vom Anwender vorgeben werden, welcher Host bei gleichen Fehlerstati
aktiv werden soll. Sind diese nicht gleich oder liegt ein bergeordneter Strfall vor, so wird diese
Eingabe nicht bercksichtigt.
Mit Hilfe der hndisch erzwungenen Umschaltung wird das gewnschte System sofort aktiv
gesetzt. Dies ist unabhngig vom Fehlerstatus. Damit kann eine dezidierte Aktivierung z.B. fr
Wartungszwecke durchgefhrt werden.
Wenn eine (oder mehrere) der angefhrten Umschaltkriterien erfllt sind, geht die Betriebsfhrung
auf den anderen Rechner ber.
Anmerkung:
Nach einer Umschaltung wird auch automatisch eine Generalabfrage der Treiber angestoen.
WinCC OA Redundanz
17
Telegrammlauflogik: Melderichtung (1-2)

Abgesetztes
UI
System
UI
Ctrl
Ctrl
4
EV
EV
DM
2
System
DM
Redu
Redu
T
1
Peripherie
Blockt alle Messages auer vom aktiven EV und fwdDP
Blockt alle Messages weil Systemstatus passiv
Anmerkung:
Obige Abbildung zeigt die Telegrammlauflogik bei einer Treibermeldung.
1) Das Prozessbild ndert sich und wird zu beiden Treibern geschickt.
2) Die beide Treiber leiten ihre Messages an ihre EVs weiter; der passive EV blockiert aber
den Eingang der Message von seinem Treiber.
WinCC OA Redundanz
18
Telegrammlauflogik: Melderichtung (3-4)

Abgesetztes
UI
System
UI
Ctrl
Ctrl
4
EV
DM
EV
4
System
DM
2
Redu
Redu
T
Peripherie

Anmerkung:
3) Der aktive EV hat das neue Prozessbild erhalten und sendet es an seinen DM und an alle
Manager, die sich fr den genderten Wert angemeldet haben (z.B. das abgesetzte UI),
sowie an den EV des passiven Systems.
4) Der passive EV leitet dann die Nachricht an seinen (passiven) DM weiter.
WinCC OA Redundanz
19
Telegrammlauflogik: Befehlsrichtung (1-2)

Abgesetztes
UI
System
UI
Ctrl
Ctrl
EV
EV
DM
DM
System
2
Redu
Redu
T
Peripherie

Anmerkung:
Obige Abbildung zeigt die Telegrammlauflogik bei einem Treiberbefehl.
Der EV des passiven Systems reagiert nicht auf Befehle seitens des UI-Managers, sondern
kommuniziert nur mit dem Event-Manager des aktiven Systems.
1) Das UI versendet einen Befehl an beide EVs.
2) Der passive EV blockiert alle Messages, die vom UI kommen.
WinCC OA Redundanz
20
Telegrammlauflogik: Befehlsrichtung (3-5)

Abgesetztes
UI
System
UI
Ctrl
Ctrl
4
EV
EV
DM
System
DM
2
Redu
Redu
T
4
Peripherie

Anmerkung:
3) Der aktive EV ndert sein Prozessbild und sendet diese Information an alle Manager, die
sich auf diese nderung angemeldet haben. Zumindest wird die Nachricht an den aktiven DM,
den aktiven Treiber und an den passiven EV gesendet.
4) Der aktive Treiber sendet die neuen Werte an den Prozess.
5) Der passive EV leitet die Nachricht mit der nderung an seinen (passiven) DM weiter.
WinCC OA Redundanz
21
Splitbetrieb
Redundante Server werden getrennt - Ein System bleibt im Fhrungsbetrieb

Zweiter Server kann fr Konfigurationstest verwendet werden
Automatische berfhrung eines beliebigen Systems zurck in Redundanz
SPS, DDC, Fernwirkkopf
Prozessbus
Engineering
(Fhrung)
Server 1
Hot-Standby
(Test)
Server 2
Betriebsleitung
Ethernet-LAN
Bedienstation 1
Bedienstation
2 Alle Rechte vorbehalten.
Siemens
AG 2010.
Anmerkung:
Um neue Konfigurationen fr das Projekt testen zu knnen, kann der redundante Betrieb temporr
aufgehoben und das Projekt im sogenannten Splitmode betrieben werden.
Dies ermglicht das gefahrenlose Testen von neuen Konfigurationen auf dem einem Server,
whrend ber den anderen der normale Anlagenbetrieb abgewickelt wird.
WinCC OA Redundanz
22
Splitbetrieb - Eigenschaften
Beide Server empfangen nach wie vor Daten von den Prozessanschlssen
(SPS, Feldbus,)
Fhrungssystem arbeitet normal weiter und versorgt die Bedienstationen
Zweiter Server kann nun vllig abgekoppelt zu Testzwecken verwendet werden
Lediglich vordefinierte Daten werden zwischen den beiden Servern
ausgetauscht
Jeder Bedienplatz kann wahlweise zum Fhrungs- oder Testsystem
verbunden werden
Automatische Rckfhrung zur Redundanz auf Basis eines beliebigen
Servers (Beibehalten der ursprnglichen Konfiguration oder
Etablierung der neuen Konfiguration)
Anmerkung:
Da das Testsystem abgekoppelt ist, kann auf ihm ein eigenstndiger Datenraum (= Datenpunkte
und deren Kopplung zum Prozess) entstehen. Die Kopplung zum Prozess ist am Testsystem so
ausgelegt, da zwar alle Daten empfangen werden, aber nur bestimmte (frei definierbare) Daten
gesendet oder empfangen werden.
WinCC OA Redundanz
23
Splitbetrieb im Detail
Abgesetztes
UI
System
(aktiv)
UI
Ctrl
DM
Ctrl
System
(split)
DM
EV
4
EV
2
Redu
Split
Split
Redu
T
Peripherie
Anmerkung:
Im Splitbetrieb laufen die beiden redundanten Systeme faktisch wie zwei einfache Systeme. Die
Redu-Manager sind somit von ihrer Aufgabe entbunden und laufen im Stand-By- Betrieb. Die
Aufgabe der Split-Manager ist jene Werte zu verwalten, die entweder nur auf Anforderung, oder
stndig zwischen den Systemen abgeglichen werden sollen.
WinCC OA Redundanz
bungsteil 1
Redundantes Projekt anlegen
24
WinCC OA Redundanz
25
Aufgabenstellung
Konfigurieren eines redundanten Systems unter Windows

Einfache Netzwerkverbindung
"Lokale" Userinterfaces
WinCC OA Redundanz
26
Neues Reduprojekt anlegen ...
Anmerkung:
Mit Hilfe der WinCC OA Projektverwaltung lsst sich leicht ein neues (redundantes) Projekt
anlegen.
WinCC OA Redundanz
27
... Name, Sprache(n) und Pfad ...
<projectName>
<projectDir>
Anmerkung:
Der Passwortschutz bezieht sich auf die Berechtigungen ein Projekt zu starten oder stoppen. Er
hat nichts mit den Berechtigungen des Betriebssystems, noch mit der von WinCC OA-Benutzern
zu tun.
WinCC OA Redundanz
28
... Redundanzeinstellungen ...
<computer_#1>
<computer_#2>
Hinweis:
Bei der Angabe von "Host 2" ist im Dialog mit dem Namen "Ordner suchen" nicht nur der
entsprechende Rechner, sondern (dem Namen des Dialogs entsprechend) wirklich auch ein
Ordner auf diesem Rechner auszusuchen. Wird das nicht gemacht, dann liefert dieser Dialog
keinen Rechnernamen zurck!
Anmerkung:
Fr eine redundante Netzwerkverbindung mssen pro Rechner zwei Netzwerkkarten installiert
sein. Die TCP-Verbindungen und die Zuordnung der IP-Adressen zu den Rechnernamen muss
unter Windows in der Datei "C:/Winnt/system32/drivers/etc/hosts" festgelegt werden.
Unter Linux erfolgt dies in der Datei "/etc/hosts".
Fr nichtredundante Netzwerkverbindungen sind diese Eintrge nicht unbedingt erforderlich,
schaden aber nicht und helfen dem Betriebssystem bei der Suche nach den jeweils anderen
Rechner.
WinCC OA Redundanz
29
... Eingaben besttigen ...
<projectName>
<projectDir>
<computer_#1>
Anmerkung:
Das Verzeichnis des soeben angelegten Projektes mu mit einer Netzwerkfreigabe versehen
werden, um es als Quellpfad beim Anlegen des zweiten Redundanzpartners auswhlen zu knnen!
Hinweis:
Alle fr den Redundanzbetrieb wesentlichen Eintrge in die Config-Datei des Projekts werden beim
Anlegen automatisch erstellt. Im Wesentlichen beschrnkt sich das auf die Angabe der beteiligten
Redu-Partner in der Form von
data = "<computer_#1>$<computer_#2>"
event = "<computer_#1>$<computer_#2>"
die noch um die Angabe von Portnummern und/oder um die symbolischen Namen der beiden
Redu-Partner bei redundanten Netzwerkverbindungen erweitert werden knnen. Fr Manager, die
sich normalerweise nur zu einem Event-Manager verbinden wrden (z.B.: Ctrl-Manager) kann in
den jeweiligen managerspezifischen Abschnitten der Config-Datei angegeben werden, ob sie sich
doch zu beiden EVs verbinden sollen:
connectToRedundantHosts = 1
(Default ist 0)
Hinweis:
Die nheren Einstellungen fr das Verhalten der Redundanz befinden sich in der Datei
config.redu . Eine solche Datei befindet sich unter <pvssPath>/config und weit wieder alle
fr den Redundanzbetrieb wesentlichen Eintrge bereits auf. Das Anpassen an projektspezifische
Gegebenheiten wird in einem eigenen bungsteil gezeigt.
WinCC OA Redundanz
30
... zweites Reduprojekt anlegen ...
WinCC OA Redundanz
31
... Quelle angeben ...
<projectSource>
<projectDir>
Hinweis:
Der Projektpfad kann beim zweiten Redundanzpartner nicht frei gewhlt werden, sondern wird wie
beim ersten Redundanzpartner angelegt. Das bedeutet somit, da am zweiten Redundanzpartner
die gleiche Partition (Laufwerkbuchstabe) wie am ersten Redundanzpartner vorhanden sein mu.
WinCC OA Redundanz
32
... Eingaben besttigen
<projectSource>
<projectDir>
Hinweis:
Das Quellprojekt darf zu diesem Zeitpunkt nicht gestartet sein, weil beim Anlegen des zweiten
Redundanzpartner eine komplette Kopie des ersten Redundanzpartners (inkl. RAIMA-Db) gemacht
wird!
Ist das zweite Projekt fertig angelegt, dann mu auch das Projektverzeichnis am zweiten
Redundanzpartner mit einer Netzwerkfreigabe versehen werden, damit in Hinkunft ein Abgleich
zwischen den beiden Projekten durchgefhrt werden kann.
WinCC OA Redundanz
33
Ersten Redu-Partner starten ...
<projectName>
Spezielle Manager
fr den Redu-Betrieb
Betreut auch das
Fehlerstati-Skript
Anmerkung:
Die fr den Redundanzbetrieb erforderlichen Manager (Redu und Split), sowie das FehlerstatiSkript calculateState.ctl werden automatisch in die Konsole eingefgt.
Hinweis:
Die Startreihenfolge der Manager darf zwischen DM-Manager und Ctrl-Manager nicht gendert
werden. Projektspezifische Manager sollten erst nach dem Ctrl-Manager in der Konsole angefhrt
werden. "Lokale" Uis erhalten automatisch Managernummern zugeteilt; die untere Schwelle ist per
Default 7. Abgesetzte UIs sollten mit fixen Managernummern zwischen 1 und 6 gestartet
werden (siehe Hinweis Seite 16)!
Hinweis:
berprfen Sie vor dem Start des Projekts die Uhrzeiten auf beiden Rechner und passen Sie sie
gegebenen Falls an!
WinCC OA Redundanz
34
... und zweiten Redu-Partner starten
Gleicher Projektname ...
<projectName>
... und gleiche

Manager wie beim
ersten
Redundanzpartner
8
Hinweis:
Es gelten die selben Hinweise wie beim Start fr den ersten Redundanzpartner!
WinCC OA Redundanz
35
Hochlauf des redundanten Systems

Partner
verfgbar
Nein
Ja
Abgleich
der History-DB
Abgleich
der Stati
DB-Recovery
Hochlauf
als aktives System
Event-Manager
Recovery
Synchrones Einklinken in
Proze als passiver Rechner
Hochlauf
calculateState.ctl
Hochlauf
Redu-Manager
Hochlauf und Init
der weiteren Manager
Laufender Betrieb
Anmerkung:
Beim Starten eines redundanten Projektes muss jeder Host aktiv vom Benutzer gestartet werden.
Der zuletzt gestartete Host gleicht dann automatisch seine Datenbank mit der des anderen
Hosts ab.
Aufgrund der aktuellen Fehlerstati der beiden Systeme wird dann im laufenden Betrieb darber
entschieden welcher der beiden mit Status aktiv bzw. passiv luft. Besitzen beide Hosts den
gleichen Fehlerstatus, luft der zuerst gestartete Host mit Status aktiv der andere mit
passiv.
Hinweis zu den Log-Eintrgen am ERSTEN Redundanzpartner:

Im folgenden wird ein kurzer berblick ber die Vorgnge beim Start des ersten
Redu-Partners an Hand von Auszgen der im Log-Viewer gezeigten Eintrge
gegeben.
<time>
aktueller Zeitstempel
... erster Redundanzpartner
... zweiter Redundanzpartner
...
<computer_#1>
<computer_#2>
1) Der DM startet und versucht seinen redundanten Partner zu finden

WinCC OA00data
(0),<time>, REDU, INFO, 3, Trying to connect to (SYS: 0 Data
-num 0 CONN: 2) @ <computer_#2> (may take some time if host is unreachable)
WinCC OA00data
(0),<time>, REDU, INFO, 0, , Could not connect to other
replica, starting active.
2) Archive starten und werden vom lokalen DM initialisiert

3) EV startet und verbindet sich zum lokalen DM, wird von diesem initialisiert und
luft als aktives System
WinCC OA Redundanz
36
Systembersicht anzeigen
<computer_#1>
<computer_#2>
Anmerkung:
Die Systembersicht zeigt die beiden Redundanz-Partner (computer_#1 und computer_#2);
das linke System ist zur Zeit das aktive (zu erkennen am grn hinterlegten EV-Symbol).
Im oberen Bereich werden die verbundenen UIs angezeigt. Im unteren Bereich werden die zu den
jeweiligen Redu-Partner lokal verbundenen Manager aufgelistet. Die Auflistung ist in die Rubriken
"Archive", "Treiber" sowie "CTRL und Div" unterteilt.
Die beiden Tabellen "Fehlerbewertung" listen die bei dem jeweiligen Redu-Partner anliegenden
Fehler auf. Die Auflistung unterteilt sich in die Angabe ber "Summe der anstehenden Fehler /
Summe aller parametrierten Gewichtungen" und in die tabelarisch angefhrten Fehler selbst. Je
besser also die Tabelle gefllt ist und/oder der Gesamtfehlerstatus sich dem mglichen
Maximalfehler annhert, umso schlechter steht es um das betreffende System. Die Einstellungen
fr die Gewichtungen der Fehler kann auch ber dieses Panel durchgefhrt werden.
Weiters werden in der Systembersicht noch verschiedene Schaltflchen zur Beeinflussung des
Aktiv/Passiv- Zustandes und fr das aufsplitten des redundanten Systems dargestellt.
WinCC OA Redundanz
bungsteil 2
Fehlergewichtungen einstellen
37
WinCC OA Redundanz
38
Aufgabenstellung
Gewichtung fr Verbindungsausfall des Treibers auf 40 erhhen

Neuen Datenpunkt vom Typ "bool" in die Fehlerbewertung
aufnehmen und mit einer Gewichtung von 100 versehen
WinCC OA Redundanz
39
Gewichtungsparameter aufrufen ...
<computer_#2>
<computer_#1>
rechts
klick
Anmerkung:
Die Einstellungen ber die Fehlergewichtungen knnen durch Rechts-Klick auf alle im Panel
dargestellten graphischen Objekte aufgerufen werden. Ausgenommen davon sind die
kreisfrmigen Symbole fr EV- und DM-Manager und die rechteckigen Symbole fr die UIManager.
WinCC OA Redundanz
40
... Gewichtung ndern ...
Anmerkung:
Ein Ausfall der Verbindung zum Treiber, der mit der Nummer 1 am System angemeldet ist, wird
jetzt mit der Gewichtung von 40 in die Berechnung des Gesamtfehlerstatus aufgenommen.
WinCC OA Redundanz
41
... und Fehlerbewertung prfen
<computer_#1>
<computer_#2>
Anmerkung:
Die Angabe "Summe der anstehenden Fehler / Summe aller parametrierten Gewichtungen" hat
sich von " 1/220 " auf " 1/240 " gendert.
WinCC OA Redundanz
42
Gewichtungsparameter aufrufen ...
<computer_#2>
<computer_#1>
rechts
klick
WinCC OA Redundanz
43
DP whlen
Anmerkung:
"ExampleDP_AlertHdl1" vom Typ "ExampleDP_Bit"
WinCC OA Redundanz
44
Werte einstellen
Anmerkung:
Wenn dieser DP den Wert TRUE einnimmt, dann wird dieser Umstand mit einer Gewichtung von
100 in der Berechnung des Gesamtfehlerstatus bercksichtigt.
WinCC OA Redundanz
45
... Fehlerbewertung prfen ...
<computer_#1>
<computer_#2>
Anmerkung:
sich von " 1/240 " auf " 1/340 " gendert.
WinCC OA Redundanz
46
... und DP setzen
<computer_#1>
<computer_#2>
Anmerkung:
sich von " 1/340 " auf " 101/340 " gendert und die Liste der anliegenden Fehler wurde
entsprechend erweitert.
Da der Wert mit Hilfe des Para-Moduls gesetzt wurde, hat sich der Wert sowohl am aktiven als
auch am passiven System gendert. Aus diesem Grund gibt es keinen Unterschied in den
Fehlerstati und somit auch keine Redu-Umschaltung.
WinCC OA Redundanz
47
bungsteil 3
Config.redu anpassen
Hinweise zur config.redu - Datei:

Die config.redu- Datei enthlt auf der einen Seite allgemeine Informationen ber die Redundanz, die fr alle Projekte
gltig sind (z.B.: Angaben ber DPs die das Stoppen von Managern steuern, wie lange soll bei einem Abgleich der
aktive EV buffern, etc. ).
Auf der anderen Seite beinhaltet diese Datei aber auch Informationen, die projektspezifischer Natur sind (z.B.: in einem
Projekt wird per OPC gekoppelt und daher sind die Verbindungen zum OPC-Treiber wichtig, in einem anderen Projekt
wird mit Profibus gekoppelt und daher sind dann diese Verbindungen wichtig).
In WinCC OA gibt es eine bereits vorgefertigte config.redu- Datei, die sich unter <pvssPath>/config befindet. In
ihr sind schon alle notwendigen allgemeinen Informationen enthalten, sowie Eintrge fr die mindesterforderlichen
projektspezifischen Einstellungen. Diese projektspezifischen Einstellungen sind (da ja nicht bei jedem Projekt
anwendbar) speziell markiert bzw. auskommentiert.
Wie der Name schon sagt, handelt es sich bei der config.redu- Datei eben um Config-Datei. So wie die "normale"
Config-Datei ist auch sie in Sektionen gegliedert. Es gibt also auch ein [general] - Sektion, sowie [event], [data],
etc. Allerdings wurde die config.redu- Datei so organisiert, dass sie in Abschnitte geteilt wurde, in denen immer
Informationen zu einem gewissen Thema zusammengefasst sind und in diesem es dann die oben angefhrten
Sektionen gibt. Es gibt also zum Beispiel einen Abschnitt der die Informationen fr den Redu-Manager zusammenfasst
und einen Abschnitt fr den OPC-Treiber. In beiden Abschnitten ist eine [event]- Sektion vorhanden.....
Hinweise zum Auslesen der Config-Dateien:
WinCC OA verwendet beim Ausfhren oder Laden von Dateien immer eine hierarchische Suche. Zuerst wird der lokale
Projektpfad, dann alternative Projektpfade und schlielich der Installationspfad durchsucht.
Die oben angefhrte config.redu- Datei befindet sich im Installtionsverzeichnis von WinCC OA und sollte nur die fr
alle Projekte gltigen Einstellungen beinhalten. Da man aber sicherlich auch projektspezifische Einstellungen in Bezug
auf die Redundanz ttigen mu, sollte sich im Projektverzeichnis ebenfalls eine config.redu- Datei befinden. In ihr
mssen nur die projektspezifischen Eintrge gemacht werden, die restlichen Eintrge werden aus der config.reduDatei der Installation ausgelesen.
Beim Starten des Projekts werden die beiden Dateien gemeinsam ausgewertet Eintrge die in der lokalen
config.redu- Datei vorhanden sind werden nicht durch Eintrge aus der config.redu- Datei im
Installtionsverzeichnis berschrieben. Und Eintrge die nicht lokal vorhanden sind, werden ergnzt.
Hinweise zu den Timeouts:
Die in der config.redu- Datei angefhrten Timeouts sind unter Umstnden an die Gegebenheiten das Projekt
anzupassen. Zu niedrig gesetzte Timeouts knnen den Stop des Projekts auslsen, die Verbindung zwischen Managern
unterbrechen oder den Verbindungsaufbau verhindern..
Hinweise zum Schlsselwort fwdDp:
In der config.redu- Datei wird unter dem Schlsselwort fwdDp Informationen verstanden, die von einem ReduPartner automatisch an den anderen Redu-Partner weitergeleitet werden, egal ob der Wert am aktiven oder am
passiven System gesetzt wurde. Dieses Verhalten dient dazu, nderungen, die nur auf einem System stattfinden (z.B.:
Fehlerstati) auch dem anderen System auf jeden Fall mitzuteilen und somit auf beiden Rechner die selben Daten zu
halten. Wichtig ist das vor allem fr Werte, die am passiven System gesetzt werden, da ja in der Regel die Werte des
passiven Systems verworfen werden.
Angegeben wird bei diesem Schlsselwort ein Datenpunktelement. Handelt es sich beim angegebenen DPE um einem
Knoten, dann werden alle Bltter unterhalb des Knotens weitergeleitet.
Hinweise zum Schlsselwort fwdDpType:
WinCC OA Redundanz
48
Aufgabenstellung
Einstellungen fr den Sim-Treiber 4
WinCC OA Redundanz
49
config.redu lokal kopieren ...
Auf welchem der beiden Redu-Partner das File zunchst kopiert wird ist egal. Nachdem es
entsprechend angepasst wurde, wird es dann auch auf den zweiten Redu-Partner kopiert.
WinCC OA Redundanz
50
und anpassen
Nachdem die config.redu- Datei lokal angepasst wurde, mssen die neu definierten
Datenpunkte falls noch nicht vorhanden angelegt werden (_Driver4 und _Driver4_2 vom Typ
_DriverCommon).
Danach ist die config.redu- Datei auf den zweiten Redu-Partner zu kopieren und die Systeme
neu zu starten, damit die config.redu- Datei neu eingelesen wird.
WinCC OA Redundanz
bungsteil 4
Splitbetrieb
51
WinCC OA Redundanz
52
Aufgabenstellung
Redundantes System in den Splitbetrieb berfhren

Erzeugen eines neuen DPs nur am Testsystem
Redundantes System wieder in den normalen Betrieb zurckfhren
WinCC OA Redundanz
53
Splitbetrieb whlen (1)
<computer_#1>
<computer_#2>
WinCC OA Redundanz
54
Splitbetrieb whlen (2)
<computer_#1>
<computer_#2>
Anmerkung:
Das vor der Teilung aktive System ist an den Prozess angebunden, dass andere System steht jetzt
fr nderungen zur Verfgung.
Durch Klick auf die Schaltflche Aktiver Treiber lsst sich die Prozesskopplung zwischen den
beiden Systemen hin- und herschalten.
Mit Hilfe des Split-Managers werden zwischen den beiden Systemen interne Systemzustnde
(Verbindungsstati, Speicherverbrauch, etc.) ausgetauscht. Sollen auch andere Daten ausgetauscht
werden, dann sind die vordefinierten DP-Gruppen SplitGet, SplitGet_2, SplitConnect und
SplitConnect_2 entsprechend anzupassen.
Solange der Splitbetrieb aufrecht ist (und somit der Split-Manager in Betrieb), luft der ReduManager nur im Stand-By- Mode.
Durch verschiedene Parametrierungen am Testsystem und am aktiven System entstehen
unterschiedliche Datenrume. Der berwiegende Teil der Datenpunkte werden beiden
Datenrumen angehren, aber einige nur dem aktiven System und andere nur dem Testsystem.
Ist in der Config-Datei der UIs nichts anderes eingestellt, dann haben sie Verbindung zu beiden
Systemen und sehen dann den gemeinsamen Datenraum beider Systeme.
Durch Angabe von data <hostname> und event <hostname> (entweder in der Config-Datei
oder als Startoption) lsst sich die Verbindung eines UIs gezielt auf das aktive System oder auf das
Testsystem lenken. Somit sieht es dann entweder nur den Datenraum am aktiven System, oder
nur am Testsystem.
WinCC OA Redundanz
55
Neues UI starten
Anmerkung:
An einem der Hosts wird ein neues UI gestartet, welches sich nur zum Testsystem verbinden soll.
Als Startoptionen sind dann einzustellen:
-extend data <hostnameTestsystem> -event <hostnameTestsystem>
WinCC OA Redundanz
56
... und neuen DP anlegen
Neuer DP nur am Split-System vorhanden!
Anmerkung:
Neuer DP split vom Typ ExampleDP_Float angelegt.
Da dieser DP mit einem PARA angelegt wurde, der nur eine Verbindung zum Testsystem hat,
wurde auch nur der Datenraum des Testsystems verndert.
WinCC OA Redundanz
57
Splitbetrieb verlassen
<computer_#2>
<computer_#1>
<computer_#1>
<computer_#2>
Anmerkung:
Durch Auswahl welcher der beiden Systeme weiterarbeiten soll, wird auch festgelegt, welcher
Datenraum in den Normalbetrieb bernommen wird. Die Tatsache, dass das andere System neu
gestartet wird bedeutet nichts anderes als das ein Abgleich stattfindet.
WinCC OA Redundanz
bungsteil 5
Redundanz-Umschaltungen
58
WinCC OA Redundanz
59
Aufgabenstellung
Ausfall der LAN-Verbindung

Bestimmen einer Vorzugslage
Hndisch erzwungene Umschaltung
WinCC OA Redundanz
60
Ausfall der LAN-Verbindungen
Beide Systeme sind aktiv!

Anmerkung:
Ausfall der LAN-Verbindungen:
Aus der Redundanzbersicht ist klar ersichtlich, dass ohne LAN-Verbindung beide Systeme aktiv
werden, weil sie annehmen mssen, dass das jeweils andere System ausgefallen ist.
Nach Wiederaufbau der Verbindung wird das System mit dem hheren Fehlerstatus bzw. das zuvor
passive System neu gestartet.
WinCC OA Redundanz
61
Bestimmen einer Vorzugslage
<computer_#1>
<computer_#2>
Anmerkung:
Fr den Fall gleicher Fehlerstati kann durch Klicken auf den Button Vorzugslage entweder das
linke oder das rechte System zum aktiven System gemacht werden.
WinCC OA Redundanz
62
Aktive Lage erzwingen
<computer_#1>
<computer_#2>
Anmerkung:
Fr den Fall ungleicher Fehlerstati kann durch Klicken auf den Button Aktiv erzwingen entweder
das linke oder das rechte System zum aktiven System gemacht werden.
WinCC OA Redundanz
Vielen Dank fr Ihre Aufmerksamkeit!

Marktstrae 3
A-7000 Eisenstadt
Telefon: +43 2682 741 0
Fax: +43 2682 741 52555
E-Mail: [email protected]
Sie mens AG 2010. Alle Rechte vorbehalten.
63

WinCC OA Redundante Systeme DE PDF

Hochgeladen von

Copyright:

Verfügbare Formate

WinCC OA Redundante Systeme DE PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

WinCC OA Redundante Systeme DE PDF

Hochgeladen von

Copyright:

Verfügbare Formate

WinCC OA Redundanz

Folien, Beispiele und Kommentare

Aufgaben von Redundanz in WinCC OA

Redundantes WinCC OA-System im Detail

18 Ausfallverhalten bei redundanten LAN-Verbindungen

Redundantes Projekt anlegen

ETM professional control GmbH

Folien, Beispiele und Kommentare

Schulungsmodul aufbauend auf:

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Proze A hat z.B. eine Verfgbarkeit von 0,90

Zwei parallele Prozesse A (redundantes System) haben dann

ETM professional control GmbH

Folien, Beispiele und Kommentare

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Aufgaben der Redundanz in WinCC OA

Ausfallsicherheit durch Hot-Standby

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

ETM professional control GmbH

Folien, Beispiele und Kommentare

Voraussetzungen fr Hot Standby

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Redundantes WinCC OA-System im Detail

Siemens AG 2010. Alle Rechte vorbehalten.

Folien, Beispiele und Kommentare

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Redu-Umschaltung im Detail (8 - 10)

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Redu-Umschaltung im Detail (11)

Siemens AG 2010. Alle Rechte vorbehalten.

Hinweis fr abgesetzten UIs bei Redundanz :

# hier liegt der Rest des Projekts

Managernummern fr Bedien- UIs bei Redundanz :

Folien, Beispiele und Kommentare

Siemens AG 2010. Alle Rechte vorbehalten.

ETM professional control GmbH

Folien, Beispiele und Kommentare

Ausfallverhalten bei redundanter LAN-Verbindung

Local Area Network (PC Netzwerk / Ethernet)

Network Interface Card (Netzwerkkarte)

ETM professional control GmbH