VATUSA Traffic Management Unit: Launch

Evan Reiter

  • Instructors
  • 108
    • View Profile
    • Boston Virtual ARTCC
VATUSA Traffic Management Unit: Launch
« on: August 28, 2020, 06:35:53 AM »
I didn't see a thread here with discussion on the new VATUSA Traffic Management Unit so I thought I would make one.

In this post, I'm advocating that OPLEVEL3 needs to be re-thought and either be:
1. Scaled back significantly if it's going to apply to all FNOs
2. Re-defined to only apply to larger, 3+ ARTCC FNOs

I'm not ARTCC staff so perhaps there's a discussion I've missed. Specifically, I wanted to know if there has been any discussion from ARTCCs about some of the staffing requirements. From reading the PDF, it seems to me that VATUSA expects (or, at least wants) Tier 1 facilities to staff a dedicated TMU position any time there is a neighboring event (Page 18). Using the sample ZTL FNO that's described, that would mean Indy, Washington, Memphis, Jacksonville, and Houston would all be expected to staff not only Center but ALSO TMU. And then beyond that, there are going to be two representatives from the "national" level. That means we are going to go from having 0 required TMU controllers today to having 8 dedicated TMU positions. Doesn't that seem like a pretty big jump?



How many of our events really go that far "down the tubes" that 8 dedicated people are required to work TMU? As of today, I'd just be happy to have each of my neighboring facilities staffed with 1 controller!

Later in the document, using the same example, it says USA96 would cover the TMU function for facilities "where staffing isn't available". That seems to imply a facility should be trying to cover TMU. Speaking for myself, not as ARTCC staff, I would not feel comfortable assigning a controller to work a TMU position to support a neighbor's event. That is going to be a very boring 4-5 hours for whoever gets that assignment. Having worked plenty of "support" for neighbor ARTCCs, I can say that almost never does ZDC traffic get overwhelming for us to manage. Every now and again a ZNY event gets busy (because of the popularity of New York airports) but in those scenarios, we would much rather split Center than have one person working TMU watching the Center controller drown in managing the holding stack. 

Expecting someone to "sit and watch" on TMU during a ZDC FNO is unrealistic and disrespectful. I can't imagine anyone wanting to do that on a regular basis.

Particularly if the limit on the centralized training program for TMU controllers is a maximum of 6 per facility, it seems there will be a challenge to find certified individuals who want to do this work.

Similarly, asking all Tier 1's to attend a meeting the night before an FNO seems a little over the top. You're going to take about 10 people away from potentially controlling on-network for a planning meeting. Again, I wonder how necessary this is, or if some of this could just as easily be managed via a Discord discussion the evening before.

I know we're striving for realism in our operations but not every FNO is CTP. I suspect if you did a poll of VATUSA controllers, you'd find that only a few really are interested in TMU as a subject area (if they have done 1-2 events as a TMU before; it does seem interesting before you do it the first time). ZBW has historically staffed a TMU during any of what you're calling "OPLEVEL4" events: Cross the Pond, Boston Tea Party, etc. Everyone who has ever done it hates the fact that they have to effectively sit out the event and not control. We rotate it and live with it because, during those events, it's a necessary evil. But I can't see how that's justifiable while we're called to staff up for a neighbor's FNO.

The overall theme of this post is: this should be fun, for us and the pilots. There's a risk to layering the TMU stuff on so thickly the enjoyment a pilot gets in flying in this airspace becomes diminished. Yes, sitting on the ground is better than holding in the air. But there's a risk we start creating significant ground delays and no lineup at the other end. I think most pilots would prefer to fly to a busy, but manageable, airspace than to wait for 20 minutes and have a completely quiet arrival experience. Likewise, a lot of controllers do this because they enjoy the experience. Let's not take that away by mandating TMU time. I'd much rather spend an evening controlling on-network than participating in an hour-long planning meeting with a neighbor two doors down, particularly when I'm probably only going to work 20 of their airplanes.

