Die Definition und Behandlung von Verkehrsklassen mit den nativen Methoden von Ethernet und IP (Bild 1) findet Gefallen im nordamerikanischen Raum und ist unter dem Namen Ethernet/IP (für Ethernet Industrial Protocol, abgekürzt auch EIP) spezifiziert. In solchen Implementierungen sind keine speziellen Voraussetzungen an die Ethernet-Switches erforderlich. Es sind jedoch Vorgaben über die Topologie des Netzes sowie gegebenenfalls über die maximalen Nachrichtenlängen nötig, um garantierte Antwortzeiten für die Prozessdaten zu erreichen. Ethernet/IP wurde von der Open DeviceNet Vendor Association (ODVA) entwicklet, mit Beteiligung der ControlNet International (CI), sowie Industrial Ethernet Association (IEA). Kommunikation per Profinet Eine Lösung aus dem heimischen Raum ist Profinet. Profinet wurde durch den Verband Profibus & Profinet International (PI) definiert und ist Bestandteil der Normen IEC61158 und IEC61784-2. Profinet überträgt Prozessdaten sowie allgemeine Daten in der Industrieautomatisierung und Informationsverarbeitung über die gleiche Leitung. Für die Prozessdaten reserviert Profinet im einfachsten Fall eine eigene Verkehrsklasse (RT benannt für Real-Time Steuerung), die bevorzugt behandelt wird. In diesem Fall entspricht das Konzept der in Bild 1 gezeigten Lösung. Für strengere Anforderungen wendet Profinet ein Zeitmultiplexverfahren an und reserviert ein zyklisches Zeitintervall für Prozessdaten. Der strengere Fall wird als isochrone Echtzeitsteuerung bezeichnet (IRT für Isochronous Real-Time, Bild 2). Zur Unterstützung des Zeitmultiplexes sind im IRT-fähigen Feldbussegment spezielle Ethernet-Switches erforderlich. Regulärer Verkehr kann im Zeitintervall für Standard-Nachrichten ebenfalls über den Feldbus geführt werden. Bild 3 zeigt, dass Profinet auch verzweigte Topologien unterstützt, sowie die Anbindung traditioneller Feldbusse wie CANopen oder Profibus. Die Switches können auch in Geräte bzw. Feldbus-Koppler integriert werden. Wie bei allen Ethernet-basierten Lösungen sind die realisierbaren Zykluszeiten und Antwortzeiten abhängig von der Größe und Topologie des Netzes. Da die Feldbusse Teil der industriellen Anlagen sind, ist eine Netzplanung jedoch immer möglich. Strukturen für Ethercat Für die Lösung Ethercat haben sich Hersteller und Anwender in der Ethercat Technology Group organisiert und entwickeln die Technologie weiter. Ethercat ist als IEC-Norm integriert in die internationalen Standards für Feldbusse IEC61158 und 61784-2. Ethercat nutzt die serielle Anbindung von Anlagen und Antrieben an die Steuerung und fasst alle Prozessdaten für einen solchen Abschnitt in einem Telegramm zusammen. Dieses wird in den Datenbereich eines Ethernet-Rahmens gepackt und durch die Kette geschickt. Bild 3 zeigt die Kette mit dem Ethercat-Master als Quelle des Telegramms sowie die in Serie angeschalteten Ethercat-Buskoppler. Der Master benötigt nur eine reguläre Netzwerkschnittstelle, wie sie jeder Rechner oder Industriecontroller besitzt. Die Elemente der Kette benötigen für das Abgreifen und Einsetzen der für sie bestimmten Prozessdaten aus dem Telegramm einen speziellen Baustein, der dieses Verfahren in Hardware unterstützt. Wie in Bild 3 unten gezeigt, findet dieser Datenzugriff im Vorwärtspfad noch während des Weiterleitens des Ethernet-Rahmens statt. In der Rückwärtsrichtung findet keine spezielle Behandlung mehr statt, der Ethernet-Rahmen wird regulär weiter geleitet. Das letzte Glied in der Kette schickt das von allen Elementen der Kette manipulierte Telegramm auf dem Rückwärtspfad an den Controller zurück. Wegen der Zusammenfassung der Prozessdaten einer kompletten Kette von Geräten in einem einzigen Telegramm arbeitet Ethercat in einer linearen Topologie sehr effektiv. Ethercat unterstützt auch Baumstrukturen sowie die Anbindung traditioneller Feldbusse (Bild 5). Powerlink rein evolutionär Ethernet Powerlink ist im Unterschied zu Profinet und Ethercat rein evolutionär, benötigt also ähnlich wie Ethernet/IP keine spezielle Hardware oder Bustopologie. Auch Ethernet Powerlink verwendet einen orchestrierten Bus mit deterministischer Phase, in der ein Bus-Master die Geräte zyklisch abfragt, sowie eine asynchrone Phase, in der beliebige Ethernet-Rahmen gesendet werden können. Allerderdings setzt Ethernet Powerlink hierzu keinen speziellen Zeitmultiplex voraus. Die Nachrichtentypen für den zyklischen und asynchronen Betrieb sind innerhalb der Nutzdaten des regulären Ethernet-Rahmens untergebracht (Bild 4). Für den zyklischen Teil sind als Nachrichtentypen SoC (Start of Cycle), sowie Pooling Requests und Polling Responses definiert. Der Nachrichtentyp SoA (Start of Asynchronous) beendet den zyklischen Teil und lässt Ethernet-Verkehr außerhalb der zeitkritischen Prozessdaten zu. Alle Nachrichten werden als reguläre Ethernet-Rahmen verschickt. Nachrichten für den Zyklusstart, sowie Polling-Responses können als Multicast-Nachrichten verschickt werden, wodurch mehrere Powerlink-Geräte Prozessdaten mithören können. Ethernet Powerlink ist ein Protokoll der Ethernet Powerlink Standardization Group (EPSG) und wurde in die Normen IEC61784-2 (Kommunikationsprofile) und IEC61158 (Feldbusse) übernommen. Eine wichtige Voraussetzung für alle Steuerungsaufgaben ist die zeitliche Synchronisation aller Rechner und Geräte. In Computernetzen werden die Uhren der Systeme üblicherweise durch ein Network Time Protocol (NTP, RFC 5905) gestellt, damit Kalender und Dateisysteme synchron laufen. Für Steuerungsaufgaben reicht die Genauigkeit aber nicht aus, hier ist eine Ganggenauigkeit mindestens im Bereich von Mikrosekunden gefordert. Hierfür wird ein Protokoll mit wesentlich höherer Präzision verwendet, das Precision Time Protocol nach dem Standard IEEE1588. Uhrensynchronisation Das Funktionsprinzip der Uhrensynchronisation in zwei Systemen beruht auf dem Versenden von Nachrichten mit Zeitstempel, mit deren Hilfe Laufzeiten und Gangunterschiede gemessen werden können. Die Uhren in beiden Systemen haben einen Gangunterschied (Offset), zwischen dem Absenden und Eintreffen einer Nachricht besteht ein Laufzeitunterschied (Delay). Um die beiden Parameter Gangunterschied und Laufzeit zu ermitteln, ist das Senden und Empfangen zweier Nachrichten mit Zeitstempel erforderlich. System 1 (Master) schickt eine Nachricht mit Zeitstempel seiner Uhr an System 2 (Slave). System 2 antwortet mit einer Nachricht, die die in System 2 gemessene Empfangszeit der ersten Nachricht enthält. System 1 (Master) schickt dann noch den Zeitstempel mit der gemessenen Empfangszeit dieser Nachricht an System 2 (Slave), damit alle Messwerte in beiden Systemen vorliegen. Der Zeitunterschied zwischen den Zeitstempeln der ersten Nachricht enthält der Laufzeit der Nachricht plus den Gangunterschied der Uhren. Der Zeitunterschied zwischen den Zeitstempeln der zweiten empfangenen Nachricht enthält die Differenz aus der Laufzeit minus den Gangunterschied. Die Zeitstempel liegen in beiden Systemen vor. Somit kann System 2 seinen Gangunterschied errechnen und seine Uhr nach der Uhr von System 1 stellen. Das Precision Time Protokoll gemäß IEEE1588 ist in allen genannten Feldbusstandards implementiert. Da die Zeitstempel präzise sein müssen, lassen sie sich nicht durch eine Anwendungssoftware erzeugen, da sich in diesem Fall zu große Laufzeitschwankungen durch den Scheduler des Betriebssystems ergeben würden. Die Zeitstempel erfordern daher Hardwareunterstützung und werden in der Netzwerksschnittstelle erzeugt, also im Netzwerk-Chip beziehungsweise im Ethernet-Switch. Ringtopologien sind in der Telekommunikation nicht unüblich und dort auch für Ethernet definiert, beispielsweise durch die ITU-T G.8031 Recommendation (Ethernet Ring Protection Switching). Im industriellen Umfeld verbreitet ist jedoch ein anderer Standard: MRP, das Media Redundanz Protokoll, spezifiziert in der IEC-Norm 62439. MRP arbeitet nach dem im vergangenen Abschnitt beschriebenen Prinzip. Ein Switch übernimmt die Funktion des Redundanzmanagers, überprüft die Durchgängigkeit des Ringes und aktiviert den redundanten Pfad im Fehlerfall. Dabei sind möglichst kurze Umschaltzeiten erforderlich, die mit den herkömmlichen Spanning-Tree-Protokollen der IEEE802.1 nicht zu erzielen sind. MRP ist hierbei völlig kompatibel zu IEEE802.3 und IEEE802.1 und erweitert die Spanning Tree Protokolle um ein weiteres Verfahren. Die Mechanismen zum Löschen der Adresstabellen in den Switchen sowie der Status der Ports während der Umschaltung der Topologie sind die gleichen wie im Rapid Spanning-Tree-Protokoll (RSTP). MRP garantiert Umschaltzeiten von 200 Millisekunden, abhängig von der Netztopologie. MRP lässt sich in allen in IEC61158-2 definierten Feldbussen einsetzen. Einsatz in Flugzeugen & Zügen Auch Flugzeuge und Bahnfahrzeuge werden seit einiger Zeit über Draht, bzw. über Feldbusse gesteuert. Auch in diesem Milieu findet Ethernet als Feldbus Verbreitung. Die Anforderungen bezüglich des Echtzeitverhaltens sind vergleichbar mit der Industrieautomatisierung. Die Anforderungen an die Fehlertoleranz sind bei Bahnfahrzeugen ebenfalls vergleichbar und lassen sich durch Ringredundanz lösen. Bei Flugzeugen sind die Anforderungen an die Fehlertoleranz jedoch deutlich höher, da auch im Fehlerfall weiter geflogen werden muss. Da im Betrieb jedoch keine Geräte ergänzt werden, lässt sich die Netztopologie fixieren und ermöglicht eine statische Konfiguration. Bei Bahnfahrzeugen ist die Netztopologie hingegen flexibel, da im Betrieb Wagen oder Zugabschnitte ergänzt werden können, bzw. sich die Fahrtrichtung und somit der Führerstand an einem Kopfbahnhof ändern kann. Für den Betrieb in Flugzeugen wurde von der Flugzeugindustrie AFDX (für Avoinics Full-Duplex Switched Ethernet) spezifiziert und als ARINC664-Standard der AEEC (Airlines Electronic Engineering Commitee) veröffentlicht. AFDX soll den bisherigen Feldbus nach dem ARINC 429 Standard für ADN (Aircraft Data Networks) ablösen. AFDX definiert Endsysteme und Switches und unterstützt beliebige Netztopologien (Bild 4) oben gezeigt. Dabei wird das Netz rein statisch fest konfiguriert: Es findet kein Lernen von MAC-Adressen statt, es gibt keine dynamischen Erweiterungen, die Wegeführung ist deterministisch. Im Detail arbeitet AFDX auch nicht mit Adressierung durch MAC-Adressen, sondern benutzt die Adressfelder zur Definition von virtuellen Links (VL) für alle Kommunikationsbeziehungen zwischen den Endgeräten. Die Endgeräte können eine Flusskontrolle für den Verkehr in den virtuellen Links durchführen. AFDX arbeitet wegen der hohen Anforderungen die Fehlerrate mit vollständig redundanten Datenpfaden. Die Bezeichnung Full-Duplex im Namen bezieht sich auf diese Betriebsart (nicht auf den Duplex-Betrieb der Daten auf der einzelnen Leitung). Wie im unteren Teil von Bild 4 gezeigt werden die Netzwerke komplett dupliziert. Jedes Endsystem schickt einen Ethernet-Frame parallel über beide Netzwerke A und B. Die Ethernet-Switches innerhalb der Netzwerke brauchen daher nichts von Redundanz zu wissen. Das Endgerät an der Zieladresse empfängt Daten auf beiden Leitungen. Sollte eine Nachricht verloren gehen, bzw. später eintreffen als auf der Nachbarleitung, bzw. fehlerhaft sein, was sich an der Prüfsumme (CRC) erkennen lässt, wählt das Endgerät die Nachricht auf der jeweils anderen Leitung aus. Auf diese Weise gibt es keinen Umschaltmechanismus oder eine Neudefinition der Netztopologie nach einem Fehlerfall. Einzelfehler werden sofort korrigiert, praktisch ohne Einfluss auf die Latenzzeit. Kommunikation im Zug Für Bahnfahrzeuge gibt es ebenfalls einen Feldbus unter der Bezeichnung TCN für Train Communication Network, der als IEC-Norm 61375-1 von einem internationalen Konsortium der Bahnhersteller standardisiert ist. Dieser Feldbus ist hierarchisch aufgebaut und besteht aus der Vernetzung von Zugabschnitten (WTB, Wire Train Bus), sowie dem Bus innerhalb eines Zugabschnittes (MVB, Multifunction Vehicle Bus). Die Spezifikation eines Ethernet basierenden Nachfolgers ist derzeit in einer Arbeitsgruppe des IEC in Arbeit und soll als IEC-Norm 61375-3-4 (Ethernet Consist Network) und 61375-2-5 (Ethernet Train Backbone) publiziert werden. Bild 5 zeigt die Struktur. Die hierarchische Struktur des Vorgängerstandards IEC61375-1 wurde übernommen: innerhalb eines Zugabschnittes gibt ein sogenanntes Ethernet-Consist-Netzwerk, das Endgeräte (End Devices ED) mithilfe von Consist Switches (CS) verbindet. Da ein Zug aus mehreren Zugabschnitten bestehen kann, werden die Zugabschnitte über Ethernet Train Backbone Nodes (ETBN) miteinander verbunden. Die Art der Netztopologie innerhalb eines Zugabschnitts ist nicht vorgeschrieben. In aller Regel wird man hierfür einen Ring mit der bereits erläuterten Ringredundanz mithilfe des MRP-Protokolls verwenden. Die Anforderungen an Echtzeit und Fehlertoleranz sind hier vergleichbar mit denen im industriellen Umfeld. Der ETBN kann pro Zugabschnitt redundant vorhanden sein. Die Verbindung zwischen den Zugabschnitten ist ebenfalls redundant ausgeführt durch doppelte Leitungsführung, die beispielsweise mit Link-Aggregation betrieben werden, sofern die Fehlertoleranz diesen Betrieb erlaubt. Die Consist Switches stellen reine Layer-2-Switches dar, unterstützen aber zur Abgrenzung der Prozessdaten von den übrigen Informationen (wie beispielsweise Messwerte, Ansagen oder Kamerabilder) unterschiedliche Verkehrsklassen nach den nativen Ethernet Verfahren. Wie bei AFDX kann auch hier das Konzept und das Datenmodell des Vorgängerbusses übernommen werden und wird auf Anwendungsebene realisiert. Eine besondere Rolle spielt bei TCN der ETBN (Ethernet Train Backbone Node). Im fahrenden Betriebszustand spielt er die Rolle eines Routers, der zwischen den Zugabschnitten auf Layer-3-Verbindungen herstellt. Hierzu können auch lokale Adressen innerhalb der Zugabschnitte verwendet werden die mithilfe von Network Address Translation übersetzt werden. Die Adressvergabe innerhalb der Zugabschnitte ist dynamisch und erfolgt per DHCP, wobei der DHCP-Server ebenfalls auf dem ETBN implementiert ist. Bei Bahnfahrzeugen kann ein Zugabschnitt ergänzt oder entfernt werden bzw. die Fahrtrichtung ändert sich. Bei einer solchen Änderung ermitteln die ETBN die neue Topologie und nummerieren alle Zugabschnitte in der korrekten Reihenfolge durch. Solche Informationen sind wichtig, da der Fahrzeugführer beispielsweise bei einem Halt alle Türen auf der richtigen Seite frei geben muss. Die Konfiguration innerhalb eines Zugabschnittes erfolgt mithilfe von URIs (Uniform Resource Identifiers), wobei ein Domain Name Server ebenfalls auf dem ETBN implementiert ist.
Thematik: Allgemein
Kontron S&T AG
