Time-Sensitive Networking mit Linux

Anbieter zum Thema

Linutronix GmbH

Die Time-Sensitive Networking (TSN)-Erweiterungen erlauben echtzeitfähige und deterministische Kommunikation über herkömmliches Ethernet. Als Betriebssystem für die Endgeräte kommt oftmals Linux zum Einsatz. Inwiefern lassen sich TSN-Netzwerke mit einem Mainline-Linux realisieren?

Linux ist ein mächtiges Betriebssystem, welches insbesondere in Verbindung mit dem PREEMPT-RT Patch um die Echtzeitfähigkeit erweitert wird. Daher ist Linux eine populäre Wahl als Betriebssystem für die involvierten Stationen. Nicht selten werden Linux-basierte TSN-Netzwerke mit proprietären oder Speziallösungen entwickelt. Es stellt sich die Frage: Inwiefern lassen TSN-Netzwerke sich mit Mainline Linux realisieren? Die grundlegenden Funktionalitäten wie die Zeitsynchronisation als auch das Traffic Scheduling sind bereits heute mit einem Standard Linux Kernel möglich. Dennoch sind noch nicht alle Standards umgesetzt oder vollständig implementiert.

Heutzutage bestehen viele technische Systeme, die uns im täglichen Leben begegnen wie z.B. Autos, Flugzeuge oder industrielle Anlagen, aus vielen einzelnen Komponenten. Zur Steuerung so eines Gesamtsystems sind Aktoren und Sensoren notwendig. Diese kommunizieren in der Regel über Feldbusse miteinander.

Seit Jahren gibt es Bestrebungen, spezialisierte Feldbusse durch herkömmliches Ethernet zu ersetzen. Denn Industrial Ethernet erlaubt nicht nur Standard-Verkabelung sowie real existierende Hardware wieder zu verwenden, sondern bietet ebenfalls die notwendige Flexibilität und Interoperabilität. Da Ethernet keine Echtzeit-Funktionalitäten bietet, haben sich diverse offene oder proprietäre Protokolle wie beispielsweise EtherCAT [1], PROFINET [2] oder SERCOS [3] entwickelt.

Time-Sensitive Networking (TSN) ist eine Initiative der Time-Sensitive Networking Task Group (IEEE 802.1), um einen einheitlichen und gemeinsamen Standard zu schaffen. Dazu beschreibt TSN eine Reihe von Standards, die Ethernet offiziell um die Echtzeitfähigkeit und Determinismus erweitern.

TSN-Lösungsansätze

Mittlerweile ist Linux in Verbindung mit dem PREEMPT-RT Patch [4] oder Xenomai [5] ein sehr beliebtes und weit verbreitetes Betriebssystem für die beteiligten Geräte. Dementsprechend haben sich verschiedene Linux-TSN-Lösungen entwickelt. Einige Beispiele können Tabelle 1 entnommen werden.

All diese Varianten haben gemeinsam, dass Modifikationen am Linux Kernel vorgenommen werden müssen. Das betrifft die involvierten Netzwerktreiber, die Data und Control Plane von der Anwendung zum Kernel als auch die Konfiguration eines TSN-Netzwerks. Dies führt zu folgenden Problemen:

• Keinerlei Wiederverwendung von Standard Linux Interfaces und Werkzeugen,

• Hersteller-spezifische Applikationen werden benötigt,

• erhöhter Pflegeaufwand durch Third-Party-Komponente.n

Es stellt sich folglich die Frage, ob sich TSN-Netzwerke nicht mit Mainline Linux realisieren lassen? Diese Frage wird nachfolgend beantwortet.

TSN mit Mainline Linux

Für TSN werden exakt drei Komponenten benötigt: Zeitsynchronisation, Traffic Scheduling und Konfiguration. Eine gemeinsame Zeitbasis der Geräte und Switches legt die Grundlage für deterministisches Netzwerk Scheduling. Die Anforderungen der Anwendungen umzusetzen und alle Komponenten im Netzwerk synchron einzustellen, ist Teil der Konfiguration.

Zeitsynchronisation

