Attachment 2 - Additional Custody Layer Reference Material.pdf

i

Attachment 2 -

Additional Custody Layer Reference Material

Broad Agency Announcement (BAA)

Space Development Agency (SDA)

Mission-Specific Application Prototypes (MSAP)

HQ085020S0002

June 26, 2020 ii

A. Automation Levels

B. Guidelines for high-consequence decisions across SDA assets

C. Fusion Levels

D. Tips/Cues

E. Additional guidance for proposal submissions

F. Objectives and Emphasis Areas for SDA Custody Mission (TBR)

G. Suggested Response Format

H. Top Level Requirements (TBR)

I. Functional Block Diagram (TBR)

A. Automation Levels

• Manual Control: In support of decisioning humans perform all activities including monitoring, selecting an option, and implementing it.

• Facilitated Control: In support of decisioning, humans perform all the decision-making activities with machine assets performing data input, manipulation, visualization, and decision-implementation.

• Human-in-the-loop (HiL) Control: In support of decisioning, both the human and machine assets generate options, the human controls selection; and the machine assets mainly perform decision implementation.

• Human-on-the-loop (HoL): Control in support of decisioning is mainly done by machine assets, with human option selection oversight / override within some time period if necessary.

• Autonomous with Override: Control in support of decisioning is performed by machine assets, with human ability to halt decision flow and allow the system to degrade to a lower level of automation to avoid catastrophic failures.

B. Guidelines for high-consequence decisions across SDA assets

SDA will use fusion and sense-making throughout their systems. Given this, it is important for high-consequence decisions made across SDA assets to follow several key guidelines.

1. Assume humans provide all weapon release decisions

2. High-consequence decisions must be based on high-confidence solutions; confidence in an indicator dictates the level of consequence one can invoke

3. Fusion and sensemaking applications must be periodically and episodically reviewed to maintain relevance in the hyper-turbulent context (i.e. fusion algorithms need to be modular and updatable)

4. All inputs/outputs need to use Application Programming Interfaces (APIs) to expose information and ensure ease of access

5. Diverse sources and combinations should be available to ensure options. If you use one set of features for a threat or over-tune an algorithm on one feature, the adversary may get rid of that feature and then the algorithm no longer works. An algorithm needs a diverse set of features that triggers it to detect targets and allows it to be resilient

6. All data is stored on the ground for anomaly investigations, training, validation, and research/testing

7. Tip/Cue rules need to be validated and kept current. The tips can be any indicator type and the cues can be any requests of action the system can perform. Rule sets are configuration managed after verification and validation

8. All algorithms must be trained, verified, validated, and flight-qualified before operating in space or on the ground to ensure trusted stable operations

9. All indicators cannot reveal information about US citizens

10. All fusion products must be consistent with the security levels and classification of systems that produce or use them.

C. Fusion Levels

Figure 1 shows the Data Fusion Model maintained by the Joint Directors of Laboratories (JDL) Data Fusion Group, which is the most widely-used method for categorizing data fusion-related functions. Following Figure 1, the SDA Custody layer will use fusion algorithms ranging from Level 0 fusion combining sub-object data with other sensing phenomena through Level 3, and eventually combining impacts to Level 5 including human interaction (recently added to the JDL fusion standard and not depicted in the figure).

Figure 1 - JDL Data Fusion Standard - data fusion: a process of integrating multiple data sources to produce more consistent, accurate, and useful information than that provided by any individual data source.

The more detailed fusion level definitions are defined as such:

• Fusion Level 0: Sub-Object data assessment that includes estimation and prediction of signal/object observable states based on pixel/signal level data association and characterization. Also known as source pre-processing

• Fusion Level 1: Object Assessment that includes identification of objects, estimation and prediction of entity states based on observation-to-track association, continuous state estimation (e.g., kinematics) and discrete state estimation (e.g. target type and ID)

• Fusion Level 2: Situation/Behavior Assessment: estimation and prediction of relations among entities, to include force structure and cross force relations, communications and perceptual influences, physical context, etc.

• Fusion Level 3: Impact Assessment: estimation and prediction of effects on situations of planned or estimated/predicted actions by the participants; to include interactions between action plans of multiple players (e.g., assessing susceptibilities and vulnerabilities to estimated/predicted threat actions given one’s own planned actions)

• Fusion Level 4: Process Refinement: adaptive data acquisition and processing to support mission objectives

• Fusion Level 5: User Refinement (or Cognitive Refinement), while not included in the JDL Fusion Levels has been added to allow for human interaction in the fusion process

D. Tips/Cues

• Tip – an indicator (i.e., leading, co-incident, or lagging) o Indicator, co-incident - a feature or attribute that changes at the same time as a desired event or state change, providing insight into the current event or state.

o Indicator, lagging - a feature or attribute that changes after a desired event or state change, allowing identification of changes and past history to support status quo pattern of life development o Indicator, leading – a feature or attribute that changes prior to a desired event or state change, allowing short term predictions.

• Cue – a prompt for action that the given system(s) can perform

Resultant cues could be:

1. Fused data is ready to be transported to the tactical edge

2. Request more data to improve the confidence and quality of the fused data to an acceptable level, or

3. Request data is sent to the ground to resolve the issues with the fusion since it does not satisfy the confidence and/or quality necessary for a firing solution

E. Additional guidance for proposal submissions

• Prospective respondents to this solicitation who can only offer partial solutions are encouraged to team to propose a comprehensive end-to-end solution.

• Proposals should address the human, data and equipment resources required to develop, test, and improve software to eventually migrate identified functionality to space.

Requests for GFI or GFE may be submitted but satisfaction of these requests is subject to availability of the requested items and government funds.

• Proposals should assume support to a Capstone demonstration envisioned to occur in 2nd through 3rd Quarter Fiscal Year 2023 in their writing of the CONOPS.

• Proposals should address the proposer’s plan to conduct risk mitigation to include equipment, human, and monetary resources for ground and, if possible, on orbit testing in advance of the Capstone demonstration on surrogate flight platforms should they be chosen to further develop the prototype in this BAA.

• Proposals should address the all-weather capabilities of the proposed solutions to maintain track of surface and low altitude targets. All-weather refers to the capability to sense to the ground under most common weather and lighting conditions sufficiently to support military operations (understanding that the most common weather and lighting conditions are different both between Combatant Commands and within Combatant Commands). As an example, RF and SAR are all-weather sensing modalities because of their ability to sense through clouds day and night. EO is not necessarily all-weather because of the inability to see through clouds. IR can sense to the ground at night but can only resolve temperature differences – a partial limitation to the support of military operations. All-weather multi-INT fusion must incorporate at least one sensor data source that senses to the ground under most common weather and lighting conditions.

The final multi-INT fused result must be sufficient to support specifically identified military operations to include specific weapon systems.

• Proposals should address any familiarity or past experience with the functions of the NIFE, particularly as it relates to integrating with and improving upon current NIFE capabilities. Proposers should include as much detail as possible about their knowledge of the NIFE and its operations as well as a discussion of the feasibility (including schedule feasibility) and benefits of their proposed improvements. If necessary, this discussion can be included in a classified addendum to the proposal.

• Proposals should address familiarity or experience with compliance, legal and data source regulations for dissemination and usage of Title 10 and Title 50 data.

• Proposals should address experience with echelons of Fires, operational law, rules of engagement and support of multiple warfare domains and Time-Sensitive Target/Dynamic target bases.

• Proposals should discuss ability to integrate with existing Sensor to Shooter and Tactical Targeting Programs throughout the DoD and IC. This includes an understanding of network communications, data classification and interpreters, including cross domain solution’s and S2S timeline for useable data flows.

• Proposals should discuss technology advancements including autonomous next generation analytics software technologies (AI/ML) to complete the intelligence cycle with increased speed, precision, accuracy and responsiveness of targetable data to dramatically improve the ability to identify and locate targets at extended ranges with increased fidelity

F. Objectives and Emphasis Areas for SDA Custody Mission (TBR)

• All-weather sensing phenomenology to locate and maintain track of surface and low altitude targets

• Sensor collected data timeliness short enough to support geolocation and track leading to a weapons quality firing solution

• Ability for identified candidate algorithms for spaceborne data fusion to be encoded to flight-SW.

• Maximized flexibility for the SDA government customer to have data rights for use in the SDA ground and space architecture

• Minimization of resources required to host candidate algorithms coded for spaceborne processor applications

• Adequate contractor facilities and environment for algorithm and software development, test and support of a Capstone demonstration in 2nd or 3rd Qtr FY2023

• Access for SDA support FFRDC advisory and IV&V support interaction

• Adequate modeling and simulation capabilities supporting the contractor’s data fusion activities

• Early identification of contractor desired GFI or GFE which will be subject to availability of the requested items and the availability of government funds

• Early identification of data required for Artificial Intelligence or Machine Learning to train algorithms for data fusion

• Identification of data bases and any other information needed to be hosted in space required to support spacecraft on-board data fusion

• Efficient storage of heterogeneous sensor data and maintenance of data provenance

G. Suggested Response Format

Algorithm Vignette Algorithm

Description Algorithm Classification

Intended Weapons System

Data Inputs/ Phenomenology

Onboard Databases

Fusion Level

Automation Level

Algorithm (Cont.)

SW/HW/Data Dependencies

Estimated

SLOC

Programming Language

OS Data Rates

Data Pre-processing

Output Type

Output Format

Table 1 – Algorithm Definition

Algorithm Validation Validation Techniques

Data Required False Alarm Rate

Probability of Detection

Receiver Operating Curves

Geolocation Capability

Modeling and Simulation Capabilities

Table 2 – Algorithm Validation

Enabling Tracking of Left-of-Launch Time-Sensitive Targets Location Accuracy (weapon/scenario dependent) Time Resolution (weapon/scenario dependent) Minimum Resolvable Size Daytime/Nighttime Target Dynamics Number of Targets Duration to Keep in Track

Table 3 – How fusion application enables tracking of Left-of-Launch Time-Sensitive Targets

Ground Processor Unit Description Processor Processor

Heritage Memory Storage Clock

Rate Volume Weight Power

(Nominal/ Peak)

In-Space Processor Unit Required Processor Processor

Heritage Memory Storage Clock

Rate Volume Weight Power (Nominal/

Peak) Radiation Tolerance

Table 4- Ground and In-Space processor units required

H. Top Level Requirements (TBR)

These requirements reflect the current state of the government’s thinking and are provided to stimulate a response in the proposals. Items in bold pertain to the interests of the Government for the Custody Layer for this particular BAA. Justified alternatives may be proposed where the government has driven an implementation or added unnecessary cost.

ID

Req.

Level Name Requirement

Explanation/ Justification Parent

CUST 1 0

24/7 Space- Based Surveillance

Custody Layer shall provide TBD duration (24/7 by Tranche 2) all-weather Custody of time-sensitive, surface (terrestrial, maritime and airborne) mobile targets left-of-launch (Threshold)

Mission - 24/7 coverage.

Threshold from ground/HWIL, objective from space

CUST 2 1

Sensor Partnerships

Custody Layer shall develop partnerships with IC and DoD tactical-ISR providers to ensure coverage in AOI of tactical importance to the warfighter (Threshold)

Custody will not be fielding its own constellation CUST01

CUST 3 2

Sensor Partners to Ground-based Custody App

Support Layer shall provide infrastructure to transmit data from Custody sensor partners into the Custody Ground Application up to the

SECRET

classification level either via media (Threshold) or direction connection (Objective)

Sensor partner data needs a method to be transmitted to the ground-based Custody application for fusion. The classification will depend on the data the sensor partners provide which is currently TBD, but for Tranche 0 Custody will choose performers at no greater than a SECRET level. Custody may own the Threshold requirement CUST02

CUST 5 2

Sensor Partners to Custody

HWIL/SWIL

Support Layer shall provide infrastructure to transmit data from Custody sensor partners into the Custody HWIL/SWIL development facility up to the SECRET

Sensor partner data needs a method to be transmitted to the HWIL/SWIL facility where the space-application will be developed. The classification will depend on the data the sensor partners provide which is currently

CUST02

classification level either via media (Threshold) or direct connection (Objective)

TBD, but for Tranche 0 Custody will choose performers at no greater than a SECRET level. Custody may own the Threshold requirement

CUST 7 2 Data Lake

Custody Layer shall procure TBD quantity of storage at the TS//SCI, SECRET and U//FOUO levels for partners to store their data lake with training/test data sets (Threshold)

The Multi-INT fusion algorithms will need to be trained and tested with appropriate data sets corresponding to the phenomenologies of interest. There needs to be a place to store these data sets on the ground. Since data can originate from NTM assets, the capability to store up to the TS//SCI level will be required. CUST02

CUST 8 2

Data Lake to Ground-based App

Custody Layer shall establish a TBD data rate terrestrial connection from the data lake to the Custody ground application at the

TS//SCI, SECRET

levels and U//FOUO levels (Threshold)

Data will need to be transmitted from the data lake to the ground-based Custody application for fusion processes. It is expected that data will go up to the TS//SCI classification level. CUST02

CUST 9 2

Data Portals to Data Lake

Custody Layer shall establish a TBD data rate terrestrial connection from data portals to the data lake at the TS//SCI, SECRET and U//FOUO levels (Threshold)

Data from the Commercial portal needs a method of transmission to the Data Lake where it will be used for training and testing purposes and as a backup for fusion development and demonstration. CUST02

CUST 10 2

Data Provenance Fusion Watchdog

(FIDDO)

The Multi-INT Fusion ground-application shall implement a fusion watch-dog (Fusing Incorrectly Double-

It is crucial to understand what collection platform data is collected on especially if data is fused from multiple partners to include the Custody Fusion

CUST02

counted Data Outlawed - FIDDO) to maintain provenance of sensor data up to the TS//SCI level and ensure data is only used once for the fusion solution (Threshold) partner. A situation could arise where the same data is being incorporated multiple times from different partners and this needs to be avoided to not skew the fusion solution

CUST 11 2

Fusion Partners to FIDDO

Custody Layer shall establish a TBD data rate terrestrial communications link(s) to send data from Custody fusion data partners to FIDDO up to the TS//SCI level (Threshold)

Custody Layer will connect partner data to the ground application and will also use data to develop its own fusion capabilities that will be migrated to the space-based application. This data is expected to go up to the TS//SCI level to account for provenance of the data which could have TS//SCI level meta data associated with it. CUST02

CUST 13 0

Tracking and Targeting

Custody Layer shall enable the creation of an all-weather firing solution for an advanced weapons system (Threshold)

Mission - creation of firing solution for 24-7, all-weather environments

CUST 14 1

Multi-INT Fusion

Custody Layer shall demonstrate Multi- INT fusion to a level of fidelity to enable creation of kinetic target nominations (Threshold)

To enable the generation of a weapons-quality firing solution, a Multi-INT Fusion capability will need to be procured CUST13

CUST 15 2

Ground-application

Custody Layer shall partner with a ground-based Multi-INT Fusion application to perform more computationally intensive applications (Threshold)

Custody fusion partner has already demonstrated fusion on ground CUST14

CUST 16 3

Collocation of Ground-Based Custody App

Custody Layer shall provide a facility with TBD amount of storage for the ground-based Custody Application at multiple levels of security up to TS//SCI (Threshold)

The ground-based Custody application will need a space to live in. The data flowing to the ground-based application is expected to go up to the TS//SCI level with the potential partnership with

NIFE. CUST15

CUST 17 2

Space- Application

Custody Layer shall migrate the Multi-INT Fusion capability to a space-based application onboard a Smallsat form factor in stages (Objective)

Objective to migrate capabilities to space for resiliency and potential reduction in latency from sensor to shooter CUST14

CUST 18 3

Developing Ground-Based support for Space-App

Custody Layer shall develop a ground-based Multi-INT fusion capability that can handle up to the SECRET level in support of space-application development (Threshold)

For the eventual migration of the fusion capability to space, the fusion performer will begin by further developing its algorithms on the ground where they will train and test their models. Data used for these purposes will need the option to go up to the SECRET level CUST17

CUST 19 3

Developing Space- Application

Custody Layer shall develop a space-based Multi-INT fusion application that can handle up to the SECRET level (Threshold)

The Multi-INT fusion space-based application will need to first be developed on the ground with the support of the ground-based application, then trained, tested, validated and locked down before migrating to space CUST17

CUST 20 4

Enabling Targeting Solution

The Multi-INT fusion application shall enable a weapons quality targeting solution with a CEP of TBD accuracy for TBD weapons system

