**En route Descent Advisor (EDA)**

# General Description {#general-description .unnumbered}

# January 31, 2002 {#january-31-2002 .unnumbered}

# NAS2-98005 {#nas2-98005 .unnumbered}

# Technical Research in Advanced Air Transportation Technologies {#technical-research-in-advanced-air-transportation-technologies .unnumbered}

Final

General Description

En route Descent Advisor (EDA)

CDRL Item 5e

# Prepared under {#prepared-under .unnumbered}

# RTO - 62 {#rto---62 .unnumbered}

# AATT Operational Concept for ATM -- Year 2002 Update {#aatt-operational-concept-for-atm-year-2002-update .unnumbered}

#### January 31, 2002 {#january-31-2002-1 .unnumbered}

#### Prepared For: NASA Ames Research Center {#prepared-for-nasa-ames-research-center .unnumbered}

#### Moffett Field, CA 94035-1000 {#moffett-field-ca-94035-1000 .unnumbered}

#### Prepared By: Titan Systems Corporation -- SRC Division {#prepared-by-titan-systems-corporation-src-division .unnumbered}

#### Billerica, MA 01821-4134 {#billerica-ma-01821-4134 .unnumbered}

![](media/image1.jpeg){width="5.416666666666667in" height="0.75in"}

**PREFACE**

The purpose of this document, and of the descriptions of the other AATT
decision support tools (DST), is to provide a current description of the
tools in a consistent format for the AATT Project Office, the tools
developers, the NASA AATT contractors, the FAA, and other interested
parties. The objective is to document available information, not to
invent new information.

**ACKNOWLEDGEMENT**

The descriptions presented in this document have been taken directly
from NASA documents shown in the bibliography. More specifically the
operational concept has been directly taken from the recent paper*,
Green, S.M., and Vivona, R. A., \"En Route Descent Advisor Concept For
Arrival Metering" AIAA 2001-4114.* The En route Descent Advisor (EDA)
functional flow chart and functional description have been extracted
from the *EDA Build 3 System Specification, System Resources
Corporation, RTO #45, December 29, 2001*. Minor modifications have been
made to the text to provide readability.

This approach to the development of this document was taken in order to
remain faithful to the efforts that are presently being undertaken by
the NASA AATT Project Office, the EDA tool developers and the associated
NASA AATT contractors.

Special thanks go to Steve Green of NASA Ames Research Center and to
Robert Vivona of Titan Systems Corporation for their help in
understanding the EDA concept and their careful review of the drafts of
this document.

**Table of Contents**

1.  **Description 1**

2.  **Operational Concept 2**

**2.1 Transition Airspace Challenges 2**

**2.2 Core EDA Capabilities 5**

3.  **Functional Flow 13**

**3.1 Track Update 13**

**3.2 Controller Input 20**

**3.3 Metering Schedule Update 23**

**List of Figures**

1.  **Conflict Probe Sensitivity to Metering Intent 3**

2.  **Envelope of Possible Trajectories 7**

3.  **Active and Provisional Aircraft Plans 10**

4.  **Provisional Plan Coordination Chart 12**

5.  **EDA Functional Flow Diagram 14**

6.  **Sequential Flow of EDA Functionality for Separation Assurance 15**

7.  **Sequential Flow of EDA Functionality for Flow Conformance 17**

8.  **Sequential Flow of EDA Functionality for Flow with Separation
    Assurance 19**

9.  **Sequential Flow of EDA Functionality for Active Controller Input
    21**

10. **Sequential Flow of EDA Functionality for non-Resolution Mode 21**

11. **Sequential Flow of EDA Functionality for Resolution Mode Change
    22**

12. **Sequential Flow of EDA Functionality for a Scheduling Update 24**

**Appendices**

### A. Bibliography 25  {#a.-bibliography-25 .unnumbered}

##  {#section .unnumbered}

## AATT EN ROUTE DESCENT ADVISOR (EDA) {#aatt-en-route-descent-advisor-eda .unnumbered}

## GENERAL DESCRIPTION {#general-description-1 .unnumbered}

**1. DESCRIPTION**

The En-route Descent Advisor (EDA) is a suite of decision support tool
(DST) capabilities designed to assist controllers to enable
user-preferred metering and separation in the departure, cruise, and
arrival phases of flight. EDA provides fuel-efficient advisories for
flow-rate conformance and integrates those advisories with conflict
detection and resolution (CD&R) capabilities.

Although adaptable to today's ATC procedures and airspace structure, EDA
is designed for the future "Free-Flight-like" environment characterized
by dynamic constraints and minimal route structure. EDA lends itself
well to such environments where it will facilitate the transition of
"random" traffic into an efficient/organized flow at the destination.
EDA capability will facilitate the transition of en route procedures
from today's "sector" orientation to a "trajectory" orientation. A
trajectory orientation is key to enabling Distributed Air-Ground Traffic
Management (DAG-TM) concepts in en route airspace.

The general benefit goals of EDA include:

1)  Increased user flexibility (to operate according to their
    preferences)

2)  Increased controller productivity (provide greater flexibility to
    more flights)

3)  Increased fuel efficiency for operations in the presence of flow
    constraints

4)  Reduced deviations/interruptions due to ATC actions

5)  Increased throughput

The primary EDA attributes for achieving these benefits are as follows:

1)  "Seconds" accuracy in 4D prediction to reduce excess buffers and
    conservative constraints.

2)  "Active" meet-time advisories for fuel-efficient conformance to
    flow-rate constraints (i.e., arrival metering or spacing).

3)  Integration of flow-rate-conformance advisories with CD&R to reduce
    controller workload in the planning, monitoring, and conformance of
    flow-rate restrictions and separation assurance.

In recent years, EDA capabilities have been de-emphasized in order to
emphasize near-term applications including the Conflict Probe and Trial
Planner (CPTP) and Direct-To (D2) capabilities. CPTP and D2 are both EDA
spin-offs designed to manage traffic that is not subject to flow-rate
constraints.

2.  **OPERATIONAL CONCEPT**

The En route Descent Advisor (EDA) concept proposes DST technology to
enable new procedures within en route airspace that support the
transition of arrivals into high-density terminal airspace. EDA fills a
void by providing controllers with automatic advisories for metering
conformance that are integrated with capabilities for conflict detection
and resolution (CD&R). This integrated advisory approach will enable
controllers to efficiently meter flights upstream of congested airspace
while ensuring separation. This description of EDA discusses the
challenges of "transition" airspace, and presents the core EDA
capabilities.

# 2.1 Transition Airspace Challenges {#transition-airspace-challenges .unnumbered}

Transition airspace is defined as en route airspace that transitions
arrivals into the terminal area. In addition to the complex mix of
aircraft types in all three phases of flight (climb, cruise, and
descent), transition airspace typically involves complex traffic
patterns (merging and crossing), and the natural compression of arrival
traffic (descending/decelerating out of cruise). Perhaps the most
complicating aspects of transition airspace are the delays and
trajectory deviations associated with congestion in high-density areas.
Metering restrictions are often imposed in response to dynamic overloads
of airspace/airport capacity. This is important to the users because
these restrictions are a significant cause of trajectory deviations, and
the frequency of their occurrence is growing as airspace and airports
become more congested. To improve the efficiency of transition-airspace
operations, three critical challenges must be addressed: controller
intent, metering conformance, and inter-sector coordination.

## Controller Intent

Accurate knowledge of flight intent (route, speed, and altitude profile)
is commonly considered the most critical component of trajectory
prediction, the cornerstone of DST automation. Except for cases
involving pilot-initiated deviations, intent modeling requires knowledge
of the controller's planned actions. Transition airspace is particularly
challenging due to the high frequency of flight profile changes,
especially during metering/spacing operations.

Even with Free Flight Phase 1 (FFP1) tools, the lack of
metering-conformance intent presents a problem. For the User Request
Evaluation Tool (URET) Conflict Probe (CP), this lack of intent
information introduces trajectory-prediction errors that may lead to
missed alerts and/or false alarms. A metering-conformance action may
actually avoid a conflict, that would otherwise have been predicted,
and/or create an emergent problem that was not originally considered a
factor. Figure 1 illustrates a scenario involving three flights. The
eastbound arrival is transitioning to a congested terminal area and will
be subject to arrival-metering delays. The other two flights represent
crossing traffic that is coincidentally at the same altitude. In this
situation, CP would predict a conflict between the arrival and
overflight-A based on the latest track data and flight-plan information
stored in the ATC Host computer. However, metering delays will result in
a different trajectory for the arrival than predicted by CP automation.
In addition, missed alerts with other traffic may occur because
controllers do not typically amend the Host flight plans[^1] to reflect
these tactical actions.^7,8^ This performance degradation may
significantly reduce the operational usefulness and acceptability of CP
alerts during metering operations, a critical time when such decision
support automation assistance may be needed.

![](media/image2.wmf){width="5.935416666666667in" height="4.0125in"}

**Figure 1. Conflict Probe Sensitivity to Metering Intent.**

##  {#section-1 .unnumbered}

## Metering Conformance

Although current methods for metering conformance vary with controller
experience and technique, metering actions tend to be relatively
tactical in nature with iterative corrections used to achieve
conformance. Vectors are common since the tactical approach leaves
little time or opportunity for speed reductions to be effective.
Although Traffic Management Advisor (TMA) provides en route controllers
with arrival-metering lists including arrival sequence, meter-fix times,
and delay feedback, it does not provide the controller with clearance
advisories to meet the meter-fix times. While the CP trial-planning
function can be used to plan conflict resolutions, the function does not
consider metering conformance in its current operational implementation,
and the manual nature of the trial-planning approach to problem
resolution can be workload intensive if required on a frequent basis.

The tactical nature of current metering-conformance techniques makes it
difficult for DSTs to model and predict controller intent. In addition,
the manual aspect requires a significant amount of work on the
controller's part over and above their nominal duties. Current
procedures only require metering conformance to within approximately 1-2
min per flight.^2^ Even if trial planning was applied to the
metering-conformance problem, this level of uncertainty is problematic
with respect to conflicts in that one minute of time error may exceed
the 5 nm requirement for en route separation resulting in the need for
additional actions to maintain separation between sequential flights.

**2.1.3 Inter-sector Coordination**

Controller procedures have evolved over several decades of radar control
to be highly adaptable and robust to "off-nominal" events such as missed
clearance, pilot deviation, lost communication, and missed coordination
between sectors. The result is an unprecedented level of safety in terms
of aircraft separation. However, given the limitations of 1970's-era
technology and infrastructure, it was necessary for these procedures to
be oriented towards sector airspace. This "sector orientation" is a
natural outcome of the need to clearly delegate ATC
responsibilities/liabilities, expedite traffic through sectors, and
mitigate the risk of inter-sector confusion.

###  {#section-2 .unnumbered}

Today's sector-oriented operations are characterized by the planning and
control of flights within a sector with an emphasis on the expeditious
hand-off to the next sector. Controllers may not allow a flight within
their sector to enter the next sector unless the downstream (receiving)
controller accepts the hand off. Conditions for hand-off acceptance
typically include several factors such as the absence of any immediate
conflicts.

Each sector is managed by a controller team consisting of at least a
radar "R" position, and if workload necessitates, a radar associate "RA"
position. Additional controller "associates" may assist the team during
peak workload situations. In general, radar controllers monitor their
sector, communicate with flights, issue clearances, and take action to
maintain separation and conform to restrictions (e.g., airspace
structure and required metering/spacing). In addition to data management
and flight strip marking, RA positions assist the radar controller with
the monitoring of the traffic situation and pilot "read back" of
clearances to mitigate the risk of blunders. Acting as a "second pair of
eyes/ears" becomes the priority role for the RA position under high
workload conditions.

Tactical separation is the sector team's top priority. Radar controllers
tactically detect and resolve conflicts with a typical look-ahead
horizon of 5-10 min. To complement this, FFP1 automation provides the
RA[^2] position with URET CP capabilities to help monitor traffic,
detect problems (conflicts with other flights or airspace restrictions),
trial plan resolutions, and coordinate resolutions with other sectors.
CP provides the RA position with an upstream look-ahead horizon of 10-20
min that can potentially reduce the traffic problems encountered by the
radar controller.

The advantage of classic sector-oriented procedures is the clear
allocation of responsibility to individual controller positions with
minimal dependence on automation. Although exercised rarely, each sector
has the authority to delay or restrict their acceptance of new hand offs
from upstream sectors. This process allows each individual sector to
limit the scope of the incoming traffic problem. However, a convenient
and expeditious solution from one sector's point of view may not be the
best overall solution for a group of sectors. Sector-oriented procedures
have limited potential to distribute workload and facilitate coordinated
actions across sectors. Sector-oriented procedures do not encourage
upstream controllers to issue clearances that resolve predictable
problems that impact downstream sectors. As a result, subsequent sectors
must often correct their portion of a flight's trajectory, a practice
that often frustrates the user community and contributes to downstream
workload.

Although FFP1 capabilities introduce benefits under today's
sector-oriented paradigm, an even greater potential benefit could be
unlocked by a shift towards a "trajectory-oriented" paradigm facilitated
by new automation. Trajectory orientation is an ATC counterpart to the
natural orientation of the airspace user. Aircraft operators consider
not only the flight's current state and immediate tactical challenges
(e.g., weather and traffic), but also their strategic plan to return to
their route and nominally complete their mission (e.g., required time of
arrival).

Trajectory-oriented operations are characterized by the upstream
planning and coordination of flight-path changes that nominally conform
to downstream metering restrictions and separation minima. Not all
predicted problems need to (or should) be solved upstream, only those
that are highly probable within a reasonable horizon (e.g., 10-20
min).^9^ The goal is to resolve predictable problems earlier, while
finding an efficient balance between acting too soon (false alarm) or
too late (missed alert).

Compared to sector-oriented operations, the trajectory-oriented approach
has the potential to push problem detection/resolution upstream and
redistribute workload from the downstream sectors (where problems are
located) to upstream sectors (that control the flights just upstream of
the problem). This approach has the potential to increase both flight
efficiency and the robustness of individual sectors to disturbances (and
uncertainties) in the traffic flow. Finally, trajectory orientation is
essential for the realization of the Free Flight concept, particularly
the DAG-TM elements such as trajectory negotiation and free maneuvering.
Collaborative trajectory planning will require pilots and controllers to
have a consistent, shared model of intent.

Trajectory orientation necessitates a fundamental shift in thinking
towards multi-sector teamwork. There are several potential operational
concepts for controller roles, responsibilities, and procedures that may
enable a transition to trajectory-oriented operations.[^3] A description
of these potential concepts is provided in Ref. 10. For the purposes of
this paper however, the focus will be on the "Upstream (sector) Team"
concept whereby the radar and radar associate positions leverage DST
capabilities to facilitate trajectory-oriented actions. Providing such
capabilities to the controller team is a fundamental goal of EDA.

2.2 Core EDA Capabilities

To facilitate trajectory-oriented operations, decision support
automation is needed to assist controllers with the inter-sector
planning, coordination, and execution of any necessary flight plan
changes. Manual trial planning techniques are not adequate for
arrival-metering situations.^11^ The EDA solution proposes a higher
level of active-advisory automation based on accurate 4D
trajectory-prediction capability.

Field tests have validated an EDA arrival-time accuracy of 15 sec^12^
based on a single clearance advisory issued prior to top of descent.
Even greater operational accuracy is readily achievable using
mid-descent updates (routinely needed today without automation), and
state-of-the-art capabilities in surveillance, wind prediction,^13^ and
data link. Trajectory prediction accuracy is key to gaining controller
confidence in DST alerts/advisories, extending the effective time
horizon for problem detection, and reducing the need for corrective
clearances to achieve a desired traffic state. In addition, good
precision between airborne Flight Management Systems (FMS) and ATC-DST
trajectory predictions will maximize the potential for DAG-TM concepts
by ensuring the interoperability of air and ground automation.^14,15^
Further details on EDA trajectory-prediction methods and
prediction-accuracy validation results may be found in Ref. 12, 16, and
17.

In addition to accurate 4D trajectory-prediction capability, two core
EDA capabilities have emerged from the lessons learned in previous
controller-in-the-loop simulations in the early 1990's. Although
controllers positively received the EDA metering-conformance advisories,
they emphasized the need for a greater level of conflict-resolution
automation (to reduce the workload associated with manual "trial plan"
methods), and the need for automation support to facilitate coordinated
actions across multiple sectors. The following two sections describe the
formulation of the EDA capabilities to address these controller
concerns. These capabilities include active clearance advisories that
integrate metering conformance with conflict detection and resolution
(CD&R), management of "active" and "provisional" (flight) plans, and the
controller plans necessary to automatically organize and manage "active"
and "provisional" (flight) plans.

**2.2.1 Integration of Metering Conformance and CD&R**

A unique feature of EDA is the capability to generate active clearance
advisories for conflict-free metering conformance (i.e., suggested
instructions for speed, altitude, and route changes). Algorithms for
accurate metering conformance, conflict detection, and conflict
resolution have been developed and integrated within research-prototype
software.^12,18^ This section presents an overview of the conceptual
approach and motivation to the EDA algorithms for arrival-metering
advisories.

Improvements in metering-conformance accuracy (e.g., reductions in error
from 1-2 min^2^ to 15 sec^12^) have the potential to unlock benefits
both downstream and upstream of the meter fix. Downstream of the meter
fix, within terminal airspace, errors of 1-2 min rival the size of the
desired approach spacing and may also exceed the controllable range of
delay for "short side" arrival routes (leading to excessive gaps between
slots). A reduction in meter-fix error may improve the efficiency and
throughput of terminal-arrival operations.

Upstream of the meter fix, improved metering accuracy has the potential
to reduce the frequency and degree of en route conflicts. A key
discriminator of the EDA concept is the sequential approach that
considers metering-conformance solutions first, followed by CD&R
iteration, rather than the other way around. Metering restrictions
impose spacing requirements on sequential flights that at least meet
(and typically exceed) the criteria for minimum radar separation. This
can be particularly advantageous in transition airspace where the
natural merging and compression of arrival traffic leads to a
significantly greater frequency of potential conflicts. With sufficient
accuracy, metering-conformance actions tend to "de-conflict" traffic
within a metered flow. EDA leverages this characteristic to reduce the
number of potential conflicts within a metered arrival stream, using
simple metering-conformance algorithms, before having to resort to more
complex algorithmic techniques for resolution.

Figure 2 illustrates the concept. Consider a single flight that is
subject to a metering restriction and simultaneously predicted to be in
conflict with another flight. Controllers have at their disposal the
ability to modify the flight's route, altitude, and speed profile to
resolve both problems (metering delays and conflicts). The large oval
region notionally depicts the envelope of possible 4D trajectories for
the flight. The slightly smaller hexagonal region (γ) represents the
subset of possible trajectories that are conflict free. The even smaller
triangle (β) represents the subset of trajectories that are in
conformance with the metering constraint. Finally, the small polygon (α)
represents the target envelope of trajectories that simultaneously
conform to all constraints. The relative size of each envelope indicates
the "degree" of that constraint. Most conflicts require only small
deviations for resolution (leaving most of the envelope open).
Comparatively speaking, the metering constraint represents a two-point
boundary value problem that is considerably more constraining.

![](media/image3.wmf){width="6.1819444444444445in"
height="3.759027777777778in"}

**Figure 2. Envelope of Possible Trajectories.**

The goal of conflict-free planning is to find a solution within the
intersection envelope. Although the natural predisposition of
controllers is to address separation first (e.g., region γ), the
potential advantage of first considering metering conformance (e.g.,
region β) is that it significantly reduces the search space for finding
a total solution (region α). For this reason, a
"metering-conformance-first" algorithm was implemented within the EDA
research prototype as the basis for conflict resolution of arrival
traffic.^19^ In addition to the beneficial side effect of reducing
potential conflicts between metered flights, the this algorithm provides
EDA with a powerful approach for gaining controller acceptance of active
advisories.[^4]

**2.2.2 Active/Provisional Planning Concept**

