January 18, 2007

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.


January 4, 2007

Altimeter Three Zero Eight One

About a month ago, the Surry sector up in Maine had an altimeter setting of 28.90, making the lowest usable flight level FL200. The rest of the center held steady at 28.92 or higher (as you can see from the posted weather report), so operations weren't affected much. However, there was a lot of discussion around the control room regarding the consequences of such a thing occurring. For example, LGA arrivals get handed off to a different sector, as does PHL arrivals. Alternatives include descending aircraft with a normal restriction of FL180 down to 16000, and allow the FL190 restrictions to descend to 17000. Yes, such a low altimeter setting would do crazy things, indeed.

But what about when the altimeter setting is too high? Too high? We're used to FL180 becoming unusable, so that's no big deal, but what could a high altimeter do to stir the pot? A month after the FL200 incident, the MSS altimeter got as high as 30.81. The weather is really getting out of control. So, my first question to every pilot out there is this: How high can you set your altimeter?

Can it go higher than 31.00?

Do you have any special considerations when the altimeter is that high? Lets whip out the AIM to 7-2-2a.

From an ATC standpoint, we simply state the altimeter and advise that you remain on 31.00 until final approach. Some aircraft cannot set above 31.00, so every aircraft remains on that setting (similar to Class A airspace). For those capable of setting the altimeter to the actual setting, pilots should do so when established on the final approach segment. For those who are unable to set above 31.00, they should remain on that setting, but take the difference into account when determining decision heights.

So, aside from an audible gasp, and asking the controller to repeat the altimeter, because you've never seen it this high in your life, do you do anything different? Do you know how to figure out your new DH if you can't set your altimeter higher than 31.00?

Fly safe.