Say Again? #44: Looking For Trouble
Trouble can come from an air traffic controller who, like AVweb's Don Brown, is conscious of all the ways things can go wrong and keeps bothering his supervisors about them. Trouble can also come from a radar system that, apparently, ignores the very traffic a controller (and other pilots) want to see. Don explains all in this month's Say Again? column.
I once had a supervisor accuse me of "just looking for trouble." I want you to pause and let that sink in for just a second. I know I did. An air traffic controller -- a safety rep no less -- looking for trouble. "Uh, yeah, I guess you're right about that, boss. I am looking for trouble." That's part of my job isn't it?
My first trainer told me that 90% of air traffic control was finding a problem before it became a problem. I've found that to be sound advice for the last 20 years. That's just another way of saying that you should look for trouble, isn't it? I've mentioned controller scanning techniques to you before. That's what controllers are scanning for, isn't it? Trouble? After all, we're not looking for the airplanes that are going to miss ... we're looking for the ones that are going to hit.
I think the supervisor was trying to say that I go out of my way to look for trouble. He might be right about that. I do tend to be a little more zealous about it than many controllers. Not all of them, but most of them. I think the real problem was what happens when I find a problem. I notify the supervisor. That is the FAA's procedure for just about anything: Notify your supervisor. I take it to heart. It drives some supervisors crazy.
It doesn't do me much good, though. I had the perfect example the other day. There was a VFR passing through -- squawking 1200 -- and indicating Flight Level 305. No, he wasn't really at 30,500 feet. That was just what the Mode C was showing. It was broken. I called him as traffic to an airplane passing by and, sure enough, he was down below 10,000 feet. I took the opportunity to show a few controllers a problem I first noticed around 20 years ago.
A Long, Long Time Ago
When I started with the FAA, aircraft squawking VFR (code 1200) weren't included in the programming for Conflict Alert. The Conflict Alert programming is the computer program that alerts a controller to a possible conflict between two (or more) aircraft. If the aircraft in question are three minutes or less apart and the computer believes that legal separation will not exist between them when they pass, the Conflict Alert goes off and causes both data blocks to flash on the controller's radar scope. It's highly annoying and it's meant to be. The program is designed to get your attention. Without fail.
That is all well and good but somebody had a better idea. I'm pretty sure it was a pilot. Anyway, the FAA decided to include VFR flights in the Conflict Alert program. That sounded pretty reasonable. Especially to somebody who doesn't sit in front of a radar scope eight hours a day. But things aren't always as they appear.
The first thing that happened was a little bit of the fear factor went away. There wasn't a controller out there who hadn't been burned, missing a traffic call on a VFR. That always kept controllers a little on edge. It made you look harder when you were working the low-altitude sectors. You were always looking for the VFR that was trying to slip through your scan. A little fear isn't necessarily a bad thing.
The next thing that happened was the Conflict Alert went off more. A lot more. Especially if you had a sector that was 10,000 feet and below (like I did) with lots of VFR traffic. Once upon a time the alert parameter on the Conflict Alert program was set at two minutes. If it went off unexpectedly, it really got your attention. You knew you didn't have much time to fix the problem. The local management bumped it up to three minutes, hoping it would cut down on the number of operational errors. Between that and adding VFRs to the program, the Conflict Alert was going off a lot. One other thing I need to mention, I guess: The altitude parameter wasn't changed for issuing an alert. If you had a VFR at 6,500 pass an IFR at 7,000 (which is perfectly fine), the Conflict Alert would go off the entire time because you didn't have 1,000 feet separation like you would between two IFR aircraft.
On a busy VFR day is wasn't unusual to have the Conflict Alert to go off almost constantly between various and assorted aircraft. It's sort of like the boy who cried wolf. After a while you just didn't get as excited about the Conflict Alert going off like you did before.
Be Very Afraid
All in all the decision to include VFRs in the Conflict Alert program was probably a wash. There was an added level of protection for noticing VFR traffic. It came at the cost of slightly less vigilance and a decreased sensitivity to the Conflict Alert. I probably wouldn't have thought much of it except for one other change the FAA made about the same time.
From the FAA 7110.65 Air Traffic Control manual:
5-2-13. CODE MONITOR
Continuously monitor the Mode 3/A radar beacon codes assigned for use by aircraft operating within your area of responsibility when nonautomated beacon decoding equipment (e.g., 10-channel decoder) is used to display the target symbol.
a. This includes the appropriate IFR code actually assigned and, additionally, Code 1200, Code 1255, and Code 1277 unless your area of responsibility includes only Class A airspace. During periods when ring-around or excessive VFR target presentations derogate the separation of IFR traffic, the monitoring of VFR Code 1200, Code 1255, and Code 1277 may be temporarily discontinued.
b. Positions of operation which contain a restricted or warning area or VR route within or immediately adjacent to their area of jurisdiction shall monitor Code 4000 and any other code used in lieu of 4000 within the warning/restricted area or VR route. If by local coordination with the restricted/warning area or VR route user a code other than 4000 is to be exclusively used, then this code shall be monitored.
The part of all that I want you to note is this: "Continuously monitor the Mode 3/A radar beacon codes ... when nonautomated beacon decoding equipment is used to display the target symbol." The key phrase is "nonautomated." At least that is how I understand it. I'll be honest, I really don't know what a "10-channel decoder" is. But about the time they "automated" the display of VFR codes by including them in the Conflict Alert program we were told we didn't need to put 1200, 1277 and 4000 in our "code list." anymore.
Breaking the Code
I guess that means I'll have to explain the beacon code list. This is getting complicated isn't it? Stick with me -- I promise it'll be worth it.
Again, a long time ago, Center controllers working in the low altitudes were required to put the beacon codes 1200, 1277 and 4000 in their code list. (1277 is for aircraft conducting search and rescue operations and 4000 is for certain military flights, usually conducting rapid VFR maneuvers. Code 1255 -- VFR fire fighter -- was added some years later.) When you insert a code into your code list, it forces any aircraft squawking that code onto your radar scope, no matter what altitude the aircraft is at or what are your altitude limit settings. It also increases the brightness of the target and beacon code if you don't have a data block attached to the target. It just makes it easier to notice the target.
This is how it works. Say you're working a sector where the bottom altitude you "own" is 11,000 feet. You're required to set your lower altitude limit no higher than 9,800 feet. That way you can see and call traffic at 10,000 that is below your sector, but you don't have to look at all the clutter from all the targets that are below 9,800; everything below that is "filtered" out. But you decide to keep 4000 in your code list, because you know how fast the military will come out of a VR route and you want the extra time to notice it. If there is somebody below you squawking 4000, that target will display on your scope no matter what its altitude.
Me, being the Chicken Little type, just kept on putting 1200 and 4000 in my code list even though it wasn't a requirement any more. A lot of controllers found it annoying. Every time they relieved me for a break they'd have to take 1200 and 4000 out of the code list to reduce the clutter on their radar scope. An old supervisor had enough of the complaining one day and decided to confront me about it.
"Brown, why do you keep putting 1200 in the code list?"
I want to make sure you understand this scene. I'm a still-wet-behind-the-ears controller. Heck, I wouldn't even be a controller yet except for the fact that the FAA was in a rush to check out controllers after the strike in 1981. And here's this supervisor -- with more experience than his whole crew put together -- wanting to know why I'm rocking his boat. Back then, the FAA didn't take too kindly to boat-rockers.
"Well," I said, "the first thing y'all taught me about Mode C was that it doesn't mean anything if it isn't verified."
"What's your point, Brown?"
"Well, look what happens to this VFR when I take 1200 out of the code list."
I took it out and "poof!" the target disappears. The target wasn't within my altitude limits so the computer erased it from my scope.
"See what I mean? The computer is (in effect) verifying an unverified Mode C."
The supervisor didn't say a word. He just turned around and walked off.
Back to the Future
Fast-forward 20 years to the incident I described when I started this tale. There's a VFR showing FL305 but I know he's below 10,000 because other traffic saw him. Like I said, I took the opportunity to show some other controllers what would happen if I didn't have 1200 in the code list. A conversation about what -- exactly -- was happening ensued. Let me make sure you understand it.
Without 1200 being in my code list, that VFR didn't exist in my low-altitude airspace. The computer would just wipe it off the scope, because it assumed the plane was at 30,500 feet. There wouldn't be a "V" for a VFR target, there wouldn't be an "+" symbol for a primary target, and the Conflict Alert wouldn't go off. I couldn't call traffic on it because it just wasn't there. A pilot passing close to the VFR could say "Hey! Who was that?" and I wouldn't have any idea who he was talking about. He could have hit him and I'd have never realized what happened.
Most of the controllers understood the process but there were a few puzzled expressions. That's the part that bothers me. You see, I have to assume that whoever designed this feature of the system did so knowing its limitations. They knew what would happen, weighed the benefits versus risks, and decided that the former outweighed the latter. So how is it that 20 years later there are some controllers who are puzzled by it? Why don't they know the limitations of this system? Perhaps the most pertinent question is, do the people running the system now know of that limitation, and why haven't they been able to do anything about it?
I really don't have to look that hard to find trouble. It seems to find me on a regular basis. While I'm writing this, it's the day before Thanksgiving. Historically it's our busiest day of the year. Under the heading of "be careful what you wish for," the controllers' prayers were answered this year. We had so many thunderstorms that it pretty well wiped out the general aviation crowd. We only worked 8,625 operations this year on the day before Thanksgiving. Funny, I remember when that would have been a record day. Now it's "only." We worked 9,786 operations on the Wednesday just the week before. I must be getting old. And off track.
Where were we? Oh yeah, in trouble. Anyway, I show up for work at 7:30 a.m. and notice a line of thunderstorms about 50 miles or so west of ATL (Atlanta.) This is not good. I'm especially concerned about it this morning. My wife is flying back into ATL, and I realize it'll be a race between her flight and the thunderstorms. I can just imagine her flight getting diverted to GSP (Greenville-Spartanburg, S.C.) or TYS (Knoxville, Tenn.) on the busiest flying day of the year. What a nightmare.
Oh well. That's the reason they pay us the big bucks. We knew what was coming. You just pull your hat down tight, nod your head and wait for the rodeo to begin.
Despite the obvious, Flow Control was missing in action (again). The first warning came when I was pulling strips on the A-side. Flow Control, a.k.a., the Air Traffic Control System Command Center, put out a "ground stop" to ATL. That means planes getting ready to fly to Atlanta have to wait on the ground. That probably sounds good to you since it'll prevent planes from being put into a holding pattern in the air near Atlanta, but what it sounds like to those of us sitting in front of a scope is a warning. We post the ground stop (it's printed on a strip and we "post" the strip on the sector) on the low-altitude sectors so they don't clear anybody else to ATL but we tell the high altitude sectors about it because we know from experience that somebody is going to tell us to hold the arrivals.
Sure enough, a few minutes later I'm working the SALEM sector and Atlanta Tracon shuts the door. That causes a chain reaction. The Tracon stops taking the arrivals, the LOGEN sector -- feeding the Tracon -- stops taking them from the LANIER sector and LANIER stops taking from me at SALEM. I look and I've got six ATL arrivals with only two altitudes to hold them in: FL310 and FL330. You have to keep in mind that SALEM is an en route sector over 150 miles from ATL. Airplanes at FL310 make really big circles and I'm expected to keep taking the airplanes en route to the rest of the country.
Six arrivals and two altitudes means I have four more than I know what to do with. This is a no-brainer. I call the controllers at Washington Center and Indianapolis Center and tell them we're not taking any more ATL arrivals. That giant flushing sound was controllers from Atlanta to New York going down the toilet.
My wife's airplane beat the storm to ATL. She drove right past the Atlanta Center (ZTL) building on her way home. Every traffic light between ATL and ZTL (about 15 miles) was out. We lost our power too, by the way. We spent the next few hours operating on generator power.
It was a heck of a storm. Everybody saw it coming. There were SIGMETS out all morning for tornadoes. Everybody knew it would be trouble. Except (it seems) Flow Control. Controllers have started referring to the thunderstorms around Atlanta as "stealth" thunderstorms.
I'm probably being unfair. I know there are some good people in Flow Control because I talk to them. I'm certain I don't know the whole story. I'm already hearing the rumors about "they" wanted this and "we" wanted that. Regardless, a bunch of controllers wound up spinning a lot of airplanes without any plan. I don't know how that equates to safe, orderly or efficient.
What I do know is that it's easier (and safer) to hold six airplanes on the ground than in the air. I know that it isn't really hard to put 1200 in your code list. I know that it's better to err on the side of caution when you're charged with keeping other people safe. Yes, I am looking for trouble. Apparently, I've come to the right place.
Have a safe flight.
Facility Safety Representative
National Air Traffic Controllers Association
Want to read more from air traffic controller Don Brown? Check out the rest of his columns.