Updating Flight Plans
 

With the choas that resulted from the weather, on Saturday and Sunday. I thought it might be timely to seek clarification for the following.
When flight xxx calls for clearance and gets told," Standby 20mins airfield delay due wx/single rwy ops/etc", who is responsible for ensuring the EOBT is kept updated?.
The reason I ask, is that LHR/LGW/LTN/STN will update the EOBT, where's other towers will not,and as a result the plan gets suspended.
If it is written somewhere, I would appreciate if someone could advise where to find out.

Many Thanks

Try the CFMU Library.
http://www.cfmu.eurocontrol.int:80/c..._public.html#2
Take a look at the CFMU Handbook and the IFPS Users Manual. It should be in there somewhere.
http://www.cfmu.eurocontrol.int:80/c...book_2006.html
Good luck!

Sillywalks.
If an a/c requests start before the EOBT +15 period has elapsed and is then delayed by ATC, it is ATC's responsibility to keep the EOBT upto date.
http://www.caa.co.uk/application.asp...detail&id=1392.
At Gatwick this will be done routinely for you. I can't speak for other units.
Hope this clears it up.

I *think* I was told that if the airline causes the delay then they update the EOBT. If ATC cause the delay ONCE THE AIRCRAFT HAS REPORTED READY IN ACCORDANCE WITH ITS EOBT then its up to ATC to input the revision to the EOBT.

In practice this rarely happens as LHR did have some dispensation when the rules came into effect and nothing has really been done to ensure we properly apply them. Once big delays are in force then EOBT updates I suspect will be lower down the priority list. In previous control towers ATSAs did a fine job of keeping EOBTs up to date if required, however times have changed and those in charge thought that not to be the best way to deal with this and other issues of ATM...... :ugh:

Likewise, yesterday we increased our default taxi time due to the outbound delay. Of course, when we wanted to send RDY messages, we could only choose from the default Ready1, Ready5, Ready10 and Ready20 on EFPS. Not what we wanted (Ready30). So we tried to use the DSM to send RDYs, old style, but the keyboard supplied doesn't work, unless you transfer all the AFTERM functions up from Flight Clearance. :ugh: First overload I've ever seen filed on GMP!

If I told you that you couldn't start for 20 mins due airfield congestion, and you were ready for your eobt, then I wouldn't update the eobt, simply because you might end up getting a massive slot delay, and that wouldn't be fair on you.

You have (if I remeber rightly) 15mins from eobt to request start and then 30mins from eobt to get airborne, at the smaller airfields this shouldn't be a problem

Radar, surely if that 20 mins start delay takes the a/c outside of EOBT+15, then a delay message will have to be sent, precisely because it might now need a slot because it will go through a restriction?

RADAR 707. "If I told you that you couldn't start for 20 mins due airfield congestion, and you were ready for your eobt, then I wouldn't update the eobt, simply because you might end up getting a massive slot delay, and that wouldn't be fair on you."

Technically not correct. If the aircraft is waiting for a CTOT then fine, the aircraft must wait unless there is an improvement. If you have delayed the aircraft, and EOBT+15 has been passed, then you must send a delay message and update the EOBT. If the aircraft picks up a CTOT then that is unfortunate, and you will need to send a RDY MSG. If there is no improvement, pick up the phone and speak to UKFMP - they can sometimes intervene and help. What you can't do is allow aircraft to start beyond EOBT+15 just becuase you think it is unfair. We have to consider the impact this could have on the sectors further down route. The traffic managers use a system called TLPD (Traffic Loading Prediction Device) which, as it sounds, predicts traffic loading in sectors at a certain time and is based on EOBTs. It is only as accurate as the information put into it. You must ask the airlines to update the EOBTs prior to them calling ready and do it yourself if they are delayed as a result of ATC.

GONZO
"Likewise, yesterday we increased our default taxi time due to the outbound delay."

What did you increase the taxi time to?

30 mins. In retrospect I should have gone for 40. And UK FMP were stars yesterday. :D

I agree, pat on the back for UKFMP - good job well done. :ok:

GONZO - if your taxi time is set to 30 mins, the system will always try and automatically improve any CTOT to meet the taxi time without the need for a RDY. So if I understand your thread correctly, the RDY 30 that you so wanted was already in place thanks to the increased taxi time!!

The impact of inaccurate data in TLPD will be felt the closer you get to the initial entry sector rather than further down route. TLPD will have the flight showing in green (planned but not active), possibly dark green (planned, not active, and past the EOBT), and then change to red when active. However, updated times will then be calculated based on live data (radar and other) and so the further away the sector is, there will be more notice of changes in traffic levels and the ability to take appropriate action, hopefully resulting in the impact being managed.

Thanks for the responses.
Interesting to see that there is confusion even amongst ATC'ers :ooh:.
What hope do us airlines have then:E:E

nodelay,

Yes, I'm aware of that. The problem occurs if the a/c is ready before the EOBT.

...And also, there were the forty or fifty a/c that were still on a 20 minute taxi time when we changed to 30, but had hours of slot delays.

From my operational experience at EGCC, ATC can update the EOB time via the NAS computer system and thus keep the plan active in the UK system, however this does NOT update the actual flight plan via Brussels. The danger of doing this, from an air traffic point of view, is that if the flight plan is not updated via the CFMU then there is the possibility of a slot requirement at the later time when the aircraft actually becomes airbourne which in return may result in overloaded en-route sectors, etc. Or on the other hand, if the destination airfield as affected by severe delays or even closure, the flight would not be aware and will depart only to find themeselves holding indefinitely! And unfortunately, it's usually the poor ATSA's that get the agro when the sh*t hits the fan!

So delay messages really should be sent by the operating company to avoid any confusion, and the P times (EOBTs) only changed by ATC to avoid squawks dropping out of the system, prior to and IN CONJUCTION WITH A DELAY MESSAGE FROM THE COMPANY!

Heathrow, Gatwick, Luton and Stansted all interface with IFPS/CFMU and NAS primarily with the EFPS electronic strip system. A DLA message sent from EFPS goes to both.

In recent days at Heathrow I would have loved to have had an ATSA helping us. They're sat right next to GMP, and yet are not allowed/unable to offer much assistance. It's ridiculous. :ugh:

Technology!!!! :D I still love my paper strips ha ha

Damn you! Never before have I wanted to work at Manch!!!! :}

As far as I am aware,

If a/c gets a big slot delay, we need to update NAS to stop squawk dropping out.

If a/c is not ready in good time for its eobt, the handling agent must send a delay to IFPS. (or we can do it from the tower if we are not busy and in a good mood!)

BUT as for EFPS, Gonzo, if it is linked into both IFPS and NAS, then I can only assume that when an a/c gets a big slot delay, NAS gets the message and therefore the squawk will not drop out?

In the good 'ol days, I sometimes had to sit in flight plans and type in every slot, SRM, etc etc. :zzz:

Well EFPS doesn't update the EOBT when a big delay results. About a month ago when Paris had severe thunderstorms the average delay was over 180 minutes. Aircraft who were ready for their initial EOBT and had waited for the 3 hours or so had squawks dropping. The only way to re-enter them from the tower was to update the EOBT but this would have caused futher slot delay. I think LTCC did the squawk re-entry for us. Good system.....