Why aren't angle-of-attack data sanity-checked before being fed to other aircraft systems?

Question

For most fixed-wing aircraft, accurate angle-of-attack information is utterly essential for safe flight, due primarily to the risk of stalling the aircraft if the AoA of one or both of its wings becomes excessively high (an additional concern which arises at very high speeds is the possibility of causing an over-g, potentially resulting in structural failure);¹ as a result, all airplanes have some form of attack-angle sensor (typically a mechanical vane which aligns itself with the ambient airstream²) which feeds AoA data to the airplane's other systems (usually via the airplane's air-data computers).

Unfortunately, the indispensability of accurate attack-angle data means that, if the AoA data fed to other aircraft systems is not accurate, very bad things happen. This has caused numerous accidents:

• TW843 (L-1011-1, 30 July 1992) - The aircraft's right-hand angle-of-attack sensor, a known temperamental component, failed completely during the beginning of pre-takeoff taxi at JFK, freezing in a position corresponding to an AoA of 26.1° (an angle of attack which is physically impossible for an L-1011 to assume when all of its wheels are on the ground) throughout the aircraft's taxi and takeoff.^4,5 This resulted in a false stall warning sounding as soon as the aircraft lifted off,⁶ leading to a very-high-speed rejected takeoff, excessively-hard touchdown, and runway excursion; structural damage incurred during touchdown resulted in a fire which destroyed the aircraft (although all 292 occupants survived).
• QF72 (A330-300, 7 October 2008) - During cruise over the eastern Indian Ocean, one of the aircraft’s three ADIRUs suffered a glitch which corrupted (to a greater or lesser extent) all of the parametric data computed and passed on by same; although this affected measurement and computation of many different aircraft parameters, the important part, for the purposes of this discussion, was that the AoA values transmitted by the malfunctioning ADIRU were contaminated by intermittent (but frequent) spikes to 50.625° (as well as, later on, some spikes to 5.625° or 16.875°), which caused the aircraft’s flight-envelope-protection systems to trigger two large nose-down elevator movements about two-and-two-thirds minutes apart (each time momentarily locking out the pilot’s compensatory nose-up control inputs) in response to a nonexistent stall condition, resulting in numerous severe injuries among the passengers and cabin crew (although all 315 occupants survived).
• JT043 / JT610 (737-8, 28-29 October 2018) - During turnaround maintenance at Denpasar on the first day, the aircraft's left-hand AoA sensor was removed due to recurrent malfunctions and replaced with one that had been in storage since being refurbished a year previously. The replacement sensor proved to have been improperly calibrated during refurbishment, causing it to read 21° higher than the aircraft's actual attack angle; the bad data from the sensor caused the aircraft's stickshaker to activate almost immediately after liftoff on the subsequent flight to Jakarta (it remained on for the remainder of the flight), and, more seriously, interacted with a poorly-designed modification of the aircraft's autotrim system in such a way as to cause the aircraft's horizontal stabiliser to run away in the nose-down direction, resulting in serious control difficulties until the flightcrew were able to stop the trim runaway by disabling the autotrim system. Maintenance personnel at Jakarta were unable to find a problem with the aircraft on the ground following the flight, and it was released again for flight the following day. As the miscalibrated AoA vane was not repaired or replaced, the problems from the previous day repeated themselves; the stickshaker activated as the aircraft rotated for takeoff (and once again remained active throughout the flight), and the stabiliser trim began to run away in the nose-down direction as soon as the aircraft's flaps were retracted.⁷ Unlike what happened the previous day, the flightcrew either forgot or were unable to disconnect the autotrim system before the extreme out-of-trim situation resulted in a loss of control and the aircraft crashed into the Java Sea with the deaths of all 189 on board.

Many of these accidents could have been prevented if some form of sanity checking (a test to detect and screen out nonsensical incoming data) were run on the angle-of-attack data before releasing it to other systems:

• An AoA vane that becomes stuck in a fixed position on the ground could be easily detected during takeoff by analysing the data provided by the sensor as soon as the aircraft's airspeed becomes high enough to allow the sensor vanes to operate, and marking as failed any sensor which reports an attack angle that it is not physically possible to assume when the aircraft is on the ground and unrotated.
• A sensor reading consistently high or low could be found out by calculating the z-axis load factor the reported angle of attack would create given the aircraft's current IAS, weight, and configuration, and rejecting the data from any sensor that has reported an AoA that is too excessively high or low to produce the observed Gz.
• A sensor that is starting to wander away from accuracy would be detected similarly, as its reported AoA would change over time in a manner inconsistent with the changes in the aircraft's airspeed, load factor, weight, and configuration.
• A failure that results in the reported attack angle changing unphysically rapidly (for instance, going from +2° to +50° and back to +2° in the space of two seconds⁸), which could conceivably be produced by certain types of sensor failures,⁹ but would more likely indicate a problem slightly further downstream, involving the improper processing and conversion of valid sensor data (such as from an ADIRU failure), would be particularly easy to detect, allowing the offending piece of equipment to be rapidly marked as failed and thrown offline.

