Nicht jede Echtzeit-Ethernet-Lösung hält, was sie verspricht

Es ist nicht ganz einfach, bei der Vielzahl der im Markt angebotenen und angepriesenen Echtzeit-Ethernet-Lösungen den Überblick zu behalten. Selbst Fachleute tun sich teilweise schwer, die genaue Funktionsweise und die daraus resultierende Charakteristik der verschiedenen Echtzeit-Ethernet-Lösungen umfassend zu bewerten und zu vergleichen. Für einen Anwender bedeutet dies, dass er die Konzepte genau analysieren muss und nicht nur Schlagworten und Powerpoint-Präsentationen Glauben schenken darf. Häufig wird nicht erläutert, wie Features im Detail funktionieren, welche Features nicht bzw. nur mit Einschränkungen unterstützt werden und wie viel Aufwand für eine Implementierung oder Projektierung hierfür erforderlich ist. Darüber hinaus werden einzelne Leistungsdaten nicht im Gesamtzusammenhang oder anhand optimierter Szenarien dargestellt. Letzten Endes kann ein objektiver Vergleich von Lösungen nur anhand konkreter Anwendungsszenarien durchgeführt werden. Sehr wichtig ist es, die grundsätzlichen Prinzipien und Arbeitsweisen der verschiedenen Echtzeit-Ethernet-Lösungen zu verstehen, um sich mit Sachverstand und mit gesundem Menschenverstand eine Meinung zu bilden. Wer die Wahl hat… Insgesamt zwölf Echtzeit-Ethernet-Lösungen werden voraussichtlich noch in diesem Jahr in der neuen Ausgabe der IEC61784/61158 Normenreihe standardisiert. Die dort beschriebenen Technologien haben gemeinsam, dass als Übertragungsphysik und Übertragungsprotokoll Ethernet IEEE 802.3 genutzt wird. Anwendungsgebiete dieser Technologien decken den gesamten Bereich der Fabrik- und Prozessautomatisierung ab. Die höchsten Anforderungen bezüglich Performance und Echtzeit werden dabei an Bussysteme gestellt, die in Motion Control Anwendungen eingesetzt werden. Mit Profinet IRT, Ethernet Powerlink, Ethercat, Ethernet/IP mit CIPsync und Sercos III treten gleich fünf Lösungen in den weltweiten Wettbewerb in dieser \’Königsklasse\‘ an. Ein oberflächlicher Blick auf die Lösungsansätze zeigt viele Gemeinsamkeiten auf, z.B. Übertragungsrate von 100Mbit/s, Jitter<1µs und TCP/IP Unterstützung. Wer jedoch tiefgründiger analysiert, entdeckt teilweise signifikante Unterschiede in den angewandten Verfahren, der Leistungsfähigkeit und der unterstützten Funktionen. Speziell bei softwareorientierten Lösungsansätzen stellt sich auch die Frage nach der Robustheit und der tatsächlichen Unabhängigkeit von produkt- und herstellerspezifischen Implementierungen. Übertragungsverfahren Grosse Unterschiede gibt es hinsichtlich des angewandten Übertragungsverfahrens und der Effizienz des Übertragungsprotokolles. Aus diesem Grunde sind trotz Verwendung der einheitlichen Geschwindigkeit von Fast-Ethernet (100MBit/s) die Nutzdatenraten (Netto-Übertragungsraten) der verschiedenen Technologien sehr unterschiedlich. Um eine hohe Performance zu erreichen, werden u.a. die folgenden Maßnahmen herangezogen: Optimale Nutzung der Bandbreite durch ein effizientes Übertragungsprotokoll, Reduzierung der Laufzeiten in den Netzwerken durch den Verzicht auf \'Standard\'-Switches und Verarbeitung der Echtzeit-Telegramme während des Durchlaufs, sowie Reduzierung von Laufzeitschwankungen mit Hilfe geeigneter Kompensationsverfahren. Nicht zu unterschätzen ist die Ausprägung des Synchronisationsverfahrens, das einfach und dennoch hochgenau arbeiten muss. Besonders effiziente Übertragungsprotokolle verwenden Sammeltelegramme basierend auf einem Zeitschlitz- (Bild 1a) oder einem Summenrahmenverfahren (Bild 1b). Die Anzahl an benötigten Ethernet-Telegrammen und somit auch der daraus resultierende Telegramm-Overhead werden auf ein Minimum reduziert. Von Vorteil sind diese Verfahren besonders bei einer großen Anzahl von Netzwerkknoten und einem eher geringen Umfang an Echtzeitdaten pro Netzwerkknoten. Werden hingegen Echtzeitdaten in einzelnen Telegrammen übertragen (Bild 1c), so entsteht ein ungünstiges Verhältnis von Ethernet-Overhead zum Nutzdatenumfang. Zudem werden - falls die Nutzdaten weniger als 46Bytes betragen - Telegramme mit Nullbytes (sog. Padding) aufgefüllt, um die Mindestlänge von 64Bytes zu erreichen. Dabei wird wertvolle Bandbreite verschenkt. Sammeltelegramme werden üblicherweise während des Knotendurchlaufs bearbeitet, d.h. Echtzeitdaten werden \'on-the-fly\' in das Telegramm geschrieben bzw. aus diesem ausgelesen. Einzeltelegramme werden hingegen von den jeweils adressierten Knoten empfangen und durchlaufen anschließend entsprechende Protokollstack, wodurch zusätzliche Laufzeiten entstehen. Noch ineffizienter sind die Übertragungsprotokolle, in denen über einen Polling-Mechanismus ein Master entsprechende Sendeberechtigungen vergibt bzw. Daten von den Slaves abfragt. Hier erhöhen sich die Laufzeiten signifikant und weiterer Protokoll-Overhead entsteht. Es ist nicht überraschend, dass bei Vertretern des letztgenannten Konzepts bereits heute die Flucht nach vorne angetreten wird und Gigabit Ethernet propagiert wird. Allerdings wird die Protokolleffizienz trotz der Bandbreitenerhöhung weiter verschlechtert. Direkte MAC-Adressierung versus \'Tunneln\' Bei Sercos III wird ein Kommunikationszyklus mit Hilfe einer Zeitsteuerung in zwei Kanäle unterteilt (Bild 1a). Im Echtzeit-Kanal werden die von Sercos III spezifizierten Sammeltelegramme als Broadcast (wie oben beschrieben) übertragen und \'on-the-fly\' bearbeitet. Im Nicht-Echtzeit-Kanal können dagegen Nicht-Echtzeit-Ethernet-Frames als Einzeltelegramme an beliebige Geräte des Netzwerkverbundes gesendet werden. Die Adressierung erfolgt direkt über die den Master- und Slavegeräten zugeordneten MAC-Adressen. Geräte können somit einzeln oder auch integriert in einen Netzwerkverbund direkt mit einer beliebigen Standard-Ethernet-Hardware (z.B. ein Notebook) über gängige Protokollstacks (z.B. TCP/IP) gekoppelt werden. Dieser Mechanismus arbeitet sowohl im Offline-Modus (d.h. ohne laufendes Sercos III Protokoll) als auch im Online-Betrieb (d.h. während des Sercos III Echtzeitbetriebs). Da die Sercos III-Hardware sicher stellt, dass der Echtzeit-Kanal nicht durch asynchrone Ethernet-Kommunikation gestört wird, können jegliche \'Nicht-Sercos III-Geräte\' ohne Zusatzhardware und ohne spezielle Softwaretreiber direkt an jeden freien Sercos III-Port angeschlossen werden. In dem Lösungsansatz nach Bild 1b werden Ethernet-Telegramme und damit auch Telegramme höherer Protokollschichten (z.B. TCP/IP) \'getunnelt\'. Tunneln heißt, dass Telegramme in ein unterlagertes Protokoll eingebettet werden. Slave-Geräte können somit erst dann über gängige Protokollstacks angesprochen werden, wenn das unterlagerte Echtzeit-Protokoll aufgesetzt und das \'Tunneln\' aktiviert wurde. Auch können Standard-Ethernet-Geräte, z.B. Notebooks, nicht direkt an Echtzeit-Ports angeschlossen werden. Eine Zusatzhardware ist erforderlich, um beispielsweise TCP/IP Kommunikation mit einem der Slave-Geräte zu betreiben. Wie schnell und wie einfach wird \'quer\' kommuniziert? Bei klassischen Master-Slave Konzepten werden Prozessdaten zwischen einem zentralen Master und den dezentralen Slaves ausgetauscht. Slaves werden dabei vom Master zyklisch abgefragt (\'gepollt\'). Ein Datenaustausch zwischen Slaves (\'Querverkehr\') erfolgt üblicherweise über den Master und dauert dadurch mindestens zwei Kommunikationszyklen. Auch bei den Echtzeit-Ethernet-Konzepten wird dieses Verfahren teilweise noch eingesetzt. Allerdings werden Multicast-Telegramme verwendet, so dass die enthaltenen Echtzeitdaten anderen Netzwerkteilnehmern unmittelbar zur Verfügung stehen. Interessant ist eine Analyse des Querverkehrs bei den beiden Vertretern der \'on-the-fly\' Verarbeitung. Wie bereits oben erläutert, werden Echtzeitdaten während des Knotendurchlaufs in das Telegramm geschrieben bzw. aus diesem ausgelesen. Um unabhängig von der physikalischen Position eines Slaves im Netzwerk einen direkten Datenaustausch zwischen beliebigen Slaves sicherzustellen, ist es erforderlich, dass die Echtzeit-Telegramme sowohl im Vorwärtspfad als auch im Rückwärtspfad bearbeitet werden (Bild 2). In diesem Falle können Daten direkt zwischen Slaves innerhalb eines Kommunikationszyklus ausgetauscht werden. Dies hat nicht nur den Vorteil, dass die Daten - auch bei höheren Zykluszeiten - immer innerhalb eines Kommunikationszyklus mit einer minimalen Verzögerungszeit zwischen Slaves übertragen werden können. Durch einheitliche Synchronisationszeitpunkte werden zudem die Sollwerte synchron und gleichzeitig gültig (sogenannte \'t3\'-Zeit), sowie die Istwerte netzwerkweit synchron und gleichzeitig erfasst (sogenannte \'t4\'-Zeit). Sercos III erreicht eine Synchronisationsgenauigkeit von <20ns und eine Gleichzeitigkeitsgenauigkeit von <100ns. Redundanz: Was dahinter steckt Die Verfügbarkeit von industriellen Netzwerken spielt eine zunehmend wichtige Rolle. Es gibt verschiedene Ansätze, die Redundanz in einem Netzwerk sicherzustellen, um den Betrieb bei Ausfall eines Teilnehmers oder im Falle eines Kabelbruchs sicherzustellen. Um den Verkabelungsaufwand gering zu halten, wird üblicherweise keine Medienredundanz verwendet, sondern ein Alternativpfad im Fehlerfall geschaltet (Bild 4). Hier kommen entweder proprietäre Konzepte oder genormte Verfahren wie Spanning Tree (STP, IEEE 802.1D) oder Rapid Spanning Tree (RSTP, IEEE 802.1w) zur Anwendung. Allerdings sind diese Verfahren für hochdynamische und hochgenaue Anwendungen nicht verwendbar, da die Rekonfigurationszeiten im Bereich von 0,5 bis 30 Sekunden liegen. Auch wenn masterseitig eine optimierte Umschaltlogik implementiert wird, bleibt zunächst beispielsweise ungeklärt, wie viele Kommunikationszyklen während der Rekonfiguration verloren gehen und wie die Synchronisation der beiden Linien erfolgt. Sercos III bedient sich der sogenannten Ring-Redundanz, um ein schnelles Umschalten im Fehlerfall sicherzustellen. Es verhält sich bei Verwendung einer Ringstruktur fehlertolerant gegenüber einem Kabelbruch oder Knotenausfällen. Die Kommunikationsfähigkeit bleibt im Fehlerfalle komplett erhalten, da sich der aktive Ring dabei in zwei Linien aufteilt. Die Echtzeitdaten werden bereits im Normalbetrieb redundant, d.h. auf zwei getrennten Wegen (sogenannter Primär- und Sekundärkanal), übertragen. Im Fehlerfalle schalten die unmittelbar an der Fehlerstelle lokalisierten Knoten unmittelbar von \'Weiterleiten\' auf \'Loopback\' um. Diese Umschaltung dauert höchstens 25µs, so dass maximal die Daten eines Kommunikationszyklus verloren gehen können. Dadurch dass die Redundanzerkennung in jedem Knoten in der Hardware vorliegt, ist das Verfahren einfach, schnell und sicher. Da die Echtzeitdatenverarbeitung in den Knoten bereits im Normalbetrieb redundant, d.h. in beide Übertragungsrichtungen erfolgt, ist keinerlei Rekonfiguration erforderlich. Auch die Möglichkeit des Querverkehrs bleibt im Redundanzfall erhalten. Lediglich Netzwerkknoten, die sich in unterschiedlichen Linien befinden, können nicht mehr auf direktem Wege miteinander kommunizieren. Doch auch hierfür wurde eine Lösung definiert: Der Master kopiert in diesem Falle die Querverkehrsdaten in das nächste ausgehende Telegramm der anderen Linie um und kennzeichnet diese Daten als \'um einen Zyklus\' verspätet. Das von Sercos III spezifizierte Redundanzverfahren ist unabhängig von der Anzahl der Teilnehmer und der Netzausdehnung. Sogar die Synchronisierung, die bei Sercos eine Genauigkeit von nur wenigen Nanosekunden erreicht, wird durch die Topologieumschaltung nicht beeinträchtigt. Das in der Hardware realisierte Synchronisierungsverfahren arbeitet sowohl in der Linien- als auch in der Ringtopologie und wird auch durch Topologieänderungen während des Betriebs nicht negativ beeinflusst. Dieses Redundanz-Verfahren erlaubt zudem das manuelle Auftrennen des Rings, um bestehende Geräte auszutauschen oder neue Geräte in das Netzwerk zu integrieren (\'Hot-Plugging\'). Dieses Verfahren ist an jeder Stelle des Rings möglich, nicht nur am Ende einer Linie. Erweiterbarkeit Auf der Basis des von Sercos III spezifizierten C2C-Profils für die Steuerungsquerkommunikation (C2C=Controller-to-Controller) können die oben beschrieben Verfahren (Querverkehr, Synchronisierung, Redundanz) kombiniert werden, um hierarchische, durchsynchronisierte und hochverfügbare Echtzeit-Netzwerke zu realisieren. Die Netzwerksegmente werden dabei nicht nur synchronisiert betrieben. Darüber hinaus können echtzeitkritische Daten zwischen allen Geräten im gesamten Automatisierungsverbund ausgetauscht werden. Zusammenfassung Anwender sind gezwungen, die vorliegenden Echtzeit-Ethernet Konzepte genau zu analysieren und an den eigenen Anforderungen zu spiegeln. Insbesondere die Bewertung, welchen Nutzen eine bestimmte Echtzeit-Ethernet-Lösung tatsächlich bringt und wie einfach die Umsetzung erfolgt, ist dabei wichtig. Bei vielen Lösungsansätzen können wichtige Kommunikations- und Synchronisierungsfunktionen nur mit zusätzlichem Hardware- und Softwareaufwand oder einer anspruchsvollen Netzwerkprojektierung realisiert werden. Oftmals wird dabei ein höherer Grad an Flexibilität mit signifikanten Nachteilen erkauft: Reduzierte Robustheit, höhere Abhängigkeit von produkt- und herstellerspezifischen Implementierungen und insgesamt höhere Gesamtkomplexität. Mit einer Fülle an Begriffen versuchen die Vertreter der verschiedenen Echtzeit-Ethernet Bussysteme neue Anhänger zu mobilisieren und sich im Markt zu etablieren: Redundanz, Multi-Master, Controller-to-Controller, Querverkehr, TCP/IP, Gigabit-Ethernet, usw. Was auf Powerpoint-Folien zunächst einfach und viel versprechend aussieht, führt in der Realität zu manchem \'Aha-Effekt\'. Weniger \'kreatives Marketing\', dafür mehr Fakten wären wünschenswert, um die von vielen Anwendern geforderte Transparenz zu schaffen.