Last week with the strike in France i got 8 CTOT changes from RocketRoute and when i was in the air ATC did not have the latest one and wanted to send me back (!). But they finally found it.
You don’t get fined, these things are just details and you eventually learn about them as you’ve seen today 
I learned about it when I had a flight plan through completely empty airspace in Cyprus and got 25 CTOTs during the whole night until the time was the original EOBT again. Cyprus is in my opinion the worst managed area of all — CTOTs all the time and pointless doglegs over the sea in completely empty skies.
@TheAvenger then you either haven’t been often to LSZG or LSZB, or you’ve been extraordinarily lucky. One almost always gets CTOT from the Berne approach sector.
@tomjnx Never been in LSZB yet and only once IFR in LSZG. Would they give me the CTOT from the ground/tower?
@achimha, would it be possible and meaningful to generate warnings in the briefing pack that the given route is likely to be subject to ATFM? If I understand the Eurocontrol mechanics correctly, some sectors have ATFM as needed and some never do, right?
Would they give me the CTOT from the ground/tower?
They would not let you depart until CTOT. Or in the case of arrival to LSZG, the departure aerodrome should not have let you depart.
If I understand the Eurocontrol mechanics correctly, some sectors have ATFM as needed and some never do
As far as I know all sectors generate slot allocation if they are over capacity. It’s just that some sectors are more prone to be over capacity than others. Unfortunately sector capacities do not seem to be publicly available…
Why do you want to read the log ?
If you have access to the AFTN messages you can quickly perform the appropriate actions for your flight.
For example a flight plan can be acknowledged (ACK) by IFPS and suspended (FLS) at the same time.
A flight plan can receive a FLS because :
1) You didn’t depart before EOBT + airport taxi time + 30’.
In this case you have to send a DLA message with an updated EOBT.
2) Because the weather at the destination airport is below CAT I minima.
In this case you have to include your own minimum in the remark field of your FPL if you can perform low visibility operations. If you’re not LVO approved, you cannot depart.
3) Because a “zero rate” has been set by the destination airport due to airport capacity busting.
In this case you just have to wait for a “DES” message.
4) Because the destination airport is not accessible (ie aircraft crashed on runway)
As an ATC I’ve seen all those cases. They are real. As the information is generally available in AFTN messages, I think it’s a valuable data to broadcast to aircraft operators.
I should also mention that as crew, it’s reassuring to know the status of your FPL.
You are very likely to waste time if you have : to start engine, be denied IFR start-up by ATC, shutdown the engine, re-file a FPL, re-start the engine…. And I really like the fact that I receive an ACK after I file my FPL :-)
Now regarding the user interface. I think this point is crucial. So far, the autorouter is so easy to use and I think it should stay that way. But still, it would be great if users who wants to have access to AFTN messages can read them.
This is why, so far, I personally use the route and briefing data’s compiled by the autorouter (as it’s a very superior tool) and file the FPL via eurofpl.
I hope I made my point clear :-) .
I get what you’re saying Guillaume and I have access to all that information and I personally use it…
We do process those messages and inform users. Not all messages are processed though. Given that we file via the Eurocontrol B2B, not all legacy ATFN options are available.
1) You didn’t depart before EOBT + airport taxi time + 30’.
In this case you have to send a DLA message with an updated EOBT.
We will send out emails and optionally SMS on FLS (flight suspension) and the user can then use the delay feature. 99% of the FLS are due to missing the EOBT but in real life, ATC does the FSA without the user having to delay. That’s what we see in the logs and in daily practise.
2) Because the weather at the destination airport is below CAT I minima.
In this case you have to include your own minimum in the remark field of your FPL if you can perform low visibility operations. If you’re not LVO approved, you cannot depart.
This requires flight plan CHG support which we currently do not have but which we will provide in the future. It’s not a major thing because it is so easy to cancel and file again and everything is available instantaneously throughout the network.
3) Because a “zero rate” has been set by the destination airport due to airport capacity busting.
In this case you just have to wait for a “DES” message.
We will handle the DES message and inform the user via email and optionally SMS.
4) Because the destination airport is not accessible (ie aircraft crashed on runway)
That’s the same as 3), a DES will eventually release the plan.
So to summarize: all scenarios you mentioned (and which I agree are valid) will be handled by our software automatically in a push fashion. We will think about how we could offer the full insight for professionals like you because as you said, we do have the data and it would be a piece of cake to present it but not at the cost of confusing the majority.
@achimha I’ve been using autorouter for a while now and can also say it’s a great tool. One thing that I miss (and is part of the topic of the current discussion) is a field showing the current status of the flight plan. Skybriefing in Switzerland is an awful tool but once I file the flight plan it tells me what the status is (and updates it continuously). When I file through autorouter I always wonder if my flight plan was accepted. I assume if it is not accepted I’ll be informed in some way (never happened until now) but there is no indication I can see.
Back to your discussion: I am a technical person and will probably be able to understand the messages from the system, so showing the log would be OK for me. However others may just get confused. IMO showing the last known status of the plan and maybe making it a link to the log would be a great feature.
A bit to the side of the topic, I think flight plan CHG would be a very useful feature. I had to make a change over my phone while being outside on the field and it’s not that easy, especially when you are with a slow 3G or even slower EDGE connection. I gave up and had to call ATC to cancel and then create the new flight plan on the phone, which is also not easy. A CHG function would require much less page loading and might have worked.
One thing that I miss (and is part of the topic of the current discussion) is a field showing the current status of the flight plan.
Of course you get that, when you file a flight plan, you receive a success message in the browser, an email and optionally an SMS. That means it was accepted and it’s in the system for sure. We constantly monitor the status and update you via email and optionally SMS on status changes.
CHG support will come in the near future.
