lunar-beacon (rodzaj scenariusza)

Rodzaj scenariusza silnika v0.40.0, rodzina Przestrzeń księżycowa i cislunarna. Wyłącznie doradczo: wynik analizy z narzędzia badawczo-inżynieryjnego; nie jest to sprzęt nawigacyjny z zatwierdzeniem typu ani usługa bezpieczeństwa życia. Każda etykieta tutaj pochodzi od silnika lub z macierzy weryfikacji; rodzaj jest MODELLED, o ile macierz nie mówi inaczej (jak zdobywa się etykietę: sekcja Evidence w README).

Co robi#

Uzupełnienie księżycowej orbitalnej usługi nawigacyjnej o latarnie powierzchniowe, jako uruchamialna tabela przed/po. Użytkownik na biegunie południowym widzi rzadki zestaw orbitalny w wąskim fragmencie nieba, więc geometria wyznaczania odległości jest źle uwarunkowana; kilka ZMIERZONYCH LATARNI POWIERZCHNIOWYCH dostarcza wiersze linii widzenia o niskiej elewacji i szerokim azymucie, których brakuje zestawowi całkowicie nad głową, a poziomy współczynnik DOP gwałtownie maleje. Scenariusz podaje trzy konfiguracje w jednej epoce — same satelity, satelity plus widoczne latarnie oraz większą konstelację jako alternatywną drogę do tej samej geometrii — każdą z liczbą widocznych źródeł, pełnym DOP i uzyskaną dokładnością 1-sigma w METRACH, otrzymaną przez przemnożenie przez błąd odległości równoważny dla użytkownika w przeliczeniu na latarnię, złożony jako pierwiastek z sumy kwadratów składników synchronizacji zegarów, wielodrogowości i pomiaru. Widoczność latarni to geometryczny horyzont dwuwysokościowy na Księżycu bez atmosfery (bez atmosfery, więc ograniczenie jest dokładne), a złożenie DOP to to samo jądro sprawdzone względem gnss_lib_py w tests/dop_reference.rs. DLACZEGO TEN RODZAJ ISTNIEJE: moduł za nim jest w silniku i sprawdzony względem niezależnej ścieżki DOP od L08/L09, ale nie był osiągalny z przebiegu — bez rodzaju, bez gałęzi dyspozytora, bez dołączonego pliku. README zapowiadało tę możliwość, a macierz weryfikacji nie miała dla niej ŻADNEGO wiersza, więc była jednocześnie deklarowana w tekście i niedeklarowana w rejestrze, a w silniku nieosiągalna. Wartości domyślne to geometria, która ma już zatwierdzony wzorzec referencyjny (golden) (użytkownik na -80 deg z anteną 2 m, trzy latarnie na -80/0, -79/+60 i -79/-60 na 2 km, sześciosatelitarna ilustracyjna migawka LCNS w t=0, maska 5 deg), więc goły przebieg odtwarza tabelę, którą wyrocznia już obejmuje, zamiast wymyślać nowe liczby. MODELLED: projekt konstelacji, rozmieszczenie latarni i każda wielkość budżetu błędów są ilustracyjnymi danymi wejściowymi, a nie rzeczywistym pomiarem terenowym ani zmierzonym łączem; tylko arytmetyka DOP, postać zamknięta horyzontu i zależność sigma = DOP x sigma_URE są zakotwiczone zewnętrznie. Nie jest to zobowiązanie co do parametrów usługi.

Jeden przebieg scenarios/lunar-beacon.toml podsumowuje się tak: Uzupełnienie księżycowe latarniami powierzchniowymi — maska 5,0 deg, epoka +0 s, sigma_URE na latarnię 1,1576 m 6 satelitów, bez latarni sats 5 beacons 0 GDOP 11,6627 PDOP 9,6941 HDOP 3,4868 VDOP 9,0454 TDOP 6,4840 uzyskane 1-sigma: 3D 11,222 m H 4,036 m V 10,471 m 6 satelitów + 1 widoczna latarnia sats 5 beacons 1 GDOP 4,9979 PDOP 4,1160 HDOP 1,9721 VDOP 3,6128 TDOP 2,8350 uzyskane 1-sigma: 3D 4,765 m H 2,283 m V 4,182 m 24 satelity, bez latarni sats 19 beacons 0 GDOP 2,8929 PDOP 2,4226 HDOP 1,0199 VDOP 2,1974 TDOP 1,5811 uzyskane 1-sigma: 3D 2,804 m H 1,181 m V 2,544 m latarnie poprawiają PDOP 2.355x; zamiast tego większa konstelacja, 4.002x MODELLED: konstelacja, rozmieszczenie latarni i budżet błędów są ilustracyjnymi danymi wejściowymi. Jądro DOP pod spodem to jądro sprawdzone względem gnss_lib_py, a horyzont latarni to postać zamknięta L01.

Wejścia#

Ze schematu (kshana kinds --json):

• Pola wymagane: brak
• Pola opcjonalne: user, beacons, n_satellites, comparison_n_satellites, epoch_s, elevation_mask_deg, clock_sync_m, multipath_m, survey_m

Przykład scenarios/lunar-beacon.toml ustawia między innymi:

Uruchom#

kshana scenarios/lunar-beacon.toml

Co daje#

Wyniki skalarne tego przebiegu, z jednostkami podanymi przez silnik:

Dowody#

MODELLED: wiersze macierzy weryfikacji, które wymieniają ten rodzaj.

• MODELLED Rozszerzony o latarnie współczynnik DOP dla użytkownika na powierzchni Księżyca: wiersze linii widzenia widocznych satelitów i wiersze pomiaru odległości do widocznych latarni powierzchniowych są łączone w jedną macierz projektu i oceniane wspólnym jądrem DOP, a t Testy: validate_p2_beacon_before_after_table.rs.

Wiersze, które sam przebieg wykorzystał, wraz z wyrocznią, jaką macierz podaje dla każdego (publiczne źródła są tam wymienione):

• MODELLED Deterministyczne, haszowane na poziomie scenariusza, bramki SBOM i złotych wyników między platformami. Wyrocznia (ExternalDataset): zgodność SBOM z oficjalnym schematem JSON CycloneDX 1,5 (+ prawidłowe identyfikatory SPDX): zewnętrzny opublikowany standard, zero błędów walidacji w całym grafie zależności; część dotycząca determinizmu wskaźników jakości i odtwarzalności bajt w bajt pozostaje przypiętą kontrolą samospójności, więc wiersz pozostaje MODELLED
• MODELLED Rozszerzony o latarnie współczynnik DOP dla użytkownika na powierzchni Księżyca: wiersze linii widzenia widocznych satelitów i wiersze pomiaru odległości do widocznych latarni powierzchniowych są łączone. Wyrocznia (ReferenceImpl): Arytmetyka DOP to jądro crate::orbit::dop, osobno sprawdzone zewnętrznie względem gnss_lib_py w tests/dop_reference.rs; ten wiersz nie przejmuje statusu tamtego wiersza. Horyzont widoczności latarni to postać zamknięta L01, a sigma = DOP x sigma_URE to standardowa zależność GNSS (Kaplan i Hegarty, Understanding GPS/GNSS, sekcja 7). W tym wierszu samo uzupełnienie sprawdzono względem niezależnego

Ograniczenia#

Co raport samego przebiegu podaje jako niemodelowane lub niesprawdzone względem niezależnego wzorca:

• MODELLED: projekt konstelacji, rozmieszczenie latarni i każda wielkość budżetu błędów są ilustracyjnymi danymi wejściowymi, a nie rzeczywistym pomiarem terenowym ani zmierzonym łączem; tylko arytmetyka DOP, postać zamknięta horyzontu i zależność sigma = DOP x sigma_URE są zakotwiczone zewnętrznie. (katalog rodzajów (kshana kinds --json))
• CO JEST ZAKOTWICZONE, A CO NIE Zakotwiczone: złożenie DOP to jądro sprawdzone względem gnss_lib_py w tests/dop_reference.rs; widoczność latarni to postać zamknięta geometrycznego horyzontu dwuwysokościowego na Księżycu bez atmosfery (bez atmosfery, więc nie ma rozszerzenia refrakcyjnego, a ograniczenie jest dokładne); a sigma = DOP x sigma_URE to standardowa zależność (Kaplan i Hegarty, Understanding GPS/GNSS, sekcja 7). NIE zakotwiczone — MODELL (komentarz w pliku scenariusza, wiersze 40 do 49)
• Odtwarzalność i zapewnienie jakości oprogramowania jest MODELLED, nie jest sprawdzona względem niezależnego wzorca: jedno twierdzenie składowe jest sprawdzone zewnętrznie, ale cała możliwość składa się z elementów obliczonych na podstawie modelu, więc pozostaje obliczona na podstawie modelu. (macierz weryfikacji (docs/MODELLED-RATIONALE.md))
• Uzupełnienie księżycowe latarniami powierzchniowymi w zakresie DOP ma poziom MODELLED, nie jest niezależnie sprawdzone względem wzorca zewnętrznego: sprawdzono je względem odrębnej implementacji w tej samej bazie kodu — niezależnej od testowanego elementu, ale nie będącej autorytetem zewnętrznym. (macierz weryfikacji (docs/MODELLED-RATIONALE.md))

Zobacz też#

• Strona rodziny: Przestrzeń księżycowa i cislunarna
• Wszystkie rodzaje: KINDS.md