NAS Status Information Subgroup Memo

**Subject**: Airborne Icing Aviation Weather Data Element

**To**: NAS Status Information Subgroup

**From**: Art Shantz

**Date**: September 12, 1997

**Integrated Icing Algorithm**

*Description of Data Element and Problem to be Addressed:*

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 occurences 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*

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*

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*

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 the
laboratory quite reliably, but are subject to our occasional network

problems.

*What Needs to be Done to get This Data on the AOCNet*

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.