Airbus crash/training flight
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
PBL,
I think BOAC get it very well.
Understand, the voting system is not at stake.
And Please, forget about the 5 sensors, far enough complexity already, simplicity taste much better.
The all issue is that the vote is transparent to the pilots, and this is wrong.
Keep the guys in the loop !
I think BOAC get it very well.
Understand, the voting system is not at stake.
And Please, forget about the 5 sensors, far enough complexity already, simplicity taste much better.
The all issue is that the vote is transparent to the pilots, and this is wrong.
Keep the guys in the loop !
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
CONF iture
As I see it, the simplest method of keeping the pilots in the loop would be a separate algorithim monitoring discrepancies between all AoA sensors on an Error/Time basis. Side slip errors should reasonably be accounted for, and even if you were to get an occasional AoA disagree warning in that situation, you at least get the option of being the judge and jury.
As I see it, the simplest method of keeping the pilots in the loop would be a separate algorithim monitoring discrepancies between all AoA sensors on an Error/Time basis. Side slip errors should reasonably be accounted for, and even if you were to get an occasional AoA disagree warning in that situation, you at least get the option of being the judge and jury.
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
PBL;
Consder a system-level requirement to tolerate ny two faults(which includes Byzantine faults). Such a system requires seven-fold (3m + 1 = 3(2) + 1 = 7) redundancy.
[...]
You reference "5" sensors. In my non-trained view I am slugging through the paper with much more to read/absorb, (and the Lamport paper) so I am needing to understand how the above comments relate, if at all.
Consder a system-level requirement to tolerate ny two faults(which includes Byzantine faults). Such a system requires seven-fold (3m + 1 = 3(2) + 1 = 7) redundancy.
[...]
You reference "5" sensors. In my non-trained view I am slugging through the paper with much more to read/absorb, (and the Lamport paper) so I am needing to understand how the above comments relate, if at all.
The general result is 3m + 1 redundancy to cope with m failures, however Lamport also showed that this could be reduced to 2n + 1 (this is PBLs "5 sensors") for digital systems, if the values are cryptographically signed. That makes it impossible for a faulty processor to corrupt a value and pass it on without the change being detected. Consider the byzantine generals form the analogy communicating by emails with digital signatures - the traitors cannot corrupt what they pass on.
The proof is at the very end of Lamports paper and the discussion is a bit limited (looks like the sort of thing you add into a paper then end up almost cutting back out again in order to get within word/page limits) - there is almost more on it in his comments on the page pointing to the paper.
For what it's worth, my own take on it is that there probably were, and are, people who are aware of and understand these results, at both A and B, and the level of redundancy is designed in knowing its limitations. Triple-redundant design is really only there to cope with a single failure, which in most cases it can. Chance of single failure is then supposed to be made small enough that the chance of uncorrelated double failure is acceptably low.
What bites us then is the correlated / common-mode failures. Same frozen fuel in the pipes to both engines, all static ports taped over, all pitot ports sticking into the same ice etc.
More redundancy doesn't solve these kind of issues.
Going back to the incident under discussion, how much AOA redundancy would you really need to prevent it ? PBL has raised that 5-way at least is needed for two failed (misreporting) sensors, but is that enough ?
My take:
1. the dodgy aircraft washing corrupted 2 out of 3 sensors
2. assume that failure rate carries on across the aircraft, however many sensors we have (reasonable ?)
2. therefore we have to cope with m (lying sensors) = 2/3 * n (total sensors)
3. we also know that n must be >= 2m+1
So we need to solve: n >= 2m +1 where m = 2n/3 (oh, and n > 0)
Good luck with that one.
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
- given the test being conducted, shouldn't the tailplane trim be entirely expected ? Isn't the whole point of the test to reduce the speed so the a/c pitches up to hold altitude (on A or B) right until the envelope protections kick in (A) or stick shaker (B) ?
- or put another way, how would you / could you do this test without the a/c trimming up ?
- and if the trim was expected, surely recovery with that trim would have been planned ? [ assuming you plan for a test failure... ]
Also, I think that from other posts you think the a/c should have flagged "AoA disagree" or similar, at an earlier stage ?
Presumably that's on the basis that you wouldn't test (or would abort test of) AoA protections when faced with reported AoA disagree, right ? ... but then, you wouldn't conduct a lets-see-if-we-can-stall test at 10k less than specified altitude, right ?
[ Note that I'm not at odds with the idea of flagging the disagree, just not sure it would have made any difference here ]
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes
on
0 Posts
Originally posted by infrequentflyer789
.... I'm not at odds with the idea of flagging the disagree, just not sure it would have made any difference here
.... I'm not at odds with the idea of flagging the disagree, just not sure it would have made any difference here
mm43;
Perhaps but I would like to offer a thought: How far does such a regression continue for similar problems and their cockpit indications and the "expected" pilot response, especially in line operations?
The Report already suggests that this "test flight" was not a requirement of any law and was an informal arrangement; the flight was being conducted as a Test Flight but the crew was not familiar with the procedures and didn't adhere to the Airbus test flight requirements.
Some have already said that the Airbus approach is too complicated, that the stream of cautions/warnings when something goes wrong can already overwhelm. As a few have observed, in ordinary line ops, two malfunctioning AoA sensors would not have made a difference to bread-and-butter flight. I agree.
The question about the desirability of doing what they did was raised the moment they reversed their decision to do the Alpha exercise on the way to Germany, and instead elected to do it below 3000ft while on final approach. Nobody among the seven participants raised the question.
Under such decision-making processes, how many dozens/hundreds of other aircraft system abnormal-performance circumstances should be covered before it is enough? What system could be the next "culprit"? Not disagreeing or agreeing with anything suggested but asking the question.
Someone else mentioned pitch problems and trim being the first thing to look at - the motion of the trim wheel in the A320 is easily seen; the wheel is very easy to roll forward or backward and it changes the trim quite quickly. I can't recall if the report addresses this possbility for a potential recovery.
infrequentflyer789;
Thanks for taking a moment to contribute. Perhaps its best to leave it at that unless of course corrections/edits are needed.
CONF iture;
A very important point is being missed here and I disagree with you that the point has been understood...some are not getting it, or if they are, they're saying, "yes, but..." and ignoring the implications of the question.
Without addressing the very issues raised regarding this set of circumstances, how do you propose to "keep the guys in the loop"? What is the "correct" infomation and how is it obtained?
Further, you urge keeping it simple and then ask for more complexity to be loaded onto the pilot. If not this system which it is proposed "has a warning", which next system requires the same, to accomplish the same purpose? How does the designer make that decision and why?
My question to mm43 above applies equally to your suggestion. How much and how far would you decide to "keep the guys in the loop!"; what would be the ECAM actions or aircraft restrictions and upon what would such outcomes of such failure be based?
Given the complexity of such systems as flight controls, engine control and ELAC/SEC/FAC or PRIM performance to name just a few, the same claims (keep the guys informed) could be made for many cases in flight near/at extreme performance limits - a place where no line crew has any business being. What then, are the arguments in this case for increasing complexity of warning presentation, analysis and appropriate response for the crew? At some point downstream, the complexity of training and ensuring high standards of response must be considered. Airbus already hides all Class 3 Maintenance messages, the fault-message inclusion of which I'm sure was an engineering decision based upon a failure mode analysis.
I think that is why the discussion took the turn it did...because it is more relevant than we thought, it isn't that simple and perhaps under line operations perhaps for these reasons, isn't necessary but understanding why, is important.
The goal as you say is to keep it simple. Perhaps this is exactly what is happening.
PJ2
If the AoA sensor disagree had been flagged, then at least the "question" would have been raised about the desirability of doing what they did.
The Report already suggests that this "test flight" was not a requirement of any law and was an informal arrangement; the flight was being conducted as a Test Flight but the crew was not familiar with the procedures and didn't adhere to the Airbus test flight requirements.
Some have already said that the Airbus approach is too complicated, that the stream of cautions/warnings when something goes wrong can already overwhelm. As a few have observed, in ordinary line ops, two malfunctioning AoA sensors would not have made a difference to bread-and-butter flight. I agree.
The question about the desirability of doing what they did was raised the moment they reversed their decision to do the Alpha exercise on the way to Germany, and instead elected to do it below 3000ft while on final approach. Nobody among the seven participants raised the question.
Under such decision-making processes, how many dozens/hundreds of other aircraft system abnormal-performance circumstances should be covered before it is enough? What system could be the next "culprit"? Not disagreeing or agreeing with anything suggested but asking the question.
Someone else mentioned pitch problems and trim being the first thing to look at - the motion of the trim wheel in the A320 is easily seen; the wheel is very easy to roll forward or backward and it changes the trim quite quickly. I can't recall if the report addresses this possbility for a potential recovery.
infrequentflyer789;
Thanks for taking a moment to contribute. Perhaps its best to leave it at that unless of course corrections/edits are needed.
CONF iture;
Keep the guys in the loop !
Without addressing the very issues raised regarding this set of circumstances, how do you propose to "keep the guys in the loop"? What is the "correct" infomation and how is it obtained?
Further, you urge keeping it simple and then ask for more complexity to be loaded onto the pilot. If not this system which it is proposed "has a warning", which next system requires the same, to accomplish the same purpose? How does the designer make that decision and why?
My question to mm43 above applies equally to your suggestion. How much and how far would you decide to "keep the guys in the loop!"; what would be the ECAM actions or aircraft restrictions and upon what would such outcomes of such failure be based?
Given the complexity of such systems as flight controls, engine control and ELAC/SEC/FAC or PRIM performance to name just a few, the same claims (keep the guys informed) could be made for many cases in flight near/at extreme performance limits - a place where no line crew has any business being. What then, are the arguments in this case for increasing complexity of warning presentation, analysis and appropriate response for the crew? At some point downstream, the complexity of training and ensuring high standards of response must be considered. Airbus already hides all Class 3 Maintenance messages, the fault-message inclusion of which I'm sure was an engineering decision based upon a failure mode analysis.
I think that is why the discussion took the turn it did...because it is more relevant than we thought, it isn't that simple and perhaps under line operations perhaps for these reasons, isn't necessary but understanding why, is important.
The goal as you say is to keep it simple. Perhaps this is exactly what is happening.
PJ2
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
infrequentflyer789,
As the test conducted is based on AoA data, I would positively assume NOBODY would carry on, even at 14000 feet, if the system was clearly advising that AoA sensors do not agree.
Page 29 is a good reading regarding your question on the trim.
PJ2,
Thanks for your comment ... I'll have to come back later.
As the test conducted is based on AoA data, I would positively assume NOBODY would carry on, even at 14000 feet, if the system was clearly advising that AoA sensors do not agree.
Page 29 is a good reading regarding your question on the trim.
PJ2,
Thanks for your comment ... I'll have to come back later.
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
An expert system-concept
PBL
Actually there is another more reasonable way to cue the crew (and the flight control computers) that something is amiss.
How did the BEA determine that the two AOA sensors were frozen? Simple-they were not changing after the aircraft reached altitude.
There are a multitude of ways to cross check instrument indications and to alert the crew that something is wrong. In the case of AOA, airspeed vs AOA checks, AOA variation over time, test control inputs, noise in the AOA signal, and no doubt many more checks that I haven't mentioned. In the old days with single indicating systems, a prudent pilot was always questioning what he was being presented.
These same methods can be used to check a whole range of indications for validity. Would AF447 have been lost if there were an expert system monitoring the airspeed indications and noting that all 3 indications appeared to be bonkers just from an energy balance standpoint? Suppose both the computers and aircrew were advised that something was wrong with all three airspeed signals? Would that have made a difference in the outcome? (I know, sheer speculation at this point).
Voting algorithms still have a place for sorting out the best information to use of 3 inputs on modern airliners but are essentially defenseless against common mode failures.
An expert system to monitor the system inputs would not be a part of the core flight control system. If it were, it would slow down the process and make the problems of certification of flight control software an order of magnitude more complicated.
The expert system would be an add-on system which would have to be integrated into the total aircraft system. Its purpose would be to look for anomalous input data using a wide range of screening methods. It would then apply a confidence factor to any critical information being input into the flight control system. If the confidence factor in any critical input was too low, it would not be used for flight control, and the system would degrade as necessary to maintain control.
I do not expect such an expert system to be retrofitted into present aircraft, at least not anytime soon, but I believe such an approach promises a reasonable way around the voting algorithm limitations problem.
Let me, however, tell you what the answer is. You need 5 sensors to detect reliably when two of them are failing-live. That is a hard constraint. And no avionics designer in hisher right mind would seriously try to implement the algorithm that lets you do it with 5.
How did the BEA determine that the two AOA sensors were frozen? Simple-they were not changing after the aircraft reached altitude.
There are a multitude of ways to cross check instrument indications and to alert the crew that something is wrong. In the case of AOA, airspeed vs AOA checks, AOA variation over time, test control inputs, noise in the AOA signal, and no doubt many more checks that I haven't mentioned. In the old days with single indicating systems, a prudent pilot was always questioning what he was being presented.
These same methods can be used to check a whole range of indications for validity. Would AF447 have been lost if there were an expert system monitoring the airspeed indications and noting that all 3 indications appeared to be bonkers just from an energy balance standpoint? Suppose both the computers and aircrew were advised that something was wrong with all three airspeed signals? Would that have made a difference in the outcome? (I know, sheer speculation at this point).
Voting algorithms still have a place for sorting out the best information to use of 3 inputs on modern airliners but are essentially defenseless against common mode failures.
An expert system to monitor the system inputs would not be a part of the core flight control system. If it were, it would slow down the process and make the problems of certification of flight control software an order of magnitude more complicated.
The expert system would be an add-on system which would have to be integrated into the total aircraft system. Its purpose would be to look for anomalous input data using a wide range of screening methods. It would then apply a confidence factor to any critical information being input into the flight control system. If the confidence factor in any critical input was too low, it would not be used for flight control, and the system would degrade as necessary to maintain control.
I do not expect such an expert system to be retrofitted into present aircraft, at least not anytime soon, but I believe such an approach promises a reasonable way around the voting algorithm limitations problem.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
infrequentflyer789 - a quick look only, and I'll come back with more time to your queries, but just to say that I am trying to isolate HF here - there were obviously big issues in that department - but am looking primarily at how crews can/should be notified when a system which is at the heart of the protections built into an aircraft has malfunctioned such that the protections are not there. This purely as a pilot now - my 'engineering days' are well behind me.
Again leaving HF aside, it has been argued that the RadAlt #1 failure on the AMS 737 should have been more readily flagged to the crew - the 'subtle' inference of the failure was not appreciated by many 737 operators. This may, of course, have been addressed by changes in emphasis during training. As said above, we do not know what was or was not 'flagged' to the AF 447 crew.
- I still take my slide rule out of its dusty box occasionally and AMAZE my sons and grandchildren - "you did what?!!!"
Again leaving HF aside, it has been argued that the RadAlt #1 failure on the AMS 737 should have been more readily flagged to the crew - the 'subtle' inference of the failure was not appreciated by many 737 operators. This may, of course, have been addressed by changes in emphasis during training. As said above, we do not know what was or was not 'flagged' to the AF 447 crew.
I am more on the sliderule side of things
Machinbird,
I think there already are expert systems monitoring aircraft "looking for anomalous data using a wide variety of screening methods": the pilots. Like any other system they have limits and in this case they were exceeded. Their 'diagnostic bandwidth' was occupied/unavailable.
It is comparatively easy to take an example like one working and two frozen probes and figure out some logical/procedural way of discounting the false readings, specific to this actual failure mode. What is not easy (or indeed possible in our current understanding, as PBL points out) is to have a process which will always return valid data when 2 out of 3 of the inputs are misbehaving in some way.
The other point is why not have some sort of alert such as "AOA DISAGREE", which has been suggested in this discussion? Given the above, unless you had a forest of probes all over the aircraft, connected to a server farm in the hold, you're going to get that message as soon as there's the slightest difference between any of the sensors. Also, the QRH would probably say something like: "Lack of and/or false stall warnings may be experienced...", amongst other things. Would it have made a difference in this case, as other warnings were disregarded/went unnoticed?
I agree with NoD in that I can't see a pressing need for a change in the aircraft systems in relation to this accident. They performed as per the manual. The crew put themselves in a position where recovery from a manoeuvre was in doubt, by overriding safety limits and being apparently unaware of the secondary effects of what they were attempting, e.g. trim. They did receive a message to check the weight, which should have led them to question some of the speeds displayed but this was ignored due overload.
This is a very interesting accident from the HF POV, where there was a "crew" made of 1 FO & 2 captains who, under what appears to be considerable commercial and time pressure, elected to follow a path which ultimately led them to disaster. A lot to learn, here.
I think there already are expert systems monitoring aircraft "looking for anomalous data using a wide variety of screening methods": the pilots. Like any other system they have limits and in this case they were exceeded. Their 'diagnostic bandwidth' was occupied/unavailable.
It is comparatively easy to take an example like one working and two frozen probes and figure out some logical/procedural way of discounting the false readings, specific to this actual failure mode. What is not easy (or indeed possible in our current understanding, as PBL points out) is to have a process which will always return valid data when 2 out of 3 of the inputs are misbehaving in some way.
The other point is why not have some sort of alert such as "AOA DISAGREE", which has been suggested in this discussion? Given the above, unless you had a forest of probes all over the aircraft, connected to a server farm in the hold, you're going to get that message as soon as there's the slightest difference between any of the sensors. Also, the QRH would probably say something like: "Lack of and/or false stall warnings may be experienced...", amongst other things. Would it have made a difference in this case, as other warnings were disregarded/went unnoticed?
I agree with NoD in that I can't see a pressing need for a change in the aircraft systems in relation to this accident. They performed as per the manual. The crew put themselves in a position where recovery from a manoeuvre was in doubt, by overriding safety limits and being apparently unaware of the secondary effects of what they were attempting, e.g. trim. They did receive a message to check the weight, which should have led them to question some of the speeds displayed but this was ignored due overload.
This is a very interesting accident from the HF POV, where there was a "crew" made of 1 FO & 2 captains who, under what appears to be considerable commercial and time pressure, elected to follow a path which ultimately led them to disaster. A lot to learn, here.
Last edited by FullWings; 21st Sep 2010 at 08:03. Reason: speling
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by infrequentflyer789
- given the test being conducted, shouldn't the tailplane trim be entirely expected ? Isn't the whole point of the test to reduce the speed so the a/c pitches up to hold altitude (on A or B) right until the envelope protections kick in (A) or stick shaker (B) ?
- or put another way, how would you / could you do this test without the a/c trimming up ?
- and if the trim was expected, surely recovery with that trim would have been planned ? [ assuming you plan for a test failure... ]
- or put another way, how would you / could you do this test without the a/c trimming up ?
- and if the trim was expected, surely recovery with that trim would have been planned ? [ assuming you plan for a test failure... ]
Originally Posted by infrequentflyer789
Also, I think that from other posts you think the a/c should have flagged "AoA disagree" or similar, at an earlier stage ?
Presumably that's on the basis that you wouldn't test (or would abort test of) AoA protections when faced with reported AoA disagree, right ? ... but then, you wouldn't conduct a lets-see-if-we-can-stall test at 10k less than specified altitude, right ?
[ Note that I'm not at odds with the idea of flagging the disagree, just not sure it would have made any difference here ]
Presumably that's on the basis that you wouldn't test (or would abort test of) AoA protections when faced with reported AoA disagree, right ? ... but then, you wouldn't conduct a lets-see-if-we-can-stall test at 10k less than specified altitude, right ?
[ Note that I'm not at odds with the idea of flagging the disagree, just not sure it would have made any difference here ]
Fullwings - I think machinbird had all your points covered?
'Actually there is another more reasonable way to cue the crew (and the flight control computers) that something is amiss' - the point is that the evidence was staring the FCC/ADIRUs in the face - they just 'didn't really' make an issue of it.
'a process which will always return valid data' - not demanded?
'An expert system to monitor the system inputs would not be a part of the core flight control system. If it were, it would slow down the process and make the problems of certification of flight control software an order of magnitude more complicated' - an acknowledgement that we are way off this target. MB's 'expert system' is acknowledged to be way in the future.
'In the old days with single indicating systems, a prudent pilot....' - I have several instances in my flying career where this happened, and my multi-function algorithms rejected the suspicious data. We have way to go to get software as intelligent as the human mind (E&OE excepted, of course). Take away the perceived need for intelligent analysis because 'this system is perfect and will look after you' and the walls (and aircraft) can come tumbling down. Oh dear - I'm into HF...................
... I still take my slide rule out of its dusty box occasionally and AMAZE my sons and grandchildren - "you did what?!!!"
Slide Rule ?? there's posh for you. Once had a Flt. Eng. who sat there in flight completing his log with a Chinese Abacus.
Knew how to use it, too.
( sorry, thought it was about time for a short break )
Join Date: Sep 2010
Location: Double Oak, Texas
Age: 71
Posts: 180
Likes: 0
Received 0 Likes
on
0 Posts
Howdy all. So much emotion in the thread and induced in me by this accident , and most especially the comments about AA965 Cali crash of 1995, a tragedy I am very familiar with.
Where to start in my first post here.
What a complete shame the waste of lives aboard the doomed flight and the sorrowful impact on the lives of those related to the crash victims, as well as colleagues of the flight crew.
Have waded thru many fatal crashes/investigations since I began flying way back in 1968 at age 15 in PA-28's to retirement just over 2 years ago from the left seat of the B777.
Having read thru the entire thread and most of the official reports, I suppose as good a place as any to start would be the last interactions with ATC the crew had. I have read some potshots taken at ATC in some of the posts and the perceived lack of cooperation of ATC with the requests by the crew in flight. No need to rehash the option the crew had of properly filing the type of flight plan they perhaps may have intended to apparently haphazardly attempt.
So I start with....
I don't recall reading any comments about the Captain's outlandish (IMO) behavior and outright disregard of the direct request/instruction/directive of ATC regarding speed assignment during their descent....
At 15 h 33 min 34, descending to FL 130, the crew contacted Perpignan
Approach. They were cleared to descend to FL 120 towards the PPG VOR. The
approach controller asked them to reduce speed to 250 kt and to plan a hold at the PPG VOR. They were number two on approach. One minute later, the crew requested radar vectoring. The approach controller asked them to turn left on heading 090 and reduce speed to 200 kt.
The controller instructs an additional reduction of 50 knots in about a minute, suggesting to meshe may be getting a little pressed somewhere for traffic separation for whatever reason.
Then about 5 minutes later....
"At around 15 h 39 min, the approach controller asked the crew to descend towards flight
level 60. The airplane was then slightly below flight level 100 and its speed was 215 kt."
So far, nearly 6 minutes to reduce speed to 215 knots?? I know, whats the rush, let that controller fly his desk and radar, us pilots, we got the responsibility and the heavy metal.....
Note that: " At 15 h 36 min 47 s, the airplane was level at FL120."
Is the A320 so slippery that even at say VNE and level at FL120 it would be a task to slow to 200kts in a little over 2 minutes?
At around 15 h 39 min, the approach controller asked the crew to descend towards flight
level 60. The airplane was then slightly below flight level 100 and its speed was 215 kt.
At around 15 h 40 min, the approach controller asked the crew to turn to the right on heading
190 and to maintain 180 kt. The Captain made a right turn. The airplane speed was 215 kt.
What I am seeing here is a pilot who just is not going to cooperate and fly ATC IFR directed speed. As in, "Don't bother me, I have more important stuff to do than help YOU (controller) with your separation duties". I seem to recall that the rules give a pilot plus or minus 10kts from assigned speed, maybe my memory is faulty.
So the intrepid pilot TRE! and crew continue...
"The aeroplane reached 5,000 ft altitude at 15 h 42. Its speed was then around 210 kt".
At 15 h 42 min 14, the approach controller asked for the aeroplane’s speed.
The Co-pilot answered initially that it was falling, then at 15 h 42 min 25 said
that it was 180 kt. The aeroplane speed was then slightly above 190 kt and the selected speed went from 180 kt to 157 kt. The approach controller asked them to maintain 180 kt and to descend to 2,000 ft.
They then did their fateful controlled deceleration to about one half of the assigned 180 knots w/o even the slightest consideration of informing the controller, after all she might have been just another "empty kitchen". I don't suggest that was the Captain's opinion of said controller. But his "who cares" attitude of slowing to requested speeds, then halving his assigned speed well outside the IAF w/o communication with ATC.... did he know that there was no IFR aircraft behind him that might be affected by his speed reduction? Any disregard for rules and common sense/courtesy beginning to be displayed here??
Won't begin to address the unbelievable flight situation he then quite voluntarily and seemingly non-chalantly dived headlong into; in an aircraft he was supposedly immenently knowledgable of and skilled in flying from A to B in all weather, day or night and surely well aware of the many dizzyingly frenetic flight law changes he was about to encounter which would snuff his and 6 other lives and affect so many more.
Where to start in my first post here.
What a complete shame the waste of lives aboard the doomed flight and the sorrowful impact on the lives of those related to the crash victims, as well as colleagues of the flight crew.
Have waded thru many fatal crashes/investigations since I began flying way back in 1968 at age 15 in PA-28's to retirement just over 2 years ago from the left seat of the B777.
Having read thru the entire thread and most of the official reports, I suppose as good a place as any to start would be the last interactions with ATC the crew had. I have read some potshots taken at ATC in some of the posts and the perceived lack of cooperation of ATC with the requests by the crew in flight. No need to rehash the option the crew had of properly filing the type of flight plan they perhaps may have intended to apparently haphazardly attempt.
So I start with....
I don't recall reading any comments about the Captain's outlandish (IMO) behavior and outright disregard of the direct request/instruction/directive of ATC regarding speed assignment during their descent....
At 15 h 33 min 34, descending to FL 130, the crew contacted Perpignan
Approach. They were cleared to descend to FL 120 towards the PPG VOR. The
approach controller asked them to reduce speed to 250 kt and to plan a hold at the PPG VOR. They were number two on approach. One minute later, the crew requested radar vectoring. The approach controller asked them to turn left on heading 090 and reduce speed to 200 kt.
The controller instructs an additional reduction of 50 knots in about a minute, suggesting to meshe may be getting a little pressed somewhere for traffic separation for whatever reason.
Then about 5 minutes later....
"At around 15 h 39 min, the approach controller asked the crew to descend towards flight
level 60. The airplane was then slightly below flight level 100 and its speed was 215 kt."
So far, nearly 6 minutes to reduce speed to 215 knots?? I know, whats the rush, let that controller fly his desk and radar, us pilots, we got the responsibility and the heavy metal.....
Note that: " At 15 h 36 min 47 s, the airplane was level at FL120."
Is the A320 so slippery that even at say VNE and level at FL120 it would be a task to slow to 200kts in a little over 2 minutes?
At around 15 h 39 min, the approach controller asked the crew to descend towards flight
level 60. The airplane was then slightly below flight level 100 and its speed was 215 kt.
At around 15 h 40 min, the approach controller asked the crew to turn to the right on heading
190 and to maintain 180 kt. The Captain made a right turn. The airplane speed was 215 kt.
What I am seeing here is a pilot who just is not going to cooperate and fly ATC IFR directed speed. As in, "Don't bother me, I have more important stuff to do than help YOU (controller) with your separation duties". I seem to recall that the rules give a pilot plus or minus 10kts from assigned speed, maybe my memory is faulty.
So the intrepid pilot TRE! and crew continue...
"The aeroplane reached 5,000 ft altitude at 15 h 42. Its speed was then around 210 kt".
At 15 h 42 min 14, the approach controller asked for the aeroplane’s speed.
The Co-pilot answered initially that it was falling, then at 15 h 42 min 25 said
that it was 180 kt. The aeroplane speed was then slightly above 190 kt and the selected speed went from 180 kt to 157 kt. The approach controller asked them to maintain 180 kt and to descend to 2,000 ft.
They then did their fateful controlled deceleration to about one half of the assigned 180 knots w/o even the slightest consideration of informing the controller, after all she might have been just another "empty kitchen". I don't suggest that was the Captain's opinion of said controller. But his "who cares" attitude of slowing to requested speeds, then halving his assigned speed well outside the IAF w/o communication with ATC.... did he know that there was no IFR aircraft behind him that might be affected by his speed reduction? Any disregard for rules and common sense/courtesy beginning to be displayed here??
Won't begin to address the unbelievable flight situation he then quite voluntarily and seemingly non-chalantly dived headlong into; in an aircraft he was supposedly immenently knowledgable of and skilled in flying from A to B in all weather, day or night and surely well aware of the many dizzyingly frenetic flight law changes he was about to encounter which would snuff his and 6 other lives and affect so many more.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
PJ2,
I did? Deary me! Not any more.
Somehow I was thinking (3 x n) +1 = 5 when n =2. Maybe it was when I wrote it, but it's not any longer. It's 7, as Kevin said.
It makes the point stronger.
infrequentflyer789 saw how to rescue me (very gracious!) but truth is it was a cognitive slip. Yes, Leslie points out that you can use digital signatures to reduce the number, but no one trying to build Byzantine-failure-tolerant devices is trying to do that.
The issue being batted around here is more or less as follows. Trying to be completely fault-tolerant (of Byzantine faults as well as others) is currently not on. There are a couple of busses which are being designed to tolerate special classes of Byzantine faults, but they are at the research level. So the question is: what kinds of fault can be tolerated using existing methods?
And here the danger is that one collects a list of phenomena, and says: we can tolerate this one like this, and this on like this, and ....... and here are two AoA sensors which are frozen, and we can tolerate this situation like this, and ..... and one ends up with a list without rhyme or much reason. It is possible to do each one after the other. But one is continually shutting the door after the horse has bolted, and the next door will not be where they have already been shut. That is no way to design fault-detecting or fault-tolerant systems.
What is needed is a description of a class of phenomena and how they are to be tolerated. Or many classes, and their mitigations. And I don't see that yet arising out of this discussion.
PBL
Originally Posted by PJ2
You reference "5" sensors
Somehow I was thinking (3 x n) +1 = 5 when n =2. Maybe it was when I wrote it, but it's not any longer. It's 7, as Kevin said.
It makes the point stronger.
infrequentflyer789 saw how to rescue me (very gracious!) but truth is it was a cognitive slip. Yes, Leslie points out that you can use digital signatures to reduce the number, but no one trying to build Byzantine-failure-tolerant devices is trying to do that.
The issue being batted around here is more or less as follows. Trying to be completely fault-tolerant (of Byzantine faults as well as others) is currently not on. There are a couple of busses which are being designed to tolerate special classes of Byzantine faults, but they are at the research level. So the question is: what kinds of fault can be tolerated using existing methods?
And here the danger is that one collects a list of phenomena, and says: we can tolerate this one like this, and this on like this, and ....... and here are two AoA sensors which are frozen, and we can tolerate this situation like this, and ..... and one ends up with a list without rhyme or much reason. It is possible to do each one after the other. But one is continually shutting the door after the horse has bolted, and the next door will not be where they have already been shut. That is no way to design fault-detecting or fault-tolerant systems.
What is needed is a description of a class of phenomena and how they are to be tolerated. Or many classes, and their mitigations. And I don't see that yet arising out of this discussion.
PBL
Last edited by PBL; 21st Sep 2010 at 12:15.
the High AoA protections did/do not function with a single AoA input, but the stall warning does? I cannot understand the logic.
Further, I think it would probably help some readers a lot to read PBL's posts replacing the word "algorithm" with "rule".
For example, if you decided to treat no change as evidence of failure, how would that work in the cruise with a sensor that fails in such a way as to start producing random readings, or to diverge from the facts steadily? Such a rule would be defeated by what might be the most likely non-obvious failure case (a/c in the cruise and therefore maintaining a steady AoA, one or two units fail actively). Obviously there'd be some change, but even a functioning-but-frozen unit would be expected to have a noise term.
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,454
Likes: 0
Received 0 Likes
on
0 Posts
It seems that PBL has already posted an objection to the "Expert Computer" concept. I guess I'm reading too slowly to keep up with all the twists and turns.
The key to the expert system is a cross checking of data types, not just comparing identical data types. Much better resistance to common mode failures this way.
Quote:
Originally Posted by atakacs
... is there some "über"computer checking in real time that all sensor readings are within reasonable value respective to each other, and provide a clear ECAM message if not ?
So in response to this objection, let me propose an architecture that perhaps makes sense.
Two computers-physically separated in the aircraft, reading the identical inputs and performing identical calculations on the data using the "expert knowledge base". Any discrepancy in outputs causes the system to disconnect from the system and advise the crew. Result-reversion back to basic Airbus that everyone is familiar with. How the information is presented to the aircrew is important to avoid over-reaction/under-reaction. This will require significant development work, but should result in usable advisories to the crew.
FullWings
In the old days, you had one altimeter and one airspeed to look at. Today when you look at these indications in a modern aircraft, you are looking at a computer selected presentation of multiple identical sensors as chosen by the computers. If the crew's "diagnostic bandwidth" was exceeded (which probably isn't too hard in today's complex aircraft), it is an indication that they could have used some help.
Supposing an expert system noted that there was a discrepancy between gross weight and AOA or between airspeed and AOA. First it could observe the output of the 3 AOA sensors and note that two of them didn't make sense in the context of airspeed and gross weight. Next it could observe the output of the sensors for a change in output and if the same two sensors that seemed aberrant before showed no change, it could advise the crew of a possible AOA malfunction involving two sensors and request a small test maneuver. If still no response by the two affected sensors to the test maneuver, then they would be locked out of the control system and the crew would either be advised or would authorize the lockout. Result-the one remaining good AOA sensor is used for all AOA inputs. There is no reason that similar procedures could not be applied to all sensor data.
The key to the expert system is a cross checking of data types, not just comparing identical data types. Much better resistance to common mode failures this way.
Quote:
Originally Posted by atakacs
... is there some "über"computer checking in real time that all sensor readings are within reasonable value respective to each other, and provide a clear ECAM message if not ?
No, there isn't. The general opinion of such things is that it wouldn't do much good, and maybe quite a lot of harm.
First, think what would happen if it failed.
Then, how it can fail. You might think of building in redundancy, but in fact one Byzantine fault can take out arbitrary levels of redundancy, as shown in one shuttle attempted flight (scrubbed during launch) when the entire 4-processor FCC partitioned itself inside seconds into 3-1, then 2-1-1, then 1-1-1-1 (info, and the observation of consequences for redundant architectures, courtesy of Kevin Driscoll).
PBL
First, think what would happen if it failed.
Then, how it can fail. You might think of building in redundancy, but in fact one Byzantine fault can take out arbitrary levels of redundancy, as shown in one shuttle attempted flight (scrubbed during launch) when the entire 4-processor FCC partitioned itself inside seconds into 3-1, then 2-1-1, then 1-1-1-1 (info, and the observation of consequences for redundant architectures, courtesy of Kevin Driscoll).
PBL
Two computers-physically separated in the aircraft, reading the identical inputs and performing identical calculations on the data using the "expert knowledge base". Any discrepancy in outputs causes the system to disconnect from the system and advise the crew. Result-reversion back to basic Airbus that everyone is familiar with. How the information is presented to the aircrew is important to avoid over-reaction/under-reaction. This will require significant development work, but should result in usable advisories to the crew.
FullWings
I think there already are expert systems monitoring aircraft "looking for anomalous data using a wide variety of screening methods": the pilots. Like any other system they have limits and in this case they were exceeded. Their 'diagnostic bandwidth' was occupied/unavailable.
It is comparatively easy to take an example like one working and two frozen probes and figure out some logical/procedural way of discounting the false readings, specific to this actual failure mode. What is not easy (or indeed possible in our current understanding, as PBL points out) is to have a process which will always return valid data when 2 out of 3 of the inputs are misbehaving in some way.
It is comparatively easy to take an example like one working and two frozen probes and figure out some logical/procedural way of discounting the false readings, specific to this actual failure mode. What is not easy (or indeed possible in our current understanding, as PBL points out) is to have a process which will always return valid data when 2 out of 3 of the inputs are misbehaving in some way.
Supposing an expert system noted that there was a discrepancy between gross weight and AOA or between airspeed and AOA. First it could observe the output of the 3 AOA sensors and note that two of them didn't make sense in the context of airspeed and gross weight. Next it could observe the output of the sensors for a change in output and if the same two sensors that seemed aberrant before showed no change, it could advise the crew of a possible AOA malfunction involving two sensors and request a small test maneuver. If still no response by the two affected sensors to the test maneuver, then they would be locked out of the control system and the crew would either be advised or would authorize the lockout. Result-the one remaining good AOA sensor is used for all AOA inputs. There is no reason that similar procedures could not be applied to all sensor data.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by FullWings
They did receive a message to check the weight
Also, Appendix 18 mentions that such message would not ensure that line pilots will become aware of the fact the lower indicated airspeed limits are inaccurate.
What was needed is a clear AOA DISAGREE ECAM MESSAGE and there is absolutely no complexity to be added for such message to be triggered as the system has already been through the necessary analyze to SILENTLY unvote one ADR.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by CONF iture
What was needed is a clear AOA DISAGREE ECAM MESSAGE and there is absolutely no complexity to be added for such message to be triggered as the system has already been through the necessary analyze to SILENTLY unvote one ADR.
The system 'knows' that the AoA of the 2 sensors is incorrect v IAS and weight. Supposedly it asks the crew to 'check the GW'. Maybe it does, maybe it doesn't; maybe they do, maybe they don't. With a Gallic shrug the system now ignores this anomaly and also 'ignores' the fact that 1 sensor is well past the point at which 'protection' would normally have been triggered. What does it do? NOTHING. Not a peep. Aviation has in all my time worked on the assumption that given 'choices', it should be the safest option that should be chosen. Not by AB. "We will ignore this fact". "2 outvotes 1 and that is that". As far as 'protection' is concerned, we effectively have here a torn condom (French letter?).
OK - we all accept this is an 'oddball' occurrence, unlikely to re-occur in normal operations. BUT the thing that bothers me as a potential AB passenger, and should be worrying the AB crews, is how many other 'protection' software systems use the same policy? Let's seriously hope they find AF447.
PBL;
Thanks for your response. I wasn't at a point of understanding so as to know whether it was "5" or "7" (or "21") and naively asked the question using Kevin's work. The important point is made, which is, it isn't possible to resolve this failure without the quality of thought and perception understood as "discernability"...a computer cannot "discern/decide" as such activity is not an algorithm. I am not familiar with the technical terms which might be used to describe this but one might view this quality as a "gestalt"....computers cannot "gestalt", they can only do zeroes and ones at extremely high speeds without anticipatory or recollective powers of perception. For me that's one way of putting it - I'm sure there are others.
So, (to Machinbird's point), one altimeter, one airspeed indicator, etc etc "worked" because discernability/decideability was not a problem; the pilot decided, (for better or worse). I'm not sure the problem highlighted is so much a "bandwidth" problem as a discerning/decideability problem. I think this is true because, as others have said (and I agree), the failure of two AoA sensors would be a non-issue for a line crew, (and this may indeed have been the thought process behind not including such failures in warnings to the crew...who knows?). In these specific circumstances, a line-crew would have all the necessary indications for successfully completing the flight.
I wonder what the ACARS maintenance messages were, if any, regarding the AoA's? Notwithstanding the low risk to normal flight, surely two u/s AoA sensors would be NO-GO.
PJ2
Thanks for your response. I wasn't at a point of understanding so as to know whether it was "5" or "7" (or "21") and naively asked the question using Kevin's work. The important point is made, which is, it isn't possible to resolve this failure without the quality of thought and perception understood as "discernability"...a computer cannot "discern/decide" as such activity is not an algorithm. I am not familiar with the technical terms which might be used to describe this but one might view this quality as a "gestalt"....computers cannot "gestalt", they can only do zeroes and ones at extremely high speeds without anticipatory or recollective powers of perception. For me that's one way of putting it - I'm sure there are others.
So, (to Machinbird's point), one altimeter, one airspeed indicator, etc etc "worked" because discernability/decideability was not a problem; the pilot decided, (for better or worse). I'm not sure the problem highlighted is so much a "bandwidth" problem as a discerning/decideability problem. I think this is true because, as others have said (and I agree), the failure of two AoA sensors would be a non-issue for a line crew, (and this may indeed have been the thought process behind not including such failures in warnings to the crew...who knows?). In these specific circumstances, a line-crew would have all the necessary indications for successfully completing the flight.
I wonder what the ACARS maintenance messages were, if any, regarding the AoA's? Notwithstanding the low risk to normal flight, surely two u/s AoA sensors would be NO-GO.
PJ2