Maskinoversettelse, ikke gjennomgått av en morsmålsbruker. Engelsk er referansen.

Sider for scenariotyperRediger på GitHubKilde: docs/kinds/by-kind/lunar-beacon.md

lunar-beacon (scenariotype)

Scenariotype i motoren v0.40.0, familie Måne og cislunart rom. Veiledende: analyseutdata fra et forsknings- og ingeniørverktøy, ikke typegodkjent navigasjonsutstyr og ikke en sikkerhetskritisk tjeneste for menneskeliv. Hver etikett her er motorens eller verifikasjonsmatrisens; en type er MODELLED med mindre matrisen sier noe annet (hvordan en etikett fortjenes: Evidens-avsnittet i README).

Hva den gjør#

Forsterkning med overflatebaker av en orbital navigasjonstjeneste på månen, som en kjørbar før/etter-tabell. En bruker ved sørpolen ser et tynt orbitalt sett i et smalt himmelfelt, så avstandsgeometrien er dårlig betinget; noen få OPPMÅLTE OVERFLATEBAKER gir de siktlinjeradene med lav elevasjon og bred asimut som et sett som bare står over hodet mangler, og den horisontale presisjonsfortynningen kollapser. Scenarioet rapporterer tre konfigurasjoner ved én epoke: bare satellitter, satellitter pluss de synlige bakene, og en større konstellasjon som alternativ vei til samme geometri. Hver har sine antall synlige kilder, sin fulle DOP og den realiserte 1-sigma-nøyaktigheten i METER, oppnådd ved å multiplisere med en brukerekvivalent avstandsfeil per bake, satt sammen som kvadratroten av summen av kvadratene til klokkesynkroniserings-, flerveis- og oppmålingsledd. Synligheten til bakene er den geometriske horisonten med to høyder for Månen uten atmosfære (ingen atmosfære, så grensen er eksakt), og DOP-oppsettet er den samme kjernen som er kryssjekket mot gnss_lib_py i tests/dop_reference.rs. HVORFOR DENNE TYPEN FINNES: modulen bak den har vært i motoren og kontrollert mot en uavhengig DOP-vei siden L08/L09, men den kunne ikke nås fra en kjøring: ingen type, ingen dispatch-gren, ingen medfølgende fil. README-en omtalte funksjonen, og verifikasjonsmatrisen hadde INGEN rad for den i det hele tatt, så den var samtidig hevdet i prosa og ikke hevdet i registeret, mens den var utilgjengelig i motoren. Standardverdiene er geometrien som allerede har en innsjekket golden-fil (en bruker ved -80 deg med en antenne på 2 m, tre baker ved -80/0, -79/+60 og -79/-60 på 2 km, et illustrativt LCNS-øyeblikksbilde med seks satellitter ved t=0, en maske på 5 deg), slik at en rå kjøring gjengir en tabell som en uavhengig referanse allerede dekker, i stedet for å finne på nye tall. MODELLED: konstellasjonsutformingen, plasseringen av bakene og hver størrelse i feilbudsjettet er illustrative inngangsverdier, ikke en operativ oppmåling eller en målt link; bare DOP-aritmetikken, den lukkede formen for horisonten og relasjonen sigma = DOP x sigma_URE er forankret eksternt. Ikke et løfte om tjenesteytelse.

Én kjøring av scenarios/lunar-beacon.toml oppsummeres slik: Forsterkning med overflatebaker på månen — maske 5,0 deg, epoke +0 s, sigma_URE per bake 1,1576 m 6 satellitter, ingen baker sats 5 beacons 0 GDOP 11,6627 PDOP 9,6941 HDOP 3,4868 VDOP 9,0454 TDOP 6,4840 realisert 1-sigma: 3D 11,222 m H 4,036 m V 10,471 m 6 satellitter + 1 synlige baker sats 5 beacons 1 GDOP 4,9979 PDOP 4,1160 HDOP 1,9721 VDOP 3,6128 TDOP 2,8350 realisert 1-sigma: 3D 4,765 m H 2,283 m V 4,182 m 24 satellitter, ingen baker sats 19 beacons 0 GDOP 2,8929 PDOP 2,4226 HDOP 1,0199 VDOP 2,1974 TDOP 1,5811 realisert 1-sigma: 3D 2,804 m H 1,181 m V 2,544 m bakene forbedrer PDOP med 2.355x; en større konstellasjon i stedet, 4.002x MODELLED: konstellasjonen, plasseringen av bakene og feilbudsjettet er illustrative inngangsverdier. DOP-kjernen under er den som er validert mot gnss_lib_py, og bakehorisonten er den lukkede formen fra L01.

Inndata#

Fra skjemaet (kshana kinds --json):

  • Påkrevde felt: ingen
  • Valgfrie felt: user, beacons, n_satellites, comparison_n_satellites, epoch_s, elevation_mask_deg, clock_sync_m, multipath_m, survey_m

