In today's Air Route Traffic Control Center (ARTCC) environment,
some very important low-altitude radar data is suppressed. This
radar data is not suppressed by the controllers themselves. Rather,
it is a result of a compromise in the radar data processing software,
and the manner in which the software is adapted by automation
personnel. This suppressed radar data has led to air traffic controllers
being unable to provide accurate and timely advisories about aircraft
which pose a collision threat. An existing software technique
to correct a portion of this problem has existed for years, but
it is optional and is not adapted system-wide. There must be a
concerted effort to address this inadvertent suppression of low-altitude
radar data, as well as an examination into the human factors aspect
of why it is allowed to continue.
On August 24, 1984, Wings West Airlines Flight 628 departed the
San Luis Obispo, CA airport en route to San Francisco. Twenty
two seconds after the controller advised Flight 628 that radar
contact was established, the Wings West aircraft collided head-on
with a single-engine Rockwell Commander aircraft at an altitude
of approximately 3,400 ft. No safety advisory was issued by the
controller to the crew of Flight 628. When Flight 628 was advised
of radar contact, the Rockwell Commander, flying under Visual
Flight Rules (VFR), was a mere 2 1/2 nautical miles (nm) away.
Seventeen people lost their lives. The Los Angeles Center controllers
testified that the radar return of the VFR aircraft was not displayed.
The National Transportation Safety Board (1985) concluded that
it had to have been displayed.
In early 1985, while I was providing radar service to a commuter
flight, a similar tragedy nearly took place. I was paying close
attention to the radar scope. During the commuter's climb to cruising
altitude, I was surprised when the pilot radioed, "Center,
did you SEE THAT AIRCRAFT?!" Just after this unnerving query,
a VFR code 1-2-0-0 beacon target appeared directly behind the
commuter aircraft's target. I immediately verified that it was
indeed the first time this VFR aircraft was displayed within the
previous minute.
In 1988, I wrote a paper addressing this compromise of suppressed
targets. It was submitted as Unsatisfactory Condition Report (UCR)
#330069 to Cleveland ARTCC (Lusch, 1989). The UCR was closed in
April, 1989. No action was taken.
The primary purpose of the air traffic control system is to prevent
a collision between aircraft. The controller's highest priority
duty is described in the ATC procedures manual 7110.65F, para.
2-2. That duty is to separate Instrument Flight Rules (IFR) aircraft
and to issue a safety alert to the pilot if the controller is
aware of any aircraft which may be on a collision course. Monan
(1989) writes of several near-midair collisions where controllers
claimed that aircraft were not displayed on their scopes.
An aircraft, detected by radar, may be suppressed from the controller's
display by the software process of selective rejection. The ARTCC
controller has absolutely no control over this radar data filtering
process.
In the following discussions, all references to radar refer strictly
to radar data processed by computers at Air Route Traffic Control
Centers. Also, all examples are based on Cleveland Center. It
should be emphasized that Cleveland Center is likely doing a better
job than most other ARTCCs in the processing of low-altitude radar
data. Due to the nature of this problem, however, the inadvertent
suppression of low-altitude radar data still occurs.
Mosaicing is the method employed to deal with the enormous amount
of radar data from overlapping radar sites. Mosaicing is a method
of sorting the data from several radars of an ARTCC into hundreds
of small boxes, known as radar sort boxes (RSBs). The dimensions
of a radar sort box is 16 nm by 16 nm. Mosaicing makes it possible
for the computer to utilize data from one and only one radar site
at a time, at any given point in space. Within a sort box, data
from overlapping radar sites is prioritized into preferred data,
and supplemental data. Data from a preferred radar site will be
utilized first, and if unavailable, the data from the supplemental
radar site may be utilized. Where a radar site is neither assigned
as preferred nor as supplemental within a sort box, its radar
data is completely rejected by the computer within that 256 square
nautical mile (sq nm) area.
Due to past computer software and hardware processing limitations,
the enormous amount of radar data from multiple radar sites simply
had to be reduced. Otherwise the computers were overloaded. Today's
software and hardware processing limitations still require mosaicing
to reduce computer processor demands, as the majority of radar
data received at an ARTCC is still abandoned (Meilander, 1989).
Unfortunately, mosaicing contributes to some important low-altitude
radar data not being utilized. This results in some aircraft not
being displayed on the controller's scope, even though these low-altitude
aircraft are, in fact, adequately detected by radar.
Compromise #1. ATC radar is not designed to detect aircraft
directly above the radar antenna. This area is known as the cone-of-silence.
Aircraft flying in a radar's cone-of-silence may, however, be
detected by another, or several other radar sites a hundred or
so miles away due to their overlapping coverage. Figure 1 depicts
a 5 nm diameter cone-of-silence area above the Dansville radar.
Aircraft at all altitudes within this cone-of-silence area are
not detected by the Dansville radar. If these aircraft are high
enough, however, they will be detected by the Clearfield, PA,
and Utica, NY, radars, which are between 100 to 115 nm away. To
solve a cone-of-silence problem, it is common practice to assign
the coverage, within a sort box which overlies the radar, to a
distant radar site. As shown in Figure 1, the preferred coverage
within RSB#986 is assigned to Clearfield radar. Such software
adaptation easily eliminates the problem of a cone-of-silence.
Unfortunately, it also eliminates many low-altitude radar targets
near the radar site from being processed for display.
Danville radar data is not utilized within RSB#986. It is neither
assigned as preferred nor supplemental. Low-altitude aircraft,
below 5,000 to 6,000 ft in this vicinity, will not be detected
by either the Clearfield or Utica radars. This is due to the fact
that the radar signals are strictly line-of-sight, and are therefore
blocked by the earth due to its curvature.
As shown in Figure 1, a northbound aircraft is about to collide
with a southbound aircraft. The northbound aircraft is within
RSB#936 and is being provided radar service by Cleveland Center.
Due to its low altitude, it is detected by only the Dansville
radar. The southbound aircraft is within RSB#986 and has a properly
functioning transponder set to the VFR code of 1-2-0-0. Since
this low-altitude aircraft is not within Dansville radar's cone-of-silence
it is detected by Dansville, and its position is sent to the ARTCC
computer, along with the position of the northbound aircraft.
Like the northbound aircraft, due to its low altitude, this southbound
aircraft is not detected by either the Clearfield or Utica radars,
which are assigned as preferred and supplemental within RSB#986.
Unfortunately, the controller will be unable to issue a warning
to the pilot of the northbound aircraft prior to the collision
with the southbound aircraft at position A. This is because the
Danville radar data on this southbound aircraft is discarded by
the program.
Figure 1. Two aircraft detected by only the Dansville radar. The southbound aircraft is not displayed since Dansville radar data is suppressed within RSB#986. (Distances are in nautical miles [nm].)
As one can see, the steps taken to correct the problem of a loss
of data in a radar's cone-of-silence leads to the loss of important
low-altitude radar data. Note the difference in size between the
depicted 20 sq nm cone-of-silence area, as compared to the much
greater 256 sq nm area within the sort box. Unfortunately, the
manner in which the radar data is processed results in 236 sq
nm of low-altitude radar data not being displayed.
Compromise #1 addressed. These inherent shortcomings do
not need to be accepted. One method of addressing this problem
is to utilize data from more than one radar at the same time.
Instead of assigning one and only one radar as the preferred radar,
a sort box may be adapted with one radar as preferred and another
as alternate preferred. When two radars are designated in this
manner, a sort box is said to have double-preferred coverage.
This solution results in a less than pleasing display, as there
will be two targets per aircraft when the aircraft are detected
by both radars. Software documentation discourages the adaptation
of sort boxes as double-preferred.
There is a similar, but much better way to deal with this problem.
It is to utilize the optional software routine called the ZC150
patch. This patch stratifies a sort box. High-altitude aircraft
are still depicted by a distant radar site, which solves the cone-of-silence
problem, but low-altitude aircraft which are detected by the radar
site within the sort box are not suppressed. A sort box with this
patch adapted utilizes single-preferred coverage at or above the
stratified altitude, whereas double-preferred coverage exists
below the stratified altitude. The ZC150 patch has been in use
at Cleveland Center since May 23, 1990. It has been adapted for
all radar sort boxes overlying radar sites within Cleveland Center,
except for RSB#986.
Compromise #2. Another compromise inherent with mosaicing
occurs when the adapted preferred coverage changes from one radar
to another. This often takes place midway between two radar sites.
If the coverage from both radars is equal, suppression of targets
may be minimal, but it can still occur. Sometimes the changeover
point is much closer to one radar than the other. When sort boxes
are adapted in this manner the results can be somewhat mystifying,
in that one aircraft will be displayed, but another, within the
same sort box, will not be displayed! See Figure 2.
Figure 2. Two aircraft detected by only the Pittsburgh radar. The southeast-bound aircraft is tracked and displayed within RSB#581. The northwest-bound aircraft is untracked, and therefore is not displayed within RSB#581. (Distances are in nautical miles [nm].)
One may find it unsettling that two aircraft, both within the
same radar sort box, both at the same altitude, both with transponders
faithfully responding to radar interrogations from the same radar,
and both about to collide, can result in one aircraft being displayed,
and the other totally invisible to the controller. The difference
that causes this phenomenon is that one aircraft is tracked, and
the other untracked. An aircraft that is tracked by the software
is one that is being provided radar service by an ARTCC. Besides
having a target symbol, it will include a full datablock, which
displays information such as identification, assigned altitude,
etc. An untracked target is typically a VFR aircraft, whose pilot
is operating under the see-and-be-seen rules, and has the aircraft's
transponder set to the VFR code 1-2-0-0. A low-altitude VFR aircraft
on the code 1-2-0-0 will be represented by the target symbol V,
and the only other data that will be associated with it will be
its altitude data, assuming the aircraft is equipped with altitude
reporting. There is a significant difference between the display
of a tracked and an untracked aircraft. This is that a tracked
aircraft, when no longer detected by the preferred radar yet still
detected by the supplemental radar, will display a target symbol
and full datablock. However, an untracked aircraft, when not detected
by the preferred radar yet still detected by the supplemental
radar, will not display a target symbol nor any other data for
that matter. It is invisible to the controller.
Figure 2 shows the path of a typical commuter flight from Pittsburgh
International Airport to the Latrobe, PA Airport. Cleveland Center
provides radar service to an aircraft on this route of flight
from approximately 15 nm east of Pittsburgh until the aircraft
is instructed to contact the Latrobe air traffic control tower.
As the commuter aircraft enters RSB#581 the preferred radar coverage
changes from Pittsburgh to Clearfield. As this aircraft descends
through 2,900 ft, the Clearfield radar will no longer detect it.
The computer software will then automatically utilize the supplemental
radar data from the much nearer Pittsburgh radar to continue to
display this tracked aircraft within RSB#581. Simultaneously,
a northwest-bound VFR aircraft which is 62 nm away from the Clearfield
radar yet only 29 nm away from Pittsburgh radar, is on a collision
course with the commuter. This VFR aircraft will soon be within
30 nm of Pittsburgh International Airport, and as required by
Federal Aviation Regulation 91.125, it is equipped with an operable
transponder with automatic altitude reporting. This VFR aircraft's
altitude is steady at 2,800 ft. As this untracked VFR aircraft
enters RSB#581 it disappears from the controller's display. This
is due to the fact that it is detected by only the Pittsburgh
radar, and it is not tracked by the computer software. While this
VFR aircraft was in RSB#531, it was displayed because Pittsburgh
radar is designated as preferred within that sort box. As the
aircraft enters RSB#581, where Pittsburgh radar is no longer assigned
as preferred, yet it is the only radar that detects this VFR aircraft,
the target vanishes from the controller's display. The pilot of
the commuter aircraft will not be warned about this VFR aircraft.
The Pittsburgh radar detects both aircraft and sends this data
to the ARTCC computer, but only the tracked aircraft receiving
radar service by Cleveland Center is displayed. The VFR aircraft
is detected by radar but not displayed!
Did the controllers at Los Angeles Center simply not see the VFR
aircraft as it was about to collide with the Wings West commuter
aircraft? When the controller established radar contact on the
commuter aircraft, the VFR aircraft would have been a mere 1/2
inch (1.27 cm) away on the screen. Could the VFR aircraft had
been inadvertently suppressed from their display due to selective
rejection? Upon my review of the radar data from that accident,
I could not help but notice that both aircraft were in separate
radar sort boxes until the collision took place. Regardless of
whether the controller just didn't see the VFR aircraft, or whether
selective rejection made that VFR aircraft invisible to the controller,
it is important to realize that in today's ARTCC environment,
the ongoing inadvertent suppression of low-altitude radar data
could result in a similar tragic scenario being replayed.
Shortly after I became a full performance level radar controller,
that near-midair collision occurred in which I was unable to issue
a safety advisory because a VFR aircraft was not displayed. I
then began to question our radar data processing methods. Nearly
everywhere I turned, I was assured that the new computer hardware
and software would most certainly enhance the display of traffic,
and that this new equipment was "coming soon." That
was 1985. Six year later, and over three years after the replacement
of the ARTCC mainframe computers with the upgraded HOST* computer,
the suppression of low-altitude radar data still exist. New hardware
and software are "coming soon," but can we be assured
that the display of low-altitude aircraft will be enhanced? When
a partial remedy has existed for years, such as the ZC150 patch,
it is difficult to understand why it has not been fully implemented.
It is truly a shame to have excellent radar coverage, yet not
have done our utmost to be certain that the radar data of low-altitude
aircraft are displayed for the controller. This problem begs for
immediate attention. Should a midair collision occur tomorrow,
and it was found that no safety advisory was issued because of
target suppression due to selective rejection, this problem would
certainly be addressed and corrected nearly immediately. This
subject should be addressed as if tomorrow's midair has already
occurred.
To correct the problems as related in Compromise #1, the first
step should be to make the ZC150 patch mandatory instead of optional.
Such immediate action costs little, as the software and hardware
already exists. The only thing necessary is a directive that it
be accomplished. The second step should be to correct the suppression
of low-altitude aircraft targets as described in Compromise #2.
There is no software patch currently designed to address this
specific problem. Resources should be directed to remedy this
situation. Possibly the most expeditious way to handle this task
is to stratify all sort boxes and utilize double-preferred coverage
throughout the low-altitude environment. The methods in the ZC150
patch could likely be broadened to include all sort boxes to achieve
this goal. The third step, which is a long range goal, should
be to seriously consider the advantages of simultaneously utilizing
all data from all radars, in an effort to track all aircraft.
Potter and Meilander (1989) discuss the advantages of utilizing
an array processor supercomputer to achieve the performance requirements
necessary to process the great amount of radar data that goes
unused today.
It would also be wise to initiate a human factors study to determine
why, when a problem of such importance is brought to the attention
of the Federal Aviation Administration (Lusch, 1989), that no
action is taken.
Lusch, T. G.( 1989)
Selective Rejection of Low Altitude Radar Data at Air Route Traffic
Control Centers: An Unsatisfactory Compromise [Machine-readable
data file SELREJ.INF, Library 3]. Wellington, OH: Thomas G. Lusch
(Producer). Columbus, OH: CompuServe: AVSIG (Distributor).
Meilander,
W. C. (1989) Ground Based Collision AvoidanceRevisited.
Fall Conference Proceedings of the 34th Air Traffic Control Association
Annual Meeting, 257-264. [Caution: Long download time as each page of this 8-page
paper is stored as a jpeg file.]
Monan, W. P. (1989) Human Factors in Aviation: Terminal Control
Area Boundary Conflicts (NASA Contractor Report no. 177522; Contract
NAS2-11934). Mountain View, CA: NASA Ames Research Center.
National Transportation Safety Board (1985) Aircraft Accident
Report--Midair Collision of Wings West Airlines Beech C-99 (N6399U)
and Aesthetec Inc., Rockwell Commander 112TC (N112SM), near San
Luis Obispo, California, August 24, 1984 (Report No. NTSB/AAR-85/07).
Washington, DC: National Transportation Safety Board. (NTIS No.
PB85-910407)
Potter, J. L., & Meilander, W. C. (1989, December). Array
Processor Supercomputers. Proceedings of the IEEE, pp. 1896-1914.
*The HOST computer systems, installed in all 20 ARTCCs, replaced the 20 year old IBM 9020 computers. Cleveland's HOST was inaugurated on Jan. 29, 1988.
"Real Targets - Unreal Displays: The inadvertent suppression of critical radar data" is posted on the internet with permission from Dr. Richard S. Jensen, Editor of the Proceedings of the Sixth International Symposium on Aviation Psychology, The Aviation Psychology Laboratory, Ohio State University, Columbus, Oh 43210. All rights reserved.
Tom Lusch tomlusch@columbus.rr.com
© 2000 by Lusch's Midair Collision Investigations. All rights reserved.
