Another 777 uncommanded engine rollback

[ChristiaanJ]

NTSB e-mail, December 18, 2008
NTSB INVESTIGATING LOSS OF ENGINE POWER ON DELTA AIR LINES BOEING 777

The National Transportation Safety Board is investigating an
incident in which a Delta Air Lines Boeing 777 experienced
an uncommanded engine rollback in the cruise phase of an
intercontinental flight.

On November 26, 2008, at about 12:30 pm MST, in the vicinity
of Great Falls, Montana, a 777-200ER (N862DA), operated by
Delta Air Lines as Flight 18, en route from Shanghai to
Atlanta, experienced an uncommanded rollback of the right
(number 2) Rolls-Royce Trent 895 engine while at 39,000 feet
in the cruise phase of flight. The crew executed applicable
flight manual procedures and descended to 31,000 feet. The
engine recovered and responded normally thereafter. The
flight continued to Atlanta where it landed without further
incident. None of the crew of 15 or 232 passengers was
injured.

Flight data recorders and other applicable data and
components were retrieved from the airplane for testing and
evaluation. Both of the pilots have been interviewed.

This event is preceded by another airline's 777 equipped
with Rolls-Royce Trent 895 engines, which experienced an
uncommanded dual engine rollback while on final approach to
London's Heathrow International Airport on January 17, 2008,
crashing short of the runway on airport property. The
United Kingdom's Air Accidents Investigation Branch (AAIB)
is investigating that accident.

NTSB Senior Air Safety Investigator Bill English, who is
serving as the U.S. Accredited Representative in the
Heathrow accident investigation, is the Investigator in
Charge of the Delta incident.

The AAIB, which has assigned an Accredited Representative to
the Delta incident, is working closely with the NTSB to
determine if there are issues common to both events.

[ChristiaanJ]

Tah, GobonaStick.
I only got the NTSB e-mail minutes ago.

CJ

[hetfield]

Investigator Bill English, who is
serving as the U.S. Accredited Representative in the
Heathrow accident investigation,

Well, it seems the right person in the right place.
;)

[Mr @ Spotty M]

Boeing sent out an e-mail on this days ago.

[ChristiaanJ]

Boeing sent out an e-mail on this days ago.Any link to the contents?

[paull]

This was on the original thread for the LHR incident a few days ago, I was amazed there was no response from Ppruners.

[captplaystation]

Indeed, a slightly disturbing incident for sure. I wonder if a common cause or just some random electrical spike. Perhaps all the research into ice etc will prove to have been for nought and the cause for both found (or not ) to have been some transitory electrical woopsie that nobody forecast and the BITE stuff doesn't recognise.
Damned funny stuff electricity, black magic. :rolleyes:

[lomapaseo]

I was amazed there was no response from Ppruners.

Not much to be said until they look at the data and decide if the fuel control was commanding it or following it.

There are more common reasons for rollback not related to ice in the fuel.

The BA038 thread evidenced unique response of the fuel control not associated with more common causes of rollback.

I'm not saying that the fuel control is causal, only that's a indicator of where to look.

[bvcu]

Similar issue a year ago with ER and GE engine resulting in a long period of non derated take offs until software modified , although this problem was only on T/O .

[stilton]

If i'm not mistaken Delta have Rolls on their -ER'S, same as the BA in LHR :eek:

[bermudatriangle]

sems to dispell the ice in fuel explanation of the beijing incident.becoming a bit concerning if software and electrical systems are less than 100% reliable.considering the number of triples in service,i suppose no need to cause too much concern.

[Loose rivets]

So how long was the remaining section of the flight?

[safetypee]

Don’t discount the weather as a cause:- The Ice Crystal Weather Threat to Engines. (www.sae.org/events/icing/presentations/2007sopenmason.pdf)

[Capn Bloggs]

becoming a bit concerning if software and electrical systems are less than 100% reliable.
Like QF 72: One component of one ADIRU (of three identical on board) goes haywire and the aircraft goes bananas.

[banana9999]

"becoming a bit concerning if software and electrical systems are less than 100% reliable."

I doubt any are, but they can still be more reliable then a large number of mechanical moving rods.

[twochai]

a bit concerning if software and electrical systems are less than 100% reliable

Which planet are you living on?? Anything made or touched by poor, humble man (or woman) is subject to screw up and/or failure. If anybody in aviation believes anything different, they're in the wrong field of endeavour.

[AnthonyGA]

The problem is that software isn't verified as thoroughly as hardware.

Verification and certification processes were designed for mechanical systems, not ones and zeroes. Digital systems, including anything controlled by software, have failure modes that are dramatically different from those of mechanical systems, and catastrophic failures for unforeseen circumstances are the rule rather than the exception. Systems that mix software and hardware are still tested and verified as if everything were hardware, and that lets lots of potential bugs slip through the cracks.

Combine this with the extremely poor record of reliability for software engineering as a whole, and software becomes a considerable cause of concern.

I know that aviation tries harder to verify software than most other industries do, but manifestly it isn't trying hard enough, if events like this are happening. Which type of mechanical failure would roll an engine back in cruise? Weird, random, off-the-wall incidents like that have all the hallmarks of software bugs.

My specialty is information technology; aviation is my hobby. Decades of experience with IT have taught me that the more software there is in a safety-of-life system, the less it should be trusted. In an ideal world, software would be completely safe, but we are still in the Dark Ages when it comes to designing reliable software. To paraphrase a famous saying, whenever I hear "computer," I arm the pyrotechnics on my ejection seat.

[ChristiaanJ]

AnthonyGA,
Yes, no and maybe.

In the analog days, we had TWO physically separate and distinct channels, one monitoring the other. If they disagreed, they disconnected. The probability of the same op-amp or same resistor failing identically at the same time was infinitesimal.

When 'digital' came along, I had qualms as well, but dissimilar processors and dissimilar software between 'command' and 'monitor' mostly were supposed to have solved their 'identical failure' problems.

Some of those concepts now seem to have gone out of the window, judging from some recent posts elsewhere.

So far, we have no idea whether this incident is again ice or something similarly mechanical, or indeed "IT" related, so let's give it a break until we have more data?

Cabin crew spilled some Coke on the pedestal during the last flight and it now soaked through? Weirder things have happened.

I sincerely hope the QAR/FDR data will tell a useful story.

CJ

[jetsetjobbie]

Cabin crew spilled some Coke on the pedestal during the last flight and it now soaked through? Weirder things have happened.


..........such as pilots spilling coke and blaming the cabin staff in the ASR...

[JW411]

Everywhere I have ever been in aviation, everyone who was allowed on the flight deck was taught to pass drinks to pilots around the outside and never, ever on the inside over the central pedestal.

Fluids and automatics do not mix and exciting and expensve things happen when they come together.

[The Sultan]

BS on the coke. Just a "Fate is the Hunter" troll.

The Sultan

[Gen. Jack D Ripper]

Regardless of similar airframe/engine combination, the fact that leaps out at me is that both these flights originated ay Shanghai.
:ok:

[captplaystation]

AnthonyGA, as a sceptical luddite whose knowledge of computers is limited to coming on here and giving my opinion, it is interesting to hear that someone who does understand a lot more, has the same misgivings as myself, but backed up by a knowledge of what is involved.
As I have said many times, if I see the tricks Windows Vista can pull ( and I am sure Microsoft have more money/resources invested than Boeing & Airbus combined) it doesn't fill me full of joy to imagine what lies within the systems of these aircraft for the future amusement of the crews.
Since I first expressed this view we have had BA, the Qantas 330 upset & the XL accident in PGF and now this. I may be an old fart, but my misgivings are not without grounds.

[Simonta]

and I am sure Microsoft have more money/resources invested than Boeing & Airbus combined

There is no comparison between the type of engineering Microsoft does (general purpose computers, consumer and business, huge number of operating modes, unimaginable combinations of hardware and software) and Boeing/Airbus does (single purpose, limited operating modes, known hardware/software).

