QF72: How could a disconnected autopilot change the pitch?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.