Hacker News Reader

Comment by marvin | Hacker News Reader

In the Airbus accident, the level of automation was a contributing factor to the accident. The fly-by-wire system prevents the pilot from placing the aircraft in an unsafe condition. However, this system was automatically deactivated (which is an extremely rare occurence) when the pitot/airspeed tubes were covered with ice and the computer hence couldn't make correctly informed decisions about the aircraft.

In that case, however, you could point to a big UX problem: It was not announced in big, red letters that the fly-by-wire system had in fact been deactivated. If I remember correctly, this was hidden under some menu in the flight computer and simply abstracted away to a "master caution" light or something in that vein.

View on HN

> It was not announced in big, red letters that the fly-by-wire system had in fact been deactivated

It was announced in medium-sized orange letters reading “F/CTL ALTN LAW (PROT LOST)”. At least one pilot did notice this; the co-pilot who wasn’t pulling up the whole time said “alternate law, protections lost” out loud, as recorded on the CVR, when the message appeared.

I think he might have noticed, but not fully realized the implications of it. His behaviour following at least did not indicate that he was concerned about a stall, and there were no further mentions of this warning.

Would that not be a UX issue? Perhaps the warning needs to include the phrase "Failsafes deactivated" announced repeatedly.

Yep, I would say that, as far as I remember there were also several other warnings at the same time. There were some recommendations in the accident report regarding UX improvements.

I think there was a similar problems at Qantas Flight 32, where the crew had to spend a lot of time going through 54 error messages after an uncontained engine failure.

right, but there was also a pilot who was pulling back on the stick the entire time.

And the airplane averaged the inputs from the two sticks, which strikes me as a positively BRAINDEAD design choice. Why would you ever want to average the two inputs when flying a plane? Are you hoping that one pilot pushing and one pulling will somehow, on average, fly the plane correctly?

When assuming that in the normal case the pilots are never doing the opposite of each other ... the difference between each stick is probably less than 5% or something. Agreed that in this case it seems the worst thing to do.

The braindead decision (in my uninformed, armchair pilot opinion) was made when the controls were no longer physically linked. Once you have controls that can move independently of each other, none of the options for handling conflicting inputs makes sense to me...

Sum them?

Only take the most extreme of the two inputs (in any given direction)?

Only take the most recently seen input?

Averaging makes more sense than any of those, given the premise of "Control sticks that can move in different directions"

You're right, but I'd go with "the secondary control is ignored and clearly marked as such" ("ignored" light turns on or something). But yeah, if they aren't linked, there's not much you can do that will make sense.

Nah, the right way to compute the final inputs in a case like this is, "This design is stupid and is going to get somebody killed. There is nothing I can do at this level to fix it. You must physically link the two controls."

It is rarely discussed, but a major factor contributing to the Airbus crash was that the software did not derive airspeed from engine parameters and use it to verify the pitot tubes. The common mode failure of the pitot tubes could have been anticipated and protected against.

Reply on news.ycombinator.com