HR001119S0012-Amendment-02.pdf

HR001119S0012

Broad Agency Announcement

Blackjack Pit Boss

Tactical Technology Office

HR001119S0012

Amendment 02

April 1, 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 II.I.B. Blackjack Schedule – Figure 3 - page 15

PART II.I.F. Deliverables – Table 3 - Primary Deliverables, page 25-27

PART II.I.F. Deliverables – Table 4 - Milestones and Deliverables Dates, page 27

PART IV.B.4.a. Abstract Submission, page 51-52

PART IV.B.4.b. Proposal Submission, page 52-53

Contents

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

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

II. Award Information A. General Award Information B. Proposals and Awards 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

List of Figures Figure 1 – Blackjack Operational Concept………………………………………………………12 Figure 2 – Blackjack Assembly Levels (notional)……………………………………………….13 Figure 3 – Blackjack Schedule…………………………………………………………………..14

List of Tables Table 1 – Roles and Responsibilities**…………………………………………………………...8 Table 2 – Pit Boss Performance Objectives……………………………………………………...16 Table 3 – Primary Deliverables………………………………………………………………….24 Table 4 – Milestones and Deliverable Dates…………………………………………………….26

PART I: OVERVIEW INFORMATION

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

Funding Opportunity Title – Blackjack Pit Boss Announcement Type – Initial Announcement Funding Opportunity Number – HR001119S0012 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable Dates o Proposers Day: September 19, 2018 o Posting Date: February 1, 2019 o Deadline to Request Copies of the Classified and Export Controlled Appendices:

February 11, 2019 o Abstract Due Date and Time (indicate Eastern Time): February 19, 2019 by 4 p.m. Eastern Time o Questions Due Date: February 22, 2019 by 2 p.m. Eastern Time o Proposal Due Date and Time: April 12, 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 spacecraft autonomy hardware and software elements. Key aspects of the Blackjack Pit Boss program are classified. Only proposals addressing the classified aspects of Pit Boss will be eligible for funding under this Broad Agency Announcement (BAA).

Total amount anticipated to be awarded – The total planned budget for award is $38.5M over three phases of the Blackjack Pit Boss program. The program anticipates future announcements and awards that are not encompassed by this BAA that will be utilized to solicit for launch services, ground systems, and constellation flight operations.

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:

HR001119S0012@darpa.mil

DARPA/TTO

ATTN: HR001119S0012

675 North Randolph Street Arlington, VA 22203-2114

Other – Appendices containing controlled and classified information are available upon request for additional distribution as described in Section IV.A of Part II of this announcement.

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 Pit Boss, an architecture and associated software/hardware approach providing a proliferated Low Earth Orbit (P-LEO) system the ability to continuously deliver perishable target data to selected subscribers, without the need for (1) commanding from human satellite operators; or (2) ground-based payload data processing and exploitation. Dramatically reducing the time required to task, collect, process, exploit, and disseminate critical target data during peacetime and conflict is an overarching goal. The objective of Pit Boss is to rapidly, precisely, and autonomously acquire target localization, characterization, and persistent tracking information using a global constellation of P-LEO satellites, some carrying militarily relevant payloads. Additional goals of Pit Boss include augmentation of associated capabilities, to include positioning, navigation, and timing enhancements, as well as low-latency, global space-to-surface tactical user communications. Pit Boss will enable rapid dissemination of critical data to tactical users worldwide, at campaign scale.

DARPA desires proposals from prospective providers for a P-LEO constellation-level autonomous, collaborative, distributed space-based network functionality, the Pit Boss on-orbit cloud network. Providers will be expected to work closely with multiple Blackjack bus (Blue Canyon Technologies, Telesat Canada, and Airbus Defense and Space) and payload (TBD) performers to bring about this new, disruptive capability to support DoD space. 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. DARPA expects the Pit Boss network to incorporate advances in constellation command and control, health monitoring and remediation, inter- and intra-satellite data management, and on-orbit resource scheduling for hundreds (and eventually thousands) of DoD satellite nodes, with minimal human intervention. Pit Boss will perform target hand-off among satellites surveilling a given geographic region, as individual P-LEO nodes will be continuously entering and exiting these regions due not only to (1) the high velocities of Low Earth Orbit (LEO) nodes relative to a ground position, but also due to (2) differences in altitude, payload phenomenology, footprint, and fields of view. Active nodes surveilling a geographic region at any given time define an “instantaneous orbital observation group.”

DARPA expects architectural proposals for Pit Boss that are extensible, scalable, and adaptable. Extensible architectures are defined as those which easily integrate 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 missile threats;

alternate, high-accuracy positioning, navigation, and timing; and space-based surface moving target indication). Each pairing of a specific bus and payload (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), and by incorporating other bus/payload pairings, other functional layers may be rapidly deployed and integrated without modifying the Pit Boss architecture.

Scalable architectures more easily accommodate greater numbers of satellite nodes without degradation to tasking, collection, processing, and data dissemination functions – Pit Boss will be expected to provide data products on short timelines to thousands of subscribers simultaneously.

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 targets worldwide. Scaling up in this fashion should not require different software or a new cloud network architecture. Finally, adaptable architectures are those that 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. Pit Boss performers will be expected to provide the equivalent of a software development kit and integrated development environment to enable iterative development of Blackjack bus, payload, and Pit Boss systems 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 LEO, multiple tactical intelligence, surveillance, and reconnaissance payloads, and all-weather, multi-domain asset geolocation, identification, characterization, and tracking.

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 earlier. Detailed examples of specific mission scenarios and representative performance parameters for bus/payload pairings can be found in Appendix B (classified) and Appendix C. Key aspects of the Blackjack Pit Boss program are classified. Only proposals addressing the classified aspects of Pit Boss will be eligible for funding under this BAA. Proposers should define and describe an architecture that addresses the following areas:

An approach to achieve extensibility, scalability, and adaptability for a P-LEO architecture composed of multiple functional layers, buses, and payload types, to include compatibility with existing and proposed user and command and control segment hardware and software architectures

An approach to developing and deploying robust Autonomous Multi-Mission Execution Software

An approach to developing and deploying a Human-Machine Subscriber Interface

(HMSI)

An approach to specifying and satisfying On-Orbit Computing Resource Requirements, including those resources required by Pit Boss in excess of available node (bus/payload) resources and how these computing resources will be managed and used

An approach to executing Mission Demonstration through Live and Virtual Constructive Environments, intended to demonstrate technical maturation and provide early opportunities for risk retirement

An approach to Encryption and Information Assurance for proliferated satellites communicating through a commercially-derived data transport layer (CDDTL) in a system that includes large numbers of network subscribers with low-latency, high-bandwidth data requirements

Specifically excluded would be any research that results in evolutionary improvements to the existing state of practice of small quantities of high-value spacecraft.

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. This BAA focuses on the third category, constellation-level autonomy, which includes on-orbit cybersecurity and cryptographic solutions. Future announcements will address node integration, launch, and operations.

Pit Boss is a constellation-level autonomous functionality suite. It can be viewed as a collection of data services hosted aboard on-orbit processors on Blackjack functional layer nodes, or – at a higher level of abstraction – as a space-based data cloud service. Pit Boss will be expected to continuously run on-orbit node (bus/payload) control algorithms, perform network data routing, and sustain the operation of multiple Blackjack functional layers (constellations) while providing perishable data products to surface-based subscribers on tactically-relevant timelines. Proposers are requested to define and describe an architecture for Pit Boss that includes functional layer and node control, mission data management, data transfer, storage and processing, and data dissemination to subscribers.

Selected Pit Boss performer(s), in conjunction with Blackjack bus and payload providers, will develop designs for the architectural and hardware/software elements comprising Pit Boss.

DARPA expects Pit Boss, bus, and payload performers to interact as equal participants, working as needed with the node integrator, to develop interfaces and a constellation and mission architectural approach 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

• Develop zero integrator model

• 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

**Note: See definitions in Program Lexicon: Pit Boss, flatsat, CDDTL, zero integrator model.

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 1 and 2, as described in Section III, Detailed Proposal Information. Proposals for Phase 1 Base and Phase 1 Options 1 and 2 should provide task-level descriptions (typically Level 4) in the Integrated Master Schedule (IMS) and Statement of Work (SOW) to provide the Government adequate insight into the task breakdown and resources proposed to accomplish the work.

Because the Government intends to ask for proposal updates for Phases 2 and 3 during Phase 1 options, proposers should submit a SOW and Rough Order of Magnitude (ROM) costs for Phases 2 and 3 at one higher level (e.g. Work Breakdown Structure (WBS) Level 3) at this time.

It is anticipated that Phase 2 and 3 full proposals will be updated with additional detail in the IMS, SOW and cost proposal during Phase 1. DARPA expects proposers to support their ROMs with documented cost estimates defining the total program cost to support an evaluation of cost realism.

Proposers are encouraged to provide example solutions describing specific bus, payload, and Pit Boss subsystem (node) combinations and resulting functional layers, but they must also describe how their solution will provide a versatile, open framework that allows Pit Boss to accommodate alternative commoditized buses, payloads, and functions/missions described in Appendices B and C. Proposals that incorporate public/private partnerships will be considered.

Program Lexicon

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: Each Blackjack satellite – or bus/payload pairing - is a node in the Pit Boss system. Each node is expected to host on-orbit processing hardware and software that permits collaboration with other Blackjack nodes and communication with network subscribers via one or more commercially-derived transport layers. Each node includes Pit Boss elements, exclusive of payload- and bus- specific systems.

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.

The Pit Boss BAA opportunity focuses on the development of constellation-level autonomous functionality to support Blackjack program objectives.

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.

Instantaneous Orbital Observation Group (IOOG) or Observation Group (OG): A collection of nodes from one or more constellations or functional layers, instantaneously resident over, and capable of collecting data from, a given geographic area. The list of nodes that make up an IOOG or OG will change as individual spacecraft move into and out of coverage, based on payload phenomenology, orbital parameters, and other factors (e.g., duty cycle, operational status). Constellations and functional layers will support engagements in multiple OGs simultaneously, at various locations around the globe.

Stub: A partial (non-globally persistent) constellation – usually intended to demonstrate a new capability - that is a subset of a constellation or functional layer. 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-satellite stub, a pathfinder for a future (larger) constellation or functional layer. A stub can prove out specific mission capability without deploying a full constellation 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.

Zero Integrator Model: A design approach, similar to open 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.

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.

Software Development Kit (SDK): An implementation of application programming interfaces (APIs) in the form of libraries to interface to the Pit Boss system and hardware-specific tools that can communicate with Blackjack nodes and subscribers to allow any DARPA-approved third-party developers to integrate new software without formal teaming with existing bus, payload, or Pit Boss performers.

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.

Common Relevant Operating Picture (CROP): A common set of relevant data continually shared and updated by nodes in a functional layer. Some examples of the types of data contained in the CROP include ephemerides; health and status information; mission tasking requests; target track data; sensor data; cybersecurity status; and payload collected raw data.

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 infinite over the horizon sensing, signals, and communication, and hold ground, maritime, and air domains under constant custody, globally.

This BAA solicits solutions for a constellation-level autonomy functionality suite (i.e., Pit Boss) and its architecture. Pit Boss functionality includes autonomy, on-orbit edge processing, network management, data management, command and control, health monitoring, and station keeping functions. These solutions will be designed without direct consideration of a specific combination of spacecraft bus/payload (node). Representative bus and payload performance parameters are summarized in Appendix C. Selection of technology solutions to fly on a specific bus will not occur until after a Pit Boss Preliminary Design Review (PDR). Pit Boss providers will be given draft interface documents at program kick-off that define interfaces and environments for each bus under consideration for flight. Providers will also be given technical parameters for at least six payloads that cover functions and missions associated with OPIR, PNT, RF communications, and geolocation. Pit Boss providers will be further given an opportunity to design an integrated solution that works for each of the payload types in Government-provided mission vignettes provided one month after kickoff along with additional design information for the buses and payloads under development. Pit Boss must integrate the data provided by individual nodes into useable information to support these missions. Pit Boss must provide that information to subscribers, including on-orbit, in-air, at-sea, and on-ground subscribers, using ISL and CDDTL downlinks, or other satellite-to-satellite or satellite-to-ground links. Pit Boss must provide that information with minimum latency to support real-time decision making and situational awareness, and it must deal with high-bandwidth requirements on-orbit to transfer raw data and process it to useful information, as well as high-bandwidth requirements for data transfer to the ground. Proposals should address the capability of the proposed architecture to meet these requirements.

