One platform, sixty satellites: configuration management for constellations

A constellation is built on a promise: design the satellite once, then build it many times. In practice, the satellites of a constellation are near-identical, not identical. A supplier changes a component between batch 2 and batch 3. One plane carries a different payload option. A unit that failed acceptance testing is reworked. A few satellites fly with a deviation that was accepted after review.

Each of these differences is small. Together, across dozens of satellites and several years of production, they make a simple question hard to answer: what exactly is on satellite 37?

What ECSS-M-ST-40C asks for

ECSS-M-ST-40C, the ECSS standard for configuration and information management, defines four activities that apply to every space product, whatever the production volume:

• —Configuration identification: defining the configuration items and the documents that describe them, and establishing baselines at agreed points in the programme.
• —Configuration control: managing every change to a baseline through a formal process, including change requests and the handling of deviations and waivers.
• —Configuration status accounting: recording and reporting the current configuration of each item and the status of every change.
• —Configuration verification and audit: checking that the product as built matches its configuration documentation.

For a single satellite, many teams manage this with documents and spreadsheets. For a constellation, the same four activities have to be applied to every unit, and the volume of records grows with every batch.

Why spreadsheets break at fleet scale

The usual approach is to copy. Each satellite gets its own as-built list, derived from the reference design. When the reference changes, someone updates each copy. When one satellite deviates, someone notes it in that satellite's file.

This works for five satellites. At sixty, three problems appear:

• —Copies drift. A change applied to the reference is missed on two satellites. Nobody notices until an audit or an anomaly investigation.
• —Deviations hide. An accepted deviation on one unit is recorded in a document that the next production batch does not read.
• —Impact questions take days. When a shared part has a problem, the team needs to know which satellites carry it, in which revision, and which requirements and tests are affected. With copies, that means opening every file.

A shared platform with per-satellite deltas

The structure that works is inheritance rather than copying. The platform is modelled once: its requirements, its product structure, its interfaces and its verification. Each satellite inherits the platform and records only what differs: a different component revision, a payload option, an accepted deviation, a rework.

In Koddex, variants work this way. A satellite variant inherits the common platform, and its own items and attributes override the shared ones where they differ. The configuration of satellite 37 is then the platform plus its recorded deltas, computed rather than maintained by hand.

Baselines follow the same logic. The programme freezes a baseline of the platform at each review, and each satellite's as-built configuration can be frozen at acceptance. You can compare two baselines side by side: the platform before and after a change, or two satellites from different batches.

What happens when a shared part changes

Suppose a supplier announces a change to a component used on every satellite from batch 2 onwards. The questions are always the same:

1. 1.Which satellites carry this component, and in which revision?
2. 2.Which requirements depend on its properties (mass, power, thermal behaviour, radiation tolerance)?
3. 3.Which tests and analyses verified those requirements, and are they still valid?
4. 4.Which satellites are already built, and which can still take the change?

With a shared model, impact analysis answers these in one view: Koddex follows the links from the component to every satellite variant, requirement, test and baseline that depends on it. The engineering change board sees the full list before it decides, and the decision and its reason are recorded on the items concerned.

Supplier scopes

Constellation programmes rely on many suppliers. Each one needs to see the interfaces and requirements for its own equipment, and nothing else. In Koddex, access rights are set per partner on the same model: a supplier works on its scope, the requirement stays linked to the satellite, and the prime keeps a single source of truth instead of exchanging spreadsheets.

Where AI agents help

Configuration status accounting is largely bookkeeping, which makes it a good fit for agents working as teammates. An engineer can assign tasks such as:

• —"List every satellite that carries revision C of this component and draft the change request."
• —"Check that each accepted deviation on batch 3 is reflected in the as-built configuration."
• —"Compare the as-built baselines of satellites 12 and 37 and summarise the differences."

The agent works on a branch, prepares the result, comments on what it found and hands it back for review. The configuration manager approves or corrects it. Every action is recorded in the activity log.

Getting started

A practical first scope is one platform and two satellites from different batches:

• —Model the platform's product structure and its main requirements.
• —Create the two satellites as variants and record their known differences.
• —Freeze a baseline of each and compare them.
• —Run the impact of one real component change.

If the comparison shows a difference nobody had written down, the model has already paid for itself. Read more about Koddex for space programmes or about running the V-model on the same data.