Computer-Generated Safety Alerts

Picture this. You're flying a textbook VOR approach. You're ahead of the airplane and doing everything right. ATC gave you a perfect radar vector turn-on to the final. Crossing the FAF, you started the timer, dropped the gear, and pulled the power back for a nice steep 1,000 FPM non-precision descent. You've committed the MDA and the initial missed-approach procedure to memory. Any moment now you expect to break out below the overcast...

The adrenalin rush gives you goose bumps, dilated pupils, and tachycardia. You check your altimeter: 600 feet and descending. The Kollsman window isset to 30.06, exactly what you wrote down when you copied the ATIS. The approach plate lists the MDA as 460 feet.

What's going on here? You've done everything by the book. You're not even down to MDA yet, much less below it. Why is this controller trying to give you cardiac arrest?

If you ask, the controller will give you the same explanation that you got from American Express when you called to complain about that $17 million charge on your monthly statement: "Don't blame me, it's the computer's fault."

The ATC manual tells controllers to give first priority to separating aircraft and issuing safety alerts. The controller is required to issue a safety alert whenever he becomes aware that your aircraft is at an altitude that (in his judgement) places you in unsafe proximity to terrain,obstructions, or other aircraft.

There are two basic flavors of safety alert: a LOW-ALTITUDE ALERT warning of proximity to terrain or obstructions, and a TRAFFIC ALERT warning of proximity to other aircraft.

A controller's ability to recognize such unsafe situations is obviously dependent upon his experience, skill, and (especially) workload. If the poor fellow is juggling fifteen airplanes, he can't allocate much time to making sure you don't bump into a TV tower.

For this reason, the FAA's automation gurus decided to help the controllers by providing automated safety alerts. During the past ten years, the software in the radar processing computers at Centers and Approach Controls has been enhanced with various software "patches" that alert controllers to potentially unsafe situations. These enhancements are known to controllers by their alphabet-soup acronyms: "CA" means Conflict Alert, "LAAS" means LowAltitude Alert System, "MSAW" means Minimum Safe Altitude Warning, and "MCI" means Mode C Intruder (which is why most controllers use AT&T or Sprint).The most infamous software patch of them all—the Operational Error Detection Patch—surely deserves a fancy acronym like OEDIPUS or somesuch, but instead is universally referred to by its disparaging nickname: "snitch".

On balance, these new automated alarms have been helpful in preventing accidents. But they've created their own set of new problems in the form of nuisance alerts on the one hand and excessive reliance on the other.

The earliest attempt at automated safety alerts was a straightforward software function called Low Altitude Alert System (or LAAS). It still exists in a few low-rent approach control facilities that are equipped with ancient AN/TPX-42A radar gear.

Under LAAS, the terminal area is divided up into a grid and each square is assigned a predetermined minimum safe altitude. Whenever the computer sees an IFR aircraft that is reporting a Mode C altitude below the minimum safe altitude of its grid square, the computer sounds an alarm and highlights the target on the controller's radar scope. Sounds simple and logical, doesn't it?

In practice, LAAS turned out to have a number of deficiencies. It is quite common for Mode C altitude data to be momentarily corrupted by a phenomenon called "synchronous garble", which can occur when several aircraft are at a similar bearing and distance from the radar site although at differentaltitudes. Garbled Mode C data can cause LAAS to issue bogus low-altitude alerts, which can be a real nuisance.

Furthermore, the minimum safe altitude threshold in each grid square can't simply be set to the published MEA, MOCA, MVA, MIA, or MDA. If it were,there would be a veritable tidal wave of nuisance alerts. Aircraft cruising at the MEA commonly make excursions of 100 or 200 feet from the assigned altitude. Altimetry problems and encoder slop can add another 200 feet of error to the Mode C data. Thus, the LAAS grid thresholds must be set quite low to keep the incidence of nuisance alerts to an acceptable minimum.

But this creates another problem. Pressurized aircraft commonly descend at several thousand feet-per-minute. An alert triggered when such an aircraft descends through the warning threshold doesn't provide much warning time before terrain impact. Like maybe: "MIRAGE 648, LOW <splat!> ALTITUDE ALERT...oops, now where'd I put that clipboard full of accident/incident reporting forms?" This problem is exacerbated by the fact that the LAAS software is working on altitude data that is typically 6-12 seconds old (due to the nature of rotating-antenna radar and the limited processing speed of the computer).

By virtue of its short warning time and its proclivity for nuisance alerts, simpleminded LAAS isn't anything to write home about. Which is why it is nearly extinct (except in a few small hand-me-down terminal radar facilitiesthat still use AN/TPX-42A radar).

Today, most TRACONs use a far more sophisticated automated terminal radar system known as ARTS. ARTS differs radically from older radar systems inthat the ARTS computer maintains atrack on each aircraft that a controller is working. The computer tracks all IFR beacon targets plus those VFRs who are receiving radar service.

For each tracked target, the computer maintains a history of the location and altitude readout of that target during each of the past several radar sweeps. From this history, the computer computes the target's course, horizontal velocity, and vertical velocity. It then extrapolates from this information and tries to predict where the target will be on the next radar sweep.The computer advances the target's computer symbol and alphanumeric datablock to the predicted position.

When the transponder return from the next sweep actually arrives, the computer tries to correlate it with the predicted position of the target. If the transponder return shows up reasonably close to where the computer predicted it would be, the computer accepts the beacon return as valid and updates the target's position.

On the other hand, if the transponder return is missing or garbled or seems to be ridiculously far away from the predicted position, the computer ignores it and sticks with its prediction for another sweep. The computer will continue to "coast" the track for several sweeps...but if it doesn't eventually receive a reasonable-looking transponder return from the aircraft,the computer will drop the track from the radar screen. A dropped track might be caused by all sorts of things: a transponder failure, an aircraft flyingout of or below radar coverage, a prolonged episode of synchronous garble, or even a sudden sharp change of direction that fakes out the computer's prediction algorithm.

This track concept in ARTS made it possible to create a greatly improved system called Minimum Safe Altitude Warning. MSAW eliminates most of the problems with LAAS.

For one thing, the problem of garbled Mode C returns is solved because the computer can correlate each Mode C reply with prior altitude data from the track's history, and can thereby detect and ignore bogus Mode C replies.This eliminates a major source of nuisance alerts that plagues LAAS.

More importantly, the track history allows MSAW to predict what the position and altitude of a tracked target will be, say, 30 seconds from now. The computer can generate an alert if thepredicted altitude of the aircraft is below the minimum safe altitude for its predicted position.Thus, MSAW can issue alerts with significantly greater warning time than LAAS. The objective is to make sure that MSAW sounds its alarm early enoughto give the controller time to transmit all of the required phraseology:

before the airplane goes "splat." And MSAW usually does.

If MSAW has a weakness, it's that the computer knows nothing about clearances or pilot intentions...all it knows is what it "sees" on the radar scope. When MSAW sees an aircraft descending rapidly toward the MEA/MVA/MDA, it assumes that the aircraft will continue descending at that rate for awhile and consequently generates an alert. Such nuisance alerts are particularly common during non-precision approaches.

Now imagine for a moment that you are a radar controller. You see an MSAW alert flashing on the data block associated with one of the aircraft you are working. You know the pilot is making a non-precision approach, and so you're pretty sure that the alert is a false alarm. What do you do? Do you issue a low altitude alert to the pilot, or do you disregard it? Theoretically (according to the ATC manual), it's your judgment call. But in practice, you have no real choice. If you don't issue the alert and then the aircraft winds up pranging, guess what happens to your career? So...you go ahead and issue the alert, even though you're 99% certain that it's unnecessary.

To reduce this problem of nuisance alerts, each TRACON defines the airspace in the immediate vicinity of busy airports as "Type I" areas, and the commonly used approach corridors as "Type II" areas...all the rest of the airspace is considered "Type III." MSAW is programmed to disable alerts TypeI areas, and to shorten its look-ahead time in Type II areas.

In addition, MSAW must detect a low-altitude problem with a target for two consecutive sweeps before it will generate an alert. This helps reduce the frequency of nuisance alerts due to momentary altitude excursions.

Overall, MSAW received such high marks at TRACONS that the FAA installed a similar software enhancement known as Enroute Minimum Safe Altitude Warning (E-MSAW) at all of the Air Route Traffic Control Centers. So if you're in radar contact and squawking a discrete IFR code, it's almost a sure bet thatMSAW is watching out for you.

MSAW can also watch tracked VFR targets that are squawking a discrete code. However, most ATC facilities disable MSAW on the code blocks that they assign to VFRs. They do this to reduce nuisance alerts, and their rationale is that ATC is not responsible for terrain separation on VFRs.

Conflict Alert (CA) is a software enhancement whose objective is to warn controllers of potentially hazardous proximity situations between aircraft. To steal a phrase from Apple Computer, Conflict Alert is "TCAS for the rest of us."

By using projective techniques similar to those used in MSAW, CA tries to provide sufficient warning time that the controller can take action to prevent loss of standard separation...or at least avert a collision. In a TRACON, the CA warning objective is 30 seconds prior to collision; in an ARTCC, it is 80 seconds.

In the Center, CA-generated alert causes the data blocks of both aircraft to blink on the controller's radar screen. In a TRACON, it puts up a blinking "CA" in the upper right hand corner of each data block, and sounds an audible alarm as well. When the controller sees the CA alert, he is supposed to warn the pilot(s) using the following standard phraseology:

Despite the sophistication and complexity of its software, CA still generates lots of nuisance alerts. Like MSAW, CA's Achilles' heel is that it doesn't know anything about clearances or pilot intentions.

Imagine two IFR aircraft at the same altitude and on converging courses. CA predicts that the two targets will merge in 30 seconds and generates an alert. The controller knows that there's really no problem because one of the aircraft is about to intercept the localizer and make a 30-degree left turn. Or perhaps one of the aircraft has reported the other one in-sight and is maintaining visual separation. So the controller ignores the computer alert and you never hear about it.

Unfortunately, CA cries "wolf" so often (especially in a terminal area) that controllers are often tempted to disregard its warnings even when there is a real collision threat. But there's not much that can be done about this until ATC starts issuing clearances to aircraft via keyboard and digital data-link.

CA works only on tracked targets. In a TRACON, the computer usually tracks only transponder-equipped aircraft that are squawking a discrete code...this typically includes all IFRs and those VFRs that have requested radar service. This means that if you are flying IFR and about to be boresighted by a VFRaircraft squawking a 1200 code, you better hope the controller notices it...the computer definitely won't. This is one of the motivations behind the imposition of ARSAs and TCAs. An ARSA or TCA ensures that all VFRs within high-density terminal airspace are squawking a discrete code and being tracked by the ARTS computer. In the high-altitude enroute structure, Positive Controlled Airspace performs the same function: it assures that all aircraft at FL180 and above are being tracked.

That still leaves aircraft that fly below FL180 in jeopardy. So a few years ago, the FAA automation whizzes came up with a new software patch with a dramatic sounding name: Mode C Intruder (MCI). MCI is now implemented in all ARTCCs. What MCI does is simply this: it looks for any target that is squawking 1200 with Mode C within Center-controlled airspace and automatically starts a track on it. Such "intruder" tracks are identified on the Center controller's radar scope with the letter "I" and a limited datablock that identifies the target as VFR and displays its altitude. Intruder tracks are processed by CA in much the same fashion as the tracked targets of IFR and participating VFR aircraft.

The bottom line on MCI is this: when you're flying IFR (or VFR with advisories) in Center airspace, you are now significantly more likely to receive traffic alerts on non-participating VFR aircraft than you used to be. And that's definitely good news.

What isn't such good news is another software patch that was installed in all ARTCCs during the mid-1980s: the Operational Error Detection patch. The idea behind "snitch patch" is simple: whenever a loss of standard separation occurs between IFR aircraft in Center airspace, the computer lets the Area Manager know by sounding an alarm at his desk and printing out a report. The Area Manager then trots over to the radar console for the sector where the"deal" occurred and has a little talk with the controller to find out whatwent wrong. Sounds pretty reasonable, doesn't it?

Ah, but here's the rub. When the snitch wakes him up, the Area Manager is required to determine who was at fault in the loss of separation and then submit a report to his boss. There are three possibilities:

The snitch patch and the FAA's it's-gotta-be-someone's-fault policy that accompanied the implementation of snitch has had a real chilling effect on the relationship between pilots and controllers during the last decade. The relationship used to be one of camaraderie and teamwork. Nowadays, it's more likely to be adversarial. Since the advent of snitch, Center controllers are a lot more conservative about separation and workload issues than they used to be. Can you blame them? To IFR pilots like you and me, this meansmore ATC delays. It also means that we pilots receive a lot more violations and certificate actions than in the pre-snitch days.

In the opinion of this humble scribe, the "kinder, gentler FAA" definitely needs to make some changes in this area.