Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metro D Dual ADCs #414

Merged
merged 21 commits into from
Mar 9, 2025
Merged

Metro D Dual ADCs #414

merged 21 commits into from
Mar 9, 2025

Conversation

alphadelta332
Copy link
Collaborator

@alphadelta332 alphadelta332 commented Dec 20, 2024

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).

@alphadelta332 alphadelta332 linked an issue Dec 20, 2024 that may be closed by this pull request
@tylerthetiletiler tylerthetiletiler added new procedures New SOPs to be added notify Send notification to Discord on merge labels Dec 22, 2024
@alphadelta332 alphadelta332 marked this pull request as ready for review December 23, 2024 04:27
@alphadelta332 alphadelta332 requested review from Slep-wt and a team December 23, 2024 04:27
@@ -21,6 +35,9 @@ BK ADC is responsible for the Class D airspace in the BK CTR `SFC` to `A015`.

Refer to [Class D Tower Separation Standards](../../../separation-standards/classd) for more information.

### Dual ADC Operations
Airspace Ownership when ADC 2 is online, is split down the middle of the **11C/29C** and **11R/29L** extended centrelines.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


#### ADC 2 Online
When ADC 2 is online, SY TCU may not be familiar with which controller owns what airspace. Best practice is to receive the coordination no matter what, and if it was meant for the other ADC controller, relay the coordination to them internally.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


### BK ADC Internal
BK ADC must heads-up coordinate **all aircraft** transiting from one ADC controller to the other.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Remember that IFR aircraft are only separated from other IFR or SVFR aircraft in class D. You should *generally* be able to issue a clearance for an approach and use other separation methods (visual separation, holding a departure on the ground) if separation is required with these aircraft.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

!!! phraseology
<span class="hotline">**BK ADC 2** -> **BK ADC**</span>: "via TWRN, EWY for an overhead join"
<span class="hotline">**BK ADC** -> **BK ADC 2**</span>: "EWY, A015"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@alphadelta332 alphadelta332 Dec 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@alphadelta332 alphadelta332 marked this pull request as draft December 23, 2024 05:28
| =2 | 26L & 26R |
| 3 | Any Single Runway Operations |

When 2 ADC controllers are online, the ATIS shall be formatted: `RWY 03R/08R/21L/26L FOR ARRS AND DEPS EAST, FREQ 118.7. RWY 03L/08L/21R/26R FOR ARRS AND DEPS WEST, FREQ 124.6`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -8,9 +8,23 @@
| Name | Callsign | Frequency | Login ID |
| ------------------ | -------------- | ---------------- | ---------------------------------------- |
| **Parafield ADC** | **Parafield Tower** | **118.700** | **PF_TWR** |
| Parafield ADC 2† | Parafield Tower | 124.600 | PF-2_TWR |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PF_TWR 118.700
PF_E_TWR 124.600
(See below)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PF_TWR 118.700 PF_E_TWR 124.600 (See below)

@Slep-wt this too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@LeGiraffe LeGiraffe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@alphadelta332 can you proof-read and fix formatting in-line with other docs on my behalf please? Delete anything that's too much or doesn't make sense.
Copy link
Contributor

@LeGiraffe LeGiraffe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting review required before proceeding.

@LeGiraffe
Copy link
Contributor

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

@mattk04 mattk04 added DO NOT MERGE This PR is not ready to be merged. Do not merge until approval from the Publications Manager. and removed Awaiting Changes Awaiting requested changes from the pull request author labels Mar 6, 2025
Comment on lines 209 to 218
!!! phraseology
<span class="hotline">**CG ADC** -> **BAC**</span>: "Next, CBN, runway 14"
<span class="hotline">**BAC** -> **CG ADC**</span>: "CBN, heading 030, unrestricted"
<span class="hotline">**CG ADC** -> **BAC**</span>: "Heading 030, CBN"

**CG ADC**: "CBN, Assigned heading left 030, Runway 14, Cleared for Takeoff"
**CBN**: "Left heading 030, Runway 14, Cleared for Takeoff, CBN"

The BN TCU controller can suspend/resume Auto Release at any time, with the concurrence of **CG ADC**.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@alphadelta332 alphadelta332 removed the DO NOT MERGE This PR is not ready to be merged. Do not merge until approval from the Publications Manager. label Mar 6, 2025
@mattk04 mattk04 self-requested a review March 9, 2025 03:26
Removes example as per previous PR
@alphadelta332 alphadelta332 merged commit 1988848 into main Mar 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new procedures New SOPs to be added notify Send notification to Discord on merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Addition of Class D Secondary Tower Positions (AIRAC 2412)
7 participants