Fehler in industriellen Netzwerktopologien: Linien-, Stern-, Ring- und Baumfehler bei Schneider-Modicon- und Phoenix-Contact-Systemen

Warum sind Kenntnisse der Netzwerktopologie für die industrielle Verfügbarkeit entscheidend?

Jedes Industrienetzwerk hat eine Struktur, und jede Struktur weist ein eigenes Fehlermuster auf. Die meisten Ingenieure lernen diese Muster jedoch erst bei einem Ausfall kennen. Ich musste sie an einer Abfüllanlage auf die harte Tour lernen. Eine Schneider Modicon M580 SPS hatte drei Altivar-Frequenzumrichter über Modbus RTU in einer Daisy-Chain verbunden. Eine lose Klemme an VFD-2 unterbrach die Kommunikation zu VFD-3, während VFD-1 weiterhin problemlos abfragte. Die Anlage stand vier Stunden still, weil niemand dem Topologieplan vertraute. Untersuchen Sie daher, wie Linien-, Stern-, Ring- und Baumtopologien ausfallen, bevor der Ausfall Sie überrascht.

Welche typischen Probleme mit Terminierung und Leitungslänge gibt es bei Linientopologien?

Bei einer Linientopologie werden die Geräte von Knoten eins bis Knoten N in Reihe geschaltet. Sie benötigt nur wenig Verkabelung und eignet sich für kleine, weniger kritische Anwendungen. Allerdings birgt sie einige Fallen. Erstens: die Terminierung. Ein RS-485-Modbus-RTU-Segment benötigt an beiden physikalischen Enden einen Abschlusswiderstand von 120 Ohm. Ein Profibus-DP-Segment benötigt sein spezifisches Abschlussnetzwerk: 220 Ohm zwischen den Adern und 390-Ohm-Bias-Widerstände bei Verwendung geeigneter Busstecker, die nur am ersten und letzten Gerät zugeschaltet werden. Außerdem fand ich einmal drei zugeschaltete Abschlusswiderstände an einem Trunk. Reflexionen verfälschten zufällig Telegramme, und CRC-Fehler überfluteten das Ausnahmeprotokoll der M580. Zweitens: die Entfernung. Ein Modbus-RTU-Trunk arbeitet bei 9.600 Baud zuverlässig über ungefähr 1.200 Meter. Wird die Baudrate auf 115.200 erhöht, verkürzt sich die sichere Leitungslänge drastisch. Denken Sie schließlich an die asymmetrischen Ausfallfolgen. Ein ausgeschaltetes Gerät führt die Verbindung normalerweise weiter. Ein kurzgeschlossener Anschluss unterbricht jedoch die gesamte Linie.

• Schritt 1: Begehen Sie den physikalischen Trunk und tragen Sie die Position jedes Geräts auf Papier ein.
• Schritt 2: Prüfen Sie, ob die Terminierung genau an den beiden physikalischen Enden aktiv ist und nirgendwo sonst.
• Schritt 3: Messen Sie den Bus mit einem Leitungstester auf Bias-Spannung und Signalqualität.
• Schritt 4: Vergleichen Sie die Baudrate mit der gesamten Leitungslänge und reduzieren Sie die Rate, wenn die Reserven knapp sind.

Warum hängt eine Sterntopologie vollständig vom Zustand des zentralen Switches ab?

Bei einer Sterntopologie sind alle Geräte an einem zentralen Switch angeschlossen. Die Fehlersuche ist einfach, und eine Erweiterung lässt sich problemlos umsetzen. Allerdings ist das zentrale Gerät ein Single Point of Failure. Fällt dieser Switch aus, fällt die gesamte Zelle mit ihm aus. Ich betreue eine Anlage, in der ein gemanagter Phoenix Contact FL SWITCH eine Modbus-TCP-Zelle bündelt, die über ein Modbus-TCP-Kommunikationsmodul verbunden ist. Der Switch blieb funktionsfähig, doch ein falsch konfigurierter Port überflutete einmal den Datenverkehr mit Multicast-Paketen von einem einzigen IO-Scanner. Jeder Modbus-TCP-Client lief innerhalb von Sekunden in einen Timeout. Außerdem kann ein nicht gemanagter Switch einen solchen Fehler nicht einmal melden. Verwenden Sie daher überall dort gemanagte Switches, wo die Produktion betroffen ist. Aktivieren Sie IGMP-Snooping, um Multicast-Verkehr einzudämmen. Konfigurieren Sie schließlich Portstatistiken und lösen Sie bei steigenden Fehlerzählern einen Alarm aus, bevor die Benutzer etwas bemerken.

• Schritt 1: Ersetzen Sie nicht gemanagte Switches in Produktionszellen durch gemanagte Geräte.
• Schritt 2: Aktivieren Sie IGMP-Snooping und prüfen Sie die Portstatistiken wöchentlich.
• Schritt 3: Sperren Sie ungenutzte Ports und konfigurieren Sie Geschwindigkeit und Duplexmodus ausdrücklich.
• Schritt 4: Halten Sie für jede kritische Zelle einen programmierten Ersatz-Switch als Kaltreserve bereit.

Wie konfiguriert man Redundanz in einer Ringtopologie richtig?

