Stellar Systems builds the software and hardware that integration labs, operators and subsystem manufacturers use to test, qualify and fly: mission control, bench interfaces, and RF link emulation that share one set of procedures.
| 10:42:07.114 | send | obc.set_mode SAFE | CAN · ECHO |
| 10:42:07.958 | expect | obc.mode is SAFE | ✓ 0.84 s |
| 10:42:08.310 | check | eps.bus_voltage | 28.1 V · 26–30 V |
| 10:42:09.020 | rf | pass leo_doppler_v1 · UHF | AOS · locked |
| 10:42:11.021 | ask | operator: arm deployment? | confirmed |
| 10:42:14.487 | step | "Pre-flight checks" | passed · evidence |
Stellar Control runs the procedures, Stellar Bench reaches the hardware, Stellar Link brings the RF channel to the bench.
From the test bench to orbit, with the same procedures.
Drives your equipment under test, your EGSE and your spacecraft through telecommands, telemetry and file transfers. Catalogues, topologies and procedures are code: versioned, reviewed and validated before they reach a bench or a satellite.
Every bus of your bench, one box.
Connects your equipment under test through CAN, RS-422, RS-485, Ethernet, SpaceWire and discrete I/O, and brings every link to Stellar Control over one network cable.
Fly the pass on the bench.
A software-defined radio test bench for satellite links: CCSDS and CSP over BPSK, QPSK and GMSK, a LEO pass played in the FPGA, measured assertions and a report for every run.
Only the topology changes between environments. Each one enforces its own rules, and every run leaves its evidence.
Catalogues, topologies and procedures in Git, reviewed and compiled in CI by Stellar Control.
Deterministic simulated targets with faults, link losses and passes, on a laptop.
Stellar Bench binds CAN, serial, SpaceWire and Ethernet to the system in one box.
Stellar Link replays the pass: Doppler, path loss, AOS and LOS, measured.
The same procedures in orbit, with confirmations, plans and a full audit trail.
A payload to integrate, a CubeSat from simulation to flight model, a test bench that runs unattended: each one runs in your browser or in an environment of your own.
From the supplier's ICD to a driver and a simulation, before the hardware arrives.
See the use case →One topology, the same procedures in simulation, on the flatsat and on the flight model.
See the use case →Environmental test facilities that run unattended, and stop safely when they must.
See the use case →Everything that describes a mission lives in a repository, follows merge requests and is compiled before use.
Every command, acknowledgement and verdict is recorded with the configuration version that produced it.
On-premise, in hosted isolated cells, or hybrid: the core where you want it, gateways next to the hardware.
Rust and Python SDKs, HTTP and WebSocket APIs, and a documented contract any language can join.
We help you from the interface document to the first run on your bench.
