Question: What were non-radar operations called before radar?
Answer: Air Traffic Control
You may wonder why I'm putting the very basics -- the bedrock -- of Air Traffic Control in an advanced class in my series of ATC courses. The answer is simple: Because it's complicated. It also involves a lot of math. I hate math. Be that as it may, nobody seems to think about these things anymore and we need to think about them. Hopefully, if you do think about these things, it will help you fend off the reality-distortion field that emanates from some of the folks trying to sell you something.
There are some things that you just can't change. Like gravity. Or distance. Or time. This train of thought really hit me when I was talking to a controller who was about to retire a few years ago. We were talking about air traffic control in general and he mentioned that it still took a jet 46 minutes to get from GSO (Greensboro, N.C.) to the MACEY intersection (the arrival fix on the northeast side of Atlanta).
The first thought that popped into my head was, "How does he know it takes 46 minutes? Exactly?" Remembering that he was an older controller, he'd calculated it a million times. Well, he probably only calculated it a dozen times or so on a whiz-wheel, but he'd written it down a million times. What's that? What's a whiz-wheel? Geez, I must be getting old. A whiz-wheel is a mechanical computer -- a circular slide-rule. Pilots (and probably controllers) used the model E6-B. Here, take a look.
Anyway, this controller had worked in the days of manual flight-data processing. That's just fancy language for handwriting flight-progress strips. When FSS sent a flight plan to the Center, the guys in the Flight Data section would take the information, calculate the distances between the fixes in the flight plan, factor in the speed and figure out the time it'd take the airplane to travel the distance. They would hand-write the strips for each sector and deliver them to the controllers on the floor. I suspect (I never actually had to do this myself) that after the 10th, 11th or 12th time they'd done the calculations and come up with 46 minutes for the same Eastern, Piedmont, Southern and Delta flights everyday, they just started remembering that GSO to MACEY was 46 minutes. And it didn't really matter if they were flying DC-8s, DC-9s or Boeing 737s. The speed differences weren't enough to make a three-minute difference and that was as accurate as they had to be.
You can fast-forward to today, use a personal computer, a mainframe or an E6-B and you'll still get the same number: 46 minutes. The distance hasn't changed and the speeds of the airplanes haven't changed much, even if they are B757s and regional jets. Back in those days, the controller at GSO used to call the arrival sector (the LOGEN sector) for ATL and request approval to launch the flight off GSO. The arrival controller would take the proposed flight-progress strip, see the "+46" on it, add that to the current time and put the strip in sequence with the other strips. Just to keep the math simple, let's say the proposed departure time was 00:00Z. The controller would write down 00:46 for the MACEY time and put it on the strip board in time sequence. That made it easy to see that he had arrivals due over MACEY (for example) at 00:44, 00:45, 00:46, 00:47, 00:48 and then a "gap" until the next arrival at 00:55. Obviously, he wouldn't want the arrival from GSO over MACEY before 00:49. 00:49 - 46 = 00:03, for a departure time of 00:03. He'd "release" the GSO departure "at or after 00:03Z."
Today, this function is in the realm of "Flow Control," a.k.a., the Traffic Management Unit. They (of course) use computers running "sophisticated" computer programs that can re-sort the times in the blink of an eye and do it without making any telephone calls to the sector controllers for any approval. It's really complicated and it's really involved but they still come up with the same number: 46 minutes.
And to tell the truth, this process really doesn't work much better than it did back in the old days. Planes are still late leaving the gates, other traffic still prevents them from departing at precisely 00:03 and they still deviate around thunderstorms and wind up over MACEY tied up with some other airplane that was late, or early or actually on time. So, it doesn't work any better but the process is a whole lot faster.
Air traffic control is still about making sure that two airplanes don't occupy the same space at the same time. While the math involved gets complicated, in the end, you're left with two factors: space and time. A vector for traffic just means that a controller is pointing you towards the space currently occupied by another aircraft knowing that by the time you get there the other plane will be gone. No matter how involved the process gets, no matter how sophisticated your new glass panel is, it's still all about space and time. Even on the runways and taxiways.
Just because people tend to forget, let me restate that I'm a Center controller. I don't get to say "cleared to land," "taxi," "cleared for takeoff" or any of that other cool stuff that the swivel-heads get to say. I do live and die by runway acceptance rates, though. Just like the rest of air traffic control, the math might be tough but the principle is simple. Only one airplane gets to occupy the runway (the space) at one time. We can change that if you'd like. The military does it all the time and we do it at Oshkosh (and a few other places) every year. But in the normal world, it's one airplane at a time.
Once you accept that premise, the math is inescapable. It takes a certain amount of time for an airplane to flare, touchdown, slow down and taxi off the runway. There might be small variations in that amount of time but you can average it out. Just to keep it simple (have I mentioned I hate math?) let's say it's 60 airplanes an hour. That's one airplane per minute. If you don't use the runway for anything except arrivals, that is 60 arrivals per hour. If you let any departures use it (or airplanes being towed to a hangar across the field or airport personnel checking the runway surface or anything else) that number starts going downhill in a hurry.
To put it in real-world terms: At Charlotte, N.C., the very best airport acceptance rate you can expect is around 70 airplanes per hour, or about one plane every 51 seconds. That is if the wind doesn't blow the wrong way, the weather is good and all the planets and stars are aligned correctly. This explains why the airlines schedule 78 per hour -- because we all know how reliable perfect weather is. Actually, the airlines don't schedule 78 per hour; they just schedule a bunch of planes to arrive in a short time span. But to get all those flights on the ground during that time span, Charlotte would have to land a plane every 46 seconds and Charlotte can't do that even on the best day. Someone is going to be late; and lots of flights will be late when the wind shifts and the storms move through.
Yes, yes, I know that the airlines are just flying when their customers want to fly, the role competition plays and all that. I also know that controllers can't defy the laws of physics no matter how many times somebody says "air traffic delays." So, let's just stick with the math for the time being.
If we can't put but one airplane on the runway at a time and the modern airliner can't hover, we're back to dealing with space and time in my neck of the ATC woods: holding. Sure, you can slow them down and you can make a half-dozen S-turns starting 200 miles from the airport. We do all that and more. But sooner or later, you wind up holding.
Holding -- to some folks -- takes up too much space. Excessive vectoring -- to me -- takes up too much time. Pick your poison. I will make one observation while I'm here, though. There seems to be a trend amongst controllers to avoid holding at almost any cost. It might be because some of our new equipment makes it uncomfortable to hold or because holding is counted as a delay while a 60-mile vector isn't. Whatever the reason, I saw one the other day where the airplane had been on a vector away from the airport for about 60 miles. The pilot finally had enough and asked the controller when he could expect to turn back towards the airport. He was trying to calculate his minimum-fuel time and, because the space between him and the airport kept increasing, it was proving to be problematic. (Just consider this one of those random thoughts that hit me while I write. No need to dwell on it.)
Where were we? Ah yes, the fundamentals. The basics. Let's talk about crossing traffic a moment. To deduce a way to separate crossing traffic you must first figure out a way to determine if they are (indeed) crossing. That may sound silly to some of you but if you'll turn off your mental picture of a radarscope for a moment you'll see it isn't quite so simple. Take these two examples for instance:
1A5 direct 78N
35A direct 0A9
Where -- exactly -- do they cross? Or do they cross at all? How would you like to define the point at which they cross? By a latitude/longitude coordinate ? A fix radial/distance? A landmark? A street address, perhaps? Are you getting my point?
Right now, the vast majority of you aren't even certain they cross. Let me redefine the routes for you and let's see if it gets any easier.
Can you tell if they cross now? I can. I can tell you precisely where they cross. At the GENOD intersection. Although a number of you will now be able to grasp that we are somewhere near the North Carolina - South Carolina border, I suspect the vast majority still don't know where GENOD intersection is and can't envision what these routes look like in relation to each other. Yet, in order to ensure that these two aircraft are separated, that is exactly what controllers must do: envision what the routes look like. Let me narrow it down for you further.
Now that we know the precise point at which these two aircraft will cross, we have to figure out what to do about it. First, we'll need to check the altitudes. They are (of course) at the same altitude or otherwise this wouldn't be any fun. If the space (altitude and location) is the same, then the only thing we have left that might work for us is time. In other words, we've already established that these two flights will indeed occupy the same space so the only question remaining is, "Will they occupy the same space at the same time?"
I'll spare you the discussion on how we define time and it's relationship to location (space) but if you never saw (or read) "Longitude" you might want to check it out. Fascinating stuff. Anyway, we return to our calculations (whether with pencil and paper, whiz-wheels or mainframes) and we determine that, yes indeed, these two aircraft are estimated to be at the same space at the same time.
A controller's job is to now determine at what point they will no longer be separated (using the appropriate minimum) so as to make sure some alternate form of separation (like altitude) exists by prior to that point. To do this, you need to know what the route width is (4 nm either side of the centerline), how accurate the navigation system is (we're using two different VORs: SUG and SPA) and the angle at which the two routes intersect. Toss in the speed, the margin of error and a large fudge factor. Pull out your slide rule, do some math (that is way beyond my capabilities) and you come up "the number."
Or you can just look in the book and see what it says. In this case it's 10 minutes if you don't have DME (yes Virginia, there are still some of those out there) or 20 miles if you have DME. We'll assume that both of these flight have DME so, 20 miles prior to GENOD, one of these flight has to be at a different altitude or the controller has to come up with a Plan B. Plan B could be a reroute (change 35A..SPA.V605.HMV..0A9 to 35A..SPA. V53.SUG.V35.HMV.0A9) or you could delay (hold or slow down) one of them for 10 minutes until the other one passes. I think that will pretty much explain why controllers are taught to "think altitude" most of the time.
Just so you won't think that air traffic control is as simple a separating two airplanes, I'm going to say that there is also traffic at 8,000, opposite direction to the other aircraft on V222. That makes it difficult to separate the head-on traffic and it also means that you'd have to miss the 8,000 traffic if you wanted to descend the aircraft going north on V605 down to 7,000. Not to mention, 7,000 is below the MEA on V605 north of GENOD. So, it comes down to moving one of the aircraft up to 10,000.
We've already determined that the aircraft needs to be at 10,000 no later than 20 miles from the GENOD intersection. Pick a flight. Either flight. You should have picked the one going north on V605. V605 isn't nearly as busy as V222. GENOD is 31 miles north of SPA (Spartanburg) VOR on V605, and 31 - 20 = 11.
"Cessna one two three four five, cross one one miles north of Spartanburg at and maintain one zero thousand."
And that, boys and girls (who might want to become air traffic controllers), is how it is done. That is how generations of air traffic controllers have been trained to think. They've been trained to think that way because it is the basis of en route air traffic control. You can turn the radar back on and it makes things much easier to see, but it does not change the basics. You can use that radar to vector an aircraft behind another (instead of a reroute) but it does not change the fact that you are changing the time and space where two aircraft cross for the purpose of attaining separation. You can use radar to run the airplanes by each other closer (5 miles is the minimum in the Centers) because radar is more precise. But again, it does not change the basics.
You can change the route width (think protected airspace) with technology of greater precision (think GPS vs. VOR) from 4 miles either side of centerline to 2 miles, but it does not change the equation. The number you plug into the equation (2 miles instead of 4 miles) may change the answer but it does not change the equation used to define that protected airspace.
In a typically FAA schizophrenic fashion, the powers-that-be have once again started emphasizing these basics after unwisely dropping them several years ago. At the same time, they have implemented the URET (User Request Evaluation Tool) system, which makes it impossible for controllers to learn and retain these basics because it removed the controller's reference to time. In this picture of the main URET screen, notice that there isn't any reference to the time an aircraft will occupy a particular space (a fix):
URET is (of course) performing the same calculations that are -- and always will be -- the bedrock of air traffic control. It just doesn't provide the information needed for controllers to perform them.
Understanding these basics doesn't begin to describe how complex air traffic control is any more than thrust, drag, lift and weight explain the complexities of flying. Yet they are essential to it's operation. Ignoring them will only lead to frustration and failure. Scheduling more airplanes into an airport than it can handle only forces that air traffic system to use more space to buy some time at the airport. Putting airplanes into holding patterns uses space and it uses that extra space for a significant amount of time.
I hope you'll think about the basic principles of air traffic control the next time you have some spare time on your hands. Say, for instance, when you're on a 5-minute vector, or in a holding pattern or perhaps even when you're sitting in the passenger lounge waiting to board an airliner. They will help explain why you can't fly across CLT's final (or ATL's or LGA's, etc.) and why you can't fly through holding patterns. Well, at least most of the time.
Have a safe flight.
Want to read more from air traffic controller Don Brown? Check out the rest of his columns.