Serious Software problem
I think everyone is missing the point.
The problem is not that the ADIRU 1 sent "erroneous and spike" values. ADIRUs are known to fail occasionally, that's one of the reasons why there are several of them.
This is evidence of a serious flaw in the Airbus FBW control software in the A330/A340 PRIMs (Flight Control Primary Computers).
Spike filtering is essential, and "the manufacturer advised" that there was "an issue" with the software, in which AoA spike values could be passed on to the control algorithms in certain conditions.
It is not unexpected to people involved with high-reliability software for safety-critical systems that it appears to be a requirements/specification problem.
There is a temporal sequence of AoA spike values (I will call it "Critical Spike Value Sequence", CSVS) from the ADIRUs that will get past the spike filtering and be interpreted by the flight control/envelope protection algorithms as real values.
It appears that the software develeopment process at Airbus is not quite what it should be.
Either the algorithms were specified incorrectly and the emergence of CSVS is inherent in the algorithm, or the algorithm was implemented incorrectly, and the emergence of CSVS is an artifact of implementation issues (coding/compiler/linker/hardware). According to the report, Airbus identified a problem with the algorithm, so that points to the first alternative.
Either way it is a strong case for the need to use formal methods for both requirements elicitation, ensuring their completeness
and adequacy, and for implementation, using state-of-the-technology "Correct-by-Construction"-methods.
Bernd