Call for Exec Summaries - PWSA Ground Segment_AppFac Transition.pdf

Space Development Agency STEC BAA Special Notice

PWSA Ground Segment & AppFac Transition Study Call for Executive Summaries

27 March 2025

Under the Systems, Technologies, and Emerging Capabilities (STEC) Space Development Agency (SDA) Broad Agency Announcement, FA240125S0001, posted on SAM.gov on January 15th, 2025, SDA is soliciting this call for executive summaries. SDA is soliciting executive summaries describing the technical approach the performer will utilize to perform 180-day studies on evolving the current Proliferated Warfighter Space Architecture (PWSA) Ground Segment (GS) and the Battle Management, Command, Control, and Communications (BMC3) software Application Factory (AppFac). This Call for Executive Summaries falls under SDA BAA Focus Area #4 – Global Battle Management.

Background

Recognized as the Department of Defense's constructive disruptor for space acquisition, the Space Development Agency (SDA) will quickly deliver needed space-based capabilities to the joint warfighter to support terrestrial missions through development, fielding, and operation of the Proliferated Warfighter Space Architecture (PWSA). The PWSA provides our warfighters with a resilient military sensing and data transport capability. Beginning with Tranche 1 in 2025, SDA will deploy hundreds of space vehicles (SV) to begin fielding the PWSA.

As part of this architecture, the PWSA requires a tightly-integrated Ground Segment to effectively execute its mission. The first instantiation of the PWSA Ground will be delivered as part of Tranche 1 and incrementally advanced through the Ground, Management, and Integration (GMI) effort. SDA is considering evolving the Ground Segment further through a multi-pronged acquisition strategy. The notional schedule is shown in Attachment A. Awarded study contracts will inform the Government on how to affordably, efficiently, and competitively transition from the current Ground Segment to this new architecture and acquisition strategy.

The PWSA Ground and BMC3 Segments represent a software intensive system-of-systems, employing agile development and management framework methodologies to provide iterative capabilities to the PWSA enterprise and warfighter. SDA and the United States Space Force (USSF) are interested in understanding how the Government may be able to leverage commercially available and emerging technologies to transition and expand the current PWSA Ground and BMC3 Segments, based on loosely-coupled Modular Opens Systems Architecture (MOSA) design principles.

The purpose of this evolution is to integrate new space segment capabilities, mission data applications and services, and GS infrastructure elements to increase the overall performance and resiliency of the PWSA. In addition, SDA is seeking to expand the BMC3 AppFac to be able to support GS framework, GS applications and services, and BMC3 application development activities across the PWSA enterprise. SDA is interested in creating an eco-system that enables broad industry participation in the software-enabled PWSA GS, application, and services environment by fielding a GS Framework that hosts both capability-specific and capability-agnostic applications and services from multiple developers through a PWSA Enterprise AppFac (denoted PWSA AppFac).

SDA envisions an end-state that includes a common GS Framework hosting applications and services from multiple developers. The GS Framework & Integration (GFI) provider will be responsible for integration activities both within the GS and between the GS, SVVs, and the PWSA AppFac. SDA anticipates a phased transition of the GS and BMC3 AppFac, whereby the new GFI provider would implement, or adhere to, existing GS Framework, application, and service interfaces enabling current GS applications to migrate to the new framework with minimal effort and risk. The new GS Framework and PWSA AppFac will enable rapid development, test, and deployment of both existing and new GS and BMC3 mission applications and services. For example, the GS Framework itself may be developed in the PWSA AppFac.

The current GS cloud-based processing system includes a common framework hosting common and enterprise services, as well as mission-unique applications as depicted in the “PWSA Ground Segment OV-1” - Attachment B. The GS includes interfaces with space vehicle vendor (SVV)-specific command and control applications, BMC3 applications, Ground Entry Points (GEPs), and other external entities, e.g., the Unified Data Library (UDL), 18SDS, RTS, and external users. The BMC3 AppFac currently provides development environments, build pipelines, and integration environments to support BMC3 application development, integration, and test.

- Common and enterprise services include Enterprise Service Bus (ESB), application and processing workflow/orchestration, data transport, data management, account management, cybersecurity, authentication, logging, audit, time reference, cross-domain interface (AWS DIODE), and data storage/archive. The infrastructure also connects the ESB to non-Cloud components via WAN with data encryption occurring upon entry/exit from the IL6 cloud.

Network communications are governed by the SDA’s Network Established Beyond the Upper Limits of the Atmosphere (NEBULA) Standard.

- The BMC3 AppFac provides a DoD Enterprise DevSecOps Reference Design-compliant (v1.0 DoD Chief Information Officer) software factory with specifically tailored pipelines to support embedded software development, BMC3 mission application development, and software integration services. The current AppFac provides a tiered testing approach beginning in an IL5 cloud (Cloud 1 – AWS) which provides an integrated development environment (IDE) that provides an environment for software development (consists of a source-code editor, build automation tools, and a debugger). Additionally, the BMC3 AppFac provides a tier 2 hardware-in-the-loop (HWITL)/software-in-the-loop (SWITL) lab for testing space software, a tier 3 IL6 cloud development environment (which mirrors the IL5 tier 1 environment, a production-like tier 4 environment (e.g., sandbox), and support for in-production testing (Canary Ops).

- Mission services cover flight dynamics, alternative Position, Navigation, and Timing, constellation, network, and ground resource management (e.g., GEPs), mission planning and scheduling, mission data processing, and operator interface services. Mission services also include applications specific to each capability i.e., Transport, Tracking, BMC3, and Custody.

- SVV services provide command and control (C2) of the space vehicles and implement routing almanacs and other instructions. SVVs provide C2 capabilities via “NEBULA Operations – Vendor Architecture” (NOVA) systems, which interface with the GS via the “SDA Unified Planning Environment and Resources for NEBULA Operations – Vendor Agnostic” (SUPERNOVA).”

The new GFI provider will deploy many of these same services, in some cases transitioning the apps from the existing GS. Additionally, the GFI provider will design, develop, and sustain the ground system framework including the ground system platform and common services, implement a loosely coupled

MOSA design approach, and ensure backward compatibility throughout evolution of the ground segment. The GFI provider will provide enterprise and messaging services, broker external interfaces, curate common framework services, and manage user interfaces. They will lead ground system integration and test to integrate third-party services and applications into the framework and ensure end-to-end ground segment performance. The GFI provider may leverage the current BMC3 AppFac or expanded PWSA AppFac for development of the ground system framework and collaborate with the PWSA AppFac provider for integrated ground and space segment SW factory requirements to enable capability expansion. The GFI provider will develop ground segment verification plans, coordinate execution, and support PWSA enterprise interoperability and integration testing.

The PWSA AppFac provider must provide a flexible, adaptable, and Agile production-like software development ecosystem which prioritizes DevSecOps principles. The PWSA AppFac will work hand-in-hand with the GFI provider to ensure that all SW developed in the DevSecOps pipeline is integrated to work as an integrated mission system and will incorporate the same approach to ensure T1-Tn compatibility. It will be critical that the PWSA AppFac incorporates cybersecurity principles early and throughout the pipeline, builds in emulation services to replicate the production environment, and is able to quickly adapt to SW development teams’ needs.

The GS framework should provide, at a minimum, the following capabilities and attributes:

a. Loosely coupled MOSA design principles

b. Zero-Trust architecture principles

c. Support rapid development, training, and fielding of Artificial Intelligence (AI)-enabled apps

d. Application and data processing workflow/orchestration

e. Common cybersecurity services; authentication, SIEM, logging and auditing, RBAC

f. Bulk and streaming data transport services

g. Data management and data storage services

h. Timing services

i. Health and status

j. System monitoring and metrics

k. External interfaces (UDL, 18SDS, RTS, and other external users or data providers)

Study Scope and Major Deliverables

With this call for executive summaries, SDA is specifically seeking approaches to conduct studies to understand challenges of implementing a new GS framework and the implications to the overall PWSA Ground Segment and AppFac. The studies will include data collection, analyses, and trades, to aid the government in understanding the scope, effort, and details of transitioning to a loosely coupled MOSA GS that includes a GS framework, developed and fielded by the GFI performer, a new PWSA Application Factory, and third-party-developed mission applications and services that are integrated with the framework. The government is interested in understanding challenges/effort in expanding the current BMC3 AppFac into a PWSA AppFac, establishing a new GS and transitioning existing operations and maintenance activities, facilities, materiel, and government owned (rights) SW to the new GS; and in determining which data/information is required about the current GS to accurately emulate/replicate interfaces with the NOVAs, SVs, facilities, and users. All proposed efforts should address, at a minimum, the following:

Study tasks:

1. Describe recommended technology and design approaches for the new framework that are consistent with loosely coupled, Modular Open System Architecture design principles. Describe abstraction techniques that enable rapid, low risk extensibility and adoption of new technologies.

2. Perform trades and provide recommendations with supporting analyses and references covering all aspects of the transition from the current PWSA GS to an enhanced MOSA. This includes technical, logistical, schedule, and risk assessments.

3. Investigate options for transitioning existing services, utilizing new services, connecting to existing GEPs and circuits, expanding to new GEPs, connecting to existing factories and facilities, and adding new ones while upgrading and maintaining critical connections and operations with partners and users.

4. Identify options for sequencing the developments and transitions; integrating, testing, and certifying portions of the new system; and avenues for attaining IATT and ATO to support transition to operations for each tranche.

5. Work with the incumbent GMI and BMC3 AppFac performers to understand the complexity of the architecture and transferability of components outlined in the scope of this study.

6. Define the implementation of the DoD Enterprise DevSecOps Reference Design, of the expanded PWSA AppFac (i.e., IDEs, M&S tools, Software Development Kits (SDKs), cybersecurity tools, SW development management tools, and the DevSecOps Architecture) to support the capability to scale to any type of operational requirement needing a software solution, including:

a. Business systems

b. Command and control systems

c. Embedded and weapons systems

d. Intelligence analysis systems

e. Autonomous systems

f. Assisted human operations

7. Describe approach for incorporation of Machine Learning Operations (MLOps) into the PWSA AppFac, including:

a. Model development: Creation of new ML and deep learning (DL) models

b. Model deployment: Deployment approaches of models to production

c. Model monitoring: Monitoring of model performance and quality

d. Model retraining: Retraining approaches of models when needed

e. Model version control: Version control maintenance over models

f. Continuous integration and continuous delivery (CI/CD): Automation of the process of building and deploying models

8. Define contents of SDKs, ICDs, standards, and other documentation required to ensure the enterprise ground framework implements MOSA principles, is well defined, and ensures each of the components will be interoperable. Recommend where use of similar information from the existing GS (e.g., SDKs) will ensure backward compatibility.

a. Specify what tools, artifacts, libraries, etc. should be included in the SDK provided by the current SUPERNOVA developer. An SDK is a set of tools to build software for a particular platform. The tools allow a developer to build application software that integrates with the platform and other applications. This SDK should help the new framework provider develop a framework/platform that is compatible with the current SUPERNOVA applications so that these applications can easily be rehosted on the new framework.

b. Specify what architecture and design artifacts need to be provided by the current SUPERNOVA developer to develop the new framework. The new framework should be developed in a manner that allows seamless rehosting of the current SUPERNOVA applications and enables scalability and extensibility for supporting and incorporating new missions, applications, and technologies. Be more specific than just specifying an MBSE model. Specify which system views, data flow diagrams, internal system ICDs, and sequence diagrams, etc.

c. Specify what should be included in the SDK provided by the new framework and integration provider—this may be different than the SDK provided by the current SUPERNOVA developer depending on the specific architecture and technologies used.

d. Specify what common applications and services are recommended for inclusion in the new framework. Examples of possible common services include data ingest and transport, health and status, application orchestration/workflow, timing, SIEM, audit, logging, authentication, and UI framework.

9. Perform a kickoff meeting to review objectives, constraints, schedule, and deliverables, in detail.

Include two interim reviews to assess progress, and a final review with a final report/presentation.

Draft presentations are due 10 working days prior to a review and final (corrected) presentations are due 20 working days after the review.

Purpose of Solicited Work

SDA intends to use the results of any contracted efforts to inform planning for PWSA Ground Segment activities.

SUBMISSION INSTRUCTIONS

All executive summaries shall comply with the proposal instructions set forth under the Systems, Technologies, and Emerging Capabilities (STEC) Space Development Agency (SDA) Broad Agency Announcement, FA240125S0001. The executive summary should be clearly marked “EXECUTIVE SUMMARY”, and the total length shall not exceed four [4] pages if both the GFI and AppFac aspects of the study are addressed. Alternatively, up to two [2] Executive Summaries may be submitted, one addressing the GFI aspect of the study, and/or one addressing the AppFac aspect of the study, not to exceed two [2] pages each. All Executive Summary submissions must be written in narrative form. No formal transmittal letter is required, but submission must include the organization name, submission title, SDA focus area(s) and technical POC information (e-mail and mailing address).

Additional Instructions and Assumptions

1. SDA encourages Executive Summaries to address the Offeror’s proposed technical approach for executing this study, relevant corporate experience and expertise, and preliminary concepts for evolution of the PWSA GS and PWSA AppFac.

2. Potential Offerors shall assume a study Period of Performance of 180 calendar days and an Authority to Proceed (ATP) of 27 June 2025.

3. SDA strongly encourages Offerors assert Government Purpose Rights or better on all deliverables and interim products in support of the awarded effort.

4. SDA strongly encourages Firm Fixed Price proposals.

5. SDA is contemplating multiple awards, but the Government reserves the right to make a single award, multiple awards, or no awards at all.

6. SDA will respond to executive summaries with a statement as to whether SDA is interested in the idea. A letter of interest will encourage the submission of a full proposal. Regardless of SDA’s response to an executive summary, proposers may submit a full proposal but do so with the understanding that funding or interest levels may not support selection for award. SDA will review all submissions submitted using the published evaluation criteria and without regard to any comments resulting from the review of an executive summary.