Every Blackjack node in a constellation or functional layer will consist of one commoditized bus capable of broadband-rate global communications to other nodes and through the CDDTL to subscribers, one or more military payloads capable of autonomous operation, and the constellation-level autonomy function (Pit Boss), providing relevant space-based tactical data to DoD subscribers on short timelines. A diagram of the Blackjack operational concept is provided in Figure 1. Note the direct connection from in-theater sensing by satellite nodes that have direct network connection to the commercial transport layer nodes which in turn provide processed data to users (subscribers) anywhere without the need to transmit raw data to a traditional ground station or perform offline data processing prior to transmitting data to subscribers.

DoD Satellite

DoD Satellite

DoD Satellite

Instantaneous Orbital Observation Group

Commercially-Derived Data Transport Layer (CDDTL)

Functional Layer

Subscriber Theater

Subscribers Figure 1 - Blackjack Operational Concept

For reference, Figure 2 represents a notional hierarchy of assembly for Pit Boss program elements and establishes the terminology used to describe each level. The information in Figure 2 shows an example of the items envisioned to be included at each level of decomposition of the System, Segment, Subsystem, and Component architecture. It is not meant to be prescriptive or exhaustive. Proposers will be expected to provide a more detailed decomposition in their proposals. If required, additional levels of decomposition may be added.

B. Program Overview

The Pit Boss performer will develop the overall autonomy architecture, constellation integration schema, and hardware and software components to enable a proliferated LEO satellite constellation to autonomously task, collect, process, exploit, and disseminate multi-sensor data and/or signals in support of warfighters across ground, air, and maritime domains based on objective-level tactical inputs from authorized users anywhere on the globe. The performer will determine what hardware and software elements are required to enable their proposed architecture (e.g. interface cards and/or computing platforms) and will be responsible for development of those elements and for working with the satellite integrator to ensure integrated system compatibility. The architecture will incorporate an open, modular, and scalable approach to facilitate rapid on-orbit software updates and implementation of new applications. The Pit Boss must be capable of self-tasking, distributed processing, dynamic reallocation of resources, and network management strategies that maximize on-orbit collected knowledge while minimizing distribution latency to manned and unmanned subscriber elements given cybersecurity and cryptographic requirements.

The Pit Boss should enable global persistence and awareness while simultaneously focusing attention on multiple specific geographical regions. Each of these regions will require Pit Boss to hand off mission tasks, objectives, status, and data as satellites rise and set over the horizon. The set of functional layer nodes engaged over a geographic region are defined collectively as an observation group (OG) or instantaneous orbital observation group (IOOG).

Pit Boss must be capable of taking data and target queue information from onboard and remote payloads, processing the data through performer or third party developed applications, and disseminating the data to the relevant subscribers via the CDDTL. Pit Boss must be capable of managing requests to and from the bus for bus services that include but are not limited to attitude and orbital controls, power subsystem information, bus telemetry and health/status, star tracker data, and dissemination of constellation, functional layer, and Pit Boss data via the CDDTL.

Figure 2 - Blackjack Assembly Levels (notional)

The program is divided into three phases (see Figure 3). 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 (this BAA) HR001119S00XX Satellite Integration (future BAA)

The notional Blackjack schedule is shown below in Figure 3.

Figure 3 - Blackjack Schedule

C. Design Reference Mission

It is envisioned that Blackjack nodes will operate near, or be proliferated within, a CDDTL with communications provided by a proliferated commercial (or commercially-derived) constellation in LEO. Blackjack nodes will not be an integral or required element of the CDDTL and will operate independently such that the loss of any or all Blackjack nodes will not degrade CDDTL commercial operations.

The long-term operational design reference mission for this BAA includes a functional layer of 60 to 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 operations center input 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, intelligence priorities, and subscriber data request prioritization. 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 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 to enable theater-wide demonstration of the Pit Boss system in any region of interest.

To facilitate assessment of the performance of proposed Pit Boss solutions, Pit Boss design reference information is provided in Appendices B and C. Appendix B (classified) includes a summary description of a representative set of mission scenarios. Appendix C provides additional reference information with a summary of representative bus and payload design parameters, including payloads for OPIR missile defense and RF-based PNT.

D. Management Approach

Pit Boss proposers should provide a description of their program and risk management approach. The approach should address how to ensure physical and functional compatibility between Pit Boss and the bus, payload, and third party software, through regular interactions and/or partnerships with those developers. The approach should also include the process for coordination of interfaces through regular interaction with the satellite integrator, including early definition of interfaces and establishment of open architecture standards. This process should describe how to provide interface definitions and design standards to potential hardware and software developers, including the Software Developers Kit (see section I.E, Technical Area 2) for third party software development. The process should also 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 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 (see section I.F, Development Plan) 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.

The overall approach for technology maturation should be described for all program phases, including the plan for incremental progression of Pit Boss demonstrations within program budget and schedule constraints while incorporating bus and payload models and prototypes. The management approach should describe the process for schedule management both for the performer and for any subcontractors, as well as coordination with any relevant bus and payload performers, in light of the complexity of integration of multiple program elements and participants.

E. Technical Focus Areas

DARPA has identified six key technical areas that collectively define the Pit Boss development program. The subsections below provide detailed descriptions of each of these areas.

The Pit Boss must balance functionality with space hardware development in the constrained realities of cost, performance, environment, resilience, and availability. The Pit Boss should meet the performance objectives provided in Table 2 - Pit Boss Performance Objectives

Table 2 - Pit Boss Performance Objectives

(Table 2 is included in Appendix A – Controlled Unclassified Information.)

Of specific note, Table 2 specifies the recurring cost objective for each unit for current and future contract quantities from the initial two flight spacecraft, through the 20-node stub demonstration (18 additional spacecraft), and up to the full functional layer quantity (expected to be on the order of 90 satellites). This will ensure the DoD can expand the constellation 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 spacecraft.

Technical Area 1 (TA1) - Mission Architecture for Proliferated LEO Space Order of Battle: DARPA is interested in the development of an extensible, scalable and adaptable mission architecture to achieve the objectives listed in Table 2. Under this technical area, Pit Boss network architecture approach, constellation- and functional layer-level data management, resource management, mission/target custody, and data dissemination will be defined. The mission architecture should address the following attributes:

Ability for Blackjack nodes to achieve mission objectives through autonomous collaboration with other nodes for tasking, decision making, data sharing and data fusion including data from other ISR sources, on-orbit, in-air, at-sea, and on-ground

Ability for Blackjack nodes to seamlessly and continuously handoff mission tasking from one satellite to the next logical satellite within the observation group to maintain constant custody or continuous action for a target or region

Ability for Blackjack nodes to transmit and receive commands and data with other nodes and system subscribers (e.g. tactical platforms, commanders, satellite managers) via the

CDDTL

Ability to support a range of functional layer sizes from 60 to 400 satellites Approach to interfaces between Pit Boss and the CDDTL; Pit Boss node to Pit Boss node; Pit Boss to ground control station; and Pit Boss to subscriber terminal Approaches that enable graceful mission degradation as a function of satellite loss Architecture approaches that maximize software commonality between multiple missions Open standards and approaches that permit third party applications with minimum interactions for integration Approaches that maximize data throughput to subscribers to meet a broad range of potential mission requirements Approaches that ensure a high quality of service Functional breakout of bus, payload, Pit Boss, CDDTL, and the human-machine ground interface Establish metrics for how the architecture performs in the mission scenarios (e.g., tasking availability, tracking custody, engagement range, latency, time transfer reliability and quality)

Technical Area 2 (TA2) - Multi-Mission Execution Software: DARPA is interested in development of flexible and modular software that can be applied to autonomously execute multiple different missions. Some functionality may support multiple missions (e.g., target handoff among Blackjack functional layer nodes, data management/dissemination, resource coordination) while other functionality may be mission specific (e.g. automatic target recognition). Proposed approaches should enable constellation-level autonomy and should meet the following performance goals:

Perform autonomous execution of the planned mission Perform autonomous constellation management (e.g., node health monitoring, orbit maintenance, node spacing) Enable constellation command and control, (e.g., a commander’s intent is uploaded to Pit Boss from a subscriber terminal, and the system autonomously identifies and commands a node or nodes to perform collection, processing, and dissemination for an area of interest)

Enable node-to-node collaboration to provide:

o Enhanced mission performance (e.g. stereo viewing to improve track accuracy) o Data processing and distributed data processing capability o Target handoff as nodes enter and depart the observation group to maintain constant custody o Payload data transfer to other nodes, to subscribers, and to command elements

Autonomously diagnose and respond to common system failures, such as loss of a node, while continuing to perform the planned mission

Provide data storage Host third party applications

This listing is not intended to be all-inclusive of Pit Boss software performance goals, and proposers should address any additional areas required to support autonomous mission execution.

Where possible, proposers should leverage bus and payload functionality in meeting the performance goals to reduce software complexity and cost.

SDK: Pit Boss proposers should describe their planned approach to development of a freely releasable SDK to support integration of third-party massless payloads. The SDK objective is to enable third-party software development to augment the capabilities of a functional layer (e.g., data fusion capability or automatic target recognition) by uploading to the functional layer after launch. The SDK will be an implementation of application programming interfaces (APIs) in the form of libraries to interface to the Pit Boss system and hardware-specific tools that can communicate with Blackjack nodes and subscribers. The toolset should include development environment tools enabling new massless payloads. The SDK must allow a third party to develop software for Pit Boss without support from the performer. The SDK should define standard software interfaces and open data formats.

Technical Area 3 (TA3) –HMSI: The HMSI provides a human interface to the Pit Boss software to support tactical subscribers, commanders, and satellite managers. Tactical subscribers require relevant tactical information, e.g. target track vectors, target location, and imagery directly from Pit Boss. Commanders require the ability to request a mission-specific service and provide mission priority, manage subscribers, and receive mission availability forecasts. The satellite managers require the ability to receive bus and payload health status, anomalies, and relevant telemetry and to provide corrective commands.

DARPA is seeking approaches to provide the human interface to the Pit Boss to enable constellation command and control, subscriber requests, and communication of telemetry and payload data. DARPA envisions this to be a ground-based terminal with a Pit Boss interface, linking to a functional layer for each of three types of users: subscribers, commanders, or satellite managers. Terminals require the necessary equipment and facilities, capable of handling data up to TS/SCI level, to support each user for the Phase 3 demonstration. User terminals providing up and downlinks into the functional layer via the CDDTL will be available for procurement. The approach should be scalable to accommodate up to 10,000 subscribers.

Additional direct links to nodes may be required for the demonstration. Approaches that seek to minimize facility and equipment costs (e.g., leverage existing commercial facilities) are highly desirable.

As noted previously, proposed approaches for management of the constellation must be designed for staffing by no more than two people whose primary function will be to provide the interface between Pit Boss and commander’s intent, intelligence priorities, and subscriber data request prioritization.

DARPA envisions each functional layer will be highly autonomous and capable of extended operations for up to 60 days, even if ground-based constellation management inputs are not available. Under these conditions, the constellation must continue to provide data to subscribers, and provide prioritization of subscriber requests. Furthermore, the functional layer must be capable of adapting to other degradation events during this period, such as subsystem failures on nodes. Proposals should address how this level of autonomy will be achieved and maintained.

Responses should describe the HMSI approach for the subscriber, commander, and satellite manager interfaces with consideration of the following capabilities:

Provide ability to easily define mission parameters and generate commands with minimal training

Provide the ability to set and rapidly update command hierarchy and mission priorities and the ability to prioritize commanders and subscribers requests based on the hierarchy and mission priorities

Provide ability to capture and display up-to-date health and status and ephemeris for the Blackjack functional layer and CDDTL

Access to other commercial, Government, or other intel data systems to ingest information that may fulfill the requestor’s intent

Provide ability to accommodate a wide range of satellite and phenomenology expertise levels of users (i.e., analysts, tactical users, and senior commanders)

Provide ability to request other non-primary mission functions such as Space Situational Awareness

Enable intuitive visualization of Pit Boss collection requests and functional layer status

This listing may not be all-inclusive of HMSI capabilities, and proposers should address any additional areas required to support the human interface with the system.

Technical Area 4 (TA4) – On-Orbit Computing Resources: High performance processing, memory, and bandwidth will be necessary to implement the autonomy/AI software with extensibility for future mission upgrades. DARPA is seeking innovative approaches to execute Pit Boss with strong consideration for the lowest recurring cost solution to the operational mission (e.g., hosted on the spacecraft bus, on the payload, or through a third-party computing system on the satellite). Solutions should address estimated computing requirements and the basis of estimates should be included in proposals. The performer will define their proposed on-orbit computing architecture and describe what hardware and software elements are required to enable their proposed architecture (e.g. interface cards and/or computing platforms).

Performers will be responsible for development of those elements and for working with the Satellite Integrator to ensure integrated system compatibility.

The performer should describe how the proposed elements support a zero integrator model. This is a design approach in which any Blackjack payload can 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. It is a system that defines and documents mechanical, electrical, network, and software interfaces sufficiently and with appropriate compatibility such that new buses, payloads, and autonomy software can be developed and flown without lengthy periods of design, integration, and testing (e.g., see Personal Computer (PC) standards for Universal Serial Bus (USB) and Wi-Fi system integration, which are now ubiquitous).

The computing resources approach should address the following:

Total required computing resources with consideration of available Pit Boss per spacecraft SWaP constraints defined in Table 2, Appendix A

Required memory resources with consideration of available Pit Boss per spacecraft SWaP constraints defined in Table 2, Appendix A

Ability to support third party applications and massless payloads Power consumption and duty cycle Extensibility to host new algorithms and mission threads, as they are identified post-launch Scalability to increase the amount of onboard computing resources (processor and memory) without redesign of the Pit Boss

Technical Area 5 (TA5) - Mission Demonstration through Live and Virtual Environments: DARPA is interested in innovative approaches to demonstrate mission architecture adaptability through an evolutionary modeling, simulation, and demonstration process. Proposers should describe a process for integration of the Pit Boss models with multiple bus and payload models in a mission demonstration environment to show mission function through a series of ground simulations, progressing to a full on-orbit demonstration event.

Approaches should address how the Pit Boss developer will work with the satellite integrator throughout this process with the objective of incrementally and progressively demonstrating a zero integrator model. The proposer will provide their software and hardware deliverables to the satellite integrator for integration into the demonstration environment and will provide mission architecture, engineering, integration and demonstration support throughout the process. Mission demonstration events will incorporate increasing technical sophistication, leading to the on-orbit checkout of two nodes, followed by a full demonstration of 20 spacecraft and payloads during Phase 3. These on-orbit demonstrations shall represent the full operational functional layer through virtual representations of bus and payload behaviors for nodes that are not part of the on-orbit stub. Bus and payload models will be available at their respective PDRs as defined in Figure 3.

Proposers should address how they will design the system to be adaptable to hardware and software developed in parallel with the Pit Boss architecture, and how they will address risk reduction early in the development efforts, while maintaining flexibility to integrate new buses and payloads into their architecture.