Echtzeit für Industrie 4.0. - Teil 2 Echtzeit-Ethernet – Basis für Industrie 4.0

Durchgängigkeit ist das A und O für industrie-4.0-konforme Automation. Echtzeit mit Reaktionszeiten von bis zu 50 µs stellt demgegenüber einen mit konventionellem Ethernet nicht erreichbaren Kontrast dar. Jeder Anbieter versucht seine eigene Lösung in den Markt zu bringen – doch ist das zielführend?

Wie im vorhergehenden Artikel [1] dargestellt, wird Switched-Ethernet häufig als Schlüssel für die echtzeittaugliche Kommunikation auch für industrielle Netzwerke angesehen. Doch das ist nur die halbe Wahrheit. Ohne detaillierte Kenntnisse des Betriebsverhaltens von Sternkopplern oder der tatsächlichen Kommunikationslast ist eine determinierbare Aussage bezüglich des Kommunikationsverhaltens so gut wie nicht möglich. Durch die inhärenten Latenzzeiten und die Warteschlangen innerhalb von Switches sind durchaus Verzögerungszeiten von einigen 100 µs möglich. Damit ist, ohne weitere Hilfsmittel, gerade bei Abtastregelungen und Antriebstechnik keine adäquate Automatisierungslösung möglich. Abhilfe schafft nur eine genaue Planung der Kommunikation oder die Nutzung der organisatorischen und technischen Möglichkeiten – oder die Entwicklung proprietärer Erweiterungen. Dieses war dann nach 2000 auch die Wahl der führenden Automatisierungsunternehmen, um Ethernet die notwendigen Leistungsdaten anzuerziehen. 

Automatisierungs- Echtzeit-Ethernet 

Eigentlich gibt es nur zwei Gründe für den Einsatz von Ethernet-Netzwerken. Erstens gibt es keine weitere Kommunikationstechnologie die eine vergleichbare Penetration und Performance-Entwicklung hat und zweitens ist Ethernet der priorisierte Träger von TCP/IP-Datenpaketen. Und genau das Letztere ist für die viel zitierte Konvergenz zu IT-Services von entscheidender Bedeutung.

Schließlich stellt sich die Frage was muss überhaupt automatisiert werden? Die extrem schnellen Reaktionszeiten im Bereich einiger 10 µs ist für viele Anwendungsfälle gar nicht notwendig. Schaut man in die Prozessindustrie oder in die Gebäudeautomation, dann lassen sich mit einer Reaktionszeit von einigen wenigen 100 ms schon eine akzeptable Systemreaktion herstellen und teilweise sogar die bisher eingesetzten proprietären Feldbusse um Längen in der Performance schlagen. Man darf also nicht schwarzweiß sehen sondern sollte schon sehr dediziert auf das Anwendungsumfeld und den Use-Case schauen. Betrachtet man dann noch Anwendungen, wo es mehr auf Konnektivität als auf Reaktionszeit ankommt, dann kann auch ein konventionelles Ethernet mit TCP/IP eingesetzt werden. Hierzu kann man sinnvoll vier Kategorien von Echtzeit-Ethernet-Netzwerken identifizieren. 

Sind nur geringe Echtzeitanforderungen vorhanden, kann durch einen intelligenten Einsatz eines Dienstes oberhalb der Transportschicht ein gewisses Echtzeitverhalten erreicht werden. Gerade die Verwendung von UDP-Protokollen in Verbindung mit einer Master-Slave-Kommunikation begünstigt ein erfreuliches Verhalten. Ein typischer Vertreter dieser Protokollgattung ist Modbus/TCP (Bild 1). Dieser bietet Services als Client oder Server über den Port 502 an. Da es sich bei Modbus um OpenSource handelt, gibt es kein Betriebssystem und keine Embedded-Plattform, die nicht unterstützt wird. Auch kleinste Embedded-Controller wie Arduinos unterstützen dieses Protokoll. Für harte Echtzeitanwendungen ist diese Strategie nicht hilfreich, aber gerade in der Gebäudeautomation oder der Prozessindustrie kann ein ausreichendes Betriebsverhalten mit Updatezeiten besser als 200 ms bei einem Jitter von wenigen ms erreicht werden.

Ist zumindest die IEC 61784-2 Echtzeitklasse 2, mit Reaktionszeiten <10 ms gefordert, dann ist man mit konventionellen Ethernet und TCP/IP schnell am Ende. Ein Trend geht heute in Richtung schlanker, IP-freier Echtzeitprotokolle oberhalb der Sicherungsschicht. Der Ethernet-Protokollrahmen erlaubt es, über den Ethertype zu bestimmen, welche höheren Protokolle oberhalb Schicht 2 angesprochen werden (Bild 2). Heute hat nahezu jeder Anbieter von Echtzeitlösungen seinen eigenen Ethertype, der dann in die eigene Automatisierungswelt verzweigt.

Die Vorteile liegen auf der Hand. Der Hersteller ist in der Lage, die eigenen Echtzeitprotokolle priorisiert zu bearbeiten, ohne auf die Kompatibilität zu konventionellen TCP/IP-Netzwerken zu verzichten. Eine geradezu ideale Kombination. Dieses Verfahren wird deshalb von den wesentlichen IP-kompatiblen Echtzeitlösungen realisiert. Während der konventionelle IPv4-Stack den Ethertyp 0x800 hat, nutzen die Firmen Beckhoff bei Realtime-Ethernet (RTE – Ethertype 0x88A4), Siemens und die PNO bei Profinet (CC-B 0x8892), B&R bei Powerlink (Ethertype 0x88AB) oder Sercos bei Sercos III (Ethertype 0x88CD) ihren eigenen Bypass. Der Vorteil ist offensichtlich, die kritischen Stacklaufzeiten im TCP/IP-Protokollstapel können unmittelbar umgangen werden. Durch diese Maßnahmen sind in abgeschotteten Netzwerken Zykluszeiten im Bereich von 10 ms sicher möglich.

Für alles, was eine bessere Performance aufweisen soll, sind zusätzliche Maßnahmen notwendig, die eine Anpassung der Treiber oder sogar der Hardware erforderlich machen. Dann entfernt man sich tatsächlich vom konventionellen Ethernet.

Unter Beibehaltung der typischen Infrastruktur wird die Sicherungsschicht des Ethernet-Protokolls optimiert. Dieses kann in unterschiedlichen Ausprägungen erfolgen. Ein erster Schritt wäre Treiber zu entwickeln, welche eine auf den Automatisierungsprozess zugeschnittene maximale Datenrahmenlänge aufweisen. Eine Reduktion um den Faktor 10 von 1500 auf 150 Bytes würde tatsächlich fast 1/10 Telegrammdauer entsprechen, also gerade einmal knapp 13 µs. Darüber hinaus können spezifische latenzarme Switches mit Cut-Through-Technologie oder Hubs eine weitere Verbesserung des Betriebsverhaltens erreichen. Zykluszeiten um die 200 µs sind mit diesen Maßnahmen durchaus realistisch zu erreichen. Geräte dieser Kategorie können noch kompatibel zu konventioneller Ethernet-Infrastruktur sein. Ein typischer Vertreter dieser Gattung ist beispielsweise Powerlink.

Sollen weitere Optimierungen erfolgen und Zykluszeiten im zweistelligen µs-Bereich erreicht werden, sind spezialisierte Lösungen mit eigener Hardware die geeignete Wahl. Hierbei handelt es sich in der Regel um FPGAs oder ASICs, die in Form eines Bitstream-Prozesses den Ethernet-Protokollrahmen bearbeiten. So sind mit geringster Latenz die kurzen Reaktionszeiten zu erreichen. In der Regel verzichten optimierte Systeme auf Infrastrukturkomponenten wie Switche oder Hubs, die einen Beitrag zu einer zusätzlichen Zeitverzögerung hätten. Ein prominenter Vertreter dieser Gattung ist EtherCAT der Firma Beckhoff. Hier benutzt nur die Masteranschaltung eine Standard-Ethernetschnittstelle. Die Slaves bearbeiten ausschließlich den Bitstream. Auch Profinet in der Conformance Class C (IRT) nutzt einen Kommunikationsprozessor, der spezifische Echtzeit-Ethernet-Funktionen bereit stellt.

Die vorhergehenden Ausführungen machen deutlich, dass hier nicht mehr von »dem« Ethernet gesprochen werden kann. Ein Grund sich mit den detaillierten Funktionsweisen der Bussysteme auseinanderzusetzen um die Leistungsfähigkeit der führenden Echtzeit-Ethernet-Derivate aus neutraler Sicht zu bewerten. Neben den hier detailliert erläuterten Bussystemen Powerlink, EtherCat und Profinet haben Sercos III im europäischen Umfeld aber auch Ethernet IP für den US amerikanischen Markt und CC-Link IE für den asiatischen beziehungsweise japanischen Markt eine gewisse Dominanz erreicht. 

Powerlink 
 
Die österreichische Firma B&R (Bernecker & Rainer Industrie Elektronik) ist der erste Anbieter optimierter Ethernet-Technologie für High-Speed-Ethernet-Lösungen. Im Herbst 2001 wurde Powerlink V.1 der Öffentlichkeit vorgestellt. 2002 erfolgte die Offenlegung der Spezifikation und 2003 wurde der Standard in der EPSG (Ethernet Powerlink Standardization Group), einer herstelleroffenen Organisation, der Allgemeinheit verfügbar gemacht. Powerlink der ersten Generation nutzte konventionelle Ethernet-Anschaltungen mit einem optimierten Schicht-2-Protokollstapel, einem überlagerten Master-Slave-System und Hubs als Sternkoppler zur Optimierung der Duchlaufverzögerungen im Sternkoppler. Die Anschaltung der Slaves erfolgte in einer proprietären Weise, ebenfalls war die Kommunikation zu den Slaves B&R-spezifisch. 

Powerlink-Protokolle 

Mit Powerlink V2 und der Bemühung um eine herstelleroffene Implementierung wurden zunehmend offene Standards in der Protokollumsetzung eingeführt. Hierzu gehört eine IEEE802.3-konforme Adressierung der Slaves, eine Integration der TCP/IP-Kommunikation für den Austausch asynchroner Daten und im Besonderen die Nutzung von CANopen als Anwendungslayer. Powerlink wird damit offen für die CANopen-Profile und bietet ein alternatives High-Speed-Kommunikationsmedium zu der konventionellen CAN-Anschaltung (Bild 3). 

Powerlink bietet zwei unterschiedliche Betriebsmodi. Im »Protected Mode« wird ein dediziertes Echtzeit-Netzwerk aufgebaut. Es erfolgt ein topologischer Sternaufbau, wobei die Synchronisation durch den Master erfolgt. Das System bildet eine »mechanische Einheit«, wobei Zykluszeiten kleiner als 1 ms erreichbar sind.

Im sogenannten »Open Mode« ist keine Segmentierung notwendig. Sehr wohl erfolgt aber eine Synchronisation der Teilnehmer über eine konventionelle IEEE1588-Infrastruktur. Die erreichbaren Performance-Werte sind unterhalb des »Protected Modes« angesiedelt, lassen aber mit entsprechenden RT-Gateways eine durchgängige Kommunikation über ein ausgedehntes heterogenes Netzwerk zu.

Powerlink-Kommunikation 

Ein Powerlink-Netzwerk wird durch einen Master, den sogenannten Managing Node arbitriert. Ein Kommunikationszyklus besteht aus einem isochronen und einem asynchronen Abschnitt. Im isochronen Abschnitt erfolgt eine exakt während des Engineerings determinierte Echtzeitkommunikation. Der Zyklus wird mit einem Synchronisationsbroadcast gestartet. Aufgrund der extrem kurzen Hub-Durchleitezeiten (typisch 500 nsec) trifft die Nachricht quasi gleichzeitig bei allen Slaves an. Danach pollt der Master die Slaves. Nach der Echtzeitkommunikation wird mit einem SoA-Broadcast (Start of Asynchronous Communication) die asynchrone Kommunikationsphase eingeleitet. Hier kann eine konventionelle IP-Kommunikation mit den Feldgeräten durchgeführt werden. In der Echtzeitphase ist die Hub-Durchleitezeit und der Interfame-Gap – also der kleinste Abstand zwischen zwei Ethernet Paketen – von 0,96 µs bei 100 Mbps oder 96 ns für Gigabit-Ethernet-Zeit bestimmend. 

Zur weiteren Optimierung wurde 2012 durch die EPSG das Pollresponse-Chaining eingeführt, bei dem der Master alle seine Daten per Pollresponse Broadcast auf dem Bus legt und die Slaves in der engineerten Reihenfolge antworten. Bei vielen Teilnehmern ist hierbei eine signifikante Geschwindigkeitszunahme zu erreichen. 

Powerlink-Performance

Eines der wichtigsten Argumente für ethernetbasierte Systeme ist die Steigerung der Performance und die Durchgängigkeit durch Unterstützung der TCP/IP-Protokollfamilie. Betrachtet man die Benchmarks der einzelnen RT-Ethernet-Hersteller, dann kann man erstaunliche Dinge feststellen. Jede Nutzerorganisation findet eine Konstellation bei der ihr Bussystem dem des Wettbewerbers überlegen ist. Doch häufig werden Äpfel mit Birnen verglichen. Insgesamt kann man festhalten, dass für jedes RT-Ethernet-System Anwendungsfälle gefunden werden, bei dem es besonders geeignet oder besonders ungeeignet ist. Hier kann dem Anwender nur empfohlen werden ganz genau hinzuschauen, um dann das System zu verwenden, das für die spezifische Systemlösung geeignet ist.

Powerlink ist dann gut geeignet wenn mittlere Datenmengen (knapp 100 Bytes) an hierarchisch flach gegliederte Automatisierungssysteme verteilt werden. Daisy-Chaining ist für Powerlink-Systeme immer ungeeignet, Sternstrukturen unterstützen das positive Betriebsverhalten. Da immer ein Request-Response-Paar mit jeweils einem eigenen Ethernetframe für die Kommunikation pro Slave erforderlich ist, ist der Overhead bei der Übertragung weniger Bytes extrem ungünstig. Bei der Übertragung von typisch 100 Bytes je Slave kann ein günstiges Betriebsverhalten attestiert werden. Bei sehr wenigen Teilnehmern ist eine Zykluszeit von 200 µs mit einem Jitter kleiner als 1 µs auch in praktischen Anwendungen möglich. Als Faustformel benötigt ein Powerlinksystem etwa 500 µs pro 10 Slaves – quasi unabhängig ob 1 oder 100 Bytes transportiert werden.

Im nächsten Teil dieser Betrachtungen wird EtherCAT untersucht, bevor es dann mit TSN weiter geht.