Mission control · Test automation · EGSE

From the test bench to orbit, with the same procedures.

Stellar Control 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.

Try it now Bring your ICD
Hot standby test · flatsat-1 run 01JB7Q…K2
SIM AIT IVV IN ORBIT
10:42:07.114 send adcs[RW1].set_mode DETUMBLING ENCODED · SENT · ECHO
10:42:08.302 expect adcs[RW1].mode is DETUMBLING ✓ 1.19 s
10:42:08.310 send psu.set_voltage 28 V VERIFIED
10:42:11.020 check adcs[RW1].anode_voltage 250.0 V · soft 5–280 V
10:42:11.021 ask operator: start blank firing? confirmed by operator
10:42:14.487 step "ADCS in mode" passed · evidence recorded
Anode voltage 250.0 V
Cathode temp. 812.3 °C
COP-1 · V(S) 41
Who it is for

Built for the people who build space systems

Test labs and bench operators

Automate acceptance tests, keep a traceable record of every run, and stop maintaining fragile scripts bench by bench.

NewSpace integrators

AIT, IVV and flight operations on one platform: the procedure validated on the flatsat is the procedure flown.

Subsystem manufacturers

Ship your thruster, on-board computer or power unit with its catalogue, driver and test procedures, ready for your customers' ground segment.

Payload and ground teams

Add a ground station, a radio or a bench without touching the core of the system.

One system, four environments

Simulate, integrate, qualify, fly

The same catalogues and procedures run on a simulated target, a flatsat, a qualification model and the flight model. Only the topology changes, and each environment enforces its own rules.

SIM

Simulation

Drafts allowed, no confirmations. Deterministic simulated targets with injectable faults, link losses and fictitious passes.

AIT

Integration

Fast iteration on the bench: CAN buses, RF benches, power supplies and instruments, driven from one place.

IVV

Qualification

Declared identities, operator confirmation of hazardous commands, released configurations only.

IN ORBIT

Operations

Authenticated users, operator then supervisor confirmation, and a validated plan before any hazardous command.

Configuration as code

A GitOps workflow for mission control

Everything that describes your mission lives in a Git repository: catalogues of measures and telecommands with units, calibrations, limits and alarms; topologies of targets, links and gateways; steps and procedures; simulations. Changes follow the workflow your software teams already use.

  1. Branch

    Edit in the web editor or in VS Code, with completion and live diagnostics.

  2. Review

    The editor opens a merge request. Your team reviews the change like any other code.

  3. Check

    Continuous integration compiles everything: units, types, references and safety rules, against locked package versions.

  4. Publish

    The compiled configuration is stored as an immutable, content-addressed snapshot.

  5. Apply

    Running systems switch to it at a safe point. You always know which version was active, and when.

# A reusable step: its action and its success criterion
step "OBC1 answers" retry 3 times every 2 s
  uses sat: platform-v3
  input obc: obc1
  send ping to sat.obc[obc] via rf_leafspace
  expect sat.obc[obc].responding is true within 5 s

Safety built into the language

  • Hazardous commands need an explicit operator confirmation, checked when the procedure is compiled.
  • Every step has a timeout and a success criterion; the maximum duration of a procedure is known before it starts.
  • No loops, no recursion. Retries are derived and shown to the author.
  • Every telecommand verifies its effect : on-board echo, expected values, time windows.
  • Targets are leased : two procedures never drive the same equipment at once.
Operators and developers

One platform, two crafts

For operators

  • Live telemetry Current values with their freshness, source link, and real-time or recorded origin.
  • Procedures Run, suspend, resume or abort from the web interface, the command line or a schedule.
  • Alarms Soft and hard limits, named conditions, acknowledgement and shelving, and reactions that suspend the run in progress.
  • Passes Passes imported from flight dynamics or your station provider, runs started at AOS, a warning when a run no longer fits.
  • Files Resumable transfers over several passes, CCSDS CFDP, and recorded telemetry (LTTM) decoded at its on-board time.
  • Evidence Step-by-step evidence and AIT / IVV reports, with the configuration version and the active faults.

