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... ]
The 'traditional' method of conducting stalling tests is to establish a computed (I do not mean electronically) stall speed. No further trim movement is then applied once this speed plus xxx kts is achieved TO AVOID EXCESSIVE tail trim which could hamper the recovery. I do not know how you would achieve this on the 'bus, but I assume it is built into the airtest schedule.
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 ]
Agree on all of that, but we are straying into HF and my point is that the choice was not presented clearly to this crew. Regarding altitude, this is outwith this discussion here, since a major upset would have taken place at any altitude.
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...................
