Re: Boeing 737 and 737 MAX software

[tranngocduong@gmail.com]

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 
> 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).
> 
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 limited knowledge, AoA is a critical parameter that is used by many flight control algorithms, not just the MCAS. The real issue is thus the failure to detect an unreliable sensor. If the failure was a "feature, not bug", the entire 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).
> 
>  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).
> 
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 
> 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

I know. SPARK and ParaSail do not allow exceptions for a reason. But because the MCAS was [mistakenly] classified as a non-critical component, programmers may choose to use less formal/rigorous methodology, which give rise for constraints and exceptions if Ada was selected.