Das Ethercat Automation Protocol: Ethercat durchgängig in allen Ebenen

Die Geräte der Feldebene werden von einer übergeordneten Steuerung kontrolliert. Große Anlagen, wie in der Automobilindustrie, werden aus mehreren Maschinen aufgebaut. Hierbei müssen die Steuerungen der einzelnen Anlagenteile Daten austauschen. Unter Umständen kann sogar der Datenaustausch zwischen E/A-Geräten aus verschiedenen Anlangenteilen sinnvoll sein. Für ein Kommunikationsprotokoll, das im Bereich der Produktionsleitebene Anwendung finden soll, ergeben sich folgende Anforderungen: – Datenaustausch zwischen Ether- cat-Mastern (Master-Master- Kommunikation) = Datenaustausch auf Steuerungsebene – Datenaustausch zwischen Ethercat-Master und Visualisierung – Durchgriff von überlagerten Steue- rungen auf Teilnehmer in unterla- gerte Ethercat-Segmente (Routing) – Datenaustausch zwischen Ethercat-Mastern und anderen Teilnehmern, wie Konfigurations-Tools Zusätzliche Anforderungen: – Standard-Ethernet-Kommunika- tionsschnittstelle – keine strengen Anforderungen an Zykluszeit und Synchronität – zyklische Kommunikation im Milli- sekundenbereich – Einsatz von Standard-Infrastrukturelementen wie Switche zur Vernetzung der Teilnehmer Diese Anforderungen werden vom Ethercat Automation Protocol (EAP) erfüllt, das damit die vertikale Integration von Ethercat im Gesamtsystem stärkt. Ethercat-Protokolltypen Das Ethercat-Protokoll kann über Ethernet (EtherType 0x88A4), über UDP (User Datagram Protocol, UDP-Port 0x88A4) oder per TCP (Transmission Control Protocol, TCP-Port 0x88A4) übertragen werden. Das Übertragungsmedium ist dabei nicht relevant: Fast-Ethernet- oder Gigabit-Ethernet-Verbindungen auf Kupfer oder Glasfaser sind ebenso möglich, wie die Nutzung des Protokolls über eine Wireless-Verbindung. Somit können auch Anlagenteile eingebunden werden, die nicht über eine feste Leitung verbunden werden können (z.B. Flurförderfahrzeuge, Regalbediensysteme). In den Nutzdaten dieser Telegramme schließt sich der Ethercat-Frame an (Bild 2). Der Header des Ethercat-Frames spezifiziert den Ethercat-Protokolltyp (Tabelle 1). Ethercat-Slaves, die an einen Ethercat-Master angeschlossen sind, verwenden immer das Ethercat Device Protocol. Für die Umsetzung des Protokolls wird in den Ethercat-Slaves ein Ether­cat-Kommunikations-Chip, der Ethercat Slave Controller (ESC), verwendet. Dieser wertet ausschließlich Telegramme vom Typ 1 aus. Sowohl zyklische als auch azyklische Daten können in einem Ethercat-Frame mit diesem Typ übertragen werden. Für das Ethercat Automation Protocol werden die Typen 4 und 5 verwendet. Folgen Prozessdaten, wird der Typ 4 verwendet, bei Mailbox-Daten steht der Typ 5 im Ethercat Frame Header. Die Mailbox-Protokolle (CoE, SoE und FoE), wie sie bereits mit dem Ethercat Device Protocol genutzt werden, können ebenso mit dem Ethercat Automation Protocol verwendet werden. EAP-Nachrichten-Routing Damit Master-Geräte untereinander Daten austauschen können oder z.B. ein Konfigurations-Tool Parameter in einem Antrieb im unterlagerten Ethercat-Segment einstellen kann, muss ein Nachrichten-Routing vom Konfigurations-Tool über den Ethercat-Master bis zum -Slave möglich sein. Hierfür wird das Ethercat Mailbox Protocol AoE (Automation Device Protocol over Ethercat) verwendet. Dieses Protokoll hat den Vorteil, dass es routingfähig ist und somit durch mehrere Ebenen durchgereicht werden kann, um unterlagerte Objektverzeichnisse zu erreichen. Jeder Ethernet-Port im Master wird als AoE-Gerät implementiert und erhält eine eigene AoE-NetID. Im Beispiel (Bild 3) erhalten Port 1 und Port 2 je eine AoE-NetID. Das Routing von einem Port zum anderen wird von einem AoE-Router im Master übernommen, welcher ebenfalls eine AoE-NetID zugewiesen bekommt. Über die AoE-NetID lässt sich auf jeden Port bzw. jedes AoE-Gerät und die mit diesem verbundenen Informationen zugreifen. Die Informationen, die dem Netzwerk zur Verfügung gestellt werden, sind in Objektverzeichnissen strukturiert. Deren genauer Inhalt unterscheidet sich je nach Aufgabe des AoE-Geräts/-Ports. Strukturierung der Gerätedaten Objektverzeichnis Ein Objektverzeichnis ist eine Liste mit Variablen und Parametern. Jeder Eintrag wird über einen eigenen Index und gegebenenfalls einen Subindex adressiert. Der gesamte Indexraum ist in verschiedene Bereiche unterteilt. Durch die Unterteilung des Indexraums in festgelegte Bereiche wird die Strukturierung der Daten übersichtlich. Außerdem ist dies die Grundlage für die Verwendung von Algorithmen, mit denen die Zusammenstellung der Prozessdaten (PDO-Konfiguration und PDO-Zuordnung) organisiert wird. Profilspezifischer Bereich für das EAP Der profilspezifische Bereich ab Index 0x6000 wird durch sogenannte Geräteprofile festgelegt. Für viele Geräteklassen (Antriebe, E/A-Geräte) wurden entsprechende Geräteprofile spezifiziert. Für das EAP wird das Modular Device Profile (MDP, Profilnummer 5001) verwendet. Dieses Profil legt die Verwendung des Indexraums entsprechend einer Tabelle fest. Spezielle Geräteklassen werden dabei durch Subprofile in dieses Raster eingeordnet (z.B. für Gateway-Geräte). Das Ethercat Automation Protocol besitzt eine eigene Subprofilnummer (1000), eben­so wie das Ethercat Device Protocol (1100) für die Ethercat-Master-Funktion zum unterlagerten Ethercat-Segment. Der AoE-Router besitzt die Subprofilnummer 9000. Auf einem Master, der sowohl das Ethercat Automation Protocol als auch das Ethercat Device Protocol unterstützt, haben die Ports zum jeweiligen Netzwerk ein eigenes Objektverzeichnis mit der entsprechenden Subprofilnummer (Bild 3). 1.Subprofil 1000 – Ethercat Automation Protocol Das Objektverzeichnis für das Subprofil 1000 wird für die Konfi- guration der Kommunikationsbe- ziehung zwischen zwei EAP-Gerä- ten verwendet. Es beschreibt die Prozessdaten, wie sie für das EAP verwendet werden. 2.Subprofil 1100 – Ethercat Device Protocol Das Objektverzeichnis des Ether-cat-Segments listet alle ange-schlossenen Slaves auf. Ein Slave wird dabei im Objektverzeichnis als Modul beschrieben. 3.Subprofil 9000 – Ethercat Router Information Im Router-Objektverzeichnis ste- hen alle verfügbaren Schnittstellen des Geräts und deren AoE-NetIDs. EAP – Zyklischer Datenaustausch Der 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 dabei über das Objektverzeichnis nach dem Subprofil 1000. Im \’Polled\‘-Betrieb werden die Daten von den Teilnehmern abgefragt. Hierzu schickt ein Teilnehmer, häufig der übergeordnete Leitrechner, ein Telegramm zu den Teilnehmern, woraufhin diese mit einem eigenen Telegramm antworten. Hierdurch ist auch eine Synchronisierung der Teilnehmer möglich. Aufbau der Prozessdaten Der Inhalt eines Process-Data-Telegramms wird wie die Prozessdaten eines Ethercat-Slaves beschrieben. Ein Telegramm entspricht einer SyncManager Area, sodass der Aufbau der Prozessdaten eines Telegramms über die PDO-Zuordnung und PDO-Konfiguration festgelegt wird (Bild 4). Ein Gerät definiert seine Ausgangsvariablen (Tx Process Variables) im Indexbereich ab 0x6000. Für jede Variable wird ein Index verwendet (Variable 1 Þ 0x6000, Variable 2 Þ 0x6001 usw.). Mit dem tatsächlichen Wert der Variable wird der Name, die Länge und der Variablentyp, z.B. Prozessdatum oder Diagnosedatum, verbunden. Im Process-Data-Telegramm wird nur der Variablenwert selbst übertragen. Die Process Variables können dann beliebig mit Hilfe der Tx Mapping PDOs ab 0x1A00 gruppiert werden. Dabei kann eine Variable auch in mehrere PDOs übertragen werden. Die über das Mapping beschriebenen Strukturen von Variablen werden mit einer Variable ID, Version (Version) und Alter (Quality) kombiniert. Dies geschieht im Tx-Process-Data-Bereich ab 0xD000. Die Process Data müssen nun für die Übertragung noch einem Ethernet-Frame zugeordnet werden. Die Zuordnung und Reihenfolge jedes Process Data wird über die Assign-Objekte im Bereich ab 0x8000 festgelegt. Auf der Empfängerseite wird der Absender des empfangenen Frames durch die Publisher-ID im Frame-Header bestimmt. Mit dieser und der Variable ID und Version aus dem PDO-Header kann der Empfänger den Process-Data-Index (ab 0xE000) finden, in dem der Verweis auf seine interne Zielvariable steht. Über das gefundene Mapping-PDO (ab 0x1600) wird also der Index der Zielvariablen bestimmt, in dem der empfangene Variablenwert als Eingangsvariable gespeichert wird. Die Konfiguration der Prozessdatenstruktur auf der Empfängerseite ist, wie auf der Absenderseite, beliebig. Welcher Index einer Rx Process Variable zugeordnet wird, ist unabhängig von dem Index der Tx Process Variable. Da die Ausgangs- und Eingangsvariablen vorab konfiguriert werden, ist ein zusätzlicher Verbindungsaufbau vor Kommunikationsbeginn nicht mehr notwendig. EAP – Azyklischer Datenaustausch Zur Konfiguration der Ausgangs- und Eingangsvariablen und um auf die Objektverzeichnisse des Masters oder auf die der Ethercat-Slaves zuzugreifen, wird ein azyklischer Zugriff auf diese ermöglicht. Hierzu wird das AoE-Protokoll (ADS over Ethercat) verwendet. Damit können mehrere Objektverzeichnisse adressiert werden. Als Transportprotokoll wird ein Telegramm vom Typ 5 (Mailbox-Kommunikation) verwendet. Der Aufbau des Frames ist dabei identisch mit der Mailbox-Kommunikation innerhalb eines Ethercat-Segments. Auf das AoE-Protokoll können wiederum die Mailbox-Protokolle CoE, SoE und FoE abgebildet werden. Dadurch kann z.B. ein Konfigurations-Tool an den Master angeschlossen werden, um dann auf einen Antrieb im Ethercat-Netzwerk für Konfigurationszwecke zuzugreifen. Beispiel einer Anlagenautomation mit EAP Die Fertigung von Solarmodulen integriert eine Vielzahl von Prozessschritten, für die Markierungs- und Identifikationssysteme, messtechnische Einheiten und spezielle Handlingsmodule eingesetzt werden. Die verwendete Förderanlage ist in bis zu 14 Prozessinseln aufgeteilt, wobei jedes Segment mit einem Steuerungs- und einem Bedienrechner ausgestattet ist. Hinzu kommen Bedienpanels, die bei Bedarf an jedem Punkt der Fertigungslinie anschließbar sind. Jede Station tauscht bidirektional mit der jeweils vorherigen und der nachfolgenden Station Status- und Kontrollinformationen aus: 600Byte in jede Richtung mit einer Zykluszeit von 10ms. Hinzu kommt die Kommunikation zum Kontrollrechner, der zusätzlich mit jeder Station bis zu 1kByte Daten bidirektional austauscht.