Press Alert

If you’re a member of the Press (and I know you’re out there), you need to run over to The FAA Follies and file today’s blog away some place safe. Trust me, you’ll need it sometime down the road. The guys at the Follies are still on the inside -- working for the FAA -- and they will have a better sense of how the program is going than I will.

The story is about ERAM. I told you to keep your eyes open for this program on February 18. I can not overstate the importance of this program as far as air traffic control. This is the Big One, the Whole Kit and Kaboddle, the Alpha and Omega. Unfortunately, it is going to be real difficult for most of the Press to understand the significance -- much less explain it to John Q. Public. But that is what the Press does and I have faith that they will find a way.

Let me try out what I am sure will be one of a long line of imperfect analogies. The FAA -- through Lockheed Martin -- is trying replicate the Great Pyramid of Giza. Obviously, we now have better engineering and equipment so the task ought to be easier. But what we don’t have is the lessons learned from the mistakes. Think about how old the pyramid is and how little was known about the principles of engineering when it was built. I’m sure lots of lessons were learned from mistakes but we don’t know what those mistakes were. We just have the final product -- the pyramid -- and we know that it can be done.

The program that runs the air traffic control system now is a lot like that. It was written back in the infancy of software engineering. I’ll make the assumption that the software guys are schooled in the “ancient” principles of software design (probably a really bad assumption) and can figure out the logic of the code. But I assure you, they aren’t schooled in the “ancient” principles of air traffic control. And the kicker is, neither are most air traffic controllers. The logic of that will be mysterious indeed.

Think back to the days before computers and before radar. You have to take the information for every single flight -- the route of flight, the altitude, the speed, the type aircraft, etc. -- and transmit that information along the entire route of flight of the aircraft. Any change to that information -- a different altitude, a route deviation, a speed change, etc. -- has to be transmitted in real time. It has to be done with precision.

How much precision ? Let’s look at just one factor -- speed. Back in the day when all aircraft were required to be on fixed routes -- airways -- you separated aircraft at the points where the routes crossed -- intersections. Crossing aircraft at the same altitude were separated by time -- 10 minutes. The speed of an aircraft as measured across the ground changes constantly due to the winds changing constantly. Thus, the time an aircraft was supposed to pass over a particular fix (say an intersection) was always referred to as an estimate. Cessna 12345 is estimated to cross the MULBE intersection at 12:13.

Remember, we’re just dealing with precision right now. We’ve already demonstrated that we are limiting the precision. We don’t say the aircraft is estimated over MULBE at 12:13 and 17 seconds, or 45 seconds. We limit our precision to one minute. If that were indeed the case, every time the aircraft was one minute late or one minute early over the fix, we would have to recalculate -- and communicate -- a revision to the estimate for the next fix. Remember, this is without radar or computers. Back in the day, revisions to the estimates were communicated via telephone. “N12345, revised estimate, estimating STAIN intersection at 12:36.” That would be a lot of telephone calls. So after some trial and error, some real-world experience and some calculations, the requirement for passing a revised estimate was set at 3 minutes -- early or late.

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

2-2-6. IFR FLIGHT PROGRESS DATA

”b. Forward position report over last reporting point in the transferring facility's area if any of the following conditions exist:

1. Time differs more than 3 minutes from estimate given. “

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


A programmer needs to ask himself a question, “Why 3 minutes ?” The fundamental objective is to separate airplanes -- not limit the number of telephone calls made.

Telephone calls aren’t even made any more. In my day, revised estimates were sent by computer. If someone put the wrong speed into the computer you’d get 3, 4 or 5 time updates via the computer and you would know to look for a erroneous speed entry. And you would fuss about somebody not catching the error because all the time updates were distracting you from your duties -- separating airplanes. With the implementation of URET, the computer no longer sent time update messages to the controller. The computer just updated the revised time automatically. So nobody noticed overdue aircraft anymore. “Losing” an airplane is considered bad form in air traffic control. Pilots tend to frown on it also -- when they crash, nobody notices an overdue aircraft and, therefore, we fail to start search and rescue operations.

Mercy. I hadn’t planned to go this far afield when I started this post. I just wanted to give you a glimpse of how complicated this business is and just how complicated a computer program to accomplish it all will be. Just one tiny area -- the precision with which we calculate the speed of an aircraft across the ground -- has dozens of implications and pitfalls. But the real challenge will be designing the system to handle the aircraft when the ERAM program crashes. That is the reason the 3-minute-revised-estimate rule is still in the controller’s handbook. Computer programs, on occasion, crash. When they do, controllers still have to separate the airplanes. Computer or no computer, radar or no radar.

Think about that while you watch this. If your computer freezes or crashes during the video, be assured, the airplanes keep moving at few hundred miles per hour and every, single one of them has people on board. Somebody has to ensure that they stay separated.

Don Brown
April 18, 2008