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."

Errrrr..

[Deekin_Scalesinger (755062)]

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...

Airplane Operating Systems

[Alien54 (180860)]

"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 [theregister.co.uk] I couldn't resist

Re:Airplane Operating Systems

[jorghis (1000092)]

These OSes typically are not custom designed. (although a few in older aircraft are) There are a few commercial rtoses that are commonly used, they are specially marketed to the avionics industry as conforming the DO-178B standard. The most common would probably be Integrity-178B sold by Green Hills Software and VxWorks 653 Platform sold by Wind River.

Re:Airplane Operating Systems

[Alien54 (180860)]

unfortunately I can't mod up your reply to my comment.

But the idea of Windows for Airplanes is something that would strike fear into many a person's heart. Would you trust your aircraft to Windows for Airplanes?

Or your helicopter to Windows for Helicopters?

Re:Airplane Operating Systems

[Alien54 (180860)]

2nd thought:

The Knowledge Base reports on Flight Simulator are scary enough [microsoft.com] as it is.....

the rest of the scenario writes itself

Re:Airplane Operating Systems

[jorghis (1000092)]

It is substantially different. (and integrity is different from integrity-178b also)

The 653 in the name is a reference ARINC-653, which is an industry standard that specifies the api that the OS exposes to the user. (Integrity also supports this same api)

I havent used VxWorks 653, but I am very familiar with both Integrity and Intregrity-178b, and there is no question that the latter is a LOT more reliable.

There may be a little bit of code reused in these platforms, but really the name is the same for marketing reasons. (kind of like how windows CE is completely different from the windows you run on your desktop)

Re:Errrrr..

[einhverfr (238914)]

Not so sure.

I read a number of articles on it and:

1) Avionics resulted in a near miss relating to a 777 a few months ago operated by Malaysian Airlines. The problem was a combination of a software bug and a dead sensor (i.e. the software didn't properly handle sensor errors and a sensor went dead).
2) Despite this problem, the 777 still has an impressive safety record. Only one crash in the history of operating that aircraft and that didn't result in fatalities?

In a plain like the 777 basically, you have three possibilities: human error, electronics failure, or mechanical failures. I think this case seems unlikely to be the result of other human or mechanical failures, so we are left with electronics issues and the primary suspect.

I am guessing that the real lesson here is that nothing is infallible, but that the 777 is pretty-darn good.

My suspicion is that we will eventually find that the 777 needs regular maintenance to portions of it which have not received as much attention in the past. It could be a similar issue to the MA failure-- a dead sensor sending information the software was not prepared to handle, it could be an electrical short circuit (for example, caused by water corrosian or even condensation) as we saw recently with the ISS. The point is that only now, thirteen years after the planes entered operation, we are running into these problems. I don't think that software alone could have caused the problem. More likely it is a combination ofhardware failure triggering bugs in software.

Re:Errrrr..

[SL Baur (19540)]

I am guessing that the real lesson here is that nothing is infallible, but that the 777 is pretty-darn good.

That's what I read out of it too. The track record remains and speaks for itself - those are damn good planes.

They experienced a catastrophic failure losing both engines at low altitude where the plane has all the flight worthiness of a brick and nobody died.

More complicated than that

[einhverfr (238914)]

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.

Good case to examine

[jhines (82154)]

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.

Re:Errrrr..

[Richard_at_work (517087)]

The current official initial report says the following -

1. The autothrottle system commanded an increase in thrust from the engines which did not respond
2. The autothrottle demanded further increases in thrust again with no results
3. The PIC commanded an increase in thrust via movement of the throttles, with no result
4. The aircraft slowed and subsequently lost height

http://www.aaib.dft.gov.uk/latest_news/accident__heathrow_17_january_2008___initial_report.cfm [dft.gov.uk]

For both engines to have not responded to either the autothrottle or manual throttle movements, we are looking at a software issue in either the FADEC or the EMC.

BA are extremely happy about the crash

[Malevolent Tester (1201209)]

They actually have a decent excuse for lost luggage for once.

No, not the Avionics...

[bradgoodman (964302)]

No - I don't think so. The autothrusters responded properly, but they literally just move the throttle levers, to which the engines didn't respond.

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...

Re:No, not the Avionics...

[s20451 (410424)]

In two other instances in large jets of engine failure by fuel starvation (Air Transat 236 and Air Canada 143), the failure of the engines was not simultaneous: one engine kept working for a few minutes longer than the other.

