Report no. ETMS-TFMDI-002

**Traffic Flow Management**

**Data to Industry:**

#### Explanation of the Data {#explanation-of-the-data .unnumbered}

Version 1.0

10 August 2004

Prepared by

Volpe Center

55 Broadway

Cambridge, MA 02142

Table of Contents

[1. Introduction 3](#introduction)

[1.1. Background 3](#background)

[1.2. Purpose of this Document 3](#purpose-of-this-document)

[1.3. Use of the TFM Data 4](#use-of-the-tfm-data)

[1.4. XML Tags 4](#xml-tags)

[1.5. References 4](#references)

[2. Public Reroutes and Flight Lists
6](#public-reroutes-and-flight-lists)

[2.1. Introduction 6](#introduction-1)

[2.2. The Create Reroute Dialog Box 6](#the-create-reroute-dialog-box)

[2.3. The Reroute Definition Tab 10](#the-reroute-definition-tab)

[2.3.1. Introduction 10](#introduction-2)

[2.3.2. Flight Identification Fields 10](#flight-identification-fields)

[2.3.3. Characteristics Fields 10](#characteristics-fields)

[2.3.4. Route Information Fields: Filling in the Grids
11](#route-information-fields-filling-in-the-grids)

[2.3.5. Full Routes v. Split Routes 11](#full-routes-v.-split-routes)

[2.3.6. Filters 15](#filters)

[2.3.7. Miscellaneous Data About Reroute Segments
15](#miscellaneous-data-about-reroute-segments)

[2.4. The Flight List Tab 19](#the-flight-list-tab)

[2.5. The Advisory Tab 19](#the-advisory-tab)

[3. Public Flow Evaluation Areas/Flow Constrained Areas
21](#public-flow-evaluation-areasflow-constrained-areas)

[4. Flow Evaluation Area/Flow Constrained Area Flight Lists
21](#flow-evaluation-areaflow-constrained-area-flight-lists)

[5. Alert Data 21](#alert-data)

[6. Collaborative Convective Forecast Product
21](#collaborative-convective-forecast-product)

[7. National Convective Weather Forecast
21](#national-convective-weather-forecast)

# Introduction

## Background

Currently, the FAA provides a great deal of data to Collaborative
Decision Making (CDM) participants on the Common Constraint Situation
Display (CCSD). The CCSD, in effect, provides a map that graphically
displays current information relevant to traffic flow management (TFM)
such as flow evaluation areas (FEAs), flow constraint areas (FCAs),
reroutes, and alerts. In addition, the CCSD provides textual data about
these items, such as reroute advisories and lists of flights that are
affected. This data is jointly referred to in this document as TFM data.

The distribution of this data on the CCSD has gone part of the way
toward providing common situational awareness to NAS users, but there
are two shortcomings.

-   The data on the CCSD is "display-only" in that the user can, for
    example, see the FCA on the CCSD but does not have access in
    computer-readable format to the data that defines the FCA, e.g., the
    lat/lons of the corners. This means that the user cannot in an
    automated way grab this data and use it in internal applications.

-   The data is not available even in display-only mode to the Aircraft
    Situation Display to Industry (ASDI) vendors, so these vendors are
    not able to include this data in any of the products that they
    supply to the aviation community.

To deal with these two shortcomings, the FAA has decided to undertake
the program called TFM Data to Industry (TFMDI). In short, this program
will provide the TFM data in a machine-readable format to Industry,
which could then incorporate it into their tools. For example, if the
data that defines an FCA (the lat/lon of the corners, upper and lower
altitudes, filtering, and so forth) were provided, then Industry could
incorporate FCAs into their own displays and other tools. This would
improve the tools, promote common situational awareness, and perhaps
provide this data to a much wider audience.

## Purpose of this Document

A interface control document is being provided that gives detailed
formatting information to industry users of the TFM data; see the
reference in section 1.5. If, however, industry users are to make
satisfactory use of this data, they need to know much more than how the
data is formatted; that is, they need to know what the data means so
that they can incorporate it into their applications in a meaningful and
useful way. The purpose of this document is to provide additional
understanding of this data. Since traffic flow management is both
complicated and rapidly changing, it should not be expected that this
document is a totally comprehensive guide to this data, but it will
provide information that the industry user might not otherwise have
ready access to.

The current version of this document only describes the data for public
reroutes. As more types of TFM data become available, this document will
be expanded to cover them.

## Use of the TFM Data

It should be stressed that it is the responsibility of the Industry user
how to learn the characteristics of the TFM data and to determine how to
use it properly. It is not the responsibility of the FAA or Volpe to
tell Industry how to use this data, to evaluate the industry products,
or to attempt to exert any kind of quality control; it is up to the
private sector to determine how the data should be used and to police
the quality of the products.

In short, this document can be used as a source of information, but it
is still up to industry to decide how to use the data.

There is, however, one point that industry developers might keep in
mind, and that is the value of providing common situational awareness,
which means not only that everyone is looking at the same data but also
looking at it displayed in similar ways. The FAA views this data on the
Traffic Situation Display, and much of industry currently views it on
the Common Constraint Situation Display, which is patterned after the
TSD. If industry tools look like the TSD and the CCSD, this will promote
common situational awareness, so industry will want to consider the
degree to which its display tools should look like these two FAA tools.
Industry can see how this data is displayed on the CCSD by examining the
screenshots and text in the CCSD user manual; see Section 1.5

## XML Tags

The TFM data is for the most part provided in the XML language. A
central feature of this language is that it marks each piece of data
with what is called a tag. An example will make this clear. In a TFM
data XML file one would see the aircraft ID as

\<ACID\>COA218\</ACID\>

\<ACID\> is the opening tag, and \</ACID\> is the closing tag. The data
is between the two tags. This means that a program finds \<ACID\>, and
it knows that everything that it finds until it reaches \</ACID\>
represents the aircraft ID.

The interface control document (see Section 1.5) uses tags to describe
the format of the document. So that the data referred to in this
document can be related to the data in the ICD, the tags will be used
here to indicate the data that is being discussed. The reader should
consult the ICD not only for the formatting but also for the values than
each tag might take; this document will not try to describe every value.
The reader who is not interested in the formatting but only wants to
learn about the data can ignore these tags in this document.

## References

"Traffic Flow Management Data to Industry: Overview," Volpe Center,
report no. ETMS-TFMDI-001, ver. 1.0, 10 August 2004. This document
explains the rationale for the TFM Data to Industry program and spells
out the principles that guide it.

"Traffic Flow Management Data to Industry: Interface Control Document,"
Volpe Center, report no. ETMS-TFMDI-003, ver. 1.0, 10 August 2004. This
document provides detailed information, e.g., formatting and allowed
values, that is needed by software developers who are writing
applications that make use of the TFM data. This document is referred to
as the ICD.

[]{.mark}

To download the latest versions of the documents listed here as well as
others such as sample data files, go to the Traffic Flow Management Data
to Industry web page at <http://www.fly.faa.gov/ASDI/asdi.html>

For access to the coded departure routes, see
<http://www.fly.faa.gov/Products/Coded_Departure_Routes/coded_departure_routes.html>

To download the National Playbook, go to <http://www.fly.faa.gov/ois/>

To download the CCSD user manual, go to
<http://www.metronaviation.com/cdm/products/ccsd.html>

# Public Reroutes and Flight Lists

## Introduction

The ideal is that every National Airspace System (NAS) user files the
route that it wants to fly, and it then flies that route. It might be
the case, however, that congestion in the NAS prevents the NAS user from
flying the route that it wants to fly. This congestion might arise
because of bad weather, extremely heavy traffic, a failed navaid, or any
number of other reasons. If this congestion is of more than local
significance, then the severe weather specialists at the Air Traffic
Control System Command Center (ATCSCC, or Command Center for short)
might issue a public reroute. The essence of a public reroute is that it
specifies which flights are affected and which reroutes they should
take. The reason why a public reroute is issued is to organize the
system's response to the congestion so that it will be dealt with in an
efficient and equitable way.

The Traffic Situation Display (TSD) is the main user interface to ETMS;
it shows aviation activity graphically, and it also provides a number of
tools. One of these tools is the Create Reroute dialog box. A severe
weather specialist at the Command Center uses this dialog box to define
and issue a public reroute.

The expositional strategy followed in this section is to let the reader
look over the shoulder of a severe weather specialist as he or she uses
the Create Reroute dialog box to define a public reroute and then issue
an advisory; this shows how the public reroute data is generated. The
hope is that showing how the public reroute data arises from the actions
of a severe weather specialist will help the reader to understand this
data. The goal is to put the Industry reader in a position to make good
use of this data.

## The Create Reroute Dialog Box

When the severe weather specialist issues the TSD's Create Reroute
command, he or she will then see the Create Reroute dialog box as shown
in Figure 2-1. It is seen that this dialog box has three tabs, and it
opens on the "Reroute Definition" tab, which is used to provide the
basic information about the reroute. If the specialist clicks the
"Flight List" tab, then the user sees the blank flight list shown in
Figure 2-2; this list, when filled in, shows the flights affected by the
reroute. Finally, if the specialist clicks the "Advisory" tab, then the
user sees the template in Figure 2-3 that is filled in to produce the
text that goes into the public reroute advisory. The information from
these three tabs is included in the TFM Data to Industry. The discussion
below is organized by these three tabs.

Once the severe weather specialist has filled out all three tabs as
desired, he or she clicks the "Send" button at the bottom of the dialog
box, and this causes the public reroute advisory to be sent to NAS users
and FAA facilities, who then have the responsibility of implementing
this advisory, i.e., of seeing that the designated aircraft fly the
specified reroutes; this implementation is beyond the scope of this
document and will not be discussed further here.

Note: Fields in this dialog box that are marked with an asterisk are
required fields that the severe weather specialist must fill in. Also,
this document is not a tutorial on how to use the Create Reroute

![](media/image1.png){width="7.586805555555555in"
height="5.991666666666666in"}

Figure 2-1: Create Reroute Dialog Box: Reroute Definition Tab

![](media/image2.png){width="7.565972222222222in"
height="5.991666666666666in"}

Figure 2-2: Create Reroute Dialog Box: Flight List Tab

![](media/image3.png){width="7.565972222222222in"
height="5.991666666666666in"}

Figure 2-3: Create Reroute Dialog Box: Advisory Tab

dialog box; aspects of this dialog box that do not affect the TFM data
provided to Industry, e.g., the options to sort the order in which
flights are displayed in the flight list, are not discussed here.

## The Reroute Definition Tab

### Introduction

The severe weather specialist uses the Reroute Definition tab to specify
the details of the flights that are subject to the reroute and also to
specify the reroutes that they should take. Each area of this tab will
be explained. To get the most out of this discussion, the user should
relate the text below to the picture of the Reroute Definition tab in
Figure 2-1. As explained above, the tags are shown so that the reader
can relate the discussion here to the fields shown in the ICD. A reader
not interested in details of programming can skip the tags.

### Flight Identification Fields

The first item is to indicate the start time \<REROUTE_STARTTIME\> and
stop time \<REROUTE_ENDTIME\> of the reroute. There are three possible
interpretations of these times; which interpretation is being used in
indicated by \<REROUTE_TIMETYPE\>. The first interpretation is that a
flight is covered by this reroute if its actual or predicted wheels-up
time is between the start time and the stop time. The second
interpretation is that a flight is covered by this reroute if its
predicted wheels-down time is between the start time and the stop time.

The third interpretation is a little more involved. The severe weather
specialist might indicate that this reroute is based on a
flow-constrained area (FCA). An FCA is a designated volume of airspace
that is relevant to the reroute; for example, an FCA might be airspace
that surrounds convective weather. The goal might be for flights that
intersect an FCA to be rerouted out of the FCA. For a fuller description
of FCAs, see section 3 (to be provided in a later version of this
document). If the severe weather specialist indicates that an FCA is to
be used as the basis for this reroute, then the name of the FCA
\<FCA_NAME\> is included in the TFM data; the start \<FCA_STARTTIME\>
and stop \<FCA_ENDTIME\> times are taken from the definition of the FCA;
these cannot be changed within the Create Reroute dialog box.

The severe weather specialist must also indicate which flights
\<AIRBORNE\> are included in the reroute, where the choices are to
include only flights that are airborne when the reroute is issued, only
the flights that are not yet airborne when the reroute is issued, or all
flights.

### Characteristics Fields

The severe weather specialist gives each public reroute a name \<NAME\>
that uniquely identifies it. The domain \<DOMAIN\> will always be public
for reroutes that appear in the TFM data; the other categories are for
internal FAA use. The status \<STATUS\> can be active, which means that
this reroute is effective and should be taken into account in all
decisions, or planned, which means that this is not currently an active
reroute but that it might eventually become one; users can take the
possibility that it will become an active reroute into account in their
planning.

### Route Information Fields: Filling in the Grids

At the heart of the Create Reroute dialog box are the grids in Figure
2-1, which are used to indicate the reroutes and the flights that must
take each reroute. While a severe weather specialist could fill in these
grids by typing in by hand all the reroute information, this is
time-consuming and rarely done. Quicker ways of entering the data
automatically are:

-   Load in one or more plays from the National Playbook.

-   Load in one or more coded departure routes.

-   Load in one or more routes that the specialist has used in the past
    and has saved.

The National Playbook and coded departure routes will not be discussed
any further here since, from the point of view of the TFM data, what
matters is the data itself rather than its source. If the reader wants
to investigate the National Playbook or the coded departure routes
further, see the web sites referred to in Section 1.5. However the
specialist initially enters the data, he or she will need to fine tune
it so that it fits the particular situation being handled; the next few
sections indicate how does this fine tuning is done and how it is
represented in the TFM data.

### Full Routes v. Split Routes

The data in any one line of the grids in the Create Reroute dialog box
is called a *reroute segment*. A reroute segment might be a *full route*
or a *split route*. Understanding the difference between a full route
and a split route is critical to understanding the TFM reroute data.

Figure 2-4 shows three coded departure routes that have been loaded into
the Create Reroute dialog box to illustrate a full route. This figure
shows three reroutes from LGA \<ORIGIN\> to BOS \<DESTINATION\>. Since
three routes are given with no filtering, this means that any of the
flights from LGA to BOS will be compliant with the reroute if it takes
any of these three routes. These are called full routes since the
reroute for a city pair consists of a single string of elements on one
line. In this case, the full route goes all the way from origin to
destination, but this is not always the case.

In Figure 2-5 the BAE_2 play from the National Playbook has been loaded
into the Create Reroute dialog box to illustrate a split reroute. It is
seen that the fix BAE is the last element in the origin segments in the
top grid and also the first element in the destination segments in the
bottom grid. For example, for a flight going from MSP in ZMP to JFK, the
required route is MCW J16 BAE J70 LVZ LENDY5; any flight from MSP to JFK
that includes this route segment in its flight plan is compliant with
the reroute advisory. It is seen that by combining the origin route
segment with the destination route segment, where BAE is the point where
they join, a reroute is constructed. The BAE_2 play is shown graphically
in Figure 2-6.

A reroute such as is shown in Figure 2-5 is called a split route since
any origin segment in the top grid can be combined with any destination
segment in the bottom grid. Put another way, the origin segments fan in
to a common point, and the destination segments then fan out from this
common point. Not all split routes, however, are as simple as this
example since sometimes not all route segments will fan into and out of
a single point. Split routes can have more than one common point, so it
will not be the case that all of the origin segments will match all of
the destination segments; in this case, the route needs to be formed by
matching the last point in some origin segment with the first point in
some destination segment.

![](media/image4.png){width="7.565972222222222in"
height="5.991666666666666in"}

Figure 2-4: Example of Full Routes

![](media/image5.png){width="7.565972222222222in"
height="5.991666666666666in"}

Figure 2-5: Example of Split Routes

![](media/image6.png){width="8.372916666666667in"
height="5.998611111111111in"}

Figure 2-6: Example Split Routes Displayed on the TSD

Whether a reroute segment is a full route or part of a split route is
indicated by the \<FULL_ROUTE\> tag, wbich has three possible values.

-   FULL: Indicates that the reroute segment is a full route.

-   ORIG: Indicates that the reroute segment is a origin segment in a
    split route.

-   DEST: Indicates that the reroute segment is a destination segment in
    a split route.

For any of these values, \<ROUTE_STR\> gives the text of the reroute
segment in the Route column of Figure 2-5.

### Filters

If the severe weather specialist clicks the button just to the left of
the filter field, then the Flight Filters dialog box pops up; this is
shown in Figure 2-7. This allows the severe weather specialist to limit
the reroute segment to a particular flight set. For example, if in the
first line of the play shown in Figure 2-5 the severe weather specialist
wants to exempt all flights departing from LAX, he or she enters LAX
into the "do not depart from" fields in the Flight Filters box in Figure
2-7, clicks OK, and this filters the first reroute segment to exclude
flights departing from LAX, as shown in Figure 2-8.

The tag \<CTR_FLTR\> includes all the filter tags; see the ICD for
details. A text summary \<FLTR_SUMMARY\> describes the filters for a
reroute segment; in Figure 2-8 this text is "-LAX". This text is
redundant, but it is included to provide a human-readable description of
the filters.

### Miscellaneous Data About Reroute Segments

The severe weather specialist can choose to include or exclude any of
the route segments shown in the Create Reroute dialog box; this is done
by checking or unchecking the box at the left of the reroute segment.
For example, in Figure 2-8 the flights originating from ZSE are excluded
from the reroute. From the industry user's point of view, any reroute
segments that are excluded are not part of the reroute and can be
ignored. The \<INCLUDE\> tag indicates if a reroute segment is included.

The severe weather specialist can fill in the Type field \<ROUTE_TYPE\>
in Figure 2-6 with one of the following values.

-   NONE

-   CDR RTE

-   RERTE

-   UNKN RTE

-   UPT RTE

If the Type is NONE, ETMS parses the route and includes waypoints
\<WAYPOINT\> in the TFM data; this allows the route to be displayed. If
the Type takes on any value other than NONE, ETMS does not parse the
route and does not include waypoints in the data; the route is treated
as an uninterpreted text string. UPT RTE, which stands for a
user-preferred trajectory, means that the specialist does not specify a
route; the NAS user is left to pick any route that avoids the FCA and
that complies with any other conditions that are specified, e.g., that
the route go north of a given fix.

![](media/image7.png){width="3.8854166666666665in" height="5.59375in"}

Figure 2-7: Flight Filters Dialog Box

![](media/image8.png){width="7.565972222222222in"
height="5.991666666666666in"}

Figure 2-8: Example of a Filtered Route

![](media/image9.png){width="7.565972222222222in"
height="5.991666666666666in"}

Figure 2-9: Example of a Flight List

If in the Flight Filters dialog box in Figure 2-7 the severe weather
specialist entered any text in the "Segment Remarks" field, these are
included in \<SEG_REMARKS\>. This text can be thought of as a comment.

## The Flight List Tab

Once the severe weather specialist has filled out the Reroute Definition
tab in the Create Reroute dialog box, he or she will probably next want
to see the list of flights that are affected by this reroute. The severe
weather specialist can then click the Flight List tab to go to the empty
flight list shown in Figure 2-2. If the severe weather specialist clicks
the "Update Flight List" button, ETMS determines which flights known to
the system satisfy the criteria spelled out in the Reroute Definition
tab, and it then displays the list. Figure 2-9 shows the flight list
that was calculated for the BAE_2 play.

The severe weather specialist can inspect the flights to make sure that
these are indeed the flights that should be rerouted. If the specialist
determines that this flight list needs to be adjusted, he or she can go
back to the Reroute Definition tab, modify the definition of the
reroute, return to the Flight List tab, and update the flight list.
Also, if the specialist determines that a particular flight in the list
should not be included in the reroute, this flight can excluded by
unchecking the box at the far left of the line of data for this flight
in the Flight List; whether a flight is include or excluded from the
reroute is indicated in the tag \<INCLUDE_RTE\>.

Most advisories will have a flight list. If there is no flight list,
then the container tag \<CTR_FLIGHT_LIST\> will not be present.

## The Advisory Tab

Once the severe weather specialist is satisfied with the reroute
definitions and with the flight list, it is time to click the "Advisory"
tab and to complete the text of the advisory. The specialist needs to
select a category \<CATEGORY\>, where the possible values in the pick
list currently are:

-   CDR

-   FCA

-   INFO

-   MISC

-   NAT

-   NRP

-   PLAYBOOK

-   ROUTE

-   SHUTTLE

-   SPECOPS

-   VACAPES

New categories might be added in the future. The specialist also
indicates the Action \<ACTION\>, where the possible values in the pick
list currently are:

-   FYI: This advisory is for informational purposes only. No action is
    required from the NAS users.

-   PLN: This indicates a reroute that might be issued in the future (or
    might not, depending on the course of events). No action is required
    from the NAS users, but they can take this possible reroute into
    account in their planning if they wish.

-   RMD: This indicates reroutes that are recommend but not required. No
    action is required from the NAS users, but they should consider the
    reroutes specified in the advisory.

-   RQD: This advisory is required. All affected flights are expected to
    comply with it.

New actions might be added in the future.

Once the specialist has filled out the rest of the fields in the
advisory tab and is content with all the data shown in all the tabs, the
specialist clicks Send, and this distributes the advisory to the NAS
users and to FAA facilities. At this point the public reroute data
becomes available in the TFM Data to Industry feed.

[]{.mark}

# Public Flow Evaluation Areas/Flow Constrained Areas

To be provided later.

# Flow Evaluation Area/Flow Constrained Area Flight Lists

To be provided later.

# Alert Data

To be provide later.

# Collaborative Convective Forecast Product

To be provided later.

# National Convective Weather Forecast

To be provided later.