Um in einem Ethernet-Netzwerk Fehler zu finden oder Netzwerkengpässe frühzeitig zu erkennen, werden hohe Anforderungen an die Qualifikation des Personals der Anlage gestellt. Neue, in der Industrie bislang nicht gebräuchliche Diagnosewege, z.B. das Simple Netzwerk Management-Protokoll (SNMP), können nur sinnvoll über entsprechende, teilweise sehr teure Diagnosetools genutzt werden. Darüber hinaus werden von vielen Netzkomponenten über gerätespezifische Web-Seiten Statistikzähler (z.B. CRC-Fehler) und zusätzliche Projektierungsmöglichkeiten der Geräte (z.B. Porteinstellungen) zur Verfügung gestellt. Aber auch hier werden vom Anwender entsprechende Netzwerkkenntnisse vorausgesetzt, um mit diesen Informationen eine entsprechende Diagnose bzw. Netzeinstellung durchführen zu können. Neben diesen seit einiger Zeit etablierten Diagnosemöglichkeiten wird jetzt die Projektierung und Diagnose der Netzkomponenten über die bei Profinet standardisierten Projektier- und Diagnosewege wesentlich erleichtert. Durch die Einbindung der Netzkomponenten in den offenen Automatisierungsstandard Profinet ist erstmalig eine umfassende und einheitliche Diagnose einer Industrieapplikation vom Controller über die E/A-Baugruppe bis zur Netzwerkkomponente möglich. Simatic NET Scalance Die gemanagten Switches der Produktlinien Simatic NET Scalance X-200 und X-400 bieten dem Anwender die Möglichkeit, den Datenverkehr an den einzelnen Ports genau zu beobachten und bei Störungen entsprechend zu reagieren. Weiterhin bieten die Switches aus den Produktlinien Scalance X-200 und X-400 auch die Möglichkeit der Überwachung der Geräte über SNMP- bzw. Profinet-Mechanismen. Die Geräte ermöglichen damit den reibungslosen Betrieb einer jeden Industrieapplikation (Bild 1+2). Diagnose mittels SNMP In den 80er Jahren wurde auf Grund ständig wachsender Netze mit unterschiedlichsten Komponenten von verschiedenen Herstellern das Simple Network Management Protocol (SNMP) eingeführt. Dieser Standard, der von der Netzwerkindustrie sehr schnell akzeptiert wurde, schaffte die Basis, in Netzen mit unterschiedlichsten Geräten von verschiedenen Herstellern eine einheitliche Schnittstelle zur Diagnose und Projektierung dieser Geräte zu schaffen. Mit der steigenden Anzahl von heterogenen Ethernet-Netzwerken in der Industrie wächst aber auch dort die Bedeutung von SNMP. SNMP ist ein UDP-basiertes Protokoll (User Datagram Protocol), das sich mittlerweile zum Defacto-Standard für Diagnose und Konfiguration von Netzkomponenten etabliert hat. Die einzelnen Netzkomponenten verfügen über einen so genannten SNMP-Agenten, der Informationen in strukturierter Form Kasten: Ausgelastete Server Oftmals beklagen Anwender von geswitchten Netzen, dass das Netz sehr langsam ist. Um der Ursache auf den Grund zu gehen, kann die Portauslastung am Switch des angeschlossenen Teilnehmers bewertet werden, ein Parameter, der häufig auf den Web-Oberflächen der Switches zur Verfügung gestellt wird. Die Auslastung an Endgeräteports bewegt sich typischerweise in der Größenordnung von 1 bis 5%. Hier sind für den Netzwerkbetrieb in der Regel keine Probleme zu erwarten. Treten dennoch Schwierigkeiten auf, sind oftmals überlastete Server im Netz, auf denen die genutzten Applikationen laufen, die Ursache für Probleme. Es ist aber nicht nur der Port, an dem der Teilnehmer angeschlossen ist, zu bewerten, sondern alle Ports des Switches. Vielleicht gibt es auf dem Switch einen anderen Port, der den Switch unnötig belastet, da dort eine deutlich höhere Portauslastung vorherrscht. Fehlende Autonegotiation Ein anderes, häufig auftretendes Problem sind fest konfigurierte Switch- bzw. Endgeräte-Ports, also Ports, die nicht am Autonegotiationsverfahren teilnehmen. Mit Hilfe dieses Verfahrens handeln beide Partner die Parameter für die Datenübertragung aus. Es wird festgelegt, welche Übertragungsgeschwindigkeit (10Mbit/s oder 100Mbit/s) und welche Betriebsart verwendet wird (Half-Duplex oder Full-Duplex). Wird hier ein Teilnehmer mit aktiviertem Autonegotiation an einen Teilnehmer mit fest eingestelltem Port angeschlossen, so sind Probleme in der Kommunikation nicht auszuschließen. Der Teilnehmer mit aktiviertem Autonegotiation erkennt den Partner als nicht autonegotiationsfähiges Gerät. Deshalb stellt sich dieser zwar auf die richtige Übertragungsgeschwindigkeit ein, kann aber die Datenübertragungsart nicht erkennen. Die Daten werden dann häufig im Half-Duplex-Verfahren übertragen, was bedeutet, dass immer nur eine Station sendet und die andere Station empfängt. Beim Full-Duplex-Übertragungsverfahren können dagegen beide Stationen gleichzeitig Daten senden und empfangen. Treten nun am Port mit eingestellter Autonegotiation Kollisionsfehler auf, so kann dies ein Anzeichen einer fehlerhaften Einstellung von Half- und Full-Duplex sein. Sollten nun bei der Untersuchung des fest eingestellten Ports noch verstärkt Telegramme mit gültiger Länge, aber fehlerhafter Prüfsumme (Telegramme mit CRC-Fehler) und zusätzlich noch zu kurze Telegramme (Undersize-Telegramme bzw. Runts) bzw. nicht durch acht teilbare Telegramme (Oversize-Telegramme bzw. Alignment Errors) auftreten, so ist die Diagnose eindeutig. Der mit Autonegotiation arbeitende Port hat sich auf Half-Duplex eingestellt, der fest eingestellte Port wurde auf Full-Duplex eingestellt. Die für diese Diagnose benötigten Informationen werden üblicherweise auf den Web-Oberflächen der handelsüblichen Switches angezeigt. Mit dem Hintergrundwissen über die oben geschilderten Zusammenhänge ist es dem Anwender nun möglich, entsprechende Fehler schnell und einfach zu analysieren. Leitungsbeschädigungen Ein weiterhin sehr häufig auftretendes Problem sind Leitungsbeschädigungen im laufenden Betrieb. Viele Applikationen tolerieren einige Wiederholungen fehlerhaft oder nicht angekommener Telegramme, so dass eine leicht beschädigte Leitung zuerst in der Anlage nicht bemerkt wird. Als Beschädigung wird hier jede Abweichung von den spezifizierten Übertragungsparametern der Leitung verstanden. Beschädigte Leitungen zwischen zwei Geräten, die im Full-Duplex-Modus betrieben werden, können aber durch die auftretenden Telegramme mit gültiger Länge und fehlerhafter Prüfsumme (Telegramme mit CRC-Fehler) erkannt werden. Bei Leitungen, die im Half-Duplex-Modus betrieben werden, kommen zu den Telegrammen mit gültiger Länge und fehlerhafter Prüfsumme (Telegramme mit CRC-Fehler) noch zusätzlich Telegramme, die zu kurz (Undersize-Telegramme bzw. Runts) bzw. deren Länge nicht durch acht teilbar ist (Oversize-Telegramme bzw Alignment Errors) hinzu, so dass auch hier eine einfache Diagnose über die an der Web-Oberfläche zur Verfügung gestellten Daten möglich ist. Port-Mirroring Einige der moderneren Switches bieten auch die Diagnosemöglichkeit des Port-Mirroring. Dies bedeutet, dass der Datenverkehr an einem Port auf einen weiteren, speziell ausgewählten Port gespiegelt wird. Die Mirror-Port-Einstellungen können meist über die Web-Oberfläche des Geräts vorgenommen werden. Durch diese Funktion kann der Anwender mit einer geeigneten Hard- und Software die gewünschten Telegramme aufzeichnen und vorliegende Netzwerkprobleme analysieren. Bei diesem Verfahren ist das möglicherweise entstehende Datenaufkommen zu berücksichtigen, wenn ein auf Full-Duplex arbeitender 100Mbit/s-Port gespiegelt werden soll. Um aus solchen Aufzeichnungen entsprechende Fehler besser herauslesen zu können, ist eine Referenzmessung in einer Laborumgebung zu empfehlen, um das richtige Arbeiten der Spiegelfunktion sicherzustellen. Nach Abschluss der Analyse sollte nicht vergessen werden, den Mirror-Port wieder in seine alte Konfiguration zurückzustellen, da sonst der Anschluss eines neuen Geräts an diesen Port zu ungewollten Effekten führen kann. Vor der Auswahl eines gemanagten Industrieswitches ist also darauf zu achten, welche Diagnosemöglichkeiten der Switch insbesondere über seine Weboberfläche zur Verfügung stellt. Ein einfaches Handling ist wichtig und ermöglicht im Problemfall eine schnelle, zuverlässige und einfache Diagnose. Kasten Ende zur Verfügung stellt. Diese Struktur wird als MIB (Management Information Base) bezeichnet. Eine MIB ist eine standardisierte Datenstruktur aus verschiedenen SNMP-Variablen, die in einer vom Zielsystem unabhängigen Sprache geschrieben ist. Durch die herstellerübergreifende Standardisierung der MIBs und des Zugriffsmechanismus lässt sich auch ein heterogenes Netzwerk mit Komponenten von unterschiedlichen Herstellern überwachen und steuern. Neben den gerätespezifischen MIBs werden von den Geräten auch teilweise MIBs zur Verfügung gestellt, in denen die prozentuale Auslastung einzelner Ports, Fehlerstatistiken oder Art und Anzahl der übermittelten Telegramme ausgegeben werden. Diese Werte werden in so genannten RMON-MIBs (Remote Monitoring) zur Verfügung gestellt und über SNMP abgefragt. Mit Hilfe dieser Werte ist es möglich, die Diagnose eines Netzwerks durchzuführen und Netzwerkengpässe und fehlerhafte Konfigurationen aufzudecken. Mit Hilfe von RMON lassen sich aber auch Verkehrsdaten dezentral sammeln und statistisch verdichten. Die Datensammlung erfolgt über so genannte RMON-Probes. Diese als Probe bezeichneten Geräte oder Software erfassen, speichern und analysieren den an ihnen vorüberströmenden Datenverkehr in Echtzeit. Eine Probe kann als separate Hardware, als Funktion eines Switches oder in einer Netzwerkmanagement-Applikation integriert sein. Eine auf SNMP basierende Netzwerkmanagementlösung arbeitet nach dem Client/Server-Modell. Die Managementstation (SNMP Client) kann Informationen von den zu kontrollierenden Agenten, die als Server agieren, abfragen. Die MIB-Informationen werden von der Managementstation zyklisch abgerufen und gegebenenfalls visualisiert. Die Netzkomponenten sind jedoch auch in der Lage, gewisse Zustände über so genannte Traps unaufgefordert an die Netzwerkmanagementstation zu melden. Mit SNMP lassen sich Netzkomponenten nicht nur überwachen, sondern auch steuern. Hierzu zählt z.B. das Aktivieren oder Deaktivieren eines Ports an einer Netzkomponente. Die Kommunikation zwischen den Agenten und der Netzwerkmanagementstation läuft im Hintergrund ab und belastet das Netzwerk nur unwesentlich. Da bei industriellen Netzwerken unterschiedlichste Netzgrößen vorkommen, kann eine Netzwerkmanagementstation, bestehend aus einem leistungsfähigen Rechner mit entsprechender Netzwerkmanagement-Software, in der Anschaffung sehr teuer und in der Bedienung sehr aufwendig sein. Deshalb wird oftmals eine Integration der gesamten Netzwerkdiagnose in ein in der Anlage bereits bestehendes HMI- bzw. Scada-System (Human Machine Interface, Supervisory Control And Data Aquisition) gefordert. SNMP-OPC-Schnittstelle Um eine Einbindung der SNMP-fähigen Geräte zu ermöglichen, unterstützen diese Systeme die standardisierte und herstellerunabhängige Software-Schnittstelle OPC (OLE for Process Control). Mit dieser Schnittstelle in den HMI- und Scada-Systemen und dem SNMP-OPC-Server von Simatic Net wurde eine in die Automatisierungslandschaft eingebettete Lösung für Netzwerkmanagement über SNMP geschaffen. Der SNMP-OPC-Server erlaubt den Zugriff auf SNMP-fähige Geräte aus beliebigen OPC-Client-Systemen. Die Visualisierung der Geräteinformationen lässt sich je nach Anforderung individuell gestalten und kann an die Bedürfnisse der jeweiligen Anlage angepasst werden. Darüber hinaus können die zur Verfügung gestellten Informationen ins Meldesystem und Meldearchiv eines HMI/Scada-Systems eingebunden werden. Somit lassen sich die gleichen Werte, die auf den gerätespezifischen Webseiten zur Verfügung gestellt werden, über SNMP-Befehle aus den Geräten auslesen und in den HMI-Systemen darstellen. Vorteil hierbei ist, dass Daten über einen größeren Zeitbereich aufgezeichnet und feingranularer dargestellt werden können. Somit lassen sich Laststatistiken mehrer Ports parallel erstellen, die dann einen einfachen Überblick über die Netzauslastung bzw. die Auslastung der Netzkomponente ermöglichen. Schwellwerte können gezielt überwacht werden, und bei Überschreitung von eingestellten Schwellen können entsprechende Alarmmeldungen generiert werden. Über den SNMP-Zugang der Netzkomponenten und über den SNMP-OPC-Server von Simatic Net ist ein vorhandenes HMI/Scada-System somit zum anlagenspezifischen Netzwerk-Management-System erweiterbar. Auf diese Weise können die Netzwerkkomponenten der Automatisierungs-Applikation zum einen in übergeordnete SNMP-basierte Netzwerk-Management-Lösungen eingebunden werden. Andererseits kann durch die Einbindung in vorhandene HMI/ Scada-Lösungen ein separates Netzwerk-Management-System für die Automatisierungsapplikationen eingespart werden. (Bild 3+4). Profinet vereinfacht Diagnose In industriellen Anlagen haben sich in der Vergangenheit Mechanismen etabliert, über die es möglich ist, fehlerhafte Geräte zu melden und in einem für den Anwender gebräuchlichen Engineeringtool zu visualisieren. IO-Geräte bzw. Controller meldeten einen Fehler über einen Alarm an eine übergeordnete Engeneeringstation. Manchmal sind diese Meldungen aber nur die Auswirkungen von nicht richtig funktionierenden Netzwerkkomponenten, die keinen Zugang zum eingesetzten Engineeringtool haben. Die Netzkomponenten konnten bis jetzt nicht oder nur über Umwege in das anlagenspezifische Engineeringtool eingebunden werden. Im Grunde war die Anlagendiagnose damit lü-ckenhaft. Waren die Netzwerkkomponenten nicht über E/A-Baugruppen in die Diagnose mit eingebunden, so begann für den Anlagenbetreiber eine aufwendige Suche nach dem Fehler. Profinet nutzt die Diagnosemechanismen der Automatisierungskomponenten (Controller, Feldgeräte, usw.) auch für Netzwerkkomponenten wie Switches. Somit können also auch Netzwerkprobleme ohne netzwerktechnische Spezialkenntnisse mit den bekannten Hilfsmitteln aus der Automatisierungstechnik genau lokalisiert werden. Viel stärker als das reine Erkennen von Fehlern im Engineeringsystem wiegt die Möglichkeit, Ereignisse aus dem Netzwerk genau wie Prozessereignisse zu verknüpfen und Aktionen anzustoßen. Eine Netzkomponente kann z.B. einen Link-Down eines Ports (Verbindungsabbruch) auf Grund einer Leitungsunterbrechung an den Controller melden. Der Controller kann im Anwenderprogramm auf diese Meldungen reagieren und die Anlage neu konfigurieren. Zuvor konnte der Anlagenführer nur erkennen, dass der Controller ein Endgerät nicht mehr erreichen konnte. Verschiedene Fehlermöglichkeiten kamen in Betracht: Das Endgerät ist defekt, eine Netzkomponente ist defekt oder eine Leitung zwischen Controller und Endgeräte ist beschädigt worden. Durch die Integration der Profinet-Device-Funktionalität auch in die Netzwerkkomponenten stehen der Netzkomponente alle bei Profinet standardisierten Melde-, Diagnose- und Projektierungswege zur Verfügung. Über ein dem Anlagenbetreiber geläufiges Engineeringtool kann er nun beim Aufbau der Anlage alle Projektierungsdaten der Netzkomponenten einstellen und wie für die Endgeräte auf die Baugruppen laden. Bei der Anlageninbetriebnahme lässt sich über das Engineeringtool weiterhin erkennen, ob ein 10 oder 100MBit-Link zwischen Netzkomponente und angeschlossenem Endgerät aufgebaut wurde, ob es sich um eine Full- oder Half-Duplex-Verbindung handelt und ob eine gekreuzte oder ungekreuzte Leitung gesteckt ist. Für den Fehlerfall kann weiterhin über das Engineeringtool die Meldemaske konfiguriert werden. Setzt nun eine Netzkomponente einen Fehleralarm ab, z.B. bei einem Link-Down an einem Port, so erhält der Anlagenbetreiber wieder über sein Engineeringtool eine Meldung, welche Netzkomponente die Meldung abgesetzt hat. Nach Abfrage des Baugruppenzustands der Netzkomponente kann genau der Port erkannt werden, an dem es zu einem Link-Down gekommen ist. Werden weitere Daten zur Fehlerdiagnose benötigt, so kann zur Darstellung weiterer Details direkt aus dem Engineeringtool auf die Web-Seiten der Netzkomponente zugegriffen werden. Über die Web-Seiten der Baugruppe können die Telegramme, die über einen fehlerhaften Port übertragen wurden, analysiert werden. Einfach zu erkennen ist, ob Telegramme mit CRC-Fehler, Kollisionen oder zu kurze Telegramme aufgetreten sind. Durch die Nutzung der über Profinet standardisierten Kommunikationswege sind die oben beschriebenen Diagnosemöglichkeiten z.B. über Step7 bei einem Profinet Switch Scalance X-200 bzw X-400 durchführbar. Der Anlagenbetreiber hat somit die Möglichkeit, mit einem ihm bekannten Engineeringtool sowohl die Anlage zu projektieren, Fehlermeldungen zu empfangen und bei Bedarf auch über das gleiche Tool die Anlage zu diagnostizieren. Das Zusammenspiel von standardisierten Projektier- und Diagnosewegen bei Profinet vermeidet somit den Aufbau zusätzlicher, in der Industrie bislang noch nicht verbreiteter bzw. getrennter Projektierungs- und Diagnosewege, die ggf. separate und leistungsfähige Rechner (z.B. Management Station) erfordern. Profinet bietet mit der integrierten, durchgehenden Projektierungs- und Diagnoselösung für Profinet-Endgeräte, -Controller und -Netzkomponenten ein enormes Ratiopotenzial, durch die der Anwender seine Betriebskosten reduzieren und die Anlagenverfügbarkeit auf Grund einfacher Fehlerlokalisierung deutlich erhöhen kann.
Siemens AG
