AF 447 Search to resume (part2)
Join Date: May 2008
Location: Belgium
Posts: 26
Likes: 0
Received 0 Likes
on
0 Posts
It really takes me back all this discussion of IT and SE. I worked on the "Green" compiler for a short while and it was very clear when DoD selected Green as the official Ada language, everyone from Jean Ichbiah down accepted that Ada needed a lower level tasking mechanism than that provided by Green. It did not happen until 95.
deSitter might realise that the A320 flies with 60 000 lines of code, something that would not even get a "Hello World" working in Windoze
. Small, tight, well tested packages that do a specific task without any excess bloat are the tools that are needed to build ultra-reliable systems. While many could argue with the specification for Airbus' FBW system, few could argue that it does anything other than what the box says (that is good software engineering)
deSitter might realise that the A320 flies with 60 000 lines of code, something that would not even get a "Hello World" working in Windoze
. Small, tight, well tested packages that do a specific task without any excess bloat are the tools that are needed to build ultra-reliable systems. While many could argue with the specification for Airbus' FBW system, few could argue that it does anything other than what the box says (that is good software engineering)
Join Date: Jul 2009
Location: France - mostly
Age: 84
Posts: 1,682
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by sirgawain123
I recall reading in the forum (...) that A330 SOP for unreliable air speed called for CT and 5degrees up nose.
PJ2 has explained that a pilot would not be expected to go to 5° at FL350 and M.82.
Thread Starter
Bad air data? we've been there, done that...
Salute!
The B-2 crash was another topic that got my attention like the AF447 one. Guess I am a FBW freak. STOP ME before I read/post/mull/wonder again!!!!
Most of the links do not work now, but someone might find the accident report referenced in this URL from the F-16.net.
http://www.f-16.net/f-16_forum_viewtopic-t-10556.html
Worth a read, as one of the designers chimes in with some good poop.
Some of the pilot's comments are very revealing., as in "...plane was doing exactly what it was supposed to be doing..." I have heard that this past week or so someplace.
The B-2 crash was another topic that got my attention like the AF447 one. Guess I am a FBW freak. STOP ME before I read/post/mull/wonder again!!!!
Most of the links do not work now, but someone might find the accident report referenced in this URL from the F-16.net.
http://www.f-16.net/f-16_forum_viewtopic-t-10556.html
Worth a read, as one of the designers chimes in with some good poop.
Some of the pilot's comments are very revealing., as in "...plane was doing exactly what it was supposed to be doing..." I have heard that this past week or so someplace.
Join Date: Aug 2009
Location: Germany
Age: 67
Posts: 1,777
Likes: 0
Received 0 Likes
on
0 Posts
Hi,
The 'Maneuvre d'urgence' contains a note that refers to the follow-up procedure 'Vol avec IAS douteuse/ADR Check' that is reproduced in BEA's Interim Report #1, Appendix 9. There you'll find for FL250 - 370, W>190t: 3.5°/90%N1.
PJ2 has explained that a pilot would not be expected to go to 5° at FL350 and M.82.
PJ2 has explained that a pilot would not be expected to go to 5° at FL350 and M.82.
Join Date: Jun 2010
Location: On the ground too often
Age: 49
Posts: 127
Likes: 0
Received 0 Likes
on
0 Posts
Why bother? Back to pilot training. We can also do that. We SHOULD be trained to do it (some are).
Computers can tackle problems such as these. There are millions of flight hours worth of data available covering thousands of parameters of an aircraft such as the A330. I can imagine that by processing this data it would be possible to develop a probabilistic model of the actual dynamics of the aircraft. Computer processing power is available to analyse the actual flight parameters against such a reference database real-time and (a) identify any discrepancies, (b) extrapolate to a high degree of certainty any missing parameters. The real challenge will be to get such solutions certified.
The pitot-static system relies on a duplication of the same devices to achieve redundancy. This approach was far too simplistic for the computers - not only are they multiplied - but they are in fact totally different computers. If we expose 3 identical probes mounted more or less on the same place to the same conditions we are far more likely to encounter multiple failures then if we have different devices. Why were not the same criteria as applied to the fbw computers applied to the air-data system?
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
Wot's an 'rto'? (other than a rejected take-off)?
thanks for your post on state machines.... saved it. We never used that 'notion', but then I'm an analog dinosaur.... Was a good time actually, until the µP asteroid hit.
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes
on
0 Posts
Redundancy, Fault Tolerance and Graceful Degradation
Hi,
Simply, because (it seems) there are no solutions yet available (sensors) to have the (could provide) required redundancy.
In an earlier post you could find patents filed by Airbus SAS on sensors (laser based).
We heard about another solution being prepared for short time UAS. A Software based "hysteresis like" band-aid.
Why were not the same criteria as applied to the fbw computers applied to the air-data system?
In an earlier post you could find patents filed by Airbus SAS on sensors (laser based).
We heard about another solution being prepared for short time UAS. A Software based "hysteresis like" band-aid.
Last edited by Jetdriver; 25th May 2011 at 02:59.
Join Date: May 2008
Location: USA
Posts: 44
Likes: 0
Received 0 Likes
on
0 Posts
Common mode errors
Forgive me if this has already been covered - I have tried to keep up on the thread, but the posting has been very prolific.
I work with sensor driven control systems and have noted that when exposed to slightly abnormal conditions, sensors using the same design initially tend to degrade toward failure in a very similar manner. In redundant sensor systems this can result in a common mode error which may be difficult or impossible to detect. It is only when abnormal conditions become excessive and the sensors become erratic that they provide enough differential error to be detected.
Since the ADR's depend on differential errors to detect potential sensor faults, it seems to me that if all pitot tubes initially began to degrade at about the same rate (perhaps due to water buildup at the drains), such a common mode degradation would not be detected initially and would fool the system into believing that the A/C was traveling faster than it really was. The AP would respond accordingly and slow the A/C down. Then, as water/ice build up continued, the differences in readings would have exceeded the error detection threshold for the system, causing the AP, etc to disconnect. But when that finally happened, the A/C would be going slower and closer to the stall speed than the computed flight envelope would expect.
Could a scenario like this have robbed the crew of precious time needed to make corrections? Are there parameters recorded on the FDR that could be used to determine retroactively that something like this occurred?
I work with sensor driven control systems and have noted that when exposed to slightly abnormal conditions, sensors using the same design initially tend to degrade toward failure in a very similar manner. In redundant sensor systems this can result in a common mode error which may be difficult or impossible to detect. It is only when abnormal conditions become excessive and the sensors become erratic that they provide enough differential error to be detected.
Since the ADR's depend on differential errors to detect potential sensor faults, it seems to me that if all pitot tubes initially began to degrade at about the same rate (perhaps due to water buildup at the drains), such a common mode degradation would not be detected initially and would fool the system into believing that the A/C was traveling faster than it really was. The AP would respond accordingly and slow the A/C down. Then, as water/ice build up continued, the differences in readings would have exceeded the error detection threshold for the system, causing the AP, etc to disconnect. But when that finally happened, the A/C would be going slower and closer to the stall speed than the computed flight envelope would expect.
Could a scenario like this have robbed the crew of precious time needed to make corrections? Are there parameters recorded on the FDR that could be used to determine retroactively that something like this occurred?
gums, #2226
Something that's been bothering me for some time as well. I'm really not
concerned what language is used to program the system, or any other software
related issue, as the field is by and large, well proven. What does bother
me is more of a human factors issue. If the whole idea of automation is
to reduce workload and do something predictable under all circumstances,
how is it that the system can max out the crew by too many or ambiguous
warning messages to the point that they have no idea of the state of
the aircraft ?. Speculation ?. Well perhaps, but how did a perfectly
servicable aircraft with a highly competent crew just fall out of the
sky ?.
The other point, again, is the probes. It cannot be beyond the wit of man
to design a probe that doesn't overheat on the ground, yet has enough
capability to melt ice under worse case conditions. Any engineer looking
at this cold would put in one or more temp sensors such as platinum film or
even a simple thermostat, perhaps a 3 term controller and big fat heating
element. No on/off switches or modes needed either, further reducing
workload and possibility of human error.
All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft.
Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
back to my cave, now, as the press is now focusing upon "deep stall" and
such. And my pea-brained background causes me to wonder how a system
that works as advertised can allow ( maybe even cause) the confused
aircrew to wind up in a loss of control accident. I thought all those
control laws and sub-laws, and sub-sub-laws would help just a bit.
such. And my pea-brained background causes me to wonder how a system
that works as advertised can allow ( maybe even cause) the confused
aircrew to wind up in a loss of control accident. I thought all those
control laws and sub-laws, and sub-sub-laws would help just a bit.
concerned what language is used to program the system, or any other software
related issue, as the field is by and large, well proven. What does bother
me is more of a human factors issue. If the whole idea of automation is
to reduce workload and do something predictable under all circumstances,
how is it that the system can max out the crew by too many or ambiguous
warning messages to the point that they have no idea of the state of
the aircraft ?. Speculation ?. Well perhaps, but how did a perfectly
servicable aircraft with a highly competent crew just fall out of the
sky ?.
The other point, again, is the probes. It cannot be beyond the wit of man
to design a probe that doesn't overheat on the ground, yet has enough
capability to melt ice under worse case conditions. Any engineer looking
at this cold would put in one or more temp sensors such as platinum film or
even a simple thermostat, perhaps a 3 term controller and big fat heating
element. No on/off switches or modes needed either, further reducing
workload and possibility of human error.
All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft.
Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
Join Date: Jul 2009
Location: Planet Earth
Posts: 91
Likes: 0
Received 0 Likes
on
0 Posts
When everything is said and done, if the root cause points beyond a doubt to crew action or lack thereof, the approach taken will be, "if it ain't broken, don't fix it". The most recent AIT from Airbus already points in that direction. Given the complexity of systems involved, on the whole, it may the wiser approach. Improvements will come when they are ready. Until then just fly the airplane.
Not saying its good or bad, just the way it is.
Not saying its good or bad, just the way it is.
All 3 probes are currently of similar design and would thus be expected to fail in a similar way worst case, representing an effective single point of failure. Avoidance of single point failure is the first line of defense in any safety critical work, especially relevant in this case when one considers how important the probe info is for safe operation of the aircraft.
Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
Given the criticality of the probess function, how different can they be and still provide the input that permits airspeed to be used by both the flight crew and the computers in the flight control system? I'll ask the Airbus drivers a question that has come up before: would an AoA gage (which is apparently not common in any airliner design, and for most regimes of flight a supplemental scan item) be a useful addition to the flying display?
AoA is already detected and provided to the system for protections and laws. Is there a good reason not to feed AoA to the flight crew? Adding "one more thing" to the display or HUD or instrument panel isn't to be done lightly, given ergonomics and scan development.
Or, is the general consensus something like this:
if you are flying, your charge is to stay ahead of the aircraft far enough to avoid getting into marginal AoA conditions? From the comments in this, and a host of other threads regarding varying mishaps, I get the impression that adding an AoA gage isn't perceived as the way ahead.
*shields up*
Last edited by Lonewolf_50; 24th May 2011 at 18:14.
Guest
Posts: n/a
syseng68k
hello chris. This was a long train on BA038. Redundancy, Reliability, and Reconciliation.
"...All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft...."
************************************************************ *****
Aviation IS "single point". Flying an aircraft is not overly complicated, yet we are discussing complex ways to approach simple things. Of course the solution is complex, it proposes to be so. One Pitot is all one needs. If it plugs, we heat it. If it has a wasp nest in it, my bad. If it has tape over the hole, also my bad, though I did not install the tape. To fix to an a/c three of the same type of pitot is not only redundancy, it is the raison d'etre for three separate flight computers. Collecting, reconciling and determining are slick computer work, but something has to re-simplify to input the single command that keeps the a/c flying. Of course since flight is dynamic, it is composed of sensing trends, and arresting bad behaviour. It is usually no more difficult than juggling one ball. But Nature being who she is, sometimes it requires the panache to juggle two balls. Then Three, etc.
When navigating in a complex system, it takes time, man or machine.
One can have simple, or one can have complex, but one cannot apparently have both. At least not quickly, also apparently. Something about 447's situation caused the autopilot to quit. No big, hand fly. One does not understand why it is called for to "troubleshoot" the thing that caused the issue. Hand fly. She troubleshot herself, hence ACARS, which have nothing to do with aviating.
It really is that simple. If any argument can be proven that these gents got confused, I'll consider it. If they did, who paid them to do it? Who "trained" them to ?
It is counterintuitive. Laugh if you like, intuition in a professional is money in the bank.
It was NOT the pitots. Something got in between a patent and ho hum gotcha and the pilots. Who let the dogs out?
hello chris. This was a long train on BA038. Redundancy, Reliability, and Reconciliation.
"...All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft...."
************************************************************ *****
Aviation IS "single point". Flying an aircraft is not overly complicated, yet we are discussing complex ways to approach simple things. Of course the solution is complex, it proposes to be so. One Pitot is all one needs. If it plugs, we heat it. If it has a wasp nest in it, my bad. If it has tape over the hole, also my bad, though I did not install the tape. To fix to an a/c three of the same type of pitot is not only redundancy, it is the raison d'etre for three separate flight computers. Collecting, reconciling and determining are slick computer work, but something has to re-simplify to input the single command that keeps the a/c flying. Of course since flight is dynamic, it is composed of sensing trends, and arresting bad behaviour. It is usually no more difficult than juggling one ball. But Nature being who she is, sometimes it requires the panache to juggle two balls. Then Three, etc.
When navigating in a complex system, it takes time, man or machine.
One can have simple, or one can have complex, but one cannot apparently have both. At least not quickly, also apparently. Something about 447's situation caused the autopilot to quit. No big, hand fly. One does not understand why it is called for to "troubleshoot" the thing that caused the issue. Hand fly. She troubleshot herself, hence ACARS, which have nothing to do with aviating.
It really is that simple. If any argument can be proven that these gents got confused, I'll consider it. If they did, who paid them to do it? Who "trained" them to ?
It is counterintuitive. Laugh if you like, intuition in a professional is money in the bank.
It was NOT the pitots. Something got in between a patent and ho hum gotcha and the pilots. Who let the dogs out?
syseng68k;
Respectfully, I disagree.
The point in this accident is NOT the probes.
A loss of airspeed information is not cause for Loss of Control.
A series of ECAM messages and chimes, (expected, with such loss of data), is not a cause for LOC.
A loss of attitude information IS cause for LOC but as far as we know, that did not occur here.
In previous pitot incidents, the exact same ECAM messages occurred. The crews continued to fly and within a few moments/minutes indications returned to normal.
We see such "ECAM streams" of multiple faults/failures in the simulator, during practised dual hydraulic failures for example.
As aircraft systems degrade, they engage in their monitoring/BITE behaviours and, according to their individual timings in sending data to the FWC which in turn are distributed to the CMC, DMUs etc, there will be a cascade of re-prioritizing messages until things settle down. I have seen such streams, many times in the simulator, once, during a serious hydraulic emergency in the air. In such circumstances, one must slow things down, wait and respond deliberately, with "pace", but not hurry.
I have previously observed that the UAS QRH drill memorized items to set the pitch at 15, 10, or 5deg and to set the power to the TOGA detent or in the last two cases, to the CLB detent, are intended for immediate "safe" responses right after takeoff, (catering to the Birgenair and Aeroperu accidents). The qualifying condition is at the end of the memorized items, which states that once the aircraft is above the MSA it should be leveled off for "troubleshooting". Such troubleshooting means getting out the QRH and reading-doing the checklist items. The first items involve appropriate pitch and power settings for weights and altitudes.
Ergo, none of the memorized items in the UAS QRH checklist applied here.
The first response would be to do nothing and touch nothing while the QRH was brought out.
The airplane was stable before the event, and, short of significant disturbance either through heavy turbulence, (thunderstorm entry) or intentional alteration of pitch or, (to a lesser extent) power, the aircraft should remain in a stable state for a reasonable period of time while the P1 hand-flies the aircraft and calls for the UAS drill, and the P2 brings out the QRH.
Contrary to some of the ill-informed statements made here and in the media by those who have never flown, or who have never flown the A330, this airplane hand-flies beautifully at all flight levels and is not a "hand-full", unless, like any airplane, it is near/at the boundaries of flight it was designed for and the crew trained for.
The crew could respond to all the messages, once the ECAM had settled down...it doesn't take long, but the professional airline pilots here I'm sure will say that slowing things down a tad (but not dragging it out), and gathering thoughts before launching, is a key to successfull handling of very complex and serious events. One must get one's surprise and rush of adrenaline under control first, then, as a crew, begin.
Even DP Davies advises "lighting up a pipe", (so to speak!), before rushing into drills. He quite markedly states that the only drill which must be done swiftly, accurately, with discipline and deliberation is the rejected takeoff.
However this unfolds on Friday and in the subsequent months, we must bear in mind first, the families whose loved ones died in this accident and set aside any desire to be "first" or "right" with this or that solution to this accident. The presentation of the actual data will not resolve all questions and, as many have already observed, "the crew" are a part of a very complex, dynamic system in which human factors will inevitably play a part.
The other point, again, is the probes.
. . . .
Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
. . . .
Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
The point in this accident is NOT the probes.
A loss of airspeed information is not cause for Loss of Control.
A series of ECAM messages and chimes, (expected, with such loss of data), is not a cause for LOC.
A loss of attitude information IS cause for LOC but as far as we know, that did not occur here.
In previous pitot incidents, the exact same ECAM messages occurred. The crews continued to fly and within a few moments/minutes indications returned to normal.
We see such "ECAM streams" of multiple faults/failures in the simulator, during practised dual hydraulic failures for example.
As aircraft systems degrade, they engage in their monitoring/BITE behaviours and, according to their individual timings in sending data to the FWC which in turn are distributed to the CMC, DMUs etc, there will be a cascade of re-prioritizing messages until things settle down. I have seen such streams, many times in the simulator, once, during a serious hydraulic emergency in the air. In such circumstances, one must slow things down, wait and respond deliberately, with "pace", but not hurry.
I have previously observed that the UAS QRH drill memorized items to set the pitch at 15, 10, or 5deg and to set the power to the TOGA detent or in the last two cases, to the CLB detent, are intended for immediate "safe" responses right after takeoff, (catering to the Birgenair and Aeroperu accidents). The qualifying condition is at the end of the memorized items, which states that once the aircraft is above the MSA it should be leveled off for "troubleshooting". Such troubleshooting means getting out the QRH and reading-doing the checklist items. The first items involve appropriate pitch and power settings for weights and altitudes.
Ergo, none of the memorized items in the UAS QRH checklist applied here.
The first response would be to do nothing and touch nothing while the QRH was brought out.
The airplane was stable before the event, and, short of significant disturbance either through heavy turbulence, (thunderstorm entry) or intentional alteration of pitch or, (to a lesser extent) power, the aircraft should remain in a stable state for a reasonable period of time while the P1 hand-flies the aircraft and calls for the UAS drill, and the P2 brings out the QRH.
Contrary to some of the ill-informed statements made here and in the media by those who have never flown, or who have never flown the A330, this airplane hand-flies beautifully at all flight levels and is not a "hand-full", unless, like any airplane, it is near/at the boundaries of flight it was designed for and the crew trained for.
The crew could respond to all the messages, once the ECAM had settled down...it doesn't take long, but the professional airline pilots here I'm sure will say that slowing things down a tad (but not dragging it out), and gathering thoughts before launching, is a key to successfull handling of very complex and serious events. One must get one's surprise and rush of adrenaline under control first, then, as a crew, begin.
Even DP Davies advises "lighting up a pipe", (so to speak!), before rushing into drills. He quite markedly states that the only drill which must be done swiftly, accurately, with discipline and deliberation is the rejected takeoff.
However this unfolds on Friday and in the subsequent months, we must bear in mind first, the families whose loved ones died in this accident and set aside any desire to be "first" or "right" with this or that solution to this accident. The presentation of the actual data will not resolve all questions and, as many have already observed, "the crew" are a part of a very complex, dynamic system in which human factors will inevitably play a part.
AoA Works
Snowfalcon2
Some sort of airspeed sensor (as opposed to groundspeed, as provided by GPS and inertial) therefore seems fairly indispensable, at least for critical flight regimes at high altitudes and approach/landing phases where the local wind needs to be considered.
Some sort of airspeed sensor (as opposed to groundspeed, as provided by GPS and inertial) therefore seems fairly indispensable, at least for critical flight regimes at high altitudes and approach/landing phases where the local wind needs to be considered.
Join Date: Jul 2009
Location: spain
Posts: 7
Likes: 0
Received 0 Likes
on
0 Posts
PJ, respectfully, I understand your explanations, acknowledge your type experience, and consider a nose up command as inappropiate at cruise speed /height for an unreliable air speed event , but No single sentence in the AF card posted here restricts its use to a below_MSA or take_off condition!
And pilots DO Train to follow the card or SOP, not our instinct (provided there is a card /SOP )
And pilots DO Train to follow the card or SOP, not our instinct (provided there is a card /SOP )
Last edited by sirgawain123; 24th May 2011 at 19:09.
PJ:
I will defer to your deeper understanding of this flight problem set.
I will offer, as a point related to training, that since airspeed is an imbedded element of an instrument scan, and a critical performance measure in any instrument scan, the unexpected lack of it disrupts the scan. The "don't pay attention to the airpspeed" scan is a non-standard scan, and (IMO, I am biased due to some years of training pilots) should be practiced so that the PF is flying and crosschecking while deliberately ignoring a fundamental scan item ... while the PNF is doing as you illustrate, and handling the trouble shooting.
EDIT: I don't think I need to tell any experienced pilots this, but for those who aren't -- if you don't practice and use your instrument scan habitually, it tends to start off a touch slow when you begin to use it at need. Also, if you don't practice your degraded mode scan, your scan will tend to be slow (initially) when you need to implement that scan pattern. How much time did this crew have to get into that rhythm? Don't know.
This I have seen first hand, not only in my own flying, but also in hundreds of other pilots, when I gave them instrument checks or was being the SOB at the console for a simulator training event intended to "run them through the wringer." This observation applies to both inexperienced and experienced pilots. How quickly the scan, or degraded mode scan, was established, or re-established, varied with the pilot.
I grant you that crews in some other events where AS became unreliable (under other conditions and variables) were able to manage that transition via one means or another. Based on the points you raise, unreliable airspeed wasn't a new failure mode experienced for the first time by AF 447's crew. What it may have been was that rare failure mode, experienced with some novel other conditions, and most likely for the first time by that crew. (This consideration is related to the question I asked to studi about what Conventional Wisdom is and was among the A330 pilot community in re his described escape maneuver ...)
Friday will hopefully be enlightening.
I will defer to your deeper understanding of this flight problem set.
I will offer, as a point related to training, that since airspeed is an imbedded element of an instrument scan, and a critical performance measure in any instrument scan, the unexpected lack of it disrupts the scan. The "don't pay attention to the airpspeed" scan is a non-standard scan, and (IMO, I am biased due to some years of training pilots) should be practiced so that the PF is flying and crosschecking while deliberately ignoring a fundamental scan item ... while the PNF is doing as you illustrate, and handling the trouble shooting.
EDIT: I don't think I need to tell any experienced pilots this, but for those who aren't -- if you don't practice and use your instrument scan habitually, it tends to start off a touch slow when you begin to use it at need. Also, if you don't practice your degraded mode scan, your scan will tend to be slow (initially) when you need to implement that scan pattern. How much time did this crew have to get into that rhythm? Don't know.
This I have seen first hand, not only in my own flying, but also in hundreds of other pilots, when I gave them instrument checks or was being the SOB at the console for a simulator training event intended to "run them through the wringer." This observation applies to both inexperienced and experienced pilots. How quickly the scan, or degraded mode scan, was established, or re-established, varied with the pilot.
I grant you that crews in some other events where AS became unreliable (under other conditions and variables) were able to manage that transition via one means or another. Based on the points you raise, unreliable airspeed wasn't a new failure mode experienced for the first time by AF 447's crew. What it may have been was that rare failure mode, experienced with some novel other conditions, and most likely for the first time by that crew. (This consideration is related to the question I asked to studi about what Conventional Wisdom is and was among the A330 pilot community in re his described escape maneuver ...)
Friday will hopefully be enlightening.
Join Date: Jun 2009
Location: Paris
Posts: 691
Likes: 0
Received 0 Likes
on
0 Posts
Hi areobat,
Certainly. This is the main reason why the BEA should be given all the time necessary to make a complete correlation between all the dataset recorded as, of course, some data could have been erroneously displayed (and recorded). Because all the flight parameters are related to each others, it would be possible to find, beyond any doubt, if anything was wrong with the airspeed before the system started to reject it.
In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures. This is also the main reason why a clean probe system would very very unlikely be clogged (in flight) at exactly the same rate and at exactly the same time.
Originally Posted by areobat
Are there parameters recorded on the FDR that could be used to determine retroactively that something like this occurred?
In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures. This is also the main reason why a clean probe system would very very unlikely be clogged (in flight) at exactly the same rate and at exactly the same time.
Last edited by takata; 24th May 2011 at 19:10.
ChristiaanJ, #2261:
Thanks for that, and for the record, am a bit of a dinosaur here as well :-).
I originally came into embedded work from a hardware, rather than comp sci
background and still do some analog work from time to time. It never
ceases to amaze me what was achieved in the past with mechanical gyros,
servos, synchros and discreet components. Often straddling many disciplines,
the designers of old were masters of their art...
PS : thanks for your post on state machines.... saved it. We never used
that 'notion', but then I'm an analog dinosaur.... Was a good time actually,
until the µP asteroid hit.
that 'notion', but then I'm an analog dinosaur.... Was a good time actually,
until the µP asteroid hit.
I originally came into embedded work from a hardware, rather than comp sci
background and still do some analog work from time to time. It never
ceases to amaze me what was achieved in the past with mechanical gyros,
servos, synchros and discreet components. Often straddling many disciplines,
the designers of old were masters of their art...