EtherCAT – der Ethernet-Feldbus

EtherCAT ist Industrial Ethernet und nutzt Standard-Frames sowie die physikalischen Schichten aus dem Ethernet-Standard IEEE 802.3. Für die Nutzung eines Ethernet-basierten Kommunikationssystems in der Automatisierungstechnik gibt es gegenüber der IT- und Office-Welt weitere Anforderungen:

• Harte Echtzeit mit deterministischen Antwortzeiten wird benötigt.
• In der Regel sind in den Anlagen viele Teilnehmer vorhanden, die jeweils nur wenige zyklische Prozessdaten besitzen.
• Die Feldbussysteme werden nicht von IT-Administratoren in Betrieb genommen und gewartet.

Diese Anforderungen schließen die Nutzung eines Standard-Ethernet-Netzwerks innerhalb der Feldebene praktisch aus. Wird für jeden Teilnehmer ein individuelles Ethernet-Telegramm genutzt, dann sinkt bei wenigen Byte zyklischer Prozessdaten die effektive Datenrate erheblich: Das kürzeste Ethernet-Telegramm hat eine Länge von 84 Byte (inkl. Inter Frame Gap), von denen bis zu 46 Byte für Nutzdaten verwendet werden können.

Wenn beispielsweise ein Antrieb 4 Byte Prozessdaten für die aktuelle Position und eine Statusinformation versendet und ebenfalls 4 Byte Daten für die Zielposition und eine Control-Information empfängt, sinkt die Nutzdatenrate für die beiden Telegramme auf 4/84 = 4,8%. Hinzu kommt in der Regel eine Reaktionszeit im Antrieb, um durch den Empfang der Sollwerte das Senden der Istwerte auszulösen. Von der 100-MBit/s-Datenrate bleibt dann nicht viel übrig. Protokoll-Stacks, wie sie in der IT-Welt für das Routing (IP) und den Verbindungsaufbau (TCP) verwendet werden, bedeuten einen zusätzlichen Overhead in den Teilnehmern und bedingen durch die Stack-Laufzeiten weitere Verzögerungen. MAC- und IP-Adressen, SNMP, IGMP-Snooping, Router und Switche zu managen, ist nicht jedermanns Sache.

EtherCAT umgeht die Nachteile von Ethernet durch das besonders performante Funktionsprinzip: Ein Frame reicht in der Regel aus, um in allen Teilnehmern die Ausgangsinformationen zu aktualisieren und mit dem gleichen Frame die Eingangsinformationen für die Steuerung einzulesen. Das vom EtherCAT-Master ausgesandte Telegramm durchläuft alle Teilnehmer. Jeder EtherCAT-Slave liest „on the fly“ die an ihn adressierten Ausgangsdaten und legt seine Eingangsdaten in den weitergeleiteten Frame. Das Telegramm wird nur durch Hardware-Durchlaufzeiten verzögert. Der letzte Teilnehmer eines Segments (oder Abzweigs) erkennt einen offenen Port und sendet das Telegramm zum Master zurück – hierbei wird die Vollduplex-Eigenschaft der Ethernet-Physik ausgenutzt. Die maximale Nutzdatenrate eines Telegramms liegt dadurch bei über 90%, und die theoretische effektive Datenrate durch Ausnutzung der Full-Duplex-Eigenschaft sogar bei über 100 MBit/s (> 90% von zweimal 100 MBit/s). Der EtherCAT-Master ist der einzige Teilnehmer im Segment, der aktiv einen EtherCAT-Frame versenden darf; alle anderen Teilnehmer leiten die Frames nur weiter. Dies vermeidet unvorhersehbare Verzögerungen und garantiert die Echtzeitfähigkeit. Der Master nutzt einen Standard-Ethernet-Medium-Access-Controller (MAC) ohne einen zusätzlichen Kommunikationsprozessor. Damit kann ein Master auf jeder Hardware-Plattform installiert werden, die einen Ethernet-Port zur Verfügung stellt. Das verwendete Echtzeit-Betriebssystem oder die Applikationssoftware sind dabei unerheblich. Die EtherCAT-Slaves nutzen einen EtherCAT Slave Controller (ESC) für die Verarbeitung „on-the-fly“. Die Verarbeitung erfolgt also vollkommen in Hardware, wodurch die Performance des Netzwerks berechenbar wird und nicht von der Implementierung der einzelnen Slaves abhängt.

