Scenario kind pagesEdit on GitHubSource: docs/kinds/by-kind/aperture-duty-cycle.md

aperture-duty-cycle (scenario kind)

Scenario kind of the engine v0.38.0, family Mission analysis, links and space operations. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. Every label here is the engine's or the verification matrix's; a kind is MODELLED unless the matrix says otherwise (how a label is earned: the README's Evidence section).

What it does#

Aperture duty cycle: the navigation-versus-communications time-share a contact plan implies for a pool of steerable apertures. Takes a contact plan (a list of [[contacts]] aos_s/los_s windows, each asking for navigation or communications — the same aos_s/los_s vocabulary the passes predictor emits), an aperture count, and an ARBITRATION POLICY (navigation-priority by default, or communications-priority, or non-preemptive first-come-first-served), and reports the navigation duty, the communications duty, the idle duty, and the per-session outage — the contact time a session requested and no aperture served. An exact interval sweep over the window boundaries, so touching windows never contend and no aperture-second is double-counted; navigation, communications and idle aperture-seconds are accumulated independently and close against apertures*horizon_s. The report states the resolved policy, its full definition, and the duty and outage definitions, because a duty figure quoted without its arbitration policy is not reproducible. MODELLED scheduling arithmetic: no slew / retune / changeover time is charged when an aperture changes service or session, no data volume, buffer state, energy budget or link closure enters the decision, and the contact windows are inputs — their geometry is whatever produced them. Not a ground-segment scheduling product.

One run of scenarios/aperture-duty-cycle.toml summarises as: aperture-duty-cycle: 6 session(s) on 2 aperture(s) under navigation-priority -> navigation duty 0.1167, communications duty 0.2667, idle 0.6167; 0 s of 6900 s requested lost to contention (MODELLED)

Inputs#

From the schema (kshana kinds --json):

  • Required fields: none
  • Optional fields: apertures, arbitration, horizon_start_s, horizon_end_s, contacts

The example scenarios/aperture-duty-cycle.toml sets, among others:

Field Value Unit
apertures 2 count
arbitration navigation-priority text
contacts[0].aos_s 0 s
contacts[0].los_s 600 s
contacts[0].name nav-1 text
contacts[0].service navigation text
contacts[1].aos_s 300 s
contacts[1].los_s 1500 s
contacts[1].name comms-1 text
contacts[1].service communications text
contacts[2].aos_s 3600 s
contacts[2].los_s 4500 s

Run it#

kshana scenarios/aperture-duty-cycle.toml

What it gives#

The scalar results of that run, with the units the engine states:

Result Value Unit
aperture_seconds_available 18000 aperture*s
apertures 2 count
arbitration_policy navigation-priority text
arbitration_policy_default navigation-priority text
communications_duty 0.266667 fraction (dimensionless)
communications_served_aperture_s 4800 aperture*s
contention_s 0 s
horizon_end_s 9000 s
horizon_s 9000 s
horizon_start_s 0 s

Result label (the engine's): MODELLED — aperture scheduling arithmetic over a supplied contact plan: an exact interval sweep of navigation-versus-communications time-share and per-session contention loss under a named arbitration policy. No slew / retune / changeover time is charged when an aperture changes service or session,

The chart the engine writes for scenarios/aperture-duty-cycle.toml, kind aperture-duty-cycle

Evidence#

MODELLED: the verification matrix rows that name this kind.

  • MODELLED One run takes a contact plan (a list of aos_s/los_s windows, each asking the aperture for navigation or communications — the same window vocabulary passes::predict_passes emits, converted by aperture_duty::windows_from_passes), an apert

The rows the run itself exercised, with the oracle the matrix gives each (the public sources are named there):

  • MODELLED Deterministic, scenario-hashed, SBOM + cross-platform golden gates. Oracle (ExternalDataset): SBOM conformance to the official CycloneDX 1.5 JSON Schema (+ valid SPDX identifiers) — an external published standard, zero validation errors over the full dependency graph; the FoM-determinism / byte-reproducibility part remains a pinned self-consistency check, so the row stays MODELLED
  • MODELLED One run takes a contact plan (a list of aos_s/los_s windows, each asking the aperture for navigation or communications — the same window vocabulary `passes::pre. Oracle (InternalConsistency): Internal consistency, from three quantities computed by different expressions in the same sweep and then required to close. Navigation aperture-seconds, communications aperture-seconds and idle aperture-seconds are accumulated separately — idle from (apertures − |served|) per elementary interval, never as a remainder — and their sum is asserted against apertures × horizon_s, which a mis-bracketed boundary, a double-c

Limitations#

What the run's own report says is not modelled or not validated:

  • MODELLED — aperture scheduling arithmetic over a supplied contact plan: an exact interval sweep of navigation-versus-communications time-share and per-session contention loss under a named arbitration policy. No slew / retune / changeover time is charged when an aperture changes service or session, no data volume, buffer state, energy budget or link closure enters the decision, and the contact windows are inputs — th (result label)
  • MODELLED scheduling arithmetic: no slew / retune / changeover time is charged when an aperture changes service or session, no data volume, buffer state, energy budget or link closure enters the decision, and the contact windows are inputs — their geometry is whatever produced them. (kind catalogue (kshana kinds --json))
  • HONEST SCOPE: MODELLED scheduling arithmetic over the supplied windows. No slew / retune / changeover time is charged when an aperture changes service or session; no data volume, buffer state, energy budget or link closure enters the decision; and the contact windows are inputs -- their geometry is whatever produced them (the passes scenario emits the same aos_s / los_s vocabulary). Not a ground-segment scheduling (scenario file comment, lines 18 to 24)
  • Reproducibility & software assurance is MODELLED, not validated: a sub-claim is externally checked, but the whole capability composes modelled pieces, so the capability stays Modelled. (verification matrix (docs/MODELLED-RATIONALE.md))
  • Aperture navigation-versus-communications duty cycle is MODELLED, not validated: checked against its own closed-form / analytic identity — catches transcription and coefficient errors, but is not an external oracle. (verification matrix (docs/MODELLED-RATIONALE.md))

See also#