Hacker News Reader

The button did not fail. Once your wheels are on the ground advancing the throttle is dangerous and requires manual throttle entry. so that is what the system did.

Take-off/go-around is a complicated maneuver involving quite a few tasks that need to be orchestrated to preform it correctly, in short you need to quickly transition the aircraft from it's landing configuration to it's take-off configuration. an ideal situation for automation. However according to the article.

"However, the TOGA switches are inhibited on landing after touchdown, because if a pilot were to accidentally press it during rollout, it could cause the plane to run off the runway. The autothrottle system remains active, but if sensors detect that there is weight on the wheels, the TOGA switches simply won’t do anything."

The button failed. If one of its core functions can't be carried out because of the circumstances, that's fine. But it's the system's responsibility to announce this very clearly, because if a button that usually makes you go fast suddenly doesn't, you want to know.

You missed the point. The core issue is not the button being inhibited, but being silently inhibited. The pilots were not aware that power did not increase when they expected it to do so.

Just show a bright red warning or a voice alert when the inhibition activates.

But there is an indicator, there is this huge lever that takes up most of the space in the center console. when the thrust is increased by the auto throttle the lever moves forward, With no critique to the pilots, they were in the edgeist of edge conditions, things were happening very fast, the airplane had more lift than it should have, and they acted with all due credit to the profession during the incident.

So we look to find what could have been done differently, There are many small things that perhaps could have prevented this, basicly this is the article. But one of those things was to notice that the huge lever in the center console was not moving. and their hand was right there to pull the togo switches.

It's weird to me that the pilots didn't notice that the engine thrust hadn't increased. I realise they have a lot to monitor and it all happened quite quickly, but it seems like not having your engines at 100% when they're supposed to be would stand out. I'd be interested to see what they would have seen and how obvious it was.

The engines don’t immediately go to 100% - it takes time for them to spin up, 5+ seconds sometimes.

The engines are also very far from the cockpit, and behind them. They hear them, but not well.

So it’s not that surprising they didn’t immediately notice the problem.

That they did notice, and relatively quickly, is a sign of how well they did. But seconds matter in this scenario, and by then the lag to spin up resulted in no significant change of thrust before impact.

There is a feedback mechanism to engine throttle that is immediate and physically obvious: The thrust levers. They will move to indicate the amount of thrust the engines are ordered to produce, even when under autothrottle control.

If a pilot doesn't pay attention to where his thrust levers are when appropriate thrust is critical to safe flight, that is pilot error.

A go-around isn't complicated enough to merit reliance on automation anyway: Max thrust (or whatever is appropriate), pitch up and climb according to ATC orders or go-around procedure at airport, landing gears up, and come back for another landing attempt.

There is a button they use on go around that turns on auto throttle up, which they hit. In the scenario they thought they were in, they don’t directly interact with the throttle levers. They were paying attention to other things, like they were supposed to.

In this scenario, the auto throttle doesn’t auto throttle up because unexpectedly, they were partially wheels down for a moment, and that disables auto throttle up.

Oops.

In the "Children of the Magenta Line" video they tell you to hold the throttles physically in place in similar situations, but not this one exactly. They want you to hold all the controls when turning on or off autopilot, changing modes, or if you think something is going wrong (this kind of plane has multiple autopilots, so weird stuff can and has happened). I guess what you could do in this case is touch the throttles to make sure they are doing what you want, and retain the ability to grab them and push them forward if the auto-throttle system is not doing it.

However the levers do physically move forward and the EPR indication should spool up when the TO/GA button is pressed. Many moons ago, one of my instrument instructors was insistent on physical verification of control status even in light(er) aircraft. You didn’t take your hand off the gear lever until you saw 3 green. On takeoff or go-around, especially go-around, you kept one hand on the throttle levers until after positive rate of climb was achieved. Had the PF here had that practice, the accident would not have occurred. That said, if the TO/GA button is unavailable in a given flight mode, a more obvious verbal annunciation of that mode should be made by the aircraft.

Nod, and they changed their training to make many of those changes after this accident - one of about 40 changes.

Definitely one of those ‘if the PIC had been a little more paranoid, and a bunch of other rare/weird things had not happened, it would have been fine’ type accidents. The first officer was supposed to also verify things, but the specific step wasn’t in the training either, and wasn’t normally applicable because of the TO/GA automation.

