Ethiopian airliner down in Africa
It occurs to me that the usual scenario for a runaway stabilizer is that pilot has just commanded a trim change and a failure caused the stab to continue to the limit of its travel. Does that not give the pilot a clue that the problem he's experiencing might be connected to his action of changing the trim? He's been trained for that possibility and presumably has practiced the procedure of cutting the switches. Without knowledge of MCAS and the possibility that something external to the pilot might command the stabilizer to move, how in the world would he recognize what's happening and what to do?
MCAS does not operate when in autopilot - it is intended solely for manual flying to ensure that the reduction in backpressure on the control column when in high AOA does not lead a pilot to inadvertently pull back into a stall. So the article you quote is not looking at the MCAS issue at all as the problem only occurred on engaging autopilot. It is probably looking at ASRS reports from crews that in some way mis-set the autopilot causing it to attempt to fly to where the crew had set it to fly. It is most definitely not MCAS..
MCAS being 'live' when it should not have been remains a plausible explanation. It ticks all the boxes for a latent failure - no direct indication to the crew, no failure modes displayed, no routine interaction with other systems, no BITE or similar and does not drive the stab at any point during a normal sortie. As long as it thinks the AoA is ok it does nothing.
Time will tell if functions like trim cutout, AP cutout, configuration cutout etc actually work. Given that the system seems to be blissfully unaware of the actual flight dynamics beyond simple unmonitored raw sensor data and will willingly fly the aircraft into the ground, I remain reluctant to accept the claimed operating envelope as gospel.
I guess I have spent too many years flight testing aircraft and my level of 'trust' has been swamped by 'verify'. As an aside, flight testing has become inconvenient in the last 15 years or so. We get more facetime and interaction these days post-crash - everyone is 'all ears' at that point. We need to get flight testing and training verified before an aircraft is released to the line. Kicking over aluminium at an accident site is just too late.
Gender Faculty Specialist
Yep, used to do engineering check flights. Part of that was manual reversion. It was a requirement to use manual trim because you had to count the number of turns.
Gender Faculty Specialist
Look back a few pages. With duff alpha you're likely to get up to 9 other warnings/indications not including the Southwest option.
Join Date: Jan 2008
Location: US
Posts: 7
Likes: 0
Received 0 Likes
on
0 Posts
Which to me seems a huge issue. Before this second incident (assuming they're related) Boeing was downplaying the issue, basically trying to put lipstick on the pig. The second instance of this problem, in short order, shows that more is required than what was likely the lowest cost, most expedient fix Boeing could come up with. The assumption that Boeing made previously that pilots should be able to safely deal with another instance of this problem (hence justifying that grounding the fleet wasn't necessary, even after the second crash) proved to be sadly wrong and hence I conclude that the fix that Boeing had conceived before the second instance must also be flawed since it was based on their same myoptic attitude. To implement the 'fix' conceived of before this second incident within the next 10 days seems untenable. Unfortunately Boeing is motivated by $ to get any fix out there asap whether its a real fix or not. Today when news was leaked that the fix would be ready in 10 days (by Boeing?), the Boeing stock bumped 1.5%. If they had announced the fix would take another 5 months then likely the opposite would have happened or much worse. Hopefully, common sense will prevail and the required fix/action will be fully re-evaluated. I'm considering shorting Boeing stock but that would assume common sense will prevail.
Join Date: Feb 2011
Location: Leeds
Posts: 1
Likes: 0
Received 0 Likes
on
0 Posts
Guys, think people need to ease of the aircraft a little as if its got some huge design defect especially until we have some more facts, bear in mind many operators have been using this type for a fair while southwest nearly 3 years, with no such issues, also bear in mind that both operators here that have managed to "fly it into the ground" have very questionalble safety records as an operator.
Join Date: Nov 2006
Location: Dallas
Posts: 455
Likes: 0
Received 0 Likes
on
0 Posts
Guys, think people need to ease of the aircraft a little as if its got some huge design defect especially until we have some more facts, bear in mind many operators have been using this type for a fair while southwest nearly 3 years, with no such issues, also bear in mind that both operators here that have managed to "fly it into the ground" have very questionalble safety records as an operator.
Hoke
How many turns does it take to go from max down to say a neutral position? Given they they were never that high from the ground , How long would it take them to trim from max down to something that would save the flight? What am trying to say is OK we have a trim problem disable trim motor via cut out switches.. Turn the manual trim wheel . Would they have the time to do this if the are only approximately 1000ft above ground?
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
I keep reading such explanations but to be clear, MCAS is always powered on. When and where it functions is defined by software alone. As such this is safety critical software and should meet the highest assurance levels. The designer did not wish for the aircraft to crash and may have set all the protection methods they could think of as a credible design goals. We have yet to learn if MCAS, as implemented, did respect the AP selection, flap configuration or anything else the designer had in mind.
MCAS being 'live' when it should not have been remains a plausible explanation. It ticks all the boxes for a latent failure - no direct indication to the crew, no failure modes displayed, no routine interaction with other systems, no BITE or similar and does not drive the stab at any point during a normal sortie. As long as it thinks the AoA is ok it does nothing.
Time will tell if functions like trim cutout, AP cutout, configuration cutout etc actually work. Given that the system seems to be blissfully unaware of the actual flight dynamics beyond simple unmonitored raw sensor data and will willingly fly the aircraft into the ground, I remain reluctant to accept the claimed operating envelope as gospel.
I guess I have spent too many years flight testing aircraft and my level of 'trust' has been swamped by 'verify'. As an aside, flight testing has become inconvenient in the last 15 years or so. We get more facetime and interaction these days post-crash - everyone is 'all ears' at that point. We need to get flight testing and training verified before an aircraft is released to the line. Kicking over aluminium at an accident site is just too late.
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes
on
0 Posts
Which to me seems a huge issue. Before this second incident (assuming they're related) Boeing was downplaying the issue, basically trying to put lipstick on the pig. The second instance of this problem, in short order, shows that more is required than what was likely the lowest cost, most expedient fix Boeing could come up with. The assumption that Boeing made previously that pilots should be able to safely deal with another instance of this problem (hence justifying that grounding the fleet wasn't necessary, even after the second crash) proved to be sadly wrong and hence I conclude that the fix that Boeing had conceived before the second instance must also be flawed since it was based on their same myoptic attitude. To implement the 'fix' conceived of before this second incident within the next 10 days seems untenable. Unfortunately Boeing is motivated by $ to get any fix out there asap whether its a real fix or not. Today when news was leaked that the fix would be ready in 10 days (by Boeing?), the Boeing stock bumped 1.5%. If they had announced the fix would take another 5 months then likely the opposite would have happened or much worse. Hopefully, common sense will prevail and the required fix/action will be fully re-evaluated. I'm considering shorting Boeing stock but that would assume common sense will prevail.
Join Date: Oct 2018
Location: New york
Posts: 3
Likes: 0
Received 0 Likes
on
0 Posts
Total Bewilderment
I recognize that there are serious issues with the MCAS system but.... I am not a 737 Max driver but based on the Lion Air crash and the airworthiness directive my hand would be at the ready to flick a switch to deactivate the MCAS system if there are any flight control issues. That is less than a 1 second procedure. The thought that 157 souls died because the pilot did not flip a switch..which he knew was there ... total bewilderment. I’m sure the Boeing team is thinking the same thing. Maybe the stabilizer trim cutoff switches were indeed flipped but not likely. Time will tell.
Join Date: Apr 2009
Location: Hotel Gypsy
Posts: 2,821
Likes: 0
Received 0 Likes
on
0 Posts
Depending on speed they aircraft can be controlled with full nose down trim. It’s highly unlikely MCAS trimmed the aircraft full nose down since it only moves in increments of 2.5 degrees and if the pilot countered it with the electric trim the aircraft would remain close to a trimmed state. Any pilot with a basic level of competence would counter the trim to attempt to remain in trim. The MCAS if getting bad inputs would again after a period of time input 2.5 units of trim again. It’s not instantaneous and the pilot would be alerted by feel, sight and noise. At the point you would expect the pilot to disconnect the trim and continue the flight using manual trim. Pretty much a non event for a competent crew.
If your taxi driver pitched-up in a vehicle that first hit the roads on 9 April 1967, 9 days after my birthday, would you get in or would you wait for the next ride? The broomhandle and the broom have been replaced/modified numerous times over but were still waxing-lyrical about how it’s the same broom we bought 50 years back. Yes, I’m being a bit simplistic but it’s still time to wake up.
Shame on our industry.
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes
on
0 Posts
I keep reading such explanations but to be clear, MCAS is always powered on. When and where it functions is defined by software alone. As such this is safety critical software and should meet the highest assurance levels. The designer did not wish for the aircraft to crash and may have set all the protection methods they could think of as a credible design goals. We have yet to learn if MCAS, as implemented, did respect the AP selection, flap configuration or anything else the designer had in mind.
MCAS being 'live' when it should not have been remains a plausible explanation. It ticks all the boxes for a latent failure - no direct indication to the crew, no failure modes displayed, no routine interaction with other systems, no BITE or similar and does not drive the stab at any point during a normal sortie. As long as it thinks the AoA is ok it does nothing.
Time will tell if functions like trim cutout, AP cutout, configuration cutout etc actually work. Given that the system seems to be blissfully unaware of the actual flight dynamics beyond simple unmonitored raw sensor data and will willingly fly the aircraft into the ground, I remain reluctant to accept the claimed operating envelope as gospel.
I guess I have spent too many years flight testing aircraft and my level of 'trust' has been swamped by 'verify'. As an aside, flight testing has become inconvenient in the last 15 years or so. We get more facetime and interaction these days post-crash - everyone is 'all ears' at that point. We need to get flight testing and training verified before an aircraft is released to the line. Kicking over aluminium at an accident site is just too late.
As I have stated before, I think a key element in evaluating the safety of any system (aviation related or otherwise) that involves operator interface is clearly stating what the assumptions are with regard to how the operator will respond to the various scenarios to that he or she will encounter. Those assumptions then need to be evaluated and challenged before they can be relied upon as part of the foundation of a safe system. From all that has been written about the motivation for MCAS and the way it operates I believe that the baseline MCAS design assumed the following:
(1) If the flight crew uses their pilot commanded electric trim (thumb switches) they will not stop trimming for more that 5 seconds until the column force has been trimmed to (or close to) zero.
(2) Repeated events of the automatic stabilizer control running the stabilizer away from trim when starting from an otherwise trimmed, relatively steady flight condition will be recognized by the flight crew as errant behavior of the automatic stabilizer control system and that the flight crew response will be to activate the stabilizer cutout switches to disable further automatic stabilizer control commands.
(3) The impact of an errant AOA signal feeding into MCAS would be acceptable at the expected failure rate based on assumptions (1) and (2) above.
Much of what we have discussed for a couple of hundred PPRUNE pages across several threads over the past four plus month has been essentially the merits of these three assumptions. I suggest that a good way to evaluate the MCAS updates that Boeing is about to introduce will be to ask what pilot responses they assume. Furthermore I recommend that we check the revised design specifically against these three assumptions to see which of them are no longer needed to declare MCAS safe. If the new design includes provisions that eliminate dependence on all three of these assumptions I will have much greater peace of mind the next time that anyone (particularly anyone I care deeply for) files into the back of a 737MAX.
Join Date: Jun 2010
Location: Nanaimo, B.C.
Age: 66
Posts: 49
Likes: 0
Received 0 Likes
on
0 Posts
This will IMHO turn out to be a failure of FMECA - https://en.wikipedia.org/wiki/Failur...ality_analysis. The programmers failed to test the case where the AOA sensors disagreed and then project forward to the effect on the aircraft if the pilot either didn't know about or was slow to disable the autotrim. Code should have been written to either limit the horizontal stabilizer travel or to find another way to confirm that the angle of attack was really nearing the stall angle.
OTOH, if it is really necessary to drive the trim to full nose down to prevent stalls then arguably there is a fundamental design flaw in the aircraft. Maybe it just needs bigger elevators period.
OTOH, if it is really necessary to drive the trim to full nose down to prevent stalls then arguably there is a fundamental design flaw in the aircraft. Maybe it just needs bigger elevators period.
Salute Cows and FC eng !
Most of us here are not of the "Chuck Yeager" variety and "any competent crew" stock that could quickly save the day when a new feature of the airplane appears at the worst possible time.
Sad day for the flying public.
Gums....
Most of us here are not of the "Chuck Yeager" variety and "any competent crew" stock that could quickly save the day when a new feature of the airplane appears at the worst possible time.
Sad day for the flying public.
Gums....
Altitude data are not 100% reliable either. It is between 7200 and 7250 ft during takeoff roll then descend to 7075 ft after rotation (is there a hole in the runway ?)
Vertical speed is coherent with altitude variation. In 60 seconds between 05:38:39 and 05:39:39 altitude varies from 7200 to 8000 ft (800 ft/mn) and I computed the mean value of VS which is 822 ft/mn.
Of course, VS is very unstable and we don't know which part is due to the instrument errors and which (if any) to piloting or troubles with the controls...
Vertical speed is coherent with altitude variation. In 60 seconds between 05:38:39 and 05:39:39 altitude varies from 7200 to 8000 ft (800 ft/mn) and I computed the mean value of VS which is 822 ft/mn.
Of course, VS is very unstable and we don't know which part is due to the instrument errors and which (if any) to piloting or troubles with the controls...
It is also possible the runways are not level, like NFFN RWY02.
Join Date: Feb 2009
Location: Seattle
Posts: 379
Likes: 0
Received 0 Likes
on
0 Posts
MCAS is able to do its job with 2.5 degrees of stabilizer up to Mach 0.4 and less than 1/3rd of that at cruise. That MCAS can insert more stabilizer motion that this design limit is beyond its design requirements. There is not a control power deficiency as there is plenty of elevator to counter the design levels of stabilizer that MCAS needs.
Join Date: Aug 2006
Location: Looking for the signals square at LHR
Posts: 236
Likes: 0
Received 0 Likes
on
0 Posts
Maybe it just needs the CG moved to a position of improved intrinsic balance and reduced polar moments of inertia?
MCAS appears to be doing its job.
Adding a system like the MCAS to an aircraft it no different than adding a stick pusher to an aircraft has has suspect stall recovery?
I think everyone is missing the elephant in the room.
The MCAS is getting all the attention in the media and on this forum when it appears that the input to the MCAS is the suspect.
The MCAS is acting on what information it is fed. Why are we not looking at the source of that information?
Adding a system like the MCAS to an aircraft it no different than adding a stick pusher to an aircraft has has suspect stall recovery?
I think everyone is missing the elephant in the room.
The MCAS is getting all the attention in the media and on this forum when it appears that the input to the MCAS is the suspect.
The MCAS is acting on what information it is fed. Why are we not looking at the source of that information?