ATCC Controllers' Read
Binder... NOTAMS, FAQs and other info for users
of ATCC
April, 1998
#1: Voice Recognition Driver
Testing for the voice recognition driver
has been delayed a bit, so if you were on the beta tester list, you
haven't been forgotten. We are still trying different optimizations to
get the highest accuracy and response rates, because it is natural to
want to speak faster as things get busier, which can make things worse.
It does take some practice to get used to the calm, even speech needed
for accurate speech recognition, but it does seem workable so far.
Testing will probably begin this month, and further info will be
available in the next newsletter.
#2: Positive Separation
Remember that the policy of the FAA
is to have aircraft positively separated at all times, such that
if the radar or radios fail, or for that matter the controller
"fails" (insanity, heart attack, etc), all aircraft will be at
guaranteed safe altitudes or headings, just by ingrained controller
habit. This means you don't point aircraft at a mountain, even though it
is 30 miles away, planning to turn them before they get too close, and
you don't put two aircraft at the same altitude on a collision course,
even though they are 50 miles away and you plan to descend one before
then. If there is known traffic, you must fix it before doing
anything else, and especially before taking the handoff and letting it
into the sector. There is some difference in the terminal (approach and
tower) environment, but in general fixing conflicts as soon as they are
detected is the rule.
Thus, if a new handoff begins flashing at
you, which will eventually be in conflict with one of your other
aircraft, you should get on the interphone, change the altitude or
heading (or alter the other aircraft's altitude/heading) to get
separation before accepting the handoff. Do not take the handoff
with the assumption that you will be talking to the aircraft within a
minute anyway, and will still have plenty of time to change the altitude
then. That may be true, but it just isn't the desired policy. Make sure
all aircraft entering your sector are guaranteed separated from everyone
else.
Examine your controlling habits... do you
climb departures all the way up when you don't have the full
"flick", after only a quick glance of the immediate area,
figuring you can always stop or turn them later, or...
Do you roger their check-on, but let them
level off at FL230 until you can regain the full flick and give them a
guaranteed safe altitude when you finally get to them in the scan?
The "official" answer, of course,
is the latter: only give altitudes that you know for a fact are
guaranteed safe, regardless of how fast or slow they climb. Let them
level off until you regain the picture, or are finished with the other
things going on in the sector to get back to them.
What is actually practiced by the
controllers out there may differ, but that is supposed to be the
"official" policy.
#3: Datablocks
Datablock habits every good controller
should have:
- Immediately after issuing an altitude,
in the same motion as unkeying the mike (ENTER key), your hand
should continue up to the <F8> key to type in the temp
altitude, or take it out:
246,^270<ENTER><F8>270
521<ENTER>
...should be similar to what you type for every altitude command. If
you are a fast enough typist, you should be finishing the temp
altitude entry as the pilot is saying his readback. As he restates
the altitude, check the datablock to make sure your entry was
successful, and correlates with what he says.
- As you reach each aircraft in your scan,
after checking its altitudes and where it fits in with other
traffic, you should be moving the datablock to prevent future
overlaps as much as possible. So you are both separating the
aircraft from other aircraft, and separating its datablock from
other datablocks. Some ATC radar systems do this automatically, but
with the U.S. system it is all manual. You do get used to it, and
learn the "good" directions in each sector that minimize
overlaps.
- (Optional, though helpful): After
issuing a frequency change, move the datablock to the /0 position
(e.g. <F1>/0 345) in the same manner as you enter temp
altitudes immediately after unkeying your microphone. If the
aircraft acknowledges, say goodbye and move on. If he doesn't,
immediately /1 the datablock again to indicate the aircraft never
acknowledged. You can either issue the frequency change again, or
move on to more important matters in the scan and get back to it
next time--the datablock still being a /1 will remind you he is
still on your frequency.
- After a slant-zeroed (/0) datablock has
reached the boundary of your sector, remove it from your scope! If
it is still /1, it means you never switched him over: switch
him over, then remove it from your scope when he acknowledges. Of
course, the boundary can also be vertical, so once you have seen a
/0 datablock climb above or descend below your sector, take it off
to keep your scope clean.
- It's usually easier to move datablocks
around using the computer ID number instead of the mouse, because
you can keep your hand on the keypad after typing
<F1><direction>. If the datablocks are overlapping,
though, it is probably easier to use
<F1><direction><mouse click> instead of trying to
decipher the computer ID from two overlapping datablocks.
#4: The Interphone
This happens in reality, as well as ATCC:
after you take a handoff on an incoming aircraft, but before you are
talking to him, you see that you now need him to be at a different
altitude as soon as possible, so you get on the interphone and tell him
to descend to FL240. The other controller acknowledges, so you think all
is well. Then the aircraft comes over, still level at the old altitude.
Or you want to slow an aircraft to 250 knots, so issue it via the
interphone as soon as it pops up, only to find out 15 minutes later when
your aircraft are still tied, that he was never issued the speed.
What happens is that you reach the other
sector's D-side, just as the other sector's R-side is issuing the
frequency change. Because the D-side is talking to you, he often doesn't
hear his R-side issue the frequency change, so thinks the aircraft is
still on their frequency and acknowledges the instruction. ATCC D-sides
aren't smart enough to realize this, and assume things will
"somehow fix themselves."
Thus, you should verify that the aircraft
received the instruction by checking the strip. If it doesn't show the
speed/heading/altitude change, or you don't see the aircraft moving to
the new altitude in the datablock, get on the interphone and issue it
again, or better yet ask to talk to the aircraft (*) so you can do it
yourself.
Miscommunication between sectors is
frequently the cause or contributing factor to deals, especially when
there are multiple middlemen involved, such as telling your D-side to
call the other sector's D-side (who then tells the other R-side) to
issue an instruction. This is why the * command should be the most-often
used on the interphone: just do it yourself. "*" in
ATCC equals the common "Let me talk to him!" interphone call
in real-life.
#5: Similar Callsigns
This is another frequent contributor to
miscommunication and deals, both in reality and probably ATCC. It can be
common to have a DAL175, AAL75 and UAL275 on the same frequency, for
example, so in ATCC if you shorten the callsign to "75" it
could be any one of the three (or all or none) who answer. Thus, in ATCC
be sure to have at least three letters in the callsign, because
the last 3 digits are designed to always be different. Thus, AAL75
should be abbreviated to no less than "L75." Even if you only
have one aircraft in your sector, such as NWA23, you should by habit
call him "A23" instead of 23. Or, if you don't mind the extra
typing, it can't hurt to type the full NWA23 every time, when there is
only a two-digit flight number.
In reality too, similar sounding callsigns
are somewhat frequent problems. Controllers are supposed to tell their
supervisor whenever they get similar callsigns on frequency, and the
supervisor is supposed to forward a form to the flow control supervisor,
who forwards it to Washington DC headquarters, who are supposed to
disseminate it to the proper airlines and ask them to change it. The
paperwork always gets lost, though, and it seems sectors get stuck with
the same similar callsigns every day. Some airlines with the "spoke
and hub" system of flights have even numbered their batches of
departures similarly, like GLB105, GLB205, and GLB305, all departing in
a row and headed to the same sector. Confusion, and "was that for
Global 205?" "Blocked!" "That was for Global ONE
zero five, ONE zero five only; Global TWO zero five stay right where
you're at!" ensue, day after day.
It is possible to change an aircraft's
callsign with a computer entry (like turning AAL510 into AAL510Q), often
done when the aircraft are going to be next to each other for a long
time, but you can't do that in ATCC. Usually when you get similar
sounding or looking callsigns, just try to get them to the next
frequency as quickly as you can, and be extra careful with your
transmissions and readbacks.
#6: Featured Sector: ZAU 75
- If an overflight aircraft is eventually
going over CRL (check the strip), you are authorized in sector 75 to
give them ..CRL. This pretty much looks like ..OBK, so there is not
much difference in the flow if they are coming from the west, and
the pilots appreciate it. If they are coming from the southwest, it
puts them along the southern boundary, out of the way of everybody
except the occasional departure. On some stormy days, though, the
supervisor will tell you not to give them CRL because it puts the
aircraft between J584 and J146 later on in sector 82, which can add
to the problems if everybody there is deviating. So if your screen
is filled with weather, you should only give them ..OBK.
- Other common direct routings you can
give are ..JVL for anybody landing at ORD, and ..FOD for the ORD
departures. You give direct routings to be "nice," and
also because everybody in reality will ask for something direct
anyway, so giving them ..FOD or ..CRL when it's not busy will keep
them quiet later.
- You need to develop your own memory
techniques to remember who is going where: which are the ORD landers,
and which are the overflights. One method is to move the datablocks
for the overflights to one side, like the 1, 2 or 3 "down"
positions, and ORD's to the 7, 8, or 9 "up" positions (or
vice-versa). Or you can change the overflights' datablocks to the /2
length, to stand out more. Another way is to give all of the
overflights direct to somewhere (like CRL, OBK or BAE), which will
take them off the airways, and leave the ORD arrivals on the
airways. Then, any aircraft on an airway approaching DBQ is probably
an ORD lander, though check the strip if you are ever unsure.
- The regular procedure is to have ORD arrivals cross 20 west of
JVL (or NW of JVL) at FL240, but probably nobody bothers. Just start
their descent in the vicinity of DBQ (or a little before) if coming
from the west, and around the J16 intersection if coming from the
northwest, and they will level off at 240 in plenty of time. If they
don't, sector 74 doesn't really care because they probably work the
same sector themselves and know the story.
- Overflights are usually spread out
enough that they aren't in conflict with each other, but sometimes
you can get clumps of overflights merging in the BRIBE or COTON
area, so watch out. If you do see a merging conflict at the same
altitude, and catch it soon enough, turn whomever is a little behind
the other (usually they're not in a dead-tie) 10 or 20 degrees toward
(to go behind) the other one. Or, you can climb one of the
aircraft to a higher altitude, say from FL330 to FL370, or from
FL370 to FL410 (and tell them to expedite, i.e. E^410 if they are
getting close, and keep saying AAL123,E to get them to hurry, though
the higher up they go the harder it will be to climb rapidly). If
you do change their "cruising" altitude, be sure to use
the <F5> key to show the new permanent (hard) altitude,
otherwise the next controller will see a temp altitude and try to
descend them back down. There is no "best" way to resolve
crossing overflight conflicts, so sometimes controllers just ask the
pilot which he prefers, 10 degrees left for about five minutes, or
climb to a new altitude and stay on course. Sometimes they prefer
the short turn (if they're on time or have a smooth ride), but
usually they'll opt for a higher altitude to burn less fuel. It is
also usually easier for you just to climb them up to a new altitude
and not worry about forgetting to turn them back on course later.
- The spacing requirement to ORD is 10 miles-in-trail, but
unlike ZLA sector 19, you are handing off to another Center sector
(74), so they are more forgiving and have some extra room to get the
final spacing. So, just eyeball the spacing, and if you have the
histories set at 3 (roughly 5 miles), just aim for equal length of
histories and blank space from one aircraft to the next. Whether it
is 8, 9 or 12 miles, sector 74 won't mind fine-tuning it. Try to get
something started if you end up with less than 10 miles, though, by
slowing the back aircraft down a bit (maybe to 270 or even 250 if
you only have 7 or 8 miles) to help out sector 74. They'll make fun
of you for not being able to get the spacing ("200 miles of
sector isn't enough room for you?"), but they will understand.
- For ORD aircraft west of DBQ, don't worry so much about
spacing until they get further east. It is likely that whatever you
try to accomplish won't work, because of the vast distance,
inaccuracy of the wide range, and different tailwinds. Once they get
east of VINTY, compare their distance to JVL with <F4>, and
give whomever is in front (or a little in back but naturally
faster--check the speed on the flight strip) ..JVL and leave the
other on course over BRIBE. After DBQ, if your plan worked, great,
but if not, there is still enough room to get the 10 miles by
turning one out and matching or reducing speeds. If they are tied
after DBQ, turn one 30 left and give the other ..JVL. After you have
8 or so miles (measured from JVL), turn the back one to JVL again
and you should end up with 10. Assign both the same speed (like 310
knots) and it should hold.
- Start fitting in the ORD arrivals from the northwest as they
near J16. The intersection of J16 and J30 is about 5 miles closer
than DBQ, so if you have one over J16/J30 and one over DBQ, the
northwest arrival should be number one, all else being equal. Leave
the one over DBQ on course over BRIBE, and give the northwest
arrival ..JVL to widen the spacing a little more, then tweak it more
as they near BRIBE. If, however, the northwest arrival is tied with
the one from over DBQ, or just a little behind, turn him to a 180
heading, and give the DBQ aircraft ..JVL, turning the northwest
aircraft back to JVL as he falls in behind the DBQ aircraft.
The same applies if you have a whole mess of ORD arrivals between
DBQ and BRIBE, different tailwinds, and you have no idea how the
northwest arrival will fit in: just turn him to a 180 heading, or
even further, to fit him in line (or the back of the line) with your
west arrival stream.
- Most of the ORD departures can be climbed all the way up to
their cruising altitude, because they will be level well before they
conflict with aircraft coming from the west. If you give overflights
..CRL or ..OBK, though, watch for head-on traffic, and also be
careful with the MKE arrivals from over MZV; if necessary, descend
them to FL250 or FL270 so the ORD departures can more easily
get above them, or just stop the departures underneath and wait
until they pass.
- MKE arrivals and ORD arrivals merge at JVL and both need to
descend, but in general leave the MKE aircraft above the ORD. The
MKE arrival may be at FL270 or FL290, and the ORD at FL370 abeam DBQ,
which is reversed from how you need it, but if you descend the ORD
to FL240 at or before DBQ, they will get down in time so as not to
be in conflict with the MKE's... it will look scary, but it is
usually OK.
- For the northwest-to-southeast overflights down J30, be aware
that sector 83 frequently has merging traffic along J146, and can
and will climb or descend the aircraft while still in your sector
(if they are talking to them) to resolve their traffic conflict.
Thus you shouldn't switch aircraft to sector 83 until they are clear
of all other traffic in the area, regardless of altitude. If there
are two along J30 in the same direction and within 5 miles of each
other, make sure 83 has a handoff on both before you switch one
over.
- When you have 20-plus aircraft and a screen full of weather
(which should be appearing as spring and summer approach), where
chaos is the norm and you are struggling to "put out
fires," aircraft will start asking for 10 or 20 degree left or
right turns to get around weather. Just answer with "A"
("approved as requested"), because the sector is big
enough that you probably don't need to worry whether they go left or
right. In the more crowded sectors like 66 and 97 you should specify
the direction (DV8L or DV8R) and fix to go to when they're finished,
but in 75 you probably have them ..JVL or ..CRL anyway, and with so
much space between streams of traffic they'll probably be done
deviating and be back on course before they conflict with anybody
else.
- Sequencing and spacing when weather is present can be
difficult, especially when a cell is sitting over a key point like
DBQ or JVL. You can improvise and give ORD arrivals ..OBK, if that
will get them around the weather and prevent deviations from messing
up your sequencing, if you want, though often the deviations are
minor or consistent with everybody (e.g. everybody asks for 10 left
at the same point), so it may not affect things much. Bad weather is
the norm at ZAU in summer months, and Flow Control is supposed to
watch out for you and re-route or restrict arrivals to help
alleviate the workload in 75. As controllers will attest, though,
don't count on it!
- "Positive Separation," of course, is always the
policy of the FAA, so technically if you see a possible conflict
between one of your aircraft on J82-94, say, and a new handoff
coming up J144, you're supposed to take action and fix it before
accepting the handoff (e.g. descending one to a different
altitude)... but with a sector this large, don't worry about it.
Your guess that they are or are not going to be a conflict is
probably off, because of the large distance and different tailwinds,
and it's unfair to chronically descend ORD arrivals that early.
Most probably take the handoffs from the west and southwest without
caring so much about conflicts until they near the VINTY area,
unless they are taking a certification check and have a supervisor
standing over them. The same is true for conflicts between J30 and
J82/94 overflights... there's no way to tell if they will really be
traffic when they're 200 miles apart, so don't bother until they get
closer to DBQ and BRIBE.
#7: On Being FPL
Though getting certified on your sixth sector is really no
different procedurally than getting any other, there is a significant
change in status. You are now considered FPL, "Full Performance
Level," and change from being a "naive trainee" to being
a "real" controller. As a trainee, even if you are certified
on five of the world's busiest and most complex sectors, but are still
missing that sixth (simple) sector to make you a full FPL, you are open
game to any "real" controller (FPL) to criticize or comment on
your performance, or tell you the "right" way to do things,
and you are expected to thoughtfully nod and not question their
reasoning. Supervisors feel free to watch you work your five sectors,
and pull you into the back room afterward to "talk" about what
you did with so-and-so, or why you descended so-and-so, and wouldn't it
have been better to turn him instead? One FPL training you will tell you
his way -- the right way -- to do something, then the next day another
will tell you something opposite. You are expected to do both. You have
no say in the matter, because you are a trainee.
But once you are certified on that last sector, you become a
member of the Club. It is just the culture (in the U.S. at least) that
FPL's are not criticized or second-guessed about their techniques or
decisions, as long as the fundamental rules are adhered to (i.e. you
don't have deals, and you get the proper spacing). If one
controller sees another (FPL) working a sector the hard way,
thrashing around from crisis to crisis, he would certainly be tempted to
offer a suggestion--"just descend United to 250"--but won't.
The unwritten rule is that if you are an FPL, you can do it how you
want. As long as you don't have a deal, or violate official rules,
or act grossly unprofessional, supervisors don't care how you get it
done, and though other controllers may grimace at another's techniques,
the prevailing saying is "he's an FPL, he can do it however he
wants."
The justification for this autonomy and reluctance to criticize
technique is that for any given sector, there are probably only a few
dozen people who are certified on and work that sector, making them the de
facto experts for that corner of the aviation world. No
outsider--classroom teacher, management higher-up, or newsletter
writer--would be justified in coming in and lecturing how to sequence
ORD arrivals after DBQ, to the very FPL's who sequence ORD arrivals
there day after day. Thus, once you are declared FPL, you are considered
one of the few experts in your sectors, and are not second-guessed about
your decisions. As long as you don't have a deal, and get your 10
miles-in-trail, nobody can tell you how to work traffic.
Until you are certified on that sixth sector (or if you have a
deal, making you a "trainee" again), you are fair game, so
take all advice from higher ups, other controllers, and newsletter
writers into consideration. Once you are bestowed with the
"FPL" title, though, feel free to disagree, or do things your
own way. As long as it works, and as long as you make it through the
chaos without a deal, they will consider you a success.
END
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 support@xavius.com
and we'll be glad to help!
|