Evolution of the NAVSPACECOM Catalog Processing System Using Special Perturbations

Transcription

1 Evolution of the NAVSPACECOM Catalog Processing System Using Special Perturbations Paul W. Schumacher, Jr. 1 and Felix R. Hoots 2 Abstract Recently the Naval Space Command (NAVSPACECOM) has developed a capability to perform special-perturbations orbit determinations and predictions on a large subset of the satellite catalog. In addition, they continue to perform catalog maintenance on the entire satellite catalog using the PPT3 general perturbations orbit model. In the near future, NAVSPACECOM will begin to maintain the entire satellite catalog using special perturbations. At that point in time, they will be in a position to discontinue use of the general perturbations model for catalog maintenance. However, almost every application in the Naval Space Operation Center (NAVSPOC) at NAVSPACECOM depends on use of the general perturbations model. Therefore, the transition from a general perturbations catalog to a special perturbations catalog is more than just a change in orbit determination and prediction models. This paper identifies the ephemerisdependent applications present in the NAVSPOC, addresses alternatives for how to transition to use of special perturbations vectors, and discusses how to support current users of the general perturbations element sets. 1.0 Introduction Although the satellite catalog has long been maintained with a moderately accurate general-perturbations (GP, or analytical) orbit model, it has been known for an equally long time that highly accurate special-perturbations (SP, or numerical) models are the preferred way to represent orbital motion. In 1961, the Naval Space Surveillance System (NAVSPASUR), predecessor to NAVSPACECOM, began formal operations, detecting space objects with the Fence radar interferometer system and maintaining the satellite catalog with one of the most powerful computer processing systems of the era. In fact, the NAVSPASUR facility was located in Dahlgren originally so that it could share the computer, the so-called Naval Ordnance Research Calculator (NORC), which was already installed at the Dahlgren Proving Ground [1]. In those days, it was easier to move people than to move computers. During the development period from 1958 to 1960, a number of processing methods were examined for the NAVSPASUR mission. In particular, SP models were tried for the catalog maintenance function, but these had to be abandoned. Even though the NORC was the most powerful computer of its day, several hours were needed to compute an updated orbit for a single satellite using SP methods [2]. The same job could be done in minutes, though with relatively poor accuracy, using GP methods. Although the speed and capacity of computers has increased by many 1 Naval Space Command, Dahlgren, Virginia. schumach@nsc.navy.mil 2 GRC International, Vienna, Virginia. fhoots@grci.com

2 orders of magnitude since 1961, the number of trackable space objects also has increased by nearly four orders of magnitude. The net result has been that, until recently, GP methods had to be used to maintain the satellite catalog, regardless of what accuracy might have been desired in the orbit solutions. Whenever higher accuracy has been needed for some particular satellite, analysts have used SP techniques in an ad hoc way without disturbing the automatic GP catalog maintenance process. In effect, because of its high computational requirements, SP orbit determination has always been merely another space surveillance application rather than part of the catalog maintenance operation. This situation changed in 1997, with the availability of new computer techniques to remove the SP processing bottleneck and with the emergence of new operational requirements to do so. Since 1993, workers at NAVSPACECOM and Naval Research Laboratory have been experimenting with distributed parallel processing for computation-intensive space surveillance applications. These parallel techniques use special software to coordinate the simultaneous execution of an application program on the individual processing nodes of a computer network. Essentially, this approach allows the network to emulate the operation of a supercomputer, though without the very high processor-to-processor data transfer speeds that are characteristic of supercomputers. It turns out that, if the application does not involve extensive inter-process communication, then the actual computational speedup is almost proportional to the number of processors on the network, and impressive performance gains can be realized without a supercomputer. Most space surveillance applications happen to fall into this agreeable category of problems. Among the early successes in this work were demonstrations (and some real operational use) of parallel algorithms for many-to-all and all-to-all conjunction predictions [3] and for dataassociation processing of uncorrelated targets [4]. The plan for 1997 had been to demonstrate catalog maintenance using an SP orbit model in place of the GP orbit model. Interest in the SP catalog maintenance problem redoubled when, in August 1997, NASA published new requirements for space surveillance support of manned space flight operations [5]. These requirements, which are discussed later, implied nearly instant availability of SP orbit solutions for any object in the satellite catalog, on a permanent and continuous basis. The capability to produce and communicate these SP solutions was needed before the launch of the first element of the International Space Station, which turned out to be in July In response, the SP catalog development activities at NAVSPACECOM during 1997 culminated in an extended demonstration in December of that year [6]. Approximately 8800 satellite orbits were maintained for 30 days using distributed parallel processing on a 26-node sub-network partitioned out of the NAVSPACECOM operational computer system. This demonstration system processed all the same observations as the operational GP-based system. However, the GP system supplied all data-association processing for the demonstration since the purpose was to show how the necessary throughput for SP orbit determination could be achieved at low cost. The shift from GP-based processing to SP-based processing has a number of important implications besides the obvious gain in prediction accuracy for all cataloged

3 objects. The shift is really from a model-limited system to a data-limited system. Using only GP orbit models, which may have kilometers of inherent prediction error, it is not possible to extract all the information present in the current space surveillance tracking data, most of which are precise to within hundreds of meters. No amount of high-quality data will improve the catalog accuracy beyond the limitations of the GP model itself. On the other hand, SP models have only meters of inherent error (except possibly for atmospheric drag effects), so the data can be more fully exploited. With an SP model, the catalog accuracy is limited mainly by the amount and quality of the data available. The result is that maintaining an SP-based catalog encourages the best use of the existing computer systems, sensor systems, and observational data. Moreover, the SP catalog encourages sensor system improvements that would not have been worthwhile if only GP accuracy were available to end users of the catalog. Along with the gain in prediction accuracy, the SP catalog also enables a realistic assessment of prediction uncertainty for all cataloged objects. This is something that has not been within reach until now. When the physical model of satellite motion has large inherent errors, as a GP model often does, the job of adequately characterizing the model uncertainty becomes too complicated to carry out in practice. With an SP model, this job, though still complicated, can be done, mainly because the inherent errors are much smaller. At the same time, regardless of the model used, space surveillance observational uncertainties can be characterized through the use of highly accurate calibration reference orbits for a few satellites [7]. As a result, the prediction error covariance matrix, which depends on both the observational errors and the model errors, can be estimated with reasonable confidence for an SP orbit solution, whereas the same confidence cannot be achieved in practice for the less accurate GP predictions. This fact implies that the SP catalog can enable realistic assessments of collision risk in close conjunctions, reliable tracking discrimination when cataloged objects are close together, and reliable acquisition or avoidance of any cataloged objects by laser systems. These are fundamentally new capabilities that have profound implications for both civil and military space control. They provide ample justification for trying to build the best possible SP cataloging system. 2.0 Requirements for the SP Catalog The SP catalog development at NAVSPACECOM is partly a natural evolution, given the drastic increase in computer performance per unit cost in recent years and the continual need to make the best use of data from existing sensor systems. However, the single biggest impetus for the current SP work has been new requirements from NASA for manned orbital flight safety [5]. Although the space control mission, including space surveillance, is a military mission administered under formal military requirements, United States Space Command (USSPACECOM) and it service components do provide support to civil space missions under a Memorandum of Agreement with NASA [8]. There are also military requirements for space control that imply the need for a complete SP catalog together with an extensive set of improvements throughout the space surveillance sensor network. However, these military requirements are different from the

4 NASA requirements and their purpose is, among other things, to foster long-term developments in space surveillance capabilities. In contrast, the NASA requirements call for immediate developments to support current manned space flight on the Space Shuttle and the International Space Station. USSPACECOM and its service components have endeavored to accommodate the NASA requirements under the Memorandum of Agreement on a basis of best effort within resources available, not to interfere with primary military mission. The complete set of NASA requirements for space surveillance support is extensive. Here we note and discuss only those items that most clearly show the need for an SP catalog. The main application of the present SP catalog is to warn NASA flight controllers of impending close approaches between the Space Station and any known space objects so that evasive maneuvers can be considered. To this end, NASA has specified the following requirements, in no particular priority order. (1) The orbital prediction accuracy should correspond to a standard deviation of 5 meters in semimajor axis for low-earth-orbit (LEO) objects. This translates into about 50 meters per revolution in-track error on a circular orbit, or about 700 meters per day in-track error for most LEO objects. Only SP orbit solutions can achieve this level of accuracy consistently. (2) Notice of possible close approaches to the Space Station should be given at least 72 hours in advance. SP orbit solutions are needed to maintain the best possible prediction accuracy this far in the future, to avoid both excessive under-alerting and overalerting. (3) On-demand reporting of current conjunction estimates is needed within 1 hour. This timeline cannot be met reliably if the SP orbit solutions are generated on-demand at the time of the request. The SP solutions must be maintained continuously. (4) Conjunction assessments are needed for objects whose perigee altitude is at or below 600 kilometers. This covers the altitude regime of interest for the Space Station, and includes about 2000 objects from the current catalog of more than 9000 objects. Having developed the capability to maintain a catalog of 2000 objects with an SP orbit model, one finds that the entire current catalog can be maintained at low additional cost. (5) Conjunction assessments must include the covariance matrices for the orbits, reckoned at the time of conjunction. Realistic covariance information can be provided with SP orbit solutions, but not with GP solutions, as discussed previously. (6) The catalog of objects to be screened for conjunctions with the Space Station should have a threshold object size of 5 centimeters in the near term and 1 centimeter in the far term. This requirement stems from inability to shield critical Space Station modules against penetrations by objects larger than 1 centimeter. However, the current catalog is very incomplete for objects smaller than about 30 centimeters because of fundamental sensor limitations. In the near term, nothing can be done about

5 this gap in detection capabilities. The Space Station program has to accept the extra risk. In the far term, sensor improvements may allow the detection and cataloging of small objects, but the potentially vast numbers of small space objects is a concern for the cataloging system. While SP accuracy would be needed to discriminate among objects reliably when there are many of them, the data-association processing load goes up exponentially with the number of objects. (7) Though not explicitly stated, there is an implied requirement that conjunction alerting for the Space Station have a low false-alarm rate. Maneuvering disrupts the Space Station missions, and excessive maneuvering prevents some missions, such as micro-gravity research, from being accomplished. Hence, the SP catalog must, without firm specifications, allow realistic conjunction assessments, neither over-alerting nor under-alerting. NASA uses the covariance matrices produced with the SP orbit solutions to estimate the probability of collision in a close conjunction, and decides to maneuver based on pre-established thresholds in the probability. However, it is known that the calculated probabilities are sensitive to errors in the covariance matrices [9]. Small errors in the covariance matrices can lead to large errors in the calculated probability. The result is that the SP catalog must always be as accurate as possible and both the observational errors and the model errors must be characterized as completely as possible. 3.0 The Present SP Cataloging System The phased development of the SP cataloging system at NAVSPACECOM aims, first of all, to provide continuity of space surveillance operations. At present, the SP catalog is maintained in addition to the regular GP catalog and no modifications have been made to the GP-based operational system. The SP catalog therefore requires extra computers, software maintenance, analysts and training. These additional costs and complications are, in fact, the main motivation for considering more cost-effective future configurations for the system. Moreover, the present SP system supplies only orbit determination processing. All other catalog maintenance functions and space surveillance applications, including data-association processing for the entire catalog, sensor tasking for the entire space surveillance network, and naval fleet support applications, are executed by the GP cataloging system. The current SP catalog is based on the same observations as the GP catalog. However, for the SP orbit determination, the observations are weighted by sensor calibration statistics in order to account for variable measurement uncertainties. The present SP orbit determination also includes a fixed-percentage consider parameter in the covariance of the ballistic coefficient to account for some dragrelated orbit model uncertainties. The GP orbit determination is, by comparison, an unweighted batch least-squares update, with no accounting for model uncertainties. At this writing, the operational SP catalog at NAVSPACECOM includes only those orbits with perigee altitude at or below 550 kilometers, for a total of about 1200 objects. This limitation is accepted temporarily while the full-catalog capability is being tested, in order to reduce the number of human analysts needed.

6 3.1 Dataflow for Present GP Catalog Maintenance The present SP catalog depends on the GP-based cataloging system, so we first describe that system briefly (Figure 1). Space Environment Dataflow for GP Catalog Maintenance 3% SSN sensor ops SSN obs tagged + untagged SSN obs proc. untagged 97% tagged auto verify NO < 3% auto id./ retag NO 40% 1 GP el per ob YES > 97% all per ob YES 60% External customers auto sensor tasking GPels proc. known obs/ database UCT processing Space Environment 97% known obs good GPels 98.5% Fence sensor ops Fence raw data 100% untagged SSN handoff Fence obs proc. 1-pass state vector 3% unknown obs Auto GP Bad 1.5% Manual GP obs/ Figure 1 The cataloged GP element sets and all observations are stored in a central database. When new observations arrive from the Fence, they have not been associated ( tagged ) with a satellite number. To make the association, a time-ordered list of precomputed Fence crossings is examined to see which crossing best accounts for the observation in terms of time, apparent sighting angle within the Fence beam and Doppler shift of the signal. These crossings have been predicted using the most recent element sets available for each satellite. Ordinarily, about 97% of all Fence observations can be associated with cataloged element sets in real time. The remaining 3%, the unidentified observations, are passed to a more refined data association process where each one is checked against the entire catalog.

7 When new observations arrive from other space surveillance network (SSN) sensors, a satellite number is included in about 97% of cases. For each of these, the data association is verified against the most current element set for the satellite. If the observation s nominal association cannot be verified, or if the observation was unassociated to begin with, then it is checked against the entire catalog. In the case of unverified or unassociated observations, about 60% can be identified as belonging to some cataloged element set when the entire catalog is searched. The remaining 40% are subjected to so-called uncorrelated target (UCT) processing. Here initial element sets are generated directly from the observations and an extensive set of association hypotheses is investigated. Human expertise is indispensable for UCT processing because a variety of unforeseeable events may have occurred: the satellite may have been lost for some time or may have maneuvered; a satellite may have broken up into dozens or hundreds of trackable pieces; the element set may have been corrupted somehow; or the GP model may simply be inadequate to represent the motion of certain decaying or otherwise unusual objects. Ultimately, candidate element sets are produced by a manually controlled differential correction () process and are maintained by human analysts until they meet certain criteria for automatic maintenance. Periodically, if new observations have arrived for a satellite, the cataloged element set is updated in an automatically controlled process. On average, about 98.5% of the cataloged GP element sets are successfully updated without human intervention. However, because the least-squares process may fail for a variety of reasons, analysts must examine the remaining 1.5% of cases individually to diagnose and fix the cause of the failure. Approximately once per day, updated element sets are transmitted to the other SSN sensors, along with assigned priorities for the next day s tracking schedule. This sensor tasking assignment closes the catalog maintenance loop, because the sensors use the new element sets to acquire their targets and produce more observations. It is important that the tasked sensors have current element sets so that they can find and identify their targets with high probability. Any serious delay in transmitting updated elements to the sensors can result in either no new observations being reported for some satellites or excessive numbers of unassociated observations being reported. The Fence is unique among USSPACECOM space surveillance sensors in that it is not tasked; rather, it reports unassociated observations on all objects in its field of view. The NAVSPOC at Dahlgren must then perform the data association processing in real time in order to keep up with the Fence data flow. 3.2 Dataflow for Present SP Catalog Maintenance The present SP cataloging process is added on to the GP cataloging process just described. In Figure 2, the database of known observations and GP element sets is the same one shown in Figure 1. However, the associated dataflow for GP catalog

8 maintenance is not depicted here, for the sake clarity. It is understood that the GP processing continues as described above. Dataflow For SP Catalog Maintenance (1) Reference Orbits GP maintenance continues Sensor Data Calibration known obs/ database obs weights & biases obs obs Auto SP bad SP 10% Manual SP good SP 90% External Customers SP Proc. SP vectors database Figure 2 Twice per day, an automatic SP differential correction process updates state vectors for each satellite, using the same observations that are used for the GP catalog. On average, 90% of the state vectors are updated successfully without human intervention, leaving 10% for human analysts to investigate. This success rate is markedly lower than for the GP catalog, for a variety of reasons. First, the success criteria are more stringent than for the GP process. Second, the software implementation is complicated and relatively immature. Third, less human analyst time is available for the SP catalog in the current phase of development. Lastly, only those orbits with perigee altitudes below 550 kilometers are currently being maintained. This population has a higher percentage of difficult-to-maintain orbits than the catalog as a whole does, mainly because of decaying orbits. We expect that ultimately the whole SP catalog will be maintained automatically with about the same success rate as the GP catalog, based on experience with the December 1997 demonstration [6]. A special feature of the SP catalog update is that the observations are treated differently than for the GP catalog. Weights and biases for each sensor are calculated by comparing surveillance observations with highly accurate reference orbits derived from satellite laser ranging data [7]. These laser data are obtained through a NASA scientific

9 program designed to monitor tectonic plate motions in the crust of the Earth. The data are archived at Goddard Space Flight Center and downloaded daily by analysts at Naval Research Laboratory for the space surveillance reference orbit generation. Reference orbits for approximately 20 different satellites are available at any one time, given the current level of scientific activity in crustal dynamics. The SSN sensors are assigned special tasking to track these satellites frequently in order to obtain a good statistical basis for sensor data calibration. The calibration weights and biases then provide a characterization of the measurement errors in the observations. Note that all the present SP catalog maintenance functions except the actual differential correction itself are supplied by the GP cataloging system. The better accuracy of the SP catalog is not available for either data association or sensor tasking, and is not available to most external customers of the catalog. These deficiencies lead us to consider the strategy for SP developments in the future. 4.0 Transitioning from Two Catalogs to One The cost of maintaining two separate catalogs is high enough to be of concern to NAVSPACECOM even in the short term. We now consider the basic issues involved in trying to avoid this duplication of effort. 4.1 The Problem The catalog both requires and supports many different applications. A few of these are: Orbit update via differential correction Observation verification, identification and retagging UCT processing Sensor tasking Conjunction assessment Orbital decay prediction and re-entry assessment Laser clearinghouse analysis Fence predictions Naval fleet and other military support Special requests and testing Although this list is by no means exhaustive, it should help illustrate why, with a catalog size approaching 10,000 objects, the GP orbit model is executed on the order of 10 7 times per day at NAVSPACECOM. If the SP model eventually has to be executed this many times per day, the computer requirements become a major concern even if we assume that parallel processing is used maximally. Moreover, the required predictions are not always in time order. This fact does not matter with the GP model, because every prediction involves essentially only one time step. However, repeatedly integrating

10 forward and backward over many time steps with the SP model causes a noticeable extra computation load. We are therefore led to consider some intermediate representations of the SP ephemeris, rather than a direct numerical integration to every prediction time. 4.2 Options We have not tried to assess all possible options for representing an SP ephemeris. Instead, we have concentrated on well-understood techniques that we believe could be implemented in the near term. (1) Ephemeris compression could be used to reduce every SP ephemeris to a set of polynomial and Fourier coefficients valid over a fixed interval of time. In our experience, 40 to 50 coefficients permit one to match the numerically integrated orbit to within about 100 meters over reasonably long intervals. Predictions with the coefficients are no more expensive to compute than a GP prediction. However, the prediction accuracy degrades rapidly outside the original interval for which the coefficients were derived. (2) An ephemeris array can be used to store the ephemeris points for both the data fitting interval and whatever prediction interval is required, at the time of the orbit update. Subsequent predictions are then mere interpolations in the array and are faster than GP predictions. We have found that a 1-minute step size typically allows less than 10-meter interpolation error, if the interpolating polynomial is chosen carefully. Of course, vast amounts of computer memory would be required to store the entire catalog as an ephemeris array. (3) GP pseudo-elements can be constructed by fitting mean elements to the SP ephemeris rather than to the observations. Logically, the current GP model would be used for this purpose. This model is capable of matching the SP ephemeris to within 700 meters to several kilometers over reasonably long time intervals. Unlike predictions with ephemeris compression coefficients, predictions with GP pseudo-elements tend to degrade slowly outside the interval for which they are defined. Moreover, no changes would be needed in any existing application software that currently uses GP elements. 4.3 Recommendation We believe that, of the above choices, the ephemeris array is the best method of representing SP-derived orbits. It is the only method that efficiently retains the full SP accuracy. At the same time, the cost of the extra computer hardware is not prohibitive. GP pseudo-elements should be used on an interim basis. The basic idea is illustrated in Figures 3 and 4. In a phased development of this recommendation, GP pseudo-elements could first be generated at the completion of every successful SP update (Figure 3). The SP ephemeris need not be stored permanently at this stage. The pseudo-elements then replace the GP elements that are currently being derived

11 from observations. No GP catalog maintenance is required. Some recent analysis has shown that the pseudo-elements often are more accurate in the prediction interval than are GP elements determined directly from real observations, apparently because of the smoothing effect of the SP orbit determination [10]. In a later stage of development, the permanent ephemeris array for the entire catalog could be implemented (Figure 4). GP pseudo-elements could still be generated as needed for certain external customers and applications; however, the SP catalog maintenance and all related internal applications could be based on predictions interpolated from the ephemeris array. Few architectural changes would be needed in the catalog software system. Since every call of the GP-model software returns basically only a prediction for a given time, the interpolation routine can be structured to do the same thing without affecting the rest of the application. Dataflow For SP Catalog Maintenance (2) Reference Orbits no GP maintenance needed Sensor Data Calibration known obs/ database generation special Proc. special External customers obs weights & biases obs obs Auto SP bad SP 10% Manual SP good SP 90% External Customers SP Proc. SP vectors database SP ephemeris, Each satellite Figure 3

12 Dataflow For SP Catalog Maintenance (3) Reference Orbits no GP maintenance needed Sensor Data Calibration known obs database generation special Proc. special External customers obs weights & biases obs obs obs auto Verify / id External Customers SP Proc. Auto SP bad SP 10% good SP 90% SP vectors database Manual SP predictions interpolator instead of GP propagator SP ephemeris array, All satellites Fence obs Proc. UCT Proc. sensor tasking Figure Supporting External Users of the Space Catalog The catalog serves a very wide variety of military and civil applications. Direct primary customers number almost a thousand, while no estimate is available for the number of indirect or secondary users that depend on the public version of the catalog made available through NASA Goddard Space Flight Center. Supporting all these customers with the SP catalog is a prime concern. 5.1 The Problem Continuity of operations is vital to all external users of the catalog. At present, and for the foreseeable future, most users can accept only GP element sets, not SP state vectors, for their applications. On the other hand, most users would benefit from the improved accuracy of the SP state vectors. We are therefore led to consider the implications of the SP catalog from a customer s point of view. 5.2 Options Here again, we have not tried to consider every possible option. We have concentrated on those that we believe could be implemented in the near term.

13 (1) SP state vectors could be declared the standard product for all users. This draconian approach does present the customers with the best possible accuracy, plus the realistic prediction uncertainty information available in the state covariance matrix. However, some primary users and many secondary users would be left unsupported indefinitely. For every user, all new application software and message formats would be required. (2) GP pseudo-elements could be published instead of GP elements determined from observations. All the advantages of pseudo-elements mentioned above apply here. Moreover, no new user software or message formats would be required. (3) Ephemeris compression could be used to supply customers with coefficients instead of GP elements. Somewhat better accuracy is available with ephemeris compression than with pseudo-elements, and the execution speed is about the same as for a GP model. However, new user software and message formats would be required. (4) Perform application services for selected users in an on-line client-server arrangement. If users could connect to a server containing the SP catalog and application software, they could get the SP accuracy directly without hosting software of their own. No new user application software or message formats would be required. Moreover, new user applications would be possible that are infeasible for most users to host now, such as many-to-all conjunction assessments. This option does imply an extra user-support investment at NAVSPACECOM that is not being made now. 5.3 Recommendation Of these choices, we believe that GP pseudo-elements are the best choice for general customer support in the near term. The facts that the change would be completely transparent to all users and that they would get a noticeably improved product are decisive. However, we believe that client-server support is the best way to accommodate selected high-priority users. 6.0 Some Remaining Issues Some important questions remain to be answered. Although the answers will affect the future development of the SP catalog, it is beyond the scope of this discussion to suggest any answers. We simply note the following issues, in no particular priority order. If sensor systems are deployed that can, with high probability, detect 5-centimeter sized targets in LEO, the number of trackable space objects may grow from 10,000 to as many as 30,000 or 50,000. How do we build a catalog of this size from millions of

14 unassociated observations? The job has never been done before, because the present catalog has been maintained since the first satellite was launched. How do we use the realistic state covariance that will soon be available with every SP state vector? At present, the only use is in calculating collision probabilities for manned spacecraft. We could equally well consider calculating collision probabilities for all payloads. We could use the state covariance in more robust data association methods. We could also calculate probabilities of acquisition or avoidance of any cataloged object by laser systems. Given these possibilities, should the covariance be stored in the ephemeris array, greatly increasing the computer memory requirements, or should it be generated on demand? Additionally, how should covariance information be made available to general external customers? Finally, the current sensor tasking method was developed to support a GP catalog of limited and hard-to-measure accuracy. How do we optimize the sensor tasking to support an SP catalog? We could, for example, consider tasking the sensors to maintain desired precision in the state vectors as well as desired accuracy, with the covariance matrices providing the measures of precision. In any case, using the surveillance sensors most efficiently must be a prime concern for all future space control operations. Development of the SP catalog is perhaps the single most cost-effective step that could be taken in this direction at present. Conclusion The development of the present SP catalog at NAVSPACECOM has been reviewed. Several key issues related to the future development of the SP catalog have been discussed. Some feasible strategies for transitioning to a single SP-based cataloging system have been outlined, and some of the implications for customer support have been discussed. No major technical impediments to developing an extremely robust and accurate cataloging system have yet been identified. Acknowledgement The authors gratefully acknowledge the many helpful comments made by Mr. John Seago of Honeywell Technology Solutions, Inc., on an earlier draft of this paper. References [1] Raymond H. Hughey, Jr., History of Mathematics and Computing Technology at the Dahlgren Laboratory, Naval Surface Warfare Center (Dahlgren Division) Technical Digest, 1995 issue, pp

15 [2] Private communication, 23 June 1998, with Robert Cox, former Analysis and Software Department Head at NAVSPASUR, by Gary Van Horn of GRCI. [3] Liam M. Healy, Close Conjunction Detection on Parallel Computer, Journal of Guidance, Control and Dynamics, vol. 18, no. 1, July-August 1995, pp [4] Shannon L. Coffey, Edna Jenkins, Harold L. Neal, Herbert Reynolds, Parallel Processing of Uncorrelated Observations into Satellite Orbits, AAS Paper , AAS/AIAA Space Flight Mechanics Meeting, February [5] Letter from NASA Administrator (Daniel S. Goldin) to Commander in Chief, United States Space Command (Gen. Howell M. Estes, USAF), 27 August [6] Shannon L. Coffey, Harold L. Neal, Cynthia L. Visel, Pete Conolly, Demonstration of a Special-Perturbations-Based Catalog in the Naval Space Command System, AAS Paper , AAS/AIAA Space Flight Mechanics Meeting, 9-11 February 1998, Monterey, California. [7] Paul W. Schumacher, Jr., G. Charmaine Gilbreath, Edward D. Lydick, Mark A. Davis, John H. Seago and Stephen G. Walters, Design for Operational Calibration of the Naval Space Surveillance System, American Astronautical Society Paper , Advances in the Astronautical Sciences, Vol. 99, Spaceflight Mechanics [8] Memorandum of Agreement Between United States Space Command and Johnson Space Center for Space Control Operations Relationship, Space Shuttle Program Support and International Space Station Program Support, 10 April 1996, by Roger de Kok, Director of Operations for United States Space Command and George W. S. Abbey, Director, Lyndon B. Johnson Space Center. [9] K.T. Alfriend, M.R. Akella, D.J. Lee, M.P. Wilkins, J. Frisbee and J.L. Foster, Probability of Collision Error Analysis AIAA Paper , AIAA/AAS Astrodynamics Specialist Conference, Girdwood, Alaska, August [10] Mathew P. Wilkins, Kyle T. Alfriend, Shannon L. Coffey, and Alan M. Segerman, Transitioning From a General Perturbations to a Special Perturbations Catalog, AIAA Paper , AIAA/AAS Astrodynamics Specialist Conference, August 2000, Denver, Colorado.