AF 447 Search to resume

[mm43]

wetbehindear;

I'd go along with Grizzled and welcome you to this sometimes disjointed discussion on the fathomable / unfathomable logic and algorithms used by Airbus in protecting its aircraft from the questionable antics of those ostensibly in charge at the pointy end.

Having read your post of yesterday, I suddenly realized I had read it all just a few hours earlier. We've got Machinbird to thank for posting the link to the (your??) blog.

EDIT:: While on this subject, I have found an interesting document published by the European Commission Transport Research Unit, titled Clearance of Flight Control Laws using Optimisation. The document is dated February 2010, and in the Results section Airbus is mentioned as soon to incorporate the results of this research into its internal Airbus flight control laws validation process.

mm43

[bia botal]

We will have to find the recorders to know for certain but I am beginning to see potential Swiss Cheese holes in Airbus system design.

I have been following this thread since the beginning, like i am sure many many others, but just reading the contents of discussion trying to get my head around what happened to this flight. For the most the information is staggering and the knowledge of the primary contributors is very impressive, which is why i find the quoted comment alarming, is this the likely outcome of this whole sorry event, that the a330 has a built in flaw, are you suggesting that once the aircraft goes into ALT LAW, all protections are lost and the aircraft in severe turbulence anyway is un-flyable by the crew.

[wetbehindear]

Mea culpa

mm43

It was my mistake not to ask my question in a more straightforward manner.

When I read the Hudson event NTSB report I was taken aback by the manner of Airbus response to a (imho) 2+2=4 situation i.e. not preparing dual engine failure checklist under 20k feet. It looked like they turned a blind eye to the apparent problem at hand.( Pls see NTSB Final Report on US Airways 1549 thread )

When I read the blog which machinebird gave a link to -I'm indebted to him - ,again I was surprised by the handling of the problem. But in this case being not qualified to judge what has been brought forward under the paragraphs of Epistemic vulnerability and Context vulnerability I tried to seek expert view though in an inadept manner.

Are there fellow pruners around who can amplify what this blogger claiming and whether it is correct or not ?

Very best

wetbehindear

[SPA83]

AF 447 significant events

may be some answers here : http://henrimarnetcornus.20minutes-blogs.fr/

[Machinbird]

are you suggesting that once the aircraft goes into ALT LAW, all protections are lost and the aircraft in severe turbulence anyway is un-flyable by the crew.

Absolutely not. What I am beginning to see is the limits to which Airbus took their design concept and how there may be corners of the envelope that may not be completely appropriate in their treatment by the various aircraft software systems.
Compare the systems decision tree to the branches of a tree. How far out toward the tips of the branches will you take the design process (keeping in mind that you can likely branch many more times if you had the time and money to do so)? At some point, a decision is made that what has been achieved is sufficient for 99.99999% of the possibilities. Only problem is, the probability estimate may be off.
Unfortunately, computers do what you tell them to do in an exact literal sense. Sometimes it may not be what you intended them to do.

[thermalsniffer]

Confusion on Prim Sec Shutdown

Per Svarin at 1683 and Hazelnuts at 1686, could someone clarify the answers to Svarian's questions in 1683 and other related posts. BEA 2nd Report p. 36 regarding Prim and Sec ECAMs, states quote: "In the absence of an associated fault message, it is not possible to command a shutdown." The report then discusses the possibility of the missing fault message. What "associated faults" will allow manual shutdown of PRIM1 and SEC1?

[HazelNuts39]

lost in translation

Originally Posted by thermalsniffer

"In the absence of an associated fault message, it is not possible to command a shutdown."

Perhaps you are misled by a less-than-perfect translation of a somewhat convoluted french sentence:

En l’absence de message fault associé, l’arrêt ne peut être que commandé.

It means: In the absence of an associated fault message, the shutdown must have been commanded. (lit. ... cannot have been other than commanded)


REGARDS,
HN39

[kilomikedelta]

Aviation Software

I believe it is essential to realize that any software written in a language at a level higher than machine code native to a specific processor is subject to the vagaries of the compiler that translates that higher level language into machine code. I do not know what hardware processors are used by Airbus or Boeing but I'm sure that the coding for them is written in a higher level language than native machine code and that the writers of those higher level language programmes are unaware of the inherent hardware idiosyncrasies of the target processor or those of the compiler to which they are feeding their programming efforts. Software debugging may catch programming errors when tested to respond to certain conditions or limits but the response of software written in generic higher level languages and sometimes in machine code will be unknown when presented with anomalous inputs. In my 45 years of experience of hardware design and software programming (it was mostly machine code back then), I have learned that the truism that computers are idiots and that programmers who do not understand their target processors can be led to be idiots too has never been disproved. I'm not an aeronautical engineer but I'd be more trusting of the current generation of aircraft if there were a bit more cable and hydraulics in modern aeroplanes that could be utilized by an experienced human in the cockpit when the computer bugs manifest themselves (sorry, I know Ryanair will disagree). The software that runs this forum doesn't seen to recognize carriage returns or line feeds.

[HarryMann]

The
software
that
runs
this
forum
doesn't
seen
to
recognize
carriage
returns
or
line
feeds.

Mmm!
The text editor embedded in the forum posts display does seem to respond to carriage returns at least.

I doubt there is a software~processor interpretation problem in Airbus aircraft

I agree though many would like (or think they would like) a bit more manual reversion in instrumentation and controls than appears to be the case in some modern aircraft...

[kilomikedelta]

CRLF in the forum text editor doesn't seem to work with Firefox and Windows 98 (an old OS but stable, unlike Vista - the darling of a "trusted" multinational corporation like Airbus or Boeing). Your may believe that aviation software is 100% reliable but are you 100% sure. SLF want to know. By the way, those were line feeds.

[MountainWest]

Undocumented Software Features

kilomikedelta,

As another hardware / software / systems person with 40+ years experience I agree with your post #1707. I have yet to see a complex system that does not contain at least one surprise. Many devices have succumbed to gravity at inconvenient times due to software issues, including F-117, Ariene V, Mars Climate Orbiter, etc. Whether AF447 is another example remains to be seen.

[p51guy]

Is any effort being made to find the aircraft now?

[mm43]

No.

We are waiting for an update from the BEA

mm43

[mosteo]

I believe it is essential to realize that any software written in a language at a level higher than machine code native to a specific processor is subject to the vagaries of the compiler

If some industry goes to great lengths to ensure its software quality, that's the aviation industry. Compilers have to pass certification levels (see, e.g., here or here). Among other things, traceability from source code to generated assembler is validated. About the software itself, formal proof (e.g. SPARK) and real-time deadline analysis I think are the norm. Nothing to do with the crash-prone in-flight entertainment systems.

I'm in total agreement that computers do what they're told and nothing more, nothing less, and there can be a problem of under/misspecification (basically, the human side of software design). How can we expect any system to perform correctly out of its specs, be it code or a mechanism with its tolerances? My point is that I don't think "computer fairies" in the sense of the ones we experiment in our desktop computers have much to do with this crash, at least until some evidence in this direction is found. And while general software production is certainly of a bare-minimum-and-ship quality, that's not the case in avionic systems.

Someone talked before about the different degradation qualities of computer systems and mechanical systems, once you push their limits. I think this may be a valid point for discussion; once you exceed some routine preconditions, bets are off. But then also cables snap.

Going slightly off-topic: I'm not an insider, but I'm a software engineer with a great interest in these matters. I was told once by some person in the business something that I don't know if is the truth (I'd like to know if it is not, obviously), but that to me, as a programmer, is quite impressive. He told that no plane accident to date can be attributed to a software bug. Note that I mean a runtime bug, in the sense of correct input, unexpected output; not some misunderstanding between pilot and automation, or operating out of the specifications (which can fail to anticipate situations, as Machinbird I think is concerned in a recent post).

E.g. the much touted Ariane 5 blow-up was not really a software programming problem (and that's not civil aviation anyway), but a software management issue. The closest I know are the unexpected pitch commands recently in some Qantas A330/340, but I think that's still unclear. Also I vaguely remember that unexpected spikes in input data could be the cause (although if these spikes came from another software component I don't know).

[Peter-1959]

Aviation Software

ref post 1707: There is a lengthy and predefined process preceeding aviation software validation and certification. Development and implementation of software hosted by the airplane's flightcontrol system must comply to certain (not limited too .. ) criteria when falling into the following categories:
Level A: Software whose anomalous behaviour, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition
for the aircraft.
Level B: Software whose anomalous behaviour. as shown by the system safety assessment process would cause or contribute to a failure of system function resulting in a hazardous / severe-major failure condition for the aircraft. (RTCA DO178)
These categories and subsequent validation requirements are not new but established decades ago.

Rgds

[Machinbird]

Going forward

...as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition

I think what Airbus needs to do is set the probability of triple airspeed failure = highly probable in their analysis, and then modify their systems so that such events are ho-hum non-events. This will not be inexpensive. Then again, accidents are not inexpensive either. They have to be already looking at this question and cringing at the cost. We need to collectively hurry them along in their decision process---before we have more reasons to do so.
Making better pitot tubes more nearly resembles putting band aids on the existing process.
You can almost bet that they discounted the possibility of a common mode failure of the pitot tubes in their initial system design process.

[MurphyWasRight]

Arian 5 SW

Mosteo's point:

the much touted Ariane 5 blow-up was not really a software programming problem (and that's not civil aviation anyway), but a software management issue.

The low level cause of the Ariane 5 failure was indeed a SW bug:

A float to integer conversion caused an unprotected exception that in turn caused the navigation computers to report an error code rather than current position. Both failed within one or 2 master clock ticks (1 ms as I recall).

The conversion was unprotected since it was in a calibration routine that was originally not meant to be running after lift-off. This was changed to allow fast recycling in case of a last second abort.
Extensive analysis showed that the registers would not overflow during the first (45 seconds?) following lift-off that the routine continued to run.

The (mis)management issues are much more interesting though:

The system was designed with the assumption that the only hardware was subject to failure, had the SW been designed to continue to provide "I may have a problem but here is my best guess boss data" the flight would have been a success.

The real cause of the disaster though was cutting of testing due to time and budget constraints, since the code had flown previously on prior rockets it was decided that testing could be reduced.

The Arian 5 flight profile was steeper, resulting in the numerical overflow.

[Peter H]

Going forward

Machinbird:
I think what Airbus needs to do is set the probability of triple airspeed failure = highly probable in their analysis, and then modify their systems so that such events are ho-hum non-events.
This will not be inexpensive.
... They have to be already looking at this question and cringing at the cost.

Your analysis is convincing, however there might be another option.

What would have happened if the pilot was warned of the imminent pitot-tube failure and then flew the plane appropriately for unreliable-airspeed [e.g. flying attitude & power]?

Would this have kept the wolves at bay until the plane was out of the ice-crystal conditions? Would a few false alarms in severe ice-crystal conditions be acceptable?

If so, don't we have the much cheaper option of designing a pitot-tube that reports when its heater is being overwhelmed ... and integrating this information into the AB display.

Regards, Peter

As well as providing early warning of imminent failure, a smarter pitot-tube could also provide maintenance-level feedback of the thermal headroom actually available in flight.

[mm43]

Reference has earlier been made to an A330/AF447 blog by Matthew Squair, an Australian Engineering Systems Analysist, who has a Marine Engineering background. He has questioned the viability of the Airbus triple redundancy systems, and has used the QF72 faulty air data incident as an example of how asynchronous as opposed to synchronous sampling of data can lead to momentary spikes skewing the resultant output. The case he has made relates in particular to the polling method used in determining valid AoA, a special case, as it is possible that in certain sideslip type situations AoA vanes #1 & #2 on the port-side may disagree with the single vane #3 on the starboard-side.

Issue was taken with the Airbus statement that spikes occur in air data on many flights, but there is little evidence of them ever having caused any untoward affects. To which Matthew commented, "... for high integrity systems a lack of evidence cannot be used as evidence of lack". At face value, a valid point.

Without knowing precisly the algorithms used by Airbus in determining what is "valid" and what is "not valid" sensor input, it is not easy to confirm nor deny that momentary spikes have been or could be responsible for delivering erroneous data to to the AIRDU's and PRIMs. My initial reaction is that time domain analysis of raw data needs to be made, but time is of the essence and delaying data by a few milliseconds could be critical. Why not use higher sample rates? Well, some noise spikes could appear over a number of cycles, but higher rates do lend themselves to determining a trend quickly. Comparison of multiple sensor trends should enable determining if the trend is valid or not. Different sensors may have different trend rates, but if their directions of trend are the same and fall within allowable rates of change, then it should be possible to sort out "good" from "bad" data. Common mode rejection techniques are often used to sort out noise problems that are potentially localised, e.g. earth loops as in audio equipment and other power supply induced noise. For instance, a lightning strike may cause a momemtary blip in otherwise clean power, but the common mode rejection techniques ensure that a similar out of phase blip cancels out any rogue input/output.

This is drifting a bit, but situational awareness is nothing more than an overview of current trends that leads you to believe that the bulls-eye is where it should be. In the example I gave back in post #1690, i.e.

There is something about this whole situation that doesn't quite fit, i.e. a sophisticated FBW aircraft is being held by AP in an increasing nose up attitude and decreasing A/THR to maintain a BARO-ALT. The available inertia is disappearing fast, and somehow I think that that scenario would have been covered in the design algorithms as indicative of unreliable airspeed.

- is actually a relatively long-term trend which if put to the bulls-eye test would fail.

mm43

[Machinbird]

Peter H

What would have happened if the pilot was warned of the imminent pitot-tube failure and then flew the plane appropriately for unreliable-airspeed [e.g. flying attitude & power]?

Would this have kept the wolves at bay until the plane was out of the ice-crystal conditions?

The short answers are: Yes,probably so, assuming the aircraft continued to fly like an aircraft, but NO, if activation of a protection mode took control of the aircraft away from the crew and actually caused the loss of control, for example, the Vmo/Mmo protection mode scenario.
Airbus protections work on the mother knows best principle. The crew is outvoted. Perhaps the crew should have their own button to allow them to use their human airmanship over that of the computers. Not necessarily as in direct mode, but rather like a protection override button, something to be used with great caution, knowing that the Monday morning quarterbacks will be looking over your shoulder and you had better be right in your decision.