Say Again? #68: ATC Programming

I was reading a description of a pilot's actions as he was programming his GPS the other day. It didn't take me long to get lost. Press this button, go to that page, turn this dial. Pretty soon I found myself wondering, "Who's flying the airplane during all this?" It sure seemed complicated.I'm sure it doesn't seem as complicated with a little training. After all, flying is a complicated affair and that is what training is all about -- learning to do complicated things in a orderly fashion. I couldn't help but wonder about all the human factors behind the issue, though. No matter how sophisticated it all gets, it's a human being that takes the actions and makes the decisions.One thought led to another (as it always does) and I thought the mechanics of my job might be interesting to my readers. Using computers in ATC is old hat. But it seems like we're always changing hats. New equipment comes along -- or at least new features. As you work your way through this article, there are a couple of themes I'd like you to keep in mind. We need to find a balance between new features and familiarity. Likewise, we need to find a balance between desirable advancements and commonality. I believe this is just as true in the cockpit as it is in the radar room.And just a reminder, I work in a Center -- an ARTCC. Approach Controls and Towers work with different equipment.

There's no good place to start, so I'll just start with putting a flight plan into the computer. The vast majority of flight plans are already in the computer before an airplane ever talks to a Center controller. Virtually all the airline flight plans are "canned" -- that is, the same flights fly on a regular schedule so that the flight plans are kept on file and automatically entered into the computer daily. Most of the rest are entered by FSS or via DUATS. But occasionally Center controllers have to enter a flight plan from scratch.We'll start with the FP or "Flight Plan" message:

"FP" is one of the Quick Action Keys (QAK, pronounced "quack keys") available to the D-side (the controller who handles Data.) It's exactly like the function keys at the top of your computer keyboard. We press "FP" and it tells the computer we want to enter a flight plan. Then we type in the callsign, the type aircraft and navigational equipment suffix (/A), the true airspeed, the point at which the flight will start (in this case, HKY -- Hickory, N.C.), the proposed time of departure (P1200), the requested altitude (060 is 6,000) and finally the route of flight. You might notice that we don't type in the transponder beacon code. We could but the computer will automatically assign one if the navigational equipment suffix indicates the aircraft has a transponder.As you might guess, the formatting of this message has to be exact. If we don't get it right, the computer will reject the message. Another interesting tidbit is that this is the same message we use to put a VFR flight plan into the computer. In other words, if an aircraft calls for VFR advisories (a.k.a., VFR flight following), we need to get a flight plan into the computer on that aircraft. It would look like this.

Again we have the callsign, the type aircraft and equipment, the true airspeed, the place at which the flight plan starts, the estimated time over the fix (E1205) the altitude (VFR at 6,500) and the route of flight. We don't know where the aircraft departed (and don't care); so, long ago, Atlanta Center controllers took to starting the route of flight field with "AVFR" to indicated that the departure point was unknown because the aircraft was VFR. Yes, Virginia, even in the restrictive structure of computer syntax, people get creative.

Back when I started as a controller, we couldn't enter this message from the R-side -- the position/keyboard in front of the radar scope. The D-side had to enter it or, if the R-side was alone, the R-side would have to slide over to the D-side position and enter it. As you can imagine, this could be aggravating if not downright distracting, so we designed a better mousetrap.Yes, I'm being insincere when I use the word "better." We invented a computer patch called the VP patch -- as in, "VFR flight Plan" patch. I have to confess, I don't even know the syntax for it. It's something like:

As you can see, it just beats the heck out of:

Well, if all you're worried about is easy, it does beat the heck out of the complicated one. I was excited about it when it came out, too. My section of Atlanta Center works as many (if not more) VFRs than anybody else. Anything that would make the job easier would be welcome. However, the VP patch quickly wore out its welcome with me.As you'll notice, the VP patch doesn't require an altitude. It processes the flight at a VFR altitude of 10,500. This, in effect, processes the flight plan to everybody along the route of flight. Even if the airplane isn't going to enter everybody's airspace. In addition, you'll notice there isn't an airspeed entered. I know you're thinking that the FAA's computer recognizes a PA28 and knows that it will have a true airspeed in the vicinity of 120 knots ... but it doesn't. The speed is actually derived from the radar track data. I could go into the details, but suffice it to say, the speed in the flight plan isn't likely to be correct anymore than the altitude. Speaking of which, even if the aircraft is at 10,500, the flight plan just shows VFR, as opposed to VFR/105.The workaround is to go back and fix the altitude and the speed. You do that with the amendment message -- "AM." To do this, you need to know the Computer IDentification number (CID). The CID is three alphanumerics. It was always three numbers until we started running out of numbers (at 999.) We can now go into the alphabet. If you get a CID of 67E, you know it's going to be a long day.Where were we? Oh yeah, fixing (amending) the altitude. The CID for N23456 is 987. You type:

Amendment Message 987 (the CID), ALT (altitude) VFR/065 (the actual altitude of the aircraft -- VFR at 6,500), and press "Enter." Actually, there's another way to fix it. We'll get to that later.To fix the speed you'd type:

Amendment Message for CID 987, Speed 120 kts.

As soon as you do all this, every sector along that aircraft's route of flight gets two "dings." Literally, a bell rings at the sector to advise the controller of an incoming computer message. The first message would be to advise that N23456's altitude was now VFR/065 and the second message would be to advise that N23456's true airspeed has been revised to 120 knots. That would probably have a time update included with it. The new speed will affect the ETA at AVL (and every other fix/estimate along the aircraft's route of flight.)That is a lot of junk to absorb so far, so let's review. This message ...

... versus these messages ...

... along with two "dings."Assuming you took the time to figure all this out, you'd see that the "old-fashioned way" -- the FP message -- isn't really any slower than the VP message. You also wouldn't be bothering a bunch of other sectors down the line with erroneous information that needs to be corrected. With the FP message, the correct data is entered to start with. But this is the real world and this is what really happens. Many controllers just type in the VP message and never get around to correcting the speed and altitude with the amendment messages. That has all kinds of unintended consequences, but I'll spare you from reading them. All but one:Remember I said earlier that Center controllers don't enter that many flight plans to start with? The majority that we enter are VFR flight plans, since the IFRs come into the system in other ways, like FSS and DUATS. If you don't enter those with the FP message, it isn't long before you forget how to use the FP message. And when you need to enter an IFR flight plan, it can get painfully slow trying to remember how to do it when the computer keeps giving you error message after error message. I bet you wouldn't be surprised to see a frustrated controller use the VP patch to put in an IFR flight plan, would you?

I want to bring this back to how you, the pilots, think about technology in the cockpit and in ATC. I know it's expedient for everyone to talk about how far behind the FAA is in technology. In too many cases, it's true. But when I used to climb into a cockpit on a regular basis (in my pre-FAA days) there weren't many computers to be found. When I first walked in the door at Atlanta Center, it was "golly-gee-whiz" time. I don't want you to think about the capability of the computers. I want you to think about how you interact with them. Controllers may not have the latest-greatest computers, but we've been interacting with them a long time.Most of you have GPS these days. Are you sticking to the book or has your buddy taught you a couple of "cheats" that are easier to remember and use? If you're safety-minded, you know you need to keep your head.The VP patch isn't even a cheat for controllers. It's an officially approved procedure. Yet it has had all sorts of unintended consequences. And it isn't an approved procedure for entering an IFR flight plan. Do you understand that what might be acceptable for a VFR GPS isn't necessarily acceptable for an IFR-certified GPS? Are you looking for those unintended consequences when you're using your GPS? Think about that as we move along.

The most common computer message Center controllers use is the one to move a data block. This is done by selecting the number from the numeric keypad that corresponds to the position you'd like the data block in and typing in the CID. For example: if you want to move the data block of N23456 to the north position you'd type in 2 (the northernmost number on the keypad) and 987:

You'll notice we didn't have to press a Quick Action Key (QAK) to enter the message. It's so common the computer is programmed to recognize the message by syntax alone. Let's say the CID is covered up by some other data and you can't see it. You could use the call sign to identify the flight:

You can also use the trackball to identify the flight. Just press 2, scroll over the position symbol of N23456 on the radar screen and press ENTER. It works just like the mouse on your computer. We called it a slew ball in the old days but now they usually call it a trackball.Most of the computer entries we make are similar in that there is more than one way to enter them. Some controllers favor the keyboard and others favor the trackball.You might think we'd automate the process of moving the data blocks where they'd stay clear of each other. I understand it was tried and rejected. There is nothing more annoying than reading a critical piece of information and having it move on you while you're reading it. Trust me. We know that now because the URET system does just that. We'll talk more about it later.Repositioning data blocks is absolutely mindless for controllers. The syntax is logical and straightforward. We do it hundreds (if not thousands) of times a day. We can do it in our sleep. Again, I want you to put your thinking cap on. Whenever someone mentions putting a new piece of data on our computer screens -- our radar scopes -- the first thing that enters my mind is, "Is the new data worth the effort of moving even more data blocks?" Moving data blocks may be simple and mindless but it does eat up time.

As I alluded to, we have a new system in the control room called URET -- the User Request Evaluation Tool. The only reason I mention it here is that it has radically changed the way we work. In trying to decide which are the more common entries controller make on the computer, URET has thrown a kink in my works. For instance, I didn't use the FR key much before URET but now I use it every time I talk to an airplane. That's a lot of times. FR stands for Flight Plan Readout.For instance, now that we have N23456 in the computer, if we type in "FR 987" we get this:

In the past (pre-URET), I'd just look at the Flight Progress Strip for that data. URET replaced strips so now you need to look at the URET screen for the info. I haven't found that easy to do (the data keeps jumping around -- automatically), so now I just get a flight plan readout instead.

Another function we use more often because of URET is the ROUTE key. The ROUTE key actually has two functions. You can use it to view the present routing or you can use it to change a routing. To view a graphical depiction of the route of flight on the radar screen, you simply punch the ROUTE key and type in the CID. This will draw a line on the radarscope showing you the route of flight for the next 20 minutes. If you'd like to see what the route looks like for 30 minutes (or up to 99 minutes), you'd type in 30 987 after depressing the ROUTE key.Let's say we wanted to change the route of flight for N23456. Here's the flight plan to refresh your memory. (Remember, the controller would press the FR key and type in 987.)

Let's "route" him over the SUG VOR and then to the AVL airport.

If you get a flight plan readout (FR message) on him now it, will look like this:

The BZM245045 is the fix where the aircraft was when the ROUTE amendment was entered. By the way, for you sharp-eyed people, 6457 is the transponder beacon code. The computer would now print a new strip showing the new route of flight (over SUG) for those that use strips. URET would just change it automatically on the URET screen and you'd probably never notice it.

I told you'd I show you the other way to change the altitude of an aircraft. Again, press FR 987 to get a flight plan readout on N23456 so we can see what we're doing.

See the altitude, VFR/065? If we wanted to change the altitude a different way, we'd type in 060 987 and press ENTER. Voila! We just changed N23456 from VFR advisories to an IFR flight plan with an assigned altitude of 6,000. Get a flight plan readout and it will now show:

There's that pesky "AVFR" in the flight plan, though. That might prove to be confusing to someone down the road. But I'm out of time and we''ll have to deal with that some other day.

Just as a closing thought, I want you to think about familiarity. I was at the Communicating for Safety conference recently and one of the presenters mentioned their quest to bring new technology to market as quickly as possible. As you all know, in today's world that can be pretty quick. I think it would be well worth our time to consider if this is a desirable course of action. Or not.If your GPS is version 1.0, do you want to move up to version 2.0? The obvious answer is "Yes." But is that the "safe" answer? Obviously we hunger for the new capabilities. But at what cost? I can tell you from first-hand experience that it's a horrible feeling to be as busy as a beaver and not be able to recall the new coding for a message that you used to know like the back of your hand. When you think about the differences in programming between your GPS, NEXRAD display and your electronic flight bag (EFB), do you really want to upgrade to version 2.5.1 for the GPS, 3.6.7 for the NEXRAD display and 2.4.3 for the EFB at the same time and then go fly an ILS down to minimums?Have a safe flight.