Bild 1: Szenario Sterntopologie: Telegramme an einem Port des Switches werden auf den Mirror-Port gespiegelt

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.

Bild 2: Szenario Linientopologie mit integriertem Tap: Ein Tap muss rückwirkungsfrei sein, das heißt, es darf die Kommunikation nicht beeinträchtigen ”“ selbst dann nicht, wenn das Tap ausfällt

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.

Die Profinet-IO-Spezifikation definiert eine Vielzahl von Funktionen wie zum Beispiel den gleichzeitigen Zugriff auf Geräte durch mehrere SPSen, die Unterstützung von Medienredundanz, das Erfassen von Topologie-Information aus der Anlage, den Gerätetausch ohne erneutes Verwenden eines Parametriergerätes oder auch Anwendungen mit sehr kurzen Zykluszeiten und geringem Jitter. Je nach geforderter Funktionalität ergeben sich spezielle Anforderungen an Monitoring-Lösungen. Ein Beispiel dafür ist das Link Layer Discovery Protocol (LLDP), welches für den Austausch von Information zwischen direkt benachbarten Geräten verwendet wird. Im Ergebnis „weiß“ ein Kommunikationsteilnehmer, mit welchen anderen Teilnehmern er verbunden ist und welche Eigenschaften die Verbindung hat. Eine Überwachung des Informationsaustausches kann aber nur in der direkten Verbindung zwischen benachbarten Geräten erfolgen.

Das Verwenden der verschiedenen IT-Protokolle in den Conformance Classes eröffnet aber auch neue Möglichkeiten. Das Simple Network Management Protocol (SNMP) etwa erlaubt über den Zugriff auf Management Information Bases (MIB) das Auslesen von Information über den Zustand des Gerätes, der Kommunikationsschnittstellen und der Kommunikation. So gibt es eine MIB-Spezifikation, die Information zur Verwaltung der Ethernet-Schnittstelle zur Verfügung stellt. Durch das Auslesen entsprechender Zähler lässt sich das gehäufte Auftreten zerstörter Frames feststellen. Ein Monitor muss in diesem Fall aktiv im Netzwerk kommunizieren.

Soviel zu den grundlegenden Anforderungen an Busmonitore am Ethernet. Je nach Einsatzszenario sind weitere Aspekte von Bedeutung und müssen entsprechend in künftigen Tools berücksichtigt werden:

Einsatzszenario A – Test der Geräte-Implementierung

Im einfachsten Fall möchte der potenzielle Nutzer des Netzwerkdiagnosetools damit die Richtigkeit und Vollständigkeit seiner Geräte-Implementierung testen. Diesen Test wird er üblicherweise in einem Testbett zusammen mit weiteren marktgängigen Geräten sowie unter Umständen unter Verwendung bestimmter Testprogramme durchführen. Je nach Topologie – Linien- oder Sternstrukturen – kann die Aufzeichnung der Daten wie bereits erwähnt über Mirror-Ports oder Taps erfolgen. Da es um die Funktionsweise eines einzigen Gerätes geht, stellt die Überwachung der Kommunikation zwischen benachbarten Teilnehmern keine große Schwierigkeit dar. Hierzu ist lediglich ein Tap an entsprechender Stelle einzubringen. Auch der Testfall, dass mehrere Steuerungen auf das Device zugreifen, lässt sich mit Hilfe mehrerer Taps durchführen. Die Monitoring-Anwendung muss in diesem Fall entsprechende Synchronisationsmechanismen unterstützen.

Einsatzszenario B – Inbetriebsetzung, Kommunikationsoptimierung und Fehlersuche

Bei diesem Szenario wird es der Anwender immer mit einer vorgegebenen Kommunikationsstruktur zu tun haben, bei der die Automatisierungsgeräte durchaus zum Teil in Stern- und zum Teil in Linienstruktur miteinander verbunden sein können. Üblicherweise findet sich hier ein Switch/Router, der die Verbindung zum zentralen Firmennetz herstellt. Ein PC mit Visualisierungs-Software ist in der Regel ebenfalls in das Netz integriert. Im ungünstigsten Fall existiert hier weder die Möglichkeit, Daten über Mirror-Ports zu erfassen, noch können Taps eingebracht werden. Dafür gibt es folgende Gründe:

• Mirror-Ports finden sich nur in der Klasse der „Managed Switches“. Diese verfügen im Unterschied zu „Unmanaged Switches“ über mehr Funktionalität, die sich über entsprechende Schnittstellen (Web, serielles Terminal) verwalten lässt. Diesem Vorteil steht allerdings ein deutlich höherer Preis gegenüber. Hinzu kommt, dass ein zum Mirror-Port erklärter Port für die Nutzdatenkommunikation nicht mehr zur Verfügung steht. Unter Umständen treibt dies die Kosten für die Kommunikations-Infrastruktur weiter in die Höhe.
• Sind erst einmal alle Kabel verlegt und die Installation abgenommen, ist es meist nicht mehr einfach, Verkabelungen wieder aufzutrennen und Taps einzubringen.

Bild 3: Conformance Classes für Profinet IO: Die Spezifikation adressiert eine Vielzahl von Anforderungen aus unterschiedlichen Bereichen. Nicht für jeden Einsatzfall müssen alle Funktionen im Gerät implementiert sein. Vielmehr definieren die Conformance Classes Mindestanforderungen, die dem Anwender bei der Geräteauswahl helfen sollen

Die Profinet-IO-Spezifikation definiert für diese Fälle eine Reihe von Funktionen (Erfassen der angeschlossenen Geräte und ihrer Eigenschaften/Auslesen von Datenobjekten) und in die Geräte zu implementierende Objekte, über die sich ein aktuelles Systemabbild erfassen lässt. Bei Vorhandensein eines Netzwerkzuganges zum System kann die aktive Komponente eines Monitors angeschlossen werden. Dieser Bestandteil des Monitors kann im Unterschied zum passiven Teil, der Daten lediglich erfasst und auswertet, selber Daten mit Geräten austauschen. Diese Komponente dient dazu, Information aus den vorhandenen Profinet-IO-Geräten – wie etwa deren symbolische Namen, bereits vergebene IP-Adressen oder auch die Eigenschaften der bereits aufgebauten Kommunikationsbeziehungen – zu erfassen. Auf diese Weise ist der Ist-Zustand des Kommunikationssystems und der Geräte darstellbar.

Abweichungen vom Ist-Zustand kann der Inbetriebnehmer über die Kenntnis des Soll-Zustandes identifizieren – im Idealfall wird er dabei vom Diagnosetool unterstützt.

Nicht erfassbar sind auf diese Weise die Gründe für Kommunikationsprobleme, also zum Beispiel nicht vergebene IPAdressen, nicht aufgebaute Verbindungen, sporadische Verbindungsabbrüche oder ein Geräteausfall. Da diese Information in den Geräten nicht verfügbar ist, sind diese Gegebenheiten nur über eine Aufzeichnung des entsprechenden Kommunikationsverkehrs identifizierbar.

Mess-Netz-Kombination in der Praxis

Für den Fall, dass ein Mirror-Port an einem oder mehreren Switches genutzt werden kann beziehungsweise sich Taps einbringen lassen, sind weitere Punkte zu berücksichtigen: In der Hochlaufphase des Systems werden die IP-Adressen vergeben, die Verbindungen aufgebaut und – sofern notwendig – Parameter in die Geräte übertragen. Ethernet-Frames sind jetzt nur durch die MAC-Adresse gekennzeichnet. Somit ist es nahezu ausgeschlossen, aus der Aufzeichnung dieses Datenverkehrs Rückschlüsse auf die Systemstruktur zu treffen und somit eine verständliche Darstellung der Zusammenhänge vorzunehmen. Heutige Busmonitore liefern immer eine „Lifelist“ der angeschlossenen Geräte mit detaillierter Information. Allein aus Kenntnis der MAC-Adresse ist diese Lifelist nicht entsprechend generierbar. Somit ist es auch in diesem Szenario wichtig, eine aktive Komponente als Bestandteil des Monitors zu nutzen.

Bild 4: In realen Netzen ist oft ein Mix aus Stern- und Linientopologie vorzufinden und zum Teil auch noch komplexere Strukturen: Für all diese Fälle gilt es praxistaugliche Monitore für Industrial Ethernet zu entwickeln

