Jump to content

David Z - 1027224

Members
  • Posts

    3119
  • Joined

  • Last visited

  • Days Won

    31

Posts posted by David Z - 1027224

  1. Sean, the basis of your argument is that there are two situations: events where there are high traffic volumes and outside of events where traffic volumes are low. If this were true, I would agree with your points completely.

     

    However, there is an in between: situations like Milk Run as well as some non-official times when traffic volumes are sufficient to warrant sectors that are not so large. This not only covers ML-SY in the Milk Run case but also for Spilled Milk Runs and sometimes for Australia Online, etc. In these cases, it is not appropriate to increase complexity by adding non-standard sectors into the mix. Ad-hoc non-standard sectors should be avoided where possible as the lack of procedures and familiarity can quickly create confusion in high traffic volumes and this balance must be struck when a C3 or staff member authorises their use.

     

    It has therefore been the case for many years that our sectors are arranged in three tiers. Our standard sectors are designed around our higher traffic scenarios outside of major events (you could call this the 99th percentile traffic). They serve us well in all situations outside of major events and our familiarity with them makes it easier for us to handle busy Monday nights and also to adapt to non-standard sectors when they are required. Outside of our peak times, the sector extension procedure allows a single controller to take a larger chunk of airspace and serve more pilots. During major events, the events and operations teams carefully evaluate expected traffic volumes and controller workload and make judicious use of non-standard sectors. Procedures for the use of the non-standard sectors are developed and documented and controllers briefed to ensure that confusion and misunderstanding do not compromise the effectiveness of the non-standard sectors as a workload management measure.

     

    I offer two arguments in relation to putting TMAs on sector boundaries. First, it allows a controller on a busy night who is stretched a bit thin to focus only on event arrivals and not arrivals from other directions. For example, on a Milk Run, excluding YWE and WON from SNO would mean that the SNO controller does not need to cover arrivals from Adelaide, Brisbane and Tasmania. The second is that when traffic is light and it is desired to provide top-down coverage to the TMA, the controller may extend to the adjacent sector and cover all inbound traffic and therefore there is no issue with missing a wedge of the arrival traffic and needing to pick them up shortly prior to the TMA boundary.

  2. Might I suggest this one as a variation...

     

    - Maintains the ISA sector shape, a conscious decision back in the day by Greg Wilson so that there were clear SY-CS sectors (whereas ISA covers south-east Asia/Darwin flights)

    - Puts GTH and KAT back into BKE... particularly with KAT, this avoids having both BIK and BKE online to cover SY-AD and SY-PH flights. When BIK is broken out into a separate arrivals sector, it means that you don't have to create another one west of it to ensure that BIK can focus on arrivals without dealing with SY departures via KADOM (formerly KAT).

    - Restores the multiple arrival sectors for AD, ML and BN. This eliminates the need to necessarily activate SNO (either with a separate controller or by extending) for ML-AD and ML-HB/LT events. In those events, only TBD or TAS (as the case may be) would be required (extending is still possible, of course, but is not necessary if workload increases).

     

    There was a brief discussion about "streaming" earlier - I guarantee every C1+ controller has heard of this technique and if not, you clearly weren't paying attention in your training! We don't use the term "streaming", but it is simply the process of applying (say) 20 miles between successive arrivals. That is all that is required under normal traffic loads even with aircraft coming in from multiple directions. No need to coordinate between arrival sectors or muck around with FF times, etc.

     

    a89cda0040.png

  3. ATIS is different to controller info. ATIS refers to the separate connection that you make as xxxx_ATIS.

     

    Your controller info doesn't need to be replicated in the voice ATIS. However, the text ATIS and voice ATIS must have substantially the same information.

  4. Arrival sectors should not need to coordinate with each other. The sequencing of arrivals occurs either with or without Flow.

     

    Without Flow, arrival sectors should apply "streaming" (this is AsA terminology that we have not adopted). "Streaming" is when you simply apply a fixed number of miles-in-trail or minutes-in-trail between successive aircraft on the same stream (you could say that all aircraft via a feeder fix constitute a "stream"). The 20 NM-in-trail parameter that we have always used is more than adequate for situations where Flow is not employed. This requires no coordination between arrival sectors and the only coordination required would be from the Approach controller if the "in-trail" parameter needs to be adjusted.

     

    With Flow, obviously the Flow controller determines feeder fix times and the arrival sectors only need to comply with those times.

     

    In any case, it is important to realise that the sequence is owned by the TMA not enroute. While enroute applies spacing between successive arrivals by default, it is up to the TMA to look forward and determine whether there are any necessary changes to the status quo.

  5. There are certainly a few on the market that can do DME arcs (another one is the Aerosoft A320), but I'm not sure I've seen any that do radius legs (which are identical, except that the parameters on which the arc is defined are different).

  6. I haven't tried, but can anyone advise whether the Q400 or at least Majestic's rendition is actually capable of flying radius legs?

     

    The typical situation is that flight sim aircraft are not capable of flying so called "RF" or radius legs where the aircraft is to fly between to fixes via a radius arc around an arbitrary point. This applies even to PMDG aircraft, and for some reason, PMDG refuse to change their navdata format to support the encoding of such legs despite their proliferation around the world.

     

    The general rule of thumb has been to stick to the RNAV X Y and Z approaches as these don't have radius legs.

  7. I have argued against this arrangement from the start.

     

    There is a principle that sectors should be roughly (very roughly) square in shape so that they actually fit on the screen without zooming out excessively. In our case, since many of us use 16:9 screens rather than 1:1, some elongation east-west is more than acceptable. But such an extreme north-south elongation means that either- the controller is zoomed way out to fit on the screen that Sydney arrivals become very clumped together and it is difficult to judge distances; or the screen is zoomed into Sydney arrivals and massive parts of the sector are off-screen.

     

    Also agree with Sean on arranging sectors to suit traffic patterns. Our former arrangements worked extremely well day-to-day and proved themselves during events that excluded non-standard positions. The recent PS Adelaide showed that excessively workload was placed on the arrival sector controller because his airspace was not set up to divide workload appropriately. I would suggest that even if we keep our current subsectors, that action be taken to adjust the main sectors to line up more with our old sectors, at least from Cairns to Adelaide; the north and west should be designed to suit typical event flows and around Perth, be arranged similar to east coast airports, that is, with multiple arrival sectors.

     

    There should also be consideration given to modifying or abolishing the "FIFO" subsectors in the west (under ORE). We are unlikely to ever see FIFO-like traffic patterns and instead when we have an event to a regional airport the traffic pattern is similar to a major airport. That demands an typical arrival sector of 120-150 miles, but the existence of the subsectors may cause reluctance in event planners and operations staff to deviate from the subsectors, even if they are inappropriate for the event.

     

    I note that in the past, special event sectors were NOT real world sectors. An assessment was made on what special sectors were needed THEN real world sectors were looked at for inspiration. Clearly for major airports, the real world arrangements are likely to be suitable. However, when we have planned for events like Worldflight where massive arrivals and departures are expected into regional airports, it is better to have a custom design. A typical design we used was to have an arrival sector of about 120-150 miles and divide the TMA airspace by drawing an appropriate line across it.

  8. On behalf of the ATC Training Team, I would like to wish all members a happy Christmas and a safe festive season.

     

    Our ATC Training Team perform an enormously important task and do so entirely with their generously donated time. So it is traditional for us to express our gratitude to them by giving them a couple of weeks off to enjoy family, friends and VATSIM.

     

    ATC Training will be closed from 21 December 2017 and will reopen on 8 January 2018.

     

    During this time, there will be no new theory exam passwords given out, no exam results processed and no additional arrangements will be made for official mentoring or practical assessments (existing arrangements will of course be honoured).

     

    If you feel you are nearing completion of your selfdirected study, please consider using these 2 weeks as an opportunity to read over those tricky subjects again and we will be happy to serve you in the new year.

  9. I note that a similar policy is applied to other procedures which are day/night dependent, for example, clearance below LSALT, visual definite passing separation standards and runway selection at some airports.

     

    It is also interesting to note that the official delineation between day/night is based on civil dawn/dusk, the times for which can be found on NAIPS and Geoscience Australia.

  10. A and B are both acceptable as are solutions put by Josh. C and D don't provide separation assurance.

     

    One of the rules of separation assurance is that you must place a control measure in place to ensure separation until you can be certain of achieving another standard. For example, you can assign non-conflicting levels to guarantee vertical separation until you can be certain that radar separation can be achieved.

     

    Personally I would takes Josh's option 2 and decide whether vectoring or rerouting is necessary once departures have become airborne. With a tower online, it is appropriate to put a standing agreement that all departures are to "maintain 4000 until further notice".

     

    The vectoring option could be implemented by agreeing with tower to clear all departures via "ML4, left/right heading xxx, unrestricted" but this is a bit trickier and depends on the track of the aircraft. You also have to keep in mind that radar separation is not applicable until identification and so this could result in a loss of separation assurance if applied incorrectly.

  11. Yes but there are always exceptions to the rule. One example is that aircraft of foreign governments ("state aircraft") are not required to have RVSM. It is also possible for a failure or degradation of aircraft systems in-flight to render an aircraft no longer RVSM capable.

  12. I believe that we put it on controllers to make a judgement on this.

     

    The reality is that most sims do not simulate altimeter error - observe that on your PMDG aircraft, at high altitude, the uncorrected standby altimeter shows the same altitude as the PFD which shows corrected altitude.

     

    That being said, if you are flying a historical aircraft or one that does not frequently cruise in the RVSM band in real world service, it may be more realistic to treat it as non-RVSM.

  13. Hi Nathan,

     

    You probably would have guessed this, but what you are proposing goes beyond "normal" and this is where divisional-level staff would have to tread carefully as there is little-to-no guidance from above. Contrary to the "god-like" comments, we cannot approve things willy nilly :)

     

    This is not my area to look after, but taking off my director hat, this is some advice based on my experiences.

     

    You are best served to get in touch with the Director Operations, which is currently Arjun, and discuss with him some ways to get the broad strokes of your idea implemented in a way that is acceptable to VATSIM.

     

    Some things that are unlikely to be accepted include:

    • Double connections
    • Observers doing more than observing or spending excessive amounts of time doing so
    • "Fake" ATC positions - an ATC position should provide air traffic services to all aircraft that request it within the area of responsibility for that position

     

    While it is not for me to make that determination, I would put to you that it is unlikely that an AEWACS or refueller would be acceptable as an ATC position.

     

    A possible solution that you may consider/tweak and put to Arjun for consideration is:

    • have your AEWACS be in contact with ATC via TeamSpeak
    • ATC hands over the airspace to the AEWACS
    • coordination between AEWACS and ATC (for the purposes of issuing airways clearances, etc) is done by TeamSpeak
    • ATC denies clearance to non-participating aircraft on the basis of separation and if the pilot insists on flying his planned route, notifies AEWACS of the aircraft and its intentions (although I note that it has been RAAFv's practice to cease operations to allow transiting aircraft to pass rather than prevent access to the airspace)
    • participating aircraft contact AEWACS via TeamSpeak or other communications platform (i.e. other than via VATSIM voice)
    • AEWACS monitors air situation via alternate "scope" software (i.e. other than connecting to VATSIM with a controller client)

  14. ATC do not provide services inside airspace designated as "military flying training". Coordination of this airspace is done by the likes of 3CRU and squadrons operating AEWACs.

     

    For "military control areas", air traffic services (usually Class C) are provided by RAAF ATC. For example, the airspace above the Tindal military control zone would presumably be managed by Tindal Approach.

  15. Guys, let's calm down a bit. As much as we love Teamspeak, keep in mind that at one stage VATPAC management believed that it was more trouble than it was worth. While I was a big advocate for it at the time, let's remember that it is very much a bonus feature and its unavailability doesn't stop anyone from flying or controlling. While this is certainly the venue for airing grievances (and I would encourage that), let's be respectful of other staff members.

     

    Public notices were made on the forums (and elsewhere I believe) and our volunteer staff fixed it within about 24 hours, despite being away from their usual setups.

     

    That being said, if you have any ideas on ways we can fail-proof our systems, this is a great venue to share :)

  16. The Board attempted to address the conflicts on interest, but as I had stated yesterday, the arrangements we had put in place were inadequate and need improvement in future.

     

    Zach, I will not address the allegations you have raised as I have not been given any details nor would this be the right venue to discuss them. In fact, if there are allegations against the division director, they should be addressed to the VP Regions standing in for the regional director. That being said, I am happy to assist as a neutral party if anyone needs assistance to do this.

  17. Going back through my correspondence records, I note the first time the Alice idea was discussed was way back before the previous Board walked out.

    Just sayin.

     

    Very interesting, I don't remember discussing this.... @David Zhong Can you confirm that you were aware of this and approved this within VATPAC Airspace.

     

    Paul and others,

     

    I refer you to the Q3 meeting minutes where we had made our governance arrangements in relation to WorldFlight. It was noted that Tracy, Browny and Arjun had interests with WorldFlight and they had therefore removed themselves from the decision-making process from VATPAC's end. Callum and the events portfolio had been appointed to represent VATPAC's interests in discussion with WFHQ.

     

    I will not use hindsight to judge the actions of others in implementing these procedures, however it has become apparent to me that these governance arrangements have not stood up to the test. I will be discussing these with the Board as there is certainly room for improvement in the way in which we interact with WorldFlight and some of you (e.g. Greg) would be aware that this has been an area of difficulty for VATPAC for many years.

  18. Well you can disregard those things for a hypothetical discussion but you can't disregard them if you are planning on actually doing this. If AYPM is in a separate sector file, then you can't extend. And private sector files have never been condoned because they create a data consistency risk.

  19. Hi Nathan, while I appreciate that RAAFv are putting together what will hopefully be a great resource, I hope you can understand that we have a strong interest in ensuring that the information that people are getting is correct and in line with our "realism settings". It has certainly been the experience in some areas in the past that conflict has arisen due to overzealous controlling and we want to ensure that any material that is used doesn't inadvertently empower people to do things that we all know they shouldn't do.

  20. Hi Nathan,

     

    Could I request that VATPAC be given an opportunity to review the content to ensure that the material being delivered is consistent with our policies and procedures (e.g. MATS)?

     

    I would also note that FAC and battlespace control functions fundamentally have different goals to ATS. The only real similarity is that they both manage airspace.

×
×
  • Create New...