Re: Boeing 737 and 737 MAX software

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .