Warum PToB auf UTC setzt
Die Entscheidung, Schaltsekunden zu beenden, lässt uns UTC für kleine Clients einfach halten und einen klaren Weg zu TAI- und PTP-Umgebungen bewahren.
UTC-Präzisionsinstrument
Anzeige der Mesh-Epoche
GNSS- und PTP-Diagnostik
Wir haben uns entschieden, PToB auf die koordinierte Weltzeit UTC zu vereinheitlichen. Unsere Clients sollen Zeit erhalten, die sie direkt für Uhren, Protokolle und Messungen nutzen können; Systeme mit entsprechendem Bedarf behalten die Möglichkeit zur Umrechnung mit TAI-Versatz.
Wir hatten einen Wechsel zur internationalen Atomzeit TAI erwogen, um näher an der Zeitskala des Precision Time Protocol (PTP) zu liegen. Die jüngste Entscheidung für kontinuierliches UTC verändert diese Abwägung. Sie gibt kleinen Mikrocontrollern am Mesh-Rand eine einfachere Grundlage.
Was die Schaltsekundenentscheidung ändert
UTC und TAI laufen gleich schnell, doch UTC hat bisher Schaltsekunden genutzt, um nahe an der unregelmäßigen Erdrotation zu bleiben. Am 15. Oktober 2026 beschloss die Generalkonferenz für Maß und Gewicht den nächsten Schritt: Kontinuierliches UTC tritt am 20. Mai 2027 in Kraft. Die erlaubte Differenz zwischen UTC und der Erdrotationszeit UT1 steigt auf eine Stunde; damit kann UTC mehrere Jahrhunderte kontinuierlich bleiben. BIPM-Resolution 5 beschreibt diese Änderung.
Heute gilt: TAI ist UTC plus 37 Sekunden. Die neue Regelung macht daraus auf absehbare Zeit einen beständigen Versatz und beseitigt die wiederkehrenden Schaltsekundenänderungen, die Umrechnungen erschwerten. Historische Zeitstempel brauchen weiterhin den zu ihrem Datum geltenden Versatz. Die Schaltsekundenübersicht des NIST dokumentiert den aktuellen Versatz und frühere Änderungen.
Für PToB entfällt damit ein wesentlicher Grund, das gesamte Mesh auf TAI umzustellen.
UTC am Client, TAI bei Bedarf
Bei Verteilung von TAI müsste jeder Mikrocontroller, der UTC braucht, den richtigen Versatz anwenden. Die Rechnung ist einfach; zusätzliche Verantwortung entsteht dadurch, den Versatz über Geräte, Firmwareversionen und Quellenwechsel hinweg gültig und einheitlich zu halten.
Wir wählen UTC als standardmäßig bereitgestellte Zeit. Ein Sensor kann eine Beobachtung zeitstempeln, ein Instrument die Uhrzeit anzeigen und ein Client ein Protokoll schreiben, ohne zunächst eine separate TAI-UTC-Umrechnung zu verwalten.
Für Schnittstellen, die TAI erwarten, gilt derzeit einfach: TAI = UTC + 37 Sekunden. Diese Umrechnung lässt sich an der Schnittstelle anbieten, während PToB durchgehend einer UTC-Konvention folgt. Der zusätzliche Versatz ändert die Zeitdarstellung; Präzision und Unsicherheit der Uhr bleiben erhalten.
Eine PTP-Brücke muss weiterhin richtige Domäne, Zeitstempelepoche und Zeiteigenschaften übertragen. PTP bildet den UTC-Versatz und seine Gültigkeit ausdrücklich ab. Die passende Zeitskala ist ein Teil der Interoperabilität; unsere Entscheidung schafft dafür eine klare Grundlage.
Eine Mesh-Epoche über Grandmaster-Wechsel hinweg
Neben der Zeitskalenentscheidung arbeiten wir an der eigenen Epoche des Meshs: der Identität eines laufenden Meshs, die bei seiner Entstehung initialisiert wird.
Diese Epoche übersteht Grandmaster-Wechsel, solange mindestens ein beteiligter Knoten das Mesh am Leben hält. Ein Ersatz-GM übernimmt die bestehende Epoche von verbliebenen Mitgliedern. Fällt das gesamte Mesh aus, begründet ein Neustart eine neue Epoche.
So unterscheiden Clients die Kontinuität des Meshs von der Laufzeit eines bestimmten GMs. Quellenwechsel verlangen weiterhin frische Uhrenabbildungen und die üblichen Eignungsprüfungen; die beibehaltene Epoche erhält bei diesen Wechseln die Mesh-Identität.
Ein Präzisionsinstrument zum Untersuchen des Meshs
Unsere neue CoreS3-SE-Uhr bringt diese Ideen auf eine von klassischen Präzisionsinstrumenten inspirierte Anzeige: große UTC-Ziffern, eingelassene Messfenster und klare Zustandsanzeigen.
Wir ergänzen außerdem per Funk übertragene GNSS- und PTP-Qualitätsdiagnostik für Clients. Authentifizierte Berichte zeigen GNSS-Fix, PPS- und Qualifizierungszustand der ausgewählten Quelle, Satellitenzahl, HDOP sowie Uhrenklasse und Wahlprioritäten im Mesh. Clients können diese Berichte neben ihrem Zeitpfad und ihrer lokalen Empfangsqualität prüfen.
Diese Berichte beschreiben die Quelle. Sie erteilen keine Zeitfreigabe und belegen keine kalibrierte UTC-Genauigkeit. Das Instrument trennt berichteten Quellenzustand von eigenen Empfangsmessungen und kennzeichnet ältere zwischengespeicherte Berichte.
Das CoreS3-SE-Ziel ist jetzt auf GitHub verfügbar (Englisch), mit Build- und Installationsanleitung (Englisch) sowie Dokumentation der Diagnosefelder (Englisch) für alle, die Instrument und Berichte hinter den Anzeigen erkunden möchten.