In-flight upset - 154 km west of Learmonth, WA, 7 October 2008,

The ADIRU’s response to a detected fault depended on the nature of the fault, butusually involved isolating the affected function(s), sending a fault message to theflight warning system (FWS), sending a fault message to the central maintenancesystem (CMS), and flagging any affected parameters with an invalid SSM.The BITE tests were performed during initialisation of the system (power-on) andmost were performed continuously during normal operation.BITE information was designed to be recorded in non-volatile memory so that itcould be analysed if required. In addition to fault detection, the BITE also storedroutine maintenance information, such as system temperature, time in operation,inertial alignment records, flight leg records, instrument trends, and navigationupdates and performance.3.7.2 Flight data parameter testsThe investigation reviewed the tests that were conducted by the ADIRU on theflight data parameters to determine if any of the tests could have detected the dataspikefailure mode. The most relevant tests were the range tests conducted on manyof the parameters prior to them being transmitted to other systems. The availableevidence showed that these range checks were working correctly, with groundspeedclamped to 1,000 kts and computed airspeed set to 0 kts when the speed reduced toless than 30 kts (section 3.4.3). No other reasonableness checks were performed onthe output data, nor were they required in the aircraft manufacturer’s specification.Other tests were also conducted on various parameters. For example, testsconducted on AOA values were:• AOA integrity monitor. When Mach was greater than or equal to 0.75, and withthe aircraft straight and level (determined using two IR parameters), thecorrected AOA was compared to the pitch attitude. If the difference betweenthem was greater than or equal to 0.6°, a class 3 maintenance message wastransmitted to the CMS. No such messages were recorded during the data-spikeoccurrence flights. However, after the data-spike failure mode was initiated, theIR parameters were flagged as invalid (section 1.11.3), which would haveinhibited the operation of this check. In any event, a class 3 fault would notresult in a warning or caution message being provided to the flight crew(section 1.6.10).• Air data sensor input comparison monitor. During takeoff, each ADIRUcompared its air data parameters, including indicated AOA, with the values fromthe other two ADIRUs using information shared across the digital air datasystem (DADS) buses (section 1.12.6). For AOA, if the difference between theindicated AOA values exceeded 3°, then a class 2 maintenance fault messagewas generated. The test was not conducted when the aircraft was airborne.In common with the AOA checks, none of the specific tests that were conducted forthe other ADR flight data parameters would be expected to generate a warning orcaution message to the flight crew in the event of a data-spike occurrence.There were many tests on IR parameters that, had one failed, would have resulted inthe IR parameters being flagged as invalid. For example, the output range monitorfor groundspeed would flag IR parameters as invalid if groundspeed exceeded therange-limit value of 1,000 kts. The QAR data showed that groundspeed hadexceeded 1,000 kts and been clamped to that value (section 1.11.3). As BITE data- 152 -