Timing hardware-in-the-loop: træk antennen, og scor holdoveren

Telecom- og energioperatører tester et tidssynkroniseringssystem ved at tage dets GNSS væk og se, hvad uret gør. Kshana gør ikke det for dem og rører ikke deres udstyr. Det læser den tidsfejlsoptegnelse, som operatørens egne instrumenter har frembragt, deler den ved de to tidspunkter, operatøren angiver, og måler hvert trin mod offentlige ITU-T-masker. Scenarietypen er holdover-test; eksempelscenarierne er scenarios/holdover-test-example.toml og scenarios/holdover-test-ptp4l.toml.

Dette er hardwaresikkerhedens trin 1: passivt, kun modtagelse, ingen RF fra Kshana (HARDWARE-SAFETY.md). Vejledende software, ikke typegodkendt udstyr. Ingen har vurderet, godkendt eller gennemgået denne fremgangsmåde, og den siger intet om, hvorvidt et system lever op til en anbefaling.

Fremgangsmåden#

Operatøren udfører fire trin. Kshana udfører ingen af dem.

To ting, operatøren skal gøre, fordi Kshana ikke kan:

• Angiv de to tidspunkter. gnss_removed_s og gnss_restored_s er operatørens erklæring. Kshana opdager ikke fjernelsen ud fra optegnelsen og verificerer ikke tidspunkterne. Et forkert tidspunkt flytter trinnenes grænser og dermed resultatet.
• Brug det samme ur til optegnelsen og tidspunkterne. For en urlog starter tidsaksen ved den første aflæsning, så de to tidspunkter er sekunder fra logens første linje.

Hvad der skal optages#

Et hvilket som helst af disse, gennem de eksisterende læsere i clock_log (CLOCK-LOG-FORMATS.md):

Det, optegnelsen måler, betyder noget. En servolog (linuxptp, chrony) registrerer den forskydning, som dæmonen målte og er ved at korrigere: det er den tidsfejl, der er tilbage under servostyring, ikke en uafhængig måling af uret mod UTC. Under holdover-trinnet i en test, der virkelig fjerner referencen, viser en servolog stadig, hvad dæmonen mente, hvilket kan afvige fra den sande fejl. En TICC eller en anden tæller mod en uafhængig reference er den stærkere optegnelse; angiv, hvilken du brugte, når du rapporterer resultatet.

Scenariet#

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øgler: budgets (navn, max_abs_te_ns, kilde; standardværdierne for telecom-timing, når de mangler) og clock = "..." inde i [series.clock_log] for at udvælge én kilde fra en log, der rummer flere.

Hvad rapporten indeholder#

• steps: for baseline, holdover og genopretning start og slut, antal sampler samt middelværdien, rms, den største og slutværdien af tidsfejlen.
• masks: hver maske, du navngav, målt på det trin, dens betingelse angiver. En maske, der er skrevet til et låst ur, måles på baseline; en, der er skrevet til holdover eller et autonomt ur, måles på holdoveren. Hver kontrol har sin grænse, den målte værdi, marginen og den tabel, den er afskrevet fra. En maske, der kræver en længere optegnelse, end trinnet gav, er INCOMPLETE og bliver aldrig ekstrapoleret; en, som motoren ikke kan evaluere for optegnelsens sampleinterval, er NOT-EVALUATED med begrundelsen.
• holdover: den brøkdelsfrekvensforskydning, som systemet holdt (hældningen på en mindste kvadraters linje gennem holdoverens tidsfejl, i ns/s, hvilket er dele pr. milliard), resten omkring den linje, den største absolutte tidsfejl og hvornår den opstod, samt trinnet i det øjeblik, referencen blev fjernet.
• holdover_envelope: ePRTC-A-holdoverindhyllingen i ITU-T G.8272.1 Tabel 3, ud fra locked_duration_days, med det tidspunkt, hvor den første gang overskrides.
• budgets: tiden efter fjernelsen, hvor hvert tidsfejlsbudget første gang overskrides.
• recovery: om |TE| kom inden for båndet og blev der i opholdstiden, hvor længe efter GNSS vendte tilbage det begyndte, spidsen efter genoprettelsen og det største trin mellem på hinanden følgende sampler under genopretningen.
• curves: MTIE og TDEV for baseline- og holdovertrinnene.
• verdicts: en opsummering på ét ord pr. trin.

Hvert tal bærer sin enhed og hvor det kom fra, i rapportens units-blok.

Ordene og grænserne#

• Resultatet er målt mod masken. Maskerne er afskrevet fra frit tilgængelige ITU-T-anbefalinger (de samme tabeller som typen telecom-timing, opført i TELECOM-TIMING.md), og hver post, som anbefalingerne lader stå "for further study", er udeladt og ikke udfyldt. Kshana siger ikke, at et ur eller et system lever op til eller er godkendt i forhold til en anbefaling, og det gør rapporten heller ikke.
• MODELLED. Trinlogikken, linjetilpasningen og genopretningsreglen er kontrolleret på optegnelser bygget ud fra formler, hvis svar er kendt før kørslen; ingen laboratorieholdover er scoret mod en ekstern uafhængig reference, og ingen partner eller noget laboratorium har aftalt noget. Der ville være brug for et tidslaboratorium, før noget tal for en urklasse kan opgraderes.
• Hvad der ikke er dækket, angivet i hver rapport: om GNSS virkelig blev fjernet og genoprettet på de angivne tidspunkter; ethvert trin, operatøren ikke optog; masker defineret gennem et filter på 0,1 Hz for en optegnelse, der er samplet langsommere end én gang i sekundet; instrumentets egen måleusikkerhed; og enhver procedure i en anbefaling ud over en tidsfejlsoptegnelse (temperaturprofiler, belastning af pakkenetværk).
• Genopretningsbåndet er testens eget valg. Standarden på 100 ns er den maksimale absolutte tidsfejl for en PRTC-A (ITU-T G.8272); det er en praktisk linje og ikke et krav i nogen anbefaling til genopretning.
• Ingen sendevej. Kshana læser filer. Det genererer ikke et signal, og fjernelse af GNSS i et laboratorium sker med laboratoriets eget udstyr og under dets egen tilladelse.

Flader#

holdover-test er en scenarietype, så den kører overalt, hvor typer kører: kshana <scenario.toml>, Rust-API'et (kshana::api::run_toml), Python-bindingen (kshana.run), WebAssembly- og npm-builden (inline samples eller clock_log.text; filnøglerne er ikke tilgængelige dér), MCP-serveren (run_scenario, kun inline indhold) og Kshana Studios scenarieafvikler. De to scenariefiler er medfølgende (kshana example holdover-test-example).