État de la validation

À propos des tolérances. « Vérifié » ci-dessous signifie qu'un test d'étalonnage affirme que la statistique simulée correspond à la relation de référence à l'intérieur d'un seuil appliqué, actuellement 20–25 % d'erreur relative (moyennée sur les graines) pour les relations d'Allan et de budget de bruit. L'accord médian observé est souvent bien plus serré (quelques pour cent), mais la borne garantie est le seuil, et non la médiane. Lorsqu'un nombre comme « ~2 % » apparaît, il s'agit d'une observation typique, et non de la tolérance appliquée. Voir Affirmations et réalité.

La règle de promotion#

Une ligne de la matrice de vérification contrôlée par machine (src/verification.rs) est VALIDATED seulement lorsqu'une référence indépendante indépendante de Kshana concorde avec l'implémentation dans une tolérance énoncée avant l'exécution de la comparaison, dans un test exécuté dans la barrière de contrôle. Cette section est le seul endroit où la règle est écrite ; la matrice, le texte de chaque ligne et les notes de version s'y réfèrent.

Les types de référence indépendante acceptés#

Deux autres critères tranchent les cas limites. Les deux sont adoptés pour la version 0,30.

• P1, une valeur détaillée publiée. Une valeur détaillée publiée, calculée à partir de la même forme fermée que celle qu'implémente la ligne, compte comme un vecteur de référence publié, lorsque la publication est indépendante de Kshana et que la comparaison fixe une tolérance énoncée. La valeur doit être imprimée sous forme de nombre dans la publication (une valeur lue sur un graphique ne compte que si l'incertitude de lecture est inférieure à la tolérance énoncée), et le test doit faire calculer cette valeur par Kshana à partir des entrées de la publication ; comparer une constante au document dont elle a été copiée est un contrôle de transcription, pas P1.
• P2, une bibliothèque numérique indépendante. Une bibliothèque numérique indépendante telle que numpy ou LAPACK (Linear Algebra PACKage) qui recalcule une grandeur d'algèbre linéaire définie de façon unique sur des entrées indiquées compte comme une bibliothèque indépendante. La bibliothèque doit effectuer l'étape de décomposition, d'inversion, de résolution ou de moindres carrés par son propre algorithme, sur des entrées validées avec le jeu de test ; l'affirmation validée porte alors sur l'algèbre linéaire sur ces entrées, et non sur les grandeurs physiques d'un scénario représentatif. Un script qui réévalue une forme fermée scalaire avec l'arithmétique de numpy est une seconde implémentation de notre cru, pas P2.

Conditions valables pour tous les types : la référence indépendante n'est ni écrite, ni exécutée, ni publiée par ce projet (la série d'articles propre à ce dépôt n'est donc pas indépendante de lui) ; la tolérance figure dans le test et a été fixée avant la première comparaison ; un test conditionné par des données, qui est ignoré lorsque ses données publiques sont absentes, le signale lorsqu'il est ignoré.

Ce qui ne compte pas#

• Notre propre seconde implémentation : un second chemin de code dans ce crate (ReferenceImpl), ou un script de ce dépôt qui réévalue la même forme fermée.
• La concordance avec nos propres sorties antérieures : références figées (goldens), points de non-régression, instantanés, ou un tableau issu des propres articles de ce projet.
• Une transcription des constantes d'une citation : vérifier un coefficient, un préréglage, une valeur de fiche technique ou une fiche de paramètres par rapport au document dont ils ont été copiés.
• Un choix de conception : une allocation, une pondération, un seuil, une limite d'alerte ou un scénario représentatif. Il n'y a pas de vérité externe pour un choix.
• Une identité interne : une intégrale numérique comparée à sa propre forme analytique, un aller-retour, une inversion, un test de propriété ou de monotonie.
• Une exécution d'intégration contre un hôte réel (IntegrationRun) : charger un module dans un vrai serveur Signal K ou OpenCPN, ou alimenter un consommateur TCP avec la sortie d'une vraie passerelle, et vérifier que l'hôte accepte l'entrée et affiche l'état attendu. Cela montre que la tuyauterie fonctionne. L'hôte n'est pas une référence indépendante pour une valeur que porte l'intégration ; il n'y a donc rien d'externe à comparer, et une telle ligne (la ligne des intégrations maritimes) est MODELLED, et non VALIDATED. IntegrationRun est son propre type de référence indépendante, autorisé seulement sur les lignes MODELLED : integration_run_only_on_modelled_rows dans src/verification.rs échoue si une ligne VALIDATED le porte, et validated_rows_require_an_external_oracle exige déjà que chaque ligne VALIDATED soit ExternalDataset.
• La vraisemblance sur des entrées réelles : des données réelles utilisées uniquement comme entrée, avec des assertions d'ordre de grandeur plutôt qu'une comparaison à une valeur externe.
• Une tolérance choisie après avoir vu la comparaison.

Comment la règle est appliquée#

Chaque ligne VALIDATED déclare, dans validated_oracle_basis() de src/verification.rs, sur quel type elle repose (Measured, Library, Reference, P1 ou P2), la source indépendante (citée à partir du texte de référence indépendante de la ligne elle-même) et l'unique test qui porte la comparaison. Les tests unitaires placés à côté du tableau échouent lorsqu'une ligne VALIDATED n'est pas déclarée ou l'est deux fois, lorsqu'une déclaration nomme une ligne qui n'est pas VALIDATED, lorsque la source déclarée n'est pas celle que nomme le texte de référence indépendante de la ligne ou est Kshana lui-même, lorsque le test déclaré n'est pas un test que cite la ligne, ou lorsqu'une ligne P2 ne nomme aucune bibliothèque numérique indépendante. tests/verification_rows_declare_an_oracle_basis.rs exige ensuite que le test déclaré existe sur le disque comme un véritable #[test] qui n'est pas ignoré. Ce que la machine ne peut pas vérifier, c'est si le test nommé compare bien à la source déclarée ; cela reste une lecture humaine. Les décomptes par type ne sont pas saisis ici : le tableau fait foi.

Lignes VALIDATED existantes réexaminées selon la règle#

La règle a été appliquée aux lignes existantes comme aux promotions futures.

