Kommunikation

So kann mit programmierbarem SoC bei Ethercat gespart werden

| Autor / Redakteur: Punya Parkash, David Zaucha / Sariana Kunze

Einsparmöglichkeit bei Ethercat: Programmierbare SoC-Bausteine erzielen eine Ersparnis bei den Ausrüstungskosten, bieten mehr Vielseitigkeit und bescheren längere Lebenszyklen.
Einsparmöglichkeit bei Ethercat: Programmierbare SoC-Bausteine erzielen eine Ersparnis bei den Ausrüstungskosten, bieten mehr Vielseitigkeit und bescheren längere Lebenszyklen. (Bild: gemeinfrei / CC0)

Programmierbare SoC-Bausteine (System-on-Chip) sollen Ethercat weiter im Markt vorantreiben. Denn die Bausteine sollen eine deutliche Kosteneinsparung gegenüber der hardwareintensiven Architektur von Ethercat-Netzwerken erzielen.

Ethercat ist eines von vielen Echtzeit-Ethernet-Protokollen, die es in der industriellen Automatisierungstechnik zu großer Verbreitung gebracht haben. Ethercat kann sehr kurze Zykluszeiten erzielen und zur präzisen Verteilung eines Echtzeit-Takts dienen. Bisher waren Ethercat-Slave-Knoten vorwiegend als recht hardwareintensive Lösungen implementiert, die die für Ethercat erforderliche ‚on-the-fly‘, d.h. im Durchlauf erfolgende Echtzeitverarbeitung und -synchronisation, übernehmen. Bei diesen Implementierungen werden die Ethercat- und Slave-Funktionen von mehreren Bauelementen ausgeführt. Neuere technische Fortschritte haben allerdings programmierbare SoC-Bausteine hervorgebracht, die den Anwendern industrieller Systeme greifbare Einsparungen bei den Ausrüstungskosten, mehr Vielseitigkeit und längere Lebenszyklen bescheren.

Ein EtherCat-Netzwerk besteht aus Master- und Slave-Knoten. Die Master-Knoten, die das Netzwerk verwalten und konfigurieren, sind in der Regel als Industrie-PCs ausgeführt. Die Architekturen der Slave-Knoten sind dagegen unterschiedlich – je nach dem finalen Equipment oder der Maschine, die zu dem betreffenden Knoten gehört. Ethercat nutzt ein On-the-fly-Kommunikationsschema. Die Datenpakete oder Telegramme werden also nicht empfangen, verarbeitet und beantwortet, wie es in einem typischen Ethernet-Netzwerk der Fall ist, sondern beim Durchlaufen des Knotens gelesen und ergänzt. Die Kommunikation wird hierdurch nur um wenige Bitzeiten versetzt und ist somit erheblich effizienter als bei typischen Punkt-zu-Punkt-Ethernet-Netzwerken. Zur Unterstützung dieser Vorgänge ist spezielle Hardware mit zwei Ethernet-Ports erforderlich, damit die Telegramme mit minimaler Verzögerung gelesen, geschrieben und weitergeleitet werden können.

Hardware-Implementierung von Ethercat-Netzwerken

Von der Funktion her setzt sich ein Ethercat-Slave-Knoten aus drei Hauptabschnitten zusammen: der physischen Anbindung, der Data-Link-Verarbeitung und der Applikationsverarbeitung. Die physische Anbindung an das Netzwerk erfolgt mithilfe spezieller Chips, die der Ethernet IEEE 802.3 MAC-Definition (Media Access Control) gemäß IEEE 802.3 entsprechen. Unabhängig von der jeweiligen Architektur müssen alle Slaves diese Funktionen enthalten. Zum Data Link Layer (Sicherungsschicht) gehört der Ethercat Slave Controller (ESC). Dieser übernimmt die Verarbeitung des On-the-fly-Ethercat-Kommunikationsprotokolls über eine als Process Data Interface (PDI) bezeichnete Schnittstelle zum Speicher des Slaves. In der Vergangenheit wurde die Verarbeitung der Ethercat-Datenkommunikation von einem Chip, und zwar üblicherweise von einem FPGA (Field Programmable Gate Array) oder einem ASIC (Application Specific Integrated Circuit) vorgenommen. Der dritte und letzte Funktionsabschnitt eines Slaves ist der Applikations-Block, der auf die vom Slave wahrgenommene Funktion abgestimmt ist. Bei einigen Knoten (z. B. I/O-Knoten) kann es sich hierbei um recht einfache Peripherieschnittstellen handeln. Andere dagegen, wie zum Beispiel Sensor-Slave-Knoten oder Antriebs-Knoten, können sehr komplex sein und erheblichen Verarbeitungsaufwand verursachen. In einer hardwareorientierten Slave-Architektur werden die Echtzeitfunktionen per Hardware, d. h. von einem FPGA oder ASIC ausgeführt. Die Applikationsverarbeitung wird dagegen oft von einem weiteren diskreten Baustein wie etwa einem Mikrocontroller (MCU) wahrgenommen. Welche Verarbeitungsleistung und welche Peripherieschnittstellen der Mikrocontroller mitbringen muss, richtet sich nach den Anforderungen der jeweiligen Funktion.

