Automated Traffic Control?

URET (User Request Evaluation Tool) is the strip replacement system installed last year at Boston Center. It was already operational at most other ARTCC's, as we were in the next to last group to receive it. The system is basically a parallel computer program that runs with our HOST computer and stores flight plan information, weather data, updates the data with our inputs, and displays it on an LCD screen which was installed where our strip bays once were. There are some quirks and bugs in it, which distract us momentarily, but once you learn what they are, you assume it will screw up when you do certain things, and you ignore them or work around them as they happen. Some day, the bugs may be fixed; we are waiting for the computer techs to learn how to fix URET (they were last on the list to learn how to use URET and fix it, ironically).

And while there are plenty of bugs in the system's internal programming features, the issues extend far beyond that when you consider the possible future usage of the program.

I will NOT say that I think that URET will someday run air traffic. I do believe that the attempt to use URET to aid another automated program to replace air traffic controllers will occur in the near future. It would be at least a two step process. URET has a "probe" function at its core, which scans traffic based on current position, route of flight, current flight track, estimated wind at altitude, filed airspeed, and aircraft performance characteristics. This current probe function could be used to predict, based on a flight's scheduled departure time, all aircraft it would become a potential conflict for before it even takes off. This probe is relatively very simple, as it cannot create an alternative route or altitude that will eliminate the conflict. A second program would have to developed to create the plan of action. In a previous post, I wrote of a program being developed that could run sectors better than any human. I do not know much about this tested (its still in testing behind closed doors), but the results seeping out from under the closed door indicate the program is very good at maintaining current separation standards at much higher rates of traffic though current sectors. I wonder, though, if it can maintain 15 miles in trail separation for aircraft going to certain destinations? What would happen when the weather is crappy in the summer, and planes REQUEST something, such as a weather deviation, or a lower altitude for turbulence? What would happen if aircraft are flying slower to save gas?

For all you savvy fliers out there, you may have noticed when the captain comes on the PA to announce that "they apologize for the delay at the gate, but we're gonna try to make up time in the air". How could this be? It may be a shock to realize that aircraft don't always fly as fast as they can go. The slower they go, the less gas they guzzle. An interesting side note: Airlines that aren't doing so well financially fly slower than those that make money occasionally.

Unfortunately, URET doesn't pick up on this, since its a computer. Airlines always file the same flight plan every day. They amend things like the route or type of aircraft when needed, though rarely change the filed airspeed, regardless if the fight that day is going slower to save gas, or faster to make up for the ground delay.

Now, things like weather, emergencies, and spacing are all widely regarded as "the human element" when there is talk of computers taking over the world or air traffic. Yet, the speed of aircraft is never discussed, but when examples offered, the responce is typically, "oh, thats just the human element".

I'll close with an example:

Two aircraft are going to hit over SYR. They are N108KC, a Cessna Citation jet from Manchester to someplace west of SYR at FL360, and ACA995 (Air Canada) an A319 (Airbus 319) from Montreal to Mexico City climbing to FL360. When the aircraft were just entering the sector (N108KC was about 60 miles east of SYR, ACA995 was about 90 miles northeast of SYR), the two aircraft were determined to be in conflict by the controllers working the sector (myself and the radar controller). Since ACA995 was still climbing out of Montreal, we simply stopped his climb at FL350. URET showed no conflict alert whatsoever. It took the wind into account correctly, but failed to realize that the actual airspeed of N108KC was significantly less than the filed airspeed. Thus, since URET doesn't actually track the aircraft's datablock, it didn't realize the Citation wasn't as far along his route as it thought (they don't call it a "Slowtation" for nothing). Come to think of it, HOST thought the plane was farther along that it was, as well. When we drew the Route line on the radar screen, it showed the start of the line well ahead of the actual target of N108KC. The datablock still tracks the actual target of the aircraft, but the rest of the computer thinks the plane is farther along, and things like that affect automation such as handoffs to other facilities in ways that aren't relevant to this discussion. So, while the HOST and URET assume that N108KC will pass 15 miles in front of ACA995, the targets merged perfectly, directly overhead SYR, but with 1000 feet vertical separation.

Too bad for the human element in our world lest we could get computers to run it for us.

DM