Investigators Suspect Computers Doomed Air France Jet

DesScorp writes "Investigators working with the wreckage of Air France flight 447 believe the aircraft suffered cascading system failures with the on-board computers, eliminating the automation the aircraft needed to stay aloft. 'Relying on backup instruments, the Air France pilots apparently struggled to restart flight-management computers even as their plane may have begun breaking up from excessive speed,' reports the Wall Street Journal. Computer malfunctions may not be an isolated incident on the Airbus A330, as the NTSB is now investigating two other flights 'in which airspeed and altitude indications in the cockpits of Airbus A330 aircraft may have malfunctioned.'"

Comments

Two things

[Kupfernigk]

First, the article is mainly about whether the breakup was ultimately caused by over-reliance on automation leaving pilots insufficiently equipped to handle emergencies in manual mode. This business of excessive automation is getting general. As a simple example, my car has front and rear parking sensors. The other day I was parking in a tight space when suddenly I remembered I was in someone else's car, just a few inches from a steel barrier. My parking habits are now quite conditioned to the bleep patterns from front and rear, and switching back to manual mode slowed me right down. On the other hand, I can moor my boat, entirely by eye and feel, in a fifteen-knot sidewind without a bow thruster. It's purely a matter of experience and conditioning.

Second, the US announcement of the two computer failures, neither of which caused an accident, presumably has nothing at all to do with Boeing's recent embarrassment over continuing delays and cancellations to the Dreamliner, and a desire to damage Airbus?

Aerospace systems are made by humans, but...

[3seas]

...the way aerospace (life critical and specialized or specific field oriented) software is created, it is highly bug free, quite the opposite of feature creep bloat you see everywhere else, but even at the code level there is avoidance of function calls that can introduce another level of abstraction and complexity and contribute to bugs and failure. It is in this way that using the process of elimination we can come to some conclusions about where error is or can most certainly exist, philosophy.

On a hardware level, we have redundant backups and check system....

As such there is one area that neither software nor hardware has but only as a secondary or implimentation of, position.
Human error in concepts, beliefs, philosophies, abstraction definition variation, etc... That which exist before the hardware and software and often what hardware and software creation is inspired by, directed by, guide lined by, etc..

If the philosophy base is wrong then its limitations will manifest through the software and hardware created under such a philosophy and eventually show the limitations, via failure to perform.

There are plenty examples of human philosophy errors, such as how it wasn't until the early 1990's that the Catholic Church exonerated Galileo over his observation the earth revolved around the sun.
The Atlanta Centennial park bombing where the 911 system failed because no-one gave the park an address..... or is the philosophy of programming a 911 system to require an address the error? Or is it a good thing that all things needing 911 are at an address?

My pet peeve of the computer industry, the button on the front of the computer marked with a 0 & 1 symbol(s), yet over engineering has resulted in the meaning of those symbols to be more than "off & on" and this went further in removing the hard on off switch so that when the software based power switch failed, you have to physically unplug the computer from the wall, or take teh battery out.
The correct philosophy for such a switch would be a multi position switch, which the consumer doesn't have to know more than is obvious... And ultimately the motivating philosophy behind the software switch is that of creating an OS that needs a shutdown sequence and time for it. When you think of this "0&1" switch, what better representation of distorting the most basic and fundamental concept of computers with overcomplexifabulocation can there possible be?

Software and hardware is not where the error lies in this Air France tragedy, even if there is failure or limitations found there in hardware and software, but the failure is in not providing a manual override. And if the technology has been made to complex for manual control.... then let grandma crawl under the desk to unplug the damn computer....shut it down until the real problem is fixed.

BTW, due to the competitive commercial nature of aerospace software development tools, there is a level of incompatibility between them and as such there is also motive for playing the lockin game regardless of any "unforseen" risk to others. Perhaps there is a place for open source software here!!!

Don't bow down to the stone image (Stone = computer hardware - Image = software) of the beast of man, for the beast is error prone and his image can be no better. Instead take a closer look at the code.... with many eyes.....

Re:Aerospace systems are made by humans, but...

[cjonslashdot]

Good points.

I will also point out though that systems should be simple to operate, hence Apple for example would never think of having more than two positions for an on/off switch: but in order to achieve that, the system has to be engineered to be truly robust. (I am not saying that Apple equipment is.)

It used to be that equipment had well-defined states, but nowadays everything is programmed using procedural code, and nothing works right anymore.

Electrical engineers are trained in how to design things that really work: they assume asynchronous behavior and concurrency from the outset, and they have design methodologies to create a system that has well-defined states. Procedural code has indeterminate states, unless one uses design paradigms that pair those states, and simulation to test the design. Programmers don't use these techniques: generally speaking, procedural code is hacked together, and so we have laptops OSs that freeze, cellphones that lock up, and airplanes that crash.

The software that exists today is by and large all crap. Procedural programming is appropriate for business apps, but for a reliable real-time system you need an asynchronous design methodology, and you need to prove correctness for critical functions. This is not always done, in aerospace and even for spacecraft software.

Today's programmers don't even have a culture any longer that espouses design and design verification, as opposed to hacking together "code". In their purported quest for "clean code" they have culturally inculcated an obsolete and broken approach.

A330 -- No Margin for Error

[Anonymous Coward]

There are a couple of aspects about the A330 problems that amaze me:

1. How can an airplane be allowed to carry passengers when the margin to airframe disintegration is so narrow? I can understand falling out of the sky if it stalls, but to be able to tear the airplane apart in level flight? What happened to margin of safety in airframe construction -- or is that whole concept now obsolete?
2. If the airplane can send fault messages home, why don't blackbox data streams get sent as well? At least that way there would be some situation info available as opposed to none.
3. In some ways reliance on flight computers is like reliance on spreadsheets or calculators -- if you do not understand what is going on and are not capable of doing it yourself then you cannot tell if the software is correct. Essentially, if the computer says it is so then it is, and you either survive or not.

Re:Unintended effects

[Tanktalus]

Nah. This is all about designing to handle faults you can imagine, and failing to handle faults you can't. Imagining roll-over or stalls are easy. Imagining everything that could go wrong in a wind storm, probably not so much.

Re:Design Philosphy

[Anynomous Coward]

In the case of AF447 the vertical stabilizer was recovered intact with the rudder still properly attached.