Time-Sensitive Networking (TSN): Was ist das und wie geht das?

Ob sie nun Profibus, Profinet oder EtherCat heißen: Wen es um vernetzte Echtzeit-Lösungen geht, stehen in der Industrie zahlreiche unterschiedliche Standards in Konkurrenz. OPC/UA over TSN könnte nun erstmals eine einheitliche Lösung bieten. Was steckt dahinter?

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Open Source Automation Development Lab (OSADL) eG

Im Vergleich zum weltweit enormen Erfolg von Standard-Ethernet und dessen allgegenwärtiger Verbreitung und Verfügbarkeit sieht es bei Echtzeit-Ethernet völlig anders aus: Hier haben sich in erster Linie proprietäre und untereinander nicht kompatible Verfahren durchgesetzt. Mit der Standardisierung von TSN, der benötigten ebenfalls standardisierten Erweiterung des schon lange vorhandenen Protokolls OPC UA und dessen Verfügbarkeit unter einer Open Source-Lizenz könnte sich dies nun ändern.

Dieser Beitrag erläutert die technische Basis von TSN und OPC UA mit Publish- und Subscribe-Erweiterungen und zeigt einen Weg auf, wie ein alter Traum Wahrheit werden könnte: Uneingeschränktes Echtzeit-Ethernet für jedermann.

Bildergalerie

Bildergalerie mit 11 Bildern

Was ist Echtzeit, wie sollten derartige Systeme bezeichnet werden?

Der Begriff „Echtzeit“ wurde vor langer Zeit eingeführt, obwohl der Wortsinn dieses Begriffs eigentlich nicht korrekt dessen übliche Verwendung beschreibt. Denn basierend auf dem Wortsinn müsste „Echtzeit“ die „richtige Uhrzeit“ bedeuten, also die zu einem bestimmten Zeitpunkt an einem bestimmten Ort gültige Zeit. Diese „richtige Uhrzeit“ hat den Nachteil, dass sie nicht notwendigerweise monoton ansteigt, sondern mitunter automatisch oder manuell nachgeführt werden muss. Eine solche Notwendigkeit zur Nachführung entsteht z.B. durch Einfügung von Korrektursekunden wegen mechanischer Unregelmäßigkeiten von Himmelskörpern, durch willkürliche Zeitsprünge wie bei Umschaltung von Normalzeit auf Sommerzeit oder durch Verbringung von mobilen Systemen in eine andere Zeitzone.

Aber der etablierte Begriff „Echtzeit“ bedeutet dies gerade nicht, sondern bezeichnet Systeme, die in der Lage sind, in einem typischen maximalen Zeitraum auf nicht vorhersagbare externe Ereignisse zu reagieren und daher eine Uhr benötigen, die ohne Zeitsprünge kontinuierlich weiterläuft. Solche Systeme sollten besser als „deterministische Systeme“ bezeichnet werden; darüber hinaus ist es wünschenswert, dass zusätzlich noch angegeben wird, wie lange es maximal dauern kann, bis ein System reagiert.

In Anlehnung an die Klassifizierung von feuerfesten Türen, die nach DIN 4102-5 mit dem Buchstaben „T“ und einer Zahl bezeichnet werden, wobei die Zahl die Dauer in Minuten angibt, wie lange die Tür das Feuer abhalten und sich noch öffnen lassen muss (z.B. T30-, T60-, T90-Tür), könnte man Systeme, die üblicher-, aber fälschlicherweise Echtzeit-Systeme genannt werden, mit dem Buchstaben „D“ gefolgt von einer Zahl bezeichnen. Die Zahl würde dann die maximale Reaktionszeit in Mikrosekunden angeben. So weist ein üblicher in industriellen Steuerungen eingesetzter 1-GHz-Prozessor typischerweise eine maximale Reaktionszeit von 100 μs auf und könnte dementsprechend als D100-System bezeichnet werden. Aber auch Anforderungen könnten entsprechend klassifiziert werden: Wird z.B. eine industrielle Steuerung benötigt, die nach spätestens 500 μs reagieren muss, würde es sich um eine „D500-Anforderung“ handeln.

