In the National Airspace System (NAS), some important Air Route Surveillance Radar (ARSR) data is not sent to the Air Route Traffic Control Centers (ARTCC's) for processing. In other instances, the radar data which is sent is not processed for display since it is selectively rejected. The Radar Data Processing (RDP) system is a complex hardware and software package which compels the selective rejection of available and important low altitude radar data. There are existing software techniques to deal with some of the compromises in today's system, but these techniques cause clutter on the display, or deal with only a small portion of the problem. A new method of processing low altitude radar data is proposed, to ensure that virtually all of the low altitude aircraft are presented to the air traffic controller.
The primary purpose of the air traffic control system is to
prevent a collision between aircraft. The air traffic controller's
first priority (1)
is to separate IFR (2)
aircraft and to issue a safety alert to the pilot if the
controller is aware of another aircraft (IFR or VFR)
(3) which may be on a collision course.
The tool a controller utilizes in determining conflicts between
aircraft is the radar display. If a pilot receives a timely traffic
alert, the pilot may spot the threatening aircraft and/or maneuver
his aircraft to avoid a collision. It has been demonstrated when
two aircraft are on a collision course, the probability of visual
acquisition can be improved by a factor of eight if the pilot(s)
receive accurate and timely traffic alerts.
(4) The display of aircraft in possible
conflict is of the utmost importance to the controller, as well
as to the flying public.
It is generally believed radar data from the ARSRs
(5) is used in an optimal fashion
to provide a representation of air traffic to the en route air
traffic controller. There is evidence to the contrary. An evaluation
of a typical ARTCC shows that some important radar data is not
sent to the facility. Also, the current method of processing the
radar data which is sent to the facility shows that an aircraft
detected by an ARSR may not be displayed
on the controllers Plan View Display (PVD)
(6). This report outlines significant
aspects of the problem of selective rejection that must be solved
before there can be confidence the picture presented on the controller's
display is the low altitude radar data actually available. Immediate
and near term solutions are suggested to deal with the problem
of selective rejection.
In June 1988, the FAA took steps to enhance the radar data transmitted from airborne aircraft by issuing a new ruling which will require that even more aircraft shall be equipped with transponders (7) and altitude reporting equipment (8). This radar-enhancing beacon equipment will be required in a much greater amount of airspace than was previously required. These new laws will go into effect by the end of 1989. While many aircraft already comply with such equipment requirements, many more pilots will be spending a considerable amount of money in equipping their airplanes with this required transponder equipment. Unfortunately, as will be demonstrated in the following examples, an airplane equipped with such radar-enhancing beacon equipment may not be displayed on the ARTCC controller's screen, even though that aircraft is within ARSR coverage.
If radar service is provided to one of two aircraft on a collision course, and the other aircraft is detected by radar, but not displayed on the PVD, the controller obviously has no way of issuing a safety advisory or of suggesting an avoidance maneuver. It may be surprising such a scenario is possible. Most people would think it preposterous that such critical data would not be displayed on the radarscope!
It is important to understand, in the discussion that follows, the selective rejection of aircraft targets from the ARTCC display has no bearing whatsoever on how the controller manages the PVD. All examples deal with the ARTCC computer's processing of radar data in the en route environment, over which the controller has no command. It is assumed the controller has the PVD correctly adjusted. (9)
Mosaicing is an unfortunate approach to the problem of a computer having to deal with multiple radar reports of one aircraft from several radar sites. Mosaicing has been described as a system in which the "best" radar data available is utilized. Under this definition, "best" radar data is not all radar data, and often it is not the optimum radar data. Most airborne aircraft are detected by several ARSR sites simultaneously. (10)
Mosaicing reduces the large ARSR radar coverage of an ARTCC into hundreds of small boxes, and "optimizes(?)" the coverage for each radar into "preferred," "alternate preferred," and "supplemental (11)" categories. These boxes are referred to as Radar Sort Boxes (RSBs). RSBs are rectangular areas of airspace (16 by 16 nautical miles) which are an aid to the computer in reducing the amount of data it must process. (12) A grid of RSBs cover the entire control area of an ARTCC. 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. Mosaicing creates some very undesirable situations in the low altitude environment by not displaying all of the critical radar data which the controller must have in order to perform his job with confidence.
Figure 1 gives an approximation of Cleveland ARTCC's (ZOB's) (13) lateral boundaries superimposed on 473 squares (radar sort boxes). The boxes are shaded to show the mosaicing, or coverage utilized, of the eight ARSRs supplying data to ZOB. (An extension beyond the boundary of approximately two RSBs is included since it is customary for a controller to provide radar service to an aircraft for 20-30 miles before it enters ARTCC airspace.) Radar data is collected at each radar site, processed, and sent to the "HOST" (14) computer over telephone lines or microwave link. There are three ways by which important radar data is not utilized in building the controller's radar picture. Cleveland ARTCC is used in the following examples. It should be understood that ZOB is processing radar data in similar fashion to other ARTCC's. The problems presented here are symptomatic of the entire ARTCC radar data processing system, not just Cleveland ARTCC.
The following discussion concerning compromises made in the display of aircraft on the controller's display deal with aircraft in the low altitude environment. Over half of all near midair collisions occur below 5,000 ft above ground level (AGL). (15)
Any pilot departing the Cumberland, Maryland airport (CBE) to the southeast will find the airplane's transponder will be replying to interrogations from ATC radar much sooner than the ZOB controller will advise (if ever) of "RADAR CONTACT." Likewise, when an aircraft landing at CBE is handed off from Washington Center to Cleveland Center, the pilot will be told "RADAR SERVICE TERMINATED" or "RADAR CONTACT LOST," yet the pilot can observe that the airplane's transponder will continue to reply to ATC radar interrogations until the aircraft descends through approximately 5,000 ft. MSL (17) . This arriving aircraft may be flying between 5,000 to 6,000 ft. MSL for 25 miles without radar service from ZOB, even though radar coverage exists from an ARSR. Such a dichotomy is probably confusing to the pilot.
Figure 2 shows CBE located within ZOB's RSB #433. This RSB is utilizing the "best" radar site for this airspace, which is the ARSR located at Clearfield, PA (QCF). QCF is located approximately 88 nautical miles (nm) north of the CBE airport. The Pittsburgh, PA (PIT) ARSR (which is utilized for the two sort boxes just to the south and southeast of CBE) is approximately 80 nm northwest of CBE. The ARSR which Washington ARTCC utilizes in this area is located at The Plains, VA, which is only 66 nm to the southeast of CBE. Twenty-two nautical miles can make a great difference to an ARSR when dealing with the detection of low altitude aircraft. Due to the line-of-sight nature of radar, many low altitude aircraft in the vicinity of Cumberland are effectively below the horizon of the QCF and PIT ARSRs. Unfortunately, radar data is not utilized from the more suitable (closer proximity) ARSR which is located at The Plains, VA, simply because it is not "on-line." ZOB receives no data from it whatsoever.
The Cumberland, MD area is not the only area where radar service is provided from a less than optimal ARSR. Figure 3 illustrates this same problem that occurs near the Parkersburg, WV VOR. (18)
Similar conditions may occur anywhere within the NAS where existing radar data is not "on-line" to a facility.
Figure 4 shows a typical example of how a RSB that lies directly over a radar site may be programed to not display existing radar data. RSB #725 overlays the ARSR located near Cleveland, OH. With all radars working normally, this 256 square miles of airspace is programed to use data received from the PIT ARSR only.
The airspace contained in RSB #725 lies just to the south and east of Cleveland Hopkins (CLE) airport. Under normal circumstances Cleveland Approach Control (19) has responsibility for aircraft in this airspace below 11,000 ft. MSL, utilizing the Cleveland ASR, which is totally independent of any ARSRs that ZOB utilizes. There have been occasions, however, such as the period of approximately April 15-19, 1988, when Cleveland Approach Control's ASR was out of service. The approach control operated from ZOB, utilizing ZOB's radar display. Low altitude aircraft (below approximately 5,000 ft. MSL) that fly within this 256 square mile area of RSB #725 are not displayed for the controller because they are below the line-of-sight coverage of the PIT ARSR, which is located from between 73 to 95 nm to the southeast. Aircraft that depart Cleveland Hopkins airport are immediately displayed on the ZOB controller's PVD as they become airborne, since the airspace directly over CLE airport utilizes radar data from the CLE ARSR, which is located just 9.5 nm to the southeast of the airport. However, the ZOB display loses (selectively rejects) a southeast bound departing aircraft as soon as it enters RSB #725, which occurs approximately 4 nm east of the airport. RADAR CONTACT is re-established if/when the aircraft climbs above approximately 5,000 ft. MSL, or exits sort box #725. It is important to understand that most low altitude aircraft within this 256 sq. mi. area are detected by the CLE ARSR, unless they happen to be directly over the top of this ARSR, in its "cone of silence" (20). The cone of silence at 5,000 ft. above the radar antenna is about four square miles, which is only 1.5% of the 256 square mile sort box! This cone of silence is the reason why this radar sort box is programed to not make use of the CLE ARSR data. (21) Failure to display low altitude aircraft just southeast of Cleveland Hopkins airport is unsafe. This lack of such critical data being displayed is due to the compromise of displaying data from one and only one radar site within a given RSB.
Another undesirable situation may occur approximately midway between two ARSRs. Consider the data displayed within RSB #681, as illustrated in Figure 5, which lies approximately midway between the PIT and QCF ARSRs.
Mosaicing forces a choice to be made as to which ARSR will provide the "best" coverage. As figure 5 illustrates, the east half of RSB #681 may be best covered by the QCF ARSR (since it is closer), and the southwest corner best covered by the PIT ARSR. Data from one and only one radar site is utilized, and in this case the site chosen was the PIT ARSR. Unfortunately, an eastbound aircraft (Airplane A in Figure 6) in the northeast corner of RSB #681, but just below the line-of-sight coverage of the PIT ARSR (although within QCF ARSR coverage), may be on a collision course with a westbound aircraft (Airplane B). A controller who may be providing radar 'service' to Airplane B, located just to the east of RSB #681, would not have Airplane A on his PVD, even though airplane A would be replying to transponder interrogations (complete with altitude data) from the QCF ARSR.
A review of Figure 1 depicts many sort boxes which lie approximately midway between ARSRs. Is true 'best' coverage really provided by one and only one radar site per given sort box? The situation illustrated in Figure 6 could occur at any of these midpoints between ARSRs where the truly best coverage may change from one ARSR to another within a sort box. Figure 7 illustrates a similar condition that exists in airspace that is not quite midway between two ARSRs.
An aircraft en route from the Greater Pittsburgh, PA (PIT) airport to the Latrobe, PA (LBE) airport will commonly traverse through the very southwestern edge of RSB #581. Typically during the transition through the southwest corner of this sort box, the aircraft will be at a low altitude and beginning a descent for landing at LBE. It is entirely possible that another aircraft, operating VFR, could be on a collision course with the aircraft being provided radar service, yet just below the line-of-sight coverage of the QCF ARSR, which is approximately 65 nm to the northeast. Most likely, this conflicting VFR aircraft is within the coverage of the PIT ARSR, since the aircraft is only approximately 24 miles to the east of this radar. Since the computer will only utilize the QCF ARSR to display traffic within this airspace, the ZOB controller will be unable to issue a safety alert to the aircraft beginning a descent for landing at LBE, simply because the conflicting aircraft is not displayed, even though it is detected by the supplemental ARSR. A difference of approximately 40 nm can be very meaningful when one considers the line-of-sight propagation of radar signals, the curvature of the earth, and low altitudes.
Why would an ARSR that is so far away be utilized when there is a much closer ARSR, such as in the case of RSB #581? The answer is not always obvious, but may have to do with poor coverage along a single azimuth of the closer ARSR, which affects a small but important portion of that same RSB. Unfortunately, when a RSB has an anomaly causing a small portion of poor coverage to exist from a seemingly appropriate (close proximity) ARSR, another (more distant) ARSR may be programed as "preferred." (22) When such a compromise is made, it unfortunately affects the entire sort box, or 256 square miles of airspace. As can be seen, utilizing a more distant ARSR for radar coverage in such circumstances can have a significant affect on the radar presentation, especially in the low altitude environment.
If a problem exists, there is most likely a solution. Selective rejection of radar data, by use of radar sort boxes, is a solution to the problem of dealing with an overwhelming amount of radar data, which our present computer system cannot adequately handle. Unfortunately, such a solution brings along with it a major compromise in the display of low altitude traffic. A solution to each previously mentioned compromise is offered.
The discussion involving Compromise #1 dealt with two ARSRs (located at The Plains, VA and Higby, WV) which, simply by their proximity to the airspace in the examples, would obviously provide superior low altitude radar coverage. The concentration of VFR traffic in the low altitude environment, coupled with the greater percentage of near midair collisions within this low altitude structure, should be a strong motivation toward utilizing such important radar data from currently available, but unused ARSRs.
The currently utilized solution to overcome the problem of selective rejection of aircraft targets using existing software is rather simple and easily accomplished. This involves adapting a RSB to utilize the data from more than one radar site simultaneously (double-preferred coverage). This solution is less than attractive from a human engineering standpoint because it results in unwanted clutter (23). This "quick and dirty" solution will easily remedy the problems of compromises # 2 & 3, however, due to the problem of visual clutter on the display, such programing methods are scantily utilized. The documentation for the NAS software specifically cautions against the use of double-preferred coverage.
"Caution should be used in adapting double-preferred coverage (02 or 03). This coverage will result in the display of all radar returns from both radar sites." (24)
Figure 8 illustrates the presentation of this unwanted clutter (the display of double targets of the same aircraft) when double-preferred coverage is utilized, while it also illustrates how a VFR aircraft within radar coverage may be displayed (or intentionally not displayed) under four different circumstances.
When using "double-preferred" coverage, an aircraft's radar return that is detected by both the designated preferred and alternate preferred ARSRs of a given sort box will show as two targets. These two displayed targets will likely be in slightly different locations, due to the slight misalignment of the ARSRs, inherent radar errors, and the fact that the ARSRs detect the targets at slightly different times. (25) Nevertheless, such "double-preferred" programming occasionally results in important data (i.e. beacon code and/or altitude data of a single aircraft) becoming difficult to read on the PVD because of overlap, as illustrated in Figure 8(B). Double-preferred coverage, while providing the controller with superior low altitude radar data, is currently kept to an absolute minimum. Figure 1 shows only 9 of 473 RSBs utilizing data from two ARSRs simultaneously. (26) The elimination of this visual clutter by not utilizing double-preferred coverage may often mean the elimination of some important low altitude aircraft from the controller's display, as illustrated in Figure 8(C).
The other currently used solution for dealing with selective rejection is somewhat more sophisticated, in that it reduces double targets, but it involves a much greater programming effort. This solution is in the form of a software patch (27) which stratifies the RSB so that the lower altitude coverage will be handled by one radar site, and the higher altitude coverage will be handled by a distant site (28). This patch is designed to handle the "cone of silence" problem that was illustrated in Figure 4 (Compromise #2), where the RSB overlying an ARSR is programed to utilize data from another ARSR much further away. However, this type of stratification would not improve the situations depicted in Figures 5,6, and 7 (Compromise #3). This software patch is optional, and in the case of ZOB, not utilized.
Double targets and their associated clutter are certainly annoying. The lack of a safety advisory from ATC, due to selective rejection, is obviously more annoying, as a lack of radar service can result in the complete failure of ATC's primary mission. The need to eliminate the poor display of targets, often accompanied by double-preferred coverage, is important. We should not, however, be content with the elimination of a target from the display when it happens to be at such an altitude that it is not detected by the preferred ARSR, yet is detected by the supplemental ARSR. The controller must be presented with all the necessary data.
The importance of issuing a safety advisory cannot be overstated. To accomplish the main mission of ATC, the controller needs all aircraft, which are detected by radar, to be displayed. The optimum solution would be to utilize all data, from all radars (ASRs & ARSRs), to track and display all aircraft. Unfortunately, today's processors do not handle the immense amount of radar data that is currently available. It is hoped that when the Advanced Automation System is available (29), all data will be utilized for both tracking and display. In the meantime there must be a remedy utilizing today's equipment and software.
One solution to the problem of selective rejection of aircraft within the low altitude environment would be to display all aircraft detected by all ARSRs. Of course, such a presentation would be totally objectionable, because many high altitude aircraft would be detected by several ARSRs simultaneously. The problem of such unnecessary clutter in the higher altitudes, however, could be alleviated by simply STRATIFYING ALL RSBs. Below a predetermined altitude, all data, from all assigned ARSRs should be processed for display. Above the predetermined altitude, selective rejection would still exist. While such programing would add further clutter to the controller's PVD, this clutter would be associated only with low altitude aircraft that are detected by two (or more) ARSRs simultaneously. As an aircraft (with altitude reporting equipment) climbs above this predetermined stratified altitude (30), double targets would be eliminated, as the selective rejection process of a RSB would then only display one target per aircraft as is currently done. As this same aircraft descends down through this stratified altitude, it would again be displayed as two (or more) targets, in slightly different locations, until it reached an altitude where it is detected by only one of the assigned ARSR sites. The controller's display would then have all aircraft that are detected by ARSRs displayed, especially those important low altitude aircraft where most near midair collisions occur.
Anywhere within the NAS system that existing radar data is not utilized to develop a representation of air traffic, the controller will not be able to achieve his number one priority of issuing safety alerts. The occupants of an aircraft may pay the ultimate price for the compromises that should never have been accepted.
Today's ARTCC radar tracking and display system cannot adequately handle the large amounts of excellent radar data that is currently available. Radar data in today's system is selectively rejected before presentation to the air traffic controller, resulting in the lack of display of some low altitude aircraft which are actually detected by the ARTCC's radar network. Current radar data processing techniques need to be altered. Ultimately, a system which utilizes all radar data, from all ATC radars (ASRs & ARSRs) simultaneously, needs to be developed. In the meantime, FAA needs to reconsider it's primary mission in ATC. Instead of selectively rejecting radar data in the low altitude structure, ATC needs to selectively enhance the radar data of aircraft at these important low altitudes, and display all aircraft which are detected by the existing ARSR network.
Until better display and tracking methods can be realized, ultimately utilizing all data from all radars simultaneously , what can be done? The following recommendations are given:
1. Conduct a complete and comprehensive examination of the RSB programming in all 20 ARTCC's. Identify all Radar Sort Boxes where the possibility exists that low altitude aircraft will not be displayed for the controller, even though these aircraft are detected by at least one ARSR.
a.) Identify all RSBs which have superior radar coverage from an existing ARSR that is currently not on-line with the facility (Compromise #1 example), and promptly bring the data on-line.
b.) Identify all RSBs which enclose an ARSR, but do not utilize that ARSR (Compromise #2 - the "cone of silence" example). Program these RSBs to utilize both sites simultaneously (i.e. double-preferred coverage), or utilize software patch "IT200-CPF-008" to ease the problem with clutter (double targets) while providing all radar targets to the controller's PVD. Make the use of this software patch mandatory at all ARTCC's , rather than optional.
c.) Identify all RSBs that lie at a point between two radar sites (Compromise #3 example), where the better coverage changes from one radar site to another radar site within the RSB. Program these RSBs to utilize double-preferred coverage. While this will result in a great many more RSBs that will display double targets, it is preferable to not displaying an aircraft that is a threat.
d.) Promptly develop a new and enhanced software patch to make possible the stratification of all radar sort boxes, so that all low altitude traffic detected by ARSRs will be displayed instead of selectively rejected. While this will result in some low altitude aircraft being displayed as multiple targets, this approach should be preferred over not displaying an aircraft that is actually detected by an ARSR. Such a patch would eliminate the need for double-preferred coverage at high altitudes, and would actually result in less visual clutter at these higher altitudes where double-preferred coverage is currently utilized, but not really needed.
Thomas G. Lusch is a full performance level air traffic controller at Cleveland ARTCC, beginning his ATC career there in January 1982, and has been a member of the Air Traffic Control Association since 1984. Mr. Lusch holds a commercial pilot certificate, glider rating, and is an active instrument pilot. His strong interest in the processing of radar data began in 1985 when a commuter pilot en route from Dubois, PA to Pittsburgh, PA (for whom he was providing radar service), experienced a near midair collision with an aircraft that was not displayed on his PVD until shortly after the near collision.