The photonic OTV

A space tug built like software.

SpaceNoneSuch builds on decades of aerospace experience and starts from the software. The tug is a software-defined robot with a light-based nervous system. It can act on its own far from Earth, learn in simulation before it flies, and keep improving after launch.

Two ways to build a spacecraft

Both work. The hardware-first approach has flown for decades. The software-first approach adds autonomy for jobs where waiting for the ground is too slow.

Role of software

Hardware-first:Software built around carefully qualified hardware, an approach with decades of success.

SpNH:Software leads the design. The vehicle is a software-defined robot that decides for itself on orbit.

How it is built

Hardware-first:A stable design, fully qualified before flight.

SpNH:Small changes made often, each one re-checked automatically.

How it is tested

Hardware-first:Thorough physical test campaigns on dedicated hardware.

SpNH:Thousands of simulated flights per change, then hardware in the loop, then physical tests and flight.

Data backbone

Hardware-first:Proven, highly reliable buses such as MIL-STD-1553.

SpNH:Time-triggered Ethernet to the edge, carried on light. Every sensor and valve has an address.

Reuse

Hardware-first:Conservative, scheduled maintenance intervals.

SpNH:Software tracks each part's measured structural margin to support safe, rapid reuse.

Autonomy

Hardware-first:Operators on the ground direct key steps in real time.

SpNH:The tug plans and acts on its own when ground signals would arrive too late, with people approving the critical steps.

Six software edges

Pick one to see what it does, what is already proven, and the honest limit.

Continuous integration and digital twins

One digital twin of the whole vehicle, with end-to-end simulation. Every mechanical change automatically re-runs thousands of simulated orbital trajectories before anyone cuts metal. Risk moves upstream, into code, where it is cheap to fix.

Proven today. Digital twins and simulation-in-CI are used across modern aerospace and automotive.

Honest limit. A twin is only as good as its models. It has to be checked against real test data, not trusted on its own.

What it is for

Services, not weapons

  • Last-mile delivery and precise orbit insertion
  • Refueling and life extension
  • Inspection and repair
  • Module swaps with a servicing arm
  • Debris removal and end-of-life deorbit

Every close approach follows published on-orbit servicing safety norms, with a person approving the final approach.

Updates in days, not years

Every update signed, tested and reversible

  • Signed. The vehicle only loads code that carries a valid signature.

  • Staged. Simulator first, then the hardware bench, then a backup computer in orbit.

  • Reversible. If an update misbehaves, the vehicle returns to the last good version.

  • Hardware safe mode. A safety layer that software cannot override guards every close approach.

How we get there

  1. 1Prove the photonic sensing kit on the bench, in liquid nitrogen.
  2. 2Fly the kit as a hosted payload on a tug we rent.
  3. 3License the software to tug operators.
  4. 4Build our own tug on the same nervous system.

This page describes direction, not a flying vehicle. Proven-today notes refer to the wider industry.

See the communications platform