Nachteile der hardwareorientierten Ethercat-Architektur

Die Nachteile einer hardwareorientierten oder aus mehreren Bausteinen bestehenden Lösung haben mit der Flexibilität, der Upgradefähigkeit und den Kosten zu tun. So sind hardwareorientierte Lösungen möglicherweise nur eingeschränkt in der Lage, künftige Updates und Verbesserungen des Systems zu unterstützen, denn sie sind für die Unterstützung genau der Features ausgelegt, auf die man sich beim Design eingestellt hat. Im Unterschied dazu ist eine vollständig programmierbare Lösung softwaregetrieben, was deutlich weniger Restriktionen mit sich bringt. Dementsprechend kann ein breites Spektrum von Features unterstützt werden, und auch künftige Anforderungen lassen sich abdecken. Jeder zusätzliche Baustein treibt zwangsläufig die Materialkosten in die Höhe. Eine Architektur, die auf einem FPGA basiert, kann sich zwar die Programmierbarkeit dieses Bausteins zunutze machen, doch kommt ein FPGA nicht an die Schaltungsdichte von kundenspezifischen Bauelementen wie etwa ASICs oder programmierbaren SoCs heran. Die Schaltungsdichte ist gleichbedeutend mit dem auf die Chipfläche umgerechneten Funktionsumfang und wirkt sich damit unmittelbar auf die Kosten eines Knotens aus. Je umfangreicher die Funktionalität pro Flächeneinheit ist, umso niedriger fallen die Systemkosten aus.

Als Alternative zu einem FPGA oder SoC bietet sich ein individuell entwickeltes ASIC an. Da dessen Architektur gezielt zur Unterstützung der anvisierten Ethercat-Slave-Funktionalität entwickelt werden kann, kann ein ASIC einen höheren Integrationsgrad bieten als eine FPGA-basierte Lösung. Dabei darf indes nicht vergessen werden, dass der Zeitaufwand, die Kosten und die Risiken bei einer ASIC-Entwicklung deutlich höher sein können als bei den anderen Alternativen.

Programmierbare Multicore-SoCs bieten sich als flexible, erweiterungsfähige, zukunftssichere und kostengünstige Architektur für Ethercat-Slave-Knoten an. Während ein hardwareorientiertes Konzept mehrere Bausteine für die Ethercat-Kommunikation, die Peripherieschnittstellen und die Motoransteuerung enthält, stellt ein SoC mit seinen programmierbaren Echtzeitverarbeitungs-Cores und seinen konfigurierbaren Peripherieschnittstellen eine einzige integrierte Lösung bereit. Somit kann ein einziger Multicore-Baustein zwei oder mehr diskrete Verarbeitungselemente ersetzen. In der Multicore-SoC-Architektur wird ein Echtzeitverarbeitungs-Core so programmiert, dass er die Aufgaben eines größeren Funktionsabschnitts übernehmen kann, wie etwa die Hälfte der Interface- und Verarbeitungsaufgaben der Ethercat-Sicherungsschicht. Z.B. könnten zwei Cores für die Verarbeitung des Ethercat-Protokolls abgestellt werden. Die übrigen programmierbaren Echtzeit-Cores können dann für andere Echtzeitaufgaben wie etwa die Delta-Sigma-Datenwandlung, die Positionsgeber-Rückmeldungen, die verteilte Synchronisation oder weitere Echtzeitsteuerungs-Funktionen genutzt werden. Dabei lassen sich die Features des Multicore-SoC nicht nur bei der Produktion, sondern auch im Feld konfigurieren.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44442690 / Industrial Networking)