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

Ethernetbasierte Bussysteme haben in den letzten 15 Jahren einen wahren Siegeszug in der Automatisierungstechnik angetreten. Mit Industrie 4.0 ist der Zug noch schneller geworden. In diesem 3-teiligen Beitrag werden der Stand der Technik aufgezeigt und die echtzeitfähigen Lösungen analysiert.

Kommunikation ist bei Industrie 4.0 von zentraler Bedeutung. Die Diskussion um BigData, Cloud Services und Machine Learning ist ohne eine leistungsfähige Kommunikationsinfrastruktur nicht möglich. Ergänzend um die vielfältigen Anforderungen rund um das Thema Daten steht die Herausforderung »Echtzeit-Kommunikation« im Mittelpunkt. Hier scheiden sich die Geister. Echtzeit in der Automatisierungstechnik und Echtzeit in der Servicewelt sind so grundverschieden, dass es immer wieder zu Missverständnissen und Irritationen führt.

Für die ITler ist die Welt noch in Ordnung. Das was für »Echtzeit-Banktransaktionen« reicht, sollte doch auch für Echtzeit in der OT (Operational Technologie) ausreichen. Doch weit gefehlt. Die Anforderungen liegen derart weit auseinander dass sich sogar die Kommunikationstechnologien auf Hardwareebene in andere Richtungen entwickeln. Dieses liegt an zwei wesentlichen Faktoren.

Zum einen wird der Begriff Ethernet als Synonym für interoperable Kommunikation verwendet. Das ist auf der physischen Ebene richtig, aber zunehmend sind unsere Kommunikationsgeräte gar nicht mit Ethernet-Schnittstellen ausgerüstet, sondern mit WIFI-, 3G-, 4G- oder in Zukunft 5G-Kommunikationsstandards. Diese Schnittstellen werden zwar meistens im Backbone auf Ethernet zusammengefasst, aber es sind eigene Technologien. Das, was Automatisierer als »Echtzeit« bezeichnen, wird im ISO-OSI-Layer 2 realisiert.

Zum anderen wird Durchgängigkeit mittels ISO-OSI-Layer 3 und 4 mit der TCP/IP-Protokollfamilie realisiert (Bild 1). Hier geht es um das Finden von Rechnern in einem hierarchischen Netzwerk, was IP realisiert und um den Austausch von Diensten oder Services und der Bereitstellung genau definierter Anwendungsschnittstellen. Das ist die Aufgabe der Transportschicht mit der TCP-Protokollfamilie. Hier spielt der physikalische Transport keine Rolle mehr. Es geht ausschließlich um die Serviceschnittstellen und die bereit gestellten Dienste.

Noch deutlicher wird die Herausforderung, wenn man die Industrie-4.0-Entwicklungen und Referenzarchitektur betrachtet (Bild 2). Hier wird klar zwischen der serviceorientierten Industrie-4.0-Kommunikation und deterministischer Echtzeit-Kommunikation differenziert.

Den Arbeitsgruppen ist es völlig klar, dass Echtzeit und Durchgängigkeit zwei vollkommen unterschiedliche Aspekte sind, die es zu lösen gilt. Es ist also nicht trivial zu entscheiden, was die richtige Technologie ist. Offensichtlich ist, das zumindest die in Industrie 4.0 konforme Kommunikation über TCP/IP abgewickelt wird. Naheliegend ist dann auch die Nutzung von Ethernet als Basiskommunikation oder jede andere Hardwaretechnologie, die in der Lage ist, TCP/IP-Kommunikation zu transportieren. Das ist ein weiterer Grund, warum WiFi und 4G und im Besonderen die neu aufkommenden 5G-Standards für Industrie-4.0-Kommunikation eine große Rolle spielen werden. Unter konformer Kommunikation in Industrie 4.0 versteht man in erster Linie ein Kommunikationsmedium, das in der Lage ist, Rechner zu finden und Services anzubieten und zu konsumieren. Und hierbei spielt der TCP/IP-Stapel die entscheidende Rolle.

Das man auch für den Rest der Kommunikation Ethernet verwenden möchte ist naheliegend – doch so einfach ist das nicht. Ethernet »von der Stange« hat spezifische Eigenschaften und die widersprechen den Anforderungen einer deterministischen Reaktion im µs-Bereich. Auch das ist hinlänglich bekannt und der Grund für herstellerspezifische Lösungen. Ethercat, Powerlink, Profinet oder Sercos III basieren zwar in gewisser Weise auf Ethernet – aber sie sind keine IT-kompatiblen Standards. Sie lösen alle Zusammen das Thema »Durchgängkeit« und »Echtzeitfähigkeit« – aber jede Technologie auf ihre Art. Doch dazu mehr im folgenden Artikel. An dieser Stelle wird der Fokus zunächst auf die Basis von Ethernet gelenkt, wie es in der IT üblicherweise verwendet wird. 

Ethernet – Historische Entwicklung

Jeder redet von Ethernet, aber »das« Ethernet gibt es gar nicht. Ethernet beschreibt ein Bussystem, welches eine phänomenale Evolution in den letzten 40 Jahren vollzogen hat. Es ist eng verbunden mit Robert Metcalfe und dem Xeroc Palo Alto Research Center (PARC). Metcalf entwickelte mit seinem Team über mehrere Jahre das »Ethernet« als firmenspezifisches Protokoll. 1976 veröffentlichte er einen ersten grundlegenden Artikel zusammen mit David Boggs »Ethernet: Distributed Packet Switching For Local Computer Networks« [1]. 1979 gründete Metcalfe die Firma 3COM und konnte DEC, Intel und Xerox überzeugen, Ethernet zu einem gemeinsamen Standard zu entwickeln. Dieser Backbone-basierte Ansatz, häufig auch als DIX bezeichnet, führte 1980 zu einer entsprechenden Initiative und gipfelte 1985 in der Normung der IEEE 802.3. Mit der Standardisierung begann in den letzten 30 Jahren eine herausragende Entwicklung. Vergleichbar zum Moorschen Gesetz in der Halbleiterindustrie, der Verdopplung der Rechenleistung alle 18 Monate, kann nur Ethernet eine vergleichbare Performancesteigerung bei Kommunikationssystemen vorweisen. Mit etwa einer Verzehnfachung alle 5 Jahre ist der Anstieg an Kommunikationsleistung signifikant. Ein Ende dieser Entwicklung ist nicht abzusehen, ein Grund warum Ethernet als universelles Kommunikationsmedium so interessant ist und sich stetig neu erfindet. 

Grundlagen 

Bei der anfänglichen Entwicklung von Ethernet stand die Kommunikation von nahezu beliebig vielen Stationen an einem Backbone im Vordergrund. Seit etwa 1996 wird Ethernet als Sterntopologie mit Twisted-Pair-Verkabelung realisiert. Über Sternkoppler (Hubs, Switches, Switching Hubs) wird eine Punkt-zu-Punkt-Kommunikation zwischen zwei Kommunikationsknoten realisiert (Bild 3). Routing, Internet und sonstige Dienste nicht eingeschlossen – die werden auf anderen Ebenen des ISO-OSI-Schichtenmodells realisiert und haben mit »Ethernet« nichts zu tun. 

Die Kommunikation zwischen zwei Knoten erfolgt also ausschließlich als Punkt-zu-Punkt-Verbindung. Die Adressierung der Teilnehmer erfolgt über die MAC-Adresse, die eine Eigenschaft der Ethernet-Karte ist. In der Regel sind die Adressen einzigartig, damit tatsächlich eine eindeutige Kommunikation möglich ist. Wird als Sternkoppler ein Switch eingesetzt, erfüllt dieser noch weitere Anforderungen. Er dient vielfach als PHY-Konverter. Ethernet-Switches können mit unterschiedlichen Geschwindigkeiten auf jedem Port betrieben werden. Der Switch ist dann für die Detektion der Geschwindigkeit eines Teilnehmers verantwortlich. Dieses wird durch die Frequenzbestimmung der Präambel des Ethernet-Telegramms realisiert (Bild 4). Der so genannte SFD (Start of Frame Delimiter), eine Verletzung der 1010-Folge, zeigt an, dass die Telegrammdaten jetzt folgen.

Hub und Switch

Sternkoppler können eine vollständig unterschiedliche Ausprägung haben. In erster Linie unterscheidet man zwischen Hub und Switch. Ein Hub ist nichts anderes als ein Koppler, der eingehende Datenpakete auf alle weiteren Kanäle des Sternkopplers dupliziert. Datenpakete kommen damit mehrfach vor. Durch die eindeutige Teilnehmeradressierung werden nicht benötigte Datenpakete später verworfen. Hubs sind hardware-synchronisiert und können daher nur mit einer Geschwindigkeit betrieben werden.

Aus der Sicht der Automatisierungstechnik können Hubs interessant sein, da die Pakete als Broadcasts versendet werden und so quasi gleichzeitig an allen Stationen ankommen. Für die konventionelle IT-Technik ist dieses Verhalten eher unerwünscht, da der Datenverkehr nur unerwünscht stark ist. 
Aus diesem Grund haben sich sogenannte Switches als Sternkoppler seit Anfang der 2000er Jahre als Stand der Technik herauskristallisiert. Hierbei werden innerhalb der Sternkoppler Filterdatenbanken gehalten, in der angeschlossenen Rechnersysteme mit ihrer MAC-Adressen registriert werden. Der Switch kennt durch mitlesen des Telegramms über welchen Port das Zielsystem erreichbar ist und kann dann, wie bei einem Kreuzschienenverteiler, Quell- und Zielport verbinden. Bei reinen 1:1-Kommunikationsverbindungen hat ein Switch damit die gleiche Funktion wie ein gekreuztes Kabel, das heißt, es ist eine exklusive störungsfreie Full-Duplex-Verbindung möglich. Echtzeit kann in diesem Fall garantiert werden – ein Grund warum man Switched-Ethernet eine »Echtzeitfähigkeit« attestiert.

Anders sieht es aus, wenn ein Zielsystem dem Switch nicht bekannt ist. Das ist immer bei einem Neustart der Fall oder wenn tatsächlich ein neuer Teilnehmer erreicht werden soll. Der Switch kann dann nicht wissen, über welchen Port der Teilnehmer erreichbar ist und das Datenpaket wird durch das sogenannte »Flooding«, wie bei einem Hub, an alle Ports kopiert. Aus der Sicht der Echtzeit ist dieses Verhalten kaum zu akzeptieren, weil eine deterministische Antwort zu keinem Zeitpunkt möglich ist.

Darüber hinaus ist auch das interne Verhalten der Switche von hoher Bedeutung. In der technischen Praxis haben sich zwei grundsätzliche Technologien herausgebildet: Die Store-and-Forward- und die Cut-Through-Technologie. 

Store-and-Foreward 

Diese Betriebsart ist heute am häufigsten vorzufinden und eine Grundeigenschaft aller preissensitiven Sternkoppler. Wie der Name schon sagt, werden die Datenpakete vollständig in den Switch eingeladen, zwischengespeichert, auf eine gültige Prüfsumme untersucht und dann erst an den Zielport weiter gegeben. Vorteil von Store-and-Foreward-Switches ist die Filterung von korrupten Datenpaketen. Durch die Überprüfung der Checksumme des Ethernet-Datenpakets können defekte Nachrichten aussortiert werden. Nachteilig ist die notwendige Bearbeitungszeit. Bei einer typischen Paketlänge von 1518 Byte ist die Mindestdauer für ein Datenpaket rund 120 µs bei 100 Mbps plus der typischen Verzögerungszeit von bis zu einigen 10 µs. Selbst bei Gigabit-Ethernet kann man mit Verzögerungszeiten um die 40 µs rechnen. Noch schlimmer wird es beim Pipelineing von Nachrichten an einem Port – hier steigt die Wartezeit mit der Anzahl der Teilnehmer. Aus der Sicht der Echtzeit ist dies eine wahre Katastrophe. Das System ist zwar für Worst-Case-Szenarien determinierbar (Bild 6), aber die Warte- beziehungsweise Latenzzeiten können einen hohen Systemjitter erzeugen. Eine deutliche Verbesserung des Zeitverhaltens ist nur durch kleinere Datenpakete oder andere Switching-Technologien möglich. 

