Im industriellen Umfeld gibt es Anforderungen an das Netzwerk, die für den Einsatz im Büro unerheblich sind. Dazu gehören rein praktische Gesichtspunkte, wie z.B. die sternförmige Verkabelung, die sowohl für industrielle Anlagen als auch für den Einsatz in Fahrzeugen nicht praktikabel ist. Eine lineare Topologie ist hierfür besser geeignet bzw. wegen der erwünschten höheren Ausfallsicherheit eine Ringtopologie mit Redundanz. Wird Ethernet als Feldbus zur Steuerung von Anlagen oder Fahrzeugen eingesetzt, ist außerdem das Zeitverhalten erheblich. Im industriellen Umfeld ist Echtzeitfähigkeit erwünscht, also definierte Antwortzeiten. Bild 1 zeigt das Umfeld und die Anforderungen. Über einen Feldbus empfängt eine Steuerungseinheit (Controller im linken Teil der Abbildung) Nachrichten von Messgebern (Sensoren) und steuert damit z.B. Antriebe (Aktuatoren). Die über den Bus geschickten Nachrichten unterliegen dabei statistischen Laufzeitschwankungen. Dieses Verhalten lässt sich z.B. als Poisson-Verteilung modellieren. Diese Verteilung beschreibt sinngemäß die mittlere Verweildauer von Leuten in einem Supermarkt. Bis zum Eintreffen einer Nachricht (bzw. bis zum Verlassen des Supermarktes) vergeht eine individuell unterschiedliche Zeit. Im Mittel kann man eine Antwortzeit ablesen, die jedoch Laufzeitschwankungen unterliegt. Welche Antwortzeiten gefordert sind, hängt vom Anwendungsfall ab. Für die Steuerung von Antrieben sind Antwortzeiten im Bereich einer Millisekunde erforderlich. Beispiele für Antwortzeiten im Industrial Ethernet Der Wert wird plausibel für Antriebe mit circa 3.000 Umdrehungen pro Minute, also 50 Umdrehungen pro Sekunde. Eine Umdrehung dauert in diesem Fall 20ms. Eine winkelabhängige Steuerung in Inkrementen von 18° erfordert 1ms Reaktionszeit. Für andere Geräte genügen unter Umständen 10ms, bei Bedienterminals an Anlagen oder Fahrzeugen sollte die Antwortzeit in der Größenordnung der menschlichen Reaktionszeit von circa 100ms liegen. Welche Antwortzeiten sich mit Ethernet als Feldbus erreichen lassen, hängt u.a. von der Größe und der Topologie des Netzes ab sowie von der Größe der Nachrichten (gemessen in Bytes). Ein Grund ist das Speichern und Weiterleiten der Nachrichten in jedem Switch. Deterministische bzw. garantierte Antwortzeiten kann Ethernet ohne weitere Vorgaben grundsätzlich nicht realisieren. Hierzu ist allerdings zu bemerken, dass die Sensoren, Controller und Aktuatoren selbst ebenfalls kein deterministisches Verhalten haben. In der Regel wird jedoch vom Feldbus gefordert, dass er z.B. Prozessdaten innerhalb einer vorgegebenen definierten Antwortzeit kommuniziert. Im industriellen Umfeld hat ein Feldbus außerdem unterschiedliche Verkehrsklassen zu bedienen: steuerungsrelevante Prozessdaten, Diagnose-Information und Status-Meldungen sowie sonstige Nachrichten. Definierte Antwortzeiten sind meist für die Prozessdaten erforderlich. Andere Nachrichten sind weniger bzw. nicht kritisch. Lösungsansätze für den industriellen Betrieb Für den industriellen Einsatz werden unterschiedliche Konzepte zur Realisierung der besonderen Anforderungen verfolgt. Die Lösungsansätze sind zum Teil evolutionär, also vereinbar mit der Entwicklung des IEEE802-Projektes, zum Teil kompatibel bzw. nicht kompatibel mit dieser Entwicklung. Die Behandlung unterschiedlicher Verkehrsklassen beispielsweise ist Teil der regulären Ethernet- und IP-Standards und wird u.a. für Telekommunikationsanwendungen benötigt. Unter dem Begriff \’Quality of Service\‘ werden sowohl auf Layer 2 (IEEE802.1p) als auch auf Layer 3 (DiffServ, nach dem RFC2474 und 2475 sowie einigen ergänzenden RFC) geeignete Methoden beschrieben. Das Funktionsprinzip ist in Bild 2 dargestellt und beruht auf der Klassifizierung von Nachrichten in unterschiedliche Kategorien in einem geeigneten Feld im Paketkopf (Ethernet bzw. IP-Header). Die unterschiedlichen Verkehrsklassen werden nun in jedem Verkehrsknoten (Switch oder Router) unterschiedlich behandelt. Eine Nachricht der Klasse mit höherem Rang wird dabei bevorzugt weitergeleitet. Das Verfahren entspricht den Warteschlangen am Check-in einer Fluglinie: Es gibt für jeden Flug (bzw. Port) Warteschlangen je Verkehrsklasse. Die oberste Klasse wird bevorzugt abgefertigt und darf als erste auf die Datenbahn. Dieses Verfahren sorgt dafür, dass in jedem Verkehrsknoten die Nachrichten gemäß ihrem Rang umsortiert und die erstrangigen Nachrichten bevorzugt an die Sende-Ports weitergeleitet werden. Eine definierte Antwortzeit ist damit allerdings nicht gegeben, da diese vom gesamten Verkehrsaufkommen abhängig ist. Die Menge an Prozessdaten in einer konkreten Anwendung ist allerdings bekannt, auch eine Zykluszeit für das Senden von Prozessdaten lässt sich vereinbaren und so das Verkehrsaufkommen an Prozessdaten regulieren. Wechselwirkung aufgrund der Nachrichten-Klassifizierung Es gibt eine Wechselwirkung der Klassen untereinander. Während eine Nachricht zweiter Klasse (Business-Klasse in Bild 2) gerade über den Port gesendet wird, muss die Nachricht der ersten Klasse (Senator-Klasse in Bild 2) warten. Die Wartezeit ist dabei abhängig von der Nachrichtenlänge und der Übertragungsrate. Die Länge eines Ethernet-Rahmens kann 64 bis 1.518Bytes betragen (bzw. 9.000 Bytes für Jumbo-Rahmen, IP-Pakete können maximal 64kBytes lang werden). Jumbo-Rahmen einkalkuliert, schwankt die Länge der Fahrzeuge auf der Datenbahn also um mehr als einen Faktor 100. Ein 64Byte kurzes Telegramm mit Prozessdaten höchster Priorität muss also unter Umständen warten, bis ein Jumbo-Rahmen mit 9.000Bytes Daten aus einer Kamera abgefertigt sind. Das sind mit einer Übertragungsrate von 100MBits/s immerhin 0,7ms. Je nach Anzahl der Knoten zwischen Sender und Empfänger können sich diese Effekte summieren. Die Übertragung der Nachricht von 64Byte durch Speichern und Senden hätte mit der gleichen Übertragungsrate nur 5µs gedauert. Hier liegt dann auch die Lösung der Echtzeitanforderung für Prozessdaten über die regulären Leistungsmerkmale des Klassenkonzeptes von Ethernet und IP (Quality of Service): In einem solchen Netz muss für Steuerungsaufgaben eine maximale Paketlänge vereinbart werden, die alle Sender einhalten. Bei einer Paketlänge von maximal 512Bytes wäre die Schwankung pro Knoten dann maximal 40µs. Die maximale Anzahl der Knoten ist durch die gewählte Netztopologie vorgegeben. Traditionelles Feldbus-Verfahren für Ethernet nutzen Ein anderer Lösungsansatz projiziert die gängigen Verfahren der traditionellen Feldbusse auf den Ethernet-basierenden Feldbus. Bei einem traditionellen Bus teilen sich alle Sender und Empfänger den Bus als gemeinsames Medium, eben wie Personen in einem Raum bzw. an einem Tisch sich das Medium für die akustische Übertragung teilen. In einem solchen Arrangement wird ein Moderator bzw. Bus-Master benötigt, der die Konversation steuert und die Teilnehmer gezielt abfragt. Der Moderator oder Master muss dabei selbst nichts mit der Steuerung zu tun haben, er regelt nur die Konversation. Bild 3 zeigt das Prinzip. Um den Prozessdaten eine höhere Aufmerksamkeit zu schenken, wird ein Zeitabschnitt nur für Prozessdaten reserviert (deterministischer Teil), ein weiterer Zeitabschnitt für alle übrigen Daten (asynchroner Teil). Diese Zeitabschnitte werden zyklisch wiederholt. Innerhalb des deterministischen Intervalls organsiert der Busmaster den Informationsfluss zwischen den Sendern und Empfängern der Prozessdaten. Anschließend folgt das Intervall für alle übrigen Daten ohne besondere Organisation. Während zwar alle Nachrichten in diesem Verfahren als reguläre Ethernet-Rahmen verteilt werden, benötigt der Zeitmultiplex der beiden Intervalle spezielle hierfür gebaute Ethernet-Switches. Insofern ist dieses Verfahren zwar kompatibel mit regulärem Ethernet-Verkehr, der auch über ein Feldbus-Segment innerhalb des asynchronen Zeitintervalls übertragen werden kann. Innerhalb des Feldbusses werden jedoch spezielle Ethernet-Switches benötigt, da Zeitmultiplex für reguläre Switches nicht üblich ist. Die Organisation der Prozessdaten selber wird auf Anwendungsebene geregelt und ist daher ohne Einfluss auf Layer 2 oder Layer 3. Alternativer Lösungsansatz mit vorgegebener Topologie Ein weiterer Lösungsansatz gibt die Topologie vor und packt Prozessdaten in ein gemeinsames Telegramm für alle Teilnehmer eines Netzabschnittes. Das Format des gemeinsamen Telegramms wird im Datenbereich (Payload-Bereich) des Ethernet-Rahmens definiert und ist daher ohne Einfluss auf den IEEE802 Ethernet-Header (Bild 4). Da das Telegramm mit den Prozessdaten Teil des Datenbereiches ist, kann jeder reguläre Ethernet-Switch die Prozessdaten weiter übertragen. Innerhalb des Feldbus-Abschnittes sind alle angeschlossenen Geräte über spezielle Bus-koppler in einer Kette angeordnet (einer sogenannten Daisy-Chain). Die Buskoppler geben den Ethernet-Rahmen mit dem Telegramm an den jeweils nächsten Buskoppler weiter. Während des Transportes durch die Kette entnehmen die Buskoppler bereits die für die jeweils angeschlossenen Geräte bestimmten Prozessdaten aus dem Telegramm bzw. schreiben Daten der angeschlossenen Geräte in das Telegramm. Am Ende der Kette wird das Telegramm dann wieder zurückgeschickt, dieses Mal ohne Zugriff auf die Prozessdaten. Wie in Bild 4 dargestellt, ähnelt das Verfahren einem Transportfahrzeug, das die Stationen im Prozess nacheinander abfährt, an jeder Station die dort subskribierten Informationen abliefert und die dort anfallenden Informationen einsammelt. Aus Sicht des Ethernet-Protokolls ergibt sich eine einfache lineare Struktur. Die Prozessdaten selbst stellen einen im Datenbereich eingebetteten Kanal dar. Da die Ethernet-Rahmen unverändert bleiben, lassen sich mit diesem Verfahren auch Baumstrukturen mit mehreren linearen Ästen realisieren. Auch dieser Lösungsansatz ist kompatibel mit IEEE802, benötigt jedoch innerhalb jeder Kette spezielle Buskoppler, die in Vorwärtsrichtung zwischen dem Speichern und Weiterleiten der Rahmen auf die Prozessdaten im Datenbereich zugreifen. Dieser Zugriff findet jedoch auf Anwendungsebene statt und ist ohne Einfluss auf Layer 2. In Rückwärtsrichtung werden Pakete regulär weiter geleitet (ohne Verarbeitung auf Anwendungsebene). Lineare Netzwerkstrukturen: geringer Aufwand Um verschiedene Netzsegmente bzw. Feldbus-Segmente miteinander zu verbinden, bieten lineare Strukturen den geringsten Aufwand an Verkabelung (etwa im Unterschied zu einer sternförmigen Verkabelung). Allerdings bietet eine lineare Vernetzung keinen Schutz vor einfachen Fehlern: Bei Ausfall eines einzelnen Links können alle dahinter liegenden Systeme nicht mehr erreicht werden. Daher wäre eine redundante Vernetzung wünschenswert. Mit geringem Aufwand ist eine solche Redundanz mit Schutz vor einzelnen Fehlern mithilfe einer ringförmigen Verkabelung erreichbar. Bild 5 zeigt das Prinzip. Die Knoten (Ethernet-Switches) sind ringförmig angeordnet und miteinander verbunden. Der Betrieb des Netzes ist dabei nicht ringförmig, sondern linear. Ringstrukturen möchte man im Betrieb wegen der Gefahr von Endlos-Schleifen vermeiden. Daher sind die Knoten im Betrieb linear miteinander verbunden, eine der Verbindungen ist eine Reserve-Verbindung (RPL: Ring Protection Link), die nicht für den Transport verwendet wird. Im Falle des Ausfalls einer Verbindung wird die Reserve aktiviert, wie in Bild 5 unten gezeigt. Alle Knoten sind nun wieder linear miteinander verbunden und in Betrieb. Die Umschaltung vom Fehlerfall bis zur Aktivierung der neuen Topologie muss natürlich im industriellen Umfeld rasch geschehen, wenn eine Unterbrechung der Anwendung vermieden werden soll. Typischerweise sind Umschaltzeiten von weniger als 500ms gefordert. Fehler erkennen, Reserve-Verbindungen aktivieren Um Fehler zu erkennen und die Reserve-Verbindung zu aktivieren, sind zusätzliche Funktionen und ein passendes Steuerprotokoll erforderlich. Einer der Switches übernimmt dabei die Bereitstellung der Reserve-Verbindung (er wird damit zum \’RPL Owner\‘). Um den Ring auf Fehler zu überprüfen, kann der Hüter der \’RPL-Owner\‘ Steuernachrichten in beiden Richtungen über den Ring schicken (auch über die ReserveVerbindung, die sonst keinen Verkehr transportiert). Kommen die Steuernachrichten nach Durchlauf des Ringes am jeweils gegenüberliegenden Port des Switches an, ist die Verbindung in Ordnung. Bei Unterbrechung des Ringes wird der Reservelink aktiviert und die Topologie umprogrammiert. Da die Nachrichten an die angeschlossenen Geräte nun andere Wege nehmen, müssen alle Switches im Ring die MAC-Adressen für den Weitertransport von Nachrichten im Ring neu lernen. Um den Einsatz von Switches unterschiedlicher Hersteller zu ermöglichen, ist ein standardisiertes Verfahren für den Mechanismus zur Überwachung des Ringes und zur Aktivierung der Reserve im Fehlerfall erforderlich.
Kontron S&T AG
