EtherCAT - Der Ethernet-Feldbus

EtherCAT ist eine Echtzeit-Ethernet-Technologie, die ursprünglich von der Firma Beckhoff Automation entwickelt wurde. Die folgenden Informationen finden sich auch in der EtherCAT-Broschüre, welche in mehreren Sprachen verfügbar ist.

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 Das EtherCAT-Funktionsprinzip
1.2. Protokolleigenschaften
1.3. Flexible Topologie
1.4. EtherCAT P: Kommunikation und Power auf einer Leitung
1.5. Hochgenaue Synchronisierung mit Distributed Clocks
1.6. Diagnose und Fehlerlokalisierung
1.6. Hohe Verfügbarkeit
1.8. Sichere Datenübertragung mit Safety-over-EtherCAT
1.9. Kommunikationsprofile
1.9.1 CAN Application Protocol over EtherCAT (CoE)
1.9.2 Servo Drive Profile according to IEC 61491-7-204 over EtherCAT (SoE)
1.9.3 Ethernet over EtherCAT (EoE)
1.9.4 File Access over EtherCAT (FoE)
1.9.5 ADS over EtherCAT (AoE)
1.10 Anlagenweite Kommunikation mit dem EtherCAT Automation Protocol (EAP)
1.11. Integration anderer Bussysteme
1.12. EtherCAT, Industrie 4.0 und IoT

2. EtherCAT-Schnittstellen-Implementierung

2.1 MainDevice
2.2 SubDevice

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

nach oben

1.1 Das EtherCAT-Funktionsprinzip

Das vom EtherCAT-MainDevice ausgesandte Telegramm durchläuft alle Teilnehmer.

Jedes EtherCAT-SubDevice liest „on the fly“ die an es 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 MainDevice zurück – hierbei wird die Full-Duplex-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 zwei mal 100 MBit/s).

Das EtherCAT-MainDevice 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.

Das MainDevice nutzt einen Standard-Ethernet-Medium-Access-Controller (MAC) ohne einen zusätzlichen Kommunikationsprozessor. Damit kann ein MainDevice 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-SubDevices nutzen einen EtherCAT SubDevice 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 SubDevices abhängt.

1.2 Protokolleigenschaften

EtherCAT nutzt Standard-Ethernet-Frames. In die Frames eingebettet sind die EtherCATNutzdaten. 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 belastenden Protokoll-Stacks, wie z. B. TCP/IP oder UDP/IP, verzichtet werden.

EtherCAT: Standard-Ethernet-Telegramm entsprechend IEEE 802.3

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 MainDevice in den SubDevices konfiguriert. Je SubDevice 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 das MainDevice im Netzwerk durchführen möchte:

Lesen, Schreiben, Lesen und Schreiben
Zugriff auf ein bestimmtes SubDevice durch direkte Adressierung, oder Zugriff auf viele SubDevices 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. Jedes SubDevice bekommt beim Hochlauf des Netzwerks eine oder mehrere Adressen in diesem Adressraum zugewiesen. Indem mehrere/viele SubDevices eine Adresse im gleichen Bereich bekommen, können diese SubDevices über ein einziges Datagramm angesprochen werden. Da die Information über den gewünschten Datenzugriff vollständig in den Datagrammen enthalten ist, kann das MainDevice entscheiden, wann es auf welche Daten zugreift. Es 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. Dies entlastet auch das MainDevice: In bisherigen Feldbusanschaltungen war es nötig, die Daten von jedem einzelnen Feldbusteilnehmer einzeln auszulesen und dann mit Hilfe des Prozessors diese Daten zu sortieren und in den Arbeitsspeicher zu kopieren. Mit EtherCAT muss das MainDevice nur einen EtherCAT-Frame mit neuen Ausgangsdaten füllen und kann diesen per automatischem Direct Memory Access (DMA) an den MAC-Controller senden. Wenn der Frame mit den Eingangsinformationen vom MAC-Controller wieder empfangen wird, kann dieser ihn ebenfalls per DMA in den Arbeitsspeicher des Rechners kopieren – ein aktives Kopieren durch die CPU wird nicht benötigt.

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

Prozessdaten werden im Durchlauf in das Telegramm eingefügt

