3

Systems Issues

Tracking satellites requires efficient collection, processing, distribution, and interpretation of data throughout the system, including its user community. Figure 3.1 is a simplified depiction of data flow both into and out of the Joint Space Operations Center (JSpOC). Inputs on the left side include various sensor measurements augmented by owner/operator ephemerides. The output products include Special Perburbations (SP)-based vector covariance messages, general perturbations (GP)-based two-line element sets, and SP-based conjunction summary messages and orbital conjunction messages. Note that tracking data from owners/operators currently cannot be ingested, and using owner/operator ephemerides requires manual intervention.

Although the Air Force Space Command’s (AFSPC’s) standardized astrodynamics algorithms are a set of algorithms defined in specific computer codes, they must function in a system-of-systems environment. Many issues and considerations come about as the needs and requirements of all these different systems weigh upon the single set of standardized algorithms. This chapter looks at architecture, interoperability, and automation as areas that include the use of standard algorithms but are broader than the algorithms themselves, and also looks at personnel.

ARCHITECTURE

As is described in Chapter 1, the historical Delta, 427M, and Space Defense Operations Center (SPADOC) computer systems were traditional Air Force acquisitions that took decades to develop and deploy. They were also developed as closed systems on proprietary hardware with customized software and operating systems. The standardized astrodynamics algorithms were deeply embedded in the operational software in these systems, which were tightly configuration-controlled. Because of the difficulty of making changes to the large SPADOC system on the mainframe computer, a separate astrodynamics support workstation was deployed as an operational prototype to allow enhancements to the standardized algorithms and to maintain a high-accuracy special perturbations-based catalog. The astrodynamics support workstation was developed on the off-line system called CAVENet (Command, Analysis, Verification and Ephemeris Network), consisting of Silicon Graphics Incorporated servers and workstations.

Finding: The existing Air Force system architecture was originally designed for internal purposes using mainframe computer hardware and deeply embedded algorithms. As such, it is difficult to infuse new technologies and capabilities into the system and to extract algorithms for external distribution.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 44
3 Systems Issues Tracking satellites requires efficient collection, processing, distribution, and interpretation of data throughout the system, including its user community. Figure 3.1 is a simplified depiction of data flow both into and out of the Joint Space Operations Center (JSpOC). Inputs on the left side include various sensor measurements augmented by owner/operator ephemerides. The output products include Special Perburbations (SP)-based vector covariance messages, general perturbations (GP)-based two-line element sets, and SP-based conjunction summary messages and orbital conjunction messages. Note that tracking data from owners/operators currently cannot be ingested, and using owner/operator ephemerides requires manual intervention. Although the Air Force Space Command’s (AFSPC’s) standardized astrodynamics algorithms are a set of algorithms defined in specific computer codes, they must function in a system-of-systems environment. Many issues and considerations come about as the needs and requirements of all these different systems weigh upon the single set of standardized algorithms. This chapter looks at architecture, interoperability, and automation as areas that include the use of standard algorithms but are broader than the algorithms themselves, and also looks at personnel. ARCHITECTURE As is described in Chapter 1, the historical Delta, 427M, and Space Defense Operations Center (SPADOC) computer systems were traditional Air Force acquisitions that took decades to develop and deploy. They were also developed as closed systems on proprietary hardware with customized software and operating systems. The stan - dardized astrodynamics algorithms were deeply embedded in the operational software in these systems, which were tightly configuration-controlled. Because of the difficulty of making changes to the large SPADOC system on the mainframe computer, a separate astrodynamics support workstation was deployed as an operational prototype to allow enhancements to the standardized algorithms and to maintain a high-accuracy special perturbations-based catalog. The astrodynamics support workstation was developed on the off-line system called CAVENet (Command, Analysis, Verification and Ephemeris Network), consisting of Silicon Graphics Incorporated servers and workstations. Finding: The existing Air Force system architecture was originally designed for internal purposes using mainframe computer hardware and deeply embedded algorithms. As such, it is difficult to infuse new technologies and capabilities into the system and to extract algorithms for external distribution. 44

OCR for page 44
45 SYSTEM ISSUES Space SSN (SBSS) Radars Sensors Tracking Tasking, Data Public GP elsets Tracking Server Data GP elsets DOD and USG Op cs GP elsets users Tracking SP VCM’s Data Manual outputs SPADOC ASW servers Conjunc on mainframe users Owner OCM,CSM Antennas data USG DoD Not yet Commercial possible Manual inputs JSpOC data flow Owner 2011 Ephemeris FIGURE 3.1 JSpOC data flow showing tracking data inputs and data product outputs. Solid lines indicate automated data handling, and dashed lines indicate the need for some level of manual intervention. SOURCE: Based on material in JSpOC presentations to the committee. Figure 3-1 Realizing the limitations of the SPADOC systems, AFSPC is currently developing a new, more flexible system called the JSpOC Mission System (JMS). It is being developed with an open, service-oriented architecture on commodity hardware using network-centric interfaces. The development time of such modern systems is poten - tially greatly reduced compared to the traditional acquisition approach, with the added advantage of providing a more flexible and extensible system. In particular, the commodity hardware with multiple node server design allows easy scaling of computational capabilities as the space catalog grows, and new algorithms can be much more easily implemented. Finding: The Air Force recognizes that any new system architecture must be scalable in both hardware and software in order to meet the increasing demands imposed by catalog growth and new mission responsibilities. JMS is intended not only to improve the hardware architecture supporting space situational awareness, but also to modernize the software architecture and enhance the accuracy of the products generated on a routine basis. The suite of standardized algorithms and software for the catalog maintenance aspect of space situational awareness has been maintained by A9, the Analysis Directorate of AFSPC. A9 has been the conduit for providing and maintain - ing the standardized astrodynamics algorithms to the external user community. However, AFSPC/A9 has not been adequately funded to maintain and upgrade the standardized software and to develop documentation. Further, it has not been possible for A9 to easily insert newer technology into the existing hardware, software, or processing system because of complications associated with maintaining compatibility with the external user community. This conundrum is borne out by the fact that the SPADOC workhorse analytical orbit propagation software, Simplified General Perturbations 4 (SGP4), and the SPADOC numerical Special Perturbations algorithm have not

OCR for page 44
46 CONTINUING KEPLER’S QUEST—ASSESSING AIR FORCE SPACE COMMAND’S ASTRODYNAMICS STANDARDS been substantially improved in software or hardware technology in more than 20 years 1,2 even though, internally on the astrodynamics support workstation off-line platform, considerable improvement of the special perturbation orbit determination and orbit propagation has taken place over the past 10 years. (These improvements have been reflected only in updates to the astrodynamics standardized codes distributed to specific users who could take advantage of them.) Unlike in conventional, commercial software companies, in the Air Force system the concept of “pushing” or forcibly distributing improved software to user hardware is not practicable. Users of AFSPC software have different needs and do not have standard hardware, and, equally important, most users bury the standardized software in an overarching system that serves their particular uses. For example, a radar system 3 has a large body of command, control, and processing software within which AFSPC software is only a small percentage (<10 percent) of the code. AFSPC also has to be cautious about International Traffic in Arms Regulations (ITAR) restrictions, further complicating the model of automatically distributing and upgrading software for external users. Finding: The Air Force recognizes the need for maintaining compatibility with existing systems in any new system development, and is committed to supporting its legacy customers. Examples of problems caused by a rigid, older architecture abound, and a few are described below: • New software technologies. The standardized software was originally written in FORTRAN 77 as used by the SPADOC system and has since been somewhat improved to Fortran 95 and C with only SGP4 available in Java. However, modern computer science practices are moving away from monolithic codes and toward architectures and languages that support advanced software technologies such as object-oriented design, modularity, parallel processing, etc. • New hardware technologies. SGP4 and the SP standardized algorithms were written for single-thread, single core computers. Adaptation to modern, multi-thread and multi-core architectures to support parallelism will require explicit investment in research and development and in implementation. • New database technologies. Use of the standardized software requires databases of orbital elements and tracking data. While a database is used on the SPADOC system, flat files were the only technology supported in the astrodynamics support workstation environment and the distributed versions of the standard algorithms, and so modern relational generalized databases cannot be used without modifying the software. • New algorithms. Some of the standardized software has been frozen for more than 20 years. Other parts have slowly evolved during the past 10 years. However, many of the modern improvements in dynamical systems, in computational algorithms, and uncertainty assessment have not yet been included. • New types of data. A principal purpose of space situational awareness is to monitor, and warn of, close approaches to operational satellites as mandated by the 2010 National Space Policy and recently accepted by U.S. Strategic Command on behalf of AFSPC/JSpOC. The accuracy and the immediacy of such warnings would be significantly enhanced if the JSpOC could automatically accept and process data from satellite owners/operators— military, civilian, and commercial. However, such an automated capability does not exist in the JSpOC, largely because of lack of funding to automate this capability, information assurance issues (i.e., computer security), and concern over the potential to compromise internal systems and processes by corrupted data. The population of cataloged objects continues to rise, and with that increase comes a corresponding increase in computational demand. Catalog growth is anticipated from improvements in observational capabilities as well as from higher frequencies of launches and collisions. The forecasted growth in computational demands can be 1 F.R. Hoots, P.W. Schumacher, and R.A. Glover, History of analytical orbit modeling in the U.S. space surveillance system, Journal of Guidance, Control and Dynamics 27(2):176, 2004. 2 This does not imply that the products have not improved: they have because of more accurate and more prolific sensor data as well as more frequent data processing. However, the theory in the algorithms remains as it was 20 years ago—and does not reflect advances in astrodynam - ics and in computation systems. 3 From verbal communications with the software and space operations personnel at the Space Surveillance radars at MIT Lincoln Laboratory.

OCR for page 44
47 SYSTEM ISSUES relieved, in part, with the explicit use of multiple levels of parallelism in the next generation of astrodynamics algorithms. Predicting a doubling every 2 years of the number of transistors on an integrated circuit, Moore’s law has proven remarkably accurate since the digital computer’s inception decades ago, producing concomitant increases in computing speed and storage capacity. AFSPC capabilities have grown in tandem with computational technol - ogy, although not nearly at the same rate as described by Moore’s law. Only recently, for example, has it been practical to compute the full catalog in real time using the more expensive SP methods as opposed to the faster and less accurate GP methods such as SGP4.4 The computer industry is now moving away from improving clock speed alone. Instead, the general trends are moving toward the stacking of processors, cores, and threads. Costs have dropped precipitously for multi-core processors, clusters of multiple processors, and most recently general- purpose graphics processing units (GPGPUs).5,6,7 As modern computer hardware architectures evolve away from serial processing, the astrodynamics algorithms are poised to benefit tremendously across multiple levels of paral - lelism that currently are not exploited. In particular, satellite catalog maintenance is naturally suited to parallelism for uncoupled applications such as orbit determination, state and uncertainty propagation, geometry calculations, maneuver detection, etc. In addition, there are loosely coupled applications such as track association and conjunction analysis that suffer from quadratic growth in the computational complexity as a function of the catalog population size. Such applications could be split into parallel batches and handled routinely by separate compute nodes or threads. Although there are historical precedents of the astrodynamics algorithms utilizing more sophisticated methods in order to exploit more computational power, most of the AFSPC operational algorithms are designed for serial use on a single CPU processor. Hardware infrastructure and other programmatic constraints have limited the use of modern parallel processing for operations. However, a variety of prototype studies from multiple research and operations groups have demonstrated that dramatic gains in performance are feasible across a broad spectrum of catalog tasks. Within the JSpOC, there is also a move toward parallel processing. For example, the astrodynamics support workstation contractor implemented parallel processing of the satellite catalog updates by distributing the process- ing load in the 16-processor symmetric multi-processing server in CAVENet. The satellite catalog auto differential correction program now runs as a batch process every 8 hours and updates the entire satellite catalog of 22,000 objects in a few hours for all objects that have received observations in the past 8 hours. Finding: The increased accuracy requirements that space situational awareness and conjunction assess - ment demand would be facilitated by the inclusion of new types of data. In particular, the consideration of orbital object metadata, new sensor data types, and owner/operator ephemerides in the JSpOC’s analyses offer the promise of higher levels of accuracy and insight. Recommendation: The Air Force should continue with the design and development of the service- oriented architecture-based Joint Space Operations Center Mission System and employ modern, modular, and extensible hardware and software architecture design practices to ensure the follow - ing capabilities: • Insertion of new technologies, capabilities, and algorithm modifications while preserving interoperability with the external community; • Hardware and software scalability including explicit adaptation to parallel computing; 4 S.L. Coffey, H.L. Neal, C.L. Visel, and P. Conolly, Demonstration of a special-perturbations-based catalog in the Naval Space Command System,” AAS Paper 98-113, AAS/AIAA Space Flight Mechanics Meeting, Monterey, Calif., February 9-11, 1998. 5 H. Kasim, V. March, R. Zhang, and S. See, Survey on parallel programming model, pp. 266-275 in Proceedings of the IFIP International Conference on Network and Parallel Computing (NPC ‘08), Springer-Verlag, Berlin, Heidelberg, doi:10.1007/978-3-540-88140-7_24, 2008. 6 J. Diaz, C. Munoz-Caro, and A. Nino, A survey of parallel programming models and tools in the multi and many-core era, IEEE Transac- tions on Parallel and Distributed Systems 23(8):1369-1386, doi:10.1109/TPDS.2011.308, 2012. 7 J.D. Owens, D. Luebke, N. Govindaraju, M. Harris, J. Krüger, A.E. Lefohn, and T. Purcell, A survey of general-purpose computation on graphics hardware, Computer Graphics Forum 26(1):80-113, 2007.

