Die Netzwerkdiagnose

Für die Fehlersuche in Feldbusnetzwerken leisten heute spezielle Tools, so genannte Busmonitore, gute Dienste. Inwieweit lassen sich die dort implementieren Prüfmethoden und Strategien auch auf die Ethernet-Kommunikation übertragen?

Für die Fehlersuche in Feldbusnetzwerken leisten heute spezielle Tools, so genannte Busmonitore, gute Dienste. Inwieweit lassen sich die dort implementieren Prüfmethoden und Strategien auch auf die Ethernet-Kommunikation übertragen?

Kommunikationssystemen im Industriebereich liegen in der Regel umfangreiche Spezifikationen zugrunde. Werden diese unterschiedlich, nicht optimal oder gar falsch interpretiert, so können sowohl bei der Implementierung der definierten Funktionen in reale Geräten und Anwendungen als auch beim Zusammenschalten verschiedener Geräte und Anwendungen Verhältnisse entstehen, die eine Kommunikation unmöglich machen oder zumindest stark einschränken. Damit nicht genug: Auch Fehler bei der Parametrierung und Konfiguration des Datenaustausches sowie externe Einflüsse – zum Beispiel elektromagnetische oder mechanische Störungen – führen in der Praxis immer wieder zu Kommunikationsproblemen.

Was die etablierten Feldbusse betrifft, haben sich für solche Fälle Busmonitore bewährt: Sie zeichnen den Datenverkehr auf dem Kommunikationsmedium auf, stellen komplexe Zusammenhänge einfach und übersichtlich dar und bieten umfangreiche Möglichkeiten zur Fehlerlokalisierung. Dabei reicht der Einsatzbereich solcher Lösungen von der Überprüfung der Funktionsweise von Geräten über die Inbetriebnahme und die Optimierung der Kommunikation bis hin zum Auffinden von sporadischen Fehlern in laufenden Anlagen. In letzterem Fall werden Busmonitore temporär direkt in der Anlage verbaut.

Nach der Ära der Feldbusse stehen jetzt die Ethernet-basierten Kommunikationssysteme in den Startlöchern. Zwar bleiben dabei viele Randbedingungen und Anforderungen im Vergleich zu den etablierten Feldbussystemen gleich. Dennoch gilt es einige wichtige Punkte zu beachten, die letztendlich neue Konzepte für die Netzwerkdiagnose erfordern.

Die Anforderungen am Beispiel Profinet IO

Im Beispiel von Profinet IO – einem typischen Vertreter von „Industrial Ethernet“ – lassen sich erst mit dem Einsatz von Switches und der Full-Duplex-Übertragung die Anforderungen an einen uneingeschränkten bidirektionalen Datenaustausch zwischen verschiedenen Bereichen beziehungsweise Ebenen in der Automatisierungspyramide erfüllen. Der überwiegende Teil der Daten wird dabei als Unicast zwischen zwei Teilnehmern ausgetauscht. Aus diesen Randbedingungen folgt, dass sich Telegramme nicht an jedem beliebigen Punkt des Netzwerkes, sondern nur im Kommunikationspfad zwischen Sender und Empfänger aufzeichnen lassen.

Die Aufzeichnung dieser Daten kann auf zweierlei Arten erfolgen. Im Fall einer Sterntopologie – sprich, wenn alle Geräte an einem externen Switch angeschlossen sind -– ist ein Switch zu wählen, der Port-Mirroring unterstützt. Hierbei wird der gesamte Datenverkehr an einem Port auf einen Spiegel-Port verdoppelt und steht dort für die Datenauswertung zum Beispiel durch einen Monitor zur Verfügung. Die besten Ergebnisse lassen sich erzielen, wenn derjenige Port gespiegelt wird, an dem die SPS angeschlossen ist. Grund ist: Die SPS ist Sender und Empfänger fast aller Telegramme im System. Ergo lassen sich aus der Aufzeichnung dieser Telegramme entsprechend aussagekräftige Schlussfolgerungen ableiten.

Es gibt aber auch Einsatzfälle, bei denen eine Sterntopologie aus verschiedenen Gründen nicht passend ist. So erfordert der Aufbau einer Sterntopologie mehr Kabel; außerdem steht in kompakten Maschinen und Anlagen der Platz für einen externen Switch oft nicht zur Verfügung, oder es entstehen durch einen externen Switch zusätzliche Kosten. Dann ist der Aufbau einer Linien-Topologie unter Verwendung von Geräten mit integrierten 2-Port-Switches eine passende Alternative. Ein Mirror-Port steht hier aber nicht zur Verfügung. Stattdessen lassen sich Daten bei der Linien-Topologie nur über ein passives T-Stück (Tap) erfassen. Hierzu wird das Ethernet-Kabel aufgetrennt – im Idealfall ebenfalls zwischen SPS und erstem Device – und ein entsprechendes T-Stück eingesetzt.