Updating Flight Plans

[silly walks]

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

[Talkdownman]

Try the CFMU Library.
http://www.cfmu.eurocontrol.int:80/cfmu/public/site_preferences/display_library_list_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/cfmu/public/standard_page/userdocs_news_handbook_2006.html
Good luck!

[Ratatat]

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.aspx?catid=33&pagetype=65&appid=11&mode=detail&id=1392.
At Gatwick this will be done routinely for you. I can't speak for other units.
Hope this clears it up.

[GT3]

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:

[Gonzo]

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!

[radar707]

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

[Gonzo]

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?

[nodelay]

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?

[Gonzo]

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

[nodelay]

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!!

[PPRuNe Radar]

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.

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.

[silly walks]

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

[Gonzo]

nodelay,

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

[Gonzo]

...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.

[FinDir]

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!

[Gonzo]

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:

[FinDir]

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

[Gonzo]

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

[WAIF-er]

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:

[GT3]

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.....

[Gonzo]

As GT3 says, it does not update the EOBT if a slot gets allocated.

We can ignore slots if there are MDIs in force and a/c call in time to make their CTOT. Flow were happy about this, but asked us to update the EOBT to aid their planning. Of course, having updated the EOBTs, new slots got allocated another few hours hence, and then flow told us we had to depart on the slots, as the MDIs were due to end before the latest slots.

[WAIF-er]

maybe an idea for EFPS is that when the a/c signs in and is ready but has a big slot delay, the GMP can activate the squawk in NAS, even though it will not be airborne for some time?

or if CCDS is running out of squawks, then it could delay the issue of one until the a/c is within 15 mins of its slot time, or the controller requests a squawk with a DQ message or some equivalent, whichever is the sooner.

(I want recognition if either of these ideas are taken on!)

Its probably a case of "computer says no", which in my language translates into "we didnt write the software so we dont know if its possible":=

[Gonzo]

When it's busy at LL 'within 15 minutes of its slot time' it might well be at the holding point queue, and if it's that busy I certainly don't want to be worrying about giving out new squawks over the R/T.

[WAIF-er]

Ok then, why cant we have transponders that have an 8 and 9 on them?

Going off on a tangent now, surely the US would have an issue with a shortage of squawks. How do they get around this problem? (0 points for anyone who says Squawk 7000!)

[niknak]

Why can't transponders have 8 or 9 on them?

Because they can't, its part of the scientific and mathematical formula which is an integral part of the transmission and recieve process of that particular piece of kit.

I've never understood it myself and never will, just accept it as one of those things.:ugh:;)

[smellysnelly2004]

Each selected number on the transponder is sent in binary form - 3 'bits' which can either be 0 or 1. The first digit represents 4 units, the second 2 and the third 1. ie. 100 represents 4, 001 represents 1, 110 represents 6. This is why you can't have 8 or 9. As to the mechanics of why it can't be done using 4 binary 'bits' representing units of 4,3,2 and 1 which would produce numbers 0-9 I ahve no idea!!:ok:

[mm_flynn]

In the olden days many computers Octals (3 bits) which to a human are the numbers 0-7. Later we used Bytes (8 bits) and nibbles (4 bits) which give the numbers 0-F in hexadecimal (as you see on your computer). The transponder code is you setting 4 Octals of data which is why there are only the numbers 0-7.

Re - Why does Europe have a code shortage and the US not. I believe the US dynamically allocates codes across the whole airspace system using flight plan info to minimize the potential for a duplicate code - which is why very occasionally you do have a code change enroute in the US. As far as I am aware they don't have lots of special conspicuity codes or allocations of codes to individual controlling areas - hence much greater flexibility. They also have ‘everyone’ except VFR on a discrete code as compared to the use of here of say a 'Farnborough Code' used simultaneously by several aircraft receiving a service.