Nach dem anfänglichen Hype um das Thema „Industrial Ethernet“ ist diese Technologie mittlerweile im wirklichen (Automatisierungs-) Leben angekommen und zum ernstzunehmenden Wettbewerber der etablierten Feldbusse herangewachsen. Allerdings treten damit jetzt auch „Nebenwirkungen“ zu Tage: So ist Ethernet seit dem Umstieg vom „Yellow Cable“ beziehungsweise 10Base2 (RG58 Koaxialkabel) auf das deutlich zuverlässigere und leistungsfähigere Twisted-Pair kein Bus mehr und damit streng genommen nicht mehr lininstrukturfähig. Der Grund: Durch die mit 10BaseT begonnene und mit 100­-BaseTX weitergeführte Nutzung von Twisted-Pair-Kabeln ist die Stern-Struktur in Ethernet-Netzwerken verankert. Das heißt: An einem Switch/Hub laufen viele Twisted-Pair-Knoten zusammen. Dabei kann der Switch entweder der zent­rale Knotenpunkt des Netzwerkes sein oder ein Knotenpunkt eines strukturierten Netzwerkes, in dem Segmente nur noch aus dem Knoten und dem Port des Switches beziehungsweise des Hubs bestehen. Der Vorteil einer solchen Topologie: Knoten lassen sich problemlos hinzufügen und Verkabelungs- beziehungsweise Knotenfehler führen nicht mehr zum Ausfall des gesamten Netzwerkes.

Während die klassische Sternstruktur innerhalb eines Schaltschrankes durchaus noch sinnvoll und vertretbar ist, ist der Aufwand im Feld hierfür immens und sowohl technisch als auch wirtschaftlich nicht mehr darstellbar. Ergo gilt es, im Feld die Linienstruktur mit Komponenten der Sternstruktur nachzubilden. Die Umsetzung der Linienstruktur – also das Daisy-Chaining von einem Netzwerkknoten zum nächsten – verlangt jedoch nach Unterstützung in jedem Knoten, der nun als 3-Wege-„Sternpunkt“ ausgeführt sein muss und aus einem ankommendem, einem weitergeführten und einem abgezweigtem Segment besteht.

Das Prinzip der Linienstruktur mit Ethernet: Die Knoten werden „in Reihe geschaltet“ und jeder Teilnehmer mit Linienstrukturkomponenten ausgestattet.

© Port

Im Office-Ethernet ließe sich die Linienstruktur noch recht einfach nachrüsten. Dem eigentlichen Gerät beziehungsweise der CPU wird hierzu ein 3-Port-Hub beziehungsweise 3-Port-Switch vorgeschalten – das Gerät erhält zwei nach außen sichtbare Ethernet-Ports und der dritte Port wird intern an die CPU des Gerätes gekoppelt. Bei Industrial Ethernet funktioniert dies nicht so einfach. Der Grund: Zur Überwindung einiger Unzulänglichkeiten des Ethernet für den industriellen Einsatz – zum Beispiel die fehlende Deterministik oder unzureichende Echtzeit-Fähigkeiten – haben sich verschiedene Nutzerorganisationen gebildet, welche wiederum spezielle, auf die Anforderungen der Industrie zugeschnittene Protokolle definiert haben. Genau deren Mechanismen (zum Beispiel IGMP-Snooping, MRP, LLDP) behindern nun aber den vorgenannten schnellen und einfachen Lösungsansatz zum Nachbilden der Linienstruktur.

Mit welchen ‚Kniffen‘ sich die Li­nienstruktur trotzdem nachbilden lässt, wird auf den folgenden vier Unterseiten am Beispiel der im Markt dominierenden Industrial-Ethernet-Lösungen beschrieben.

Powerlink

Die Komponenten zum Nachbilden der Linienstruktur bestehen bei Powerlink fast immer aus einem speziellen Hub – in der Regel als VHDL-basierter FPGA-IP-Core – und sehr oft aus der direkt angekoppelten, Powerlink-spezifischen MAC.

© Port

Powerlink basiert auf einem fest definierten Ablauf (zum Beispiel Poll-Requests, Poll-Responses) der Netzwerkzugriffe und darauf, dass jeder Teilnehmer jede Nachricht im Netzwerk sieht. Das Protokoll verlangt eine 100-Mbit-Halb-Duplex-Kommunikation und folgerichtig nach 100-Mbit-Hubs. Die Linienstrukturkomponente ist ein spezieller Hub, der sogenannte Powerlink-Hub.

Damit wird die ansonsten durch jeden Switch eingebrachte Verzögerung minimiert, welche beim Empfangen, Speichern und anschließendem Versenden entsteht (siehe Unterseite 'Switches versus Hubs'). Nur mit Embedded-Hubs, die auf FPGAs basieren, lässt sich die von der EPSG vorgegebene Durchlaufverzögerung von weniger als 400 ns erreichen. Damit werden die Durchlaufzeiten – ganz besonders in der Linienstruktur – optimiert.

Weitere Optimierungsmöglichkeiten bestehen bei den Poll-Reponses. Durch das strenge Regime von Powerlink steht fest, wann im Netzwerk welche Daten abgefragt werden (Polling). Da also bekannt ist, was gleich gefragt wird, kann man die Antwort bereits vorbereiten. Mit speziellen, in FPGAs untergebrachten MACs (Media Access Controller) lassen sich die Antworten sofort nach Eintreffen des Poll-Frames versenden, ohne den Protokollstack durchlaufen zu müssen – die Antwort wurde ja vorab in der MAC gespeichert. Auf diese Weise wird die CPU-Last reduziert, die Poll-Responses werden postwendend versendet und der Netzwerk-Jitter ist sehr gering.

Üblicherweise wird eine solche spe­zielle MAC-Lösung mit einem vor­geschaltenen Hub kombiniert und als VHDL-Code beziehungsweise IP-Core für FPGAs angeboten. Verbunden mit einem darauf optimierten Powerlink-Protokollstack und einer durchgehenden Toolkette (DesignTool, Device-Monitor) ergibt sich eine komfortable Lösung. Doch auch ohne spezielle MACs kann ein Powerlink-Netzwerk brauchbar betrieben werden.

Für die FPGA-Lösung bieten sich dem Anwender zwei mögliche Anwendungsszenarien. Erstens: Der FPGA wird so bemessen, dass auch die Linienstrukturkomponenten anderer Feldbus-Komponenten mittels einer universellen DP-RAM-Schnittstelle (zum Beispiel PUDIn von Port) angekoppelt werden können. Die Abarbeitung des Protokolls übernimmt eine Soft-CPU (Microblaze) und entlastet so die eigentliche Anwendung. Optional ist die Anwendung in die Soft-CPU integrierbar. Auch in diesem Szenario sorgt die Entkopplung mittels einer universellen Schnittstelle für hohe Flexibilität. Als FPGA ist hier der Spartan 6 XC6LX45 ein guter gemeinsamer Nenner.

Zweitens: In dem FPGA werden nur die Powerlink-spezifischen Linienstrukturkomponenten untergebracht. Hierzu reichen FPGAs der Größenordnung Spartan3 XC3S50 oder Spartan 6 XC6SLX4. Die Verarbeitung des Protokolls erfolgt in einem externen Mikrocontroller (MCU) oder einer externen CPU. Dieser kosten- und leistungsoptimierte Ansatz für die Powerlink-Linienstruktur lässt allerdings die (Nach-) Nutzung der Plattform für andere Industrial-Ethernet-Protokolle nicht zu.

Ethercat

Auch wenn in den Ethercat Slave Controllern von Beckhoff die Linienstruktur bereits enthalten ist, ergeben sich interessante Optionen – zum Beispiel als alternative Bestückoption mit einem Switch Controller.

© Port

In kaum einem anderen Industrial-Ethernet- Protokoll ist die Linienstruktur so fest verankert wie in Ethercat. Ethercat bedient sich einer modifizierten Layer-2-Schnittstelle und lässt den Ethernet-Frame durch den Ethercat Slave Controller (ESC) „durchlaufen“. Während dieses Durchlaufens werden Daten entnommen und neue Daten eingesetzt sowie im Anschluss daran die Checksumme des modifizierten Frames neu berechnet. Dieses Verfahren ist an Geschwindigkeit kaum zu überbieten, bedingt jedoch einen Ethercat Slave Controller oder eine anderweitig kompatible Hardwarekomponente. Mit anderen Worten: Mit „normalen“ Hubs oder Switches funktioniert Ethercat nicht. Der Frame wird zwar weitergeleitet, ein Datenaustausch findet aber nur im ESC statt.

Der ESC kann als tatsächlicher ASIC zum Einsatz kommen (ESC1100, ESC1200) oder als FPGA-IP-Core in ein FPGA-Design integriert werden – beide Lösungen stammen von Beckhoff. Optional gibt es bereits integrierte Lösungen wie zum Beispiel der Am335x von Texas Instruments. Die Lösungsansätze ähneln denen von Powerlink, unterscheiden sich aber im Detail:

Der ESC-IP-Core bietet verschiedene Konfigurations-Szenarien; entsprechend variiert die Größe des nötigen FPGAs. Werden alle Optionen umgesetzt, ist bereits ein FPGA der Größe Spartan 6 XC6LX45 erforderlich. Hier lässt sich die Soft-CPU unterbringen und das Ethercat-Protokoll kann dort ebenfalls verarbeitet werden. Der DSP einer Automatisierungskomponente – zum Beispiel eines intelligenten Antriebs – wird so weitgehend von Kommunikationsaufgaben entlastet und die Rückwirkungen der Protokoll-Implementierung (zum Beispiel CPU-Belastung durch Kommunikationsaufgaben) bleiben minimal. Über ein universelles DP-RAM Interface (zum Beispiel PUDIn von Port) sind dann verschiedene andere Protokolle (etwa Profinet, Ethernet/IP, Powerlink) unkompliziert ankoppelbar. Kurzum: Die Linienstruktur ist automatisch mit an Bord. Der ESC-ASIC hingegen ermöglicht die entwicklungsseitig weniger aufwendige, aber auch exklusive Ankopplung von Ethercat an die CPU beziehungsweise MCU. Die Linienstruktur ist hier im Silizium fest verankert. Nachteil ist: Der Einsatz des ESC-ASIC mit einem anderen Industrial-Ethernet-Protokoll ist nicht möglich.

Profinet

Linienstrukturop­tionen für Profinet und Ethernet/IP: Beide Protokolle benötigen einen Managed (embedded) Ethernet Switch. Die Anforderungen an die Managementsoftware sind trotzdem unterschiedlich.

© Port

So lange man sich bei Profinet im Rahmen der Real Time Class 1 oder 2 und der Conformance Class B bewegt, entstehen keine Anforderungen an die Nachbildung der Linienstruktur, die sich mit Standard-Ethernet-Komponenten nicht erfüllen ließen. Erst ab der Real Time Class 3 und der Conformance Class C (IRT/DFP) sind hierfür spezielle Komponenten erforderlich. Einfach ist die Nachbildung der Linienstruktur damit aber trotzdem nicht! Integration der Linienstruktur in ein Gerät heißt bei Profinet, einen Managed-Switch in das Gerät beziehungsweise in den FPGA zu integrieren. Das Management dieses Switches erfolgt in Software und diese Software muss von der CPU des Gerätes oder auf einer anderen, lokalen CPU mit ausgeführt werden.

Auch hier steht wieder die Option im Raum, eine MCU oder CPU und einen externen Baustein (Managed Switch Controller) zur Nachbildung der Linienstruktur zu verwenden. Das ist preiswert – Managed Switch Controller mit drei oder fünf Ports sind durchaus bezahlbar (je nach Hersteller und Menge sind hier 5 bis 10 Euro verhandelbar) – und ergibt zusammen mit einer leistungsfähigen 32-Bit-MCU (zum Beispiel STM32) ein attraktives Gesamtsystem. Und mit auf Speicherbedarf optimierten Stacks lässt sich Profinet bereits mit den Onboard-Ressourcen ausführen. Ein Beispiel hierfür ist der Profinet-Stack von Port, der mit 96kByte RAM auskommt. Doch kein „Wenn“ ohne „Aber“: Eine solche Lösung mit externem Switch-Controller funktioniert für Profinet und angepasst auch für Etheret/IP. Andere Systeme – etwa Ethercat und Powerlink – bleiben jedoch außen vor, denn ein Switch ist kein Hub und auch kein Ethercat Slave Controller.

Die andere Alternative zur Nachbildung der Linienstruktur für den FPGA ist ein „Managed Embedded Ethernet Switch“. Damit kehrt die Wiederverwendbarkeit zurück. Dieses Stück VHDL-Code – als IP Core im FPGA eingebettet – ist das Äquivalent zum externen Switch Controller. Identisch zum externen Managed Switch Controller wird bei der Embedded-Variante eine Software-Applikation ausgeführt, die die eigentlichen Managementaufgaben durchführt. Das erfolgt idealerweise auf der Soft-CPU parallel zur Abarbeitung des Protokollstacks. Die Anwendung wird wiederum über ein DP-RAM-Interface angekoppelt.

Ethernet/IP

Ethernet/IP setzt schon in seinen Grundlagen auf TCP/IP-Kommunikation. Anders als bei Profinet bleibt die Standardkonformität in allen Ausbaustufen erhalten. Das bei der ODVA beheimatete und von Rockwell Automation getriebene Industrial-Ethernet-System setzt bei der zyklischen Datenkommunikation auf Layer-3-Multicast-Nachrichten. Das IGMP (Internet Group Messaging Protocol) verlangt Unterstützung in allen beteiligten Switches, weshalb auch bei Ethernet/IP die Nachbildung der Linienstruktur durch Managed Switches mit der zugehörigen Managementsoftware erfolgen muss. Zusätzlich ist hier auf die Verwendung eines multicastfähigen TCP/IP-Stacks zu achten. Ansonsten sind die Anwendungs-Szenarien zur Nachbildung der Linienstruktur bei Ethernet/IP identisch mit denen von Profinet.

ASIC oder FPGA?

Welche Option zur Nachbildung der Linienstruktur im Industrial Ethernet letztendlich zum Einsatz kommt, muss jeder Anwender nach eigenen Kriterien selbst entscheiden. Als sofort erkennbarer Nachteil fällt bei der FPGA-Lösung der höhere Materialpreis ins Auge, während die ASIC-Lösung durch augenscheinlich günstigere Materialpreise besticht.

Bei der Betrachtung der Materialpreise sollten die Kosten der Fertigung und die Bedürfnisse des EMS-Fertigers (EMS – Electronic Manufacturing Services, Auftragsfertiger) nicht übersehen werden. Oftmals wird dieser beispielsweise den Umstieg vom „exotischen“ Low-Power-Typ eines FPGA-Herstellers auf den Mainstream-Typ einer Linie empfehlen – niemand kann diese Optimierung so wirksam vornehmen wie ein EMS-Fertiger mit soliden Lieferantenbeziehungen.

Nicht zuletzt kann das wohl immer teurere FPGA-Design gegenüber der spezifischen Lösung mit höheren Stückzahlen punkten. Das heißt: Richtig umgesetzt wird nur eine Baugruppe gefertigt und erst kurz vor der Auslieferung entschieden, welches Industrial-Ethernet-Protokoll unterstützt wird. Gegebenenfalls kann sogar im Feld umgestellt werden und es sind sogar nachträgliche Modifikationen am Embedded-Ethernet-Switch oder anderen Linienstrukturkomponenten denkbar.

Switches versus Hubs

Ein Switch liest den kompletten Frame ein, bevor dieser am Zielport wieder ausgesendet wird (Store & Forward Mode). Dabei entsteht eine Verzögerung von etwa 5 µs bei der minimalen Frame-Länge von 64 Byte und bis zu etwa 120 µs bei der maximalen Frame-Länge von 1518 Bytes. Dabei braucht ein Switch erfahrungsgemäß zwischen 1 bis 10 µs zwischen dem Ende des Empfangs und dem Beginn des Versendens des weitergeleiteten Frames.

Im Cut-Through-Modus muss der Switch zumindest die Empfängeradresse eines einkommenden Frames einlesen und sendet ihn dann sofort aus. Dadurch entsteht zwar nur eine geringere Verzögerung zwischen 40 und 50 µs; im Vergleich zu der durch einen Hub eingebrachten Verzögerung von deutlich unter 800 ns ist das aber immer noch sehr lange.

Somit entstehen pro Teilnehmer bei einer mit Hilfe von Switches nachgebildeter Linienstruktur (Store & Forward Mode) Verzögerungen zwischen 15 und 130 µs. Bei mehreren Geräten mit nachgebildeter Linienstruktur ist die Summe der aufaddierten Verzögerungen erheblich.

Durch den Cut Through Mode lässt sich diese Verzögerung immerhin auf konstant rund 50 µs begrenzen. Da der Switch den Frame und die Checksumme dabei nicht prüft, steigt jedoch das Risiko deutlich, das Netzwerk mit fehlerhaften Frames unnötig zu belasten. Der Einsatz optimierter Hubs reduziert diese Verzögerung immerhin auf unter 400 ns.

Autor: Christian Bornschein ist Geschäftsführer bei der Firma Port in Halle/Saale.