47 ms·

USS McCain collision ultimately caused by UI confusion

476 points by tooba 9y ago

CamperBob2 9y ago
The Navy's investigation found that both collisions were avoidable accidents. And in the case of the USS McCain, the accident was in part caused by an error made in switching which control console on the ship's bridge had steering control So, basically this was a reprise of the AF 447 crash at sea, where lack of clear command authority combined with a maddeningly poorly-thought-out UI resulted in a serious accident with loss of life. At least they didn't have genuine malfunctioning hardware on top of everything else, the way the Air France crew did. They just thought they had a malfunction.
- foldr 9y ago
  >So, basically this was a reprise of the AF 447 crash at sea, where lack of clear command authority combined with a maddeningly poorly-thought-out UI resulted in a serious accident with loss of life. I don't want to take this off on a tangent, but this theory of the AF 447 crash keeps getting repeated online despite the fact that the accident report did not conclude that the UI was a factor. If it's got to the point where the pilots have lost track of who's flying the plane, are ignoring the (audible) "dual control" warning, and are making conflicting control inputs, the plane is probably going to crash anyway. Linking the sticks physically has potential safety downsides in addition to safety upsides (e.g. in the case where one stick gets stuck, or a incapacitated pilot holds it in a particular position). See e.g. here for further info on sidesticks and safety: https://aviation.stackexchange.com/questions/14027/sidestick-safety-concern https://aviation.stackexchange.com/questions/14027/sidestick...
  - dredmorbius 9y ago
    Hearing (one of many) alarms is one thing. Feeling the control wheel or stick fighting you is far more direct. AF 447 was absolutely a UX failure.
    - foldr 9y ago
      If you're going to go against the conclusions of the accident report, which is very thorough, you'll have to do more than just assert that the side sticks were responsible. Check it out here: https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp090601.en.pdf https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
      - dredmorbius 9y ago
        I have read it. Several times.
        foldr 9y ago
        Great, the pages and sections are numbered, so it's easy to refer to the parts of it that support your theory. Or alternatively, you can direct us to whatever conflicting sources of information you believe are more reliable than the official accident report.
        avar 9y ago
        This theory isn't citing the report itself, but independent analysis that's been done on the same data. The Wikipedia article on the topic has a whole section for these [1], and a section about this theory in particular [2]. Furthermore. The official accident report for crashes is not always considered the authoritative source for what happened. One good example is EgyptAir Flight 990 which the official report claims is a mechanical failure [3], but which is widely considered to have been pilot suicide. In that case the Egyptian investigative body was thought to be politically motivated. Similarly, it's not at all implausible that the French BEA would be reluctant to make conclusions that could result in the grounding of the entire worldwide Airbus fleet while they're retrofitted with Boeing-style controls while France is the main Airbus manufacturing partner country. 1. https://en.wikipedia.org/wiki/Air_France_Flight_447#Independent_analyses https://en.wikipedia.org/wiki/Air_France_Flight_447#Independ... 2. https://en.wikipedia.org/wiki/Air_France_Flight_447#Sidestick_control https://en.wikipedia.org/wiki/Air_France_Flight_447#Sidestic... 3. https://en.wikipedia.org/wiki/EgyptAir_Flight_990 https://en.wikipedia.org/wiki/EgyptAir_Flight_990
  - NoPiece 9y ago
    I'd call it an interpretation, not a theory. But clearly the conflicting inputs was a UI problem, and while there may be tradeoffs, a better UI could have prevented the AF 447 crash.
    - foldr 9y ago
      This really won't die. It's clear if you read the accident report (linked in another comment) that the plane was already doomed by the time that conflicting inputs were potentially a factor.
    - inferiorhuman 9y ago
      Basic airmanship could've prevented the crash too. The pilot-in-command got a stall warning and pulled back on the stick, climbing to 38,000 feet. That's not a UI issue, it's a forgetting one of the most fundamental rules of flying issue. https://aviation.stackexchange.com/questions/1418/what-happens-when-an-airplane-stalls-and-why-do-pilots-practice-it https://aviation.stackexchange.com/questions/1418/what-happe...
      - dredmorbius 9y ago
        UI issues contribute to situational complexity, stress, ambiguity, and failures to respond appropriately to circumstances. And whilst the BEA report ... rather inexplicably, frankly ... fails to mention the inputs issues, it does address all the other factors I've described here.
      - avar 9y ago
        You normally can't stall an Airbus aircraft, except in cases where the flight mode changes as it did in this situation. This was a huge part of the problem, an emergency occurred and the pilots were effectively flying an aircraft they hadn't flown before. Fully pulling back the stick is what you'd normally do in an Airbus to gain altitude. It's guaranteed not to stall the plane.
        inferiorhuman 9y ago
        > Fully pulling back the stick is what you'd normally do in an Airbus to gain altitude. It's guaranteed not to stall the plane. I'd love to see some documentation on "pull back in a stall". In fact, this is all I could find: http://www.pprune.org/tech-log/415373-new-airbus-stall-recovery-procedure.html http://www.pprune.org/tech-log/415373-new-airbus-stall-recov...
  - mikeash 9y ago
    With linked controls, the sane pilot at the controls would have immediately realized that the crazy one was fighting him, and it would have been brought to a swift end. I know a lot of pilots and I don’t recall ever hearing one express the opinion that non-linked dual controls were anything other than idiotic. I’d personally be quite wary of ever flying such a machine. (Although of course the stuff I fly uses purely mechanical controls so there’s no choice in the matter.)
    - foldr 9y ago
      The sane pilot realized this anyway. Check the accident report. (Or rather, the captain realized once he entered the cockpit. Neither of the pilots in the cockpit ever figured it out.)
      - mikeash 9y ago
        Once Bonin told them he had been holding the stick back the entire time, they immediately began a proper recovery, it was just far too late. This might have happened much, much earlier if the other pilot at the controls had been able to feel this.
        foldr 9y ago
        What is your source for this? It does not seem consistent with sections 2.1.3.4-5 of the report. In any case, the captain was not holding a stick when he returned to the cockpit, as both pilots were in their seats. So the captain could not have gotten any tactile feedback regardless of the stick design.
        mikeash 9y ago
        This transcript: http://www.popularmechanics.com/flight/a3115/what-really-happened-aboard-air-france-447-6611877/ http://www.popularmechanics.com/flight/a3115/what-really-hap... I’m not talking about the captain, I’m talking about the other pilot at the controls, Robert. He also held the stick back for some time, but he appears to have done this in the mistaken belief that the correct recovery procedure had been tried and failed.
  - zkms 9y ago
    > I don't want to take this off on a tangent, but this theory of the AF 447 crash keeps getting repeated online despite the fact that the accident report did not conclude that the UI was a factor. This is incorrect. The BEA report explicitly blames the lack of an AoA display and recommends that an AoA indicator be directly visible to the pilots. The aircraft already has sensors to measure AoA to feed the flight computers; asking for a direct readout of AoA is nothing beyond a UI change recommendation (and not fundamental aircraft re-engineering): > It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required. The AoA invalidation logic ("mark AoA measurements as invalid if airspeed is less than 60kt") made the stall warning turn off as the stall became even deeper, making diagnosis of the stall more complicated. Worse, the BEA report states that the appropriate (nose down) control input led to the stall warning reactivating (since such an input would increase airspeed above the 60kt threshold -- inherent to a proper stall recovery), leading the pilot flying to reverse their control inputs and return the aircraft into a worse stall: > A few seconds after the transition to alternate law, the stall warning sounded briefly, even though the PF’s inputs should have made this warning sound for several seconds. The reason for this is the drop in the measured airspeeds, some of which fell temporarily to below 60 kt, while the angle of attack reached 40°. Furthermore, the drop in measured airspeeds to values of less than 60 kt during the stall caused the repeated activation and deactivation of the warning which may have made it considerably more difficult for the Captain to effectively analyse the situation on his return to the cockpit. > Several nose-down inputs caused a drop in the pitch attitude and the angle of attack, whose values then became valid, such that a clear nose-down input resulted in the triggering of the stall warning. It appears that the PF reacted, on at least two occasions, with a nose-up input, whose consequences were an increase in angle of attack, a drop in measured speed and consequently stopping the stall warning. Lacking an AoA readout, the pilots would have had to reverse-engineer AoA from their extant instrument displays, the warnings they were presented, the "feel" of the airplane (is it buffeting? how is it responding to various control inputs?, etc), and past control inputs. Every one of those sources were degraded per the BEA report: they didn't trust (to the point of changing the selected inertial data source even if there was no indicated issue with inertial data) their instruments because of the airspeed inconsistency, the stall warning would reactivate every time they made the correct control input (the exact opposite behaviour of a stall warning simply based on an AoA threshold), and buffet might have been interpreted as overspeed buffet. Expecting pilots to reverse-engineer the aircraft's warnings to guesstimate AoA -- a value that the machinery simultaneously measures and hides from the pilots -- is fatally bad UI (BEA uses the fancier term "ergonomics"), especially in cases when the flight computers deal with air data inconsistencies by forking over more authority to the pilots.
tlb 9y ago
Amazing that someone would design in multiple steering wheels, only one of which is active, and no big indicator to make it super-obvious which one it is. Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.
- Jtsummers 9y ago
  Check out the recent O'Reilly book Tragic Design for more situations exactly like this. Poor UI design is remarkably common, even on controls that are essential for safe operations. http://www.tragicdesign.com http://www.tragicdesign.com
  - csours 9y ago
    Also the classic Field Guide to Understanding Human Error. Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265/ref=mt_paperback?_encoding=UTF8&me= https://www.amazon.com/Field-Guide-Understanding-Human-Error... Older PDF (paperback is well worth it, in my opinion): http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human...
- deleted 9y ago
  [deleted]
- oasisbob 9y ago
  Having differential engine control isn't too surprising - it's just another way to maintain a course in addition to the rudder. Jetliners have gangable throttle controls for their engines, albeit with what is probably a much better interface.
  - cyberferret 9y ago
    Airliners usually have a hardware clip to 'gangload' all throttles together, and the 'interface' of having two or more separate levers next to each other makes it obvious if you missed one while moving them, or notice that the clip is flipped so the levers now work independently instead of all as one. Then again, in high stress situations even totally obvious signs like this can be missed, as evidenced by the Qantas 747 crew on the famous runway overrun in Thailand some years ago. I believe in that case, a large contributing factor was when the captain went to pull the levers back over the rear detents for reverse thrust after landing on the wet runway, he only grabbed three of the levers, and left one engine running at just over idle speed.
tomohawk 9y ago
Sometimes having too much money is worse than not having enough. With a tighter budget, you have to wonder if such an extravagantly over functional interface would be created.
- theyregreat 9y ago
  I’ve seen hundreds of millions (!!) wasted at a university on a program of software projects that failed miserably. Having too much money allows for unproven, complicated or arbitrarily selected solutions and more bureaucracy that introduces Tragedy of the Commons mediocrity and diffusion of responsbility to address higher-level risks.
pbh101 9y ago
UI flaws have hit the Navy before, with even worse consequences [1]. [1] https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air_Flight_655 https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...
- dragonwriter 9y ago
  Nothing I see in that article (or anything else I've seen about the incident) attributes it to a UI issue. Not all errors made by users are the fault of the UI.
  - theyregreat 9y ago
    More than binary nuance is needed. The ship that crashed is a system of humans plus machines, the UI being just the API between the two. Forensic incident analysis of ship design, UI, human factors, etc. is needed.
  - pbh101 9y ago
    You're right: nothing in that article mentions the UI. I learned about the incident in my computer ethics class in college (along with Therac-25, etc). Quickly-skimming, it looks like Cracked has a decent writeup of the UI issue specifically [1]. [1] http://www.cracked.com/article_19776_6-disasters-caused-by-poorly-designed-user-interfaces.html http://www.cracked.com/article_19776_6-disasters-caused-by-p...
    - LeifCarrotson 9y ago
      Because that website is cancer if you don't have an ad-blocker, I'll quote the relevant text: > The screen showed the operator what objects were detected on radar, and if he clicked on an object, it would track it. But if the operator wanted to get more information about the object (in this case, by listening in on its radio signals) to find out what it actually was, he had to move a separate cursor and click on the object again. > It's clumsy and unintuitive, and it made it really easy to forget which thing they were highlighting at any given moment -- the operator can be tracking one object and have it display the information for a completely different one because he forgot to move the other cursor. It's the kind of user interface that wouldn't make it out of the testing phase of a cheap browser game. And it cost the passengers of the plane their lives. > That's because the operator in the USS Vincennes thought he was listening to the incoming aircraft (the Airbus full of innocent people), because that's the thing he selected, when he was actually receiving signals from a parked F-14 several miles away, because that's where his other cursor was. > Granted, the transmissions alone wouldn't be reason enough to shoot down a plane: They'd also have to think that it was moving like an enemy aircraft. Unfortunately, the stupid system made that mistake pretty easy, too. Instead of telling the operators at the Vincennes if the approaching plane was ascending or descending, the system just showed them the present altitude on a smaller monitor. The operator had to write down or memorize the altitude, wait a few seconds, then ask again and mentally compare the two results to see if the aircraft was going up or going down. > Because of this, a calculation error led an operator to report that the Airbus was descending toward the USS Vincennes, like a combat aircraft would, when it was probably getting the hell away from them as fast as possible.
jordanb 9y ago
The real cause of the collision was poor seamanship and failure to follow the COLREGS on the part of the bridge crew of the destroyer. Most specifically they were seriously in violation of Rule 6: the Safe Speed Rule http://navruleshandbook.com/Rule6.html http://navruleshandbook.com/Rule6.html Every vessel shall at all times proceed at a safe speed so that she can take proper and effective action to avoid collision and be stopped within a distance appropriate to the prevailing circumstances and conditions. The USS McCain was traveling at over 20 knots at the time of the collision, through a very crowded area at the entrance of a traffic separation scheme. If they hadn't been traveling at this obviously excessive speed they would have had the time to think, and to work through little UI issues like the one described here.
- csours 9y ago
  The path to a disaster has been compared to a tunnel [0]. You can escape from the tunnel at many points, but you may not realize it. Trying to find the 'real cause' is a fool's errand, because there are many places and ways to avoid the outcome. I do take your meaning, reducing speed and following well established rules would have almost certainly have saved them. 0. PDF: http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human... Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648257 https://www.amazon.com/Field-Guide-Understanding-Human-Error...
  - JshWright 9y ago
    I've never heard the tunnel analogy. Seems odd, since tunnels generally only have one entrance and one exit... In a lot of fields where the stakes are high and mistakes are costly (aviation and emergency services are the two I'm most familiar with) the analogy used is a chain. Break any link in the chain and you prevent the event. https://www.aopa.org/asf/publications/inst_reports2.cfm?article=4401 https://www.aopa.org/asf/publications/inst_reports2.cfm?arti...
    - csours 9y ago
      It's the perception tunnel. There are many branches, but only one route is followed. In hindsight, you can see all the branches and call out everything that went wrong.
Zak 9y ago
Aside from the lack of clarity about which station has control over what, which should be made really obvious, with additional warnings when someone sets a control input on an inactive station, this seems bizarre to me: While the Ship's Control Console has a wheel for manual steering, both steering and throttle can be controlled with trackballs, with the adjustments showing up on the screens for each station. I've never been on the bridge of a ship, but I've operated a lot of vehicles including boats, ATVs, snowmobiles, cars, bulldozers and once, an army Blackhawk helicopter simulator. These very disparate vehicles had one thing in common: there's a relationship between the position of any movement-related control and the movement commanded, and there are stops at the limits of control input. Trackballs do not have either property, and I'm having trouble thinking of advantages they might offer in this application.
- csours 9y ago
  None of those operate on the open ocean. There's a wheel there for steering; from the article it sounds like the trackball is used with a menu system of some type, not directly to set the steering angle.
- mjlee 9y ago
  I have been on the bridge of a ship, as an Officer of the Watch in the Royal Navy. Ships have both open loop and closed loop control systems. Closed loop is the normal mode of operation, but there are open loop systems to fall back to. The procedure tends to involve sending someone down to the rudder to communicate back the actual angle of the rudder. The difference between a warship and a most other vehicles is that you can't simply stop a warship and get out. You need to be able to fight even if you've lost the feedback loop from the bridge to the rudder. For the comparison to the blackhawk, in a ship you can at least do something about mechanical failures in control systems.
- noobiemcfoob 9y ago
  You use trackballs to input relative movement commands. The position of the ball doesn't need to relate to the position of the cursor. It's like a mouse if you picked it up and replaced it after every stroke. They have a couple nice properties in that they can be fixed in place and offer more freedom of movement to a joystick.
bluetwo 9y ago
I'm sure we've all read "The Inmates are Running the Asylum" by Alan Cooper.
lordnacho 9y ago
Even specialised UIs need to be intuitive. You should need to know the domain (navigation), but not the specifics of everything the UI can show. The problem with this kind of thing is people are sent on a course, which gives everyone a false sense of control and understanding. Clearly the crew didn't understand it, leading to a panic and wasted time.
greedo 9y ago
The headline is inaccurate. While the design of the bridge leaves a lot to be desired (in the eyes of laymen), the real issue is an incredible dereliction of duty by 7th Fleet and the USN in general in terms of training and staffing.
rdl 9y ago
Everyone in the chain of command in 7th fleet (from ADM Smith on down through the captains and those standing watch) should have been separated and potentially prosecuted for negligence. UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals, and obviously many systems failed for this to happen. When the military runs well, it runs on accountability -- there's been a serious shortage of that, especially above O-6, for a long time. "Retiring" without losing rank doesn't cut it.
- kevinburke 9y ago
  > UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals There are plenty of examples of "UI confusion" causing professionals to make mistakes in all sorts of industries. I'd suggest taking a look at the book "Behind Human Error," for example. http://www.usabilityfirst.com/glossary/mode-error/index.html http://www.usabilityfirst.com/glossary/mode-error/index.html https://www.amazon.com/Behind-Human-Error-David-Woods/dp/0754678342/ref=sr_1_1/146-0878510-2747236?ie=UTF8&qid=1509666426&sr=8-1&keywords=behind+human+error https://www.amazon.com/Behind-Human-Error-David-Woods/dp/075...
- tormeh 9y ago
  From what I hear the Navy has been very diligent about accountability. There are problems you can't really hard-ass yourself out of.
  - jessaustin 9y ago
    Multiple crewman have died from multiple preventable errors in multiple incidents. I haven't heard about any firing squads for COs? Normally we Americans are so enthusiastic about severe penalties? Watch-keeping and safe navigation are boring, so officers need extra incentive to pay attention to them!
    - azernik 9y ago
      "Preventable" doesn't mean "preventable by harsher discipline".
trhway 9y ago
>At this point, everyone on the bridge thought there had been a loss of steering. In the commotion that ensued, the commanding officer and bridge crew lost track of what was going on around them. now add to that picture (according to your historical preferences) a salvo of the 10 inch battery from an enemy battlecruiser 10 miles away or 2 Moskits rushing at 2.5x Mach ... blaming UI is just so childish and lame. Like our Sun executives blaming market conditions back then 10 years ago when everybody else had already been enjoying the boom for a few years.
cocoablazing 9y ago
A key occurrence during this mishap: 0127 The Officer of the Deck ordered course to the right to course 240T, but rescinded the order within a minute. Instead, the Officer of the Deck ordered an increase to full speed and a rapid turn to the left (port). These orders were not carried out. 0129 The Bosun Mate of the Watch, a more senior supervisor on the bridge, took over the helm and executed the orders. I've witnessed multiple similar situations on a warship (imminent loss of extremely critical systems), and had to forcibly push the watchstanders out of the way to do their job for them. Many people are going to freeze when the SHTF, and there may be no prior indication. Major attaboy to the BMOW who saved many of his shipmates. Given the incident angle of collision, many more would have died from a perpendicular collision.
- ineedasername 9y ago
  Yep, but that freeze is limited with more training, and mixed watches when teh newbs have to be rotated in for the real thing so the "hold my beer" guys aren't outnumbered 10 to 1 by the frozen folks.
  - cocoablazing 9y ago
    I can't believe these watchstanders had the LOK they should have had on the steering system, or every one involved in ship control would have been able to immediately identify the problem and realign the steering system, other than bmow. I don't think the senior watch team had their st either, or the orders to prepare to take manual control of the steering and propulsion system aft would have immediately been out. Also it makes little sense that lookouts who calculated cpa at collision weren't raising the alarm. These guys who I had to do their job for them: I got them removed, and tried to get them off our boat. They were fine people but they were a danger to us.
    - LeifCarrotson 9y ago
      There's a lot of acronyms in there. LOK = Level of knowledge? BMOW = Boatswain's Mate Of the Watch ST = ? Not "Subject to" or "Such that" as I've seen. CPA = Collision Prevention Assist in automotive systems, but maybe not here?
Animats 9y ago
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 at 12 knots. 79 injured, 4 seriously. This is bad design. All the controls that can steer the ship should be tied together and move together. How to do that was figured out decades ago. The Navy still has this thing where they hate to give control of both speed and steering to the same person. The helmsman and engine room take orders from the officer that has the conn. But that officer doesn't actually operate the controls. Some enlisted sailors do. This dates from the age of sail and steam. Merchant shipping gave this up decades ago. Back in the 1950s, the U.S. Navy built the USS Albacore. This was an experimental submarine to test out the teardrop-hull concept. It wasn't nuclear; it was just a test vehicle to see how such a hull form handled. It was expected to be more maneuverable than previous designs, so it was set up with aircraft-like controls. One person sat in the pilot's seat, strapped in facing forward, looking at aircraft-type instruments, and controlled all the maneuvering controls. It was a very agile craft. The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers. To this day, the Navy sets up nuclear submarines so that different people steer, control power, and control buoyancy. (The British in WWII tried to control aircraft with multiple people. As bombers got bigger, they wanted to put a senior officer in charge, but younger people were better pilots. So they had an "aircraft commander" back-seat driving, as well as a pilot handling the controls. This did not work out at all and was rapidly dropped.) [1] https://www.ntsb.gov/news/press-releases/Pages/PR20140408c.aspx https://www.ntsb.gov/news/press-releases/Pages/PR20140408c.a...
- tlb 9y ago
  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 more complicated about controlling engine power than I imagine?
ilaksh 9y ago
Shouldn't it have some kind of automated collision avoidance that would have at least given an optional course correction?
- jzwinck 9y ago
  I sail regularly in the waters where this occurred. They are extremely crowded with large ships, small fishing boats, and more. The Navy ship was moving at 12 knots which is relatively fast in the local context. Not only does this open them to a violation of the Safe Speed Rule discussed in another comment, it means that any automated course correction would have a decent chance of putting them on a new collision course with a different boat. Perhaps even a small one their radar will not see. The solution is to slow down. This is well known in nautical practice: if things are not going your way, slow down. If you are not sure what to do, slow down. If you are unable to control your vessel, slow down.
hinkley 9y ago
> The report found that the McCain did not have the right type of watch on duty for navigation in congested waters and that watchstanders' training was insufficient. But there was never a warning signal from the Alnic of impending collision or a change of course by the merchant in an effort to avoid the collision. "Despite their close proximity, neither JOHN S MCCAIN nor ALNIC sounded the five short blasts of whistle required by the International Rules of the Nautical Road for warning one another of danger," investigators found, "and neither attempted to make contact through Bridge to Bridge communications." What a comedy of errors.
Johnny555 9y ago
A billion dollar ship seems like the kind of place it's worth having real physical controls and indicator lights for functions like this. I get why auto makers love touchscreens, because buttons, knobs and lights are comparatively more expensive than adding another menu entry to the touchscreen, but that's not the case in an expensive ship.
mikerathbun 9y ago
I would be interested to see how much liberty the contractors who develop these systems are given. Are they given a rigid spec by the Navy and expected to implement it exactly or are they given a general proposal which allows them to iterate on UI from lessons learned from previous accidents caused by confusion.
ineedasername 9y ago
Nope; No, just not at all: UI Confusion is never "ultimately" the cause for accidentally killing people through poor operation of a $2 billion piece of military equipment. A UI may suck, many do, in or out of the military. So, training. and then more training. I don't have a high stakes job, but if I allowed code-completion to drop tables, commit the change, delete the backups, and then burn down the building... well, that's not on the UI, that's on me. So unless we're talking MS Word Clippy-- and I think the article would have mentioned that-- UI can't take the fall on this. Besides: It began with the Helmsman sending all control instead of just throttle control to the Lee Helm station. That mistake isn't explained as a UI issue, it's glossed over, but everything came from that initial screw-up. Sure, afterwards there was confusion, but even then, "OMG WE LOST ALL STEERING INCREMENT THE IDIOTIC PANIC OPTION VARIABLES!" isn't really an acceptable response. How about, calmly, "Helmsman double check that control assignment if you please <insert navy jargon cliche />"
- josephwegner 9y ago
  Interestingly, this is the opposite of the direction much of the tech industry has been moving with post-mortems. - http://firstround.com/review/this-is-how-effective-leaders-move-beyond-blame/ http://firstround.com/review/this-is-how-effective-leaders-m... - http://code.hootsuite.com/blameless-post-mortems/ http://code.hootsuite.com/blameless-post-mortems/ - https://codeascraft.com/2012/05/22/blameless-postmortems/ https://codeascraft.com/2012/05/22/blameless-postmortems/
robbrown451 9y ago
There were multiple causes. The article makes this clear, but the title to the HN post implies there was only one main cause. The UI should be fixed. There should be a process for helmsmen to report problem UIs. And of course training. But you can't really train for situations that you don't fully understand, and the people designing the UI are really the ones who need to put the hard work into understanding all these possibilities.
thunderplot 9y ago
Militaries are good at making horrible UI. :-) I used to work at early warning radar, that should notify our tops about incoming ICBMs. When there's a target, classified as "suspicious" or "something that's going to fall onto {our, neighbour} territory", the following happens: - very loud sine 1200Hz tone starts sounding - the only output device, "fast-printing device", starts dumping hexdumps of internal structures to long 10cm wide paper (like toilet paper). - the whole chain of command start yelling to each other (downwards), demanding data and info about the target. So as the last person in that food chain, you're in the middle of panic, 1200Hz are drilling into your brain, damned thing prints hexdumps, and you need to apply binary shifts and ANDs, convert from floating point hex to decimals and pray that there's enough paper in damned FPD. I could never imagine worse UI, it's strange that we didn't start WW3 in those conditions.
- wmeredith 9y ago
  "Militaries are good at making horrible UI." This is extremely applicable: https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa9 https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa... Disclaimer: it's an article I wrote about why government software contractors suck at their jobs.
lisper 9y ago
It's not just boats that have safety-critical UI design problems. The avionics in airplanes are becoming so complicated that managing the avionics is almost more difficult than flying the plane. I'm a private pilot who has been flying a Cirrus SR22 for twelve years. In that time it has gone through two major glass cockpit avionics revisions. In the first revision, called the Avidyne, the autopilot was either on or off. In the current revision, called the G-1000, the autopilot can operate in two modes: AP mode, where the autopilot is actually flying the plane, and FD or flight-director mode, where the autopilot does all of the calculations to figure out where the plane should be flying and displays a target on the primary flight display, but the actual control of the plane is still in the hands of the pilot. If the plane is stable, it is very easy to get fooled into thinking the autopilot is flying the plane when in fact it is not. There are only two visual indicators that tell you if the autopilot is actually flying the plane: a small green LED on the autopilot console, which is down near your right knee, and another small annunciator on the primary flight display. It looks like this: http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a36ad6e-3ab6-a48c-3f67-d5318ba1f66b/source/552x414bb.jpg http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a3... The autopilot indicator is indicating AP mode in that image. See if you can spot it. It has happened to me more than once that I thought I had the autopilot engaged when in fact I had only turned on the flight director. I predict that one of these days someone will die because they made this mistake in instrument conditions.
- rangibaby 9y ago
  Is there a purpose to the display being so colorful? If AP were the only green thing and the others were monochrome it would stand out more.
  - lisper 9y ago
    Some of the colors do have a rationale. The blue and brown background are actually the attitude indicator display. Blue is sky. Brown is ground. There is now an option available that renders the terrain you're over so you can "see" outside via the PFD even in clouds, e.g.: http://glasspilot.com/2008/08/is-synthetic-vision-a-game-changer/ http://glasspilot.com/2008/08/is-synthetic-vision-a-game-cha... But the other colors I think are just "because they can." There are a lot of IMHO stupid aspects of the G1000 UI design. (To be fair, the G1000 has to many features that designing a good UI for it is a real challenge.)
tacotornado 9y ago
There was a big ferry accident involving a similar transfer of control problem in the New York harbor.
jrochkind1 9y ago
not surprised
kepano 9y ago
Reminds me of the book "Set Phasers on Stun" which details stories of poor designs that caused deadly disasters. An essential read for anyone designing these types of systems.
exabrial 9y ago
My friend's boat is a dual engine diesel, 78ft, two stories. It has a controller where you set a course and a computer controls the throttles and rudder. On the very choppy lake of the Ozarks, this is a handy feature. You're telling me a million dollar guided missle destroyer can't do this?
- jessaustin 9y ago
  Everybody come to the beautiful Lake of the Ozarks, where you too can be menaced on narrow inland waterways by giant overpowered wave-making monstrosities like that of 'exabrial's friend! At least you won't have to worry about uncontrolled USN vessels...
  - exabrial 9y ago
    HAHA :D I took a 5mi trip up the channel on jet skis on memorial day weekend. Holy smokes, I thought I was going to die. The channel chop is no joke!
trisimix 9y ago
Pretty sure all collisions are avoidable.
ericb 9y ago
On a related note, it occurs to me that UI/UX for car navigation systems and cell phones is an actual life-and-death matter. Maybe we should treat it differently.
Camillo 9y ago
The headline is clickbait, and directly contradicts the report's conclusions. The article says as much ("While the report lays the blame on training"), but by that point you've already clicked. But look at that bridge schematic. There were TEN PEOPLE in that room, and they couldn't keep an eye on the radar, raise a collision alert, radio the other ship, etc. They just completely lost it. The John McCain was put in a state of complete confusion by a simple control error they themselves made, while cruising along a commercial shipping lane, at peace. How would they have handled an enemy attack?
newsreader2 9y ago
Are you able to leave some of the steam in?
hliyan 9y ago
Actual naval experts in HN notwithstanding, I think it's worth remembering that a little knowledge, at times, can be a dangerous thing. This is true of many topics on HN that are only obliquely related to software engineering. Silicon Valley has earned a great deal of confidence by disrupting other industries by out-thinking their experts, but perhaps we should temper that confidence a little, least it becomes hubris... Bottom line, if we're going to dismiss experts, I think we should be armed with a little more than the knowledge we garnered from an internet article.
deleted 9y ago
[deleted]
_pmf_ 9y ago
It's not necessarily the UI that must have been confusing, it might have been that these modes of operation are inherently confusing.
jonsen 9y ago
"His theoretical insights are grounded in an extended analysis of ship navigation—its computational basis, its historical roots, its social organization, and the details of its implementation in actual practice aboard large ships.": https://mitpress.mit.edu/books/cognition-wild https://mitpress.mit.edu/books/cognition-wild
deleted 9y ago
[deleted]
matt_the_bass 9y ago
Good maritime discussion on gcaptain http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-was-the-navees-fault-twice/46496/2 http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-wa...
matt_the_bass 9y ago
I've been on the bridge of many commercial ships including giant yachts and cruise ships during trafficked maneuvering. They never have that many personnel involved on the bridge. Maybe that is part of it?
PythonicAlpha 9y ago
Alan Cooper wrote some books about User Interface design and this really reminds me of his books and talks. When you cross a car with a computer, what does happen? When you cross a ship with a computer, what does happen? Ship steering and management was developed in hundreds of years, than comes the computer and changes everything in some decades ... no wonder, that some friction happens. I am not anti computer, because I am a developer myself, but you must be very carefully in designing these things. I even see it in our modern cars and cell phones ...
wruza 9y ago
Maybe I’m too late or too simplistic, but why do ships and aircrafts have so complex control systems in normal functioning modes at all? Why can’t layman ship commander like me just tell the system to be “there” in specific time via hand-drawn or standard route? If my engines malfunctioning, or steering lost it is one thing, but if everything is okay, can’t a simple swipe-to-sail iphone app just coordinate all ship controls to “be there in 3m08s” in most effective way according to the safety rules? Now it seems like all the precise counters and sensors are passed to slow, biased, narrow-focused and error-prone device that is my mind to get goal-related feedback. And this device happens to be proud of being it. As a programmer, I just can’t understand it. Do commanders quickly solve unsolvable differential equations in realtime or what?
- dragonwriter 9y ago
  > Maybe I’m too late or too simplistic, but why do ships and aircrafts have so complex control systems in normal functioning modes at all? In the case of warships, specifically, its because normal operations are reduced-complexity training opportunities.
- Zeebrommer 9y ago
  Although I think ship control can definitely be made more user-friendly, what you are asking for is of similar complexity as a self-driving car.
  - freeone3000 9y ago
    We have those! Or at least, we have close enough to one of those for a secondary autopilot system.
  - wruza 9y ago
    I thought most of self-driving car complexity comes from guessing the route and stop timings, not from following them?
    - 0xffff2 9y ago
      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.
polynomial 9y ago
Alan Cooper observes in his book Inmates are Running the Asylum than the majority of non-terrorist related airline disasters are caused by bad UI. Not instrumentation as such, but the modern version of it which is the "interface." One example he cites is a pilot selecting a destination beacon using a "simple" drop down menu. 2 possible options, similar in name and adjacent on the alphabetized list are deadly in difference. One is the correct orientation, the other takes the plane directly into the side of a mountain. Given the state of confusion that is modern UI design, this revelation is not too surprising.

476 points by tooba 9y ago

The Navy's investigation found that both collisions were avoidable accidents. And in the case of the USS McCain, the accident was in part caused by an error made in switching which control console on the ship's bridge had steering control So, basically this was a reprise of the AF 447 crash at sea, where lack of clear command authority combined with a maddeningly poorly-thought-out UI resulted in a serious accident with loss of life. At least they didn't have genuine malfunctioning hardware on top of everything else, the way the Air France crew did. They just thought they had a malfunction.

foldr 9y ago
>So, basically this was a reprise of the AF 447 crash at sea, where lack of clear command authority combined with a maddeningly poorly-thought-out UI resulted in a serious accident with loss of life. I don't want to take this off on a tangent, but this theory of the AF 447 crash keeps getting repeated online despite the fact that the accident report did not conclude that the UI was a factor. If it's got to the point where the pilots have lost track of who's flying the plane, are ignoring the (audible) "dual control" warning, and are making conflicting control inputs, the plane is probably going to crash anyway. Linking the sticks physically has potential safety downsides in addition to safety upsides (e.g. in the case where one stick gets stuck, or a incapacitated pilot holds it in a particular position). See e.g. here for further info on sidesticks and safety: https://aviation.stackexchange.com/questions/14027/sidestick-safety-concern https://aviation.stackexchange.com/questions/14027/sidestick...
- dredmorbius 9y ago
  Hearing (one of many) alarms is one thing. Feeling the control wheel or stick fighting you is far more direct. AF 447 was absolutely a UX failure.
  - foldr 9y ago
    If you're going to go against the conclusions of the accident report, which is very thorough, you'll have to do more than just assert that the side sticks were responsible. Check it out here: https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp090601.en.pdf https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
    - dredmorbius 9y ago
      I have read it. Several times.
      - foldr 9y ago
        Great, the pages and sections are numbered, so it's easy to refer to the parts of it that support your theory. Or alternatively, you can direct us to whatever conflicting sources of information you believe are more reliable than the official accident report.
        avar 9y ago
        This theory isn't citing the report itself, but independent analysis that's been done on the same data. The Wikipedia article on the topic has a whole section for these [1], and a section about this theory in particular [2]. Furthermore. The official accident report for crashes is not always considered the authoritative source for what happened. One good example is EgyptAir Flight 990 which the official report claims is a mechanical failure [3], but which is widely considered to have been pilot suicide. In that case the Egyptian investigative body was thought to be politically motivated. Similarly, it's not at all implausible that the French BEA would be reluctant to make conclusions that could result in the grounding of the entire worldwide Airbus fleet while they're retrofitted with Boeing-style controls while France is the main Airbus manufacturing partner country. 1. https://en.wikipedia.org/wiki/Air_France_Flight_447#Independent_analyses https://en.wikipedia.org/wiki/Air_France_Flight_447#Independ... 2. https://en.wikipedia.org/wiki/Air_France_Flight_447#Sidestick_control https://en.wikipedia.org/wiki/Air_France_Flight_447#Sidestic... 3. https://en.wikipedia.org/wiki/EgyptAir_Flight_990 https://en.wikipedia.org/wiki/EgyptAir_Flight_990
- NoPiece 9y ago
  I'd call it an interpretation, not a theory. But clearly the conflicting inputs was a UI problem, and while there may be tradeoffs, a better UI could have prevented the AF 447 crash.
  - foldr 9y ago
    This really won't die. It's clear if you read the accident report (linked in another comment) that the plane was already doomed by the time that conflicting inputs were potentially a factor.
  - inferiorhuman 9y ago
    Basic airmanship could've prevented the crash too. The pilot-in-command got a stall warning and pulled back on the stick, climbing to 38,000 feet. That's not a UI issue, it's a forgetting one of the most fundamental rules of flying issue. https://aviation.stackexchange.com/questions/1418/what-happens-when-an-airplane-stalls-and-why-do-pilots-practice-it https://aviation.stackexchange.com/questions/1418/what-happe...
    - dredmorbius 9y ago
      UI issues contribute to situational complexity, stress, ambiguity, and failures to respond appropriately to circumstances. And whilst the BEA report ... rather inexplicably, frankly ... fails to mention the inputs issues, it does address all the other factors I've described here.
    - avar 9y ago
      You normally can't stall an Airbus aircraft, except in cases where the flight mode changes as it did in this situation. This was a huge part of the problem, an emergency occurred and the pilots were effectively flying an aircraft they hadn't flown before. Fully pulling back the stick is what you'd normally do in an Airbus to gain altitude. It's guaranteed not to stall the plane.
      - inferiorhuman 9y ago
        > Fully pulling back the stick is what you'd normally do in an Airbus to gain altitude. It's guaranteed not to stall the plane. I'd love to see some documentation on "pull back in a stall". In fact, this is all I could find: http://www.pprune.org/tech-log/415373-new-airbus-stall-recovery-procedure.html http://www.pprune.org/tech-log/415373-new-airbus-stall-recov...
- mikeash 9y ago
  With linked controls, the sane pilot at the controls would have immediately realized that the crazy one was fighting him, and it would have been brought to a swift end. I know a lot of pilots and I don’t recall ever hearing one express the opinion that non-linked dual controls were anything other than idiotic. I’d personally be quite wary of ever flying such a machine. (Although of course the stuff I fly uses purely mechanical controls so there’s no choice in the matter.)
  - foldr 9y ago
    The sane pilot realized this anyway. Check the accident report. (Or rather, the captain realized once he entered the cockpit. Neither of the pilots in the cockpit ever figured it out.)
    - mikeash 9y ago
      Once Bonin told them he had been holding the stick back the entire time, they immediately began a proper recovery, it was just far too late. This might have happened much, much earlier if the other pilot at the controls had been able to feel this.
      - foldr 9y ago
        What is your source for this? It does not seem consistent with sections 2.1.3.4-5 of the report. In any case, the captain was not holding a stick when he returned to the cockpit, as both pilots were in their seats. So the captain could not have gotten any tactile feedback regardless of the stick design.
        mikeash 9y ago
        This transcript: http://www.popularmechanics.com/flight/a3115/what-really-happened-aboard-air-france-447-6611877/ http://www.popularmechanics.com/flight/a3115/what-really-hap... I’m not talking about the captain, I’m talking about the other pilot at the controls, Robert. He also held the stick back for some time, but he appears to have done this in the mistaken belief that the correct recovery procedure had been tried and failed.
- zkms 9y ago
  > I don't want to take this off on a tangent, but this theory of the AF 447 crash keeps getting repeated online despite the fact that the accident report did not conclude that the UI was a factor. This is incorrect. The BEA report explicitly blames the lack of an AoA display and recommends that an AoA indicator be directly visible to the pilots. The aircraft already has sensors to measure AoA to feed the flight computers; asking for a direct readout of AoA is nothing beyond a UI change recommendation (and not fundamental aircraft re-engineering): > It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required. The AoA invalidation logic ("mark AoA measurements as invalid if airspeed is less than 60kt") made the stall warning turn off as the stall became even deeper, making diagnosis of the stall more complicated. Worse, the BEA report states that the appropriate (nose down) control input led to the stall warning reactivating (since such an input would increase airspeed above the 60kt threshold -- inherent to a proper stall recovery), leading the pilot flying to reverse their control inputs and return the aircraft into a worse stall: > A few seconds after the transition to alternate law, the stall warning sounded briefly, even though the PF’s inputs should have made this warning sound for several seconds. The reason for this is the drop in the measured airspeeds, some of which fell temporarily to below 60 kt, while the angle of attack reached 40°. Furthermore, the drop in measured airspeeds to values of less than 60 kt during the stall caused the repeated activation and deactivation of the warning which may have made it considerably more difficult for the Captain to effectively analyse the situation on his return to the cockpit. > Several nose-down inputs caused a drop in the pitch attitude and the angle of attack, whose values then became valid, such that a clear nose-down input resulted in the triggering of the stall warning. It appears that the PF reacted, on at least two occasions, with a nose-up input, whose consequences were an increase in angle of attack, a drop in measured speed and consequently stopping the stall warning. Lacking an AoA readout, the pilots would have had to reverse-engineer AoA from their extant instrument displays, the warnings they were presented, the "feel" of the airplane (is it buffeting? how is it responding to various control inputs?, etc), and past control inputs. Every one of those sources were degraded per the BEA report: they didn't trust (to the point of changing the selected inertial data source even if there was no indicated issue with inertial data) their instruments because of the airspeed inconsistency, the stall warning would reactivate every time they made the correct control input (the exact opposite behaviour of a stall warning simply based on an AoA threshold), and buffet might have been interpreted as overspeed buffet. Expecting pilots to reverse-engineer the aircraft's warnings to guesstimate AoA -- a value that the machinery simultaneously measures and hides from the pilots -- is fatally bad UI (BEA uses the fancier term "ergonomics"), especially in cases when the flight computers deal with air data inconsistencies by forking over more authority to the pilots.

tlb 9y ago

Amazing that someone would design in multiple steering wheels, only one of which is active, and no big indicator to make it super-obvious which one it is. Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.

Jtsummers 9y ago
Check out the recent O'Reilly book Tragic Design for more situations exactly like this. Poor UI design is remarkably common, even on controls that are essential for safe operations. http://www.tragicdesign.com http://www.tragicdesign.com
- csours 9y ago
  Also the classic Field Guide to Understanding Human Error. Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265/ref=mt_paperback?_encoding=UTF8&me= https://www.amazon.com/Field-Guide-Understanding-Human-Error... Older PDF (paperback is well worth it, in my opinion): http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human...
deleted 9y ago
[deleted]
oasisbob 9y ago
Having differential engine control isn't too surprising - it's just another way to maintain a course in addition to the rudder. Jetliners have gangable throttle controls for their engines, albeit with what is probably a much better interface.
- cyberferret 9y ago
  Airliners usually have a hardware clip to 'gangload' all throttles together, and the 'interface' of having two or more separate levers next to each other makes it obvious if you missed one while moving them, or notice that the clip is flipped so the levers now work independently instead of all as one. Then again, in high stress situations even totally obvious signs like this can be missed, as evidenced by the Qantas 747 crew on the famous runway overrun in Thailand some years ago. I believe in that case, a large contributing factor was when the captain went to pull the levers back over the rear detents for reverse thrust after landing on the wet runway, he only grabbed three of the levers, and left one engine running at just over idle speed.

tomohawk 9y ago

Sometimes having too much money is worse than not having enough. With a tighter budget, you have to wonder if such an extravagantly over functional interface would be created.

theyregreat 9y ago
I’ve seen hundreds of millions (!!) wasted at a university on a program of software projects that failed miserably. Having too much money allows for unproven, complicated or arbitrarily selected solutions and more bureaucracy that introduces Tragedy of the Commons mediocrity and diffusion of responsbility to address higher-level risks.

pbh101 9y ago

UI flaws have hit the Navy before, with even worse consequences [1]. [1] https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air_Flight_655 https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...

dragonwriter 9y ago
Nothing I see in that article (or anything else I've seen about the incident) attributes it to a UI issue. Not all errors made by users are the fault of the UI.
- theyregreat 9y ago
  More than binary nuance is needed. The ship that crashed is a system of humans plus machines, the UI being just the API between the two. Forensic incident analysis of ship design, UI, human factors, etc. is needed.
- pbh101 9y ago
  You're right: nothing in that article mentions the UI. I learned about the incident in my computer ethics class in college (along with Therac-25, etc). Quickly-skimming, it looks like Cracked has a decent writeup of the UI issue specifically [1]. [1] http://www.cracked.com/article_19776_6-disasters-caused-by-poorly-designed-user-interfaces.html http://www.cracked.com/article_19776_6-disasters-caused-by-p...
  - LeifCarrotson 9y ago
    Because that website is cancer if you don't have an ad-blocker, I'll quote the relevant text: > The screen showed the operator what objects were detected on radar, and if he clicked on an object, it would track it. But if the operator wanted to get more information about the object (in this case, by listening in on its radio signals) to find out what it actually was, he had to move a separate cursor and click on the object again. > It's clumsy and unintuitive, and it made it really easy to forget which thing they were highlighting at any given moment -- the operator can be tracking one object and have it display the information for a completely different one because he forgot to move the other cursor. It's the kind of user interface that wouldn't make it out of the testing phase of a cheap browser game. And it cost the passengers of the plane their lives. > That's because the operator in the USS Vincennes thought he was listening to the incoming aircraft (the Airbus full of innocent people), because that's the thing he selected, when he was actually receiving signals from a parked F-14 several miles away, because that's where his other cursor was. > Granted, the transmissions alone wouldn't be reason enough to shoot down a plane: They'd also have to think that it was moving like an enemy aircraft. Unfortunately, the stupid system made that mistake pretty easy, too. Instead of telling the operators at the Vincennes if the approaching plane was ascending or descending, the system just showed them the present altitude on a smaller monitor. The operator had to write down or memorize the altitude, wait a few seconds, then ask again and mentally compare the two results to see if the aircraft was going up or going down. > Because of this, a calculation error led an operator to report that the Airbus was descending toward the USS Vincennes, like a combat aircraft would, when it was probably getting the hell away from them as fast as possible.

jordanb 9y ago

The real cause of the collision was poor seamanship and failure to follow the COLREGS on the part of the bridge crew of the destroyer. Most specifically they were seriously in violation of Rule 6: the Safe Speed Rule http://navruleshandbook.com/Rule6.html http://navruleshandbook.com/Rule6.html Every vessel shall at all times proceed at a safe speed so that she can take proper and effective action to avoid collision and be stopped within a distance appropriate to the prevailing circumstances and conditions. The USS McCain was traveling at over 20 knots at the time of the collision, through a very crowded area at the entrance of a traffic separation scheme. If they hadn't been traveling at this obviously excessive speed they would have had the time to think, and to work through little UI issues like the one described here.

csours 9y ago
The path to a disaster has been compared to a tunnel [0]. You can escape from the tunnel at many points, but you may not realize it. Trying to find the 'real cause' is a fool's errand, because there are many places and ways to avoid the outcome. I do take your meaning, reducing speed and following well established rules would have almost certainly have saved them. 0. PDF: http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human... Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648257 https://www.amazon.com/Field-Guide-Understanding-Human-Error...
- JshWright 9y ago
  I've never heard the tunnel analogy. Seems odd, since tunnels generally only have one entrance and one exit... In a lot of fields where the stakes are high and mistakes are costly (aviation and emergency services are the two I'm most familiar with) the analogy used is a chain. Break any link in the chain and you prevent the event. https://www.aopa.org/asf/publications/inst_reports2.cfm?article=4401 https://www.aopa.org/asf/publications/inst_reports2.cfm?arti...
  - csours 9y ago
    It's the perception tunnel. There are many branches, but only one route is followed. In hindsight, you can see all the branches and call out everything that went wrong.

Zak 9y ago

Aside from the lack of clarity about which station has control over what, which should be made really obvious, with additional warnings when someone sets a control input on an inactive station, this seems bizarre to me: While the Ship's Control Console has a wheel for manual steering, both steering and throttle can be controlled with trackballs, with the adjustments showing up on the screens for each station. I've never been on the bridge of a ship, but I've operated a lot of vehicles including boats, ATVs, snowmobiles, cars, bulldozers and once, an army Blackhawk helicopter simulator. These very disparate vehicles had one thing in common: there's a relationship between the position of any movement-related control and the movement commanded, and there are stops at the limits of control input. Trackballs do not have either property, and I'm having trouble thinking of advantages they might offer in this application.

csours 9y ago
None of those operate on the open ocean. There's a wheel there for steering; from the article it sounds like the trackball is used with a menu system of some type, not directly to set the steering angle.
mjlee 9y ago
I have been on the bridge of a ship, as an Officer of the Watch in the Royal Navy. Ships have both open loop and closed loop control systems. Closed loop is the normal mode of operation, but there are open loop systems to fall back to. The procedure tends to involve sending someone down to the rudder to communicate back the actual angle of the rudder. The difference between a warship and a most other vehicles is that you can't simply stop a warship and get out. You need to be able to fight even if you've lost the feedback loop from the bridge to the rudder. For the comparison to the blackhawk, in a ship you can at least do something about mechanical failures in control systems.
noobiemcfoob 9y ago
You use trackballs to input relative movement commands. The position of the ball doesn't need to relate to the position of the cursor. It's like a mouse if you picked it up and replaced it after every stroke. They have a couple nice properties in that they can be fixed in place and offer more freedom of movement to a joystick.

bluetwo 9y ago

I'm sure we've all read "The Inmates are Running the Asylum" by Alan Cooper.

lordnacho 9y ago

Even specialised UIs need to be intuitive. You should need to know the domain (navigation), but not the specifics of everything the UI can show. The problem with this kind of thing is people are sent on a course, which gives everyone a false sense of control and understanding. Clearly the crew didn't understand it, leading to a panic and wasted time.

greedo 9y ago

The headline is inaccurate. While the design of the bridge leaves a lot to be desired (in the eyes of laymen), the real issue is an incredible dereliction of duty by 7th Fleet and the USN in general in terms of training and staffing.

rdl 9y ago

Everyone in the chain of command in 7th fleet (from ADM Smith on down through the captains and those standing watch) should have been separated and potentially prosecuted for negligence. UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals, and obviously many systems failed for this to happen. When the military runs well, it runs on accountability -- there's been a serious shortage of that, especially above O-6, for a long time. "Retiring" without losing rank doesn't cut it.

kevinburke 9y ago
> UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals There are plenty of examples of "UI confusion" causing professionals to make mistakes in all sorts of industries. I'd suggest taking a look at the book "Behind Human Error," for example. http://www.usabilityfirst.com/glossary/mode-error/index.html http://www.usabilityfirst.com/glossary/mode-error/index.html https://www.amazon.com/Behind-Human-Error-David-Woods/dp/0754678342/ref=sr_1_1/146-0878510-2747236?ie=UTF8&qid=1509666426&sr=8-1&keywords=behind+human+error https://www.amazon.com/Behind-Human-Error-David-Woods/dp/075...
tormeh 9y ago
From what I hear the Navy has been very diligent about accountability. There are problems you can't really hard-ass yourself out of.
- jessaustin 9y ago
  Multiple crewman have died from multiple preventable errors in multiple incidents. I haven't heard about any firing squads for COs? Normally we Americans are so enthusiastic about severe penalties? Watch-keeping and safe navigation are boring, so officers need extra incentive to pay attention to them!
  - azernik 9y ago
    "Preventable" doesn't mean "preventable by harsher discipline".

trhway 9y ago

>At this point, everyone on the bridge thought there had been a loss of steering. In the commotion that ensued, the commanding officer and bridge crew lost track of what was going on around them. now add to that picture (according to your historical preferences) a salvo of the 10 inch battery from an enemy battlecruiser 10 miles away or 2 Moskits rushing at 2.5x Mach ... blaming UI is just so childish and lame. Like our Sun executives blaming market conditions back then 10 years ago when everybody else had already been enjoying the boom for a few years.

cocoablazing 9y ago

A key occurrence during this mishap: 0127 The Officer of the Deck ordered course to the right to course 240T, but rescinded the order within a minute. Instead, the Officer of the Deck ordered an increase to full speed and a rapid turn to the left (port). These orders were not carried out. 0129 The Bosun Mate of the Watch, a more senior supervisor on the bridge, took over the helm and executed the orders. I've witnessed multiple similar situations on a warship (imminent loss of extremely critical systems), and had to forcibly push the watchstanders out of the way to do their job for them. Many people are going to freeze when the SHTF, and there may be no prior indication. Major attaboy to the BMOW who saved many of his shipmates. Given the incident angle of collision, many more would have died from a perpendicular collision.

ineedasername 9y ago
Yep, but that freeze is limited with more training, and mixed watches when teh newbs have to be rotated in for the real thing so the "hold my beer" guys aren't outnumbered 10 to 1 by the frozen folks.
- cocoablazing 9y ago
  I can't believe these watchstanders had the LOK they should have had on the steering system, or every one involved in ship control would have been able to immediately identify the problem and realign the steering system, other than bmow. I don't think the senior watch team had their st either, or the orders to prepare to take manual control of the steering and propulsion system aft would have immediately been out. Also it makes little sense that lookouts who calculated cpa at collision weren't raising the alarm. These guys who I had to do their job for them: I got them removed, and tried to get them off our boat. They were fine people but they were a danger to us.
  - LeifCarrotson 9y ago
    There's a lot of acronyms in there. LOK = Level of knowledge? BMOW = Boatswain's Mate Of the Watch ST = ? Not "Subject to" or "Such that" as I've seen. CPA = Collision Prevention Assist in automotive systems, but maybe not here?

Animats 9y ago

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 at 12 knots. 79 injured, 4 seriously. This is bad design. All the controls that can steer the ship should be tied together and move together. How to do that was figured out decades ago. The Navy still has this thing where they hate to give control of both speed and steering to the same person. The helmsman and engine room take orders from the officer that has the conn. But that officer doesn't actually operate the controls. Some enlisted sailors do. This dates from the age of sail and steam. Merchant shipping gave this up decades ago. Back in the 1950s, the U.S. Navy built the USS Albacore. This was an experimental submarine to test out the teardrop-hull concept. It wasn't nuclear; it was just a test vehicle to see how such a hull form handled. It was expected to be more maneuverable than previous designs, so it was set up with aircraft-like controls. One person sat in the pilot's seat, strapped in facing forward, looking at aircraft-type instruments, and controlled all the maneuvering controls. It was a very agile craft. The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers. To this day, the Navy sets up nuclear submarines so that different people steer, control power, and control buoyancy. (The British in WWII tried to control aircraft with multiple people. As bombers got bigger, they wanted to put a senior officer in charge, but younger people were better pilots. So they had an "aircraft commander" back-seat driving, as well as a pilot handling the controls. This did not work out at all and was rapidly dropped.) [1] https://www.ntsb.gov/news/press-releases/Pages/PR20140408c.aspx https://www.ntsb.gov/news/press-releases/Pages/PR20140408c.a...

tlb 9y ago
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 more complicated about controlling engine power than I imagine?

ilaksh 9y ago

Shouldn't it have some kind of automated collision avoidance that would have at least given an optional course correction?

jzwinck 9y ago
I sail regularly in the waters where this occurred. They are extremely crowded with large ships, small fishing boats, and more. The Navy ship was moving at 12 knots which is relatively fast in the local context. Not only does this open them to a violation of the Safe Speed Rule discussed in another comment, it means that any automated course correction would have a decent chance of putting them on a new collision course with a different boat. Perhaps even a small one their radar will not see. The solution is to slow down. This is well known in nautical practice: if things are not going your way, slow down. If you are not sure what to do, slow down. If you are unable to control your vessel, slow down.

hinkley 9y ago

> The report found that the McCain did not have the right type of watch on duty for navigation in congested waters and that watchstanders' training was insufficient. But there was never a warning signal from the Alnic of impending collision or a change of course by the merchant in an effort to avoid the collision. "Despite their close proximity, neither JOHN S MCCAIN nor ALNIC sounded the five short blasts of whistle required by the International Rules of the Nautical Road for warning one another of danger," investigators found, "and neither attempted to make contact through Bridge to Bridge communications." What a comedy of errors.

Johnny555 9y ago

A billion dollar ship seems like the kind of place it's worth having real physical controls and indicator lights for functions like this. I get why auto makers love touchscreens, because buttons, knobs and lights are comparatively more expensive than adding another menu entry to the touchscreen, but that's not the case in an expensive ship.

mikerathbun 9y ago

I would be interested to see how much liberty the contractors who develop these systems are given. Are they given a rigid spec by the Navy and expected to implement it exactly or are they given a general proposal which allows them to iterate on UI from lessons learned from previous accidents caused by confusion.

ineedasername 9y ago

Nope; No, just not at all: UI Confusion is never "ultimately" the cause for accidentally killing people through poor operation of a $2 billion piece of military equipment. A UI may suck, many do, in or out of the military. So, training. and then more training. I don't have a high stakes job, but if I allowed code-completion to drop tables, commit the change, delete the backups, and then burn down the building... well, that's not on the UI, that's on me. So unless we're talking MS Word Clippy-- and I think the article would have mentioned that-- UI can't take the fall on this. Besides: It began with the Helmsman sending all control instead of just throttle control to the Lee Helm station. That mistake isn't explained as a UI issue, it's glossed over, but everything came from that initial screw-up. Sure, afterwards there was confusion, but even then, "OMG WE LOST ALL STEERING INCREMENT THE IDIOTIC PANIC OPTION VARIABLES!" isn't really an acceptable response. How about, calmly, "Helmsman double check that control assignment if you please <insert navy jargon cliche />"

josephwegner 9y ago
Interestingly, this is the opposite of the direction much of the tech industry has been moving with post-mortems. - http://firstround.com/review/this-is-how-effective-leaders-move-beyond-blame/ http://firstround.com/review/this-is-how-effective-leaders-m... - http://code.hootsuite.com/blameless-post-mortems/ http://code.hootsuite.com/blameless-post-mortems/ - https://codeascraft.com/2012/05/22/blameless-postmortems/ https://codeascraft.com/2012/05/22/blameless-postmortems/

robbrown451 9y ago

