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 X-Received: by 2002:a37:470b:: with SMTP id u11mr25285147qka.172.1574091121674; Mon, 18 Nov 2019 07:32:01 -0800 (PST) X-Received: by 2002:a05:6830:1003:: with SMTP id a3mr23485140otp.16.1574091121279; Mon, 18 Nov 2019 07:32:01 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!j16no630111qtl.0!news-out.google.com!g53ni272qtg.0!nntp.google.com!j16no630098qtl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 18 Nov 2019 07:32:00 -0800 (PST) In-Reply-To: <77c1a16c-cb3c-4d09-a932-6ceb369996f9@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.234.173; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.234.173 References: <8736mwi257.fsf@nightsong.com> <5rnhael4n4dunnbrcs5o2t5tnua2t3iunh@4ax.com> <87bltn9nmy.fsf@nightsong.com> <77c1a16c-cb3c-4d09-a932-6ceb369996f9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <326a6118-2177-4290-bd66-a7f71ddff263@googlegroups.com> Subject: Re: Boeing 737 and 737 MAX software From: Optikos Injection-Date: Mon, 18 Nov 2019 15:32:01 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57584 Date: 2019-11-18T07:32:00-08:00 List-Id: On Monday, November 18, 2019 at 5:16:42 AM UTC-6, robin...@gmail.com wrote: > On Friday, November 8, 2019 at 12:13:07 PM UTC+11, Paul Rubin wrote: > > Dennis Lee Bieber writes: > > > Unless things have changed severely -- GE Aviation (formerly Smith's > > > Aerospace, formerly Lear Siegler) produces the 737 FMS software (and = also > > > the processor boxes). > >=20 > > It looks like Collins Aerospace (formerly Rockwell Collins) is now > > getting some heat over the flight deck software: > >=20 > > https://www.nytimes.com/2019/11/07/business/boeing-737-max-collins.html >=20 > Since Boeing manufactured the plane, it's basically their problem - > no matter who they contract to supply parts. Fractional/contributing culpability of suppliers & subcontractors is a key = portion of the USA's legal system. And perhaps more to the point, fraction= al/contributing culpability of suppliers & subcontractors (and the meticulo= us tracking/feedback/transparency thereof) is a key tenant of AS9100 that i= s the mantra (largely driven by Boeing no less) throughout the aerospace in= dustry. > The MAX software might not be the only problem that Boeing will have > with the Max. Well, this is obviously quite true in the MAX since software written in Ada= was being utilized to cover up the fundamental aerodynamic problem of exce= ssive lift by over-powered engines. (Conversely, the software taking input= from a lone single-point-of-failure sensor was unwise, when at least 1 sen= sor was available that could be presented in conflict for human authorizati= on of what to do, and in some configurations 2 sensors that could vote.) > 737 NGs are suffering premature fatigue cracks with the pickle forks - > these are what hold the wings to the body of the aircraft. > These fatigue cracks are occurring after some 30,000 flights, > which is about half of the design life of some 60,000 flights. Another potential symptom of excessive force by engines in the pre-MAX vari= ant, as you note below. > The MAXes have larger and more powerful engines that may stress the > wings more than the earlier engines. This may result in fatigue cracks > appearing even earlier than on the NG's. A not-quite-fully-stated subtext of this thread (and more so in this most-r= ecent posting) is: 1) How much should Ada software engineers & the software management chain t= hereof be merely strictly obedient servants that incompletely/pathetically = cover up hardware problems with software? =E2=80=9CNo null pointer de-refe= rences and impeccable type-correctness when the design is viewed in the sma= ll, but oopsie it still slaughters people by the hundreds at a time when th= e design is viewed in the large without any significant amount of compiler = enforcement of higher-order assurances of correctness.=E2=80=9D 2) How much should Ada software engineers implement software to knowingly r= ead from a singe-point-of-failure sensor when 1 or 2 more sensors are avail= able, just because the specification said to read from =E2=80=9Ca=E2=80=9D = sensor? 3) How much should Ada software engineers have a glorious language, then le= t slipshod topics like this slide outside the language in a not-my-job or a= bove-my-paygrade or contractual-obligation or don't-make-waves attitude? O= r equivalently how much should Ada software engineers allow these things to= be human debates with management instead of moving them within a regime of= compiler enforcement to beat over the head of management to prove manageme= nt or system engineers wrong: hey, look at where your misleadership led, t= o an otherwise irresolvable compile-time error? 4) Indeed, should the Ada programming language and/or Ada's libraries/frame= works/provers present engineering best-practices to the ultimate app-domain= , such as an in-your-face disdain for single points of failure and other ob= vious higher-order brain-fart mistakes or, worse, intentional do-it-anyway = mismanagement from up the chain of command? 5) Couldn't a valid criticism of Ada be: Ada solves the 1975-era software-= quality problem well, but doesn't solve higher-order software-quality (and = system-quality) issues that have become prominent, say, post-1980? Or equi= valently, isn't the tragedy of Ada ultimately not its lack of dominance & l= ack of overwhelming popularity, but rather the most potent tragedy of Ada i= s that it ceased pursuing ever more-immense/aggressive variants of its orig= inally-chartered mission, remaining stunted in solving primarily software-e= ngineering challenges known in, say, 1975 with just more & more icing on th= e same old cake? (I view SPARK as effectively saying this same criticism o= f Ada. I view Rust as even effectively saying that Ada rested on its laure= ls of solving merely even the 1975-era problem too soon.) I have observed = such a false sense of perfection from managers & lead engineers who brag ab= out software written in Ada simply because it was written in Ada and thus i= s naturally high-quality software by definition. Be careful how you answer or dismiss those questions above, because your an= swers might strongly resemble the analogous answers or dismissals that some= portions of the C or C++ community might give to those same questions if t= hey were directed toward C or C++ instead of toward Ada.