ATCC Controllers' Read Binder...
NOTAMS, FAQs and other info for users of ATCC
#1: New Sectors and Features
A list of more ZLA, ZAU and ZNY sectors has been finalized as the next official ATCC sectors. There is no specific release date, but they are "on the way" according to a handwritten note on the (locked) door of the Xavius R&D department. Some new program features are also in the works, though the fundamental radar display and functionality are and shall remain identical to the real-life system. Suggestions for things like color radar and pop-up menus would be easy enough to implement, but U.S. controllers just don't have such luxuries, so they won't appear in ATCC (at least not when working the real sectors--training or demo modes, possibly). Likely the new additions will be things like holding, refused handoffs, starting out with the sector full of traffic, and unusual situations (such as needing to return to the airport), among others.
#2: Wing and a Prayer TV Movie
This original made-for-TV movie first aired last month on the USA Network (a lower-budget cable TV channel), and will be shown again on May 2nd. It is about an airliner that is hit by lightning, which disables its transponder and radios. A simultaneous radar outage at the Center means nobody knows where the aircraft is or where it is going! Disaster is averted by the hero controller, whose husband happens to be on the flight.
Though the technical bits (i.e. most of it) are largely inaccurate, the radar consoles are unusually realistic...only because they borrowed (or stole) them from the set of the Xavius-assisted movie Blackout Effect! Keen viewers will also note ATCC sectors 66 and 97 filling the background radar screens (though not the closeups).
Interestingly, it is "neither confirmed nor denied" that the Xavius-assisted film Ground Control, about a controller who has an incident while working sector 75 (then must struggle to redeem himself), may have itself borrowed (or stole) the old consoles from the movie Apollo 13.
#3: Operational Deviations
Operational Deviation is FAA-speak for "letting one of your aircraft get into another sector without a handoff." It is considered about as serious as a deal, and the controller would likely be decertified as a result. The reason for the seriousness of a missed handoff is that you don't know for sure what is going on in the next sector--they could have a non-radar aircraft, or could have just turned someone toward that part of their sector, which you can't see, or any number of uncertainties. Even if nothing happens, and you quickly make the handoff after-the-fact, the FAA does not want any moments of uncertainty in the separation and safety of IFR aircraft, so they consider it a serious error.
In practice, though, controllers are always aware of any targets in their sector. A "left-leaner" (backslash, meaning an aircraft under Center's control) drifting into a controller's sector should stand out like a blinking red (or green) light, and should cause the controller to immediately click over the target to bring up the datablock. So, even if a controller "forgets" about an aircraft and lets it drift into another sector, at least that other controller (in practice) would be watching it and would steer his aircraft clear.
Still, it is an unneeded (and unwanted) surprise to suddenly notice an aircraft screaming through your sector at 500 knots, straight toward your congested knot of arrivals. If a controller is struggling to keep the flick (or has already lost it), something like that could put them over the edge. Thus, many controllers will react angrily if you let one of your aircraft enter their sector without a handoff, and you would be completely at their mercy whether they report you or not (it is usually their option).
Good controllers, however, who have the flick and include nearby radar targets as part of their scan, will notice it ahead of time and may call you politely on the interphone as it nears their boundary ("You probably meant to handoff that UAL255 to me, didn't you?"). But, the odds are you will get the angry controller and you will have to apologize, plead and beg not to get the black mark in your employee file. Though they will probably not turn you in, because everyone knows it could happen to them too. But, they will love to give you a hard time about it and make you sweat.
In any case, do not "forget" the handoffs! You can get away with it in ATCC, but probably not in any future versions. Making handoffs should be the second priority, after separation and before getting the right spacing. This is one way a D-side can help (since he focuses on handoffs and datablock entries), but you should double-check even if you have a D-side. Start the handoff a little early, even, just to make sure you don't forget it later.
#4: Enroute Spacing
When excessive congestion, or storms (especially) start choking off key traffic routings, controllers turn to their supervisors to "do something." One of the few actions supervisors can take is to call adjacent areas and request (demand) miles-in-trail restrictions on all traffic, regardless of destination. Sector 82, for example, may be told by the supervisor that Cleveland Center is getting too many weather deviations and needs 20 miles in trail for aircraft at the same altitude (e.g. one can be over another at different altitudes, like 330 and 370, but if they're both at 330 they need to be 20 miles apart).
This adds workload to sector 82, so often that supervisor calls others down the line and asks for the same--20 miles in trail at the same altitude. And on and on down the line, until Denver Center is suddenly doing sequencing for JFK.
It usually doesn't propagate that far, but it isn't atypical for 82 (one of the main entrance points into the northeast U.S.) to be spacing aircraft bound for the east coast (800-1000 miles away).
Thus for some additional realism when working 82 (or 75, even) in the coming summer months, impose a 20 mile-in-trail restriction (on yourself) for any aircraft along the same route at the same altitude, regardless of destination. This, of course, makes it easier for subsequent controllers who have aircraft deviating left and right, to have extra spacing between subsequent aircraft.
Or, if another altitude is available, change their final cruise altitude. Normally you would ask the pilot ("for enroute spacing, you can either slow to mach .72 for the rest of your trip, and stay at 330, or go down to 290 and normal speed"), but probably 99 percent would take the new altitude (and normal speed), so just do it without asking. That is if another altitude is available--you may have another at 290, and another at 370, so there may be no option.
Central Flow control frowns on such miles-in-trail restrictions between facilities, because the delays propagate across the country and tend to make things worse. But for temporary situations (e.g. until storms along a major airway dissipate), supervisors may impose them. The avoidance of nightmare traffic congestion (and possible deals) takes precedence over added delays.
#5: Decertification and Re-training
Officially, if you are decertified on a sector (or sectors) after a deal, you are supposed to undergo some kind of re-training, focusing on whatever the investigative board determined was the cause. Most of the time, deals are just flukes... you told one to climb, one to descend, both to expedite, but it just didn't work. You saw the traffic, tried to make it work, but it just didn't. What would "re-training" teach you that you didn't already know (besides not doing it again)?
Everybody is aware of this, so usually "retraining" is just a formality. If you get decertified in ATCC, to be true to the experience you should do what real controllers do. Something like:
Mostly, retraining is just designed somewhat to humble you and make sure you are extra careful the next time.
If you should have three deals in the same 12 months, there are more formal procedures they can take, including re-assigning you to a smaller (quieter) facility, giving you an office job (which are actually coveted, since you keep the same pay and work straight days instead of rotating shifts), or letting you take some time off (with or without pay) to refresh your psyche or resolve any life problems that are affecting your work.
The FAA really doesn't fire controllers for poor performance... they are too hard to find and train, so they usually won't let you escape!
Not the mental act, but the card game, where you lay out a deck of playing cards on a table (in rows and columns), then turn them over two at a time, trying to find matches. If they're a match, take them out, and if they're not a match you turn them back over and try to remember what and where they were, for your next turn.
This simple game has a lot in common with running a sector, and good controllers would likely be good at Concentration (and vice-versa). When a datablock first pops up on your scope, prior to taking the handoff, the normal procedure is to first check its strip. Use whatever memory technique you need to burn in where he is going and what he needs to do, and if possible or relevant the type of aircraft. This should last in your mind long enough that you can do a complete scan of the sector, and come back to the aircraft and remember (and refresh) the information without having to look at the strip again. At any given time while working a sector, you should be able to point to all the ORD arrivals, for example, then all the overflights, then all the MKE arrivals, in separate groups. This is also part of the secret to keeping the flick (as mentioned in a recent issue), to be able to immediately separate your traffic into common groups based on your memory of where everyone goes.
You shouldn't have to recheck strips if you have and keep the flick. One common question is "How do controllers remember where everyone goes," and the answer is they just do. There are tricks to help with remembering, like offsetting datablocks in a certain direction, or length (like /2). But a controller should just remember where the aircraft is going, or if the amount of traffic is beyond memorization (the limit is probably around 10-15), the controller should at least remember that somebody in that general area needs to descend into ABE, for example, then just check the strips of those few aircraft for the right one.
By some curiosity of the human mind, the burning-in process used to remember (and refresh at each scan) the callsign, type of aircraft and general routing, even though used only for the 10 or so minutes the aircraft is in the sector, often stays in the brain for hours or even days. A supervisor can ask a controller, hours after the fact, about commands issued to a routine overflight, and many controllers remember all the details, including callsign, type, altitude and destination.
That may not apply to some of the smaller, more congested sectors, where everyone is on a preset route and altitude. All you know and care about in those cases is that if it's on a certain route, it is a certain type that needs a certain altitude. Aircraft type and other info is mostly irrelevant, so there is no need to memorize it.
Many situations are especially memorable (for months or years even) when you do things like barely escape a deal with 5.0 miles of separation, or perform some heroic spacing that makes a perfect string of pearls. And if a controller should have a deal (most only have a few, at most, in their career), he will probably remember it for life.
#7: Little Things
#8: Bad Advice?
Careful cross-referencing of hints and tips in this and previous newsletters will reveal contradictions. And if you ask controllers or instructors the same questions, you will get contradictions, and different answers from the same people on different days. The reason is that there are just too many variables, and several "correct" answers for any situation, that the only real answer to questions on controlling technique is "it depends."
So there is not always an answer to situations you may see in ATCC (or real controlling). There is no pre-set scenario generator in ATCC that creates "overtake" or "merging at same altitude" situations for you to apply a given rule to solve, just a flow generator that cranks out random aircraft along real-life routings, which closely mimics the (ultimately) random flows in the real-life sectors. So you will possibly see situations that were never programmed, and that nobody else has seen in ATCC or even reality. There is no "solution" to any problem, only 10 different things you might do from the mouths of 10 different controllers. A typical example:
Q: In sector 66, I get a slow turboprop from the southwest at FL210. A minute later, a JFK arrival pops up-- at FL230 (instead of 210), and gets stuck above the overflight. What was I supposed to do?
A: Who knows? One thing you might have done is turn the slow guy at FL210 to the left, maybe, so the one at FL230 could descend. Or maybe not. Maybe descend the one at 210 to 190, so you could descend the one at 230 to 210, by which time he might have passed the other by 5 miles and could continue descending. It depends!
You just use your bag of controlling tricks (even if small) to try something, and do your best to make it work. It may not work--hand them off and move on. There are always more aircraft aimed for your sector, and you don't have time to dwell on one situation. Try to fix the situation, but if you can't get them at the correct altitude or the correct spacing, just move on.
Which contradicts a previous newsletter item (about 10 miles spacing requirement meaning 10 miles, not 9 or 8!)... so, the correct answer is:
You must be a super-controller at all times. Fix other controllers' incoming mistakes, and make none of your own.
And there is always the FAA's standard reply: We don't care, just don't have a deal!
The Read Binder is updated at the beginning of the month. All information is for use with Xavius Software's Air Traffic Control CenterTM 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 firstname.lastname@example.org and we'll be glad to help!