Satellite
Deliver the energy an orbiting satellite needs, when it needs it—expanding service life, capability, and operational freedom.
Space Energy
Energy for satellites, spacecraft, and future bases. We are defining how to generate, store, and deliver power in space.
Intended uses
By building the interfaces and evidence each satellite, spacecraft, and base requires, we aim to make energy shared infrastructure for space.
Deliver the energy an orbiting satellite needs, when it needs it—expanding service life, capability, and operational freedom.
Energy systems that support spacecraft navigation, habitation, communications, and life support.
Generation, storage, and management for sustained operation of crewed and uncrewed stations.
Local energy infrastructure for bases, hotels, research, industry, and mobility.
One connected system
We are considering generation, power use, and monitoring as one connected system. The methods and interfaces remain undecided.
Generation method: OPEN
Storage / thermal control: OPEN
Delivery interface: OPEN
Monitoring / allocation: OPEN
Proposed sequence · Not formally adopted
Everything below except the Ground Digital Model in the formal plan is a sequence for future consideration.※1
First define generation, storage, power delivery, thermal behavior, and communications using numerical models and synthetic data.
A candidate internal ground demonstration that avoids hazardous high-pressure and combustion work while establishing measurement and failure conditions.
A candidate pilot that delivers energy to a Copernicus-owned receiver and verifies its use. Platform, interface, and timing remain OPEN.
After internal demonstration, consider a pilot with an independent external customer, including a contract, price, and acceptance conditions.
Offer a service only where the technology, demand, safety, legal framework, responsibility, and insurance have all been established.
Proposed orbital pilot
The proposal would use a separate Copernicus-owned receiver to check that power is received and used, and compare records from both ends. Delivery method, output, interface, and timing remain undecided.※2
AI and human responsibility
Supports requirements, model creation, potential abnormal conditions, documentation, and review preparation.
The design direction is for Safety AI to issue a STOP only within predefined, approved conditions. This is not implemented. Only the accountable human authority may decide GO, release a STOP, restart, or accept risk.
GO, HOLD, STOP, release of STOP, risk acceptance, crewed GO, legal, quality, and contracts are decided by accountable human authorities.