APL2

Real Time Processing at the Missile Defense Agency

Customer: Northrop Grumman
Author: Jack Rudd
Country: United States of America

I worked in the field of ballistic missile surveillance from 1969 until 2003. Throughout this time, I first used APL, and then APL2, to prototype tracking and estimation algorithms that I then translated into either Fortran or Ada. Some of this work is described in my APL93 paper, "Roles of APL in Satellite Surveillance" and in the paper, "Surveillance and Tracking of Ballistic Missile Launches" in the March 1994 issue of the IBM Journal of Research and Development.

I still remember my chagrin when President Nixon signed the ABM treaty with the USSR in 1972. For some time I had been studying Soviet tests of extremely threatening strategic systems, and I loathed our official policy of Mutual Assured Destruction. My goal was not to watch hostile missiles helplessly, but instead to have the capability to destroy them before they could reach American soil.

In 2002, at long last, President Bush dissolved the ABM treaty and Congress authorized contracts to begin missile defense work in earnest. Existing programs were transitioned from research to development and deployment. Many readers will be familiar with the Ground Midcourse Defense (GMD) system that recently intercepted a target missile that mimicked a North Korean Taepo-Dong ICBM. There have also been successful intercepts of target missiles by the Navy's Standard Missile 3, and by the Army's Theater High Altitude Area Defense (THAAD) missiles. All of these systems intercept the target missile in its midcourse or terminal phase, not its boost phase.

There also arose two new development programs that are designed to destroy a hostile missile in its boost phase, before or soon after it burns out, and before it deploys decoys or other countermeasures. One of these is the AirBorne Laser (ABL).

The other is the Kinetic Energy Intercept (KEI) program, which is a hit-to-kill system like GMD, THAAD and SM-3. The main differences are that KEI has much less time to react, it needs more powerful interceptors, and it needs more sophisticated (and very fast) tracking and prediction algorithms.

My work involves the "prediction" portion of the KEI program. The objective here is to predict the future trajectory of the target missile so that an interceptor missile can be directed to the right time and place for a successful intercept. This prediction is first made shortly after the launch of the hostile missile has been detected. The prediction is then continually refined based on additional surveillance sensor inputs, so as to provide real-time directives to the interceptor missile to maneuver as necessary until its own sensors can take over.

As usual, I have used APL2 to prototype all of my work on this program, including performance testing against both real and simulated inputs. Those prediction algorithms that prove their worth are then migrated to C++ and integrated with the tracking algorithms.

Attached is General Henry Obering's letter of commendation to the CEO of Northrop Grumman regarding our team's recent work on KEI. General Obering is head of the Missile Defense Agency.

Note particularly his remark about algorithm performance. This refers to the "Tracking and Prediction" algorithms that our Boulder team developed and implemented in a real time processing system. These algorithms use sensor data in real time to track and predict the future trajectory of a threatening ICBM so as to direct KEI's interceptor to hit it before, or shortly after, it burns out (and before it can deploy decoys).

Our Prediction algorithms were first prototyped in recent years (by yours truly) in APL2. Also some of the tracking algorithms were originally prototyped in APL2. Therefore, our prototyping work using APL2 is largely responsible for Obering's remark about our ability to direct the interceptor toward where the target will be at the time of interception.

And therefore, you great folks in IBM APL Products and Services have been helping America's defense against missile attack, whether you have known it or not.

Thank you very much for all you've done over the decades.

Sincerely,
Jack Rudd

P.S. One related (and unclassified) piece of work may surprise even experienced users. I downloaded from NOAA's website a global topographical map that was partitioned as 16 large files. I then used APL2 to create from this information a single file that contains a single byte for each of 21600 latitudes and 43200 longitudes all over the globe. Each byte contains the elevation above sea level for the corresponding position on the globe, with a vertical resolution of 35 meters. (Thus covering the range from sea level to the peak of Mount Everest.)

This file contains nearly one gigabyte of data, and it is used as a simple lookup table. Given any latitude and longitude, to a resolution of 1/120 of a degree, one locates and reads a single byte from this file to obtain the corresponding elevation above sea level. Statistically it turns out that APL2's Auxiliary Processor 210 takes no more time than C to obtain this value (at least under Windows).

Thus neither workspace memory nor cycle speed nor auxiliary storage access time was a limiting factor for using APL2 for this rather large problem. This will likely come as a surprise to many, and I hope it helps counter some ancient myths about APL performance.

General Obering's letter: