Why Satellites Need Shared Standards (Not Just Good Code)

satellites · standards · ccsds · xtce

Every satellite mission touches at least three organizations that didn't write each other's software: the manufacturer building the spacecraft, the agency or company operating it, and whoever built the ground station talking to it. If each of those groups invents its own way of describing a telemetry packet or a command sequence, every handoff between them becomes a manual, error-prone translation job. That's the actual problem the standards in this space exist to solve — not paperwork for its own sake, but avoiding re-validating everything every time control of a mission changes hands.

CCSDS: the base layer

The Consultative Committee for Space Data Systems (CCSDS) was formed in 1982 by the world's major space agencies specifically to provide a forum for discussing common problems in the development and operation of space data systems. It now runs six technical areas covering system engineering, mission operations, onboard interfaces, space link protocols, and cross-support services, and its standards define the actual telemetry and telecommand links between spacecraft and ground.

CCSDS is why, in principle, two different space agencies can hand a spacecraft off to each other mid-mission without rebuilding the ground segment from scratch.

XTCE: describing what the packets mean

CCSDS defines the link. XTCE (XML Telemetric and Command Exchange), an OMG standard also adopted by CCSDS, defines the meaning of what's flowing across it — telemetry parameters, command structures, calibration rules — as a shared XML information model.

The practical case for it is concrete: a satellite operator switching from one ground system to another can move an existing command-and-telemetry database that follows the XTCE spec straight into the new system, instead of hand-translating it. Without a standard, every organization along a mission's lifecycle has to custom-build ingestion for telemetry and command definitions — which is slow and error-prone, and forces revalidation at every step.

OMG's Space Domain Task Force: SOLM and GEMS

Beyond XTCE, OMG's Space Domain Task Force maintains two narrower standards worth knowing:

• SOLM (Satellite Operation Language Metamodel) — a metamodel for representing spacecraft operations procedures: sequences of spacecraft commands and telemetry checks, plus ground equipment configuration and test execution.
• GEMS (Ground Equipment Monitoring Service) — a lightweight interface model for controlling and monitoring almost any device in a ground system.

Both exist for the same underlying reason as XTCE: so a procedure or a device interface written for one ground system doesn't have to be rewritten from scratch for the next one.

Where cFS and NOS3 fit in

None of the above says anything about how the flight software itself is built — that's where NASA's core Flight System (cFS) comes in, as a reusable flight software framework rather than a data-exchange format. And before flight software like that ever reaches real hardware, it's typically run inside NOS3, NASA IV&V's Docker-based simulation environment, against a virtual spacecraft.

Put together, the stack looks roughly like this: CCSDS moves the bits, XTCE (and SOLM/GEMS) describe what the bits mean, cFS is one common way to write the flight software that produces and consumes them, and NOS3 is where you test all of it before it's real.

Why this matters more as space gets more commercial

Vendor lock-in happens whenever switching away from a supplier carries substantial switching costs — and a proprietary, undocumented telemetry format is exactly that kind of cost. As more of the ground segment gets built by cost-driven commercial players instead of a single government program, standards like these stop being nice-to-have documentation and start being the only thing that keeps missions portable between vendors.