Ethiopian airliner down in Africa

[FCeng84]

Originally Posted by VicMel

FCeng84 - Excellent comments on the ‘bigger picture’ of the problem. You refer to “the elephant in the room”, this does not only apply to MCAS. Some years ago when I was an aviation safety assessor, shortly after the loss of AF447, it became clear to me the premise that ADU TAS output is not a ‘safety critical’ parameter was a badly flawed concept. The approach of suppliers and the aviation authorities was that TAS was only ‘advisory information’ and that incorrect data would be handled by ‘good airmanship’. It is ‘obvious’ from AF447 and three other incidents I am aware of, the probability that pilots can always safely deal with bad Air Data is not high enough to mitigate the ADS to be not a safety critical system. Sadly this elephant is still hidden away, for now.

The same flawed argument now seems to being applied to AoA with MCAS. I am only aware of three cases of the MCAS not working correctly, in only one case did the crew manage to safely deal with the situation. The real hard evidence suggests that a significant proportion of pilots (somewhere between 10% and 90%) would not be able to cope. From what I understand about MCAS from the Pprune posts, I would expect this probability of pilots failing to cope would need to be of the order of 0.1% (or lower) in order for the MCAS to be considered as not safety critical. IHO, only a basic understanding of Human Factors is needed to show that the MCAS safety assessment is fundamentally flawed. This is the elephant in the room, Boeing might perhaps try to hide it with a software patch, but it will still be there.

The software patch looks inadequate to me for the following reasons:-
A) Quote from https://www.seattletimes.com/busines...ion-air-crash/
“According to a detailed FAA briefing to legislators, Boeing will change the MCAS software to give the system input from both angle-of-attack sensors. It will also limit how much MCAS can move the horizontal tail in response to an erroneous signal. And when activated, the system will kick in only for one cycle, rather than multiple times.”
I find this quite disturbing:-
i) They seem to have ‘defined’ the software patch before they even know the cause.
ii) How does having both inputs help if one of them is ‘erroneous, but believable’?
iii) Presumably the software would have be set to be cautious and use the higher (potentially wrong) value?
iv) MCAS was originally designed at its current limits in order to counteract a known problem. Presumably lowering the limits mean that more ‘real’ problems will not now be safely dealt with.

B) There may well be failure modes other than the AoA vane that need to be considered. From https://leehamnews.com/2018/11/07/bo...-air-accident/ the Alpha Vanes input to the ADIRUs, presumably there they are at least A to D converted. Are the (non-safety critical) ADIRUs a potential source of failures?

C) From The Seattle Times report, the MCAS was not considered to be a Level 1 safety critical system, so presumably the software was not designed, developed and tested to Level 1 standards. In which case, a software failure within the MCAS has to be considered as a feasible cause of the MCAS’s undesirable behaviour.

Considering your points A to E on the future of aviation safety: I fear the aviation industry is approaching a ‘perfect storm’ dilemma:
a) aircraft are becoming more complex, even Boeing consider that “average” pilots cannot cope with the workload of extra information about MCAS
b) air traffic is increasing and new aircraft designs are ‘down-sizing’ as smaller aircraft are more cost effective; this means many more new, inexperienced, pilots will be needed
c) it is not possible to train pilots such that they all become ‘super Sulleys’.

My conclusions are:-
a) systems must no longer use human intervention as part of their safety case; we are too unpredictable.
b) safety critical systems must get smarter; garbage in, garbage out is not an option, neither is giving up and disconnecting.

VicMel - I really appreciate your thoughtful response. I sense that overall you and I are on the same page. Please allow me to provide a few inputs on your points:

A i) The update in work by Boeing is in response to the Lion Air accident, not the Ethiopian accident. Hopefully we will know more about the Ethiopian accident soon and only then will it be possible to determine if this same update would have helped lead to a better outcome in Ethiopia.
A ii) It seems that the proposed update will disable MCAS if the two AOA vanes do not track each other sufficiently. The severity of the degradation in handling qualities without MCAS must be minor enough to allow for this reduction in MCAS availability. Boeing must be assuming some probability for an AOA sensor failure and then showing that it is acceptable to turn MCAS off twice as often as a failure of either AOA sensor would lead to MCAS shut down.
A iii) No MCAS when AOA vanes do not track. See A ii above.
A iv) I doubt that we will find that the MCAS update reduces the size of a single increment of MCAS stabilizer motion. I can't imagine that Boeing would have given this function any more authority than absolutely needed to meet FARs and thus there is probably no room to reduce its single increment authority.
C) MCAS is implemented within the FCC within the same software that controls other automatic stabilizer control functions such as offload when A/P is engaged and STS. This code already required to be designed to high standards.
Conclusion a) We may need to rely less on critical crew action, but there must be some base level that can be counted upon. I suggest at least:
- RTO for engine out below V1
- Pull for takeoff somewhere near Vr
- Gear and flap management and coordination with associated speeds throughout flight
- Comply with ATC guidance
- Ability to navigate to destination
- Ability to capture and follow glideslope and localizer to runway and command landing flare
- Recognize unstable approach and execute go-around
- Sorry for the length of this list. My point is that there are many pilot actions we count on to maintain safe operation
Conclusion b) I fully agree and suggest adding that if the inputs are garbage the system should be robust enough to maintain safety.