• Lignes P1 nommées par l'étude de validation 0,30, chacune étayée : bilan de liaison unidirectionnel (le tableau de contrôle de conception X-band Galileo du JPL Pub 82-76, reconstitué à partir de ses lignes de détail à 4.6e-3 dB de perte en espace libre) ; formes fermées en bande limitée pour tout signal de télémétrie (90,3 pour cent de la puissance du lobe principal et la gigue cohérente early-late publiée) ; Doppler maximal d'un satellite de navigation en orbite terrestre basse (les chiffres publiés de Xona Pulsar X1 et d'Iridium) ; Doppler maximal vu par un utilisateur statique depuis une orbite LEO ou MEO (tableau 1 de l'article Pulsar, 20 valeurs) ; Doppler qu'un récepteur au sol doit gérer depuis un satellite de navigation LEO (les mêmes chiffres publiés à partir d'une orbite effectivement parcourue). Chaque publication est indépendante de Kshana, imprime ses nombres, et le test énonce sa tolérance.
• Autres lignes reposant sur P1, trouvées lors du réexamen, chacune étayée : compromis de conception du code de télémétrie (la corrélation croisée de Gold publiée à −23,9 dB) ; temps-coordonnée lunaire (Ashby et Patla 2024, dont le contrôle croisé de la vitesse de la Lune par rapport à DE440 est un contrôle Library) ; densités spectrales de puissance de signaux en bande L en forme fermée (valeurs Q de Kaplan et Hegarty) ; retard ionosphérique au premier ordre par bande (le rapport de retard de groupe de l'IS-GPS-200) ; pondérations de l'erreur de distance du signal dans l'espace en moyenne globale (le tableau de Montenbruck, Steigenberger et Hauschild 2018).
• Lignes P2 nommées par l'étude, chacune étayée : information de Fisher et observabilité de Cramér–Rao (numpy eigh/inv) ; identifiabilité du datum lunaire ; jauge couplée du référentiel et de l'échelle de temps lunaires ; chaîne autonome d'observabilité de défaut en réseau libre (SVD numpy/SciPy, décomposition en valeurs singulières). Chacune recalcule une grandeur d'algèbre linéaire définie de façon unique sur des entrées validées, par un algorithme différent du solveur propre de Jacobi de Kshana.
• Autres lignes reposant sur P2, trouvées lors du réexamen, chacune étayée : dérivation de priorité MCDA (analyse de décision multicritère) (le vecteur propre AHP, processus de hiérarchie analytique, par SciPy/LAPACK ; la table d'indice aléatoire qu'elle reproduit aussi est une transcription et n'est pas comptée) ; variance de dérive en holdover d'horloge (expm de SciPy sur la matrice augmentée de Van Loan) ; réalisation du référentiel lunaire (une résolution d'Umeyama par SVD numpy) ; formation de faisceau CRPA (antenne à diagramme de réception contrôlé) (résolution complexe LAPACK) ; noyau de niveau de protection ARAIM lunaire (l'inverse LU de RTKLIB avec les quantiles de SciPy) ; cohérence référentiel/dynamique lunaire entre fournisseurs (un ajustement par moindres carrés SVD numpy de trois éphémérides publiées).
• Signalées lors du premier passage, rétablies sur une base solide à la ronde 2 de l'exécution 0,30. Trois lignes avaient été signalées comme non étayées par la règle écrite. Chacune repose désormais sur une comparaison préenregistrée avant la récupération de son jeu de test ; aucune ligne n'est donc signalée ; un test unitaire placé à côté de validated_oracle_basis() fige la liste (désormais vide).
  • Intégrité (RAIM/ARAIM/SBAS). Les tests cités n'affirmaient auparavant que la vraisemblance sur la géométrie réelle de l'IGS (International GNSS Service). La ligne repose maintenant sur trois références indépendantes de type bibliothèque : la séparation des solutions à hypothèses multiples de l'ARAIM du Airborne Design Document v4.2 par rapport à Stanford MAAST pour ARAIM 2 (270 cas réels, pire écart de VPL 2.2e-3 m contre 0,05 m) ; la détection et l'exclusion RAIM par instantané par rapport à RTKLIB raim_fde (2016 décisions identiques sur 2016) avec le niveau de protection de pente ; et les niveaux de protection SBAS DO-229E L1 par rapport à Stanford MAAST sur de vraies diffusions WAAS (2868 paires à 1.6e-5 m près). La ligne dit clairement que les fonctions à sigma uniforme raim::araim_raim et raim::araim_dual_raim ne respectent pas l'ADD et que la comparaison SBAS L5 bifréquence est un constat.
  • Positions des planètes dans tout le système solaire à partir des éléments képlériens de Standish du JPL. Le seuil a posteriori de deux fois l'erreur nominale est remplacé par un seuil préenregistré : RMS au plus égal à la valeur du tableau 8.10.1 de l'Explanatory Supplement par planète et par composante, par rapport à JPL Horizons DE441, avec la scission de la Terre et la rotation ICRF couvertes.
  • Temps de lumière entre corps du système solaire. Le solveur de temps de lumière est désormais comparé aux temps de lumière d'Horizons à 1e-6 s près sur les positions DE441, un seuil préenregistré qui n'hérite pas du seuil de position.
• Lignes MODELLED que les deux politiques rendent promouvables (seulement par l'exécution 0,30 ligne par ligne, jamais par ce texte) : sous P1, la borne de géolocalisation d'émetteur TDOA/FDOA (différence de temps et de fréquence d'arrivée), le couplage entre taux d'horloge relativiste et référentiel, les gabarits de synchronisation de l'UIT-T (Secteur de la normalisation des télécommunications) (seulement pour les valeurs de gabarit que les Recommandations impriment sous forme de nombres ; les points de rupture transcrits contrôlés par rapport à eux-mêmes ne comptent pas) et la borne de positionnement 5G par réseau non terrestre (seulement si une valeur détaillée publiée est trouvée) ; sous P2, la cécité d'intégrité en mode commun, le niveau de protection temporel scalaire MHSS (séparation des solutions à hypothèses multiples) et le blanchiment GLS (moindres carrés généralisés). Les deux lignes de benchmark d'intégrité temporelle (le classifieur du diagramme d'intégrité de Stanford et le calculateur de couverture d'intégrité) relèvent d'une classification à base de règles, et non de l'algèbre linéaire ; P2 ne les atteint donc pas ; elles ont besoin d'un outil indépendant, et le seul trouvé (gLAB) porte une licence non commerciale.
• Cohérence avec des refus antérieurs. Le contrôle de Vallado de la ligne de fenêtre de lancement serait maintenant admissible sous P1 si son test calcule l'exemple détaillé imprimé ; le plan 0,30 la promeut plutôt par Orekit. Le tableau de croisement du temps lunaire par classe d'horloge reste MODELLED : le tableau qu'il reproduit provient de l'article propre à ce projet, qui n'est pas indépendant.

Statut : FM blanche et FM de marche aléatoire validées ; vieillissement modélisé et corrigé ; FM de scintillement modélisée et validée (désactivée par défaut dans les scénarios cités).

Maturité : les chiffres de l'horloge optique sont l'objectif orienté spatial sur du matériel au sol -- aucune horloge optique à strontium n'a volé. Les horloges Sr de laboratoire atteignent 4.8e-17 (Oelker et al. 2019, Nature Photonics). Les chiffres du CSAC proviennent d'un composant commercial déployé.

Relations : Riley, NIST SP 1065, éq. 67 -- FM blanche sigma_y^2(tau)=h0/(2 tau) ; FM de marche aléatoire sigma_y^2(tau)=(2 pi^2/3) h_-2 tau, soit de façon équivalente q_rw*tau/3 pour un processus de Wiener de fréquence de diffusion q_rw.

Paquet 2 — navigation à l'estime inertielle (centrale inertielle quantique)#

Mise en perspective honnête : l'avantage de l'atome froid est la stabilité de biais à long terme (~2600 fois plus faible), qui domine lors d'une longue interruption du GNSS via 0,5bT^2. Le bruit à court terme est comparable (quantique ~22 contre classique ~20 ug/sqrtHz) — le capteur quantique gagne le marathon, pas le sprint. Maturité : les accéléromètres à atomes froids en sont au stade du laboratoire/des débuts (JRC122785), le quartz de qualité navigation est déployé.

Paquet 3 — transfert de temps (optique contre radiofréquence (RF), liaison optique inter-satellites)#

Mise en perspective honnête : le chiffre optique est une cible de synchronisation en orbite au niveau de la picoseconde (non volée). Le plancher des laboratoires optiques terrestres est d'environ 1 fs (bien meilleur) ; une liaison micro-onde bien conçue (la liaison micro-onde (MWL) d'ACES (Atomic Clock Ensemble in Space), ~0,3 ps) peut rivaliser avec l'optique, de sorte que la référence de base « RF = 0,5 ns » désigne précisément un TWSTFT ordinaire. La conversion en distance est unidirectionnelle (distance = cdt) ; le bidirectionnel/aller-retour la divise par deux (distance = cdt/2).

Paquet 4 — fusion hybride (synthèse)#

Compose le paquet 1 (horloge), le paquet 2 (inertiel) et le paquet 3 (transfert de temps) en une seule suite PNT (positionnement, navigation et synchronisation temporelle). La suite doit maintenir À LA FOIS la synchronisation temporelle (< spécification de temps) et la position (< spécification de position) dans les limites ; pnt_holdover_s est la durée jusqu'à ce que l'une des deux soit dépassée. Un transfert de temps optique inter-satellites (ISL) facultatif resynchronise l'horloge pendant l'interruption (aide au temps seulement — la position n'est pas resynchronisée, puisque le transfert de temps donne le temps, pas la position).

Résultat : la suite tout-quantique tient un PNT complet pendant une interruption de 1,8 h ; la suite tout-classique est limitée par la position (l'IMU de qualité navigation dépasse sa limite en premier). Le transfert de temps optique ISL maintient verrouillée même l'HORLOGE classique, ce qui isole le capteur inertiel comme maillon faible de la suite classique — l'argument central en faveur de l'inertiel quantique et de la synchronisation optique ensemble.

Géométrie — disponibilité du GNSS à partir des orbites#

Mise en perspective honnête : il s'agit d'une couche géométrique déterministe (orbites circulaires, Terre sphérique de rayon moyen 6371 km, ligne de visée pure). Elle établit la disponibilité et la précision de position géométrique (dilution de précision × un budget représentatif d'erreur de distance) à partir de la géométrie réelle, et non une solution de navigation à éphémérides précises. La référence orbit-gnss-challenged.toml place un engin spatial à l'intérieur de la couche GNSS : il ne maintient un point que ~59 % de la journée, l'horloge quantique maintient une solution de synchronisation temporelle de 5 ns à travers chaque interruption (disponibilité 1,0) tandis que l'horloge à l'échelle d'une puce tient ~0,73.

Propagateur numérique (Cowell) et modèle de forces#

Le propagateur numérique (src/propagator.rs) intègre un modèle de forces hiérarchique (src/forces.rs) avec les intégrateurs adaptatifs (src/integrator.rs). Chaque terme ci-dessous est validé par rapport à une vérité analytique ou à une forme fermée dérivée à la main ; les perturbations sont désactivées par défaut, de sorte que les références figées publiées sont intactes. Le modèle composé est aussi contrôlé de façon croisée par rapport à un autre outil : tests/numerical_cowell_propagator_reference.rs exécute 11 cas LEO et GTO (orbite de transfert géostationnaire), 275 époques horaires, par rapport au propagateur DormandPrince853 d'Orekit 12,2, et les niveaux conservatifs (deux corps → J2–J6 → Soleil/Lune → PRS boulet de canon) concordent à un pire cas de 0,08 m sur 24 h (VALIDATED dans la matrice) ; le niveau de traînée est seulement caractérisé (333 m) et reste MODELLED.

Portée honnête : les valeurs par défaut publiées de ForceModel intègrent le champ zonal. Le champ tesséral EGM2008 de haut degré (src/gravity_sh.rs, degré/ordre 70), les marées solides/océaniques/atmosphériques (src/tides.rs) et le terme d'entraînement des référentiels de Lense–Thirring sont maintenant implémentés et composés dans le modèle de forces d'ajustement d'éphéméride précis (src/precise_od.rs — voir ci-dessous). Le champ tesséral est aussi un terme facultatif du ForceModel de Cowell (propagator::Geopotential, désactivé par défaut), validé par rapport à HolmesFeatherstoneAttractionModel d'Orekit 12,2 jusqu'au degré/ordre 70 (6 cas sur 24 h, pire |Δr| 0,036 m ; tests/cowell_tesseral_orekit_oracle.rs). Deux évaluateurs de champ existent : l'historique acceleration (dérivées partielles sphériques ; valide jusqu'au degré ~180 loin des pôles ; sorties figées) et acceleration_hf (colonne directe modifiée de Holmes–Featherstone 2002, gradient sans 1/cos φ ; valide jusqu'au degré 2190 à toute latitude). EGM2008 jusqu'à 2190 se charge à l'exécution (from_gfc_file, scripts/fetch_egm2008.sh, non inclus). acceleration_hf concorde avec Orekit 12,2 à 7.3e-17 m/s² en huit points jusqu'au degré 2190 ; il reste MODELLED parce que pyshtools a manqué le seuil préenregistré près des pôles (un contrôle mpmath place l'erreur dans pyshtools ; xval/high-degree-gravity/). Une orbite de 200×200 sur 24 h concorde avec Orekit à 0,13 m, mais son contrôle de sensibilité préenregistré au degré 70 a échoué (0,73 m < 1 m), de sorte que les degrés 71–200 sont caractérisés, et non validés, en orbite (xval/cowell-tesseral-200-orekit/). La densité thermosphérique NRLMSISE-00 (NRLMSISE : Naval Research Laboratory Mass Spectrometer and Incoherent Scatter Radar Extended atmosphere model) est portée (src/nrlmsise00.rs : identique au bit près au portage C du domaine public sur 720 points, à 1.9e-6 en valeur relative de pymsis, les 17 cas de test publiés reproduits ; tests/nrlmsise00_reference.rs) et constitue un niveau facultatif de densité de traînée (forces::DensityModel, ForceModel::drag_density ; la valeur par défaut reste le modèle statique de Vallado). Cela valide le portage, et non la précision du modèle par rapport à la densité mesurée. Le Soleil et la Lune DE440 (DE : Development Ephemeris) forment un niveau d'éphéméride facultatif (ForceModel::with_ephemeris). L'ombre SRP d'une Terre aplatie WGS-84 est facultative (ForceModel::srp_shadow), et concorde avec le rapport d'éclairement d'Orekit 12,2 à 7.4e-9 près sur 2400 géométries (tests/srp_oblate_shadow_orekit_oracle.rs) ; sa variante à assombrissement centre-bord n'a pas de référence indépendante externe (MODELLED). Le niveau de traînée NRLMSISE-00 concorde avec la propre traînée NRLMSISE-00 d'Orekit 12,2 sur 24 h à 0,03 m près pour jusqu'à 142 km de déplacement dû à la traînée (tests/drag_tier_orekit_oracle.rs, VALIDATED sous les conventions partagées). Un contrôle croisé GMAT (General Mission Analysis Tool) reste à faire.

Marées sur le géopotentiel (src/tides.rs)#

Corrections variables dans le temps ΔC̄_nm, ΔS̄_nm aux coefficients de Stokes (IERS Conventions 2010, chapitre 6), validées par rapport aux propres nombres publiés des conventions — et non par rapport à un autre outil.

Manœuvres et conception de trajectoire (src/maneuver.rs)#

Portée honnête : pas d'optimiseur de trajectoire, pas de branches de Lambert à révolutions multiples, et un modèle héliocentrique synthétique circulaire coplanaire (pas d'éphéméride planétaire DE, de sorte qu'un contrôle croisé C3 Terre–Mars par GMAT n'a pas été exécuté).

Détermination d'orbite (OD) (src/orbit_determination.rs, src/batch_ls.rs)#

| OD par lot en vitesse de distance / azimut-élévation avec un masque d'élévation | modelled (comparaison externe, un seuil préenregistré manqué) | tests/od_tracking_measurements_reference.rs : 8 scénarios par rapport aux moindres carrés par lot d'Orekit 12,2 avec des mesures géométriques instantanées personnalisées ; ensembles visibles identiques, valeurs de mesure à 5.8e-8 m / 6.3e-10 m/s / 1.4e-13 rad près, matrice de transition d'état à 1.2e-14 près, états bruités à 1,74 cm près et RMS par type à 2.7e-4 près ; le seuil préenregistré d'état sans bruit ≤ 1 cm est manqué sur 2 scénarios sur 4 (1,46 et 1,74 cm ; l'estimation propre d'Orekit se situe aussi loin de sa vérité simulée, celle de kshana à 1e-8 m près). Voir xval/od-measurements-orekit/RESULTS.md. |

Portée honnête : l'OD pédagogique utilise des stations inertielles fixes, un repère topocentrique à Terre sphérique et des mesures géométriques instantanées (sans temps de lumière, aberration, réfraction ni rotation de la Terre) ; la matrice de transition d'état du chemin vitesse de distance/angles est variationnelle (intégrée par RK4 avec des dérivées partielles analytiques à deux corps + J2), et non en forme fermée ; il n'y a pas de filtre séquentiel pour la vitesse de distance ou les angles. Le chemin à distance seule conserve sa jacobienne par différences finies. (Le moteur d'ajustement d'éphéméride à forces complètes ci-dessous porte sa propre matrice de transition d'état variationnelle.)

Validation du modèle de forces par ajustement d'éphéméride (src/precise_od.rs)#

Un estimateur précis par moindres carrés par lot à observation de position et forces complètes : le géopotentiel tesséral EGM2008 (évalué dans le référentiel lié à la Terre par la réduction CIO) composé avec le troisième corps Soleil/Lune, la SRP, la traînée, la RG (relativité générale) de Schwarzschild/Lense–Thirring et les marées ci-dessus, ajusté à une piste de points de position inertiels avec une jacobienne par matrice de transition d'état variationnelle. Validé sur des données synthétiques, où la vérité est l'intégrateur propre de Kshana, de sorte que chaque résidu est celui de l'estimateur et non celui de la dynamique.

Portée honnête : l'onde synthétique utilise des paramètres d'orientation de la Terre nominaux (EOP : UT1 (Universal Time 1, temps de rotation de la Terre) ≈ TT (Terrestrial Time), sans mouvement du pôle) — exacts pour l'auto-récupération, puisque le même modèle génère et ajuste l'arc. Les validations par jeux de données d'agences superposent des EOP finals2000A réels et une vérité SP3/SPK (SPK : noyau d'éphéméride planétaire) à ce moteur par la chaîne de référentiel CIO (src/eop.rs, tests/agency_galileo.rs, tests/agency_swarm.rs, tests/agency_lro.rs).

Orbites précises réelles d'agences (tests/agency_galileo.rs, tests/agency_swarm.rs, tests/agency_lro.rs)#

Navigation par carte de gravité / PNT alternatif (src/gravimeter.rs, src/mapmatch.rs, src/particle_filter.rs, src/altpnt/terrain.rs)#

Portée honnête : le champ de gravité est de bas degré + des mascons synthétiques, et non le jeu complet de coefficients EGM2008/EIGEN (EIGEN : European Improved Gravity model of the Earth by New techniques) ; le canal magnétique s'appuie sur le champ principal lisse de l'IGRF plus des mascons d'anomalie crustale synthétiques (une vraie carte crustale à haute fréquence reste à faire) ; le champ de terrain de CI pour les benchmarks de point de navigation est le DEM synthétique autonome, tandis que le lecteur .hgt lui-même est maintenant validé en CI par rapport à une vraie tuile SRTM v3 versée (ci-dessus) ; les vraies tuiles en pleine résolution restent conditionnées par #[ignore]. Un Monte-Carlo de l'erreur de représentation des cartes reste à faire. Les trois navigateurs sont maintenant câblés dans le moteur de scénarios par kind= (gravity-map, terrain-nav, combined-altpnt).

Modèle d'erreur INS / IMU — validation par rapport aux fiches techniques (src/inertial/)#

Le modèle d'erreur stochastique de l'IMU est validé par rapport à des spécifications publiées de fiches techniques / jeux de données de fabricants — jamais par rapport à une valeur produite par Kshana lui-même. Le passage d'une spécification en unités de terrain au modèle de bruit en SI (Système international d'unités) est l'identification standard par l'écart-type d'Allan (Riley, NIST SP 1065 §5 ; norme IEEE (Institute of Electrical and Electronics Engineers) 952) : le coefficient de marche aléatoire N est l'ADEV avec recouvrement lu à τ = 1 s sur la pente en τ⁻¹ᐟ², et le coefficient d'instabilité de biais est le plateau plat d'Allan (tests/imu_allan_spec.rs, hermétique — aucun téléchargement).

Portée honnête : ceci valide le modèle d'erreur stochastique par rapport aux coefficients d'Allan des fiches techniques. Le jeu de données de véhicule i2Nav-WHU (WHU : université de Wuhan) KF-GINS sert de vérification distincte, conditionnée par la disponibilité des données : l'EKF à boucle fermée sur l'état d'erreur, faiblement couplé, avec le modèle de bras de levier GNSS, est une ligne VALIDATED de la matrice de vérification (EKF GNSS/INS faiblement couplé avec bras de levier sur le jeu de données KF-GINS), comparée à la trajectoire de référence C++ de KF-GINS selon des seuils enregistrés avant l'exécution. Il ne s'exécute que lorsque le jeu de données est fourni (KSHANA_KFGINS_DIR) ; sans lui, ce sont le chargeur synthétique et les tests de bras de levier qui s'exécutent. Les variantes à couplage serré et à phase de la porteuse ne sont pas couvertes par cette ligne (la ligne GNSS/INS à couplage serré avec phase de la porteuse est MODELLED).

PNT pour l'espace lointain et Mars — fondation D0 (src/body.rs, src/mars_frame.rs, src/ephem_provider.rs, src/radiometric.rs, src/timescales.rs)#

Le premier jalon du moteur de navigation pour l'espace lointain : généraliser le noyau, codé en dur pour la Terre, à un corps central arbitraire, ajouter la dynamique martienne, une interface de fournisseur d'éphémérides, un temps de précision inférieure à la microseconde, et les primitives de temps de lumière et de retard relativiste. Chaque scénario terrestre existant est identique à l'octet près — les références d'or de reproductibilité multiplateforme (tests/cross_platform_golden.rs, tests/golden.rs) passent sans modification et sans régénération, ce qui est vérifié à chaque commit.

Observables radiométriques de l'espace lointain et message de données de poursuite CCSDS — D1 (src/radiometric.rs, src/ccsds_tdm.rs)#

Le deuxième jalon du moteur de navigation pour l'espace lointain : le modèle d'observables qui transforme le noyau de temps de lumière et de retard relativiste de D0 en grandeurs effectives que rapporte une passe de poursuite du Deep Space Network (DSN) ou d'ESTRACK (European Space Tracking network) — distance, Doppler à un, deux ou trois trajets, transpondeur cohérent à rapport de transposition, mesure de distance régénérative/PN (PN : pseudo-bruit), Δ-DOR (DOR : differential one-way ranging), et milieux de propagation — ainsi que l'entrée/sortie du message de données de poursuite (TDM) CCSDS (Consultative Committee for Space Data Systems) 503.0-B, qui ingère et émet un fichier de poursuite d'agence standard. Portée honnête : il s'agit de modèles géométriques exacts suivant les conventions de Moyer / CCSDS ; le bruit de mesure est le sigma par observation fourni par l'appelant, et non intégré au modèle. Reproduire une passe de poursuite réelle donnée nécessite de vraies données TDM ainsi que le solveur de détermination d'orbite pour l'espace lointain — c'est D2, et non D1. Tout ce qui suit est additif (les références d'or de reproductibilité sont inchangées ; même SHA, sans régénération).

DO en dynamique réduite pour l'espace lointain — D2 (src/deepspace_od.rs, src/clock_state.rs, src/mars_atmos.rs)#

Le troisième jalon du moteur de navigation pour l'espace lointain : l'estimateur qui transforme les observables radiométriques de D1 en trajectoire retrouvée — un filtre d'information en racine carrée (SRIF) numériquement robuste, avec des accélérations empiriques en dynamique réduite, une horloge embarquée à trois états, un modèle de traînée martienne, et les dérivées partielles de mesure radiométrique qui relient distance et Doppler à l'état du filtre, le tout bouclé de bout en bout par une récupération synthétique de détermination d'orbite en orbite basse martienne (LMO). Portée honnête : la récupération est une boucle fermée synthétique (la vérité et le filtre partagent le même propagateur martien, et les observations sont le même modèle géométrique d'observables que le filtre inverse, plus un bruit gaussien injecté) — elle valide la mécanique de l'estimateur, et non la fidélité absolue du modèle de forces martien ; la vérification croisée externe de niveau DE est le crate xval/anise-mars-od conditionné par le noyau (D0.8b). Tout ce qui suit est additif (les références d'or de reproductibilité sont inchangées ; même SHA, sans régénération).

Scénario PNT pour l'espace lointain et fusion à un trajet + deux trajets — D3 (src/mars_pnt.rs, src/deepspace_od.rs)#

Le quatrième jalon du moteur de navigation pour l'espace lointain : un scénario de produit PNT martien exécutable qui relie le corps / référentiel martien de D0, les observables radiométriques de D1 et la DO en dynamique réduite de D2 en un unique type de scénario mars-pnt. Il modélise une petite constellation relais de style MARCONI qui diffuse un signal dans l'espace à un trajet (couplé à l'horloge) et relaie en outre une liaison à deux trajets (cohérente, indépendante de l'horloge) vers une station de l'espace lointain, et il navigue trois utilisateurs de référence (transfert vers Mars, orbiteur en orbite basse martienne, point fixe de surface) à l'aide de l'estimateur de fusion conjoint à un trajet + deux trajets de D3.1 — un SRIF à douze états qui augmente le bloc orbite/empirique en dynamique réduite de D2 d'une horloge embarquée à trois états. Portée honnête : chaque chiffre de mérite est la borne de covariance formelle de l'estimateur (position à 1σ / 3σ par époque) et le RMS atteint par rapport à une vérité en boucle fermée synthétique (la vérité et le filtre partagent la même dynamique martienne et le même modèle géométrique d'observables, plus un bruit gaussien injecté) — un chiffre de mérite de navigation simulé, et NON un niveau de protection certifié pour l'aviation, et NON une affirmation de vol (pas de modèle de pannes certifié, pas de moniteur d'intégrité, pas de données de poursuite réelles). Tout ce qui suit est additif (les références d'or de reproductibilité sont inchangées ; même SHA, sans régénération).

Temps-coordonnée lunaire — vitesse relativiste de l'horloge Terre-Lune (src/lunar_time.rs)#

Une échelle de temps-coordonnée lunaire (LTC/TCL (TCL : Temps-Coordonnée Lunaire, nom français du temps-coordonnée lunaire)) exige la vitesse séculaire à laquelle une horloge en surface lunaire marche par rapport à une horloge du géoïde terrestre (TT). src/lunar_time.rs la calcule à partir des premiers principes : une identité post-newtonienne du premier ordre qui somme la différence de potentiel propre (le potentiel conventionnel du géoïde IAU L_G W0 = L_G·c² ≈ 6.26369e7 m²/s² moins le potentiel propre de la surface de la Lune GM_moon/R_moon ≈ 2.822e6 m²/s²) et le terme cinétique (effet Doppler du second ordre) −<v²>/2c² issu de la vitesse géocentrique de la Lune (obtenue par différences finies à partir de la série lunaire de Montenbruck-Gill dans src/ephem.rs). Le terme dominant de potentiel propre donne ≈ 57,5 µs/jour, le terme cinétique ≈ −0,5 µs/jour, pour un total de ≈ 57 µs/jour. Le scénario lunar-time-offset rapporte cette vitesse, le décalage LTC−TT accumulé sur un horizon, et prend en charge un ensemble minimal à variance inverse (une horloge papier lunaire) ; les conversions TT↔LTC reviennent à leur valeur de départ à < 1 ns/jour près.

VLBI géodésique lunaire — retard en champ proche pour une base terrestre observant une balise lunaire (src/lunar_vlbi.rs)#

Une observable de VLBI (very-long-baseline interferometry) géodésique pour deux stations terrestres au sol (une base) observant un signal à un trajet d'un émetteur de classe NovaMoon en surface lunaire. La Lune est en champ proche, et non une onde plane ; le retard géométrique est donc la différence exacte de deux distances tau_geom = (|r2 − r_B| − |r1 − r_B|)/c plutôt que la projection dans le plan du ciel. L'observable complète ajoute la différence des décalages d'horloge des stations et un terme de Shapiro du potentiel terrestre différencié (réutilisé de src/radiometric.rs). Les stations sont placées en coordonnées inertielles géocentriques (GCRS) via src/frames.rs + src/cio.rs ; la balise via src/ephem.rs (Lune géocentrique) + src/lunar.rs (sélénographique→MCMF (MCMF : Moon-centred, Moon-fixed, centré sur la Lune et lié à la Lune)) + src/lunar_frame.rs (corps lié IAU-2015 ME→inertiel). Le scénario lunar-vlbi échantillonne le retard, sa vitesse de variation par différences finies et la correction de champ proche au cours d'une passe.

La référence indépendante est l'observable Δ-DOR en onde plane de la même base de code delta_dor dans src/radiometric.rs : à la limite du champ lointain (une balise synthétique à 1e15 m), le retard géométrique doit se réduire à −(B·ŝ_B)/c = delta_dor(r_B, [0,0,0], B) à la précision machine ; à la vraie distance lunaire, la correction de champ proche due à la courbure du front d'onde est non nulle (de quelques dizaines à quelques centaines de µs). Les dérivées partielles de la balise dtau/dr_B = ((r_B−r2)/|r_B−r2| − (r_B−r1)/|r_B−r1|)/c (et celles des stations) sont vérifiées par différence finie centrée (erreur relative < 1e-5).

DO et horloge lunaires conjointes multitechniques — récupération simulée en boucle fermée (src/lunar_combination.rs)#

Un ajustement par moindres carrés par lot à époque unique (instantané) (crate::batch_ls::gauss_newton_qr, une étape QR de Householder depuis 0,30) qui fusionne les techniques de VLBI géodésique, de radiométrie/télémétrie locale lunaire et de télémétrie inter-satellites sur un réseau lunaire SIMULÉ afin de retrouver, ensemble, la position 3-D d'une station de surface lunaire, les positions par satellite d'une petite constellation et le décalage d'horloge de chaque équipement. Les observables sont : (1) les retards de VLBI géodésique sur base terrestre vers la station lunaire traitée comme balise (réutilisant src/lunar_vlbi.rs, inertiel géocentrique) — la technique phare ; (2) les distances radiométriques géocentriques station terrestre→satellite (qui multilatèrent la constellation à partir des stations terrestres bien réparties) et les distances locales lunaires station↔satellite (distance euclidienne MCI (Moon-centred inertial, inertiel centré sur la Lune) plus le terme d'horloge différencié) ; (3) les distances inter-satellites (même forme) ; plus une unique pseudo-observation de synchronisation d'horloge de station qui ancre le décalage d'horloge commun, sinon inobservable. Le vecteur d'état est [station_pos(3), {sat_pos(3)}×N_sat, station_clk, {sat_clk}×N_sat]. Il n'y a aucune propagation par modèle de forces dans le solveur — les satellites sont des points fixes, distincts et illustratifs sur une orbite lunaire représentative ; il s'agit d'un ajustement instantané volontairement épuré. En interne, les positions sont mises à l'échelle et les horloges sont estimées en mètres équivalents-distance afin que la matrice normale reste bien conditionnée en f64 ; les distances VLBI et lunaires sont centrées (moyenne retirée) autour de la géométrie nominale afin que le jacobien par différences finies ne souffre pas d'une annulation catastrophique. Le scénario lunar-joint-od-clock exécute la résolution avec et sans les liaisons VLBI sur la même graine/vérité et rapporte les deux solutions ainsi que le facteur d'amélioration de l'observabilité de la station.

Le résultat honnête phare : la télémétrie locale lunaire depuis une station polaire vers une poignée de satellites tous situés d'un même côté du ciel laisse la position de la station faiblement observée selon une direction, de sorte que la résolution par distances seules est mal conditionnée et que l'erreur 3-D retrouvée de la station est grande (ou que la résolution ne converge pas). Ajouter les retards VLBI sur base terrestre rend observable la position 3-D complète de la station, et l'erreur retrouvée de la station tombe au niveau du mètre. Le test vlbi_restores_station_observability vérifie que l'erreur de la station avec VLBI est nettement (≥5×) plus petite que l'erreur avec distances seules sur la même vérité injectée — le VLBI qui rétablit la direction de la station, sinon inobservable, est l'objet de cette phase.

La référence indépendante est la cohérence interne : un état de vérité injecté (station ~50 m/axe, satellites ~30 m/axe, horloges ~1e-7 s, avec une gigue par composante issue d'une graine) est converti en observables synthétiques par le même modèle géométrique que le solveur inverse, un bruit gaussien issu d'une graine est ajouté (valeurs illustratives par défaut : σ VLBI ≈ 1e-11 s, σ de distance ≈ 0,1 m, σ ISL ≈ 0,1 m ; poids 1/σ²), et l'estimateur doit retrouver la vérité injectée dans le bruit à partir d'une estimation initiale nulle. Un NEES moyen Monte-Carlo Δxᵀ(HᵀWH)Δx sur les graines (formal_covariance_nees) reste dans une bande large autour de n_params, une vérification du réalisme de la covariance.

Réalisation du référentiel lunaire — ajustement de datum par transformation de Helmert à 7 paramètres (src/lunar_frame_realise.rs)#

Là où src/lunar_frame.rs applique l'orientation du corps lunaire IAU 2015 WGCCRE (un modèle direct), ce module estime (réalise) un référentiel lunaire à partir d'un réseau de coordonnées de points estimées rattaché à un datum. Le cœur d'estimation est une transformation de similitude (Helmert) classique à 7 paramètres — trois de translation, trois de rotation aux petits angles et un d'échelle — qui transforme les points p_i (référentiel estimé) en q_i (référentiel du datum) sous la forme q_i = t + (1 + s)·R(θ)·p_i, avec R(θ) = rz(θz)·ry(θy)·rx(θx) construit à partir de crate::precession::{rx, ry, rz, matmul, mat_vec}. Les sept paramètres [tx, ty, tz, θx, θy, θz, s] sont estimés à partir d'au moins 3 paires de points non colinéaires par moindres carrés pondérés via crate::batch_ls::gauss_newton : le modèle direct prédit chaque q_i à partir de son p_i et aplatit les trois composantes de tous les points dans le vecteur d'observables, les coordonnées observées du datum forment z, les poids sont 1/σ², et la résolution part de x0 = zeros. Les angles de rotation sont estimés en µrad et l'échelle en ppb afin que le jacobien par différences finies reste bien mis à l'échelle à la grandeur des coordonnées de surface lunaire (~1.7e6 m). Un petit icrf_orientation_tie compose la petite rotation réalisée à travers l'orientation IAU corps→ICRF (transpose(crate::lunar_frame::icrf_to_iau_moon(jd_tdb))) et renvoie le décalage résiduel aux petits angles du référentiel réalisé autour des axes ICRF — un changement d'expression de référentiel volontairement simple, et non une estimation indépendante du pôle lunaire.

La référence indépendante est la cohérence interne : une transformation de Helmert connue (translation de l'ordre de quelques dizaines de m, rotation de l'ordre du µrad, échelle ~1e-7) est injectée dans un réseau de points synthétique bien réparti (latitude/longitude sélénographiques variées → MCMF, certains points en altitude), un bruit gaussien issu d'une graine est ajouté, et l'ajustement doit retrouver les paramètres injectés. Sur des données sans bruit, la récupération se fait à environ la précision machine (translation < 1e-6 m, rotation < 1e-9 rad, échelle < 1e-12) ; avec un bruit métrique, les paramètres retrouvés se situent à quelques × le σ formel et le RMS résiduel après ajustement est proche du niveau de bruit. Le scénario lunar-frame-realisation rapporte le datum retrouvé, l'erreur de récupération par paramètre par rapport à la vérité injectée, le RMS résiduel après ajustement et le rattachement d'orientation ICRF de la rotation réalisée.

Volume de service de navigation lunaire — DOP / couverture / disponibilité + PL ARAIM lunaire généralisé (src/lunar_service.rs)#

Ce module compose des éléments déjà construits en une analyse de volume de service de navigation lunaire : il balaie une grille de latitude/longitude sélénographiques sur un horizon temporel face à une constellation en orbite lunaire illustrative, de source publique, de classe Moonlight / LCNS (LCNS : Lunar Communications and Navigation Services) et rapporte le DOP / la couverture / la disponibilité ainsi qu'une enveloppe généralisée de niveau de protection ARAIM lunaire. Les deux réutilisations sont déterminantes et explicites. La géométrie DOP est le noyau VALIDATED (par rapport à gnss_lib_py) crate::orbit::dop — service_dop est un simple filtre de masque d'élévation plus ce noyau, et un test vérifie l'identité (service_dop égale un orbit::dop direct sur les mêmes positions visibles). L'intégrité réutilise la mécanique ARAIM lunaire LunaNet LNIS (LunaNet Interoperability Specification) crate::lunar::lunar_araim (σ_URE ≈ 30 m, P_sat ≈ 1e-4) ; lunar_protection_level généralise le niveau de protection existant du pôle Sud à un point de surface arbitraire, et un test vérifie qu'il se réduit au cas du pôle Sud (au pôle Sud, avec la même géométrie et le même budget, il renvoie exactement le résultat existant de lunar::lunar_araim à < 1e-9 près).

Les paramètres de la constellation sont une approximation illustrative des descriptions publiques de l'ESA pour cette classe de système (≈ 4 satellites sur des orbites lunaires elliptiques gelées favorisant la couverture du pôle Sud — apolune au-dessus de l'hémisphère sud ; 4 est la valeur par défaut de la bibliothèque, et le moonlight-service-volume.toml fourni la fixe à 8 parce que le niveau de protection exige au moins 6 en vue). Ils ne sont pas les véritables éphémérides Moonlight/LCNS et n'impliquent aucune affiliation, approbation, héritage, certification ni TRL. La composition (couverture / disponibilité / intégrité) est MODELLED : un ensemble de relais képlériens circulaires/elliptiques (et non des éphémérides LCNS / NRHO (near-rectilinear halo orbit) 9:2 corrigées différentiellement), une Lune en rotation moyenne (sans libration physique ni précession du pôle) et des paramètres d'intégrité LunaNet LNIS publiés. Elle illustre la méthode de volume de service, et non un chiffre de disponibilité opérationnelle. Déterministe (géométrie pure ; aucun aléa). Le scénario moonlight-service-volume rapporte le pourcentage de couverture, les enveloppes du nombre de satellites visibles et du PDOP, l'enveloppe HPL/VPL sur le volume et la disponibilité du niveau de protection par rapport à la limite d'alerte.

PNT différentiel lunaire — annulation du mode commun + résidu croissant avec la base + niveaux de protection DGNSS (src/lunar_dpnt.rs)#

Un analogue lunaire de DGNSS (navigation par satellite différentielle) / SBAS : une station de référence de classe NovaMoon à un emplacement sélénographique connu calcule des corrections différentielles par satellite à partir d'une constellation illustrative, de source publique, de classe Moonlight / LCNS, et un utilisateur mobile décalé de celle-ci d'une base les applique de sorte que les erreurs d'éphémérides diffusées de mode commun s'annulent. Chaque satellite i porte un vecteur d'erreur d'orbite 3-D commun injecté e_i et une erreur d'horloge commune c_i. Le résidu de pseudodistance de la station de référence est la correction −e_i · û_ref,i + c_i ; l'erreur brute de l'utilisateur est −e_i · û_user,i + c_i ; l'erreur corrigée de l'utilisateur est leur différence −e_i · (û_user,i − û_ref,i). Le terme d'horloge c_i s'annule exactement (il est identique dans les deux observations), et le terme d'orbite se réduit à la projection sur la différence des deux vecteurs unitaires de ligne de visée, qui → 0 lorsque la base → 0 (le plancher de décorrélation spatiale) et croît ≈ linéairement avec la base. Les erreurs de distance corrigées par satellite sont projetées à travers la géométrie de l'utilisateur par une petite résolution instantanée aux moindres carrés pondérés à faibles dépendances (état [x, y, z, clock] via crate::orbit::invert4 ; un biais de distance constant est absorbé par l'inconnue d'horloge au lieu de corrompre la solution) pour donner l'erreur de position de l'utilisateur. Le niveau de protection de l'utilisateur réutilise la mécanique de niveau de protection SBAS DO-229E (crate::sbas::sbas_protection_level, facteurs K d'approche de précision) avec le σ résiduel différentiel comme budget d'erreur à 1-σ de chaque satellite.

NovaMoon n'est référencé que comme classe de système (une description publique d'une station de référence lunaire) ; la constellation réutilise la crate::lunar_service::LunarConstellation illustrative de source publique. Ce sont des paramètres illustratifs destinés à exercer la méthode différentielle, et non des éphémérides réelles, et ils n'impliquent aucune affiliation, approbation, héritage, certification ni TRL. Le scénario lunar-differential-pnt rapporte l'erreur de position de l'utilisateur avec et sans corrections, le facteur de réduction, la courbe erreur-en-fonction-de-la-base et le niveau de protection. Dans la configuration par défaut, l'erreur corrigée de l'utilisateur à une base de 50 km est ≈ 0,008 m contre ≈ 24 m sans correction (une réduction d'un facteur ~3000), et ≈ 0 à base nulle.

La référence indépendante est la cohérence interne : l'annulation du mode commun est une identité algébrique exacte (avec noise = 0, erreur corrigée < 1e-6 m à base nulle ; le terme d'horloge s'annule à la précision machine quelle que soit la base), le résidu croît de façon monotone avec la base, et le niveau de protection est le même algorithme DO-229E auquel la pile SBAS est rattachée. Le résidu de décorrélation spatiale est un modèle géométrique du premier ordre, et non un modèle de décorrélation ajusté sur de vraies données de poursuite lunaire.

Export d'interopérabilité lunaire — CCSDS OEM + KIF alignés LunaNet/IOAG avec vérification d'aller-retour (src/lunar_interop.rs)#

Le référentiel lunaire, l'échelle de temps lunaire et l'éphéméride lunaire sont exportés sous des formes d'échange alignées sur LunaNet/IOAG (IOAG : Interagency Operations Advisory Group) et fondées sur le CCSDS. Cette phase n'invente pas de format de transmission : elle réutilise l'émetteur et l'analyseur CCSDS OEM (Orbit Ephemeris Message) 2,0 existants du crate (crate::oem::OemFile::to_oem_string / crate::oem::parse_oem) et l'enveloppe du format d'échange Kshana (crate::interchange::Envelope), rééquipés pour le contexte lunaire. export_lunar_oem règle le REF_FRAME de l'OEM sur le référentiel lunaire lié au corps WGCCRE de l'IAU 2015 (MOON_ME Terre moyenne ou MOON_PA axes principaux), TIME_SYSTEM sur l'échelle de temps lunaire (LTC / TCL / UTC) et CENTER_NAME sur MOON, sur un échantillon d'éphéméride illustrative, de source publique, de classe LCNS (positions issues de crate::lunar_service::LunarSat::position_mci, vitesse par différence finie centrale). export_lunar_time_metadata émet un descripteur de temps lunaire aligné sur LunaNet/IOAG (identifiant d'échelle, taux séculaire en µs/jour issu de crate::lunar_time::lunar_rate_breakdown, la bande publiée de 56–59 µs/jour, surface de référence) qui fait l'aller-retour par serde_json. export_kif_lunar enveloppe l'OEM + le descripteur + l'étiquette de référentiel dans l'enveloppe KIF existante avec l'étiquette d'honnêteté MODELLED.

La référence indépendante est l'aller-retour / le respect des champs. Comme oem.rs fournit les deux sens, l'OEM fait l'aller-retour par crate::oem::parse_oem (retour à un segment égal, avec le référentiel/temps lunaire et le nombre d'états préservés) et est vérifié indépendamment par oem_conformance, qui contrôle que chaque mot-clé d'en-tête CCSDS/LunaNet requis est présent, que REF_FRAME porte un jeton MOON_* lunaire et que TIME_SYSTEM n'est pas vide, que l'encadrement META_START … META_STOP tient, et que les lignes de données position+vitesse sont bien formées — en renvoyant un succès structuré plus la liste des champs présents/manquants, de sorte qu'un export cassé (p. ex. un TIME_SYSTEM supprimé) est détecté et nommé. Les métadonnées de temps font l'aller-retour par parse_lunar_time_metadata, et l'enveloppe KIF fait l'aller-retour par Envelope::parse vers des artefacts égaux portant l'étiquette MODELLED.

Prédictions préenregistrées#

Une prédiction préenregistrée est un résultat MODELLED figé avant l'existence de toute donnée permettant de l'évaluer, avec le protocole d'évaluation fixé en même temps. Ce n'est pas une validation et elle n'ajoute aucune ligne au registre. Chacune se trouve dans docs/predictions/, avec ses entrées figées, son résultat et leurs empreintes SHA-256, et tests/prediction_frozen.rs échoue si un octet figé bouge ; une hypothèse modifiée appelle une nouvelle prédiction datée à côté de l'ancienne, jamais une modification de celle-ci.

Registre de représentativité de la démonstration et des écarts avant le vol (src/representativeness.rs)#

Un résultat de simulation n'est utile comme preuve que s'il indique, sur sa face même, à quoi il est ancré, ce qu'il suppose et ce qui le sépare encore d'un système de vol. Le registre de représentativité en fait une sortie de premier rang, contrôlée par machine : un enregistrement Representativeness porte les Anchor externes de la démonstration, ses hypothèses modélisées, ses Gap par rapport au vol (chacun avec la phase/activité qui le comblerait) et la bande TRL pour laquelle il est représentatif. C'est le compagnon, par résultat, de la matrice verification au niveau des capacités.

La référence indépendante est un ensemble d'invariants en forme fermée, appliqués par representativeness::tests : un enregistrement Validated doit lister au moins un ancrage ExternalDataset (une simulation ne peut pas être validée par rapport à elle-même) ; un enregistrement Modelled doit lister au moins un écart avant le vol et ne peut pas revendiquer une bande TRL représentative supérieure à 4 (une maturation au-delà exige une preuve matérielle/de vol, qui est un écart, et non une sortie de simulation) ; la bande TRL doit être bien formée ; et un enregistrement PartnerOwned ne doit rien affirmer. Ces invariants rendent opérationnelle la discipline « représentativité justifiée + écarts restants vers le vol clairement identifiés ».

Preuve unifiée du compromis quantique contre classique (src/qtrade.rs)#

Chaque domaine d'application du PNT quantique répond à la même question de la même façon : fixer un cadre de comparaison (scénario + graine + version du moteur), faire passer un candidat quantique et une référence de base classique par un seul chemin de code neutre, les noter sur des figures de mérite communes, et rapporter — avec un intervalle de confiance et une étiquette honnête validé/modélisé — où le quantique gagne et où il ne gagne pas. TradeEvidence donne à cette réponse une forme unique, de sorte que les verticaux de synchronisation temporelle, de navigation et de détection d'anomalies émettent tous le même objet reproductible et honnêtement étiqueté. Il ne réimplémente aucun compromis : les nombres par FoM proviennent des moteurs existants (quantum_trade, crossover, et les modules verticaux) ; il s'agit du contrat plus l'enveloppe de reproductibilité/représentativité, bâtie sur le registre de représentativité et les étiquettes de vérification.

La référence indépendante est constituée d'identités de bénéfice/gagnant en forme fermée plus un enrobage fidèle de la sortie de compromis existante. qtrade::tests : le rapport de bénéfice est correct en polarité (orienté de sorte que >1 signifie toujours que le côté quantique est meilleur, tant pour les FoM de holdover où plus est mieux que pour les FoM d'erreur où moins est mieux) ; un objet de preuve construit à partir d'un véritable quantum_trade::TradeResult reproduit ses rapports de bénéfice ; une preuve malhonnête est rejetée (une représentativité modélisée sans écart, ou une FoM Validated dont l'enregistrement de compromis ne porte aucun ancrage externe) ; le JSON est déterministe et porte les champs cadre/graine/moteur/FoM/représentativité.

Bibliothèque de modèles d'erreur de dispositifs quantiques (src/quantum_devices.rs)#

Un lieu unique qui expose les dispositifs de PNT quantique que le démonstrateur compare — horloges optiques / à ions piégés / à ions de mercure, horloges de référence classiques, interféromètre à atomes froids et liaisons de transfert de temps — chacun sous forme de DeviceCard portant sa spécification principale et un enregistrement de représentativité. La plupart de la physique des dispositifs est réutilisée (stabilités d'horloge issues de holdover::QuantumClockClass et clock_state::ClockClass ; l'interféromètre à atomes froids issu de quantum_trade/crossover ; les liaisons optiques/RF classiques issues de timetransfer_adv). Le seul modèle réellement nouveau est la liaison de transfert de temps par intrication / photon unique, dont la précision de synchronisation est limitée par le bruit de grenaille : σ_t ≈ jitter/√(R·τ) en fonction du taux de coïncidences détectées R et de l'intégration τ, dégradée par une pénalité de comptage d'obscurité √(1 + dark/R) et plafonnée par une systématique irréductible.

La référence indépendante est constituée des coefficients publiés réutilisés d'horloge/CAI plus des identités de bruit de grenaille/perte en forme fermée. quantum_devices::tests : l'ordre de stabilité d'horloge réutilisé est sain (réseau optique < ions de mercure < CSAC en σ_y(1 s)) ; la précision de l'intrication s'améliore comme 1/√τ (une intégration × 4 divise σ par deux) lorsqu'elle est limitée par le bruit de grenaille ; le taux de coïncidences détectées chute d'un facteur 10 par 10 dB de perte de liaison ; les comptages d'obscurité dégradent la précision de façon monotone ; le plancher systématique borne la précision par le bas ; chaque fiche de dispositif est un enregistrement de représentativité valide et modélisé.

Synchronisation quantique de confiance — chaîne de bout en bout, diffusion sécurisée, anomalie + compromis (src/timetransfer_chain.rs)#

Le scénario quantum-time-transfer compose la chaîne de synchronisation temporelle dont a besoin un démonstrateur de PNT quantique : un budget de temps utilisateur de bout en bout (erreur de marche libre de l'horloge de référence et précision de synchronisation de la liaison combinées en quadrature) pour une chaîne quantique (horloge à réseau optique + liaison par intrication/photon unique) contre une chaîne classique (CSAC + liaison bidirectionnelle RF) ; un niveau de protection temporel (TPL, réutilisé de tpl) bornant l'erreur de temps non détectée ; une figure de mérite de sécurité contre les attaques par retard/rejeu 1 − P_md à un taux de fausse alarme énoncé (réutilisée de detection) ; une probabilité de détection d'anomalie d'horloge + latence de détection de changement par CUSUM (somme cumulée) ; et la comparaison quantique contre classique sous forme de qtrade::TradeEvidence honnête portant un enregistrement de représentativité + d'écarts avant le vol.

La référence indépendante est un budget en quadrature en forme fermée sur des noyaux réutilisés et validés séparément (ADEV par rapport à Stable32/NIST ; la borne TPL ; detection::analytic_pd/analytic_pmd). timetransfer_chain::tests : la précision quantique s'améliore avec le temps d'intégration ; la chaîne quantique peut gagner et peut perdre sur la FoM de précision (honnête — pas une victoire universelle ; une liaison très perdante inverse le résultat) ; le niveau de protection est fini et positif ; la FoM de sécurité est dans [0 1] et croît avec le retard de l'attaque ; la probabilité de détection d'anomalie est monotone en l'amplitude du défaut ; et la preuve du compromis est internement honnête (is_honest()).

Navigation quantique sans GNSS (src/quantum_nav_od.rs)#

Le scénario quantum-gnss-free-nav compare la navigation à l'estime pendant une interruption du GNSS avec un budget inertiel quantique (un accéléromètre à interféromètre à atomes froids, réutilisé de inertial::quantum_imu/quantum_trade, dont le plancher de bruit blanc du CAI est validé à ~2 ordres de grandeur près de Freier et al. 2016) face à un INS classique de qualité navigation. Il rapporte la croissance de l'erreur de position pendant la marche libre, la durée de holdover jusqu'à un seuil de position, et le compromis quantique contre classique sous forme de qtrade::TradeEvidence honnête. L'observabilité est énoncée honnêtement : sans point externe pendant l'interruption, le biais de l'accéléromètre est inobservable, de sorte que l'erreur de position croît sans borne (≈ ½·biais·t² plus un terme de marche aléatoire de vitesse) ; un capteur quantique à biais plus faible ralentit cette croissance mais ne comble pas l'écart — seul un point externe le fait.

La référence indépendante est constituée des budgets inertiels réutilisés (QuantumNavBudget/ClassicalInsBudget, qui implémentent tous deux le trait PositionDrift) plus des identités de dérive en forme fermée. quantum_nav_od::tests : le budget quantique bat le classique sur une longue interruption (erreur plus faible, holdover plus long) ; l'erreur croît avec la durée de l'interruption pour les deux (l'écart d'observabilité) ; l'avantage dépend de l'interruption, ce n'est pas un facteur de gain constant (la courbe quantique est dominée par le bruit en marche libre courte, par le biais en marche libre longue) ; la preuve du compromis est internement honnête.

Détection de défauts / d'anomalies pour les systèmes PNT quantiques (src/quantum_faults.rs)#

Le scénario quantum-anomaly-detect définit un catalogue étiqueté de défauts du PNT quantique (saut de fréquence d'horloge, dérive, perte d'accrochage ; saut de biais de capteur, perte de signal), note une statistique de détection sur des fenêtres nominales contre défaillantes, et rapporte la discrimination du détecteur sous forme d'AUC ROC et de défaut minimal détectable à un taux de fausse alarme fixé. L'angle quantique contre classique : une référence d'horloge quantique plus stable abaisse le bruit σ du moniteur, de sorte qu'elle détecte des défauts plus petits — émis sous forme de qtrade::TradeEvidence honnête avec un enregistrement de représentativité.

La référence indépendante est une AUC en forme fermée pour la statistique de détection gaussienne (nominale N(0,σ), défaut N(μ,σ) ⇒ AUC = Φ(μ/(σ√2))) contrôlée par rapport à eval_stats::bootstrap_auc_ci, validé en externe (validé par rapport à scikit-learn), et aux seuils analytiques de detection. quantum_faults::tests : l'AUC analytique concorde avec les valeurs connues (0,5 à μ=0, →1 pour de grands μ/σ, monotone) ; l'IC d'AUC par bootstrap empirique encadre la forme fermée ; le moniteur quantique a une AUC plus haute et un défaut minimal détectable plus petit ; l'avantage disparaît pour des défauts énormes (les deux détectent parfaitement — pas une marge universelle) ; le catalogue a cinq classes étiquetées ; le compromis est internement honnête.

Respect des normes — formats d'échange, bilan de liaison et intégrité (contrôles par référence indépendante externe)#

Ces normes sont validées en retrouvant les exemples détaillés / valeurs de référence verbatim publiés dans les normes elles-mêmes (ou dans une implémentation de référence indépendante), et non par l'aller-retour propre de Kshana. Retrouver l'exemple d'annexe d'une norme est le contrôle de respect de la norme le plus fort disponible pour un analyseur de format d'échange.

Normes GNSS — statut de la référence indépendante externe et écarts restants, en toute honnêteté :

Synchronisation temporelle pour les réseaux, le spectre, le système solaire, les constellations, les campagnes et le LEO-PNT#

Les capacités ajoutées dans la ligne 0,28 sont notées ligne par ligne dans le VERIFICATION-MATRIX.md généré ; cette section résume lesquelles portent une référence indépendante externe. Une ligne n'est VALIDATED qu'avec une référence indépendante externe ; tout le reste est MODELLED.

Les sorties qui sont des rendus, et non des preuves, ont des tests mais pas de ligne de matrice : les exports d'échange (CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON, éphéméride STK (Systems Tool Kit), SigMF (Signal Metadata Format)), chacun ré-analysé par un validateur écrit à partir de la spécification du format (tests/interop_formats.rs, 13 tests ; voir INTEROP.md) ; les animations (tests/animation.rs : réexécutions identiques à l'octet, nombres d'images exacts, SVG (Scalable Vector Graphics) bien formé, aucune adresse externe dans le lecteur HTML (HyperText Markup Language)) ; et le rapport d'exécution (tests/advanced_report.rs, tests/advanced_report_cli.rs : chaque scénario fourni produit un rapport sans section vide ni valeur de substitution, les étiquettes concordent avec la matrice, et la commande enregistrée reproduit result.json et le rapport octet pour octet).

Domaine de fonctionnement#

Chaque paquet est exercé sur son domaine d'entrée déclaré par tests/scenario_coverage.rs, qui affirme que chaque sortie numérique est finie (ni NaN ni Inf (NaN : not a number)) et bornée. Le tableau liste la plage d'entrée testée par paquet, le comportement de sortie attendu et le test qui la couvre.

Les lignes FM de scintillement et biais de fusion comblent deux écarts précis de réalisme : les termes de bruit sont désactivés par défaut mais affectent manifestement la sortie lorsqu'ils sont activés, et le filtre de fusion conjoint ne dépend pas de biais mis à zéro — il converge aussi avec un biais résiduel réaliste de qualité atomes froids.

Limites connues#

• Les exécutions quantiques et classiques utilisent maintenant des graines de RNG (générateur de nombres aléatoires) indépendantes (graine classique = graine + 0x9e3779b97f4a7c15) afin que leurs réalisations de bruit soient décorrélées — corrigé après relecture.
• holdover_s tient compte des segments : les lignes de temps d'interruption sont découpées en segments contigus aux réacquisitions du GNSS et la valeur rapportée est la marche libre du pire cas (la plus courte) parmi eux. Elle reste bornée par la résolution de la grille de temps (une borne inférieure).
• La resynchronisation par transfert de temps ISL modélise l'incertitude résiduelle de la liaison comme une gigue fraîche à moyenne nulle par pas de mesure plus un réancrage à l'intervalle configuré.

Affirmations et réalité — référence rapide#

La liste de contrôle d'un évaluateur hostile. Pour chaque terme qui pourrait être lu comme plus qu'il n'est : ce que Kshana fait aujourd'hui, et où se situe la vraie version dans la feuille de route.

Contrôles croisés de l'article sur le PNT lunaire (preuves de non-régression, et non lignes de matrice)#

La suite lunaire/cislunaire (les capacités « Lunar & cislunar » et « Lunar PNT suite » du README) voit ses affirmations d'articles publiés contrôlées de façon croisée et indépendante dans tests/validate_p*.rs, chacune par rapport à une référence indépendante issue d'une implémentation différente :

• empreinte orbitale d'émission/de capture par rapport à scipy.special.j1 (Bessel J1 de Cephes) ;
• DOP de géométrie de balises de surface par rapport à une résolution (HᵀH)⁻¹ indépendante de NumPy ;
• croissance de l'erreur de prédiction de persistance UT1/EOP par rapport à une ré-analyse NumPy des mêmes lignes finals2000A verbatim de l'IERS ;
• famille d'orbites rétrogrades lointaines planes par rapport à la Three-Body Periodic Orbit Database de la NASA/JPL ;
• budget de précision de télémétrie RF par rapport à une référence issue des premiers principes.

Les jeux de test et les scripts de génération de référence indépendante se trouvent sous tests/fixtures/{p1_footprint,lunar_service,eop_prediction,rf_ranging_precision,dro_family_jpl,p2_independent_dop}/. Ils renforcent la preuve derrière des capacités qui restent MODELLED dans la matrice contrôlée par machine (src/verification.rs) ; ce sont des contrôles de non-régression, et non de nouvelles lignes VALIDATED de la matrice, de sorte qu'ils ne modifient pas eux-mêmes le décompte de la matrice contrôlée par machine. Ce décompte n'est pas répété ici, car une copie saisie à la main dérive : la répartition en vigueur est l'en-tête généré de VERIFICATION-MATRIX.md, que gen_validation_artifacts écrit à partir de verification_matrix() et que tests/verification_artifacts_doc_sync.rs fige.