Re: Boeing 737 and 737 MAX software

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

On 19-04-18 19:21 , tranngocduong@gmail.com wrote:
> 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.

I didn't claim that it was helpful, but the fact that the "fix" is 
making it standard rather than optional suggests strongly that the MCAS 
originally used only one AoA sensor, confirming other descriptions of 
the issue.

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

I've read rumours that even if the U.S. FAA lets the fixed 737 MAX fly 
again, other air safety authorities (Europe, for example) might not be 
satisfied, for that very reason -- suspicion that the flight software 
process was at fault.

 From more recent descriptions of the two crashes, it seems that the 
problem also involves complex interaction between MCAS, the enabling or 
disabling of the elevation trim motors, restarts of the control 
computer, and the fact that manual correction of the elevation trim 
becomes impossibly hard when the MCAS-commanded large "dive" trim 
applies large aerodynamic forces to the trim mechanism. Thus the problem 
was not only in the software process, but also in the controllability of 
the aircraft under anomalies -- a chain of failures, as typical for 
accidents.

>>> b) Contrary to general belief, the software was not programmed
>>> with multiple redundant computation. Simply: process failure.

    [snip]

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

The suspicion involves Boeing sliding down two slippery slopes, as I 
understand it:

1) For MCAS in particular, its control authority was greatly increased 
from its first design to the flying version, but this was not propagated 
into a new consideration of its criticality.

2) For the process in general, an increasing complacency ("we know how 
to do it") and increasing delegation of checks from the FAA to Boeing 
(and other airplance builders), combined with specific driving forces 
for 737 MAX (urgency + desire to avoid pilot retraining).

I am reminded of the Space Shuttle O-rings... and perhaps also of the 
scandals with automotive SW hiding emissions, leading to multi-billion 
losses for the guilty European companies...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .