NWA188 - The Story That Won’t Die

I have no idea why the story on Northwest 188 -- the flight that overflew MSP -- won’t die. It was a non-event. It’s terribly embarrassing but that’s it. Nobody was hurt. Nobody was harmed. But still, the story lives on.

I’m not complaining. I just don’t understand it. If anyone wants to take a hard look at the aviation industry (I’m all for it) there are dozens of other incidents that are more compelling. Oh well. Here’s the latest angle:

FAA looking at controllers of errant plane


”Controllers in Denver apparently did not realize for at least 20 minutes that Flight 188, after being told to switch to a new radio frequency, had not checked in again. Supervisors in Denver did not alert security agencies about the aircraft for another 20 or 30 minutes.“

First, this reporter got this right, supervisors take care of notifying “security agencies”. Some reporters have mistakenly reported that “controllers” do that. The general public probably doesn’t care which one does but controllers do (care that is). Controllers don’t like being blamed for management’s mistakes.

Second, the issue of communication transfer is near and dear to my heart. If the NTSB and the FAA want to go down that road, I’ll gladly give them a shove. Before I do, let me make this clear again. This is an event, not an accident. Even if it’s found that there was some misstep on any controller’s part, there were a dozen other safeguards in place to prevent this incident from escalating. Why none of them worked is beyond me. I gladly note that one of the most overlooked safety systems finally resolved this matter -- an alert flight attendant.

Having said all that, here is where the FAA and NTSB will start looking. I hope my readers have already thought of it. Because I wrote this before I retired. John Carr published it on his blog and I published it here at Get the Flick on March 13, 2007.

=======================

URET - A Dissenting View

Communication

The very first problem I heard of concerning URET was that controllers would forget to switch airplanes to the next controller after a handoff was completed. Imagine my surprise that this is still a problem. Actually, it is a much bigger problem than is commonly stated. With URET, controllers don’t even know if they are talking to an airplane to start with. There are two strategies mentioned (in training) to address this problem in URET.

The first is the “slant zero” strategy. The controller will “slant zero” the leader length on the data block to signify that the aircraft has been switched. While it is a solution (albeit a poor solution) to remembering that you have switched the aircraft, it doesn’t tell you whether you ever talked to the aircraft in the first place, or not. Controllers will attempt to turn an aircraft that is well inside their airspace only to discover that they are not talking to the aircraft. Remember, this happens more often than in the past because there isn’t any strip --- without a mark -- to remind you that you aren’t talking to the aircraft.

The second recommended strategy is using the “dwell lock” feature. When an aircraft checks in you place your slew ball cursor on the data block until it brightens (the “dwell”) and then you “lock” in the brightness. When you switch the aircraft you “unlock” the brightness, dimming the data block. This is a much better strategy (in my opinion) but it is not without it’s own unique problems.

The real problem is that neither of these methods is standardized nor required. Strip marking (including the marking signifying communication with the aircraft) was required. In Atlanta Center, that mark consisted of a slash (signifying you were talking to an aircraft) followed by another slash (when you switched the aircraft) forming an “X”. It was universal. Anyone could walk up to any sector and instantly determine if the controller was talking to an aircraft. Or not.

This is basic, fundamental air traffic control. It is unfathomable to me that this system has been installed in a dozen facilities and no one has addressed this issue. No one has found a workable solution (that works in all situations) much less standardized any solution. I remind you of the two NORDO freighters that almost hit over Kansas. The incident that the FAA made the training video about. The chain of events that led up to this event began with a controller simply forgetting to switch an airplane. Knowing whether or not you are in communication with an aircraft is critical.

===============

I realize the language in that is a little technical for non-controllers. You have to remember it started off an an internal communication between a safety rep (me) and the union president (John Carr). The pertinent, non-technical parts are:

”The real problem is that neither of these methods is standardized nor required. “

and

”This is basic, fundamental air traffic control. It is unfathomable to me that this system has been installed in a dozen facilities and no one has addressed this issue. “

If I found it “unfathomable” back in 2006 (when I wrote the document) you can imagine the words I’ll use if -- as I suspect -- the problem has never been addressed.

And here’s a little bit of information that someone might find useful. A study from the folks that helped push URET onto the air traffic control system -- MITRE. (Warning: it’s a .pdf file for super-geeky ATC types only.)

Analysis for Enabling Benefits at User Request Evaluation Tool (URET) Field Sites

"3.2.7 Standardization of Usage

Experience with standardizing the use of URET varies. Examples of areas of standardization of URET usage include the establishment of procedures for use of the Free Text area, the establishment of symbols for entry into the Free Text area, the specification for use of the check box; e.g., for noting when the aircraft is on frequency, and specification of the set-up of URET displays.

ZDV specifically decided to limit facility procedures and requirements for the use of URET. One of their lessons learned states “Don’t over-proceduralize.” ZDV personnel said that some FFP1 sites instituted too many local procedures and it became too cumbersome. However, limited standardization puts more responsibility on the controller going off duty to make sure that the new controller knows how the system is configured. ZDV did specify procedures for use of the free text area. "

(Emphasis added)

As you can see, that study was published in 2004. For anyone interested, ZDV is Denver Center.

”Controllers in Denver apparently did not realize for at least 20 minutes that Flight 188, after being told to switch to a new radio frequency, had not checked in again.“

Don’t jump to any conclusions about what really happened based on a story in the newspaper. You may jump to the conclusion that I was paying attention when I was a safety rep. for NATCA and I took notes. And I’m still serious about safety.

Don Brown
November 1, 2009