TSN, als Teil von IEEE 802.1 Ethernet, ist ein Netzwerkstandard und ent-sprechend relevant für die Kommunikations-Infrastruktur. Noch bedeutender ist TSN aber als Basistechnologie für konvergente IT/OT-Netzwerke und somit für die Endpunkte, auf welchen die zukünftigen Applikationen realisiert werden. Genauso wie es bei Ethernet heute der Fall ist, liegt das größte Potenzial – und somit auch Geschäfte und Umsätze – bei den über das Netz laufenden Applikationen. Kein Geschäftsmodell im Internet differenziert sich durch einen besseren Ethernet-Treiber von der Konkurrenz – genauso wenig wird dies bei TSN für innovative Industrie- applikationen der Fall sein. Viel wichtiger als eine eigene ‚bessere‘ Implementierung sind für alle Teilnehmer in einem TSN-Netzwerk Interoperabilität, Stabilität, Robustheit, eine schnelle Entwicklung des Ökosystems und Durchdringung des Marktes.

Offene Lösungen können hierzu einen entscheidenden Anteil liefern. Denn sie ermöglichen: 

• Direkt einsetzbare Implementierungen,

• ‚Inspiration‘ und Referenz für proprietäre Lösungen,

• Unterstützung der Standardisierung durch frühzeitiges Testen und Validieren,

• Grundlage zur Entwicklung innovativer Applikationen und Geschäftsmodelle vor der Verfügbarkeit des gesamten Ökosystems.

Viele verschiedene Hersteller und Initiativen tragen deshalb aktiv zu Open-Source-Lösungen bei. Zu nennen seien hier Projekte wie AccessTSN (Linutronix, Hirschmann, ISW und HS Offenburg), Organisationen wie OSADL (mit IOSB und Kalycito), Linaro als Unterstützer verschiedener Hardware-Hersteller und einzelne Unternehmen wie Intel.

Open Source ist für viele in der Automatisierungsbranche Neuland und wird oft noch sehr kritisch gesehen. Aktuell sind selbst Basistechnologien oft proprietäre Lösungen und für einige Unternehmen zuverlässige Cash-Cows. Außerdem haftet in der Automatisierungsbranche Open Source häufig das Vorurteil an, eine von idealistischen Hobbyprogrammierern getriebene Community zu sein. Ein Blick in andere Branchen – ob IT oder Mobile – zeigt, dass Open Source durchaus als Enabler für innovative, effiziente, zuverlässige und nachhaltige Anwendungen und Geschäftsmodelle taugt. Dementsprechend sollten alle Beteiligten bemüht sein, sich bei der digitalen Transformation der Automatisierungsbranche nicht in Details der Basis-technologien zu verlieren, sondern den Fokus auf innovative Applikationen zu richten.

TSN-Endpunkte

Die Struktur und Funktionen eines TSN-Endpunkts.

© ISW

Open-Source-Lösungen haben in erster Linie für die TSN-Endpunkte eine hohe Relevanz. Den einen typischen Endpunkt gibt es jedoch nicht. Vielmehr kann der Grad der unterstützten TSN-Funktionen bei den jeweiligen Endpunkten applikationsspezifisch sehr unterschiedlich sein. Kategorisieren lassen sich Endpunkte hinsichtlich verschiedener Aspekte:

• Signifikante Unterschiede bei der zur Verfügung stehenden Rechenleistung resultieren in der Entscheidung, ob ein Betriebssystem oder eine Bare-Metal-Implementierung zum Einsatz kommt. 

• Die deterministischen Anforderungen können von ‚lediglich Konnektivität‘ zum Netzwerk bis hin zu nanosekundengenauer Synchronisierung reichen.

• Große Unterschiede gibt es auch bei der Hardware-Unterstützung der TSN-Funktionen sowie bei der Anzahl der Ports. 

Das Bild oben zeigt eine verallgemeinerte Übersicht über die Struktur und Funktionen eines TSN-Endpunkts. Aber welche Funktionen braucht es in den TSN-Endpunkten genau und welche offenen Lösungen stehen für diese Funktionen heute schon zur Verfügung?

