[jonplackett]

Reminds me of the news coverage of SpaceX’s first landing attempts, where they crashed into the barge and exploded and everyone was like “it’s a failure, it will never work”. Yeah but so much went right.

I think it’s just the (well deserved) media narrative Boeing is in now. When you kill hundreds of people and then pretend it wasn’t your fault, you get what’s coming to you.

[khuey]

The obvious difference is that SpaceX's landings were secondary objectives and something that nobody had ever done before. Getting in the proper orbit to the ISS was a primary objective for Starliner and something we've been doing for 20 years.

[Grimm665]

I don't know, space is hard and things go wrong. Just because we've done it hundreds of times doesn't mean we should expect perfection.

[remarkEon]

Yes it does?

These are known engineering problems with known engineering solutions. The explanation from Boeing was that a timer was set incorrectly. This sounds like a trivial error to me (though I'm not a "rocket scientist" just a "kerbal scientist", I guess, but we've been using timers for a long time afaik to properly manage burns to orbit).

[frostburg]

Let's take a moment to consider the fact that apparently the MCAS uses input from only one of the two AoA sensors on a 737 MAX and swaps which one it takes the data from after each flight. I can't grasp how everyone involved could fail to realize that this statistically makes it less safe than only having one sensor.

I don't know how much the systemic issues that clearly compromised the design of the plane extend to the design of the capsule, but trivals errors seem to be very possible.

[toast0]

> I can't grasp how everyone involved could fail to realize that this statistically makes it less safe than only having one sensor.

This design is bad, but it makes sense as a update of the 737. The flight computer setup is each pilot gets a computer under their chair, each computer gets its own set of sensors and the computers take turns each flight. The flight computer is generally safe (i don't think it's been implicated in any crashes?), but that's because in case of issues in flight, the system usually will disengage and alert the pilot, or if the system takes poor actions, it will disengage when the pilot opposes it, or the pilot will disengage it.

Adding MCAS to the flight computer makes sense, the flight computer needs to be aware of it. It's understandable, but negligent, to add a new feature to the computer without considering the original design. The problem comes in when MCAS was not disclosed to pilots, doesn't disengage on errors, doesn't disengage when pilot input opposes it (partially by design), and can't be disabled except by disabling electric trim, which is more or less needed to recover from the error condition MCAS puts the plane into.

I think this is fixable, but the public information on the current fix doesn't include being able to turn MCAS off, so it doesn't seem like they've really done enough.

[bumby]

Of course they realize it makes it statistically less reliable. I think the gap is it becomes much more difficult to assess the probability of failure between different systems. In the case of MCAS, they already had the ability to override it. In complex systems one domain may think a simple mitigation is sufficient (e.g., the pilot can override MCAS) without understanding the layering of other issues (e.g., human factors like complex controls, lack of training etc.) Meaning from the standpoint of a single domain, that simple mitigation maybe incorrectly be assumed to bring the risk probability into a reasonable range.

I think it’s important to acknowledge the process failures like lack of communication between domains rather than acquiesce to simple conclusions that are more clear only in hindsight.

[mlyle]

The procedures and how software systems handle changes to launch time are members of the set of hundreds of thousands of choices made during design and implementation that need to be validated. Yes, they feel like a "silly mistake" but ultimately most things that lead to failure will be in that category.

[ethbro]

Or, in other words, getting to space is hard because it requires millions of opportunities for silly mistakes.

Most complex engineering projects are hard not because of one thing, but because of the mind-bogglingly large number of things that must all be done correctly.

(1 - x) ^ y, where x is the chance of each small mistake and y is the total number of opportunities, doesn't need a very large x, if y is large enough, for things to start looking dicey.

[camkego]

Yeah, this is a key insight, and something I didn't learn as a software developer with many years of experience until I studied probability formally. Maybe these days this is better known. This is also known as the inclusion-exclusion principal and can be used to model failure probability.

[sitkack]

At some point we do, and that time is now. How qualified are you to give them a pass?

[Rebelgecko]

After SpaceX's failures, lots of people were saying things like "This is why they test— if you're not occassionally failing, you're not pushing the limits enough".

I would guess that at least in part the difference in attitudes is because SpaceX is considered more startup-y and Boeing is more associated with the "failure is not an option" ethos.

[bkor]

SpaceX still put satellites in orbit. From what I understood, SpaceX tests the entire software where they simulate launches. Something such as different timers should've been caught already.

Anyway, I do not care too much about pointing fingers elsewhere. The parachute thing was quite embarrassing and IMO this problem should have been prevented as well.

[Rebelgecko]

Boeing still put a capsule in orbit too. And I actually saw those excuses I'm referring to when the BFR prototype blew its lid, which didn't involved even a partially successful mission. Similar things were also said when the Crew Dragon blew up on the ground.

Regardless, testing all of the flight software is certainly not exclusive to SpaceX. I would bet any amount of money that Boeing also tested their software and performed simulated launches, moreover that testing is probably mandated by their contract with NASA. My uninformed guess is that one of two things happened:

1. Their tests were incomplete. e.g. they didn't find some edge case that would cause problems when the T-0 changed.

2. Someone goofed the procedures on the day of launch and didn't update their configuration properly.

[kevin_thibedeau]

That negative messaging was driven by ULA in a desperate bid to close the door on their new competitor. If they could kill off enough contracts, SpaceX might have run out of runway before they established their business model.

[jonplackett]

There were lots of scientists and ‘experts’ on our TV in the UK. Do you think they were part of that? That would be some impressive PRing.

[mlyle]

It's easy to be indirectly involved in something like that. Your PR finds outside experts that agree with your world view, because journalists often ask you where they can find independent validation of your claims.

Then when something like this happens, you can have your PR call up journalists they know and suggest a name or two that is likely to say what you'd hope for.

[themeiguoren]

Citation? That’s the first I’ve heard of it and that’s a pretty big accusation.

[WalterBright]

A significant share of the blame for the crashes accrues to the pilots who did not remember/follow emergency procedures for runaway trim. There was also the LA problem of putting an airplane back into service despite the critical malfunction on the earlier flight.

To reiterate, the procedure is:

1. restore trim to normal with the electric thumb switches

2. throw the stab trim cutoff switches

[WalterBright]

I know, sounds too simple to be true. But it is:

Boeing Emergency Airworthiness Directive

"Initially, higher control forces may be needed to overcome any stabilizer nose down trim already applied. Electric stabilizer trim can be used to neutralize control column pitch forces before moving the STAB TRIM CUTOUT switches to CUTOUT. Manual stabilizer trim can be used before and after the STAB TRIM CUTOUT switches are moved to CUTOUT."

https://theaircurrent.com/wp-content/uploads/2018/11/B737-MA...

This AD was sent to all MAX flight crews. It works because the first incident of MCAS failure (Lion Air) was safely dealt with by doing just this.

[inferiorhuman]

I know, sounds too simple to be true. But it is

No, it's not.

So here's some context. Boeing installed known not-to-spec structural components on the NG. Boeing installed known to fail prematurely slat tracks on the NG and 737 MAX. Boeing installed (probably known) not-to-spec pickle forks in the NG and 737 MAX. Boeing falsified repair documentation for an Air Canada 787. Oh, and of course, Boeing hid any mention of MCAS. Point being Boeing doesn't have a lot of credibility left.

With that in mind:

Manual stabilizer trim can be used before and after the STAB TRIM CUTOUT switches are moved to CUTOUT.

As the Ethiopian crew found out: it can't. The larger instruments of the NG required the hand cranks to shrink while the stabilizer itself grew. With the resulting lower mechanical advantage and increase in force required to move the stab itself the wheels became unusable. Sure, the Ethiopian crew went over the "maximum" speed but they were still under the max diving speed (Vd). That means the cranks were supposed to work.

It works because the first incident of MCAS failure (Lion Air) was safely dealt with by doing just this.

It worked because the first crew got lucky and had a third set of eyes that was free to dig through everything in search of a best guess.

[WalterBright]

> As the Ethiopian crew found out: it can't.

