SMD Rideshare 101

Date: July 30, 2020

Revision: Rideshare 101_v9_Final

National Aeronautics and Space Administration

NASA Headquarters

Science Mission Directorate

Washington, DC 20546

1
 

 

 

 

CONFIGURATION MANAGEMENT

This document is a Science Mission Directorate (SMD) Configuration Management (CM)-controlled

document. Changes to this document require approval of the SMD Rideshare Lead. Changes to this

document will be made by complete revision. Questions or comments concerning this document should

be addressed to:

2
 

 

 

 

 

 

 

 

 

Aly Mendoza-Hill

SMD Rideshare Lead

NASA Headquarters

Washington, DC 20546

VERSION HISTORY

Version Description of Change Rationale for Change Author/POC Effective Date

A Initial Release Bruce Yost

3
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table of Contents

Table of Contents ......................................................................................................................................... 5

I. Purpose and Background ..................................................................................................................... 6

II. Introduction.......................................................................................................................................... 7

III. What is Rideshare?.............................................................................................................................. 7

IV. Advantages of Rideshare .................................................................................................................... 8

V. Rideshare Challenges and Developments............................................................................................ 8

VI. Rideshare Definitions.......................................................................................................................... 8

Primary Payload..................................................................................................................................... 9

Secondary Payload ................................................................................................................................. 9

Tertiary (Auxiliary) Payload............................................................................................................... 10

CubeSat ................................................................................................................................................. 10

Hosted or Piggyback Payload.............................................................................................................. 10

ESPA-Class Spacecraft and Adapters................................................................................................ 11

Table 1: ESPA-Class Spacecraft Adapter/Carrier Options ............................................................. 11

Table 2: MOOG ESPA Configurations.............................................................................................. 12

Propulsive ESPA................................................................................................................................... 12

Figure 1: Example ESPA-Class Spacecraft Adapter/Carrier Options............................................ 13

Figure 2: Graphical Representation of Select Rideshare Definitions.............................................. 14

VII. Science Mission Directorate Rideshare Documents........................................................................ 15

Science Mission Directorate Rideshare Policy................................................................................... 15

Do No Harm.......................................................................................................................................... 15

Rideshare User’s Guide ....................................................................................................................... 15

VIII. References...................................................................................................................................... 16

4
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I. Purpose and Background

Rideshare 101 is intended as an informational source for mission developers and investigators to help

delineate the framework of the NASA SMD’s philosophy and general information that is useful to

manifest and launch small spacecraft on NASA launch vehicles using a method generally termed as

rideshare.

Rideshare indicates that additional and suitable spacecraft can participate on the same launch as another

larger NASA spacecraft on missions that possess similar launch profiles. This opportunity occurs as

occasionally the larger spacecraft, or primary payload, does not require all of the available launch

performance capability of the launch vehicle. This excess performance, or margin, can therefore be used

to carry secondary spacecraft that are compatible with the primary launch/mission profile. This process of

sharing launch opportunities results in lower costs for NASA SMD and an increase in available launch

opportunities. The expected end result is a more efficient use of existing resources to enable increased

opportunities for launch accommodations for Evolved Secondary Payload Adapter (ESPA)-class payloads

that address various science, technology, and exploration goals.

However, in order to allow a number of spacecraft to share a specific launch opportunity, some critical

considerations must be observed to limit any additional risk to the primary mission and the overall launch

campaign. This document describes and references these considerations, and is intended to serve as a

planning resource for mission designers with the desire to use a rideshare arrangement for their

mission.The SMD Rideshare Office (SRO) will serve as the single point of contact in SMD for

coordinating the sharing of launch vehicles between compatible payloads.

This document is not intended to be a requirements document, but rather a general guide for mission

designers and developers to help navigate through the NASA ESPA-class rideshare process. Mission

designers should refer to launch campaign requirements documents and resources for detailed information

related to specific launch opportunities.

This document is developed, maintained, and published by the SRO. It is applicable to any SMD

solicitation that provides or allows for the use of rideshare as a method to access space on SMD-funded

missions. NASA-sponsored missions funded by other mission directorates, such as the Space Technology

Mission Directorate or the Human Exploration and Operations Mission Directorate, may employ different

processes for rideshare accommodations.

This document also does not address CubeSats, also often launched as rideshare payloads. These

spacecraft are mostly addressed and accommodated in NASA’s CubeSat Launch Initiative.1

1 CSLI website, Cubesat 101, (https://www.nasa.gov/directorates/heo/home/CubeSats_initiative)

5
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

II. Introduction

The use of small spacecraft for scientific discovery is rapidly gaining acceptance within NASA and related

science communities. NASA science missions intend to utilize available launch performance margin to

launch and deploy SMD missions.2 NASA SMD regularly funds and sponsors a number of launch

campaigns for a variety of primary spacecraft missions to both Earth orbital and deep space destinations.

These missions may have available launch performance margin, which will be made available to other

NASA-sponsored missions.

Smallsats are central to NASA’s technology development, maturation, and demonstration missions.

Further, in a 2016 National Research Council (NRC) study,3 a strong case was presented for the use of

smallsats to achieve NASA’s science objectives. Currently, there are robust programs in SMD’s Earth

Sciences, Planetary Sciences, Astrophysics, and Heliophysics programs that exploit a number of smallsat

form factors.

III. What is Rideshare?

Spacecraft often share launch services to achieve access to space. This approach has been used to support

spacecraft much smaller than the primary payload. By utilizing launch services in this manner, spacecraft

operators were able to deliver more payloads to orbit for a fraction of the cost when compared to dedicated

launch opportunities.

Rideshare, the method of launching multiple payloads into orbit on a single launch vehicle, has been used

over the past 50 years. While its use has not always been consistent, the number of rideshare missions

launched to orbit has increased, beginning in the 1990s with the development of more standardized

mechanical interfaces for attaching payloads to launch vehicles. This continual improvement in rideshare

capabilities has allowed more organizations to successfully design, produce, and launch payloads to orbit,

increasing the amount of operational capability and scientific knowledge gained from these space-based

payloads. Rideshare opportunities currently exist on NASA, U.S. Space Force (USSF), and commercial

launch vehicles.

2 Thomas Zurbuchen, 2018 Smallsat Conference Keynote Address

3 Thinking Inside the Box, NRC, Zurbuchen, et al. 2017

6
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IV. Advantages of Rideshare

The most obvious advantage of using the rideshare concept for launching payloads to orbit isthe decreased

cost to the mission developer. Instead of procuring a dedicated launch vehicle to launch a single payload,

the mission can acquire the same delivery to orbit by launching as a secondary payload for significantly

lower cost. This cost savings can be applied to the payload, or to other parts of the overall space mission's

architecture.

Another advantage to rideshare is potential access to a larger number of launch opportunities for the

secondary spacecraft. Since many launch campaigns possess excess margin, rideshare opens up a number

of launch options.

V. Rideshare Challenges and Developments

While rideshare launches have successfully supported and enabled low-cost missions, there are some

considerations associated with launching spacecraft together that mission designers should acknowledge.

The original tenet of rideshare was that all “riders” or spacecraft are delivered to approximately the same

orbit. This has restricted launch vehicles from accommodating spacecraft with varying orbital

requirements on the same launch campaign. In addition, a number of vendors are developing and testing

unique upper stage concepts, sometimes called “space tugs,” that can deploy spacecraft at different orbits

from the launch insertion.

Another limitation of rideshare launches is that the secondary spacecraft typically cannot influence the

date and time of the launch. The milestones and schedule for integration and launch are dictated largely

by the primary spacecraft or mission. However, if a rideshare payload includes common and industryestablished interfaces and follows the Do No Harm4 requirements, it may be possible for a secondary

payload to switch to a different launch vehicle and schedule. For instance, the United States Space Force

(USSF)/Department of Defense (DoD) has annual launches to low-Earth orbit (LEO), geostationary

transfer orbit/geosynchronous orbit (GTO/GEO), and medium Earth orbit (MEO). Industry offers annual

flights to LEO and GTO/GEO. However, if the secondary payload does not conform to the interfaces and

Do No Harm requirements, these opportunities become limited and expensive.

4 See the Rideshare Do No Harm Requirements document for more information.

7
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

VI. Rideshare Definitions

There are a number of terms used within the space community to describe elements of the rideshare

opportunity. Not all terms are completely standardized. However, the following terms are generally used

by the smallsat and rideshare communities when discussing these opportunities. Rideshare standard

definitions appear first in order and are followed by definitions from NASA Policy Directive (NPD)

8610.12, Office of Space Operations (OSO) Space Transportation Services for NASA and NASASponsored Payloads, NPD 8610.12 definitions are are designated by a preceeding identifier.

Primary Payload

The primary spacecraft, or payload, is the spacecraft for which the launch service is initially

procured.The primary payload typically dictates launch requirements including launch schedule,

time of launch, orbit inclination and destination, and orbit insertion accuracy.

NPD 8610.12: A payload that justifies its own launch. Specific characteristics: A primary payload

typically defines the orbital placement/trajectory, flight design, critical path of the mission

integration, including launch preparation process, and mission operations.

Secondary Payload

A secondary payload is typically a smallsat that is usually designed to separate after the primary

payload or satellite has been deployed into its orbit or trajectory. There can be a number of

secondary smallsats on any launch campaign.

Often payloads are launched with excess performance capability due to large spacecraft being

volume limited rather than mass limited. To utilize this excess capability, secondary payloads may

be launched along with the primary, providing a means to economically launch small spacecraft.

These are generally independent missions that minimally impact the primary payload.

NPD 8610.12: A payload that is manifested subordinate to a primary payload and, therefore, is

subordinate in launch date and orbit selection. Specific characteristics: A single secondary payload

does not justify a dedicated launch; however, a launch could be justified for the flight of multiple

secondaries. A secondary payload is usually independent of the primary payload, providing its

own power and communication system, but is dependent on a primary payload's launch vehicle to

achieve orbit/desired trajectory. A secondary payload can be manifested on a mission where excess

performance margin allows such an addition. A secondary payload does not drive the launch

mission's orbit selection, flight design, or mission integration critical path without agreement from

the primary payload. The secondary payload does not cause a launch delay without agreement

from the primary payload. Currently, the launch vehicle contractor will create an appropriate

fidelity mass simulator for the secondary payload to meet the schedule needs of the primary

payload should the secondary be unable to support the launch date. There can be more than one

secondary payload on a launch mission. The primary payload's organization typically pays the

majority of, if not the entire, space transportation service costs; however, a secondary payload

provider typically pays for any mission unique integration costs.

8
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tertiary (Auxiliary) Payload

A tertiary payload is a small satellite (e.g., CubeSats, Nanosatellites, Picosatellites) that does not

interfere with the primary payload mission.

NPD 8610.12: A payload that is lower in priority than a secondary (a third-order payload), e.g., a

CubeSat. Specific characteristics: A tertiary payload has all the same characteristics as noted

above for a secondary.

CubeSat

For NASA missions, a CubeSat is a small spacecraft, (usually less than 25 kg mass) that is

compatible with the NASA Launch Services Program, Program Level Dispenser and CubeSat

Requirements Document.5 CubeSats are built in units (U) with a 1U being 10 cm x 10 cm x 10 cm.

CubeSats are typically accommodated in enclosed dispensers which are also used to deploy the

CubeSat. To date, 1U, 3U, 6U and now 12U CubeSats have been launched as payloads.

Hosted or Piggyback Payload

A hosted or piggyback payload is launched as part of a primary payload, and is usually

permanently attached to the host spacecraft (non-deployed). In addition to containing the hosted

or piggyback payload, the host spacecraft typically provides resources such as power, thermal

management, and communications to the hosted or piggyback payload.

NPD 8610.12: A payload comprised of one or more sensors or instruments that is attached and/or

integrated into a host space vehicle for the purpose of obtaining one or more ongoing resources

from the host for the life of the hosted payload. Specific characteristics: A hosted payload's

objective is typically independent of its host's objective, but is dependent on the host space vehicle

for one or more resources (e.g., volume, mass, power, communications). A hosted payload

typically does not drive the launch schedule or orbital placement/trajectory. The host space vehicle

provider or owner is the lead for the space transportation service agreement. Terms are negotiated,

but the hosted payload typically pays for its own integration onto the host space vehicle and/or the

marginal costs of the hosted payload's share of ongoing mission operations (resources used, e.g.,

power, thermal, data processing, and communications).

ESPA-Class Spacecraft and Adapters

Multi-payload missions typically utilize specific adapter hardware systems to safely accommodate

and then deploy rideshare payloads. ESPA-class spacecraft, therefore, are vehicles that are

5 LSP-REQ-317.

9
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

compatible with and able to utilize the suite of ESPA-class hardware. These spacecraft are

typically not containerized like CubeSats.

Table 1 – ESPA-Class Spacecraft Adapter/Carrier Options

Rideshare Carrier Max

S/C

Mass

(kg)

Volume

Available

S/C

interface

Comment

ESPA Ring 220* 24”x28”x38”

24”x28”x56”

8/15” dia S/C mass driven by fastener (1/4 v. 5/16”)

*up to 450kg with Heavy ESPA variant

plus use of larger fasteners and nonheritage load factors

ESPA Grande Ring 465** 42”x46”x38”

42”x46”x56”

15/24”

dia

S/C radial dim driven by fairing diameter

(4m x 5m)

**up to 700kg with larger fatseners & nonheritage load factors

A-Deck `1,000 56” dia x

60” h

24/38”

dia

A dual spacecraft adaptor for taller/larger

S/C

Propulsive ESPA ~180-

450***

4m dia x

24”h

15/24”

dia

4-6 Ports for Rideshare P/L or Hosted P/L

***Total S/C mass dependent on delta-v

required

Propulsive ESPA Grande up to

700***

5m dia x

42”h

24” dia 4-5 Ports for Rideshare P/L or Hosted P/L

***Total S/C mass dependent on delta-v

required

Airbus Multi-Payload

Carrier (MPC) (also

referred to as ASAP-S)

120 26”x31”x

41”

11.7” dia Multiple attach locations for up to 4 S/C

externally with an internal microsat or freeflyer volume. (SSO-A mission)

Airbus Hub ~400 24”x28”x38”

42”x46”x56”

24” dia 6-ports. Composite adapter similar to the

ESPA Grande (SSO-A mission)

ESPA-classsecondary payload adapters may accomodate can-type structures where one satellite is mounted

internal to the structure and the other on top, or they can be frame-type structures where various rideshare

payloads are mounted together on external frames or strongback structures. There are several new

containerized adapters for ESPA-class or other smallsats that allow integration with a ring-type separation

system, but provide a structure holding the satellite inside.

Table 2 – MOOG ESPA Configurations

10
 

 

 

 

 

 

Propulsive ESPA

A number of companies have added satellite functionality including propulsion systems and basic avionics

to ESPA-type structures allowing multi-orbit insertions and in some cases extended on-orbit operations to

support multi-missions. These upper stages, or “space tugs” can carry multiple satellites, burn to different

orbits, and drop off satellites in separate locations. This capability enables a wide variety of spacecraft to

be manifested on a single launch.

11
 

Airbus MPC (SSO-A)

 

 

Airbus Hub (SSO-A)

SpaceX

Dispenser Ring

Figure 1 – Example ESPA-Class Spacecraft Adapter/Carrier Options

12
Figure 2 – Graphical Representation of Select Rideshare Definitions

13
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

VII. Science Mission Directorate Rideshare Documents

The following describes some of the relevant documents and resources pertaining to the rideshare process

for NASA science missions.

Science Mission Directorate Rideshare Policy

The SMD Rideshare Policy, NASA-SPD-32: Evolved Expendable Launch Vehicle (EELV)

Secondary Payload Adapter (ESPA) Secondary Payloads Rideshare defines the process for

identifying and prioritizing secondary spacecraft on SMD-procured launch vehicles. It also

specifies roles and responsibilities for implementing the SMD Rideshare Policy.

Do No Harm Requirements

As rideshare missions become more accessible and accepted in today’s space and science industry,

there is an increased need to mitigate risks from the rideshare spacecraft (secondary payload) to

the primary mission and all other payloads on the mission. NASA SMD has developed its

Rideshare Mission Assurance (RMA) process with the objective to provide all mission partners

with a degree of certainty that all payloads included on a mission will do no harm (DNH) to each

other, or to any operational aspect of the launch.

The RMA process mitigates risks by assessing each payload on a mission against a tailored set of

criteria, known as Do No Harm (DNH) requirements. The primary concerns of the RMA process

are to ensure that the payloads are robust enough to survive the launch environment; will not

inadvertently power on, and will not perform functions that could be harmful to personnel or the

mission. The DNH assessment also includes a review of any co-use of facilities during the launch

campaign as well as a review of the critical function inhibit scheme utilized by the payload. The

focus of this process is to ensure safety of flight for all mission partners. It is not to ensure mission

success for individual secondary spacecraft. It is the responsibility of these spacecraft/missions to

ensure their own mission success.

A NASA SMD DNH Requirements document was developed incorporating key elements of the

DoD RMA process for the intended use in a mission’s concept development phase leading up to

vehicle procurement and final manifesting. Once the Launch Vehicle Contractor (LVC) is on

contract, this process is formalized and a detailed mission specific set of DNH criteria will be

developed and validated as part of the overall mission integration cycle.

Rideshare User’s Guide

The NASA SMD Rideshare User’s Guide (RUG) provides a step-by-step process to develop a

rideshare concept and to generically formulate/implement a rideshare mission. The RUG includes

details to explore and select a rideshare option, including NASA, DoD, and commercial rideshare

opportunities. The RUG provides generic guidelines and information for preliminary spacecraft

design, launch vehicle integration, and mission planning for rideshare payloads. The NASA RUG

focuses on payloads that integrate to the ESPA-type ring, including: 1) CubeSats (when their

deployer integrates to an ESPA port); 2) ESPA-class payloads; 3) ESPA Grande payloads; 4)

14
 

 

 

 

 

 

 

 

 

 

 

 

 

 

propulsive ESPA-class payloads; 5) propulsive ESPA Grande payloads; 6) and A-Deck payloads

(payloads that mount inside the ESPA ring). The NASA RUG is modeled after the DoD RUG

allowing NASA payloads that implement the NASA RUG to be compatible with primary DoD

missions and DoD Payloads that implement the DoD RUG, to be compatible with primary NASA

missions.

VIII. References

1. Orbital Space Transportation Services (NPD 8610.12H, 9/23/15)

2. NASA SMD Do No Harm Requirements Document (TBD)

3. NASA SMD Rideshare User’s Guide (TBD)

4. SMD Rideshare Policy (SPD-32) NASA-SPD-32: Evolved Expendable Launch Vehicle (EELV)

Secondary Payload Adapter (ESPA) Secondary Payloads Rideshare

5. Launch Services Program, Program Level and Dispenser and CubeSat Requirements Document

(LSP-REQ-317, 1/30/14)

For more information, please go to www.nasa.gov/smallsat-institute or contact HQ-SMDRideshare@mail.nasa.gov.

15