DRAFT SIR CSS-FD Attachment J-0.pdf

Solicitation # Attachment J-0

Federal Aviation Administration

Common Support Services – Flight Data (CSS-FD)

CSS-FD Strategy

September 2023

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.3 CAPABILITY INTERDEPENDENCE

5 KEY NAS PROGRAM INTERDEPENDENCIES

5.1 FLOW MANAGEMENT DATA AND SERVICES (FMDS)

5.2 IMS-C

5.3 SWIM SEGMENT 3

APPENDIX A – ACRONYMS AND ABBREVIATIONS

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 ii

1 INTRODUCTION

The purpose of this document is to identify the Federal Aviation Administration’s 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 does 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, the utilization of business rules as a more agile alternative to hard coding, 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.

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.

This document does not contain or imply any functional or performance requirements, nor should it be interpreted as guidance or direction for how to architect a solution for CSS-FD.

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.

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

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

• 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, which includes the following.

• 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 the 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 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 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 is able to take advantage of the trajectory 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 AU 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. Under CSS-FD a business rules engine will facilitate decision-making, automation, and orchestration of services for FP&F and FDS.

The FP&F and FDS components have been further categorized into seven 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 AUs (eAUs) via the FF-ICE method 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 Submission: Supports the ingestion of Preliminary

Flight Plans, provides feedback based on known constraints, and distributes flight planning information as appropriate.

6 Consumer-Specified Data Filtering: Provides information to users based on requests from consumers with data filtering criteria and subscription.

Capability Description 7 Preliminary Flight Plan Integration with TFMS/FMDS: Provides preliminary flight plan filing information to Traffic Flow Management (TFM) automation.

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 Identifier2. 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, the Business Rules Engine (BRE) will determine the rules that should 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 strengthen system resiliency. This includes the storage of data, in the Flight Object data store, for later analysis, data reconstitution, and recall for planning and investigation purposes. 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.

It is known that the system will operate in a mixed mode environment where flight data will not

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

always be provided from users in a common format, so the CSS-FD Data Management and Security Framework capability will be able to perform data mediation and conversion. Data mediation is the ability to accept and translate between FIXM versions (e.g., FIXM 4.2 to FIXM 3.0). Data conversion is the ability to convert data to format extensions required by external systems (e.g., International Civil Aviation Organization (ICAO) 2012 to FIXM 4.2).

Not only can data be in different formats, but there can also be redundant or conflicting flight 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 source3 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 store4. CSS-FD will have a publication/subscription function that receives flight data from various authoritative sources, mediates the data, and then publishes it to eAUs5 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. Other than a submission response, which is acceptable for both AUs and eAUs, only eAUs will have the ability to receive the additional outbound messages from CSS-FD.

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 information from the flight plan in FF-ICE format (i.e., FIXM) through NAS Data Interchange Network (NADIN) Message Rehost (1486) to the ERAM system using Air Traffic System (ATS) message format.

The Data Management aspect of Capability 1 will create a Flight Object at the first instance when the filing request (for both legacy and FF-ICE) is received 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. Furthermore, CSS-

3 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.

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

5 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.

FD will have the ability to determine the ATC facility with which to file the received flight plan and send that flight plan to the ATC facility in the form needed 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 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 the 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 Reference6 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 Activity Airspace (SAA), Special Use Airspace (SUA), ATC

Assigned Airspace (ATCAA)

• Closed/Impacted Routes

• Prohibited Areas

• Altitude Reservation (ALTRV)

Traffic Management Constraints

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

• Airspace Flow Program (AFP)

• Miles in Trail (MIT)/Minute 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)

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

Category Constraint 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)

• Ground Positioning System (GPS) Status

• Outages

• Airport Closure

Others • Other Applicable Notice to Airmen(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 planning 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 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 constraints7 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.

4.2 PHASE 2 CAPABILITIES

As a result of program segmentation, three capabilities are expected to be included in CSS-FD Phase 2. Because Phase 2 scope has yet been fully defined, the capabilities are listed, but detailed descriptions will not be provided in this document.

Phase 2 capabilities include:

• Capability 5: PFPL Submission

• Capability 6: Consumer-Specified Data Filtering

• Capability 7: PFPL Integration with TFMS/FMDS

4.3 CAPABILITY INTERDEPENDENCE

The seven capabilities described, in most cases, build on other capabilities and some of the capabilities are interdependent on the implementation of other capabilities. Table 3 illustrates the minimum interdependencies and, in some cases, includes the assumed dependencies.

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 six 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.

7 The identification of constraints is supported by Capability 3.

Capabilities Dependencies Explanation

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.

5. PFPL

Submission

1 or 2 PFPLs could be implemented without Capability 2.

However, because the program chose to implement Capability 2 in Phase 1 and Capability 5 in Phase 2, it is assumed there is a dependency on Capability 2 due to the overlapping functionality.

6. Consumer- Specific Data Filtering

1 The minimum dependency for Capability 6 is Capability 1. However, this would mean there is no planning and filing functions, only flight data sharing;

so it is unlikely this would be implemented without the benefits other capabilities provide.

7. PFPL Integration with TFMS/FMDS

5 Capability 7 is dependent on Capability 5, which is foundational to provide future integration with

TFMS/FMDS.

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). This includes FMDS enhancements to trajectory services, enterprise infrastructure and services improvements in the FAA Enterprise Network Services (FENS) Information Management Services (IMS), and SWIM advancements for efficiency critical services for SWIM Terminal Data Distribution System (STDDS) and SWIM Flight Data Publication Service (SFDPS).

CSS-FD’s development schedule will align with these key NAS maturation milestones. Outlined below are the notional schedules along with the high-level descriptions for these key programs.

5.1 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/atmm. FMDS Step 2 has a dependency on CSS-FD for FDS.

CSS-FD will need to reach a successful initial operating capability (IOC) for the FDS requirements by the FMDS need date, projected to be July 2028. The Contractor may provide intermittent software releases.

The remaining requirements will be prioritized second, with schedule milestones to be proposed by the Contractor in accordance with Section F.

5.2 IMS-C

Implementation of CSS-FD is dependent upon the capabilities provided by Information Management Services in the Cloud (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.

5.3 SWIM SEGMENT 3

SWIM Segment 3 will incorporate enhancements to SWIM Flight Data Publication Service (SFDPS) and SWIM Terminal Data Distribution System (STDDS). These enhancements include upgrades to support efficiency critical (EC) requirements and are expected to be available in the baseline environment. Both SFDPS and STDDS will serve as data inputs for CSS-FD.

APPENDIX A – ACRONYMS AND ABBREVIATIONS

Acronym/Abbreviation Definition

AES Automation Evolution Strategy

AOC Airline Operations Control/Center

API Application Programming Interface

COTS Commercial-off-the-Shelf

CSS-FD Common Support Services – Flight Data

DevSecOps Development, Security, and Operations eAU Enhanced Airspace User

EC Efficiency Critical

FAA Federal Aviation Administration

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

FMDS Flow Management Distribution Service

FOSS Free and Open Source

IMS-C Information Management Services in the Cloud

IOC Initial Operating Capability

LAN Local Area Networks

NAS National Airspace System

NSRR NAS Service Registry and Repository

OS Operating System

PaaS Cloud Platform as a Service

SFDPS SWIM Flight Data Publication Service

STDDS SWIM Terminal Data Distribution System (STDDS)

TBO Trajectory Based Operations

TFMS Traffic Flow Management System

Appendix A – Acronyms and Abbreviations