Boeing 737 Max Crashes: Sensors Vulnerable to Failure
bloomberg.com
bloomberg.com
Fix:let the FAA do it's job independently
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...)
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/).
"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"
I guess you and I disagree on the definition of "absolutely".
EDIT: expanding: I understand "stall" as an end-result, and AoA as one of the sensors that might be an indicator of a "stall"
EDIT2: thx for that URL => I'll have a look at it - looks very interesting.
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
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 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.
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.
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...
[1] https://avherald.com/h?article=47d74074
EDIT: incomplete citation
https://en.wikipedia.org/wiki/XL_Airways_Germany_Flight_888T
which I think had to do with New Zealand regulators following up on
https://en.wikipedia.org/wiki/Qantas_Flight_72
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.
>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.
"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.
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.
[0] https://philip.greenspun.com/blog/2018/11/11/boeing-737-cras...
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.
Much of this is discussed here which I found to be decent: https://www.satcom.guru/2019/04/what-happened-on-et302.html
incredibly it just dumps the stab and leaves it to the pilot to get it back.
Electric trim must be used to neutralize control column pitch forces before cutout!
I'm hopeful that they have analysed what happens if the AoA returns more or less random data.
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 :)
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.
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.
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.
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 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.)
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'.
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.
Pitch != AoA.
https://aviation.stackexchange.com/questions/2287/can-the-pi...
http://www.aerospaceweb.org/question/aerodynamics/q0165.shtm...
"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."
https://www.nytimes.com/2019/04/08/business/boeing-737-max-....
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.
"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
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.
Shouldn't this have been more of a red flag not to rely on a single sensor when human lives are literally at stake?
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.
You would need a sensor to measure relative wind. Angle of attack is the angle between the wing and the relative wind.
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.
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.
What are you basing this assumption on?
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.
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?
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.
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...
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.
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.
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.
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.
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.
For a good, in-depth explanation, see http://www.av8n.com/how/htm/aoa.html#sec-ias-aoa
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.
CL(AoA) = Az.m/(q.A)
(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.)
This is not true at or near stall conditions.
(If the flight conditions are that unstable, a mechanical AoA vane will struggle too, since it has mechanical inertia.)
CG doesn't enter into it except to second order due to horizontal stabilizer lift.
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.
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.)
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?
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.
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.
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.
[https://theaircurrent.com/aviation-safety/boeing-nearing-737...]
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.
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.
Another issue could be the failure mode, if it failed at or near 0 AoA it wouldn't cause too many safety of flight issues on a normal flight.
MCAS is only required to maintain a positive slope to AoA - stick force curve.
MCAS resulted in 2 crashes because the implementation was completely brain dead. Not because the aircraft is impossible to fly without it.
You and other keeps parroting this line, I don't believe it to be true. MCAS is an anti-stall device, show me once source that says otherwise.
> Not because the aircraft is impossible to fly without it.
Not impossible, but possibly also not safe. The system was implemented to prevent stalls in the MAX 8 planes due to it's flight characteristics.
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.
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.
"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³).
+++
¹–https://www.ecfr.gov/cgi-bin/text-idx?node=14:1.0.1.3.11#sp1...
²–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.
³–https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect?wprov...
NB: this comment is edited/recompiled from snips of earlier comments I posted.
(me: FAA licensed aircraft dispatcher in a previous life)
> 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.
[1] http://www.b737.org.uk/mcas.htm
[2] https://www.law.cornell.edu/cfr/text/14/25.203
[3] https://en.wikipedia.org/wiki/Category:Accidents_and_inciden...
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.
So what is "normal" nose-up pitching?
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.
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.
> 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.
[1] https://i.imgur.com/XTrf6EX.jpg
[2] https://www.engineering.com/ElectronicsDesign/ElectronicsDes...
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.
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.
Those are expensive and it was a specific goal to avoid them.
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.
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!)
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?
Not sure if you caught this post https://philip.greenspun.com/blog/2019/04/08/boeing-737-max-... which I think is basically the same idea as you are suggesting.
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.
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.
it would probably just get blocked then by bits of bird.
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.
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.
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.
Triple redundancy is pretty common in safety critical systems.
According to https://www.satcom.guru/2019/04/what-happened-on-et302.html it was swiveling freely because it was broken.
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.
Sometimes you gotta throw it out.
> Boeing 737 Max Crashes: Sensors Vulnerable to Failure
Mods should likely change it.