![](media/image1.emf){width="1.5520833333333333in"
height="1.6666666666666667in"}

**NAS STATUS INFORMATION**

**Data Items Under Review**

A partial list of the data items that will be considered is the
following. For many of these items, both current and projected data is
of interest.

**[Data on Airport and Terminal Airspace Conditions]{.underline}**

> **Runway Conditions**

-   Low level wind shear.

-   Braking action.

-   Runway contamination.

-   Departure delays.

-   Active arrival runway(s).

-   Active departure runway(s).

-   Airport demand vs. capacity, both current and projected (ETMS
    Monitor/Alert data).

-   Navaid outages.

-   RVR.

-   Surface Movement Advisor data.

-   Runway and taxiway maintenance.

-   Field condition reports.

    **Air Traffic Control Restrictions and Traffic Information**

-   EFC data (holding times for an airport).

-   Convective activity, e.g., ITWS and TDWR data.

-   Digital ATIS.

-   Metering at arrival fix.

-   Noise data.

-   CTAS data.

    **[Data on En Route Airspace Weather]{.underline}**

-   Severe turbulence.

-   Severe icing.

    **Air Traffic Control Restrictions and Traffic Information**

-   Forecast airborne holding time.

-   SWAP plans.

-   SUA status.

-   Sector/Center constraints.

-   Miles-in-trail.

-   Reroutings due to traffic.

-   Sector loadings.

-   GPS data, e.g., outages.

-   Loading of oceanic tracks.

    **[Data on Aircraft Capabilities]{.underline}**

-   Aircraft capabilities.

    **Miscellaneous**

-   NOTAM(D).

-   NOTAM(L).

-   FDC NOTAMs.

-   Military NOTAMs.

-   International NOTAMs.

-   "New Age" flight plan data, as defined by RTCA169 WG 5.

-   Flights changing emergency transponder codes.

-   Flight plan destination change alerts.

-   Airline prioritization of flight arrivals at a station.

-   Airline prioritization of flight departures at a station.

-   Advisories.

    **NAS Status Information**

    **Data Items Under Review - cont'd.**

    **Table of Contents**

    Low Level Windshear Alerting System (LLWAS)
    [1](#low-level-windshear-alerting-system-llwas)Braking Action
    [3](#braking-action)Airport Surface Movement Conditions
    [5](#airport-surface-movement-conditions)Departure Delays, Actual
    Departure Delays.
    [9](#departure-delays-actual-departure-delays.)Active Runway, Active
    Arrival Runways, Active Departure Runways, "The Active"
    [11](#active-runway-active-arrival-runways-active-departure-runways-the-active)Airport
    Demand and Capacity (current and predicted)
    [13](#airport-demand-and-capacity-current-and-predicted)NAS Outages
    [16](#nas-outages)Runway Visual Range (RVR)
    [18](#runway-visual-range-rvr)Surface Movement Advisor (SMA)
    [20](#surface-movement-advisor-sma)Local Notams, Distant Notams,
    Field Condition Reports, Surface Guidance Control and Movement
    (SMCG) Implementation Notices
    [23](#local-notams-distant-notams-field-condition-reports-surface-guidance-control-and-movement-smcg-implementation-notices)Forecasted
    and Existing Airborne Holding/Expect Further Clearance (EFC)
    [25](#forecasted-and-existing-airborne-holdingexpect-further-clearance-efc)National
    Convective Weather Forecast Product
    [27](#national-convective-weather-forecast-product)Digital Automatic
    Terminal Information Service (Digital ATIS/D-ATIS)
    [29](#digital-automatic-terminal-information-service-digital-atisd-atis)Metering
    [31](#metering)Center-TRACON Automation System (CTAS)
    [34](#center-tracon-automation-system-ctas)Severe Turbulence and
    Severe Icing [36](#severe-turbulence-and-severe-icing)Other Names :
    Severe CAT, Extreme Turbulence
    [36](#other-names-severe-cat-extreme-turbulence)Integrated
    Turbulence Detection and Forecast Product(s)
    [40](#integrated-turbulence-detection-and-forecast-products)Operational
    De-icing and Snowfall Accumulation Product
    [43](#operational-de-icing-and-snowfall-accumulation-product)Severe
    Weather Avoidance Program (SWAP) Plans
    [45](#severe-weather-avoidance-program-swap-plans)Special Use
    Airspace (SUA) status.
    [47](#special-use-airspace-sua-status.)Predicted Demand and Capacity
    for Sectors and Fixes
    [49](#predicted-demand-and-capacity-for-sectors-and-fixes)Miles-in-Trail
    (MIT) Restrictions [53](#miles-in-trail-mit-restrictions)Active
    Re-Routes [55](#active-re-routes)Global Positioning System (GPS)
    Reliability Information
    [57](#global-positioning-system-gps-reliability-information)Oceanic
    Demand (Track Loading by time)
    [59](#oceanic-demand-track-loading-by-time)Aircraft Capabilities
    [61](#aircraft-capabilities)Distant Notice to Airmen (NOTAM D)
    [64](#distant-notice-to-airmen-notam-d)Local Notice to Airmen
    (NOTAM L) [66](#local-notice-to-airmen-notam-l)Flight Data Center
    Notice to Airmen (FDC NOTAM)
    [68](#flight-data-center-notice-to-airmen-fdc-notam)Military Notice
    to Airmen (Military NOTAM)
    [70](#military-notice-to-airmen-military-notam)International Notice
    to Airmen (INTL NOTAM)
    [73](#international-notice-to-airmen-intl-notam)Airline Arrival
    Prioritization [76](#airline-arrival-prioritization)ATCSCC Air
    Traffic Management Advisory Messages
    [79](#atcscc-air-traffic-management-advisory-messages)Collaborative
    Advisory [79](#collaborative-advisory)Weather Re-Route messages
    [79](#weather-re-route-messages)Airborne Icing Aviation Weather Data
    Element [82](#airborne-icing-aviation-weather-data-element)

# Low Level Windshear Alerting System (LLWAS) {#low-level-windshear-alerting-system-llwas .unnumbered}

**[Description of Data Item]{.underline}**

Low level wind shear refers to a weather condition in which wind speed
or direction changes abruptly within a small horizontal or vertical
distance. This condition is of interest because it can produce
fluctuations in airspeed which are hazardous to aircraft operating at
low altitude. The FAA's Low Level Windshear Alerting System (LLWAS)
monitors a collection of sensors located around an airport and warns ATC
if a large difference in either wind direction or speed is detected.
LLWAS operates on a 10 second update cycle, providing a wind speed and
direction for each sensor, plus a center field average of the readings.

**[Benefits]{.underline}**

LLWAS information is currently displayed only within the local ATC
tower. Warnings are verbally communicated to arriving and departing
aircraft as necessary. Real-time publication of this information to AOCs
and others would allow earlier warning of potential shear conditions
than is currently available by waiting until aircraft contact the
airport tower. The optimum update rate and amount of warning which would
be operationally useful is a topic for study, as wind shear is typically
a transient condition.

LLWAS data is particularly useful to pilots and dispatchers, and can
also be used by ATC for planning and advisory purposes. It can be used
to determine whether a flight should attempt an approach or departure,
or perhaps wait until the wind conditions have improved. Numerous
accidents have been attributed to windshear, so there is a clear safety
benefit to be obtained by avoiding serious windshear encounters.

**[Source of the Data]{.underline}**

LLWAS is displayed within airport towers via an FAA PDP-11 minicomputer
which provides a digital interface capability. Making the information
available across AOCNet requires that the information be extracted from
the tower system and forwarded to an AOCNet server through some
communications mechanism. One possible path would be to ARINC via the
Tower Data Link System connection used for Pre-Departure Clearance (PDC)
delivery, but that solution is restricted to PDC-equipped airports. At
other airports, a server could be established to collect local data such
as LLWAS and export it to ADTN2000 or NADIN as a path to ARINC and
AOCNet.

**[Nature of the Data]{.underline}**

LLWAS sensors update continuously, with logic applied to produce an
alert when conditions appear to be likely to produce windshear
encounters. In order to avoid sending excessive updates across the
network, it would be wise to apply some logic which filters out
non-alarm conditions and reports only when hazardous conditions exist or
dissipate.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

LLWAS already presents a digital interface containing formatted data, so
the major problem is in establishing a path from local tower equipment
to AOCNet. There are a variety of options available, with one
possibility being a connection to the ARINC TDLS present at most major
towers. This would make the information available to ARINC and therefore
more easily distributable to AOCNet users. FAA communications paths such
as LINCS can also be used, but this requires allocation of bandwidth,
internal wiring, and the provision of FAA communication equipment and
labor.

**[Other Issues]{.underline}**

LLWAS information is time critical. Minimizing the length of time it
takes to collect and distribute rapidly changing data such as LLWAS
should be a long-term goal of collaboration studies.

By FAR the air carrier through its AOC is responsible for advising its
flights enroute of any conditions which may adversely affect the safety
of flight (14 CFR 121.601) . "Rapid and reliable" communication between
the AOC dispatcher and the PIC is required by FAR and every air carrier
meets that requirement by law (14 CFR 121.99). The rapid and reliable
delivery of LLWAS and other safety critical information to the AOC will
allow the carrier to meet its regulatory and safety requirements through
existing means. ATC does provide weather information as able but several
air carrier accidents involving wind shear had as a contributing factor
the PIC not receiving LLWAS information that was available locally.

# Braking Action {#braking-action .unnumbered}

**[Description of Item]{.underline}**

Braking Action Coefficient of Friction. The ratio of the tangential
force needed to maintain uniform relative motion between two contacting
surfaces (aircraft tires to the pavement surface) to the perpendicular
force holding them in contact (distributed aircraft weight to the
aircraft tire area). The coefficient is denoted by the Greek letter Mu.
It is a simple means used to quantify the relative slipperiness of
pavement surfaces. Friction values range from zero to 100 where zero is
the lowest friction value and 100 is the maximum friction value
obtainable.

**[Benefits]{.underline}**

Accurate, frequent, and timely reports of braking action contribute to
the safety of flight. FAR 121.601 (a) (c) require that the aircraft
dispatcher apprise the pilot in command of conditions and keep the pilot
updated when changes occur. The tower Air Traffic Controller is also
required to provide the pilot with braking action advisories. Individual
airlines obtain braking action reports and maintain them in their own
field condition reporting systems. The timely transmittal of braking
action information among the airlines would enhance the safety of
flight. Every winter season air carrier aircraft encounter runway
conditions that lead to incidents.

**[Source of the Data]{.underline}**

Braking action data is gathered either from a pilot or a ground source.
Reports from a ground source are communicated to the ATC tower which
then has the responsibility to advise aircraft. ATC may also solicit
braking action reports from inbound flights. Pilot braking action
reports as well as MU meter reports may be stored in each airline\'s
data base.

**[Nature of the Data]{.underline}**

Pilot braking action reports include the aircraft time, the runway or
other airport surface, the time, and the reported condition. Pilot
braking action reports are subjective. Airport ground source reports are
reported in Mu meter readings or as RCR readings or pilot reports of
Good, Fair, Poor, or Nil.

Mu-meter and RCR decelerometer reports are numeric and come from the
airport authorities. Pilot reports are subjective and based on braking
action experienced by that pilot in that type of aircraft.

Mu-meter Readings.40 and above = Good

.36 to .39 = Ice and Snow Fair to Good

.30 to .35 = Ice and Snow Fair

.26 to .29 = Ice and Snow Fair to Poor

.25 and below = Ice and Snow Poor

.30 to .39 = Water and Slush Fair

.29 and below = Water and Slush Poor

RCR Readings

5 and Below = Nil

6 to 12 = Fair to Poor

13 to 18 = Fair

19 to 23 = Fair to Good

24 and above = Good

Pilot Reports

BRAG = Good

BRAF = Fair

BRAP = Poor

BRAN = nil

**[What Must be Done to get this Data on AOCNet?]{.underline}**

In order to transmit the airline information on the AOCNet the airlines
need to bridge their current systems to the AOCNet. ATC and/or airport
operators would also have to be able to make entries into a system that
would bridge directly to the AOCNet. Consideration should be given to
adopting a common format such as the European SNOWTAM to disseminate
this information.

# Airport Surface Movement Conditions {#airport-surface-movement-conditions .unnumbered}

*(to include field conditions, landing surface conditions, runway
contamination, taxiway conditions, apron and ramp conditions)*

**[Description of Item]{.underline}**

Wet runway conditions, or the presence of measurable amounts of standing
water, wet or dry snow, ice, slush on airport surfaces affects airport
and airline operations. Wet or contaminated conditions of the landing
surfaces and the contamination or obstruction of taxiway, ramp, and
apron surfaces reduce airport acceptance rates and thereby cause delays
and/or cancellations.

The accurate reporting of surface contamination is necessary for the
go/no go decisions of the dispatcher and pilot in command. It is also
required for the accurate calculation of aircraft take off and landing
performance limits.

General aircraft surface operations and other safety concerns including
but not limited to the following are generally reported in the NOTAMS.
Although a significant lag time of up to 2 hours from the time the
condition first exists until the NOTAM is received by the users is not
uncommon.

Obscured Visual Aids: Runway and edge lights, taxiway lights, runway
markings, airport guidance signs, and VASI need to be free of
contaminants such as snow and ice.

Obstructions: Hazardous snow banks, drifts, wind rows, ice ridges and
other measurable obstructions should be eliminated as soon as possible.
Where they cannot be eliminated they must be accurately measured and
reported.

Navigational Aids: Any snow, ice or other contaminant which affects the
accuracy of navigational aids should be removed as soon as possible.
Failure to do so may raise landing limits with the result being
additional delays and/or cancellations and loss of airline and airport
revenue.

Parking ramp operations: Snow, ice and slush accumulations on ramps and
parking areas create safety hazards.

Common safety problems resulting from contaminated ramp operations
include but ate not limited to the following.

1\) Traction. Airline ramp personnel and their ground equipment may not
have sufficient traction to start, stop, or maintain position when
operations are impacted by winds on contaminated surfaces. Aircraft
under power or under tow may be unable to start, stop or maintain
directional control.

2\) Foreign Object Damage. Pilots of parked or taxiing aircraft may have
to apply increase power in order maintain control while maneuvering or
to initiate or halt movement. The results of increased power, especially
from turbojets may directly damage other aircraft, ground equipment,
terminal property (glass) and ground personnel. Jet blast during such
operations may also affect sensitive aircraft equipment such as static
ports and pitot tubes.

3\) Obscured Visual Aids. The obscuration of airport signs, lights and
visual markings make it difficult for pilots to identify taxiway and
ramps and may lead to traffic conflicts.

Take off performance: "Balanced Field Length" calculations yield the
runway take off weight limit for any air carrier departure. The effect
of snow and slush retarding acceleration down the runway and the effect
of reduced braking action are important variables in this calculation.
Snow/Slush depth, standing water and whether the runway is wet or dry
are all required data for determining if the aircraft can initiate a
takeoff and if necessary stop on the runway in case of an aborted
takeoff at speeds under V~1.~

Landing Performance: The effective stopping distance of an aircraft on
landing is affected by runway conditions. Reduced braking action due to
wet runways, slush, ice, or snow on the runway can degrade braking to
the point that an aircraft at it's current landing weight can not safely
use that runway for landing.

**[Benefits]{.underline}**

The accurate and timely reporting of surface contamination is necessary
for the safety of airline operations. 121.599 requires that the
dispatcher be thoroughly familiar with reported and forecast weather
conditions. 121.601(a) requires that the dispatcher furnish the pilot in
command with all available current reports and 121.601(c) requires that
the pilot be updated during flight. 121.629(2)(iv) specifically
addresses airport surface contamination. The timely availability of
accurate reports contributes directly to aircraft and passenger safety.

When this information is provided in a timely manner to Air Traffic
Management, the facility specialist can make accurate judgements in
regard to reduced arrival rates, ground stops, and runway closures.

Timely action by airport management in measuring the surface
contamination, and a more thorough knowledge of what such contamination
does to airline and aircraft operations will greatly enhance safety and
improve air carrier on time performance.

Runway Operations. Snow, ice, slush and standing water impede aircraft
acceleration and braking performance. AC 91-61A, \"Water, Slush and Snow
on the Runway\" provides additional information concerning the operation
of turbojet aircraft on contaminated runways. Accurate knowledge of
runway contamination is critical to the dispatcher and captain as it is
a key segment of information in the joint go/no go decision during foul
weather operations. Accurate and timely reporting of contamination type
and depth is essential to the safety of flight operations. While
acceptable limits vary by aircraft type, as little as 1/4 inch of wet
snow can bring a halt to operations.

**[Source of the Data]{.underline}**

All airport leases and agreements are clear and specific in terms of the
responsibilities of the lessees with regard to their duties in snow and
ice control and transmission of this information. Airport operators have
a clearly defined legal duty to ensure the safety of operations at their
facilities and to advise users of any degradation of airport facilities.
The FAA is required to ensure that the snow and ice removal plan in the
airport\'s certification manual is current, complete, and customized to
local conditions. Airport operators have the an affirmative legal
responsibility to warn of any change in published procedure or in the
physical facility. This information is normally broadcast through the
NOTAM system. Because of the current lack of reliability in timeliness
and accuracy of this information, each airline has its own field
condition monitoring system.

**[Nature of the Data]{.underline}**

Most Airport Surface Movement Condition data entered by the Airport
Operator is transmitted voice or local communication system. The
frequency of these messages depends on the event. During a heavy
snowstorm these messages may be sent every few minutes. Presently the
data received from the Airport Operator at the AOC is too old to be used
for airline operations. Providing airport operators with a uniform,
rapid, and reliable system to disseminate this information is essential.
The data consists of:

Runway Conditions

Snow/Slush depth

Braking Action by aircraft and/or vehicles

Accelerometer readings

Runway Surface wet or dry conditions

Ramp Conditions

Braking Action by aircraft of vehicle

Snow/Slush depth.

**[What Must be Done to Get this Data on AOC Net?]{.underline}**

[To what current or proposed system must AOCnet be
interfaced.]{.underline}

No industry wide system currently exists. The use of an internet E-mail
system sending formatted messages would suffice to deliver this
information to the AOCnet. System Atlanta data or some other network may
be used. Air carriers, FAA, and the airport operators must agree to a
standard inexpensive, reliable communications system between airport
operators and AOCnet.

[What manual data entry woud be needed]{.underline}

Because of the nature of the data almost all of it will need to be
entered manually by the airlines and the airport operator. It should be
in digital format so as to update airline weight and balance systems. It
should also be available in a readable format for non-automated users.

[What other actions would be necessary to get this data on
AOCnet]{.underline}

Airports with scheduled commercial operations are governed by US CFR 14
Part 139 regulations. The text of the applicable regulation is quoted
below. To get this data the FAA must enforce these regulations and
support the provision of the means to airport operators.

*139.313 Snow and ice control.*

*(a) Each certificate holder whose airport is located where snow and
icing conditions regularly occur shall prepare, maintain, and carry out
a snow and ice control plan.*

*(b) The snow and ice control plan required by this section shall
include instructions and procedures for -*

*(1) Prompt removal or control, as completely as practical, of snow,
ice, and slush on each movement area;*

*(2) Positioning snow off of movement area surfaces so that all air
carrier aircraft propellers, engine pods, rotors, and wingtips will
clear any snowdrift and snowbank as the aircraft\'s landing gear
traverses any full strength portion of the movement area;*

*(3) Selection and application of approved materials for snow and ice
control to ensure that they adhere to snow and ice sufficiently to
minimize engine ingestion;*

*(4) Timely commencement of snow and ice control operations; and*

*(5) Prompt notification, in accordance with § 139.339, of all air
carriers using the airport when any portion of the movement area
normally available to them is less than satisfactorily cleared for safe
operation by their aircraft.*

*(c) FAA Advisory Circulars in the 150 series contain standards for snow
and ice control equipment, materials, and procedures for snow and ice
control which are acceptable to the Administrator.*

*139.339 Airport condition reporting.*

*(a) Each certificate holder shall provide for the collection and
dissemination of airport condition information to air carriers.*

*(b) In complying with paragraph (a) of this section, the certificate
holder shall utilize the NOTAM system and, as appropriate, other systems
and procedures acceptable to the Administrator.*

*(c) In complying with paragraph (a) of this section, the certificate
holder shall provide information on the following airport conditions
which may affect the safe operations of air carriers:*

*(1) Construction or maintenance activity on movement areas, safety
areas, or loading ramps and parking areas.*

*(2) Surface irregularities on movement areas or loading ramps and
parking areas.*

*(3) Snow, ice, slush, or water on the movement area or loading ramps
and parking areas.*

*(4) Snow piled or drifted on or near movement areas contrary to §
139.313.*

*(5) Objects on the movement area or safety areas contrary to §
139.309.*

*(6) Malfunction of any lighting system required by § 139.311.*

*(7) Unresolved wildlife hazards as identified in accordance with §
139.337.*

*(8) Nonavailability of any rescue and firefighting capability required
in §§ 139.317 and 139.319.*

*(9) Any other condition as specified in the airport certification
manual or airport certification specifications, or which may otherwise
adversely affect the safe operations of air carriers.*

*(d) FAA Advisory Circulars in the 150 series contain standards and
procedures for using the NOTAM system for dissemination of airport
information which are acceptable to the Administrator.*

*\[52 FR 44282, Nov. 18, 1987; 53 FR 4258, Feb. 12, 1988\]*

*139.341 Identifying, marking, and reporting construction and other
unserviceable areas.*

*(a) Each certificate holder shall -*

*(1) Mark and, if appropriate, light in a manner acceptable to the
Administrator -*

*(i) Each construction area and unserviceable area which is on or
adjacent to any movement area or any other area of the airport on which
air carrier aircraft may be operated;*

*(ii) Each item of construction equipment and each construction roadway,
which may affect the safe movement of aircraft on the airport; and*

*(iii) Any area adjacent to a navaid that, if traversed, could cause
derogation of the signal or the failure of the navaid, and*

*(2) Provide procedures, such as a review of all appropriate utility
plans prior to construction, for avoiding damage to existing utilities,
cables, wires, conduits, pipelines, or other underground facilities.*

*(b) FAA Advisory Circulars in the 150 series contain standards and
procedures for identifying and marking construction areas which are
acceptable to the Administrator.*

*139.343 Noncomplying conditions.*

*Unless otherwise authorized by the Administrator, whenever the
requirements of Subpart D of this part cannot be met to the extent that
uncorrected unsafe conditions exist on the airport, the certificate
holder shall limit air carrier operations to those portions of the
airport not rendered unsafe by those conditions.*

[When could the data be available digitally so it could be placed on
AOCnet]{.underline}

The data can be available once a communication system is agreed on and
hardware and software is deployed at the airports.

**[Other Issues]{.underline}**

Currently air carriers use company generated field condition reports.
Due to the variations in experience and knowledge at each airport, from
airline to airline, and individually within each airline these reports
often differ in content and accuracy during the same event. When
accurate, timely, and "official" reports are being issued what is the
regulatory consequence of a carrier disregarding the published
information and using company generated reports?

# Departure Delays, Actual Departure Delays. {#departure-delays-actual-departure-delays. .unnumbered}

**[Description of Data Item]{.underline}**

A departure delay is a deviation from a scheduled flight time. This can
occur for a variety of reasons, such as ATC restrictions, mechanical
problems, weather conditions or a myriad of other causes. Not all these
situations call for the same response, as their causes vary. For
example, ATC has no influence over a mechanical delay, but could
intervene to improve the situation if delays were the result of a
departure interval restriction.

**[Benefits]{.underline}**

Distribution of departure delay information would assist aircraft
operators in flight, gate, and schedule planning, and also assist ATC in
better predicting traffic capacity and demand. Forecasts of sector
loading depend heavily on predictability of departure times.
Off-schedule operations reduce the accuracy of airborne traffic
predictions, resulting in less-than-optimal management of available
capacity. Additionally, ensuring that TFM personnel are aware of
departure delays increases the likelihood that they can respond to the
situation by reallocating resources or altering the configuration of the
system to meet the demand.

**[Source of the Data]{.underline}**

Departure delay information is available from at least two sources:
airport ATC and the operators. ATC currently must relay delay
information via telephone, as there is no generally available automated
means of distribution. It is unlikely that manually provided ATC data
will be a reliable source of information, as providing such information
will never be a high priority duty for air traffic controllers. Airline
ops centers receive reports from their gate personnel and aircraft. For
ACARS equipped aircraft, the "OUT" and "OFF" messages can be used to
compute delay , but only after the aircraft is moving. At major
airports, examination of the OUT/OFF message pairs would provide a
significant sample of flights and a reasonable estimate of departure
delays usable for TFM purposes. Making this information available via
AOCnet would be straightforward, as the requisite message traffic is
already handled by ARINC. Airline ops centers receive reports from their
gate personnel and aircraft, and could choose to make delay information
available to the FAA via the AOCNet to ADTN2000 gateway, achieving the
objective of ensuring that delays are known to the service provider but
maintaining more direct control over the process.

**[Nature of the Data]{.underline}**

Departure delays can be viewed in at least two ways: as individual
flight delay information or as delays aggregated by airport. ATC is
mainly concerned with the latter, as their objective is optimizing
system operations to the extent possible.. AOCs need both views in order
to meet the business needs of the airline. Therefore, it would be useful
to provide both a high-level view and a means of drilling down to
individual flights as necessary.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

Delay data derived from Out-Off-On-In messages is already handled by
ARINC, and could be made available in filtered form to provide delay
information. AOCs holding internal information that they wished to make
available could also distribute it via AOCNet. At ATC locations where
alternative means of distribution (SA-IDS, ACE, etc) are available,
local controllers or TMCs could report delays, but this would be less
desirable than automated provision since it would be workload-permitting
and therefore less reliable and consistent.

**[Other Issues]{.underline}**

This item is related to but not the same as the Forecast Departure Delay
information CDM participants are currently providing to ATC through the
AOCnet,

# Active Runway, Active Arrival Runways, Active Departure Runways, "The Active" {#active-runway-active-arrival-runways-active-departure-runways-the-active .unnumbered}

**[Description of Data Item]{.underline}**

An active arrival runway is a runway which is being used to accommodate
aircraft landing at an airport. An active departure runway is a runway
which is being used to accommodate aircraft leaving an airport. While
ATC may elect to use any suitable runway for a particular flight
operation, I will define the term 'active' as referring to the runway
generally being used to accommodate a particular type of operation. The
active arrival runway and active departure runway may be one and the
same. Additional possible statuses are "inactive", meaning available on
request but not currently in use, or "closed" (unavailable due to
maintenance activities, for instance.)

**[Benefits]{.underline}**

This information is of use to anyone involved in flight planning or ATC
operations, as the airport runway configuration affects surface
operations, terminal airspace configuration, frequencies in use,
departure and arrival routes, and aircraft performance limitations.
Ready access to actual and planned airport configuration information
contributes to flight safety and efficiency by improving the quality of
flight planning and scheduling and reducing the frequency of unexpected
route changes.

Safety benefits from this information are difficult to quantify but
anecdotally real. Improper planning based on the incorrect runway due to
lack of current, accurate information quite often results in the
pre-departure check lists being completed as the aircraft turns onto the
runway. The PNF (Pilot not Flying) performs the check list while also
attempting to insure that the performance limits on the unplanned runway
are met. In two man cockpits the work load can lead to operational
errors.

The majority of large air carriers employ an automated performance
planning and weight and balance system. These systems require a valid
source of active runway information. Currently air carriers have local
staffing by each air carrier to acquire and enter this information.

**[Source of the Data]{.underline}**

The fundamental source of airport configuration data at a controlled
airport is local ATC. There is no generally available automated method
of providing the information. One possibility is to extract the runways
in use from Digital ATIS messages at sites where D-ATIS is to be
installed. This is something that ARINC could readily do, perhaps
requiring minor changes to the D-ATIS entry software to specifically
identify active runways in a parseable format. D-ATIS is being installed
now at about 50 airports, and should be available by the end of 1997. If
accessed through ARINC, AOCNet would be an excellent distribution
mechanism. An alternative approach would be to publish manually entered
configuration data via an automated system such as ETMS, System
Atlanta's Information Distribution System (IDS-2 or IDS-4), ACE, or
another method such as a new network and local input device developed
specifically to collect local operational data. This would require
development and implementation of a local interface at each site of
interest, but could be done at reasonable cost using existing FAA
communication services.

**[Nature of the Data]{.underline}**

Runway changes are usually infrequent, thus representing a minor
communications bandwidth requirement. A message would generally contain
one or more runway identifiers and the status of the runway. (Arrival,
departure, both, inactive, or closed.)

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

The D-ATIS to ARINC connection seems to be the most obvious way to get
runway information from towers to AOCNet for D-ATIS equipped airports. A
more general solution may be possible for all Part 139 airports if
airport operators, local ATC facilities and air carriers can agree on
automation and staffing. AOCnet access via the internet may provide a
low cost method of gathering this information.

# Airport Demand and Capacity (current and predicted) {#airport-demand-and-capacity-current-and-predicted .unnumbered}

**[Description of Data Item]{.underline}**

Airport Demand refers to the number of flights that are expected to
arrive and depart at an airport over some time interval. The demand
might be an aggregate number, or it could be a list that contains data
about each predicted flight such as its call sign, aircraft type, and
wheels-up time.

Airport capacity refers to the maximum number of arrivals or departures
that could be safely handled by an airport. The capacity might change
during the course of the day because of weather or other reasons.

**[Benefits]{.underline}**

*What is the current availability of this data?* The Enhanced Traffic
Management System (ETMS) predicts the arrival and departure time for
each flight under instrument flight rules. ETMS also aggregates this
data to derive a predicted arrival and departure demand for each airport
for each fifteen-minute interval. Currently, the aggregate data and also
the detailed data on each flight predicted to depart from or arrive at
an airport is provided to the FAA users of ETMS. Detailed data on each
arriving flight is provided over AOCnet to airlines that participate in
the Collaborative Decision-Making (CDM) Program; this detailed list of
arrivals at an airport is called the Aggregate Demand List (ADL).

ETMS provides data on *thresholds* for airports, which can be
interpreted as an approximation to capacity. ETMS has a default
threshold for departures and separately for arrivals for each
fifteen-minutes interval for each airport in the ETMS databases, which
is about a thousand; a traffic manager can change this number for any
time interval over the next twenty-four hours. The default might be
changed to reflect bad weather, equipment outages, or any other change
that affects an airport's ability to accept traffic. Also, a traffic
manager might change the threshold to suit his or her individual working
style. The significance of the threshold to the traffic manager is that
ETMS's Monitor/Alert function signals an alert if the demand exceeds the
threshold; a traffic manager might set the threshold to a lower or
higher level to increase or decrease the sensitivity of Monitor/Alert.

There are various sources for computed capacities, but ETMS appears to
be the only source of capacity-like data that is changed dynamically to
reflect conditions.

*How would the data be improved if it were on AOCNet?* The demand data
for arrivals is already on AOCnet. If threshold data were on AOCnet,
this would mainly be new data for the airlines. The only capacity data
that the airlines get now is that they are told what the acceptance rate
is when a ground delay program is issued.

*Who would use this data?* Airline dispatchers would use this data when
planning flights.

*To what use or uses would this data be put?* This would alert airline
dispatchers to airports where problems might be expected. This might,
for example, cause them to load more fuel onto a flight that faces a
possibly lengthy hold.

*What would be the benefits in terms of efficiency and safety?* \[Maybe
some airline people can fill this in.\]

**[Source of the Data]{.underline}**

*Who could provide the data? Is there more than one source of the data?*
ETMS derives the demand predictions from a number of different data
sources, including the Official Airline Guide, flight plans, radar
position reports, and CDM messages sent by the airlines. The threshold
values are default values provided by Air Traffic; changes to these
default values are provided by traffic management specialists.

*Is there a system that already contains the data, or is such a system
planned?* Yes, ETMS, as explained above.

**[Nature of the Data]{.underline}**

*How much data is involved*? A current Aggregate Demand List file for an
airport that is sent over AOCnet is perhaps 20KB when compressed. These
files contain detailed data on all the flights arriving at an airport
over a ten-hour period. Adding capacity data to these files would
increase their size only slightly.

*How frequently is the data updated?* The ETMS databases on flights are
updated continually as data is received, where this data includes flight
plans, radar position updates, CDM messages from the airlines, and other
data. A threshold changes whenever a traffic manager uses the Aircraft
Situation Display's CAPS command to change it.

*How reliably will the data be provided?* This data can be provided very
reliably since it comes from ETMS, which is an operational FAA system.
That is, ETMS outages that would prevent this data from being generated
and sent are very rare.

*How accurate will the data be?* Since this data consists of a
prediction of a highly uncertain future, completely accurate predictions
should not be expected. There are three main contributors to inaccuracy.

-   Inaccurate input data: If ETMS does not have accurate data about the
    flights that will fly, then it cannot predict accurately. Efforts to
    improve the quality of the data received by ETMS are always being
    pursued, e.g., through the Collaborative Decision-making Program.

-   Inaccurate modeling by ETMS: When modeling the trajectory of an
    individual flight and hence predicting when it will arrive at an
    airport, ETMS makes a number of assumptions about that flight, e.g.,
    the ascent and descent profiles that it will fly, the speed at which
    it will cruise, and its route of flight. Insofar as the modeling
    assumptions that ETMS makes are incorrect, this will tend to make
    the predictions inaccurate. Efforts to improve the ETMS modeling are
    always being pursued.

-   Random factors: For example, if at the last minute a mechanical
    problem prevents an aircraft from flying, then all the predictions
    that ETMS made about the deoparture and arrival time of that that
    aircraft will be wrong. There is probably no good way to predict
    random events.

    There is no overall measure of the accuracy of the ETMS predictions.
    It should be noted, however, that these ETMS predictions are the
    data that goes to the traffic managers who use ETMS, so it would
    contribute to a common understanding of the problems if the same
    data went to the airlines and other NAS users.

    **[What Must be Done to Get this Data on AOCNet?]{.underline}**

    *To what current or planned system must AOCNet be interfaced?* The
    interface between AOCnet and ETMS is already in place.

    *What manual data entry would be needed?* None.

    *What other actions would be necessary to get this data on AOCNet?*
    A modest amount of software development would need to be done to
    include thresholds in the Aggregate Demand List (ADL), which is
    already available to airlines over AOCnet. Also, permission would
    need to be obtained from the FAA before the threshold data could be
    sent to the airlines.

    *When could this data be available digitally so it could be placed
    on AOCNet?* Once FAA approval is obtained, and once funding is made
    available for the software development work that would need to be
    done to get this data from ETMS to AOCNet, this data should be
    available very quickly, i.e., within a period of months or perhaps
    even weeks.

# NAS Outages[^1] {#nas-outages .unnumbered}

**[Description of Item]{.underline}**

Identifies scheduled outages and ongoing unplanned outages of NAS
equipment directly affecting flight. Specific attributes (properties or
fields ) are:

-   FAA Facility or service type[^2] (Localizer, ASR, ARSR, RCAG, ARTCC,
    etc.). Attachment A provides a list of relevant services

-   Location: (City, state, lat, long)

-   Type of message: (outage or restoration message)

-   Type of outage: (scheduled or unscheduled)

-   Outage start time: (perhaps GMT rather than local time; can be in
    the future for scheduled outages; must be in the past for
    unscheduled outages)

-   Scheduled end time: (for scheduled outages only)

-   Impact/consequence: (none, full capability maintained with alternate
    system, degraded performance, airway closed, runway closed, minimums
    raised, etc)

-   NOTAM reference

    **[Benefits]{.underline}**

    ***Users:*** All users whose flight plans are or might be impacted
    by equipment outages including AOCs and other organizations
    supplying information to pilots filing their own flight plans

    ***Uses:*** To support decisions on

-   schedule revisions ,

-   flight cancellations (if outages are likely to affect airport
    operation rates),

-   flight plans (departure and arrival times, routing \-- if affected
    by equipment outages),

-   equipment (e.g., sending more capable aircraft to compensate for nav
    aid outage)

***Efficiency and safety benefits:*** Can mitigate congestion and delays
due to outages

**[Source of the Data]{.underline}**

The National Airspace Performance Reporting System (NAPRS, FAA Order
6040.15C) is the means for collecting data on interruptions to
facilities and services and air traffic delays to selected airports in
the NAS. Currently, outage and delay data for major NAS facilities is
collected nightly over TINYNET, a network of PCs at General NAS (GNAS)
locations. Tandem computers at the 20 national Air Route Control Centers
(ARTCCs) poll these GNAS locations in their control areas and feed data
to Washington where the National Maintenance Control Center personnel
extract the needed data and process it for review at the ATCSCC and FAA
Headquarters the following morning. When information is not sufficient,
the MCC will contact the field facilities for additional background. The
current data includes equipment outages at the 22 pacing airports, busy
airports, and ARTCCs, long range radars where there is no overlapping
coverage, ASR 9 data, telco-caused failures and other significant data.
The data also includes delays caused by equipment outages and delays of
all causes at the pacing airports, Level IV and Level V airports,
ARTCCs, and other delays of significance. There is a future system
called NIMS (National Infrastructure Maintenance System) which may
provide a single integrated timely source for such data. However, this
system will not be in place for several years.

There may be a separate source of data for providing NOTAMS on NAS
outages at flight service stations (FSSs). In addition, other from local
airport authorities for facilities not maintained by the FAA (e.g., some
runway and taxiway lighting, construction, etc.) may also be gathered.

**[Nature of the Data]{.underline}**

***Estimated size***: Unknown. Probably less than 1 kbyte/report

***Estimated frequency***: Variable (reports generated asynchronously).
Based on past NAS Performance Reporting System (NAPRS) experience,
approximately 140,000 outages/yr, or 400/day indicating failure; another
400/day for restoration.

***Reliability of data sources**:* Unknown; most likely variable

***Accuracy of data:*** Unknown

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

**C*urrent or planned system to which AOCNet should be interfaced:
***The primary system is the Maintenance Management System (MMS) Tandem
system located at the NMCC. It may be also be necessary to interface the
AOCnet to multiple Flight Service Stations (FSSs), GNAS PCs and ARTCC
Tandem systems[^3]. However, this can not currently be determined. The
primary issue affecting this determination is the timeliness of the
data. Delays occur as outage data move up a hierarchy of systems to the
centralized MMS (see above). From the Tandem, it may be necessary to
download the data can then be downloaded to another computer which can
be more easily interface to ADTN 2000 (and from there to AOCnet).

***Additional manual data entry:*** In general, manual data entry would
not be necessary. The exception is forms that were filled out by hand
rather than entering the data into PCs at the GNASs (or elsewhere).

***Other actions would be necessary to get this data on AOCNet:***

1.  *Procedures for release of raw outage data.* NAS outages are items
    reportable to congress and are therefore sensitive. Raw outage data
    are subject to change can not considered to be official FAA
    information until a validation process has occurred. Procedures
    (including limitations) for release of such raw data must be
    defined. Presumably, this procedure can be made similar to that used
    for announcing outages via NOTAMs

2.  *Interfaces to local airport authority data information systems:* A
    separate data connection would be necessary to local airport
    operating authorities. Outages may be reported as part of other
    systems such as SMA or SAIDS.

# Runway Visual Range (RVR)

**[Description of Data Item]{.underline}**

Runway visual range is a measurement (in hundreds of feet) of the
horizontal visibility at ground level along an ILS-equipped runway. ILS
runways may provide up to three separate readings (touchdown, mid-field,
rollout). Particular categories of ILS approach (I, II, III) require
specific minimum RVR readings to be available for use.

**[Benefits]{.underline}**

Distribution of timely and accurate RVR readings to NAS users provides
essential information for operational control of air carriers and
planning by non-air carriers. Allowing dispatchers and aviation
meteorologists to compare current RVR reports with other information
allows more accurate forecasting of visibility and weather at near
minimum conditions. RVR requirements vary by air carrier, aircraft type,
aircraft avionics, crew qualifications, deferred maintenance items and
crew experience. Knowledge of recent RVR reports with current RVR
reports assists flight crews and dispatchers in assessing fuel status,
likelihood of completing the approach, and the possible need for a
diversion, or whether a proposed flight operation should be undertaken.
ATC can also use RVR for planning purposes and prediction of holding
delays.

**[Source of the Data]{.underline}**

RVR sensors come in two types: the old Tasker system, which employs a
frequency-shift-keying transmission method and analog-to-sort
-of-digital conversion with dedicated displays at towers and TRACONs,
and the new Teledyne system, which is in the process of installation at
major airports. The Teledyne RVR sensors use a standard RS-232 serial
presentation that is suitable for digital distribution and access. It is
theoretically possible to provide a digital interface to the Taskers,
but that would require design and construction of a custom conversion
box costing a few hundred dollars a reading. Pre ASOS weather observers
appended RVR reports to weather reports during periods of low
visibility. ASOS implementation caused these RVR reports to be removed
from METARS. Recent industry efforts have resulted in provision of RVR
reports at some airports.

While the actual sensors are always located at the airport, RVR readings
are normally remoted to the overlying TRACON, thus providing a second
point of access. The TRACON end is more attractive in a major area such
as New York, as there will be several airports aggregated up to the
TRACON: this provides a common access point for several sites and
runways. At the tower end, it is possible that RVR could be relayed to
ARINC over the TDLS connection. TRACON data could be transmitted to
ARINC over NADIN and then made available to AOCNet. System Atlanta has
proposed installing a connection from one airport to AOCnet as a test of
integrating System Atlanta information into AOCnet.

**[Nature of the Data]{.underline}**

RVR is expressed as one or more visibility measurements, and updates
continuously. As a result, it is likely that some filtering or sampling
will be required to prevent sending excessive numbers of readings over
the network. The specific update rate is a topic for study and
discussion.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

Making the information available across AOCNet requires that the
information be extracted from the airport or TRACON systems and
forwarded to an AOCnet through some communications mechanism. One
possible path would be to ARINC via the Tower Data Link System
connection used for Pre-Departure Clearance (PDC) delivery, but that
solution is restricted to PDC-equipped airports. At other airports, a
server could be established to collect local data such as LLWAS and RVR,
and export it to ADTN2000 or NADIN as a path to ARINC and AOCNet. The
System Atlanta prototype connection from one site to AOCnet would not
only provide RVR reports but could also facilitate the exchange of much
more information between users and facilities.

**[Other Issues:]{.underline}**

The current ICAO Annex describes the RVR portion of a METAR. ICAO
standards require that RVR for all active RVR equipped runways be
reported. The US filed an exception to this requirement due to
inadequacies and limitations of the US weather reporting system. Any
long-term solution to providing RVR should include bringing the US into
compliance with the ICAO METAR standards with respect to RVR.

# Surface Movement Advisor (SMA)

**[Description of Data Item]{.underline}**

By the sharing of both AOC and FAA data, the SMA project is showing both
the FAA and airlines the advantages of collaborative decision making at
a local level. This data sharing allows for optimization of taxi,
takeoff, and departure transition operations which have an important
affect on airport capacity and through-put. Also, the SMA computer
algorithms benefit from knowledge available at the airline/operator
level. SMA makes the information available to the airlines in two forms,
a carrier-specific display which is generated by the SMA file servers
and also in a "raw data" form which consists of the FAA data in message
formats. Following is the type of data exchange occurring between the
FAA and the airlines.

1\. Updated Schedule Information

In the case of an airport like ATL, the majority of the arrivals and
departures capacity comes from schedule commercial carriers like Delta,
ASA, and other commercial operators. In the past, the FAA planned for
this capacity based on the published marketing schedule (OAG) of these
carriers. In reality, the time these flights arrive and depart is a
function of the resources needed to operate the flight (aircraft and
crew) and the items which are out of the AOCs control (weather, runway
closures, and etc.). These are tracked by the AOC systems and revised
estimated time of arrivals (ETAs) and revised estimated time of
departures (ETDs) are predicted. By making the ETAs, ETDs, and
cancellations available to the FAA electronically, a more accurate
capacity plan can be determined.

2\. TRACON Information

The commercial operators have had tracking information, furnished by the
FAA, in the form of the ASD data feed. Unfortunately, this data only
provided position data for flights under the control of the centers.
Once the flight was turned over to the FAA tower's control (TRACON), the
tracking data ceases. With SMA, the following information is now
available for the ATL airport.

a\. Hand-Off message

> SMA provides specific flight information when a flight goes from the
> center's control to the FAA tower's control (TRACON).

b\. Outer Marker (In-Range) message

SMA provides specific flight information when a flight is on final
approach. This

provides carriers (like Delta, ASA, and etc.) a more accurate status of
their flights.

c\. Touchdown (On-Time) message

SMA provides specific flight information when a flight has touchdown
(on-time).

This can be especially useful for a carrier's flight which is not
equipped with ACARS.

3\. Estimated Taxi Time to Gate Message

Based on a algorithm, which takes into account the direction flights are
landing, runway which a flight has used, and the gate assignment of that
flight, a estimated taxi time to the gate is calculated.

4\. Designated Gate for Inbound Flight Message

By knowing the designated gate where the arriving flight will park, a
more accurate estimated time to the gate can be predicted. Gate
assignments are tracked by AOC systems and revised assignments are
predicted. SMA initially captures this information from the Flight
Information Display Systems (FIDS). Certain carriers, like Delta, also
provides this information to SMA and will supercept the FIDS source.

5\. Estimated Taxi Time to Takeoff Message

SMA provides estimated taxi time to take-off based on designated runway.
This allows the FAA tower to better balance the take-off demand. This
should result in lower taxi times for all flights.

6\. "Ready for Departure" Message

The AOC systems, like Delta's, have the ability to know when a flight is
ready for departure based upon the flight's ready status. Approximately
6 minutes before departure, Delta provides a message to SMA for a more
accurate ETD.

7\. Actual Out Time Message

The AOC systems, like Delta's, track out times via both ACARS messages
and station personnel messages. SMA uses this information to determine
the true demand on the departure capacity of the airport. For those
carriers which do not have the ability to provide this information, SMA
captures out times from the FIDS environment.

8\. Improved Airport Ground Operations

All carriers operating at the ATL airport can benefit from the SMA
information. This allows carriers to better utilize their stations
resources, both personnel and facilities.

a\. Decision-making for Hub Connections

Smarter decisions can be made by knowing the true status of inbound
flights which

have passenger connections. Then, a more accurate assessment of holding
a flight

for connections can be determined.

b\. Decision Making for Pushback

> Due to flights with identical departures and location of where the
> flight is parked (gate location), a priority flight (has a critical
> arrival time at downline station for connections, equipment need,
> curfew, and etc.) could be in-line for departure behind that same
> carrier's non-priority flights. With knowledge of both the flight's
> status (AOC information) and length of taxi time before departure,
> AOCs can make smarter decisions on when to pushback flights from the
> gate.

c\. Ability to Update FIDS Programmaticly with Accurate ETAs

> With the raw data feed from the SMA, AOCs can programmaticly update
> FIDS and other passenger information systems (like voice response
> units (VRU)) with

more accurate ETAs.

d\. Better Utilization of Ground Personnel

> Knowing a more accurate status of the inbound flights allows better
> use of the ground personnel. Instead of gate personnel, both inside
> and outside, having to wait on the arrival of a flight, they can be of
> assistance at other gates.

9\. SMA Display Information

a\. Visual Display of Airport Split for Take-offs

> SMA display provides the actual split of the airport for departures.
> The ATL Airport has two runways on the north side and two runways on
> the south side. A split indicates which departure vector gates will be
> accessed via which runways. The standard split is a NW/SE which
> indicates that flights using vector gates N1, N2, W1, and W2 depart
> from the north side (north complex). The remaining flights use the
> south side (south complex). In the past, this information has been
> verbal. The verbal communications will continue at present.

b\. Visual Display of Airport Operations Direction

> SMA display provides information on which direction the airport is
> operating. In ATL airport's case, it is a East or West operation.

c\. FAA Visual Display of Airport Take-off Demand

> SMA display provides the FAA with individual flight information. This
> allows the moving of selective flights from one departure complex to
> another departure complex to assist in balancing the departure demand.

d\. FAA Graph Display of All Take-off Splits' Demand

> SMA display provides the FAA a graphical display of all the possible
> splits using the current departure demand. This allows the FAA tower
> the opportunity to change departure splits to better balance the
> demand. The end result is lower taxi times.

**[Benefits]{.underline}**

What is the current availability of this data?

The data is available electronically in parsable, digital format. It is
located on a Oracle database at the ATL TRACON. It is currently a
prototype, awaiting funding for future rollouts.

How would it be improved if it were on AOCNet?

It would be available to all AOCNet participants instead of providing it
to those AOCs which currently have a communication connection to their
ATL operations. This could be rolled into the future "CDM/ETMS"
database.

Who would use this data?

This would provide each AOC a "picture" of the ATL operation and each
dispatcher a understanding of the current airport operation.

Benefits and/or uses of this product?

With a better understanding of "what is occurring", a AOC can make
better decisions on their operations (traffic delays, connections,
ground handling, etc) and dispatchers can make better decisions on
single flights for alternates, turn times, and etc.

**[Source of the Data]{.underline}**

The data could be provided as the realtime Oracle database is updated.
ADTN2000 backbone could be the communication link to Volpe Center/ETMS
database.

**[Nature of the Data]{.underline}**

The data is made up of multiple data messages (see above description),
each with a format that makes it easily identified, and length of each
message condensed for speed of transmission. The current database is
updated (realtime) as each event occurs. The reliability of the data is
very good because the sources are the ARTS, FIDS, and, in some cases,
AOCs.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

Tom Stamps has been in conversation with the SMA's IPT Lead, Denny
Lawson, and with NASA Ames about delivering this data to Volpe Center
and the CDM/ETMS database as part of Phase II. Phase II has now received
funding through Fiscal Year 98 and future discussions will be required.
If this comes about, then this data will be available to the AOCs before
Summer, 1998.

# Local Notams, Distant Notams, Field Condition Reports, Surface Guidance Control and Movement (SMCG) Implementation Notices

**[Description of Item:]{.underline}**

Notams is an acronym for Notices to Airmen. This information is
information complied from a variety of sources and disseminated by the
FAA to pilots to provide the status and equipment and components of the
national airspace system which may affect aviation safety.

Field condition reports are collected and disseminated locally by the
airport operator. This information has proven valuable to airport
residents in describing the status and condition or runways, taxiways,
and ramp areas which may affect the movement of aircraft on the
airfield.

Surface Movement Guidance and Control procedures are required by the FAA
when airport visibility falls below 1200 feet Runway Visual Range (RVR).
These notices must be provided to each airfield aircraft operator as
required by FAA.

**[Benefits:]{.underline}**

Who would use this data?

Anyone who is involved in the operation of the national airspace system
is a potential user of Notams and Field Condition information. This
includes pilots, controllers, dispatchers, air traffic control managers,
etc.

To what use or uses would this data be put?

This information is necessary to safely manage national airspace system
resources.

What would be the benefits in terms of safety and efficiency?

Timely and accurate delivery of this information is critical to flight
safety.

**[Source of Data:]{.underline}**

What could provide this data? Is there more than one source of the data?

Airport can provide Notams and Field Condition information pursuant to
the status of their airport and its components, including runway,
taxiway, lighting, and airport owned and operated navigation and landing
aids. Airports are the primary and often sole initiator of this
information.

Is there a system that already contains the data, or is such a system
planned?

There is currently NO automated interface from an airport operator into
the national airspace systems which permits timely and accurate entry of
airport status information into the FAA Notams System for dissemination
to FAA and aircraft operators. Currently a variety of methods are used
including telephone calls and faxes to local or remote FAA Flight
Services Stations for data entry. Further, there is no automated
confirmation that Notams have been accurately entered by FAA personnel
in a timely fashion into the Notams system, or if affected users have
received those Notams.

Field Condition Reports suffer even greater dissemination challenges
than Notams since Field Condition Reports are not officially recognized
as Notamable information according to past FAA practices. These policy
and practices hearken from a time of very limited communication
capabilities when 100 work per minute teletype circuits were the
backbone of the weather and Notam distribution system. Even now Field
Condition Reports are only disseminated locally by telephone, fax, or
electrowriter to resident aircraft operators and air traffic tower
control personnel.

**[Nature of Data:]{.underline}**

How much data is involved?

Of the approximately 800 commercial service airports in the US there is
probably an average of one Notams or Field Condition message per day per
airport consisting of less than 1K bytes of data Ð a daily total of less
than 1M of data. Of course regional conditions, such as snow, will
result in an increased hourly and daily data load. However, under no
circumstances are the amount of data relevant in size or impact to
current high bandwidth communication capabilities.

How frequently is data updated?

Most frequent update is estimated from hourly to daily at irregular
intervals.

How reliably will the data be provided?

Data is critical to flight safety. It will be entered as required.

How accurate will the data be?

As accurate as possible.

**[What Must be Done to Get this Data on AOCNet:]{.underline}**

To what current or planned system must AOCNet be interfaced?

There is no current system which provides a data interface directly from
airports. This capability must be provided by the AOCNet.

What manual data entry would be needed?

Currently this information is maintained locally in various forms. The
current data providers would realize some saving by having a single
system to enter all data items in a uniform format

What other actions would be necessary to get this data on the AOCNet?

Communication interface and supporting software and hardware capability.

When could this data be available digitally so it could be placed on
AOCNet?

Yes.

**[Other Issues]{.underline}**

FAA Flight Standards must be involved in the creation of any system to
distribute this data. The Regulatory and safety issues involved will
require review and approval by FAA Flight Standards of any proposed
system.

# Forecasted and Existing Airborne Holding/Expect Further Clearance (EFC)

[**Description of Data Item**:]{.underline}

Airborne holding is a procedure where by enroute aircraft are issued a
clearance for a predetermined maneuver which keeps aircraft within a
specified airspace while awaiting further clearance from ATC. Airborne
holding is caused by any number of factors: airport arrival demand
exceeds airport arrival capacity, equipment outages (nav aid, radar,
computer etc.), aircraft emergencies, enroute weather, airport gridlock,
and sector saturation. With the exception of demand exceeding airport
capacity, these factors are usually unknown in advance. However, planned
limited airborne holding (MAR), at certain airports, is utilized to
insure arrival demand is available when capacity is unknown or when
capacity unexpectedly increases. EFC is an ATC verbal tool to inform a
pilot to expect to receive clearance beyond a clearance limit. A

EFC is issued according to controller judgment, experience, possibility
of loss of communications, or to avoid frequency congestion. Procedures
may vary from controller to controller and from ATC Center to Center.
Usually aircraft EFC's are separated by five to eight minutes and rarely
accurately depict a true release time.

**[Benefits:]{.underline}**

Accurate information concerning "expected" airborne holding aids the
dispatcher in meeting the FAR 121.647 requirement to plan fuel for
expected traffic delays. It is an important tool to enhance pilot and
dispatcher situational awareness. It has the possibility of reducing
cost and decreasing passenger inconvenience by minimizing the chance of
aircraft diversions. Additional benefits include development of better
traffic management tools, more accurate delay initiatives, and better
matches of demand and capacity and capacity enhancement. The safety
benefits of this information being available to PIC, AOC, and TMUs is
eloquently stated in the NTSB report on Avianca 52's fuel exhaustion
accident at Colts Neck Long Island.

**[Source of the Data:]{.underline}**

Timely expected airborne holding projections are difficult for planning
purposes. Accurate projections become more available as the affected
aircraft nears its scheduled arrival time. There are several available
means to arrive at delay/airborne holding possibilities. The following
are arranged in a time line from planning to actual holding:

\*FSM (Flight Schedule Monitor). The best indicator of future airborne
holding/delays is the projected match of demand vs. capacity. Real time
minute by minute demand is projected by FSM. This demand compared with
forecasted airport configuration and forecasted airport arrival rates
could provide a good look at the future probabilities of holding.

\*ASP (Arrival Sequencing Program). An arrival flow metering tool used
by some ARTCC's . ASP considers airport configuration and predetermined
capacity based on runway configuration to sequence aircraft for arrival.
This tool does not necessarily predict airborne holding but can be an
indicator that holding is possible by estimating a time a aircraft must
be delayed to meet the needs of airport capacity. These delays are
constantly changing and can be in the form of speed changes, vectors, or
airborne holding.

\*CTAS (Center/Tracon Automation System. Computer intelligence for
planning and controlling arrival traffic is provided by the Traffic
Management Advisor (TMA) portion of CTAS. TMA provides Center Traffic
Management personnel a tool to control the flow of traffic to a specific
runway configuration by generating a sequential order. Landing time
delay information is provided. All delays can be increased or decreased
by speed adjustments.

\*ASD (Aircraft Situation Display). Heading change alerts could provide
real time information on entering and departing holding patterns.

\*Manual inputs by Center and TRACON TMCs. Recording of delays and
airborne holding is a required responsibility of the TMC. This
information could be provided by Teletype to AOCNet or via IDS4.

\*Air/Ground PIC to Dispatch. Aircraft given a hold pass that
information to their AOC dispatcher via voice or datalink. This
information usually includes fuel on board, location, and EFC.

**[Nature of the Data:]{.underline}**

Forecast holding information is expressed in expected minutes of holding
during a time period. Actual holding is expressed both as an EFC which
does not state the expected actual hold time and interpolated from
recent data from flights that were held for that airport and released.
Actual holding is a moving average based on recent events and is
therefore very time critical if the information is to be of use.
Forecast holding can come from many sources which may not agree. Until
studies are done to identify which sources are the most accurate
predictors the forecasting of holding times will remain subjective. Data
from all sources must therefore be available to all participants.

**[What must be done to get this Data on the AOCNet?]{.underline}**

There is a constant flow of data available from ASP, CTAS, and ASD. ASP
information is already available to TWA from ZKC through ARINC. CTAS,
ASD, and FSM should easily interface with the AOCNet. Center and TRACON
delay data could easily be entered into the system or captured from the
ATC computer system. Individual flight EFC's and hold times are most
easily available from the individual carriers. AOCs can forward this
information through the AOCnet for capture and storage by the
appropriate system. To be useful all the various forms of forecast and
actual holding should be available from a single centralized source
accessible by all the participants.

**[Other Issues:]{.underline}**

Once the various holding forecasts are captured in a usable form a study
should be made to identify the most accurate source or sources of
forecast holding times. Before a useful system can be put in place
decisions need to be made about how the data will be stored and by whom
as well as how users will be able to access it.

# National Convective Weather Forecast Product

**[Description of Data Item]{.underline}**

This product provides graphical information regarding the current and
forecast locations of thunderstorms. The algorithm produces 60-minute
extrapolation forecasts of thunderstorm activity on a national scale.
The algorithm uses a tracker to follow and extrapolate a combined
lightning and radar reflectivity field. Future refinements will improve
the predictive capabilities of the system by including forecast of
thunderstorm growth and decay. We propose to implement a prototype
national-scale convective forecast algorithm during FY98. The prototype
algorithm will run in the NCAR aviation weather development laboratory
in Boulder. The output will be available for display on the web on a
password-protected weather page where it can be accessed through the
AOCNet.

The problem with thunderstorms is that they assemble just about every
known hazard to aviation in one place. Lightning, turbulence, hail,
rain, and poor visibility require that airspace users provide a wide
margin of separation between these phenomena and aircraft operations. In
addition to safety, the great variation in thunderstorm size and
duration can create huge airspace capacity and flight operations
effects. A line of thunderstorms crossing the airspace of a major
terminal area can quickly produce national traffic flow problems and
delays. Exactly where this phenomenon is and where it is going, how long
it will be there or in the forecast location, and whether it is building
in size and strength or dissipating its energy are critical operational
as well as safety questions.

From an operational perspective, the sooner a pilot can be directed to
deviate from an en route flight path occupied by a thunderstorm, the
less abrupt and operationally consequential the escape maneuver will be.
Similarly, the trend and track of a thunderstorm in terminal areas is
critical to organizing gate holds and ground delay effects.

**[Benefits]{.underline}**

Based upon NTSB data developed at the Volpe National Transportation
Systems Center for the FAA, that as many as 3 commercial (Part 121),
convection-related accidents a year might occur over the next 20 years.
An estimate prepared for the NASA-ASTT program suggested that about 10
percent of the convection and convection-related winds accidents could
be avoided with better convection and convection-related wind
information, yielding an annual convection avoidance benefit of about
\$60 million a year for commercial carriers, if the cost per aircraft
loss averaged \$200 million.

**[Source of Data and Algorithm Description]{.underline}**

The convective weather forecast algorithm consists of three steps which
that are summarized here. The three steps are first, processing and
combining the lightning and radar data; second, extrapolating from the
combined lightning and radar field using NCAR-developed software; and
third, producing the forecast grids for the appropriate times.

First, in order to ingest and combine radar and lightning data, Kavouras
national radar mosaics are used as input to the convective weather
forecasting algorithm. The Kavouras radar mosaics are calculated on a
2-km by 2-km grid, with radar reflectivity summarized into six levels
based upon velocity indexing (VIP levels). In order to reduce the
quantity of data and filter the data to a spatial scale consistent with
a 1-hr forecast period, the 2-km Kavouras radar mosaic is filtered to
10-km grids. This is done by mapping the average reflectivity value from
the surrounding 2-km data to the 10-km grid point.

Next, the national lightning data set is included in the algorithm to
aid identification of active thunderstorm regions. Kavouras also
distributes the present national lightning data set that is used in the
prototype thunderstorm forecast product. In order to effectively

combine the lightning data with the radar data, the lightning data must
be mapped to a grid that is congruent with the radar grid. To create the
array, the lightning rate is produced for each 10-km grid point. The
rate is determined by the number of lightning strokes in a 20-km area
surrounding each of these 10-km grid points over a 5-minute time
interval. The lower left-hand panel of the demonstration product shows
the lightning rate field.

Then, the radar and lightning grids are combined into a common grid used
by the NCAR algorithm. Information regarding lightning rate and percent
coverage of level 4 (greater than 46 dBZ) or greater radar echo will be
displayed for each storm, nationwide, on the web page accessible to the
AOCNet.

**[Nature of the Data]{.underline}**

Second, a part of the NCAR convection product algorithm (called TITAN)
will monitor the growth, direction of propagation, and decay of storms.
TITAN includes 2-dimensional, combined reflectivity and lightning data
for its calculations. A storm is defined by a data threshold and size
(for example VIP level 3 and 1500 km2, respectively). An optimization
method that matches storms at one radar volume time to those at a
subsequent time is used to track the storms. Based on past storm trends,
TITAN predicts future storm location and size.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

The final step is to produce the intensity and forecast grids and
display them on the web. The grids will update at 10-minute intervals.
The intensity grid provides information on active thunderstorm regions.
The forecast grid provides one hour extrapolation forecast.

The most reliable method to get this data on the AOCNet is for NCAR to
conduct the data processing and create a series of .gif images (or some
other similar web-compatible format), and then either send these images
to an AOCNet server via automatic FTP, or have AOCNet users link to a
password-protected web page that NCAR would maintain at RAP for a test
and demonstration period. A set of plan view and vertical cross-section
coordinates for pre-selected flight levels and regions could be
provided.

Alternatively, NCAR could ship the algorithm output grids to the AOCNet
server and a service provider could write a Java applet allowing the
graphics to be created on the server for AOCNet airline operations
centers and the FAA traffic management unit users (allowing the service
provider more flexibility to create critical area cross sections, etc,
but also requiring the provider to build the architecture and software
necessary to handle the grids and plots).

For the purposes of an operational testing and evaluation of these
product concepts, we think that it might be impractical to give
NCAR-EXPERIMENTAL software to an AOCNet service provider. There is a
great deal of \"hidden\" architecture at NCAR to ingest all of the
required data sets, run the software, and create the test imagery which
makes these products run. A costly and very labor-intensive effort by a
service provider might be required to identify and duplicate this
architecture elsewhere for an operational test and evaluation.

# Digital Automatic Terminal Information Service (Digital ATIS/D-ATIS)

**[Description of Item]{.underline}**

Automatic Terminal Information Service (ATIS) is currently a continuous
voice broadcast over very high frequency (VHF) air/ground radio channels
(108-137 MHz). It provides local weather, approach in use, departing
runway, Notices to Airmen (NOTAMS), and notices of hazardous weather
warning. D-ATIS provides: (1) ATIS text message via data link to
aircraft, airlines, and other users upon request; and (2) computer
synthesized ATIS voice messages via existing ATIS VHF transmitters at
each airport.

The following airport specific information is available on D-ATIS.

a.  NOTAMS (specific to reporting airport): Free text, Taxiways &
    Runways closed, SIGMETS, PIREPS, Equipment Outages, Equipment
    Obstacles, Field Conditions, Ramps Closed, Airport Closed, and other
    ARR/DEP NOTAMS.

b.  Advisories: Free text, Braking Action, Bird Activity, Wind
    Shear/Microburst Alerts, Other Advisories.

c.  Runways: Active Arrival & Departure Runways, Parallel Runways, ILS
    Runways, Approaches in Use.

d.  Other/Weather: Airport, Time, Measured Wind, Altimeter, Weather
    Remarks, Meteorological Aviation Reports (METAR), ATC Frequencies.

D-ATIS is operational at 24 towers. It is installed and expected to be
operational at an additional 33 towers in the May/June time-frame.
Expansion to the remaining 35 FAA towers is projected to occurr in the
more distant future.

**[Benefits]{.underline}**

Users of D-ATIS would include dispatchers and Command Center personnel
and pilots. The information would convey the noted airport weather,
status and configuration information.

The D-ATIS information would be used for flight planning, routing, and
scheduling.

The efficiency and safety benefits accrue from the NOTAM and Advisories
information contained in the text. Coupled with the Runway information,
the resultant picture can be used to make informed decisions on the best
use of assets to efficiently exploit the airport available capacity.

**[Source of the Data]{.underline}**

Currently, the Digital ATIS information is generated in the Air Traffic
Control Tower (ATCT) via the Tower Data Link System (TDLS). The TDLS
system interfaces to and receives the weather information from the site
weather input (e.g., Systems Atlanta Information Display System/SAIDS,
Airport Weather Information System/AWIS, or Automated Surface Observing
System/ASOS). Using an editor, the controller can modify the weather
information and add or modify airport information (e.g., runway, NOTAMS,
etc.). The TDLS system then compiles that ATIS text message and the
computer generated voice message. The text message is sent to the D-ATIS
database through NADIN II, the FAA's X.25 service, and the ARINC Data
Network Service (ADNS). The flight crew of an Airport Communications and
Reporting System (ACARS) equipped aircraft can then request the ATIS
message via ACARS for any of the TDLS equipped ATCTs from the D-ATIS
server. Concurrently, the ATIS voice message will be broadcast over
existing ATIS frequencies. The D-ATIS data is also accessible by the
Airlines from the ARINC server via the ARINC Packet Network (APN)/ADNS.

**[Nature of the Data]{.underline}**

The D-ATIS message format is as follows.

+-------+--------------------+--------------------+--------------------+
| Line  | Field              | Line format \*     | Max \# of          |
|       |                    |                    | Characters         |
+-------+--------------------+--------------------+--------------------+
| 1     | ATA/IATA Priority  | *SOH QU SP*        | 4                  |
|       |                    |                    |                    |
|       | Designation        | *rrrrrrr CR LF*    | 9                  |
|       | Address            |                    |                    |
+-------+--------------------+--------------------+--------------------+
| 2     | Origination        | *.aaaATXA*         | 8                  |
|       | Address            |                    |                    |
|       |                    | *SP ddhhmm CR LF*  | 9                  |
|       | Time Stamp         |                    |                    |
+-------+--------------------+--------------------+--------------------+
| 3     | Message            | *STX TIS CR LF*    | 6                  |
|       | Application Code   |                    |                    |
+-------+--------------------+--------------------+--------------------+
| 4     | Reporting Airport  | *AD SP aaaa/OS*    | 10                 |
|       | Location           |                    |                    |
|       |                    | *SP I*             | 2                  |
|       | Identifier         |                    |                    |
|       |                    | *V hhmm CR LF*     | 7                  |
|       | ATIS Type          |                    |                    |
|       | Indicator          |                    |                    |
|       |                    |                    |                    |
|       | ATIS Version       |                    |                    |
|       | Designator         |                    |                    |
+-------+--------------------+--------------------+--------------------+
| 5     | ATIS Text          | *- SP SP*          | 3                  |
|       |                    |                    |                    |
|       |                    | *x (3400) CR LF*   | 3402               |
|       |                    |                    |                    |
|       |                    | *ETX*              | 1                  |
+-------+--------------------+--------------------+--------------------+

**\*** *Line format is ASCII characters*

The data is updated twice an hour, or as changes occur (e.g., weather,
NOTAMS, runway change, etc.)

D-ATIS is operational data. A controller (FD/CD) is assigned to prepare
and send the data. It is reliable and accurate.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

The source of the D-ATIS data is the ATS Server located at ARINC. Since
both AOCNet and the ATS Server reside at ARINC Annapolis, it is
envisioned that a router/hub type interface will be required, and that
the information could very easily be made available on AOCNet.

**[Other Issues]{.underline}**

Regulatory : Currently weather reports used for air carrier operations
must be those prepared by the NWS or an approved source. NWS and FAA
Flight Standards will need to agree that Digital ATIS reports are
acceptable for use in air carrier operations.

# Metering

**[Description of Data Item]{.underline}**

There are actually a number of parameters relevant to this category.
I\'ll use the definitions provided on the NASA CTAS web page, since that
is one source of such data in the NAS that is already in digital form
(for very limited locations):

\"TRACON Acceptance Rate"

The maximum number of aircraft per hour that can be scheduled to enter
the TRACON.

"Meter Fix Acceptance Rate"

The maximum number of aircraft per hour that can be scheduled to cross a
meter fix. Each meter fix has its own meter fix acceptance rate.

"Gate Acceptance Rate"

The maximum number of aircraft per hour that can be scheduled to cross
any of the meter fixes contained within a gate. Each gate has its own
gate acceptance rate.

"Meter Fix Blocked Intervals"

Time intervals during which aircraft may not be scheduled to cross the
meter fix.\"

**[Benefits]{.underline}**

What is the current availability of this data? Different subsets of
these data currently reside at 3 types of locations.

First, for the limited number of sites with CTAS, this data is all
available real-time in digital form.

Second, ATCSCC has a new program under which all centers are supposed to
provide them with real time information on all dynamic restrictions that
are to be imposed. This information includes the following -

Date:

Time:

Facility From:

Facility to:

What the Restriction is:

Primary Facility, Sector or Airway Affected:

Start Time:

End Time:

Reason:

Comments:

At present, only a subset of the restrictions in the NAS is actually
available at ATCSCC, but the goal is to ultimately be comprehensive.

Third, the only comprehensive source of data at present is the knowledge
distributed at the particular facilities involved with a given
restriction.

How would the data be improved if it were on AOCNet? These data
currently are not available on any routine basis to the airlines. They
typically only get access to information about a particular restriction
if they talk with ATCSCC or the local facility on the phone.

Who would use this data? Airline dispatchers would use this data.

To what use or uses would this data be put? These data would be useful
for identifying routine (daily) as well as momentary bottlenecks due to
capacity constraints. This could be useful to dispatchers when planning
flights (preflight) or when amending flight plans while the aircraft are
enroute.

What would be the benefits in terms of efficiency and safety? In
general, this would help AOCs to make decisions about whether and when
to consider air traffic bottlenecks in planning and amending flights. As
an example, dispatchers have commented that, to deal effectively with
the expanded NRP, they need air traffic forecasts.

**[Source of the Data]{.underline}**

Who could provide these data? In the short to mid run, the likely
feasible source is the ATCSCC program described above. As it becomes
more comprehensive, it could be a viable mechanism for distribution to
AOCs.

For the sites where CTAS is available, it is also a potential source
(and perhaps even a preferred one as there will be a stronger incentive
to keep the data up to date).

**[Nature of Data]{.underline}**

How much data is involved? Someone needs to get a list of the number of
such fixes to estimate this. Perhaps Volpe has such data.

How frequently is the data updated? The data itself obviously will
change based on traffic conditions (including the impact of weather).
Frequency therefore will vary depending on conditions.

How reliably will the data be provided? This could be a major challenge,
as the local facilities will have to make the effort to provide such
data to ATCSCC. Missing data could be a problem unless adequate
incentives and resources are provided to make it easy and worth the
while of local facilities to provide the data in a timely fashion.

How accurate will the data be? Two issues must be considered. The first
is completeness of the database (discussed above) and the accuracy of
input into the database. The second is the informativeness of the data
in terms of forecast horizon and predictiveness. For identifying regular
daily bottlenecks, what needs to be known is what the parameters
actually are from day to day (to estimate the mean and variance or
probability density function). For real-time use, the forecasts have to
be available far enough in advance to allow meaningful changes in flight
plans to be made, but still accurate enough to be informative. Do Volpe
or Mitre have data on such predictive accuracy?

**[What Must be Done to get This Data on AOC Net?]{.underline}**

A subset of the data could be made available fairly easily, using the
restrictions already being compiled at ATCSCC and/or the data available
through CTAS. A broader question than simple availability must be

addressed as well however, which is how to make the data as useful as
possible. In its ultimate version, this could require tools for data
analysis, data display and incorporation of such data into flight
planning tools. (The raw data could be of use directly by dispatchers,
however, even without such tools.)

**[Other Issues]{.underline}**

Possibly incorporate meter fix rate data into the FSM software for
departure and arrival fixes and planning routes etc.

# Center-TRACON Automation System (CTAS)

**[Description of Item]{.underline}**

CTAS, developed at NASA-Ames Research Center, comprises two tools: The
traffic management advisor (TMA) and the final approach spacing tool
(FAST). TMA is used by the En Route Controller and Traffic Management
Coordinator (TMC) in ARTCCs. FAST is used by the Terminal controller in
TRACONs.

TMA provides meter lists with crossing times, delay estimates, and
schedules to fixes. Specifically, TMA provides an ETA to the meter fix,
outer-outer fix, and the runway threshold. It also provides a traffic
situation display, traffic counts, rush alert advisories, demand
information, and NAPRS delay reporting. This advisory information is
provided to the TMCs and, in later versions, to the sector controllers.
FAST provides runway assignments, landing sequence numbers, priority
aircraft designations, and missed approaches. The TMA operating envelope
is essentially Center-wide to the TRACON boundary, whereas FAST is
within the TRACON. The increased flow-rates and decreased delay benefits
of TMA and FAST are complementary, given their distinct operating
horizons.

CTAS "Build 1" consists of only the Build 1 version of TMA. CTAS Build 1
is installed at the following locations: Los Angeles/SCT, Denver, Miami,
and Atlanta. The currently installed CTAS Build 1 sites are prototypes
and there are no more prototype installations planned. CTAS Build 1
sites provide metering and miles in trail information to TMCs in the
ARTCCs, TRACONs, and to the Towers at the above locations.

CTAS "Build 2" consists of FAST and the build 2 version of TMA. Build 2
TMA provides the same type of information to the TMCs as TMA Build 1
(although improved and expanded), and, in addition, provides metering
lists to the individual ARTCC sector controllers on their PVDs, who thus
schedule arrival aircraft to fixes per the CTAS generated sequence list.
FAST schedules landing sequence and assigns runways for arriving
traffic. A traffic situation display and traffic counts are also
generated. Landing sequence and runway assignment are provided to the
TRACON controller through the FDADs. TMA build 2 and FAST are in
operation at the Fort Worth ARTCC and DFW TRACON. CTAS is currently a
"prototype development system", supported by the FAA AUA-540 "Traffic
Flow Management IPT". Build 2 CTAS is planned for national deployment
beginning in 2001. Specific future sites and deployment schedules are
currently being established.

Primary CTAS TMA inputs are from the Host (specifically Flight Plan and
Track Update related), and weather from NOAA. FAST gets En Route and
Terminal track data from ARTS and Host inputs from TMA.

**[Benefits]{.underline}**

Build 2 CTAS provides computer intelligence for the planning and control
of terminal air traffic by means of advisories presented to controllers
on their displays. CTAS advisories provide a better situational
awareness to the controller and improve traffic flow efficiency. ATC
Operations at the Ft. Worth ARTCC with Build 2 TMA show a 1-2 min per
aircraft delay reduction during rush periods, while reducing controller
workload and increasing TMC situational awareness. FAST results at DFW
TRACON have demonstrated throughput increases of more than 13% with no
negative impact on controller workload or safety.

Build 2 CTAS data could assist airlines by providing arrival flight data
and ARTCC/TRACON air traffic management data. Arrival flight data would
include aircraft ETAs, sequence, runway assignment, and delay
information. CTAS time of arrival (ETA) data will be more accurate than
those based on historical projections or extrapolated from flight plans.
During en-route ARTCC metering, CTAS scheduled time of arrivals (STAs)
will provide accurate per aircraft delay information in addition to time
of arrival. Build 2 CTAS data should thus improve the efficiency of
ground operations, particularly at airline hubs.

**[Source of the Data]{.underline}**

Currently CTAS data is not available outside of its fielded FAA
facilities. A plan has been developed to provide CTAS Build 2 TMA data
to airlines operating in the ZFW/DFW area. The data would be provided
through a specialized, filtered, CTAS "repeater" display. The data would
remove the specific aircraft identifiers of the non-host airline and
prevent any computer feedback from the host airline to the FAA
facilities (ZFW and DFW TRACON) through CTAS. Such constraints on the
sharing of CTAS data with airlines were required to allow the planned
limited data sharing of Build 2 CTAS data with airlines. Approval for
such data sharing is still pending, although expected, from FAA Air
Traffic.

There are no plans to provide CTAS data on any "open network" such as
AOCnet. Issues that would have to be worked out for such an activity
would include airline competitive advantage, measures to prevent airline
questioning of ATC decisions given the additional data, non-government
control of sensitive ATC data in the event of an air incident or
accident, and FAA computer network security. These issues have both
technical and political ramifications.

Some thought has been given to a CTAS-ETMS integration effort, either
providing CTAS data to ETMS or providing ETMS data to CTAS. An ETMS data
feed has recently been established to the CTAS development lab at
NASA-Ames.

**[Nature of the Data]{.underline}**

Build 2 CTAS TMA data is updated at a 12 sec rate; FAST at a 6 sec rate.
For the CTAS TMA "repeater" display mentioned above, the data would
nominally use around 60% of a 128Kbps ISDN, which would vary with air
traffic conditions (e.g. number of planes to track and schedule, etc.)
Start-up transients would require more bandwidth for "reasonable"
start-up times. These data specifications are for the research TMA
"repeater" system mentioned above, and include some additional message
traffic that is not accessed by the repeater. Hence, exact bandwidth
requirements for CTAS data would be less than the above estimate.

The data stream itself is very reliable (stable) as it is in operation
at FAA operational facilities. The CTAS data is quite accurate in its
ETAs, sequence lists, and runway assignments, as evidenced by the daily
reliance and use of these advisories by the ARTCC TMCs and sector
controllers, and TRACON controllers.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

See discussion above in Section 4 "Source of the Data".

#  Severe Turbulence and Severe Icing

# Other Names : Severe CAT, Extreme Turbulence

**[Description of Data Item]{.underline}**

Severe Turbulence : Turbulence which causes loose objects to move around
the cabin and causes brief periods where effective control of the
aircraft is impossible. It may cause damage to aircraft structures.
Extreme turbulence is defined as causing structural damage and prolonged
loss of control of the aircraft.

Severe and extreme turbulence can occur in convective activity
(thunderstorms). Clear Air Turbulence (CAT) can occur in conjunction
with the Jet Stream or in association with mountainous terrain over
which high speed winds are moving.

Severe Icing : Icing which the aircraft's anti-icing systems can not
effectively handle.

Known and forecast turbulence and icing is a four dimensional constraint
which has the added property of probability of actual existence. An
AIRMET forecasting possible moderate to severe turbulence or icing has
less weight in planning and executing air carrier operations than a
Center Weather Advisory of the same with pilot reports confirming it's
existence.

**[Benefits:]{.underline}**

Severe turbulence is dangerous to aircraft and their occupants. Once an
area is identified as having severe turbulence that block of airspace is
no longer useable and creates a constraint around which ATC and the
users must operate. Forecast turbulence can create an area the user
wishes to avoid. Known Severe or Extreme turbulence makes avoidance of
the area required for all users.

Severe Icing is a hazard to aircraft. When an area of forecast or actual
severe icing is identified both users and ATC must avoid that airspace.

[**Safety Benefit** :]{.underline}

A number of passengers and crew are injured each year during encounters
with Severe or Extreme turbulence. Better and more timely reporting of
forecast and actual conditions will reduce this number. Air carrier and
other aircraft fatal accidents have been attributed to encounters with
severe icing. Any improvement in the accuracy and reliability of
identifying areas of severe icing will help prevent further icing
related fatalities.

[**NAS Benefit** :]{.underline}

**Turbulence**

The early and accurate identification of 4D constraints in the NAS
caused by Severe or Extreme turbulence will reduce disruptions to
traffic flow and will lower controller work load due to unexpected user
requests for deviation from filed user trajectories.

**Icing**

Due to the altitudes at which severe icing is usually encountered the
users and ATC have to make changes to holding and arrival procedures at
a terminal when severe icing is forecast or known. These can include
changes to the AAR up to a suspension of arrivals and departures,
sequencing of Turboprop and piston aircraft ahead of turbojet aircraft
for arrival, and loss of the use of one or more arrival routes or
holding fixes. Better reporting and forecasting will allow ATC and NAS
user to plan around these constraints.

**[Source of the Data]{.underline}**

Turbulence Data elements :

  --------- ---------- -------- ------------------ -------- -------------- --------
  Type      Forecast   Actual   Issuance           Format   Source         Valid

  AIRMET    Yes                 0145Z then every 6 Text     NWS            6 Hours
                                Hours                                      

  SIGMET    Yes                 When required      Text     NWS            Stated

  CWA       Yes        Yes      When required      Text     ARTCC CSWU     2 hours

  Company   Yes                 Varies by company  Text     Company        Varies
                                                            sources        

  PIREP                Yes      When required      Text     FSS ATC AOC    Varies
  --------- ---------- -------- ------------------ -------- -------------- --------

Icing Data Elements :

  --------- ---------- -------- ------------------ -------- -------------- --------
  Type      Forecast   Actual   Issuance           Format   Source         Valid

  AIRMET    Yes                 0145Z then every 6 Text     NWS            6 Hours
                                Hours                                      

  SIGMET    Yes                 When required      Text     NWS            Stated

  CWA       Yes        Yes      When required      Text     ARTCC CSWU     2 hours

  Company   Yes                 Varies by company  Text     Company        Varies
                                                            sources        

  PIREP                Yes      When required      Text     FSS ATC AOC    Varies

  TAF       Yes                 00Z then every 8   Text     NWS            24 Hours
                                hours                                      

  METAR     Yes        Yes      00Z then every     Text     NWS            1 hour
                                hours                                      
  --------- ---------- -------- ------------------ -------- -------------- --------

Format :

All turbulence and icing forecasts are issued using a set of standard
location identifiers and include the altitude range for which turbulence
or icing is expected.

Validity

The period for which these elements are valid varies by product. AIRMETS
and CWA (Center Weather Advisories) have a standard period of validity.
SIGMETS include in the text the period of validity. PIREPS (Pilot
Reports) have a validity ranging from one hour to the period of any
forecast calling for the reported condition. All periods of validity for
forecasts are subject to change should an amendment to the forecast be
issued.

**[Nature of the Data Items]{.underline}**

**Forecast**

All of these products except company forecasts are currently available
with varying periods of delay over current weather circuits. Company
forecasts are available to authorized users via the ARINC or SITA
networks.

**Pilot reports:**

Pilot reports are given to FSS facilities, ATC controllers, ATC Towers,
air carrier station operations personnel, and air carrier dispatch
offices. FAA facilities receiving pilot reports pass them to the NWS
weather circuits for all NAS users. Currently pilot reports received by
air carriers are passed on to that air carriers flights by company
means.

The AOCNET will allow air carriers to place company pilot reports on the
general weather circuits for all users and on AOCNET for participating
users.

**[Requirements to place on AOCNET:]{.underline}**

**Forecasts**

The current resolution of Forecasts of icing and turbulence must be
improved. New forecasting products from NCAR and others are currently
available as prototypes on the internet. These prototypes are being used
today by air carriers and other aviation interests. The Aviation Weather
Center must be given the funding to evaluate these products along with
industry and provide validated products on a 7X24 basis to all users.
Since many of these products are currently available on the internet,
moving them to the AOCnet can be done quickly.

**Pilot Reports**

For FAA facilities the current method of reporting through an FSS which
places reports on the weather circuits causes a substantial delay before
this information is available to all users. An AOCNET messaging ability
will allow ARTCC facilities and air carriers to directly enter pilot
reports into the system thus reducing delay in dissemination. ARTCC and
air carrier access to an AOCNET formatted message ability will be
required. A link between AOCNET and the weather circuits will have to be
established to allow the transport of this information between the them.
ARINC/SITA messaging to a pilot report processor that places these
reports on the AOCNET and weather circuits is also possible.

**[Other Issues]{.underline}**

**New and Experimental Data Sources:**

NCAR and other aviation weather research centers have prototype products
which are currently not disseminated over the weather circuits or not
disseminated at all. This is a non inclusive listing provided to show
the opportunities that the AOCNET provides for NAS users to acquire new
and more accurate forecasts of Severe Icing and Severe Turbulence.

**Neural net icing forecast**

NOAA generated discrete Graphic forecast of icing probability and
intensity by time frame and altitude. This product is not currently
provided to users except through the internet and due to internet
reliability issues is not yet an official NWS forecast. AOCNET can
provide the reliability of transmission and make this product available
to all participating users. Individual graphic forecasts are in the GIF
format and 16k in size.

**Mountain wave turbulence**

NOAA generated map showing expected turbulence values due to mountain
wave activity. Updated every 12 hours. GIF format approximately 16k in
size per 12 hour forecast.

**Turbulence Indicator Forecast**.

Graphic display of forecast upper air turbulence and CAT for a 12 or 24
hour period. GIF format and approximately 32k in size.

**Pilot reports graphic**

UCAR provided display of pilot reports based on user selectable criteria
such as moderate to severe icing over a one to six hour period. GIF
format approximately 32k in size for each graphic forecast.

**Requirements to place on AOCNET:**

Preliminary discussions with UCAR and NOAA indicate that links to Volpe
can be established via the Internet. The AOCNET could additionally have
a process to access and transport these products. NWS and FAA need to be
consulted about the use of these products especially for air carriers.
Discussions with the FAA Regional Dispatch Resources will take place on
May 20-21 about these issues.

The interactive pilot report graphic display is a product that could be
made available to users through the AOCNET immediately with an internet
connection. Air Carriers will have to develop or provide from available
software (Net browsers, or "GIF viewer" should be sufficient initially)
to properly display this graphic information.

**[Requirements to Interface with AOCNET.]{.underline}**

Access to the current weather circuits with a pass through and possible
filtering capability will make most of these products available to
AOCNET users. Since most of this data is currently available to all
users through other means consideration should be given to only moving
those data elements to the AOCNET that will gain some value added
component.

Company forecasts are the exception to the general availability
mentioned above. Currently the ATCSCC receives some company forecasts of
turbulence and/or icing for the ATCSCC's use in recognizing constraints
on that carrier's operation. Air Carrier's that desire to share company
forecasts of icing and turbulence with ATCSCC or a set of other users
should be allowed to place this information on the AOCNET. Once on
AOCNET these company forecasts will assist ATCSCC and the TMUs to
recognize constraints on those carriers using that product.

There are legal questions that must be answered in regard to company
forecasts. If the ABQ TMU has a forecast of severe turbulence at FL 330
over TCC provided by carrier X and carrier Y is routed over TCC at FL
330 with resulting injuries from turbulence, who, if anyone is liable
for allowing this flight to operate through forecast turbulence.

Value added components such as filtering can enhance safety and identify
possible constraints more rapidly than the existing weather circuit
process. Most Pilot reports (UA) do not report severe icing or
severe/extreme turbulence. All Urgent Pilot reports (UUA) report severe
conditions. A process that forwards UUAs to AOCNET would insure the
rapid receipt by all users of this information.

# Integrated Turbulence Detection and Forecast Product(s)

**[Description of Data Item]{.underline}**

There is a need for an integrated turbulence product, combining in situ

and terrain-induced detection and forecasting (modeling) in a
2-dimensional display of grid coordinates that map a plan view and
vertical cross section for any portion of any route of flight and
altitude over the US. This turbulence display product would be shown as
one of several weather products on a password-protected, weather web
page for flight planning, dispatch, and traffic management. The page
would be accessed through the AOC Net.

Our current understanding of atmospheric turbulence processes is
limited. This is because turbulence occurs in the atmosphere on scales
that are not adequately observed in the atmosphere, there are a variety
of ways to generate turbulence in the atmosphere, and turbulent
processes are complex and non-linear. One major problem is the lack of
reliable, accurate, and timely measurements and reporting of atmospheric
turbulence locations and intensities on a network that is useful to the
operational aviation community. Current information in the form of pilot
reports (PIREPs) has not been a satisfactory turbulence detection
system. Another major problem is the poor performance of turbulence
forecasts at present, which may miss detected turbulence and
over-predict its occurrence, i.e., false alarm.

The lack of precision of current turbulence pilot reports and
over-forecast areas of turbulence prediction may increase its
operational impact. Pilot reports can effectively \"close\" air routes
without warning, limiting available airspace and increasing airspace
user and service-provider workloads as well as overloading radio
frequencies. Reporting aircraft and all trailing aircraft on the
frequency generally request altitude and vector changes. Although some
seasonal turbulence associated with the movement of the jet stream and
air movements over terrain can affect several hundred kilometers of
flight-level air routes, if turbulence forecast areas are too large or
include entire regions of the country they encourage users to disregard
them.

**[Benefits]{.underline}**

Despite over-forecasting and conservative piloting practices, turbulence
accounts for over 40 percent of all weather-related factors or causes
cited in air carrier accident reports by the NTSB. One major airline
estimates that it encounters severe turbulence an average of once a day.
There are about 30 turbulence incidents a year reported by the NTSB,
estimated by one airline to cost an average of \$750,000 per incident.
Based on an analysis of NTSB accident data, Volpe National
Transportation Systems Center estimated that there could be an average
(baseline) of 43 air carrier (Part 121), turbulence-related accidents
per year in the future, about 20 percent of which might be avoided with
better detection and forecast products. This suggests an average annual
air carrier benefit of about \$6 million. An estimate for the NASA-ASTT
program based on these Volpe data for all of aviation, identified annual
turbulence accident avoidance benefits of about \$17 million.

Real-time in situ measurements of turbulence encounters and a
quantitative measure of the severity of that turbulence would be a vast
improvement over current pilot reports. In addition, higher resolution
forecast models capable of capturing fine scale turbulence features,
based on updated winds and turbulence reports would also improve
turbulence forecasts. Finally, the NASA-ASTT team documented that
putting both these detection and forecast improvements in a
user-friendly display would foster common situation awareness among
pilots, dispatchers, controllers and traffic managers, greatly reducing
turbulence-related accidents.

**[Source of the Data]{.underline}**

The integrated turbulence detection and forecast product remedies the

under-measurement detection and reporting problem by using
state-of-the-, in-situ and remote sensors. In-situ sensors on commercial
aircraft are coming on-line shortly, and the use of remote sensors like
satellites and weather radar to detect turbulence (especially
convection-induced turbulence), is imminent. As these in-situ and remote
sensor observations become available, they will be

incorporated to initialize models and become components of diagnostic
and forecast turbulence. The integrated detection and forecast product
combines numerical weather prediction model outputs with in situ
turbulence observations and other turbulence measurements to generate
forecasts initialized by these state-of-the-atmosphere measurements and
explicit forecast model parameterizations.

As its name implies the integrated turbulence detection and forecasting
product involves two kinds of requirements: (1) detecting and reporting
turbulence, and (2) forecasting regions of likely turbulence.

The two main data sources for turbulence detection are traditional pilot

Reports and in-situ measurements of on-board vertical accelerometer data
converted to turbulence intensity data. In situ measurements are
received in real-time by ARINC (via the ARINC-ACARS-MDCRS data networks
and NADIN 2) and provided to the NWS for distribution, as they become
available on a high priority, Internet data delivery system (IDDS).
These in situ measurements are based on NCAR software that is presently
integrated in avionics transponder packages for United Airlines' B-737s
and 757s, and which will be implemented fleet-wide for these aircraft
within the next two years. As other airlines acquire this avionics
package, a data-rich source of quantitative turbulence reports will
become available. Secondary data sources to be included within the next
two years for use in convection-generated turbulence are GOES satellite
imagery and WSR-88D weather radar imagery products, available from
satellite data feeds and the NEXRAD Information and Distribution System
(NIDS).

The main data source for the turbulence forecasts are the NWS National

Center for Environmental Prediction (NCEP) forecast and analysis
products. Initially the Rapid Update Cycle (RUC) forecast model would be
used as input to a suite of turbulence diagnostic algorithms in order to
produce turbulence forecasts out to a period of six hours. Besides
ingesting and updating forecasts rapidly, the RUC uses an isentropic
coordinate system that permits especially high resolution of the
atmosphere in the vicinity of fronts and the tropopause, known areas
favorable to the production of clear-air turbulence.

**[Nature of the Data]{.underline}**

Turbulence detection data will come from the two kinds of pilot reports.
Conventional turbulence pilot reports, and quantitative, in situ
turbulence reports. Conventional turbulence pilot reports include the
severity of turbulence encountered as well as the location and time of
the encounter. Although subjective, these reports are valuable as direct
observations of turbulence encounters and will be sorted and stored for
developmental purposes by environmental conditions (e.g., clear or
cloudy), aircraft altitudes, and aircraft type to minimize their
qualitative nature. Quantitative, in-situ measurements of turbulence
will be taken from the aircraft avionics packages in

real-time. They consist of aircraft accelerometer data used in on-board
NCAR algorithms to estimate turbulent intensities. Thus quantitative
reports will be provided continuously by appropriately equipped aircraft
in the national airspace.

Current NCEP forecast products do not include turbulence predictions.
However, the forecasts do provide fields of data that may be used to
diagnose the likelihood and possible the intensity of the turbulence.
For example, from the forecasts of winds, horizontal and vertical wind
shear information can be deduced. When this forecast is used with a
suite of turbulence diagnostic algorithms, turbulence can be predicted.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

The most reliable method to get this data on the AOCNet is for NCAR to
conduct the data processing and create a series web-compatible format
images. Then either send these images to an AOCNet server via automatic
FTP, or have AOCNet users link to a password-protected web page that
NCAR would maintain at RAP for a test and demonstration period. A set of
plan view and vertical cross-section coordinates for pre-selected flight
levels and regions could be provided.

Alternatively, NCAR could ship the algorithm output grids to the AOCNet
server and a service provider could write a Java applet allowing the
graphics to be created on the server for AOCNet airline operations
centers and the FAA traffic management unit users. This would allow the
service provider more flexibility to create critical area cross
sections, etc, but also require the provider to build the architecture
and software necessary to handle the grids and plots.

For the purposes of an operational testing and evaluation of these
product concepts, we think that it might be impractical to give
NCAR-EXPERIMENTAL software to an AOCNet service provider. There is a
great deal of \"hidden\" architecture at NCAR to ingest all of the
required data sets, run the software, and create the test imagery which
makes these products run. A costly and very labor-intensive effort by a
service provider might be required to identify and duplicate this
architecture elsewhere for an operational test and evaluation.

**[Other Issues]{.underline}**

Coordination with FAA Flight Standards is required to insure
interpretation of the regulations to allow the use of these new products
is not required. Prior FAA Flight Standards approval of the use of these
products by air carriers and airmen is also required to avoid legal
liability issues.

# Operational De-icing and Snowfall Accumulation Product

**[Description of Data Item]{.underline}**

The problem facing the pilot and dispatch organization is deciding when
to de-ice aircraft based upon their estimates of current conditions, and
the amount of time before the aircraft is likely to be cleared for
take-off. Field and laboratory studies have shown that the amount of
time an aircraft is protected by a deicing fluid is inversely
proportional to the liquid equivalent precipitation rate. The
anticipated liquid equivalent snowfall rate, therefore, in combination
with past accumulated liquid equivalent precipitation for a given
location, and directly related to the estimated protection time
available before take-off, would be useful information to decide whether
or not further deicing would be necessary prior to take-off. The
operational de-icing and snowfall accumulation product will
automatically relate radar reflectivity and snowfall rate to total
liquid water accumulation and projected accumulation on aircraft control
surfaces over fixed time intervals. This accumulation and forecast
product will be graphically displayed for airline dispatchers and gate

control, airport runway managers, and local air traffic controllers.

Although the responsibility for aircraft de-icing decisions is legally
only the pilots, the guidance and decision aides currently available to
help make this decision and to share necessary information with others
whose functions critically depend on it, are clearly limited. When an
aircraft should be de-iced is currently a difficult decision, based on
subjective assessments of its current condition, future meteorological
conditions, and an estimate of the amount of time before take-off.
Moreover, current National Weather Service guidance regarding icing
conditions relates visibility to snowfall rate and may be misleading.
FAA standards regarding icing accumulation and aircraft inspection are
based on visual cues, at the same time that they explicitly acknowledge
that very small (invisible) accumulations on all aircraft control
surfaces may be potentially hazardous to flight. Resulting pilot
de-icing decisions based on this guidance contribute to aviation
accidents and affect flight dispatch and air traffic control functions,
and drive airport operating rates.

**[Benefits]{.underline}**

Commercial aircraft (part 121) accidents due to inadequate de-icing and
runway surfaces are not uncommon, though hardly routine occurrences.
Based on a Volpe National Transportation Systems Center analysis for the
FAA, an average of about 3, de-icing related, commercial airline
accidents will occur per year in the future. An analysis prepared for
the NASA-ASIST program estimated that about 10 percent of these
accidents might be avoidable with better weather situation awareness and
de-icing decision aides available at major airport terminals. This would
save about 6 commercial aircraft in the U.S. from de-icing accidents
over the next 20 years, producing an annual de-icing safety benefit of
about \$60 million.

**[Source of the Data]{.underline}**

The sources of the data for this product are commercial vendors using
the National Weather Service (NWS) NEXRAD Information and Distribution
System (NIDS), such as WSI and Kavouras, and the NWS Automated Surface
Observations System (ASOS) and airport weather observers, together with
weather station snow gauges.

**[Nature of the Data]{.underline}**

The operational deicing and snowfall accumulation system uses
automatically processed Doppler radar reflectivity and velocity data
from operational, WSR-88D (Doppler) weather radar, ASOS 5-minute
temperature readings and human surface weather observations, and
1-minute resolution weather station snow gauge measurements of liquid
water equivalent rates to compute snow band location and liquid
water-equivalent precipitation rates in the terminal area.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

The most reliable method to get this data on the AOCNet is for NCAR to
conduct the data processing and create a series of .gif images (or some
other similar web-compatible format), and then either send these images
to an AOCNet server via automatic FTP, or have AOCNet users link to a
password-protected web page that NCAR would maintain at RAP for a test
and demonstration period. A set of plan view and vertical cross-section
coordinates for pre-selected flight levels and regions could be
provided.

Alternatively, NCAR could ship the algorithm output grids to the AOCNet
server and a service provider could write a Java applet allowing the
graphics to be created on the server for AOCNet airline operations
centers and the FAA traffic management unit users (allowing the service
provider more flexibility to create critical area cross sections, etc,
but also requiring the provider to build the architecture and software
necessary to handle the grids and plots).

For the purposes of an operational testing and evaluation of these
product concepts, we think that it might be impractical to give
NCAR-EXPERIMENTAL software to an AOCNet service provider. There is a
great deal of \"hidden\" architecture at NCAR to ingest all of the
required data sets, run the software, and create the test imagery which
makes these products run. A costly and very labor-intensive effort by a
service provider might be required to identify and duplicate this
architecture elsewhere for an operational test and evaluation.

# Severe Weather Avoidance Program (SWAP) Plans

**[Description of Item]{.underline}**

SWAP plans are typically put into effect for certain time periods
(typically around two hours, but it all depends on the severity of the
weather) when departures from an airport are going to differ
significantly from the standard departure routes because of severe
weather in the area. Although the term SWAP generally refers to
departure routes, the term is also often used for enroute deviations due
to weather. The SWAP routes are usually agreed upon somewhere between
30-60 minutes before the weather impacts the area, but this could vary
depending on the situation (e.g. for a large, tractable weather system,
reroutes could be possibly be planned a couple of hours in advance;
likewise sometimes storm cells buildup and the reroutes are immediate).

Currently these routes are determined by consensus among all the
affected ARTCCs and the ATCSCC. Once an area of weather is identified as
a major hindrance to traffic flow (typically by a local facility
initiating a call to the Severe Weather Complex at the ATCSCC),
alternatives are discussed on a telcon amongst the affected facilities.
Items considered are congestion, crossing streams of traffic, distance
of reroute, altitudes affected by storm, jet routes affected by storm,
and others.

Work is in progress to improve the process of determining efficient SWAP
routes for all users, both internal to the FAA and external. Procedures
are in place now, with technology hopefully to follow, to get the users
much more involved in the route determination process.

**[Benefits]{.underline}**

The distribution of SWAP plans would be beneficial for all users of the
NAS. Flight planners of all scales, as well as local FAA facilities
(including ARTCCs, TRACONs, Towers, and FSSs) would benefit from having
this data.

The flight planners could use this information to replan their schedules
based on the new constraints imposed by the severe weather and the
accompanying SWAP routes. Optimally they would have enough time to fuel
the aircraft accordingly based on the SWAP plan, or manipulate the
affected flights in whatever way they deem necessary.

For the flight plans that could not be altered by the flight planners
due to time constraints, the availability of SWAP information
electronically, may permit the use of automated refiling in the ARTCC.
Currently the ARTCC controller now performs that refiling process
manually for every flight affected by the SWAP route. Also, ARTCCs could
now constantly be aware of reroutes happening in their neighboring
facilities that could affect traffic flow initiatives they may be
considering internally.

The availability of this information also helps the general aviation
community by allowing more information to be presented in the pre-flight
briefings on a more timely, automated basis, and keeping making the
pilot more prepared for decisions that need to be made for the upcoming
flight as far as fuel, altitude, route, communications along route, etc.

**[Source of the Data]{.underline}**

Currently an agreed upon SWAP route would only reside in the ATCSCC and
the local facility implementing that SWAP route. For both terminal and
enroute SWAPs, the ATCSCC will disseminate the information pertaining to
the route (such as which traffic is affected and times the route is in
effect) over ETMS to all FAA facilities, and ARINC to all aviation
subscribers.

A few ARTCCs have published numbered SWAP routes (e.g. ZNY has 3600
published routes). However, these routes are rarely implemented by
number, but instead, whatever routes are appropriate for the situation.
It just so happens that the route used ended up being #1867.

**[Nature of the Data]{.underline}**

The data for SWAP routes is basically in the form of a text message. The
message explains who the SWAP routes apply to (traffic departing X,
bound for Y), the new route including fix names and jet routes, and a
time the route will expire. Typically anywhere from 3-8 lines of text.
The data would be updated as the weather changes enough that the route
is no longer valid or necessary. Depending on the day and the severity
of the weather, there could be quite a few messages pertaining to new
routes due to severe weather. At most, it would be a handful an hour
over the course of a shift. The data about the new route has to be sent
immediately after it is agreed upon. Getting the data into a log may be
interrupted by other work, but sending the advisory out to all users
happens very quickly and will be very accurate. The exact location and
movement of the weather may be somewhat inaccurate (as weather
prediction can tend to be), but the routes chosen will be solid.

**Data Elements**

Controlling Facility: Facility identification code

Effective time: GMT

Departure station(s): 4 Letter airport identification

Full route or dept. Route: D/R

Arrival stations(s): 4 Letter airport identification or departure fix

Constrained Resource: Airway, Navaid, Facility, Geographic area

Constraint: Weather, congestion, Facility outage

Route: Standard route notation (XXX..YYY.J00.ZZZ)

Flight Levels involved: From FLXXX to FLYYY

Expiration time: GMT

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

Currently SWAP routes are manually typed and sent via ARINC and Email.
AOC net could tap into these sources, and have some parser for the SWAP
message. This would imply a very standardized message format for a SWAP
message which would be useful. Given the evolving ETMS chalkboard and
similar capabilities, it seems like the agreed upon route could be
generated from the display that is being used to stimulate the reroute
discussion. Once captured, this route could be sent electronically to
AOCNet or any other source in some standardized format. There would
probably still be some text entry to discuss times and which traffic is
affected.

**[Example of possible format]{.underline}**

SWAP ZNY 021845 KEWR D SBY ZNY TRW KEWR..COL..SBY FL100 FL 410 2100

There is a SWAP route published by NY ARTCC for EWR Departures via SBY
VOR. The route is EWR direct COL VOR Direct SBY VOR thence Destination
for all flights from FL 100 to FL410 from 1845Z to 2100Z

SWAP ZFW 021845 KDFW R IAH ZHU TRW KDFW..ACT..FST..AUS..IAH FL000 FL410
022300

There is a SWAP route published by ZFW ARTCC for DFW departures to IAH.
The route is DFW direct ACT direct FST direct AUS direct IAH for FL000
(SFC) to FL 410 beginning at 1845Z and ending at 2100Z

# Special Use Airspace (SUA) status. 

*Includes any restricted airspace like Military Operations Areas (MOA)
or ATC Assigned Airspaces (ATCA).*

**[Description of Item]{.underline}**

SUAs are restricted portions of airspace that are reserved for military
use only. The times they are reserved can vary quite a bit week to week.
They may be reserved 24 hours a day, or 8 hours for one day, or for 2
hours every day. It completely depends on the mission the military is
trying to accomplish in that airspace.

While these areas are reserved (referred to as "being HOT"), commercial
traffic is not allowed in these chunks of airspace for obvious reasons.
This becomes a constraint that flight planners have to consider when
planning a route. If these areas are known well in advance (4+ hours)
and distributed, then things typically work smoothly from a flight
planning perspective. The problem is, both scheduling and distribution
need improvement.

The SUA status data item would consist of a list of restricted
airspaces, and what times they are reserved. This would probably be
organized by ARTCC boundaries and the SUAs contained within them.

Each SUA is a 4-D exclusion zone in the airspace. The Flight Levels,
times, and geography of each SUA's active state can already be described
using known data. The time element for each active SUA is currently
known to some entities in the NAS (DOD) but not accurately disseminated.

**[Benefits]{.underline}**

The flight planners could use as much of this information as they can
get, as far in advance as they can get it. The optimum notification time
would be somewhere between 2-6 hours before an aircraft departs to get
the maximum benefit of flight planning. However, even if this airspace
is "released" while an aircraft is in flight, direct routes through the
airspace may be suggested, and/or planned for to receive some benefit.
The amount of fuel saved by not having to fly around an SUA can be very
significant, as well as time saved, which has to be taken into account
when planning gate space, etc.

The current level of uncertainty about SUA status leads air carrier
dispatchers and crews to carry sufficient fuel to fly around an
intervening SUA even though the SUA will reportedly be open. This is
done to prevent diversions if the SUA opening forecast is incorrect. The
cost of carrying this 'insurance' fuel to air carriers is significant.
Timely and accurate SUA information would lead to reductions in
commercial air carrier fuel use.

FAA facilities would also benefit from this information being
distributed beyond the local area. Typically a controller has to call to
find out if an airspace is "hot" or not. Flow management specialists
could take these released airspaces into account when trying to resolve
problems, particularly severe weather reroutes. The Flight Service
specialists would also benefit by being able to provide the GA pilots
with more accurate information pertaining to restricted areas,
especially if flying VFR.

**[Source of the Data]{.underline}**

This SUA status data would be provided by the FAA's IFR control facility
in whose airspace the SUA lies. FAA would get this information from the
scheduling authority responsible for that airspace, basically the branch
of the military that owns that airspace.

Currently, the SAMS system being developed by the FAA (ATO-130) will be
responsible for dissemination of this data. Currently, the SAMS system
is being installed at all ARTCCs (by Nov97). They will exchange
information amongst FAA facilities over ADTN for now or possibly NADIN
in the future. The central database and/or server will be located at the
ATCSCC. However, this data is initially just going to be used for
historical purposes, not for real-time planning. Eventually, SAMS is
scheduled to be interfaced with ETMS (4Q98/1Q99) for wider distribution
and hopefully get closer to a real-time tool. Also, SAMS will be
interfaced with MAMS which is the military scheduling software being
developed by the DoD.

**[Nature of the Data]{.underline}**

Besides normal routine schedules, things can get interesting when the
military reserves a chunk of airspace for a considerable length of time,
and then due to any of a number of reasons, either decides not to use
the airspace or only uses it for a short time. The commercial aviation
users would like to be able to use this airspace during these times.
There are many groups working on that issue, but it all starts with
electronic SUA schedule passing airspaces, both in planning timeframes
and in real time.

There are 4500(?) SUAs in the CONUS airspace. The minimum number of
elements for each of these SUAs would be (on a daily basis): the id of
the restricted area (e.g. R-2508), start of reserved time and release
time, and altitude reserved, for each slot the military needs during the
day. There would also have to be some mechanism for allowing time for
aircraft in the airspace to clear the restricted zone before time the
military actually is going to use the airspace. This data would have to
be updated whenever it changes, and if nothing else, at least daily.

The SAMS/MAMS program is working the reliability and accuracy issues.
Currently, the data is very unreliable, except about 30 minutes before
an event.. With the development of these automation tools, the status
data should be accurate further in advance most of the time.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

The SUA status information will be available on ADTN (or possibly NADIN)
by late November 1997. There will obviously be some testing involved to
determine the value of the data they have, and what else is needed.
However, once that settles down, AOCNet could capture that data directly
from ADTN. Again, content of the data and value of what's there will
have to worked out.

# Predicted Demand and Capacity for Sectors and Fixes

**[Description of Item]{.underline}**

The airspace over the United States is divided into volumes known as
sectors. Roughly speaking, a separation controller has responsibility
for one sector. Depending on the level of traffic, sometimes two or more
sectors are temporarily combined and controlled by a single controller.
A fix is a named point on the ground that is used for navigation.

Since a separation controller can safely handle some maximum number of
aircraft at once, it is important to predict the number of aircraft that
will be in a sector or that will pass over a fix; if this predicted
number exceeds the controller's capacity, then this is an indication
that steps should be taken to avoid this controller from being
overworked.

The number of aircraft in a sector or passing over a fix is termed the
*demand*; there is more than one way to measure demand, as discussed
below. The maximum demand that a separation controller can safely handle
is the *capacity* of that sector; usually only an approximation to the
capacity called a threshold is available, as discussed below. Sectors
and fixes will be referred to collectively as airspace.

**[Benefits]{.underline}**

*Who would use this data?* Traffic managers already have access to this
data through the Enhanced Traffic Management System (ETMS) and use it
when deciding what traffic management actions should be taken to deal
with congested airspace. Airlines could use this data to get an idea of
what airspace threatens to be congested and, therefore, might be the
subject of traffic management actions.

*To what use or uses would this data be put?* Conceivably, airlines
could take this data into account when constructing flight plans so that
flights would avoid heavily loaded airspace. This would be especially
useful during bad weather, when congestion problems tend to be more
severe.

*What would be the benefits in terms of efficiency and safety?* If
airlines had several hours notice of where congestion problems were
brewing, then by filing flight plans that avoided these areas,
congestion could be reduced, and the resulting need for a traffic
management action could be reduced and perhaps eliminated. Also, by
avoiding last-minute route adjustments, airlines would be better able to
more accurately judge fuel needs.

**[Source of the Data]{.underline}**

*Predicted sector demand.* The Enhanced Traffic Management System (ETMS)
predicts the number of aircraft that will be in each sector for twelve
hours in advance. To do this, ETMS models the trajectory for each flight
and predicts the minute that the flight will enter and leave each sector
that it traverses. ETMS stores this minute-by-minute prediction of the
sector that each flight is in. ETMS then adds up the individual flights
to obtain an aggregate, predicted sector demand.

Currently, the predicted sector demand provided by ETMS has the
following characteristics.

-   The sector demand predictions are aggregated by fifteen-minute
    intervals.

-   The number given for each fifteen-minutes interval is the peak
    number of aircraft that are predicted to be in that sector during
    any minute in that interval. For example, if five aircraft are in
    the sector for the first five minutes of the interval, eight
    aircraft for the next five minutes, and three aircraft for the final
    five minutes, then the sector loading that ETMS currently reports
    for this interval is eight.

    Using the peak count during the fifteen-minute interval is the
    current way that ETMS reports sector demand, but there has been
    considerable discussion of changing this to some measure that gives
    a better picture of the traffic situation.

    *Predicted fix demand.* ETMS treats fixes in a similar way to
    sectors. For each fix, ETMS predicts the minute that each flight
    will pass over that fix over the next twelve hours. ETMS adds up the
    individual flights to obtain an aggregate, predicted fix demand.
    Currently, the predicted fix demand provided by ETMS has the
    following characteristics.

-   The fix demand predictions are aggregated by fifteen-minute
    intervals.

-   The number given for each fifteen-minutes interval is the total
    number of aircraft that passes over the fix during that interval.
    For example, if one aircraft passes over the fix during each minute
    in the fifteen-minute interval, then the demand that ETMS currently
    reports for this interval is fifteen.

    Again, there has been considerable discussion of changing the way
    that ETMS measures fix demand.

    *Predicted capacity*. Data on true capacity is apparently not
    available from any source. However, ETMS provides data on
    *thresholds* for sectors and fixes, which can be interpreted as an
    approximation to capacity. ETMS has a default threshold for each
    sector and fix, but a traffic manager can change this number for any
    time interval over the next twenty-four hours. The default might be
    changed to reflect bad weather, equipment outages, or a change in
    the number of controllers that are working a position. Also, a
    traffic manager might change the threshold to suit his or her
    individual working style. The significance of the threshold to the
    traffic manager is that ETMS's Monitor/Alert function signals an
    alert if the demand exceeds the threshold; a traffic manager might
    set the threshold to a lower or higher level to increase or decrease
    the sensitivity of Monitor/Alert.

    In short, ETMS does not contain true capacity data. It does,
    however, contain the threshold for every sector and fix for every
    fifteen-minute period over the next twenty-four hours. It is these
    threshold values that are shown to the users of the Aircraft
    Situation Display (ASD).

    *Other sources.* ETMS apparently is the only possible source of this
    data.

    **[Nature of the Data]{.underline}**

    *TMD file.* There are two forms in which ETMS currently provides
    this data. The first form is in what is called the TMD file, where
    TMD stands for Traffic Model Demand. This file is produced every
    five minutes, and it contains the sector demand and the threshold
    for each fifteen-minute interval over the next 2 ¼ hours, i.e., it
    contains the data for the current fifteen minute interval and for
    the following two hours. The TMD file only contains data on the
    sectors and fixes for which there is an alert, i.e., for which there
    is some fifteen-minute interval over the next 2 ¼ hours for which
    the demand exceeds the threshold. This is a binary file that is
    provided to every ETMS site and is used for part of the ETMS
    Monitor/Alert display. This file only contains the counts and not
    the specific flights. A TMD file is typically under 100 KB. (The TMD
    file also contains demand and threshold data for arrivals and
    departures for all alerted airports and for roughly the thirty
    busiest airports in the United States.)

    *Request data.* A drawback to the TMD file is that it only looks 2 ¼
    hours ahead even though ETMS stores this data for twelve hours
    ahead. An FAA user of ETMS can request the predicted sector demand
    and the threshold for a longer time period, and the ASD can display
    this data either in a textual list or in a bar chart. If it is in a
    textual list, the specific flights that contribute to the demand in
    each fifteen-minute interval can also be listed, along with detailed
    data about each flight. Request data is not provided at regular
    intervals but only when it is requested; when a request is made, the
    current data in the ETMS databases at that moment is returned to the
    requester. Conceivably, all of this data could be put on AOCNet. If
    a file contained the counts and threshold values for a single sector
    for twelve hours, the file would be quite small, e.g., a kilobyte or
    two. The file would be bigger if more sectors were included or if a
    list of flight were included; how big would depend on how many
    sectors were included or how much data was included for each flight.

    *How reliably will the data be provided?* This data can be provided
    very reliably since it comes from ETMS, which is an operational FAA
    system. That is, ETMS outages that would prevent this data from
    being generated and sent are very rare.

    *How accurate will the data be?* Since this data consists of a
    prediction of a highly uncertain future, completely accurate
    predictions should not be expected. There are three main
    contributors to inaccuracy.

-   Inaccurate input data: If ETMS does not have accurate data about the
    flights that will fly, then it cannot predict accurately. Efforts to
    improve the quality of the data received by ETMS are always being
    pursued, e.g., through the Collaborative Decision-making Program.

-   Inaccurate modeling by ETMS: When modeling the trajectory of an
    individual flight and hence predicting when it will be in a sector,
    ETMS makes a number of assumptions about that flight, e.g., the
    ascent and descent profiles that it will fly, the speed at which it
    will cruise, and its route of flight. Insofar as the modeling
    assumptions that ETMS makes are incorrect, this will tend to make
    the predictions inaccurate. Efforts to improve the ETMS modeling are
    always being pursued.

-   Random factors: For example, if at the last minute a mechanical
    problem prevents an aircraft from flying, then all the predictions
    that ETMS made about the sectors that that aircraft would fly
    through will be wrong. There is probably no good way to predict
    random events.

    There is no overall measure of the accuracy of the ETMS predictions.
    It should be noted, however, that these ETMS predictions are the
    data that goes to the traffic managers who use ETMS, so it would
    contribute to a common understanding of the problems if the same
    data went to the airlines and other NAS users.

    **[What Must be Done to Get this Data on AOCNet?]{.underline}**

    *TMD file*. This file is produced at the Volpe Center every five
    minutes. Since the Volpe Center is connected to AOCNet, with a
    modest amount of work this file could be put on AOCNet every five
    minutes as it is produced. While there is no technical problem to
    putting the TMD file on AOCNet, there is, however, a procedural
    problem. This file could not be put on AOCNet until the FAA gave its
    approval. Since this file contains thresholds, which sometimes do
    not have a straightforward interpretation, the FAA might be
    reluctant for these thresholds to go outside the FAA.

    *Request data.* It would be necessary to make a request if more than
    2 ¼ hours of data is needed or if data is needed about a sector or
    fix that is not alerted. There is more than one way that this could
    be handled. One way would be for ETMS to request a file analogous to
    the TMD file but that had sector counts and thresholds for, say,
    nine hours rather than 2 ¼, and to periodically put this on AOCNet.
    Another way would be to imitate the arrangement used for the
    Aggregate Demand List. That is, an airline would register to get the
    data on a particular sector or fix, which would be sent to that
    airline at intervals. One can imagine other ways to distribute this
    data.

    *Other data.* It might be that other forms of this data would be
    useful. For example, a picture that showed the alerted sectors could
    be generated in some graphics format and made available, if this
    would be useful.

    *Needed work*. The following must be done before this data can be
    placed on AOCNet.

-   It must be decided what data should go on AOCNet. Should it be the
    current TMD file? An enlarged TMD file? Requested data? Graphical
    data?

-   Approval from the FAA is needed before any of this data is placed on
    AOCNet.

-   How will this data be put on AOCNet? Will it be sent to a database
    from which airlines will fetch it? Will it be streamed to the
    airlines?

-   Software development will be needed at Volpe to implement whatever
    decisions are made. This development would be quite modest if it
    were decided that the current TMD file should be sent. The needed
    development would increase if other decisions were made.

    *What manual data entry would be needed?* No manual data entry would
    be needed since this data is already in ETMS in digital form.

    *When could this data be available digitally so it could be placed
    on AOCNet?* Once it is decided exactly what should be distributed,
    once FAA approval is obtained, and once funding is made available
    for the software development work that would need to be done to get
    this data from ETMS to AOCNet, this data should be available very
    quickly, i.e., within a period of months or perhaps even weeks,
    depending on the format in which the data is distributed.

# Miles-in-Trail (MIT) Restrictions {#miles-in-trail-mit-restrictions .unnumbered}

**[Description of Item]{.underline}**

MIT restrictions are spacing constraints put on aircraft to help keep
space between adjacent aircraft beyond safe separation criteria, to help
manage the flow of traffic. These restrictions are implemented between
aircraft at ARTCC boundaries, over fixes, off runways, or anywhere that
extra separation is needed. Reasons for the restrictions are usually
volume of traffic or weather.

MIT restrictions can ripple thru the system easily. Quite often, ARTCCs
will "pass" the restriction given to them, onto the adjacent facility.
They can pass the restriction as is, or increase it. This allows that
facility extra space to merge and maneuver the traffic to get the proper
spacing to meet the requirement of the upstream ARTCC. It is not unusual
for these restrictions to back up to an airport, and cause some level of
ground delay.

MIT restrictions can be *static* (usually written in Letters of
Agreement (LOAs) between facilities) such that they occur everyday; or
they can be *dynamic* such that they occur irregularly, or they can be
*dyna-stats* such that they occur on a regular basis but are not in
LOAs. These restrictions usually are only in effect for an hour or two
at a time, but may be repeated multiple times during a day (e.g. during
rushes). They may be limited for aircraft at specific altitudes, or for
aircraft at all altitudes over a certain navaid.

**[Benefits]{.underline}**

The MIT restriction data would be used by flight planners to plan for
potential delays, or replan around them. Unfortunately, there is usually
not a lot of lead time before an MIT restriction goes into effect. But
for the restrictions that do stay in place for some time, especially the
ones that back up to an airport, the flight planners could certainly use
that information to try and avoid the problem, if not help resolve it.

The ATCSCC and other FAA facilities have a pretty good handle on what
MIT restrictions are affecting them. However, a benefit of having these
in electronic form is for "what-if" analysis. If the automation in the
facilities could be aware of all the restrictions in place, then
possible resolutions to other problems would be much more accurate.

**[Source of the Data]{.underline}**

The data on restrictions would come from the ARTCC TMU logs, to get both
internal restrictions to an ARTCC, as well as inter-ARTCC restrictions.
This information is usually handwritten into a facility log, and
possibly typed in to an electronic log as text. The ATCSCC also records
in their logs restrictions that affect multiple facilities.

**[Nature of the Data]{.underline}**

The restrictions would typically be one line of text. The message would
have to include: which facility is requesting the restriction, which
facilities are getting a restriction, the size of the MIT to be
implemented, what specific traffic does the restriction apply to, time
restriction start and stops, and what the reason for the restriction is.
For example: ZAU to ZOB, ORD Landing Traffic, 15 MIT over FWA, until
1700 due to volume.

Depending on the weather and traffic conditions, there may be many
restrictions in a facility for any given hour. At any given time in the
NAS, there may be any number of restrictions in effect; possibly some
number less than 10 to some number greater than 30. These restrictions
would be updated as new ones are created, or old ones expire.

Currently these restrictions are requested amongst facilities via
telephone and notes are made. Based on workload, the notes may not get
transcribed into the logs until some time after that. As of June 97,
there will be a formal process for a facility to request a restriction.
This will insure that proper analysis has been done both locally and
nationally, to measure the effects of a restriction and any alternatives
that are possible. Part of the process is also a thorough critique of
every restriction as to its desired result and evaluation as to the
success of meeting that result. This process should help the accuracy
and necessity of restrictions that are implemented in the system.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

There is currently no system that AOCNet could interface with to get
this data. The MIT restrictions would have to be manually entered into
some automation system (of which FAACnet is the only thing I know of
being planned) for AOCNet to interface with to get these manual entries.
They would probably be entered by a specialist at the ARTCC TMU or the
ATCSCC. An alternative would be to parse the text of the position logs,
which would be difficult. A standard screen format could be developed as
part of the formal restriction process effective Jun97, which would make
entering restriction information easier and more uniform. Then this
information could be loaded into a database accessible to FAACnet or
AOCNet or both. These are just some ideas.

Static MIT restrictions as codified in interfacility LOAs could be
placed in an accessible database for the use of flight planners and
automated flight planning systems. As LOAs were created, deleted or
amended this database would have to updated probably by the requesting
facility. The same is true for '*dyna-stats'* which are defined as
recurring static restrictions that are active for defined periods.

# Active Re-Routes {#active-re-routes .unnumbered}

**[Description of Item]{.underline}**

If there were no bad weather or congestion, then for each flight an
airline would file a flight plan with the route that seemed best to that
airline; this route would take into account winds, the need to make up
delay, or any other factors that were important to the airline.
Sometimes, however, the airline will not be able to fly this desired
route because of bad weather, congestion, or other factors, and this
flight will need to be rerouted.

It is the severe weather specialists at the Command Center who are
responsible for conferring with airlines, field personnel at the
centers, and then assigning (or at least recognizing) the reroutes that
are to be used. These specialists put these reroutes on the Traffic
Situation Display and project these on one of the big screens at the
front of the Command Center. When other specialists at the Command
Center need to make decisions, they can see what the active reroutes are
and adjust their decisions accordingly. The severe weather specialists
can also send these reroutes to the field to be displayed on the ASD.

Currently, as reroutes are defined or changed, an advisory is sent to
the airlines and affected FAA personnel. There is not, however, a good
way to send out at once a list of all the active reroutes, and there is
not a good way to distribute reroute data in a well-defined, digital
format. It is these gaps that this data item is meant to address. This
data item would consist of the list of active reroutes and the following
data for each active reroute.

-   Name.

-   Projected expiration time.

-   Reroute in a field 10-like format. That is, a sequence of fixes and
    airways are given that define the route.

-   Distance along the reroute.

-   Other information might be included such as the fixes along an
    airway.

    **[Benefits]{.underline}**

    *Who would use this data?* The airlines are the potential users of
    this data.

    *To what use or uses would this data be put?*

    *What would be the benefits in terms of efficiency and safety?*

    **[Source of the Data]{.underline}**

    The data on active reroutes recognized by the severe weather
    specialists currently is kept in the Traffic Situation Display (TSD)
    in digital format. The TSD will eventually replace the Aircraft
    Situation Display as the primary user interface to the Enhanced
    Traffic Management System. The severe weather specialists currently
    use a prototype version of the TSD for displaying reroutes and other
    tasks. The TSD could send a file of active reroutes to the Volpe
    Center, which in turn could put it on AOCNet. Details of how this
    would be done are the responsibility of the Data Integration
    Subgroup.

    Other than the TSD, I can think of one other possible source of this
    data. If the advisories were sent in a standard format rather than
    in the free-form text format in which they are now sent, it would be
    possible for a database of active reroutes to be built up. Since
    this possibility is covered in data item on advisories, it will not
    be discussed here.

    **[Nature of the Data]{.underline}**

    *How much data is involved?* A file containing data on all the
    active reroutes would be at most a few kilobytes.

    *How frequently is the data updated?* This frequency with which this
    data changes depends greatly on the situation. When there are no
    problems, hours might elapse with no new reroutes. When there are
    problems and two or three severe weather specialists are working,
    there might be a change in a reroute (i.e., creating, deleting,
    editing) every minute or so. To be determined is how frequently a
    file containing the active reroutes would be distributed. For
    example, one could be sent every five minutes, or one could be sent
    every time a reroute is changed.

    *How reliably will the data be provided?* The data could be provided
    reliably. Entering the reroutes on the TSD is a required duty of the
    severe weather specialists, who are on duty twenty-four hours a day.
    The TSD is an operational FAA system that can be expected to be
    operational virtually all of the time.

    *How accurate will the data be?* The data can be expected to be very
    accurate since a specialist who is responsible for a geographic area
    enters the data; the data is then graphically displayed so that the
    specialist can immediately see if an error was made during data
    entry. (At the moment there is one exception to the claim that this
    data would be accurate. The TSD currently does not accept a jet
    route to jet route intersection, so the specialist has to use a fix
    that is close to an intersection to define the reroute. This problem
    with the TSD will be fixed.)

    **[What Must be Done to Get this Data on AOCNet?]{.underline}**

    Since the active reroute data already exists in digital format on a
    system that can communicate with the Volpe Center, much of the work
    needed to get this data on AOCNet has already been done. Work that
    remains to be done is the following.

-   Secure FAA approval for this data to be distributed over AOCNet.

-   Determine the format in which the data should be distributed. For
    example, should the data be in a text file? Should it be in a
    graphical format that one could use as an overlay? Should it be a
    picture of an entire screen, as would be used in whiteboarding?

-   Determine how frequently the active reroutes should be sent. Should
    the complete file of active reroutes be sent, say, five minutes? Or
    should it be sent every time a change is made to a reroute?

-   Decide what method should be used to distribute the active reroute
    data. For example, should each file be sent to every airline, or
    should each file go to a database from which airlines could retrieve
    the data?

It is expected that the Data Integration Subgroup will deal with these
issues. Since this data already exists in digital format, this data
could be on AOCNet soon after these issues are settled; the work
involved is modest (at least if a simple distribution scheme is chosen
such as sending each file to every airline).

**[Other Issues]{.underline}**

When the TSD is fielded in 1998, the plan is that active reroutes will
be sent from the Command Center to the TSDs at FAA facilities in the
field. If airlines also had TSDs, then it is conceivable that the active
reroutes could be distributed to the airlines at the same time and in
the same format that the reroutes are distributed to FAA field
facilities. This approach is attractive since the airlines could use the
TSDs to display not only reroutes but also much more. As far as I know,
discussion has not yet started of the technical, administrative, and
political problems that would arise in providing TSDs to the airlines.

# Global Positioning System (GPS) Reliability Information

*Global Navigation Satellite System (GNSS) is a superset of GPS
including Russian GLONASS satellites*

**[Description of Data Item]{.underline}**

The Global Positioning System (GPS) is a worldwide, precise navigation
system that gives highly accurate position, time and altitude
information to the user. GPS is used today in the same way as
TACAN/VOR/Loran C radio navigation systems, and provides a direct
lat/long readout. Its advantages over standard land based radio
navigation aids include economy, reliability, higher accuracy, less
infrastructure, and the ability (by installing land based systems,
modifying the GPS satellites, or launching augmentation satellites) to
provide positioning data reliable and accurate enough for instrument
landings in minimal visibility conditions.

**[Benefits]{.underline}**

Coverage and current status of the signal is currently being tracked by
the USAF and passed to the US Coast Guard, who provides it to the public
over the Internet in parsable, digital messages. An email request will
put users on a mailing list for the information.

Information is put out daily between noon and 1300 of the affected day.
Predicted failures are published via NANU's, Notices Advisory to Navstar
Users as soon as the information is available.

Military, International and FAA Facility NOTAMs are published on the
NOTAM(D) circuit advising of periods and areas of known or forecast GPS
unreliability. Currently these NOTAMs are not easily identifiable and
require users to scan all available NOTAMs to discover them.

Areas of GPS unreliability can exist for a temporary period for unknown
reasons. Pilot reports of GPS signal loss etc. are not currently
disseminated in a rapid and reliable manner to other users. Recent
incidents in Europe and the United States of commercial flights
experiencing extended GPS signal loss were only reported to all users
through commercial news publications.

As the information is not currently readily available, distribution via
the AOCnet is essential in a comprehensive and easily accessed format.

Airline dispatchers must ensure that properly equipped aircraft (i.e.,
Inertial systems) are operating in areas that may have less reliable GPS
signals, and that there may be landing delays during inclement weather
due to degraded approaches, in addition to notifying flight crews of GPS
status changes. ATCSCC's will want to know GPS status in the future to
consider adding aircraft separation due to degraded navigation accuracy
in an affected area.

**[Sources of the Data]{.underline}**

1.  US Coast Guard- http://www.navcen.uscg.mil/

2.  Directly from the USAF at Falcon AFB, CO. The coasties get it from
    there.

3.  FAA Facilities (currently through NOTAM(D) publication)

4.  Military Facilities (currently through NOTAM(D) or MIL NOTAM
    publication.

5.  Pilot reports to AOCs and FAA Facilities

6.  International aviation facilities (currently through INTL NOTAMS)

**[Nature of the Data]{.underline}**

1.  NANU Files are 1 page of alphanumeric characters for the daily files
    and roughly 150 alphanumeric characters for the NANUs. A daily file
    is sent between 0800-1300 each day. NANUs' are sent out as needed,
    roughly twice a week. Data should be highly reliable and accurate.

2.  NOTAM(D) in a non-standardized text format describing location and
    duration.

3.  MIL NOTAMS in a non-standardized text format

4.  Pilot reports usually via VHF or HF Voice with AOCs or ATC

5.  International Aviation interests should be encouraged to forward GPS
    NOTAMS via ARINC/SITA/AFTN circuits to the NOTAM(G) system for
    dissemination to all users.

6.  A NOTAM(G) system must be created that allows users real time access
    to current GPS information in a concise and organized manner. Access
    should be via AOCnet, ARINC, SITA, and AFTN to ensure all users have
    access.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

1.  USCG Data can be received automatically via the Internet. Should be
    relatively easy to retransmit the data to the AOCs. No manual data
    entry required.

2.  USAF information should be transmitted directly to the NOTAM(G)
    system.

3.  3\. FAA Facilities must be required to publish NOTAM(G) information
    as soon as available to the NOTAM(G) system.

4.  Militiary facilities should be required to publish GPS information
    to the FAA NOTAM(G) system.

5.  ATC facilities, AOCs and other aviation interests should be required
    to forward pilot reports of GPS problems to the NOTAM(G) system.

6.  International Facilities should be encouraged to forward GPS
    information to the

7.  NOTAM(G) system via ARINC, SITA, AFTN, or AOCnet connection. ICAO
    and IATA should be encouraged to create a standardized,
    international NOTAM(G) system.

8.  A NOTAM(G) system must be created with appropriate policies and
    procedures.

**[Other Issues]{.underline}**

> Regulatory

1.  What are the requirements to avoid areas of GPS unreliability based
    on pilot reports?

2.  Is the US military required to notify users of operations that may
    impact GPS reception ?

3.  Future

4.  The installation of LAAS and WAAS ground based systems to augment
    GPS will require a NOTAM system. Include LAAS and WAAS in NOTAM(G) ?

5.  A common NOTAM(G) format needs to be created to allow machine
    parsing of information.

6.  ADS-B envisions using GPS location information for ATC. 4D areas of
    GPS unreliablity need to be available graphically as well as
    textually for NAS utilization planning.

# Oceanic Demand (Track Loading by time) 

**[Description of Item]{.underline}**

A list of flights intending to fly a given oceanic track and flight
level ordered by time. Best approach to relate the time variable to the
list is to select a fix crossing time on the track that is meaningful to
both users and flow management. In this convention the secondary
variable is flight level so the list could be generated in time order
crossing the fix with another column stating flight level. It may not be
necessary to include flight level since this info may present a level of
detail that is unnecessary.

Example:

TRACK R220

FLT \"NATES\" CROSSING TIME REQ. FLT LEVEL

NWA17 0107Z 350

UAL 851 0109Z 310

DAL625 0130Z 350

JAL9 0130Z 350

NWA7 0132Z 350

**[Benefits]{.underline}**

Who would use this data? Traffic managers at some facilities already
have access to this data through the internal systems and use it when
deciding what traffic management actions should be taken to deal with
congested airspace. Facilities who lack this information would like to
have access to it (ZAN). Airlines could use this data to get an idea of
what oceanic tracks

are saturated and therefore present an undesirable risk of reroute or
non-optimal cruse altitude.

To what use or uses would this data be put? Conceivably, airlines could
take this data into account when selecting oceanic trajectories so that
flights would avoid heavily loaded track. As tracks become congested
they lose their overall appeal to the user even if they offer the
minimum time or burn by comparison to other tracks. This would be
especially useful during unusual jet stream geometries and periods of
upper air turbulence, when congestion problems tend to be more severe.

What would be the benefits in terms of efficiency and safety? If airline
dispatchers, who are the creators of the traffic congestion, knew a
track was already congested while they were examining route alternatives
they might consider less congested tracks over the optimum tracks in
terms of time/burn. Similarly \"early filers\" could at a later time
reassess the risk to their flights and in some cases change the route.
This migration to less congested tracks would tend to spread out demand
consistent with the carrier\'s priorities rather than by some ATC
initiative or traffic management action. Also, by avoiding in-flight
route adjustments, airlines would be better able to more accurately
judge fuel needs in the flight-planning phase.

**[Source of the Data]{.underline}**

Users. The users are the ultimate source of the data and therefore the
users participating in the track loading are ideally those tasked to
supply the data. However the data may already exist in certain Oceanic
Air Traffic Control Centers who already process the data for oceanic
traffic control. In others facilities some automation may be needed to
compile the data in digitized form.

In the Atlantic the ACC at Gander NF would be the source for the
eastbound flow and the CFMU at Brussels would be the best source for the
westbound flow. In the Pacific Oakland and Anchorage could support the
westbound flow and Tokyo ACC would be the best source for the eastbound
flow.

**[Nature of the Data]{.underline}**

Currently the data exists in digitized form at the Gander NF ACC.
Brussels may also have the data and this will be followed-up. Oakland
Center in the U.S. has a program of coordinating slot of the West Coast
known as Track Advisory. For slot controlled airports track loading
information is provided by users and fed back to users directly via
Oakland center. Therefore for these slot controlled tracks adding the
data to AOCnet would provide a duplication of efforts. Anchorage center
is interested in the data and expressed an interest in the helping to
provide it. Tokyo center interest is not known at this time but a
preliminary discussion will take place in October at the International
Oceanic Airspace Conference.

Here are the key contacts that will be instrumental in further
development of this element:

Gander Oceanic - Brian Bowers - 709-256-6753 Wayne Lyon 709-256-6751
(TECH)

Brussels CFMU - Kim Bravic - 0032-2729-9849

ATCSCC - Art Klassen - 703-904-4420

Oakland Center - Mike Jengo - 510-745-3469 Randy Park - 510-745-3475

Anchorage Center- Gordon Gruber - 907-269-1108

**[What must be done to get this Data on AOCNet?]{.underline}**

The following must be done before this data can be placed on AOCNet:

A convention or format for the info must be agreed to. Should it be the
current format at Oakland center? Requested data? Graphical data?
Approval from the FAA and other ATC authorities is needed before any of
this data is placed on AOCNet.

How will this data be put on AOCNet? Will it be sent to a database from
which airlines will fetch it? Will it be streamed to the airlines?

How often can it be refreshed and in what time frames should it be made
available ?

Software development will be needed at Volpe to implement whatever
decisions are made. For ACC\'s where the data does not yet exist, are
the users willing to compile it and transmit it to VOLPE/AOCNET

What manual data entry would be needed? No manual data entry would be
needed where the data already exists in digitized form. Other centers
will need to establish manual procedures or other means of compiling the
list. Finally if the ATC facilities cannot supply the data are the users
willing to provide it ?

When could this data be available digitally so it could be placed on
AOCNet?

Depends on the efforts made by each country and facility.

**[Other Issues:]{.underline}**

Oceanic Working Group versus CDM NAS Status. Either of these groups
could lead the effort but some coordination between the two group is
needed.

# Aircraft Capabilities

**[Description of Data Item]{.underline}**

Aircraft Capabilities asks the question, "does the aircraft have the
ability to accommodate ATC requests for changes?", e.g., vectors onto AR
routes, altitude changes. Can information be transmitted over the AOC
Net to ATC notifying them of what the aircraft is capable of doing?

**[Benefits]{.underline}**

*Who would use this data?* Center and Terminal Controllers and ATCSCC.

*How would the data be improved if it were on AOCNet?* Currently the
only way to find out if the aircraft has any number of capabilities is
for the Controller to ask the pilot.

*To what use or uses would this data be put*? ATC personal would know if
an aircraft was capable of changing altitudes. They would know if an
aircraft was overwater equipped and capable of taking AR routes to
alleviate congestion or avoid weather.

*What would be the benefits in terms of efficiency and safety*? It may
be faster and more efficient for the Controller to contact
[just]{.underline} the flights that may be capable of helping the
controller route aircraft away from weather or congestion.

**[Source of the Data]{.underline}**

The information would have to come from the individual airlines.
(*note:* Be aware of proprietary concerns. Airlines would probably not
want their competitors to know what mechanical problems they were
having.)

**[Nature of the Data]{.underline}**

The data would have to be updated as dispatchers received and added the
restrictive MELs to the release. There would have to be a mechanism in
place to transmit an aircraft limiting MEL to ATC. If there was an Air
Conditioning Pack out on a 737, that aircraft would be limited to FL250.
That restrictive data would have to be sent within a reasonable time,
through the AOC Net, in order for ATC to know they could not adjust that
aircraft's altitude above FL250.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

In the short term the AOC could send the "Aircraft Capability",
information over the AOC Net. We may look to the advent of the "New Age
Flight Plan" to accommodate "aircraft capability" information in the
future. (In addition to the current flight plan information, the new-age
flight plans contain: preferred climb profile, preferred departure
runway, preferred departure speed, projected timing over each fix en
route, acceptable altitude range (at each fix), required time of arrival
(RTA), fuel state (an indicator of how much holding can be endured), air
carrier preferences, and aircraft equipage (Flight Management System
\[FMS\] approach capability, weight, ILS approach capability for
Category I-II-III).

**[Other Issues]{.underline}**

Regulatory Issues : Since the PIC and AOC dispatcher must both approve
any significant change to the planned route of flight (See attached FAA
GC opinion) providing this information to the controller will not
alleviate the requirement for coordination between ATC, AOC and PIC for
air carrier flights. CDM has precipitated a growing paradigm shift away
from the ATC only deals with the PIC to a more collaborative ATC, PIC,
AOC view. The possibility of ATC negotiating route changes with the AOC
using automated tools and receiving the AOC and PIC concurrence from the
AOC should be explored.

Safety Issues : The air carrier through it's PIC and AOC personnel is
responsible for the safe operation of the flight. Currently ATC has
imposed route changes that in the judgement of the PIC or AOC degraded
the safety of flight. Better information flow between all participants
will reduce, and hopefully avoid these incidents.

Currently the Controller can retrieve aircraft capabilities simply by
asking the PIC. Even if the Controller has Aircraft Capabilities
information s/he should still verify that the aircraft in question has
the ability to fly overwater, or into icing conditions. The aircraft
could have an equipment failure enroute and it wouldn't have shown up on
the "New Age Flight Plan".

The text of FAA GC Opinion on CFR 14 part 121.663\<!DOCTYPE HTML PUBLIC
\"-//IETF//DTD HTML//EN\"\>\<div align=\"center\"\>

 

+-----------------------------------------------------------------------+
| December 24, 1990                                                     |
|                                                                       |
| Mr. Glenn Morse                                                       |
|                                                                       |
| Air Transport Association of America                                  |
|                                                                       |
| Eastern Regional Office                                               |
|                                                                       |
| 181 South Franklin Avenue, Room 601                                   |
|                                                                       |
| Valley Stream, New York 11581-1190                                    |
|                                                                       |
| Dear Mr. Morse,                                                       |
|                                                                       |
| This is in response to issue E13, Implementation of the Severe        |
| Weather Avoidance Plans, which is contained in the Northeast Corridor |
| System Safety and Efficiency Review, Volume 1: On-Site Reviews dated  |
| June 12, 1989. The Office of Aviation Safety of the Federal Aviation  |
| Administration (FAA) advised our office that \"The FAA General        |
| Counsel should provide the Air Transport Association with in          |
| interpretation of Federal Aviation Regulation 121.663 as it pertains  |
| to this issue \[Issue E13\].\"                                        |
|                                                                       |
| Section 121.663 provides:                                             |
|                                                                       |
| > *Each domestic and flag air carrier shall prepare a dispatch        |
| > release for each flight between specific points, based on           |
| > information furnished by an authorized aircraft dispatcher. The     |
| > pilot in command and an authorized aircraft dispatcher shall sign   |
| > the release only if they both believe that the flight can be made   |
| > with safety. The aircraft dispatcher may delegate authority to sign |
| > a release for a particular flight, but he may not delegate his      |
| > authority to dispatch.*                                             |
|                                                                       |
| The members of the flight standards team state, in Volume I of the    |
| Northeast System Safety and Efficiency Review, that issue E13, in     |
| pertinent part, is:                                                   |
|                                                                       |
| The Air Transport Association (ATA) also voiced concerns about        |
| \[the\] SWAP program implementation that results in an air carrier    |
| pilot being issued a new routing which calls for immediate departure  |
| when the aircraft is still at the gate. There appears to be a         |
| conflict with the Federal Aviation Regulations (FAR) which requires   |
| the air carrier\'s dispatcher to be included in the rerouting         |
| discussion.                                                           |
|                                                                       |
| Additionally, in your supplemental letter dated April 24, 1990, you   |
| state:                                                                |
|                                                                       |
| > *In order to keep traffic moving, a revised routing is issued to    |
| > the pilot. This may occur while he is number one for takeoff or at  |
| > some other time during taxi to the runway.*                         |
| >                                                                     |
| > *The basic question is: During SWAP, may Air Traffic Control issue, |
| > and the pilot accept without flight dispatcher concurrence, a       |
| > revised clearance with a new flight plan route in order to minimize |
| > delay and expedite the flow of traffic?*                            |
|                                                                       |
| We have researched the history of FAR 121.663, but that research did  |
| not reveal any preamble language that assists in explaining the       |
| provisions in FAR 121.663. Therefore, the language of FAR 121.663     |
| must be interpreted using the techniques of statutory construction.   |
|                                                                       |
| A fundamental rule of statutory constructions is that regulatory      |
| language should be given its plain and ordinary meaning. The language |
| in FAR 121.663 is clear in charging both the aircraft dispatcher and  |
| the pilot in command with the responsibility of mutually agreeing     |
| that the flight can be conducted safely. The implied intent of the    |
| regulation is to minimize judgmental errors by imposing dual          |
| responsibility for determining, at the time of dispatch, that the     |
| flight as planned in be conducted safely.                             |
|                                                                       |
| Another fundamental rule of statutory construction is that a          |
| particular section of regulation should be read with other pertinent  |
| parts of that regulation and interpreted as a whole. Section 121.663  |
| should be read in relationship with other pertinent sections in the   |
| FAR, and many of those pertinent sections are listed in your letter   |
| as \"relevant FAR 121 regulations\". Those pertinent sections would   |
| necessarily include weather conditions (e.g. FAR 121.599, Familiarity |
| with weather conditions). (Flight Standards Service advises us that   |
| the weather conditions impacting the Northeast corridor that prompt   |
| implementation of SWAP are normally frontal in nature and, thereby,   |
| can be anticipated and predicted reliably.\") Also, other pertinent   |
| sections that necessarily would be considered (many are listed in     |
| your letter in the specific sections discuss in this letter are not   |
| exhaustive) include fuel requirements in FAR 121.639 for domestic air |
| carriers and in FAR 121.645 for flag and supplemental air carriers,   |
| as well as the additional factors for computing the required fuel in  |
| FAR 121.647.                                                          |
|                                                                       |
| Section 121.647 requires that \"(d) Any other conditions that may     |
| delay landing of the aircraft\" be considered in computing fuel       |
| requirements. You state in your letter that \"The various FAA         |
| facilities do make SWAP routes available to the airlines. However the |
| routes are provided with the understanding that the airlines will not |
| file them\". Therefore, with knowledge of the SWAP routes, the        |
| dispatcher and pilot in command in calculating fuel requirements      |
| would consider, among other things, reported and forecast weather and |
| anticipated delays (i.e., diversions to SWAP routes). Therefore, if   |
| the dispatcher and pilot in command have considered the SWAP routes   |
| during their flight planning, and, if both the dispatcher and pilot   |
| in command agree that the flight can be conducted safely, and if the  |
| fuel and all other pertinent requirements of the FAR are met, then    |
| the pilot may accept a new flight plan route. However, if the SWAP    |
| routes are not considered in the flight planning, then the pilot in   |
| command must refuse the ATC. clearance, appraise the dispatcher of    |
| the new routing, analyze and discuss the new route with the           |
| dispatcher, and reach a joint agreement with the dispatcher that the  |
| flight may be conducted safely.                                       |
|                                                                       |
| We trust this satisfactorily answers your inquiry.                    |
|                                                                       |
| Sincerely,                                                            |
|                                                                       |
| Donald P. Byrne                                                       |
|                                                                       |
| Assistant Chief Council                                               |
|                                                                       |
| Regulations and Enforcement Division                                  |
+-----------------------------------------------------------------------+

\</div\>

# Distant Notice to Airmen (NOTAM D)

**[Description of Data Item]{.underline}**

Changes in the National Airspace System or at airports are publicized as
NOTAMs when they are temporary or when time does not permit issuance of
appropriate charts or publications. NOTAM D information pertains to
those changes associated with enroute navigational aids, civil
public-use airports, facilities, services and procedures. This
information requires wide dissemination to airline operation's offices,
local aviation companies, and interested users.

These NOTAMs will typically include information concerning airport
operating hours and airspace restrictions, airport rescue and fire
fighting capability, runway closures, lighting aids and airport and
enroute navigational aids.

NOTAM D information is critical to flight safety and efficiency. FAR 121
and FAA Handbook 8400.10 require that airline operation centers acquire
these NOTAMs and disseminate their contents to dispatchers, pilots and
other appropriate personnel. It is further required that this
information is taken into account during the preparation of the flight
plan and legal dispatch release.

**[Benefits]{.underline}**

The NOTAM D is currently available from the U.S. NOTAM System (USNS) and
distributed via the Weather Message Switching Center replacement
(WMSCR). WMSCR is the same communication net that provides weather
observations and forecasts from the National Weather Service.

Airline dispatchers, flight planners, pilots and air traffic managers
would use this information in a strategic sense when planning flights
and in a tactical sense when NOTAM information necessitates some revised
course of action while a flight is enroute.

In the planning stages, the user will plan a flight based on applicable
NOTAM information. The dispatcher or pilot could plan for contingencies
such as route restrictions due to navaid outages or takeoff and landing
weight limitations due to closed or reduced length runways. NOTAM
information might have an impact on the fuel requirements and alternate
selection, or an airport might even be closed at the planned arrival
time due to construction activity. Having timely and accurate
information, the operator could plan accordingly and adapt to the
current situation. Without advance awareness, operators would be much
more susceptible to delays or even unnecessary and costly flight
interruptions.

During the enroute phase, timely receipt of NOTAMs could greatly affect
the outcome of the flight. Certain NOTAM information may only require a
greater situational awareness but could necessitate a re-direction of
flight (i.e. diversion). The more timely this information is received,
the more quickly operators and traffic managers can react and plan the
most appropriate course of action. The result will be greater operating
efficiency, improved resource management and less passenger disruption.
Foremost is the obvious safety factor and, for this reason, FAR 121
requires that airline dispatchers monitor flight progress and advise
pilots, while enroute, of any changing conditions that may adversely
affect the safety of flight.

Since D type NOTAMs are currently available from USNS/WMSCR and from
private companies such as Jeppesen, providing them via AOCnet is not
critical to airline operation control centers at this time. However, due
to periodic delay problems with existing WMSCR lines, it is anticipated
that the AOCnet could provide a more reliable and timelier source. In
addition, since some types of NOTAMs (local and military) are not
automatically distributed to the airline operations community, AOCnet
could provide a [single]{.underline} source for [all]{.underline} NOTAM
types.

**[Source of the Data]{.underline}**

Presently, D type NOTAMs reside in the U.S. NOTAM System (USNS) host
computer in Plano, Texas. Airport operations personnel call the NOTAMs
into the local Flight Service Station. FSS specialists then format the
NOTAMs according to stringent guidelines and transmit them to the USNS
computer via service B network.

The USNS computer monitors transmissions for the presence of proper
coding, validity of the station identifier, format and effective times
before assigning a number and updating the NOTAM master file. The NOTAMs
are also sent to the U.S. NOTAM Office (USNOF) at the Air Traffic
Control System Command Center. If rejected due to format error, USNOF
revises and returns to the USNS computer. The USNOF can also edit or
correct any NOTAM.

The USNS relays the NOTAMs via NADIN to WMSCR and from there to user
receiving locations. Transmissions from WMSCR (same circuit used for
transmitting weather observations and forecasts) can be via ARINC
2400-baud line or X.25.

Initially, NOTAM D information is provided by airports and/or air
traffic control facilities so they could be considered the primary
source; however, FSS personnel are responsible for proper content and
format. In that respect, potential AOCnet sources are FSS, USNS
computer, WMSCR, or the USNOF.

## 

## [Nature of the Data]{.underline} 

NOTAM D data is stored in a master file in the USNS computer. The file
size is unknown at this time. D type NOTAMs are compiled for any airport
listed in the Airport Facilities Directory and for any enroute navaid.
These NOTAMs can be retrieved individually via NADIN request/reply.
NOTAM D information is updated on an ad hoc basis as new information is
passed from airport to FSS to USNS.

Reliability of the data is dependent on the timeliness of information
being relayed from an airport to the FSS and manual input by the FSS
specialist. From that point there should be no interruption in data flow
unless communication circuits fail. In the current environment, failures
or delays have been known to occur in the transmission from WMSCR. If
the data is routed to the AOCnet, reliability should increase. The
AOCnet could also be a single source for all NOTAM types. Accuracy of
the NOTAM data should not be an issue. FSS specialists already follow
specific format guidelines, and in addition, the USNOF monitors content
and accuracy.

## 

## [What must be Done to Get this Data on AOCnet?]{.underline}

Depending on the technical communication requirements, there appears to
be multiple options to interface the AOCnet. The only manual data entry
requirements would be that required of the FSS specialist in properly
formatting the NOTAMs.

This data should be available in digital form from either FSS or the
USNS computer and relayed to ARNIC and AOCnet via ADTN2000 or NADIN.

Any potential method will require FAA concurrence and coordination by
the technical communications experts.

# Local Notice to Airmen (NOTAM L)

**[Description of Data Item]{.underline}**

Local NOTAMs generally contain airport movement area information of a
less critical nature than other NOTAM types and typically address the
following conditions:

[Runway information]{.underline} -- that does not restrict or preclude
the use of a runway, such as cracks in a runway, soft edges, frost
heaves or personnel and equipment on a runway. If a runway becomes
unsafe due to these conditions, it is the responsibility of the airport
management to close or restrict the use of the runway or the affected
portions of the runway as appropriate (then requiring a NOTAM D). A
NOTAM L would also be issued for information on runways under
construction that may present a hazard to aircraft operations.

[Taxiway conditions]{.underline} -- pertaining to single or multiple
taxiway closures or could apply to personnel and equipment adjacent to a
runway.

A NOTAM L could also be issued for conditions that normally fall under
the NOTAM D category but are only effective for a short duration. Short
term runway closures, navaid and approach aid outages can be NOTAM(L)
information that users need and air carriers are required to have.

Although these NOTAMs should not affect safety of flight, they could
inform airline operators of potential hazards in airport movement areas.
For this reason and because local NOTAMs address other conditions of
short duration, FAA Handbook 8400.10 makes reference to the fact that
air carriers must provide some means for obtaining local NOTAMs.

**[Benefits]{.underline}**

Local NOTAMs are not disseminated beyond the regional Flight Service
Station (FSS). This presents a compliance problem for air carriers
because there is no automatic transmission to the aviation community as
with other types of NOTAMs.

Airline dispatchers, flight planners and pilots would benefit from NOTAM
L information more in the tactical sense than in the planning process.
NOTAM L information would not usually affect safety in the planning
stages due to the nature of the NOTAM L criteria or because the
condition is for a short duration. However, the air carrier would want
to consider taxiway closures, for example, since this could impact taxi
times and affect overall operating efficiency.

From a tactical aspect, local NOTAMs should be available so that air
carriers can make their own determination as to whether or not the
information is critical and should be passed along to enroute aircraft.
FAR 121 requires that airline dispatchers monitor flight progress and
advise the pilot, while enroute, of any changing conditions that may
affect the safety of flight. Since local NOTAMs may contain information
that could present a hazard to aircraft operations, the operator must be
provided the opportunity to evaluate the situation so that they can
react accordingly.

**[Source of Data]{.underline}**

Airport operators forward the applicable information to the local FSS
where FSS specialists format the NOTAM L and store in their local
database.

These NOTAMs are not distributed beyond the local FSS. It would be
necessary for Airlines and aircraft operators to obtain NOTAM L
information directly from the airport operation's office or from the
FSS. From a timing aspect, this would not be practical for large scale
airline operations.

Some airlines task their own airport personnel with the responsibility
of obtaining local NOTAMs and forwarding them to the airline operation
control center. This method would only suffice for on-line stations
where the airline employees its own personnel. For off-line alternates,
the information flow does not exist.

## [Nature of the Data]{.underline} 

Local NOTAMs are electronically stored at the responsible FSS. They may
or may not be stored electronically at airports. The file size is
unknown at this time.

There was a previous attempt to distribute local NOTAMs via the U.S.
NOTAM System (USNS) computer and the Weather Message Switching Center
Replacement (WMSCR). This is the same process by which NOTAM D and FDC
NOTAMs are disseminated to aviation users. This attempt caused a major
backlog in WMSCR that also affected weather transmission. There have
been no subsequent plans to distribute local NOTAMs beyond the FSS.

NOTAM L information is updated on an ad hoc basis as new information is
passed from airport operations to the regional FSS.

Reliability of the data is dependent on the timeliness of information
being relayed from the airport to the FSS. Since local NOTAMs are not
forwarded beyond the FSS, there are no other current factors. If other
types of NOTAMs can be processed via the AOCnet, local NOTAMs should not
affect other data streams, and AOCnet could become the
[single]{.underline} source for [all]{.underline} NOTAM types.

Accuracy of the NOTAM L data should not be an issue. FSS specialists
already follow specific guidelines for content and format.

## 

## [What must be Done to Get this Data on AOCnet?]{.underline}

Based on the current data source, there appears to be two options to
interface the AOCnet. Since format and reliability should not be issues,
the remaining factors would be procedural for airport operators or FSS
personnel and the communication link to AOCnet.

Airport operators could possibly transmit NOTAM L information to AOCnet
via ADTN2000. This data should be available in digital form from the FSS
where the NOTAM L is formatted. Perhaps FAA would agree to procedures
for FSS specialists to transmit local NOTAMs to AOCnet via ADTN2000.
Since airlines are required to obtain NOTAM L information in accordance
with FAA Inspector's Handbook 8400.00, and because there is no current
method for wide dissemination of local NOTAMs, it would be incumbent
upon FAA to approve and implement such procedures.

**[Other Issues :]{.underline}**

Since a previous attempt to distribute NOTAM(L) information over the
WMSCR was abandoned due to insufficient bandwidth the volume of NOTAM(L)
information needs to be assessed to insure AOCnet as currrently
envisioned has sufficient bandwidth to handle NOTAM(L) information.

# Flight Data Center Notice to Airmen (FDC NOTAM)

**[Description of Data Item]{.underline}**

FDC NOTAMs consist of information that is regulatory in nature
pertaining to flight including, but not limited to, changes to IFR
charts, procedures and airspace usage. FDC NOTAMs are issued for the
interim period until such chart changes are publicized.

These NOTAMs will typically include the following information:

[Interim IFR flight procedures]{.underline} -- such as airway structure
changes, instrument approach & departure procedures and airspace changes
in general.

[Temporary flight restrictions]{.underline} -- such as disaster areas,
special events with high degree of interest, restrictions in the
proximity of the President or other parties and hijackings.

[Title 14 CFR Part 139 certificated airport condition
changes]{.underline} -- such as snow affecting glide slope operation,
air defense emergencies, emergency flight rules, substitute airway
routes and special data.

FDC NOTAM information is critical to flight safety and efficiency. FAR
121 and FAA Handbook 8400.10 require that airline operation centers
acquire these NOTAMs and disseminate their contents to dispatchers,
pilots and other appropriate personnel. It is further required that this
information is taken into account during the preparation of the flight
plan and legal dispatch release.

**[Benefits]{.underline}**

FDC NOTAMs are currently available from the U.S. NOTAM System (USNS) and
distributed via the Weather Message Switching Center replacement
(WMSCR). WMSCR is the same communication net that provides weather
observations and forecasts from the National Weather Service.

Airline dispatchers, flight planners, pilots and air traffic managers
would use this information in a strategic sense when planning flights
and in a tactical sense when NOTAM information necessitates some revised
course of action while a flight is enroute.

In the planning stages, the user will plan a flight based on applicable
NOTAM information. The dispatcher or pilot could safely and efficiently
[plan]{.underline} for those contingencies that might impact route
selection, alternate selection, fuel load and approach minimums. FDC
NOTAM information could mean the difference between a "go" and "no-go"
decision. Having timely and accurate information, the operator could
plan accordingly and adapt to the current situation. Without advance
awareness, operators would be much more susceptible to delays or even
unnecessary and costly flight interruptions.

During the enroute phase, timely receipt of NOTAMs could greatly affect
the outcome of the flight. Certain NOTAM information may only require a
greater situational awareness but could necessitate a change in landing
procedures or weather minimums or even a re-direction of flight (i.e.
diversion). The more timely this information is received, the more
quickly operators and traffic managers can react and plan the most
appropriate course of action. The result will be greater operating
efficiency, improved resource management and less passenger disruption.
Foremost is the obvious safety factor and, for this reason, FAR 121
requires that airline dispatchers monitor flight progress and advise
pilots, while enroute, of any changing conditions that may adversely
affect the safety of flight.

Since FDC NOTAMs are currently available from USNS/WMSCR and from
private companies such as Jeppesen, providing them via AOCnet is not
critical to airline operation control centers at this time. However, due
to periodic delay problems with existing WMSCR lines, it is anticipated
that the AOCnet could provide a more reliable and timelier source. In
addition, since some types of NOTAMs (local and military) are not
automatically distributed to the airline operations community, AOCnet
could provide a [single]{.underline} source for [all]{.underline} NOTAM
types.

**[Source of Data]{.underline}**

Presently, FDC NOTAMs reside in the U.S. NOTAM System (USNS) host
computer in Plano, Texas. Information requiring issuance of an FDC NOTAM
originates from FAA Flight Standards District Offices (FSDO) or Air
Route Traffic Control Centers (ARTCC). This information is forwarded
directly to the National Flight Data Center (NFDC). Once received,
specialists in the U.S. NOTAM Office (USNOF) at the Air Traffic Control
System Command Center format and transmit the information as FDC NOTAMs
to the USNS computer.

The USNS assigns a NOTAM number and relays the FDC NOTAM via NADIN to
WMSCR and from there to user receiving locations. Transmissions from
WMSCR (same circuit used for transmitting weather observations and
forecasts) can be via ARINC 2400-baud line or X.25.

Initially, FDC NOTAM information is provided by airports, FSDOs or air
traffic control facilities so they could be considered the primary
source; however, USNOF personnel are responsible for proper content and
format. In that respect, potential AOCnet sources are USNOF, USNS
computer or WMSCR.

## 

## 

## [Nature of the Data]{.underline} 

FDC NOTAM data is stored in a master file in the USNS computer. The file
size is unknown at this time. FDC NOTAMs are compiled for a multitude of
reasons, and FDC NOTAMs generally require more text than other type
NOTAMs. Twice each day the USNOF transmits a list of FDC NOTAM
[numbers]{.underline} issued during the previous 12 and 24 hours. In
addition, FDC NOTAMs and cancellations can be retrieved individually via
NADIN request/reply.

FDC NOTAM information is updated on an ad hoc basis as new information
is passed from FSDO or ARTCC to the USNOF and to USNS.

Reliability of the data is dependent on the timeliness of information
being relayed from a FSDO or ARTCC to the USNOF and manual input by the
USNOF specialist. From that point there should be no interruption in
data flow unless communication circuits fail. In the current
environment, failures or delays have been known to occur in the
transmission from WMSCR. If the data is routed to the AOCnet,
reliability should increase. The AOCnet could also be a single source
for all NOTAM types.

Accuracy of the NOTAM data should not be an issue. USNOF specialists
already follow specific format guidelines, and monitor content and
accuracy.

## 

## [What must be Done to Get this Data on AOCnet?]{.underline}

Depending on the technical communication requirements, there appears to
be multiple options to interface the AOCnet. The only manual data entry
requirements would be that required of the USNOF specialist in properly
formatting the FDC NOTAMs.

This data should be available in digital form from either the USNOF or
the USNS computer and relayed to ARNIC and AOCnet via ADTN2000 or NADIN.
Any potential method will require FAA concurrence and coordination by
the technical communications experts.

# Military Notice to Airmen (Military NOTAM)

**[Description of Data Item]{.underline}**

Changes in the National Airspace System or at military airports are
publicized as NOTAMs when they are temporary or when time does not
permit issuance of appropriate charts or publications. Like most other
type NOTAMs, Military NOTAM information pertains to those changes
associated with enroute navigational aids, military airports,
facilities, services and procedures. Some of this information requires
wide dissemination to airline operation's offices, local aviation
companies, and interested users.

These NOTAMs will typically include information concerning airport
operating hours and airspace restrictions, airport rescue and fire
fighting capability, runway closures, lighting aids and airport and
enroute navigational aids.

NOTAMs pertaining to U.S. Air Force, Army and Navy navigational aids
that are part of the National Airspace System (NAS) and those pertaining
to joint-use military/civil airports shall receive dissemination in the
civil system in addition to dissemination in the military system. These
NOTAMs would be automatically disseminated as a NOTAM D via the U.S.
NOTAM System (USNS) computer and the Weather Message Switching Center
Replacement (WMSCR). WMSCR is the same communication net that provides
weather observations and forecasts from the National Weather Service.
NOTAMs pertaining strictly to military [only]{.underline} airfields are
**[not]{.underline}** disseminated in the **[civil]{.underline}**
system.

**[Benefits]{.underline}**

Military NOTAM information may be critical to flight safety and
efficiency for civil air carriers since some military airports are
authorized as [alternate airports]{.underline} for passenger and cargo
airlines. FAR 121 and FAA Handbook 8400.10 require that airline
operation centers acquire applicable NOTAMs and disseminate their
contents to dispatchers, pilots and other appropriate personnel. It is
further required that this information is taken into account during the
preparation of the flight plan and legal dispatch release. Some military
NOTAM information is currently available from USNS/WMSCR while
information pertaining to military [only]{.underline} airports is not
readily available.

Airline dispatchers, flight planners, pilots and air traffic managers
would use this information in a strategic sense when planning flights
and in a tactical sense when NOTAM information necessitates some revised
course of action while a flight is enroute.

In the planning stages, the user will plan a flight based on applicable
NOTAM information. The dispatcher or pilot could plan for contingencies
such as route restrictions due to navaid outages or NOTAM information
might have an impact on the alternate selection and fuel requirements.
Having timely and accurate information, the operator could plan
accordingly and adapt to the current situation. Without advance
awareness, operators would be much more susceptible to delays or even
unnecessary and costly flight interruptions.

During the enroute phase, timely receipt of NOTAMs could greatly affect
the outcome of the flight. Certain NOTAM information may only require a
greater situational awareness but could, in regard to an alternate
airport, necessitate an amendment to the original dispatch release
subject to the new fuel requirements. The more timely this information
is received, the more quickly operators and traffic managers can react
and plan the most appropriate course of action. The result will be
greater operating efficiency, improved resource management and less
passenger disruption. Foremost is the obvious safety factor and, for
this reason, FAR 121 requires that airline dispatchers monitor flight
progress and advise pilots, while enroute, of any changing conditions
that may adversely affect the safety of flight.

Only certain military type NOTAMs are available from USNS/WMSCR and from
private companies such as Jeppesen. Providing them via AOCnet is not
critical to airline operation control centers at this time; however, due
to periodic delay problems with existing WMSCR lines, it is anticipated
that the AOCnet could provide a more reliable and timelier source. In
addition, NOTAMs pertaining to military [only]{.underline} airfields, as
well as civil local NOTAMs (NOTAM L), are not automatically disseminated
to the airline operations community. AOCnet could therefore provide a
[single]{.underline} source for [all]{.underline} NOTAM types.

**[Source of Data]{.underline}**

Presently, Military NOTAMs reside in the U.S. NOTAM System (USNS) host
computer in Plano, Texas, but not all information is disseminated to the
civil aviation community. Department of Defense NOTAMs on facilities
that are part of the NAS are disseminated in the FAA NOTAM system. This
includes joint-use military/civil airports and all Alaskan military
facilities. Most of the military facilities are assigned to a tie-in FSS
for NOTAM purposes. FSS specialists then format the NOTAMs according to
stringent guidelines and transmit them to the USNS computer via service
B network. For Alaskan military facilities, base operations will
transmit NOTAMs directly into the USNS.

The USNS computer monitors transmissions for the presence of proper
coding, validity of the station identifier, format and effective times
before assigning a number and updating the NOTAM master file. The NOTAMs
are also sent to the U.S. NOTAM Office (USNOF) at the Air Traffic
Control System Command Center. If rejected due to format error, USNOF
revises and returns to the USNS computer. The USNOF can also edit or
correct any NOTAM.

The USNS relays the NOTAMs via NADIN to WMSCR and from there to user
receiving locations. Transmissions from WMSCR (same circuit used for
transmitting weather observations and forecasts) can be via ARINC
2400-baud line or X.25.

NOTAMs pertaining to military [only]{.underline} airfields (except
Alaskan) are [not]{.underline} disseminated beyond the USNS to the civil
receiving locations.

[All]{.underline} military NOTAMs are stored in the USNS computer so any
military NOTAM, whether disseminated in the civil system or not, may be
retrieved individually by both AFTN subscribers and FAA facilities via
USNS request/reply. This method would not be practical from a time and
productivity standpoint for large scale airline operations.

Initially, Military NOTAM information is provided by DOD and military
airfields so these facilities could be considered the primary sources;
however, FSS personnel are responsible for issuance of NOTAMs in the
USNS (except Alaskan NOTAMs). In that respect, potential AOCnet sources
are FSS, or USNS computer.

## [Nature of the Data]{.underline} 

Military NOTAM data is stored in a master file in the USNS computer. The
file size is unknown at this time. Military NOTAMs are compiled for any
military and joint-use airport listed in the Airport Facilities
Directory and for enroute navaids.

Military NOTAM information is updated on an ad hoc basis as new
information is passed from military facilities to FSS to USNS.

Reliability of the data is dependent on the timeliness of information
being relayed from the military to the FSS and manual input by the FSS
specialist. From that point there should be no interruption in data flow
unless communication circuits fail. In the current environment, failures
or delays have been known to occur in the transmission from WMSCR. If
the data is routed to the AOCnet, reliability should increase. For those
Military NOTAMs that are not automatically disseminated to civil
aviation operators, The AOCnet could provide an automated and more
timely source vs. a manual request by individual NOTAM.

Accuracy of the NOTAM data should not be an issue. FSS specialists
already follow specific format guidelines, and in addition, the USNOF
monitors content and accuracy.

## [What must be Done to Get this Data on AOCnet?]{.underline}

The only manual data entry requirements would be that required of the
FSS specialist and Alaskan base operators in properly formatting the
NOTAMs.

This data should be available in digital form from either FSS or the
USNS computer. FSS does not input all military NOTAMs, but all are
stored in the USNS computer which could relay to ARNIC and AOCnet via
ADTN2000 or NADIN.

Any potential method would have to be approved by FAA and DOT and
coordinated by the technical communications experts.

# International Notice to Airmen (INTL NOTAM)

**[Description of Data Item]{.underline}**

Changes in Airspace Systems or at airports are publicized as NOTAMs when
they are temporary or when time does not permit issuance of appropriate
charts or publications. INTL NOTAM information pertains to those changes
associated with enroute navigational aids, civil public-use airports,
facilities, services and procedures. This information requires wide
dissemination to airline operation's offices, local aviation companies,
and interested users.

These NOTAMs will typically include information concerning airport
operating hours and airspace restrictions, airport rescue and fire
fighting capability, runway closures, lighting aids and airport and
enroute navigational aids. INTL NOTAMs also concern OMEGA, LORAN and GPS
systems and certain special use airspace for ARTCC's which control
oceanic airspace; i.e., ARTCC and CARF altitude reservations and warning
areas.

INTL NOTAM information is critical to flight safety and efficiency. FAR
121 and FAA Handbook 8400.10 require that airline operation centers
acquire these NOTAMs and disseminate their contents to dispatchers,
pilots and other appropriate personnel. It is further required that this
information is taken into account during the preparation of the flight
plan and legal dispatch release.

**[Benefits]{.underline}**

INTL NOTAMs are currently distributed by the U.S. NOTAM Office (USNOF)
when they are received from various international NOTAM offices around
the world. These NOTAMs are also stored in the U.S. NOTAM System
computer (USNS).

Airline dispatchers, flight planners, pilots and air traffic managers
would use this information in a strategic sense when planning flights
and in a tactical sense when NOTAM information necessitates some revised
course of action while a flight is enroute.

In the planning stages, the user will plan a flight based on applicable
NOTAM information. The dispatcher or pilot could plan for contingencies
such as route restrictions due to navaid outages or takeoff and landing
weight limitations due to closed or reduced length runways. NOTAM
information might have an impact on the fuel requirements and alternate
selection, or an airport might even be closed at the planned arrival
time due to construction activity. Having timely and accurate
information, the operator could plan accordingly and adapt to the
current situation. Without advance awareness, operators would be much
more susceptible to delays or even unnecessary and costly flight
interruptions.

During the enroute phase, timely receipt of NOTAMs could greatly affect
the outcome of the flight. Certain NOTAM information may only require a
greater situational awareness but could necessitate a re-direction of
flight (i.e. diversion). The more timely this information is received,
the more quickly operators and traffic managers can react and plan the
most appropriate course of action. The result will be greater operating
efficiency, improved resource management and less passenger disruption.
Foremost is the obvious safety factor and, for this reason, FAR 121
requires that airline dispatchers monitor flight progress and advise
pilots, while enroute, of any changing conditions that may adversely
affect the safety of flight.

Since International type NOTAMs are currently available from USNOF, USNS
and from private companies such as Jeppesen, providing them via AOCnet
is not critical to airline operation control centers at this time.
However, INTL NOTAMs are distributed differently that other type NOTAMs
some of which are not widely distributed at all. It is anticipated that
the AOCnet could provide a more reliable and timelier source and could
provide a [single]{.underline} source for [all]{.underline} NOTAM types.

**[Source of Data]{.underline}**

Presently, various International NOTAM Offices around the world collect
INTL NOTAM information for their region and transmit these NOTAMs via
AFTN to the USNOF at the Air Traffic Control System Command Center. The
USNOF edits format, assigns an INTL NOTAM number and transmits them via
AFTN to aviation companies and other interested users. Most users would
not want to receive [all]{.underline} INTL NOTAMs so a distribution list
is normally pre-arranged with the USNOF to receive INTL NOTAMs only for
specific airports and ARTCC's.

The USNOF also receives NOTAM data from Canadian FSS's. If the data
meets the U.S. NOTAM criteria, the USNOF reformats the data into an INTL
NOTAM format for storage and to serve as the basis for formatting a U.S.
domestic NOTAM. The domestic format is then transmitted to WMSC for
storage and distribution.

INTL NOTAMs transmitted by the USNOF are stored in the USNS computer,
and while current, may be retrieved by both AFTN subscribers and FAA
facilities via request/reply.

Initially, INTL NOTAM information is provided by airports and/or air
traffic control facilities from the international community and
collected and sent to the U.S. by the Regional International NOTAM
Offices. They could be considered the primary source; however, the USNOF
personnel insure that these NOTAMs are distributed in a standard format.
In that respect, potential AOCnet sources are the USNOF or the USNS
computer where the NOTAMs are stored.

## 

## 

## [Nature of the Data]{.underline} 

INTL NOTAM data is stored in a master file in the USNS computer. The
file size is unknown at this time. INTL NOTAMs are compiled for a
multitude of airports and enroute navaids. These NOTAMs can be retrieved
from the USNS individually via AFTN request/reply.

Information is updated on an ad hoc basis as new information is passed
from airports/ARTCC's to International NOTAM Offices to the USNOF to the
USNS.

Reliability of the data is dependent on the timeliness of information
being relayed from an International NOTAM Office to the USNOF and manual
transmission by the USNOF specialist. From that point there should be no
interruption in data flow unless communication circuits fail. In the
current environment, delays have been known to occur in AFTN
transmissions. If the data is routed to the AOCnet, reliability should
increase. The AOCnet could also be a [single]{.underline} source for
[all]{.underline} NOTAM types.

Accuracy of the NOTAM data should not be an issue. USNOF specialists
already follow specific format guidelines, and in addition, the USNOF
monitors content and accuracy.

## 

## [What must be Done to Get this Data on AOCnet?]{.underline}

Depending on the technical communication requirements, there appears to
be A couple of options to interface the AOCnet. The only manual data
entry requirements would be that required of the USNOF specialist in
properly formatting the NOTAMs.

This data should be available in digital form from either the USNOF or
the USNS computer and relayed to ARNIC and AOCnet via ADTN2000 or NADIN.

Any potential method will require FAA concurrence and coordination by
the technical communications experts.

**[Other Issues :]{.underline}**

When Intl. NOTAMs are available on AOCnet the AOCnet will become the
most concise, timely, and accessible source of Intl. NOTAMS. Providing
access to AOCnet by foreign carriers may become an important issue.

# Airline Arrival Prioritization

*AUTHORS NOTE: This write-up is really not about a new data item, but
about the potential for new operational concepts that will make new data
exchanges necessary. The new operational concepts need to be further
explored before details regarding the data exchange can be more fully
documented. At his point it is probably premature to discuss a data
exchange without regard to the underlying operational concepts.*

**[Description of Item]{.underline}**

As flights transition from enroute airspace into congested terminal
airspace, the ATM system often must place restrictions on arrivals to
ensure that the safe capacity of the terminal area is not exceeded.
These restrictions include metering, miles-in-trail, vectoring, long
final approaches (aka tromboning), fix-load balancing, etc. This
activity is known as arrival flow management. To the air traffic
management system, one flight is pretty much the same as any other
flight. However, to the operators there are huge differences among
flights depending upon their operational business objectives. In the
current system, restrictions are for the most part enacted without
regard for the relative priority individual airspace users are placing
upon their flights.

This situation is of particular concern at airline hub airports. At
these airports where a single airline together with its code-sharing
express partners operates a hub, the traffic causing the arrival
congestion problem is often dominated by the hubbing carrier. However
ATC restrictions are put in place without regard to individual airline
priorities among incoming flights such as crew criticality, passenger
connectivity, critical turn times, gate availability, on-time
performance, fuel status, runway preference, etc.

As ATM becomes more collaborative, allowing airspace users greater
flexibility and control over their own operations, this situation is
likely to change. There are two main classes of mechanisms by which this
practice is likely to be altered.

1.  **Airspace Users send Flight Priorities to the ATM Service
    Provider:** Airspace users could express their relative priorities
    among their flights to the ATM service providers. This will involve
    operational concept changes on the part of both ATM service
    providers and among airspace users. Service providers will need new
    ATM techniques to place restrictions in a manner that is sensitive
    to priorities expressed by the carriers.

2.  **Airspace Users have Responsibility for Arrival Flow Management:**
    Airspace users will operate within ATM service provider constraints
    and make the necessary operational trade-offs among their own
    flights. Users would thus be responsible for arrival flow management
    and ensuring that the arrival traffic is sufficient smoothed.

Each of these classes of mechanism raise several issues and they may not
work in every situation or at every airport. Currently, UPS, the ATCSCC,
and MITRE-CAASD are cooperating in an experiment to determine if the
later of the two mechanisms would be feasible at an airport where a
single carrier dominants. This experiment utilizes a decision support
system known as SMART (Self-Managed Arrival Re-sequencing Tool).
Findings from this experiment will indicate whether extension to other
circumstances would be feasible. However, it is unclear if the second
class of mechanisms will work at arrival airports where there is no
clear dominance by one or two carriers.

**[Benefits]{.underline}**

> [What is the current availability of this data]{.underline}
>
> • This data is currently not available in digital format
>
> • The data is available within each airline AOC
>
> [How would the data be improved if it were on AOCnet]{.underline}
>
> • The user's preferences would be acted upon
>
> [Who would use this data]{.underline}

• The TRACON or other approach control facility

[To what uses would this data be put]{.underline}

> *•* The carrier's arrivals would be ordered based upon carrier
> preference instead of first come, first served allocation of arrivals
> among company flights

[What would the benefits be in terms of efficiency and
safety]{.underline}

> • Carrier preferred ordering would reduce misconnected passengers,
> arrival delays awaiting a gate to open, and downline delay propagation

[Who would use this data]{.underline}

> *•* ATC TRACONs and other FAA facilities

**[Source of the Data]{.underline}**

Air carrier AOCs.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

1.  Determine how ATC Facilities can use this data to accomplish its
    goal

2.  Create the proper ATC systems and procedures to facilitate the datas
    use

3.  Determine the proper message formats to transfer the information

4.  Create air carrier systems to capture and disseminate this
    information

5.  Connect the air carrier and ATC systems to the AOCnet.

**[Other Issues]{.underline}**

The issues listed below are questions that need to be answered as the
group explores various alternative operational concepts that will allow
system users to express their arrival priorities. Many of these issues
are similar to the issue that the group dealt with in exploring the
operational concepts associated with GDP enhancements.

1.  Will the operational concept allow priorities between flights from
    different users to be compared? If a user declares a flight as being
    high priority, will it get preference over other flights from the
    same airline or over flights from other carriers as well?

2.  If a user is to declare priorities to the FAA how can it be assured
    that users don't declare all flights as priority? E.g., Each airline
    is able to declare 10% of their scheduled operations as being
    priority flights. This declaration can vary daily. Active flights
    can be declared a priority flight. However, once a flight is
    declared a priority flight, its status can not change. When
    considering actions, the service provider will take into account the
    relative priority of all flights involved. This may include granting
    preference to a high priority flight from one airline over a flight
    from another competing carrier.

3.  Will service providers be willing to consider a flight priority in
    making arrival flow management decisions?

4.  Will airspace user priorities include sequencing and/or runway
    selection?

5.  What warranties are implied by service providers if they are unable
    to grant preference to priority flights and/or are unable to grant
    the preferred runway?

6.  Will the service provider be able implement arrival flow management
    techniques used today if user priorities are to be considered? E.g.,
    How would miles-in-trail work if a user could declare some flights
    as having higher priority than others?

7.  Can airspace users take the responsibility for arrival flow
    management when they dominate the operations at an airport (e.g.,
    SMART)?

8.  Can two cooperating airspace users take the responsibility for
    arrival flow management when they dominate the operations at an
    airport (e.g., UAL & AAL at ORD)?

9.  How can users take responsibility for arrival flow management at
    airports/terminal areas where there is no clear dominate players
    (e.g., LGA, LAX, DCA)?

10. How will the operational concepts ensure that small operators and/or
    users who don't participate in CDM are not been penalized?

11. How will the users determine priorities? How can we be assured that
    priorities among various airlines can be compared? Will priority
    definitions be uniform?

12. How will users express priorities? E.g., low vs. High; 1-10;
    specific arrival sequence;

# ATCSCC Air Traffic Management Advisory Messages 

# Collaborative Advisory 

# Weather Re-Route messages

**[Description of Item]{.underline}**

Textual data being sent to the airlines by ATCSCC concerning some type
of action that will be taken by ATC to manage traffic in the terminal
and en-route environment. These items would include the following.

A.  Station / Area and Date/Time issued in UTC/GMT

B. Type of ATCSCC initiative

Ground Delay program for weather, facilities, or other reason.

Ground Delay program expected average delays.

Equipment included in the program.

Ground Stop

Blanket Program

Blanket programs length of increase or reduction in time.

Extension of a Ground Delay Program

Extension of a Ground Stop

Missile Launches

Airport conditions

Severe weather reroutes

ATC Facility outage

C. Centers that are effected by the action.

D. Why the action is being taken.

Airport conditions

Winds

Visibility

Ceilings

Construction

Aircraft incident on the field

Facility Outage

Enroute Conditions

Missile Launch

SUA status

Reroutes due to TRW

Reroutes due to Turbulence

Facility outage

Excess Demand on a sector, center, or fix

E. The number of the program for that station (1,2\....99) for the ZULU
day the program begins

This number is useful for the computer to detect missing program
messages and

possibly automatically retrieve a missing message

F. DDHHMM= Month / Day / Hour / Minute the program will be in effect

G. DDHHMM= Month / Day / Hour / Minute the program will terminate

H. AVG = Average delay expected during the program

I. AAR = Airport Arrival Rate upon which the program is based.

J. Exemptions to the program( Time, Specific flts(by carrier), Specific
airports).

K. Current airborne holding estimates as well as expected airborne
holding planned into the

delay program if any.

L. Free Text (limited to so many characters) ARINC only allows 64
characters a line.

**[Benefits]{.underline}**

This information would filtered by the airline and rebroadcast to the
Dispatcher, Customer Service, Reservations, Crews, Management, and
anyone else needing information concerning the daily operation of the
airline. Air Traffic Facilities that need information concerning ATCSCC
initiatives.

This information can be stored and filtered allowing the airlines and
ATC to get the right information to the right people.

Presently this information is being inefficiently communicated.
Continuous changes in the NAS cause for a large volume of these messages
to be sent daily. Trying to keep track of this information is difficult
for the airlines and ATC. Many flights are held on the ground by the
airlines and ATC after restrictions have been lifted because this
information is not communicated effectively. Currently the system
depends on users and ATC facilities manually tracking and updating the
state of the NAS using freeform text messages and verbal communications.

The benefits to this information would be to improve on efficiency by
reducing unnecessary delays. With standard message formats the airlines
and ATC could store and filter this information to support many existing
systems. An airline could automatically generate a message to the
cockpit advising the pilot that ATCSCC has lifted a ground stop. ATC
could build and maintain a display that would automatically display all
current Traffic Management. Both ATC and the users would be able to
insure the appropriate people had the correct information at the right
time.

**[Source of the Data]{.underline}**

Presently this information is being input by the ATCSCC in a free flow
text format message which is then sent to the users via ARINC/SITA/AFTN.
There is already an ATCSCC project to create a formatted screen to input
this data.

**[Nature of the Data]{.underline}**

These messages are text messages and are usually less than 1024 bytes.
They are only created and transmitted when an event occurs. This
information is based on the decisions that are being made by the ATCSCC
specialist who then creates the message.

**[What Must be Done to Get this Data on AOCNet?]{.underline}**

[To what current or planned system must AOCNet be
interfaced?]{.underline}

The ATCSCC computer system for creating and transmitting these messages
must be connected to the ETMS "E-mail" system.

[What manual data entry would be needed?]{.underline}

The ATCSCC specialists already enter this data into a free text message.
Using defined format message shells will reduce the time it takes the
specialist to enter the information.

[What other actions would be necessary to get this data on
AOCNet?]{.underline}

Message formats must be defined with easily parseable fields so that
users and ATC facilities can create software to read, store, and pass on
this information.

[When could this data be available digitally so it could be placed on
AOCNet?]{.underline}

This data will be available digitally as soon as the connection is made
and the message formats are created.

**[Other Issues.]{.underline}**

A database of current advisories that are in effect could be created at
the ATCSCC which would allow internet access by all users and ATC
Facilities. Users could create software to access this database
directly. This would allow non-participants in CDM better access to ATC
advisories as well as offering CDM participants a current database to
insure all advisories were received.

# Airborne Icing Aviation Weather Data Element

## Integrated Icing Algorithm

**[Description of Data Element and Problem to be
Addressed]{.underline}**

There is a need for an integrated icing algorithm that would result in
automated, airborne icing hazards products, detecting and forecasting
the icing potential of the national airspace, and shown in a
2-dimensional display of grid coordinates that map the plan view and
vertical cross section of any portion of any route of flight and
altitude over the US. The algorithm would be run every hour for icing
detection, and the icing forecast would run once every 3 hours and
displayed every hour for the 0-6 hour period. (It would be very computer
intensive to produce diagnostic and predictive output and ship it to the
AOC-Net more frequently, and shorter term differences in these products
probably would add little value.)

Airborne icing is not a singular phenomenon, but results from variations
in a number of meteorological and physical state-of-the-atmosphere
parameters. No single kind of sensor observation or physical state
appears to describe the occurrence of airborne icing. In the atmosphere,
three critical variables govern the occurrence of an airborne icing
hazard - liquid water content, temperature, and droplet size. The
integrated icing algorithm is concerned with the diagnosis of all three
of these variables.

The problems with airborne icing are both operational and safety
related. Legal constraints govern the dispatch of aircraft into known
and forecast icing conditions and make the quality of icing diagnostics
and forecasts pivotal to safe and efficient dispatch and traffic
management. As a result of the complexity of icing occurrences in the
atmosphere, however, NCAR studies have shown that forecasters tend to
significantly over-forecast the occurrence of potential airborne icing
conditions. Because the pilot is also legally charged with avoiding
icing conditions, over-forecasting certain kinds of icing can create
potential operational problems dispatching aircraft. NCAR studies also
show that current NWS icing forecasts continue to miss about 25 percent
of the pilot icing reports - despite the weather service significantly
over forecasting the area of potential airborne icing conditions. An
integrated icing algorithm and display products that better represents
physical reality, rather than legal and administrative considerations,
would be a huge step forward.

**[Benefits]{.underline}**

An integrated icing algorithm would provide a graphical depiction of the
horizontal and vertical locations of current and forecast in-flight
icing. Such a graphical depiction would provide a quick and easy way to
identify where icing exists, rather than reading through text forecasts
of icing which contain a series of station locations to outline the
icing regions (which the user has to either picture in their head or
manually draw). Movement of icing areas also would be easier to
interpret with the graphical product. The identification of potential
locations of supercooled-large-drop icing regions would also be
possible, since this phenomenon can be particularly hazardous to
aircraft. In addition, current pilot reports of icing severity and type
would be plotted on top of icing diagnoses, permitting the user to
identify areas of real-time verification of the algorithm performance.
Hourly updates to current icing locations and 3-hourly updates to
forecasts out to 12 hours would be a marked improvement over current
text forecasts which are released every 6 hours.

A Volpe National Transportation Systems Center evaluation for the FAA
weather program, based upon NTSB data, suggested a baseline of about 41
aviation icing-related accidents annually. About half of these accidents
were due to airborne icing, as opposed to ice accreting while the
aircraft is on the ground. Of the approximately 41 annual, aviation
icing-related accidents, about 6 could be attributable to Part 121
carriers. An analysis performed for the NASA-ASTT program estimated that
about 11 percent of the annual, icing-related accidents might be
avoidable. Although such data suggest that only about one quarter of a
commercial, airborne icing accident might be avoidable every year, the
cost of such an accidents are very substantial. For example, the
American Eagle ATR-72 accident in 1994 is estimated to have cost society
around \$1 billion, in addition to the 68 lives lost. If airline hull
loss, claims settlements, and loss of \"good will\" in adverse publicity
represented only 20 percent of this social cost, the annual benefit of
such commercial aircraft airborne icing accident reductions to airlines
and insurance underwriters would be around \$50 million.

The avoidance of airborne icing accidents depends on qualitatively
better icing diagnostics and forecasts. Such forecasts also could have
huge operational benefits for flight dispatch in the northern half of
the country during the winter months, when only suitably equipped
aircraft can be dispatched into forecast icing conditions. They could
increase aircraft utility and dispatch flexibility through better route
selection.

**[Source of the Data]{.underline}**

The algorithm will integrate information from a wide variety of
meteorological data sources. I will describe this in terms of who we get
it from, since it seems that the original version of this will be
running locally. The data sources are as follows:

> 1\. Satellite data, which is brought into RAP via our own dish. The
> data are generated by NOAA\'s GOES-8 satellite and are processed
> locally on a series of unix workstations before integration into the
> icing algorithm. The data are available every 15 minutes.
>
> 2\. Surface observations which come in as part of the \"family of
> services\" data from the NWS. NCAR gets it as part of our \"weather\"
> package via internet connections. The data are updated essentially
> once
>
> per hour.
>
> 3\. RUC model data. Downloaded via automatic, real-time FTP from the
> National Center for Environmental Prediction. Model runs are available
> every 3 hours.
>
> 4\. National radar mosaics from Kavouras. Radar mosaics are updated
> every 5 minutes.

**[Nature of the Data]{.underline}**

1.  Satellite data files are quite large. Every 15 minutes about 12Mb of
    raw data must be downloaded in order to generate the icing field.
    These files balloon to 20Mb during the processing and are stored in
    Tera-Scan binary format files, similar to NetCDF files. The data
    have about 4km grid spacing, and are quite reliably retrieved.

2.  Surface observation files are much smaller. Every hour the aviation
    weather development laboratory at NCAR creates 2 files of about 0.1
    Mb. The data access is fairly reliably and are essentially dependent
    upon the reporting network remaining in operation. Not surprisingly,
    most network outages to NCAR occur at night and on weekends.

3.  Raw rapid update cycle (RUC) model data are about 1.1 Mb per cycle,
    but expand to 3.3 Mb by the time that they are converted to a more
    useful format. The data stream is fairly reliable and is dependent
    upon outages at the National Center for Environmental Prediction,
    which happens on occasion. When such an outage occurs, no one is
    getting RUC data.

4.  National radar mosaic raw files from NEXRAD (WSR-88D) are 50-100 kB
    each. They are in a Kavouras-specific format (.mcg) and are
    converted to Dobson format at NCAR via our own software. These data
    come into thelaboratory quite reliably, but are subject to our
    occasional network problems.

**[What Needs to be Done to get This Data on the AOCNet]{.underline}**

The most reliable method to get this data on the AOCNet is for NCAR to
conduct the data processing and create a series of .gif images (or some
other similar web-compatible format), and then either send these images
to an AOCNet server via automatic FTP, or have AOCNet users link to a
password-protected web page that NCAR would maintain at RAP for a test
and demonstration period. A set of plan view and vertical cross-section
coordinates for pre-selected flight levels and regions could be
provided.

Alternatively, NCAR could ship the algorithm output grids to the AOCNet
server and a service provider could write a Java applet allowing the
graphics to be created on the server for AOCNet airline operations
centers and the FAA traffic management unit users (allowing the service
provider more flexibility to create critical area cross sections, etc,
but also requiring the provider to build the architecture and software
necessary to handle the grids and plots).

For the purposes of an operational testing and evaluation of these
product concepts, we think that it might be impractical to give
NCAR-EXPERIMENTAL software to an AOCNet service provider. There is a
great deal of \"hidden\" architecture at NCAR to ingest all of the
required data sets, run the software, and create the test imagery which
makes these products run. A costly and very labor-intensive effort by a
service provider might be required to identify and duplicate this
architecture elsewhere for an operational test and evaluation.

[^1]: Formerly titled Nav aids outages, however, actually applies to all
    NAS equipment (ARTCCs, radars, voice communications, etc.) in NAS
    Status Information Subgroup memo dated 12 April 1997

[^2]: Facility is the FAA terminology for Nav aids and other equipment.
    Services are functions performed by one or more facilities operating
    as a system.

[^3]: This may be possible by using the appropriate IP addresses through
    a single physical connection between AOCnet and ADTN 2000 but
    requires further investigation. It is highly likely that the Tandems
    at the ARTCCs are (or soon will be) on ADTN 2000; it is not known
    what proportion of GNAS PCs will be so attached.