Veiledning 2 — Klokkens holdover: hvor lenge kan du seile på egen kraft

Kind: clock · Scenario: scenarios/clock-holdover.toml (undervisningskopi: scenarios/clock.toml) · Vanskelighetsgrad: nybegynner · ~20 min

Til slutt har du kjørt en klokke-holdover med GNSS-signaler (Global Navigation Satellite System) nektet, lest tidskvalitetsmålet og forstått driftsloven √(q_wf·T) som forklarer hvorfor den optiske klokken holder lenger enn den på brikkenivå, med loven hentet fra NIST (det amerikanske National Institute of Standards and Technology), ikke funnet på.

Hva dette scenarioet er#

Når GNSS-signalene forsvinner, holder et system tiden på sin egen klokke om bord. Klokkens fase driver sakte, og når driften overstiger den operative tidsspesifikasjonen, er du ute av drift. Holdover er hvor lenge du holder deg innenfor spesifikasjonen etter GNSS-tap — det sentrale tallet for autonomi.

Scenarioet kjører en tidslinje på 2 h: 10 min GNSS-synkronisering, deretter 6600 s (1,83 h) nektet, mot en tidsspesifikasjon på 20 ns, samplet hvert 10 s. Det sammenligner to klokker på identisk kode med deres egne publiserte støy:

Kvante: en optisk strontium-gitterklokke, romsmål σ_y(1 s) = 1×10⁻¹⁵ (arXiv:1503,08457), et mål for en bakkedemonstrator, ikke flydd. σ_y(τ) er Allan-avviket, standardmålet for klokkens frekvensstabilitet ved midlingstid τ.
Klassisk: en Microchip SA.45s-atomklokke på brikkenivå (CSAC), σ_y(1 s) = 3×10⁻¹⁰ (datablad) — en kommersiell del i bruk.

Kjø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"])

Les oppsummeringen på én linje#

Med seed = 42, spesifikasjonen på 20 ns og utfallet 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 optiske klokken holder hele utfallet på 6600 s uten å bryte 20 ns. Dens 95-persentil av fasefeilen er 1.20e-4 ns, omtrent en titusendel av et nanosekund: den beveger seg knapt.
classical holdover 2610s — CSAC-en bryter spesifikasjonen på 20 ns ved ~2610 s, mindre enn halvparten av utfallet. Dens p95-fasefeil (19,7 ns) ligger rett ved spesifikasjonslinjen.
security n/a (no attack) — dette scenarioet setter ikke opp noe angrep, så det er ingenting å oppdage, og oppsummeringen skriver ikke ut et tall. JSON-en har likevel hver klokkes analytiske grense for spoof-detekterbarhet i fom.security (0,997 for den optiske klokken; 0,000 for CSAC-en, hvis egen seilingsstøy over vinduet allerede overstiger 20 ns), merket applicable: false i blokken figure_tiers. Å skåre deteksjon mot et ekte angrep er historien i veiledning 3.
integrity 1.000 — her er dette filterets selvkonsistens (andelen utfallssampler innenfor Kalman-filterets egen k-sigma-grense), ikke et horisontalt eller vertikalt beskyttelsesnivå for luftfart (HPL/VPL). Se docs/INTEGRITY.md.

Den ikke-sirkulære referansen: hvorfor 2610 s for CSAC-en?#

For en klokke med hvit frekvensmodulasjon (white-FM) vokser 1-σ-fasefeilen som σ_x(T) ≈ √(q_wf · T), der q_wf = σ_y(1 s)² har enheten s². Denne sammenhengen er fra NIST Special Publication 1065 (Riley, Handbook of Frequency Stability Analysis) — sammenhengene mellom σ_y(τ) og fase — den samme SP-1065-sammenhengen som tests/calibration.rs validerer motorens Allan-avvik mot til ~2 %.

For CSAC-en er q_wf = (3×10⁻¹⁰)² = 9×10⁻²⁰ s². Løs for tiden 1-σ-fasen når 20 ns = 2×10⁻⁸ s:

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

Motorens 2610 s er ikke den 1-σ-tiden, og skal ikke være det. holdover_s er det første punktet i 10 s-rutenettet (step_s = 10) der denne seedede realisasjonens absolutte fasefeil overstiger 20 ns (src/fom.rs). En tilfeldig vandrings første kryssing av et nivå kommer ofte langt før tiden 1-σ-omhyllingskurven når det nivået, og realisasjonen bærer også restfrekvensfeilen filteret sitter igjen med etter synkroniseringen på 600 s. Så loven fastsetter størrelsesorden, noen tusen sekunder for en klokke på 3×10⁻¹⁰ mot 20 ns, ikke den eksakte verdien. Testen krever et 2000–3200 s-bånd rundt den, ikke tallet.

Databladankrene selv er eksterne, sitert i scenarioets provenance-strenger: optisk Sr-gittermål 1×10⁻¹⁵ (arXiv:1503,08457); Microchip SA.45s CSAC 3×10⁻¹⁰ (datablad). Og den eksporterte adev_curve stemmer med databladets σ_y(τ) til ~2 % (tests/calibration.rs, NIST SP 1065). Plott den som et log-log-diagram «Clock stability (ADEV, Allan deviation)» i lekeplassen.

Hva testen fester#

tests/tutorials.rs::tutorial2_clock_holdover_holds:

quantum holdover >= classical holdover (den optiske klokken må holde minst like lenge),
quantum holdover ≈ 6600 s (holder hele utfallet),
classical holdover ∈ [2000, 3200] s — et toleransebånd rundt SP-1065 white-FM-størrelsen, ikke et magisk tall. Referansen er loven, ikke verdien.

Fallgruver og enheter#

Tidstall er i nanosekunder, aldri meter. (Posisjons-holdover er en annen pakke — se det inertielle avsnittet i veiledning 3.)
q_wf har enheten s² og er lik σ_y(1 s)². Det er broen fra et Allan-tall i et datablad til modellen.
Holdover er en nedre grense kvantisert til rutenettet (step_s). Ikke les for mye i den eksakte verdien; les båndet.
integrity her er filterets selvkonsistens, ikke integritet i luftfartens forstand.

Veien videre#

Nivå 2: stram inn threshold_ns fra 20 til 10 og se CSAC-holdoveren falle (2610 s → 1300 s, målt med exercises/tier2_sweep.py), eller bruk kind = "sweep" til å tabulere holdover mot CSAC-ens støynivå classical_q_wf (scenarios/sweep-clock-stability.toml: 25 punkter fra 10⁻²⁴ til 10⁻¹⁸ s², klassisk holdover 2610 s → 250 s).
Nivå 3: legg til runs = 200 for å gjøre dette om til et Monte Carlo-ensemble og les holdover-båndet [p05–p95] (scenarios/clock-ensemble.toml skriver ut classical holdover 844s [220-2130]).
Så avslutningsoppgaven: Veiledning 3 — Kvante mot klassisk robusthet.