S3 STDDS PWS DRAFT.pdf

1.0. PERFORMANCE WORK STATEMENT

1.1. BACKGROUND

The U.S. DOT Volpe Center supports Federal Aviation Administration (FAA) organization AJM-316 to establish System Wide Information Management (SWIM) as an interface to legacy and new air traffic management systems. Specifically, the Volpe Center provides essential SWIM support including development, analysis, and support of the Segment 2C SWIM Terminal Data Distribution System (STDDS).

The purpose of this performance work statement is to procure services in the following areas:

• STDDS Centralization Release Software Development, Testing, and Integration

• System Release Deployment

• Project Management

1.2. STDDS

STDDS converts raw surface data collected from airport towers and Terminal Radar Approach Control (TRACON) facilities into easily accessible information, which is published via the NAS Enterprise Message Service (NEMS).

STDDS publishes data from the following FAA airport and terminal systems:

• ASDE-X - Airport Surface Detection Equipment – Model X

• ASSC - Airport Surface Surveillance Capability

• STARS - Standard Terminal Automation Replacement System

• RVR - Runway Visual Range

• EFSTS - Electronic Flight Strip Transfer System

• TDLS - Tower Data Link Services

• SFDPS - SWIM Flight Data Publication Service

• STDDS enhanced ASDE-X/ASSC, STARS, and EFSTS/TDLS data with SFDPS flight plan data where applicable

STDDS publishes data to FAA and external consumers, via NEMS, in accordance with SWIM standards, and provides access to data from over 200 airports and over 400 individual systems.

The current STDDS deployment is based on a distributed architecture which is difficult and costly to manage and maintain, with STDDS equipment deployed at over 100 remote Standard Terminal Automation Replacement System (STARS) TRACONs and 38 STDDS TRACONs.

There are additionally more than 100 remote STDDS interfaces at towers. FAA Telecommunications Infrastructure (FTI) network services are used to connect to NEMS to publish STDDS data to SWIM consumers. STDDS does not currently support efficiency critical (EC) services which will be needed in Segment 3.

1.3. SWIM Segment 3

SWIM Segment 3 represents the next evolution of SWIM. The overall objective of SWIM Segment 3 is to provide enhanced information sharing services to support the transition of the National Airspace System (NAS) to begin to enable Performance Based Operations (PBO), a collective set of performance and safety criteria that various aspects of the Air Traffic Management (ATM) system need to meet, within a given probability, to support the approved quality of service specified for a given operation. SWIM Segment 3 will provide improved aviation information in terms of usability and granularity, supporting efficiency critical service threads, improved security protections, enhanced governance, and improving operational efficiencies.

The STDDS Centralization Release in Segment 3 adds two primary requirements:

- Centralize the STDDS System from its current distributed architecture

- Upgrade STDDS to support EC operations

Under Segment 3, a centralized cloud-based STDDS deployment is planned in order to support EC services but this needs further analysis to refine the best approach. By centralizing the STDDS architecture, the need for redundant equipment, staff, and related support systems will be greatly reduced. The efficiency of system updates will also be improved. SWIM Segment 3 upgrades STDDS by making it EC, and also improves service quality, capacity, and scalability by creating a centralized cloud-based STDDS architecture. Analysis of upstream networks providing data to STDDS must also be performed to ensure the entire processing thread supports EC availability and security requirements.

The STDDS Centralization Release will require significant transition planning to coordinate the rerouting of over 400 interfaces to the centralized location. This planning will need to account for FAA initiatives such as FAA Enterprise Network Services (FENS), Time Division Multiplexing to Internet Protocol (TDM-to-IP) conversion, and IPv6 upgrade, which may be pre-requisites to portions of the STDDS Centralization Release.

The STDDS Centralization Release may also make changes to STDDS Infrastructure, Monitor and Control (ISMC) to support improved system and service monitoring.

The STDDS Centralization Release Initial Operating Capability (IOC) is Q3 FY28. It is a dependency for SWIM’s Common Support Services – Flight Data (CSS-FD) Phase 1 deployment, because STDDS is the source of ASDE-X/ASSC and STARS data in the CSS-FD Flight Object.

Volpe requires contract support in order to develop the STDDS Centralization Release.

2.0 SCOPE / REQUIRED TASKS AND DELIVERABLES

Task 1: STDDS Centralization Release Software Development, Testing, and Integration The contractor shall provide support to design, develop, and test the STDDS Centralization Release software, as well as any required and related software updates necessary to ensure functionality.

As a preliminary step, detailed system requirements and an engineering recommendation for the software solution need to be developed and documented to ensure mutual agreement between Volpe, the contractor, and the sponsor on the scope of the development work.

The STDDS Centralization Release changes may include the following:

STDDS Centralization to a Cloud-Ready System Contract support is required to assist with the design of the cloud ready system:

• Define centralized cloud platform and approach

• Identify cloud specific Commercial Off The Shelf (COTS) products

• Design the system to be compatible with Amazon Web Services (AWS) GovCloud (US) to utilize multiple available zones within each region to provide fault tolerance, stability, and provide failover capabilities in alignment with FAA Mission Essential Operating Environment (ME-OE) and FAA Mission Essential (ME)-Cloud requirements

Contract support is required to update STDDS software to support the centralized architecture:

• Cloud National Test Bed (CNTB) is an AWS GovCloud Federal Information Security Modernization Act (FISMA) High off-premise enterprise cloud hosting environment. This environment will be configured, secured, monitored, operated, and controlled by the FAA

• CNTB will be used for the development, testing (dev and ops) and pre-production of FAA system/applications in this new environment to identify and resolve code, interface/interchange, security, sustainment, programmatic, and Operation Technology security scans/penetration testing needs for the FAA ME-OE production

• Establish connections to centralized system for NEMS, TDLS, SFDPS, STARS, RVR, ASDE-X/ASSC and EFSTS data

• Update adaptation to allow all source systems to connect to a single site

• Configuration changes of STDDS system (site numbers, loads)

• Updates to administrative functionality (Maintenance Workstation in S2C) to reflect new architecture

• Update Site Monitor - requires display redesign to reflect new architecture

• Design/develop software at a level of rigor equivalent to Radio Technical Commission for Aeronautics (RTCA) DO-278A software assurance level AL6, with the understanding that no additional software development requirements will be levied to meet AL6. For AL6, the RTCA document guidance does not apply

Support of Efficiency Critical (EC) Operations EC Surface Movement Event Service (SMES) and Terminal Automation Information

Service (TAIS) are requirements for the CSS-FD Flight Object. Contract support is required for the design of the EC system:

• Develop EC design Contract support is required to update STDDS software to support EC operations:

• Add any missing redundant source system connections o Remote ASDE-X and ASSC

• Updating software to support dual connections for EC feeds

• Add heartbeat message for use by EC consumers The contractor shall provide support to make changes to STDDS Infrastructure, Monitor and Control (ISMC) to support improved system and service monitoring in support of EC operations:

• Updates to ISMC Service per ACG’s new order addressing Sensitive Technical Information (STI) o Generalizes content of publicly distributed ISMC messages o Designates detailed ISMC messages such as STDDS Status as STI (auth only)

• Updates to ISMC Service to meet STDDS’ Remote Monitoring and Logging System (RMLS) reporting requirements o Develop new ISMC message in RMLS’ required format, based on

Maintenance Management Information Exchange Model (MMIXM) 3.0 Contract support is required for the following enhancements to the STDDS software to support EC operations:

• Moving STDDS altitude filter function to SAFA sites o This would reduce TAIS bandwidth and processing requirements by 50%

• Proposed by STARS: Develop new ISMC message in RMLS’ required format, based on MMIXM 3.0 to fulfill STARS RMLS reporting requirements

Following extensive internal testing, including early Information Management Services (IMS) integration testing, System/Development testing, and Operational Testing, contract support is required to verify the final software solution via implementation at one or more selected key sites, depending on the transition plan implementation decision.

Development and testing equipment will nominally consist of five systems and two workstations, and/or other ancillary equipment as required. A development and testing platform in the CNTB will be provided, including all tools.

Contract support may be required to develop and test requirements associated with external changes such as the FENS transition, TDM-to-IP, and the IPv6 upgrade, as well as with integration planning and risk assessment for these changes.

Deliverable/Milestone/Activity Target Date

Project Start July 2025

System Specification Document (SSD) draft document Sep 2025

System Specification Document (SSD) final document Nov 2025

Web Services Requirement Document (WSRD) draft document Oct 2025

Web Services Requirement Document (WSRD) final document Nov 2025 System/Subsystem Specification (SSS) draft document Dec 2025 System/Subsystem Design Description (S/SDD) draft document Mar 2026 Contractor's Master Test Plan (CMTP) draft document May 2026 System/Subsystem Specification (SSS) final document May 2026 System/Subsystem Design Description (S/SDD) final document May 2026 Contractor's Master Test Plan (CMTP) final document July 2026 Safety Risk Management (SRM) Document completed Sep 2026 Engineering Dry Runs (EDR) Apr 2027 Quality Dry Runs (QADR) May 2027 System Test completed June 2027 Operational Test (OT) Dec 2027 Key Site 1 software installed and dry runs Feb 2027 Key Site 1 formal test Feb 2027 Transfer of verified software to FAA June 2028

Task 2: System Release Deployment Continuous Integration / Continuous Delivery (CI/CD) pipeline integrations between CNTB and ME-Cloud will allow software solutions developed in CNTB to deploy seamlessly to staging and production in off-premises ME-Cloud.

This new deployment construct along with the centralized STDDS will differ from the prior distributed architecture and many details are still being refined.

The contractor shall provide support to work with STDDS Second Level Engineering to develop a centralized STDDS deployment plan that outlines transition roles, responsibilities, and includes milestones for cutting over all associated interfaces.

No. Deliverable Format Due Date

1 TBD TBD TBD

Task 3: Project Management

The Contractor will provide project management support for this activity. This will include:

• Creating a project management plan, which describes the scope of work, required tasks, budget allocation, and schedule projections for deliverables

• Developing, coordinating, and maintaining project schedules, timelines, and associated milestones

• Tracking and measuring project performance against requirements

• Conducting cost estimation and tracking via monthly project cost reports

• Identifying assumptions, constraints, task dependencies (e.g., funding availability), and external dependencies (e.g., delivery dates)

• Reviewing internal/external constraints/dependencies and assessing the impact on project schedules and goals

• Reviewing project deliverables and associated technical documentation

• Coordinating arrangements for meetings, teleconferences, and demonstrations

• Preparing meeting minutes and relevant notes from participation in technical interchange meetings, project reviews, and relevant teleconferences.

No. Deliverable Format Frequency 1 Contractor's Master Test Plan

(CMTP) final document Word 12 months after project start 2 Project Management Reviews with external stakeholders Microsoft

PowerPoint - Teleconference

Monthly on or around the second Wednesday

3 Check-in meetings with COR Microsoft Teams Weekly

3.0 GOVERNMENT FURNISHED PROPERTY/INFORMATION

The Government will provide all related documentation including deliverable and work product templates (e.g., MS Project Plan, Monthly Status Reports, and System Requirement Specifications), all non-standard software that is needed to support the project and access to government application environments (e.g., hosted machines and servers. The following is a list of Government Furnished Property/Information to be provided to the Contractor at task order award as required:

No. Government Furnished Property/Information 1 Microsoft Team Foundation Server access 2 Non-Standard licenses required for web development 3 Access to web environments 4 Deliverable and work product templates (e.g., MS Project Plan, Monthly Status

Reports, and System Requirement Specifications)

4.0 TRAVEL

Travel to FAA sites will be expected. To be determined prior to solicitation.

5.0 PERIOD OF PERFORMANCE

The period of performance for this order is from award for three years.

5.1 PLACE OF PERFORMANCE

The Place of Performance shall be virtual or at the contractor’s facility.

6.0 DELIVERABLES

The required deliverables of this order are identified for each task area in the Performance Work Statement.