Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

AAIB initial report out on BA B777 crash at LHR

Wikiposts
Search
Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

AAIB initial report out on BA B777 crash at LHR

Thread Tools
 
Search this Thread
 
Old 21st Jan 2008, 22:42
  #221 (permalink)  
 
Join Date: Dec 2006
Location: canberra
Posts: 11
Likes: 0
Received 0 Likes on 0 Posts
Double Zero, in post 201 asks
As no answer publicly known - why allow similar a/c to fly ?
A less cynical response than that of Zorst in post 203 is that, a risk management approach to the question would first consider the likelihood of a similar incident occurring again in the timeframe required to determine the root cause of the accident.

Given the safety history of the 777, the length of time in service and the number of flying hours accumulated (even with the same type of engine), and the fact that this is the first time this has ocurred, the likelihood of the accident recurring in the next few months has to be extremely small.

Once more is known about the specific cause, then the risk profile will be reassessed.
blakkekatte is offline  
Old 21st Jan 2008, 22:56
  #222 (permalink)  
 
Join Date: May 2000
Location: Seattle
Posts: 3,196
Likes: 0
Received 0 Likes on 0 Posts
please recall that when you select flaps 25 in the beast Approach Idle is automatically selected. There are several other parameters for this selection but none the less this should give you a fairly rapid spool up in the event of a rejected approach or landing.
However, we do not yet know his configuration at 600'. It it possible they were at or near idle and selected Flaps25 just prior to that, i.e., after the "160 at 4" gate, and the throttles "failed to respond" after configuring and decelerating? Indeed, if the Pilots were at flight idle instead of approach idle, the lack of response could be a bit alarming...
Intruder is offline  
Old 21st Jan 2008, 23:04
  #223 (permalink)  
 
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes on 0 Posts
"The engines seem to have stopped in a staggered fashion the left seems to have been rotating more than the right. what does this indicate?"

Maybe that one landing gear collapsed before the other one did?


If the fuel came from a contaminated source in Beijing I would have thought that it was likely that one or more aircraft could have used that same contaminated fuel source and sufferred engine malfunctions as a consequence?
Maybe only one dead donkey fell into storage tank that day? Our Airbus fuel filters are frequently clogged up with Beijing's finest. A good point was raised about EICAS messages... On the 777, Cautions and Advisories are inhibited below 800' RA. A fuel fiter impending bypass appears as a Status Message (not something likely to cause concern....especially on finals). There are several stages of fuel filtering, by the way.

On the subject of those keen to ground the 777.... If it was deemed to be a pilot error.. do we ground all pilots?

Rgds
NSEU

P.S. I fly Flight Simulator on my days off
NSEU is offline  
Old 21st Jan 2008, 23:13
  #224 (permalink)  
 
Join Date: Jan 2008
Location: Tallong NSW
Posts: 280
Likes: 0
Received 0 Likes on 0 Posts
Has it been established beyond doubt that the auto throttles were armed or correctly set at the appropriate time?
denabol is offline  
Old 21st Jan 2008, 23:20
  #225 (permalink)  
 
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes on 0 Posts
"I doubt whether coffee could penetrate the conformal coating of pcb's and the like, unless they are overheated."

Haven't looked at the wiring under the pedestal in a 777, but there are probably canon plug connections under the floor for the thrust lever position-sensing wiring (trying to keep it simple here for beginners). Oil and fuel get into them, so why not coffee?

However (and I'll say this again for those that weren't paying attention earlier)... there are independent circuits/wiring for each thrust lever. The chances of coffee getting into two different plugs at the same time and causing the same type of failure is rarer than...... 777 accidents.

...and hey, don't they have coffee cup holders on BA 777's??? (They do on their 747-400's).

(Edit) After further checking. The thrust lever position resolvers/wiring are mounted at opposite ends of the very wide assembly under the cockpit floor. The resolvers are not separated merely by the width of the thrust lever knobs. In each resolver, there are two channels (two sets of wiring) which feed the A & B channels in each EEC (fuel control computer on the engine)

Last edited by NSEU; 21st Jan 2008 at 23:47.
NSEU is offline  
Old 21st Jan 2008, 23:32
  #226 (permalink)  
 
Join Date: Dec 2007
Location: Montreal
Age: 92
Posts: 156
Likes: 0
Received 0 Likes on 0 Posts
B777 Heathrow

Someone pointed out the need for more detailed information and I totally agree.
Let us wait for the findings of blackbox and pilot information from an investigation team before starting to speculate the cause.
All options are open and that is some too many.

May I suggest that any technical information is always welcome, such as A/T use on approach, fuel control systems and computer/human decision making. Oh Man!, wasn't the DC3 "simple" in comparison? Maybe, this "simple" fact should be included in the KISS approach to design.
Yankee Whisky is offline  
Old 21st Jan 2008, 23:48
  #227 (permalink)  
 
Join Date: Mar 2001
Location: us
Posts: 694
Likes: 0
Received 0 Likes on 0 Posts
Intruder, if Flight International is correct in saying they were late with the gear, is it not then possible that they were late at the 1000ft gate (configuration wise) and matters got sticky from there.

You Gomboid (in the closed thread) stated that BA SOP (and I'm summarizing) is:
> have gear selected down by 2000ft RA (radio altitude=height above the ground)
> with concurrent selection of flap 20 and 55% N1 (offset 15 knot loss of speed)
> at 1500ft RA, select final flap setting of flap 25 (with small increase in thrust)
> by 1000ft RA, be configured in the final stabilised approach
> at 500ft RA, if not in correct configuration, profile, and speed fly a go-around.

The N1 number at 600ft may speak volumes.
SaturnV is offline  
Old 22nd Jan 2008, 00:09
  #228 (permalink)  
 
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes on 0 Posts
Let us wait for the findings of blackbox and pilot information from an investigation team before starting to speculate the cause.
Not sure that I agree... I know a lot more about 777's as a result of these PPRuNe threads than I did a few days ago because of the theories proposed here. Questions have been raised that I, personally, didn't immediately have an answer to... until I went back to my manuals (or until one of the more knowledgeable forum members responded).

Albeit maddening, it is a learning process.. Unfortunately, some of us don't take on information as easily as others

Let's hope the FDR/CVR have the answers... but as someone already mentioned, it may not have what we are looking for. The FDR may tell us what was happening to the aircraft, but not necessarily why it was doing that. However, hopefully it should reduce the variables

Rgds.
NSEU
NSEU is offline  
Old 22nd Jan 2008, 00:35
  #229 (permalink)  
 
Join Date: May 2000
Location: Seattle
Posts: 3,196
Likes: 0
Received 0 Likes on 0 Posts
Intruder, if Flight International is correct in saying they were late with the gear, is it not then possible that they were late at the 1000ft gate (configuration wise) and matters got sticky from there.
I haven't read FI. Is there a copy of the article on line somewhere that doesn't require a login?

That is, though, one plausible scenario...
Intruder is offline  
Old 22nd Jan 2008, 02:06
  #230 (permalink)  
Paxing All Over The World
 
Join Date: May 2001
Location: Hertfordshire, UK.
Age: 67
Posts: 10,150
Received 62 Likes on 50 Posts
KC13577
I've been told- that much condensation was found to be in the E&E compartment...
Would that be seconds after the a/c came to a halt or an hour later after all the good work by the fire crews? Ten hours later? After the local rain?

Serious questions (I hope) from a pax.
1) Based on a standard approach that follows expectations: from the moment that the engines where required to spool up for touch down - How much time elapses? So, for this crew, from the moment that they knew something was wrong, to hitting the deck - How many seconds?

2) Many have commented on the physical strength of the Triple and that this was a factor in ensuring no loss of life and that the hull could be picked up in one piece. Will the Dreamliner be made in the same way? Or are they moving more towards plastics and composites?
PAXboy is offline  
Old 22nd Jan 2008, 02:08
  #231 (permalink)  
 
Join Date: Dec 2005
Location: No. Cal, USA
Age: 72
Posts: 112
Likes: 0
Received 0 Likes on 0 Posts
Speaking as an electronics engineer with a bit of aerospace experience, I would first suspect the physical components between the thrust levers backwards to the place the two signals fan out to the engines. From what I've read, if the EEC is disconnected from the thrust lever the engine will soldier on at it's current thrust level. In that case, one plausible scenario would be that the thrust lever assembly became either functionally or physically separated from the EEC's. This might happen if the thrust lever resolvers shared a common power supply or the box connected to the thrust lever resolvers had common power or clock circuitry. In the physical realm, I'd look for a broken cable or connector that carried the signals to both engines.
grumpyoldgeek is offline  
Old 22nd Jan 2008, 02:23
  #232 (permalink)  
 
Join Date: Jan 2008
Location: Australia
Posts: 1
Likes: 0
Received 0 Likes on 0 Posts
Realtime Software Engineer

Thought I'd pitch in with some general observations concerning realtime software development in such systems such as boeing 777 avionics, honeywell aims, autothrottle and fadec (I've not worked on these systems but know of them).

Firstly all realtime software is based on modelling. Your software is only as good as the model you have developed.

Very simplistically the model need to do two things. It needs to simplify the complex outside world into an internal representation that is 100% predictive within the expected boundaries of the inputs AND the expected way that various input ranges should work together. i.e. As one set of inputs is moving up the model expects another set of inputs to be moving down, perhaps with a lag, because this is what is physically happening in reality.

The second part of modelling is making the model fault tolerant or fail safe. This is where you try to analyse all possible failure modes (of the inputs) to ensure that your output is still appropriate to the task in hand.

Simplistically this whole model is captured as a specification, testing is done against specification, in the 777, 99% of the code used ADA programming language. ADA's strength is that it you can enforce expected input and output boundaries on functions/procedures/methods and capture programming logic errors on this basis. In other words after completing testing and certification you can be sure your software is 99.9999% accurate to the specification, and adheres accurantely to your model.

The largest problem, by far, for realtime software, is where the inputs fail in such a way that they still provide data that is within the expected range for the model. The software's ability to control is now VERY dependant on whether this particular failure mode, has been anticipated, in the second part of the modelling process explaination above. If it has not been anticipated then this is where the software starts to make bizarre choices in terms of controlling the output.

I believe, IF it is a software problem, it will be due to inputs from measuring devices that have partially failed.

In basic terms my understanding of auto-throttle ->AIMS->fadec process is as follows.

Physical throttle settings in the cabin -> read by auto-throttle module in the honeywell AIMS system -> processing based on internal model -> specific thrust request command to the fadec -> fadec compares request to current measure/calculated thrust - > fadec adjust thrust accordingly.

Even where the auto-throttle is turned off, the auto-throttle module is still doing the interpretation of the manual throttle settings.

When autothrottle is turned on, the auto-throttle makes DIRECT request to be FADEC (via hardware buses) for appropriate thrust based on its calculations, and the auto-throttle THEN sends a signal to the physical throttle servos to move the physical throttles in the cabin for feedback to the pilots.

Each engine has its own FADEC. The auto-throttle would appear to be working within its model, as the pilots have reported that auto-throttle detected lower speed than set, and requested additional thrust, and communicated this to the pilots via the physical movement of the throttles in the cabin.

AIMS connection to each fadec is via dual bus channels. I find it hard to believe both channels to both engines failed simultaneously (that's four channels failing at once).

Reports from the captain said that half the displays blanked. This would be consistent with a loss of electrical generating power from the engines. On detecting a power loss, the system switches to battery, cuts all unessential systems (i.e. only one set of displays), and commands the APU to start. Once the APU starts and stabilises voltage (30sec- 1minute) the non-essential systems should restart.

IMO the blanking displays is part of the engines spooling down past idle, not the cause of the engines spooling down.

Loss of electrical generating power from both engines would only occur if the electrical power management unit completely failed - as per the qantas flight going into Bangkok earlier this month - or if both engines spooled down past idle.

Given what we know about the engines, it seems clear the engines spooled down past idle, causing the power failure and not the other way around.

Loss of communication between the AIMS and both FADECS, i.e. multiple bus failure, would not cause this. Loss of power to the AIMS system would not cause this. In simple terms the FADECS proceed with the last thrust command until commanded otherwise.

I do not know what unit commands the fadecs to turn-off the engines. But that request will be so tightly predicated, for that to happen, literally hundreds of inputs that confirm that the plane is on the ground would have to be met. I don't believe that this command could be sent accidently by the software or through a modelling error. (Reset, restart, dealing with flameouts, if not dealt automatically by the fadec, would be a different set of predicates, but the same meticulousness would still apply. Many conditions would have to be met to allow this command to go ahead.)

To me the areas of interest are the fadecs on each engine, the inputs to the fadec that give feedback for actual measured thrust, the fuel management system, the fuel level sensors, and the fuel.

I can't see that both fadecs would fail simultaneously. Even if physical conditions outside the plane caused, say, engine thrust inputs to falsely give a high reading, the fadec would not spool the engines down past idle, based on this.

My best guess is that it is something to do with the fuel level sensors - which I believe are ultrasonic - and would go for the subtle, swopped inputs problem, as this by definition means the model is working in the fault-tolerant area of its model.

a. Swopped inputs.

For example, Sensor for Tank A is plugged into input for Tank B. Sensor for Tank B is plugged into input for Tank A. This would cause the system to swop from a full tank to an empty tank. Obviously with more sensors and more possible combinations of swopping you can see how you could have fuel on board, yet not get fuel to the engines. Obviously the swapping could be more subtle, even a digital swopping. i.e. If a sensor unit connects to the data-bus, and the unit malfunctions and starts sending out levels under multiple valid sensor ids, you can see how this would confuse the fuel management system. Don't know if this is possible in exactly this fashion, but you can see how swopped inputs, digital or physical, can cause havoc.
realtime_it is offline  
Old 22nd Jan 2008, 02:24
  #233 (permalink)  
Nemo Me Impune Lacessit
 
Join Date: Jun 2004
Location: Derbyshire, England.
Posts: 4,091
Received 0 Likes on 0 Posts
Thanks Going Boeing, stupid me!!! The engines were GE??B2.
parabellum is offline  
Old 22nd Jan 2008, 03:30
  #234 (permalink)  
 
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes on 0 Posts
This might happen if the thrust lever resolvers shared a common power supply or the box connected to the thrust lever resolvers had common power or clock circuitry. In the physical realm, I'd look for a broken cable or connector that carried the signals to both engines.
Let's put this one to bed....

#Each dual-redundant channel (A & B) of each engine EEC can supply the individual left/right thrust lever position resolvers with power (excitation).
Each EEC channel is powered by individual windings in a permanent magnet dedicated engine-driven alternator (which can function at a mere 5% N3... although some sources quote 8%). There are also independent sources of power from the main AC busses (Left Bus feeds Left engine EEC, etc) should the dedicated generators fail.

#Separate wiring with large gap between (see a few messages above) the position resolvers.

A picture is worth a thousand words... but all the pics I have are protected by copyright.

Rgds.
NSEU

(Edited for clarity)
NSEU is offline  
Old 22nd Jan 2008, 04:32
  #235 (permalink)  
 
Join Date: Sep 2001
Location: Toronto
Posts: 2,558
Received 39 Likes on 18 Posts
Investigations of approach accidents often include review of FDR (and QAR if available) data from the last few a/c that did the approach for comparison pupposes. If a 777 did an approach shortly before at about the same weight, contrasting the two sets of data may help identify where it started to go wrong.
RatherBeFlying is offline  
Old 22nd Jan 2008, 05:11
  #236 (permalink)  
 
Join Date: Aug 2007
Location: CYWG
Age: 43
Posts: 1
Likes: 0
Received 0 Likes on 0 Posts
have these pictures from the landing been posted yet?

a member if Anet took them and had to wait until they got them back from the authorities...

http://www.dailymail.co.uk/pages/liv...n_page_id=1770

scrubbs is offline  
Old 22nd Jan 2008, 07:06
  #237 (permalink)  
 
Join Date: Aug 2003
Location: Hampshire physically; Perthshire and Pembrokeshire mentally.
Posts: 1,611
Likes: 0
Received 0 Likes on 0 Posts
Gatbusdriver,

A CDA is not a descent in idle, it is a continuous descent (min I believe is 500fpm) with an allowable level segment (without checking think it is 2 mile i'm sure someone will correct me).

Therefore once you are established on the glide most people will only be at approach idle to get the speed back after 4 miles, where you have invariably been maintaining 160kts.

Ergo I think CDA's have little bearing on this incident.
Thanks, but I know that. I have seen plenty CDAs which do result in a descent at idle to inside four miles, especially at LHR where the controllers will cut you in short if there is an opportunity for them to do so - just as they do at LGW. That's why I posed the original question.
Wingswinger is offline  
Old 22nd Jan 2008, 07:47
  #238 (permalink)  
 
Join Date: Jun 1999
Location: Oztrailia
Posts: 2,991
Received 14 Likes on 10 Posts
Well if that is a photo of YMMM on the day then 2 observations:

1/ Nose Gear Landing Lights are on
2/ No Rat deployed.

Indicates they had plenty of AC power running.


mmmmmmmmmmmm

Plot thickens..................I think it's time we called in Inspector Morse.
ACMS is offline  
Old 22nd Jan 2008, 07:51
  #239 (permalink)  
 
Join Date: Jun 1999
Location: Oztrailia
Posts: 2,991
Received 14 Likes on 10 Posts
Mate it doesn't matter, if both transfer busses were unpowered, as some suggested from a dual engine failure, then high Powered AC Landing Lights would NOT be running AND you'd see the RAT.

So they had at least one Eng AC Gen online.

Either the crew attempted to start the APU or it Auto started after the impact knocked off the Transfer Busses?

Who knows.
ACMS is offline  
Old 22nd Jan 2008, 08:04
  #240 (permalink)  
 
Join Date: May 2000
Location: UK
Posts: 737
Likes: 0
Received 0 Likes on 0 Posts
The RAT is clearly visible (under R2) in many post accident pics, and the APU inlet door is open too.
squeaker is offline  


Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.