autopilot 1, crew 0

An open discussion of aviation safety related issues.

Moderators: FrankM, el, Dmmoore

User avatar
ocelot
Posts: 689
Joined: Thu Jan 15, 2009 9:26 pm
Location: /bin/cat

autopilot 1, crew 0

Postby ocelot » Fri Nov 16, 2018 5:45 am

http://avherald.com/h?article=4c003f22

Summary: Q400 crew engages autopilot after takeoff, autopilot decides it wants to go home as fast as possible. Cause: wrong autopilot modes selected, plus various missed opportunities for the crew to notice the mistake.

So it seems the Dash-8 autopilot has an altitude selection knob. As we know from computers there are two kinds of knobs: those that take effect immediately and those where you have to click Apply (or press return, or something like that) -- the altitude selection knob is one where you have to push a button to load the setting, but the crew apparently didn't understand that. So in a rush (apparently) they pushed the button first, then dialed in the altitude they wanted. The net result of this was that the altitude entered into the autopilot was 0, so when they engaged the autopilot during climbout it said "oops, too high" and nosed over.

There are a number of holes in the autopilot's cheese layer here.

First, there's nothing that indicates that the dialed-in altitude hasn't been entered into the autopilot yet. Having the display change from yellow to green when you enter it (or something like that) would avoid a bunch of unnecessary risks.

Second, the autopilot actually has two internal altitudes, one being the altitude it's been asked to hold and the other being the altitude it's been asked to level off at. The first is not displayed anywhere, ever. Mostly this is ok because it's normally selected either from the current altitude or by leveling off at the level-off altitude. But if some other altitude gets selected, which happened in this incident, there's no way to know about it or see what it is. It seems that the incident crew did not realize that these altitudes are separate and that the displayed level-off altitude was not the same as the hold altitude. It's dangerous for automation systems to have hidden state, especially when there are ways for the hidden state to diverge from expectations. Displaying both altitudes (especially when different) would avoid this problem.

Third, the way the autopilot modes are presented to the crew is unnecessarily confusing. There are six pitch modes (go around, pitch hold, vertical speed hold, airspeed hold, altitude hold, and FMS) and an additional set of widgetry for capturing altitudes/leveling off. The altitude capture mechanism is presented as an additional mode, but it's really orthogonal to the others and can (must) be used in conjunction with one of them. If you don't read the directions carefully and understand this you can easily (like the incident crew, apparently) get the wrong mental model, and then from time to time the actual behavior is not what you expect. Wrong models like this always end up able to account for routine behavior (because one sees the routine behavior all the time, and any mismatch with expectations results in altered expectations) but fail in unusual situations... which tend to be times when additional unexpected complications are most likely to be serious.

Fourth: the altitude hold mode should disconnect when the current altitude diverges too far from the selected hold altitude. Apparently it does not. This is the reason the incident flight experienced a fairly sharp nose-down: control logic meant to hold a state is not the same as control logic meant to transition to a state, and may generate unreasonably or dangerously large corrective actions if the current state has diverged too far from the target state. (Which is also related to the next point -- if the autopilot logic interpreted the target altitude and chose how to get there, it wouldn't have just nosed over; but this autopilot doesn't work that way.)

Fifth: the autopilot is not the kind where you dial in a new altitude and push go and it figures out how to get there. To use it to change altitudes, you first engage the altitude capture logic (the ALT SEL "mode") and then use one of the real modes to select a climb or descent. If you don't engage one of the real modes, nothing happens; if you dial in a lower altitude and then program a climb, it climbs forever(*), and so on. There is nothing wrong with this by itself, but it's unsafe to not recognize this limitation. Calling the altitude capture logic "altitude select" is (IMO) actively misleading.

Sixth: it is nonsensical to use altitude capture (ALT SEL) and altitude hold (ALT) at the same time. The autopilot ought to reject this combination or warn if it seems to be in use, and it doesn't. This is what happened to the incident flight; a warning about this invalid state would have prevented the incident. (It isn't quite as simple as not allowing ALT and ALT SEL to be active at once, because this happens temporarily in the process of setting up a climb or descent; but there are various possible ways to handle that.)

Seventh: one of the missed opportunities to avoid the incident occurred when the crew checked the autopilot modes and failed to notice that the vertical modes engaged were ALT and ALT SEL instead of GA and ALT SEL. This is not the first or last time people have seen what they expected to see when what was actually being displayed was silghtly different; but all the same we should try to display information in ways that discourage this. For example, using colors helps distinguish otherwise similar alphabetic readouts.

Eighth: another missed opportunity was that when the target altitude was entered incorrectly, the altitude capture logic triggered and captured the airfield altitude, that is, 0. (This is how altitude hold mode got engaged, and how the hold altitude got set to 0.) This mode transition occurring at an unexpected time should have been noticeable enough to alert the crewmember manipulating the autopilot to an anomaly, and apparently it wasn't. Mode changes need to be overt. There have been any number of accidents and incidents where unnoticed mode changes have led to missed opportunities or even made situations worse.

None of this is really all that important (after all, there are a lot of Q400s and they're known for gear problems, not for autopilot runaways) and posting it here is fairly pointless in any event, but ... there it is.

User avatar
3WE
Posts: 8141
Joined: Wed Feb 06, 2008 2:37 pm
Location: Flyover, America

Re: autopilot 1, crew 0

Postby 3WE » Sun Nov 18, 2018 12:13 pm

Wow...Pilots aren't idiots, but they do seem to have lots and lots of buttons to push, and then you throw in (was it 7?) MODES of how the autopilot works, if this mode then that, and on alternate Thursdays in even numbered Months (unless they contain an "R")…

There's something to be said for an idiot proof design.

It does appear that the crew used a super basic procedure: 1. Use solid situational awareness to recognize that you aren't supposed to be descending and 2) Use appropriate control inputs to reestablish a climb...I think we have that going for us.
Commercial Pilot, Vandelay Industries, Inc., Plant Nutrient Division.

User avatar
ocelot
Posts: 689
Joined: Thu Jan 15, 2009 9:26 pm
Location: /bin/cat

Re: autopilot 1, crew 0

Postby ocelot » Mon Nov 19, 2018 1:37 am

Well, one of the other mistakes the crew made (which I didn't mention since I was posting specifically about weaknesses in the autopilot) is that they engaged the autopilot (that is, connected it to the flight director) without first cross-checking what the flight director was directing and what the autopilot would thus begin doing. Not doing that would also have avoided the incident.

(as would flying the plane instead of sitting heads-down reading a checklist, so as to not notice the pitch excursion until the EGPWS went off...)

oh and the modes? those are just the vertical modes. There's also horizontal modes.


Return to “Aviation Safety Discussion Forum”

Who is online

Users browsing this forum: No registered users and 16 guests