SDA-SN-21-0002 - BMC3 for Proliferated Space Architectures.pdf

Space Development Agency Integrated and Interoperable Battle Management, Command, Control, and Communications (BMC3) for Proliferated Space Architectures Request for Information

SDA-SN-21-0002

The Space Development Agency (SDA) seeks industry feedback on in-space and ground-based Battle Management Command, Control, and Communications capabilities to inform SDA's future solicitations, including the Tranche 1 solicitation(s) anticipated for Summer 2021.

Background

The Space Development Agency (SDA) was created in March 2019 to provide fast, responsive, resilient solutions to national security space requirements. Its focus is on the National Defense Space Architecture (NDSA), a "mesh network" of hundreds of satellites in several layers networked together. These layers provide missile warnings, air, ground, and surface object tracking; and other missile defense capabilities, including capabilities to detect and defeat the hypersonic missile threat. The goal is to make data available to the warfighter "at or ahead of the speed of the threat."

SDA is responsible for orchestrating the Department's future threat-driven space architecture and accelerating the development and fielding of new military space capabilities necessary to ensure U.S. technological and military advantage in space for national defense. To achieve this mission, SDA will unify and integrate next-generation space capabilities to deliver the NDSA, a resilient military sensing and data transport capability via a proliferated space architecture primarily in Low Earth Orbit (LEO).

The SDA mission, aligned with the National Defense Strategy (NDS), defines and delivers the Department's future resilient, threat-driven, and affordable military space architecture for the joint warfighter. With the NDS and the capability gaps identified in the DoD Space Vision guiding our thinking, SDA will continuously refine and prioritize activities to ensure U.S. leadership in space.

SDA's mission begins and ends with the warfighter. SDA recognizes that good enough capabilities in the hands of warfighter sooner may be better than delivering the perfect solution too late. SDA remains mission-focused and continues to make advances toward delivering the next-generation NDSA.

Awards have already been made for the Tranche 0 transport layer and the tracking layer. This RFI seeks to inform the Battle Management Command, Control, and Communications (BMC3) Layer.

BMC3 BACKGROUND:

The SDA Battle Management Layer will provide the hardware and software framework to host mission-specific processing, algorithms, and applications across the architecture layers and systems. Supported use cases will include space-based command and control, tasking, and mission processing. Processed data will be routed across a mesh network through cross-links and down-links to enable timely dissemination to both the warfighter and other systems in the architecture. BMC3 will continuously address evolving threats and mission needs through on-orbit updates to hardware/firmware with each tranche delivery and on-orbit updates to flight software throughout the lifecycle of each tranche.

SDA's Battle Management Layer (BMC3) is exploring technical areas including, but not limited to:

• Low-latency on-orbit mesh networks,

• Distributed command and control,

• Advanced human-computer interfaces for Battle Management and information dissemination,

• Automated mission-plan optimization and sensor tasking,

• Onboard processing algorithms,

• Software architectures that enable task migration and on-orbit upgrades,

• Trusted autonomy and artificial intelligence,

• Enhanced cybersecurity, DevSecOps, and secure updates,

• Improved performance and minimized size, weight, and power of onboard processing hardware

• Improved modularity and interoperability of battle management functionality

• Training concepts and methodologies for operational support,

• Improved tasking and exploitation of delivered planning and intelligence products,

• Management of multiple heterogeneous computing architectures, and

• Improved strategies for data retention and task migration between in-orbit and ground processing platforms.

The SDA satellite constellation is a set of heterogeneous nodes controlled and managed by the on-orbit and ground-based BMC3 computer hardware and software. On-orbit nodes have limited size, weight, power (SWaP), compute resources, and communication bandwidth. Data rates between nodes are likely to be less than between terrestrial data centers. Connectivity between nodes is not necessarily continuous, so the software platform will need to be partition and data loss tolerant. At any point in time, the SDA constellation may include nodes from multiple "tranches" with different hardware and software capabilities.

SDA's long-term vision for BMC3 is to remove access to situational awareness, operational decision support, and execution of the commander's decisions as latency drivers for time-sensitive kill chains. Ideally, the time needed to execute a given kill chain should be driven entirely by the time it takes for a commander to authorize weapons release and the weapon's (or weapons') engagement time. SDA believes resilient, space-based sensing, data transport, and BMC3 are enablers for this vision.