OCR for page 44
48 CONTINUING KEPLER’S QUEST—ASSESSING AIR FORCE SPACE COMMAND’S ASTRODYNAMICS STANDARDS • Rigorous configuration management practices to ensure backward compatibility, change control, and full documentation; and • Accommodation and exploitation of nontraditional data types, including object metadata, new sensor data types, and owner/operator ephemerides and operations information. INTEROPERABILITY Interoperability means that catalog orbital data products produced and published by the JSpOC should be compatible with user software, for users who can achieve the same orbit accuracy as the JSpOC. 8 Currently, two types of catalog orbital data are published by the JSpOC: two-line element (TLE) sets and vector covariance mes - sages (VCMs). Users usually need satellite ephemerides at future times and need an orbit propagator to propagate the orbit state contained in TLEs or VCMs to the desired time, given that the JSpOC does not publish ephemeris data. The widely used operational orbit propagators are SGP4 and SP. SGP4, the satellite workhorse, takes the TLEs as input and runs rapidly with moderate accuracy; SP is used for orbital safety-related predictions requiring high accuracy and runs more slowly but with higher accuracy. Physical and environment models, such as those for Earth’s atmosphere and gravity, implemented in the orbit propagator affect the accuracy of the propagated orbit. This requires the models in the users’ orbit propagator to be compatible with the ones used by the JSpOC in produc- ing the TLEs and VCMs in the original orbit determination process. As mentioned in Chapter 1, if interoperatbility is not maintained, users can be severely affected, such as with the 10-fold degradation in Defense Meteorological Satellite Program (DMSP) satellite prediction accuracy when the gravity models are not compatible. To maintain proper interoperability, AFSPC has to provide external users the same orbit propagating algo - rithms and force models, including gravitational and nongravitational (atmospheric drag, solar radiation pressure, etc.) forces, as implemented in the JSpOC’s operation system. External users have to embed AFSPC algorithms and models in their systems for their applications of the catalog data. The tight coupling of users’ systems to the JSpOC’s operation system and users’ dependence on AFSPC’s orbit propagating algorithms and modeling make it difficult and costly to change or improve the astrodynamics algorithms or to make software/system upgrades. This dependence also introduces other issues and requires extra user efforts: • Timely updating of atmosphere model parameters to all user systems is practically difficult. • Access to the JSpOC system’s astrodynamics algorithms and models is limited because of national security concerns and ITAR restrictions. • Users are forced to acquire expertise in astrodynamics and to maintain a system for orbit propagating and modeling. Finding: Because of the strong interdependence between astrodynamics modeling and the accuracy of propagated products, the current systems run by the Air Force and those run by external entities that use JSpOC products are typically coupled. Thus it is necessary to coordinate any significant changes among all parties. Although “interoperability” typically refers to the consistency of computational results among different sys - tems, the term can also be applied in a wider context. Interoperability also addresses how well external users are able to take advantage of expanded services offered by the JSpOC, what form and formats for data products are most useful to users, and what process and system interfaces are established for the exchange of data and information. 8 Denise Kaya, A9AC, Air Force Space Command, “Astrodynamics Interoperability,” presentation to the Committee for the Assessment of the U.S. Air Force’s Astrodynamic Standards on October 11, 2011.

