Are you still advocating designing a whole new airframe instead?
> we still have to acknowledge it's not the best solution
We don't have to agree on that at all. It's an inherently simple solution, although Boeing made mistakes in its implementation.
> Just because a mitigation works some of the time
It's turning off a switch. The purpose of that switch is supposed to be a "memory item", meaning the crew should not need to consult a checklist. The switch is for dealing with runaway stab trim. Reading the step-by-step of the crisis, it is impossible for me to believe that the pilots did not know they had a runaway trim problem. There are two wheels on the side of the console, painted black and white, that spin when the trim runs, making a loud clack-clack sound. They are physically connected to the stab trim jackscrew with a cable. If the trim motor fails, the crew can manually turn the jackscrew via those wheels.
> You are advocating against well-established best practices in safety and reliability
Turning off a system that is adversely working is well-established in aviation. It's quite effective.
> and argue the points rather than appealing to (relatively weak) authority
Appeal to authority is not a fallacy when one has some authority :-) And so it is fair to list what makes one an authority.
> This isn't a pissing contest
You might want to review the condescending and quite rude post you wrote that I replied to. Your reply here is also rather rude. I don't think I've been rude to you.
Thank you for listing your credentials.
That would be the ideal solution for that hazard. But I can’t say if it’s the best risk profile overall. I would settle for a properly implemented engineered mitigation of MCAS.
>* It’s an inherently simple solution*
The fact that the engineers who built the thing mischaracterized it would seemingly be evidence to the contrary. I have experienced this flawed thinking often, where software is treated as a quick simple solution without considering the effects on the overall system.
>Appeal to authority is not a fallacy when one has some authority
It actually is. As Carl Sagan said, “mistrust arguments from authority.” But regardless, we seem to have different ideas on what makes someone an “authority”. You may be an aerospace authority when you’re in a room of CRUD software developers, but this forum has a much wider net than that. “Technical authority” is an actual assigned title at NASA, and you probably wouldn’t get it with 3 years of experience from decades prior.
“Turning off a switch” is the easy solution when you’re dealing with the benefit of hindsight. The pilots were operating in a completely different different environment. That’s why administrative mitigations are not a favored approach. Boeing simulator results demonstrate that it was a confusing scenario to identify the correct root cause in a time-critical situation.
As to the tone of the post, I’ve witnessed you in many aero circumstances state your credentials as a “I know what what I’m talking about so that’s the end of it” puffery tone. It in itself comes across as condescending and, worse, adds little to the conversation. I generally try to be respectful on these forums until someone shows they aren’t reciprocating. Normally I just roll my eyes and move on. I’ll give you the benefit of the doubt and assume you don’t even realize the condescending tone some of your posts take. I debated even responding but thought it might make you realize how off-putting you’re style can be. In your case, it comes across as very arrogant rather than curious which is contrary to the HN guidelines. If it offended you, I apologize.
I'm not offended, as that's to be expected when I write things that are unpopular.
But I still accept your apology, and no worries. Perhaps we can engage again in the future!
P.S. I know about the simulator issues, but the information came filtered through a journalist and I am skeptical. What I cannot reconcile is the first incident where the deadhead pilot simply turned off the switch, compared with the simulator pilot. It didn't matter whether the runaway trim was the root cause. It did matter that runaway trim will kill you and it must be stopped. All three crews knew that, which is why they fought it.
In my work on the stab trim system, it was accepted that the first resort for trim failure was turning the thing off. Overhead in the 757 is a matrix of circuit breakers, the purpose of each is to turn off a malfunctioning system. The stab trim one, being critical, isn't located overhead but right there on the console.
I work with machinery all the time. When it fails, my first reflex is to always turn it off. For example, one day I smelled smoke. Looking around, smoke was coming out of my computer box. I could see fire through the grille. The very first thing I did was yank the plug out of the wall, the second was to take the box outside. The flames went out when the current was removed.
I simply do not understand failing to turn off a runaway trim system. Especially when it kept coming back on after normal trim was restored.
For another example, an engine fire. I don't know what the fire checklist says, but I bet right at the top it says to activate the fire extinguishers and cut off the fuel and electric power to the engine. I've done the same for an engine fire in my car :-)
1. an absolutely enormous cost, like a couple orders of magnitude more
2. several years of delay
3. pilots would have to be completely retrained
Yes, this is the same case I was making. They took a higher (or unknown) risk for business (profit) motives. That's why they deserve a large chunk (but certainly not all) of the blame.
There was nothing at all inherently wrong with the concept of the MCAS system
My claim isn't that the concept was inherently wrong, it's that the execution was wrong. Their own process documents say so and they also belie the fact that they didn't understand their airframe. The damning part of it is that they were likely wrong for the reason of increasing profit. (Still, even if MCAS isn't inherently bad, we still have to acknowledge it's not the best solution...see the discussion above about hierarchies of controls).
>You claim "it's not hard"...Yet it's true.
This is exactly the wrong way to think about this. Just because a mitigation works some of the time doesn't mean it's the best mitigation. Can I still design a car with a coal-fired steam engine and cat-gut brake lines and drive it safely? Sure. But by modern standards, it's still a sub-par design and the likelihood of safe operation is lower because of it. That likelihood is the entire reason there is a hierarchy of controls. You are advocating against well-established best practices in safety and reliability.
>You can also google my experience. I have a degree in mechanical engineering with a minor in aeronautics from Caltech. I worked for Boeing for 3 years
Please don't do this next time and argue the points rather than appealing to (relatively weak) authority. I'm familiar with your points and can usually set a clock by the time it takes you to either bring up your experience at Boeing or some story about your daddy in these discussions. But you aren't the only one with aerospace experience. I've been an airframe mechanic. I also have an ME and additional engineering degrees to include a PhD and published aerospace-related research. I've worked in NASA for many more years than you worked for Boeing. I filled roles in aerospace, quality/safety, reliability, and software engineering related to both software and hardware design. I've worked alongside Boeing on crew-rated space systems. I've also piloted aircraft (although my ratings are no longer current). I've had dinners and discussed similar issues with pilots and astronauts with thousands and thousands of hours of flight time. But parading out your credentials doesn't make your points any stronger and tends to be the bastion of those without much else to rely upon. This isn't a pissing contest, so please make an argument based on its own merits rather than relying on credentials.