To implement this vision for BMC3, SDA intends to deploy a constellation that will incorporate increasing autonomy levels with increasingly less reliance on the ground system. The constellation will also provide increasing support and automation of operational planning tasks.

On a practical level, this means that most functions customarily performed on the ground need to migrate into space over time. In its mature state, the SDA constellation will need a high degree of automation and autonomy. A mature BMC3 will have the capability to schedule SDA resources and deconflict tasking requests autonomously by following a pre-established set of policies and practices.

For a Tranche 1 BMC3 capability, SDA is still exploring the trade space but anticipates seeking hybrid ground-based/space-based (threshold) and primarily space-based (goal) solutions for both constellation operations and mission operations. Mission operations may include dynamic mesh network planning and routing; tactical data link message set generation; OPIR- or ISR-derived track fusion and targeting solution development; and experimental testbed for other BMC3 applications using organic or offboard data sources.

SDA's Request for Information (RFI)

While generic Statement of Capabilities provides helpful context for industry responses, SDA is explicitly seeking the following information to inform future solicitations and reduce risk toward battle management interoperability within the SDA architecture and development plans. SDA strongly encourages the industry to provide feedback to these specific areas.

BMC3 Technical Challenges

Industry feedback is critical to better inform SDA on current and innovative approaches to developing the BMC3 hardware and software.

1. Provide a brief background on your company, including if U.S. Owned, and your experience with the types of architectures, systems, algorithms, and hardware needed to implement BMC3 capability. Could SDA engage your company through any existing contracting vehicles (e.g., GSA Schedule, Block Purchase Agreements, or other contracts open to engagement via the Economy Act)?

2. What is your experience with agile contracting or developments that support frequent delivery of functional capability, mitigate risk via continuous integration, test, and user feedback, and provide enhanced visibility into contract execution performance?

3. How would your company approach an open architecture implementation of BMC3 capability, both hardware- and software-based? Does your company have any experience with DoD and space domain software open frameworks relevant to hosting hardware-agnostic applications? If so, what was the maturity level of the framework (proof of concept/lab prototype; inclusion into a developed or developing system; use in an operational system)?

4. Does your company have models, simulations, modeling capability, or implemented systems that can help determine needed system resources such as space, weight, power consumption, and heat dissipation? Describe what this modeling or actual system implementation determines as feasible in terms of computational capacity and cost.

5. How would you address the design and development of a space-based, open architecture distributed synchronized database? What challenges do you envision, such as node or network segmentation and recovery? Does your company have models, simulations, or modeling capability to help determine network capacity, in particular network capacity for mesh networks? Do you have an estimate of the resources (e.g., processing power and bandwidth) that would be required to establish and maintain the multi-platform, open architecture framework, or a distributed synchronized database?

6. What approaches would you consider in the development of a multi-satellite distributed dynamic processing architecture? How would you structure and manage process and task migration between platforms? What approaches to hardware, firmware, and operating system support would you consider to enable and support these capabilities?

How would you manage updates, process, and task migration between on-orbit and ground platforms? What challenges, risks, or issues do you see in developing and deploying practical algorithms for fusing data from multiple sensor types and sensors on-orbit or in a hybrid on-orbit/ground architecture? How would you address mitigating these items?

7. What challenges do you see in developing and evolving a secure, cyber-resilient space system? Consider technologies new or novel to the National Security Space domain, such as mesh networks, artificial intelligence/machine learning, advanced on-orbit re-programmability, on-orbit process/task migration, and autonomy in your response.

8. Does your company have HWIL/SWIL, constructive simulation systems, or other technologies and capabilities to support critical system testing of BMC3 components?

Describe how you would apply these capabilities to BMC3's unique on-orbit and ground-based systems.

9. In terms of orders-of-magnitude estimates, how would you quantify the cost and schedule necessary to meet the capabilities you have described? Where do you see the most significant risk in these estimates?

10. What risk reduction activities would you propose to position BMC3 for long term evolution (Tranche 2 and beyond)?

BMC3 Acquisition Challenges

SDA intends to develop a BMC3 module with the functionality as described elsewhere and seamlessly integrate those modules amongst all T1 space vehicles (SVs), be they dedicated NDSA nodes (e.g., Transport T1 SVs) or aboard NDSA-contributing nodes (e.g., Government or commercial mission partner sensing satellites). For dedicated NDSA nodes, SDA is exploring the trade space for acquiring these BMC3 modules, including 1) specifying the BMC3 hardware and software architecture within the requirements of those SVs (i.e., as part of the same RFP),

