INTEGRATED DEPARTURE ROUTE PLANNING Anthony Masalonis, Hilton Bateman, Lixia Song, Norma Taber, Craig Wanke

The MITRE Corporation, McLean, VA Rich DeLaura, Massachusetts Institute of Technology/Lincoln Laboratory, Lexington, MA

Abstract

This paper describes research on the Integrated Departure Route Planning (IDRP) operational concept and supporting functions that will assist Traffic Flow Management (TFM) personnel conducting departure management. IDRP will provide automated support and information to help decision makers evaluate and implement different solutions, taking into account all significant data such as filed flight plans and acceptable alternatives, surface departure queues, predicted convective weather and traffic congestion impacts to routes in the terminal area and nearby en route airspace, and forecast uncertainty. By bringing all of these factors into a single integrated environment, IDRP will reduce the time needed to make departure management decisions and coordinate their implementation, increase the effectiveness of the decisions made, and support efficient revision of departure management plans as weather and traffic situations change.

IDRP’s background and operational concept are described, followed by an overview of a prototype used to demonstrate and evaluate the concept. Results are presented from a series of interviews with experts having TFM experience; these sessions helped to enhance the operational concept and refine the information requirements for the prototype. Next steps are to implement the IDRP prototype in operational centers for the purpose of obtaining further data about the usage and benefits of the capabilities, and to conduct additional laboratory research exploring more highly automated IDRP functionality and addressing integration issues.

Introduction

Background In the U.S. National Airspace System (NAS),

TFM is the function that balances air traffic demand

with available system capacity, to ensure a safe and expeditious flow of aircraft. A variety of Traffic Management Initiatives (TMIs) are generated to protect the NAS when traffic demand on sectors, routes, or fixes is predicted to exceed the capacity, especially when capacity is reduced under severe weather impact. TMIs include reroutes, miles-in-trail (MIT) flow restrictions, and ground delay programs (GDPs). Traffic Management Coordinators (TMCs), also referred to as traffic managers, must be able to identify the need for TMIs, explore alternatives, and prepare a justification. The traffic manager must also continuously monitor and evaluate the TMI, and make adjustments as necessary, including cancellation. In current operations, with limited automation support, traffic managers have to mentally integrate the traffic, weather, and airspace resource information and project the information into the future. This process is difficult, time-consuming and prone to error. As a result, TMIs are often too large-scale or inflexible to respond to dynamically changing weather conditions (e.g., GDPs and ground stops), or are not used effectively (e.g., MIT and reroutes). It is imperative to minimize the impact of TMIs on operations and to implement only those initiatives necessary to maintain system integrity. The MITRE Corporation and Massachusetts Institute of Technology/Lincoln Laboratory (MIT/LL) are conducting a joint research effort to develop concepts and prototype applications for departure management decision support in convective weather. The goal is to develop a set of functions that can help traffic managers to manage departure traffic more efficiently and safely using integrated departure route and en route sector congestion information, especially when convective weather is present.

The Route Availability Planning Tool (RAPT) [1] was designed by MIT/LL to help TMCs determine the specific departure routes and departure times that will be affected by significant convective weather. RAPT helps users to

978-1-4244-2208-1/08/$25.00 ©2008 IEEE. 3.E.3-1

determine when departure routes or fixes should be opened or closed and to identify alternative departure routes that are free of convective weather. A field assessment of RAPT undertaken jointly by by MIT/LL and the Federal Aviation Administration (FAA) in the summer of 2007 [2] documented significant departure delay reductions due to decisions made with the assistance of RAPT. However, the study noted several operational factors that limited the ability of air traffic managers to use tools like RAPT effectively. On several occasions, coordinating facilities were not aware of the state of departure routes (open, closed, MITs in effect) or did not fully understand the airspace concerns and constraints of other facilities. When the information or knowledge is limited as to why a particular TFM decision has been made or as to what type of impacts a decision can have on other airspace operations, team collaboration and decision-making suffers.

Problem Addressed RAPT was originally developed based on

experience with the Integrated Terminal Weather System (ITWS) prototype in New York. Discussions with managers in area towers and the New York Terminal Radar Approach Control (TRACON) suggested the need for departure management decision support during convective weather. The RAPT prototype is used to estimate and visualize the weather impact on departure time for each departure route.

