Air Traffic Controller Discussion With a Global Perspective
By Fraser Cooper 1303570
#520009 Evening,

I have controlled for several CTP's now. Many of our controllers/pilots do not understand how a slot system works. In VATSIM UK we also train members an easy alternative flow management technique to manage high traffic situations on GMP, such as city-pairs. We issue all aircraft a sequence instead of a slot.

If we assume that city-pair aircraft will all be on the same SID (2 minutes route separation), we will hand an aircraft from GMP to GMC no quicker than 2 minutes apart. When we can see the queue at the hold is getting bigger and bigger, the FLOW MANAGER (Rostered ATC Position) will tell GMP to impose a greater handoff restriction, such as 3-4 minutes.

As we use Euroscope we display a SLOT column (Renamed to SEQ). We will assign a sequence to an a/c when they call for push and start. (S1 - added to SPAD). Departure list arranged by SEQ so lowest SEQ at the top. Each a/c that calls up will be given the next available SEQ number (S2) etc. Every 2 minutes (or whatever the Flow manager has selected at the appropriate time between pushes), GMP will hand the a/c with the lowest SEQ number to GMP and clear the SEQ.

SEQ numbers do not change. We simply hand the a/c with the lowest SEQ number to ground (as they are deleted after we hand them off).

To stop a/c logging on at the same time for CTP, we allocate a CONNECTION TIME instead of a CTOT. Therefore, we will not have the complication of dealing with SLOTS and a/c missing CTOTS.

Interested to see what people's thoughts are on this.

Image

Image

This technique has been trialled and tested on events in the UK.
Last edited by Fraser Cooper 1303570 on Thu Dec 07, 2017 3:16 pm, edited 1 time in total.
By Johan Grauers 1113891
#520020 Drawing on RW experience I partly agree.

The types of flow I've come into contact with are
Slots or CTOT, Calculated Take Off Time
ADI, Average Departure Interval
MDI, Minimum Departure Interval
MIT, Miles in Trail
TNBF, Take off Not Before
TNAF, Take off not After

They are used for different things. MIT is a radar thing (mainly, I think there are places that use MIT for tower as well), all the others are tower based.

MIT is a requirement to have a certain amount of miles in trail for en-route aircraft. In other words as an en-route sector you will have to sequence. In some cases this is also done in such a way that you are targeting certain waypoints at certain times.

For real this is quite a big part of en-route control, and you can find flights on FR24 that have been sequenced en-route if you look in the right places. On vatsim however we sometimes forget this. Partly because our en-route sectors spend so much time doing top-down and coordination. Things that for real would be done by other controllers. Also because we suffer from a lack of C1+ controllers for these events we can't get the sectors staffed to the level we would want regardless.

This is always a major issue with these types of events, we simply do not have the en-route controllers required to optimise these sort of things. Also an MIT reduces complexity by reducing bunching, but if you keep firing traffic in at a higher rate than can be managed then the MIT is unsustainable.


CTOTs are issued by CFMU, the Central Flow Management Unit, in Brussels and they are generally used to control traffic flow over several hours.

CTOTs can be extremely complex, and include multiple restrictions both en-route and at the arrival airport. CTOTs however come with a -5/+10 takeoff window. This mean they are fairly blunt, therefore the longer flying time is used to look at the situation continuously and the flow can then be managed tactically. This can be things such as delaying some flights, short-cutting some, changing a few levels to reduce complexity and splitting the sectors. On Vatsim again we don't have the expertise (with a few exceptions), we don't have the tools (although that is changing) and we don't have the staff to do these things.

ADI and MDI are similar. An ADI require every 3 aircraft to be spaced by an average interval. So if an ADI is 3 minutes you can have something like a 2 minute gap, 4 minute gap, 3 minute gap etc.

An MDI has to be a minimum. So an MDI of 3 requires you to have a minimum 3 minutes between all aircraft on that route. Ie 3-3-4-3, but never 2.

These are generally used to stop bunching in sectors close to the airport. In other words Heathrow might get an MDI to protect a TC sector or something like the Dover sectors. Manchester might get MDIs to protect the Daventry sectors.

In general these are used to reduce complexity in sectors, not to reduce the flow through. If the flow needs to be reduced CTOTs are often used, sometimes in combination with an ADI or MDI.

TNBF and TNAF are generally used for short (often domestic) flights to reduce delay in the air or on the ground. For example if Dublin are fogged in a flight from Liverpool might be issued with a TNBF to keep it behind a stream of aircraft coming in ahead. Or conversly a TNAF to keep it ahead of other inbounds, thereby reducing air and ground delay and reducing complexity in the radar sectors.



So, with that background, my thoughts relating to CTP.


MDIs could be useful, but I think it would be to protect the en-route sectors, not the ocean. The ocean is so far away from most departure fields that by the point the flow reaches the boundary any MDI effect has been lost.

We could attempt a MIT solution, but that again is only really useful to stop bunching. Not to mention you need to find a quiet sector with the capacity to apply the MIT, I don't think we've got any quiet sectors during CTP.

The slot system used in theory should spread traffic out, but it also helps to keep track of who has booked and who hasn't. The system could be changed to track this in another way, but I don't know if it's worth it.

For me personally I think it would be worth spending time trying to optimise the system on the ocean and en-route more. We could apply more flow restrictions but this would mainly stop the near-airfield sectors from an overload, and I don't know if that's been a big issue?


I think what we're doing with routes is good and should continue. Ideally arranging the routes artificially to reduce conflict points and to try to avoid giving a single sector too many conflicts. It means longer distance for the pilots but on the whole I think it's a compromise worth doing.

I have said in the past as well that I think we should consider how we work the ocean. I have to provide a disclaimer though which is that I am not shanwick qualified, so feel free to shot me down if it's stupid. However my suggestions are based on what the RW guys do.

The RW system works either on CPDLC or HF. The HF is operated by radio operators who are not controllers. They can spend time to repeat messages several times and listen closely to the frequency because it is their only task.

You can also have several radio operators for a track, there is no need to keep them contained to a single track or flight level. You could simply pass an equal amount of aircraft to say 10 or even 20 frequencies, each manned by one person. This gives flexibility with closing and opening more frequencies based on traffic load.

We don't have nearly enough C1s to do this. But we do have plenty of S2 and S3s in the system. I am well aware of the restrictions in the current rules for frequency range. However I think it's worht exploring if S2 and S3 controllers could be trained as radio operators and be allowed to man a shanwick or gander frequency where they will take position reports and requests, and relay these to the controllers as well as relaying any controller clearance to the aircraft.


This means the controllers don't have to spend time managing a frequency, instead they can sit with a spreadsheet (or similar) in front of them and only input data and do the controlling. This is roughly how the real system works.

For real as well there are controllers providing clearances and en-route controllers. Put your more experienced controllers onto clearance where they receive and formulate clearances and nothing else. They are responsible for giving clearances that should work all the way through. If the clearances are safe then in theory the en-route controllers should only have to monitor the traffic and ensure any position reports and estimates conform with what is expected (and the clearances as needed).

Another thing to consider. For real they split en-route vertically, not by track. When I was there visting they had two en-route controllers for all of Shanwick (I think they had 3 or 4 clearance controllers most the time). This means that if your traffic is on different tracks you can ignore it as a conflict, you only work within each track (assuming nobody crossing at an angle, which for real there are but pretty rare for CTP I believe).

The only downside is that if you want to let someone climb you may have to coordinate with another controller, but for CTP we never really do any level changes on the track system anyway.


To me, again from the outside looking in, this seems like an easier way of working than to have one controller per track. Also if we can use some sort of off-load system with radio operators we could both reduce frequency congestion and give the controllers more time to do actual controlling rather than admin.




So on the whole, I do think we have things we could improve. However the main issue will always be staffing of en-route sectors. I don't think an MDI system is a bad idea, but use it for the right things. It can be useful to protect sectors close in, it will not make a big difference to the oceanic part of the event.
By Martijn Rammeloo 1302622
#520068 We (DutchVacc) use a tool that checks (and displays) automatically if a pilot booked for the event. If so, and if CTOTs are used during that particular event, the CTOT is assigned to that pilot. Next, a start-up time is calculated, taking into account the time it takes to taxi from the (specific) gate to the departure runway(s).

The problem is that during events like CtP, many pilots try to join without booking. The solution is simple: our tool will always give them a lower priority, resulting in (long) start-up delays for non-event- traffic.

In ES we have (additional) columns for CTOT (slot), projected take-off time, startup time, departure interval (per runway) and a flag to display if a flight was booked or not.

Bottom-line: CTOTs/slots can be quite useful, as long as you make sure that they get the priority that they deserve.

(Obviously, the flow manager (‘operational planner’ in our lingo) should be an experienced controller during busy events)

Martijn
By Fraser Cooper 1303570
#520071
Martijn Rammeloo 1302622 wrote:We (DutchVacc) use a tool that checks (and displays) automatically if a pilot booked for the event. If so, and if CTOTs are used during that particular event, the CTOT is assigned to that pilot. Next, a start-up time is calculated, taking into account the time it takes to taxi from the (specific) gate to the departure runway(s).

The problem is that during events like CtP, many pilots try to join without booking. The solution is simple: our tool will always give them a lower priority, resulting in (long) start-up delays for non-event- traffic.

In ES we have (additional) columns for CTOT (slot), projected take-off time, startup time, departure interval (per runway) and a flag to display if a flight was booked or not.

Bottom-line: CTOTs/slots can be quite useful, as long as you make sure that they get the priority that they deserve.

(Obviously, the flow manager (‘operational planner’ in our lingo) should be an experienced controller during busy events)

Martijn


I agree, that if used correctly CTOT's are the best flow management technique. A ES plugin would be good that would auto populate the CTOT and TSAT column. Also, a system that assigns a CTOT to NET (Non-event traffic) too.
By Martijn Rammeloo 1302622
#520090 Andreas,

It is a suite of over 40 PHP scripts and about as many database tables. In addition to that, another controller developed a plugin in order to exchange data between ES and the server-backend.

Initially it was developed for gate assignement, but after a while inbound planning and outbound planning were added. In the (hopefully) near future SSR assignement will be added.

Unfortunately, I am not keen to share. The reason is simple: there are some (hard-coded) username/password combinations in some script, some of them for commercial services (i.e.: Flightware, in order to translate ICAO callsign into IATA flightnumbers, I need that to obtain the real-life gate through the Schiphol API). It would simply be too much work to 'clean' the code (25000+ lines...).

Furthermore, the code is not documented well enough for 'outsiders' to be able to port it to another airfield.

Martijn
By Andreas Fuchs 810809
#520098 Hi Martijn,

thanks for your detailed answer. I see that it is a grown software and I wish there was a way that VATEUD or higher up organizational structures weren given such code and were able to provide vACCs/vARTCCs with a ready to go set for their events. Well, well, we can all dream a little bit.
By Morten Jelle 1012739
#520114 It will require a more large project. In order to get a setup that is ready to use at different areas, requires a source that provides these data to all airports (eg. Europe). However, this is not the case at the moment, and therefore it is not possible to do. The only way now, is to create a system, that can work with manual data and VATSIM data or even figure something out automatically. Martijn is using the Schiphol API in his plugin - so this will only work there.
By Martijn Rammeloo 1302622
#520154 The Schiphol API, and then some :-)

I have a database table containing all 'gate-coordinates', extracted from several sceneries, including default FSX. So, when a pilot logs in, I know at which gate his plane is. In the same table are 'taxi-times': how long does it take to taxi from each gate to each possible departure runway? I need that time to determine the start-up time, based on a two-minute departure interval at each departure runway in use.

Obviously, all this data is airport specific!

This also applies for example to the inbound-planner:

http://spi.dutchvacc.nl/inboundplanner.php

The script tries to 'guess' the IAF, based on the STAR entry point, or the ADEP. Then, it calculates the ETA at that IAF.

Anyway, the foundation of this tool is simple: read and parse the VATSIM data every minute, and then do some clever things with it 8)

Martijn