Tidssynkronisering med hårdvara i loopen: dra ur antennen, poängsätt holdovern

Telekom- och elnätsoperatörer testar ett tidssynkroniseringssystem genom att ta bort dess GNSS och se vad klockan gör. Kshana gör inte det åt dem och rör inte deras utrustning. Den läser tidsfelsregistreringen som operatörens egna instrument producerade, delar upp den vid de två tider operatören anger och mäter varje steg mot offentliga ITU-T-masker. Scenariotypen är holdover-test; exempelscenarierna är scenarios/holdover-test-example.toml och scenarios/holdover-test-ptp4l.toml.

Det här är hårdvarusäkerhet steg 1: passivt, endast mottagning, ingen RF från Kshana (HARDWARE-SAFETY.md). Rådgivande programvara, inte typgodkänd utrustning. Ingen har betygsatt, godkänt eller granskat den här proceduren, och den säger ingenting om huruvida ett system klarar en rekommendation.

Proceduren#

Operatören utför fyra steg. Kshana utför inget av dem.

Två saker som operatören måste göra, eftersom Kshana inte kan:

• Ange de två tiderna. gnss_removed_s och gnss_restored_s är operatörens uppgift. Kshana upptäcker inte borttagningen i registreringen och verifierar inte tiderna. En felaktig tid flyttar stegens gränser och därmed resultatet.
• Använd samma klocka för registreringen och tiderna. För en klocklogg börjar tidsaxeln vid den första avläsningen, så de två tiderna anges i sekunder från loggens första rad.

Vad som ska registreras#

Vilken som helst av dessa, via de befintliga läsarna för clock_log (CLOCK-LOG-FORMATS.md):

Vad registreringen mäter spelar roll. En servologg (linuxptp, chrony) registrerar den offset som daemonen mätte och korrigerar: det är tidsfelet som återstår under servostyrning, inte en oberoende mätning av klockan mot UTC. Under holdover-steget i ett test som verkligen tar bort referensen visar en servologg fortfarande vad daemonen trodde, vilket kan skilja sig från det verkliga felet. En TICC eller annan räknare mot en oberoende referens är den starkare registreringen; ange vilken du använde när du rapporterar resultatet.

Scenariot#

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

Valfria nycklar: budgets (namn, max_abs_te_ns, källa; standardvärdena för telecom-timing när de saknas) och clock = "..." inuti [series.clock_log] för att välja en källa ur en logg som innehåller flera.

Vad rapporten innehåller#

• steps: för baslinjen, holdovern och återhämtningen, start och slut, antalet sampel samt medelvärde, rms, största värde och slutvärde för tidsfelet.
• masks: varje mask du namngav, mätt på det steg som dess villkor anger. En mask skriven för en låst klocka mäts på baslinjen; en skriven för holdover eller en självständig klocka mäts på holdovern. Varje kontroll har sin gräns, det uppmätta värdet, marginalen och tabellen den är avskriven från. En mask som behöver en längre registrering än steget gav är INCOMPLETE, aldrig extrapolerad; en som motorn inte kan utvärdera för registreringens samplingsintervall är NOT-EVALUATED med skälet angivet.
• holdover: den relativa frekvensoffset som systemet höll (lutningen på en minsta kvadrat-linje genom holdover-tidsfelet, i ns/s, vilket är miljarddelar), residualen kring den linjen, det största absoluta tidsfelet och när det inträffade, samt steget vid borttagningsögonblicket.
• holdover_envelope: ePRTC-A:s holdover-kurva enligt ITU-T G.8272.1 tabell 3, utifrån locked_duration_days, med tiden då den först överskrids.
• budgets: tiden efter borttagningen då varje tidsfelsbudget först överskrids.
• recovery: om |TE| kom in i bandet och stannade där under uppehållstiden, hur lång tid efter att GNSS återvänt det började, toppen efter återställningen och det största steget mellan på varandra följande sampel under återhämtningen.
• curves: MTIE och TDEV för baslinje- och holdover-stegen.
• verdicts: en sammanfattning på ett ord per steg.

Varje tal har sin enhet och sitt ursprung i rapportens units-block.

Orden och gränserna#

• Resultatet är uppmätt mot masken. Maskerna är avskrivna från fritt nedladdningsbara ITU-T-rekommendationer (samma tabeller som typen telecom-timing, listade i TELECOM-TIMING.md), och varje post som rekommendationerna lämnar "for further study" saknas, den är inte ifylld. Kshana säger inte att en klocka eller ett system klarar eller är godkänt mot en rekommendation, och det gör inte rapporten heller.
• MODELLED. Steglogiken, linjeanpassningen och återhämtningsregeln är kontrollerade på registreringar byggda av formler vars svar är kända före körningen; ingen laboratorie-holdover har poängsatts mot en oberoende extern referens, och ingen partner eller något laboratorium har gått med på något. Ett tidslaboratorium skulle behövas innan någon siffra per klockklass kunde lyftas upp.
• Vad som inte täcks, angivet i varje rapport: om GNSS verkligen togs bort och återställdes vid de angivna tiderna; varje steg som operatören inte registrerade; masker definierade genom ett filter på 0,1 Hz för en registrering samplad långsammare än en gång per sekund; instrumentets egen mätosäkerhet; och varje procedur i en rekommendation utöver en tidsfelsregistrering (temperaturprofiler, last i paketnät).
• Återhämtningsbandet är testets eget val. Standardvärdet 100 ns är det största absoluta tidsfelet för en PRTC-A (ITU-T G.8272); det är en praktisk linje, inte ett krav i någon rekommendation för återhämtning.
• Ingen sändningsväg. Kshana läser filer. Den genererar ingen signal, och att ta bort GNSS i ett laboratorium görs med laboratoriets egen utrustning och under dess eget tillstånd.

Ytor#

holdover-test är en scenariotyp, så den körs överallt där typer körs: kshana <scenario.toml>, Rust-API:et (kshana::api::run_toml), Python-bindningen (kshana.run), bygget för WebAssembly och npm (inbäddad samples eller clock_log.text; filnycklarna finns inte där), MCP-servern (run_scenario, endast inbäddat innehåll) och Kshana Studios scenariokörare. De två scenariofilerna medföljer (kshana example holdover-test-example).