Payload Integration · Stellar Control

For the subsystem integrator who receives a payload from a supplier, with its ICD as the only input. Repository: stellar-systems-eu/control-usecase-payload-integration · Try it.

The payload is the HSC-100, a VNIR push-broom hyperspectral camera for 6U CubeSats, commanded over CSP. Its supplier and the camera are fictitious; the ICD (icd/hsc-100.md) is representative of what a supplier delivers: network, modes, ports and their frames, housekeeping record, on-board files, status codes, faults, limits and timings.

1. From the ICD to the catalogue#

packages/hsc-100/catalogue.yaml is written by hand from the ICD. What the ground segment knows of the camera goes there; the bytes stay in the driver.

ICD	Catalogue
Modes (§4), status codes (§8)	Enums, and measures calibrated by enumeration (`raw: u8`, `calibration: {enum: …}`)
Housekeeping record (§6)	Measures with their raw type, calibration and limits. The temperatures at 0.01 °C (issue 2.1) are a polynomial `[0, 0.01]`
Fault flags (§9)	One boolean measure per bit, split by the driver
"Acquisition in READY only, detector at its setpoint, 10 min between two" (§5.2)	`requires: ["can_acquire"]`, a derived measure of the mode, the setpoint and the duty cycle
"An acquisition lasts at most 60 s" (§5.1)	`requires: ["args.lines * args.integration_time <= 60 s"]`
Release the cover, erase the storage (keyed, irreversible)	`hazardous: true`: an operator confirms each send. The keys stay in the driver
Files, chunks of 184 B (§7)	The standard `files` component, `protocol: chunked`, `max_chunk: 184 B`, `checksum: crc32`
Detector setpoint per mode	A `parameter` with `set` and `readback`, its values per mode in the topology

stellar check . checks it as it is written: types, units, limits, calibrations, conditions. See Catalogue Packages and Telecommands and Verification.

2. The simulation#

Shell

stellar generate simulation hsc-100 --repository .

This writes a simulated camera that meets every verification of the catalogue, a starting point. simulations/hsc-100-sim.yaml then makes it realistic by hand:

powers per mode: 1.8 W in standby, 4.5 W in READY, 11 W imaging;
the detector cooling to its setpoint;
the camera going by itself from COOLING to READY, and from IMAGING back to READY at the end of an acquisition (then, until);
the duty cycle, the storage filling up;
the faults of the ICD.

See Simulated Targets.

3. The driver#

Shell

stellar generate driver hsc-100 --repository . -o drivers/hsc_100 --software hsc-100-csp

This writes the typed skeleton (_generated.py, regenerated with each version of the catalogue). driver.py, completed from the ICD, then builds whole CSP 1 packets:

the address and port of each request come from the ICD;
the address of the ground comes from the link (csp_address);
the transport of the link (csp1-kiss, csp1-can) frames and checks them.

It decodes the replies into raw samples, the file listing into one instance of files per file, the chunks of a read into file chunks, and recognises the echo of a ping. test_driver.py compares each frame with the one the ICD gives. See Code Generation and Drivers.

4. First light#

packages/hsc-100-ops holds the procedures written against the catalogue: First light, Release cover (hazardous, confirmed) and Download quicklook.

Shell

stellar run --dry runs/first-light.yaml --repository . --report report.html

First light runs in this order:

the camera answers and is healthy;
it is configured for the Nominal mode (detector setpoint);
READY through COOLING;
a short acquisition, waiting for its return to READY;
back to standby.

The topology already declares the engineering model on the CAN bus of the integration bench (cam-em-1, environment BENCH). The same procedures run there unchanged.

Then#

The catalogue hsc-100 is the deliverable: Satellite integration imports it as the payload of a 6U CubeSat, with its driver and its procedures (see Importing Components).