Re: Boeing 737 and 737 MAX software

[Optikos <optikos@verizon.net>]

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 <w.....@ix.netcom.com> 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).
> > 
> > It looks like Collins Aerospace (formerly Rockwell Collins) is now
> > getting some heat over the flight deck software:
> > 
> > https://www.nytimes.com/2019/11/07/business/boeing-737-max-collins.html
> 
> 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, fractional/contributing culpability of suppliers & subcontractors (and the meticulous tracking/feedback/transparency thereof) is a key tenant of AS9100 that is the mantra (largely driven by Boeing no less) throughout the aerospace industry.

> 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 excessive lift by over-powered engines.  (Conversely, the software taking input from a lone single-point-of-failure sensor was unwise, when at least 1 sensor was available that could be presented in conflict for human authorization 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 variant, 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-recent posting) is:

1) How much should Ada software engineers & the software management chain thereof be merely strictly obedient servants that incompletely/pathetically cover up hardware problems with software?  “No null pointer de-references and impeccable type-correctness when the design is viewed in the small, but oopsie it still slaughters people by the hundreds at a time when the design is viewed in the large without any significant amount of compiler enforcement of higher-order assurances of correctness.”

2) How much should Ada software engineers implement software to knowingly read from a singe-point-of-failure sensor when 1 or 2 more sensors are available, just because the specification said to read from “a” sensor?

3) How much should Ada software engineers have a glorious language, then let slipshod topics like this slide outside the language in a not-my-job or above-my-paygrade or contractual-obligation or don't-make-waves attitude?  Or 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 management or system engineers wrong:  hey, look at where your misleadership led, to an otherwise irresolvable compile-time error?

4) Indeed, should the Ada programming language and/or Ada's libraries/frameworks/provers present engineering best-practices to the ultimate app-domain, such as an in-your-face disdain for single points of failure and other obvious 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 equivalently, isn't the tragedy of Ada ultimately not its lack of dominance & lack of overwhelming popularity, but rather the most potent tragedy of Ada is that it ceased pursuing ever more-immense/aggressive variants of its originally-chartered mission, remaining stunted in solving primarily software-engineering challenges known in, say, 1975 with just more & more icing on the same old cake?  (I view SPARK as effectively saying this same criticism of Ada.  I view Rust as even effectively saying that Ada rested on its laurels 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 about software written in Ada simply because it was written in Ada and thus is naturally high-quality software by definition.

Be careful how you answer or dismiss those questions above, because your answers might strongly resemble the analogous answers or dismissals that some portions of the C or C++ community might give to those same questions if they were directed toward C or C++ instead of toward Ada.