2) acquiring the BMC3 hardware and software architecture in a standalone soliciting and providing the modules and integration support as Government-furnished material, or 3) a hybrid approach where either the hardware or software architecture is specified, and the other is separately procured.

1. What is your company's ability to support these acquisition approaches, any preference, and why?

2. What key challenges and risks do you associated with any of these acquisition approaches, including schedule, cost, and technical challenges and risks? What are the existing or likely mitigations for these risks and challenges?

3. What should be the current TRL for candidate hardware architectures and candidate software architectures to be considered viable? What are your company's plans to mature TRL with current development programs or initiatives?

4. Assuming a plan to mature to TRL = 9 during the BMC3 T1 program, what is a Rough Order of Magnitude (ROM) first unit cost, including all Non-Recurring Engineering costs of your company's envisioned product?

5. What are your company's ROM recurring cost and manufacturing capacity (i.e., number of units producible during BMC3's T1 program) estimates? What do you consider to the supply chain limiting factors?

6. How would you characterize functional and interoperability test and verification approaches for any or all of these acquisition approaches? Does any approach provide for significantly higher risk, if so, how? Are there test and verification approaches that could minimize these risks? What are the cost and schedule impacts induced by these mitigation approaches?

7. Given SDA's desire to support open architectures and non-traditional DoD performers, what standards, methodologies, processes, policies, and contracting approaches should we consider?

Responses to this RFI will inform SDA's Transport Tranche 1 solicitation in Spring 2020 as well as future SDA solicitations related to NDSA capabilities. Additionally, information obtained from this RFI will be shared with the OUSD(R&E) Fully Networked Command, Control and Communications (FNC3) Directorate.

SUBMISSION INSTRUCTIONS

• All responses to this RFI must be received no later than 5:00 pm (Eastern) on Friday, 8 January 2021.

• Responses are limited to no more than 8 pages and shall use a minimum of 12-point font and 1 inch margins.

• Responses shall be sent electronically to:

osd.pentagon.ousd-r-e.mbx.sda-sn-21-0002@mail.mil

• Responses to this notice shall include Vendor's Company Name, Address, and Contact Information.

• When submitting a response, please use the subject "SDA T1 BMC3 RFI Response

- [Vendor Name]".

• Any responses submitted through different channels or to a different email address will not be considered.

• Organizations are encouraged to limit to a single response.

• If a vendor would like to include classified information, please submit an unclassified response as requested with a classified addendum. Contact the above mailbox for classified submission instructions. Please indicate the classification level desired.

Classified addendums are subject to same submission deadline but are further limited to one page in length, 12 pt. font.

DISCLAIMERS AND IMPORTANT NOTES

This announcement contains all information required to submit a response. No additional forms, kits, or other materials are needed. This is an RFI issued solely for information and planning purposes; it does not constitute a formal solicitation for proposals. In accordance with FAR 15.201(e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Submission of a response is strictly voluntary and is not required to propose to a subsequent SDA solicitation. No solicitation exists; therefore, do not request a copy of the solicitation. If a solicitation is released, it will be synopsized on the Federal Business Opportunities website. It is the responsibility of any potential offerors/bidders to monitor this site for release of any solicitation or synopsis. The SDA will NOT provide reimbursement for costs incurred in responding to this RFI or participating in any subsequent workshop. SDA will acknowledge receipt of all submissions but is under no obligation to provide feedback.

To the maximum extent possible, please submit non-proprietary information. If proprietary information is submitted, it must be appropriately and specifically marked. It is the submitter's responsibility to clearly define to the Government what is considered proprietary data. Any proprietary information should be clearly labeled as "Proprietary." The SDA will not publicly disclose proprietary information obtained as a result of the RFI. To the full extent that it is protected pursuant to the Freedom of Information Act and other laws and regulations, information properly identified by a respondent as "Proprietary" will be appropriately controlled.

Submissions may be reviewed by Government personnel and support contractors bound by appropriate non-disclosure agreements. Responses to this RFI will not be returned. Intellectual or other privileged or proprietary information contained in responses to this RFI will not be distributed outside of the Department of Defense or United States Government employees from other Government agencies who are working with the SDA on this RFI. Respondents are advised that the SDA is under no obligation to acknowledge receipt.