AnthonyGA, sorry, you lead me to believe you might be in IT but know little about designing, engineering and testing embedded aviation software.


Verification and certification processes were designed for mechanical systems, not ones and zeroes.


Verification and certification of aviation software bears resemblance to mechanical systems processes in what way? Both Boeing and Airbus (and the vendors who supply software and hardware to them) operate with verification systems designed from the ground up,specifically for these applications.


Systems that mix software and hardware are still tested and verified as if everything were hardware, and that lets lots of potential bugs slip through the cracks


Please explain? Do you mean hardware without software - i.e. useless or are you saying mechanical systems, or avionics without software? Either way, please explain what you mean. I can see no parallels between testing airborne software and mechnicals.

No more likely to have an unknown bug in software than a design fault in mechnical systems - do a little research into how these systems are designed and engineered.

Would I rather travel in a mechnical aircraft or FBW? Actually, never crosses my mind. Both are demonstrably far safer than any other form of travel I use by far. And of course, safety just keeps getting better - including FBWs and other computer controlled a/c.

Finally, I'd be interested to hear how 3 different programs, written by entirely separate teams (with no knowledge of each other) running on different hardware can have the same bug? Design error yes (see above re mechnical systems) but bug? Any idea of the chance that 2 entirely separate systems can both get it wrong, at exactly the same time whilst the 3rd, entirely separate system gets it right?

Move along there, nothing to see...

[Ex Cargo Clown]

Regardless of similar airframe/engine combination, the fact that leaps out at me is that both these flights originated ay Shanghai.

Very good point.

But shhhhh, don't upset the Chinese...... I wonder why the BA investigation has gone so quiet....

[HotDog]

That's stretching a bit Cargo Clown. I don't know how many 777s are amongst the hundreds of daily departures from Shanghai but if the engine rollbacks had anything to do with Shanghai fuel, there would have been more than two incidents of this nature.

[Union Jack]

Regardless of similar airframe/engine combination, the fact that leaps out at me is that both these flights originated ay Shanghai.

Sorry to rain on your parade, General Jack, but BA038 actually originated from what we must now call Beijing.:)

Jack

[Smilin_Ed]

Many posters continue to try to implicate software but they completely ignore the fact that, in BA 038, in response to auto-throttle and power lever movement, both fuel metering valves opened fully, yet the engines did not respond. Does that not mean that there was no little or no fuel there to flow toward the nozzles? How then can software be implicated? :ugh: Faulty software can cause a lot of problems, but the evidence does not point to software in the case of BA038. In fact, hard evidence seems to completely exonerate software.

[Gen. Jack D Ripper]

Union Jack

You overstate the relevance of your correction ("...rain on your parade.." oh! purrlease!!!)

The fact is they were BOTH B777's, BOTH had RR Trent engines, BOTH originated in CHINA & BOTH had long cruises at high cruising levels in extremely cold temperatures.

I'm NOT saying that incorrect ratios of fuel additives was the cause, however, I don't think it was explored as thoroughly as it could have been during the investigation, certainly when compared to the scrutiny the airframe/engine hardware/software had to endure.
:ok:

[AnthonyGA]

Unfortunately, aviation software engineering isn't as different from other types of software engineering as many people in aviation would like to believe. The list of problems with aviation software is extremely long, although it is not widely publicized.

Most software fails because of design defects rather than bugs, although bugs are certainly important sources of problems. Aviation software is just as prone to design defects as any other type of software. Checking code against a spec will not prevent design defects. Having three versions of the code written by three different teams also will not prevent design defects. Even verifying bit patterns in firmware will not prevent design defects.

Design defects exist in mechanical systems, too. The problem is that defects in software manifest in a completely different way from defects in mechanical systems. Software systems usually have catastrophic modes of failure because of the disconnect that exists between bits and bytes and actual physical systems. Mechanical systems typically do not fail in catastrophic ways because of physical limitations that prevent failures from moving outside a certain envelope. Physical laws limit the magnitude and nature of mechanical failures. No such laws protect software.

A classic, simple example: Suppose you have a throttle lever that can mechanically travel between two stops, corresponding to idle and full power. A large number of different physical limitations prevent isolated failures from having dramatic effects. For instance, if the lower stop on the throttle fails, the worst that can happen is that the throttle will descend past idle—but since the engine is already at idle, that doesn't change much of anything. And if the upper stop fails, the throttle can move a bit past full power, but many other factors limit the effects of that: the throttle travel is only so far, the engines cannot run at two or three times full power no matter what the throttle setting, and so on. There's a lot of inevitable physical interaction that limits the effects of failures and design flaws. This interaction doesn't have to be built in by the designers, it's just a consequence of the laws of physics.

Now consider a "FBW" throttle. The throttle provides inputs to a computer, which then decides what setting to use for the actual engine throttle. The engine throttle settings are represented by a three-digit number, from 000 (idle) to 999 (full power). The throttle lever in the cockpit merely commands changes in throttle setting: pushing the throttle tells the computer to increase the throttle control number, and pulling the throttle back tells the computer to decrease the throttle control number.

Now you have a situation where the FBW can cause a catastrophic failure that would be impossible with the mechanical throttle. If the pilot advances the throttle repeatedly or very aggressively, the computer will continue to add to the throttle control number: 500, 501, 506, 600, and so on. What happens when the number reaches 999? Well, that's the problem. If the designers of the software haven't foreseen this in advance, adding one to 999 will produce 000. Which means that if the captain advances the throttle too far, the engines will be abruptly set to idle. That is catastrophic behavior that can cause a crash. And it WILL happen, UNLESS the designers foresee the possibility and program the software to not add anything to a throttle control number that is already at 999. The same problem exists if the pilots retard the throttles too far: they could go from 000 to 999.

In a mechanical system, there's no way for a throttle to snap back to idle if you push it past full power. In a FBW system, it's easy, and in fact it's guaranteed to happen unless the people who build the system specifically protect against the possibility.

That's why software is dangerous. Designers often overlook things, and the things they overlook can kill you a lot more easily than any mechanical failure could, because there are no laws of physics to limit the magnitude of a malfunction.

And while aviation is certainly more careful about software than many other fields, it's not nearly careful enough. I've been following the use of software in aviation for years, and it's grim. Way too much software is put in place with way too little thought, and periodically that causes problems, sometimes deadly problems.

The weird thing is that people tend to trust computers more than mechanical systems, when it should be the other way around. Yes, in theory, computers can do a better job, but as long as they have to depend on flawed software designed and written by human beings, they may actually be more dangerous than the mechanical systems they replace. It's interesting to see the blinders that people put on when they are looking at computer controlled systems.

They say that the rules of aviation are written in blood, but apparently that is only true if the blood is shed by mechanical systems. If software is at fault, people try to hide the problem, downplay the problem, and even resort to falsifying data to conceal the problem—they seem very unwilling to simply acknowledge and fix the problem, and equally unwilling to take responsibility for their design flaws and bugs. That kind of attitude might be more understandable when the only possible consequence is a day of bookkeeping lost, but I'm surprised to see it still in full force even when people die.

[maxrpm]

Anthony GA:
The weird thing is that people tend to trust computers more than mechanical systems, when it should be the other way around. Yes, in theory, computers can do a better job, but as long as they have to depend on flawed software designed and written by human beings, they may actually be more dangerous than the mechanical systems they replace.


Ever experienced a frozen Handle due to a struck elevator cable? Might make you feel different about mechanical systems being less flawed.

[scrivenger]

AnthonyGA

A very interesting and thought provoking post, I would be most intrigued to hear a counter argument, if anyone is so qualified, or indeed dares to give one.

[His dudeness]

