| von Maneesh Soni

Für die Vernetzung und Kommunikation in Industrie- oder Fabrikumgebungen taugen keine herkömmlichen IT-Netzwerke. Die Branchen nähern sich aber an: Ethercat gehört zu den führenden Ethernet-basierenden Feldbussen. Das echtzeitfähige Protokoll verbindet Ein- und Ausgabegeräte, Sensoren und speicherprogrammierbare Steuerungen (SPS). Das von der deutschen Firma Beckhoff erfundene Protokoll wurde später durch die Ethercat Technology Group (ETG) standardisiert. Inzwischen gehören über 1700 Unternehmen aus 52 Ländern zur ETG. Um Interoperabilität zu gewährleisten, unterhält die ETG mehrere Programme, die die Einhaltung der technischen Spezifikationen gewährleisten.

Effizienz und Topologie

Im industriellen Umfeld ist herkömmliches Ethernet bei kleinen Datenmengen zu wenig effizient und es fehlt der nötige Determinismus für Echtzeit-Anwendungen. Jenseits des 10-MBit/s-Urahns ist Ethernet auch nur als Sterntopologie einsetzbar, während die Automatisierung auf Bus-Strukturen setzt. Ethercat ergänzt Ethernet durch eine Reihe zusätzlicher Features und setzt bestimmte Konfigurationen voraus. Es wird damit zu einer effizienten Netzwerktechnologie für Automatisierungszwecke, ohne die Ethernet-Konformität aufzugeben.

Bild 1: In einem Ethercat-Netzwerk kommuniziert der Master mit verschiedenen in Serie geschalteten Slaves.

Bild 1: In einem Ethercat-Netzwerk kommuniziert der Master mit verschiedenen in Serie geschalteten Slaves.Texas Instruments

Das Design ermöglicht es, jeden Standard-PC mit Ethernet als Ethercat-Master zu verwenden, um mit speziellen Ethercat-Slaves zu kommunizieren (Bild 1). Ethercat-Master und -Slaves eignen sich für sämtliche Geräte eines Fabriknetzwerks, wie Automatisierungssteuerungen, Bediengeräte, dezentrale I/O-Einheiten, Sensoren, Aktoren, Antriebe und weitere Einheiten. Der Ethercat-Standard unterstützt jede Topologie (Linie, Stern oder Baum). Die in Feldbus-Netzwerken häufig verwendeten Busstrukturen lassen sich mit Ethercat gut realisieren.

Senden und empfangen

Jedes E/A-Gerät besitzt eine empfangende und eine sendende Ethercat-Schnittstelle; Switching-Hardware wie bei Ethernet ist daher nicht nötig. Dank der Reichweite von 100 m mit Kupferleitungen (weitere Distanzen mit Lichtwellenleitern) kann Ethercat Tausende von Geräten verbinden, die sich über einen großen geografischen Bereich verteilen. Sind die Übertragungsdistanzen kurz (etwa in einer Backplane) setzt Ethercat auf die differenzielle Signalisierungstechnik E-Bus.

Auf einen Blick

Ethercat erweitert das etablierte Ethernet um Echtzeit-Eigenschaften, eignet sich für Bus-Strukturen und arbeitet viel effizienter. Abgesehen vom Ethercat-Master ist dazu spezielle Hardware nötig. Warum das so ist und welche Architekturen in Frage kommen, erklärt der Beitrag.

Von Ethernet unterscheidet sich Ethercat vor allem durch die On-the-fly-Verarbeitung: Die Knoten eines Ethercat-Netzwerks lesen gleichsam im Vorbeigehen die Daten eines weitergeleiteten Frames. Alle Ethercat-Frames haben ihren Ursprung im Ethercat-Master, der Befehle und Daten an seine Slaves sendet. Daten, die an den Master zurückgehen, schreiben die Slaves in die durchgeleiteten Frames. Eine Punkt-zu-Punkt-Übertragung vieler kleiner Frames zwischen Master und den einzelnen Slaves ist damit unnötig, was die Kommunikationseffizienz drastisch verbessert. Allerdings braucht jeder Slave zwei Ethernet-Ports: Er muss einen Frame durchleiten und gleichzeitig aus ihm lesen oder in ihn hineinschreiben. Die Slaves benötigen deshalb spezielle Hardware.

Als Resultat aller Verbesserungen kann ein 100-MBit/s-Netzwerk unter Ethercat über 90 Prozent der Bandbreite tatsächlich nutzen. In Netzwerken, in denen der Master separat mit jedem Slave-Knoten kommunizieren muss, sind es weniger als 5 Prozent.

Das Ethercat-Telegramm

Bild 2: Ethercat-Telegramme bestehen aus mehreren Ethercat-Datagrammen. Das Telegramm selbst kann direkt in einem Ethernet-Frame, oder in einem UDP/IP-Paket stecken.

Bild 2: Ethercat-Telegramme bestehen aus mehreren Ethercat-Datagrammen. Das Telegramm selbst kann direkt in einem Ethernet-Frame, oder in einem UDP/IP-Paket stecken.Texas Instruments

Wie Bild 2 zeigt, wird das Ethercat-Telegramm üblicherweise in einem Ethernet-Frame gekapselt. Das Telegramm enthält eines oder mehrere Ethercat-Datagramme, die für die Ethercat-Slaves bestimmt sind. Derartige Ethercat-Telegramme sind direkt im Ethernet-Header mit dem Ethercat-Typ gekennzeichnet oder zunächst in ein IP/UDP-Paket verpackt. IP/UDP erzeugt zwar Overhead, das Ethercat-Protokoll lässt sich damit aber auch über Netzwerk-Router hinweg übermitteln.

Jedes Ethercat-Datagramm ist ein Kommando, das aus einem Header, den Daten und einem Working-Counter besteht. Der Header und die Daten spezifizieren die vom Slave auszuführende Operation, während der Arbeitszähler vom Slave aktualisiert wird. Der Master kann hieran erkennen, dass sein Befehl von einem Slave verarbeitet wurde.

Das Protokoll

Jeder Slave verarbeitet die Ethercat-Pakete praktisch im Vorbeigehen. Er empfängt und analysiert jedes Paket, um anschließend Aktionen einzuleiten, sollte das Ethercat-Datagramm an ihn adressiert sein. Quasi gleichzeitig leitet der Slave das gesamte Datagramm über den zweiten Port weiter – er aktualisiert vorher nur den Inhalt und die CRC-Prüfsumme. Das Senden beginnt bereits, lange bevor der Slave das komplette Paket empfangen hat.

Mithilfe der Datagramme unterscheidet der Ethercat-Master bis zu vier Millionen Adressen, genauer: 65.536 Ethercat-Slaves mit jeweils 65.536 Adressen. Für die Ethercat-Datagramme gelten keinerlei Beschränkungen hinsichtlich der Reihenfolge: Die Slaves können sich an beliebiger Stelle im Netzwerk befinden.

Es gibt zwei Arten von Ethercat-Datenübertragungen: zyklische und azyklische. Zyklische Daten sind die Prozessdaten, die in periodischen Intervallen oder Zykluszeiten anfallen. Bei den azyklischen Daten handelt es sich in der Regel um unkritische und meist große Datenmengen, die als Reaktion auf einen Befehl der Steuerung anfallen. Einige azyklische Daten (etwa Diagnosedaten) sind jedoch kritisch und stellen hohe Anforderungen an das Timing. Ethercat trägt diesen unterschiedlichen Datenübertragungsanforderungen durch optimierte Adressierungsschemata Rechnung: physische Adressierung, logische Adressierung, Mehrfach-Adressierung und Broadcast-Adressierung.

Speicheradressierung

Um verschiedene Adressierungsarten zu berücksichtigen, enthält jeder Slave eine Fieldbus Memory Management Unit (FMMU). Dank der FMMUs kann Ethercat den Speicherbereich jedes Slave-Geräts als Bestandteil eines 4 GByte großen Adressraums ansprechen. Der Ethercat-Master stellt während der Initialisierungsphase ein komplettes Prozessabbild zusammen und kann anschließend mithilfe eines einzigen Ethercat-Kommandos Zugriff auf die Slave-Einheiten bis zur Bit-Ebene herab ausführen. Das ermöglicht die Kommunikation mit einer beliebigen Zahl von E/A-Kanälen durch große und kleine Geräte hindurch und über das gesamte Feldbus-Netzwerk hinweg.

Die hardwarebasierte FMMU und die On-the-fly-Verarbeitung verleihen Ethercat-Netzwerken eine sehr hohe Effizienz. Bei der Kommunikation zwischen Steuerungen und Feldgeräten sind Zykluszeiten im Mikrosekundenbereich möglich. Das macht es beispielsweise möglich, neben der Positions- auch die Stromregelung verteilter Antriebe per Ethercat zu implementieren.

Dezentrale Taktung

Wenn dezentral angeordnete Knoten gleichzeitige Aktionen ausführen sollen, müssen die internen Takte dieser Geräte synchronisiert sein. Jeder Ethercat-Slave liest dazu Zeitstempel von ankommenden und abgehenden Ethercat-Paketen. Der Master nutzt die Zeitstempelinformationen der Slaves und berechnet daraus die präzisen Laufzeiten eines jeden einzelnen Slaves. Auf dieser Basis werden die Takte der Slaves eingestellt und auf 1 µs genau zueinander synchronisiert. Ein zusätzlicher Vorteil der präzisen Taktsynchronisation ist, dass sich alle durchgeführten Messungen auf die einheitliche Zeit beziehen lassen. Es entfällt damit auch die Unsicherheit, die sich durch den Jitter der Kommunikation zwischen den Geräten einstellt.

In der industriellen Kommunikation ist die Verwendung von Geräteprofilen eine sehr beliebte Methode, um die Funktionalität und die Parameter von Geräten zu beschreiben. Ethercat bringt keine neuen Geräteprofile, hält aber Schnittstellen zu bestehenden Geräteprofilen bereit, sodass sich ältere Feldbus-Geräte problemlos für die Nutzung von Ethercat upgraden lassen. Zu diesen Schnittstellen gehören CAN-Open over Ethercat und Sercos over Ethercat. Sie ermöglichen die Nutzung von CAN-Open und Sercos, indem sie deren Datenstrukturen auf Ethercat abbilden.

Komponenten eines Ethercat-Knotens

Bild 3: Zu einem Ethercat-Knoten gehören die Ethernet- und die Echtzeit-Applikation, die auf verschiedene Weise auf das Netzwerk zugreifen.

Bild 3: Zu einem Ethercat-Knoten gehören die Ethernet- und die Echtzeit-Applikation, die auf verschiedene Weise auf das Netzwerk zugreifen.Texas Instruments

Jeder Ethercat-Knoten besteht aus drei Komponenten (Bild 3): der Bitübertragungsschicht (Physical Layer, unten), der Verbindungsschicht (Data Link Layer, Mitte) und der Anwendungsschicht (Application Layer, oben). Der Physical Layer wird per Kupferleitung (100BASE-TX), per Lichtwellenleiter (100BASE-FX) oder per E-Bus auf Basis der LVDS-Signalisierung implementiert. Die MAC-Komponente (Media Access Control) implementiert man dabei gemäß den Ethercat-Spezifikationen in einem speziellen ASIC oder FPGA.

Auf die MAC-Komponente setzt die industrielle Applikation auf, die letztlich das applikationsspezifische Verhalten bestimmt. Hinzu kommt ein standardisierter TCP/IP- und UDP/IP-Stack zur Unterstützung Ethernet-basierter Geräteprofile. Je nach Komplexität des Geräts kann der Ethercat-Knoten per Hardware implementiert werden, oder als eine Kombination aus Hard- und Software mit einer Embedded-CPU.

Typischer Ethercat-Knoten

Bild 4: Struktur eines Ethercat-Geräts mit digitaler E/A-Funktionalität (oben), mit ASIC und einem externen Prozessor (Mitte) oder der Single-Chip-Lösung von TI (unten).

Bild 4: Struktur eines Ethercat-Geräts mit digitaler E/A-Funktionalität (oben), mit ASIC und einem externen Prozessor (Mitte) oder der Single-Chip-Lösung von TI (unten).Texas Instruments

Viele einfache Ethercat-Geräte lassen sich mit den heute angebotenen Lösungen auf Basis eines einzigen ASIC oder FPGA realisieren. Die erste Darstellung in Bild 4 zeigt diese Architektur in vereinfachter Form. Sie eignet sich hervorragend für simple und kostengünstige E/A-Knoten. Hier ist keine Software erforderlich, sondern die gesamte Funktionalität ist hardwaremäßig implementiert.

Andere Ethercat-Knoten brauchen zusätzliche Verarbeitungsleistung, typischerweise umgesetzt als externer Prozessor, häufig mit integriertem Flash-Speicher (Bild 4, Mitte). Der Prozessor übernimmt die Verarbeitungsaufgaben auf der Anwendungsschicht. Der Prozessor steuert zum Beispiel einen Sensor an, implementiert den Gerätetreiber und verarbeitet den Ethercat-Applikationsstack. Die tieferen Schichten sind weiterhin als ASIC oder FPGA umgesetzt. Eine solche Architektur ist teurer als die eines einfachen digitalen E/A-Geräts, sie überlässt allerdings den Entwicklern die Wahl des Prozessors, der ihren Anforderungen und Kostenvorgaben am besten entspricht.

Es gibt jedoch noch einen weiteren Ansatz, bei dem die Ethercat-Implementierung eine von mehreren Peripheriefunktionen eines Bausteins mit integrierter CPU ist (Bild 4, unten). Viele FPGAs besitzen bereits einen integrierten Prozessor oder bieten die Möglichkeit, einen solchen zu konfigurieren. Von einigen Anbietern gibt es außerdem ASICs, die sowohl mit Ethercat-Funktionalität als auch mit einem Prozessor bestückt sind – meist aber nur mit einem 8-Bit-Mikrocontroller. Eine reine FPGA-Lösung bietet zwar die größte Flexibilität, ist aber auch am teuersten.

Ethercat als Single-Chip-Lösung

Bild 5: Ethercat-Slave, implementiert auf einem ARM-Mikroprozessor des Typs Sitara AM335x von TI.

Bild 5: Ethercat-Slave, implementiert auf einem ARM-Mikroprozessor des Typs Sitara AM335x von TI.Texas Instruments

Als weitere Alternative gibt es eine Single-Chip-Lösung von Texas Instruments (Bild 5): Sie kombiniert einen ARM Cortex-A8-Prozessor mit vielen weiteren Peripheriefunktionen und Schnittstellen und kann laut Hersteller die Materialkosten um 30 % senken.

Die Integration eines PRU-Subsystems (Programmable Real-time Unit), die eine sehr maschinennahe Interaktion mit den MII-Schnittstellen unterstützt, befähigt das PRU-Subsystem zur Implementierung spezieller Kommunikationsprotokolle wie etwa Ethercat. Der gesamte Ethercat MAC-Layer wird per Firmware in das PRU-Subsystem gekapselt. Die PRUs verarbeiten die Ethercat-Telegramme im Vorbeigehen, analysieren sie, decodieren die Adresse und führen die Ethercat-Kommandos aus.

Interrupts werden für jegliche Kommunikation mit dem ARM-Prozessor genutzt, auf dem sowohl der Ethercat-Stack als auch die industrielle Applikation laufen. Auch die Weiterleitung der Frames in umgekehrter Richtung übernimmt das PRU-Subsystem. Da die gesamte Ethercat-Funktionalität im PRU-Subsystem steckt, bleibt der ARM-Prozessor für komplexe Applikationen verfügbar. Alternativ kann man für einfache Geräte mit begrenztem Kostenbudget (zum Beispiel in dezentralen E/A-Funktionen) eine langsamere Prozessorversion wählen.

Die Ethercat-Softwarearchitektur

Die Software ist ein entscheidender Faktor, um sicherzustellen, dass die Ethercat-Implementierung reibungslos auf den Geräten läuft. Bei einer Single-Chip-Lösung sind in erster Linie drei Komponenten zu beachten:

  • Mikrocode, der die Layer-2-Funktionalität in der PRU implementiert
  • Applikations-Stack des Ethercat-Slaves auf dem ARM-Mikroprozessor
  • Industrielle Applikation, je nach Endgerät

Bild 5 zeigt dieses Konzept am Beispiel der kürzlich angekündigten Sitara-MCU-Reihe AM335x von Texas Instruments (ARM Cortex A8). Man erkennt, wie sich zur Implementierung des Ethercat-Protokolls mehrere Peripheriefunktionen in einen Chip integrieren lassen. Die Software wird durch unterstützende Komponenten ergänzt, zum Beispiel die Protokollanpassungsschicht und Gerätetreiber, die TI im Rahmen des Software Development Kits zur Verfügung stellt.

Die Single-Chip-Lösung gibt dem Entwickler damit enorme Freiheit: Er kann sich voll auf die Software konzentrieren und dennoch eine effiziente industrielle Automatisierungslösung designen.

Maneesh Soni

: Systems Engineering Lead für Industrial Automation Products in der Sitara-ARM-Mikroprocessor-Gruppe bei Texas Instruments.

(lei)

Kostenlose Registrierung

Der Eintrag "freemium_overlay_form_all" existiert leider nicht.

*) Pflichtfeld

Sie sind bereits registriert?