# Boeing software fix for 737 Max **URL:** \ **Category:** Factual Questions\ **Created:** [March 27, 2019, 7:12pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626 "2019-03-27T19:12:55Z")\ **Posts on this page:** 20\ **Page:** 8
**Author:** ![TokyoBayer](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/tokyobayer/32/13989_2.png) [@TokyoBayer](https://boards.straightdope.com/u/TokyoBayer)\ **Post date:** [April 9, 2019, 3:07am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/141 "2019-04-09T03:07:44Z")
> [@Magiver](#): > > You’ve already pointed out that this can be reduced with programming changes and that may be all it takes. > > I personally would expect a switch that deactivates the MCAS and would be surprised if it doesn’t already exist. > > (Snip) > > I think this likely pilot error in response to a serious MCAS system flaw made worse by a lack of training. I keep coming back to this and wondering why there wasn’t a switch to deactivate the MCAS system. I can sort of understand why it may not have been implemented initially, but once the first crash occurred why wouldn’t that have been changed? Boeing should have become forcefully aware of the issue after the Lion Air accident. I wonder why this potential situation wasn’t addressed better. Did they carefully analyze the failure rate and assume that the risk was acceptable or was the analysis wrong? Additional training appears to not have been implemented after that Lion Air, and again one has to wonder why. Boeing and the airlines are not looking good at the moment. ---
**Author:** ![Magiver](https://avatars.discourse-cdn.com/v4/letter/m/4491bb/32.png) [@Magiver](https://boards.straightdope.com/u/Magiver)\ **Post date:** [April 9, 2019, 4:20am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/142 "2019-04-09T04:20:12Z")
I would like to know what testing was done in relation to AoA failure. It’s actually an easy problem to handle with training. All you need to know is that the MCAS is engaging the trim in an obviously unnecessary manner. For those who need a visual here’s a picture of a [737-max cockpit](https://www.nytimes.com/interactive/2018/11/16/world/asia/lion-air-crash-cockpit.html). The solution is to hit the trim switch on the yoke handle (1) until it’s where you want it trimmed and then turn off the trim system with the deactivation switch (2). Done. You can either manually turn the trim wheels or reactivate the electric trim and repeat as needed. Now if the AoA is triggering the anti-stall system you’ll still have to fight the yoke but at least you have control of the horizontal stabilizer. ---
**Author:** ![GreenWyvern](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/greenwyvern/32/2834_2.png) [@GreenWyvern](https://boards.straightdope.com/u/GreenWyvern)\ **Post date:** [April 9, 2019, 6:56am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/143 "2019-04-09T06:56:05Z")
> [@Magiver](#): > > The solution is to hit the trim switch on the yoke handle (1) until it’s where you want it trimmed and then turn off the trim system with the deactivation switch (2). Done. You can either manually turn the trim wheels or reactivate the electric trim and repeat as needed. > > Now if the AoA is triggering the anti-stall system you’ll still have to fight the yoke but at least you have control of the horizontal stabilizer. From the preliminary report, it looks to me like that’s exactly what the pilots did, or tried to do. What I don’t understand is that with the stab trim switches off, “From 05:40:42 to 05:43:11 (about two and a half minutes), the stabilizer position gradually moved in the AND direction from 2.3 units to 2.1 units.” The pilots were struggling with the trim and saying it was not working. In fact the trim was gradually getting worse. Then they switched on the electric stab trim again, and twice pitched up - but it looks to me like it had no effect. It didn’t respond, and the pitch didn’t go up. Only then did the MCAS engage again, and the plane went into its final dive. Could there have been a problem with the stabilizer separate from the MCAS? Perhaps caused by the stabilizer being moved to its extreme position by the MCAS (at 5:40:27) and refusing to come back again to level? ---
**Author:** ![TokyoBayer](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/tokyobayer/32/13989_2.png) [@TokyoBayer](https://boards.straightdope.com/u/TokyoBayer)\ **Post date:** [April 9, 2019, 8:11am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/144 "2019-04-09T08:11:27Z")
Back around the year 2000, and my friend, an IC chip designer and I were having a discussion. Both Americans,working in Japan and comparing philosophies about quality. In both of our fields, Japanese manufacturers tended to be much more likely to chase after possible defects in rare cases. In a case like this, where a defect lead to such a catastrophe, it’s just so surprising that or changes were not made. I would have thought that the aircraft industry would have been much more proactive about solving this, including additional training. ---
**Author:** ![Richard\_Pearse](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/richard_pearse/32/13144_2.png) [@Richard\_Pearse](https://boards.straightdope.com/u/Richard_Pearse)\ **Post date:** [April 9, 2019, 9:48am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/145 "2019-04-09T09:48:07Z")
> [@TokyoBayer](#): > > I keep coming back to this and wondering why there wasn’t a switch to deactivate the MCAS system. I can sort of understand why it may not have been implemented initially, but once the first crash occurred why wouldn’t that have been changed? > > Boeing should have become forcefully aware of the issue after the Lion Air accident. I wonder why this potential situation wasn’t addressed better. Did they carefully analyze the failure rate and assume that the risk was acceptable or was the analysis wrong? > > Additional training appears to not have been implemented after that Lion Air, and again one has to wonder why. > > Boeing and the airlines are not looking good at the moment. It was only a few months between the Lion Air crash and Ethiopian. That’s not enough time to do anything significant to the aircraft itself. The software changes that are being worked on at the moment were in response to Lion Air, not Ethiopian, so it’s taken this long plus some since the first crash to get some changes made. In the meantime Boeing and the FAA thought that an Airworthiness Directive pointing pilots toward using the runaway stabiliser procedure in response to an MCAS issue was satisfactory until the software changes were finished. The Ethiopian crash demonstrated that this was not the case and so the type has been grounded. > [@](#): > > In a case like this, where a defect lead to such a catastrophe, it’s just so surprising that or changes were not made. I would have thought that the aircraft industry would have been much more proactive about solving this, including additional training. The industry is slow. If a problem can’t be fixed by publishing a revised procedure and it is a serious problem then airframes get grounded for months while it is dealt with. ---
**Author:** ![eschrodinger](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/eschrodinger/32/122_2.png) [@eschrodinger](https://boards.straightdope.com/u/eschrodinger)\ **Post date:** [April 9, 2019, 6:27pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/146 "2019-04-09T18:27:56Z")
This post has some interesting detailed analysis of the preliminary report. [Satcom Guru: What happened on ET302?](https://www.satcom.guru/2019/04/what-happened-on-et302.html?m=1#more) It gives an explanation why the final MCAS action was likely unrecoverable. (There is also a link to another interesting discussion of what the DFDR shows happened, and what might have been going on in the cockpit.) It mentions ways that the MCAS authority should have been (and should now be) limited to scenarios where a stall/near stall could actually be possible. Points out how it is odd and unexplained that the manual electric trim was never used to trim back up past 2.3 or so. Provides a possible explanation for the gradual AND trim applied manually after the cutout switches were flipped. (That the stabilizer jack screw was likely impossible to manually move in the ANU direction due to forces on the stabilizer and elevator, and the AND movement may have been experimental movement the other way.) ---
**Author:** ![eschrodinger](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/eschrodinger/32/122_2.png) [@eschrodinger](https://boards.straightdope.com/u/eschrodinger)\ **Post date:** [April 9, 2019, 6:39pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/147 "2019-04-09T18:39:08Z")
For those with more knowledge of how such things work, is it fairly clear now that the runaway trim checklist was not sufficient to respond to this scenario, and that training/simulator time would have been needed for pilots to learn the necessary responses in this scenario? What about after a software fix, if one is made, and particularly if it will include MCAS being disengaged in some circumstances? ---
**Author:** ![Frankenstein\_Monster](https://avatars.discourse-cdn.com/v4/letter/f/ccd318/32.png) [@Frankenstein\_Monster](https://boards.straightdope.com/u/Frankenstein_Monster)\ **Post date:** [April 10, 2019, 3:43pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/148 "2019-04-10T15:43:10Z")
Everybody says the two accidents were very much alike but what strikes me is how they differed. The Ethiopian accident has the additional factor of the overspeed condition due to engines in Take-Off thrust. They have the throttles left in Take-Off thrust and continuously increasing airspeed, eventually going through VMO and triggering the clacker. I see both the right pitot and the radar altitude working correctly, showing the altitude increasing. So they were not gaining speed from diving, they were gaining speed from the engines. Why didn’t they pull back on the throttles? I can see they were dealing with that AoA/MCAS aftermath, i.e. high column forces, out-of-trim condition, inability to trim, stick shaker shaking, and assorted failure indications. Still a rather basic thing to forget for a pilot! ISTM they dealt with the MCAS thing correctly. Then forgot one of the most basic pilot instincts, leveling off the throttle. Or is this another “Chuck Yeager” moment? ---
**Author:** ![GreenWyvern](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/greenwyvern/32/2834_2.png) [@GreenWyvern](https://boards.straightdope.com/u/GreenWyvern)\ **Post date:** [April 10, 2019, 4:38pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/149 "2019-04-10T16:38:48Z")
> [@Frankenstein\_Monster](#): > > Why didn’t they pull back on the throttles? Perhaps they didn’t see that as a problem. They wanted to gain altitude quickly. In fact the altitude was steadily increasing throughout the time they were having difficulties, from about 9,000ft when the MCAS first cut in, to about 14,000ft just before the final dive. This was the stated altitude that they wanted to reach. (Airport altitude is 5,000ft.) They may not have realized that the speed was making it difficult to adjust the trim, if in fact that was what was happening. ---
**Author:** ![Frankenstein\_Monster](https://avatars.discourse-cdn.com/v4/letter/f/ccd318/32.png) [@Frankenstein\_Monster](https://boards.straightdope.com/u/Frankenstein_Monster)\ **Post date:** [April 10, 2019, 5:57pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/150 "2019-04-10T17:57:49Z")
Thanks **GreenWyvern** , I think I see it now. The throttles were set for a much steeper climb. They are unable to reach their pitch attitude due to being to much out of trim. You can see the pitch attitude struggling and generally too low in any case. Chuck Yeager time again then, I suppose. ---
**Author:** ![Frankenstein\_Monster](https://avatars.discourse-cdn.com/v4/letter/f/ccd318/32.png) [@Frankenstein\_Monster](https://boards.straightdope.com/u/Frankenstein_Monster)\ **Post date:** [April 10, 2019, 6:18pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/151 "2019-04-10T18:18:37Z")
> [@GreenWyvern](#): > > What I don’t understand is that with the stab trim switches off, “From 05:40:42 to 05:43:11 (about two and a half minutes), the stabilizer position gradually moved in the AND direction from 2.3 units to 2.1 units.” > > The pilots were struggling with the trim and saying it was not working. In fact the trim was gradually getting worse. Then they switched on the electric stab trim again, and twice pitched up - but it looks to me like it had no effect. It didn’t respond, and the pitch didn’t go up. Only then did the MCAS engage again, and the plane went into its final dive. > > Could there have been a problem with the stabilizer separate from the MCAS? Perhaps caused by the stabilizer being moved to its extreme position by the MCAS (at 5:40:27) and refusing to come back again to level? Answered by **eschrodinger’s** link but I wanted to highlight this. Due to high aerodynamic forces, the stabilizer trim jackscrew would have been very hard or impossible to move in one direction and very easy to move in the other (wrong) direction. And this was apparently known since the original 1960’s version of the 737 and documented in the flight manual. (quote in the link) Clearly a large contributing factor to the accident, as well as a problem largely separate from the MCAS. Would this be something they’re also going to have to fix? Other than by just telling the pilots to fly the correct speed? ---
**Author:** ![eschrodinger](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/eschrodinger/32/122_2.png) [@eschrodinger](https://boards.straightdope.com/u/eschrodinger)\ **Post date:** [April 10, 2019, 9:13pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/152 "2019-04-10T21:13:04Z")
> [@GreenWyvern](#): > > Airport altitude is 5,000ft. Just a slight correction. Addis Ababa airport is at 7656’ above sea level, according to the preliminary report. I think the pressure altitude was around 5,000 at ground level at the time of the crash. They reached a maximum altitude of around 14,000’ above sea level, or around 7,000’ above ground level before the crash. Frankenstein Monster As I understand it, when the stick shaker/stall warnings are going off, and airspeed values are not agreeing, the tendency will not be to throttle back. One overspeed clacker kicked in around 2:30 before the crash, when one pilot was struggling to hold back the yoke, and the other was struggling with trying to move the hand crank stabilizer wheel. The checklist and additional advice from Boeing don’t focus on speed. They were still trying to work through the checklist at that point. The other overspeed clacker started later (the one on the right, which was the side with the more reliable instruments at that point.) Now there is an emerging question about whether the elevator – the control surfaces that is providing the “up” force to counter the nose down stabilizer trim – suffers from “blowback” at high speeds. This would possibly explain why the final efforts to pull back on the yoke, which moved it back more than it had been pulled back the whole flight, did almost nothing. Blowback would mean that, at high enough speeds, the forces on the elevator are enough to overcome the hydraulics, and start to drive the elevator back/down despite the controls trying to move it the other way. It may be easy to point to a few specific things in retrospect that could have changed the outcome. But it seems to me that this is exactly what simulator training is for, after there is a set, reliable procedure for the issue. Put the pilots in the critical scenario enough times that they can recognize it and respond reliably in the correct way, including knowing what to focus on, and what can wait until the issue is resolved. ---
**Author:** ![eschrodinger](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/eschrodinger/32/122_2.png) [@eschrodinger](https://boards.straightdope.com/u/eschrodinger)\ **Post date:** [April 10, 2019, 9:23pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/153 "2019-04-10T21:23:34Z")
Correction (too late to edit): The right overspeed clacker was the first one to sound. ---
**Author:** ![scr4](https://avatars.discourse-cdn.com/v4/letter/s/59ef9b/32.png) [@scr4](https://boards.straightdope.com/u/scr4)\ **Post date:** [April 10, 2019, 10:07pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/154 "2019-04-10T22:07:22Z")
> [@Frankenstein\_Monster](#): > > Why didn’t they pull back on the throttles? Since the engines are mounted under the wings, pulling back on the throttle would cause the aircraft to pitch down further, wouldn’t it? ---
**Author:** ![TokyoBayer](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/tokyobayer/32/13989_2.png) [@TokyoBayer](https://boards.straightdope.com/u/TokyoBayer)\ **Post date:** [April 10, 2019, 11:43pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/155 "2019-04-10T23:43:23Z")
> [@eschrodinger](#): > > This post has some interesting detailed analysis of the preliminary report. [Satcom Guru: What happened on ET302?](https://www.satcom.guru/2019/04/what-happened-on-et302.html?m=1#more) Very interesting report. From it: > [@post](#): > > The captain is pulling the column aft stabilize the pitch attitude. He desperately wants to trim the stabilizer nose up to offload the column and restore trimmed flight. By hitting the cutout switches, the flight crew must resort to manual trim wheel. > > The cutout switch function was changed with the 737MAX from all prior 737 models. The legacy switch combination was one switch to cutout electric trim altogether, the other to cutout the autopilot trim commands. MCAS and Speed Trim System are both commands from the “autopilot”. With the legacy switch configuration, the flight crew can disable the autopilot commands and retain electric trim. > > (shows picture of the STAB TRIM switches for the 737 prior models) > > With the 737MAX, the flight crew lose both electric trim and autopilot trim with the cutout switch. > > (shows picture of the STAB TRIM switches for the 737 MAX) > > The Flight Standardization Board (FSB) took notice of the nomenclature change of the cutout switches but did not make any mention of the difference in responding to autopilot stab trim runaway. On the 737NG, the flight crew retain electric trim; on the 737MAX the flight crew must use manual trim. It turns out, this is a significant difference in pilot workload and pilot capacity to fly the airplane. This addresses the question raised in this thread concerning why they didn’t have switch to cutout the MCAS system while retaining electric trim. From a system design point of view, it’s interesting (people died so maybe that’s the wrong choice of words) that the feature of allowing the crew to retain electric trim was eliminated on the 737 Max. The various articles so far suggest that the MCAS system was required in order for the plane to be certified. Without it, the plane would be unstable in certain circumstances. However, the next question has to be why the was the change made to not allow a disable? Would that have required the type of training they wanted to avoid? ---
**Author:** ![Magiver](https://avatars.discourse-cdn.com/v4/letter/m/4491bb/32.png) [@Magiver](https://boards.straightdope.com/u/Magiver)\ **Post date:** [April 11, 2019, 1:32am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/156 "2019-04-11T01:32:06Z")
> [@Frankenstein\_Monster](#): > > Would this be something they’re also going to have to fix? Other than by just telling the pilots to fly the correct speed? the fix is not to let the plane get in this situation in the first place. Which ironically is the purpose of the MCAS and stall prevention system. ---
**Author:** ![wolfpup](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/wolfpup/32/10618_2.png) [@wolfpup](https://boards.straightdope.com/u/wolfpup)\ **Post date:** [April 11, 2019, 1:48am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/157 "2019-04-11T01:48:21Z")
> [@TokyoBayer](#): > > Very interesting report. From it:This addresses the question raised in this thread concerning why they didn’t have switch to cutout the MCAS system while retaining electric trim. > > From a system design point of view, it’s interesting (people died so maybe that’s the wrong choice of words) that the feature of allowing the crew to retain electric trim was eliminated on the 737 Max. > > The various articles so far suggest that the MCAS system was required in order for the plane to be certified. Without it, the plane would be unstable in certain circumstances. However, the next question has to be why the was the change made to not allow a disable? Would that have required the type of training they wanted to avoid? The quote about the change in cut-out switch functionality is extremely interesting and pertinent. With the caveat that we don’t know whether that particular commentary is 100% authoritative, it does make sense, because it explains the otherwise incomprehensible change of labeling from “MAIN ELECT” and “AUTO-PILOT” to “PRI” and “B/U”. Mind you, as mentioned, one of the official documents notes it as being merely a “nomenclature change”. So which is it? If it’s true that previous generations could disable trim commands from the flight control computer without disabling electric trim, but the 737 MAX cannot, then this is a monumentally stupid design decision. Moreover, given the state of [non-]documentation of the MCAS, I wonder whether even a 737 MAX pilot would know for sure whether or not the switch functions changed between the NG and the MAX. It seems that with every new revelation, this is looking worse and worse for Boeing. ---
**Author:** ![eschrodinger](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/eschrodinger/32/122_2.png) [@eschrodinger](https://boards.straightdope.com/u/eschrodinger)\ **Post date:** [April 11, 2019, 1:55am UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/158 "2019-04-11T01:55:19Z")
> [@Magiver](#): > > the fix is not to let the plane get in this situation in the first place. Which ironically is the purpose of the MCAS and stall prevention system. How is that the purpose of the MCAS and stall prevention system? ---
**Author:** ![Spiderman](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/spiderman/32/230_2.png) [@Spiderman](https://boards.straightdope.com/u/Spiderman)\ **Post date:** [January 6, 2020, 2:37pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/159 "2020-01-06T14:37:41Z")
::Bump:: Potential new problem discovered with 737 MAX, wiring issue in tail this time. [NY Times](https://www.nytimes.com/2020/01/05/business/boeing-737-max.html) [CNN](https://www.cnn.com/2020/01/05/business/boeing-737-max-wiring-issue/) ---
**Author:** ![Crafter\_Man](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/crafter_man/32/458_2.png) [@Crafter\_Man](https://boards.straightdope.com/u/Crafter_Man)\ **Post date:** [January 6, 2020, 4:35pm UTC](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626/160 "2020-01-06T16:35:17Z")
> [@Spiderman](#): > > ::Bump:: > > Potential new problem discovered with 737 MAX, wiring issue in tail this time. > [NY Times](https://www.nytimes.com/2020/01/05/business/boeing-737-max.html) > [CNN](https://www.cnn.com/2020/01/05/business/boeing-737-max-wiring-issue/) I’ve been searching for the actual audit but haven’t found it. Is it not online? [Previous page](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626.md?page=7) [Next page](https://boards.straightdope.com/t/boeing-software-fix-for-737-max/831626.md?page=9)