Attachment 2 FMDS fPRD 250918.pdf

United States Department of Transportation Federal Aviation Administration

Flow Management Data and Services (FMDS)

Final Program Requirements Document (fPRD)

FINAL, Version 1.3

February 18, 2025

THIS PAGE INTENTIONALLY LEFT BLANK

Flow Management Data and Services Final Program Requirements Document

Table of Contents 1 Introduction

1.1 Description

1.2 Scope

2 Capability Description and Program Information

2.1 Operational Concept

2.2 Quantities and Location

2.3 Constraints and Assumptions

3 FUNCTIONAL, INFORMATION AND PERFORMANCE REQUIREMENTS

3.1 Functional Requirements

3.2 Data and Information Requirements

3.3 Performance Requirements

3.4 Reliability, Maintainability, and Availability (RMA) and Resiliency Requirements

4 INTEGRATION REQUIREMENTS

4.1 Physical Integration

4.2 Functional Integration

4.3 NAS Integration

4.4 Human Factors

4.5 Employee Safety and Health

5 SECURITY AND SAFETY REQUIREMENTS

5.1 Security Requirements

5.2 Safety Requirements

6 QUALITY AND CONFIGURATION MANAGEMENT REQUIREMENTS

6.1 Quality Assurance

6.2 Configuration Management

7 TEST AND EVALUATION REQUIREMENTS

7.1 Planning and Test Design

7.2 Development Test

7.3 Operational Test

7.4 Site Test

7.5 Reporting

7.6 Test Support

7.7 Critical Operational Issues (COIs)

7.8 Independent Operational Assessment

8 IMPLEMENTATION AND TRANSITION REQUIREMENTS

9 IN-SERVICE SUPPORT AND MANAGEMENT REQUIREMENTS

9.1 Integrated Logistics Support (ILS)

9.2 Maintenance Planning

9.3 Supply Support

9.4 Packaging, Handling, Supplies, and Transportation (PHS&T)

9.5 Support Equipment Maintenance

9.6 Direct-Work Maintenance Staffing

9.7 Maintenance Support Facilities

9.8 Training, Training Support, and Personnel Skills

9.9 Technical Data

Appendix 1: Reference Documents

Appendix 2: Acronyms and Glossary Terms

Appendix 3: Critical Performance Requirements (CPRs)

Appendix 4: RMA Functional Groupings

Appendix 5: Security Control Requirements

Appendix 6: Program Requirements Traceability and Verification

1 Introduction The fundamental goal of Traffic Flow Management (TFM) is to strategically manage the flow of air traffic to minimize delays and congestion in response to changing weather and system constraints. TFM promotes a safe, orderly, and expeditious flow of traffic that minimizes delays through analysis, coordination, and dynamic utilization of Traffic Management Initiatives (TMIs). Today, the Traffic Flow Management System (TFMS) provides tools to support balancing National Airspace System (NAS) capacity and (growing) flight demand within a dynamic environment.

However, those tools have reached end of life and are exhibiting reliability, maintainability, and availability (RMA) and other performance shortfalls.

In recent years, TFMS user expectations for RMA and performance have increased to a point that exceeds the current system capability. A recent technical refresh at the TFMS Remote Sites (TRSs) was unable to address all the performance issues, and the obsolescence of the current software may preclude another technical refresh [1]. The TFMS Program Office investigated the root causes of TFMS outages, identified system shortfalls, and developed recommendations, with the goal of improving RMA and performance [2] [3]. The TFMS Program Office is pursuing many of these recommendations as part of the Flow Management Data and Services (FMDS) program.

This final Program Requirements Document (fPRD) describes the high-level requirements for FMDS that conform to the selected alternative and expand on the requirements in the preliminary Program Requirements Document (pPRD) with information obtained during the Final Investment Analysis (FIA) phase of the Acquisition Management System (AMS) process. This fPRD was developed in accordance with the Federal Aviation Administration's (FAA's) Program Requirements Document Template [4] with use of the FAA’s Target NAS Requirements Document (TNRD) [5].

1.1 Description

TFMS has evolved over several decades, from the original Enhanced Traffic Management System (ETMS) automation prototype to the architecture and functionality seen in FAA air traffic facilities today. Capabilities were developed in a piecemeal fashion and deployed onto an aging infrastructure making maintenance and updates challenging. The requirements put forth in this fPRD account for all current TFMS functions, as well as some planned enhancements, and provide an initial foundation to address the shortfall areas identified in the FMDS Shortfall Analysis Report (SAR) [1] and listed below.

• Unacceptable performance and a lack of expandability and scalability prevents TFMS from meeting evolving needs.

• Lack of a comprehensive failover strategy prevents continuity of operations.

• Lack of integrated capabilities prevents consistent operational system-wide views, operational decision making, and usability of the system.

FMDS is accounted for in the FAA NAS Enterprise Architecture (EA) Airport and Automation Roadmaps as shown in Figure 1 and Figure 2.

Figure 1. NAS EA Airport Roadmap

Figure 2. NAS EA Automation Roadmap

FMDS aligns to the NextGen Operational Improvement (OI) Increments summarized in Table 1, as described in the FMDS Concept of Operations (ConOps) v1.31 [6].

Table 1. FMDS Alignment to OI Increments ID Number OI Increment Description 1 105211-01 Integrated Departure Route Planning 2 105210-04 Aircraft Equipage Eligibility During TMIs 3 105210-01 Improve Demand Predictions 4 105210-02 Integrate TMI Modeling 5 105303-24 Enhanced Post Operations 6 105210-03 Improved Integration of Traffic Flow Management Operations

FMDS is a solution-level concept, as illustrated in Table 2.

Table 2. FMDS Concept Alignments Level Layer Concept

0 Global ICAO Doc 9971: Manual Collaborative Air Traffic Flow Management 1 Enterprise Charting Aviation's Future - Operating in an Info-Centric NAS Enterprise

Information Management 2 Service Performance-Based Flow Management (PBFM)

FFM: The Corporate Plan for Future TFM Collaborative Air Traffic Management System Wide Information Management (SWIM)

3 Sub-Service N/A 4 Solution FMDS

1.2 Scope

The FMDS ConOps describes a replacement system that provides a streamlined experience for the full array of users internal and external to the FAA. FMDS plans to include all the functionality of the current TFMS through R16 and provide a foundation to achieve future FAA goals. FMDS functions are summarized as:

• Manage Data - Ingests and processes external data sources including flight, weather, aeronautical, Collaborative Decision Making (CDM), and space data to create a common model of NAS operations based on available data and supporting algorithms. This includes the derivation of additional data (e.g., modeled trajectories, weather analysis) and the provision of data for use by FMDS services and external automation and users.

• Assess NAS State - Evaluates the current and projected state of the NAS and enables Traffic Managers to identify near- and long-term problems to determine whether mitigating actions are needed.

• Conduct Traffic Flow Management - Provides tools to Traffic Managers to maintain the flow of air traffic in the NAS by defining Flow Evaluation/Constraint Areas (FxAs), conducting TMIs for balancing demand and capacity, and logging NAS events.

• Conduct Post-Event Analysis - Employs historical data to improve trajectory and demand algorithms, enable the replay capability, and generate reports of past data.

• Manage Display - Manages the user interface display and configuration settings of the display, as well as allows users to capture their workstation screen activity for post-event analysis and training purposes.

• Maintain Operations - Records and archives operational data, maintains FMDS adaptation, monitors and controls the operational system, analyzes system performance, maintains user access and identities, and supports test and training.

1.2.1 Baseline Capabilities

FMDS will provide all capabilities currently provided by TFMS, with the following exceptions:

• Capabilities that other programs will provide in the future. For example, CSS-Wx and CSS-FD will perform some of the weather and flight data processing functions performed by TFMS today. For example, CSS-Wx will provide the Weather Avoidance Field (WAF) grid generated by TFMS today.

• Capabilities currently provided by TFMS that are unused in the current environment and no longer necessary.

Stakeholder feedback throughout the requirements development process identified capabilities no longer required.

1.2.2 Enhanced Capabilities

FMDS will provide all capabilities that were baselined as part of TFMS Enhancement 4 (E4) [7] and/or requirements levied on TFMS by the Terminal Flight Data Manager (TFDM) Program [8]. The E4 requirements comprise two capabilities: the Integrated Departure Route Planning (IDRP) (OI Increment 105211-01) and Improving Demand Predictions (IDP) (OI Increment 105210-01). The functionality required for these capabilities that is not currently available in TFMS but will be deployed with FMDS is summarized below.

1.2.2.1 Data Exchange

• Ingest airport configuration data from TBFM.

• Exchange departure sequencing data and surface viewer data with TFDM.

1.2.2.2 Departure and Airport Resource Management

• Ability for traffic managers to view status of airport/runway line-ups at all airports feeding shared Metroplex departure fixes (existing Departure Spacing Program [DSP] capability) for selected Metroplexes,

• Capability for Air Traffic Control Towers (ATCT) and Air Route Traffic Control Center (ARTCC)/Terminal Radar Approach Control (TRACON) facilities traffic managers to tactically coordinate departures to manage departure flows more efficiently (existing DSP capability), and

• Airport Resource Management Tool (ARMT) departure efficiency analysis and reporting to replace the standalone tool currently deployed at 30+ Air Traffic Control (ATC) facilities.

1.2.2.3 Improved Departure Time Prediction

• Use historical data to predict ground times between ground events and wheels-off (during deicing events and otherwise),

• Use available surface data and historical ground times when determining time-out delay for individual flight departure times,

• Determine quality of CDM times based on historical variance (i.e., between CDM times and actual times), and

• Use CDM times and available surface event data to predict individual flight departure times.

1.2.2.4 Improved Trajectory Modeling

• Use historical and planned altitude and speed changes when modeling trajectories,

• Use metering information (e.g., TBFM Scheduled Times of Arrival [STAs] and Estimated Times of Arrival [ETAs]) when modeling trajectories, and

• Apply effects RNAV arrival route effects when modeling trajectories.

1.2.2.5 Restriction and TMI Modeling

• Apply the effects of Miles-In-Trail (MITs)/Minutes-In-Trail (MINITs) when modeling trajectories,

• Apply the effects of altitude (ALT) and deicing restrictions when modeling trajectories, and

• Apply the effects of existing restrictions when modeling and implementing TMIs (i.e., Ground Delay Programs

[GDPs], Ground Stops [GSs], Airspace Flow Programs [AFPs], and Collaborative Trajectory Options Programs [CTOPs]).

1.2.2.6 Probabilistic Demand Prediction

• Determine variance and error distributions between historical demand predictions and actual events, and

• Calculate probabilistic demand counts using error distributions.

1.2.2.7 Automated Problem Resolution

• Generate user-requested problem resolutions, with implied impacts, for one or more alerted departure fixes.

1.2.2.8 Alternatives Modeling

• Model departure route alternatives associated with, but not limited to:

o Departure fix/route closures, o MIT restrictions over departure fixes/routes, and/or o Changing fix alert thresholds or adjustments to Problem Resolution automation.

• Calculate the impact of the chosen alternative.

2 Capability Description and Program Information

2.1 Operational Concept

Figure 3 provides an overview of the FMDS concept as described in the FMDS ConOps v1.31 [6]. FMDS users internal to the FAA will access most of the information needed to perform the key TFM collaboration and decision-making functions through an integrated situation awareness display. FMDS users external to the FAA (e.g., NAS users) will access the TFM information through a streamlined suite of FMDS applications and data. Access to these applications will be configurable based on individual users and their role(s). Users of FMDS are delineated in Table 3.

Table 3. FMDS Users

User Group Description

NAS Users Flying public, including private pilots and small operators, and non-CDM air carriers (passenger and cargo).

CDM Members Representatives from government, general aviation, airlines, and private industry that collaborate to support TFM decision making.

Traffic Managers

Air Traffic Control System Command Center (ATCSCC) and Traffic Management Unit (TMU) personnel that use FMDS to monitor demand and capacity and, as needed, to model, implement, and maintain TMIs. Includes AJR and AJT personnel at various facilities.

ATC Personnel

Personnel at ATC facilities that use FMDS to maintain situation awareness of TFM activities, including Operations Supervisors, Operations Managers, and Air Traffic Controllers. Includes international ATC organizations.

Military Military users of FMDS.

Flight Plan Service

Providers Provide TFM data on behalf of their customers to support flight planning and re-planning.

Post-event Analysts Any user conducting analyses after real-time operations.

Adaptation Specialists Personnel that maintain the set of adaptation data used by FMDS.

Maintenance Specialists System maintenance personnel that monitor the status of system hardware, software, and network components and interfaces, perform diagnostics checks, and execute

User Group Description system-level actions (e.g., set operation mode, shut down/restart processors, enable/disable external interfaces, select software version).

System Administrators Administration personnel that maintain user roles, assignments, and authorizations.

System Testers QC personnel that use FMDS’ scenario capability to test system function.

Training Instructors Personnel overseeing training activities. Responsible for scripting and reviewing student run-throughs.

Trainees Users being trained on FMDS capabilities.

FMDS will impact stakeholders in different ways as summarized below:

• Traffic managers will experience increased productivity in conducting their TFM activities. FMDS will relieve traffic managers from manual entry of data from one application into another by automating these processes.

Traffic managers will access TFM information and capabilities from a single integrated situation awareness display rather than having to switch back and forth between applications.

• NAS Users will have access to improved situation awareness of NAS status and operations through the centralized portal for NAS status information. NAS users will be able to exchange data with FMDS using the same capabilities they use today except for CDM members who use Flight Schedule Monitor (FSM) and the web-based Traffic Situation Display (TSD) Thin Client since these specific applications will not be part of the FMDS architecture.

• Maintenance Specialists will be able to deliver improved RMA with a reduced hardware and logistics footprint.

The modernization envisioned for FMDS will change the technologies employed and the skills needed for system support.

• Post-Event Analysts and System Testers supporting the post-event, quality control, and quality assurance processes will have improved access to the data they need to build an understanding of NAS operations.

• System developers will have an improved ability to develop and deploy new capabilities in a timely and efficient manner. FMDS will provide a more modern architecture that allows for expedited and simpler system development.

• FMDS Program Office will benefit from improved return on investments in system development and maintenance. The modernized FMDS architecture and envisioned development and deployment strategy may require new approaches for contract management and configuration management.

FMDS will deliver gravely needed updates to today’s TFM environment that will benefit all stakeholders and will facilitate future enhancements in TFM decision support that cannot be accommodated with today’s infrastructure.

FMDS will improve operational availability and system reliability, system response times, and remote site equipment maintenance. It will implement failover strategies that maintain a full suite of FMDS services during system upgrades and provide better management of outages, component failures, and major disaster failures. The FMDS applications will exchange data with an underlying suite of common services using Application Programming Interfaces (APIs) designed according to approved industry standards.

Figure 3. FMDS To-Be High-Level Concept Overview

System enhancements will be provided through applications and services developed and deployed using a set of practices that automates processes between development, security, and operations teams to build, test, and release incremental software improvements rapidly and reliably. This process is envisioned to be one of continuous exploration of enhancements that, once tested, are deployed via automated processes that ensure continuous synchronization between operational and test environments. FMDS will release new features into the operational environment on-demand instead of as part of large, periodic system updates. FMDS will streamline and standardize the data exchange interfaces within the TFM automation system as well as the external interfaces between the TFM automation system and other NAS automation systems.

2.2 Quantities and Location

FMDS processing capabilities will be hosted in geographically disperse locations that support a primary and contingency operational capability. The FMDS architecture and infrastructure are still under development; however, current plans are for FMDS software architecture to be off-prem, native cloud focused, and for central computing operations to be served as an Infrastructure-as-a-Service (IaaS).

FMDS will provide end user hardware and networking capabilities for the following FAA facilities:

• The ATCSCC

• Twenty-one U.S. ARTCC facilities

• Three Combined En Route/Radar Approach Control (CERAP) facilities

• Five Regional offices

• Thirty-five U.S. TRACON facilities

• Seventeen ATCT facilities

• Other FAA facilities, including the Emergency Operations Center (EOC), FAA Headquarters, FAA Academy, and William J. Hughes Technical Center (WJHTC)

• Facilities identified to use ARMT but not TFMS:

• Kalamazoo Tower/TRACON (AZO)

• Kalamazoo/Battle Creek International Airport

• Central Florida TRACON (F11)

• Fort Lauderdale Tower (FLL)

• Memphis TRACON (M03)

• West Palm Beach Tower/TRACON (PBI)

• Palm Beach International Airport

At this time, the FAA has not determined if FMDS will provide hardware and networking capabilities for the non-FAA locations currently supported by TFMS. These facilities may be responsible for providing the hardware and networking necessary to access FMDS data and services. The locations currently receiving FAA support for TFMS are as follows:

• Military and other non-FAA government sites, including:

o North American Aerospace Defense Command (NORAD) o Air and Marine Interdiction Coordination Center (AMICC)

• International ATC sites:

o United Kingdom (London) o Eurocontrol o Mexico o Chile o Central American Corporation for Air Navigation Services (COCESNA) o Colombia o Canada

• Other undisclosed US Government locations as designated by the FMDS program

• Approximately thirty CDM airline sites and six contractor sites

2.3 Constraints and Assumptions

2.3.1 Constraints

The following constraints impact the technical and operational environment for the FMDS concept:

• Implementing FMDS will not impose changes on other NAS systems that are not specified in baselined requirements documents.

• FMDS will be designed and implemented in a manner consistent with existing agreements with the CDM community. This includes data and functionality provided to CDM members.

• Deployment of FMDS should be coordinated with the deployment or maintenance of other critical NAS systems to avoid interference.

• Implementation of FMDS should not complicate traffic managers’ current working environment or require additional floor space in the field facilities.

• FMDS user interfaces will be designed with an emphasis on maximizing usability and transferability of TFMS users’ knowledge to the new system.

• FMDS requirements based on criticality of the system to the NAS may constrain the options for FMDS architecture and hosting.

• FMDS options for data exchange standards may be constrained if FMDS needs to maintain legacy interfaces between NAS automation systems.

• The projected Contract Award date is Q1 CY2025 with Initial Operating Capability (IOC) date in Q4 CY2029.

2.3.2 Assumptions

This document includes the following assumptions about the FMDS operational and technical environment:

• FMDS will be deployed in a NAS automation environment that is evolving to embrace new processes and technologies such as enterprise services; Cloud computing; DevSecOps (Development, Security, and Operations); continuous testing and continuous integration practices; and Agile acquisition, software development, and deployment processes [9] [10].

• FMDS will be implemented in an operational environment characterized by the increased use of Time-Based Management (TBM), arrival pre-conditioning, and other flow management improvements deployed by NAS-wide initiatives such as Trajectory Based Operations (TBO) and the FAA Metroplex Program.

• FMDS will leverage new and existing SWIM services for receiving relevant data as appropriate.

• CDM Members will continue to be active participants in TFM by providing the necessary data to FMDS in a timely and effective manner and participating in planning webinars as they do today.

• NAS users will transition away from legacy data exchange interfaces (ARINC, AOCNet), to use SWIM data exchange interfaces (TFMData Request/Reply). Note that advisories and Expect Departure Clearance Times (EDCTs) will continue to be disseminated via teletype in addition to modern data exchange methods to support a broad range of NAS users.

• FMDS will utilize, or be integrated with, services developed by other FAA programs as appropriate based on related functionality and deployment schedule, including Common Support Services-Weather (CSS-Wx) and Common Support Services-Flight Data (CSS-FD). While the schedule and integration with CSS-Wx and CSS-FD are not known at this time, FMDS will not create a dependency on either of these programs that negatively impacts the FMDS deployment schedule.

3 FUNCTIONAL, INFORMATION AND PERFORMANCE

REQUIREMENTS

3.1 Functional Requirements

3.1.1 Manage Data (F.1)

Ingests and processes external data sources including flight, weather, aeronautical, CDM, and space data to create a common model of NAS operations based on available data and supporting algorithms. This includes the derivation of additional data (e.g., modeled trajectories, weather analysis) and the provision of data for use by FMDS services and external automation and users.

3.1.1.1 Ingest Data (F.1.1)

Acquires data messages provided by external systems and human operators that are needed by FMDS functions.

FMDS_fPRD_0100. The FMDS system must acquire flight data.

Note, this includes NAS and international flight data consisting of flight plans, surveillance data, and surface events. When implemented, it is expected that FMDS will obtain all required flight data from CSS-FD.

FMDS_fPRD_0104. The FMDS system must acquire schedule data from OAG.

Note, schedule data originates from OAG and batched flight plan schedule data (FPSD) command files retrieved from the ARTCCs, the ATCSCC, and Canadian sites.

FMDS_fPRD_0102. The FMDS system must acquire textual and gridded weather data messages from CSS-Wx for the following types of weather data:

• Meteorological Aerodrome Reports (METARs)

• Terminal Aerodrome Forecasts (TAFs)

• Volcanic Ash Advisories (VAAs)

• Radar

• Satellite

• Lightning

• TFM Convective Forecasts (TCFs)

• Forecast Wind

• Echo Tops

• Weather Avoidance Field (WAF) Grid

FMDS_fPRD_0997. The FMDS system must acquire Runway Visual Range (RVR) data from SWIM Terminal Data Distribution System - Airport Data Service (STDDS-APDS).

FMDS_fPRD_0103. The FMDS system must acquire adaptation data, including geographic boundaries, aeronautical features (e.g., Navigational Aids [NAVAIDs], fixes, routes, sectors), and system data from the following sources:

• National Airspace System Resource (NASR)/National Flight Data Center (NFDC)

• En Route Automated Modernization (ERAM)

• International Air Navigation Service Providers (ANSPs) including UK, Chile, Mexico, Colombia, Brazil, COCESNA, Canada, EUROCONTROL, Trinidad and Tobago, and Dominican Republic

• Official Airline Guide (OAG) Supporting Data

• ATCSCC FMDS Adaptation (e.g., Airport Arrival Rates/Airport Departure Rates [AARs/ADRs], flight number ranges, code share information)

• Route Availability Planning Tool (RAPT) Adaptation

• Weather Location Reporting

• Flight Service Station (FSS)

• World Geographic Boundaries

• TFDM Surface Viewer Adaptation

• TBFM airport configuration data

Note, ingesting airport configuration data from TBFM is part of the IDP requirements.

FMDS_fPRD_0105. The FMDS system must acquire CDM data from CDM Members.

Note, CDM data consists of CDM flight data (e.g., identification, origin, destination, gate and runway estimates, and actual events [e.g., OOOI (Gate Off, Wheels Off, Wheels On, Gate In)]), and CDM action data (e.g., Trajectory Options Set (TOS), substitution).

FMDS_fPRD_0662. The FMDS system must acquire data messages that provide space operation information.

