PROFINET-Analyse: Welche Grenzwerte wirklich gelten

Ein PROFINET-Messbericht liegt auf dem Tisch. Darin: eine Jitter-Kurve mit roter Markierung, eine Tabelle mit CRC-Fehlern, eine Durchschnittsnetzlast von acht Prozent, darunter der Satz „Grenzwert nach PI-Richtlinie überschritten“.

Zwei der drei genannten Größen sind in der PI-Inbetriebnahmerichtlinie kein Abnahmekriterium — und für eine davon existiert dort überhaupt kein Zahlenwert. Das ist keine Spitzfindigkeit: Wer nach einem Bericht dieser Art Switches tauscht, behebt möglicherweise nichts, weil die eigentliche Ursache gar nicht gemessen wurde.

Dieser Artikel sortiert, welche Werte die Richtlinie tatsächlich setzt, wie sie zu lesen sind und wo die Ursachen liegen, wenn alle Protokollwerte unauffällig aussehen und die Anlage trotzdem sporadisch stehenbleibt. Wer ohnehin vor der Umstellung von PROFIBUS steht, findet den Weg dorthin unter den Migrationspfaden — die Grenzwerte unten gelten dann für das Ergebnis.

• An dieser Stelle belastbar
• Verfälscht oder unvollständig
• Zählwerte statt Mitschnitt

Eigene Darstellung nach der PI-Inbetriebnahmerichtlinie 8.081/8.082 V1.53 (Abgriffsarten und ihre Einschränkungen).

Die vier Kriterien, die tatsächlich gesetzt sind

Die Inbetriebnahmerichtlinie führt die Abnahmekriterien in einem eigenen Kapitel — es sind genau vier. Alles Weitere, namentlich der Jitter, steht in einem nachfolgenden Kapitel unter der Überschrift „weitere Parameter zur Bewertung des Netzwerkes“.

Leitungstiefe: die härteste Zahl, ganz ohne Messgerät

Wie viele weiterleitende Geräte zwischen einem Device und dem Controller liegen dürfen, hängt an der Aktualisierungszeit und am Switch-Verfahren:

Aktualisierungszeit	Store-and-Forward	Cut-Through
1 ms	7	64
2 ms	14	100
4 ms	28	100
8 ms	58	100

PI-Inbetriebnahmerichtlinie 8.081/8.082 V1.53, Kapitel der Abnahmekriterien.

Bei gemischtem Aufbau gelten die Store-and-Forward-Werte; ist das Verfahren unbekannt, ist davon auszugehen. Diese Prüfung kostet zehn Minuten am Topologieplan und erklärt einen erheblichen Teil aller Jitter-Beschwerden: Eine lange Linie bei 1 ms Aktualisierungszeit erzeugt lastabhängige Durchlaufzeiten, die als Jitter sichtbar werden — obwohl kein Gerät defekt ist.

Verworfene Pakete: der Grenzwert ist null

Die Null ist wörtlich gemeint. Über einen Betrachtungszeitraum von 60 Sekunden soll kein Paket verloren gehen, ausdrücklich für Kupfer- wie für Lichtwellenleiterstrecken. „Ein paar Discards sind normal“ ist von der Richtlinie nicht gedeckt — der Satz fällt in Diskussionen über Messberichte trotzdem regelmäßig.

Broadcasts: die Fehlerklasse, die niemand misst

Für ARP und DCP setzt die Richtlinie harte Stückzahlen. Null Broadcasts bedeuten keine Handlung; treten welche auf, ist zu klären, ob einzelne Teilnehmer gesucht werden oder ob jemand zyklisch ganze IP-Bereiche absucht. Letzteres ist mit dem Planungsverantwortlichen zu bewerten — es ist weniger eine Frage des Netzes als eine Frage danach, was im Produktionsnetz laufen darf.

Was nicht drinsteht: Jitter und CRC-Fehler

Für Jitter nennt die Richtlinie keinen Zahlenwert. Sie beschreibt ihn qualitativ: Ein gewisser Jitter sei besonders bei Linientopologien systembedingt und entstehe durch lastabhängig unterschiedliche Durchlaufzeiten; ein dauerhaft steigender Jitter könne auf Störungen, geänderte Last, Topologieänderungen oder einen Gerätetausch hindeuten.

Der viel zitierte Wert „50 Prozent der Aktualisierungszeit“ stammt aus dem Handbuch eines Messgeräteherstellers. Als Praxisfaustregel ist er brauchbar — als „Grenzwert nach PI-Richtlinie“ ist er falsch zitiert.

CRC-Fehler kommen in der Inbetriebnahmerichtlinie als Abnahmekriterium überhaupt nicht vor. Was sie zum Auslesen an Switches nennt, sind drei andere Größen:

Ausgerechnet die letzte Größe ist in der Praxis ergiebig und steht selten in Berichten: Ein Port, der im Halbduplex läuft, weil eine Seite fest eingestellt ist und die andere verhandelt, produziert genau die sporadischen Ausfälle, die man dann in der Jitter-Kurve sucht.

Netzlast: die meistverkürzte Zahl

Zitiert wird fast immer nur „20 Prozent“. Unterschlagen wird zweierlei: dass 20 bis 50 Prozent kein Fehler ist, sondern ein Prüfauftrag, und dass sich der Wert auf die zyklische Echtzeitkommunikation bezieht — während Messgeräte oft die Gesamtlast aller Protokolle anzeigen.

Wichtiger noch ist, was die Richtlinie selbst zur Aussagekraft sagt: Die Verteilung der Last im Betrachtungszeitraum lässt sich nicht bestimmen, weil die Werte immer gemittelt werden — je länger der Zeitraum, desto stärker verwischen kurze Spitzen. Eine Durchschnittslast von acht Prozent über eine Stunde schließt eine Spitze von hundert Prozent über drei Millisekunden nicht aus. Und genau diese Spitze legt die Anlage lahm, nicht der Mittelwert.

Zur Gegenprobe am Schreibtisch liefert die Planungsrichtlinie Erzeugungswerte je Gerät für ein typisches Telegramm bei 100 Mbit/s. Damit lässt sich vor jeder Messung ausrechnen, welche Größenordnung überhaupt zu erwarten ist:

Aktualisierungszeit	Last je Gerät
1 ms	0,86 %
2 ms	0,43 %
4 ms	0,22 %
8 ms	0,11 %

PI-Planungsrichtlinie 8.061/8.062 V1.59. Die Rechnung ersetzt keine Messung — sie sagt nur, welche Größenordnung eine Messung bestätigen müsste.

Vierzig Geräte auf 1 ms ergeben damit rechnerisch etwa 34 Prozent in Richtung Controller. Werden dort sechs Prozent gemessen, misst das Gerät etwas anderes als angenommen — oder an der falschen Stelle.

Der Messweg: vier Stufen, vier Fehlerquellen

Zwischen dem Verdacht und dem Bericht liegen vier Stufen. Jede hat ihre eigene Art, ein Ergebnis unbrauchbar zu machen — und die erste ist die einzige, die sich später nicht mehr korrigieren lässt.

Warum der Spiegelport für Zeitmessungen nicht taugt

Der Spiegelport — in den Menüs der Switches meist Mirror-Port — kopiert den Verkehr eines Ports auf einen Zielport. Dass er für Zeitmessungen nichts taugt, hört man sonst meist von TAP-Herstellern. Die Aussage steht aber auch in der Richtlinie selbst, und zwar mit zwei Begründungen.

Ähnlich klar ist die Abgrenzung zur aktiven Diagnose über SNMP, Webserver oder Bordmittel: Aktives Auslesen erzeugt zusätzlichen Verkehr und ist für zeitlich hochauflösende Analysen deshalb nicht geeignet.

Wenn alle Protokollwerte sauber sind

Bleiben die vier Kriterien unauffällig und die Anlage fällt trotzdem sporadisch aus, liegt die Ursache meist in der Physik. Vier Punkte mit belegten Zahlen — und keiner davon braucht einen Netzwerkanalysator.

Ein Konflikt, bei dem beide Seiten recht haben

Bei der Kommunikationsüberwachung stoßen zwei Empfehlungen aufeinander, die beide belegt sind. Die Richtlinie setzt als Auslöseschwelle drei Zyklen ohne gültige Daten an und empfiehlt, es dabei zu belassen; Siemens warnt für Ringtopologien ausdrücklich vor genau dieser Einstellung.

Was ein Bericht enthalten muss

Die Richtlinie sieht für das Abnahmeprotokoll zur Hälfte Soll-Ist-Vergleiche gegen die Planung vor: Gerätenamen, IP-Adressen, Firmwarestände, Aktualisierungszeiten, Überwachungsschwellen. Ein Bericht, der nur Messkurven zeigt, ist damit kein Abnahmeprotokoll — er ist eine Momentaufnahme ohne Bezugsgröße.

Zum Schluss ein Punkt, der in Messberichten selten steht: Eine Abnahmemessung der Verkabelung ist beim Komponentenansatz mit Herstellererklärung nicht verpflichtend. Wer sie beauftragt, tut das aus gutem Grund — bei konfektionierten Leitungen, gewachsenen Anlagen oder wiederkehrenden Störungen. Als gesetzliche Pflicht lässt sie sich nicht begründen.

Bleibt am Ende die Frage, ob das Netz oder die Steuerung das Problem ist: Bei Anlagen mit Altsteuerungen lohnt es, beides zusammen zu betrachten — die Bestandsaufnahme erhebt Feldbus und Peripherie ohnehin gemeinsam.