Dreamliner in emergency landing at Dublin Airport
 

US-bound Ethiopian Boeing 787 Dreamliner took off from Dublin at 6.10am en route to Washington. info below

Emergency landing at Dublin Airport | BreakingNews.ie

Some more info from RTE

The Dreamliner had been cruising at 40,000 feet and was about 600km north west of Donegal when the pilot declared an emergency at around 7.30am.

The plane was then forced to dump thousands of litres of fuel so it could land within safe weight limits.

The crew had been in contact with controllers at the Irish Aviation Authority's North Atlantic Communications Service centre at Ballygirreen, Co Clare and advised them that they had to shut down one of the jet's two engines.

Several units of Dublin Fire Brigade along with HSE ambulances and an incident officer were mobilised to the airport.

Engineers are now investigating the problem.

Thomsonfly binliner had engine problems a week ago.
Incident: Thomson B788 near Gander on Oct 14th 2015, engine rolled back

And Royal Brunei also had a engine shutdown the other day too.

Brian

This is a professional pilots forum. I know you just direct quoted but can we leave dramatics to the press and consider a re-title of your thread. Perhaps "Boeing 787 engine failure - return to Dublin 23 Oct 2015" would be more appropriate.

I am curious which of Ethiopians Dreamliners was involved. Was this one of their earlier purchases or one of the six "Terrible Teens" that they recently purchased ? --- actually I don't know if the "Terrible Teens" are yet delivered to them, and in service.

ET-ARF according to FR24.

ET-ARF. So, what is with the GEnx-1B (or not 2B) engines?http://i1047.photobucket.com/albums/...ket/Resize.jpg

The shutdown rate for the GEnx engines (both -1B and -2B) is running around 2 per million engine operating hours. That's only about ten times better than what's required for 180 minute ETOPS.:=


We better ground the fleet :ugh::ugh::ugh:

It is still valid to ask why they shut down. If there was no apparent defect then clearly something is not quite right and the technical team needs to learn from that.

I must say, as a controller who deals with ETOPS diversions regularly, I was finding the original, uncensored thread both educational and interesting. Bizarre.

Right to the specifics, it's implied that there was 3 separate incidents of GEnx engines rolling back uncommanded with no other abnormal indications within a few days, in different stages of flight in different parts of the world. Any new FADEC software upgrades in the last couple of weeks?

VW syndrom ?
 

Too many people assert it is unpossible to write zero-bug softwares. And that is wrong. In result we stay with no-answer questions about how we shall avoid the multi-repetition of failure... Until we discover the hidden Volkswagen syndrom ?:}

UDT - as is sometimes the case, I know more than I can probably repeat. But we have a pretty good idea what's causing the rollbacks (all recoverable, BTW), and it's not software as such (although the fix will likely include a s/w change).

I've always been under the impression that if I could avoid shutting down an errant engine, (say just keep it at idle), that this would prevent possible adverse ETOPS penalties down the road based on my company's reliability program for that particular model of engine.

At least that's what I've been led to believe from our line check airmen (LCA's).

Go on, go on, do tell!!! :)

It is possible to write bug free software, but proving that that's what's been achieved is basically impossible except in trivial examples.

Mostly we rely on a whole lot of very carefully designed testing and many hours of logged trouble-free running before reluctantly concluding that it might be ok... That's why making changes to this kind of software is so expensive - All the software tests have to be repeated.

IF it's a software problem AND it's the same software on both engines I would have expected that to impinge on ETOPs certification since the risk of the second engine doing the same thing is higher than if it were a mechanical (as opposed to design) fault. ETOPs is defined by acceptable risk of the other engine failing within a set time period and whilst demonstrated failure rate is a very good metric it should not, IMHO, be considered in isolation.

What about the issue where the aircraft engines need to be "re-booted" every 248 days...perhaps something left over from this issue?

Boeing defeat mechanism to make the fuel burn look better in testing!

I've never ever seen a piece of bugfree software in 30 years of working with mission-critical systems.

agreed - it is not possible to make software totally bug free

Quote from beardy:
"IF it's a software problem AND it's the same software on both engines I would have expected that to impinge on ETOPs certification since the risk of the second engine doing the same thing is higher than if it were a mechanical (as opposed to design) fault. ETOPs is defined by acceptable risk of the other engine failing within a set time period and whilst demonstrated failure rate is a very good metric it should not, IMHO, be considered in isolation."

That's a very powerful argument, IMHO.

In which case, are FADEC software updates permitted to be introduced simultaneously on the two engines of a given a/c? (Or, for that matter, simultaneously on all the engines of a/c with 3 or 4 engines?) As beardy implies, introducing faulty software could cause a failure on the first flight, whereas a mechanical failure caused by faulty manufacture and/or wear and tear is a different matter. It would be comparable to allowing one mechanic to change the chip detectors on both engines on the same turnround...

One hopes the loss of the A400M on a test flight due to a FADEC problem has focussed minds across the industry?