MCAS And The 737: When Small Changes Have Huge Consequences

When the first 737 MAX entered service in May of 2017, it was considered a major milestone for Boeing. For nearly a decade, the aerospace giant had been working on a more fuel efficient iteration of the classic 737 that first took to the skies in 1967. Powered by cutting-edge CFM International LEAP engines, and sporting modern aerodynamic improvements such as unique split wingtips, Boeing built the new 737 to have an operating cost that was competitive with the latest designs from Airbus. With over 5,000 orders placed between the different 737 MAX variants, the aircraft was an instant success.

But now, in response to a pair of accidents which claimed 346 lives, the entire Boeing 737 MAX global fleet is grounded. While the investigations into these tragedies are still ongoing, the preliminary findings are too similar to ignore. In both cases, it appears the aircraft put itself into a dive despite the efforts of the crew to maintain altitude. While the Federal Aviation Administration initially hesitated to suspend operations of the Boeing 737 MAX, they eventually agreed with government regulatory bodies all over the world to call for a temporary ban on operating the planes until the cause of these accidents can be identified and resolved.

Boeing continues to have full confidence in the safety of the 737 MAX. However, after consultation with the U.S. Federal Aviation Administration (FAA), the U.S. National Transportation Safety Board (NTSB), and aviation authorities and its customers around the world, Boeing has determined — out of an abundance of caution and in order to reassure the flying public of the aircraft’s safety — to recommend to the FAA the temporary suspension of operations of the entire global fleet of 371 737 MAX aircraft.

Until both accident investigations are completed, nobody can say with complete certainty what caused the loss of the aircraft and their passengers. But with the available information about what changes were made during the 737 redesign, along with Boeing’s own recommendations to operators, industry insiders have started to point towards a fault in the plane’s new Maneuvering Characteristics Augmentation System (MCAS) as a likely culprit in both accidents.

Despite the billions of dollars spent developing these incredibly complex aircraft, and the exceptionally stringent standards their operation is held to, there’s now a strong indication that the Boeing 737 MAX could be plagued with two common issues that we’ve likely all experienced in the past: a software glitch and poor documentation.

Unintentional Side Effects

It may be somewhat counter-intuitive, but the more efficient LEAP engines used on the 737 MAX are actually much larger than the engines used on previous versions of the aircraft. To make these significantly larger engines fit on the wing, they had to be mounted not only higher but farther forward than previous generations of the 737. Even to the untrained eye, the difference in engine size and position is clearly discernible:

737 MAX 8

737-800

It was found that this new positioning of the engines caused the 737 MAX to pitch up slightly during certain maneuvers, especially when the aircraft was already at a high angle-of-attack (AoA). In other words, when the nose of the aircraft was raised to gain altitude, the plane would start to climb higher than the pilot intended. If left unchecked, this tendency could potentially lead to a disastrous stall condition; where the aircraft has pitched up so far that it’s no longer able to produce lift. To counteract this quirk of the design, the MCAS system was introduced.

Put simply, MCAS detects when the 737 MAX is at risk of this pitch-up tendency, and compensates by using the aircraft’s rear stabilizer to bring the nose back down. When operating as intended the pilot shouldn’t even know that MCAS was engaged. It was designed to be a system that operated in the background, automatically providing the pilot with the ideal aircraft performance.

In fact, it was since been revealed that 737 MAX operators were not informed about MCAS, or trained on its operation. Documentation detailing the changes made between the two generations of aircraft didn’t mention the automatic system, as Boeing believed it wasn’t something pilots would need to be consciously aware of. As such, many pilots didn’t learn about MCAS until the first fatal accident had already occurred.

Erroneous Data

Automated systems which supersede the crew’s inputs on the controls are hardly a new development, and have been used on aircraft for decades. The McDonnell Douglas MD-11, an airliner which first flew in 1990, features a system called Longitudinal Stability Augmentation System (LSAS) that has direct parallels with MCAS in the 737 MAX. But what happens when they aren’t working correctly?

Could invalid sensor data be enough to engage MCAS while the plane is in level flight? Could this force the aircraft into an unnecessary dive, ignoring the pilot’s commands to pull up? Without training on the MCAS system, would the pilots understand what was happening and know how to disable the system to regain control of the aircraft?

These are precisely the kind of questions that investigators are currently trying to answer. Maintenance records show that the crew of the 737 MAX involved in the first fatal accident had previously reported issues with the AoA sensors. The plane had already put itself into uncommanded dives before the accident, during which the crew noted a twenty-degree difference between the readings on the left and right sensors.

Critics argue that had Boeing more clearly explained the nature of the MCAS system, crews would have had the chance to familiarize themselves with the override procedure ahead of time; potentially averting the disaster altogether.

A Tragic Lesson

The investigation into the second crash has only just begun, so it’s far too early to make any definitive claims about what brought the aircraft down. But with ground radar observations confirming the plane’s altitude was fluctuating before impact, there’s a enough concern that it could be related to MCAS that continuing to fly the aircraft without a thorough investigation would be irresponsible.

Before agreeing to ground the fleet, Boeing’s position had been that crews simply need to be trained on how to disable MCAS in the event that it received invalid AoA data. But clearly that solution wasn’t good enough for the FAA and its global partners; clear deficiencies in the system must be addressed. Improvements need to be made in how the system interprets conflicting AoA data, along with safeguards that will automatically override the system in situations where it’s not operating in accordance with the pilot’s commands. MCAS is supposed to prevent the plane from pitching up higher than intended, not keep the aircraft from gaining altitude when it’s already in a nose-down position.

It’s unfortunate that it often takes the loss of human life before faults like these are discovered. In the case of MCAS, these events are a stark reminder of the importance of documentation when developing new features. A glitch that causes unintended behavior in a brand new system is hardly a surprise, or even completely unexpected. But if the user wasn’t informed of how the system is supposed to operate, much less what to do when it malfunctions, the consequences can be disastrous. Pilots need to understand how their airplanes work.

Apparently it will pull up, the MCAS system will temporarily disable for 20 seconds before re enabling. This results in the noise pitching down again, and the oscillations can increase in intensity until a true loss of control occurs.
This is what I’ve read on an aviation reporting site I frequent anyway.

Ken- I noted you made comments on the documentation and training issue in the earlier threads, which gave me pause. I’m not familiar with how the aircraft industry works. I’m assuming that the manufacturer publishes an operating manual about the various features and operating parameters about the aircraft, but its up to the airlines to interpret these documents into flight manuals, providing various scenarios, procedures and training for their air crews? I’m sure I’m simplifying, but trying to walk your path to the same logical conclusion – if I’m following correctly, its a big wow.

I think I’m starting to see where there’s allot to lose on the airline’s side (possibly even the regulators, if they didn’t post a bulletin after the first occurrence), especially if the conclusion is that Boeing said “We told you about this, its right there in the Operations Manual. You didn’t incorporate this information in your training and procedures…..”. Again simplifying, but I think I get the gist of your comments.

Yes. I don’t hold Boeing blameless, but since one regulator found and appreciated the importance of the MCAS change, I have to believe the FAA in the US could have reached the same conclusion.

Also, the report from Dec. 2028 after the first crash where US airlines are asking for training or at a minimum expressing informed opinions on MCAS undercuts the argument that US airlines were ignorant of issue heading into March, 2019.

Any reasonable investigation should consider regulator oversight AND airlines responses after first crash in Oct. 2018.

I agree, yes some blame on Boeing, unless they can show from meeting minutes or other documentation during the air worthiness reviews that they highlighted this feature on this variant of aircraft.

I think what we’re seeing here is the continued shrinking of resources on all sides – OEM, Regulator and Airlines (like in every other industry). Where you may have had 100 people involved in the past, may be down to 1/3 the original staffing. It takes sharp minds to review all the documentation and make the right inferences about system interaction and how these mods may impact or increase risk – getting all this documented takes even more resources, sadly a lot of those headcount have been designated as excess and have been eliminated (hey – we have computers that can do all this, don’t need people….).

Kudo’s to the Brazilian regulators who saw this and raised the point – too bad this wasn’t highlighted at some global conference of regulators, air industry folks, or was it? May have saved some lives.

A timely post thanks.
Have watched heaps of “Aircraft Investigation” over the decades and especially where the combinatorial complexity of collisions vs gaps of human vs electronic controls and their unclear breadth/consequence issues not considered or which has raised so many issues – some beggar belief in that even recent (last 30yrs) aircraft design for cockpit controls/feedbacks make damn obvious errors precipitating disasters too easily. Eg The design selection, not a fault FFS (!!), to specifically not inform or even better to Alert pilots a partial disconnect of the auto pilot system has occured (for whatever reason) – sheer idiot negligence of the dumbest aspect of feedback as if the designers are retards – and this passed certification logistics not just Boeing but also Airbus too – aargh !
Might call up my archive of the oddest NTSB reports, looking forward to comments cheers.

It beggars belief that any commercial aircraft is designed so that the pilot’s control input can be completely overridden by the plane’s computers (I understand the necessity of doing this with some military planes such as the B-2 Spirit). This, in my opinion, is the single most idiotic and most tragic design decision that could ever be made for any vehicle (including automobiles). The human operator should never become a passenger to a computer. Too many lives have been lost to this sort of stupidity.
It’s for this reason that I will never ride in an Airbus aircraft, and now I’ll have to avoid Boeing as well. I guess that leaves me with Bombardier, Cessna, or flapping my arms really fast?

Indeed, I won’t fly Airbus due to its higher reliance on fly by wire And the fact that earlier on its autopilot system can disengage partially WithOut informing pilot !
My understanding was Boeing still employed hydraulics/cables under pilot control and with force enhancers alsos as if fly by wire re autopilot but, now I won’t fly more recent Boeing craft and prefer the 747. Will have to review the 727 and also now the 777 which I favoured for many years…

The issue is not that the system exists, it’s that it can take over when in clear contradiction with what the pilot’s want to do. Despite trying to pull up and gain altitude, it seems MCAS continued to force the plane’s nose down anyway. Considering the stated purpose of MCAS (to keep the plane from stalling out by pitching up higher than intended), it would seem there are fringe cases where the system is overstepping its authority.

To use the anti-lock brakes example, it would be like if your car was kicking on the ABS while you were driving down the highway and had your foot off the brake pedal. Having the system is fine, maybe even necessary. But it shouldn’t activate itself unless its the appropriate time.

The use of software to compensate for issues in the design of a modern aircraft in parallel to pilot control is extensive and well documented.

The issue here isn’t the fact that the controls are taken over by the software, it’s that pilots were not adequately trained to over-ride the system when it malfunctions due to faulty inputs.

The first crash clearly showed faulty sensor data (left and right sensors conflicted), but the pilot was likely never trained in the procedure to disable the MCAS.

The ABS example is valid, as a parallel imagine the sensor that triggers the ABS engaged when not needed, and it overrode driver controls, and the driver was never told how to disable ABS. The issue is a support system engaging due to flawed sensor input.

Plenty of pilots want to do dumb things. The assumption that they always make better decisions is just wrong. For the 2 crashes based on bad sensor data & poor communication on overriding it there are dozens of cases where the computer stopped the pilot from crashing the plane. But we don’t hear about those because all that happened was an indicator turned on and the computer adjusted the control surfaces.

It would be like having a clearly marked button to disable an improperly activated traction control system.

Everyone here likes to ignore the override facility, because then then they can declare the Boeing engineers incompetent, rather than hold the regulators, airline safety experts, and pilots responsible for not learning the MCAS system and it’s issues, and back that up with proper training and practice, as the Brazilian regulators did.

Modern ABS is often combined with Brake-By-Wire. Your brake pedal is more or less only a sensor input to the computer. Probably combined with a mechanical backup mode which is barely usable due to the required forces to stop a 2 ton vehicle without power assist. A Mercedes car from the early 2000s even had a second battery to ensure you can stop when the main battery is flat.

You sure about that second battery, the era sounds right but, not the utility ?
My understanding it was useful to accelerate the heating of the catalytic converter (CAT) when it was cold to minimise emissions as far as possible during warm up cycle – it was also positioned appropriately to not just dump that power with minimal resistivity ie close to CAT with shortest high current copper but, also balanced weight each side ie with the other battery along the car’s centre line side to side – got an industry reference supporting your claim ?
In any case are you therefore claiming manufacturers stopped using the cost effective engine vacuum assist for brake pedal function ?
Maybe you meant the Eaton/Bosch/Merc/BMW trials of enhanced electrical system around 42v beyond traditional 12v ?
Over to you Martin :-)

There is an enormous difference between the two… Both in design and the impact of failure. If ABS fails it fails safe and you will still have braking, it does not completely override you it just modulates your input. There are individual valves for each brake (at least nowadays). If you are using ABS every day you have issues (unless on track). It is a driver aid, it does not “take over”.

These “individual valves” aren’t for redundancy. They exist to allow the system to brake an individual wheel when software deems it necessary… without driver input. Manufacturers call this stability control or something similar, but in short, the ABS computer uses the braking force of an algorithmically-selected wheel to pivot a skidding car into the direction the steering wheel is turned.

This is more like you turn the wheel to the left…but the computer thinks its better to turn right…because its reading a series of zeros and ones.Any software is only good as the developer at solving yes or no queries…it can never replace human logic.

Do I have a choice to avoid anti-lock brakes?
They are a double edged feature.
The recover from lockup has in my experience been a win.
The anticipatory behavior which superceeds my brake pedal input needs to be excised from the designs.
Brakes make an implicit promise about performance as you use them. Then one day an unexpected event occurs which requires a somewhat urgent action on the brakes. The ABS gives a firm pedal and a longer braking distance instead. It is unaware of surface conditions, loose material, water, or ice on the road, rough asphalt, etc.
If we are supposed to drive like the brakes might break their promise, then don’t allow the promise in the first place.
Check with BMW if you are curious how this automation should behave if it is to assist drivers.

Humans aren’t great at applying the appropriate amount of force. As an example: there have been “hull loss incidents” because of the human pilot wrestling the rudder back and forth under high winds at too high a speed, eventually the rudder itself just got sheared off by the stresses. The computer system can keep those forces manageable, but still allow the pilot to fix their yaw.

That was an Airbus the month after 9/11. The manual for that plane stated that moving the rudder quickly back and forth through its full range of motion was Not To Be Done without pausing in the middle. The data recorder showed the pilot was whanging the rudder back and forth without any pauses. He kept at it until it broke almost the entire tailfin off. Then the violent yawing broke the engines off.

Boeing designed (at least used to) their planes so nothing the pilot could do with the controls could damage the aircraft, short of deliberately flying into the ground.

Airbus has tended to build their planes *just strong enough*. They continued that idea with their early fly by wire planes loaded with automation. That included saving fuel and reducing noise by having the computer control the throttle to allow just enough thrust for takeoff, and not allowing the pilot to override – at least not easily. They had some get smacked into the ground by wind shear and microbursts, crashes that might have been avoided had the pilot had full throttle. One happened at an airshow with just the flight crew aboard. Another incident, at another airshow, was when an airline wanted to do a low flyby with a load of passengers. The computer wouldn’t allow such a non-standard flight profile so the crew had to set the plane for landing and make some tweaks so it wouldn’t actually land. What they didn’t reckon with was that when set to landing, the system wouldn’t allow immediate full throttle and climb without first disengaging landing mode.

IIRC it was after that crash that Airbus finally relented and altered their software so the pilots could have full throttle and other overrides at any time.

Now it looks like Boeing had made a grave error similar to some that Airbus did. It would seem logical to me that since MCAS is a system that’s supposed to prevent excessive *climb* angle it should automatically disengage at negative angle of attack and be blocked from engaging whenever the plane is in level flight or any degree nose down. Also its degree of action should be set to progressively increase as AoA increases. The “PULL UP!” alert system should also be changed to include a check and forceful OFF command to MCAS to ensure that system is not trying to dive the plane into the ground.

But Fly-by-wire is not the aircraft flying for you. The fly-by-wire systems merely take the input from the two yokes and the A/P and relay the position data to actuators at the flight control surfaces. Fly-by-wire systems are actually safer than traditional cable system in that cables cannot get stuck (The cause of many, many accidents), they are triply redundant, and if the autopilot breaks the controls remain unaffected (As the A/P isn’t going to be sending signals to the position mixer).

If you are dead-set on avoiding fly-by-wire, your choices are pretty much piston aircraft or the train. Boeing and airbus aircraft have been fly-by-wire since at least the 1970s, Bombardier since the early 80s, Embraer the E175, Phenom, Lineage series, ATR, Antonov, Illyushin, Pilatus, Fokker, McDonald-Douglas, and pretty much any other aircraft with more than 12 seats is going to be fly-by-wire. Really, anything that is still in the air and powered by Turboprop/turbojet/turbofan engines is going to be fly-by-wire.

Which tbh is also dependant on a whole bunch of electrical stuff working too. There might not be as much in the train but the rest of the signalling system is (generally) electronic. They better stick with railways that still use wire cable signals.

I really doubt they don’t know, I perceive Boeing have the collection of resources to find out damn quickly months ago ie Lion Air but, did not draw attention to it for obvious reasons – rather take the time to fix ‘under the radar’ with the tacit assumption it was a one-off in a wait and see attitude – disgusting. These sorts of control systems discontinuities are getting all too common yet so very easily predictable of course from a probabilistic perspective so manage the probability by assessing leverage.
Eg BHP in Australia lost $300 million relatively recently over an ore train operator failure with only minor complication of a brake timeout. ie some nut allowed the brake system to detach without warning, the train had to be de-railed costing millions in track and train damage as well as loss of time and settlements. Simple Boolean logic could have pointed to that potential FFS yet it as never addressed as a potential needing to be fixed (the direct intervention ticket sign-off issue) – the facile adage of “..if it ain’t broke don’t fix it..” failed dismally as it has in several airliner crashes precipitated by logic failures complicated by physical design changes, arbitrary rules without education and assumptions “..ain’t gonna happen, we trained them”, basic human management psychology of key personal missing and negligence in education certification of pilots dealing with new models due to inertia and complacency…

I think you’ll find BHP were very fast to blame it directly on the operator; instead of the value-engineered, lowest bidder, built by low-paid/slave labour, only one-human-on-train-to-save costs attitude BHP and most other corporates have. Reminder – BHP is a major shareholder in the mines that had those horrific dam collapses too. They’re arseholes.

Before any flight, even a civilian flight of a small aircraft, the pilot should perform a weight and balance calculation. On commercial aircraft, this is done almost automatically, I believe. There is a range of positions on the wing where the balance point can be to achieve a safe condition for take off and flight. The reason they allow you to move around after takeoff is likely due to the fact that, during takeoff, you have the least amount of lift available and it’s most critical to have a proper balance. During flight, you’re burning fuel, which can change balance. Also, higher velocity creates more lift, making the airplane more controllable. There is still a limit to the balance point position, though.

Not done automatically, but rather accomplished by flight planners at the airline. What also helps is that modern airliners carry so much fuel that the weight of the passengers doesn’t upset the Center-of-Gravity enough to affect the flight. Passenger flights, especially the empty ones, will also carry large amounts of cargo (The USPS contracts with US-based airlines for transporting mail. Many other countries do the same)

In flight, changes in center of gravity can be compensated for by minute adjustments to the trim or by cross-feeding fuel between tanks. But, for the most part, a few 200-pound passengers aren’t going to upset the weight/balance of a 175,000 pound aircraft with 30,000 pounds of fuel in the wings.

I did have one flight, with a connection, where they did ask us passengers to redistribute ourselves in the cabin. For some reason, the computer seated everyone at our originating airport at the back of the plane, and those at the middle airport in front of us. Without us sitting randomly in the plane, there was too much weight in the back for them to safely move the plane from the gate, let alone try to take off.

I’m also concerned about the noise and smoke people reported seeing from the plane prior to the crash.
Perhaps an engine failure (FOD?) caused the plane to leave the normal operation profile and the software took over?

If so it points to the sadly too often problem in the 3rd world of fuel contamination or slack maintenance contributing to loss of oil Or could it be blade failure by birdstrike, the sooner Boeing disclose flight voice recorder the better of course with data recorder summary the better…

That’s a good point, and if accurate would seem to support there being some other issue with Ethiopian Airlines Flight 302, though that doesn’t necessarily mean the MCAS problem wasn’t involved. It’s just too early in the investigation to say much, the flight recorder was only just recovered earlier this week.

Of course, it’s also true that in accident investigations the early eyewitness accounts are often misleading if not completely false. People have a tendency to see what they want to see, and the facts of the case are sometimes in direct contradiction to what eyewitnesses claimed.

“Of course, it’s also true that in accident investigations the early eyewitness accounts are often misleading if not completely false.”
I watched television reports of the 737 crash at Colorado Springs (decades ago) and one of the eye witnesses was a doozy!
“I could see the passengers at the windows were waving red flags to warn people on the ground that they were about to crash!”

So, even with a triple redundancy, if data from the sensor is coming, an autopilot won’t even bother trying to validate it as it probably can’t – it can only access his own pitot!. The 2ndary sensor is tied to the 2ndary autopilot etc.

The thing is, as soon as the autopilot commands weird unexpected maneuvers, any sane pilot will disconnect it and revert to manual flying, so redundancy is not urgently needed (or the redundancy is implemented as two automatic humanoid monitoring systems). The situation is very different of course with a system like MCAS that is active in manual flight too and not easily disconnectable when it malfunctions.
I agree though, the notion that there is an undocumented, unmonitored, not easily deactivated system that can erroneously pitch down a plane just from one faulty sensor input is pure insanity.

I know we have the benefit of hindsight, but the people charged with designing these things are supposed to have good foresight.

If they are smart enough to have redundant sensors, then they should be smart enough to design for an inconsistency between the two sensors. It seems obvious to me, a layperson in this field, that in the event that there is an inconsistency between two sensors critical to determining a specific course of action AND the users input contradicts what the machine thinks the specific course of action should be, the machine should automatically defer, at least partially, to the user.

Sadly, these systems are designed by engineers, who by reputation, are not “People Persons”.
Many design by catalog, not by function.
I’ll get some slams for this post, but that’s expected.
My group, led by engineers, decided to replace some infrastructure with 100 year replacements.
Other engineers got involved, and changed some specs.
“Unintended Consequences” resulted in failure in three years, not 100 years.
Because the group was led by engineers, no body was found at fault.
I suspect the same could be said of San Onofre power plant.
Led by engineers, no fault found, tax payers must pay for the incompetence.
EFF!

>> tax payers must pay for the incompetence.
No, the rate payers, both Southern California Edison and San Diego Gas and Electric customers. And none of what SCE collects from Mitsubishi Heavy Industries is going back into our pockets.

Yes, your missing the whole history of automated systems in aviation. When these systems first started to show up they always deferred to the pilot to take final action. Lots of planes flew straight into the side of mountains on autopilot with the flight computer screaming the whole way at the pilot. Pilot’s ignored the system warnings doubting the information that the system was giving them. Plenty of voice recordings from the cockpit have proven this out. Eventually the lay public screamed at the engineering staff how could they let a plane not take corrective action on its own. So they changed the system and gave the computer more authority to make calls. The number one cause of aviation accidents is still human error, followed by weather, then mechanical failure. As a pilot, certified aircraft mechanic and engineer I have dealt with it from every aspect. Adding more system or components to check for more possible modes of failure just introduces more modes of failures.

This lead to two design philosophies: Airbus the computer is always right, Boeing the pilot better know how to kill the computer in a hurry and take over.

Now I suspect the lay public will push for more pilot authority over the computer until enough pilot error accidents swing the pendulum back to the computer.

I think Airbus is more, “the design must insure the computer is right, hand unaugmented control to the apes only if the shit is already flung by the fan”. Boeing seems to have had more of “the pilots will catch it if things aren’t right”.

I think the big problem with MCAS is that it seems to be more Airbus philosophy than Boeing, and Boeing pilots are used to being able to arm wrestle the autopilot when they disagree with it. Give the autopilot a bad sensor, like the frozen Pitot tube that doomed Air France 447, and you have to know procedures that are almost never used to overcome the bad computer decisions. Boeing pilots are used to just being able to pull harder on the stick when it’s fighting them, and knowing it’s designed to let them win if it’s really serious. It’s not wonder that these pilots are outraged that MCAS is different and that they weren’t told about this very important difference.

