Attachment 1_FMDS ConOps - Final (2).pdf

WARNING: This document contains information that is subject to the U.S. Export Administration Regulations (EAR, 15 C.F.R. Parts 730-774) and designated as EAR99. As a consequence, this information cannot be exported nor re-exported to country group E:1 or E:2 countries/persons (see Supp.1 to Part 740 of the EAR), nor can be made available to any national of such country.

In addition, the information in this document cannot be exported nor re-exported to an end-user or for an end-use that is prohibited by Part 744 of the Export Administration Regulations (15 C.F.R. Part 744).

Traffic Flow Management Concept of Operations for Flow Management Data and Services (FMDS) for Investment Analysis Readiness Decision (IARD)

February 2022

Federal Aviation Administration 800 Independence Avenue

Washington, D.C. 20591 ii

Table of Contents

1 Introduction

1.1 Background

1.2 Definition of Key Terms

1.3 Problem Statement

1.4 Concept Overview

1.5 Alignment

2 “As is” Operations

2.1 TFM Automation System Users

2.2 TFMS Applications

2.3 Traffic Flow Management Collaboration and Decision-making

2.3.1 TFM Data Management

2.3.2 Support TFM Decision-making

2.4 Maintaining the TFM Automation System

2.5 Training Users for TFM Automation System Improvements

3 Justification and Description of Changes

3.1 Shortfall Category SF-1: Unacceptable performance and lack of expandability and scalability prevent TFMS from meeting evolving needs

3.1.1 Shortfall SF-1.1: TFMS no longer meets the necessary availability and reliability for effective TFM operations

3.1.2 Shortfall SF-1.2: TFMS components cannot meet peak operational performance needs and can be inefficient during routine operations

3.1.3 Shortfall SF-1.3: TFMS cannot support planned future enhancements and updates ..

3.1.4 Shortfall SF-1.4: TFMS includes multiple types of data interfaces which are costly, unintegrated, and difficult to maintain and update

3.2 Shortfall Category SF-2: Lack of a comprehensive failover strategy prevents continuity of operations

3.2.1 Shortfall SF-2.1: TFMS lacks a comprehensive failover strategy for loss of service

3.2.2 Shortfall SF-2.2: TFMS lacks a comprehensive, timely response to major disaster failures

3.3 Shortfall Category SF-3: Lack of integrated capabilities inhibits consistent operational system-wide views, operational decision-making, and usability of the system

3.3.1 Shortfall SF-3.1: TFM operational decision-making requires manual assimilation of data from a variety of sources due to piecemeal operational information, decision-making, and tools iii

3.3.2 Shortfall SF-3.2: TFMS user interfaces are graphically and functionally inconsistent and complex

3.3.3 Shortfall SF-3.3: TFMS applications are not integrated and provide duplicative functionality

4 “To Be” Operations

4.1 Assumptions

4.1.1 Operational and Technical Environment Assumptions

4.1.2 Baseline FMDS Capabilities

4.2 Constraints

4.3 Operational Environment

4.4 Concept of Operations

4.4.1 Traffic Flow Management Collaboration and Decision-making

4.4.2 Maintaining the TFM Automation System

4.4.3 Training Personnel for TFM Automation System Improvements

4.5 Supporting Infrastructure

4.5.1 Infrastructure Internal to FMDS

4.5.2 Infrastructure External to FMDS

4.6 Benefits

4.6.1 Replacing Obsolete Capabilities

4.6.2 Administrative Benefits

4.6.3 Supportability Benefits

4.6.4 Infrastructure Benefits

4.6.5 Productivity Benefits

5 Operational Scenarios

5.1 FMDS Support for a Large-Scale Weather Event

5.1.1 AFP Event Planning

5.1.2 AFP Strategy Execution

5.1.3 AFP Monitoring

5.1.4 AFP Conclusion

5.1.5 Post-event Analysis

5.2 FMDS Support for a Large-Scale Weather Event Using CTOP

5.3 Using the TOS with PDRR

5.4 Using the TOS to Find a Pathfinder

5.5 Managing a Partial System Outage

5.6 CDM Member Creates a Slot Credit Substitution Capability

iv

6 Summary of Impacts

7 References

Appendix A Acronyms

Appendix B TFMS Web Applications v

List of Figures

Figure 1-1. TFM Functions Figure 2-1. Current Operational Environment Figure 2-2. Relative Organization of ATC Facilities Figure 2-3. TFM Facilities Across the NAS Figure 2-4. Overview of TFM Decision-making Process Figure 2-5. Automated Systems that Exchange Data with TFMS Figure 2-6. Example PERTI Planning Timeline Figure 2-7. NAS Monitor Figure 2-8. Departure Viewer Figure 2-9. FCA Dynamic Flight List Figure 2-10. AADC view of Chicago O’Hare International Airport (ORD) Figure 2-11. Example of FEAs to Justify Flow Restrictions Figure 2-12. Sample Modeling Results in FSM Figure 2-13. RMT Display of Playbook Routes Avoiding a Constraint Figure 2-14. RRIA Model Results Showing Affected Flights and Change in Flight Time and Distance due to the Modeled Reroute Figure 2-15. Example Advisories, including Proposed Advisory Figure 4-1. FMDS Operational Environment Figure 4-2. FMDS Concept Overview Figure 5-1. Multiple TFMS Applications for AFP Planning (Left) versus FMDS Integrated Situation Awareness Display (Right) Figure 5-2. Applications for CDM Members to Manage EDCTs in TFMS (Left) vs FMDS (Right) Figure 5-3. Multiple TFMS Applications (Left) vs Integrated Situation Awareness Display Support (Right) for AFP Execution Figure 5-4. TFMS Applications (Left) vs FMDS Applications (Right) to Support Post- Event Analysis Figure 5-5. Thunderstorms Building West of IAD Affecting Departures Over RAMAY ... 73 Figure 5-6. Thunderstorm Dissipation Indicates Option for a Pathfinder Flight Figure 5-7. Multiple TFMS Applications to Support TOS Querying, and Reroute Selection and Implementation (Left) versus Integrated Situation Awareness Display in FMDS (Right) Figure 5-8. Static TFMS Documentation (Left) vs Editable, Maintainable, Navigable FMDS System Documentation (Right) vi

List of Tables

Table 1-1. TFMS Shortfalls and FMDS Capabilities Table 1-2. FMDS Concept Alignment Table 1-3. FMDS Alignment to BTI Table 1-4. FMDS Alignment to OI Increments Table 1-5. FMDS Capabilities Mapped to BTI and OI Increments Table 2-1. TFM Automation System Users

1 Introduction

The National Airspace System (NAS) is a dynamic system that must respond to variability in weather, system constraints, and traffic demand. The fundamental goal of Traffic Flow Management (TFM) is to promote a safe, orderly, and expeditious flow of traffic that minimizes delays. This is achieved through coordination, utilization, and analysis of Traffic Management Initiatives (TMIs) that modify demand to account for changes in capacity.

Today, the Traffic Flow Management System (TFMS) provides tools for users to develop, coordinate, issue, and manage TMIs that balance flight demand and NAS capacity.

However, those tools have reached end of life and are exhibiting accuracy and latency issues, as well as shortfalls in reliability, maintainability, and availability (RMA). The core functions that TFMS supports are summarized in Figure 1-1.

Figure 1-1. TFM Functions

This Concept of Operations provides a vision for the initial deployment of Flow Management Data and Services (FMDS), a new incarnation of TFMS that will meet the operational, RMA, and performance needs of its users. FMDS is expected to be deployed in 2027. Although FMDS is not anticipated to make significant changes to TFM roles and responsibilities relative to the current system, it is a key step in realizing the future TFM vision and maturing the transition to Trajectory Based Operations (TBO) [1].

FMDS is envisioned to leverage new technologies and a new approach to software development and deployment to accelerate the delivery of TFM automation capabilities.

FMDS will employ a new software architecture that will align with evolutions in the FAA Enterprise Architecture and infrastructure. The new architecture and infrastructure will allow TFM activities to scale to projected air traffic growth. With an architecture designed for flexibility and extensibility, FMDS will provide a foundation for future TFM capabilities that can leverage new technologies and operate in a more interconnected operational and technical environment. In meeting this vision, FMDS will address shortfalls in TFMS related to the inability of its architecture and hardware to support long-desired features and functions.

FMDS will provide a streamlined user experience for a broad array of users within and external to the Federal Aviation Administration (FAA). FMDS will also provide a foundation for efforts to achieve future FAA goals such as [2, 3, 1]:

Quickly identify lessons learned to better support continuous TFM planning processes.

Gate-to-gate integration of flight and flow data.

Standardize operational metrics across TMIs and planning timeframes.

Integrate new entrants into the NAS.

Improve response of NAS operations to uncertainty.

Improve underlying TFM algorithms to better support predicting and managing demand and capacity.

1.1 Background

TFMS is the result of modernization of the Enhanced Traffic Management System (ETMS). ETMS was a prototype developed organically from the late 1980s through the early 2000s to support TFM functions conducted by traffic managers at Air Route Traffic Control Centers (ARTCCs) and the Air Traffic Control System Command Center (ATCSCC).

It evolved into the framework for conducting Collaborative Decision Making (CDM) and therefore expanded its user base to include Terminal Radar Approach Controls (TRACONs), Air Traffic Control Towers (ATCTs), NAS users, and international air traffic control (ATC) organizations. The data produced by ETMS and, later, TFMS, became crucial to NAS users, other external organizations, and the flying public to maintain awareness of NAS operations and status.

In recent years, TFMS users’ operational needs for availability, accuracy, and system response times 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 obsolescence of the current software may preclude another technical refresh. The TFMS Program Office investigated the root causes of TFMS outages, identified system shortfalls, and developed recommendations for improving RMA and performance [4, 5]. The FAA is pursuing many of these recommendations as part of the FMDS program.

1.2 Definition of Key Terms

This section defines terms used in this document that may be interpreted differently by different readers. The descriptions provided here define the terms as they are used in this document. This is not intended to be a complete glossary for FMDS, nor is it intended to provide definitions for all terms relevant to traffic flow management.1

Traffic Flow Management (TFM) is defined on the FAA website [6] as follows:

“A ‘system approach’ to managing traffic that considers the impact of individual actions on the whole. Managing disruptions in airspace capacity (caused for example by bad weather, traffic [volume], or emergencies) requires consideration of who or what may be impacted by events, and a coordinated mitigation effort to ensure safety, efficiency and equity in the delivery of air traffic services. Without a coordinated response, local flight delays due to small disruptions can quickly ripple across the entire U.S., causing large scale rerouting, flight cancellations, and significant widespread delays.”

TFM in the NAS is overseen by the ATCSCC. Traffic management also takes place in the ARTCCs, TRACONs, and ATCTs, and in collaboration with other NAS stakeholders, including the airlines, general aviation (GA), and the military.

The term TFM automation system is used in statements that are equally applicable to TFMS or FMDS. If the statement is applicable to only one, the specific automation system name (i.e., TFMS or FMDS) is used.

NAS resources include the airports, airways, fixes, ATC sectors, and other features of the NAS that TFM personnel can use in TMI definitions.

Traffic management initiatives (TMIs) are techniques used to balance demand with capacity, including Ground Delay Programs (GDPs), Airspace Flow Programs (AFPs), Collaborative Trajectory Options Programs (CTOPs), Miles-in-Trail (MIT), Minutes-in-Trail (MINIT), reroutes, and other techniques defined in procedures [7].

The term traffic managers includes Traffic Management Specialists (TMSs), Traffic Management Coordinators (TMCs), National Operations Managers (NOMs), and other FAA personnel from different types of facilities that today use TFMS to support TFM functions. There are multiple personnel within many facilities with a variety of job titles that perform similar TFM functions. At some facilities or during certain time periods, even ATC personnel act in a TFM role. For brevity, this document collectively refers to these users as traffic managers.

NAS users are individuals and organizations who operate aircraft in the NAS, and who currently use TFMS applications and data to maintain awareness of TMIs and other constraints.

The term user, with no qualifier, refers to any TFM automation system user, including FAA users, NAS users, and others. A complete list of users is provided in Section 2.1.

Collaborative Decision Making (CDM) “is a joint [FAA] and aviation industry endeavor aimed at improving [TFM] through increased data and information exchange among aviation community stakeholders. … CDM is an operating paradigm where TFM

1 For detailed discussions of TFM concepts, see the TFM Learning website: https://tfmlearning.faa.gov/ decisions are based on a shared, common view of the NAS and an awareness of the consequences these decisions may have on the system and its stakeholders” [8]. CDM is both: 1) the philosophy that stakeholders should share “operational information, ideologies and preferences” to build a common view of the NAS; and 2) the tools and procedures that support this information sharing to produce TFM decisions and actions that are best for the NAS. “Participation in CDM is limited to qualified aviation and aerospace related entities that support the specific data-sharing criteria defined in a CDM Agreement” [8].

A CDM member is a NAS user organization that: “(1) provides raw CDM data to the FAA,

(2) receives processed CDM data from the FAA, and (3) collaboratively works with the FAA [TFM] function in responding to NAS demand-capacity imbalances and other system constraints” [9]. The FAA aggregates the data provided by all CDM members, uses it to support the CDM process, and distributes it to all CDM members.

A software service is a software functionality or set of functionalities that different software clients can use for different purposes, along with the rules that should control its usage. One such rule might control the data available from the service based on the identity of the client requesting the service. An example service might support retrieval of specified information or the execution of a set of operations [10]. FMDS is envisioned to leverage shared services to avoid duplication of functionality within the system.

The software service is the primary component for implementing functionality in a microservices architecture. In a microservices environment, services are self-contained and loosely coupled, such that they “can be individually designed, developed, tested, and deployed with little or no dependency on other components or services in the application” [11]. FMDS is envisioned to leverage a microservices architecture, in alignment with the NAS Automation Evolution Strategy [25].

1.3 Problem Statement

TFMS does not meet its RMA and response time requirements and is expected to become untenable within the next few years. The system has become a patchwork of disparate applications that traffic managers must employ individually at various stages of a single TFM activity. This disjointed process leads to inefficient TFM and complicates post-event analysis. Furthermore, evolution of TFMS capabilities has slowed due to the cost of adding modern functionality to an archaic system architecture and the need to expend an increasing portion of development resources to address reported system problems.

The TFMS shortfalls and needed FMDS capabilities, as documented in the Shortfall Analysis Report [12], are summarized in Table 1-1.

Ta bl e 1-

1.

T

FM

S

Sh or tf al ls an d

FM

DS

C ap ab ili tie s

TF

M S

Sh or tfa ll

Ca te go ry

TF

M S

Sh or tfa ll

De sc rip tio n Sh or tfa ll Ex am pl e( s)

/M ea su re

(s

FM

DS

C ap ab ili tie s

SF

-1

: U na cc ep ta bl e pe rfo rm an ce a nd a la ck o f e xp an da bi lit y an d sc al ab ili ty pr ev en t T

FM

S fro m m ee tin g ev ol vi ng ne ed s.

SF

-1

.1 : T

FM

S no lo ng er m ee ts th e ne ce ss ar y av ai la bi lit y an d re lia bi lit y fo r ef fe ct iv e

TF

M o pe ra tio ns

Ex am pl es o f w or ka ro un ds tr af fic m an ag er s e m pl oy to a cc ou nt fo r T

FM

S pe rfo rm an ce li m ita tio ns

Ac cu m ul at ed le ng th o f o ut ag es d ue to ai nt en an ce a ct io ns to p re ve nt sy st em or co m po ne nt p er fo rm ce de gr ad at io n.

Co un t o f p ro bl em ti ck et s a ss oc ia te d w ith sy em re sp on se ti e.

Co un t o f T

RS

su pp or t i nc id en ts fe ct ed h ar dw ar

FM

DS

w ill p ro vi de a st an da rd s-ba se d m icr os er vi ce s a rc hi te ct ur e th at ill ee t s ys te m R

M A re qu ire m en ts ad dr es s o pe ra tio na l n ee ds

SF

-1

.2 : K ey T

FM

S co m po ne nt s c an no t m ee t p ea k op er at io na l p er fo rm ne s a nd ca n be in ef fic ie nt d ur in g ro ut in e op er at io ns

O pe ra tio na l w or kl oa d va lu es th at ex ed T

FM

S de sig n th re sh ol ds fo r nu m be r o f a ct iv e fli gh ts , F lo w

E va lu at io n

Ar ea s (

FE

As ) a nd F lo w

C on st ra in

Ar ea s (

FC

As

FE

A/

FC

A-re la te d ac tio ns fli gh t l ist re qu es ts , a nd M on ito r A le rt re po rt s.

A m od er ni ze d ar ch ite ct ur e an d in fra st ru ct ur e w ill a llo w F

M

DS

to m ee t op er at io na l r eq ui re m en ts fo r pe rfo rm an ce , r el ia bi lit y, a nd a va ila bi lit y.

SF

-1

.3 : T

FM

S ca nn ot su pp or t p la nn fu tu re e nh an ce m en ts a nd u pd at es

Ex am pl es o f e nh an ce m en ts a pp ro ve d fo r T

FM

S ac qu isi tio n th at w er e de la ye d, fe rr ed

, a nd

/o r r es co pe d du e to T

FM

S lim ita tio ns

Th e

FM

DS

a rc hi te ct ur e w ill su pp or t fu tu re e nh an ce m en ts

S Sh or tfa ll Ca te

S Sh or tfa ll De sc rip tio n

Sh or tfa ll

Ex am pl e(

s) /M ea su re (s

FM

DS

C ap ab ili tie s

SF

-1

.4 : T

FM

S in clu de s m ul tip le ty pe s o f da ta in te rf ac es th at a re u ni nt eg ra te d an d di ffi cu lt to m ai nt ai n an d up da te

Co un t o f p ro bl em ti ck et s r el at ed to d at a in te rfa ce p ro bl s.

DS

w ill m od er ni ze a nd st an da rd ize da ta in te rf ac es a nd le ve ra ge

N

AS

en te rp ris e da ta se rv ice s t o re du ce th e fo ot pr in t a nd co m pl ex ity o f d ep lo ye d so ftw ar e an d ha rd w ar

-2

: L ac k of a co m pr eh en siv e fa ilo ve r st ra te gy p re ve nt s c on tin ui ty o f op er at io ns

SF

-2

.1 : T

FM

S la ck s a co m pr eh en siv e fa ilo ve r s tr at eg y fo r l os s o f s er vi ce

O ut ag e du ra tio ns fo r T

FM

S pa tc h in st al la tio ns

FM

DS

w ill e m pl oy a co m pr eh en siv e fa ilo ve r s tr at eg y to m ai nt ai n hi gh le ve ls of re lia bi lit y an d av ai la bi

-2

.2 : T

FM

S la ck s a co m pr eh en siv e, tim el y re sp on se to m aj or d isa er fa ilu re s.

Do cu m en ta tio n of

T

FM

S ca pa bi lit ie s n ot ov id ed b y th e Di sa st er R ec ov er y

Ce nt er (D

RC

Co m pl ex ity a nd le ng th o f D

RC

a ct iv at io n pr oc es s.

FM

DS

w ill p ro vi de a co m pr eh en siv e di sa st er re co ve ry p la n to e ns ur e av ai la bi lit y of ca pa bi lit ie s w he n a fa ilu oc cu rs

SF

-3

: L ac k of in te gr at ed ca pa bi lit ie s in hi bi ts co ns ist en t o pe ra tio na l s ys te m w id e vi ew s, op er at io na l d ec isi on m ak in g, a nd u sa bi lit y of th e sy st em

SF

-3

.1 : T

FM

o pe ra tio na l d ec isi on

-m ak in g re qu ire s m an ua l a ss im ila tio n of d at a fro m a v ar ie ty o f s ou rc es d ue pi ec em ea l o pe ra tio na l i nf or m at io n, cis io n-m ak in g, a nd to ol s.

Am ou nt o f t im e w as te d by tr fic ag er s e nt er in g in fo rm at io n ul tip le a pp lic at io ns fo r M

IT

ric tio ns

FM

DS

w ill p ro vi de a st re am lin ap pl ica tio n su ite th at su pp or ts

T kf lo w s a nd e lim in at es re du nd an t m an ua l d at a en tr

-3

.2 : T

FM

S us er in te rfa ce s a gr hi ca lly a nd fu nc tio na lly in co ns ist en t an d co m pl ex

Ex am pl es o f u se r i nt er fa ns ist en cie s t ha t i nh ib it us ab ili ty o f

TF

M S ca pa bi lit ie

Th e

FM

DS

u se r a pp lic at io n su ite ov id e a co ns ist en t l oo k an d fe el w ith od er ni ze d us er in te rfa ce (U

I) th at im ov e us ab ili ty

, i nc re as e ef fic ie nc y, d re du ce o pp or tu ni tie s f or u se r e rr

S Sh or tfa ll Ca te

S Sh or tfa ll De sc rip tio n

Sh or tfa ll

Ex am pl e(

s) /M ea su re (s

FM

DS

C ap ab ili tie s

SF

-3

.3 : T

FM

S ap pl ic at io ns a re n ot te gr at ed a nd p ro vi de d up lic at iv e fu nc tio na

Ex am pl es o f d at a in co ns ist en cie s a du ica tio n of fu nc tio na lit y ac ro ss ica tio ns th at in cr ea se sy pl ex ity

Th e st re am lin ed F

M

DS

u se r a pp lic at io n su ite w ill in te gr at e fu nc tio na lit y su pp or t T

FM

w or kf lo

1.4 Concept Overview

FMDS will provide a reliable TFM automation system with a modernized architecture that will increase reliability and reduce response time. A microservices architecture will provide flexibility to the FAA for implementing capabilities and leveraging enterprise services. A modernized architecture will also support future enhancements. As much as possible, FMDS will leverage enterprise services. Functions needed by multiple applications (and automation systems) will be implemented as shared services. This will avoid duplication of functions and data across services, applications, and automation systems, which will simplify development and maintenance. A modernized architecture will also improve the processes for providing system support, from reducing the need for synchronizing data on the backend to providing visibility into system and component performance to prevent system failures.

TFM automation system functions will be implemented in a streamlined interface that will improve the user experience. The consolidated application suite and improved performance of FMDS will allow traffic managers to view all traffic, TMIs, and weather in one integrated application, allowing for more proactive and efficient execution of TFM actions. Today, traffic managers collect information electronically but manually log it.

FMDS will support automated logging of common information, reducing traffic manager workload associated with entering duplicate data across applications. Automated logging will also make it easier for traffic managers to share information with multiple facilities, improving electronic coordination.

NAS users will access information about NAS operations and collaborate with traffic managers in new ways. The various TFMS web applications that NAS users must currently monitor separately will be streamlined and accessible via a centralized portal.

NAS users will be able to subscribe to notifications of changes in TMIs, operations plans, and other information, relieving them from the need to poll or scrape2 several websites.

CDM members will transition away from the use of local instances of the Flight Schedule Monitor (FSM) application, as its functionality will be included in the integrated situation awareness display application. To support this transition, FMDS may provide application programming interfaces (APIs) that will allow CDM members to access data and services they can use to model the impact of TMIs on their flights. Alternatively, or in addition, FMDS may provide CDM members access to a web-based version of the integrated situation awareness display that will allow them to perform similar tasks as they can do today via FSM and the remote desktop version of the Traffic Situation Display (TSD) application.

Post-event analysis will be supported by a searchable store of the data FMDS presents to users, data exchanged among FMDS users/facilities, and data exchanged among the underlying software services and automation systems. The data store will support better understanding of series of events and their impacts on NAS operations and will provide improved replay capabilities.

2 Web scraping is an automated process for periodically downloading and extracting data from a web page.

FMDS will use NAS enterprise services and standard industry data formats when appropriate to minimize the number of different data structures utilized and duplicate functionality across systems. This will allow for simplified internal maintenance and updates and will ease data sharing across NAS automation systems.

1.5 Alignment

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

Table 1-2. FMDS Concept Alignment

Level Layer Concept

0 Global ICAO Doc 9971: Manual on 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 Flow Management Data and Services (FMDS)

FMDS aligns to Business and Technology Improvement (BTI) number 508120, Improved Automation Infrastructure, described in Table 1-3.

Table 1-3. FMDS Alignment to BTI

BTI Number BTI Description

508120 Improved Automation Infrastructure

FMDS aligns to the Next Generation Air Transportation System (NextGen) Operational Improvement (OI) Increments summarized in Table 1-4.

Table 1-4. FMDS Alignment to OI Increments

ID Number OI Increment Description

1 105210-01 Improve Demand Predictions

2 105210-02 Integrate TMI Modeling

3 105210-03 Improved Integration of Traffic Flow Management Operations

4 105210-04 Aircraft Equipage Eligibility During TMIs

ID Number OI Increment Description

5 105211-01 Integrated Departure Route Planning

6 105303-24 Enhanced Post Operations

The BTI and OI Increments align to the FMDS opportunities as shown in Table 1-5.

Table 1-5. FMDS Capabilities Mapped to BTI and OI Increments

FMDS Capability BTI OI 1 OI 2 OI 3 OI 4 OI 5 OI 6

FMDS will provide a standards-based microservices architecture that will meet system RMA requirements to address operational needs.

X X X X

A modernized architecture and infrastructure will allow FMDS to meet operational requirements for performance, reliability, and availability.

X X X X X X X

The FMDS architecture will reduce the footprint and complexity of deployed software and hardware, leverage NAS enterprise data services, and support future enhancements.

X X X X X X X

FMDS will employ a comprehensive failover strategy to maintain high levels of reliability and availability.

X

FMDS will provide a comprehensive disaster recovery plan to ensure availability of capabilities when a failure occurs.

X

FMDS will provide a streamlined application suite that supports TFM workflows and eliminates redundant manual data entry. The user application suite will provide a consistent look and feel with a modernized user interface (UI) that will improve usability, increase efficiency, and reduce opportunities for user error.

X X X X X X

2 “As is” Operations

TFMS primarily supports traffic managers and NAS users in monitoring demand relative to capacity, assessing the impact of constraints such as weather on NAS operations, and coordinating TMIs to address demand-capacity imbalances, as shown in Figure 2-1.

Figure 2-1. Current Operational Environment

The following subsections introduce the TFMS users, their relative organization and use of TFMS, the TFMS applications, and illustrate how the TFMS shortfalls impact their work.

2.1 TFM Automation System Users

TFM automation system users include internal FAA users and users external to the FAA, as shown in Table 2-1. FMDS will continue to support the system users identified in Table 2-1.

Table 2-1. TFM Automation System Users

Internal FAA Users External Users

Traffic managers at different facilities, including ATCSCC, ARTCCs, TRACONs, and ATCTs

Air traffic control personnel, including:

o Operations Supervisors o Operations Managers o Air traffic controllers

Quality control (QC) personnel

System analysts

Training personnel

System administration and support:

o System specialists o System administrators o Software engineering support

NAS users:

o Domestic and international air carriers o Commercial operators o General aviation o Flight Plan Service Providers3 o Military

Flying public

International ATC organizations

External users of TFM automation system data

The core group of internal FAA users includes traffic managers at different facilities, including the ATCSCC, ARTCCs, TRACONs, and ATCTs (see Figure 2-2). Each type of facility has a different area of focus within the NAS, and therefore a different scope of TFM decision-making. Their access to TFMS capabilities reflects that scope.

For example, “the ATCSCC monitors and manages the flow of air traffic throughout the NAS, producing a safe, orderly, and expeditious flow of traffic while minimizing delays” [7, pp.

18-1-1]. ATCSCC traffic managers, including a NOM, multiple National Traffic Management Officers (NTMOs), and multiple National Traffic Management Specialists (NTMSs) “direct the operation” of TFM in the NAS [7, pp. 18-2- 3], interacting with facilities where there are authorized traffic management personnel (see Figure 2-3). The ATCSCC is the focal point for traffic management in the NAS and is the final approving authority for TMIs that impact multiple ARTCCs. ATCSCC traffic

3 Flight plan service providers access TFM data on behalf of their customers to support flight planning and replanning.

Figure 2-2. Relative Organization of ATC Facilities managers coordinate with ARTCC, TRACON, and ATCT traffic managers and NAS users as appropriate to [7]:

Monitor NAS components and weather to determine when capacity is likely to be reduced and TMIs will be required.

Reroute flows of traffic as needed.

Implement national TMIs including time-based metering (TBM), GDPs, AFPs, and CTOPs.

Evaluate proposed TMIs throughout the NAS for appropriateness.

Monitor TMIs issued throughout the NAS for effectiveness.

Manage airspace relevant to space launch and reentry operations.

Figure 2-3. TFM Facilities Across the NAS

Meanwhile, ARTCC traffic managers, including a Supervisory Traffic Management Coordinator (STMC), multiple TMCs, and the Center Weather Service Unit (CWSU), “monitor and balance traffic flows within their areas of responsibility in accordance with [TFM] directives” [7, pp. 18-1-4]. Their responsibilities include [7]:

Implementing TMIs “in conjunction with, or as directed by the ATCSCC” [7, pp.

18-2-4].

Ensuring that the ATCSCC is advised of all changes within their area of responsibility that could significantly impact the system and all agreements with other facilities related to TMIs.

Coordinating TFM actions with adjacent facilities through the ATCSCC.

Implementing TMIs to manage traffic within their area of responsibility.

Logging all TMIs and TFM actions.

Coordinating with TRACON traffic managers to develop strategies to manage arrivals and maintain airport arrival capacity.

Reporting delays according to FAA policy.

Managing civil aviation traffic in the vicinity of active Special Activity Airspace

(SAA).

Large TRACONs have traffic management units (TMUs) that are organized similarly to those at ARTCCs, whereas small TRACONs and ATCTs have at least one staff member responsible for acting as a TMC for their facility. They coordinate with relevant ARTCCs (typically the ARTCC overlying their facility), neighboring TRACONs, and the local ATCT(s) to balance traffic flows with capacity. They coordinate with ATCTs to manage airport and airspace configurations. TRACON traffic managers may participate in teleconferences with ARTCC and ATCSCC traffic managers, but it is rare for a TRACON to coordinate directly with the ATCSCC without the participation of the ARTCC.

Multiple additional FAA users interact with TFMS and/or the data it produces. In addition to viewing TMI information from TFMS, air traffic controllers interact with TFMS via Airborne Reroute (ABRR) and Pre-Departure Reroute (PDRR). TFMS sends reroutes issued via ABRR/PDRR to En Route Automation Modernization (ERAM), and the controller either applies or rejects the route amendment. ERAM then returns this controller response to TFMS.

QC personnel and system analysts use TFMS applications and data for post-event analysis. Training personnel use TFMS to support TFM training activities. In the context of this document, TFMS users also include system administration and support personnel responsible for maintaining TFMS software, hardware, and communication infrastructure.

Other FAA automation systems use the data that TFMS produces. For example, ERAM receives route amendments from TFMS for controllers to issue to aircraft, as noted above. Other NAS systems receive TFMS information about TMIs and their impact on flights via the TFMData SWIM service. TFMData includes both a flight information service that provides flight plans and track data, and a flow information service that provides TMI data. TFMS also exchanges flight and traffic management data with international ATC automation systems to support operations planning.

External user groups that leverage TFMS data include NAS users that receive information about NAS operations, constraints, and initiatives from various TFMS applications. CDM members are a subset of NAS users that have an explicit role in TFM decision-making and have access to certain TFMS capabilities that are not available to other NAS users (although some TFMS features are available only to traffic managers).

Other external users leverage flight and flow data from TFMData to participate in flight tracking, planning, post-event analysis, maintenance, engineering, and research and development activities, as well as third party commercial organizations that provide access to NAS data for a variety of customers.

2.2 TFMS Applications

TFMS capabilities are provided via a collection of applications that have evolved over the last 20+ years. Some of the applications run locally on a TRS workstation, while others are web-based. Both TRS desktop and web applications use data provided by the TFM Production Center (TPC), which is a centralized site for receiving, processing, and synchronizing data from external sources and the TFMS applications. The web applications are hosted at the TPC but in the Auxiliary Subsystem, which includes three separate zones allowing varying access controls to users. The exchange of data between TRS applications and the TPC is accomplished via a patchwork of technologies – many of which are proprietary and outdated – that duplicate functionality, introduce latency into the display of data to users, and hinder implementation of desired capabilities. This section introduces several TFMS applications that are frequently named in this document.

The desktop applications, listed below, are used for monitoring the NAS, modeling and issuing TMIs, and logging and communicating the TMIs across facilities. FMDS will ensure TFM system users have access to functionality like that provided by these applications. Traffic managers also routinely use TMIs developed in and issued from Time Based Flow Management (TBFM) as part of their TFM strategy and decision making. However, as TBFM is a separate automation system from TFMS, it will not be addressed in this document except in relation to TFMS.

The following are the most frequently used desktop applications:

Traffic Situation Display (TSD): Displays geospatial, flight, and weather data on a map. It also provides text reports, alerts (e.g., NAS Monitor), and FEA/FCA timelines and bar charts. The TSD is used by traffic managers to model and issue FEAs, FCAs, Reroutes, and CTOPs. CDM members can access a web-based, read-only version of the TSD (referred to as the “thin-client”).

Flight Schedule Monitor (FSM): Shows demand and capacity at airports and FEAs/FCAs and is used by traffic managers to model and issue GDPs, Ground Stops, and AFPs. Many CDM members have locally installed versions of FSM they can use to model the impact of proposed and issued TMIs on their operations.

National Traffic Management Log (NTML): Used by traffic managers to issue TMIs such as MIT restrictions and to log alerts and events. NTML automatically collects certain data and distributes NAS operational data among TFMS users to support electronic coordination. Some data from NTML is passed to the Operational Information System (OIS),4 where NAS users can access information about NAS operations.

Enhanced Status Information System (ESIS): Used by traffic managers to communicate TFM-related NAS status information to air traffic controllers and

4 The public-facing website for the OIS has been redesigned and renamed to be the NAS Status page, but the data provided on that site is still driven by the OIS. FAA facilities and authorized NAS users still access OIS. This document generally refers to this information sharing capability as OIS.

other operational personnel within a facility. Limited integration with NTML allows some restrictions and edits to be posted to the ESIS display from NTML.

However, a TFMS workstation is only allowed to send or edit a locally created TMI to ESIS if it was created at that workstation.

Route Management Tool (RMT): Provides three separate sets of capabilities for different groups of users:

o Adaptation specialists can create, edit, and coordinate changes to all stored traffic management routes, such as Coded Departure Routes (CDRs) and Playbook Routes (not in real-time with the operation).

o Traffic managers can search for and display specific routes in real-time with the operation, along with determining which routes avoid weather.

o NAS users and FAA users can export specific data for use in adaptation data sets for other systems, such as the Reroute Manager (listed below).

Surface Viewer (SV): Displays aircraft locations on the ground at select airports,5 providing traffic managers in ARTCCs and other traffic management facilities access to information from the Terminal Flight Data Manager (TFDM).

These six primary desktop applications are supported by ancillary applications available on the TFMS workstation, including:

Preference (Pref) Set Manager: Enables users to save and recall customized TSD configurations across workspaces on a single workstation. Pref sets cannot be shared across workstations.

Reroute Manager (RRMGR): Used to query adaptation data to aid in constructing reroutes. It provides static information on airport/Navigational Aid (NAVAID)/fix identifiers, preferred routes, major traffic flows, and parsed routes.

It also displays whether filed routes are compliant or non-compliant with published route advisories.

TFMS Messaging Application: Used by traffic managers to create advisories or general messages. Advisories publish information about TMIs to other TFMS applications and users. General messages are like email messages that traffic managers can send to other TFMS users.

TFMS Reports: Allows users, including traffic managers, to create reports that provide information about TMI performance and other aspects of NAS operations, in addition to the hard-coded reports available through the TSD command line. Some of the reports support real-time TFM decision-making, whereas others support end-of-day reporting and/or post-event analysis.

Pop-Notify: Provides users with notifications of various messages, such as advisories or receipt of reports.

5 The Surface Viewer application was deployed as part of TFMS R14 in October 2021, but not activated.

At the time of writing, a date for activation of the SV application has not been published.

Global Secure Desktop (GSD): Allows sites that are not TRSs to access the TSD and FSM applications through a remote desktop. CDM members use GSD to access the TSD, reducing the complexity of deploying FSM and TSD locally to CDM members.6

In addition to these applications, traffic managers use an external utility to capture a screenshot, take a video, or capture slides of a desired area of the workstation display at a specified interval. System support and QC personnel may use an external spreadsheet application for testing, troubleshooting, and performing post-operations analysis based on data exported from FSM.

An additional set of web-based applications, some of which are available to external users as well as internal users, is listed in Appendix B. Many of the web applications are accessible via the OIS, which is a key conduit of information between the ATCSCC and other facilities and NAS users.

2.3 Traffic Flow Management Collaboration and Decision-making

A core TFM function is collaborative decision-making among FAA traffic managers and NAS users. The key TFM functions supported by TFMS today and a high-level view of the TFM decision-making process are shown in Figure 2-4. Each of the main tasks is discussed in the following subsections.

Figure 2-4. Overview of TFM Decision-making Process

6 CDM members may choose a local installation of FSM, but they are not provided a local installation of the TSD.

2.3.1 TFM Data Management

TFMS receives information about air traffic demand and capacity constraints to inform the TFM decision-making process. The automated systems that exchange this data with TFMS are summarized in Figure 2-5.

Figure 2-5. Automated Systems that Exchange Data with TFMS

TFMS processes weather data from a variety of sources and in a variety of formats, and transforms that data as needed for display and to incorporate into certain decision support functions. Traffic managers use weather forecasts to manually estimate capacity for NAS resources.

TFMS receives adaptation data from a variety of US and international sources, including NAS users. TFMS has some automated processes for transforming the adaptation data as needed to ensure airspaces, routes, and aircraft are represented appropriately.

However, some of the data is very difficult to process automatically and adaptation specialists must process some of it manually. Furthermore, different data is provided on different time scales and adaptation specialists must manually incorporate it into the adaptation update process. Once they have assembled the data, adaptation specialists build and test the adaptation update with limited automation support from TFMS.

The TFMS tools and information accessible to NAS users depends on the type of user.

For example, all authorized NAS users have access to the web applications available through the OIS (see Appendix B), whereas CDM members have access to applications and data that are not available to non-CDM members, such as FSM and a web-based version of the TSD.

The TFMData SWIM service supports data exchange between TFMS and NAS users, including CDM members. NAS users may subscribe to TFMS data published via TFMData and incorporate it into their own flight planning capabilities.7

One of the many uses of data published by the TFMData SWIM service is to support real-time TFM operations. For example, ATCSCC traffic managers have access to a TFM Efficiency Toolbox, a web-based suite of tools external to TFMS, that allows personnel to drill into TFMS data to answer pertinent questions. For example, if a facility loses its ability to provide ATC services (“ATC-zero”), these tools allow ATCSCC traffic managers to determine the schedule and volume of flights for that facility to inform their strategy development. In addition, Plan, Execute, Review, Train and Improve (PERTI) teams have built tools using data from TFMS that allows planning to focus on the future time periods during which constraints are expected to impact NAS traffic, as shown in Figure 2-6 (from [13]).

Figure 2-6. Example PERTI Planning Timeline

Thus, TFMS not only ingests data from multiple sources for use within TFMS, but it also processes and provides data externally to support various aspects of NAS operations.

2.3.2 Support TFM Decision-making

TFMS supports TFM decision-making at multiple time scales, ranging from the PERTI planning process that seeks to identify constraints over the next several days, to managing demand and capacity imbalances over the next several hours. TFMS also supports its users in evaluating the performance of TMIs, both in real-time and as part

7 Note that all external users may subscribe to the non-sensitive TFMData feed and incorporate the data into their proprietary capabilities; however, only NAS users are relevant to the discussion of TFM collaboration and decision-making.

of post-event analysis. This section describes the support TFMS provides to traffic managers and NAS users as they carry out TFM coordination and decision-making. The large breadth of TFMS users and features gives rise to multiple workflows and interactions between TFMS and its users; the description here summarizes common uses of TFMS across multiple users.

2.3.2.1 Monitor Demand and Capacity

Identifying time periods when demand is likely to exceed capacity for NAS resources is a key input to developing effective TFM strategies. This requires information about both demand for, and capacity of, NAS resources. Different TFMS users monitor demand and capacity at different time scales; PERTI teams monitor for constraints such as weather and SAA that are likely to impact NAS traffic over the next several days, whereas most traffic managers and NAS users are focused on constraints that will impact NAS traffic over the next several hours.

The Monitor Alert Parameter (MAP) for each ATC sector, fix, and airport is the level of traffic demand that triggers the TSD to notify traffic managers “that sector/airport efficiency may be degraded during specific periods of time” [7]. If demand for a given NAS resource is expected to exceed the MAP value at any point during a given 15-minute time period, TFMS provides a notification to the relevant traffic management workstation via both the TSD map display and a color-coded grid in the NAS Monitor (see Figure 2-7, from [14]). The traffic manager is required to examine the sector in the TSD/NAS Monitor and determine if any action is needed. Then, the traffic manager must make a NTML entry detailing the action(s) taken to resolve the alert, as the data is not automatically shared across applications. Since NTML is a standalone application with its own supporting infrastructure that was built using different technology than TSD and FSM, it is difficult for NTML to exchange data with these applications [12].

Figure 2-7. NAS Monitor

Traffic managers use the Departure Viewer feature of the TSD to monitor departures, grouped by airports or departure fixes, as shown in Figure 2-8 (from [14]). They can use this information to determine whether demand exceeds capacity for departure fixes or how well demand is balanced across departure fixes. Improvements to this information have been in the development and deployment pipeline for more than 10 years but have not yet been fielded [12].

Figure 2-8. Departure Viewer

FEAs and FCAs allow traffic managers to determine demand for a given NAS resource or region of airspace. Only ATCSCC users can create and publish FCAs, which identify flights subject to a constraint. Users at other sites can only create and share FEAs, which identify flights in the defined region of airspace and time interval that satisfy given flight filters [7].

Traffic managers draw one or more FEAs/FCAs on the TSD, set the valid time period based on their expectation of when a demand-capacity imbalance may occur, and filter only the specific flights of interest to the FEA/FCA (e.g., departures from a given airport).

Then, they can view the number of flights meeting the filter criteria expected to intersect the FEA/FCA over time and the list of flights in each time period, as shown in Figure 2-9 (from [14]). Note that this provides demand information, but not demand relative to expected capacity. Furthermore, if a traffic manager requests a flight list, the TFMS response time may be so slow that the traffic manager re-submits the request, creating additional load on the system and further bogging down system response [12].

Figure 2-9. FCA Dynamic Flight List

In some instances, traffic managers may need to identify demand associated with GA traffic. For example, some AFPs schedule GA aircraft separately from scheduled carriers, and some airports have ramp space for scheduled carriers but not GA aircraft. TFMS allows traffic managers to create an FEA and specify they are interested in “GA” and/or “Air Taxi” flights. However, TFMS is unable to accurately identify all such aircraft. As a result, TFMS displays an inaccurate flight list for the FEA and provides inaccurate demand information to the traffic manager. One work-around is to create an FEA to generate a list of the scheduled air carriers and then exempt those aircraft from a separate FEA in order to capture GA traffic only. This work-around is time consuming and inefficient.

Whereas traffic managers use FEA/FCAs displayed on the TSD to monitor demand for regions of airspace, they use FSM to monitor demand and capacity for airports. It is common for ARTCC traffic managers to use multiple FSM windows to monitor demand for all of the airports within their area of interest.

When traffic managers perceive that forecast weather or other constraints will impact capacity, they must estimate the projected capacity based on their experience and existing guidelines. To support estimations of airport arrival and departure capacity, TRACON and ATCT traffic managers enter airport configuration, rates, and arrival and departure counts into NTML (if they have access) or the Airport Metrics web page (if they do not have access to NTML). The duplicated functionality between NTML and the Airport Metrics web application requires backend synchronization of the separate databases [5].