Tidssynkronisering med maskinvare i løkken: trekk ut antennen, skår holdoveren

Telekom- og kraftoperatører tester et tidssynkroniseringssystem ved å ta GNSS bort og se hva klokken gjør. Kshana gjør ikke det for dem, og rører ikke utstyret deres. Den leser tidsfeilregistreringen operatørens egne instrumenter har laget, deler den ved de to tidspunktene operatøren oppgir, og måler hvert trinn mot offentlige ITU-T-masker. Scenariotypen er holdover-test; eksempelscenarioene er scenarios/holdover-test-example.toml og scenarios/holdover-test-ptp4l.toml.

Dette er maskinvaresikkerhet trinn 1: passivt, bare mottak, ingen RF fra Kshana (HARDWARE-SAFETY.md). Veiledende programvare, ikke typegodkjent utstyr. Ingen har vurdert, godkjent eller gjennomgått denne prosedyren, og den sier ingenting om hvorvidt et system oppfyller en anbefaling.

Prosedyren#

Operatøren utfører fire trinn. Kshana utfører ingen av dem.

To ting operatøren må gjøre, fordi Kshana ikke kan:

• Oppgi de to tidspunktene. gnss_removed_s og gnss_restored_s er operatørens oppgave. Kshana oppdager ikke fjerningen ut fra registreringen og verifiserer ikke tidspunktene. Et feil tidspunkt flytter trinngrensene og dermed resultatet.
• Bruk den samme klokken for registreringen og tidspunktene. For en klokkelogg starter tidsaksen ved den første avlesningen, så de to tidspunktene er sekunder fra første linje i loggen.

Hva som skal registreres#

Hvilken som helst av disse, gjennom de eksisterende leserne for clock_log (CLOCK-LOG-FORMATS.md):

Hva registreringen måler, har betydning. En servolog (linuxptp, chrony) registrerer forskyvningen daemonen målte og korrigerer: det er tidsfeilen som er igjen under servostyring, ikke en uavhengig måling av klokken mot UTC. Under holdover-trinnet i en test som virkelig fjerner referansen, viser en servolog fortsatt hva daemonen trodde, og det kan avvike fra den sanne feilen. En TICC eller en annen teller mot en uavhengig referanse er den sterkere registreringen; oppgi hvilken du brukte når du rapporterer resultatet.

Scenarioet#

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

Valgfrie nøkler: budgets (navn, max_abs_te_ns, kilde; standardverdiene for telecom-timing når de mangler) og clock = "..." inne i [series.clock_log] for å velge én kilde fra en logg som inneholder flere.

Hva rapporten inneholder#

• steps: for grunnlinjen, holdoveren og gjenopprettingen: start og slutt, antall sampler og middelverdi, rms, største verdi og sluttverdi for tidsfeilen.
• masks: hver maske du navnga, målt på trinnet betingelsen dens peker ut. En maske skrevet for en låst klokke måles på grunnlinjen; en skrevet for holdover eller en autonom klokke måles på holdoveren. Hver kontroll har sin grense, den målte verdien, marginen og tabellen den er overført fra. En maske som trenger en lengre registrering enn trinnet ga, er INCOMPLETE, aldri ekstrapolert; en som motoren ikke kan evaluere for registreringens sampleintervall, er NOT-EVALUATED med begrunnelse.
• holdover: den fraksjonelle frekvensforskyvningen systemet holdt (stigningstallet til en minste kvadraters linje gjennom holdoverens tidsfeil, i ns/s, som er milliarddeler), restavviket rundt den linjen, den største absolutte tidsfeilen og når den oppstod, og sprangene ved fjerningen.
• holdover_envelope: ePRTC-A-holdover-omhyllingskurven i ITU-T G.8272.1 tabell 3, ut fra locked_duration_days, med tidspunktet den først overskrides.
• budgets: tiden etter fjerningen da hvert tidsfeilbudsjett først overskrides.
• recovery: om |TE| kom inn i båndet og ble der i hviletiden, hvor lenge etter at GNSS kom tilbake det startet, toppverdien etter gjenopprettingen og det største sprang mellom påfølgende sampler under gjenopprettingen.
• curves: MTIE og TDEV for grunnlinje- og holdover-trinnene.
• verdicts: en oppsummering på ett ord per trinn.

Hvert tall oppgir enheten sin og hvor det kom fra, i rapportens units-blokk.

Ordene og grensene#

• Resultatet er målt mot masken. Maskene er overført fra ITU-T-anbefalinger som kan lastes ned fritt (de samme tabellene som typen telecom-timing, oppført i TELECOM-TIMING.md), og hver oppføring som anbefalingene overlater «for further study», er utelatt, ikke fylt inn. Kshana sier ikke at en klokke eller et system oppfyller eller er godkjent mot en anbefaling, og det gjør heller ikke rapporten.
• MODELLED. Trinnlogikken, linjetilpasningen og gjenopprettingsregelen er kontrollert på registreringer bygd fra formler der svarene er kjent før kjøringen; ingen laboratorie-holdover er skåret mot en ekstern uavhengig referanse, og ingen partner eller noe laboratorium har gått med på noe. Et tidslaboratorium ville være nødvendig før noe tall per klokkeklasse kunne løftes.
• Hva som ikke dekkes, oppgitt i hver rapport: om GNSS virkelig ble fjernet og gjenopprettet på de oppgitte tidspunktene; ethvert trinn operatøren ikke registrerte; masker definert gjennom et 0,1 Hz-filter for en registrering samplet saktere enn én gang i sekundet; instrumentets egen måleusikkerhet; og enhver prosedyre i anbefalingene utover en tidsfeilregistrering (temperaturprofiler, pakkenettbelastning).
• Gjenopprettingsbåndet er testens eget valg. Standarden på 100 ns er den maksimale absolutte tidsfeilen for en PRTC-A (ITU-T G.8272); det er en praktisk grense, ikke et krav i noen anbefaling for gjenoppretting.
• Ingen sendevei. Kshana leser filer. Den genererer ikke et signal, og å fjerne GNSS i et laboratorium gjøres med laboratoriets eget utstyr og under dets egen tillatelse.

Flater#

holdover-test er en scenariotype, så den kjører overalt der typer kjører: kshana <scenario.toml>, Rust-API-et (kshana::api::run_toml), Python-bindingen (kshana.run), WebAssembly- og npm-bygget (innebygd samples eller clock_log.text; filnøklene er ikke tilgjengelige der), MCP-serveren (run_scenario, bare innebygd innhold) og Kshana Studios scenariokjører. De to scenariofilene følger med (kshana example holdover-test-example).