I’ve just finished reading the ATSB’s second interim report on the the QF 72 in flight upset that resulted in two uncommaned pitch over events (1). In this accident one of the Air Data Inertial Reference Units (ADIRU) provided erroneous data in the form of transient spikes vales of the angle of attack AoA parameter to the flight control computers which then initiated two un-commanded extreme pitch overs.
This post is part of the Airbus aircraft family and system safety thread.
To date the comprehensive technical investigation carried out by the ATSB has not determined the root cause of the spikes. However ADIRU1 also generated spikes in other flight parameters that were recorded by the Flight Data Recorder (FDR). Which is where the story starts to get interesting. As per the first ATSB report (ATSB 2008) the full set of affected ADIRU outputs were:
- angle of attack (AoA) (ADR),
- pressure altitude (ADR),
- computed airspeed (ADR),
- mach number (ADR),
- static air temperature (ADR),
- pitch angle (IR),
- roll angle (IR),
- wind speed (ADR)+IR), and
- wind direction (ADR+IR).
At first glance that’s a dizzying number of flight air data and attitude parameters exhibiting anomalous values, especially if we naively presume that they are independent. But in modern air data systems few parameters are truly independent. A classic example of this dependency is the use of AoA and mach parameters to compensate measured static and dynamic air pressure. Subsequent calculations of mach, static air temperature and so on all depend on these basic pressure parameters so for example an error in AoA can potentially cause subsequent downstream processing errors (2).
In the case of mach, mach is itself derived from the ratio of impact and static pressures which means that some form of an iterative algorithm must be used. The air data process also needs to handle the case where a solution does not converge, normally by computing a raw mach value for use in subsequent pressure compensations.
Software temptations are virtually irresistible. The apparent ease of creating arbitrary behavior makes us arrogant. We become sorcerer’s apprentices, foolishly believing we can control any amount of complexity. … We would be better off if we learned how and when to say no
G.F. McCormick, When Reach Exceeds Grasp
So a spike value in AoA could notionally affect a range of other air data parameters, depending on where in the processing cycle it occurred, it’s magnitude, duration and how it interacted with any onboard reasonableness checks. The ATSB noted that the spikes appeared to be random and occurred for different parameters at different times but the interaction of processing cycles, AoA (or another parameter) spikes and onboard error detection gives (IMO) at least a plausible explanation for such behaviour.
This of course leaves the pitch and roll parameters generated by the Inertial Reference Unit. Puzzling, as the IRU uses a strap down ring laser gyro to generate these parameters, not air data. However even for the IRU air data plays a part in calculating flight parameters, specifically barometric altitude is used to stabilise the IRU vertical acceleration calculation. If other air data is used by the IRU to stabilise other calculations then we again have a plausible explanation for these IRU failures.
Taking a broader view integrated architectures, such as modern ADIRU’s, have a nasty habit of introducing interaction type hazards which are difficult to anticipate during design. The more we integrate the greater the unanticipated risk, when things go wrong in an unanticipated way.
ATSB Transport Safety Report, Aviation Occurrence Investigation, AO-2008-070 Interim Factual No. 2 Report on in-flight upset 154 km west of Learmonth, WA 7 October 2008, VH-QPA Airbus A330-303.
ATSB Transport Safety Report, Aviation Occurrence Investigation, AO-2008-070 Interim Factual Report on in-flight upset 154 km west of Learmonth, WA 7 October 2008, VH-QPA Airbus A330-303.
BEA, Interim report no. 2, on the accident on 1st June 2009, to the Airbus A330-203, registered F-GZCP, operated by Air France flight AF 447 Rio de Janeiro – Paris, Report Number f-cp090601ae2, November 2009.
1. Mea culpa, I missed the second report when it was first released.
2. See BEA’s second interim report (BEA Nov 2009) p 48 and 49 for further details of Airbus’ implementation.