Mid-Term NAS-Wide Trajectory Automation Requirements Analysis Plan

whinnycampingMechanics

Nov 5, 2013 (3 years and 10 months ago)

438 views


-
DRAFT
-


John Bernard

Travis Gaydos

Al Kwong

Stéphane Mondoloni

Wilson Warren


August 2011


DOCUMENT NUMBER

MI TRE
TECHNI CAL REPORT



Mid
-
Term NAS
-
Wide Trajectory
Automation Requirements
Analysis Plan

-
DRAFT
-


-
DRAFT
-



The contents of this material reflect the views of the author and/or the Director of the Center for
Advanced Aviation System Development (CAASD), and do not nec
essarily reflect the views of
the Federal Aviation Administration (FAA) or the Department of Transportation (DOT). Neither
the FAA nor the DOT makes any warranty or guarantee, or promise, expressed or implied,
concerning the content or accuracy of the view
s expressed herein.

This is the copyright work of The MITRE Corporation and was produced for the U.S.
Government under Contract Number
DTFAWA
-
10
-
C
-
00080

and is subject to Federal Aviation
Administration Acquisition Management System Clause 3.5
-
13, Rights in Data
-
General, Alt. III
and Alt. IV (Oct. 1996). No other use other than that granted to the U.S. Government, or to those
acting on behalf of the U.S.
Government, under that Clause is authorized without the express
written permission of The MITRE Corporation. For further information, please contact The
MITRE Corporation, Contract Office, 7515 Colshire Drive, McLean, VA 22102 (703) 983
-
6000.


2011

The MIT
RE Corporation. The Government retains a nonexclusive, royalty
-
free right to
publish or reproduce this document, or to allow others to do so, for “Government Purposes
Only.”



-
DRAFT
-



Sponsor:
The Federal Aviation Administration

De
pt. No.:

F055

Project No.:

0210CH01
-
IF


Outcome No.:

1

PBWP Reference
: 3
-
3
-
B
-
5


Mid
-
Term Trajectory Automation
Requirements Analysis Plan



For Release to all FAA

This document was prepared for authorized
distribution only. It has not been approved for
public release.


©2011

The MITRE Corporation.

All Rights Reserved.


Mid
-
Term NAS
-
Wide Trajectory
Automation Requirements
Analysis Plan


-
DRAFT
-


John Bernard

Travis Gaydos

Al Kwong

Stéphane Mondoloni

Wilson Warren


August 2011


DOCUMENT NUMBER

MI TRE TECHNI CAL REPO
RT





-
DRAFT
-


iii


Abstract



-
DRAFT
-


iv


Table of Contents

1

Introduction

1
-
1

1.1

Purpose

1
-
2

1.2

Assumptions

1
-
4

1.3

Document Organization

1
-
5

2

Trajectory Concept

2
-
1

2.1

Ev
olution of a Single Flight’s Trajectories

2
-
1

2.1.1

NAS
-
Wide Shared Trajectory

2
-
1

2.1.1.1

Trajectory Update

2
-
1

2.1.2

Integration with Airborne Reports

2
-
3

2.2

Flight Planning & Strategic TFM

2
-
5

2.2.1

FCM

2
-
9

2.2.2

CTOP

2
-
9

2.2.3

IDRP

2
-
10

2.2.4

ICM

2
-
11

2.2.5

EFPT

2
-
12

2.2.6

Summary

2
-
12

2.3

Surface Operations

2
-
13

2.4

Terminal Operations

2
-
14

2.4.1

Terminal DSTs Utilizing a Terminal Specific Trajectory

2
-
14

2.4.2

Terminal DSTs Utilizing a NAS wide Trajectory

2
-
16

2.4.3

Far term Terminal Capabilities t
hat would utilize a trajectory

2
-
17

2.5

En Route Operations

2
-
18

2.5.1

High Altitude Sector

2
-
19

2.5.2

Delegated separation
-

Interval management

2
-
19

2.5.3

Enhanced Conflict
-
Probe

2
-
20

2.5.4

Conflict Resolution

2
-
21

2.5.5

RNP/RNAV Routes

2
-
22

2.5.6

En Route
Data Communications

2
-
22

2.5.7

Airborne Reroute Execution

2
-
22

2.6

Time
-
Based Flow Management

2
-
22

2.6.1

NAS Functions Performed by T
BFM

2
-
23


-
DRAFT
-


v


2.6.2

TBFM Inputs

2
-
24

3

Data Communication

3
-
1

3.1

Uplink Messages

3
-
3

3.1.1

Open versus closed trajectories

3
-
4

3.1.2

Multip
le trajectory options possible

3
-
4

3.1.3

Execution of Instruction

3
-
5

3.2

Downlink Messages

3
-
7

3.2.1

Downlink Request Messages

3
-
7

3.2.2

Downlinked Information Reports

3
-
8

3.2.3

Downlink of Preferences or Constraints on Instructions

3
-
9

3.2.4

Emergency Maneuvers

3
-
9

3.3

Aircraft
-
derived Intent Information

3
-
9

3.3.1

ADS
-
C Messages

3
-
9

3.3.2

ADS
-
B Reports

3
-
13

4

Trajectory Performance Evaluation

4
-
1

4.1

Trajectory Prediction and DST Evaluation

4
-
1

4.1.1

Decomposition


Trajectory Prediction versus DST

4
-
5

4.2

Trajectory Update Evaluation

4
-
5

4.3

Trajectory Exchange and Errors of representation

4
-
9

4.4

Effect of Data Communication

4
-
10

4.4.1

Analysis of Automated Dependent Surveillance Capabilities

4
-
10

4.4.2

Analysis of CPDLC messages

4
-
11

4.5

Tools for Trajectory Prediction

4
-
12

5

Impact to DST Evaluation

5
-
1

5.1

Operational Conditions

5
-
2

5.2

Buffers & Interruptions

5
-
2

5.3

NAS Functions

5
-
3

6

Summary and Next Steps

6
-
1

7

List of References

7
-
1

Append
ix A

SC
-
214 Message Applicability to TBO

A
-
1

Appendix B

ADS
-
C Reports


Changes to DO
-
258A

B
-
1

Appendix C

ADS
-
B Reports

C
-
1


-
DRAFT
-


vi


Appendix

D

Glossary

D
-
1



-
DRAFT
-


vii


List of Figures

No table of figures entries found.





-
DRAFT
-


viii


List of Tables

No table of figures entries found.

No table of figures entries found.



-
DRAFT
-


1
-
1


1

Introduction


Delivery of the Next Generation Air Transportation System (NextGen) Mid
-
Term Capabilities
requires the exchange of predicted trajectory information. This trajectory information is used in
a variety of contexts from
strategic (e.g., post
-
operational analysis) to tactical (e.g., problem
detection and resolution) applications. In the NextGen Mid
-
Term, trajectories are evaluated for
resource utilization and problem identification and may be controlled to resolve problem
s from
strategic to tactical time horizons.

Control of the trajectory may be accomplished through modification of the route, or imposition
of constraints on altitude, time, or speed. These control actions may be proposed by the flight
operator when tim
e is available, developed by traffic flow management (TFM) or developed by
air traffic control (ATC) depending on the nature of the problem being addressed. Control
actions may be evaluated by automation using a predicted, “trial” trajectory or may be man
ually
developed in response to a detected problem. However, it is expected that any problem
resolution created manually will be provided to automation ensuring that accurate trajectory
input information will be available.

The quality of the trajectories

available for trajectory evaluation and problem resolution will
impact the performance of both the evaluation and problem resolution functions. The
performance of these functions will have consequences in the areas of airspace capacity,
controller workloa
d, fuel efficiency, delays and predictability. In light of this, one might argue
that one would simply want to have the highest quality trajectory available to all functions all the
time. However, at a minimum when a trajectory is being evaluated for prob
lems or resource
utilization across a multitude of NAS functions spread across domains, this requires that:

1.

The information required to develop such a trajectory be obtained and maintained up
-
to
-
date in a dynamic environment;

2.

The trajectory be predicted us
ing the above information, tailored to the individual flight
parameters; and,

3.

The trajectory be disseminated, or exchanged between trajectory consumers in a form
that does not degrade the quality of the trajectory.

Each of the above steps requires increas
ing resources as one seeks to improve the quality of a
trajectory prediction. In the case of information exchange, information pertinent to a trajectory
may be obtained from the flight operations center, the flight deck, the ATC controller ready to
issue
an instruction, ramp control ready to issue pushback instructions, local controllers
impacting the departure time and TFM potentially issuing traffic management initiatives. With
all these participants holding information on the flight, one must define re
quirements on what
information is provided by whom at what times.

The use of information to generate a trajectory requires an accurate model of the aircraft and
aero
-
propulsive behavior to model the lateral, vertical and longitudinal profiles of a flight
. This
model must be consistent with the level of flight
-
specific information provided. For example,

-
DRAFT
-


1
-
2


variations of engine types may be incorporated into the aero
-
propulsive models, but if this
information is never provided for a flight, the model is over
-
specified.

Trajectories created in one system may be exchanged with another system. This can include the
downlink of trajectories to ground automation from aircraft automation via data communication.
How the trajectory is specified and re
-
created on th
e receiving end will impact the quality of the
trajectory used by the recipient. The definition of standard trajectory interfaces for ground
-
ground exchange also simplifies the exchange of these data.

In the case of problem resolution, the generation of
control actions is typically accomplished
through an evaluation of the resulting trajectory when control is applied. This requires that
problem resolution functions:

1.

Ensure feasibility and acceptability of the resolution (enacted through control actions on

the trajectory);

2.

Evaluate a multitude of trajectories under various candidate control actions;

3.

Ensure that the execution of the control instructions result in the trajectory predicted to
resolve a detected problem.

Additional information beyond that required for prediction of a single trajectory will likely be
required to accomplish the above. Control instructions must also be specified in a manner
suitable to creating an unambiguous trajectory (i.e., no “open” instr
uctions).

With problem resolution functions expected to remain distributed across the NAS, the above
necessitates the timely generation of alternative trajectories either locally or through a trajectory
service. Either of these options requires informat
ion exchange and management of consistency
of dynamic trajectory information. Specific requirements on data exchange should be defined by
considering the performance implications of various alternatives.

1.1

Purpose

This document describes an analysis plan fo
r the evaluation of Trajectory Prediction and
Exchange alternatives suitable for the end of the NextGen Mid
-
Term. The objective of the plan
is to

provide a detailed approach for the
develop
ment of

recommendations forming the basis for
trajectory predictio
n and exchange requirements.
Specifically
, the approach will detail an
approach involving analysis, modeling and simulation

seeking to address these
areas:

1.

What is the impact on trajectory prediction of choices in information exchange between
participants
?

This information exchange may be ground
-
ground or air
-
ground.

2.

What is the impact of various representations of

exchanged four
-
di
mensional trajectories
?

3.

What is the impact of various

alternatives for exchanging
trajectories? These alternatives
include

the description of:

a.

Under what circumstances are predicted trajectories generated versus shared?

b.

When multiple trajectories are involved, what are the consequences of
discrepancies and how are these managed?


-
DRAFT
-


1
-
3


c.

What NextGen capabilities are supported by whic
h predicted or exchanged
trajectory?

4.

The above three questions help define trajectory prediction and exchange alternatives
(i.e., alternatives in information exchange, trajectory representation and which systems
are responsible for prediction).
Given

the
impact of alternatives on traje
ctory prediction
performance, what is

the subsequent effect on Decision Su
pport p
erformance for
automation using the trajectories?

In addition to providing recommendations for the development of requirements applicable to
tra
jectory prediction and exchange, i
t is expected that recommendations stemming from the
execution of this plan will inform the information items required for trajectory exchange forming
part of the
Flight Object.


The overall approach
first involved the ide
ntification of NAS Functions impacted by trajectory
prediction and exchange including

the description

of
performance
metrics applicable to these
functions [1].
These metrics and NAS functions define the future DST “clients” of trajectories to
be investiga
ted in item 4 described above.

Initi
al concept
-
level alternatives w
ere subsequently
described in [2]. These alternatives were
also evaluated against the Trajectory Operations Concept as articulated in [3] to ensure
consistency.

These initial alternativ
es form the basis for the more detailed alternative specified
herein.

Data communication with the flight deck is an important aspect of trajectory operations. It is
through air/ground data communication that
“closed” clearances can be provided to the flig
ht
deck and that
air/ground synchron
ization of a trajectory may

occur
.
As such, a report in [4]
described the data communications options available for the
air/ground
exchange of trajec
tory
information and clearances.
A further inves
tigation of data commu
nication
messages is described
herein to define the specific exchange patterns and information exchanges to be analyzed.

The overall approach described in this analysis plan decomposes the problem of trajectory
prediction and exchange into two fundamenta
l elements: (a) the impact of alternatives on the
trajectory and (b) the impact of the trajectory on the consumers of the trajectory information. It
is recognized that his approach captures the initial effect of trajectory prediction performance on
DST pe
rformance and not the knock
-
on effects

described below.

As an example of knock
-
on effects of trajectory prediction performance, consider a
trajectory prediction subject to inaccuracies. When a prediction results in a decision
support tool recommending a
trajectory modification, that modification is expected to be
problem
-
free. However, as a result of prediction inaccuracies, there is some likelihood
that a problem will remain and have t
o be dealt with again. The process continues with
each problem resol
ution.

The proposed approach is not expected to predict the full consequence of trajectory prediction
errors. However, it is expected to provide the accurate relative performance between alternatives

(i.e., a trajectory with poor initial performance is u
nlikely to perform better when knock
-
on

-
DRAFT
-


1
-
4


effects are incorporated).
It is
also
expected that the rate of knock
-
on effects will be low, thanks
in large part to the application of buffers to mitigate their effect.



1.2

Assumptions

The concept and analysis pl
an described in this document is subject to several key assumptions.
These are summarized below.



Data communication will be ena
bled for trajectory operations on the surface and for en
route operations. No data communication capability is assumed in termi
nal airspace.



A mixed
equipage environment will persist through the NextGen Mid
-
Term. This
implies varying levels of data communications capabilities including: none, FANS
-
1/A+,
through full RTCA SC
-
214 messages.
This also implies varying level of capabilities
regarding the auto
-
loading of clearances and the ability to handle a complex route
clearance.



All controlled aircraft are assumed to operate with trajectory information

known to
ground automation. A trajec
tory is expected to be maintained in ground systems
regardless of aircraft equipage. The accuracy of trajectories will be a function of the
aircraft equipage and may impact the magnitude of buffers imposed by decision support
automation using the trajecto
ry.



Aircraft with FMS are assumed to construct and fly the trajectory via the FMS, per the
TOps concept

[3]
. When also equipped with ADS
-
B and ADS
-
C capabilities, intent
information may be provided

through ADS
-
B and/or
-
C

to the ground in accordance with
the level of data communication available.
This includes the provision of Estimated
Times of Arrival (ETA) at trajectory change points along the trajectory. This information
will be incorporated into ground predictions.




Some aircraft with FMS will be equ
ipped with RTA capabilities
. These aircraft will only
be capable of accepting one RTA at a time.

This capabilit
y may be used for the purposes
of

time
-
based metering.



Wherever possible, “closed” trajectory instructions will be provided to the flight enab
ling
intent to be known for creating a trajectory.



Trajectory uncertainty stemming from human errors

not attributable to trajectory
performance

is not considered in this analysis. This includes such effects as pilot
blunders, missed read
-
back errors, an
d dropped messages.



Information items that are indicated as required for trajectory prediction within an
alternative are available and input correctly by participants. For example, wind
information is assumed to be input into flight deck automation
, when
available
.
However, the analysis may investigate the impact of discrepancies between information
quality (i.e., differences stemming from air/ground wind differences).

When information
required for trajectory prediction may reside within different databa
ses (i.e. navigation

-
DRAFT
-


1
-
5


databases)

there is a requirement for synchronization of this information or the derived
trajectory information.



Flight information can be shared across domains through a Flight Object

[5]

allowing
request/ response and publish/ subscr
ibe exchange patterns.



Common situational awareness exists for additional information required for trajectory
prediction such as aeronautical information, flight
-
specific TFM constraints,
airport/airspace configuration, weather, etc.



Alternatives for tra
jectory prediction and exchange should be developed in a manner to
support NextGen capabilities as defined through Operational Improvements in the NAS
Enterprise Architecture.



Aircraft enabled with certain capabilities will be able to use those capabiliti
es to the
maximum extent possible. For example flights capable of providing important trajectory
information via data communication will do so.

1.3

Document Organization

This document describes the following:



Section 2 articulates a concept for trajectory p
rediction and exchange (TPAX) that will
form the basis for the evaluation proposed herein.



Section 3 describes the specific impact that data communication will have on TPAX.
This Section references Appendices A through C on the CPDLC, ADS
-
C and ADS
-
B
alte
rnatives, and their applicability to trajectory
-
based operations.



Section 4 discusses the approach for evaluating the performance of trajectories under
various alternatives. This approach will generate a collection of trajectories and error
data under mul
tiple operational conditions to be used when evaluating decision support
tools as described in Section 5.



Section 5 describes how the trajectory data discussed in Section 4 will be used to obtain
DST performance measures as defined in [1].



Section 6 discus
ses the next steps.



-
DRAFT
-


2
-
1


2

Trajectory Concept

A prior effort

[2
] has

described a collection of alternatives for trajectory prediction and
exchange
. For the purposes of this trajectory evaluation plan, we are constraining these
alternatives t
o those that have the following properties:



A NAS
-
Wide strategic trajectory exists and is shared across domains. This
trajectory is
analogous in current operations to the active flight plan as amended.



Capabilities requiring more accuracy, particularly
in the short
/medium

time look
-
ahead
horizon,

may supplement the NAS
-
Wide trajectory with a higher
-
fidelity local trajectory
incorporating additional information or be updated at more frequent intervals. An
example might be the incorporation of surveillance

information upon receipt of every
update.



A higher
-
fidelity predicted trajectory is expected to describe a flight path and profile that
is within defined tolerance bounds of the NAS
-
Wide strategic trajectory. Exceeding
these bounds should result in an
update to the NAS
-
Wide strategic trajectory.



Events may lead to an update of the NAS
-
wide strategic trajectory. The update is
disseminated to all consumers of the NAS
-
wide strategic trajectory.



Where
necessary to build one or more trial strategic trajec
tories
, the capability exists to
be able to do so using the
same algorithms and shared common trajectory input
information as used for the NAS
-
Wide strategic trajectory. This capability may be
implemented in a variety of manners such as through common sof
tware libraries or
through a Service Oriented Architecture (SOA) compliant service.



When a NAS
-
Wide strategic trajectory for a flight is based upon aircraft
-
derived
information (such as through the use of aircraft
-
provided ETAs), a trial strategic
trajec
tory for the same flight will have access to some shared input information such as
constraints and speed schedules. However,
airborne algorithms are not expected to be
shared with ground systems for the development of trial trajectories.

The above
properties are

consistent with
multiple
concept documents, suc
h as the UFPF Concept
[6
],
the Flight Object Concept of Use [
5
]
,
the
Far
-
Term NAS Flight Data Services
Concept of
Use
[7
] and the Draft RTCA Trajectory Operations Concept [3].

2.1

Evolution of a Sin
gle Flight’s Trajectories

Applying the properties described previously to the alternatives described in [2], we describe the
evolution of a single flight’s trajectories from scheduling through its operation.

Scheduling



During the scheduling phase, multi
ple ANSP
-
derived trajectories are
expected to be applied with probabilities assigned to each. We assume that these
trajectories are developed through historically available trajectory input data combined
with and conditioned on operator
-
provided data. Tra
jectories are generated using a

-
DRAFT
-


2
-
2


common algorithm for the strategic trajectory.
These trajectories are not expected to be
shared at this stage beyond TFM tools evaluating demand/capacity imbalances.

Flight Planning


During the flight planning stage, ope
rators provide multiple trajectory
options
.

These trajectories may have variable departure time options. They may be
provided
in
one of two
alternatives:

Trajectory input data


Operators provide ranked options for each flight including
trajectory input

data (see below) for each option. This information
, together with
shared NAS data,

is used by the ANSP to generate a traj
ectory using a common
algorithm

for the strategic trajectory.

Operator
-
provided trajectory



Operators provide ranked options for eac
h flight
including an end
-
to
-
end strategic trajectory for each option.

Each trajectory is
represented in a manner consistent with the shared NAS
-
Wide strategic trajectory.
The input data above must also be provided in the event that a new trajectory
must
be generated subsequent to ANSP
-
initiated amendments.

The above

trajectories are used for flight planning by the operator and demand
-
capacity
balancing by TFM. Ranked trajectories are selected in accordance with know
n business
rules to identify a single t
rajectory for each flight meeting TFM objectives consistent
with the flight rankings provided.

Flight Plan Filing and

Pre
-
departure

Amending



Once a trajectory has been selected for
filing during the flight planning stage, this trajectory becomes the in
itial shared NAS
-
wide strategic trajectory.
This trajectory may be subject to amendments by either
the
operator

(e.g. substitutions)

or by the

ANSP regardless of which participant

created the
trajectory. In either case, the trajectory
-
generation process is identical to that during
flight planning.

Surface Operations


Surface trajectory
-
based operations
(STBO)
are expected to provide
six capabilities as described in [2]. These cap
abilities interact with
multiple
dom
ains at
various periods during the flight. Interactions

are not unidirectional; NAS
-
Wide strategic
trajectories

affect the output of th
ese surface capabilities and

vice
-
versa.
While STBO
operations are likely to operat
e with a surface trajectory, the interaction with a NAS
-
wide
strate
gic trajectory is expected to be
through the

departure and arrival times, airport
configurations, runways and their corresponding
departure and arrival routing. When
available, the D
-
TAXI s
ervice would be applied for issuance of STBO clearances to
suitably equipped aircraft.

Terminal

-

For the late NextGen Mid
-
Term, anticipated decision support automation in
terminal airspace will rely on two forms of trajectories
: the NAS
-
wide strategic
trajectory
and a very short
-
term tactical trajectory.

This short
-
term tactical trajectory is expected to
be the result of state
-
space extrapolation, or short
-
term intent, versus a 20
-
minute look
-
ahead horizon. Terminal airspace capabilities include:

Auto
mated Terminal Proximity Alert (ATPA)



Display of a separation cone for
mitigating
loss of separation
on final approach. This is a short
-
term problem

-
DRAFT
-


2
-
3


detection capability alerting the control. This capability is based on state
-
vector
extrapolation.

Relative Position Indicator (RPI)


This capability facilitates merging and spacing

on arrival through projection of surveillance information on respective
procedures. This capability is based on state
-
vector extrapolation projected onto
an RNAV path (i.e
., short
-
term intent is applied).

Route Conformance Monitoring


Provides a display to the controller when the
flight is not conforming to a SID or STAR’s route and vertical constraints. This
capability uses surveillance information, route information a
nd vertical constraint
information. A short
-
term projection of the profile is expected to anticipate
constraint violation.

Arrival Sector Load Assessment and Alerting


A NAS
-
wide trajectory would

be
applied for sector load prediction and alerting in te
rminal airspace.

Airspace Reconfiguration Tool


Pre
-
defined airspace
configurations are
evaluated considering weather impact and traffic through the NAS
-
Wide strategic
trajectory.
Longer look
-
ahead horizons would require demand information from
flights
that have not yet filed. TFM capabilities also require this additional
information as probabilistic based on historical data or early intent information.

