+ All Categories
Home > Documents > connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web...

connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web...

Date post: 27-Apr-2020
Category:
Upload: others
View: 1 times
Download: 0 times
Share this document with a friend
43
System Wide Information Management (SWIM) Flight Data Use Case Document Version Number 1.1 December 6, 2018
Transcript
Page 1: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

System Wide Information Management (SWIM)

Flight Data

Use Case Document

Version Number 1.1

December 6, 2018

Page 2: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

SIGNATURE PAGE

Name Date

SWIM Implementation Lead

Name Date

SWIM Program Manager

Federal Aviation Administration

800 Independence Avenue, SW

Washington, D.C. 20591

ii

Page 3: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

DOCUMENT CHANGE HISTORY

Version Date Description of Changes

0.4 10/25/2018 Initial draft for SWIFT review

1.0 11/29/18 Interim version reviewed by SWIFT Use Case Focus group

1.1 12/6/18 Final version incorporating all comments by SWIFT Use Case Focus group

iii

Page 4: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

TABLE OF CONTENTS

1 Introduction..............................................................................................................................11.1 Purpose..............................................................................................................................21.2 SWIM Flight Information Services...................................................................................21.3 Overview of Use Case.......................................................................................................4

2 Current State.............................................................................................................................72.1 Problem Statement..........................................................................................................102.2 Perspectives.....................................................................................................................122.3 Current State Operational Example................................................................................13

3 Future State............................................................................................................................153.1 Future State Operational Example..................................................................................203.2 Benefits...........................................................................................................................213.3 Conclusion......................................................................................................................23

Appendix A – Acronym Listing....................................................................................................24

LIST OF TABLES

Table 1. Subset of TFMS Flight, STDDS (SMES/TAIS), SFDPS Messages...............................16Table 2. Acronym Listing..............................................................................................................24

LIST OF FIGURES

Figure 1. Decomposition of Flight Domain Data Elements............................................................1Figure 2. Sourcing Traffic Flow Flight Information Services.........................................................4Figure 3. Decomposition of TFMS, SMES, TAIS and SFDPS Flight data by phase of Flight.......6Figure 4. Current State: NAS Operations......................................................................................10Figure 5. Problem Statement Depiction.........................................................................................12Figure 6. New Reality Based on New Information Service..........................................................15Figure 7. Future Use Case Diagram..............................................................................................18Figure 8. Future State: NAS Operations........................................................................................20

iv

Page 5: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

1 IntroductionThis document will discuss how the various System Wide Information Management

(SWIM) flight information services made available by the Federal Aviation Administration (FAA) can be used by aviation stakeholders to help improve flight planning, flight operations, and airspace management in the National Airspace System (NAS). The services included will be Traffic Flow Management System (TFMS) flight data, SWIM Terminal Data Distribution System (STDDS), and SWIM Flight Data Publication Service (SFDPS) flight and general information. While the SFDPS publishes both airspace and flight data messages, and TFMS publishes both flight and flow information, this document will focus primarily on flight data messages from SFDPS, STDDS, and TFMS. TFMS flight data includes scheduling, routing, and positional information that is enhanced by flight plan data, departure and arrival time notifications, flight cancellations, boundary crossings, and track position reports. Flight data produced by SFDPS includes flight plans and any associated updates, as well as flight tracking. STDDS flight data messages include Surface Movement Event Service (SMES), Terminal Automation Information Service (TAIS), and Tower Departure Event Service (TDES). This use case will use a combination of the available services to show the potential operational benefits available to airspace users.

Figure 1. Decomposition of Flight Domain Data Elements

1

Page 6: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

1.1 PurposeThe purpose of this document is to propose an improved process for managing future

flight operations and flight management problems that occur in the NAS due to inadequate information management. Integration of SFDPS, STDDS, and TFMS airspace and flight data messages into a stakeholder’s existing business process will facilitate improved awareness as flights progress from flight planning, pre-departure, en route, and arrival at destination. With improved informational updates provided through SWIM, Airspace Users (AU) can better manage the trajectory, en route cost, and estimated time of arrival of each flight more precisely, resulting in gains in system performance and integrity.

1.2 SWIM Flight Information ServicesTFMS flight data is designed to provide the same basic data as the previous Aircraft

Situation Display to Industries (ASDI) but is enhanced with additional data related to flights being monitored and managed by TFMS. Data from TFMS is published in the eXtensible Markup Language (XML) format that will allow for increased use of automation in data processing and transfer. TFMS flight data describes each individual flight modeled in the TFMS database and consists of data from several different systems. The main contributors of input data are the AUs, STDDS, En Route Automation Modernization (ERAM) system, Oceanic Air Traffic Control Systems, and International Data Providers (IDP). TFMS consolidates flight data along with some additional flow, route, and traffic information so that the resulting output is a compilation of all flights in the NAS. Standardization of the data format allows for improved automation applications, quicker transfer of data, and more robust post-flight analysis.

The incorporation of international flight data into SWIM provides for enhanced situational awareness of international flights and more timely data transfer to downline Flight Information Regions (FIRs), which will allow Air Traffic Control (ATC) facilities to have a truer picture of future demand and allow for AUs/airports to have more precise arrival times. When AUs and associated business services/vendors make the investment to process SWIM formatting through automation, they will be able to share both their flight data, user information, and various applications with ATC. When improved data processing becomes available, both AUs and ATC will benefit from the resulting new product applications.

STDDS provides interfaces for Tower and Terminal Radar Approach Control (TRACON) systems to send terminal events to both the NAS and AUs who have SWIM compliant infrastructure and interfaces. The STDDS interfaces with the Runway Visual Range (RVR) system, Electronic Flight Strip Transfer System (EFSTS), Airport Surface Detection Equipment Model X (ASDE-X), Airport Surface Surveillance Capability (ASSC), and Tower Data Link Service (TDLS) at airports, with the Standard Terminal Automation Replacement System (STARS) interface at TRACONs and SFDPS at Air Route Traffic Control Centers (ARTCCs).

SFDPS is the FAA NextGen solution for distributing flight, airspace, operational data, and general message information from the ERAM system to SWIM consumers.

2

Page 7: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

TFMS, STDDS, and SFDPS airspace data is transmitted whenever updates occur or whenever there is a significant change of data. It is published to consumers in a machine-readable format, which allows AUs or authorized data services to construct their own database consistent with approved standards.

It is important to identify each of the systems/services and to define their role in the Flight Domain environment. Note that there are several different types of services represented. As such, relevant definitions are provided below.

• Service

– A mechanism to enable access to one or more capabilities, where access is provided using a prescribed interface.

• Data Service

– A service that provides access to source data.

• Business Service

– Business function or capability offered as a service.

– Functionality delivered to business/operational decision-makers.

• Information Service

– A service that provides tailored access to data or information defined by a set of user configurable rules.

3

Page 8: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Figure 2. Sourcing Traffic Flow Flight Information Services

1.3 Overview of Use CaseThe intent of this use case is to demonstrate how TFMS, SFDPS, and STDDS flight

information improves informational sharing, more timely delivery of data, collaborative situational awareness, and standardized data formatting between AUs and ATC can benefit the overall operation of the NAS. Currently, AUs and air traffic managers often have differing views of a flight’s actual versus expected future positions and estimated arrival time. Lack of common situational awareness and full information sharing across multiple FIR boundaries cause longer flights to have greater discrepancy or misconnect in information between ATC and AUs.

The use case presented in this document focuses on using effective interactions and communication between various ATC facilities (en route, tower and ground controllers, Traffic Management Unit [TMU], Central Flow Control), airport management, AUs (airlines, general, and corporate aviation), and service providers to improve management of surface, en route, and arrival movements. These stakeholders play a vital role in managing flight operations. As the capabilities or requirements of any of the participants change, those changes must be coordinated and communicated with the other players to ensure all activities remain aligned. To highlight the specific challenges of airport surface management, the use case takes place on an airport surface that is currently experiencing a deicing event along with icing conditions. Deicing events are a major challenge for all stakeholders and provide a “worse case” example to highlight the difficulties in the current state. This use case will demonstrate the improvement that can be made during airport terminal movements with the use of STDDS (SMES/TAIS) data.

4

Page 9: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

This use case is focused on a deicing event, the departure flow and arrival process, and en route SAA constraints; however, the benefits gained from the use of SWIM data will also be realized in normal conditions. The arrival process can receive similar benefits by working backwards from gate arrival to runway arrival to positioning aircraft for a certain runway arrival time and runway even before top of descent. Also, additional information in TAIS regarding flight track and holding status (or any other deviations in the arrival phase) will improve arrival estimates significantly. With the improved information sharing and data management that is available for each individual flight from STDDS (SMES/TAIS) of both arriving and departing aircraft, mitigations can be made to the system impacts of surface operations and also smooth traffic flows within the NAS.

While the focus of the use case demonstrates the benefits of enhanced flight information using SWIM, the use case also demonstrates how operational improvements can be realized by NAS stakeholders through improved Special Activity Airspace (SAA) data sharing. SAA is airspace that is not available for normal use in the NAS. This means that aircraft must be routed around, over, or under SAA airspace, rather than through it. This unavailable airspace creates challenges for controllers and Traffic Flow Management (TFM) personnel who must ensure aircraft do not enter that airspace. It also creates a challenge for AUs who must file flight plans that avoid SAA areas. There are several types of SAA, and their location, size, and timing change continually. When this dynamic airspace environment is coupled with constraints, such as weather or high traffic volume, the complexity often rises to levels that negatively impact aviation efficiency. When this occurs, air traffic is restricted around SAA, causing throughput reductions.

Stakeholders currently possess only partial knowledge of the scope and timing of SAA, but it is difficult for stakeholders to have confidence that their SAA data is accurate. Stakeholders must work collaboratively to ensure that the integrity of flight planning and flight operations are maintained at the highest levels. Collaborative information exchanges using SFDPS airspace data will increase SAA situational awareness and improve the efficiency and safety of flight operations. With reliable and timely information, stakeholders can plan flights with full awareness of SAA impacts, allowing more efficient trajectories. Additionally, when changes occur, timely dissemination of updated data will provide stakeholders with adequate lead time to plan mitigating strategies to minimize the impacts.

5

Page 10: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Figure 3. Decomposition of TFMS, SMES, TAIS, and SFDPS Flight Data by Phase of Flight

Each of the stakeholders currently perform with different operational goals, requirements, and systems.

FAA: primarily responsible for separation of traffic and keeping system integrity intact. They need to safely fill every available takeoff and landing slot to utilize the full system capacity.

Airlines: have a system flight schedule to maintain while safely applying their business model to each individual flight. They require a certain level of predictability, and the ability to prioritize certain flights to optimize economic benefits and meet customer needs.

General and Corporate Aviation: need to sometimes move customers on short notice, often with less than optimum system support and resources. They need access to arrival and departure slots that may already had been allocated to other users.

Airport Operators: need to maintain operational standards while maintaining, repairing, and upgrading airports and systems that are sometimes old and outdated.

6

Page 11: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

2 Current StateCurrently, a combination of airline schedule data provided by the Official Airline Guide

(OAG), early intent data from AUs, and filed flight plan data is used to populate flight decision support services/tools. ATC systems apply past route information, cruising speed, and altitude derived from historical data to develop an initial trajectory for the flight. Historical information is supplemented by flight plan filing/updates, departure and arrival messages, position reports, and updated movement messages from controllers. Each stakeholder has created a plan for managing their portion of the event and many use a different system (or systems) to manage their own part of the operation. Because these systems do not interact, one of the biggest issues is the inability to measure results precisely.

For example, an airline may know that block time needs to increase to maintain schedule but do not have insight as the cause of the delay. The airline does not know if the time is being lost on the airline ramps and alleyways (both arriving and departing), on the taxi portion, waiting on the deicing pad, in queue for a departure runway, or somewhere during the en route phase (or a combination of all). If airlines cannot measure the precise cause of the problem, it becomes difficult to manage the problem effectively.

The core information of each stakeholder system was developed primarily for internal use by the system developer, and very few were developed to share information with other stakeholders. The FAA uses ERAM for en route purposes, TFMS, Time-Based Flow Management (TBFM) for traffic management, and Terminal Flow Data Manager (TFDM) for airport management. Airlines have their own set of systems designed specifically to manage their operation (e.g., flight planning system, operations management system, crew management system, tarmac monitor, diversion monitor, etc.), and each hub airport has a gate management system. Each of these systems were designed and developed to meet the historical needs of the individual users. Because the various operational needs and systems are not aligned (or share informational updates), each entity operates in a “silo,” which presents a varying or incomplete picture of what is happening. Airport management has a runway treatment plan that includes equipment to be used, surface cleaning priorities, frequency of surface treatment, and anticipated runway closure times. Deicing providers have a deicing plan that includes the number of deicing pads, spots, trucks, available manpower, type of deicing fluid, and expected deicing throughput based on equipment types. Airlines and Air Traffic Flow Management are in constant discussion regarding delay programs, made plans for flight cancellations, managed arrivals and departures rates, and made preliminary plans for surface operations.

As each stakeholder performs these activities, they have performance goals to meet. The goal of airport management is to provide the safest environment for airport operations while having the least impact on operations. Efficiency is measured by how many runways are available, the condition of the runways, how frequently the runways are closed, and the length of closures. The deicing provider’s goal is to have staff and equipment to deice a maximum number of aircraft in the least amount of time. Performance is measured by the time each aircraft requires to deice and the delay waiting for a deicing spot. The goal of the AU is to minimize the impact of

7

Page 12: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

the event and maintain operations as close to planned as possible. Success is measured by the number of arrivals and departures each hour and average delays (arrival, departure, gate delay, gate and deicing pad returns). The goal of ATC is to ensure safety while mitigating the impact of the event to maintain operations as close to planned as possible. This is measured by arrival and departure rates, actual arrival and departure throughput, arrival and departure delays, amount of airborne holding, number of diversions, and number of flight cancellations.

While a deicing event is predictable from a time standpoint, the variability of the exact timing, precipitation rates, intensity, and duration make management difficult. As the event unfolds, actual conditions (e.g., precipitation rates and intensities) and staffing levels will govern the schedule of runway closures and deicing capabilities. Gate availability will determine the airlines’ ability to schedule arriving and departing aircraft, but it is hard to predict because of the uncertainty of available departure or arrival slots and surface movements.

While attempts are made to coordinate efforts amongst stakeholders, there is often a disconnect in the information flow. Airlines will often not know when the airport will take a runway or taxiway for treatment. ATC will not know the airline gate situation, staffing levels, available deicing spots, throughput rate, and when a flight must return to the gate because of Department of Transportation (DOT) rules and Federal Aviation Regulations (FAR) 117 restrictions. As a result, aircraft often push from the gate when a deicing spot is not available or may not be metered through deicing to match departure runway availability. Holdover times or DOT/FAR 117 violations may force a flight to return to the gate or deicing pad (neither of which may be available), which further disrupts movements on the already constrained airport. Because insufficient data arrival information may not match gate availability, aircraft may not be properly metered through deicing, runway capacity may be underutilized, and unnecessary gate returns may result. All of these events add additional delay time within the entire NAS.

Information about SAA is often outdated, imprecise, or inaccurate, and message formats do not allow filtering to determine whether a SAA will impact an individual flight. Flights are often planned to circumnavigate the SAA unnecessarily or they are rerouted after departure to avoid a planned SAA. Currently, each stakeholder uses available SAA data to create flight plans that will avoid the SAA airspace, but this can be imprecise because flight plans are often formulated hours in advance of a flight and, in the meantime, the status of the SAA can change. Additionally, for long flights, an aircraft may be airborne for several hours before reaching the SAA, and during the intervening hours, the status of the SAA often changes.

The only way for AUs to minimize this uncertainty is to manually check the status of the SAA to determine whether a planned trajectory is still viable, which is cumbersome and time-consuming. Additionally, the data requirements for each stakeholder are different, but with current data sharing capabilities, the ability of each stakeholder to collect only pertinent data is limited due to ineffective data distribution methods being used. Stakeholders must manually sort through large amounts of SAA data to determine the impact on flights. This “one-size-fits-all” approach to data sharing does not lend itself to the tailored needs of the individual stakeholder. The inability of stakeholders to automatically download SAA data into their data management systems causes the effectiveness of their data management tools to be diminished. When the

8

Page 13: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

effectiveness of these tools is diminished, decisions are less strategic, placing more reliance on tactical methods to address operational problems. This has negative impacts on efficiency and safety.

Frequently, changes to SAA status are not disseminated quickly. When there is a delay disseminating changes, the options for mitigating the impact become fewer and are less efficient. Alternate trajectories must be negotiated after the flight departs, which increases the workload for AUs and controllers. This also creates subsequent impacts, as re-routed flights are introduced into airspace not previously planned to receive those flights, resulting in unanticipated volume problems requiring further mitigations. AUs and the FAA are making critical operational decisions based on SAA data, so it is imperative that the data is reliable, timely, and usable.

Information for flights that operate across international boundaries and multiple FIRs is often inconsistent between ATC and AUs. The lack of consistency sometimes delays the transfer of information between ATC facilities, or from ATC facilities to AUs. As an example, although ERAM accepts the International Civil Aviation Organization (ICAO) formatted flight plans, it converts the ICAO formatted flight plans into the old NAS flight plan format. ERAM then publishes the flight plan as part of the Common Message Set (CMS). When TFMS receives the CMS from ERAM, the flight plan is converted to a TFMS flight plan format before TFMS can process the flight data internally. As a result, planned altitude and speed changes embedded in the ICAO route are discarded. TFMS uses only the initial cruise speed and altitude that was filed when modeling a flight. Also, equipment codes and navigational capabilities are translated from the multiple ICAO codes to single-letter FAA codes, which usually causes some loss of data. The result is inaccurate flight plan equipment codes and erroneous downline traffic demand predictions, which could impact future ATC reroute decisions and potential Traffic Management Initiative (TMI) implementation.

Flight plan updates and delays are usually not transmitted until after the triggering event, which creates an interval from the event until the time it is made available to ERAM and TFMS. The result is trajectories that are not always current and arrival times that are not always accurate. Inaccurate departure or arrival times influence gate assignments, passenger connections, and crew and aircraft rotations. All are negatively impacted when the planned arrival/departure times differ from the actual times.

The following is a depiction of current NAS Operational Information Flow:

Flight information received by combination of airline schedule data & filed flight plans Information is supplemented by departure and arrival messages, position reports, etc. Information usually not updated until after the fact, creating a lack of awareness

throughout the system, resulting in trajectories that are not always current AU is unsure of the actual departure and arrival times, which negatively impact gate

assignments, passenger connections, crew and aircraft rotations AU, airport, and ATC planning is negatively affected due to lack of accurate position

reports and times

9

Page 14: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Figure 4. Current State: NAS Operations

2.1 Problem StatementA weather event at a major airport is highly complex. It requires effective interactions

and cooperation among all stakeholders to optimize surface operations and airspace utilization. Many factors make it difficult to maintain orderly traffic flows. Examples include:

Deicing Runway closures for plowing and treating Weather impacting arrival and departure routes Airport construction activities Taxiway and gate conflicts Insufficient runway capacities for arrivals or departures Restrictions placed on aircraft operators for DOT rules Crew duty limitations (FAR 117) Aircraft maintenance requirements

All these operational issues must be managed while maintaining the highest levels of safety and security throughout the system. Airport operations and AUs are especially impacted by changes to the status of flights.

Flight planning and flight operations are negatively impacted by difficulties determining the status and timing of SAA. A primary consideration for effective flight planning and flight operations is airspace availability. Accurate data concerning the status and timing of SAA is needed for AUs to plan efficient routes, and for controllers and TFM personnel to plan safe and efficient traffic flows. Frequently, operations are hampered by difficulties acquiring timely and

10

Page 15: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

accurate SAA data. At times, published data shows airspace will be unavailable due to SAA at a certain time, but the SAA is never activated. When this happens, dispatchers and pilots plan circuitous routes to avoid the SAA even though the SAA airspace was never used. This adds extra miles, fuel cost, potential overflight expense, and additional delays that are unnecessary. Airspace congestion also occurs due to funneling of air traffic to avoid the planned SAA, requiring controllers to add more spacing between flights. At other times, SAA data is disseminated using Notices to Airmen (NOTAM), but often the NOTAMs are not current, resulting in the use of outdated data. This causes unnecessarily longer routes, airspace congestion, or in-flight reroutes. Frequently, military SAA is restricted for use but is not actually being used. In these instances, improved data dissemination could return that airspace to civilian use more quickly. Late notifications of SAA also disrupt flight planning and operations when SAA becomes active after a flight departs, causing unplanned reroutes. Another problem for AUs and FAA personnel is that SAA data is not available in a format that allows automated sorting and filtering of large amounts of complex SAA data. This makes it difficult to quickly determine the airspace and flights that will be impacted.

Both domestic and international flights often experience significant deviations in their flight plan. Departure times are impacted by maintenance delays, holds for passenger connections, deicing, ramp congestion, and numerous other factors. Routes are often amended by requests for direct routings, weather deviations, traffic conflicts, etc. Altitudes change due to unplanned turbulence, unexpected winds, and actual traffic conditions. The variance of operational factors after the flight departs the gate creates a constantly changing trajectory, which, in turn, creates changes to arrival time. Both the trajectory and arrival times shown by ATC and various user systems are often in conflict. Because ATC and the Airline Operational Control Center have different perspectives of aircraft position and estimated time of arrival, decisions are made by stakeholders on flight data that is not unified. Aircraft may arrive later or earlier than planned, potentially requiring the Airline Operations Center (AOC) to reallocate ground resources to handle late arriving aircraft and may result in backups and delays on taxiways due to unplanned surface congestion. Congestion in surface movement areas, alleyways, and holding areas creates additional delay and inefficient utilization of AU assets and resources.

Currently, the ability to tie all the data and information from each of the stakeholder’s systems together does not exist. Inaccurate flight information creates unused capacity in the ATC system, unnecessary delays, and reduces decision-making ability. With the advent of SWIM formatting and data sharing, all stakeholders will be able to integrate and automate information so that all flight data can be shared, monitored, and constantly updated.

The following is a depiction of the problems with the present state of NAS operations.

11

Page 16: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Figure 5. Problem Statement Depiction

2.2 PerspectivesEach of the stakeholders performs a different function, but their activities are all related and

interdependent upon each other. Each has information within their systems that is important to them but is not currently shared with other entities. For example:

Dispatchers / Pilots: have performance and weight limiting data that arises from Minimum Equipment List (MEL) restrictions, weight penalties, or performance limitations that may require en route altitude, speed, or weight restrictions. In an extended ground delay situation, fuel load can become a factor as fuel is consumed during the delay or if suitable alternate fuel requirements become restrictive. FAR part 117 requirements must also be monitored closely. Maximum ground delays for DOT 180 rule must also be considered to prevent gate returns.

Airline Operations Management: has crew limitation data, DOT hard time limits, and passenger information that may require prioritization on a flight-by-flight basis (e.g., high value customers, large numbers of connections, international connections, or other business case priorities). Schedule reconstruction post-event activities must be considered when determining which flight, crews, and equipment needs to be where to minimize the detrimental impact to follow-on schedules.

Airline Hub Control Center: has constantly changing gate information, delay status, and expected push times. The maximum utilization of gate and ramp space as well as

12

Page 17: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

ground support personnel are critical factors in a weather event that includes ground holds. Fueling also has the potential to be impacted by severe weather.

Airport Operator: has a runway/taxiway closure schedule based on actual conditions, availability of manpower, and possible budget constraints. Maximum effort must be made to make all runways and taxiways/ramps available to handle additional capacity/volume during unscheduled severe weather.

Traffic Flow Management: Tasked with the efficient use of airspace, effective strategic planning, minimizing the impacts of SAA, and reducing the requirement for controllers and pilots to use unnecessary tactical interventions that add delay to flights.

Air Traffic Control: has information on arrival/departure rates, capacity restrictions, and all aircraft operator flight plans.

International Data Provider (IDP): provides flight data for flights that will traverse FAA (or other FIR) airspace while the flight is in that IDP’s airspace.

Flight Data Services: A Data service is a service that provides access to source data. A business service is a business function or capability offered to business or operational decision-makers. An informational service is a service that provides tailored access to data or information defined by a set of user configurable rules.

All stakeholders have separate systems to manage their part of the operation and to address their individual concerns; however, in most cases, they do not have the ability nor personnel to manually share information with other stakeholders. Operational data is constantly changing as it is updated within each system by each interested party, but the airspace system currently lacks automation and the ability to share stakeholder real time data.

2.3 Current State Operational ExampleA commercial aircraft is flying from the Seattle (KSEA) airport to the New York John F.

Kennedy airport (KJFK). KSEA is experiencing freezing rain in the area, and deicing will be required. However, the freezing rain was not forecast at this time, and deicing staff and equipment is limited. The airline has a constrained gate availability, so the flight is forced to push the gate and taxi to remote parking until a deicing spot becomes available. A significant delay is experienced before deicing is completed, and a long line of departing aircraft is in the taxi queue for takeoff due to ongoing runway treatment. Because there is no coordination between pushback, deicing, taxi, and takeoff time, the flight exceeds holdover time and must return to the gate for additional fuel before being deiced a second time. Often, the delays incurred after pushback will put the flight crew at risk of exceeding duty time, requiring crew to be replaced, or the flight could exceed DOT 180 limits, requiring a gate return.

During preflight planning, it was determined that the Dickinson SAA, which is on the preferred route, is scheduled to be active from flight level 280-370. The aircraft is not able to climb above the SAA and descending below it is operationally undesirable. The timing of the SAA will impact the flight, so the dispatcher must decide to route the aircraft north or south of the SAA, requiring a deviation of about 100 miles. Due to severe weather constraints, a southern route is not feasible, so the decision is made to reroute the aircraft north, despite the potential for increased AU costs incurred from overflight expenses from flying through Canadian airspace.

13

Page 18: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Eventually, the flight departs, and when the aircraft is one hour from the Dickinson SAA, the SAA restriction is cancelled. Due to delays processing the cancellation and sharing the information, neither the pilot nor the dispatcher is aware of the cancellation until it is too late to amend the route, and the opportunity to shorten the flight path for this aircraft is lost.

The delay created by gate return and deicing at KSEA pushes the arrival time at KJFK into a busy arrival period. As a result, the flight encounters metering and miles in trail restrictions when entering New York airspace. The flight track is extended due to a minor routing change, and holding is required at the arrival fix. Due to flight deck workload, the crew is unable to advise dispatch of the additional delay, and the arrival estimate at KJFK is not updated.

14

Page 19: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

3 Future StateIn the future, when an aircraft pushes back from a gate, the deicing and departure plan

will be known and coordinated with all stakeholders. Runway closures will be coordinated in advance, so runway availability will be known, and each departure will be assigned a departure slot. This will help maintain departure queues at a manageable level. Airspace users will know the departure time in advance, and departure slots will be coordinated to coincide with a deicing time that will allow the aircraft to complete deicing and taxi to the departure runway in time to fill the departure slot. By scheduling aircraft to arrive at the deicing location to meet their assigned time, the system will will maintain deicing flows at a manageable level without waiting in extended queues. Once a flight pushes back from the gate, information is continually updated and shared so all users have the same reliable data. Airline schedules and flight plan information will be continuously updated via SWIM with the current schedule, route, and aircraft position data to present a clear picture of events as they are occurring. Air traffic service messages will include information received from en route ATC, international data providers, oceanic ATC, surface surveillance systems, and metering systems. This will ensure that downline ATC facilities, AUs, and airports have the latest and most accurate operational data available.

Figure 6. New Reality Based on New Information Service

International flights (especially those of greater distances) will experience improved transfer of data between individual FIRs and to the destination airport. Because international flights are planned earlier in the flight planning process, and flight duration is extended, more change occurs while an international flight is en route. Winds can change more dramatically, turbulence

15

Page 20: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

may necessitate altitude or speed changes, en route weather becomes evident, and the possibility of rerouting or deviation increases. Destination airports and downline FIRs will have en route and arrival data that will be updated with increased accuracy and frequency, which will allow AUs to plan future operations more effectively and ATC to have increased fidelity regarding airspace and airport demand prediction.

Future flight plans (both domestic and international) will be exchanged via the Flight Information Exchange Model (FIXM) format. FIXM is a data exchange format that captures Flight and Flow information in a globally standardized, semantically harmonized model. FIXM is the equivalent, for the flight domain, of the Aeronautical Information Exchange Model (AIXM) and the Weather Information Exchange Model (WXXM), both of which were developed to achieve global interoperability. Flight plans in the FIXM format will have globally understood data fields, are more conducive to automation applications, and allow for enhanced communication amongst stakeholders.

Collaboration with ATC will be improved because AUs, airports, and ATC will all have the same accurate picture to manage resources. A much more precise trajectory (4DT) can be established for each flight. As changes occur during flight, updates continue to be shared with downline ATC, AUs, and airports, making each constantly aware of current and projected trajectories of each flight. This precision will improve the estimated arrival times at boundary crossings and airports.

Planning by the AU for gate usage, fleet management, and crew resources will be improved with precise arrival data. Airport planning will improve with a current picture of operations for better traffic prediction of aircraft using the airport.

Table 1 below is a depiction of various available flight data and how the individual data combines to offer a consolidated view of the entire system.

Table 1. Subset of TFMS Flight, STDDS (SMES/TAIS), SFDPS Messages

Message Name Description

Track Information

Track Information messages are used to provide a position update for the identified flight. In cases where the track position causes a route re-conformance (trajectory modeling), additional route data is provided. The messages are transmitted as received by TFMS on a cyclic basis.

Flight Plan Amend Information

The Flight Plan Amendment message provides revised flight plan data as the result of a flight plan being successfully amended.

Arrival Information

The Arrival Information message is used to provide arrival date and time information for all eligible arriving flights.

Departure Information The Departure Information message is transmitted for all eligible, initially activated flight plans.

Flight Plan Information

The Flight Plan Information message is used to provide flight plan data for all eligible flight plans.

16

Page 21: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Message Name Description

Flight Plan Cancellation

Flight Plan Cancellation messages are used to provide cancellation data for all eligible flight plans when a cancel message is received from the Host/ERAM, International Air Navigation Service Provider (ANSP) Data Exchange (IADE) interface, or an operator action associated with the schedule database that causes previously Schedule Activated flights inserted into the NAS Common Situation Model (NCSM) to be canceled.

Boundary Crossing Update

Boundary Crossing Update is used to provide TFM with current flight plan information on active eligible flights that are inbound from one ARTCC to another ARTCC facility.

Oceanic Report

The Oceanic Report type provides flight information for transoceanic flights and is generated when an Oceanic Position Report is received via National Airspace Data Interchange Network (NADIN).

Special Activity Airspace

The SAA message provides schedules and status of SAA activity.

General Information A general information message is used to communicate a free-form text message and remarks.

Hold Status Information

The Hold Status Information message provides hold information (holding fix and estimated fix departure time for definite-duration holds) on all active aircraft.

STARS Data STARS status is sent periodically (nominally every 60 seconds) and upon change of any published fields.

In a future weather event, when an aircraft pushes back from a gate, the deicing and departure plan will be known and coordinated with all stakeholders. Runway closures will be coordinated in advance, runway availability will be known, and each departure will be assigned a departure slot. This will help maintain departure queues at a manageable level.

The deicing time will determine the time when the aircraft will push back from the gate. Aircraft operators will have the ability to substitute their departure runway arrival slots to prioritize flights according to their DOT, FAR 117, or business needs. Aircraft will be rescheduled if the departure slot was missed by more than a few minutes but would still maintain a certain priority within the queue until a new delay time is published. The pushback will be timed so the aircraft is able to absorb the deicing delay at the gate before taxiing to the deicing location. This will save the airlines on both crew and block time. If the user is unable to absorb the delay at the gate due to lack of gate availability, the aircraft can be taxied to a holding area until the scheduled deicing time. AUs will know the time at which departures will leave the gate, allowing them the ability to coordinate arrival times with planned gate availability, thus improving overall gate management. Dispatchers and flight crews will know the pushback, deicing, and departure time in advance, allowing flight operations to be more efficient and predictable. By coordinating these activities, ATC will know the precise schedule of all departure operations and can reduce the number of departing or deicing aircraft holding in queue. This will free both ramp and taxiway space and allow them to plan arrival operations that will complement the departure schedule so airport throughput balance can be maintained.

In future operations, no activity will occur without first taking into account the ability of the next entity to manage the flight. This means the next flight manager’s concerns serve as an input to the current activity. For example, each pushback time will be associated with a deicing

17

Page 22: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

time, and each deicing time will be associated with a takeoff time. Each takeoff time will be associated with a runway use plan, and runway use plans will be determined by runway availability. The sequence of events in a future deicing situation for the various entities is presented in Figure 7 below.

18

Page 23: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Figure 7. Future Use Case Diagram

19

Page 24: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

As conditions change throughout the day, runway closures are adjusted in advance to minimize the impact on flight operations. Impacts of the closures will be shared with stakeholders who adjust operations accordingly. Actual performance of the stakeholder’s activities (departure rates, taxi times, deicing times, etc.) will be measured and monitored continually, and that data will be used to adjust the plans periodically. Unpredicted changes will be dealt with tactically by stakeholders. By devising a departure plan that coordinates stakeholder activities and shares information more effectively, more reliable and predictable operations result. Much of this process will be automated, and updates to any individual system will be shared with other stakeholders.

AUs will have access to SFDPS fight data via SWIM. Once a flight pushes back from the gate, information is continually updated and shared so all users have the same, reliable data. SAA data will be shared with ATC and AUs via SWIM. SAA data will be formatted for filtering and sorting, enabling AUs and ATC to readily determine impacts. AUs and ATC will have the same current data and will be able to quickly and accurately determine the status, timing, and impacts of SAA during planning and after departure. Routing decisions will be made earlier, with fewer negative impacts. As changes occur, updates will be shared giving AOCs and flight crews early notification of status changes. This will facilitate improved accuracy of flight planning, flight operations, airspace management, and coordination. This improved accuracy enables flight crews to operate with less uncertainty. Planning and collaboration between AUs and ATC will improve. Gate usage, fleet management, resource management, fuel planning, and customer experience will benefit.

Flight track will be continually updated for flights that are en route, and current track information will be shared with users. The Hold Status Information message will provide hold information (holding fix and estimated fix departure time for definite-duration holds) on all active aircraft. As a result, flight arrival times will be far more accurate.

The following is a depiction of the future NAS Operational Information Flow:

Once flight pushes back, information is shared continuously so all the users have the same updated data

Airline schedules and flight plan information will be updated continuously via SWIM with the current schedule, route, and aircraft position data that will be sent to ATC/airports

Collaboration with ATC will be improved because AUs, airports, and ANSPs all have the same, accurate picture to manage resources.

As changes occur during flight (e.g., route changes, speed and altitude changes, SAA, etc.), updates continue to be shared with AUs & airports

AU planning for gate usage, fleet management, and crew resources is improved with precise arrival data

Airport planning will improve with the current operations picture for traffic using the airport

20

Page 25: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Figure 8. Future State: NAS Operations

3.1 Future State Operational ExampleA commercial aircraft is flying from KSEA airport to KJFK. KSEA is experiencing

freezing rain in the area, and deicing will be required. However, the freezing rain was not forecast, and deicing staff and equipment is limited. The airline has limited gate availability, and the flight is forced to push the gate and taxi to remote parking until a deicing spot becomes available. Using the procedure outlined in Chapter 3: Future State, the flight pushes back from the gate, is metered through deicing, and directed to a departure runway slot. Even though the flight will be delayed, the uncertainty of the deicing and runway sequencing are mitigated. The risk of a gate return is greatly reduced, and the sequencing provides predictability for the airline, ATC, airports, and customers.

The Dickinson SAA, which is on the preferred route, is scheduled to be active from flight level 280-370. The aircraft is not able to climb above the SAA, and descending below it is operationally undesirable, so the dispatcher must decide to route the aircraft north or south of the SAA, a deviation of about 100 miles. Due to severe weather, a southern route is not feasible, so the decision is made to reroute the aircraft north, despite the potential for increased AU costs by placing the flight in Canadian airspace with associated overflight expense.

The flight departs, and when the aircraft is one hour from the Dickinson SAA, the SAA restriction is cancelled. As soon as the SAA is cancelled, notifications will be sent to all stakeholders. The AU will electronically receive the data into their airline’s internal flight planning/tracking system that monitors the trajectory of all flights. Any time SAA activity is planned or changed within a certain distance of a planned trajectory (e.g., 50-100 miles), a

21

Page 26: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

notification will be automatically provided to the AU. This will occur without human intervention.

The pilot and AOC are advised of the SAA cancellation immediately after the SAA is cancelled and jointly decide to request a route change back to the preferred trajectory. The pilot makes the request with ATC and the controller, also using the same SAA data, approves the reroute, and the aircraft begins navigating on the preferred trajectory.

The timely dissemination of the SAA data coupled with automated data processing has enabled the AOC and flight crew to maintain continuous awareness of SAA activity affecting the flight with minimal human effort. Due to the timeliness of this activity, the situational awareness of the flight crew and AOC was increased, and actions were taken to shorten the route of the aircraft and reduce the cost of the flight. The FAA, AU, and passengers all experience the benefits of this enhancement.

The delay created by the gate return and deicing at KSEA pushes the arrival time at KJFK into a busy arrival period. As a result, the flight encounters metering and miles in trail restrictions when entering New York airspace. The flight track is extended due to a minor routing change, and holding is required at the arrival fix. Due to flight deck workload, the crew is unable to advise dispatch of additional delay, but a new flight track, holding status, estimated holding fix departure time, and new estimated time of arrival are automatically communicated to the AOC.

3.2 BenefitsWith an integrated surface management system available as a common platform to

facilitate the sharing of information and coordinate actions between all the entities, it will smooth the flow of processes during an irregular operation. When outputs and inputs from all users are aligned and coordinated, the smoothest possible traffic flows will result. Using SWIM to share TFMS, SFDPS, and STDDS flight and SAA information with AUs and ATC will facilitate greater efficiency and reduce workload. This will enable AUs and ATC to readily determine impacts to flights and create mitigations that are timely and efficient

By automating the sharing of common data from the AOC, Airline Hub Control Center, Airport Operations, and the various FAA functions and systems, better predictions can be made. This helps manage deicing scheduling and throughput, runway scheduling, departure rates, traffic flows, and reduce the number of gate or deicing pad returns. Each of the entities should receive operational value and benefits from the improved information sharing and coordination of activities.

TFM will have more current and useful information for strategic planning. They can better coordinate their decisions to optimize both airport and airspace demand and capacities. The entire airspace system functions more efficiently as a result.

22

Page 27: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

ATC predictability will improve as snow removal and flight operations will be scheduled in advance. This will reduce surface congestion and departure delays, which will allow ATC to optimize arrival and departure slots.

AUs will see improved predictability for their operations. They will benefit by being aware of delays in advance so impacts can be mitigated. Gate conflicts, deicing, and departure delays can be reduced. Crew and block times can be better managed, tarmac delays will be reduced, and throughput will increase to the maximum allowed by the circumstances. If

identification of where bottlenecks occur is possible, viable solutions can be easily initiated. Pilots/dispatchers can plan and execute each individual flight operation more precisely and operations managers can better prioritize their fleets on a flight-by-flight basis to improve management of the airline’s business model. This equates to lower block times, timelier passenger information, better delay management, improved customer service, and will help to maintain the airline’s system integrity.

Airport operators will have an improved view of customer, vendor, and user activities at their airport and can use this information to plan their staffing levels, overtime needs, and schedule their operations. Deicing operations will improve as flights will be scheduled in advance to match deicing output with departure capability. Deicing queues will be reduced by coordinating deicing times with pushback times. Because certain information is known (e.g., assigned times for pushback from the gate, entering ATC control upon ramp exit, deicing pad arrival/departure, and runway arrival time), measurements of these metrics can be taken against the actual times to see immediately where the issues lie, and resources can be directed accordingly to correct the problem.

Airport service providers will have a clearer picture of events as they unfold. With more timely and complete information, they will be able to align their staffing needs and schedule activities based on current and changing conditions.

Efficiency is improved by simplifying operations, improving communications between stakeholders, and adding structure to operations. Flight operations will be managed more effectively as dispatchers and flight crews will be informed of delays and schedule changes in advance.

The main beneficiaries will be the passengers and airline customers, as they will experience more accurate delay information, improved predictability, and fewer system failures that leave them stranded in airports with limited options.

Improved flight data and sharing of information with stakeholders will allow AUs and airports to know precisely when aircraft will depart and arrive. This enables improvements to:

Decision-making concerning aircraft fuel efficiency Diversion management Gate management Flight crew management Ground crew management

23

Page 28: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Delay management Fleet management Customer experience TFM system performance Airport effectiveness

3.3 ConclusionThese benefits would be achieved by enhanced collaborative decision-making by all

stakeholders during all strategic and tactical phases of flight (pre-flight, in-flight, and post-flight). The improved shared situational awareness will increase the accuracy of all flight information. The expanded availability of quality data will allow for increased system performance and more flexible communications between air traffic managers and AUs. Operators will have a better understanding of actual flight position, future flight position, and possible downline options. As a result, they will have a clearer picture of possible miles in trail restrictions, corner post arrival restrictions, metering, fix balancing, or any other adjustments that will impact arrival time. This improved visibility will create awareness by ATC of crew- and fuel-critical flights. Having this knowledge shared between AUs and ATC may prevent some future diversions or gate returns, which will further improve overall system integrity.

More precise runway and gate arrival times will allow AUs to increase the efficiency of gate scheduling and utilization by optimizing ground and turn times. This will subsequently enhance the accuracy of departure times, the posting of passenger delays on individual flights, and the ability to meet required wheels up times. Benefits of this higher-quality data include improved crew/fleet management and the ability to make better business decisions by operations managers.

The additional precision of flight data will allow for pilots and dispatchers to flight plan with higher predictability and better manage diversions and diversion recovery. Airport operations can make more informed decisions to efficiently schedule gates, ramps, manpower, and equipment.

The improved availability of timely arrival and delay information will provide AUs with elevated predictability, fewer system failures, and an overall improvement in customer experience.

24

Page 29: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Appendix A – Acronym ListingTable 2. Acronym Listing

Acronym Definition4DT Four Dimensional TrajectoryAIXM Aeronautical Information eXchange ModelAOC Airline Operations CenterANSP Air Navigation Service ProviderARTCC Air Route Traffic Control CenterASDE-X Airport Surface Detection Equipment - Model XASDI Aircraft Situation Display to IndustryASSC Airport Surface Surveillance CapabilityATC Air Traffic ControlAU Airspace UserCMS Common Message SetDOT Department of TransportationEDCT Expect Departure Clearance TimeEFSTS Electronic Flight Strip Transfer SystemERAM En Route Automation ModernizationFAA Federal Aviation AdministrationFAR Federal Aviation RegulationsFIR Flight Information RegionFIXM Flight Information eXchange ModelFP NAS Flight Plan formatFPL ICAO Flight Plan formatIADE International ANSP Data ExchangeICAO International Civil Aviation OrganizationIDP International Data ProvidersKJFK New York John F. Kennedy AirportKSEA Seattle AirportMEL Minimum Equipment ListNADIN National Airspace Data Interchange NetworkNAS National Airspace SystemNCSM NAS Common Situation ModelNOTAM Notice to AirmenOAG Official Airline GuideRVR Runway Visual RangeSAA Special Activity AirspaceSFDPS SWIM Flight Data Publication Service

25

Page 30: connect.lstechllc.comconnect.lstechllc.com/files/Flight Use Case v1.1_20181206... · Web view2018/12/06  · Flight Use Case Document Version 1.1 12/6/18 2 2 System Wide Information

Flight Use Case Document Version 1.112/6/18

Acronym DefinitionSMES Surface Movement Event ServiceSTARS Standard Terminal Automation Replacement SystemSTDDS SWIM Terminal Data Distribution SystemSWIM System Wide Information ManagementTAIS Terminal Automation Information ServiceTBFM Time Based Flow ManagementTDES Tower Departure Event ServiceTDLS Tower Data Link ServiceTFDM Terminal Flight Data ManagerTFM Traffic Flow ManagementTFMS Traffic Flow Management SystemTMI Traffic Management InitiativeTMU Traffic Management UnitTRACON Terminal Radar Approach ControlWXXM Weather Information eXchange ModelXML eXtensible Markup Language

26


Recommended