My limited understanding is that it is NOT a typical stall recovery system such as a stick pusher. (never flown 737)
The NG model used an automatic trim system, to modify the trim automatically so that it could meet certain certification requirements, at slow speeds that relate to speed stability. i.e. how quickly it would return to “trimmed” speed.
This system was extended because the MAX could not meet the part 25 stall certification requirements without the stabiliser being moved down. i.e. if the stabiliser remains at “higher” positions and the pilot only uses forward elevator control, the certification requirements could not be met. With this automated system the pilot can use normal control input, e.g. push the stick forward and the stall certification requirements can be met. (a stick pusher on it own in all cases would not work to meet the certification requirements)
I think is gets further complicated as they removed one of the ways the system can be disabled. (the trim brake when the control column is pulled/pushed)
Well some Bpeing pilots may know those systems better than others who were told “just fly it as you did in your previous 1000h”, you need to be close to the engineers to get a better picture, besides the certification issue, I wonder how difficult to fly the typical manoeuvres with MCAS disabled? Asymmetric activation in climb/decent?
If that is very easy then you only need to notice/recognize MCAS bug, disable it and fly
If that is tough, then good luck learning how to really fly the 737Max for the first time like test pilots in the heat of the moment…
Ibra wrote:
with MCAS disabled
You can deactivate the MCAS system only by setting flaps or by engaging the AP. The switches disable the electric trim alltogether, but not selectively the MCAS.
a_kraut wrote:
You can deactivate the MCAS system only by setting flaps or by engaging the AP. The switches disable the electric trim alltogether, but not selectively the MCAS.
How does the autopilot cope with a faulty AoA sensor?
Dimme wrote:
How does the autopilot cope with a faulty AoA sensor?
It does not make sense for the autopilot to use the system. The autopilot just needs to command trim and elevator to the correct position as required. i.e. if autopilot wants a high angle of attack it would both adjust the stabiliser and elevator as appropriate. (keeping in mind the A/P will have limits as well). In manual flight at high AoA the MCAS will trim nose down, so that if the pilot wants to maintain a high AoA he will need more elevator.
Yet at the same time it is obviously not quite that simple…
Well to me at the core of it is a design philosophy: building complicated automatic systems just to show safety & stability on the narrow scope of certification tests under the commands of “expert pilots” is never a good idea, the thing will be flown outside those scenarios by “amateur pilots”…
You do will always get away with this “reverse engineering” most of the time without having to disclose anything, it is part of the game/rule, but only when the solution you propose is “simple” and “trivial” for everybody to come up with and understand ;)
Ted wrote:
if autopilot wants a high angle of attack it would both adjust the stabiliser and elevator as appropriate.
But if the AoA sensor is faulty then how does the autopilot know it has achieved the desired angle of attack? What I’m trying to figure out is if a faulty AoA sensor (in a system with 2 sensors) would disengage the autopilot since the computer does not know which of the 2 sensors to rely on.
It does not make sense for the autopilot to use the system
I don’t think it does. Enabling the autopilot disconnects the MCAS software, anyway.
The 737 AP is going to have stall protection, via airspeed and AoA sensing, just like an Airbus has. AIUI, the Airbus implementation allows operation closer to the onset of stall, so an Airbus will climb a little bit faster than a Boeing with same weight, thrust, etc.
So I think that if MCAS is implicated in these two accidents (and I have not seen anything saying either way) then either
But if the AoA sensor is faulty then how does the autopilot know it has achieved the desired angle of attack? What I’m trying to figure out is if a faulty AoA sensor (in a system with 2 sensors) would disengage the autopilot since the computer does not know which of the 2 sensors to rely on.
Are the AoA sensors shared between the two systems?
The 2 out of 3 method is problematic and requires complex solutions. For example you have to get different teams to write different bits in different languages, otherwise you just waste your time when both end up with the same bug in some library. Also programmers tend to make the same mistakes. This is one reason why an Airbus has the reversion modes, all the way to a total loss of ailerons and just using the (hydraulically coupled) rudder to control roll (as explained to me by one Airbus pilot).
But if the AoA sensor is faulty then how does the autopilot know it has achieved the desired angle of attack? What I’m trying to figure out is if a faulty AoA sensor (in a system with 2 sensors) would disengage the autopilot since the computer does not know which of the 2 sensors to rely on.
I don’t think it needs to, AFAIK it flies the aircraft much like the pilot would using pitch, with or without thrust control to get the desired performance. However the AoA sensor might be used as inputs to limit the pitch or as you speculate to disengage the autopilot, this would then engage MCAS…
It seems that detail for this sort of subtle interactions have not been provided to the pilots…
Peter wrote:
Are the AoA sensors shared between the two systems?
That is going to be a difficult question, if the computer has good reasons to disengage the AP and revert control to you for manual flying then the MCAS should be disabled IMO, irrespective of sensors architecture, reliability and fail-safe
Otherwise you will end up having to run a 12 out of 18 voting systems, 2*(2 out of 3) out of 3*(2 out of 3) to get to the bottom of it….
