LoginBenutzernamePasswort
Bei jedem Besuch automatisch einloggen    
Registrieren
Registrieren
Einloggen, um private Nachrichten zu lesen
Einloggen, um private Nachrichten zu lesen
Fluglotsen-Chat  
...::: FLUGLOTSE.com :::... :: Das Forum für Fluglotsen :: Foren-Übersicht » Center Talk

Neues Thema eröffnen   Neue Antwort erstellen
ATC Simulation Fankfurt Arrival Gehe zu Seite Zurück  1, 2, 3, 4
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Redfox



Anmeldungsdatum: 09.05.2004
Beiträge: 36
Wohnort: München

BeitragVerfasst am: So Apr 04, 2010 7:55 pm    Titel: Antworten mit Zitat

Hi ChrisFly,

mal zwei Fragen aus purer Neugier ... zwinker

Ist bei deiner SW angegeben welches System der Amis damit simuliert wird?

Bastelst du den FRA-Sektor, weil dir das programmieren und "selber entwickeln" Spass macht, oder hauptsächlich, weil du gerne 'nen deutschen Sektor zum "Spielen" haben möchtest (nix für ungut, ich weiss aus Erfahrung, dass einige ATC-Sims für den PC selbst den Lotsen den Schweiss auf die Stirn treiben können )?

Falls letzteres der Fall sein sollte, und du a bisserl was "investieren" kannst, würde ich dir empfehlen mal Folgendes anzusehen:

London Control
http://www.londoncontrol.com/

Germany Radar
http://www.aviascan.de/
(Autor-HP: http://www.andreas-milde.de/

Ersteres ist Voraussetzung für Zweiteres (Add-on) ... und dort bekommst etliche deutschen Sektoren (APP, ACC und UAC) up-to-date und mit nahezu real abgebildetem Traffic ... und vor allem mit einem tollen Handbuch und fast perfekten Sektor-Beschreibungen fürs reale Handling der Fliegers froehlich001
_________________
Grüsse
Redfox
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ChrisFly



Anmeldungsdatum: 07.02.2010
Beiträge: 23

BeitragVerfasst am: Fr Apr 09, 2010 1:13 pm    Titel: Antworten mit Zitat

Hallo Redfox,

Redfox hat folgendes geschrieben:

Ist bei deiner SW angegeben welches System der Amis damit simuliert wird?


Ich habe beim Durchsehen der Beschreibung keinen direkten Hinweis finden können, wie die Systeme genau heissen, die simuliert werden. Ich werde mal in der ATCW Usergroup nachfragen.

Farben und Symbole können in einem gewissen Rahmen konfiguriert werden, so dass eine Anpassung an verschiedene Systeme möglich ist.

Es werden Konfigurationen für TRACON, RsiT, das ursprüngliche ATCCv2 und eine Standardkonfiguration (wobei ich nicht sagen kann, auf welchem System diese beruht) mitgeliefert.

Für Frankfurt habe ich anhand von Bildschirmfotos versucht Farben und Symbole entsprechend zu konfigurieren (wobei ich jetzt nicht sagen kann wie das in Langen verwendete System heisst).

Redfox hat folgendes geschrieben:

Bastelst du den FRA-Sektor, weil dir das programmieren und "selber entwickeln" Spass macht, oder hauptsächlich, weil du gerne 'nen deutschen Sektor zum "Spielen" haben möchtest (nix für ungut, ich weiss aus Erfahrung, dass einige ATC-Sims für den PC selbst den Lotsen den Schweiss auf die Stirn treiben können )?


Ist beides der Fall. Darüber hinaus macht es mir auch Spass mich auf diese Art und Weise mit den Verfahren auseinanderzusetzen froehlich

Nur "Schweiss" erzeugen genügt nicht; die Frage nach dem Wie dürfte bei ATCW meiner Einschätzung nach fast sogar wichtiger sein, d.h. es sollte die Simulation real existierender Abläufe sein.

Ich weiss, dass sich in der ATCW Usergroup auch Controller und Piloten befinden und nehme daher an (auch aufgrund der Diskussionen, die ich bisher verfolgt habe), dass die Sektoren ziemlich gut den Ablauf der realen Welt (USA, Kanada) wiedergeben.

Redfox hat folgendes geschrieben:

Falls letzteres der Fall sein sollte, und du a bisserl was "investieren" kannst, würde ich dir empfehlen mal Folgendes anzusehen:


Danke für die Hinweise.

Gruß
Christian
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ChrisFly



Anmeldungsdatum: 07.02.2010
Beiträge: 23

BeitragVerfasst am: So Apr 11, 2010 7:43 am    Titel: Antworten mit Zitat

Redfox hat folgendes geschrieben:

Ist bei deiner SW angegeben welches System der Amis damit simuliert wird?


So, jetzt kann ich es genauer sagen:
Für Canada können das RSiT Terminal (Radar Situational Display) und das DSR (Display System Replacement) simluliert werden.

Für USA wird eine Konfiguration des FAA DSR Terminals zur Verfügung gestellt.

Gruß
Christian
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Redfox



Anmeldungsdatum: 09.05.2004
Beiträge: 36
Wohnort: München

BeitragVerfasst am: Fr Apr 30, 2010 11:56 pm    Titel: Antworten mit Zitat

Hi Chris,

merci für die Info froehlich001

Na, dann wünsch ich dir viel Spass beim Programmieren und dann Simulieren ... auf das du ins Schwitzen kommst zwinker
_________________
Grüsse
Redfox
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Redfox



Anmeldungsdatum: 09.05.2004
Beiträge: 36
Wohnort: München

BeitragVerfasst am: Sa Mai 01, 2010 11:20 am    Titel: Antworten mit Zitat

Hi Chris,

hab hier noch was für dich, was vielleicht "nützlich" beim Lotsensimmen zwinker sein kann ...

------------------------------

"Hints & Tips" für den Radarlotsen

Hallo allerseits,

die Firma Xavius ( http://www.xavius.com ) ist Hersteller einer ziemlich "realitätsnahen" ATC-Simulation, bekannt unter dem Namen "ATCC". Simuliert werden Sektoren der amerik. ACC (ARTCC), aber mittlerweile auch einige europäische Sektoren. Der Autor dieser SW war selber einige Jahre lang Controller in einem ARTCC. Zu dieser Sim wurde eine zeitlang ein "Newsletter" von Xavius herausgegeben, indem der Autor nicht nur speziell zur Sim selber, sondern auch allgemein "Hints & Tips" für den Radarcontroller und einiges über diverse Gepflogenheiten der RL ATC (in den US) zum Besten gibt.

Ich habe mal versucht das spezielle Sim-Zeugs "auszuklammern" und einen "Extrakt" dieser nützlichen (?) Hinweise für den Radar-Controller etc. zusammenzufassen ... ich hoffe, es trägt zu eurer Unterhaltung bei ... und hinterlässt den einen oder anderen verwertbaren Hinweis ... (leider alles in Englisch ... I beg your pardon ;D )

Aus http://www.xavius.com/archives.html ...

________________________

LOOKING AWAY FROM THE RADAR SCREEN

Center radar controllers do not sit glued to the radar scope! The typical Center controller has to do all the following:

Every few minutes, new strips are brought to the sector, in little plastic holders, and dropped in the top of the strip rack adjacent to the radar. The sector controller has to go through each new strip (around 5 new ones at a time), weed out the unneeded "deadwood" (duplicates, old versions, etc, as much as 50 percent of the total), then those that remain must be sequenced in the rack by the time estimate on the strip. Every few minutes the controller has to look away from the radar and do it all again as more strips are brought to the sector.
About every 30 to 60 seconds, the ATC computer sends strip update messages to the sector, which causes an orange button to light up on the D-side's keyboard. The controller has to lean over, press the button, then read the message on the D-side's computer terminal. The message contains revised info for a strip at the sector, such as a new time estimate, or new altitude. The controller has to look through the rack (maybe 20-50 strips), find the one in question, then cross out the old info and write in the new.
After every instruction, controllers have to look over, find the appropriate strip, and mark down what instruction was issued. Descend and maintain 15,000 would be written as down-arrow and 150 (or 15). Turn 20 left would be written 20L, or RV and the new heading (for "radar vector"). Even if an aircraft is just checking on to the frequency, a little checkmark must be made next to the altitude on the strip.
In the sim, all of the above are done for you automatically, to provide a balance with your need to look down at incoming messages or to type commands you'd otherwise speak. The overall looking-away-from-the-scope versus looking-at-the-scope thus remains similar to the real-life workload. But yes, speaking pilots and voice recognition would make it better, and we're working on that! But as-is, it's still very realistic.



WORKLOAD AND GETTING OVERWHELMED

It's entirely possible that things will get to be too much for even a seasoned professional controller to handle. Having to type a lot only makes it worse. As a controller, you are expected to make the best of the situation, keep as calm as possible, concentrate on one thing at a time, do it, and systematically move on to the next. Still, things may get away from you, at which point you should request a break, hang on for a couple more minutes, then get out of there and recollect your thoughts. These are some reminders on how to reduce complexity hopefully before it starts, or as soon as you realize you've lost control:

A shining gold nugget on your screen is a handoff that has been taken by the next sector. As soon as you see this, and there's no other potential traffic for them, get them the heck off your frequency! If they're at or close to the boundary, take the datablock off too. Technically, you're supposed to leave it displayed until the aircraft is 2.5 miles outside your boundary, but don't worry about it. Take it off to clear up your scope. Do a complete scan cycle where you just get rid of handed-off aircraft. Ignore everyone as they call you--you can get back to them later, or they'll call again if it's important. After the complete cycle, you'll probably find your workload has reduced significantly.
As you're doing your scan from aircraft to aircraft, you've probably found that as soon as you see something that needs to be done, and you're just about to key up the microphone, somebody interrupts you with a check-on message, or asks you if there's "any chance for higher," or some other message that messes you up and causes you to stop your scan and find who it was, then stumble back to where you left off in the scan. Here's the Big Secret: YOU ARE THE ONLY ONE WITH ANYTHING IMPORTANT TO SAY!! When you are on the edge of chaos, or are in deep chaos already, ignore everybody!! Forget everyone. First go around and get rid of the handed-off aircraft. Next go around from aircraft to aircraft in your scan, and one by one issue appropriate altitudes. All along, you will be interrupted: "Ahhhhh we're getting moderate chop, any chance for lower?" IGNORE!! TRANSMIT YOUR MESSAGE: DAL357,*258. "Good evening, UAL456 out of 8,700 climbing to 12,000" IGNORE!! TRANSMIT YOUR MESSAGE: 803*2697. "USA234 leaving 17,000 for 11,000" IGNORE!! TRANSMIT YOUR MESSAGE: 150<20 etc etc. Yes, you're supposed to be polite, professional, and respond to all calls. Some pilots may get mad at you (though most do understand when you're busy), and may say "didn't you hear us calling you?!", and yes, you were rude and arrogant and ignored them all. But you HAVE TO, when the choice is between being meek and responsive and losing control of everything, or being aggressive and regaining control and awareness. Of course, when things are slower, ALWAYS be polite and ALWAYS respond promptly. But if things get crazy, be arrogant, ignore the fluff calls and get things back in order!
When you're in chaos and cleaning up your sector, don't take additional handoffs. They'll still fly into your sector, but you won't be charged with any deals with them. In real life the previous controller would turn them around before they entered your sector, and that does happen in the high-strung, congested areas, especially the northeast U.S. But system complexity then increases exponentially, and there are numerous mechanisms (ground stops, re-routes, holding, increased miles-in-trail) to help compensate for it. The sim doesn't have the number-crunching power to do all that, so aircraft just keep flying into the sector. It shouldn't be that big of a problem, however, in most cases. Once things are cleared up in your sector, you can start taking more handoffs (even though they may be halfway through your sector already).
A good controller will be arrogant and ignore calls when restoring order in the sector, but will make a mental note of who is asking about rides or checking on, and will get back to them politely once the sector is under control again.



APPROACH

Many approach control functions are similar to the Center environment, in that you must provide separation (3 miles at TRACONs, 5 at Centers, but the same 1,000 foot requirement) to all aircraft. But, the "final controller" (which the ORD sector simulates) only works aircraft headed for the same runways: there are no overflights, no departures, and everybody is pretty much at the same speed.

It is impractical to use "range rings" (like in ZLA19) or "common convergence points" to determine sequencing when close to the airport; instead, you mostly "eyeball" who goes where, and mentally determine who you want to follow whom, then turn them as necessary to make it work.

To keep it simple, though, you want to try to keep everybody in the "standard pattern:" downwind (opposite course from landing), base leg (90 degrees to the runway), then final (lined up for the runway). In the ORD sector, aircraft from the northeast are already on final to runway 22; just leave them alone. Those coming from the southeast need to be turned onto base (360 heading), then onto final (..O). The ones from the southwest are already on downwind, so they need to be turned to base and final along with those from the southeast. The arrivals from the northwest should be turned onto downwind (040 heading), then base (130 heading), then final (..O). You may, however, elect to turn these arrivals directly onto base if you want them to cut in front of other arrivals.

To know when to turn aircraft onto base, or onto final, mentally determine who you want #1, #2 and so on. Turn #2 onto base and final just at the right moments to stay behind #1. Keep #3 on downwind, then maybe a little after you've turned #2 onto base, turn #3 onto base. Keep in mind that #2 could be coming from the south side, and #3 from the north, or vice-versa. Or maybe you want both #2 and #3 from the same side, so it's just a matter of keeping them following each other.

If you're just a little late with a turn, you can mess everything up. You have to be at complete alertness and ultimate concentration. If you do miss a turn, though, it's probably easier just to turn the missed aircraft out and back into the downwind/base pattern than to try to force them back in sequence.

Sequencing to final approach is really beyond the scope of a newsletter, but we should have more tips in the future...



VECTORS VS. ALTITUDES

There are usually several ways to solve traffic conflicts, but usually it boils down to: go over/under, or go around? Usually, going over or under (using altitudes) is the easiest and quickest. If two aircraft are converging at FL330, climb or descend one of them to FL350 or FL310 until they pass, then take them back to FL330. It will probably only take two minutes to get to the new altitude (or less), so it is usually the quickest.

Turning aircraft out (10 or 20 degrees, say) involves guesswork, may need additional turning (if your initial calculations were wrong, due to different groundspeeds, or upper winds), and you run the risk that you could get busy suddenly and forget the aircraft was turned out.

Develop your own techniques and use whichever method you are most comfortable with, and whichever is most fair to the pilots. They may be a little annoyed at having to descend then climb again a few minutes later, but they also may be annoyed at having to be turned out when they're already running late. Take that into account, along with what is easiest for you.

If you catch the problem soon enough so that only a 10 degree turn would solve the problem, use turns--nobody should be annoyed at only 10 degrees. If you don't notice the problem until the last minute, it's probably quicker to descend or climb one aircraft than to have to turn one or both 30 or 40 degrees.



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.



THE CAUSE OF MOST DEALS -- UNDER-RESTRICTIONS

In the real-world, most deals occur not because the controller "just didn't see it," but because ineffective or not enough action is taken to correct a conflict once it is first recognized. Also, they tend to occur when traffic is only moderate or less, and not when things are extremely busy!

The two "trends" may be related... when traffic has been slow for awhile, or the controller has just worked a busy rush and things have quieted down, controllers (and pilot alertness) can become complacent, and when there appears to be a conflict, for example, the controller might figure "just a little turn to the left" would solve it (after all, there's hardly any traffic out there, right?)... and might lazily ask the pilot to turn "oh, 10 degrees left, short vector around traffic."

Later he might notice it's not looking too good, but things are still quiet, there's only those two aircraft in the sky, and there can't be a real problem when it's this quiet! So he casually tells the pilot: "Trans Air 225, I need you to turn an additional 10...no, better make it twenty degrees left."

The casual tone and quiet frequencies have lulled the pilot into complacency (and into a conversation about sports with his co-pilot), and he replies with the worst response a controller wants to hear at that point: "Uhhhhhh, was that for Trans Air 225?"

"Yes, turn 40 degrees left now, and expedite the turn" the now-alarmed controller spits out, a little too rapidly.

"Uhhhh, Ok, I believe you said 40 degrees left, for Trans Air, uhhhh, <pause> 225."

"That's right, FORTY degrees left and start the turn NOW!!"

"Ok, forty left, Trans Air 225." The pilots calculates: Let's see, heading 017 minus 40 degrees... carry the 7.. negative 23, so 23 degrees left from 360... hmmmm...

Too late! Deal.

Don't be complacent... deals can happen any time, even when things feel slow and there's no apparent urgency. Don't fall into a common trap of denying there's a real conflict, and "just a little turn" will fix it. It's better to unnecessarily turn an airplane 90 degrees off course, and avoid a deal, than to be standing before the Inquisition trying to explain why you only gave him a 10 degree jog to the left that didn't fix anything at all...

Don't over-restrict!

Remember you are burning fuel (and lots of money) when you over-restrict aircraft by making them descend before they need to, or turning them 40 right when they only need to go 20 right. When you have everybody expediting and turning hard left and hard right and everywhere else, you sound out of control, which the pilots can sense (and may be a little more hesitant when you need a response now).

But WAIT! Doesn't that contradict # above? That it's better to turn an aircraft 90 degrees off course and avoid a deal than to try to be nice and just turn him a little?

Yes, it does contradict #! You have to find a way to do both, somehow. Turn and restrict aircraft as little as possible, but whatever you do, don't have a deal! Maybe 90 degrees left to guarantee avoiding a deal is too harsh... would 70 still do it? How about 50 degrees? 50 degrees is a pretty big turn. But so is 40! Or 30 for that matter, when you really think of it...

If you are really good, you can do both. Turning and restricting as little as possible, and always avoiding deals. But if there is ever a question, # always takes priority-- do whatever it takes to avoid having a deal, and worry about the burned fuel and late passengers later!



WHEN YOU FIRST SIT DOWN AT THE SECTOR

The first thing a controller does is to receive a "relief briefing" from the controller he's replacing. A relief checklist, actually a laminated card that can be marked with a grease pen, is posted at each sector, but varies a little depending on the sector and facility.

The L.A. Sector 38 relief board, for example, might look like this:

R-2508 STATUS HOT

SPECIAL ACTIVITIES

FLOW CONTROL 20 MIT LAS

EQUIPMENT

AIRPORTS

WEATHER LT-MOD CHOP 250-290

TRAFFIC

Briefings tend to be very quick, because it's usually the same group of controllers working together at the same sectors year after year, and everybody's pretty much seen everything before. The sector 38 briefing might sound like this:

"2508 is hot, they're not letting anybody through... no special activities; you need 20 miles in trail landing Las Vegas; equipment's fine; airports fine; Weather: Light to moderate chop in the climbout, until about Dagget, but everybody says it's smooth at 33 and 37. Probably 24 or 25 is the best ride if they're landing at Las Vegas. Traffic is: (pointing with finger at each, from top-down usually) Gone; Direct Vegas, still talking (i.e. still tuned to the sector frequency); Has the restriction (DAG at FL240); Talking, cutting across at 31; Climbing to 29, stopped for this guy; expediting through 25 to get below this guy, looks like it'll work; and not talking to this one."

After working the same sectors year after year, controllers can usually pretty quickly figure out what's going on with relief briefings as quick as you can read the previous paragraph. 99 percent of the time traffic is kept conflict-free, but if something is still unsure (like above, "expediting through 25 to get below this guy, look's like it'll work"), the controller being relieved should either offer to stay until it's resolved, or make sure the new controller fully understands the conflict and will accept the responsibility. He might say "are you OK with that, or do you want me to stay a little while?" If the new controller hesitates, the other controller should stay until it's resolved and the sector is conflict-free again. But if it looks good, the new controller may say it's OK, he'll finish it.

Because relief briefings are usually very quick, there is an amount of trust that the relieving controller isn't going to inherit a traffic mess from the previous guy, who may be long gone on lunch break. Controllers tend to learn who leaves messes and who runs their sectors smoothly, and may pay more attention to the relief briefing depending on who they're relieving.

After first sitting down, controllers usually do a couple quick scans to get the "flick," then may spend a few minutes adjusting the chair, the volume knobs, and the brightness levels to how they like it. The same is true in ATCC, that the default brightness levels may not be to your liking, and every time you run a sector, you have to keep adjusting the levels until they're just right! Wouldn't it be nice if ATCC remembered my preferences? Yes, nice and easy to implement, but in the real world you have to keep fiddling with the brightness knobs, too, so that's the way we had it. Maybe we'll change it, though--there is new real-world equipment under development:



FRUSTRATION

If you have been working busy traffic, especially with storms around, you have probably encountered a similar scenario: DAL492 suddenly requests 40 right for weather, and you take a moment to find him and notice that NO! He can't go right! And just as you are about to key your microphone to tell him deviations left approved, somebody else checks on... "Center, ASH468 with you <pause> 15,000." Agggh! You go to type in the instruction to DAL492 when ANOTHER aircraft starts transmitting... "Uhhhhhh <pause>... any chance for higher for USA850?" AGGGHHHH!! Again, as you go to key up your microphone, DAL492 now announces he's "turning right, we can't go through this." And turns right toward another aircraft at the same altitude...deal! Wait, you didn't even have a chance to say anything, let alone approve the deviation, and DAL492 just turned on his own! How could it be your fault? Dumb computer, right? How were you supposed to know Delta needed to deviate, when all of the aircraft before him went straight through?

The answer is: too bad! Controllers must be able to cope with anything and everything that may happen, unexpected or not, and will ultimately receive at least part of the blame. Certainly, in the above scenario (which does and has happened in real life), formal discipline probably would not occur, but the controller would be asked harsh questions:

"Why didn't you anticipate deviations when you knew you had weather in the area?"

"I didn't..."

"Why did you have two aircraft at the same altitude so close together?"

"But 10 miles... I mean..."

"If radio congestion was a problem, why were you taking handoffs when you knew they would check on moments later, clogging up your frequency?"

"If I knew..."

"Why didn't you expedite the Delta?"

"But that wouldn't have..."

"Why didn't you climb the other one or turn him out?"

"But there was no..."

No if's...but's... the controller is ultimately responsible, if not technically than morally. Everybody knows there will be situations beyond the controller's control, and nobody will be fired or even disciplined necessarily. But ultimately the controller will feel the blame--it was his sector, after all.

The point is, things run smoothly most of the time, and most of the time it is even fun. But sometimes, the frustration level will rise, situations may seem unsolvable (they may, in fact, be unsolvable), and events will occur beyond the control of the well-intentioned controller. The only thing one can do is to make the best of a bad situation, then move on. The job is only stressful to those who dwell on their mistakes or situations beyond their control... those who forget about everything when they leave the radar room learn to come back refreshed and eager to tackle the sector again!



AS ALWAYS, SCAN, SCAN, SCAN!

Even the most experienced controllers sometimes forget to keep scanning-- it's just human nature to fixate on something when you have a problem developing. But remember, you have 12 seconds between radar updates, so nothing is going to change in that time. Even if you have a pending situation about to occur, take a quick 10 second scan around the scope to keep your mental picture refreshed, and you should get back to the situation in time for the next radar update.

If you are frequently missing radio transmissions, you are probably fixating too much in your scan or are having too many conflicts. If you are busy, you should be able to quickly look at a situation and within 4-5 seconds come up with a safe altitude or heading, issue it, glimpse at the response, and move on. Remember that the overall ATC policy is to keep everything positively separated, meaning if the radar or radios fail, everybody is still separated. You shouldn't have to constantly monitor a situation, wondering if it is going to work or not-- use guaranteed safe altitude separation if you are in doubt.

The section of the ATCC manual on calculating climbs and descents mostly applies when your sector is quiet, and you have time to do the mental calculations. If you are busy, forget it... use guaranteed safe altitudes until the aircraft pass, then continue their climbs/descents. They may level off unnecessarily, but you don't have the time to watch them and hope it's going to work... keep the scan moving, and the sector will move much more smoothly!



PROPER SPACING!

It is a primary requirement (after separation of aircraft), that you create the necessary in-trail spacing for those airports/routes that require it: 10 Miles to LAX in sector 19; 10 miles to ORD in 75; and 7 miles to JFK in sector 66. 9 miles to LAX is not good enough. 8 miles to ORD is not good enough. More than required is OK, but less is not. Yes, the next ATCC controller will still take the handoff if you don't get the spacing, but in reality you would be heckled over the interphone, your supervisor would be called and he would ask you why you're not adhering to the sector procedures. Spacing usually can't be compromised, because most of the major airports already run aircraft as tightly as they can get them in, and trying to squeeze the spacing a little just won't work. There is a lot of over-spacing, but very little under-spacing in reality. The best controllers are exact: neither over nor under. 10 miles exactly.

If you have chronic problems achieving the required spacing, you would probably be decertified and sent to the classroom for re-training. "Re-training" would probably mean sitting down with another controller/instructor, brainstorming ideas for getting and keeping spacing, and running simulations (increasingly soon on our ATCC program itself). These are a few spacing tips from real controllers:

For most of ATC, the earlier you do something or start it, the better. Except for spacing... if you start too early, such as at the western or southern boundary of sector 75, you'll likely find that errors in your distance measuring, or different tail winds, or slight variations in aircrafts' speeds (one could go mach .755, the other .764, both "technically" mach .76) result in different spacing than you anticipated -- you either get less spacing than you thought, or you over-restrict somebody and waste space, time, and fuel.

If you start your sequencing too late, of course, you have to take more drastic actions (large turns) to get the spacing, and that can also be imprecise. Thus, there is some kind of balance you have to find: in sector 75, the "right time" to start spacing is probably around DBQ, unless they are already in a line and you can see the direct results; in sector 19, start sequencing right away, and in 66 you should probably wait until the oceanic arrivals are around MANTA or PREPI before you decide which gap to put them in.

When you're too busy to mess with the distance-measuring key, or things fall apart at the last moment (like you suddenly notice that "overflight" is actually an ORD arrival you have to fit in), you can play Follow the Leader, and create a "snake." With whatever physical space you have between two aircraft, regardless of which direction they're coming from, just point one at the other, and that distance will hold. For example, in sector 66 if you have one JFK arrival at DRIFT, and one at PANZE, both at the same speed and both direct CRI, point the aircraft at PANZE directly at the one at DRIFT (70 heading?), and you'll hold that spacing (roughly 15 miles). Then when the aircraft reaches DRIFT, keep turning him to follow the one in front, wherever he may be at that moment. You may have had to turn that one out to follow somebody else, but it doesn't matter. Just keep everybody turning to follow the one immediately in front of them, and you'll have the "snake," and the spacing between them will hold.

Once the extra aircraft has been fit into line, or the chaos restored, the "snake" will continue for awhile, as you have to keep turning aircraft to follow the ones in front of them, until there is a big enough gap between new aircraft coming in, that you can keep them on course without them catching up to the tail end of the snake.

The benefit of this technique is that it is very intuitive once you see how it works (it's confusing to read--once you've done it, it's easy, though) and it is easy and quick to see how much spacing you have without the <F4> key. The downside is that you have to manually turn everybody to keep them following each other, so you can make yourself very busy. Also, if you forget to keep somebody following the previous aircraft, creating extra space, the snake will grow larger as everybody else behind him will have to turn out the extra distance, too.

Don't trust datablock groundspeeds. They are calculated by a simple estimate of the speed based on previous radar hits. If a radar hit is missed, or the aircraft is in a turn, the groundspeed readout grows more inaccurate. Thus, if you have an aircraft merging into line, and you turn him to line up with everybody else, the groundspeed readout will drop drastically, then slowly catch up. For awhile you will think you have a massive overtake developing, and may feel compelled to unnecessarily slow down everybody behind him. That wastes space, adds to your workload, and is unnecessary.

The most reliable way to determine their speeds is to ask the pilots (they could conceivably lie, but they don't). Also remember to take into account different altitudes-- 300 knots at 14,000 is faster than 300 knots at 10,000. But if they are close together in altitude and direction, 300 knots on the front guy and 300 on the back means they're at matched speeds, regardless of what the groundspeed readout says. And autopilots on the airliners are very precise, so you can expect them to do 300 knots exactly, not 302 or 299.

The second most reliable way to determine if you have an overtake/undertake when your groundspeeds are erroneous (such as in a turn) is to compare the differences in spacing between the target and its previous histories. If one aircraft is moving 4 millimeters between updates, and the one in front is only moving 3mm, you have an overtake, even if the groundspeeds say they're matched.

The ATCC groundspeed readout is actually pretty close to what the aircraft are doing, so the above may not apply, but the real-life groundspeed readout is almost useless once the aircraft start to turn, speed up or slow down.

None of these hints may help you! You have to develop methods that work for you, whether methods used by others, or completely unique to you, or combinations of both. If it works, and you get the correct spacing without over-restricting, then keep it! There are probably as many techniques as there are controllers, and each controller thinks his/hers are the best! (This author included, except his are the best).



DEALS EVERYWHERE!

If you have been certified at one or more sectors in ATCC, you are a "controller" now, so you might as well know the truth: real-life losses of separation ("deals") happen all the time, and nobody knows how to stop them! (Numbers are on the order of 500+ per year in the U.S.). Full-time trend analysts produce comically random graphs that ultimately show almost zero correlation between the occurence of deals and time of day, season, time on position, complexity of traffic, or any other factor that might contribute to the problem.

Various changes in practices and procedures have been attempted, to try to reduce the frequency of these "operational errors." One cyclical stop-gap measure has been to have a D-side at the sector at all times, with the reasoning that an extra pair of eyes and ears can only help. As it turns out, it also means having somebody to talk to, share jokes with and get distracted. Also, some controllers tend to be more bold and daring when somebody else is watching closely, so there are both advantages and disadvantages to permanent D-sides.

"Miscommunication" is likely the bottom-line cause of the vast majority of "dumb" errors. You tell an aircraft to turn "left," when you really meant to say "right." Or you say "flight level two two zero" while you think you are saying "flight level two zero zero." Or maybe you see aircraft A and B are in conflict, plan to descend aircraft A, but look at B's callsign in the datablock as you issue the descent.

Certainly fatigue and lack of alertness (see August issue, #6 ) can play a large role, but even the most careful, precise, ultra-alert controller will make the occasional mistake. What can be done? Humans make mistakes. Fortunately, radar separation is just one of several safeguards against collisions, which include cockpit radar (TCAS), pilots' eyes, and the big-sky theory. It is unlikely all will fail simultaneously, and in fact there have been no mid-air collisions between two Center-controlled IFR aircraft in the U.S. (Collisions with VFR aircraft have occured, though--those little I's and V's are very real!)

Good scanning techniques and a constant re-evaluation of what is happening in the sector can help catch "dumb mistakes" before they become a problem. Good short-term memory also helps. For example, you may see in your scan that you have an aircraft climbing to an interim (temporary) altitude of FL330 for crossing traffic at FL350. You may remember that was your plan, to stop the aircraft underneath the other until they pass, then continue his climb. But if you cannot specifically remember issuing FL330, and cannot specifically remember the pilot reading it back, re-issue it ("just to verify...maintain flight level 330."). The pilot may sound annoyed, "uhhh, yea, that's what you said the first time, FL330." But why risk it? It may be one of the one-in-ten-thousand-times you meant to say FL330, and put FL330 in the datablock, but actually said FL350.

On the other hand, at some point you have to trust your memory, that the pilot did indeed read back FL330, otherwise you will go crazy trying to verify everybody's altitude again. But, if you are ever unsure, re-issue the altitude "just to be safe."



DEALS IN ATCC

For comparison, a real-life controller trains and works for 500-1000 hours on the six sectors before becoming an FPL, and that is after spending a similar amount of time doing just D-sides (which mostly just let you watch how other controllers work). If you spend 300-500 hours with ATCC either working traffic or training at the 80-100 level (with master level set at 100), you should get a similar level of experience as a real-life (new) controller. Of course, you will not get one-on-one instruction ("On-the-job training"), but in most cases the real-life instruction just consists of a bored controller who is told to watch you, and who yells at you if you make a mistake, and writes "no discrepencies noted" if you don't. Controllers aren't teachers, and teachers aren't controllers -- you sink or you swim, and are mostly on your own. Out of the 500 or so hours this author spent training at radar positions (after about 500 on the D-sides), he received only three moments of practical advice: "Keep the scan moving," "Get rid of aircraft as soon as you can," and "The sooner you start something, the less you have to do." The rest was just figured out as time went on, and new situations were experienced.

After almost 7 years of real-life controlling, and about 120 hours of "working" ATCC sectors, this author has an 85 rating and one deal in ATCC, ironically at one of the sectors he worked in real-life, ZLA 38 ("I just didn't see it!"). Unless you are a real Center controller, you may certainly have more deals than this, but if you ever make it to the 300-500 hour level (including time spent training), you will be a true "professional" and should have no more, ever.



ARTICLE 65

The controller is responsible for all activity in the sector, and if there is a deal, he will take the blame. With their jobs ultimately at stake, very few controllers will tolerate somebody else telling them what to do with their traffic, especially when it is busy and the controller has formulated a shaky plan he is struggling to make happen. If you were working a very busy sector 97, for example, and received a call from sector 73 telling you to "Hold UAL243 at ETX" because they can't take him right now, the proper, expected response would probably be an obscenity. Nobody can tell you how to run your sector! Forget sector 73. Hand him off to sector 93. 93 can't take him? Try 98. No? Hold him at PTW. Or FJC. Or anywhere you want! 73 can't tell you how to run your traffic. It's your sector, your responsibility, and you run your own traffic!

Nobody can tell you what to do with your traffic, that is, except a supervisor. A supervisor may override you at any time, and whatever he says to do, you must do. If a supervisor tells you to "descend this guy to FL230," you must descend him to FL230, even if that causes a deal. If the supervisor says to slow UAL243 to 250 knots, you must slow UAL243 to 250 knots, even if there is a DC-10 immediately behind him, coming up his tailpipe! If a supervisor ever tells you to issue a particular clearance, and you don't personally agree with it, you must issue it but invoke "article 65" (of the union contract), which states the supervisor now assumes all responsibility for the operation of the sector. Even if the particular command does not cause a deal, it may disrupt the general flow of the sector, and was not your plan originally, so you cannot be held responsible for future deals that may occur.

Naturally, supervisors can't (and don't) know what is going on with every aircraft in every sector, so it is extremely rare for them to order you to issue a particular command. It has happened, though... in a recent deal at L.A. Center, a supervisor looked over the shoulder at a situation he thought would not work, and told the controller to turn one aircraft 40 degrees to the right, which the controller promptly issued--which then put the aircraft head-on with another the supervisor didn't know about, causing a deal. The deal was blamed entirely on the supervisor.

That can be a very difficult situation for a controller--follow the orders of the supervisor, and possibly have a head-on collision, or disobey the supervisor, and be fired. Too bad! Take some more antacid tablets. Also, your request for vacation has been denied.

Fortunately, most supervisors know better, and leave controllers alone. They learn who they can trust in the busy sectors, who will need a D-side, and who needs extra watching. They'll bite their lip as they watch controllers run aircraft 5.1 miles apart, and if there is a deal, there is a deal. What can they do?



MORE GENERAL TIPS

Datablock positions should be part of your regular scan. After you've refreshed your memory regarding the aircraft and its altitudes, check that the datablock position won't overlap with another datablock later on. Move the datablock to the position that will minimize future overlapping. Don't, however, put the datablock directly in front of the target (blocking possible traffic), or directly behind (blocking the histories).

If you start to lose control of your radios, where suddenly everybody starts to transmit their check-on, or requests for higher, ignore them all. Do your scan, issuing commands one at a time, making handoffs where they need to be made, and moving datablocks where they need to be moved. Once everything you need to do is completed, then go back and "roger" the check-ons, or just wait for them to check on again. You are the only one with anything important to say. Everything you need to do takes priority over anything they want from you. You run the show!!



THE IMPORTANCE OF READBACKS!

Listening to readbacks is absolutely critical in real-life ATC, and now with talking pilots becomes equally as important. Your instruction to the pilot is not complete until you have heard a correct readback... if you correctly issue an altitude of FL330, for example, but the pilot reads back FL350 (which you miss) and there is a subsequent deal, you are to blame!

Likewise, if you do not get a readback, you are required to assume the pilot did not receive the command (though it is possible they did, and are already doing it), and must re-issue it. This may typically occur after you first issue the instruction, but then a different aircraft begins talking. You might even answer that second aircraft, but you must remember to get the readback from the first aircraft, or re-issue the command.

If the pilot acknowledges with just "roger," or "copy," instead of reading back the altitude/heading/speed assignment, you are allowed to accept that as a proper readback, but there is no harm if you issue the instruction again, "just to verify" the altitude, for example.

Be fully alert when listening to readbacks! You might tell Southwest 35 to descend to FL240, but Northwest 35 may respond. If you're not fully alert, it is easy to miss, and you take the blame if there is a deal! The instruction is not complete until you have issued it and heard a proper readback... don't move on with your scan until you have heard the readback.



LOSING CONTROL OF YOUR FREQUENCY

The addition of talking pilots makes the limitations of radio communications even more obvious. You issue an instruction to an aircraft: "Delta 415, descend and maintain 14,000." Before the aircraft can even answer, somebody else checks on: "Good evening, N15J 12,000." You decide to quickly answer 15J before Delta's readback, but after you do, you get "Blocked!" Still no readback from Delta 415, so you re-issue 14,000: "Blocked!" ... <squeal from two talking at once> ... "Was that for Delta 415?" "Good evening center, UAL756 flight level 240." ...

"DELTA 415!!!! DESCEND AND MAINTAIN 14,000!!!!!!"

"Blocked!"

You've lost control of your frequency. You know what you need to say, but nobody will let you say it! Getting the proper sequencing and spacing can depend on turning aircraft precisely at the right moment, but you can't tell the aircraft to turn when everybody keeps stepping on each other.

Too bad. The same problem exists in reality, and is the true source of the Stress. You have to simply accept that occasionally you will be unable to issue timely instructions, due to radio frequency congestion. This means not relying on being able to turn them "at the last minute," because that may be when you lose control of your radios.

When you have lost control, and everybody is talking at once, the best method is to take a deep breath, key your mike, and type slowly and deliberately, to one aircraft at a time. Wait for the readback, and ignore everybody else. You are the only one with anything important to say! Move on to the next aircraft, issue the instruction, and wait for the readback. Ignore the aircraft checking on. Ignore the aircraft asking about the rides. Ignore the requests for lower. Do what you need to do, until the immediate tasks are complete. Then go back and acknowledge the check-ons, or give ride information to those who asked.

Ideally you shouldn't lose control at all. If things are starting to get busy, but are still under control, don't ignore check-ons or requests, because the pilots will assume you didn't hear them, and will keep asking. Ignore pilots only after you have lost control and need to regain it.

Other tips are to issue plain descend-and-maintain instructions instead of crossing restrictions, to keep them from interrupting you later to tell you they have started their descent. Also don't take a bunch of handoffs at the same time, as they may all try to check on at the same time. And get rid of aircraft as soon as you can... if the next sector has taken the handoff, and you are done with the aircraft, switch them to the next guy and get them off your frequency!

Congested radios indirectly or even directly cause many of the delays that exist in commercial aviation. Controllers may be able to handle more traffic mentally, but there is usually a lower limit on how many they can have on frequency at once. One shared radio frequency can quickly become filled with ride complaints or s-l-o-w talkers!



THRASHING

At the other extreme to losing control of your radios is having your radios so much under control that you are tricked into thinking things aren't as busy as they actually are. The radios may be quiet, and things running so smoothly that you begin to reflexively take new handoffs without fitting them into the overall picture, subconsciously equating a quiet radio with a quiet sector. Eventually the radios will get busier, and you may forget about those new aircraft until the last minute, when you notice the conflicts and have to thrash around from crisis to crisis.

Don't let quiet radios fool you. Always make complete scans, and be sure to note where the new aircraft fit into the sector before you take the handoff!



ANGRY CONTROLLERS

For whatever reasons, controllers honestly believe they each have the best controlling techniques. Most will gladly defend absolutely any decision they make about any instructions they ever give. Even if it results in a deal, many will stand before the investigative committee and say the deal was unavoidable, or it was somebody else's fault, because the actions taken were "obviously" the best possible at the time.

This arrogance can cause a great deal of tension between controllers, especially if it is ever implied that a decision was wrong or could have been done better. Controllers restrain themselves from physically attacking others over comments like "Couldn't get them 10 in trail, huh?", which may be said to friends, but never to others. Shoving and punching may ensue.

Why are controllers aggressive? Because aggressive, arrogant controllers are successful! They don't wonder if a proposed solution is the right solution, they know it is (because they thought of it) and they just do it! They don't mess around trying to vector someone left and right to get to his requested cruising altitude, they just tell him FL290 will be his final, and BOOM, that's his final. They keep traffic moving, getting aircraft up and out of their sectors. They sound professional, and even friendly, but it becomes obvious that there is no compromise, because they have decided on an action, and that action is taking place. They have no time to wonder: maybe there is a better way? Because their plan is the absolute best, and damn it, they will make their plan work.

They move traffic quickly, and there are no deals because they have a firm grip on everything that is going on. They grind their teeth, twirl their pencils and bounce their knees, impatiently waiting to see their perfect plan fall into place. Move this guy here, this guy down to 25, this guy over here, and BOOM, everybody's separated. DO IT!!! DO IT NOW!!! Can't wait to see this!!!! <twirling pencil>. If somebody suggests: just climb him to 27, that'll work too... the controller snaps: TOO BAD!!! HE'S GOING TO 25!!!

This arrogant, "Type A" personality is successful because the job demands quick, unhesitating decisions with little time to ponder alternatives. Come up with a solution, and do it! is the credo of the successful controller. Don't listen to alternatives, don't confer with others about what to do, just key up the damned microphone and do it! They work best in busy, congested facilities, and busy, congested facilities love having them as controllers. They may not come up with the best solutions, but whatever solutions they do come up with will happen, and everybody else can kiss their a##.

The ideal controllers, though, don't need to be rude. They may be just as arrogant and aggressive, but they hide it well. There is no need to externalize their intensity; they simply know their solution is the best, so it is just a matter of efficiently relaying it to the pilots and smugly watching it fall into place. Another controller may suggest an alternative, which the ideal controller may acknowledge is a good plan. But I am going to do it my way, he ultimately says, with a smile! [Ok, a sarcastic smile.]



THE SECRET TO THE "FLICK"

A good controller can only keep a picture of maybe five separate things at once... if even that. Try to animate a scene in your head of a ball rolling slowly across the floor. Now add another ball moving in another direction, while still "moving" the first. Add another, and another. It probably gets difficult after just two or three! Yet controllers are expected to somehow mentally keep track of 15 to 20 aircraft at once, supposedly without resorting to noticing things on radar at the last second.

The secret is to clump aircraft together into common streams of traffic, then just look at and keep track of a few different streams instead of 15 to 20 individual aircraft. Sector 82, for example, only has two real streams, the northern flow along the top half, and the southern flow along the bottom. You could have 10, or even 20 aircraft in each stream, but really you only have the two "streams" to keep track of, and they don't even intersect. Sector 38 has three main streams: the LAX departures, the BUR departures, and the BUR arrivals. 66 mostly has four: JFK arrivals from the south, JFK arrivals from the east, PHL/ACY arrivals from the northeast, and JFK departures to the south.

When you consider aircraft along the same route (especially when close together and single-file) to be "one" aircraft or one stream of aircraft, you reduce the number of separate "things" you need to keep track of, so keeping the mental picture becomes easier.

If you ever look up and see a screen full of 20 random aircraft, group them together and you'll see it's probably not that bad: 8 of them might be ORD arrivals from the west, for example, making up one group; 3 from the northwest are the second group; 3 overflights from the west are the third; 2 from the northwest the fourth; and a few other departures or MKE arrivals make up the rest. But mostly keep an overall mental picture of just the 4 or 5 different groupings of aircraft, instead of trying to visualize and remember 20 separate aircraft going in 20 different directions. You will have to scan for occasional conflicts within the same group, such as overtakes or merging together at the same altitude, but mostly the sector's conflicts will be between aircraft in one group with aircraft in another.



CONTROL ON CONTACT

In ATCC, controllers have "control on contact," meaning as soon as the aircraft checks on to the controller's frequency, the controller has permission to climb, descend or turn the aircraft as needed, even if it is still within the other sector. In practice, most Centers would allow it only on an individual (sector by sector) basis, such as aircraft going from sector 27 to sector 26 are 26's control for left turns only, "on contact." With ATCC, you have full control, and may turn, climb and descend as you need, within the other controller's sector. Other ATCC computer controllers, though, will never turn aircraft in your sector, and will only occasionally change the altitude.

If you forget about this, and switch an aircraft to the next frequency, you may end up in a difficult situation when that aircraft suddenly starts climbing to a new altitude, right into one of your other aircraft. This situation happens in sector 75, for example, with overflights headed southeast to sector 83. The sector 83 computer controller might have other traffic (which you can sometimes see along the bottom of the screen), and if it has two converging at JOT, it may tell your aircraft to climb or descend to a new altitude. If you have another aircraft above or below the one you just switched, look out!

The solution, of course, is not to switch an aircraft to the next frequency until it is clear of all possible traffic. It is good practice, and a requirement as well.



COORDINATION WITH OTHER SECTORS

In ATCC, the only need for the interphone is when relaying an instruction to an aircraft not yet on your frequency, or to ask that it be switched to your frequency. In the real world, these are also common reasons to coordinate with another sector:

If something about an aircraft changes after you have made a handoff. This is because the next sector took the handoff based on the altitude in the datablock, or the route of flight listed on the strip, or the assumption the aircraft is at its "normal" speed. If you then change one of these things, you need to notify the next sector about the changes, and that sector has the right to "refuse" the change or the handoff, though in practice they will provide an alternate instruction that hopefully works for both sectors.

To seek permission to enter or cross through another sector without making a regular handoff. This is called a "point out," and is used when the aircraft is just going to clip the corner of another sector, or is otherwise not going to be in that sector very long. It saves the hassle of switching the aircraft over, only to have it quickly switched over to another sector again. The controller puts up the datablock on the other sector's scope (with a command equivalent to <F7>sector# CID), then calls the sector and says "Point out", the position of the aircraft, callsign, and what that aircraft will do, such as "will be descending to 240," or "just coming up to your boundary, then turning north", or just "eastbound." If that is OK with the other controller, he says "point out approved," otherwise can provide alternate instructions (like "just down to FL260 is approved", or "reference VIR007, point-out approved.") In ATCC, you can't make an official point-out, so try not to stray into another sector. If you need to, though, consider it automatically approved.

If an aircraft that was pointed out to another sector will now do something different. This, of course, is because the original point-out was approved under the original conditions, so changing them will require new approval.

To pass along information not on the computer flight strip, like a heading assignment or speed, and the reason for issuing it. For example, "UAL150 assigned mach .72, at Flow Control's request." (In ATCC, speed or heading assignments are passed automatically.)

There are various other reasons for coordinating with other sectors (such as finding out ride information), but the above reasons are the most common. When you are busy, it is very inconvenient and distracting to have to go off frequency and wait for the other controller to finish what he's doing and say "go ahead," so the D-side (or even a third "handoff" controller) takes over most coordination. They just have to be sure to properly inform the R-side on what they just coordinated, though, so that there are no misunderstandings. Some of it can be done silently, by marking the strip (such as a red circle indicating the information was forwarded to the next sector, or an altitude written and circled in red to indicate the next sector wants them at that altitude). If the controller is extremely busy and can't look at the strips (or just doesn't care much for strips), the D-side has to somehow get the R-side to hear and understand the information, whether it is waiting for a break in the radio chatter to slip in that "sector 34 wants DAL833 at FL330," or loudly tapping on the strip until the R-side looks over and sees the information. Whatever the case, the D-side ultimately bears responsibility for making sure the R-side learns about the coordination. The R-side, though, also has a responsibility to be at least semi-aware of what the D-side is doing, using the other ear or eye not on the scope... it is supposed to be a team effort, especially when things are busy.



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.



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.



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
_________________
Grüsse
Redfox
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ChrisFly



Anmeldungsdatum: 07.02.2010
Beiträge: 23

BeitragVerfasst am: Sa Mai 01, 2010 11:49 am    Titel: Antworten mit Zitat

Redfox hat folgendes geschrieben:

die Firma Xavius ( http://www.xavius.com ) ist Hersteller einer ziemlich "realitätsnahen" ATC-Simulation, bekannt unter dem Namen "ATCC".


... auf dessen Version V2 viele von uns gewartet haben, bevor Xavius dann schlußendlich die Entwicklung ganz eingestellt hat. traurig

Aus diesem Frust heraus hat sich der Autor von AtcWindows hingesetzt und diesen Nachfolger entwickelt, von dem wir hier die ganze Zeit sprechen und für den ich Frankfurt Arrival entwickel. froehlich001

Mittlerweile ist AtcWindows wesentlich weiter entwickelt als die Vorlage ATCC.

Gruß
Christian
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    ...::: FLUGLOTSE.com :::... :: Das Forum für Fluglotsen :: Foren-Übersicht » Center Talk Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite Zurück  1, 2, 3, 4
Seite 4 von 4

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Powered by phpBB © 2001, 2002 phpBB Group
iCGstation v1.0 Template By Ray © 2003, 2004 iOptional