The fact that the engines responded the same way, at the same time, strongly suggests a single point of failure in an electronic flight control system.

Re:No, not the Avionics...

[chuckymonkey (1059244)]

These things *shouldn't* happen - but the investigation will tell...


Exactly why speculation as to the cause gets us nowhere. Pointing fingers and throwing blame about serves nothing, just like the guy above saying something about Iranians. We really should have something similar to a Godwin for Terrorist/Bush/Iranian bullshit that people post.

Re:No, not the Avionics...

[DaveAtFraud (460127)]

No - I don't think so. The autothrusters responded properly, but they literally just move the throttle levers, to which the engines didn't respond.

Just because the indicators in the cockpit show that the autothrusters were to provide more power doesn't mean the signal gets to the engines. There is a lot of wiring and other systems between the cockpit and the engine. On a "fly-by-wire" plane like the 777, even moving the throttle levers just sends a signal to a system that eventually gets to the engines. Bottom line is there are lots of lower level avionics systems that could have failed and the pilots would only see that the autothruster was supposed to provide more power and didn't.

The question is, which on the various boxes along the way had a BSOD?

Cheers,
Dave

Re:No, not the Avionics...

[hughk (248126)]

I think we will find that there was a coding error that caused the engines not to respond to controls with this one.

Flight systems (hydraulics, power and controls) are triplicated to give the appropriate security for fly-by-wire. Airbus Industrie on the 320 used two different processor architectures and three separate teams working on flight software to ensure that the same problem would not occur on two out of three computers. Does anyone know if Boeing used the same practice for their flight systems?

Re:No, not the Avionics...

[Mike1024 (184871)]

Airbus Industrie on the 320 used two different processor architectures and three separate teams working on flight software to ensure that the same problem would not occur on two out of three computers. Does anyone know if Boeing used the same practice for their flight systems?

They probably do. This is the time to whip out An experimental evaluation of the assumption of independence in multiversion programming [google.co.uk] by Knight and Leveson. It's a 47-page paper, but here's the summary:

N-version programming has been proposed as a method of incorporating fault tolerance into software. Multiple versions of a program (i.e. ''N'') are prepared and executed in parallel. Their outputs are collected and examined by a voter, and, if theyare not identical, it is assumed that the majority is correct. This method depends for its reliability improvement on the assumption that programs that have been developed independently will fail independently. In this paper an experiment is described in which the fundamental axiom is tested. A total of twenty seven versions of a program were prepared independently from the same specification at two universities and then subjected to one million tests. The results of the tests revealed that the programs were individually extremely reliable but that the number of tests in which more than one program failed was substantially more than expected. The results of these tests are presented along with an analysis of some of the faults that were found in the programs. Background information on the programmers used is also summarized. The conclusion from this experiment is that N-version programming must be used with care and that analysis of its reliability must include the effect of dependent errors.

Of course, one would think there would be two types of redundancy: The software would be N-version programmed and there would be separate systems for each engine. The chances of two independent N-version-programmed programs failing at the same instant seems particularly low.

It's easy to jump to the it-must-be-the-computers conclusion because PCs are unreliable in everyday use compared to washing machines, cars or compact disk players. But until the accident investigators' report comes out there really isn't much evidence to base speculations upon; the problem could have been anything.

Just my $0.02

Made by Diebold?

[Hognoxious (631665)]

Their outputs are collected and examined by a voter

That's OK then, we all know that computers couldn't possibly have any problems counting votes.

Re:No, not the Avionics...

[timthorn (690924)]

No, this happened at the worst possible point. Over the middle of the ocean the aircraft will have been at perhaps 38000 feet and in a flight configuration, giving time to attempt various restart procedures, declare an emergency and glide to an airfield - a transatlantic flight is rarely out of gliding distance to a landing strip, and a flight from China likewise.

Re:No, not the Avionics...

[Hognoxious (631665)]

a transatlantic flight is rarely out of gliding distance to a landing strip

Assuming it's flying at 40 thousand feet and can do 30 feet forward for every foot of drop (probably a high estimate; top sailplanes get more but they're designed for it) that means it can never be more than about a million feet from a fairly long and smooth runway. Sounds a lot but that's barely 200 miles.

Ah, no, they don't glide THAT well

[VAG-Man (1223780)]

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 [wadenelson.com]) 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.

Damnit!