EtherCAT fügt seine Daten direkt in die Standard-Ethernet-Frames ein. Dank der Optimierung für kurzzyklische Prozessdaten, kann auf die Verwendung von belastenden Protokoll-Stacks, wie z. B. TCP/IP oder UDP/IP, verzichtet werden. Die Ethernet-IT-Kommunikation zwischen den Teilnehmern kann optional parallel über einen Mailbox-Kanal getunnelt werden, ohne dabei den Echtzeitverkehr zu beeinträchtigen. Das EtherCAT-Frame enthält ein oder mehrere Datagramme. Im Datagramm-Header wird festgelegt, welchen Zugriff der Master im Netzwerk durchführen möchte:

• Lesen, Schreiben, Lesen und Schreiben
• Der Zugriff auf einen bestimmten Slave durch die direkte Adressierung oder der direkte Zugriff auf viele Slaves erfolgt durch eine logische Adressierung (implizite Adressierung).

Die logische Adressierung wird für den zyklischen Austausch der Prozessdaten verwendet. Jedes Datagramm adressiert einen bestimmten Teil des Prozessabbilds im EtherCAT-Segment; hierfür steht ein 4-GByte-Adressraum zur Verfügung. Jeder Slave bekommt beim Hochlauf des Netzwerks eine oder mehrere Adressen in diesem Adressraum zugewiesen. Indem mehrere Knoten Adressen im gleichen Bereich erhalten, können diese über ein einziges Datagramm angesprochen werden.

Da die Information über den gewünschten Datenzugriff vollständig in den Datagrammen enthalten ist, kann der Master die Frames variabel gestalten und so entscheiden, wann er auf welche Daten zugreift. Er kann diese zum Beispiel nutzen, um mit kurzen Zykluszeiten die Antriebe im System zu aktualisieren und gleichzeitig mit einer längeren Zykluszeit die I/Os abzufragen. Ein fester Frame-Aufbau ist nicht vorgeschrieben.

Neben der logischen Adressierung hat der Master die Möglichkeit, ein Gerät anhand seiner Position im Netzwerk zu adressieren. Diese wird verwendet, um die Topologie des Netzwerks beim Aufstarten auszulesen und mit einer erwarteten Konfiguration abzugleichen. Nachdem die Konfiguration überprüft wurde, kann der Master jedem Knoten eine konfigurierte Knotenadresse zuweisen und ihn von da an über diese fixe Knotenadresse erreichen. Damit ist ein gezielter Gerätezugriff auch dann möglich, wenn sich die Topologie im laufenden Betrieb ändert, zum Beispiel durch Hot-Connect-Gruppen. Zusätzlich zu den zyklischen Daten können weitere Datagramme eingefügt werden, um eine asynchrone oder bedarfsgesteuerte Kommunikation zu ermöglichen.

Linie, Baum, Stern, Daisy-Chain: EtherCAT unterstützt nahezu alle Topologievarianten. Eine reine Bus- bzw. Linientopologie aus vielen Hunderten Teilnehmern ist mit EtherCAT möglich; und das ohne Einschränkungen, die sich bei anderen Systemen z. B. aus der Kaskadierung von Switches oder Hubs ergeben.

Für die Systemverdrahtung ist aber auch besonders die Kombination aus Linie und Abzweigen oder Stichleitungen von Vorteil: Die hierfür benötigten Abzweigports sind auf vielen I/O-Modulen direkt integriert – Switches oder andere aktive Infrastrukturkomponenten werden nicht benötigt. Natürlich kann auch die für Ethernet klassische Sterntopologie genutzt werden.

Modulare Maschinen oder Werkzeugwechsler benötigen ein Zu- und Abschalten von Netzwerksegmenten oder einzelnen Teilnehmern im laufenden Betrieb. In den EtherCAT Slave Controllern ist die Grundlage für diese Hot-Connect-Funktion bereits enthalten: Wird eine Partnerstation abgezogen, dann wird der Port automatisch geschlossen, sodass das verbleibende Netzwerk störungsfrei weiterarbeiten kann. Sehr kurze Detektionszeiten < 15 μs gewährleisten dabei eine stoßfreie Umschaltung.

Eine hohe Flexibilität bietet auch die Varianz der möglichen Kabel. Kostengünstige Industrial-Ethernet-Kabel können für den 100BASE-TX-Mode mit einer Länge von 100 m zwischen zwei Teilnehmern verwendet werden. Lichtleiter können ebenfalls genutzt werden, zum Beispiel, um zwischen zwei Teilnehmern Strecken von über 100 m zu überwinden. Darüber hinaus ermöglicht die Protokollerweiterung EtherCAT P die Übertragung von Daten und Strom auf nur einem einzigen Kabel. Diese Option erlaubt den Anschluss von Geräten, beispielsweise Sensoren, mit nur einer Leitung. Die komplette Bandbreite an Ethernet-Verkabelung steht also auch für EtherCAT zur Verfügung.

