USS McCain collision ultimately caused by UI confusion(arstechnica.co.uk)
arstechnica.co.uk
USS McCain collision ultimately caused by UI confusion
https://arstechnica.co.uk/information-technology/2017/11/uss-mccain-collision-ultimately-caused-by-ui-confusion/
362 comments
User interfaces have gone backwards decades in quality.
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.
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.
It's truly awful. The last time I bought a car I wanted to take a hammer and smash the freaking "screen" because the UI was such a POS (VW Beetle). A 20-year-old radio is a better audio system, and the cheapest smartphone is a better navigation system than anything that comes in a car nowadays. But I suppose the manufacturers think they can't sell a car nowadays without "teh shiny screen." And they might be right.
Automotive "climate control" has been around since the mid-60s, and the controls of the early versions were also far more straightforward; basically, one knob for temperature and another for turning the system on/off at various settings. Here's one from 1973:
http://i44.servimg.com/u/f44/16/54/79/13/1973_c12.jpg
http://i44.servimg.com/u/f44/16/54/79/13/1973_c12.jpg
I had no idea that automatic climate control (i.e. user just sets the target temperature) dates back to 1970, because it was not a standard option for low/mid-price cars yet in 90s (at least in Finland). Heck, my parents bought a Toyota Corolla in 2003 with no automatic climate control. Fascinating to see it implemented with old-style analogous controls. Same for 6-way power seat.
Indeed, it was originally only on luxury models --- Cadillac introduced it in 1964.
https://ccco.s3.amazonaws.com/kb_photos/290/2284_1964_Cadill...
https://ccco.s3.amazonaws.com/kb_photos/290/2284_1964_Cadill...
I thought most of YC HN was based out of/lived in a California bubble. Surely the rest of the commenters here have modern cars? I have a VW GLI that has climate control that beats the shit out of any car I've owned before it. There was also another posted complaining about their radio having to ''boot up'' before they could change the audio volume. I've literally never heard of these issues. This is ridiculous.
I know. I'm not saying they invented it. I'm saying that it wasn't a common feature on lower price cars.
That wasn't particularly early. I learned to drive in a used (but perfectly functioning, of course) '91 Lexus LS400. It was the make or break car for the new Lexus marque, and they put serious effort into the experience.
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.
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.
Tesla's console is the embodiment of form over function for UI. It looks beautiful having a flowing button-free cockpit, but I'd rather be able to adjust settings without looking away from the road. Whatever happened to HUDs? It seems like a HUD with a dial on the steering wheel would let you have the best of both worlds.
Don't get me started about TVs. When I grew up our family TV turned on in seconds, and pressing channel up/down reacted in tens of milliseconds.
How long ago? My color CRT TV took a good 10 s or so to warm up the tube before you'd see much/anything. But at least it responded instantly, so you could spend that time walking back to the couch instead of waiting for some stupid menu. Instant and trustworthy response is basically gone from most appliances. I think it's a combination of marketing (has to look high tech) and cost (touch buttons are cheaper than mechanically interlinked toggle buttons.
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.
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.
> 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.
https://en.wikipedia.org/wiki/QuickTime
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.
https://en.wikipedia.org/wiki/QuickTime
mps / mps-youtube :)
We have some recent TVs. They have no buttons. Including power buttons. If you want to turn them on, you need the remote control.
The ones I've seen don't have physical buttons, but have nearly invisible capacitive buttons, at least for power/channel/volume. For most other functions, you do need the remote control.
To be fair, you weren't getting near-instantaneous full HD quality broadcasting with DVR support on your TV back then.
The problem is that there's no reason one couldn't design a TV that had both full HD and zero boot time with instantaneous channel switching. The reason such TVs don't exist is simply engineering laziness.
Mine is almost instantaneous. Except it's a lie because the TV is never actually off. It's "Standby" mode consumes a crap ton of wattage and the manual literally says "unplug it" if you intend to not use it for a long time.
Not to mention the damn spyware that's included with it...
Not to mention the damn spyware that's included with it...
> The reason such TVs don't exist is simply engineering laziness.
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.
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.
> 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.
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.
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.
[deleted]
When you change channels it has to wait for the next key frame before it can display video.
Booting a computer doesn't have to be slow, and that's even more true for embedded computers. But making the boot process fast requires very careful engineering, which is both a rare skill and also not very well supported by management for consumer products companies.
The distance to the satellite has nothing to do with it. You're using big numbers to exaggerate the problem.
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.
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.
Yes, the MPEG-2 decoder in your TV needs to be fast enough to keep up with the transmitted data rate, but that doesn't mean that it has instantaneous stream startup times.
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.
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.
And the way to solve this -- at least for the case of consecutive channel surfing -- is to have multiple decoders and multiple buffers. It's simply precaching.
Eventually you're going to run into RF limits, especially if the signal is coming in over the air.
You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?
You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?
I'd pay extra for it. I'd pay even more for a TV that didn't spy on me and that couldn't update its firmware without my consent. But I'm probably not the target consumer.
> 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.
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.
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.
Exactly. Just having two decoders instead of one would drastically improve the 80% use case of consecutive channel surfing.
Some TVs including Samsungs have dual tuners.
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.
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.
Fair enough, but you were getting useful fallback, the image quality progressively degrading, and even with almost no image, the audio was still intelligible. With digital boradcast, it's all-or-nothing: all is fine, all is fine, until the error correction can no longer save you...and you get soundless picture, with block artifacts. Very useful for emergency broadcasts, when anything unicast will be overloaded as well.
Wish I could get that...
Y'know how they say "don't touch that dial"? When I grew up, TVs actually still had dials you had to turn. The tuner responded instantaneously when you changed the channel. Now get off my lawn you damn kids.
Of course it did, you were directly manipulating the a resistor in its circuit. Getting the channel just right...and keeping it there...that was, of course, the flipside.
>So you may start the car and have 5-10 seconds of blasting radio that you can do nothing about.
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.
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.
Microwave oven UI's are terrible but they weren't always that way. My old Amana had 5 controls: a knob for intensity (never changed it) and a knob for the timer, plus start, stop and light buttons. When the the start button broke we just jammed it in the "on" position with a penny making the UI even simpler: put the food in, and turn the knob for the time.
https://www.ebay.com/itm/Vintage-Cookmatic-Radarange-Made-by...
https://www.ebay.com/itm/Vintage-Cookmatic-Radarange-Made-by...
I don't have the same feeling. Different brands have different UI's, and some are as simple as "Press then numbered button for how many minutes of full power cooking you want"
Unless you want more than 10 minutes, then you have to press a different button and then type in the time. Fortunately, there are only something like 20 buttons...a big improvement over a knob and a button that is immediately usable by anyone.
What do you cook in the microwave for that long? You could also look at much cheaper brands/models. I find that cheaper products seem to be keeping older UIs and therefor staying more functional
I was mistaken, my microwave makes you press somewhat hidden button if you want cook something longer than 6 minutes, not 10.
Thanks for pointing this out.
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.
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.
[deleted]
Splitting command is still useful when maintaining control takes constant effort. If there needs to be a human in the loop maintaining and adjusting speed or heading, rather than using a 'cruise control' and letting an automated control loop maintain that setting, then it does make some sense to let different people handle it so that the person actually in charge can focus on what they need to do rather than the minutiae of that controller.
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.
[1] https://youtu.be/bAXA0mIXGmU
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.
[1] https://youtu.be/bAXA0mIXGmU
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?
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?
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.
On a modern diesel or gas turbine ship, no there's not. Obviously there are limits to what the engine can do still.
On a modern diesel or gas turbine ship, no there's not. Obviously there are limits to what the engine can do still.
On a nuclear powered ship, yes, since you still essentially have a steam engine
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...
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...
The nuclear part isn’t just used to generate electricity for the motors?
If https://www.defensetech.org/2013/09/27/ohio-class-subs-to-sh... is correct, then at least the Ohio class submarine drives the motor directly off the turbines, but the thing being designed to replace it will use electric motors. And actually, https://en.wikipedia.org/wiki/Columbia-class_submarine#Elect... talks about the same, but with some comments about the few submarine types that do this so far. And following the link to https://en.wikipedia.org/wiki/Integrated_electric_propulsion gives us https://en.wikipedia.org/wiki/Integrated_electric_propulsion...
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.
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.
The heat from the nuclear reaction in a nuclear power plant is typically just used to boil water, which turns turbines, which creates the electricity.
Does this electricity charge a battery pack, which then is used to drive the electric motors which turn the screws? This would imply that the heat generation and turbine spin-up time merely need to respond before the batteries are discharged, potentially allowing response times of minutes or hours. It would give Tesla-like instant throttle response, where the operator would move the lever and the sub would jump forward.
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/
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/
It looks like warships with electric drive are _just_ starting to go into production. See https://en.wikipedia.org/wiki/Integrated_electric_propulsion... and https://en.wikipedia.org/wiki/Columbia-class_submarine#Elect... for some background.
Both the Ohio and Los Angeles class submarines use mechanical linkage propulsion, not electric, if I understand correctly.
Both the Ohio and Los Angeles class submarines use mechanical linkage propulsion, not electric, if I understand correctly.
Your entire comment is wrong, and toomanybeersies is right.
Source: https://www.defensetech.org/2013/09/27/ohio-class-subs-to-sh...
Source: https://www.defensetech.org/2013/09/27/ohio-class-subs-to-sh...
The nuclear power plant is heating water to generate steam.
Which presumably drives a turbine to make electric which can run motors, charge batteries, run scrubbers, run heaters, etc., presumably.
They're not direct driving the screw with steam power from the reactor heat-exchange, surely.
They're not direct driving the screw with steam power from the reactor heat-exchange, surely.
It's hard to find anything like a schematic of a Nimitz-class carrier for obvious reasons, but as far as I can tell yes, it's all directly steam powered. The reactor boils (sea)water, which is used to power 4 steam turbines[1][2][3], those turbines drive the propellers.
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_...
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_...
I love the way they did the electromagnetic catapult.
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.
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.
some nuclear submarines are not steam powered directly, they use electric engines.
Very few, if https://en.wikipedia.org/wiki/Integrated_electric_propulsion... and https://en.wikipedia.org/wiki/Columbia-class_submarine#Elect... are to be believed. The latter claims that as of 2013 there is exactly one nuclear submarine class (https://en.wikipedia.org/wiki/Triomphant-class_submarine to be exact) that uses electric engines.
> They're not direct driving the screw with steam power from the reactor heat-exchange, surely.
Yes, they are, for the simple reason that it's more efficient. This is beginning to give way to a series electrical design, but that's for reasons of increased stealth and other concerns, at the cost of overall thermodynamic efficiency.
On all existing nuclear carriers steam is used for the catapults (and this is much more demanding than many people are aware of). The Ford class is developing electromagnetic catapults, which are also proving to be demanding to perfect.
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.
[deleted]
> Valve linkages had immediate effect on the output, but you also had to adjust the boiler heat input to keep the temperature within limits.
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?
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?
I think their point is that when changing engine output is labor-intensive, it made perfect sense to have an officer giving orders and somebody else implementing them. Why the command structure hasn't shifted to accommodate modern technology is an interesting question
It's not labor-intensive, it's attention-intensive.
You want the person managing the speed to be focused on that. You want the person managing the heading to be focused on that. And you definitely don't want the officer to be distracted by maintaining course and speed when they need to be keeping track of what's going on around the ship.
You want the person managing the speed to be focused on that if managing speed is still inherently and unavoidably attention-intensive - if modern control technology is able to automagically maintain speed at x knots, adjusting all the various engine control parameters to implement that, then an extra person in the loop only means an extra chance for mistakes or delays.
If the military learned a lesson from exploding a reactor with an automatic control system, you might never know - it's not required to be reported to the public.
If an automatic control system can blow up a reactor so can the manual one. You have a problematic design issue in both cases. You can also still assign someone to keep an eye on the reactor in case things go bad an have that person pull an emergency stop or warn the guy in charge. There is no reason to relay every little speed change through several people.
[deleted]
This would mean wasting fuel, no?
What's that got to do with anything?
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 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?
A basic of driving a steam engine is not to waste steam, since steam represents fuel, which in turn represents money. As you say, not having an accident is more important than wasting a bit of fuel (hence safety valves on steam boilers), but in everyday operation wasting fuel is a cardinal sin and something that is to be avoided. At one point I was involved in steam rail preservation, and the old-timers used to mourn the loss of engine driving/firing skills whenever engines sat at the platform with the safety valves blowing.
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.
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.
> Are you going to choose to crash into something because it's wasting fuel to vent part of the steam?
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.
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.
At sea, efficiency gets you back to land.
I think if the same volume of steam is being produced then it's going to cause problems regardless
> Or is there something more complicated about controlling engine power than I imagine?
Large marine diesels such as used by container ships do need to follow a procedure to change out of the cruise rpm. I don't know how much that can be skipped/abbreviated in case of an impending collision, but I do know that generally it takes more than just someone on the bridge changing a control setting.
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.
Yes, steam demand controls the power response of a nuclear reactor.
It makes some sense to me. Conning officer instructs helmsman which direction to go. Helmsman then executes that and monitors/adjusts to stay on that heading without further attention. Same for speed. The officer is then free of the tasks of monitoring and adjusting speed and direction and can focus on what's happening outside of that.
Looking for good models for ops team improvement, I was just handed the Watch Officer's Handbook. It encourages new watch officers to give rudder orders, not desired headings.
Depends on the context.
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.
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.
Thank you. That's precisely why things are this way.
Source: me, Navy veteran
What about the question regarding having one guy doing direction, and another guy doing speed? Is that called for?
Absolutely.
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.
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.
As an outsider (well, I have plenty of experience with pleasure boats/yachts, but none with large ships) it seems really extraordinary that just maintaining a heading would be a full time job.
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.
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.
Navy sub vet and almost licensed as a pilot:
The small aircraft case - one mind, one set of hands, to reduce the feedback loop to fractions of a second overall. Things other than throttle/ailerons/elevators get timeshared in when all else is stable momentarily.
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.
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.
I understand that keeping on a desired course is not a simple task and requires prediction and understanding of the surrounding waters... But you can say the same thing about crosswinds and thermal layers and pockets of turbulence in the air over a runway, and autopilots land 747s every day. In a far more computationally intensive and less recoverable domain, with more complex system dynamics and controls even discounting the extra dimension, plus sensing that's both more limited and harder to interpret. If modern controls theory can land an aircraft, I'd expect it to be able to run a ship along a trajectory like it's nailed to a rail in space-time.
TL/DR: I have to boil this down to a gut feel, but I'd rather fly a known takeoff/landing profile at any airport, than take a n-thousand ton vessel through a port departure/arrival, simply because the overall situation in the air is so much simpler.
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.
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.
I'm not advocating full autopilot; I agree that safe trajectories can be harder to plan in dense 2d than in sparse 3d, and that military ships in particular often have high-level objectives that would be extremely difficult to formalize for input into a planner.
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.
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.
Well said, that gives me a perfect frame to say that the inherent complication in handling the ship's trajectory is how rapidly the trajectory may need to completely change, contrasted against the reaction time of the vessel itself.
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 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'.
Aircraft, even big ones, are still far more maneuverable than large navy vessels. That extra Z dimension gives you more space to work through problems, even if it adds complexity.
Fewer obstacles maybe? Also, with a fast plane you either land or take off, or do stuff in practically free space.
Also there is the example of infantry tank. There is the driver who has speed and direction. Then there is the commander who gives orders but apparently has backup system to drive if the driver is incapacitated.
A ship just can't have as much obstacles as tank negotiating battlefield.
A ship just can't have as much obstacles as tank negotiating battlefield.
> the example of infantry tank. There is the driver who has speed and direction. Then there is the commander who gives orders but apparently has backup system to drive
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.
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.
"Infantry tank" was my mistake. Those things only existed around WWII. Regardless any modern tank, infantry fighting vehicle etc. has single man controlling both speed and direction.
And in 3 dimensions (which a sub does too, but not a ship)
[deleted]
It may be on a US Navy warship, that absolutely isn't the case for other blue water navies. If anything I would suggest that having too many people involved adds confusion. The OOW has repeaters of the course and speed so that they can verify their orders are being followed, they are the check.
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.
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.
Especially if it's so easy to get off course, and since the responsibility lies with another officer anyway, steering sounds like a job better suited for a computer, rather than a person. As far as I know, airline pilots already dial in most navigational course changes to the autopilot, I would have imagined ships to work similarly.
That seems obvious today, but the McCain was laid down in 1991. Computers were much less sophisticated back then.
I wonder if there is enough information publicly available to compare the workflows on the McCain to the same workflows on the Zumwalt.
I wonder if there is enough information publicly available to compare the workflows on the McCain to the same workflows on the Zumwalt.
What I don't get is that obviously on a military vessel the chance of someone getting injured or incapacitated are rather high - so why would you want critical things like speed to be controlled by a separate person from the one steering? If they get knocked out and the controls for speed/direction/depth are in a physically different location, doesn't that result in a complete loss of control?
On the flip side, if there is an event that incapacitates one person it might not affect all 3 so you still have some control during and right after the event instead of waiting for someone to make their way to the control station
You could have 3 sets of full controls and personnel, that's more redundancy; you need lockout and takeover abilities.
That's how Star Trek do it!
That's how Star Trek do it!
Reading the raw accident report, I draw the opposite conclusion. The sequence of events that led to the accident started with one person controlling both steering & throttle. The reason for splitting responsibility is that the original helmsman was overwhelmed by the number of actions required to control both.
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.
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.
To be fair, split throttles is not a sane or intuitive default.
> 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.
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.
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.
As a devil's…inquisitor, I guess— I'm curious what the reasoning has been behind the Navy's (and WWII RAF's) preference for split/seniority control and in what situations that balances out, if any. Are those situations where some known, serious risk of error is mitigated by sharing responsibility? Is betting on experience over skill actually wrong, or is their implementation misguided? Or just not applicable to those situations? (Fast situational awareness, etc)
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 seems similar to the whole democracy v. autocracy tradeoff. One optimizing for coverage of perspective, the other optimizing for efficiency of a perspective.
Article says:
> 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.
> 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.
Part of the reason might be the variety of warship designs and handling characteristics compared to civilian ships. I would think it'd make it easier for Officers to transfer between various ships.
I do think the Navy has difficulty delegating and tends to try and focus power on a few positions.
I do think the Navy has difficulty delegating and tends to try and focus power on a few positions.
I'm sure there's a good reason for the "tradition". Similar to a group of monastic monks following some bizarre ritual which could be done in a more efficient way. Someone from westpoint or the naval academy probably knows..
I’d say it’s the same reason why manual transmission vehicles are still more popular than automatic transmission in some countries. Automatic transmission of modern cars is easier (you can give more attention to the road than having to think about changing gears), gives a smoother ride, is more fuel efficient and causes less wear and tear on the engine.
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)
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)
I drive a manual transmission car every day and I'm bemused by your reference to "having to think about changing gears". For an experienced and competent driver, registering and acting upon the need to move up or down a gear usually requires no conscious thought whatsoever. The mechanical process itself literally takes a split second.
By contrast, in my one experience with an automatic transmission, it proved to be a constant distraction from the business of steering the car and enjoying the drive. That was because it was never in what I considered the appropriate gear, refusing to change up in a proportionate manner as I accelerated, or to change down quickly enough on upward inclines. It was teeth-grindingly irritating.
Admittedly, that was 10 or 11 years ago, and perhaps the state of the art has improved since then.
Certainly it has. Having converted to automatic transmission recently, shifting is one less thing to keep in the back of your mind (even if it was second nature to me, after many years of driving stick). With the kickdown button, you don't even have to worry about getting enough power in emergency situations ("have I downshifted low enough?").
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).
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 agree it's not something you really think about (I used to think automatic was for lazy people), but when you don't have to think about it, it's a load off your mind. This is exactly my point though - it's a habit that people are used to, and don't see why (or don't want to know why) changing it might be beneficial.
Automatics are usually less efficient than manuals - the Hydraulic torque converter has to slip to function.
That said, the automatic might beat a manual in other metrics.
That said, the automatic might beat a manual in other metrics.
A modern dual-clutch automatic* switches gears so swiftly and seamlessly that there is no feeling of clutching going on at all, if not for the motor tune or the RPM indicator you wouldn't know it's changing gears. If you disregard either it almost feels as-if the car is going from 0 to 180 in one gear.
* 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.
* 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.
Torque converts are the niche choice nowadays, a lot of modern cars have dual-clutch transmissions which are always more efficient than manuals. They use less fuel, shift quicker and commonly have more gears for less strain and better efficiency(almost all new MB cars ship with 9-gear dual clutch tranmissions nowadays for example).
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.
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.
I had the reverse experience of you, that is, I always drove automatics and then learned to drive manual later on. I actually felt I was more focused on the road in the manual because I needed to plan ahead for gear shifts. In an automatic everything is taken care of so it's easier for the mind to wander. I thought I was a better driver in the manual. I guess if I drove a manual for years it would probably go on mental autopilot more.
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.
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.
Modern automatics are almost always more efficient. The biggest is that the torque converter has a lockup clutch during crusing, and often more gears and a near perfect knowledge of when to shift gear.
Do they break more often too? Like TCO is higher?
Automatics in UK certainly cost more, if one doesn't ride the clutch I imagine the manual will have lower maintenance costs?
Automatics in UK certainly cost more, if one doesn't ride the clutch I imagine the manual will have lower maintenance costs?
Manual has lower maintenance costs regardless. A clutch plate is about $500, an automatic transmission is between $1500 and $4000. Manual doesn't require its fluid to be changed.
I would be interested in seeing additional sources that support the theory that political machinations, not practical concerns, decided how many pilots a modern warship requires.
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...
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...
>>> The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers.
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.
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.
(An amusing note on ferry control. In San Francisco, at the Hyde Street Pier, there is a large steam powered car ferry boat, the Eureka, from 1890. That boat is powered by a double-acting one-cylinder engine driving both side paddlewheels. It's reversible, with some difficulty. It cannot get itself started at top dead center or bottom dead center. So there's a giant pry bar, about eight feet long, which can be used to get it started. You can see this hanging on a bulkhead near the engine.
Think about operating this turkey. This car ferry docks nose into the dock, not parallel to it. You're coming into the dock, and have to stop and reverse the engine to slow. If the stopping and reversing operation results in the engine stopped at dead center, there's no power until the crew frantically gets the pry bar and levers the engine into a position where a power stroke is possible. Screw up and you crash into the dock. It's a ferry boat, so it docks a dozen times a day.
Now that's a control problem.
The Eureka is the last surviving example of this design. Other paddlewheel ferries were built, but usually with multiple engines or multiple cylinders.)
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.)
So do other navies have a single person steering their ships like you advocate?
Do you have references for the Submarine story? The submarines I've seen have a rudder, stern plane, and another on the sail. With mechanical controls, I imagine it's difficult to have one person control all three of those movements. Two people controlling three movements seems right.
The Albacore museum has a virtual tour, it shows 2 seats:
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.
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.
See [1], the section on "The Pilot".
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.
[1] http://www.ussalbacore.org/html/albacore_story.html
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.
[1] http://www.ussalbacore.org/html/albacore_story.html
It looks like steering was controlled by one person. Unfortunately it lacks further detail. I saved the link to read later. Thank you.
[deleted]
thanks for this comment!
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.
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.
I think this whole text, but especially the paragraph about British WWII is a good example of what "Military Intelligence" is about
Split command also provides plausible deniability.
“No, we did not deliberately ram a ship suspected of smuggling contraband to North Korea, that would be illegal.”
“No, we did not deliberately ram a ship suspected of smuggling contraband to North Korea, that would be illegal.”
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 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...
Amazon: https://www.amazon.com/Field-Guide-Understanding-Human-Error...
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...
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?arti...
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...
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.
Normally that is called "tunnel vision".
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.
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.
> I've never heard the tunnel analogy. Seems odd, since tunnels generally only have one entrance and one exit...
Road and train tunnels have many emergency exits...
Road and train tunnels have many emergency exits...
Generally they have a parallel tunnel (either for traffic in the other direction, or specifically for emergency egress), and connections between them. They still take you to the same general place.
I think the idea is that if you are stuck in a dark train tunnel and there's a train coming towards you, there may be doorways, recesses, etc in the walls that are invisible without the proper tools (flashlight, etc).
[deleted]
Urban tunnels have many regular entries and exits, as well as emergency exits, not to speak of emergency crossovers.
I prefer the swiss cheese model.
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.
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.
Yup! My cousin & cousin-in-law work to maintain human health at some nuclear power plants in Canada. They use the swiss-cheese model, and whenever they notice that one layer missed something, they do a re-evaulation of that safety layer.
Aha! I sense an opportunity for an enterprising statistical physicist to model this with https://en.wikipedia.org/wiki/Percolation_theory :)
As we say when teaching new riders to ride a motorcycle, a crash is often an intersection of factors. If you remove even one of those issues it likely would have prevented it.
I've noticed a lot of learners (eg in YouTube videos) crash because they grab at the handlebars, grabbing the throttle and inadvertently accelerating.
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.)
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.)
Are you recommending the 2nd edition specifically?
There is a 3rd edition available: https://www.amazon.com/Field-Guide-Understanding-Human-Error...
No, I just didn't notice (speaking of confusing UI, Amazon seems to do everything possible to move UI elements small and large on a basis so arbitrary as to seem completely random)
A number of the worlds largest ferries - 50% longer than USS McCain - are routinely navigating in very restricted and crowded waters in the archipelagos of Stockholm and Helsinki with a clearing under the keel of just a few meters.
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.
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.
The article says they fairly quickly tried to reduce speed once they noticed something was wrong. But due to a (UI?) mistake they only reduced speed for 1 engine. It wasn't until 3 minutes later they finally fixed that mistake but by then it was too late.
So they were unable to understand their own speed controls.
So they were unable to understand their own speed controls.
I’m sorry for bringing this up here, but why do I need to scroll sideways in Safari on iphone on Hacker News every time there is a quote written in an unproportional font? Just, why?
Because he used block quote syntax. It's designed for code on HN's implementation, so it preserves newlines, instead making you scroll.
It's a poor choice for quoting non computer languages.
It's a poor choice for quoting non computer languages.
People wouldn't use it if a better option was available. Lots of people are familiar with Markdown, which lets you start a line with > to have it quoted, but HN does nothing with this syntax so it looks ugly and as a consequence people don't do it.
More importantly, in mobile the code block's width is only 200 pixels.
Seriously this. Not wrapping text doesn't also mean fixed width 200px viewport.
The problem isn't "because they used codeblock" the problem is codeblock is broken.
The problem isn't "because they used codeblock" the problem is codeblock is broken.
Does anyone know a HN web interface (like hckrnews.com) that prettifies such quirks on the comment page for mobile phones?
https://app.hackerwebapp.com is rather nice, although read-only. Tapping a link if you want to comment is acceptable to me, though I'd love to have voting on there.
Because the markup for those blocks isn't intended for general-purpose quotations; it's <code> blocks. You don't word-wrap code.
Pretty sure merely not wrapping doesn't imply quite as horrible a UI as we have there.
Leave it to HN to uncover the real cause.
I completely agree, it seems like the speed was entirely excessive, and they literally lost control of their boat. Shameful.
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.
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.
When will the first ship crash because of a BSOD? You think I am joking? No, unfortunately several types run on general purpose OS, and the possibility is there.
http://www.popularmechanics.com/military/navy-ships/news/a27...
http://www.popularmechanics.com/military/navy-ships/news/a27...
> The USS McCain was traveling at over 20 knots at the time of the collision
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.
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.
http://s3.amazonaws.com/CHINFO/USS+Fitzgerald+and+USS+John+S...
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.
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.
Sounds like some kind of cowboy culture. "Hey, we have this fast and maneuverable ship moving along these lumbering civilians. We can handle it, we're the best of the best!".
A bit like those organ donors, err.. motorcycle drivers, that swerve among the traffic at high speed.
A bit like those organ donors, err.. motorcycle drivers, that swerve among the traffic at high speed.
This to me is the under reported fact. Realizing how fast these ships were moving up to and through the moment of impact, while the crew responded hopelessly is extraordinary. Absolutely tragic.
Sure, don't believe your lying eyes. Point out a single scratch that indicates anything other thana 90 degree impact with a stationary vessel.
If you read the report that is linked above, you can see the relative speeds, headings and impact geometry.
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.
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.
When a car gets t-boned at an intersection, do you always assume it was stationary? Please point out what aspects of the damage has speedometer-like qualities that your eyes are seeing.
There will be, by physical necessity, surface damage reflecting the forward motion of the penetrated vessel.
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.
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.
[deleted]
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/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.
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.
Air France 477 was caused by UI stupidity, too.
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.
https://en.m.wikipedia.org/wiki/Air_France_Flight_447
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.
https://en.m.wikipedia.org/wiki/Air_France_Flight_447
That's a very simplistic interpretation. The article is really worth a read.
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.
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.
Losing airspeed indicators can be a minor problem, but not in a jet at altitude at night, which was the case for AF477. You can fly a small plane without an ASI, particular in visual conditions, because the margin for error is large and you have other visual and auditory cues to tell you whether you're in the ballpark. But Jets at altitude fly in a very narrow envelope between stalling and over-stressing the airframe (look up "coffin corner"), and in instrument conditions you have no way to tell whether you're in the zone or not. Furthermore, without reliable airpseed, the autopilot stops working properly. AF477 was not just a case of the crew being stupid or bad UI. It really was a very serious situation aerodynamically.
Agreed, I was just paraphrasing from old memory. Only intended to get people interested in further reading. :)
nice! Also an SR22 pilot (though I just sold mine a few months ago).
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.
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.
Wow that UI is truly terrible. It's like they said "we need all this information on the screen" and then just dumped it anywhere. Who knew Microsoft Flight Simulator 2.0 was so accurate?
MSFS is amazing. So is X-plane. The latter has aerodynamic models accurate enough to simulate flight on other planets!
https://what-if.xkcd.com/30/
https://what-if.xkcd.com/30/
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.
Most of the colors on that display have a rationale. For example, on the speed tape on the left, the white, green, and yellow colors all map to colors of a standard airspeed indicator. That the course (CRS) is green instantly tells me I'm navigating by a ground-based VOR, not GPS (which would be magenta). Same with the green diamond on the right by the altitude indicator. The waypoints at the top are all GPS-calculated, therefore also magenta. At the top, the green radio frequency is the one you'll transmit on. The blue airport icons in the Nearest page (bottom left) indicate towered airports (matching those found on standard aeronautical charts).
(In case it's not obvious, I've got a few hundred hours behind the G1000. AMA.)
(In case it's not obvious, I've got a few hundred hours behind the G1000. AMA.)
Do you have any opinion on the G1000 (and subsequent Garmin flight decks) vs competitors, such as Avidyne Entegra?
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.
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.
I'm not familiar with the Entegra. I've played with stuff by Dynon and Advanced Flight Systems though. If you think the G1000 is clunky, try the Advanced system. I'm really not a fan. Perhaps it's for that exact reason (that Garmin products all work somewhat similarly), but I've been up in a friend's RV-10 with the Advanced system in it, and I find it to be much more clunky.
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.
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.
I think there's some truth to your GNS 530 theory... Pilots are not typically that interested in stylish/modern UIs, and they're not thrilled when a familiar UI changes. There are so many features now that it's a challenge to find room on the PFD. I'm curious, which other UIs do you prefer? What do you think of the G1000 NXi?
> which other UIs do you prefer
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.
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.
[deleted]
yes, thanks for your reply. It's why I asked my question that way (Chesteron's fence etc).
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.
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.
A little late getting back to this (was away from HN this weekend), but some things do use color changes and background changes to alert the user. There's also audio tones for various things, like the autopilot being disabled (regardless of whether the computer or user disabled it). The actual sounds depend on the features installed; a GFC700 autopilot has different sounds and alerts than a KAP140.
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.
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.
The colours have significance. There's a famous talk by a AA training captain, Capt. Warren VanderBurgh, about the dangers of over reliance on automation, and it's called "Children of the Magenta" (magenta being the colour with which the computer generated navigation guidance is displayed).
https://www.youtube.com/watch?v=pN41LvuSz10
https://99percentinvisible.org/episode/children-of-the-magen...
https://www.youtube.com/watch?v=pN41LvuSz10
https://99percentinvisible.org/episode/children-of-the-magen...
While the "AP" indicator is very important, such that overlooking it, or rather missing its absence, could lead to loss of control and death, the same holds for many other of the items displayed.
That's actually a great point: "missing an absence" is far harder than "noting a presence of opposite indicator".
> the same holds for many other of the items displayed
Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.
Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.
I didn't (and wouldn't necessarily) claim the same ratio.
But clearly airspeed is critically important, attitude is, a wrong heading can kill you (eg Varig 254 [0]), a transponder that's off can kill you (eg the Embraer/GOL accident [1]), wrong altitude can clearly kill you, etc.
But you've got a point, it's a pretty small indicator for a pretty crucial function. However, making everything else monochrome doesn't strike me as a realistic or preferable alternative.
[0] https://en.wikipedia.org/wiki/Varig_Flight_254
[1] https://en.wikipedia.org/wiki/Gol_Transportes_Aéreos_Flight_...
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_...
> airspeed is critically important, attitude is, a wrong heading can kill you
Losing track of airspeed/attitude/heading is a whole different category of error than losing track of which mode the autopilot is in.
> a transponder that's off can kill you
Not without a whole pile of other errors stacked on top of that one.
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.
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-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.)
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.)
"managing the avionics is almost more difficult than flying the plane" The same goes for modern cars. The electronics is a nightmare. HVAC controls locked away behind touch screens menus. It's awful.
Oh, so much this! The whole UI world seems to have jumped the shark about 2-3 years ago. I dread the day when my current car (a 2012 model) dies because everything on the market today sucks UI beans. (Actually, the same goes for phones and laptops too. I have an iPhone 4S running a jailbroken iOS 7 and a late 2013 Macbook Pro Retina running Mavericks, both of which I am going to hang on to until either they or I die.)
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.
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.
"Militaries are good at making horrible UI."
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.
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.
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.
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.
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.
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.
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.
Yeah, it's boggling how it went down. That's why I can't credit "UI" a cause, not at all. I'm no seaman, but I have some close contacts. UI might cover a BM taking a second before he realized the controls weren't ganged. Maybe.
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.
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.
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?
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?
ST = shit together
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.
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.
I don't know which one is more bizzare here - the story itself, or the barrage of "this is due to bad UX" comments in this thread.
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"
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"
The problem is that you can't "fix" humans. They'll make mistakes. Aviation is as safe as it is precisely because it moved past the "pilot error! that guy just made a mistake, how can one be so stupid" attitude evinced in your comment.
You have to look at the entire accident chain, and at the entire system, including training, supervision, redundancy, and, indeed, UX.
You have to look at the entire accident chain, and at the entire system, including training, supervision, redundancy, and, indeed, UX.
Good UI makes the effort of doing the 'right thing' very little, and the effort of doing the 'bad thing' as costly as possible.
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.
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.
> 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.
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.
I think that's the real point. The ship in question is by far not the largest and should be more agile than most ships that go through these waters. How can ferries and tankers easily master this every day and the Navy is not? If they cannot figure out how to solve a situation like this within 2 minutes, how would they react to enemy fire or being attacked by another ship?
Seamanship in the USN has been on a downward slope for over a decade due to changes in training methodology. Qualification standards have slipped, and I'm sure that officers have slipped through the cracks who in previous generations would have had to recycle through the training programs. The 7th Fleet has huge issues right now.
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.
Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.
> Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.
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.
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.
Happens more often than we like.
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.
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.
That is super dumb and dangerous. They should just flip the inputs on one end.
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.
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.
Even better, make the stations operable from either side. Then the yokes always orient in reality, and it's just the frame of reference of the pilot that changes.
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.
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.
No, they just have a big button by each wheel marked "MAKE THIS THE BOW".
When would you ever not press that button?
You’re bikeshedding on a switch versus a button, still an extra, unnecessary step to forget. Same problem. You failed. Try again.
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
Poor UI design is remarkably common, even on controls that are essential for safe operations.
http://www.tragicdesign.com
Also the classic Field Guide to Understanding Human Error.
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...
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...
In my view, on screen UI instead of physical controls is a big factor. If the throttles had been levers it would be instantly discernable if one or both were being moved. This is also why I dislike touch screen controls in cars. I want levers and knobs that give tactile, physical feedback.
Agreed on this. The more important controls should be operable by a suited astronaut, and should also try to express the current 'feedback' of the system state.
Decent odds you've flown on an airplane with a similar UX for primary flight controls.
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.
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.
> > 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.
> 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.
> 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.
I believe the warning can change depending on which of the 3 flight modes the aircraft is in at the time. Big contribution to AF447's demise was that the aircraft was in 'alternate flight' mode and the crew assumed it was still in 'normal flight' mode and made a lot of their judgement calls accordingly.
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...
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...
I'd argue it's more like getting dropped into single user mode. No friendly GUI, but the underlying systems are the same. The flaw with any sort of safety net is that you get used to it and forget the basics of aviation.
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 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 big problem was that the pilot-in-command simply forgot (or did not know) how to fly the plane.
The pilot flying wasn't the pilot-in-command. Half the problem was the PIC was out of the cockpit at the time and the lack of any clear command structure between the two first officers in the cockpit. You can also argue that it may have been recoverable if the PIC took over as PF when he returned to the cockpit (had 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).
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).
"PIC", pilot in control, refers to the pilot actually flying the plane. Not the command or seniority structure amongst pilots.
There were a Captain and two co-pilots aboard AF445. The junior co-pilot was PIC for much of the incident.
There were a Captain and two co-pilots aboard AF445. The junior co-pilot was PIC for much of the incident.
PIC is in command, not in control. In plenty of short-haul flights, the FO can be PF, but they aren't competent to be PIC.
See also <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.
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.
My error. I was getting confused on the BAE terminology:
PF Pilot Flying
PNF Pilot Not Flying
https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
PF Pilot Flying
PNF Pilot Not Flying
https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
Good points all around. Obviously it's up to the human beings to do the best they can in the face of limited information and control.
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?
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?
QF32 had 5 (!) rated pilots in the cockpit and managed to communicate and delegate effectively. That's truly an amazing accomplishment.
Right, I was thinking of making the same point.
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 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.
And as the Air France 447 cockpit voice recordings demonstrated, those are not sufficiently obvious in all circumstances (particularly in high stress situations when you're already several steps down the path to disaster).
Redundant affordances are needed:
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.
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.
I can imagine the requirements doc that led to that, where some Pentagon wonk was thinking "What happens if the helmsman is shot? If there's engine damage? If the helmsman is shot and there's engine damage?" and wrote all of those cases in, and completely forgot about the case where the bridge crew gets super confused because they triggered an edge case in the software and have no idea how to regain control of the ship.
Well, it's a warship. In their defense, they really have to plan for people dying and part of the ship being destroyed.
But if it leads to them not being able to steer through a busy area in peacetime where thousands of ships go through every day (many larger than this destroyer), this clearly failed. With this happening I'm not sure if they would've reacted better if they had suddenly been under enemy attack. Would they've been less confused then?
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.
Jetliners have gangable throttle controls for their engines, albeit with what is probably a much better interface.
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.
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.
[deleted]
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.
"Retiring" without losing rank doesn't cut it.
> 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 https://www.amazon.com/Behind-Human-Error-David-Woods/dp/075...
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...
From what I hear the Navy has been very diligent about accountability. There are problems you can't really hard-ass yourself out of.
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!
"Preventable" doesn't mean "preventable by harsher discipline".
Haha this has got to be a reference to theWarOnDrugs...
Not intentionally. But now that you mention it...
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.
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.
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.
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.
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.
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.
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.
These are all multi-purpose consoles - the trackballs are general-purpose input devices at what looks kind of like a desktop computer setup. The helm station has special-purpose steering input devices, but it just so happens that all the things those special input devices control can be controlled also by the general-purpose desktop setups at other stations.
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.
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.
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.
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.
>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...
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...
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.)
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.)
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.)
(Or rather, the captain realized once he entered the cockpit. Neither of the pilots in the cockpit ever figured it out.)
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.
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.
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.
This transcript: 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.
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.
That is an article in popular mechanics that contains a few excerpts from the transcript selected in order to make a particular point. The accident report gives a detailed description of the behavior of both pilots before the copilot entered (2.1.2.3).
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.
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 believe this is the official transcript: https://www.bea.aero/uploads/tx_elyextendttnews/annexe.01_04...
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!
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!
Figure 69 shows Bonin's stick inputs before Robert took control (and a few seconds after). As explained on p. 182 of the report, Robert pressed the override switch at this point and took control, so Bonin's stick inputs would have been ignored. Bonin then took back control by himself pressing the override switch. In effect, then, at this late stage, the pilots were fighting over the stick. If it had been a physical fight via linked control columns, the outcome would most likely have been the same. What can you do if the pilot and co-pilot just don't agree on the correct input, and neither is willing to yield to the other?
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.
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.
There's a big difference between unknowingly fighting over the controls and knowingly fighting over the controls. If Robert had realized that Bonin was making the completely wrong control input then maybe he would have put a stop to it somehow. "Stop that, you'll get us all killed" is likely to be effective. He could have told the captain about it as soon as the captain arrived, rather than just before impact. Note that when the incorrect input was finally identified by someone other than Bonin, it was corrected immediately, it was just far too late.
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.
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.
There's no indication that they were fighting unknowingly. I'm not sure what you're concluding that on the basis of.
>Note that when the incorrect input was finally identified by someone other than Bonin, it was corrected immediately, it was just far too late.
So the popular mechanics article says, but it's not so clear in the report that this ever really happened.
>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.
To me it still sounds like physically linked sticks would have been helpful here, if the fundamental problem was that the pilots did not understand the situation. At 11:38, when this first "fighting over the stick" episode happened, Bonin held his stick fully back to the nose-up limit stop, and Robert was not aware of that fact. If the sticks had been linked, he would presumably have noticed it, which might have helped him make sense of the stall warning etc.
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.
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.
With physically linked controls, direct physical feedback will tell you if the person in the other seat is fighting your inputs. Without them, that doesn't happen, so any explanation for the aircraft not responding to your inputs is potentially valid.
They most likely would have been aware of the audio and visual "dual input" warnings.
And why didn't they figure it out...?
Read the report. There is no simple answer to that question. It was a complicated and confusing situation, and the pilots in the cockpit made a number of mistakes.
It was a complicated and confusing situation
It's the job of the UI/UX designers to make that less likely.
Like most air crashes, it took at least two things going wrong to make this one happen. Three in this case. Factor #1, a couple of morons were flying the aircraft. Factor #2, pitot tube icing. Factor #3, the aircraft was designed with certain unintuitive control features that depart from longstanding industry 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.
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.
The report examined UX issues but didn't identify the side sticks as a significant factor. You can keep insisting that they were a factor if you like, but you haven't actually provided any evidence in support of that contention.
I think we can find common ground in agreeing that those pilots needed all the help they could get. Same with these sailors.
> 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.
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.
> 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
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.
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.
> 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.
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.
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.
Feeling the control wheel or stick fighting you is far more direct.
AF 447 was absolutely a UX failure.
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-cp09060...
Check it out here: https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
First, I did not say the side-sticks are the fully responsible factor for the accident, but a contributing factor.
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...
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...
I've addressed the popular mechanics article in other comments. It's difficult to square some of its key claims with the description of events in the accident report. In particular, the report gives no indication that any of the three pilots successfully identified that the plane was stalled.
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.
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.
Pilot error based on the actions of a single pilot, or even, in extreme cases, two pilots, might reasonably be attributed.
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.
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.
It's clear from the available transcripts that there were only brief moments when both pilots were making stick inputs, as otherwise the "dual input" alarm would have sounded repeatedly. So it seems likely that for the most part, the pilots knew which of them was in control. That would makes sense, as there are clear audio and visual indications of this.
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".
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".
I have read it. Several times.
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.
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#Independ...
2. https://en.wikipedia.org/wiki/Air_France_Flight_447#Sidestic...
3. https://en.wikipedia.org/wiki/EgyptAir_Flight_990
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...
3. https://en.wikipedia.org/wiki/EgyptAir_Flight_990
The theory is generally sourced from a popular mechanics article. There's nothing particularly authoritative about that "independent analysis". Goodness knows what you mean by the "same data". No third party has access to all the data recovered from the flight recorders and the wreckage.
>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.
>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.
I think PM brought wide attention to it, but it's not like it's just some fringe theory of theirs, see e.g. this CBS report [1] from 2012 (after the PM article was published) with Captain Chesley Sullenberger (of the 2009 Hudson crash fame). Many aviation experts have weighed in on this.
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
2. https://en.wikipedia.org/wiki/Qantas_Flight_72
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
2. https://en.wikipedia.org/wiki/Qantas_Flight_72
Every Airbus crash gives rise to lots of FUD in the media. Initially, everyone was blaming AF447 on the vertical stabilizer breaking off (http://www.businessinsider.com/henry-blodget-air-france-447-...). I guess they thought they had "enough" data then, and of course plenty of "experts" were on hand to lend credence to this particular speculation. But anyway, the accident report says what it says. I see no reason to put more trust in random newspaper/magazine articles that just riff on a standard template for covering Airbus accidents (it was the scary computers what dunnit).
Equating initial media speculation not even 3 weeks from the crash when the black box was still at the bottom of the ocean with analysis done after all the data was in by industry experts in flight safety is absurd.
My point regarding the Business Insider article is that lots of pilots and other 'experts' were willing to give quotes to journalists back then, even though they knew nothing really about what had happened. Captain Sullenberger was hired by CBS as an aviation safety expert in 2011. He's expressing an opinion about the sidesticks that many other professional pilots disagree with (see e.g. the endless forum discussions on pprune). You can find pilots who support all kinds of wacky theories of various accidents. Sullenberger has a high profile (deservedly), and can get on TV.
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=...
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=...
You seem awfully invested in quashing this particular line of argument. Mind my asking why?
I think it's wrong. If you think I am some kind of shill (?), then I guess it makes sense that you would be some kind of conspiracy theorist, given your unwarranted skepticism about the conclusions of the official report.
I made no such accusation.
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.
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.
You insinuated that I had some kind of ulterior motive, in the same way that you are now insinuating that the accident report was a cover up.
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.
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.
I've asked you to state your interests.
You've declined to do so.
You've declined to do so.
What a gloriously absurd thing to say.
Look, this is me:
http://adrummond.net
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.)
Look, this is me:
http://adrummond.net
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.)
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.
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.
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-happe...
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...
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.
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.
> 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'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...
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.
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.
>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.
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.
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?
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?
> 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.
In the case of warships, specifically, its because normal operations are reduced-complexity training opportunities.
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.
We have those! Or at least, we have close enough to one of those for a secondary autopilot system.
Looks more like an aircraft's auto-pilot. It's not something that would look for obstacles, read signs, or take any kind of input from the environment besides current position.
[deleted]
I thought most of self-driving car complexity comes from guessing the route and stop timings, not from following them?
I'm honestly confused by this comment. If I'm reading it correctly, you have those two backwards. Computers have been able to figure out routes since the mid-90s (see MapQuest, Google Maps, Waze, etc). It's exactly the "following" that is the responsibility of self-driving cars.
By routes I mean dynamic physically safe corridors (hard part of self-driving), not just graph walking. By following I mean a bunch of purely mechanical reactions to maintain planned coordinates in each moment. Many cars can autopark by measuring distances around (no “vision”), this is example of “following”.
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.
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.
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.
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?
You're telling me a million dollar guided missle destroyer can't do this?
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...
At least you won't have to worry about uncontrolled USN vessels...
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!
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!
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?
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?
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.
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.
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.
Maybe we should treat it differently.
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.
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.
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.
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.
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.
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.
UI flaws have hit the Navy before, with even worse consequences [1].
[1] https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...
[1] https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...
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.
Not all errors made by users are the fault of the UI.
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-p...
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...
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.
> 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.
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.
> 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.
What a comedy of errors.
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.
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?
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 ...
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 ...
"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
Shouldn't it have some kind of automated collision avoidance that would have at least given an optional course correction?
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.
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.
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.
Good maritime discussion on gcaptain
http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-wa...
http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-wa...
I'm sure we've all read "The Inmates are Running the Asylum" by Alan Cooper.
[deleted]
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.
It's not necessarily the UI that must have been confusing, it might have been that these modes of operation are inherently confusing.
Pretty sure all collisions are avoidable.
[deleted]
There was a big ferry accident involving a similar transfer of control problem in the New York harbor.
not surprised
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 />"
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 />"
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-m...
- http://code.hootsuite.com/blameless-post-mortems/
- https://codeascraft.com/2012/05/22/blameless-postmortems/
- http://firstround.com/review/this-is-how-effective-leaders-m...
- http://code.hootsuite.com/blameless-post-mortems/
- https://codeascraft.com/2012/05/22/blameless-postmortems/
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...