Grundsätzlich treten bei der indus­triellen Kommunikation vielfältige Effekte auf, die sich unterschiedlich auf Fehlersituationen auswirken. Was, wann, wo und aus welchem Grund passiert, bildet einerseits die Kernfrage, welche im Fehlerfall kurzfristig beantwortet werden muss, sich jedoch nicht immer einfach beantworten lässt. Andererseits gilt es, die Datenkonsistenz im Blick zu behalten, wenn man sich mit Fehlerfällen befasst. Was bedeutet dies nun in der Praxis?

In vielen Automatisierungstechnik-Applikationen sind mittlerweile Ethernet-basierte Lösungen sehr populär. ­Erfolgreich im Feld bewährt hat sich dabei insbesondere die Robustheit der physikalischen Datenübertragung mit 100 Mbit/s (Fast Ethernet). Zur Diskussion steht daher vielmehr die Effizienz der Protokollschichten oberhalb der physikalischen Ebene bezogen auf die Zuverlässigkeit.

Ein Ansatz zur Evaluierung ist hier die Untersuchung des Protokoll-Overheads. Nutzt man für jeden Netzwerk-Teilnehmer einen individuellen Ethernet-Frame, so ergibt sich ein deutlicher Overhead von mehr als 90 %, da selbst bei minimaler Frame-Größe insgesamt 84 Byte versendet werden müssen und die Nutzlast typischerweise kleiner als 8 Byte ist (zum Beispiel bei CAN zwischen 1 und 8 Byte).

Der Einfluss des Protokoll-Overheads

Für gewöhnlich ist das Kommunikationssystem einer Maschine als lineare Topologie aufgebaut, wobei die ­Fast-Ethernet-Infrastruktur das aktive Koppeln der Schnittstellen erfordert. Letzteres erfolgt durch ein so genanntes Bridged LAN, auch bekannt als ­Switched Ethernet, wobei die Switches hier oft integraler Bestandteil der Netzwerk-Knoten wie etwa I/O-Geräte oder Antriebe sind. Da sämtliche Daten ohnehin in ­jedem Knoten verarbeitet werden, kann man alternativ die gesamte Nutzdaten-Information in einem gemeinsamen Frame sammeln und – wie bei Ethercat der Fall – im Durchlauf verarbeiten. Diese Art der Protokollverarbeitung kann als Shared-Frame-Lösung bezeichnet werden. Das Ergebnis ist ein Overhead von weniger als 50 % – selbst wenn die ­Anzahl der verbundenen Elemente beziehungsweise  Netzwerk-Knoten gering ist. Liegt die Gesamtnutzlast des Systems über 400 Byte, so beträgt der ­Overhead bei der Shared-Frame-Lösung weniger als 10 %.

Bild 2: Shared-Frame-Prinzip: Ein zufälliger Zyklusfehler beeinträchtigt den Frame in einem von sieben Fällen. © Ethercat Technology Group

Auch wenn der Physical Layer (PhL) bei Ethernet generell robust ist, können etwa starke elektromagnetische Störsignale zu Kommunikationsfehlern führen. Zwar sind die meisten vernetzten Applikationen in der Lage, einen einzelnen Fehler mitunter unbeschadet zu überstehen; folgen jedoch zwei Fehler direkt aufeinander, hat man es bereits mit einer kritischen Situation zu tun. Folglich korreliert das Verhältnis zwischen Kommunikationsfehlern pro Zyklus mit den kritischen Situationen. Bezogen auf das in Bild 1 und Bild 2 dargestellte, recht realistische Beispiel bedeutet dies eine weit höhere Anzahl beschädigter Frames beim individuellen Frame-Ansatz verglichen mit der Shared-Frame-Lösung, da letztere nur rund ein Sechstel der Übertragungszeit nutzt. Ergo beeinflusst die Störung auch nur in einem von sechs Fällen den gemeinsamen Frame. Kurzum: Die Fehlerwahrscheinlichkeit innerhalb eines Netzwerk-Zy­klus ist beim Shared-Frame-Prinzip weit geringer als beim herkömmlichen, individuellen Frame-Ansatz.

Der Einfluss fehlerhafter Bits

Speziell in Motion-Control-Anwendungen kommen anspruchsvolle Algorithmen zum Einsatz, um den Sollwert und die Istwerte im Falle eines einzelnen Kommunikationsfehlers zu interpolieren. Der individuelle Frame-Ansatz führt hierbei besonders dann zu schwer vorhersehbaren Ergebnissen, wenn mehrere Achsen gekoppelt sind. Demnach resultiert aus der weit höheren Rate fehlerhafter Zyklen bei diesem Ansatz eine ganze Reihe von kaskadierten und damit kritischen Situationen. Zudem erhöht die geringe Effizienz dieser Lösung von rund 10 % – sprich, es stehen nur etwa 10 % der Bandbreite für Nutzdaten zur Verfügung – die Rate fehlerhafter Zyklen weiter und macht eine zuverlässige Steuerung der Anwendung deutlich schwieriger.

Um noch beim Thema Motion beziehungsweise der Regelung von Geschwindigkeit und Position zu bleiben: In Bezug auf die Position ist die Kon­trolle eines Werts weit kritischer als in Bezug auf die Geschwindigkeit mit nur kleinen, inkrementellen Änderungen. Somit kann je nach Applikation der Einfluss von Störungen durch geschickte Wahl der Stellgrößen minimiert werden: Geschwindigkeitsregelung über den Bus bietet sich bei bewegungsintensiven Anwendungen an, während die Lageregelung bei von Halteaufgaben geprägten Anwendungen vorteilhaft ist. So hilft das alte Programmierer-Motto "Behalte Werte, solange sich nichts ändert", die Auswirkungen von Fehlern grundsätzlich zu verringern sowie gebündelte Fehler zu vermeiden.

Bis hier lässt sich also festhalten: Es besteht keine direkte Abhängigkeit zwischen der Anzahl von Fehlern in einem Zyklus und dem aus ihnen resultierenden Steuerungsfehler. Vielmehr können einzelne Fehler sogar kritischer sein als gebündelte Fehler.

Ein weiteres Problem bei der Lösung mit einzelnen Frames für jeden Knoten ist die Isolierung von Fehlern. Grundsätzlich wird bei Ethernet die Übertragung von Störungen vermieden, da jede Verbindung von einem speziellen Transceiver kontrolliert wird. Zwar ist der PhL beim heutigen Ethernet kein Bus, sondern eine Ansammlung von Punkt-zu-Punkt-Verbindungen; dennoch kann es zu Fehlern kommen – etwa aufgrund von Störungen in der Stromversorgung –, die sich auf mehrere Knoten gleichzeitig auswirken können.

Eine vergleichbare Fehlerquelle findet sich auch in einer schlechten Anbindung an den Schutzleiter, sofern die direkte Schirmungsmethode genutzt wird. Ethercat etwa empfiehlt diese nicht, doch da sie von manchen Konsortien vorgeschrieben wird, müssen vor allem Multiprotokollgeräte diesem Ansatz folgen und dürfen keine alternativen Methoden verwenden. Da die Erdung von Schaltschränken manchmal schlechter ist als erwartet, kann es auf dem Schirm insbesondere dort zu Störungen kommen, wo verschiedene Abschnitte der Verkabelung zusammengeführt werden. In einem solchen Fall gestaltet sich die Diagnose sehr schwierig, weshalb es diese Art der Störungsübertragung nach Möglichkeit zu vermeiden gilt. Verwendet man wie bei Ethercat gemeinsame Frames, so wirkt sich eine solche Störungsübertragung lediglich mehrfach auf denselben Frame aus.

Bild 3: Beim langsamen Weiterleiten werden zahlreiche Frames beeinträchtigt. © Ethercat Technology Group

Im Falle kurzer individueller Frames mit der typischen Switch-Weiterleitungsmethode, welche vom IEEE-Standard definiert wird und die für gewöhnlich mindestens zehnmal langsamer ist als die Ethercat-Zeit, werden mehrere Frames gleichzeitig auf verschiedene Netzwerk-Teilnehmer übertragen. Hierbei entsteht ein großer zeitlicher Versatz, so dass bei einer Störungsübertragung mehrere unterschiedliche Frames betroffen sind. Dabei können ­unter Umständen Daten aus verschiedenen Zyklen beziehungsweise verschiedene Kommunikationsarten betroffen sein. Aus diesem Grund ist hier die Störungsübertragung ein sehr kritischer Faktor, der praktisch immer eine Art Domino-Effekt nach sich zieht. Bei Ethercat dagegen sind die Weiterleitungszeiten mit etwa einer halben Mikro­sekunde so kurz, so dass auch eine Störung am Anfang eines Frames nicht noch das Ende eines vorherigen Frames in der Nachbarschaft betreffen kann.

Wenn mehrere einzelne Frames beeinträchtigt sind, ist außerdem der resultierende Fehlertyp nur schwer zu definieren. So sind manche Eingangsdaten neu, andere hingegen bereits veraltet. Die Folgerung, dass es bei dieser Methode lediglich einzelne Fehler gibt, ist demnach nicht haltbar. Vielmehr erfordert es eine besonders ausgeklügelte, komplexe Fehlerbehandlungsstrategie, wenn in jedem Fehlerfall eine andere Mischung aus aktuellen und veralteten Istwerten behandelt werden muss: Die Fehlerbehandlung ist generell einfacher, wenn nur zwei Fälle (Daten aktuell oder nicht) zu berücksichtigen sind. Zudem übertragen die meisten Switches/Bridges erst, wenn sie einen Frame korrekt empfangen haben (store and forward), was für unterschiedliche Frames an jeder Schnittstelle sorgt und zur Folge hat, dass die Störungsübertragung eine hohe Anzahl an Frames beeinflusst.

