EASA - "…
an objective to implement a 737 MAX AOA Integrity Enhancement to further reduce crew workload following single AOA failures and to improve the systems reliability, thus alleviating the aircraft architectural AOA-dependency noted previously. "
The requirement is to reduce the effects of several system's dependency on AoA, minimise consequential alerts (distraction, surprise) and crew workload.
A systems view would suggest three AoA inputs with voting 2 out of 3. However, this may be not be an easy task with the 737s old (although digital) dual architecture. e.g. dual air-data system requires comparison, an alerting 'disagree' (between two), and crew to resolve validity with comparison of a third, dissimilar input - StBy ASI / ALT.
A third AoA, real or synthetic, would have to interface with this old architecture, with 'automatic' selection and changeover for EFIS and all other systems. Probably requiring the same format and resolution as the existing AoA input, thence how accurate is the third system.
Alternatively the new input might only be used as a monitor to resolve the dual comparison after the first failure, the aircraft then continuing to operate with one AoA - been there before.
This might not as significant as emotion suggests. If one of the current AoA inputs fail, and is compared and could be isolated with aid of system 3, then the aircraft would be in a similar state as the current 737 mod with MCAS isolated, but possibly fewer alerts and consequences.
The key to this is to appropriate switching logic and alert suppression. In a fully integrated aircraft this should be possible to amend all of the component functions 'in one box' - a systems approach. However, with the 737 'individual box' architecture there could be multiple changes and consequential interface issues, operational problems, and more failure paths - not the objective.
It may be relatively easy to find an additional AoA input, real / synthetic, but its integration very complex.
Also, a reversal of an AoA to speed algorithm, as with EFIS low speed awareness, might not work if the required inputs, Inertial, AirData, etc, already use AoA. Thus if one AoA fails, these inputs may not be sufficiently reliable to compute synthetic AoA - boot strapping.
As with existing dual / StdBy installations, human logic and judgement for resolution is more adaptable than computation; if only this did not come with the baggage of distraction and workload, - around and around we go … …
With gum's sharp mind, yes there is a relevant AF 447 debate in this. Save for later to test alternative views.
From the archives; AoA to Speed.
https://www.dropbox.com/s/ljdhpbsnby...Speed.pdf?dl=0