Eine Ringtopologie bietet jedem Gerät zwei Kommunikationswege. Im Normalbetrieb bleibt ein Weg logisch blockiert, und der Ring verhält sich wie eine Linie. Wenn ein Kabel ausfällt, heilt sich der Ring über den alternativen Weg. Die Wiederherstellung hängt jedoch vollständig von der korrekten Konfiguration ab. Gemanagte Phoenix-Contact-Switches unterstützen MRP, das in IEC 62439-2 standardisierte Media Redundancy Protocol. Bei MRP muss genau ein Switch als Ringmanager, der MRM, konfiguriert sein, während alle anderen als Clients arbeiten. Bei korrekter Konfiguration dauert die Wiederherstellung weniger als 200 Millisekunden. Die Schneider Modicon M580 bietet eine eigene redundante Ringstruktur für dezentrale IO-Stationen. Überprüfen Sie daher bei jeder Inbetriebnahme die Managerrolle. Ich prüfte einmal einen Ring, in dem zwei Manager von zwei verschiedenen Auftragnehmern konfiguriert worden waren. Das Netzwerk lief monatelang problemlos. Dann löste das Abziehen eines Kabels doppelte Pakete und eine Überflutung aus, woraufhin das gesamte Segment instabil wurde. Denken Sie außerdem an das zweite Gesetz von Ringen: Nach dem ersten Bruch haben Sie eine Linie ohne jegliche Redundanz. Beheben Sie den Fehler sofort.

• Schritt 1: Bestätigen Sie, dass in jedem Ringsegment genau ein MRP-Manager vorhanden ist.
• Schritt 2: Testen Sie den Ring während der Inbetriebnahme, indem Sie absichtlich ein Kabel abziehen.
• Schritt 3: Messen Sie die Wiederherstellungszeit und vergleichen Sie sie mit der Toleranz Ihres Prozesses.
• Schritt 4: Lösen Sie bei Ring-Neukonfigurationen einen Alarm aus, damit defekte Kabel noch am selben Tag repariert werden.

Wie verhindert man Broadcast-Stürme in hierarchischen Baumtopologien?

Hierarchische Baumtopologien lassen sich hervorragend auf große Anlagen skalieren. Zellenswitches werden in Bereichsswitches zusammengeführt, und die Bereichsswitches speisen den Anlagen-Backbone. Die Hierarchie schafft jedoch Abhängigkeiten. Fällt ein Switch auf höherer Ebene aus, wird alles darunter dunkel. Außerdem kann ein einziger unscheinbarer Verdrahtungsfehler den gesamten Baum lahmlegen. Ein zusätzliches Patchkabel zwischen zwei Switches erzeugt eine Ethernet-Schleife. Broadcast-Frames zirkulieren endlos, und ein Broadcast-Sturm überlastet innerhalb von Sekunden jeden Switch. Ich habe erlebt, wie dadurch eine komplette Verpackungshalle ausfiel. SPSen und HMIs verloren zufällig die Kommunikation, obwohl die gesamte Hardware gesund wirkte. Wenn das Spanning Tree Protocol zu langsam reagiert oder gar nicht konfiguriert ist, gewinnt der Sturm. Aktivieren Sie daher Rapid Spanning Tree in der Hierarchie und kennzeichnen Sie jeden Uplink physisch.

• Schritt 1: Aktivieren Sie RSTP auf allen hierarchischen Phoenix-Contact-Switches mit den richtigen Prioritäten.
• Schritt 2: Kennzeichnen und farbcodieren Sie jedes Uplink-Kabel, um versehentliche Kreuzverbindungen zu verhindern.
• Schritt 3: Überwachen Sie die Broadcast-Pakete pro Port und lösen Sie bei plötzlichen Spitzen einen Alarm aus.
• Schritt 4: Verschließen Sie den Switchraum und verlangen Sie für alle Patcharbeiten eine Änderungsfreigabe.

Fazit und Handlungsempfehlungen

Topologiefehler sind Designfehler, die im ungünstigsten Moment sichtbar werden. Prüfen Sie zunächst jeden RS-485-Trunk auf korrekte Terminierung und ausreichende Längenreserven. Standardisieren Sie zweitens auf gemanagte Switches und lesen Sie deren Statistiken, bevor die Bediener die Alarme sehen. Testen Sie außerdem jeden Redundanzring, indem Sie während der Inbetriebnahme physisch ein Kabel abziehen. Gehen Sie jedoch niemals davon aus, dass ein Ring, der die Inbetriebnahme überstanden hat, weiterhin gesund ist — überprüfen Sie die Managerrolle nach jedem Switch-Austausch. Halten Sie daher Ihre Topologiezeichnungen aktuell und behandeln Sie sie als kontrollierte Dokumente. Üben Sie schließlich die in diesem Leitfaden beschriebenen Ausfallszenarien mit Ihrem Team. Der beste Zeitpunkt, das Verhalten eines Rings kennenzulernen, ist ein geplanter Test und kein Ausfall um 3 Uhr morgens.

Autor: Xu Jiawei ist Ingenieur für industrielle Automatisierung und verfügt über mehr als 10 Jahre Erfahrung mit SPS-, DCS- und Leitsystemen.