Slashdot Mirror
Failed Avionics a Possible Cause of BA038 Crash
Muhammar writes "As you may have heard by now, both engines of the Boeing 777 aircraft flight BA038 suddenly cut off without warning at very low altitude and low speed during autopilot-assisted landing at Heathrow. A prompt reaction of the pilots prevented the stall and saved all lives aboard. The crash landing short of the runway tore off the landing gear on impact, and the fuselage plowed a long, deep gouge in the grass. With the investigation ongoing, the available information points to an electronic control problem as the most likely cause of the sudden engine power loss."
If it is a software problem, then expect more public scrutiny of software based machinery. Especially after the US Senate vs UK debacle over the source code for the new joint-combat fighter.
My little Linux and tech blog
A bit of FUD here I think - unless I read TFA wrong, the entire thing is under investigation and no one is saying anything for at least a month. The autopilot apparently sensed the need for more thrust and warned the pilots of this. It might be premature to say that a software problem is the likely cause of failure...
"As the intrepid kobold companion continues his journey, he begins to wonder... if priests raises dead, why anybody die?
They actually have a decent excuse for lost luggage for once.
If you haven't made a developer cry, you've wasted a day.
The pilots then manually increased throttle - to no avail.
For both engines to malfunction like this at the same time greatly seems to point to a fuel delivery problem.
This does not necessarily mean "running out of gas" - as a plane like this has multiple tanks, valves and pumps, all of which can be configured multiple different ways - which change during the flight.
A simplistic example: they could have been running both engines off one tank - which went dry - though another was full - or both engines were being fed from a common fuel pump which failed, etc. These things *shouldn't* happen - but the investigation will tell...
"It might be premature to say that a software problem is the likely cause of failure..."
Unless it was running on an OS like Windows for Aircraft, "now with fewer crashes".
Yes, I know it's all custom designed. But thinking about the infamous Windows for Warships I couldn't resist
"It is a greater offense to steal men's labor, than their clothes"
Now we're all going to be forced to re-learn Ada!
What I've read is that the pilots observed a relatively gradual loss of power symmetrically on both engines. This tells me that I can rule out engine problems with FADEC and fuel. It all points to the auto-throttle. Autopilot tells where it wants the plane to go and autothrottle calculates how much throttle is needed. It then commands both engines FADECs via the bus system which is doubly redundant. What I'm thinking is that auto-throttle is supposed to be backed up, bypassed by a manual direct control to the engine FADECs from the cockpit throttle control?
Any B777 avionics mechanics around - I only know military jets...
www.tribalnetworks.org - helping tribal people around the world to own their own means of high-tech communications
Actually, it's more like "nucular", "gubmint", and "librul".
I've read several summaries, such as this one, which state that the pilots did something to save the lives of the passengers. But I've never read a news article that provides the information that supports this claim. I'd like to read about what the pilots did to save the situation. Can anyone point out a news article that is actually coherent, and tells more than how many 777s are in service around the world?
Let's just wait for the official forensics rather than patched together rumours shall we?
AT&ROFLMAO
It's uncanny how they made the flight control system sound just like my wife.
As Coward stared at the controls, the autothrottle demanded more thrust.That's a feature that is sadly lacking, though.
Show me on the doll where his noodly appendage touched you.
Given that the plane is heavily instrumented, available, and didn't burn, this should be a simpler case to examine. Hopefully, a lot can be learned. At least more than if it crashed and burned in a jungle, or into the ocean.
A little bit of perspective here.
First, there were MANY credible witnesses that swore they saw a missile shoot into the sky before the explosion. Of course, it turned out to be the different trajectories of the airplane pieces, but that was only figured out after a detailed analysis of radar records.
Second, prior to Flight 800 the terrorist explanation WAS more likely - I don't think a modern airliner had EVER exploded by itself before that, but there had been a few that did it with outside help.
Finally, the intelligence and police agencies were careful NOT to peg it on terrorists as the only theory. It was the news media that ran with the "Arabs and Stingers and Bombs Oh My" stories incessantly. Yeah, the government floated the idea - because it was a definite possibility. What are they going to say? "We have some eyewitness acounts of what looks like a missile launch, but we have definitely ruled out terrorist involvement."
As an aside, where are the Flight 800 "Truthers"? Why isn't anyone blathering about the conspiracy to hide the REAL reason Flight 800 blew up?
"As God is my witness, I thought turkeys could fly." A. Carlson
So how many airlines are still flying the De Havilland DH-50 anyway!?
AT&ROFLMAO
The problem was not computers. After extensive investigation, the authorities
have released what actually caused the accident. The evidence is clearly visible
in these pictures:
http://www.heathrowpictures.com/pictures/images/picturegallery_baw_b772_gymmm20.jpg
The cause for the engine problems is massive ingestion of dirt. The manuals clearly
specify that the engines need to be run on air, not dirt. Even small quantities
of dirt can cause loss of power.
Posting anon for obvious reasons.
:)
I work in the avionics industry and this was exactly my thought as well. These systems are becoming much more complex than you would expect embedded software to be. Several address spaces and over a dozen threads is fairly normal with most newer systems.
Typically the safety critical industry likes to tout itself as being better designed than other software because it conforms to various standards, particularly do178b. At their core, these standards basically say you need to have processes that everyone understands in place when you design your software and you need have documentation that shows you tested all the different elements of functionality. The testing may be fairly rigorous depending on who is doing it, but at the end of the day they arent doing much that microsoft/oracle/your favorite well known software vendor doesnt do. (although I am sure that many here beleive that ms doesnt test its software)
The first linked article is more-or-less gossip, and gives no reason to blame the avionics. Not to say that it wasn't, but we want some evidence. The second is a much more reasoned article, and gives a number of possibilities, including avionics but also a number of others, all of which is possible. My favourite is fuel contamination - but we shall see.
The simple "running out of fuel" hypothesis is very unlikely. All aircraft are supposed to carry reserves to divert to another airport (not far in this case) plus ninety minutes flying. While cheapo airlines might short-cut on this, I cannot imagine BA doing so. There is no indication that the aircraft had been "stacked" for any length of time, so it shoudl have landed with two hours worth of fuel on board. There have been cases of aircraft being misfueled, but on a regular run between two sophisticated endpoints, this seems unlikely.
Consciousness is an illusion caused by an excess of self consciousness.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Maybe that's your current thinking, but it doesn't necessarily reflect reality. Turbine engines don't "switch into reverse". They do have thrust reversers, but that's a mechanical device that redirects the exhaust flow. They're typically activated in the "last stages of landing" i.e. after the plane is fully on the ground.
There are a set of interlocks involving both weight being present of the landing gear and the wheels rotating to prevent the reversers deploying.
First, there were MANY credible witnesses that swore they saw a missile shoot into the sky before the explosion.
a) no, they were not credible, and
b) they by and large didn't claim they saw "a missile".
What they claimed is that they saw a "streak of light" or some variation thereof. Only a few people claimed they saw "a missile", and those people by and large are the people that made it onto the news. So it probably seemed like there were more of them than there were. The news outlets chose the most radical, attention whoring witnesses to put on the air.
But if you read the NTSB report, they break down the witness statements. Out of something like 2,000 witnesses, only a relatively small percentage (I'm remembering it being something like 25%) saw a "streak of light". Of that percentage, about half saw the light going up, half saw it going down. Some saw it going to the left, some going to the right. In other words, none of them had any idea what they were looking at.
This is pretty normal for witnesses to an airliner crash. Nobody's expecting to see what they're seeing, so their mind initially doesn't record things correctly. What the NTSB has to do is filter out the crud and see if there's anything that everybody agrees on. If there is, then they investigate that. In this case, a large enough percentage of people indicated they saw a flash of light, and that ended up supporting the mid-air explosion theory.
But the NTSB never gave any real credence to it being a missile. Neither did the FBI, for that matter. There was just never any evidence. The FBI had pretty much ruled out terrorism within 2 days of the accident.
Please post this at every /. article on aviation.
People, if you are so interested in aviation then get off the couch, take lessons and get some first hand experience. I know little airplanes are not completely the same as big airplanes, but you will be closer to some factual opinions.
Each engine has its own separate EEC. Each EEC has full authority over engine operation. In the normal mode, the EEC sets thrust by controlling EPR based on thrust lever position. EPR is commanded by positioning the thrust levers either automatically with the autothrottles, or manually by the flight crew.
Engine flameout protection is provided for an auto-relight and rain/hail ingestion. The auto-relight function is activated whenever an engine is at or below idle with the FUEL CONTROL switch in RUN. When the EEC detects an engine flameout, the respective engine ignitors are activated.
Fuel is supplied by fuel pumps located in the fuel tanks. The fuel flows through a spar fuel valve located in the main tank. It then passes through the first stage engine fuel pump where additional pressure is added. It flows through a fuel/oil heat exchanger where it is preheated. A fuel filter removes contaminants. If the filter becomes clogged, the filter will be bypassed, passing fuel directly to the engine. In that case, a Advisory EICAS message "ENG FUEL FILTER L/R" will be displayed.
When main tank fuel pump pressure is low, each engine can draw fuel from its corresponding main tank through a suction feed line that bypasses the pumps.
Trans-Atlantic flights are often 90 minutes of flying time from a suitable runway. Trans-Pacific flights can be 3 hours or more of flying time from a suitable runway. Needless to say, airlines cannot glide with no power for hours. Air Canada Flight 143 (see http://www.wadenelson.com/gimli.html) was estimated to have a glide ratio of 11:1 with both engines windmilling. So from 40,000 ft, the maximum glide distance would have been about 100km. Sink rate was estimated at 2000 ft/sec meaning with all engines out, you will be visiting some destination at sea level within about 20 minutes.
Yep, the plane was actually punctured and he was hit, you can see the hole on the RHS of the aircraft behind the wing, just under windows.
Anyway, his recollection indicates that the plane was punctured before it touched the ground. If that were the case, his "hole" would probably be the point of failure.
I think it is more likely that the puncture happened after the plane hit the ground, caused by debris from the right landing gear ripping away. It would be like this--plane touches down on grass (he thinks they're still smooth in the air); wheels dig in rip off, and punctures hull in quick succession (he has been hit); the plane starts scraping along the hull and engines (he feels the plane "hit the ground hard").
So it's probably just a slightly misleading passenger recollection, but something to think about while we're guessing about the control systems.
Damn, I already moderated this topic. Now I'll have to log in with my sock puppet to comment.
It is indeed far more convenient to blame the pilots, regardless of the real cause. However in this case Boeing and BA and Rolls Royce have no such an easy way out. The airplane was on autopilot when the error occurred. Pilots involved themselves only when they had to, after the failure was apparent. In addition, they have megabytes of data intact on all flight data recorders, and they won't be allowed to change even a single bit of that, since these companies are not the investigators.
It may not be just a software bug. It may be that the software cannot handle some unforeseen hardware state, as happened on the Malaysian Airlines incident a few months ago (that incident was a near-miss but did not result in a crash-- the problem was that the software was unable to handle properly bad data coming in from an accelerometer). Whether this counts as a "software bug" or a "hardware failure" I don't know....
You can prove that the software is bug free for any set of foreseen inputs. The question becomes whether there are unforeseen inputs which can cause problems. Suppose for example, that a sensor fails in an unexpected way-- for example shorting a circuit instead of breaking it, or by sending incorrect data to the computer. In essence you not only have to handle valid inputs from sensors, and normal sensor failures, but you also have to handle sensors which fail in unexpected ways, and you also have to handle every possible electrical fault as well. And then you *still* have to make some assumptions about the underlying communictions between the remaining components.
How, here is the real issue:
Software exists only to process information on underlying hardware. When you have failures in that hardware which cause the information to be corrupted, you cannot count on any results on the software. Hence you software can only be proven bug-free within a reasonably limited set of circumstances. Or, in simpler terms, garbage in? garbage out.
LedgerSMB: Open source Accounting/ERP
A nice idea, but commercial airliners have several characteristics that would make that unworkable. First off, in the landing configuration (flaps 30 and gear down), the descent angle would probably be close to 6 or 7 degrees rather than the normal 3 - leading to a descent rate of 2000 fpm or more. In a sailplane (with a very low moment of inertia around the lateral axis), when you command pitch up, the lag between your pulling back on the stick and the airplane rotating to a different angle of attack and increasing lift is almost zero - i.e. near instantaneous response in vertical speed to pitch commands. In a commerical jet, the moment of inertia is much greater, so it takes a few seconds for the plane to rotate to a different angle of attack and thus generate more lift. If you didn't time your flare perfectly, you would smash into the ground quite smartly.
Secondly, if you instead had the airliner attempt to land in a much 'cleaner' configuration with a better glide ratio, closer to 3 degrees, your landing speeds would probably be 50% faster, probably near 200 knots. The required landing distance is proportional to the square of the velocity, so you would need to double the size of existing runways. Not likely....
Third, jet engines have relatively slow response characteristics, particularly from idle (much better than a decade or two ago, but they are still slow compared to piston powered engines); this caused several crashes back in the late 50's and early 60's - pilots would be doing idle thrust approaches, then circumstances called for a go around, and when they advanced the thrust levers, it took a good 10 seconds (or more... DC-9s particularly sucked in that area, from what I remember) for full thrust to be developed... and they didn't have 10 seconds to wait. So, it was decided that jets should approach in a 'thrusted-up' configuration; one where the engines were developing much more than idle thrust throughout the final approach - if go around was required, the time to full power was much smaller. But, to maintain such a 'thrusted-up' configuration, the approach slope had to be shallow (a good idea as I mentioned above), and the airplane had to have a very draggy configuration. The amount of extra lift at a given speed from flaps 15 to 30 is very small, but the additional drag is quite large... that's the reason airplanes take off with very small flap settings (typically 5 degrees), for maximum additional lift with little additional drag, but put out full flaps, with lots of drag, for landing, so the engines stay spooled up until about touchdown.
The right and left engines are controlled by different computers. The only single points of control are the pilot and a central engine control system. Thus in the absence of pilot error, the only single point of failure is that specific avionics system.
Now the root fault may be due to some sensor or processing system failing and causing a cascade failure to other portions of the system. This sort of thing *has* happened in other 777's (an accelerometer failing in a way as to cause a cascade error into flight control software). In the end the most careful proof of software accurate operation must make certain assumptions about unerlying hardare states. Once hardware starts to go bad, all bets are off (for example, sensors could fail in such a way as to provide apparently valid but wildly inaccurate data to the software which would then return incorrect results (and hence take wrong actions).
LedgerSMB: Open source Accounting/ERP