Ground Control PWS 1.0.pdf

GROUND CONTROL PERFORMANCE WORK STATEMENT

(PWS)

Space Systems Command (SSC) Innovation and

Prototyping Division

(SYD89/SD)

Prototype Ground Development and Sustainment

Branch (SDG) Kirtland AFB, New Mexico

CHANGE LOG

Version Date Summary of Changes V1 14 January 2026 Initial Draft

TABLE OF CONTENTS

1. PURPOSE

2. BACKGROUND

3. SCOPE

4. PERFORMANCE OBJECTIVES

5. CONTRACT TRANSITION

6. SUPPORT REQUIREMENTS

7. ABBREVIATIONS AND ACRONYMS

1. PURPOSE

This Performance Work Statement (PWS) supplements the originating Hybrid Architecture and Development for Experimental Systems (HADES) Indefinite Delivery/Indefinite Quantity (IDIQ) PWS, encompassing the development, management and sustainment of all technical operational requirements necessary to ensure continuous mission execution on the Research, Development, Test, and Evaluation Support Complex (RSC). The contractor shall provide day-to-day operational support, maintain full mission readiness and ensure the RSC environment remains capable of supporting multi-mission, multi-classification space operations. The scope includes sustaining existing RSC capabilities, developing and integrating new or evolving mission requirements, ensuring secure and reliable system performance, and delivering responsive support to all programs operating within or dependent upon the RSC. As supplemental, the contractor shall perform engineering, development, integration, and sustainment, and associated support services primarily at the RSC located at Kirtland Air Force Base (KAFB), New Mexico and may include occasional travel to contractor facilities for collaboration and integration testing.

2. BACKGROUND

The RSC supports simultaneous multi-level missions. To continue to meet mission partners’ emerging requirements, SDG sustains and develops hybrid on-premises and cloud-based ground systems. The organization’s goal is to accelerate mission design and ground integration, launch and on-orbit operations, ground system tests, and rapid fielding to provide reliable, low-cost access to space in support of the warfighter. The Ground Control section maintains both on-premises and cloud information technology (IT) systems, and performs cybersecurity compliance and integration activities that are critical to day-to-day mission execution.

3. SCOPE

The scope of this acquisition is to provide comprehensive IT and operational support for the hybrid ground control environment. This includes, but is not limited to, the management of on-premises hardware and software, private cloud resources, and the integration and orchestration of all components. The objective is to ensure a secure, reliable, and scalable ground control system that can adapt to evolving mission requirements.

4. PERFORMANCE OBJECTIVES

The PWS requirements from the originating HADES PWS which are applicable to this effort are identified via bullet lists below. In general, the following paragraphs apply only to the extent the work is directly applicable to the accomplishment of this effort. Further clarified specifications are identified for specific requirements where appropriate.

The following requirements are applicable to this effort in entirety:

1.2 Scope

1.3 Access Department of the Air Force

Computer Systems

2.0 Basic Services

5. CONTRACT TRANSITION

The following transition requirements are applicable to this effort in entirety:

2.1 Contract Transition

6. SUPPORT REQUIREMENTS

The following aspects of the HADES IDIQ Support Services section (2.2) are applicable to this effort:

2.2 Support Services

2.2.1

Program Management

2.2.1.11 The contractor shall propose a staffing plan to the government and, with government approval, fulfill the staffing plan according to the level of effort (or FTE (Full Time Equivalent)) agreed upon. This may include full-time and matrixed positions.

2.2.1.12 Point of Contact for concept development should be the Engineering Lead, with the Test Lead serving as backup and support as needed.

2.2.1.13 The contractor shall provide daily status of all testing activities, including technical schedule issues. Reports and informal reviews shall be delivered to government leads.

2.2.1.14 The contractor shall document Operational Assessment Test (OAT) results or any mission impacting issues that result from OAT activities.

2.2.2 Cost Management

2.2.2.1 2.2.2.2

2.2.2.3 2.2.2.4

2.2.2.5

2.2.3 Information Management

2.2.3.1 2.2.3.2

2.2.3.3

2.2.3.4 The Contractor shall work with the government and the Configuration Management teams to provide and track documentation for all new or updated hardware or software.

2.2.3.5 Contractors must ensure their Configuration Management databases and all related tracking information are readily available on government-directed systems. Contractors may be required to provide data or access to databases as required.

2.2.4 Security and Data Handling

2.2.4.1 2.2.4.2

2.2.4.3 2.4.4.4

2.2.4.5 2.2.4.6

2.2.4.7 2.2.4.8

2.2.4.9 2.2.4.10

2.2.4.11

2.2.4.12 All contractors are required to complete security training as directed by the government.

2.2.4.13 The contractor shall provide management, supervision, labor, and personnel necessary to perform security escort services for uncleared and unauthorized individuals within [Specify area] and other designated controlled or restricted areas as required.

2.2.5 Quality Control

2.2.5.1 2.2.5.2

2.2.5.3 2.2.5.4

2.2.5.5 2.2.5.6

2.2.5.7 The Contractor shall use software for tracking, as directed by government.

2.2.5.8 The contractor shall consult the government prior to initiating Root Cause Analysis (RCA) or Lessons Learned investigations. The draft report shall be due ten days after the receipt of government authority.

2.2.6 Risk Management

2.2.6.1 2.2.6.2

2.2.6.3

2.2.6.4 The Contractor shall be responsible for risk identification and mitigation associated with supporting this effort.

2.2.7 Training and Certification

2.2.7.1 2.2.7.2

2.2.7.3 2.2.7.4

2.2.7.5 2.2.7.6

2.2.7.7 2.2.7.8

2.2.7.9 2.2.7.10

2.2.7.11

2.2.7.12 The Contractor shall be responsible for updating, documenting, storing, and maintaining all system training materials as well as training records.

2.2.8 Configuration Management

2.2.8.1 2.2.8.2

2.2.8.3

2.2.8.4 The Contractor shall be responsible for configuration of any Mission-Unique Software (MUS) scripts.

2.2.8.5 The Contractor shall be responsible for creating, updating or modifying MUS scripts.

2.2.8.6 The Contractor shall be responsible to review all scripts, licenses, MUS, hardware, adjacent systems, control items and consider mission partners when assessing impact.

2.2.9 Procurement, Logistics and

Lifecycle Management

2.2.9.1 2.2.9.2

2.2.9.3 2.2.9.4

2.2.9.5 2.2.9.6

2.2.9.7

2.2.9.8 Receive, inventory, and track all hardware materials in accordance with the HADES IDIQ PWS. Manage the inventory of the Government Furnished Property (GFP) to include spares.

2.2.9.9 Review equipment utilization and material consumption. Ensure 100% accountability of GFP controlled on contract. Deliver a written report quarterly.

2.2.9.10 Track and obtain, when necessary, all required maintenance, repairs, inspections, spares, replacements for GFP. Send defective or unserviceable parts and components to the manufacturer for repair or replacement if necessary.

2.2.9.11 The Contractor shall develop and maintain a lifecycle sustainment plan. The plan should include tools, processes and procedures that maintain configuration management of the systems and provide the government recommendations for hardware recapitalization opportunities.

Software and licensing renewals must also be identified to the government prior to their expiration.

2.2.9.12 The Contractor shall develop technology refresh packages in accordance with their Life Cycle Sustainment plan and any applicable System Engineering plan and make these packages available to the government.

2.2.9.13 Troubleshoot and replace failing/failed or broken components/hardware ensuring system availability requirements are met while adhering to government Engineering Review Board (ERB) / Configuration Control Board (CCB) and Information Assurance (IA) requirements.

2.2.9.14 Provide hardware engineers to provide on-call support.

2.2.9.15 Ground system solutions must integrate with existing RDSMO architectures, networks, and interfaces.

2.2.9.16 All capabilities must remain interoperable with government, commercial, and Kirtland-based ground stations.

2.2.9.17 System designs must align with SSC/SZI enterprise standards, configuration management processes, and approved technical baselines.

2.2.9.18 Changes must be compatible with legacy instantiations and future modernization paths.

2.2.9.19 Support must ensure seamless continuity with services previously provided under EDIS 2020.

2.2.9.20 All deliverables, reporting, and performance metrics must comply with HADES contract requirements.

2.2.9.21 Work must remain within the scope, funding, and authorities defined by SSC/SZI.

2.2.9.22 Contractor must adhere to government-approved processes for requirements development, change control, and risk management.

2.2.9.23 Provide on-site hardware support, troubleshooting and maintenance during normal business days and hours (M–F, 8–5) and on-call support during non-business hours with a 3-hour threshold.

2.2.9.25 Contractor shall resolve the identified problems within 2 hours during business hours.

