Fehlertoleranz und Eigensicherheit

Hinsichtlich Fehlertoleranz und Eigensicherheit wurden in WinCC OA laufend Verbesserungen vorgenommen. Auf dieser Seite soll hinsichtlich der Änderungen ein Überblick und Beschreibung gegeben werden. Weitere Informationen finden Sie schließlich in den weiterführenden Kapitel der Dokumentation.


Änderung	Beschreibung
Überlastregelung bei Treibern	Die Überlastregelung dient dazu, eine Instabilität des Gesamtsystems durch einen Treiber, der Daten schneller erzeugt, als sie im System verarbeitet werden können, zu verhindern. Normalerweise würde die Ausgangsqueue zum Event-Manager wachsen, bis kein Speicher mehr allokiert werden kann, wenn der Treiber die Daten schneller generiert, als sie vom Event-Manager abgeholt werden können. Um das zu verhindern, muss der Event-Manager die Nachrichten mit neuen Werten bestätigen, und die Ausgangsqueue wird beschränkt um die [driver] Config-Einstellung "maxOutputQueueSize". Dieser Parameter gibt die Anzahl der Wertänderungen in der Queue (pro DPE-Änderung ein Wert) an. Wenn die Anzahl der Wertänderungen diese Grenze überschreitet, kommen die Messages in eine zweite Queue (=Overload-Queue), in der Daten vom gleichen DPE überschrieben werden. D.h. die Queue kann nicht beliebig ansteigen. Wird die erste Queue geleert, so kommen die Daten der Overload-Queue wieder in die erste Queue und das Überschreiben wird beendet. Bei Analogwerten führt die Überschreibung zu Datenverlust. Ein Impuls bei Digitalwerten (z.B. 0-1 Änderungen) bleibt erhalten und wird in der Overflow-Queue nicht überschrieben. Eine gewisse Anzahl der Nachrichten kann der Treiber im voraus schicken ohne eine Bestätigung abzuwarten. Dieser Parameter kann durch den Config-Eintrag "commitCount" eingestellt werden. D.h. wenn commitCount 10 ist, kann der Treiber 10 Messages schicken und wartet dann auf die Bestätigung der ersten Message. Weiterführende Kapitel: Konfigurationsdatei - Treiber
Message-Queue-Container im Event-Manager (Empfangsrichtung)	Mit den Config-Einträgen "maxInputMsgCount" und "msgQueueLimitTimeout" in der [event]-Sektion kann die Anzahl der Messages in der Queue und die Zeit des Timeouts (Zeit während der das Limit überschritten werden darf) eingestellt werden. Nach Ablauf des Timeouts und weiterhin überschrittener Anzahl an Messages tritt eine Notfallbehandlung in Kraft. Die Notfallbehandlung sieht so aus, dass die Verbindung zum spezifischen Manager geschlossen wird, sofern es sich nicht um Data- oder Event-Manager handelt (der Event-Manager beendet die Verbindung, was bewirken sollte, dass der Manager sich selbst beendet). Weiterführende Kapitel: Konfigurationsdatei - Event-Manager
BCM Output Queue in allen Managern (Senderichtung)	Mit den Config-Einträgen "maxBcmBufferSize" und "bcmBufferLimitTimeout" in der [general]-Sektion kann die Größe der BCM Output Queue und die Zeit des Timeouts (Zeit während der das Limit überschritten werden darf) eingestellt werden. Nach Ablauf des Timeouts und weiterhin überschrittener Größe der Queue tritt eine Notfallbehandlung in Kraft. Die Notfallbehandlung sieht so aus, dass die Verbindung zum spezifischen Manager geschlossen wird, sofern es sich nicht um Data- oder Event-Manager handelt (der Event-Manager beendet die Verbindung, was bewirken sollte, dass der Manager sich selbst beendet). Weiterführende Kapitel: Konfigurationsdatei - Allgemeine Einstellungen
Zeitbeschränkung für Event-Manager Queries	Um ein vollständiges Blockieren des Event-Managers bei der Bearbeitung von Queries zu verhindern, kann die Bearbeitungszeit der Queries beim Event-Manager mit dem Config-Eintrag "maxParseTime" eingestellt werden. Weiterführende Kapitel: Konfigurationsdatei - Event-Manager
Beschränkung der Abfragegröße mit Werten beim Event-Manager	Historische Abfragen, die mehr als die maximal eingestellte Anzahl an Elementen (= Anzahl Zeilen x Anzahl Spalten) abfragen, werden sobald als möglich abgebrochen und eine Fehlermeldung wird zurückgeliefert (die Einstellung der maximal abzufragenden Elemente erfolgt durch den Config-Eintrag "maxValueRequestCount" für dpQuery() und "maxValueConnectCount" für dpQueryConnect() in der [event]-Sektion). Weiterführende Kapitel: Konfigurationsdatei - Event-Manager
Beschränkung der Abfragegröße mit Alarmen beim Event-Manager	Historische Abfragen, die mehr als die maximal eingestellte Anzahl an Elementen (= Anzahl Zeilen x Anzahl Spalten) abfragen, werden sobald als möglich abgebrochen und eine Fehlermeldung wird zurückgeliefert (die Einstellung der maximal abzufragenden Elemente erfolgt durch den Config-Eintrag "maxAlertRequestCount" für dpQuery() und "maxAlertConnectCount" für dpQueryConnect() in der [event]-Sektion). Weiterführende Kapitel: Konfigurationsdatei - Event-Manager
Beschränkung der Abfragegröße mit Werten beim Data-Manager	Historische Abfragen, die mehr als die maximal eingestellte Anzahl an Elementen (= Anzahl Zeilen x Anzahl Spalten) abfragen, werden sobald als möglich abgebrochen und eine Fehlermeldung wird zurückgeliefert (die Einstellung der maximal abzufragenden Elemente erfolgt durch den Config-Eintrag "maxValueRequestCount" in der [data]-Sektion). Das gilt für Abfragen mit dpGetPeriod() und dpQuery(). Die Beschränkung kann auch durch Manipulation am internen Datenpunkt "_Config.MaxValueRequestCount" gesetzt werden (Defaultwert wenn DPE auf -1 steht = 1000000 Elemente, 0 = keine Beschränkung). Weiterführende Kapitel: Konfigurationsdatei - Data-Manager
Beschränkung der Abfragegröße mit Alarmen beim Data-Manager	Historische Abfragen, die mehr als die maximal eingestellte Anzahl an Elementen (= Anzahl Zeilen x Anzahl Spalten) abfragen, werden sobald als möglich abgebrochen und eine Fehlermeldung wird zurückgeliefert (die Einstellung der maximal abzufragenden Elemente erfolgt durch den Config-Eintrag "maxAlertRequestCount" in der [data]-Sektion). Das gilt für Abfragen mit alertGetPeriod(), dpQuery() und OLE DB. Die Beschränkung kann auch durch Änderungen am internen Datenpunkt "_Config.MaxAlertRequestCount" gesetzt werden (Defaultwert wenn DPE auf -1 steht = 1000000 Elemente, 0 = keine Beschränkung). Weiterführende Kapitel: Konfigurationsdatei - Data-Manager
Beschränkung der Abfragegröße für Werte aus der History DB	Historische Abfragen, die mehr als die maximal eingestellte Anzahl an Zeilen in 1 oder mehrere Archive der History DB abfragen, werden sobald als möglich abgebrochen und eine Fehlermeldung wird zurückgeliefert (die Einstellung der maximal abzufragenden Zeilen und das Timeout erfolgt durch die Config-Einträge "queryTimeout" und "queryMaxValues" in der [valarch]-Sektion). Das gilt für Abfragen mit dpGetPeriod(), dpQuery() und OLE DB. Weiterführende Kapitel: Konfigurationsdatei - Archive-Manager
Berechnung von statistischen Funktionen	Wenn (z.B. aufgrund von Überlast) der Event-Manager nicht dazukommt, die statistischen Funktionen rechtzeitig zu berechnen, so werden ab einem Verzug von n Intervallen (ohne Rücksicht auf eine eventuelle Verzögerungszeit!) sämtliche älteren Perioden im Puffer mit einer Meldung verworfen und das n-letzte Intervall berechnet. n kann mit dem Config-Eintrag "statFctMaxIntervalsInPast" (Default 3) eingestellt werden. Auf 3 Intervalle wird gewartet (Intervall ab Intervallende bis zur aktuellen Zeit). Ebenso gilt das für Funktionen mit verzögerter Berechnung; diese müssen jedenfalls innerhalb von 3 Perioden durchgeführt werden, sonst wird die hinfällige Periode verworfen. Weiterführende Kapitel: Konfigurationsdatei - Allgemeine Einstellungen bzw. Statistische Funktionen
Telegrammverbindungsüberprüfung	Jede Message eines WinCC OA Managers enthält einen eigenen Header, der die Message identifiziert. Verbindunsgversuche von nicht WinCC OA Managern (z.B. Portscans, Telnet) werden sofort abgebrochen.
Errorhandler	Vielfache Wiederholungen der selben Fehlermeldung werden verworfen. Das führt zu einer Verringerung eines unnötigen Schwall von Fehlermeldungen (Log Viewer).