HR001119S0015-Amendment-01.pdf

PDF 611 KB Posted

Attached to
Blackjack Satellite Integration Federal contract opportunity
Solicitation number
HR001119S0015
Issued by
Defense Advanced Research Projects Agency

About this file

This document provides questions and answers associated with the Blackjack Satellite Integration solicitation. The solicitation seeks proposals to develop approaches for integrating satellite buses, payloads, and autonomous network elements as part of the Blackjack program. Questions and answers covered interface requirements, design processes, collaboration needs, and other technical and management topics pertaining to satellite integration for the demonstration mission.

Not Listed

View the file

Other files for this federal contract opportunity

Other files attached to Blackjack Satellite Integration, newest first.
File Type Posted
Blackjack_Satellite_Integration_Q&A.docx DOCX document
HR001119S0015_Attachment_1_SCG_Request_Form_20190515.pdf PDF
HR001119S0015_Attachment_4_Summary_Slides_20190515.PPTX PPTX presentation
HR001119S0015_Attachment_3_Proposal_Template_Adm_National_Policy_20190515.docx DOCX document
HR001119S0015_Attachment_2_Cost_Summary_20190515.xlsx XLSX spreadsheet
HR001119S0015.pdf PDF
HR001119S0015_Attachment_5_Cost_Breakdown.xlsx XLSX spreadsheet

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

HR001119S0015

Broad Agency Announcement

Blackjack Satellite Integration

Tactical Technology Office

HR001119S0015

Amendment 01

July 19, 2019

The purpose of this amendment is to make revisions to language in the following sections, which are highlighted in yellow throughout the document:

PART I: OVERVIEW INFORMATION – Proposal Due Date

Contents

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

Program Lexicon A. Blackjack Program Vision B. Program Overview C. Design Reference Mission D. Management Approach E. Technical Focus Area F. Development Plan

II. Award Information A. General Award Information B. Proposals and Award C. Fundamental Research

III. Eligibility Information A. Eligible Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching

IV. Application and Submission Information A. Address to Request Application Package B. Content and Form of Application Submission

V. Application Review Information A. Evaluation Criteria B. Review of Proposals

VI. Award Administration Information A. Selection Notices and Notifications B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems

VII. Agency Contacts VIII. Other Information

PART I: OVERVIEW INFORMATION

• Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Tactical Technology Office (TTO)

• Funding Opportunity Title – Blackjack Satellite Integration

• Announcement Type – Initial Announcement

• Funding Opportunity Number – HR001119S0015

• Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable

• Dates o Posting Date: May 24, 2019 o Deadline to Request Copies of the Export Controlled Addendum: June 5, 2019 o Abstract Due Date and Time (indicate Eastern Time): June 11, 2019 by 4 p.m.

Eastern Time o Questions Due Date: June 14, 2019 by 2 p.m. Eastern Time o Proposal Due Date and Time: August 9, 2019 by 2 p.m. Eastern Time

• Concise description of the funding opportunity: Blackjack will develop and demonstrate a low earth orbit constellation that provides global persistent coverage. This opportunity focuses on development of satellite integration approaches.

• Total amount anticipated to be awarded – The total planned budget for award is $20.0M over three phases of the Blackjack Satellite Integration program.

• Anticipated individual awards – Multiple awards are anticipated.

• Types of instruments that may be awarded – Procurement contract or other transaction.

• Agency contact o Points of Contact The BAA Coordinator for this effort can be reached at:

HR001119S0015@darpa.mil

DARPA/TTO

ATTN: HR001119S0015

675 North Randolph Street Arlington, VA 22203-2114

• Other – An addendum containing additional export controlled information is available upon request as described in Section IV.A of Part II of this announcement.

mailto:HR001119S0015@darpa.mil

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 CFR § 200.203. Any resultant award negotiations will follow all pertinent law and regulation, and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA.

The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative proposals for Blackjack Satellite Integration. Under the Blackjack program, DARPA is contemplating a broad range of commercial satellite buses and military payloads and desires an approach that supports pairing any of the Blackjack commodity buses with any Blackjack payload, as late as possible in the design process. Information on representative buses, payloads, and Pit Boss is available in the addendum. Proposed research should investigate innovative approaches that enable revolutionary advances in the rapid integration of Department of Defense (DoD) payloads with commodity satellite buses. Specifically excluded would be any research that results in evolutionary improvements to the existing state of practice of small quantities of high-value spacecraft.

DARPA expects the Blackjack architecture to be extensible, easily integrating multiple types of commoditized satellite buses with a wide range of militarily relevant payloads supporting a variety of potential missions (e.g., detection, characterization, and tracking of advanced missile threats; alternate, high-accuracy positioning, navigation, and timing; and space-based surface moving target indication). Each pairing of a specific bus and one or more payloads (e.g., an infrared camera and its host satellite) will define a node in a particular functional constellation layer (see functional layer definition in Program Lexicon). Incorporating different pairings of a bus and one or more payloads, other functional layers may be rapidly deployed and integrated without modifying the architecture. DARPA envisions increasing the number of satellites in a given functional layer from a demonstration level (e.g., 20 nodes, sufficient to provide extended coverage over a geographic region for several hours) to a fully-capable constellation of hundreds of nodes providing constant custody of points of interest worldwide.

