Puffern bei Verbindungsausfall
Nach Verbindungsausfall versucht der OPC UA Client die OPC UA Session und die entsprechenden Subscriptions wieder zu verwenden. Dadurch können in Subscriptions gepufferte Daten verwendet und der Verlust von Daten für kurze Verbindungsausfälle vermieden werden.
Gepufferte Daten können auch nach dem Neustart des OPC UA Clients verwendet werden. Siehe Puffern bei Neustart für nähere Informationen.
Die Timeouts für Subscriptions und Session sind unterschiedlich lang. Der Verlust von Daten kann vermieden werden, solange der Verbindungsausfall kürzer als diese Timeouts ist und die Puffergröße für die Monitored Items nicht überschritten wird.
Session-Timeout
Der Client kann ein Session-Timeout anfordern, das maximale Timeout hängt allerdings vom für den Server konfigurierten Limit ab. Per Default erlaubt der WinCC OA OPC UA Server beispielsweise ein maximales Session-Timeout von 60 Sekunden (siehe maxSessionTimeout), der WinCC OA Client fordert aber ein Timeout von 20 Minuten an (siehe sessionTimeout). Kommunizieren WinCC OA OPC UA Client und Sever mit Defaulteinstellungen ist das Session-Timeout 60 Sekunden.
Subscription-Timeout
Das Timeout einer Subscription ist abhängig vom Publishing-Intervall und dem Lifetime-Count (per _OPCUASubscription.Config.RequestedLifetimeCount konfigurierbar). Per Default ist der Lifetime-Count 100 und das angefragte Publishing-Interval ist 500ms. Das ergibt eine Lebenszeit von 50 Sekunden (sofern der Server das Publishing-Intervall nicht limitiert).
Das bedeutet dass die Lebenszeit einer Subscription bei Defaulteinstellung 10 Sekunden vor der Session endet und die Daten für 50 Sekunden gepuffert werden (falls die Puffergröße der Monitored Items groß genug ist).
Sollen gepufferte Daten verwendet werden, ist es bei Konfiguration der Subscription wichtig, den Zeitstempel entweder von der Quelle oder vom Server zu verwenden. Wird "none" ausgewählt bekommt man falsche Zeitstempel wenn die Verbindung wiederhergestellt wird.
Monitored Items
Die maximale Puffergröße der Monitored Items im WinCC OA Server ist per Default 100. Dieser Wert kann konfiguriert werden (siehe uaMaxDataQueueSize).
Beispiel
Das folgende Beispiel zeigt wie die entsprechenden Parameter gesetzt werden können und welche Abhängigkeiten beachtet bzw. berechnet werden müssen.
Szenario
- Ein Server liefert für 100 Items Daten.
- Alle 100ms (=Abfrageintervall) werden die Daten eines jeden Items geändert.
- Der Client fragt diese Daten alle 500ms (=Publishing-Intervall) ab.
- Die Daten sollen im Falle eines Verbindungsverlustes für 10 Minuten gepuffert werden.
Konfiguration
| Server | Client | |||
| uaMaxDataQueueSize [Wertänderungen] | maxSessionTimeout [ms] | sessionTimeout [ms] | Queue Size [Wertänderungen] | Lifetime Count [Versuche] |
| 6.000 | 600.000 | 600.000 | 6.000 | 1.200 |
uaMaxDataQueueSize
Die maximale Puffergröße pro Monitored Item. Die hier definierte Anzahl an Wertänderungen kann bis zum nächsten Publish gespeichert werden.
Die Werte sollen über 10 Minuten gepuffert werden, daher muss die erforderliche Einstellung für den Config Eintrag wie folgt berechnet werden:
10 (Anzahl an Wertänderungen pro Sekunde) * 600 (gepufferte Zeit in Sekunden) = 6000
In diesem Fall werden für 100 Items 600.000 Werteänderungen gepuffert.
maxSessionTimeout
Die Session-Timeout (Server) für 10 Minuten in Millisekunden beträgt 600.000.
sessionTimeout
Die Session-Timeout (Client) für 10 Minuten in Millisekunden beträgt 600.000.
Queue Size
Die Größe der Request-Warteschlange für den OPC UA Server (siehe maxRequestQueueSize).
LifetimeCount
Anzahl an Wiederholungen bis eine Subscription gelöscht wird, wenn keine Werte gelesen werden können. Der Client versucht 600 Sekunden lang alle 500ms Werte zu lesen, daher ergibt sich ein LifetimeCount von 1.200.
Grenzen
Bei Verbindungswiederaufbau müssen alle gepufferten Daten das WinCC OA System durchlaufen. Wir empfehlen daher die folgenden Grenzen nicht zu überschreiten, da es ansonsten zu einer hohen Belastung von CPU und Speicher kommen kann. Die tatsächlichen Grenzen hängen aber auch von der erforderlichen Datenverarbeitung (Archivierung, Alarming, usw.) ab, daher können die hier angegebenen Zahlen nicht als absolute Grenzwerte angesehen werden.
- Gesamtzahl an gepufferten Daten < 1.000.000
- sessionTimeout < 20.000 Sekunden
- Queue Size < 10.000
Sollen gepufferte Daten bei Verbindungsverlust zusätzlich als "ungültig" gekennzeichnet werden, darf nur setInvalidForConnLoss = 2 verwendet werden. Andernfalls könnte es zu ungültigen Quellzeitstempel kommen.
Als Referenzhardware für die Ermittlung der Wertgrenzen oberhalb wurde ein Core i7 der 8ten Generation mit 16 GB DDR4 RAM verwendet.