Das Echtzeit-Betriebssystem

Insbesondere bei industriellen Anwendungen müssen neben dem Kommu-nikationsnetz die Endpunkte deterministische Anforderungen erfüllen. Wenn ausreichend Ressourcen zur Verfügung stehen – sodass keine Bare-Metal-Lösung oder ein minimales Betriebssystem genutzt werden müssen – ist Linux mit der Echtzeit-Erweiterung Preempt-RT eine gute Option. Durch das ständig wachsende Ökosystem, eine große Community und die zunehmende Inte-gration in Mainline-Linux sind Lösungen für viele Aufgaben bereits verfügbar, ein breiter Hardware-Support garantiert und eine nachhaltige Unterstützung gewährleistet.

Die Zeitsynchronisation

Eine gemeinsame Zeitbasis ist für verteilte Echtzeit-Anwendungen in einem TSN-Netzwerk essenziell. Für die hierfür genutzten Synchronisations-protokolle, IEEE 1588, das darauf basierende IEEE 802.1AS und die dieses Jahr erscheinende Revision gibt es offene Implementierungen. Von zentraler Bedeutung ist hier Linux PTP (ptp4l). Dieses unterstützt IEEE 1588 vollwertig und 802.1AS-2011 für Endpunkte. Fehlende Features zur vollständigen Unterstützung von Bridges sowie der neuen Funktionen im Kontext von 802.1AS-2020 werden aktuell diskutiert und entwickelt. Linux PTP kann sowohl als reine Softwarelösung oder aber auch mit Hardware-Unterstützung arbeiten. Ebenso kann dank entsprechender Mechanismen das lokale Echtzeit-System mit der synchronisierten Uhr, welche sich in der Netzwerk-Karte befinden kann, synchronisiert werden.

Das Traffic Management

Der Schedule nach IEEE 802.1Qbv und die ­zugehörige qdisc-Konfiguration.

© ISW

Zur Gewährleistung einer determinis-tischen Kommunikation werden im Kontext von TSN verschiedene Mecha-nismen zur Steuerung des Datenverkehrs genutzt. Die relevantesten sind das zeitgesteuerte Senden von Daten, beispielsweise für Streams und das klassenbasierte Senden von Daten entsprechend eines Schedules (IEEE 802.1Qbv). 
Die grundlegende Kommunikationsarchitektur für Ethernet bleibt in Linux auch bei Hinzunahme von TSN-Features bestehen: Applikationen übergeben mittels Sockets Daten an den Kommunikations-Stack, welcher unter Nutzung hardwarespezifischer Treiber die Daten an die Netzwerk-Karte übergibt. Innerhalb des Stack existieren bereits Strukturen zum Sortieren und Prio-risieren von Paketen. Hierzu kommen die Queueing Disciplines (qdiscs) zum Einsatz, welche hierarchisch organisiert sind und anwendungsabhängig konfiguriert werden können. 

Für das zeitgesteuerte Senden von Daten haben insbesondere zwei Mecha-nismen eine zentrale Bedeutung: Zum einen wurde eine neue Socket-Option in Linux eingeführt, welche es erlaubt, Paketen einen Sendezeitstempel zu übergeben (Launch Time). Um das Senden zur gewünschten Zeit sicherzu-stellen, kommt die neu eingeführte qdisc etf (earliest txtime first) zum Einsatz. Diese sortiert zu sendende Pakete entsprechend der Zeitstempel und stellt eine deterministische Kommunikation sicher. Falls verfügbar, kann auch auf hardwarebasierte zeitgesteuerte Sendemechanismen zurückgegriffen werden (Hardware-Offloading).
Für ein klassenbasiertes Senden entsprechend eines IEEE-802.1Qbv-Schedules kann auf die neue qdisc taprio zurückgegriffen werden. Diese erlaubt das Mapping der Linux-Prioritätsklassen auf Netzwerk-Prioritätsklassen und Zeitslots. Das Bild oben zeigt eine beispielhafte Konfiguration des Mecha-nismus entsprechend des dargestellten Schedules. Hier ist ebenso ein Hardware-Offloading möglich. Eine effiziente Konfiguration und somit Nutzung der neuen Mechanismen ist momentan im Fokus verschiedener Aktivitäten.

