The article summarizes the report a bit badly. With most ADIRU inputs, each flight computer independently samples all three ADIRUs, and takes the median value.

The article summarizes the report a bit badly. With most ADIRU inputs, each flight computer independently samples all three ADIRUs, and takes the median value. It also looks for outliers - if an ADIRU input falls far out of line with the others, the flight computer signals a fault, and disables that input. This can also be done manually. What actually happened is one (of three) ADIRUs started mixing up its outputs - it intermittently labelled altitude data as angle-of-attack data. This happened after internal checks for data consistency, and before CRC generation - exactly how this occurred is a mystery, but it happened without the ADIRU detecting an internal fault. Now, AOA data is measured by multiple independent sensors, and each ADIRU has its own sensor, on different sides of the plane. Because of this, under normal circumstances, AOA data can be somewhat different between the ADIRUs - much more so than the other inputs. Moreover, two sensors are on one side of the plane, and one on the other - making the median method weight one side far more than the other. As such, the flight computer software normally averages the AOA data from all three ADIRUs, but has an error checking system to detect and exclude erroneous data. This system detects when an outlier occurs, after which point it enters a 1.2-second cooldown, in which it uses last-known-good data. 1 second into the cooldown, it rechecks its inputs to see if the outlier remains (and if so kicks it out of the system), and at the 1.2 second mark it resumes normal operation. This error-checking algorithm is supposedly meant to deal with the situation where two ADIRUs are both temporarily bad due to some turbulence on one side of the plane - a fault scenario identified during early testing of the A330. The key thing is, at that 1.2 second mark, it assumes any input that passed the 1-second-mark test is valid. In this event, ADIRU 1's AOA input spiked, triggering the 1.2-second cooldown. It then returned to a normal value for the 1-second-mark test, and then spiked again - at the 1.2 second mark, this invalid data was sampled, the average of all three ADIRUs taken, and a bogus value resulted. Once the spike resolved again, rate-of-change limiting prevented the value from returning to its true value immediately. Note that there's also an independent flight computer monitoring system for each flight computer that only listens to one of the three ADIRUs, cross-checks the control outputs, and has the authority to disable the specific flight computer it's attached to if there is a discrepancy for too long (450ms). This flight control computer monitoring system did work properly, and disabled the flight computers in the end, switching over to manual pitch control via a more primitive, secondary flight control system. However, it took two faults (ie, pitch down events) to do so - one to take out each of the primary flight computers with pitch control authority. In any case, a new error detection algorithm that avoids this issue is currently being distributed as a software update, and in the meantime there are safety bulletins instructing pilots to disable the affected ADIRU manually at the first sign of trouble.