Luckily no loss of life from the crash directly. If the firefighters had listened to prior crash issues and fixed them in their own response, likely no firefighters would have died either.

> On takeoff or go-around, especially go-around, you kept one hand on the throttle levers until after positive rate of climb was achieved.

On multi-engine jets, common training is to remove your hand from the throttle at V1 (takeoff decision speed). Most problems after that speed are to be taken airborne and dealt with there.

Moving to high thrust is felt by the gravity vector shifting off your butt a little toward your back. There's another thing that has this effect: pitching up. The two can be really hard to distinguish.

(In fact, this idea of gravity-relative-to-butt is very strong in people and when that fails to be a useful model is often when we see accidents happen.)

Diving straight down, can feel like driving forwards, which is why the https://en.wikipedia.org/wiki/Primary_flight_display is absolutely vital. One can not trust your senses when flying a plane.

On the same theme, inverted flight feels like a rapid change of pitch downwards (both accelerate you kind of toward your head), so the natural response is to "pitch back up" and get the acceleration back under your butt (which of course inverted means you actually start diving for the ground).

Not sure about that, if there is no additional thrust the aircraft will be decelerating because it's running "uphill", pulling the gravity vector forward. It'll be balanced, so you don't "feel" acceleration or deceleration.

It's the same in a car, if you are coasting in neutral and encounter a hill, even though the car will be slowing down there is no "perceptible" longitudinal acceleration because it's caused by gravity (equally acting on the car and the occupant), just like in space or one of those zero-G flights.

There would be an increase in drag when pitching up, that would also cause deceleration.

And that's why full-motion flight simulators "work".

I think it's a "yes, and..." because it's conceivable that the alert itself could fail to notify pilots for some reason. So the pilots shouldn't rely on the automation to work 100% of the time, nor that the system will alert them to a problem with 100% accuracy.

So it's both correct to recommend that the Boeing 777 try to alert the pilots to the misconfiguration, and to reinforce pilot behavior to reduce the risk of being in a position where that misconfiguration happens.

i'd be curious to hear the reasoning that lead to "silently ignore the button press."

even basic consumer devices bark at you when a button press is invalid, and the people who work at boeing are obviously not idiots.

my guess is that there are a series of guidelines, solid reasoning or standardizations that lead to this nonsensical result and that decision-making and design process itself would be the interesting thing to understand in what went wrong here...

> the people who work at boeing are obviously not idiots

well... knowing what we know of MCAS, and their whole approach to user interaction ... that bar is very shaky.

anyway, the answer seems to be that the button has a clear feedback in the form of physical thrust set-point indicators. basically the pilot (if I remember the post correctly, the first officer) should have noticed that despite pressing the button the set-point indicators did not move.

mcas seems sort of different, in that it was a software/computer patch for a hole that was opened up in the physical handling characteristics of the aircraft as part of the retrofit to make it more efficient. it seems clear to me that it was an experiment in fusing computer with modified airframe to try and thread the needle of "no additional training required" and increase the financial performance of the program.

i suspect the story behind most decisions in flight control ui is a very long one, with a long list of lessons learned, expectations set and human factors. these things arise in any complicated design, where some new feature violates the existing design principles and a compromise is made that on its face makes no sense, but in context is totally understandable.

that context would be interesting.

sorry, I wasn't clear what I meant.

As far as I know - please correct me if write this wall of text based on inadequate information - the problem with MCAS was that they wanted to hide it, but that's not necessarily bad UX. what's bad is that they obviously failed in two distinct, but connected and together critical steps/aspects.

1) MCAS did its thing in 10 sec bursts. which was just crazy, never before seen madness. (I agree local design context is important, and I would like to know WTF was the context for this.)

2) it was undocumented because Boeing argued that it was technically just a runaway stabilizer failure, already covered by the manual/training

I would argue that the 1st failure was the (more) fundamental one, the UX one. because if the fucking thing looks like what a typical runaway stabilizer malfunction looks like, then yeah, it's "okay", pilots should be able to recognize/remember the correct remediation method for it.

...

of course it's debatable how close the new airframe + engines (without MCAS) were to the old one in terms of flight characteristics. it's possible that it really flies like an old one with too much weight in the back, and that's routine for pilots.

...

and just to be clear, I think it's just inexcusably dumb to try to cheap out on proper training.