Evaluation of RAPT decision support guidance [1, 2] identified key areas for improvement in the algorithms and display, and identified several potential benefits of improved/integrated decision support. Issues calling for enhanced support included uncertainty about the status of NAS resources (e.g., which routes are closed and why), and congestion en route or at departure fixes (which may or may not be due to weather-related flow disruptions).

Impediments to efficient departure management during adverse weather or volume congestion include the workload associated with determining 4-D (space-time) intersections of departures and storms, estimating the impacts of storms on departure traffic flows and translating those impacts to departure times and determining a

suitable alternative departure route for aircraft whose filed departure is unavailable due to weather or volume related constraints. Coordination within and between ATC facilities and/or with airlines to orchestrate departures in these off-nominal situations is also problematic, due to inadequate common situational awareness of route constraints, and due to use of verbal communication to achieve common awareness of current and future storm blockage affecting departure fixes and routes. Another issue with today’s departure management is sub-optimal departure queue sequencing. When weather or volume impacts are significant, departing aircraft with cleared departure routes are often behind flights whose departure routes are unavailable, resulting in excessive and avoidable delays.

Operational Concept IDRP will partially automate, and/or provide

decision support for, rerouting, sequencing and delay decisions. This increased automation will reduce the workload needed to identify and implement reroutes for avoidance of obvious weather or volume congestion impacts, and allow traffic managers and airline dispatch to focus more effort on solving other problems such as surface management and risk assessment/ mitigation.

The underlying concept of IDRP is to combine predictions of weather impacts along departure routes from RAPT, predictions of congestion at departure fixes and in nearby en route airspace, and an automated reroute identification algorithm into a single decision support tool that will help traffic managers implement reroutes for departures blocked by weather or traffic constraints.

IDRP will identify departure flights whose flight plans cannot be executed due to weather or volume constraints, and search the set of alternatives acceptable to TFM/ATC and airline operations to find feasible (i.e., unblocked) reroutes. Alternatives explored by IDRP will include the option to delay departure until weather or operational circumstances change.

IDRP expands upon the capabilities of RAPT in several ways relating to the route blockage and route options capability. One is to add flight-specific route impact information. While RAPT

3.E.3-2

3.E.3-3

indicates to the user whether a flight departing at a given time will encounter weather blockage if it departs on a given route, the information is general for the departure route using an average or typical flight trajectory. In reality, of two flights departing the same route at the same time, it is possible that one will encounter blockage and one will not, due to flying at a different speed or altitude, or taking a different route after the departure fix but before leaving the temporal and geographical scope of departure management personnel’s interest. By providing specific departure trajectories to RAPT, IDRP can obtain and present weather impact information for individual flights, including the viability of various reroute options for flights that cannot depart on their planned route.

IDRP will also provide estimates of traffic volume impacts on departure route availability. The IDRP grid has options to show the weather-related impact to a specific flight’s trajectory if it departs during a given time interval, or to show the traffic-related impact, or both. Another display option, for which algorithms and display issues are still being researched, is an “integrated” impact display that shows a single measure of impact which in some way weights the effects of weather and traffic on the route.

While IDRP features a richer set of display options, this increases the risk of information overload. Therefore, the users can toggle on and off the various grids and features to tailor the display to the level of detail and type of information required. Significant human factors research will be required to identify the optimal presentation of information and set of user interface features.

In order to determine the status of specific proposed departures, IDRP must be integrated with other surface and departure management decision support tools. In the near term, it is envisioned that

IDRP will integrate with some of the functionalities of the Departure Spacing Program (DSP) capability currently used in the New York area to provide flight plans, departure times and departure queue positions for pending departures to traffic managers at coordinating facilities.

It is likely that IDRP will be used differently at each type of facility. Under the initial concept of operations, in the en route ATC center or Air Route Traffic Control Center (ARTCC), it might be used to explore reroutes for a group of aircraft; TMCs at ARTCCs might be concerned only with the route information and not the flight-specific information. The focus of the TRACON will most likely be on choosing reroutes and/or delays for individual aircraft to solve departure fix congestion or avoid weather blockage at these fixes, though if present operations continue, much of this work will be conducted at the ARTCC. TMCs at the towers might use IDRP to change the lineup queue based on their view of the airport situation. Though the initial IDRP concept does not call for its use at the national Air Traffic Control System Command Center (ATCSCC), this facility might eventually utilize IDRP as a reference to maintain their awareness of congested departure routes. It is not envisioned that ATCSCC would be concerned with flight-specific information.

