This short note is about Air Traffic control automation. The ATC problem is primarily one of maintaining a real-time database. That ATC database contains the relevant data of the system updated to the latest second of time. Where is every aircraft (cooperative or non-cooperative), where is it going and at what speed. What flight plans exist, what are the current weather conditions, what is the minimum terrain what flights are planned for arrival and departure at each terminal?
With this database - optimization of routes, terminal operations and minimization of delays can be realized. Air to air conflicts and flight into terrain can be detected and advisories issued to both IFR and VFR traffic to correct problems as they are found.
But these capabilities are dependent on a simpler and more efficient computer capability than the multiprocessor in use today. The multiprocessor has repeatedly been proven inadequate for the real-time ATC problem. Theorists declare the problem intractable with the multiprocessor. Let's look at some examples of a different technology that is capable of managing real-time ATC database problems.
The following was written By Richard Collins in his column ON TOP. It appeared in "Flying" Magazine Dec. 1995 pg 16.
It was entitled "BACK TO THE FUTURE""In November 1971, I flew to Knoxville, Tennessee, for a demonstration of a revolutionary new use of air traffic control computers. It was the first system to offer conflict alert plus the promise of low altitude alert. There was a potential additional benefit from the new equipment: automated VFR traffic advisories. You were given a transponder code that was identified with your aircraft. Then, in a computer-generated voice (not as good as they are today) the computer would automatically call traffic at five, three and one mile ranges. A VHF frequency was dedicated to this experimental service in the area. The information was based primarily on the Mode A transponder. Mode C (altitude reporting) was in its infancy at the time, but if both airplanes were so equipped the automated system would also give the altitude of the other aircraft. Once the threat had passed, the voice would let you know that the traffic was no longer a factor."
Terrain avoidance was implemented in December 1971. It worked as promised. In addition to the functions mentioned in Collins' note, the AP was automatically initiating and tracking all primary and secondary radar targets, and was providing display data for all traffic. The AP was programmed with about three man-years of effort, and had less than 2,800 instructions.
I was project engineer on the Knoxville experiment, and I can state, unequivocally, that what was done in Knoxville in 1971 cannot be done in any ATC system in our country today.
Based on the success of the Knoxville experiment, Goodyear Aerospace, designed, fabricated and programmed an improved version of the Knoxville computer. This machine, called the STARAN associative processor (AP), had much more capability and was programmed to function as an ATC system. It could automatically track 250 primary radar targets. Secondary radar was used for identification and altitude reporting. It contained all the functions of the Knoxville system plus radar, flight plan and display processing.
Programming STARAN was started on Jan. 4, 1972 and six programmers wrote about 7,000 instructions before the hardware was delivered to Dulles Field for the 1972 International Air Show on May 15th. It performed its design functions in about 10 % of available time, and contained simulation modes that demonstrated the very high-speed performance capabilities of the technology. The real-time database management system at Knoxville and in STARAN used a single instruction stream architecture to achieve the performance demonstrated.
Based on the success of the AP in '71 and '72, the U. S. Navy, in 1977, started a development program to design an AP for their airborne early warning command and control system in the E2C aircraft. Their goal was to be able to automatically track 2,000 aircraft based on 4,000 primary radar reports. The problem was predicted to require about 171 milliseconds in the AP. Grumman engineers programmed the tracking problem, and the measured performance was 115 milliseconds. The AP (renamed ASPRO by the Navy) became the repository for the E2C real-time database. ASPRO occupied a space of about 0.42 cu ft (including power supply and backup battery. More than 130 units were delivered to the Navy starting in 1983.
The ASPRO could have easily satisfied the AAS requirements, thus eliminating the need for the STARS program. Billions of dollars would have been saved while achieving real utility. The aircraft tracking performance shown in ASPRO, using 1978 hardware, cannot be realized in any ATC system in the Nation today! AP performance for the ATC problem is predictable. Multiprocessor performance for ATC is not predictable. All theoretical studies declare the multiprocessor solution intractable.
The AP can manage the real-time database in ATC. The capability of the AP is difficult to understand because it is so simple computers are supposed to be complex. There is not a demonstrated alternative at this time. The AP is proven!
I'd like to discuss it with you. I can be reached by phone at 678-450-4413, by email, or by postal service at: Will Meilander, APT 1110, 3801 Village View Dr. Gainesville, GA 30605.
[Go to Slide 6 of Tom Lusch's Real Targets - Unreal Displays slide show]
[Go to Slide 40 of Tom Lusch's Real Targets - Unreal Displays slide show]