Alle Endgeräte und Switches benötigen das gleiche Zeitverständnis. Die Echtzeitfähigkeit des Netzwerks wird dadurch sichergestellt, dass jeder Teilnehmer zum richtigen Zeitpunkt die richtigen Aktionen durchführt, d.h. es muss eine Synchronisierung der internen Uhren zwischen allen beteiligten Partnern erfolgen. In TSN-Netzwerken erfolgt die Synchronisierung über Ethernet selbst durch das Precision Time Protocol (PTP). Dieses Protokoll erlaubt eine Genauigkeit im Bereich von Nanosekunden.

Der Linux Kernel bietet zur Steuerung von PTP Hardware Clocks (PHC) ein eigenes Subsystem [9] an. Die Uhren werden als POSIX Clocks dargestellt. Damit können die Standard Interfaces zum Auslesen, Setzen und Regeln der Clocks verwendet werden. Das PTP-Protokoll selbst ist nicht Teil des Kernels, sondern wird im User Space implementiert. Der Linux Kernel stellt lediglich den Hardware-Zugriff auf die Clocks zur Verfügung. Der Linux PTP Stack kann der Abbildung 1 entnommen werden.

Einer der beliebtesten Linux User Space PTP Stacks ist linuxptp. Linuxptp implementiert das PTP-Protokoll nach IEEE 1588 als auch 802.1AS-2011 in der Rolle einer Endstation. In TSN-Netzwerken wird die Zeitsynchronisierung über 802.1AS erledigt. Dieser Standard ist ein Subset von 1588 und bietet Erweiterungen z.B. für die Synchronisation über WiFi. Ein weiterer Standard IEEE 802.1AS-Rev ist in der Erstellungsphase und wird dementsprechend nicht unterstützt.

Alle diese verschiedenen PTP-Profile benötigen die Information, wann ein PTP-Paket empfangen bzw. versendet wurde, d.h. es werden Zeitstempel vorausgesetzt. Je genauer die Zeitstempel sind, desto besser wird die Synchronisation. Linux bietet zur Anforderung der Zeitstempel das SO_TIMESTAMPING [10] Interface an.

Traffic Scheduling

Der Determinismus und die Echtzeitfähigkeit in TSN-Netzwerken werden über verschiedene Shaper und Scheduler sichergestellt. Die verfügbare Bandbreite wird kontrolliert und unter den Anwendungen anhand der Anforderungen aufgeteilt.

Traditionell kommunizieren Anwendungen mit Netzwerken über das Socket Interface. Der Linux-Netzwerkstack übernimmt das Paket Handling, die Protokollimplementierung wie z.B. TCP/IP, UDP/IP oder Raw Ethernet und die Hardware-Ansteuerung. Der Netzwerkstack wird anhand von Schedulern, Klassen und Filter konfiguriert. Diese Mechanismen sind seit Jahren etabliert und verstanden. Da TSN eine Erweiterung zu Ethernet darstellt, basiert die aktuelle Linux-Implementierung eben auf diesen Komponenten. Dementsprechend integriert sich TSN direkt in den Linux-Netzwerkstack. Das Prinzip kann Abbildung 2 entnommen werden.

Durch dieses Prinzip können Anwendungen mit Echtzeit-Anforderungen als auch bereits existierende Applikationen ohne besondere Ansprüche koexistieren und das gleiche Interface verwenden. Der Linux Kernel kontrolliert den Zugriff auf die Netzwerk-Hardware und stellt sicher, dass die Pakete zur richtigen Zeit versendet werden. Das ist die Time-Slot-Management-Komponente. Allerdings muss der Kernel dafür richtig konfiguriert sein. Denn die Anforderungen stammen von der Anwendung.

Die Konfiguration des Netzwerk-Stacks erfolgt anhand von Queuing Disciplines (Qdiscs). Eine Qdisc entspricht einem Paket Scheduler. Dieser entscheidet, wann ein Paket an die Netzwerk-Hardware bzw. die Anwendung gegeben wird. Im Rahmen der TSN-Umsetzung wurden in den letzten Jahren verschiedene Qdiscs entwickelt und in den Mainline Linux Kernel integriert.

Applikationen zur Steuerung von Industrieanlagen müssen in der Regel Pakete zyklisch und mit möglichst wenig Jitter versenden. Moderne Netzwerkkarten bieten dazu die Möglichkeit, Frames zu einem bestimmten Zeitpunkt in Hardware loszuschicken. Exakt für dieses Szenario wurde eine Qdisc namens Earliest Tx Time [12] entwickelt. Die Konfiguration erfolgt über das Traffic Control Subsystem und dessen zugehöriges User Space Werkzeug tc. Ein Beispiel kann Abbildung 3 entnommen werden.

Dieser tc Aufruf ersetzt die aktuelle Qdisc des Interfaces eth0 durch ETF. Die Zeitstempel werden in Referenz auf die TAI Clock angeben. Die Anwendung kann über eine Socket Option im User Space (SO_TXTIME) einen Zeitstempel für jeden Frame angeben. Der offload Parameter gibt an, dass Hardware Offloading der Netzwerkkarte verwendet werden soll. Ansonsten wird auf eine Software-Implementierung zurückgegriffen.

Ebenso wichtig wie den Jitter zu minimieren, ist das Traffic Shaping. Die TSN-Standards definieren mehrere verschiedene Mechanismen. Verbreitet insbesondere im Audio- und Video- Streaming-Umfeld, ist die Limitierung von Traffic auf eine fixe Bandbreite. Zu diesem Zweck enthält der Linux Kernel seit Version 4.15 den Credit Based Shaper [13], ebenfalls implementiert als Qdisc. Eine Beispielkonfiguration ist in Abbildung 4 zu finden. Die Konfigurationsparameter entstammen dem 802.Qav Standard.

Allerdings wird die Echtzeitfähigkeit nicht nur durch die Begrenzung der Bandbreite, sondern durch das Time Slot Management sichergestellt. Der TSN-Standard 802.Qbv definiert für diesen Zweck den Time Aware Shaper. Der Linux Kernel enthält bereits eine Umsetzung dessen, die sogenannte TAPRIO [14] Qdisc. Dieser Scheduler erlaubt die Unterteilung der Bandbreite in sich zyklische wiederholende Time Slots. Der Ethernet Traffic wird in verschiedene Klassen aufgeteilt und diesen werden Slots zugewiesen. Ein Beispielzyklus kann Abbildung 5 entnommen werden.

Dieser Zyklus beinhaltet drei Time Slots für drei verschiedene Traffic-Klassen z.B. für Automation, Streaming und General-Purpose-Anwendungen. Jede Traffic-Klasse hat einen Slot von jeweils 100 bzw. 200 µs. Nach 400 µs wiederholt sich der Zyklus und der nächste beginnt. Dieser Beispielzyklus kann für ein Netzwerk-Interface wie in Abbildung 6 gezeigt konfiguriert werden:

In dieser Konfiguration wird zunächst die Anzahl an Traffic-Klassen bestimmt. Die Zuordnung von Paketen im User Space zu diesen Traffic-Klassen erfolgt über die 16 Socket Prioritäten. Der map Parameter erledigt dies. TSN-fähige Hardware hat in der Regel mehrere Tx Queues. Die Traffic-Klassen werden anhand des queues Parameter den Queues zugewiesen. Der eigentliche Zyklus und der Startzeitpunkt werden anschließend angelegt. Über die flags lassen sich Konfigurationen wie z.B. Hardware Offloading vornehmen.

Konfiguration

Die Zeitsynchronisation sowie das Traffic Scheduling bilden die Grundlage für TSN-Netzwerke. Doch wie werden die Zeitpläne und einzelnen Parameter berechnet und schlussendlich auf die Endstationen und Switches verteilt? Die Anforderungen stammen von den Anwendungen. Der 802.1Qcc Standard definiert das Management und die Protokolle zur TSN-Konfiguration. Es gibt zum einen den Central Network Controller (CNC), welcher die Kommunikationspfade bzw. Zyklen bestimmt und die Switches konfiguriert, zum anderen den Centralized User Configuration (CUC), welcher die Anforderungen der Anwendungen entgegennimmt und an den CNC weiterreicht. Der Aufbau ist in Abbildung 7 zu sehen.

