Contact Us

FAQ: In-Orbit Refueling Systems Initiative

Below are the questions we have been asked. If you query is not addressed, please send to: ior.project@reliqai.com

Q1: What kind of details can you share about your new initiative?

A1: This IOR initiative is a systems engineering architecture study focused on in-orbit refueling (IOR). It structures the problem from mission context and operational scenarios through to system architecture.

The objective is to create a common framework that brings together ISAM/RPOD providers, satellite manufacturers, and constellation operators to enable a more standardized refueling ecosystem.

We have developed artifacts covering mission context, stakeholders, operational scenarios, and system boundaries. A short excerpt from the CONOPS section is attached for context.

We also support companies in aligning their systems with the IOR framework through systems engineering, embedded software development, and verification and certification support.

Q2: Have you looked at any existing studies, missions, vehicle architecture, etc to see how it integrates with your proposed framework?

A2: To develop a common framework, we are currently:

  1. Adapting and aligning with guidelines from standards such as CONFERS, IRSIS, and ESA

  2. Supporting SERB-approved physical interfaces (e.g., Northrop Grumman’s PRM and Orbit Fab’s RAFTI)

With the objective of creating a truly common IOR framework, we are defining standardized interfaces for:

  1. Inter-Spacecraft Interfaces

  • Physical (Docking/Transfer) – These are the two SERB-approved physical interfaces.

  • Proximity Operations and Relative Navigation – Defines how two spacecrafts interact across three supported capability levels: IOR Enabled, IOR Aware, and IOR Cooperative. Definitions are provided in Appendix: 1.11.0: Terminology and Definitions.

  1. Inter-Ground System Interfaces

  • Service Provider <-> Client Operator Ground Systems– Defines how the service provider and client operator coordinates planning, authorization, and execution of services.

  • Service Provider <-> Resupply Provider– Supports resupply providers to coordinate and deliver propellant to the service provider in a standardized manner.

  1. Ground Systems to Spacecraft Interfaces

  • Service Provider Ground System <-> Service Vehicle – Supports command, mission planning, and execution of servicing operations.

  • Client Operator Ground System <-> IOR Cooperative Client Spacecraft – Provides telemetry, health monitoring, and coordination support for servicing activities to IOR System

These interfaces are intended to enable companies to develop compliant components and participate in a shared IOR ecosystem.

Q3: Are you looking for inputs to this at a high level?

A3: Yes, we are currently seeking input on:

  1. Nominal and off-nominal CONOPS

  2. System requirements

  3. External interface definitions

  4. Physical architecture and key components

Q4: How does it work exactly? Do you have a team of volunteers working on this initiative and/or do you have companies affiliated with the initiative?

A4: We are a team of systems engineers and MBSE professionals with space/aerospace backgrounds who are contributing on a voluntary basis.

As of early April, we have received engagement interest from six organizations, including both startups and established space companies. These companies include spacecraft manufacturers and on-orbit service providers.

Q5: Satellite and its subsystems’ design are highly proprietary. How is that taken into account?

A5: The initiative provides guidelines for systems providers for implementation to comply with the IOR framework. The implementation work is performed by system owners to align their systems with these guidelines.

The initiative focuses on interoperability covering the following interfaces:

  1. Physical (Docking/Transfer) – These are the two SERB-approved physical interfaces.

  2. Proximity Operations and Relative Navigation – Defines how two spacecrafts interact across three supported capability levels: IOR Enabled, IOR Aware, and IOR Cooperative. Definitions are provided in Appendix: 1.11.0: Terminology and Definitions.

  3. Service Provider to Client Operator Ground Systems Interface – Defines how the service provider and client operator coordinate planning, authorization, and execution of services.

  4. Service Provider Ground Systems to Satellite Interface – Covers command, mission planning, and execution of refueling operations.

  5. Service Provider to Resupply Provider Interface – Enables resupply providers to coordinate and deliver propellant to the service provider in a standardized manner.

Q6: How is the IP managed? Is it shared IP?

A6: Each participating company develops, manages, and retains ownership of its own intellectual property.

This initiative focuses only on defining interfaces between components, ensuring that independently developed solutions can interoperate when they comply with the defined interface standards.

Companies can bring IP which complies with the IOR system and license IP to its customers. For example:

A company may develop a docking and propellant transfer interface device (e.g., a RAFTI-like interface) that is compliant with the IOR Initiative. The company retains ownership of the device design and may license or supply it directly to users.

A LiDAR vendor may provide LiDAR technology compliant with the IOR Initiative and license its implementation directly to customers.

Q7: How do you support participating companies. Do you provide services to support the efforts?

A7: Yes, we support participating companies in aligning their systems with the IOR framework.

This includes systems engineering, embedded software development, and verification and validation support to ensure their components integrate cleanly within the broader architecture.

Where required, we also support traceability and certification readiness so that solutions are not only compliant at the interface level but are also deliverable within real program constraints.