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 eigenes Abnahmekriterium — die eine wird nur qualitativ beschrieben, die andere kommt dort unter diesem Namen gar nicht vor. 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 stehen bleibt. 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 Kriterien für die Abnahme des Netzwerks in einem eigenen Kapitel — es sind genau vier. Daneben prüft die Abnahme die eingestellte Kommunikationsüberwachung gegen die Planung und bei Polymerfaser die optische Systemreserve; beides sind Soll-Ist-Vergleiche gegen die Planung, keine Messgrößen des laufenden Netzes. Alles Weitere, namentlich der Jitter, steht in einem nachfolgenden Kapitel unter der Überschrift „weitere Parameter zur Bewertung des Netzwerkes“ — hier kurz: ergänzende Parameter.

Linientiefe: 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. Die Richtlinie nennt diese Größe Linientiefe: die Anzahl aller durchleitenden Geräte einer Kommunikationsstrecke — Switches wie Devices mit integriertem Switch.

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; die Werte gelten für Netze mit 100 Mbit/s.

Bei gemischtem Aufbau gelten die Store-and-Forward-Werte — oder die Durchleitezeit wird explizit gerechnet; ist das Verfahren unbekannt, ist von Store-and-Forward auszugehen. Unabhängig von der Tabelle empfehlen Planungs- und Inbetriebnahmerichtlinie, aus Gründen der Verfügbarkeit, der Diagnose und einer späteren Ringerweiterung mit MRP höchstens 45 Geräte in Linie zu planen. 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 und Multicasts: die Fehlerklasse, die niemand misst

Für ARP-Broadcasts gilt: Null bedeutet keine Handlung; treten welche auf, ist zu klären, ob einzelne Teilnehmer gesucht werden oder ob jemand zyklisch ganze IP-Bereiche absucht. Für DCP-Multicasts nach dem Systemhochlauf setzt die Richtlinie eine Staffel: bis zehn vom Controller gesuchte Teilnehmer sind bei bekannter, unabänderlicher Ursache — Werkzeugwechsel, temporäre Teilnehmer — hinnehmbar, elf bis zwanzig gelten als hohe Multicast-Last, über zwanzig ist ein störungsfreier Betrieb nicht mehr sicherzustellen. MRP-Testtelegramme dürfen außerhalb des Rings gar nicht auftreten; tauchen sie an einem freien Port auf, ist die Ringkonfiguration falsch.

Der zyklische IP-Scan ist mit dem Planungsverantwortlichen zu bewerten — es ist weniger eine Frage des Netzes als eine Frage danach, was im Produktionsnetz laufen darf; wie sich ein Produktionsnetz ohne solche Scans systematisch erfassen lässt, steht in einem eigenen Beitrag.

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 führt die Inbetriebnahmerichtlinie nicht als eigene Größe. Gleichgültig sind sie deshalb nicht: Die Richtlinie nennt Übertragungsfehler ausdrücklich als eine Ursache verworfener Pakete — ein Telegramm mit falscher Prüfsumme wird verworfen und fällt damit unter das Kriterium mit dem Grenzwert null. Der Messbericht nennt die Ursache, die Richtlinie die Wirkung. Was die Richtlinie an Switch-Statistiken als üblicherweise auslesbar 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. Die ist nicht wertlos: Die Inbetriebnahmerichtlinie will sie als kombinierte Netzlast einschließlich Nicht-Echtzeit-Verkehr zusätzlich erfasst und bei erheblicher Abweichung von der zyklischen Last in ihrer Ursache geklärt haben. Aber sie ist eine andere Zahl.

Wichtiger noch ist, was die Planungsrichtlinie zur Aussagekraft sagt: Bei der Netzlastermittlung findet eine Mittelwertbildung statt, die Verteilung der Last im Betrachtungszeitraum lässt sich daraus nicht bestimmen — 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. Die Inbetriebnahmerichtlinie zieht daraus die Konsequenz: dokumentiert wird mindestens der Maximalwert, gemessen so lange, dass ein Produktionszyklus vollständig erfasst ist, und für Sende- und Empfangsrichtung getrennt bewertet.

Zur Gegenprobe am Schreibtisch liefert die Planungsrichtlinie Erzeugungswerte je Gerät für ein typisches Telegramm von 108 Byte (60 Byte Nutzdaten, einschließlich Präambel und Telegrammlücke) bei 100 Mbit/s. Geräte mit mehr E/A-Daten — Antriebe, Ventilinseln mit Diagnose — liegen entsprechend höher. 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, für ein Telegramm von 108 Byte mit 60 Byte Nutzdaten. Die Richtlinie nennt die Werte einen ersten Anhaltspunkt und stellt für die eigene Datenmenge ein kostenloses Berechnungswerkzeug bereit; 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, wird meist mit Herstellerinteressen abgetan. Die Begründung steht aber in der Richtlinie selbst: Sie hält fest, dass sich die Pakete am Zielport in Aufbau und zeitlicher Zuordnung von den ursprünglichen unterscheiden können. Eine Jitter-Kurve aus einem Spiegelport misst deshalb den Switch mit — daraus folgt der Schluss, nicht aus einem Verbot.

Ä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 Zahlen aus den Richtlinien — drei Ursachen und eine Grenze der Kabelmessung — 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 hält für Ringe mit Medienredundanz fest, dass die Ansprechüberwachungszeit über der Rekonfigurationszeit des Rings liegen muss — und die beträgt bei MRP typischerweise 200 ms.

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. Ob sie geschuldet ist, entscheidet nicht die Richtlinie, sondern das, was im Lastenheft oder in der Abnahmevereinbarung steht.

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.