Die Multiport-Unterstützung

Insbesondere in der Automatisierungsbranche sind Geräte mit mehreren Ports weit verbreitet und werden auch in TSN-basierten Netzwerken vorkommen. In der Vergangenheit waren dies üblicherweise proprietäre und hardware-abhängige Lösungen. Für TSN liegen bereits offene Ansätze vor, wie sich diese Geräteklasse einheitlich abstrahieren und nutzen lässt. Details dazu siehe auch Seite 5 „Switched Endpoints auf Linux-Basis“.

Protokolle auf höheren Schichten

Florian Frick ist Gruppenleiter Echtzeit­kommunikation und Steuerungshardware am ISW Stuttgart.

© ISW

TSN als Teil von Ethernet deckt die Schichten 1 und 2 des OSI-Modells sowie die Zeitsynchronisation ab. Anwendungen benötigen daher stets Protokolle auf den höheren Schichten. Für klassische IT-Anwendungen finden auch weiterhin die etablierten Standards wie TCP, IP, http und ähnliche Verwen-dung, für welche es die bekannten offenen Lösungen gibt. 
In der Automatisierungsbranche spielt OPC UA eine zentrale Rolle. Während branchenweit Einigkeit hinsichtlich der Nutzung von OPC UA für die Kommuni-kation von den Steuerungen zur IT und meist auch von Steuerung zu Steuerung herrscht, gibt es hinsichtlich der Feldebene zwei konkurrierende Lager: die einen favorisieren auch hier eine Standardisierung bis hoch zur Applikationsebene mit OPC UA, die anderen streben die Nutzung bestehender Feldbus-Protokolle über TSN an. Neben weiteren offenen Implementierungen gibt es für OPC UA ein von einer breiten industriellen Community unterstütztes Projekt, welches auch die Pub-Sub-Standards unterstützt: open62541. Eine Einführung in das Projekt gibt der Bericht auf Seite 6 „OPC UA PubSub über TSN“.

Bereit loszulegen?

Zusammenfassend lässt sich festhalten, dass viele TSN-Mechanismen bereits ­heute unterstützt werden und sich nahtlos in das bestehende Ökosystem inte­grieren. Für eine erste experimentelle ­Nutzung oder aber auch den Grundstein für zukünftige Projekte kann mit einer Vielzahl bereits verfügbarer PC- und Embedded-Hardware gearbeitet werden. Um den Start möglichst einfach zu ge­stalten wird im Rahmen des Access-TSN-Projekts eine Beispiel-Konfiguration zur freien Nutzung angeboten (mehr Informationen).

TSN in Corona-Zeiten

Meinrad Happacher, Editor at Large Computer&AUTOMATION

© WEKA Fachmedien

Ohne Frage, auch die TSN-Community ist von den Auswirkungen der Pandemie stark betroffen: Die Anzahl abgesagter Meetings von IEEE, IEC, OPC Foundation, FLC Group sowie der Testbeds steigt täglich an und viele abzuarbeitende Aufgaben werden deswegen sicherlich etwas länger dauern als erhofft. Nichtsdestotrotz geht es voran, ob bei den Standards wie AS, der Konfiguration oder verfügbaren Produkten. 
Für die potenziellen Nutzer der Techno-logie gibt es trotzdem keinen Grund, die Entwicklungsarbeiten von TSN-Lösungen hinauszuzögern. Die Grundlagen sind ausreichend stabil und Lösungen beeits verfügbar, um Entwicklungen anzugehen. 
Passend dazu geht dieser zweite Teil dieser Artikelserie nun auf offene Lösungen für TSN ein. Sollten Sie selbst bereits an einem Prototypen arbeiten oder dazu inspiriert werden, stellen Sie sich sicher die Frage, wie Sie die neuesten Entwicklungen sinnvoll testen können. Darauf nehmen wir bald im nächsten Teil der Serie Bezug.

Ihr Florian Frick und Meinrad Happacher