Qantas Flight 72 When the system reacted correctly to something that wasn’t real

Qantas Flight 72 experienced two uncommanded pitch-down events at cruise altitude when a faulty Air Data Inertial Reference Unit (ADIRU) transmitted false angle of attack spikes to the aircraft’s flight control computers. The computers, receiving data indicating an imminent stall, activated the pitch-down protection — exactly as designed. The data was false. The protection was real. The aircraft pitched down violently, injuring 110 people.

QF 72 is the case study that demonstrates one of automation’s most dangerous failure modes: a system responding correctly to false sensor data. The flight computers did not malfunction. They received an AoA spike and they responded to it. The problem was in the ADIRU that generated the spike — a problem with no history, no known failure mode, and no available diagnostic or protection.

The A330’s flight computers did exactly what they were designed to do. They received an AoA spike indicating an impending stall and they pitched the aircraft down to recover. The spike was false. The protection was real. One hundred and ten people were injured by a system doing its job correctly on bad data.

apibus leo.

Date	7 October 2008
Flight	QF 72
Aircraft	Airbus A330-303
Operator	Qantas Airways
Fatalities	0 — 110 injuries (12 serious)
Category	ADIRU Fault / Uncommanded Pitch-Down / Sensor Failure / Automation
Location	Near Learmonth, Western Australia

The Event

QF 72 cruises at FL370 en route from Singapore to Perth in cruise conditions
7 October 2008: The Number 1 ADIRU (Air Data Inertial Reference Unit) begins generating intermittent, spurious AoA and inertial reference spikes
At 12:40, the flight control primary computers receive an AoA spike from the faulty ADIRU
The computers interpret the spike as an impending high-AoA event and command a nose-down pitch
The aircraft pitches down approximately 8.4 degrees without crew input
Passengers and crew not seated or secured are thrown against the cabin ceiling
The crew regains control; 57 people are injured in the first event
A second, smaller pitch-down occurs approximately 70 seconds later; 53 further injuries
The aircraft diverts to Learmonth Airport; all 315 on board survive

The investigation found that the Number 1 ADIRU had experienced an internal hardware failure that produced the spurious AoA spikes. This specific failure mode had not been previously identified or documented. CASA and Airbus issued modifications to the ADIRU software to improve fault detection.

Systems Engineering Perspective

From a systems engineering perspective, QF 72 is the false data input problem at its purest: a correctly-functioning protection system responding appropriately to incorrect sensor data, producing an undesired and hazardous output.

A protection system that responds correctly to false sensor data is not malfunctioning. It is functioning exactly as designed. The failure is in the sensor and in the system’s inability to distinguish true AoA exceedances from false ones.

ADIRU Fault — A Novel Failure Mode

The Air Data Inertial Reference Unit is a safety-critical avionics component that provides angle of attack, airspeed, altitude, and inertial reference data to the aircraft’s flight control computers. The A330 carries three ADIRUs. The primary computers use a voting system to compare data from multiple sources and reject outliers.

The specific failure mode on QF 72 — periodic, large AoA spikes from one ADIRU — had not been previously identified or characterised. The voting system had thresholds designed to reject obvious outliers. The spike values generated by the failed ADIRU fell within a range that was large enough to trigger the protection logic but not so large as to be immediately rejected by the voting algorithm. It was in the gap between ‘normal’ and ‘obviously wrong.’

Sensor failure modes that produce values in the range between ‘normal’ and ‘obviously wrong’ are the most dangerous. They pass through voting algorithms and trigger protection systems on false data.

The Pitch-Down Protection — Correct Function, Wrong Data

The Airbus A330’s high-AoA protection is designed to prevent an aerodynamic stall. When the flight control computers receive an AoA value above the protection threshold, they command a nose-down pitch — reducing AoA and increasing airspeed. This protection has saved aircraft. On QF 72, it pitched the nose down 8.4 degrees in response to data that did not represent the aircraft’s actual flight state.

The protection worked. It worked on false data. The result was 110 injuries.

The Crew Response — Managing Without Understanding

The first pitch-down event gave the crew no warning and no indication of cause. They had no alert that told them ‘ADIRU 1 is generating false AoA data.’ They had an aircraft that had pitched down without their input. They applied the abnormal procedure, reduced airspeed, and prepared for further events. When the second event occurred, they were better positioned. The diversion to Learmonth was executed professionally.

Human Factors Perspective

The human factors analysis of QF 72 focuses on the crew’s management of an event with no available diagnosis and on the systemic question of how a crew manages automation that is behaving unexpectedly when the reason for the unexpected behaviour is not available.

Managing Without Diagnosis

The QF 72 crew had no means of diagnosing the ADIRU failure from the flight deck. The fault was internal to a black box avionics unit. The crew’s response — reducing speed, securing the cabin, preparing for further events, diverting — was exactly correct without knowing the cause. They managed the symptoms because they could not manage the cause.

When diagnosis is not available, symptom management is the only tool. Crews must be trained to manage abnormal automation behaviour without requiring diagnosis of the underlying cause.

Airbus and ATSB Investigation — Identifying the Novel Failure

The ATSB investigation — one of the most technically complex in Australian aviation history — required detailed analysis of ADIRU internal data to characterise the failure mode. The investigation eventually produced modifications to ADIRU fault detection software that improved the system’s ability to identify and reject the specific failure mode encountered.

System Interaction Breakdown

1. ADIRU Fault in the ‘Gap’ Between Normal and Obviously Wrong

The AoA spike values were large enough to trigger protection but not large enough to be immediately rejected. They fell in the gap that voting algorithms leave between ‘normal’ and ‘reject.’

2. Protection System Responding to False Data

The pitch-down protection was correctly functioning. The data driving it was false. The system had no means of distinguishing the two.

3. No Cockpit Indication of ADIRU Failure Mode

The crew had no specific alert identifying the ADIRU as the source of the anomalous behaviour.

QF 72 demonstrates that protection systems are only as good as the data quality of the sensors driving them. Sensor validation and fault isolation are as important as protection logic design.

Significance in Aviation Risk

1. ADIRU Software Modification

Airbus and the ADIRU manufacturer developed and issued software modifications improving fault detection sensitivity for the specific spike failure mode identified in QF 72.

2. Sensor Validation Architecture

The accident drove review of the sensor voting and fault rejection architecture for safety-critical avionics inputs, with attention to the ‘gap’ failure modes between normal and obviously-wrong sensor values.

3. Crew Procedures for Unexplained Automation Behaviour

The accident contributed to the development of crew procedures for managing unexplained, sudden automation-driven attitude changes — including immediate manual takeover and reduced airspeed protocols.

Closing Perspective

Qantas 72 is the proof that a protection system functioning correctly on false sensor data is not a safe protection system — it is a hazard delivery mechanism. The computers did exactly what they should do on an AoA spike. The spike was not real. The pitch-down was.

The ADIRU modification that followed addresses the specific failure mode at the sensor level — improving the system’s ability to identify and reject the spike pattern before it reaches the protection logic. That is the correct engineering response: fix the sensor validation, not the protection.

QF 72 established that sensor validation is as safety-critical as protection logic. A protection system is only as safe as the data it acts on.