Werden die neuen Echtzeit-Standards den gewünschten Einfluss haben und mit einem Schlag Echtzeit komplett regeln? Oder ist es ein Kompromiss viele Ansprüche, auf den Automatisierer nicht bauen können? Sdecoret – Fotolia.com
Ethernet wird in den Arbeitskreisen des IEEE-802-Projekts spezifiziert und weiterentwickelt. Vor zwei Jahren wurde dort auch die Task Group ‚Time Sensitive Networking‘ (TSN) etabliert. Ziel der Arbeitsgruppe: Ethernet für zeitkritische Anwendungen nutzbar machen. Allerdings bietet die IEEE 802 keine Komplettlösung an, sondern liefert Standards auf der Datenübertragungsschicht, die eine Einbindung in ein Anwendungskonzept erfordern.
Ursprünglich war geplant, diese Projekte der Task Group Time Sensitive Networking bis Ende 2016 zum Abschluss zu bringen. Doch zusätzlich zu den sechs bisher vorgeschlagenen Erweiterungen des Ethernet-Standards (siehe Kasten) werden mittlerweile weitere Projekte diskutiert, zum Beispiel ein Verfahren, bei dem die zeitkritischen Nachrichten pro Zyklus nur zum nächsten Nachbarn weitergeleitet werden (IEEE 802.1Qch). Dies ist dann von Vorteil, wenn die Kaskadiertiefe gering ist. Der Ansatz kann helfen, drahtlose Geräte oder andere Komponenten mit schwer bestimmbarer Latenz einzubinden und ist robuster als die Zeitsteuerung.
Technik im Detail
Die Echtzeit-Standards
Die TSN-Gruppe hat bis heute sechs Standardisierungsprojekte auf den Weg gebracht:
- Verbessertes Synchronisationsverhalten (IEEE 802.1ASbt)
Die Vorgängerversion IEEE802.1AS hatte bereits ein Synchronisationsprotokoll zum Abgleich der Zeitsteuerung von verteilten Uhren spezifiziert, das sich an den Standard IEEE 1588 anlehnte. Dabei hatte man die Integration in eine Standard-Ethernet-Umgebung vorangetrieben. Die Kompatibilität zu anderen 1588-Ethernet-Profilen ging dabei verloren. Verbessert werden soll nun vor allem die Reaktion auf Fehlersituationen, wie den Ausfall einer Kommunikationsleitung oder des Masters. Auch verschiedene Zeitdomänen in einem Gerät sollen mit der neuen Version möglich sein.
- Unterbrechung (Preemption) langer Frames (IEEE 802.1Qbu)
Ein Hauptproblem für die deterministische Übertragung zeitkritischer Nachrichten sind die auf demselben Netzabschnitt vorhandenen zeit-unkritischen Datenströme, wobei ein einzelnes Frame mehr als 1.500 Bytes lang sein kann. Dadurch können Verzögerungen von bis zu 125 µs pro Knotendurchlauf auftreten. Dies reduziert ein Frame-Unterbrechungsmechanismus (innerhalb der IEEE-Arbeitskreise im Ethernet-Projekt P802.3br spezifiziert). Letztendlich erfordert dieser Mechanismus nicht nur neue Netzkomponenten, sondern auch neue Ethernet-Bausteine.
- Zeitsteuerung der Übertragungseinrichtung (IEEE 802.1Qbv)
Bei TSN spielt die Zeitsteuerung der Sendevorgänge eine zentrale Rolle. Wie im realen Leben kann es auch auf Datenautobahnen zu Staus kommen, und auch bei hochprioren Echtzeitdaten und Preemption gibt es immer noch eine gewisse Variation in der Übertragungszeit. Da die zeitkritischen Ströme zyklisch übertragen werden, kann man durch Blockieren der nicht so zeitkritischen Daten eine weitgehend ungestörte Kommunikation realisieren. Man kann sich das wie eine Ampelsteuerung vorstellen.
- Erfassung der Netztopologie und Pfadauswahl (IEEE 802.1Qca)
Um möglichst schnell von A nach B zu kommen, braucht man eine Karte und einen Routenplaner. Genauso wie im täglichen Leben muss man in einem Netz erfassen, wie die Komponenten angeordnet sind und wie man die Kommunikationsstrecken am effizientesten auswählt. Als Protokollbasis wird das Konzept ‚Intermediate System to Intermediate System‘ (IS-IS) präferiert, das auch von Routern genutzt wird. Dabei werden alle Topologieinformationen der Nachbarknoten gesammelt und über weitere Kanäle verteilt. Nach mehreren Iterationsschritten haben dann alle Knoten alle Topologieinformationen aus dem gesamten Netz. Wenn es mehrere Wege zum Ziel gibt, kann man so den kürzesten finden. Auch redundante Wege lassen sich damit ermitteln.
- Stoßfreie Redundanz (IEEE 802.1CB)
Zwar gibt es bereits in der IEC spezifizierte Protokolle für stoßfreie Redundanz wie High-availability, Seamless Redundancy (HSR) oder Parallel Redundancy Protocol (PRP), aber diese erfordern es, den kompletten Datenaustausch zwischen Stationen redundant auszulegen. Das kann zu Problemen führen, weil die Reihenfolge der Nachrichten im Fehlerfall nicht eingehalten wird. Auch die Diagnose von Fehlersituationen ist dabei recht komplex. Aus diesem Grund hat man sich in der IEEE 802.1 dafür entschieden, die stoßfreie Redundanz explizit nur für einzelne kritische Datenströme anzuwenden. Damit lässt sich der Protokollaufwand verringern und die kritischen Stellen sind leichter zu identifizieren.
- Bandbreitenreservierung (IEEE 802.1Qcc)
Ein großes Problem bei Ethernet sind Überlastsituationen, wenn etwa über zwei Kanäle Daten empfangen und über einen einzelnen Ausgang weitergeleitet werden. Auch ein großer Speicher ist suboptimal, da mit dem Füllstand die Verweilzeit immer mehr ansteigt. In der Automatisierungstechnik lässt sich diese Verzögerung (Best Effort) nicht durch die erhöhte Reaktionszeit regulieren. Um dieses Verhalten zu eliminieren, werden Echtzeitdatenströme bevorzugt behandelt. Damit läuft man jedoch Gefahr, dass sich die Überlastsituationen noch weiter verstärken, wenn der Anteil der Echtzeitkommunikation zu groß wird. Aus diesem Grund wird hier genau bestimmt, welche Bandbreite erforderlich ist. Diese wird dann fest reserviert. Das Protokoll ermöglicht eine Echtzeitlast von bis zu 80 % der Bandbreite und ist eine Erweiterung des bereits existierenden Reservierungsprotokolls.
Darüber hinaus diskutieren die Experten, wie man die Effekte von fehlerhaft agierenden Knoten klein halten kann. Dazu muss die Eingangsseite (Ingress) der Netzknoten die Partner überwachen. Auch in Ethernet selbst werden Veränderungen vorgenommen: hier ist vor allem die neue Zweidraht-Übertragungstechnik (100 Mbps: IEEE P802.3bw, 1 Gbps: IEEE P802.3bp) anzuführen, bei der ungeschirmte Kabel zum Einsatz kommen können. Treiber der neuen Projekte sind vor allem die Automobilbauer. Denn wenn die Prognosen von einer halben Milliarde Ethernet-Knoten im Fahrzeug bis 2022 zutreffen (‚Automotive Ethernet: Market Growth Outlook‘, Ian Riches, Strategy Analytics) wird das auch andere Märkte nachhaltig beeinflussen – nicht nur die direkten Automotive-Zulieferer.
Die Datenströme werden so organisiert, dass keine Überlastsituationen auftreten können. Beckhoff
Hilft TSN den Automatisierern wirklich?
Kleine Datenmengen lassen sich mit den in TSN definierten Verfahren nicht effizient verteilen oder einsammeln. Im Vergleich zu einer Ethercat-Lösung würde man auch im optimalen Fall bei einem typischem Datenaufkommen von unter 10 Bytes je Teilnehmer bei TSN einen zehnfach höheren Protokolloverhead haben. Der TSN-Ansatz mit seiner signifikant schlechteren Effizienz ist also nicht wirklich für den klassischen I/O- oder Antriebsbereich geeignet. Er kann aber Vorteile in einem heterogenen Umfeld mit Datenmengen von über 100 Bytes pro Transfer haben. Ein solches Umfeld findet sich beispielsweise bei der Vernetzung von Steuerungen, bei Robotern im Zellenbereich oder auch bei der Einbindung von Kamerasystemen.
TSN-Standards liefern keine maßgeschneiderten Lösungen
Da Standards auf Einzelfälle und Sonderwünsche keine Rücksicht nehmen können, können Funktionen entstehen, die für die spezifischen Anwendungsfälle der Automatisierung nicht gut passen. So werden in der IEEE802.1Qca zwar topologische Informationen verteilt, allerdings hat man so viel Funktionalität in dieses Protokoll gepackt, dass ein erheblicher Übertragungs- und Speicheraufwand anfällt. Die mangelnde Skalierbarkeit schränkt die Nutzbarkeit für einfach ausgeprägte Knoten ein. Man könnte die wirklich wichtigen Informationen zur Topologie mit einem deutlich geringeren Aufwand verteilen.
Die Organisation von Datenströmen muss wie ein Fahrplan eines Schienennetzes organisiert werden, allerdings ist hier ein Umsteigen nicht vorgesehen. Beckhoff
Außerdem wurden Freiheitsgrade in der Synchronisation in der IEEE 802.1AS eingeschränkt. Aber das Verhaöten der einzelnen Knoten kann zeitlich beliebig variieren, was sich auf die Regelung des Taktes negativ auswirken kann. So führt eine verzögerte Anpassung der Zeit in den einzelnen Knoten in kritischen Augenblicken zu einer erhöhten Ungenauigkeit.
Mit einer Zeitsteuerung kann man zwar den Einfluss von anderen Protokollen auf zeitkritische Aktionen eliminieren, aber darüber hinaus müsste man den verbleibenden Echtzeitverkehr so regeln, dass der zyklische Datenaustausch ohne Verzögerungen realisiert werden kann. Das ist jedoch ein komplexes Optimierungsproblem und auch bei einer nicht so hohen Zahl von Datenströmen lässt sich das Optimum nicht innerhalb einer vernünftigen Zeitspanne ermitteln.
Integration in die Anwendungen
Die IEEE 802 kümmert sich nur um die Datenübertragung. Eine sogenannte Applikations-Schicht ist zusätzlich erforderlich, um die Kommunikation in das operative Geschehen einzubinden. Auf Zellenebene dominieren aber heute die privaten Protokolle einzelner Steuerungshersteller. Es gibt Standards auf der I/O-Ebene, die in verschiedenen Systemen in ähnlicher Weise angeboten werden, allerdings meist mit eingeschränkten Adressiervolumen, die bei strukturierten Systemen hinderlich sein können. CANopen-basierte Protokolle mit einigen Erweiterungen, wie sie bei Ethercat zur Anwendung kommen, kämen als geeignete Zwischenebene in Frage. Dies würde den Übergang zur I/O-Protokollwelt erleichtern und wäre sowohl im zyklischen als auch azyklischen Bereich effizient.
Technik im Detail
Im Februar 2013 griff die IEE das Thema Time Sensitive Networking das erste Mal auf. Damals prägten die Ursprünge der TSN-Initiative, die Audio- und Videoübertragung, die Ideen rund um die neuen Echtzeit-Standards noch deutlich. Die Grundlagen der in die IEEE eingereichten Erweiterung der Norm 802 waren aber bereits gelegt.
TSN ein Erfolgsmodell?
Die industrielle Kommunikation hat dazu beigetragen, die Automatisierungstechnik entscheidend voranzutreiben. Sie hat aber auch eine ganze Reihe von Entwicklungsgräbern produziert, wie etwa das Manufacturing Automation Protokoll (MAP) oder auch den Versuch, mit .NET-Komponenten zu vernetzen. Alle gescheiterten Ansätze zeichneten sich durch eine unnötig hohe Komplexität der Protokolle bei recht geringer Effizienz aus und hatten sich nicht an den Bedürfnissen der Automatisierer orientiert. TSN hat ebenfalls eine Tendenz hin zu komplexeren Verfahren. Aber es gibt eine Reihe von Firmen, die ein starkes Interesse an einem standardisierten Echtzeit-Ethernet haben. Allerdings gibt es auf der Feldebene heute bereits gute und an die Automatisierung angepasste Lösungen, sodass hier die Bereitschaft nicht hoch sein wird, einen weiteren Feldbus zu etablieren. Weiter oben in der Automatisierungspyramide könnte TSN jedoch eine wichtige Rolle spielen.
Durch ein Ampelsystem kann eine Verzögerung von Datenströmen durch niederprioren Verkehr vermieden werden. Beckhoff
Also macht es sehr wohl Sinn, sich mit TSN und den damit verknüpften Aktivitäten auseinanderzusetzen, auch wenn noch einiges offen ist. Dabei müssen Automatisierer und Automatisierungsanbieter auf das bisher Erreichte in der I/O-Ebene aufsetzen. Wenn TSN ein Erfolgsmodell für die Automatisierung in einer heterogenen Zelleninfrastruktur werden soll, muss man sich auf ein Anwendungsprotokoll einigen und die geeigneten Echtzeitmechanismen aus dem TSN-Fundus auswählen.
Dr. Karl Weber
(mf)