So why isn't an airplane's raw angle-of-attack data sanity-checked before letting other aircraft systems run wild with it?

---

¹: This does not necessarily require that the aircraft's attack angle be constantly displayed to the pilots; it is often sufficient simply to have the aircraft's systems monitor its AoA, and take action (such as activating the stickshaker) if it becomes excessive.

²: These sensors are typically mounted on the forward fuselage, even though mounting them on the wings - which are, typically, the part of the aircraft that generates most of its lift, and, thus, the part of the aircraft whose angle of attack is actually relevant - would provide more accurate data (because the local airflow - and, thus, local attack angle - over the forward fuselage is generally different from that over the wings; thus, AoA readings from nose-mounted sensors need to be corrected in order to calculate the wings' AoA).³

³: The magnitude and direction of the difference depends, among other things, on the aircraft's airspeed; thus, the process of calculating the wings' attack angle from that of the nose requires valid airspeed data, which can create problems of its own if the aircraft's systems do not actually have access to valid airspeed data.

⁴: The L-1011 uses an unusual, and ridiculously-complicated, type of AoA sensor, which, rather than a simple mechanical vane, uses magic a hollow tube, pierced with two rows of perforations, which interfaces with a nearby differential-pressure sensor.

⁵: The data provided by any type of attack-angle sensor will necessarily be meaningless at low airspeeds (such as during taxi and the early portion of takeoff) due to the very low dynamic pressure imposed on the sensors at these low speeds; however, properly-functioning AoA sensors will provide valid data at high airspeeds, even on the ground.

⁶: Due to the abovementioned unreliability of AoA-sensor data at low speeds, combined with the physical impossibility of stalling an aircraft which is sitting on the ground, the L-1011's stall-warning system is inhibited when the aircraft's air/ground switch is in "ground" mode.

⁷: The particular subsegment of the 737 MAX (737-7/-8/-9/-10)'s autotrim system which caused the nose-down trim runaways is only active when the flaps are fully retracted.

⁸: This is not to say that attack angles of this magnitude cannot be experienced in a typical airplane; an airplane's AoA can easily approach 90° in a prolonged stall (especially one that degrades into a flat spin). However, no airplane larger than a fighter jet - and especially without thrust vectoring - is capable of pitching up by over 45° in the space of a single second; the rotational inertia of a large, enlongated, heavy fuselage is simply much too great for such a rapid, drastic maneouvre to be physically possible.

⁹: For instance, the L-1011's aforementioned mess of an attack-angle sensor system includes a motor which rotates the external sensor tube to null out the sensor's internal pressure differential, and reads out the local angle of attack by measuring the angle through which the sensor tube is rotated by the internal motor; a short circuit could easily cause the motor to keep running until it hit its mechanical stops in one direction or the other, driving the sensor tube to a very high positive or negative angle, and thereby causing the sensor to report a falsely-high AoA (and possibly one not even in the right direction, at that).

Answer 1

And exactly what or how are you going to ‘sanity check’ these systems? The AoA sensor is just a sensor, converting a physical position into a voltage which another piece of hardware can interpret the results from. Now some aircraft have multiple AoA vanes so a faulty vane could be detected and isolated if its input data does not concur with other sensors or available information.

Now a lot of this is mitigated through risk assessment ie determining the mean failure rates associated with properly maintained equipment. I would add the fact that you cite a mere 3 accidents associated with millions of air carrier flight hours over the past 60 years of modern air travel seems to indicate the risk of these accidents to be so small that it may simply be trivial compared with the additional weight gain form additional systems. Second, this is kind of Monday morning quarterbacking in that it’s easy to say that now AFTER these mishaps occur. Third remember that in the L1011 example these aircraft are products of their time and that aircraft design is an continuously evolving process. We get better as we go and many time our best lessons were paid for in the blood of the less fortunate.

Answer 2

Most modern systems, such as those found in Air Data System, stall warning, Primary Flight Control Computers, already do bound checks on the measurement values. If an AOA measurement is outside of programmed static thresholds, typically very negative or very large, the system can either inhibit its functionality or vote the measurement out. This is pretty much all a sanity check can do with an isolated measurement (other checks include signal integrity checks, such as parity checks, which are not of our interest here).

For the other checks that you have proposed, they will inevitably include other measurements.

The first problem is, if a measurement disagrees with your model predicted measurement, how do you tell which is erroneous? Is it the weight, impact pressure, Nz, TAT, or your assumed CL-alpha curve at the measured Mach? If this is a voting scheme, you risk voting off the wrong sensor and exacerbate the problem. The complexity very quickly ramps up as you would need to do cross checks for all the other measurements, and still need to add a large bound to cater for uncertainties.

A better solution is to cross-check against multiple AOA measurements. For example, the A330 uses the median of the three AOA measurements as an integrity source, while the final AOA value used for control law input is the rate-limited average of two offside AOAs.

This comes to the second issue of availability vs integrity, which has been discussed in detail in this answer.

Answer 3

It is a very good question, in light of what happened with the Lion Air flight 610 crash. Caused by a single mis-calibrated AoA sensor, resulting in 189 deaths.

Single inputs into flight automation are allowed, if the single input can be safely disregarded by the on-board systems. A safety analysis will take into account:

• what the consequences of the signal failure are (both fail-to-zero and hard-over fail to a large value);
• how safety critical the system is that utilises the signal;
• what actions need to be taken (if any), and how fast;
• how often the signal fail may occur in the lifetime of the aircraft.

As also discussed in this answer: it must be shown in the safety analysis that the probability of catastrophic failure is less than one in a billion flight hours. This is in an analysis, which can only be statistically verified if the fleet has accumulated several hundred billion flight hours.

And this is where the procedure went astray in the B737MAX certification. The AoA sensor hard-over failure had catastrophic consequences, and was a single input into a flight critical system. Aeronautical Engineering 101: never do this. I am sure that all Boeing engineers involved in the system design were aware of the possible implications, release of the internal communications has shown their concerns and flags.

Yes a sanity check might make sense, particularly in 10/10 hindsight. But in system safety, any action may have an unintended consequence, like in software programming: any statement may introduce a bug, which of course was never foreseen. Even alerting the pilot that something may be wrong with the AoA input may increase pre-TakeOff workload and stress, resulting in more incidents than without the warning. And it may be that the safety analysis makes a compelling case for this side of the coin.

Picture from the crash report

But even a simple sanity check on ground may have pitfalls. Does the AoA sensor always deflect down due to gravity, indicating a negative AoA. or is its position on ground undefined due to small mass unbalance and some allowable friction? The AoA sensors did show a 10° difference on ground, would then all automated systems and stall warnings that use AoA input be disconnected, creating possible other danger scenario's or consequences for dispatch reliability?

The AoA sensor in the B737 max is sanity checked in a sense: in the preceding Lion Air flight SPD and ALT flags appeared on the PFD, and SPEED TRIM and MACH TRIM warning lights illuminated. As a result maintenance performed troubleshooting, also from the crash report:

The AFML entry stated the engineer in Denpasar intended to replace the AOA sensor for trouble shooting due to repetitive problem.

In the balance, the single FCC design of the B737 does seem like a heritage from a bygone era - which it is. AoA sensor failures had not resulted catastrophes in the B737 fleet prior to MAX. From the report page 195:

Erroneous AOA signals are not frequent events. Boeing reported that 25 activations of stick shaker mostly due to AOA failures occurred in 737 aircraft for the past 17 years during more than 240 million flight hours. The MCAS architecture with redundant AOA inputs for MCAS could have been considered but was not required based on the FHA classification of Major.

There is pressure from the airlines to maintain type commonality and limited differences training. All good, but duty of care must be taken to protect us, the passengers, to exclude risks larger than acceptable.

Answer 4

Aircraft usually have "disagree" warnings when redundant sensors do not provide the same reading (within some specified tolerance). This warning may (or may not) inhibit other systems that depend on those sensors.

For instance, the MCAS system in the 737MAX was designed to rely on two AoA sensors. If the two sensors disagreed, the pilots were given a warning and MCAS was inhibited since it wouldn't know which sensor to believe and might cause a crash. Unfortunately, the second AoA input was later changed to an optional feature, and two planes purchased without that feature (despite being physically equipped with multiple AoA sensors) crashed because the failure of the single AoA sensor connected to MCAS was therefore not detected.