For a weapon to be able to fire upon a target, a weapons quality targeting solution needs to be generated. Goal is for the space application. CUST19

(Threshold ground/Objective space)

CUST 21 4

Demonstrating Response to Tip/Cue

The Multi-INT fusion application shall demonstrate response to tipping/cueing and enable re-tasking of collection platform sensors to include simulation capability (Threshold ground/Objective space)

To maintain Custody of a target and provide further fidelity to the generation of a geolocation, there needs to be a capability to tip/cue collection platforms for further data collection.

Goal is for the space application CUST19

CUST 22 5

Tip/Cue Interface

The Multi-INT fusion Tip/Cue capability can follow the common sensor interface standards defined in the All- Domain Overhead Cooperative Operations AOCO Joint Interface Control Document (JICD) to be able to access geolocation data (Threshold)

The AOCO program SIGINT repository can be utilized to increase geolocation accuracy CUST21

CUST 23 3

Provision of Test and Training Data

The Multi-INT Fusion application shall have separate test and training data (Threshold)

The Multi-INT fusion performer will need to train and test its algorithms and should thus come prepared with data its familiar with or ask for GFI CUST17

CUST 24 4

Commercial or Simulated Data

The data for fusion processing development can be commercial or simulated (Threshold)

Sensor data for algorithm development can be commercial or simulated to start CUST23

CUST 25 4 NTM Data

The data for fusion processing development shall be NTM data (Objective)

The eventual objective is to utilize NTM data for fusion processing CUST23

CUST 26 4

All-weather Sensor Data

The Multi-INT Fusion capability shall implement all-weather sensor phenomenology data for processing development (Threshold)

To demonstrate fusion and generation of a targeting solution 24x7, all-weather data needs to be provided CUST23

CUST 27 3

HWIL/SWIL

Facility

The Multi-INT Fusion algorithms shall be tested in a performer-provided HWIL/SWIL Development Facility at the SECRET level of security (Threshold)

Initially, the Multi-INT Fusion performer will need to develop and test their space-based application in a flight-like environment CUST17

CUST 28 4

Provision of Flight-Like

HW

Multi-INT fusion algorithms shall be integrated into flight-like HW provided by the performer by TBD date to perform testing in time for the Capstone (Threshold)

The Custody and Transport performers will need to work together to ensure that an additional code to be added into the flight SW is safe and doesn't crash the satellite CUST27

CUST 29 3

Conversion of Custody App to Space

Custody Layer shall use the Transport Layer provided SDK to convert its space-based Multi-INT fusion application into flight code (Objective)

Transport Layer's performers will be developing the flight HW and SW and thus Custody's space-based application will need to be incorporated into representative HW that the Custody performer purchases, but may need support from Transport performer to ensure it is comparable. CUST17

CUST 30 4

Verification of Code

Transport/BMC3 Layers will verify the conversion of the Multi-INT fusion space-application in to flight SW (Objective)

It is imperative that the code be validated prior to pushing it up to the performer's space vehicle CUST29

CUST 31 4

Pushing Code Onboard

Transport/BMC3 Layers will push the Multi-INT Fusion space-application flight code onto the Transport space vehicle (Objective)

Once the code has been validated by the Transport performer, it will actually need to be pushed onto the

SV CUST29

CUST 32 3

IV&V of Fusion Algorithms

The Multi-INT Fusion capability shall go through IV&V (Threshold)

It is imperative before migrating the fusion algorithms to be used on a space vehicle that they be verified and validated to ensure that they work properly especially since the eventual objective will be a machine to machine interaction to fire upon a targeting solution.

Furthermore, as algorithms are updated, there needs to be regression testing performed that ensures the capability still performs as expected. CUST17

CUST 12 1

Ground App to Space App

Custody Layer shall provide a TBD data rate terrestrial connection from the Custody Ground- Application (Threshold) directly to the Custody performer-provided HWIL/SWIL facility at the SECRET and U//FOUO levels and Support Layer shall provide a TBD data rate terrestrial

Data from the ground application needs to be available for training and testing purposes for the space-based application.

Since the HWIL/SWIL facility is flight-like, it will only go up to the SECRET level. if we’re unable to put the Custody application in space, with the HWIL/SWIL connected through the Support Layer, we can simulate the space-based capability and “capture the

CUST13

connection from the Custody Ground Application (Objective) through its network to the Custody performer-provided HWIL/SWIL facility at the SECRET and U//FOUO levels way we fight” as Carl mentioned in our original telecon. So, for instance, we could ingest partner data either via a disc or real-time, send that to the HWIL/SWIL for data fusion and the resulting solution would be sent via the Support Layer to the Transport Layer for dissemination to the tactical edge.

CUST 33 0

Sensor to Shooter Data Delivery

Custody shall provide critical tactical target data to the warfighter within a TBD latency (Threshold)

Mission - getting data to tactical edge

CUST 34 1

Ground-Based Custody App Interface to Support

Support Layer shall provide an interface for the ground-based Custody application to its SW at SECRET and lower classified levels (Threshold)

The ground-based Custody application will need to interface with the Support Layer's ground software to be able to transmit fusion solutions which are expected to match the Transport Layer's SECRET classification environment. CUST33

CUST 35 1

Targeting Solution to Tactical Edge

Transport Layer shall disseminate Custody's targeting solutions to the tactical edge (Threshold)

The objectives of the Custody layer is to disseminate timely targeting solutions from sensor to the tactical edge. This will be enabled by the Transport Layer. CUST33

CUST 36 2

Converting Data to Link-

16/IBS

Custody Layer will provide the capability to generate Custody data based Link-

16/IBS (TBR)

messages (Threshold)

Data will be sent to the Transport Layer via Link- 16/IBS messages and Custody needs a method to generate such messages CUST35

CUST 37 2

Transmission from Ground to Transport

Support shall provide proper transmission formatting of Custody-created data and transmission from

Data needs to be properly formatted to be transmitted from the ground terminals to the Transport Layer. For Tranche 0, Transport Layer

CUST3

ground optical or RF terminals to the Transport Layer at SECRET or lower classification levels can accommodate data up to the SECRET level which Custody will have

I. Functional Block Diagram (TBR)

Figure 2 shows a potential Functional Block Diagram (FBD) that is consistent with the requirements given in the previous sub-section. It is again provided to stimulate a response in the proposals. It is not the only architecture possible, but it illustrates the complexity of the Custody mission. Custody performers are not required to follow this FBD in whole or in part. It is provided as reference material to show the government’s latest thinking regarding a potential architecture to meet the Custody mission. Justified alternatives may be proposed where the government has driven an implementation or added unnecessary cost.

The functional blocks and links are color-coded by the SDA functional cell (refer to the figure legend) but they do not necessarily imply a physical architecture. Blocks and links that correspond to the requirements provided in the previous sub-section are labelled with the appropriate requirement ID. Requirement IDs that are bolded (and underlined for enhanced visibility) in this figure correspond to the bolded requirements. Major sections of this FBD include functions and links housed within a Ground-based Custody Application Host Facility that focuses on providing target quality fused sensor outputs (orange block in the center of the figure), a HWIL/SWIL Development Facility focusing on the in-space multi-INT application (orange block on the right of the figure), sensors supporting the NIFE (partnering discussions are still on-going and have not yet been finalized), sensors and fusion capabilities from partners other than the NIFE, and finally ground- and space-based SDA assets.

Options for risk mitigation are highlighted in black and magenta boxes with dashed lines. Options that could contribute to Custody’s realism risks in the Tranche 0 Capstone include using canned or playback data to stimulate ground-based, HWIL/SWIL, or space-based multi- INT fusion applications (magenta dashed boxes labelled (e), (f), and (g)). The use of such data is not precluded in any potential functional designs for the Tranche 0 Capstone, but they do contribute to increased Tranche 0 realism risks. Potential mitigations for these realism risks (black dashed boxes, labelled (b), (c), and (d)) focus on real-time networked connections between sensors and the multi-INT fusion applications running either on the ground, HWIL/SWIL facility, or in space. These mitigation options can reduce the Tranche 0 Capstone realism risks at the expense of increased complexity which can introduce risks of their own.

Potential Tranche 1 risk mitigations could include the integration of other ground-based multi- INT fusion capabilities (black dashed box labelled (a)) in addition to the NIFE which could result in a more robust Custody capability but which could also introduce other risks.

Figure 2 - Custody Functional Block Diagram