"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.
http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
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.
[EDIT remove "roughly speaking an order of magnitude"]
No. No it is not. 787 approach speed is 145-153 knots. It does not cruise at 1400+ knots.
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?
I'd call that half a order of magnitude, considering log₁₀(3) is around 0.477. So you're off by more than 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.
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.
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.
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.
That counts as a pretty serious thing to avoid :-).
Ideally, yes. I submitted a recent incident where the RAT deployed on a 777 because it's so unusual (and was also not due to lack of fuel):
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.
(Somewhat frighteningly, two of those people are doing that at Facebook right now...)
These groups are not mutually exclusive, membership can only be assigned by a domain expert and is finally irrelevant if the other is right.
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.
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."
Things are complicated and rarely as simple as they seem.
On the other hand, I've worked on things for hours before for someone to glance at the problem and solve it. Always a humbling experience.
It is less appreciated when people phrase things in a condescending manner, though.
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."
If you use anything other than non-SPA, Go, PostgreSQL then it's over engineered and doomed to fail.
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.