Slashdot Mirror
Software Bug Caused Qantas Airbus A330 To Nose-Dive
pdcull writes "According to Stuff.co.nz, the Australian Transport Safety Board found that a software bug was responsible for a Qantas Airbus A330 nose-diving twice while at cruising altitude, injuring 12 people seriously and causing 39 to be taken to the hospital. The event, which happened three years ago, was found to be caused by an airspeed sensor malfunction, linked to a bug in an algorithm which 'translated the sensors' data into actions, where the flight control computer could put the plane into a nosedive using bad data from just one sensor.' A software update was installed in November 2009, and the ATSB concluded that 'as a result of this redesign, passengers, crew and operators can be confident that the same type of accident will not reoccur.' I can't help wondering just how a piece of code, which presumably didn't test its input data for validity before acting on it, could become part of a modern jet's onboard software suite?"
The worst part is that Google wants to build a driverless car. Flight pilots have been trained to react to emergencies in a calm manner and they have time to do so while in air. Neither is true for cars. People will panic when something goes wrong, and there won't be any time to react to them. Your life (and others life) will be completely dependent on the AI, and lets face it, there will be bugs.. Google isn't exactly known for bug free products. Hell, even NASA has bugs and they use billions so that there wouldn't be any. I just think it's a really bad idea and Google is being irresponsible and malicious with such project. Of course they will also hide some "we are not responsible for accidents in any way" under some clause. Let me just say that somewhere in the future we will be hearing how Google killed some innocent people and children.
Instead of what is it now: "what are the odds that we should be in a nose-dive? well, nothing else seems better."
Probably more like, "the sensor spec sheet says it's right 99.99999% of the time. may as well assume it's right all the time".
The devil almost surely lives on a set of zero measure.
the idea that a bunch of automatically piloted vehicles is somehow a better solution to city transport than mass-transit, it boggles my mind.
real people do not have money to maintain their cars properly. things are going to break. there are not going to be 'system administrators' to fix all the glitches that come up when cars start breaking down after a few years.
there will be problems. do i know which problems? no, but i know the main problem.
arrogance amongst revolutionaries. it is historically a pattern of the human species. declaring that nothing could go wrong is usually a precursor to a lot of things going wrong. not because the situation was unpredictable, but because human beings in an arrogant mindset tend to make a lot of mistakes, be reckless, and try to cover their asses when things go wrong.
but successful engineering is the anti-thesis of arrogance. nobody worth his salt is going to say 'what could go wrong'? they are going to have a list of 500 things that could go wrong, and all the ways they have tried to counter-act those wrong things happening.
I'm sure they must have more than one sensor. Perhaps even more than one sensing principle is involved. The problem with the system of having multiple computers vote, is we tend to solve problems in similar ways, so if there is a logic error in one machine (as opposed to a typo) it is fairly likely to be repeated in at least 2 of the other machines. Some sets of conditions are very hard to predict and design for. Even in the most simple systems. I often see code (when updating a system) that does not account for every possibility because either everyone considers that combination unlikely, or nobody thought of it in the first place(until it happens of course...) Being a perfectionist in this business is very costly in development time.
The fact is a complex system such as an aircraft could easily be beyond human capability to perfect first time. And test completely.
I have determined that my sig is indeterminate.
From out here it's hard to distinguish between 'forgot what the specification said they should do' and 'didn't bother to read it in the first place'. Even if your 10 testing guys knew it was in the specification doesn't mean they necessarily understood how to test it properly, and maybe did some sort of relative test (input of x should come out to be 10x in a simple example). The problem with using the wrong unit of measure is that the math is, in isolation all correct and self consistent, it's just off by a constant - which just happens to be enough to cause catastrophic failures.
In the case of an aircraft using only once sensor in the article, did it read in data from all the sensors, and just ignored some of the input? Did it average the inputs, (which, naively, isn't a bad answer, but fails badly when you have really wonky data), was there some race condition in their resolution between multiple sensors? That's a fun one, maybe it works on data on poling intervals and in very rare cases it can read data from only one sensor and not the others and so on. Even if you know the specification it can be tricky to implement (and realize all of the things that can go wrong, it's not like all of these people doing the calculations are experts in distributed systems necessarily, they might be experts in physics and and engineering). Doing something simple like taking an average of an array can fail in really bad ways - what if the array isn't populated on time? How do you even know if the array is fully populated? How does my average handle out of bounds numbers? How about off by 10^6 numbers? Does old data just hang out in those memory addresses, and if so what happens to it? A lot of those underlying problems, especially with how the array (or in this case probably how a handful of floats) is populated and is it aware if it is properly populated are handled by the implementation of the language, which is well beyond the people who actually do most of the programming. And not everyone thinks 'hey for every line of code I need to go and check to make sure the assembler version doesn't have a bizarre race condition in it', assuming you could even find the race conditions in the first place.
Yes. Human pilots can fuck up as easily as anyone else.
But in an emergency, I'd rather have a human pilot making the decisions and being in control.
On Airbus vehicles, if the avionics computers crash, the airplane crashes. There's exactly ZERO way to pilot the computer manually in such a failure.
Moreover, the avionics system can and does overrule pilot input. So if you get sensor malfunctions like this, even if the pilot is trying desperately to save the plane, the computer can still crash you.
On Boeing, if the avionics computer fails, the pilot at least has a chance of saving the aircraft.
You can come up with all the sleepy, crazy, stupid, drug-addled, locked in a bathroom with a stewardess horror scenarios you want.
What would you rather have in a failure scenario? A slim chance or no chance?
Chas - The one, the only.
THANK GOD!!!
It looked like half of one 32-bit word was combined with half of another 32-bit word during queue assembly on at least some occasions. But there are errors not explained by that.
This is why I like fuzzing. Sending random and/or corrupted data to software to evaluate the software's robustness and sensitivity to corrupted inputs. For a project like this I would like to send simulated inputs from regression tests and recorded data from actual flights to the software while fuzzing each playback, repeat. Let a system sit in the corner running such tests 24/7.
In theory some permutation of the data should eventually resemble what you describe.
Speaking as a pilot, I care a great deal where I am right now because it may affect whether I'm going to hit another plane. I've been close enough to see the crew of another plane and felt safe because I first spotted him nearly two miles out and knew where he was the whole time, and I've leveled off out of a take-off to see another plane inside of a quarter mile and was shaken by the experience. I know that a quarter mile seems like a long way, but when converging airspeeds are in the range of 150 knots, there's very little time between seeing him and a collision, and I want to know when someone is passing 500 feet above or below me or is on a potential collision course.
We maintain distance (something that falls into your definition of "everything else") for a reason. My plane's max cruising speed is only about 130 knots, but the Baron over there has a max speed in excess of 200 knots. If we're both tooling around max and closing on reciprocal courses, that's a potential closing speed of 235 knots--4.5 miles per minute. If we're two miles apart, we have less than 30 seconds to see each other and properly maneuver. I've also had a plane pass over me close enough that I could hear his engine over mine, and that's the last time I want to hear that sound.
I measure where I am because that is by far the most important. Where I will be is secondary. The basic rules of piloting: Aviate, navigate, communicate. Fly the plane as it is, figure out where you're going, tell someone where you're going. Notice that the first is where I am right now. The second one deals with where I'm going to be, because I almost always have options, even if it means turning around and going back where I came from.
You're either not a pilot, or one who I don't want to be within 100NM of.
You can never go home again... but I guess you can shop there.
injuring 12 people seriously and causing 39 to be taken to the hospital.
That is why you keep your safty belt shut.
If you don't like the feeling, losen it a bit, but keep it closed.
I really wonder why people keep taking such nonsense risks and open the seat belt directly after launch.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.