• Nacvičte minutu, kdy GNSS zhasne
• Co je nového ve verzi 0,40, Co je nového ve verzi 0,39, Co je nového ve verzi 0,38 a 0,38 podrobně: bodování jammertestu, vlastní příznaky přijímače, strojové vstupy, časování a holdover, balíčky norem, LunaNet AFS, okružní zkouška v laboratoři, kshana-bench, observatoř, exportéry, optika, navigace uživatelů ve vesmíru a lunární infrastruktura
• Kshana Studio a každá stránka Studia
• Schopnosti: tabulka oblastí, každý druh scénáře podle rodiny, každý příkaz, každé rozhraní
• Jak běh funguje, Mise
• Důkazy: registr, domény schopností
• Instalace, Architektura (a diagramy), asistent AI
• Edice, Výzkum, Citovat, Licence
• Reference: použití, formát scénáře, výstup, struktura repozitáře, FAQ, řešení potíží, verzování, plán vývoje, přispívání, dokumentace

Spusťte kterýkoli z nich pomocí kshana example <scenario> > s.toml && kshana s.toml: scénáře jsou l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour a leo-pass-iridium.

Všechny čtyři jsou vymyšlená data a mají poradní charakter: ukazují formát a chování softwaru, nikoli to, jak si kterýkoli přijímač či systém vede proti interferenci. První spusťte pomocí kshana receiver-trust examples/maritime-trust/session.toml, druhý pomocí kshana route-exposure na vzorcích v examples/interference-map/, třetí pomocí kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (jen pro výcvik: nikdy jej nepouštějte do živého navigačního zařízení) a čtvrtý jako v docs/EVIDENCE-PACKS.md.

Následuje úplný rozpis doména po doméně; pro registr zralosti po jednotlivých schopnostech viz docs/CAPABILITY.md a docs/VALIDATION.md.

Každá schopnost je dosažitelná jako API v Rustu, jako spustitelný scénář kind, nebo obojí. Zralost každé schopnosti – ověřená, spustitelná nebo knihovní – se sleduje v docs/CAPABILITY.md. Strojově kontrolovaná verifikační matice (src/verification.rs) vykresluje křížový odkaz požadavek → modul → test → orákulum → stav, s jednotkově testovanými invarianty poctivosti, které povolují štítek ověřená jen tam, kde ji podpírá nezávislé vnější orákulum – a které zaznamenávají schopnosti hardwaru/PA (zajištění produktu), jež Kshana záměrně neposkytuje.

Výsledky#

Každý scénář porovnává kvantový senzor s jeho klasickým protějškem při výpadku GNSS trvajícím ~1,8 h. Čísla jsou reprodukovatelná (scenario + seed + version).

_{Co kvantové senzory přinesou, když GNSS zmizí – clock-holdover · seed 42 · nakresleno v enginu 0.40.0 a každá hodnota výše je při každém sestavení znovu zkontrolována proti aktuálnímu enginu pomocí tests/published_figures_still_reproduce.rs · SVG}

Výhoda závisí na délce výpadku a na vibracích, s výslovným bodem zvratu, kde vyhrává klasické řešení – ukázáno otevřeně napříč žebříčkem technologické připravenosti (údaje optických hodin jsou cíle pozemních demonstrátorů; žádné optické hodiny se stronciem dosud nelétaly):

_{Křížení odolnosti kvantového a klasického – žebříček TRL holdoveru hodin (nahoře) · mapa inerciální výhody s vrstevnicí bodu zvratu (dole). Lze znovu vytvořit pomocí cargo run --release --bin crossover_study.}

Chyba polohy dead-reckoning při výpadku GNSS: kvantový senzor (modře) zůstává plochý u specifikace; klasický senzor (červeně) se rozbíhá na desítky kilometrů. Vytvořeno Kshana z scenarios/imu-deadreckoning.toml.

Vrcholný scénář ukazuje tezi o fúzi: optický mezidružicový přenos času drží uzamčené i klasické hodiny a izoluje inerciální senzor jako slabý článek klasické sestavy – tedy kvantový inerciální senzor + optické časování společně.

Holdover hodin při výpadku GNSS: optické hodiny (modře) zůstávají po celý doběh uvnitř specifikace 20 ns; čipové hodiny (červeně) ji částečně překročí. Vytvořeno Kshana z scenarios/clock-holdover.toml.

Další scénář, orbit-gnss-challenged.toml, odvozuje dostupnost GNSS z orbitální geometrie místo ručně zadaných oken: kosmická loď uvnitř slupky GNSS se propaguje proti konstelaci Walker podobné GPS a počet viditelných družic (přímá viditelnost, zákryt Zemí, elevační maska) určuje stav určení polohy v každém kroku. Během dne je uživatel v určení polohy jen ~59 % času; kvantové hodiny drží časové řešení 5 ns přes každou mezeru (dostupnost 1.0), čipové hodiny jen ~0.83.

Časová chyba během dne s dostupností GNSS odvozenou z orbitální geometrie: počet viditelných družic (přímá viditelnost, zákryt Zemí, elevační maska) určuje stav určení polohy v každém kroku, takže hodiny musí překlenout každou mezeru – optické hodiny drží specifikaci 5 ns, zatímco čipové hodiny ji překročí. Vytvořeno Kshana z scenarios/orbit-gnss-challenged.toml.

Konstelaci lze zadat také jako skutečné dvouřádkové sady elementů (TLE). Úplné TLE (řádek 1 + řádek 2) se propaguje úplným modelem SGP4/SDP4 – včetně atmosférického odporu a hlubokovesmírných lunisolárních a 12 h / 24 h rezonančních členů, které u drah GNSS s ~12 h záleží – ověřeno proti oficiálním vektorům AIAA 2006-6753 na nejhůře ≈ 4 mm. scenarios/orbit-sgp4-gps.toml obsahuje skutečný snímek Celestrak gps-ops provozní konstelace GPS (2021-07-28, 30 družic) a vyžaduje platné kontrolní součty TLE – dvouřádkové sady elementů jsou otevřená data z katalogu US Space Force / 18th Space Defense Squadron, redistribuovaná Celestrakem (Dr T. S. Kelso, celestrak.org); obnovují se pomocí scripts/fetch_tles.sh. Blok jen s řádkem 2 zachovává analytickou dvoutělesovou propagaci (scenarios/orbit-real-tle.toml); obě formy lze v jedné konstelaci míchat. Konstelaci lze stejně tak sestavit z bloku záznamů vysílaných efemerid GPS RINEX-3 – formátu, který přijímač dekóduje – propagovaných uživatelským algoritmem IS-GPS-200 a vedených stejnou geometrií (scenarios/orbit-rinex.toml).

Co to je / není#

Je to: deterministický engine s malými závislostmi, který pokrývá celý zásobník PNT – geometrii oběžných drah, inerciální navigaci, fúzi GNSS/INS, integritu, hodiny a časování. Spouští scénář (často výpadek GNSS), vyvíjí kalibrované modely chyb senzorů příslušným estimátorem a výsledek skóruje proti provozním ukazatelům kvality – vydává reprodukovatelný výsledek JSON (JavaScript Object Notation) a graf SVG, z knihovny v Rustu, rozhraní příkazového řádku (CLI), rozšíření pro Python, modulu WebAssembly v prohlížeči, serveru Model Context Protocol (MCP) pro agenty AI nebo pluginu pro JetBrains IDE (integrované vývojové prostředí).

Není to: letový hardware, návrh kvantového nákladu, úplný přijímač signálu GNSS, simulátor rádiofrekvenčních (RF) signálů ani zkušební stav hardware-in-the-loop, ani certifikovaný letecký produkt – a nenahrazuje MATLAB/Simulink, STK (Systems Tool Kit) ani Orekit; stojí vedle nich a vyměňuje si s nimi soubory. Věrnost kvantového hardwaru pochází z publikovaných modelů chyb, nikoli z tohoto nástroje. Podrobná zralost každé schopnosti je zdokumentována v docs/CAPABILITY.md.

Není to (zatím): úplný fyzikální engine atomové interferometrie (většina kvantových senzorů spotřebovává publikované koeficienty Allanova/šumového rozpočtu; akcelerometr CAI (atomový interferometr) má vrstvu z prvních principů – fáze Mach–Zehnder, projekční šum, pokles kontrastu a vazba vibrací, plus systematiky Coriolisovy síly a světelného posunu – ale systematiky vlnoplochy a řešení nejednoznačnosti proužků zůstávají vrstvou plánu vývoje P2 (fáze plánu 2, vrstva kvantové fyziky), viz ROADMAP.md a docs/QUANTUM-MODELS.md); certifikovaný nebo hardwarový přijímač GNSS (řeší jednobodové určení polohy PVT (poloha, rychlost a čas) ze skutečných kódových pozorování RINEX (Receiver Independent Exchange Format) – ověřeno na skutečných datech IGS (International GNSS Service) – a jeho vrstva IQ (kshana iq, od 0.31.0) softwarově zachycuje a sleduje zaznamenané nebo vygenerované vzorky v základním pásmu, jako analytický přijímač: neovládá rádiový hardware ani nevysílá, není certifikovaným přijímačem a neprovádí určování polohy z fáze nosné (RTK ani PPP)); nebo úplná sada pro návrh mise (má stavební bloky Lambert / porkchop / manévr / určování oběžné dráhy, ale je to vrstva simulace výkonu nad GMAT (General Mission Analysis Tool)/Orekit, nikoli náhrada). Přiznat si tento rozsah je záměrné. Pokud potřebujete rozpočty chyb atomového interferometru z prvních principů (např. třídy CARIOQA-PMP – Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation – nebo validaci ve stylu X-37B), podívejte se na plán vývoje P2 a ozvěte se nám ohledně spolupráce.

Validace, reprodukovatelnost a poctivost#

• Každý šumový člen je kalibrován podle publikované, citované hodnoty a ověřen proti standardnímu vztahu (Allanova odchylka u hodin; Grovesův růst chyby dead-reckoningu u inerciálních systémů; převod časování na měření vzdálenosti u přenosu času). Stav každého členu se vede v docs/VALIDATION.md jako validated nebo not modeled: nic není prezentováno jako ověřené, co ověřené není.
• Reprodukovatelné již konstrukcí: scenario + seed + engine version → identical bits. scripts/check-reproducible.sh to vynucuje; kvantové a klasické běhy používají nezávislé seedy, takže jejich šum není korelovaný.
• Zralost je uvedena poctivě: údaje o optických hodinách a optických spojích jsou výsledky typu cíle / pozemního demonstrátoru, nikoli letové.

Štítek důkazů u každého čísla#

Každé číslo a každá tabulka, které běh zapíše, říká, nakolik jim lze důvěřovat a na kterých řádcích registru stojí. Výsledné JSON má klíč evidence, graf SVG řádek pod grafem (a prvek <metadata id="kshana-evidence">) a tabulka CSV na začátku řádky komentářů # evidence: (čtěte s comment='#'). Uvádí úroveň, VALIDATED, MODELLED nebo PARTNER, a identifikátory (VM- a osm hexadecimálních číslic) řádků verifikační matice, které běh použil. Úroveň je nejslabší z těchto řádků, takže běh, který se opírá o jediný modelovaný řádek, je označen MODELLED bez ohledu na to, kolik ověřených řádků leží vedle něj; štítek tedy nikdy netvrdí víc než registr. Řádky, stavy a identifikátory se čtou z matice, nepíší se ručně (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md) a tests/evidence_labels_doc_sync.rs selže, pokud číslo nemá štítek nebo štítek s maticí nesouhlasí.

Validace v kostce#

Každý řádek vynucuje pojmenovaný test v CI. Tato tabulka je vybraný výběr; úplná strojově kontrolovaná matice má 401 řádků — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), s úplnými důkazy (a tím, co poctivě ještě není ověřeno) v docs/VALIDATION.md a v artefaktu kshana-validation-summary.html každého vydání (generovaném pomocí cargo run --bin validation_report, s atestací SLSA — Supply-chain Levels for Software Artifacts).

Sloupec Stav uvádí druh důkazu v souladu s výše uvedeným žebříčkem validace: VALIDATED = ověřeno proti nezávislému vnějšímu orákulu (reálná data, nezávislá knihovna nebo publikované referenční vektory); MODELLED = ověřeno proti analytické pravdě nebo vnitřní konzistenci simulace (bez nezávislé vnější datové sady). VALIDATED popisuje způsob kontroly, nikoli výsledek typu splněno/nesplněno: poctivé minutí proti skutečnému vnějšímu orákulu zůstává VALIDATED, zatímco srovnání, které žádný řádek matice neuvádí jako orákulum (výše uvedené proložení LRO — Lunar Reconnaissance Orbiter), je označeno MODELLED. Řádky CI jsou procesní pojistky, nikoli ukazatele kvality. Několik ostrůvků reálných dat (měřené cesiové hodiny, Stable32 PHASE.DAT a kontroly OPS-SAT/ICGEM, kde surové vstupy nemají licenci k redistribuci) je omezeno dostupností dat: test vypíše oznámení o přeskočení a zůstane zelený, pokud vstup chybí, a veřejná referenční čísla jsou uložena v tests/fixtures/. Surové vstupy získáte příslušným scripts/fetch_*.sh.

_{Jak schopnost získá své označení — invariant vynucený v CI: žádné vnější orákulum ⇒ nemůže být ověřena · SVG}

_{Nahoře: každý ověřený řádek je z konstrukce podložen vnější datovou sadou. Dole: SGP4 souhlasí s oficiální referencí v každém režimu (nejhorší 4,12 mm). SVG · SVG}

_{176 ověřeno · 221 modelováno · 4 partnerské — 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

Kromě run modul zpřístupňuje run_full (JSON, SVG a jednořádkové shrnutí najednou), run_typed, validate_toml, list_kinds / scenario_kinds a error_kind; viz docs/PYTHON_API.md.

Balíček npm je celý engine zkompilovaný do WebAssembly. V Node.js předejte binární soubor funkci initSync; v prohlížeči jej stáhne await init() (viz 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));

Jeden engine, mnoho vstupních bodů. Jediné jádro v Rustu (kshana) spouští každý scénář a je dostupné přes CLI, rozšíření pro Python, modul WebAssembly v prohlížeči, server MCP pro agenty AI a plugin pro IDE JetBrains — vše směřuje do jednoho rozdělovače api::run_toml. Uvnitř se balíčky senzorů připojují ke společnému rozhraní chybových modelů; vedle nich stojí vrstva referenčních soustav (precese–nutace IAU 2006/2000A a redukce GCRS↔ITRS založená na CIO), astrodynamická/numerická vrstva (analytický SGP4/SDP4 i numerický propagátor Cowell s modelem sil EGM2008/poruch, návrhem manévrů a určováním oběžné dráhy), vrstva integrity/GNSS (RAIM/ARAIM, SBAS, měřicí doména, rušení, cislunární), vrstva fúze / alt-PNT (odhadovače GNSS/INS a mapové korelátory gravitace/terénu/magnetismu), vrstva hlubokého vesmíru a Měsíce (radiometrické PNT pro Mars a lunární sada PNT, s úrovní důkazů každé části v matici — čas LTC, VLBI, společné OD + hodiny, realizace soustavy, objem služby, diferenciální PNT, interoperabilita), vrstva analýzy misí (rozpočty startu / návratu / pokrytí / zaměřování / přeletu / spojů a prostředí kosmického počasí) a otevřená vrstva studií odolnosti a strojového učení (hodnocení odolnosti RPCF, optimistická mezera RF poruch a kvantově podporovaný demonstrátor PNT), jejíž reprodukovatelné artefakty stojí na ověřených jádrech.

Vedle jádra stojí dva samostatné crates vyňaté z workspace — mcp/kshana-mcp (server MCP, postavený na SDK rmcp edice 2024) a xval/anise-frames (křížová kontrola soustav ANISE/SPICE, která stahuje závislosti pod MPL-2.0 (Mozilla Public License 2,0)) — udržované mimo graf závislostí publikovaného crate, Cargo.lock, licenční bránu a sestavení MSRV (minimum supported Rust version, nejnižší podporovaná verze Rustu) seznamem exclude v kořenovém Cargo.toml. Plugin pro JetBrains (ide/jetbrains) je samostatný projekt v Kotlinu. Úplnou sadu diagramů viz docs/ARCHITECTURE.md.

Vykreslené diagramy (tok enginu, mapa modulů, distribuce) jsou v docs/ARCHITECTURE.md.

Scénáře a zprávy

Export a interoperabilita

Důvěra v přijímač a plavidlo

IQ GNSS (soubory v pracovním adresáři; v režimu HTTP vypnuto)

Mapování compliance

Benchmark

Na čem Kshana Pro stojí. Každá část Pro pracuje z otevřeného enginu a nechává jej beze změny:

• Optimalizátor návrhu, studie nejistoty a dossier mise spouštějí scénáře otevřeného enginu přes veřejné rozhraní enginu a každé číslo počítají z výsledků běhů. Každý výstup si ponechává úroveň VALIDATED, MODELLED nebo PARTNER, kterou otevřený engine dal každému údaji, nikdy vyšší.
• Digitální dvojčata hodin používají model hodin otevřeného enginu a jeho odhadovač Allanovy odchylky: dvojče se kalibruje podle publikovaného Allanova rozpočtu zařízení a poté se zkontroluje odhadem Allanovy odchylky dvojčete otevřeným odhadovačem.
• Obchodní studie spouštějí každou architektonickou variantu jako scénář otevřeného enginu, beze změny, a řadí varianty podle ukazatele kvality načteného z výsledku každého běhu.
• Sledování kampaně čte své ukazatele z výsledků běhů scénářů v balíčku na otevřeném enginu a porovnává je s předchozím úspěšným během.
• Koexistence spektra čte každé fyzikální číslo z běhů otevřeného enginu druhů leo-signal a constellation-design a přidává jen součet přes družice v dohledu a řazení plánů.
• Služba úloh v místní infrastruktuře spouští otevřené scénáře i scénáře Pro týmž enginem a každý výsledek ukládá tak, jak jej běh vrátil.
• Balíčky důkazů zaznamenávají pro každý běh hash scénáře, který otevřený engine vtiskne do výsledku, takže údaj v balíčku lze reprodukovat opětovným během jeho scénáře.
• Nástroje systémového inženýrství a programů. Nástroje Kshana Pro pro systémové inženýrství založené na modelech (MBSE) a programy kontrolují požadavky programu proti během otevřeného enginu: importují požadavky jako hodnoty oddělené čárkami (CSV) nebo jako zdokumentovanou podmnožinu Requirements Interchange Format (ReqIF) či textu Systems Modeling Language verze 2 (SysML v2), vyhodnocují každé přejímací kritérium s jeho jednotkou proti hodnotám, které běh zapsal, a vytvářejí matici křížových odkazů verifikace (VCRM), model SysML v2, zprávu o dopadu změn a offline balíček důkazů. Nic znovu nespouštějí ani nepřepočítávají a čtou jen to, co otevřený engine zveřejňuje: result.json každého běhu (pole, která kritérium uvádí, jejich jednotky, otisk reprodukovatelnosti ve složení hash scénáře, seed, verze enginu a verze schématu a označení běhu a úrovně údajů), jeho report.json (druh, záznam reprodukovatelnosti a označení schopností), soubor scénáře (jeho hash, druh, seed a parametry), schéma jednotek polí (jednotka, původ a úroveň důkazů každého pole) a verifikační matici (označení VALIDATED, MODELLED nebo PARTNER každé schopnosti).

Podpora a profesionální služby#

Kshana je zdarma a open source pod AGPL-3.0 a profesionálně vyvíjen a udržován společností Ashforde® OÜ (Estonsko). Otevřený engine je úplný a použitelný sám o sobě. Organizacím, které potřebují víc, Ashforde® OÜ nabízí:

• Komerční podpora a integrace — zabudování Kshana do vašeho řetězce nástrojů, scénáře na míru a prioritní opravy.
• Modely senzorů na míru — kalibrované pro váš hardware, včetně modelů odolnosti citlivých na export, udržovaných v soukromé nadstavbě.
• Kshana Pro — proprietární nástroje pro systémové inženýrství založené na modelech (MBSE) a programy, které kontrolují požadavky programu proti během otevřeného enginu a vytvářejí matici křížových odkazů verifikace (VCRM), model Systems Modeling Language verze 2 (SysML v2), zprávu o dopadu změn a offline balíček důkazů. Nic znovu nespouštějí a čtou jen zveřejněné výstupy enginu: result.json a report.json každého běhu, soubor scénáře, schéma jednotek polí a označení verifikační matice (úplný seznam je v části Edice).
• Nástroje Kshana Pro pro návrh, nejistotu a mise — Paretova fronta návrhového prostoru, nejistota a citlivost přes tisíce běhů a dossier mise jedním příkazem s verifikační maticí a PDF; viz docs/PRO.md.
• Sledování kampaně, koexistence spektra a služba úloh v Kshana Pro — pipeline, která selže, když se sledovaný ukazatel zhorší, plány signálů testované proti otevřeným družicovým navigačním signálům v obou směrech a fronta úloh v místní infrastruktuře s hashově řetězeným registrem (ledger) dodávek; viz docs/PRO.md.
• Školení a poradenství k analýze výkonu kvantového/klasického PNT.

Toto je model open-core: engine je a zůstane pod otevřenou licencí; udržitelný byznys tvoří odbornost, podpora a proprietární rozšíření — nikoli licenční poplatky. Kontakt contact@ashforde.org · ashforde.org.

Instalace a sestavení#

Vyžaduje toolchain Rustu (≥ 1,88, tedy rust-version v Cargo.toml; vyvíjeno na 1,93).

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

Použití#

Spusťte libovolný scénář; CLI se řídí polem kind scénáře a vedle něj zapíše <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html a <scenario>.report.json — plus <scenario>.table.csv pro druhy, které publikují tabulku. Zpráva (stránka HyperText Markup Language (HTML) a dokument JSON se stejným obsahem) obsahuje shrnutí pro vedení, každý vstup s jeho jednotkou, výsledky a grafy, u kampaně tabulky průchodu, Monte Carlo nebo řetězců, časovou osu událostí, označení VALIDATED / MODELLED / PARTNER a zdroj každé schopnosti, kterou běh použil, co není modelováno a záznam reprodukovatelnosti (verze enginu, výtahy Secure Hash Algorithm 256-bit (SHA-256), seed, platforma a přesný příkaz). Z prohlížeče se vytiskne do čistého souboru PDF (Portable Document Format) na papír A4 nebo Letter; engine žádné PDF nezapisuje. Viz 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> zapisuje vedle scénáře záznamy CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), efemeridy Ansys STK (Systems Tool Kit) .e a SigMF (Signal Metadata Format) a --import-route <route.geojson> vkládá čáru GeoJSON do druhů, které létají po trase. Každý formát se ověřuje proti své publikované specifikaci a scénář, na který se formát nevztahuje, uvede proč: viz docs/INTEROP.md.

Další režimy CLI — kontrola scénáře (lint), vkládání skutečných dat o orientaci Země nebo spuštění celé sady:

# 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

Export animace. --animate svg|html|frames|all zapisuje <scenario>.animation.svg (klíčové snímky Cascading Style Sheets (CSS), bez skriptu), <scenario>.animation.html (přehrát, pozastavit, posouvat, rychlost a synchronizované panely, bez vnějších prostředků) a <scenario>.frames/ (frame_0000.svg, … plus manifest.json s počtem snímků za sekundu a trváním). Kampaň přehraje své fáze a poplachy, běh spektra svůj vodopád; téma se řídí prefers-color-scheme a prefers-reduced-motion zobrazí hotový obraz. Vykresluje vlastní vzorky běhu, při opakovaném běhu bajtově shodné, a nepřidává žádné důkazy. Viz docs/ANIMATION.md.

Manifest sady je malý soubor TOML (Tom's Obvious, Minimal Language) — title a pole scenarios = [ … ] cest ke scénářům — který engine spouští postupně a všechny výsledky (s jejich označeními MODELLED / VALIDATED) skládá do jednoho samopopisného artefaktu studie. Viz scenarios/quantum-pnt-demonstrator.suite.toml.

Role v interoperabilitě. Kshana je vrstva simulace výkonu, která stojí vedle toolchainu pro následné zpracování, nikoli jako jeho náhrada: jeho výstup RINEX předejte RTKLIB nebo gLAB pro řešení polohy a jeho výstup SP3 použijte jako produkt přesné dráhy pro nástroje jako Ginan — Kshana odpovídá na otázku, jakou odolnost daná architektura PNT přinese, dříve než máte skutečné signály, a to ve formátech, které tyto nástroje už přijímají (--export-sp3 nebo export_sp3 = true ve scénáři orbit zapíše <scenario>.sp3). Tatáž dráha může být publikována jako střední elementy CCSDS OMM ze standardizační linie (--export-omm nebo export_omm = true zapíše <scenario>.omm) — jedna zpráva OMM 502,0 KVN (keyword = value notation) na družici definovanou v TLE, nesoucí skutečné katalogové číslo NORAD (North American Aerospace Defense Command), mezinárodní označení COSPAR (Committee on Space Research) a epochu každého objektu, pro každého spotřebitele znalého OMM místo svérázného dvouřádkového souboru elementů.

Ukázkový výstup (holdover hodin — všimněte si, jak jsou uváděny ukazatele kvality Integrita a Bezpečnost):

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

95. percentil (p95) časové chyby optických hodin je 1.20e-4 ns: shrnutí vypisuje malé hodnoty se platnými číslicemi, místo aby je zaokrouhlovalo na 0.0. security ukazuje n/a (no attack), protože tento scénář nenastavuje žádný útok, takže není co detekovat. Výsledek JSON přesto nese u každých hodin analytickou mez detekovatelnosti spoofingu v fom.security (0,997 pro optické hodiny, 0,000 pro čipové atomové hodiny, jejichž vlastní šum v monitorovacím okně přesahuje specifikaci 20 ns) a jeho blok figure_tiers označuje tento údaj applicable: false. Druh scénáře spoof hodnotí detekci proti vnesenému útoku. figure_tiers také každému uvedenému údaji přiřazuje jeho verifikační úroveň — VALIDATED (ověřeno proti vnějšímu orákulu) nebo MODELLED — a řádek verifikační matice, z něhož se úroveň čte. Scénář orbit navíc uvádí blok geometrie — podíl vzorků s určením polohy a nejlepší/mediánový faktor DOP polohy (PDOP) a přesnost polohy — vedle výsledku hodin.

Tato dvě čísla čtěte pozorně. security je analytická mez detekovatelnosti spoofingu odvozená ze stability každých hodin — má smysl pouze vůči nakonfigurovanému scénáři spoofingu a není vícedružicovým detektorem RAIM. integrity je zde vnitřní konzistence filtru (podíl vzorků výpadku uvnitř jeho vlastní meze k-sigma), nikoli ukazatel integrity HPL/VPL pro letectví. Viz docs/INTEGRITY.md.

Pro skutečnou integritu autonomní v přijímači spouští druh scénáře integrity (scenarios/integrity-raim.toml) skutečný snímkový RAIM a RAIM s oddělením řešení (ve stylu ARAIM) nad propagovanou geometrií konstelace: pro každou epochu počítá horizontální/vertikální ochranné úrovně (HPL/VPL) a uvádí podíl epoch, které splňují nakonfigurované meze poplachu, se Stanfordovým diagramem integrity pro klasifikaci chyba vs. PL (ochranná úroveň).

Reprodukovatelné artefakty studií

Čtyři otevřené studie z jediného příkazu znovu vygenerují bajtově deterministický artefakt (pevný seed) — čísla za studiemi křížení kvantového a klasického přístupu, optimistické mezery RF poruch, hodnocení odolnosti PNT a ochranné úrovně časování:

# 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

Každý artefakt zaznamenává verzi enginu, seedy a hash konfigurace a nese poctivé označení MODELLED/VALIDATED. Sondy na skutečných datech (*_probe) spouštějí tentýž řetězec nad záznamy, které dodáte lokálně; v repozitáři se žádné datové sady nedodávají. Studie optimistické mezery RF poruch je popsána v preprintu arXiv:2606,22054 a podmíněná ochranná úroveň časování (tpl_jammertest výše) v preprintu arXiv:2606,24210 (viz Citace).

Publikované studie lunárního PNT (arXiv:2607,06212 DOP povrchových majáků, arXiv:2607,02566 pozorovatelnost VLBI a arXiv:2610,23871 pozorovatelnost cislunární délky oblouku) mají svá tvrzení o geometrii, zhoršení přesnosti, předpovědi soustavy / parametrů orientace Země (EOP) v reálném čase, vzdálených retrográdních drahách a měření vzdálenosti RF nezávisle křížově zkontrolována v tests/validate_p*.rs proti samostatným orákulům (scipy.special.j1, nezávislé řešení DOP v NumPy (HᵀH)⁻¹, nové zpracování týchž řádků IERS finals2000A v NumPy a Three-Body Periodic Orbit Database NASA/JPL). Jde o dodatečné regresní kontroly nad z modelu vypočtenou lunární sadou; nemění strojově kontrolovaný počet v matici.

Formát scénáře#

Scénáře jsou deklarativní TOML. Pole kind na nejvyšší úrovni vybírá balíček — celkem padesát (clock je výchozí, pokud chybí): 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 (zkušební prostředí pro vyhodnocení detekce RF poruch strojovým učením — označený syntetický korpus + harness ROC/AUC nezávislý na detektoru + optimistická mezera uvnitř/vně rozdělení), quantum-trade (srovnání kvantového a klasického PNT s načtením měřené ADEV + obálka odolnosti bez GNSS; MODELLED), space-weather (sluneční/geomagnetické indexy + exosférická teplota Jacchia-71 + termosférická hustota řízená aktivitou nad statickou atmosférou; MODELLED), oem-interop (most pro import/zpětný průchod CCSDS OEM pro efemeridy GMAT/Orekit/STK; MODELLED), trojice analýzy misí launch-window (dvoutělesový azimut startu / změna roviny / příležitosti), reentry (balistický koridor návratu podle Allena-Eggerse), eo-coverage (geometrie šířky záběru EO / GSD / přístupu / revisitu), space-packet (rámcování Space Packet CCSDS 133,0 TM/TC — telemetrie/telekomandy — přesné bitové rozvržení, ověřený zpětný průchod) a attitude-budget (3-DOF gravitačně-gradientní moment + rozpočet chyby zaměření RSS), passes (předpověď přeletů nad pozemní stanicí, východ/západ — AOS/TCA/LOS, maximální elevace, přístup) a link-budget (jednosměrná rovnice spoje CCSDS/DSN — FSPL / Eb·N₀ / rezerva / uzavření); telecom-timing (časová chyba holdoveru, MTIE a TDEV zkontrolované proti maskám ITU-T); spectrum (celé pásmo L GNSS jako jedna spektrální hustota výkonu: vodopád frekvence a času pod skriptovanou časovou osou rušiče s nepřetržitou vlnou, úzkopásmového, čirpového nebo shodného šumu, poměr rušiče k signálu po pásmech a efektivní hustota nosné k šumu ze součinitele spektrální separace a vstup a výstup záznamu Signal Metadata Format (SigMF) s Welchovými spektrálními odhady; signálová spektra VALIDATED proti učebnicovým hodnotám, scénář rušiče MODELLED; viz docs/SPECTRUM.md; týž druh kreslí panely pásem UHF, S a C s navrženými signály na nízké oběžné dráze Země); leo-signal (návrhy signálů určování polohy, navigace a času na nízké oběžné dráze Země pro libovolný systém: pásmově omezená spektra, jitter sledování kódu a přesnost měření vzdálenosti, akvizice a doba hledání, spektrální separace vůči GPS a Galileo, odolnost vůči rušiči a srovnání pásem UHF až C, z veřejných předvoleb jako Xona Pulsar, Iridium, Starlink a CentiSpace nebo z vložených návrhů; uzavřené tvary a Doppler LEO VALIDATED, návrhy MODELLED; viz docs/LEO-SIGNAL.md); solar-system (Slunce, planety, Pluto, Měsíc a sedm velkých měsíců v jedné epoše — polohy, konstanty, světelné doby a dráhy; polohy planet VALIDATED proti JPL Horizons) a body-pnt (určování polohy kolem kteréhokoli z těchto těles s místní navigační konstelací a spojem z hlubokého vesmíru od Země; MODELLED); campaign (existující druhy složené do řetězené časové osy mise se stavem předávaným mezi fázemi, průchodu parametrů, seedovaného souboru Monte Carlo nebo několika scénářů za jedné sdílené podmínky; MODELLED, viz docs/CAMPAIGNS.md); constellation-design (vzory Walker delta a star, seznamy elementů a vícevrstvé návrhy s předvolbami GPS, Galileo, BeiDou a GLONASS a pokrytí a zhoršení přesnosti nad mřížkou zeměpisné šířky/délky; generátor a globální DOP GPS VALIDATED proti publikovaným servisním dokumentům, viz docs/CONSTELLATION-DESIGN.md); leo-pass (přelet družice určování polohy, navigace a času (PNT) na nízké oběžné dráze Země (LEO) a její rozpočet spoje pásmo po pásmu, z libovolné konstelace a libovolného návrhu signálu: úhly pohledu, Doppler a rychlost jeho změny, ztráty ITU-R deštěm, plyny, scintilací a průnikem do budov, hustota nosné k šumu vůči družicím GNSS na MEO v dohledu, ionosféra prvního řádu a dvojice bez ionosféry, rozpočet určení polohy s nízkou energií, sondování ionosféry z každé dvojice pásem a monitory spoofingu podle konzistence Dopplera a geometrie přeletu a podle konzistence mezi pásmy; členy ITU-R a obálka Dopplera pro statického uživatele VALIDATED, přelet MODELLED, viz docs/LEO-PASS.md); leo-navmsg (vysílaná zpráva efemerid a hodin družice PNT na nízké oběžné dráze Země (LEO), pro libovolnou dráhu a nosnou: prokládač z integrované pravdivé dráhy do keplerovské sady Galileo, tato sada s polynomy oprav v podélném, příčném a radiálním směru, 22parametrový model Liu et al. 2025 nebo polynom ECEF ATOMIC s nulovými hodinami; chyba rozsahu signálu ve vesmíru (SISRE) vs. interval proložení a perioda aktualizace, kontrola návaznosti aktualizace uprostřed přeletu, vlastní zdokumentovaný binární rámec Kshana s cyklickým redundančním kontrolním součtem CRC-24Q a rozpočet kvantizace a blok ve stylu RINEX-4 označený jako rozšíření Kshana; váhy SISRE, uživatelský algoritmus Galileo a CRC-24Q VALIDATED, proložení MODELLED; volitelné předvolby pro Xona Pulsar, Iridium, Starlink, CentiSpace, reprezentativní systém v pásmu C, ATOMIC a Celeste IOD; viz docs/LEO-NAVMSG.md); trojice fúzovaného PNT MEO + LEO leo-pvt (Dopplerovo určování polohy z rychlosti změny vzdálenosti družic na nízké oběžné dráze Země (LEO), společná určení polohy z pseudovzdáleností GNSS + LEO s mezisystémovými biasy a DOP vůči počtu družic LEO, polární a arktické pokrytí a přenos času LEO do UTC — přes libovolnou konstelaci, s volitelnými předvolbami, jako jsou signály příležitosti Xona Pulsar, Iridium a Starlink; obálka Dopplera LEO VALIDATED proti publikovaným údajům Iridium a Xona), leo-ppp (konvergence přesného určení polohy samotného bodu jen s GNSS a s doplněním o LEO, porovnáno s Li et al. 2019) a ntn-positioning (určování polohy v 5G neterestrických sítích z Cramérovy–Raovy meze šířky pásma signálu), MODELLED kromě této obálky, viz docs/LEO-PNT-FUSION.md; leo-pnt-chain (jeden systém LEO-PNT od začátku do konce: návrh leo-signal nesený pásmem leo-pass, C/N0 přeletu a chyba rozsahu signálu ve vesmíru navigační zprávy předané fúzovanému určení leo-pvt a konvergenci leo-ppp, každé předání uvedeno; MODELLED, viz docs/LEO-PNT.md, který je zároveň přehledem každého druhu a scénáře LEO-PNT, včetně kampaní odolnosti, jednoho scénáře na každou zaměřenou oblast experimentu a jednoho na každou koncovou vertikálu); sada lunárního PNT lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export; demonstrátor kvantově podporovaného PNT quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect; a výzkumné druhy zabezpečení signálu, cislunární a vrstvené odolnosti lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience — trojice analýzy misí i tyto pozdější druhy jsou všechny MODELLED (každý s ověřeným jádrem v uzavřeném tvaru; viz matice). Společná pole: seed, mřížka [time], časová osa dostupnosti [gnss] (řídicí výpadek) a bloky jednotlivých senzorů s řetězci provenance citujícími zdroj každého údaje. Příklad (hodiny):

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

Volitelná pole (bez nich vypnuto): hodiny mohou přidat flicker_floor (práh Allanovy odchylky 1/f FM — frekvenční modulace); inerciální senzor může přidat gyro_bias a q_arw (bias gyroskopu a úhlová náhodná procházka) a bias_instability a q_aa (práh nestability biasu podle Allana a náhodná procházka zrychlení) — dohromady jednoosý (1-DOF) rozpočet chyby akcelerometru (VRW/ARW — rychlostní/úhlová náhodná procházka — a nestabilita biasu). To je rozpočet chyb, který spouští dodávaná sada scénářů inertial. Zvlášť knihovna nově nese ověřený 3osý strapdown navigátor (src/inertial/{attitude,mechanization,imu_errors}.rs): kvaternionovou orientaci s kompenzací coning/sculling, plnou mechanizaci NED (členy rychlosti Země a transportní rychlosti, tíže WGS-84 podle Somiglianovy formule) a deterministický chybový model IMU, ve kterém jsou modelovány činitel měřítka, nesouosost, g-citlivost, kvantizace a rychlostní rampa (IEEE Std 952-1997, norma IEEE pro specifikaci a zkušební postup gyroskopů, §A.2; Groves 2013 §4,3). Tato 3osá cesta je nyní zapojena do spustitelné volně vázané sady GNSS/INS (kind = "gnss-ins"): 15stavový chybový EKF disciplinuje strapdown řešení vůči zašuměným určením polohy, dokud GNSS funguje, a poté setrvačně pokračuje výpadkem a uvádí fúzovanou horizontální chybu proti volné setrvačné extrapolaci INS s otevřenou smyčkou. K dispozici je také těsně vázaná aktualizace pseudovzdáleností (tvoří inovaci v oblasti vzdáleností, takže opravuje i při méně než čtyřech družicích). Scénář holdoveru hodin může přidat runs (> 1) pro spuštění souboru Monte Carlo — každý ukazatel kvality se pak uvádí jako střední hodnota s rozptylem 5.–95. percentilu a graf zastíní pásmo spolehlivosti chyby (viz scenarios/clock-ensemble.toml).

Scénář fusion (stejné bloky jako hybrid) spouští dva nezávislé Kalmanovy odhadovače — jeden pro stav hodin, jeden pro stav polohy — disciplinované GNSS a podporované optickým přenosem času a uvádí kombinovaný ukazatel kvality holdoveru. Oba bloky nesdílejí žádnou kovarianci: jde o naskládanou dvojici chybových rozpočtů, nikoli o skutečný spřažený společný filtr hodiny + poloha (kovariance mezi bloky je položka plánu). Viz scenarios/fusion-pnt.toml.

Scénář spoof vnáší časový spoofing — jeden ze čtyř druhů [attack.shape] (linear_ramp, step_jump, meaconing, replay; holé rate_ns_per_s se stále přijímá jako lineární rampa) — a spouští detektor spoofingu každých hodin. Detektor je oboustranný test energie χ²₁ / Neyman–Pearson nad monitorovací statistikou podporovanou hodinami: práh se určuje z cílového rozpočtu falešného poplachu target_pfa a pravděpodobnost nezachycené události P_md se uvádí jak v uzavřeném tvaru, tak metodou Monte Carlo (mc_runs pokusů na hypotézu — obě se shodují na několik ×1/√N). Ukazatel kvality Bezpečnost je 1 − P_md při provozně škodlivé (specifikační) velikosti, takže tichý hodinový zdroj, který zachytí spoofing o velikosti specifikace, získá ≈ 1 a hlučný, který jej často mine, méně (viz scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Scénář gnss-sim je simulace v měřicí doméně: pro každou viditelnou družici syntetizuje pseudovzdálenost ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath a Doppler na L1, s jednofrekvenční ionosférou Klobuchar ([iono], IS-GPS-200 §20.3.3.5.2.5) a zenitovou troposférou Saastamoinen promítnutou mapovací funkcí Niell (1996) ([tropo]). Rezidua napájejí snímkový RAIM pro HPL/VPL po epochách a pseudovzdálenost, Doppler, C/N₀ a korekce iono/tropo každé družice se vysílají v poli JSON gnss_measurements. Je to dopředný simulátor (vytváří měření ze známé pravdy), nikoli přijímač/řešitel — běh s nulovým šumem reprodukuje geometrii plus korekce na úrovni pod milimetr (viz scenarios/gnss-sim-raim.toml).

Scénář jamming modeluje RF interferenci jako rozpočet spoje: [jammer] (poloha ECEF, vysílací power_dbw, typ) zvyšuje poměr rušiče k signálu u [receiver], který sleduje Walkerovu [constellation]. Z geometrie (ztráta šířením ve volném prostoru a zisk přijímací antény v každém směru) počítá J/S každé družice, efektivní C/N₀ podle standardní rovnice odolnosti proti rušení (zisk zpracování rozprostřením × činitel spektrální separace Q; Kaplan & Hegarty §9,4) a hlásí ztrátu uzamčení pod nastavitelným prahem sledování — a uvádí ukazatel kvality availability_under_jamming. Širokopásmový jammer o výkonu 10 W ve vzdálenosti 1 km přijímač zcela vyřadí (J/S ≈ 72 dB); tentýž jammer ve vzdálenosti 100 km spoje jen zhorší (viz scenarios/jamming-demo.toml).

Scénář sweep spouští obchodní studii: mění jeden parameter (threshold_ns, duration_s, quantum_q_wf nebo classical_q_wf) od start do stop v steps bodech na škále lin nebo log (scale), zaznamenává metric (např. holdover_s) pro oba hodinové zdroje a vykresluje obě křivky. Základní scénář patří pod [base] (viz scenarios/sweep-clock-stability.toml).

Scénář sweep-nd to zobecňuje na libovolný balíček a libovolný počet os: mění tečkované klíče TOML scénáře [base] (libovolného kind) přes kartézský součin [[axes]], znovu spouští každý uzel mřížky a zaznamenává metrics zadané jako tečkované cesty JSON do výsledku (např. classical.fom.holdover_s). Funguje pro každý balíček, protože pracuje na rozhraní TOML/výsledek; nativní běhy vyhodnocují mřížku paralelně (bez další závislosti, wasm se vrací k sekvenčnímu režimu) a výstup je deterministický a řazený po řádcích (viz scenarios/sweep-nd-inertial.toml).

Scénář orbit odvozuje časovou osu [gnss] z geometrie, místo aby ji zadával — uveďte oběžnou dráhu [user], [constellation], elevační mask_deg a dva bloky hodin. Z geometrie družic také uvádí přesnost polohy; volitelné sigma_uere_m (1-sigma ekvivalentní chyba vzdálenosti uživatele, výchozí 1 m) převádí faktor DOP polohy na sigma polohy. Dráha uživatele může být excentrická pomocí eccentricity a argp_deg a j2 = true přidává sekulární drift způsobený zploštěním Země (viz scenarios/orbit-molniya.toml). Konstelace může být místo toho skutečná: dejte [constellation] blok tle s dvouřádkovými sadami elementů a družice se z něj zpracují (viz scenarios/orbit-real-tle.toml). Přidejte jeden či více bloků [[constellations]] pro multi-GNSS (např. GPS + Galileo; viz 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

Druhy alt-PNT bez GPS navigují zcela bez GNSS a porovnávají naměřenou polní posloupnost s mapou přes časticový filtr. Scénář gravity-map letí po trati sférickým harmonickým polem gravitačních anomálií a obnovuje ji z údaje gravimetru se studenými atomy (scenarios/gps-denied-gravity-nav.toml); scénář terrain-nav totéž dělá proti výškovému modelu SRTM (TERCOM/SITAN, scenarios/terrain-nav.toml); a scénář combined-altpnt slučuje gravitaci + magnetické pole IGRF + terén v jednom filtru (scenarios/combined-altpnt.toml).

Scénář lunar-integrity hodnotí cislunární PNT: spouští přelet s ochrannou úrovní ARAIM na lunárním jižním pólu proti sadě relé LunaNet/LNIS a poctivě uvádí mezeru v integritě — lunární σ_URE ~30 m žene ochrannou úroveň hluboko nad mez poplachu 50 m, takže služba je podle pravidel integrity ve stylu letectví nedostupná (scenarios/lunanet-araim.toml).

Scénář lunar-time-offset uvádí relativistickou rychlost chodu hodin Země–Měsíc — základ časové škály Lunar Coordinate Time (LTC/TCL). Identita post-newtonovského řádu z prvních principů sčítá rozdíl vlastních potenciálů (potenciál geoidu IAU L_G mínus vlastní potenciál povrchu Měsíce) a kinetický člen Měsíce (Dopplerův člen druhého řádu) na sekulární rychlost ≈ 57 µs/den, uváděnou spolu s publikovaným pásmem 56–59 µs/den; dává také nahromaděný posun LTC−TT za horizont a soubor s inverzním rozptylem (lunární papírové hodiny). MODELLED — hlavní údaj závisí na referenci (geoid Země vs. selenoid Měsíce, okno průměrování), a proto se uvádí pásmo, nikoli jediné certifikované číslo (scenarios/lunar-time-offset.toml).

V scenarios/ najdete alespoň jeden vzorový příklad každého druhu (92 druhů, 193 souborů scénářů .toml + 1 manifest sady — některé druhy mají více než jeden příklad). Ne každý druh má soubor pojmenovaný podle sebe: lunar-integrity → scenarios/lunanet-araim.toml a gravity-map → scenarios/gps-denied-gravity-nav.toml jsou dva z několika takových případů. Dispečovatelné druhy lze kdykoli vypsat pomocí chyb cargo run -- --validate <file>, Pythonu list_kinds() nebo nástroje MCP list_scenario_kinds.

Výstup#

Artefakt výsledku je verzovaný, samopopisný JSON: časové řady po krocích, hodnocené ukazatele kvality, aktivní specifikace modelů (s původem), seed, hash scénáře — aby šel každý graf reprodukovat ze souboru — a pro každé hodiny adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]): překrývající se Allanova odchylka napříč oktávově rozloženými dobami průměrování — standardní způsob čtení stability hodin — nyní s 95% pásmem spolehlivosti specifickým pro typ šumu v každém bodě (mocninný typ záznamu se určí ze sklonu modifikované Allanovy odchylky a interval χ² používá odpovídající efektivní stupně volnosti podle NIST SP 1065). Hřiště v prohlížeči jej vykreslí jako log-log graf „Stabilita hodin (ADEV)“. (MDEV, TDEV a HDEV jsou k dispozici jako odhadovače knihovny; exportovaná křivka výsledku je překrývající se ADEV.) Každé pole, s jednotkami a odkazem na zdroj, je zdokumentováno v docs/SCHEMA.md.

Každý graf je samopopisný. Hřiště v prohlížeči, export *.chart.svg z CLI i výsledková karta HTML (HyperText Markup Language) opatřují každý obrázek grafu patičkou ve tvaru Kshana v<version> · scenario <hash> · kshana.dev. scenario <hash> je prvních 12 hexadecimálních znaků hashe scénáře běhu — výtahu SHA-256 (256bitový Secure Hash Algorithm) z kanonické definice scénáře (seed, prahy, parametry modelů, okna GNSS, …); zprávy o integritě a lunární zprávy, které nenesou vlastní hash, se vracejí k SHA-256 zdroje scénáře. Je to tentýž otisk, který ukazuje jednořádkové shrnutí a JSON výsledku, takže uložený nebo vložený graf vždy nese svou verzi, přesný scénář, který jej vytvořil (pro reprodukci bit po bitu), a zdroj — změňte jakýkoli vstup a hash se změní.

Ukazatele kvality sledují standardní provozní ukazatele kvality PNT:

Jsou vám tyto pojmy nové? Každý je vysvětlen prostým jazykem ve slovníčku.

Struktura repozitáře#

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#

Musím rozumět kvantové fyzice, abych to mohl používat? Ne. Pokud umíte spustit příkaz v příkazové řádce, umíte spustit Kshana. Začněte populárním úvodem; pojmy hledejte ve slovníčku.

Je to návrh kvantového hardwaru, nebo letový software? Ne. Je to simulátor výkonu. Věrnost kvantového hardwaru pochází z publikovaných chybových modelů, nikoli z tohoto nástroje. Viz Co to je / není.

Jsou kvantové výsledky realistické, nebo marketing? Každý parametr je citován z datového listu nebo článku, každý model je ověřen proti učebnicovému vztahu a zralost je poctivě označena v VALIDATION.md — včetně toho, že žádné optické hodiny se stronciem dosud nelétaly. Engine je neutrální: kvantový a klasický přístup jsou týž kód s různými publikovanými čísly.

Mohu se spolehnout, že se dva běhy shodnou? Ano — běhy jsou deterministické: scenario + seed + engine version → bit-identical output, vynuceno scripts/check-reproducible.sh.

Mohu to používat z Pythonu nebo v prohlížeči? Ano — viz Instalace: příklady pro Python a WebAssembly jsou pod ní. Oba volají tentýž engine.

Jak namodeluji vlastní senzor? Napište scénář .toml s publikovanými údaji svého senzoru v polích provenance. Viz Formát scénáře a příklady v scenarios/.

Je to zdarma pro komerční použití? Ano — pod AGPL-3.0, včetně komerčního prostředí, pokud dodržujete copyleft licence AGPL (zejména: pokud Kshana upravíte a nabízíte jej přes síť, musíte těmto uživatelům nabídnout svůj upravený zdroj). Pokud vám to nevyhovuje — např. potřebujete Kshana zabudovat do proprietárního produktu nebo provozovat uzavřenou síťovou službu — je u Ashforde® OÜ k dispozici komerční licence; viz LICENSING.md a Podpora.

Řešení problémů#

cargo build selže na starém toolchainu. Kshana potřebuje Rust ≥ 1,88. Aktualizujte pomocí rustup update.

Sestavení rozšíření pro Python se na macOS nepodaří slinkovat (Undefined symbols … _Py…). Rozšíření pro Python řeší své symboly při načtení. maturin nastaví správný příznak linkeru automaticky — použijte maturin develop --features python místo holého cargo build.

Sestavení pro Python si stěžuje, že interpret je novější, než PyO3 zná. Nastavte PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (kola abi3 jsou dopředně kompatibilní napříč verzemi CPythonu).

Sestavení WebAssembly nenajde cíl. Nainstalujte jej jednou pomocí rustup target add wasm32-unknown-unknown a poté wasm-pack build --target web -- --features wasm.

Kam se poděl můj výstup? Každý běh zapíše <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html a <scenario>.report.json vedle vstupního .toml a u druhů, které publikují tabulku, také <scenario>.table.csv. Všechny jsou záměrně ignorovány gitem.

Verzování a vydání#

Kshana se řídí sémantickým verzováním. Před verzí 1.0 se může veřejné schéma scénáře/výsledku ještě měnit; zásadní změny jsou výslovně uvedeny v CHANGELOG.md. Každý výsledek je reprodukovatelný z scenario + seed + engine version.

Každý tag vX.Y.Z publikuje všechny kanály automaticky, v jednom pořadí — nejprve se na označeném commitu spustí úplná testovací sada, dokud neprojde, nic se nepublikuje, a poté pipeline zkontroluje, že každý registr skutečně servíruje novou verzi (docs/RELEASING.md). Kanály:

Verze crate / obrazu / registru serveru MCP sleduje engine (zahrnuje knihovnu); plugin pro JetBrains je verzován nezávisle (volá nainstalovanou binárku kshana přes shell).

Plán#

Viz ROADMAP.md pro fázový plán, CHANGELOG.md pro historii vydání a docs/CAPABILITY.md pro plán po jednotlivých schopnostech. Pořadí priorit je: nejprve důkazy o časování a holdoveru pro kritickou infrastrukturu (telekomunikační masky, delší holdover se stárnutím a flicker šumem, načítání měřených dat hodin); na druhém místě neutrální metoda srovnání kvantového a klasického přístupu (výsledky označené MODELLED, dokud je nepovýší měřená data partnera); a lunární / cislunární navigace a navigace v hlubokém vesmíru je udržována, nikoli rozšiřována jako hlavní směr. Přesná redukce soustav ITRF je nyní dodána — úplný řetězec GCRS↔ITRS IAU 2006/2000A založený na CIO (pohyb pólu + nutace pod obloukovou vteřinu), ověřený bit po bitu proti SOFA/ERFA a nezávisle křížově zkontrolovaný proti ANISE (čisté Rust SPICE) na ≤ 3,6 m na oběžné dráze GNSS. Mezi blízké položky patří těsně vázaná fúze fáze nosné a zpřístupnění volně/těsně vázaného navigátoru GNSS/INS ve více balíčcích; engine radiometrické navigace v hlubokém vesmíru / u Marsu přistál ve verzi v0.17.0 (ověřeno simulací). Kvantová fyzikální vrstva je položka P2: akcelerometr CAI je nyní simulován z prvních principů (fáze Mach–Zehnder, projekční šum, pokles kontrastu, vazba vibrací), zatímco senzory hodin/přenosu času stále řídí publikované koeficienty Allanova/šumového rozpočtu. TEME↔ECEF založené na GMST, časové soustavy IERS s přestupnými sekundami (UTC/TAI/TT/UT1), propagace oběžných drah SGP4/SDP4 (v0.7.0, ověřeno proti vektorům AIAA 2006-6753) a spustitelný balíček fúze gnss-ins byly všechny dodány a inerciální rychlost je zpřístupněna dále. Na main přistály aktivní stochastický detektor časového spoofingu (test energie Neyman–Pearson / χ²₁ s Monte-Carlo P_fa/P_md a ukazatelem kvality Bezpečnost 1−P_md), model rušení rozpočtem spoje (J/S → efektivní C/N₀ → ztráta uzamčení), dostupnost více konstelací, jednoosý (1-DOF) chybový rozpočet IMU, dva nezávislé Kalmanovy odhadovače (hodiny + poloha) uváděné jako kombinovaný ukazatel kvality, skutečná geometrie konstelace z TLE, zpráva ve formě výsledkové karty HTML, dostupnost GNSS odvozená z geometrie i faktor DOP z keplerovských drah s excentricitou a driftem J2, pásma spolehlivosti Monte Carlo, průchody parametrů v obchodních studiích, hřiště WebAssembly v prohlížeči a volitelné vazby pro Python (PyO3) a WebAssembly (wasm-bindgen).

Přispívání#

Viz CONTRIBUTING.md. Ve zkratce: testy projdou (cargo test), projdou oba ochranné skripty, Conventional Commits a záznam [Unreleased] v CHANGELOG.md pro každou změnu viditelnou uživateli. Účast se řídí naším Kodexem chování. Bezpečnostní problém nahlásíte podle Bezpečnostní politiky — u zranitelností prosím neotevírejte veřejný issue.

Dokumentace#

Klíčové reference#

Validační orákula a normy — vnější autority, ke kterým jsou kontroly Kshana ukotveny:

• Vallado, Crawford, Hujsak & Kelso — Revisiting Spacetrack Report #3 (AIAA 2006-6753; testovací data): ověřovací sada SGP4/SDP4, s níž Kshana souhlasí na 4,12 mm, a dopracované příklady soustav, proti nimž se kontroluje řetězec TEME→ITRF.
• IAU SOFA / ERFA — rutiny pro referenční čas a soustavy, proti nimž jsou nutace IAU 2000A a redukce CIO GCRS↔ITRS ověřeny bit po bitu.
• Petit & Luzum (eds.) — IERS Conventions (2010), IERS TN (Technical Note) 36 (standardy pro orientaci Země, pohyb pólu a referenční soustavy).
• Riley — Handbook of Frequency Stability Analysis, NIST SP 1065 (vztahy pro Allanovu odchylku a referenční řada NBS14; NBS = bývalý americký Národní úřad pro standardy).
• Pedregosa et al. — scikit-learn: Machine Learning in Python, JMLR 12 (2011): referenční implementace ROC/AUC, matice záměn a precision/recall/F1, s nimiž se testovací prostředí pro hodnocení RF-impairment přesně shoduje (tests/eval_metrics_reference.rs).
• Virtanen et al. — SciPy 1,0, Nature Methods 17 (2020): optimize.nnls, stats.chi2 a linalg.expm — referenční rutiny, proti nimž jsou ověřeny NNLS fit naměřené ADEV v kvantové obchodní studii, pásma konzistence χ² a kovarianční matice procesního šumu hodin podle van Loana (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024): používá se jednak jako otevřená předchozí práce (viz Srovnání a otevřená předchozí práce níže), jednak jako nezávislé orákulum DOP, s nímž se výpočet GDOP/PDOP/HDOP/VDOP/TDOP shoduje na 1e-6 (tests/dop_reference.rs).
• Montenbruck & Gill — Satellite Orbits: Models, Methods and Applications (Springer): silové modely, na nichž stojí fit silového modelu k přesným efemeridám agentur.
• 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 (rodiny drah halo/NRHO, které diferenciální korektor CR3BP reprodukuje).

Fyzika zařízení a metod — citované zdroje za modely senzorů:

• Origlia, Schiller, Bongs et al. — arXiv:1503,08457 (optické hodiny se stronciem v optické mřížce, cíl pro použití ve vesmíru).
• Oelker et al., Nature Photonics (2019) — doi:10.1038/s41566-019-0493-4 (laboratorní hodiny se Sr, 4,8×10⁻¹⁷).
• Templier et al., Science Advances (2022) — arXiv:2209,13209 (hybridní kvantová trojice akcelerometrů).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation — tutoriál IEEE AESS (Aerospace and Electronic Systems Society) (repozitář University College London Discovery) (růst chyby při dead reckoningu).
• 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) (optický dvoucestný přenos času a frekvence; optická mezidružicová linka podle nich modeluje svůj rozpočet nereciprocity).
• Betz — Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (modulace BOC a teorie spektrální separace, na nichž stojí src/navsignal.rs).
• Kaplan & Hegarty (eds.) — Understanding GPS/GNSS: Principles and Applications (3. vyd., Artech House, 2017): rovnice efektivního C/N₀ při potlačení rušení a tepelný šum jitteru kódového sledování early–late DLL, které používají modely navigačního signálu a rušení.

Srovnání a otevřená předchozí práce — nástroje a přehledy, vůči nimž je Kshana vymezena:

• Humphreys et al. — TEXBAT (Texas Spoofing Test Battery; ION — Institute of Navigation — GNSS 2012): parametry testovací baterie spoofingu, vůči nimž je vícevrstvý detektor charakterizován.
• González et al. — NaveGo (2017): otevřené, ověřené profily chyb inerciální navigace použité jako klasický základ.
• Iiyama, Casadesús Vila & Gao — LuPNT (ION GNSS+ 2023, Stanford NavLab): otevřený simulátor lunárního PNT.
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811: otevřená analýza dat GNSS.
• 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: reduced-dynamic OD pro GRAIL, empirická hranice zrychlení, kterou fit LRO reprodukuje.