British Airways Flight BA38 Crash Lands At Heathrow Airport

No comment.

AAIB yesterday issued a further update, which doesn't add a lot - although one safety recommendation regarding fuel cut-off valves has been made.

So far it seems the engines were not the problem.

Air Accidents Investigation Branch: S1/2008 - Boeing 777-236 ER, G-YMMM

P.S. Good luck for March. I'm sure you won't need it but it's nice to have, regardless.

Lol, this reminds me a lot of my doctor. "Take two aspirin and if it doesn't get better, come back tomorrow."

The results sound like a whole lot of words around nothing conclusive. The debris and parts found in the tank sound a little interesting, but I don't see anything that could have caused a serious blocking in the fuel lines. Cavitation on the HP fuel pumps sounds like something, but without knowing the maintenance intervals and service times of these parts, I don't want to judge the significance of it. The rest of the damages seem to be accident consequences.

I still vote for a software glitch, a program crash or abnormal termination. Surely it won't show up in the volatile memories, but I'm not sure whether such a termination, if it only appears in a part or a subsystem, would be recorded. A computer expert's opinion on this, please?

Oh, and thanks to your luck! I'm hoping for the best, since I have quit my job and am on residual leave since Monday.

That was both our initial thoughts if I recall; software and I've read nothing to make me seriously question that. The debris is interesting but again being no expert in that regard it's hard to assess the significance, if any but it seems unlikely to have been a significant factor. It seems the AAIB don't either.

Computer glitches can be hard to prove though, and without knowing precisely what is and isn't logged it's hard to guess if it's a systemic flaw or an anomaly due to a random, but very rare set of circumstances, or a transient failure in one or more minor components but that's just speculation. Hopefully the simulations will through something up.

Not to have a definitive cause would have worrying consequences. Especially in light of the recent B787 software 'scare'. There doesn't have to be a real problem to cause a real problem, if that makes sense?

Enjoy the (hopefully brief) spell of unemployment.

I'm booked on BA38 soon, guess a few will be hoping it crashes better next time.

Or that it crashes not at all. Soft landings.

Thnaks - I'll think of you if we go down

A severe software error, such as a complete crash of the concerned program due to sensor miscompares or input errors (missing, confusing or senseless signals) would surely be logged. But I'm not sure if this would also happen if the program abortion happened due to a pure computer error (run time error, division by zero, etc); I admit that I am no expert for systems architecture and don't know the 777's electrical system's details. However, the fact that no physical evidence for an error has been found so far would point to an error either inside the computer workings, or a completely external error source (EMP gun, cosmic background radiation penetrating a computer chip and altering a 0 to a 1, rather improbable). And I still stick with my theory: At cruising altitude and with time for a system reset, I'm sure this accident would not have happened. But 2 mi short of the runway and at 600 ft, there is no time for a system reset.


Just keep your thumbs crossed that I won't run into the same situation during my check flight.

Something severe like that absolutely I would expect that to be logged, on routine code execution though I don't know what level of logging exists, presumably just exceptions and such like.

Again I'm not familiar with any redundancy or cross checking between computers in the different systems. A random state change does seem unlikely, but a perverse combination of values causing a problem by way of correct execution of incorrect programming is plausible and probably hard to replicate. Again I'm really just guessing, my knowledge of Aircraft systems is limited to what I can obtain online, or ask.

As to the the timing, I agree. Even a couple of minutes earlier and I'd think it would have been recoverable, with a go-around if necessary.

Lightning and all that...

If it does, let's hope you can walk away too. After all if you do, that's a safe landing.

That does sound probable Claire. Is there anything unusual about the pilot or system's procedure at all? Is requiring additional thrust at that point in flight unusual? When it comes to programming, you have to anticipate all possible scenarios under which your program may need to have something happen; need to have a process for all possible situations in which that program may be asked to respond to all possible input combinations. It's certainly not easy to do so and it requires immense amounts of code written, and compiled, perfectly. It's rare that happens though. It's very rare to find any complex program that doesn't need glitch fixing down the road. The most obvious example is Windows update. While Windows (I hope to GOD) doesn't run any airplanes, the updater demonstrates that even years after production, flaws can still be found. The more complex a program or set of programs is/are, the less chance there is finding every possible scenario in which the program will do something unintended.

Even Windows though, as I'm sure you've seen, can capture some errors and record them before a systems crash, but not always. A fatal error, aka The Blue Screen of Death, may not be captured before a crash if the process which runs the crash recording dies along with the rest of the operating system. You would need, in effect, a separate computer running a separate operating system, to monitor and record what happened in the primary system it monitors. I don't know if the planes have such a thing.

Flight parameters are always logged in the DFDR and QAR, and these data have been exploited. In addition, theres a FDAU, a recorder that counts error messages in various systems, sorted by flight intervals. It doesn't make big news since its data is always inconclusive, and a "0" in its log doesn't automatically mean no error, it can also mean that the system isn't installed.

Exactly what I was referring to, something like a good old run-time error, and a processor going haywire through an operation that is correct, but doesn't produce a reasonable result. Code termination, and more false signals in the electronics hence ensue.

I'm not so sure of that. The timing is peculiar here, it would take a little more time to push the required circuit breakers and switches for a restart. Also, one must figure in that probably an engine restart could be necessary. A few minutes earlier could have left more time to make a decision, however, and give the pilots a better chance of selecting and proceeding to a site for an emergency landing.

There is nothing unusual at all. The thrust serves to control the pitch angle, and smaller corrections need to be done all the time. Plus, power would have to be added if a Go-Around maneuver was necessary. Also, a manual power application would override the automatic system, and would surely be taken into consideration when the system had been designed.

Windows can't serve as comparison here. These systems are hardware-based and consist of input/output user interfaces, plus a programmed processor unit. And they are not free of glitches either, of course. Most errors are debugged during flight and non-flight testing, but some errors hide until the systems are used in line service, very much like windows or other software.

A little criticism of my side would have to go to the pilots, though. Obviously, they didn't disconnect the autopilot as the spool-down occurred, this way the automatic system kept heading towards the runway at the pre-programmed speed/angle set-up. My first reaction when I had noticed that neither auto-thrust nor manual application of power help would have been to hit the red button and put the plane down manually, short of the runway if necessary, but definitely as long as I still have the speed and scope.

And another thing is just catching my eye: Obviously, there has been no alert due to fuel or lubricant anomalies. A decrease in fuel pressure, unusual fuel temperature, oil pressure loss or similar would have been recorded by the DFDR, and announced to the pilots. This makes the whole thing look even more like a computer matter to me.

Computers...can't live with them, can't pee down the back.
That's the thing, being unable to reproduce and thus deduce the cause.

Having thought about that since I posted, I agree with you, had this happened a mere couple of minutes earlier it could have ended much worse. Much earlier and yes, there would have been time to explore alternate scenarios.

As you say, the architectures are very different.I recall in the B777 thread a similar comparison to 'retail' software was made. The use of a (presumably) hardened version of Windows 2000 by the US Navy was interesting though. It's true that too much bug finding happens in the real world, much like any 'software', really.

I agree that once a manual request had failed, continued reliance on automatics for any lengthy period (which they didn't have) could be questionable, though with the application hindsight I'd think the crew are wondering the same thing. Of course, the little Cessnas I flew years ago didn't have a red button (of that sort) so I'm in no real position to judge.

In the report there was mention of 'unusual' but not extreme cold en route, although that was very early on in the flight and (recorded) fuel temperatures never reached or even approached limits. In any event the fuel as tested by AAIB had a freezing point far below minimum spec and well within the 3 degree margin.

It does look more and more like an automation problem. Quite worrying really eh, Drifter^^^^^just kidding you.

If the problem can't be reproduced then perhaps they don't need to worry about it?

The AAIB has published an interim report suggesting ice in the fuel system restricted fuel flow to both engines. Below is a quote from the summary at the end of the report:

The investigation has shown that the fuel flow to both engines was restricted; most probably due to ice within the fuel feed system. The ice is likely to have formed from water that occurred naturally in the fuel whilst the aircraft operated for a long period, with low fuel flows, in an unusually cold environment; although, G-YMMM was operated within the certified operational envelope at all times.

All aviation fuel contains water which cannot be completely removed, either by sumping or other means. Therefore, if the fuel temperature drops below the freezing point of the water, it will form ice. The majority of flights have bulk fuel temperatures below the freezing point of water and so there will always be a certain amount of ice in the fuel.

To prevent the ice causing a restriction requires either: the fuel system must be designed in such a way that the ice in the fuel does not pose a risk of causing an interruption of the fuel supply to the engine or; prevention of the water from becoming ice in the first instance. Changes to the fuel system design could make the system more tolerant, but would take time to implement and would certainly not be available within the near term. Therefore, to reduce the risk of recurrence interim measures need to be adopted until such design changes to the fuel system are available.
...

Full report: http://www.aaib.gov.uk/cms_resources...m%20Report.pdf

I briefly browsed through their report and their conclusions look reasonable but unsatisfying. Since it's a interim report, I assume the investigation is continuing.

Ice?? Odd. Of course I'm talking out my ass as I'm not a jet engineer nor a pilot. Not what I expected. Never heard of this.

Thanks for the update Steve, I appreciate it.

Ice is suspected but they can't prove it as of yet. The aircraft flew through some unusually cold air.