USS McCain collision ultimately caused by UI confusion
arstechnica.co.uk
arstechnica.co.uk
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.a...
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?
Can you not vent some of the steam, so the same volume of steam is being produced and the temperature the same but only some of it goes to the drive?
The comment was about the ability to vary power at all, not doing it efficiently.
Are you going to choose to crash into something because it's wasting fuel to vent part of the steam?
The ship command structure was a form of information hiding, whereby the commander only worried about the speed, whilst the engineer worried about how to efficiently deliver the requested speed.
Under emergency you will vent, but under normal operations where you just want to slow down you care very much about efficiency.
Not just for monetary reasons either (though that's a factor) but because the lumps of coal you're not burning now could save your ass in bad weather and make you reach safety instead of being stranded in the middle of the ocean.
On a modern diesel or gas turbine ship, no there's not. Obviously there are limits to what the engine can do still.
They're not direct driving the screw with steam power from the reactor heat-exchange, surely.
You've probably seen aircraft carrier decks covered in smoke. This is because the Nimitz's catapult system is directly steam powered, service steam is widely used on the class. I can't find a citation for this now (this is from memory) but I saw some documentary on it once where it was mentioned in passing that even the washing machines on the ship were steam powered. There's service steam everywhere on the Nimitz.
Having steam power everywhere introduces a lot of complexities, which is why the Navy's moving away from it with their new carrier class[4]. The Gerald R. Ford-class does away with service steam in favor of more powerful electric generators. There'll be no service steam, just steam to drive the electric turbines.
1. http://www.nimitz.navy.mil/FACTS.html
2. https://en.wikipedia.org/wiki/Nimitz-class_aircraft_carrier#...
3. https://www.marinelink.com/news/dresserrand-propulsion302604
4. https://en.wikipedia.org/wiki/Gerald_R._Ford-class_aircraft_...
https://en.wikipedia.org/wiki/Electromagnetic_Aircraft_Launc...
Basically they spin up flywheels that then dump their kinetic energy back into electric power as the catapult is released.
And it allows them to finely adjust the speed of the catapult depending on the kind of aircraft they are launching.
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.
Or does it directly power the engines? This would mean that your entire control loop would include the latency of the steam generation process. Move the lever, wait for the water to get hot, wait for the turbines to spin up, and then the screws would start to turn faster. Like the throttle response in an ancient diesel truck.
Given that the original diesel submarines used giant battery arrays to power the electric motors while the engines were off, and that the former gives much better control response, I'd assume that there are still large batteries in the loop. This paper [2] supports that assertion:
> The nominal cell voltage is 2.0 V. [1] The PDX-57 cell designed for Ohio-class submarines weights 2,100 pounds with a capacity of more than 10,000 Amp-hours and stored energy of 2.6 MWh. [1] The ASB-49 cell designed for the Los Angeles-class submarine weights 1,300 pounds with a capacity of 7,200 Amp-hours and stored energy of 1.8 MWh. [1] The LLL-69 type cell weights 1,500 pounds with a capacity of 8,100 Amp- hours and stored energy of 2.0 MHh. [1]
A couple megawatthours is plenty to run the screws while the steam loop and nuclear reactor respond.
Therefore, toomanybeersies comment:
> On a nuclear powered ship, yes, since you still essentially have a steam engine, the engine telegraph (throttle) isn't actually linked directly to the engine.
is technically correct but actually irrelevant. The nuclear reactor telegraph does control the steam turbine and eventually the battery charge, rather than the engine. But somewhere there's an electric motor controller which responds instantly.
[1] http://ieeexplore.ieee.org/document/1177196/?reload=true&tp=... [2] http://large.stanford.edu/courses/2013/ph241/ditiangkin1/
Both the Ohio and Los Angeles class submarines use mechanical linkage propulsion, not electric, if I understand correctly.
Source: https://www.defensetech.org/2013/09/27/ohio-class-subs-to-sh...
Looks like some of the most modern or in-design classes are using electric drive, but most things out there are using direct mechanical linkage to the turbines to drive the propeller.
Right, this is why when BAe lied to the UK claiming that the QE class carriers could easily be converted to cats'n'traps every engineer in the country said WTF? Because with no nuke where do you get either the steam for the catapults or the surplus electrical power for EMALS when you want to steam directly into the wind for deck operations? But our idiot PPE-educated politicians lapped it up and signed cheques for billions anyway...
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.
“No, we did not deliberately ram a ship suspected of smuggling contraband to North Korea, that would be illegal.”
http://www.ussalbacore.org/html/virtual_tour.html
http://www.ussalbacore.org/img/img_virtual_tour/32-lg.jpg
But it was modified several times, so that doesn't really contradict the story.
Albacore was very maneuverable, probably more so than any large sub before or since. The term "hydrobatics" was used. Probably too maneuverable for a ship of that size, since it wasn't configured for operation with everybody strapped in.
It seems similar to the whole democracy v. autocracy tradeoff. One optimizing for coverage of perspective, the other optimizing for efficiency of a perspective.
It’s a habit that the organisation is used to, so there is resistance to change.
(I was born in one of those countries, and drove manual transmission for my first 10 years of driving, but am now a convert)
That said, the automatic might beat a manual in other metrics.
Automatics in UK certainly cost more, if one doesn't ride the clutch I imagine the manual will have lower maintenance costs?
But yes, after owning manuals for years I would never go back, an automatic allows you to be so much more focused on the road and enjoy it more - I love driving and have a sports car, would never ever swap the transmission in that back for a manual.
At the end of the day I think manuals are great fun but automatics are more practical. An automatic will never stall out in a safety critical moment, as I always worried I would do in the manual. I've also pondered that if I was ever to sustain a serious injury to an arm or leg, I would probably be able to drive an automatic in an emergency. Driving stick with a broken arm would be substantially more difficult. The fuel economy advantages enjoyed by manuals seem to have dissipated at this point as well.
* i.e. it doesn't have a torque converter, since it basically has two separate gear sets with two separate clutches. To switch gears it seamlessly moves between gear sets via the clutches. There is no interruption in power.
Even so, the stick driving reflexes only get dulled temporarily - within five minutes of driving stick, you're back up to speed again (pardon the pun).
I do think the Navy has difficulty delegating and tends to try and focus power on a few positions.
> Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control."
If that's true and not just an excuse for an unnecessary command, then maybe it's still difficult trying to do both at once.
The Apache Attack Helicopter is renowned for being especially difficult to fly [1], and I wonder if Navy wished to avoid having a similarly single, not-so-easily-replaced bottleneck.
[1] https://www.airspacemag.com/daily-planet/hardest-to-fly-8713...
When maneuvering, you are watching obstacles and can see how much you need to turn to avoid them. So you give rudder orders. Your actual heading is only a secondary concern.
When navigating, you simply order the desired heading (for minutes, hours, or days). Then you focus on other things while the helmsman sweats the details.
Maintaining a ship's heading is a full time job. If you get distracted, you get off course pretty quickly.
Speed isn't even really handled on the bridge. The engine order (ahead full, back half, emergency stop, etc) goes to the engine room where multiple people do the work.
Note: This is in the context of oil and nuclear steam-powered ships. Gas turbine ships may well have an actual throttle on the bridge. Whether the bridge has a throttle or just an engine order telegraph, the helmsman can often have their hands too full to deal with it. But someone else can do it along with their other duties, as speed control is not so intensive.
I wonder if there is enough information publicly available to compare the workflows on the McCain to the same workflows on the Zumwalt.
Somehow in airplanes a single pilot manages to control not only the rudder, but throttles, ailerons, elevators, flaps and whatnot while also yakking on the radio. And airplanes zip along at 500 knots rather than 20 like a ship.
A ship just can't have as much obstacles as tank negotiating battlefield.
The UK's Warrior armoured personnel carrier is an example of what I guess you mean by 'Infantry Tank'. It has a Commander, Gunner and Driver (plus the 'dismounts' - seven guys in the back who get out to fight on their feet). The driver - as the role name implies - does all the drving. The commander (who is also the loader, incidentally) directs the driver where to go. He does not have duplicate driving controls. If the driver is very inexperienced, the commander will give him very precise direction. If the driver is experienced - in the sense of understanding tactical movement considerations - the commander can be much more hands off.
If the vehicle commander is also a platoon commander, he is also giving orders to the commnanders of the three other vehicles in the platoon. He is much more likely to be paired with an experienced driver so he can focus more on the overall battle than control of his own vehicle.
Larger ship - water is never still, and any vessel's helm left untended results in drift, both in heading and real speed vs ordered. Depending on traffic and the reaction time of the hull, corrections need to be made immediately or even well ahead of time. So helmsman watching constant compass shifts and adjusting steering is a full attention task. As is monitoring speed made vs speed ordered. Still need more eyeballs to keep a full 360 visual watch, radar watch, and a quartermaster to plot position against nav hazards and boundaries and warn against the 'invisible' navigation issues.
If a destroyer could respond to control input like a plane, there would need to be a single person at the helm/throttle.
Entering/leaving any decent sized port that handles larger vessels is a much more intense collision avoidance situation than any airspace management situation I can imagine.
Reducing the reaction space from three to two dimensions and extending the reaction time from control input -> output by a factor of 100 to 1000 is part of it.
The other complication is having a magnitude or more of different classes of "threats", from unexpected solid objects ( chart errors or new items unreported), other vessels both larger and smaller with faster or slower response times of their own, errors in SA... eyes and professional judgment help immensely. Thus the focus on keeping the OOD watching the whole SA.
My sub had at least a dozen people involved in building the "picture" around the boat, visual, sonar, radar... plus two or three of us collating that into displays and reports the OOD could see immediately.
Rather, I'm doubting that going in a straight line at a target speed is correctly handled with a three-person steering wheel. My understanding is that the current OOD already has a trajectory planned through the workspace coordinate system (space, time) and gives orders in workspace coordinates ("go this fast") that are then translated into low-level control outputs ("set the rudder to X"). It sounds like in some cases the OOD even gives direct control outputs - "Prepare for X thrust in Y minutes". Certainly these low-level controllers can't be a good thing for the OOD to be spending cognitive resources on, and I'd be astounded if we can't replace that with a computer that translates directly from that trajectory to the control outputs.
That's why I used airplanes as my example, rather than, say, autonomous vehicles. A commercial airliner's path through the air to a safe landing is basically hard-coded. The task of the airplane's autopilot, then, is simply to follow that trajectory - and I'd guess that it's far more difficult for an airliner to follow a workspace trajectory than it is for a ship to do so.
Really, the hard part is going to be getting the trajectory out of the OOD's head. And even then, it'd be so much easier if the helmsman could execute "go this way" by punching "this way" into a computer instead of staring at a compass and directly and continuously controlling the rudder.
The OOD is estimating a best trajectory given an analysis of the navigation constraints and the behavior of every possible contact in the vicinity. Orders at every level of detail are possible at any time... from 'resume best course for point "X-Ray"' to 'allaheadflankfullrightrudderbraceforimpactport!'. That is the point of resistance to most levels of automation past 'ship's wheel mirrors rudder angle' and 'engine order repeater indicates desired engine rpm'.
The Wolf Rock collision board of inquiry makes for interesting (and embarrassing) reading around what happens when assumptions are being made about who is doing what.
That's how Star Trek do it!
Look at your car radio in a 90's car. You didn't need to look at it to figure out how to push the radio button, turn the volume, anything. You could even adjust the bass on the fly with a bass knob instead of navigating to your "eq" menu to do it.
Now, you've got to look away from the road, realize what "mode" your in, you can move the menu around to the "audio" section, then "fm", then select a channel. And of course, it's a touch screen so there's no tactile feedback. But at least it's got PRETTY ANIMATIONS!
My Toyota Corolla will blast audio out of the speakers as it boots but the volume knob doesn't respond till it completely boots up. So you may start the car and have 5-10 seconds of blasting radio that you can do nothing about. GREAT JOB GUYS. A volume knob that needs to boot.
This is what was considered not only acceptable, but a "Feature" in a modern vehicle with hundreds of millions of dollars in investment and NOBODY thought to see if the radio interface was actually... efficient? It's not like people interact with the radio/music console in a car on a regular basis...
Or my 2001 Jetta. It was one of the earlier cars with "climate control". What that actually means is that to set it to heat, you have to tap the "plus temp" button a literal 20-30 times to get it into "HI" to force heat on. And then the day warms up and on your drive home you want AC? Tap it 20-30 times on the "minus temp" button. There was no knob for AC temp. They gave you 1 degree precision on a car that couldn't guarantee 10 degree temperatures. Additionally, the volume control for the car had digital buttons. That's right. Enjoy pressing up/down 50 times. No ability to rapidly change volume. So when you switch radio stations or to casette/cd and the volume is highly different you have to sit there pressing the button over and over. But, even then, at least these were BUTTONS that you didn't have to look away from the road to use. They had little tactile notches on them so you could feel around for them.
If your answer to the question "why can't a billion dollar industry provide me with instantaneous channel switching?" is "because they are lazy", you are severely misguided (at the very least!). There are hundreds of extremely talented engineers working full-time on these problems. If the solution were as easy as you propose, the issues would be solved.
> zero boot time
That's not going to happen, ever, but I'll assume you meant "faster" boot times.
Probably. Keep in mind that your average set-top box likely goes through a more complex secure boot process than most electronic devices you would ever interact with. Why? Because if people can run arbitrary firmware on a set-top box, your cable company would lose a shit ton of money.
> instantaneous channel switching
You are bound by the latency required to demodulate a signal being broadcast from some satellite ~30,000 km away from the receiver, decrypt the resulting stream, and finally decode it, all on the fly so you get a nice, continuous, stutter-free full HD broadcast.
I am no expert, so there is probably way more stuff happening behind the scene that someone else could probably shed light on. The point of my comment was to demonstrate that things can sometimes be more complicated than they seem at first glance.
Simple solution: just put 10x decoders/tuners for most recently used channels. I don't think it's really an engineering problem but more about cost-effectiviness, i.e. not enough consumers are willing to pay the premium.
However, even if the read-ahead tuner was perfectly predictive you'd still need to flip through channels fairly slowly, otherwise you'll outrun it - about a second a channel.
Decrypting and demodulating have be as fast as the data is coming, otherwise the delay would grow until you never saw the end of the show. So that's not the reason either.
Your TV doesn't have the information it needs to start displaying MPEG-2+ATSC A/53 video for as long as 700ms. It needs to buffer quite a bit of timing information and at least an I-picture frame before it can start displaying anything: http://www.bretl.com/mpeghtml/startbuf.HTM
Not only that - the overall standard has tight timing tolerances to keep video arriving at the encoder/transmitter in-sync with audio/video leaving the decoder in your TV. It's not like MP3 streaming where every client has its own buffer size and time to start playing depending on network conditions, bitrate, etc.
Having a reliable buffering process to keep receivers in-sync is a feature, not a bug.
You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?
The answer is never "engineers are lazy". The answer is, the company doesn't give a flying fuck about this problem and will actually prevent engineers from working on solving it, because they can sell you a TV perfectly well with this problem still present, and there's other work for engineers that makes TVs easier to sell than actually delivering a quality product.
Not to mention the damn spyware that's included with it...
I still can't tell if my computer monitor is on or off because I don't know the weird LED flashing code it uses to communicate that (Holy crap! appliances use something like morse code to tell you important information about their state! How did they get so needlessly cryptic? If there's no picture, I have to check all the cables and push the power button a couple of times to see what happens.
Web programmers are as much to blame too. Show me a web video player that has play and pause buttons that always do what they say when they say it.
The only player which ever worked properly — even allowing the user to step through a video frame by frame — was part of Apple’s QuickTime framework.
Fun fact: QuickTime will be 26 years old in December.
As cool as my friends' new car's features are, I still love my Acura RSX. I can reach from the steering wheel to adjust anything on the console without taking my eyes off the road. No fuss, made for human hands, knobs and buttons.
https://ccco.s3.amazonaws.com/kb_photos/290/2284_1964_Cadill...
It has excellent thermostat-controlled AC and heat, and it was very easily controllable using dedicated buttons without looking away from the road at all. I wish modern cars (cough, Tesla) would put a tenth the care into UX.
What some people do is make an audio file consisting of several seconds of silence, and do whatever is needed (call it "AAA.mp3", or put it first in a default playlist) to have it play while the player boots.
But yeah, it's really messed up that that should be considered acceptable.
https://www.ebay.com/itm/Vintage-Cookmatic-Radarange-Made-by...
After reading Ben Rich's Skunk Works memoire, and coming across some other references to the Navy's intransigence in some areas, this fits right in.
A great reminder that "the way things are" often are just accepted, never questioned, even ritually enforced; all while drifting further and further from better ways.
This was used on the America's Cup New Zealand hydrofoil [1]. Conventional designs gave a helmsman a wheel to control the rudder with a twist grip on that wheel which controlled the angle of the hydrofoils and therefore the ride height of the boat. On the New Zealand design,
> they've got control of the boat divided between three people, so that Peter Burling is just steering. You can see he's just driving Miss Daisy when he's going down the run. And there's a guy trimming the wing sheet [adjusting power], he's doing a relatively conventional job. But then the third man forward in the boat has got his arms in what look like biathlon bars and he's controlling both the daggerboards all the time. He's in charge of just keeping the boat ride height at the right level, whereas on the other boats it's the helm with his buttons and paddles on the wheel who's actually having to fly the boat up and down and do the steering.
This does leave just one person - the helm - with real control of the boat. The others are just maintaining the ride height and maximum power from the sail. In the naval model, the helm doesn't actually have control of the boat.
But I think that you're correct that a naval ship which would allow electronics to maintain speed and bearing doesn't require that, and the primary reason for retaining it is political desires from the brass.
Which is why pilots in modern air forces are officers. It isn't about guarding traditions. It's about the level of training and responsibility needed when navigating a vessel. The Albacore operated in a totally different environment. Its "pilot" wasn't navigating in a busy shipping channel and could turn on a dime. The reason that the watch officer doesn't operate the control is because that frees him/her to concentrate on actual navigation, the forward thinking needed when operating a huge object that cannot turn on a dime. Civilian vessels at sea are going from A to B. For a military vessel (ship or aircraft) the A->B navigation is one of many different missions going on simultaneously. That's why they need more heads making decisions.
" ... did not have the right type of watch on duty for navigation in congested waters ... "and neither attempted to make contact through Bridge to Bridge communications."
The system did not fail. The system wasn't implemented. UI issues were secondary to the fact that this was an undermanned ship with an unconfident crew.
This reminds me of the Air France crash that was largely due to split control. The UX of transferring control of a system is difficult, and I don't know the details of what it looks like in an Arleigh-Burke.
Though the 2nd helmsman getting confused by having the throttles split points to training. That's ship control 101. I do think the loss of practical training is a root cause here. How many hours does the average helmsman have under their belt? It's just not that much.
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.)
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.
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...
Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error...
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?arti...
https://en.wiktionary.org/wiki/tunnel_vision
(figuratively) The tendency to focus one's attention on one specific idea or viewpoint, to the exclusion of everything else; a one-track mind.
Road and train tunnels have many emergency exits...
Is there a reason the throttle can't be reversed so that grabbing would reduce throttle and slow the bike?
(FWIW, I'm a fully licensed motorcyclist, don't currently ride.)
https://en.wikipedia.org/wiki/Swiss_cheese_model
"In the Swiss Cheese model, an organisation's defenses against failure are modeled as a series of barriers, represented as slices of cheese. The holes in the slices represent weaknesses in individual parts of the system and are continually varying in size and position across the slices. The system produces failures when a hole in each slice momentarily aligns, permitting (in Reason's words) "a trajectory of accident opportunity", so that a hazard passes through holes in all of the slices, leading to a failure."
A series of minor failures that combine for a serious crisis seems very relatable.
It's a poor choice for quoting non computer languages.
The problem isn't "because they used codeblock" the problem is codeblock is broken.
They seem to manage avoid colliding with both commercial traffic and the numerous sailing yachts while doing 18-20 kn.
Accidents have happened, but it's not recurring events. One exception in the Baltic see is the Polish M/S Jan Heweliusz, that was involved in a number of of accidents, until it finally capsized in hard weather.
http://cdn.cnn.com/cnnnext/dam/assets/170821080742-04-uss-jo...
Sorry. That does not compute. Based on that visual, the ship was dead in the water.
The McCain entered the TSS at 20 knots and varied between 20 and 18 knots until the steering problem began. The OOD ordered the vessel slowed to 5 knots but due to confusion on the bridge the orders weren't carried out properly and the vessel was still making 11.8 knots and turning to port at the moment of impact. The Fitzgerald was also traveling through traffic at 20 knots and narrowly passed three vessels at that speed before finally being struck by the Crystal.
A bit like those organ donors, err.. motorcycle drivers, that swerve among the traffic at high speed.
http://cdn.cnn.com/cnnnext/dam/assets/170821080742-04-uss-jo...
There is no visile damage indicating that the penetrated vessel was moving forward. The damage is perfectly symmetric, as you can clearly see.
The McCain crossed in front of the cargo vessel and was hit in the aft section by the cargo vessel that had a constant speed and heading.
You don't stop or turn a cargo vessel as quickly as the McCain can maneuver. You also need to take into account that you don't shove a ship sideways through the water easily - it can't slide as easily as a car can. The majority of the cargo vessel's kinetic energy will go into plastic deformation. It's not a sudden impact, more a crushing and deforming.
Edit: I have to revise what I said about the impact, according to the report, sailors close to the impact likened it to an explosion.
This sounds like pandemonium and panic. Sounds like the bridge was totally out of control. They didn't even follow basic procedure to warn nearby ships of danger, they just plowed right in front of one.
http://www.popularmechanics.com/military/navy-ships/news/a27...
So they were unable to understand their own speed controls.
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/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.
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.)
(In case it's not obvious, I've got a few hundred hours behind the G1000. AMA.)
My feeling has always been that the Garmin UI was somewhat clunky and suboptimal, possibly because they tried to keep it similar to the UI of previous smaller devices (such as the GNS 430); a bit like if the iPhone hadn't come along and we'd still scroll by putting our finger on a little arrow in a scroll bar on mobile devices.
My impression was that other manufacturers had a better UI, but somehow didn't make it in the marketplace.
Well, I haven't flown other glass cockpits. I just find the G1000 clunky and a bit unintuitive, that's why I was wondering whether there are still viable and possibly better competitors out there.
The GTN650 keeps a bit of the GNS430 feel... and those are, in my opinion, the best parts. I hate scrolling through the alphabet by dragging my finger across the screen. I have a similar disdain for trying to select stuff in-flight on my iPad in ForeFlight.
Would it be possible to display that same information using a traffic light system?
(Red=Immediate action required, Yellow=keep an eye on this, Green decaying to grey=something that changed (eg AP OFF green then turns gray after 10 seconds or so). It would need to be applied with discipline to avoid every single piece of information being red and hence useless. (cf phone notifications or people who click OK to every dialog box).
Information overload / fatigue is a real thing and something designers need to concentrate on more, the ugly brother of "minimalism" which looks pretty but is frustratingly useless.
If you're interested in human factors in aviation, there's a lot of work being done out there in the field. A friend of mine is actually working on an MS in Human Factors at ERAU.
https://www.youtube.com/watch?v=pN41LvuSz10
https://99percentinvisible.org/episode/children-of-the-magen...
Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.
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_...
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.
Here are some other G1000 confusions I remember:
- Flying down the ILS expecting to click the "go around" button on the throttle and see the missed approach cycle .... only to find out that the autopilot didn't know I started the approach because I had the wrong leg selected as "active" when I across the IAF (and I've been tracking the green ILS instead of the PINK gps for the approach)
- Given "vectors to final" from ATC, selecting "vectors to final" on the MFD, and then have ATC issue a speed restriction up to some waypoint ... which has now just disappeared because "vectors to final" doesn't display any of the waypoints (I think the logic is that you shouldn't need them, except in this case when you do)
- Doing an approach that has a IAF and IF with a holding pattern. Am I starting the approach from the IAF (in which case I do the hold), or from the IF (in which case I proceed directly to the FAF)? Once I've coordinated that with ATC .... I forgot to tell the autopilot who helpfully started planning for the holding pattern.
Honestly I think the solution here is more automation not less. These systems got so bad because pilots correct for them all the time.
Linked controls (nobody realized the junior copilot was making opposing inputs, which were then averaged with the pilot's) plus poor autopilot UI that they were accustomed to ignoring, made it stall and crash after a single wind speed sensor iced up.
If nobody had touched the controls, autopilot would have flown safely through the storm.
The whole accident is a prime example for a very minor problem (loosing air speed indicators) spinning completely out of control, with the crew being making every possible mistake all the way down, all three people in the cockpit completely ignoring 47 stall warnings.
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.
This is extremely applicable: 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.
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.
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.
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?
CPA = closest point of approach.
CPA is calculated for anything close ahead of time, but only if both you and another ship are moving in a straight line. Which the McCain wasn't.
UI doesn't cover mass confusion -> panic over critical loss of control that had NOT been lost. They heard hoofbeats and decided it was zebras, not horses.
So I guess if this warship fired all its rockets away, "due to bad UX", and destroyed a small nation, I guess the comments would also be about a bad UX. Oh crumbs, the "check status" button was so close to the "start armageddon" button. Perhaps we should submit a meek complaint to Microsoft or something.
"Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control.""
So... we gave the control of a warship to some guy that... has some difficulty navigating through the straits that like 1M of ships go through every day, without problems. Mind you, this is the navy that is supposed to be highly trained to deal with real-world issues such as naval blockades, pirates, and even wars.
It does not make sense at all. Allegedly there were some cuts to funding for navy. Maybe someone is trying to make a point. I do not know, this is just unexplainable. Certainly nothing to do with just "bad UX"
You have to look at the entire accident chain, and at the entire system, including training, supervision, redundancy, and, indeed, UX.
Design (in my opinion) is planning out what good and bad things are for a given tool and determining how to express that through the UI.
I disagree with the premise you have that the designer deciding what is good and bad is the whole or even the right story. I think I might agree with the implication that a system should make doing cognitively difficult/safety critical things easy but there is no possible way to plan for all eventualities, that's why we have 'intelligent' controllers in ultimate charge.
One day we might have artificial intelligence in charge but we're not there yet.
So instead of the goal of good UX being the designer planning out what is good and bad, it is much better to design a system that reduces cognitive load but presents information about the current state of the system in the most obvious and intuitive way possible. It should do everything it can to make sure the operator understands the current state of the system.
In terms of operating complex physical systems like ships and aircraft the ultimate goal of designing control systems is to simultaneously take as much of the burden off the operator as possible but present all information needed in order to bring the system back to an _understood_ state as rapidly as possible following deviation from that state. This is the only way to maintain _control_.
It's reasonable to try and make it difficult to get to a state that is 'uncontrolled'. But it's imperative that more credence is given to getting a system back to an understood state once the controller finds them self in one that's not understood. It may get to this state in a way the designer didn't plan for, so getting out of it has to be incredibly quick and easy.
Personally, I put more stock in getting the system in an understood state than a controlled one as from there it's easier to return to control. Without understanding the state of the system it's easy to make further mistakes.
Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.
Poor UI design is remarkably common, even on controls that are essential for safe operations.
Amazon: 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...
Jetliners have gangable throttle controls for their engines, albeit with what is probably a much better interface.
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.
I know of a ferry that a local warf built that had two bridges, and a combined throttle and rudder in each.
The thing is that when moving from one bridge to the other, the crew had to flip a switch to indicate what direction was forward. And quite often they forgot.
End result was a long history of damaged because ferry would ram the pier when the crew was actually attempting to move away from it.
EDIT (since some people obviously don’t understand the problem): ... so that each set of controls is always correct for the respective side on which it is located. No switch is necessary.
Eg, if you're facing the dock, and push forward, you'll hit the dock. Take the other side and point your body to sea. Intuitive.
Controls that are active should be illuminated in a particular color, say red.
Controls that are disabled should be extinguished, physically-locked or track active controls, and sound a warning when manipulated.
Airbus uses two "side stick" controllers that are on opposite sides of the cockpit. This was a contributing factor in the Air France 447 crash.
> Decent odds you've flown on an airplane with a similar UX for primary flight controls.
Ah, well Airbus does a few things. 1.) A "dual input" warning is issued if there is an attempt at using both controls simultaneously. 2.) There are lights to indicate when your sidestick is active and when it is not.
For an industry that is so safety conscious, I believe this is a huge flaw in disaster control. To put it in context that most readers here can understand - lets say your everyday computer uses OS X as its operating system, but one day, with deadlines to meet, you have a huge crash, and the OS reverts to Windows, and you have to find the problem and remember the appropriate commands under intense pressure...
The big problem was that the pilot-in-command simply forgot (or did not know) how to fly the plane. He overcorrected in reaction to turbulence and the rest is history. Normal law does not allow the pilot to set an angle of attack that would lead to a stall. In the alternate law modes this protection is not there and so when the PIC didn't adhere to the rule of "don't pull up while in a stall" there was no safety net to prevent him from exacerbating the situation. In fact he kept pulling back when the stall alarm went off.
A better UI would not have solved the self-inflicted problems. From the findings sections in the wiki entry:
- The pilots apparently did not notice that the aircraft had reached its maximum permissible altitude
- The pilots did not read out the available data (vertical velocity, altitude, etc.)
- the crew made inappropriate control inputs that destabilized the flight path;
- the crew failed to follow appropriate procedure for loss of displayed airspeed information;
- the crew lacked understanding of the approach to stall
- the crew lacked practical training in manually handling the aircraft both at high altitude and in the event of anomalies of speed indication
- the two co-pilots' task sharing was weakened both by incomprehension of the situation at the time of autopilot disconnection, and by poor management of the "startle effect", leaving them in an emotionally charged situation
- the crew did not respond to the stall warning
A better cockpit may have given the pilots a better chance of surviving but definitely wouldn't have guaranteed a better outcome. One only needs to look at Asiana to see that even Boeing, with their contrasting approach to UX, can't save pilots who lack basic airmanship. My understanding is that most long-haul pilots will fly a fairly small number of segments each month, and that most of those segments are going to involve a huge amount of time spent in the middle of nowhere with autopilot on. This leads to atrophying of skills needed to manually fly a plane.
Conversely, one only need to look at Qantas' QF32 incident to see that good airmanship can absolutely make catastrophic failure survivable. Yes, there is a lot of information to process in an emergency... but the Qantas crew took that information and delegated appropriately. The Air France pilots lost their cool and fucked up.
The initially-designated co-pilot also was virtually fully occupied simply clearing alerts from the aircraft's control and diagnostics systems -- for about 45 minutes as I recall.
That's a near-deadly case of TMI, I suspect.
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 he acted rationally, etc.), instead of being confused by the situation they were in and unable to get out of, likely without knowing what the PF was doing.
> My understanding is that most long-haul pilots will fly a fairly small number of segments each month, and that most of those segments are going to involve a huge amount of time spent in the middle of nowhere with autopilot on. This leads to atrophying of skills needed to manually fly a plane.
Much flying nowadays is through RVSM (reduced vertical separation minima) airspace, and you're not allowed to hand-fly the aircraft there (in general, modern autopilots can maintain altitude better than a pilot can).
There were a Captain and two co-pilots aboard AF445. The junior co-pilot was PIC for much of the incident.
See also <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.
PF Pilot Flying
PNF Pilot Not Flying
https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
But where does your viewpoint meet up with someone like Chesley Sullenberger who says the pilots would have probably not crashed if the plane was a Boeing rather than an Airbus, because it would have had an angle-of-attack indicator?
This is a fallback in case the primary rudder fails. You can still shift left or right, but you will take more time and it will be far less precise than using the rudder.
This is also valid for aircraft, where not only the rudder can be compensated but also the elevator (aka up/down) by simultaneously modifying the power of all engines. You can see a list at https://en.wikipedia.org/wiki/Flight_with_disabled_controls.
"Retiring" without losing rank doesn't cut it.
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 https://www.amazon.com/Behind-Human-Error-David-Woods/dp/075...
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.
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.
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.
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.
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.
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...
Feeling the control wheel or stick fighting you is far more direct.
AF 447 was absolutely a UX failure.
Check it out here: https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
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#Independ...
2. https://en.wikipedia.org/wiki/Air_France_Flight_447#Sidestic...
>conclusions that could result in the grounding of the entire worldwide Airbus fleet
Concluding that the sidesticks were a contributing factor would not have resulted in the grounding of the fleet. That only happens in the case of extremely severe and extremely immediate threats to safety. UX tweaks would more likely just be included as recommendations. And in fact the report does make some UX recommendations, IIRC.
Yes they don't have all the data, but they have enough to draw this sort of conclusion, including flight path, status of the plane at any given point, and the cockpit transcripts.
And true. Suggesting the fleet would be grounded was hyperbolic on my part. But I stand by my general point. Aside from happened in this accident, you're assuming that anything worthwhile to be learned from a given incident must be covered in the final report, or it must not be worth considering at all.
This expects too much of accident investigators, and doesn't account for the sort of institutional blindness that happens when everyone is used to things being done a certain way. Of course that was pilot error, two disconnected joysticks are just how planes are flown!
This wasn't the first case of an incident being attributed to Airbus's overdesigned flight controls, QF72 [2]. comes to mind.
1. https://www.youtube.com/watch?time_continue=62&v=kERSSRJant0
The fundamental issues with Sullenberger's claim that the accident would be much less likely in an aircraft with conventional controls are (i) that there have been multiple crashes in such aircraft caused by unrecovered recoverable stalls (e.g. Colgan 3407, Turkish 1951) and (ii) that there is pretty good evidence from the transcript that the PNF was aware of the PFs inputs in any case. This forum post has a good summary:
http://www.airliners.net/forum/viewtopic.php?t=772033&start=...
There is considerable informed and expert opinion voiced that the conflicting inputs were a potential issue. A fair bit of that discussed here. There are other instances of conflicted inputs. And despite considering numerous elements of confusion, uncertainty, and information overload, the BEA report doesn't even consider the matter.
This calls into question the report itself, the investigation, and the investigators. Such processes are not perfect and may be subject to political pressures (say: EgyptAir Flight 990).
I've given the basis on which my skepticism is warrented. You've chosen not to accept it.
Cheers.
As for expert opinion, could you give references? All I can find are articles in the popular press where a journalist emailed someone in the know to confirm that yes, indeed, Airbus control columns are not linked -- which is not a point in dispute.
There's a really simple explanation for why the accident report doesn't consider the issue of the control sticks not being linked. It just wasn't a significant factor in the accident, as far as anyone can tell.
If you have evidence of a cover up, you should provide it. The fact that the report did not draw the same conclusions that you would have drawn is not evidence of a cover up.
You've declined to do so.
Look, this is me:
If you're willing to put your real name up here, then we can start speculating on who's being paid by whom to shill for what. Until then, I'll assume that you're on the Boeing payroll...
(I don't in general intend this account to be associated with my real identity, so I may remove the link above in a day or two.)
That said, there might be a more productive discussion, perhaps in future, on linguistics rather than French aviation mishaps.
Second (and as noted in the parallel subthread), the BEA report does not include cockpit transcripts in section 2, 2.1, and relevant subsections, in describing the cockpit situation. It mentions specific utterances of the crew, but not in the specific context and sequence they occurred. Other reports do include these transcripts and from them it's highly probable that multiple inputs were being supplied, or that even if that was not the case it could not be ruled out readily.
There are multiple references in the BEA report of the level of confusion and complexity of the situation. The merits of scheduling the Captain's relief in the ITCZ crossing, the flight path itself relative to other aircraft which had diverted around the region, the loss of instrument readings, autopilot disconnects, multiple audio alerts, the disabling of a master alarm that wasn't clearly deliberate, the stated confusion of both co-pilots, the switching to and from "alternate law" of aircraft controls, and more.
Adding ambiguity of flight controls, feedback, and possible multiple inputs in the context of all of this again strikes me as, well, a disaster that actually happened.
In a description based on the full transcript:
02:11:21 (Robert) On a pourtant les moteurs! Qu'est-ce qui se passe bordel? Je ne comprends pas ce que se passe.
We still have the engines! What the hell is happening? I don't understand what's happening.
Unlike the control yokes of a Boeing jetliner, the side sticks on an Airbus are "asynchronous"—that is, they move independently. "If the person in the right seat is pulling back on the joystick, the person in the left seat doesn't feel it," says Dr. David Esser, a professor of aeronautical science at Embry-Riddle Aeronautical University. "Their stick doesn't move just because the other one does, unlike the old-fashioned mechanical systems like you find in small planes, where if you turn one, the [other] one turns the same way." Robert has no idea that, despite their conversation about descending, Bonin has continued to pull back on the side stick.
http://www.popularmechanics.com/flight/a3115/what-really-hap...
The fundamental issue here is that if only one pilot has his hand on the stick (which should always be true) then linked sticks won't help much, and if both have their hands on the stick (which triggers both audio and visual warnings on the airbus) then they are already fighting over the sticks, indicating a total breakdown of cockpit discipline. The author of the popular mechanics article appears to think that it's normal for both pilots to be holding their sticks at the same time.
It's also worth noting that a half-competent PNF could have looked at (i) the pitch attitude, (ii) the throttle setting and (iii) the rate of descent and concluded that the plane was stalled. The fact that the PNF never managed to integrate these three very basic pieces of information makes it seem rather unlikely that he would have paid close attention to the position of his (hypothetically linked) control stick.
Note that when the PNF took over the controls briefly, he made a lateral input rather than pushing the stick forward! (p. 183)
Finally, sidesticks don't really have "a position". The airbus is usually flown using short movements away from center with the stick then returning to the center.
To have three pilots fail to grasp a situation central to principles of flight, and to have similar situations arise in other aircraft, suggests exogenous factors at play.
You've repeatedly made the case that multiple pilots fighting for control indicates a breakdown of cockpit discipline. You've failed to note that the pilots showed no awareness of such a conflict, or, further, that the stick-back position couldn't be readily identified by anyone other than the pilot applying that input.
You're insinuating that AF had three other-than-half-competent pilots in the cockpit, which raises numerous other concerns.
You're litigating use of the term "position" rather than the general understanding of "force feedback" which applies whether controls have a significant range of motion (traditional mechanical yoke) or a very short throw (sidestick).
In general, you're showing very little charitability to points of view differing from your own, which raises concerns.
I have not been able to find any source other than the popular mechanics article (and its descendants) suggesting that there were extended periods of time where both pilots had their hands on their sticks and were making conflicting inputs.
Accidents almost by definition involve rare confluences of factors. This one seems to have involved two incompetent pilots in the cockpit, and a captain who came in too late to resolve the situation. Pilot error does happen. There have previously been accidents caused by pilot error when three or more people were present in the cockpit.
I'm not "litigating" the use of position. My point is that if you looked at the position of the pilot's stick, it would usually be in the center position, even if the control surfaces were significantly deflected. For example, if you push the stick forward and then let it return to the center, the plane will pitch down, and remain in that attitude until the stick is pushed again. To know the deflection of the control surfaces, you'd have to mentally track "number * length of forward movements - number * length of backward movements".
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-happe...
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.
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-recov...
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.)
(Or rather, the captain realized once he entered the cockpit. Neither of the pilots in the cockpit ever figured it out.)
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.
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.
One possible misconception here is that the copilot would have had his hands on the stick. It isn't normal for both pilots to have their hands on the stick. Only the pilot flying does -- for obvious reasons. At the stage where the problem developed, the copilot's attention, as the report explains, was mostly concerned with trying to interpret the ECAM warnings, and later with calling the captain. The idea that the copilot would have closely observed his own (hypothetically linked) stick and detected the problem, despite being fundamentally confused about what was going on, and having many more things on his plate, is little more than wishful thinking. The possibility cannot be conclusively ruled out, but there is no evidence that this would have happened.
I see that the first link I posted doesn't contain everything, but I don't see any major omissions either.
At 2:11:37.5, Robert takes control of the plane. According to the report, he pushed the stick to the left twice. Bonin then took back control. Figure 69 on page 96 of the report you linked shows Bonin's pitch inputs during this period. He applies near maximum nose-up pitch right as Robert takes control, and keeps it there. Robert would have felt this had the controls been connected, since he was attempting to control the plane at that time. The report says that Bonin quickly took back control, but the transcript indicates no communication regarding this, which makes it likely they were both attempting to control it for at least a brief period. That figure also indicates that at no time was Bonin's stick ever neutral, so it seems that he never stopped trying to fly the plane even when Robert was nominally in control. Without physical feedback, neither one seems to have realized this. No wonder they were confused about what was going on!
For context, all of this is happening at a relatively late stage. Recovery may still have been possible, but the problem developed when the PF was unambiguously in control and the PNF would not have been holding the stick.
According to the report, ~20 seconds after the events I described above, the plane was still above 30,000ft and recovery was still possible. Yes, the problem developed before this, but it sure looks to me that the bad control design was a major factor in the failure to correct the problem.
>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.
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 recorder, and especially in the "unknowingly" phase. The evidence would be in the pilots simultaneously making conflicting control inputs while the airplane was in the dual-control state, and IIRC, the data recorder did show that. Also, according to Langewiesche [1], 'Bonin, using his own priority button, and without saying a word, took control back. This left Robert with a sense that his side-stick had failed. He said, “Fuck, what’s going on?"' - i.e. the nature of the controls introduced additional doubt over what was happening, rather than that it was all a consequence of Bonin's actions (OK, so maybe there is evidence on the CVR.)
A similar situation (sustained, pilot-commanded stall) occurred in the AirAsia flight 8501 crash into the Java Sea.
While I agree that the nature of the side-stick control was far from being the primary cause of either accident, I am not convinced that it has been ruled out as something of a contributory factor.
There is also an entirely different user interface issue here: the stall warnings stopped when Bonin raised the angle of attack beyond a certain point (as the system no longer treated the data as 'plausible') and resumed when he lowered it.
[1] https://www.vanityfair.com/news/business/2014/10/air-france-...
"it" was meant to be that the plane was stalled.
(My fault for ambiguous phrasing.)
You say it's not so clear that this ever really happened, but it's pretty clear to me from the official transcript:
Robert: remonte remonte remonte remonte
Bonin: mais je suis à fond à cabrer depuis tout à l’heure
Captain: non non non ne remonte plus là
Robert: alors descends
Robert: alors donne moi les commandes à moi les commandes
My quick and dirty translation:
Robert: climb, climb, climb, climb
Bonin: but I've had the stick back all the way this whole time
Captain: no, no, no, don't climb anymore
Robert: then descend
Robert: then give me the controls, I have the controls
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.
Before that, yes, Robert didn't realize the plane was stalled. But I would bet that this is partially due to having no idea what Bonin's control inputs were. One of the signs of a stall is stick back. If he didn't think the stick was back, he wouldn't think the plane was stalled.
I guess it's still a bit of random luck that he actually took the controls for a moment here. Like you say, this was already at a late stage.
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 practices. The sticks that everybody's talking about were only one of those elements.
An arguable (if perhaps not politically-acceptable) conclusion is that if the pilots aren't sure who's doing what, the control system engineers and the pilots need to go back to school.
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.
This sounds extremely confusing indeed. Having this kind of inconsistencies under high pressure is something that would need a really experienced and steel-nerve person to handle.
It's made even more confusing by the fact that the usual/sensical pilot approach to guesstimating AoA in an aircraft with a stall warning that is boolean (can only be sounding or quiet, nothing else) is to see where its threshold is. When you're right on the threshold (modulo some hysteresis) where the horn turns on and off, that's your stall angle, and pulling the stick back makes it stall more, pushing it forwards recovers from the stall.
Flipping the sense/polarity of the stall horn's semantics -- the effect of the 60kt invalidation threshold -- certainly contributed to making the upset recovery harder and more confusing.
In an aircraft that has multiple AoA sensors, I (and the BEA concurs) maintain that it is pointlessly cruel and baroque to make the humans try to guess what the AoA value is. AoA is no obscure technical parameter of interest only to avionics engineers, it's amongst the most crucial instrument readings, and it should be presented to pilots right next to their airspeed and attitude indicators.
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.
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?
In the case of warships, specifically, its because normal operations are reduced-complexity training opportunities.
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.
You're telling me a million dollar guided missle destroyer can't do this?
At least you won't have to worry about uncontrolled USN vessels...
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!
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?
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.
Maybe we should treat it differently.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...
Not all errors made by users are the fault of 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-p...
> 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.
What a comedy of errors.
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 ...
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.
http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-wa...
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 />"
- http://firstround.com/review/this-is-how-effective-leaders-m...