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.)
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 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.
I still can't tell if my computer monitor is on or off because I don't know the weird LED flashing code it uses to communicate that (Holy crap! appliances use something like morse code to tell you important information about their state! How did they get so needlessly cryptic? If there's no picture, I have to check all the cables and push the power button a couple of times to see what happens.
Web programmers are as much to blame too. Show me a web video player that has play and pause buttons that always do what they say when they say it.
The only player which ever worked properly — even allowing the user to step through a video frame by frame — was part of Apple’s QuickTime framework.
Fun fact: QuickTime will be 26 years old in December.
Not to mention the damn spyware that's included with it...
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.
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.
Decrypting and demodulating have be as fast as the data is coming, otherwise the delay would grow until you never saw the end of the show. So that's not the reason either.
Your TV doesn't have the information it needs to start displaying MPEG-2+ATSC A/53 video for as long as 700ms. It needs to buffer quite a bit of timing information and at least an I-picture frame before it can start displaying anything:
Not only that - the overall standard has tight timing tolerances to keep video arriving at the encoder/transmitter in-sync with audio/video leaving the decoder in your TV. It's not like MP3 streaming where every client has its own buffer size and time to start playing depending on network conditions, bitrate, etc.
Having a reliable buffering process to keep receivers in-sync is a feature, not a bug.
You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?
Simple solution: just put 10x decoders/tuners for most recently used channels. I don't think it's really an engineering problem but more about cost-effectiviness, i.e. not enough consumers are willing to pay the premium.
However, even if the read-ahead tuner was perfectly predictive you'd still need to flip through channels fairly slowly, otherwise you'll outrun it - about a second a channel.
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.
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.
This was used on the America's Cup New Zealand hydrofoil . 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.
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 modern diesel or gas turbine ship, no there's not. Obviously there are limits to what the engine can do still.
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...
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.
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  supports that assertion:
> The nominal cell voltage is 2.0 V.  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.  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.  The LLL-69 type cell weights 1,500 pounds with a capacity of 8,100 Amp- hours and stored energy of 2.0 MHh. 
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.
Both the Ohio and Los Angeles class submarines use mechanical linkage propulsion, not electric, if I understand correctly.
They're not direct driving the screw with steam power from the reactor heat-exchange, surely.
You've probably seen aircraft carrier decks covered in smoke. This is because the Nimitz's catapult system is directly steam powered, service steam is widely used on the class. I can't find a citation for this now (this is from memory) but I saw some documentary on it once where it was mentioned in passing that even the washing machines on the ship were steam powered. There's service steam everywhere on the Nimitz.
Having steam power everywhere introduces a lot of complexities, which is why the Navy's moving away from it with their new carrier class. 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.
Basically they spin up flywheels that then dump their kinetic energy back into electric power as the catapult is released.
And it allows them to finely adjust the speed of the catapult depending on the kind of aircraft they are launching.
Yes, they are, for the simple reason that it's more efficient. This is beginning to give way to a series electrical design, but that's for reasons of increased stealth and other concerns, at the cost of overall thermodynamic efficiency.
On all existing nuclear carriers steam is used for the catapults (and this is much more demanding than many people are aware of). The Ford class is developing electromagnetic catapults, which are also proving to be demanding to perfect.
Can you not vent some of the steam, so the same volume of steam is being produced and the temperature the same but only some of it goes to the drive?
The comment was about the ability to vary power at all, not doing it efficiently.
Are you going to choose to crash into something because it's wasting fuel to vent part of the steam?
The ship command structure was a form of information hiding, whereby the commander only worried about the speed, whilst the engineer worried about how to efficiently deliver the requested speed.
Under emergency you will vent, but under normal operations where you just want to slow down you care very much about efficiency.
Not just for monetary reasons either (though that's a factor) but because the lumps of coal you're not burning now could save your ass in bad weather and make you reach safety instead of being stranded in the middle of the ocean.
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.
When maneuvering, you are watching obstacles and can see how much you need to turn to avoid them. So you give rudder orders. Your actual heading is only a secondary concern.
When navigating, you simply order the desired heading (for minutes, hours, or days). Then you focus on other things while the helmsman sweats the details.
Maintaining a ship's heading is a full time job. If you get distracted, you get off course pretty quickly.
Speed isn't even really handled on the bridge. The engine order (ahead full, back half, emergency stop, etc) goes to the engine room where multiple people do the work.
Note: This is in the context of oil and nuclear steam-powered ships. Gas turbine ships may well have an actual throttle on the bridge. Whether the bridge has a throttle or just an engine order telegraph, the helmsman can often have their hands too full to deal with it. But someone else can do it along with their other duties, as speed control is not so intensive.
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.
Larger ship - water is never still, and any vessel's helm left untended results in drift, both in heading and real speed vs ordered. Depending on traffic and the reaction time of the hull, corrections need to be made immediately or even well ahead of time. So helmsman watching constant compass shifts and adjusting steering is a full attention task. As is monitoring speed made vs speed ordered. Still need more eyeballs to keep a full 360 visual watch, radar watch, and a quartermaster to plot position against nav hazards and boundaries and warn against the 'invisible' navigation issues.
If a destroyer could respond to control input like a plane, there would need to be a single person at the helm/throttle.
Entering/leaving any decent sized port that handles larger vessels is a much more intense collision avoidance situation than any airspace management situation I can imagine.
Reducing the reaction space from three to two dimensions and extending the reaction time from control input -> output by a factor of 100 to 1000 is part of it.
The other complication is having a magnitude or more of different classes of "threats", from unexpected solid objects ( chart errors or new items unreported), other vessels both larger and smaller with faster or slower response times of their own, errors in SA... eyes and professional judgment help immensely. Thus the focus on keeping the OOD watching the whole SA.
My sub had at least a dozen people involved in building the "picture" around the boat, visual, sonar, radar... plus two or three of us collating that into displays and reports the OOD could see immediately.
Rather, I'm doubting that going in a straight line at a target speed is correctly handled with a three-person steering wheel. My understanding is that the current OOD already has a trajectory planned through the workspace coordinate system (space, time) and gives orders in workspace coordinates ("go this fast") that are then translated into low-level control outputs ("set the rudder to X"). It sounds like in some cases the OOD even gives direct control outputs - "Prepare for X thrust in Y minutes". Certainly these low-level controllers can't be a good thing for the OOD to be spending cognitive resources on, and I'd be astounded if we can't replace that with a computer that translates directly from that trajectory to the control outputs.
That's why I used airplanes as my example, rather than, say, autonomous vehicles. A commercial airliner's path through the air to a safe landing is basically hard-coded. The task of the airplane's autopilot, then, is simply to follow that trajectory - and I'd guess that it's far more difficult for an airliner to follow a workspace trajectory than it is for a ship to do so.
Really, the hard part is going to be getting the trajectory out of the OOD's head. And even then, it'd be so much easier if the helmsman could execute "go this way" by punching "this way" into a computer instead of staring at a compass and directly and continuously controlling the rudder.
The OOD is estimating a best trajectory given an analysis of the navigation constraints and the behavior of every possible contact in the vicinity. Orders at every level of detail are possible at any time... from 'resume best course for point "X-Ray"' to 'allaheadflankfullrightrudderbraceforimpactport!'.
That is the point of resistance to most levels of automation past 'ship's wheel mirrors rudder angle' and 'engine order repeater indicates desired engine rpm'.
A ship just can't have as much obstacles as tank negotiating battlefield.
The UK's Warrior armoured personnel carrier is an example of what I guess you mean by 'Infantry Tank'. It has a Commander, Gunner and Driver (plus the 'dismounts' - seven guys in the back who get out to fight on their feet). The driver - as the role name implies - does all the drving. The commander (who is also the loader, incidentally) directs the driver where to go. He does not have duplicate driving controls. If the driver is very inexperienced, the commander will give him very precise direction. If the driver is experienced - in the sense of understanding tactical movement considerations - the commander can be much more hands off.
If the vehicle commander is also a platoon commander, he is also giving orders to the commnanders of the three other vehicles in the platoon. He is much more likely to be paired with an experienced driver so he can focus more on the overall battle than control of his own vehicle.
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.
I wonder if there is enough information publicly available to compare the workflows on the McCain to the same workflows on the Zumwalt.
That's how Star Trek do it!
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.
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.
It seems similar to the whole democracy v. autocracy tradeoff. One optimizing for coverage of perspective, the other optimizing for efficiency of a perspective.
> 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.
I do think the Navy has difficulty delegating and tends to try and focus power on a few positions.
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)
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).
That said, the automatic might beat a manual in other metrics.
* 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.
But yes, after owning manuals for years I would never go back, an automatic allows you to be so much more focused on the road and enjoy it more - I love driving and have a sports car, would never ever swap the transmission in that back for a manual.
At the end of the day I think manuals are great fun but automatics are more practical. An automatic will never stall out in a safety critical moment, as I always worried I would do in the manual. I've also pondered that if I was ever to sustain a serious injury to an arm or leg, I would probably be able to drive an automatic in an emergency. Driving stick with a broken arm would be substantially more difficult. The fuel economy advantages enjoyed by manuals seem to have dissipated at this point as well.
Automatics in UK certainly cost more, if one doesn't ride the clutch I imagine the manual will have lower maintenance costs?
The Apache Attack Helicopter is renowned for being especially difficult to fly , and I wonder if Navy wished to avoid having a similarly single, not-so-easily-replaced bottleneck.
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.
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.)
But it was modified several times, so that doesn't really contradict the story.
Albacore was very maneuverable, probably more so than any large sub before or since. The term "hydrobatics" was used. Probably too maneuverable for a ship of that size, since it wasn't configured for operation with everybody strapped in.
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.
“No, we did not deliberately ram a ship suspected of smuggling contraband to North Korea, that would be illegal.”
Every vessel shall at all times proceed at a safe speed so
that she can take proper and effective action to avoid
collision and be stopped within a distance appropriate to
the prevailing circumstances and conditions.
Trying to find the 'real cause' is a fool's errand, because there are many places and ways to avoid the outcome.
I do take your meaning, reducing speed and following well established rules would have almost certainly have saved them.
0. PDF: http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human...
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.
(figuratively) The tendency to focus one's attention on one specific idea or viewpoint, to the exclusion of everything else; a one-track mind.
Road and train tunnels have many emergency exits...
"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.
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.)
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.
So they were unable to understand their own speed controls.
It's a poor choice for quoting non computer languages.
The problem isn't "because they used codeblock" the problem is codeblock is broken.
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.
Sorry. That does not compute. Based on that visual, the ship was dead in the water.
The McCain entered the TSS at 20 knots and varied between 20 and 18 knots until the steering problem began. The OOD ordered the vessel slowed to 5 knots but due to confusion on the bridge the orders weren't carried out properly and the vessel was still making 11.8 knots and turning to port at the moment of impact. The Fitzgerald was also traveling through traffic at 20 knots and narrowly passed three vessels at that speed before finally being struck by the Crystal.
A bit like those organ donors, err.. motorcycle drivers, that swerve among the traffic at high speed.
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.
There is no visile damage indicating that the penetrated vessel was moving forward. The damage is perfectly symmetric, as you can clearly see.
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:
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.
Linked controls (nobody realized the junior copilot was making opposing inputs, which were then averaged with the pilot's) plus poor autopilot UI that they were accustomed to ignoring, made it stall and crash after a single wind speed sensor iced up.
If nobody had touched the controls, autopilot would have flown safely through the storm.
The whole accident is a prime example for a very minor problem (loosing air speed indicators) spinning completely out of control, with the crew being making every possible mistake all the way down, all three people in the cockpit completely ignoring 47 stall warnings.
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.
(In case it's not obvious, I've got a few hundred hours behind the G1000. AMA.)
My feeling has always been that the Garmin UI was somewhat clunky and suboptimal, possibly because they tried to keep it similar to the UI of previous smaller devices (such as the GNS 430); a bit like if the iPhone hadn't come along and we'd still scroll by putting our finger on a little arrow in a scroll bar on mobile devices.
My impression was that other manufacturers had a better UI, but somehow didn't make it in the marketplace.
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.
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.
Would it be possible to display that same information using a traffic light system?
(Red=Immediate action required, Yellow=keep an eye on this, Green decaying to grey=something that changed (eg AP OFF green then turns gray after 10 seconds or so). It would need to be applied with discipline to avoid every single piece of information being red and hence useless. (cf phone notifications or people who click OK to every dialog box).
Information overload / fatigue is a real thing and something designers need to concentrate on more, the ugly brother of "minimalism" which looks pretty but is frustratingly useless.
If you're interested in human factors in aviation, there's a lot of work being done out there in the field. A friend of mine is actually working on an MS in Human Factors at ERAU.
Like what? I really can't think of anything that has the same ratio of danger to visual subtlety.
But clearly airspeed is critically important, attitude is, a wrong heading can kill you (eg Varig 254 ), a transponder that's off can kill you (eg the Embraer/GOL accident ), 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.
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.
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.)
So as the last person in that food chain, you're in the middle of panic, 1200Hz are drilling into your brain, damned thing prints hexdumps, and you need to apply binary shifts and ANDs, convert from floating point hex to decimals and pray that there's enough paper in damned FPD.
I could never imagine worse UI, it's strange that we didn't start WW3 in those conditions.
This is extremely applicable: https://hackernoon.com/why-the-dmv-website-sucks-2f27a367baa...
Disclaimer: it's an article I wrote about why government software contractors suck at their jobs.
0127 The Officer of the Deck ordered course to the right to course 240T, but rescinded the order within a minute. Instead, the Officer of the Deck ordered an increase to full speed and a rapid turn to the left (port). These orders were not carried out.
0129 The Bosun Mate of the Watch, a more senior supervisor on the bridge, took over the helm and executed the orders.
I've witnessed multiple similar situations on a warship (imminent loss of extremely critical systems), and had to forcibly push the watchstanders out of the way to do their job for them. Many people are going to freeze when the SHTF, and there may be no prior indication.
Major attaboy to the BMOW who saved many of his shipmates. Given the incident angle of collision, many more would have died from a perpendicular collision.
I don't think the senior watch team had their st either, or the orders to prepare to take manual control of the steering and propulsion system aft would have immediately been out.
Also it makes little sense that lookouts who calculated cpa at collision weren't raising the alarm. These guys who I had to do their job for them: I got them removed, and tried to get them off our boat. They were fine people but they were a danger to us.
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.
LOK = Level of knowledge?
BMOW = Boatswain's Mate Of the Watch
ST = ? Not "Subject to" or "Such that" as I've seen.
CPA = Collision Prevention Assist in automotive systems, but maybe not here?
CPA = closest point of approach.
CPA is calculated for anything close ahead of time, but only if both you and another ship are moving in a straight line. Which the McCain wasn't.
So I guess if this warship fired all its rockets away, "due to bad UX", and destroyed a small nation, I guess the comments would also be about a bad UX.
Oh crumbs, the "check status" button was so close to the "start armageddon" button. Perhaps we should submit a meek complaint to Microsoft or something.
"Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control.""
So... we gave the control of a warship to some guy that... has some difficulty navigating through the straits that like 1M of ships go through every day, without problems.
Mind you, this is the navy that is supposed to be highly trained to deal with real-world issues such as naval blockades, pirates, and even wars.
It does not make sense at all. Allegedly there were some cuts to funding for navy. Maybe someone is trying to make a point. I do not know, this is just unexplainable. Certainly nothing to do with just "bad UX"
You have to look at the entire accident chain, and at the entire system, including training, supervision, redundancy, and, indeed, UX.
Design (in my opinion) is planning out what good and bad things are for a given tool and determining how to express that through the UI.
I disagree with the premise you have that the designer deciding what is good and bad is the whole or even the right story. I think I might agree with the implication that a system should make doing cognitively difficult/safety critical things easy but there is no possible way to plan for all eventualities, that's why we have 'intelligent' controllers in ultimate charge.
One day we might have artificial intelligence in charge but we're not there yet.
So instead of the goal of good UX being the designer planning out what is good and bad, it is much better to design a system that reduces cognitive load but presents information about the current state of the system in the most obvious and intuitive way possible. It should do everything it can to make sure the operator understands the current state of the system.
In terms of operating complex physical systems like ships and aircraft the ultimate goal of designing control systems is to simultaneously take as much of the burden off the operator as possible but present all information needed in order to bring the system back to an _understood_ state as rapidly as possible following deviation from that state. This is the only way to maintain _control_.
It's reasonable to try and make it difficult to get to a state that is 'uncontrolled'. But it's imperative that more credence is given to getting a system back to an understood state once the controller finds them self in one that's not understood. It may get to this state in a way the designer didn't plan for, so getting out of it has to be incredibly quick and easy.
Personally, I put more stock in getting the system in an understood state than a controlled one as from there it's easier to return to control. Without understanding the state of the system it's easy to make further mistakes.
Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.
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.
I know of a ferry that a local warf built that had two bridges, and a combined throttle and rudder in each.
The thing is that when moving from one bridge to the other, the crew had to flip a switch to indicate what direction was forward. And quite often they forgot.
End result was a long history of damaged because ferry would ram the pier when the crew was actually attempting to move away from it.
EDIT (since some people obviously don’t understand the problem): ... so that each set of controls is always correct for the respective side on which it is located. No switch is necessary.
Eg, if you're facing the dock, and push forward, you'll hit the dock. Take the other side and point your body to sea. Intuitive.
Poor UI design is remarkably common, even on controls that are essential for safe operations.
Older PDF (paperback is well worth it, in my opinion): http://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human...
Airbus uses two "side stick" controllers that are on opposite sides of the cockpit. This was a contributing factor in the Air France 447 crash.
> Decent odds you've flown on an airplane with a similar UX for primary flight controls.
Ah, well Airbus does a few things. 1.) A "dual input" warning is issued if there is an attempt at using both controls simultaneously. 2.) There are lights to indicate when your sidestick is active and when it is not.
For an industry that is so safety conscious, I believe this is a huge flaw in disaster control. To put it in context that most readers here can understand - lets say your everyday computer uses OS X as its operating system, but one day, with deadlines to meet, you have a huge crash, and the OS reverts to Windows, and you have to find the problem and remember the appropriate commands under intense pressure...
The big problem was that the pilot-in-command simply forgot (or did not know) how to fly the plane. He overcorrected in reaction to turbulence and the rest is history. Normal law does not allow the pilot to set an angle of attack that would lead to a stall. In the alternate law modes this protection is not there and so when the PIC didn't adhere to the rule of "don't pull up while in a stall" there was no safety net to prevent him from exacerbating the situation. In fact he kept pulling back when the stall alarm went off.
A better UI would not have solved the self-inflicted problems. From the findings sections in the wiki entry:
- The pilots apparently did not notice that the aircraft had reached its maximum permissible altitude
- The pilots did not read out the available data (vertical velocity, altitude, etc.)
- the crew made inappropriate control inputs that destabilized the flight path;
- the crew failed to follow appropriate procedure for loss of displayed airspeed information;
- the crew lacked understanding of the approach to stall
- the crew lacked practical training in manually handling the aircraft both at high altitude and in the event of anomalies of speed indication
- the two co-pilots' task sharing was weakened both by incomprehension of the situation at the time of autopilot disconnection, and by poor management of the "startle effect", leaving them in an emotionally charged situation
- the crew did not respond to the stall warning
A better cockpit may have given the pilots a better chance of surviving but definitely wouldn't have guaranteed a better outcome. One only needs to look at Asiana to see that even Boeing, with their contrasting approach to UX, can't save pilots who lack basic airmanship. My understanding is that most long-haul pilots will fly a fairly small number of segments each month, and that most of those segments are going to involve a huge amount of time spent in the middle of nowhere with autopilot on. This leads to atrophying of skills needed to manually fly a plane.
Conversely, one only need to look at Qantas' QF32 incident to see that good airmanship can absolutely make catastrophic failure survivable. Yes, there is a lot of information to process in an emergency... but the Qantas crew took that information and delegated appropriately. The Air France pilots lost their cool and fucked up.
The pilot flying wasn't the pilot-in-command. Half the problem was the PIC was out of the cockpit at the time and the lack of any clear command structure between the two first officers in the cockpit. You can also argue that it may have been recoverable if the PIC took over as PF when he returned to the cockpit (had he acted rationally, etc.), instead of being confused by the situation they were in and unable to get out of, likely without knowing what the PF was doing.
> My understanding is that most long-haul pilots will fly a fairly small number of segments each month, and that most of those segments are going to involve a huge amount of time spent in the middle of nowhere with autopilot on. This leads to atrophying of skills needed to manually fly a plane.
Much flying nowadays is through RVSM (reduced vertical separation minima) airspace, and you're not allowed to hand-fly the aircraft there (in general, modern autopilots can maintain altitude better than a pilot can).
There were a Captain and two co-pilots aboard AF445. The junior co-pilot was PIC for much of the incident.
See also <https://aviation.stackexchange.com/questions/33414/who-is-th....
As in the AF447 case, the PIC will delegate to an acting PIC while they are on their rest break, but ultimate responsibility still remains with them.
PF Pilot Flying
PNF Pilot Not Flying
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?
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.
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.
Jetliners have gangable throttle controls for their engines, albeit with what is probably a much better interface.
Then again, in high stress situations even totally obvious signs like this can be missed, as evidenced by the Qantas 747 crew on the famous runway overrun in Thailand some years ago. I believe in that case, a large contributing factor was when the captain went to pull the levers back over the rear detents for reverse thrust after landing on the wet runway, he only grabbed three of the levers, and left one engine running at just over idle speed.
"Retiring" without losing rank doesn't cut it.
There are plenty of examples of "UI confusion" causing professionals to make mistakes in all sorts of industries. I'd suggest taking a look at the book "Behind Human Error," for example.
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.