NTP vs. PTP: Wann verteilte Geräte dieselbe Zeitbasis brauchen

Gleiche Zeitstempel sind noch keine gemeinsame Zeit

Ein Zeitstempel beschreibt zunächst, was eine bestimmte Uhr zu einem bestimmten Zeitpunkt angezeigt hat. Werden Ereignisse aus mehreren Geräten zusammengeführt, kommt eine zweite Frage hinzu: Wie stehen diese Uhren zueinander?

Das wird relevant, sobald mehrere technische Quellen denselben Vorgang beschreiben. Eine Waage erfasst eine Masse, eine Kamera dokumentiert den Zustand am Arbeitsplatz, ein Scanner ordnet einen Behälter zu und ein Terminal hält eine Bestätigung fest. Jedes dieser Systeme kann einen eigenen Zeitpunkt liefern. Ob diese Zeitpunkte unmittelbar gegeneinander sortiert werden dürfen, folgt daraus noch nicht.

Für die spätere Rekonstruktion müssen deshalb mehrere Dinge auseinandergehalten werden: Auf welcher Uhr beruht ein Zeitstempel? Woher erhält diese Uhr ihre Zeit? Wie groß kann ihre Abweichung gegenüber den anderen beteiligten Uhren sein? Und welche zeitliche Unterscheidung benötigt der Prozess überhaupt?

NTP vs. PTP: Der Unterschied liegt nicht nur in der Genauigkeit

NTP und PTP sollen Uhren in einem Netzwerk auf eine gemeinsame Zeitbasis beziehen. Für die Prozessarchitektur unterscheiden sie sich aber nicht nur darin, wie eng zwei Uhren zusammengeführt werden können. Entscheidend ist auch, wie stark das Netzwerk selbst in die Synchronisation einbezogen wird.

Ein Übersichtsbeitrag in IEEE Access von Idrees et al. beschreibt die PTP-Seite dieses Unterschieds vor allem architektonisch: Grandmaster, unterschiedliche Uhrentypen, hardwaregestützte Zeitstempelung und die Kompensation von Netzverzögerungen wirken zusammen.^[3]

Der Vergleich beantwortet deshalb nicht, welches Protokoll grundsätzlich besser ist.

Wie NTP Uhren angleicht

Das Network Time Protocol dient dazu, Rechneruhren über Netzwerke zu synchronisieren. RFC 5905 beschreibt dafür eine hierarchische Struktur: Primäre Zeitserver stehen an der Wurzel, Sekundärserver und Clients beziehen ihre Zeit über weitere Ebenen. Diese Hierarchie wird als Stratum beschrieben; der RFC kennzeichnet Stratum 16 als unsynchronized.^[1]

Für die Beurteilung einer Zeitquelle reicht deshalb nicht allein der zuletzt gesetzte Uhrzeitwert. RFC 5905 unterscheidet unter anderem Offset, Delay, Dispersion und Jitter. Der Offset beschreibt die ermittelte zeitliche Verschiebung zwischen Server- und Systemuhr, der Delay die Hin- und Rücklaufzeit der Kommunikation. Dispersion bildet eine Fehlergrenze der Messung ab, während Jitter die Schwankung aufeinanderfolgender Offset-Werte beschreibt.^[1]

NTP kann außerdem mehrere mögliche Quellen gegeneinander bewerten. Der Auswahlalgorithmus verwirft Kandidaten, die als fehlerhaft angesehen werden, und arbeitet mit den verbleibenden geeigneten Quellen weiter. Zur Synchronisation gehört damit nicht nur das Übernehmen einer Uhrzeit, sondern auch die Bewertung der Quellen, aus denen diese Zeit abgeleitet wird.^[1]

Eine Grenze bleibt die Übertragung selbst. Die Berechnung des Zeitversatzes geht davon aus, dass die Netzlaufzeit in beide Richtungen ungefähr symmetrisch ist.^[2]

Wie PTP nach IEEE 1588 Zeit im Netzwerk verteilt

PTP, das Protokoll von IEEE 1588, verteilt Zeit hierarchisch von einer gemeinsamen Referenz an weitere Uhren im Netzwerk. Der Grandmaster bildet dabei die zentrale Zeitquelle. Ein Best-Master-Clock-Algorithmus kann bestimmen, welche Uhr diese Rolle übernimmt.^[3]

Die Fachliteratur unterscheidet dabei mehrere Uhrentypen. Eine Ordinary Clock ist die lokale Uhr eines Endgeräts. Eine Boundary Clock sitzt zwischen Master und nachgelagerten Uhren und führt die Synchronisation über Zwischenknoten weiter. Eine Transparent Clock misst dagegen, wie lange eine PTP-Nachricht in einem Zwischenknoten verweilt, und führt diese Aufenthaltszeit in einem Korrekturwert mit.^[3]