Die Herausforderungen in diesem Szenario vergrößern sich, wenn mehrere Steuerungen auf die Daten in den Devices zugreifen. In diesem Fall reicht es nicht aus, die ausgetauschten Telegramme nur an einem Mirror-Port oder nur über ein Tap aufzuzeichnen. Vielmehr sind jetzt Aufzeichnungen an mehreren Punkten vonnöten und in der Folge eine Synchronisation dieser Aufzeichnungen hinsichtlich ihrer logischen und zeitlichen Abfolge durch die Monitoranwendung. Dies betrifft zum Beispiel die bereits erwähnte Lifelist: Jeder Controller baut eine Verbindung zu einem Gerät auf, mit dem er Daten austauschen will. Werden beide Kommunikationswege zwischen zwei Controllern und demselben Device überwacht, wird der Verbindungsaufbau zweimal aufgezeichnet – es existiert aber nur ein Device! Weiterhin sind Lösungen für die Übertragung der Datenströme vom Mirror-Port oder Tap zur Monitoranwendung zu finden.

Erfolgt der Anschluss einer Monitorstation an einen Mirror-Port oder Tap über Ethernet, so werden die erfassten Daten dabei unverändert als Nachrichtenstrom weitergeleitet. Um die Telegramme zu akzeptieren, muss die entsprechende Ethernet-Schnittstelle des PC im „Promiscious Mode“ arbeiten. Ein Vergleich der Zieladresse des Telegramms mit der eigenen Adresse der Ethernet-Schnittstelle findet in diesem Modus nicht statt – alle ankommenden Telegramme werden akzeptiert. Es gibt durchaus Szenarien, bei denen mehrere Taps oder Mirror-Ports an der Datenerfassung beteiligt sind. In diesem Fall muss eine Lösung für das Zusammenfassen der Datenströme beim Übertragen zur Monitoranwendung gefunden werden. Da sich die Übertragung der Daten vom Tap über das vorhandene Prozessdatennetz aus Gründen der Rückwirkungsfreiheit und Bandbreitenbelastung verbietet, ist für diese Zwecke die Implementierung eines eigenständigen Mess-Netzes mit entsprechendem Protokoll anzudenken.

Einsatzszenario C – Busmonitor für die stationäre Diagnose

Was die stationäre Diagnose betrifft, lassen sich zwei Einsatzfälle unterscheiden:

> Finden sporadischer oder wiederkehrender Fehler beziehungsweise Fehlverhalten,

> Überwachen des Prozess-Zustandes und der Automatisierungsgeräte durch Auswerten der ausgetauschten Prozessgrößen und Telegramme.

Bei beiden „Use Cases“ ist der gesamte Datenverkehr immer über einen längeren Zeitraum aufzuzeichnen. Hier helfen eigentlich nur Taps, da sie im Vergleich zu Switches mit Mirror-Ports flexiblere Einsatzmöglichkeiten bieten. In verschiedenen Projekten (zum Beispiel DFAMProjekt „Industrial Ethernet Monitor“, durchgeführt am ITM der TU München) werden gegenwärtig Taps mehrerer Hersteller auf ihre Eignung im Umfeld von Real-Time-Ethernet untersucht.

Eine der an einen Tap gestellten Anforderungen ist die Rückwirkungsfreiheit der Datenerfassung; ein Punkt, der bei allen marktüblichen Taps als erfüllt angesehen werden kann. Eine weitere Forderung ist die Parametrierbarkeit der Datenaufzeichnung. Bei der stationären Diagnose interessieren nur bestimmte Telegramme oder deren Ausbleiben – zum Beispiel Telegramme, die Kommunikationsfehler anzeigen oder Telegramme mit Prozessdaten. Deshalb ist eine Möglichkeit der Parametrierung des aufzuzeichnenden Datenverkehrs notwendig, um den PC zu entlasten. Die entsprechende Funktionalität muss zukünftige Taps für die Diagnose im RTE-Umfeld implementieren.

Letztendlich sind auch für die stationäre Diagnose entsprechende Konzepte zu erarbeiten, die Anschlüsse zur Datenerfassung bereits im Entwurf der Anlage berücksichtigen.

Autor:

Franz Iwanitz ist Produktmanager Real-Time-Ethernet bei der Softing AG, Haar.