Attachment 3_FMDS Implementation Strategy White Paper - Final.docx

Implementation Strategy for Flow Management Data and Services (FMDS)

June 2, 2022

Federal Aviation Administration 800 Independence Avenue SW

Table of Contents

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

Implementation Strategy for FMDS June 2, 2022 ii

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

Figure 11. TFM Functions This implementation strategy document provides a proposed approach 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 the initial deployment of 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).

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:

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

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 technology refresh at the TFMS Remote Sites (TRSs) was unable to address all the performance issues, and obsolescence of the current software may preclude another technology refresh. The TFMS Program Office investigated the root causes of TFMS outages, identified system shortfalls, and developed recommendations for improving RMA and performance. The FAA is pursuing many of these recommendations as part of the FMDS program.

TFMS History The transition from ETMS to TFMS was approached incrementally during the timeframe of 2007 through 2010, reducing risks by postponing modernization of some of the complex functions, while establishing the foundation for a modular, open architecture. Once the foundation was established, incremental system enhancements continued through the development of defined work packages, adding new capabilities for the operational users that would not have been possible under the ETMS infrastructure. Though the centralized processing in ETMS was replaced by TFMS, it is important to note that the user applications were never modernized, and to this day, continue to provide the end user functionality. A complex architecture of adapters exists between the modernized TFMS Core and the legacy applications to facilitate data exchange.

The TFMS system boundary is shown in Figure 12. Within the TFMS boundary are the TFM Production Center (TPC), TRS, ATCSCC, and the Disaster Recovery Center (DRC).

Figure 12. TFMS System Boundary The infrastructure includes three general classes of installation. The first is the TPC and the DRC[footnoteRef:2], which are the centralized sites for the receipt, processing, and synchronization of data. Users of TFMS primarily interact with the TPC/DRC by a remote site configuration, or TRS, the second class of installation. TRSs also collect NAS data from various FAA systems and provide them to the TPC/DRC. The third type of installation is specific to the ATCSCC, which is a special case of a TRS, requiring more processing capabilities to support a higher number of users with advanced functionality requirements, but with no connections to other FAA systems for data collection. [2: It is important to note that the DRC is not a fully redundant TPC. Instead, the intent of the DRC is to provide a “slightly reduced TFM operational capability” in the event of a disaster, outage, or failure. ]

TFMS Applications The software installed at both the TPC and the TRSs are in whole designed to support a required set of user functionality. Today that functionality is provided via several different applications, some of which run on a TRS workstation, while others are web-based. Though there are many different applications, six key desktop applications are used for monitoring the NAS, modeling and issuing TMIs, and logging and communicating the TMIs across facilities. These desktop applications are:

· Traffic Situation Display (TSD): User interface (UI) for all TFMS functions except those provided by FSM and NTML. It provides numerous displays to a traffic manager, including geospatial data (e.g., flight data, weather data, aeronautical data), text reports, alerts, and Flow Evaluation Area (FEA)/Flow Constrained Area (FCA) timelines and bar charts. The TSD is also used to model and issue FEA/FCAs, Reroutes, and Collaborative Trajectory Options Programs (CTOPs). Flight operators and other users external to TFMS have access to selected TSD functions through the “thin–client” TSD–C.

· Flight Schedule Monitor (FSM): Application used by traffic managers to create, issue, and maintain Ground Delay Programs (GDPs), Ground Stops (GSs), and Airspace Flow Programs (AFPs). Flight operators also use this application to view the impact of these TMIs on their fleet.

· National Traffic Management Log (NTML): Application used by traffic managers to enter and coordinate restrictions and log other significant events and actions affecting the NAS.

· Enhanced Status Information System (ESIS): System used to communicate TFM–related NAS status information within a facility. It is integrated with the NTML such that restrictions entered via NTML can optionally be posted to the ESIS display.

· Route Management Tool (RMT): Provides three separate sets of capabilities with different user bases. First is a non-operational capability to manage and coordinate the creation of routes such as preferred routes and playbook routes. Second is an operational capability to search for and display specific routes, along with determining which route avoids weather. Third is an administrative capability to export specific data for use in adaptation data sets for other systems.

· Surface Viewer (SV): Provides situational awareness of aircraft locations on the ground at a select number of airports.

These desktop applications are supported by some ancillary applications available on the TFMS Workstation along with upwards of 30 web applications, many available via fly.faa.gov.

TFMS Architecture The TFMS architecture is complex, involving different facilities, networks, communication protocols, hardware, and software. Some aspects of this architecture have been modernized, primarily the services within the TPC, while other elements still utilize older legacy technologies, to include applications, communication protocols, and data exchange processes. These legacy elements are primarily in the TRSs, though there are some in the TPC as well, such as legacy adapters. This mix of modernized and legacy architecture elements is a key factor affecting TFMS RMA and performance.Figure 13. Today’s TFMS Architecture

A simplistic view of today’s TFMS architecture is shown in Figure 13. The TPC is further decomposed into the Data, Application, Portal, Transition, and Auxiliary Subsystems. The Application and Data Subsystems, referred to as the “Core”, host all the centralized functionality of the system to include data management and TMI processing. The Portal Subsystem hosts the functions responsible for data ingest and publication. Four of the key types of interfaces for data exchange are the External Data Ingest (interfaces to external data sources), TRS interfaces (responsible for data exchange with the remote sites to support the applications), TFMData (the SWIM services for TFM data exchange), and TFMS Support Subsystem (TSS) Forwarders (responsible for providing data from the core to the Auxiliary Subsystem). The interface to the TRS applications requires legacy adaptors that are hosted in the Transition Subsystem. The Auxiliary Subsystem hosts the various TFMS web applications along with the NTML servers. The top of the figure shows the key applications in use at the TRSs, described in the previous section.

The software running at the TPC was the focus of the modernization effort over approximately the last decade. Very little legacy ETMS software remains as part of the TPC. Exceptions include the Transition Subsystem, needed to support data exchange with legacy applications.

The software at the TRS sites, however, is still based on the legacy software developed under the ETMS program (note that the recent technology refresh only addressed the hardware, not the software). The only exception is the recently deployed Surface Viewer. The TRS software is installed on two types of hardware:

· Workstations running the primary TFMS applications, which include the TSD, FSM, NTML, ESIS, SV, and RMT, along with other secondary applications.

· File Servers providing data interfaces between the TRS and TPC/DRC, among other key services. Note that File Servers can also be concurrently used as Workstations at some sites.

FMDS 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 scrape[footnoteRef:3] several websites. CDM members will transition away from the use of local instances of the 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 TSD application. [3: Web scraping is an automated process for periodically downloading and extracting data from a web page.]

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.

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 streamline data sharing across NAS automation systems.

FMDS Architecture As described earlier, FMDS will provide a reliable automation system to support traffic flow management functions in a modernized, service-based architecture using industry standards. Modernization will increase reliability and reduce response time for users, and a standards- and service-based architecture will provide flexibility to the FAA for implementing capabilities as well as extensibility to future enhancements. As much as possible, functions needed by multiple applications will be implemented as services, keeping the business logic in each application as minimal as possible. This will be achieved using three distinct subsystems: data, services and applications, and auxiliary applications subsystems. The data subsystem, referred to as Flow Management Data (FMD), will provide common services for ingesting, matching, processing, updating, and managing flight data, along with trajectory modeling and trajectory conformance monitoring. The services and applications, known as Flow Management Services (FMS), will be comprised of back end services and front end applications to provide various TFM-specific functionality, including demand monitoring and alerting as well as TMI modeling, coordination, and implementation. To promote common situational awareness and facilitate collaboration, the Auxiliary Applications (Aux Apps) subsystem will provide operational information to external users via a series of web application portals. The distinction between FMD, FMS, and Aux Apps is summarized in Table 31.

Table 31. FMDS Subsystems

· Ingests, processes, matches, and updates flight data from the following sources:

· NAS flight data

· International flight data

· CDM flight data

· Flight schedule data

· TMIs issued via FMS

· Performs trajectory modeling and conformance monitoring

· Publishes and archives flight data

· TFM-specific functions, such as demand/capacity monitoring and TMI modeling and implementation.

· Centralized architecture, minimizing footprint at remote sites

· New thin client Situation Display integrating TSD, FSM, NTML, ESIS, RMT, and Surface Viewer

· Public-facing APIs and data publication services

· Modernized and integrated web application portals leveraging FMS microservices

FMDS will be implemented on top of underlying computation, storage, and networking infrastructure. As a result, the FMDS program must decide what infrastructure (or combination of infrastructure) to use. There are a range of infrastructure alternatives from well-established, program-owned approaches exemplified by many FAA system to the “latest and greatest” new technologies, such as cloud. The program is evaluating the following alternatives:

· Program Owned and Hosted Hardware

· FAA Integrated Enterprise Service Platform (IESP)

· On-Premise Cloud Platform

· Off-Premise Cloud Platform

· Vendor Owned and Hosted Hardware These alternatives are being evaluated for factors to include security, performance, in-service management, cost, schedule, risk, and critical dependencies. Regardless of the eventual selection of the infrastructure, the software will be containerized, and the hardware will run in a virtual server environment.

Implementation Strategy The preferred implementation approach for FMDS is phased, with each successive release building upon the functionality provided in the preceding one. The strategy focuses on replacing the remote site applications and infrastructure as soon as possible. It relies heavily on the TFMS Core during the transition period, that is, the timeframe when FMDS is being incrementally deployed and the TFMS applications are being retired.

TFMS Rehosting The TFMS program will soon be rehosting the Web Applications portion of the Auxiliary Subsystem in a virtual environment (see Figure 41). This platform, referred to as the TFMS Web Platform, will utilize the existing TFM Support System (TSS) Forwarders to obtain the needed data for the rehosted web applications, which will have little to no changes in their software.

Figure 41. Baseline TFMS architecture after Web Application Rehosting FMDS Phases Using this baseline architecture, a two-phase approach is utilized to implement FMDS. In the first phase, shown in Figure 42, the FMDS Situation Display (SD) will be deployed, replacing all of the applications and supporting infrastructure currently at the TRSs.

Figure 42. FMDS Phase 1: Remote Site Replacement As described in the FMDS ConOps, the FMDS Situation Display (SD) will encompass all functionality that is currently available via the TSD, SV, FSM, NTML, and the capability to provide data to ESIS displays. (Note that the SD will also encompass the operational functions included in RMT.) As a result, these legacy applications, as well as their backend infrastructure at the TPC, will be retired (e.g., the NTML severs in the Auxiliary Subsystem and TRS interfaces in the Portal and Transition Subsystems). The SD will be supported by back end services in FMS, which will subscribe to the SWIM TFMData services to provide flight and flow data to the application. Additionally, FMS will leverage the request/response functionality provided by TFMData to leverage key TFMS functions, including NAS monitoring, TMI modeling, coordination, and implementation, and route management. For the functionality not provided by TFMData (e.g., monitor alert), new services will be developed and deployed in FMS to provide traffic managers with a complete suite of tools.

In the second and final phase, shown in Figure 43, TFMS in its entirety will be retired. Before this can occur, FMD will be deployed and assume all flight data management functions, including ingest and processing, trajectory modeling, and publication. Separately, additional services will be deployed in FMS to replace other critical TFMS Core functionality, such as TMI modeling and implementation. FMS will also interface with FMD to exchange flight data updates and the FM Web Applications Platform to exchange required information to/from the hosted web applications. When all the existing TFMS functionality has been accounted for and deployed, a complete switchover to the new FMDS environment can take place.

Figure 43. Phase 2 – TFMS Retirement FMDS Releases These proposed phases can be further decomposed into releases. In Phase 1, each SD release will incorporate the functionality of a legacy application, while the legacy application itself is retired. For example, an initial release of the SD could include all functionality in the TSD with some functions being allocated either to the SD itself (display functions) or FMS services (business logic). Some functions will continue to be supported by the TFMS Core.

As an example, the TSD today provides the user interface for the modeling and issuance of CTOPs and the business logic for modeling and implementing CTOPs are contained in the TFMS Core. In Phase 1 of FMDS, the SD would include the display functions for CTOPs, the FMS would host backend services for providing data to the display and interfacing with the TFMS Core, and the TFMS Core would continue to provide the services for modeling and implementing CTOPs. The TFMData services would support the exchange of data between the TFMS Core and FMS.

After this initial release in Phase 1, users would begin using the new SD for TSD functionality alongside the existing FSM, NTML, and other legacy applications. Since both the SD and the legacy applications are using the same data produced by the TFMS Core, this hybrid environment of old and new applications can be supported. By incrementally retiring the old applications and adding functionality to the SD, it minimizes risks associated with large software releases and minimizes the amount of training needed for users with each release. A proposed sequence of releases for Phase 1 are:

1. TSD: Retirement of the TSD, incorporating all TSD functions in the SD and FMS. This would also include the operational features for route searching/displaying in RMT.

2. SV: Retirement of the Surface Viewer and integration of its functions in the SD and FMS.

3. FSM: Retirement of the FSM, adding FSM functions to the SD and FMS.

4. NTML and ESIS: Retirement of the NTML application and infrastructure, adding the capabilities to the SD and FMS.

FMDS Detailed Example – GDPs This phased implementation strategy is possible due to the SWIM services provided via TFMData, documented in the TFMData Java Messaging Service Description Document (JMSDD). Of the six business functions available via TFMData, the following can be used to leverage the TFMS Core by FMS in Phase 1:

· Flight Data: Event-based publication of flight data representative of the TFMS NAS Common Situation Model (NCSM), allowing a subscriber to recreate the flight data repository in TFMS.[footnoteRef:4] This data flows continuously once a subscription is established. [4: Note that not every flight data element is published via the Flight Data business function, but one of the TFM Request Response services allows a subscriber to access these additional data elements.]

· Flow Information: Event-based publication of flow information (TMIs and NTML restrictions and status information). This includes create, update, and delete events, along with associated flight lists and allows a subscriber to access all TFMS flow information. This data flows continuously once a subscription is established.

· TFM Request Reply: Exposes all of the TFMS services supporting TMI management and data exchange with NAS users.

To illustrate how these services can be used by FMDS to leverage the TFMS Core, we can use a GDP as an example, illustrated in Figure 44. The Flight Data functions can be used to obtain the flight data and provide it to the SD to support GDP modeling. Then, the TFM Request Reply functions can be used to request historical popup data and submit the GDP and advisory information, allowing the TFMS core to implement the GDP and distribute the advisory. Finally, the Flow Information functions will publish the resulting GDP information and the Flight Data functions will provide the impacts of that GDP on the flights.

Figure 44. GDP Processing Sequence Diagram – Phase 1 As mentioned above, the results of implementing the GDP are published via the Flight Data and Flow Information services. FMS will rely on that data to maintain its data repository and provide data for display on the SD.

At the end of Phase 2, TFMS will be retired with its remaining functions allocated to either FMS or FMD. The same example of modeling and implementing a GDP, but within the final architecture after Phase 2, is shown in Figure 45. Flight data is managed within FMD and provided to FMS to support TFM functions. The data is provided to the SD for the user to evaluate demand vs. capacity. With the removal of the TFMS Core and TFMData interfaces, all of the modeling and implementation functions are done within FMS. Once completed, the status is provided to the user and the flight data changes are sent to FMD. All flow information is maintained in FMS and provided to the user upon request.

Figure 45. GDP Processing Sequence Diagram – Phase 2

Acronyms

image1.wmf image2.png image3.png image4.png image5.png image6.png image7.png image8.jpg image9.png