There were multiple causes. The article makes this clear, but the title to the HN post implies there was only one main cause. The UI should be fixed. There should be a process for helmsmen to report problem UIs. And of course training. But you can't really train for situations that you don't fully understand, and the people designing the UI are really the ones who need to put the hard work into understanding all these possibilities.

thunderplot 9y ago

Militaries are good at making horrible UI. :-) I used to work at early warning radar, that should notify our tops about incoming ICBMs. When there's a target, classified as "suspicious" or "something that's going to fall onto {our, neighbour} territory", the following happens: - very loud sine 1200Hz tone starts sounding - the only output device, "fast-printing device", starts dumping hexdumps of internal structures to long 10cm wide paper (like toilet paper). - the whole chain of command start yelling to each other (downwards), demanding data and info about the target. So as the last person in that food chain, you're in the middle of panic, 1200Hz are drilling into your brain, damned thing prints hexdumps, and you need to apply binary shifts and ANDs, convert from floating point hex to decimals and pray that there's enough paper in damned FPD. I could never imagine worse UI, it's strange that we didn't start WW3 in those conditions.

wmeredith 9y ago
"Militaries are good at making horrible UI." This is extremely applicable: https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa9 https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa... Disclaimer: it's an article I wrote about why government software contractors suck at their jobs.

lisper 9y ago

It's not just boats that have safety-critical UI design problems. The avionics in airplanes are becoming so complicated that managing the avionics is almost more difficult than flying the plane. I'm a private pilot who has been flying a Cirrus SR22 for twelve years. In that time it has gone through two major glass cockpit avionics revisions. In the first revision, called the Avidyne, the autopilot was either on or off. In the current revision, called the G-1000, the autopilot can operate in two modes: AP mode, where the autopilot is actually flying the plane, and FD or flight-director mode, where the autopilot does all of the calculations to figure out where the plane should be flying and displays a target on the primary flight display, but the actual control of the plane is still in the hands of the pilot. If the plane is stable, it is very easy to get fooled into thinking the autopilot is flying the plane when in fact it is not. There are only two visual indicators that tell you if the autopilot is actually flying the plane: a small green LED on the autopilot console, which is down near your right knee, and another small annunciator on the primary flight display. It looks like this: http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a36ad6e-3ab6-a48c-3f67-d5318ba1f66b/source/552x414bb.jpg http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a3... The autopilot indicator is indicating AP mode in that image. See if you can spot it. It has happened to me more than once that I thought I had the autopilot engaged when in fact I had only turned on the flight director. I predict that one of these days someone will die because they made this mistake in instrument conditions.

rangibaby 9y ago
Is there a purpose to the display being so colorful? If AP were the only green thing and the others were monochrome it would stand out more.
- lisper 9y ago
  Some of the colors do have a rationale. The blue and brown background are actually the attitude indicator display. Blue is sky. Brown is ground. There is now an option available that renders the terrain you're over so you can "see" outside via the PFD even in clouds, e.g.: http://glasspilot.com/2008/08/is-synthetic-vision-a-game-changer/ http://glasspilot.com/2008/08/is-synthetic-vision-a-game-cha... But the other colors I think are just "because they can." There are a lot of IMHO stupid aspects of the G1000 UI design. (To be fair, the G1000 has to many features that designing a good UI for it is a real challenge.)

tacotornado 9y ago

There was a big ferry accident involving a similar transfer of control problem in the New York harbor.

jrochkind1 9y ago

not surprised

kepano 9y ago

Reminds me of the book "Set Phasers on Stun" which details stories of poor designs that caused deadly disasters. An essential read for anyone designing these types of systems.

exabrial 9y ago

My friend's boat is a dual engine diesel, 78ft, two stories. It has a controller where you set a course and a computer controls the throttles and rudder. On the very choppy lake of the Ozarks, this is a handy feature. You're telling me a million dollar guided missle destroyer can't do this?

jessaustin 9y ago
Everybody come to the beautiful Lake of the Ozarks, where you too can be menaced on narrow inland waterways by giant overpowered wave-making monstrosities like that of 'exabrial's friend! At least you won't have to worry about uncontrolled USN vessels...
- exabrial 9y ago
  HAHA :D I took a 5mi trip up the channel on jet skis on memorial day weekend. Holy smokes, I thought I was going to die. The channel chop is no joke!

trisimix 9y ago

Pretty sure all collisions are avoidable.

ericb 9y ago

On a related note, it occurs to me that UI/UX for car navigation systems and cell phones is an actual life-and-death matter. Maybe we should treat it differently.

Camillo 9y ago

The headline is clickbait, and directly contradicts the report's conclusions. The article says as much ("While the report lays the blame on training"), but by that point you've already clicked. But look at that bridge schematic. There were TEN PEOPLE in that room, and they couldn't keep an eye on the radar, raise a collision alert, radio the other ship, etc. They just completely lost it. The John McCain was put in a state of complete confusion by a simple control error they themselves made, while cruising along a commercial shipping lane, at peace. How would they have handled an enemy attack?

newsreader2 9y ago

Are you able to leave some of the steam in?

hliyan 9y ago

Actual naval experts in HN notwithstanding, I think it's worth remembering that a little knowledge, at times, can be a dangerous thing. This is true of many topics on HN that are only obliquely related to software engineering. Silicon Valley has earned a great deal of confidence by disrupting other industries by out-thinking their experts, but perhaps we should temper that confidence a little, least it becomes hubris... Bottom line, if we're going to dismiss experts, I think we should be armed with a little more than the knowledge we garnered from an internet article.

deleted 9y ago

[deleted]

_pmf_ 9y ago

It's not necessarily the UI that must have been confusing, it might have been that these modes of operation are inherently confusing.

jonsen 9y ago

"His theoretical insights are grounded in an extended analysis of ship navigation—its computational basis, its historical roots, its social organization, and the details of its implementation in actual practice aboard large ships.": https://mitpress.mit.edu/books/cognition-wild https://mitpress.mit.edu/books/cognition-wild

deleted 9y ago

[deleted]

matt_the_bass 9y ago

Good maritime discussion on gcaptain http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-was-the-navees-fault-twice/46496/2 http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-wa...

matt_the_bass 9y ago

I've been on the bridge of many commercial ships including giant yachts and cruise ships during trafficked maneuvering. They never have that many personnel involved on the bridge. Maybe that is part of it?

PythonicAlpha 9y ago

Alan Cooper wrote some books about User Interface design and this really reminds me of his books and talks. When you cross a car with a computer, what does happen? When you cross a ship with a computer, what does happen? Ship steering and management was developed in hundreds of years, than comes the computer and changes everything in some decades ... no wonder, that some friction happens. I am not anti computer, because I am a developer myself, but you must be very carefully in designing these things. I even see it in our modern cars and cell phones ...

wruza 9y ago

Maybe I’m too late or too simplistic, but why do ships and aircrafts have so complex control systems in normal functioning modes at all? Why can’t layman ship commander like me just tell the system to be “there” in specific time via hand-drawn or standard route? If my engines malfunctioning, or steering lost it is one thing, but if everything is okay, can’t a simple swipe-to-sail iphone app just coordinate all ship controls to “be there in 3m08s” in most effective way according to the safety rules? Now it seems like all the precise counters and sensors are passed to slow, biased, narrow-focused and error-prone device that is my mind to get goal-related feedback. And this device happens to be proud of being it. As a programmer, I just can’t understand it. Do commanders quickly solve unsolvable differential equations in realtime or what?

dragonwriter 9y ago
> Maybe I’m too late or too simplistic, but why do ships and aircrafts have so complex control systems in normal functioning modes at all? In the case of warships, specifically, its because normal operations are reduced-complexity training opportunities.
Zeebrommer 9y ago
Although I think ship control can definitely be made more user-friendly, what you are asking for is of similar complexity as a self-driving car.
- freeone3000 9y ago
  We have those! Or at least, we have close enough to one of those for a secondary autopilot system.
- wruza 9y ago
  I thought most of self-driving car complexity comes from guessing the route and stop timings, not from following them?
  - 0xffff2 9y ago
    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.

polynomial 9y ago

Alan Cooper observes in his book Inmates are Running the Asylum than the majority of non-terrorist related airline disasters are caused by bad UI. Not instrumentation as such, but the modern version of it which is the "interface." One example he cites is a pilot selecting a destination beacon using a "simple" drop down menu. 2 possible options, similar in name and adjacent on the alphabetized list are deadly in difference. One is the correct orientation, the other takes the plane directly into the side of a mountain. Given the state of confusion that is modern UI design, this revelation is not too surprising.