ATCC Controllers' Read Binder...

NOTAMS, FAQs and other info for users of ATCC

June, 1997

#1: Voice Upgrade

The voice upgrade and some program revisions are still under development and remain scheduled for the July release. Among the revisions will include moving weather, and a selectable vector length display in minutes or miles (instead of just 5-mile increments). There will also be more aircraft added, such as the new Citation 750's (typical cruise: mach .94) and Gulfstream V (mach .88). Various glitches will also be fixed, including a sometimes-erratic supervisor (or is that a real-life feature?):

#2: Strange Supervisor Behavior in "CERT" mode

Some users have reported failing certification checks even though the sector was run flawlessly; others seem to have passed cert checks with a minimum of effort (like after 5 minutes)...

ATCC is set up so that you shouldn't have a deal, then turn around 10 seconds later and expect to be re-certified in a CERT check. Even if you do everything properly, you probably won't be certified, because the supervisor just watched you have a deal moments earlier. You should either train for at least one session, or just exit and restart the program to "reset" the supervisor's memory.

Likewise, it is possible to pass a cert check with almost no effort or time... if you performed extremely well at one of your certified sectors, then go to take a cert check at another sector, your supervisor may be in a good enough mood to just sign you off, having watched you at the other sector. It probably shouldn't be that easy, and we may modify it in the next upgrade, but it can happen in real-life too.

#3: Holding

We do plan to implement a holding command for a future release, if not the next upgrade. However, you shouldn't need to hold aircraft! The entire U.S. aviation system has evolved particularly to avoid holding... all of the procedures, static flow-control restrictions (like getting aircraft 20 miles in trail, or having to sequence them 10 miles in trail), route designs, sector designs, sector procedures, ground delays and everything else in ATC is supposed to avoid having aircraft spin aimlessly in the sky, burning up fuel and making passengers miss their connecting flights.

Though an individual controller has the ability to put an aircraft in hold, he will have to justify his actions to higher-ups, including the immediate supervisor, the Center's flow control supervisor, and National flow control (in Washington D.C.) when the airline's angry dispatchers call and demand to know what the reason is for the hold. If the aircraft is headed for one of the major airports, it probably has a landing slot determined by the national flow computer, and by putting that aircraft in hold, the controller messes up everybody else's slot for that airport. The computer may over-compensate, and aircraft on the ground 1,000 miles away could be delayed at the gate until the mess caused by the rogue controller clears up. Maybe it's not quite that bad, but a single controller can cause long-lasting problems by doing too much holding.

The bottom line is, you are not supposed to put aircraft into hold on your own. A legitimate reason would be if flow control called you at the sector and said to start holding any ORD-bound aircraft, or if the next Center lost their radar, or a line of storms has shut off a major routing, and flow control needs some time to create re-routes. Or, maybe the airport had to close momentarily for some problem, so you might hold aircraft headed for there.

But what if you are overwhelmed, and can't handle any more aircraft? You'll just have to figure out some way to deal with it. Putting aircraft into hold because you can't handle them, in real-life, is considered an admission to everyone around you that you are "weak." There are usually 10 other hot-shot controllers (always younger), who will gladly step in and work your traffic for you, if you can't! So as a matter of pride, just work the traffic, gripe out loud about other facilities causing your mess, and chew on another antacid tablet.

#4: Strips

Controllers do not really need flight strips, but they do need to know the information about an aircraft, such as type and route of flight at an easy glance. The existing radar software is not advanced enough to overlay that information on the scope, however, so it is printed out on old, slow (circa early-1980's) dot-matrix printers. Usually too many strips are printed for each aircraft, so maybe only half are actually relevant, and the rest go straight into a wastebasket next to the printer. And somebody has to tear the strips along the perforations, and replace the paper when it runs out, so additional controllers are hired full-time just to tend to the printer (at $80,000 to 100,000 per year salary!) Flight strips are really an unneeded waste of resources, but it has always been that way, so that is how it is and how it shall remain in real life. It is tough to justify changing procedures in a system that works, no matter how cumbersome.

There is no need to waste such resources with ATCC, though, so the strips are only overlayed on the screen. Still, some have requested the ability to print them out. It would be as awkward as the real-life method (they would print out constantly as new aircraft come into the sector), and you would probably need somebody else to cut them and gather them as they print out, or you would have to unrealistically leave your position to get them from the printer yourself. Thus, we are inclined to leave the strip display as-is, but if enough people would like strips to be printed, we could implement it for a future upgrade. Email to support@xavius.com if you feel strongly one way or the other.

#5: Weather Everywhere

When you are first looking at an empty sector, you may just see scattered, "minor" storm areas. Remember, though, that the actual weather out there is much bigger (maybe around 4 times bigger) than what shows up on your scope, so what looks like a little blotch of rain may actually be a huge buildup choking off the main routing through your sector.

Once you have determined where the bulk of the deviations are occurring, also remember that you can re-route aircraft around the weather as soon as they come over to your frequency, to avoid having every aircraft clog your frequency with deviation requests. If you had a storm buildup in the BRIBE area of sector 75, for example, you might re-route the ORD arrivals DBQ direct JVL (..DBQ..JVL), or even COTON direct JVL (..COTON..JVL) to bypass the mess. Or, you might try sending them direct OBK, and sector 74 should be able to figure it out and should still take the handoffs. If not, put them over JVL.

For another example, maybe in sector 97 you have a fat storm sitting over ETX and ABE, and some of your PHL arrivals want to go right, some want to go left, some go right through it, and it is a huge mess. You might re-route all arrivals ..ELIOT..MAZIE (or shortcut, ..EL..MA), or even ..DUMMR..MAZIE when they first check on, which will keep the frequency less congested as they go around the weather automatically. However, expect to have new conflicts where you never had them before (like PHL departures clashing with PHL arrivals). It can make things much more interesting, sometimes.

In real-life, re-routes such as that would probably be coordinated with your supervisor first, to make sure they wouldn't affect other, adjacent sectors. Re-routing PHL arrivals over ELIOT then MAZIE would probably be frowned upon, because ELIOT and PARKE are major departure fixes coming out of the NY metro area (and going just above sector 97). But, if there is no other choice, do what you have to do, and have the other sectors re-adjust.

#6: Conflict Alert

The flashing of the datablocks that occurs in ATCC when you have a deal also occurs with the real-life equipment. But the real-life system also has "Conflict Alert" that will start the datablocks blinking before the deal occurs (maybe 1 to 2 minutes prior), to alert you to a pending situation. The computer attempts to project conflicts between all aircraft under Center control, so if it thinks any aircraft (whether VFR or IFR) will get within 5 miles/1000 feet, it'll start them blinking.

The problem with the real-life system is that there are so many aircraft in the sky, and only 1 central computer, that it gets overwhelmed and is all but useless in the low-altitude sectors (below 24,000 feet). Aircraft climbing out of 10,000 feet will blink with aircraft on the ground (!), aircraft will start blinking after they have passed each other, and aircraft will blink that are 20 miles apart, different directions, while two head-on at the same altitude don't blink. Thus, controllers routinely supress the conflicts without even looking at them, because there are so many false alerts. L.A. Sector 4, for example, might have every single aircraft blinking, and the controller has to go through and make a computer entry to turn off each one to stop the annoying flashing.

In high altitude, however (above 24,000 feet), there aren't the numerous V and I targets, and conflict alert is more accurate, which can save you if you make a mistake. But, it can't be relied upon to catch all errors, so you have to control as if it weren't there (like in ATCC). We may put in a form of conflict alert for a future upgrade, but you could expect just as many false alerts, because computers just don't know what's going on, which is why human controllers still have the job!

#7: Real-Life Typing, Typing, Typing

When you re-route an aircraft, or just give them direct to somewhere, you are required to modify their routing in the computer. In ATCC, this is done automatically, to compensate for the typing you have to do to issue the route. In real-life sector 82, if you issue "cleared direct Carleton" to an aircraft, you would then press the RTE key (F7), CRL, space, computer ID number and ENTER. This would modify the computer-stored routing to show it was now direct CRL.

However, for reasons unknown, the ATC computer usually spits out a "REJECT-- CRL CANNOT MERGE" error message. Or, it says "REJECT-- ROUTE ..CRL.DTW NOT STORED." Then you have to do what is known as a "6-7-10 amendment," a very user-unfriendly process where you have to directly modify the computer database entry for field number 6 (position), field number 7 (time estimate), and field number 10 (route). The entry would look like: <AM key>234 6 GIJ280020 7 EXX00 10 DRCT..CRL and <Enter>. If you are lucky, you'll get an "accept" message, but you may still get a "REJECT-- CRL CANNOT MERGE", in which case you have to retype the whole thing, with DRCT..CRL..DTW at the end. Woe to you if the VOR isn't in the database, then you get a "CRL NOT STORED" message, and you have to look up the latitude and longitude coordinates (or ask the pilot), type those in, and make a "field 11 amendment" (remark section) noting that "L/L ARE CRL."

So yes, ATCC has a lot of typing involved, but there is often even more in the real-world!

#8: Coast Track (CST)

If the system looses its radar feed (but the computer and display circuits are still working properly), you get the "NOT RECEIVING RADAR" message. Datablocks continue to move based on where the computer thinks the aircraft should be, but if there are no radar hits after about 3 cycles, the datablock will stop moving, and "CST" appears over the speed value. This means the datablock is "in coast" and not attached to a radar target. When an aircraft's datablock goes into "coast," you are required to tell them "radar contact lost," so they know not to expect radar traffic advisories.

A datablock would also go into coast if the aircraft suddenly crashed, so seeing "CST" in the datablock of an aircraft well away from the airport should cause an immediate lump in the controller's throat. Essentially always, though, it is due to a faulty transponder in the aircraft, and asking the pilot to "recycle your transponder" (turn it off and back on) brings the radar target back. Though the author hasn't heard the tapes, that was probably the first thing the Boston sector 32 controller told TWA800 when the datablock went into CST-- "TWA800, recycle your transponder."

#9: SCAN, SCAN, SCAN!

Things get hectic, weather is all over the place, aircraft are all over the place, and more keep coming. Even the most experienced controller has to always remember: scan, scan, scan! Go over every aircraft in the sector, no more than a few seconds at each, make sure they're OK, the handoff is being made (or it's been taken and you can switch them over), and maybe climb or descend them to the next guaranteed safe altitude--- then move on to the next one! You don't have time to fixate on one aircraft, trying to figure out if another aircraft at the other side of the sector may or may not be traffic. If there is a chance they're traffic for each other, fix it now and move on! Turn the guy 20 degrees right, and move on in your scan. Or let him level off his climb... you don't have time to analyze climb rates and points of intersection! Keep things moving, and always SCAN, SCAN, SCAN!

#10: ORD Approach Sector

Revision #2 (with multiple runways) was posted earlier, and the section of last month's newsletter describing the sector has been revised to correctly describe the new version. We're busy with the new voice upgrade and new Center sectors, so the ORD sector remains a test version for now, but hopefully we'll elaborate on it in the future. Similar Center ATC principles apply with to the ORD sector, so never forget to keep your scan moving, and you'll find it's actually pretty easy! Easier than sector 66 any day...

END

The Read Binder is updated at the beginning of the month. All information is for use with Xavius Software's Air Traffic Control Center^TM only, is the opinion of the author(s), and does not necessarily reflect the policies or practices of the U.S. Federal Aviation Administration or Federal Aviation Service. Send your questions or comments to support@xavius.com and we'll be glad to help!