NEWSCLIP-2007-03-13: URET – A Dissenting View

NOTE: copied 6-29-2014 from Don Brown’s ATC-related website, http://gettheflick.blogspot.com/2007/03/uret-dissenting-view.html

WARNING — Safety Geek Stuff.
Seriously, the average reader (probably) won’t be interested in anything below (especially the second part.) The only thing that might interest the non-aviation geek is the (excruciatingly) detailed description of what it means to have The Flick. Just don’t say I didn’t warn you.

Back in the day when I was a Safety Rep. for NATCA, John Carr was the president of NATCA. John had a blog — The Main Bang — that was immensely popular in the air traffic control world. Unfortunately, he took the blog down after he lost the election. It was a typical, classy act on his part….there I go, getting off the subject again.

Back on track. As a Safety Rep., I had (and still have) some real concerns about a new computer program used in the Air Route Traffic Control Centers (ARTCCs) called URET — User Request Evaluation Tool (pronounced You’re It.) After taking my concerns to various and assorted outlets within the FAA and NATCA, I decided to write John about it. You can infer several things from that but I’ll just point out a couple. Information gets filtered as it goes up the food chain. I wanted to make sure the unfiltered truth was getting to the top. It also points out the level of my concern. There are very few (if any) safety problems to which I gave this level of attention.

A significant problem I was having (as you’ll see) is that NATCA supported this project. And I was a representative of NATCA. Like so much in the safety business, much of what I did consisted of pointing out problems that somebody would consider embarrassing. Or at least uncomfortable. Nobody wants a safety problem. If they have one, they certainly don’t want anybody shouting from the rooftops about it.

Yet, that is exactly what John did. He put my private letter on his blog — The Main Bang— for all the world to see (with my permission of course.) I want you to really think about that. The president of the controller’s union was willing to accept any potential embarrassment to ensure that a potential safety problem was fully addressed.

I emphasize the word “potential” to make another point. I wasn’t the only safety guy in the business. I wasn’t even the only safety rep in NATCA. Not by a long shot. And my opinion on URET is definitely a minority opinion. In that it is no longer available on The Main Bang, I decided to post it here.

Believe it or not, I hope this opinion — like a dissenting opinion in a court ruling — remains a forgotten footnote in history. But it is the truth as I know it and I believe it’s important enough to justify the space. And as John Carr’s action made so crystal clear, if it really is about “Safety Above All”, then any embarrassment suffered is a small price to pay. Even if I’m that one that has to suffer it.

Don Brown
March 12, 2007

——————————

URET – A Dissenting View

Background

I have been opposed to URET for many years. URET’s original design intention — evaluating user requests — was a nonstarter from my perspective. As URET morphed into a flight progress strip replacement, my concerns — and my opposition — deepened. The majority of pilot requests involve a shorter, more direct route of flight. This is nothing new. If this issue were to be addressed, we’d make straight-line airways from coast to coast. The reason that we don’t is that the users do not want to fly in a straight line. The users base their routes not only on the shortest distance but also on the winds aloft. Much effort is expended in avoiding unfavorable winds and flying to favorable ones.

In addition, if the users did indeed want to fly in straight lines ATC would be faced with running traffic head to head on a regular basis. As we all know, as soon as traffic in and out of an airport reaches a significant level, we refuse to do this for justifiable safety reasons. We design arrival and departure gates and enforce their usage. Otherwise, we’d abolish all the STARs and SIDs.

Structure begets structure. As an example, I offer the BROOK STAR into GSO (Greensboro, NC). The STAR has very little to do with the level of traffic at GSO and a lot to do with running the GSO traffic around the CLT (Charlotte, NC) traffic. We are faced with the same problem on the other side of CLT at the GSP (Greenville – Spartanburg, SC) airport. The needed structure at CLT forces us to use yet even more structure to handle the traffic into GSP and GSO.

This principle holds true even in the higher altitudes. It would be the height of folly to attempt to run any traffic head on to the the ATL (Atlanta, GA) airport traffic inbound on J48, in the flight levels. Because of the significant volume of traffic on this airway, it is — in effect — a one way airway inbound to ATL. In that form follows function, the aircraft northeast bound out of ATL are contained on different airways, indeed, in an entirely different sector. Users may not accept this premise but as long as runways are long, thin, strips of concrete that aircraft must line up to use, it is a fact of air traffic control. They have to get in line. And that line starts hundreds of miles away from the airport.

As to replacing flight progress strips, I have to ask, “Why ?” For a gain in efficiency ? We aren’t in the efficiency business. We are in the safety business. While that doesn’t prevent us from attempting to be more efficient it it not the first order of business. At the very outset, URET replaces a tool that has withstood the test of time with an untried and inherently less reliable piece of technology. Strips have been around since the dawn of air traffic control. They have survived every single technological advancement. And for good reasons. The mechanical reliability of a piece of paper and a pencil is several orders of magnitude higher than a computer. That fact alone should have given us pause prior to replacing them. But it didn’t.

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.

Time

The next big issue with URET is the lack of a fix/time on the Aircraft List Display. For a controller (such as myself) that “thinks non-radar”, it is unimaginable that anyone would even consider this as an option much less that it would be implemented. You can read the route of flight (say MOL.J22.VUZ./.IAH) and you can “see” the route in your mind. You can tell that the aircraft on the JAX./.SPA..HMV..FLM./.ORD route will cross his route. But without a time over a fix (a fix/time) you cannot tell if the aircraft will be anywhere close to each other. You can’t even tell if they will be in the sector at the same time. Although you can use URET to “probe” for this conflict it isn’t the same thing.

I was working the BRISTOL/SPRING sector the other day for over an hour. It was busy and I was using URET. URET didn’t show a single conflict for the entire time. I was just looking at the PSK sector. They had 23 airplanes in their sector at one time. Not a single URET alert was showing. Time isn’t used solely for determining conflicts. It’s used to plan.

You put the time into the equation so you’ll know when you are going to get busy. You pre plan — think non-radar — so that you’ll know how many airplanes will need to transition altitudes in any given period of time and their relationship to other aircraft that might be a factor. You build a mental picture of what the traffic will look like — ahead of time — so that you can formulate a plan. Without a fix/time you cannot do this. URET robs you of this ability to plan. This is a totally different mental process than looking at a radar scope. Using this mental process — thinking non-radar — is a vital element to memory and compliments the thought process of working radar.

Using strips, I can “see” much further ahead and with more mental clarity than with URET. Yes, URET is more accurate, but it does not provide you with this mental clarity. It actually prevents you from having it. Yet when we are forced to use non-radar procedures (about twice a month in my Area) we must revert to the same process that URET prevents you from using. At the same time, we are supposed to magically pick up the habit of marking strips again. But marking them is no longer habitual. This does not work. We are asking controllers to do the impossible. We have implemented a system that will make controllers fail.

Human Factors

Sitting in URET training, it was hard to believe a Human Factors specialist ever had any input into the program. The memory requirements are unbelievable (in more ways than one.) Left click, right click, center click, HOT FSH, red fish, blue fish. I have been using URET for several months now and to this day I can’t tell you what happens if you left-click the call sign as compared to center-clicking or right-clicking it. And if you try to click on the call sign, it’s likely to “jump” just as your are doing so and you wind up clicking on an entirely different call sign.

I was working the SHINE/MOPED sector last night and was surprised to see three “bright red alerts” on URET. I stopped what I was doing, leaned over to investigate and before I could even read the first call sign all three alerts disappeared. Huh ? Another time during this same session I stopped to count them. I had three red (muted) alerts and eight yellow (muted) alerts. Without the mental picture of traffic (described above) I had no idea what URET was trying to tell me. And in that I was working by myself I certainly didn’t have time to investigate each one. So I did the same thing that every single controller in ZTL does with them. I ignored them.

URET cannot accomplish even the simplest functions in air traffic control. The SHINE sector runs the inbounds to CLT from the northwest. We are required to give each arrival the crossing restriction at the SHINE intersection. “USAir four fifty two, cross SHINE at and maintain one one thousand and two five zero knots.” There isn’t a way to denote this restriction — which is given hundreds of times a day — in URET. As you know, a crossing restriction is a discretionary descent. If you can’t give a pilots discretion descent you issue the clearance to descend to one one thousand. Both clearances look exactly alike in URET. Five minutes later you are supposed to remember which one doesn’t have the crossing restriction when you’re working a dozen airplanes doing exactly the same thing ?

When I ask about this lack of capability in URET, I receive the same answer I get for every other thing that URET can’t do, “You just have to remember.” That phrase — “have to remember” — should sound the alarms bells for any human factors specialist that knows anything about human memory.

How do you designate that 12,000 and direct to the airport is approved for N12345 ? You have to remember.

How do you designate that direct SJI.STROHS2.IAH has been entered into the computer but hasn’t been issued to COA1256 ? You have to remember.

How do you designate that climbing to FL340 has been coordinated with the Bluefield sector for DAL1391 ? You have to remember.

Let me quote from a human factors experiment conducted with controllers.

“This result suggests that it was more difficult for participants to maintain critical information in memory the more commands they issued, particularly when they were unable to record this information on flight strips.”

(from Influence of Individual Experience and Flight Strips on Air Traffic Controller Memory/Situational Awareness by Earl S. Stein, PhD, Supervisory Engineering Research Psychologist with the NAS Human Factors Group at the FAA  William J. Hughes Technical Center)

And this from another study conducted with controllers:

“Controlling aircraft in today’s crowded skies is a complex and dynamic process. Air traffic controllers are surrounded by sources of information from which they must select critical data. They code and store in their memories a portion of this data. However, they do not always do this effectively. One of the most common expressions uttered by controllers who have made an operational error is: “I forgot!””

(from Air Traffic Controller Memory by Earl S. Stein, PhD)

Controllers already rely on their memory too much. It’s as simple (and as old) as what each of our mothers told us, “If you want to remember something, WRITE IT DOWN.” Yet URET prevents you from doing so. Which leads us to another URET weakness.

Non Verbal Communication

Flight Progress Strips were a shared tool. The URET display isn’t. With strips, both controllers could read all the information present, even if each controller was reading something entirely different. The D-side could be looking at the spatial relationship between two flight at the same altitude while the R-side was reading the “red route” that needed to be issued to an entirely different airplane.

In URET that “red route” (now a HERT route) may scroll off the screen. The R-side will have to ask the D-side to scroll the screen so he can see the complete route. It is more likely that he won’t see it at all because the D-side is using the probe function of URET and the Graphic Plan Display is covering up the Aircraft List Display.

Perhaps most telling about this situation is when a D-side sits down to help a controller that is becoming busy. The vast majority of time the D-side will have to remind the R-side to relinquish the URET trackball so the D-side can manipulate the URET data. Adding a tracker to the mix just exacerbates the situation. The D-side takes the URET slew ball and robs the R-side of the ability to access the flight data exactly when he needs it. The tracker takes the R-side keyboard and/or the radar scope trackball denying the R-side use of the Flight Plan Readout function. (It also steals his ability to use the “dwell lock” or “slant zero” function to denote communications with an aircraft.)

And just when the workload reaches the R-side’s breaking point, the D-side has to lean over and say, “Give Delta1491 25 degrees left, slow him to 250 kts and switch him to 124.37.” Instead of the D-side writing (in red) on the strip of DAL1491, “25L”, “250 kts” and “124.37” and cocking it out towards the R-side and pointing to it when the R-side looks…the D-side has to issue complicated verbal instructions in a noisy and distracting environment.

Closing Thoughts

Despite the length of this document, I have barely scratched the surface of all the problems I perceive with URET. It is a poorly thought out solution to a nonexistent problem. The concept of “Free Flight” is the folly of the uninformed. I don’t know of a single controller that believes it will work. My perception of URET is that it is a program adapted by controllers that neither liked, used, nor understood that Flight Progress Strips were (and still are) an incredibly effective, flexible and reliable tool. The fact that strips work in both a radar and non-radar environment, while URET does not, should make this fact abundantly clear. My perception is that URET was designed by people that think “five miles and a thousand feet” is the end all of end alls in air traffic control.

I have witnessed this mentality for years at Atlanta Center. Controllers that allow the high altitude sectors to define their work habits and mental processes find that these habits don’t work well in the lower altitudes. Conversely, controllers whose work habits and mental processes are formed by the low altitudes sectors — while somewhat slower on the high altitude sectors — are just as safe and orderly on the high altitude sectors. The definition of Air Traffic Control is still safe, orderly and (then) expeditious. And when these controllers that allow radar to dominate their minds are faced with working non-radar, their habits and mental processes fail them. Their methods simply do not work in non radar.

I can think of no better analogy for URET. While more efficient in the high altitude sectors, it becomes less and less effective in the lower altitudes until it ultimately fails in a non radar environment.

All this leaves us in a untenable position. NATCA has supported both the concept of Free Flight and the URET program. I cannot imagine the circumstances under which URET is pulled from all the Centers and we revert to Flight Progress Strips at all sectors. I know just as you do that it would be politically impossible and that URET is very popular with a majority of our controllers. But popular doesn’t equate to safe. URET is full of holes and we must close them. I’ll be the first to admit that I don’t know how — or even if — it can be done.

At a minimum though, I would require that strips be used on any sector that has any non radar airspace and/or performs any Approach Control type services. Not just for the individual aircraft that meet this criteria but for the entire sector. In addition, I would give serious consideration to requiring flight progress strip usage on any sector that routinely holds for a hub airport. This will address the most serious weaknesses in URET and hopefully allow us time to find and implement workable solutions.

Don Brown
NATCA Safety Rep.
(Originally published on The Main Bang in July 29/30, 2006)