Hacker News Reader

Comment by Nick_C | Hacker News Reader

> how does a plane know it's stalling if the pitot tubes are frozen

Angle of attack sensor. AoA is the actual definition of a stall as it measures the point at which airflow breaks away from the wing, reducing lift.

Re your other points on computer warnings, cockpits can get pretty noisy when shit happens with various alarms, buzzers, horns and voices going off. There's actually a tendency to reduce the number of different alarms and use screen information to indicate the problem (although that may be changing after the Qantas drama in 2010 http://en.wikipedia.org/wiki/Qantas_Flight_32).

View on HN

I utterly agree on reducing continuous and loud sound warnings in the cabin.

This 1996 757 Aeroperu crash recording is quite scary: http://www.youtube.com/watch?v=G5QSBlYTJ1Y

They had no functioning pitot tubes and lots of contradictory indications, which triggered a storm of alarms, most of them false. Pilots spend quite some time trying to shut alarms off while trying to figure out their situation with air control. I can't imagine trying to talk and cooperate with colleagues, facing a complex system and a life-or-death situation, while so many loud and stressful sounds are buzzing through my ears.

After 9:00, the plane inverts upside down, a "whoop-whoop" alarm goes off and the plane finally crashes into the sea. The alarm only served the sinister purpose of announcing they were going to die.

I really appreciate that recording because it helps empathize with exactly how disturbing it would be to be in that situation.

   There's actually a tendency to reduce
   the number of different alarms and 
   use screen information to indicate the problem

Yes, that'd be good UX. There should be only one actionable task presented at any time to correct errors. In any case, user testing is more important than guidelines.

I wonder if grouped alarms make any sense. For instance you can group all alarms related to stalling together, and present the one thing the pilot can do to correct this. This gives the pilot a sense of what is the most effective use of their attention in a bad situation.

QF mishap - the Wikipedia article didn't talk about the alarms.

With the Qantas incident, they had something like 146 msgs appear on the screen spread over about 5 or 6 pages. So they were forcibly distracted from solving the problem from a top-down approach to having to investigate and cancel each of the 146 msgs, and that was why the two extra pilots were such a godsend, they were able to help out.

Yes, a message flood is also a failure of UX. At my place of work, when a flood of errors occur, we throttle and batch the errors so that the admin doesn't get thousands of emails.

Given that user interfaces on airplanes are digital now, there are a lot of opportunities to innovate.

For instance, where there are multiple failures and alarms, it might be better for the panel to continuously replay the sequence in which the alarms were set off, more or less like how movies do it to help the viewer understand what is happening on the computer. By showing how a system is failing through time, it shows a causal relationship. In addition, you can provide drill down capabilities.

In the case of Air France, perhaps it could have illustrated the AoA through time, and the flight velocity. Perhaps that would have explained something to the pilot.

Messages are prioritized on the screens in the cockpit in any aircraft I've ever seen. Higher priority messages are near the top and are a different color.

There are lots of messages because lots of things can go wrong with an aircraft. They aren't all critical "land now" messages, but may be relevant.

This already happens. I have not been trained to fly an airliner, but I believe that the priority is something like stall, gpws (flying into the ground), tcas (flying into other traffic), master warning, and master caution. These all have their own lights and sounds in the cockpit, and if I know them, so does the flight crew. Presumably the 150 messages that needed to be looked at were all "caution" messages. Too many messages, yes, but nothing that endangered the safety of the flight.

In the AF447 case, the crew was getting the stall warning. They did the exact opposite of what you are supposed to do to recover from the stall. Computers were not the problem. (The same thing happened to that Colgan Air flight a few years ago. The crew reacted to the stall warning by stalling the plane even more. The plane tried to physically force the controls to nose down, which is how you recover from a stall, but the pilots fought it. Bad UI was not the problem. Bad flying was.)

      The plane tried to physically force the
      controls to nose down,

I'm glad you mentioned that. I thought that's what a plane should do at first, and then on second consideration wondered if the psychology of panicking pilots would be to fight the controls in order to wrest the plane from going down.

It does seem like that happens. Wikipedia links to a few incidents involving the stick pusher:

http://en.wikipedia.org/wiki/Stick_pusher

Yeah, I don't know about the a/c in question; however, the Colgan crash was a result of the pilot fighting the stick pusher and winning. The stick pusher is not easy to override.

It seems counter intuitive to nose down when you're falling out of the sky, but it's how you recover.

Exactly.

If one were to apply principles of Tao, it would be to yield. Give the stick pusher nothing to push.

Reply on news.ycombinator.com