SDA BMC3 App Factory RFI.pdf

Space Development Agency Application Factory for Battle Management, Command, Control, and

Communications (BMC3) for Future National Defense Space Architectures

Request for Information

SDA-SN-22-0007

The Space Development Agency (SDA) seeks industry feedback on approaches to establishing an Application Factory to support space and ground based BMC3 software capabilities to inform future solicitations.

Background

SDA was created in March 2019 to provide fast, responsive, and resilient solutions to national security space requirements. Its focus is on creating additional space layers of capability that will provide for the consolidation of the future National Defense Space Architecture (NDSA). The Tranche 1 (T1) Transport Layer (T1TL) is the foundational layer launching in FY24. This layer will consist of between 126-144 satellites onboard which will ride a BMC3 module. These modules comprise SDA’s BMC3 Layer to provide advanced capabilities at the edge. The eventual NDSA will 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 of Defense’s (DoD) 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. SDA achieves this mission by implementing DoD’s vision to transform its software development process. Critical to these objectives is a Software Factory that executes a DevSecOps lifecycle that provides for continuous Authorization to Operate (cATO).

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 of software development in support of NDSA space-based software applications.

This RFI seeks to inform the establishment of an Application Factory that will provide continuous updates to the BMC3 Layer.

BMC3 Background

The NDSA BMC3 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 optical cross-links and down-links to enable timely dissemination to both the warfighter and other systems in the architecture. BMC3 Layer 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.

The BMC3 Layer consists of the BMC3 module on the SVs, the BMC3 Secure Interoperability-middleware Layer (SIL), the BMC3 Application Factory (AppFac), and BMC3 Applications. The BMC3 module is the hardware provided by the SV vendor. The BMC3 SIL will be the middleware upon which mission based applications will run. The AppFac contractor is responsible for two key deliverables. First, the AppFac contractor will design, develop and deliver a DevSecOps-based environment and processes to ensure secure development of space- and ground-based capabilities envisioned in BMC3 Applications. Working with other Tranche 1 (T1) vendors, this environment will support the development, integration and deployment of BMC3 Applications building NDSA layers. Second, the AppFac contractor will design, develop and deliver the SIL within the AppFac’s DevSecOps-based environment for deployment on all BMC3 modules.

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 industry to provide feedback to the following two specific challenge areas.

BMC3 Acquisition Challenges

SDA intends to develop a BMC3 Application Factory with the functionality as described in the next section. As described, SDA is primarily considering one of three options. One, establish a Platform One or similar based application factory. Two, use an existing DoD or non-DoD application factory with a Continuous Authorization to Operation (cATO) in place. Three, use a vendor-specific application factory that implements DevSecOps and has or can receive a cATO status.

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

1. What key challenges and risks do you associate 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?

2. Assuming a plan to mature to TRL = 9 during the BMC3 T1 program, what is a Rough Order of Magnitude (ROM) cost to establish an application factory, including all Non- Recurring Engineering costs of your company's envisioned approach?

3. 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 reduced risk, if so, how? Are there test and verification approaches that could minimize risks further? What are the cost and schedule impacts induced by these mitigation approaches?

4. 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 BMC3 Application Factory solicitation in FY22-23 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.

BMC3 Technical Challenges

Industry feedback is critical to better inform SDA on current and innovative approaches to establishing and operating the BMC3 Application Factory.

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 AppFac and SIL 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 contracting agile development that supports 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 the creation and operation of an Application Factory based on DoD’s Platform One, or similar or derived environments? Provide analysis of how your approach maximizes the delivery of key capabilities embodied in the Platform One reference design.

4. Outline your support for 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)?

5. Platform One-based and/or similar capability implementation:

a) Experience using a DoD Centralized Artifacts Repository (DCAR) such as Iron Bank. Iron Bank is the DoD repository of digitally signed, binary container images including both Free and Open-Source software (FOSS) and Commercial off-the-shelf (COTS). Provide pros and cons of using DCARs.

Does your company have experience using a repository such as Iron Bank?

b) Experience using a multi-tenant environment such as Party Bus. Party Bus is a CNCF Kubernetes based platform providing secure, multi-tenant and multi-classification with Develop, Test, and Production environments. What experience does your company have deploying software through Party Bus?

c) Describe any experience your company has working within C2S, SC2S, Cloud One, or FENCES environments. What are the pros and cons of using such environments?

d) Experience standing up a Big Bang implementation of Platform One. Describe any experience establishing a dedicated Platform One or similar DevSecOps Environment. Provide classification level and/or Impact Level of the implementation. Provide experience with RMF and obtaining cATO. What are the pros and cons of setting up a dedicated environment? How would Big Bang be used if the operational environment was on various embedded spacecraft mission processors of different CPU architectures? How would Big Bang be used to produce software into a closed operational environment? Do you foresee issues using Big Bang if target applications are BMC3 and not web applications?

e) Experience with Stargate: Diode/Cross Domain Service. What experience does your company have with staging artifacts at a CDS for deployment on higher classification enclaves and domains?

f) Experience with Hardware in the Loop/Software in the Loop (HITL/SITL) simulations. What experience does your company have with utilizing emulation capabilities for space systems? How would you envision incorporation of the HITL/SITL with a Platform One-based and/or similar capability implementation?

g) Provide estimates for cost and schedule.

h) Provide thoughts regarding adaptability, open architectures, data rights.

i) Provide other experience establishing and maintaining a Continuous ATO

j) Connection to SDA’s Operations Centers. Describe, if able, your companies approach to integrating the Ops Centers with the BMC3 Application Factory from a DevSecOps perspective. How would testing on a BMC3 Hardware representative Engineering Development Unit (EDU) within the Ops Center (separate from the BMC3 Application Factory) occur? How would deployment and Feedback loops occur?

k) Provide other experience developing software using a DevSecOps framework

l) Describe any experience deploying software onto a space vehicle.

6. Implementation using other existing software factory. Based on capabilities implied in 1- 5 above, describe any experience using another, DoD or non-DoD software factories.

What would be the challenges in migrating to compliance with the DoD DevSecOps Reference Design (Ref: https://dodcio.defense.gov/Library)?

a) Provide estimates for cost and schedule

b) Provide thoughts regarding adaptability, open architectures, data rights

c) Provide other experience establishing and maintaining a Continuous ATO

d) Connection to SDA’s Operations Centers. Describe, if able, your companies approach to integrating the Ops Centers with the BMC3 Application Factory from a DevSecOps perspective. How would testing on a BMC3 hardware representative Engineering Development Unit (EDU) within the Ops Center (separate from the BMC3 Application Factory) occur? How would deployment and feedback loops occur?

e) Describe any experience deploying software onto a space vehicle.

7. Solution using a company specific implementation. Based on capabilities implied in 1-5 above, describe your software development process. What experience do you have working within the DoD CIO’s DevSecOps Software Development Framework?

a) Provide estimates for cost and schedule

b) Provide thoughts regarding adaptability, open architectures, data rights

c) Provide other experience establishing and maintaining a Continuous ATO

d) Connection to SDA’s Operations Centers. Describe, if able, your companies approach to integrating the Ops Centers with the BMC3 Application Factory from a DevSecOps perspective. How would testing on a BMC3 hardware representative Engineering Development Unit (EDU) within the Ops Center (separate from the BMC3 Application Factory) occur? How would deployment and Feedback loops occur?

e) Describe any experience deploying software onto a space vehicle.

f) What would be the challenges in migrating to compliance with the DoD DevSecOps Reference Design (Ref: https://dodcio.defense.gov/Library)?

8. Recommended contract structure for application factory, application development, integration of outside developed apps.

9. Would you expect human factors studies to be involved which may require an Institutional Review Board?

SUBMISSION INSTRUCTIONS

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

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

• Responses shall be sent electronically to:

osd.pentagon.ousd-r-e.mbx.SDA-SN-22-0007@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]".

mailto:osd.pentagon.ousd%1Er%1Ee.mbx.SDA%1ESN%1E22%1E0007@mail.mil

• 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, and single line spacing.

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.