holdover-test (Szenarioart)
Szenariotyp der Engine v0.40.0, Familie Uhren, Zeitgebung und Holdover. Nur beratend: Analyseausgabe eines Forschungs- und Engineering-Werkzeugs, keine typzugelassene Navigationsausrüstung und kein Safety-of-Life-Dienst. Jede Kennzeichnung hier stammt von der Engine oder von der Verifikationsmatrix; ein Typ ist MODELLED, sofern die Matrix nichts anderes angibt (wie eine Kennzeichnung erworben wird: Abschnitt „Evidence“ der README).
Was es tut#
MODELLED Holdover-Test eines Zeitgebungssystems, bewertet anhand eines Zeitfehlerprotokolls, das der BETREIBER liefert (ein linuxptp-Protokoll von ptp4l, phc2sys oder ts2phc, ein chrony-Tracking- oder Statistikprotokoll, ein TICC-, TimeLab- oder RINEX-Uhrenprotokoll oder Paare aus time_s,time_error_ns). Der Test hat vier Schritte, und Kshana führt keinen davon aus: eine eingerastete BASISLINIE, GNSS ENTFERNT durch den Betreiber (das Antennenkabel oder der Simulatorausgang; Kshana sendet nichts und steuert nichts an) zu einem angegebenen Zeitpunkt, HOLDOVER auf dem eigenen Oszillator des Systems und WIEDERHERSTELLUNG, nachdem der Betreiber GNSS zu einem zweiten angegebenen Zeitpunkt wiederherstellt. Das Protokoll wird an diesen beiden Zeitpunkten geteilt. Basislinie: Zeitfehlerstatistik und die für eine eingerastete Uhr geschriebenen ITU-T-Masken. Holdover: Statistik, der Bruchteil des Frequenzversatzes, den das System gehalten hat (eine Ausgleichsgerade nach kleinsten Quadraten), die für Holdover oder eine autonome Uhr geschriebenen Masken, die ePRTC-A-Holdover-Hüllkurve aus der angegebenen Dauer im eingerasteten Zustand und die Zeit bis zur Überschreitung jedes Zeitfehlerbudgets. Wiederherstellung: ob und wann |TE| in ein angegebenes Band gelangte und dort blieb, der Spitzenwert und der größte Sprung. Jeder Grenzwert ist aus einer öffentlichen ITU-T-Tabelle übertragen (die Masken für Telekom-Zeitgebung); die Formulierung lautet 'gegen die Maske gemessen', und die beiden Zeitpunkte sind die Angabe des Betreibers, nicht verifiziert. Ein für eine Maske zu kurzes Protokoll ist INCOMPLETE, nie extrapoliert. Siehe docs/TIMING-HIL.md.
Ein Lauf von scenarios/holdover-test-ptp4l.toml fasst sich so zusammen: holdover-test: holdover 1795 s, max|TE| 59,0 ns; prtc-a PASS, eprtc-a-holdover FAIL; recovered 0 s after GNSS returned (MODELLED, measured against the mask)
Eingaben#
Aus dem Schema (kshana kinds --json):
- Pflichtfelder:
test,series - Optionale Felder:
masks,budgets
Das Beispiel scenarios/holdover-test-ptp4l.toml setzt unter anderem:
| Feld | Wert | Einheit |
|---|---|---|
kind |
holdover-test | Text |
masks |
[prtc-a, eprtc-a-holdover] | nicht angegeben |
series.clock_log.format |
ptp4l | Text |
series.clock_log.text |
ptp4l[1000,000]: master offset -4 s2 freq + 1200 pa | Text |
test.gnss_removed_s |
600 | s |
test.gnss_restored_s |
2400 | s |
test.locked_duration_days |
5 | d |
test.recovery_band_ns |
100 | ns |
test.recovery_dwell_s |
60 | s |
Ausführen#
kshana scenarios/holdover-test-ptp4l.toml
2 mitgelieferte Szenarien verwenden diese Art; die anderen sind in scenarios/.
Was es liefert#
Die skalaren Ergebnisse dieses Laufs, mit den Einheiten, die die Engine angibt:
| Ergebnis | Wert | Einheit |
|---|---|---|
clock_log.clock |
master | Text |
clock_log.data |
phase | Text |
clock_log.format |
ptp4l | Text |
clock_log.gap_policy |
refuse | Text |
clock_log.n_duplicates |
0 | 1 |
clock_log.n_gaps |
0 | 1 |
clock_log.n_grid |
600 | 1 |
clock_log.n_interpolated |
0 | 1 |
clock_log.n_missing |
0 | 1 |
clock_log.n_off_grid |
0 | 1 |
Ergebnisbezeichnung (der Engine): MODELLED — ein Holdover-Test, bewertet anhand eines Zeitfehlerprotokolls, das der Betreiber geliefert hat. Jeder Grenzwert ist aus der benannten öffentlichen ITU-T-Empfehlung übertragen, und das Ergebnis wird gegen die Maske gemessen; es sagt nichts darüber aus, ob eine Uhr oder ein System eine Empfehlung erfüllt, und niemand hat es bewertet oder genehmigt
Nachweise#
MODELLED: die Zeilen der Verifikationsmatrix, die diese Art nennen.
- MODELLED Die Szenarioart
holdover-test: Ein Zeitfehlerprotokoll (ein linuxptp-, chrony-, TICC-, TimeLab- oder RINEX-Uhrenprotokoll oder Paare aus time_s,time_error_ns) wird an den beiden vom Betreiber angegebenen Zeitpunkten für das Entfernen und Wiederherstellen von GNSS in eine Basislinie, einen Holdover und
Die Zeilen, die der Lauf selbst ausgeübt hat, mit der unabhängigen Referenz, die die Matrix jeder gibt (die öffentlichen Quellen sind dort genannt):
- MODELLED Deterministisch, szenario-gehasht, SBOM- und plattformübergreifende Golden-Gates. Unabhängige Referenz (ExternalDataset): SBOM-Übereinstimmung mit dem offiziellen CycloneDX-1,5-JSON-Schema (+ gültige SPDX-Kennungen) — ein externer veröffentlichter Standard, null Validierungsfehler über den gesamten Abhängigkeitsgraphen; der Teil FoM-Determinismus / Byte-Reproduzierbarkeit bleibt eine festgelegte Selbstkonsistenzprüfung, daher bleibt die Zeile MODELLED
- VALIDATED Das maximale Zeitintervallfehler- und Zeitabweichungsmaß, das die Szenarioart
telecom-timingauf einem Holdover-Protokoll im Telekom-Maßstab meldet: ein O(n) monotones Warteschlangen-Schiebefenster. Orakel (ExternalDataset): allantools 2024,06 — eine unabhängige Frequenzstabilitätsbibliothek eines Drittanbieters — mtie() und tdev() auf tests/fixtures/telecom_timing/holdover_te_series.csv, wobei die Reihe auf beiden Seiten aus demselben Text mit 17 signifikanten Stellen geparst wird; die Referenz zeichnet das SHA-256 der Reihe auf und ist offline über tests/fixtures/telecom_timing/generate_telecom_timing_reference.py neu erzeugbar. Validiert die SCHÄTZER auf diesem Protokoll, nicht die syn - MODELLED Übertragene Grenzwerte von ITU-T G.8272 (07/2025) PRTC-A/B, G.8272.1 (2024) Amd. 1 (07/2025) ePRTC eingerastet und ePRTC-A-Holdover (einschließlich der Zeitfehler-Hüllkurve nach Tabelle 3. Orakel (InternalConsistency): Übertragung der benannten Empfehlungen (frei herunterladbar von itu.int), wobei jeder Grenzwert seine Tabelle oder Klausel trägt, aufgelistet zusammen mit jedem unbestätigten oder nicht implementierten Punkt in docs/TELECOM-TIMING.md; die Stetigkeitsidentitäten an den Knickpunkten, die die Tabellen implizieren, werden in den Tests geprüft. Eine Normübertragung mit Prüfungen auf interne Konsistenz, kein Konformitätstest und keine externe Validierung. 0,30 round 2 (pre-register
- MODELLED Die Szenarioart
holdover-test: Ein Zeitfehlerprotokoll (ein linuxptp-, chrony-, TICC-, TimeLab- oder RINEX-Uhrenprotokoll oder Paare aus time_s,time_error_ns) wird an den beiden Zeitpunkten geteilt. Orakel (InternalConsistency): Handrechnung an Protokollen, die aus Formeln aufgebaut sind, deren Steigung, Sprung, Extremum und Wiederherstellungszeit vor dem Lauf bekannt sind (die Tests geben sie an), sowie die Masken, die Hüllkurve und die Budgets der oben stehenden Telecom-Timing-Zeilen. Es wurde keine Labormessung eines echten Holdovers bewertet und keine externe unabhängige Referenz verglichen, daher erhebt die Szenarioart keine Aussage über irgendeine Uhr oder ein System; vor jedem Abschluss je Uhrenklasse ist ein Zeitlabor-Partner nötig
Einschränkungen#
Was der eigene Bericht des Laufs als nicht modelliert oder nicht validiert nennt:
- MODELLED — ein Holdover-Test, bewertet anhand eines Zeitfehlerprotokolls, das der Betreiber geliefert hat. Jeder Grenzwert ist aus der benannten öffentlichen ITU-T-Empfehlung übertragen, und das Ergebnis wird gegen die Maske gemessen; es sagt nichts darüber aus, ob eine Uhr oder ein System eine Empfehlung erfüllt, und niemand hat es bewertet oder genehmigt. Die Zeitpunkte, zu denen GNSS entfernt und wiederhergestellt wurde, sind die Angabe des Betreibers und nicht verifiziert. Beratende Soft (Ergebnis
label) - MODELLED Holdover-Test eines Zeitgebungssystems, bewertet anhand eines Zeitfehlerprotokolls, das der BETREIBER liefert (ein linuxptp-Protokoll von ptp4l, phc2sys oder ts2phc, ein chrony-Tracking- oder Statistikprotokoll, ein TICC-, TimeLab- oder RINEX-Uhrenprotokoll oder Paare aus time_s,time_error_ns). (Szenarioarten-Katalog (
kshana kinds --json)) - Reproduzierbarkeit und Software-Assurance ist MODELLED, nicht validiert: Eine Teilbehauptung ist extern geprüft, aber die gesamte Fähigkeit setzt sich aus modellierten Teilen zusammen, daher bleibt die Fähigkeit modelliert. (Verifikationsmatrix (docs/MODELLED-RATIONALE.md))
- Die ITU-T-Masken für Telekom-Synchronisation mit PASS/FAIL und Marge sind MODELLED, nicht validiert: Sie werden gegen ihre eigene geschlossene bzw. analytische Identität geprüft - das fängt Übertragungs- und Koeffizientenfehler ab, ist aber keine externe unabhängige Referenz. (Verifikationsmatrix (docs/MODELLED-RATIONALE.md))
- Der Holdover-Test, bewertet anhand eines vom Betreiber gelieferten Zeitfehlerprotokolls, ist MODELLED, nicht validiert: Er wird gegen seine eigene geschlossene bzw. analytische Identität geprüft - das fängt Übertragungs- und Koeffizientenfehler ab, ist aber keine externe unabhängige Referenz. (Verifikationsmatrix (docs/MODELLED-RATIONALE.md))
Siehe auch#
- Familienseite: Uhren, Zeitgebung und Holdover
- Alle Arten: KINDS.md
- Themenseite: TIMING-HIL.md
- Themenseite: HARDWARE-SAFETY.md