From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Boeing 737 and 737 MAX software Date: Sat, 6 Apr 2019 21:45:24 +0300 Organization: Tidorum Ltd Message-ID: References: <8736mwi257.fsf@nightsong.com> <5rnhael4n4dunnbrcs5o2t5tnua2t3iunh@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net jkNEs8cFVWySdvXV8jWpUgLj4zVp7+514uSrziYBPR7W38F4hn Cancel-Lock: sha1:j1WlHuk9aqVjaM4CCSGuzjRByZY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <5rnhael4n4dunnbrcs5o2t5tnua2t3iunh@4ax.com> Xref: reader01.eternal-september.org comp.lang.ada:56090 Date: 2019-04-06T21:45:24+03:00 List-Id: On 19-04-06 20:30 , Dennis Lee Bieber wrote: > On Fri, 05 Apr 2019 14:16:20 -0700, Paul Rubin > declaimed the following: > >> Does anyone know anything about this? It has been under some criticism >> lately. As I've read more about these accidents than I usually do, I will boldly (and perhaps foolhardily) describe how I have understood it. All info is from public sources, I have no insider info. I am not a pilot, and moreover I write from recollection of my reading and have no references to give, so reader beware. >> I have heard that the 777 software was almost entirely in Ada. It also >> sounds as if Boeing's software operation may have slipped in recent >> years, not good news for the 737 MAX. > > Unless things have changed severely -- GE Aviation (formerly Smith's > Aerospace, formerly Lear Siegler) produces the 737 FMS software (and also > the processor boxes). > > However, I have the impression (from TV news) the software is > functioning /as designed/. All info I have seen agrees with that. > Some reports have indicated that Boeing designed > the hardware (and corresponding software requirements) such that only one > sensor is used for the MCAS subsystem The are two angle-of-attack (AoA) sensors, one on each side of the nose. They feed two redundant computers, each able to run MCAS. Normally only one MCAS instance is running and it uses only its "own" AoA sensor. The original design of MCAS gave it rather little control authority, which is probably why this single-sensor approach was accepted. > -- and a fault in that sensor results > in MCAS attempting to prevent a (non) stall by pushing the nose down. Yes, but MCAS does not apply a temporary nose-down command -- as if pushing the stick forward -- it changes the pitch trim, the overall angle of the horizontal stabilizer, giving the plane a permanent tendency to dive. This trim change can be overridden by the pilots, but only if they notice that it has happened. In the original MCAS design, one activation of MCAS changed the pitch trim by a small amount, at most 0.6 degrees IIRC, and this limit was reported in the MCAS design documentation to the authorities. During testing, Boeing found that it was not enough, and they increased it quite a lot, to over 2 degrees IIRC. One source I read claimed that this change was _not_ updated in the documentation shown to the authorities. Moreover, by design MCAS would repeat this trim change, with a certain minimum interval, as long as the AoA sensor reading remained too large and indicated a risk of stall. This iteration should converge and stop if the sensor is working, but if the sensor fails and is stuck at a high AoA (the false value reported in the second accident was around 60 degrees, IIRC) then MCAS will incrementally and cumulatively keep increasing the pitch trim and the diving tendency. If the pilots do not understand what is happening, they will find it ever harder to counteract the "dive" trim with stick inputs. > Some > hints in the news that Boeing is changing the requirements (well, in truth, > the news only says Boeing is changing the software) to have MCAS > cross-reference with other flight parameter data -- and making an optional > bit of hardware (additional sensors) standard. AIUI the modifed MCAS will read both AoA sensors and will disable itself if they disagree, and the disagreement will also be reported by a display. This display is the new piece of HW which used to be an option. There are no new sensors, AIUI. I believe Boeing are also changing the minimum interval between MCAS activations -- perhaps even allowing only one activation -- so as to prevent a cumulatively increasing "dive" trim. In summary, it seems to me that the criticality of MCAS, and thus the need for redundant sensors, was not realized for two reasons: (1) in its initial design, MCAS command authority was small, and (2) the possibility of multiple repeated commands (due to a stuck sensor) and the resulting large cumulative command (large change of pitch trim) was not considered. A kind of "criticality creep". -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .