CSS-FD SIR J-0 CSS-FD Strategy DRAFT_v2.0.pdf

Solicitation #

Attachment J-0

Federal Aviation Administration

Common Support Services – Flight Data (CSS-FD)

CSS-FD Strategy

November 2024

Federal Aviation Administration

800 Independence Avenue, SW

Washington, DC 20591 i

TABLE OF CONTENTS

1 INTRODUCTION

2 AES OVERVIEW

3 AES IMPLICATIONS FOR CSS-FD

4 MULTI-PHASED CAPABILITIES IMPLEMENTATION APPROACH

4.1 PHASE 1 CAPABILITIES

4.1.1 Capability 1: Data Management and Security Framework

4.1.2 Capability 2: Flight Planning and Flight Plan Filing

4.1.3 Capability 3: Feedback by Reference

4.1.4 Capability 4: Return ATC Preferences

4.2 PHASE 2 CAPABILITIES

4.2.1 Capability 5: Preliminary Flight Plan Submission and Planning Status Response

4.2.2 Capability 6: Preliminary Flight Information Distribution

4.2.3 Capability 7: Return ATC Preferences Enhancements

4.2.4 Capability 8: Notification Service

4.3 CAPABILITY INTERDEPENDENCE

5 KEY NAS PROGRAM INTERDEPENDENCIES

5.1 SWIM SEGMENT 3 (S3)

5.1.1 SWIM Terminal Data Distribution Systems (STDDS)

5.1.2 SWIM Flight Data Publication Services (SFDPS)

5.2 FLOW MANAGEMENT DATA AND SERVICES (FMDS)

5.3 SWIM PROGRAMS FOR FLIGHT OBJECT (FO)

5.4 FAA ENTERPRISE NETWORK SERVICES (FENS)

5.5 SWIM SEGMENT S2D (S2D)

5.5.1 Information Management Services – in the Cloud (IMS / IMS-C)

5.6 MISSION-ESSENTIAL (ME) CLOUD

5.7 NAS COMMON REFERENCE (NCR)

6 FAA PRIORITIES AND INCENTIVE STRUCTURE

6.1 COST INCENTIVES ................................................................ ERROR! BOOKMARK NOT DEFINED.

6.2 AWARD FEE .......................................................................... ERROR! BOOKMARK NOT DEFINED.

APPENDIX A – ACRONYMS AND ABBREVIATIONS

ii

List of Figures

Figure 1: AES Technical Architecture

Figure 2: Example CSS-FD - FMDS System to System Interaction Utilizing AES

List of Tables

Table 1: CSS-FD Capabilities by Phase

Table 2: Constraints for Feedback by Reference

Table 3: CSS-FD Capability Interdependencies

1 INTRODUCTION

The purpose of this document is to identify the Federal Aviation Administration’s (FAA) strategy for the Common Support Services – Flight Data (CSS-FD) program. To assist Offerors in understanding the strategy, this document provides an overview of the FAA’s Automation

Evolution Strategy (AES), a description of a multi-phased implementation approach, and key

National Airspace System (NAS) program interdependencies.

The prevailing landscape of automation systems has a historical trajectory of systems that are siloed, monolithic, and encumbered by hard-coded functionalities. These programs, while they fulfill their intended roles, pose limitations that hinder adaptability and do not encourage exploration of emerging solutions. By transitioning from siloed, monolithic systems to a framework of enterprise services, the FAA can address the constraints imposed by legacy systems while enabling rapid adaptation to evolving needs. This transition will improve NAS resilience, efficiency, and agility.

Common support services provide scalability through the deployment of enterprise services and the embrace of a cloud-based architecture. This transition is not simply a technology upgrade; it represents an architectural shift that drives toward an aviation infrastructure prepared for technological advancements. The CSS-FD program facilitates the modernization and strategic alignment to an enterprise approach for the management and exchange of flight data.

NAS systems and Air Service Providers (ASPs) lack coordination of flight data sharing, since they operate independently across different domains. Without synchronization and compatible interfaces, there is a fragmented overview of flights, which complicates collaboration among flight operators, Traffic Flow Management (TFM), and Air Traffic Control (ATC), and hampers effective management of system constraints. CSS-FD seeks to address these challenges by implementing a unified, standards-based framework for flight data exchange across the NAS and beyond with international stakeholders, using the Flight Information Exchange Model (FIXM) standard to achieve global interoperability and enable more advanced, data-centric operations.

This document identifies key elements of CSS-FD's strategic objectives and describes the alignment with the FAA’s AES (to introduce greater flexibility, scalability, and interoperability).

The goal is to begin unlocking opportunities for enhanced collaboration, data sharing, and innovation. The FAA leverages feedback and recommendations provided by industry stakeholders, including the emphasis on avoiding proprietary systems, enhancing business rules management with Artificial Intelligence/Machine Learning (AI/ML) capabilities, and focusing on innovation and data management strategies to develop new enterprise services. Transitioning to a framework of enterprise services allows the FAA to overcome legacy system constraints, enabling rapid adaptation to evolving requirements. This transition enhances NAS resilience, efficiency, and agility. Common support services enhance scalability through the deployment of enterprise services and adopting cloud-based architectures.

This document offers a comprehensive overview of the CSS-FD strategy, enriched by industry feedback, and aligned with the FAA’s broader objectives to foster innovation and collaboration within the aviation community. This document does not contain or imply any functional or performance requirements.

2 AES OVERVIEW1

The FAA’s AES is a vision of the future evolution of how the FAA’s automation systems are built. This strategy is based on a layered, service-based architecture encompassing air traffic management service and promotes reuse of software capabilities while increasing the speed and agility in making new functionality operational. AES promotes these goals by envisioning the future NAS consisting of loosely coupled and well-defined services (i.e., Mission Services) that can be developed and sustained independently. This will increase opportunities for safe incremental improvement, reuse, competition, and parallel development. For more information about AES, please see the Attachment J-8, AES Technical Architecture document or refer to the

AES Market Survey2, which provides references for the AES ConUse and AES Reference

Architecture.

The FAA has developed the AES technical architecture with the following objectives:

• Service-Based Design: AES outcomes should promote the availability of services, rather than functions or capabilities, that are embedded within large systems. The proposed architecture should maintain loose coupling and minimized dependencies across services.

• Enterprise Scope: AES should support the implementation of services that meet the needs of multiple programs and systems.

• Incremental Development: AES should promote the incremental development of services

(i.e., Development, Security, Operations [DevSecOps]) that can be implemented more rapidly and produce operational benefits in the near and long term. By focusing on more immediate needs and priorities, incremental development avoids unnecessary work and rework resulting from speculation about potential future operations.

• Enable Opportunities for Reuse: AES should promote reuse by providing computing resources, platform software, and Mission Services so that, when appropriate, resources and services may be reused by future Mission Service developments.

Enhancements and amplification of some of these key concepts have led to the development of an AES layered service-based architecture, depicted in Figure 1: AES Technical Architecture, which includes the following.

1 See Attachment J-8, AES Technical Architecture, for more details.

2 See https://sam.gov/opp/3158fdd42ea54662bb89f24a70340c12/view https://sam.gov/opp/3158fdd42ea54662bb89f24a70340c12/view

• Mission Software Layer: Contains aviation-specific applications and services built leveraging the Software Platform Layer and Computing Resources Layer. Applications and services are built following modern architecture approaches (e.g., microservices).

• Standards-Based Software Platform Layer: Contains a set of enterprise services and tools made available to programs to maximize reuse and accelerate the development and deployment of capabilities. Includes Commercial-off-the-Shelf (COTS), Free and Open

Source (FOSS) components, and Cloud Platform as a Service (PaaS) offerings. These services and tools provide the environment/platform for the Mission Applications and

Mission Services.

• Computing Resources Layer: Includes end-user equipment, compute infrastructure, storage, Local Area Networks (LANs), and Wide Area Networks (WANs) that tie them together. Allows for the rapid availability of infrastructure and improved resiliency.

Examples of end-user equipment are workstations, displays, tablets, mice, trackballs, and keyboards. Examples of compute infrastructure are servers that run services, Operating

Systems (OSs), storage, Virtual Machines (VMs), and containers.

Figure 1: AES Technical Architecture

AES is a layered services-based architecture containing Mission Applications and/or Common

Mission Services at the Mission Software Layer, using the below definitions.

• Mission Service: Software components that provide the FAA with mission-specific data

(e.g., flight data) and computation functions (e.g., tracking, conflict probe). This software is deployed as a service within an authority domain that provides NAS data or functionality.

• Common Mission Service: A Mission Service that is exposed for use by other Mission

Services or mission partners that reside outside its authority domain.

• Authority Domain: A collection of mission applications, mission services, and/or common mission services of which the development, deployment, and operations are controlled by a designated program or group.

• Application Programming Interface (API): Provides access to functions within a

Mission Service or Common Mission Service.

Within an authority domain, services can also be classified as follows based on service dependencies:

• Application Service: An application that is deployed as a service and uses other composite and/or independent services to provide information to the user.

• Composite Service: A service that has dependencies on other applications or services to provide its data or functionality.

• Independent Service: A standalone service that provides data or functionality without dependencies on any other application or service.

3 AES IMPLICATIONS FOR CSS-FD

CSS-FD has complex interdependencies with existing operational programs and systems as well as additional programs and systems expected to become operational in the near future. AES provides information on how a service can be exposed and governed as a Common Mission

Service to be used by multiple authority domains. Doing this requires careful planning through the use of service encapsulation, bounded context, and API contract management.

Figure 2: Example CSS-FD - FMDS System to System InteractionError! Reference source not found. depicts an example of AES applied to CSS-FD and Flow Management Data and Services

(FMDS).

Figure 2: Example CSS-FD - FMDS System to System Interaction Utilizing AES

In this notional example, a mission user (an Airline Operations Center [AOC] dispatcher) accesses Common Mission Services through a more complex arrangement of applications and services orchestrated to provide flight planning and filing services, as well as interact with

FMDS services. Specifically, the AOC accessing flight planning functions within CSS-FD can take advantage of the Trajectory Modeling Service offered by FMDS to better support their

Trajectory Based Operations (TBO). This figure depicts the interaction among services as defined for the purpose of providing a NAS function to one or more applications or systems.

Common Mission Services are managed by separate programs but utilized across authority domains to support one another’s service offerings.

4 MULTI-PHASED CAPABILITIES IMPLEMENTATION APPROACH

The FAA has investigated two concepts that relate to how an airspace users (AUs) and flight data consumer exchange flight data with the NAS. The first was Unified Flight Planning and

Filing (UFPF), which addressed problems with how airspace users AUs submit planning and filing data to the NAS. The second was Flight Object Exchange Services (FOXS), which defined an enhanced approach to sharing NAS flight data with various data consumers. These two concepts have been unified under CSS-FD and are referred to as CSS-FD Flight Planning and

Filing (FP&F) and CSS-FD Flight Data Sharing (FDS), respectively.

The FP&F and FDS components have been further categorized into eight (8) capabilities and divided into two phases. Capabilities are segmented in this way so that the foundational elements are implemented first in Phase 1. Additional capabilities can then be realized as part of Phase 1 or with implementation of Phase 2 capabilities. The following table provides mapping for capability and description by phase for CSS-FD.

Table 1: CSS-FD Capabilities by Phase

Capability Description

Phase 1

1 Data Management and Security Framework: Enables flight planning, flight plan filing, and flight data sharing to include global flight data management functions (e.g., standardization, translation, reconciliation, and validation along with reconstitution) as well as security elements required for identity and access management.

2 Flight Planning and Flight Plan Filing: Supports the ingestion and routing of appropriate responses to submitted filing of a flight plan by enhanced airspace users (eAUs) via the FF-ICE method (enhanced flight plans [eFPLs]) as well as ingesting flight plans submitted by AUs via the legacy method. Also supports the

Flight Planning trial requests functionality for eAUs to explore “what-if” scenarios regarding their plan

3 Feedback by Reference: Provides information on airspace constraints or other restrictions for flight plans as part of the filing status and for trial requests.

4 Return ATC Preferences: Provides information and notification about changes impacting a flight that are made either manually or by automation to apply ATC preferences and/or Air Route Traffic Control Centers (ARTCC) adaptations.

Phase 2

5 Preliminary Flight Plan (PFP) Submission and Planning Status Response:

Supports the ingestion of PFPs and provides feedback based on known constraints.

6 Preliminary Flight Information Distribution: Provides preliminary flight plan filing information to Traffic Flow Management (TFM) automation.

Capability Description

7 Return ATC Preferences Enhancements: Enhances the Phase 1 Capability 4 to provide flight plan feedback from all ARTCCs on the flight plan trajectory for filed flight plans as well as for trial requests and PFPs.

8 Notification Service: Provides departure and arrival messages to the eAU.

4.1 PHASE 1 CAPABILITIES

These capabilities are described in more detail in the following subsections.

4.1.1 Capability 1: Data Management and Security Framework

Data Management and Security Framework is the foundational capability that enables flight planning, flight plan filing, and flight data sharing. This foundation includes global flight data management functions including data validation, mediation, conversion, and reconciliation, along with reconstitution and security elements required for identity and access management.

One part of the Data Management and Security Framework capability is Globally Unique Flight

Identifier (GUFI) management. A GUFI is a single reference for Flight and Flow Information for a Collaborative Environment (FF-ICE) information pertinent to a flight that is unique globally. If a GUFI is present in the flight plan, this capability will validate it. If a GUFI is not present, e.g., due to a legacy user, the system will create and assign a Unique Flight Identifier3. Both GUFIs and Unique Flight Identifiers allow for a consistent view of each flight and will be used for data matching.

In addition to GUFI management, data validation rules will be applied to the received flight plan message to determine if flight data is acceptable for processing based on syntax, semantics, and data values. Following the validation of the data, relevant business rules will be applied to each flight message for processing. Additionally, there will be reconstitution of flight data built into the system, so that NAS and non-NAS systems can efficiently obtain flight data upon start-up or system recovery to ensure system resiliency. This includes the storage of data, in the Flight

Object data store, for analysis or data reconstitution. The data store is managed by the Flight

Object data store management, which performs data storage management functions including, but not limited to, create, read, update, and delete data records.

Another large part of Data Management and Security Framework will be security management, including managing the identity and access privileges for interfacing systems and users. This will be done through managing data access rights to change current flight plan data, ensuring access rights to submit flight plans or access flight planning capabilities, and validating access and change rights to data subscriptions. Additionally, the Data Management and Security Framework will ensure data integrity, message authentication, data tagging and filtering, and non-repudiation as required by FAA policy.

Not only can data be in different formats, but there can also be redundant or conflicting flight

3 A Unique Flight Identifier is an internal flight identification tag similar to a GUFI but used internally by CSS-FD.

data from different systems. CSS-FD will use reconciliation to produce a single value for each flight data element using pre-defined business rules to determine the authoritative source4 in each context. This eliminates the need for consumers to develop and maintain their own means to reconcile flight data, enables a consistent set of flight data values being provided to all consumers, and ensures all CSS-FD users share a single situational awareness derived from the most appropriate data source(s) for each circumstance. The reconciled data is stored and maintained as a Flight Object and made available for CSS-FD services through the Flight Object data store5. CSS-FD will have a publication/subscription function that receives flight data from various authoritative sources, mediates the data, and then publishes it to eAUs6 and flight data consumers. Data tagging and filtering will aid in routing of messages and ensure the right data contents are delivered to the right data consumers. These data exchange functions will be enabled through SWIM Information Management Services (IMS/IMS-C) program which is discussed further in Section 5.5.

4.1.2 Capability 2: Flight Planning and Flight Plan Filing

For CSS-FD Phase 1, the Flight Planning capability is limited to trial requests, which allows users to explore “what-if” scenarios regarding their plan, and only available for eAUs. The Flight

Plan Filing capability, on the other hand, will support the ingestion and routing of appropriate responses to flight plan submissions by eAUs via the FF-ICE method as well as the ingestion of flight plans submitted by AUs via the legacy method from SWIM Flight Data Publication

Service (SFDPS). CSS-FD will receive, process, and disseminate the FF-ICE Flight Plan (i.e., FIXM). CSS-FD will also perform Air Traffic System (ATS) message format translation to exchange flight data through NAS Data Interchange Network (NADIN) Message Rehost (1486) to ATC automation systems using Air Traffic System (ATS) message format.

The Data Management aspect of Capability 1 will create a Flight Object at the first instance when flight data is received (e.g., schedule, track, filing information for both legacy and FF-

ICE) and perform the necessary data matching and reconciliation to match incoming flight data to the associated Flight Object as filing messages are exchanged. While the Data Management and Security Framework capability will provide the ability to validate data, mediate, and convert messages between data versions and formats, the Flight Planning and Flight Plan Filing capability will enable those messages to be routed between CSS-FD and other systems through network connections to NADIN and SWIM. Furthermore, CSS-FD will have the ability to determine the ATC facility(ies) with which to file the received flight plan and send that flight plan to the ATC facility through NADIN based on the content included.

For eAUs, CSS-FD will send an outbound message with an acknowledgement confirming the inbound message was successfully received (i.e., submission response) and filing status will be

4 The authoritative source will vary depending on the data. CSS-FD is the aggregator of data from authoritative sources and may be the authoritative source for data which will be determined during system design.

5 The Flight Object data store is the local CSS-FD repository for Flight Object information.

6 An eAU is an AU that is capable of using FF-ICE services. A GUFI is not sent back to an AU because the AU cannot accept that information in the current system.

sent with additional information. eAUs will receive the outbound messages through Information

Management Services in the Cloud (IMS-C). As needed, data reconciliation, conversion, and mediation will also be performed to facilitate the work of Capability 2.

As part of flight planning, eAUs will be able to submit trial requests to evaluate constraints for a desired route or alternatives for an existing filed flight plan. These trial requests will have no effect on the flight plan’s current Flight Object content and an eAU may submit multiple trial requests to evaluate constraints over time even without a filed flight plan. Capability 3 provides the information that is included in the trial responses. CSS-FD will not retain the trial request for future evaluation, but the eAU may use the results from the trial request to update their flight plan.

4.1.3 Capability 3: Feedback by Reference

Feedback by Reference7 is the ability to provide information on airspace constraints or other restrictions for flight plans as part of the filing status and trial request responses. The constraints and restrictions in Phase 1 will include the candidate constraints presented in Table 2.

Table 2: Constraints for Feedback by Reference

Category Constraint

Airspace Constraints • Special Use Airspace (SUA)

• Special Activity Airspace (SAA) o Temporary Flight Restrictions (TFRs) o Aerial Refueling Tracks/Anchors (AR) o Air Traffic Control Assigned Airspace (ATCAAs) o Altitude Reservations (ALTRVs) o Special Security Instructions (SSI) o Aircraft Hazard Areas (AHA)

• Warning Areas (non-Regulatory)

• Restricted Areas (Regulatory)

• Prohibited Areas (Regulatory)

• Alert Areas (non-Regulatory)

• Military Operations Areas (MOA) (non-Regulatory)

• Closed/Impacted Routes

7 This will pertain to PFPs once CSS-FD is fully implemented, but only filed flight plans and trial requests when implemented in Phase 1. PFPs are a Phase 2 capability to be further defined in a separate document.

Category Constraint

Traffic Management

Constraints

• Flow Evaluation Area (FEA)/Flow Constrained Area (FCA)

• Airspace Flow Program (AFP)

• Miles in Trail (MIT)/Minutes in Trail (MINIT)

• Ground Delay Program (GDP)

• Ground Stop (GS)

• Stop Restrictions

• Collaborative Trajectory Option Program (CTOP)

• Metering Restrictions

• Departure Spacing Program

• Reroute (TFM Advisory Required)

Resources

Constraints Due to

Weather

• Deicing

Runway Constraints • Closed Runway

• Runway Configuration at Departure/Destination

NAS Resources

Constraints

• Communication Constraints

• Navigation Aid (NAVAID) Status

• Radar

• Closed Taxiway

• Instrument Landing System (ILS)

• Global Positioning System (GPS) Status

• Outages

• Airport Closure

Others • Other Applicable Notice to Air Missions(s) (NOTAMs)

For filing status responses (created by Capability 2 to both the flight plan submission and flight plan update messages), the Feedback by Reference capability will provide feedback on the trajectory on which the flight will be cleared (Capability 3 will use the resultant trajectory from

Capability 4, if applicable), with indicators for changes from the previously filed flight plan. This capability also includes a re-evaluation service which provides updates to the eAU when constraints relevant to their flight have changed. As the trajectory results change, the corresponding filing status messages will be distributed.

For trial response, the feedback to the eAU will include relevant constraint information, and the eAU is then expected to assess the feedback and determine their course of action. As a one-time request and response, CSS-FD will not retain a record of trial request information, and therefore, will not provide updates to the previously generated trial response. The eAU could resubmit trial requests to assess constraints that may be updated over time prior to the flight departure.

4.1.4 Capability 4: Return ATC Preferences

The Return ATC Preferences capability provides information and notification about changes impacting a flight that are made either manually (i.e., ATC applies flight plan changes in En

Route Automation Modernization (ERAM) or by automation to apply ATC preferences and/or local Air Route Traffic Control Center (ARTCC) adaptations. These changes result in an update to planned flight information, such as an amendment to the filed flight plan or an FAA automation’s update to flight data. CSS-FD will process the amended flight plan or the flight data update message and identify additional constraints8 that are pertinent to the changed trajectory. The updated flight plan and flight data will be fused and stored in the Flight Object data store through functionality of Capability 1 with the creation of an updated Filing Status provided by Capability 2. The system then notifies the eAU with the new trajectory and references its constraints in the Filing Status message. Route automation adaptations that may be applied beyond the departing facility will be provided as feedback to the user increasing the probability of flying the entire desired route.

4.2 PHASE 2 CAPABILITIES

As a result of program segmentation, the following capabilities are expected to be included in

CSS-FD Phase 2. While Phase 2 scope has not yet been fully defined, the capabilities are notional and will be further defined after contract award. The timeline and scope of these capabilities will depend on the FAA funding availability and necessary approvals. The current

Phase 2 capabilities include the FF-ICE R1 functionality not included in Phase 1, so CSS-FD

Phase 1 and 2 cover both the mandatory and optional FF-ICE R1 functionality

Phase 2 capabilities are currently expected to include:

• Capability 5: Preliminary Flight Plan (PFP) Submission and Planning Status Response

• Capability 6: Preliminary Flight Information Distribution

• Capability 7: Return ATC Preferences Enhancements

• Capability 8: Notification Service

4.2.1 Capability 5: Preliminary Flight Plan Submission and Planning Status Response

This capability supports the ingestion and routing of appropriate responses to Preliminary Flight

Plans (PFPs) submitted by enhanced Airspace Users (eAUs) according to the FF-ICE concept. It involves receiving, processing, and distributing the PFPs while providing feedback based on known constraints. This capability ensures that preliminary flight information is accurately managed and communicated to relevant stakeholders, enhancing early planning and coordination efforts.

8 The identification of constraints is supported by Capability 3.

4.2.2 Capability 6: Preliminary Flight Information Distribution

CSS-FD will store and manage preliminary flight information in the FO for distribution to appropriate parties. This capability ensures that preliminary flight plan information is integrated with Traffic Flow Management System (TFMS)9 or FMDS. It supports the provision of preliminary flight plan data to TFM automation, enhancing traffic flow management and coordination.

4.2.3 Capability 7: Return ATC Preferences Enhancements

In Phase 1, Capability 4 provides a similar function to legacy operations today: providing flight plan feedback on ATC preferences and ARTCC adaptations. Phase 2 will expand this to have letters of agreement (LOAs), standard operating procedures (SOPs), and all domestic adaptations configured to provide true full departure to arrival airport en route feedback. In addition to providing this feedback for filed flight plans, this capability will also provide this feedback for trial requests and PFPs. This capability is expected to be foundational for FF-ICE Release 2.

4.2.4 Capability 8: Notification Service

Inclusion of flight departure messages and flight arrival messages will allow all exchanges to be via FF-ICE rather than depending on Aeronautical Message Handling System (AMHS, formerly

Aeronautical Fixed Telecommunications Network [AFTN]) for departure (DEP) and arrival

(ARR) messages. Messages sent from the eAU may be more accurate (if utilizing Out Off On In

[OOOI]) than DEP or ARR messages that are sent by NAS automation as they are derived in different ways.

4.3 CAPABILITY INTERDEPENDENCE

The Phase 1 descriptions, in most cases, build on other capabilities within CSS-FD and some of these service descriptions are interdependent on the implementation of other capabilities. Table 3 illustrates the minimum interdependencies and, in some cases, includes the assumed dependencies.

9 FMDS is expected to have replaced TFMS in the timeframe that CSS-FD services become operational.

Table 3: CSS-FD Capability Interdependencies

Capabilities Dependencies Explanation

1. Data

Management and

Security

Framework

None This capability is the building block of the other capabilities because it creates and maintains the Flight

Object and provides security management. This capability manages the received flight data from various sources. The data will be fused, reconciled, mediated/converted (if necessary), and stored as a

Flight Object. This capability also publishes flight data to the subscribers and responses to the data request.

2. Flight Plan

Filing

1 Capability 2 is dependent on Capability 1 functionality for the data management (e.g., data validation, data conversion, data matching and reconciliation) of the flight plans and for the security management.

Capability 2 provides the foundation for Capabilities 3 and 4. The relevant constraint feedback for the trial requests and filed flight plan included in Capability 2 are created by Capability 3, where applied ATC preferences are enabled by Capability 4.

3. Feedback by

Reference

2, 4 Capability 3 is dependent on Capability 2 to deliver constraints as part of flight planning (trial requests) and flight plan filing responses. Feedback by Reference could be implemented without Capability 4, but there is an interdependency where Capability 3 will provide additional constraints based on the ATC adjusted flight plan trajectory.

4. Return ATC

Preferences

1, 2 Capability 4 is dependent on Capabilities 1 and 2 for the data management functionality and the message handling. The ATC preferences are captured as flight data, fused, and stored in the Flight Object data store as part of the creation of the updated Filing Status.

Because of these interdependencies, it is important to not consider these capabilities as an “à la carte” menu. Choosing to or not to implement certain capabilities aside from what was divided between Phase 1 and Phase 2 may lead to rewriting the system requirements.

5 KEY NAS PROGRAM INTERDEPENDENCIES

Throughout the development lifecycle, CSS-FD will coordinate with key NAS programs providing maturation of services and information through System Wide Information

Management (SWIM). Outlined below are high-level descriptions of these programs with CSS-

FD interdependencies along with projected dates for program implementation and updates.

5.1 SWIM SEGMENT 3 (S3)

The SWIM program serves as the digital data-sharing backbone of the National Airspace

System (NAS) to implement the Next Generation Air Transportation System (NextGen) goals to enhance safety, reduce delay, save fuel and reduce environmental impact. SWIM has been implemented in phases: SWIM Segment 1, which introduced Service-Oriented

Architecture (SOA) to SWIM producers/consumers and a flight data publication system;

SWIM Segment 2A, which established a SOA infrastructure called the NAS Enterprise

Messaging Service (NEMS) under the L3Harris FAA Telecommunications Infrastructure

(FTI) contract; SWIM Segment 2B, which established security and monitoring capabilities for the infrastructure; SWIM Segment 2C, which included a Tech Refresh of SWIM equipment, a capacity expansion, the addition of the Message Reliability Quality of Service

(QoS) (B2) and Advanced Mediation (B15) failover capabilities, and the SWIM Cloud

Distribution System (SCDS); SWIM Segment 2D which will replace the NEMS architecture with the Information Management System (IMS) under the new FAA Enterprise Network

Services (FENS) contract with Verizon. The S2D improvements will retain all original

NEMS functionality with addition enhancements to the user interface via the External User

Portal (EUP), refined service ordering and provisioning, infrastructure that can support

Efficiency Critical service paths, and an IMS-Cloud (IMS-C) platform that will replace the existing SCDS cloud messaging system while adding a bidirectional message capability.

In SWIM Segment 3 (S3), the information sharing concept of SWIM and approach will not change. However, many enhancements will be provided to enable SWIM to support the transition of the NAS to begin to enable performance-based operations by providing improved aviation information in terms of usability and granularity, supporting efficiency-critical service threads, improved security protections, enhanced governance, and improving operational efficiencies. The following high-level NAS functions are supported/improved by this concept:

• The SWIM information exchange capabilities will be augmented with the introduction of

API Management, providing an enterprise capability to support the design, development, deployment, lifecycle management, and operational usage of APIs and API Gateways.

• SWIM Flight Data product generation via the SFDPS producer.

• Surface Data and Terminal Status product generation via the STDDS producer.

• Enterprise-level identity and access management services via the Identity and Access

Management (IAM) capability

• NAS Service Registry Repository (NSRR) for discoverability of SWIM services

To ensure a common view among decision makers, CSS-FD capabilities require automation applications logically interconnected through information flows, executed as events and queries, delivered over physical and logical networks (for example, event/service meshes) then integrated seamlessly in automation systems. SWIM Segment 3 provides the necessary enhanced services and capabilities to support these anticipated information flows that support the CSS-FD data supply chain.

5.1.1 SWIM Terminal Data Distribution Systems (STDDS)

STDDS converts raw surface data collected from airport towers and Terminal Radar Approach

Control (TRACON) facilities into easily accessible information, which is currently published via the NAS Enterprise Messaging Service (NEMS). Please note that in the near-future, this will transition over to Information Management Services (see Section 5.4 for more information on

IMS). STDDS will also leverage the SWIM Segment 2 Lost Message Retrieval service and

Efficiency-Critical SWIM infrastructure.

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 (currently only available to authorized

• users)

• TDLS - Tower Data Link Services (currently only available to authorized users)

S3 STDDS Enhancements

Upgrade architecture to support Efficiency-Critical requirements and a new centralized model with remote site consolidation into the ME Cloud.

• Planned Deployment: Feb 2028 - June 2028

STDDS data feeds consumed by CSS-FD that will be EC (see Attachment J-12, Flight Object

Workbook for more information regarding what data is included in these sources)

• Surface Movement Event Service (SMES) - YES

• Terminal Automation Information Service (TAIS) - YES

• Infrastructure, System Monitor and Control (ISMC) - NO

• Airport Data Service (APDS) - NO

• Tower Departure Event Service (TDES) – NO

5.1.2 SWIM Flight Data Publication Services (SFDPS)

The SWIM Flight Data Publication Service (SFDPS) program provides authorized consumers with access to NAS ERAM data. Services in SFDPS include:

• En Route Flight Data Publication & Query

• En Route Airspace Data Publication & Query

• En Route General Message Publication & Query

• En Route Operational Data Publication & Query

S3 SFDPS Enhancements

Upgrade to being hosted in a cloud environment, Efficiency-Critical and bi-directional data exchange with ERAM via En Route Data Distribution System (EDDS) / Host ATM Data

Distribution System (HADDS).

• Planned Deployment: July 2027 - Sep 2027

SFDPS data feeds consumed by CSS-FD that will be EC (see Attachment J-12, Flight Object

Workbook for more information regarding what data is included in these sources)

• All SFDPS data feeds

5.2 FLOW MANAGEMENT DATA AND SERVICES (FMDS)

FMDS is also being implemented in phases (referred to as steps). For more information on

FMDS, see https://www.faa.gov/fmds. There are 2 main interdependencies between these 2 programs:

• FMDS Step 2 has a dependency on CSS-FD for FDS as FMDS plans to consume the

CSS-FD FO. It is expected for CSS-FD to complete its Operational Testing prior to the

FMDS dependency needs for its Development Testing and integration. CSS-FD will need to reach a successful Operational Testing for the FDS requirements by the FMDS need date, projected to be FY 2028.

• CSS-FD will utilize the FMDS trajectory modeler service to generate four dimensional trajectories (4DTs) for both trial requests and filed flight plans. The FMDS trajectory modeler is expected to be available for CSS-FD to utilize by FMDS development phase, targeting 2028 timeframe.

CSS-FD and FMDS will work closely together to ensure the success of both programs.

5.3 SWIM PROGRAMS FOR FLIGHT OBJECT (FO)

As described in Attachment J-12, Flight Object Workbook, CSS-FD will ingest data from the eFPL filed by the eAU as well as other SWIM programs to generate the FO. These programs include SFDPS, STDDS, TBFM, TFDM, FMDS, and Advanced Technologies and Oceanic

Procedures (ATOP).

• eAU eFPL: Specific elements in the enhanced eFPL filed by the eAU that will be used to populate the FO.

• SFDPS: Provides en route flight data from ERAM systems. Updates planned as part of

S3.

• STDDS: Converts legacy terminal data collected from airport towers and TRACON facilities into easily accessible information, publishing data from multiple FAA airport and terminal systems. Updates planned as part of S3.

• TBFM: A foundational decision support tool for time-based management in the en route and terminal environments. TBFM's core function is the ability to schedule aircraft within a stream of traffic to reach a defined constraint point (e.g., meter fix/meter arc) at specified times, creating a time-ordered sequence of traffic.

• TFDM: A surface management solution used to o Modernize the air traffic control tower equipment by improving the exchange of electronic flight data and implementing electronic flight strips in the tower, o Streamline the flow of departures on the surface to save fuel and reduce CO2 emissions, and o Optimize the experience for the flying public, Air Traffic Control, and the airline industry by improving the collaboration and decision-making capabilities between the gate and the tower.

• FMDS: FMDS will replace the FAA's current TFMS and provide traffic flow management services to the NAS.

• ATOP: The ATOP program replaced the original oceanic air traffic control system, updated procedures, and modernized the oceanic automation systems located at Oakland

(ZOA/ZAP), New York (ZNY/ZWN), and Anchorage (ZAN/AZN) ARTCCs. As part of ongoing ATOP technical refreshes, ATOP plans to publish flight data to SWIM in the

2028 timeframe, which CSS-FD will consume.

5.4 FAA ENTERPRISE NETWORK SERVICES (FENS)

FAA Enterprise Network Services (FENS) program will provide highly available and secure communications, information services, and networking capabilities required to support NAS operations and agency administration functions. The FENS Program will acquire telecommunications services, information management services (to support SWIM data distribution capability), and specialized services such as Domain Name Service (DNS), time synchronization services, and enterprise-wide security solutions. The FENS contract will provide required system resources to support FAA-defined telecommunications and information management service needs at Service Delivery Points (SDPs) within FAA facilities and required field locations. FENS is expected to improve operational resiliency and messaging services at various sites, affecting both the operational and administrative domains.

FENS will support CSS-FD through the following objectives:

• Maintain the high levels of availability, survivability, security, and performance that are required for NAS mission critical applications.

• Provide dynamic service provisioning, reconfiguration and configuration management capabilities.

• Provide insight and visibility into the network service configuration and operations.

• Evolve to future technologies that may benefit both NAS and Administrative users.

• Manage initial and lifecycle costs for both NAS and administrative communications needs.

As Information Management Services (IMS) – a SWIM investment infrastructure change to support Efficiency-Critical level of messaging between NAS systems – will be delivered via

FENS resources, CSS-FD will also be dependent upon the FENS infrastructure. FENS will need to achieve successful operational capability for CSS-FD service and need requirements by the

CSS-FD IOC date, projected to be Fall 2028. If FENS is delayed, it will impact the deployment of CSS-FD.

5.5 SWIM SEGMENT S2D (S2D)10

SWIM Segment 2D (S2D) program will develop IMS on the FENS to replace NEMS on FAA

Telecommunications Infrastructure (FTI). The changes brought forth by S2D intend to expand

SWIM’s operational capabilities into the FAA Cloud platform. Planned changes relevant to CSS-

FD include:

• Enabling data exchange between external partners over the internet.

• Enabling international Air Navigation Service Providers (ANSPs) exchanges with NAS systems.

• Updates to support Efficiency-Critical RMA messaging infrastructure.

5.5.1 Information Management Services – in the Cloud (IMS / IMS-C)

As stated previously, IMS supports Efficiency-Critical Reliability, Maintainability and

Availability (RMA) messaging infrastructure and provides internal FAA and external user portals, including two-way communication functionality and sensitive data. IMS-C expands the

FAA’s cloud messaging capability to include Web Services, Java Message Service (JMS) and ingestion of content from external Producers (e.g. international ANSPs). Implementation of CSS-

FD is dependent upon the capabilities provided by IMS-C. IMS-C is planned to be in the baseline environment and will be available in the publicly accessible cloud to facilitate flight information exchanges between CSS-FD, eAUs, and flight data consumers. The interface is used for submittal of FF-ICE messages to the system and receipt of responses including feedback on applicable constraints.

At its core, IMS-C is a containerized system that will host its service and database containers.

IMS-C is composed of several types of messaging nodes with varying functions and purposes:

• Establishing an interface to SWIM Data Producers and Consumers

• Controlling Business Service, queue and topic provisioning to messaging nodes

10 FENS/IMS Relationship and CSS-FD Dependency: FENS is an investment that replaces FAA FTI capabilities with FENS networking and enterprise services capabilities. FTI NEMS infrastructure and associated services will be replaced by FENS IMS. SWIM S2D acquisition appropriates IMS, IMS-related portions of FENS and transition of SWIM users.

• Containing software baselines and allows for initial configuration of IMS nodes

• Contains test control and test producer/consumer components

In the Cloud National Test Bed (CNTB) environment, IMS-C will be developed and tested in preparation for end-state deployment to NCIS-managed Government Sponsored Cloud

Environment (GSCE) Mission Essential-Operating Environment (ME-OE). Within CNTB, IMS will be interoperable with NCIS-managed AWS infrastructure and FAA Enterprise capabilities such as IAM and Directory Services.

CSS-FD will ingest SWIM data transported via IMS-C. Early IMS-C integration testing with

SWIM data and CNTB NAS IAM are targeting Q4 2026 timeframe.

5.6 MISSION-ESSENTIAL (ME) CLOUD

CSS-FD will be deployed on the ME-Cloud platform, which will serve as the FAA cloud services enterprise resource that supports modernizing the FAA system/application development and deployment process for operational NAS services. The ME-Cloud platform will establish a standardized set of services, processes and capabilities to address CSS-FD infrastructure and platform service needs, enabling CSS-FD to take advantage of cloud service and enterprise infrastructure. These services include:

• Infrastructure Services including computing processor, memory and storage resources

• Platform Services with common shared tools, capabilities and services for all programs

• Cloud Core Services for connectivity, security, operations and account management, including internetworking, provisioning, scalability, fault, performance and security monitoring, management and control

ME-Cloud is already the preferred platform for CSS-FD; however, ME-Cloud Infrastructure, Platform and Cloud Core Services will need to reach successful operating capability for CSS-FD service and need requirements by the CSS-FD IOC date, projected to be Fall 2028. If ME-Cloud is delayed, it will impact the deployment of CSS-FD.

5.7 NAS COMMON REFERENCE (NCR)

CSS-FD will utilize constraint information provided by NAS Common Reference (NCR). The

CSS-FD Program Office will transition NCR, so it is deployed on the ME-Cloud, which is yet to be scheduled.

NCR Enhancements

Upgrade to support CSS-FD Efficiency-Critical requirements and increased simultaneous user subscription count.

• Expected Deployment: FY2025 – FY2026

6 FAA PRIORITIES AND INCENTIVE STRUCTURE

The FAA will utilize a combination of cost, schedule, and technical incentives as part of this contract. The Screening Information Request (SIR) includes incentives in all of these areas, and offerors can propose additional incentives as part of their proposals. The FAA places a high priority on the contractor producing a quality product with particular emphasis on the FDS Key

Site Acceptance milestone.

APPENDIX A – ACRONYMS AND ABBREVIATIONS

Acronym/Abbreviation Definition

4DT Four Dimensional Trajectories

AES Automation Evolution Strategy

AFP Airspace Flow Program

AFTN Aeronautical Fixed Telecommunications Network

AHA Aircraft Hazard Area

ALTRV Altitude Reservation

AMHS Aeronautical Message Handling System

ANSP Air Navigation Service Provider

AOC Airline Operations Control/Center

APDS Airport Data Service

AR Aerial Refueling Tracks/Anchors

ARR Arrival

ASP Air Service Provider

API Application Programming Interface

ARTCC Air Route Traffic Control Centers

ATC Air Traffic Control

ATCAA Air Traffic Control Assigned Airspace

ATOP Advanced Technologies and Oceanic Procedures

ATS Air Traffic System

AU Airspace User

AZN ATOP Anchorage ARTCC

CLIN Contract Line Item

CNTB Cloud National Test Bed

COTS Commercial-off-the-Shelf

CSS-FD Common Support Services – Flight Data

CPIF Cost Plus Incentive Fee

CTOP Collaborative Trajectory Option Program

DEP Departure

DevSecOps Development, Security, and Operations

DNS Domain Name Service

DOT Department of Transportation eAU Enhanced Airspace User

EC Efficiency Critical

EDDS En Route Data Distribution System eFPL Enhanced Flight Plan

ERAM En Route Automation Modernization

FAA Federal Aviation Administration

FCA Flow Constrained Area

FEA Flow Evaluation Area

FDS Flight Data Sharing

FENS FAA Enterprise Network Services

FF-ICE Flight and Flow – Information for a Collaborative Environment

FFP Firm Fixed Price

FIXM Flight Information Exchange Model

FO Flight Object

FMDS Flow Management Distribution Service

FNTB FAA National Test Bed

FOSS Free and Open Source

FOXS Flight Object Exchange Services

FP&F Flight Planning and Filing

FTI FAA Telecommunications Infrastructure

GDP Ground Delay Program

GPS Global Positioning System

GS Ground Stop

GSCE Government Sponsored Cloud Environment

GUFI Globally Unique Flight Identifier

HADDS Host ATM Data Distribution System

IAM Identity and Access Management

ICAO International Civil Aviation Organization

ILS Instrument Landing System

IMS-C Information Management Services in the Cloud

IOC Initial Operating Capability

ISMC Infrastructure, System Monitoring and Control

JMS Java Message Service

LAN Local Area Networks

LOA Letter of Agreement

ME Mission Essential

ME-OE Mission Essential-Operating Environment

MINIT Minutes in Trail

MIT Miles in Trail

MOA Military Operations Area

NADIN NAS Data Interchange Network

NAS National Airspace System

NAVAID Navigation Aid

NEMS NAS Enterprise Messaging Service

NOTAM Notice to Air Missions

NSRR NAS Service Registry and Repository

OOOI Out Off On In

OS Operating System

PaaS Cloud Platform as a Service

PFP Preliminary Flight Plan

RMA Reliability, Maintainability and Availability

SAA Special Activity Airspace

SDP Service Delivery Points

SFDPS SWIM Flight Data Publication Service

SLA Service Level Agreement

SMES…