Re: Boeing 737 and 737 MAX software

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

On 19-04-06 20:30 , Dennis Lee Bieber wrote:
> On Fri, 05 Apr 2019 14:16:20 -0700, Paul Rubin <no.email@nospam.invalid>
> declaimed the following:
>
>> Does anyone know anything about this?  It has been under some criticism
>> lately.

As I've read more about these accidents than I usually do, I will boldly 
(and perhaps foolhardily) describe how I have understood it. All info is 
from public sources, I have no insider info. I am not a pilot, and 
moreover I write from recollection of my reading and have no references 
to give, so reader beware.

>> I have heard that the 777 software was almost entirely in Ada.  It also
>> sounds as if Boeing's software operation may have slipped in recent
>> years, not good news for the 737 MAX.
>
> 	Unless things have changed severely -- GE Aviation (formerly Smith's
> Aerospace, formerly Lear Siegler) produces the 737 FMS software (and also
> the processor boxes).
>
> 	However, I have the impression (from TV news) the software is
> functioning /as designed/.

All info I have seen agrees with that.

> Some reports have indicated that Boeing designed
> the hardware (and corresponding software requirements) such that only one
> sensor is used for the MCAS subsystem

The are two angle-of-attack (AoA) sensors, one on each side of the nose. 
They feed two redundant computers, each able to run MCAS. Normally only 
one MCAS instance is running and it uses only its "own" AoA sensor.

The original design of MCAS gave it rather little control authority, 
which is probably why this single-sensor approach was accepted.

> -- and a fault in that sensor results
> in MCAS attempting to prevent a (non) stall by pushing the nose down.

Yes, but MCAS does not apply a temporary nose-down command -- as if 
pushing the stick forward -- it changes the pitch trim, the overall 
angle of the horizontal stabilizer, giving the plane a permanent 
tendency to dive. This trim change can be overridden by the pilots, but 
only if they notice that it has happened.

In the original MCAS design, one activation of MCAS changed the pitch 
trim by a small amount, at most 0.6 degrees IIRC, and this limit was 
reported in the MCAS design documentation to the authorities. During 
testing, Boeing found that it was not enough, and they increased it 
quite a lot, to over 2 degrees IIRC. One source I read claimed that this 
change was _not_ updated in the documentation shown to the authorities.

Moreover, by design MCAS would repeat this trim change, with a certain 
minimum interval, as long as the AoA sensor reading remained too large 
and indicated a risk of stall. This iteration should converge and stop 
if the sensor is working, but if the sensor fails and is stuck at a high 
AoA (the false value reported in the second accident was around 60 
degrees, IIRC) then MCAS will incrementally and cumulatively keep 
increasing the pitch trim and the diving tendency. If the pilots do not 
understand what is happening, they will find it ever harder to 
counteract the "dive" trim with stick inputs.

> Some
> hints in the news that Boeing is changing the requirements (well, in truth,
> the news only says Boeing is changing the software) to have MCAS
> cross-reference with other flight parameter data -- and making an optional
> bit of hardware (additional sensors) standard.

AIUI the modifed MCAS will read both AoA sensors and will disable itself 
if they disagree, and the disagreement will also be reported by a 
display. This display is the new piece of HW which used to be an option. 
There are no new sensors, AIUI.

I believe Boeing are also changing the minimum interval between MCAS 
activations -- perhaps even allowing only one activation -- so as to 
prevent a cumulatively increasing "dive" trim.

In summary, it seems to me that the criticality of MCAS, and thus the 
need for redundant sensors, was not realized for two reasons: (1) in its 
initial design, MCAS command authority was small, and (2) the 
possibility of multiple repeated commands (due to a stuck sensor) and 
the resulting large cumulative command (large change of pitch trim) was 
not considered.

A kind of "criticality creep".

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