Do you have experience with aircraft engine design, or landing protocols, or insight in to the meetings when the engines were designed?
If so, I'll take back my words but considering the manufacturer doesn't know exactly why this happened, and the engineers on the ground said it seems like a "software bug", it seems a bit presumptuous and frankly a bit comical to start saying things like:
"Surely a better solution would be to just"...
Ah well, glad a 5 sentence comment on the internet can resolve an issue in a hardware, software, and social engineering challenge decades in the making.
"For every complex problem there is an answer that is clear, simple, and wrong." -- H.L. Mencken
One of the things I have experienced in my career is the mind boggling complexity of the software in systems that are capable of killing people. The more people it can kill the more complex the software.
As a result when I read articles like the one posted I find it tantalizing to speculate about the requirements behind the story. Taking the story at face value that Boeing has thought a lot about it and that is how the software has to be, what prevents the other solution of disabling the reverser? My guess is that you want the reverser to work in the event of software failure so it has to always work, but if the pilots pull it while you are flying that would probably rip the engines off the plane. Perhaps the compromise is to take the reverser off during flight and relight the engines using aerial pressure to spin up the engines. (which has me wondering if airlines still have a turbine they can drop down to start an APU which can then be used to start the engines). Which leads me to wondering if the pilots turn off the reverser right away do they have enough residual engine power to relight? Versus when they got to the end of the runway and had nothing? Clearly the 777 doesn't have an APU running when it lands since they would have used that to do an engine start at the end of the runway or if it does, it isn't running.
It is one of those things that my like minded systems friends could sit around lunch and make a good hour and a half discussion out of.
If the reverser could rip the engine off the wing, it wouldn't be safe to engage on the ground. Just thought that was worth pointing out.
A reverser only redirects thrust, and only generates about 60% of max thrust pushing backwards.
It's only on for a limited time on the ground because under a certain speed, you run the risk of blowing FOD into the intake path, putting the engine at risk.
I'm not aware of any reason to outright lockout a reverser in flight other than to hedge your bets against a very, very poor set of configuration choices by the pilot (reversing near stall speed too low to recover). I could foresee scenarios where being able to use reversers in the air could save the aircraft with the right combination of subsystem casualties.
Not a pilot or engineer, but absolutely LOVE aviation.
The cruising airspeed of an airplane is faster than its landing speed. I don't know if that alone is enough to rip the engine off the wing, but it's something that it sounds like you did not consider in making your point.
[EDIT remove "roughly speaking an order of magnitude"]
Thanks for bringing more precision to the conversation (really).
What would you like to call the factor? 3? Call me a weasel, but I was hoping "roughly speaking an order of magnitude" would go down to 3. I suspected it was comfortably above 2. Am I right about that?
It's surprisingly non-trivial to pin down exactly what the 'correct' scale[0] for a given measurement is. I do agree about "roughly" generally being up to a factor of two in the appropriate scale[1], although I'm the sort who thinks a 19% increase (or 16% decrease) should be called a quarter of a factor of two.
0: Uniform, linear and logarithmic are obvious candidates, but depending on the domain you can end up with some really wierd scales (eg floating-point ULPs, which can look logarithmic or linear, but aren't either).
1: hence > So you're off by more than a factor of two.
re go down to 3:
Use different words and see if you think it was reasonable
roughly 10x going down to 3x would also mean it would go up to 17x. That's a pretty wide range, so I don't think that order of magnitude is going to ever really be similar to 3x of something on the basis of what it means.
Your wording makes it where you aren’t factually wrong, but a plane was in fact wripped apart due to the thrust reverser engaging on one engine of a 767:
The difference isn't that large in the grand scheme of things. The engine mount would have to be able to fail in it's operational envelope in order for the reverser kicking in to be realistic.
In fact, the reversed kicking in would decrease the loading on the aircraft by decreasing it's airspeed.
This isn't a case of acceleration being able to break the mount from the frame. If it ever could, one wouldn't want it on the plane in the first place.
Doesn't mean you couldn't ruin your day with it, but it isn't an instant catastrophic failure either.
> but it isn't an instant catastrophic failure either.
Read the accident report and follow up on Lauda Air Flight 004. Boeing specifically was forced to issue a statement that it was virtually impossible to overcome a catastrophic failure outcome from a thrust reverser deploying at cruising speed.
Apropos, the Wikipedia article (https://en.wikipedia.org/wiki/Thrust_reversal) mentions number of events where an engine reverser was deployed in flight, one involving a 767 which resulted in the loss of the aircraft.
That counts as a pretty serious thing to avoid :-).
Why "still"? Even if the chances of a failure of both engines is almost zero, it has happened that there are losses of fuel. The ram-air turbine allows the pilots to have some instrumentation. That's super useful, for example in this accident: https://en.wikipedia.org/wiki/Air_Transat_Flight_236
Is that from other experts with a very close understanding of the specifics, or random people online?
What I find is you start with several viable approaches, pick one and go down the path enough to figure out the downsides. At which point you need to decide to backtrack or keep going. That’s the hard part not simply coming up with a seemingly simple solution.
Not "random people online", but I've got a few friends I think of as "terrifyingly smart", and one of their common characteristics is how they've all, in areas of expertise I've been investigating/researching/working in for weeks or months and which they have barely a passing interest in, quite obviously thought about a problem I'm describing and thought through a bunch of the obvious options, categorised them, and made conclusions about which avenues are workable and which should be discarded, and come up with either a workable solution or options I'd not even considered yet - all just in the course of a conversation over coffee...
(Somewhat frighteningly, two of those people are doing that at Facebook right now...)
Constraints define good decisions. A new team member making a viable suggestion is very different from a random person tossing out a wild ass guess that happens to be right. The difference is the random commentator has no real way to judge how viable something is, and thus is simply tossing out ideas.
This can be right when things change over time and people still operate under their initial assumptions. Times change constrains change but on some teams assumptions and choices are not revisited.
My experience is about 50/50, both with my own mistakes and with others.
Generally when one is very close to the problem, one sees the environment as immutable. Because, well you spent very many hours building that environment, for very good reasons. And your complex solution "has to" work within the constraints of that complex environment.
Whereas, the "mind of a child" that doesn't grok the environment, also doesn't have a fixed notion of it. This is anecdotal of course, but maybe half the time what I see happen is that it's easier/better to change the environment and this can only be seen with fresh eyes.
It's not the spoon that bends, and it's not you that bends around the spoon. There is no spoon.
Had someone do that this morning. They ran across a problem that has been the focus of a multi-year effort involving dozens of people. Fixing the problem is a big part of the literal #1 priority for the company.
Anyway, he hit an example of the issue, and wanted to just put in a bug ticket to one team, and didn't understand why that was not useful or necessary.
My analogy is that it's like showing up at NASA in 1965, and wanting to submit a ticket that says "Your rockets can't actually go to the moon. Fix rocket so that it can go to the moon."
The best part is when your project is running late or having issues, and the non-technical manager plans a meeting with all the other dead-weight people. "Explain the problem to us, and since we know absolutely nothing about it, our stupid questions might give you new insights". Facepalm.
I for one love this type of question, and was the one asking it as I started out. 10-20% of the time, the asker has a valid suggestion. The rest of the time, the explanation as for why it will not work or is not a good idea fosters a better understanding for the asker, and reinforcement brush up for the answerer.
Yeah, it shows someone is trying to understand the problem. I mean, sure, most often the response is, "because that would require data that does not yet exist when the decision must be made," or, "there are legitimate circumstances where that would be the exact wrong response," but it does get you thinking.
It is less appreciated when people phrase things in a condescending manner, though.
They are right more often than you’d expect. Irrational escalation, loss aversion, confirmation bias, etc play their part everywhere causing senseless projects to be pushed to completion.
When the "they" is at least another expert in the same field and not a total stranger completely ignorant of pretty much every relevant detail, and the "you'd expect" part starts at a baseline of nearly 0% for people walking in out of the street unfamiliar with the specific problem at hand, then yes, "they" are right more often than I'd "expect."
Tech is the worst. Fetishizing disruption leads to neophytes thinking they're breaking new ground when they're just re-discovering long dismissed ideas.
My answer to the question is no, but I am a pilot, and my expectation is an invalid input is recorded but is a no op. It is fly by wire so why not just no op the request? The idea such input suggest sabotage, is more paranoid than cautious. And shutting down the engines is hardly fail safe. It's just less fail danger than engaging the thrust reversers.
Quite a few turboprops have beta range that is supported for use in-flight. The purpose is to increase the rate of decent, similar to slipping the plane. So it's not always an invalid input; it's make/model/phase of flight specific.
If so, I'll take back my words but considering the manufacturer doesn't know exactly why this happened, and the engineers on the ground said it seems like a "software bug", it seems a bit presumptuous and frankly a bit comical to start saying things like:
"Surely a better solution would be to just"...
Ah well, glad a 5 sentence comment on the internet can resolve an issue in a hardware, software, and social engineering challenge decades in the making.