Overview · Stellar Control

Stellar Control is a Mission Control System for space systems. It sends telecommands, decodes telemetry into measures, runs operational procedures, raises alarms, plans runs on ground station passes and transfers files. The same system, the same catalogues and the same procedures serve the test bench, the flatsat and the satellite in orbit: only the environment changes.

It is written in Rust, runs on top of a NATS server with JetStream, and is driven from a command line (stellar), a web console and an HTTP/WebSocket API.

What it does#

Capability	In short	Read more
Telecommands	Semantic telecommands with typed arguments, preconditions and a three-step acknowledgement chain (driver, gateway, verification on telemetry)	Telecommand Lifecycle
Telemetry	Frames decoded by drivers, calibrated, turned into derived measures, kept as current values	Measures and Current Values
Procedures	A dedicated language, inspired by PLUTO, checked at compile time: steps, procedures, retries, confirmations	Procedure Language
Runs	Launch, follow, answer, suspend, resume, abort; evidence and HTML test reports	Running Procedures
Safety	Hazardous telecommands confirmed by operator and supervisor, policies per environment	Hazardous Confirmations
Passes and scheduling	Passes pushed by the flight dynamics system and the station provider, runs fired on them	Passes, Scheduling
Alarms	Limits and conditions, acknowledgement, shelving, automatic reactions	Alarm Handling
Files and streams	Multi-pass file transfers (chunked or CFDP), uploads, continuous payload streams	File Transfers
Integration	Drivers, transports, gateways, output connectors and pass feeders in Rust, Python or any language	Extending Stellar Control
Simulation	Simulated targets described in YAML, dry runs of procedures without any infrastructure	Simulated Targets

Principles#

Declarative desired state, reconciled continuously. Catalogues, topology, steps and procedures live in a Git repository and are reviewed through merge requests. They compile into a snapshot; a reconciler compares that desired state with the components actually running, binds them together and publishes which targets are ready.

Stateless components, stateful system. Every piece of state lives in Git (desired), in NATS KV (observed) or in JetStream (operational). A restarted component resumes without loss, and adding instances of a component spreads the load.

The language is the contract. The MCS only handles semantic data: telecommands with named arguments, measures, enum values. Binary formats stay inside the drivers, which are plug-and-play processes speaking a NATS contract.

A procedure validated on a flatsat runs as is in orbit. Roles in procedures are bound to concrete targets at launch; environments (SIM, AIT, IVV, in_orbit) carry the policies that differ, such as who confirms a hazardous telecommand.

Errors are found at compile time. Types, units, cross-references, confirmations of hazardous telecommands, maximum durations and environment policies are checked in CI and live in the editor, not during a pass.

Written for operators. The procedure language targets non-developers; diagnostics point at the faulty line in plain words; a language server, a web editor and dry runs are part of the product.

Full traceability. Every message carries the hash of the configuration revision that produced it, every run archives the resolved request it executed, and every step records its evidence.

Main parts#

flowchart LR
    subgraph Git["Configuration repository"]
      cat[Catalogues] --- topo[Topology] --- proc[Procedures]
    end
    Git -- "stellar compile --publish" --> NATS[(NATS + JetStream)]
    subgraph Core["Services of the core"]
      api[API] --- rec[Reconciler] --- exe[Executor]
      comp[Compute] --- alarms[Alarms] --- sched[Scheduler] --- xfer[Transfers]
    end
    Core <--> NATS
    subgraph Edge["Components at the edge"]
      drv[Drivers] --- tr[Transports] --- gw[Gateways] --- conn[Output connectors]
    end
    Edge <--> NATS
    cli[stellar CLI] --> api
    web[Web console] --> api
    gw <--> sat((Target))

Part	What it contains
Services of the core	API, reconciler, executor, compute stage and current value table, alarm service, scheduler, transfer manager; one binary each, or all of them in the `stellar-mcs` binary
Tools	The `stellar` CLI, the web console, the web editor (`stellar-editor`), the language server (`stellar-lsp`) and its VS Code extension
SDKs	A Rust SDK and a Python SDK for drivers, transports, gateways, output connectors and pass feeders
Simulator	`stellar-simulator`, which plays a simulated target from a YAML description as a driver and a gateway
Examples	Drivers, transports, gateways and a TimescaleDB connector built on the SDK, and a complete example configuration repository (`examples/config`)

See Architecture for how the services work together.

Where to start#

Installation: build Stellar Control and start a NATS server, the services and simulated targets.
Your First Procedure: send telecommands, watch values and run a procedure on simulated targets.
Glossary: the vocabulary used throughout this documentation.
Configuration Repository: how to describe your own platforms, targets and procedures.