Design Recommendations for an Integrated Approach to the Development, Dissemination and Use of Reroute Advisories

 

Roger Beatty and Phil Smith

Cognitive Systems Engineering Laboratory

The Ohio State University

December 11, 2000

This report was produced under funding from the

FAA Office of the Chief Scientist for Human Factors

 

 

Abstract

Frequently, Air Traffic Control-Traffic Flow Management (ATC-TFM) needs to:

  1. Amend user filed routes; or
  2. advise the user prior to filing that only specific routes are available due to some NAS constraint..

This is done today by the issuance of a Special Traffic Management Advisory, commonly referred to as a Reroute Advisory, via teletype circuit and a Web page. A review of this process suggests that this is currently a very labor-intensive process for the recipients for these advisories, both within the FAA (ARTCCs, TRACONs and Towers) and at the airlines. As a result, responses to these advisories may not always be completed in a timely fashion. This paper discusses the deficiencies in the current system and describes a range of possible improvements that would help to ensure that the development of the component subsystems is consistent with the long-term goal of providing an integrated reroute advisory system.

From a broader human factors perspective, this report serves to highlight one of the major challenges that arises when designing tools to support a distributed work environment that is evolving over time. Tools need to be designed to effectively support the specific responsibilities of different individuals, with the result that some of the tools required by traffic managers may be quite different from some of those required by airline dispatchers. However, these tools must also be designed to support interactions within this distributed work environment, allowing these individuals to coordinate their activities as effectively and efficiently as possible.

 

Concepts and Opportunities in Route of Flight Information Data Transfer

I. Overview

Normally, the user preferred route of flight is sent from the user (Airline Operational Control Center or pilot) to ATC in the rather formal and standardized filing of an ATC IFR flight plan. In a perfect world this filing would be accepted and the flight flown per the user's plan, which would satisfy both his business goals and safety concerns, and would not conflict with other flight operations.

Unfortunately, in the ever more congested National Airspace System (NAS) this scenario is becoming increasingly unlikely. Frequently, congestion (weather induced or simply created by excessive demand) requires Air Traffic Control - Traffic Flow Management (ATC-TFM) to amend user filed routes or advise them prior to filing that only limited or specific routes are available.

This paper will discuss how this process currently operates, outline shortcomings in the current system, and provide recommendations on how to improve the speed, accuracy and effectiveness of route information data transfer amongst the various parties using the system.

II. Participants in the Reroute Advisory Process

We may consider the current users of the route information data transfer system to be the following:

A) The originator of the user preferred route. Normally the AOC dispatcher and/or pilot is tasked with considering the business and safety needs of the operator. Some of these considerations are: payload versus fuel tradeoffs, direct operating economics (e.g. schedule reliability vs. fuel consumption) and FAR required operational safety analysis of each planned flight.

B) Detectors of the congestion problem and developers of the ATC traffic flow congestion mitigation plan. These are normally Air Traffic Control System Command Center (ATCSCC) and ARTCC TMU specialists, sometimes in consultation with airline AOC staff. (see also Airline ATC Coordinator below).

C) ATC implementers of the congestion mitigation plan. These are normally individual Air Traffic Controllers working the Sector or Flight Data positions, supported by supervisors and ATCSCC and ARTCC traffic management staff.

D) User implementers of the ATC congestion mitigation plan. Depending on the phase of operation (pre-departure or post-departure) this is the AOC dispatcher filing the flight plan or the pilot accepting and flying the flight plan amendment.

E) ATCSCC, ARTCC and intra-airline coordination and optimization for the ATC congestion mitigation plan. This coordination is commonly done through the Airline ATC Coordinator position at the airline’s Operational Control Center, but may also be done by a Chief Dispatcher or another senior Dispatcher at the airline. This is a relatively new responsibility at most airlines. This position often acts as an intermediary between the four functions outlined above. (Currently there is no regulatory requirement for the function of the Airline ATC Coordinator, but the position is most frequently staffed by airline dispatchers or dispatch managers who have had specialized training and focus on ATC operational issues. This position often interacts with ATCSCC, ARTCCs and Dispatchers in functions B) and D) as outlined above.)

It is important to note that, in terms of the role of the Airline ATC Coordinator, ATC-TFM (FAA) staff occasionally assume incorrectly that, if an Airline ATC Coordinator acknowledges or agrees to a course of action, all other airline participants (dispatcher and pilots) have been informed and concur with the Airline ATC Coordinator's opinion. Depending on the design of the airline's communication and personnel reporting structure, this may not always be the case.

F) Quality assurance and systems analysis staff (within the FAA and the airlines).

These groups are often overlooked since they do not normally participate in real-time operations. It is however, crucial to the ongoing refinement of policies and procedures that this group be able to review, with great fidelity, operational events and decisions.

III. The design and implementation of an ATC-TFM traffic flow congestion mitigation plan

Currently, it is typical for the ATC-TFM function to be the first to detect and react to a traffic congestion problem. The reasons for this are four fold:

A) Only ATC-TFM can see all of the IFR flight plans as they are filed. (This is changing as electronic data transfer efforts such as ASDI become available to NAS users.)

B) ATC-TFM has access to the Enhanced Traffic Management System (ETMS), which is the "official" view of future traffic congestion problems that is currently used to as the basis for TFM decisions. ETMS has a combination of historical, "modeled", filed and actual traffic data that is unavailable to the airline user.

C) One of the determining factors in deciding if congestion exists is that the projected aircraft demand will place excessive workload on ATC staff. It is therefore reasonable that ATC management should attempt to control its own organization’s workload. (While there is much debate on whether these workload estimates are reasonable, and whether reducing demand or increasing staff is a more appropriate reaction, this is beyond the scope of this discussion.)

D) The ATC-TFM congestion mitigation plan is the only one that "counts" since ATC-TFM has the authority and responsibility for developing and implementing such plans. Although this plan may be developed in consultation with users, ultimately, one plan has to be selected for implementation.

Once the predicted congestion is detected, a mitigation plan must be devised. Since ATC-TFM is frequently confronted with weather induced reductions in air space, it is common for them to think of how aircraft should "flow" around these unusable or Flow Constrained Areas (FCAs) in order to avoid excessive traffic congestion or complexity. Thus, if an area of thunderstorms is located over Little Rock AR (LIT), ATC-TFM needs to describe a plan in which some East-West traffic will flow to the south of the area and some to the north. This is commonly done by ATCSCC issuing a "REROUTE ADVISORY MESSAGE" via Teletype circuit. (These advisories are now also available on the ATCSCC Web page.)

If we assume that the primary objective of the ATCSCC Reroute Advisory System is to take traffic flows that were "predicted" to happen and change them into flows that "should" happen, then a common understanding of what flights are involved in the original prediction is crucial. It is also important that the description of what should happen is communicated with sufficient clarity to allow the implementers of the plan to assign to the appropriate flights, operating at specific times, the specific routes required by the congestion mitigation plan.

This is in fact quite difficult at the present time because of a lack of integrated tools for developing decisions and sharing information among FAA facilities and airline AOCs.  From the user’s point of view, if the dispatcher hasn’t yet submitted a flight plan to ATC, that flight has no route. From the ATC-TFM point of view, this flight does have a route.  It has a "historical" route provided by ETMS which will eventually be replaced by the user’s intended route once the flight plan is filed. 

This situation leads to two problems.  First, the user doesn’t know what flights ATC-TFM thinks are included in a particular advisory, as the user doesn’t know what flights the ETMS model has identified as relevant.  This makes it hard for the user to determine which flights to file consistent with the reroute advisory.  Furthermore, ATC-TFM doesn’t know whether a flight has been identified as relevant by ETMS because of a modeled route or because of a user-submitted flight plan, as it is difficult if not impossible to tell if the route of flight (and therefore the predicted traffic demand) in ETMS is based on historical or user supplied flight plans. Because of this uncertainty, ATC-TFM could be solving a nonexistent problem (if in reality, the users were not planning to file through the constrained airspace).

IV. How to determine the success of a Reroute Advisory Message

It is instructive to decompose a typical Reroute Advisory Message to see what process the reader must undertake to translate the information it contains into user action. That action is first the determination of what flights apply to the instructions in the advisory. Secondly, the user must update the route in a manner consistent with the advisory. For a dispatcher, that might be changing the input to the airline’s flight planning and tracking software in order to generate information on a new departure time or route of flight; for the ATC controller it might be updates to the ATC host computer; for the pilot, it might mean amending his flight plan using the on-board Flight Management Systems (FMS).

A representative Reroute Advisory is as follows:

ATCSCC ADVZY 046 DCC 11/08/2000 REROUTE ADVISORY MESSAGE: 

IMPACTED AREA: JFK LTFC THROUGH ZAU  
REASON: VOL/COMPLEXITY ZAU/ZOB    
ASSIGNED REROUTE: ONL J94 PMM J70 LVZ LENDY4 JFK 
FACILITIES INCLUDED: ZAB/ZLA/ZOA/ZLC/ZDV/ZSE/ZLC/ZMP/ZAU
VALID UNTIL: 2200Z
       
REMARKS: FLIGHTS THAT NORMALLY FILE O/GRB INTO CANADIAN AIRSPACE
WILL BE LEFT ON FILED ROUTES.

EFFECTIVE TIME: 081452 - 082200 SIGNATURE: 00/11/08 14:51

This message structure first has a header indicating the message number and type of advisory. This is followed by a description of the impacted area. In this case it is not really an area but a combination of what Center the flight is transiting and at which airport it is landing. The user might read this example as applying only to traffic transiting ZAU (the Chicago ARTCC) and landing at JFK (JFK New York). The reason for this restriction is "VOL/COMPLEXITY ZAU/ZOB" and the congestion mitigation route that should be assigned to appropriate flights is "ONL J94 PMM J70 LVZ LENDY4 JFK".

The section labeled FACILITIES INCLUDED: ZAB/ZLA/ZOA/ZLC/ZDV/ZSE/ZLC/ZMP/ZAU would lead many users to decide to use these Centers as a guide to determine the origination airports of the affected flights. While this is a good guess, and would be correct for the majority of flights involved, it is not 100 percent accurate. For example if this advisory were applied to the ORD to JFK city pair, flights departing ORD would be required to fly westbound into ZMP (Minneapolis ARTCC) to pick up the assigned route at ONL (Oneill, NB) some 500 miles to the West before turning back East to JFK. Even those departure airports where the "FACILITIES INCLUDED" provide accurate guidance, user knowledge of which airports are contained in which ARTCCs is required.

Presumably the "VALID UNTIL: 2200Z" would indicate that this restriction should be applied from 1452Z (the issue time) until 2200Z. The next question now faced by the user is: Does this valid time apply to a specific flight’s departure time? The flight’s arrival time? Or does it apply to the time it is expected to enter the "Impacted Area"?

The statement in the remarks section that "FLIGHTS THAT NORMALLY FILE O/GRB INTO CANADIAN AIRSPACE WILL BE LEFT ON FILED ROUTES." is even more confusing. Since a flight  plan is often calculated to take advantage of changing wind conditions, it is difficult to determine what constitutes a "normal" filing over GRB (Greenbay, WI).

In summary, while this advisory is an attempt to have implementers of the ATC congestion mitigation plan assign specific flights to a route, it fails to deliver sufficient detail or clarity to allow this to happen. The implementers must infer the departure airport and appropriate operating times and then determine the collection of what might be the appropriate flights.  Implementers could be the dispatcher in charge of that flight or a traffic manager at the departure Center or airport tower.

While experienced humans (after much time and effort) are capable of working with this kind of unclear and implied direction, less experienced users and computer automation (which must be used to help generate possible flight plans consistent with the advisory) find it almost impossible to deal with these ambiguities in determining which flight should be affected by an advisory. Additionally, any analytical effort that attempts to use automated means to collect and compare reroute data is impeded by the lack of clarity in such an advisory.

V.   Improving the Reroute Information Data Transfer

There are a number of points in the current reroute advisory process where improvements could be made to enhance the system. Some are small and concern only changes to the wording and format of the current advisory system. Others involve automation improvements that range from limited changes at ATCSCC to wholesale integration of ETMS and airline flight planning systems.

To better organize these possibilities and allow for a strategy that would build on simple and quickly deployed changes but still be mindful of an overall integrated development path, we offer the following outline.

A)  Better wording of current Reroute Advisories. ATCSCC specialists are confronted with the task of communicating complex descriptions and instructions in the fewest words possible. To that end Reroute Advisories often contain abbreviations, contractions and shorthand descriptions that are undecipherable by some users. For example a statement such as "Flights departing the LAX basin bound for N90 should ..." is attempting to convey that a collection of flights departing airports in and around LAX that are going to airports that are served by the New York TRACON (N90) should take some action. The user, however, must interpret which departure airports are in "the LAX basin" (might SAN be included?) and might not even know where or what is "N90". 

Given that the current advisory system requires such shorthand notation, it is recommended that ATCSCC and airline users develop a lexicon of these terms that provide the official definition of these terms. This would allow users to decode the unfamiliar expression and encourage ATCSCC specialist to use official terminology when ever possible.  (This interpretation process could also be assisted by suitable graphical interfaces that would reduce the burden on the user to decode the expressions.  This solution is discussed further below.)

B) Better structure to current Reroute Advisories. Even thought the current Reroute Advisories have significant structure, the format is not sufficiently comprehensive or rigid to allow for automation to easily parse them.  In the current system each advisory must be interpreted for content by every flight planner and congestion plan implementer. This is a significant consideration since, on a bad weather day, well over 100 advisories can be issued that affect thousands of flights and require hundreds of people to interpret them in real time.

One of the possible methods for imposing structure on the advisory is to have the specialist enter the required information into a template and have the template create the actual Reroute Advisory.  This could lead to many benefits:
1) Allow rapid entry of complex advisory information such as Playbook routes and CDRs.
2) Improve human interpretation of advisory content due to the consistent structure even if automation is not applied to assist the user.
3) Develop automation for the user to automatically direct advisories to the appropriate decision makers.
4) Provide advisories that would be sortable to accommodate different user needs.
5) Enhance the ease and effectiveness of quality assurance and systems analysis efforts. 

C) Graphical interface to create the advisory. The ATCSCC specialist and other TFM personal could possibly increase precision and save a great deal of effort by creating Reroute Advisories using a graphical interface. Elements of such an interface might be:
1) The ability to display forecast weather and traffic flows on a geographical map.
2) The ability to select/specify the constraint and constraint time period in a point and click environment.
3) The ability to retrieve and select from pre-defined routes (such as CDRs), either by selecting from organized lists or by selecting a route on a map display.
4) The ability to create ETMS flight lists from the graphical interface.
5) The ability to create and contrast several different "what-if" solutions before committing to a course of action.
6) The ability to create an advisory and update other automation systems from the display.
7) The ability for a group of people at remote sites to view and interact with shared displays. (Increasingly, the creation of advisories involves collaborative processes where ATCSCC, ARTCC and/or AOC staff use teleconferencing to discuss a situation and consider alternatives. To be more effective, these distributed groups need to be able to view and manipulate shared displays.

D)  Machine readability. The term "machine readability" here means a class of computer to computer interactivity that allows for a high degree of specific data transfer. In most of the examples above, while the Reroute Advisory process is improved, it is still up to the human user to determine which particular flights are affected by the advisory and to manually intervene to make the reroute occur. In some cases this manual intervention may be the dispatcher building a route in his flight planning software or the ATC controller typing a full route clearance into the host computer. Thus, by applying this machine readability concept, the automation systems at ATC, AOC and the cockpit would be able to directly accept and interpret the route information from each other, saving a great deal of time and reducing the possibility of human input error.

Like the other efforts described above, there is a range of possibilities that would migrate from the simple to the more ambitious for taking advantage of increased machine readability .  Examples are:
1) Link advisories to the Common Constraint Situation Display (CCSD) that VOLPE is developing. The CCSD is a graphical display of constraints in the NAS. It should be available by April of 2001. This system is ETMS based and could allow users to see associated Reroute Advisory information and along with the underlying ETMS data.
2) Create an ETMS list request that would allow users to receive a list of flights covered by specific advisories.
3) Link CDR and Playbook databases so they may be used in the creation of advisories, allowing the user to pick from displayed routes using a graphical interface.
4) Implement a design such that routes could be exchanged in a common computer readable format such as the ARINC 424 standard.
5) Allow for congestion based flight planning by permitting users to develop flight planning tools that interact directly with the outputs of ETMS congestion predictions.

E) Graphical interface to display advisory information. Section V.C. above points out the need for a graphical interface to create advisories. Graphical interfaces are also needed to support the work done by the congestion plan implementers (Dispatchers or traffic managers at ARTCCs or Towers). In many cases, it is advantageous to display geographical as well text-based Reroute Advisory information. 

The design of such a display must carefully consider many factors in order to be successful. Among them are:
1) The problem of displaying selected or multiple alternative routes on a single display (possibly linking this display to Playbook and CDR databases to provide easy access to these routes).
2) The ability to display what is predicted to happen versus what is desired to happen versus what has actually happened. 
3) The problems of 4D (time) displays where the users must work in multiple time frames.
4) The human factors problem of displaying predictive data of varying levels of reliability (Smith, McCoy, and Layton, 1997).

F) Data structures and tools to support quality assurance and analysis staff.  Both the FAA and the airlines need to be able to evaluate the quality of performance within the NAS when various reroutes and reroute procedures are used.  As an example, airline ATC Coordinators need to know whether the reroutes that they negotiate in teleconferences with ATCSCC and ARTCC staff are actually submitted as flight plans by individual dispatchers, and if so, how closely the flight crew and ATC system follow these plans.  Many of the features listed above would greatly enhance the ability for quality assurance staff to perform such analyses. 

VI.  Summary

The theme of this paper has been the need for better information systems to support the creation and use of route and reroute information within the FAA ATC/TFM system and within airline AOCs. One major topic has been the need for better integration across the subsystems that support the work done by different individuals within this distributed work system (Smith, Billings, et al., 1997).  A second topic has been the need to provide this information in a form that both people and computers can deal with more accurately and efficiently, so that automation can be developed to handle some of the more routine processing activities. 

There are clearly a number of human factors issues that are central to these concerns. These issues range from the potential to reduce workload and to reduce the potential for errors, to the need to understand and support individuals when they are performing their subtasks alone as well as when they are interacting with other people in real-time discussions.

Thus, ultimately, it is important to recognize that these tools need to support a distributed work environment (Smith, P.J., McCoy, et al., 1998), where different people (and computer systems) need access to different subsets of the overall information set, and need to be able to display and interact with this information in different ways in order to work in a coordinated fashion with each other while completing their specific subtasks.

As mentioned above, at present, there are a number of prototypes and operational systems that deal with subsets of this problem. Among these systems are:
A) The ATCSCC Advisory, CDR and National Playbook Web pages.
B) Metron’s CDR Tool.
C) The Event Advisory Monitor System that has been developed by The Human Factors and Experimental Ergonomics Laboratory at Kansas State University.
D) VOLPE’s Common Constraint Situation Display.
E) Functions supported by ETMS to retrieve flight lists according to certain criteria.
F) MITRE’s CRCT.
G) ATCSCC’s National Logs Project
H) POET.


What is now needed is a integrated plan to evolve from currently available tools and databases to a more integrated system that supports the distributed work that is involved in the creation and use of route and reroute information within the FAA and the airlines.

VII.  References

Smith, P.J., Billings, C. Woods, D., McCoy, C.E., Sarter, N., Denning, R. and Dekker, S. (1997). Can automation enable a cooperative future ATM system? Proceedings of the 1997 Aviation Psychology Symposium, 1481-1485.

Smith, P.J., McCoy, E. and Layton, C. (1997). Brittleness in the design of cooperative problem-solving systems: The effects on user performance. IEEE 

Transactions on Systems, Man and Cybernetics, 27, 360-371.

Smith, P.J., McCoy, C.E., and Orasanu, J. (1998). Distributed cooperative problem-solving in the air traffic management system.  Proceedings of the Fourth Conference on Naturalistic Decision Making, Warrenton VA.