Машинний переклад, не перевірений носієм мови. Еталоном є англійська версія.

Сторінки видів сценаріївРедагувати на GitHubДжерело: docs/kinds/by-kind/lunar-beacon.md

lunar-beacon (вид сценарію)

Тип сценарію рушія v0.40.0, родина Місячний і цисмісячний простір. Лише консультативно: результат аналізу від дослідницького та інженерного інструмента; це не навігаційне обладнання із затвердженням типу і не послуга забезпечення безпеки життя. Кожна позначка тут належить рушієві або матриці верифікації; тип вважається MODELLED, якщо матриця не каже іншого (як заробляється позначка: розділ Evidence у README).

Що він робить#

Доповнення місячної орбітальної навігаційної служби наземними маяками у вигляді запускної таблиці «до/після». Користувач на південному полюсі бачить розріджений орбітальний набір у вузькій ділянці неба, тому геометрія вимірювання дальності погано обумовлена; кілька ОБСТЕЖЕНИХ НАЗЕМНИХ МАЯКІВ додають рядки прямої видимості з малим кутом місця та широким азимутом, яких бракує набору, що весь над головою, і горизонтальний геометричний чинник DOP різко падає. Сценарій повідомляє три конфігурації на одній епосі — лише супутники, супутники плюс видимі маяки та більше угруповання як альтернативний шлях до тієї самої геометрії — кожну з кількістю видимих джерел, повним DOP та реалізованою точністю 1-сигма в МЕТРАХ, отриманою множенням на еквівалентну користувачеві похибку дальності на маяк, складену як корінь із суми квадратів доданків синхронізації годинників, багатопроменевості та обстеження. Видимість маяка — це геометричний горизонт безповітряного Місяця за двома висотами (без атмосфери, тож межа точна), а складання DOP — це те саме ядро, перехресно перевірене з gnss_lib_py у tests/dop_reference.rs. НАВІЩО ЦЕЙ ВИД ІСНУЄ: модуль за ним був у рушії і перевірявся за незалежним шляхом DOP з L08/L09, але був недосяжний із прогону — без виду, без гілки диспетчеризації, без вбудованого файлу. README рекламував можливість, а матриця верифікації НЕ мала жодного рядка для неї, тож вона водночас була заявлена в прозі й незаявлена в реєстрі, залишаючись недосяжною в рушії. Типові значення — це геометрія, яка вже має зафіксований еталонний результат (користувач на -80 град з антеною 2 м, три маяки на -80/0, -79/+60 і -79/-60 на 2 км, ілюстративний знімок LCNS із шести супутників за t=0, маска 5 град), тож порожній прогін відтворює таблицю, яку вже охоплює оракул, а не вигадує нові числа. MODELLED: проєкт угруповання, розміщення маяків і кожна величина бюджету похибок — це ілюстративні входи, а не експлуатаційне обстеження чи виміряна лінія; лише арифметика DOP, замкнена форма горизонту та співвідношення sigma = DOP x sigma_URE мають зовнішнє закріплення. Не є зобов'язанням щодо продуктивності служби.

Один прогін scenarios/lunar-beacon.toml підсумовується так: 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.

Входи#

Зі схеми (kshana kinds --json):

  • Обов'язкові поля: немає
  • Необов'язкові поля: user, beacons, n_satellites, comparison_n_satellites, epoch_s, elevation_mask_deg, clock_sync_m, multipath_m, survey_m

Приклад scenarios/lunar-beacon.toml задає, зокрема:

Поле Значення Одиниця
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 не вказано
elevation_mask_deg 5 deg

Запуск#

kshana scenarios/lunar-beacon.toml

Що це дає#

Скалярні результати цього прогону з одиницями, які вказує рушій:

Результат Значення Одиниця
beacon_pdop_improvement 2.355211 1
constellation_pdop_improvement 4.001566 1
elevation_mask_deg 5 deg
epoch_s 0 s
evidence.id_rule стабільний ідентифікатор рядка матриці (ID text
evidence.matrix docs/VERIFICATION-MATRIX.md text
evidence.tier MODELLED text
sigma_ure_m 1.157584 m
Діаграма, яку рушій записує для scenarios/lunar-beacon.toml, вид lunar-beacon

Докази#

MODELLED: рядки матриці верифікації, що називають цей різновид.

  • MODELLED Диференційне погіршення точності з урахуванням маяків для користувача на місячній поверхні: рядки променів візування видимих супутників і рядки далекомірних вимірювань видимих наземних маяків об'єднано в одну матрицю плану й обчислено через спільне ядро DOP, а t Тести: validate_p2_beacon_before_after_table.rs.

Рядки, які задіяв сам прогін, з оракулом, що його дає матриця кожному (публічні джерела названі там):

  • MODELLED Детерміновані, хешовані за сценарієм, SBOM + міжплатформні еталонні шлюзи. Оракул (ExternalDataset): відповідність SBOM офіційній схемі JSON CycloneDX 1,5 (+ дійсні ідентифікатори SPDX) — зовнішній опублікований стандарт, нуль помилок валідації на всьому графі залежностей; частина щодо детермінованості FoM / побайтової відтворюваності залишається закріпленою перевіркою самоузгодженості, тому рядок залишається MODELLED
  • MODELLED Диференційне погіршення точності з урахуванням маяків для користувача на місячній поверхні: рядки променів візування видимих супутників і рядки далекомірних вимірювань видимих наземних маяків об'єднано. Оракул (ReferenceImpl): арифметика DOP виконується ядром crate::orbit::dop, яке окремо зовнішньо перевірено за gnss_lib_py у tests/dop_reference.rs; цей рядок не успадковує статус того рядка. Горизонт видимості маяків — це замкнена формула L01, а sigma = DOP x sigma_URE — стандартне співвідношення ГНСС (GNSS) (Kaplan and Hegarty, Understanding GPS/GNSS, розділ 7). У межах цього рядка саму аугментацію перевірено за незалежним

Обмеження#

Що, за власним звітом прогону, не обчислено за моделлю або не перевірено за зовнішнім еталоном:

  • MODELLED: конструкція орбітального угруповання, розміщення маяків і кожна величина бюджету похибок — ілюстративні вхідні дані, а не обстеження в реальних умовах і не виміряна лінія зв'язку; зовнішньо закріплені лише арифметика DOP, замкнена формула горизонту та співвідношення sigma = DOP x sigma_URE. (каталог видів (kshana kinds --json))
  • ЩО ЗАКРІПЛЕНО І ЩО НІ Закріплено: складання DOP — це ядро, перехресно перевірене за gnss_lib_py у tests/dop_reference.rs; видимість маяків — це замкнена формула геометричного горизонту для двох висот на Місяці без атмосфери (атмосфери немає, тож рефракційного розширення немає, а межа точна); а sigma = DOP x sigma_URE — стандартне співвідношення (Kaplan & Hegarty, Understanding GPS/GNSS, розділ 7). НЕ закріплено — MODELL (коментар у файлі сценарію, рядки 40–49)
  • Відтворюваність і гарантування якості програмного забезпечення — MODELLED, а не перевірено за зовнішнім еталоном: підтвердження частини вимоги перевірено зовні, але вся можливість складається з обчислених за моделлю частин, тому можливість залишається обчисленою за моделлю. (матриця верифікації (docs/MODELLED-RATIONALE.md))
  • Доповнення DOP місячними наземними маяками є MODELLED, а не перевіреним за незалежним зовнішнім еталоном: перевірено за окремою реалізацією в цій самій кодовій базі — незалежною від досліджуваного модуля, але не зовнішньо авторитетною. (матриця верифікації (docs/MODELLED-RATIONALE.md))

Див. також#