[DoofusOfDeath (636671)]

Now we're all going to be forced to re-learn Ada!

Re:Damnit!

[Sponge Bath (413667)]

I read it was actually MIX machine code converted directly to Java byte code by a drunken leprechaun.
Wikipedia is an awesome source.

Possible autothrottle problem

[bananaendian (928499)]

With the investigation ongoing, the available information points to an electronic control problem as the most likely cause of the sudden engine power loss."

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...

Re:Possible autothrottle problem

[BlueStrat (756137)]

Not a commercial aircraft airframe and powerplant mechanic, but I was a senior avionics technician for many years dealing with corporate and private jets.

What I've read is that the pilots observed a relatively gradual loss of power symmetrically on both engines.

Interesting. Do you have a link to the source for that? Not that I doubt you, just curious to parse it myself.

This tells me that I can rule out engine problems with FADEC and fuel.

FADEC, possibly, but fuel? It's quite possible there was either water or crud in the fuel, especially since the aircraft almost certainly took on fuel in China, and China seems to have had problems of late with products being adulterated in some form. The crud could cause blockages in the filters from the tank(s). The water would cause an increasingly-diluted fuel mixture to enter the engines as the level dropped which might also cause the gradual loss of power.

The two most-likely culprits I would examine first are the discrete devices at either end of the control path that send the data and receive it at the other end, and the cables and connectors used to transmit the data.

The next point I'd check would be the power supply that powers the electrical actuators that physically move the actual throttles in each engine. This supply would be separate from the power used for the electronics, as it would be a relatively high-current source. This might also be caused by cabling/connector problems.

Aircraft tend to have many problems with cabling due to high vibration and multiple pinch-points and stress and vibration/abrasion at support points, as well as contact problems at connectors.

Another very major problem is human error. In many cases the turn-to-lock type connectors are in very tight spaces, sometimes so much so that it may only be visible by a small mirror and flashlight held by the tech while he may be laying on his back or nearly standing on his head. I had a whole set of strange-looking pliers of different lengths and weird angles with curved padded jaws for just this purpose in my tool box, along with small hand-held extend-able flexible-tubing-mounted inspection mirrors and flashlights with the head on flexible tubing as well.

It can be very hard to tell, given the above circumstances, if the locking sleeve on these aircraft instrumentation connectors had been twisted far enough to complete the lock. It doesn't take much imagination to see what could happen given time, vibration, and G-forces.

Of course, these are just my rough guesses, and I don't have enough information to really make any informed statements.

Cheers!

Strat

Patience

[Linker3000 (626634)]

Let's just wait for the official forensics rather than patched together rumours shall we?

Typical

[pyrrhonist (701154)]

Once such a procedure was set, the plane would continue under automatic control until it reached an altitude of 250ft. Then a female computer voice would say, "Decide."

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.

Pointless speculation by we who know nothing

[caseih (160668)]

A comment on airliners.net's forums is very appropriate for us slashdotters I think:

A BA 772 landed short of the runway. Initially, speculation was entirely wild, ranging from random double engine failure to fuel contamination to one engine being actually working. Some witnesses said the plane came in high and fast, others said low and slow, others mixed the two together; all agree it was nose-high. A few helpful posters who actually knew something contributed. Some posters asked why the tires were brown...after the plane had skidded through a wet, grassy area on collapsed landing gear. A few posters got into pedantic discussions on various features of the 772 or its operational history as compared to the 340. Others took great pains to demonstrate to the world their lack of basic knowledge of unpowered flight. Few seemed familiar with the notion that fan blades windmill even when no power is applied to the engine. Most all were engaged in a game of nerdy one-upmanship in which they vigorously tried to validate their lofty views of themselves based on their aeronautical knowledge. In sum, we know about as much now as we did when the plane went down: the plane turned onto final, engines did not respond to power inputs, plane landed short of runway, slides deployed, people all survived, plane almost certainly a W/O. Shockingly, neither BA nor Boeing has decided to keep the 15-year-old speculation artists abreast of the situation.

Re:Pointless speculation by we who know nothing

[caseih (160668)]

Obviously you didn't check the website either or you'd know that the site doesn't indicate whether the plane was a 772 or 773, only that it was a 777, of which there are several different types. Other places on the net, including the news sites, say it was a 777-236ER, which is definitely a 772.