IDRP Prototype Capabilities The IDRP prototype was built to demonstrate

the operational concept, and to support operational evaluations of the concept. The demonstration and evaluation work made possible by the prototype will determine which automation capabilities best meet the needs of TMCs conducting departure planning. Figure 1 shows the Situation Display of the IDRP prototype.

Current Weather

Gates

Moderate Congestion Severity

No Congestion

EastHigh Congestion Severity North

WestSouth

Figure 1. IDRP Situation Display

Key features include a color-coded Corridor Integrated Weather System (CIWS) weather display showing exactly where weather blockage is occurring. NAS sectors are also shown, as are the

departure routes. Each of these display elements can be toggled. In Figure 2, the weather display is disabled.

3.E.3-4

Moderate Congestion Severity

High Congestion Severity

No Congestion

GatesEastNorthWestSouth

Figure 2. IDRP Situation Display Without Weather

This display allows a clearer view of the departure routes. Here, the routes leaving New York are shown, color-coded by the general direction of the route; in many locations, TMCs, air traffic controllers, and supervisors group routes for easy reference into “gates” based on route direction, e.g., “west gates” and “south gates”. Demand, capacity, and congestion information for the sectors along each route can also be shown. In Figure 2, each sector traversed by one or more of the departure routes being displayed is colored

according to the presence and severity of traffic congestion (green, yellow, and red, in order of increasing congestion severity). Another feature of the Situation Display, not shown in Figure 2, is the time slider, which the user can click and drag to see a still or animated forward projection of aircraft trajectories and predicted weather and congestion, or to see a still or animated history of where the weather and traffic have been.

The route blockage and congestion information are presented in grid form, shown in Figure 3.

3.E.3-5

DisplayOptions

RouteGrid

FlightGrid

RerouteOptions

Figure 3. Blockage and Congestion Grids

The top pane above the grids allows the selection of various display options, including whether to display the departure route impact resulting from weather, traffic, or both, as described earlier. In this example, the Weather (i.e., weather only) option is selected.

Each column in the color-coded grids represents a five-minute interval, starting at the present time and optionally extending out for up to 60 minutes (a 35-minute look-ahead is shown in Figure 3). In the topmost (route) grid, each row is a departure route, composed of the departure airport, fix(es) (e.g., BREZY) and airway (e.g., V419). The number of flights filed along each route is also provided. The grids can be filtered or sorted by any available field, such as gate, departure fix, route, and origin.

The cell where each route and time interval intersect is color-coded according to the impact to be encountered by a flight taking off at the specified time and flying that route. Text in the cell indicates

the nature of the impact: the echo top (essentially the highest altitude, in thousands of feet, of the weather blocking the route) and location (e.g., N90 means New York TRACON airspace and ENR means en route). Note that the color and impact information does not indicate whether the route will be impacted at the specified time, but rather is tied to flight departure time. For example, a flight departing from Teterboro, NJ (TEB) and using the departure route beginning with BREZY and CMK, will encounter weather extending to 32,000 feet in N90 if it departs in the time interval beginning at 1935 or 1940. This does not necessarily mean that the weather will be present in N90 at 1935, rather that it will impact flights taking off at 1935 and utilizing the given route.

The second (flight) grid shows the flight-by-flight information. The TMC can click on any departure route or group of routes to bring up a list of aircraft filed on the route(s). Similarly to the route grid, the user can sort the aircraft list by any

3.E.3-6

of the flight features (ACID, departure fix, jet route, origin, destination, departure time, or queue on the runway, etc). Like the route grid, the status for each departure time for each flight is indicated.

The third (options) grid provides the available reroute options for one or a group of aircraft. For example, in Figure 3 the TMC has selected COA570 to view its available reroute options. It is not encountering weather on the filed route (all cells are green), but in this hypothetical example, the flight is being rerouted for a traffic congestion problem on the filed route. Two alternate routes are shown, titled EWRYYZCA and EWRYYZPT, with the weather blockage status indicated for each. It is envisioned that the route options will be pulled from existing databases such as Coded Departure Routes (CDRs), or may be submitted by customers as their preferred alternate as described in [3]. Other useful data is also available to be shown on the reroute option grid, including the coordination needs for that route (i.e., which facilities would need to be coordinated with in order to implement the route) and the extra flying time and distance that would be added by the route.

Subject Matter Expert Feedback Sessions

In order to refine the operational concept and determine the usefulness of specific capabilities, feedback sessions were conducted with four Subject Matter Experts (SMEs), with one SME participating in each session. All were former TMCs with recent experience in Systems Engineering and development of operational concepts for TFM and other areas of Air Traffic Management (ATM).

Methodology In each session, the TMC was given an update

on the IDRP operational concept and user interfaces (all had some prior familiarity with IDRP). A storyboard was presented in briefing form showing the current concept for how the IDRP capabilities would be used in an operational situation. The example used depicted convective weather affecting departure routes west of New York, with the weather predicted to first block one major departure route and then move to block another route. Screen shots from the prototype and mockups were used to illustrate the capabilities and how they would be

used using today’s tools and procedures, and using IDRP. The scenario was presented in several stages (e.g., monitor situation, identify problem, prioritize flights, evaluate solutions and select a solution) which were based on an earlier task analysis of departure route planning conducted with the input of some of the same operational personnel who participated in the feedback session.

A semi-structured interview protocol was used as the storyboard was presented, where the TMC was asked predefined open-ended questions at specified points in the briefing. In addition, questions and comments were taken at any time during the briefing, and a discussion period followed the briefing. Comments were recorded during the interviews and later categorized. In general, the concept and capabilities were well received by the SMEs. Specific issues discussed included procedures, timing, location-specific applications, benefits, and information requirements.

Procedural Issues Naturally, it will be necessary as the concept

matures to refine the definition of operational procedures for use of IDRP. The SME feedback was useful to help identify specific procedural issues that need to be addressed in order to mature the concept. For example, it was indicated during the interviews that the IDRP capabilities can provide an indication of situations that need to be dealt with, but that they will not totally replace human judgment and that therefore, specific procedures must be developed for dealing with various weather and traffic alerts. For example, the procedures that must be followed might be different for weather alerts, traffic alerts, and weather-plus-traffic alerts, as well as for alerts of varying severity. In addition, some operational situations may call for disabling particular alerted conditions that TMCs are aware of and have determined to be acceptable. Particular attention must be paid to defining intra- and interfacility coordination procedures for various situations. At the same time, it was stated by operational personnel that decisions regarding which solution to implement are sometimes too dependent on how much coordination is required. It may be useful to explore how the IDRP concept and capabilities can

3.E.3-7

be designed to help TMCs to use more appropriate factors in selecting a reroute option, rather than being overly biased toward the solution requiring the least coordination.

Also regarding procedures and the general development of the concept of operations for IDRP, it was noted that it is important to consider the likelihood of a future decrease in the average TFM experience of TMCs. This has implications for the level of automation the tools may be required to have, and the types of information that will be important to present. For example, the excess flying time added by a potential reroute may not be critical for a TMC who has years of experience in his/her airspace and knows the relative lengths of different reroute options, but in the future it may become more useful to display this data to benefit less experienced personnel.

Timing Issues Regarding timing, there is an issue about when

flights should first appear in the list. One SME believed it would be very beneficial for flights to appear on the IDRP display at pushback time or a few minutes before, but that if they appeared when their departure status and time were still too uncertain (e.g., before the aircraft had even arrived from its previous leg), the result might be overcontrol in the form of needlessly delaying other flights.

Usage in Various Facilities Because the SMEs participating in the sessions

had experience in a variety of geographical locations and were familiar with operations in multiple ATM domains (e.g., tower and center), it was possible to obtain feedback to mature the operational concept for IDRP in multiple locations (e.g., domains/types of facilities, geographical locations), as discussed earlier. SME feedback indicates that, in the tower, IDRP could support appropriate sequencing of the departure queue, and help identify potential pathfinders, flights that take off and fly near a weather-impacted area to report whether the situation has improved. In addition, it would be useful for tower TMCs to see flight status (e.g., whether flights have pushed back). On the other hand, ARTCC personnel might be more concerned about maintaining the broader picture

including impacts to sectors, while still being able to view data that would support decisions regarding finer-tuned initiatives, perhaps allowing one or a few flights to depart on a route that had a small amount of remaining capacity. This is slightly different from the initial concept of operations, which assumed that the center TMCs would not be concerned with individual flights. Another capability that might be useful for the ARTCC is monitoring whether assigned reroutes had yet been implemented. A related function deemed useful is an indication of which aircraft that require action have already been acted upon.

It was noted that both tower and ARTCC could use the capabilities to assist in call-for-release applications, where the tower calls the center for release of a flight into a congested overhead stream.

In addition to the type of facility, the application of the IDRP capabilities would vary from facility to facility. For example, Phoenix Sky Harbor Airport (PHX) is different from New York in that thunderstorms are infrequent—therefore TMCs have less experience at dealing with them and airlines are less likely to add extra fuel for weather-related reroutes—but develop suddenly and move rapidly, thus increasing their impact when they do happen. These factors in conjunction with the limited surface space at PHX make departure management assistance important, especially during severe weather. The call-for-release operation at PHX, where interfacility telephone coordination is conducted to approve take-off for flights departing into the overhead stream from the east coast of the US to southern California, would benefit a great deal from IDRP. For this operational application, IDRP would support delay versus reroute decisions and help tower personnel to line up the departure queue to balance workload for the TRACON and en route center.

Specific operational situations were also identified where IDRP could be applied at Hartsfield Atlanta International Airport, such as rerouting single or small numbers of flights filed to depart to the east, including international flights, to use the north route when the east is affected by congestion and/or weather. It is apparent that, though it grows out of the RAPT work designed to be applied in New York airspace, IDRP has the potential to be useful in many different locations.

3.E.3-8

Benefits In addition to the RAPT benefits identified in

[2], specific benefits that could be achieved using the IDRP functions were identified during the interviews. One benefit is simply the availability of more information. For example, one TMC noted that the flight-by-flight grid indicates exactly which aircraft are going to be impacted by a weather and/or congestion situation, and makes it easier to identify specifics such as how many flights can be moved and to where.

In addition, the grids permit easy and quick detection of problem areas. That is, a “sea” of a “bad color” provides a general picture of the problem and potential solution(s). It was noted, though, that a very small (e.g., 5-minute) “green” window is not useful, because it is generally not possible or worthwhile to construct a detailed plan affecting many flights, merely to ensure that a given flight or a few flights can depart during the one small feasible timeframe. Another stated benefit of IDRP is that it will help with predictability; this is useful not only for TFM personnel but also for airlines and other airspace customers, by giving them better knowledge about when their flights are likely to be able to depart and what their route options are. It was noted that this may be especially important in “now or never” situations where a flight that does not depart immediately on its filed route will face delays or reroutes from developing/approaching congestion or weather. The predictability improvements due to IDRP will also be useful for exiting from a weather/congestion mitigation strategy, by giving more fine-tuned information about when the situation will improve.

Information Requirements Regarding information requirements, a number

of comments were received about both general issues and specific data items and presentation methods that could enhance the utility of IDRP. One important point is that weather/congestion problems do not call only for longitudinal (i.e., delay) and lateral (reroute) solutions, but also vertical solutions. Operationally, flights are often subjected to capping and tunneling, in which they fly at a lower altitude than originally filed for all or part of their flight. Also, in some situations, certain flights can fly higher than their filed altitude to go

over the top of a congested sector or a weather cell (though not usually over thunderstorms). If IDRP can model these types of solutions, its usefulness will be increased. In order to model altitude-based solutions, especially those involving flying higher than planned, it would be useful to present rate of climb and/or aircraft type data to the TMC, and/or use it in the modeling algorithms, to ensure the planned altitude change was feasible. It will also be important to display the nature of depicted weather cells (e.g., whether the cell is a thunderstorm or not) to support TMC and customer decisions regarding altitude-based solutions and to improve overall awareness.

It was also deemed that a “what if” capability to show impact of group reroutes on sector congestion would be useful. This would include “what if” functions not only for reroutes but also for re-ordering the surface queue. It was suggested during the feedback sessions that these capabilities offer more benefit than the less-automated approach of showing the traffic volume and/or available capacity and requiring the TMC to decide what to do about it.

When determining which reroute option to implement, it would be useful to allow the TMC to specify the criteria for the reroute options, and only show the options satisfying the criteria entered. If no option meeting all criteria were available, the next best one could be shown; the definition of “next best” is to be determined by future work.

It would also be useful to allow greater tailoring of the alerting by the user, as some TMCs may only be concerned with weather and congestion effects on fixes, some may be concerned only with routes, and so forth. In addition, the TMC might only wish to monitor specific fixes, sectors, routes, and/or groups thereof. The specific NAS resources or resource types to monitor should therefore be user selectable, with alerting and the “what-if” function tailored accordingly, both on the grids and on the Situation Display.

Furthermore, indications could be displayed on each field of the grids shown in Figure 3 to provide a more detailed picture of the nature of the problem. For example, when a tactical situation (e.g., gridlock, excess taxi time) exists at the departure airport, the Origin (airport) field could be augmented with an indication, perhaps a warning

3.E.3-9

icon that could be clicked to bring up detailed data. It was noted that this would improve awareness especially in multiple-airport regions such as New York. Similar indications could be provided for fields like Departure Fix (e.g., when a traffic management initiative such as an MIT restriction is in effect at that fix) and Route (for example, when the responsible TFM unit declares a route completely closed to traffic).

Some information will be more useful at certain facilities and facility types. For towers and perhaps TRACONs, knowing the planned departure runway would assist personnel with planning the surface movement and the traffic patterns immediately following departure, as would indication of which terminal each flight was going to be taxiing from. Awareness of the surface situation would also be enhanced by presentation of departure queue order, so that the TMC could know when aircraft are taxiing and in which order they are lined up for departure. For the ARTCC, the time at which each flight is projected to reach the departure fix would assist with traffic planning.

User interface issues were not the focus of the study, but some important higher-level ones that were identified during the sessions are mentioned here. There is an ongoing question of whether to simultaneously represent weather and traffic problems. The concept of integrating traffic and weather information in one grid was generally positively received, but the proper user interface to present this information has yet to be determined. TFM personnel are accustomed to using color coding for both of these factors. However, if it was desired to simultaneously present the weather and traffic status for flights or routes in Figure 3, then using color coding for both factors could result in information overload and confusion, regardless of whether the same or different color schemes were used. One solution that has been proposed and was used in the mockups presented to the SMEs was to use a hatching pattern in the grid cell for one of the factors (traffic in this case, though it would not necessarily be implemented that way) and color coding for the other (weather). However, comments were received that, especially when viewed from a distance or quickly, the hatching might look like a darker version of the cell color rather than two integrated pieces of information, and be misinterpreted.

Future Work Continuation of the laboratory-based

operational evaluation work is planned for IDRP, in order to further refine the capabilities and concept of use. The interview/briefing method will continue to be used, coupled with human-in-the-loop simulation activity using structured scenarios and direct SME interaction with the prototype. Issues of focus in the near term include the reroute options capabilities depicted in the bottom grid of Figure 3. These will be investigated by attempting to capture the decision-making rules and strategies used by TMCs, and other stakeholders such as airline dispatchers and other NAS customers, for selecting and ranking reroutes. If rules can be adequately captured in an algorithm, it may be possible to implement a route ranking function that would present TMCs with the most recommended reroute option(s) for a given flight or flights, to save the workload of comparing the various routes on different criteria, while still allowing the final decision to be made by the stakeholders. Laboratory work using interviews, prototypes, mockups, and cognitive task analysis will further address this issue and other information requirement and user interface issues discussed earlier.

In addition, shadow mode operation at field sites is planned for the near future, similar to the work with RAPT described in [2]. Once all important RAPT capabilities are successfully integrated with the new ones added by IDRP—and the majority of this has been accomplished already in the existing prototype—the updated prototype will be implemented at the New York area sites where RAPT is currently installed. The prototype may be implemented along with RAPT at other facilities as well in order to continue the work of developing the operational concept for use in different TFM domains and geographical locations. The field prototype will be equipped with capabilities to capture usage metrics in order to assess when the capabilities would be used in live operations and which functions would be most used.