Übrigens hat die genannte Unschärfe des Begriffs „Echtzeit“ bzw. „Realtime“ speziell im Zusammenhang mit Linux-Echtzeitprogrammierung bereits zu erheblicher Verwirrung geführt. Denn die Präprozessor-Definitionen für die verschiedenen Uhren des Linuxkernels verwenden den Begriff „Realtime“ im Wortsinn und bezeichnen die Uhr, welche die aktuelle Uhrzeit wiedergibt, aber durchaus Sprünge aufweisen kann, als CLOCK_REALTIME und die monoton stetig fortschreitende Uhr, die in Echtzeitanwendungen zwingend verwendet werden muss, als CLOCK_MONOTONIC. Da es aber bisher übliche und unveränderte Praxis ist, die Anforderung an Determinismus als „Echtzeit“-Anforderung zu bezeichnen, wird dies auch in diesem Beitrag weiterhin so gehandhabt.

Was ist Echtzeit-Ethernet?

In der gleichen Weise wie von einem Echtzeit-System deterministisches Antwortverhalten erwartet wird, muss Echtzeit-Ethernet ein deterministisches Transportverhalten aufweisen. Dies bedeutet, dass beim Absenden eines Netzwerkpakets dieses so konfiguriert werden kann, dass es zu einem bestimmten Zeitpunkt zuverlässig auf dem Zielrechner ankommt. Und zwangsläufig bedeutet dies dann auch, dass das Netzwerkpaket zu einem vorhersagbaren Zeitpunkt von einem Anwenderprogramm empfangen und bearbeitet wird. Insofern ist es aus praktischen Gründen unabdingbare Voraussetzung für Echtzeit-Ethernet, dass auch das jeweilige Betriebssystem von Sender und Empfänger echtzeitfähig ist. Man könnte zwar theoretisch eine echtzeitfähige Transportschicht auf einem nicht-echtzeitfähigen Computer installieren, aber dies hätte wohl kaum jemals praktischen Nutzen.

Zwei verschiedene Ansätze, um Echtzeit-Ethernet zu realisieren

1. Exklusive Verbindung zweier Rechner mit UDP
Um Echtzeit-Ethernet zu realisieren, kann man die gesamte Strecke vom 1. Versenden eines Pakets durch ein Anwenderprogramm, 2. Versenden dieses Pakets durch den Netzwerkadapter des Senders über 3. die physikalische Verbindung zum Netzwerkadapter des Empfängers und 4. bis zur Programmfortsetzung eines auf eine Netzwerknachricht wartenden Anwenderprogramms so gestalten, dass diese Sequenz vorrangig abläuft. Wenn auf Sender- und Empfängerrechner jeweils ein echtzeitfähiges Betriebssystem installiert ist, die beiden Rechner exklusiv und bidirektional miteinander verbunden sind, zunächst kein anderer Netzwerkverkehr gleichzeitig über diese Netzwerkverbindung gesandt wird und das besonders anspruchslose Protokoll UDP verwendet wird, dann lässt sich damit im Prinzip eine Echtzeit-Ethernet-Verbindung realisieren. Das Ergebnis einer Messung der kombinierten Sende- und Empfangsdauer einer Netzwerkverbindung mit diesen Bedingungen ist in Bild 1 gezeigt.

Zweimal am Tag wurde für jeweils knapp drei Stunden eine Messung durchgeführt, wobei Netzwerkpakete mit einem Zyklusintervall von 500 μs versandt, vom Empfänger unmittelbar an den Sender zurückgesandt und deren Zeiten registriert wurden. Die in Bild 1 über die Zeit aufgetragenen Werte repräsentieren jeweils die maximale Dauer eines kompletten Sende- und Empfangsvorgangs während aufeinanderfolgender 5-Minuten-Intervalle. Es ist erkennbar, dass die Dauer zu keinem Zeitpunkt 343 μs überschreitet und sich damit dieses Verfahren vermutlich für eine echtzeitfähige Ethernet-Verbindung eignet.

Das beschriebene Verfahren lässt sich dahingehend optimieren, dass auch anderer nicht-echtzeitfähiger Netzwerkverkehr zugelassen werden kann. Dies erfolgt durch Aufspaltung des physikalischen Netzwerks in logische Teilnetze mit Hilfe von Virtual Local Area Network (VLAN) und Zuordnung von Bearbeitungsprioritäten. Im vorliegenden

Fall wurden die echtzeitpflichtigen UDP-Netzwerkpakete über das hochpriorisierte VLAN eth1.2 versandt (Bild 2), während gleichzeitig anderer Netzwerkverkehr zwar mit hoher Bandbreitennutzung bis 20 Mb/s, aber niedriger VLAN-Priorität über eth1.3 versandt wurde (Bild 3).

Da Netzwerk-Switche erhältlich sind, die über VLAN verfügen, kann das beschriebene Verfahren, das sich ausschließlich mit Open Source-lizenzierter Software realisieren lässt, durchaus auch in einer entsprechend erweiterten Topologie eingesetzt werden, was beim Messaufbau für die Gewinnung der Daten in den Bilden 1 bis 3 der Fall war. Aber die Hinzunahme weiterer Rechner ist nicht möglich, und als darüber hinaus relevanter Nachteil des Verfahrens muss angemerkt werden, dass sich alle Zeitangaben dieser Echtzeit-Netzwerkverbindung immer auf die Uhrzeit des Senders beziehen. Insofern kann der Empfänger Antwortpakete oder auch eigenständige neue Pakete immer nur relativ zur Uhrzeit des Senders versenden. Da es aber in vielen Fällen durchaus wünschenswert ist, dass alle beteiligten Rechner relativ zur gleichen Uhrzeit Netzwerkpakete senden und empfangen können und aktuelle Anforderungen wie zum Beispiel für das Internet der Dinge von einer großen Anzahl angeschlossener Rechner ausgehen, ist dieses Verfahren zur Realisierung von universell verwendbarem Echtzeit-Ethernet nicht zukunftsfähig.

2. Time-Sensitive Network (TSN)
Ein zweiter grundsätzlich unterschiedlicher Ansatz für Echtzeit-Ethernet geht davon aus, dass alle im Netzwerk zusammengeschalteten Rechner hochgenau zeitlich synchronisiert sind. Die dabei geforderte Gangabweichung liegt um Dimensionen niedriger als üblicherweise im Internet mit dem Network Time Protocol (NTP) erreichbar ist. Während sich mit dem NTP-Verfahren maximale Abweichungen im Millisekundenbereich erreichen lassen (Bild 4), wird für ein universell verwendbares Echtzeit-Ethernet eine Rechnersynchronisation im Submikrosekundenbereich gefordert. Wenn Rechner mit einer derartig hohen Präzision mit definierter maximaler Gangabweichung synchronisiert werden und ein Sendeverfahren bereitgestellt wird, das es erlaubt, Netzwerkpakete zu einem bestimmten Zeitpunkt und mit bekannter Übertragungsgeschwindigkeit absenden zu lassen, dann kann man den spätestmöglichen Empfangszeitpunkt eines Netzwerkpakets präzise vorhersagen und auf diese Weise Echtzeit-Ethernet realisieren.

Genau dies – und noch vieles mehr – verbirgt sich hinter den verschiedenen Methoden, die unter dem gemeinsamen Begriff Time-Sensitive Network (TSN) zusammengefasst werden. Diese Methoden sind mit einer Ausnahme in der Gruppe IEEE 802.1Qxx standardisiert. Bei der Ausnahme handelt es sich um das Verfahren zur hochgenauen Rechnersynchronisation, das ein spezielles Profil des bereits vor längerer Zeit als IEEE 1588 standardisierten Precision Time Protocol (PTP) verwendet und voraussichtlich in naher Zukunft unter dem Standard IEEE 802.1AS-rev veröffentlicht werden wird. Insgesamt werden wohl mehr als zehn unterschiedliche Standards die verschiedenen Komponenten von TSN beschreiben; allerdings sind erst ein kleiner Teil davon verabschiedet, und aktuell stehen unter Linux bzw. bei unter Linux lauffähiger Netzwerk-Hardware zunächst die ersten drei in Tabelle 1 genannten Verfahren zur Verfügung.

Während alle genannten in IEEE 802.1Q zusammengefassten Standards und selbstverständlich auch VLAN ausschließlich die Link-Layer-Schicht (Schicht 2) der im Open Systems Interconnection (OSI) Referenz-Modell definierten Schichten betrifft, sind für die komplette Realisierung von Echtzeit-Ethernet mit Hilfe von TSN zusätzliche Komponenten in fast allen Schichten erforderlich (Tabelle 2).

Dies bedeutet, dass Spezialisten aus verschiedenen Bereichen zusammenarbeiten müssen, um die erfolgreiche Einführung von auf TSN basierendem Echtzeit-Ethernet zu ermöglichen. Benötigt werden

• Netzwerk-Hardware mit TSN-Unterstützung: Netzwerkadapter, Switche, Router

• Linuxtreiber für die Netzwerkadapter

• Bibliotheken für Anwenderprogramme

• Anwenderprogramme zum Konfigurieren von TSN-Komponenten

(ID:45747486)