20 Jahre EtherCAT

Das von Beckhoff entwickelte und zur Hannover 2003 erstmals vorgestellte Kommunikationssystem hat sich seither als hochleistungsfähiges Echtzeit-Ethernet in vielfältigsten Anwendungsbereichen bewährt, mit Kontinuität und technischer Weiterentwicklung im Markt durchgesetzt und als offener IEC-Standard etabliert.

Hans Beckhoff (Bild 1) und Martin Rostan (Bild 2) beschreiben die wichtigsten Aspekte dieser spannenden Zeit. Johannes Beckhoff (Bild 3) richtet als Vertreter der nächsten Führungsgeneration im Unternehmen den Blick auf die künftigen Anforderungen (Anm. d. Red.: Das komplette Interview ist auf der Internetseite von Beckhoff Automation unter www.beckhoff.com/de-de → Unternehmen → News → »EtherCAT feiert 20-jähriges Jubiläum« zu lesen).

Herr Beckhoff und Herr Rostan, wie lassen sich die grundlegenden Vorteile von EtherCAT zusammenfassend beschreiben?

Hans Beckhoff: Zunächst handelt es sich bei den traditionellen RS485- und CAN-basierten Feldbussen um sogenannte Party-Line- Busse mit vielen Teilnehmern an einer einzigen Verbindung. Das erschwert deutlich die Netzwerkdiagnose und Fehlersuche. EtherCAT hat daher die Punkt-zu-Punkt-Verbindung von Ethernet übernommen, sodass sich – eine wesentliche Eigenschaft – jede Übertragungsstrecke gut diagnostizieren lässt. Weiterhin haben wir schon recht früh beschlossen, mit einem Standard-Ethernet-Telegramm auszukommen und somit auf eine spezielle Kommunikationskarte im Master zu verzichten, was nach wie vor einen immensen Vorteil von EtherCAT darstellt.

Ganz entscheidend ist die erwähnte Protokolleffizienz, dass also dem 64- bis 1 500-Byte-Ethernet-Telegramm im Durchlauf Daten entnommen oder hinzugefügt werden können. Nur so lässt sich die hohe Bandbreite konsequent und für die vielen kleinen Informationseinheiten der zahlreichen Automatisierungsgeräte – über 65 000 sind in einem Netzwerk möglich – in einem Telegramm nutzen.

Martin Rostan: Dieses Prinzip ergibt einen weiteren Vorteil: Die Steuerung kann das Prozessabbild im Datentelegramm schon genau passend zusammenstellen, da die Netzwerkteilnehmer ihre Daten an beliebigen Stellen einfügen oder entnehmen können. Daher entfallen die bei anderen Systemen erforderlichen, aufwändig zu implementierenden Bit-Operationen über eine Schnittstellenkarte. Durch den EtherCAT-Master wird die Steuerung hingegen in keiner Weise belastet, da ein komplett vorsortiertes Prozessabbild bereitsteht, das direkt verarbeitet werden kann. EtherCAT ist daher nicht nur in der eigentlichen Kommunikation mit sehr kurzen Zykluszeiten sehr schnell, sondern auch in allen vor- und nachgelagerten Prozessschritten.

Hans Beckhoff: Und dieses Prinzip basiert auf der IT-Funktion der Memory Management Unit, die wir dafür zur Fieldbus Memory Management Unit (FMMU) weiterentwickelt haben. Die FMMU ist eine der wesentlichen Eigenschaften von EtherCAT und ermöglicht es, Daten im Durchlauf aus einem dezentralen Speicher zu entnehmen und wieder zurückzuschreiben, sodass man ein beliebiges Mapping zwischen den Daten im physikalischen Gerät und den Daten im durchlaufenden Telegramm durchführen kann.

Außerdem lassen sich über die FMMU sehr gut auch einzelne Tasks bzw. Prozessorkerne abbilden und mit entsprechenden Zeitebenen definieren, was der modernen und Task-basierten Steuerungstechnik ideal entspricht. Eine weitere zentrale Eigenschaft von EtherCAT sind die Distributed Clocks, mit denen eine definierte und automatisch abgeglichene Systemzeit für das Kommunikationssystem eingeführt wurde. Das ist entscheidend, da fortschrittliche Steuerungskonzepte fast immer Zeitscheiben-basiert sind und synchronisierte Abtastpunkte für die Daten und Signale benötigen. Eine solches Konzept der verteilten Uhren gab es bei den bisherigen Feldbussen nicht.

Was macht EtherCAT heute nach wie vor zur bevorzugten Wahl als industrielles Kommunikationssystem?

Hans Beckhoff: In den letzten 20 Jahren hat sich die Technologie als so gut durchdacht herausgestellt, dass wir keine Änderungen am grundsätzlichen Protokoll durchführen mussten. Das ist ein wesentlicher Aspekt unseres Erfolgs. Hinzu kommt, dass wir die EtherCAT-Prinzipien auch in andere Anwendungsebenen eingebracht haben, beispielsweise mit dem EtherCAT Automation Protokoll (EAP) für die Steuerung-zu-Steuerung-Kommunikation.

Weiterhin wurde die Erweiterung EtherCAT G eingeführt, als 1-GBit/s-Variante und auch als 10-GBit/s-Version. Das EtherCAT-Protokoll funktioniert also auch bei diesen rasant steigenden Geschwindigkeiten.

Martin Rostan: Es ist sogar ein Alleinstellungsmerkmal von EtherCAT, dass die Technologie an sich nie geändert werden musste. Das im Chip enthaltene Basisprotokoll ist stets gleichgeblieben und immer nur vollständig abwärtskompatibel erweitert worden. Gleiches gilt für Safety over EtherCAT, bei dem die Abwärtskompatibilität ebenfalls durchgängig gegeben ist.

Und auch in EtherCAT-G-Netzwerken können nach wie vor 100-MBit/s-Geräte eingebunden und betrieben werden. Dementsprechend funktioniert ein heutiges EtherCAT-Gerät auch in einer 20 Jahre alten Anlage, was für viele Anwender allein schon Grund genug ist für die Wahl dieses Feldbusses. Unsere Technologie stellt also auch in Zukunft keinen Flaschenhals in der Steuerungsarchitektur dar. Für die meisten Anwendungen wird dies mit 100 MBit/s weiterhin so bleiben, durch EtherCAT G besteht aber zudem ausreichend Potenzial um alle Highend-Anforderungen der nächsten 20 Jahre ohne Technologiebruch problemlos zu erfüllen.

Johannes Beckhoff: Und 100 MBit/s reichen für die meisten Anforderungen einer Maschine sogar für Zykluszeiten kleiner 1 ms aus. Mit EtherCAT G lassen sich dann sehr datenintensive Anwendungen realisieren, wie z. B. XPlanar oder Vision-Applikationen – mit mehreren kByte Daten in einem Sub-ms-Zyklus. So könnten wir ohne EtherCAT G kein wirklich großes XPlanar-System realisieren, vielleicht maximal 20 Kacheln. Eine GBit/s-Datenrate ermöglicht bereits über 100 Kacheln. Grundsätzlich gilt das auch für das lineare Transportsystem XTS.

Es funktioniert hervorragend mit einer Übertragungsrate von 100 MBit/s, wäre aber ohne das effiziente EtherCAT-Protokoll überhaupt nicht möglich, da auch hier mehrere kByte Daten bei sehr kurzen Zykluszeiten von 250 µs übertragen werden müssen. Andere Kommunikationssysteme können das nicht leisten und erfordern bei vergleichbaren Systemen eine aufwändige dezentrale Steuerungsarchitektur.