Hacker News Reader

Comment by _whiteCaps_ | Hacker News Reader

Interesting to read this, as I have some experience sailing - and that sometimes involves people changing control of the tiller/wheel. The procedure that was drilled into my head at an early stage was this:

  A: B, take the helm 
  B: I have the helm

or for tacking:

  Skipper: Prepare to tack 
  Crew: Ready to tack 
  Skipper: Helm's a lee 
  Skipper tacks, crew does their stuff

If you don't get a response at any point don't continue. Communicate.

View on HN

Yeah, I was trained to say:

P1: Take the controls

P2: I have the controls

P1: You have the controls

It’s basically syn:ack

That's standard procedure in flying as well, drilled into pilots' heads from their very first flight lesson:

  A: "You have the flight controls."
  B: "I have the flight controls."
  A: "You have the flight controls."

It’s weird I’d thought they use different terms for A’s two phrases, because it’s the same words but the first is an instruction and the second a statement! Different meanings but same words - why’d you do that in designing a protocol!

Just like TCP, it’s a stateful protocol.

TCP got it right tho:

    SYN

    SYN-ACK

    ACK

Seems like a terrible idea - what if you’re mistaken about the other person’s understanding of the current state?

I'm trying to think how this could possibly be misconstrued

What if A didn't hear B's response, and was reiterating their first instruction? B wouldn't respond because they think A is already at step 3 of the handshake, whereas A thinks they are at step 1. A thinks A has control of the plane, whereas B thinks B has control of the plane.

Won't A just repeat until he gets a response? A doesn't want control, if they think they have it, they will probably retry the whole thing, meaning the confusion is probably brief.

He might also just see that B is making inputs and assume, if they are being lax, but I assume they wouldn't.

Even if A says the same words (he probably wouldn't) it definitely wouldn't be in the same tone. B would understand that it was a repeated command and not an acknowledgement.

Commands that can only be disambiguated via tone sounds insane to me.

Imagine being in an emergency, possibly listening to someone speaking while wearing an oxygen mask, in a smoke filled cabin, with alarms going off, and asking yourself - "wait did they say 'you ^have^ the controls', or 'you _have_ the controls'".

That seems tricky. Climbing, I was always taught to make the commands unambiguous. You never say "take in the slack" because on a windy day that can sound awfully like "I need slack". Each command should be distinct.

A is supposed to watch the other person and see their hands move to the controls.

responding to sibling, in my experience it actually goes “i have controls, you have controls, i have controls”. always ending on someone saying “i have controls.” so if someone doesn’t hear a call or response, it ends with either two people on the controls (not a disaster), or the person relinquishing controls repeating his line.

> two people on the controls (not a disaster)

Err… isn’t that exactly how Air France Flight 447 crashed? Both people thought they were flying, doing opposite things, the plane cancelled out their inputs and did nothing.

I mean, TFA is about two people on the controls. So that sounds like an ambiguity to be avoided.

Then you send a letter to Byzantine and ask the Generals if they have any bright ideas?

Communication was also the main cause of the Tenerife airport disaster [0], leading to an overhaul of communication protocols.

"As a consequence of the accident, sweeping changes were made to international airline regulations and to aircraft. Aviation authorities around the world introduced requirements for standard phrases and a greater emphasis on English as a common working language."

[0] https://en.wikipedia.org/wiki/Tenerife_airport_disaster#Comm...

Yeah, in flying this is usually called three way positive exchange of controls, with A repeating that B has the controls.

There's no real reason to not have this exchange digitally/mechanically intermediated, in my estimation.

A plane doesn't need to have both controls mechanically linked, or both active at the same time. You could have a nice big toggle in the middle of the cockpit that is either 2 or 3 positions (L/R/Both). Toggling it will announce "Left/Right in control" and activate the stick shaker on the dead side and re-announce if any input is received.

Panic isn't something that you can remove by training nor train for. It needs to be factored into the design that only one set of inputs is effective at a time.

> Panic isn't something that you can remove by training nor train for.

Of course it is. It's probably 50% of training.

Panic increases the impact of mental workload and induces a kind of "tunnel thinking" similar to tunnel vision: you become fixated on one problem and one solution, without considering other parameters and options.

But panic is caused, many times, by surprise and lack of competence.

You avoid panic by becoming more familiar with specific emergency situations.

And you fight panic by learning to recognize it early, reduce mental workload, organize and follow procedures.

I find it worrying that this incident shows a lack of professionalism from the crew. When something unexpexted happened, they simply jumped on the controls at once, didn't communicate and simply blamed the plane. This is amateurish, and somehow... quite French (I am French).

> Panic isn't something that you can remove by training nor train for.

On the contrary, that's exactly what repetitive training of emergency scenarios is about.

Panic happens when you get overwhelmed with multiple bad things happening and each one requires dedicated concentration, you don't have that much attention to give so panic sets in and you do all of the tasks badly. The solution is to train repeatedly so all the reactions are muscle memory (or mental "muscle memory"), which lets you remain comfortable and in control because you've done this a hundred times before.

In SCUBA diving for example many fatal accidents are the overlap of simple problems that end up overwhelming the diver because they had not practiced it enough or recently enough.

> A plane doesn't need to have both controls mechanically linked, or both active at the same time.

If you have a switching control, mechanical or digital, it is a thing that can fail, and even if you assume it would be good before considering that, you have to consider the impact failure has on net utility, especially if a plausible failure mode renders both controls inoperable.

Inevitably you will get "Plane crashed as pilot in command attempted to control plane while toggle was in opposing position" and someone will say "okay, you should add a warning light" and then the same thing will happen and someone will say "there are too many warning lights" and so on and so forth.

Panic is absolutely something you can train for and the human factor of flight controls is a central part of the design. Accidents heavily inform this design and training and control characteristics are always on the table as a response to incidents.

Didn't that switchable controls scheme contribute to one of the us navy destroyer collisions recently?

Yes, although in that case it wasn’t a big mechanical toggle, just a software setting. And the bridge crew were not trained in how to use it safely, or to check if the controls they were using were actually operable.

A less extreme(Since change can be it's own danger) solution would be an audible pilots fighting warning system.

Maybe instead some equivalent of the stick shaker that indicates your controls are being overridden

Sometimes you have to tack now. Then you’re lucky if you hear, “tacking!”

Reply on news.ycombinator.com