Metering Inside TRACON Airspace



Time
-
based flow management extends
metering fixes into terminal airs
pace.
Scheduled metering times, an ability to
estimate the time of arrival at the metering fix and the ability to determine the
impact of control actions on the metering fix arrival time are all required.

These
have typically necessitated a more accurate

trajectory predictor with a focus on
prediction of arrival time at
the fix.

Far
-
Term

Capabilities



Terminal airspace has a number of additional capabilities
potentially requiring a more accurate local trajectory. These capabilities include:
automated point
-
outs, handoffs, delegated spacing assistance, merging and
spacing with resolutions and termina
l conflict probe.

En Route



In the late NextGen Mid
-
Term, the En Route airspace is expected to be
capable of controller
-
pilot data communications (CPDLC) with ADS
-
C capabilities as
well. A mixed equipage environment is expected to prevail. En Route ai
rspace will
incorporate
enhanced
conflict detection and resolution capabilities

taking advantage of
RNP capabilities. These capabilities are expected to use a more precise medium look
-
ahead trajectory consistent with the NAS
-
Wide strategic trajectory. AD
S
-
B and

C
information will be used (for equipped aircraft) to ensure consistency of the trajectory
between the ground and the aircraft, and to improve the prediction used by the ground.
Clearances are expected to be provided in a manne
r that ensures a uni
que, closed

end
-
to
-
end trajectory can be generated. Airborne re
-
routes
can be generated by Traffic Flow
Management and can be implemented by En Route automation resulting in updates to
the
NAS
-
wide trajectory and any local trajectory.


-
DRAFT
-


2
-
4


Time
-
Based Flow Man
agement



Time
-
based flow management in the NextGen Mid
-
Term will be modified to incorporate metering in terminal airspace enabling greater
delivery accuracy closer to the threshold. More efficient time control will be made
possible through
extended meteri
ng. Use of on
-
board required time
-
of
-
arrival control
will enable precision in meeting metering fix arrival times. Where possible, Optimized
Profile Descents will be integrated with TBFM.
Departure time control will also be
integrated into TBFM. For the
meet
-
time function of metering, trajectory prediction with
a faster update rate (over a NAS
-
wide strategic trajectory) is expected. It is assumed here
that an integrated trajectory prediction used for en route conflict detection and resolution
will be app
lied to this end.

Figure 2.1
-
1 illustrates the various domains together with the
various
expected trajectories
. These
are summarized below:



Historical trajectories are used early in the flight planning and flow contingency
management process. These are
based on early intent information that may not include
route of flight.



Trajectory Options Sets are complete prioritized trajectories based upon user
-
specified
information. These are compliant with some constraints but may be shifted in time by
TFM. The

trajectory is generated using identical algorithms and information to that used
to obtain a NAS
-
Wide strategic trajectory.



The NAS
-
wide strategic trajectory is created during flight plan filing and is continually
updated and shared between domains as
add
itional
information becomes available.



Surface trajectories may be defined for STBO operations at departure and/ or arrival
airports. Consistency with the NAS
-
wide strategic trajectory is achieved through
departure/arrival time matching and through runw
ay use coupled with appropriate
departure or arrival procedures. Improved surface information can update the NAS
-
wide
trajectory and vice
-
versa.



A terminal tactical trajectory is based upon short look
-
ahead surveillance information.
This short
-
term traj
ectory is used for RPI and ATAP functions and may be coupled with
information in the NAS
-
wide trajectory for conformance monitoring.



A medium
-
term look
-
ahead trajectory is computed through more
frequent surveillance
updates and

integration with downlinked
aircraft intent information (if available)
. The
trajectory is applied to conflict detection and resolution functionality in addition to
TBFM meet
-
time functions. For metering into terminal airspace, adjacent center
medium
-
term trajectories may have to be

shared with terminal automation. Flights
exceeding adherence bounds between the medium
-
term trajectory and the NAS
-
wide
strategic trajectory will require an update to the NAS
-
wide trajectory.



-
DRAFT
-


2
-
1




Figure 2.1
-
1 Illustration of trajector
y interaction across domains


Flight Planning &
Filing
Surface
-
Departure
Terminal
-
Departure
En Route
Terminal
-
Arrival
Surface
-
Arrival
TFM
NAS
-
Wide Strategic Trajectory (NWST)
Create
Shared
Update
Shared
Update
Shared
Update
Shared
Update
Weather
Winds
Constraints
Eligibility rules
Aeronautical Information
Aircraft Performance models
Update
Shared
NWST
-
TP
NWST
-
TP
TBFM
Surface
Trajectory
Terminal
Tactical
Trajectory
Medium
-
term
Trajectory
Terminal
Tactical
Trajectory
Surface
Trajectory
Historical
Trajectories
Trajectory
Options Set

-
DRAFT
-


2
-
2



Figure 2.1
-
2 Illustration of potential NAS
-
Wide strategic trajectory





Points in Route

Additional
TCPs

CAS/Mach

TOC

Begin Step

End Step

TOD

M/CAS

Altitude Constraint

Climb Schedule

Descent Schedule

Step Climb


-
DRAFT
-


2
-
1


2.1.1

NAS
-
Wide Shared Trajectory

It i
s assumed that a NAS
-
wide strategic trajectory is sh
ared across domains as described
previously
. At

a minimum, the shared trajectory is described through a converted route,
important additional TCPs with times and altitudes at the points. Constraint information, events
and named points are also included in the trajectory (See Figure
2.
1
-
2
). Various co
nformance
and adherence bounds may exist around the trajectory. When airborne, the NAS
-
wide trajectory
may be a blend of historical and projected data. Historical data applies from departure to
approximately PPOS, with projected da
ta to all subsequent po
ints.


With RNP equipage, adherence to the lateral trajectory is expected within bounds as described
by the RNP level. Adherence to a trajectory either vertically (during climb or descent) or along
-
track (longitudinally) is not expected within pre
-
deter
mined vertical or longitudinal bounds along
the trajectory. As a result, NAS
-
wide trajectory predictions are expected to have vertical and
longitudinal inaccuracies. These inaccuracies will not be constant with look
-
ahead time.
Constraints at a point such

as an altitude constraint or a required time
-
of
-
arrival constraint can
limit the growth of these errors to required error bounds at the constraints.


It is fully expected that a NAS
-
wide strategic trajectory would be represented by a collection of
trajec
tory change points
(TCP)
each containing position (latitude, longitude, altitude and time)
information. Associated with each change point could be additional information such as:



Type of change point



Named fix location



Turn information (if necessary, such

as fly
-
by, fly over, turn radius)



Applicable time, altitude, or speed constraints



Speed at the point (air, ground, Mach)



Wind at the point



Adherence bounds in 4D for NAS
-
wide trajectory update



Uncertainty around estimates (e.g.
,
errors in ETA
as a result
of propagation of departure
time uncertainty)


One of the objectives of the work emanating from this plan is to identify the trajectory accuracy
impacts of specifying various types of TCP and of including different data items within each
TCP. The type of
interpolation specified between different types of TCPs will also be specified.
Further, the capabilities described in all domains will update the trajectory subsequent to certain
events

occurring within each domain.

2.1.1.1

Trajectory Update

Once an initial NAS
-
Wide strategic trajectory has been generated and sha
red for a flight, there
are multiple

events that can lead to a subs
equent update. Many of t
hese are related to the
functions that are conducted by the various domains as the flight progresses through. F
or
example:


-
DRAFT
-


2
-
2




Flight Planning & Filing



As business objectives may vary as a result of exogenous
influences, operators may elect to modify any aspect of a trajectory prior to filing. These
must be accepted after filing. Weather forecasts and congestion ca
n change post
-
filing,
leading to updates by TFM as a result of selecting different options in a trajectory options
set.



Surface



Updates to the configuration & runway selection can alter not just the departure
time but the departure and arrival procedure
s. Events occurring on the airport surface
will impact the uncertainty surrounding an estimate of the departure time. For instance,
subsequent to pushback, one expects departure time uncertainty to be reduced.

Changes
to a surface trajectory will affect
the airborne trajectory forecast and vice versa on arrival.



Terminal


Actions in terminal airspace resulting in changes to the flight path or time at
specified locations can require an update. Regarding the time at points, one would expe
ct
surveillance d
ata to update the terminal

tactical trajectory which can result
in the NAS
-
wide trajectory needing an

update as a result of exceeding adherence bounds.



En Route


Functions in en route airspace may require changes to a trajectory as re
-
routes,
clearances a
s a result of requests,
conflict resol
ution or metering functionality.
Each of these update an en route medium
-
term trajectory resulting in an update to the
NAS
-
wide strategic trajectory when necessary (either adherence bounds are violated or
on a
time
-
cycle).



Time
-
Based Flow Management



The NAS
-
wide strat
egic trajectory can be modified as a
result of TBFM activities. These can potentially lead to changes in routing, departure
time and speed control for meeting scheduled times
-
of
-
arrival. Changes

to a local high
-
fidelity trajectory are expected to propagate to the NAS
-
wide trajectory as a result of
exceeding adherence bounds.

Other updates can occur as a result of:



E
xogenous I
nformation Updates



Additional information required for a trajectory
p
rediction may be updated, these include: wind forecasts, required constraints, or system
outages.




Cyclical Updates


The NAS
-
wide trajectory might have a mandatory time cycle on
which it is
refreshed.



Airborne Updates



Receipt of aircraft intent informat
ion through CPDLC, ADS
-
C or
ADS
-
B messages and reports will require that the NAS
-
Wide strategic trajectory
be
updated as a
result of improved information (e.g. updated descent speed
profile
,
improved along
-
track time prediction).
For medium look
-
ahead cha
nges to the trajectory,
it is assumed that the information
would be used to update

a local, high
-
fidelity
trajectory, which would then update the NAS
-
Wide strategic trajectory if adherence
bounds are exceeded.


-
DRAFT
-


2
-
3


Table 2.1
-
1 summarizes trajectory update tri
ggers and operational uses of the trajectory by
domain
. A trajectory update will typically cause the re
-
evaluation of that trajectory, which may
result in additional updates and further evaluations by other systems and domains.

Table 2.1
-
1 Summary of Tr
ajectory Updates and Uses by Domain

Domain

Trajectory Updates

NAS
-
Wide
Trajectory Uses

Planning & Filing

Operator
-
initiated

Changes to TMI including departure time
control

Initial NAS
-
Wide strategic trajectory

Resource utilization


Evaluate
airspace and
airport demand, identify
impacted flights.

Constraint evaluation

Trajectory Feasibility

(Fuel Calculation on operator
-
trajectories)

Surface & TBFM
pre
-
departure

Configuration Changes

Runway Selection

Departure time Update

Resource utilization


Evaluate
arr/dep demand, determine departure
fix times

Terminal & TBFM
in terminal

Adherence due to surveillance updates

Clearance issuance for resolution or
metering

Weather avoidance

Resource utilization


for terminal
metering

Conforman
ce monitoring & constrain
t
evaluation

Trajectory feasibility for trajectory
modifications

Estimating separation using local
higher
-
fidelity trajectory

En Route & TBFM
en route

Adherence due to surveillance updates

Clearance issuance for conflict resolution,
metering

Weather
avoidance

Estimating separation using local
higher
-
fidelity trajectory

Conformance monitoring & constraint
evaluation

Trajectory feasibility for trajectory
modifications

Resource utilization


for metering

Aircraft
-
initiated

Executing a clearance

Updates
to trajectory parameters (e.g.
descent schedule, speed)

Ground r
eceipt of ADS
-
C/B reports

Aircraft not expected to receive the
NAS
-
Wide trajectory


2.1.2

In
tegration with Airborne Reports

Suitably equipped aircraft will provide the ground system with Automated

Dependent
Surveillance reports through a combination of ADS
-
B reports or ADS
-
C reports.

Ground
systems will be receiving surveillance information and potentially short
-
term intent data
(as a

-
DRAFT
-


2
-
4


sequence of trajectory change reports)
through ADS
-
B messages.
Longer time
-
horizon intent
can be received through ADS
-
C messages obtained on either a periodic or event
-
based contract.

Figure 2.1
-
3 illustrates the exchange pattern associated with receipt of surveillance data through
an ADS
-
B
report. We assume a process for update based upon

the receipt of state vector reports
and

short
-
term intent
through TC reports
as follows:

1.

State vector data is compared against the predicted state vector at the reported time.

2.

Conformance monitoring is performed on the data first to ensure that the reported data is
consistent with the intent information contained in the ground predicted trajectory.

a.

When conformance monitoring indicates a lack of consistency between the data,
t
he controller is notified of such discrepancy.

3.

Adherence monitoring is then performed on the data to determine if the reported data is
out
-
of
-
adherence with a previously predicted trajectory. A trajectory that is out of
adherence will be updated using the
up
-
to
-
date state vector report.

a.

If required
, the trajectory will be updated in the appropriate dimension and the
update is propagated to the end of the trajectory look
-
ahead horizon (end
-
to
-
end
for a NAS
-
wide strategic trajectory).

4.

When TC reports are
received as well, the process above applies to the combined state
-
vector report and intent information received in the TC report.
Turn data, such as turn
radius, would be included in this report.

5.

Target state reports can be used to supplement the short
-
te
rm trajectory prediction in
several manners:

a.

When out
-
of
-
conformance, a short
-
term
projection

can be based on extrapolation
using
target state.

b.

Use o
f mode and target information can help improve short
-
term accuracy and
verify targets are consistent with

clearances.

The above process applies to either a local, higher fidelity trajectory or to a NAS
-
Wide strategic
trajectory. It is expected that the NAS
-
Wide strategic
trajectory will have larger

adherence
bounds. More

details on the update process, adher
ence bounds and the impact on accuracy
are
discussed in Section 4.1.

The use of ADS
-
C reports, whether through FANS
-
1/A+ or through the DRAFT reports
discussed in the RTCA SC
-
214, will follow a similar process
to the ADS
-
B update
with different
levels of i
nformation content.

Several differences exist

between the ADS
-
B and C information:

1.

Event
-
based reports can be used to trigger ADS
-
C reports when exceeding certain
adherence bounds.

2.

Significantly more waypoints can be included in ADS
-
C reports.

3.

Additional i
nformation improving trajectory prediction can be provided. For example:
speed
-
schedules in climb and descent, current total mass of the aircraft
, mass at top
-
of
-

-
DRAFT
-


2
-
5


descent, speed in units other than Mach number, resolution for time and position
reporting are

different, inclusion of meteorological data, significant number of trajectory
change point types

(including step climb/descent)

and expression of ETA windows.

When additional information is
included in the trajectory
(i.e.,
such as aircraft mass
)
, ground
-
based trajectory prediction may use such information in predictions, and, where possible, in trial
trajectories.


Figure 2.1
-
3 Illustration of update process from ADS
-
B reporting

It is recognized that not all flights will be equipped with the c
apability to share information air
-
to
-
ground. It is assumed that such flights will therefore have a lower level of trajectory
prediction accuracy

More air
-
ground exchange patterns are described in Section 3 pertaining to the issuance of
clearances via c
ontroller
-
pilot data communication. Another very similar concept for the use of
exchanged trajectory information with the flight deck is described in the 4DTRAD Concept of
Operations [34].

2.2

Flight Planning

& Strategic TFM

A number of
TFM mid
-
term concepts
may drive requirements for NextGen trajectory
development. These concepts are summarized below.
Note: Of the concepts summarized
below, only the Collaborative Trajectory Management Program has proceeded through the
Final Investment Decision within the FAA acquisition management process. As such, all other
capabilities discussed are
only discussed a
s
potential TFM capabilities for the mid
-
term.



Flow Contingency Management (FCM)


The FCM concept
[8
] introduces a new
approach to managing uncertainty in strategic TFM operations by attempting to provide
scientific basis to strategic operational decision
s. Under the FCM concept, automation
will identify demand
-
capacity imbalances 4
-
6 hours in advance of a potential constraint
ADS
-
B

Report(s)

Conformance Monitoring

Adherence Monitoring


Notify Controller

Update Intended Trajectory

Intended

trajectory

One cycle to

gather intent (TC reports)


-
DRAFT
-


2
-
6


by evaluating aggregate demand information against known and forecast weather or
events that will impact NAS capacity. Based on t
his evaluation, FCM automation will
recommend a set of strategic TFM actions. The aggregated demand information will be
developed from information sources including: historical demand data, scheduled
flights, early intent information from NAS operators (
including Collaborative Decision
Making early intent messages), filed flight plans, and amended flight plans.



Collaborative Trajectory Management Program (CTOP)


The CTOP concept
[9
]
provides NAS operators the opportunity to begin formally providing
alternate trajectory
preference information to TFM. With the implementation of CTOP, operators will be
able to submit multiple route options along with preference and constraint information
for each route via a Trajectory Options Set (TOS) message. Traff
ic managers will apply
CTOP by constructing a Flow Constraint Area (FCA) and selecting a flow rate through
the FCA. CTOP automation will apply the submitted preferences and constraint
information to issue ground delays and reroutes to meet the FCA rate.
The demand
forecast employed by CTOP will be developed via historical demand data, scheduled
flights, NAS operator submitted TOS messages, and filed flight plans, and amended
flight plans.



Integrated Departure Route Planning (IDRP)


The IDRP concept
[10
]
identifies
departure routes and departing flights that are forecast to be impacted by weather or
volume constraints in the terminal airspace in the 30 minute to two hour look ahead
timeframe. The concept also assists traffic managers in developing alterna
tive routing
options for impacted flights. This concept may also utilize TOS messages developed as
part of CTOP or similar NAS operator input.



Incremental Congestion Management (ICM)


The concept for ICM has been
documented as part of the NAS EA OV
-
6c de
velopment
[11
] as well as in various
research and concept papers
[12][13][14
]. This concept will provide traffic managers
with a capability to manage en route traffic more tactically through incremental
management on a flight specific basis in the 30


120

minute look
-
ahead timeframe.
Flights that are utilizing sectors with forecast congestion will be identified. ICM
automation will propose a resolution designed to reduce the probability of congestion via
and ground delays. The demand, capacity, and cong
estion models will all provide
probabilistic forecasts as a means for accounting for uncertainty. This concept may also
utilize TOS messages developed as part of CTOP or similar NAS operator input.



En Route Flow Planning Tool (EFPT)


The EFPT concept
[15
] will serve as an even
more tactical en route management capability designed to operate in the 30


90 minute
look
-
ahead time frame. The concept will identify flights that utilize route segments that
are forecast to be impacted by convective weather. Th
e intended trajectory of each flight
within a traffic manager defined area of interest will be probed against a three
-
dimensional representation of forecast weather that would lead pilots to deviate
[16
].

With these concepts in mind, three phases to the tr
ajectory life cycle can be defined from the
perspective of Strategic TFM:


-
DRAFT
-


2
-
7




Scheduled flights



Planned flights with intent information



Filed flight plans (including flight plan amendments and trajectory updates)

These three phases have varying impacts across
different concepts and capabilities that are
proposed for the mid
-
term, but as previously assumed [
2
], the filing of a flight plan will serve as
the initial basis of a shared NAS
-
wide trajectory. Thus, as each capability is discussed in further
detail, sp
ecial attention will be placed on the performance of functions after a flight plan has
been filed.

The NAS function that will be performed by each TFM capability on the common trajectory is
Resource Utilization as defined in prev
ious NAS
-
wide trajectory wo
rk [
1]. The IDRP capability
will also perform a Constraint Evaluation function on individual flight trajectories. While the
specific needs of each capability vary to a degree, a common group of information elements are
expected to be utilized in the mid
-
t
erm. These common information elements correspond to the
information utilized by the current TFMS trajectory model and are listed in
Table
1

along with
their current
source and a potential alternate source.

Table
1



Current Information Elements Utilized by TFMS For Trajectory Modeling

Information Element

Current
Originator

Mid
-
Term
Alternative Sources

Origin

FOC via OAG Schedule / Historical Data /
FOC via
CDM Early Intent Information /
FOC via
Filed Flight Plan

FOC via UFPF

Destination

FOC via OAG Schedule / Historical Data /
FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Estimated Time of
Departure (ETD)

FOC via OAG Schedule / Historical Data /
FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Estimated Time of
Arrival (ETA)

FOC via OAG Schedule / Historical Data /
FOC via CDM Early Intent Info
rmation /
FOC via Filed Flight Plan

FOC via UFPF

Aircraft Type

FOC via OAG Schedule / Historical Data /
FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Crew Qualifications

FOC via
CDM Early Intent Information /
FOC via
Filed

Flight Plan

FOC via UFPF

Aircraft Capabilities

FOC via
CDM Early Intent Information /
FOC via
Filed Flight Plan

FOC via UFPF

Route

FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF


-
DRAFT
-


2
-
8


Requested Cruise
Altitude

FOC via CDM Early

Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Requested Cruise Speed

FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Earliest Runway Time of
Departure (ERTD)

FOC via CDM Early Intent Information /
FOC via File
d Flight Plan

FOC via UFPF

Earliest Runway Time of
Arrival (ERTA)

FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Estimated Elapsed Time
(EET)

FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF

Gate Time of Departure

FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF,
TFDM

Gate Time of Arrival

FOC via CDM Early Intent Information /
FOC via Filed Flight Plan

FOC via UFPF,
TFDM

Applied Adaptation

HOST / ERAM

ERAM

via UF
PF

Aircraft Performance
Characteristics


Histori
cal Data based on aircraft type

FOC via UFPF,
Aircraft via
DataLink

Wind Data

RUC?

NNEW

The most significant source of error in current
TFM trajectory calculations
occurs due to
inaccuracies in the information concerning the pushback and wheels
-
off times of flights
approaching departure
(Uncertainty in
Decision Making Reference)
. Prior to the mid
-
term,
TFMS demand models are expected to incorporate surface surveilla
nce information from Airport
Surface Detection Equipment Model X (ASDE
-
X) including pushback time, current surface
position for a flight, departure queue length, and actual wheels
-
off time. Using the pushback
time, current surface position, and departure
queue length, TFMS will calculate a predicted
wheels
-
off time.

Table
2

-

Surface Information Elements

Surface
Information Element

Pre Mid
-
Term Source

Mid
-
Term
Alternative Sources

Actual Pushback Time

ASDE
-
X

TFDM

Current Surface
Position

ASDE
-
X

TFDM

Departure Queue Length

ASDE
-
X

TFDM

In the following sub
-
sections, each of the TFM capabilities previously mentioned and the
impacts they may place on trajectory requirements will be described in further detail. When
possible, a list

of further information elements that are known or expected to be utilized by these
capabilities in applying the various NAS functions will be included.


-
DRAFT
-


2
-
9


2.2.1

FCM

In applying the Resource Utilization function, the FCM capability will take known information
about

individual flights and aggregate the information to construct a network flow model
representing forecast demand across the NAS. This network flow model will be constructed of
nodes and arcs, each representing individual or multiple NAS resources. “Sink
nodes” and
“source nodes” will likely represent airports or groups of airports, while “transshipment nodes”
will represent airspace resources such as sectors, routes, or fixes. This model will primarily
provide forecast demand loading for airports and sec
tors during the strategic time frame

[8
].

The FCM capability will utilize the origin, destination, estimated time of departure (ETD), and
estimated time of arrival (ETA) along with historical routing data to calculate likely paths
through the model
for agg
regated groups of flights
. This information will be accumulated from
multiple sources with initial information being acquired from historical data from previous
flights and the OAG Schedule. As flight planning intent information provided by the NAS
op
erator, filed flight plans, and post
-
departure updates to the both the actual and intended
trajectory become available, this information will be utilized to update the FCM network flow
model. As each piece of information is ingested by FCM, it will assi
gn a value describing the
uncertainty associated with the source of the information. This estimation of uncertainty will be
included in calculations that utilize that information element.

Somewhat obviously, improved accuracy in individual information i
tems utilized by the FCM
network model (e.g., estimated time of departure (ETD)) will improve the accuracy of FCM
demand forecasts for airports and sectors. Though FCM will not calculate individual flight
trajectories explicitly, the information contained

in the
NAS
-
wide trajectory will likely be
utilized by the FCM network model
and potential inaccuracies in this information may need to
be quantified to determine the impacts to FCM demand forecasts.

Table
3

-

Additional Informat
ion Elements for FCM

Additional
Information Element

Mid
-
Term Source

Mid
-
Term
Alternative Sources

Uncertainty of Information Sources

TBD

TBD

2.2.2

CTOP

Based on the forecast sector loadings that were observed using the FCM capability, a traffic
manager may decide to implement CTOP as a means of managing traffic demand during the
strategic time frame. As CTOP will be managing flights to a traffic manager
designated FCA
rate, determining the forecast of demand through the FCA will be the primary application of the
Resource Utilization function in CTOP. In addition to the information elements already utilized
by TFMS in modeling trajectories, CTOP will util
ize
trajectory preference information
submitted
by NAS operators FOCs to develop resolutions that meet the rate of demand set for the FCA.
CTOP will probe the intended trajectory for a flight against the geographic and temporal
definitions of an FCA to

determine the flight’s occupancy times within the FCA. Aside from the
submission of the additional trajectory preference information submitted by NAS operators, the

-
DRAFT
-


2
-
10


CTOP concept makes no additional assumptions concerning changes in trajectory information

supplied to TFMS.

Table
4

-

Additional Information Elements for CTOP

Additional
Information
Element

Mid
-
Term Source

Mid
-
Term
Alternative
Sources

Trajectory Options Set (TOS
)

FOC via CDM
TOS
Message

FOC via UFPF


2.2.3

IDRP

The IDRP capability will be used to manage traffic demand over departure fixes and departure
routes in the terminal airspace up to 30
-
45 minutes look
-
ahead time. This will require
calculation of traffic demand over individual departure fixes and routes an
d will apply the
Resource Utilization NAS function. It has been recognized in discussion of the IDRP concept
that a lack of accuracy exists in the current TFMS demand profile that could reduce the
effectiveness of the concept as well as the trust of traff
ic managers in the
results [10
], as such
IDRP will incorporate additional features in its trajectory model. One origin of this inaccuracy
can be traced to the method with which TFMS models the aircraft trajectory on the surface to
calculate a wheels
-
off ti
me. Phase 1 of the IDRP concept will model the wheels
-
off time by
adding an estimated taxi
-
time to the filed departure time or current Expect Departure Clearance
Time (EDCT) in the case of flights delayed by TFM TMI

[10
].

For Phase 2 of IDRP, it has been

recommended as a temporary measure that Airport Surface
Detection Equipment Model X (ASDE
-
X) data that will be available through the TFMS hub be
used to improve the wheels
-
off time prediction accuracy by updating TFMS with the actual
pushback time and inc
luding departure queue length as a factor in calculating the estimated taxi
-
time. A longer term solution was suggested by applying a concept like Tower Flight Data
Manager to ensure better consistency among the information provided to all parties involved

(ATCT, TRACON, and ARTCC). A common model of the surface trajectory may also achieve
the desired improvement in accuracy, though as stated earlier the only need for a surface
trajectory model for IDRP is to calculate a predicted wheels
-
off time. Thus, a
n alternative to
fulfill the IDRP need of improved accuracy in wheels
-
off time may be for surface automation to
provide the predicted wheels
-
off time directly to TFMS or IDRP.

In modeling the predicted airborne trajectory (prior to departure), it has been recommended
[10
]
that the IDRP Phase 1 trajectory model use historical data as the primary information source for
route, cruise speed, and altitude prior to filing of the fligh
t plan. Once a flight plan has been
filed, these information elements will be replaced by the corresponding information contained in
the filed flight plan. Applying aircraft type performance data, wind forecasts, and modeled
LOAs and SOPs along with this

trajectory information, the
IDRP Phase 1 capability will
calculate individual airborne trajectories

and aggregate these individual trajectories into demand
forecasts for departure routes and fixes. A
Weather Avoidance Field (WAF) [15
] is used to
forec
ast a 3
-
dimensional field where flights are likely to deviate due to weather. Each trajectory

-
DRAFT
-


2
-
11


is examined by fix
-
to
-
fix segments and probed against the WAF. Should any parts of the
trajectory fail to avoid the WAF, these segments will be identified as co
nstrained and the flight
will be recommended for a traffic management resolution.

IDRP also performs a Constraint Evaluation function to determine which flights are eligible for
management. First IDRP determines the flights that utilize Route Availability

Planning Tool
(RAPT) “departure routes.” These routes were defined based on statistical analysis of historical
flight track data from fair
-
weather
operations in the target area [10
]. By applying a clustering
algorithm and removing outliers flights were
grouped into a nominal set of “departure routes”
defined as a centerline between the edges of the flows. Using the trajectory model previously
described, flights with a predicted trajectory within approximately 20km of the centerline are
matched to the de
parture route. From this set, only flights that are predicted to climb to altitudes
of FL300 or higher within the first 45 minutes of flight are considered eligible for IDRP.

A question remains in the mid
-
term over the management of departures. While ATC
Ts will
remain responsible for developing and managing a departure queue, the overlying ARTCC will
retain responsibility for managing airspace congestion and constraints on departure routes. Due
to the highly dynamic nature of tactical adjustments to depa
rting flights, situations will likely
continue to exist where the departure queue developed by the ATCT and the reroutes and other
TMI planned by the ARTCC conflict. Future versions of IDRP will likely integrate a sector
capacity modeling capability that
utilizes both forecast weather and traffic demand to determine
forecast sector capacities. These advancements have yet to be defined but may place additional
requirements on the NAS
-
wide trajectory model.

Table
5

-

Additional Infor
mation Elements for IDRP

Additional
Information Element

Mid
-
Term
Source

Mid
-
Term
Alternative
Sources

Published LOA and SOP Data

SWIM

???

Weather Information Supporting WAF
Development

CIWS

NNEW

2.2.4

ICM

As previously stated, ICM will identify flights that

are projected to utilize sectors during time
periods with forecast congestion. This process will rely on the Resource Utilization NAS
function.

Also, under the proposed sector management method, ICM will explicitly account for
uncertainty in both demand
and capacity forecasts by applying probabilistic models to develop
each and convolving them to develop a probabilistic congestion model
[12
]. While neither the
demand or capacity models, and by extension the requirements for trajectory modeling that ICM
w
ill levy, has been defined as of yet, a number of assumptions can be made concerning the NAS
functions to be performed.


-
DRAFT
-


2
-
12


ICM will identify sectors that are forecast to be congested by 15 minute time bins. This
congestion forecast will be developed by convo
lving a probabilistic demand forecast with a
probabilistic capacity forecast based on weather impact
[14
]. Previous research suggests that the
“distribution of traffic demand in en route sectors [will be] predicted based on flight plans (or
down
-
linked ai
rcraft data), track data, wind forecasts, aircraft performance data, and other
adapted elements.”

Table
6

-

Additional Information Elements for ICM

Additional
Information Element

Mid
-
Term Source

Mid
-
Term
Alternative Sources

Uncertainty of Information Sources

TBD

TBD

2.2.5

EFPT

EFPT will identify flights that are projected to utilize routes during time periods with forecast
impacts by convective weather. As such, the EFPT concept will apply the Resource Utilization
NAS function
.

Under the EFPT concept, the utilization of routes will need to be determined from 30 minutes


90 minutes look
-
ahead time. No assumptions have yet been made
concerning the trajectory
prediction requirements for individual flights
beyond the
trajectory currently available in TFMS
[8]. Flights that are forecast to be impacted by convective weather on their current predicted
route

will be identified. As for IDRP, in EFPT a WAF

[15
] is used to forecast a 3
-
dimensional
field where flights are li
kely to deviate due to weather. Each trajectory is examined by fix
-
to
-
fix
segments and probed against the WAF. Should any parts of the trajectory fail to avoid the WAF,
these segments will be identified as constrained and the flight will be recommended f
or a traffic
management resolutions.

Table
7

-

Additional Information Elements for EFPT

Additional
Information Element

Mid
-
Term
Source

Mid
-
Term
Alternative
Sources

Weather Information Supporting WAF
Development

CIWS

NNEW

2.2.6

Summary

As detailed, the primary changes in information that may be utilized by planned strategic TFM
capabilities can be divided into four categories: current information utilized by TFMS that is
acquired through a new source (primarily UFPF), surface status in
formation, weather
information supporting the development of a 3
-
dimensional WAF, and the estimated uncertainty
of each information element depending on the information source.


-
DRAFT
-


2
-
13


2.3

Surface Operations

Surface Trajectory
-
Based Operations (STBO) are expected to evolve towards an operation based
upon individual flight surface trajectories. Until the end of the NextGen Mid
-
Term,
sevral
capabilities

are expected to be implemented

towards th
is objective as

d
escribed below.

While the full surface trajectory has little reason to be shared with other ANSP Air Traffic
Management domains, certain
information items forming part of

the surface trajectory and the
airborne trajectory must be managed for consistency.

Other dynamic information provided by the
surface domain will have an impact on the airborne trajectory, such as airport configuration.

Airport Configuration Management

The NAS
-
wide strategic trajectory is used to estimate arrival and departure demand u
sed in the
setting of airport configurations. Predicted airport configurations would be used as input to the
flight planning process and affects the departure and arrival portion of the trajectory, allowable
runway choices, and taxi times. Only large err
ors in arrival or departure times persisting over
many flights would alter the output of the ACM. However, changes in forecast configuration
will result in updates to trajectories for many flights. The issue of the stability of this interaction
is outsid
e the scope of this effort.

Collabora
tive Departure Queue Management

The NAS
-
wide strategic trajectory is used to provide an estimate for both the departure and
arrival aggregate demand at airports with CDQM. These are used to predict the carrier
-
specif
ic
allocation of departures (or delay to minor participants), which in turn is used by the operators to
assign a scheduled off
-
block time (SOBT). The SOBT updates the NAS
-
wide strategic
trajectory forecast departure time.

Departure Runway Assignment

Aggregate demand data is obtained from the NAS
-
Wide strategic trajectories and combined with
flight
-
specific runway constraint / preference information and pushback time estimates to
provide an assigned departure runway. During flight planning and post
-
fi
ling, the DRA
capability is expected to provide updates of departure runways, thereby resulting in updates to
the NAS
-
wide strategic trajectory. How this affects the stability of the airborne trajectory
(departure time and routing) remains to be determined
, and is outside the scope of this effort.

Departure Sequencing


A departure sequence recommended to the controller, taking into account demand, APREQ times
and controlled departure times will affect the NAS
-
Wide strategic trajectory departure time.

Two
-
Dimensional Taxi Route Generation


In concert with other surface operations capabilities, 2
-
D Taxi Route Generation is expected to
provide input to the estimate of a (wheels
-
off) departure time. On arrival, accuracy of arrival
trajectory data contained in

the NAS
-
Wide strategic trajectory will impact the optimal choice of
inbound taxi path.

Surface Conformance Monitoring


-
DRAFT
-


2
-
14


The assigned taxi path is expected to be monitored for conformance using surveillance data. The
impact of conformance monitoring on a
NAS
-
Wide strat
egic trajectory appears minimal, except
subsequent to the uncommon event of non
-
conformance.

When non
-
conformance events can
alter a departure time, conformance monitoring may provide an earlier indication to automation
that the departure ti
me will be altered.

2.4

Terminal Operations

There are two trajectories that are utilized by automation (i.e., DSTs) that will exist [
19
] at the
end of the
NextGen Mid
-
Term
in the terminal area. One is a strategic trajectory (i.e., the overall
NAS trajectory) a
nd a very short term tactical trajectory (i.e., terminal specific trajectory) that is
almost completely based on surveillance information and shor
t term intent information. Current
plans do not expect

a longer look ahead tactical trajectory, such as the lo
nger look ahead tactical
trajectory that exists in en route for conflict probe. This section will descri
be relevant DSTs that
are planned for

in the terminal area and how they would utilize the given trajectories. From these
descriptions of how the traject
ories are being used by the DSTs we will infer what information

envisioned to exist in the Mid
-
T
erm could
improve

trajectories and DST performance. This
section will also describe DSTs that would enable better information sharing, with respect to
trajector
y information.


One information sharing capability that we are assuming will not exist in the terminal area at the
end of the midterm is data communications between ground and aircraft. While it is recognized
that the data communications in TRACON capabil
ity would enable more efficient information
sharing and act as an enabler for successful imp
lementation of other trajectory
-
based DSTs in the
terminal area, the current plans are not to have the capability in place in
the terminal by the end
of the M
i
d
-
T
er
m. Although a data communications capability will be present in the en route
domain in the
Mid
-
Term
.


This analysis will focus

on the automation perspective and the information that will provide
benefit to automation. So while there is other information t
hat would improve the system by the
controller having knowledge of it, that no automation perspective will be excluded from this
discussion. For example, providing a departure schedule for an arrival controller that has arrivals
utilizing the same runway w
ould help the arrival controller integrate the arrival and departure
schedules for better runway usage. But all of the benefit is gained from the controller having a
better mental model and not from automation providing decision support based on trajectory

information
.

2.4.1

Terminal
DSTs

Utilizing a Terminal Specific Trajectory

This subsection
focus
es on what DSTs are planned to

exist in the term
inal area at the end of the
Mid
-
T
erm that would utilize a terminal specific trajectory. These include Automated Termin
al
Proximity Alert (ATPA), Relative Position Indicator (RPI), and Route Conformance Monitoring.


Automated Terminal Proximity Alert

(ATPA)


-
DRAFT
-


2
-
15


ATPA is a terminal DST that will use the terminal specific trajectory to detect when a loss of
separation is expected occur between aircraft on final approach and alert the controller to that
expected loss of separation, through display of a colored cone.
Its initial implementation is
viewed to be only for longitudinal separation issues of in
-
trail aircraft. But in this timeframe the
capability will
be

extended to include checking for loss of diagonal separation between aircraft
on dependent approaches.


Re
lative Position Indicator

(RPI)

The terminal DST known as RPI as stated in [1
9
] “displays the relative position of flights on
converging paths onto a reference path” This typically is a projection of surveillance information
of an aircraft on one RNAV
procedure onto another RNAV procedure based on distance to the
merge fix. RPI can be used by arrival feeder, final position, and/or a departure controller. The
TMC can also use RPI to determine sequencing, runway load balancing and departure fix
management
. In this timeframe the DST would account for wind even though the initial (near
term) implementation of RPI would not account for wind. RPI relies mainly on surveillance data
and the knowledge of RNAV procedures. But for the wind component the terminal sp
ecific
trajectory would be used to determine appropriate projections of the surveillance information
with wind accounted for.


Route Conformance Monitoring

Conformance monitoring is a terminal DST that would use current surveillance information and
the ter
minal specific trajectory to determine when an aircraft was not conforming (based on pre
-
defined tolerances) to its RNAV SID or STAR either laterally or vertically and alert the
controller to this non
-
conformance. While the lateral conform
ance may be purel
y surveillance
-
based the vertical conformance monitoring would require the terminal specific trajectory to
determine that the aircraft was not expected to meet a RNAV procedure vertical constraint to