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

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

contact-schedule (тип сценарію)

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

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

Планування наземних контактів для кількох супутників над кількома станціями: видимі вікна доступу (SGP4, земна система IAU 2006/2000A, рефракція ITU-R P.834, світловий час), обсяг даних DVB-S2 ACM кожного проходу (пороги ETSI EN 302 307-1 Table 13) та безконфліктний розклад (один супутник на антену із часом переналаштування, одна станція на супутник, зважена за пріоритетом доставка, обмежена кожним накопиченим обсягом) жадібним методом за граничною цінністю, базовим методом «хто перший» і точним методом гілок і меж на малих наборах, з розривом оптимальності жадібного методу. MODELLED.

Один прогін scenarios/contact-schedule.toml підсумовується так: contact-schedule: 3 супутники x 3 станції за 12 год -> 31 кандидат на контакт, 22 заплановано; доставлено 797266 із 860000 Мбіт (MODELLED)

Входи#

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

  • Обов'язкові поля: немає
  • Необов'язкові поля: epoch, duration_hours, step_s, refraction, light_time, link, satellites, stations

Приклад scenarios/contact-schedule.toml задає, серед іншого:

Поле Значення Одиниця
duration_hours 12 h
epoch [2024, 1, 1, 0, 0, 0] не вказано
kind contact-schedule text
light_time true flag
link.acm_step_s 10 s
link.eirp_dbw 7 dBW
link.frequency_ghz 8.2 GHz
link.implementation_margin_db 1 dB
link.other_losses_db 2 dB
link.symbol_rate_msps 20 Msymbol/s
link.zenith_atm_loss_db 0.3 dB
refraction true flag

Запуск#

kshana scenarios/contact-schedule.toml

Що це дає#

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

Результат Значення Одиниця
candidate_contacts 31 кількість
conflicting_pairs 5 кількість
duration_hours 12 h
evidence.id_rule стабільний ідентифікатор рядка матриці (ID text
evidence.matrix docs/VERIFICATION-MATRIX.md text
evidence.tier MODELLED text
light_time true flag
link.acm_step_s 10 s
link.eirp_dbw 7 dBW
link.frequency_ghz 8.2 GHz

Позначка результату (від рушія): MODELLED — план контактів для кількох супутників і кількох станцій: видимі вікна доступу (SGP4, IAU 2006/2000A, рефракція ITU-R P.834, світловий час), обсяг даних DVB-S2 ACM на прохід за бюджетом лінії за ясного неба (пороги ETSI EN 302 307-1 Table 13) та розв'язання конфліктів (один супутник на антену із

Діаграма, яку рушій записує для scenarios/contact-schedule.toml, тип contact-schedule

Докази#

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

  • MODELLED Es/N0 низхідної лінії вздовж кожного проходу одного супутника над однією станцією (EIRP, втрати у вільному просторі, атмосферні втрати за косекансним законом, інші втрати, G/T, стала Больцмана, символьна швидкість), найефективніший MODCOD DVB-S2, що долає свій ETSI EN 302 307-
  • MODELLED Кандидати на контакт з кожного проходу супутник–станція з його обсягом даних ACM; конфлікти, де одна антена обслуговувала б два супутники в межах свого часу переналаштування або один супутник передавав би на дві станції одночасно; зважена за пріоритетом доставка

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

  • MODELLED Детерміновані, хешовані за сценарієм, SBOM + міжплатформні еталонні шлюзи. Оракул (ExternalDataset): відповідність SBOM офіційній схемі JSON CycloneDX 1,5 (+ дійсні ідентифікатори SPDX) — зовнішній опублікований стандарт, нуль помилок валідації на всьому графі залежностей; частина щодо детермінованості FoM / побайтової відтворюваності залишається закріпленою перевіркою самоузгодженості, тому рядок залишається MODELLED
  • VALIDATED Проходи видимості (AOS, TCA, LOS, максимальна видима висота, тривалість) набору елементів SGP4 над станцією WGS-84 на перевіреному за зовнішнім еталоном шляху навколоземної орбіти (IAU 2006. Оракул (ExternalDataset): Orekit 13.1.8 (CS GROUP, Apache-2.0) з Hipparchus 4.0.3: TLEPropagator на тих самих наборах елементів у TEME, який Orekit будує за заявленим визначенням (його IERS 2010 TOD, повернутий на GAST - GMST), ElevationDetector і ElevationExtremumDetector з ITURP834AtmosphericRefraction і без неї та AngularAzEl з AngularRadioRefractionModifier для випадку світлового часу, перетини й максимум розв'язує Hipparchus; 60 випадків (f
  • MODELLED Es/N0 низхідної лінії вздовж кожного проходу одного супутника над однією станцією (EIRP, втрати у вільному просторі, атмосферні втрати за косекансним законом, інші втрати, G/T, стала Больцмана,. Оракул (InternalConsistency): внутрішня узгодженість: спектральна ефективність, обчислена в замкненій формі з K_bch таблиці 5a і довжин кадрів, збігається з ефективностями, які друкує таблиця 13 (перевірка транскрипції таблиці порогів); складники бюджету лінії збігаються зі своїми замкненими формами; вибір монотонний за Es/N0 і шанує запас; ACM передає щонайменше обсяг зі сталим кодуванням. Геометрія проходу походить з окремо VALIDATED а
  • MODELLED Кандидати на контакт з кожного проходу супутник–станція з його обсягом даних ACM; конфлікти, де одна антена обслуговувала б два супутники в межах свого часу переналаштування або о. Оракул (InternalConsistency): Внутрішня узгодженість: точний метод гілок і меж збігається з повним перебором на малих випадкових наборах, кожен план перевіряється на здійсненність за правилами конфліктів, а жадібний метод ніколи не перевершує точний оптимум. ЧОГО НЕМАЄ: жодного зовнішнього планувальника чи оперативного плану не порівнювали; контакти беруться цілком (без розбиття), накопичений обсяг фіксований на початку вікна, час повороту понад фіксований час переналаштування та бортов

Обмеження#

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

  • MODELLED — план контактів для кількох супутників і кількох станцій: видимі вікна доступу (SGP4, IAU 2006/2000A, рефракція ITU-R P.834, світловий час), обсяг даних DVB-S2 ACM на прохід за бюджетом лінії за ясного неба (пороги ETSI EN 302 307-1 Table 13) та розв'язання конфліктів (один супутник на антену із часом переналаштування, одна станція на супутник) жадібним методом за граничною цінністю, звіреним із точним методом гілок і меж; без дощового згасання, (результат label)
  • MODELLED. (каталог різновидів (kshana kinds --json))
  • Кожне число нижче є ILLUSTRATIVE: не орбіти, станції чи бюджет лінії жодного оператора. MODELLED: планувальник звірено з власним точним розв'язувачем, а не із зовнішнім інструментом. (коментар у файлі сценарію, рядки 11–12)
  • Відтворюваність і гарантування якості програмного забезпечення — MODELLED, а не перевірено за зовнішнім еталоном: підтвердження частини вимоги перевірено зовні, але вся можливість складається з обчислених за моделлю частин, тому можливість залишається обчисленою за моделлю. (матриця верифікації (docs/MODELLED-RATIONALE.md))
  • Адаптивне кодування та модуляція DVB-S2 вздовж проходу низхідної лінії LEO — MODELLED, а не перевірено за зовнішнім еталоном: звірено з власною замкненою / аналітичною тотожністю — ловить помилки транскрипції та коефіцієнтів, але не є зовнішнім оракулом. (матриця верифікації (docs/MODELLED-RATIONALE.md))
  • Планування наземних контактів для кількох супутників і кількох станцій із розв'язанням конфліктів є MODELLED, а не перевіреним (validated): звірено з власною замкненою / аналітичною тотожністю — виявляє помилки перенесення та коефіцієнтів, але не є зовнішнім оракулом. (матриця верифікації (docs/MODELLED-RATIONALE.md))

Див. також#