Active advisory tools, such as EDA, must model appropriate controller
options and preferences in order to generate problem-resolution
advisories that are acceptable to controllers. This presents a challenge
in terms of supporting a controller's situational awareness while
striking the right balance between automation alerts (e.g., predicted
conflicts and delays) based on the current traffic state, and alerts
based on potential changes under consideration by one or more
controllers. The basis of such alerts must be absolutely clear to
controllers (i.e., whether the alert is based on current traffic state,
or potential changes). Anything less may result in a lack of situational
awareness leading to unnecessary control actions or problems that go
undetected too long.[^5] Furthermore, the management of flight-plan
intent is an essential element needed to support the multi-sector
coordination of trajectory changes. This is particularly important for
transition airspace, compared to simpler en route airspace, where flight
path changes are the rule, rather than the exception. The EDA approach
to address these challenges is described next in terms of the concept of
"active" and "provisional" planning.

The EDA concept for active and provisional planning was initially
formulated in 1990 as an ATC counterpart to a flight management system
(FMS) concept.^19,22^ In the FMS domain, the "active plan" represents
the mission profile as a series of profile segments and/or waypoints
defined by route, altitude, speed, and/or time constraints. The active
plan drives the FMS trajectory predictions that are used to derive the
flight guidance for lateral, vertical, and time-based navigation. The
FMS also provides the pilot with "provisional-planning" capability. This
capability enables the pilot to assess the implications of an
alternative 4D trajectory while the aircraft remains on the active plan.
Provisional planning allows the pilot to assess plan changes before they
are made "active" for flight guidance.

The EDA concept extends this FMS planning approach to a more complex ATC
application. This complexity stems from the controller's simultaneous
responsibility for many flights and the complex interactions between
flights (particularly within transition airspace). The ATC application
necessitates a distinction between two categories of "plans," namely
aircraft plans, for the modeling the intent of individual flights; and
controller plans, for enhancing controller awareness of any dependencies
between potential sector actions and facilitating the coordinated
resolution of plans that may potentially conflict across sectors.

The success of an active advisory tool depends in large part on the
adequate modeling of flight-plan intent. Intent may be gleaned from the
current ATC Host computer flight plan, radar-track update,
airspace-adaptation data, and heuristic algorithms^20^ used to infer
controller intent when clearances/instructions are not reflected in
official Host flight-plan amendments.[^6] EDA stores such intent
information in a unique "aircraft plan" for each flight. Aircraft plans
form the basis of trajectory predictions for guiding the computational
integration of the aircraft equations of motion. Problem-detection
functions utilize the resulting 4D trajectories to predict downstream
problems such as predicted conflicts or the lack of metering
conformance.

For the purposes of EDA, each flight is represented by an "active
aircraft plan" that is designed to reflect the current ATC intent for
that flight. Active aircraft plans are made available to all sectors to
support a common situational awareness across sectors. Authorization to
modify an active aircraft plan is granted only to the sector that
currently controls the flight.

A "provisional aircraft plan" represents an alternative plan for a
flight that a controller would like to consider as a modification to the
active aircraft plan for that flight. Provisional aircraft plans differ
from active aircraft plans in that any controller may initiate one for a
flight in any sector. Controllers can generate a provisional aircraft
plan manually (i.e., trial plan), or incorporate modifications based on
automated advisories, such as those generated by EDA or the Problem
Analysis Resolution and Ranking (PARR) tool.^23^ This allows individual
sectors to assess a traffic situation (nominally based on the active
aircraft plans) and formulate their own preferences for change.

Figure 3 illustrates a simple example based on two flights (A and B), in
separate sectors (1 and 2), that will merge and transition through
Sector 4 to arrive at the meter fix. Although both flights would be
subject to metering delays, this case will focus on the actions of
Sector 1 relative to flight A (the next section will address the
situation involving simultaneous actions across sectors for both
arrivals). The solid lines depict the trajectories that are based on the
active aircraft plans prior to metering conformance. The conflict probe
predicts a loss of separation at the merge point, based on a probe of
the "un-delayed" trajectories (based on the current active aircraft
plans). However, both flights must also be delayed for metering
conformance. In this case, the Sector 1 controller uses the automation
to suggest a provisional aircraft plan for flight A. The automation
feedback indicates the plan, a delay vector to the north, is predicted
to be conflict free (i.e., no alert). If satisfied, the controller may
promote the provisional aircraft plan to active status and issue the
corresponding instructions to the flight.

A far more critical situation exists with respect to multi-sector
interactions when the provisional aircraft plans of one sector interact
or conflict with the provisional aircraft plans of another. Such a
situation is described next to illustrate the concept of "controller
plans."

**2.2.3 Controller Plans**

Controller plans define the set of all aircraft plans that are of
interest to a sector. Controller plans form the basis for automated
alerts (e.g., predicted conflicts and delays) in that they distinguish
between the current "active" traffic state (shared by all sectors), and
an alternate traffic plan that may be considered by an individual
sector. This distinction is critical because controllers (and advisory
algorithms) must consider the potential interaction between the aircraft
plans of multiple flights as well as the implications of potential
changes to those plans. This is particularly relevant when more than one
controller would like to change the active aircraft plan of the same
flight. Controller plans provide the foundation necessary to
automatically organize and manage the potentially overwhelming
combinations of active and provisional aircraft plans.

The "active controller plan," defined as the set of all active aircraft
plans, is shared by all sectors to ensure consistent feedback on
"active" alerts for predicted conflicts and metering conformance.
"Provisional controller plans," on the other hand, are uniquely defined
for each sector, allowing controllers to assess their own alternate
traffic plan separate from the current active controller plan. A
provisional controller plan is defined as the combined set of all
provisional aircraft plans (under consideration by a specific sector)
and the active aircraft plans for all other traffic. The provisional
controller plan drives the "provisional" alerts for each sector (i.e.,
probes of the alternate traffic plan).

![](media/image4.wmf){width="6.184722222222222in"
height="5.093055555555556in"}

**Figure 3. Active and Provisional Aircraft Plans.**

Whereas current operational implementation of trial planning only
supports the analysis (probing) of trial-plan changes for one flight at
a time (per sector), the provisional-controller-planning approach
supports the simultaneously analysis of provisional aircraft plan
trajectories for multiple flights. This allows each sector/controller to
evaluate the impact of plan changes for one flight on the plan changes
for other flights (as well as the active aircraft plans for the
remaining flights). If many flights are being metered, this allows each
sector to consider the interaction of the potential metering-conformance
actions between metered arrivals, and between metered arrivals and other
traffic.

This provisional-controller-planning approach is intended to facilitate,
when needed, multi-sector collaboration of provisional aircraft plans.
If two sectors/controllers are considering separate provisional aircraft
plans for the same flight, either controller may "swap in" the
provisional aircraft plan of the other to enable their automation to
analyze the potential interactions of the aircraft plans reflected in
their provisional controller plan.[^7] This will enable controllers to
leverage their automation to assess traffic impact and collaborate on
traffic solutions before committing to a specific course of action.

The key to managing the potentially overwhelming combination of active
and provisional aircraft plan interactions is the following. The
aircraft plan content of each sector's provisional controller plan must
be uniquely defined for each controller/sector through automation
settings (defining which advisories should be automatically included)
and/or explicit controller inputs. Such inputs would be used to edit
provisional aircraft plans already under consideration, invoke advisory
functions, and/or swap in a different provisional aircraft plan (perhaps
from another sector or pilot). In addition, the role of the DST
automation is to automatically detect "secondary" problems and provide
the controller with adequate cues to maintain situational awareness.
Secondary problems are defined as provisional aircraft plan interactions
that do not warrant alerts, but deserve a warning. In comparison,
"primary problems" are defined here as the problems predicted by the
automation and alerted to the controller (e.g., conflicts and
metering-conformance delays).

For example, Figure 4 illustrates a more complex version of the
situation presented earlier in Figure 3. In this case, the Sector 2
controller actions will be considered relative to their impact on the
other sectors. Picking up from Figure 3, the Sector 1 controller is
still considering a metering-conformance maneuver to the north for
flight A. At the same time, the Sector 2 controller must plan the delay
action for flight B. One option that could be proposed by the
automation, or trial planned by the controller, is to vector flight B to
the east through Sector 3. However, such a plan would automatically
trigger an alert to a potential conflict with the active aircraft plan
for flight C. Alternatively, the Sector 2 controller may consider an
alternate plan involving a delay vector to the south, through Sector 2.
Although this plan is clear of the active aircraft plans for all other
traffic, it would in fact conflict with Sector 1's provisional aircraft
plan for flight A if either sector activated their plan. Although this
sort of secondary interaction would occur rarely in simple en route
airspace, it can occur much more frequently in transition airspace where
a larger portion of the traffic must be delayed for congestion.

The solution proposed here is for the DST to automatically compare the
provisional controller plans across sectors and identify such secondary
interactions. Once identified, the concept calls for the DST to generate
a "coordination alert" to warn each controller that their respective
provisional aircraft plans have a potentially negative interaction.[^8]
Once identified, and alerted, the controllers and/or automation have the
opportunity to develop a coordinated plan.

This conceptual approach to active/provisional controller planning
offers a framework for managing potential flight plan changes that
enables DST automation to identify sector interdependencies. Accurate
knowledge of these interdependencies is needed to maintain inter-sector
situational awareness, reduce the potential for conflicting actions
between sectors, and minimize the effort necessary to coordinate
multi-sector actions. In particular, this planning approach provides a
mechanism by which individual controllers may consider active clearance
advisories, evaluate modifications, and coordinate actions, all while
maintaining a model of intent that is consistent across neighboring
sectors. Although it is anticipated that workload levels will challenge
the feasibility of this concept, further research is planned to develop,
evaluate, and refine the algorithms and automation needed to address
such challenges.

![](media/image5.wmf){width="6.052777777777778in"
height="4.986805555555556in"}

**Figure 4 Provisional Plan Coordination Alert.**

2.  FUNCTIONAL DESCRIPTION

Figure 5 illustrates the relationships between the EDA functions by
using arrows between the function boxes. On each line is the primary
piece of information that causes the inter-relationship between the
functions (e.g., the information one function must provide for the
other). As the EDA design evolves and new functions and relationships
are defined, more boxes and arrows will be added to diagram.

Execution of the EDA functions as shown in Figure 5 are illustrated by
describing the various use cases for the system. A use case illustrates
the order in which functions are executed based on system events. The
use cases for EDA are broken up into three main categories: Track
Update, Controller Input, and Metering Schedule Update. Each of these
events causes EDA to update its predictions and advisories.

1.  Track Update

When a track update is received by EDA from the Host Computer, all
trajectory prediction and EDA functionality (e.g., separation assurance,
flow conformance) are updated. This is the "basic cycle" of EDA, and
will be described in three sub-cases:

-   Separation Assurance (No Flow Conformance)

-   Flow Conformance (Conflict Detection Only)

-   Flow Conformance with Separation Assurance (Conflict Detection and
    Resolution)

    1.  Separation Assurance (No Flow Conformance)

The first use case illustrates the sequential flow of the EDA system
functions for separation assurance for aircraft without flow conformance
constraints (see Figure 6).

As shown in Figure 6, the EDA system is invoked by reception of new
track data from the Host Computer. This event results in the need to
update both the active and provisional plan trajectories. This is the
first action performed in Figure 6 and is executed by *Active Trajectory
Generation* and *Provisional Trajectory Generation*.

*Active Trajectory Generation* uses the new track, flight plan, and any
active inputs to generate lateral and vertical path constraints, which
are passed to *Trajectory Generation.* *Trajectory Generation* returns a
linearly interpolatable trajectory back to *Active Trajectory
Generation*. Similarly, *Provisional Trajectory Generation* uses the new
track, flight plan, and any active and provisional inputs to generate
lateral and vertical path constraints, which are passed to *Trajectory
Generation,* and receives back a linearly interpolatable trajectory.
Next, all active and provisional plan trajectories received by *Conflict
Detection* are probed for conflicts with all other active and
provisional trajectories in the system. If no conflicts are found, the
system is finished performing all necessary tasks required for
separation assurance; no advisories are sent to the controller.

![](media/image6.wmf)

**Figure 5. EDA Functional Flow Diagram**

![](media/image7.wmf){width="5.998611111111111in"
height="8.755555555555556in"}**Figure 6. Sequential Flow of EDA
Functionality for Separation Assurance (No Flow Conformance)**

If at least one conflict has been detected, the active conflict list and
provisional conflict list are passed to *Conflict Resolution*. *Conflict
Resolution* cycles through all resolvable conflicts and determines
solutions for each conflict in the Resolution Conflict List (RCL). As
described earlier, *Conflict Resolution* may determine that no
resolution maneuver is possible and at other times may create new
resolution maneuvers by passing DOF values to *Trajectory Generation*,
which returns linearly interpolatable trajectories back to *Conflict
Resolution*. *Conflict Resolution* passes these resolution trajectories
to *Conflict Detection* where they are probed for conflicts. The
conflict status for these trajectories (i.e., whether they were conflict
free or not) is passed back to *Conflict Resolution*. *Conflict
Resolution* determines if it has finished searching for resolution
maneuvers because either all conflicts have been resolved or all Degrees
of Freedom (DOFs) maxed out. If the search is not finished the *Conflict
Resolution/Trajectory Generation/Conflict Detection* cycle is repeated.
If the search is complete, *Extract Advisories* is executed. This
function obtains all ACL/PCL conflict advisories and their corresponding
maneuver advisories. This information is passed on to the *Controller
Interface* where the data is prepared and formatted for display to the
controller.

2.  Flow Conformance (Conflict Detection Only)

Figure 7 illustrates the sequential flow of the EDA system functions for
flow conformance without automatic conflict resolution (i.e., conflict
detection only). The system is invoked by the reception of new track
data from the Host.

The first actions performed under this use case are for *Active
Trajectory Generation* and *Provisional Trajectory Generation* to use
the track/flight plan data to build active and provisional plan
trajectories with *Trajectory Generation* (as in the previous use case).
The provisional plan trajectories generated in *Provisional Trajectory
Generation* are for non-flow constrained aircraft only (flow conformance
aircraft are covered next). As in the previous use case, the active and
provisional plan trajectories are sent to *Conflict Detection* for
probing (probing does not occur until provisional plan trajectories for
flow constrained aircraft are created, as described next). The active
plan trajectories from *Active Trajectory Generation* are also passed to
*Metering Conformance*. *Metering Conformance* determines whether or not
each active trajectory is conformant with its metering constraint (e.g.,
a metered aircraft's active plan trajectory has no remaining delay to
absorb to meet its STA). Active trajectory flow conformance information
(e.g., delay) is passed from *Metering Conformance* to *Extract
Advisories* as shown in Figure 7. All active trajectories that are not
flow conformant are then passed on to *Build Metering Trajectories*. For
each aircraft, *Build Metering Trajectories* determines allowable flow
conformant degree of freedom values and adds these flow conformance
trajectory modifications to existing track, flight plan, active input
and provisional input data to generate new lateral and vertical
constraints for a flow conformant provisional plan trajectory. *Build
Metering Trajectories* passes these values on to *Trajectory
Generation*, which returns a linearly interpolatable trajectory. This
trajectory is passed on to *Metering Conformance*, which determines if
the metering constraints are now met, and then passes any remaining
delay on to *Build Metering Trajectories*. If the solution is not flow
conformant the process is repeated again until a flow conformant
solution is obtained or *Build Metering Trajectories* determines that a
solution cannot be found (e.g., due to controller imposed constraints in
flow conformance DOFs). Once *Build Metering Trajectories* has finished,
all provisional plan trajectories for the flow-constrained aircraft are
passed to *Conflict Detection.*

![](media/image8.wmf){width="6.0in" height="7.420138888888889in"}

**Figure 7. Sequential Flow of EDA Functionality for Flow Conformance
Without Automatic Conflict Resolution**

When *Conflict Detection* receives all active and provisional plan
trajectories, they are probed for conflicts. All active and provisional
conflict information is then sent to *Extract Advisories*, which in turn
passes this information along to the *Controller Interface* for display.
Along the same path between *Conflict Detection* and *Extract
Advisories*, provisional flow conformance information (e.g., delays for
metered aircraft with provisional plan flow conformance trajectories)
and flow conformance advisory information (e.g., cruise speed) is passed
on to *Extract Advisories* (recall that active flow conformance advisory
information was sent directly from *Metering Conformance*).

3.  Flow Conformance With Separation Assurance (Conflict Detection and
    Resolution)

Figure 8 illustrates the sequential flow of the EDA system functions for
flow conformance with separation assurance. The system is invoked by the
reception of new track data from the Host as described in Section 3.1.1.
This use case begins with the exact same processing as described in the
previous use case (see Section 3.1.2). After all of the active and
provisional (flow conformance and non-flow conformance) plan
trajectories are received and probed by *Conflict Detection*, the ACL
and PCL are sent to *Conflict Resolution*. All provisional plan
trajectories that are conflict free or for which resolution advisory
generation is not to be performed are passed directly to *Extract
Advisories* as shown in Figure 8. The information passed along this path
consists of 1) provisional flow conformance (e.g., delay) for all
conflict free aircraft and 2) provisional flow conformance advisories
(e.g., cruise speed) for all conflict free aircraft. Conflict free
aircraft are defined as aircraft that are not in the ACL or PCL.

All ACL and PCL trajectories are passed from *Conflict Detection* to
*Conflict Resolution*. For all aircraft without flow conformance
constraints or for aircraft where flow conformance advisory generation
is over-ridden by conflict resolution advisory generation, *Conflict
Resolution* determines the resolution DOFs and their respective values
and iterates with *Trajectory Generation* and *Conflict Detection* to
resolve the conflict (see the first use case, Section 3.1.1, for
description of resolution for aircraft without flow conformance).

For aircraft with flow conformance constraints, *Conflict Resolution*
determines the DOFs to be used for conflict resolution and flow
conformance and calculates the DOF values for the conflict resolution
DOFs. This information is passed on to *Build Metering Trajectories*,
which selects the value for the flow conformance DOF(s). All DOF values
for both resolution and flow conformance and track, flight plan, active
input and provisional input data are used to generate lateral and
vertical constraints for the aircraft. This data is passed on to
*Trajectory Generation*, which builds a linearly interpolatable
trajectory and returns it to *Build Metering Trajectories*. *Build
Metering Trajectories* passes this trajectory to *Metering Conformance*,
which determines if the trajectory is flow conformant. If the trajectory
is not flow conformant *Build Metering Trajectories* determines a new
flow conformance DOF value and the process is repeated until a flow
conformant trajectory is found or the flow conformance DOF maxes
out[^9]. If a flow conformant trajectory is found, *Build Metering
Trajectories* returns this trajectory to *Conflict Resolution*.
*Conflict Resolution* passes this trajectory to *Conflict Detection*
where it is probed for conflicts. If the trajectory is not conflict
free, *Conflict Resolution* determines new resolution DOFs and/or DOF
values and/or new flow conformance DOFs. Conflict Resolution finishes
once all conflicts have been solved or all DOF possibilities exhausted.

![](media/image9.wmf){width="5.995833333333334in"
height="7.429166666666666in"}

**Figure 8. Sequential Flow of EDA Functionality for Flow with
Separation Assurance**

Once *Conflict Resolution* has completed all required actions, the
following information is sent from *Conflict Resolution* to *Extract
Advisories*: 1) ACL and PCL advisories for all conflicting aircraft, 2)
Provisional flow conformance for all conflicting aircraft (e.g., delay),
and 3) Provisional flow conformance advisories for all conflicting
aircraft (e.g., cruise speed). *Extract Advisories* passes all required
information on to the *Controller Interface*, which prepares and formats
the data for display to the controller.

1.  Controller Input

When a controller input, either active or provisional, is received by
EDA in between track updates, EDA must immediately calculate new
trajectory predictions and advisories based on the input without waiting
for a new track update.

1.  Active Controller Input

Figure 9 illustrates the sequential flow of the EDA system functions
when an active input is entered by the controller.

The first action performed by the system when the controller enters an
active input is the building of a new active plan trajectory for the
impacted aircraft by *Active Trajectory Generation*. If the aircraft
also has provisional inputs and no metering constraint, then
*Provisional Trajectory Generation* builds a new provisional plan
trajectory. If the aircraft has a metering constraint, then the active
plan trajectory is sent to *Metering Conformance* to see if *Build
Metering Trajectories* needs to develop a new provisional plan flow
conformance trajectory. Once a new active plan and provisional plan (if
provisional inputs or metering constraint) trajectory is built, all
actions performed by the system are the same as for those described for
Figure 8 in Section 3.1.3, the only difference being that the process
here is performed for only one aircraft.

2.  Provisional Controller Input

Figure 10 and 11 illustrate the sequential flow of the EDA system
functions when a provisional input is entered by the controller. There
are two sub-cases for provisional plan inputs:

1.  Provisional constraints placed on aircraft with/without flow
    conformance constraints or a Flow Conformance (advisory generation
    or DOF selection) mode change to an aircraft with flow conformance
    constraints.

2.  A Conflict Resolution (advisory generation or DOF selection) mode
    change to an aircraft.

Figure 10 illustrates the sequential flow of the EDA system functions
for a non-resolution mode change provisional input for an aircraft
with/without flow conformance constraints.

If the provisional input is for a non-flow constrained aircraft, the
aircraft's provisional plan trajectory is updated by *Provisional
Trajectory Generation* and sent to *Conflict Detection* for probing. The
rest of this use case follows the use case description in Section 3.1.3,
the only difference being that the process here is performed for only
one aircraft.

![](media/image10.wmf){width="5.995138888888889in"
height="3.948611111111111in"}**Figure 9. Sequential flow of EDA
functionality for active controller input**

![](media/image11.wmf){width="5.995138888888889in"
height="3.3333333333333335in"}**Figure 10. Sequential Flow of EDA
Functionality for Non-Resolution Mode Provisional Input**

![](media/image12.wmf){width="6.0in"
height="8.306944444444444in"}**Figure 11. Sequential Flow of EDA
Functionality for Resolution Mode Change**

If the provisional input is for an aircraft with a flow conformance
constraint, *Build Metering Trajectories* builds the new flow
conformance provisional plan trajectory, iterating with *Metering
Conformance* and *Trajectory Generation* as necessary. The rest of this
use case follows the use case description in Section 3.1.3, the only
difference being that the process here is performed for only one
aircraft.

Figure 11 illustrates the sequential flow of the EDA system functions
for a resolution mode change provisional input for an aircraft.
Execution for this event requires that PCL information prior to the
original operation of *Conflict Resolution* is stored in memory. This
PCL information represents the original provisional information for a
track update, flight update, or controller input (active or provisional)
prior to execution of *Conflict Resolution* during the last track
update. This information needs to be stored so that if a resolution mode
is changed by the controller, the resolution algorithm begins its search
for a solution using this initial data.

If the algorithm has the original (pre-resolution) PCL and the updated
resolution mode for the aircraft, iteration to resolve the conflict can
begin. If the aircraft has a flow conformance constraint, the iteration
between *Conflict Resolution* and *Build Metering Trajectories* is
performed. If no flow conformance constraint exists, then iteration
occurs between *Conflict Resolution* and *Trajectory Generation*. The
rest of this use case follows the use case description in Section 3.1.3;
the only difference being that the process here is performed for only
one aircraft.

1.  Metering Schedule Update

When a new list of STAs is received by EDA from TMA, EDA must
immediately update the metering conformance and metering advisories for
aircraft whose STAs have changed, without waiting until the next
track/flight plan update.

Figure 12 illustrates the sequential flow of the EDA system functions
when a scheduling update occurs. The first action is reception of the
new metering restrictions, which are passed from the TMA to *Assign
STAs*. *Assign STAs* assigns the scheduled time of arrival for each
aircraft and passes this information on to *Build Metering
Trajectories*. *Build Metering Trajectories* creates flow conformant
trajectories for each via the *Build Metering Trajectories/Trajectory
Generation/Metering Conformance* iteration process discussed previously.
Once flow conformant trajectories are built, they are passed to
*Conflict Detection* where they are probed for conflicts. The rest of
this use case follows the same process as in Section 3.2.2 for
provisional input changes to the provisional plan flow conformance
trajectory.

![](media/image13.wmf){width="6.0in" height="8.88888888888889in"}Figure
12. Sequential Flow of EDA Functionality for a Scheduling Update

**APPENDIX A. BIBLIOGRAPHY**

1.  Final Report of the RTCA Task Force 3, "Free Flight Implementation,"
    RTCA Inc., Washington D.C., October 26, 1995.
    [www.RTCA.org](http://www.RTCA.org/)

2.  **Swenson, H., et al,** "Design & Operational Evaluation of the
    Traffic Management Advisor at the Fort Worth Air Route Traffic
    Control Center," 1st USA / Europe Air Traffic Management R&D
    Seminar, Saclay, France, June 1997.

3.  **Brudnicki, D., and McFarland, A.,** \"User Request Evaluation Tool
    (URET) Conflict Probe Performance and Benefits Assessment,\" 1st
    USA/Europe Air Traffic Management R&D Seminar, Saclay, France, June
    1997, MP97W112.

4.  **Erzberger, H., Davis, T., and Green, S.,** \"Design of
    Center-TRACON Automation System,\" AGARD Guidance and Control
    Symposium on Machine Intelligence in Air Traffic Management, Berlin,
    Germany, May 1993. pp. 11-1-11-12.

5.  **Green, S. M. and Jackson, J.W**., "Complexity in Air Traffic
    Management," *Automation, Control and Complexity*, edited by
    Samad T. and Weyrauch, New York: John Wiley & Sons, 2000.

6.  **Green, S., Bilimoria, K., and Ballin, M. G.,** "Distributed
    Air-Ground Traffic Management for En route Flight Operations," AIAA
    2000-4064, Guidance, Navigation, and Control Conference, Denver CO,
    August 2000.

7.  **Arthur, W. C., Lindsay, K. S.,** September 1999, User Request
    Evaluation Tool (URET) Initial Two-Way Host Interface Functional
    Accuracy, MTR99W0000090, The MITRE Corporation, McLean, VA.

8.  **Lindsay, K. S.,** January 2000, Results of a URET Operational
    Utility Experiment, WN 00W0000081, The MITRE Corporation, McLean,
    VA.

9.  **Erzberger, H., Paielli, R.A., Isaacson, D.R., and Eshow, M.,**
    "Conflict Detection and Resolution In the Presence of Prediction
    Error," 1st USA / Europe Air Traffic Management R&D Seminar, Saclay,
    France, June 1997.

10. **Leiden, K. and Green, S.,** "Trajectory Orientation: A
    Technology-Enabled Concept Requiring a Shift in Controller Roles and
    Responsibilities," Paper 081, 3^rd^ USA/Europe Air Traffic
    Management R&D Seminar, Naples, Italy, June 2000.
    \<http://atm-seminar-2000.eurocontrol.fr\>

11. **McNally, B. D., Erzberger, H., Bach, R., and Chan, W.,**
    "Controller Tools for Transition Airspace," AIAA-99-4298, AIAA
    Guidance, Navigation, and Control Conference, Portland OR, August
    1999.

12. **Green, S., Vivona, R., Grace, M., and Fang, T**., "Field
    Evaluation of Descent Advisor Trajectory Prediction Accuracy for En
    route Clearance Advisories," AIAA-98-4479, AIAA Guidance,
    Navigation, and Control Conference, Boston MA, August 1998.

13. **Cole, R., et al.,** "Wind Prediction Accuracy for Air Traffic
    Management Decision Support Tools," Paper 110, 3^rd^
    USA / EUROCONTROL Air Traffic Management R&D Seminar, Naples Italy,
    Jun. 2000.

14. **Green, S. M., T. Goka, and D. H. Williams***,* "Enabling User
    Preferences Through Data Exchange," AIAA-97-3862 Guidance,
    Navigation and Control Conference, New Orleans, LA, August 1997.

15. RTCA Special Committee 194, "Concepts for Services Integrating
    Flight Operations and Air Traffic Management Using Addressed Data
    Link," DO-269, RTCA Inc., Washington D.C., 2001.
    [www.RTCA.org](http://www.RTCA.org/)

16. **Williams, D. H., and Green, S. M.,** "*Flight Evaluation of the
    Center / TRACON Automation System Trajectory Prediction Process*,"
    NASA/TP-1998-208439, July 1998.

17. **Green, S., Grace, M., and Williams, D.,** "Flight Test Results:
    CTAS and FMS Cruise/Descent Trajectory Prediction Accuracy," Paper
    84, 3^rd^ USA / Europe Air Traffic Management R&D Seminar, Naples,
    Italy, June 2000.

18. **Slattery, R. and Green, S.M**., "Conflict-Free Trajectory Planning
    for Air Traffic Control Automation," NASA TM-108790, January 1994.

19. **Green, S.M., Williams, D.H., and den Braven, W.:** \"Development
    and Evaluation of a Profile Negotiation Process for Integrating
    Aircraft and Air Traffic Control Automation,\" NASA TM-4360, April
    1993.

20. **Celio, J. C., et al**., "Free Flight Phase 1 Conflict Probe
    Operational Description," MITRE Corp., McLean, VA, March 2000.
    [www.mitrecaasd.org/library/tech_docs/index.html](http://www.mitrecaasd.org/library/tech_docs/index.html)

21. **Green, S.,** \"EDA Concept Definition," Milestone 5.10, Advanced
    Air Transportation Technologies Project Office M/S 262-4, NASA Ames
    Research Center, Moffett Field, CA 94035, September 1999.
    \<[www.asc.nasa.gov/aatt](http://www.asc.nasa.gov/aatt)\>

22. **Williams, D., and Green, S.,** \"Airborne Four-Dimensional Flight
    Management in a Time-Based Air Traffic Control Environment,\" NASA
    TM-4249, March 1991.

23. **Kirk, D., Heagy, W., and Yoblanski, M.,** "Problem Resolution
    Support for Free Flight Operations," IEEE Transactions on
    Intelligent Transportation Systems, Vol. 2, No. 2, June 2001.

24. **Erzberger, H.,** \"Design Principles and Algorithms for Automated
    Air Traffic Management,\" AGARD Lecture Series No. 200 on
    Knowledge-based Functions in Aerospace Systems, Madrid, Paris, San
    Francisco, Nov. 1995.

25. **Hunter, G., Weidner, T., Couluris, G., Sorensen, J., Bortins,
    R.,** " CTAS Error Sensitivity, Fuel Efficiency, and Throughput
    Benefits Analysis," TR96150-02, Seagull Technology, Los Gatos, CA,
    July 1996.

26. **Coppenbarger, R., Green, S., and Weidner, T.,** "Comprehensive
    Benefits Assessment for the En route Descent Advisor," NASA AATT
    Milestone 5.8.1 Report, Advanced Air Transportation Technologies
    Project Office M/S 262-4, NASA Ames Research Center, Moffett Field,
    CA 94035, Sept. 1999.
    \<[www.asc.nasa.gov/aatt](http://www.asc.nasa.gov/aatt)\>

27. **Den Braven, W.,** "Design and Evaluation of an Advanced Air-Ground
    Data-Link System for Air Traffic Control," NASA TM-103899, January
    1992.

[^1]: Current-day Host flight-plan ("6-7-10") amendments were designed
    to support flight plan processing and sector posting of flight
    strips (flight-plan data). Amendments are cumbersome for controllers
    to implement, due to the limitations of the controller interface,
    and have undesirable side effects on the generation and posting of
    flight strips.

[^2]: During single-position sector operations, the R-side has direct
    access to URET capabilities.

[^3]: It may be interesting and beneficial to extend the lessons of
    flight deck crew resource management (CRM) to the ATC counterpart of
    controller roles, responsibilities, and procedures.

[^4]: Controller-in-the-loop simulations of the EDA research prototype
    in the early 1990's led to the qualitative observation that it was
    far more challenging to develop controller-acceptable advisories for
    conflict resolution than for metering conformance.

[^5]: ^†^ This critical awareness issue shares similarities with the
    flight deck related to pilot-FMS interaction. Even rare cases of
    mode confusion may outweigh the benefits of automation under nominal
    conditions, let alone be operationally unacceptable for reasons of
    safety.

[^6]: A supplementary process for streamlined controller inputs was
    developed for the EDA research prototype in 1990 to support
    controller-in-the-loop simulations. The technique applied
    point-and-click/keyboard short cuts, integrated with the primary
    traffic display, to fill flight plan gaps that are not currently
    modeled by the FAA Host computer and don't lend themselves to
    heuristic rules (Ref. 21).

[^7]: This approach, combined with FMS integration via data link, lends
    itself to air-ground trajectory collaboration (Ref. 19).

[^8]: The concept also calls for a complementary DST function to
    identify "dependency alerts" to warn controllers when the
    conflict-free nature of a provisional aircraft plan depends on the
    activation of a

    provisional aircraft plan for one or more other flights.

[^9]: If the flow conformance DOF maxes out, *Build Metering
    Trajectories* returns to *Conflict Resolution* which restarts the
    *Build Metering Trajectories/Trajectory Generation/Metering
    Conformance* iteration again with new resolution DOFs and/or DOF
    values (see section 3.2.4.2.2 for further details).