Better ATFM solutions for VATSIM

General Discussion Controller Talk
1

More and more areas on the network are getting increasingly busy, especially during events, even non-special ones such as the “Weeklies” popular in many places, and more and more of these places are trying to deal with this by utilizing ATFM measures. However, the available tools, such as MDIs or ground stops are rather crude, often either having only a marginal impact on the traffic situation or being much harsher than necessary - especially in areas where traffic flies between dozens of airports - while at the same time hitting pilots completely unexpectedly, often leading to complaints.

I would like to propose a potential solution that should make this situation more manageable, but cannot be achieved by individual vACCs or even projects involving multiple vACCs, such as ECFMP, and instead requires help from the network level to implement.
Essentially, the idea is the implementation of a (mostly) automated system to flatten traffic peaks at relevant airports. What I envision is a way for vACCs to set up a maximum capacity for a time frame of 30 minutes (which can of course be done back to back to cover an entire two hour event, e.g.); when pilots file a flight plan from or to that airport, the system checks whether the estimated departure/arrival time frame (calculated based on pilot-filed EOBT and - for arrival traffic - EET) still has available capacity. If yes, the flight plan files as usual, but in the background, the remaining available capacity for that time frame is reduced by one. If no, the flight plan doesn’t file and instead informs the pilot that they have to move their flight forward or backward to a time frame for which there is still available capacity or no capacity limit set up or alternatively to choose a different flight.
To keep it fair for everyone, vACCs should set up such a capacity limit at least a day in advance and there should then be a way for pilots to see for which airports a capacity limit is planned, when that limit is planned, and what the current remaining capacity for each 30 minute time frame is.

Such a system would help vACCs to effectively keep traffic levels at a given airport manageable, regardless of where this traffic is coming from or going to without adding workload and complexity for controllers at that airport and it may even have a positive effect on adjacent area controllers’ workload as it becomes less likely that they have to work a lot of tight sequences.
At the same time, pilots would be better able to plan their flights to avoid lengthy delays and pilots specifically looking for busy places would also be able to better find airports that are going to see a lot of traffic at a certain time. And unlike more traditional event bookings, pilots would still largely be able to plan their flights pretty spontaneously and without having to actively reserve a slot.

2

I’m not sure such a system could actually be effective on VATSIM. In the real world, the facilities have a better idea of what their staffing will be. The staffing is more predictable and more regular. This is obviously not the case on VATSIM, where controllers can come and go as they wish. Obviously, for events, the staffing is more controlled, but it’s still not as predictable and steady as the real world.

The same is also true on the pilot side. In the real world, flight schedules are (mostly) regular and predictable, known in advance.

Also, on VATSIM, traffic attracts traffic. People want to fly where others are flying. That fact works directly against any system that would try to flatten the peaks.

Basically, you’re suggesting a slot system like what we do for Cross The Pond, but it would be used on a regular basis, not just twice a year. Take a look at how the CTP events actually play out, and you can see that it is very hard to implement effectively. We always get people missing their slot times, or unslotted traffic showing up to join the fun, etc.

And then there’s the problem of fairness. People that don’t get to fly the flight that they want, at the time they want, won’t be happy. Sure, some pilots will be fine just flying somewhere else, but plenty won’t.

Anyway, I think there are just too many uncontrollable variables that would make a system like this ineffective. I think it might be better to instead make a system that lets ATC implement delay programs (ground stops, etc.) when needed, and pilots can be informed that they can expect delays before being given departure clearance. (Along with some way of implementing/enforcing ground stops when there is no ATC covering the departure airport.)

At least in the US, there has been a lot of discussion about implementing better TMU functionality into the system, and this is where I think we should focus any efforts in this area.

1 Like
3

My suggestion is less so aimed at staffing levels than actual traffic levels. Here in central Europe, there are a number of weekly events that regularly, if not always, reach traffic levels at or above the published maximum IRL capacity of the respective airport (and then we also need to keep in mind that most VATSIM controllers are hobbyists that are usually not able to achieve quite the level of efficiency that real world controllers would be - similar point for pilots, of course) with even real world controllers saying that these are traffic levels that would long have been flow managed just for airport capacity. The exact capacity on VATSIM can of course be different from the real world one, but I’m confident the respective vACCs’ event teams would be able to find good values for their airports after a bit of testing (accounting, e.g. for the fact that some pilots don’t end up completing their flight, as you mention).
Of course, depending on airspace layout, the idea may also be useful for load management in the TMA or other specific sectors to some degree, but that’s at best a side effect and not really what my idea is aimed at.

It is akin to to the booking system used for CTP, CTL, 24HoV, FSS, and various other larger events, but with two very important differences. Firstly, there is much less organization involved as vACCs would only need to set up the capacity limit and the system would then work entirely in the background while for pilots, there wouldn’t be a need to plan their flights days or even weeks in advance; secondly, it wouldn’t require vACCs/controllers to set up their software in a way that allows them to see who has and doesn’t have a booking and have training in place to make sure everybody understands how to use the bookings etc.; and finally, thirdly, it would automatically “catch” all pilots, not just the ones who are aware of the event and have made a booking (which could also be helpful in removing the necessity for actual bookings at some events and it might even be possible to use it in conjunction with bookings to manage capacity for non-booked traffic).

As for fairness, I don’t think the system would be unfair, rather the opposite: it would increase fairness. As I mentioned initially, current flow measures or capacity bottlenecks hit pilots completely unexpectedly. You may be planning a flight, loading the aircraft, be basically ready to go after likely spending 15-30 minutes to get everything set up, only to then be told there is a 20 minute delay or even a full-on ground stop. That might throw your entire plan for the evening into chaos. Or even worse, you get to depart just fine but then suddenly end up arriving at your destination 30-40 minutes later than planned because you had to spend a significant portion of your cruise flying at minimum clean speed and then a long time in one or even multiple holdings.
The way I see it, if a pilot has enough time and willingness to spend that extra time flying, there is nothing unfair in having the system tell them they need to delay their departure (or move it forward, for that matter) a bit to make ATC’s life easier. Meanwhile, pilots who are pressed for time or don’t want to deal with delays would more often be able to avoid them, which would actually make it fairer for them as they would be less likely to have to cancel their flight or one they had planned to do afterwards. Sure, that might mean that pilots occasionally can’t do exactly the flight at exactly the time they wanted, but I don’t see how the system I propose would be any different from them being affected by a hold, MDI, ground stop, or other flow measure other than the lack of predictability of the current system in that regard?

I agree that there are numerous uncontrollable variables, but that applies to any other system as well, even in the real world, and I don’t think that we should let that keep us from trying to add to and improve the systems and options in place for vACCs. I believe my proposal would be a significant improvement for locations where traffic patterns are too complex to be handled with simple ground stops, MDIs, or similar while also adding to the available ATFM tools globally and increasing predictability for pilots.
In that sense, though, I’d of course be interested to hear more about what you are planning in on the other side of the pond.

2 Likes
4

Sure, there are uncontrolled variables in the real world, but on VATSIM we have far more of them. We don’t have the benefit of knowing airline schedules well in advance, for example.

In short, I don’t see this working because you are trying to plan for traffic levels that are unpredictable, and can change dramatically literally at the last minute because pilots can file their flight plan and connect just minutes before they plan to depart. This is exactly what many pilots do when they see a lot of activity at an airport. This is why I think a better solution would involve monitoring the current traffic picture in real time and implementing flow-control measures when traffic levels are trending towards congestion. This could use automated algorithms as well as human input to fine-tune the variables.

Anyway, that’s my thoughts on the matter, coming from the perspective of someone that is most familiar with how things work in VATUSA. Maybe what you’re suggesting could be more effective in Europe, but I’m doubtful.

5

I have actually thought about this as well and think the system I propose would work well in precisely those unpredictable situations.
To take the European example: currently, someone in the vACC tries to actively predict how much traffic there will be and where it’s coming from to decide whether a flow measure is necessary and if so, what the most effective flow measure would be, then post that via ECFMP. However, as VATSIM’s traffic is significantly less predictable than IRL, as you say, these flow measures more often than not seem to be either way too harsh, not enough, or even both at the same time. On top of that, if the position that would need to implement the flow measure isn’t covered, hasn’t been informed about the measure, or is too busy to really pay attention to proper implementation of the measure, it’s not going to be effective either way.
In my proposal, on the other hand, a vACC could simply put a maximum capacity for the duration of the event into the system if they have reason to believe that there may be more traffic than the airport can handle and once the value is entered into the system, everything else happens in the background and the capacity won’t be exceeded while pilots won’t be unnecessarily delayed either, regardless of whether all traffic comes from/goes to the same airport on the same route or each flight is entirely unique, regardless of whether pilots plan their flights one minute or 5 hours in advance, and regardless of whether the capacity would actually have been exceeded or not.

Active human intervention tends to be tricky in my experience. We have had “coordinators” for most bigger events here for years and it usually tends to not quite work, partly because controllers are not trained for it and partly because of the unpredictability (which isn’t helped by the rather limited vis range in many cases, but that’s a separate issue). Said unpredictability also means that human intervention can usually only be reactive, which tends to lead to very harsh measures and a sudden increase in workload for the positions that have to implement those measures. Not to speak of the necessity of having to put one or even multiple controllers (that often have to be C1 rated for various reasons - and C1s are in short supply as is) aside just for flow management, thus likely reducing the actual capacity even more.
I do like the idea of having automated algorithms to help with that, however (if you guys are working on something in that direction, hopefully something that can be used by all or at least most vACCs and not just with vNAS/CRC?). Anything that works in the background with no or only a minimum requirement for someone to actively set stuff up can help and a greater pool of options for vACCs to pick the most fitting solution from certainly never hurts.

6

This makes sense in theory, but all the variables mentioned previously are factors in determining that max capacity value, making it a moving target. Those variables can change minute-to-minute in the hours leading up to the event, as well as during the event. Some of the variables can be known ahead of time (the number of runways usable given the weather, for example) but many are more unstable, such as the number of controllers available, and the skill level of those controllers. And then there are the variables introduced on the pilot side. Pilots often don’t show up at or near their filed departure time, if they even filed a reasonably-accurate departure time in the first place. Some pilots don’t file in advance and they just show up with no notice when they see a busy airport. Obviously you can allow the capacity value to be adjusted as needed, but you can’t retroactively adjust it to apply to flight plans that have already been filed and accepted by the system. The horse has already left the barn, so to speak.

Don’t get me wrong, I’d love to see a system like this come to fruition, I just don’t see how it can be effective (at least, effective enough to justify the level of effort required to develop the system) given the unpredictability of traffic levels and ATC staffing on VATSIM, during all but the most rigidly-controlled events such as CTP.

So far, we’ve only had discussions like this one. No plans or concrete designs yet. We’ve mostly just identified the need for a special type of TMU position in vNAS which could see traffic across multiple ARTCCs, modify flight plans, modify data blocks, send messages to controllers, etc. Basically a position with greater permissions than a regular controller would have.

We’ve also briefly discussed integrating https://simtraffic.net/ into the vNAS system, but nothing has happened yet.

1 Like
7

I’m of course not familiar with how airport capacity is determined in the US, but I believe that for VATSIM purposes, there is no reason to be 100% precise and plan for every single minute (here, even IRL, airport departure capacity at the most tightly planned airports, those with ACDM procedures, is usually planned only for 30 minute time frames, and even when it comes to other capacity constraints which lead to slots, there is a wiggle room of a whole 15 minutes - anything more precise would normally be done quite spontaneously) and I would even argue that when it comes to the exact capacity, particularly during event situations, VATSIM is much more predictable than IRL. Almost all traffic will be IFR jetliners with similar performance - without military airspace, lawnmowers, parachute droppers, runway inspections, noise abatement limits, etc. complicating capacity considerations (runway configurations are usually not really a factor in capacity here) - and staffing levels at ADC level and usually even above tend to be relatively stable for these weekly events, enough so that I’m confident vACCs should be able to get reasonable values from published runway capacities and slight adjustments based on experience.
As such, I also don’t think there’d be a need to make readjustments after the fact - the idea, after all, is to flatten peaks to a more managable level, not to remove the need for sequencing altogether.

You probably have access to more accurate data than what I can guesstimate from my own controlling sessions, but it has been my impression that the vast majority of pilots appears to create their flight plans with SimBrief about 10-15 minutes before they call for clearance, so I imagine it should all roughly equal out with the EOBT 30 minutes from flight plan creation that SimBrief does automatically if you don’t manually change it (also considering taxi time which can be differ greatly and is not part of the simple EOBT(+EET) calculation), especially with my point from above in mind that it’s a tool to roughly flatten out peaks, not to have precise data in advance.
As for pilots choosing to load in and connect spontaneously without checking for potential capacity constraints beforehand, that’s of course their choice - no need to force them to do that amount of preplanning. If someone happens to do that only to realize afterwards that they have to wait 20-30 minutes, that’s their fault and not really different from what already happens, but with the system I propose, they would at least have the option of checking that in advance and as it would be a centralized, official VATSIM system instead of just something a few vACCs have thrown together, developers of map tools such as VATSIM Radar and other applications that pilots may use to aid or enhance their VATSIM flying might be more willing and able to implement that information into their programs, making it even easier for pilots to notice about such a measure in advance.

Absolutely understand that with the backlog you guys have - and trust me, I’d be the first one to volunteer to help, but unfortunately my coding experience is limited to a bit of basic html and JavaKara from back in school, most of which I have probably already forgotten again :sweat_smile:

Sounds like some cool ideas, will be interesting to see how it all works out, particularly if there are personnel limitations and/or a necessity for additional training. Some of the tools from simtraffic also seem to be quite close to what I have in mind, though that’s of course something where you guys have it much easier in the US with the same procedures and programs used across a huge area - in Europe, e.g., getting every vACC to use the same basic plugin setup for EuroScope, train controllers on how to properly implement flow measures, etc. would be near impossible due to all the local differences, preferences, etc., making a centralized option on the network level that doesn’t require each vACC to actively do something for another vACC’s flow measures to be effective much more desirable.

1 Like
8

Based on this paragraph, I’m realizing that I may have gotten the wrong idea from your original post. I thought you were looking to be able to predict traffic loads much more in advance, like several hours or even 24+ hours, so that a pilot could file that far in advance and the system would be able to tell them if the airport had the capacity or not. I think I got that impression from this part of your original post:

Obviously, for pilots to be able to see the “current remaining capacity” a day in advance, then pilots must be able to file plans a day in advance. (Which would require VATSIM to change the current 2 hour flight plan expiration time, and it would exacerbate the problem of multiple pilots wanting to use the same callsign within that time period.)

If that’s not what you meant, and we’re only talking about much shorter time frames from say 15 minutes out to an hour or two, then yes, it’s much more doable, because obviously the unpredictability of VATSIM traffic has a much lesser effect over such short time frames. In that way, what you’re proposing is similar to existing tools, just more centralized and “official”, as you mentioned. And I fully agree that something like this needs to be done at the network level (or at least at the region or division level, like with vNAS) for it to truly take hold and gain widespread adoption.

Essentially this would be an automation tool for controllers, so that they don’t have to constantly tell pilots “you’re looking at about a 30 minute delay before I can get you clearance” during busy events, like they do now. The pilot would automatically get that same message via this system. Of course, with a human in the loop, they can take a look at the current traffic picture, including how long the list of pending clearance requests is, and come up with a delay estimate right there on the spot. By trying to automate it, you are relying entirely on someone setting and updating capacity values as the picture changes. Because it will change, for all the reasons previously discussed. So if someone isn’t constantly reevaluating the 30 minute capacity values, and doing a good job of choosing the value, you are going to end up having the automated system telling pilots very inaccurate wait times. If the system says there is available capacity, but then they end up waiting for a half hour or more for clearance anyway, then the system is working against you. Or, conversely, if the system says there is no capacity, when there really is (because perhaps more controllers have come online, or some pilots haven’t showed up, or some pilots got out quicker than expected, or you were able to open up another runway, etc.) then you’ve sent a pilot away for no reason.

Obviously, the estimates that the human gives on the spot aren’t 100% accurate either, but at least they are taking the current situation into account each time they tell a pilot about their estimated delay. The automated system can only work with whatever values were last fed into it. Without someone keeping an eye on the capacity numbers to see how they stack up against reality, then your automation will be shooting you in the foot. Garbage in, garbage out.

TL;DR: Yeah, I think this could work for shorter time frames where the uncontrollable variables have much less of an effect, as long as someone is monitoring and updating the capacity values as the situation changes.

9

My fault for not expressing myself clearly enough then!
What I was talking about when I said “vACCs should set up such a capacity limit at least a day in advance” was only a potential deadline for when vACCs have to put the measure in the system. One day seems like a reasonable value to me as it would make sure that all inbound traffic, even ultra-long hauls, get counted toward the remaining capacity and give pilots reasonable advance notice, even if they already want to plan their evening flights in the morning, while still allowing vACCs to be relatively spontaneous about setting up such a measure; but at the end of the day, this and all other exact values I included in my original post are just values I included for illustration purposes and that I thought might be reasonable and workable but they could of course be changed to something else if another value turns out to be better.
So no, I’m not advocating for a long term load prediction (which would of course be nice too, but is quite unrealistic for our hobbyist network), just for a way for vACCs to prevent overload situations by saying “from time x to time y, we can accept a total of z movements at this airport”.

Yeah, I mainly wanted to keep the idea as simple as possible for posting it here, hence why I didn’t include things like real-time fine-tuning. And while I do think it’s a reasonable and useful evolution of the idea (after all, it generally can’t hurt to have more options), I still think that it’d be important to also have the option of a basic system that works just from the preset capacity limit as not all vACCs will always have the people for real-time fine-tuning and it may also not always be necessary to make adjustments (I of course can’t speak for every airport in the world, but our airports here tend to have pretty stable capacity limits across all scenarios, especially when traffic is mostly similar performance IFR, as is normally the case on VATSIM, with the only real outlier being low visibility operations).

10

It probably didn’t help that this part got added in:

If you’re filing a flight plan 15 minutes before calling for clearance, you wouldn’t then be able to move your departure time to an earlier time, you just don’t have enough time to be able to do so that close to the departure time, so your only option would be to then move it to a later time. That being said, for streamers, that could be a bit of a challenge to work with because you’ve already told people you were going to be live at a certain time, so people knew what to expect. If you then have to move the departure time by 30 minutes to an hour, what do you tell them. Oops, we can’t do that? Even worse if streamers go live with the airplane in a cold and dark state and they do the entire flight preparation when they’re live because they’re most likely not going to just end their streams and start up again 30 minutes to an hour later, so what do they do then.

11

your argument for streamers goes against itself. If you are well aware of when you are going to fly, and know exactly what you are going to fly, why would you only submit a fpl 15min before?

12

With some airports, you file the departure procedure along with the flight plan. If, by some chance, the runway changes during the pre-flight preparation, now you have to file the flight plan again if that results in the departure procedure being changed.

13

Were does it work like that? To my knowledge, in most countries you don’t have to (and in some cases might even be specifically asked not to) file a departure/arrival procedure, but in those that do and have runway-specific procedures, you file your best guess based on the forecast and if you’re wrong, you just get cleared for something different but that change to your route would be done by ATC without you having to file a new flight plan.

14

I’ve seen some flights out of the United States doing this. For instance, if you’re getting a flight plan from KMCO to KJFK, you get the following:

FATHE3 VIYAP Q87 JROSS YURCK Q109 DFENC SAWED Q108 SIE CAMRN4

I can’t comment on how SimBrief does this since I use PFPX to do my flight planning, but when I go to the ATC tab, which has the route that would be filed with ATC, I just copy the route from there and paste it into the flight plan when I file it. If it has the departure procedure in there, I generally leave it in there. The other thing is that with PFPX, the wind data gets updated every so often, so depending on when the flight is going to take place, it’s entirely possible for the winds aloft forecast to change from the time I start the initial flight planning to the time I file the flight plan. On shorter flights, like some domestic flights within the United States, that might not change much since the routes are generally fixed, but on longer flights, that could mean an entirely different route altogether. What I don’t want to do is file a flight plan using one route, only to then have to file the flight plan again later on down the line with a completely different route, so at that point, it’s better for me to just wait until closer to departure time to file it.

15

Ah, I thought you were only talking about the departure procedure, not the entire route.
While I think most pilots (unfortunately) don’t put that much preparation and planning into their flights , I can see where your concern comes from. But worst case, you file a preliminary flight plan once you’ve decided what and when to fly and then just refile later on with an amended route if necessary, no? Unless you significantly change your EOBT and/or EET compared to what you originally filed, the system I have in mind would/should treat you exactly the same with that amended flight plan.