[SystemSafety] "FAA chief '100% confident' of 737 MAX safety as flights to resume"

Olwen Morgan olwen at phaedsys.com
Mon Nov 30 21:19:19 CET 2020


On 30/11/2020 19:36, Kinalzyk, Dietmar AVL/DE wrote:
> Olwen
>   I made a Problem based learning session with my students, that's why I studied the causes intensively.
> MCAS was introduced to correct the nose up tendency of Boing 737 Max after lifting up the bigger engines (avoid hazard to stall). Bigger engines have less fuel consumption. This was necessary because Airbus did it before but without change of the relation of wings to engine.
> Here is a demonstration video:
> https://youtu.be/H2tuKiiznsY
>
> If you want to read the Aircraft Accident Investigation Report of KOMITE NASIONAL KESELAMATAN TRANSPORTASI REPUBLIC OF INDONESIA, Boeing 737-8 (MAX); PK-LQP
> Tanjung Karawang, West Java, Republic of Indonesia:
> https://www.flightradar24.com/blog/wp-content/uploads/2019/10/JT610-PK-LQP-Final-Report.pdf
>
> It is amazing how many causes are coming together to this disaster.

Thank you. I reproduce here a section of the Indonesian report - Clause 
3.1 (13):

"13. In the event of MCAS activation with manual electric trim inputs by 
the flight
crew, the MCAS function will reset which can lead to subsequent MCAS
activations. To recover, the flight crew has 3 options to respond, if one of
these 3 responses is not used, it may result in a miss-trimmed condition 
that
cannot be controlled."

This, I believe, bears out my point that, considered with respect to the 
phase-space of the airstream/airframe/pilot/flight-controls, the system 
IS potentially unstable, in that there is a feasible and reasonably 
foreseeable sequence of control events in which pilots will lose control 
of the aircraft. In introducing MCAS to control one form of instability, 
Boeing has *created* other forms of instability. That is typical of the 
kinds of risks that are introduced when the physical design does not 
have all the desired dependability properties and you fix it with 
software used like sticking-plaster.

PBL and others can balkanise their definitions of stability as much as 
they like with respect to subspaces or dimension-reducing projections of 
the the airstream/airframe/pilot/flight-controls phase space. In so 
doing they miss the point that some such balkanised definitions obscure 
the forest by hiding it behind trees.

  As Michael Jackson's blog points out by quoting some of Perlis' 
aphorisms: Devices have users. Systems have participants. Therein lies 
the nub of the problem of what are useful and what are less useful 
definitions of stability. The more balkanised and the less holistic your 
definitions and design processes are, the more you risk introducing the 
possibility of unintended trajectories through the relevant phase space.


(Doubtless PBL will still claim I'm being deliberately obtuse ... but WGAF?)


Olwen







More information about the systemsafety mailing list