• Répétez la minute où le GNSS s'éteint
• Nouveautés de la version 0,40, Nouveautés de la version 0,39, Nouveautés de la version 0,38 et 0,38 en détail : notation jammertest, les indicateurs propres du récepteur, entrées machine, synchronisation temporelle et holdover, paquets de normes, LunaNet AFS, l'aller-retour de laboratoire, kshana-bench, l'observatoire, exportateurs, optique, navigation de l'utilisateur spatial et infrastructure lunaire
• Kshana Studio et chaque page du Studio
• Capacités : le tableau des domaines, chaque type de scénario par famille, chaque commande, chaque surface
• Comment se déroule une exécution, Missions
• Preuves : le registre, domaines de capacités
• Installer, Architecture (et les diagrammes), assistant d'IA
• Éditions, Recherche, Citer, Licence
• Référence : utilisation, format de scénario, sortie, organisation du dépôt, FAQ, dépannage, gestion des versions, feuille de route, contribuer, documentation

Exécutez n'importe lequel avec kshana example <scenario> > s.toml && kshana s.toml : les scénarios sont l-band-waterfall-jamming, constellation-multi-gnss-coverage, solar-system-tour et leo-pass-iridium.

Les quatre sont des données fictives et à titre consultatif : elles montrent le format et le comportement du logiciel, non la façon dont un récepteur ou un système se comporte face aux interférences. Exécutez le premier avec kshana receiver-trust examples/maritime-trust/session.toml, le deuxième avec kshana route-exposure sur les échantillons de examples/interference-map/, le troisième avec kshana nmea-scenario scenarios/training/coastal-drag-off.toml --out drag.nmea (à des fins de formation seulement : ne l'envoyez jamais à un équipement de navigation en service), et le quatrième comme dans docs/EVIDENCE-PACKS.md.

Le détail complet, domaine par domaine, suit ; pour un registre de maturité par capacité, voir docs/CAPABILITY.md et docs/VALIDATION.md.

Chaque capacité est accessible sous forme d'API Rust, d'un kind de scénario exécutable, ou des deux. La maturité par capacité — validée, exécutable ou bibliothèque — est suivie dans docs/CAPABILITY.md. Une matrice de vérification vérifiée par machine (src/verification.rs) restitue le renvoi exigence → module → test → référence → état, avec des invariants d'honnêteté testés unitairement qui n'autorisent une étiquette validée que lorsqu'une référence externe indépendante l'étaye — et qui consignent les capacités matérielles/PA (assurance produit) que Kshana ne fournit délibérément pas.

Résultats#

Chaque scénario compare un capteur quantique à son équivalent classique durant une interruption du GNSS d'environ 1,8 h. Les chiffres sont reproductibles (scenario + seed + version).

_{Ce que les capteurs quantiques apportent quand le GNSS a disparu — clock-holdover · graine 42 · tracé avec le moteur 0.40.0, et chaque figure ci-dessus revérifiée par rapport au moteur actuel à chaque compilation par tests/published_figures_still_reproduce.rs · SVG}

L'avantage dépend de la durée de l'interruption et des vibrations, avec un seuil de rentabilité explicite où le classique l'emporte — montré honnêtement sur toute l'échelle de maturité technologique (les chiffres des horloges optiques sont des cibles de démonstrateur au sol ; aucune horloge optique au strontium n'a volé) :

_{Croisement de résilience quantique contre classique — échelle TRL du holdover d'horloge (haut) · carte de l'avantage inertiel avec contour de seuil de rentabilité (bas). Régénérable via cargo run --release --bin crossover_study.}

Erreur de position en navigation à l'estime pendant une interruption du GNSS : le capteur quantique (bleu) reste plat près de la spécification ; le capteur classique (rouge) diverge jusqu'à des dizaines de kilomètres. Généré par Kshana à partir de scenarios/imu-deadreckoning.toml.

Le couronnement montre la thèse de la fusion : le transfert de temps optique inter-satellites maintient verrouillée même une horloge classique, isolant le capteur inertiel comme maillon faible de la suite classique — c'est-à-dire l'inertie quantique et la synchronisation optique ensemble.

Holdover d'horloge pendant une interruption du GNSS : l'horloge optique (bleu) reste dans la spécification de 20 ns pendant toute la marche libre ; l'horloge à puce (rouge) la dépasse en cours de route. Généré par Kshana à partir de scenarios/clock-holdover.toml.

Un autre scénario, orbit-gnss-challenged.toml, tire la disponibilité du GNSS de la géométrie orbitale plutôt que de fenêtres écrites à la main : un engin spatial à l'intérieur de la coquille GNSS est propagé face à une constellation Walker de type GPS, et le nombre de satellites visibles (visibilité directe, occultation par la Terre, masque d'élévation) fixe l'état de la position à chaque pas. Sur une journée, l'utilisateur n'est en position que ~59 % du temps ; l'horloge quantique tient une solution de synchronisation temporelle de 5 ns à travers chaque interruption (disponibilité 1.0), l'horloge à puce seulement ~0.83.

Erreur de synchronisation temporelle sur une journée avec une disponibilité du GNSS tirée de la géométrie orbitale : le nombre de satellites visibles (visibilité directe, occultation par la Terre, masque d'élévation) fixe l'état de la position à chaque pas, de sorte que l'horloge doit traverser chaque interruption en marche libre — l'horloge optique tient la spécification de 5 ns tandis que l'horloge à puce la dépasse. Généré par Kshana à partir de scenarios/orbit-gnss-challenged.toml.

La constellation peut aussi être donnée sous forme de véritables jeux d'éléments à deux lignes (TLE). Un TLE complet (ligne 1 + ligne 2) est propagé avec le modèle SGP4/SDP4 complet — y compris la traînée atmosphérique et les termes lunisolaires d'espace lointain et de résonance de 12 h / 24 h qui comptent pour des orbites GNSS de ~12 h — validé par rapport aux vecteurs officiels AIAA 2006-6753 à un pire cas ≈ 4 mm. scenarios/orbit-sgp4-gps.toml livre un véritable instantané Celestrak gps-ops de la constellation GPS opérationnelle (2021-07-28, 30 satellites) et exige des sommes de contrôle TLE valides — les jeux d'éléments à deux lignes sont des données ouvertes du catalogue de la Force spatiale des États-Unis / du 18e Escadron de défense spatiale, redistribuées par Celestrak (Dr T. S. Kelso, celestrak.org) ; actualisez avec scripts/fetch_tles.sh. Un bloc à ligne 2 seule conserve la propagation analytique à deux corps (scenarios/orbit-real-tle.toml) ; les deux formes peuvent être mélangées dans une même constellation. Une constellation peut tout aussi bien être construite à partir d'un bloc d'enregistrements d'éphémérides diffusées GPS RINEX-3 — le format qu'un récepteur décode — propagés par l'algorithme utilisateur IS-GPS-200 et passés dans la même géométrie (scenarios/orbit-rinex.toml).

Ce que c'est et ce que ce n'est pas#

C'est : un moteur déterministe, léger en dépendances, qui couvre toute la pile PNT — géométrie orbitale, navigation inertielle, fusion GNSS/INS, intégrité, horloges et synchronisation temporelle. Il exécute un scénario (souvent une interruption du GNSS), fait évoluer des modèles d'erreur de capteurs étalonnés à travers l'estimateur approprié, et note le résultat par rapport aux chiffres de mérite opérationnels — en émettant un résultat JSON (JavaScript Object Notation) reproductible et un graphique SVG, depuis une bibliothèque Rust, une interface en ligne de commande (CLI), une extension Python, un module WebAssembly dans le navigateur, un serveur Model Context Protocol (MCP) pour agents d'IA, ou un module d'extension d'IDE JetBrains (environnement de développement intégré).

Ce n'est pas : du matériel de vol, une conception de charge utile quantique, un récepteur complet de signaux GNSS, un simulateur de signaux radiofréquence (RF) ou un banc matériel en boucle, ou un produit d'avionique certifié — et il ne remplace pas MATLAB/Simulink, STK (Systems Tool Kit) ni Orekit ; il se place à côté d'eux et échange des fichiers avec eux. La fidélité du matériel quantique vient de modèles d'erreur publiés, non de cet outil. La maturité détaillée de chaque capacité est documentée dans docs/CAPABILITY.md.

Ce n'est pas (encore) : un moteur de physique d'interférométrie atomique complet (la plupart des capteurs quantiques consomment des coefficients d'Allan/de budget de bruit publiés ; l'accéléromètre CAI (interféromètre à atomes froids) a une couche de premiers principes — phase de Mach–Zehnder, bruit de projection, décroissance du contraste et couplage aux vibrations, plus les systématiques de Coriolis et de déplacement lumineux — mais les systématiques de front d'onde et la résolution d'ambiguïté de frange restent une couche de feuille de route P2 (phase 2 de la feuille de route, la couche de physique quantique), voir ROADMAP.md et docs/QUANTUM-MODELS.md) ; un récepteur GNSS certifié ou matériel (il résout une position PVT (position, vitesse et temps) à point unique à partir de vraies observations de code RINEX (Receiver Independent Exchange Format) — validée sur de vraies données de l'IGS (International GNSS Service) — et sa couche IQ (kshana iq, depuis 0.31.0) acquiert et poursuit des échantillons en bande de base enregistrés ou générés dans le logiciel, comme récepteur d'analyse : il ne pilote pas de matériel radio et n'émet pas, n'est pas un récepteur certifié, et ne fait aucun positionnement par phase de la porteuse (RTK ou PPP)) ; ou une suite complète de conception de mission (il offre des blocs de construction Lambert / porkchop / manœuvre / détermination d'orbite, mais c'est la couche de simulation de performance au-dessus de GMAT (General Mission Analysis Tool)/Orekit, non un remplacement). Assumer ce périmètre est délibéré. Si vous avez besoin de budgets d'erreur d'interféromètre à atomes froids de premiers principes (par exemple de qualité CARIOQA-PMP — Cold Atom Rubidium Interferometry in Orbit for Quantum Accelerometry, Pathfinder Mission Preparation — ou de validation de type X-37B), consultez la feuille de route P2 et prenez contact pour collaborer.

Validation, reproductibilité et honnêteté#

• Chaque terme de bruit est étalonné sur un chiffre publié et cité et validé par rapport à la relation standard (écart d'Allan pour les horloges ; croissance de l'erreur de navigation à l'estime de Groves pour l'inertie ; la conversion synchronisation temporelle→télémétrie pour le transfert de temps). L'état par terme est suivi dans docs/VALIDATION.md comme validated ou not modeled — rien n'est présenté comme validé qui ne le soit pas.
• Reproductible par construction : scenario + seed + engine version → identical bits. scripts/check-reproducible.sh l'impose ; les exécutions quantiques et classiques utilisent des graines indépendantes afin que leur bruit soit non corrélé.
• La maturité est énoncée honnêtement : les chiffres des horloges optiques et des liaisons optiques sont des résultats de cibles / démonstrateurs au sol, non volés.

L'étiquette de preuve sur chaque figure#

Chaque figure et chaque tableau qu'une exécution écrit indique dans quelle mesure on peut s'y fier, et sur quelles lignes du registre cela repose. Le JSON de résultat a une clé evidence, le SVG du graphique une ligne sous le tracé (et un élément <metadata id="kshana-evidence">), et le tableau CSV des lignes de commentaire # evidence: en tête (lues avec comment='#'). Elle nomme un niveau, VALIDATED, MODELLED ou PARTNER, et les identifiants (VM- et huit chiffres hexadécimaux) des lignes de la matrice de vérification que l'exécution a mises en jeu. Le niveau est le plus faible de ces lignes, de sorte qu'une exécution qui s'appuie sur une ligne modélisée est étiquetée MODELLED quel que soit le nombre de lignes vérifiées à côté ; l'étiquette ne peut jamais prétendre à plus que le registre. Les lignes, les statuts et les identifiants sont lus dans la matrice, et non saisis à la main (docs/VERIFICATION-MATRIX.md, docs/SCHEMA.md), et tests/evidence_labels_doc_sync.rs échoue si une figure n'a pas d'étiquette ou si une étiquette est en désaccord avec la matrice.

La validation en un coup d'œil#

Chaque ligne est imposée par un test nommé en CI. Ce tableau est un choix de points forts ; la matrice complète vérifiée par machine compte 401 lignes — 176 VALIDATED, 221 MODELLED, 4 PARTNER (src/verification.rs), avec les preuves complètes (et ce qui n'est honnêtement pas encore vérifié) dans docs/VALIDATION.md et l'artefact kshana-validation-summary.html de chaque version (généré par cargo run --bin validation_report, attesté SLSA — Supply-chain Levels for Software Artifacts).

La colonne État indique la nature de la preuve, conformément à l'échelle de validation ci-dessus : VALIDATED = vérifié par rapport à une référence externe indépendante (données réelles, bibliothèque indépendante ou vecteurs de référence publiés) ; MODELLED = vérifié par rapport à une vérité analytique ou à l'autocohérence d'une simulation (pas de jeu de données externe indépendant). VALIDATED décrit la méthode de vérification, non une réussite/un échec — un écart honnête par rapport à une vraie référence externe reste VALIDATED, tandis qu'une comparaison qu'aucune ligne de la matrice ne nomme comme référence (l'ajustement LRO — Lunar Reconnaissance Orbiter — ci-dessus) est montrée comme MODELLED. Les lignes CI sont des garde-fous de processus, non des chiffres de mérite. Quelques îlots de données réelles (l'horloge au césium mesurée, Stable32 PHASE.DAT, et les vérifications OPS-SAT/ICGEM où les entrées brutes ne portent aucune licence de redistribution) sont conditionnés aux données : le test imprime un avis d'omission et reste vert lorsque l'entrée est absente, et les chiffres de référence publics sont versés au dépôt sous tests/fixtures/. Reproduisez les entrées brutes avec le scripts/fetch_*.sh correspondant.

_{Comment une capacité gagne son étiquette — l'invariant imposé par la CI : pas de référence externe ⇒ ne peut pas être validée · SVG}

_{En haut : chaque ligne validée est étayée par un jeu de données externe, par construction. En bas : SGP4 concorde avec la référence officielle dans chaque régime (pire cas 4,12 mm). SVG · SVG}

_{176 vérifiées · 221 modélisées · 4 du partenaire — 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

Outre run, le module expose run_full (JSON, SVG et le résumé en une ligne à la fois), run_typed, validate_toml, list_kinds / scenario_kinds et error_kind ; voir docs/PYTHON_API.md.

Le paquet npm est le moteur entier compilé en WebAssembly. Dans Node.js, passez le binaire à initSync ; dans un navigateur, await init() le récupère (voir 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));

Un seul moteur, de nombreuses portes d'entrée. Un cœur Rust unique (kshana) exécute chaque scénario, atteint par une CLI, une extension Python, un module WebAssembly dans le navigateur, un serveur MCP pour agents d'IA, et un module d'extension d'IDE JetBrains — tous convergeant vers une seule répartition api::run_toml. À l'intérieur, les paquets de capteurs se branchent sur une interface commune de modèle d'erreur ; à côté se trouvent une couche de référentiels (précession–nutation IAU 2006/2000A et réduction GCRS↔ITRS fondée sur le CIO), une couche d'astrodynamique/numérique (SGP4/SDP4 analytique et un propagateur numérique de Cowell avec son modèle de forces EGM2008/perturbations, la conception de manœuvres et la détermination d'orbite), une couche d'intégrité/GNSS (RAIM/ARAIM, SBAS, le domaine de mesure, le brouillage, le cislunaire), une couche de fusion / PNT alternatif (les estimateurs GNSS/INS et les appariements de cartes de gravité/terrain/magnétisme), une couche d'espace lointain et lunaire (PNT martien radiométrique et la suite PNT lunaire, son niveau de preuve par élément dans la matrice — temps LTC, VLBI, OD + horloge conjointes, réalisation de référentiel, volume de service, PNT différentiel, interopérabilité), une couche d'analyse de mission (budgets de lancement / rentrée / couverture / pointage / passage / liaison et l'environnement de météorologie spatiale), et la couche ouverte d'études de résilience et d'apprentissage automatique (notation de résilience RPCF, l'écart d'optimisme des dégradations RF, et le démonstrateur de PNT à technologie quantique) dont les artefacts reproductibles s'appuient sur les noyaux validés.

Deux crates autonomes, exclues de l'espace de travail, se trouvent à côté du cœur — mcp/kshana-mcp (le serveur MCP, construit sur le SDK rmcp édition 2024) et xval/anise-frames (le recoupement des référentiels ANISE/SPICE, qui tire des dépendances MPL-2.0 (Mozilla Public License 2,0)) — tenues hors du graphe de dépendances de la crate publiée, de Cargo.lock, de la barrière de licences et de la compilation MSRV (version minimale de Rust prise en charge) par la liste exclude du Cargo.toml racine. Le module d'extension JetBrains (ide/jetbrains) est un projet Kotlin distinct. Voir docs/ARCHITECTURE.md pour l'ensemble complet des diagrammes.

Les diagrammes restitués (flux du moteur, carte des modules, distribution) sont dans docs/ARCHITECTURE.md.

Scénarios et rapports

Exportation et interopérabilité

Confiance du récepteur et du navire

IQ GNSS (fichiers du répertoire de travail ; désactivé en mode HTTP)

Correspondance de compliance

Benchmark

Sur quoi repose Kshana Pro. Chaque partie de Pro travaille à partir du moteur ouvert et le laisse inchangé :

• L'optimiseur de conception, l'étude d'incertitude et le dossier de mission exécutent des scénarios du moteur ouvert par l'interface publique du moteur et calculent chaque nombre à partir des résultats des exécutions. Chaque sortie conserve le niveau VALIDATED, MODELLED ou PARTNER que le moteur ouvert a attribué à chaque chiffre, jamais un niveau supérieur.
• Les jumeaux numériques d'horloge utilisent le modèle d'horloge du moteur ouvert et son estimateur de déviation d'Allan : un jumeau est calibré sur le budget d'Allan publié du dispositif, puis vérifié en estimant la déviation d'Allan du jumeau avec l'estimateur ouvert.
• Les études de compromis exécutent chaque option d'architecture comme un scénario du moteur ouvert, sans changement, et classent les options selon une figure de mérite lue dans le résultat de chaque exécution.
• La surveillance de campagne lit ses chiffres dans les résultats des exécutions du moteur ouvert des scénarios d'un paquet, et les compare à la dernière exécution réussie.
• La coexistence spectrale lit chaque nombre physique dans des exécutions du moteur ouvert des types leo-signal et constellation-design, et n'ajoute que la somme sur les satellites en vue et le classement des plans.
• Le service de tâches sur site exécute des scénarios ouverts et Pro avec le même moteur et stocke chaque résultat tel que l'exécution l'a renvoyé.
• Les paquets de preuves consignent, pour chaque exécution, l'empreinte du scénario que le moteur ouvert appose sur son résultat, de sorte qu'un chiffre d'un paquet peut être reproduit en réexécutant son scénario.
• Outillage d'ingénierie système et de programme. L'outillage d'ingénierie système fondée sur les modèles (MBSE) et de programme de Kshana Pro vérifie les exigences d'un programme par rapport à des exécutions du moteur ouvert : il importe des exigences au format de valeurs séparées par des virgules (CSV), ou sous la forme d'un sous-ensemble documenté du Requirements Interchange Format (ReqIF) ou d'un texte Systems Modeling Language version 2 (SysML v2), évalue chaque critère d'acceptation, avec son unité, par rapport aux valeurs qu'une exécution a écrites, et produit une matrice de références croisées de vérification (VCRM), un modèle SysML v2, un rapport d'impact des changements et un paquet de preuves hors ligne. Il ne réexécute et ne recalcule rien, et ne lit que ce que le moteur ouvert publie : le result.json de chaque exécution (les champs qu'un critère nomme, leurs unités, l'estampille de reproductibilité composée de l'empreinte du scénario, de la graine, de la version du moteur et de la version du schéma, ainsi que l'étiquette de l'exécution et les niveaux de ses chiffres), son report.json (type, enregistrement de reproductibilité et étiquettes de capacités), le fichier de scénario (son empreinte, son type, sa graine et ses paramètres), le schéma des unités des champs (l'unité, la provenance et le niveau de preuve de chaque champ) et la matrice de vérification (l'étiquette VALIDATED, MODELLED ou PARTNER de chaque capacité).

Assistance et services professionnels#

Kshana est gratuit et open source sous l'AGPL-3.0 et développé et maintenu professionnellement par Ashforde® OÜ (Estonie). Le moteur ouvert est complet et utilisable seul. Pour les organisations qui ont besoin de plus, Ashforde® OÜ propose :

• Assistance commerciale et intégration — intégration de Kshana dans votre chaîne d'outils, scénarios sur mesure et correctifs prioritaires.
• Modèles de capteurs sur mesure — calibrés sur votre matériel, y compris des modèles de résilience soumis à contrôle des exportations, maintenus dans une surcouche privée.
• Kshana Pro — outillage propriétaire d'ingénierie système fondée sur les modèles (MBSE) et de programme, qui vérifie les exigences d'un programme par rapport à des exécutions du moteur ouvert et produit une matrice de références croisées de vérification (VCRM), un modèle Systems Modeling Language version 2 (SysML v2), un rapport d'impact des changements et un paquet de preuves hors ligne. Il ne réexécute rien et ne lit que les sorties publiées du moteur : le result.json et le report.json de chaque exécution, le fichier de scénario, le schéma des unités des champs et les étiquettes de la matrice de vérification (la liste complète se trouve sous Éditions).
• Outillage Kshana Pro de conception, d'incertitude et de mission — le front de Pareto d'un espace de conception, l'incertitude et la sensibilité sur des milliers d'exécutions, et un dossier de mission en une commande avec une matrice de vérification et un PDF ; voir docs/PRO.md.
• Surveillance de campagne, coexistence spectrale et service de tâches de Kshana Pro — un pipeline qui échoue lorsqu'un chiffre surveillé se dégrade, des plans de signaux testés par rapport aux signaux ouverts de navigation par satellite dans les deux sens, et une file de tâches sur site avec un registre de livraison chaîné par empreintes ; voir docs/PRO.md.
• Formation et conseil sur l'analyse de performance PNT quantique/classique.

Voilà le modèle open-core : le moteur est, et reste, sous licence ouverte ; l'activité qui le fait vivre repose sur l'expertise, l'assistance et les extensions propriétaires — pas sur des frais de licence. Contact : contact@ashforde.org · ashforde.org.

Installer et compiler#

Nécessite une chaîne d'outils Rust (≥ 1,88, le champ rust-version de Cargo.toml ; développé avec la 1,93).

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

Usage#

Exécutez n'importe quel scénario ; la CLI s'aiguille sur le champ kind du scénario et écrit <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html et <scenario>.report.json à côté de lui — ainsi que <scenario>.table.csv pour les types qui publient un tableau. Le rapport (une page HyperText Markup Language (HTML) et un document JSON de même contenu) comporte un résumé exécutif, chaque entrée avec son unité, les résultats et les graphiques, les tableaux de balayage, de Monte-Carlo ou de chaîne d'une campagne, une chronologie des événements, l'étiquette VALIDATED / MODELLED / PARTNER et la source de chaque capacité utilisée par l'exécution, ce qui n'est pas modélisé, et un enregistrement de reproductibilité (version du moteur, condensats Secure Hash Algorithm 256-bit (SHA-256), graine, plateforme et commande exacte). Il s'imprime en un fichier PDF (Portable Document Format) propre depuis le navigateur sur papier A4 ou Letter ; le moteur n'écrit lui-même aucun PDF. Voir 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> écrit à côté du scénario des fichiers CZML (le Cesium Language), KML (Keyhole Markup Language), GeoJSON (Request for Comments 7946), des éphémérides .e Ansys STK (Systems Tool Kit) et des enregistrements SigMF (Signal Metadata Format), et --import-route <route.geojson> injecte une ligne GeoJSON dans les types qui suivent une trajectoire. Chaque format est validé par rapport à sa spécification publiée, et un scénario auquel un format ne s'applique pas en explique la raison : voir docs/INTEROP.md.

Autres modes de la CLI — analyser un scénario, fournir des données réelles d'orientation de la Terre, ou exécuter une suite entière :

# 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 d'animation. --animate svg|html|frames|all écrit <scenario>.animation.svg (images clés Cascading Style Sheets (CSS), sans script), <scenario>.animation.html (lecture, pause, défilement, vitesse et panneaux synchronisés, sans ressource externe) et <scenario>.frames/ (frame_0000.svg, … plus manifest.json avec le nombre d'images par seconde et la durée). Une campagne rejoue ses phases et ses alarmes, une exécution de spectre sa cascade ; le thème suit prefers-color-scheme et prefers-reduced-motion affiche l'image finale. Il restitue les propres échantillons de l'exécution, identiques à l'octet près lors d'une nouvelle exécution, et n'ajoute aucune preuve. Voir docs/ANIMATION.md.

Un manifeste de suite est un petit fichier TOML (Tom's Obvious, Minimal Language) — un title et un tableau scenarios = [ … ] de chemins de scénarios — que le moteur exécute à tour de rôle, en regroupant chaque résultat (avec ses étiquettes MODELLED / VALIDATED) dans un unique artefact d'étude autodescriptif. Voir scenarios/quantum-pnt-demonstrator.suite.toml.

Rôle d'interopérabilité. Kshana est la couche de simulation de performance qui se place à côté de la chaîne d'outils de post-traitement, et non un remplacement de celle-ci : fournissez sa sortie RINEX à RTKLIB ou gLAB pour une solution de position, et utilisez sa sortie SP3 comme produit d'orbite précise pour des outils comme Ginan — Kshana répond à la question quelle résilience une architecture PNT donnée procure avant que vous ayez de vrais signaux, dans des formats que ces outils savent déjà ingérer (--export-sp3, ou export_sp3 = true dans un scénario orbit, écrit <scenario>.sp3). La même orbite peut être publiée sous forme d'éléments moyens CCSDS OMM de la filière des normes (--export-omm, ou export_omm = true, écrit <scenario>.omm) — un message OMM 502,0 KVN (notation clé = valeur) par satellite défini par TLE, portant le vrai numéro de catalogue NORAD (North American Aerospace Defense Command), la désignation internationale COSPAR (Committee on Space Research) et l'époque de chaque objet, pour tout consommateur compatible OMM, au lieu d'un jeu d'éléments à deux lignes sur mesure.

Exemple de sortie (holdover d'horloge — remarquez comment les figures de mérite d'intégrité et de sécurité sont rapportées) :

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

L'erreur de synchronisation temporelle au 95e centile (p95) de l'horloge optique est de 1.20e-4 ns : le résumé affiche les petites valeurs avec leurs chiffres significatifs plutôt que de les arrondir à 0.0. security indique n/a (no attack) parce que ce scénario ne configure aucune attaque, il n'y a donc rien à détecter. Le résultat JSON porte néanmoins la borne analytique de détectabilité du leurrage de chaque horloge dans fom.security (0,997 pour l'horloge optique, 0,000 pour l'horloge atomique à puce, dont le propre bruit sur la fenêtre de surveillance dépasse la spécification de 20 ns), et son bloc figure_tiers marque ce chiffre applicable: false. Le type de scénario spoof note la détection par rapport à une attaque injectée. figure_tiers attribue aussi à chaque chiffre rapporté son niveau de vérification — VALIDATED (vérifié par rapport à une référence indépendante) ou MODELLED — et la ligne de la matrice de vérification dont le niveau est tiré. Le scénario d'orbite rapporte en outre un bloc de géométrie — fraction d'échantillons avec une solution, meilleure et médiane dilution de précision de position (PDOP) et précision de position — à côté du résultat d'horloge.

Lisez attentivement ces deux nombres. security est une borne analytique de détectabilité du leurrage dérivée de la stabilité de chaque horloge — elle n'a de sens que face à un scénario de leurrage configuré et n'est pas un détecteur RAIM multisatellite. integrity désigne ici l'autocohérence du filtre (fraction des échantillons de la coupure situés dans sa propre borne en k sigma), et non un chiffre d'intégrité HPL/VPL aéronautique. Voir docs/INTEGRITY.md.

Pour une véritable intégrité autonome du récepteur, le type de scénario integrity (scenarios/integrity-raim.toml) exécute un RAIM réel par instantané et par séparation de solutions (de style ARAIM) sur la géométrie de constellation propagée : il calcule les niveaux de protection (HPL/VPL) horizontaux et verticaux à chaque époque et rapporte la fraction d'époques qui respectent les limites d'alerte configurées, avec un diagramme d'intégrité de Stanford pour la classification erreur par rapport au PL (niveau de protection).

Artefacts d'étude reproductibles

Quatre études ouvertes régénèrent chacune un artefact déterministe à l'octet près (graine fixe) à partir d'une seule commande — les nombres derrière les études sur le croisement quantique contre classique, l'écart d'optimisme des perturbations RF, la notation de la résilience PNT et le niveau de protection de la synchronisation temporelle :

# 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

Chaque artefact consigne la version du moteur, les graines et une empreinte de configuration, et porte une étiquette MODELLED/VALIDATED honnête. Les sondes sur données réelles (*_probe) exécutent le même pipeline sur des enregistrements que vous fournissez localement ; aucun jeu de données n'est livré dans le dépôt. L'étude de l'écart d'optimisme des perturbations RF est rédigée dans la prépublication arXiv:2606,22054, et le niveau de protection conditionnel de la synchronisation temporelle (tpl_jammertest ci-dessus) dans la prépublication arXiv:2606,24210 (voir Citer).

Les études publiées sur le PNT lunaire (arXiv:2607,06212 DOP des balises de surface, arXiv:2607,02566 observabilité par VLBI et arXiv:2610,23871 observabilité par longueur d'arc cislunaire) voient leurs affirmations de géométrie, de dilution de précision, de prédiction en temps réel du référentiel et des paramètres d'orientation de la Terre (EOP), d'orbites rétrogrades distantes et de télémétrie RF recoupées indépendamment dans tests/validate_p*.rs avec des références distinctes (scipy.special.j1, une résolution DOP NumPy indépendante par (HᵀH)⁻¹, une nouvelle analyse NumPy des mêmes lignes finals2000A de l'IERS, et la NASA/JPL Three-Body Periodic Orbit Database). Ce sont des vérifications de régression supplémentaires sur la suite lunaire modélisée ; elles ne changent pas le décompte de la matrice vérifié par machine.

Format de scénario#

Les scénarios sont du TOML déclaratif. Un champ kind de premier niveau sélectionne le paquet — cinquante au total (clock est la valeur par défaut si le champ est omis) : 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 (banc d'évaluation de la détection par apprentissage automatique des perturbations RF — corpus synthétique étiqueté + harnais ROC/AUC indépendant du détecteur + écart d'optimisme en distribution / hors distribution), quantum-trade (compromis PNT quantique contre classique avec ingestion d'ADEV mesurée + enveloppe de résilience hors GNSS ; MODELLED), space-weather (indices solaires/géomagnétiques + température exosphérique de Jacchia-71 + densité thermosphérique pilotée par l'activité sur l'atmosphère statique ; MODELLED), oem-interop (passerelle d'import/aller-retour CCSDS OEM pour les éphémérides GMAT/Orekit/STK ; MODELLED), le trio d'analyse de mission launch-window (azimut de lancement à deux corps / changement de plan / opportunités), reentry (corridor de rentrée balistique d'Allen-Eggers), eo-coverage (géométrie de fauchée / GSD / accès / revisite en observation de la Terre), space-packet (CCSDS 133,0 TM/TC — télémesure/télécommande — mise en trame Space Packet — structure exacte des bits, aller-retour vérifié), et attitude-budget (couple de gradient de gravité à 3 degrés de liberté + budget d'erreur de pointage en RSS), passes (prédiction des passages de lever/coucher en station sol — AOS/TCA/LOS, élévation maximale, accès), et link-budget (équation de liaison CCSDS/DSN à sens unique — FSPL / Eb·N₀ / marge / fermeture) ; telecom-timing (erreur de temps en holdover, MTIE et TDEV vérifiés par rapport aux gabarits ITU-T) ; spectrum (toute la bande L du GNSS comme une seule densité spectrale de puissance : une cascade fréquence-temps sous une chronologie scénarisée de brouilleur à onde continue, à bande étroite, à balayage ou à bruit adapté, le rapport brouilleur sur signal par bande et la densité de puissance porteuse sur bruit effective à partir du coefficient de séparation spectrale, et l'entrée et la sortie d'enregistrements Signal Metadata Format (SigMF) avec estimations spectrales de Welch ; les spectres des signaux VALIDATED par rapport aux valeurs des manuels, le scénario de brouilleur MODELLED ; voir docs/SPECTRUM.md ; le même type trace des panneaux des bandes UHF, S et C avec des signaux conçus pour l'orbite terrestre basse) ; leo-signal (conceptions de signaux de positionnement, navigation et synchronisation temporelle en orbite terrestre basse pour n'importe quel système : spectres à bande limitée, gigue de poursuite de code et précision de télémétrie, recherche d'acquisition et durée, séparation spectrale par rapport au GPS et à Galileo, tolérance au brouillage et compromis de l'UHF à la bande C, à partir de préréglages publics comme Xona Pulsar, Iridium, Starlink et CentiSpace ou de conceptions en ligne ; les formes closes et le Doppler LEO VALIDATED, les conceptions MODELLED ; voir docs/LEO-SIGNAL.md) ; solar-system (le Soleil, les planètes, Pluton, la Lune et sept grandes lunes à une même époque — positions, constantes, temps de lumière et trajectoires orbitales ; positions des planètes VALIDATED par rapport à JPL Horizons) et body-pnt (positionnement autour de n'importe lequel de ces corps avec une constellation de navigation locale et une liaison d'espace lointain depuis la Terre ; MODELLED) ; campaign (des types existants composés en une chronologie de mission enchaînée avec transmission de l'état entre les phases, un balayage de paramètres, un ensemble Monte-Carlo à graine, ou plusieurs scénarios sous une même condition partagée ; MODELLED, voir docs/CAMPAIGNS.md) ; constellation-design (motifs Walker delta et étoile, listes d'éléments et conceptions multicouches avec préréglages GPS, Galileo, BeiDou et GLONASS, et couverture et dilution de précision sur une grille de latitude/longitude ; le générateur et le DOP global GPS VALIDATED par rapport aux documents de service publiés, voir docs/CONSTELLATION-DESIGN.md) ; leo-pass (un passage de satellite de positionnement, navigation et synchronisation temporelle (PNT) en orbite terrestre basse (LEO) et son bilan de liaison bande par bande, à partir de n'importe quelle constellation et de n'importe quelle conception de signal : angles de visée, Doppler et taux de Doppler, affaiblissements ITU-R dus à la pluie, aux gaz, à la scintillation et à la pénétration des bâtiments, densité de puissance porteuse sur bruit par rapport aux satellites GNSS MEO en vue, ionosphère du premier ordre et combinaisons sans ionosphère, et un bilan de solution à faible énergie, sondage de l'ionosphère à partir de chaque paire de bandes, et moniteurs de leurrage par cohérence du Doppler et de la géométrie du passage et par cohérence entre bandes ; les termes ITU-R et l'enveloppe Doppler d'utilisateur statique VALIDATED, le passage MODELLED, voir docs/LEO-PASS.md) ; leo-navmsg (le message d'éphéméride et d'horloge diffusé d'un satellite PNT en orbite terrestre basse (LEO), pour n'importe quelle orbite et porteuse : un ajusteur d'une orbite de vérité intégrée vers le jeu képlérien de Galileo, ce jeu avec des polynômes de correction le long de la trace, transverses et radiaux, le modèle à 22 paramètres de Liu et al. 2025 ou le polynôme ECEF à horloge nulle ATOMIC ; erreur de distance dans le signal dans l'espace (SISRE) en fonction de l'intervalle d'ajustement et de la période de mise à jour, une vérification de continuité d'une mise à jour en cours de passage, la propre trame binaire documentée de Kshana avec un contrôle de redondance cyclique CRC-24Q et un budget de quantification, et un bloc de style RINEX-4 étiqueté extension de Kshana ; les poids SISRE, l'algorithme utilisateur de Galileo et le CRC-24Q VALIDATED, les ajustements MODELLED ; préréglages facultatifs pour Xona Pulsar, Iridium, Starlink, CentiSpace, un système représentatif en bande C, ATOMIC et Celeste IOD ; voir docs/LEO-NAVMSG.md) ; le trio PNT fusionné MEO + LEO leo-pvt (positionnement Doppler à partir de la vitesse de distance en orbite terrestre basse (LEO), solutions conjointes de pseudodistances GNSS + LEO avec biais inter-systèmes et DOP en fonction du nombre de satellites LEO, couverture polaire et arctique, et transfert de temps LEO vers l'UTC — sur n'importe quelle constellation, avec des préréglages facultatifs comme les signaux d'opportunité de Xona Pulsar, Iridium et Starlink ; l'enveloppe Doppler LEO VALIDATED par rapport aux chiffres publiés d'Iridium et de Xona), leo-ppp (convergence du positionnement ponctuel précis avec GNSS seul et avec augmentation LEO, comparée à Li et al. 2019) et ntn-positioning (positionnement par réseau non terrestre 5G à partir de la borne de Cramér-Rao de la largeur de bande du signal), MODELLED hormis cette enveloppe, voir docs/LEO-PNT-FUSION.md ; leo-pnt-chain (un système LEO-PNT de bout en bout : une conception leo-signal portée par une bande leo-pass, le C/N0 du passage et l'erreur de distance dans le signal dans l'espace du message de navigation transmis à une solution fusionnée leo-pvt et à une convergence leo-ppp, chaque transmission étant listée ; MODELLED, voir docs/LEO-PNT.md, qui est aussi la vue d'ensemble de chaque type et scénario LEO-PNT, y compris les campagnes de résilience, un scénario par domaine d'expérimentation et un par secteur d'utilisateur final) ; la suite PNT lunaire lunar-vlbi, lunar-joint-od-clock, lunar-frame-realisation, moonlight-service-volume, lunar-differential-pnt, lunar-interop-export ; le démonstrateur PNT quantique quantum-time-transfer, quantum-gnss-free-nav, quantum-anomaly-detect ; et les types de recherche sur la sécurité des signaux, le cislunaire et la résilience en couches lunar-attack-surface, realtime-frame-eop, lunar-time-budget, hybrid-optical-rf, cislunar-observability, conflict-resilience — le trio d'analyse de mission et ces types plus récents étant tous MODELLED (chacun avec un noyau en forme close validé ; voir la matrice). Champs communs : seed, une grille [time], une chronologie de disponibilité [gnss] (le pilote de la coupure), et des blocs par capteur avec des chaînes provenance citant la source de chaque chiffre. Exemple (horloge) :

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

Champs facultatifs (désactivés en leur absence) : une horloge peut ajouter flicker_floor (plancher d'Allan du bruit de fréquence en 1/f — modulation de fréquence) ; un capteur inertiel peut ajouter gyro_bias et q_arw (biais du gyroscope et marche aléatoire angulaire), ainsi que bias_instability et q_aa (le plancher d'Allan d'instabilité de biais et la marche aléatoire d'accélération) — ensemble, un budget d'erreur d'accéléromètre à axe unique (1 degré de liberté) (VRW/ARW — marche aléatoire de vitesse/angulaire — et instabilité de biais). C'est le budget d'erreur qu'exécute le paquet de scénarios inertial livré. Par ailleurs, la bibliothèque comporte désormais un navigateur à composants liés à 3 axes vérifié (src/inertial/{attitude,mechanization,imu_errors}.rs) : attitude par quaternion avec compensation du coning/sculling, une mécanisation NED complète (termes de rotation de la Terre et de transport, gravité de Somigliana WGS-84), et un modèle déterministe d'erreurs de centrale inertielle dans lequel le facteur d'échelle, le désalignement, la sensibilité à g, la quantification et la rampe de vitesse sont modélisés (IEEE Std 952-1997, la norme IEEE de spécification et de procédure d'essai des gyroscopes, §A.2 ; Groves 2013 §4,3). Ce chemin à 3 axes est maintenant raccordé à un paquet GNSS/INS à couplage lâche exécutable (kind = "gnss-ins") : un EKF à 15 états d'erreur discipline la solution à composants liés par rapport à des solutions bruitées tant que le GNSS est disponible, puis poursuit en roue libre pendant la coupure, en rapportant l'erreur horizontale fusionnée par rapport à la dérive de l'INS seul en boucle ouverte. Une mise à jour pseudodistance à couplage serré est aussi disponible (elle forme l'innovation dans le domaine des distances, et continue donc de corriger avec moins de quatre satellites). Un scénario de holdover d'horloge peut ajouter runs (> 1) pour exécuter un ensemble Monte-Carlo — chaque figure de mérite est alors rapportée sous forme de moyenne avec une dispersion du 5e au 95e centile, et le graphique grise la bande de confiance de l'erreur (voir scenarios/clock-ensemble.toml).

Un scénario fusion (mêmes blocs que hybrid) exécute deux estimateurs de Kalman indépendants — un pour l'état de l'horloge, un pour l'état de position — disciplinés par le GNSS et assistés par un transfert de temps optique, et rapporte une figure de mérite combinée de holdover. Les deux blocs ne partagent aucune covariance croisée : c'est une paire empilée de budgets d'erreur, et non un véritable filtre conjoint couplé horloge + position (la covariance entre blocs est un élément de la feuille de route). Voir scenarios/fusion-pnt.toml.

Un scénario spoof injecte un leurrage temporel — l'un des quatre types [attack.shape] (linear_ramp, step_jump, meaconing, replay ; un simple rate_ns_per_s reste accepté comme rampe linéaire) — et exécute le détecteur de leurrage de chaque horloge. Le détecteur est un test d'énergie χ²₁ / de Neyman–Pearson bilatéral sur la statistique de surveillance assistée par l'horloge : le seuil est fixé à partir d'un budget cible de fausses alarmes target_pfa, et la probabilité de non-détection P_md est rapportée à la fois en forme close et par Monte-Carlo (mc_runs essais par hypothèse — les deux concordent à quelques ×1/√N près). La figure de mérite de sécurité est 1 − P_md à l'amplitude opérationnellement nuisible (spécification), de sorte qu'une horloge calme qui détecte un leurrage de la taille de la spécification obtient ≈ 1 et qu'une horloge bruitée qui le manque souvent obtient moins (voir scenarios/spoof-attack.toml, scenarios/spoof-meaconing.toml).

Un scénario gnss-sim est une simulation dans le domaine des mesures : pour chaque satellite visible, il synthétise la pseudodistance ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath et le Doppler L1, avec l'ionosphère monofréquence de Klobuchar ([iono], IS-GPS-200 §20.3.3.5.2.5) et la troposphère zénithale de Saastamoinen projetée par la fonction de projection de Niell (1996) ([tropo]). Les résidus alimentent le RAIM par instantané pour obtenir les HPL/VPL à chaque époque, et la pseudodistance, le Doppler, le C/N₀ et les corrections iono/tropo de chaque satellite sont émis dans le tableau JSON gnss_measurements. C'est un simulateur direct (il génère des mesures à partir d'une vérité connue), et non un récepteur/solveur — une exécution sans bruit reproduit la géométrie plus les corrections au niveau sous-millimétrique (voir scenarios/gnss-sim-raim.toml).

Un scénario jamming modélise l'interférence RF comme un bilan de liaison : un [jammer] (position ECEF, power_dbw d'émission, type) augmente le rapport brouilleur sur signal chez un [receiver] qui observe une [constellation] Walker. À partir de la géométrie (affaiblissement en espace libre et gain de l'antenne de réception selon la direction), il calcule le J/S de chaque satellite, le C/N₀ effectif par l'équation anti-brouillage standard (gain de traitement par désétalement × le facteur de séparation spectrale Q ; Kaplan & Hegarty §9,4), et signale la perte d'accrochage sous un seuil de poursuite configurable — en rapportant une figure de mérite availability_under_jamming. Un brouilleur à large bande de 10 W à 1 km neutralise entièrement le récepteur (J/S ≈ 72 dB) ; le même brouilleur à 100 km ne fait que dégrader les liaisons (voir scenarios/jamming-demo.toml).

Un scénario sweep réalise une étude de compromis : il fait varier un parameter (threshold_ns, duration_s, quantum_q_wf ou classical_q_wf) de start à stop sur steps points selon une scale lin ou log, enregistre une metric (par exemple holdover_s) pour les deux horloges, et trace les deux courbes. Le scénario de base se place sous [base] (voir scenarios/sweep-clock-stability.toml).

Un scénario sweep-nd généralise cela à n'importe quel paquet et à un nombre quelconque d'axes : il fait varier des clés TOML pointées d'un scénario [base] (de n'importe quel kind) sur le produit cartésien des [[axes]], réexécute chaque nœud de la grille, et enregistre des metrics données sous forme de chemins JSON pointés dans le résultat (par exemple classical.fom.holdover_s). Il fonctionne pour chaque paquet parce qu'il opère à la frontière TOML/résultat ; les exécutions natives évaluent la grille en parallèle (sans dépendance supplémentaire, wasm retombe sur le séquentiel) et la sortie est déterministe et ordonnée par lignes (voir scenarios/sweep-nd-inertial.toml).

Un scénario orbit dérive la chronologie [gnss] de la géométrie au lieu de la rédiger — donnez une orbite [user], une [constellation], un mask_deg d'élévation et les deux blocs d'horloge. Il rapporte aussi la précision de position à partir de la géométrie des satellites ; le paramètre facultatif sigma_uere_m (erreur de distance équivalente utilisateur à 1 sigma, 1 m par défaut) convertit la dilution de précision de position en un sigma de position. L'orbite de l'utilisateur peut être rendue excentrique avec eccentricity et argp_deg, et j2 = true ajoute la dérive séculaire due à l'aplatissement de la Terre (voir scenarios/orbit-molniya.toml). La constellation peut aussi être réelle : donnez à [constellation] un bloc tle d'ensembles d'éléments à deux lignes et les satellites en sont extraits (voir scenarios/orbit-real-tle.toml). Ajoutez un ou plusieurs blocs [[constellations]] pour du multi-GNSS (par exemple GPS + Galileo ; voir 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

Les types alt-PNT sans GPS naviguent sans aucun GNSS, en faisant correspondre une séquence de champ mesurée à une carte au moyen d'un filtre particulaire. Un scénario gravity-map fait voler une trace à travers un champ d'anomalie de gravité en harmoniques sphériques et la retrouve à partir de la lecture d'un gravimètre à atomes froids (scenarios/gps-denied-gravity-nav.toml) ; un scénario terrain-nav fait de même par rapport à un MNT d'élévation SRTM (TERCOM/SITAN, scenarios/terrain-nav.toml) ; et un scénario combined-altpnt fusionne gravité + magnétisme IGRF + terrain dans un seul filtre (scenarios/combined-altpnt.toml).

Un scénario lunar-integrity évalue le PNT cislunaire : il exécute une passe de niveau de protection ARAIM au pôle Sud lunaire par rapport à un ensemble de relais LunaNet/LNIS et rapporte honnêtement l'écart d'intégrité — un σ_URE lunaire d'environ 30 m fait monter le niveau de protection bien au-dessus d'une limite d'alerte de 50 m, de sorte que le service est indisponible selon des règles d'intégrité de type aéronautique (scenarios/lunanet-araim.toml).

Un scénario lunar-time-offset rapporte le taux d'horloge relativiste Terre–Lune — la base d'une échelle de Temps coordonné lunaire (LTC/TCL). Une identité post-newtonienne de premiers principes additionne la différence de potentiel propre (potentiel du géoïde L_G de l'IAU moins le potentiel propre de la surface de la Lune) et le terme cinétique de la Lune (Doppler du second ordre) pour obtenir un taux séculaire de ≈ 57 µs/jour, rapporté avec la plage publiée de 56–59 µs/jour ; il donne aussi le décalage LTC−TT accumulé sur un horizon et un ensemble à variance inverse (une horloge papier lunaire). MODELLED — le chiffre principal dépend de la référence (géoïde terrestre contre sélénoïde lunaire, fenêtre de moyennage), ce qui explique qu'une plage, et non un nombre unique certifié, soit rapportée (scenarios/lunar-time-offset.toml).

Voir scenarios/ pour au moins un exemple travaillé de chaque type (92 types, 193 fichiers de scénario .toml + 1 manifeste de suite — plusieurs types fournissent plus d'un exemple). Tous les types n'ont pas un fichier portant leur nom : lunar-integrity → scenarios/lunanet-araim.toml et gravity-map → scenarios/gps-denied-gravity-nav.toml en sont deux parmi plusieurs. Listez les types répartissables à tout moment avec les erreurs de cargo run -- --validate <file>, le list_kinds() de Python, ou l'outil MCP list_scenario_kinds.

Sortie#

L'artefact de résultat est un JSON versionné et autodescriptif : séries temporelles par pas, figures de mérite notées, spécifications des modèles actifs (avec provenance), graine, une empreinte du scénario — de sorte que tout graphique peut être reproduit à partir du fichier — et, pour chaque horloge, une adev_curve ([{tau_s, adev, n_samples, noise, edf, ci_lo, ci_hi}]) : la déviation d'Allan chevauchante sur des temps de moyennage espacés par octaves — la manière standard de lire la stabilité d'une horloge — désormais avec une bande de confiance à 95 % propre au type de bruit pour chaque point (le type en loi de puissance de l'enregistrement est identifié à partir de sa pente d'Allan modifiée, et l'intervalle du χ² utilise les degrés de liberté effectifs correspondants du NIST SP 1065). Le terrain de jeu du navigateur la restitue sous forme de graphique log-log « Clock stability (ADEV) ». (MDEV, TDEV et HDEV sont disponibles comme estimateurs de la bibliothèque ; la courbe du résultat exporté est l'ADEV chevauchante.) Chaque champ, avec ses unités et un renvoi à sa source, est documenté dans docs/SCHEMA.md.

Chaque graphique est autodescriptif. Le terrain de jeu du navigateur, l'export *.chart.svg de la CLI et la fiche de résultats HTML (HyperText Markup Language) apposent tous sur chaque image de graphique un pied de page qui indique Kshana v<version> · scenario <hash> · kshana.dev. Le scenario <hash> correspond aux 12 premiers caractères hexadécimaux de l'empreinte du scénario de l'exécution — un condensat SHA-256 (le Secure Hash Algorithm sur 256 bits) de la définition canonique du scénario (graine, seuils, paramètres des modèles, fenêtres GNSS, …) ; les rapports d'intégrité et lunaires, qui ne portent pas d'empreinte propre, se rabattent sur un SHA-256 de la source du scénario. C'est la même empreinte que celle affichée dans le résumé d'une ligne et dans le JSON du résultat, de sorte qu'un graphique enregistré ou collé porte toujours sa version, le scénario exact qui l'a produit (pour une reproduction bit à bit) et la source — modifiez une entrée quelconque et l'empreinte change.

Les figures de mérite suivent les figures de mérite PNT opérationnelles standard :

Ces termes sont nouveaux pour vous ? Chacun est défini en langage clair dans le glossaire.

Organisation du dépôt#

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#

Dois-je comprendre la physique quantique pour l'utiliser ? Non. Si vous savez exécuter une ligne de commande, vous savez exécuter Kshana. Commencez par le guide en langage clair ; cherchez les termes dans le glossaire.

S'agit-il d'une conception de matériel quantique ou d'un logiciel de vol ? Non. C'est un simulateur de performance. La fidélité au matériel quantique provient de modèles d'erreur publiés, pas de cet outil. Voir Ce que c'est / n'est pas.

Les résultats quantiques sont-ils réalistes, ou du marketing ? Chaque paramètre est cité d'après une fiche technique ou un article, chaque modèle est validé par rapport à une relation de manuel, et la maturité est étiquetée honnêtement dans VALIDATION.md — y compris le fait qu'aucune horloge optique au strontium n'a volé. Le moteur est neutre : le quantique et le classique utilisent le même code avec des nombres publiés différents.

Puis-je compter sur l'accord de deux exécutions ? Oui — les exécutions sont déterministes : scenario + seed + engine version → bit-identical output, garanti par scripts/check-reproducible.sh.

Puis-je l'utiliser depuis Python ou dans un navigateur ? Oui — voir Installer : les exemples Python et WebAssembly s'y trouvent. Les deux appellent le même moteur.

Comment modéliser mon propre capteur ? Écrivez un scénario .toml avec les chiffres publiés de votre capteur dans les champs provenance. Voir Format de scénario et les exemples dans scenarios/.

Est-il gratuit pour un usage commercial ? Oui — sous l'AGPL-3.0, y compris dans un cadre commercial, tant que vous respectez le copyleft de l'AGPL (notamment : si vous modifiez Kshana et l'offrez via un réseau, vous devez offrir à ces utilisateurs votre source modifiée). Si cela ne vous convient pas — par exemple si vous devez intégrer Kshana dans un produit propriétaire ou exploiter un service réseau fermé — une licence commerciale est disponible auprès d'Ashforde® OÜ ; voir LICENSING.md et Assistance.

Dépannage#

cargo build échoue avec une ancienne chaîne d'outils. Kshana nécessite Rust ≥ 1,88. Mettez à jour avec rustup update.

La compilation de l'extension Python échoue à l'édition de liens sur macOS (Undefined symbols … _Py…). Une extension Python résout ses symboles au chargement. maturin définit automatiquement le bon indicateur de l'éditeur de liens — utilisez maturin develop --features python plutôt qu'un simple cargo build.

La compilation Python se plaint que l'interpréteur est plus récent que ce que PyO3 connaît. Définissez PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 (les wheels abi3 sont compatibles vers l'avant entre versions de CPython).

La compilation WebAssembly ne trouve pas la cible. Installez-la une fois avec rustup target add wasm32-unknown-unknown, puis wasm-pack build --target web -- --features wasm.

Où est passée ma sortie ? Chaque exécution écrit <scenario>.result.json, <scenario>.chart.svg, <scenario>.report.html et <scenario>.report.json à côté du fichier .toml d'entrée, et aussi <scenario>.table.csv pour les types qui publient un tableau. Tous sont ignorés par git par conception.

Gestion des versions et publications#

Kshana suit le versionnage sémantique. Tant que la version est antérieure à 1.0, le schéma public des scénarios et des résultats peut encore changer ; les changements incompatibles sont signalés explicitement dans le CHANGELOG.md. Chaque résultat est reproductible à partir de scenario + seed + engine version.

Chaque étiquette vX.Y.Z publie automatiquement tous les canaux, dans un ordre unique — la suite de tests complète s'exécute d'abord sur le commit étiqueté, rien n'est publié tant qu'elle ne passe pas, et ensuite le pipeline vérifie que chaque registre sert bien la nouvelle version (docs/RELEASING.md). Les canaux :

La version du crate / de l'image / du registre du serveur MCP suit celle du moteur (il embarque la bibliothèque) ; le plugin JetBrains a sa propre version (il appelle votre binaire kshana installé).

Feuille de route#

Voir ROADMAP.md pour la feuille de route par phases, CHANGELOG.md pour l'historique des versions publiées, et docs/CAPABILITY.md pour la feuille de route par capacité. L'ordre de priorité est le suivant : d'abord les preuves de synchronisation temporelle et de holdover pour les infrastructures critiques (gabarits télécoms, holdover plus long avec vieillissement et bruit de scintillation, ingestion de données d'horloge mesurées) ; ensuite la méthode neutre de comparaison quantique contre classique (résultats étiquetés MODELLED jusqu'à ce que les données mesurées d'un partenaire les promeuvent) ; et navigation lunaire / cislunaire et en espace lointain maintenue, non étendue comme priorité. La réduction de référentiel précise ITRF est maintenant livrée — la chaîne complète GCRS↔ITRS IAU 2006/2000A fondée sur le CIO (mouvement du pôle + nutation sous la seconde d'arc), vérifiée bit à bit par rapport à SOFA/ERFA et recoupée indépendamment avec ANISE (SPICE en Rust pur) à ≤ 3,6 m sur l'orbite GNSS. Les éléments à court terme comprennent la fusion de phase de la porteuse à couplage serré et la mise à disposition du navigateur GNSS/INS à couplage lâche/serré dans davantage de paquets ; le moteur de navigation radiométrique en espace lointain / sur Mars est arrivé dans v0.17.0 (validé en simulation). La couche de physique quantique est un élément P2 : l'accéléromètre CAI est désormais simulé à partir des premiers principes (phase de Mach–Zehnder, bruit de projection, décroissance du contraste, couplage des vibrations), tandis que les capteurs d'horloge/de transfert de temps sont encore pilotés par des coefficients publiés d'Allan/de budget de bruit. Le TEME↔ECEF fondé sur le GMST, les systèmes de temps IERS à secondes intercalaires (UTC/TAI/TT/UT1), la propagation d'orbite SGP4/SDP4 (v0.7.0, validée par rapport aux vecteurs AIAA 2006-6753) et le paquet de fusion gnss-ins exécutable ont tous été livrés, et la vitesse inertielle est exposée en aval. Un détecteur stochastique actif de leurrage temporel (test d'énergie de Neyman–Pearson / χ²₁ avec P_fa/P_md Monte-Carlo et une figure de mérite de sécurité de 1−P_md), un modèle de brouillage par bilan de liaison (J/S → C/N₀ effectif → perte d'accrochage), la disponibilité multiconstellation, un budget d'erreur d'IMU à axe unique (1 degré de liberté), deux estimateurs de Kalman indépendants (horloge + position) rapportés comme une figure de mérite combinée, la géométrie réelle des constellations à partir des TLE, un rapport sous forme de fiche de résultats HTML, la disponibilité GNSS dérivée de la géométrie et la dilution de précision à partir d'orbites képlériennes avec excentricité et dérive J2, des bandes de confiance Monte-Carlo, des balayages de paramètres d'études de compromis, un terrain de jeu WebAssembly dans le navigateur, et des liaisons facultatives Python (PyO3) et WebAssembly (wasm-bindgen) ont été intégrés à main.

Contribuer#

Voir CONTRIBUTING.md. En bref : les tests passent (cargo test), les deux scripts de garde passent, Conventional Commits, et une entrée CHANGELOG.md [Unreleased] pour chaque changement visible par l'utilisateur. La participation est régie par notre code de conduite. Pour signaler un problème de sécurité, voir la politique de sécurité — merci de ne pas ouvrir de ticket public pour des vulnérabilités.

Documentation#

Références principales#

Références indépendantes et normes de validation — les autorités externes auxquelles les vérifications de Kshana sont rattachées :

• Vallado, Crawford, Hujsak & Kelso — Revisiting Spacetrack Report #3 (AIAA 2006-6753 ; données de test) : le jeu de vérification SGP4/SDP4 auquel Kshana concorde à 4,12 mm, et les exemples de référentiels résolus par rapport auxquels la chaîne TEME→ITRF est vérifiée.
• IAU SOFA / ERFA — les routines de référence de temps et de référentiel par rapport auxquelles la nutation IAU 2000A et la réduction CIO GCRS↔ITRS sont validées bit à bit.
• Petit & Luzum (dir.) — IERS Conventions (2010), IERS TN (Technical Note) 36 (orientation de la Terre, mouvement du pôle et normes de référentiel).
• Riley — Handbook of Frequency Stability Analysis, NIST SP 1065 (relations de la déviation d'Allan et série de référence NBS14 ; NBS = l'ancien National Bureau of Standards des États-Unis).
• Pedregosa et al. — scikit-learn: Machine Learning in Python, JMLR 12 (2011) : les implémentations de référence de ROC/AUC, de matrice de confusion et de précision/rappel/F1 auxquelles la plateforme d'évaluation des perturbations RF est rapproché exactement (tests/eval_metrics_reference.rs).
• Virtanen et al. — SciPy 1,0, Nature Methods 17 (2020) : optimize.nnls, stats.chi2 et linalg.expm — les routines de référence par rapport auxquelles l'ajustement NNLS de l'ADEV mesurée du compromis quantique, les bandes de cohérence du χ² et la covariance du bruit de processus d'horloge de van Loan sont validés (tests/scipy_reference.rs).
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024) : utilisé à la fois comme antériorité ouverte (voir Comparaison et antériorité ouverte ci-dessous) et comme référence indépendante du DOP à laquelle le calcul de GDOP/PDOP/HDOP/VDOP/TDOP est rapproché à 1e-6 près (tests/dop_reference.rs).
• Montenbruck & Gill — Satellite Orbits: Models, Methods and Applications (Springer) : les modèles de forces à la base de l'ajustement du modèle de forces aux éphémérides précises des agences.
• 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 (les familles halo/NRHO que le correcteur différentiel CR3BP reproduit).

Physique des dispositifs et des méthodes — les sources citées derrière les modèles de capteurs :

• Origlia, Schiller, Bongs et al. — arXiv:1503,08457 (horloge à réseau optique de strontium, objectif spatial).
• Oelker et al., Nature Photonics (2019) — doi:10.1038/s41566-019-0493-4 (horloge Sr de laboratoire, 4,8×10⁻¹⁷).
• Templier et al., Science Advances (2022) — arXiv:2209,13209 (triade d'accéléromètres quantiques hybrides).
• Groves, Principles of GNSS, Inertial, and Multisensor Integrated Navigation — tutoriel de l'IEEE AESS (Aerospace and Electronic Systems Society) (dépôt Discovery de l'University College London) (croissance de l'erreur d'estime).
• 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) (transfert optique bidirectionnel de temps et de fréquence ; la liaison optique inter-satellites modélise son budget de non-réciprocité d'après ces travaux).
• Betz — Binary Offset Carrier Modulations for Radionavigation, NAVIGATION 48(4) (2001), doi:10.1002/j.2161-4296.2001.tb00247.x (la modulation BOC et la théorie de séparation spectrale derrière src/navsignal.rs).
• Kaplan & Hegarty (dir.) — Understanding GPS/GNSS: Principles and Applications (3e éd., Artech House, 2017) : l'équation du C/N₀ effectif en anti-brouillage et la gigue de bruit thermique du suivi de code par DLL précoce–tardif que les modèles de signal de navigation et de brouillage utilisent.

Comparaison et antériorité ouverte — les outils et les études par rapport auxquels Kshana se situe :

• Humphreys et al. — TEXBAT (le Texas Spoofing Test Battery ; ION — Institute of Navigation — GNSS 2012) : les paramètres de la batterie de tests de leurrage par rapport auxquels le détecteur multicouche est caractérisé.
• González et al. — NaveGo (2017) : les profils d'erreur de navigation inertielle ouverts et validés utilisés comme référence de base classique.
• Iiyama, Casadesús Vila & Gao — LuPNT (ION GNSS+ 2023, Stanford NavLab) : simulateur PNT lunaire ouvert.
• Knowles, Kanhere, Neamati & Gao — gnss_lib_py, SoftwareX 27 (2024), doi:10.1016/j.softx.2024.101811 : analyse ouverte de données 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 : DO réduite-dynamique de GRAIL, le plancher d'accélération empirique que l'ajustement LRO reproduit.