Low SWaP SDA Hosted Payload Data Call (30 Apr 20).pdf

TOPIC 2 - Low-SWaP SDA Hosted Payload

1 Topic Overview Information

1.1 Brief Topic Summary

This Broad Agency Announcement and Data Call is not a formal request for proposal. Proposals are not being requested or evaluated at this time. This will be a two-step closed BAA that will close on 15 June 2020 (45 days after release).

This is a Data Call that is being issued in conjunction with the FreeSol BAA (FA8819-19-R-1002). This closed broad agency announcement (BAA) will identify, develop, and demonstrate concepts for low-cost, low size, weight, and power (SWaP-C) (in accordance with Section 2.2.3) hosted space-based sensors to improve Space Domain

Awareness (SDA) of the GEO belt. The Government has identified a need for evolutionary or revolutionary space-based SDA sensors to augment current and planned systems by providing frequent, timely, assured volume revisit of significant portions of the GEO belt with real-time or near-real-time downlink and processing of collected data. As hosted payloads, these sensors should support a scalable architecture that can extend coverage as hosting opportunities arise. The goal of this BAA is demonstrate militarily useful, space-based SDA hosted sensor concepts with significantly lower recurring engineering costs (≤$10M).

The Government has worked with MIT/Lincoln Laboratories to develop a hosted payload (HP) that will fly on

Japan’s QZSS spacecraft. Bidders are encouraged to take advantage of this relevant design work in creating their concepts. One goal of this Data Call is to technology transfer aspects of the QZSS hosted payload from the laboratory to commercial vendors to enable a production line of GEO SDA Hosted Payloads. Requests for QZSS preliminary design information can be made through the technical POCs listed in section 1.4.1. The proposed concepts should account not only for the hosted payload space segment, but also the necessary ground segment components to ensure timely publishing of observations to the Unified Data Library. To support a scalable, hosted architecture, concepts must be low cost and low SWaP, and Bidders are expected to reuse existing technology and heritage components to minimize technical risk.

The Government’s evaluation at each phase will be based on the following factors (not in priority order):

1) Affordability, especially recurring engineering cost,

2) Degree to which the proposed concept meets or exceeds Government desired performance capabilities

3) Degree of technical risk associated with concept development, including the reuse of QZSS-HP design elements or other proven technologies

4) Degree to which the proposed concept schedule is achievable

1.2 Program Structure and Estimated Scope

The program will be structured into three phases, Phase 1 – Concept Design (CLIN 0001), Phase 2 – Design Phase

(CLIN 0002), and Phase 3 – Demonstration Phase (CLIN 0003). Initial proposals and awards will cover a Phase 1 for concept development. 30 days prior to the conclusion of Phase 1, bidders selected for Phase 1 have the option to propose to Phase 2. Phase 2 culminates in a design review that shows how the design satisfies project objectives.

60 days prior to the conclusion of Phase 2, bidders selected for Phase 2 have the option to propose to Phase 3. Phase

3 culminates in a ground demonstration of an engineering design unit and prototype ground segment. The

Government reserves the right to exercise the follow-on Phases 2 and 3 or not. If successful, further solicitations for additional ground tests or on-orbit flight tests (in or on a Government-supplied host) may follow.

Phase 1 is for a concept design phase. The contractor will explore design concepts, evaluate those concepts’ ability to fulfill the program objectives, develop and document requirements, describe risks, and propose a design, integration, test, and demonstration approach for Phases 2 and 3. The Phase 1 Concept Design Review should serve as the System Requirements Review/System Design Review leading to Phase 2. As part of Phase 1, contractors will collaborate with the Government to jointly identify and tailor compliance specifications and standards to be applied to Phase 2 and Phase 3. The duration for Phase 1 will not exceed 4 months. A notional schedule of milestones and expected deliverables are:

● Month 1: Kick-Off Meeting: 2-hour meeting (in person or via teleconference) (CDRL A001)

● Month 2: Technical Interchange Meeting: 4-hour technical interchange meeting (in person or via teleconference) to facilitate and refine mutual understanding of concept capabilities and Government objectives. During the technical interchange meeting, the bidder shall present a cost and schedule estimate for Phase 2 and 3. If long-lead procurements are required, identify the total cost and required procurement timeline. (CDRL A001)

● Month 4: Concept Design Review and Delivery; 4-hour presentation of the final concept design and report.

(CDRL A002)

Table 1: Phase 1 Funding Profile

Phase 1 - Concept Development Phase

Number of Awards Up to 5

Maximum Award (each) Up to $400,000

Phase 2 is the design phase of the program. The concept or concepts selected for Phase 2 will be funded based on