From my experience I tend to say AnthonyGA has a point. The biggest airplane I ever flew yet is the Challenger 300, but that airplane has (had?) enough software generated problems and also problems that origin from the analog / digital interfaces. For example, we had erratic engine behaviour which was not reproducable, in the end we replaced the throttle quadrant (comes a s a complete unit) and thing worked as advertised again. The test and measurements where all within limits. I nowadays fly the Cessna C680 and on our airplane we sometimes don´t get the HP bleed from one side when anitIce is on. MX have checked everything and the condition is not reproduceable at will, it just happens sometimes. I found out that we could get it to work with changing fadec channels, however P&W and Cessna say its not a FADEC (aka software) problem. What is it then I ask? ADCs Rat probes etc have been checked....
And how do we deal with problems we can reset by cont/alt/del aka cycling the power? Hold item, MEL or just shrug shoulders? A wide field that needs a bit more attention IMO.

Regarding the certification of software, I´m not involved in that, but I ask myself how can they get stuff certified that acts sometimes really strangely, like the Honeywell Epic avionic suite installed in the C680...You are not allowed to use a lot of functions that originally have been okay to use and we get them back in little steps. The magical phase 5 software that is supposed to cure all the probs is delayed time and again, so methinks its a lot harder to find out and rule out software related problems than hardware.

Sorry for the OT.

[clearedtocross]

If some of the posters here would design computer controlled systems for aircraft, that would indeed be dangerous. Take a look at the example of the throttle encoding: angle encoders used for this kind of control are made in a way that precludes wrong readouts by design using an error tolerant coding technique (gray code or code with parity checking). They may not read out at all, or the link may be broken, but they most certainly do not go from 999 to 000. What rubbish. Nothing to do with software neither, by the way. There are other sensor techniques for command inputs like side sticks etc (like potentiometers or phase angel encoding), then they use redundant components or other fail safe designs.

We all agree that we would not trust an aircraft based on windows software, but you cannot compare an office system with an embedded and dedicated controller like FADEC or FMS or you name it, not be design and certainly not by price.

By the way, Captain Ernie Gann describes an uncommanded rollback on a flight from California to Hawaii in his book "fate is the hunter". It was no jet he was flying, it was a DC-4 running on 4 corncobs some 55 years before. Plenty of avgas on board. Now whatever the problem really was (Gann does not provide an answer, but resonance may have been a problem), a DC-4 was not known to be computer controlled. So such things did obviuosly happen without the help of software.

[scrivenger]

So what we seem to be facing is the fact that aircraft, for at least 55 years, have had uncommanded engine rollback, and nobody is any the wiser. Now thats progress....

Surely everything that ever happens to something mechanical, be it instigated by a person or a computer MUST be correctly and fully monitored, otherwise there seems to be a total lack of inherent concern for safety with regard to that monitoring.

[flown-it]

I believe "AnthonyGA" was trying to make a point with his 000-999 analogy. I have a feeling he is well aware that is not how a FADEC system works. I also think both he and "His dudeness" have a point. Why did the E-190s (or whatever e jet it was) that USAirways introduced have such a dreadfull introduction? Because of the Magic..not the airframe. Look at the complex avionics packages being introduced into the fleets these days. After a few years in service where are we? Airframe? Same as certified. Software? -6,7 or -e,f etc. Certainly several iterations of the original installation. I fly/ have flown some of the most advanced avionics and FBW aircraft and I have no desire to go back to round dials and I just hate big yokes. I just think we need to be aware of the potential problems inherent with our reliance on software. When cont/alt/delete means a totally black airplane watch out!!

[AnthonyGA]

I wasn't talking about the encoding of the throttle movements, which is mechanical, not software. I was giving an example of why software failures are so much more dangerous than mechanical failures. The fact that this was misunderstood helps to prove my point.

Apparently mechanical engineers have been humbled by centuries of mistakes and are at least moderately willing to accept that they might have made a mistake that could have put someone in danger. Not so for computer engineers, in my experience, and software engineers are the worst of the lot. Even when you walk them through the faulty code and show them their errors, they will continue to deny them. It's always someone else's fault.

It reminds me eerily of a certain airframe manufacturer and airline who immediately claimed that a chief test pilot was mentally disturbed after an accident, rather than admit that there was a software problem. Never mind that people died in the accident; that apparently was not important. (I've been unwilling to board their aircraft ever since, and from all reports their attitude has not changed.)

It worries me that more and more software is being put into service faster and faster with less and less verification in aviation. The things I hear about software-bloated avionics, for example, are identical to what I hear about desktop computer software, the only difference being that malfunctioning avionics kill people, whereas a malfunctioning spreadsheet usually does not. There should never, ever be a situation in which features included in an avionics package must be avoided after installation because of bugs. If the software were designed and tested properly, that would never happen—but obviously it is happening, which conclusively demonstrates that the software is indeed being put into real airplanes with life-threatening defects. And yet crews still are willing to fly on aircraft that depend on software that already contains proven defects. What makes them think that the defects discovered are the only defects lurking within? Typically, for every bug you find in software, there are dozens or hundreds of others that you haven't seen yet.

I don't understand the denial that I hear about this. Is it really preferable to die from the consequences of bad software than it is to admit that the software is bad? Or perhaps people insist that software is safe and adequately tested because it scares them to consider the very real likelihood that it isn't safe and isn't adequately tested.

Some of it is probably conditioning. Most people around today have grown up with computer systems that are incredibly unreliable, thanks to very hastily, poorly written software that has never been adequately designed or tested. They actually believe that this is normal, and that there's no other way for computers to work. They take this irrational belief into other domains where computers are increasingly used, including safety-of-life domains such as aviation. Problems that would lead them to riot and sue in a furious frenzy if they occurred in mechanical systems merely cause them to shrug their shoulders in software systems, as if software reliability depended on fate rather than hard science.

If it took NASA years and billions of dollars to produce very simple software running on very simple computers with a reasonable degree of reliability, do you really thing that software written in a month and modified every two months by underpaid Third World subcontractors working against deadlines, and tested based on obsolete and irrelevant certification criteria, is really going to be safer? Remember, whichever way you feel about it, you're betting your life on being correct.

[Union Jack]

You overstate the relevance of your correction ("...rain on your parade.." oh! purrlease!!!)

Nice try, General, we all completely understand that:

The fact is they were BOTH B777's, BOTH had RR Trent engines, BOTH originated in CHINA & BOTH had long cruises at high cruising levels in extremely cold temperatures.

which are all indeed very relevant, but the fact is that the point you actually tried to make was:

Regardless of similar airframe/engine combination (my italics), the fact that leaps out at me is that both these flights originated ay (sic) Shanghai

Some leap since even a presumed Spam should know that Shanghai is not exactly a suburb of Beijing!

Now, just let the real experts get on with it

Jack

PS Congratulations on your promotion ......

[IO540]

Finally, I'd be interested to hear how 3 different programs, written by entirely separate teams (with no knowledge of each other) running on different hardware can have the same bug? Design error yes (see above re mechnical systems) but bug? Any idea of the chance that 2 entirely separate systems can both get it wrong, at exactly the same time whilst the 3rd, entirely separate system gets it right?

I don't think you do software either!

In the real world, programmers come from the same "school" where they learnt the same algorithms, they read the same internet programmer forums, they pick up bits of the same open-source source code, lift the same algorithms off the internet, they make the same mistakes generally (stray pointers etc etc etc), so while having three different teams write some code to the same overall spec will protect against a lot of problems, it will fall far short of protecting against all.

And in many ways, the overall system spec will plant the seeds for the three teams making the same mistake in the same place.

I've been doing hardware/software for 30 years. One can get it damn good, and trivial bits of software can be made totally (and provably) reliable, but as soon as it departs from being trivial, the reliability is no longer assured, and can no longer be proven. One can still make it damn good if one is really careful, even to the extent where no customer ever finds a bug over say 10 years in a 24/7 industrial application, and I have achieved that with a number of products, even writing in assembler, but you still never really "know" what is around the corner - because most usage patterns are similar and test only a small part of the functionality.

The other thing is that the "box" which compares the outputs of the three systems will be the new single point of failure...

I have read the entire BA038 thread, and the intermediate AAIB reports, and yes I agree it doesn't look like a control system issue because the fuel control valves were found to be fully open. Plus the cavitation damage, etc.

But I wonder how reliable is the position encoder / data acquisition on the fuel control valve. Sensors can and do fail. OK, one would not get two failing on both engines at the same time, but there is an awful lot of software between those sensors and the recorded data on the valve positions. Many millions of instructions executed to collect and store that data.

[lomapaseo]

I don't understand why all i8rrelevant talk about computer knowledge when we still don't have clue to what precipitated the rollback.Most of the rollbacks that I have come across start with mechanical deterioration and it's the computer that is tweaked to accomodate the problem to fix some of the rollback issues

So have any new facts surfaced like commanded fuel metering vs a timeline:confused:

[11th Earl]

Hi all,

A question from a curious non-pilot; apologies in advance if i may be on the wrong formum! With regard to uncommanded thrust roll back on one engine in the cruise, presumably there is an immediate effect on the yaw/bank angle off the aircraft? Is this compensated for by anything automatically, for example rudder trim or is that not enough? Presumably the pilots would have to do something else to stabilise the situation?

Just curious about the aerodynamic effects during an event of this nature. Thanks in advance. As I said, if i'm in the wrong place, apologies and please redirect me if so.

Thanks, Ian

[no sponsor]

The aircraft would yaw in the direction of the non-working engine side due to asymmetric thrust, with possible autopilot disconnect. Rudder, and then trim would be required to hold the desired track, and the autothrottle would be disconnected by the pilot, with power applied to the good engine. I believe in a 777, the application of yaw is also automatic (but not in older aircraft, like a 737/757, where it is all manual). If the loss of thrust was for any length of time, and at high altitude, the aircraft would need to descend.

[Il Pilota]

Just to add another element to the hardware/software debate, all structural design and modelling of airframes, bridges, skyscrapers, etc, is now done in software, so there is no getting away from software, no matter which side of the arguement you are coming from. Quite clearly, there is a big difference between realtime software controlling safety critical systems and software used in CAD, etc, but the principles are the same, the outcome is dependent upon the integrity of the design and development process.

[DozyWannabe]

AnthonyGA:
Combine this with the extremely poor record of reliability for software engineering as a whole, and software becomes a considerable cause of concern.

I'll refer you to some older posts I made on earlier incidents, because I don't want to go round the houses with it again, but the gist of it is that the software engineering discipline for real-time safety-critical systems cannot be compared to any other type of software engineering in terms of reliability and testing.

http://www.pprune.org/rumours-news/340666-ba038-b777-thread-83.html#post4321101

http://www.pprune.org/rumours-news/340666-ba038-b777-thread-44.html#post4046089

[fotoguzzi]

Hello (please ignore if redundant or off topic),

Flight data recorders and other applicable data and components were retrieved from the airplane for testing and evaluation.Would there have been more information available if the pilot had landed as soon as possible versus continuing to Atlanta?

Thanks.

[ChristiaanJ]

quote: Flight data recorders and other applicable data and components were retrieved from the airplane for testing and evaluation.end quote
Would there have been more information available if the pilot had landed as soon as possible versus continuing to Atlanta?
Thanks.Unlikely.
Present-day FDRs and QARs run for something like 25 hours before they start over-writing previous data. Older CVRs looped in 30 minutes, but more recent ones loop and over-write only after two hours... And in this case the pilots were right there to tell what happened anyway.

Even if they had landed ASAP, the rollback gremlin would probably have quit the aircraft well before....
On BA038 we've been looking at ice... which would have melted by the time the investigators arrived.
This time, we may be looking at ice again, or a transient, or whatever... it came and went.
So let's hope this time the rollback gremlin left a bit more of a DNA footprint.... I'm sure everybody would like to catch him... and wring his neck.

CJ

[precept]

Christiaan J:

Right you are. Ice, or not, one trusts the eventual science shall present an opportunity for refining design requirements rather than perpetual procedural refinements. The aviation industry always welcomes science to further its capabilities. From the 1920's when the science was that there was "not enough lift in the air" to the capabilities of todays aircraft, science will bring us through. We enjoy the performance of todays professional pilots, aircraft and supporting systems. Under it all though is the requirement to continuously learn and improve. Happy New Year to all.