Live data from Hacker News

USS McCain collision ultimately caused by UI confusion

arstechnica.co.uk

341–350 of 369 posts

Re: USS McCain collision ultimately caused by UI confusion

#341
post #223

Earlier quoted context omitted.

There's no indication that they were fighting unknowingly. I'm not sure what you're concluding that on the basis of. >Note that when the incorrect input was finally identified by someone other than Bonin, it was corrected immediately, it was just far too late. So the popular mechanics article says, but it's not so clear in the report that this ever really happened.

In an earlier reply you wrote "Neither of the pilots in the cockpit ever figured it out" where "it" appears to be that they were fighting over control of the airplane. I realize that this is somewhat unfair, in that your earlier statements are not part of the official report, but what indication would you expect to see that they were fighting unknowingly? There will not necessarily be evidence for it on the voice rec…

>"it" appears to be that they were fighting over control of the airplane.

"it" was meant to be that the plane was stalled.

(My fault for ambiguous phrasing.)

Re: USS McCain collision ultimately caused by UI confusion

#342
post #223

Earlier quoted context omitted.

There's no indication that they were fighting unknowingly. I'm not sure what you're concluding that on the basis of. >Note that when the incorrect input was finally identified by someone other than Bonin, it was corrected immediately, it was just far too late. So the popular mechanics article says, but it's not so clear in the report that this ever really happened.

Whether or not they knew they were fighting is not quite the relevant bit. What's relevant is knowing what the other guy's inputs are. Given that the other two pilots were quite surprised once Bonin finally said that he had been holding the stick back the entire time, they clearly were not aware of this. You say it's not so clear that this ever really happened, but it's pretty clear to me from the official transcript…

But look at what Robert says before the captain enters: "climb climb climb". He still didn't have a clue that the plane was stalled, even though this could easily have been figured out from the absolutely crazy combination of attitude, throttle setting, and rate of descent. It's the captain who's surprised by the stick being held back, not Robert. In fact, earlier portions of the trascript suggest that Robert was keeping track, more or less, of what the pilot was doing.

The captain entered when, according to the report, the plane was at about ~30,000 feet with a 40 degree angle of attack. The report states that "up until the end of the flight, no valid angle of attack value was less than 35°". It seems, then, that even once everyone was aware of what the PF was doing, a correct stall recovery procedure was still not initiated. Or perhaps the stall was already unrecoverable -- I don't know if airliners are designed to recover from such extreme configurations.

So, could linked sticks conceivably have helped before the captain entered? Probably not, because there is no evidence that Robert would have recognized that the stick inputs were inapporpriate, given that he was focusing on the ECAM warnings and appeared unable to grasp the implications of the readings from his primary flight instruments. Could linked sticks have helped after the captain entered? At that point, it was just a question of whether either pilot would take control and push the nose down. There's no way of designing the stick system to make sure that most sensible pilot ends up getting control.

Re: USS McCain collision ultimately caused by UI confusion

#343
post #77
post #73

There was a ferry accident involving a similar transfer of control problem in New York harbor.[1] Ferries have a lot of maneuvering modes and directional thrusters, because they do so many dockings, and so they have a more complex control problem. The pilot put the system into a backup dumb mode while in cruise, then changed stations to where he could best see the dock while still in the wrong mode. Rammed the dock a…

In the steam days, it was a major operation to adjust the output of an engine. Valve linkages had immediate effect on the output, but you also had to adjust the boiler heat input to keep the temperature within limits. Far enough back, there were men shoveling coal into the boilers who had to be told to slow down or speed up. Do you think it's mainly bureaucratic inertia that keeps it separate? Or is there something m…

> Or is there something more complicated about controlling engine power than I imagine?

Large marine diesels such as used by container ships do need to follow a procedure to change out of the cruise rpm. I don't know how much that can be skipped/abbreviated in case of an impending collision, but I do know that generally it takes more than just someone on the bridge changing a control setting.

Re: USS McCain collision ultimately caused by UI confusion

#344

Earlier quoted context omitted.

The nuclear power plant is heating water to generate steam.

Which presumably drives a turbine to make electric which can run motors, charge batteries, run scrubbers, run heaters, etc., presumably. They're not direct driving the screw with steam power from the reactor heat-exchange, surely.

> They're not direct driving the screw with steam power from the reactor heat-exchange, surely.

Yes, they are, for the simple reason that it's more efficient. This is beginning to give way to a series electrical design, but that's for reasons of increased stealth and other concerns, at the cost of overall thermodynamic efficiency.

On all existing nuclear carriers steam is used for the catapults (and this is much more demanding than many people are aware of). The Ford class is developing electromagnetic catapults, which are also proving to be demanding to perfect.

Re: USS McCain collision ultimately caused by UI confusion

#345
post #340

Earlier quoted context omitted.

It was a complicated and confusing situation It's the job of the UI/UX designers to make that less likely. Like most air crashes, it took at least two things going wrong to make this one happen. Three in this case. Factor #1, a couple of morons were flying the aircraft. Factor #2, pitot tube icing. Factor #3, the aircraft was designed with certain unintuitive control features that depart from longstanding industry pr…

The report examined UX issues but didn't identify the side sticks as a significant factor. You can keep insisting that they were a factor if you like, but you haven't actually provided any evidence in support of that contention.

I think we can find common ground in agreeing that those pilots needed all the help they could get. Same with these sailors.

Re: USS McCain collision ultimately caused by UI confusion

#346

Earlier quoted context omitted.

> The big problem was that the pilot-in-command simply forgot (or did not know) how to fly the plane. The pilot flying wasn't the pilot-in-command. Half the problem was the PIC was out of the cockpit at the time and the lack of any clear command structure between the two first officers in the cockpit. You can also argue that it may have been recoverable if the PIC took over as PF when he returned to the cockpit (had…

"PIC", pilot in control , refers to the pilot actually flying the plane. Not the command or seniority structure amongst pilots. There were a Captain and two co-pilots aboard AF445. The junior co-pilot was PIC for much of the incident.

PIC is in command, not in control. In plenty of short-haul flights, the FO can be PF, but they aren't competent to be PIC.

See also " rel="nofollow">https://aviation.stackexchange.com/questions/33414/who-is-th....

As in the AF447 case, the PIC will delegate to an acting PIC while they are on their rest break, but ultimate responsibility still remains with them.

Re: USS McCain collision ultimately caused by UI confusion

#347
post #329
post #189

Earlier quoted context omitted.

While the "AP" indicator is very important, such that overlooking it, or rather missing its absence, could lead to loss of control and death, the same holds for many other of the items displayed.

> the same holds for many other of the items displayed Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.

I didn't (and wouldn't necessarily) claim the same ratio.

But clearly airspeed is critically important, attitude is, a wrong heading can kill you (eg Varig 254 [0]), a transponder that's off can kill you (eg the Embraer/GOL accident [1]), wrong altitude can clearly kill you, etc.

But you've got a point, it's a pretty small indicator for a pretty crucial function. However, making everything else monochrome doesn't strike me as a realistic or preferable alternative.

[0] https://en.wikipedia.org/wiki/Varig_Flight_254

[1] https://en.wikipedia.org/wiki/Gol_Transportes_Aéreos_Flight_...

Re: USS McCain collision ultimately caused by UI confusion

#348
post #300

Earlier quoted context omitted.

I thought most of self-driving car complexity comes from guessing the route and stop timings, not from following them?

I'm honestly confused by this comment. If I'm reading it correctly, you have those two backwards. Computers have been able to figure out routes since the mid-90s (see MapQuest, Google Maps, Waze, etc). It's exactly the "following" that is the responsibility of self-driving cars.

By routes I mean dynamic physically safe corridors (hard part of self-driving), not just graph walking. By following I mean a bunch of purely mechanical reactions to maintain planned coordinates in each moment. Many cars can autopark by measuring distances around (no “vision”), this is example of “following”.

Re: USS McCain collision ultimately caused by UI confusion

#349
post #73

There was a ferry accident involving a similar transfer of control problem in New York harbor.[1] Ferries have a lot of maneuvering modes and directional thrusters, because they do so many dockings, and so they have a more complex control problem. The pilot put the system into a backup dumb mode while in cruise, then changed stations to where he could best see the dock while still in the wrong mode. Rammed the dock a…

(An amusing note on ferry control. In San Francisco, at the Hyde Street Pier, there is a large steam powered car ferry boat, the Eureka, from 1890. That boat is powered by a double-acting one-cylinder engine driving both side paddlewheels. It's reversible, with some difficulty. It cannot get itself started at top dead center or bottom dead center. So there's a giant pry bar, about eight feet long, which can be used to get it started. You can see this hanging on a bulkhead near the engine.

Think about operating this turkey. This car ferry docks nose into the dock, not parallel to it. You're coming into the dock, and have to stop and reverse the engine to slow. If the stopping and reversing operation results in the engine stopped at dead center, there's no power until the crew frantically gets the pry bar and levers the engine into a position where a power stroke is possible. Screw up and you crash into the dock. It's a ferry boat, so it docks a dozen times a day.

Now that's a control problem.

The Eureka is the last surviving example of this design. Other paddlewheel ferries were built, but usually with multiple engines or multiple cylinders.)

Re: USS McCain collision ultimately caused by UI confusion

#350
post #347
post #329

Earlier quoted context omitted.

> the same holds for many other of the items displayed Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.

I didn't (and wouldn't necessarily) claim the same ratio. But clearly airspeed is critically important, attitude is, a wrong heading can kill you (eg Varig 254 [0]), a transponder that's off can kill you (eg the Embraer/GOL accident [1]), wrong altitude can clearly kill you, etc. But you've got a point, it's a pretty small indicator for a pretty crucial function. However, making everything else monochrome doesn't str…

> airspeed is critically important, attitude is, a wrong heading can kill you

Losing track of airspeed/attitude/heading is a whole different category of error than losing track of which mode the autopilot is in.

> a transponder that's off can kill you

Not without a whole pile of other errors stacked on top of that one.

Post reply on HN