Cross the Pond - SUGGESTED FLOW TECHNIQUE

[Fraser Cooper]

[REMOVED]

Edited March 14, 2018 at 01:14 AM by Guest

[Johan Grauers]

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 p[Mod - Happy Thoughts] 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 ([Mod - Happy Thoughts]uming 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.

[Martijn Rammeloo]

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 [Mod - Happy Thoughts]igned 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

[Fraser Cooper]

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 [Mod - Happy Thoughts]igned 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 [Mod - Happy Thoughts]igns a CTOT to NET (Non-event traffic) too.

[Andreas Fuchs]

Would you share that script and plug-in with the rest?

[Martijn Rammeloo]

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 [Mod - Happy Thoughts]ignement, but after a while inbound planning and outbound planning were added. In the (hopefully) near future SSR [Mod - Happy Thoughts]ignement will be added.

 

Unfortunately, I am not keen to share. The reason is simple: there are some (hard-coded) username/p[Mod - Happy Thoughts]word 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 docomeented well enough for 'outsiders' to be able to port it to another airfield.

 

Martijn

[Andreas Fuchs]

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.

[Morten Jelle]

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.

[Martijn Rammeloo]

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 p[Mod - Happy Thoughts] the VATSIM data every minute, and then do some clever things with it

 

Martijn

[Alex Beavil 1302142]

My single CTP this year showed 2 things:

On average, conflicts aren't an issue, unless aircraft don't stick to clearances. I only had to make 2-3 speed/level/route changes during the whole event.

The biggest issue was simply inputting all position reports and clearance requests into the spreadsheet, and then actually checking it, all before someone else decides to call up for whatever they want.

As a result, I agree with the idea of having separated radio operators and controllers, because the two jobs are effectively nothing alike, and very difficult to do at high speeds required during CTP.

There's plenty of very competent (from a RT point of view at least) S2-S3 people that would be perfectly fine as radio operators, and often better than the oceanic validated people currently, simply because they'd only need to learn one thing, and only be doing one thing at once, rather than trying to operate a "fix everything" toolshop

 

But, it'd require people to work very well as a team, which may in itself require separate training for both parties