Bild 3 stellt diese Abhängigkeit in einem Ort-Zeit-Diagramm dar. Horizontal sind die einzelnen Stationen aufgetragen, vertikal ist die Zeitachse zu sehen. Die Verzögerung auf der Leitung ist relativ gering. Während zum Beispiel der S4-Frame (hellgrün) von S1 zu S2 gesendet wird, überträgt S2 an S3 noch den S5-Frame (hellblau) und S4 ist damit beschäftigt, den S6-Frame (orange) an S5 weiterzuleiten usw. Während die Fehlerauswertung mit etwa 60 % der Lichtgeschwindigkeit abläuft (annähernd horizontale Linie im Ort-Zeit-Diagramm), ist die Ausbreitungsgeschwindigkeit der Frames durch komplexe Weiterleitungsprozeduren bestimmt, die allerdings bei Ethercat um etwa den Faktor 10 verkürzt werden können.

Aus Gründen der Effizienz liefern Ansätze mit individuellen Frames meist kein umgehendes Feedback. Ein direktes Feedback zum Update der Ausgangsdaten würde eine Weiterleitung vom Master zum Slave und wieder zurück erfordern. Diese Duplikation der Weiterleitungszeit wäre dann auch ein limitierender Faktor für die Zykluszeit.

Die Fehlerbehandlung ­beschleunigen

Folglich ist die Reaktion auf den Verlust individueller Ausgangs-Frames auf die einzelnen Komponenten beschränkt – ohne direkte Benachrichtigung der Steuerungseinheit. In dieser Situation können vom Master keine Maßnahmen eingeleitet werden. Der früheste Zeitpunkt, zu dem ein solcher Fehler gemeldet werden kann, ist erst einen Eingangszyklus später. Bis die Auslösung des Fehler-Timeout erfolgt, benötigt das System normalerweise drei Zyklen. Ethercat hingegen arbeitet mit einem direkten Feedback der Slaves. Aufgrund der schnellen Weiterleitungen erscheinen die Eingangsdaten im Master direkt, nachdem die Ausgangsdaten übertragen wurden. Für den Fall, dass ein Feedback ausbleibt, kann der Master sofort entsprechende Maßnahmen ergreifen und aufgrund der sehr geringen Weiterleitungsvarianz ist ein präzises Timeout möglich.

Bild 4: Direktes Feedback mit Ethercat © Ethercat Technology Group

Ein Ethercat-Frame wird vom Endgerät einer Linie wieder an den Master zurückgeleitet, was in Bild 4 in einem ­Ort-Zeit-Diagramm dargestellt ist. Da Ethernet in beiden Richtungen übertragen kann, wird das zurücklaufende Frame auf dem zweiten Kabelpaar übertragen. Die Rückantwort ist damit automatisch die Quittung, das auch die vom Master gesendeten Daten richtig übertragen worden sind.

So agiert Ethercat im Prinzip wie ein klassischer Feldbus, bei welchem eine Wiederholung sofort veranlasst werden kann. Letzteres macht jedoch den Master deutlich komplexer. Auch muss Kommunikationsbandbreite für Wiederholungen reserviert werden. Da es zudem wünschenswert ist, aktuelle Daten zu bekommen anstatt mittlerweile veraltete Daten erneut zu übertragen, verzichtet Ethercat in der Regel auf die Wiederholung im Fehlerfall und arbeitet lieber mit kürzeren Zykluszeiten, was die Auswirkungen möglicher Fehler ebenfalls reduziert.

Und last but not least: Verglichen mit Lösungen, die auf individuelle Frames setzen, sind mit Ethercat deutlich kürzere Zykluszeiten erreichbar – im Beispiel um den Faktor 6 –, was wiederum zu einer höheren Genauigkeit sowie zu einer gesteigerten Robustheit der Verarbeitung führt. Der Weg über die kürzere Zykluszeit ist demnach ein gutes Mittel, selbst im Fehlerfall die Produktqualität weiterhin zu verbessern. Und treten keine Fehler auf, wird die Qualität entsprechend noch besser.

Als Fazit lässt sich festhalten: Ein Ansatz wie der von Ethercat ­bildet auch die Basis für ein zuverlässiges Netzwerk-Design, niedrigere Bandbreitenbesetzung führt zu einer ge­ringeren Fehlerfrequenz und die schnelle Weiterleitung der Frames vermeidet Störungsübertragungen. Aufgrund der Punkt-zu-Punkt-Ver­bindung über Ethernet werden Re­flexionen sowie andere Störeinflüsse vermieden. Dies macht die Kommunikation zuverlässiger, da die Fehlerwahrscheinlichkeit gering ist und der Ort, an dem ein Fehler auftritt, leicht ermittelbar ist. Zudem kann die Zuverlässigkeit eines Systems sowohl durch die geringere Protokollkomplexität als auch durch das geringere Frame-Aufkommen auf den Kommunikationsverbindungen positiv beeinflusst werden.

Autor:
Dr. Karl Weber ist Senior Technology Expert bei der Ethercat Technology Group (ETG).