Whatever you read about that is simply wrong. (I've seen a LOT of misinformation in popular print about this.) You're correct that the hand cranks were unusable. But the electric thumb switches WERE usable and were pointed out in the AD.

Note that the crews of BOTH the LA and EA crashes had already used the thumb switches to restore normal trim, the LA crew did so 25 times.

> best guess

No guessing required. Follow the training, which is supposed to be a "memory item", meaning they weren't supposed to need to consult a checklist nor dig through anything nor guess.

I am not a pilot, but I would not consider myself fit to fly unless I knew by memory what every single switch in the cockpit does, ESPECIALLY the ones prominently located within easy reach. You can bet it's not the infotainment system.

For damn sure I would read every Emergency Airworthiness Directive for the airplane I'm the pilot of, most especially one issued in response to a crash.

[inferiorhuman]

Whatever you read about that is simply wrong. (I've seen a LOT of misinformation in popular print about this.) You're correct that the hand cranks were unusable. But the electric thumb switches WERE usable and were pointed out in the AD.

And if you enable the electric trim switches on a 737 MAX you get MCAS activation. MCAS, of course, trims faster than the switches. Using the electric switches is fighting a losing battle (look at the graphs of trim input vs output). How are you supposed to fly the plane when you can't trim the stabilizer?

Look at the graphs from the Indonesian report. The pilots were countering with trim up button presses and MCAS still managed to take the trim to a severe AND position.

Look at the graphs from the Ethiopian report. You'll see a long gap where the electric trim was disabled (leaving the pilots with no way to trim the stabilizer). Outside that gap you'll see an automatic (MCAS) AND command with no change in trim and a couple ANU clicks from the pilots with no resulting change in trim.

No guessing required. Follow the training, which is supposed to be a "memory item", meaning they weren't supposed to need to consult a checklist nor dig through anything nor guess.

And what memory items were they supposed to have in mind? Keeping in mind MCAS presented counter to how Boeing defines runaway trim.

[WalterBright]

> And if you enable the electric trim switches on a 737 MAX you get MCAS activation.

The electric trim switches override MCAS. That is why the steps are:

1. use the electric trim switches to set the trim to normal

2. cut off the electric trim

That's all there is to it.

> MCAS presented counter to how Boeing defines runaway trim.

That's simply false. (And runaway trim does not need definition, Boeing does not define it.)

[bumby]

The problem with this standpoint is that procedural fixes are the least preferable way of managing a hazardous condition. Engineering the hazard away is almost always the better option with procedural mitigation’s being a last resort. If engineering fixes were available and unused its indicative of poor safety engineering practices

[WalterBright]

> The problem with this standpoint is that procedural fixes are the least preferable way of managing a hazardous condition.

The way to make things safe is to address ALL points in the zipper that led to the accident. That includes the pilot error aspects.

[inferiorhuman]

The way to make things safe is to address ALL points in the zipper that led to the accident. That includes the pilot error aspects.

So how do you propose training against an unfinished product? Boeing still hasn't given the FAA a completed software package to evaluate. At the time of the 737 MAX crashes there were, what? two? 737 MAX simulators, and none of them emulated MCAS or even the forces required to crank the stabilizer manually.

One Lion Air flight got lucky because they had a third set of eyes that could spend time going through reams of documentation.

To even begin discussing pilot "error" is disingenuous when the pilots weren't informed or trained on new 737 MAX behavior. MCAS activation is not, and was not, a runaway stabilizer situation.

[WalterBright]

> MCAS activation is not, and was not, a runaway stabilizer situation.

It presented as a runaway stab trim. Repeatedly coming on and driving the nose down is runaway trim. No two ways about it. And the usual, standard, runaway trim procedure would stop it.

> they had a third set of eyes that could spend time going through reams of documentation

From my reading of that incident, nothing of the sort happened. The 3rd pilot simply reached forward and flipped off the cutoff switches. The crew landed safely and went on with their day. Nobody bothered to inform the next crew flying that same airplane.

[bumby]

I don’t disagree but there are clear hierarchical criteria on how these hazards should be addressed. The reason behind engineering mitigation being favored is because they make the less reliable procedural mitigations moot (I.e., they improve the overall reliability by removing one of the points of failure, in this case the pilot). Forgoing engineering mitigations in favor of procedural fixes goes against good engineering practice at best and is a cheap, lazy fix at worst.

I can understand if the AD was intended as a short term fix but I would question the rationale if it were considered a long term solution

[WalterBright]

> I can understand if the AD was intended as a short term fix but I would question the rationale if it were considered a long term solution

It was not, Boeing at the time was working on a solution.

Regardless, however, the pilots MUST know how to deal with runaway trim. This was true before MCAS, and is true after. It was true on the 757 (I spend 3 years working on the design of the 757 stab trim system). The cutoff switches are prominently within easy reach on the center console for very good reason, 40 years before MCAS.

It is not acceptable that pilots were unaware of the cutoff switches. It is unacceptable that MAX pilots did not read, understand, and remember the Airworthiness Directive sent to all MAX crews.

Similarly, airplane engineers work hard to keep the airplane from catching fire. But pilots also MUST learn to properly use the airplane's fire suppression systems. Most of pilot training consists of learning emergency procedures.

It's why airplanes still have pilots, instead of using automation instead.

Boeing still deserves blame for the flawed MCAS implementation. But there were other contributing factors in the crashes that must be dealt with.