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:a02:ac9a:: with SMTP id x26mr66893854jan.129.1555604512303; Thu, 18 Apr 2019 09:21:52 -0700 (PDT) X-Received: by 2002:aca:61d6:: with SMTP id v205mr2458969oib.122.1555604512049; Thu, 18 Apr 2019 09:21:52 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!b2no165532itd.0!news-out.google.com!w17ni220itb.0!nntp.google.com!136no166277itk.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 18 Apr 2019 09:21:51 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=113.172.131.50; posting-account=swBhQwoAAAASyh-mRsC176VDTWaaVHF2 NNTP-Posting-Host: 113.172.131.50 References: <8736mwi257.fsf@nightsong.com> <2590d3d8-5f91-4f59-897e-e0c9b7e1b5ca@googlegroups.com> <5f483f72-9213-4c63-b3f9-7150fc4e455f@googlegroups.com> <03d33940-85e9-4fc9-9f2b-2b43f2cfd6af@googlegroups.com> <47a71ba7-38cb-426b-8dad-564f08afbcb2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <70d7f427-ddce-4ec0-aba3-99edab0780bc@googlegroups.com> Subject: Re: Boeing 737 and 737 MAX software From: tranngocduong@gmail.com Injection-Date: Thu, 18 Apr 2019 16:21:52 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56158 Date: 2019-04-18T09:21:51-07:00 List-Id: On Thursday, April 18, 2019 at 10:13:05 PM UTC+7, Niklas Holsti wrote: > The descriptions of the MCAS system that I have seen say quite clearly=20 > that it used only one of the two AoA sensors mounted on the aircraft=20 > (and that this single-sensor design is unacceptable for a flight-control= =20 > system that ended up with this level of authority and criticality). >=20 > I have not seen any statement about other standard SW that would be able= =20 > to flag an AoA sensor as faulty. There was an optional addition that=20 > could do it, not mounted on the planes that crashed. The whole MCAS=20 > system was an add-on and perhaps for that reason not well integrated=20 > with the rest of the flight SW (this is speculation on my part). >=20 The optional "AoA disagree" indicator is just a surface issue. I've seen a = couple of analysis stating that it is really not very helpful. To my limite= d knowledge, AoA is a critical parameter that is used by many flight contro= l algorithms, not just the MCAS. The real issue is thus the failure to dete= ct an unreliable sensor. If the failure was a "feature, not bug", the entir= e flight software (and its certificate) would be questioned. > > a) Ada was used but programmers have chosen a wrong (too relaxed) > > subtype, or other language was used and programmers failed to code > > whatever equivalent to raising and handling a CONSTRAINT_ERROR. > > Simply: software bug. > > > > b) Contrary to general belief, the software was not programmed with > > multiple redundant computation. Simply: process failure. > > > > I chose to believe a). >=20 > From the descriptions I have read, it is clear (to me) that (b) was the= =20 > case, at least that MCAS used a single AoA sensor and there was no=20 > cross-check against the other AoA sensor or other sensors or=20 > computations. Moreover, the descriptions of the planned correction to=20 > the 737 MAX focus on using both AoA sensors and warning the pilots if=20 > they disagree, which is coherent with (b) but not with (a). >=20 If b) was the case, not only the software, but the entire process would be = questioned. A bug would take weeks or months to fix. A software would take = years to re-engineer. A process would take decades to develop. Would Boeing= as a company risk its very existence by comiting such a big mistake? I don= 't think so. > On the issue of Ada subtypes, it seems to me that if the SW=20 > specification, design and coding considers sensor faults (as it of=20 > course should), the normal approach for such critical SW is _not_ to use= =20 > strongly constrained subtypes and rely on Constraint_Error handling. The= =20 > normal approach is to add explicit and specific range checks and=20 > sensor/computation cross-checks. That would be much easier to specify=20 > and test, and would also make it much easier to identify the faulty=20 > sensor(s) and to handle such situations properly. >=20 > --=20 > Niklas Holsti > Tidorum Ltd I know. SPARK and ParaSail do not allow exceptions for a reason. But becaus= e the MCAS was [mistakenly] classified as a non-critical component, program= mers may choose to use less formal/rigorous methodology, which give rise fo= r constraints and exceptions if Ada was selected.