Scenario kind pagesEdit on GitHubSource: docs/kinds/by-kind/moonlight-service-volume.md

moonlight-service-volume (scenario kind)

Scenario kind of the engine v0.38.0, family Lunar and cislunar. 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#

Modelled lunar navigation service-volume analysis from an ILLUSTRATIVE, public-source Moonlight/LCNS-class lunar-orbit constellation (not affiliated with ESA): sweeps a selenographic lat/lon grid over a time horizon and reports DOP / coverage / availability (≥4 sats AND PDOP < threshold) plus a generalised lunar ARAIM protection-level (HPL/VPL) envelope over the volume. The DOP geometry REUSES the gnss_lib_py-VALIDATED kernel (crate::orbit::dop); the protection level REUSES the LunaNet LNIS lunar ARAIM machinery (crate::lunar, σ_URE≈30 m) and reduces to the existing south-pole PL as a special case. MODELLED composition: a circular-/elliptical-Keplerian relay set (not the real differential-corrected LCNS/NRHO ephemeris), a mean-rotation Moon (no libration/precessing pole). Deterministic (pure geometry). No TRL/heritage/agency endorsement.

One run of scenarios/moonlight-service-volume.toml summarises as: moonlight-service-volume | 8 sats (illustrative LCNS-class, not affiliated) | 24 pts × 12 epochs | coverage 37.8% (PDOP<6.0) | sats 4–7 | PDOP 2.19/13.74/180.30 | HPL 139–4177 m | PL avail 0.0% | MODELLED

Inputs#

From the schema (kshana kinds --json):

  • Required fields: none
  • Optional fields: n_sats, sma_km, eccentricity, inc_deg, argp_deg, lat_min_deg, lat_max_deg, lat_step_deg, lon_min_deg, lon_max_deg, lon_step_deg, horizon_hours, step_min, elev_mask_deg, pdop_threshold, alert_limit_m, p_hmi, perturbed, sigma_ure_m, export_site_lat_deg, export_site_lon_deg, export_antenna, ephemeris_path, planetary_kernel_path, epoch_utc, terrain

The example scenarios/moonlight-service-volume.toml sets, among others:

Field Value Unit
alert_limit_m 50 m
argp_deg 90 deg
eccentricity 0.6 not stated
elev_mask_deg 5 deg
horizon_hours 12 h
inc_deg 57.7 deg
kind moonlight-service-volume text
lat_max_deg -60 deg
lat_min_deg -90 deg
lat_step_deg 10 deg
lon_max_deg 180 deg
lon_min_deg -180 deg

Run it#

kshana scenarios/moonlight-service-volume.toml

What it gives#

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

Result Value Unit
alert_limit_m 50 m
coverage_pct 37.847222 %
elev_mask_deg 5 deg
hpl_max_m 4176.665443 m
hpl_min_m 138.725726 m
max_sats 7 count
min_sats 4 count
n_epochs 12 count
n_grid_points 24 count
n_pl_samples 249 count
The chart the engine writes for scenarios/moonlight-service-volume.toml, kind moonlight-service-volume

Evidence#

No matrix row names this kind by name; the label on its result is the engine's own, above.

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
  • VALIDATED Moonlight-class lunar DOP / coverage / availability + generalised lunar ARAIM protection levels over a service volume. Oracle (ExternalDataset): Independent third-party authority ANISE 0.10.2 astro::Orbit Keplerian propagator (Nyx Space, MPL-2.0) — an equinoctial two-body code path distinct from kshana's Newton-Raphson Kepler; per-satellite MCI position agrees to <1e-3 m and the derived visible-satellite count/set matches exactly at every grid point. The DOP kernel is gnss_lib_py-validated; integrity uses published LunaNet/LCNS parameters
  • VALIDATED Per-satellite topocentric look angles (azimuth clockwise from north, elevation) and slant range at a named selenographic site, given the satellite in the site's. Oracle (ExternalDataset): ANISE 0.10.2 (Nyx Space, MPL-2.0, run as a tool from xval/anise-service-geometry, binary lunar-look-angles-xval, which calls no Kshana code): ANISE's own azimuth, elevation and range routine (azimuth_elevation_range_sez) from sites built by its latitude-longitude-altitude constructor on the pck00011 Moon (sphere 1737.4 km), with the satellites rotated into MOON_PA_DE440 through moon_pa_de440_200625.bpc. 768 samples o

Limitations#

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

  • MODELLED composition: a circular-/elliptical-Keplerian relay set (not the real differential-corrected LCNS/NRHO ephemeris), a mean-rotation Moon (no libration/precessing pole). (kind catalogue (kshana kinds --json))
  • HONESTY: MODELLED composition. The DOP geometry is validated BY REUSE of the validated kernel; the coverage / availability / integrity composition is MODELLED — a circular-/ elliptical-Keplerian relay set (not a differential-corrected LCNS / 9:2 NRHO ephemeris), a mean-rotation Moon (no physical libration / precessing pole), and published LunaNet LNIS integrity parameters. This demonstrates the lunar service-volume M (scenario file comment, lines 27 to 32)
  • 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))

See also#