Cut-Through 

Ein deutlich besseres Zeitverhalten ist durch sogenannte Cut-Trough- oder auch On-the-Fly-Switche möglich. Im Gegensatz zu den Store-and-Foreward-Varianten werden hier die Nachrichten nur bis zu der Zieladresse eingelesen und dann sofort der Weiterleitungsprozess angestoßen. Hierdurch können die Datenpakete zwar nicht überprüft werden, jedoch erfolgt die Weiterleitung typisch im Bereich um die 10 µs. Das ist auch aus der Sicht von Echtzeitsystemen hinreichend schnell und deterministisch. Nur bei einem belegten Port werden die Pakete zwischengespeichert. Diese Art von Switche haben nur einen Vorteil, wenn in kleinen Netzwerksegmenten eine große Anzahl von kleinen Datenpaketen ausgetauscht werden, was in der Automatisierungstechnik typischerweise der Fall ist. Unter allen Umständen sollte auch hier eine Kanalnutzung von 100 Prozent vermieden werden, da es sonst auch zu Warteschlangeneffekten kommt.

Automatisierungstechnik

Gerade für automatisierungstechnische Anwendungen sollte man sehr genau wissen, welche Kommunikationsanforderungen tat-sächlich vorliegen. Nur so kann man sich vor ungewollten Effekten schützen. Generell sollte man bei dem Einsatz von Ethernet auf das Anforderungsprofil des Automatisierungseinsatzes achten. In der IEC 61784-2 werden ganz allgemein Echtzeitklassen (RTC - Realtime Class) anhand der Reaktionszeit definiert. Bei der RTC 3, in erster Linie für hoch synchrone Echtzeitanwendungen, wird darüber hinaus noch ein Jitter von <1 µs gefordert. Aus den vorhergehenden Ausführungen wird deutlich, dass dieses mit konventionellen Switched-Ethernet nicht möglich ist. Alleine durch die Latenz- und Forewarding-Zeiten sind die geforderten Zeiten nicht einzuhalten.

Echtzeitverhalten in Ethernet-Netzwerken bekommt man folglich nicht geschenkt. Die aus dem Officebereich bekannten Techniken reichen bestenfalls für die Echtzeitklasse 1. Selbst für Anwendungen der Klasse 2 müssen zusätzliche Randbedingungen eingehalten werden, um die notwendigen Randbedingungen einzuhalten: 

Die Netzlast ist soweit zu reduzieren, dass eine Bildung von Warteschlangen möglichst unwahrscheinlich wird.

Alternativ kann eine zentrale Koordination bei der Verwaltung der Netzlast helfen, die eine dedizierte Planung der Bandbreite zulässt.

Kollisionen treten bei der Fullduplex-Kommunikation nicht auf. Hierbei spielt nur die zeitliche Verzögerung eine Rolle. Eine deutlich verbesserte Vorhersagegenauigkeit schaffen hier gemanagte Switches, die eine definierte Datenrate für einen oder mehrere Ports reservieren können oder eine Priorisierung der Nachrichten ermöglichen. 

Es ist offensichtlich, dass Ethernet aus der IT-Welt kein Allheilmittel für die Automatisierungstechnik darstellt. Ganz im Gegenteil. Man löst das Problem »Durchgängigkeit« durch eine serviceorientierte TCP/IP-Kommunikation und gleichzeitig schafft man sich neue Herausforderungen bei der deterministischen Kommunikation – der Automatisierungs-Echtzeit.

In Teil 2 wird es um diverse echtzeitoptimierte Ethernet-Lösungen und die Frage gehen, inwieweit dies zielführend ist. (fr)

Professor Dr.-Ing. Jörg Wollert

ist seit 1999 an verschiedenen Hochschulen tätig. Im Rahmen seiner Tätigkeit für diverse Einrichtungen berät er Unternehmen im Bereich verteilter Automatisierungssysteme und eingebetteter Systeme insbesondere mit Funktechnologie und Industrie 4.0.