Neben der logischen Adressierung hat das MainDevice die Möglichkeit, ein SubDevice 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 das MainDevice 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. SubDevice-zu-SubDevice-Kommunikation kann auf zwei Weisen erfolgen: Ein SubDevice 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 topologieabhängig. Sie ist besonders geeignet für SubDevice-zu-SubDevice-Beziehungen in einem festen Maschinendesign, zum Beispiel in Druck- oder Verpackungsmaschinen. Frei konfigurierbare SubDevice-zu-SubDevice-Kommunikation erfolgt hingegen über das MainDevice. Hierfür werden zwei Buszyklen benötigt (nicht unbedingt zwei Steuerungszyklen); dank der hervorragenden Performance von EtherCAT ist dies dennoch schneller als bei anderen Ansätzen.

1.3 Flexible Topologie

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.

Flexible Topologie: Linie, Baum oder Stern

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 E/A-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 SubDevice 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.

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 E/A-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.

1.4. EtherCAT P: Kommunikation und Power auf einer Leitung

EtherCAT P (P = Power) ermöglicht als Erweiterung des bisher beschriebenen EtherCAT-Protokolls nicht nur die Übertragung von Kommunikationsdaten, sondern auch die Stromversorgung über ein und dasselbe vieradrige Standard-Ethernet-Kabel.

EtherCAT und EtherCAT P sind protokolltechnisch identisch, die Erweiterung betrifft ausschließlich den Physical Layer, was auch bedeutet, dass für EtherCAT P keine neuen EtherCAT SubDevice Controller vonnöten sind. EtherCAT P bietet demnach die gleichen Vorteile wie EtherCAT, ermöglicht zusätzlich jedoch die Stromversorgung über das Kommunikationskabel und bietet damit für viele Applikationen attraktive Vorteile.

EtherCAT P: Daten und Leistung in nur einem Kabel

Zur Versorgung der speziellen EtherCAT-P-Geräte stehen zwei galvanisch getrennte, auch einzeln schaltbare 24-Volt-Spannungen zur Verfügung, wobei US der System- und Sensorversorgung, UP der Versorgung von Peripherie und Aktoren dient. Beide Spannungen, US und UP, sind bei EtherCAT P direkt in die 100Mbit/s-EtherCAT-Kommunikationsleitung eingebunden, und dank Weiterleitung können mehrere EtherCAT-Geräte kaskadiert werden, alles mit einem Kabel. All das führt zu reduzierter Verkabelung, kompakter und kostengünstiger Verdrahtung, gesenkten Systemkosten und allgemein einem geringeren Platzbedarf für Geräte, Zubehör und Maschinen.

Besonders interessant ist EtherCAT P für Maschinenteile, die in sich abgeschlossen und abgesetzt vom Rest des Systems arbeiten und dank der Erweiterung durch eine einzige Stichleitung mit Daten und Leistung versorgt werden können. Auch für Sensoren aller Art ist EtherCAT P hervorragend geeignet: Diese werden von nun an über einen speziellen M8-Stecker ins Highspeed-Netzwerk integriert und an die Versorgungsspannung angeschlossen. Mögliches Fehlstecken wird dank der mechanischen Kodierung des Steckers ausgeschlossen.

EtherCAT P kann mit EtherCAT im selben Netzwerk genutzt werden. Entsprechende Einspeisegeräte setzen von der herkömmlichen EtherCAT-Physik auf EtherCAT P um, wobei die Ethernet-Datenkodierung voll erhalten bleibt. Genauso kann ein Gerät für sich mit EtherCAT P versorgt werden, daneben aber auch herkömmliches EtherCAT weiterleiten.

Weitere Informationen zu EtherCAT P finden sich unter:
www.ethercat.org/ethercat-p

1.5 Hochgenaue Synchronisierung mit Distributed Clocks

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.

Die Synchronisierung der Teilnehmer erfolgt vollständig hardwarebasiert; Laufzeitverzögerungen werden berechnet und ausgeglichen.

Der Abgleich der Uhren in den Teilnehmern erfolgt vollständig in Hardware. Hierfür wird die Uhrzeit des ersten synchron arbeitenden SubDevice zyklisch an alle anderen Uhren im System verteilt. Die SubDevice-Uhren können sich dadurch exakt auf diese Referenzuhr einregeln. Der resultierende Jitter im System ist signifikant kleiner als 1 μs.

