• Øv på minuttet GNSS går i svart
• Nytt i 0,40, Nytt i 0,39, Nytt i 0,38 og 0,38 i dybden: jammertest-skåring, mottakerens egne flagg, maskininndata, tidssynkronisering og holdover, standardpakker, LunaNet AFS, laboratorierunden, kshana-bench, observatoriet, eksportører, optikk, rombrukernavigasjon og månens infrastruktur
• Kshana Studio og hver Studio-side
• Funksjoner: tabellen over områder, hver scenariotype etter familie, hver kommando, hver flate
• Hvordan en kjøring fungerer, Oppdrag
• Evidens: registeret, funksjonsdomener
• Installasjon, Arkitektur (og diagrammene), AI-assistent
• Utgaver, Forskning, Siter, Lisens
• Referanse: bruk, scenarioformat, utdata, depotstruktur, FAQ, feilsøking, versjonering, veikart, bidrag, dokumentasjon

Kjør hvilken som helst av dem med kshana example <scenario> > s.toml && kshana s.toml: scenarioene er l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour og leo-pass-iridium.

Alle fire er oppdiktede data og veiledende: de viser formatet og oppførselen til programvaren, ikke hvordan noen mottaker eller noe system presterer mot interferens. Kjør den første med kshana receiver-trust examples/maritime-trust/session.toml, den andre med kshana route-exposure på eksemplene i examples/interference-map/, den tredje med kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (bare til trening: aldri mat den inn i levende navigasjonsutstyr), og den fjerde som i docs/EVIDENCE-PACKS.md.

Hele detaljeringen domene for domene følger; for et modenhetsregister per funksjon, se docs/CAPABILITY.md og docs/VALIDATION.md.

Hver funksjon er tilgjengelig som et Rust-API, et kjørbart scenario kind eller begge deler. Modenhet per funksjon — validert, kjørbar eller bibliotek — føres i docs/CAPABILITY.md. En maskinkontrollert verifikasjonsmatrise (src/verification.rs) gjengir kryssreferansen krav → modul → test → uavhengig referanse → status, med enhetstestede ærlighetsinvarianter som kun tillater merkelappen validert der en uavhengig ekstern referanse støtter den — og som registrerer maskinvare- og PA-funksjonene (produktsikring) som Kshana bevisst ikke tilbyr.

Resultater#

Hvert scenario sammenligner en kvantesensor med sin klassiske motpart gjennom et GNSS-bortfall på ~1,8 t. Tallene kan gjengis (scenario + seed + version).

_{Hva kvantesensorer gir når GNSS er borte — clock-holdover · seed 42 · tegnet med motor 0.40.0, og hver figur ovenfor kontrolleres på nytt mot gjeldende motor ved hvert bygg av tests/published_figures_still_reproduce.rs · SVG}

Fordelen er avhengig av bortfallets varighet og av vibrasjon, med et eksplisitt balansepunkt der klassisk vinner — vist ærlig over stigen for teknologisk modenhet (tallene for optiske klokker er mål for bakkedemonstratorer; ingen strontium-optisk klokke har fløyet):

_{Krysningspunkt for robusthet, kvante mot klassisk — TRL-stige for klokkens holdover (øverst) · kart over inertialfordel med balansekontur (nederst). Kan regenereres via cargo run --release --bin crossover_study.}

Posisjonsfeil ved dødregning under et GNSS-bortfall: kvantesensoren (blå) holder seg flat nær spesifikasjonen; den klassiske sensoren (rød) divergerer til titalls kilometer. Generert av Kshana fra scenarios/imu-deadreckoning.toml.

Sluttsteinen viser fusjonstesen: optisk tidsoverføring mellom satellitter holder selv en klassisk klokke låst og isolerer den inertiale sensoren som det svake leddet i den klassiske pakken — altså kvanteinertial og optisk tidssynkronisering sammen.

Klokkens holdover gjennom et GNSS-bortfall: den optiske klokken (blå) holder seg innenfor spesifikasjonen på 20 ns under hele frittløpet; klokken i brikkeformat (rød) bryter den underveis. Generert av Kshana fra scenarios/clock-holdover.toml.

Et ytterligere scenario, orbit-gnss-challenged.toml, utleder GNSS-tilgjengelighet fra banegeometri i stedet for håndskrevne vinduer: et romfartøy inne i GNSS-skallet propageres mot en GPS-lignende Walker-konstellasjon, og antallet synlige satellitter (fri sikt, jordokkultasjon, elevasjonsmaske) bestemmer posisjonsbestemmelsens tilstand i hvert trinn. Over et døgn har brukeren posisjonsbestemmelse bare ~59 % av tiden; kvanteklokken holder en tidsløsning på 5 ns gjennom hvert opphold (tilgjengelighet 1.0), klokken i brikkeformat bare ~0.83.

Tidsfeil over et døgn med GNSS-tilgjengelighet utledet fra banegeometri: antallet synlige satellitter (fri sikt, jordokkultasjon, elevasjonsmaske) bestemmer posisjonsbestemmelsens tilstand i hvert trinn, slik at klokken må gå fritt gjennom hvert opphold — den optiske klokken holder spesifikasjonen på 5 ns mens klokken i brikkeformat bryter den. Generert av Kshana fra scenarios/orbit-gnss-challenged.toml.

Konstellasjonen kan også oppgis som reelle to-linjers elementsett (TLE). Et fullt TLE (linje 1 + linje 2) propageres med den fulle SGP4/SDP4-modellen — inkludert atmosfærisk luftmotstand og termene for måne-sol i dypt rom og for resonans på 12 t / 24 t som betyr noe for GNSS-baner på ~12 t — validert mot de offisielle AIAA 2006-6753-vektorene til et verste tilfelle på ≈ 4 mm. scenarios/orbit-sgp4-gps.toml leveres med et reelt Celestrak-snapshot av gps-ops av den operative GPS-konstellasjonen (2021-07-28, 30 satellitter) og krever gyldige TLE-kontrollsummer — to-linjers elementsett er åpne data fra katalogen til US Space Force / 18th Space Defense Squadron, videredistribuert av Celestrak (Dr T. S. Kelso, celestrak.org); oppdater med scripts/fetch_tles.sh. En blokk med bare linje 2 beholder den analytiske propageringen for to legemer (scenarios/orbit-real-tle.toml); de to formene kan blandes i én konstellasjon. En konstellasjon kan like godt bygges fra en blokk med RINEX-3 GPS-poster for kringkastet efemeride — formatet en mottaker dekoder — propagert med IS-GPS-200-brukeralgoritmen og ført gjennom den samme geometrien (scenarios/orbit-rinex.toml).

Hva den er og ikke er#

Den er: en deterministisk motor med få avhengigheter som spenner over hele PNT-stakken — banegeometri, inertialnavigasjon, GNSS/INS-fusjon, integritet, klokker og tidssynkronisering. Den kjører et scenario (ofte et GNSS-bortfall), utvikler kalibrerte feilmodeller for sensorer gjennom en passende estimator og scorer resultatet mot de operative kvalitetsmålene — og gir et reproduserbart JSON-resultat (JavaScript Object Notation) og et SVG-diagram, fra et Rust-bibliotek, et kommandolinjegrensesnitt (CLI), en Python-utvidelse, en WebAssembly-modul i nettleseren, en Model Context Protocol (MCP)-server for AI-agenter eller en programtillegg for JetBrains IDE (integrert utviklingsmiljø).

Den er ikke: flymaskinvare, en utforming av kvantenyttelast, en full GNSS-signalmottaker, en simulator for radiofrekvenssignaler (RF) eller en maskinvare-i-løkken-rigg, eller et sertifisert avionikkprodukt — og den erstatter ikke MATLAB/Simulink, STK (Systems Tool Kit) eller Orekit; den står ved siden av dem og utveksler filer med dem. Troverdigheten til kvantemaskinvare kommer fra publiserte feilmodeller, ikke fra dette verktøyet. Den detaljerte modenheten til hver funksjon er dokumentert i docs/CAPABILITY.md.

Den er (ennå) ikke: en full fysikkmotor for atominterferometri (de fleste kvantesensorer bruker publiserte Allan-/støybudsjettkoeffisienter; akselerometeret med CAI (kaldatominterferometer) har et førsteprinsipplag — Mach–Zehnder-fase, projeksjonsstøy, kontrastavtak og vibrasjonskobling, pluss Coriolis- og lysforskyvningssystematikk — men bølgefrontsystematikk og oppløsning av fringe-flertydighet forblir et veikartlag på P2 (veikartfase 2, kvantefysikklaget), se ROADMAP.md og docs/QUANTUM-MODELS.md); en sertifisert eller maskinvarebasert GNSS-mottaker (den løser en PVT-posisjonsbestemmelse (posisjon, hastighet og tid) i enkeltpunkt fra reelle RINEX-kodeobservasjoner (Receiver Independent Exchange Format) — validert på reelle IGS-data (International GNSS Service) — og IQ-laget (kshana iq, siden 0.31.0) innhenter og sporer innspilte eller genererte basebåndsampler i programvare, som en analysemottaker: det styrer ikke radiomaskinvare og sender ikke, er ikke en sertifisert mottaker og gjør ingen posisjonsbestemmelse med bærebølgefase (RTK eller PPP)); eller en full suite for oppdragsutforming (den har byggeklosser for Lambert / porkchop / manøver / banebestemmelse, men er laget for ytelsessimulering over GMAT (General Mission Analysis Tool)/Orekit, ikke en erstatning). Å eie denne avgrensningen er bevisst. Hvis du trenger førsteprinsippbudsjetter for feil i kaldatominterferometre (for eksempel validering på CARIOQA-PMP-nivå — Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation — eller i X-37B-stil), se P2-veikartet og ta kontakt for å samarbeide.

Validering, reproduserbarhet og ærlighet#

• Hvert støyledd er kalibrert mot en publisert, sitert verdi og validert mot den vanlige sammenhengen (Allan-avvik for klokker; Groves' feilvekst ved dødregning for inertial; konverteringen fra tidssynkronisering til avstandsmåling for tidsoverføring). Status per ledd føres i docs/VALIDATION.md som validated eller not modeled — ingenting presenteres som validert som ikke er det.
• Reproduserbar fra grunnen av: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh håndhever det; kvante- og klassiske kjøringer bruker uavhengige seeder slik at støyen deres er ukorrelert.
• Modenheten oppgis ærlig: tallene for optiske klokker og optiske linker er mål / resultater fra bakkedemonstratorer, ikke fløyet.

Bevismerkelappen på hvert tall#

Hvert tall og hver tabell en kjøring skriver, sier hvor langt det kan stoles på, og hvilke registerrader det hviler på. Resultat-JSON har en evidence-nøkkel, diagram-SVG-en en linje under plottet (og et <metadata id="kshana-evidence">-element), og CSV-tabellen har # evidence:-kommentarlinjer foran (les dem med comment='#'). Den navngir et nivå, VALIDATED, MODELLED eller PARTNER, og id-ene (VM- og åtte heksadesimale sifre) til de verifikasjonsmatriserradene kjøringen brukte. Nivået er det svakeste av disse radene, så en kjøring som støtter seg på én modellert rad, merkes MODELLED uansett hvor mange validerte rader som står ved siden av; merkelappen kan aldri hevde mer enn registeret gjør. Rader, statuser og id-er leses fra matrisen og skrives ikke for hånd (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), og tests/evidence_labels_doc_sync.rs feiler hvis et tall mangler merkelapp eller en merkelapp ikke stemmer med matrisen.

Validering på et blikk#

Hver rad håndheves av en navngitt test i CI. Denne tabellen er et utvalg av høydepunkter; den fulle maskinkontrollerte matrisen er 401 rader — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), med det fullstendige beviset (og hva som ærlig talt ikke er validert ennå) i docs/VALIDATION.md og artefakten kshana-validation-summary.html for hver utgivelse (generert av cargo run --bin validation_report, SLSA-attestert — Supply-chain Levels for Software Artifacts).

Kolonnen Status oppgir slaget evidens, i tråd med valideringsstigen ovenfor: VALIDATED = kontrollert mot en uavhengig ekstern referanse (reelle data, et uavhengig bibliotek eller publiserte referansevektorer); MODELLED = kontrollert mot analytisk fasit eller simuleringens egenkonsistens (uten uavhengig eksternt datasett). VALIDATED beskriver metoden for kontroll, ikke bestått/ikke bestått — en ærlig bom mot en reell ekstern referanse forblir VALIDATED, mens en sammenligning som ingen matriserad navngir som referanse (LRO — Lunar Reconnaissance Orbiter — tilpasningen ovenfor) vises som MODELLED. CI-rader er prosessvern, ikke kvalitetsmål. Noen få øyer med reelle data (den målte cesiumklokken, Stable32 PHASE.DAT og OPS-SAT/ICGEM-kontrollene der rådataene ikke har lisens for videredistribusjon) er datastyrte: testen skriver ut et hoppvarsel og forblir grønn når inndataene mangler, og de offentlige referansetallene er sjekket inn under tests/fixtures/. Gjenskap rådataene med det tilhørende scripts/fetch_*.sh.

_{Hvordan en funksjon får merkelappen sin — den CI-håndhevede invarianten: ingen ekstern uavhengig referanse ⇒ kan ikke være Validated · SVG}

_{Øverst: hver Validated-rad støttes av et eksternt datasett, per konstruksjon. Nederst: SGP4 stemmer overens med den offisielle referansen i hvert regime (verst 4,12 mm). SVG · SVG}

_{176 validert · 221 modellert · 4 partner — SVG}

import json, kshana

toml = open("clock-holdover.toml").read()
result = json.loads(kshana.run(toml))
print(kshana.version(), result["quantum"]["fom"]["holdover_s"], result["classical"]["fom"]["holdover_s"])
# 0.40.0 6600.0 2610.0

Ved siden av run tilbyr modulen run_full (JSON, SVG og enlinjesammendraget på én gang), run_typed, validate_toml, list_kinds / scenario_kinds og error_kind; se docs/PYTHON_API.md.

npm-pakken er hele motoren kompilert til WebAssembly. I Node.js gir du binærfilen til initSync; i en nettleser henter await init() den (se README.npm.md).

import { readFileSync } from "node:fs";
import { createRequire } from "node:module";
import { initSync, run, summary, version } from "kshana";

const wasm = createRequire(import.meta.url).resolve("kshana/kshana_bg.wasm");
initSync({ module: readFileSync(wasm) });

const toml = readFileSync("clock-holdover.toml", "utf8");
const result = JSON.parse(run(toml));
console.log(version(), result.quantum.fom.holdover_s, result.classical.fom.holdover_s);
// 0.40.0 6600 2610
console.log(summary(toml));

Én motor, mange inngangsdører. En enkelt Rust-kjerne (kshana) kjører hvert scenario, nådd gjennom en CLI, en Python-utvidelse, en WebAssembly-modul i nettleseren, en MCP-server for AI-agenter og et JetBrains IDE-programtillegg — som alle munner ut i én api::run_toml-dispatch. Inne i den kobles sensorpakkene til et felles grensesnitt for feilmodeller; ved siden av dem ligger et referansesystemlag (IAU 2006/2000A presesjon–nutasjon og den CIO-baserte GCRS↔ITRS-reduksjonen), et astrodynamikk-/numerisk lag (analytisk SGP4/SDP4 og en numerisk Cowell-propagator med sin EGM2008-/perturbasjonskraftmodell, manøverutforming og banebestemmelse), et integritets-/GNSS-lag (RAIM/ARAIM, SBAS, måledomenet, jamming, cislunar), et fusjons-/alt-PNT-lag (GNSS/INS-estimatorene og kartsammenstillerne for tyngde/terreng/magnetfelt), et lag for dypt rom og Månen (radiometrisk Mars-PNT og månens PNT-suite, med evidensnivået for hver del i matrisen — LTC-tid, VLBI, felles OD+klokke, realisering av referansesystem, tjenestevolum, differensiell PNT, interoperabilitet), et oppdragsanalyselag (budsjetter for oppskyting / innstigning / dekning / peking / overflyvning / link og romværmiljøet) og det åpne laget for robusthets- og maskinlæringsstudier (RPCF-robusthetsscoring, optimismegapet for RF-forstyrrelser og demonstratoren for kvanteaktivert PNT) hvis reproduserbare artefakter bygger på de validerte kjernene.

To frittstående crater utenfor workspace står ved siden av kjernen — mcp/kshana-mcp (MCP-serveren, bygget på edition-2024-SDK-en rmcp) og xval/anise-frames (kryssjekken av ANISE/SPICE-referansesystemer, som trekker inn avhengigheter under MPL-2.0 (Mozilla Public License 2,0)) — holdt utenfor avhengighetsgrafen til den publiserte craten, Cargo.lock, lisensporten og MSRV-bygget (minste støttede Rust-versjon) av listen exclude i rotens Cargo.toml. JetBrains-programtillegget (ide/jetbrains) er et eget Kotlin-prosjekt. Se docs/ARCHITECTURE.md for hele settet med diagrammer.

De gjengitte diagrammene (motorflyt, modulkart, distribusjon) står i docs/ARCHITECTURE.md.

Scenarioer og rapporter

Eksport og interoperabilitet

Mottaker- og fartøytillit

GNSS IQ (filer i arbeidsmappen; av i HTTP-modus)

Compliance-kartlegging

Benchmark

Hva Kshana Pro bygger på. Hver del av Pro arbeider ut fra den åpne motoren og lar den stå uendret:

• Optimereren for utforming, usikkerhetsstudien og oppdragsdossieret kjører scenarioer for den åpne motoren gjennom motorens offentlige grensesnitt og beregner hvert tall fra resultatene av kjøringene. Hvert resultat beholder nivået VALIDATED, MODELLED eller PARTNER som den åpne motoren ga hvert tall, aldri et høyere.
• Digitale tvillinger av klokker bruker den åpne motorens klokkemodell og dens estimator for Allan-avvik: en tvilling kalibreres mot enhetens publiserte Allan-budsjett og kontrolleres deretter ved å estimere tvillingens Allan-avvik med den åpne estimatoren.
• Avveiningsstudier kjører hvert arkitekturalternativ som et scenario for den åpne motoren, uendret, og rangerer alternativene på et kvalitetsmål lest fra resultatet av hver kjøring.
• Kampanjefølging leser tallene sine fra resultatene av kjøringer i den åpne motoren av scenarioene i en pakke, og sammenligner dem med den forrige kjøringen som besto.
• Spektrumsameksistens leser hvert fysiske tall fra kjøringer i den åpne motoren av slagene leo-signal og constellation-design, og legger bare til summen over satellittene i sikte og rangeringen av planene.
• Jobbtjenesten på egen server kjører åpne scenarioer og Pro-scenarioer gjennom den samme motoren og lagrer hvert resultat slik kjøringen returnerte det.
• Bevispakker registrerer, for hver kjøring, scenariohashen som den åpne motoren stempler på resultatet, slik at et tall i en pakke kan gjengis ved å kjøre scenarioet på nytt.
• Verktøy for systemutvikling og programmer. Kshana Pros verktøy for modellbasert systemutvikling (MBSE) og programmer kontrollerer et programs krav mot kjøringer av den åpne motoren: det importerer krav som kommaseparerte verdier (CSV), eller som en dokumentert delmengde av Requirements Interchange Format (ReqIF) eller av tekst i Systems Modeling Language versjon 2 (SysML v2), evaluerer hvert akseptkriterium, med enhet, mot verdiene en kjøring skrev, og lager en verifikasjonskryssreferansematrise (VCRM), en SysML v2-modell, en rapport om endringspåvirkning og en frakoblet bevispakke. Det kjører ingenting på nytt og beregner ingenting på nytt, og leser bare det den åpne motoren publiserer: hver kjørings result.json (feltene et kriterium navngir, enhetene deres, reproduserbarhetsstempelet med scenariohash, seed, motorversjon og skjemaversjon, og kjøringens merkelapp og nivåer for tallene), dens report.json (slag, reproduserbarhetspost og funksjonsmerkelapper), scenariofilen (hash, slag, seed og parametere), skjemaet for feltenheter (hvert felts enhet, proveniens og evidensnivå) og verifikasjonsmatrisen (hver funksjons merkelapp VALIDATED, MODELLED eller PARTNER).

Støtte og profesjonelle tjenester#

Kshana er gratis og åpen kildekode under AGPL-3.0 og profesjonelt utviklet og vedlikeholdt av Ashforde® OÜ (Estland). Den åpne motoren er komplett og kan brukes alene. For organisasjoner som trenger mer, tilbyr Ashforde® OÜ:

• Kommersiell støtte og integrasjon — å bygge Kshana inn i verktøykjeden din, skreddersydde scenarioer og prioriterte rettelser.
• Egne sensormodeller — kalibrert mot maskinvaren din, inkludert eksportsensitive robusthetsmodeller som vedlikeholdes i et privat overlegg.
• Kshana Pro — proprietære verktøy for modellbasert systemutvikling (MBSE) og programmer som kontrollerer et programs krav mot kjøringer av den åpne motoren og lager en verifikasjonskryssreferansematrise (VCRM), en modell i Systems Modeling Language versjon 2 (SysML v2), en rapport om endringspåvirkning og en frakoblet bevispakke. Det kjører ingenting på nytt og leser bare motorens publiserte utdata: hver kjørings result.json og report.json, scenariofilen, skjemaet for feltenheter og merkelappene i verifikasjonsmatrisen (hele listen står under Utgaver).
• Kshana Pro-verktøy for utforming, usikkerhet og oppdrag — Pareto-fronten for et utformingsrom, usikkerhet og sensitivitet over tusenvis av kjøringer og et oppdragsdossier med én kommando med en verifikasjonsmatrise og en PDF; se docs/PRO.md.
• Kshana Pro kampanjefølging, spektrumsameksistens og jobbtjeneste — en pipeline som feiler når et fulgt tall blir dårligere, signalplaner testet mot de åpne satellittnavigasjonssignalene i begge retninger og en jobbkø på egen server med et leveringsregister med hashkjede; se docs/PRO.md.
• Opplæring og rådgivning om ytelsesanalyse av kvante- og klassisk PNT.

Dette er åpen-kjerne-modellen: motoren er, og forblir, åpent lisensiert; virksomheten som bærer den er ekspertise, støtte og de proprietære utvidelsene — ikke lisensavgifter. Kontakt contact@ashforde.org · ashforde.org.

Installer og bygg#

Krever en Rust-verktøykjede (≥ 1,88, rust-version i Cargo.toml; utviklet på 1,93).

git clone https://github.com/ashfordeOU/kshana
cd kshana
cargo build --release
cargo test          # all tests pass

Bruk#

Kjør et hvilket som helst scenario; CLI-en sender på feltet kind i scenarioet og skriver <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html og <scenario>.report.json ved siden av det — pluss <scenario>.table.csv for slagene som publiserer en tabell. Rapporten (en HyperText Markup Language (HTML)-side og et JSON-dokument med samme innhold) har et sammendrag for ledelsen, hver inndata med enhet, resultatene og diagrammene, en kampanjes sveip-, Monte Carlo- eller kjedetabeller, en hendelsestidslinje, merkelappen VALIDATED / MODELLED / PARTNER og kilden for hver funksjon kjøringen brukte, hva som ikke er modellert og en reproduserbarhetspost (motorversjon, Secure Hash Algorithm 256-bit (SHA-256)-sammendrag, seed, plattform og den nøyaktige kommandoen). Den skrives ut til en ren PDF-fil (Portable Document Format) fra nettleseren på A4- eller Letter-papir; motoren skriver ingen PDF selv. Se docs/REPORTS.md.

cargo run -- scenarios/clock-holdover.toml
cargo run -- scenarios/imu-deadreckoning.toml
cargo run -- scenarios/timetransfer.toml
cargo run -- scenarios/hybrid-pnt.toml
cargo run -- scenarios/orbit-gnss-challenged.toml
cargo run -- scenarios/orbit-sgp4-gps.toml
cargo run -- scenarios/orbit-rinex.toml
cargo run -- scenarios/integrity-raim.toml

# Export a propagated constellation to an SP3-c precise-ephemeris file:
cargo run -- scenarios/orbit-sgp4-gps.toml --export-sp3 gps.sp3

# Export the constellation's mean elements to a CCSDS OMM catalogue (one OMM
# message per TLE-defined satellite, with its real NORAD id / COSPAR designator):
cargo run -- scenarios/orbit-sgp4-gps.toml --export-omm gps.omm

# Export the velocity-carrying state to a CCSDS OEM 2.0 ephemeris (GMAT/Orekit/STK):
cargo run -- scenarios/orbit-sgp4-gps.toml --export-oem gps.oem

# Export the geometry for a globe, a map or a mission-analysis tool: CZML, KML,
# GeoJSON, STK .e, or SigMF for the spectrum kind (every format that applies):
cargo run -- scenarios/jamming-demo.toml --export all

--export <czml|kml|geojson|stk|sigmf|all|list> skriver CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), Ansys STK (Systems Tool Kit) .e-efemerider og SigMF-opptak (Signal Metadata Format) ved siden av scenarioet, og --import-route <route.geojson> mater en GeoJSON-linje inn i slagene som flyr et spor. Hvert format valideres mot sin publiserte spesifikasjon, og et scenario et format ikke gjelder for sier hvorfor: se docs/INTEROP.md.

Andre CLI-moduser — lint et scenario, mat inn reelle data om jordens orientering eller kjør en hel suite:

# Lint a scenario without running it (checks the kind + required fields):
cargo run -- --validate scenarios/integrity-raim.toml

# Feed a real IERS Earth-orientation file (finals2000A) for frame precision:
cargo run -- scenarios/orbit-sgp4-gps.toml --eop tests/fixtures/agency/eop/finals2000A_2022001.txt

# Run a SUITE of scenarios into one aggregated, stamped study artifact
# (writes <suite>.study.json + <suite>.study.html next to the manifest):
cargo run -- --study scenarios/quantum-pnt-demonstrator.suite.toml

# Animate a run's time series: an animated SVG, a self-contained HTML player, and a
# numbered SVG frame sequence with manifest.json (see docs/ANIMATION.md):
cargo run -- scenarios/campaign-jam-spoof-holdover-integrity.toml --animate all

Animasjonseksport. --animate svg|html|frames|all skriver <scenario>.animation.svg (Cascading Style Sheets (CSS)-keyframes, uten skript), <scenario>.animation.html (avspilling, pause, skrubbing, hastighet og synkroniserte paneler, uten ekstern ressurs) og <scenario>.frames/ (frame_0000.svg, … pluss manifest.json med bilder per sekund og varighet). En kampanje spiller av fasene og alarmene sine, en spektrumkjøring sitt fossefall; temaet følger prefers-color-scheme og prefers-reduced-motion viser det ferdige bildet. Den gjengir kjøringens egne sampler, byte-identisk ved ny kjøring, og legger ikke til noen evidens. Se docs/ANIMATION.md.

Et suite-manifest er en liten TOML-fil (Tom's Obvious, Minimal Language) — en title og en scenarios = [ … ]-tabell med scenariostier — som motoren kjører i tur og orden, og som samler hvert resultat (med merkelappene MODELLED / VALIDATED) i én selvbeskrivende studieartefakt. Se scenarios/quantum-pnt-demonstrator.suite.toml.

Rolle i interoperabilitet. Kshana er laget for ytelsessimulering ved siden av verktøykjeden for etterbehandling, ikke som en erstatning for den: mat RINEX-utdataene inn i RTKLIB eller gLAB for en posisjonsløsning, og bruk SP3-utdataene som presist banedata for verktøy som Ginan — Kshana svarer på hvilken robusthet en gitt PNT-arkitektur gir før du har reelle signaler, i formater disse verktøyene allerede tar inn (--export-sp3, eller export_sp3 = true i et orbit-scenario, skriver <scenario>.sp3). Den samme banen kan publiseres som CCSDS OMM-middelelementer på standardiseringsspor (--export-omm, eller export_omm = true, skriver <scenario>.omm) — én OMM 502,0 KVN-melding (nøkkelord = verdi-notasjon) per TLE-definert satellitt, med hvert objekts reelle NORAD-katalognummer (North American Aerospace Defense Command), internasjonale COSPAR-betegnelse (Committee on Space Research) og epoke, for enhver OMM-bevisst mottaker i stedet for et skreddersydd to-linjers elementsett.

Eksempel på utdata (klokkens holdover — legg merke til hvordan kvalitetsmålene for integritet og sikkerhet rapporteres):

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)
wrote scenarios/clock-holdover.result.json, scenarios/clock-holdover.chart.svg, scenarios/clock-holdover.report.html, and scenarios/clock-holdover.report.json

Den optiske klokkens timingfeil på 95-persentilen (p95) er 1.20e-4 ns: sammendraget skriver ut små verdier med gjeldende siffer i stedet for å avrunde dem til 0.0. security viser n/a (no attack) fordi dette scenarioet ikke konfigurerer noe angrep, så det er ingenting å oppdage. JSON-resultatet har likevel hver klokkes analytiske grense for deteksjon av spoofing i fom.security (0,997 for den optiske klokken, 0,000 for atomklokken i brikkeformat, hvis egen støy over overvåkingsvinduet overskrider spesifikasjonen på 20 ns), og blokken figure_tiers merker det tallet applicable: false. Scenarioslaget spoof scorer deteksjon mot et injisert angrep. figure_tiers gir også hvert rapporterte tall sitt verifikasjonsnivå — VALIDATED (kontrollert mot en ekstern uavhengig referanse) eller MODELLED — og raden i verifikasjonsmatrisen nivået leses fra. Banescenarioet rapporterer i tillegg en geometriblokk — andel av sampler med posisjonsbestemmelse, og beste/median posisjons-dilution of precision (PDOP) og posisjonsnøyaktighet — ved siden av klokkeresultatet.

Les disse to tallene nøye. security er en analytisk grense for deteksjon av spoofing utledet fra hver klokkes stabilitet — den er bare meningsfull mot et konfigurert spoofingscenario og er ikke en RAIM-detektor med flere satellitter. integrity her er filterets egenkonsistens (andelen av bortfallssampler innenfor filterets egen k-sigma-grense), ikke et integritetstall for HPL/VPL i luftfart. Se docs/INTEGRITY.md.

For ekte autonom integritet i mottakeren kjører scenarioslaget integrity (scenarios/integrity-raim.toml) ekte snapshot- og løsningsseparasjons-RAIM (ARAIM-stil) over geometrien til den propagerte konstellasjonen: det beregner horisontale/vertikale beskyttelsesnivåer (HPL/VPL) per epoke og rapporterer andelen epoker som oppfyller de konfigurerte alarmgrensene, med et Stanford-integritetsdiagram for klassifisering av feil mot PL (beskyttelsesnivå).

Reproduserbare studieartefakter

Fire åpne studier regenererer hver en bytedeterministisk artefakt (fast seed) fra én kommando — tallene bak studiene av krysningspunktet mellom kvante og klassisk, optimismegapet for RF-forstyrrelser, scoring av PNT-robusthet og tidsbeskyttelsesnivå:

# Quantum-vs-classical resilience crossover map (writes paper/crossover/*.json):
cargo run --release --bin crossover_study -- paper/crossover

# RF-impairment optimism-gap study (13-detector panel, scaling laws, LOO predictor):
cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json

# Framework-aligned PNT-resilience scoring + decision-instability study:
cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json

# Conditional Timing Protection Level, calibrated on a real recorded spoof:
cargo run --release --example tpl_jammertest

Hver artefakt registrerer motorversjon, seeder og en konfigurasjonshash og bærer en ærlig merkelapp MODELLED/VALIDATED. Probene med reelle data (*_probe) kjører den samme pipelinen over opptak du leverer lokalt; ingen datasett følger med i repositoriet. Studien av optimismegapet for RF-forstyrrelser er skrevet opp i preprinten arXiv:2606,22054, og det betingede tidsbeskyttelsesnivået (tpl_jammertest ovenfor) i preprinten arXiv:2606,24210 (se Siter).

De publiserte månestudiene for PNT (arXiv:2607,06212 DOP for fyrlykter på overflaten, arXiv:2607,02566 observerbarhet med VLBI og arXiv:2610,23871 observerbarhet av buelengde i cislunar rom) har påstandene sine om geometri, dilution of precision, sanntidsprediksjon av referansesystem / parametere for jordens orientering (EOP), distante retrograde baner og RF-avstandsmåling uavhengig kryssjekket i tests/validate_p*.rs mot separate uavhengige referanser (scipy.special.j1, en uavhengig NumPy-løsning av DOP med (HᵀH)⁻¹, en NumPy-omparsing av de samme IERS-radene finals2000A og databasen NASA/JPL Three-Body Periodic Orbit Database). Dette er ekstra regresjonskontroller over den modellerte månesuiten; de endrer ikke antallet i den maskinkontrollerte matrisen.

Scenarioformat#

Scenarioer er deklarative TOML. Et kind på toppnivå velger pakken — femti i alt (clock er standard hvis det utelates): inertial, timetransfer, hybrid, hybrid-ukf, fusion, gnss-ins, orbit, ephemeris, gnss-sim, integrity, lunar-integrity, lunar-time-offset, spoof, spoof-detect, jamming, sweep, sweep-nd, gravity-map, terrain-nav, terrain-slam, combined-altpnt, pvt, mars-pnt, impairment-eval (testbenk for evaluering av deteksjon av RF-forstyrrelser med maskinlæring — merket syntetisk korpus + detektoragnostisk ROC/AUC-løype + optimismegap i og utenfor fordelingen), quantum-trade (kvante-mot-klassisk PNT-avveining med innlesing av målt ADEV + konvolutt for robusthet i GNSS-nektet miljø; MODELLED), space-weather (sol-/geomagnetiske indekser + eksosfærisk temperatur etter Jacchia-71 + aktivitetsdrevet termosfærisk tetthet over den statiske atmosfæren; MODELLED), oem-interop (CCSDS OEM-bro for import/rundtur for efemerider fra GMAT/Orekit/STK; MODELLED), trioen for oppdragsanalyse launch-window (oppskytingsazimut / planendring / muligheter for to legemer), reentry (ballistisk innstigningskorridor etter Allen-Eggers), eo-coverage (EO-geometri for svatbredde / GSD / tilgang / revisitt), space-packet (CCSDS 133,0 TM/TC — telemetri/telekommando — Space Packet-innramming — eksakt bitlayout, verifisert ved rundtur) og attitude-budget (3-DOF gravitasjonsgradientmoment + RSS-budsjett for pekefeil), passes (prediksjon av bakkestasjonsoverflyvninger med soloppgang/-nedgang — AOS/TCA/LOS, maksimal elevasjon, tilgang) og link-budget (enveis CCSDS/DSN-linkligning — FSPL / Eb·N₀ / margin / lukking); telecom-timing (tidsfeil i holdover, MTIE og TDEV kontrollert mot ITU-T-masker); spectrum (hele GNSS L-båndet som én effekttetthetsspekter: et fossefall av frekvens mot tid under en skriptet tidslinje for jammer med kontinuerlig bølge, smalbånd, chirp eller matchet støy, forhold mellom jammer og signal per bånd og effektiv bærebølge-til-støytetthet fra den spektrale separasjonskoeffisienten, og inn- og utdata av opptak i Signal Metadata Format (SigMF) med Welch-spektralestimater; signalspektrene VALIDATED mot lærebokverdier, jammerscenarioet MODELLED; se docs/SPECTRUM.md; det samme slaget tegner paneler for UHF-, S- og C-bånd med utformede signaler for lav jordbane); leo-signal (signalutforminger for posisjonering, navigasjon og tidssynkronisering i lav jordbane for et hvilket som helst system: båndbegrensede spektre, jitter i kodesporing og nøyaktighet i avstandsmåling, innhentingssøk og -tid, spektral separasjon mot GPS og Galileo, jammertoleranse og en avveining mellom UHF og C-bånd, fra offentlige forhåndsinnstillinger som Xona Pulsar, Iridium, Starlink og CentiSpace eller innebygde utforminger; formene i lukket form og LEO-Doppler VALIDATED, utformingene MODELLED; se docs/LEO-SIGNAL.md); solar-system (Solen, planetene, Pluto, Månen og sju store måner ved én epoke — posisjoner, konstanter, lystider og banespor; planetposisjoner VALIDATED mot JPL Horizons) og body-pnt (posisjonering rundt et hvilket som helst av disse legemene med en lokal navigasjonskonstellasjon og en dypromslink fra jorden; MODELLED); campaign (eksisterende slag satt sammen til en lenket oppdragstidslinje med tilstand gitt videre mellom fasene, et parametersveip, et Monte Carlo-ensemble med seed eller flere scenarioer under én felles betingelse; MODELLED, se docs/CAMPAIGNS.md); constellation-design (Walker-delta- og stjernemønstre, elementlister og utforminger med flere skall med forhåndsinnstillinger for GPS, Galileo, BeiDou og GLONASS, og dekning og dilution of precision over et breddegrad/lengdegrad-rutenett; generatoren og global GPS-DOP VALIDATED mot de publiserte tjenestedokumentene, se docs/CONSTELLATION-DESIGN.md); leo-pass (en overflyvning av en satellitt for posisjonering, navigasjon og tidssynkronisering (PNT) i lav jordbane (LEO) og dens linkbudsjett bånd for bånd, fra en hvilken som helst konstellasjon og signalutforming: synsvinkler, Doppler og Doppler-rate, ITU-R-tap fra regn, gass, scintillasjon og innendørs bygningstap, bærebølge-til-støytetthet mot MEO GNSS-satellittene i sikte, førsteordens ionosfære og ionosfærefrie par og et lavenergibudsjett for posisjonsbestemmelse, ionosfæresondering fra hvert båndpar og spoofingmonitorer ved konsistens i Doppler og overflyvningsgeometri og ved konsistens mellom bånd; ITU-R-leddene og Doppler-envelopen for statisk bruker VALIDATED, overflyvningen MODELLED, se docs/LEO-PASS.md); leo-navmsg (kringkastet efemeride- og klokkemelding fra en PNT-satellitt i lav jordbane (LEO), for en hvilken som helst bane og bærebølge: en tilpasser fra en integrert referansebane til Galileos keplerske sett, det settet med korreksjonspolynomer langs sporet, på tvers av sporet og radialt, modellen med 22 parametere fra Liu et al. 2025 eller ATOMIC-polynomet i ECEF uten klokke; avstandsfeil for signal i rommet (SISRE) mot tilpasningsintervall og oppdateringsperiode, en kontinuitetskontroll for oppdatering midt i overflyvningen, Kshanas egen dokumenterte binære ramme med en syklisk redundanskontroll CRC-24Q og et kvantiseringsbudsjett og en blokk i RINEX-4-stil merket som en Kshana-utvidelse; SISRE-vektene, Galileo-brukeralgoritmen og CRC-24Q VALIDATED, tilpasningene MODELLED; valgfrie forhåndsinnstillinger for Xona Pulsar, Iridium, Starlink, CentiSpace, et representativt C-bånd-system, ATOMIC og Celeste IOD; se docs/LEO-NAVMSG.md); trioen for fusjonert MEO + LEO PNT leo-pvt (Doppler-posisjonsbestemmelse fra avstandsrate i lav jordbane (LEO), felles pseudoavstandsløsninger for GNSS + LEO med intersystembiaser og DOP mot antall LEO-satellitter, dekning ved polene og i Arktis og LEO-tidsoverføring til UTC — over en hvilken som helst konstellasjon, med valgfrie forhåndsinnstillinger som Xona Pulsar, Iridium og Starlink-signaler ved anledning; LEO-Doppler-envelopen VALIDATED mot publiserte Iridium- og Xona-tall), leo-ppp (konvergens i presis punktposisjonering med bare GNSS og med LEO-augmentering, sammenlignet med Li et al. 2019) og ntn-positioning (5G-posisjonering i ikke-terrestriske nett fra Cramér-Rao-grensen for signalbåndbredden), MODELLED bortsett fra den envelopen, se docs/LEO-PNT-FUSION.md; leo-pnt-chain (ett LEO-PNT-system fra ende til ende: en utforming leo-signal båret av et bånd leo-pass, overflyvningens C/N0 og navigasjonsmeldingens avstandsfeil for signal i rommet gitt videre til en fusjonert posisjonsbestemmelse leo-pvt og konvergens leo-ppp, hver overlevering listet; MODELLED, se docs/LEO-PNT.md, som også er oversikten over hvert LEO-PNT-slag og -scenario, inkludert robusthetskampanjene, ett scenario per fokusområde i eksperimentet og ett per sluttbrukervertikal); PNT-suiten for Månen lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export; demonstratoren for kvanteaktivert PNT quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; og forskningsslagene for signalsikkerhet, cislunar og lagdelt robusthet lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience — trioen for oppdragsanalyse og disse senere slagene alle MODELLED (hver med en validert kjerne i lukket form; se matrisen). Felles felt: seed, et [time]-rutenett, en [gnss]-tidslinje for tilgjengelighet (det som driver bortfallet) og blokker per sensor med provenance-strenger som siterer kilden for hvert tall. Eksempel (klokke):

seed = 42
threshold_ns = 20.0
[time]
step_s = 10.0
duration_s = 7200.0
[gnss]
windows = [
  { t0 = 0.0,   t1 = 600.0,  state = "nominal" },  # 10 min GNSS sync
  { t0 = 600.0, t1 = 7200.0, state = "denied"  },  # ~1.8 h outage
]
[clock_quantum]
id = "optical-sr-lattice"
provenance = "Strontium optical lattice clock, space-oriented goal sigma_y(1s)=1e-15 (arXiv:1503.08457)"
y0 = 5.0e-17
q_wf = 1.0e-30   # white FM:  q_wf = sigma_y(1s)^2
q_rw = 0.0       # random-walk FM
drift = 0.0      # linear aging (per second)
[clock_classical]
id = "csac-sa45s"
provenance = "Microchip SA65 / SA.45s CSAC datasheet sigma_y(1s)=3e-10"
y0 = 5.0e-10
q_wf = 9.0e-20
q_rw = 0.0
drift = 0.0

Valgfrie felt (av når de mangler): en klokke kan legge til flicker_floor (1/f FM – frekvensmodulasjon – Allan-gulv); en treghetssensor kan legge til gyro_bias og q_arw (gyrobias og angulær tilfeldig gange), og bias_instability og q_aa (Allan-gulvet for biasustabilitet og akselerasjonens tilfeldige gange) – til sammen et enakset (1-DOF) feilbudsjett for akselerometer (VRW/ARW – hastighetens og vinkelens tilfeldige gange – og biasustabilitet). Dette er feilbudsjettet som den medfølgende scenario-pakken inertial kjører. I tillegg har biblioteket nå en verifisert 3-akset strapdown-navigator (src/inertial/{attitude,mechanization,imu_errors}.rs): kvaternionbasert orientering med coning/sculling-kompensasjon, en full NED-mekanisering (ledd for jordrotasjon og transportrate, WGS-84 Somigliana-tyngde) og en deterministisk IMU-feilmodell der skalafaktor, skjevstilling, g-følsomhet, kvantisering og ratterampe er modellert (IEEE Std 952-1997, IEEE-standarden for spesifikasjon og testprosedyre for gyroer, §A.2; Groves 2013 §4,3). Denne 3-akse-banen er nå koblet inn i en kjørbar, løst koblet GNSS/INS-pakke (kind = "gnss-ins"): et feiltilstands-EKF med 15 tilstander styrer strapdown-løsningen mot støyende posisjonsbestemmelser mens GNSS er tilgjengelig, og ruller deretter gjennom bortfallet og rapporterer den fusjonerte horisontale feilen mot den åpne sløyfens frie INS-rulling. En tett koblet pseudorange-oppdatering er også tilgjengelig (den danner innovasjonen i avstandsdomenet og fortsetter derfor å korrigere med færre enn fire satellitter). Et scenario for klokke-holdover kan legge til runs (> 1) for å kjøre et Monte Carlo-ensemble – hvert kvalitetsmål rapporteres da som et gjennomsnitt med en spredning mellom 5. og 95. persentil, og diagrammet skraverer konfidensbåndet for feilen (se scenarios/clock-ensemble.toml).

Et fusion-scenario (samme blokker som hybrid) kjører to uavhengige Kalman-estimatorer – én for klokketilstanden og én for posisjonstilstanden – styrt av GNSS og støttet av optisk tidsoverføring, og rapporterer et samlet kvalitetsmål for holdover. De to blokkene deler ingen kryssovarians: dette er et sammenstilt par av feilbudsjetter, ikke et ekte koblet felles filter for klokke og posisjon (kovarians på tvers av blokkene står på veikartet). Se scenarios/fusion-pnt.toml.

Et spoof-scenario injiserer en tidsspoofing – én av fire [attack.shape]-typer (linear_ramp, step_jump, meaconing, replay; en enkelt rate_ns_per_s godtas fortsatt som en lineær rampe) – og kjører spoofingdetektoren til hver klokke. Detektoren er en tosidig χ²₁-energitest / Neyman–Pearson-test på klokkestøttet overvåkingsstatistikk: terskelen settes ut fra et mål for falsk-alarm-budsjettet target_pfa, og sannsynligheten for udetektert hendelse P_md rapporteres både på lukket form og med Monte Carlo (mc_runs forsøk per hypotese – de to stemmer overens innenfor noen få ganger 1/√N). Kvalitetsmålet for sikkerhet er 1 − P_md ved den operativt skadelige (spesifiserte) størrelsen, slik at en stille klokke som fanger opp en spoofing av spesifisert størrelse får ≈ 1, mens en støyende klokke som ofte går glipp av den får lavere (se scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Et gnss-sim-scenario er en simulering i målingsdomenet: for hver synlige satellitt syntetiserer det pseudoranget ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath og L1-Doppler, med den enfrekvente Klobuchar-ionosfæren ([iono], IS-GPS-200 §20.3.3.5.2.5) og Saastamoinen-zenittroposfæren projisert med mappingfunksjonen Niell (1996) ([tropo]). Residualene mates inn i snapshot-RAIM for HPL/VPL per epoke, og hver satellitts pseudorange, Doppler, C/N₀ og iono-/tropo-korreksjoner sendes ut i JSON-tabellen gnss_measurements. Det er en foroverrettet simulator (den genererer målinger ut fra en kjent referanse), ikke en mottaker eller løser – en kjøring uten støy gjenskaper geometrien pluss korreksjonene ned på submillimeternivå (se scenarios/gnss-sim-raim.toml).

Et jamming-scenario modellerer RF-interferens som et linkbudsjett: en [jammer] (ECEF-posisjon, sendt power_dbw, type) øker forholdet mellom jammer og signal hos en [receiver] som observerer en Walker-[constellation]. Ut fra geometrien (frirom-banetap og mottaksantennens forsterkning i hver retning) beregner det hver satellitts J/S og den effektive C/N₀ med standard anti-jam-ligning (prosesseringsgevinst fra spredning × spektralseparasjonsfaktoren Q; Kaplan & Hegarty §9,4), og markerer tap av lås under en konfigurerbar sporingsterskel – og rapporterer et kvalitetsmål availability_under_jamming. En bredbånds-jammer på 10 W på 1 km avstand gjør mottakeren helt ubrukelig (J/S ≈ 72 dB); den samme jammeren på 100 km svekker bare linkene (se scenarios/jamming-demo.toml).

Et sweep-scenario kjører en avveiningsstudie: det varierer én parameter (threshold_ns, duration_s, quantum_q_wf eller classical_q_wf) fra start til stop over steps punkter på en lin- eller log-scale, registrerer en metric (for eksempel holdover_s) for begge klokkene og tegner de to kurvene. Basisscenarioet legges under [base] (se scenarios/sweep-clock-stability.toml).

Et sweep-nd-scenario generaliserer dette til en hvilken som helst pakke og et hvilket som helst antall akser: det varierer TOML-nøkler med punktum i et [base]-scenario (av en hvilken som helst kind) over det kartesiske produktet av [[axes]], kjører hver rutenettnode på nytt og registrerer metrics oppgitt som JSON-stier med punktum inn i resultatet (for eksempel classical.fom.holdover_s). Det fungerer for alle pakker fordi det virker i grensesnittet mellom TOML og resultat; native kjøringer evaluerer rutenettet parallelt (uten ekstra avhengighet, wasm faller tilbake til sekvensiell kjøring), og utdataene er deterministiske og radvis (se scenarios/sweep-nd-inertial.toml).

Et orbit-scenario utleder [gnss]-tidslinjen fra geometri i stedet for å skrive den inn – oppgi en [user]-bane, en [constellation], en elevasjonsmask_deg og de to klokkeblokkene. Det rapporterer også posisjonsnøyaktighet ut fra satellittgeometrien; den valgfrie sigma_uere_m (1-sigma brukerekvivalent avstandsfeil, standard 1 m) skalerer posisjonens presisjonsfortynning til et posisjonssigma. Brukerbanen kan gjøres eksentrisk med eccentricity og argp_deg, og j2 = true legger til sekulær drift fra jordens avplatning (se scenarios/orbit-molniya.toml). Konstellasjonen kan i stedet være en ekte: gi [constellation] en tle-blokk med to-linjers elementsett, så leses satellittene derfra (se scenarios/orbit-real-tle.toml). Legg til én eller flere [[constellations]]-blokker for multi-GNSS (for eksempel GPS + Galileo; se scenarios/orbit-multignss.toml):

kind = "orbit"
seed = 7
threshold_ns = 5.0
mask_deg = 10.0
sigma_uere_m = 1.0           # optional; position sigma = position-DOP * this
[time]
step_s = 60.0
duration_s = 86400.0
[user]                       # spacecraft (altitude in km, angles in deg)
altitude_km = 8000.0
inclination_deg = 0.0
[constellation]              # Walker-delta GNSS (GPS-like)
altitude_km = 20180.0
inclination_deg = 55.0
planes = 6
sats_per_plane = 4
phasing_f = 1.0
[clock_quantum]  # ... as above
[clock_classical]  # ... as above

Typene for GPS-denied alt-PNT navigerer helt uten GNSS og matcher en målt feltsekvens mot et kart gjennom et partikkelfilter. Et gravity-map-scenario flyr et spor gjennom et gravitasjonsanomalifelt av sfæriske harmoniske og gjenfinner det ut fra avlesningen til et kaldatom-gravimeter (scenarios/gps-denied-gravity-nav.toml); et terrain-nav-scenario gjør det samme mot en SRTM-høydemodell (TERCOM/SITAN, scenarios/terrain-nav.toml); og et combined-altpnt-scenario fusjonerer gravitasjon + IGRF-magnetfelt + terreng i ett filter (scenarios/combined-altpnt.toml).

Et lunar-integrity-scenario evaluerer cislunar PNT: det kjører en ARAIM-beskyttelsesnivåberegning ved månens sørpol mot et sett LunaNet/LNIS-relé og rapporterer ærlig integritetsgapet – en lunar σ_URE på ~30 m driver beskyttelsesnivået godt over en varslingsgrense på 50 m, slik at tjenesten er utilgjengelig under integritetsregler i luftfartsstil (scenarios/lunanet-araim.toml).

Et lunar-time-offset-scenario rapporterer den relativistiske klokkeraten mellom jorden og månen – grunnlaget for en tidsskala for lunar koordinattid (LTC/TCL). En post-newtonsk identitet fra første prinsipper summerer forskjellen i selvpotensial (IAU L_G geoidepotensial minus månens overflatepotensial) og månens kinetiske ledd (andre ordens Doppler) til en sekulær rate på ≈ 57 µs/døgn, rapportert sammen med det publiserte båndet på 56–59 µs/døgn; det gir også den akkumulerte LTC−TT-forskjellen over en horisont og et ensemble med invers varians (en lunar papirklokke). MODELLED – hovedtallet er referanseavhengig (jordens geoide mot månens selenoide, midlingsvindu), og derfor rapporteres et bånd, ikke ett enkelt sertifisert tall (scenarios/lunar-time-offset.toml).

Se scenarios/ for minst ett gjennomarbeidet eksempel på hver type (92 typer, 193 scenario-.toml-filer + 1 suitemanifest – flere typer har mer enn ett eksempel). Ikke alle typer har en fil oppkalt etter seg: lunar-integrity → scenarios/lunanet-araim.toml og gravity-map → scenarios/gps-denied-gravity-nav.toml er to av flere slike. Du kan når som helst liste de tilgjengelige typene med cargo run -- --validate <file>-feil, Python-funksjonen list_kinds() eller MCP-verktøyet list_scenario_kinds.

Utdata#

Resultatartefakten er versjonert, selvbeskrivende JSON: tidsserier per steg, de beregnede kvalitetsmålene, de aktive modellspesifikasjonene (med proveniens), seedet, en scenario-hash – slik at ethvert diagram kan gjenskapes fra filen – og, for hver klokke, en adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]): den overlappende Allan-deviasjonen over middelingstider med oktavavstand – den vanlige måten å lese en klokkes stabilitet på – nå med et støytypespesifikt 95 %-konfidensbånd per punkt (postens potenslovtype identifiseres fra den modifiserte Allan-helningen, og χ²-intervallet bruker de tilsvarende effektive frihetsgradene fra NIST SP 1065). Nettleser-playgrounden viser den som et log-log-diagram «Clock stability (ADEV)». (MDEV, TDEV og HDEV finnes som bibliotekestimatorer; den eksporterte resultatkurven er den overlappende ADEV.) Hvert felt, med enheter og en kildehenvisning, er dokumentert i docs/SCHEMA.md.

Hvert diagram er selvbeskrivende. Nettleser-playgrounden, CLI-ens *.chart.svg-eksport og HTML-resultatkortet (HyperText Markup Language) stempler alle diagrambilder med en bunntekst som lyder Kshana v<version> · scenario <hash> · kshana.dev. scenario <hash> er de første 12 heksadesimale tegnene i kjøringens scenario-hash – en SHA-256-sammendrag (256-biters Secure Hash Algorithm) over den kanoniske scenariodefinisjonen (seed, terskler, modellparametere, GNSS-vinduer, …); integritets- og månerapportene, som ikke har noen egen hash, faller tilbake til en SHA-256 av scenariokilden. Det er det samme fingeravtrykket som vises i enlinjesammendraget og i resultat-JSON-en, slik at et lagret eller limt inn diagram alltid bærer versjonen, det nøyaktige scenarioet som produserte det (for bit-for-bit-gjenskaping) og kilden – endrer du en inndata, endres hashen.

Kvalitetsmålene følger de vanlige operative kvalitetsmålene for PNT:

Ny med disse begrepene? Hvert av dem er forklart på vanlig språk i ordlisten.

Oppbygging av depotet#

kshana/
├── src/                                       # the kshana core crate (library + CLI)
│   ├── api.rs · main.rs · lib.rs              # typed dispatch (92 kinds) + CLI + crate root
│   ├── python.rs · wasm.rs                    # optional PyO3 / wasm-bindgen bindings
│   ├── types.rs · scenario.rs · allan.rs      # shared core (time grid, GNSS timeline, Allan)
│   │
│   ├── models.rs · estimator.rs · kalman.rs   # Pack 1 — clock holdover + integrity
│   ├── security.rs · detection.rs · spoof.rs · spoof_monitors.rs  # spoof detection
│   ├── filter_health.rs · fom.rs · fom_label.rs · report.rs · chart.rs · run.rs  # health · FoM scoring + labelling · output
│   ├── suite.rs · study.rs                     # scenario suites + aggregated multi-scenario study artifacts (`--study`)
│   ├── inertial/                              # Pack 2 — strapdown INS (attitude · mechanization · imu_errors · quantum_imu)
│   ├── timetransfer.rs · timetransfer_adv.rs · timegeo.rs  # Pack 3 — TWSTFT/CV/PPP/optical, Sagnac
│   ├── hybrid.rs · ensemble.rs · sweep.rs     # Pack 4 — fused PNT, Monte-Carlo, trade sweeps
│   │
│   ├── timescales.rs · jd2.rs · ephem.rs      # time systems, two-part JD, Sun/Moon ephemeris
│   ├── precession.rs · nutation.rs · cio.rs   # IAU 2006/2000A precession-nutation + CIO GCRS↔ITRS
│   ├── frames.rs · *_data.rs                  # TEME↔ECEF + generated nutation/CIO/EGM2008/IGRF tables
│   │
│   ├── orbit.rs · sgp4.rs · tle.rs · walker.rs   # geometry, SGP4/SDP4, TLE, Walker design
│   ├── propagator.rs · forces.rs · gravity_sh.rs · integrator.rs  # Cowell + perturbations (EGM2008 d/o70, GR) + RK4/DOPRI
│   ├── maneuver.rs · batch_ls.rs · orbit_determination.rs  # burns/Lambert/porkchop, Gauss-Newton, OD
│   ├── cr3bp.rs · lunar.rs · lunar_frame.rs · lunar_od.rs  # Earth–Moon CR3BP + halo/NRHO STM corrector, cislunar/LunaNet ARAIM, MCI↔MCMF, lunar OD
│   ├── lunar_time.rs · lunar_vlbi.rs · lunar_combination.rs · lunar_frame_realise.rs · lunar_service.rs · lunar_dpnt.rs · lunar_interop.rs  # tiers per piece in the matrix lunar PNT suite — LTC time · geodetic VLBI · joint OD+clock · frame realisation · Moonlight service-volume · differential PNT · LunaNet/IOAG interop export
│   ├── body.rs · mars_frame.rs · ephem_provider.rs · radiometric.rs · ccsds_tdm.rs  # deep-space: multi-body · Mars frame · ephemeris seam · radiometric obs + CCSDS-TDM
│   ├── deepspace_od.rs · clock_state.rs · mars_atmos.rs · mars_pnt.rs · linkbudget.rs · gse_sim.rs  # SRIF OD · onboard clock · Mars drag · relay-PNT · link budget · GSE sim
│   │
│   ├── fusion/                                # GNSS/INS — EKF · UKF · tightly_coupled(17) · coupled · closed_loop
│   ├── raim.rs · sbas.rs                      # RAIM/ARAIM HPL/VPL, SBAS DO-229E PLs + L1/L5 iono-free
│   ├── gnss_sim.rs · ionex.rs · pvt.rs · jamming.rs  # measurement domain · ionosphere maps · single-point positioning · jamming
│   ├── navsignal.rs                            # nav-signal PSD (BPSK-R/BOC) · spectral-separation → anti-jam Q · DLL code-tracking jitter · multipath envelope
│   ├── gravimeter.rs · igrf.rs · mapmatch.rs · particle_filter.rs · altpnt/  # gravity/magnetic/terrain alt-PNT
│   ├── rinex.rs · rinex_obs.rs · glonass.rs · sp3.rs · oem.rs · omm.rs · permalink.rs  # interop formats
│   ├── launch.rs · reentry.rs · eo_payload.rs · attitude_budget.rs · passes.rs · space_packet.rs  # mission-analysis budgets + CCSDS Space Packet
│   ├── space_weather.rs · holdover.rs · tpl.rs   # space-weather environment · GNSS-denied clock-holdover calculator · conditional Timing Protection Level (under spoofing)
│   ├── resilience/                              # framework-aligned PNT-resilience scoring + decision-instability study (RPCF · Dirichlet · Kendall-τ · diversity collapse · assurance report)
│   ├── impairment_eval.rs · impairment_study.rs · impairment_ml.rs · eval_stats.rs  # Machine-learning RF-impairment eval testbed · optimism-gap study · LR/MLP detectors · bootstrap/DeLong/Spearman stats
│   ├── sdr.rs · realdata/                       # software-defined-receiver front end (IQ/IF → E/P/L taps → SQM) + real-data ingest adapters (RINEX · UBX · GnssLogger · JammerTest · Yunnan · SatGrid)
│   ├── crossover.rs · quantum_trade.rs · frugal.rs · integrity_impact.rs  # quantum-vs-classical crossover map · PNT trade · cost-per-coverage ROI · integrity impact
│   ├── quantum_devices.rs · quantum_faults.rs · quantum_nav_od.rs · qtrade.rs · timetransfer_chain.rs · representativeness.rs  # Quantum-Enabled PNT demonstrator — device error models · fault catalogue · GNSS-free quantum OD · unified trade harness · quantum time-transfer chain · representativeness / gaps-to-flight ledger
│   ├── interchange.rs · verification.rs          # KIF artifact envelope · machine-checked verification matrix
│   └── bin/crossover_study.rs · bin/validation_report.rs  # crossover-study artifact generator · release validation-summary HTML
│
├── mcp/kshana-mcp/        # standalone, workspace-EXCLUDED crate — the MCP server (+ Dockerfile, server.json)
├── ide/jetbrains/         # standalone Kotlin/Gradle IntelliJ-Platform plugin
├── xval/                  # standalone, workspace-EXCLUDED external cross-checks: anise-{frames,lunar-od,mars-od,service-geometry} (Rust ANISE/SPICE DE440) + orekit-passes (Java Orekit)
│
├── examples/            # reproducible study generators: tpl_jammertest · resilience_report · optimism_study + real-data probes (jammertest_probe · yunnan_probe · satgrid_probe · texbat_probe · ingest_realdata)
├── paper-artifacts/     # byte-deterministic study artifacts, regenerable from examples/ (optimism-study.json · resilience-study.json); raw datasets stay out
├── scenarios/            # one cited .toml per kind + geometry-driven + GPS-denied
├── scripts/              # reproducibility + repo-hygiene + SBOM guards
├── docs/                 # CONCEPTS, ARCHITECTURE, CAPABILITY, VALIDATION, PROVENANCE, GLOSSARY, …
├── web/                  # the WebAssembly playground + kshana.dev site
├── tools/                # table generators (EGM2008 · IGRF · nutation · CIO) + fetch_tles.sh
├── .github/workflows/    # ci · release · publish · wheels · pages · mcp-publish · jetbrains-plugin · frame-xval
├── pyproject.toml        # Python packaging (maturin)
├── CHANGELOG.md          # Keep a Changelog + SemVer
└── CITATION.cff · ROADMAP.md · CONTRIBUTING.md · SECURITY.md

FAQ#

Må jeg forstå kvantefysikk for å bruke dette? Nei. Hvis du kan kjøre en kommandolinje, kan du kjøre Kshana. Begynn med innføringen på vanlig språk; slå opp begreper i ordlisten.

Er dette en utforming av kvantemaskinvare eller flyprogramvare? Nei. Det er en simulator for ytelse. Kvantemaskinvarens nøyaktighet kommer fra publiserte feilmodeller, ikke fra dette verktøyet. Se Hva det er og ikke er.

Er kvanteresultatene realistiske, eller markedsføring? Hver parameter er sitert til et datablad eller en artikkel, hver modell er validert mot en lærebokrelasjon, og modenhet er merket ærlig i VALIDATION.md – inkludert at ingen strontium-optisk klokke har fløyet. Motoren er nøytral: kvante og klassisk er den samme koden med ulike publiserte tall.

Kan jeg stole på at to kjøringer gir det samme? Ja – kjøringene er deterministiske: scenario + seed + engine version → bit-identical output, håndhevet av scripts/check-reproducible.sh.

Kan jeg bruke det fra Python eller i en nettleser? Ja – se Installasjon: Python- og WebAssembly-eksemplene står under den. Begge kaller den samme motoren.

Hvordan modellerer jeg min egen sensor? Skriv et scenario-.toml med sensorens publiserte tall i provenance-feltene. Se Scenarioformat og eksemplene i scenarios/.

Er det gratis til kommersiell bruk? Ja – under AGPL-3.0, også i kommersielle sammenhenger, så lenge du respekterer AGPLs copyleft (særlig: hvis du endrer Kshana og tilbyr det over et nettverk, må du tilby de brukerne den endrede kildekoden). Hvis det ikke passer deg – for eksempel fordi du må bygge Kshana inn i et proprietært produkt eller drive en lukket nettverkstjeneste – kan du få en kommersiell lisens fra Ashforde® OÜ; se LICENSING.md og Støtte.

Feilsøking#

cargo build feiler med en gammel verktøykjede. Kshana krever Rust ≥ 1,88. Oppdater med rustup update.

Bygging av Python-utvidelsen feiler under lenking på macOS (Undefined symbols … _Py…). En Python-utvidelse løser symbolene sine ved innlasting. maturin setter riktig lenkerflagg automatisk – bruk maturin develop --features python i stedet for en bar cargo build.

Python-bygget klager over at tolken er nyere enn PyO3 kjenner til. Sett PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (abi3-hjul er framoverkompatible på tvers av CPython-versjoner).

WebAssembly-bygget finner ikke målet. Installer det én gang med rustup target add wasm32-unknown-unknown, og kjør deretter wasm-pack build --target web -- --features wasm.

Hvor ble det av utdataene mine? Hver kjøring skriver <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html og <scenario>.report.json ved siden av inndata-.toml, og <scenario>.table.csv i tillegg for de typene som publiserer en tabell. Alle disse er git-ignorert med vilje.

Versjonering og utgivelser#

Kshana følger semantisk versjonering. Før 1.0 kan det offentlige scenario-/resultatskjemaet fortsatt endres; brytende endringer pekes ut eksplisitt i CHANGELOG.md. Hvert resultat kan gjenskapes fra scenario + seed + engine version.

Hver vX.Y.Z-tagg publiserer alle kanaler automatisk, i én bestemt rekkefølge – hele testsuiten kjøres først på den taggede commiten, ingenting publiseres før den består, og etterpå kontrollerer pipelinen at hvert register faktisk leverer den nye versjonen (docs/RELEASING.md). Kanalene:

MCP-serverens crate-, image- og registerversjon følger motoren (den bundler biblioteket); JetBrains-pluginen har uavhengig versjonering (den kaller den installerte kshana-binærfilen din).

Veikart#

Se ROADMAP.md for det trinnvise veikartet, CHANGELOG.md for utgitt historikk og docs/CAPABILITY.md for veikartet per funksjon. Prioriteringsrekkefølgen er: først evidens for tidssynkronisering og holdover for kritisk infrastruktur (telekommasker, lengre holdover med aldring og flickerstøy, innlesing av målte klokkedata); deretter den nøytrale avveiningsmetoden mellom kvante og klassisk (resultater merket MODELLED til en partners målte data løfter dem); og lunar/cislunar og dypromsnavigasjon vedlikeholdes, men utvides ikke som hovedsatsing. Den ITRF-presise referanserammereduksjonen er nå levert – hele CIO-baserte IAU 2006/2000A GCRS↔ITRS-kjeden (polbevegelse + nutasjon på under en buesekund), validert bit-for-bit mot SOFA/ERFA og uavhengig kryssjekket mot ANISE (SPICE i ren Rust) til ≤ 3,6 m i GNSS-bane. Nærliggende punkter omfatter tett koblet bærebølgefase-fusjon og å gjøre den løst/tett koblede GNSS/INS-navigatoren tilgjengelig i flere pakker; motoren for radiometrisk navigasjon i dypt rom / til Mars kom i v0.17.0 (validert i simulering). Kvantefysikklaget er et P2-punkt: CAI-akselerometeret simuleres nå fra første prinsipper (Mach–Zehnder-fase, projeksjonsstøy, kontrastavtak, vibrasjonskobling), mens klokke- og tidsoverføringssensorene fortsatt drives av publiserte Allan-/støybudsjettkoeffisienter. GMST-basert TEME↔ECEF, IERS-skuddsekundets tidssystemer (UTC/TAI/TT/UT1), SGP4/SDP4-banepropagering (v0.7.0, validert mot AIAA 2006-6753-vektorene) og den kjørbare gnss-ins-fusjonspakken er alle levert, og treghetshastigheten er gjort tilgjengelig videre nedstrøms. En aktiv stokastisk tidsspoofingdetektor (Neyman–Pearson / χ²₁-energitest med Monte Carlo-P_fa/P_md og et sikkerhetskvalitetsmål på 1−P_md), en linkbudsjettmodell for jamming (J/S → effektiv C/N₀ → tap av lås), tilgjengelighet for flere konstellasjoner, et enakset (1-DOF) IMU-feilbudsjett, to uavhengige Kalman-estimatorer (klokke + posisjon) rapportert som ett samlet kvalitetsmål, reell konstellasjonsgeometri fra TLE-er, en HTML-resultatrapport, geometriavledet GNSS-tilgjengelighet og presisjonsfortynning fra Kepler-baner med eksentrisitet og J2-drift, Monte Carlo-konfidensbånd, parametersveip for avveiningsstudier, en WebAssembly-playground i nettleseren og valgfrie bindinger for Python (PyO3) og WebAssembly (wasm-bindgen) er landet på main.

Bidra#

Se CONTRIBUTING.md. Kort sagt: testene består (cargo test), de to vaktskriptene består, Conventional Commits, og en oppføring i CHANGELOG.md under [Unreleased] for hver endring som er synlig for brukeren. Deltakelse styres av vår atferdskodeks. For å rapportere et sikkerhetsproblem, se sikkerhetspolicyen – ikke åpne en offentlig sak for sårbarheter.

Dokumentasjon#

Viktige referanser#

Uavhengige referanser og standarder for validering – de eksterne autoritetene Kshanas kontroller er forankret i:

• Vallado, Crawford, Hujsak & Kelso – Revisiting Spacetrack Report #3 (AIAA 2006-6753; testdata): verifikasjonssettet for SGP4/SDP4 som Kshana stemmer overens med til 4,12 mm, og de gjennomarbeidede referansesystemeksemplene TEME→ITRF-kjeden kontrolleres mot.
• IAU SOFA / ERFA – rutinene for tid og referansesystem som IAU 2000A-nutasjonen og CIO GCRS↔ITRS-reduksjonen er validert bit-for-bit mot.
• Petit & Luzum (red.) – IERS Conventions (2010), IERS TN (Technical Note) 36 (standarder for jordorientering, polbevegelse og referansesystem).
• Riley – Handbook of Frequency Stability Analysis, NIST SP 1065 (Allan-deviasjonsrelasjoner og NBS14-referanseserien; NBS = det tidligere amerikanske National Bureau of Standards).
• Pedregosa et al. – scikit-learn: Machine Learning in Python, JMLR 12 (2011): referanseimplementasjonene av ROC/AUC, forvekslingsmatrise og presisjon/gjenkalling/F1 som testbenken for evaluering av RF-forstyrrelser er avstemt nøyaktig mot (tests/eval_metrics_reference.rs).
• Virtanen et al. – SciPy 1,0, Nature Methods 17 (2020): optimize.nnls, stats.chi2 og linalg.expm – referanserutinene som NNLS-tilpasningen av målt ADEV i kvanteavveiningen, χ²-konsistensbåndene og van Loan-kovariansen for klokkens prosessstøy er validert mot (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao – gnss_lib_py, SoftwareX 27 (2024): brukt både som åpen tidligere teknikk (se Comparison & open prior art nedenfor) og som den uavhengige DOP-referansen som beregningen av GDOP/PDOP/HDOP/VDOP/TDOP er avstemt mot til 1e-6 (tests/dop_reference.rs).
• Montenbruck & Gill – Satellite Orbits: Models, Methods and Applications (Springer): kraftmodellene bak tilpasningen av kraftmodellen til byråenes presise efemerider.
• Howell – Three-dimensional, periodic, halo orbits, Celestial Mechanics 32(1) (1984), doi:10.1007/BF01358403; Zimovan-Spreen, Howell & Davis – Near rectilinear halo orbits and nearby higher-period dynamical structures, Astrodynamics 6 (2022), doi:10.1007/s42064-021-0125-x (halo-/NRHO-familiene som CR3BP-differensialkorrektoren gjenskaper).

Fysikk for komponenter og metoder – de siterte kildene bak sensormodellene:

• Origlia, Schiller, Bongs et al. – arXiv:1503,08457 (optisk gitterklokke med strontium, mål for bruk i rommet).
• Oelker et al., Nature Photonics (2019) – doi:10.1038/s41566-019-0493-4 (Sr-klokke i laboratorium, 4,8×10⁻¹⁷).
• Templier et al., Science Advances (2022) – arXiv:2209,13209 (hybrid kvanteakselerometer-triade).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation – IEEE AESS-veiledning (Aerospace and Electronic Systems Society; University College London Discovery repository) (feilvekst ved dødregning).
• Giorgetta et al., Nature Photonics 7, 434 (2013) – arXiv:1211,4902; Deschênes et al., Phys. Rev. X 6, 021016 (2016) – APS (American Physical Society) (optisk toveis overføring av tid og frekvens; den optiske inter-satellittlinken modellerer budsjettet for ikke-resiprositet etter disse).
• Betz – Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (BOC-modulasjonen og teorien om spektralseparasjon bak src/navsignal.rs).
• Kaplan & Hegarty (red.) – Understanding GPS/GNSS: Principles and Applications (3. utg., Artech House, 2017): ligningen for effektiv C/N₀ under anti-jam og den termiske støyjitteren i tidlig–sen-DLL-kodesporing som navigasjonssignal- og jammingmodellene bruker.

Sammenligning og åpen tidligere teknikk – verktøyene og oversiktene Kshana posisjoneres mot:

• Humphreys et al. – TEXBAT (Texas Spoofing Test Battery; ION – Institute of Navigation – GNSS 2012): parametrene i testbatteriet for spoofing som flerlagsdetektoren er karakterisert mot.
• González et al. – NaveGo (2017): de åpne, validerte feilprofilene for treghetsnavigasjon som brukes som klassisk grunnlinje.
• Iiyama, Casadesús Vila & Gao – LuPNT (ION GNSS+ 2023, Stanford NavLab): åpen simulator for lunar PNT.
• Knowles, Kanhere, Neamati & Gao – gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811: åpen analyse av GNSS-data.
• Li, Zaminpardaz, Kealy & Greentree – Quantum sensors for enhanced positioning and navigation: a comprehensive review, GPS Solutions 30(1):62 (2026), doi:10.1007/s10291-026-02030-y.
• Bertone et al. – Earth and Space Science 8(6) (2021), doi:10.1029/2020EA001454: GRAIL redusert-dynamisk banebestemmelse, gulvet for empirisk akselerasjon som LRO-tilpasningen gjenskaper.