Iīll repeat: It is VERY EASY to diagnose UAS before the garbage coming from the Pitotīs destroy the confidence of the crew in the machine.
And it seems airbus SAS had no competence (an absurd approach imho) to implement a better solution. Delegate was natural. Easy, no investment.
And it would be easy, later to blame dead guys.
But,
If the man-machine interface (a good one, assertively) presented a clear indication the history certainly would* be completely different.
Who would ignore or not believe an alarm (garbage coming from the sensors) AND resulting anomalies like degradation.
I insist, F-GZCP had:
1) A ridiculous design WRT UAS (no redundancy)
2) An absurd man-machine interface behavior aggravating a "minor" issue (a brief probes "cold")
Result:
A critical and dangerous System. And the POB of F-GZCP paid it.
(*) Specially if training was developed to this scenario. BTW a
very simple training.
Iīm sorry the way i put. Itīs sad. IMO the accident was designed by Airbus SAS. The victims were the operator (with some % of responsability, obviously) and all POB.
The crew errors (all, like CRM, etc.) occurred
after two very serious design issues.
Technically speaking i repeat: It is very easy to detect the UAS onset. And even to (automatically) disable the subsystems in order to not process garbage and feed it to non properly trained pilots.
Therefore the effective System (plane+crew) could benefit from a non causal approach: Itīs output could occur before itīs input. Why? Because after UAS detection you block the garbage to contaminate the System. A System with several other problems as the recommendations suggest.