Neben dem zentralisierten Modell, sind weitere Ansätze wie z.B. dezentral oder Mischformen vorstellbar. Die eingesetzten Protokolle zur Konfiguration sind NETCONF bzw. RESTCONF. Die Konfiguration ist für ein Linux-System ein orthogonales Problem. Die CUC und CNC sowie die notwendigen Programme auf den Endstationen bzw. Switches ist aus Sicht des Linux Kernels lediglich Software. Die PTP als auch Traffic-Konfiguration erfolgt über die bereits vorgestellten Mechanismen.

Fazit

Die grundlegenden Funktionen wie die Zeitsynchronisation und das Traffic Scheduling sind bereits heute mit einem Standard-Linux-System möglich. Die Basis-Infrastruktur wurde entsprechend im Linux Kernel geschaffen. D.h. Basis-TSN-Netzwerke lassen sich mit Linux realisieren. Dennoch werden bei weitem noch nicht alle TSN-Standards unterstützt. Tabelle 2 zeigt den aktuellen Stand auf und ob der Standard überhaupt für Linux relevant ist.

Letztendlich gibt es kein fundamentales Problem, was es unmöglich machen würde, diese Standards und die notwendigen Linux-Erweiterungen zu implementieren. Dementsprechend wird die Unterstützung stetig besser werden.

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

Architektur-Plan zur Integration von TSN und DDS in industrielle Systeme

Literatur- und Quellenverzeichnis

[1] „Beckhoff EtherCAT-Komponenten: Schnell, flexibel, präzise, kostenoptimiert,“ [Online]. Available: www.beckhoff.de/EtherCAT. [Zugriff am 07 09 2019].

[2] „PROFINET - the leading Industrial Ethernet Standard,“ [Online]. Available: https://www.profibus.com/technology/profinet/. [Zugriff am 07 09 2019].

[3] „SERCOS, The Automation Bus,“ [Online]. Available: https://www.sercos.de/. [Zugriff am 07 09 2019].

[4] „PREEMPT_RT Wiki,“ [Online]. Available: https://wiki.linuxfoundation.org/realtime/start. [Zugriff am 07 09 2019].

[5] „Xenomai,“ [Online]. Available: https://xenomai.org/. [Zugriff am 07 09 2019].

[6] „TSN (Time Sensitive Networking) Software Stack,“ [Online]. Available: https://www.acontis.com/en/tsn.html. [Zugriff am 07 09 2019].

[7] „Open Industrial Linux,“ [Online]. Available: https://www.openil.org/. [Zugriff am 07 09 2019].

[8] „OpenAvnu,“ [Online]. Available: https://github.com/AVnu/OpenAvnu. [Zugriff am 07 09 2019].

[9] R. Cochran, „PTP (Precision Time Protocol) Documentation,“ [Online]. Available: https://www.kernel.org/doc/Documentation/ptp/ptp.txt. [Zugriff am 07 09 2019].

[10] P. Ohly, „The Linux Kernel Archives,“ [Online]. Available: https://www.kernel.org/doc/Documentation/networking/timestamping.txt. [Zugriff am 06 09 2019].

[11] T. Gleixner, „Evolution and current status of TSN in Linux,“ in TSN/A Konferenz, Stuttgart, 2018.

[12] J. Sanchez-Palencia, „ETF (Earliest TxTime First) Documentation,“ [Online]. Available: http://man7.org/linux/man-pages/man8/tc-etf.8.html. [Zugriff am 06 09 2019].

[13] V. C. Gomes, „CBS (Credit Based Shaper) Dokumentation,“ [Online]. Available: http://man7.org/linux/man-pages/man8/tc-cbs.8.html. [Zugriff am 07 09 2019].

[14] V. C. Gomes, „TAPRIO (Time Aware Priority Shaper) Dokumentation,“ [Online]. Available: http://man7.org/linux/man-pages/man8/tc-taprio.8.html. [Zugriff am 07 09 2019].

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2019 entnommen.)

* Kurt Kanzenbach, M.Sc. (FAU) ist Embedded Linux Ingenieur bei der Linutronix GmbH. Er studierte Informatik an der Friedrich-Alexander-Universität Erlangen-Nürnberg. In seiner täglichen Arbeit ist er verantwortlich für Linux-basierte Board Support Packages und hält Trainings sowie Workshops in dem Bereich Echtzeit Linux. Außerdem ist er von technischer Seite in dem AccessTSN Projekt involviert.

(ID:46849202)