So I was reading about flight QF72, where the A330 had incorrect sensor data. The aircraft automatically pitched the nose down twice in response to abnormally high incorrect angle of attack data, but it did so AFTER the autopilot was disengaged. (See https://www.atsb.gov.au/media/51218/AO2008070_interim.pdf page 16-17).

How is that possible? Isn't it the autopilot that does that? I am probably getting the wrong idea about what the autopilot does, right?

Also, what would be the idea behind why the pilots attempt to correct the situation by pulling back the sidestick be unsuccessful at first, but suddenly have the desired effect right after he stopped giving that input?


3 Answers 3


The A330 has a degree of automation that can't be turned off, as part of its 'fly by wire' system.

This is to say that the pilot's controls aren't directly connected to the control surfaces. They are electronic in nature, sending signals to a controller which then decides how much to move the control surfaces.

As part of that, an automatic feature is built in to prevent the aircraft from entering flight attitudes that could be dangerous. This safeguard detects unsafe flying conditions using input from the the Air Data Inertial Reference Unit (ADIRU).

In the QF 72 case, a fault in the #1 ADIRU led it to believe that the aircraft was in a 50 degree nose up attitude, so it automatically forced the nose down. Problem was... the aircraft was flying straight and level, so the result was a very sharp nose down attitude, with negative G's applied to to the cabin (and everyone in it). Anyone not strapped in was slammed into the ceiling, and then into the floor when QF72 recovered from the dive. (only to do it again)

In this case, it wasn't a faulty AOA sensor, but a faulty ADIRU, which appears to have hit an unforeseen combination of inputs... and an unfortunate combination of data and timing that led the Flight Control Primary Computer that actually runs the control surfaces to not figure out that ADIRU 1 was giving it faulty data.

A couple of months later, QF71 encountered the same problem. Fortunately, the pilot was familiar with the QF72 incident, and simply switched the FCPC from the faulty ADIRU 1 to the backup ADIRU 2 that wasn't experiencing a problem. The flight continued without incident.

So the issue wasn't really a faulty AOA sensor, it was faulty code in both the ADIRU and FCPC, which appear to have been triggered by a rare combination of ordinary circumstances.

Note that a frozen angle of attack sensor and consequent incorrect automation responses led to the crash of XL 888, on an acceptance flight when the A320 was due to be returned to Air New Zealand after a lease.

  • 1
    $\begingroup$ The automation can actually be turned off, but doing so requires disabling all of the flight-control computers and dropping the aircraft into mechanical law. $\endgroup$
    – Vikki
    Oct 23, 2019 at 22:43
  • 1
    $\begingroup$ Actually they disable all but one computers to drop to alternate law without any protection. $\endgroup$
    – Manu H
    Mar 11, 2020 at 13:24
  • $\begingroup$ Ad XL888 there was simply no response, because the frozen sensors didn't provide the data and the problem was that the crew was testing the response at altitude where they didn't have enough to recover when the response didn't occur. $\endgroup$
    – Jan Hudec
    Mar 11, 2020 at 19:59

I do agree with the general layout of the previous answers, I am just adding details.

Once the autopilot disconnects, the fly by wire FBW will control the flight surfaces.

If the stick is at neutral position fundamentally the FBW will maintain a « load factor » of « 1 ». Nevertheless the flight envelop will provide an alpha (AOA) protection as well a pitch protection. These protections might have cumulative protection effects

Unhappily in our case it was not a single sensor fault but an ADIRU1 fault with spikes in the following several parameters:

Spikes24 from ADIRU 1 were evident in the following parameters: • angle of attack • pressure altitude • computed airspeed • mach number • static air temperature • pitch angle • roll angle • wind speed • wind direction. The spikes appeared to be random in nature and occurred for different parameters at different times.

The ADIRU1 fault was not permanent, the very short spikes prevented the PRIMs to stop considering ADIRU1 data, because the discrepancy between every 3 similar parameters should remain at least for more than 1 second, while the spikes were very narrow, they were occurring in between the sampling period of discrepancy research.

As a consequence the spikes of the erroneous data transmitted by the faulty ADIRU concerning the AOA and the pitch angle produced the cumulative effect of the protections, however the erroneous pitching down protection durations was short and intermittent thus allowing the pilots to correct the aircraft attitude. Once ADIRU1 has been switched off everything went ok.


How is that possible? Isn't it the autopilot that does that? I am probably getting the wrong idea about what the autopilot does, right?

There are 2 different systems involved in this question:

  • The autopilot
  • The anti-stall system

The autopilot's role is to keep an altitude and a heading or to follow a route.
The anti-stall system's role is to prevent stalling.

In this incident, the anti-stall system was fed with incorrect data from sensors and decided that the plane needed to be pitched down to prevent stalling and did exactly that. The autopilot has nothing to do with this action.

Also, what would be the idea behind why the pilots attempt to correct the situation by pulling back the sidestick be unsuccessful at first, but suddenly have the desired effect right after he stopped giving that input?

The report states (emphasis mine):

The captain reported that he applied back pressure on his sidestick to arrest the pitch-down movement. He said that initially this action seemed to have no effect, but then the aircraft responded to his control input and he commenced recovery to the assigned altitude.

The pilot did not stop to give that input. The plane just did not immediately respond to it. The reason is probably that the anti-stall system was overriding his input. According to the table on page 17, the Flight control primary computer switched from PRIM 1 to PRIM 2 on the first occurence, then from PRIM 2 to PRIM 1 on the second one, each time just before the plane started to respond to the sidestick again. This could explain the delay between input and response.

enter image description here

  • $\begingroup$ I remember reading about the cause, and it is most interesting (cosmic rays flipping a bit). $\endgroup$
    – user14897
    Jun 6, 2019 at 16:02
  • $\begingroup$ @ymb1 that would explain why the peaks where not filtered out before being fed to the computer. $\endgroup$
    – Quentin H
    Jun 6, 2019 at 16:03
  • 2
    $\begingroup$ @ymb1 I'd hesitate to jump to that conclusion, as no one is entirely sure why the ADIRU failed without flagging the failure, and there are other places to put blame like the bad validity and safety checks. The official report does note concerning SEE's that "The LTN-101 air data inertial reference unit (ADIRU) model had a demonstrated susceptibility to single event effects" and "the neutron fluxes for the three occurrences were at around the normal levels, [yet] this still meant there were a significant number of particles present" $\endgroup$
    – Cody P
    Jun 6, 2019 at 17:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .