Машинный перевод, не проверенный носителем языка. Эталоном служит английская версия.

Страницы видов сценариевПравить на GitHubИсточник: docs/kinds/by-kind/aperture-duty-cycle.md

aperture-duty-cycle (вид сценария)

Вид сценария движка v0.40.0, семейство Анализ миссий, линии связи и космические операции. Носит консультативный характер: результат анализа исследовательского и инженерного инструмента; это не навигационное оборудование с утверждённым типом и не служба обеспечения безопасности жизни. Каждая метка здесь принадлежит движку или матрице верификации; вид считается MODELLED, если матрица не говорит иного (как заслуживается метка: раздел README «Evidence»).

Что делает#

Коэффициент занятости апертур: разделение времени между навигацией и связью, которое подразумевает план контактов для пула управляемых апертур. Принимает план контактов (список окон [[contacts]] aos_s/los_s, каждое из которых запрашивает навигацию или связь — тот же словарь aos_s/los_s, который выдаёт предиктор passes), число апертур и ПОЛИТИКУ АРБИТРАЖА (по умолчанию приоритет навигации, либо приоритет связи, либо невытесняющее обслуживание в порядке поступления) и сообщает занятость навигацией, занятость связью, долю простоя и простой по сеансам — время контакта, которое сеанс запросил и которое ни одна апертура не обслужила. Точный интервальный проход по границам окон, поэтому соприкасающиеся окна никогда не конкурируют и ни одна секунда апертуры не учитывается дважды; секунды апертур для навигации, связи и простоя накапливаются независимо и сходятся с apertures*horizon_s. Отчёт указывает применённую политику, её полное определение и определения занятости и простоя, потому что значение занятости, приведённое без политики арбитража, невоспроизводимо. MODELLED арифметика планирования: время на перенаведение / перестройку / смену не учитывается, когда апертура меняет службу или сеанс, в решении не участвуют ни объём данных, ни состояние буфера, ни энергобюджет, ни замыкание линии, а окна контактов — входные данные, и их геометрия такова, какой её получил источник. Это не продукт для планирования наземного сегмента.

Один прогон scenarios/aperture-duty-cycle.toml сводится к следующему: aperture-duty-cycle: 6 сеанса(ов) на 2 апертурах при приоритете навигации -> занятость навигацией 0,1167, занятость связью 0,2667, простой 0,6167; 0 с из 6900 с запрошенных потеряно из-за конкуренции (MODELLED)

Входные параметры#

Из схемы (kshana kinds --json):

  • Обязательные поля: нет
  • Необязательные поля: apertures, arbitration, horizon_start_s, horizon_end_s, contacts

Пример scenarios/aperture-duty-cycle.toml задаёт, среди прочего:

Поле Значение Единица
apertures 2 число
arbitration navigation-priority текст
contacts[0].aos_s 0 s
contacts[0].los_s 600 s
contacts[0].name nav-1 текст
contacts[0].service навигация текст
contacts[1].aos_s 300 s
contacts[1].los_s 1500 s
contacts[1].name comms-1 текст
contacts[1].service связь текст
contacts[2].aos_s 3600 s
contacts[2].los_s 4500 s

Запустите#

kshana scenarios/aperture-duty-cycle.toml

Что он даёт#

Скалярные результаты этого прогона с единицами, которые указывает движок:

Результат Значение Единица
aperture_seconds_available 18000 aperture*s
apertures 2 число
arbitration_policy navigation-priority текст
arbitration_policy_default navigation-priority текст
communications_duty 0.266667 доля (безразмерная)
communications_served_aperture_s 4800 aperture*s
contention_s 0 s
evidence.id_rule стабильный идентификатор строки матрицы (ID текст
evidence.matrix docs/VERIFICATION-MATRIX.md текст
evidence.tier MODELLED текст

Метка результата (движка): MODELLED — арифметика планирования апертур по заданному плану контактов: точный интервальный проход по разделению времени между навигацией и связью и потерям на конкуренцию по сеансам при названной политике арбитража. Время на перенаведение / перестройку / смену не учитывается, когда апертура меняет службу или сеанс,

График, который движок записывает для scenarios/aperture-duty-cycle.toml, вид aperture-duty-cycle

Доказательства#

MODELLED: строки матрицы верификации, называющие этот вид.

  • MODELLED Один прогон принимает план контактов (список окон aos_s/los_s, каждое из которых запрашивает у апертуры навигацию или связь — тот же словарь окон, который выдаёт passes::predict_passes и преобразует aperture_duty::windows_from_passes), число апертур

Строки, которые задействовал сам прогон, с оракулом, который указывает им матрица (публичные источники названы там):

  • MODELLED Детерминированные, хешируемые по сценарию, SBOM и кроссплатформенные эталонные проверки (golden). Оракул (ExternalDataset): соответствие SBOM официальной схеме JSON CycloneDX 1,5 (плюс допустимые идентификаторы SPDX) — внешний опубликованный стандарт, ноль ошибок валидации на всём графе зависимостей; часть о детерминизме FoM и побайтной воспроизводимости остаётся закреплённой проверкой внутренней согласованности, поэтому строка остаётся MODELLED
  • MODELLED Один прогон принимает план контактов (список окон aos_s/los_s, каждое из которых запрашивает у апертуры навигацию или связь — тот же словарь окон, который `passes::pre. Оракул (InternalConsistency): Внутренняя согласованность, по трём величинам, вычисленным разными выражениями в одном проходе, которые затем должны сойтись. Секунды апертур навигации, секунды апертур связи и секунды апертур простоя накапливаются отдельно — простой из (apertures − |served|) на элементарный интервал, а не как остаток, — и их сумма проверяется на равенство apertures × horizon_s, чего ошибочно расставленная граница, двойной уч

Ограничения#

Что отчёт самого прогона называет не смоделированным или не проверенным:

  • MODELLED — арифметика планирования апертур по заданному плану контактов: точный интервальный проход по разделению времени между навигацией и связью и потерям на конкуренцию по сеансам при названной политике арбитража. Время на перенаведение / перестройку / смену не учитывается, когда апертура меняет службу или сеанс, в решении не участвуют ни объём данных, ни состояние буфера, ни энергобюджет, ни замыкание линии, а окна контактов — входные данные — их (результат label)
  • MODELLED арифметика планирования: время на перенаведение / перестройку / смену не учитывается, когда апертура меняет службу или сеанс, в решении не участвуют ни объём данных, ни состояние буфера, ни энергобюджет, ни замыкание линии, а окна контактов — входные данные, и их геометрия такова, какой её получил источник. (каталог видов (kshana kinds --json))
  • ЧЕСТНАЯ ОБЛАСТЬ ПРИМЕНЕНИЯ: MODELLED арифметика планирования по заданным окнам. Время на перенаведение / перестройку / смену не учитывается, когда апертура меняет службу или сеанс; в решении не участвуют ни объём данных, ни состояние буфера, ни энергобюджет, ни замыкание линии; а окна контактов — входные данные -- их геометрия такова, какой её получил источник (сценарий passes выдаёт тот же словарь aos_s / los_s). Не планирование наземного сегмента (комментарий в файле сценария, строки 18–24)
  • Воспроизводимость и гарантии качества ПО — MODELLED, а не validated: одно из частных утверждений проверено извне, но вся возможность составлена из смоделированных частей, поэтому возможность остаётся Modelled. (матрица верификации (docs/MODELLED-RATIONALE.md))
  • Коэффициент занятости апертуры навигацией и связью — MODELLED, а не validated: проверено по собственному замкнутому / аналитическому тождеству — это выявляет ошибки переписывания и коэффициентов, но не является внешним оракулом. (матрица верификации (docs/MODELLED-RATIONALE.md))

См. также#