EtherCAT - Der Ethernet-Feldbus.

EtherCAT ist eine Echtzeit-Ethernet-Technologie, die ursprünglich von der Firma Beckhoff Automation entwickelt wurde. Das im IEC-Standard IEC 61158 offengelegte Protokoll von EtherCAT eignet sich für harte sowie weiche Echtzeitanforderungen in der Automatisierungstechnik, in der Messtechnik und vielen anderen Anwendungen.

Die Schwerpunkte bei der Entwicklung von EtherCAT lagen auf kurzen Zykluszeiten (≤ 100 µs), geringem Jitter für eine exakte Synchronisierung (≤ 1 µs) sowie niedrigen Hardware-Kosten.

EtherCAT wurde im April 2003 vorgestellt und die EtherCAT Technology Group (ETG) wurde im November 2003 gegründet. Mittlerweile ist die ETG zur größten Industrial Ethernet- und Feldbus-Nutzerorganisation weltweit gewachsen. Die ETG bringt Hersteller und Anwender zusammen, welche in technischen Arbeitskreisen zur Weiterentwicklung der Technologie beitragen.

1. Eigenschaften von EtherCAT

1.1 Funktionsprinzip
1.2. Protokoll
1.3. Topologie
1.4. Synchronisierung
1.5. Diagnose und Fehlerlokalisierung
1.6. Hochverfügbarkeit
1.7. Sichere Datenübertragung
1.8. Kommunikationsprofile
1.8.1 CAN Application Protocol over EtherCAT (CoE)
1.8.2 Servo Drive Profile according to IEC 61491-7-204 over EtherCAT (SoE)
1.8.3 Ethernet over EtherCAT (EoE)
1.8.4 File Access over EtherCAT (FoE)
1.9 EtherCAT Automation Protocol (EAP)
1.10. Integration anderer Bussysteme

2. Implementierung

2.1 Master
2.2 Slave

3. Konformität und Zertifizierung

3.1 Plug Fest
3.2 Conformance Test Tool
3.3 Technical Working Group Conformance
3.4 EtherCAT Test Center

4. Internationale Normung

1. Eigenschaften von EtherCAT 

 

1.1 Funktionsprinzip 

Das vom EtherCAT-Master ausgesandte Telegramm durchläuft alle Netzwerkteilnehmer. Jeder EtherCAT-Slave liest die an ihn adressierten Ausgangsdaten und legt seine Eingangsdaten in den weitergeleiteten Daten-Frame, während das Telegramm das Gerät durchläuft. Das Telegramm wird ausschließlich 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 Voll-Duplex-Eigenschaft von Ethernet genutzt.

Die maximale Nutzdatenrate eines Telegramms liegt bei über 90%, die theoretische effektive Datenrate durch Ausnutzung der Voll-Duplex-Eigenschaft sogar bei über 100 MBit/s (> 90 % von zwei mal 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. Die EtherCAT-Slaves nutzen einen EtherCAT Slave Controller (ESC) für die Verarbeitung im Durchlauf, die vollständig in Hardware abgewickelt wird. Damit wird die Netzwerkperformance vorhersagbar und unabhängig von der individuellen Slave-Geräteimplementierung.

1.2 Protokoll 

EtherCAT nutzt Standard-Ethernet-Frames, in welche die EtherCAT-Nutzdaten eingebettet sind. Ein EtherCAT-Frame wird durch Verwendung der Kennung (Ox88A4) im EtherType-Feld identifiziert. Da das EtherCAT-Protokoll für kurzzyklische Prozessdaten optimiert ist, kann auf die Verwendung von Protokoll-Stacks, wie z. B. TCP/IP oder UDP/IP, verzichtet werden.

Zur Wahrung einer Ethernet-IT-Kommunikation zwischen den Teilnehmern können TCP/IP-Verbindungen optional parallel über einen Mailbox-Kanal getunnelt werden, ohne dabei den Echtzeitverkehr zu beeinträchtigen.

Die Konfiguration bzw. das Mapping der Prozessdaten wird während des Hochlaufs vom Master in den Slaves konfiguriert. Je Slave können unterschiedlich viele Daten ausgetauscht werden: von einer Bit-Information über einige Byte bis hin zu kByte.

Der 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
  • Zugriff auf einen bestimmten Slave durch direkte Adressierung, oder Zugriff auf viele Slaves 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 Slaves eine Adresse im gleichen Bereich bekommen, können diese über nur ein Datagramm angesprochen werden. Da die Information über den gewünschten Datenzugriff vollständig in den Datagrammen enthalten ist, kann der Master entscheiden, wann er auf welche Daten zugreift. Er kann dies zum Beispiel nutzen, um mit kurzen Zykluszeiten die Antriebe im System zu aktualisieren und gleichzeitig mit einer längeren Zykluszeit die E/As abzufragen; ein fester Frame-Aufbau ist nicht vorgeschrieben.

Zusätzlich zu den zyklischen Daten können weitere Datagramme eingefügt werden, um asynchrone oder bedarfsgesteuerte Kommunikation zu ermöglichen.

Neben der logischen Adressierung hat der Master die Möglichkeit, einen Slave anhand seiner Position im Netzwerk zu adressieren. Dies wird verwendet, um die Topologie des Netzwerks beim Aufstarten auszulesen und gegen eine erwartete Konfiguration zu prüfen.

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.

Slave-to-Slave-Kommunikation kann auf zwei Arten erfolgen. Ein Slave kann einem anderen Teilnehmer, der weiter hinten im Netzwerk eingebunden ist, direkt Daten zusenden. Da die Verarbeitung des EtherCAT-Frames nur in Vorwärtsrichtung erfolgt, ist diese direkte Kommunikation abhängig von der Topologie. Sie eignet sich v.a. für Slave-to-Slave-Beziehungen in einem festen Maschinendesign, zum Beispiel in Druck- oder Verpackungsmaschinen. Frei konfigurierbare Slave-to-Slave-Kommunikation erfolgt hingegen über den Master. Hierfür werden zwei Bus-Zyklen benötigt (nicht unbedingt zwei Steuerungs-Zyklen).

1.3 Topologie 

Linie, Baum, Stern, Daisy Chain: EtherCAT unterstützt nahezu alle Topologievarianten. So ist etwa eine reine Bus- bzw. Linientopologie aus vielen hundert Teilnehmern mit EtherCAT auch ohne die Einschränkungen möglich, die normalerweise durch kaskadierte Switches oder Hubs entstehen.

Für die Systemverdrahtung ist v.a. die Kombination aus Linie und Abzweigen oder Stichleitungen von Vorteil: Die hierfür benötigten Abzweig-Ports sind auf vielen E/A-Modulen direkt integriert – Switches oder andere aktive Infrastrukturkomponenten werden auch hier nicht benötigt.

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, so dass das verbleibende Netzwerk störungsfrei weiterarbeiten kann. Sehr kurze Detektionszeiten < 15 μs gewährleisten dabei eine stoßfreie Umschaltung.

Zusätzliche Flexibilität bietet auch die Varianz der möglichen Kabel. Mit einer Länge von 100 m zwischen zwei Teilnehmern können für im 100BASE-TX-Mode kostengünstige Industrial Ethernet-Kabel verwendet werden. Die Power-over-EtherCAT-Option (kompatibel zu IEEE 802.3af) ermöglicht den Anschluss von Geräten, beispielsweise Sensoren, mit nur einer Leitung. Lichtleiter können ebenfalls genutzt werden, zum Beispiel, um zwischen zwei Teilnehmern Strecken von über 100 m zu überwinden.

Bis zu 65.535 Geräte können an ein EtherCAT Segment angeschlossen werden, sodass die Netzwerkausdehnung praktisch unbeschränkt ist. Wie bei Ethernet üblich, sind beliebige Wechsel zwischen den Physical Layern erlaubt.

1.4 Synchronisierung 

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.

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 (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 dabei deutlich kleiner als 1 μs.

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 Synchronität Gleichzeitigkeit zu erreichen. Auch diese Gleichzeitigkeit ist besser 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.

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 lediglich 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.

1.5 Diagnose und Fehlerlokalisierung 

Verfügbarkeit und Inbetriebnahmezeit einer Anlage werden wesentlich durch die Diagnoseeigenschaften des Systems bestimmt. Hierbei ist neben der Fehlererkennung auch die Fehlerlokalisierung für eine schnelle Behebung wichtig. In jedem Slave wird das durchlaufende Telegramm vom EtherCAT Slave Controller mit Hilfe einer Prüfsumme auf Fehler überprüft. Nur wenn das Telegramm fehlerfrei empfangen wurde, werden auch die Informationen 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. Selten auftretende Störeinflüsse können bei EtherCAT erkannt und lokalisiert werden, selbst wenn die Störungen die Funktionalität der Maschine noch nicht beeinflussen.

In den Datenpaketen ermöglicht ein Working Counter in jedem Datagramm 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. Mit Hilfe von Status- und Fehlerinformationen der Teilnehmer sowie ggf. den Link Status kann der Master dann den Grund für das unerwartete Verhalten ermitteln.

Ethernet-Netzwerkverkehr kann mit Hilfe von Software-Tools aufgezeichnet werden. Diese Tools können für EtherCAT ebenfalls verwendet werden, da EtherCAT Standard-Ethernet-Telegramme nutzt. Das weit verbreitete Tool „Wireshark“ hat beispielsweise einen Protokollinterpretierer für EtherCAT bereits in der Installation enthalten, so dass die protokollspezifischen Informationen, wie zum Beispiel Working Counter, Kommandos etc., in Klartext angezeigt werden.

1.6 Hochverfügbarkeit / Redundanz 

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.

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 < 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 wie 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.

1.7 Sichere Datenübertragung 

EtherCAT setzt bei der Übertragung sicherheitsrelevanter Daten auf dem gleichen Medium auf das sichere Protokoll Safety-over-EtherCAT (FSoE). Daraus ergeben sich folgende Vorteile:

  • ein Kommunikationssystem für die steuerungs- und die sicherheitsrelevanten Informationen
  • flexible Erweiterungsmöglichkeiten der sicherheitsrelevanten Anlagenstruktur
  • vorgefertigte, zertifizierte Sicherheitslösungen für ein hohes Maß an Sicherheit
  • sehr gute Diagnosemöglichkeiten auch für Sicherheitsfunktionen
  • nahtlose Integration des Sicherheitskonzepts in das Maschinenkonzept
  • keine getrennten Entwicklungswerkzeuge für Standard- und Sicherheitsapplikation 

Die vom TÜV zertifizierte Technologie wurde nach IEC 61508 entwickelt und ist in der IEC 61784-3 international standardisiert. Das Protokoll ist geeignet, um in Anwendungen bis zu einem Safety Integrity Level SIL3 eingesetzt zu werden.

Das Transportmedium wird bei Safety-over-EtherCAT als „Black Channel“ betrachtet und daher nicht in die Sicherheitsbetrachtung einbezogen. Das Standard-Kommunikationssystem EtherCAT bleibt einkanalig und überträgt nebeneinander sichere und Standard-Informationen. Die Safety-Frames enthalten die sicheren Prozessdaten sowie zusätzliche Informationen zur Datensicherung; diese Frames werden als „Container“ mit den Prozessdaten der Kommunikation verschickt. Die Übertragungsstrecke ist dabei beliebig und nicht auf EtherCAT beschränkt: es können Feldbussysteme, Ethernet oder ähnliche Strecken zur Übertragung auf elektrischen Leitungen, Lichtwellenleitern oder sogar via Funkübertragung eingesetzt werden.

Der Safety-over-EtherCAT-Container wird über die Steuerungen geroutet und im anderen Anlagenteil ausgewertet. Übergreifende Not-Halt-Funktionen und gezieltes Stillsetzen von Maschinenmodulen sind somit lösbar, auch wenn diese über andere Kommunikationssysteme wie z. B. Ethernet miteinander gekoppelt sind.

1.8 Kommunikationsprofile 

Zur Konfiguration und Diagnose der Teilnehmer kann mit Hilfe von azyklischer Kommunikation auf die für das Netzwerk zur Verfügung gestellten Variablen zugegriffen werden. Ein zuverlässiges Mailbox-Protokoll mit Auto-Recover-Funktion fehlerhafter Telegramme ist hierfür die Grundlage.

Basierend auf diesem Mailbox-Kanal sind folgende Kommunikationsprofile für EtherCAT festgelegt:

  • CAN application protocol over EtherCAT (CoE)
  • Servo drive profile, according to IEC 61800-7-204 (SoE)
  • Ethernet over EtherCAT (EoE)
  • File Access over EtherCAT (FoE)

Ein Teilnehmer muss nicht alle Profile unterstützen, sondern kann entsprechend der eigenen Anforderungen entscheiden, welches Profil geeignet ist. Dem Master werden die implementierten Profile in der Gerätebeschreibungsdatei bekannt gegeben.

1.8.1 CAN application protocol over EtherCAT (CoE) 

EtherCAT stellt mit dem CoE-Protokoll die gleichen Kommunikationsmechanismen bereit, wie sie vom CANopen®-Standard EN 50325-4 her bekannt sind: Objektverzeichnis, PDO Mapping (Process Data Objects) und SDO (Service Data Objects) – auch das Netzwerkmanagement ist vergleichbar. So kann EtherCAT auf Geräten, die bisher mit CANopen ausgestattet waren, mit minimalem Aufwand implementiert werden, große Teile der CANopen-Firmware sind wieder verwendbar. Dabei lassen sich die Objekte optional erweitern, um einerseits die 8-Byte-Beschränkung aufzuheben und andererseits die vollständige Auslesbarkeit des Objektverzeichnisses zu ermöglichen. Auch die Geräteprofile, zum Beispiel das Antriebsprofil CiA402, können für EtherCAT wiederverwendet werden.

1.8.2 Servo drive profile according to IEC 61800-7-204 (SoE) 

SERCOS™ ist als Echtzeit-Kommunikationsschnittstelle für Motion Control-Anwendungen bekannt. Das SERCOS™-Profil für Servoantriebe ist in der IEC 61800-7 genormt. In dieser Norm ist auch dessen Abbildung auf EtherCAT enthalten. Der Servicekanal und damit der Zugriff auf alle antriebsinternen Parameter und Funktionen wird auf die EtherCAT-Mailbox abgebildet.

1.8.3 Ethernet over EtherCAT (EoE) 

EtherCAT nutzt die Ethernet-Kompatibilität auf dem Physical Layer und im Telegrammaufbau. Häufig wird mit dem Begriff Ethernet aber auch die Übertragung von IT-Anwendungen assoziiert, die z. B. auf einer TCP/IP-Verbindung beruhen. Mit dem Ethernet over EtherCAT (EoE)-Protokoll kann beliebiger Ethernet-Datenverkehr im EtherCAT-Segment transportiert werden. Standard Ethernet-Geräte werden innerhalb des EtherCAT-Segments via so genanntem Switchport angeschlossen und die Ethernet-Frames per EoE getunnelt. Dies ist bei den Internet-Protokollen auch in anderen Bereichen üblich (z. B. TCP/IP, VPN, PPPoE (DSL) etc.). Das EtherCAT-Netzwerk ist dabei für die Ethernet-Geräte voll transparent. Das Gerät mit Switchport-Eigenschaft sorgt für das „Eintakten“ von TCP/IP-Fragmenten in den EtherCAT-Verkehr und vermeidet dadurch, dass die Echtzeit im Netzwerk beeinflusst wird. EtherCAT-Geräte können zusätzlich selbst Internet-Protokolle (wie z. B. HTTP) unterstützen und damit außerhalb des EtherCAT-Segments wie ein Standard-Ethernet-Teilnehmer auftreten. Der Master fungiert als Layer-2-Switch, der die Frames gemäß der MAC-Adressinformation zu den entsprechenden Teilnehmern per EoE weiterleitet. Damit können sämtliche Internet-Technologien auch im EtherCAT-Umfeld zum Einsatz kommen: integrierte Webserver, E-Mail, FTP-Transfer, etc.

1.8.4 File access over EtherCAT (FoE) 

Dieses an TFTP (Trivial File Transfer Protocol) angelehnte, sehr einfache Protokoll ermöglicht den Zugriff auf Dateien im Gerät. Genutzt wird dies vor allem, um einen einheitlichen Firmware-Upload auf die Geräte über das Netzwerk zu erreichen. Damit das FoE-Protokoll auch von Boot-Loader-Programmen unterstützt werden kann, wurde es bewusst schlank spezifiziert – ein TCP/IP-Stack muss hierfür nicht vorhanden sein.

1.9 EtherCAT Automation Protocol (EAP) 

Die Prozessleitebene erfordert zum Betrieb einer Anlage oder einer Fabrik weitere (und teilweise andere) Kommunikationsmöglichkeiten, als es das bisher beschriebene EtherCAT Device Protocol bietet. Anlagenteile müssen häufig mit Steuerungen benachbarter Anlagenteile Informationen über den eigenen Status und die nächsten Produktionsschritte abgleichen. Zudem gibt es häufig einen zentralen Leitrechner, der die Überwachung des gesamten Systems durchführt, dem Anwender Statusdaten zur Produktivität bereitstellt und neue Aufträge an die Maschinenteile vergibt.

Das EtherCAT Automation Protocol (EAP) erfüllt die Anforderungen der genannten Anwendungsfälle. Es definiert Schnittstellen und Dienste für:

  • den Datenaustausch zwischen EtherCAT-Master-Geräten (Master-Master-Kommunikation)
  • den Datenaustausch zu Visualisierungsgeräten
  • den Durchgriff von überlagerten Steuerungen auf Teilnehmer in unterlagerten EtherCAT-Segmenten (Routing)
  • die Anbindung von Konfigurationstools für die Anlagen- sowie für die Teilnehmerkonfiguration

Die in EAP verwendeten Kommunikationsprotokolle sind Bestandteil des IEC 61158-Standards. EAP kann über beliebige Ethernet-Verbindungen, auch per Funk, übertragen werden. So lassen sich zum Beispiel fahrerlose Transportgeräte, wie sie in der Halbleiter- oder Automobilindustrie üblich sind, in das Netzwerk einbinden.

Der zyklische Prozessdatenaustausch im EAP kann nach dem „Pushed“- oder dem „Polled“-Prinzip erfolgen. Im „Pushed“-Betrieb sendet jeder Kommunikationsteilnehmer seine Daten zyklisch oder in einem Vielfachen des eigenen Zyklus. Im Empfänger kann konfiguriert werden, von welchem Sender welche Daten empfangen werden sollen. Die Konfiguration zwischen Sender- und Empfängerdaten erfolgt wie gewohnt über das Objektverzeichnis. Im „Polled“-Betrieb werden die Daten von den Teilnehmern abgefragt.

Die zyklische EAP-Kommunikation kann direkt in den Nutzdaten eines Ethernet-Telegramms übertragen werden, ohne ein zusätzliches Transport- oder Sicherungsprotokoll. Der EtherType Ox88A4 identifiziert auch hier die EtherCAT-spezifische Nutzung des Frames. Dadurch können mit dem EAP Daten im Millisekundentakt ausgetauscht werden. Wenn ein Routing der Daten innerhalb einer verteilten Anlage gefordert ist, dann können die Prozessdaten auch per UPD/IP oder TCP/IP übertragen werden.

Mit Hilfe von EAP und der Nutzung des Safety-over-EtherCAT-Protokolls können auch sicherheitsrelevante Daten ausgetauscht werden. Anlagenweit werden zwischen den Maschinenmodulen Sicherheitsinformationen ausgetauscht, um z.B. übergreifende Not-Aus-Funktionen zu realisieren oder um Vorgänger- und Nachfolgemodule über die Aktivierung von Stillstandfunktionen zu informieren.

1.10 Integration anderer Bussysteme 

Durch die zur Verfügung stehende Bandbreite ist es möglich, klassische Feldbusanschaltungen in einem EtherCAT-Gateway als unterlagertes System zu nutzen. Die schrittweise Umsetzung einer Anlage auf EtherCAT sowie die Einbindung von Automatisierungskomponenten, die (noch) keine EtherCAT-Schnittstelle unterstützen, ist somit möglich.

Zudem werden dadurch kleine oder Embedded-Industrie-PC-Lösungen ermöglicht, da der Platz für Erweiterungskarten nicht mehr bereitgestellt werden muss: Über einen einzigen Ethernet-Port im PC können neben den dezentralen E/As, Achsen und Bediengeräten auch komplexe Systeme wie Feldbus-Master/Slaves (Gateways), schnelle serielle Schnittstellen und andere Kommunikations-Interfaces angesprochen werden. Die Daten des eingebundenen Feldbusses stehen dem Master im Prozessdatenabbild direkt zur Verfügung.

2. Implementierung 

 

Jeder Sensor, jedes E/A-Gerät und jeder Embedded-Controller soll in der Lage sein, eine EtherCAT-Anschaltung einbinden zu können. Nicht die EtherCAT-Schnittstelle, sondern die Geräteapplikation bestimmt die Leistungsanforderung der benötigten CPU.

Neben den reinen Hardware- und Softwareanforderungen sind für die Entwicklung einer Schnittstelle der Support und die verfügbaren Kommunikations-Stacks von hoher Bedeutung. Evaluation-Kits von verschiedenen Herstellern, Entwickler-Workshops und frei verfügbare Beispiel-Codes erleichtern zudem den Einstieg.

Um die Interoperabilität von EtherCAT-Geräten zu gewährleisten, ist jeder Hersteller verpflichtet, vor Marktstart einen Conformance Test durchzuführen. Dieser automatische Test prüft das Verhalten der Implementierung und hilft bereits während der Entwicklung, Fehler zu erkennen und zu vermeiden.

2.1 Master 

EtherCAT ist die Ethernet-Lösung für harte Echtzeit-Anforderungen, die ohne spezielle Master-Hardware auskommt; der On-Board-Ethernet-Controller oder eine Standard-Netzwerkkarte genügen.

Die Anbindung dieser Ethernet-Controller erfolgt bei nahezu all diesen Interface-Lösungen per Direct Memory Access (DMA). Der Datentransfer zwischen Master und Netzwerk benötigt also keine CPU-Performance. Dabei ist das Prozessabbild bereits fertig sortiert, da das Mapping bei EtherCAT nicht im Master, sondern in den Slaves erfolgt – die Peripheriegeräte fügen ihre Daten an die entsprechende Stelle im durchlaufenden Frame ein und lesen die für sie bestimmten Daten im Durchlauf. EtherCAT-Master wurden bereits auf zahlreichen Betriebssystemen wie z.B. Windows, Linux, QNX, RTX, VxWorks, Intime oder eCos implementiert.

Der EtherCAT-Master benötigt zum Betrieb des Netzwerks neben dem zyklischen Frame-Aufbau noch die Hochlaufkommandos für jeden Slave. Diese Kommandos können mit Hilfe eines EtherCAT-Konfigurationstools in ein EtherCAT Network Information (ENI) File exportiert werden. Hierzu verwendet das Konfigurationstool die EtherCAT Slave Information (ESI) Files der angeschlossenen Geräte.

Der Umfang der verfügbaren Master-Implementierung und der unterstützten Funktionen variiert je nach Zielapplikation. Optionale Funktionen werden unterstützt oder bewusst weggelassen, um die Hardware- und Software-Ressourcen zu optimieren. Die EtherCAT Master Classes-Spezifikation definiert daher zwei Klassen von Mastergeräten: Ein Class-A-Master ist ein Standard-EtherCAT-Master, ein Class-B-Master einer mit reduziertem Funktionsumfang. Class B wird nur empfohlen, wenn die verfügbaren Ressourcen Class A nicht zulassen, zum Beispiel in einem Embedded-System. Notwendige und empfohlene Funktionen werden dementsprechend für die beiden Klassen aus Sicht des Endanwenders zugeordnet.

2.2 Slave 

Im Slave-Gerät kommt ein EtherCAT Slave Controller (ESC) als ASIC, FPGA oder integriert in einem Standard-Microcontroller zum Einsatz. Für einfache Geräte ist kein zusätzlicher Microcontroller erforderlich – die Prozess-Ein- und -Ausgänge können direkt an den ESC angeschlossen werden. Bei komplexeren Geräten ist die Kommunikations-Performance bei EtherCAT nahezu unabhängig von der Leistungsfähigkeit des verwendeten Microcontrollers. In den meisten Fällen ist ein 8 Bit-Microcontroller ausreichend.

EtherCAT Slave Controller sind von mehreren Herstellern verfügbar. Je nach Ausprägung variiert die Größe des internen DPRAM sowie die Anzahl der FMMUs und SyncManager. Unterschiedliche Prozessdaten-Schnittstellen (PDI) für den externen Zugriff des Applikationscontrollers auf den Anwendungsspeicher stehen zur Verfügung:

  • Das 32-Bit-Parallel-E/A-Interface eignet sich für den Anschluss von bis zu 32 digitalen Ein- und Ausgängen, aber auch für einfache Sensoren oder Aktoren, die mit 32 Datenbits auskommen und keinen Applikationscontroller benötigen.
  • Das SPI (Serial Peripheral Interface) ist speziell für Geräte mit kleiner Prozessdatenmenge gedacht, wie z. B. analoge E/A-Module, Geber, Encoder oder auch einfache Antriebe.
  • Das parallele 8/16-Bit-Microcontroller-Interface entspricht herkömmlichen Schnittstellen bei Feldbus-Controllern mit integriertem DPRAM. Es eignet sich besonders für komplexere Teilnehmer mit größerem Datenaufkommen.
  • Für die FPGA- und On-Chip-Varianten sind passende synchrone Busse für die verschiedenen Microcontroller implementiert.

In einem nichtflüchtigen Speicherbaustein (z.B. einem EEPROM) werden Informationen über die Hardware-Konfiguration der PDI-Schnittstelle abgelegt. Zudem werden in diesem SII (Slave Information Interface) die zentralen Geräteeigenschaften abgelegt, sodass ein EtherCAT-Master auch ohne vorhandene Gerätebeschreibungsdatei das Gerät betreiben kann. Die vollständige Beschreibung der Geräteeigenschaften wird in der Gerätebeschreibungsdatei der EtherCAT Slave Information (ESI) File mitgeliefert. Diese XML-Datei enthält unter anderem Möglichkeiten des Prozessdaten-Mappings, unterstützte Mailbox-Protokolle inkl. der optionalen Features sowie die unterstützten Synchronisierungsmodi. Ein Netzwerk-Konfigurationstool nutzt diese Informationen zur (Offline-) Konfiguration des Netzwerks.

Zur Unterstützung einer Slave-Implementierung werden verschiedene Evaluation-Kits von den Herstellern angeboten. Der Umfang umfasst auch Slave-Anwendungssoftware im Sourcecode; Test-Master sind teilweise enthalten.

3. Konformität und Zertifizierung 

 

Konformität und Interoperabilität sind entscheidende Faktoren für den Erfolg einer Kommunikationstechnologie. Ausgehend von der notwendigen Konformitätsprüfung jeder Geräteimplementierung mit Hilfe eines automatischen Konformitätstesttools bietet die EtherCAT Technology Group (ETG) weitere Aktivitäten zur Verbesserung der Interoperabilität zwischen EtherCAT-Master, EtherCAT-Slave und den EtherCAT-Konfigurationstools an.

3.1 Plug Fest 

Ein pragmatischer Ansatz, um die Interoperabilität von Geräten zu testen, ist, diese zusammenzuschließen. Hierfür lädt die ETG mehrmals jährlich zu so genannten „Plug Fests“ ein. Zu diesen in der Regel zweitägigen Events treffen sich Master- und Slave-Anbieter, um das gegenseitige Verhalten der Geräte zu testen und die Handhabung im Feld zu verbessern. Diese Entwicklertreffen finden regelmäßig in Europa, Nordamerika und Asien statt.

3.2 Conformance Test Tool (CTT) 

Das EtherCAT Conformance Test Tool (CTT) ermöglicht die automatische Überprüfung des Verhaltens eines EtherCAT-Slave-Geräts.

Das CTT ist eine Windows-Applikation, die als Hardware-Schnittstelle lediglich einen Standard-Ethernet-Port benötigt. Über diesen Port werden EtherCAT-Frames an das Device under Test (DuT) versendet und die Antworten empfangen. Die Antworten werden dann mit einem erwarteten Ergebnis verglichen und der Test-Case damit als gültig oder ungültig gewertet. Die Test-Cases inklusive der erwarteten Antwort werden in Form von XML-Dateien beschrieben. Dadurch ist es möglich, die Test-Cases zu erweitern, ohne das Tool selbst anpassen zu müssen. Die Spezifikation der aktuell gültigen Test-Cases erfolgt durch die Technical Working Group Conformance der EtherCAT Technology Group.

Neben den reinen Protokolltests wird vom CTT auch das EtherCAT Slave Information File (ESI) auf gültige Werte überprüft. Zudem gibt es gerätespezifische Protokolltests, beispielsweise für das CiA402 Antriebsprofil. Alle Testschritte und die Testergebnisse werden in einem Test-Logger gespeichert und können anschließend näher analysiert werden oder zur Ablage und zum Nachweis für die Gerätefreigabe dienen.

3.3 Technical Working Group Conformance 

Das Technical Committee (TC) der ETG hat eine Technical Working Group (TWG) Conformance etabliert, die die Testprozedur und die Testinhalte für die Umsetzung im Conformance Test Tool festlegt. Die TWG Conformance arbeitet kontinuierlich an der Erweiterung der Tests und der Testtiefe, zudem wird in dem Arbeitskreis auch die Spezifikation eines Interoperabilitäts-Tests erarbeitet.

4. Internationale Normung 

 

EtherCAT sowie Safety-over-EtherCAT sind internationale IEC-Standards (in IEC 61158 und IEC 61784). Genormt sind hierbei nicht nur die unteren Protokollschichten, sondern auch Anwendungsschicht und Geräteprofile, z.B. für Antriebstechnik. In vielen Ländern ist EtherCAT zusätzlich auch nationaler Standard, z.B. in den meisten europäischen Ländern, in China und in Korea.

SEMI™ (Semiconductor Equipment and Materials International) hat EtherCAT als Kommunikationsstandard (E54.20) für die Halbleiterindustrie akzeptiert. Die Arbeitskreise der ETG Semiconductor Technical Working Group definieren entsprechende branchenspezifische Geräteprofile und Implementierungsrichtlinien. Die EtherCAT-Spezifikation steht in englischer, japanischer, koreanischer und chinesischer Sprache zur Verfügung.

 

* CANopen is a trademark of the CAN in Automation e.V.
** SERCOS interface is a trademark of the SERCOS International .V.