Mission-control software
Sovereign satellite operations software
Overview
Standalone mission-control software for planning, tasking, telemetry and fleet operations, run from your own facilities, by your own operators. The software layer of a sovereign space programme, decoupled from any single satellite vendor.
The software layer of a sovereign space programme: mission control run from your facilities, by your operators, decoupled from any satellite vendor.
Capabilities
- Planning, tasking, telemetry and fleet operations in one suite
- Runs from national facilities under national control
- Independent of any single satellite vendor
- Operator training delivered alongside deployment
- Gives a nation the software layer to fly its own fleet: mission command stays in-country rather than routed through a vendor's operations centre
- Decoupled from any one satellite supplier, so the ground software outlasts individual spacecraft and protects the programme from lock-in
Specifications
| Type | Mission-control software |
| Functions | Planning / tasking / telemetry / fleet ops |
| Hosting | Your facilities, your operators |
| Origin | Independent / non-aligned |
In depth
Put mission command in the software layer
Mission-control software is the operating layer for a sovereign space programme. Its listed functions are planning, tasking, telemetry and fleet operations in one suite. Planning prepares the work the fleet must perform. Tasking sends those instructions. Telemetry gives operators the spacecraft information needed to monitor the mission. Fleet operations bring those functions together when more than one spacecraft is part of the programme. The catalogue specifies that the software runs from the buyer's facilities and under the buyer's operators. It is deliberately independent of any single satellite vendor. That is the central procurement distinction. A spacecraft supplier may change over the life of a programme, while the mission-control layer is intended to outlast individual spacecraft and protect the programme from vendor lock-in. The record does not claim a specific interface standard, hosting architecture or supported spacecraft list.
Operate the fleet from your facilities
National hosting and national operators make the control path explicit. The software gives a nation the layer to fly its own fleet, with mission command staying in-country rather than being routed through a vendor's operations centre. Operator training is listed as being delivered alongside deployment. This connects the software to the space-program-training capability, which develops engineers and operators and describes certified pathways for satellite and ground-segment operators. The ground station is the terrestrial mission backbone for antennas, tasking, telemetry and data reception. Mission-control software is the software layer that uses those operational functions. Observation satellites are one related mission, and communication satellites are another. The software should therefore be configured around the spacecraft, ground segment, operators and fleet tasks the buyer actually has, rather than presented as an abstract application detached from the mission.
Avoid a new lock-in at the control desk
Decoupling from one satellite vendor is useful only if the programme defines what the control layer must connect to and what the buyer will operate. The available facts support one suite for planning, tasking, telemetry and fleet operations, national facilities, national operators and deployment alongside operator training. They do not support a claim that every spacecraft or ground station can connect without integration work. The practical consequence of the vendor-decoupled model is continuity across a growing fleet. Mission command stays in-country instead of being routed through a vendor's operations centre. The software layer is intended to outlast individual spacecraft, so adding or replacing a satellite does not by itself require the whole programme to adopt that supplier's operations environment. That is a statement about the control model, not a promise that integration is automatic. Ground stations still provide the antennas, tasking, telemetry and data-reception functions the software must use. Planning and tasking are separate from telemetry and fleet operations: the suite must present the work to be done, send it, receive spacecraft status and manage the fleet as an operating whole. This separation also gives the buyer a clear boundary for acceptance, because the software functions can be reviewed against the mission-control tasks rather than against a supplier's general product description. The same review should distinguish what is hosted at national facilities from what is supplied by a spacecraft or ground-segment partner. The listed type is mission-control software, with hosting at the buyer's facilities and functions spanning planning, tasking, telemetry and fleet operations. Operator training delivered alongside deployment is part of the published scope, but the training path still has to be agreed with the fleet and its mission interfaces. A procurement review should establish the mission interfaces, hosting location, operator roles, training path, fleet scope and export eligibility. The record identifies the origin as independent and non-aligned and frames the software as the layer that protects a programme from supplier lock-in. It does not publish customer deployments, performance figures or a named software standard. A vendor-decoupled control layer is the supported proposition; the integration boundary must be agreed for each fleet.
Why Unstrat: the difference
Unstrat is the authorised global representative and distributor for this capability. It is already in service with a track record behind it, so you are buying something that has done the job elsewhere, not funding a first attempt. You are not the test bed.
Independent, non-aligned origin, with no political exposure to any major-power ecosystem.
One accountable team from first briefing through delivery and in-region sustainment.
Vendor-decoupled: one control layer across satellites from any supplier.
How it reaches you
Related capability
View all →
Procurement & sustainment
Classification and the end-user-certificate chain are confirmed before this capability is represented to your market.
Sourced from an independent manufacturer: no major-power disclosure rules or political conditions.
A single team responsible from first briefing through delivery: not a chain of foreign primes to integrate yourself.
Lifecycle support and operator training delivered in-region, building capability that outlasts the initial deployment.
Questions buyers ask
What does satellite mission control software do?
It plans and schedules what the spacecraft will do, sends the commands, receives and monitors telemetry, and manages the fleet across passes. Our suite covers planning, tasking, telemetry and fleet operations, and it is operational software used to fly fleets from national facilities rather than from a vendor's operations centre. GomSpace publishes a comparably detailed function list for HOOP, including flight dynamics and event sequencing, and is worth studying alongside ours.
See: Mission-control softwareSide-by-side with GomSpace HOOP
What is the best mission control software for a government satellite fleet?
For a government fleet the deciding factors are usually where it runs, who it is coupled to and who can restrict the next release. HOOP is a documented, deployable system with an on-premise option, flight dynamics and role-based access, and it publishes more architectural detail than we currently do. Ours is sold independently of any satellite vendor, designed to run from your facilities with your operators, and comes from a non-aligned supplier with no member-state export process behind the next update.
On-premise or cloud mission control?
Both work technically, and the choice is usually driven by classification rather than performance. GomSpace publishes an on-premise minimum of 4 virtual CPUs and 16 GB of RAM for HOOP, or cloud deployment on Azure or AWS, which shows how modest the compute requirement is. Our software is built to run from national facilities under national control, which is the posture most defence ministries end up requiring once the data classification is settled.
Mission control software independent of the satellite manufacturer
This is a procurement position more than a feature list. HOOP states it supports any ground station or spacecraft through a generic core with protocol-specific adaptors, which is credible, but it is sold by a company that also builds satellites, so its roadmap follows that bus line. Ours is sold separately from any spacecraft, so replacing a satellite supplier at the next procurement does not force you to replace the console your operators have spent five years learning.
One control room for satellites from different manufacturers
Technically achievable and commercially important. GomSpace states HOOP supports any spacecraft using a generic core with adaptors, and our software is built to fly satellites from any supplier so the ground layer outlasts individual spacecraft. For a fleet assembled over a decade this is the difference between one operations room and three. Test the claim during evaluation with real telemetry from a second vendor rather than accepting it on paper.
See: Independence from the satellite vendorSovereign space solution
What hardware do we need to run mission control ourselves?
Less than most ministries expect. GomSpace publishes an on-premise minimum of 4 virtual CPUs and 16 GB of RAM for HOOP, which is a single modest server. The real requirements are people, procedures and antenna access, which is why we deliver operator training alongside the software. The console is the easy part; the trained shift roster is not.
See: Deployment requirements comparedSpace programme training
Mission control software supplied with operator training
Buying the software without the training is how operations rooms end up staffed by people reading a manual during a pass. Our software is supplied with operator training as part of the deployment, and the same programme covers ground-segment roles so the antenna and the console teams train together. GomSpace states that no satellite operations experience is required for HOOP customers and provides training with it, so the sector broadly agrees on this point.
Running satellite operations from a national operations centre
That is the default our software is designed for: mission command in-country, run by your operators, rather than routed through a vendor's operations centre. NanoAvionics provides operations support from its own satellite operations centre, and HOOP's ground integration is built first around KSAT with other networks listed as coming. Both are rational commercial choices; they also make a foreign network the default path for your contacts.
Our satellites come from three manufacturers. Can one control room fly them all?
Yes, and it is worth insisting on before the fleet grows further. Our control layer is decoupled from any single satellite supplier precisely so the software outlasts individual spacecraft, and GomSpace makes a similar claim for HOOP through its connector layer. The practical test is an evaluation using a real telemetry format from each manufacturer, with your own operators running it, rather than a vendor demonstration on a prepared dataset.
Should we buy control software from the company that builds our satellites?
It is usually faster to integrate, and GomSpace has done real work to support other platforms as well as its own. The cost appears at the second procurement: if the ground software came from your spacecraft supplier, changing supplier means retraining operators, rewriting procedures and revalidating the console. Buying the control layer separately keeps that decision open, which is worth considerably more than it looks on day one.
We have no satellite operations experience. Can our own staff really fly the fleet?
Yes, and the sector has largely stopped pretending otherwise: GomSpace states that no satellite operations experience is required for its HOOP customers. Our software is supplied with operator training and is in service flying national fleets, so the workflow your people learn is the one already running elsewhere. Budget for procedures and a roster as carefully as for the software, because those are what turn a trained individual into an operations capability.
What should we demand from a mission control vendor during evaluation?
Flight dynamics capability, supported ground-station protocols and standards, the security model including authentication and role-based access, the API surface, and the number of missions currently flown with the software. GomSpace answers all of those in a two-page document, including OAuth2, role-based access control, a REST API and three operational LEO missions with five more underway. We do not publish that level of detail today, so require written answers from us rather than a functional description.
What happens to our operations if the software vendor's government restricts exports?
Mission control is not a system you can leave unpatched for a year, so an export interruption is an operational problem rather than a paperwork one. A Danish or Lithuanian supplier sits inside an EU member-state process for every release and every support renewal. Our origin is non-aligned, the software runs in your facilities, and the operators are yours, so a political disagreement does not put your console on hold.
How do we avoid rebuilding the operations room at every procurement?
Treat the ground software as infrastructure with a longer life than the spacecraft, and buy it accordingly. A control layer bought independently of the satellites keeps procedures, training and interfaces stable while the fleet changes underneath, which is the arrangement our software is sold under. Pair it with ground stations you own and the operations room becomes the durable part of the programme rather than the part replaced every time a supplier changes.
Does mission control software depend on which ground network we use?
In practice it often does, and that dependency is worth examining. HOOP publishes built-in KSAT integration for S and X-band with automatic contact booking, with AWS and RBC Signals support stated as coming, so the easy path runs through a commercial network. Our software is designed for the opposite default: national antennas and national operators, with commercial passes used when convenient rather than required. We do not publish our ground-station protocol support, so ask for it in writing.
See: Ground station integration comparedGround segment capability brief
Mission-control software: questions
What is Mission-control software?
Mission-control software is Unstrat's Space (Space Domain) capability: Standalone mission-control software for planning, tasking, telemetry and fleet operations, run from your own facilities, by your own operators. The software layer of a sovereign space programme, decoupled from any single satellite vendor.
How does Mission-control software work?
Mission-control software delivers its effect through Planning, tasking, telemetry and fleet operations in one suite, Runs from national facilities under national control and Independent of any single satellite vendor, capabilities matched to the requirement and confirmed under briefing rather than published.
Who provides Mission-control software?
Mission-control software is delivered by The Satellite Programme Partner, whose focus is satellites & sovereign space programmes. Unstrat represents The Satellite Programme Partner to government and enterprise buyers worldwide as an independent, non-aligned prime vendor.
Why choose Mission-control software over a major-power alternative?
Mission-control software is sourced from an independent, non-aligned provider, so it carries no major-power disclosure rules, upgrade-locks or political ramifications. Concretely: Vendor-decoupled: one control layer across satellites from any supplier. The capability is accountable to you, not to a foreign vendor's government and its release schedule.
How is Mission-control software procured, and where can it be delivered?
The software layer of a sovereign space programme: mission control run from your facilities, by your operators, decoupled from any satellite vendor. Every engagement begins with a briefing, and export eligibility is confirmed per market under briefing rather than published. Where controlled capabilities are involved, the classification and end-user-certificate chain is confirmed first. Mission-control software is then sustained in-region by one accountable team from briefing through long-term operation.