For developers

  • Editors A web editor and a VS Code extension backed by a language server.
  • Command line stellar checks, compiles, sends, watches and runs procedures, including dry runs on your laptop.
  • Simulator A simulated target for every platform: models, echoes, noise, passes, losses, on-board files and faults, deterministic with a seed.
  • Test vectors Every driver is replayed bit for bit against its ICD in continuous integration.
  • Open APIs HTTP and WebSocket APIs, and output connectors to your time-series database and Grafana.
  • Replayable archives Raw frames kept as received, with the version of the driver that decoded them.
SDKs

Connect any equipment

Drivers, transports, gateways and connectors are independent components built with the SDKs. They register themselves; the core binds them to your targets, checks that they fit, and grants each one only the rights it needs.

Driver

Speaks your ICD

Semantic telecommands and measures to bytes and back: PUS, CSP, SCPI, CAN and your own formats.

Transport

Frames for the medium

CCSDS TC/TM frames with COP-1, CSP over CAN or KISS. Parameters come from the topology, per environment.

Gateway

Reaches the hardware

Ground stations, RF benches, CAN buses, Ethernet instruments, serial lines.

Connector

Feeds your systems

Telemetry, events, alarms and files exported to your data platforms.

AIT   obc-csp → csp1-can → bench CAN bus   |   IN ORBIT   obc-csp → csp1-kiss → UHF station   ·  same driver, only the topology changes
Rust Live
Python Live
Java Planned
TypeScript Planned

The SDKs take care of registration, health, credentials, metrics, COP-1 and CFDP; your code describes your equipment. Behind them sits a documented, language-neutral contract, so any language can join.

The core in the cloud or a data centre, connected to an integration hall, a ground station, a partner site and operators SCS core cloud or data centre Integration hall bench gateways · CAN · RF Ground station S-band · UHF gateways Partner site subsystem driver Operators web · CLI · VS Code
Distributed by design

Deploy across sites

Components do not need to live together. Put the core in your data centre or in the cloud, the bench gateway next to the hardware, the station gateway at the antenna, and a manufacturer's driver on the partner's premises.

Each site connects securely to the system. Commands and telemetry go through a persistent, event-driven backbone: they are stored and delivered, never silently dropped. The system continuously binds every link to healthy components, tells you why a target is not ready, and fails over on its own.

The core infrastructure

DevOps-ready, secure by default

Operations

  • Infrastructure as code : orchestrator jobs and deployment scripts; secrets live in the orchestrator, never in the repository.
  • Observability : structured logs and Prometheus metrics for every service and component, including throughput and COP-1 counters.
  • Scales both ways : a single binary for demonstrations, integration tests and development; horizontally scaled services for operations.

Security

  • Encrypted everywhere : TLS between all components, mutual TLS for equipment, HTTPS and secure WebSocket for users.
  • Encrypted at rest , with key rotation without downtime.
  • Least privilege : short-lived credentials per component; a driver only reaches the targets it is bound to.
  • Single sign-on for users, with every confirmation traced to a person.

Isolation

  • Cells : fully isolated instances per customer, programme or team on shared infrastructure.
  • Quotas per cell : one programme's archives never starve another's.
  • On demand : create a cell, put it to sleep between campaigns, wake it when the bench is back.
Deployment options

Where you need it

On-premise

In your integration facility or your mission operations centre, on your own infrastructure.

Hosted cells

Ready-to-use, isolated instances for evaluation, integration campaigns and development environments.

Hybrid

A hosted core, with your benches and ground stations connected from your own sites.

Get started

Bring your ICD. Run your first procedure.

Stellar Systems helps you from the interface document to the first run on your bench.

Or start now with the online trial: an environment of your own for your use case, every target simulated, procedures ready to run in the web console. Nothing to install, free for a week.

Try it now Read the docs
  1. Write the catalogue of your platform or subsystem.
  2. Build its driver with the SDK, checked against test vectors.
  3. Run your first procedure on a simulated target.
  4. Connect your bench and run it for real.
Use cases

From the supplier's ICD to the test chamber

Each use case is a complete configuration, simulated equipment included: explore it in your browser, or run it in an environment of your own.

Subsystem integrator

Payload integration

From the supplier's ICD to a driver and a simulation, before the hardware arrives.

See the use case → System engineer / AIT manager at a CubeSat startup

Satellite integration

One topology, the same procedures in simulation, on the flatsat and on the flight model.

See the use case → Test engineer / test facilities manager

Test bench automation

Environmental test facilities that run unattended, and stop safely when they must.

See the use case →

All use cases →