| by |
Mike Busch |
This article originally appeared in IFR MAGAZINE.
|
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...
"VIKING 592, LOW ALTITUDE ALERT, CHECK YOUR ALTITUDE IMMEDIATELY! THE
MDA IS 460 FEET. ACKNOWLEDGE."
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."
ATC's top priority
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.
How low can you go?
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).
Tricky tracks
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 a
track 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.
A better mousetrap
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 the
predicted 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:
"(Identification) LOW ALTITUDE ALERT, CHECK YOUR ALTITUDE IMMEDIATELY. THE
MEA/MVA/MOCA/MIA/MDA/DH (as appropriate) IN YOUR AREA IS (altitude)."
before the airplane goes "splat." And MSAW usually does.
False alarms
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
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:
"(Identification) TRAFFIC ALERT (position of traffic), ADVISE YOU TURN LEFT/RIGHT TO
(heading), and/or CLIMB/DESCEND TO (altitude), IMMEDIATELY."
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.
Flight of the intruder
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.
The infamous "snitch"
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:
-
It's nobody's fault. There are some legitimate situations that can set off the snitch. Military aircraft
joining up in formation can do it, for example, or a civilian aircraft that cancels IFR and then sets off the
snitch before the controller has the chance to tell the computer of the target's change of status. In these cases,
there's no fault and no foul.
-
It's the controller's fault. In this case, the controller is immediately pulled off position and de-briefed.
He gets a black mark on his record. He might be decertified and given remedial training. If it happens often
enough, he might even lose his job. So you can bet that the controller is going to do everything in his power
to convince the Area Manager that the loss of separation wasn't his fault.
-
It's the pilot's fault. That's the only other possibility. So if the controller succeeds in persuading the Area
Manager that he didn't screw up, guess who's gonna get a letter from the Friendlies? You
betcha!
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.
Email this article
