Step 7 Langsame Lesezeiten OPCUA-Server S7-1500

[canogretic]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi zusammen,

wir haben bei uns mit dem Siemens OPCUA Server der CPU zyklische lange Lesezeiten beim Lesen von Daten vom Server. Es werden registered Reads verwendet und die Probleme treten auch bei minimalster Datenlast auf wenn nur ein Datenpunkt gelesen wird.

Zwischen Client und Server haben wir einen Siemens Scalance XC206 Switch verbaut. Netzwerkseitig haben wir das ein oder andere (z.B. Netzwerkleitung) schon getauscht und konnten die Probleme nicht abstellen.
Da weitere Steuerungen im Anlagennetzwerk dieses verhalten ebenfalls aufweisen würde ich persönlich den Switch als Fehlerquelle ausschließen.

Auffällig ist, dass von dem Windows System ein ping zum OPC UA Server zwar möglich ist, dieser aber Aussetzer hat wenn die langsamen Reads auftreten.
Ebenfalls auffällig ist, dass ich von dem Webinterface des Switches die Siemens CPU nicht pingen kann, dieses bei anderen SPSen im Netzwerk aber funktioniert.
Aufgrund dessen das ich der OPC Client Entwickler bei uns bin, stecke ich in der Siemens Welt nicht so tief drin und denke eher das irgendeine Einstellung im TIA dafür sorgt, dass dieses nicht möglich ist.

Bei der Steuerung handelt es sich um eine S7-1500 IPC mit Soft-SPS und TIA Portal Version 16 und Software Revision V21.08.03. Interessant könnte noch die Einstellung der Kommunikationslast sein. Diese steht aktuell bei 25%.

Ich weiß die Infos sind etwas dünn, aber ich hoffe ich finde hier den ein oder anderen Ansatz mit dem wir weiter arbeiten können.

Viele Grüße

Alex

 

[Larry Laffer]

Zunächst :
Was heißt denn "zyklische lange Lesezeiten" in Werten - also z.B. Sekunden ?
Was ist sonst noch in dem Netzwerk los ? Und was hängt da noch so alles dran wenn du schreibst "Da weitere Steuerungen im Anlagennetzwerk dieses verhalten ebenfalls aufweisen" ?
Du mußt da schon etwas konkreter werden ...

 

[canogretic]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für deine Nachricht.
Zyklisch heißt in dem Fall, dass ich ca. alle 5 sek den Wert aus dem Server Lese (~2ms) und alle 12 Takte also jede Minute (nicht konstant immer zur gleichen Zeit) braucht das Lesen länger (~ 6,5 sek).

Insgesamt sind 14 Steuerungen innerhalb der Anlage verbaut vom selben Typ mit jeweils einem eigenen Switch. Die Switche sind über eine Glasfaserleitung miteinander verbunden. Die Netzwerkauslastung liegt ungefähr um 10%. Dieses wird zumindest auf einem Analyzer von Indu-Sol angezeigt, welcher zwischen SPS und Switch hängt.
Das Verhalten tritt ebenfalls bei stehender Anlage auf, also wenn nichts produziert wird und alles steht. Da sollte die Netzwerklast nicht so hoch sein, wodurch ich etwas die Konfiguration in Verdacht habe.

 

[PN/DP]

Das Verhalten tritt ebenfalls bei stehender Anlage auf, also wenn nichts produziert wird und alles steht. Da sollte die Netzwerklast nicht so hoch sein

Hmm, wie kommst du da drauf? Das sollte der Kommunikation doch egal sein?

 

[canogretic]

Das ist eine reine Vermutung und hat keinen wirklich technischen Aussagekraft. Da bei Betrieb aber nur 10% (Anzeige Web Oberfläche des Indu-Sol Inspektors) Auslastung herrscht vermute ich eher nicht die Netzwerkauslastung.
Bin aber durchaus dankbar für jeden Tipp um das Problem einfangen zu können / bzw. die Netzwerklast anderweitig messen zu können.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zyklisch heißt in dem Fall, dass ich ca. alle 5 sek den Wert aus dem Server Lese (~2ms) und alle 12 Takte also jede Minute (nicht konstant immer zur gleichen Zeit) braucht das Lesen länger (~ 6,5 sek).

