AF 447 Search to resume
Join Date: Jul 2009
Location: UK
Posts: 134
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Mar 2010
Location: Sweden
Age: 87
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
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 -
Note he spoke about the flight recorders in the past tense, rather than they have not been found!
mm43
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.
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.
mm43
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
I did a search for a full text of the French report of the AGM, but without success.
CJ
Join Date: Jan 2008
Location: Herts, UK
Posts: 748
Likes: 0
Received 0 Likes
on
0 Posts
mm43
Is this categorically correct do you think?
What air data value and what use of that data would really be critical or compromised by a throughput a few milliseconds slower.
And if an exampe can be given, then of what value when the data quality is potentially compromised.
..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.
What air data value and what use of that data would really be critical or compromised by a throughput a few milliseconds slower.
And if an exampe can be given, then of what value when the data quality is potentially compromised.
Join Date: Jun 2009
Location: I am where I am and that's all where I am.
Posts: 660
Likes: 0
Received 0 Likes
on
0 Posts
HarryMann, I've resisted replying to mm43 on that point. Any cogent reply would get too deeply into analysis of digital data and filter theory.
For example: Sensor data of any sort is inherently noisy. Think in terms of turbulence and the way it would randomize data from a pressure detector on a part of the aircraft with turbulent air flow.
You can smooth data which is inherently noisy by filtering it. Depending on the characteristics of the noise from sensors themselves increasing the sample rate might and might not do some good. Note that the sensors themselves will provide some filtering of high frequency noise.
If you filter over several minutes the accuracy of the filter output can be quite good. But that much filtering introduces delay. In point of fact there are two basic types of filters in the digital realm, finite and infinite impulse response.
The infinite impulse response filters resemble pure analog filters. The delay of the filter is directly related to the filter's bandwidth and "shape". The narrower the filter the longer the delay. The same applies to the finite impulse response filters with slightly different constants involved.
The response of a 10 Hz low pass filter of the same design is 10 times slower than a 100 Hz low pass filter. And the output has 10 times the noise power for what is called "White Gaussian Noise" (typical radio noise with no antenna connected.) I have no reason to presume aircraft sensors respond with WGN superimposed on the signals. But it's a starting point for discussion.
I think you can see where this is going. It gets deeper and deeper and nastier as you dig into it. The upshot of it all is that you must determine what response rate is really necessary for keeping the control loops for the aircraft stable while filtering out enough noise that the aircraft is not trying to respond to turbulence that is better damped out by wing design.
I do know that this is an area Rockwell Collins is experimenting with. I saw a video from them some time back that showed an autopilot controlled "model" aircraft lose its wing and continue to fly after a momentary upset. (Of course, if you put enough motor on a brick it will fly. The trick is to get it to go where you want. Ever see pictures of the flying lawn mower?) I figure this is an area where there is still some research needed to find optimums. And it all interacts with the physical characteristics if the aircraft such as wing flexibility and so forth.
So I hesitate to suggest a higher sample rate might be beneficial, unless there is CPU power to burn. (I suspect that was not the case given the year the computers for the A330 series was designed.)
I've rambled too much here. Please excuse me. I hope you learned enough to appreciate some of the problems involved just in filtering data alone.
For example: Sensor data of any sort is inherently noisy. Think in terms of turbulence and the way it would randomize data from a pressure detector on a part of the aircraft with turbulent air flow.
You can smooth data which is inherently noisy by filtering it. Depending on the characteristics of the noise from sensors themselves increasing the sample rate might and might not do some good. Note that the sensors themselves will provide some filtering of high frequency noise.
If you filter over several minutes the accuracy of the filter output can be quite good. But that much filtering introduces delay. In point of fact there are two basic types of filters in the digital realm, finite and infinite impulse response.
The infinite impulse response filters resemble pure analog filters. The delay of the filter is directly related to the filter's bandwidth and "shape". The narrower the filter the longer the delay. The same applies to the finite impulse response filters with slightly different constants involved.
The response of a 10 Hz low pass filter of the same design is 10 times slower than a 100 Hz low pass filter. And the output has 10 times the noise power for what is called "White Gaussian Noise" (typical radio noise with no antenna connected.) I have no reason to presume aircraft sensors respond with WGN superimposed on the signals. But it's a starting point for discussion.
I think you can see where this is going. It gets deeper and deeper and nastier as you dig into it. The upshot of it all is that you must determine what response rate is really necessary for keeping the control loops for the aircraft stable while filtering out enough noise that the aircraft is not trying to respond to turbulence that is better damped out by wing design.
I do know that this is an area Rockwell Collins is experimenting with. I saw a video from them some time back that showed an autopilot controlled "model" aircraft lose its wing and continue to fly after a momentary upset. (Of course, if you put enough motor on a brick it will fly. The trick is to get it to go where you want. Ever see pictures of the flying lawn mower?) I figure this is an area where there is still some research needed to find optimums. And it all interacts with the physical characteristics if the aircraft such as wing flexibility and so forth.
So I hesitate to suggest a higher sample rate might be beneficial, unless there is CPU power to burn. (I suspect that was not the case given the year the computers for the A330 series was designed.)
I've rambled too much here. Please excuse me. I hope you learned enough to appreciate some of the problems involved just in filtering data alone.
Autopilot Overreaction
JD-EE
Right on! Back in the Jurassic Age, I was taught that in heavy turbulence you should disconnect the autopilot because it would react with inappropriately strong control inputs. The question now becomes: Will more modern autopilots recognize that an easy hand on the controls is best or should we disconnect and concentrate on maintaining pitch attitude?
The upshot of it all is that you must determine what response rate is really necessary for keeping the control loops for the aircraft stable while filtering out enough noise that the aircraft is not trying to respond to turbulence that is better damped out by wing design.
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
Analog vs Digital
Does anyone have any idea regarding whether things like AOA, Pitot Pressure, Static Pressure, Acceleration and TAT start out as digital information or as analog information that is then processed to digital on A330 systems?
If initially analog data, RC smoothing can smooth spiky ouput very reliably and predictably if the time constant is appropriately chosen. Of course if the data is just plain wrong, the output is just as wrong. Data that starts out digital encounters the problems of choosing appropriate processing techniques that JD-EE has discussed.
Ideally data needs to be reviewed for appropriateness before being used by aircraft systems.
Checks such as:
Data checking would probably require a new computer (in triplicate) together with certification of its correct operation. Trying to use existing aircraft computers for this purpose would likely slow them down.
The present Airbus solution to the airspeed problem seems to be diversity of pitot tube manufacturers. Perhaps they too believe AF447 encountered a synchronous common mode pitot icing situation. They not only removed Thales P/N C16195AA pitots from service, but instituted a defined mix of Goodrich and Thales pitots.
From AD No.: 2009-0195
Does anyone have data on how this new pitot configuration is faring?
If initially analog data, RC smoothing can smooth spiky ouput very reliably and predictably if the time constant is appropriately chosen. Of course if the data is just plain wrong, the output is just as wrong. Data that starts out digital encounters the problems of choosing appropriate processing techniques that JD-EE has discussed.
Ideally data needs to be reviewed for appropriateness before being used by aircraft systems.
Checks such as:
Is the value reasonable by itself?
If the value is changing, is the rate of change appropriate?
Is the data consistent with other related aircraft data, not just with like sensors, but with related aircraft sensors.
Has there been recent anomalous behavior by that sensor?
Data input identified as suspect should have its confidence rating reduced appropriately so that it is not used or is minimally used. Data checking would probably require a new computer (in triplicate) together with certification of its correct operation. Trying to use existing aircraft computers for this purpose would likely slow them down.
The present Airbus solution to the airspeed problem seems to be diversity of pitot tube manufacturers. Perhaps they too believe AF447 encountered a synchronous common mode pitot icing situation. They not only removed Thales P/N C16195AA pitots from service, but instituted a defined mix of Goodrich and Thales pitots.
From AD No.: 2009-0195
" replacement of Thales Avionics P/N C16195BA pitot probes at positions 1 (Captain) and 3 (Stand by) with Goodrich P/N 0851HL probes and the installation at position 2 (First Officer) of a Thales Avionics pitot probe P/N C16195BA."
Does anyone have data on how this new pitot configuration is faring?
Join Date: Feb 2008
Location: Subterranea
Age: 70
Posts: 187
Likes: 0
Received 0 Likes
on
0 Posts
Regarding AOA and Pitot and Static pressures:
AOA are digital signals to and from the ADR part of the ADIRU's.
Pitot probes or static ports pressure go through ADM's (Air Data Modules) via ARINC busses to the ADR's.
ADM inputs are one pressure input and several discrete inputs. All ADM's are identical. The discrete inputs determine the ADM location and the type of pressure data (Pitot or Static) to provide to the ADR part of the ADIRU. The ADIRU's provide a DC voltage to supply each associated ADM.
Each ADM contains the following components: a pressure transducer which converts pressure into an analog signal. This analog signal is then converted into a digital signal by means of an analog/digital converter. The digital signal then passes through a microcomputer which processes an ARINC signal according to the discrete inputs and according to the digitized pressure.
The ADM output is an ARINC bus which provides digital pressure information, type of pressure, ADM identification and BITE status to the ADIRU.
The ADR processes sensor and ADM inputs in order to provide air data to "users."
Captain and F/O static ports directly provide static pressure to four ADM's which, as mentioned above, convert this pressure into digital format. ADR1 and ADR2 compute the average static pressure value from left and right ADM's.
Standby static ports provide an average pressure directly to the standby instruments and to a single ADM connected to ADR3.
The three pitot probes directly provide the total pressure to three ADM's. Capt. pitot thru an ADM connected to ADR1, F/O pitot thru an ADM connected to ADR2, and standby pitot thru an ADM connected to ADR3.
Regards,
G-d
AOA are digital signals to and from the ADR part of the ADIRU's.
Pitot probes or static ports pressure go through ADM's (Air Data Modules) via ARINC busses to the ADR's.
ADM inputs are one pressure input and several discrete inputs. All ADM's are identical. The discrete inputs determine the ADM location and the type of pressure data (Pitot or Static) to provide to the ADR part of the ADIRU. The ADIRU's provide a DC voltage to supply each associated ADM.
Each ADM contains the following components: a pressure transducer which converts pressure into an analog signal. This analog signal is then converted into a digital signal by means of an analog/digital converter. The digital signal then passes through a microcomputer which processes an ARINC signal according to the discrete inputs and according to the digitized pressure.
The ADM output is an ARINC bus which provides digital pressure information, type of pressure, ADM identification and BITE status to the ADIRU.
The ADR processes sensor and ADM inputs in order to provide air data to "users."
Captain and F/O static ports directly provide static pressure to four ADM's which, as mentioned above, convert this pressure into digital format. ADR1 and ADR2 compute the average static pressure value from left and right ADM's.
Standby static ports provide an average pressure directly to the standby instruments and to a single ADM connected to ADR3.
The three pitot probes directly provide the total pressure to three ADM's. Capt. pitot thru an ADM connected to ADR1, F/O pitot thru an ADM connected to ADR2, and standby pitot thru an ADM connected to ADR3.
Regards,
G-d
Join Date: Mar 2010
Location: overthehillsandmountains
Posts: 140
Likes: 0
Received 0 Likes
on
0 Posts
Possible phase 4
Secretary of State for Transport Dominique Bussereau said today that he would make a decision from September on a possible new phase of search to try to explain the circumstances of the accident to flight AF447 between Rio and Paris. "I will have in early September elements from the BEA that will allow me to propose a possible resumption of search".
(Translation mostly by Google)
(Translation mostly by Google)
Join Date: Jun 2009
Location: I am where I am and that's all where I am.
Posts: 660
Likes: 0
Received 0 Likes
on
0 Posts
Machinbird, my discussion was intended to be generic, analog or digital. Digital is a little more difficult to stabilize in a feedback loop than is analog if the digital sample rate is too low. If the digital sample rate is high enough very simple (short time constant) analog filtering preceding the digital sampling can give close enough to the same results as analog that distinguishing a difference is a futile. (... except, I might note, for the same people who think gold plated wall power sockets make their audio sound better for their hi-fi system.)
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
Hi,
EDIT:
I assume this is the original link ?
AFP: Crash du Rio-Paris en 2009 : dcision sur une ventuelle nouvelle recherche en septembre
"I will have in early September elements from the BEA that will allow me to propose a possible resumption of search".
I assume this is the original link ?
AFP: Crash du Rio-Paris en 2009 : dcision sur une ventuelle nouvelle recherche en septembre
Last edited by jcjeant; 12th Jul 2010 at 23:12. Reason: Added link
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
Just as BP cannot walk away from the Gulf oil spill, Airbus and AF cannot walk away from the question of what happened to AF447, no matter how much the financial pinch hurts. If they don't nail down the cause precisely, they will have to fix any long shot possibility that anyone can demonstrate might have caused the accident. The pitot tube AD solution didn't make the problem completely go away, it only has improved the statistics against loss of valid airspeed indications into the range that everyone else is currently accepting. The question to be answered is what happened after the triple pitot disagree.
Last edited by Machinbird; 13th Jul 2010 at 11:48. Reason: incorporate Sensor Validation's comments/correction
Join Date: Mar 2010
Location: overthehillsandmountains
Posts: 140
Likes: 0
Received 0 Likes
on
0 Posts
jcjeant:
That's the same quote from Mr Bussereau. I saw the rest of the text from a different source.
Machinbird:
There's no way that Airbus would want this to fade away. There are thousands of Airbus aircraft flying with similar systems, including some A380s, and they are more than anyone interested in clearing their name. That means finding the recorders.
That's the same quote from Mr Bussereau. I saw the rest of the text from a different source.
Machinbird:
There's no way that Airbus would want this to fade away. There are thousands of Airbus aircraft flying with similar systems, including some A380s, and they are more than anyone interested in clearing their name. That means finding the recorders.
Join Date: Jul 2009
Location: UK
Posts: 134
Likes: 0
Received 0 Likes
on
0 Posts
Just to be pedantic - its triple pitot disagree, which means only a double pitot failure. The third pitot may be working fine, but you have no way of knowing. The triple sensor system can only detect and cope with a single sensor failure.
Of concern, to me at least, is what happens if two sensors fail at the same time in the same way (yes incredibly unlikely - but same sensor design/ heating, same drain holes - same cloud), the good sensor input would be rejected and flight controls act on bad-data for a short time?
What has happened to all the Thales AA probes removed from A/C - wouldn't it have been sensible to collect and inspect and look for signs of decay with age/ maintenance. I understand they are just certified scrapped when replacements fitted.
Of concern, to me at least, is what happens if two sensors fail at the same time in the same way (yes incredibly unlikely - but same sensor design/ heating, same drain holes - same cloud), the good sensor input would be rejected and flight controls act on bad-data for a short time?
What has happened to all the Thales AA probes removed from A/C - wouldn't it have been sensible to collect and inspect and look for signs of decay with age/ maintenance. I understand they are just certified scrapped when replacements fitted.
Join Date: Jan 2008
Location: Herts, UK
Posts: 748
Likes: 0
Received 0 Likes
on
0 Posts
What has happened to all the Thales AA probes removed from A/C - wouldn't it have been sensible to collect and inspect and look for signs of decay with age/ maintenance. I understand they are just certified scrapped when replacements fitted.
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
Of concern, to me at least, is what happens if two sensors fail at the same time in the same way (yes incredibly unlikely - but same sensor design/ heating, same drain holes - same cloud), the good sensor input would be rejected and flight controls act on bad-data for a short time?
Probably not so unlikely as you indicate considering the likely abrupt transition to the inside of a rapidly growing Cb. A perfect setup for a common mode "malfunction".