Government needs and funds available. During this phase the contractor will develop a design for their concept and assess how well it meets the Government objectives. The contractor should include any necessary long-lead procurements for Phase 3 as part of their Phase 2 proposal. The duration for Phase 2 will not exceed 9 months. A notional schedule of milestones and expected deliverables are:

● Kick-Off Meeting: 2-hour meeting (in person or via teleconference) within 30 days of Phase 2 option exercise (CDRL A001)

● Preliminary Design Review: 1-day in person. Deliverable in contractor format. (CDRL A001). During the meeting, the bidder shall present an updated cost and schedule estimate for Phase 3 and an estimate to build and deliver a flight qualified payload unit and a preliminary Build of Materials (BOM) for long lead materials.

● Technical Interchange Meetings: up to 2 meetings as requested by the Government or contractor lasting up to 1 day (in person or via teleconference) (CDRL A001)

● Critical Design Review: 1-day in person. Deliverable in contractor format. (CDRL A001)

● Final Report due for each concept awarded a Phase 2 design. Final report will include full critical design details. (CDRL A002)

Table 2: Phase 2 Funding Profile

Phase 2 - Design

Number of Awards Up to 2

Phase 3 is the demonstration phase of the program. The concept or concepts selected for Phase 3 will be funded based on Government needs and funds available for those options. During this phase the contractor will build an engineering design unit of the payload and a prototype ground segment designed in Phase 2 and use these to demonstrate the capabilities of their system with respect to Government objectives. Bidders are encouraged to execute Phase 3 in 12 months or less after the exercise of the option. A notional schedule of milestones and expected deliverables are:

● Kick-Off Meeting: 2-hour meeting (in person or via teleconference) within 30 days of Phase 3 option exercise (CDRL A001)

● Demonstration Plan: 2-hour meeting (in person or via teleconference). Deliverable in contractor format.

(CDRL A002)

● Technical Interchange Meetings: up to 2 meetings as requested by the Government or contractor lasting up to 1 day (in person or via teleconference) (CDRL A001)

● Demonstration Readiness Review: 1-day in person. Deliverable in contractor format. (CDRL A001)

● The Government will witness the demonstration activities (in-person)

● Final Demonstration Report: 4-hour out-brief (in person or via teleconference). Final report will include full demonstration as-executed procedures, results, and analysis. (CDRL A002)

● As-built Technical Data Package (CDRL A003) including an updated BOM.

Table 3: Phase 3 Funding Profile

Phase 3 - Demonstration

Number of Awards Up to 2

1.3 Whitepaper Requirements

A whitepaper broadly describing the concept and technical approach for Phases 1, 2, and 3 is requested.

Whitepapers should provide an overview of the proposed concept, describe expected performance with respect to

Government objectives, identify the key design features, describe risks and challenges (including procurement risks), discuss re-use of QZSS-HP design elements or other proven technologies, summarize intended demonstration scope, and discuss the innovations that will enable the design of a low-cost, low-SWaP sensor.

Whitepapers are due no later than 15 June 2020, 2:00 PM Pacific Time (45 days after release). The Government will review these whitepapers and request proposals within 30 days of the submittal deadline for those that most closely meet the needs of the government. Multiple whitepapers may be submitted by an organization.

The anticipated number of awards for each phase is detailed in Tables 1, 2, and 3 in Section 1.2.

Whitepapers will be evaluated in accordance with the FreeSol BAA guidelines (solicitation number:

FA8819-19-R-1002).

1.4.1 Points of Contact

Address technical questions to:

1Lt David Stiles (david.stiles.5@us.af.mil)

Capt Hillary Keltner (hillary.keltner.1@us.af.mil)

Address contracting questions to

Capt Patrick Enslen (patrick.enslen.1@us.af.mil) & Ms. Jacqueline Nguyen

(jacqueline.nguyen@us.af.mil)

Address security questions to:

Mr. Stephen A. Taylor (stephen.taylor.2@us.af.mil)

2 Description of Technical Area(s): Low-SWaP SDA Sensors

2.1 Scope

The Government needs low-SWaP-C, hosted, space-based SDA sensors to augment exquisite sensor systems and enhance the nation’s ability to detect high interest objects, track changes, and provide indications and warning for space events. These sensors need to be low cost and able to operate in a scalable manner that can take advantage of a variety of hosting opportunities, including international hosting opportunities. For this solicitation, bidders will propose concepts and perform a ground demonstration for a standard, low-cost, hosted payload (and associated ground segment) that can provide timely, assured revisit of a volume of the GEO belt. Bidders should assume their hosted payload concept will be mounted on the east or west panel of a host spacecraft in a GEO orbit.

2.2 Objectives

The objective of this solicitation is to develop and demonstrate concepts for low-cost, hosted SDA payloads to provide timely, assured volume revisit of the GEO belt. Phase 1, Concept Development, will deliver fully developed concepts to meet the Government objectives described below. The ongoing QZSS-HP development aims to deliver an initial hosted SDA capability, but is limited by unique constraints of the host (most notably uplink and mailto:david.stiles.5@us.af.mil downlink data rates), thermal challenges, and a significant solar exclusion gap. This solicitation aims to provide a more general hosted payload capability optimized for cost and size, weight, and power (SWaP) against a modified set of performance requirements. The Government will make QZSS-HP preliminary design data available to bidders, but challenges them to look at a broad range of solutions against the modified performance requirements with a focus on designing a low-cost, low-SWaP payload. Phase 2, Design, will be a government-exercised option in which the contractor will complete a full design for their concept. Phase 3, also a government-exercised option, will build, test, and demonstrate an engineering design unit and associated ground segment to provide measurable capabilities with respect to Government objectives described below.

Successful proposals will take into account the following considerations:

2.2.1 Operation

The operational construct for the hosted payload is for the SDA sensors to be mounted on either the east or west face of a host spacecraft in a GEO orbit with an unobstructed field of regard down the GEO belt. The sensors will operate in a non-tasked manner, executing search-based SDA operations of the GEO belt, within the sensor’s field-of-regard (FOR). While scanning through a predefined search volume, the sensors will collect SDA data on all

GEO objects that fall within the sensors’ minimum sensitivity threshold. The sensors will operate autonomously and require minimal commanding, with the exception of potential commands during anomaly resolution or emergency operations, as well as limited, non-time-sensitive commands to narrow or adjust scan coverage areas within pre-defined system limits.

The system will consist of a space segment (the hosted payload capable of flying on varied hosts) and a supporting ground segment at a US Payload Ops Control Center (POCC). C2 of the spacecraft bus will be performed by the host, while C2 of the payload will be done at the POCC. Encrypted data will flow between the POCC and the payload through an existing link segment that is part of the host spacecraft architecture. The payload ground segment development will include a nominal interface that can be tailored for any particular selected link segment.

The Government will provide encryption and long-haul communications on the ground as well as a Hosted Payload

Interface Unit (HPIU) to provide power conditioning and a communication path (including data encryption/decryption) between the payload and the host spacecraft.

The SDA data will flow near real-time to be further processed at the POCC for correlation of the observations. The processed SSA data will be published net-centrically to the Unified Data Library and be of sufficient quality to augment the SSN. Data collected by the payload will support the CSpOC and National Space Defense Center

(NSDC) operations as a dedicated SSN sensor.

2.2.2 Desired Capabilities and Performance

The key performance parameters include the following key areas: recurring engineering cost, volume surveilled, volume revisit rate, and sensitivity. The Government recognizes that these various areas require trades to be made.

The following table summarizes the thresholds and goals for these areas independently, but the Government expects that minimum performance in some areas may be matched with above minimum performance in others. The objective intent is to be able to cover at least 20° of latitude (10° of inclination) per payload and be able to proliferate payloads around the full 360° of the GEO belt. The greater the per payload performance and/or lower the cost, the greater the likelihood the government will be able to afford to proliferate.

Key Areas Threshold Goal

Recurring Engineering Cost* Not Specified ≤$10M

Volume Surveilled**

Longitude 10° ≥30°

Inclination ±7° ±15°

Altitude ±500 km ±1000 km

Volume Revisit Rate*** 30 min <15 min

Sensitivity**** 100 cm Min Detectable Object (MDO) ≤30 cm MDO

*doesn’t include host integration cost

**Bidders may choose standoff range

***when not in solar, lunar, or other exclusion. Sensor shall operate in the non-excluded portions of the volume

****with a probability of collect of ≥95% and probability of false track ≤3% when at Optimal Solar Phase Angle assuming a 0.2 reflective diffuse sphere

In addition, the concepts and designs should satisfy as many of these objectives as possible:

- Interface to the host using a Government-provided Hosted Payload Interface Unit

- Not drive significant changes to host spacecraft design

- “Do no harm” to the host for the duration of the host’s design life (assume 20 years)

- Operate in an autonomous discovery concept of operations throughout the volume. Sensors will be able to receive limited, non-time-sensitive commands to narrow or adjust scan coverage areas within pre-defined system limits

- Autonomously survive exposure to the sun as a result of space vehicle orientation, provided payload is continuously powered or shutdown command is provided before power shutdown

- Provide astrometric data with ≤5 arcsec accuracy in each right ascension and declination

- Minimize outages due to solar gaps, lunar gaps, or other reasons, with a threshold of no more than 12 hours within a 24-hour span and an objective of significantly less outage time

- Produce and report ≥4 observation per RSO track generated and be consistent with the guidelines in

AFSPCI 13-1214

