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.unit0.net!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: Thu, 18 Apr 2019 18:13:02 +0300 Organization: Tidorum Ltd Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net gxhlawsG6k+kd/JbXO00GQzyVwYJylaaipc1AXtBwn6d5MsWRY Cancel-Lock: sha1:TPKS72gztIfNbgLRUzvkiE7wM/E= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader01.eternal-september.org comp.lang.ada:56157 Date: 2019-04-18T18:13:02+03:00 List-Id: On 19-04-18 16:53 , tranngocduong@gmail.com wrote: > Generally, flight control softwares are supposed to use multiple, > redundant, algorithms (including multiple, redundant, computers and > sensors) to derive flight parameters. Yes. [snip] > Yet the faulty left AoA sensor went undetected. How can it be? The descriptions of the MCAS system that I have seen say quite clearly that it used only one of the two AoA sensors mounted on the aircraft (and that this single-sensor design is unacceptable for a flight-control system that ended up with this level of authority and criticality). I have not seen any statement about other standard SW that would be able to flag an AoA sensor as faulty. There was an optional addition that could do it, not mounted on the planes that crashed. The whole MCAS system was an add-on and perhaps for that reason not well integrated with the rest of the flight SW (this is speculation on my part). > 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). From the descriptions I have read, it is clear (to me) that (b) was the case, at least that MCAS used a single AoA sensor and there was no cross-check against the other AoA sensor or other sensors or computations. Moreover, the descriptions of the planned correction to the 737 MAX focus on using both AoA sensors and warning the pilots if they disagree, which is coherent with (b) but not with (a). On the issue of Ada subtypes, it seems to me that if the SW specification, design and coding considers sensor faults (as it of course should), the normal approach for such critical SW is _not_ to use strongly constrained subtypes and rely on Constraint_Error handling. The normal approach is to add explicit and specific range checks and sensor/computation cross-checks. That would be much easier to specify and test, and would also make it much easier to identify the faulty sensor(s) and to handle such situations properly. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .