Diese Seite verwendet Cookies. Mit der weiteren Nutzung der Seite erklären Sie sich damit einverstanden. Ausblenden Mehr Informationen

PLC server redundancy

Redundanz

Die Redundanz soll beim Defekt von Komponenten einen Ausfall und Folgeschäden verhindern

Grundlagen für Redundanz

Ideal ist es wenn alle Komponenten redundant ausgelegt sind. Das schließt den Leitrechner samt Bedienung ein, ebenso die Maschine selbst. Aus Kostengründen sind Maschinen, Leitrechner und Bedienmannschaften nur in wenigen Spezialfällen redundant. Ideal sind zwei Anlagen, aus Sicherheitsgründen an unterschiedlichen Standorten.

Werden die Kosten betrachtet dann sind sehr umfangreiche Redundanzen wirtschaftlich nur selten tragbar. Es gibt nur wenige Ausnahmen für weitreichende Redundanz wie kerntechnische Anlagen oder Bahnsignale.

Sinnvoll ist es die Komponenten redundant auszulegen, die die häufigsten Ausfälle haben, oder die die höchsten Schäden verursachen. Dazu zählen Netzwerkkabel und Switches, ebenso Netzwerkkarten im PC und an der Steuerung. Der Grund der Ausfälle liegt in der großen Ausdehnung der Netze. Vielfältige Störungen bedrohen die Komponenten durch Bauarbeiten, Überspannungen, alternde Kontakte, Tiere die Kabel beschädigen.
Funknetze können nicht redundant ausgelegt werden. Die unterbrochene "Luftstrecke" kann nicht durch Funk ersetzt werden. Mehrere Sender und Empfänger helfen selten, die möglichen Funkkanäle lassen das nicht zu. Maximal kann eine Störungshäufigkeit ein wenig herabgesetzt werden.
Die Stromversorgungen können auch redundant sein. Diese Dinge werden hier aber nicht weiter betrachtet.
Mehrfach vorhandene Leitrechner sind auch nicht Gegenstand dieser Betrachtung, ebensowenig mehrfach vorhandene Steuerungen oder Anlagen zum Zwecke der Redundanz. Hochverfügbare Steuerungen mit mehreren Netzwerkkarten sind aber Teil des Konzeptes.

Grenzen der Redundanz

Eigentlich müssen bei guter Redundanz die Informationen gleichzeitig von mehr als zwei Verbindungen beschafft und verglichen werden. Genutzt werden die beiden plausibelsten Daten. Solch eine Logik belastet die Steuerungen stark - so stark, das das so an vielen Anlagen nicht anwendbar ist. Grund: Steuerungen sind auf die Steuerungsaufgabe optimiert, nicht auf die Kommunikation. Zusätzlich besteht das Problem inkonsistenter Daten: Das Datenlesen arbeitet technisch bedingt mit mehreren kleinen Blöcken. Ändern sich die Daten zwischen den Anfragen, vor Allem wenn das über mehrere Verbindungen erfolgt - so ist eine Konsistenzprüfung nicht möglich. In laufenden Anlagen ändern sich die Daten oft.
Sollen systemimanente Fehler (Konstruktionsfehler oder Designfehler) abgefangen werden so müssen unterschiedliche Technologien eingesetzt werden. Beispiel sind Steuerungen unterschiedlicher Hersteller an einer Maschine. Ein anderes Beispiel sind Rechner unterschiedlicher Architekturen wie ein PC mit ARM CPU und Linux, der Andere mit Intel CPU und Windows. Das wird hier auch nicht weiter betrachtet.

Auslegung der Netzwerkredundanz

Das Netzwerk fällt am häufigsten aus. Das Netz redundant auslegen steigert die Anlagenverfügbarkeit deutlich.
Der Leitrechner hat mindestens zwei Netzwerkkarten, ebenso die Steuerung.
Es sind zwei Netze verlegt.
Beide Netze nutzen unterschiedliche IP Adressbereiche. Eine Station lässt mit Standardbetriebssystemen das Nutzen der gleichen Netzadresse an mehreren Netzwerkkarten nur mit hohem Aufwand zu. Überschneidende Subnetze schalten bei Unterbrechungen standardmäßig nicht auf den anderen Strang um.
Die Netzwerkkabel sind nicht im gleichen Kabelkanal verlegt. Die Switches der beiden Netze sind in unterschiedlichen Schaltschränken aufgebaut. Die Kabel und Verteiler sollen ausreichend gegeneinander abgeschirmt sein, ein Brandschutz der die Netze trennt ist eine gute Voraussetzung.

Regel: Zentrale Fehlerpunkte "Single Point Of Failure" sollen verhindert werden. Ausnahmen sind der Startpunkt (das SCADA System) und der Endpunkt (die Maschine).

Arbeitsweise Redundanz bei Tani Produkten

Im OPC Server und PLC Engine Collect wird eine Redundanzverbindung angelegt. Diese besteht intern aus zwei oder mehr Verbindungen. Jede einzelne Verbindung ist so konfiguriert, das sie nur über die dazu konfigurierte Netzwerkkarte arbeitet. Die Steuerung hat auch mehrere Netzwerkkarten. Jede der Redundanz Einzelverbindung hat eine IP Zieladresse. Das stellt sicher, das wirklich jede der SPS Zieladressen über die dafür vorgesehene Netzwerkkarte arbeitet.
Wahlweise kann nur die Netzwerkverbindung überwacht werden. Es kann zusätzlich auch der Status der einzelnen Steuerungen getestet werden; Sie muss in RUN stehen. Es kann aber auch ein Watchdogelement in den Steuerungen angelegt werden. Diese Watchdogelemente werden auf Änderung getestet: Ändert sich der Wert nicht mindestens einmal in der Überwachungszeit so wird umgeschaltet.

Konfiguration von Verbindungsredundanz im OPC Server oder der PLC Engine Collect

Die Verbindung für Redundanz erhält den Haken bei Redundanz gesetzt. Dadurch erscheint weiteres Feld zum Eingabe weiterer Steuerungs IP Adressen.

Arbeitsweise im OPC Server

Ist eine Verbindung redundant ausgelegt so muss die OPC Applikation nicht angepasst werden.

Beim Start der Datenaquise über die Redundanzverbindung werden beide Verbindungen zur Steuerung aufgebaut und überwacht. Die Daten werden nur auf einer Verbindung angefragt um die Steuerung nicht zu überlasten. Diese Verbindung ist nun Master. Über die Slave Verbindungen wird nur ein Status gelesen.
Reagiert die Masterverbindung nicht weil sie zusammenbricht oder die Daten nicht in der geforderten Zeit geliefert werden, so werden alle Items auf der Slave Verbindung scharfgeschaltet. Kommen nun die Daten so wird diese Verbindung nun Master. Die vorherige Verbindung wird nun Slave, alle Items werden im Slave inaktiviert. Keins der angemeldeten Items bringt auf der OPC Schnittstelle eine Quality Fehlermeldung. Im Diagnoselogger wird das Umschalten protokolliert.
Nur wenn wenn alle Verbindungen gestört sind, melden die Elemente Quality BAD. Der OPC Client erfährt vom Umschalten über das Spezielle Item "System.Topics.<sps Verbindung>.Redundancy", der Wert wechselt.
Fällt die gerade nicht benutzte Slave Verbindung aus so wird das in den Diagnoselogger eingetragen. Zusätzlich wird die Variable "System.Topics.<sps Verbindung>.Status<x>" auf Fehler gesetzt.
Besteht Dreierredundanz so werden beim Fehler der Masterverbindung bei beiden Slave Verbindungen einige Items scharfgeschaltet. Bei der Verbindung die zuerst Daten liefert werden die restlichen Items angemeldet. Die langsamere Verbindung geht wieder in den Slave Status. Ist auch eine der beiden Slave Verbindungen gestört so wird direkt auf die stabile Verbindung geschaltet.
Über das Systemelement "Redundancy" wird gemeldet welche Verbindung gerade Master ist, 1 ist die erste Teilverbindung. Das Systemelement "Status1" und "Status2" (gegebenenfalls auch "Status3" oder Weitere) zeigt den Status der jeweiligen Redundanz Teilverbindung an. Sind alle Werte Null so sind alle Verbindungen in Ordnung.
Mit Schreiben auf das Systemelement "Redundancy" kann der Master aktiv umgeschaltet werden. Das kann zu Wartungszwecken oder zum Test dienen.
Der Jitter beim Unschalten der Redundanzerkennung setzt sich zusammen aus

Überwachungstimeout - das Applikationstimeout. Das soll etwa die dreifache Reaktionszeit der Steuerung betragen, mindestens aber eine Sekunde.
Wiederverbindungstimeout. Dieser Wert reagiert bei kompletten Verbindungsunterbrechungen, oft als Folge des Überwachungstimeouts.

Der kleinere der beiden Werte wird genutzt.
Meldet die Verbindung selbstständig einen Fehler z.B. weil das Netzwerkkabel gezogen wird und das Betriebssystem diese Information weitergibt so wird sofort umgeschaltet.
Im Scada System oder in der Steuerung sollte der Verbindungszustand für Warnmeldungen genutzt werden. So wird das Wartungspersonal auch dann auf einen Fehler hingewiesen wenn alles scheinbar arbeitet, die Reserveverbindung aber nicht nutzbar ist.

Arbeitsweise in der PLC Engine

Die PLC Engine Collect nutzt das Verbindungs und Itemsystem das auch vom OPC Server genutzt wird. Die Redundanzfunktionen werden in der gleichen Weise bereitgestellt. Die Status Variablen sollen in den Logiktabellen so verarbeitet werden, das eine ausfallende Verbindung zu einer Information des Anlagen Bedienpersonals führt. Das kann mit dem Schreiben des Zustandes in eine der Steuerungen oder Datenbanken geschehen.

PLC Engine Collect - OPC Redundanz