Profinet-IO Statistiken mit Wireshark

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,
mein Plan ist es, Wireshark um ein paar Statistik-Funktionen für Profinet zu erweitern, um damit in der Praxis ein paar nützliche Aussagen über das Netzwerk treffen zu können.

Solche Statitstikfunktionen sind in Wireshark für ausgewählte Netzwerkprotokolle schon vorhanden. In etwa vergleichbar wäre das Protokoll RTP (Real-Time Transport Protocol) für Medienstreams (übrigens ganz witzig, Wireshark kann aus einem Netzwerkmitschnitt die übertragenen Audiodaten abspielen).

Meine bisherige Liste an Daten die interessant sind, wären:

1) Netzwerkauslastung anteilig Profinet / restliche Netzwerklast
2) Anzahl der Pakete einer Konversation (Quell-MAC zu Ziel-MAC)
3) Min/Max/Mittelwert Jitter in ms
4) Anzahl der Watchdog-Timeout-Fehler
5) Erfassung der Teilnehmernamen (falls ein Konfigurationstelegramm in der Aufzeichnung vorhanden ist)


Zu 1) Die Funktion ist in Wireshark schon vorhanden. Über Statistics -> Protocol Hierarchie bekommt man eine Balkendarstellung in dem die Protokolle die in dieser Datei erfasst wurden aufgelistet werden. Mit Anteilen in %, in kbit/s usw.

Punkt 3) berechne ich aus dem Unterschied des PN-Cyclecounters aus zwei aufeinander folgenden Telegrammen, und dem Unterschied zwischen den Zeitstempeln zu denen diese Telegramme erfasst wurden. Die Genauigkeit hängt dabei davon ab, wie genau das Betriebssystem die Zeitstempel einträgt. USB-Netzwerkadapter sind darum aufgrund der zusätzlichen Latenzen zu vermeiden.

Fragen:
- Welche Statuswerte führen noch zu einem Erhöhen des Fehlerzählers? Der Jitter würde dann ab diesem Punkt neu berechnet.
Bisher habe ich als Bedingung:
pn_rt.frame_id == 0xfe01 and pn_io.error_code1 == 253 and pn_io.error_code2 == 5
welche ich bisher immer bei meinen Aufzeichnungen gesehen habe, wenn ein Teilnehmer ausfällt.
Vielleicht hat jemand Zugriff auf die Profinet-Spec und kann mal nachsehen was dort für den Fall festgelegt wurde.

- Welche Informationen könnte man noch sammeln?


Bisher mache ich die Analyse statisch mit einem Python-Skript. Wenn die Funktion feststeht werde ich mich daran machen das in Wireshark zu integrieren.

Aus der Wireshark-Aufzeichnung aus diesem Thread (http://www.sps-forum.de/simatic/63239-profinet-sporadischer-teilnehmerausfall.html) bekomme ich z. Zt. die folgende Informationen extrahiert:

Src MAC            Dst MAC            Packets[#]  Min-Jitter[ms]  Max-Jitter[ms]  Mean-Jitter[ms]  Min in Frame[#]  Max in Frame[#]  Errors[#]
----------------------------------------------------------------------------------------------------------------------------------------------
00:20:d5:01:19:45  00:30:de:06:66:f1        5240        0.000032        2.968040         0.074671             4905             4501          0
ec:e5:55:33:77:75  00:20:d5:01:19:45           4       31.868956       32.189152        32.035372            31549            31546          1
00:30:de:06:67:1b  00:20:d5:01:19:45           5        0.002893        0.104937         0.048654            31524            31543          1
00:30:de:06:66:f1  00:20:d5:01:19:45        5227        0.000032        4.113880         0.058599             1535             4313          1
00:30:de:06:66:9f  00:20:d5:01:19:45        5228        0.000032        0.889984         0.061982              320            21933          1
00:20:d5:01:19:45  00:30:de:06:66:fa        5241        0.000032        4.114119         0.073236             1266             4312          0
00:20:d5:01:19:45  00:30:de:06:66:9f        5241        0.000032        3.042969         0.071416              787             4308          0
00:30:de:06:67:06  00:20:d5:01:19:45           2        0.037941        0.037941         0.037941            31529            31529          1
00:30:de:06:a8:33  00:20:d5:01:19:45           3        0.017134        0.083891         0.050512            31530            31538          1
00:30:de:06:66:fa  00:20:d5:01:19:45        5228        0.000032        0.968012         0.060594             1457            30099          1
00:30:de:06:66:a5  00:20:d5:01:19:45           3        0.010046        0.034061         0.022054            31528            31537          1

MAC-Adresse        Device-Name
----------------------------------------------------------------------------------------------------------------------------------------------
00:30:de:06:66:fa  montagekanuelekappe
00:30:de:06:66:9f  zufuehrungkanuele
00:30:de:06:66:f1  kanalkanuelekappe

 

[uwe.k]

Hallo Thomas_v2.1
durch Zufall bin ich auf diesen älteren thread gestoßen. Wie ist denn dein Wireshark Projekt zur PN - Statistik fortgeschritten?

VG Uwe K

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Uwe,

ich habe daran bis auf einen ersten Ansatz nicht weitergemacht, ich weiß aber nicht mehr warum nicht, ob es da irgendwelche Schwierigkeiten gab. Falls du dich etwas mit Python auskennst, kann ich dir aber das Skript zur Verfügung stellen. So ganz fertig ist das aber nicht, weil ich eben eigentlich vorhatte das zu integrieren.

 

[uwe.k]

Hallo Thomas,
habe mit Python noch nicht gearbeitet, wie leicht ließe es denn sich in Wireshark weiternutzen/ einbinden um dort zusätzliche Dateninformationen zu generieren? Wenn die Implementierung in Wireshark leicht realisieren ließe, könnte man sich ja mal mit Python beschäftigen. Einfacher wäre es wenn man in Wireshark direkt Formel - Berechnungen von Spaltenwerten in einer User - Spalte durchführen könnte.
VG Uwe

 

[Thomas_v2.1]

Weiternutzen lässt sich da nichts, außer das Prinzip wie etwas zu berechnen ist. In der Wireshark GUI lassen sich über Benutzereingaben nur Pakete filtern. Könnte sein, dass es möglich ist durch passende Filter nach Teilnehmer und Zeitdifferenz nach Ausreißern zu filtern, und dann selber zu rechnen wie viele sind gesamt da / wie viele haben Ausreißer. Um in Wireshark etwas in der GUI selber außerhalb der Paketdarstellung anzuzeigen, muss du das direkt in C bzw. C++ schreiben. Ansonsten gibt es noch die Möglichkeit kleine Skripte in Wireshark in LUA zu schreiben, aber das wirkt sich auch nur auf die Paketdarstellung aus.

Der Profinet Teil in Wireshark wird als einer der wenigen Protokolle von Haus aus in einer separaten dll geliefert. Wenn ich mich recht entsinne hat das ein paar nachteilige Auswirkungen zur Folge wenn man so einen Stats-Tree in Wireshark selber bauen möchte. Kann aber auch sein, dass ich damals nicht wusste wie das richtig geht.

Mit meinem Python-Skript hole ich mir mit tshark (bei Wireshark dabei) die notwendigen Felder aus einer pcap Aufzeichnung. Das kannst du auch in jeder anderen beliebigen Sprache machen wenn dir eine besser gefällt.

 

[Process-Informatik GmbH]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas_v2.1 Schick uns doch bitte eine EMail mit einer Beschreibung Deiner Anforderungen, wir haben einen PN-Watchdog, der Aufzeichnungen im Profinet bereits durchführt. Der wird einfach in die Verkabelung eingesetzt, Du musst nicht mit speziellen Hub oder Managed-Switch Deinen PC ins Profinet bekommen.
Einfach den PN-WATCHDOG einstecken und über den integrierten WebServer aufzeichnen. Die Darstellung ist dann wie bei Wireshark, aber mit den geforderten Funktionen.
EMail-Adresse: verkauf@process-informatik.de

 

[LW167237]

@Thomas_v2.1 könntest du mir dein Skript zukommen lassen?
Ich habe bereits viel mit Python gearbeitet. Vielleicht kann man das ganze ja gemeinsam weiter machen.

 

[olliew]

Falls noch von Interesse (ist ja schon ein bisschen her)

Fragen:
- Welche Statuswerte führen noch zu einem Erhöhen des Fehlerzählers? Der Jitter würde dann ab diesem Punkt neu berechnet.
Bisher habe ich als Bedingung:
pn_rt.frame_id == 0xfe01 and pn_io.error_code1 == 253 and pn_io.error_code2 == 5
welche ich bisher immer bei meinen Aufzeichnungen gesehen habe, wenn ein Teilnehmer ausfällt.
Vielleicht hat jemand Zugriff auf die Profinet-Spec und kann mal nachsehen was dort für den Fall festgelegt wurde.

errorcode == 0xCF mit code1 == 253 und code2 == 5 bedeutet so viel wie Watchdog Fehler wegen fehlende zyklische Frames.

Es gibt dann auch noch code2 == 15 -> wenn der SPS bewusst aufhört und dies auch mitteilt am Device. Zum Beispiel nach ein SFC12 D_ACT_DP.

Damit hat man dann geschätzte > 99,9% der Ausfall Fälle abgedeckt