Zeitgebung Hardware-in-the-Loop: die Antenne abziehen, den Holdover bewerten

Telecom- und Energiebetreiber prüfen ein Zeitgebungssystem, indem sie ihm GNSS wegnehmen und beobachten, was die Uhr tut. Kshana tut das nicht für sie und berührt ihre Geräte nicht. Es liest die Zeitfehleraufzeichnung, die die eigenen Instrumente des Betreibers erzeugt haben, teilt sie an den beiden vom Betreiber angegebenen Zeiten auf und misst jeden Schritt an öffentlichen ITU-T-Masken. Die Szenarioart ist holdover-test; die Beispielszenarien sind scenarios/holdover-test-example.toml und scenarios/holdover-test-ptp4l.toml.

Dies ist Stufe 1 der Hardware-Sicherheit: passiv, nur empfangend, kein HF von Kshana (HARDWARE-SAFETY.md). Beratende Software, kein typzugelassenes Gerät. Niemand hat dieses Verfahren bewertet, genehmigt oder geprüft, und es sagt nichts darüber aus, ob ein System eine Empfehlung erfüllt.

Das Verfahren#

Der Betreiber führt vier Schritte aus. Kshana führt keinen davon aus.

Zwei Dinge muss der Betreiber tun, weil Kshana sie nicht kann:

• Die beiden Zeiten angeben. gnss_removed_s und gnss_restored_s sind die Angabe des Betreibers. Kshana erkennt das Entfernen nicht in der Aufzeichnung und prüft die Zeiten nicht. Eine falsche Zeit verschiebt die Schrittgrenzen und damit das Ergebnis.
• Verwenden Sie für die Aufzeichnung und die Zeiten dieselbe Uhr. Bei einem Uhrenprotokoll beginnt die Zeitachse mit dem ersten Messwert, daher sind die beiden Zeiten Sekunden ab der ersten Zeile des Protokolls.

Was aufzuzeichnen ist#

Eines davon, über die vorhandenen clock_log-Leser (CLOCK-LOG-FORMATS.md):

Was die Aufzeichnung misst, ist wichtig. Ein Servo-Protokoll (linuxptp, chrony) zeichnet den Versatz auf, den der Daemon gemessen hat und korrigiert: Es ist der unter Servoregelung verbleibende Zeitfehler, keine unabhängige Messung der Uhr gegen UTC. Während des Holdover-Schritts eines Tests, der die Referenz wirklich entfernt, zeigt ein Servo-Protokoll weiterhin, was der Daemon annahm, was vom wahren Fehler abweichen kann. Ein TICC oder ein anderer Zähler gegen eine unabhängige Referenz ist die stärkere Aufzeichnung; geben Sie bei der Berichterstattung des Ergebnisses an, welche Sie verwendet haben.

Das Szenario#

kind = "holdover-test"
masks = ["prtc-a", "eprtc-a-holdover"]      # see docs/TELECOM-TIMING.md for the ids

[test]
gnss_removed_s = 600.0                      # the operator's statement
gnss_restored_s = 2400.0                    # omit if GNSS was not restored within the record
locked_duration_days = 5.0                  # how long it was locked before step 2 (sets the ePRTC-A period)
recovery_band_ns = 100.0                    # |TE| inside this counts as recovered
recovery_dwell_s = 60.0                     # ... and must stay inside this long

[series.clock_log]                          # or [series] samples = [[t, ns], ...] or csv_path = "..."
format = "ptp4l"
path = "holdover-2026-11-02.log"            # or text = "..." inline

kshana holdover-test.toml

Optionale Schlüssel: budgets (Name, max_abs_te_ns, Quelle; die Telecom-Timing-Standardwerte, wenn nicht vorhanden) und clock = "..." innerhalb von [series.clock_log], um aus einem Protokoll mit mehreren Uhren eine Quelle auszuwählen.

Was der Bericht enthält#

• steps: für die Basislinie, den Holdover und die Wiederherstellung Anfang und Ende, die Anzahl der Abtastwerte sowie Mittelwert, Effektivwert, größten Wert und Endwert des Zeitfehlers.
• masks: jede genannte Maske, gemessen an dem Schritt, den ihre Bedingung nennt. Eine für eine synchronisierte Uhr geschriebene Maske wird an der Basislinie gemessen; eine für Holdover oder eine autonome Uhr geschriebene am Holdover. Jede Prüfung hat ihren Grenzwert, den gemessenen Wert, die Marge und die Tabelle, aus der sie übertragen ist. Eine Maske, die eine längere Aufzeichnung braucht, als der Schritt lieferte, ist INCOMPLETE und wird nie extrapoliert; eine, die die Engine für das Abtastintervall der Aufzeichnung nicht auswerten kann, ist NOT-EVALUATED mit Angabe des Grundes.
• holdover: der relative Frequenzversatz, den das System hielt (die Steigung einer Ausgleichsgeraden nach kleinsten Quadraten durch den Holdover-Zeitfehler, in ns/s, also parts per billion), die Restabweichung um diese Gerade, der größte absolute Zeitfehler und wann er auftrat sowie der Sprung im Moment des Entfernens.
• holdover_envelope: die ePRTC-A-Holdover-Hüllkurve aus ITU-T G.8272.1 Tabelle 3, aus locked_duration_days, mit dem Zeitpunkt ihrer ersten Überschreitung.
• budgets: die Zeit nach dem Entfernen, zu der jedes Zeitfehlerbudget erstmals überschritten wird.
• recovery: ob |TE| in das Band kam und für die Verweilzeit darin blieb, wie lange nach der Rückkehr von GNSS das begann, die Spitze nach der Wiederherstellung und der größte Sprung zwischen aufeinanderfolgenden Abtastwerten während der Wiederherstellung.
• curves: MTIE und TDEV der Basislinien- und Holdover-Schritte.
• verdicts: eine Ein-Wort-Zusammenfassung pro Schritt.

Jede Zahl trägt ihre Einheit und ihre Herkunft im Block units des Berichts.

Die Worte und die Grenzen#

• Das Ergebnis wird an der Maske gemessen. Die Masken sind aus frei herunterladbaren ITU-T-Empfehlungen übertragen (dieselben Tabellen wie bei der Szenarioart telecom-timing, aufgeführt in TELECOM-TIMING.md), und jeder Eintrag, den die Empfehlungen „Gegenstand weiterer Untersuchung“ lassen, fehlt, statt ergänzt zu werden. Kshana sagt nicht, dass eine Uhr oder ein System eine Empfehlung erfüllt oder gegen sie zugelassen ist, und der Bericht sagt es auch nicht.
• MODELLED. Die Schrittlogik, die Geradenanpassung und die Wiederherstellungsregel werden an Aufzeichnungen geprüft, die aus Formeln mit vor dem Lauf bekannten Ergebnissen erzeugt wurden; kein Labor-Holdover wurde gegen eine externe unabhängige Referenz bewertet, und kein Partner und kein Labor hat irgendetwas zugestimmt. Ein Zeitgebungslabor wäre nötig, bevor eine Angabe je Uhrenklasse hochgestuft werden könnte.
• Was nicht abgedeckt ist, in jedem Bericht angegeben: ob GNSS zu den angegebenen Zeiten wirklich entfernt und wiederhergestellt wurde; jeder Schritt, den der Betreiber nicht aufgezeichnet hat; über ein 0,1-Hz-Filter definierte Masken bei einer Aufzeichnung, die langsamer als einmal pro Sekunde abgetastet wurde; die eigene Messunsicherheit des Instruments; und jedes Verfahren der Empfehlungen, das über eine Zeitfehleraufzeichnung hinausgeht (Temperaturprofile, Last im Paketnetz).
• Das Wiederherstellungsband ist die eigene Wahl des Tests. Der Standardwert von 100 ns ist der maximale absolute Zeitfehler eines PRTC-A (ITU-T G.8272); er ist eine bequeme Linie, keine Anforderung irgendeiner Empfehlung an die Wiederherstellung.
• Kein Sendepfad. Kshana liest Dateien. Es erzeugt kein Signal, und das Entfernen von GNSS im Labor erfolgt mit den eigenen Geräten des Labors und unter dessen eigener Genehmigung.

Oberflächen#

holdover-test ist eine Szenarioart und läuft daher überall, wo Szenarioarten laufen: kshana <scenario.toml>, die Rust-API (kshana::api::run_toml), die Python-Anbindung (kshana.run), der WebAssembly- und npm-Build (Inline-samples oder clock_log.text; die Dateischlüssel sind dort nicht verfügbar), der MCP-Server (run_scenario, nur Inline-Inhalt) und der Szenario-Runner von Kshana Studio. Die beiden Szenariodateien sind mitgeliefert (kshana example holdover-test-example).