Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF 447 Search to resume

Tech Log The very best in practical technical discussion on the web

AF 447 Search to resume

Old 7th Jul 2010, 11:43
  #1701 (permalink)  
 
Join Date: Dec 2007
Location: france
Age: 71
Posts: 74
AF 447 significant events

may be some answers here : http://henrimarnetcornus.20minutes-blogs.fr/
SPA83 is offline  
Old 7th Jul 2010, 14:04
  #1702 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 78
Posts: 1,458
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.
Machinbird is offline  
Old 7th Jul 2010, 14:19
  #1703 (permalink)  
 
Join Date: Jul 2009
Location: USA
Age: 58
Posts: 28
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?
thermalsniffer is offline  
Old 7th Jul 2010, 17:33
  #1704 (permalink)  
 
Join Date: Jul 2009
Location: France - mostly
Age: 80
Posts: 1,689
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
HazelNuts39 is offline  
Old 7th Jul 2010, 23:35
  #1705 (permalink)  
 
Join Date: Jun 2009
Location: Toronto
Age: 75
Posts: 117
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.
kilomikedelta is offline  
Old 8th Jul 2010, 01:03
  #1706 (permalink)  
 
Join Date: Jan 2008
Location: Herts, UK
Posts: 743
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...
HarryMann is offline  
Old 8th Jul 2010, 01:12
  #1707 (permalink)  
 
Join Date: Jun 2009
Location: Toronto
Age: 75
Posts: 117
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.

Last edited by kilomikedelta; 8th Jul 2010 at 01:27.
kilomikedelta is offline  
Old 8th Jul 2010, 02:50
  #1708 (permalink)  
 
Join Date: May 2010
Location: USA
Age: 72
Posts: 18
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.
MountainWest is offline  
Old 8th Jul 2010, 03:21
  #1709 (permalink)  
 
Join Date: Jun 2009
Location: US
Posts: 497
Is any effort being made to find the aircraft now?
p51guy is offline  
Old 8th Jul 2010, 04:24
  #1710 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 77
Posts: 1,330
No.

We are waiting for an update from the BEA

mm43
mm43 is offline  
Old 8th Jul 2010, 08:15
  #1711 (permalink)  
 
Join Date: Jun 2009
Location: Spain
Posts: 13
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).
mosteo is offline  
Old 8th Jul 2010, 10:48
  #1712 (permalink)  
 
Join Date: Jun 2009
Location: 6m below sea-level
Posts: 8
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
Peter-1959 is offline  
Old 8th Jul 2010, 12:48
  #1713 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 78
Posts: 1,458
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.

Last edited by Machinbird; 8th Jul 2010 at 15:27. Reason: change font size-better wording (I hope)
Machinbird is offline  
Old 8th Jul 2010, 15:04
  #1714 (permalink)  
 
Join Date: May 2010
Location: Boston
Age: 69
Posts: 441
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.
MurphyWasRight is offline  
Old 8th Jul 2010, 23:32
  #1715 (permalink)  
 
Join Date: Jun 2008
Location: Cambridge UK
Posts: 165
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.
Peter H is offline  
Old 8th Jul 2010, 23:36
  #1716 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 77
Posts: 1,330
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
mm43 is offline  
Old 9th Jul 2010, 03:08
  #1717 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 78
Posts: 1,458
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.

Last edited by Machinbird; 9th Jul 2010 at 03:34. Reason: attribute quote
Machinbird is offline  
Old 9th Jul 2010, 08:24
  #1718 (permalink)  
 
Join Date: Jul 2009
Location: UK
Posts: 133
Much discussion since first few days after accident that loss of control could have been caused by inappropriate "Pitch and Power" following disconnection of autopilot and auto-thrust - hence the reminder Airbus sent out on 4th June 2009

http://www.pprune.org/rumours-news/3...ml#post4976210

But isn't this a systems design fault - admitting that the auto-controls can hand back control to the pilots in an inappropriate state requiring immediate action?

The BBC made a suggestion that the loss of reliable air-speed was during a commanded speed reduction, so the engines could be close to flight idle.

Shouldn't the a/p and a/thr disconnect leaving the pitch and thrust settings at an appropriate setting for 'steady' flight?

'Steady' in quotes as I suspect you find out how much the controls do to counter the phugoid mode even without turbulence and changing winds inside the storm, so it would be a roller coaster ride.
sensor_validation is offline  
Old 9th Jul 2010, 15:25
  #1719 (permalink)  
 
Join Date: Mar 2010
Location: Sweden
Age: 83
Posts: 67
Software bugs

kilomikedelta, mountainwest, mosteo and Peter-1959

Even the best designed, coded, and verified program can contain undiscovered bugs only showing up on very special occations - usually unforseen combinations of events and their timing. I am retired, but have 50 yr+ experience with real-time op:s and programs.
One bug(s) in an ADIRU code is documented:

Cited from ATSB final report on the 9M-MRG upset.
The ADIRU OPS versions up to and including version -07 contained a latent software error in the algorithm to manage the sensor set used for computing flight control outputs which, after the unit went through a power cycle, did not recognise
that accelerometer number-5 was unserviceable. The status of the failed unit was recorded in the on-board maintenance computer memory, but that memory was not checked by the ADIRU software during the start-up initialisation sequence. The software error had not been detected during the original certification of the ADIRU and was present in all versions of the software. The effect of the error was suppressed by other software functions in OPS version -03. When the OPS version - 04 was released in December 1998, the software functions that suppressed the error were further revised to improve shop repair capability, re-exposing the undiscovered latent problem.
The variations to OPS version -04 and subsequent versions included changes to the Fault Detection and Isolation (FDI) software which monitored the serviceability of various ADIRU components. The changes allowed the FDI software to detect any
transient unserviceability of hardware and reinstate it if no further unserviceability was detected. The FDI software allowed the erroneous output values from accelerometer number-5 that had failed in 2001, to be used by the primary flight computer and other aircraft systems when accelerometer number-6 failed, just prior to the in-flight upset.
The effect of the software error was partially offset by the inclusion of mid-value select (MVS) within the primary flight computer. The MVS function was included in the primary flight computer to moderate the effect of anomalous outputs from the
ADIRU. Analysis and testing during initial development indicated that these theorized outputs could not occur, and the MVS function was deemed no longer necessary. However, a decision was made by the aircraft manufacturer to retain the MVS function in the PFC.
Diversification is offline  
Old 10th Jul 2010, 04:36
  #1720 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 77
Posts: 1,330
At a shareholder's meeting of the Air France / KLM Group, which was reported on 8 July 2010 by Bloomberg Businessweek, the Chief Executive Officer Pierre Henri Gourgeon when questioned made the following comments -
Shareholders asked Gourgeon about safety practices in the wake of the fatal crash last year of a plane flying from Rio de Janeiro to Paris.

The airline has assembled a team of full-time experts, including pilots, to study practices in the air and on the ground, and suggest improvements, he said. Some cockpit changes have been implemented, the CEO said, without giving details.

No conclusions have been reached about the cause of the AF447 accident, he said. The black boxes, or flight recorders, were never found.
Note he spoke about the flight recorders in the past tense, rather than they have not been found!

mm43
mm43 is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information

Copyright © 2018 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.