erklär mir bitte mal das mit den 2 ms ... wie soll ich das verstehen ?

Was passiert denn sonst noch in deinem Netzwerk ? Nur die OPC-Kommunikation ?

 

[volker]

Benutzt du für den Server diverse Sicherheitseinstellungen? Zetifikate, Verschlüsselung?
Ich hab das vor Jahren mal mit einer 1516 getestet. Da hat die Anmelduung (connect) am Server über 4 Sekunden gedauert. Das lesen selber geht dann schnell. (wenn man die Verbindung anschliessend nicht trennt ist die Zeit zum lesen immer sehr kurz im2-stelligen ms-Bereich (soweit ich mich erinner))
Bei Authentisierung mit Benutzer Passwort hielt sich die Anmeldezeit in Grenzen. War glaube ich unter 1 Sek.

Kann es also evtl sein, das du schon den nächsten request auslöst bevor die vorigen bendet waren?
Ich weiss jetzt nicht wie weit das stapelbar ist.

 

[canogretic]

erklär mir bitte mal das mit den 2 ms ... wie soll ich das verstehen ?

Was passiert denn sonst noch in deinem Netzwerk ? Nur die OPC-Kommunikation ?

Die 2ms sind clientseitig (Stoppwatch C# Konsolenanwendung ) gemessen worden. Die Messung erfolgte nur während der Datenabfrage und ist exkl. Verbindungsaufbau und Variablenregistrierung. Als Framework wird hier der OPC UA Client von Träger GmbH verwendet. Mit UAExpert besteht das Problem auch. Daher gehe ich auch hier davon aus das die Zeitaufnahme tendenziell eher passend ist.

Im Netzwerk sind ein paar ARP Requests welche auffällig sind, da sich die Teilnehmer eigentlich nicht ändern was MAC Adresse und IP Adresse betrifft.

 

[canogretic]

Zuviel Werbung?
-> Hier kostenlos registrieren

Benutzt du für den Server diverse Sicherheitseinstellungen? Zetifikate, Verschlüsselung?
Ich hab das vor Jahren mal mit einer 1516 getestet. Da hat die Anmelduung (connect) am Server über 4 Sekunden gedauert. Das lesen selber geht dann schnell. (wenn man die Verbindung anschliessend nicht trennt ist die Zeit zum lesen immer sehr kurz im2-stelligen ms-Bereich (soweit ich mich erinner))
Bei Authentisierung mit Benutzer Passwort hielt sich die Anmeldezeit in Grenzen. War glaube ich unter 1 Sek.

Kann es also evtl sein, das du schon den nächsten request auslöst bevor die vorigen bendet waren?
Ich weiss jetzt nicht wie weit das stapelbar ist.

Die Verbindung in dem Testtool wird einmal hergestellt und ist unabhängig von der aufgenommenen Zeit. Das Abbauen der Verbindung erfolgt erst beim Schließen der Anwendung. Das in dem Test erfolgt alle 5 Sekunden und ist immer sequentiell, sodass sich da nichts überholt.

Eine Benutzer und Passwort Authentifizierung ist teilweise eingerichtet teilweise nicht.

 

[blackpeat]

Baust du vorm Lesen die OPC UA Verbindung neu auf oder besteht die immer?

 

[canogretic]

Die Verbindung besteht immer. Ich habe das Verhalten letzte Woche mal mit Wireshark untersucht mit etwas mehr als einem Datenpunkt (Die Menge ist aber auch noch sehr gering). Aufzeichnung hänge ich mal an.
Die Probleme treten im Bereich der Retransmissions auf, weswegen die erste Vermutung die verbauten Netzwerkleitungen waren. Da sich aber aufgrund des Tausches keine Besserung ergeben hat, gehe ich eher nicht mehr von Netzwerkproblemen aus.

 

[Indu-Sol]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo canogretic,

so wie es aussieht, kommen die OPC UA Nachrichten von der Siemens Steuerung bei dem OPC UA Client an, was bedeutet, dass die Anfragen erneut gesendet werden, wodurch die TCP/Retransmissions entstehen.
Folgende Ursachen könnte diese Verhalten hervorrufen:

1. Die Anfrage kommt bei der SPS nicht an (Anfrage geht im Netzwerk verloren)
2. Die SPS antwortet nicht auf die Anfrage (Evtl. Performance Engpässe zu diesem Zeitpunkt)
3. Die Antwort kommt bei der SPS nicht an (Anfrage geht im Netzwerk verloren)

Um die Ursache einzugrenzen können folgende Maßnahmen durchgeführt werden:

1. Netzwerkscan/Topologiescan mit dem INspektor ausführen, um anhand der Portstatistiken aller Geräte zu prüfen, ob es verworfene Pakete im Netzwerk gibt. Ports mit erhöhten Discard-Werten deuten auf kurzzeitige Überladen hin und Ports mit Errors auf Kabel oder EMV-Ursachen.
2. Wireshark Mitschnitt an der SPS durchführen, um zu prüfen, ob die Anfragen korrekt ankommen und die Antworten auch versendet werden
   -> Werden zum Beispiel die Anfragen aufgezeichnet, aber auch hier bleiben die Antworten aus, dann würde es auf ein Performance oder Konfigurationsproblem der SPS hindeuten. Vielleicht gibt es ja minütlich auch andere Abfragen.

Sollte der OPC UA Client nicht direkt im selben Netzwerkbereich installiert sein und es gibt noch Firewalls oder Router zwischen beiden Kommunikationspartner, dann sind diese Prüfungen auch an anderen Stellen erforderlich.

Da das Verhalten wie von dir beschrieben zyklisch pro Minute auftritt, würde ich einen Installationsfehler ausschließen und das Performance-Thema als erstes ins Auge fassen.

VG

Frank Lehmann

 

[blackpeat]

Was mir gerade noch einfällt wie hoch ist die Zykluszeit? Wir hatten Probleme mit dem OPC-UA wenn wir keine Mindestzykluszeit eingestellt hatten wir tauschen aber auch sehr viele Daten aus. Kommunikationslast in den Einstellungen könnte da auch eine Einstellung sein wo du mal gucken kannst.

 

[Pipboy]

D4:F5:27: ist doch die MAC vom XC206.
Hast du da NAT oder Inter-VLAN-Routing eingeschaltet?

 

[canogretic]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo canogretic,

so wie es aussieht, kommen die OPC UA Nachrichten von der Siemens Steuerung bei dem OPC UA Client an, was bedeutet, dass die Anfragen erneut gesendet werden, wodurch die TCP/Retransmissions entstehen.
Folgende Ursachen könnte diese Verhalten hervorrufen:

1. Die Anfrage kommt bei der SPS nicht an (Anfrage geht im Netzwerk verloren)
2. Die SPS antwortet nicht auf die Anfrage (Evtl. Performance Engpässe zu diesem Zeitpunkt)
3. Die Antwort kommt bei der SPS nicht an (Anfrage geht im Netzwerk verloren)

Um die Ursache einzugrenzen können folgende Maßnahmen durchgeführt werden:

1. Netzwerkscan/Topologiescan mit dem INspektor ausführen, um anhand der Portstatistiken aller Geräte zu prüfen, ob es verworfene Pakete im Netzwerk gibt. Ports mit erhöhten Discard-Werten deuten auf kurzzeitige Überladen hin und Ports mit Errors auf Kabel oder EMV-Ursachen.
2. Wireshark Mitschnitt an der SPS durchführen, um zu prüfen, ob die Anfragen korrekt ankommen und die Antworten auch versendet werden
   -> Werden zum Beispiel die Anfragen aufgezeichnet, aber auch hier bleiben die Antworten aus, dann würde es auf ein Performance oder Konfigurationsproblem der SPS hindeuten. Vielleicht gibt es ja minütlich auch andere Abfragen.

Sollte der OPC UA Client nicht direkt im selben Netzwerkbereich installiert sein und es gibt noch Firewalls oder Router zwischen beiden Kommunikationspartner, dann sind diese Prüfungen auch an anderen Stellen erforderlich.

Da das Verhalten wie von dir beschrieben zyklisch pro Minute auftritt, würde ich einen Installationsfehler ausschließen und das Performance-Thema als erstes ins Auge fassen.

VG

Frank Lehmann

Hi @Indu-Sol,

zunächst vielen Dank für die Nachricht. Den Scan werde ich gleich oder spätestens morgen mal durchführen. Inzwischen hat sich herausgestellt, dass im Netzwerk sehr viele Arp Request entstehen. Aus meiner Sicht deutet das auf eine Fehlkonfiguration hin.

Die angeschlossenen HMI Panels bei uns beispielsweise, melden komischerweise innerhalb einer Wireshark Aufzeichnung den ARP-Request nach der eigenen IP mit der Ziel Adresse 0.0.0.0. Und das Ganze auch mehrfach in kurzen zeitabständen.
Optisch sieht die Einstellung auf dem Panel aber passend und richtig aus. Daher können wir das aktuell noch nicht einordnen.

Daher ist unser erster Ansatz jetzt erstmal die Ganzen Arp Nachrichten im Netzwerk zu analysieren und abzustellen. In wie weit das dann eine Besserung hervorruft muss sich aber erst noch zeigen.

VG Alex

 

[canogretic]

D4:F5:27: ist doch die MAC vom XC206.
Hast du da NAT oder Inter-VLAN-Routing eingeschaltet?

NAT und VLAN Routing sind nicht eingeschaltet.

 

[canogretic]

Was mir gerade noch einfällt wie hoch ist die Zykluszeit? Wir hatten Probleme mit dem OPC-UA wenn wir keine Mindestzykluszeit eingestellt hatten wir tauschen aber auch sehr viele Daten aus. Kommunikationslast in den Einstellungen könnte da auch eine Einstellung sein wo du mal gucken kannst.

Die Kommunikationslast ist aktuell auf 25% eingestellt. Die Mindestzykluszeit bei 1ms. An die Kommunikationslast hatte ich auch schon kurz gedacht. Werden jetzt aber erstmal versuchen die ARP Anfragen im Netzwerk zu reduzieren, da diese sehr viel traffic ausmachen

 

[UWI]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Alex,

beide im Wireshark-Log aufgezeichneten Unterbrechungen laufen exakt nach dem selben Muster ab.

1. Siemens (als Server!!!) schickt einen ARP los
2. Client antwortet korrekt
3. Siemens schickt noch die Response auf den Request vor dem ARP
4. Client schickt nächsten Request und wiederholt ihn 4 mal mit Retransmission, weil Siemens nicht antwortet
5. Client schickt selbst ARP
6. Siemens beantwortet den ARP korrekt
7. Siemens schickt sofort die Response auf den letzten Request.

Das bedeutet: Siemens hat den zunächst unbeantworten Request verstanden, sonst gäbe es keine korrekte Response.

Dass Siemens bei Verbindungen, die von der SPS als Client aktiv geöffnet worden sind, auch bei laufendem, intensiven Telegrammverkehr zyklisch nutzlose ARP’s einstreut, ist bekannt und stört eigentlich nicht weiter.

In deinem Fall macht dies aber die SPS als Server. Das habe ich so noch nicht beobachtet. Mir scheint, das Siemens die nach diesem ARP eingelaufenen Telegramme intern nicht an den Applikation-Layer weiterreicht, oder aber die Antwort blockiert. Das könnte u.U. sogar ein Firmware-Bug bei Siemens sein.

Gegen Fehlinterpretationen benutzte ich für die Wireshark-Aufzeichnungen einen separaten PC und einen zwischengeschalteten „Schnüffel-Switch“, bei dem ich den Traffic zwischen zwei Ports auf einen dritten Mirrorport ausleite. Dies würde ich hier auch empfehlen, um eventuelles Fehlverhalten des Scalance bei diesen ARP’s auszuschließen. Ich würde ihn hier zwischen die Siemens-SPS und den Scalance hängen.

VG Uwe

 

[canogretic]

Hi Alex,

beide im Wireshark-Log aufgezeichneten Unterbrechungen laufen exakt nach dem selben Muster ab.

1. Siemens (als Server!!!) schickt einen ARP los
2. Client antwortet korrekt
3. Siemens schickt noch die Response auf den Request vor dem ARP
4. Client schickt nächsten Request und wiederholt ihn 4 mal mit Retransmission, weil Siemens nicht antwortet
5. Client schickt selbst ARP
6. Siemens beantwortet den ARP korrekt
7. Siemens schickt sofort die Response auf den letzten Request.

Das bedeutet: Siemens hat den zunächst unbeantworten Request verstanden, sonst gäbe es keine korrekte Response.

Dass Siemens bei Verbindungen, die von der SPS als Client aktiv geöffnet worden sind, auch bei laufendem, intensiven Telegrammverkehr zyklisch nutzlose ARP’s einstreut, ist bekannt und stört eigentlich nicht weiter.

In deinem Fall macht dies aber die SPS als Server. Das habe ich so noch nicht beobachtet. Mir scheint, das Siemens die nach diesem ARP eingelaufenen Telegramme intern nicht an den Applikation-Layer weiterreicht, oder aber die Antwort blockiert. Das könnte u.U. sogar ein Firmware-Bug bei Siemens sein.

Gegen Fehlinterpretationen benutzte ich für die Wireshark-Aufzeichnungen einen separaten PC und einen zwischengeschalteten „Schnüffel-Switch“, bei dem ich den Traffic zwischen zwei Ports auf einen dritten Mirrorport ausleite. Dies würde ich hier auch empfehlen, um eventuelles Fehlverhalten des Scalance bei diesen ARP’s auszuschließen. Ich würde ihn hier zwischen die Siemens-SPS und den Scalance hängen.

VG Uwe

Hi Uwe,

ja das es immer nach dem selben Muster abläuft ist mir auch aufgefallen. Der Siemens Support verwies auch nur darauf das 75% des aufgezeichneten Netzwerktraffics Arp Requests sind und der ein oder andere Teilnehmer wohl auf Adresse 0.0.0.0 hört.

Auffällig sind in diesem Bereich eingesetzte Simatic HMI Panels. Von den Einstellungen sah das aber in Ordnung aus und das horchen auf 0.0.0.0 ist nicht wirklich erklärbar.

Gestern wollte ich den ganzen Traffic zwischen CPU und Switch aufzeichnen. Dabei ist mir aufgefallen, dass das Problem plötzlich weg ist seit letzten Freitag und ich absolut keine Erklärung dafür habe.

Ich muss dazu sagen, dass wir vor ca. 2 Wochen einen auffälligen IP-Adressbereich innerhalb des Netzes umgestellt haben. Das die Einstellung aber erst 10 Tage später greift (Ob irgendwas neu gestartet wurde kann ich nicht sagen. Der IPC nach der Umstellung aber wohl definitiv nicht).

Jedenfalls muss ich im Augenblick unzufriedener Weise leider sagen, dass das Problem sich auf einmal in Luft aufgelöst hat und ich keine plausible Erklärung habe warum das so ist.

VG Alex

 

[Indu-Sol]

Hi Alex,

die ARP-Requests der HMI Panels können folgendermaßen entstehen: Wird in einem PROFINET-Projekt keine Gateway-Adresse verwendet, dann wird für alle PROFINET-Geräte die eigene Adresse als Gatewayadresse vergeben. Das ist in der Regel auch nicht schlimm, da die Geräte keine Funktionen besitzen, die die Gateway-Adresse benötigen, da die Geräte nicht selbständig versuchen eine Kommunikation zu einem anderen Gerät aufzubauen. Bei HMI-Panels könnte dies aber anders sein, da diese auch unterschiedliche Dienste unterstützen, welche aktiv nach einem Server suchen, wie zum Beispiel einen Zeitserver.
Daher prüfe bitte mal, wie die IP-Konfiguration der Geräte ist, welche Dienste aktiv sind, welche IP-Adressen hinterlegt sind und teile die Ergebnisse des Scans hier einfach.

Am besten du machst auch noch den Wireshark-Mitschnitt am Spiegelport des INspektors. Das hat dieselbe Wirkung wie die Vorgehensweise, die UWI empfohlen hat.

Wie UWI es beschrieb, kann es ein Performance Thema sein und dann ist es die SPS. Und an dieser Stelle wäre auch interessant, wie viele Geräte sich im Layer 2-Netzwerk befinden, wenn es bereits mindestens der Adressbereich von 192.168.0.0 bis 192.168.11.254 ist. Vielleicht kommt es auch zu einem Überlauf des ARP-Caches.

Danke dir für weiteren Input.

VG
Frank Lehmann