Metro D Dual ADCs

[alphadelta332]

Summary

Introduces the second ADC position at a number of Metro D aerodromes, in line with their real world setup.

Changes

Additions:

• Added Dual ADC Operations for:
  • Archerfield (YBAF)
  • Bankstown (YSBK)
  • Parafield (YPPF)
  • Jandakot (YPJT)
  • Tamworth (YSTW)
  • Moorabbin (YMMB)
• Added detailed information regarding parallel runway operations at Bankstown (YSBK).

[LeGiraffe]

ADC2 owns SFC-A010 STH OF 29C/11C, ADC1 the rest (including A015 over the top of the circuit)

[alphadelta332]

Are there any risks associated with leaving it how its currently published? Ie for simplicity?

[LeGiraffe]

Technically more complicated as written. For example, TWRN inbound (RWY 29) should contact ADC1 for clearance. Joining instruction of "Join crosswind 29R, M15" cuts through ADC2's airspace and would require coordination. Same with tfc inbound via PNP for either RWY configs... normally expected to overfly at A015 to join northern CCT.
Creating the shelf reduces coordination and frequency management.

[LeGiraffe]

All coordination to ADC1. ADC1 responsible for onwards Coord with ADC2 where required (very rare).

[alphadelta332]

I might just leave this in there, since ENR will probably coord to ADC 1 by default most of the time, just so the tower controllers know to distribute the information internally where required

[LeGiraffe]

Coordination required for;

• All arrivals assigned Runway 29C/11C
• All multi-engine / Jet aircraft departing Runway 11C/29C.
• All Heli's overflying at A005.
• All other acft assigned non-standard circuit directions (ie departing 11L & making a right turn)

[LeGiraffe]

Reference line 156 (not this line), can we remove "Visual" from cleared approach? Acft will be OCTA and usually assigned M015 (RWY 29) if tracking visually anyway. (On phone, limited functionality sorry)

[alphadelta332]

This is how we have it to be standardised with all other Class D towers. Essentially so the tower knows that all coordinated IFR arrivals have been cleared for the approach. Would this cause any issues at YSBK?

[LeGiraffe]

99% of IFR arrivals are from Class G at BK rather than CTA. So, control instruction to an Acft OCTA, probably doesn't work.

However, an Acft does require clearance for an INST APCH prior to handoff.

This differs from somewhere like PF, where 99% of IFR arrivals are via PAL, and call PF TWR assigned A015V day / A018 night (or cleared INST APCH if applicable.

APP/ENR issuing VSA's removes TWR's ability to use levels as a form of Separation/Segregation.

Not 100% sure we can actually standardize this between units, I'm sure other towers will also differ.

[LeGiraffe]

Can we incorporate Runway Dependency when using 29C/11C for departures / prohibition for opposite bases to adjacent runways (29L/29C & 29C/29R)? Let me know if you need more info... just thought it'd be good for those keen

[alphadelta332]

Yeah could you flesh this out a bit? Im a bit confused haha

[LeGiraffe]

Gets complicated... happy to leave it out, but here it is;

RWY Dependency;
The distance between adjacent Runways (Centrelines) at Bankstown does not meet the standard required for Independent Runway Operations. Actual distance 66m(?). Required distance for Single Engines = 60m, Multi-Engine = 90m, Jet = 120m (off the top of my head).

Because Single Engine aircraft are independent (above), you can use the runways independently (ie at the same time). However, the moment a Twin/Jet is involved, you require a runway standard with the adjacent runway(s) in addition the the runway in use.

Note; only applies for departures (an exemption exists for arrivals, causing opposite base issue, more below)

My proposed clause would probably say something like;

(Departures Section)
"Due to the close proximity of parallel runways at Bankstown, runways are NOT independent for multi-engine and Jet aircraft. Controllers MUST apply a runway standard to the Runway(s) immediately adjacent when departing Multi-Engined or Jet Aircraft

Note; Arriving aircraft are exempt from this runway dependency.

For example; A C510 (Jet) is ready runway 29C. The controller must apply a separation standard to ALL 3 runways simultaneously when clearing this acft for take-off. However, clearing an aircraft to land (not touch and go) whilst the C510 departs on an adjacent runway is permitted.

Opposite Base;

CASA instrument exists permitting independent arrivals to adjacent runways, however (due to a midair 20 years ago), aircraft cannot BOTH make the turn to final in close proximity. Controllers must instead ensure at least one of the aircraft is established on final prior to entering conflicts, AND mutual traffic is passed in the event someone passes thru final

Suggested clause;

Arrivals;
Due to high risk of collision and poor field of view during turns to final, Do NOT permit a pair aircraft to turn final simultaneously and/or in close proximity when assigned adjacent runways (EG; 29R & 29C, or 29C & 29L). Controllers should stagger base turns or issue 'go arounds' to solve conflicts.
This does not apply to aircraft pairing assigned adjacent where an aircraft is already established on final AND traffic has been passed to BOTH aircraft.

[alphadelta332]

Yep all makes sense.

Would be a bit of a bigger job though, we currently don't publish those sep standards anywhere, so we'd need to add those in too, and include some stuff in the moodle. Maybe something for down the line?

I think the clauses might be good though. Just saying "don't permit aircraft to turn final at the same time" and "only single engine aircraft can be independent" might be worth adding, without having to publish any additional sep standards or SOPs

[LeGiraffe]

I'd be fine with that. Sep standard are already in place in other sections anyway, even if they aren't the smallest we can get (600m).

[LeGiraffe]

Swap frequencies please.

East/South 124.600
West/North 118.700

Not sure what you want to call them either, as ADC2 (West/North) should be the prime position (CTAF freq)... not familiar with the naming conventions available but PF_E_TWR could work...

[alphadelta332]

Swap frequencies please.

East/South 124.600 West/North 118.700

Not sure what you want to call them either, as ADC2 (West/North) should be the prime position (CTAF freq)... not familiar with the naming conventions available but PF_E_TWR could work...

@Slep-wt thoughts?

[Slep-wt]

Swap frequencies please.
East/South 124.600 West/North 118.700
Not sure what you want to call them either, as ADC2 (West/North) should be the prime position (CTAF freq)... not familiar with the naming conventions available but PF_E_TWR could work...

@Slep-wt thoughts?

As per here, I'd prefer not to change the position identifer. In terms of swapping ADC1/ADC2 internally that is pretty easy to do if thats how it runs rw.

@LeGiraffe

[LeGiraffe]

Leaving as is, Night Ops will be performed on the incorrect frequency, with the opportunity to be "undercut" when the secondary tower logs on and steals majority of meaningful traffic. The lack of ability to combine frequencies across multiple tower positions also hinders this.

Another issue is (RW) PF ADC1 is going to be called PF-2 (ADC2) for us.

Any reason for the lack of flexibility with the identifiers, when we're using other letter for other aerodromes already (including TW-S in this PR)?

PF-E is not perfect, just feel as though there's a better solution out there than PF-2. For example, BK-2 could be BK-C given all it does is CCT's and (almost) nothing else, helping all other units know who is doing what and who to talk/transfer to without reading the book.

@Slep-wt @alphadelta332

I need to also check that our other 2's are actually ADC2 RW...

[Slep-wt]

Leaving as is, Night Ops will be performed on the incorrect frequency, with the opportunity to be "undercut" when the secondary tower logs on and steals majority of meaningful traffic. The lack of ability to combine frequencies across multiple tower positions also hinders this.

Another issue is (RW) PF ADC1 is going to be called PF-2 (ADC2) for us.

Any reason for the lack of flexibility with the identifiers, when we're using other letter for other aerodromes already (including TW-S in this PR)?

PF-E is not perfect, just feel as though there's a better solution out there than PF-2. For example, BK-2 could be BK-C given all it does is CCT's and (almost) nothing else, helping all other units know who is doing what and who to talk/transfer to without reading the book.

@Slep-wt @alphadelta332

I need to also check that our other 2's are actually ADC2 RW...

Swapping ADC1 and ADC2's assigned frequencies isnt too difficult to do, we can resolve that quite easily.

In regard to Tamworth, it was done that way because it has an explicit definition for its area of responsibility in the ERSA (Its very hard to get confused as TW ADCS is only responsible for the southern runway during PROPS).

Again, adding extra information such as explicit responsibility for runways in the controller info may be more appropriate and useful to pilots, as it is simpler to do in terms of the amount of things to edit.

[LeGiraffe]

The same logic could be applied to BK. While it may not be defined, BK ADC2 is solely responsible for the southern runway during PROPS. Does that mean it too gets BK-S?

My main sticking point is the question; Are we happy calling ADC1 (RW) ADC2 (Here) and vice versa?

I don't feel this one shoe fits all is the most optimal solution for clarity (for both Pilots & controllers).

[alphadelta332]

For what it's worth, I agree, and would prefer a cardinal direction designation over a 1/2 designation, where the cardinal direction is consistent and obvious. But ultimately its up to @Slep-wt

[mattk04]

I'm assuming based on the stuff here that we've decided to go down the 1/2 line but if its still up for discussion, I'd prefer cardinal direction naming too (BK-S_TWR rather than BK-2_TWR). Not a biggie though

[LeGiraffe]

PF_TWR 118.700
PF_E_TWR 124.600
(See below)

[alphadelta332]

PF_TWR 118.700 PF_E_TWR 124.600 (See below)

@Slep-wt this too

[Slep-wt]

PF_TWR 118.700 PF_E_TWR 124.600 (See below)

@Slep-wt this too

Currently we have it as PF-2_TWR as y'all know, if possible I'd like to keep it as such. In terms of denoting who owns what, editing the controller info in Positions.xml to state exactly what runways each position is responsible for would be a good way to go about it.

[LeGiraffe]

.

[LeGiraffe]

Formatting review required before proceeding.

[LeGiraffe]

@Slep-wt Got a few outstanding questions awaiting your attention before approving this

[mattk04]

Might just be a merge thing here, but I removed these location-specific examples and instead provided better examples on the linked controller skills page for Next coord. @alphadelta332 are you happy if we remove this?

changes fixed