There are absolutely, without question, some airports and some events that require a concerted TMU effort, particularly with the increases in traffic we have seen lately. For "OPLEVEL4" events...sure, let's have a TMU rep from each facility that's participating (as we've always done with CTP). But expecting or even asking ZBW to staff two separate Center-rated controllers, one to work traffic and a second to be TMU, for a ZDC event, is ridiculous.

There are good concepts here and many of them would be strong additions to the event lineup. But I challenge you to explain what problem you are really trying to solve when you say that two people, a Center and a TMU, are going to be requested from every Tier 1 for every FNO. I would advocate for removal of the OPLEVEL3, scaling it back significantly if it is going to apply to FNOs, or only categorizing some larger FNOs (like those involving 3+ ARTCCs as event facilities) as OPLEVEL3 and then leaving others as OPLEVEL2. Regardless, there should not be a requirement or expectation for neighbors to provide TMU staffing or pre-event discussion for a simple, single-airport FNO. Let's focus on getting the neighbors staffing their airspace first.
« Last Edit: August 28, 2020, 06:47:32 AM by Evan Reiter »

Matt Bromback

  • ZJX Staff
  • 235
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #1 on: August 28, 2020, 06:51:36 AM »
Excellent questions asked Evan. I agree with you 100%

Lets be honest with ourselves here...TMU won't really fix anything if ARTCC's don't have the staffing, or the proper training, or poorly designed events. I have seen time and time again ARTCC's staff up for a bordering FNO and even with 3 to 4 controllers still go down the tubes because the controller(s) working the traffic were not trained properly on those type of traffic levels. Conversely I have seen ARTCC's plan and host events into airports that the AAR is so low that FNO level traffic is nearly impossible to fit in there.

I think overall a TMU program is great to have for VATUSA but take it with a grain of salt. Much better time and resources should be spent helping the ARTCC's deal with staffing, training issues and event planning. Perhaps a one or 2 man national TMU person can oversee an entire event such as FNO, big picture eyes on the system type of thing.

Jeremy Peterson

  • Members
  • 250
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #2 on: August 28, 2020, 08:52:36 AM »
1.
2. Re-defined to only apply to larger, 3+ ARTCC FNOs
It is this way, without the "larger" modifier:
Quote
This level is activated for all events or operations requiring coordination involving more than two ARTCCs, including the host
ARTCC (i.e. FNO).

2.
I wanted to know if there has been any discussion from ARTCCs about some of the staffing requirements. From reading the PDF, it seems to me that VATUSA expects (or, at least wants) Tier 1 facilities to staff a dedicated TMU position any time there is a neighboring event (Page 18).
Yes we've had discussions about this very thing. I think the important principle to be understood here is that all facilities must first perform their 7110.65 2-1-1.b.1 duties: "[Provide] a safe, orderly, and expeditious flow of air traffic" before addressing their TMU duties. Now, that being said, facilities should absolutely be thinking about incorporating a dedicated TMU into their event schedules--particularly for the bigger events--but the actual execution of that is up to the facilities.

As far as the logic behind staffing for our neighbors is multi-faceted and I refer you back to slide 12 of the VATUSA TMU Roadmap ("Responsibilities").

3.
That means we are going to go from having 0 required TMU controllers today to having 8 dedicated TMU positions. Doesn't that seem like a pretty big jump?
Until now, we have absolutely no requirement for staffing TMU positions during events. However, in the past six months or so, numerous facilities (in varying levels of coverage) have been providing TMU positions. Particularly, I explicitly remember ZJX, ZMA, ZTL, ZDC, ZNY, ZLC, and ZDV having staffed at least one TMU position during a busy event in the recent past. Not only can it be done, but it should be done, again referring you back to slide 12.

4.
How many of our events really go that far "down the tubes" that 8 dedicated people are required to work TMU?
I would say enough to warrant a division-level TMU program. As an example, the PHL FNO in March 2020 used multiple facility level TMU positions (e.g., ZNY Enroute Coordinator, ZNY Arrival Coordinator, N90 Departure Coordinator, etc.). Even then, ZNY would've greatly benefited from a division-level Command Center to handle the influx of southeast and Midwest traffic that was outside the immediate purview of ZNY.

5.
Later in the document, using the same example, it says USA96 would cover the TMU function for facilities "where staffing isn't available". That seems to imply a facility should be trying to cover TMU...I would not feel comfortable assigning a controller to work a TMU position to support a neighbor's event. That is going to be a very boring 4-5 hours for whoever gets that assignment.
Facilities should now begin to think about the best ways to incorporate TMU into their event schedules. If you have absolutely no candidates who are willing to be available for coordination, maintaining facility-level situational awareness, anticipating traffic impacts, and performing required reporting, then by all means, the wording is there to allow the Command Center to help augment your availability to those resources. Will the Command Center ever make a decision for you without your facility's input? No. Will the Command Center coordinate with your facility to make sure TMU duties (whatever level appropriate for said situation) are being performed and objectives met? Yes, collaboratively.

6.
[If] the limit on the centralized training program for TMU controllers is a maximum of 6 per facility, it seems there will be a challenge to find certified individuals who want to do this work.
The reason for this is so we can actually train people at a reasonable pace. We don't have the resources to train everybody who wants to participate all at once.

7.
[Asking] all Tier 1's to attend a meeting the night before an FNO seems a little over the top. You're going to take about 10 people away from potentially controlling on-network for a planning meeting. Again, I wonder how necessary this is, or if some of this could just as easily be managed via a Discord discussion the evening before.
There are benefits to doing it over voice because it can happen quickly and there's less wait for typing and reading. Like in the real world, the conferences take as long as they need to get the important information across. If there's lots of route coordination that needs to go on, maybe it'll take 10 or more minutes. If there's severe clear, the call could take literally 30 seconds. Further, the goal is to have planning constantly ongoing so by the time the final planning telcon comes up the night before or night of, all goals (strategic and operational) should be clear to the point where these telcons are just routine, in a way. Either way, the coordination, collaboration, and communication are the three pieces Command Center is requesting facilities participate in.

8.
I know we're striving for realism in our operations but not every FNO is CTP. I suspect if you did a poll of VATUSA controllers, you'd find that only a few really are interested in TMU as a subject area (if they have done 1-2 events as a TMU before; it does seem interesting before you do it the first time). ZBW has historically staffed a TMU during any of what you're calling "OPLEVEL4" events: Cross the Pond, Boston Tea Party, etc. Everyone who has ever done it hates the fact that they have to effectively sit out the event and not control. We rotate it and live with it because, during those events, it's a necessary evil. But I can't see how that's justifiable while we're called to staff up for a neighbor's FNO.
It is my personal understanding that there are members who are willing or at least interested in the TMU functions in all facilities. Of course, I don't necessarily know who those people are but my suspicion is that they exist. Anywho, I refer you back to the Purpose and Responsibilities slides of the Command Center (slides 9 & 10) and also the Responsibilities slide for the facilities (slide 12).

9.
The overall theme of this post is: this should be fun, for us and the pilots. There's a risk to layering the TMU stuff on so thickly the enjoyment a pilot gets in flying in this airspace becomes diminished. Yes, sitting on the ground is better than holding in the air. But there's a risk we start creating significant ground delays and no lineup at the other end. I think most pilots would prefer to fly to a busy, but manageable, airspace than to wait for 20 minutes and have a completely quiet arrival experience. Likewise, a lot of controllers do this because they enjoy the experience. Let's not take that away by mandating TMU time. I'd much rather spend an evening controlling on-network than participating in an hour-long planning meeting with a neighbor two doors down, particularly when I'm probably only going to work 20 of their airplanes.
These are all genuine concerns and frankly, we won't know the full implications of implementing the TMU program until it has been tried, tested, reviewed, the whole process. The foundation for this program is to execute 7210.3BB 18-1-1 by providing a division-level platform for communication, collaboration, and coordination between facilities (including the Command Center).

In summary, I want to urge all readers of these documents to remind themselves that the Command Center is not going to be a regulatory body, it is not going to mandate orders (unless there is a TMU-related disagreement between ARTCCs that cannot be settled themselves), and it is going to do its best to include all relevant facilities in the collaborative decision making (CDM) process. Evan, we appreciate the feedback! But, in order for this to work, we need to work with the facilities. Bottom line is, if we simply implement a program at the top and don't have some changes in how the facilities operate, then what we'd actually accomplish is a disconnect between the division and the facilities. Currently, there isn't always someone to communicate to during an event about routing, restrictions, or any other relevant factors. But if we want to address the traffic management problem, we need to start with having people who can communicate for their facilities and people who will coordinate with others.

If you want to talk with the team at any time, please reach out!
« Last Edit: August 28, 2020, 09:08:56 AM by Jeremy Peterson »

Evan Reiter

  • Instructors
  • 108
    • View Profile
    • Boston Virtual ARTCC
Re: VATUSA Traffic Management Unit: Launch
« Reply #3 on: August 28, 2020, 09:51:18 AM »
1.
2. Re-defined to only apply to larger, 3+ ARTCC FNOs
It is this way, without the "larger" modifier:
What I mean is that, if you are going to keep the requirements of OPLEVEL3 the same, effectively encouraging a dedicated TMU at each Tier 1 and saying each Tier 1 has to be involved in pre-event meetings, you should limit OPLEVEL3 events to those that advertise multiple ARTCCs like the ZAB/ZFW/ZME Trifire in October that has one major airport in each ARTCC. However, the example in the slides is a ZTL FNO, which has one airport advertised in one ARTCC.

I'm proposing that an FNO advertising one airport in one ARTCC should be classified as OPLEVEL2 or we should consider reducing the requirements of OPLEVEL3 so each FNO doesn't become a massive burden, not just on the host facility but on each of their Tier 1's. Imagine being Memphis Center. The staff of ZME are going to have to give up not just their Friday but also their Thursday nights any time an FNO or other single-airport event is held in Indy, Atlanta, Houston, Fort Worth, or Kansas City. That could easily happen 3 out of 4-5 weeks and thus represent a significant impact for their staff.

(During COVID and/or for airports like ATL that tend to be very popular, you might make the odd FNO an OPLEVEL3 event. But I would advocate against this becoming the standard unless you reduce the workload burden on neighbor facilities.)

However, in the past six months or so, numerous facilities (in varying levels of coverage) have been providing TMU positions. Particularly, I explicitly remember ZJX, ZMA, ZTL, ZDC, ZNY, ZLC, and ZDV having staffed at least one TMU position during a busy event in the recent past.
Totally agree; I'm in favor of the majority of what you've got in the slides. ZBW has been staffing TMU since before I joined VATSIM too. It's a great resource for us, when the operational conditions dictate.

There are benefits to doing it over voice because it can happen quickly and there's less wait for typing and reading.
From a visibility perspective, I hope you're planning to use the regional channels in the vATCSSC Discord to manage pre-event communications (as we've been informally doing for past events). That way, each neighboring airspace can be kept in the loop about discussions. Maybe it's a matter of having the initial discussion via text with the option for a call and/or voice meeting as needed. Speaking from a ZBW perspective, it's truly hard to imagine a scenario where I would need to have a voice discussion with ZOB for a standard FNO featuring KBOS in non-COVID times. Again, I don't want every FNO to become CTP. The traffic (in regular times) doesn't warrant it. You may also want to think about how you schedule the pre-event meeting. That should, at minimum, be established in the staffing request 3-4 weeks out. Saying to people "hey, let's meet tomorrow night" doesn't always work for those of us who don't have a 9am-5pm work schedule (or even for those who do). Then, you have your discussions via Discord 3-7 days out and the day before, people can decide if the scenario warrants a voice call or not. From a ZBW perspective, very few of our events would. That likely is different in other regions where there is more inter-ARTCC collaboration required.

Currently, there isn't always someone to communicate to during an event about routing, restrictions, or any other relevant factors. But if we want to address the traffic management problem, we need to start with having people who can communicate for their facilities and people who will coordinate with others.
We should absolutely make this a requirement but it should be left for discretion as to whether a dedicated position is required or whether this can be managed by a controller who is working traffic. Yes, I realize it's much better to have a dedicated person in real life. And if you want to pay the same salary FAA TMU operators received, I'm game! When it warrants, have a dedicated position. But when it doesn't warrant, you should come up with a standard of identifying which active controller from the facility is "in charge" from a TMU perspective. I don't know if that's a _T_ in their callsign (not ideal for position swaps) or some kind of identification in Discord (like changing nicknames?). However you do it, identifying "the person" to talk to during an event (or heck, even during non-event scenarios) would be a valuable addition to our standard cross-ARTCC communication practices.

For example, in ZBW we define a CIC. In regular operations, that's the highest-level controller for the facility (so, ZBW). During an event when split Centers are in play, we'll always identify which of them is the CIC. I'm sure it would help neighbors to have a quick resource knowing which of the staffed Center controllers is the best person to contact for general cross-ARTCC questions.

Ryan Geckler

  • Mentors
  • 453
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #4 on: August 28, 2020, 10:44:01 AM »
Before I go through the replies, I do want to make a quick clarification on all of this:

None of what was in the slides is final - it was merely a first draft designed to get conversation going between staff members about how to attack this issue. Changes are always an option and feedback is highly encouraged to myself, my team, and the rest of USA staff. Like was said in the meeting last week - we are here to help you guys succeed in your event.

1.
2. Re-defined to only apply to larger, 3+ ARTCC FNOs
It is this way, without the "larger" modifier:
What I mean is that, if you are going to keep the requirements of OPLEVEL3 the same, effectively encouraging a dedicated TMU at each Tier 1 and saying each Tier 1 has to be involved in pre-event meetings, you should limit OPLEVEL3 events to those that advertise multiple ARTCCs like the ZAB/ZFW/ZME Trifire in October that has one major airport in each ARTCC. However, the example in the slides is a ZTL FNO, which has one airport advertised in one ARTCC.

I'm proposing that an FNO advertising one airport in one ARTCC should be classified as OPLEVEL2 or we should consider reducing the requirements of OPLEVEL3 so each FNO doesn't become a massive burden, not just on the host facility but on each of their Tier 1's. Imagine being Memphis Center. The staff of ZME are going to have to give up not just their Friday but also their Thursday nights any time an FNO or other single-airport event is held in Indy, Atlanta, Houston, Fort Worth, or Kansas City. That could easily happen 3 out of 4-5 weeks and thus represent a significant impact for their staff.

