Scottish Airports EFPS
 

Was wondering how preparation for the EFPS transition was going up in haggis land?

The rumour mill has it that the organisation of the whole project is about as polished and well though out as the Iraq conflict. i.e. a shambles. :ok:

How very dare you! It will be another NATS triumph and bonuses all round. HURRAH!!!!!

Yes that really sums it up.

NSL as usual has tried to bring EFPS in on the cheap. It has not provided the correct resources i.e. an overbearing of valid controllers to release people to train but has managed to secure a few 'blip drivers'.

Whilst most people are reasonably happy with the twr/gnd side of things Approach is another matter. Quite a few of the LCE's believe that it is not fit for purpose and needs more work.

One final point.

I suspect that this would not have happened down south and correct resources (money) would have been more readily available! :ugh:

We're due to get it down south early next year and rumour has it that it's not going too well :rolleyes:, but I'm sure it will be introduced on time, on budget and NOT FIT FOR PURPOSE!

EFPS is the stripless system used by NSL, not to be confused with EFD which is the stripless solution for TC and PC. They come from different suppliers and are technically very different.

What company got the contract for the EFPS?

And it's UCE, not LCE anymore!!:=

Interesting. I thought it was meant to be working well for ATSOCAS and could be rolled out to all of us?

UCE/LCE? Oh, get her!

Since the Heathrow debacle D of S are very hot on making sure things are fit for purpose AND that staff are comfortable providing an ATS using it. So if the staff using it are not happy (and evidence will have to be provided to D of S) then it won't go live.

BD

EFPS runs on Windows XP.

We should be thankful it's not based on Vista!

Actually in the south we are using Windows NT.

Interestingly Windows NT has an end user licencing agreement with includes
I brought this up when it was introduced and was told that we don't worry about such things:eek:

There you go then, any failure would be a known system property not a failure.

Dan Dare.

Um .. a little more accuracy and a little less FUD if you would please. The words at the start of that part of the EULA go ......

So - Don't write your ATC software in Java and run it on Windows - but Micro$oft are quite happy for their operating system to be used to run applications written in other languages.

CS

eglnyt wrote:

And by all accounts not compatible, so no chance of linking them together to make one seamless system:ugh:

Depends what you mean by compatible and seamless system. The thing really stopping that at the moment is the rather old FDP system in the middle. It's replacement will join up the EFPS towers and the centre systems.

It would be interesting to work out the cost of this exercise.Multiple AVAAs daily and days off in lieu for the volunteer staff,against retaining the ATSAs and a system which works.
I would be surprised if the break even is 20 years,just like some other wonderful cost cutting measures.
As for the system then the jury is still out on being fit for purpose.There are serious issues with it,that are safety critical.
As has been said before no doubt it will be brought in,with much trumpet blowing and fanfares.Until some poor sod has the first nasty because of it.The controller will no doubt take the can.:suspect:

Broaden your horizons and think of the impact on the ACC which your ATSA is phoning through to. Removal of the carbon based interface helps them in moving towards greater use of automation and electronics. EFD is the first stepping stone on the way to making much more use of the capabilities of computers to do checks but it's crucial that those computer systems 'know' the tactical decisions the ATCO makes, hence moving away from pen & paper. Automated CFL versus SFL checking is one of the first benefits to come from automation. Downstream, as we remove NAS and replace it with a system which has more automatic checking abilities and which can interface with adjacent ANSP's much better than current OLDI links, there will be a host of safety net benefits for the ACC.
And as I said before the company has learnt from Heathrow and D of S will never allow it into service unless it's fit.

BD

BDiONU,
OK why don't you broaden your horizons.Half our traffic is generated inhouse and never goes near NAS,or whatever comes next.In fact it doesn't even go to our ACC,because we actually are the inhouse ACC for this traffic.
As it stands today,because I asked,there is no way to input this data into EFPS.The ATSAs are not going to be allowed to touch it.No-one can answer this question.
Fine if you say that it won't be brought in until it's safe.Perhaps that is why the O date has been brought forward,while people are still scratching their heads to try and make it work.
Currently it isn't fit and in the environment we work,I doubt if it ever will be.At best the way we operate will have to change for the worse,to work in with the shortcomings of the system.Hardly benefits the customer does it.
I haven't even started on the radar side.:hmm:
I do have experience of state of the art computer systems,at a brand new airport the size of Heathrow,which were far more advanced than anything NATS has.

I assume you're talking about choppers out to the rigs? So what's the answer, a split system with half done manually and half electronically? You'll disagree but my personal view is that certain ATC practices need to be dragged, kicking and screaming, into the 21st century and not left as is "because we've always done it this way". If the MOPS don't fit the modern way of working then the MOPS need to change.

BD