News for hackers. Stuff that matters.
Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Sunday February 06, 2022 @11:17PM (#30240359)
The author makes the bizarre assertion that runaway trim is only caused by short circuits, and would only be continuous (not intermittent), and therefore the pilot would not recognize the MCAS runaway trim as runaway trim:

http://www.gregorytravis.com/WhyDoesNotPresent/

First off, as an engineer who often has to find and fix electrical short circuits, they'd be easy to find if they were continuous. They're frustratingly intermittent.

Secondly, I worked on the design of the 757 stab trim system. Runaway trim is the trim system coming on and trying to crash the airplane - it being intermittent is NOT part of the diagnosis. That intermittent vs continuous NEVER was part of the discussions about runaway trim. I don't know where that notion comes from. It doesn't make any sense.

Anyhow, the author certainly knows a lot about Cessnas. He stretches this into knowing about 737 systems, a much more complex airplane in its systems and aerodynamics, and he stretches it past the breaking point.

Re:How the Boeing 737 Max disaster looks to a software devel... by tgsovlerkhgsel on Sunday February 06, 2022 @11:27PM (#30240421)
There is strong evidence against the assumption that this should be something that a typical flight crew can handle, in the form of the smoldering wreckage of not one but two planes, each with a trained, professional crew.
Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Sunday February 06, 2022 @11:32PM (#30240457)
You're right that there's something wrong with the training. There were 3 flights that had MCAS failure. All three were able to restore normal trim with the electric trim switches, which override MCAS.

#1 turned off the trim system and continued the flight without incident. (This flight is almost never mentioned, as it doesn't fit the narrative.)

#2 never turned off the trim system and crashed.

At this point, an Emergency Airworthiness Directive was distributed to all MAX pilots instructing them to restore trim with the electric trim switches and then turn it off.

#3 turned off the trim system when it was severely nose down, and crashed.

Re:How the Boeing 737 Max disaster looks to a software devel... by salawat on Monday February 07, 2022 @01:07AM (#30241003)
>This flight is almost never mentioned, as it doesn't fit the narrative.

It was mentioned repeatedly Walter; if not in the articles, then in the comments. The fact remains that afterward, when regulators put more pilots (two military and one civilian trained) pilots into single-event upset simulations, 1 of the three failed to recover the plane in time.

If you acknowledge the training was faulty, then just let it be. Trim runaway presenting continuously vs. intermittently may not seem that important from a clean room engineer's perspective, but when viewed by a pilot through the lens of instruments, blaring alarms, and whatever else is going on in the cockpit, my engineer's optimism favors not relying on the human being perfect, or the defect only happening at a non-terminal part of the flight regime.

It sucks that it played out the way it did. Maybe if someone would have spent as much time on MCAS and the pilot training as you did the 757 auto-trim, it wouldn't have been an issue.

But they didn't. And innocents paid for it.

Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Monday February 07, 2022 @01:38AM (#30241142)
> 1 of the three failed to recover the plane in time

Without more information on what the background and training of those pilots, and why the one failed, I'm afraid it's just an anecdote.

In both crashes, the trim came on repeatedly and the crews repeatedly brought it back to normal with the electric trim switches. 25 times in the case of the LA crash. They obviously knew that the trim was the problem, because they took this corrective action. The trim running is obvious by the large black&white spinning wheels in the cockpit, and the deliberately loud clacking sound the running trim makes.

All they had to do was then turn it off.

> But they didn't. And innocents paid for it.

That's right, and that's the tragedy.

As to why they didn't, who knows. The stab trim cutoff switch is right there in a priority position on the console, because it's a damned important switch. Dealing with runaway trim is supposed to be a memory item, i.e. memorized.

It does suggest a training problem.

Re:How the Boeing 737 Max disaster looks to a software devel... by PicassoCTs on Monday February 07, 2022 @05:37AM (#30242886)
It suggests a system design philosophy problem. A system that continuously goes into a erroneous state instead of a safe state (turn off automatically and rely on manual trim) is designed badly. It couldn't be designed better, because cooperate added the requirement to remain within the flight model of the 737 at all cost.

Nobody is blaming the engineers for this. But it is, by design, a bad system, that can by attrition defeat human decisions.

Re:How the Boeing 737 Max disaster looks to a software devel... by salawat on Monday February 07, 2022 @02:19AM (#30241355)
Here's the article I was thinking of, though I think it was originally either in seattletimes or WSJ.

http://airsoc.com/articles/view/id/5d5143c7c4263ce96fd616b6/...

Differen source.

https://aviationweek.com/air-transport/software-fix-will-add...

The civillian trained test pilot lost it. The two military pilots did not.

Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Monday February 07, 2022 @03:07AM (#30241709)
Thanks for the reference. I haven't seen this information before.

"In one scenario, the bits chosen first told the computer that MCAS was engaged when it wasn’t. This had the effect of disabling the cut-off switches inside the pilot-control column, which normally stop any uncommanded movement of the horizontal tail if the pilot pulls in the opposite direction."

The cutoff switches cannot be disabled on the airplane.

"They flew the same fault scenario again, this time deliberately allowing the fault to run for some time before responding. This time, one of the three pilots didn’t manage to recover and lost the aircraft."

That's kinda vague.

Re:How the Boeing 737 Max disaster looks to a software devel... by salawat on Monday February 07, 2022 @03:15AM (#30241766)
https://www.seattletimes.com/business/boeing-aerospace/newly...

There it is! Knew it was in SeattleTimes somewhere!

And lookout for the part about disabling cutoff switches, I think Dominic might have written that better, because I think he's talking about a safety function that was removed specifically for the MAX where hauling back hard on the yoke would stop trim commands in progress on NG airframes? MCAS required that that functionality not be ported forward to the MAX.

This isn't disabling those cutouts though. Those are literally, like you said, a hard switch.

>According to a second FAA source, it was the AEG pilot, representing a typical U.S. airline captain, who failed to recover the jet.

There's the bit about the civilian test pilot.

Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Monday February 07, 2022 @03:24AM (#30241839)
Thanks. My experience is Aviation Week is a much more reliable source on technical topics.

It's a hard switch for good reason. I hate "soft" switches that supposedly disable microphones. Phooey on that.

BTW, on my hotrod I installed a hard switch to shut off the fuel pump, as well as an oil pressure switch that would shut it off. I have a g-switch to cut it off, too, but haven't gotten around to installing it.

Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Monday February 07, 2022 @03:20AM (#30241802)
The article also does not mention the LA flight that survived the MCAS malfunction. Hence it always fall to me to mention it.
Re:How the Boeing 737 Max disaster looks to a software devel... by mannykannot on Monday February 07, 2022 @08:14AM (#30244360)
Flight into wind shear does not always lead to crashes. This does not mean that there is no need to train pilots for it.
Re:How the Boeing 737 Max disaster looks to a software devel... by SAI_Peregrinus on Monday February 07, 2022 @09:49AM (#30245568)
If the trim runs away far enough (which it clearly can, more easily because MCAS was also activating the stick shaker which is INCREDIBLY DISTRACTING) it can become impossible for a pilot to physically turn the manual trim wheels to get back into trim.

So the procedure for runaway trim (turn off electric trim, use hand wheels) doesn't work. You have to instead use electric trim first to get back into normal trim, then turn off the electric trim, and never turn it back on for that flight.

Re:How the Boeing 737 Max disaster looks to a software devel... by jcalvinowens on Monday February 07, 2022 @10:13AM (#30245887)
> ... it can become impossible for a pilot to physically turn the manual trim wheels to get back into trim

I feel like this isn't talked about enough. I had no idea how bad it can actually get: https://youtu.be/aoNOVlxJmow?t=806

Re:How the Boeing 737 Max disaster looks to a software devel... by dhx on Monday February 07, 2022 @11:27AM (#30246992)
The difficulty of using the manual trim wheels is also demonstrated in this simulator run showing the MCAS problem: https://www.youtube.com/watch?v=xixM_cwSLcQ&t=1011s

There is some discussion amongst pilots at https://www.pprune.org/tech-log/619326-boeing-advice-aerodyn... which further explains how difficult it can be to manually reduce load on the stabilizer and manually trim the nose up.

Re:How the Boeing 737 Max disaster looks to a software devel... by salawat on Monday February 07, 2022 @06:44PM (#30253141)
I did some napkin math to try to calculate the force that'd have to be applied to the jackscrew to actuate under load, and it was not a small number. Basically, an electric motor with the torque of a sporty automobile.

With the gear ratios we're talking with by hand actuation, I would not want to have to be one of those pilots.

Re:How the Boeing 737 Max disaster looks to a software devel... by yunohn on Monday February 07, 2022 @08:01AM (#30244221)
> It does suggest a training problem.

Aviation rules are written in blood. Training is being updated and fixed. But regardless, MCAS itself is controversial and fallible - it’s crucially important that Boeing make it better.

Re:How the Boeing 737 Max disaster looks to a software devel... by MayeulC on Monday February 07, 2022 @03:53AM (#30242030)
IIRC, #1 also had an extra pilot at hand, and that extra pilot is the one who suggested turning off the trim system.
Re:How the Boeing 737 Max disaster looks to a software devel... by oldsecondhand on Monday February 07, 2022 @07:58AM (#30244190)
> #1 turned off the trim system and continued the flight without incident. (This flight is almost never mentioned, as it doesn't fit the narrative.)

I.e. they piloted the plane without the MCAS, which they were not trained to do. The whole reason of the existence of the MCAS is to avoid training the pilots to fly the planes without it.

Re:How the Boeing 737 Max disaster looks to a software devel... by throwaway0a5e on Monday February 07, 2022 @09:55AM (#30245647)
>I.e. they piloted the plane without the MCAS, which they were not trained to do. The whole reason of the existence of the MCAS is to avoid training the pilots to fly the planes without it.

This kind of hand wringing shares a non-negligible part of the blame for why hundreds of people are dead.

If Boeing had been allowed to say "of course our new engines are gonna pull the nose up a little harder, throttle back and climb slower if you don't like it" the MCAS system would never have been built to be the safety critical boondoggle it became. The plane itself handled just fine but the problem that they tried to solve with MCAS is that it wasn't identical to the prior 737. Even the most incompetent professional 737 pilot can fly a 737 that wants to <insert control input here> slightly when <insert other control input here> so long as they're expecting it (remember, they train for this stuff in simulator and most of these pilots are certified for multiple different aircraft) but just letting the pilots deal with it wasn't an option because the regulations disallowed that due in large part to decades of "people are just dumb cogs" type thinking.

And once the airplanes started falling out of the sky nobody could say "just turn of MCAS, it won't handle the same but close enough" because Boeing, the airlines and the FAA were all so balls deep in the lie they'd look like idiots if they changed their opinions and thanks to the society we've cultivated nobody is willing to be the first to break formation because that's who gets targeted by the bulk of the fallout.

Re:How the Boeing 737 Max disaster looks to a software devel... by Gwypaas on Monday February 07, 2022 @01:03PM (#30248559)
That is not correct, it simply would not be certified as airworthy without it. Differences in feeling between airplanes are fine. Airbus has a system of common type ratings allowing fairly quick transitions. Especially between A330, A340 and A350.[0]

> MCAS is a longitudinal stability enhancement. It is not for stall prevention (although indirectly it helps) or to make the MAX handle like the NG (although it does); it was introduced to counteract the non-linear lift generated by the LEAP-1B engine nacelles at high AoA and give a steady increase in stick force as the stall is approached as required by regulation. > 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.

http://www.b737.org.uk/mcas.htm#background

[0]: https://www.airbus.com/en/products-services/commercial-aircr...

Re:How the Boeing 737 Max disaster looks to a software devel... by salawat on Monday February 07, 2022 @08:59AM (#30244921)
This is the part that bugs me as well. When you have to disable MCAS, you're flying a plane you've not trained for. Particularly given the fact MCAS featured prominently in the landing regime.
Re:How the Boeing 737 Max disaster looks to a software devel... by landemva on Monday February 07, 2022 @10:14AM (#30245910)
"The whole reason of the existence of the MCAS is to avoid training the pilots to fly the planes without it."

That summarizes why the plane did not go through a new type certification process - avoid costs of pilot training. Boeing instead painted over the differences (larger fans mounted forward) with software to make it feel the same.

Re:How the Boeing 737 Max disaster looks to a software devel... by hinkley on Sunday February 13, 2022 @08:46PM (#30327563)
The classical problem in software and apparently in engineering is that some suit with a big mouth makes promises that can't be kept, and then makes everything difficult for everyone else by trying to make their lie true. Either people sacrifice their health, sanity and families bending over backward trying to cover for them, or some safety problem makes it into the product due to false constraints.

The 737 Max was sold on not having to do certain kinds of retraining. "Something wrong with the training" is a divide by zero error here. There was no training. If memory serves this was also tied up in how much and what kind of recertification the FAA would require for a 'new' plane versus a refit of an existing one. Training means newness, and newness means retesting. The lies snowballed into dead passengers.

Re:How the Boeing 737 Max disaster looks to a software devel... by caconym_ on Monday February 07, 2022 @11:50AM (#30247406)
I don't think GP is suggesting there was some issue with the training. I think they are suggesting that it's very difficult to justify MCAS (as originally implemented) as WAI when it quite clearly brought down two airplanes full of people.

This seems a bit of a non sequitur from your first comment, but you did reply (here). I'm still not sure what your point is, though. What "narrative" are you referring to?

Re:How the Boeing 737 Max disaster looks to a software devel... by na85 on Sunday February 06, 2022 @11:59PM (#30240618)
>The author makes the bizarre assertion that runaway trim is only caused by short circuits

That's not the only problem with TFA. I worked on the Hercules, not any of the Boeing airliners, but this "30-year pilot" has some pretty fundamental misunderstandings of how MCAS works, what the effects of moving the engines are, and what actually went wrong with the 737 Max. Color me surprised.

Regurgitating the same "MCAS prevents the aircraft from stalling because it's unstable" shlock betrays the author's surface level (at best) understanding of the issue.

Re:How the Boeing 737 Max disaster looks to a software devel... by alexose on Monday February 07, 2022 @12:11AM (#30240697)
As a surface-level-understanding layman myself, what about this is wrong? The 737 MAX is unstable, no?
Re:How the Boeing 737 Max disaster looks to a software devel... by na85 on Monday February 07, 2022 @12:12AM (#30240708)
>The 737 MAX is unstable, no?

No, it's not unstable. The 737 Max exhibits stable pitch behavior along the entire envelope. A lot of people think "unstable" means "it crashes" but these terms have precise meanings.

The 737 Max is a stable airplane. One of the problems it exhibits is that with increasing angle of attack, the stick force does not increase (linearly is the requirement, I think, I'm writing from memory here).

The way you know this is because MCAS moves the horizontal stabilizer directly, and not the control column that the pilot is holding. An anti-stall device like a stick pusher or a stick shaker provides tactile feedback to the pilot via the control column. Moving the horizontal stab directly is (basically) altering the trim of the aircraft. Thus it is a handling-qualities system.

Re:How the Boeing 737 Max disaster looks to a software devel... by alexose on Monday February 07, 2022 @12:28AM (#30240795)
I see. So calling it "unstable" isn't really fair. It's more that it just flies differently enough that it would feel unfamiliar to typical 737-trained pilots.
Re:How the Boeing 737 Max disaster looks to a software devel... by salawat on Monday February 07, 2022 @01:17AM (#30241054)
Correct, but it's more subtle than that. FAR's are prescriptive. To carry passengers a plane from the pilot's perspective must have that linear increase in stick pressure required to pull into a stall, otherwise it can't be certified for carrying passengers.

This is part of why the MCAS could not be decoupled from the flight computer as I recall. If you turned off MCAS, you'd be non-compliant in the wind-up turn flight regime, and when coming in on final if I recall correctly.

So in aerodynamic parlance it is stable, but with disqualifying flying characteristics that had to be mitigated via a gadget whose nature, failure modes, and existence was largely hidden from the pilot, and downplayed in the FMEA/FMECA. (Failure Mode, Effects, and Criticality Analysis)

This downplaying was specifically intended to keep regulators from stipulating enhanced training for pilots. Thereby saving money.

Re:How the Boeing 737 Max disaster looks to a software devel... by na85 on Monday February 07, 2022 @01:29AM (#30241108)
This is a good summary.
Re:How the Boeing 737 Max disaster looks to a software devel... by Dma54rhs on Monday February 07, 2022 @12:53AM (#30240945)
Not getting pilots retrained was the cost saving strategy for companies buying the new area aircrafts.
Re:How the Boeing 737 Max disaster looks to a software devel... by WalterBright on Monday February 07, 2022 @01:47AM (#30241189)
Not needing retraining was a good goal because it improves safety. Sometimes airplanes have crashed because in a crisis the pilot did the right thing for another airplane he was trained on, but was the wrong thing for what he was piloting at the moment.

It's not just a cost saving measure.

MCAS was a sound concept. It's implementation, however, was not sound at all.

Re:How the Boeing 737 Max disaster looks to a software devel... by asd4232 on Monday February 07, 2022 @03:32AM (#30241891)
A typical pilot switches aircraft type multiple times in their career. It's all about the cost and convenience ultimately, allowing same pilots to fly both 737MAX and the older 737NG as most 737MAX customers operate both.

As far as MCAS goes, in my opinion Airbus got it right already in the 80's in their A320 with their flight envelope protection.

Re:How the Boeing 737 Max disaster looks to a software devel... by wikfwikf on Monday February 07, 2022 @04:55AM (#30242544)
Do you understand how delusional it sounds in this specific context to say that not needing retraining improves safety? Not that it might improve safety or should improve safety, but that it does improve safety?
Re:How the Boeing 737 Max disaster looks to a software devel... by dpark on Monday February 07, 2022 @09:24AM (#30245237)
"Not needing retraining" is another way of saying "works as expected".

Yes, it would likely have been safer if the 737 Max worked as expected by the pilots flying it.

Re:How the Boeing 737 Max disaster looks to a software devel... by rramadass on Monday February 07, 2022 @08:57AM (#30244885)
Rightly said!
Re:How the Boeing 737 Max disaster looks to a software devel... by mannykannot on Monday February 07, 2022 @08:09AM (#30244311)
> Not needing retraining was a good goal because it improves safety.

That only works if retraining is not actually needed. Boeing's own test program gave adequate (but undisclosed, at the time) information for an independent observer to conclude that this was not the case here.

Re:How the Boeing 737 Max disaster looks to a software devel... by VBprogrammer on Monday February 07, 2022 @08:42AM (#30244685)
I'm not sure I could agree that MCAS is a sound concept. Moving the trim automatically to account for the pitch up at high angles of attack feels like a hack, like restarting a dodgy service every couple of hours rather than fixing the underlying issues.

I've never understood why the fix wasn't implemented in the elevator feel computer. Except perhaps that it doesn't have AoA inputs and it's an old hydroelectrical system for which there may be a lack detailed knowledge.

Re:How the Boeing 737 Max disaster looks to a software devel... by ummonk on Monday February 07, 2022 @12:17AM (#30240732)
No, it's always stable. The issue is that pulling back further on the control stick wasn't causing an increase in force feedback at high angles of attack, making it more likely for the pilot to inadvertently stall the aircraft.
Re:How the Boeing 737 Max disaster looks to a software devel... by mopsi on Monday February 07, 2022 @07:59AM (#30244199)
> That intermittent vs continuous NEVER was part of the discussions about runaway trim. I don't know where that notion comes from. It doesn't make any sense.

It comes from Boeing's checklists: https://i.stack.imgur.com/cRG4J.jpg

It makes perfect sense, because continuous operation identifies a fault condition. Under normal conditions, automatic systems may intermittently move the stabilizer, but never continuously. It may be faulty when moving on its own, but if it moves continuously without input, it's definitely faulty. That's where the name cames from: runs away into physical stops.

Re:How the Boeing 737 Max disaster looks to a software devel... by techie128 on Monday February 07, 2022 @12:06AM (#30240661)
Weird part is that IEEE published this. Someone might actually take it seriously...