0. Boundaries and Interfaces

The System of Interest (SoI) is the In-Orbit Refueling (IOR) System, composed of:

1. Ground Segment (GS)
2. Orbital Depot
3. Service Vehicle (SV)
4. Resupply Vehicle (RV) [when defined]

External actors include:

1. Client Operator Ground System (CO)
2. IOR Operator (IORO)
3. Client Spacecraft (CS)
4. Conjunction Service Provider
5. Space Tracking Data Provider – provides orbital data (e.g., TLE/ephemeris) for space objects
6. Space Environment / Debris (non-cooperative)

The Functional System Boundary is illustrated in Figure 1:IOR: External and Internal Interfaces. Interfaces in this section are organized as:

• External interfaces: SoI ↔ external actors
• Internal interfaces: interfaces between GS, Depot, SV, and RV within the SoI.

Standard External IOR Interfaces

With the objective of creating a truly common IOR framework, this initiative defines standardized interfaces for:

1. Inter-Spacecraft 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.
2. Inter-Ground System Interfaces
   1. IOR Service Provider <-> Client Operator Ground Systems– Defines how the service provider and client operator coordinates planning, authorization, and execution of services.
   2. IOR Service Provider <-> Resupply Provider– Supports resupply providers to coordinate and deliver propellant to the service provider in a standardized manner.
3. Ground Systems to Spacecraft Interfaces
   1. IOR Service Provider Ground System <-> Service Vehicle/Depot – Supports command, mission planning, and execution of servicing operations.
   2. 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.

Inter-Spacecraft Interfaces

Physical (Docking/Transfer)

These are Physical Interfaces between SV, Depot, Client Craft and Resupply Vehicle.

Space System Command’s System Engineering Review Board (SERB) has two approved standard interfaces for satellite refueling –

1. Northrop Grumman’s Passive Refueling Module (PRM) and
2. Orbit Fab’s Rapidly Attachable Fluid Transfer Interface (RAFTI).

Industry solutions for refueling of National Security Space assets equipped with these SERB-approved interfaces are sought to meet sustained space maneuver (SSM) needs by 2030

Timely: SAM.gov (RFI)

Proximity Operations and Relative Navigation

This section discusses the interface between an IOR Capable chaser and different levels of capability of the target. Definitions of these capability levels are give here.

Client Spacecraft are standardized to enable fuel service delivery. Client Spacecraft can have any one of the four capability levels. Client Spacecraft MUST meet all requirements to qualify for compliance within a capability level. Each proceeding level has all capabilities of the previous level.

IOR Capable Chaser (ICAC)/SV ↔︎ IOR Enabled Target (IET) IOR

There is no communication between the chaser with IOR Enabled chaser.

Physical interface as defined in section Physical Interfaces.

(TBD: Study the 2 Physical Interfaces)

IOR Capable Chaser (ICAC)/SV ↔︎ IOR Aware Target (IAT)

There is no communication between the chaser with IOR Aware chaser. IOR Aware senses progress and sends the status to the Client Ground Segment.

(more work is required on IOR Aware)

IOR Capable Chaser (ICAC)/SV ↔︎ IOR Cooperative Target (ICOT)

This section provides interface between IOR Cooperative target (ICOT) and IOR Capable chaser (ICAC). The chaser drives the RPOD process with target assisting chaser with status responses and executing commands. ICOT retails safety authority and may reject commands from ICOT if it unable or it is not safe to perform.

Chaser Spacecraft <->Target Spacecraft Communication

Chaser and Target spacecrafts communicate over RF using CCSDS’ Space Packet Protocol.

The ICAC when enters the REP and tries to achieves initial acquisition of the target. Simultaneously the Chaser and Target spacecrafts try to establish an RF link. Once the RF link is established communications as outlined in table below commences:

IOR Capable Chaser (ICAC) ↔︎ IOR Capable Target (ICAT)

Two IOR Capable spacecrafts provide is full two way cooperative RPOD, transfer and return.

The Depot, Service Vehicle (SV), Resupply Vehicle (RV) and the IOR Capable Client Spacecraft (CS) have same capabilities enabling two-way cooperative Proximity Operations. These capabilities are independently verified to be labeled as compliant with this IOR initiative. Details of these capabilities are documented here.

Following is complete pairing of IOR Capable Chaser and IOR Capable Target spacecrafts:

• Chaser: Service Vehicle (SV) Target: Depot | IOR Capable Client Spacecraft
• Chaser: Resupply Vehicle (RV) Target: Depot

Below is Fuel Transfer Supply Relationship:

• Service Vehicle (SV) -> Client Spacecraft
• Resupply Vehicle (RV) ->Depot

Depot may supply to SV but it not as a part of any mission.

IOR Capable Chaser (ICAC) and IOR Capable Target (ICAT) use the same messages as IOR Capable Chaser (ICAC) and IOR Cooperative Target (ICAT) as shown in the previous section.

Depot ↔︎ Service Vehicle (SV)

Depot and Service Vehicle communicates in two states:

Depot↔︎SV: Nominal State Communication

Nominal state is when SV is docked to the Depot. SV and Depot communicate through a physical connector.

Depot↔︎SV: Proximity Operations

Proximity Operations occurs when SV approaches Depot on return from a fuel delivery service mission. These proximity operation steps between Depot and SV are similar to the proximity operation steps between the SV and IOR Cooperative CS since Depot capabilities match that of an IOR Cooperative Spacecraft. The differences are:

1. The fuel is transferred from Depot to the SV
2. The SV does not undock and retreat after docking is complete. SV on Docking to Depot reaches a nominal stage and stays until the next service mission.

Depot and Service Vehicle both must be IOR cooperative capable crafts hence must have all capabilities documented here. The Depot and Service follow the process as outlined here.

Resupply Vehicle <-> Depot

Depot and Resupply Vehicle both must have IOR capable level capability hence must have all capabilities documented here. The Resupply Vehicle and Depot follow the process as outlined here.

Inter-Ground System Interfaces

IOR Service Provider (ISP) <-> Client Operator (CO) Ground Segments

Service Request

Refuel Service Related

IOR Service Provider (ISP) <-> Resupply Service Provider (RSP) Ground Systems

To be added.

Ground Systems to Spacecraft Interfaces

IOR Service Provider (ISP) Ground Segment ↔︎ Depot

ISP GS↔︎ Depot: Nominal

ISP GS↔︎ Depot: Refuel Service

IOR Service Provider (ISP) Ground Segment (GS) ↔︎ Service Vehicle (SV)

ISP Ground Segment and Service Vehicle communicate only when SV is undocked. In docking state GS gets all SV info from the depot.

Other External Interfaces

These external interfaces are not standardized under this initiative:

IOR Service Provider (ISP) Ground Segment <-> IOR Operator (IORO)

Admin

Manage Clients – Create, Update and Delete

Operations

Operate Service Mission – Authorize, Go No/Go

Service Mission Monitor

Monitor Service Mission is a browser based dashboard and graphical interface interface to enable the IOR Operator monitor mission and critical data about the mission. The IOR Operator can monitor several missions at the same time.

Conjunction Service Provider <-> Ground Segment

TBD

Exchange Message Structures

Used in several communication – between spacecrafts, spacecraft to ground systems.

Spacecraft Classification

Spacecraft Classification originates at any IOR Capable and IOR Cooperative spacecrafts. This message is exchanged as below:

1. IOR Capable Spacecraft <→ IOR Cooperative Spacecraft
2. IOR Capable Spacecraft <-> IOR Capable Spacecraft

Spacecraft classification provides spacecraft classification fields to represent the sending spacecraft. Not all fields are useful in all spacecraft to spacecraft interactions.

SpacecraftClassifiction {
  Mode: {SERVICE_VEHICLE, DEPOT, CLIENT_SPACECRAFT}
  CapbilityLevel {IOR_ENABLED, IOR_AWARE, IOR_COO[ERATIVE, IOR_CAPABLE} // Valid when Mode =CLIENT_SPACECRAFT
  ComplianceVersion: String
  InterfaceType interfaceType
  PropellantType propellantType
}

Spacecraft State

Spacecraft State message originates at any IOR Capable and IOR Cooperative spacecrafts. This message is exchanged as below:

1. IOR Capable Spacecraft <→ IOR Cooperative Spacecraft
2. IOR Capable Spacecraft <→ IOR Capable Spacecraft

Spacecraft State provides following state fields representing the state of the sending spacecraft.

SpacecraftState {
  ThermalInfo thermalInfo;
  PropellantInfo propellantInfo;
}

ThermalInfo {
  ThermalNominal boolean;
  Bus_K   double;
  Propulsion_K double;
}

PropellantInfo {
     PropellantType { HYRAZINE | BIPROPELLANTS | XENON | CRYOGENIC }
     PropellantQuanity_Gms double; // mass in grams 
     Pressure_bar double; // in bar
     Temprature_K temp; // in Kelvin
}

RPOD State

RPOD state originates at any IOR Capable spacecraft. This message is exchanged as below:

1. IOR Capable spacecraft → Ground Segment
2. IOR Capable Spacecraft → IOR Cooperative Spacecraft
3. IOR Capable Spacecraft ↔︎ IOR Capable Spacecraft

RPODState {
  RPODControlMode: {GS_CONTROLLED | FULL_AUTONOMOUS | AUTONOMOUS_WITH_GS_AUTH}
          //ControlMode does not generally change, but can change in case chaser looser ground connection
  
  RPODStatus: {ORBIT_TRANSFER | RENDEZVOUS_ENTRY_POINT_REACHED | FAR_RENDEZVOUS | CLOSE_RENDEZVOUS | PROXIMITY_OPERATIONS | RETURN}  NOMINAL_MODE = SV back with Depot
  
  // ProximityOperationStatus is used with RPODStatus ==  PROXIMITY_OPERATIONS            
  ProximityOperationStatus (POS): {APPROACH | ENTER_HOLD | VERIFY_HOLD | WAIT_FOR_STABILIZATION | RETREAT | PROXIMITY_OPER_ABORT | NOMINAL}

  //ProximityState is used with ProximityOperationStatus == NOMINAL
  ProximityState (PRS): { APPROACH | ALIGNEMENT | DOCK | FUEL_TRANSFER | UNDOCK | RETURN | MISSION_ABORT }
}

Spacecraft Relative Nav Info

Spacecraft Relative Navigation Info originates at any IOR Capable spacecraft during RPOD operations. This message is exchanged as below:

1. IOR Capable Spacecraft → IOR Cooperative Spacecraft
2. IOR Capable Spacecraft <→ IOR Capable Spacecraft

SpacecraftRelativeNavInfo {
  Ephemeris:  {x, y, z, Vx, Vy, Vz}
  Attitude { pitchAngle, yawAngle, rollAngle }
  InView: Yes | No  // Relaative 
  RelativeCooridates { x, y, z }  // meters in ECI framework
  RelativeVelocity {Vx, Vy, Vz} // m/s ECI framework
}

Spacecraft Return Plan

Spacecraft Return Plan is sent by IOR Service Provider GS to SV to enable SV to return to REP to enable RPOD operations with the Depot

This message is exchanged as below:

1. IOR Service Provider Ground Station → SV

SpacecraftReturnPlans {
  ReturnTrajectory returnTrajectory; // gets the SV to REP 
  ContactPlan contactPlan // Contact Plan for SV to use to communicate with IOR Service Provider GS
  DepotEphemeris Ephemeris;
}

Referenced by AbortRefuelService (GS→SV) and by RefuelServicePlans to ensure consistent abort behavior

IOR Refuel Service Plan

IOR Service Provider GS sends the Refuel Service Plan to provide all the necessary details to the SV/Depot to carry out a refuel service request. The IOR Service GS continues to support the SV through the delivery process.

This message is exchanged as below:

1. IOR Service Provider Ground Station → SV

IORRefuelServicePlan {
  RPODToClientSpacecraftPlan rpodPlan;
  ContactPlan contactPlan;
  RefuelServiceRequest refuelServiceRequest;
}

Abort Command

Abort Command can can be initiated by any authorized entity:

1. IOR Capable Spacecraft
2. IOR Cooperative Spacecraft
3. IOR Service Supplier Ground Segment
4. Client Operator Ground Segment

AbortType {
    ABORT_TYPE_PROXIMITY_OPS,
    ABORT_TYPE_DOCKING,
    ABORT_TYPE_TRANSFER,
    ABORT_TYPE_MISSION
  }

AbortSource {
  CHASER, 
  TARGET, 
  SERVICE_PROVIDER_GS, 
  CLIENT_OPERATOR_GS
  }

AbortReason {
    ABORT_REASON_PIP_FAILED,
    ABORT_REASON_NAV_FAILURE,
    ABORT_REASON_SAFETY_VIOLATION,
    ABORT_REASON_COMMS_LOSS,
    ABORT_REASON_SYSTEM_FAULT
  } 
  
AbortCommand {
  AbortID int; 
  AbortSource {CHASER, TARGET, SERVICE_PROVIDER_GS, CLIENT_OPERATOR_GS}
  AbortType abortType;
  AbortReason abortReason;
  AbortTime time;
  NextStage  {RESUME, RETURN, WAIT_FOR_NEXT_STAGE};
}

Data Structures

These data structures are used by

RPOD to Client Spacecraft Plan

RPODToClientSpacecraftPlan {
  TransferAndOrbitPhasing orbitPhasing; // Tracjectory for Orbit Phasiing
  RendezvousEntryPoint {x, y, z} // in kms ECI
  RendezvousSphere {Cx, Cy,Cz, Radius} // in Kms ECI
  HoldPoints holdPoint[N]; // {x, y, z} // in kms ECI
  ApproachSphere {Cx, Cy,Cz, Radius} // in Kms ECI
  KeepOutSphere {Cx, Cy, Cz, Radius} // in Kms ECI
  ACSphere {Cx, Cy, Cz, Radius} // Approach Corridor Sphere, Radius in m, ECI
  ApproachCorridor {Rbar, VBar, Length,  ACSphere}
}

Contact Window

Contact Window is the time window when two entities can contact each other

ContactWindow {
   ContactType {RF_LSL, RF_HSL} // Low speed, High speed links
   StartTime time;
   EndTime time;
   Entity entityDst;
   RequiresPointing boolean;
   PointingDirection {x, y, z};
}

Contact Plan

Contact Plan Windows SV/Depot to communicate through during service delivery

ContactPlan {
      Entity entitySrc;  // Who is the contact plan for
      ContactWindow contactWindow[ContactPeriod]
}

Refuel Service Request

Refuel Service Request is what was received from the client either manually or from the Client Operator Ground Segment.

RefuelServiceRequest {
  Client Spacecraft ID
  ClientType
  Propellant type
  Requested volume
  Client spacecraft ephemeris data
  Abort/Return Plan Reference
  SV Abort/Return Plan
}