Da bei EtherCAT bis zu 65.535 Teilnehmer in einem Segment angeschlossen werden können, ist die Netzwerkausdehnung nahezu unbegrenzt. Dank der praktisch unbeschränkten Teilnehmerzahl können modulare Geräte wie z. B. anreihbare I/O-Stationen so ausgeprägt werden, dass jedes Modul ein eigener EtherCAT-Teilnehmer ist. Damit entfällt der sonst erforderliche lokale Erweiterungsbus; die EtherCAT Performance erreicht jedes Modul direkt und ohne Verzögerung, da das Gateway in der Kopfstation entfällt

Der exakten Synchronisierung kommt immer dann eine besondere Bedeutung zu, wenn räumlich verteilte Prozesse gleichzeitige Aktionen erfordern. Das kann z. B. in Applikationen der Fall sein, bei denen mehrere Servoachsen gleichzeitig koordinierte Bewegungen ausführen. Wie unten näher erläutert, ist aber auch zur Regelung einer einzigen Achse eine exakte Zeitbasis wichtig.

Im Gegensatz zur vollsynchronen Kommunikation, deren Qualität bei Kommunikationsstörungen sofort leidet, verfügen verteilte abgeglichene Uhren über ein hohes Maß an Toleranz gegenüber möglichen störungsbedingten Verzögerungen im Kommunikationssystem. Daher basiert die EtherCAT-Lösung zur Synchronisierung von Teilnehmern auf dem Mechanismus der verteilten Uhren, genannt Distributed Clocks (DC). Der Abgleich der Uhren in den Teilnehmern erfolgt vollständig in Hardware. Hierfür wird die Uhrzeit des ersten synchron arbeitenden Slave-Geräts zyklisch an alle anderen Uhren im System verteilt. Die Slave-Uhren können sich dadurch exakt auf diese Referenzuhr einregeln. Der resultierende Jitter im System ist signifikant kleiner als 1 μs; meist liegt er im zweistelligen Nanosekunden-Bereich.

Da die Uhrzeitinformation der Referenzuhr durch die Laufzeitverzögerung auf dem Kabel und in den Teilnehmern erst verspätet bei den Slave-Uhren empfangen wird, ist eine Messung und ein Ausgleich dieser Verzögerung für jeden Slave notwendig, um neben der physikalischen Synchronität auch Gleichzeitigkeit zu erreichen. Auch diese Gleichzeitigkeit ist signifikant kleiner als 1 μs.

Wenn alle Teilnehmer die gleiche Zeitinformation besitzen, dann können in den Teilnehmern Ausgänge gleichzeitig gesetzt werden und Eingangssignale mit einem hochgenauen Zeitstempel versehen werden. Bei Motion-Control-Anwendungen ist neben Synchronität und Gleichzeitigkeit auch die Zyklustreue entscheidend: Typischerweise wird hier die Geschwindigkeit aus der zyklisch gemessenen Position ermittelt. Besonders bei kurzen Zykluszeiten macht sich bereits ein kleiner Jitter in der Erfassung der Position in Form eines großen Sprungs in der Geschwindigkeit bemerkbar. Wenn die Positionserfassung aber nicht mit dem Empfang des Telegramms erfolgt, sondern äquidistant aufgrund der Distributed Clock, wird eine wesentlich höhere Genauigkeit erreicht. Die Verwendung der Distributed Clocks entlastet auch den Master: Das Versenden eines EtherCAT-Telegramms wird in einem Bereich > 1 μs jittern, da der Master-Stack in Software realisiert ist und eine Standard-Ethernet-Schnittstelle verwendet wird. Da die zum Sendezeitpunkt des Telegramms aus der Referenzuhr gelesene Uhrzeit verwendet wird, um die Slave-Uhren nachzustellen, ist der absolute Sendezeitpunkt unerheblich und darf auch jittern. Der EtherCAT-Master muss nur noch dafür sorgen, dass das EtherCAT-Telegramm früh genug verschickt wird, bevor in den Slaves das DC-Signal den Trigger zum Setzen der Ausgänge gibt.

Die Erfahrungen mit den klassischen Feldbussystemen zeigen, dass die Verfügbarkeit und Inbetriebnahmezeit einer Anlage wesentlich durch die Diagnoseeigenschaften des Systems bestimmt werden. Hierbei ist neben der Fehlererkennung auch die Fehlerlokalisierung für eine schnelle Behebung wichtig. Neben der Möglichkeit zum Einscannen und Vergleich der Netzwerktopologie während des Hochlaufs unterstützt EtherCAT systeminhärent viele weitere Diagnoseeigenschaften.

In jedem Slave wird das durchlaufende Telegramm vom EtherCAT Slave Controller mithilfe einer Prüfsumme auf Fehler untersucht. Nur wenn das Telegramm fehlerfrei empfangen wurde, werden die Informationen auch der Slave-Applikation zur Verfügung gestellt. Fehlerhafte Telegramme hingegen inkrementieren einen Zähler und werden für die nachfolgenden Teilnehmer als fehlerhaft gekennzeichnet. Das fehlerhafte Telegramm wird auch im Master erkannt und dort ebenfalls verworfen. Über das Auslesen der Fehlerzähler der Teilnehmer ist der Master in der Lage, die Fehlerstelle im System exakt zu lokalisieren. Dies ist ein wesentlicher Vorteil gegenüber den klassischen Feldbussystemen, bei denen sich Störungen auf der gemeinsam genutzten Busleitung im System ausbreiten und die Quelle einer Störung nicht lokalisiert werden kann. Selten auftretende Störeinflüsse können bei EtherCAT erkannt und lokalisiert werden, auch wenn die Störungen die Funktionalität der Maschine noch nicht beeinflussen. Selbst ein loser Stecker kann dank des Link-Lost-Counters schnell gefunden werden.

Dank der deutlich besseren Bandbreitennutzung ist bei EtherCAT die Wahrscheinlichkeit, dass ein Frame von einer Störung verfälscht wird, ohnehin deutlich geringer als bei Technologien mit Einzelframes – gleiche Zykluszeit vorausgesetzt. Und wenn, wie bei EtherCAT üblich, kürzere Zykluszeiten Verwendung finden, ist die temporäre Wirkung einer etwaigen Störung signifikant verringert. Damit wird auch die applikative Beherrschung solcher Störungen deutlich vereinfacht.

In den Datenpaketen ermöglicht in jedem Datagramm ein Working Counter (WC) die Überwachung der Datenkonsistenz. Jeder Teilnehmer, der von einem Datagramm adressiert wird und dessen Speicherbereich für den Datenzugriff verfügbar ist, inkrementiert den Working Counter automatisch. Der Master kann dadurch zyklussynchron überprüfen, ob alle konfigurierten Teilnehmer die Daten auch bearbeitet haben. Mithilfe von Status- und Fehlerinformationen der Teilnehmer sowie ggf. dem Link-Status kann der Master dann den Grund für das unerwartete Verhalten ermitteln.

Bei vielen Anlagen dürfen Kabelunterbrechungen oder der Ausfall eines Teilnehmers nicht dazu führen, dass das Netzwerk ausfällt oder dass Netzwerksegmente nicht mehr erreichbar sind. Kabelredundanz wird bei EtherCAT über einfache Maßnahmen ermöglicht: Ein zusätzlicher Ethernet-Port im Master und ein zusätzliches Kabel vom letzten Teilnehmer zu diesem Port erweitern die Linien- zu einer Ringtopologie; eine Software-Erweiterung im Master-Stack dient zur Erkennung des Redundanzfalls. Mehr ist nicht notwendig. Die Slave-Teilnehmer bleiben unverändert und wissen nicht einmal, dass sie in einem redundanten Netzwerk betrieben werden.

Der Redundanzfall – eine Kabelunterbrechung oder ein ausgefallener Teilnehmer – wird durch die Link-Erkennung der Teilnehmer automatisch erkannt und aufgelöst. Die Recovery-Zeit liegt bei weniger als 15 μs, so dass maximal ein Kommunikationszyklus gestört wird. Damit können auch kurzzyklische Motion-Anwendungen im Falle eines Kabelbruchs ungestört weiterarbeiten.

Auch Master-Redundanz mit Hot-Standby-Funktionen kann mit EtherCAT realisiert werden. Zudem können gefährdete Maschinenteile, zum Beispiel Teilnehmer, die über eine Schleppkette angebunden sind, per Stichleitungen angebunden werden, um im Falle einer Unterbrechung nicht weitere Teile des Netzwerks zu beeinflussen.