While pilots and air traffic controllers work with each other daily, perhaps we don’t often think about the nitty-gritty details and problem-solving taking place on the other side. When everything appears to be running smoothly, there’s nothing to worry about, right?
If I’m your controller for the moment and tell you, “Proceed direct [FIX],” it’s unnecessary for me to know every keystroke you’re inputting in your navigation system to make that happen. Even if you accidentally mistype the entries a dozen times while spilling your coffee, if you go direct [FIX] in reasonable time, I’m none the wiser.
Likewise, on our ATC side, sometimes what appears automatic or uneventful to the pilot isn’t truly so. This is especially true with flight plans, where we must stay on top of things, or end up rushing to make things right. What kind of situations does ATC handle beyond earshot of the pilots?
Zombie Flight Plan
Rule one of managing an aircraft’s flight plan is simple: make sure there’s a flight plan to manage. A flight plan’s strip typically prints out in a tower or approach control half an hour before the flight’s filed proposed departure time. Two hours after that P-time, if that flight hasn’t departed, the flight plan is automatically dropped from the system.
To stay ahead of that, in the control tower, I and many other controllers sort our flight plan strips by proposed departure time. If we see an aircraft has already received its clearance, and notice it’s approaching that two-hour drop mark, we may bump the proposed time back to give them extra time. While good technique, it is workload-permitting and not a requirement. On the pilot’s end, if you realize you’re going to be delayed, call Clearance Delivery and ask them to extend your time. A little foresight can spare everyone the hassle of a refile.
Unfortunately … occasionally … oversights happen, when a tower controller (Author points finger to self as a prior offender.) doesn’t realize that a flight has already timed out, and he clears the aircraft for takeoff. One of the crappiest things you can experience as a controller is when a flight departs and squawks the correct code, but doesn’t properly acquire on your radar. You know you’re in for a bit of drama.
One afternoon, I was working radar, and our tower launched an IFR King Air. Normally, our radar will “tag up” a flight’s target with its callsign, destination, and aircraft type. None of that appeared. All I could see was a basic target, with his squawk code and a flashing “WHO” beside it. (Yes, our radar will literally show “WHO” as in “Who is this guy?”)
Our rather embarrassed tower controller called a moment later, admitting the flight plan had timed out. Well, planes don’t just stop flying because their flight plan is deceased. I turned the King Air in the direction he needed to go, climbed him to 10,000 feet, and added a temporary callsign to his target so I wouldn’t lose track of him.
Meanwhile, I called our Flight Data controller over, who’s responsible for managing and distributing flight plans in the radar room. In between working my other traffic, I explained the situation. He grabbed the strip and ran over to our Flight Data Input Output system (FDIO), an archaic computer console with a monochrome screen. These unassuming little machines allow ATC towers and radar facilities to create and amend flight plans. (Center controllers can do everything at their scope.)
Clacking away furiously, he typed in an all-new IFR flight plan: Callsign, aircraft type, equipment suffix, requested altitude, and full routing off the old strip.
As the King Air soared through 7000 feet, Flight Data handed me a shiny new flight progress strip. It was as if the old flight plan had been raised from the dead. No new clearance needed, except for a new automatically generated squawk. I told the King Air, “I have a new squawk for you. Squawk [new code].”
A moment later, the King Air’s data block blossomed with all the correct target information. I immediately initiated a handoff to the Center. They took it and I switched him to Center to continue his climb. He never even had to level off. Our off-frequency scrambling hadn’t impacted the pilot, which is how it should be, ideally.
There Can Be Only One
A lack of a flight plan is obviously a problem. Too many of them is also not good. “Wait,” you may be thinking, “can’t I file multiple flight plans?” Absolutely. The problem comes when there are too many active ones. Let’s discuss what that means.
Imagine you’re flying N123AB around sunny South Florida, building your cross-country time and shooting some practice approaches. You file an IFR flight plan from Fort Lauderdale Executive Airport (FXE) to Palm Beach International (PBI), another from PBI to Tampa International (TPA), and a third flight plan from TPA back to FXE.
While you’re sitting on the ground, those flight plans are inactive. FXE Tower issues your clearance to PBI. Soon afterwards, you’re wheels up. Miami Approach’s radar detects your transponder code and matches it to the one on your FXE-PBI flight plan. As your callsign appears on your radar target, your first IFR flight plan is automatically activated and your flight info sent downstream to the next ATC facility on your route, Palm Beach Approach.
After a handoff, you ask Palm Beach Approach for a practice ILS, followed by your clearance to TPA. The PBI radar controller should, at that point, ask his Flight Data controller for two things. First, locate your outbound PBI-TPA flight plan, so it’s handy when needed. Second? Delete your inbound flight plan from FXE.
Wait, aren’t you still on that flight plan? Does that cancel your IFR clearance? No. ATC systems work on two levels: the national and the local. When you file an IFR flight plan, it goes into the National Airspace System. The NAS is what enabled your FXE-PBI data to transfer from Miami Approach to Palm Beach Approach.
However, you’re already in PBI’s airspace. They’ve already got everything they need. Also, that flight plan terminates in their airspace, and therefore doesn’t need to be sent anywhere else. If they remove it from the NAS, your target won’t change at all on their scope, since PBI’s local radar computer already knows who you are.
So, why delete it at all? In the NAS, each callsign can only have one active flight plan. This ensures that only the current, correct data gets passed from facility to facility.
Imagine if the PBI controller left the FXE-PBI leg in the system. After your approach, the PBI controller issues you the PBI-TPA clearance and new squawk. Despite differing squawks, the computer realizes your callsign already has an active flight plan. It throws an error, preventing the PBI-TPA flight plan from activating or being handed off to the next facility.
To prevent this from happening, the PBI controller deletes your FXE-PBI flight plan before issuing the PBI-TPA clearance. (Note: If he forgets and gets the error, he can still have Flight Data delete the first plan and manually activate the next flight plan.) Later, when you arrive in TPA’s airspace and request a practice approach there too, their controller will then delete your inbound PBI-TPA flight plan. That’ll leave only the TPA-FXE leg remaining. This little bit of preemptive housekeeping keeps the transitions from flight plan to flight plan running smoothly.
Helping Handoffs
In the cockpit, pilots often rely on the autopilot and other technology to ease workload, whether it’s flying a programmed route or maintaining an altitude and heading. Technology takes an ever-increasing load off controllers too. It’s been cool watching subtle advancements over the years.
One example: handoff functions. At my first approach radar facility, we had to manually initiate every handoff to a receiving center sector. For every airplane, I had to type “C” plus the number of the center sector and click on the target. Example: “C23” and click. It doesn’t sound like much, does it?
However, picture this: I’m inundated with aircraft, I’m trying to stay afloat, and annoyed that Center still hasn’t climbed this one airliner out of my airspace, so I can finally stop watching him. The plane’s been level for ten miles. Then I realize: Crap. I never initiated the handoff. Center has no idea he was coming. Type. Click. Wait longer until they finally accept it, then finally switch the plane, and wait again until he climbs out of my airspace.
Now, approach controls have a feature where IFR aircraft automatically hand off. If the aircraft’s filed altitude is above our airspace limit, it’ll initiate the handoff to Center once the aircraft climbs through a specified altitude. Other IFR aircraft that are remaining within our altitudes will automatically start handing off once the system calculates they’re a certain amount of time from the boundary.
Many times, we never need to click on or manipulate the aircraft’s target at all. This allows us to focus on separating and sequencing aircraft, rather than extraneous keyboard entries. It helps ensure your smooth transition from facility to facility. In the case of jets climbing quickly, they rarely need to level off within our airspace, since the handoffs are completed so early.
Doin’ It Old School
Inevitably, no matter how cool the toys are, they break. If your autopilot fails, it’s time to hand-fly. In ATC, we need to verbally coordinate or figure out a workaround. Sometimes we do both.
One afternoon, I was working Flight Data in our radar room. Our busy North radar controller got a call from an adjacent Center sector. “Manual IFR handoff.” That’s never good. It means the automation for a flight has failed, and all the info needs to be passed verbally.
North answered the line. Center gave him the details. “November 123AB. Beechcraft Baron. Five miles north of [FIX1] at 8000.” North looked at the location and saw a blank target at 8000. “He’s going to [destination] via [FIX2] [FIX3] [FIX4].”
North replied, “Radar contact,” indicating he was accepting responsibility for the aircraft. He quickly typed in N123AB’s callsign, type, and destination on its target. A moment later, the Baron checked in on his frequency. The Baron was heading to an airport in the facility next door. Soon, North was going to have to manually hand off the Baron to them too, making more workload for himself and the next facility’s receiving controller.
Overhearing the exchange, I got on our FDIO console and searched for the callsign. It showed two flight plans in the system, one active, one not. Guess what? The plane was on the squawk for the inactive one. Remember earlier, the errors that can happen when an active flight isn’t removed before a new clearance is issued? Yeah, that’s what happened here.
The active FP had been filed through two other facilities, nowhere near ours. While I could see it, I couldn’t readily manipulate it. All wasn’t lost, though. Using a trick I’ve learned over the years, I “stole” control of that old FP and deleted it. One down.
Next, I saw the inactive plan was from an airport a hundred miles away. I didn’t initially have control over that one either. Playing burglar again, I stole that one, too. I amended its departure to a fix within our airspace and amended the route to just the last few relevant fixes. Then I activated the flight plan.
I ran over to the North scope. He was busy. Quickly, using the spare radar keyboard, I cleared off the temporary data he’d applied to the Baron. A moment later, the newly active flight plan’s info popped up on it. I initiated the automated handoff to the next facility, and we were all set to go. No landline call required.
The Baron driver was unaware that these kinds of complications were going on behind the scenes. What appears seamless may not always be so, but if the pilot doesn’t notice the backstage drama, then ATC is still getting the job done.
Tarrance Kramer prefers functioning automation and trouble-free flight plans while working traffic in the Midwest.
