Sadly, another "the sensor did it" scenario. https://semiengineering.com/dirty-data-is-the-sensor-malfunc... The tragic example of the Lion Air crash of a new Boeing MAX 8 aircraft, which on Oct. 29 killed all aboard, may be heading toward “the sensor did it” category. The black box recovered from the flight showed inconsistent data from one of the two angle-of-attack (AOA) sensors. With one half of the data apparently incorrect, it was enough to trigger this plane’s anti-stall system into a nose down action, which the pilots wrestled all the way into the Java sea.
On a technical level: personally I think that the root cause could be a lack of "integration" of the system (MCAS) with the rest.
Meaning that e.g.
1) if the pilots' yokes/sticks are being pulled and
2) if the altitude based on gps and/or air pressure and/or radar is decreasing and
3) if the speed registered by the airspeed probe is high respectively increasing and
4) if the fuel being used by the engines to keep or even increase the speed is very low and
5) if the G-force registered by <some sensor, if it exists?> is lower than usual (neutral or even negative?)
6) etc... (anything else excluding AoA?)
...then the airplane is mooost probably "going down", even if the AoA says the opposite.
As the MCAS auto-trim has apparently a big potential impact on how the airplane flies (surfaces on the tail are big and their angle can move a lot), it should therefore not rely on just 1 (or even 2 duplicate) lonely sensor(s) but on multiple types that provide multiple point-of-views of the aircraft's situation to then abstract/determine/confirm the current high-level situation (in this case "is the aircraft going up or down?") and only after such result to react/take countermeasures to save the aircraft respectively help the pilots and/or lower costs for the flight.
If this is not totally wrong, is this (the total integration of all sensors) how Airbus did it with their super-automated systems like e.g. their side-sticks/joysticks just telling the airplane what pilots "want"? (meaning, did they start already from scratch creating a totally integrated system, if they did create such an integrated system?) (not sure about how automated the new Boeing airplanes are, so I did not mention them...)
Angle of attack is not related to any of the items that you list. You could be approaching stall even while your altitude is increasing (2), while you are at a high speed (3), at less than 1 G (5) etc.
I'm not sure you quite understand what a stall is. A great resource I can recommend is a book called See How it Flies (http://www.av8n.com/how/).
Actually from the link you provided, airspeed is absolutely a quantitative indicator of a stall.
"The airspeed indicator provides quantitative information about angle of attack, when the airspeed is not too low. Correction factors must be applied to correct for nonstandard weight and/or load factors.3"
You miss my point. Root Cause typically does what you are doing, focusses on technology and in-the-moment behaviours and remediation.
I wanted to go above this to a higher layer: Had the regulatory environment the FAA has mandate to operate run better, then Boeing could not have asserted "same type" for such a huge change to the flight dynamics of the aircraft moving its CG with the new engine.
The "root cause" is not technological, its the compliance processes, and the desperate desire to artificially re-create a "level playing field" between Boeing and Airbus
Funny thing is, that sounds a lot like a certain Air France flight. Besides the airspeed probe, though, since it was inoperative. (And the AOA sensors agreed) But in that situation, pushing the nose down would have been the correct decision.
Fix: Make Engineers actually liable for the correct classification of systems and require signed justification for NOT defaulting to the highest possible standard.
...which demands a fully independent FAA. Not the one we seem to have which appears on the face of it, compromised by the consequences of embedded self assessment and 'same type' rules. Why was it in the national interest to have Boeing get 'same type' ? Because of the cost of competing with airbus.
The regulator was hamstrung in the interests of 'efficiency'
(I'm not an American and this is an argument i read which resonates. I'd welcome good rebuttal)
I'd dispute it causes the over-engineering. Engineering principles cause safety margins, and regulators enforce safety margins. As the industry decides it can live with reduced safety margins they get reduced. When they get too close to a risk window, they get raised.
I know the over-engineering term exists, but I think it's based on flawed logic. Not having margins results in under-engineering, which is significantly worse in almost all cases. Its not a symmetric world out there. Some things are worse than others.
Realize some pilots lurk here...was the angle of attack sensor ever associated with an automatic system prior to MCAS?
Seems like previous errors would have been less impactful due to human observation and synthesis with other instruments, window observation, etc.
If so, it shows how GIGO works in automatic systems...this should have been scrutinized as AOA sensor was not above the 1:1,000,000 threshold for single-input systems w/o failover.
Not a pilot, but angle of attack sensors are used with flight envelope protection systems in Airbus airliners (and probably newer Boeing planes too, though I'm not sure).
Take for instance this particular incident on an A321 aircraft [1]: "two angle of attack sensors having frozen in their positions during climb at an angle, that caused the fly by wire protection to assume the aircraft entered a stall while it climbed through FL310. The Alpha Protection activated forcing the aircraft to pitch down, which could not be corrected even by full back stick input. The crew eventually disconnected the related Air Data Units and was able to recover the aircraft.".
A321 have three AoA sensors, so if two freeze in the same wrong position, they outvote the good sensor...
A group of New Zealand pilots and regulators pressured a
German pilot to test the envelope protection systems during
a simulated emergency landing (so well simulated that the
pilot did not seem to know where he was going ahead of time)
The AoA vanes were out of commission with this aircraft, the flight protection system malfunctioned and the plane flew into the ground.
That is, the danger got caught on a test flight and only 7 were killed. Compare that to the problem happening on not one but two revenue flights.
Had the FAA required that pilots ride out an MCAS failure in a simulator they probably would have learned that pilots could not ride out an MCAS failure before passengers were put at risk.
AoA vanes not just failed, they failed because of incorrect maintenance procedure.
>One of the contributing causes was incorrect maintenance procedures which allowed water to enter the angle of attack (AOA) sensors. During fuselage rinsing with water before painting, three days before the flight, the AOA sensors were unprotected. As specified in the Structure Repair Manual by Airbus, it is mandatory to fit a protection device on AOA sensors before these tasks.
In this case several failures all happening at the same time cause the crash: software, pilots following protocols and maintenance.
Wow, that still happens? Not the first accident caused by incorrectly covering and uncovering probes during maintenance. I think once the Pitot tubes were still covered with their caps.
"On 5 November 2014, Lufthansa Flight 1829, an Airbus A321 was flying from Bilbao to Munich when the aircraft, while on autopilot, lowered the nose into a descent reaching 4000 fpm. The uncommanded pitch-down was caused by two angle of attack sensors that were jammed in their positions, causing the fly by wire protection to believe the aircraft entered a stall while it climbed through FL310. The Alpha Protection activated, forcing the aircraft to pitch down, which could not be corrected even by full stick input. The crew disconnected the related Air Data Units and were able to recover the aircraft."
The computer thinks the plane in a otherwise normal climb (attitude, airspeed, power, rate of climb) is stalling? That's just...we cannot call this kind of automation anything like a pilot. The term "autopilot" is too much anthropomorphizing. A pilot reacting this way in this same situation with the same information, they would be incompetent or crazy to trust two AOA sensors and assume a stall. If a crash ensued they absolutely would be blamed for it. Not the goddamn sensors.
And calling such a thing a safeguard when it can fail danger like this? A 4000fpm decent as a correction for a stall in a normal climb? That's just batshit. I'm now in a dive recovery operation, itself with higher risks than a stall in the midst of a climb! A stall in a climb is not more dangerous than a 4000fpm dive. Think of throwing a football, it's stalling the entire way, all that's going to happen is the plane stops climbing as fast as it was and the nose is supposed to come down (that's why planes must have positive static stability) and viola we're flying again!
Let's pretend it is true you are somehow stalling in a normal climb (an instantaneous increase in angle of attack): what do does a pilot need to do? Neutralize controls, that's it. Maybe the attitude goes somewhere between 5 and 0 degrees. But a 4000fpm decent? pUke.
(I'm a pilot and former CFII, so I feel sufficiently entitled with my biases to comment with such editorialization.)
The only reason we humans tolerate such unsophisticated systems arriving at weird and dangerous edge cases is because the automation has in fact helped to make flying so much safer. But so have many other things: components are so much more reliable, turbine engines run for many thousands of hours between overhauls, they're really incredible. The training is a lot better. CRM has made things way safer! It's not just the automation. And we really shouldn't be cutting automation so much slack either. I mean for fucks sake, 4000fpm? Crazy. But it's an edge case and it should not be accepted with "oh well the pilots recovered! AOK!"
Obviously if the pilots had not recovered a central theme would be "the pilots didn't recover! INCOMPETENT PILOTS! THEY DIDN'T FOLLOW THE CHECKLIST! WARGARBLE!
Automation is not anything like a human. So accusing it of being crazy, or trying to murder people isn't exactly accurate. But I think it's reasonable to hold it accountable to things that look like "insane" behavior when it fails this spectacularly. Its just a sequence of narrowly defined laws, with each law doing its specific thing, without any regard to other information. Very myopic worldview. And then having more authority to take (wrong) action than pilots have to correct it?! What a bad sequence!
I used to be one of the "automate all the things!" crowd, but as I've been exposed to more and more fields, I've come to realize that automation's place is to augment and assist, not replace. There are diminishing returns to increased automation, as at the end of the day, the user of the automation needs to be 10% smarter than the piece of equipment, which quickly becomes a more and more challenging task the more the challenge of overseeing the automation takes away from doing what you are there to do in the first place. In this case, flying the plane.
> was the angle of attack sensor ever associated with an automatic system prior to MCAS?
Yes [0]. The stick shaker and stick pusher. But those are overridable by pilot muscle power. With the MCAS, there can be situations where that isn't the case, and we have two crashes as a (probable) result.
Too much is being made about the sensors. From my pilot's perspective it's far worse that:
a.) MCAS can mistrim the airplane faster than pilots can even recognize what's going on.
b.) Boeing and FAA directives still don't account for a.), and therefore they're still giving pilot's inadequate advice. And it's sufficiently bad that I think it's intentional because the advice is consistent with prior Boeing 737 models: runaway stabilizer. If they came up with a better checklist to run that only applies to the MAX, that is suggestive that at least difference training is needed, and might even suggest a different type certificate is needed.
So if the sensors have a higher rate of failure then it looks like changing MCAS software to rely on both sensors may not be enough as there is a higher probability of both sensors malfunctioning and sending bad data to MCAS at the same moment. In that case, I am not sure how would MCAS behave.
The other part of Boeings fix is to prevent MCAS from being reactivated repeatedly. If I remember correctly they are not allowing it to reactivate until the AoA returns to normal.
I'm hopeful that they have analysed what happens if the AoA returns more or less random data.
> ...they are not allowing it to reactivate until the AoA returns to normal.
Puah, but what is "normal"? This is probably kind of tricky to define if you cannot potentially rely on the sensor(s). Additionally I understand that the auto-trim of MCAS was created to actually react to "abnormal" situations (nose too high), which brings us here into a conflict :)
By normal I mean below its threshold for activation. According to Boeing this depends on speed and attitude.
Of course this leaves the problem of what happens if the sensor data was wrong but fluctuating wildly. Which is what I was getting at in the other paragraph.
In both the Lion Air and the Ethiopian incident the sensor data went to some very high value and stayed fixed basically until the aircraft hit the ground so perhaps they know that is the only failure mode or maybe they are accounting for other failures but don't feel the need to expand upon that in public.
If these sensors have a common failure mode (eg. always showing lowest possible value after blowing up), this could be bad. If they just produce junk, it's unlikely they would agree, and MCAS would be turned off.
The common failure mode would be e.g. freezing, perhaps in identical positions, while on the ground before takeoff. You can't easily detect it before takeoff because the sensor requires airflow.
It can freeze from icing or other low temperature conditions after takeoff. The sensors are heated to prevent this, with a system in place to detect if the heater has failed, but they can still jam from a heater failure that is not detected or heavy icing.
Surely this could be easily detected, even with too low airspeed to give reliable readings the sensors should flap around slightly and thus provide noise. If they're frozen, there should be very little noise in comparison.
In addition you should be able to cross-correlate with gyro and airspeed sensor, not to check the absolute AoA, but certainly determine if delta-AoA is near zero (frozen) or not.
The sensors should be on good bearings, in order to promote them moving freely. Them flapping around slightly won't provide much noise. Which is probably drowned out by all the other noise on an aircraft.
> Them flapping around slightly won't provide much noise. Which is probably drowned out by all the other noise on an aircraft.
But the readings with the vane flapping around should have a significantly higher variance than the readings where the vane has frozen stuck. In addition, a sliding average should show the mean moving around significantly compared to the frozen readings. Surely they should be able to discriminate between these cases based on those factors, especially when cross-correlated with other sensors.
Can't always test the mechanics like that. Ex: Pitot tubes are just hollow tubes. The interiors of pitot tubes getting iced over has crashed planes. This wouldn't even be visible from the outside, and there is no test you could do.
For example, if the AoA sensors say the nose is too high and the flight control software trims down to compensate and then it doesn't see the AoA sensors report lower pitch, couldn't it check the Attitude Indicator (AI)?
Angle of attack and attitude aren't necessarily the same, because the wind vector is not necessarily parallel to the ground, but AoA changes and AI changes should be well correlated most of the time. If trim changes are showing up in the AI data but not the AoA data, then you've probably got malfunctioning AoA sensors.
My understanding is that attitude is only a reasonable approximation of Angle of attack (assuming winds are parallel to the ground) if you are in level flight.
My understanding is that with still air, AOA is basically the difference between the attitude and the vertical direction of travel. (i.e. in still air you are climbing at an angle of 5 degrees with the nose pointed up at 10 degrees, your AOA would be 5).
So in my possibly flawed understanding the better way to approximate real angle of attack when the wind is parallel to the ground would probably be to take airspeed and rate of climb data, perform trig to get the angle of climb or descent as seen from the air reference frame (cf. airspeed vs groundspeed). Then subtract that from the gyro indicated attitude, and you get an angle of attack approximation that assumes no up or downdrafts.
That combination might yield something better to compare against the AOA sensors than just the attitude value. (Although I would agree that if it changing the trim causes the attitude to change but not the AOA sensor output, something is probably wrong.)
I'm just amazed by how poorly this was implemented. Software engineers expect hardware to fail. This wasn't just the work of a newb (or I hope it wasn't). This was planned; both the requirements and the failure modes. Then implemented by another team, and the quality verified by another team, even a 3rd party. There wasn't even a cutoff if it started operating outside it's expected range, surely one of those people would have noticed the shortfalls. This software should have the same level of engineering as other systems/ parts of the plane.
Every phone I've had in the last decade has come with GPS (which includes altitude), giros and even magnetic compasses. So they can work out the angle of attack without the need for additional sensors, or at the very least a backup!
Is this a wider issue with software development in general? My guess is that many businesses are moving away from the waterful model, which can often go overboard with planning (not really a problem in aerospace..). To 'Agile', which I don't think many people truly understand (especially some managers), often sidestepping the planning and documentation to software that appears to work fine, and senior management are overjoyed with the progress and become complacent.
This software wasn't even a crucial feature. It was only needed when high power is applied to the engines (like during takeoff) to stop the nose feeling too light by existing 737 pilots. This wasn't a jet-fighter, which would become unstable without the aid of computers. It's a shame 338 died because of what is effectively a 'schoolboy error'.
Every phone I've had in the last decade has come with GPS (which includes altitude), giros and even magnetic compasses. So they can work out the angle of attack without the need for additional sensors, or at the very least a backup!
Unless you’ve launched your phone into the air in a fit of rage, it doesn’t have an angle of attack. :)
Angle of attack is the angle between the wing and the oncoming air.
You might be wondering how that’s different from how high the nose is, and you’d be justified in wondering that. Every student pilot in the world gets these two very different things mixed up! But they are very different.
Next time you’re near an airport, watch the planes as they come in for landing. Try to get a vantage point from the side if you can. You’ll notice two things: (1) the airplane is descending, and (2) the nose is flat or pointed just slightly up.
It should be clear that in this situation, the angle between the oncoming air and the wing — the angle of attack — and the angle of the nose are different. Because the airplane is descending, the angle of attack is greater than the angle of the nose.
> Every phone I've had in the last decade has come with GPS (which includes altitude), giros and even magnetic compasses. So they can work out the angle of attack without the need for additional sensors, or at the very least a backup!
"Instead, engineers were able to add just a few inches to the front landing gear and shift the engines farther forward on the wing. The engines fit, but the Max sat at a slightly uneven angle when parked.
While that design solved one problem, it created another. The larger size and new location of the engines gave the Max the tendency to tilt up during certain flight maneuvers, potentially to a dangerous angle.
To compensate, Boeing engineers created the automated anti-stall system, called MCAS, that pushed the jet’s nose down if it was lifting too high. The software was intended to operate in the background so that the Max flew just like its predecessor. Boeing didn’t mention the system in its training materials for the Max.
Boeing also designed the system to rely on a single sensor — a rarity in aviation, where redundancy is common. Several former Boeing engineers who were not directly involved in the system’s design said their colleagues most likely opted for such an approach since relying on two sensors could still create issues. If one of two sensors malfunctioned, the system could struggle to know which was right.
Airbus addressed this potential problem on some of its planes by installing three or more such sensors. Former Max engineers, including one who worked on the sensors, said adding a third sensor to the Max was a nonstarter. Previous 737s, they said, had used two and managers wanted to limit changes."
> Boeing also designed the system to rely on a single sensor — a rarity in aviation, where redundancy is common.
I worked on the C-2 Greyhound aircraft in a past life. Part of an upgrade they got, only because it was an absolute requirement to fly in European airspace, was a magnetometer. The documentation on replacing and testing the new sensor, of which there was only one, was non-existent. The documentation said that the sensor could not and would never fail.
While in another country one failed. In disbelief my Chief had me read out every wire in the system even though I knew it was the sensor immediately. The bird was down for weeks until we got a new one because supply didn't exist and I had to make up a suitable plan for testing the replacement on the fly.
I wonder what kind of practices lead to a "this system can never fail" mentality. It should be assumed everything can and will fail.
This is the second time I've had occasion to post this quote here in the last week:
"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair." -- Douglas Adams
>It should be assumed everything can and will fail.
And anything still seemingly working to spec over a fairly conservative cycle count has already failed. Just in ingenious ways that it hasn't yet informed you of and nobody has yet discovered. You should probably swap it out for a spare and take it apart and hit it with things till you are sure. You should probably do that now while there is still time.
"Several former Boeing engineers who were not directly involved in the system’s design said their colleagues most likely opted for such an approach since relying on two sensors could still create issues. If one of two sensors malfunctioned, the system could struggle to know which was right."
Shouldn't this have been more of a red flag not to rely on a single sensor when human lives are literally at stake?
I suspect their reasoning was: It only trims down by 0.6°, what does it matter if a faulty sensor accdentally activates it. The plane is still flyable slightly out of trim and the pilots can easily correct it.
The 0.6° number was what they said immediately after the Lion Air crash.
But their reasoning was wrong.
Turns out, MCAS was actually adjusting trim down by more like 1.5° and they never considered that a faulty sensor would trigger multiple MCAS activations and move the stablizer all the way to the end of it's range.
MCAS is not an anti-stall system, it’s a way to change stick forces by trimming the horizontal stabilizer - the surface with most control authority. There’s no evidence it has ever prevented a single stall or even activated properly, but there’s evidence it has helped crash two planes.
>Every phone I've had in the last decade has come with GPS (which includes altitude), giros and even magnetic compasses. So they can work out the angle of attack without the need for additional sensors, or at the very least a backup!
You would need a sensor to measure relative wind. Angle of attack is the angle between the wing and the relative wind.
A six axis sensor could probably measure AoA in a pinch. It’s just like how a stability control system works in a car (which is measuring slip angle, which is the lateral “angle of attack” between tires and road). If you detect upwards rotation but no matching acceleration forces, you’re detaching from the air stream.
Obviously this system will drift over time, but it could more than adequate to detect a failed AoA sensor and revert to the second one.
Since angle of attack is by definition the angle between a reference line of a body and the fluid it is moving through, I fail to see how you could measure it without measuring the relative motion of the fluid.
Your suggestion would work under the assumption that there is never any vertical motion of air, but that's not the case in real life. E.g. in a downdraft your sensor would fail to detect a stall.
That’s true, but it would still be good enough to cross check the aerodynamic AoA sensors upon a disagree between the two and select the one that’s more reliable.
Past professional experience with similar sensor systems.
I also assume the AoA sensor failure was evident over time, through several phases of the flight and not momentarily.
A sensor fusion algorithm would notice the divergence over time between the IMU and the two AoA sensors, then select the one AoA sensor that was closer.
Even in the case of a momentary failure, it would take an extreme coincidence to have the readout pattern of the failed sensor seem closer to the IMU based AoA model than the working sensor.
Keep in mind I’m only talking about cross checking the AoA sensors here; the flight control algorithms are only considering the aerodynamic sensors for AoA calculation as before, but they have an independent external reference to gauge the data quality of each sensor.
It could at least provide a reference to infer if readings were within a sensible range. Outside of that range it might be best to scream bloody murder and require manual human piloting with automated assistance at producing the desired results. (E.G. If the pilot's pulling back on the stick, they PROBABLY want the airframe to go up as a result rather than down.)
Is it really necessary to measure the relative wind or is that just how it's always been done?
What would be wrong with using an accelerometer to measure/calculate velocity with respect to pitch give you a better reading of AoA? In conjunction with a second velocity source to provide redundancy?
Ah yes, the classic "software engineer reveals one easy trick to solve a complex problem domain" post. Maybe they just needed a Raspberry Pi and a sixaxis sensor board, has anybody thought of that!?
GPS info might be something you can use for sanity-checking input, but AoA can only be reliably read from an actual instrument. Air moves, you can't rely on the plane's motion.
Also, MCAS isn't active with flaps extended, so "like during takeoff" isn't correct. MCAS won't be active during takeoff and landing because it's not designed to be active at those times.
That's what I was getting at. If the nose is at an extreme angle (or reported to be) and the plane isn't climbing/ or descending - there's something wrong!
Just after takeoff while the plane is still climbing. I'm not sure that helps matters much, as the plane is off the ground and lore's the pilots into a false sense of security as plane's working ok..
Here's the bulletin Boeing issued after the first crash. It's hidden away in the bottom left and not highlighted, so it's easy to miss: "runaway stabilizer". Unfortunately, the brief is more focussed on assuring how safe the planes are, and what counter-measures to take in the event. Rather than what a runaway event looks like.
https://theaircurrent.com/aviation-safety/boeing-nearing-737...
This is a weather vane which needs to be exposed to the elements, its not something that can be inside the aircraft. It needs to be exposed to super harsh conditions to get its reading.
I don't think that's accurate or consistent enough to meet the requirements of FAR 25.207. Load factor is constantly changing in flight. You only have a constant load factor with zero turbulence and ~~straight and level flight~~ unaccelerated flight. edited Obviously I can climb at 500fpm at 1.0g, but if the rate itself is changing I'm at something other than 1.0g.
It also can't withstand failure of the selected pitot-static system, because it depends directly on it. So now you need a mechanism to detect such failures, and use a different pitot-static system, and do all of that switching while maintaining the requirements in FAR 25.207. I'm unconvinced that's feasible.
Pitot-static failure is already a big deal for much more immediate reasons than an AoA estimate. And I'm puzzled why load factor changing would be a problem? The air data computer knows what the load factor is at any given time.
To be clear: I didn't imply that you'd want to use this as the single source of AoA, only that you can use this in concert with the physical sensors to determine if the sensors are producing a valid value. You need 3 sources to be able to throw out a bad measurement, 2 AoA sensors and an airspeed-based measurement should be a perfectly valid, single-fault-tolerant, way to outvote a bad sensor.
Remember that these accidents happened at high airspeed. You'd rip the wings off the airplane before you'd stall it at those speeds. It's not a subtle failure.
That's a ridiculous statement. All sensor data are estimates.
If the IMU and airspeed sensors are good enough to feed the artificial horizon, autopilot, etc, they're surely good enough to produce an AoA estimate that's good enough to serve as a cross-check on the physical sensor.
> That's a ridiculous statement. All sensor data are estimates.
Some more reliable than others. You have no fucking clue what direction the wind is coming down on the wings based on horizon.
You have a skewed perception of what wind is. On the ground it is always horizontal because it can't go into the ground. Once you get up into the sky the dynamics are insane. Get out of your armchair.
Are you a pilot? This is the basic way that a pilot can know whether he's close to stall without anything more than an airspeed indicator.
It's basic flight physics. The lift developed by the wing is equal to CL.q.A. A is the wing area, the dynamic pressure q is basically indicated by the airspeed indicator, and CL is a known function of AoA. Lift is by definition equal to the load factor * mass.
The pilot can "know whether he's close to stall without anything more than an airspeed indicator" only if he's not in a turn (see accelerated stall).
While you are right in theory - if you knew the load factor and indicated airspeed (IAS) you could determine AoA - how would you measure IAS in practice? Normally a pitot tube would give you incorrect readings at non-zero angles of attack, and that's why airplanes use an input from an AoA sensor for correction. Which brings you back to where you started - an AoA sensor.
You are second-guessing tens (hundreds?) of thousands of engineers who thought about these problems for more than a hundred years.
(Az = vertical acceleration.) The relationship between coefficient of lift and AoA is a known function that depends on the airfoil. As long as you're below the critical angle of attack, it's an invertible function. (If you're not below the critical AoA, you've already departed controlled flight so it's too late for MCAS.)
How so? As far as I understand, it will hold to a very high degree as long as the flight conditions are stable over the time scale needed to establish the airflow pattern over the wing, which is very short.
(If the flight conditions are that unstable, a mechanical AoA vane will struggle too, since it has mechanical inertia.)
It's a ratio, so you could use a vertical accelerometer. But this isn't enough information to derive angle of attack even with airspeed. Of course, a plane can be in straight and level flight with 1.0 g loading, at 200kts, and maintain that with many different angles of attack due to weight and center of gravity differences, both of which are changing throughout the flight as fuel is consumed from tanks in different locations.
Indeed. But the system already knows what the mass is, this is needed to calculate takeoff performance, rotation speed, stall speed, maneuvering speed, etc.
CG doesn't enter into it except to second order due to horizontal stabilizer lift.
It's still not enough information to compute AOA. Let's say I'm configured for 300kts in level flight. Now I pull back on power changing nothing else. I'll end up in a decent, and eventually that will stabilize to e.g. 1000fpm at 300kts. I'm still at 1.0g, and 300kts, but I'm in a decent, obviously angle of attack is less than in level flight. So airspeed and load factor aren't enough, nor is including mass.
Horizontal stabilizer lift is a downward force and must be countered with lift from the wing to maintain level flight. It's effectively the same as adding weight. Angle of attack absolutely changes as CG changes. This is a central purpose of weight and balance computation. W&B also changes as fuel is consumed. So you'd have to take that into account.
Anyway, you can't infer angle of attack or the coefficient of lift from only airspeed, load factor, and mass. You need more information.
I'm still at 1.0g, and 300kts, but I'm in a decent, obviously angle of attack is less than in level flight.
This is a common misconception, but is not true. The angle of attack does not care if you are in level flight, climbing, or descending. As long as you are in unaccelerated flight, the AoA is identical.
It's not exactly the same, because if the descent (or climb) angle is significant, the lift only has to supply part of the weight of the airplane (the rest being supplied by drag or thrust), so the AoA will be slightly less. But that's accounted for because the load factor will also be slightly <1G.
(The edge case is if the plane is flying straight up or down. In that situation, the wings provide no lift at all and the AoA will be zero.)
Replying specifically about the stabilizer lift discussion:
What you're saying is true, but the effect of AoA is not huge. Stabilizer lift is a small fraction of main wing lift, because it has a huge leverage. The corresponding effect on aoa (effectively stall speed) is noticeable but also not huge. CG matters mostly because of its effect on controllability, not because of its effect on stall speed (although the effect is there.)
I maintain that, for the purpose of judging whether an alpha vane has failed or you're actually about to stall, you can ignore this effect when estimating AoA.
It's exactly the same as making the statement "If I'm flying at 1.5 Vs0, I know I'm not stalling (unless I'm in a very steeply banked turn or is pulling up sharply out of a dive.)
I saw you're a CFII. If a student made the above statement, would you berate him for failing to consider CG position?
These airplanes all have inertial measurement units feeding the flight instruments. On older aircraft, there would at the very least be a simple "G-meter". There are design limits on the load factor so it's important to track it to make sure it's not exceeded.
Load factor is the number of Gs the aircraft structure is supporting. In unaccelerated flight it’s 1. Straight and level, an established climb, and an established descent are all unaccelerated.
In a turn, an airplane experiences a higher load factor as a function of the bank angle. The lift from the wings is what makes the airplane turn. Since some of the lift is being diverted to the horizontal, the total lift must be increased to keep the airplane from sinking. The result is a higher load due to the acceleration in the turn.
The beginning of a climb or descent also changes load, but once established, the load returns to 1.
> Is this a wider issue with software development in general? My guess is that many businesses are moving away from the waterful model, which can often go overboard with planning (not really a problem in aerospace..). To 'Agile', which I don't think many people truly understand (especially some managers), often sidestepping the planning and documentation to software that appears to work fine, and senior management are overjoyed with the progress and become complacent.
I think this is a good point on why Agile is so dangerous to the users. Agile allows for engineering to be micromanaged and due diligence from engineers to be overlooked. (It's not something the business people care about) Don't deliver without the safety feature? Well, you're underperforming... they're going to be let go pretty quickly.
There are two crashes directly related to this feature. So, it doesn't make sense to claim it wasn't critical.
In Boeing's own hazard analysis, they rated the feature "Hazardous", which is the second most critical rating. Obviously, it should have been rated "Catastrophic". But even with their own policy, anything rated hazardous is not allowed to have single-sensor failure. By their own policy, this should have had at least two sensors. There were multiple failures that let this slip through to production.
Sorry, I meant to write crucial (similar word, quite a different meaning..)
I believe the reason for MCAS was because the had to lower and move the engines forward. So at lower power, the forward engines make the plane nose-heavy. When the engines are near full power, the lower engines push the nose up. Compounding the difference in handling compared to the older models.
Here's the safety bulletin Boeing issued after the first crash. Even when you know what you're looking for it's hard to spot: "runaway stabilizer". It does seem they downplayed how serious the failure is, but they couldn't know how common it could be. That raises another question: Other pilots must have experienced the runaway event, but managed to gain control. What happened to those reports?
There will be lessons learnt from these crashes, in a number of fields.
> I believe the reason for MCAS was because the had to lower and move the engines forward. So at lower power, the forward engines make the plane nose-heavy. When the engines are near full power, the lower engines push the nose up. Compounding the difference in handling compared to the older models.
Wrong. If the power of the engines mattered, it'd have been an input to MCAS. Moving the engines forward changed how the nacelles created lift at high angles of attack, causing a pitch up effect from the nacelles, reducing (but not eliminating) the stick forces required to maintain the high angle of attack.
One thing I haven't seen fully explained ( maybe it was but I missed it ). Were these vanes damaged on both of these downed flights? Why didn't all the other 737 MAX 8's crash around the world, Was it something about the flight profile or the weather? Can the plane be flown as-is with a sufficiently conservative flight profile?
The sensor was never designed for what it was used. It was designed to provide input to a visual display for the pilot. The pilot always had a lot of other inputs. The reliability requirements were totally different to what was needed to directly control an airplane in a critical situation.
The software design compounded the problem with some bizare design decisions.
This was a system design failure. High level reliability requirements were not properly communicated to the subsystems. Subsystem failure was not properly analyzed. Human Machine interface considerations were ignored.
Considering the rush job and shortcuts Boeing made for this "feature" a valid consideration by a regulator would be to question their quality system. And that should trigger a systematic approach to reviewing all other requirements and design work going into the 737MAX.
There just aren't that many MAX planes. Only went into production in 2017, around 350 delivered to airlines. The vanes were presumably damaged (either mechanically or electrically) on both downed planes but not others.
> You and other keeps parroting this line, I don't believe it to be true.
You are free to believe anything you want to believe. Of course if you where involved in the 737 Max development and you have inside information to the contrary then I'll accept that.
It's the explanation which best tallies with the official description of the system, the circumstances surrounding its introduction and the certification requirements.
Many aircraft have systems implemented to prevent stalls (see stick pusher); and systems to prevent undamped yawing movements becoming uncontrollable (see yaw damper). And to prevent mach tuck (see mach trim system); and to prevent changes in pitch trim due to speed changes (see Speed trim system).
1. The position and size of the upgraded engines for the 737 MAX caused the plane to tend to pitch upwards, which could cause a stall.
2. Boeing was concerned designed MCAS to automatically push the plane's nose down to prevent stalls
Every single piece of reporting I've seen on the matter refers to MCAS as an anti-stall device.
Pilots of 737 who have talked to reporters refer to it as an anti-stall device.
I have a hard time believing that this information hasn't been fact checked to hell and back yet.
> Every single piece of reporting I've seen on the matter refers to MCAS as an anti-stall device.
Assuming you are a developer, have you ever seen some reporting of something technical in the news? Does it not make you cringe?
> Pilots of 737 who have talked to reporters refer to it as an anti-stall device.
Even Boeing themselves do; so who can blame them. The reason that the certification item exists is to prevent certification of aircraft which demonstrate increasingly lighter control forces as the aircraft approaches a stall. The reason being that it makes it easier for an inattentive pilot to accidentally fly the aircraft into a stall. So if you want to shorten that to anti-stall then I'm fine with that.
What I don't really like is the retoric about how these aircraft would fall out of the sky without MCAS "controlling" the plane. It isn't a closed loop control system implementing PID control to account for some crazy instability in the aircraft.
> Every single piece of reporting I've seen on the matter refers to MCAS as an anti-stall device.
"Anti-stall" has become a catchphrase wrt the 737 MAX. I wish everyone would stop using it, but the horse has left the barn it seems.
MCAS was cooked up to maintain the handling characteristics required by the FAA certification specifications.
Other commenters in other threads have explained why consistent response curves are vital in operating an aircraft, so I won't take on the why of the regulation other than to say it's well founded and some smart systems/human factors engineers have elucidated on this in earlier threads. Otherwise, wouldn't it have been easiest of all for Boeing to beg "let us have the airplane respond this way; all planes are different, right?" And even if the FAA allowed that, it'd force a new type rating, I suspect; the very thing they so badly wanted to avoid.
The standard (see below) requires stick resistance to increase as the critical (stall) angle of attack is approached. The MAX violated that requirement due to the aerodynamics of the new engine cowls. (So: why didn't they mess with the cowls? I suspect that wasn't possible without impacting efficiency, which is a key selling point of the MAX.)
Back to the spec: as noted, it exists to provide a consistent response curve to the pilot compliant with the regulation.
As borne out by these accidents, MCAS is Boeing's (quick & dirty) implementation of "artificial feel" to meet the spec. Big, transport planes with hydraulic flight controls have had artificial feel for many years to provide a consistent and properly scaled input response (not too heavy, not too light, etc.)
As far as the FAA specification in question, the critical section is in CFR 14 §25 Subpart B—Flight ¹, notably the sections on Controllability & Maneuverability and Stability. In these sections 'stick force' appears sixteen times; 'stick force curve' appears six times.
It's "stick force curve" that MCAS was created to tweak. There's no mention of "reduce the critical angle" or "change the stall onset speed" or anything about the aircraft performance. It's about how the plane handles in a particular part of the flight envelope².
> Every single piece of reporting I've seen on the matter refers to MCAS as an anti-stall device.
Because it was printed repeatedly doesn't make it true (see, Gell-Mann amnesia effect³).
²–I'm surprised that MCAS reacts fast enough to count as artifical feel. Electric trim doesn't move all that fast, AFAIK. Still an open question in my mind.
The 737 Max does fly differently, the MCAS and AoA checks to offset the engine "pitch up" due to more powerful engines was to get around a regulation/certification [1].
> The LEAP engine nacelles are larger and had to be mounted slightly higher and further forward from the previous NG CFM56-7 engines to give the necessary ground clearance. This new location and larger size of nacelle cause the vortex flow off the nacelle body to produce lift at high AoA. As the nacelle is ahead of the C of G, this lift causes a slight pitch-up effect (ie a reducing stick force) which could lead the pilot to inadvertently pull the yoke further aft than intended bringing the aircraft closer towards the stall. This abnormal nose-up pitching is not allowable under 14CFR §25.203(a) "Stall characteristics". Several aerodynamic solutions were introduced such as revising the leading edge stall strip and modifying the leading edge vortilons but they were insufficient to pass regulation. MCAS was therefore introduced to give an automatic nose down stabilizer input during elevated AoA when flaps are up.
The regulation that they had to make to fit within the 14CFR §25.203(a) regulation/rule was first tried by physical designs but ultimately settled on a sensor/software solution that constantly polls every 9 seconds to check the nose pitch/attitude and adjust, if it goes to0 far MCAS is triggered and pulls the nose down. Since there was a faulty sensor, this caused the nose dive catastrophic failures.
The 14CFR §25.203(a) regulation (a) is [2]:
>It must be possible to produce and to correct roll and yaw by unreversed use of the aileron and rudder controls, up to the time the airplane is stalled. No abnormal nose-up pitching may occur. The longitudinal control force must be positive up to and throughout the stall. In addition, it must be possible to promptly prevent stalling and to recover from a stall by normal use of the controls.
Since the change had to do with "No abnormal nose-up pitching may occur" in that rule, then the plane definitely flies differently as the cause of the MCAS and sensor flow is to constantly check for a nose pitch up that it corrects, if too far, enable MCAS to bring the nose down. This plane flies differently definitely and a bit opposite in that other planes will pitch down, it pitches up due to engine power of the larger more fuel efficient LEAP engines.
Ultimately the root of the problem was cost cutting which led to retro-fitting the 737NG to the 737 Max 7-10 to fit within cost/training/testing/regulations and in the end that was the problem that caused the end result of a software/sensor single point of failure which has squandered trust in Boeing engineering, management and safety as well as the 737 brand. Most people don't know the 737 Max is essentially an entire new plane. How the FAA let Boeing get away with this will be a focus as time goes on.
As a software engineer, the 737 Max looks like a legacy system hack that they tried to version 2 with it rather than make a new plane and incur all the training/testing/certifications of a new plane.
Boeing other planes don't have these issues, the 767 is has only had a couple issues beyond terrorism and those were related to pilots and fuel [3]. Two crashes of two new Boeing 737 Maxs within months of release and service is not a good trust enabling product.
I'm unconvinced that a software routine (MCAS) that can be (indirectly) disabled, and pilots are instructed to disable in the case of MCAS upset, is an acceptable work around for any portion of FAR 25 certification.
I think it's more likely that MCAS was intended to avoid a new type certificate for the MAX, thereby triggering FAR 61.31(a) requiring that the pilot be type rated.
Either way we have a problem here, as I see it. The aircraft flight manual and emergency AD 2018-23-51 specifically recommend a procedure that instantly makes the airplane not airworthy, or renders the pilot flying an airplane with behavior he's not really type rated for. This seems highly problematic, and I'm not able to account for it.
As far as I understand, the older 737 models also exhibit a nose-up pitching behavior in high-thrust/low-speed situations, to the point that stall recovery procedure explicitly specifies that the nose has to come down first, before thrust is increased. And maximum thrust may not be used, only max continuous thrust (or something similar) because otherwise the pitch moment from the engines may overwhelm elevator control.
Good question, apparently on the 737 Max this is more pronounced with the larger/forward LEAP engines.
This was enough of a problem that it constantly has to be checked and MCAS has to trigger if it is off by too much.
Most planes have a nose down pitch over time but the 737 is smaller/lighter so maybe the engines have always affected flying.
With the 737 Max and new LEAP engines, here it was enough for Boeing to make a system for it, they didn't make it just for extra, it was a cost cutting measure already.
> stall recovery procedure explicitly specifies that the nose has to come down first, before thrust is increased
Pulling the nose down is probably standard on any stall recovery because the nose up exacerbates conditions for a stall.
The problem wasn't really with the nose pitch up, but the nose pitch up created the need for nose up detection/monitoring and an MCAS in case of issues.
The major problem is that MCAS relies on a single sensor and a single point of failure, which can result in the MCAS constantly pitching the nose down if it is bad data or a broken/incorrect AoA sensor.
The root cause of this major problem is the cost cutting retro-fitting that Boeing did and their reliance on a single point of failure that can trigger a catastrophic nose dive.
This is one of those cases that the fix to keep the 737 flying the same as previous versions, without pilot knowledge of the MCAS initially, caused more damage than just the pitch up might do.
I don't think you understand the market the A32x and the 737 are in. They are planes flown by carriers who want to keep costs low. The MAX was designed the way it was because the airlines wanted more of the same with minimal retraining and support retooling. Boeing had originally proposed and may still pursue a carbon-fiber redesign of the 737 incorporating more of the lessons learned from the 787, but for now the airlines wanted and got a progressive improvement on the 737.
The MCAS system was designed as a response to FAA requirements and directives based on a concern about performance at the edge of the flight envelope. Since as we see it now (the public does not have enough information to conclude on how well the design process went except in the result) it was designed poorly and improvements are being made.
Once those improvements are made I expect the MAX to be, at that point a safer aircraft than the 737 NG. Its unfortunate that so many people had to die before the issue was identified, maybe congress should provide more funding for aviation safety enforcement and research at the FAA, NTSB and NASA.
The AoA sensor that MCAS uses, as well as the nose pitch monitoring adjustment due to the larger more powerful LEAP engines that causes a pitch up on the nose, is external and in the front [1][2].
> Stall sensors are common, but the MAX is the only 737 to have a blade-like sensor on the exterior of the plane that can automatically pitch the plane down when it detects stall conditions -- without input any input from the crew [2]
Not only is it susceptible to birds but it could be sabotaged as well from the location of it, if I were investigating it I'd check into maintenance/storage/possible sabotage just in case.
Since the nose pitch monitoring system and MCAS use the AoA single sensor it is a single point of failure, it also seems like a security issue.
About the single sensor and single point of failure[2]:
> Boeing's 737 MAX, the model being flown by Indonesia's Lion Air that crashed last October killing all 189 on board, had been criticized for relying on a single sensor to detect the aircraft's angle of attack, according to today's Wall Street Journal. A preliminary investigation by Indonesia's National Transportation Safety Committee (NTSC) blamed the stall prevention system (known as Maneuvering Characteristics Augmentation System, or MCAS) which relied on a the single sensor that provided erroneous data, causing the MCAS to misfire, leading to a series of events that put the plane into a nosedive.
> After the October crash, Boeing began updating the plane's software so multiple sensors would provide data to the stall prevention system, the company said in a statement on Monday.
About the external AoA sensor [1][2]:
> The 737 MAX with its larger engines mounted even more forward needed a separate sensor to sense stall, the nose up attitude of a plane that turns off aerodynamic lift over the wings. Stall sensors are common, but the MAX is the only 737 to have a blade-like sensor on the exterior of the plane that can automatically pitch the plane down when it detects stall conditions -- without input any input from the crew --according to Seattle Times veteran aerospace reporter, Dominic Gates, who is close to Renton, Washington where the 737 MAX is assembled.
> According to the preliminary report from Indonesia's NTSC and in a Boeing service bulletin, Lion Air flight 610 was providing erroneous data from a angle of attack (AOA) sensor. It appears the crew may have been fighting against: bad sensor data, a multitude of warnings and an automatic flight control system that seemed to be malfunctioning by automatically pushing the nose of the plane down repeatedly during the 11-minute flight. Ground control was contacted numerous times by the crew, who were repeatedly requesting permission to return to the airport.
That is really an interesting point on sabotage. Will these planes be cleared to take off without the sensor functioning though? I think the sensors failed after take off in these crash cases.
It's generally difficult to test these sensors before takeoff, it's basically a little blade or wing which measures the relative wind over the aircraft. Without forward speed it has nothing to measure.
On the lion air the sensor was non-operable from the start of the flight; so yes on both flights the AoA sensor was in a non-flightworthy condition.
One point of clarification: on the 737 and most other airplanes the airspeed is unreliable if the AoA sensor becomes damaged. This occurred on both the ET302 and the lion air flight. In such a state, it is up to the pilot to place the plane in safe flying state that does not depend on access to the airspeed. The pilot should by memory, ideally, set the thrust and nose up attitude of the plane along with other control surfaces. Failure to do this is what indirectly caused the AF447 disaster and it seems the the crew didn't execute this procedure on the ET302 flight. At the very least, attempting to engage the autopilot and disengaging flaps were contrary to standard procedure. Not executing this procedure dramatically increases the workload on the pilot and increases the risk that either airspeed wall outside of the safe operating range of the aircraft or the pilot will have to take drastic action to maintain airspeed in a safe range. Both are dangerous and even an experienced pilot can fail to take appropriate action especially in an emergency with the flight crew attending to other anomalies.
With that caveat stated, there is nothing inherently unsafe about flying with the combination of unreliable airspeed and an uncommanded MCAS activation in theory. The previous flight of the lion air flight was able to counteract 20+ instances of MCAS activation by simply trimming the aircraft using manual trim before they tried disengaging electrical power to the stabilizer motors. After disengaging trim the pilots felt comfortable continuing the flight and adjusting trim using the manual cockpit trim wheels. With all that being said, no aviation regulator would certify a plane that couldn't fly safely with an unreliable airspeed and manual trim turned off.
I think the question about why the 737 MAX's haven't crashed more is two fold. First, a birdstrike that takes out an AoA sensor is very rare. In that sense, Boeing got very unlucky in that they had a birdstrike that knocked out the specific AoA sensor tied to MCAS a month before they planned on rolling out the software update. Additionally, flight sensors are usually maintained very well as they are a critical item. You would never expect standard maintenance procedure not to fix an unreliable airspeed. When it has happened before though, the outcome can be tragic just as it was on the lion air flights regardless of any issues with MCAS.
And then the Cessna 182 has an aerodynamic switch that activates an electric "horn". And in either case they can get jammed up with bugs. But we do a lot of training with slow flight, approach to stall, full stall, and recoveries including recovery from the ensuing dive and secondary stalls.
I'm wondering now if MCAS should be an active system. Perhaps it should instead just warn the pilots that it thinks a stall is imminent instead, like when you get the stick shaking.
They cannot do that, because then the Max loses its shared type rating due to the larger engines. MCAS exists to give the aircraft more similar flight characteristics to its predecessors.
MCAS apparently exists for more than that. A few days ago someone posted a link and some quotes from the FAA regulations on pitch stability. They require that the control force must be positive up to and throughout a stall.
Without MCAS there would be a point on that MAX where you no longer needed positive control force to continue pitching up. Without MCAS or some other system to automatically counter that, so that the pilot needs positive control force to continue pitching up, the plane could not be certified even if they did go for a new type rating.
It's not that the force must be positive. It's the the force must be consistantly increasing up to the stall as well. Without MCAS, the problem is that the force does not continue to increase to the stall point. It does stay positive at all times.
Having to get a new type certificate would likely kill the MAX. I work in aircraft certification, and I know it would be a very long and slow process on the order of years.
Not only is it a long and expensive process, but the 737 type cert grandfathers in a whole lot of things that would not be permitted in a new type. So they would have to re-engineer a brand new plane from the wheels up.
Keeping the 737 type certification was a powerful incentive. Oversight investigation should look in to whether it should have been permitted by the regulator, and what other perverse incentives may exist in the certification process.
I wonder if it's feasible to build a guard to cover the AoA sensor to mitigate the ability of foreign objects damaging the vane.
Clearly it'd need to be very transparent to airflow—something like the face guards of an NFL player—a heavy gauge titanium cage or something like that.
Btw, the Wright Bros knew the importance of AoA and included one on the Wright Flyer. Implementation? — a length of straight stick parallel to the wing chord with a bit of ribbon affixed to the end :-D (KISS at work!)
AoA sensors are sensitive to very minor deviations in the surface they are mounted to, there are aircraft which don't allow any minor damage in that area because it can cause misreadings.
You seem to have a pretty high level of knowledge of avionics. Do I remember correctly that you worked in the field? If so, do you have any idea of what the allowable range of an AoA sensor might be?
i.e., on some systems I've worked on, we had a range that a sensor was expected to be in (normal, just do regular control loop), an outer range that was unlikely (stop reporting for a while/hold control output constant to see if it gets better or worse before warning operator), and a narrower range that was flat out impossible (notify operator of sensor failure/put system into a graceful shutdown).
I assume that the engineers designing this system had something similar, but given that MCAS activated with an AoA indication of 80 degrees (IIRC) and that's essentially impossible on a 737 (or at least would correlate with a hell of a lot of other warnings), was there anything they could do to warn the operator (pilot) that there was likely a bad sensor input?
From all outward appearance it appears they failed to do any kind of range check On the data. Although people were quick to point out that AF447 had a situation where the airspeed decreased to such a low level that the warnings stopped (because it was outside of any normal flying range) which was implicated as a source of confusion.
I was thinking whether they can "hide" an extra AoA sensor under the hood for emergencies. Just like a landing gear can be put down or retracted, an AoA sensor can be kept inside the fuselage, and brought out only when necessary. Maybe this one sensor will have better lifetime/reliability since it is not exposed to outside conditions.
My general practice is to assume that the engineers in a highly regulated field are competent and have good reasons for the things they do/don't do. If there isn't a guard, then it's likely that having one would cause more problems that leaving it off or it would be ineffective. e.g., hitting a bird at 100+ kts would damage both the guard and the sensor anyway, rendering the guard useless.
Given they test aircraft canopies by firing frozen (after defrosting) chickens at them it's usually a safe assumption.
Air travel is very safe because of literal generations of engineers working hard to make it safe, in this case the failure is one of procedure and people been people (cutting close to the wind on what was allowed).
Things usually tighten up after this kind of thing and then gradually loosen until the next disaster that could have been preventable.
Engineers can have their hands tied as well, limiting their options to doing the job or resignation. Perhaps putting a guard on the vane would have only been necessary if it was considered an intolerable failure and being flagged as an intolerable failure would have required a recertification of the plane or something. Just a guess.
I wonder if they could take the mesure from the underside of the plane (90 degrees difference from the front)? It might help for bird strike, not much for ice.
I wonder if a small array of microphones couldn't be used to accomplish the same thing by cross-correlating the sound made by airflow hitting adjacent surfaces at different angles.
Seems like a bad idea to use mechanical vanes for this, especially if you're going to bet the whole farm on a single instrument as Boeing seems to have done.
All equipment on the plane has a potential for failure... the question is what systematic design and pilot training is in place to take action in the face of failures.
What? Does the degree of failure not matter at all? That makes no sense. The question is whether all these parts are actually meeting the specified failure tolerance rate.
It matters, but if the rate of failure is high enough to be expected to be encountered within an all-fleet, constant flight environment for the lifetime of the aircraft, then you plan for failures as well as having the pilot know what to do when there is a failure.
In air sensors like this, their failures are higher than the rate at which you can ignore. They fail on their own, they get bumped and bent on the ground, they ice over in the air, or have objects striking them.
I don’t think it’s fair to put pilot training and systematic design right next to each other.
If the design in itself, and the subsequent factors of safety are at fault, pilots can’t recover from that fast enough. Why put them in a dangerous situation and expect them to recover. How long could this go on even if we didn’t have these two plane crashes. The pilots/airlines could be at fault for not training too much but the bigger issue is the system in the question.
It’s like saying the drivers don’t know how to drive because the manufacturer didnt put it front and center on the driver’s manual that the car suddenly swerves right. As ic drivers should always have their hands tight on the wheels and be ready for situations like that. It’s not fair.
There certainly are examples of sensors failing or providing conflicting data, and pilots using prescribed backup systems to rely on in order to get home safe.
This thing is a small fin on a swivel. It's a wind vane about 6 inches long, sticking out into a 500 mph airstream. It's a heavy-duty piece of metal, but that swivel joint makes it vulnerable to bird strikes, freezing, etc.
Hmm...if it works that way it seems quite easy to determine if it is working -- if it isn't swiveling then it is probably broken. Perhaps also you could make an active version of this sensor where there's a stepper that pushes it a bit either side of the current neutral position, then measure resistance to that push with a strain gauge. It might be possible to thereby know that you're pushing against flowing air, not bird guts jammed in the mechanism, for example.
Probably could be done but it would require significant reengineering because it introduces new failure modes. Best approach is what everybody else does: Assume the AoA sensor can fail and design the software accordingly. Boeing didn't do that and the results were fatal.
The elephant in the room, which I've not yet seen alluded to: Boeing wants at all costs (which will be very high) to avoid having pilots be required to requalify with new MCAS software in flight simulators.
Exactly, using mechanical vanes for this sounds pretty stupid, given what can be done with acoustical signal processing. It must be a more difficult problem than it seems.
Not necessarily. It could be that after doing the safety analysis, the mechanical method is less likely to fail.
Remember that there are usually many ways to skin a cat. Often the one chosen hits the sweet spot of reliability, manufacturability, cost (both initial purchase and operational), maintainability (e.g., how easy is it to test/inspect), etc.
When you have decades of experience with something and it works well enough, there's generally no reason to improve it when your engineering resources can be focused on more pressing problems.
I was a team lead on a new system that was based on the IBM ISA bus in 2013. The reasons were simply that it worked well enough and we had tons of experience with it and could reuse a lot of custom-built hardware and code. The only downside (and reason we switched), was that it was getting harder to find blade PCs that still had an ISA bus and the system was expected to be in the field for 15+ years.
I was hardware lead on a system that was the 2013 revision to an existing ISA-bus blade PC architecture. We threw it all out and switched to an off-the-shelf DIN rail PC from Beckhoff with snap-on EtherCAT modules. It took a little extra development time but it was 100% worth it.
This is not even remotely surprising, and by all standards should be taken into account in your implementation of dependent systems' gradual degradation fault modes.