Eksempelet scenarios/lunar-beacon.toml setter blant annet:

Felt Verdi Enhet
beacons[0].alt_m 2000 m
beacons[0].lat_deg -80 deg
beacons[0].lon_deg 0 deg
beacons[1].alt_m 2000 m
beacons[1].lat_deg -79 deg
beacons[1].lon_deg 60 deg
beacons[2].alt_m 2000 m
beacons[2].lat_deg -79 deg
beacons[2].lon_deg -60 deg
clock_sync_m 1 m
comparison_n_satellites 24 ikke oppgitt
elevation_mask_deg 5 deg

Kjør den#

kshana scenarios/lunar-beacon.toml

Hva den gir#

Skalarresultatene fra den kjøringen, med enhetene motoren oppgir:

Resultat Verdi Enhet
beacon_pdop_improvement 2.355211 1
constellation_pdop_improvement 4.001566 1
elevation_mask_deg 5 deg
epoch_s 0 s
evidence.id_rule den stabile id-en til matriseraden (ID tekst
evidence.matrix docs/VERIFICATION-MATRIX.md tekst
evidence.tier MODELLED tekst
sigma_ure_m 1.157584 m
Diagrammet motoren skriver for scenarios/lunar-beacon.toml, type lunar-beacon

Evidens#

MODELLED: radene i verifikasjonsmatrisen som navngir denne typen.

  • MODELLED Bakeforsterket presisjonsfortynning for en bruker på månens overflate: siktlinjeradene til de synlige satellittene og avstandsradene til de synlige overflatebakene settes sammen til én designmatrise og evalueres gjennom den felles DOP-kjernen, og t Tester: validate_p2_beacon_before_after_table.rs.

Radene kjøringen selv brukte, med den uavhengige referansen matrisen gir hver (de offentlige kildene er navngitt der):

  • MODELLED Deterministisk, scenariohashet, SBOM + gates med gylne verdier på tvers av plattformer. Uavhengig referanse (ExternalDataset): SBOM-overensstemmelse med det offisielle CycloneDX 1,5 JSON Schema (+ gyldige SPDX-identifikatorer), en ekstern publisert standard, null valideringsfeil over hele avhengighetsgrafen; delen om FoM-determinisme / byte-reproduserbarhet er fortsatt en festet selvkonsistenssjekk, så raden forblir MODELLED
  • MODELLED Bakeforsterket presisjonsfortynning for en bruker på månens overflate: siktlinjeradene til de synlige satellittene og avstandsradene til de synlige overflatebakene er sammenslått. Uavhengig referanse (ReferenceImpl): DOP-aritmetikken er kjernen crate::orbit::dop, som er validert separat og eksternt mot gnss_lib_py i tests/dop_reference.rs; denne raden låner ikke den radens status på nytt. Bakenes synlighetshorisont er den lukkede formen fra L01, og sigma = DOP x sigma_URE er den vanlige GNSS-relasjonen (Kaplan og Hegarty, Understanding GPS/GNSS, avsnitt 7). Innenfor denne raden kontrolleres selve forsterkningen mot en uavhengig

Begrensninger#

Hva kjøringens egen rapport sier ikke er modellert eller ikke er validert:

  • MODELLED: konstellasjonsutformingen, plasseringen av bakene og hver størrelse i feilbudsjettet er illustrative inngangsverdier, ikke en operativ oppmåling eller en målt link; bare DOP-aritmetikken, den lukkede formen for horisonten og relasjonen sigma = DOP x sigma_URE er forankret eksternt. (typekatalog (kshana kinds --json))
  • HVA SOM ER FORANKRET OG HVA SOM IKKE ER Forankret: DOP-oppsettet er kjernen som er kryssjekket mot gnss_lib_py i tests/dop_reference.rs; bakesynlighet er den lukkede formen for den geometriske horisonten med to høyder for Månen uten atmosfære (ingen atmosfære, så det finnes ingen refraktiv utvidelse og grensen er eksakt); og sigma = DOP x sigma_URE er den vanlige relasjonen (Kaplan & Hegarty, Understanding GPS/GNSS, avsnitt 7). IKKE forankret — MODELL (kommentar i scenariofilen, linje 40 til 49)
  • Reproduserbarhet og programvarekvalitetssikring er MODELLED, ikke validert: en delpåstand er kontrollert eksternt, men hele funksjonen setter sammen modellerte deler, så funksjonen forblir modellert. (verifikasjonsmatrise (docs/MODELLED-RATIONALE.md))
  • DOP-forsterkning med overflatebaker på månen er MODELLED, ikke validert: kontrollert mot en separat implementasjon i samme kodebase, uavhengig av enheten som testes, men ikke eksternt autoritativ. (verifikasjonsmatrise (docs/MODELLED-RATIONALE.md))

Se også#