TL;DR: This incident was, as usual, the result of multiple failures happening together.
1. An airspeed sensor starts outputting intermittent data spikes. This is a software failure, but they still don't know what caused it. There is some theory about high energy particles hitting the CPU. It seems very strange to me that a critical system like this can output garbage data and nobody knows why.
2. The flight control computer usually detects these spikes and filters them out by using the last good data for the next 1.2 seconds. However, at the end of the 1.2s, it assumes that the input from the sensor is good. If another spike is occurring at the moment it switches back, it isn't detected. That seems like a rookie mistake to me. I've definitely run into the same sort of issue in other contexts -- handling a second event while reacting to the first one.
Happened in November 2010 in the timespan of 4 days. (I think there were even more but this is what I remembered I can quickly grab from http://goo.gl/FgcAv)
http://www.atsb.gov.au/media/3532398/ao2008070.pdf
is the final report. Quite a scary read. 30 warnings on the displays with master caution and master warning going on and off. All of it because of a bug where the binary representation of the altitude was interpreted as angle of attack and a design problem in the flight computer which does filtering on the signals but couldn't cope with spikes exactly 1.2 seconds apart.
Result - the vertical acceleration went to -1.5G in 3s and then to 1.7G in the next 2s. That can look something like this
http://www.faa.gov/other_visit/aviation_industry/airline_o...
I don't understand why the flight computers don't perform more aggresive smoothing on the signals from the sensors - AoA just can't go from 4 deg to 50 deg in 1/25s.
I think the biggest problem is simply that it was a software bug that occured infrequently enough. To change a working piece of software that has thousands if not millions of problem free flying hours behind it is not something you do "just because". It requires lots of analysis and testing to make sure that they don't introduce new problems.
> The air-speed sensor malfunction was one of only three such malfunctions known worldwide in 128 million operating hours ... In a strange coincidence, all three sensor malfunction events occurred on Qantas flights off the coast of Western Australia.
This line in the article seems designed to elicit comments about "the Christmas Island triangle" and "Canberra conspiracies".
I've got great faith in planes as a whole, but these sudden vertical accelerations (wind pockets etc) is one area where they don't seem to have much of a plan aside from hoping you're wearing a seat-belt at that particular point in time.
Maybe they should add something crumple-zone like in the panel above the passengers heads. Or put something air-bag like there.
I don't think they can add much crumple zone up there - that area has to be strong enough to hold people's luggage.
(On another note, I'm a very nervous flyer, and I put my seatbelt on as soon as I sit down, and don't take it off unless I'm using the restroom, or until we're at the gate. Hurray, paranoia!)
Effectively never. The fuel is kerosene which has a high flash point, and the plane is grounded to the refuelling apparatus to prevent any static sparks.
Does anyone know why an investigation like this takes three years? I would have guessed that since the plane landed safely it would be a pretty quick diagnosis.
Airbus could easily be the most unsafe major airline in history. No surprise when I read this article that it said this happened on Airbus. Those things have a nasty habit of randomly crashing for no reason whatsoever. Unfortunately planes cannot be booted back up after a crash. I would not be caught dead on an Airbus because that is probably what I would end up being, dead.
1. An airspeed sensor starts outputting intermittent data spikes. This is a software failure, but they still don't know what caused it. There is some theory about high energy particles hitting the CPU. It seems very strange to me that a critical system like this can output garbage data and nobody knows why.
2. The flight control computer usually detects these spikes and filters them out by using the last good data for the next 1.2 seconds. However, at the end of the 1.2s, it assumes that the input from the sensor is good. If another spike is occurring at the moment it switches back, it isn't detected. That seems like a rookie mistake to me. I've definitely run into the same sort of issue in other contexts -- handling a second event while reacting to the first one.