In case people are confused by people talking about a BA772 or a 773, these are standard designations. a Boeing 777-200 is referred to as a 772, the 777-300 is a 773, etc. Other common ones you'll find are things like 742 and 744 which designate 747-200s and 747-400s, respectively. Airbus planes also have similar designations.

Re:That Is Brilliant!

[caseih (160668)]

That Is Brilliant
Please post this at every /. article on aviation.

In this case, then, the quote needs to be properly attributed and sourced, which I neglected to do. Apologies. The quote comes from this thread, [airliners.net] post #6 by a user named IADCA [airliners.net].

Some facts about the 777 Electronic Engine Control

[flywithjoe.com (1223752)]

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.

Re:terrists?

[Hrdina (781504)]

Actually, it's more like "nucular", "gubmint", and "librul".

Re:terrists?

[R2.0 (532027)]

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?

Re:terrists?

[badasscat (563442)]

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.

Re:Software?

[Technician (215283)]

If it is a software problem, then expect more public scrutiny of software based machinery.

That is not likely. More likely is they had a glitch from a strong RF field someplace. Knowing the timing, it is likely to be either a radar or other high power beam or a very near lower powered source such as a cell phone inside the farady cage. Very likely the radio source is from something like this; **RING** **RING** "Hi hon, we are landing now.. Oh no, somethings wrong.."

Re:Software?

[ObsessiveMathsFreak (773371)]

That is not likely.

Yes it is likely. We are expected to believe that a single consumer grade device caused the simultaneous failure of both engines? Or from high powered sources which the planes must be built and certified to withstand. Give me a break. A Computer/Hardware glitch is a far more plausible cause.

That said, my paranoia meter says this could have been caused by some nut near the airfield with a HERF Gun [slashdot.org].

Re:Software?

[badasscat (563442)]

Yes it is likely. We are expected to believe that a single consumer grade device caused the simultaneous failure of both engines?

You're right that it's more likely than RF interference. But neither is likely at all.

A software glitch of this type (if that's what it was) has never happened in aviation history. Certainly not in the 10 year history of the 777, with more than 500 of them flying around the world, but not to any other type either.

Also, the engines didn't "fail". The engines were running both before and after the stall (and yes, the aircraft did stall, despite what the article summary says). "Failure" and "failure to respond" are two different things.

In some ways that's even more scary, because it rules out simple explanations like fuel exhaustion. It's one thing for engines to fail, quite another for them to simply ignore control inputs.

Re:Software?

[TooMuchToDo (882796)]

In some ways that's even more scary, because it rules out simple explanations like fuel exhaustion. It's one thing for engines to fail, quite another for them to simply ignore control inputs.

Indeed. If I'm piloting a turbine engine aircraft, I much prefer for the engines to just fail then for them to ignore my commands. Fly-by-wire is pretty cool until the engines ignore your commands and you have no way to shut the fuel off to them.

Re:Software?

[TClevenger (252206)]

A software glitch of this type (if that's what it was) has never happened in aviation history. Certainly not in the 10 year history of the 777, with more than 500 of them flying around the world, but not to any other type either.

It's certainly not without precedent. No case of air/fuel mixture explosion was found in 747's until TWA 800 [wikipedia.org] in 1996, and 1,396 of those were built since the 747 started flying commercially in 1970.

Re:Software?

[einhverfr (238914)]

I think a single software glitch is unlikely to be the cause of the failure. However, best guess at the moment is that the engine issues were software initiated.

You can only mathematically prove that software is bug free given some basic assumptions about hardware performance. If those assumptions fail, then your bug-free software is now buggy because the hardware is buggy and it can't sort out valid from invalid information.

TFA mentions another avionics glitch where a failed accelerometer caused a near accident on a 777 in Australia. The software inappropriately responded to the failure because the failure condition wasn't foreseen.

Most likely the root cause is hardware-related, not software-related. For example, maybe water-based corrosion on some contacts somewhere where the seal was damaged, or a short circuit on some sensor somewhere else. The issue is that this may have triggered failure conditions that were not previously foreseen in the software design.

The 777 has an impressive safety record. However incidents where, say, water gets into circuitry and causes problems, or some previously unforeseen failure situation arises, there will be problems.

As for the "first of its kind" remark-- this is not the first software initiated problem in the 777 if indeed that is the case. It *is* however, the first 777 crash ever. Which ought to make one a little less inclined to question previously unforeseen problems.

Re:Software?

[tftp (111690)]

I guess a very powerful, always-on jammer could have reached an aircraft at 600 ft. However, airplanes are designed to be illuminated with radar beams, obviously. The metal frame of the airplane shields the inside space (and the inside space is also shielded from the outside.) So the possibility of an external signal getting to an internal equipment (other than via the proper path through an antenna) is fairly low, IMO.

Another data point to consider is that the failure was not transient. Normally if you introduce some noise into the channel then you lose some symbols here and there, or the clock even. But the higher level protocols take care of that. Pull the network cable, for example - your SSH session will stay alive for half a minute, until TCP timers run out. I am sure that in an airplane loss of a message will be first noticed and logged, then reported as a potential trouble, and if it continues then some other emergency action will be taken. But if the error ceases to be then the message gets through and you can continue using the controlled device.

Since the malfunction occurred quite far from the airport, and it did not fix itself after the aircraft moved away from a possible jammer location, then in my uneducated opinion the relevant controls just "wedged" somewhere, asking for a hard reset. It will take some Boeing engineers with the diagrams to find out where two independent engine control paths merge or at least get close to each other. And they still have the physical electronics of the airplane, most of it probably undamaged. On top of that they have every single bit from every single flight data recorder, and those are of improved type that record more parameters than usual.

In addition, if the two engines are identical (as they should be) and have the same firmware loaded into their controllers, then the same command sent to both engines could easily take them out at the same time. It could be a fairly complicated sequence, for example, but as long as both engines are operated by another computer (autopilot / autothrottle) then you can be fairly sure that the two engines would be as much in sync with each other as possible, and the "ping of death", so to say, would affect both.

Re:Software?

[by Anonymous Coward]

If a cell phone can do this much damage, why the hell am I allowed to bring one (several even) on a plane?! These days, a swiss army knife will maybe get you as far as row 6 before people dogpile you, and they are confiscated. But a plane has easily 50 cell phones on it at any given time. If the only thing between me and engine failure are passengers dutifully following crew member instructions, then we are all screwed. So I am going to respectfully suggest that you are mistaken, because the alternative seems ludicrous.

Re:Software?

[AlecC (512609)]

Actually, they have given up creating multiple implementations of the code. There were only ever two implementations, scattered across several computers. However, when developing the systems for this very aircraft type, Boeing decided that they now have tools which can verify precisely that the software matches the specification, and where they actually need to put the effort in is in checking that the specification makes sense. Rather than wasting effort in having two teams implement implement the specification, and verify that using automated tools, you use the extra effort to look closely at the specification.

Re:Software?

[AlecC (512609)]

No - it shows that the specification did not define what should happen with out of range conditions. The use formal specification languages to define what they want the software to do, but it is precisely these sorts of unforeseen circumstances which show that the spec was wrong, and the code only did what was specified.

Re:Are the pilots heros?

[bradgoodman (964302)]

The word "hero" is thrown around a lot these days...

I believe what they meant, was that the pilots realized that things were going wrong, and the "normal" reaction would be to add thrust. When they realized that they couldn't add thrust, that this would result in loosing airspeed, entering a stall, and crashing

So they realized that an alternative was to lower their angle-of-attack, preventing the stall, and maintaining a bit of airspeed. This would have the unfortunate side affect of landing well-short of the runway (and perhaps airport) and destroying the aircraft - but given the information available - was a bad - but the best alternative

So they implicitly decided the best course of action was to glide the airplane and ditch it in a field - not a decision that would have exactly won them any praise had they read the situation wrong - but it saved everyone

Re:Are the pilots heros?

[Deadstick (535032)]

"Good airmanship" would be more apropos. They recognized the problem, in time to take over from the autopilot, and had the skill to pull off a deadstick landing with a survivable impact.

In principle, the airplane could have been landed on the runway without damage, if the right variables had come together -- but low and slow, in a big heavy airplane, with full flaps and no power, you're pretty well boxed in. I don't think they could have done better.

rj

Re:Are the pilots heros?

[arth1 (260657)]

"Good airmanship" would be more apropos.

Yes, but it doesn't make for as a striking newspaper headline as Coward the Hero!.

Re:Are the pilots heros?

[u38cg (607297)]

To my mind, if you manage to get 300 tonnes of falling metal out of the sky and on the deck with nothing worse than a broken leg, you've done something right.

Re:Summary Correction

[mpe (36238)]

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.