Contractor shall resolve the identified problems within 3 hours during non-business hours.

2.2.9.26 Ensure any changes to the baseline for the purpose of restoring mission service are presented to and approved by the Government prior to implementation. If the change to the operational baseline is directed by the Government, the 3-hour limitation to fix will not count against the contractor.

2.2.9.27 Perform hardware sustainment to include but not limited to: maintenance, hardware monitoring, detailed troubleshooting, fault detection, isolation, and removing and replacing failed components to restore system operations and maintain system availability.

2.2.9.28 De-conflict any scheduled system downtime with the Government to avoid affecting training and real-time contacts verified in system availability.

2.2.9.29 Perform system rollbacks (if needed) within 2 hours during business hours and 3 hours during non-business hours.

2.2.9.30 Finalize system documentation to reflect changes. Updates to hardware system documentation must be incorporated to the baseline within 3 business days of system changes.

2.2.10 Concept Development

2.2.10.1 2.2.10.2

2.2.10.3 The Contractor shall (when the contractor proposes a change, or upon request):

Conduct conceptual studies to produce a broad spectrum of ideas or alternatives which address a requirement, risk, issue or other problem. A conceptual study (sometimes referred to as an Analysis of Alternatives [AoA]) examines various alternative solutions and, for each alternative:

• Identifies and determines feasibility

• Develops technical concepts and identifies potential technological needs

• Defines scope

• Develops high-level Concept of Operations (CONOPS) or Concept of

Employment (CONEMP)

• Provides draft system-level requirements

• Identifies potential technical, schedule and cost benefits and risks

• Identifies potential cybersecurity benefits and risks

• Identifies general costs and schedule without consideration of resource availability

2.2.10.4 The contractor shall assess feasibility with input from various Subject Matter Experts (SME) (including safety/security/cyber-SMEs), test-bed simulations, models, mock-ups or other tools.

2.2.10.5 Coordinate all CCB packages with the Government Program Lead or assigned POC for simple designs or changes, the final (critical) design, may be documented in the CCB package.

The contractor shall coordinate entry and exit success criteria with the Government Program Chief Engineer. The Government may use the results of the Final (Critical) Design phase to:

• Authorize the contractor to acquire materials and services

• Begin software development (if required)

• Support a review milestone, or to direct the contractor to continue to the System

Assembly, Integration, Test and Operational Acceptance phase

2.2.10.6 Coordinate all Engineering Review Board (ERB) packages with the SDG Enclave Lead for simple Conceptual Studies. More complex studies will, upon direction from the government, be documented in a formal engineering report. From the alternatives identified, the Government may select one or more for further development.

2.2.10.7 The work performed shall be in conjunction with the specific mission and all documentation will be routed through the Government Program Office.

2.4 Facility Services

2.4.1 Power Distribution and Resiliency

Support

2.4.1.1 2.4.1.2

2.4.1.3 2.4.1.4

2.4.1.5 2.4.1.6

2.4.2 Heating, Ventilation and Air

Conditioning Support

2.4.2.1 2.4.2.2

2.4.2.3 2.4.2.4

2.4.2.5 2.4.2.6

2.4.3 Facility and Furniture Maintenance

2.4.3.1 2.4.3.2

2.4.3.3 2.4.3.4

2.4.3.5 2.4.3.6

2.4.4 Network Infrastructure Support

2.4.4.1 2.4.4.2

2.4.4.3 2.4.4.4

2.4.4.5 2.4.4.6

2.4.5 Space Optimization and Layout

2.4.5.1 2.4.5.2

2.4.5.3 2.4.5.4

2.4.5.5 2.4.5.6

7. ABBREVIATIONS AND ACRONYMS

ABBREVIATION/ACRONYM MEANING

CCB Change Control Board

CONOPS Concept of Operations

ERB Engineering Review Board FTE Full Time Equivalent GFP Government Furnished Property

HADES Hybrid Architecture and Development for Experimental

Systems

IA Information Assurance IDIQ Indefinite Delivery Indefinite Quantity KAFB Kirtland Air Force Base

MUS Mission Unique Software scripts OAT Operational Assessment Test PWS Performance Work Statement

RSC Research, Development, Test, and Evaluation Support Complex

RVDS Rendezvous and Proximity Video Distribution System SMP Symmetric Multiprocessing SSC Space Systems Command

SYD89 Innovation and Prototyping Delta