This paper begins with an overview of system requirements and design issues that must be considered in the design of algorithms and software for the surveillance and tracking of ballistic missile launches. Detection and tracking algorithms and approaches are then described for the processing of data from a single satellite and from multiple satellites. We cover track formation, missile detection, track extension, and global arbitration, and indicate how these functions fit together coherently.

Several years ago the U.S. Department of Defense created its Defense Science Board Task Force on Military Software, chaired by Dr. Frederick Brooks, to provide recommendations on how best to solve the problem of escalating military software acquisition costs. The final report (reference 2) of this task force was completed in September 1987, and was widely distributed. Among its several major conclusions are the following: DoD Directive 5000.29 and STD 2167 codify the best 1975 thinking about software, including a so-called 'waterfall' model calling for formal specification, then request for bids, then contracting, delivery, installation, and maintenance. In the decade since the waterfall model was developed, our discipline has come to recognize that setting the requirements is the most difficult and crucial part of the software building process, and one that requires iteration between the designers and users. In best modern practice, the early specification is embodied in a prototype, which the intended users can themselves drive in order to see the consequences of their imaginings. Then, as the design effort begins to yield data on the cost and schedule consequences of particular specifications, the designers and the users revise the specifications. Directive 5000.29 not only does not encourage this best modern practice, it essentially forbids it. We recommend that it be revised immediately to mandate and facilitate early prototyping before the baseline specifications are established. DoD STD-2167 likewise needs a radical overhaul to reflect best modern practice. Draft DoD STD 2167A is a step, but it does not go nearly far enough. As drafted, it continues to reinforce exactly the document-driven, specify-then-build approach that lies at the heart of so many DoD software problems.

No abstract

No abstract

PurposeThe purpose of this programming effort is to build a r&able, automatic, special-purpose translator from APL code into Ada code.'The goal is to enable an algorithm designer to prototype an algorithm rapidly, debug it, and test it in APL (specifically, APL2); then to translate it quickly, compile it, and execute it in the Ada environment. This gives the dual advantages of the quick and easy development and debugging capabilities of APL2 and the large-project maintainability of the Ada environment. An additional benefit is to minimize the amount of debugging in Ada, which in turn minimizes the number of resource-intensive Ada compilations.Since both APL and Ada are very general, powerful languages, developing a general or complete translator from one to the other would be a tall order indeed. For practical reasons this effort has been restricted to translating mathematically oriented algorithms which might normally be developed using only static, rectangular arrays with floating point and integer types. Many algorithms used in military software applications today are in this category.Of course, both APL and Ada easily accommodate dynamic (non-static) arrays, and it is desirable in many situations to program in a manner which uses this capability. The main penalty is an increase in computer resource requirements, which the project at hand (DSP System 1 Mission A) cannot tolerate. Thercforc, the judgcment call was to emphasize static arrays.An additional consideration was that since the resulting Ada code is intended for real-time use, the translator must not introduce artificial incfftcicncies of execution in the resulting Ada code. The APL user must be able to create APL code which will be translated into Ada code which is as efftcient as an Ada programmer would be expected to generate manually.Finally, the user should also have a high degree of control over the readability of the resulting Ada code, At a minimum, APL comments should be translated appropriately into Ada comments. The Ada control statements used should be among the most natural for the application. Also, standard code indentation should be applied.