The Air France junior pilot thought that a pitch up equals altitude gain. The plane was heavily loaded with passengers and fuel at a high altitude so this clearly wasn’t the right strategy to gain altitude over the storm they encountered. Indeed the plane was actually losing altitude the whole time and by the time the captain figured out the issue they were already nearly in the water and it was too late to save the aircraft. The captain realize they needed to dive but they had no altitude left to do so.

I have nothing to go on but my gut here, but calling this set of changes minor an incremental, along with a manual that pilots say bordered on criminal negligence – due to sins of omission – says to me that someone was trying to say something on the order of “these changes are incremental, and waffer-thin, so do not require the expense and time of a recertification”.
Despite being needed for a problem obvious enough to Boeing they felt they had to add MCAS in the first place.
Again, just a guess…

Indeed, it seems the 737 MAX was a kludge to an existing design, and that MCAS was a kludge on top of that.

Boeing had originally intended to replace the 737 with a new aircraft but got scared off by the development costs and associated risks, and that a new aircraft would cost them the advantage of their huge installed base of 737s.

So, they instead set out to build and sell a new iteration of the 737. To hit fuel-efficiency and capacity promises they fitted new engines and made various aerodynamic improvements. When tests showed that they changes resulted in an aircraft that didn’t fly like the existing 737 fleet, they developed a software workaround and then concealed its existence from airlines and pilots so they could, on paper, at least, meet the promise that the MAX would just be another 737 from the point of view of pilots and fleet management.

So, I guess that’s actually three kludges, with the deception being the third kludge.

It’s hard to separate the deception from the re-engineering of Boeing’s corporate culture over the last two decades, which included a campaign to put congresspeople in every state on “retainer.”