Synchronität und Gleichzeitigkeit: Scope Aufnahme zweier verteilter Geräte; dazwischen sind 300 Knoten und 120 m Leitungslänge.

Da die Uhrzeitinformation der Referenzuhr durch die Laufzeitverzögerung auf dem Kabel und in den Teilnehmern erst verspätet bei den SubDevice-Uhren empfangen wird, ist eine Messung und ein Ausgleich dieser Verzögerung für jedes SubDevice 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. 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 das MainDevice: Das Versenden eines EtherCAT-Telegramms wird in einem Bereich > 1 μs jittern, da der MainDevice 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 SubDevice-Uhren nachzustellen, ist der absolute Sendezeitpunkt unerheblich und darf auch jittern. Das EtherCAT-MainDevice muss lediglich dafür sorgen, dass das EtherCAT-Telegramm früh genug verschickt wird, bevor in den SubDevices das DC-Signal den Trigger zum Setzen der Ausgänge gibt.

1.6 Diagnose und Fehlerlokalisierung

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 SubDevice wird das durchlaufende Telegramm vom EtherCAT SubDevice Controller mit Hilfe einer Prüfsumme auf Fehler untersucht. Nur wenn das Telegramm fehlerfrei empfangen wurde, werden die Informationen auch der SubDevice-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 MainDevice erkannt und dort ebenfalls verworfen. Über das Auslesen der Fehlerzähler der Teilnehmer ist das MainDevice 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, selbst wenn die Störungen die Funktionalität der Maschine noch nicht beeinflussen.

Dank der um Größenordnungen 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 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. Das MainDevice 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 das MainDevice dann den Grund für das unerwartete Verhalten ermitteln.

Ethernet-Netzwerkverkehr kann mit Hilfe von kostenfreien 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 in der Installation enthalten, so dass die protokollspezifischen Informationen, wie etwa Working Counter, Kommandos etc., in Klartext angezeigt werden.

1.7 Hohe Verfügbarkeit

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 MainDevice und ein zusätzliches Kabel vom letzten Teilnehmer zu diesem Port erweitern die Linien- zu einer Ringtopologie; eine Software-Erweiterung im MainDevice Stack dient zur Erkennung des Redundanzfalls. Mehr ist nicht notwendig. Die SubDevice-Teilnehmer bleiben unverändert und „wissen“ nicht einmal, dass sie in einem redundanten Netzwerk betrieben werden.

Kostengünstige Kabelredundanz mit Standard-EtherCAT-SubDevices

Auch MainDevice-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.

1.8 Sichere Datenübertragung mit Safety-over-EtherCAT

Moderne Kommunikationssysteme erfüllen heute nicht nur den deterministischen Transport von Steuerungsinformationen, sie bieten außerdem die Möglichkeit, sicherheitsrelevante Daten auf dem gleichen Medium zu übertragen. EtherCAT setzt dabei auf das sichere Protokoll Safety-over-EtherCAT (FSoE = Fail Safe over EtherCAT) mit folgenden Vorteilen:

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

Gegenüber herkömmlicher sicherer E/A-Verdrahtung ermöglicht der Einsatz von Safety-over-EtherCAT wesentlich einfachere und flexiblere Architekturen.

Die vom TÜV SÜD Rail bestätigte 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 beliebig und nicht auf EtherCAT beschränkt: es können Feldbussysteme, Ethernet oder ähnliche Strecken zur Übertragung eingesetzt werden auf elektrischen Leitungen, Lichtwellenleitern oder auch via Funkübertragung.

Der Safety-Container wird in die Prozessdaten der zyklischen Kommunikation eingebettet.

Durch diese Unabhängigkeit wird auch die sicherheitsrelevante Vernetzung von Anlagenteilen vereinfacht. 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 problemlos durchführbar, auch wenn diese über andere Kommunikationssysteme wie z. B. Ethernet miteinander gekoppelt sind.

Die Implementierung des Protokolls in ein Gerät benötigt nur wenige Ressourcen und kann eine hohe Performance und damit kurze Reaktionszeit erreichen. Im Bereich der Robotersteuerungen sind Anlagen bekannt, die mit Safety-over-EtherCAT einen sicheren Antriebsbus realisieren, der in einem 8-kHz-Raster arbeitet.

Black-Channel-Prinzip: Die Standard Kommunikationsanschaltung kann verwendet werden.

Weitere Informationen zur Safety-over-EtherCAT Technologie sind auf der EtherCAT-Webseite verfügbar:
www.ethercat.org/safety

1.9 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)

Verschiedene Kommunikationsprofile können nebeneinander realisiert werden.

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

1.9.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.9.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.9.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.

EtherCAT ermöglicht eine transparente Durchleitung von Standard-IT-Protokollen.

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. Das MainDevice 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.9.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.5 ADS over EtherCAT (AoE)

Als ein Mailbox-basiertes Client-Server-Protokoll beschreibt die EtherCAT-Spezifikation ADS over EtherCAT (AoE). Während Protokolle wie CoE ein detailliertes semantisches Konzept anbieten, ergänzt AoE dieses mit routing-fähigen und parallelen Diensten, wo diese benötigt werden: zum Beispiel beim Zugriff aus einem SPS-Programm auf unterlagerte Netzwerke hinter EtherCAT/Feldbus-Gateways wie etwa CANopen®, IO-Link™ oder anderen. Die AoE-Implementierung benötigt deutlich weniger Speicher als vergleichbare Dienste wie sie vom Internet Protocol (IP) angeboten werden. Die Adressparameter von Sender und Empfänger sind im AoE-Telegramm enthalten, was eine besonders ressourcenschonende Implementierung sowohl auf Client- als auch auf Server-Seite ermöglicht.

Darüber hinaus ist AoE das Mittel der Wahl für die azyklische Kommunikation des EtherCAT Automation Protocols (EAP) und bietet somit eine durchgängige Kommunikation zwischen einem übergeordneten ERP-System, einer EtherCAT-Steuerung, und einem via Gateway angeschlossenen unterlagerten Feldbus-Gerät. AoE ist auch der standardisierte Weg, über den eine abgesetzte, herstellerunabhängige Diagnosesoftware Informationen zum Zustand des EtherCAT-Netzwerks abfragen kann.

1.10 Anlagenweite Kommunikation mit dem 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.

EtherCAT ermöglicht eine anlagenweite Kommunikation.

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

den Datenaustausch zwischen EtherCAT-MainDevices (MainDevice-MainDevice-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.

Anlagenweite Kommunikationsarchitektur realisiert mit dem EtherCAT Automation Protocol und Safety-over-EtherCAT.

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

EtherCAT ermöglicht die Integration dezentraler Feldbus-Schnittstellen.

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-MainDevice/SubDevice (Gateways), schnelle serielle Schnittstellen und andere Kommunikations-Interfaces angesprochen werden. Die Daten des eingebundenen Feldbusses stehen dem MainDevice im Prozessdatenabbild direkt zur Verfügung.

1.12 EtherCAT, Industrie 4.0 und IoT

Prozessoptimierung, vorausschauende Instandhaltung, Manufacturing-as-a-Service, adaptive Systeme, Ressourcenschonung, die intelligente Fabrik oder schlicht Kostensenkung – für die Nutzung von Prozessdaten in überlagerten Systemen gibt es zahlreiche gute Gründe.

Sei es das Internet of Things (IoT), Industrie 4.0, Made in China 2025 oder die japanische Industrial Value Chain Initiative (IVI): Allen Ansätzen gemein ist die Forderung nach nahtloser, kontinuierlicher und standardisierter Kommunikation über alle Ebenen hinweg. Sensordaten, die in die Cloud hochgeladen werden, sowie Auftragsdaten und Parameter, welche von ERP-Systemen in verteilte Geräte heruntergeladen werden; ein Zuführsystem, das sich zwei Maschinen teilen: Anforderungen an den Datenfluss gibt es sowohl in vertikaler wie horizontaler Richtung.

Aufgrund seiner Leistung, Flexibilität und der offenen Schnittstellen erfüllt EtherCAT bereits „von Natur aus“ die Anforderungen der digitalen Transformation: Herausragende Leistung ist die Voraussetzung, um Big Data-Anwendungen zu Steuerungsnetzwerken hinzuzufügen.

Die hohe Flexibilität von EtherCAT ermöglicht das Hinzufügen von Cloud-Connectivity zu bestehenden Systemen, ganz ohne die Steuerung „anfassen“ oder die SubDevices aktualisieren zu müssen: Mit Hilfe der Mailbox-Gateway-Eigenschaft des EtherCAT-MainDevice greifen Edge-Gateways auf sämtliche Daten innerhalb beliebiger EtherCAT-SubDevices zu. Hierbei kann das Edge-Gateway entweder ein abgesetztes Gerät sein, welches über TCP oder UDP/IP mit dem MainDevice kommuniziert, oder aber eine Software-Funktion, die sich auf derselben Hardware wie das EtherCAT-MainDevice selbst befindet.

Und die offenen Schnittstellen sind es, welche die Integration jedes beliebigen IT-basierten Protokolls innerhalb des MainDevice oder direkt in die SubDevices erlauben – sei es OPC UA, MQTT, AMQP oder jedes andere. So wird die direkte Verbindung ohne Technologiebrüche vom Sensor in die Cloud möglich.

Die Tatsache, dass all diese Eigenschaften bereits von vornherein Bestandteil der Technologie waren, beweist, wie zukunftsfähig die EtherCAT-Architektur ist. Sollten im Laufe der Entwicklung weitere Features relevant werden, werden diese selbstverständlich hinzugefügt und zwar ohne das Basis-Protokoll selbst zu ändern: EtherCAT ist seit der Einführung 2003 stabil.

Die neuen Time-Sensitive-Networking (TSN)-Features verbessern die Echtzeit-Eigenschaften der Controller-zu-Controller-Kommunikation. Unterstützt durch TSN können Steuerungen – sogar solche, die Cloud-basiert sind – über die vorhandene Ethernet-Infrastruktur auf ein Netzwerk aus EtherCAT-SubDevices zugreifen. Und da EtherCAT typischerweise nur ein Frame für ein gesamtes Netzwerk benötigt, erfolgt dieser Zugriff deutlich schlanker und somit schneller als bei jeder anderen Feldbus- oder Industrial-Ethernet-Technologie. Die ETG trägt zur TSN-Entwicklung bereits seit dem ersten Tag bei: Schon als TSN noch als AVB bekannt war, waren EtherCAT-Experten in der TSN-Arbeitsgruppe innerhalb der IEEE 802.1 aktiv.

Die EtherCAT Technology Group war zudem unter den ersten Feldbusnutzerorganisationen, welche eine Partnerschaft mit der OPC Foundation vereinbart haben. OPC UA stellt dem EtherCAT-Portfolio eine skalierbare TCP/IP-basierte Client-Server-Kommunikation mit integrierter Sicherheit zur Seite und ermöglicht so den verschlüsselten Datentransfer in MES/ERP-Systeme. Mit OPC UA Pub/Sub wurde die Nutzbarkeit von OPC UA in Maschine-zu-Maschine-Applikationen sowie für die vertikale Kommunikation mit Cloud-basierten Diensten verbessert. Die ETG trägt aktiv zu diesen Entwicklungen bei und sorgt dafür, dass sie sich nahtlos in die EtherCAT-Umgebung einfügen.

EtherCAT ist nicht nur IoT-ready, EtherCAT ist IoT!

2. EtherCAT-Schnittstellen-Implementierung

nach oben

Die EtherCAT-Technologie wurde speziell auf niedrige Kosten optimiert. Jeder Sensor, jedes E/A-Gerät und jeder Embedded-Controller soll in der Lage sein, eine EtherCATAnschaltung zu geringen Kosten einbinden zu können. Nicht die EtherCAT-Schnittstelle, sondern die Geräteapplikation bestimmt die Leistungsanforderung der benötigten CPU.

Dem Anwender ist hingegen die Interoperabilität der EtherCAT-Geräte wichtig. Daher ist jeder Gerätehersteller verpflichtet, vor der Markteinführung 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 MainDevice-Implementierung

Die Hardware-Anforderungen an ein EtherCAT-MainDevice sind denkbar einfach: Ein Standard-Ethernet-Port ist ausreichend. Damit ist EtherCAT die Ethernet-Lösung für harte Echtzeit-Anforderungen, die ohne spezielle MainDevice-Hardware auskommt; der On-Board-Ethernet-Controller oder eine günstige 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 MainDevice und Netzwerk benötigt also keine CPU-Performance. Dabei ist das Prozessabbild bereits fertig sortiert, da das Mapping bei EtherCAT nicht im MainDevice, sondern in den SubDevices erfolgt – die Peripheriegeräte fügen ihre Daten an die entsprechende Stelle im durch- laufenden Frame ein und lesen die für sie bestimmten Daten im Durchlauf.

Das bedeutet, die Leistungsanforderung der MainDevice-CPU wird nicht durch die EtherCAT-Anschaltung bestimmt, sondern durch die gewünschte MainDevice-Applikation. Speziell für die kleine und mittlere Steuerungstechnik und für klar umrissene Anwendungen ist die Implementierung eines EtherCAT-MainDevice sehr einfach. Auf einer Vielzahl von Betriebssystemen wurden bereits EtherCAT-MainDevices implementiert: Windows und Linux in verschiedenen Ausprägungen, QNX, RTX, VxWorks, Intime und eCos sind nur einige Beispiele.

Zur Entwicklungsunterstützung einer MainDevice-Implementierung stellen ETG-Mitglieder eine ganze Bandbreite an Möglichkeiten bereit: von frei verfügbaren EtherCAT-MainDevice-Bibliotheken zum Download über MainDevice Sample Codes bis hin zu kompletten Paketen inkl. Dienstleistungen für unterschiedliche Echtzeit-Betriebssysteme und Prozessoren.

Der Umfang der verfügbaren MainDevice-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-MainDevice-Classes-Spezifikation definiert daher zwei Klassen von MainDevice-Geräten: Ein Class-A-MainDevice ist ein Standard-EtherCAT-MainDevice, ein Class-B-MainDevice eines 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.

Typische EtherCAT-MainDevice-Architektur

2.2 SubDevice-Implementierung

Im SubDevice kommt ein EtherCAT SubDevice 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 SubDevice 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.

SubDevice-Hardware: EtherCAT SubDevice Controller mit Host CPU
In einem nichtflüchtigen Speicherbaustein (z.B. einem EEPROM) werden Informationen über die Hardware-Konfiguration der PDI-Schnittstelle abgelegt. Zudem werden in diesem SII (SubDevice Information Interface) die zentralen Geräteeigenschaften abgelegt, sodass ein EtherCAT-MainDevice auch ohne vorhandene Gerätebeschreibungsdatei das Gerät betreiben kann. Die vollständige Beschreibung der Geräteeigenschaften wird in der Gerätebeschreibungsdatei der EtherCAT SubDevice 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.

SubDevice-Hardware: EtherCAT SubDevice Controller mit direktem E/A

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

Somit kann in wenigen Schritten ein voll funktionsfähiges MainDevice-SubDevice-EtherCAT-Netzwerk in Betrieb genommen werden.

Ein SubDevice-Implementation-Guide auf der ETG-Webseite gibt wertvolle Tipps und Hinweise auf weiterführende Dokumente zur SubDevice-Implementierung:
ETG.2200 EtherCAT and EtherCAT P SubDevice Implementation Guide

3. Konformität und Zertifizierung

nach oben

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-MainDevice, EtherCAT-SubDevice 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 MainDevice- und SubDevice-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.
Mehr...

3.2 Conformance Test Tool (CTT)

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

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 SubDevice 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.
Mehr...

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

3.4 EtherCAT Test Center

Die ETG hat offizielle EtherCAT Test Center (ETC) in Nürnberg (Deutschland), Kyoto (Japan) , Peking (China) sowie in Savage bei Minneapolis in Minnesota, USA etabliert. Die ETCs führen nicht nur den offiziellen EtherCAT Conformance Test durch, sondern liefern den ETG-Mitgliedern zudem qualifiziertes Feedback sowie technischen Support bei der Implementierung. Darüber hinaus stellen die ETCs Räumlichkeiten für den Interoperabilitätstest. Verläuft ein Test erfolgreich, stellt die EtherCAT Technology Group (ETG) ein Konformitätszertifikat aus.
Mehr...

4. Internationale Normung

nach oben

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.