lunar-beacon (type de scénario)

Type de scénario du moteur v0.40.0, famille Lunaire et cislunaire. À titre consultatif : résultat d'analyse d'un outil de recherche et d'ingénierie, et non un équipement de navigation homologué ni un service de sauvegarde de la vie humaine. Chaque étiquette ici est celle du moteur ou de la matrice de vérification ; un type de scénario est MODELLED sauf si la matrice dit le contraire (comment une étiquette s'acquiert : la section Evidence du README).

Ce qu'il fait#

Augmentation par balises de surface d'un service de navigation orbital lunaire, sous forme de tableau avant/après exécutable. Un utilisateur au pôle sud voit un ensemble orbital clairsemé dans une étroite portion de ciel, de sorte que la géométrie de mesure de distance est mal conditionnée ; quelques BALISES DE SURFACE RELEVÉES fournissent les lignes de visée à basse élévation et grand azimut qui manquent à un ensemble entièrement au zénith, et la dilution de précision horizontale s'effondre. Le scénario rapporte trois configurations à une même époque — les satellites seuls, les satellites plus les balises visibles, et une constellation plus grande comme autre voie vers la même géométrie — chacune avec ses nombres de sources visibles, son DOP complet, et la précision réalisée à 1 sigma en MÈTRES obtenue en multipliant par une erreur équivalente de mesure de distance par balise, assemblée comme la racine de la somme des carrés des termes de synchronisation d'horloge, de multitrajet et de relevé. La visibilité des balises est l'horizon géométrique à deux hauteurs de la Lune sans atmosphère (pas d'atmosphère, donc la borne est exacte), et l'assemblage du DOP est le même noyau recoupé avec gnss_lib_py dans tests/dop_reference.rs. POURQUOI CE TYPE DE SCÉNARIO EXISTE : le module qui le sous-tend est dans le moteur et contrôlé par rapport à un chemin DOP indépendant depuis L08/L09, mais il n'était pas accessible depuis une exécution — pas de type de scénario, pas de branche de répartition, pas de fichier fourni. Le README annonçait la capacité et la matrice de vérification ne comportait AUCUNE ligne la concernant, de sorte qu'elle était à la fois revendiquée en prose et non revendiquée dans le registre, tout en étant inaccessible dans le moteur. Les valeurs par défaut sont la géométrie qui porte déjà une référence figée validée (un utilisateur à -80 deg avec une antenne de 2 m, trois balises à -80/0, -79/+60 et -79/-60 à 2 km, un instantané illustratif de LCNS à six satellites à t=0, un masque de 5 deg), de sorte qu'une exécution nue reproduit un tableau déjà couvert par une référence indépendante plutôt que d'inventer de nouveaux nombres. MODELLED : la conception de la constellation, le placement des balises et chaque ordre de grandeur du budget d'erreur sont des entrées illustratives, et non un relevé en service ni une liaison mesurée ; seuls l'arithmétique du DOP, la forme close de l'horizon et la relation sigma = DOP x sigma_URE sont ancrés à l'extérieur. Pas un engagement de performance de service.

Une exécution de scenarios/lunar-beacon.toml se résume ainsi : Lunar surface-beacon augmentation — mask 5,0 deg, epoch +0 s, per-beacon sigma_URE 1,1576 m 6 satellites, no beacons sats 5 beacons 0 GDOP 11,6627 PDOP 9,6941 HDOP 3,4868 VDOP 9,0454 TDOP 6,4840 realised 1-sigma: 3D 11,222 m H 4,036 m V 10,471 m 6 satellites + 1 visible beacons sats 5 beacons 1 GDOP 4,9979 PDOP 4,1160 HDOP 1,9721 VDOP 3,6128 TDOP 2,8350 realised 1-sigma: 3D 4,765 m H 2,283 m V 4,182 m 24 satellites, no beacons sats 19 beacons 0 GDOP 2,8929 PDOP 2,4226 HDOP 1,0199 VDOP 2,1974 TDOP 1,5811 realised 1-sigma: 3D 2,804 m H 1,181 m V 2,544 m beacons improve PDOP by 2.355x; a larger constellation instead, 4.002x MODELLED: the constellation, the beacon placement and the error budget are illustrative inputs. The DOP kernel underneath is the gnss_lib_py-validated one and the beacon horizon is the L01 closed form.

Entrées#

D'après le schéma (kshana kinds --json) :

• Champs requis : aucun
• Champs facultatifs : user, beacons, n_satellites, comparison_n_satellites, epoch_s, elevation_mask_deg, clock_sync_m, multipath_m, survey_m

L'exemple scenarios/lunar-beacon.toml définit, entre autres :

L'exécuter#

kshana scenarios/lunar-beacon.toml

Ce qu'il donne#

Les résultats scalaires de cette exécution, avec les unités que le moteur indique :

Preuves#

MODELLED : les lignes de la matrice de vérification qui nomment ce type de scénario.

• MODELLED Dilution de précision augmentée par balises pour un utilisateur en surface lunaire : les lignes de visée des satellites visibles et les lignes de mesure de distance des balises de surface visibles sont concaténées en une seule matrice de conception et évaluées par le noyau DOP partagé, et t Tests : validate_p2_beacon_before_after_table.rs.

Les lignes que l'exécution elle-même a exercées, avec la référence indépendante que la matrice donne pour chacune (les sources publiques y sont nommées) :

• MODELLED Déterministe, hachée par scénario, avec des barrières SBOM + références d'or multiplateformes. Référence indépendante (ExternalDataset) : respect du schéma JSON officiel CycloneDX 1,5 par la SBOM (+ identifiants SPDX valides) — une norme publiée externe, zéro erreur de validation sur tout le graphe de dépendances ; la partie déterminisme du FoM / reproductibilité à l'octet près reste un contrôle d'autocohérence figé, de sorte que la ligne reste MODELLED
• MODELLED Dilution de précision augmentée par balises pour un utilisateur en surface lunaire : les lignes de visée des satellites visibles et les lignes de mesure de distance des balises de surface visibles sont concat. Référence indépendante (ReferenceImpl) : l'arithmétique du DOP est le noyau crate::orbit::dop, validé séparément et de façon externe par rapport à gnss_lib_py dans tests/dop_reference.rs ; cette ligne ne reprend pas le statut de cette autre ligne. L'horizon de visibilité des balises est la forme close L01, et sigma = DOP x sigma_URE est la relation GNSS standard (Kaplan et Hegarty, Understanding GPS/GNSS, section 7). Dans cette ligne, l'augmentation elle-même est contrôlée par rapport à un indépendant

Limites#

Ce que le rapport propre à l'exécution dit n'être pas modélisé ou pas validé :

• MODELLED : la conception de la constellation, le placement des balises et chaque ordre de grandeur du budget d'erreur sont des entrées illustratives, et non un relevé en service ni une liaison mesurée ; seuls l'arithmétique du DOP, la forme close de l'horizon et la relation sigma = DOP x sigma_URE sont ancrés à l'extérieur. (catalogue des types de scénario (kshana kinds --json))
• CE QUI EST ANCRÉ ET CE QUI NE L'EST PAS Ancré : l'assemblage du DOP est le noyau recoupé avec gnss_lib_py dans tests/dop_reference.rs ; la visibilité des balises est la forme close de l'horizon géométrique à deux hauteurs de la Lune sans atmosphère (pas d'atmosphère, donc pas d'extension par réfraction et la borne est exacte) ; et sigma = DOP x sigma_URE est la relation standard (Kaplan & Hegarty, Understanding GPS/GNSS, section 7). NON ancré — MODELL (commentaire du fichier de scénario, lignes 40 à 49)
• La reproductibilité et l'assurance logicielle sont MODELLED, et non validées : une sous-affirmation est vérifiée de l'extérieur, mais la capacité entière compose des éléments modélisés, de sorte qu'elle reste modélisée. (matrice de vérification (docs/MODELLED-RATIONALE.md))
• L'augmentation du DOP par balises de surface lunaires est MODELLED, et non vérifiée : elle est contrôlée par rapport à une implémentation distincte dans ce même code source, indépendante de l'unité testée mais sans autorité externe. (matrice de vérification (docs/MODELLED-RATIONALE.md))

Voir aussi#

• Page de famille : Lunaire et cislunaire
• Tous les types de scénario : KINDS.md