Other conceptual work will further explore the capabilities that will need to be integrated with IDRP. These include surface management tools and en route automation, including the En route

3.E.3-10

Flow Planning Tool (EFPT) capabilities currently being researched at MITRE. EFPT provides route blockage and congestion information analogous to that given by IDRP, for the en route domain [4]. An open question is whether integrated arrival-departure management is within the eventual scope of IDRP, or whether the IDRP toolset should remain focused on departures, and integrate/ interface with arrival management capabilities at a higher level. Another conceptual issue to be researched is how to conduct tasks such as reroute distribution and coordination [3] in a more automated fashion than today. Making coordination on departure rerouting more automated, or at least electronic rather than telephone-based or face-to-face, may reduce the importance of some of the coordination issues mentioned earlier in this paper.

As noted earlier, the uncertainty associated with departure planning is an important research area. It will be necessary to quantify the uncertainty inherent in predictions of departure timing and weather impacts, and assess the implications for decision making. The presentation of probabilistic predictions to the user, and the development of operational procedures for uncertain situations, also require further study.

Finally, human factors research is needed to develop a better understanding of how IDRP can be applied to departure management decision making. Areas for investigation include the identification of the most critical departure management information from IDRP, the definition of the scope of the planning horizon, the development and incorporation of models for decision making in the face of uncertainty, the evolution of new operational procedures that are enabled by IDRP and the design of effective user interfaces to support coordinated decision making.

In closing, the IDRP capabilities have already shown promise based on initial work in New York [2] and the discussions growing out of this, and based on the initial SME evaluations, discussed in this paper, of the capabilities that IDRP adds to the existing RAPT toolset. As the concept matures and the IDRP prototype gains field exposure, the improvements to departure management will benefit TFM personnel, ATC personnel, and NAS customers alike.

References [1] DeLaura, Rich, Michael Robinson, Russell Todd, Kirk MacKenzie, “Evaluation of Weather Impact Models in Departure Management Decision Support: Operational Performance of the Route Availability Planning Tool (RAPT) Prototype,” 13th Conference on Aviation, Range and Aerospace Meteorology, 20-24 January 2008, New Orleans, LA, American Meteorological Society, Boston, MA.

[2] Robinson, Michael, Rich DeLaura, James Evans, Starr McGettigan, “Operational Usage of the Route Availability Planning Tool During the 2007 Convective Season,” 13th Conference on Aviation, Range and Aerospace Meteorology, 20-24 January 2008, New Orleans, LA, American Meteorological Society, Boston, MA.

[3] Fellman, Lynne, Tejal Topiwala, “ARTCC-Initiated Rerouting,” Proceedings of the 6th AIAA Aviation, Integration, and Operations Conference, 25-27 September 2006, Wichita, KS, AIAA 2006-7829, American Institute of Aeronautics and Astronautics (AIAA), Reston, VA.

[4] Rhodes, Laurel S., Gretchen J. Jacobs, Evaluation Results of Near-Term Congestion Management Capabilities, Doc. No. MP070214, September 2007, The MITRE Corporation, McLean, VA.

Acknowledgements The authors would like to thank Daniel

Greenbaum, David Hechtman, Timothy Stewart, and Aaron Weikle for software development efforts on the IDRP prototype; Charlie Bailey, Maurice Howland, L. Michael Klinker and Dennis Poore for input to the IDRP operational concept and/or prototype design; and Claude Jackson for project management and operational concept input.

Disclaimer The contents of this material reflect the views

of the author and/or the Director of the Center for Advanced Aviation System Development. Neither the Federal Aviation Administration nor the Department of Transportation makes any warranty or guarantee, or promise, expressed or implied, concerning the content or accuracy of the views expressed.

3.E.3-11

3.E.3-12

Email Addresses Anthony Masalonis, tonym@mitre.org

Hilton Bateman, hbateman@mitre.org

Lixia Song, lixia@mitre.org

Norma Taber, njtaber@mitre.org

Craig Wanke, cwanke@mitre.org

Rich DeLaura, richd@ll.mit.edu.

27th Digital Avionics Systems Conference

October 26-30, 2008