OCR for page 44
49 SYSTEM ISSUES Data Products and Formats Current interfacing of catalog data requires close coordination and detailed understanding of algorithms and methods by all parties. This is time-consuming and expensive. A simpler form of interface than the orbit state information, which must be propagated, would be helpful. A commonly used interface is orbit ephemeris, which is essentially the data on the position and velocity of an object as a function of time, usually written in a binary file. Users can retrieve the object’s instantaneous position and velocity at any time within the span of the ephemeris from the ephemeris file with simple file-reading software. This method frees the user from the need to process the astrodynamics models to propagate an orbit. Implementation of such an interface between AFSPC and its users would achieve the following: • A complete removal of all interoperability issues associated with orbit propagation . Users would receive the orbit ephemeris directly from the JSpOC and would not need to perform orbit propagation or maintain the attendant astrodynamics algorithms and complex force models. • A clear decoupling of the large body of external users from the JSpOC by producing orbit ephemerides only on JSpOC systems. This would enable AFSPC to freely change astrodynamics algorithms, update force models, or implement identified improvements on JSpOC systems as necessary. There would be no concerns regarding compatibility with the user communities that find it difficult to keep pace with algorithm improvement or system upgrade. • An improvement in orbit accuracy for conjunction analysis, because more users could take advantage of high-precision orbit ephemerides. The high-precision orbit information, which is currently limited to those who can process the special perturbations catalog, could be provided to all users. Pure orbit data of higher accuracy could help to improve estimation of probability of collision and would not reveal details of the algorithms and models that are used in generating the orbit. • A significant reduction in cost for transfer of the improvements to the dependent users . Costs required for users to keep pace with the JSpOC’s algorithms improvements and system changes/upgrades would no longer be incurred because of the elimination of orbit propagating by users. Users would benefit from this new interface, and from significant savings on users’ software development and system maintenance as well. Using ephemeris as an interface is not new; it has been widely used in the interplanetary space community as the main data interface for sharing and exchanging orbit information of spacecraft, planets, natural satellites, asteroids, comets, and other space objects. It is implemented through the SPICE (Spacecraft Planet Instrument Camera-matrix Events) system9 in which the ephemeris of an object is written as an SPK file in one of the standard formats. Since it was introduced, the ephemeris SPK file has been used by thousands in the United States and around the globe for accurately defining the positions and velocities of spacecraft and planetary bodies for every NASA planetary mission (29 to date) and every foreign planetary mission (14 to date). The SPK file is flexible and can hold data for multiple objects. Users can merge multiple SPK files, subset an SPK file, or append new data to an existing SPK file. Source code of the SPICE utility for reading, writing, and manipulating the data files is freely released to users. The ephemeris SPK file, or a similar file system, could serve as an interface for releas - ing JSpOC catalog orbit data to external users, as an input format for JSpOC ingesting orbit data from satellite operators and owners, or as a mechanism for holding catalog orbit data. Finding: Distributing different data products (e.g., ephemerides rather than epoch state vectors or two- line element sets) may be more useful and serve to further de-couple Air Force systems from those of external customers. 9Charles Acton, Jet Propulsion Laboratory, “The SPICE System,” presentation to the Committee for the Assessment of the U.S. Air Force’s Astrodynamic Standards on December 12, 2011.

OCR for page 44
50 CONTINUING KEPLER’S QUEST—ASSESSING AIR FORCE SPACE COMMAND’S ASTRODYNAMICS STANDARDS Ingesting New Data Tracking and transponder data are available to AFSPC from several nontraditional sources such as satellite owners, other government sensors, and so on that could be drawn upon to achieve these benefits: 1. Helping substantially in the significant issues of collision avoidance, close approach warning, and general maintenance of the orderliness of the object catalog, and where necessary, monitoring the use of space resources per agreed-to codes of conduct and international laws; and 2. Taking advantage of satellite-specific data, such as maneuver and attitude information, from satellite owners to improve ephemeris accuracy and to increase the precision of conjunction assessment. As other countries and international commercial unions begin to develop their own space situational aware - ness tracking networks, substantial improvements to the current U.S. space situational awareness network might be obtained by being able to access data from these networks (assuming proper vetting of the data). In addition, owners/operators may expand their activities in terms of supplying event information and predicted events, neces - sitating efficient ways to ingest such data, which may include: a. Raw tracking observations from new sensors; b. Processed trajectory information from owners/operators; and c. New object state data such as physical descriptions, attitude, spectral characteristics, and maneuver histories. Finding: Tracking data, ephemerides, and maneuver planning information supplied by owners/operators are potentially very useful to the JSpOC for conjunction assessment, uncorrelated tract (UCT) correlation, maneuver detection, and other purposes. However, incorporation of disparate data types and validation of received information are currently manually intensive. Recommendation: The Air Force should create an open-architecture, application programming interface to facilitate the bidirectional exchange of a wider array of data, algorithms, and docu - mentation with a growing number of external entities. Data Sharing Prior to the Iridium-33/Cosmos-2251 collision in February 2009 that left thousands of pieces of debris in an already highly populated region of low Earth orbit, there had long been a culture of secrecy in the U.S. Air Force (USAF) regarding detailed and accurate position and trajectory information on space objects. Low-fidelity informa- tion in the form of TLEs was made public for all but a relatively few national assets, but the accuracy with which TLEs can be propagated is insufficient for consumers to use them for the purpose of collision avoidance planning. The reluctance of the USAF to share higher-accuracy information presumably stemmed from two concerns, namely, that such information could be used for anti-satellite targeting by U.S. adversaries, and that knowledge might be derived from such information about the nature of U.S. tracking capabilities. However, the Iridium/Cosmos col - lision event, along with the Fengyun1C anti-satellite weapon demonstration by the Chinese just 2 years before, both of which created substantial amounts of orbital debris in low Earth orbit, have led the Air Force leadership to conclude that limited sharing of conjunction assessment data to enable operators to conduct collision avoidance maneuvers was in the best interest of the U.S. military and the space operations community as a whole. While this increased sharing is a welcome trend, it currently falls short of what could be done to maximize the safety of orbital operations. Only U.S. government programs, for example, have access to high-accuracy eph - emerides derived from JSpOC’s special perturbations processing. Although products derived from SP data, such as conjunction summary messages, are sent to operators when the JSpOC detects a conjunction involving that operator’s assets, these may be insufficient for the operator to make a meaningful determination of collision risk. Of principal concern is the problem of covariance realism, and without a solid understanding of the uncertainties

OCR for page 44
51 SYSTEM ISSUES associated with a conjunction warning, the operator may be left with the choice of either ignoring the warning or potentially being overly conservative in maneuvering more often or more drastically than the situation actually warrants.10 The intention of sharing conjunction summary messages with satellite owners/operators is to allow them to avoid collisions, but the owners/operators need to be able to assess the cost-benefit tradeoff of doing a maneuver. The cost is typically measured in fuel and service disruption. Of course, the benefit is being able to mitigate a collision that has a certain risk value. Finding: The Air Force is moving in the direction of more openness and data sharing, although some users still desire access to more information. Policies Restricting Information Sharing Effective interoperability among users and across systems is dependent on the ability of the community to share information. Visibility into JSpOC’s computational processes and the sharing of algorithms, data, and documentation are critical for users to ensure that their systems are compatible with JSpOC products and able to operate at required performance levels. This desire for open access is necessarily countered by national security concerns regarding the dissemina - tion of sensitive material. The JSpOC was established as a center for military purposes, and as such, much of the developed system was originally classified. Furthermore, elements that are not classified are often designated as For Official Use Only (FOUO), limiting distribution to those involved in government programs. ITAR represents another barrier to information sharing. Established during the Cold War to limit the export of defense-related articles and services, ITAR has been broadly applied to satellite technology and limits international dissemination of related information. One of the difficult aspects of security protections is that once an item is designated as restricted from dis - tribution, regardless of whether the label is “classified,” “FOUO,” or “ITAR Restricted,” it is often very difficult to have that label removed, even if the necessity for the restriction is no longer relevant. This is clearly the case for some aspects of the JSpOC, where the state of the art available in the public domain is as good as or more advanced than what is being used by the JSpOC. One obvious example is the decades-old SGP4 model that is widely used throughout the community yet remains under ITAR control (note that SGP4 was released in 1980 in AFSPC “Project Spacetrack Report #3” as unclassified with unlimited distribution). The committee could find no justification for the ITAR control of a product (SGP4) that has been widely distributed for more than 25 years. Not providing to users the software that is used to generate the TLEs that are distributed worldwide means that the accuracy of the orbit prediction is degraded. While national security remains a concern, it is widely recognized that overly cautious application of ITAR restrictions has a negative effect on U.S. entities’ ability to cooperate and compete on an international scale. In fact, the 2010 National Space Policy specifically supports international cooperation on matters pertaining to space situational awareness, as the following two quotes illustrate. Departments and agencies, in coordination with the Secretary of State, shall … promote the adoption of policies internationally that facilitate full, open, and timely access to government environmental data. . . . Foster the Development of Space Collision Warning Measures. The Secretary of Defense, in consultation with the Director of National Intelligence, the Administrator of NASA, and other departments and agencies, may collaborate with industry and foreign nations to maintain and improve space object databases; pursue common international data 10 For a contrasting view, see Lauri K. Newman, NASA Robotic Systems Protection Program, “NASA Robotic Conjunction Assessment Risk Analysis (CARA) Program Use of AF Astro Standards,” presentation to the Committee for the Assessment of the U.S. Air Force’s Astro- dynamic Standards on February 7, 2012.

OCR for page 44
52 CONTINUING KEPLER’S QUEST—ASSESSING AIR FORCE SPACE COMMAND’S ASTRODYNAMICS STANDARDS standards and data integrity measures; and provide services and disseminate orbital tracking information to com - mercial and international entities, including predictions of space object conjunction. 11 Finally, apart from security reasons, it was brought to the committee’s attention that legal liability concerns also constrain what information the JSpOC is able to publish. In particular, although the Air Force provides sat - ellite operators with conjunction summary messages (CSMs), it stops short of publishing collision probabilities associated with the conjunction. Its reluctance to provide such a direct measure of risk would be understandable if the determination of probability required some level of subjective judgment. However, probability of collision is directly calculable from the data contained in CSMs, and so it seems logical that publication of the CSMs would carry the same liability exposure. Nevertheless, publication of collision probability estimates would be one way of assisting operators with a standardized and valid interpretation of JSpOC products. Finding: Once restricted from distribution, either by classification or by ITAR, data and algorithms are often difficult to disseminate to the wider community, even after the necessity for the restriction may no longer be relevant (e.g., the 20+ year old SGP4 model). The committee found no legitimate justification for continued restriction of such algorithms. These restrictions are inhibiting algorithm development and innovation with no apparent benefit to national security. Recommendation: The Air Force should review its information distribution policies and work with external customers toward the objectives of (1) more freely sharing data products, algorithms, and documentation and (2) ensuring that such information is timely, accurate, useful, and actionable. Items historically restricted because of International Traffic in Arms Regulations, classification, or other national security or liability concerns should be reevaluated. Although the committee recom - mends a system-wide review, it also recommends consideration of the following specific examples: • Examination of whether there is a valid justification for restricting the distribution of Simpli - fied General Perturbations 4. • Distribution of propagated ephemerides, which would provide users with greater insight into pending conjunctions and facilitate the further decoupling of Air Force systems from those of its external customers. • Publication of collision probability, which would benefit some members of the owner/operator conjunction assessment community. AUTOMATION AFSPC standardized astrodynamics algorithms were developed originally to enable a space situational aware - ness capability using military space surveillance systems within North American Aerospace Defense Command at the Cheyenne Mountain Air Force Station just outside Colorado Springs, Colorado. Initially, the customer base consisted mostly of Department of Defense users and the National Aeronautics and Space Administration. However, JSpOC services are now increasingly sought by a wide variety of space exploration parties, including a variety of commercial users and even foreign government agencies. For example, at present, more than 100 countries 12 engaged in space operations regularly request data from the JSpOC, whereas for the first approximately 20 years of space exploration, the governments of the Soviet Union and the United States were the only major players. The ever-increasing space object catalog and the increasing number of space-faring entities, both commercial and government, have led to a requirement for more frequent and more accurate conjunction assessments and launch screenings. This, in turn, has greatly increased the workload at the JSpOC because the cataloging of satel - 11 National Space Policy of the United States of America, June 28, 2010, available at http://www.whitehouse.gov/sites/default/files/ national_space_policy_6-28-10.pdf. 12 Secure World Foundation, SSA Sharing Program, November 10, 2010, available at http://swfound.org/about-us/staff-publications/ publications-by-tiffany-chow.

OCR for page 44
53 SYSTEM ISSUES lite breakup pieces and the recovering of lost satellites from uncorrelated tracks are manually intensive and require the talents of subject-matter experts who are often in short supply. Finding: The Air Force is correctly anticipating a continuation of the increase in its workload. The evolu - tion and expansion of its mission responsibilities and the growth of the orbital population are both likely to continue and to lead to increased demands on AFSPC. Meanwhile, the existing system is manually intensive. The current software architecture, obsolete hardware platforms, and security-driven network isolation (e.g., the so-called Sneaker Net) are all contributing factors. Recommendation: The Air Force should automate routine processes to the extent possible to mini - mize manual intervention, decrease operational workload, and reduce possibilities for error. PERSONNEL Although the committee found that the JSpOC’s responsibilities have increased, both purely from the perspec - tive of space defense of the United States as well as increasing international cooperation (particularly as mandated by the latest National Space Policy13), many of the operations within the JSpOC appear to be insufficiently staffed. That is, many of them are “one active military person deep.”14 In addition, military personnel are routinely moved in and out every few years, making development and retention of internal expertise quite difficult. 15 Even in areas that rely heavily on contractor support, that support lacks redundancy. In fact, although some areas may have several people with similar titles, education, or training, their experience levels are sufficiently different that they cannot be viewed as redundant.16 Further complicating matters is that the in-house training performed to bring new users up to speed is cur - rently ad hoc. Typical new-user training includes several weeks on JSpOC fundamentals, and a month or so on orbital mechanics. Adding several weeks for in-processing time means that an approximately 6-month period out of a typical 3-year tour has been used before a new military JSpOC staffer is even able to begin contributing to JSpOC’s mission and activities. From these considerations it is evident that there is little redundancy within the JSpOC in case of illnesses, retirements, or resignations. This shallowness of personnel coverage could seriously jeopardize a number of ongo - ing life- and mission-critical operations should a program or activity lead retire, resign, or be reassigned. In order for the JSpOC to maintain its status as the premier organization for space surveillance and space situational aware - ness, a commitment on the part of AFSPC is needed to promote excellence across personnel and in its education and training programs. In addition, if some of the more routine processes were automated, those processes (as well as other, subsequent processes and activities that rely on their output) would be less vulnerable to continuing personnel turnover. Other possible solutions could include extending the 3-year service period to 4 years (which could improve the return on training investment) and considering exchanges of analysts between the JSPoC and other institutions performing Earth orbiter research (something akin to a “semester abroad”) for more complete cross-fertilization and exchange of ideas. Finding: Air Force staffing and training shortfalls could threaten the viability and scope of ongoing programs. The JSpOC is understaffed to operate the existing system and has difficulty retaining the nec - 13 National Space Policy of the United States of America, June 28, 2010, available at http://www.whitehouse.gov/sites/default/files/ national_space_policy_6-28-10.pdf; see the section “International Cooperation.” 14 Tom Walker, U.S. Air Force Space Command, “HQ AFSPC/A9 Orientation,” presentation to the Committee for the Assessment of the U.S. Air Force’s Astrodynamic Standards on December 12, 2011. 15 Tom Walker, U.S. Air Force Space Command, “HQ AFSPC/A9 Orientation,” presentation to the Committee for the Assessment of the U.S. Air Force’s Astrodynamic Standards on December 12, 2011. 16 Tom Walker, U.S. Air Force Space Command, “HQ AFSPC/A9 Orientation,” presentation to the Committee for the Assessment of the U.S. Air Force’s Astrodynamic Standards on December 12, 2011.

OCR for page 44
54 CONTINUING KEPLER’S QUEST—ASSESSING AIR FORCE SPACE COMMAND’S ASTRODYNAMICS STANDARDS essary expertise to fulfill its mission. Training materials are insufficient, the training process is long, and frequent military reassignments make long-term retention of expertise difficult. Recommendation: The Air Force should review personnel recruiting, retention, promotion, and training policies and practices so that Department of Defense military, civilian, and contractor staffing levels and expertise are budgeted for and maintained in space situational awareness mission- critical functions including the Joint Space Operations Center.