Last December, I shot my first ILS approach. My father and I were out in the practice area doing some air work west of Miami. He’s a CFII and offered to walk me through a practice approach back into Tamiami airport.
It was an eye opener. I only have a Private Pilot’s certificate, but as an air traffic controller, I’ve been clearing pilots for ILS approaches for years. Actually doing it? Uh, not so easy.
It was a cool, beautiful VFR morning, yet by the time we landed, I was sweating through my shirt. As a controller, I now appreciate the mental effort required of the pilot when I say “cleared ILS approach” or “keep your speed up” when they’re already established. It’s good to see the other side.
When I’m working air traffic, fielding requests from pilots, I sometimes wish those same pilots could get a look at how things work on our end. There can be some significant timing and teamwork involved in addressing what appears to be—from the outside looking in—a simple request.
Choosing Your Battles
One of the first lessons new controllers learn is the value of time. While handling multiple aircraft and other duties, controllers have to gauge which requests need to be tackled first. There’s actually a checkbox labeled “Control Judgment: Priority of duties is understood” on every ATC training report. If a trainee can’t grasp that concept, they probably won’t get certified.
Imagine I’ve got four aircraft. One is a Cirrus cruising on an airway about 20 miles from my airspace. The other three are on various vectors to my main airport’s ILS final, spaced five miles in trail of each other. I was about to clear the first for the approach, since he’s only a couple miles from the localizer.
The Cirrus suddenly requests a reroute around some weather down the aerial road. Now I’ve got to ask myself: should I issue the reroute before clearing the first ILS guy? That question spawns a number of “what if” scenarios in my head. What if my transmission and the pilot’s readback take too long? What if ILS #1 blows through the final? What if I then need to adjust ILS #2 and #3 behind him? How much more work would there be for everyone involved if I don’t time this right?
After a controller acquires some experience, these types of decisions take little thought. The answer is often obvious. The Cirrus has twenty flying miles—in other words, about eight minutes—before he hits my boundary. ILS #1 needs an approach clearance, well, now. No brainer. I clear ILS #1 for the approach, issue the Cirrus’s new routing clearance, then clear ILS #2 and #3 for their approaches.
Reroute a Flight Plan
So I’ve issued a verbal reroute to the Cirrus. It’s recorded “on tape” for posterity and all, but the computer doesn’t know it yet. I must amend his flight plan in the system, so the new routing gets to his upcoming ATC facilities.
The mechanics of amending a flight plan vary depending on the type of facility handling the request. Centers and terminals (towers and/or TRACONs—Terminal Radar Approach Control) each do business differently.
Centers are essentially powerful computers with radar displays. That computer processes all flight plans for all airports within each facility’s thousands of cubic miles of airspace. It then shares that information with neighboring centers and underlying towers and TRACONs as necessitated by the route and altitude of each flight. Thanks to their direct connection, center controllers can amend flight plans via a keyboard located at their radar display.
Until the past decade, every ATC facility relied on paper flight progress strips to view and manage flight plans. During the mid-2000s, the ARTCCs (centers) switched to an electronic system called URET (User Request Evaluation Tool) that displays flight plans electronically on “request” by the “user”—the controller. This “tool” (Save the jokes. We’ve used them all.) then “evaluates” each aircraft’s route and altitude to verify it doesn’t interfere with other traffic. If a potential conflict is detected, it’ll warn the controller.
Controllers in the terminal world—like me—don’t have that capability at our fingertips. We still rely on paper flight progress strips. Our radar displays are intended for short-range approach and departure vectoring within 30-50 miles of a major airport, not for long-distance en-route flight management. Our flight plan data is slaved to, processed by, and transmitted from whichever center happens to sit over our airspace.
While certain terminal facilities can generate new National Airspace System flight plans from their radar displays, they’re not easily amended once they’re input. For the majority of changes, we use a Flight Data Input/Output (FDIO—pronounced “Fido”) computer console specifically designed to interface with our parent center’s computer, which could be hundreds of miles away. Unfortunately, there are few FDIO terminals in a terminal facility, and they’re not usually next to the radar controllers.
To handle flight-plan amendments on the FDIO console, ATC terminal radar facilities and larger control towers may staff a dedicated flight data controller position. With their minds off the busywork, the controllers on frequency can keep their focus on separating and sequencing airplanes in their congested airspace. In smaller control towers, with less traffic volume, controllers may work Flight Data, Clearance Delivery, and Ground all combined at once.
Remember, I’ve already given the Cirrus his amended clearance. I note that he’s begun his turn to the new next fix. Time to get that new route into the system.
“Data,” I shout, “I need an amendment.” The data guy appears over my shoulder.
I could start by telling him the call sign, but an aircraft could potentially have multiple flight plans in the system, filed off different airports at different times. To identify the active flight plan, I use the Computer ID (CID) printed on its strip. This is a unique identifier for this flight for this aircraft on this day.
The Cirrus’ CID is 624. “Six-seven-ten CID 624,” I tell Data and just give him the amendment to the flight plan. He steps over to the FDIO console on the opposite side of the room. I go back to vectoring my ILS arrivals and clearing them for their approaches.
That hopefully all makes sense except the “six-seven ten.” That’s controller shorthand. Every flight plan in the National Airspace System database has multiple data fields, each containing a specific piece of information. Field two is the call sign. Field three is the aircraft type. Nine is the requested altitude.
What I needed changed for this amendment were—you guessed it—fields six, seven, and 10. Six is the fix closest to the aircraft’s current location. Field Seven is the Zulu time the aircraft was expected to depart that fix. Since the aircraft is departing that fix this very second, Data will use “EXX00,” the FDIO syntax for “now.” Field 10 is the new routing.
Flight Data types that into the computer, using a very specific syntax. He leads off with “AM” (telling the system this is an amendment to an existing flight plan) followed with the CID (624), then the field number and the new contents, repeating until all the necessary fields have been updated. Once it’s processed, the printer spits out the amended strip. Every facility between ours and his destination also gets updated information, either electronically or on a strip.
At first glance, it may seem a bit alien and clunky, but it’s not difficult. Long story short: This entry is basically a reset of the aircraft’s flight plan. It gives him a new departure point, departure time, and a new route to his destination. To the computer, it’s like he just took off from his current fix.
All that typing can get a little crazy when everybody’s requesting reroutes. When a NAVAID goes down or weather’s clogging up the works, Flight Data will get pulled every which way by other controllers yelling for amendments. Like any other controller, Data needs to prioritize. For example, a reroute for an IFR US Air Force F-15 clocking 500 knots, 10 miles from someone’s boundary, would demand greater priority than updating a VFR Cessna’s destination 50 miles away.
During those busy periods, all controllers in the room—radar, handoffs, flight data—need to manage their time wisely. If ATC is taking a while to handle your request, it doesn’t mean it’s any less important to the controller. Sometimes the controller just has to make the call between you and another aircraft whose needs are more time-critical. If he isn’t, he’s not doing his job properly.
Tarrance Kramer is just one gear in the big team machine, making tough calls every day while working air traffic in the wild southern U.S.