FMDS_fPRD_0663. The FMDS system must acquire sector configuration data from SWIM Flight Data Publication Service - En Route Airspace Data Publication (SFDPS - ERADP).

FMDS_fPRD_0664. The FMDS system must acquire departure sequencing data from TFDM.

3.1.1.2 Process Data (F.1.2)

Processes the data ingested by FMDS.

3.1.1.2.1 Process Flight Data (F.1.2.1)

Processes the flight data ingested by FMDS. Flight data processing includes validation, parsing, flight matching, and saving flight data.

Note, this functionality includes processing all equipment codes defined for an ICAO flight plan on CDM, ERAM, and International ICAO-format flight plan messages as part of the IDP requirements.

3.1.1.2.1.1 Validate Flight Data (F.1.2.1.1)

FMDS_fPRD_0107. The FMDS system must validate ingested flight data by performing format, syntax, range, and logic checks.

3.1.1.2.1.2 Parse Flight Data (F.1.2.1.2)

FMDS_fPRD_0111. The FMDS system must parse validated flight data into its constituent data elements.

3.1.1.2.1.3 Match Flight Data (F.1.2.1.3)

FMDS_fPRD_0115. The FMDS system must determine whether the ingested, validated, and parsed flight data message matches an existing flight based on extracted data elements.

3.1.1.2.1.4 Save Flight Data (F.1.2.1.4)

Updates flight data for matched flights or creates a new flight when no match is identified. Additionally, allows Traffic Managers to manually update flight schedule data.

FMDS_fPRD_0597. The FMDS system must create a new flight record with the information from the processed flight data if no existent flight is found.

FMDS_fPRD_0117. The FMDS system must update the matched flight record with the new information from the processed flight data.

FMDS_fPRD_1087. The FMDS system must update flight-specific schedule data based on Traffic Manager input.

3.1.1.2.2 Process Schedule Data (F.1.2.2)

Processes the schedule data ingested by FMDS. Schedule data processing includes validation and parsing.

3.1.1.2.2.1 Validate Schedule Data (F.1.2.2.1)

FMDS_fPRD_0109. The FMDS system must validate ingested schedule data by performing format, syntax, and logic checks.

3.1.1.2.2.2 Parse Schedule Data (F.1.2.2.2)

FMDS_fPRD_0113. The FMDS system must parse validated schedule data into its constituent data elements.

3.1.1.2.3 Process Weather Data (F.1.2.3)

Processes the weather data ingested by FMDS. Weather data processing includes validation.

FMDS_fPRD_0118. The FMDS system must validate weather data by performing format, syntax, range, and logic checks.

3.1.1.2.4 Process Adaptation Data (F.1.2.4)

Processes the adaptation data ingested by FMDS. Adaptation data processing includes validation, filtering, merging, aliasing, and prioritizing adaptation data.

FMDS_fPRD_0121. The FMDS system must validate adaptation data by performing format, syntax, range, and logic checks.

FMDS_fPRD_0122. The FMDS system must filter out adaptation data items not needed by the system from the following sources:

• NASR/NFDC

• ERAM

• International ANSPs, including Canada, Chile, Mexico, Colombia, Dominican Republic, Caribbean, Europe, COCESNA, and UK

• OAG

• RAPT

FMDS_fPRD_0123. The FMDS system must merge airway definitions when two or more adapted elements are geographic duplicates.

FMDS_fPRD_0124. The FMDS system must alias airport or fix definitions when two or more adapted elements are semantic duplicates.

FMDS_fPRD_0125. The FMDS system must prioritize the adapted elements when more than one source provides information on an adapted element.

3.1.1.2.5 Process CDM Data (F.1.2.5)

Processes the CDM data ingested by FMDS. CDM data processing includes validation, parsing, and, only for CDM action data messages, response generation.

3.1.1.2.5.1 Validate CDM Data (F.1.2.5.1)

Validates ingested CDM data by performing format, syntax, range, and logic checks specific to the type of CDM data:

flight, substitution, TOS.

FMDS_fPRD_0110. The FMDS system must validate ingested CDM flight data by performing format, syntax, range, and logic checks.

FMDS_fPRD_0593. The FMDS system must validate ingested substitution data by performing format, syntax, range, and logic checks.

FMDS_fPRD_0127. The FMDS system must validate ingested TOS data by performing format, syntax, range, and logic checks.

3.1.1.2.5.2 Parse CDM Data (F.1.2.5.2)

Parses CDM data into its constituent data elements specific to the type of CDM data: flight, substitution, TOS.

FMDS_fPRD_0114. The FMDS system must parse validated CDM flight data into its constituent data elements.

FMDS_fPRD_0126. The FMDS system must parse validated substitution data into its constituent data elements.

FMDS_fPRD_0666. The FMDS system must parse validated TOS data into its constituent data elements.

3.1.1.2.5.3 Generate CDM Response Messages (F.1.2.5.3)

Generates a response to the submitting CDM Member indicating whether the submitted TOS or substitution message has passed validation checks.

Note, feedback to CDM Members is based on processing, including flights impacted by slot credit substitutions as allowed by the Enable/Disable Slot Credit Substitutions function.

FMDS_fPRD_0596. The FMDS system must generate a response to the submitting CDM Member indicating whether their TOS options passed validation checks or one or more of the TOS options were rejected.

FMDS_fPRD_0594. The FMDS system must generate a response to the submitting CDM Member indicating if the substitution message passed validation checks.

Note, the response includes the control time or controlled flight status changes upon successful processing of the substitution packet, as well as any invalid elements found in the packet.

3.1.1.2.6 Process Space Data (F.1.2.6)

FMDS_fPRD_0668. The FMDS system must process the space data ingested by FMDS.

3.1.1.2.7 Process Sector Configuration Data (F.1.2.7)

FMDS_fPRD_0669. The FMDS system must process the sector configuration data ingested by FMDS.

3.1.1.2.8 Process Departure Sequencing Data (F.1.2.8)

FMDS_fPRD_0670. The FMDS system must process departure sequencing data (e.g., flight matching, Route Approval Status, Route Database Logic Checking) ingested by FMDS.

3.1.1.3 Derive Data (F.1.3)

Derives data for use by FMDS that is based on the external interface data (e.g., single flight information, weather).

3.1.1.3.1 Derive Modeled Trajectories (F.1.3.1)

Generates and evaluates modeled trajectories for each flight operating or planning to operate in the NAS.

3.1.1.3.1.1 Generate Modeled Trajectories (F.1.3.1.1)

Generates a modeled trajectory for a flight that includes profiles (i.e., lateral, vertical, speed), trajectory times, and a flight event list.

Note, this functionality includes the use of RNAV data, historical route profiles, speed and altitude changes, MIT/MINIT and altitude restriction effects, and trajectory time improvements as part of the IDP requirements.

3.1.1.3.1.1.1 Generate Lateral Profile (F.1.3.1.1.1)

FMDS_fPRD_0151. The FMDS system must generate each flight's lateral profile as a projection of the flight's trajectory on the surface of the Earth.

Note, this functionality includes the use of RNAV data and historical planned route profiles as part of the IDP requirements.

3.1.1.3.1.1.2 Generate Vertical Profile (F.1.3.1.1.2)

FMDS_fPRD_0152. The FMDS system must generate each flight’s vertical profile as a profile of the flight's altitude for each phase of flight: climb, cruise, and descent.

Note, this functionality includes the use of submitted altitude changes and historical planned route profiles as part of the IDP requirements.

3.1.1.3.1.1.3 Generate Speed Profile (F.1.3.1.1.3)

Generates a baseline speed profile and applies gridded wind data effects to generate a wind-adjusted speed profile.

FMDS_fPRD_0153. The FMDS system must generate each flight’s baseline speed profile as a profile of the flight's speed for each phase of flight: climb, cruise, and descent.

Note, this functionality includes the use of submitted speed changes and historical planned route profiles as part of the IDP requirements.

FMDS_fPRD_0875. The FMDS system must generate each flight’s wind-adjusted speed as the flight’s baseline speed profile adjusted for wind velocity at lateral locations of interest.

Note, the wind velocity profile is used to calculate ETAs for locations in the cruise phase of a flight's lateral profile using the lateral, vertical, and speed profiles, as well as gridded wind data.

3.1.1.3.1.1.4 Apply Restriction Effects (F.1.3.1.1.4)

Applies the effects of a set of restrictions (i.e., MIT, MINIT, ALT) when building individual flight trajectories.

FMDS_fPRD_2002. The FMDS system must apply the effects of MIT restrictions when building individual flight trajectories.

FMDS_fPRD_2003. The FMDS system must apply the effects of MINIT restrictions when building individual flight trajectories.

FMDS_fPRD_2004. The FMDS system must apply the effects of ALT restrictions when building individual flight trajectories.

3.1.1.3.1.1.5 Determine Trajectory Times (F.1.3.1.1.5)

FMDS_fPRD_0154. The FMDS system must determine the times associated with a flight's trajectory using historical data, CDM-provided times, and the profiles generated in the lateral, vertical and speed profiles.

Note, this functionality includes the use of surface data and historical data analyses as part of the IDP requirements.

3.1.1.3.1.1.6 Generate Event List (F.1.4.1.1.6)

FMDS_fPRD_0155. The FMDS system must generate the list of events a flight will encounter during the operation. The event list is used for flight matching and demand predictions and includes, but is not limited to, the following events:

• Departure Event - the absolute time and location at which a flight is projected to takeoff from the departure airport.

• Top-of-Climb Event - the absolute time and location at which a flight's climb profile is projected to reach the cruising altitude.

• Fix Crossing Event - the absolute time and location at which a flight is projected to cross a named fix.

• Airway Traversal Event - the absolute times and locations when a flight is projected to enter and exit a defined airway.

• Airspace Intersection Events - the absolute time and location at which a flight is projected to intersect the boundary of a defined airspace (e.g., ARTCCs, sectors, Fixed Airspace Volumes [FAVs], FxAs, Special Activity Airspaces [SAAs]).

• Inflection Point Events - the absolute times and locations a flight is projected to change its cruising speed (speed inflection), change its heading (lateral inflection), or change its altitude (vertical inflection).

• Top-of-Descent Event - the absolute time and location at which the descent profile reaches the flight's cruising altitude.

• Arrival Event - the absolute time and location at which a flight is projected to land at its arrival airport.

3.1.1.3.1.2 Evaluate Modeled Trajectories (F.1.3.1.2)

Evaluates a flight's conformance to its modeled trajectory based on its reported position, track data history, and event list. Determines whether the modeled trajectory should be updated or remodeled by identifying ATC maneuvers that the flight is performing.

3.1.1.3.1.2.1 Evaluate Conformance (F.1.3.1.2.1)

FMDS_fPRD_0156. The FMDS system must compare a flight's current position and track history to its modeled trajectory to evaluate conformance across four dimensions: lateral, vertical, longitudinal, and speed (which accounts for time).

Note, when a flight is not conformant with the modeled trajectory, a new modeled trajectory is generated.

3.1.1.3.1.2.2 Identify ATC Maneuver (F.1.3.1.2.2)

FMDS_fPRD_0157. The FMDS system must determine which ATC maneuver a flight is currently performing using its current position, track data history, event list, and conformance assessment. The ATC maneuvers identified are:

• Hold Maneuver - occurs when consecutive position reports for a flight indicate that the flight is in the same position and the track history data indicates that the flight is not progressing toward the destination.

• Coast Maneuver - occurs when consecutive position reports for a flight indicate that the flight is in the exact same position within a set distance from its destination. Identification of a Coast Maneuver ends re-conformance checking.

• Vector Maneuver - occurs when a flight's deviation from the modeled trajectory would result in a delay less than or equal to an adapted maximum vector delay time.

• Ascend Maneuver - occurs when a flight's track data history indicates a consistent altitude increase in the cruise phase of flight other than those expected in the flight plan.

• Descend Maneuver - occurs when a flight's track data history indicates a consistent altitude decrease in the cruise phase of flight other than those expected in the flight plan.

• Fly-At-New-Cruise Maneuver - occurs when the recent position reports for a flight in the cruise phase indicates that a flight has changed altitude and has leveled off.

• Direct-To-Fix Maneuver - occurs when a flight's current heading would take the flight over any of the downstream fixes in the flight's modeled trajectory other than the next fix expected in the flight plan.

• Wander Maneuver - occurs when a flight is non-conformant, but maneuver type cannot be determined.

3.1.1.3.1.2.3 Add ATC Maneuver (F.1.3.1.2.3)

FMDS_fPRD_0158. The FMDS system must add an ATC maneuver to the modeled trajectory when detected by the Identify ATC Maneuver function.

Note, these maneuvers include holding, vectoring, new cruise altitude, new cruise speed, and direct route.

Maneuvers detected by the Identify ATC Maneuver function that are not added to the modeled trajectory simply retain an indication of the maneuver.

3.1.1.3.2 Derive Weather Data (F.1.3.2)

Derives gridded and textual weather products based on ingested, validated weather data.

3.1.1.3.2.1 Derive Gridded Weather Products (F.1.3.2.1)

FMDS_fPRD_0119. The FMDS system must convert the ingested, validated gridded weather data from its native format to a format for user interface display or trajectory modeling.

3.1.1.3.2.2 Derive Textual Weather Products (F.1.3.2.2)

FMDS_fPRD_0120. The FMDS system must convert the ingested, validated textual weather data from its native format to a format for user interface display.

3.1.1.4 Provide Data (F.1.4)

Makes FMDS data available for use by FMDS services and external automation systems and users.

3.1.1.4.1 Provide Flight Data (F.1.4.1)

FMDS_fPRD_0128. The FMDS system must provide flight data for use by FMDS services and external automation and users, including:

• CSS-FD flight data

• Schedule data

• CDM flight data

• TMI-specific flight data (e.g., departure control times, route assignments)

3.1.1.4.2 Provide Demand Data (F.1.4.2)

FMDS_fPRD_0130. The FMDS system must provide NAS resource demand data for use by FMDS services and external automation and users.

3.1.1.4.3 Provide Capacity Data (F.1.4.3)

FMDS_fPRD_0131. The FMDS system must provide NAS resource capacity data for use by FMDS services and external automation and users.

3.1.1.4.4 Provide Adaptation Data (F.1.4.4)

FMDS_fPRD_0132. The FMDS system must provide FMDS adaptation data for use by FMDS services and external automation and users.

3.1.1.4.5 Provide Weather Data (F.1.4.5)

FMDS_fPRD_0133. The FMDS system must provide gridded and textual weather data for use by FMDS services and external automation and users.

3.1.1.4.6 Provide Notifications (F.1.4.6)

Provides notifications (e.g., numbered advisories, Demand Capacity Imbalance [DCI] notifications, general messages) for use by FMDS services and external automation and users.

FMDS_fPRD_0147. The FMDS system must provide numbered advisory data for use by FMDS services and external automation and users.

FMDS_fPRD_0134. The FMDS system must provide DCI notification data for use by FMDS services and external automation and users.

FMDS_fPRD_0135. The FMDS system must provide general message data for use by FMDS services and external automation and users.

FMDS_fPRD_0928. The FMDS system must provide NAS event notification data for use by FMDS services and external automation and users.

FMDS_fPRD_0929. The FMDS system must provide slot modification control notification data for use by FMDS services and users.

FMDS_fPRD_0930. The FMDS system must provide TMI parameters notification data for use by FMDS services and external automation and users.

3.1.1.4.7 Provide Route Availability Data (F.1.4.7)

FMDS_fPRD_0136. The FMDS system must provide route availability data (e.g., timelines, trend data, and blockage scores) for use by FMDS services and external automation and users.

3.1.1.4.8 Provide TMI Data (F.1.4.8)

FMDS_fPRD_0139. The FMDS system must provide TMI data (e.g., program type, time, scope, capacity, impacts) for proposed and implemented TMIs for use by FMDS services and external automation and users.

3.1.1.4.9 Provide CDM Action Data (F.1.4.9)

FMDS_fPRD_0148. The FMDS system must provide CDM action data for use by FMDS services and external automation and users.

3.1.1.4.10 Provide NAS Event Log Data (F.1.4.10)

FMDS_fPRD_0141. The FMDS system must provide NAS Event Log data for use by FMDS services and external automation and users.

3.1.1.4.11 Provide NAS Status Data (F.1.4.11)

FMDS_fPRD_0143. The FMDS system must provide NAS Status data (e.g., airport, airspace, international operations) for use by FMDS services and external automation and users.

3.1.1.4.12 Provide System Status Data (F.1.4.12)

FMDS_fPRD_0144. The FMDS system must provide system status data (e.g., monitor and control events, outages, scheduled maintenance, system performance, network performance, hardware performance) for use by FMDS services and external automation and users.

3.1.1.4.13 Provide Space Data (F.1.4.13)

FMDS_fPRD_0671. The FMDS system must provide space data for use by FMDS services and external automation and users.

3.1.1.4.14 Provide Analytics Data (F.1.4.14)

Provides analytics data (e.g., real-time and archived data reports, real-time flight and TMI history data, TFM replay data) for use by FMDS services and external automation and users for real-time and post-event analysis.

FMDS_fPRD_0137. The FMDS system must provide analytics data for use by FMDS services and external automation and users for real-time analysis.

FMDS_fPRD_0672. The FMDS system must provide analytics data for use by FMDS services and external automation and users for post-event analysis.

3.1.1.4.15 Provide FxA Data (F.1.4.15)

FMDS_fPRD_1084. The FMDS system must provide FxA data for use by FMDS services and external automation and users.

3.1.2 Assess NAS State (F.2)

Evaluates the current and projected state of the NAS and enables Traffic Managers to identify near- and long-term problems to determine whether mitigating actions are needed.

3.1.2.1 Specify Resource Capacity (F.2.1)

Specifies resource capacity as the number of operations that can safely use a NAS resource over a specified period of time (e.g., aircraft arrivals per hour). This includes the automatic setting of default capacities and dynamic user-entered values. This function also allows Traffic Managers to manage departure fix usage (i.e., rate, configuration, availability).

3.1.2.1.1 Specify Default Capacities (F.2.1.1)

Specifies the maximum number of operations that can be safely managed through a given NAS resource during a specified time period based on FMDS adaptation.

FMDS_fPRD_0673. The FMDS system must specify an airport's default capacity based on FMDS adaptation.

FMDS_fPRD_0674. The FMDS system must specify a sector's default capacity based on FMDS adaptation.

FMDS_fPRD_1066. The FMDS system must specify a fix's default capacity based on FMDS adaptation.

3.1.2.1.2 Specify User-Defined Capacities (F.2.1.2)

Specifies the maximum number of operations that can be safely managed through a given NAS resource during a specified time period based on Traffic Manager input.

FMDS_fPRD_0174. The FMDS system must specify an airport's capacity during a specified time based on Traffic Manager input.

FMDS_fPRD_0175. The FMDS system must specify a sector's capacity during a specified time based on Traffic Manager input.

FMDS_fPRD_1067. The FMDS system must specify a fix's capacity during a specified time based on Traffic Manager input.

3.1.2.1.3 Manage Departure Fix Usage (F.2.1.3)

Specifies departure fix usage (i.e., rate, combination, availability) based on Traffic Manager input, models the impact of the change, and implements the change to one or more fixes.

3.1.2.1.3.1 Specify Departure Fix Usage (F.2.1.3.1)

Specifies the expected usage of departure fixes, including fix rate, fix combining and decombining, and fix availability, based on Traffic Manager input.

FMDS_fPRD_2005. The FMDS system must specify the capacity for a departure fix based on Traffic Manager input.

FMDS_fPRD_0177. The FMDS system must specify the combination or decombination of specific departure fixes based on Traffic Manager input.

FMDS_fPRD_0178. The FMDS system must specify the availability of a specific departure fix based on Traffic Manager input.

Note, "Availability" refers to whether a departure fix is open or closed.

3.1.2.1.3.2 Model Departure Fix Usage (F.2.1.3.2)

FMDS_fPRD_2006. The FMDS system must model the flight-specific impact of a proposed change for the usage of a departure fix or fixes.

Note, in this context, "a proposed change" includes one or more of the following actions: departure fix rate change, departure fix combination or decombination, or departure fix availability update.

3.1.2.1.3.3 Implement Departure Fix Usage (F.2.1.3.3)

FMDS_fPRD_2007. The FMDS system must implement a change to the usage of a departure fix or fixes based on Traffic Manager input.

Note, in this context, "a change" includes one or more of the following actions: departure fix rate change, departure fix combination or decombination, or departure fix availability update.

3.1.2.2 Predict Resource Demand (F.2.2)

Predicts the flights that will use a NAS resource (e.g., airport, sector, fix, FxA) during the prediction horizon based on historical data and current flight counts.

Note, this functionality includes the use of historical data to generate probabilistic demand counts as part of the IDP requirements.

3.1.2.2.1 Predict Deterministic Demand (F.2.2.1)

Determines the flights intending to use a NAS resource (e.g., airport, sector, fix) during the prediction horizon based on current flight data.

FMDS_fPRD_0675. The FMDS system must determine the flights intending to use each airport during the prediction horizon based on current flight data.

FMDS_fPRD_0676. The FMDS system must determine the flights intending to use each sector during the prediction horizon based on current flight data.

FMDS_fPRD_1068. The FMDS system must determine the flights intending to use each fix during the prediction horizon based on current flight data.

FMDS_fPRD_1069. The FMDS system must determine the flights intending to use each FxA during the prediction horizon based on current flight data.

FMDS_fPRD_2009. The FMDS system must determine the flights intending to use each adapted departure route in a predefined time interval.

3.1.2.2.2 Compute Smoothing Coefficients (F.2.2.2)

FMDS_fPRD_1082. The FMDS system must compute smoothing coefficients using error distributions for airports, sectors, and fixes.

3.1.2.2.3 Predict Probabilistic Demand (F.2.2.3)

Predicts probabilistic demand counts for a NAS resource (e.g., airport, sector, fix) during the prediction horizon using deterministic demand counts and smoothing coefficients.

Note, the term "probabilistic demand" is a bit of a misnomer in this context as it is merely used to distinguish the existing deterministic demand values from those that will be calculated via IDP. When implemented, the user will not be presented with probabilistic demand values, but rather probabilistic techniques will be applied to deterministic demand data by IDP within FMDS prior to providing the values to the user.

FMDS_fPRD_1070. The FMDS system must predict probabilistic demand counts for each airport during the prediction horizon using aggregate airport demand counts and airport smoothing coefficients.

FMDS_fPRD_1071. The FMDS system must predict probabilistic demand counts for each sector during the prediction horizon using aggregate sector demand counts and sector smoothing coefficients.

FMDS_fPRD_1072. The FMDS system must predict probabilistic demand counts for each fix during the prediction horizon using aggregate fix demand counts…