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

place. Although aviation manufacturers have been paying more attention to SEE inrecent years, it was only recently that formal guidance for such manufacturers wasdeveloped. The major certification authorities have stated that they expectmanufacturers to address SEE hazards during system development processes, butthere are at present no specific regulatory requirements in place. Overall, it wouldseem that more work is required to ensure that SEE is specifically and adequatelyconsidered in the development of all safety-critical aircraft systems.Limitations with built-in test equipmentThe LTN-101 ADIRU was designed so that almost all problems would be detectedand, depending on the severity of the problem, appropriate action taken (such assending a fault message, informing the flight crew, flagging the output data asinvalid, or shutting the system down). The available evidence indicated that theBITE tests functioned as designed during the three data-spike occurrences. Thesetests resulted in the ADIRU flagging the incorrect IR data as invalid and generatingan IR fault. Although no fault messages were recorded, this appeared to be aproblem with the buffering of data within the CPU module rather than the executionof the BITE itself.It was clear that the BITE did not successfully detect and manage the problem withthe ADR data spikes. The unit’s wraparound checks probably detected an ADRproblem and sent a class 2 maintenance message to the central maintenance system(CMS). However, this response was not sufficient to generate a caution message forthe flight crew. In addition, the ADIRU did not flag the ADR data as being invalid.The BITE included output parameter range checking, but the failure mode occurredafter the range-checking tests had been performed. Even if the problem hadoccurred earlier in the processing sequence, most of the data spikes, including theAOA spikes, were within the allowable range and would not have failed a rangetest.Overall, it would not have been practical to test every step of ADIRU processing, asthe BITE complexity would increase substantially, resulting in possible adverseeffects on ADIRU processing performance and reliability. The selection of BITEtests depends on the equipment specification and the safety assessment and otherevaluation activities conducted during the system development process. In the caseof the LTN-101, the FMEA and other system development processes did notidentify the data-spike failure mode, and consequently did not introduce specificmitigators such as BITE tests to manage its occurrence.SummaryThe ADIRU data-spike failure mode occurred due to a combination of some formof trigger event, either external or internal to the unit, with a marginal susceptibilityto that type of event within the CPU module of a limited number of units. Thiscombination caused the ADIRU to enter a state that intermittently disrupted theCPU’s processes for managing the storage and retrieval of temporary data, and theunit’s BITE was not sufficient to detect some aspects of the failure mode,particularly the transmission of data spikes on ADR parameters.Operationally, the LTN-101 ADIRU met the aircraft manufacturer’s equipmentspecification in terms of its overall reliability rate and undetected failure rate.However, the data-spike failure mode had the potential to cause significantdifficulties for other systems, and therefore lessons for preventing or mitigating the- 204 -