Zeitsynchronisation ist eine grundlegende Voraussetzung für TSN-basierte Netzwerke. Einerseits wird eine synchronisierte Zeit für viele TSN-Mechanismen wie das Schedule-basierte Senden von Daten nach 802.1Qbv benötigt. Auf der anderen Seite ist die Zeit auch für die mittels TSN realisierten verteilten Applikationen nötig. Dies kann im einfachsten Fall das Generieren eines Zeitstempels für Messdaten sein oder aber auch die hochgenaue Synchronisation einer physikalischen Applikation, beispielsweise die von mehreren Maschinenachsen.

So unterschiedlich die Applikationen sind, so unterschiedlich sind auch deren Anforderungen an die Genauigkeit der Synchronisation: Für einen Sensor zur Prozessüberwachung kann es durchaus ausreichend sein, sicherzustellen, dass dieser in der ersten Millisekunde eines 10-ms-Zyklus sendet.
Bei hochdynamischen Achsen einer Präzisionsmaschine ist eine Synchronisation im unteren Nanosekundenbereich erforderlich. 

In TSN-Netzwerken wird hierzu das Precision Time Protocol (PTP) verwendet, welches in IEEE 1588 und dem darauf ­aufbauenden IEEE-802.1AS-Standard de­finiert ist. PTP ermöglicht eine Syn­chronisation aller Knoten im Netzwerk 
mit einer Genauigkeit von unter 1 μs. 
Typischerweise ist die Synchronisationsgenauigkeit jedoch deutlich besser, meist sogar unter 50 ns. 

PTP Basics

Bild 1. Die Synchronisations-Hierarchie eines TSN-Netzes.

© NetTimeLogic

PTP baut einen Synchronisationsbaum mittels des Austausches von ‚Announce‘ Frames – die Information über Qualitäten und Prioritäten des jeweiligen Knotens – und dem Best-Master-Clock Algorithmus auf.
Schlussendlich ergibt sich daraus eine Synchronisationshierarchie (Bild 1) bei der sich an oberster Stelle die Zeitquelle – PTP Grandmaster (GM) genannt – und an unterster Stelle des jeweiligen Zweigs die Zeitsenken – PTP Slaves (OC) genannt – befinden. Die Knoten dazwischen sind PTP-fähige Switches (PTP Boundary Clocks), welche an einem Port jeweils die Rolle einer Zeitsenke (PTP Slave) und auf den anderen Ports jeweils wieder die Rolle einer Zeitquelle (PTP Master) übernehmen. Hierdurch ist jede PTP-Verbindung eine Punkt-zu-Punkt-Verbindung, entsprechend dem 802.1AS-Standard.

Jede PTP-Verbindung synchronisiert die beiden Endpunkte, den Slave und den Master nach demselben Prinzip. Dabei werden sowohl die Phase zwischen den zwei Teilnehmern als auch die Drift aufgrund abweichender Frequenzen der Uhren bestimmt und kompensiert.

Um die Phase ausgleichen zu können, muss sowohl der Unterschied der lokalen Uhren als auch die Latenz der Kabelverbindung bekannt sein. Hierzu wird zuerst die Latenz (Delay) zwischen zwei PTP-Knoten bestimmt, wofür ein Mechanismus auf Basis sogenannter ‚Peer Delay Messages‘ (P2P) zum Einsatz kommt.
Mit dem Wissen über die Latenz kann nun der eigentliche Phasenfehler (Offset) mittels zeitgestempelter Nachrichten bestimmt werden. Durch aufeinanderfolgende Messung erfolgt noch die Bestimmung des Frequenzfehlers – der Drift. Wie im einzelnen Parameter – Delay, Phasenfehler und Drift – bestimmt werden, ist im Standard definiert. 
Wie die gemessenen Phasen und Frequenzfehler ausgeglichen werden, ist nicht im Standard definiert und implementierungsspezifisch. Dies kann sprunghaft oder durch ausgereifte Regelungsalgorithmen erfolgen.

Die Qualität der Synchronisation

Bild 2. Zeitstempel-Ungenauigkeit auf verschiedenen Ebenen des Netzwerk-Stacks.

© NetTimeLogic

Die erreichbare Genauigkeit hängt stark von der Stabilität der Zeitquelle, der Topologie und der daraus folgenden Anzahl an Hierarchien im PTP-Synchronisationsbaum ab. Dazu kommt ebenfalls der zu erwartende systembedingte Fehler pro Knoten in der Hierarchie (Zeitstempel-Granularität, Aufenthaltsdauer, Oszillator-Stabilität). Und schlussendlich hängt die Genauigkeit natürlich von der Implementation des zu synchronisierenden Endknotens ab (Zeitstempel-Granularität, Filter- und Regel-Parameter, Oszillator-Stabilität). 

Aus der Synchronisationshierarchie in Bild 1 ist ersichtlich, dass mit zunehmender Zahl an Ebenen (Hops) zwischen der Zeitquelle und Zeitsenke die erreichbare Genauigkeit abnimmt. Dies ist hauptsächlich der Zeitstempel-Genauigkeit in den einzelnen Hops und den darauf basierenden Berechnungen sowie der Stabilität der Oszillatoren geschuldet. Grundsätzlich legt PTP nicht fest, wie ein Zeitstempel eines Pakets genommen wird, jedoch legt es fest, wann ein Zeitstempel genommen wird. Dies ist genau dann, wenn der Start-of-Frame-Delimiter (SFD) das Kabel am jeweiligen Knoten verlässt beziehungsweise erreicht. Wie es nun zu den entsprechenden Zeitstempeln kommt, ist implementationsabhängig. Zudem gibt es verschiedene Ebenen, wo Zeitstempel genommen werden können (siehe Bild 2 oben). In den unteren Ebenen erfolgt die Zeitstempelung dabei in Hardware, in den oberen in Software.

Vereinfacht gesagt gilt, je höher die Schicht im OSI Model, desto fehlerbehafteter ist der Zeitstempel. Um eine Synchronisationsgenauigkeit <1 μs zu erreichen, ist eine Hardware-Unterstützung notwendig. Dies gilt auch, weil der Zeitstempel nur einer von drei entscheidenden Teilen ist, welcher für hochgenaue Synchronisation und deren Nutzen nötig ist. Die Zeitstempel basieren schlussendlich auf einer Zeit, welche entsprechend in Phase und Frequenz angepasst werden muss, was den zweiten entscheidenden Teil darstellt: eine anpassbare Uhr.

Je genauer die Uhr geregelt werden kann, desto genauer sind schlussendlich die Zeitstempel und dementsprechend auch wieder die Berechnungen der neuen Regelparameter. Die Genauigkeit der Regelung hängt in dem Zusammenhang aber auch sehr stark von der Oszillator-Stabilität der Taktquelle für die Uhr ab. Es bringt also nichts, wenn die Frequenz der Uhr mit einer Auflösung von etwa 1 ppb (1 ns/s) geregelt wird, die Taktquelle aber einen Jitter von 10 ppm hat (10 μs/s) hat.

Glücklicherweise sind auch viele low-cost Kristall-Oszillatoren mit 50 ppm – bei konstanter Temperatur, Vibration – sehr frequenzstabil (<10 ppb). Der absolute Frequenzfehler ist hier irrelevant, da dieser einfach weggeregelt werden kann. Es geht hier also rein um die Frequenzstabilität. Um mit weniger stabilen Oszillatoren eine passable Genauigkeit zu erreichen, kann die Frame-Rate erhöht werden. Dies führt dazu, dass ein Knoten öfters nachregeln kann und entsprechend weniger weit wegdriftet als bei niedrigeren Raten, dies jedoch auf Kosten der Netzwerklast. Das dritte und letzte entscheidende Puzzleteil ist die Möglichkeit, die hochgenaue Uhr nutzen zu können. Dabei geht es entweder darum, zeitgesteuert Events auszulösen (Phasen und Zyklen in TSN, synchrones Sampling von ADCs, synchrone Ansteuerung von Motoren oder OPC-UA Frame Trigger) oder Events mit der hochgenauen Uhr mit einem Zeitstempel zu versehen (etwa asynchrone Events für zentrale Korrelation). Auch hier gilt wie bei den Zeitstempeln, je mehr Hardware- Unterstützung desto präziser.

Die Optionen der Implementierung

Bild 3. Die Blockdiagramme einer HW-SW-Co-Lösung und einer FPGA-Lösung.

© NetTimeLogic

Grundsätzlich ist eine Implementierung als reine Software-, kombinierte Hardware-Software- oder reine Hardware-Lösung möglich. Für Endpunkte, welche in einem TSN-Netzwerk nur zeitunkritische Aufgaben erfüllen, zum Beispiel eine Visualisierung oder Monitoring-Applikation, kann eine reine Software-Lösung ausreichend sein.
Für TSN-Netzwerke mit der Anforderung einer Synchronisationsgenauigkeit <1 μs und somit der Netzwerk-Infrastruktur sowie den betroffenen Endpunkten, gibt es de facto nur zwei mögliche Ansätze (Bild 3): Software mit Hardware (SW-HW- Co-Lösung) oder eine reine Hardware-Lösung (FPGA-Lösung).

Die SW-HW-Co-Lösung

Bei einer SW-HW-Co-Lösung ist es normalerweise so gelöst, dass alles Zeitkritische in Hardware gelöst ist und alles Zeitunkritische in Software. Ein weit verbreitetes Beispiel dafür ist die PTP-Lösung mit ptp4l. ptp4l ist eine Open-Source-Protokoll-Stack-Implementation für Linux nach IEEE 1588/IEEE 802.1AS. ptp4l handhabt hierbei alles, was mit dem PTP Frame Versand/Empfang zu tun hat, die Protokoll-Algorithmen, einschließlich der Auswertung der Zeitstempel und Berechnung der Regelparameter für die Uhr. Die eigentlichen Zeitstempel kommen dabei aber von einer dedizierten Hardware – zum Beispiel Netzwerk-Karten – welche über das Socket API die Zeitstempel zur Verfügung stellt. Meistens befindet sich auf derselben dedizierten Hardware auch eine regelbare Uhr – die Zeitstempel kommen ja von einer Uhr –, welche über das PHC API von ptp4l angesprochen wird. Somit wäre die Problematik der Zeitstempel und regelbaren Uhr gelöst.

Der Punkt ist nun jener, dass die hochgenaue Zeit jetzt auf der Netzwerk-Karte zur Verfügung steht, dort ist sie aber bis auf PTP eigentlich nutzlos, außer den hardwarespezifischen Features, welche herstellerspezifisch sind. Hierfür braucht es nun noch ptp4l-spezifische Tools (phc2sys), um etwa die System Clock der PTP-Uhr (PHC Clock) nachzuführen und darauf entsprechend synchrone Events zu generieren oder Zeitstempel zu nehmen. Dabei ergeben sich zwei zusätzliche Quellen für Ungenauigkeit, einerseits beim Aufsynchronisieren des System Clocks und anderseits bei der Event-Generierung und Zeit-Stemplung, was sehr CPU-Last-abhängig sein kann. Um eine hohe Präzision zu erzielen, ist hier eigentlich ein Echtzeit-OS erforderlich. Neben ptp4l gibt es weitere kommerzielle PTP-Stacks, welche beispielsweise auch Nicht-Linux-Systeme unterstützen und dann auch auf MCUs zum Einsatz kommen können.