The Command Center will provide staffing if none is available - the reason we've initially determined that this is the best way forward is because of local knowledge of the airspace and what works for your facility. I have no idea what best practices are at ZME, so I want to rely on someone that is familiar and can tell me why my idea is bad and we should do this other plan. Eventually, we'll have put together a "playbook" of sorts where we can make better informed decisions about what to do when a scenario pops up, but if something out of the ordinary occurs, we want that local person there to tell us what they think is best so we can evaluate our decision from a national level.

There are benefits to doing it over voice because it can happen quickly and there's less wait for typing and reading.
From a visibility perspective, I hope you're planning to use the regional channels in the vATCSSC Discord to manage pre-event communications (as we've been informally doing for past events). That way, each neighboring airspace can be kept in the loop about discussions. Maybe it's a matter of having the initial discussion via text with the option for a call and/or voice meeting as needed. Speaking from a ZBW perspective, it's truly hard to imagine a scenario where I would need to have a voice discussion with ZOB for a standard FNO featuring KBOS in non-COVID times. Again, I don't want every FNO to become CTP. The traffic (in regular times) doesn't warrant it. You may also want to think about how you schedule the pre-event meeting. That should, at minimum, be established in the staffing request 3-4 weeks out. Saying to people "hey, let's meet tomorrow night" doesn't always work for those of us who don't have a 9am-5pm work schedule (or even for those who do). Then, you have your discussions via Discord 3-7 days out and the day before, people can decide if the scenario warrants a voice call or not. From a ZBW perspective, very few of our events would. That likely is different in other regions where there is more inter-ARTCC collaboration required. [/quote]

We will be using the vATCSCC discord quite heavily, especially in the preplanning phase of the event, as well as during the event for tactical communication between facilities. The 24 hr out meeting, like Jeremy said, will be short (nothing like CTP route meetings :D) and may not even need to occur on voice if everyone's happy with the plan that was put in place during the week.

Currently, there isn't always someone to communicate to during an event about routing, restrictions, or any other relevant factors. But if we want to address the traffic management problem, we need to start with having people who can communicate for their facilities and people who will coordinate with others.
We should absolutely make this a requirement but it should be left for discretion as to whether a dedicated position is required or whether this can be managed by a controller who is working traffic. Yes, I realize it's much better to have a dedicated person in real life. And if you want to pay the same salary FAA TMU operators received, I'm game! When it warrants, have a dedicated position. But when it doesn't warrant, you should come up with a standard of identifying which active controller from the facility is "in charge" from a TMU perspective. I don't know if that's a _T_ in their callsign (not ideal for position swaps) or some kind of identification in Discord (like changing nicknames?). However you do it, identifying "the person" to talk to during an event (or heck, even during non-event scenarios) would be a valuable addition to our standard cross-ARTCC communication practices.

For example, in ZBW we define a CIC. In regular operations, that's the highest-level controller for the facility (so, ZBW). During an event when split Centers are in play, we'll always identify which of them is the CIC. I'm sure it would help neighbors to have a quick resource knowing which of the staffed Center controllers is the best person to contact for general cross-ARTCC questions.
[/quote]

CICs are great for internal issues, but when it comes to external issues, I think a TMC is needed solely for routing, flow programs, and general cross-ARTCC coordination.

Again, like I said at the top, nothing here is final and I want to keep this discussion going to help us pave the way forward.

Ryan Geckler

  • Mentors
  • 453
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #5 on: August 28, 2020, 10:46:47 AM »
Before I go through the replies, I do want to make a quick clarification on all of this:

None of what was in the slides is final - it was merely a first draft designed to get conversation going between staff members about how to attack this issue. Changes are always an option and feedback is highly encouraged to myself, my team, and the rest of USA staff. Like was said in the meeting last week - we are here to help you guys succeed in your event.

1.
2. Re-defined to only apply to larger, 3+ ARTCC FNOs
It is this way, without the "larger" modifier:
What I mean is that, if you are going to keep the requirements of OPLEVEL3 the same, effectively encouraging a dedicated TMU at each Tier 1 and saying each Tier 1 has to be involved in pre-event meetings, you should limit OPLEVEL3 events to those that advertise multiple ARTCCs like the ZAB/ZFW/ZME Trifire in October that has one major airport in each ARTCC. However, the example in the slides is a ZTL FNO, which has one airport advertised in one ARTCC.

I'm proposing that an FNO advertising one airport in one ARTCC should be classified as OPLEVEL2 or we should consider reducing the requirements of OPLEVEL3 so each FNO doesn't become a massive burden, not just on the host facility but on each of their Tier 1's. Imagine being Memphis Center. The staff of ZME are going to have to give up not just their Friday but also their Thursday nights any time an FNO or other single-airport event is held in Indy, Atlanta, Houston, Fort Worth, or Kansas City. That could easily happen 3 out of 4-5 weeks and thus represent a significant impact for their staff.

The Command Center will provide staffing if none is available - the reason we've initially determined that this is the best way forward is because of local knowledge of the airspace and what works for your facility. I have no idea what best practices are at ZME, so I want to rely on someone that is familiar and can tell me why my idea is bad and we should do this other plan. Eventually, we'll have put together a "playbook" of sorts where we can make better informed decisions about what to do when a scenario pops up, but if something out of the ordinary occurs, we want that local person there to tell us what they think is best so we can evaluate our decision from a national level.

There are benefits to doing it over voice because it can happen quickly and there's less wait for typing and reading.
Quote from: Evan Reiter
From a visibility perspective, I hope you're planning to use the regional channels in the vATCSSC Discord to manage pre-event communications (as we've been informally doing for past events). That way, each neighboring airspace can be kept in the loop about discussions. Maybe it's a matter of having the initial discussion via text with the option for a call and/or voice meeting as needed. Speaking from a ZBW perspective, it's truly hard to imagine a scenario where I would need to have a voice discussion with ZOB for a standard FNO featuring KBOS in non-COVID times. Again, I don't want every FNO to become CTP. The traffic (in regular times) doesn't warrant it. You may also want to think about how you schedule the pre-event meeting. That should, at minimum, be established in the staffing request 3-4 weeks out. Saying to people "hey, let's meet tomorrow night" doesn't always work for those of us who don't have a 9am-5pm work schedule (or even for those who do). Then, you have your discussions via Discord 3-7 days out and the day before, people can decide if the scenario warrants a voice call or not. From a ZBW perspective, very few of our events would. That likely is different in other regions where there is more inter-ARTCC collaboration required.

We will be using the vATCSCC discord quite heavily, especially in the preplanning phase of the event, as well as during the event for tactical communication between facilities. The 24 hr out meeting, like Jeremy said, will be short (nothing like CTP route meetings :D) and may not even need to occur on voice if everyone's happy with the plan that was put in place during the week.

Currently, there isn't always someone to communicate to during an event about routing, restrictions, or any other relevant factors. But if we want to address the traffic management problem, we need to start with having people who can communicate for their facilities and people who will coordinate with others.
Quote from: Evan Reiter
We should absolutely make this a requirement but it should be left for discretion as to whether a dedicated position is required or whether this can be managed by a controller who is working traffic. Yes, I realize it's much better to have a dedicated person in real life. And if you want to pay the same salary FAA TMU operators received, I'm game! When it warrants, have a dedicated position. But when it doesn't warrant, you should come up with a standard of identifying which active controller from the facility is "in charge" from a TMU perspective. I don't know if that's a _T_ in their callsign (not ideal for position swaps) or some kind of identification in Discord (like changing nicknames?). However you do it, identifying "the person" to talk to during an event (or heck, even during non-event scenarios) would be a valuable addition to our standard cross-ARTCC communication practices.

For example, in ZBW we define a CIC. In regular operations, that's the highest-level controller for the facility (so, ZBW). During an event when split Centers are in play, we'll always identify which of them is the CIC. I'm sure it would help neighbors to have a quick resource knowing which of the staffed Center controllers is the best person to contact for general cross-ARTCC questions.

CICs are great for internal issues, but when it comes to external issues, I think a TMC is needed solely for routing, flow programs, and general cross-ARTCC coordination.

Again, like I said at the top, nothing here is final and I want to keep this discussion going to help us pave the way forward.

Evan Reiter

  • Instructors
  • 108
    • View Profile
    • Boston Virtual ARTCC
Re: VATUSA Traffic Management Unit: Launch
« Reply #6 on: August 28, 2020, 10:59:26 AM »
None of what was in the slides is final - it was merely a first draft designed to get conversation going between staff members about how to attack this issue. Changes are always an option and feedback is highly encouraged to myself, my team, and the rest of USA staff. Like was said in the meeting last week - we are here to help you guys succeed in your event.

[Nothing] here is final and I want to keep this discussion going to help us pave the way forward.
Thanks Ryan. So, in that theme and for clarity, I'm pointing out two things for your consideration:

1. For FNOs or other events that feature only airports in one ARTCC/facility, either:
--> Call them OPLEVEL2 events or
--> Reduce the burden of OPLEVEL3 events to make it a bit more reasonable on neighbors and on you if we're going to do a minimum of 52 FNOs a year, plus however many other events meet this criteria.

2. Find a way to identify a currently-online TMU representative, who may or may not be actively controlling a position, for each ARTCC/facility on a ongoing basis, both during events and outside of event times.

Regarding #1, my concern is the workload not just on the ARTCCs/facilities but also on your central TMU division is going to be extensive. As it stands, you'll need at least two individuals (National Ops Manager, Area Traffic Management Officer) for 7 out of the next 12 nights, based on the current VATUSA calendar. If you want to build something, built it sustainably so it's something you can have more than 3 months from now.

Ryan Parry

  • VATSIM Supervisors
  • 426
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #7 on: August 28, 2020, 01:16:30 PM »
Before I go through the replies, I do want to make a quick clarification on all of this:

None of what was in the slides is final - it was merely a first draft designed to get conversation going between staff members about how to attack this issue. Changes are always an option and feedback is highly encouraged to myself, my team, and the rest of USA staff. Like was said in the meeting last week - we are here to help you guys succeed in your event.
Can we expect for more meetings and Senior Staff input on this then? I know there was something recently, but I was under the impression it was for EC's to attend and I was told by the staff member we sent that it was more of a "this is how it's gonna go" thing and not a "what do you think" thing. Personally I think the TMU program is a great idea, but in the current form as described in the PDF it seems awfully convoluted and a little over bearing.

Ryan Geckler

  • Mentors
  • 453
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #8 on: August 28, 2020, 02:30:30 PM »
Sure, we can have another discussion with senior staff to discuss the way moving forward. I'll speak with USA12 to get a meeting set up.

Taylor Darland

  • Members
  • 3
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #9 on: August 29, 2020, 10:09:16 AM »
I'm excited at the progress and difference this is going to make in the vNAS. Are there plans to incorporate any web or software based tools in to the "official" protocol? I'm unfamiliar with the process as a whole but i think the more information you have the better your decisions can be.

Jeremy Peterson

  • Members
  • 250
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #10 on: August 29, 2020, 04:40:11 PM »
I'm excited at the progress and difference this is going to make in the vNAS. Are there plans to incorporate any web or software based tools in to the "official" protocol? I'm unfamiliar with the process as a whole but i think the more information you have the better your decisions can be.

Yes, we will rely heavily on data to make informed decisions—we know that’s what works best. Currently, one of our priorities is determining which kinds of data are most useful to us to start. Generally, things like a live flight list with various “times” (think taxi start/end times, wheels up time, boundary crossing time, etc.), a consolidated and configurable OIS that can display current traffic management initiatives, and a resource-hub for gathering and organizing traffic management information (like facility-specific playbooks, information on airport arrival/departure rates according to runway configurations, the like) are just a few things we’d eventually like to develop.

These are long-term goals and we have quite a lot to do before we dive into those things, though.

Dhruv Kalra

  • ZMP Staff
  • 431
    • View Profile
Re: VATUSA Traffic Management Unit: Launch
« Reply #11 on: August 30, 2020, 05:30:26 AM »
2. Find a way to identify a currently-online TMU representative, who may or may not be actively controlling a position, for each ARTCC/facility on a ongoing basis, both during events and outside of event times.

Please don’t get in the habit of combining your TMU position with a controlling position. The times when a TMC is needed to make tactical decisions is almost always during a period of traffic demand that requires a simultaneous elevated level of focus as a controller. Trying to do both at once, in my experience on the network, never ends well.

I’ll echo Jeremy’s sentiments above that during non-weather or non-COVID times, much of the infrastructure being proposed is merely a formality. You’ll thank its presence though during severe weather or during non-standard operations like a runway config change in the middle of an event The latter happened at a Tea Party a few years ago if I recall, and I’ll hazard a guess that you’ll agree that having a dedicated TMU controller made it less of a circus.
« Last Edit: August 30, 2020, 06:52:45 AM by Dhruv Kalra »

Evan Reiter

  • Instructors
  • 108
    • View Profile
    • Boston Virtual ARTCC
Re: VATUSA Traffic Management Unit: Launch
« Reply #12 on: August 30, 2020, 09:41:21 AM »
2. Find a way to identify a currently-online TMU representative, who may or may not be actively controlling a position, for each ARTCC/facility on a ongoing basis, both during events and outside of event times.

Please don’t get in the habit of combining your TMU position with a controlling position.
No doubt; I agree that when you need a TMC to make tactical decisions, if they also are controlling, they will be hard-pressed to fulfill the TMU functions. I'm not suggesting to get away from that.

What I'm suggesting is that it should be very easy for me to identify, on a day-to-day basis, whether or not there's an event, who is the "point of contact" for Facility X when that facility is online. Quite often, it would be nice to be able to say "hey, which N90 is covering KXXX?" or "can we get a bit more MIT on departures from these three airports?". Sometimes posting in the ATC chat doesn't get an immediate response.

If we're going to look at building new resources for VATUSA and trying to pull data and other feeds, maybe there's a way to look at a technological solution here too. Imagine if you could look at the controller list and see a * beside the name of one person, at each facility, who is the "central point of contact" at the moment. When TMU is staffed, that's who it would be. When not, it could be someone else. Of course we know VATSIM won't allow that functionality to exist but maybe there's a way to do it through a Discord integration, a dedicated TMU website, or some other function I haven't thought of.

I think I've said several times that there's a time and a place for TMU to be staffed. ZBW has done it for all our significant events, including the Boston Tea Party situation you mentioned. But during support for a Tier 1 neighbor FNO is not one of those times.