- Provide observation data to the end user within 15 minutes (threshold) / 5 minutes (objective), measured as time from photons on the detector to generation of an observation message for the data dissemination service (not including any latency associated with host communication to and from the spacecraft)

- Be able to discern between actual RSO detections and events that produce false detections such that reported observations from the system’s mission unique ground processing will contain <3% false tracks

- Have an on-orbit design life of ≥5 years

- Have the ability to downlink full frame imagery and imagery for ground testing and calibration to the ground. The downlink of this information does not need to be real-time, and is excluded from the 30 minute (threshold) / 5 minute (objective) observation reporting timeline.

- Store and retrieve raw mission data for no less than 30 days after downlink, as well as provide at least 36 hours of payload on-board telemetry storage

- Collect and disseminate both astrometric and photometric observation data

- Allow a ground operator to view mode of operations, scan pattern, and current execution status

- Have a ground segment that operates autonomously (without required user actions) with the exception of initial checkout, state of health monitoring, anomaly resolution, and mission planning (if required).

- Have a ground segment that alerts the operator to a system anomaly and supports anomaly resolution

- Meet appropriate cybersecurity standards (including RMF and TEMPEST) for a national security space payload potentially hosted on an international spacecraft

The contractor is welcome to innovate and introduce additional capabilities that they believe may be of value to the overall goals.

2.2.3 Size Weight and Power (SWaP) and Host Assumptions

The concept payload should be suitable for hosting on a variety of spacecraft. Bidders should assume the host is in a

GEO orbit at 0° inclination and provides the payload a clear field of regard in either the ram or anti-ram direction.

Bidders should design their payload to be thermally isolated from the host spacecraft. Bidders should design their payload to be mounted on the east or west panel of the host spacecraft. Within these constraints, bidders will need to make and justify reasonable assumptions associated with hosting. As a general guide, payload SWaP (including the HPIU and encryption unit) should be less than the following:

- 100 kg

- 1.0 m x 0.5 m x 0.5 m

- 200 Watts

The government challenges bidders to offer hosted payloads with significantly less SWaP.

Host data uplink and downlink availability may vary. Therefore, bidders should consider concepts with scalable uplink and downlink requirements, with consideration for rates as low as a few kilobits/second up to 100s of kilobits/second. Bidders can choose to fix the data rate for a given host or make it dynamically adjustable. Data and power interface to the host will be through a government-provided Hosted Payload Interface Unit (HPIU).

Additionally, the government will provide an encryption/decryption device. The HPIU and encryption/decryption device must be integrated into the sensor payload envelope (details to be provided after award).

Based on a mounting on the host’s east or west panel, the concept should be thermally isolated from the host, and the concept design should document any additional assumptions related to the host interface as it affects the thermal design. The concept design should make and document reasonable assumptions related to the mechanical interface for this hosting location. The concept design should identify anticipated non-recurring engineering tasks required to integrate the payload with a specific host.

Bidders should assume that encryption/decryption and communication from the POCC through the host (or other) ground segment to the spacecraft and through the HPIU are provided by the Government.

2.3 Software, Firmware, and VHSIC Hardware Description Language (VHDL)

The contractor shall provide unlimited rights for all deliverables and software. Hardware and software developed during any of the phases shall be Government owned and delivered at the end of each phase.

3 Government Furnished Information

The Government will make QZSS-HP preliminary design information and HPIU interface information available to bidders by email request to the technical POCs listed in section 1.4.1.

4 Schedule

The contractor will propose a schedule not to exceed 4 months for the Phase 1 Concept Design activities and not to exceed 9 months for the Phase 2 Design activities. The Government encourages bidders to target completion of

Phase 3 within 12 months or less from the completion of Phase 2, not to include from time of award.

5 Other Requirements

5.1 FAR

The announcement incorporates FAR and supplemental provisions and clauses by reference. The full text of provisions and clauses can be found at: www.acquisition.gov

5.2 Export Control

Information involved in these research efforts will be subject to Export control (ITAR) 22 CFR 120-131 or Export

Administration Regulations (EAR) 15 CFR 710-774. A Certified DD Form 2345 Military Critical Technical Data

Agreement shall be submitted with all proposals.

5.3 Export Controlled Items

As prescribed by DFARS 225.7901-4 “Procedures” and DFARS 252.225-7048, "Export-Controlled Item (JUN

2013)" is contained in this solicitation. This clause shall be applicable to all resulting contracts.

6 Other Information

6.1 Government Furnished Property Availability

GFP is not anticipated to be made available under the resulting contract.

6.2 Government Furnished Information

Contact the technical POC to work out accesses and transfer as applicable.

7 Deliverable Items

7.1 Data Items

CDRL Table

CDRL Title

A001 Presentation and Program Review Materials

A002 Technical Plans and Reports

A003 As-Built Technical Data Package

A004 Data Accession List