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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:b349:: with SMTP id z9mr2245842iti.77.1555665209288; Fri, 19 Apr 2019 02:13:29 -0700 (PDT) X-Received: by 2002:aca:3c55:: with SMTP id j82mr1199611oia.84.1555665209095; Fri, 19 Apr 2019 02:13:29 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!136no88287itk.0!news-out.google.com!w17ni159itb.0!nntp.google.com!136no88282itk.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 19 Apr 2019 02:13:28 -0700 (PDT) In-Reply-To: <874l6vhsvx.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=125.234.20.170; posting-account=swBhQwoAAAASyh-mRsC176VDTWaaVHF2 NNTP-Posting-Host: 125.234.20.170 References: <8736mwi257.fsf@nightsong.com> <874l6vhsvx.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Boeing 737 and 737 MAX software From: tranngocduong@gmail.com Injection-Date: Fri, 19 Apr 2019 09:13:29 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5568 X-Received-Body-CRC: 1140025214 Xref: reader01.eternal-september.org comp.lang.ada:56167 Date: 2019-04-19T02:13:28-07:00 List-Id: On Friday, April 19, 2019 at 5:04:54 AM UTC+7, Paul Rubin wrote: > FWIW here's an article that just came out in IEEE Spectrum, by a > programmer and private pilot pontificating about the 737 software and > MCAS. I don't have the impression that it's a good article from an > paviation standpoint but don't know enough about the topic to be sure. >=20 > Anyway, here it is, since it has been getting some attention: >=20 > https://spectrum.ieee.org/aerospace/aviation/how-the-boeing-737-max-disas= ter-looks-to-a-software-developer Thank you for introducing the article.=20 I, too, am under similar impression. I think that the article may contain o= versimplified or otherwise imprecise information. Nevertheless, I find it i= nspiring: it hepls me to come up with a theory which can explain many confl= icting facts and viewpoints. (Example of conflicting facts, the general pub= lic believe MCAS is an anti-stall, i.e. critical, system, while Boeing insi= sts it is a control-quality, i.e. non-critical, system.)=20 I'm just trying to sort things up in my mind. I'm not intended to blame or = to defend anyone. 1. The 737 has two, not only one, autopilots (AP1 and AP2). They work witho= ut any coordination, with the only exception that at most one can be active= at a time. In particular, neither of them monitors or can override the oth= er. 2. Technically, an autopilot can take input from a set of sensors on its si= de as well as a second set of sensors on the other side. However, as a desi= gn philosophy, to keep them as independent as possible, systematic effort w= as made to let them not to look at the other side's set of sensors unless i= t is absolutely necessary. 3. Each autopilot can detect sensor failures on its own side and manage to = fly even in case of one or couple of simultaneous faulty sensors. It diseng= ages if the number of faulty sensors go beyond of its ability. 4. For simplicity, the two autopilots are documented as "the autopilot" and= there is only one button on either (captain or first-officer) side to enga= ge/disengage one. The simplicity comes at certain inconvenience. For exampl= e, the captain can only activate AP1 while the first officer can only activ= ate AP2, and the captain may fail but the first officer may succeed to acti= vate "the autopilot". 5. On the 737 MAX, two anti-stall systems (AS1, AS2) were added, in the sam= e design principle that there is no coordination between the four systems (= AP1, AP2, AS1, AS2) except that at most one can be active at a time. Becaus= e AS1 and AS2 have authority to move control surfaces (such as the horizont= al stabilizer), they're classified safety-critical. 6. Additionally on the MAX, "maneuvering characteristics" (MC), a control-q= uality tweaker, was added. The very purpose is to keep the control stick fe= eling exactly as it was on previous 737 generations. It changes the [artifi= cial] control feeling by the classical mechanism: a "force generator" contr= olled by a "feel computer". It does not touch any control surface. Because = of that, it is classified non-critical. 7. In order to save time, the MC and the ASs were submitted to certificatio= n, and were eventually certified, as a single system, under the umbrella na= me MCAS. The name Anti-Stall was changed to Augmentation System. The catego= ry was changed from safety-critical to non-critical. 8. Like AP1/AP2, AS1/AS2 is able to detect faulty AoA sensor on its side an= d terminate itself. However, a bug causes AS1/AS2 fail to do its job in cer= tain cases, such as multiple sensor failures. 9. After the first accident, the FAA ordered to "fix the MCAS". After the s= econd accident, it finds that the name "MCAS" not correct anymore and insis= ts in resolving _two_ problems. Maybe MC and AS. Or AP and AS. And it insis= ts in re-classifying the AS safety-critical. Although generally, that would= be very hard to impossible, in this case that's no problem for Boeing: the= AS was designed to be (1) safety-critical, and (2) separately of the AP, i= n the first place. Therefore, about 10 - 14 months (since the first acciden= t) would suffice.