Handledning 2 — Klock-holdover: hur länge kan du glida

Kind: clock · Scenario: scenarios/clock-holdover.toml (undervisningskopia: scenarios/clock.toml) · Svårighetsgrad: nybörjare · ~20 min

I slutet har du kört en klock-holdover med GNSS-signaler (Global Navigation Satellite System) nekade, läst timing-kvalitetsmåttet och förstått driftlagen √(q_wf·T) som förklarar varför den optiska klockan håller längre än den i chipskala, med en lag hämtad från NIST (USA:s National Institute of Standards and Technology) och inte påhittad.

Vad det här scenariot är#

När GNSS-signalerna försvinner håller ett system tiden på sin egen inbyggda klocka. Klockans fas driver långsamt, och när driften överstiger den operativa tidsspecifikationen är du ur drift. Holdover är hur länge du håller dig inom specifikationen efter GNSS-förlust — det centrala kvalitetsmåttet för autonomi.

Scenariot kör en tidslinje på 2 h: 10 min GNSS-synkronisering, därefter 6600 s (1,83 h) nekad, mot en tidsspecifikation på 20 ns, samplad var 10:e s. Det jämför två klockor på identisk kod med sitt eget publicerade brus:

Quantum: en optisk strontiumgitterklocka, mål för rymden σ_y(1 s) = 1×10⁻¹⁵ (arXiv:1503,08457), ett markdemonstratormål, inte flugen. σ_y(τ) är Allan-deviationen, standardmåttet på klockans frekvensstabilitet vid medelvärdestiden τ.
Classical: en atomklocka i chipskala (CSAC) från Microchip SA.45s, σ_y(1 s) = 3×10⁻¹⁰ (datablad) — en kommersiell del i drift.

Kör den#

cargo run -- scenarios/clock-holdover.toml

Python:

import json, kshana
r = json.loads(kshana.run(open("scenarios/clock-holdover.toml").read()))
print(r["quantum"]["fom"]["holdover_s"], r["classical"]["fom"]["holdover_s"])

Läs enradssammanfattningen#

Med seed = 42, specifikationen på 20 ns och avbrottet på 6600 s:

scenario 5ba83a232b94 | quantum holdover 6600s p95 1.20e-4ns integrity 1.000 security n/a (no attack) | classical holdover 2610s p95 19.7ns integrity 1.000 security n/a (no attack)

quantum holdover 6600s — den optiska klockan klarar hela avbrottet på 6600 s utan att överskrida 20 ns. Dess 95:e percentil av fasfel är 1.20e-4 ns, ungefär en tiotusendels nanosekund: den rör sig knappt.
classical holdover 2610s — CSAC överskrider specifikationen på 20 ns vid ~2610 s, mindre än halva avbrottet. Dess p95-fasfel (19,7 ns) ligger precis vid specifikationslinjen.
security n/a (no attack) — det här scenariot konfigurerar ingen attack, så det finns inget att detektera och sammanfattningen skriver inte ut något tal. JSON-utdata innehåller ändå varje klockas analytiska gräns för spoofing-detekterbarhet i fom.security (0,997 för den optiska klockan; 0,000 för CSAC, vars eget glidbrus över fönstret redan överstiger 20 ns), markerad applicable: false i blocket figure_tiers. Att poängsätta detektion mot en verklig attack är historien i Handledning 3.
integrity 1.000 — här är detta filtrets självkonsistens (andelen avbrottssampel inom Kalman-filtrets eget k-sigma-gränsvärde), inte en horisontell eller vertikal skyddsnivå (HPL/VPL) inom flyget. Se docs/INTEGRITY.md.

Den icke-cirkulära referensen: varför 2610 s för CSAC?#

För en klocka med vit frekvensmodulering (white-FM) växer 1-σ-fasfelet som σ_x(T) ≈ √(q_wf · T), där q_wf = σ_y(1 s)² har enheten s². Det sambandet kommer från NIST Special Publication 1065 (Riley, Handbook of Frequency Stability Analysis) — sambanden mellan σ_y(τ) och fas — samma SP-1065-samband som tests/calibration.rs validerar motorns Allan-deviation mot inom ~2 %.

För CSAC gäller q_wf = (3×10⁻¹⁰)² = 9×10⁻²⁰ s². Lös ut tiden då 1-σ-fasen når 20 ns = 2×10⁻⁸ s:

T ≈ (2e-8)^2 / 9e-20 = 4e-16 / 9e-20 ≈ 4444 s   (1-sigma crossing)

Motorns 2610 s är inte den 1-σ-tiden, och ska inte vara det. holdover_s är den första rutnätspunkten på 10 s (step_s = 10) där just den här slumpade realiseringens absoluta fasfel överstiger 20 ns (src/fom.rs). En slumpvandrings första passage av en nivå inträffar ofta långt före den tid då dess 1-σ-hölje når nivån, och realiseringen bär dessutom det resterande frekvensfel som filtret har kvar efter synkroniseringen på 600 s. Så lagen fastställer skalan, några tusen sekunder för en klocka på 3×10⁻¹⁰ mot 20 ns, inte det exakta värdet. Testet kontrollerar ett band på 2000–3200 s kring det, inte själva talet.

Själva databladets ankarvärden är externa, angivna i scenariots strängar provenance: optiskt Sr-gittermål 1×10⁻¹⁵ (arXiv:1503,08457); Microchip SA.45s CSAC 3×10⁻¹⁰ (datablad). Och den exporterade adev_curve stämmer med databladets σ_y(τ) inom ~2 % (tests/calibration.rs, NIST SP 1065). Rita den som ett log-log-diagram "Clock stability (ADEV, Allan deviation)" på lekplatsen.

Vad testet fastställer#

tests/tutorials.rs::tutorial2_clock_holdover_holds:

quantum holdover >= classical holdover (den optiska klockan måste hålla minst lika länge),
quantum holdover ≈ 6600 s (klarar hela avbrottet),
classical holdover ∈ [2000, 3200] s – ett toleransband kring SP-1065-skalan för white-FM, inte ett magiskt tal. Den oberoende referensen är lagen, inte värdet.

Fallgropar och enheter#

Tidssynkroniseringsvärden anges i nanosekunder, aldrig i meter. (Holdover för position är ett annat paket – se avsnittet om tröghet i handledning 3.)
q_wf har enheten s² och motsvarar σ_y(1 s)². Det är bryggan från ett Allan-tal i ett datablad till modellen.
Holdover är en nedre gräns kvantiserad till rutnätet (step_s). Läs inte in för mycket i det exakta värdet; läs av bandet.
integrity avser här filtrets egen konsistens, inte integritet i flygtillämpning.

Vad händer härnäst#

Nivå 2: skärp threshold_ns från 20 till 10 och se hur CSAC-holdover sjunker (2610 s → 1300 s, uppmätt med exercises/tier2_sweep.py), eller använd kind = "sweep" för att tabellera holdover mot CSAC-brusnivån classical_q_wf (scenarios/sweep-clock-stability.toml: 25 punkter från 10⁻²⁴ till 10⁻¹⁸ s², klassisk holdover 2610 s → 250 s).
Nivå 3: lägg till runs = 200 för att göra detta till ett Monte Carlo-ensemble och läs av holdover-bandet [p05–p95] (scenarios/clock-ensemble.toml skriver ut classical holdover 844s [220-2130]).
Sedan slutprovet: Handledning 3 – Kvant mot klassisk resiliens.