I think the auto shutdown of engines in flight, in case it senses reverse thrust, is a great design.
The 787 is a replacement for my 767 (currently a pilot on the aircraft) and in 1991 a Lauda Air 767 suffered a failure in one of its thrust reverser and it became activated during cruise. The aircraft was destroyed in flight.
The thrust reversers should not activate during flight (a air/ground sensors prevents that) but as it is a catastrophic failure, having the engine shut down automatically seems like a great fail safe device.
In this case it seems that the 787 engines were reversed before the air/ground sensor had sensed ground and it is a potential problem.
As long at it is well documented and part of the training, and also ideally the system should indicate to the pilot why it is shutting down the engine(s), to avoid something like this:
"The safety system automatically cut the power to the engine suffering the thrust reverser malfunction. There was no alarm in the cockpit to indicate that a thrust reverser had been accidentally deployed. The crew had no way of knowing what the true problem was. The copilot, seeing the right engine power lever automatically move to the closed position, thought that the lever had slipped back and pushed it back to the full power position alongside the left engine throttle lever. Once again, the automatic safety system closed the right engine throttle and the captain, who was conducting the takeoff, called for the autothrottle system to be switched off. After switching off the system, the copilot again pushed the right engine power lever fully forward and forcefully held it there."
there's a really interesting story around Lauda Air flight 004 where Boeing attempted to write it off as pilot error but Niki Lauda basically threatened to go fly one himself and recreate the conditions as proof it was not. Eventually Boeing conceded and he didn't have to actually risk himself or another of his planes, but still an interesting anecdote.
He was severely burned in a Formula 1 race at the Nurburgring, and despite still suffering badly scarred lungs and weeping wounds he was back in the seat before the end of the season and only lost the championship that year because he refused to go out in the pouring rain to race the Japanese Grand Prix as he decided it would have been foolhardy.
TCMA, the system the article refers to, doesn't actually shut down the engines in flight. In fact, one of the explicit conditions for its activation is the aircraft being on the ground:
> The EEC commands shutdown of the affected engine when the:
> • airplane is on the ground, and
> • thrust lever is at idle, and
> • engine is above idle speed and not decelerating normally
> The EICAS caution message ENG FAIL (L or R) is displayed with an aural beeper once the engine falls below idle speed.
Fyi, military pilot here, there are a handful of mil aircraft that can reverse thrust in flight. A great too for dropping down fast to avoid low/slow flight over hostile areas. There might be a relationship between that ability and this problem.
> In this case it seems that the 787 engines were reversed before the air/ground sensor had sensed ground and it is a potential problem.
What I don't understand is why does the reverse thrust input from the cockpit even influence the engine control when the air/ground sensor doesn't sense ground? It seems like an obvious lockout mechanism to have in place, if the result is shutting down the engines when the combination occurs.
Then just have a manual air/ground sensor override should that thing fail and you know you're on the ground and require reverse thrust.
I am very scared of flying (although I still do it, although it's not fun). Any advice/rationalism you can convey? I am a person that became sweaty and anxious reading your post.
My advice is to look at the statistics. Commercial flying is much, much safer than any other mode of transport.
Do you get scared when you drive to work? Or take a train? Both are more risky. (Driving significantly so.)
More specifically... The pilots have extensive training, modern airliners have fail safes everywhere, and the amount of research and engineering spent on aviation safety is mind boggling.
An accident during flight is pretty much a binary event when it comes down to whether you live or not, but with cars there is a whole slew of different types of accidents and vast majority of them don't cause instant death preceded by 45 seconds of absolute terror. Before you downvote what I said in no way discounts the statistics. It is much safer to fly of course than to drive, but when we think of accidents which is an inevitable fact of any mode of travel one mode is binary you live or die and another not. To our mammalian brains the statistics is a very hard sell.
Aircraft accidents aren't binary at all. Many crashes have few or some casualties, e.g. landing gear failure, running off the runway or hitting another aircraft on the ground. Ditto with in-flight failures that don't impact the flight (there's only one major thing that fails, picked up by the redundancies), engine failures that lead to emergency landings, extreme unexpected turbulence or ditchings etc. that might cause injuries and in some cases deaths. It's only the worst crashes (termed "air disasters" or similar) that lead to everybody on board dying. Of course, these get the most attention. I blame the news.
How can you argue against what I said, it takes profound willingness to ignore precise words to accomplish that. I did not say all accidents I said majority are. If you consider a mosquito hitting the windshield of an airplane when it's parked on the ground and no passenger in it an accident that's your problem. Of course I meant an accident that happens during flight as that's the vast majority of the time that people are in an airplane and when they're worrying about dying.
I don't think that's a super fair assessment of my comment. If we're just disagreeing on the definition of an in-flight accident, or what percentage between 30% and 90% of accidents constitute a vast majority, we should probably leave it at that, because that's not really disagreement :)
My point is, there's plenty of accidents caused by things that happened while the plane was in the air, that has many survivors or just some injuries. The news article at [0] has some examples, and it's possible to search for more. Granted, if you exclude the cases where the injuries or casualties were caused during an attempted landing or a forced landing due to malfunction, the picture would probably look much more bleak, but then you would also have ruled out a large portion of the accidents that happened.
It's thankfully _extremely_ rare that it's been impossible to make an honest attempt at a controlled landing or ditching during an accident, and in a large part of the cases where this was possible, things turned out okay for most passengers.
I agree with what you say, but I think it has more to do with (perceptions of) control than the failure modes.
When you’re in an automobile, you could choose to drive faster or slower, safer or more aggressively. You can tell yourself that you are more alert or a better driver to the people who die in fatal car accidents. You can tell yourself that you have a superior ability to avoid that drunk driver who might suddenly veer into your lane from oncoming traffic. And once your car comes to a stop, if you’re not seriously injured, you can just get up and walk away.
In an airplane there’s none of that. You can make vanishingly few choices to affect the safety of your flight. And you’re stuck in that tin can until it’s on the ground and you’re either alive or dead.
I was very scared of flying for a long time. I fixed it by booking a flight a week for 12 weeks, starting the first week heavily medicated, and following the advice of a book on agoraphobia (Freedom from Anxious Energy). Then cut down the drugs progressively each week until it was none. Worked a charm
Airliners are incredibly durable machines. This article about about how much stress the wings can take is what I think about anytime I see the wings bouncing in turbulence.
It is perfectly rational to be scared of flying. Hell, you're sitting in a pressurized cylinder at 30'000 ft flying at 700 mph. But you have to realize that the crew would not do this job if they weren't sure to come home to their families and dogs every night. Most pilots I know aren't thrill seekers but their love of flying are more a drive due to interest in travel and technology.
I advise you to forget statistics. They are very hard to relate to (we're not good visualizing large numbers anyway). Instead, think of the pilots who know these things inside and out and still choose to happily board each and every day. They raise families and eventually retire uneventfully. If they know the risks and still choose to go to work, surely you can board a flight.
I feel for you. I was the same way. I just internalized the stats and remind myself of them every time I fly. As a numbers guy, I simply cannot justify my abject fear compared to being a pedestrian or auto driver.
Another thing I do is to remember the physics when I'm on a bumpy. Thanks to momentum, planes don't just fall out of the sky, and even bad turbulence is not likely to result in deaths.
I have been there. If you think this anxiety has been on the rise (think carefully about if some time ago you had such strong emotions reading about accidents, etc), consider going to a doctor and treat your anxiety. Medication solves it, I can assure you. Rationalizing does not go very far.
I was not scared of flying until one day while taking off from O’Hare lightning stroke to the tip of the left wing of my plane. I was sitting just on that row aisle side though. For a split second it felt like we stoped mid air. Kind of like when you drive over a bump with your car. After that for quite a while I was scared shitless of flying. But that didnt stop me I probably flew a hundred times since then and now when I do I dont even think about whether I am on a plane or train ( well my be for a bit). Airplanes are incredibly robust machines so my advice is just stop thinking about it and keep flying.
Summarized, I understand that you mean that a malfunction in the "reverse-thrust-detector" (which switches off automatically the involved engine(s) when the reverse-thrust is not operating within its envelope => referenced as "feature" below) is more desirable than not to have it?
(because if, when having a mulfunction of the detector's "feature" in mid-air the engines switch off you still have some time to fix/override it, but on the other hand when not having it if your reverse-thrust engages you're screwed immediately - and even if the feature fails nearby the ground you're still be slow & low enough for at least some passengers to have some chance to survive)
> it's a great fail safe but not if you lose your engines in flight and can't relight them like in the article.
It is still better to lose all engines than to have thruster reversers deploy in unsafe situations. You may stall without an engine at low altitude in a landing configuration, but you should still be able to glide for some time. Deploy reversers (or even a single reverser) and you fall like a brick very quickly.
This existing system wouldn't likely cause loss of all engines unless the PIC commanded all engines TR in-flight. Also, it doesn't make sense that such a system would go out untested because such a system should try command engines to idle before cutting fuel to what it thinks are runaway engines. Finally, it's still unknown if it's a Boeing software issue or a RR T1K issue... the OP article is purely speculative and guesswork "news" is not how aircraft safety is handled.
A single engine on reverse is enough to mess up the the flight violently enough that it'll break apart before hitting the ground (see the Lauda Air case).
I think there are a few options for a failsafe here.
none where it would deploy the reverse thrusters and probably crash regardless of other inputs to the system(could be one or more of many inputs wheel speed, slats deployed, airspeed, elevation, throttle position, etc.)
turning off the engine (presumably you want this because you are on the ground but your ground sensor is failing so you want to cut engine and apply brakes which is less preferable than the reverse thrusters but manageable normally.)
ignoring the input altogether.
not a failsafe at all and an unexpected failure mode of the system (I think this is probably the case since they couldn't relight the engine on the ground)
the point i was making is that if you have the failsafe turn off the engines under normal operating procedures it should be able to relight when in flight and it's not good if a software glitch turns your heavy into a glider without possibility to relight. (i am not a pilot but it's my understanding that you still have the turbines spinning and all you need to do is give it some fuel and fire up both ignition plugs. might need to use the compressor to spin them up to full speed but i doubt it.)
Have a mechanical latches on reverse cowls that will be operated separately of the code that deploys reverse. Landing without reverse is better than falling like a brick.
Having altitude and being able to glide in is a hell of a lot better than one of your engines reversing and throwing your plane into an irrecoverable spin.
Cutting power to all engines in response to an event that is most likely to happen while the aircraft is operating close to, but not actually on, the ground is not failing safe.
I am not sure there is a perfect solution here. you have competing issues that you need to resolve.
If it gets pulled in normal flight you would lose both engines but that's fine because you can glide and restart the engines. if the altitude sensor/ground sensor was broken and you want to override the reverse thrusters you have a conflicting goal there.
If you accidentally pull it during the approach you lose your engines and probably don't have time to relight before landing. in that case you might be able to still land by backup systems(FAU or just the ancillary tail turbine?) and glide?
I guess it boils down to how much trust you place in the pilots to not do the wrong thing or how much trust you place in the machine to not do the wrong thing/malfunction. It's a difficult question without a perfect solution imo.
Well, I thought that the design was that they would not engage if it gets pulled in normal flight.
If it's on the approach, I'd be worried. I imagine that that, at an airport like ORD, that might result in more risk than anyone really wants of the plane unexpectedly touching down on an interstate highway or something like that.
If it's like what Boeing described in the bulletin, where the engines only get shut down after the wheels are on the ground, that's maybe not super worrisome, but I can still see some room for concern. My reconsidered but still totally uninformed reading on the situation is that it takes some time for all the aircraft's systems to get the memo on whether the plane is on the ground, and that what's really going on here is that the order in which they get the memo isn't quite right. So the question of whether or not to allow a Lauda Air type situation isn't really at play here, but perhaps a related glitch to the one that caused this event could interfere with something like aborting a landing at the last minute.
Interestingly, some airplane types allow the use of thrust-reversal in flight, notably some fighter jets. It's apparently used when you do need to sink quickly..
Hmm. There might need for a sooner transition point for that particular inhibition. Perhaps somewhere between ground effect (well below minimums) and back trucks are turning.
This is really strange. Not only did they have a dual engine failure, they couldn't restart while stuck on the runway. After 40 minutes, the aircraft had to be towed in. Then maintenance couldn't find a fault.
This is an ANA aircraft, which means it's probably maintained well and flown by competent pilots. Looking forward to a good analysis on this.
Most large aircraft have a "weight on wheels" switch, activated when the aircraft is on the ground. There might be some bad interaction between the "weight on wheels" sensing and the thrust reverser protection. Pure speculation: initial touchdown, pilots deploy reversers, small bounce into the air, weight on wheels switches open, engine controller detects flight condition with thrust reversers deployed and shuts down engines.
The other side of this kind of failure is dealing with unintended thrust reverser deployment in flight. Here's an overview.[1] Historically, it wasn't a big deal at altitude, but on some newer aircraft, it is, and so stronger steps have been taken to avoid it.
Your speculative scenario has actually happened, but on a significantly less computerized Boeing 737, in 1978.[1]
In that case, the aircraft touched down, reversers were deployed, a runway obstacle (a snowplow) appeared, and the pilots attempted to go around. They got airborne and cleared the obstacle, but as they lifted off, the "squat switches" on the main gear opened. One of the reversers was still deployed, and with the squat switches open, was no longer powered, and could not retract. The aircraft was uncontrollable, and crashed.
In that case, shutting down the reversed engine would likely have been preferable, although if we're doing counter-factuals, telling the snowplow driver about the airplane's revised arrival time is your go-to move, I think.
It might be less of a small bounce than the nose wheel not being on the ground and/or not having enough weight on it. I know Airbus and Boeing handle this differently, but I don't remember the details (I want to say Airbus allows reverse thrust once the mains are firmly on the ground but the nose isn't, but I need to check my manuals).
I really do find the inability to restart extremely interesting though. I'd bet it's a bug somewhere, but it would be alarming if Boeing programmed in a lock-out on the failed engine(s) (I've heard it talked about as a solution to the sudden deployment of reverse thrust in flight) .
The Boeing 787 is now about nine years old. I wonder how much of this is operator proficiency triggering latent bugs (aka, "pilots got too good at pushing buttons quickly").
The bugs in the Therac 25 were only discovered after the machine had been in production for a while (you had to be typing "too quickly" in order to get the software to trigger the bug with the safety interlock).
It's not very typical for pilots to push buttons quickly. Especially not the thrustreversers and engine and flight controls.
But it is entirely possible that nobody pulled the reversers while still airborne in 9 years, because it's a very strange thing to do. A bit like opening your car door while still driving 60 mph... Nobody does that in normal operation.
In airplanes, a lot of procedures and diagnostics involve not re-trying a failed action, not touching anything before reading a check list, nor flipping a switch twice if it didn't work the first time.
Non-suicide doors[1] in cars are very difficult to open at 60 mph. Between air pressure, and poor leverage, you are going to have a hell of a time doing it.
I've seen a number of videos on youtube of reversers been opened, if not fully spooled up, off the ground. It's not common but it does happen, especially in high cross-wind or otherwise iffy landings.
> But it is entirely possible that nobody pulled the reversers while still airborne in 9 years, because it's a very strange thing to do.
That's overstating the case a bit. I'm 100% a layman here but I'd agree that the behavior seems like some sort of bug. But…… some planes (typically not commercial, although the Concord is one notable exception) call for reversers in flight under certain circumstances. Additionally there are definitely circumstances where a pilot might deliberately think reversers before touchdown are a good idea.
Probably not cost effective as opposed to either making the software more resilient or just letting some monkeys/interns loose in the cockpit and pressing everything (With some focused searches obviously)
I don't know, I suspect software resiliency is one of those "gets exponentially more expensive as you approach perfect" situations and a robot could bash inputs at speeds a human couldn't in thousands of orders, it would certainly let you test those weird code paths that blow up when they are never exercised until they are.
It does get exponentially more expensive, which is why you have to pick a certain level of ~perfection~ and then stop.
Also, the robots would have to bash at the speed of a human: The point is to mimick human inputs not necessarily test every code path (Which you could do in software)
When testing resiliency software testing isn't the whole of the thing.
I spent a lot of time at new job (well 18mths now) on making the software side more resilient, we still had a site wide outage of internet access and comms and internal systems because one of the women in the sales office unplugged a socket in the ingress comms cabinet to plug her hair straighteners in.
Coincidentally my request to have physical access control on all the comms cabinets shot right up the list.
The boundary layer between software and hardware itself has to be tested, the real world is a messy place :).
Considering the level of fly-by-wire that goes into airframes nowadays, I could certainly see such features added to older airframes through flight-software updates after they are already in service. I have no idea if that's how it's done in the field, though.
Software updates are done. However the manufacture has to recertify the airplane with the FAA first. This is expensive, requiring months of testing and a lot of paperwork. Each plane model getting the update needs to be re-certified, it isn't good enough to say that it works on this other model even if the planes are identical for purposes of that software.
The Ryanair booking website has several bugs exactly like what you describe. If you use it too quickly it won't sell you plane tickets. If you use it more slowly it works fine.
Boeing’s answer seems to say if you accidentally pull the thrust reverser lever before the aircraft is on the ground it just force shuts down the engines.
That sounds like an odd safety override. Surely a better solution would be to just not activate reverse thrust. Unlike car engines a jet engine can’t just be quickly restarted if it accidentally shuts down. It typically takes 30-60 seconds to get going.
This and earlier incidents are highlighting the dangers automation can add to mission critical systems. No pilot wants to hear notices about “hey, so in case you didn’t know our programmers added some code that does this strange uncommanded thing when you push buttons a certain way”
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.
So the bulletin says that activating the thrust reversers too soon can cause un-commanded high trust. Activating it too soon by itself does not cause a shutdown. But one monitor that could stop the engine would be the overspeed monitor. The un-commanded high thrust might have tripped the overspeed monitor on the turbines and shut both of them down. There are numerous other monitors on the engines that might also play a role. So determining root cause might still take a while still.
This is an issue carmakers have had to deal with, too, since the invention of the automatic transmission: what if you put it in reverse while driving on the highway?
There are a number of YouTube videos with people who have tried it. The answer, in a modern car: pretty much nothing. It just stays in Drive. On one car, it turned on the backup camera display!
Standard transmissions nowadays often include mechanical features as well that make it very difficult / impossible to engage reverse (and first gear) while going forwards at more than a few km/h.
Even a 1950s era transmission will still be very hard to force into a gear if the speed difference is too great. Likewise you'll have a very difficult time shifting into reverse or 1st at speed. That's just how syncros work. You might be able to overcome it by double clutching but it would require conscious effort. Even just shifting to reverse while rolling is difficult.
Still possible though. Years ago a friend and I pulled a manual transmission in a junk yard. He got it home, installed it, and then discovered reverse was completely stripped.
It's not an odd safety override. An overthrust situation is always dangerous for various reasons. One of the more spectacular is the possibility of liberating airfoils from the engine and shooting them into the cabin.
It's not a self-destruct button, it's anti-destruct limit.
As for the thrust reverser, there are many integrated systems on the aircraft. It's possible that the cockpit detected weight-on-wheels, but the flight mode hadn't yet transitioned for the engine controls.
Switching off is much safer than a turbine overspeed past certain limits. Because an engine failure (one engine) is a situation all pilots are trained for and it has an almost certain safe outcome. Airplanes fly and land just fine on a single engine. We all train for engine failures all the time.
On the other hand, a runaway engine fire or uncontained turbine failure is much much more likely to cause a crash.
So almost all jet engines are designed to have a shutdown (sometimes helped by the built-in fire extinguishers) as a worst case outcome. The quick response drill for an engine overspeed or temperature past certain limits is to shut it down immediately and pull the fire extinguisher handle.
Good question, you could theoretically throttle a runaway engine by reducing fuel flow (unlike a piston engine where you can limit air intake). But in 9 out of 10 cases you've already done that by pulling back the power levers. The next step is to cut off the fuel, because the throttles didn't get it under control.
Overspeed protection takes place once everything else has failed. The engine controls have already attempted to throttle down and such. If that doesn't work then overspeed kicks in.
That and restarting an engine in-flight is faster than starting it on the ground because it's already spinning (by virtue of sailing through the air, like a windmill). This is, aptly, called windmill starting.
You would be surprised at just how safe and 'normal' shutting off the engines on a plane is.
Related, British Airways Flight 268, a B-747, when taking off from LAX had a problem with one of it's engines so they shut it off, and continued flying all the way to London, albeit to Manchester instead of Heathrow, with one less engine. https://en.wikipedia.org/wiki/British_Airways_Flight_268
I was watching Air Crash Investigation yesterday, where a reverser deployed right after take off and caused the plane to crash. They said now reversers can't be activated unless all wheels are on the ground, as you've said.
I'm willing to bet that the plane does prevent the pilot from activating reverse thrust when not on the ground.
But what if a thrust reverser self-activated, without being commanded? The previous safety mechanism wouldn't help because it's being bypassed.
So there is a secondary safety system that detects such situations. Something along the lines of "I think the trust reversers shouldn't be activated right now, yet they appear to be activated. The engine is clearly malfunctioning, lets shut it down"
It appears that this secondary safety system has been activated. There was probably a bug, or a sensor malfunction that triggered it.
Thrust reversers can never be deployed while airborne. This engine shutdown system is only enable on the ground. It's designed to shutdown an engine if the engine thrust doesn't match the commanded thrust, so an engine malfunction on the ground cannot cause the plane to taxi out of control.
But it is still possible for the pilots to deploy reverse thrust too soon, after touchdown but before there there is enough weight on the wheels to provide sufficient steering. I'm guessing the pilots deployed too soon, and discovered a new corner case.
Definitely you can use thrust reversers before touchdown at least on B737.
I wonder how big is a difference between software on B737 and B787. Aviation industry doesn't have tendency to build software from scratch.
Here is example video: https://youtu.be/-RO66a_nvus
Hey, thanks for this video. I was on a flight that did that some years ago when I was doing a lot of traveling. I don't remember anymore where exactly in Europe it was, but no one I later talked to believed me that the pilot would engage thrust reverser before touchdown.
Maybe the 787 won't allow airborne use, but other aircraft allow it. It's useful for steep descent. If the feature were more common, obstructions near airports (like mountains) would be less of an issue. We could build new runways at some airports.
I think you've misunderstood. The system you're describing kicks in when (a) the aircraft is on the ground, (b) commanded thrust is idle and (c) the engines continue to produce thrust above idle (when there is an overthrust condition). Boeing does not cut power to the engines to prevent reverse thrust application in air - that would be absurd.
On this particular occasion the system is thought to have malfunctioned in some way (e.g. it might have not registered the application of reverse thrust) triggering a shutdown.
A tough call. Your solution would disappoint a pilot who actually wanted to slow down ASAP more than Boeing's solution, and might contribute to a runway overrun.
No, it would not. If the engine is shut down moments before touching down it would mean that there would be no reverse thrust after touching down since it takes a considerable amount of time to re-start a turbo-fan (not 60 seconds as OP wrote as the engine is still spooling but still a significant amount of time and I don't think that any pilot would go through the workload and checklists of re-starting an engine during the landing roll anyway). This leads to a longer braking distance.
The sane choice would be to not engage reverse thrust at all (until the pilot has reset the reverse thrust throttle) or to only engage reverse thrust once the landing gear has weight on it.
> or to only engage reverse thrust once the landing gear has weight on it.
Having reverse thrust depend on a sensor that could fail seems like a poor choice. What if the landing gear don't drop? Is there a situation where you would still want reverse thrust without landing gear?
Sometimes you'd like to have reverse thrust in-flight if you want to descend really, really quickly. Airliners don't have that feature anymore, but the C-17 and C-5 do.
Actually, maybe some ex-Soviet airliners can still do it. DC-8s being used by cargo airlines could possibly still technically do it, but don't use the ability.
Specifically, it wasn't a design goal of reverse thrust, and it's operation mid-flight was directly responsible for over 200 innocent lives lost[0]. Thrust reversers are very much a "nice to have" feature on turbofan aircraft, with every one qualified to both land and initiate a rejected takeoff at maximum weight without using them, though not without some maintenance after.
Most things in aircraft automation systems depend on sensors that could fail (those sensors could be redundant etc. but the same can be done with the sensors on landing gears). It is sane design.
> What if the landing gear don't drop?
I don't think that there is need for reverse thrust in such a scenario.
> Is there a situation where you would still want reverse thrust without landing gear?
Even if there is, there could be a manual override.
It depends on where the engines are mounted. There was a Tu-154 that landed gear-up in Greece, then took off again, dropped the landing gear, and landed normally.
There are plenty of examples of non-catastrophic belly landings. I'm no pilot or aircraft engineer, so I don't know for sure if you'd want reverse thrust in such a situation. https://en.wikipedia.org/wiki/Belly_landing
Only if the people in this thread are designing aircraft. Presumably the actual aircraft designers have more experience reasoning through these kinds of problems.
The Professional Pilots Rumor Network (PPRUNE) is a pretty awesome forum full of aviation professionals discussing aviation at a high level, I always go there for aviation news commentary. The thread on this isn't very extensive yet, but has some interesting commentary https://www.pprune.org/rumours-news/617426-ana-787-engines-s...
"Boeing said that selecting full reverse too quickly upon landing before the aircraft has fully transitioned to ground mode could cause the system to activate."
That sounds like apple's "you are holding it wrong" when "antenagate" happened. Not something I want to hear from an aircraft company where people's lives depend on it working.
Reading between the lines, and having read other comments here, I can interpret Boeing’s remark as “if the pilots or the on-board software try to reverse engines when it still is really, really dangerous, the Thrust Control Malfunction Accommodation system (TCMA) will try to make matters less bad, in some cases by shutting down the engines instead”.
They may have to fine-tune that system, but from a safety perspective, this event had a good ending, and making its decision system more complex also carries risks, so, maybe, nothing has to change.
I'm having a hard time thinking up an alternative choice of words that is similarly clear and concise.
I also think that the phrase "too X" is polysemous. Depending on how it's used, it may imply a notion of blame. But it can also just be a way of describing an incompatibility. "This clearance is too low for that truck" and "This truck is too tall for that clearance" are entirely equivalent statements, IMO. Neither implies that the truck or the bridge is wrong, just that the driver would be wrong to try and drive under it.
Even further out there, when describing a timing-based bug that isn't known to be 100% deterministic as, "If X is happens too quickly after Y, Z might happen" seems to me like it's just a much more straightforward way of saying, "If X happens within some unspecified interval after Y, then Z might happen." Nine syllables shorter, same meaning.
There's a further implication that an instruction, but not a failsafe, exists to prevent the given condition. E.g. "do not reverse thrust until ground mode has fully activated." but no check to actually prevent the crew from doing so.
I'm not a lawyer; couldn't tell you where the fault would split in that case, but if my hunch about the lack of a failsafe for a given instruction is correct... it's still a surprise to me. I'd expect existing avionics production procedures to catch this sort of thing.
>> I'd expect existing avionics production procedures to catch this sort of thing.
The older I get, the more I believe your expectation is wrong. Lessons learned are rarely transferred to new people who were not present when the lesson was initially learned.
I've even worked at companies that try to compile a database of "lessons learned", but they never instruct anyone to read through the whole thing. Even if they did, when confronted with a large amount of material how much of it actually sticks?
The we move on to more procedural methods like fault-tree analysis, FMEA, etc... That's great and can help a lot, but it's still a GIGO process and new people need to learn how to do it well. There are always new people learning new things.
In software, we usually encode lessons learned as tests and static analysis. There is a reasonable level of success on that.
Aviation usually encode them on checklists. They have a much higher degree of success (probably because of culture, not medium), but failures happen some times too.
Aircraft are very different from cell phones. There are a number of things you can do as a pilot that will cause them to crash or stall especially if something unusual like a sensor or engine failure occurs. Pilots spend a lot of time in simulators practicing how to fly the plane in a variety of such situations as well as under normal operating conditions.
Or as my neighbor says: "I've dealt with hundreds of engine fires!" (He flies A320s.)
Sort of off topic, but reverse thrust sort of boggles my mind. If you're sucking air in from the front of the aircraft and ejecting it out the front, don't those forces counterbalance each other?
To elaborate on seiferteric: If the engine were just an unducted fan, the input and output volumes and velocities would be the same, and if they're pointed in opposite directions, there would be zero net force.
In a jet engine though, you have a nozzle on the back, so the input area is greater than the output area. Heating the air also causes it to take up much more volume. These put together, mean that the output velocity is much greater than the input velocity, so there is a momentum transfer from the atmosphere to the plane.
"Sucking" doesn't actually generate any thrust - In highschool, my physics teacher did a demo with a T-shaped pipe with a fan in the middle, suspended from some string.
Without the T, the pipe moved as you'd expect. With the T directing the airflow in equal proportions perpendicular to the axis of the pipe, the pipe stayed still as if the fan wasn't on at all.
that's very interesting! but it's about angular momentum and I'm not confident that I can take the lesson over to linear momentum.
Here's my caveman f=ma thought experiment:
1. make it 2-d.
2. replace the fan with a person sitting on a chair on a frictionless surface.
3. instead of air it's an endless field cinder blocks ahead of him.
the person reaches out, and pulls in a cinder block. f=ma says they each move toward the other while the center of mass of the combination of them does not move.
Now, if he throws the cinderblock behind him, he moves further forward - this would be analogous to an airplane propeller. or a fan in an open pipe.
If he, um, splits the cinderblock in two and places each half directly off to his sides there is no net force exerted on him by this. This is the fan in a T-shaped pipe.
the fan+pipe grabs air from ahead, moves this mass backward and then sets it aside. it's not a jet-engine, but it is moving the air mass toward itself and must be moved equally and oppositely.
I don't think it's essential to worry about how the air/blocks rearrange themselves after this - but if the blocks surround and jostle, that's just another effect layered in super-position over this one, and if we don't agree so far then it will only make things more confusing
You have to look for the equal and opposite reaction. A normal jet creates a stream of fast air behind it. There's no such thing for a reverse jet that sucks air in.
With your concrete block example, as I start pulling the block towards me I experience an impulse forward. But when it approaches my body I slow it down to zero speed, creating an opposite impulse. So although I might have moved forward a few inches during the motion, my momentum is zero at the end. When you scale this up to large numbers of air molecules, the result is the same.
thanks for following up. I think this is one of those conversations that works better in front of a white board - it's surprisingly tricky to express in words.
if the demo was mainly to show that it's the jet of air expelled out the back that's providing thrust, then, fine it does that and its a valuable lesson. I guess I'm hung up on the technicality that there is actually a real movement of air mass even without that rearward jet and that has to be felt by the apparatus - I guess it's just unnoticeably small in the real world demo.
anyhow, my confidence in physics intuition has been shaken. thanks bunches.
Nah the demo was right. The impulse from the sucking (ie air molecules bouncing off the inside of the fan blade) is countered by the impulse from the air molecules bouncing off the inside off the back T-pipe. Different at a low Reynolds number with a reversible flow.
Reynolds number, compressibility, reversibility don't really matter for this - the principle under discussion is a simple momentum-balance. Find the force on the pipe by analyzing what is happening at the boundaries, you can ignore what happens inside. (in engineering this is called control-volume analysis).
The exiting flows out the sides neatly cancel. So what's happening from front-to-back? There is air flowing in at some velocity x cross-sectional area x air density. this momentum has to be balanced completely for the pipe to stay still - but there is no source of momentum in the other direction so the pipe will feel this force and move.
if the pipe was open at the back, there would be momentum exiting the pipe balancing the incoming momentum - or even over-balancing (as in a jet engine)
Reverse thrust doesn't come directly out the front of the engine - it's vented out the side (or, in very old engines, redirected from the back exhaust):
that is a misleading way to put it - the reverse-thrust air does indeed move toward the front of the plane. it also moves outward, and is often taken from the sides of the engine, but a component of the (reversed) thrust is definitely going opposite the usual direction.
Your forgetting that the cool dense intake air is expanded (greatly) in the engine via combustion with fuel, so the volume of air being exhausted is much greater than went in and at much higher pressure, this is where the thrust comes from in the first place. It's not just a big fan :)
Think of the net momentum balance. Some mass of air is entering the intake at low speed, the engine does work on the air, then the air exits the front at very high speed. The intake speed is approximately the airplane's speed (150 mph), while the exhaust speed is probably 500 mph.
If the suck force and the blow force were equal, you wouldn't need to burn fuel inside the engine during normal operation. Combustion produces a lot higher volume of gasses at higher energy than the air that goes in the front.
Keep in mind my experience was almost exclusively with communications systems, which are important but nowhere near as vital as things like autopilot. Things could very likely be better there, or at a different company. And even many of the things I worked on were like you describe. There is a lot of red tape and testing to make certain changes, and the industry documents are often strict. But it wasn't always clear how much of that actually made things better/safer and how much was just fluff.
How many easter eggs will emerge from Boeing. In last 2 months, we had similar incidents from Boeing where an undocumented software safety kicked in and causing trouble for everyone
It's not just Boeing unfortunately. Every software driven aircraft seems to suffer from these bugs. The F35 lost radio communication after crossing the international date line the wrong direction IIRC, and the pilots had to use hand signals to land.
> The F35 lost radio communication after crossing the international date line the wrong direction IIRC, and the pilots had to use hand signals to land.
From what I remember, the first time 4 USAF F22 were flying across international date line to deploy to Hawaii(?), they had software related issues. As they flew across the international date line (first time in a real flight), all computers on the jets crashed, including navigation/etc.
Luckily they were flying in close formation with a tanker, signaled with flashlights, and were able to follow the tanker back to another base safely.
I believe USAF requires a multi jet (usually tanker) to accompany small jets when they are flying across the ocean.
That aircraft was being knowingly flown with [edit: a broken sensor]. It was unsafe on takeoff.
The final problem that brought the aircraft down - the trim run-away - happens all the time in airliners you've flown in. When the run-away starts, the pilot is supposed to flip two switches to disable the trim system motors. In the Lion Air crash, it is indeed believed that a software bug from the misbehaving sensors started the run-away, but again, handling trim run-aways are something that pilots are supposed to train for and deal with.
737's are even safer here than many airliners, because after you disable the electric trim motors, you have manual wheels in the cockpit that you can rotate to set the trim back to what it should be. Some other airliners in common use don't have these manual trim controls - you have to disable a trim run-away in time, or it's game over.
> the trim run-away - happens all the time in airliners you've flown in.
It doesn't. A trim run-away is a very very serious incident for any pilot.
There are procedures to deal with it, and we check trim override in pre-flight checks, but it's absolutely not an everyday thing.
> 737's are even safer here than many airliners, because after you disable the electric trim motors, you have manual wheels in the cockpit that you can rotate to set the trim back to what it should be. Some other airliners in common use don't have these manual trim controls - you have to disable a trim run-away in time, or it's game over.
This is not true at all either. There are no planes with a single electric trim that you cannot override. The FAA and EASA would refuse to certify those.
I've never flown an E190, but if you Google the basic systems description you'll find that it has two sets of trim controls and on top of that separate override controls.
Both circuits are electric, but they are separate systems on separate power busses to ensure you always have control.
> That aircraft was knowingly flown with multiple broken sensors. It was unsafe on takeoff.
You'll need to cite that, since it contrary to any information I can find on the Lion Air accident e.g.:
> The chief executive officer of Lion Air, Edward Sirait, said the aircraft had a "technical issue" on Sunday night, but this had been addressed in accordance with maintenance manuals issued by the manufacturer. Engineers had declared that the aircraft was ready for takeoff on the morning of the accident
Your claim that it was "unsafe to takeoff" and had "multiple broken sensors" is pretty remarkable. So I'll definitely need to see a source backing up such remarkable claims.
From the same Wikipedia article that was just linked:
> "The aircraft suffered an airspeed indicator problem for its last four flights, including the flight to Denpasar. Thinking that it would fix the problem, the engineers in Bali then replaced one of the aircraft's AoA sensors, but the problem persisted on the penultimate flight [...] [the crew] recorded a twenty-degree difference between the readings of the left AoA sensor and the right sensor."
> "On 28 November, Indonesia investigators said the Lion Air jet was not airworthy on flight before crash."
Right, there were repeated problems with the angle of attack sensor. If I had to guess the sensor itself is and was just fine and the problem lay elsewhere in the pipeline.
More important though is that the 737 MAX differs wildly from earlier 737s in how much it relies on the AoA data. Mechanics and pilots not experienced with the MAX were probably operating under the (false) assumption that a bad alpha vane wouldn't be the end of the world. In fact displays indicating the angle of attack and warnings about disparity between the alpha vanes is an optional feature on the 737. It's considered that unimportant.
The key differences from earlier 737s are that the MAX uses the AoA data to calculate airspeed and that the MAX may use a single AoA input to try to kill you. I believe the former was disclosed, but considered how short the differences training is may have been easily overlooked. The latter, of course, was not disclosed until the crash.
Those are prior flights. The aircraft was fully repaired:
> The chief executive officer of Lion Air, Edward Sirait, said the aircraft had a "technical issue" on Sunday night, but this had been addressed in accordance with maintenance manuals issued by the manufacturer. Engineers had declared that the aircraft was ready for takeoff on the morning of the accident
So you still haven't supported your extraordinary claim that the aircraft was:
next flight reports that another, worse problem has appeared - bad enough that regulators have now said that the plane was "not airworthy" during this flight
maintenance "fixes" the problem
final flight impacts ocean at high speed
Your assertion is that since maintenance cleared the plane after the second fix, the plane must have been fine. To that, I point to the previous time maintenance cleared the plane, when it was demonstrably not fine.
No, my claim merely was that the quote does not make the claim about the specific flight (although I didn't word it quite clearly). The findings about bad maintenance culture certainly suggest that the plane wasn't fixed properly.
“Indonesian investigators have said the Lion Air Boeing 737 jet that plunged into the sea, killing 189 people in October, was not airworthy on a flight the day before it crashed.
They further found that Lion Air must improve its safety culture and better document repair work on its planes.
The flight from Bali to Jakarta on 28 October had experienced similar technical issues to the doomed flight the next day from Jakarta to Pangkal Pinang, said Nurcahyo Utomo, head of Indonesia’s national transport safety committee (KNKT).
The pilot of the 28 October flight chose to press on to Jakarta after shutting down the plane’s anti-stall system, Utomo said.
“This is the basis of our recommendation to Lion Air. In our view, the plane was not airworthy,” he told a news conference in Jakarta.
...
But its investigators said that Lion Air kept putting the plane back into service despite repeatedly failing to fix a problem with the airspeed indicator in the days leading up to the fatal flight.”
-
So the aircraft spent several days flying with a broken sensor, sometimes without even an attempt at repair.
> “Indonesian investigators have said the Lion Air Boeing 737 jet that plunged into the sea, killing 189 people in October, was not airworthy on a flight the day before it crashed.
And was repaired between the two flights as I quoted above. Are you selectively ignoring the information in the very post you replied to?
Here's that information again to refresh your memory:
> The chief executive officer of Lion Air, Edward Sirait, said the aircraft had a "technical issue" on Sunday night, but this had been addressed in accordance with maintenance manuals issued by the manufacturer. Engineers had declared that the aircraft was ready for takeoff on the morning of the accident
You and the other poster seem to be basing your whole position on time not moving forward in a linear fashion: Failure, repair, flight. In that order.
Pointing out the previous day over and over while ignoring what occurred in the interim isn't a real argument.
Let's say you hear a knocking sound from your car engine. You take it to a mechanic for repairs, and the mechanic says he fixed it. But you still hear the knocking sound. If you repeat this cycle for a few times, when the mechanic says for the Nth time that he fixed the problem, is it actually fixed?
To save people the reading, the safety feature triggered was an automatic dive maneuver initiated by the flight computer as a result of an incorrect angle-of-attack sensor reading causing the plane to believe it was in a stall, when it actually wasn't
I didn't look into it any further, but based on that alone I would agree that this seems like a shitty feature, perhaps a loud alarm or other warning would be more appropriate than putting the plane in a dive without human intervention
The 737 is a short and stubby airliner with its center of thrust far below the rest of the aircraft. The 737MAX version added upgraded, powerful engines. It is theoretically possible for the engines to flip the aircraft up and out of control if power is applied too quickly in certain fight situations.
You can still disable the stabilizer trim from switches in the cockpit, though. This was in the checklists that the pilots had, and done by other pilots in that aircraft in the days before the accident.
Yeah, it's hard to make the argument that a recovery procedure is so incredibly difficult and obscure when several previous flights of that plane experienced the same issue and successfully followed that procedure... And apparently without considering it extremely outside of the norm.
The second high-profile potentially deadly software caused failure related to automated safety features in as many years (if that ends up being the cause, of course).
Very glad the touchdown went nominally. Had they pushed the point of touchdown just a bit further down the tarmac, they'd have skittered right off the pavement.
This is straight out of chapter 1 of Alan Cooper's "The Inmates Are Running the Asylum" (2004). What do you get when you cross a computer and an airplane? A computer!
Seems like reasonable choice on the Boeing's part, the objective of the reverse thrust is to provide additional braking to the aircraft, if shutting down the engine has similar effect (albeit to a lesser extent), why not?
Better than getting stuck in a dangerous situation if the reverse thrust was deployed prematurely.
> Engineers inspected the engines and could find no reason for the dual failure. With the post-inspection finding nothing to cause the engines to fail, engineers are saying the likely cause for the shutdown is a software issue onboard the aircraft.
Very interesting that
a) one of the first checks by engineers is not an evaluation of the software "log" or similar. either they have a specific checklist they MUST go by and that checklist doesn't include software log, and/or such log is simply not available to them.
b)"likely cause"? again, why don't engineers have easy access to a software event log?
I can very well imagine such instrumentation of software caused events not even existing for the shit apps we build, but for safety critical systems in an airplane? The log MUST exist. Why don't engineers on the ground have easy access to it. The software is integral these days.
And where would you store these logs ?
I'm sure the engine stores its faults somewhere, but i'm not expecting more.
You have to realise that you can run safety critical software on certified microcontrollers, which have usually like 10 mb of flash. Moreover it is an aicraft, and worse it is an engine, so I guess that the mechanical requirements are insane (able to withstand a lot of vibrations, operate in -60 to 160 deg celsius, withstand cosmic rays). A samsung ssd does not fit the bill.
It's probable however that the aircraft communications lines are recorded in a black box, but you can only see the data exchanged by the ECUs, not the relevant internal variables telling you about the bug.
Mind you i'm not working in the aicraft industry, my assumptions may be false, but my guess is that the engine controller is on the engine itself.
Does nobody remember the Lockheed aircraft that ran off the end of the runway because both the brakes and lift spoilers refused to deploy?
It was another case of misguided safety interlock. IIRC, they landed 20 knots fast because of storm conditions; the brakes wouldn't go with too little weight sensed, and the lift spoilers wouldn't go above a certain speed. Catch-22!
I had expected this story was about a Rolls-Royce problem; their Trent 1000 engines are giving the 787 a bad name. But it looks like it was just a normal software interlock that would never cause a problem during flight.
Well, Rolls Royce monitors those engines remotely and have access to their logs afaik. So, it should be clear by now whether it has been called from software or not.
That's not true. A full investigation will be required to reconstruct events from all data stored by the various Aircraft systems, including the engines.
The article is a bit ambiguous to me about whether it was 40 minutes after landing or 40 minutes after they failed to restart the engines. The former is sensible to me since it'd take time for them to try to restart the engines and make sure the plane is otherwise safe (probably some kind of checklist to do as well). Some other articles on this explicitly say it was 40 minutes after landing.
> The pilots followed their checklists and worked with maintenance personnel via phone to troubleshoot, but were unable to get the engines to relight. This left the aircraft stranded and led to the closure of the runway. A tow truck arrived some 40 minutes later to tow the aircraft off the runway.
It's ambiguous to me because the runway would presumably be closed as soon as the plane got stuck and not after waiting for the engines to restart. So the obvious reading of the sentence doesn't make sense.
No, not really. It's not an emergency response. They probably did not request it right away as they expected to restart the engines. Once it was requested, they had to find someone available to operate it who had to go get it, perhaps check the fuel and fluids, et cetera, et cetera. Depending on the details, 40 minutes could actually be considered quite quick.
To my reading, it is a bit ambiguous when that 40 minutes starts, but so what? I am still not surprised even if it took 40 minutes from the time it was requested for the reasons I already stated.
It might make me worry about their fire response capability. On the other hand, there's probably an element of triage involved here (no immediate threat once the runway was closed). More generally, I would expect problems that a tow truck solves to not be as urgent as problems that a fire truck solves, so garaging the tow truck farther away seems plausible.
Wait, what - Rolls Royce?! The same company that makes the some of the most expensive and unreliable cars on the market? Boeing, Boeing, what were you thinking?
How do you restart the Boeing 787 in mid-air? With the lack of an APU (they use li-on batteries, I think?), what's the mid-air engine restart procedure?
Just like any other jet enige... Get it to spin fast enough, enable the igniters and add fuel. Be careful with how fast they spin before adding fuel, too slow and things get very hot and melt.
Getting them to spin fast enough in a 787 is a bit different from a traditional jet engine, because traditionally you spin them by pneumatic power (from ground, APU or the engine) and in the 787 you spin them by electric power (from ground, battery, APU, other engine or RAT). But there isn't much difference from a pilot's point of view.
This comment is ignorant as shit. Critical aircraft systems are certified Design Assurance Level A. Programmers are one small part of the development cycle. Every line of code is reviewed, validated, and verified.
Oddly enough, your comment makes me think that you are writing it from the perspective of a member of the very group of programmers you decry. Companies that write high-risk, life-critical systems don't just let any ole J. Random Hacker work on such critical systems, and I don't think anyone who has worked in such a field would realistically think that these "brogrammers" as you say would be seriously considered for such a position. Companies don't play around with this kind of thing as failures are EXTREMELY expensive in terms of both funds and reputation.
Sure, but tests are only as good as the programmers that write them (and that's if those programmers are GOOD at writing tests, which is not universal). Not to mention no amount of automated testing is foolproof.
Full disclosure, I design and write system software tests for a living.
I think software has existed in computer systems for 7 or 8 decades now - and the pitfalls are well understood.
I think the problem is one of simplicity vs complexity. New systems today rely on dozens - hundreds even - of packages and libraries - many of which are not written by the implementer. How can you ensure reliability in all these components?
This is why engineering from first principles - even in today's software development environment - is important. Unfortunately, the trends are in the other direction.
> I think software has existed in computer systems for 7 or 8 decades now - and the pitfalls are well understood.
This would be funny if it weren't tragically wrong. Time and again we learn that software is very much not yet well understood, especially in large and complex systems. And aviation does this a lot better than most other lines of business.
The trend has always been in the other direction. It's easy to reason from first principles when the principles are simple. As more people become experts on our problems, the correct solutions become much more diverse and specialized, and it becomes harder and harder to build integrated systems from first principles.
That's not a very useful reply. Can you explain where anonu is wrong? Can you explain why? Can you give some evidence? A bare dismissal is like five-year-olds arguing: "Did too!" "Did not!" It's not useful to advance the conversation, and it's not effective at persuading people.
It's quite possible that software creates new failure modes (as programmers I'm sure we all feel that to be true some days) while at the same time preventing more.
When the software fails (if it did) we assume the software makes it more dangerous because we have a concrete example of what happened but not what could have happened in it's absence.
This is what may eventually stall self driving cars for many years, the first time one does the PR equivalent of smashing through the local orphanage.
We as a society are notoriously poor at assessing systemic risks.
Now to address your point about evidence, I'm curious how you could control for other confounding factors.
Airliners are safer today than ever before (based on passenger miles) but how do you control for better engines, material science, procedures if you compare say 1979 to 2019.
But I have a friend who's an airline pilot. He was telling me about hitting windshear while coming in for a landing. The plane has software that not only tells him that he hit windshear, but also tells him what angle to put the nose at for best results. (The problem is airspeed. So you go to full power, but pitching the nose down also helps you gain airspeed. But the ground is down there, because you're coming in for landing. What angle is the best? The computer can figure it out and tell the pilot what to do.)
Aye, Things like that the G3000 (Garmin avionics suite for light aircraft) that now do real time 3D terrain generation so that less experienced pilots can avoid controlled flight into terrain (literally the way they describe when a pilot in control smashes into a mountain).
My suspicion is that modern computerised avionics are on balance a life saver but I'd love to know by how much.
I ended up watching videos of modern avionics in light aircraft on youtube a while back (as you do) and I find that kind of programming fascinating, couldn't find much out about the actual hardware/software side of things though I did gather it runs a custom OS.
It's a liability when you're getting equipment serviced, whether there's software or not. We have a Cat 287B skid-steer. After a month of inactivity, it wouldn't come out of "park" mode. A mechanic lifted the cab, tested a couple of solenoids, and stated "must be a bad computer". This is an old machine, so I called Cat and confirmed that it doesn't actually have a computer. I took up the floorboard and found some wires that had been chewed by rodents. We're lucky we don't have a computer, because replacing it wouldn't have helped...
Software is like any other technology. It can be a liability or an asset or both depending on how it’s built.
Sometimes software fails and sometimes it even kills people, but how many lives has it also saved because of things like collision avoidance and accurate navigation?
The trend over the last 20 years has been that 1: airliners are getting safer and safer and 2: airliners contain more and more software. True, the software introduces new failure modes. But the presence of software in airliners seems to be less a liability than the absence of software.
My take-away is a little different: As software grows it is hard to quantify.
If you have several small distinct systems, you can often quantify them down to inputs, outputs, and expected logic. Once systems get too complex, you have too many possible states, and bugs are harder to find (and the system cannot be fully defined).
I often go back to the famous Therac-25 accident. The bug in Therac-25 existed LONG before the accident, but there were two systems interacting, one system checked the other system's output and threw away invalid state. Once those two systems were merged, it was only then that the bug turned into an accident.
If aircraft stopped building monolithic software and instead built parts that ran on software, parts that could each be individually verified, it would likely result in safer software.
Indeed. And that is just an extension of the danger presented by electronic systems generally.
When learning to fly sailplanes, I was always grateful that the "primitive" wood, steel and canvas gliders I flew had purely mechanical linkages between the controls and the control surfaces, and only one instrument that required electricity at all (and even that was duplicated by a purely mechanical version).
Obviously automation has great advantages, but inevitably the increased complexity comes with risks which are more difficult to fully comprehend.
I’m also a glider pilot and I also appreciate the simplicity of the basic systems, but I feel like it’s worth noting that you’re far more likely to die in a glider crash than you are in a modern airliner full of complex software.
> I hope people are beginning to understand that the presence of software in any system is a liability.
I do not understand this point of view.
If you don't have software, you are going to replace it with something mechanical. Or with people. Or lose the functionality entirely.
Do you want to bring back a 'flight engineer' to operate airliner engines?
Do you want to bring back mechanical autopilots? Analog computers? Let's ditch GPS while we are at it (GPS failures can cause deaths, specially under poor visibility).
Airbus has been been doing "codeless" development with Esterel products for quite a while. I put codeless in quotes, because I believe the tools to generate code at the end of the day - but it's not code that is written by humans, and it is generated based on formally verified models.
Yes they generate c code which is compiled.
I don't know if the model is formally verified, but the whole toolchain from esterel, including the library blocks are certified (aicraft, automitive, industrial and train safety levels)
It does not mean that any software done with this tools is thus certified, you need to apply the safety methodology to certify it
Very interesting! Trying to understand a bit better... does this mean that a human writes some logic, then it gets translated into a formally-verified model? Or these are pieces of verified code with strict combinatorial rules and the human does the composition?
More precisely. For two systems offering the same functionality, the one that does so using less software should be preferred, because software of any nontrivial complexity is irreducibly buggy.
Is there something special about the software in new Boeings? Dual engine failure is nothing to sneeze at, and should never happen. Airbus also had its fair share of software errors in history, but if we count the recent Lion air crash as software related, Boeing has had 2 serious software related incidents in a year and I haven't heard anything serious from airbus.
Is it because Airbus started its fly-by-wire development earlier?
I think with these types of incidents being very rare, it's hard to extrapolate to any kind of patterns.
Not within the year, and I'm sure there are more (for both Boeing and Airbus), but this one comes to mind on an Airbus that's pretty scary -- thankfully occurred at cruising altitude: https://en.wikipedia.org/wiki/Qantas_Flight_72
It's not the aircraft, it's the engine. Boeing 787s have been grounded recently because problems with Trent 1000-C have been increasing. Mainly compressor blade durability.
Modern jet engines like Trent 1000 from Rolls-Royce have
Full Authority Digital Engine Control (FADEC). It comes with the engine and there are no manual overrides. The computer system runs the engines and if it fails the engine fails almost instantly.
Before the flight pilot sets flight parameters to flight management system (FMS) and FMS communicates them to FADEC in the engines. FADEC runs the engines and 'micromanages' the system in different phases of the flight. There is large number of parameters and engine health monitoring and diagnostics going on. Most of it is not the responsibility of the aircraft manufacturer. Engine sends data to Rolls-Royce.
The first Airbus FBW airliner was the A320, introduced in 1988 (31 years ago), while on Boeing side it was the 777, introduced in 1995 (24 years ago). By now I don't think it would make much of a difference, if any at all.
If anything quarterly reports to shareholders who only care about the very short-term would be the culprit (or management teams whose bonuses only depend on the next quarter revenues). But numbers are stubborn and don't tell that story: the more recent the plane the safer it is. As such 787 and A350 are probably the safest airliners currently flying, followed by 777 and A380.
Many actual pilots would likely disagree. Shoehorning vastly different planes into the same type certificate can be dangerous. Convenient for pilots due to certification and recurrency issues, but not necessarily a good idea.
Do you really want a pilot to jump into a 737MAX who only ever flew the -100? I bet the memory items are very different if not also all the speeds and weights.
I'm not sure this is a bug. It sounds like pilot-error to me (I am not a pilot):
"In the bulletin, Boeing said that selecting full reverse too quickly upon landing before the aircraft has fully transitioned to ground mode could cause the system to activate."
Dual engine shutdown is incredibly dangerous, there's no situation (other than a commanded shutdown) where that should occur.
Regardless of cause, regardless of if the pilot activated the thrust reverser too early, this is an incredibly dangerous defect that Boeing (or Rolls Royce) needs to fix before more people are put in danger.
Let me phase it this way: Even when the engines are literally on fire, they don't automatically shutdown, because doing so is considered too dangerous (since the systems don't know the circumstances, and even an engine on fire can generate thrust, and it might be your only engine).
Even if the defect was DISCOVERED due to a pilot error, it is still a defect and a safety critical one at that.
Pilot error happens and the equipment is expected to make it as difficult as possible. If a simple action can endanger a plane-load of passengers, that’s a bug regardless of whether the pilot is supposed to do that.
Depends if "too quickly" means "clearly dangerous, so the system prevents a risk, and it's clearly the safer thing to do" or "fast enough to trigger the bug"? And even if it is the former, presumably it should be signaled and restart possible afterwards.
I tend to agree after reading the bulletin. It seems to be a safety net for the plane/engines that maybe needs better input validation so that a pilot eager to hit the brakes cant do this again. In this context its a UX bug.
There are usually failsafe modes that disable most of the additional software features. It is pretty rare though for pilots to switch into those modes though since those features are what fly the plan a majority of the time.
It is like the issue that are running into with self driving cars, there is a point where the flight controls become so good that pilots are less likely to intervene when something is going wrong.
The 787 is a replacement for my 767 (currently a pilot on the aircraft) and in 1991 a Lauda Air 767 suffered a failure in one of its thrust reverser and it became activated during cruise. The aircraft was destroyed in flight.
The thrust reversers should not activate during flight (a air/ground sensors prevents that) but as it is a catastrophic failure, having the engine shut down automatically seems like a great fail safe device.
In this case it seems that the 787 engines were reversed before the air/ground sensor had sensed ground and it is a potential problem.