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:6e01:: with SMTP id w1mr3661989itc.15.1555595591123; Thu, 18 Apr 2019 06:53:11 -0700 (PDT) X-Received: by 2002:a9d:4909:: with SMTP id e9mr61186733otf.160.1555595590866; Thu, 18 Apr 2019 06:53:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!b2no151278itd.0!news-out.google.com!w17ni181itb.0!nntp.google.com!b2no151276itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 18 Apr 2019 06:53:10 -0700 (PDT) In-Reply-To: <47a71ba7-38cb-426b-8dad-564f08afbcb2@googlegroups.com> 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: Subject: Re: Boeing 737 and 737 MAX software From: tranngocduong@gmail.com Injection-Date: Thu, 18 Apr 2019 13:53:11 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56155 Date: 2019-04-18T06:53:10-07:00 List-Id: On Thursday, April 18, 2019 at 7:44:17 PM UTC+7, Maciej Sobczak wrote: > > True, airspeed needs not be computed this way. But it must be somehow c= omputed. >=20 > Note that the airspeed had to be computed (or measured) long before the n= ew sensor was invented, so presumably the method of computing it was not ta= king the new sensor into account anyway. And I don't expect that method to = be changed just because some new sensor is installed. >=20 > I don't see any reason for using this addition anywhere in the system. >=20 > > True, it is possible that the software was written in Ada. But then, th= e fact that it didn't raise an exception >=20 > If the addition was never performed (because there was no reason to do it= ), then it is quite reasonable that no exception was raised. >=20 > One could imagine a contract that binds several such values in constraint= s that are motivated at the system-level and this is arguably where Ada cou= ld help. But I doubt such novel programming techniques would be even consid= ered. >=20 > > indicating a failure to detect/handle so "exceptional" situations as Ao= A implying negative [horizontal] airspeed, is simply unbelievable. >=20 > Why? The new sensor was not installed to detect negative airspeed, but to= detect stalls. >=20 > This system might have been written in Ada or C (I don't expect anything = else to be even considered) with the same results. Which, arguably, is not = helping to promote the language (whichever was used). >=20 > --=20 > Maciej Sobczak * http://www.inspirel.com I'm not sure what is the "new sensor" but I'll try to explain my point in o= ther words. Generally, flight control softwares are supposed to use multiple, redundant= , algorithms (including multiple, redundant, computers and sensors) to deri= ve flight parameters. The derived values, if not used directly to control t= he aircraft, may be used to monitor the flying computer, the sensors, or th= e software itself.=20 In particular, in the case of the 737, we may assume that sufficiently redu= ndant computation can detect faulty AoA sensor without using any additional= AoA sensor. The aforementioned addition is an example of such a (redundant= ) computation. Note that this method is not novel. It is just an instance of a more genera= l principle that every input data have to be validated. Yet the faulty left AoA sensor went undetected. How can it be? a) Ada was used but programmers have chosen a wrong (too relaxed) subtype, = or other language was used and programmers failed to code whatever equivale= nt to raising and handling a CONSTRAINT_ERROR. Simply: software bug. b) Contrary to general belief, the software was not programmed with multipl= e redundant computation. Simply: process failure. I chose to believe a).