SignalSpore

SPACE DATA CENTERS
SUPPLIER INTELLIGENCE

SPACE COMPUTINGEvidence. Agreements. Progress.
InsightsLunar computing

INSIGHT 03   /   SPACE COMPUTING

Lunar autonomy creates a market for computing services

Fewer Earth-dependent decisions can free mission time and create opportunities in software, storage and validation.

Conceptual lunar rover with an onboard computing module, Earth in the distance and the SignalSpore mark in the corner.
Concept illustration created for SignalSpore. Not a depiction of Astrolab, HPE or other company hardware.

A lunar computer can earn its place by keeping a mission moving. When a rover can assess terrain, retrieve an operating procedure or identify an abnormal condition locally, it can reduce the number of decisions that must wait for Earth. SignalSpore sees an opportunity for suppliers to sell tested autonomy capabilities, with performance measured in completed tasks and reliable recovery as well as processor throughput.

Put a price on the decision cycle

NASA describes an Earth–Moon one-way light-time of about 1.3 seconds and identifies the growing role of onboard planning and systems management as communications delays increase.[1] This is a propagation baseline. ESA notes that digital signal processing can add further delay.[3] Contact availability, data transfer and human review can extend a real decision cycle further.

The economic question is how many times a task needs that round trip. A workflow that sends observations to Earth, waits for a choice and then repeats the process accumulates delay at each dependent step. Local software could handle intermediate steps within an approved operating boundary and request ground authorization only when needed.

EXHIBIT 1

Fewer serial approvals reduce propagation waiting

Illustrative workflow • 1.3 seconds one way • Same underlying task

Source: SignalSpore calculations using NASA’s approximate 1.3-second one-way light-time [1]. Waiting = serial round trips × 2 × 1.3 seconds. Round-trip counts are assumptions. Excludes computation, transmission duration, routing, queues, human decisions and outages. Local execution time is not modeled. This is not a measured mission result or forecast.

Moving from ten round trips to one removes 23.4 seconds of propagation waiting in this scenario. It does not prove a 23.4-second improvement in total task time: the local system must still perform its work, and some communications can overlap other activities. The best candidates are sequences where the next useful action genuinely depends on the preceding response.

A mission payload can support several supplier roles

HPE’s 20 October announcement provides a concrete example of the proposed workload mix. Spaceborne Computer-4 is planned for Astrolab’s FLIP rover, with tests covering AI, LiDAR processing and high-performance computing benchmarks. HPE identifies KIOXIA SSD storage and a planned Deloitte Silent Shield cyber-analytics workload. These are planned lunar activities, with no completed lunar results or disclosed commercial terms established by the release.[2]

The opportunity extends across the lifecycle of an application. A developer needs representative test data, an execution environment and a way to record what happened when ground support is unavailable. A customer then needs evidence that the application stays within its permitted actions. Each requirement can become a defined deliverable, independently of whether the mission purchases a dedicated computer or shares a host.

EXHIBIT 2

Turn autonomy into a purchasable service

SignalSpore analysis • Potential work packages, not announced awards

Work packageCustomer deliverableAcceptance measure
Task softwareA local workflow with explicit limits and escalation rules.Tasks completed correctly within power and time budgets.
Data persistenceRecoverable state and an event record that can synchronize with Earth.Verified restart and data integrity after an interruption.
ValidationRepresentative scenarios, fault injection and documented operating limits.Repeatable results and appropriate handling of unfamiliar conditions.

Specify the handoff between local and ground control

A useful procurement specification would identify which decisions stay local, which require approval and what happens when a link disappears. It would also define a safe fallback when sensor confidence falls or an application exceeds its resource allocation. Those boundaries let operators retain control while giving software enough discretion to complete useful work.

Benchmark results can help establish a platform’s capabilities. Commercial readiness also requires application-level evidence: completion time, output quality, energy consumed and recovery behaviour under the same test conditions. Disclosing those measures would help customers compare offerings and help suppliers reuse proven work across missions.

For an early service provider, a tightly scoped pilot offers a practical starting point. One repeatable task, an agreed success criterion and a documented ground-control handoff would give both parties something concrete to evaluate. A successful pilot could then support a paid extension to more tasks or a second mission, with less integration work to repeat.

Sources

  1. NASA, Autonomous Systems and Operations project. Earth–Moon light-time and mission autonomy rationale. Accessed 26 October 2026.
  2. HPE, Spaceborne Computer-4 lunar computing plans, 20 October 2026. Company announcement.
  3. ESA, Enabling effective communication for human space exploration beyond Low Earth Orbit. Study conducted 2021–2024. Communication-delay context.
Explore the Spaceborne Computer-4 project