… and moving them forward lead to the instabilities.
Boing could have mounted the bigger engines at the old place but that would have required an expensive expanded reauthorization/-certification and Airbus were just around the corner with their A320 (if I recall correctly from a NY-Times article….

If it stays hidden, it would be OK. But it didn’t. Although there is a big difference: In the case of the Boeing plane people died. The diesel story was just some environmental tax or regulations issue. “Only” financial impact but luckily nobody died or was in danger of death.

“Automated systems which supersede the crew’s inputs on the controls are hardly a new development, and have been used on aircraft for decades. The McDonnell Douglas MD-11, an airliner which first flew in 1990, features a system called Longitudinal Stability Augmentation System (LSAS) that has direct parallels with MCAS in the 737 MAX.”

The MD-11, nearly 30 years ago, required LSAS as just one example, so yes.

This is very typical that the software people does not know anything about flying an aircraft. The test pilots of the aircraft does not know anything about software. Very typical for a large company that are making physical product(s) and creating software for the product.

Unfortunately this happens more often than it should, a software error causes a crash and people die and the corporations try to cover it up, the same thing happened when the Airbus 320 was introduced, but the cover up there was successful, Boeing on the other hand is going to have to eat it.

And you didn’t understand at all what occurred.
The aircraft was asked to fly too low by the pilot. Because an airliner is not a fighter plane, it cannot instantly do a nose up and pull full throttle to avoid the trees.
The aircraft computer prevented the pilot from stalling the aircraft due to a too high angle of attack. Landing on trees is still better than stalling and falling like a brick.

Actually there is a pretty good school of thought that the software failed and Airbus, to keep its brand new airplane from getting a black eye, tampered with the black boxes, in collusion with the French government (who also stood to loose billions) and put the blame on pilot error. Personally I agree with this school of thought.

They had to set the plane to landing mode then tweak some settings so the plane wouldn’t actually land. Then they forgot that when set to land, the computer is *going to land*. The pilots either didn’t know or in their panic forgot they had to disengage landing mode before the plane would allow throttle increase and climb.

IIRC it was after this airshow crash that Airbus finally listened to the pilots and changed their systems so the pilots could have full throttle and other overrides any time they needed. Some other Airbus crashes had been caused during landing or just after takeoff, when hit by wind shear or microbursts. If the landing pilots had been able to get full throttle simply by shoving the throttle forward, or the ones taking off had been allowed full throttle takeoff (as any sane jet pilot does!) they may not have crashed.

Airbus was trying to cut noise and save fuel by limiting throttle to ‘just enough’ during takeoffs. Pilots prefer to take off at full throttle so if anything goes wrong the plane is already at full thrust, giving it a chance to power through and gain enough altitude to make it back around to land, or carry on with the flight if the problem is just a sudden burst of bad wind. With the computer having the last word they had no chance.

Pilots may prefer full thrust takeoff, but almost all takeoffs of commercial jets (any manufacturer) are reduced thrust takeoffs, because it saves operators huge amounts of primarily engine maintenance and also fuel. Engine wear scales exponentially with Exhaust Gas Temperature, so just backing off e.g. 7% from full thrust reduces wear by 25%.

Not fuel, actually. Derated takeoffs cost more fuel, due the aircraft staying at a lower altitude for a longer period of time. It also increases noise production, and is, arguably, detrimental to safety by lowering the margin on remaining runway in case of a rejected takeoff

Wait a minute, you are wrong. In this particular accident the pilot applied full trust and tried to gain altitude. The plane didn’t respond and crashed only a few seconds later into the forest. BUT: The auto pilot (software) command for not to lift the nose up, despite the pilot’s order, was 100% correct. At the time of the accident, the pilot was flying the plane at a very lo speed, almost stall speed, and with the nose being at a high angle of attach. When he suddenly saw the trees in front of him, he applied maximum trust and tried to pull up the nose of the plane immediately. But the acceleration doesn’t come imediately as soon as you put full trust. It needs quite a few seconds. The computer noticed that with the extreme lo speed that the aircraft had that moment, the lift of the nose would cause further reduce of the speed and stall. So, if it was not the computer, the aircraft would have gained some altitude, but after that it would have stalled and crushed immediately.

Just one correction: to increase altitude, a pilot would increase power. To decrease speed, a pilot would pull up the nose of the aircraft.

“In other words, when the nose of the aircraft was raised to gain altitude, the plane would start to climb higher than the pilot intended. ” – this is incorrect.

Translate this to the reverse, which is used during takeoff: power goes full, nose goes a little bit up to ‘lift’ the aircraft from the runway, nose gets pushed down to gain speed and altitude. Altitude is gained by increased lift, which is accomplished by increasing airflow over the wings, which is accomplished by increased power. Should you ‘nose up’ to gain altitude during initial takeoff, you need way more power and get lower speed, which is not what you want. Flaps function as a ‘lift increaser’ during slow speeds where the AoA is high, for example during landing.

Nitpick to be sure, but you also need to pull the yoke back for liftoff. Most of these occurences seem to be shortly after liftoff where the pilot has just pulled the yoke back to initiate the climb under full power, and instead of just relaxing the backward pressure while the craft starts to gain airspeed, the Max 8 tends to stay at the high angle of attack (AOA) and low airspeed, and potentially even increase its AOA due to the placement and thrust vector of the new engines.s
Pilots are trained to closely monitor their airpeed in this phase of liftoff, and are trained to be aware of the onset of a stall. My position is that the MCAS is designed for inattentive pilots, but has ended up catching even the attentive pilots off-guard. A stick-shaker and audible alarm, both of which are already present, is sufficient to refocus any inattentive pilot back to the task at hand.

During cruise, sure. But the incidents are happening during a powered climb, shortly after take-off. MCAS kicks in (or is supposed to) when the AoA is already high from the pilot pulling back on the yoke.

Could some altimeter, airspeed, and gyro reading have been used to confirm that the plane is not is a stall?
Do planes receive some sort of weather or wind info that could be used to help feed into the information along with heading as a sort of rough AoA calculation?
None of these have a high degree of accuracy but it might be able to provide an extra sanity check to the system?

I’m sure I’m missing some reason other than just ‘sensor fusion is hard’.

More like, “we don’t need sensor fusion, it’s AoA that’s the problem and we have a sensor for that”. The fix/patch that got held up by the us govt shutdown was apparently to use sensor fusion to detect more cases when the system should NOT activate. (Likely pitch angle, speed, and altitude would be added factors)

The most logical thing would be to have the system absolutely without fail disable MCAS in level flight and at any time the plane is any degree nose down. The “PULL UP!” alert should also forcibly disable MCAS, no matter what orientation the plane is in.

Using mechanical wind angle sensors to inform MCAS seems to me to be rather risky. How easily can things like dust or bug splatter interfere with them? What happens to the airflow across the sensor winglet if a big insect splatters across it during takeoff?
Can such debris around the sensors cause whacky micro turbulence that can cause the sensors to move improperly?

A few dollars worth of solid state gyro and accelerometer chips should be more reliable for detecting the planes angle(s) and rate(s) of rotation in all directions. At the prices they sell for it would be cheap to automatically grade bin them then use five per axis with system that uses an average and periodically self tests each chip. Build the box for $500 total, sell it to Boeing for $10K.

>The most logical thing would be to have the system absolutely without fail disable MCAS in level flight and at any time the plane is any degree nose down.

And how would you do that when the sensors that are built to tell you the plane’s nose up/down attitude are giving you wrong conflicting information (e.g. one -5 and the other +20 degrees, as in the Indonesia crash)?

>The “PULL UP!” alert should also forcibly disable MCAS, no matter what orientation the plane is in.

The stated MCAS objective is to prevent stalls in high pitch, high power situations. If you get yourself into such a situation shortly after takeoff or go-around and lose height as a consequence, GPWS (“pull up”) would activate immediately, rendering the MCAS useless. Not a good solution.

>A few dollars worth of solid state gyro and accelerometer chips should be more reliable for detecting the planes angle(s) and rate(s) of rotation in all directions. At the prices they sell for it would be cheap to automatically grade bin them then use five per axis with system that uses an average and periodically self tests each chip.

You severely underestimate the amount of testing and certification costs and efforts that go into aero systems. (Which is why this apparent complete systems design failure on behalf of Boeing with the MCAS is so baffling). And looking at my phones gyro that can barely keep pointing one direction for 30 seconds, I don’t want that near life critical systems at all.

NO! You can’t get airflow from how the aircraft is moving through the world because you don’t know how the air is moving relative to the world. What matters is how the aircraft is moving through the also moving air. You could be doing 180 knots according to your GPS, gyros and accelerometers, but if you were also in a 100 knot jet stream you would also be falling like a rock with about a 45 degree angle of attack. You have to measure airflow. Nothing is cheap on certified aircraft. A third AOA vane and the optional AOA Disagree system would have been a good investment.

It was just announced today that Boeing is going to retrofit the previously OPTIONAL dual sensors for MCAS system into all planes and include it as standard equipment going forward.

It seems low-budget carriers were opting to order only a single sensor for MCAS in an effort to save money.

Yet another datapoint showing that Boeing didn’t so much hide MCAS as much as previously claimed. I have to imagine since it was listed as a purchasable option, the dual sensor question must have provoked some level of conversation within the airlines before placing their orders.

Life endangering computer code should legally be required to be open source. I would like to see the Tesla code that has killed folks and the Boeing code that caused these crashes. A for profit company is not competent to audit its own code. Patents exist to encourage disclosure and still protect innovation. That companies don’t use the patent system this way is evidence of both a failure of our laws and the patent system. Non-open-source code is always a danger. The only way it will ever be determined if Boeing was negligent is through law suits that require disclosure of the code and systems that caused the accident. It is far more likely that every suit bought on behalf of the victims will be settled without a trial and the code and systems that caused the crash will remain secret.

Public Record? I want to be able to see and review the code and controls. Stringently tested? How do I (or you) know without being able to see it. It is possible to “stringently test” bad code and still not find bugs. As a retired CS professional I have seen medical companies (no aircraft companies) with “stringently tested code” harm human beings with their code. If it isn’t open source and available to me, my lawyers and the merely curious CS student, it shouldn’t be in an airplane or a car intended to carry humans. It addition it should also be “stringently tested”.

The patent system was developed because of scandals such as this. See Obstetrical forceps on wikipedia.
Peter Chamberlen the elder invented the obstetrical forceps the family kept the instrument secret for at least 150 years. Life threatening code should never be allowed to be proprietary. It should be open source and may be protected by both patent and copyright. The deal is: You must make your techniques public, and we the people will give you an exclusive right to use this technique for limited amount of time. This is essential for any code that may be life threatening.

I think you’re confusing open source and free software. You can absolutely have a license that allows others to examine the source code, while preventing it from being used for anything beyond research purposes.

It does’t need to be “open source” just copyrighted/trademarked public record. This allows anyone to investigate the code for issues while it still being protected under a copyright/trademark that other’s cannot use it to create a competing product.

Not a software expert then? Go read ARINC-653. What caused these crashes is still under investigation. However, this is actually a system design issue, not a software issue. The system was designed to work this way, then that description was handed to the software teams for implementation. The system did what it was designed to do. What caused the Tesla crashes is idiots treating driver assist as self driving. Teslas with driver assist are 3.7 times less likely to be involved in an accident than experts like you.https://qz.com/1414132/teslas-first-accident-report-claims-its-four-times-safer-than-the-us-average/

The moment I heard of MCAS and what it does, I’ve thought it was stupid. As a commercial pilot (albeit helicopter, not air transport), I can say with certainty that anything which modifies my yoke position without telling me so is stu-u-pid.

We’re taught from private pilot training day 1 to recognize the onset of a stall and prevent it by pushing the stick forward. To have this system do that automatically means I no longer know how much I need to push it forward, or pull it back once the stall is averted.

Their mistake is trying to make the Max 8 handling characteristics similar to the earlier 737 generations. Pilots know what aircraft their flying and develop an intuitive feel for each. Let the Max 8 be the Max 8 and pilots will recognize and compensate for the upward pitch at higher AOAs. To assume we would need help with that is insulting and, as has been proven, dangerous.

Why oh why would you put a system in that automatically noses the craft downward, but yet not put a similar system in for recovering it back upward?

The fact that Boeing were saying it was completely safe until around the time that the black boxes were found, after which they also grounded their fleets out of ‘an abundance of caution’ suggests Boeing feel there might be an issue with the plane.

My point was that the sequence of events, at the moment, does not particularly suggest a bomb but that there may be something wrong with the planes. The fact that they have grounded the planes is welcome. What surprises me is that they initially chose not to ground them.

I am a professional freelance software engineer. I have worked over 30 years in many sectors, including car engine control units, train safety systems and various military systems.
Everyone knows how things SHOULD be done, but companies rely on people. In good companies, with good managers, things are done right.
In other companies, where money is tight, or managers have (to my mind) not the best intentions of the company/project/end product’s best interests at heart, things don’t happen as they should. Some managers, seem perfectly happy turning up to work, authorising, what I would call, basically hacking the bear minimum to tick some boxes and get the next pay cheque in, seemingly with no concern what-so-ever about the ultimate end result of what they’re authorising.
I have challenge some of these managers. Often, the answer I get back is that “project management/the customer/QA/whoever seem OK with what we’re doing at the moment, so I’m going to ignore your (perhaps accurate) concerns, and carry on as we are, doing what I know to be, but can’t admit to you, is frankly wrong”.
A few bad people in the key positions, or a few good people in key positions make A MASSIVE DIFFERENCE in any company’s/project’s outcome.

And I’m afraid that USA/UK have their own legal systems to blame for companies not openly admitting when they’ve done something wrong and discovered it, even when other lives may be lost because of their non-discloser. Where there’s a blame, there’s a claim… An abhorant presupposition in my view.

I’ve worked in Software Valudation in the clinical drug trial industry, and our processes were what I would call fairly rigorous – every system we produced was exhaustively tested and documented, and post implementation we knew, by contract, every system we brought live the client drug company would send their own auditors to challenge every aspect of development, validation, acceptance testing and ongoing review of their system.

To imagine Boeing ‘cut corners’ and put lives at risk because of the US legal system, and you know, they just don’t care based on nothing more than personal is an insult to the professionals that designed, wrote, and tested that software.

The best information is this:

New, larger engines were fitted to the 737

Those engines changed the performance characteristics of the plane

Software was developed to compensate for the challenges present in the new configuration

The software provided an over-ride/disable mechanism

The new software and override/disable procedures were ignored by regulating bodies (except in Brazil, where pilots were forced to train/practice the override procedure)

(It appears that) Two crashes were caused by pilots not overriding/disabling the new software when it was wrongly engaged (faulty/conflicting)sensor
Readings

Not sure the software engineers are responsible for airlines not training/practicing like they should have, the software appears to have worked as designed, and when conflicting readings caused a problem, the pilots failed to execute a procedure they were never taught.

All fine and dandy if you ignore the fact that Boeing avoided mentioning the system in their own manuals, which they should have regardless of wether regulatory bodies would require that inclusion or not.

You can hardly blame pilots and airlines for too little training when they don’t even know there’s something they need to train on.

> The best information is this:
“A half baked set of information is this:”

> New, larger engines were fitted to the 737
true

> Those engines changed the performance characteristics of the plane
The placement and physical characteristics of those engines lead to stability issues in some critical flight situations.

> Software was developed to compensate for the challenges present in the new configuration
that’s a little vague and you’re missing the fact that this piece of software apparently had only on sensor to relay on. That’s not what I’d call redundancy..
And MCAS basically limited the Pilots ability raise the AoA above 20° (not sure about that – can’t find the source anymore), while older versions of the 737 were fine with an AoA of >20°.

> The software provided an over-ride/disable mechanism
When you don’t know which set of sensor information are true (pilot/co-pilot) and don’t even know anything about the system that’s influencing your plane right now, it is kind hilarious to believe pilots are realistically able to work through the text-based help system in a very critical phase (liftoff & climb) and disable the unknown system while they have to “fight” with the plane for unknown reasons….
The MCAS disable mechanism might as well have been under a random passenger seat…

> The new software and override/disable procedures were ignored by regulating bodies
That’s just misleading/wrong. Fact is that Boing tried to hide MCAS because they can sell more new planes if the pilots don’t need any retraining. And the FAA as well as the European counterpart were persuaded to go along with not requiring the pilots to even learn about MCAS

> (except in Brazil, where pilots were forced to train/practice the override procedure)
true

The plane had two sensors, which provided conflicting information, as stated in the article.

A failure to publish/promote disabling the MCAS is not a failure of the software engineers. I don’t hold Boeing blameless, but I don’t see evidence of a software failure at Boeing.

How did Brazilian regulators detect a change everyone else ignored? That tells me all the non-Brazilian regulators shirked their responsibility, they should have come to the same conclusion as Brazilian regulators.

“These are precisely the kind of questions that investigators are currently trying to answer. Maintenance records show that the crew of the 737 MAX involved in the first fatal accident had previously reported issues with the AoA sensors. The plane had already put itself into uncommanded dives before the accident, during which the crew noted a twenty-degree difference between the readings on the left and right sensors.”

A change Boeing made to the 737-400 without sufficiently ensuring pilots knew about it, led to a crash in the UK. Originally the 737 took its cabin pressurization only from the right engine compressor. The then most recent 737 model had been changed to get cabin pressure from both engines, so in the event the right one had to be shut down completely there would still be cabin pressurization. (The one engine pressure design seems to be a bit of stupid.)

On this flight, they had a fire in the left engine, accompanied by a lot of vibration and smoke entering the cabin and cockpit.

Since the pilots ‘knew’ the 737 only took cabin pressure from the right engine they throttled back the left (still on fire!) engine and put the right (good!) engine to idle. That stopped the smoke, and the reduced engine RPM almost stopped the vibration.

But the pilots ignored the tachometers and engine temperature gauges and other indicators that showed the problem was with the LEFT engine. All because as veteran 737 pilots they knew without any doubt that smoke inside a 737 meant the RIGHT engine was on fire. Passengers and flight staff saw the right engine on fire but nobody bothered to go tell the pilots “Oi! The port engine, she’s afire!”

Since the good right engine was producing only idle thrust and the throttled back and burning left engine was producing thrust below what it would have at its throttle setting, the plane’s sink rate was greater than expected, not much lower but down at the lower bound.

As they came in for approach, they throttled up the left engine, which with its reduced RPM from the broken fan, vibration and fire damage, flamed out due to too rich a fuel mix. Still believing the right engine was bad and the left good, they tried a windmill restart (too slow airspeed for that even with a good engine) instead of taking a chance on throttling up the right engine they believed was bad.

The plane struck the ground, bounced across the M1 motorway (miraculously there were no vehicles at that spot on the busy road) then broke up on the embankment at the end of the runway.

Had they realized their errors in their assumptions even a few minutes sooner, they may have been able to at least scrape out a belly landing. Amazingly, 79 people survived.

Had every airline flying The 737-400 made certain to inform all their pilots about the changes in the bleed air system, and that the engine vibration sensors in the 400 actually were accurate, had the airlines instituted a protocol that flight staff *must* inform the crew of problems visible from the cabin… there were so many operational problems going on where any one been handled differently, that crash could have been prevented.

Hopefully Boeing has learned from this wont add systems capable of affecting the performance of the airplane in future planes and not tell operators and pilots what those systems are and what they do (and how to disable them in the event of an emergency)

The FAA’s DER system is fundamentally flawed. You essentially have the design regulators being paid (and competing for work) for the very companies they’re meant to be regulating.

I’ve had personal experience of a project where the DER has been advising the company which things should and should not be presented in the formal documentation order to meet documentation standards whilst avoiding having to make safety related changes which would impact delivery times had a clearer picture been presented.

This conflict of interests does not happen with EASA and similar. Their regulators are hired and paid by EASA; their only concern is that correct process has been followed by suitably qualified people and, if the design or change does not prove itself safe, they will and have shut down deliveries while it is fixed.

FAA DER is flawed, yet the superior EASA also failed to appreciate the changes in MCAS. I assume EASA had to approve 737 Max 8/9 before it entered into service in Europe, and if EASA merely ‘rubber-stamped’ FAA approval, meaning they accepted FAA DER results, then EASA system is not superior to FAA DER.

It’s not possible the MCAS program doesn’t validate the stall vane data it receives and cuts out if not the same while they must verify even reference voltages at the sensor. I suspect because of the engine induced pitch up and down the autopiliot/AT didn’t handle it right somehow. When A/P is engaged the MCAS is disconnected on the 737. Probably they did not upgrade the A/P program to handle it or both were trying to do things by some error! I like they were laughing at Airbus at some point about things like that however!

You’d think any sensor system which had highest leverage import such as potential disaster would have a basic ‘disagree’ notification. Would Boeing charge a bit more if it also had an audible alert eg if pilots distracted in storm or busy on radio or one of the gets a blackout/stroke etc – geesh ???

Question arises and for the previous lion air flight before it crashed where a visiting pilot saved the plane if any sort of alert whether visible or audible would have enabled pilots to turn off MCAS etc Yet another autopsy where human factors need to be merged with control systems…

As s third-tier airline, they likely opted not to connect the second sensor to MCAS (that was an extra-cost option many lower-tier airlines opted to not install). Boeing announced today they will retrofit all 737 Max planes with secondary sensor.

If you opted to not connect second sensor, there would be no second reading to alert when there’s a disagreement.

Oh, and the pilot never trained on the 737 MAX simulator, so he/she had no idea how the plane worked/responded to boundary situations like this.

It is really unfortunate that the wall street greed of quarterly targets is driving down engineering and safety short cuts, thus resulting in loss of precious life. My heart goes to the families. It is very evident from the crash that the decision makers were not engineers, instead were business leaders making decision to drive down cost and sell product that was plagued with fundamental flaws. That is, putting a big engine on the same 737 frame to avoid re-certification process, and then putting a MCAS bandage to avoid positive pitch due to large engine. while competition is healthy and drives technology and better products, but I tend to believe now, the same principles are not healthy when it could threaten life.

This should not be about airbus or Boeing or others, where they are competing to take market share. We need to find a better way of managing complex technology. The day of autonomous cars, drones, air taxi and stuff is not far

You are imagining a whole lot and assigning blame to everyone’s favorite punching bag ‘bean counters’.

MCAS was documented (Brazilian air regulators noted it and required pilots get training/practice on it), airlines choose to only hook MCAS to one sensor (connecting two sensors was an extra cost option), and opted not to have an MCAS indicator on the console.

Third-tier airlines went cheap and paid the price.

The major carriers knew about MCAS in Dec. 2018, choose to complain rather than train.

There’s plenty of blame to go around, but it isn’t all on Boeing ‘bean counters.’