Finally, Blackjack will leverage open architecture standards and system controls permitting easy insertion of third-party software and hardware elements, including space-based payloads and hosted applications, communications equipment, and surface-based user devices and software.

Satellite Integration performers will be expected to provide the flexibility to enable iterative development of Blackjack elements by all developers.

The Blackjack demonstration program will investigate the incorporation of multiple functional layers and payload phenomenologies into a unified data collection and distribution architecture. These layers are expected to include overhead persistent infrared (OPIR) sensors, Position, Navigation, and Timing (PNT) payloads for Global Positioning System (GPS) augmentation, radio frequency (RF) and optical communications, including direct connectivity with tactical users from low earth orbit (LEO), multiple tactical intelligence, surveillance, and reconnaissance payloads, and all-weather, multi-domain asset geolocation, identification, characterization, and tracking.

Constellation-level and node-level command and control, health monitoring and remediation, inter- and intra-satellite data management, and on-orbit resource scheduling will be provided by the Pit Boss on-orbit cloud network. Hardware and software elements of Pit Boss will be integrated on each satellite node. The Satellite Integrator will coordinate with the bus, payload, and Pit Boss developers as equal program participants in developing the integrated spacecraft design. Providers will be required to establish an Associate Contractor Agreement with Blackjack performers to ensure that there will be appropriate coordination and integration of work by the Associate Contractors to achieve compatibility and to prevent unnecessary duplication of effort.

Blackjack’s 20-satellite demonstration is based on a notional 90-satellite functional layer that, depending on sensor type, is expected to permit global persistence and constant custody. A 20-satellite “stub” (2 orbital planes of 10 satellites each) will be flown in 2021 or 2022 to demonstrate low-cost sensor capabilities, real-time on-orbit payload processing, low-latency global connectivity using a commercial (or commercially-derived) data transport layer, and the autonomous functionality represented by the Pit Boss cloud network, described in BAA HR001119S0012. Parameters for a representative bus and representative payload mission sets can be found in the Addendum.

Within the Blackjack program, DARPA envisions five separate categories of contracts across multiple opportunities: commoditized buses, payloads, constellation-level autonomy, node integration, and launch/operations. BAA HR001118S0032 (“Blackjack”) addressed the acquisition of low-cost, commoditized bus and payload capabilities. BAA HR001119S0012 (“Blackjack Pit Boss”) focused on the third category, constellation-autonomy, which includes on-orbit cybersecurity and cryptographic solutions. This BAA focuses on satellite integration.

Selected Satellite Integration performer(s), in conjunction with Blackjack bus, payload, and Pit Boss providers, will develop approaches for integrating program hardware and software elements, while preserving the flexibility to incorporate new elements in the future. DARPA expects the satellite integrator to interact with the Pit Boss, bus, and payload performers as equal participants, to develop and define the interfaces. Successful proposers will demonstrate an advanced knowledge of the development and integration of satellite buses and bus subsystems of the size and capability being considered for the Blackjack program, including knowledge and experience with buses designed for high production rates (commoditized buses) and experience with payload integration with the types of payloads (OPIR, PNT, RF, Electro-Optical/Infrared (EO/IR)) under development for Blackjack. Table 1 summarizes the roles and responsibilities for each of the Blackjack program performers in developing functional layer architectures and integrated satellite nodes.

Table 1- Roles and Responsibilities**

Pit Boss Bus Payload Satellite Integrator

• Mission architecture, autonomy software, information assurance, mission data processing

• Constellation integration

• Deliver:

• Autonomy software

• Hardware, as required

• Constellation and satellite operations ground control

• HMSI user terminal

• Pit Boss simulator

• Pit Boss flatsat

• Mission performance validation via hardware and software in the loop testing

• Commodity bus

• Integration support

• Deliver

• 20 Buses

• Commercially-derived data transport layer (CDDTL) user terminals

• Bus flatsat

• Ground Support

Equipment

• Develop military payload, payload autonomy

• Integration support

• Deliver:

• 20 Payloads

• Payload flatsat

• Scene simulator

• Interface Control Document (ICD) management

• Prepare flight ready satellite nodes via integration of Pit Boss Subsystem, Bus, and Payloads

• Interface adapters, as required

• Deliver:

• 20 Satellites

• Interface validation via flatsat hardware-in-the-loop

** See definitions in Program Lexicon: Pit Boss, flatsat, Commercially-Derived Data Transport Layer (CDDTL).

Teaming is highly encouraged. Offers should provide an integrated team solution to cover all aspects of the BAA.

Proposers should submit fully detailed proposals for the Phase 1 base effort and Phase 1 options only. Proposers should submit only high-level statements of work (SOW) and rough order of magnitude (ROM) costs for Phases 2, 3 and potential follow-on efforts as described in Section II.1.E. DARPA expects proposers to support their ROMs with documented cost estimates defining the total program cost. It is anticipated that full proposals for Phases 2 and 3 will be requested during Phase 1 from Phase 1 performers.

Integration approaches supporting the ability to integrate multiple combinations of buses and payloads are desired. Proposers should not propose solutions that require integration of a specific bus or specific payload. If a team includes a performer from BAA HR001118S0032 or HR001119S0012, then the management section must include a plan to address intellectual property concerns with other performers. Proposals that result in a public/private partnership will be considered.

Program Lexicon

Blackjack: A DARPA program intended to develop and demonstrate a proliferated low earth orbit constellation of military payloads, providing persistent global coverage and low-latency dissemination of critical data products to users worldwide.

Satellite Integrator: Performer responsible for all aspects of achieving a launch-ready flight vehicle assembly from one or more payloads and all elements of the Pit Boss and

Blackjack spacecraft bus including testing to verify proper mechanical, electrical, and functional integration of the resultant assembly.

Zero Integration Approach: A design approach, based on open and standardized architectures, which will enable any Blackjack payload to be easily integrated with any Blackjack bus at any point prior to launch vehicle fairing encapsulation with minimal software or hardware interventions by the bus and/or payload teams. The goal is to move towards an architecture similar to computers and their peripheral equipment using standard USB interfaces for rapid integration.

Pit Boss: The autonomous, collaborative, distributed space-based network that will rapidly self-task, process, and distribute tactically relevant information to manned and unmanned subscribers. It includes architecture, software, and processing elements. Pit Boss represents the constellation-level autonomy functionality of the Blackjack architecture, extending beyond Blackjack nodes to include subscriber and command and control elements.

Node: An individual satellite consisting of a bus, payload(s), and Pit Boss.

Constellation: A nodal grouping with identical (or nearly identical) payloads and buses.

Constellation nodes are typically distributed evenly among multiple orbital planes and within each plane. Blackjack constellations are intended to provide continuous coverage (constant custody) or access to the entire surface of the earth. Each constellation will vary in capability, size, and composition depending on expected mission application and duration, payload types, and selected orbits.

Commercially-Derived Data Transport Layer (CDDTL): A constellation of commercially developed, deployed, and networked satellites intended to provide low-latency broadband service to users located across much (if not all) of the earth’s surface. The CDDTL will have inter-satellite links (ISLs) or other means of networking between satellites, enabling high-speed transmission of data among any CDDTL satellites and points on the ground via network gateways and user terminals. Blackjack constellations will communicate to end users (subscribers) primarily via the CDDTL.

Functional Layer: A homogeneous or heterogeneous constellation of DoD satellites with complementary payloads designed to collectively perform a specific military mission. A functional layer will have network connections with both the CDDTL and all other functional layers that, taken together, form the Pit Boss system.

Stub: A partial (non-globally persistent) Functional Layer – usually intended to demonstrate a new capability. A stub may be comprised of as few as two nodes, but for purposes of demonstrating low-cost reproducibility (and thus scalability of a specific function), more nodes are desirable. The Blackjack demonstration will consist of a 20-node stub, a pathfinder for a future (larger) constellation or functional layer. A stub can prove out specific mission capability without deploying a full functional layer and is envisioned as being rapidly expandable (enabling global coverage/constant custody) once the stub capability proves successful.

Subscriber: Users of data products and other services provided by the Blackjack system with connectivity into the Pit Boss network. Users can include humans (analysts, operators), unmanned and manned platforms, and other in-orbit or terrestrial sensors.

Autonomy: The ability of a Blackjack node, constellation, functional layer, or overall architecture to perform self-maintenance and to meet mission objectives through prioritization, decision making, and identification and performance of required tasking without the need for human intervention. Exemplar tasks include payload data collection, processing, and low-latency dissemination to selected subscribers. Autonomous operations may include performing a sequence of actions, such as commanding payloads or reconfiguring a constellation or functional layer, to achieve mission objectives over an extended duration without explicit human commands.

Live, Virtual, and Constructive Environment: Simulation environment combining humans operating real systems with virtual constructs of a simulated system to validate both machine-to-machine and machine-to-human interfaces. These environments permit studies of integrated solutions using networked enclaves of multiple simulator devices (i.e., simulations of Blackjack buses, payloads, Pit Boss, user and control segments, and the CDDTL network).

Massless Payload: A payload that is entirely algorithmic in nature, requiring only computing and power resources, while leveraging data and derived products available from Blackjack nodes, constellations, and functional layers, with no mission-specific hardware requirement or one that leverages existing hardware.

Behavioral Model: A simplified representation of a functional element in terms of the outputs versus inputs (e.g., payload, bus avionics unit, functional layer, Pit Boss).

Flatsat: Short for “flattened satellite,” this term refers to a benchtop-style hardware and software representation of the actual satellite flight unit, typically for bus or full spacecraft ground testing.

Brassboard: A high fidelity replication of the flight design that is assembled using flight hardware-like workmanship standards. It is used solely for development testing.

A. Blackjack Program Vision

Multiple National Security Space (NSS) assets have traditionally been deployed to geosynchronous orbit in order to deliver persistent overhead access to most points on the globe, for missions that cannot accept gaps between revisits, as would occur in sparsely-filled low earth orbiting constellations. In the increasingly contested space environment, these costly and monolithic systems have become vulnerable targets that would take years to replace after a failure. Their long development schedules preclude incorporation of new technologies or responsive adaptation to new threats. The goal of the Blackjack program is to develop and demonstrate – at low cost and on short schedules - the critical technical elements that leverage a commercially-derived space-based data transport layer in LEO. Blackjack will showcase the ability of highly networked, resilient, and persistent DoD payloads to provide over-the-horizon sensing, signals, and communication, and hold ground, maritime, and air domains under constant custody, globally.

Historically, DoD satellites have been custom-designed to specific mission sets with lengthy design and/or enhancement cycles at a high cost per spacecraft. The evolution of commercial space has led to the design of LEO constellations intended for broadband internet service. The design and manufacturing of these constellations could offer economies of scale previously unavailable in the space arena. DARPA is interested in leveraging these advances to provide military utility to a wide range of DoD users, emphasizing a commoditized bus and low recurring cost interchangeable payloads with short design cycles and frequent technology upgrades. The Blackjack architecture is based on the concept of ‘good enough’ payloads that are versatile enough to fly on more than one type of bus. Commoditized buses can be specified via mechanical, electrical, software, and mesh network (both node to node, and node to CDDTL) interface control to provide a platform for dozens or hundreds of different types of proliferated LEO payloads.

The solutions solicited in this BAA will be designed without direct consideration of a specific bus or payload. Selection of technology solutions to fly on a specific bus will not occur until after Preliminary Design Review (PDR). Satellite Integration technology providers will be provided draft interface documents at program kick-off that define the interfaces and environments of each bus under consideration for flight.

Every Blackjack orbital node will consist of one commoditized bus capable of broadband rate global communications to other nodes and to CDDTL satellites, one or more military payloads capable of operating autonomously, and Pit Boss hardware and software.

B. Program Overview

The program is divided into three phases (see Figure 1). Phase 1 will focus on the development of the system requirements and preliminary designs. This first phase will include the following elements:

HR001118S0032 Military Payload Development (previous BAA Track A) HR001118S0032 Commoditized Spacecraft Bus (previous BAA Track B) HR001119S0012 Pit Boss (previous BAA) HR001119S0015 Blackjack Satellite Integration (this BAA)

DARPA may select multiple teams for HR001119S0015 Satellite Integration during the Phase 1 base period. It is anticipated that one team will be selected to continue in Phase 2 and Phase 3.

A notional Blackjack schedule is illustrated below in Figure 1 - Blackjack Schedule.

Figure 1 - Blackjack Schedule

C. Design Reference Mission

It is envisioned that Blackjack nodes will operate near, or be proliferated within, a commercial constellation with communications and operations provided by that commercial constellation. Blackjack satellites will not be an integral or required element of the commercial constellation and will operate independently.

The long-term operational design reference mission is for a functional layer of 60 – 400 nodes operating in circular polar orbits between 500 and 1,300 km altitude. An operations center will manage DoD nodes via Pit Boss, but a functional layer should be capable of operating without the operations center for up to 60 days. The operations center will be designed to be staffed by no more than two people whose primary function will be to provide the interface between Pit Boss and commander’s intent. The operations staff will be responsible for resolving constellation, satellite, and subscriber anomalies that are outside the capability of the autonomous system to resolve. Payload data processing will be performed on-orbit and relevant data directly disseminated to tactical subscribers without intermediate ground-based data processing.

The reference demonstration mission for this BAA is comprised of 20 identical spacecraft performing a common mission, using 20 identical (or near-identical) payloads on each spacecraft. The Blackjack demonstration reference constellation will be two adjacent planes of 10 spacecraft evenly spaced in each plane in circular near-polar orbits at 1,000 km altitude. The demonstration mission will simulate global persistence by operating over 3,000-km-wide geographic regions for multiple hours each day. This 3,000 km diameter coverage area will repeat at every point on the planet every 12 hours, enabling theater-wide demonstration in any region of interest.

Additional reference information is provided in the Addendum. This includes a summary of a representative bus and representative payload parameters, including payloads for OPIR missile defense and RF-based PNT.

D. Management Approach

Blackjack Satellite Integration proposers should provide a comprehensive description of their program and risk management approach. The approach should address how to ensure physical and functional compatibility and identify incompatibilities between the bus, payload, and Pit Boss, through regular interactions and/or partnerships with those developers. The approach should include the process for management and coordination of interfaces through regular interaction with the other Blackjack performers, including definition and documentation of interfaces, interface control, and establishment of open architecture standards. This process should describe how to provide interface definitions and design standards to potential future bus or payload providers. The process should address configuration tracking and control to maintain compatibility as the design evolves.

The management approach should include regular teleconferences with the Government to review program, design, and development details, and regular interactions with payload/bus/Pit Boss performers to discuss any relevant interface and functional design details and to coordinate relevant program schedule items. In-person reviews should be held with the Government at major program milestones, to review progress against program objectives and to receive Government inputs on risk management trades. The program management approach should identify and track technical risks and establish risk mitigation approaches early and continuously throughout the program.

Lessons learned that would inform a zero integration approach should be captured at all phases of the program. The management approach should describe the process for schedule management for the satellite integrator and any subcontractors, as well as schedule coordination with bus, payload, and Pit Boss performers, in light of the complexity of integration of multiple program elements and participants.

E. Technical Focus Area

DARPA has identified two key technical areas (TAs) that collectively define the satellite integration development program. Proposals submitted must fully address both TAs to be considered. The subsections below provide detailed descriptions of each of these areas. Any hardware required for the proposed satellite integration approach should meet the performance objectives provided in Table 2 – Satellite Integration Performance Objectives.

Table 2 – Satellite Integration Performance Objectives

(Table 2 is included in the Addendum – Controlled Unclassified Information)

Of specific note, Table 2 specifies the recurring cost objective for each unit (if required) for current and future contract quantities from the initial two flight spacecraft, through the 20-node stub demonstration (18 additional nodes), and up to the full functional layer quantity (expected to be on the order of 90 nodes). This will ensure the DoD can expand the functional layer within the lower cost, ‘good enough’ envelope of the Blackjack functional layer architecture. The required Attachment 2 Cost Summary has a ‘Summary Information’ tab to provide this key information, including the notional follow-on effort to deliver 70 additional nodes. For reference, the Addendum also includes Table 3 – Payload Accommodation Parameters for a Representative Bus and Table 4 – Payload Parameters for Representative Payload Mission Sets.

TA1 – Extensible and Streamlined Satellite Integration

Under the Satellite Integration focus area, the satellite integrator shall propose an integration approach across all program phases for the Blackjack satellite nodes. The approach should enable the integration of multiple types of commoditized buses with Pit Boss and a wide range of payloads supporting a variety of potential missions while streamlining the typical integration and testing process for satellite nodes in production. This means developing an approach that minimizes both recurring and nonrecurring integration costs between a large number of DoD-specific payloads and commercial-off-the-shelf buses with the specific bus/payload pairing occurring late in the design phase. The integration approach should not drive any significant changes to the commodity buses. The integration approach should include all necessary assembly, integration, and testing activities to prepare the spacecraft node for spaceflight, including functional testing and environmental testing sufficient to verify launch vehicle compatibility. Variability between potential launch environments should be addressed in the integration approach. Proposers should address approaches for workmanship, infant mortality, environmental, and functional testing for the initial satellite node and for subsequent units including required facilities, optimization and standardization of workflows, transportation, handling, and ground support equipment.

The satellite integrator should describe their approach to working with the payload, Pit Boss, and bus performers to develop interface requirements and designs, and to develop and maintain all necessary interface control documents for the payload-to-bus, Pit Boss-to-bus, and Pit Boss-to-payload interfaces. Each bus performer, in a unilateral Interface Definition Document, will provide bus interface data. The performer should describe their approach for managing the range of on-orbit environments and the impact on bus/payload(s) pairings. The Pit Boss interface design will be dependent on the proposed Pit Boss architectural approach. The satellite integrator will be required to work with the Pit Boss developer to facilitate and incorporate their proposed architecture within the integration approach. The satellite integrator responsibility will include development of any required hardware and software to enable the mechanical and electrical integration of multiple payloads with commodity buses, and includes integration of Pit Boss hardware and software elements with buses.

The following integration capabilities are of interest:

Integration approaches that minimize recurring and non-recurring costs Approaches that enable separate development of buses, Pit Boss, and payloads past PDR Approaches that are tolerant of changing interfaces Approaches that eliminate or minimize hardware and cabling Approaches that minimize or eliminate launch site testing Methods to minimize environmental and acceptance testing Approaches that employ automated testing (scripts, tools, procedures) Approaches that accommodate a wide range of on-orbit and launch environments

TA2 – Assembly, Integration, and Test

For the Assembly, Integration, and Test (AI&T) focus area, DARPA is interested in the development of an AI&T process and plan involving close collaboration with bus, payload, and Pit Boss developers and progressive levels of complexity as design development proceeds to ensure successful integration of satellite node elements. This includes software-in-the-loop (SWIL) testing and hardware-in-the-loop (HWIL) verification of integrated node functionality for multiple bus/payload pairings selected by the Government. Testing will be conducted at the system integrator facility.

The testing approach should uncover satellite node hardware integration challenges early in the program and the system integrator should work with program participants to develop solutions. The testing should include day-in-the life operational exercising of the integrated bus, payload, and Pit Boss node in simulated space environment (e.g. Pit Boss command generation, payload receipt and data generation, transfer to Pit Boss for processing, data transfer through bus and simulated CDDTL to a large number of diverse Blackjack subscribers).

The AI&T process and plan should address final integrated node testing, delivery to the launch site and launch integration support, and performance testing for both the initial two satellite node deliveries and for the subsequent 18 satellite node launch and full 20-satellite stub.

The following capabilities are of interest:

Rapid assembly and integration of SWIL modules, HWIL flatsats, and actual flight hardware versions of buses, payloads, and Pit Boss to validate multiple pairings

Streamlined functional testing and environmental testing approaches for prototype units and integrated flight hardware with progressive optimization of testing approach for units after initial qualification

Collaborative approaches to work with Pit Boss, bus, and payload performers in support of the Pit Boss performer’s Constructive, Live, Virtual test environment

Approaches to integrate multiple bus, payload, and Pit Boss combinations Approaches to rapidly change buses and payloads

F. Development Plan

Blackjack will use a three-phase approach leading to an on-orbit demonstration. In Phase 1 Base, the satellite integration performer will perform interface requirements definition and interface design and will deliver a Systems Requirements Review (SRR). After completion of SRR, the Phase 1 Option 1 may be exercised for select performers. The Phase 1 Option 1 will focus on preliminary interface design and definition. After completion of PDR, the Phase 1 Option 2 may be exercised for select performers. It is anticipated that the request for proposals for Phase 2 and a Phase 3 Option will be provided to performers concurrently with notification of intent to exercise Phase 1 Option 2. During Phase 1 Option 2, performers will commence detailed interface design and will conduct HWIL bus, payload, and Pit Boss integration and functional testing. Performers selected to proceed into Phase 2 will continue satellite integration detailed design, including management and refinement of all program ICDs. Phase 2 performers will also deliver a Critical Design Review (CDR) and will conduct HWIL testing of buses, payloads, and Pit Boss at the integrator facility. Satellite node integration for flight will occur after CDR with delivery of two satellite nodes at the end of Phase 2. After Phase 2, the Phase 3 Option may be exercised. In Phase 3, performers will deliver the first 2 satellite nodes to the launch site before integrating and delivering an additional 18 spacecraft. Performers will also continue with HWIL integration and testing, and will deliver the final ICDs.

For each phase, proposed development plans should address the development of the items on the Deliverables list in Table 5.

Phase 1 Base – Requirements Definition

The Phase 1 Base objectives include development of interface requirements, preliminary interface design, and interface management plan including any required integration hardware and software; and development of the system integration plan. Phase 1 Base will conclude with completion of the system integration SRR as shown in schedule in Figure 1. A description of the SRR expectations is included in the Design Reviews section below. The performer will support a Technical Interchange Meeting (TIM) with all Blackjack program performers (Pit Boss, bus, and payload) to review roles and responsibilities, system development plans, integration approach, and to identify and address any gaps in completing an integrated design.

Phase 1 Option 1 – Preliminary Design

The Phase 1 Option 1 objective is to complete the system integration PDR. The proposer will refine and provide details of their proposed integration approach. Proposers are encouraged to identify key enablers for the zero integration approach. Plans for HWIL interface validation and testing will be developed.

Phase 1 – Option 2

The Phase 1 Option 2 objective is to perform the initial detailed design development for any required system integration hardware and software and to complete HWIL integration and functional testing of buses, payloads, and Pit Boss in conjunction with SWIL simulators of each as needed. During Phase 1 Option 2, detailed proposals for Phase 2 with a Phase 3 Option may be requested, selected, and awarded.

Pit Boss software and brassboard along with bus and payload emulators will be delivered to the satellite integrator facility for HWIL testing. The satellite integration performer will integrate and demonstrate three flatsats, each comprised of different bus designs, a different set of payloads, and Pit Boss software and hardware emulators together at the integrator facility.

The testing should demonstrate autonomous passing of commands and data through the integrated flatsat, across the CDDTL simulator, and out to multiple simulated subscribers (users) in the proper format.

During Option 2, detailed design work in support of CDR will commence.

Phase 2 – Detailed Design

The Phase 2 focus is on completion of the detailed design and the integrated satellite CDR, followed by the delivery of flight hardware and software, and the assembly, integration, and testing of the first two satellite nodes. Development for HWIL testing will follow the schedule outlined in Figure 1.

During Phase 2, the satellite integrator will refine and implement their integration approach. The satellite integrator will continue to manage, develop, and document all interfaces that exist between performers including bus-to-payload, bus-to-Pit Boss, and Pit Boss-to-payload. Interfaces that do not cross between performers remain the responsibility of that performer. Assembly, integration, and testing of the two flight nodes will be conducted in accordance with the AI&T plan, including environmental testing and any required flight certification testing. The two nodes will then be prepared for delivery to the launch site.

The satellite integrator will conduct verification testing with HWIL flatsats and SWIL simulators as shown in the schedule in Figure 1.

Phase 3 Option – Launch and Demonstration

During the Phase 3, the program will transition to on-orbit demonstrations. For the two satellite nodes delivered during Phase 2, final launch integration and system level testing will be completed, in accordance with the AI&T plan. Support of launch, checkout, and the on-orbit demonstration will also be required.

During Phase 3, the satellite integrator will integrate the remaining 18 satellite nodes and deliver them to the launch site along with any required flight certifications. A second round of launch integration, launch, checkout, and on-orbit demonstration will be required for the full 20-satellite stub. The satellite integrator will continue execution of HWIL testing as necessary.

After the initial satellite deliveries, integration and testing should become more streamlined, demonstrating a rapid and reduced-cost flight hardware delivery approach.

During Phase 3, the satellite integrator will maintain at least two flatsats in the “as flown” configuration of the Blackjack demonstration satellites. The flatsats will be capable of being integrated into the flight demo via the commercial network, to simulate additional spacecraft. If required, the flatsats may also be used for anomaly resolution and SWIL testing prior to on-orbit software updates. These flatsats may need to be integrated either remotely or directly into the Pit Boss Constructive Virtual Live demonstration environment.

Deliverables

All proposers should structure their deliverables as described in Table 5 – Primary Deliverables and Table 6 – Milestones and Deliverable Dates. Table 6 provides the expectations for the primary program deliverables at key milestones in the program. Performers should identify any additional deliverables required to support the program objectives. To support integration and future transition opportunities, DARPA expects to receive, at a minimum, Government Purpose Rights for deliverables 6, 9, and 10.

Proposals should contain initial versions of the deliverables identified in the “Proposal” column of Table 5 below, with updates and final deliverables provided as indicated in the table:

Table 5 - Primary Deliverables

Phase 1 Phase 2

Base Option 1 Opt 2

It em

D el iv er ab le

Pr op os al

K ic ko ff

SR

R m on th s af te r

SR

R

PD

R

B ri dg e

O pt io n

C D

R

E nd o f

Ph as e

Ph as e

1 Milestone data packages and presentations

Due (D) 10 working days in advance working days in advance working days in advance working days in advance working days in advance

2 Integrated Master Schedule

D Updated (U)

U U U U U Final

3 Risk Management Plan

D U U U U U U Final

4 AI&T Plan D U U U Final

5 Interface Management Plan

D U U U U Final

6 System ICDs* D U U U Final

Legend: U = Updated; D = Due.

*NOTE: System ICDs include bus-to-payload, Pit Boss-to-bus, and Pit Boss-to-payload interfaces, Government node/network-to-CDDTL, and CDDTL network-to-ground subscriber.

Proposers are expected to meet the milestones and deliverable dates defined in Table 6 assuming a Q4 FY19 award.

Table 6 - Milestones and Deliverable Dates

Phase Date* Integration

1 (base) Q4 FY19 Kickoff

Q1 FY20 SRR

1 (option 1) Q2 FY20 PDR

1 (option 2) Q2 FY20 System Integration Demo

7 Flatsat Integration and HWIL Plan

D U U U U Final

8 Flatsat HWIL Test Reports

D U U U U Final

9 Hardware Specification (if required)

D U U

10 Hardware ICD (if required)

D U U U Final

11 Hardware Delivery (if required)

Brass-boards

EDU, 2

Flight Units

18 Flight Units

12 Satellite Test Plan D U U U Final

13 Satellite Test Reports

D Final

14 Integrated Satellite Node

D Final

15 Next Phase Proposal

Phase 2 and 3, Due

16 Entrance/Exit Criteria

D U U U

2 Q4 FY20 CDR

Q2FY21 Deliver two spacecraft

3 Q4 FY21 Deliver 18 additional spacecraft

*Note: Deliverable dates are based on the notional schedule in Figure 1.

Proposed dates should reflect the proposer’s determination of a realistic and achievable approach.

In addition to the deliverables outlined above, the performer shall also provide the following:

• Monthly technical and financial status reports

• Monthly Integrated Master Schedule (IMS) updates, MS Project format

• Final Report

Design Reviews: The satellite integrator will execute an SRR, PDR and a CDR for the integrated spacecraft with content and entrance and exit criteria tailored from a recognized industry or military standard (e.g., Defense Acquisition Guidance (DAG) guidelines available at https://dag.dau.mil and MIL-STD-1521B are suggested sources) for appropriate application to a technology demonstration program. Proposals should clearly address how these standards will be tailored in the proposed effort. Any tailoring of design review content and criteria must include an assessment of the design maturation of the technology, technical risk, and incorporate demonstrable technology maturation progress and achievements. Specific expectations for the Blackjack program are outlined below, and should be incorporated into the performer’s comprehensive list of tailored design review criteria, which will be evaluated to assess the adequacy of the proposed systems engineering processes. In addition, these checklists will need to be approved by the Government prior to the start of the reviews to allow the Government to understand and assess the adequacy of the proposed tailoring of these reviews. Any changes or updates to the entrance and exit criteria during phases must be provided to the Government and approved, as indicated in the deliverables table.

General:

• Requirements Development - A complete set of interface, demonstration system performance, and design requirements is established down to the lowest expected level of the system hierarchy (i.e., system, subsystem, and component) for the subject review.

Each requirement must include verification provisions. System interfaces are identified and documented.

• Design Definition - The design of the system is established down to the lowest expected level of the system hierarchy for the subject review, satisfies established requirements, https://dag.dau.mil/ and is sufficiently detailed to enable the next level of design definition. Appropriate design margins are identified and maintained.

• Risk Management – Technical, cost, and schedule risks are identified and assessed (e.g., consequence and likelihood). Mitigation plans are in place along with associated completion criteria. Technical risks have been updated with results of any mitigation activities.

• Technology Maturation – System/hardware/software attributes requiring maturation have been identified and associated analysis, test, and demonstration objectives have been documented. The representative test article design is documented.

SRR

• Requirements Development – System (Level 1) requirements and preliminary allocation of segment (Level 2) and subsystem (Level 3) requirements are complete. Preliminary interface requirements and interfaces defined.

• Conceptual Design – Conceptual design is completed and approach is shown to be feasible through initial analysis. A pathway to the preliminary design is identified.

• Software Development – For any software elements, a development plan including verification and validation approach.

• Trade Studies – Results of any trade studies completed to validate design approach.

• Cost – Initial cost estimates are documented and show a feasible path to Bill of Materials

(BOM) cost that meets cost metrics.

PDR

• Requirements Development – System (Level 1), segment (Level 2), and subsystem (Level 3) requirements are complete. Initial verification methods (e.g., Analysis, Integration, Test, and Demonstration) are identified and detailed verification statements are complete at the subsystem level. Interfaces are documented (Pit Boss to bus; Pit Boss to payload; bus to payload; Blackjack node to CDDTL; Blackjack node to ground/subscriber).

• Design Definition – Assess the allocated design documented in subsystem requirements.

Preliminary design is complete to the subsystem level (Level 3), closes around documented requirements, adequately demonstrates that performance achieves minimum and maximum threshold ranges, and meets size, weight, and power, plus cost (SWaP-C) constraints.

• Software Development – Development plan with processes and metrics to measure progress.

• Risk Management – Risk matrix updated.

• Technology Maturation - Desired technology maturation can be achieved via planned development within program budget and schedule. Test plans define objectives and expected results that will validate design proof-of-concept.

• Cost – Revised BOM cost based on preliminary design is documented and within established cost metrics.

CDR

• Requirements Development – Component (Level 4) requirements are complete.

Verification approach for each requirement has been established. Internal interfaces between subsystems are documented.

• Design Definition – Critical designs are complete to the component level (Level 4) and achieves compliance with all associated requirements.

• Cost – Final design BOM costs are documented and within cost metrics.

Government Management Approach and Operations: The Government recognizes that a streamlined, collaborative management approach is essential to achieving the program technical, cost, and schedule objectives. The Government Program Office is comprised of a core technical and programmatic team, which may be augmented with Government-led Integrated Product Teams (IPTs) including Federally Funded Research and Development Center (FFRDC) and University Affiliated Research Center (UARC) personnel for targeted technical disciplines, for example, systems engineering, encryption, integration, modeling & simulation, etc. The performers will interface with the Government teams via coordination meetings at the technical level, status meetings at the management level and quarterly program management reviews. The proposers are asked to provide a management approach to allow for collaboration with the Government team to ensure a successful program.

II. Award Information

A. General Award Information

Multiple awards are anticipated. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

The Government reserves the right to select for negotiation all, some, one, or none of the proposals received in response to this solicitation and to make awards without discussions with proposers. The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options. Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award. In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work, as applicable.

The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications (see Section VI.B.4, “Representations and Certifications”). The Government reserves the right to remove proposals from award consideration, should the parties fail to reach agreement on award terms, conditions, and/or cost/price within a reasonable time, or the proposer fails to provide requested additional information in a timely manner. Proposals identified for negotiation may result in a procurement contract, or other transaction, depending upon the nature of the work proposed, the required degree of interaction between parties, whether or not the research is classified as Fundamental Research, and other factors.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see the section below on Fundamental Research.

B. Proposals and Award

Proposers shall prepare full proposals to address Phase 1 (including options) and a ROM for Phase 2, Phase 3, and the potential follow-on effort (see Section II.1.E for details on the potential follow-on effort) in accordance with the proposal format instructions detailed under Section IV.

It is anticipated that the Government will request proposals for Phase 2 and Phase 3

Option during Phase 1 Option 1. It is anticipated that this proposal will be requested around the time of PDR. After completion of PDR, the Phase 1 Option 2 may be exercised for select performers. It is anticipated that the request for proposals for Phase 2 and a Phase 3 Option will be provided to performers concurrently with notification of intent to exercise Phase 1 Option 2 Only those performers whose Phase 1 Option 2 is exercised will be invited to submit a Phase 2 and Phase 3 Option proposal.

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .