ZSE TGIF 5/19/2006
Operations Primer
These may be relatively quiet positions early and late, but in the middle of the event during peak arrival time TWR and GND can expect to be very busy and it will be the job of DEL to take care of clearance requests. Expect quite a few arrivals to ‘turn-around’ and call for a clearance. Also, given the PDX/SEA are the event airports, be prepared for many “non” TGIF aircraft to simply be in the area to join the action.
Push preferred routes and DPs as much as possible out of KSEA. If unable, be sure their route includes vectors to a departure gate (ELMAA, SUMMA, TOU, BLUIT, etc). Aircraft with preferred routes and DPs should get preferential treatment. Get them a code, a clearance and get them to GND. Tell those without preferred routes/DPs to expect a delay and save their clearance until you after you get through the pilots who are ready to go with good flight plans. It isn’t fair for us to make 10 pilots with good plans wait 15 minutes for you to ‘fix’ a bad pilot’s screwy route.
The only 2 valid DPs for KPDX are vectored DPs anyway, so be sure to suggest preferred routes, but strict adherence will not be as critical as TRACON/Enroute will expect vectored departures from KPDX.
Be friendly, be patient. Use your best judgment!
Read the Clearance Delivery information above as you will likely be DEL for all but the peak times of the event. HAVE A PLAN. Print that airport diagram in advance and have a plan ready! Remember, you may have dozens (yes dozens) of aircraft moving on the taxiways at any one time during the peak of the event. Be ready to give quick taxi instructions to aircraft exiting runways (particularly at KSEA) to ensure there isn’t a back-up of traffic onto the runways. It will be busy and TWR will need those runways clear, so be ready and be efficient.
Be prepared for a runway switch! Be prepared for a traffic jam and know what alternate routings you might use on the taxiways in case someone is stuck, backed up, or head-to-head on a taxiway.
Be prepared for a ground hold! If it gets real busy in the sky, ground holds happen. It is usually best to hold them at the gates and keep a list (first come first served when able) of planes waiting for taxi. Only taxi a few at a time to the runway so you don’t end up with more than a handful waiting for takeoff. Too many planes in line for departure is a great way to cause a traffic jam on the ground. Even without a ground hold in effect, keep an eye on that hold-short line. TWR may be very busy and having a hard time getting the departures out in a timely fashion, don’t stack too many up at that hold short line!
Know your airport! You will often be the first or last contact for these pilots. Your attitude and preparedness can make or break this event for ZSE.
Be friendly, be patient, don’t suck! :)
Read the Clearance Delivery and Ground Control information above. You may need to cover either or both of these functions either early or late in the event, or possibly even during it in case of controller disconnect, position change, or during a controller break.
Be prepared for anything! If you’re working TWR you should be an experienced S3 so you’ve been through the OTS. This should be even crazier. Be ready to use ‘tricks’ to keep thing moving smoothly. Chances are in May the weather won’t be down to IFR minimums. Expect planes to be tight on visual approaches. Be ready to issue side-step landing clearances if arrivals are too close for the same runway or if you have a departure on the runway too long in front of an arrival. A side-step landing clearance may save you a go-around.
The flow in KSEA is pretty well known. For south ops, 16R for arrivals, 16L for departures. Feel free to use 16L for arrivals also as needed if weather permits for visuals and side-step landings, but don’t land them on your departures and avoid delaying your departures with unnecessary side-step landing clearances to 16L. Use it when you need to, not just for fun.
PDX_TWR, talk to your ground controllers in advance. There is a lot more room for creative use of runways here. In real world, during busy hours, I typically see them sending all the departures to 10L except for heavies which go to 10R. They typically use 10R for all the arrivals. Work it out in advance do you don’t get a traffic jam! There’s a lot of room to use taxiways to keep traffic moving, but that also means there are plenty of opportunities for bad ideas that result in a traffic jam. Think ahead!
If it is West flow, totally different ball game! Depending on the person’s version of flightsim they may not be able to take an ILS to 28L, so expect arrivals to 28R but remember the heavies will probably still want or need the longer 28L for departure. Have a plan!
In either flow, if conditions are VFR, remember that the TRACON controllers (APP) may use simultaneous visuals into PDX. That could be a lot of steady arrival traffic to both runways at the same time. Be ready for that, and be prepared to ‘slip in’ departures on either runway when it gets busy.
Automatic releases from KSEA and KPDX are authorized. Any APP controller for your airport can cancel this at any time during the event, so be prepared to hold departures and ask for release authorization. Coordinate with GND to make sure they don’t stack up too many departures on your hold-short line.
TGIF traffic is what we train for in the Sweatbox. Expect 15+ aircraft in your sector at any one time. In split ops, that can mean a lot of aircraft and a lot of radio congestion. KNOW YOUR LIMITS! If you have doubt, call for holds. The Enroute (CTR) controllers are prepared for and expecting holds. They will do their best to give you 15+ miles in trail but things get dicey in the TRACON during events like this.
Don’t neglect departures. One of our poor service areas in the past has been holding departures when the TRACON gets busy. That’s fine to do, but leaving departures waiting for 30+ minutes sucks for them and looks bad for us. If you have a lot of planes and you’re busy, give TWR a restriction like, no more than 1 dep every 5 minutes, or something similar, to keep departures flowing but keep your load reasonable. Remember, you don’t have to work them for very long during an event like this, just keep them clear of the arrivals and get them up to CTR.
KSEA – North/South split
This is relatively straight forward. Run the TRACON like you normally would, but you only have to handle half the airspace. In south flow, S_APP should focus on keeping departures clear of arrivals and focus on speed restrictions on arrival to ensure they are all on the downwind on their way to 5k at 5-10nm in trail. As you as they are clear of arrivals and on the downwind, hand them up to N_APP. N_APP you zipper them in and get the on the approach. If it is visual, you may be able to stack them tighter, talk to TWR in advance about the possibility of doing this and tell them to expect visuals for both runways, or side-step landing clearances. In IFR, keep a close eye on those speed restrictions on final!!
All departures go to A_CTR. *NOTE* If SEA_SP_CTR is online (The Seattle/Portland Special CTR), then departures to the south (SUMMA6/HELNS4) go to SP_CTR.
KPDX – 2-way split
The P80 TRACON airspace is relatively more complicated than the S46 in that we are able to split the airspace up to 5 ways, however it has rarely been practical to split it into more than 2 or 3. Past experience has shown that the most effective 2 way split East/West. For this TGIF we will be splitting East/West on an invisible line that will be assumed roughly 3 miles short of the threshold of the runway in use. This is designed to allow one controller to handle departures and the initial sequencing of arrivals. Arrivals will then be handed to the other controller for sequencing to the final approach course.
When using Runways 10R/L, the E_APP position will take all the published arrival streams (HELNS, BONVL, MOXEE) and sequence them to be turned and handed to the W_APP controller on ‘downwind’. E_APP will also handle all departures off the 10’s.
When using Runways 28R/L, the W_APP controller will handle the North and South arrivals (HELNS/MOXEE) but not the East arrivals (BONVL). The W_APP will also be responsible for handling the departures off the 28’s.
Northbound departures go directly to A_CTR (or SP_CTR when online), all others to B_CTR.
*Note* In the unlikely event there is a severe storm on TGIF night calling for the use of RWY21, W_APP will instead be N_APP and E_APP will instead be S_APP and a north/south split will be in effect for sequencing to Runway 21.
TGIF is primarily an arrivals event. The 4-way CTR is the backbone that makes this event smooth. Our goal is 15nm in-trail MINIMUM on any arrival corridor. Our neighbors will be asked to give them to us 15-20nm in-trail MINIMUM. Know you arrival routes, know your potential holding points and be ready to use them!
C_CTR should have aircraft at or below FL240, descending for the arrival crossings at least 15nm in-trail and have appropriate airspeed restrictions in place before handing to A_CTR.
D_CTR should have aircraft for KSEA appropriately sequenced at least 15nm in-trail before handing to B_CTR. Arrivals for KPDX should be routed via the MOXEE6 arrival and be in the descent with appropriate speed restrictions for sequencing before handing to B_CTR. Be prepared to pull aircraft from the south off the OLM5/MOXEE6 arrivals and send them north towards IMB/PDT for the BONVL4/CHINS5 arrivals respectively if the OLM5/MOXEE6 arrivals are saturated. This must be coordinated in advance. Expect the Controller in Charge (CIC) or TMC (Traffic Management Controller) to advise you when to do this, but be prepared for it.
B_CTR should have aircraft on the OLM5 arrival properly sequenced at least 15nm in-trail on the decent for OLM, with appropriate speed restrictions before handing them to A_CTR. Arrivals on the MOXEE6 should be kept in sequence and handed to the appropriate PDX_APP controller when practical. Use W_APP for handoffs landing 28's and W_APP when landing 10's in KPDX. B_CTR is effectively responsible for the handling of the BONV4 arrival in its entirety, these handoffs will always go to E_APP regardless of runway in use.
A_CTR should have aircraft enroute to KPDX from the north descent via the HELNS4 routing. Arrivals to KPDX are handed directly to PDX_APP. All aircraft arriving KSEA should be kept sequenced on their respective arrivals and handed to the appropriate APP controller as appropriate. Aircraft departing KPDX to the north will be handed directly to A_CTR.
*SP_CTR* may be opened as needed. The SP_CTR (Seattle/Portland Special sector) is not depicted in the sector file but covers the area roughly from OLM to Mt. Rainier to Mt. Adams to Kelso to OLM. This sector is designed to relieve pressure from A_CTR under heavy load and would be responsible for arrival to KPDX from SEA, arrivals to KSEA on the OLM5 or from KPDX, and departures on the SUMMA6 on their initial climb-out. This allows A_CTR to focus on traffic from the north and east.
CZVR, ZOA and ZLC Controllers: All arrivals to ZSE are expected to be handed off in sequence at a minimum of 15nm in-trail separation, regardless of altitude. In an effort to create space early for our merging arrival streams, we would prefer 20MIT separation or greatr when able.
Please ensure one of the following for each aircraft before handoff:
CZVR - KSEA from the North/Northwest: TOU/JAWBN.JAWBN9, KSEA from Northeast: LOSTT.GLASR6 - KPDX from North/Northwest: SEA.HELNS4, KPDX from Northeast: LTJ.BONVL4
ZOA - KSEA: OLM5 - KPDX: MOXEE6
ZLC - KSEA from Northeast: GLASR6, KSEA from East/Southeast: CHINS5 - KPDX: BONVL4
Please note which Enroute controller your handoff will be to: Center Control Sector Map (4-way Split)
From: Dan Everette
Sent: Wednesday, May 10, 2006 8:10 AM
Subject: RE: TGIF - Coordination between PDX_E and PDX_W
Depending upon traffic levels, PDX can be much more challenging than SEA. This is primarily due to less “wiggle room” because of the airspace ceiling and terrain if nothing else.
Although it’s called E_APP and W_APP, I like to think of it as final and non-final. PVD runs a similar configuration (though they only have 2 STAR’s, and no terrain), and works well (talking with some of the controllers). You’ll see below that although it’s quite detailed, it follows a logical flow, and is very intuitive. It’s a combination of things that have worked in the past, as well as not including/modifying things that haven’t worked. In the TRACON environment, the saying goes (according to every controller I know): “Everyone works for final”. The configurations below are specifically designed for that, as best as possible given the airspace and terrain.
You might ask “Why don’t we have a final approach then”. There are quite a few reasons, which I won’t go in here. But, in short, it’s not necessary, as long as everything else is well structured.
Although we’re listed for E_APP and W_APP, I’ll leave it up to you (since it’s your home facility) which half you want to work, once we know what the weather is going to look like for the event.
Arrivals
MOXEE – All handoffs to PDX_E_APP at 10 MIT.
HELNS – All handoffs to PDX_W_APP at 10 MIT.
BONVL – All handoffs to PDX_E_APP at 15 MIT if landing west, or 10 MIT if landing east.
Definition of MIT: Obviously it means Miles In Trail, but more specifically that:
a) Vertical separation means nothing, and handoffs will be refused if the defined MIT doesn’t exist.
b) Aircraft shall be at the defined MIT and either steady (with speed restrictions) or increasing.
Runway changes
Tower cannot just change runways “on-the-fly” (i.e. out of the blue announce “Portland Landing West now”). Just like in the real world, it’s a highly coordinated and choreographed cluster. TWR notifies the APP’s and gets an acknowledgement. ALL inbounds are held outside of PDX APP airspace (APP notifies CTR). The last aircraft to land on the “old” configuration is identified and everyone after that is moved in a clockwise direction to the other side. Once the new flows are established, CTR starts peeling people off the hold.
Tower Operations
TWR needs to be aggressive with departures and needs to know the minimums down pat to depart aircraft. If it gets really busy, both parallels will be used for arrivals. When I mean aggressive, TWR putting aircraft in position on 28L when there is another a/c on a 4-5 mile final for the same runway.
This is where the commonalities end. Let me specifically cover 3 different scenarios:
1 – Landing East. The airspace delineation is the Runway 03/21 centerline.
W_APP runs final, and gets handoffs directly from CTR for HELNS arrivals.
E_APP will handoff:
MOXEE arrivals departing OCITY on a heading of 270 (I know the chart shows 280, but the extra 10 degrees buys W_APP some more time). 7k, and instructed to descend to 6k after OCITY. Handoff will be initiated 5 NM from OCITY, with comms handoff over OCITY (note*).
BONVL arrivals will either cross OCITY at the same restriction as the MOXEE guys, or will cross north of the field, on a 6-7 NM downwind, descending along the same profile as the OCITY folks. This arrangement provides some flexibility for E_APP to feed W_APP a more balanced load. Handoffs will be initiated at 10 NM from the boundary interface.
E_APP will handle ALL departures (i.e. fulfill a PDX_DEP) role. Departures will be handed off to CTR at 5 MIT and increasing.
2 – Landing West. The airspace delineation is the Runway 03/21 centerline.
E_APP runs final, and gets handoffs directly from CTR BONVL arrivals.
W_APP gets handoffs from CTR for MOXEE arrivals. Aircraft on the MOXEE arrival are descended to depart OCITY on a heading of 110, and cross OCITY at 6k. Handoff is initiated about 10 NM from OCITY. (note*)
W_APP gets handoffs from CTR for HELNS arrivals. Aircraft on the HELNS arrival are to depart BTG on a heading of 100, crossing BTG at 7k, and instructed to descend to 6k after BTG. Handoff is initiated at the BTG 5DME, with comms handoff over BTG. (note*)
W_APP will handle ALL departures (i.e. fulfill a PDX_DEP) role. Departures will be handed off to CTR at 5 MIT and increasing.
(note*) – Although this seems a bit complicated, but it’s providing a built in failsafe. Handoffs need to be accomplished EARLY. If in these cases, the next controller refuses the handoff, it still provides time for the current controller to act (turn the aircraft, or issue an alternate instruction to keep the aircraft in their airspace). Think of it as a non-verbal “hold them” command from the controller working final. It works really well, when the TRACON gets slammed. Though, I don’t think we’ll see the traffic loads that would necessitate holding within the TRACON.
Holding
If the airspace becomes too saturated, CTR can start holding people at the published locations on the arrival. Since SEA-PDX is a popular route, if aircraft start going into enroute holds to PDX, then a ground hold is in effect within ZSE for all aircraft departing for PDX.
Internally holding aircraft can be a bit tricky due to the small area within the TRACON. If you have to hold aircraft, the best bet is to first ensure vertical separation, and then just accomplish the hold via box vectors.
Two things that will absolutely suck are:
-If PDX is in CATII/III conditions for the event.
-The wind is howling (i.e. greater than 30 kts out of the SSW), necessitating the use of RWY21 alone. During this event, I’d still want to try and use the parallels, even with a still crosswind.
If the above two happens, all arrivals need to be handed off at 15 MIT.
Special Procedures – Seattle ARTCC
Ground/Local/Delivery Control Coordination Ian Linford & Garrett Wiedmeier Seattle-Tacoma (KSEA) TGIF – May 19, 2006
INTENT:
The intent of this procedure is to coordinate data flow of all tower cab positions, avoid mass congestion on taxiway bravo near the central terminal where arriving aircraft can conflict with departing aircraft, and to keep a consistent flow of departures to the end of the active runway.
QUICK POINTS:
* These procedures use features of VRC as all controllers currently scheduled are using VRC. If using ASRC, please advise other controllers of the "Tower Cab" upon logon.
* Do not 'auto-add' flight strips.
* GND will push flight strips to TWR as aircraft are handed off near the departure end of the runway.
* DEL will push strips to GND as soon as clearance readback is correct.
* TWR may push strips of arrivals to GND after landing, but this is not absolutely necessary
* GND May ask TWR to hold arriving aircraft between runways in order to taxi multiple departures on taxiway Bravo in the terminal area. A special phraseology has been developed below.
EXPANDED DISCUSSION:
During north ops (34L/R) this procedure may not be needed as there are not as many potential conflicts.
This procedure uses the VRC “text override” function where a private message with the ‘***’ prefix will flash a text message to the other controller. If using ASRC, use normal chat or use a voice override function to facilitate communication.
/Under normal circumstances ground SOP will be used/. However if the need arises, GND control may issue a special restriction to TWR and manage the restriction using the following phraseology:
From GND to TWR:
***hold all
keep arriving aircraft between rwys
***cross UAL2540
UAL2540 will be crossed
***cross 4
4 aircraft will be crossed
***cross all
have all holding aircraft taxi across 16L, h/s of bravo
***cross current
cross everyone who's between the runways, but hold all subsequent arrivals. So, if there are 10 aircraft between the runways and UAL1111 lands, I'll cross those 10, but I'll hold all planes starting with UAL1111.
***end restrictions
End all restrictions on arriving aircraft, normal ground SOP
From TWR to GND:
***filling up
it's starting to get tight, I only have 2-3 spots left, so I'd like to cross at least a few soon, or else we'll have planes on Tango and/or delays with planes trying to find a taxiway to exit.
***FULL
I have no more spots available, overflow is going to Tango, and I'd really like to cross a few before we get a big(ger) mess.
***crossing UAL/all/7
acknowledging your command
***holding
acknowledging your command
***deps?
I have no departures, not necessarily a bad thing, but I could use some to even out the traffic flow if you have the time.
***restriction: [insert restriction here] I or higher controllers have imposed a restriction (for example, one departure every 5 mins) that could affect your traffic flow.
