Der IEEE 1588 Standard

 

Autoren: Peter Plazotta und Dominik Richstein, TSEP

Zeitsynchronisation zwischen mehreren Rechnern im Netzwerk war schon immer eine Herausforderung. Was sich im ersten Schritt als eine triviale Anforderung darstellt, zwei oder mehrere Rechner mit der identischen Zeit auszustatten, ist bei genauerer Betrachtung ein durchaus komplexes Problem. Die Problemstellung kann wie folgt definiert werden:

Verteilung der Zeit einer sehr genauen Zeitquelle (Atomuhr, GPS) an einem oder mehreren Rechner im Netzwerk. Zur Verteilung der Zeit steht nur die vorhandene Netzwerkinfrastruktur zur Verf√ľgung.

Um dieses Problem zu l√∂sen wurde bereits 1985 von David L. Mills an der Universit√§t von Delaware das NTP Protokoll entwickelt und als RFC 958 ver√∂ffentlicht. Mit diesem Protokoll war es nun m√∂glich mehrere Rechner an die Zeit eines Zeitservers anzugleichen. Die Genauigkeit die hierbei erreicht wird liegt im Mikrosekunde Bereich (1x10-6 sec.) und war zur damaligen Zeit ausreichend. 

Bereits 1990 wurde im T&M Bereich die Notwendigkeit erkannt √ľber deutlich genauere Systeme zu verf√ľgen. Zu dieser Zeit waren zwar bereits auch GPS System verf√ľgbar, die eine deutlich bessere Genauigkeit bereitstellen konnten, jedoch war diese Alternative preislich nicht attraktiv. Zus√§tzlich sollte die Anforderungen an eine verbesserte Genauigkeit mit der vorhandenen Infrastruktur erreicht werden. So wurde Anfang der 90ziger Jahren bei Hewlett-Packard eine Arbeitsgruppe um John C. Eidson gegr√ľndet, die ein Konzept zur Verbesserung des NTP Standards ausarbeiten sollte. Die im Jahr 2000 von John C. Eidson ver√∂ffentlichten Ergebnisse waren f√ľr die T&M Firmen so interessant, das man einen eigenen IEEE Standard f√ľr diese neue Art von Zeitsynchronisation ins Leben rufen wollte. 2002 war es dann soweit, die IEEE 1588-2002 war fertiggestellt und freigegeben. Mit Hilfe dieses Standards sollten nun Genauigkeiten im Sub-Mikrosekunden Bereich m√∂glich werden. 2008 wurde dann der Standard nochmals an die aktuellen Anforderungen angepasst und als IEEE 1588- 2008 festgeschrieben. Dieser Standard ist bis heute g√ľltig. Zur Zeit arbeitet die IEEE Working Group um John C. Eidson und Doug Arnold, der nun als Co-Chairmen fungiert, an einer neueren Version des Standards um die erweiterten Anforderungen an den Standard Rechnung tragen zu k√∂nnen. Folgende neue Anforderungen wurden f√ľr den neuen Standard identifiziert: 

  • Verbesserung der Zeitsynchronisation Genauigkeit
  • Anwendbarkeit auf lokalisierte Systeme mit der M√∂glichkeit der Verwendung in gr√∂√üeren Systemen
  • Administrationsfreien Betrieb
  • Eignung in High-End Ger√§ten sowie in Low-End Ger√§ten
  • Management-Steuerung f√ľr redundante und fehlertolerante Systeme

Doch nicht nur in der IEEE Working Group wurde an der Verbesserung des Standards gearbeitet. Ein Zusammenschluss verschiedener Institutionen und Unternehmen, darunter die CERN-Forschungsorganisation, das GSI Helmholtz-Zentrum f√ľr Schwerionen Forschung und die Firma National Instruments, haben den Standard f√ľr ihre Anforderungen weiterentwickelt und unter dem Projektnamen "White Rabbit" [3] ver√∂ffentlicht. Die Ziele des White Rabbit-Projektes waren [4]: 

  • Genauigkeit der Zeitsynchronisation im Sub-Nanosekundenbereich
  • Tausende von Knoten innerhalb der PTP Dom√§ne
  • m√∂gliche Knotenabst√§nde von mehr als 10 km
  • Ethernet-basierte Gigabit-Netzwerk mit zuverl√§ssige Daten√ľbertragung
  • Open-Source-Hardware, Firmware und Software
  • Handels√ľbliche Hardware verschiedener Hersteller

Die aktuelle Version 2.0 des White Rabbit Standards wurde 2011 unter der "CERN Open Hardware License" ver√∂ffentlicht. Derzeit wird dieser Standard bereits in verschiedenen Projekten eingesetzt. CERN verwendet den Standard f√ľr ein Steuerungssystem des "Large Hadron Collider" und f√ľr sein Neutrino - Teleskop KM3Net im Mittelmeer und das "GSI Helmholtzzentrum f√ľr Schwerionenforschung" nutzt es f√ľr den Partikel Beschleuniger FAIR. 

Um den IEEE 1588 Standard besser verstehen zu k√∂nnen, sollte man sich nochmal die Probleme vor Augen f√ľhren, wieso eine derartig genaue Zeitsynchronisation so komplex sein kann. Im Grunde bestehen mehrere Probleme: 

  1. Jede Uhr innerhalb eines Computers ist als Z√§hler implementiert. Es werden die Takte einer Taktquelle gez√§hlt und √ľber die Frequenz der Taktquelle die Uhrzeit errechnet. Da Taktquellen nie einen konstanten Takt erzeugen k√∂nnen, k√∂nnen auch zwei parallel laufende Taktquellen nie den identischen Takt haben. Somit ist eine Anpassung der Taktfrequenz des Slaves zum Master notwendig.
  2. Das im Regelfall verwendete Ethernet entspricht weitestgehend der IEEE 802.3. Ethernet kann leider keine zeitlich deterministische Verbindung zwischen zwei Rechnern bereitstellen. Die Laufzeiten k√∂nnen von Sendung zu Sendung variieren. Somit k√∂nnen auch die Laufzeiten der Synchronisationsdaten variieren, was zu Fehlern bei der Synchronisation f√ľhren kann.
  3. Die Laufzeiten innerhalb der Rechner, also in den Treibern und dem Network- Stacks der Betriebssysteme, sind ebenfalls nicht deterministisch. Moderne Betriebssysteme arbeiten mit ‚Äěpreemtive scheduling‚Äú, was hei√üt, dass jeder Prozess innerhalb des Betriebssystems unterbrochen werden kann und zu einer anderen Zeit fortgesetzt wird. Somit k√∂nnen Verarbeitungszeiten innerhalb des Betriebssystems nicht mehr deterministisch vorhergesagt werden. Diese Unsch√§rfe f√ľhrt wiederum zu Fehlern in der Zeitsynchronisation und muss ber√ľcksichtigt werden.
  4. Als √úbertragungsmedien muss ein Consumer Produkt (Netzwerkkarte, Netzwerk-Chip) verwendet werden. Es m√ľssen die bestehenden Infrastrukturen (Netzwerke) verwendet werden. Es darf also keine eigenst√§ndige Hardware f√ľr die Zeitsynchronisation verwendet werden

Der IEEE-1588-2008 Standard enth√§lt verschiedene Aspekte der Synchronisation und ihrer Umgebung. Zuerst werden die Ger√§te in den Netzwerken betrachten (PTPDom√§nen) und deren Anordnung. Jedes der Ger√§te oder Knoten in einer PTPDom√§ne die eine PTP Funktionalit√§t enthalten, werden als ‚ÄěClocks‚Äú bezeichnet und k√∂nnen in vier verschiedenen Varianten auftreten.

Bild 1: Schematischer Aufbau eines PTP Netzwerkes [2]

Ordinary Clock:

Eine ‚ÄěOrdinary Clock‚Äú ist eine einfache Uhr (ein Port, meist ein Client) der als Slave mit einem Master verbunden ist und ihre Zeit an dessen angleicht.

Boundary Clock:

Eine "Boundary Clock" ist eine Uhr die mehrere "Ordinary Clocks" enthält (mehrere Ports) und die als Master mehrere Slaves mit ihrer Zeit synchronisieren kann. Die "Boundary Clock" kann aber auch als Slave mit einem Master verbunden sein und ihre Zeit an dessen angleichen.

Transparent Clock:

Eine "Transparent Clock" ist eine Uhr die nicht aktiv in die Zeitsynchronisation eingreift, sie ist mehr eine Hardware die die Zeitsynchronisation-Datenpakete vermittelt, typischerweise ein Netzwerk Switch. "Transparent Clocks" korrigieren die Zeitstempel innerhalb der Datenpackte um die Verweildauer innerhalb der Hardware.

Grandmaster Clock:

Die Grandmaster Clock ist eine ‚ÄěOrdinary Clock‚Äú, die normalerweise Zugang zu GPS oder einer anderen sehr genauen Zeit hat und diese sehr genaue Zeit f√ľr alle untergeordneten Knoten bereitstellt. 

Innerhalb des PTP Netzwerkes kann jede Clock (Port) entweder als Master oder Slave agieren. Innerhalb einer PTP Dom√§ne kann es aber immer nur einen Master geben. Der Master verteilt aktiv seine Zeit an die Slaves. Er ist somit f√ľr die Synchronisation der Slaves in seiner PTP Dom√§ne zust√§ndig. Ein Slave ist ein passives Element innerhalb von PTP der auf die Zeitsynchronisation-Anfragen des Masters antwortet. Grunds√§tzlich kann jede Clock (Port) innerhalb von PTP als Master oder Slave arbeiten. Die Entscheidung ob die Clock als Master oder Slave arbeiten muss wird beim Betreten des PTP Netzwerks ermittelt. Hierzu wurde der ‚ÄěBest Master Clock‚Äú- Algorithmus in IEEE 1588 Standard definiert. Dieser Algorithmus regelt, dass die Clock mit der besten Genauigkeit, die Rolle des Masters √ľbernimmt. 

Die Synchronisation der Uhrzeit zwischen Master und Slave wird √ľber sogenannte "Event Messages" durchgef√ľhrt. Diese Messages werden √ľber das UDP Netzwerkprotokoll im Netzwerk vom Master verteilt und von Slaves beantwortet. Es existieren zwei verschiedene Verfahren f√ľr die Synchronisierung, die ‚ÄěOne-Step ‚ÄěSynchronisierung und die "Two-Step" Methode. Der Unterschied in den beiden Methoden liegt in der Anzahl der Nachrichten welche ausgetauscht werden m√ľssen und ist im kommenden Diagramm zu sehen. Die "Two-Step" Methode verschickt vier Nachrichten um einen Synchronisationsschritt durchzuf√ľhren. Dahingegen braucht die "One-Step" Methode nur drei Nachrichten, was aber nur mit √§u√üerst guter Hardware-Unterst√ľtzung m√∂glich ist und somit nicht in jeder PTP Dom√§ne gegeben sein kann. 

Damit ein Slave die Synchronisierung durchf√ľhren kann, sind lediglich vier Zeitstempel (t1, t2, t3, t4) n√∂tig. Die Zeitstempel werden jeweils beim Senden oder Empfangen bestimmter Nachrichten generiert. Der Slave erh√§lt diese vier Zeitstempel durch den Austausch der folgenden "Messages": 

  • Sync Message, der Master erm√∂glicht damit den Slaves, eine Synchronisierung zu beginnen; In der eben genannten ‚ÄěOne-Step‚Äú Methode, ist in dieser Nachricht der Zeitstempel t1 enthalten
  • Follow_Up Message, diese Message ist analog zur Sync Message zu sehen, wobei damit nun der Zeitstempel t1 verschickt wird, falls die ‚ÄěTwo-Step‚Äú Methoden angewendet wird
  • Delay_Req Message, der Slave antwortet hiermit auf eine Sync oder Follow_Up Nachricht und erfr√§gt damit den Master um einen weiteren Timestamp
  • Delay_Resp Message, der Master schickt mit dieser Message den letzten Zeitstempel t4 an den Slave zur√ľck

Das nachfolgende Diagramm zeigt den genauen Ablauf der PTP Kommunikation und den damit verbunden Austausch der benötigten Zeitstempel. Die Erfassung der Zeitstempel t1 und t4 geschieht auf der Seite des Masters und wird mit den Nachrichten an die Slaves gesendet. Damit dieser Knoten zum Schluss seine vier Zeitstempel besitzt, werden t2 und t3 Slave-seitig bei Empfang der Master Nachrichten erstellt.

Bild 2: Schematischer Ablauf der Messages[1]

Mit Hilfe der Zeiten t1, t2, t3, und t4 kann nach dem Austausch der Nachrichten der ‚ÄěmeanPathDelay‚Äú berechnet werden. Der ‚ÄěmeanPathDelay‚Äú gibt an, wie lange eine Message f√ľr die √úbertragung im Netzwerk gebraucht hat, also die Verz√∂gerung. Wie an der untenstehenden Formel zu sehen ist, geht IEEE 1588 davon aus das die Latenzzeit im Netzwerk f√ľr Senden und Empfanden identisch ist.

Bild 3: Formel zu Berechnung des meanPathDelay [2]

Somit dient der ‚ÄěmeanPathDelay‚Äú zur Laufzeitkorrektur (im Netzwerk) f√ľr die Berechnung des eigenen Zeit-Offsets.

Wenn man das obige Diagramm betrachtet kann man zum Schluss kommen, das der berechnete ‚ÄěmeanPathDelay‚Äú umso genauer ist, je n√§her der Zeitstempel tn an der Hardwareschnittstelle gesetzt oder ermittelt wird. Diese Beobachtung f√ľhrt dann sehr schnell zur Erkenntnis, dass ein Teil der IEEE 1588 Funktionalit√§t optimaler Weise in den entsprechenden Netzwerkchips untergebracht werden sollte. 2012 hat Intel dann ihre Netzwerkchips der Intel Reihe I21x vorgestellt die erstmals eine Unterst√ľtzung f√ľr IEEE 1588 enthielten. Mit der Vorstellung dieser Netzwerkchips war nun auch der Zeitpunkt gekommen um √ľber kommerzielle L√∂sungen im T&M Bereich nachzudenken. Intel hatte mit diesem Consumer Chipsatz erstmals die M√∂glichkeit geschaffen f√ľr eine breite Palette an Ger√§ten die Verwendung von IEEE 1588 zu erm√∂glichen. Diese Netzwerkchips enthalten alle zeitkritischen Teile des IEEE 1588 Standards: 

  • Hardware Clock: Einen internen Z√§hler und die dazu notwendigen Stellglieder f√ľr die Anpassungen des Z√§hlers (Frequenzanpassung)
  • Hardware Timestamping: Das Timestamping der zusendenden UDP PTP Datenpakete 
  • Hardware Timestamping Grabber: Das Erfassen der Timestamps beim Empfangen von UDP PTP Datenpakete
  • Hardware Based Time Events: Das Erzeugen von zeitgesteuerten Trigger

Unter Linux existieren bereits einige Implementierungen von unterschiedlicher Qualit√§t. F√ľr das Betriebssystem Windows existieren jedoch keinerlei Treiber von Microsoft oder Intel um diese Funktionalit√§t der Intel I21x Netzwerkchips zu unterst√ľtzen. Zwar sind einige k√§ufliche Implementierungen erh√§ltlich, die preislich jedoch nur eingeschr√§nkt attraktiv sind.

Mit Hilfe der Intel I21x Netzwerkchips lassen sich mit geringem Aufwand schon hervorragende Zeitsynchronisationen in zweistelligen Nanosekunden Bereich erreichen, die auch langzeitstabil gehalten werden können.

Bild 4: Messung des Slave Offsets √ľber 100 Sekunden [2]

Wie das Diagramm oben zeigt schwankt der Offset zwischen Master und Slave immer um den Nullpunkt. Aufgrund des berechneten Offsets muss die aktuelle Uhrzeit des Slaves angepasst werden. Wie leicht einzusehen ist, kann nicht einfach die Uhrzeit korrigiert werden, also der ermittelte Offset direkt angewandt werden, da die Zeit dann in die Vergangenheit oder Zukunft springen w√ľrde. Ein sinnvolleres Vorgehen ist hier, den Takt des Z√§hlers im Slave zu manipulieren. Die Intel I21x Chips haben hierzu ein spezielles Register mit dem die Frequenz des Z√§hlers indirekt angepasst werden kann. Der Intel I21x Chip aktualisiert alle 8 ns seine lokale Uhr um 8ns, zus√§tzlich kann ein Offset von n x 2-31ns definiert werden, die bei jedem dieser Updates hinzuaddiert werde. Dieser Offset ist vorzeichenbehaftet und kann somit zu Verkleinerung oder Vergr√∂√üerung der Z√§hlerfrequenz verwendet werden. Aufgrund des Offsets zum Master kann nun der entsprechende Fehler in der Frequenz und die somit notwendige Frequenzanpassung ermittelt werden. Der zugrundeliegende Algorithmus der Frequenzanpassung ist ma√ügeblich f√ľr die Stabilit√§t der Uhr verantwortlich.

Innerhalb des Netzwerkes kann es auch zu St√∂rungen kommen die letztlich die Stabilit√§t der Clock beeinflussen. Das unten aufgef√ľhrte Diagramm zeigt St√∂rungen die von Netzwerkkollisionen und die sich dadurch ergebenden √úbertragungswiederholungen im Ethernet entstanden sind.

Bild 5: Messung des Slave Offsets √ľber 100 Sekunden [2]

Um derartige Störgrößen erkennen und bewerten zu können, kann zum Beispiel ein Kalman-Filter eingesetzt werden.

Im T&M Bereich werden heute noch viele Messaufgaben mit Hilfe des klassischen Vorgehens gel√∂st. Mit Hilfe der genauen Zeitsynchronisation √ľber IEEE 1588 ergeben sich nun aber viele neue und interessante L√∂sungsans√§tze.

Wenn man sich vor Augen hält, dass ein Triggersignal ca. 5ns Laufzeit pro Meter benötigt, kann man sich sicherlich einige Messaufgaben vorstellen die mit Hilfe der IEEE 1588 Zeitsynchronisation besser und genauer gelöst werden können. Bei Messaufgaben die beispielsweise mit Satellitensignalen zu tun haben, kann es durchaus vorkommen dass Messgeräte 100 und mehr Meter voneinander entfernt sind, hier wäre der Ansatz mit IEEE 1588 sicherlich eine Alternative.

Auch im Zuge der zunehmenden Verbreitung der IoT Sensoren und der Offline Messdatenaufnahme, w√§re eine genaue und stabile Zeitsynchronisation der einzelnen Messsensoren von gro√üem Vorteil. Somit k√∂nnen die einzelnen IoT Sensoren kontinuierlich ihre Daten liefern und zum Beispiel in einer Cloud ablegen. Diese Daten k√∂nnen dann bei einer Offline Messdatenauswertung √ľber den Zeitstempel, der bei der Messungen erstellt worden ist, einfach korreliert werden.

Da IEEE 1588 auch zeitgesteuerte Events definiert, k√∂nnen zum Beispiel mehrere Ger√§te miteinander Sequenzen von Messaufgaben abarbeiten ohne umst√§ndlich mit Triggerleitungen oder √§hnlichem verbunden sein zu m√ľssen. So k√∂nnte zum Beispiel ein Signalgenerator seine Frequenzliste zeitgesteuert abarbeiten und der zugeh√∂rige Analysator seine Messungen durchf√ľhren. Beide Aufgaben w√ľrden dann durch die zeitgebundenen Events gesteuert werden.

Auch im Bereich Mobilfunk kann man mit dem Einsatz von IEEE 1588 sicherlich verschiedenste Messaufgaben deutlich einfacher realisiert werden, da die zeitliche Kopplung zwischen Basisstation und Mobilfunkgerät bei diversen Messaufgaben von Relevanz ist.

Diese Anwendungsbeispiele h√∂ren sich im ersten Ansatz alle sehr vielversprechend an, basieren jedoch auf der Annahme dass auch die Messger√§te-Hersteller diesen Standard in ihren Ger√§ten implementiert haben. Selbst wenn alle den IEEE 1588 Standard verwenden w√ľrden, ist immer noch eine weitergehende Standardisierung notwendig um die einzelnen Aktionen und Aufgaben zu koordinieren.

Um dies den Messger√§te-Herstellern zu erleichtern wurde 2004 der LXI Standard (Lan eXentsion for Instruments) von dem f√ľhrenden Messger√§te-Hersteller ins Leben gerufen. 2008 wurde dann im LXI Standard der IEEE 1588 Standard mit aufgenommen und zus√§tzlich um einige Erweiterungen, wie die Lan Event Messages, erweitert. Mit Hilfe dieses Standards ist es nun den Messger√§te-Herstellern m√∂glich die Vorteile von IEEE 1588 in Messger√§ten effizient einzusetzen. Bis zur Vorstellung der Intel I21x Netzwerkchips war immer kostenintensive oder eigenentwickelte Hardware notwendig um den IEEE 1588 Standard in den Messger√§ten zu integrieren. Mit den Intel Netzwerkchips bietet sich nun erstmals die M√∂glichkeit diesen Standard mit Consumer Elektronik zu realisieren.

Bereits 2014 entschied das LXI Konsortium f√ľr Ihre Mitglieder ein Referenz Design bereitzustellen, um die Verwendung des Standards weiter zu verbreiten. Nachdem im LXI Referenz Design 2016 die Core Funktionalit√§t des Standards verf√ľgbar waren, begann das LXI Konsortium mit der deutschen Firma TSEP die M√∂glichkeit einer Referenz Implementierung der LXI Time Synchronisation (entspricht IEEE 1588) zu evaluieren und einen Prototypen zu erstellen. Im Februar 2017 wurde dann von TSEP auf einem der regelm√§√üigen Treffen des LXI Konsortium in den USA der erste Prototyp vorgestellt. Sowohl unter Linux als auch unter Windows war der Prototyp auf einem k√§uflichen Rechnerboard mit Intel I211 Chip lauff√§hig.

F√ľr den Linux Prototyp wurde das Linux Packet ‚ÄěLinuxPTP‚Äú verwendet. Die Implementierung der eigentlichen Clock Funktionalit√§t war aber nicht ausreichend um die geforderten Rahmenbedingungen des LXI und IEEE 1588 Standards zu erf√ľllen. TSEP hat deshalb dieses nachimplementiert. Der Regelalgorithmus zur Frequenznachf√ľhrung der IEEE 1588 Clock wurde dabei komplett neu entwickelt und optimiert.

Wie bereits erw√§hnt, bietet Windows keinerlei Unterst√ľtzung f√ľr IEEE 1588, deshalb wurde sowohl die komplette Clock Funktionalit√§t als auch der Treibersupport von TSEP erstellt. TSEP hat hierf√ľr die notwendigen Treiber f√ľr die Ansteuerung der Intel I21x Netzwerkchips f√ľr das Timestamping und das Erkennen von IEEEE 1588 Paketen im Windows Network Stack verankert. Sowohl unter Windows 7 als auch unter Windows 10 konnte diese Funktionalit√§t getestet werden.

Die ersten Gespr√§che mit dem LXI Konsortium √ľber die Bereitstellung der LXI Time Synchronisation (entspricht IEEE 1588) waren durchweg positiv und werden wahrscheinlich zu einer kostenlosen Bereitstellung f√ľr LXI Mitglieder in diesem Jahr f√ľhren. TSEP plant zus√§tzlich seine Implementierung f√ľr andere Interessenten, die nicht LXI Mitglieder sind, bereitzustellen.

Zusammenfassend kann gesagt werden, dass mit den kommerziellen Einsatz der Intel I21x Netzwerk-Chips es nun möglich ist IEEE 1588 in T&M Geräten einzusetzen. Die neuen Lösungsansätze die sich mit IEEE 1588 ergeben, erweitern die Möglichkeit Messaufgaben im T&M Bereich zu lösen um eine neue Dimension. Wird zusätzlich noch Erweiterungen wie der LXI Standard in T&M Geräten angeboten, lassen sich komplexe Messaufgaben einfacher und effizienter strukturieren.

Selbstkonfigurierende Systeme sind mit diesen Ansätzen nun möglich, da Geräte Daten und Aktionen Netzwerkweit konfigurieren, austauschen und auslösen können. Es bleibt abzuwarten wie die Messgeräte-Hersteller auf diese neue Technologie reagieren, ein großes Potenzial steckt allemal in ihr.

Literaturverzeichnis:

[1] IEEE. Ieee standard for a precision clock synchronization protocol for networked measurement and control systems, 2008.

[2] Bachelor Arbeit von Dominik Richstein, ‚ÄěUsability of the Intel Ethernet Controllers I210, I211 and I350 for the LXI Extended Function Clock Synchronization‚Äú

[3] CERN. White rabbit specification: Draft for comments, 06.07.2011.

[4] White Rabbit Project. White rabbit wiki, 2016.

 


--> -->