Für die eigentliche Synchronisation tauschen Master und nachgelagerte Uhr zeitgestempelte Nachrichten aus. Der Master sendet eine Sync-Nachricht mit seinem Sendezeitpunkt. Bei einem Zweischritt-Verfahren folgt eine Follow_Up-Nachricht mit dem präzisen Zeitstempel. Die nachgelagerte Uhr erfasst den Empfang, sendet anschließend Delay_Req, und der Master meldet den Empfangszeitpunkt über Delay_Resp zurück. Aus diesen Zeitpunkten lassen sich Offset und mittlere Laufzeit bestimmen.^[3]

Für die erreichbare Synchronisationsgüte ist dabei entscheidend, wo der Zeitstempel entsteht. Hardwaregestützte Zeitstempelung kann näher an der physischen Schnittstelle erfolgen und dadurch den Einfluss von Betriebssystem-Latenzen verringern.

Auch PTP beseitigt Unsicherheit jedoch nicht. Die Laufzeitberechnung setzt ebenfalls voraus, dass Hin- und Rückweg hinreichend symmetrisch sind – eine Annahme, die laut Fachliteratur in realen Netzen in der Regel nicht exakt zutrifft. Warteschlangen in Switches, Übertragungs- und Verarbeitungsverzögerungen sowie Drift der lokalen Oszillatoren bleiben deshalb relevante Fehlerquellen.

PTP ist damit nicht einfach eine genauere Variante von NTP. Es bezieht Teile der Netzwerkinfrastruktur selbst stärker in die Synchronisation ein.^[3]

Wann NTP genügt – und wann PTP nötig werden kann

Eine Faustregel wie „ab einer Millisekunde PTP“ beantwortet die falsche Frage. Entscheidend ist zuerst, welche Ereignisse später noch sicher voneinander unterschieden oder miteinander korreliert werden müssen.

Wenn eine Waage einen Wert liefert und eine Freigabe mehrere Sekunden später erfolgt, kann eine größere zeitliche Unsicherheit tolerierbar sein als bei einem Vorgang, in dem Kamerabild, Messwert und Maschinenzustand innerhalb eines sehr engen Zeitfensters zusammengehören.

Für die Auswahl sind deshalb vor allem drei Fragen wichtig:

• Wie dicht können die Ereignisse liegen, deren Reihenfolge noch sicher unterschieden werden muss?
• Kommen die relevanten Zeitstempel aus mehreren unabhängigen Uhren und Netzpfaden?
• Was soll geschehen, wenn die geforderte Synchronisationsgüte nicht mehr erreicht wird?

NTP kann ausreichend sein, wenn die im konkreten Netz tatsächlich erreichte Synchronisationsgüte deutlich innerhalb dessen liegt, was der Prozess benötigt.

PTP kann relevant werden, wenn Netzpfad, Zwischenkomponenten und Zeitstempelpunkt selbst Teil der geforderten zeitlichen Genauigkeit werden.

Wie stark die Implementierung zählt, zeigt die Fachliteratur: Für hardwaregestützte PTP-Zeitstempelung werden Abweichungen bis hinab zu etwa 100 Nanosekunden berichtet, für reine Software-Zeitstempelung 10 bis 100 Mikrosekunden. Das sind berichtete Werte einzelner Implementierungen, keine garantierte Eigenschaft des Protokolls. Schon die Art der Zeitstempelerzeugung kann die tatsächlich erreichte Synchronisationsgüte damit um Größenordnungen verändern.

Auch die Netzkomponenten bleiben relevant. PTP-fähige Switches und Router können für besonders enge Synchronisationsanforderungen erforderlich werden.^[3]

Nicht das Protokoll bestimmt, welche Zeitqualität ein Prozess braucht. Der Prozess bestimmt, welche Synchronisationsarchitektur diese Qualität liefern muss.

Zeitstempel sind keine synchronisierten Uhren

Ein Gerätewert kann mehr als einen Zeitbezug tragen. OPC UA kann in einem DataValue neben dem eigentlichen Wert unter anderem einen SourceTimestamp und einen ServerTimestamp führen.^[4]

Der SourceTimestamp bezeichnet den Zeitpunkt, den die Datenquelle dem Wert zugeordnet hat. Wird der Wert über einen weiteren OPC-UA-Server weitergereicht, bleibt dieser Quellzeitstempel erhalten. Der ServerTimestamp beschreibt dagegen den Zeitpunkt, zu dem der jeweilige Server den Wert erhalten hat oder ihn als zutreffend kannte. Zwei Zeitangaben können deshalb nebeneinanderstehen, ohne dass eine von ihnen falsch sein muss.^[4]

Für die Zeitsynchronisation steckt darin ein wichtiger Unterschied. OPC UA verlangt für den SourceTimestamp, dass dieser möglichst nah an der Datenquelle entsteht und immer von derselben physischen Uhr gesetzt wird. Damit ist die Herkunft des Zeitbezugs konsistent. Daraus folgt aber noch nicht, dass diese Uhr gegenüber der Uhr eines zweiten Geräts hinreichend genau läuft.

Am IoT-Gateway liegen SourceTimestamp und Empfangszeit nebeneinander vor. Diese Trennung schafft die Voraussetzung dafür, später zu erkennen, welche Uhr welchen Zeitpunkt erzeugt hat und wie dieser Zeitpunkt in den Prozess gelangt ist.^[4]

Ein vollständiger Zeitstempel beantwortet also die Frage „Wann laut dieser Quelle?“. Die weitergehende Frage lautet: Wie belastbar lässt sich dieser Zeitpunkt mit den Zeiten anderer Quellen vergleichen?

Was das System über seine eigene Zeit wissen muss

Eine belastbare Zeitbasis hat selbst einen Zustand. NTP kennt ausdrücklich den Zustand unsynchronized. OPC UA sieht vor, dass der SourceTimestamp auf null gesetzt wird, wenn die Quelle, die diesen Zeitstempel erzeugt, nicht verfügbar ist. Ein fehlender oder unsicherer Zeitbezug sollte deshalb nicht stillschweigend durch den letzten bekannten Zustand ersetzt werden.^[1][4]

Hinzu kommt die Frage, ob der Zeitquelle überhaupt vertraut werden kann. Network Time Security kann NTP kryptografisch absichern. RFC 8915 nennt unter anderem Authentizität der Synchronisationspakete und die Erkennung wiederholter Pakete als Ziele.^[2]

Diese Absicherung löst jedoch nicht jedes Zeitproblem. Bei einem asymmetrischen Verzögerungsangriff kann ein Angreifer Synchronisationspakete unterschiedlich lange verzögern. Der Inhalt der Pakete muss dabei weder verändert noch ihre Reihenfolge vertauscht werden. Weil die NTP-Berechnung ungefähr symmetrische Netzlaufzeiten voraussetzt, kann der Client trotzdem einen falschen Zeitversatz berechnen. RFC 8915 hält ausdrücklich fest, dass kryptografische Mittel diesen Angriff nicht auf praktikable Weise beseitigen.

Der dabei erzeugbare Fehler ist allerdings begrenzt: auf höchstens die halbe Round-Trip-Laufzeit. Mehrere Zeitquellen oder unterschiedliche Netzpfade können das Risiko zusätzlich mindern.

Vertrauenswürdige Übertragung und hinreichend genaue Zeit sind deshalb zwei verschiedene Anforderungen.^[2]

Was die Prozessarchitektur festlegen muss

Die Wahl einer Synchronisationstechnik sollte am Ende einer fachlichen Festlegung stehen, nicht an ihrem Anfang.

Die drei Fragen zur Auswahl führen zu Festlegungen: Der Prozess muss bestimmen, welche zeitliche Auflösung für seine Entscheidungen benötigt wird, welche technischen Quellen miteinander verglichen werden und worauf deren Zeitangaben beruhen. Ebenso muss feststehen, wie mit einer bekannten Abweichung oder dem Verlust der Zeitquelle umgegangen wird und welche Informationen zum Zeitbezug zusammen mit einem Ereignis erhalten bleiben.

21 CFR 11.10(e) verlangt zeitgestempelte Audit Trails.^[5] PIC/S PI 041-1 verlangt, dass erkennbar ist, wer eine Tätigkeit ausgeführt hat und wann.^[6] Eine Vorgabe, nach welchem Verfahren oder mit welcher Genauigkeit die beteiligten Uhren aufeinander bezogen sein müssen, enthält keines der beiden Dokumente. Die belastbare zeitliche Einordnung bleibt damit eine Anforderung, die der Betrieb aus seinem Prozess ableiten muss.

Eine geeignete Architektur muss deshalb nicht nur einen Zeitpunkt speichern können. Sie muss auch so gestaltet sein, dass erkennbar bleibt, auf welcher Zeitbasis die Angabe beruht und welchen Zustand diese Zeitbasis hatte.