introduction

Running head: CASE STUDY HUBBLE SPACE TELESCOPE SYSTEMS ENGINEER 1

Running head: CASE STUDY HUBBLE SPACE TELESCOPE SYSTEMS ENGINEER 2

Hubble Space Telescope Systems Engineering

Case Study

By

James J. Mattice SES (Ret.)

Center for Systems Engineering at the Air Force Institute of Technology (AFIT/SY)

2950 Hobson Way, Wright-Patterson AFB OH 45433 -7765

ii

PREFACE In response to Air Force Secretary James G. Roche’s charge to reinvigorate the systems

engineering profession, the Air Force Institute of Technology (AFIT) undertook a broad spectrum of initiatives that included creating new and innovative instructional material. The Institute envisioned case studies on past programs as one of these new tools for teaching the principles of systems engineering.

Four case studies, the first set in a planned series, were developed with the oversight of the Subcommittee on Systems Engineering to the Air University Board of Visitors. The Subcommittee includes the following distinguished individuals:

Chairman

Dr. Alex Levis, AF/ST

Members

Brigadier General Tom Sheridan, AFSPC/DR Dr. Daniel Stewart, AFMC/CD Dr. George Friedman, University of Southern California Dr. Andrew Sage, George Mason University Dr. Elliot Axelband, University of Southern California Dr. Dennis Buede, Innovative Decisions Inc. Dr. Dave Evans, Aerospace Institute

Dr. Levis and the Subcommittee on Systems Engineering crafted the idea of publishing these case studies, reviewed several proposals, selected four systems as the initial cases for study, and continued to provide guidance throughout their development. The Subcommittee’s leading minds in systems engineering have been a guiding force to charter, review, and approve the work of the authors. The four case studies produced in this series are the C-5 Galaxy, the F- 111, the Hubble Space Telescope, and the Theater Battle Management Core System.

Approved for Public Release; Distribution Unlimited

The views expressed in this Case Study are those of the author(s) and do not reflect the official policy or position of the United States Air Force, the Department of Defense, or the

United States Government.

iii

FOREWORD At the direction of the Secretary of the Air Force, Dr. James G. Roche, the Air Force

Institute of Technology (AFIT) established a Center for Systems Engineering (CSE) at its Wright-Patterson AFB, OH, campus in 2002. With academic oversight by a Subcommittee on Systems Engineering, chaired by Air Force Chief Scientist Dr. Alex Levis, the CSE was tasked to develop case studies focusing on the application of systems engineering principles within various aerospace programs. At a May 2003 meeting, the Subcommittee reviewed several proposals and selected the Hubble Telescope (space system), Theater Battle Management Core System (complex software development), F-111 fighter (joint program with significant involvement by the Office of the Secretary of Defense), and C-5 cargo airlifter (very large, complex aircraft). The committee drafted an initial case outline and learning objectives, and suggested the use of the Friedman-Sage Framework to guide overall analysis.

The CSE contracted for management support with Universal Technology Corporation (UTC) in July 2003. Principal investigators for the four cases included Mr. John Griffin for the C-5A, Dr. G. Keith Richey for the F-111, Mr. James Mattice for the Hubble Space Telescope, and Mr. Josh Collens from The MITRE Corporation for the Theater Battle Management Core System effort.

The Department of Defense continues to develop and acquire joint complex systems that deliver needed capabilities demanded by our warfighters. Systems engineering is the technical and technical management process that focuses explicitly on delivering and sustaining robust, high-quality, affordable products. The Air Force leadership, from the Secretary of the Air Force, to our Service Acquisition Executive, through the Commander of Air Force Materiel Command, has collectively stated the need to mature a sound systems engineering process throughout the Air Force.

These cases will support academic instruction on systems engineering within military service academies and at both civilian and military graduate schools. Plans exist for future case studies focusing on other areas. Suggestions have included various munitions programs, Joint service programs, logistics-led programs, science and technology/laboratory efforts, additional aircraft programs such as the B-2 bomber, and successful commercial systems.

As we uncovered historical facts and conducted key interviews with program managers and chief engineers, both within the government and those working for the various prime and subcontractors, we concluded that systems programs face similar challenges today. Applicable systems engineering principles and the effects of communication and the environment continue to challenge our ability to provide a balanced technical solution. We look forward to your comments on this case study and the others that follow.

MARK K. WILSON, SES

Director, Center for Systems Engineering Air Force Institute of Technology http://cse.afit.edu/

iv

ACKNOWLEDGEMENTS The author wishes to recognize the following contributors: Dr. Kathryn D. Sullivan,

President and CEO, Center of Science and Industry, Columbus, OH, a former astronaut and deployment EVA mission specialist, for her personal insights into Hubble on-orbit servicing design adequacy and mission effectiveness; James B. Odom, Senior Vice President, Science Applications International Corporation, Huntsville, AL, Hubble Program Manager, 1981–1986, for his personal insights and research leads; and Jean R. Oliver, Deputy Manager, NASA Chandra X-Ray Observatory, Hubble Chief Engineer, 1974–1988, for his personal insights and critical review of the Hubble Case Study manuscript. The author also wishes to acknowledge the valuable contributions of case study teammates Lt Col John Colombi, AFIT/SYE, Dr. G. Keith Richey (F-111 Case Study author), Mr. John Griffin (C-5A Case Study author), and Dr. Dennis Buede, Stevens Institute of Technology. Finally, of special significance and assistance in dealing with the wealth of HST information available between 1977 and 1987 was the very thorough book [2] The Space Telescope – A Study of NASA, Science, Technology, and Politics, by Robert W. Smith of the Smithsonian Institution, with key contributions by many others, including reflections, retrospective essays and interviews.

James J. Mattice

v

EXECUTIVE SUMMARY The Hubble Space Telescope (HST) is an orbiting astronomical observatory operating in

the spectrum from the near-infrared into the ultraviolet. Launched in 1990 and scheduled to operate through 2010, HST carries and has carried a wide variety of instruments producing imaging, spectrographic, astrometric, and photometric data through both pointed and parallel observing programs. Over 100,000 observations of more than 20,000 targets have been produced for retrieval. A macroscopic, cumulative representation of these observations is shown in the figure below to provide a sense of the enormous volume of astronomical data collected by the HST about our universe, our beginnings, and, consequently, about our future. The telescope is already well known as a marvel of science. This case study hopes to represent the facet of the HST that is a marvel of systems engineering, which, in fact, generated the scientific research and observation capabilities now appreciated worldwide.

The incredible story of the HST program from the early dreams and visions of a space- based telescope in 1946, through extensive, more formal program formulation and developments in the 1970s, tumultuous re-direction in the 1980s (especially due to the impact of the 1986 Challenger disaster), initial launch in 1990, and unplanned major on-orbit repairs in 1993 provides the basis for an exciting case study in all aspects of systems engineering. As we will see, this case represents a program dramatically impacted by a variety of scientific, technical, economic, political, and program management events and factors, many of them unpredictable [2].

Viewed with the clarity that only time and hindsight provide, the HST program certainly represents one of the most successful modern human endeavors on any scale of international scope and complexity. As we will see, it also represents a remarkable systems engineering case study with both contrasts and similarities when compared to large defense systems. Major differences revolved around the nature and needs of a very different HST “customer” or user from most DoD systems. The HST had to respond to requirements from the diverse international

vi

scientific community instead of from DoD’s combatant commands. In addition, at the time, NASA implemented a different research-development-acquisition philosophy and process than the DoD Acquisition Management Framework described in the DoD 5000 series acquisition reforms. As with most other large programs, powerful influences outside the systems engineering process itself became issues that HST systems engineers in effect had to acknowledge as integral to their overall system/program/engineering management responsibility.

We hope that these differences will illustrate why it is very important for Air Force, as well as other Service and DoD systems engineers at any experience level, to study a case that, on the surface, might seem only remotely relevant to DoD systems management. To the contrary, much can be learned, and perhaps even learned better in terms of systems engineering education, because the reference system is not as easily comprehended by DoD experienced students of the systems engineering process.

A synopsis of some of the most significant HST Learning Principles (LPs) to be explored is as follows:

LP 1, Early and full participation by the customer/user throughout the program is essential to success. In the early stages of the HST program the mechanism for involving the customer was not well defined. The user community was initially polarized and not effectively engaged in program definition and advocacy. This eventually changed for the better, albeit driven heavily by external political and related national program initiatives. Ultimately, institutionalization of the user’s process for involvement ensured powerful representation and a fundamental stake and role in both establishing and managing program requirements. Over time, the effectiveness of “The Institute” led to equally effective user involvement in the deployment and on-orbit operations of the system as well.

LP 2, The use of Pre-Program Trade Studies (“Phased Studies or “Phased Project Planning” in NASA parlance at the time) to broadly explore technical concepts and alternatives is essential and provides for a healthy variety of inputs from a variety of contractors and government (NASA) centers. These activities cover a range of feasibility, conceptual, alternative and preliminary design trades, with cost initially a minor (later a major) factor. In the case of HST, several Headquarters and Center organizations funded these studies and sponsored technical workshops for HST concepts. This approach can promote healthy or unhealthy competition, especially when roles and responsibilities within and between the participating management centers have not yet been decided and competing external organizations use these studies to further both technical and political agendas. Center roles and missions can also be at stake depending on political and or budgetary realities. The systems engineering challenge at this stage is to “keep it technical, stupid!”

LP 3, A high degree of systems integration to assemble, test, deploy, and operate the system is essential to success and must be identified as a fundamental program resource need as part of the program baseline. For HST, the early wedding of the program to the Shuttle, prior NASA (and of course, NASA contractor) experience with similarly complex programs, such as Apollo, and the early requirement for manned, on-orbit servicing made it hard not to recognize this was a big systems engineering integration challenge. Nonetheless, collaboration between government

vii

engineers, contractor engineers, as well as customers, must be well defined and exercised early on to overcome inevitable integration challenges and unforeseen events.

LP 4, Life Cycle Support planning and execution must be integral from day one, including concept and design phases. The results will speak for themselves. Programs structured with real life cycle performance as a design driver will be capable of performing in-service better, and will be capable of dealing with unforeseen events (even usage in unanticipated missions). HST probably represents the benchmark for building in system sustainment (reliability, maintainability, provision for technology upgrade, built-in redundancy, etc.), while providing for human execution of functions (planned and unplanned) critical to servicing missions. With four successful service missions complete, including one initially not planned (the primary mirror repair), the benefits of design-for-sustainment, or life cycle support, throughout all phases of the program becomes quite evident. Without this design approach, it is unlikely that the unanticipated, unplanned mirror repair could even have been attempted, let alone been totally successful.

LP 5, For complex programs, the number of players (government and contractor) demands that the program be structured to cope with high risk factors in many management and technical areas simultaneously. The HST program relied heavily on the contractors (especially Lockheed Missiles and Space Company (LMSC) and Perkin-Elmer (P-E)), each of which “owned” very significant and unique program risk areas. In the critical area of optical systems, NASA depended on LMSC as the overall integrator to manage risk in an area where P-E was clearly the technical expert. Accordingly, NASA relied on LMSC and LMSC relied on P-E with insufficient checks, oversight, and independence of the quality assurance function throughout. While most other risk areas were no doubt managed effectively, lapses here led directly to the HST’s going to orbit with the primary mirror defect undetected, in spite of substantial evidence that could have been used to prevent this.

viii

Table of Contents PREFACE ………………………………………………………………………………………………………………………. i

FOREWORD ………………………………………………………………………………………………………………… iii

ACKNOWLEDGEMENTS …………………………………………………………………………………………….. iv

EXECUTIVE SUMMARY ……………………………………………………………………………………………….v

1.0 SYSTEMS ENGINEERING PRINCIPLES …………………………………………………………………1

1.1 General Systems Engineering Process…………………………………………………………………1

1.2 HST Major Learning Principles………………………………………………………………………….6

2.0 SYSTEM DESCRIPTION…………………………………………………………………………………………9

3.0 HST SYSTEMS ENGINEERING LEARNING PRINCIPLES …………………………………….20

3.1 Learning Principle 1 – Early Customer/User Participation …………………………………..20

3.2 Learning Principle 2 – Use of Pre-Program Trade Studies……………………………………21

3.3 Learning Principle 3 – System Integration …………………………………………………………23

3.4 Learning Principle 4 – Life Cycle Support Planning and Execution………………………33

3.5 Learning Principle 5 – Risk Assessment and Management…………………………………..37

4.0 SUMMARY …………………………………………………………………………………………………………..43

5.0 REFERENCES ………………………………………………………………………………………………………47

6.0 LIST OF APPENDICES………………………………………………………………………………………….49

Appendix 1 – Completed Friedman Sage Matrix for HST…………………………………………….50

Appendix 2 – Author Biography ……………………………………………………………………………….52

Appendix 3 – Documentation, HST Cargo Systems Manual …………………………………………54

Appendix 4 – Hubble Space Telescope Level I Requirements For The Operational Phase of The Hubble Space Telescope Program……………..55

ix

List of Figures Figure 1-1 The Systems Engineering Process as Presented by the Defense Acquisition

University……………………………………………………………………………………………………. 2

Figure 2-1 STS-61 Repair Mission……………………………………………………………………………….. 11

Figure 2-2 1990 HST Initial Deployment April 24, 1990 ………………………………………………… 14

Figure 2-3 HST Major System Elements……………………………………………………………………….. 15

Figure 2-4 HST Optical Telescope Assembly ………………………………………………………………… 18

Figure 3-1 OTA Primary Mirror Assembly……………………………………………………………………. 25

Figure 3-2 Location of Scientific Instruments in the Optical Telescope Assembly……………… 26

Figure 3-3 Encircled Energy vs. Arc-second Radius of Image Produced by HST……………….. 29

Figure 3-4 Metering Rod Positioning in the Reflective Null Corrector ……………………………… 30

Figure 3-5 Displacement of Metering Rod – Design vs. Actual ……………………………………….. 31

Figure 3-6 HST Disposal Mission Requirements Background …………………………………………. 36

Figure 3-7 HST Disposal Mission Draft Requirements …………………………………………………… 37

Figure 3-8 1977 HST Program/Communications Interfaces …………………………………………….. 39

Figure 3-9 Hubble Space Telescope Responsibilities, 1990 …………………………………………….. 40

Figure 3-10 Marshall SFC HST Responsibilities, 1990 …………………………………………………….. 42

List of Tables Table 1-1 A Framework of Key Systems Engineering Concepts and Responsibilities…………… 5

Table 1-2 A Framework for Systems Engineering Concept and Responsibility Domains [2] …. 8

Table 2-1 Time Phase for Program……………………………………………………………………………….. 13

Table 3-1 Large Telescope Mirror Size – System Cost Trade (1975)………………………………… 22

Table 3-2 HST Specification ……………………………………………………………………………………….. 23

Table 3-3 HST Specification Weight Status…………………………………………………………………… 27

Table 3-4 HST Summary Weight Statement ………………………………………………………………….. 28

Table A1-1 The Friedman Sage Matrix for the HST……………………………………………………………50

1

1.0 SYSTEMS ENGINEERING PRINCIPLES 1.1 General Systems Engineering Process 1.1.1 Introduction

The Department of Defense continues to develop and acquire joint systems and to deliver needed capabilities to the warfighter. With a constant objective to improve and mature the acquisition process, it continues to pursue new and creative methodologies to purchase these technically complex systems. A sound systems engineering process, focused explicitly on delivering and sustaining robust, high-quality, affordable products that meet the needs of customers and stake holders must continue to evolve and mature. Systems engineering is the technical and technical management process that results in delivered products and systems that exhibit the best balance of cost and performance. The process must operate effectively with desired mission-level capabilities, establish system-level requirements, allocate these down to the lowest level of the design, and ensure validation and verification of performance, meeting cost and schedule constraints. The systems engineering process changes as the program progresses from one phase to the next, as do the tools and procedures. The process also changes over the decades, maturing, expanding, growing, and evolving from the base established during the conduct of past programs. Systems engineering has a long history. Examples can be found demonstrating a systemic application of effective engineering and engineering management, as well as poorly applied, but well defined processes. Throughout the many decades during which systems engineering has emerged as a discipline, many practices, processes, heuristics, and tools have been developed, documented, and applied.

Several core lifecycle stages have surfaced as consistently and continually challenging during any system program development. First, system development must proceed from a well- developed set of requirements. Regardless of overall waterfall or evolutionary acquisition approach, the system requirements must flow down to all subsystems and lower level components. System requirements need to be stable, balanced and must properly reflect all activities in all intended environments.

Next, the system planning and analysis occur with important tradeoffs and a baseline architecture developed. These architectural artifacts can depict any legacy system modifications, introduction of new technologies and overall system-level behavior and performance. Modeling and simulation are generally employed to organize and assess alternatives at this introductory stage. System and subsystem design follows the functional architecture. Either newer object- oriented analysis and design or classic structured analysis using functional decomposition and information flows/ data modeling occurs. Design proceeds logically using key design reviews, tradeoff analysis, and prototyping to reduce any high-risk technology areas.

Important to the efficient decomposition and creation of the functional and physical architectural designs are the management of interfaces and integration of subsystems. This is applied to subsystems within a system, or across large, complex systems of systems. Once a solution is planned, analyzed, designed and constructed, validation and verification take place to ensure satisfaction of requirements. Definition of test criteria, measures of effectiveness (MOEs) and measures of performance (MOPs), established as part of the requirements process well before any component/ subsystem assembly, takes place.

2

There are several excellent representations of the systems engineering process presented in the literature. These depictions present the current state of the art in the maturity and evolution of the systems engineering process. One can find systems engineering process definitions, guides and handbooks from the International Council on Systems Engineering (INCOSE), European Industrial Association (EIA), Institute of Electrical and Electronics Engineers (IEEE), and various Department of Defense (DoD) agencies and organizations. They show the process as it should be applied by today’s experienced practitioner. One of these processes, long used by the Defense Acquisition University (DAU), is depicted by Figure 1-1. It should be noted that this model is not accomplished in a single pass. Alternatively, it is an iterative and nested process that gets repeated at low and lower levels of definition and design.

Figure 1-1. The Systems Engineering Process as Presented by the

Defense Acquisition University

1.1.2 Evolving Systems Engineering Process The DAU model, like all others, has been documented in the last two decades, and has

expanded and developed to reflect a changing environment. Systems are becoming increasingly complex internally and more interconnected externally. The process used to develop the aircraft and systems of the past was a process effective at the time. It served the needs of the practitioners and resulted in many successful systems in our inventory. Notwithstanding, the cost and schedule performance of the past programs are fraught with examples of some well- managed programs and ones with less stellar execution. As the nation entered the 1980s and 1990s, large DoD and commercial acquisitions were overrunning costs and behind schedule. The aerospace industry and its organizations were becoming larger and were more

3

geographically and culturally distributed. The systems engineering process, as applied within the confines of a single system and a single company, is no longer the norm.

Today, many factors overshadow new acquisition, including system-of-systems (SoS) context, network centric warfare and operations, and the rapid growth in information technology. These factors have driven a new form of emergent systems engineering, which focuses on certain aspects of our current process. One of these increased areas of focus resides in the architectural definitions used during system analysis. This process will be differentiated by greater reliance on reusable, architectural views describing the system context and concept of operations, interoperability, information and data flows and network service-oriented characteristics. The DoD has recently made these architectural products, described in the DoD Architectural Framework (DoDAF), mandatory to enforce this new architecture-driven systems engineering process throughout the acquisition lifecycle.

The NASA Systems Engineering Process. The recent NASA systems engineering process is probably best described in the “NASA Systems Engineering Handbook” [25] published in 1995. The announced NASA position regarding this document is that it does not represent the current process or all current best practices but is useful mainly as an educational tool for developing systems engineers. This handbook evolved over time, beginning in 1989 with an extensive effort resulting in an initial draft in September 1992 and subsequent improvements captured in the latest (1995) version. Interestingly, the forward makes a strong statement that the handbook is primarily for those taking engineering courses, with working professionals who require a guidebook to NASA systems engineering representing a secondary audience. The reason for this appears to be that the handbook, although substantive (in excess of 150 pages), is not intended to hold sway over individual field center systems engineering handbooks, NASA Management Instructions, other NASA handbooks, field center systems engineering briefings on systems engineering processes, and the three independent systems engineering courses being taught to NASA audiences.

During the critical systems engineering phase for the HST program (1970s concept studies thru 1990 launch) there appears to have been no NASA systems engineering master process. Rather, field center processes were operative and possibly even in competition, as centers (especially Marshall and Goddard for HST) were in keen competition for lead management roles and responsibilities. We will see the systems engineering and program management impacts of this competition as it played out for HST, with the science mission objectives and instrumentation payloads being the motivation for Goddard vs. the vehicle/payload access to space motivation of Marshall. In the final analysis, the roles of the major contractors in engineering the system with uneven NASA participation over the system life cycle had a telling effect.

1.1.3 Case Studies The systems engineering process to be used in today’s complex system-of-systems

projects is a process matured and founded on the principles of systems developed in the past. The examples of systems engineering used on other programs, both past and present, provide a wealth of lessons to be used in applying and understanding today’s process. It was this thinking that led to the construction of the four case studies released in this series.

The purpose of developing detailed case studies is to support the teaching of systems engineering principles. They will facilitate learning by emphasizing to the student the long-term

4

consequences of the systems engineering and programmatic decisions on program success. The systems engineering case studies will assist in discussion of both successful and unsuccessful methodologies, processes, principles, tools, and decision material to assess the outcome of alternatives at the program/system level. In addition, the importance of using skills from multiple professions and engineering disciplines and collecting, assessing, and integrating varied functional data will be emphasized. When they are taken together, the student is provided real- world, detailed examples of how the process attempts to balance cost, schedule and performance.

The utilization and mis-utilization of systems engineering learning principles will be highlighted, with special emphasis on the conditions that foster and impede good systems engineering practice. Case studies should be used to illustrate both good and bad examples of acquisition management and learning principles, to include whether:

• Every system provides a balanced and optimized product to a customer • Effective Requirements analysis was applied • Consistent and rigorous application of systems engineering Management standards

was applied • Effective Test planning was accomplished • There were effective major Technical program reviews • Continuous Risk assessments and management was implemented • There were reliable Cost estimates and policies • They used disciplined application of Configuration Management • A well defined System boundary was defined • They used disciplined methodologies for complex systems • Problem solving incorporated understanding of the System within bigger environment

(customer’s customer)

The systems engineering process transforms an operational need into a set of system elements. These system elements are allocated and translated by the systems engineering process into detailed requirements. The systems engineering process, from the identification of the need to the development and utilization of the product, must continuously integrate and balance the requirements, cost, and schedule to provide an operationally effective system throughout its life cycle. Case studies should also highlight the various interfaces and communications to achieve this optimization, which include:

• The program manager/systems engineering interface essential between the operational user and developer (acquirer) to translate the needs into the performance requirements for the system and subsystems.

• The government/contractor interface essential for the practice of systems engineering to translate and allocate the performance requirements into detailed requirements.

• The developer (acquirer)/User interface within the project, essential for the systems engineering practice of integration and balance.

The systems engineering process must manage risk, both known and unknown, as well as internal and external. This objective will specifically capture those external factors and the impact of these uncontrollable influences, such as actions of Congress, changes in funding, new instructions/policies, changing stakeholders or user requirements or contractor and government staffing levels.

5

Lastly, the systems engineering process must respond to “Mega-Trends” in the systems engineering discipline itself, as the nature of systems engineering and related practices do vary with time.

1.1.4 Framework for Analysis The case studies will be presented in a format that follows the learning principles

specifically derived for the program, but will utilize the Friedman-Sage framework to organize the assessment of the application of the systems engineering process. The framework and the derived matrix can play an important role in developing case studies in systems engineering and systems management, especially case studies that involve systems acquisition. The framework presents a nine row by three column matrix shown in Table 1-1.

Table 1-1. A Framework of Key Systems Engineering Concepts and Responsibilities

Concept Domain Responsibility Domain 1. Contractor

Responsibility 2. Shared

Responsibility 3. Government Responsibility

A. Requirements Definition and Management

B. Systems Architecting and Conceptual Design

C. System and Subsystem Detailed Design and Implementation

D. Systems and Interface Integration E. Validation and Verification F. Deployment and Post Deployment G. Life Cycle Support H. Risk Assessment and Management I. System and Program Management

Six of the nine concept domain areas in Table 1-1 represent phases in the systems engineering lifecycle:

A. Requirements Definition and Management

B. Systems Architecting and Conceptual Design

C. Detailed System and Subsystem Design and Implementation

D. Systems and Interface Integration

E. Validation and Verification

F. System Deployment and Post Deployment

Three of the nine concept areas represent necessary process and systems management support:

G. Life Cycle Support

H. Risk management

I. System and Program Management

While other concepts could be have been identified, the Framework suggests these nine are the most relevant to systems engineering in that they cover the essential life cycle processes

6

in systems acquisition and the systems management support in the conduct of the process. Most other concept areas that were identified during the development of the matrix appear to be subsets of one of these. The three columns of this two-dimensional framework represent the responsibilities and perspectives of government and contractor, and the shared responsibilities between the government and the contractor.

The important feature of the Friedman-Sage framework is the matrix. The systems engineering case studies published by AFIT employ the Friedman-Sage construct and matrix as the baseline assessment tools to evaluate the conduct of the systems engineering process for the topic program. The Friedman Sage matrix is not a unique systems engineering applications tool per se, but rather a disciplined approach to evaluate the systems engineering process, tools, and procedures as applied to a program.

The Friedman-Sage matrix is based on two major premises as the founding objectives:

• In teaching systems engineering, case studies can be instructive in that they relate aspects of the real world to the student to provide valuable program experience and professional practice to academic theory.

In teaching systems engineering in DoD, there has previously been a little distinction between duties and responsibilities of the government and industry activities. More often than not, the government role in systems engineering is the role as the requirements developer.

1.2 HST Major Learning Principles For this case study, a learning principle is a discussion of the key points relevant to the

appropriate concept domain in Table 1-2. In this sense, a learning principle is really a systems engineering “lesson learned” for the HST. HST major learning principles are:

LP 1, Early and full participation by the customer/user throughout the program is essential to program success. In the early stages of the HST program the mechanism was not well defined and the user community was initially polarized and not effectively engaged in program definition and advocacy. This ultimately changed for the better, even if driven heavily by external political and related national program initiatives. Ultimately, institutionalization of the user’s process for involvement ensured powerful representation and a fundamental stake and role in both program requirements and requirements management. Over time, the effectiveness of “The Institute” led to equally effective user involvement in the operational aspects of system (deployment and operations) as well.

LP 2, The use of Pre-Program Trade Studies (“Phased Studies or “Phased Project Planning” in NASA parlance at the time) to broadly explore technical concepts and alternatives is essential and provides for a healthy variety of inputs from a variety of contractors and government (NASA) centers. These activities cover a range of feasibility, conceptual, alternative and preliminary design trades with cost initially a minor, then later a major, factor as the process proceeds. For HST, several Headquarters and Center organizations funded these studies and sponsored technical workshops for HST concepts. This can promote healthy or unhealthy competition, especially when roles and responsibilities within and between the participating management Centers have not yet been decided and competing external organizations use these studies to further both technical and political agendas. Center roles and missions can also be at stake depending on political and or budgetary realities. The systems engineering challenge at this stage is to “keep it technical, stupid!”

7

LP 3, Provision for a high degree of systems integration to assemble, test, deploy and operate the system is essential to success and must be identified as a fundamental program resource need from early on (part of the program baseline). For HST, the early wedding of the program to the Shuttle, prior NASA (and of course, NASA contractors) experience with similarly complex programs, such as Apollo, and the early requirement for manned, on-orbit servicing made it hard not to recognize this was a big SE integration challenge. Nonetheless, collaboration between government engineers, contractor engineers, as well as customers, must be well defined and exercised early on to overcome inevitable integration challenges and unforeseen events.

LP 4, Life Cycle Support Planning and Execution must be integral from day one (including concept and design phases) and the results will speak for themselves. Programs structured with real life cycle performance as a design driver will be capable of performing in- service better, and will be capable of dealing with unplanned, unforeseen events (even usage in unanticipated missions). HST likely represents the benchmark for building-in system sustainment (reliability, maintainability, provision for technology upgrade, built-in redundancy, etc.), all with provision for operational human execution of functions (planned and unplanned) critical to servicing missions. With four successful service missions complete, including one initially not planned (the primary mirror repair), the benefits of design-for-sustainment, or life cycle support, throughout all phases of the program, becomes quite evident. Had this not been the case, it is not likely that the unanticipated, unplanned mirror repair could have even been attempted, let alone be totally successful.

LP 5, For complex programs, the number of players (government and contractor) demands that the program be structured to cope with high risk factors in many management and technical areas simultaneously. For HST, there was heavy reliance on the contractors (especially Lockheed (LMSC) and Perkin-Elmer (P-E)) and they each “owned” very significant and unique program risk areas. In the critical optical system area, and with LM as the overall integrator, there was too much reliance on LM to manage risk in an area where P-E was clearly the technical expert. Accordingly, NASA relied on LMSC and LMSC relied on P-E with insufficient checks, oversight and independence of the QA function throughout. While most other risk areas were no doubt managed effectively, lapses here led directly to the primary mirror defect going to orbit undetected in spite of substantial evidence that could have been used to prevent this occurrence.

1.2.1 HST Friedman Sage Matrix Table 1-2 shows the Friedman Sage matrix for the HST and seven entrees in the matrix

most representative of the five learning principles.

HST Learning Principle 1, Early Customer/User Involvement, is represented by the first row of the concept domain, Requirements Definition and Management. The case study will follow the systems engineering process used in the definition and documentation of the requirements in the system specification, along with the contractor and government processes to translate functional requirements into design requirements. For HST, while the bulk of the responsibility lay with the customer (the world telescope science community) early in the process, the unique roles of NASA as a program broker and industry co-advocate was also a vital part of the process.

8

HST Learning Principle 2, Use of Pre-Program Trade Studies, is represented by the second row of the concept domain and is considered a strength of the NASA process involving a phased approach which attempts to sort out major conceptual and design technical issues early with out cost as an initial driving force. A system of the multi-dimensional complexity (electrical/optical/mechanical) in all operational phases (ground build/test, launch mated to Shuttle, on-orbit deployment/maintenance) demanded a high degree of systems architecting as a shared responsibility. While not focused upon as a learning principle, the impact of good HST architecting and conceptual design had a profound impact on all aspects of System and Subsystem Detailed Design and Implementation, especially on the part of the contractors and the NASA launch/operations organizations.

HST Learning Principle 3, Systems Integration, captures the enormous area of systems engineering activity spanning from the total system design concept domain through the actual build and test validation/verification domain. It is here that the system engineering process and discipline must prevail to literally make all of the pieces come together at every level successfully. The responsibility here is shared with the contractor more in the “do it" role and the government ensuring adherence to systems engineering discipline and sufficiency of process and resources.

HST Learning Principle 4, Life Cycle Support, covers two broad concept domains for HST – Deployment and Post Deployment, and Life Cycle Support. Design for sustainment and supportability, HST team shared responsibility for these domains had to be design drivers with the deployment phase largely automated and the maintenance phases largely planned and implemented for Astronaut implementation through servicing missions.

HST Learning Principle 5, Risk and Systems Engineering Management, necessarily transcends the concept domains of Risk Assessment/Management and System/Program Management. Ownership and implementation of technical risk management for HST was unusually complex, shared and often indistinguishable from system/program management functions. The very structure and processes for each were intertwined, shared but often blurred with respect to accountability when things did not work as planned.

Table 1-2. A Framework for Systems Engineering Concept and Responsibility Domains [2]

Concept Domain Responsibility Domain 1. SE

Contractor Responsibility

2. Shared Responsibility 3. Government Responsibility

A. Requirements Definition and Management

LP 1 Early customer/user involvement

B. Systems Architecting and Conceptual Design

LP 2 Use of pre-program trade studies

C. System and Subsystem Detailed Design and Implementation

D. Systems and Interface Integration LP 3 Systems integration E. Validation and Verification F. Deployment and Post Deployment LP 4 Life cycle support G. Life Cycle Support LP 4 Life cycle support H. Risk Assessment and Management LP 5 Risk and systems

engineering management

I. System and Program Management LP 5 Risk and systems engineering management

9

2.0 SYSTEM DESCRIPTION Historical Context

For decades astronomers dreamed of placing a telescope in space well above the Earth’s atmosphere, a complex filter that poses inherent limitations to optical investigation and observation of celestial bodies. A 1923 concept of an observatory in space was suggested by the German scientist Hermann Oberth (who first inspired Dr. Wernher von Braun to study space travel). In 1962, and later in 1965 and 1969, studies at the National Academy of Sciences formally recommended the development of a large space telescope as a long-range goal of the emerging U.S. space program. Two Orbiting Astronomical Observatories, designed for observing the stars, were successfully launched by NASA in 1968 and in 1972. These generated impressive scientific results and stimulated both public and institutional support for a bigger and more powerful optical space telescope.

With the approval of the Space Shuttle program and with the Shuttle’s inherent capacity for man-rated flight, large payloads, and on-orbit servicing, stability, and control, the concept of a large telescope in space was seen as practical (albeit at significant expense and with major technical and systems engineering challenges). In 1973 NASA selected a team of scientists to establish the basic telescope and instrumentation design and Congress provided initial funding. In 1977 an expanded group of 60 scientists from 38 institutions began to refine the earlier recommendations, concepts, and preliminary designs.

NASA formally assigned systems responsibility for design, development, and fabrication of the telescope to the Marshall Space Flight Center in Huntsville, Alabama. Marshall subsequently conducted a formal competition and selected two parallel prime contractors in 1977 to build what became known as the HST. P-E in Danbury, Connecticut, was chosen to develop the optical system and guidance sensors, and LMSC of Sunnyvale, California, was selected to produce the protective outer shroud and the support systems for the telescope, as well as to integrate and assemble the final product.

The design and development of scientific instrumentation payloads and the ground control mission were assigned to Goddard Space Flight Center in Greenbelt, Maryland. Goddard scientists were selected to develop one instrument, and three of the others became the responsibility of scientists at major universities. The European Space Agency agreed to furnish the solar arrays and one of the scientific instruments.

The Space Telescope Science Institute (STScI), on the campus of Johns Hopkins University in Baltimore, Maryland, performs planning of scientific experiments for the HST. The STScI, dedicated in 1983, is operated by the Association of Universities for Research in Astronomy (AURA) and directed by Goddard. Institute scientists generate the telescope’s research agenda, select observation proposals from astronomers around the world, coordinate on- going research, and disseminate results. They also archive and distribute results of the investigations. In 1985 the STOCC, located at Goddard, was established as the ground control, health monitoring and safety oversight facility for the telescope. The STOCC converts the observation agenda from the STScI into digital commands and relays them to the telescope. In turn, the STOCC receives observation data and the STScI translates it into a customer-usable format.

10

Development, fabrication, integration, and assembly of the HST was a daunting, almost 10-year process. The precision-ground mirror was completed in 1981. Science instrument packages were delivered for testing in 1983. The full-up optical assembly was delivered for integration into the satellite in 1984, and assembly of the entire spacecraft was completed in 1985.

Launch of the HST, originally scheduled for 1986, was delayed during the Space Shuttle return-to-flight redesign and recertification program that followed the Challenger accident. Systems engineers used the interim period to significant program advantage for extensive testing and evaluation to ensure high system reliability and ready feasibility of planned on-orbit servicing maintenance functions.

The HST was transported from the Lockheed site in California to the Kennedy Space Center, Florida, in 1989. It was prepared for launch and carried aloft aboard the STS-31 mission of the Space Shuttle Discovery on April 24, 1990.

The HST, with anticipated resolution power some 10 times better than any telescopic device on Earth, was on the verge of introducing a whole new dimension of astronomical research and education. However, soon after initial experiments began to show mixed results, a major performance problem was traced to a microscopic flaw in the main mirror that significantly reduced the ability of the telescope to focus properly for demanding (and most valuable) experiments. The focusing defect was found to result from an optical distortion due to an incorrectly shaped/machined/polished mirror. The mirror was too flat near a small area of one edge by about 1/50th of the width of a human hair. This caused an “optical aberration” that prevented focusing of light into a sharp point. Instead, the light collected was spread over a larger area, creating a fuzzy, halo-like, blurred image, especially for faintly lighted or weakly radiating objects.

Nonetheless, relatively bright objects could still be seen to a degree far superior to the capabilities of ground telescopes. A plan was devised to utilize the telescope’s capabilities and instruments less affected by the aberration for such tasks as ultraviolet and spectrographic observations. As a result, the HST provided significant new insights and discovery about the universe. Exciting images of Supernova 1987A, a black hole fueled by a disk of cold gas, and other images proved a mark of project success to many. However, for many others, this was not good enough from an overall scientific, technical, return-on-investment, and political perspective.

Since the mirror could not practicably be returned to earth or physically repaired on orbit, the decision was made to develop and install corrective optics for HST instruments. The idea parallels putting on prescription eyeglasses or contact lenses to correct a person’s vision. This approach proved feasible, even if physically and technically challenging, because the program managers and systems engineers had designed the system specifically for on-orbit servicing to upgrade instruments and change out degradable components. Instruments were designed to be installed in standard dresser-drawer fashion for ease of removal and replacement.

On 2 December 1993 the STS-61 crew launched on Space Shuttle Endeavor for an 11-day mission with a record five spacewalks planned. Watched by millions worldwide on live television, the astronauts endured long hours of challenging spacewalks to install instruments containing the corrective optics and replaced the telescope’s solar arrays, gyroscopes, and other electronic components (Figure 2-1). They installed WF/PC-2 and replaced the High Speed

11

Photometer with the COSTAR instrument. They also installed a new computer co-processor to upgrade the telescope’s computer memory and processing speed, the Solar Array Drive Electronics unit, and the Goddard High Resolution Spectrograph Redundancy Kit. After five weeks of engineering check-out, optical alignment, and instrument calibration, the confirmation of success came as the first images from the space telescope were received on the ground.

Source: NASA photo no. 94-H-16

Figure 2-1. STS-61 Repair Mission

Figure 2-1 shows Astronaut F. Story Musgrave, anchored on the end of the Remote Manipulator System (RMS) arm, as he prepares to be elevated to the top of the towering HST to install protective covers on magnetometers. Astronaut Jeffrey A. Hoffman (bottom of frame) assisted Musgrave with final servicing tasks on the telescope, wrapping up five days of space walks.

Procurement and Development Since the HST would be built largely by industry, and as part of its attempts to control

program costs and foster competition, NASA stimulated its contractor base to develop competing designs and contracting strategies to achieve an optimum acquisition strategy. Various prime, sub, and associate contract approaches were considered, with heavy input from the potential contractor teams. All of this implied a complex program management structure within and among industry players and also within NASA. Earlier competitive approaches were considered by both Marshall and Goddard, even when they were still vying for the lead NASA role during the Phase A process, and seemed both to favor an associate prime contractor relationship for the major elements of the program, even if it would be more complex managerially.

Contract Award After the protracted phased studies, Marshall ultimately selected two prime (associate)

contractors to build the HST. P-E was chosen over Itek and Kodak to develop the optical system and guidance sensors. Interestingly, Kodak was later contracted by P-E to provide a backup main mirror, which is still in storage at Kodak’s facility in Rochester, N.Y. LMSC was selected over Martin Marietta and Boeing to produce the protective outer shroud and the support systems

12

module (basic spacecraft) for the telescope, as well as to assemble and integrate the finished product.

ESA agreed to furnish the spacecraft solar arrays, one of the scientific instruments, and manpower to support the STScI in exchange for 15% of the observing time and access to the data from the other instruments. Goddard scientists were selected to develop one instrument, and scientists at the California Institute of Technology, the University of California at San Diego, and the University of Wisconsin were selected to develop three other instruments.

The Goddard Space Flight Center normally exercises mission control of unmanned satellites in Earth orbit. Because the HST is so unique and complex, two new facilities were established under the direction of Goddard, dedicated exclusively to scientific and engineering operation of the telescope: the STOCC and the STScI.

Impact of External Influences Many consequences of history involving national security, economics, politics, “big

science” project special interests, and NASA’s then-recent successes set the stage for the creation and implementation of the HST program. The election of John F. Kennedy to the White House, and the bold new vision he announced of a man on the moon by 1970 (which became project Apollo), set the stage for an extraordinary initiative by the world astronomy community to successfully advocate, market, and lobby for appropriations for a large space telescope in lieu of more Apollo- or Voyager-like projects.

Overall NASA budgets had risen sharply. Kennedy had inspired big thinking and Nixon’s 1972 approval of the Shuttle as the manned spacecraft for the immediate future all played to the HST’s ultimate advantage and needs (in spite of still-austere 1970s budgets for big space science projects). The astronomers’ success in reconciling their and others’ competitive interests in funding for large ground-based vs. space-based telescopes was also a factor. Their ability to gain significant control of the to-be HST research agenda by working with NASA and with academic and political factions to establish the STScI (which became affectionately known as “The Institute”), provided a unique user/customer relationship with the program. By issuing the “Hornig Report” [3] in 1977, the Space Science Board of the National Academy of Sciences provided the final impetus to overcoming reservations about the proposed Institute approach within and external to NASA.

The political and technical influence of contractors (Grumman, Lockheed, McDonnell Douglas, TRW, their teams and others) who had been investigating concepts and feasibility for a large space telescope also began to be felt, but in ways that were more traditional for programs of this type. The mere fact that these industry players were also significantly involved in a growing military space intelligence and operations programs is noteworthy. There are more than hints that HST’s potential for military utility was explored. It would not be far fetched to assume that these attributes were one factor among several in the eventual success of program advocacy.

Clearly, the HST program was dramatically influenced by a myriad of external factors before, during, and after the formal launch of the program in a collectively unique fashion over time, as Table 2-1 shows.

13

Table 2-1. Time Phase for Program

Year Event 1962 The first official mention of an optical space telescope, just four years after NASA was established,

when a National Academy of Sciences study group recommended the development of a large space telescope as a logical extension of the U.S. space program.

1965 This recommendation repeated by another study group. Shortly afterwards the National Academy of Sciences established a committee, headed by Lyman Spitzer, to define the scientific objectives for a proposed Large Space Telescope with a primary mirror of about 3 meters or 120 inches.

1968 The first such astronomical observatory – the Orbiting Astronomical Observatory-1 – launched successfully and provided important new information about the galaxy with its ultraviolet spectrographic instrument.

1969 The Spitzer group issued its report, but very little attention was paid to it by the astronomy community. At that time, quasars, pulsars, and other exotic cosmic phenomena were being discovered and many astronomers felt that time spent working towards a space telescope would be less productive than their existing time in ground-based observatories.

1972 A National Academy of Sciences study reviewed the needs and priorities in astronomy for the remainder of that decade and again recommended a large orbiting optical telescope as a realistic and desirable goal. At the same time, NASA convened a small group of astronomers to provide scientific guidance for several teams at the Goddard and Marshall Space Flight Centers who were doing feasibility studies for space telescopes.

1972 NASA named the Marshall Center as lead center for a space telescope program. 1973 NASA established a small scientific and engineering steering committee to determine which scientific

objectives would be feasible for a proposed space telescope. The science team was headed by Dr. C. Robert O’Dell, University of Chicago, who viewed the project as a chance to establish not just another spacecraft but a permanent orbiting observatory.

1975 ESA became involved with the project. The O’Dell group continued their work through 1977, when NASA selected a larger group of 60 scientists from 38 institutions to participate in the design and development of the proposed space telescope

1978 Congress appropriated funds for the development of the space telescope. NASA assigned responsibility for design, development, and construction of the space telescope to the Marshall Space Flight Center in Huntsville, AL. Goddard Space Flight Center, Greenbelt, MD, was chosen to lead the development of the scientific instruments and the ground control center.

1981 Construction and assembly of the space telescope was a painstaking process that spanned almost a decade. The precision-ground mirror was completed; casting and cooling of the blank by Corning Glass took nearly a year.

1983 The STScI was dedicated in a new facility near the Astronomy and Physics Departments of Johns Hopkins University and tasked to perform the science planning for the telescope. The Institute is operated under contract to NASA by AURA to ensure academic independence. It operates under the administrative direction of the Goddard Center.

1983 The science instruments were delivered for testing at the Goddard Center. 1984 The optical assembly (primary and secondary mirrors, optical truss and fine guidance system) was

delivered for integration into the satellite. 1985 The STOCC is established at Goddard as the ground control facility for the telescope. The STOCC

also maintains a constant watch over the health and safety of the satellite. 1985 Assembly of the entire spacecraft at the Lockheed Sunnyvale facility was completed. 1986 The HST was originally scheduled for launch in this year. It was delayed during the Space Shuttle

redesign that followed the Challenger accident. Engineers used the interim period to subject the telescope to conduct intensive testing and evaluation, ensuring the greatest possible reliability. An exhaustive series of end-to-end tests involving the STScI, Goddard, the TDRS, and the spacecraft were performed during this time, resulting in overall improvements in system reliability.

1989 The telescope was shipped by Air Force C-5A from LMSC, Sunnyvale, to the Kennedy Space Center in October.

14

Table 2-1. Time Phase for Program (Cont’d)

Year Event 1990 HST was launched on April 24 (see initial deployment picture below) by the Space Shuttle STS-31

crew onboard Discovery and soon began its two decades of astronomical observations and remarkable discoveries. Initial “trial run” images were exciting compared to those from ground-based telescopes.

1990 A major mirror problem was detected. The system was inherently out of focus and uncorrectable to acceptable limits. Root cause – too much material removed in mirror manufacture, making it too flat by 2.2 µm (1/50th the width of a human hair); critical light gathering reduced from 70% to 15%. Error determined to be caused by improper assembly of a “reflective null corrector” test device used to control mirror material processing (removal and polishing).

1990– 1993

NASA undertook a detailed failure analysis and characterization of the flaw, designed effective corrective optics to be inserted into the telescope during the first servicing mission, and provided effective interim modeling-based corrective solutions to enable productive use of HST prior to the mirror repair servicing mission.

1993 Space Shuttle Endeavor (STS-61) carried the first servicing crew of astronauts to orbit. In a highly demanding, 5-day extravehicular activity (EVA), corrective optics and other servicing functions (new solar arrays to correct jitter, new gyros, computer upgrade, etc.) were installed on HST. Essentially full design function of HST was restored, to the delight of most.

Figure 2-2. 1990 HST Initial Deployment April 24, 1990

HST System Design HST is a 2.4-meter reflecting telescope that was deployed in low-Earth orbit (600

kilometers) by the crew of the Space Shuttle Discovery (STS-31) on 25 April 1990 (see Figure 2-3). Since its inception, HST was destined to perform a different type of mission for NASA: to serve as a permanent space-based observatory. To accomplish this goal and protect the spacecraft against instrument and equipment failures, NASA had always planned on regular servicing missions. Therefore, Hubble has special grapple fixtures, 76 handholds, and is stabilized in all three axes.

15

Figure 2-3. HST Major System Elements

HST’s current complement of science instruments includes two cameras, two spectrographs, and fine guidance sensors (primarily used for astrometric observations). Because of HST’s location above the Earth’s atmosphere, these science instruments can produce high- resolution images of astronomical objects. Ground-based telescopes can seldom provide resolution better than 1.0 arc-second, except momentarily under the very best observing conditions. HST’s resolution is about 10 times better, or 0.1 arc-seconds.

When originally planned in 1979, the Large Space Telescope program called for return to Earth, refurbishment, and re-launch every 5 years, with on-orbit servicing every 2.5 years. Hardware lifetime and reliability requirements were based on that 2.5-year interval between servicing missions. In 1985, contamination and structural loading concerns associated with return to Earth aboard the Shuttle eliminated the concept of ground return from the program. NASA decided that on-orbit servicing might be adequate to maintain HST for its 15-year design life. A 3-year cycle of on-orbit servicing was adopted. The first HST servicing mission in December 1993 was an enormous success. Additional servicing missions were accomplished in February 1997, December 1999, and March 2002.

16

Contingency flights could conceivably still be added to the Shuttle manifest to perform specific tasks that cannot wait for the next regularly scheduled servicing mission and/or required tasks that were not completed on a given servicing mission. This is not now likely with the present NASA and Administration vision for the national “Moon, Mars and Beyond” space exploration initiative. However, the Washington Post reported on 5 October 2004 that NASA has awarded a $330 million contract to Lockheed Martin to build a robot spaceship to carry replacement parts to the HST. NASA stated that it must start work on a robotic servicing mission this fall because Hubble’s batteries are expected to give out in 2007. NASA also awarded a preliminary $144 million contract to MD Robotics, which will build an arm that will help the unmanned spaceship dock with the telescope.

The early years after the launch of HST in 1990 were momentous, with the discovery of the spherical aberration flaw in the primary mirror and the search for a practical solution. The STS-61 (Endeavor) mission of December 1993 obviated the effects of spherical aberration and fully restored the functionality of HST.

Because of the complexity of the HST as a system of systems, a brief description of the major components of the spacecraft and its payloads is provided as context for the systems engineering challenges and learning from the case study.

Science Instruments The following subsections present a representative, not all-inclusive, list of the science

instruments aboard the HST.

Wide Field/Planetary Camera 2 (WF/PC2) The original Wide Field/Planetary Camera (WF/PC, pronounced “wiff-pik”) was changed

out and displaced by WF/PC2 during the STS-61 Shuttle mission in December 1993. WF/PC2 was a spare instrument developed in 1985 by the Jet Propulsion Laboratory. It is actually four cameras. The relay mirrors in WF/PC2 are spherically aberrated to correct for the spherically aberrated primary mirror of the observatory (HST’s primary mirror is 2 microns too flat at the edge, so the corrective optics within WF/PC2 are made too high by that same amount).

Corrective Optics Space Telescope Axial Replacement (COSTAR) Although COSTAR is not a science instrument per se, it is a corrective optics package

that replaced the High Speed Photometer during the first servicing mission to HST. COSTAR (built by Ball Aerospace) is designed to optically correct the effects of the primary mirror’s aberration on the three remaining scientific instruments: Faint Object Camera (FOC), Faint Object Spectrograph (FOS), and Goddard High Resolution Spectrograph (HRS).

Faint Object Camera (FOC) The FOC was built by the European Space Agency (ESA). It is the only instrument to

utilize the full spatial resolution power of HST. Two complete detector systems comprise the FOC. Each uses an image intensifier tube to produce an image on a phosphor screen that is 100,000 times brighter than the light received. This phosphor image is then scanned by a sensitive electron-bombarded silicon (EBS) television camera. This system is so sensitive that objects brighter than 21st magnitude must be dimmed by the camera’s filter systems to avoid saturating the detectors. Even with a broadband filter, the brightest object that can be accurately measured is 20th magnitude.

17

Faint Object Spectrograph (FOS) A spectrograph spreads out the light gathered by a telescope so that it can be analyzed to

determine such properties of celestial objects as chemical composition and concentration, temperature, radial velocity, rotational velocity, and magnetic fields. The FOS (built by Martin- Marietta Corporation) examines fainter objects than the HRS (see Section 2.1.5 below), and can study these objects across a much wider spectral range – from the ultraviolet (UV – 1150 angstroms) through the visible red and the near-infrared (IR – 8000 angstroms).

The FOS uses two 512-element Digicon sensors (light intensifiers) to detect light. The “blue” tube is sensitive from 1150 to 5500 angstroms (UV to yellow). The “red” tube is sensitive from 1800 to 8000 angstroms (longer UV through red). Light can enter the FOS through any of 11 different apertures from 0.1 to about 1.0 arc-second in diameter. There are also two occulting devices to block out light from the center of an object while allowing the light from just outside the center to pass through. This allows analysis of the shells of gas around red giant stars in the faint galaxies surrounding a quasar.

The FOS has two modes of operation, low resolution and high resolution. At low resolution it can reach 26th magnitude in one hour with a resolving power of 250. At high resolution the FOS can reach only 22nd magnitude in an hour (before the signal/noise ratio becomes a problem), but the resolving power is increased to 1300.

Goddard High Resolution Spectrograph (HRS) The Goddard HRS also separates incoming light into its spectral components so that the

composition, temperature, motion, and other chemical and physical properties of objects can be analyzed. The HRS contrasts with the FOS in that it concentrates entirely on UV spectroscopy and trades the ability to detect extremely faint objects for the ability to analyze very fine spectral detail. Like the FOS, the HRS uses two 512-channel Digicon electronic light detectors, but the detectors of the HRS are deliberately blind to visible light. One tube is sensitive from 1050 to 1700 angstroms; while the other is sensitive from 1150 to 3200 angstroms.

The HRS also has three resolution modes: low, medium, and high. “Low resolution” for the HRS is 2000 – higher than the best resolution available on the FOS. Examining a feature at 1200 angstroms, the HRS can resolve detail of 0.6 angstroms and can examine objects down to 19th magnitude. At medium resolution of 20,000 that same spectral feature at 1200 angstroms can be seen in detail down to 0.06 angstroms, but the object must be brighter than 16th magnitude to be studied. High resolution for the HRS is 100,000, allowing a spectral line at 1200 angstroms to be resolved down to 0.012 angstroms. However, “high resolution” can be applied only to objects of 14th magnitude or brighter. The HRS can also discriminate between variations in light from objects as rapid as 100 milliseconds apart.

Optical Telescope Assembly (OTA) The heart of the HST is the OTA represented in Figure 2-4. It consists of the 2.4-meter

Ritchey-Chretien Cassegrain telescope, attachments for the scientific instruments, support structures, stray light reducing baffles, and the fine guidance system. P-E, as an associate contractor, was responsible for the design, development, fabrication, assembly, and verification of the OTA, as well as support of HST development, integration, and operations.

18

APERTURE DOOR

INCOMING LIGHT

SECONDARY MIRROR

CENTRAL BAFFLE

PRIMARY MIRROR

FINE GUIDANCE SENSORS (3)

AXIAL SCIENTIFIC INSTUMENTS (4)

FOCAL PLANE (IMAGE FORMED HERE)

RADIAL SCIENTIFIC INSTRUMENT

SECONDARY MIRROR BAFFLE

STRAY-LIGHT BAFFLES

Figure 2-4. HST Optical Telescope Assembly

The OTA provides high-quality images to the focal plane, which sends sub-images to the various instruments via “pick-off” mirrors. Among the many subcomponents the most critical are the primary mirror assembly, the metering truss structure, and the focal plane structure. These are of special interest here because they posed the most significant technical challenges in terms of sheer size, extreme tolerances, and application of advanced materials, designs, and manufacturing processes.

Support System Module (SSM) The SSM provides the support structure for all HST hardware, including physical

attachments, thermal control, pointing control for the telescope, solar array electrical power, communications, and data handling links. LMSC was the associate contractor for SSM design, development, fabrication, assembly, and verification, as well as for integration of overall systems engineering and analysis for the overall HST program. LMSC also supported NASA in planning and conducting HST ground, flight, and orbital operations.

Structurally, the SSM consists of the aperture door attached to a light shield and the forward shell surrounding part of the OTA, a ten-bay equipment section, and the aft shroud/aft bulkhead. The forward shell is the main attachment point for the solar array “wings,” high-gain antennas, magnetic torque generators, remote manipulator for deployment/retrieval, and two forward trunnions for latching the spacecraft in the Shuttle orbiter payload bay. Most of the equipment housed in the equipment section is made in the form of orbital replacement units (ORUs), a modified Spacelab “pallet” designed with hinged access doors or removable panels so as to be easily (relatively speaking) replaced by astronauts wearing cumbersome space suits. ORU pallets can carry needed combinations of scientific instruments, fine guidance sensors, ORUs, tools, and miscellaneous support equipment (tether attachments, working lights, etc.).

Mission Operations Although HST operates around the clock, not all of its time is spent observing. Each

orbit lasts about 95 minutes, with time allocated for housekeeping functions and for observations. “Housekeeping” functions include turning the telescope to acquire a new target or

19

avoid the sun or moon, switching communications antennas and data transmission modes, receiving command loads and downlinking data, calibrating, and similar activities.

When the Space Telescope Science Institute (STScI; see Section 3) completes its master observing plan, the schedule is forwarded to Goddard’s Space Telescope Operations Control Center (STOCC), where the science and housekeeping plans are merged into a detailed operations schedule. Each event is translated into a series of commands to be sent to the onboard computers. Computer loads are uplinked several times a day to keep the telescope operating efficiently.

When possible, two scientific instruments are used simultaneously to observe adjacent target regions of the sky. For example, while a spectrograph is focused on a chosen star or nebula, the WF/PC can image a sky region offset slightly from the main viewing target. During observations the Fine Guidance Sensors (FGS) track their respective guide stars to keep the telescope pointed steadily at the right target. Engineering and scientific data from HST, as well as uplinked operational commands, are transmitted through the Tracking Data Relay Satellite (TDRS) system and its companion ground station at White Sands, New Mexico.

Up to 24 hours of commands can be stored in the onboard computers. Data can be broadcast from HST to the ground stations immediately or stored on tape and downlinked later. The observer on the ground can examine the “raw” images and other data within a few minutes for a quick-look analysis. Within 24 hours, Goddard Space Flight Center formats the data for delivery to the STScI, which is responsible for data processing (calibration, editing, distribution, and maintenance of the data) for the scientific community.

20

3.0 HST SYSTEMS ENGINEERING LEARNING PRINCIPLES There were five primary systems engineering principles which impacted the Hubble

Space Telescope development, production, and deployment. These will be discussed in detail in the following sections. Other systems engineering principles and learnings are shown in the complete Friedman Sage Matrix (Appendix 1). These were also in play to various degrees and at various times throughout the program life cycle spanning from 1962 to 1993 (Table 2-1), the focus of this case study, and even to the present (2005).

3.1 Learning Principle 1 – Early Customer/User Participation

Early and full participation by the customer/user throughout the program is essential to program success.

Requirements Definition and System Specification The main purpose of the HST – to provide astronomers with the capability to conduct

research in their scientific discipline – is in apparently sharp contrast to DoD’s goal of providing warfighters with superior military capabilities. What is similar is that both science and warfighting are largely human endeavors, as is systems engineering. Thus, we should not be surprised to discover more similarities than differences in what can be learned from these two very different types of programs from a systems engineering perspective.

NASA’s decision to establish a unique (for purposes of a major program development) STScI had major implications for virtually all system, subsystem and component processes and decisions. The Institute was intended as, and became, a vital link between NASA and the astronomy community. It was designed to ensure that the astronomer-scientist customer did indeed have a direct say in what the HST would actually be able to do: what observations would be made when and by whom. It would become a direct, if not the controlling, external input to HST operations and NASA decisions regarding initial requirements, design, development, and on-orbit operations and maintenance.

How the Institute came to be is, in itself, a case study in institutional and agency politics. It arose out of the classical dilemma of whom – scientists or bureaucrats – should control the identification of requirements and manage the scientific content of a major science-focused program involving a huge commitment of taxpayer dollars. For HST, as well as for prior NASA legacy programs, this issue was the subject of assessment by numerous agencies, Congress, the executive branch, and scientific interest groups. The result was to form an Institute that would define location, the research agenda, and scientific instrument requirements, and play a key role in HST ground and space operations. A competition among the several groups interested in large telescopes, both space and ground based, was held to select the organization that would manage the institute. Of the five finalists the two dominant ones (although even they had many misgivings and internal conflicts about bidding) were AURA and AUI (Associated Universities Incorporated), both of which had extensive experience in operating national ground observatories and national laboratories/institutes. After an extensive, formal source selection (generally judged as being free of politics although it was an election year), the AURA/Johns Hopkins University team won the contract, with Johns Hopkins the selected site for what would become the HST- linked Institute.

21

The real challenge for the Institute would become how to wrest control over HST scientific operations from NASA. The answer involved reaching a successful compromise between the requirements of its academic clientele with those of its funding sponsor, NASA. This represented a classic clash of academic vs. bureaucratic values affecting major program technical requirements, and thus the systems engineering process, from early on. As a result of its victory, the fledgling AURA team had the difficult challenge of negotiating a contract with NASA to establish and implement the Institute (to ultimately define the scientific/technical baseline mission of the HST program) in an environment of fierce vested interests and, coincidently, critically short funding and time for program development and execution.

3.2 Learning Principle 2 – Use of Pre-Program Trade Studies

The use of pre-program trade studies to broadly explore technical concepts and alternatives is essential and provides for a healthy variety of inputs from a variety of contractors and government (in this case NASA) centers.

Pre-Proposal Competitive Phase As with the other cases in this series, the HST program featured numerous positive, and

in practice, some questionable examples of creative and effective systems engineering applications used throughout its long and complex concept exploration and development phases. For the HST some of these were:

• Phased (A, B, C, D) in-house and contractor project/engineering studies addressing critical feasibility and requirements issues. These included NASA’s then-current “Phased Program” approach:

– Phase A – addressed the question: Can we build such a large space telescope, assuming a national decision to do so (where cost is not yet a driving consideration)?

– Phase B – included conceptual design refinement with cost a factor and requirements for Phases C and D better defined.

– Phases C/D – involved detailed design, development, and construction, marking the transition from concept to implementation.

• NASA and contractor team processes for managing risk, cost, schedule, and configuration.

• Use of independent review and payload specification groups.

• Use (and in some cases, non-use) of simulation, laboratory, and ground testing prior to initial flight and on-orbit repair.

• Definition of relative roles and contributions of prime and subcontractors, NASA in- house (multiple center), and customer program management/systems engineering perspectives.

Systems Architecture and Conceptual Design “Tumult” probably best describes the early years of the design and development of the

HST. The literature points to early and continuing underfunding and understaffing, especially in the systems engineering area. Technical challenges were formidable in spite of some impressive

22

advances made in optical telescopes as a result of highly classified reconnaissance programs and Air Force adaptive optics advances in ground-based space surveillance technology. It was generally felt that the telescope designers could achieve the right optical designs for the operational environment. The Phase B and C/D studies described earlier had narrowed many of the physical design issues, and identified many of the material tolerances, guidance and stability requirements, methods, and risks.

Operational Mission Analysis Once the decision was made to design, develop, build, launch, host, and maintain the

HST in a union with the Shuttle, certain design requirements followed. Early studies had postulated that a 3-meter aperture telescope, if feasible, would meet the demanding astronomy observation challenges. Enormous challenges to the very practicality were recognized and debated. There were even major questions raised earlier as to whether or not a leap to a large telescope, without several incremental steps to build confidence and experience, was the best approach. Cost trade studies in 1975 [4], summarized in Table 3-1, showed that reducing the primary mirror size (the main system design driver) below 2.4 meters yielded diminishing returns. Beyond this point the cost for precision pointing, support equipment, and most other subsystems would remain the same.

Table 3-1. Large Telescope Mirror Size – System Cost Trade (1975)

Mirror Size, Diameter, Meters Est. System Cost, $M 3 334

2.4 273 1.8 259

The 1975 NASA trade studies led to the decision to reduce the mirror size to 2.4 meters (7.9 feet), primarily as a cost containment measure. The reduced size, while still very large, would presumably simplify anticipated complex manufacturing, test, and assembly while still permitting the telescope and its support structure to fit in the Shuttle payload bay and perform required light gathering, optical accuracy, pointing, and stability control functions. However, analysis showed that the reduction from 3 meters would come at the “expense” of telescope light collecting capability (reduced by a third), imaging exposure of objects (longer time required), restricted capability (some distant or weak objects would not be viewable), and resolving power (reduced to 0.1 second of arc). On the positive side, the telescope weight was forecast to be reduced from about 25,000 to 17,000 pounds (not counting the scientific instruments). The final specification for the system is shown in Table 3-2.

23

Table 3-2. HST Specification

The studies had also exercised various concepts of operation for launch, deployment, and servicing (including on-orbit vs. return to earth) with cost tradeoffs a major consideration – perhaps too much so in contrast to the needed depth of systems engineering in the critical early stages. The bottom line is that the final HST system architecture was, in the final analysis, to be determined more by external factors described earlier (the role of the science customer, wedding to the Shuttle, decision to provide for on-orbit servicing, optimism about the ability to build an extraordinary optical design, etc.). These decisions would be traded off initially against overly optimistic cost projections and expectations. It would take the experience of time and program maturation, as well as the unanticipated Challenger-imposed delay, to implement the architecture successfully.

3.3 Learning Principle 3 – System Integration

Provision for a high degree of systems integration to assemble, test, deploy and operate the system is essential to success and must be identified as a fundamental program resource need as part of the program baseline.

24

System/Subsystem Detailed Design and Implementation The decision to reduce the primary mirror from 3 meters to 2.4 had profound effects on

the design of other major components. The SSM had been redesigned to envelop the telescope optics and this affected other components (shield, shroud, and equipment section). This gave rise to new problems in linking the SSM to the OTA in such a fashion that large thermal gradient deformations arising from continuous day-night orbital changes would not be allowed to distort critical optical functions, such as focusing. This problem was generic to multiple components of the system and was finally overcome by the successful design and development of a set of “kinematic” joints that, in effect, dynamically isolated the components from each other.

The OTA provided additional systems engineering challenges. It was to be built by P-E, which had built many large observatory and balloon telescopes and some space telescopes and mirrors (more than 50 from the 1930s to the start of HST fabrication in 1977). It was common knowledge that the OTA –in particular, precision machining of the large primary mirror to phenomenal tolerances – would be the biggest challenge for P-E and the “long pole” for the entire program. The situation was seen as so critical that a backup mirror was funded and built by Eastman Kodak (EK). Intentionally, EK would finish its mirror by more conventional, yet high-precision polishing techniques, and P-E would use a radically new, computer-controlled polishing system.

P-E’s use of aggressive new approaches extended to its use of special mounts to simulate zero gravity during test and thus obtain the most accurate finish and compensate for gravity- generated dimensional changes. The size of the mirror required a support system consisting of 138 rods on the back surface of the mirror, with each rod uniquely countering a different fraction of the gravitational force to be dealt with. The sum and distribution of the rod upward forces were to counter exactly the weight and weight distribution of the mirror, thus creating a precise zero gravity condition for finishing and testing the mirror.

It was the primary mirror manufacturing, especially its precision manufacturing and subsequent test procedure, that led to the major on-orbit performance failure shortly after the 1990 launch. The unique systems engineering implications of this failure are covered in more detail in the Validation and Verification discussion below.

There were other major subsystem and significant component systems engineering issues, including the very precise primary mirror assembly (see Figure 3-1). The mirror is of special interest as it contains the primary mirror/lens itself, made from a blank of Corning ultra low- expansion glass, with thin front and rear face plates fused to an egg crate construction inner core. In addition to the special grinding, polishing, and fitting to an incredibly precise shape, it is vacuum-coated with aluminum and magnesium fluoride to enhance ultraviolet reflectivity.

25

FRONT FACESHEET

INNER EDGEBAND

LIGHTWEIGHT CORE

OUTER EDGEBAND

REAR FACESHEET

Figure 3-1. OTA Primary Mirror Assembly

The fine guidance sensors are the final representative illustration of the HST subsystem engineering story, although many other components could merit discussion. These sensors were critical because they enable the telescope to be properly pointed and controlled. The minutely faint (in many cases) signal of objects that HST must image in deep space requires that the telescope point in precisely the right direction for long periods of time to collect enough image energy to record the object. Exposure periods of up to 24 hours are not uncommon. These sensors were deemed so critical that Marshall commissioned an alternative design at the Jet Propulsion Laboratory (JPL). However, in 1979, Marshall forecast that the JPL study would not lead to a functional sensor by the anticipated 1983 launch date. The program thus became dependent on the P-E sensors.

The sensors also served as a separate scientific instrument by working in twos and threes to lock on multiple targets, maintain reference positioning to guide stars, and measure angular differences between stars. In recognition of this dependence and multi-functionality, a special customer Astronomy Science Team for fine guidance sensors was convened and successfully ensured that engineering changes to the sensors did not exert a negative impact on critical performance.

Systems and Interface Integration System integration challenges for the HST span a broad array of physical, structural,

electrical, optical, electronic, thermal control, power, and operational software/hardware domains (all uniquely different for pre-ascent, ascent, and on-orbit phases of the mission). One representative example is the function and placement of the scientific instruments within the confines of the OTA, shown in Figure 3-2. Each instrument has specific requirements for packaging, power, thermal control, and orientation with respect to the primary mirror. Usually these and other functional requirements flow down to the component and device levels within each instrument. The complete set is, in turn, constrained by the OTA and Shuttle bay geometry and functional interfaces. Most functions are simultaneously monitored, and in some cases

26

separately controlled, on the ground (at the launch control and STScI locations) and in the Shuttle when the system is deployed to orbit. The nature of system integration work here is clearly one of discipline, documentation, and communication, human as well as machine. Extend this to the full HST system for typical tasks (such as manned deployment, manned on- orbit servicing, or unmanned autonomous operations) and the crucial importance of effective, systems engineering- based system integration becomes readily apparent.

Figure 3-2. Location of Scientific Instruments in the Optical Telescope Assembly

Weight Allocation and Management Another major systems integration issue, as with most aeronautical and space systems, is

weight allocation and management. This is especially true for a system that will be placed on orbit. Tables 3-3 and 3-4 below illustrate two levels of HST’s tracking its weight status at two different points in time (thus, comparing the two common components will not necessarily match). Table 3-3 represents the aggregate weight status at the major subsystem level and illustrates top-level tracking and planning for the launch, and in this case, maintenance mission elements. Note the references to extensive weight reference plans, standards, and documentation that are critical to successfully managing weight and maintaining flexibility and reserve for contingencies throughout the development, fabrication, integration, deployment, and maintenance phases of the system life cycle.

27

Table 3-3. HST Specification Weight Status

Table 3-4 shows one additional example of flow-down of weight management one level lower to include tracking of many functional support subsystems and the scientific instruments. The weight dimension illustrates only one dimension of the systems integration work for these and many other components. This is why systems integration is a special branch of modern systems engineering and must be approached with the utmost human and technical discipline. The HST program represents an example where this was ultimately accomplished with great success, a tribute to all of the government, contractor, and customer (designers, developers, science users, astronauts and mission control) personnel involved over decades of activity.

28

Table 3-4. HST Summary Weight Statement

Validation and Verification Perhaps the most stunning example of an HST validation/verification test is the one

pertaining to the undetected primary mirror manufacturing defect. The methodical determination of the root cause, how it happened, why it was not detected prior to the 1990 launch, and systems engineering lessons learned are well documented [17]. The critical defect was recognized after users noted that both of the high-resolution imaging cameras (wide field/planetary and faint object) demonstrated the same spherical aberration. This was caused by the mirror’s having been made ever so slightly in the wrong shape (too flat in a small region relative to the mirror’s center). As tiny as it was (1/50th the diameter of a human hair) the mirror error was ten times greater than the design tolerance. The impact on the mirror’s performance is shown in Figure 3-3. The mirror as fabricated was simply not capable of achieving the required focusing power to operate acceptably for many imaging tasks.

29

Figure 3-3. Encircled Energy vs. Arc-second Radius of Image Produced by HST

How could this happen with all of the attention given to producing and testing this critical component? The answer, to quote the Investigation Board [17], is that: “The error in the HST mirror occurred because the optical test used in this process was not set up properly; thus the mirror was polished to the wrong shape.” The root cause was found to reside in the setup of the optics – the reflective null corrector (RNC) used as a template to shape the mirror. Figure 3-4 illustrates the position of metering rods used to space optical elements in the RNC.

30

Figure 3-4. Metering Rod Positioning in the Reflective Null Corrector

The RNC consists of two mirrors and a lens. The lens proved to be improperly positioned between the mirrors by an amount that exactly generates the observed error. Figure 3- 5 illustrates the undesirable displacement due to the interferometer focusing on the field cap instead of on the metering rod.

31

Figure 3-5. Displacement of Metering Rod – Design vs. Actual

The exact cause of the spacing error is a matter of conjecture, since the records necessary to reproduce what actually happened could not be found – another breakdown in technical discipline. A simulated scenario using what could be gleaned about the laboratory procedures from interviews and other documentation determined that, in all likelihood, optical readings used to determine critical spacing and location arose from erroneous reflection from the field cap over one metering rod rather than from the rod end itself. Further assessment showed that no verification of the RNC dimensions were carried out after assembly of the test setup, even though there were indications of a problem from at least two auxiliary null corrector tests used to align the test apparatus and check the vertex radius of the primary mirror. Both results were discounted as being flawed in their own right, since P-E had placed total reliance on the RNC for both manufacturing quality and finished mirror precision.

P-E and NASA both understood and accepted this approach despite a lack of independent measurements to confirm the reliability of the primary test. The failure was not one of system engineering design, but rather one of manufacturing system design and process/quality control. This event occurred at a time when there was also great concern about cost and schedule, possibly overshadowing the obvious need for independent verification testing, or attention to the apparently anomalous RNC data suggesting that something might have been wrong.

The failure report goes on to identify lessons learned that bear repeating here as they are entirely applicable to any system engineering task, and the cause of many that fail:

• Identify and mitigate risk – Neither contractor nor government knowledge and acceptance of a critical single point test failure possibility should be accepted without rigorous technical analysis. Adherence to simple fault tree analysis would have driven all parties to a different implementation of the selected approach. Direct test

32

comparison of the properties of the P-E mirror with the backup EK mirror, which met all specifications, would have indicated the presence of a problem.

• Maintain good communication within the project – Normally desirable delegation of authority and responsibility and problem resolution at the lowest possible level, in this case permitted P-E to deal with all mirror issues internally, with little outside communication or accountability. Internal concerns and communication among P-E designers, testers, and fabricators were discounted, disconnected, and discouraged.

• Understand accuracy of critical measurements – Key test methods were accepted or rejected on the basis of whether they were believed to be “certified” or not. The RNC was alleged to be certified (although there was no audit trail to this effect) and therefore was accepted as correct, in spite of the possibility of a flawed setup procedure. Other tests indicating a problem were not believed to be certified and were discounted, even if they indicated a problem. Accuracy (capability) and precision (outcome) are not the same things.

• Ensure clear assignment of responsibility – Project management, quality assurance, and engineering must work together, but with clear, separate functions known and respected. In this case, unclear roles, incomplete documentation, over-reliance on internal experts, lack of outside independent verification, and lack of understanding of the possible impact of a single flawed process proved catastrophic.

• Remember the mission during crisis – Cost and schedule problems in many aspects of the program preoccupied program management and caused the lack of focus on a critical issue. At the conclusion of the mirror polishing task management abandoned the review of all data for the final report and reassigned the team as a cost-cutting measure.

• Maintain rigorous documentation – Rigorous documentation, especially for high- precision requirements and operations, is the forcing function for the ability to ascertain whether adequate results are being obtained. Continuity of critical documentation throughout the design, development, fabrication, and test cycle is vital and was not followed for the mirror build.

The second example of HST validation and verification involves total system test. Since HST would actually operate in space and success could not be known with certainty until space performance was observed, the program struggled with ground vs. space approaches, incremental vs. all-up, and the associated cost and risk implications. DoD and NASA had been successful with all-up testing of the large and complex Titan II and Saturn missile systems in the 1960s, achieving the attendant reductions in numbers of test flights and big cost savings.

However, HST was seen as a higher risk program with respect to optical concepts employed and on-orbit and manned operations for deployment and servicing. This was particularly true with regard to the issue of whether or not to conduct a high-fidelity, total system vacuum thermal test in a large chamber. Advocacy and cost estimates for the program during the selling phase did not provide for this type of test. Initially a modular approach was considered. Here, major subsystems or components (SSM, OTA, and individual instruments) would be tested separately (and by different contractors) but not the whole system in the all-up mode in a realistic vacuum thermal environment. LMSC did not propose such a test in its bid but soon came to

33

realize its importance and pressed for it as a contract modification to avoid long-term costs (reasoning that an untested HST would experience earlier and more frequent maintenance needs; thus requiring more Shuttle flights). This argument finally prevailed.

Later, the cost and tempo of the assembly/test program would become a major issue as schedules were in jeopardy. LMSC was directed and funded to accelerate to a 24-hour work day to meet the anticipated launch schedule. While some time was recovered it was insufficient and by 1985 the stress on key staff was enormous. Searching for answers as to why acceleration did not lead to desired recovery, LMSC suggested that it was because the HST was being built on the “protoflight” principle – meaning that the complex instrument being designed, built, and tested was the one that would fly. This was in contrast to much of LMSC’s earlier experience with incremental approaches that involved a design-build-test-fix repetitive cycle. In the final analysis considerable schedule was recovered, but the planned launch schedule still was delayed.

By 1986, the program was moving rapidly and being readied for the crucial vacuum- thermal test (30 days or more of rapid cycling and functional checks). In spite of the Challenger accident NASA decided to proceed at full speed, with the all-up testing running from May 6 to July 1, 1986. It was generally seen as successful, but there were doubts as to the feasibility of making necessary fixes in time to meet schedule had not the Challenger event happened. The main correctable deficiencies involved premature solar array degradation and loss of battery efficiency, as well as other areas. Separate lack of maturation of the ground system and its testing was an additional risk.

An up-and-running aggressive test program also proved to be a motivation for NASA and the contractors to engage in a meaningful post-Challenger systems engineering effort until return-to-flight timing could be better defined. Additional motivations were retention of the skilled workforce to be sure the system was ready to launch and the $7 million cost for delay because of the level of effort underway. The telescope “safing” system that keeps the solar arrays properly pointed for power continuity was found to be unreliable. Scientific instruments, each in its own right a technology challenge, needed considerable work, as did the ground command and control system. There was so much to be done that the possibility of a second vacuum-thermal test arose and was finally rejected. Total cost now approached $2 billion, including planned future on-orbit refurbishments, an order of magnitude more than the original estimates.

3.4 Learning Principle 4 – Life Cycle Support Planning and Execution

Life Cycle Support planning and execution must be integral from day one, including concept and design phases.

Deployment and Post Deployment The payload configuration for the HST was stowed in the Shuttle Orbiter payload bay

using payload latch retention assemblies and an active keel fitting. Complex electrical interfaces, interface power control, and connecting/disconnecting umbilicals were provided and set up for remote operation from the Orbiter flight deck. Other berthing aids and closed-circuit TV were also provided.

34

Prelaunch Operations HST was configured for flight at the launch pad at the completion of prelaunch testing.

The essential electrical bus, heaters, and key shutters were all powered-up as part of this process. The bus was powered continuously by the Orbiter from prelaunch through deployment and monitored by the Orbiter computer system to allow ground crews to detect any automatic “failover” of the essential bus to internal (battery) power.

Mission Operations The complicated set of deployment operations is best described sequentially by most

significant deployment event [19]:

• Direct insertion ascent to operational orbit.

• Payload bay door opening.

• Ku-band antenna deployment.

• Cabin depressurization to 10.2 lb per in2 absolute.

• Post-ascent condition inspection of the HST in the payload bay.

• Activation of HST external main bus power (after a minimum of 3 hours to allow for out-gassing of communications equipment); power application to communications equipment.

• Transmissions begin with Orbiter, TDRS.

• Star trackers tested; ground-based data processing checked out.

• Crew prepare for EVA (should one become necessary).

• Maneuver for HST deployment.

• HST grappled, unlatched, and placed on internal battery.

• Orbiter power removed; umbilical disconnected.

• HST maneuvered for deployment by the remote manipulator.

• Deployment of solar array, followed by blankets that are then electrically connected to the HST to begin battery charging.

• High-gain antennas unlatched and deployed, and aperture door unlatched.

• HST placed in its release attitude with respect to the sun.

• HST pointing control system activated; software placed in drift mode until release.

• HST released just after orbital noon of the release orbit.

• Ground operations control center begins communications via relay satellite.

• Orbiter separates to a distance of 45 nmi.

Clearly, the engineering design (conceptual, preliminary and detailed) of this complex array of mechanical, electrical, electro-optical, and human components, all operating in an earth- to-orbit dynamic environment, would have posed an enormous challenge even if the project had enjoyed ideal circumstances (unlimited resources, time, and talent). Of course, this was not the

35

case. The undeniable fact that “the darn thing worked,” notwithstanding the separate primary mirror failure, is a real validation of the systems engineering excellence that resulted from the industry-government-university project team.

Life Cycle Support Programs structured with real life cycle performance as a design driver will perform

better, and will be capable of dealing with unplanned, unforeseen events (even usage in unanticipated missions). A requirement for on-orbit maintenance and repair was part of the HST architecture, acquisition strategy, and program plan from day one. A baseline list of orbital replacement items had been developed. The architecture described a set of Orbital Replacement Units, tool sets, tool carriage, storage, thermal protection, astronaut access limitations, access boxes, cradles, etc. As one small example (representative of many mundane items included), to support on-orbit servicing some uniformity of repair/change-out attachment items (i.e. 7/16” hex bolts) was part of the design baseline, with some variations of head height, surface finish, etc., to accommodate component access limitations. As an architecture, these functions and components were conceptual and in a preliminary design stage of definition. There were some preliminary specifications, loads, and dynamic interface descriptions (for example, a “Flight Support Equipment, Pallets” document had been written, along with some others). Guidance on how to implement the design requirements per the architecture at that time did not exist and would require a dedicated activity comprising systems engineering, human factors, and detailed, iterative functional design and practice.

An interview with Kathy Sullivan [20], then an astronaut and a key HST deployment mission EVA specialist, indicated that overall astronaut user/contractor/program office interfaces and interactions were good for the support missions. The Challenger-imposed five-year delay provided needed time to look deeper into servicing mission details and to take advantage of other contingencies that might develop. While the primary mirror repair was not one of these, all of the provisions for the others enabled the mirror fix to be accomplished more expeditiously than might have otherwise been the case.

For the repair/replace mission, the guiding document was the Shuttle Flight Operations Manual, Annex for EVA [18]. For payloads such as the HST, the Cargo Systems Manuals [19] applied and contained EVA Annexes for specific cargos. An Annex 11 had to be written for the specific HST repair/replace mission. The specific purpose of the documentation was to inform future mission designers and planners of system/subsystem design and functional requirements (especially the relationships among them) and to provide detailed technical and functional checklists for future mission specialists. Systems engineering inputs and even control of these documents are crucial and must include both physical and functional design criteria that have been thoroughly tested; in this case, in mechanical, electrical/electronic, and credible (from the astronauts’ perspective) human dimensions.

For HST, the most significant correct decision for servicing missions was the agreement that the program would use the physical assets and added time available while the system was still on the ground to rigorously work the on-orbit issues. This may seem obvious, but the telescope “owners” are the science community, which understandably (and normally for good reason) does not want anyone to “mess” with their delicate instruments. A questionable decision was to detach the technical development of servicing (assigned to Goddard) from overall system design and development for launch (assigned to Marshall). The unique and different design

36

approaches of the two organizations were very evident to all. This caused many reworkings of the “game plan for servicing” and eventually resulted in the need to evolve a new team midcourse in the program. This was especially true with respect to getting Goddard to work on servicing (vs. technical issues related to the science instruments) as top priority. Ultimately it was successful, though difficult and strained.

With the current Administration’s decision to cancel Servicing Mission #4, NASA has been forced to consider an earlier-than-planned mission to dispose safely of the HST, likely through a controlled de-orbit process initiated by an “add-on” propulsion de-orbit system launched on an ELV [22]. This could take place as early as 2008. Safety (minimum risk to humans on earth) is the primary design driver. Figures 3-6 and 3-7 below are the top-level draft requirements summary as advertised in August 2004 on the NASA Website (http://hubble.gsfc.nasa.gov) for potential contractors who might be interested in responding to an evolving acquisition strategy and procurement process. Ironically, HST’s fate continues to be closely linked to generally unrelated external events (in this case, the new “Moon, Mars and Beyond” Space Exploration Presidential initiative and safety concerns with continued Shuttle and International Space Station operations).

z NASA HQ Code S has formally tasked the HST Program to implement a mission to safely dispose of HST

– Reliably dispose of HST via add-on propulsion system launched on an ELV – Mission execution readiness date of April 2010 with potential of being moved up to 2008 – Capable of mission execution independent of the operational state of HST

z Rapid development activities are in work: – Requirements Definition

• Flow requirements from Level I to Program Level II and end-item Level III – Engineering responsible for mission design, systems and discipline engineering and key

technologies • Feasibility studies

– Modeling & simulations of mission concepts – Autonomous rendezvous and capture sensor demonstrations

– Project organization in place • Staffing requirements identified • Acquisition strategies are being worked with procurement • Potential partners have been identified (NASA, DARPA, NRL, Industry)

z Data Set to Support HST End of Mission Alternatives Sources Sought is

available at http://hubble.gsfc.nasa.gov

Background HST Disposal Mission (Background & Preliminary Requirements)

Figure 3-6. HST Disposal Mission Requirements Background

37

Level I

1) The method of disposal must ensure that the risk of casualty to humans on the ground meets the 10,000:1 NASA Standard (reference NSS 1740.14)

2) Earth return via the Space Shuttle retrieval is not permissible Level II

1a) A de-orbit stage shall be capable of de-orbiting HST from a 300 nm circular orbit and reliably steer HST into a pre-determined, uninhabited region of the planet in accordance with NASA Orbital Debris Mitigation Guidelines (NSS 1740.14).

1b) A disposal orbit stage shall be capable of raising HST to a 2500 km orbit in accordance with NASA Orbital Debris Mitigation Guidelines (NSS 1740.14).

2) The maximum allowable acceleration during propulsive burns is .1 g 3) The maximum allowable load at any of the three berthing pins is 1000 lbf. 4) All subsystems other than the propulsion subsystem shall be redundant. No single failure in any subsystem

shall require a switch to the redundant side of another subsystem. 5) The de-orbit stage shall be attached to existing hard points on the HST structure. 6) The capability of the de-orbit stage to perform rendezvous, capture/docking and de-orbit of the HST spacecraft

shall be irrespective and independent of the health and configuration of the HST. See DRM Note Below 7) The functional reliability of the propellant and propulsion subsystems shall be at least 0.99 at 1 year (TBR) after

stage attachment.

Draft Requirements

Design Reference Mission: 1) Preliminary analysis results in a worst case unpowered drifting HST having body rates of +/- 0.22 deg/sec on all three axes simultaneously. All powered operational states of HST are also possible

2) HST physical configuration is the current post SM3B configuration, see data set. Figure 3-7. HST Disposal Mission Draft Requirements

3.5 Learning Principle 5 – Risk Assessment and Management

For complex programs, the number of players (government and contractor) demands that the program be structured to cope with high risk factors in many management and technical areas simultaneously. The HST is a classic example of a venture with inherently high technical and program management risks by any measure. Significant risk elements had to be dealt with by employing a variety of different systems engineering and management tools and processes. Many aspects have already been described, some initially in terms other than risk (such as validation, verification, and test). Some more notable risk elements, management, and mitigation measures of the HST program throughout its life cycle phases include:

• Requirements definition – early studies involving the feasibility of autonomous or human-assisted approaches; special consideration of the needs of the astronomy/ scientific customer; trade studies to examine basic sizing (example: mirror size- performance-cost trades).

• Systems architecture – use of “phased” (A/B/C/D) studies involving all of the academic, government, and industry players to build a national technical and political consensus on preferred concepts of operation; decision to tie the HST architecture to the Shuttle.

• System/subsystem design – partitioning of the design, development, and eventual fabrication of the major functional elements of the system (instruments, SSM, OTA, etc.); employment of innovative techniques to overcome unique environmental

38

problems; kinematic joints for dynamic isolation of sensitive components and zero- gravity support system for assembly and test; decision to build a backup primary mirror from a second source with different fabrication and polishing methods; unsuccessful attempt to develop an alternative approach to fine guidance sensors; special teams, such as the Astronomy Science Team, to provide independent outside assessment and validation of scientific and engineering approaches. There are many other examples of both successful and unsuccessful design approaches.

• Systems integration – system-of-systems-level integration issues; unique environmental risk elements (physical, electronic, and optical interactions in assembly, packaging for launch, deployment, operations, and servicing).

• Validation and verification – successful all-up functional test and vacuum-thermal systems test; failed primary mirror test process implementation; use (and in some cases non-use) of independent review and technical audit groups; failure to employ decision tree failure prevention analysis in mirror case; aggressive use of Challenger- imposed down time to maintain technical competence and implement an aggressive test and deficiency correction program.

• Deployment and life cycle support – implementation of on-orbit servicing strategy; effective use of Challenger-imposed down time to master on-orbit astronaut human and mechanical tasks and provisioning; relentless astronaut ground practice and test using actual hardware in development and under test.

• System and program management (see Section 3.4.5.4) – the impacts of sustained lean (sometimes deficient, particularly early on) systems engineering manpower; acquisition strategy (associate contractors, Marshall-Goddard relationships); partitioning of technical roles and responsibilities between industry and NASA program management functions; use of Program Evaluation and Review Technique (PERT) milestone and critical path management; technical vs. cost risk factors and tradeoffs between the two; use of NASA-contractor working groups to resolve design, fabrication, and assembly issues

Communications Communications must be considered the most significant human challenge to all aspects

and phases of the HST program throughout its lifetime, even to the present. For purposes of this case study, we will deal with some 16 years of communications issues (roughly from the issuance of the RFP in 1977 through completion of the first servicing mission in 1993, including the repair/correction of the primary mirror defect). We will consider a few of the most representative communications processes and challenges within and across several program interfaces that had a significant bearing on HST systems engineering, including:

• Between and among affected NASA Headquarters and field program management and support centers (Marshall and Goddard primarily; Johnson and Kennedy secondarily) responsible for requirements consolidation, systems engineering, source selection, contracting, program management, and operations oversight.

• LMSC and P-E, the primary associate contractors.

• Major subcontractors (some 25), who worked on approximately 70 major subcontracts.

39

• ESA, provider of solar arrays, the faint object camera, and science operations personnel.

• Technical requirements definition teams (for astronomy, telescope, data, operations, and scientific instruments areas).

• Ground system (command, data flow, and operations), which dealt with all of the components of a national, on-orbit research facility (STScI at Johns Hopkins, STOCC at Goddard, among others).

Some indication of the nature of the program relationships among many of these players is generically represented in Figure 3-8. An organizational structure of this type, with parallel government and industry associates, plus parallel management, engineering, and scientific prime functions, posed an enormous technical, management, communications, and control challenge. The impacts on the ability of systems engineers and program managers to execute all facets of the HST program were certainly of first order.

E04-0124 – 1

M ARSHALL SPACE FLIGHT

CENTER PROJECT

M AN AGEM ENT

MAINTE N ANCE AND

REFURBIS HMENT

LOCKHEED MISSILES

AND SPACE

CO.

PERKIN ELM ER

EUROPEAN SPACE

AGENC Y

GODD AR D SPACE FLIGH T

CENTER

JOHNSON SPACE

CENTER

KENNED Y SPACE

CENTER

Support Systems Module

Optical Telescope Asse mbly

Solar Array

S cientific Instruments

ST/Orbiter Crew Interface and Operations

ST/Orbiter Launch

V erification

Command and Data Handling

Subsystem

Mission Operations

S cience Institute

ST Systems

Engineering

Fine Guidance

Sensor

Faint O bject

Camera Launch

ST Assembly and

Verification

Science Institute

Participation

Figure 3-8. 1977 HST Program/Communications Interfaces

System and Program Management In retrospect, with Marshall ultimately chosen for the lead NASA role, it was clear that

Marshall saw advantages in terms of cost and lead roles if it awarded contracts to associates that it could control and acted as integration manager for the overall effort. By contrast, Marshall believed that only a large aerospace prime (a Lockheed, Boeing, Grumman, etc.) would have the capability to design, build, and manage both the telescope and support system module. Because of the special optical requirements of the telescope, Marshall knew that a large optical company (Itek and P-E had both indicated interest) would be needed and that each might be expected to

40

align itself with one of the primes. This would lead to a robust, if not limited, competition, with a less favorable impact on total system cost. In the final analysis, Marshall elected to pursue the associate contractor approach, rather than working exclusively through a prime, believing it could more effectively and affordably manage the major elements of the program vs. the full-up assembly as a whole, all with better control, leverage, and management effectiveness.

The 1977 organization for the HST program illustrated above had matured through the 1980s. Figure 3-9 illustrates a 1990 representation. In 1977 the Goddard-Marshall relationship was generally seen as poor and as a continuing struggle over how to divide responsibilities, with the roles and relationships of the centers and headquarters a major issue. This came to a head in 1983 (after the JPL had been considered for an associate role and dropped on the basis of cost) with the signing of an MOA by Goddard. Goddard’s role, while subordinate in the management sense, was nonetheless very sizable, significant, and clear.

NASA HEADQUARTERS

MARSHALL SPACE FLIGHT

CENTER

LOCKHEED MISSILES & SPACE CO.

EUROPEAN SPACE

AGENCY

JOHNSON SPACE

CENTER

SPACE TELESCOPE SCIENCE

INSTITUTE

PERKIN- ELMER CORP.

GODDARD SPACE FLIGHT

CENTER

KENNEDY SPACE

CENTER

HST SYSTEMS ENGINEERING & INTEGRATION

SSM DESIGN, FABRICATION, ASSEMBLY & VERIFICATION

HST ASSEMBLY & VERIFICATION

HST LAUNCH & ORBIT VERIFICATION

HST MISSION OPERATIONS PLANNING

SUBCONTRACTOR MANAGEMENT

SOLAR ARRAY

FAINT OBJECT CAMERA

HST/ORBITER/ CREW INTERFACE & OPERATIONS

HST IN-FLIGHT MAINTENANCE PLANNING

SCIENCE OPERATIONS PLANNING

SUPERVISION OF SCIENCE OPERATIONS

SCIENCE & ENGINEERING DATA ANALYSIS

ASTRONOMICAL FINDINGS

OTA DESIGN, FABRICATION, ASSEMBLY & VERIFICATION

FGS SYSTEM ENGINEERING

SCIENTIFIC INSTRUMENTS (SI)

SI C&DH SUBSYSTEM

HST OPERATIONS CONTROL CENTER & SCIENCE OPERATIONS FACILITY

HST MISSION OPERATIONS

TDRSS

HST/ORBITER LAUNCH VERIFICATION

LAUNCH

INFORMATION PROVIDED BY LOCKHEED MISSILES AND SPACE COMPANY, INC.

Figure 3-9. Hubble Space Telescope Responsibilities, 1990

Total manpower was also a critical factor, especially impacting NASA-Marshall systems engineering talent available to penetrate and oversee the contractors’ technical activities. Total Marshall staffing in the first year (1977) was only 72 and was to grow to only 116 by FY 1981 when program activities were forecast to peak. DoD was seen as an influence here because of NASA-DoD agreements to limit the numbers of project personnel with access and thus minimize unwanted adverse technology transfer. This was reinforced by the separate desire of NASA Headquarters to minimize interference with contractor performance of program tasks and to keep HST a “low-cost” program.

The manpower issue would have a profound impact on how systems engineering would play out over the course of the program. The normal functions of moving from requirements to design specifications, selection and use of mathematical models and tools, engineering of the

41

manufacture, test, and verification of system elements, quality assurance, and technical audit functions, all to support program milestones and decisions, had to be thought through in a severely manpower-limited situation. As if this were not enough, it became increasingly evident that HST posed a major system-of-systems engineering challenge. This was because all of the optical, electronic, and mechanical components of major subsystems, often designed and built by others, were, in fact, critically interconnected. In a very direct fashion, changes or inadequacies of any one part would change the performance, if not the function, of the others. NASA project managers considered their systems engineering management options:

• Give the management function to the prime contractor.

• Give it to a separate support contractor, like an Aerospace Corporation.

• Do it with civil service manpower.

By a process of elimination (civil service was not really a practical option due to insufficient numbers and alleged bad experience with the separate support contractor approach), the project managers was left with the prime contractor, with the exception of the OTA focal plane structure, which was assigned to P-E.

By 1990, while most of the players remained the same, several key differences in management and systems engineering responsibility and relationships became evident:

• LMSC’s roles in systems engineering and integration, mission operations planning, and subcontractor management were more explicitly defined through program maturation.

• Goddard’s relationship with the STScI was more distanced, with the Institute functions in scientific activity planning, oversight of science operations, science and engineering data analysis, and astronomical findings placed more directly under the oversight of Marshall.

In addition, Marshall project management responsibilities became more specifically defined as shown in Figure 3-10. The HST program was “projectized” with specific offices formed for management and oversight of the OTA, SSM, and Maintenance and Refurbishment components of the program. Notably, separate parallel offices are evident for systems engineering, program planning, and control and operations, as well as the Project Chief Engineer (separate from the systems engineering function) and the Project (Chief) Scientist. Not evident from the chart is the conscious decision to keep engineering (and management) presence at the contractors’ sites and parallel engineering at Marshall to a minimum.

To make the organization work, project management created a number of NASA- contractor working groups (chaired by contractor representatives) intended to serve as the forum for resolution of design and manufacturing issues. Chairing these groups compelled the contractor into a visible leadership role, which, in turn, forced a greatly improved understanding of all the critical interfaces and produced close human contact between and among the key players on all sides. To track all of the working groups’ technical activities throughout the program, NASA used a modified version of the PERT that was created in the 1950s for the Navy Polaris program and later adapted successfully for the Apollo program. NASA also implemented a well-disciplined system for technical document generation and configuration control to support technical management of both hardware and software (again no doubt based upon earlier manned space flight experience).

42

MARSHALL SPACE FLIGHT

CENTER

HST PROJECT OFFICE

OPTICAL TELESCOPE ASSEMBLY

PROJECT OFFICE

PROJECT SCIENTIST

SUPPORT SYSTEMS MODULE

PROJECT OFFICE

PROJECT CHIEF ENGINEER

SYSTEMS ENGINEERING

OFFICE

PROGRAM PLANNING AND

CONTROL OFFICE

OPERATIONS OFFICE

MAINTENANCE AND REFURBISHMENT

OFFICE

MSFC RESPONSIBILITIES

• HST DEVELOPMENT LEAD CENTER

• TOTAL PROJECT MANAGEMENT

• OTA DEVELOPMENT

• SSM DEVELOPMENT

• HST INTEGRATION AND VERIFICATION

• ORBITAL VERIFICATION OPERATIONS

• MAINTENANCE AND REFURBISHMENT PLANNING

INFORMATION PROVIDED BY LOCKHEED MISSILES AND SPACE COMPANY, INC.

Figure 3-10. Marshall SFC HST Responsibilities, 1990

As the program progressed, NASA’s technical management strategy (streamlined staffing and technical oversight, minimum in-house engineering, few support contractors at Marshall, a small NASA presence at LMSC and P-E, and frequent reviews and rigorous change control management) would fall far short of the mark. As already discussed in Sections 3.2, 3.3, and 3.4 above, NASA drastically underestimated what it would take to design, build, and test a system of HST’s complexity.

Nonetheless, by 1990, after several organizational shifts and major infusions of funding and engineering talent, the program seemed to be running reasonably smoothly, having survived and recovered from major cost, systems engineering, manpower, management, and organizational challenges, as well as the Challenger tragedy.

43

4.0 SUMMARY HST and its servicing missions have been key to implementation of NASA’s national

science goals for space exploration and discovery of our physical origins. HST has yielded unprecedented information crucial to understanding the structure of our universe, testing physical theories, and revealing new phenomena throughout the universe, especially through the investigation of extreme environments. HST helps scientists understand how both dark and luminous matter determine the geometry and fate of the universe. HST instruments have helped us understand the dynamic and chemical evolution of galaxies and stars and the exchange of matter and energy among stars and the interstellar medium. HST has expanded our knowledge of how stars and planetary systems form together and has provided detailed images that assist us in understanding the nature and history of our solar system and what makes Earth similar to and different from its planetary neighbors. A better sense of the scope and magnitude of HST scientific discovery and achievement can be gained by reviewing Reference 23.

The story of how this remarkable capability came to be is a story of the complicated interactions of a systems engineering process, which we like to believe we understand, with equally demanding political, budgetary, and institutional processes we often fail to understand or comprehend at the time they occur. In the final analysis, these processes are inseparable and integral to attaining program success. The challenge to modern systems engineers is to fully embrace the discipline of the systems engineering process while at the same time learning how to continue to practice it in spite of inevitable external influences and instabilities that often cannot be anticipated.

Stepping back from the remarkably successful scientific and educational outcomes of the program from the perspective of the customer and the taxpayer, we must ask: Was the HST, as a total program, a true systems engineering success and what lessons were learned? We can gain some appreciation for the answers, which represent a complex mix of responses, by further asking the question as a function of each of the Friedman-Sage concept domains.

• Was an effective Requirements Definition and Management process evident? From the perspective of the ultimate user, the answer would have to be, in general, “yes.” There was full participation by this customer/user throughout the program. However, in the early stages the mechanism was not well defined and the user community was initially polarized and not effectively engaged in program definition and advocacy. This changed for the better, albeit driven heavily by external political and related national program initiatives. Ultimately, institutionalizing the user’s process for involvement ensured powerful representation and a fundamental stake and role in both program requirements and requirements management. Over time the effectiveness of “The Institute” led to equally effective user involvement in system deployment and operations.

• Were Systems Architecting and Conceptual Design conducted effectively from a systems engineering perspective? Here the answers are both “yes” and “no,” depending on the time frame and specific related activity under discussion. The use of Phased Studies to explore concepts and alternatives appears to have provided for a healthy variety of inputs from a variety of contractors and NASA centers. Thus, competition was evident, but it is not clear that it was always productive, especially the dimension going on within and between the centers. Center roles and missions

44

were clearly at stake to a greater or lesser degree depending on the year or administration. Many references and documented interviews indicate that the program was starved for both quality and quantity of systems engineering talent during this and some subsequent program phases, especially within NASA, and external to NASA to the extent that contracts lacked funding for systems engineering vs. conceptual content.

• Was the System/Subsystem Detailed Design and Implementation executed effectively? Weighing the enormity of the challenge against the resources available and the outcomes, again final the answer would have to be “yes,” on balance. However, this phase was lengthy, complicated, and controversial. Clearly there were many pros and cons. If success were measured by initially estimated vs. actual cost (almost an order of magnitude cost growth), one would have to raise serious questions. On closer inspection, it appears that initial estimates were simply wrong and lacking in quality systems engineering input, let alone realism. On the other hand, the growth was not atypical of many, if not most, major NASA, defense or even public works (rapid transit, highways, nuclear power, etc.) projects of the era. From a schedule standpoint, substantial delays were routine, and often attributable to management, political, and funding instability, as well as dearth of government systems engineering talent, especially at critical times early in the program. In spite of the turbulence, often caused by external factors, enthusiasm and support for the program by the faithful customer and developer communities endured and ultimately paid off.

• Was System and Interface Integration conducted and managed effectively? All indications are that this was one of the strengths of the program. Was it because this was simply a “must” or was there more to it? Clearly, provision for a high degree of integration to assemble, test, deploy, and operate HST was identified as a fundamental need from early on. Early wedding of the program to the Shuttle, prior NASA (and of course, NASA contractor) experience with similarly complex programs, such as Apollo, and the early requirement for manned, on-orbit servicing made it hard not to recognize that HST was a big systems engineering integration challenge. Here collaboration between NASA engineers and the contractors, as well as the science customers, seemed to peak. Program failures seemed to be less traceable to failures in system integration (functional definition, design, and execution of multiple critical functional interfaces) than to “weak links” that could be worked around, poor risk management, or improper test implementation.

• Were System Validation and Verification planned, conducted and executed effectively? In retrospect, and negating initially the contributions of such external events as the Challenger-imposed delay, we would have to respond with an overall “no.” System and subsystem validation and verification occurred at many levels and literally across hundreds of activities. Many, if not most, tests were no doubt planned and conducted effectively if not efficiently. However, the two critical examples discussed earlier – the total system vacuum-thermal test (ultimately conducted after considerable debate) and the landmark lack of rigor in the optical system (primary mirror) test are of sufficient magnitude and importance to outweigh most others. One occurred before Challenger and the other after. Clearly, the time made available by

45

the Challenger delay proved vital and the decision to invest significant additional resources, including systems engineering talent, was both wise and necessary. This decision stands to NASA’s credit, as NASA could have easily justified further delay in applying new resources while awaiting the outcome of the Challenger investigation and return-to-flight program plan. The prudent use of the time and additional resources also leveraged improved outcomes for other program life cycle phases.

• Were System Deployment and Post-Deployment planned and executed effectively? As these functions were finally executed after dramatically shifted schedules and with the support of significant additional resources, the answer would have to be a resounding “yes.” This is of added significance because HST first-time deployment was also first-time full system validation and verification in the often surprising, demanding, and unforgiving operational environment of space. This impressive result, notwithstanding the deployment-unrelated failure of the primary mirror, is real testimony to the collaborative approach and dedication of literally hundreds of contractor, government, and scientific community participants to make a complex program, system engineering, and management process work the first time.

• Was the Life Cycle Support dimension of the program effectively planned and executed? This dimension was integral from day one (concept and design phases) and the results speak for themselves. HST probably represents the benchmark for building in system sustainment (reliability, maintainability, provision for technology upgrade, built-in redundancy, etc.), all with provision for human execution of functions critical to servicing missions. With four successful service missions complete, including one initially not planned for the primary mirror repair, the benefits of design-for-sustainment, or life cycle support, throughout all phases of the program becomes quite evident. Had this not been the case, it is not likely that the unanticipated, unplanned mirror repair could have even been attempted, let alone been totally successful.

• Were Risk Assessment and Management effectively planned and implemented? Closely linked to most other life cycle phases, especially validation and verification, the results here are mixed. The complexity of the program and the number of players – government, university, and contractor – demanded that the program be structured to cope with high risk in many management and technical areas. Here there was heavy reliance on the contractors (especially LMSC and P-E), each of which “owned” very significant and unique program technical risk areas. In the critical optical system area, and with LMSC as the overall integrator, NASA seemed to place too much reliance on LMSC to manage risk in an area where P-E was clearly the more expert technically. Accordingly, NASA relied on LMSC and LMSC relied on P-E with insufficient checks, oversight, and independence of the quality assurance function throughout. While most other risk areas were no doubt managed effectively, lapses here led directly to the HST’s going to orbit with the primary mirror defect undetected in spite of substantial evidence that could have been used to prevent this occurrence. On the positive side, as with validation and verification, the Challenger delay was used to good advantage to attack and reduce risk in many other areas. An excellent example is the way the HST program addressed the risks to astronauts in further understanding and practicing on-orbit servicing functions using time and

46

assets that were “available” (with creative requisitioning) from system fabrication and test work-in-progress during the delay period.

• Was System and Program Management organized and implemented effectively? This could well be the most arguable facet of the case in terms of criticality to the success/failure track record of the program. Students of program management theory and practice argue passionately that the organizational structure evolved for the HST program was a design for difficult program management, if not for failure. Others indicate it was a structure designed for maximum involvement of all players. Still others say that if the program was ultimately successful, as it was and is, then the program was effectively managed by definition. Clearly the program management structure was complex and diverse, and reflected a realization of many technical, organizational, political, and institutional factors.

Could the program have been organized differently and still have succeeded? Of course – and probably with equally positive results, but it would most likely still not have avoided many, if not all, of the pitfalls. Most programs can be managed with virtually any proven, rational management approach that allows the uninhibited participation of all key contributors, especially systems engineers. How the organizational arrangement is used by leaders and managers is vastly more important than what it represents on paper. Minimum conditions for success must be met, such as establishing open and effective communications within and across government, contractor, and customer lines. Other requisites for success include rigorous systems engineering discipline enabled by the program management structure, interface and configuration control, risk management, and other well-known attributes. HST program management organization and execution either had or evolved many of these characteristics. Where and when these were lacking or not focused upon, problems arose that were more attributable to human action or inaction than to the organizational structure. Organization and management structure is always necessary but never sufficient to get the job done. This is an important learning point given management’s propensity to try to reorganize its way out of problems, rather than deal with root causes (usually human interaction and systems engineering process rigor issues) directly.

47

5.0 REFERENCES 1. O’Keefe, Sean, HQ NASA Press Release, Jan 16, 2004. 2. Smith, Robert W., “The Space Telescope – A Study of NASA, Science, Technology

and Politics,” Smithsonian Institution, The Johns Hopkins University, Cambridge University Press, 1989.

3. “National Academy of Sciences Report Regarding Institutional Arrangements for the Space Telescope,” April 6, 1977.

4. Hinners, Dr. Noel W., NASA Associate Administrator for Space Science, “Space Telescope Program Review,” Statement before the House Subcommittee on Space Science and Applications, Committee on Science and Technology, July 13, 1978.

5. “NASA New Starts in the FY 1987 Budget,” NASA Budget Recommendations to the Carter-Mondale Transition Planning Team, January 31, 1977.

6. Fletcher, James C., NASA Administrator, Memorandum to Bob Froesch, “Problems and Opportunities at NASA,” May 9, 1977.

7. Brzezinski, Zbigniew, Presidential Directive/NSC-42, “Space Science and Exploration Goals,” October 10, 1978.

8. “The History of the Hubble Space Telescope,” NASA Space Shuttle Mission STS-31 Press Kit, April 1990.

9. “The Hubble Project” (http://hubble.nasa.gov). 10. Landis, Rob, “Overview of the Hubble Space Telescope,” Space Telescope Science

11. The Space Telescope Science Institute (http://archive.stsci.edu/hst/index.html).

11. Leckrone, David S., “Hubble Space Telescope,” in Encyclopedia of Space Science and Technology, April 15, 2003.

12. Bahcall, John N. and Spitzer, Lyman, Jr., “The Space Telescope,” Scientific American, V.247, Nr. 1, July 1982.

13. Launius, Roger D., “NASA: A History of the U.S. Civil Space Program,” Krieger Publishing Company, 1994.

14. Hubble Space Telescope, “Jane’s Space Directory of International Space Programmes, 1997–1998.”

15. NASA Quest, “The History of the Hubble Space Telescope, How Hubble Came to Be,” (http://quest.arc.nasa.gov/hst/about/history.html).

16. Naisbitt, John, and Aburdene, Patricia, “Megatrends 2000”Harper Collins 1996. 17. Allen, Lew, and others, “The Hubble Space Telescope Optical Systems Failure

Report,” NASA Library Doc. QB 500.268.H83, November 1990.

18. Hanley, Jeffery M., Cargo Systems Manual: Hubble Space Telescope, All Flights, Vol. I, HST Vehicle, Basic, Rev. A, NASA JSC, Houston, TX, July 1988.

48

19. Sullivan, Dr. Kathleen, President and CEO, COSI, Columbus, Ohio (former Astronaut and HST Deployment Mission EVA Specialist), personal interview, October 17, 2003.

20. Odom, James B., Senior VP, SAIC (former MSFC HST Program Manager, 1981– 1986), periodic discussions and personal insights, 2003–2004.

21. Oliver, Jean R., Deputy Manager, NASA Chandra X-Ray Observatory (former HST Chief Engineer, 1974–1988), personal insights and manuscript review, 2004).

22. “HST: End of Mission Alternatives Dataset” (http://hubble.nasa.gov/end-of- mission.html), February 2004.

23. Summary of HST Scientific Discoveries (http://hubblesite.org), April 2004. 24. “Hubble Space Telescope Level I Requirements for the Operational Phase of the

Hubble Space Telescope Program” (http://hstsci.gsfc.nasa.gov/dowloads/level1.pdf), Office of Space Science, NASDA Headquarters, Washington, DC, February 29, 1996.

25. “NASA Systems Engineering Handbook,” NASA Report SP-610S, June 1995.

49

6.0 LIST OF APPENDICES Appendix 1 – Completed Friedman Sage Matrix for HST

Appendix 2 – Author Biography

Appendix 3 – Documentation, HST Cargo Systems Manual

Appendix 4 – Hubble Space Telescope Level I Requirements For The Operational Phase of The Hubble Space Telescope Program

50

Appendix 1 Completed Friedman Sage Matrix for HST

Table A1-1. The Friedman Sage Matrix for the HST Concept Domain Responsibility Domain

1. SE Contractor Responsibility

2. Shared Responsibility 3. Government Responsibility

A. Requirements Definition and Management

Contractors involved the scientific user community in system requirement studies for sizing the telescope, defining the instrument suite, and determining concept of operation.

Contractors and NASA centers worked collaboratively, if not competitively, on requirements definition and analysis.

Government was responsible for finding the right mechanisms to bring science users into the requirements process.

B. Systems Architecting and Conceptual Design

Multiple competing contractors were funded over several years for phased concept and architecture development approaches to the mission.

Concepts and architectures were iterated and reviewed jointly; scientific community customers participated; early example of “system-of- systems” approach.

Multiple NASA centers participated with in-house studies and concept exploration program management. Phased approach was mandated by NASA.

C. System and Subsystem Detailed Design and Implementation

Contractor (LMSC) responsible for overall system design, telescope assembly, support system module and subsystem/ instrument functional interface definition; P-E for optical system and guidance sensors; STScI for most instruments.

Considerable data exchange and sharing; convening of review and oversight groups; and joint program reviews.

ESA responsible for solar arrays; Goddard for some instruments.

D. Systems and Interface Integration

LMSC responsible overall; P-E responsible for optical system with LMSC oversight.

Jointly monitored but largely contractor dominated in execution. Extensive joint integration planning, documentation and configuration management by all participants, including users.

Marshall Center responsible overall for NASA. Goddard led for instrument package integration oversight.

E. Validation and Verification

Total system vacuum thermal test (LMSC) and rigorous optical system V&V (P-E) a contract requirement; (primary mirror test failure led to system failure).

Contractor team and government team shared responsibility for V&V result review, approval and/or rework.

NASA responsible for final review and approval. Direction for V&V acceleration only partially successful; Challenger delay used to advantage.

F. Deployment and Post Deployment (post launch)

Deployment supported by contractor team (system/subsystem functionality, operations support, problem analysis, etc.).

Joint oversight of all operations, especially early on and through the primary mirror failure root cause analysis.

Goddard responsible for mission control; two operations support facilities established (STOCC and STScI).

51

Table A1-1. The Friedman Sage Matrix for the HST Concept Domain Responsibility Domain

G. Life Cycle Support

Program designed for life cycle support (on-orbit servicing); ORU equipment integral to all contractors SE and PM activities. Accelerated disposal mission requirements and program development initiated in February 2004.

ORU functional design and performance jointly defined. Program office, contractor, and user communications and interfaces were good; payoff evident in coping with unplanned need to correct primary optics on orbit (mirror failure).

Experienced astronauts represented the mission astronauts to validate service mission details. Flight operations manuals and EVA annexes well prepared in advance.

H. Risk Assessment and Management

Contractor integral to all phases of program risk assessment and mitigation; evident from requirements through development and test; primary risk management OPR.

Generally, joint involvement in risk management, assessment and mitigation activities; usually worked well; major benefits from Challenger delay; suffered early on for lack of adequate SE manpower because of cost concerns.

NASA clearly in an oversight role; heavy dependence on contractor risk management and judgment; used special review groups to work problems and provide independent inputs.

I. System and Program Management

LMSC, P-E associate contractors with LMSC responsible for overall SE and integration; elected as the best approach for optimum NASA control and leverage.

Contractor and NASA elements organized under a project CONOPS (OTA, SSM, Maintenance and Refurbishment components); shared responsibility for management, problem solving and cost-schedule-performance monitoring.

Marshall lead with Goddard essentially an associate for the mission operations and scientific payload management; separate parallel center offices for SE, program planning and program control functions.

52

Appendix 2 Author Biography

MR. JAMES J. MATTICE Jim Mattice is Director of Management / Organizational Development at the Universal

Technology Corporation, Dayton, Ohio. He provides corporate leadership in the areas of strategic planning and new business development. He also supports on-going government and commercial activities in the areas of research, development, technology advocacy, technology transition, executive development and training. In previous positions Jim served as:

• Air Force Executive-in-Residence at the Federal Executive Institute, Charlottesville, Virginia

• Deputy Assistant Secretary of the Air Force for Research and Engineering, Office of the Secretary of the Air Force, the Pentagon

• Executive Director in the office of the Commander, Aeronautical Systems Center (ASC)

• Director, Development Planning, ASC

• Director, AF Manufacturing Technology Program

• Other senior management positions in Air Force Laboratories and multilateral international defense fora (NATO TTCP, AGARD/RTO, etc.).

Current/recent activities include:

• Strategic Planning support to the Air Force Manufacturing Technology Program and the DOD Joint Defense Manufacturing Technology Panel (JDMTP)

• Member, National Academy of Engineering Board on Manufacturing and Engineering Design (BMED)

• Chairman, NASA Next Generation Launch Technology (NGLT) Executive Program Review Team (ExPRT)

• Member, NASA Kennedy Space Center University-Affiliated Space Technology Development Center (USTDC) Senior Advisory Board

• Author, Hubble Space Telescope Systems Engineering Case Study for the Air Force Institute of Technology (AFIT) Systems Engineering Institute, May 2004

• Member, National Academy of Engineering Committee for Owner-Enabled Handgun Technology Readiness Assessment

• Leader, AFRL BRAC 2005 Strategic Planning Red Team

• Member, National Research Council Committee on Integration of Commercial and Military Manufacturing

• Member, US Army Future Combat Systems Critical Manufacturing Technologies Independent Assessment Panel

• Member, DOD Technology Area and Assessment Review Panel for the Materials and Processes

53

• Member, DOD Technology Area and Assessment Review Panel for Manufacturing Technology

• Study Director, AF Manufacturing Technology 2015 Strategic Planning Study

• Facilitator, AF Research Laboratory Nanotechnology Strategic Planning Team

• Lead Facilitator, NATO/RTO Counter-Terrorism Workshop

• Member, Defense Science Board 2005 Task Force on the DoD Manufacturing Technology Program

54

Appendix 3 Documentation, HST Cargo Systems Manual

1. HST Systems Description Handbook. ST/SE-02, LMSC/D974197B, May 1985. 2. GSE/STE Requirements Spec. LMSC 4175751B, June 1984. 3. HST Data Management Subsystem Functional Description. LMSC D712867E,

February 1985.

4. HST Data Management Unit Detailed Specification. LMSC 4171881F, April 1983. 5. SSM HW/SW Interface Document. LMSC 4171989G, July 1984. 6. HST System Electrical Schematics, ST/SE-33, all Vols. LMSC D978562C,

December 1985, March 1987.

7. HST Command List DM-01. SDM 1001. 8. HST Telemetry List DM-02. SDM 1002. 9. HST Flight Software Design Desc. DM-04, Vol. III, Part I. LMSC 4173944L,

January 1986.

10. HST to Space Support Equipment ICD ST/CM-08. ST-ICD-10C, January 1985. 11. HST Umbilical Disconnect Mechanism User’s Guide. LMSC/Sunnyvale,

November 1986.

12. HST Umbilical Retraction Mechanism User’s Guide – Deploy Mission. LMSC/Sunnyvale, November 1986.

13. HST Umbilical Retraction Mechanism User’s Guide – M&R Mission. LMSC/Sunnyvale, November 1986.

14. Orbiter/HST Unique ICD. JSC-ICD-A-140009. 15. Solar Array System Description Handbook. GL-SA-B002 Rev. G. June 1986. 16. Solar Array Deployment Control Electronics Description Handbook. TM-SA-K001

Rev. F, September 1983.

17. Solar Array Secondary Deployment Mechanism Description Handbook. GS-SA-B001 Rev. E. February 1985.

18. Solar Array Primary Deployment Mechanism/Solar Array Drive Adapter Description Handbook. TN-SA-C008 Rev F, March 1982.

19. SSM to OTA ST/CM-08. ST-ICD-01F, January 1985. 20. Solar Array to SSM ICD ST/CM-08. ST-ICD-05B, June 1984. 21. SSM Systems Procedures (SE-23)

Vol. I Instrumentation and Comm. LMSC D889541A, October 1984. Vol. II Structures/Mechanisms and TCS. LMSC D889542A, November 1984. Vol. III Electrical Power Subsystem. LMSCD889543A, January 1985. Vol. IV Data Management Subsystem. LMSC D889544A, September 1983. Vol. V Pointing Control Subsystem. LMSC D889545A, December 1984.

55

Appendix 4

HUBBLE SPACE TELESCOPE

LEVEL I REQUIREMENTS FOR THE OPERATIONAL PHASE

OF THE HUBBLE SPACE TELESCOPE PROGRAM (Extracted in part from http://hstsci.gsfc.nasa.gov/dowloads/level1.pdf)

STR-78

BASELINE ISSUE February 29, 1996

Office of Space Science Astrophysics Division

National Aeronautics and Space Administration

NASA Headquarters Washington, DC

February 29, 1996

HUBBLE SPACE TELESCOPE

LEVEL I REQUIREMENTS

FOR THE OPERATIONAL PHASE OF THE HUBBLE SPACE TELESCOPE PROGRAM

CONCURRENCE APPROVAL National Aeronautics and Space Administration NASA Headquarters Washington, DC February 29, 1996

This Level 1 requirements document for the Hubble Space Telescope is a merging of requirements as defined in the approved 1983-85 and the 1989 Level 1 Requirements documents, as amended by approved waivers and Critical Decision Items (CDI’s). The intent of this formal release is to present the complete Level 1 requirements in a single integrated document. As such, it supersedes and replaces all previous Level 1 requirements

56

CONTENTS 1. SCOPE 1.1 Control 2. OVERALL PROGRAM REQUIREMENTS 2.1 Operational Life 2.2 Servicing Mission Authorization 2.3 Scientific Capabilities 2.4 Space Transportation 2.5 Communications 2.6 Mission Termination 3. OBSERVATORY PERFORMANCE 3.1 Image Quality 3.1.1 Image Stability 3.1.2 Target Positioning 3.1.3 Guide Star Acquisition and Tracking 3.1.4 Solar System Object Tracking 3.1.5 Stray Light Performance 3.2 Science Observational Capabilities 3.2.1 Core Capabilities 3.2.2 Additional Observational Capabilities 3.3 Spacecraft Subsystems Performance 3.3.1 Power 3.3.2 On-board Data Storage 3.3.3 Data Quality 3.3.4 Time/Frequency 3.3.5 Data Management 4. GROUND SYSTEM REQUIREMENTS 4.1 General Functional Capabilities 4.2 Observatory Operations 4.2.1 On-Line Operations 4.2.2 Planning and Scheduling 4.2.3 Maintenance Mission Planning 4.2.4 Simulation and Test 4.3 Data Acquisition, 4.3.1 Data Rates 4.3.2 Data Volume 4.3.3 Data Storage 4.3.4 Data Dissemination 4.4 Science Operations 4.4.1 Research Management 4.4.2 Observing Support 4.4.3 Science Data Processing and Products 4.4.4 Data Archive 5. SERVICING SUPPORT REQUIREMENTS 5.1 Initiation Criteria 5.2 Planning Support

57

5.3 Orbital Replaceable Unit Requirements 5.4 Orbital Replacement Instrument Requirements 5.5 Space Support Equipment 5.6 Technical Information Management 6. SAFETY AND EQUIPMENT RELIABILITY 6.1 Crew Safety 6.2 Equipment Reliability

58

HUBBLE SPACE TELESCOPE LEVEL I REQUIREMENTS

FOR THE OPERATIONAL PHASE 1. SCOPE

This document combines and updates the original Hubble Space Telescope (HST) Level I Requirements document dated December 23,1983, the amendment dated October 29,1985, and the Level 1 Requirements operational phase augmentation document dated May 17, 1989. Approved waivers and approved Critical Decision Items (CDI’s) have been incorporated as required. The requirements herein cover the operational phase of the HST program. The performance requirements provided in this document represents the minimum performance levels to be used in assessing the need for on-orbit servicing or upgrade and for ground system modifications.

The mission of the HST Project is to provide a space observatory for use by the international astronomy community to increase the sensitivity and resolving power and extend the spectral range of astronomical observations decisively beyond those achievable from earth observatories.

The normal operations and condition of the HST will be maintained by NASA, including the command, Control and communications system. Within broad policy generated by NASA, the HST science program will be managed by the Space Telescope Science Institute (STScI) to maximize the scientific usefulness of the observatory and to bring the user community into direct contact with and control of the science that is done.

The European Space Agency (ESA) has provided two sets of solar arrays and one scientific instrument (the Faint Object Camera) for the Hubble Space Telescope and personnel for the STScI. In return, scientists from ESA member nations are guaranteed at least 15 percent of the HST observing time on the average through May 2001. ESA participation is defined in a Memorandum of Understanding.

1.1 Control This document shall be controlled at Level I by NASA Headquarters, Office of Space

Science (OSS), which carries the primary responsibility for fulfillment of these requirements.

2. OVERALL PROGRAM REQUIREMENTS The goal of the HST program during the operational phase is to maximize the scientific

productivity of the Observatory. To meet this goal, NASA shall operate, maintain and enhance the HST spacecraft and supporting ground systems while the Space Telescope Science Institute (STScI), in accordance with NASA policy guidance and oversight, shall conduct the HST science program.

2.1 Operational Life1 A high level of scientific productivity, using acquisition methods and strategies in

conjunction with instrumentation selected through peer review, shall be maintained to the extent

1 Per CDI-049.

59

possible, and/or practical, for 15 years, or longer2. The measures to be taken to achieve this will include:

a. operational work-arounds such as procedural and software changes,

b. orbital replacement of malfunctioning spacecraft equipment,

c. orbital replacement of scientific instruments,

d. orbital replacement of limited-life equipments or units, at the appropriate mission life points,

e. development of Space Support Equipment (SSE) to support maintenance missions,

f. maintenance and upgrade of the supporting ground system, and

g. reboost as required to maintain a satisfactory orbital altitude.

2.2 Servicing Mission Authorization The execution of all servicing missions requires approval by the NASA Administrator.

2.3 Scientific Capabilities A scientific measurement capability is provided through a complement of up to four axial

scientific instruments, one radial scientific instrument, and three Fine Guidance Sensor3. This capability shall be maintained and enhanced through the acquisition and on-orbit installation of replacement scientific instruments and Fine Guidance Sensors, and the maintenance and modification of the supporting ground system. The HST shall be able to accommodate a cryogenically-cooled infrared SI, including provision for the removal of evaporated cryogen from the aft shroud.

2.4 Space Transportation The Space Shuttle shall provide the basic transportation for all phases of the HST

program including deployment, on-orbit servicing, and reboost or return to earth.

2.5 Communications All normal forward and return link data transmission shall be via the NASA

Communications Network (NASCOM) and the Space Network (SN). In situations where there is an outage of the normal communication service, the remaining or replacement elements of the Deep Space Network (DSN) 26 meter subnet or the Goddard Space Flight Tracking and Data Network (GSTDN) shall provide tracking, command, and engineering telemetry for health and safety communications support.

2.6 Mission Termination At the completion of the useful operational life of the HST, as determined by NASA

Headquarters, the HST shall be either placed in a long-term stable orbit or safely deorbited.

2 Per CDI 054. 3 GSFC Waiver #11 points out that the first servicing mission installation of the corrective optics package

COSTAR left HST one short of the five SI’s called for in the original wording. The wording of this sentence has been modified to make it more flexible in terms of instrument complement.

60

3. OBSERVATORY PERFORMANCE The purpose of this section is to define the minimum acceptable performance capabilities

for the Observatory. These shall serve as criteria for planning and initiating orbital servicing activities. It is expected that some flight subsystems will degrade with time, e.g., the HST exterior thermal coatings, which cannot be refurbished or replaced and whose degradation cannot be circumvented by ground system work-arounds.

3.1 Image Quality The optical system shall consist of a f /24 Ritchey-Chretien telescope with a 2.4-meter

diameter primary mirror and corrective optics. The optical image, including effects of optical- wave front error, pointing stability, and scientific instrument to OTA alignment, should satisfy the following on-axis requirements at 6328 Angstroms and be a design goal at ultraviolet wavelengths: 70%4 of the total energy of a stellar image must be contained within a radius of 0.10 seconds of arc; the resolution of the image using the Rayleigh criterion for contrast shall be at least 0.10 seconds of arc; and the full-width half-intensity diameter of the image shall be no more than 0.10 seconds of arc. After correction for astigmatism, these specifications shall apply to the image quality over the entire usable HST field.

The HST shall be capable of collecting and imaging radiant energy in a broad spectral band from 1216 Angstroms to 10 micrometers. Specifically, the OTA optical throughput, which includes the combined reflectivity of both the primary and secondary mirrors and the central obscuration effect, shall be no less than 38 percent at 1216 Angstroms and 55 percent at 6328 Angstroms5.

The overall system must be capable of measuring unresolved objects appreciably fainter than those accessible from the ground; i.e., at least 27 mv with a signal-to-noise ratio of 10 in 4 hours of observing time6.

The overall system must be capable of measuring extended sources of surface brightness 25 mv per square seconds of arc with a signal-to-noise ratio of 10 in 10 hours, with a resolution of at least 0.25 seconds of arc7.

3.1.1 Image Stability The image jitter due to all causes shall be less than 0.012 arcsec R.M.S. over a period of

24 hours. The optical image quality, as defined in 3.1. shall be simultaneously maintained at the

4 GSFC Waiver #2 requested the 70% figure to be changed to 60% at 6328A and 35% at 1216 However,

the original Level I requirement was met or exceeded following 1993 servicing mission, so the requirement has not been modified.

5 GSFC Waiver #19 requested waiver based on reduced throughput that would result with incorporation of COSTAR. However, the original Level 1 requirement was met or exceeded following 1993 servicing mission, so the requirement has not been modified.

6 GSFC Waiver #3 wanted to reduce this requirement. The original Level I requirement was met or exceeded following 1993 servicing mission, so the requirement has not been modified.

7 GSFC Waiver #4 requested a 10% reduction in the requirement for extended object sensitivity. The original Level I requirement was met or exceeded following 1993 servicing mission, so the requirement has not been modified.

61

apertures of up to four axial scientific instruments8, one radial scientific instrument, and three Fine Guidance Sensors for elapsed periods of 24 hours allowing up to 4 hours for thermal stabilization after thermally worst-case slews.

3.1.2 Target Positioning9 The HST shall contribute an error no greater than 0.03 arc seconds during the acquisition

and positioning of a fixed or moving target within any instrument aperture.

3.1.3 Guide Star Acquisition & Tracking10 The HST must be able to acquire and track on guide stars in at least 75% of randomly

selected targets located at the galactic poles when using the stellar statistics of “Guide Star Probabilities,” NASA Contractor Report 3374, January 1981.

3.1.4 Solar System Object Tracking11 Tracking errors for moving targets shall remain less than 0.03 arcsec. r.m.s., for tracking

rates less than 0.02 arcsec/sec, and less than 0.04 arcsec, r.m.s., for tracking rates between 0.02 and 0.20arcsec/sec, over 3 arcmin apparent displacement.

3.1.5 Stray Light Performance The scattered light surface brightness must be less than 23 mv per square seconds of arc

except within 50 degrees of arc of the sun or 30 degrees of arc of the moon or 90 degrees of arc of the bright earth limb12.

3.2 Scientific Observational Capabilities The scientific productivity of the HST requires that certain core observational capabilities

be maintained throughout its operational lifetime. Loss of any of these capabilities shall justify instrument replacement at the earliest planned servicing mission.

3.2.1 Core observational Capabilities Allocation of time and details of observing programs are based on scientific merit. In the

long term, a stable observational capability shall be provided to enable the following:

a. Visible photometric imaging at high spatial resolution for science and target acquisition support.

b. Ultraviolet spectrophotometry at medium to high spectral and spatial resolution.

c. Near infrared spectrophotometry (> 1 micron) and imaging with high resolution. This capability is to be available for at least five years of HST lifetime, and should be instituted as soon as possible after launch13.

8 GSFC Waiver #11 points out that the first servicing mission installation of the corrective optics package

COSTAR left HST one short of the five SI’s called for in the original wording. The wording of this sentence has been modified to make it more flexible in terms of instrument complement.

9 Per CDI-057. 10 Per CDI-058. 11 CDI-063 waived this requirement for launch, but required implementation by March 1991. In 1993,

GSFC requested a further waiver, which was denied. 12 Revised from 80 degrees to 90 degrees per CDI-055. 13 Per CDI-066.

62

High spatial resolution is intended to mean roughly 2 samples per cycle at a 50% value of the Optical Telescope modulation transfer function. Medium and high spectral resolutions are intended to mean 1000 and 30,000, respectively. The minimum fields of view for the UV/visible and IR imaging shall be approximately 90 and 10 arcsec, respectively. Performance degradation below any of the levels stipulated – but not total loss – does not constitute justification for immediate instrument replacement, but shall be a factor in prioritizing replacement in service mission planning. The capability of conducting parallel observations, i.e., concurrent operation of any two science instruments on a noninterference basis, is a general core capability.

3.2.2 Additional Observational Capabilities In addition to the core capabilities, a versatile observational capability shall be

maintained to support, at any time, at least several of the following:

a Wide field of view (approx. 2 arcmin) visible imaging

b. Imaging at UV wavelengths

c. Faint object (approx. mv = 20.5) visible spectroscopy at high spatial resolution

d Faint object UV spectroscopy

e. Very high resolution (approx. 105) UV spectroscopy

f. High speed (approx. 20 microsec) photometry.

3.3 Spacecraft Subsystems Performance In general, unacceptable subsystem performance is that which compromises the

observational capabilities specified in Section 3.2 or results in operational impacts which degrade science productivity. Specific requirements, which are particularly relevant to the maintenance of adequate support for science mission operations, follow.

3.3.1 Power14 The electrical power system shall provide adequate energy to maintain the scientific

operational capabilities stated in paragraphs 3.2 and 3.2.1. In addition, the batteries shall maintain sufficient storage capability to enter safemode or gravity gradient mode (164 amp- hours). A servicing mission will be required prior to the time that the battery storage capability is projected to be less than 164 amp-hours or the solar array capability is projected to be less than that required to maintain scientific operational capabilities in paragraphs 3.2 and 3.2.1.

3.3.2 On-Board Data Storage The flight system shall provide at least 100 Mbytes of science and engineering data

storage.

3.3.3 Data Quality The system shall provide a bit error rate not worse than 2.5×10-5 without Reed – Solomon

encoding for all telemetry and 1×10-7 for end-to-end data flow for all data processed by the SI C&DH with Reed-Solomon encoding.

14 Per CDI-053

63

3.3.4 Time/Frequency The system shall provide a clock signal to the science instruments with a 1 microsecond

resolution relatable to Universal Time Code (UTC) to within 10 milliseconds. Frequency stability of the on-board frequency signal shall be at least lX10-9 over 24 hours.

3.3.5 Data Management The on-board system shall manage and communicate a long term average of 300 Mbytes

of science data per day. It shall be capable of supporting approximately a twofold growth in this average data volume due to advanced instrument requirements.

4. GROUND SYSTEM REQUIREMENTS The ground system required to support the HST program shall support Observatory and

science management, the former performed by the Goddard Space Flight Center (GSFC) and the latter, under contract to GSFC, by the Space Telescope Science Institute (STSCI).

4.1 General Functional Capabilities The ground system shall provide the following general routine functional capabilities in

support of mission operations:

a. Spacecraft and scientific instrument command and control.

b. Performance monitoring and engineering trend analysis.

c. Science and mission planning and scheduling, including parallel science data acquisition and parallel event scheduling.

d. Capture and processing of engineering and science data.

e. Science data analysis and general observer selection and support.

f. Archiving and distribution of science data and archival research support.

g. Support for spacecraft subsystem and science instrument maintenance, replacement and refurbishment.

h. Orbit and attitude data collection and processing.

4.2 Observatory Operations The ground system shall be capable of supporting HST operations on a continuous basis.

Availability for all mission critical facilities shall be at least 99.8% with a mean time to repair of less than 1 hour. The availability for off-line support systems shall be greater than 97.5% with a mean time-to repair of 8 hours. Routine maintenance shall be performed without disruption of flight operations support. The observatory operations project organization shall ensure that sufficient and appropriate hardware equipments and software programmers-developers and key hardware and software maintenance skills are available to support expected life-cycle activities, including the incorporation of efficiency and capabilities enhancements and upgrades and problems resolution.

64

4.2.1 On Line Operations The following on-line operational capabilities, normally used to support real time

transactions, shall be provided15:

a. Generation, uplink, and logging of command loads and real-time commands.

b. Monitoring of all flight systems and science instruments in order to assure their health, safety, and data quality.

c. Generation and uplink of commands to adjust pointing and maintain tracking.

d. Attitude determination and sensor calibration in support of pointing control.

e. Monitoring and recording of the performance, runtime, and any anomalies in the flight and ground systems.

4.2.2 Planning and Scheduling The ground system shall provide the following capabilities:

a. Planning and scheduling, accounting for all constraints, in order to maximize efficient use of the Observatory. The goal is to achieve an annual average of 35% on-target time (OTT). OTT is defined to be the period which begins with the initiation of the Fine Guidance Sensor (FGS) acquisition process and ends with the release of the telescope pointing control each orbit (e.g., the HST is released to slew to the next target). In achieving this 35% goal, the intent is to minimize the amount of “on target’ time spent for acquisition while maximizing the actual amount of target exposure time. If an observation can be accomplished on gyro control only, then OTT begins with commencement of science data collection or with any instrument- peculiar target acquisition procedures (e.g., shutter open) and ends with release of spacecraft pointing control each orbit.

b. Planning maneuvers and housekeeping activities to maintain the amount of dark time available for scientific observing at or above 20 minutes per orbit averaged over the precession cycle.

c. Timeline re-planning and scheduling for observing targets of opportunity within 24 hours of authorization.

d. Concurrent operation of two scientific instruments (parallel science) plus the use of a Fine Guidance Sensor for astrometry16.

e. Preparation of schedules and command loads for 24 clock-time hours of HST operation, including scheduling of parallel activities, in less than 12 working hours as a goal, and including the ability to reschedule 5% of these activities in response to mission needs17.

f. Maintaining reference materials and procedures to enable acquisition, tracking and observation of moving targets as per Section 3.1.4.

15 Interactive selection and execution of alternative preplanned mission sequences (referred to as branching)

for up to 20% of the total activity” was formally waived via CDI-062 and GSFC Waiver #16. 16 Per CDI-059, waived for launch but to be implemented by March ’91. 17 Per CDI-061-Rl.

65

4.2.3 Servicing Mission Planning The ground system, to support planning for servicing missions, shall provide reliability

forecasting, mission simulations, mission operations and post-mission data processing and analysis.

4.2.4 Simulation and Test The capability shall be provided to simulate the operation of the HST to support building

or modifying hardware and software over the full life cycle of HST, test operational procedures and commands, assist in fault diagnostics, verify compliance of new subsystems against interfaces, and train new operators. The system shall be capable of testing new or revised flight software before installation without undue disturbance of ongoing normal orbital operations.

4.3 Data Acquisition The ground system shall maintain and upgrade its data capture and processing throughput

capability commensurate with advanced science instrument requirements.

4.3.1 Data Rates The ground system shall be capable of simultaneously receiving data at rates of 1.024

Mbps and 32 or 4 or 0.5 Kbps.

4.3.2 Data Volume The ground system shall be capable of capturing a peak maximum data volume of 900

Mbytes in a 24 hour period and of processing, on a long term average, 300 Mbytes daily for transmission to the STScI within 24 hours after receipt.

4.3.3 Data Storage The ground system shall provide a minimum of 30 days of fail-safe storage of captured

(unedited) data.

4.3.4 Data Dissemination After a one year proprietary period, HST data shall be made accessible to the general

scientific community. Archived data shall be periodically transferred to the HST European Coordination Facility and other facilities as authorized by the Associate Administrator, Office of Space Science.

4.4 Science Operations The STScI has been established for the purpose of conducting and managing the science operations of the HST program. Its primary functions include:

a. Establishment of science program guidelines.

b. Selection of HST general observers and archival researchers, providing them technical assistance with their research programs, and managing grants to selected U.S. general observers.

c. Developing operational procedures and science observing schedules, including parallel science and parallel events scheduling.

d. Providing applications utilities and calibration data for analysis of HST data.

66

e. Processing, archiving and publicizing HST science data and results.

f. Evaluating Observatory and scientific instrument performance.

g. Maintaining the Guide Star Selection System.

4.4.1 Research Management The ground system shall provide for the management and selection of research proposals,

tracking associated resource requirements, and maintaining resulting products of the research throughout the life of the program.

4.4.2 Observing Support18 The ground system shall have the capability to support two general observers

concurrently in the conduct of their observing programs involving such functional areas as target acquisition, acquisition verification, and quick-look data analysis.

4.4.3 Science Data Processing and Products Calibrated standard data products shall be available to observers within five days of their

acquisition. Uncalibrated data in SOGS format19 shall be available to observers 24 hours after receipt by the STScI Calibration algorithms, tables, and files shall be made available to authorized observers within thirty days of the request. Transportable versions of the data analysis software shall be maintained for use by observers who have access to compatible computers.

4.4.4 Data Archive The capability shall be provided to archive, search and retrieve all the edited and

calibrated science and related engineering data. The system shall support the access and distribution needs of up to 1000 archival researchers per year. A minimum of 3 years of current data shall be maintained on-line to facilitate automatic real-time interactive access. The remainder shall be permanently archived and retrievable, within a reasonable time, on request (“reasonable” defined as seconds to minutes if requested by an online user, and 1-2 weeks if by mail). The system shall accommodate both local and remote users via electronic access, restrict access to only authorized users, and prevent against inadvertent loss or destruction of data, accidental or malicious.

5. SERVICING SUPPORT REQUIREMENTS Over the operational lifetime of the HST, a capability must be maintained for on orbit

servicing in order to restore, wherever possible, original levels of performance and to enhance the science capability. Assuring this involves the timely development of replacement scientific instruments; Space Shuttle Program support; servicing mission planning; timely availability of Orbital Replaceable Units (ORUs); the development and maintenance of supporting test equipment, ORU delivery systems, spare components, and the Space Support Equipment (SSE); and a ground logistics system. Two classes of missions may be needed: Planned Service Missions (PSM) and Contingency Service Missions (CSM). Although both types require planning, the CSM launch preparation is triggered by a critical event, whereas the PSM occurs

18 GSFC Waiver #18 eliminated branching as a requirement. 19 Per CDI-064.

67

on a schedule related to forecasted maintenance need. A PSM is used to restore or upgrade the Observatory and scientific instrument performance (cf. Section 3.0). It is also used to reboost the spacecraft. The CSM corrects a failure which leaves a single point failure mode in a mission critical subsystem. A CSM may also be utilized to reboost the Observatory.

The program infrastructure shall maintain the capability to return the HST from orbit. The capability to return the HST from orbit shall not be maintained for every HST servicing mission, but instead will be provided only if so specified in the mission call-up instructions. That is, the hardware, software, procedures, etc., necessary for returning the HST from orbit shall be developed, verified, etc., on a schedule that permits the recovery of the HST by the Space Shuttle from orbit on any mission so desired, provided that recovery capability is specifically ordered up prior to mission initiation. Specific hardware capability does not, however, have to be planned for nor carried on every servicing mission, thus optimizing the use of the Space Shuttle lift capability to better support HST servicing missions where there is no identified imminent need for returning the HST.

5.1 Initiation Criteria The decision to perform a servicing mission will be made by the Administrator in

response to an Office of Space Science request. The request for a CSM will be initiated as soon as a justifying condition or pending condition is established. The need and requirements for a PSM shall be reviewed at least every six months and, under normal circumstances, confirmed at least 18 months prior to the scheduled launch.

A CSM will be requested whenever there is a loss of an ORV(s) which leaves the HST with a potential single point mission failure. A mission failure condition is one in which the Observatory is no longer in communication with the ground or commandable, cannot be safely retrieved for servicing or reboost, is unable to support any science operations, or has lost the scientific payload. Potential failure of any one of the five major subsystems – power, thermal, pointing control, command and data handling, communications – is justification for initiating the CSM process.

The criteria considered in planning and requesting a PSM are the forecast of:

a. Orbital decay to an altitude such that science operations become constrained or mission duration is imperiled.

b. Loss of core observational capability as specified in Section 3.2.1

c. Subsystem performance degradation below levels specified in Section 3.

d. Availability of advanced instruments.

Activities supporting conduct of a CSM ‘will require major mobilization of effort across NASA in order to effect rapid repair of the HST. The basic purpose or such a call-up will of course be to repair the HST before it sustains further failure which could then result in irreversible damage to or loss of the Observatory. For planning purposes, the maximum allowable Space Shuttle response time – that is, time from call-up of the CSM by the Administrator to achieving launch readiness status – is assumed to be no greater than 12 months.

If resources and the situation allow, routine servicing activities and/or replacement of scientific instruments may be accomplished during a CSM.

68

5.2 Planning Support The servicing support system shall:

a Maintain a long term schedule of servicing missions including best estimate of launch dates, the most likely complements of subsystems and scientific instruments, and associated procurement schedules and activities.

b. Provide a reliability model of the HST, updated periodically with flight data, for use in decision support and logistics management.

c. Account for all ORUs through a logistics data system covering reliability parameters, inventory status, and EVA timeline activities and tool requirements.

d. Maintain trend analyses on sub-system performance, orbital decay and relevant geophysical models.

5.3 ORU Requirements An inventory of critical Orbital Replaceable Units (ORUs) shall be provisioned and

maintained to ensure support of a CSM call-up at any time. The inventory shall also include those ORUs which need to be replaced on PSMs based on current forecasts of need dates. To the extent the budget permits, an inventory of desirable ORU changeouts, i.e., those which will result in enhancements, shall also be supported.

5.4 Orbital Replacement Instrument Requirements In order to meet the scientific performance requirements established in Section 3.2 or to

upgrade FIST science return, additional scientific instruments will be acquired for installation on PSMs. These Orbital Replacement Instruments (ORIs) shall:

a. Be fully compatible with the flight and ground data management and communication systems, as they currently exist or are expected to be upgraded.

b. Meet operational phase thermal, mechanical and electrical interface specifications.

c. Have as a design goal an operational lifetime of at least 5 years.

d. Use, to the maximum extent practicable, on-orbit replaceable subsystems. Algorithms shall be provided along with the ORIs to permit on- orbit support and instrument-unique ground data processing.

5.5 Space Support Equipment A baseline set of reconfigurable Space Support Equipment (SSE) shall be maintained to

support servicing missions. This baseline includes:

a. The Flight Support System (FSS) to provide the mechanical and electrical interface between HST and the Space Shuttle.

b. Orbital Replacement Unit Carrier(s) to provide mounting, power, environmental protection and load isolation for the ORUs and ORIs.

c. EVA crew aids and tools.

On a single mission, the capability shall exist to carry into orbit a full set of replacement batteries, a set of solar arrays, at least one radial and one axial module, and multiple ORUs as required. The actual servicing mission equipment mix for a given mission will be determined by

69

Observatory performance and trend analyses, space support equipment considerations, available EVA capability, Space Shuttle performance capabilities, and other considerations determined relevant at the time.

5.6 Technical Information Management An automated information management system shall be maintained which provides:

a. Management and resource control data.

b. Technical design and test data.

6. SAFETY AND EQUIPMENT RELIABILITY 6.1 Crew Safety

The design of the SSE, ORUs and ORIs shall assure that the Space Shuttle Orbiter or crew safety shall not be compromised at any time under either normal or contingency modes of operation. These modes include all phases of mission activity, i.e., rendezvous, capture, on-orbit maintenance, redeployment, reboost and earth return.

6.2 Equipment Reliability The HST and SSE shall meet the requirement that no single failure or operator error

result in damage to the Space Shuttle. Any deployment or extension which could prevent payload bay door closure must be controlled by independent primary and backup methods, and the combination must be two-failure tolerant. Payload equipment which could interfere with the closing of the payload bay doors shall be jettisonable without EVA.

The HST shall have no single point failure that will jeopardize recovery of the HST or affect Space Shuttle crew safety. Nor shall a single point failure within the HST subsystems cause a permanent loss of command capability, engineering telemetry, or scientific data. HST structures shall be designed with adequate factors of safety to meet these requirements.

GLOBAL POSITIONING SYSTEM SYSTEMS ENGINEERING

CASE STUDY

4 October 2007

Air Force Center for Systems Engineering (AFIT/SY)

Air Force Institute of Technology 2950 Hobson Way, Wright-Patterson AFB OH 45433-7765 Preface

In response to Air Force Secretary James G. Roche’s charge to reinvigorate the systems

engineering profession, the Air Force Institute of Technology (AFIT) undertook a broad spec- trum of initiatives that included creating new and innovative instructional material. The material included case studies of past programs to teach the principles of systems engineering via “real world” examples.

Four case studies, the first set in a planned series, were developed with the oversight of the Subcommittee on Systems Engineering to the Air University Board of Visitors. The Subcommittee included the following distinguished individuals: Chairman Dr. Alex Levis, AF/ST Members Tom Sheridan, Brigadier General Dr. Daniel Stewart, AFMC/CD Dr. George Friedman, University of Southern California Dr. Andrew Sage, George Mason University

Dr. Elliot Axelband, University of Southern California Dr. Dennis Buede, Innovative Decisions Inc Dr. Dave Evans, Aerospace Institute Dr. Levis and the Subcommittee on Systems Engineering crafted the idea of publishing

these case studies, reviewed several proposals, selected four systems as the initial cases for study, and continued to provide guidance throughout their development. The Subcommittee members have been a guiding force to charter, review, and approve the work of the authors. The four case studies produced in that series were the C-5A Galaxy, the F-111, the Hubble Space Telescope, and the Theater Battle Management Core System. The second series of case studies produced were the B-2 Spirit Stealth Bomber and the Joint Air-To-Surface Standoff Missile (JASSM).

This third series includes the Global Positioning System (GPS).

[Pending] Approved for Public Release; Distribution Unlimited

The views expressed in this Case Study are those of the author(s) and do not reflect the official policy or position of the United States Air Force, the Department of Defense, or the

United States Government

2

Foreword

At the direction of the Secretary of the Air Force, Dr. James G. Roche, the Air Force Institute of Technology (AFIT) established a Center for Systems Engineering (CSE) at its Wright Patterson AFB, campus in 2002. With academic oversight by a Subcommittee on Systems Engi- neering, chaired by Air Force Chief Scientist Dr. Alex Lewis, the CSE was tasked to develop case studies focusing on the application of systems engineering principles within various Air Force programs. The committee drafted an initial case outline and learning objectives, and suggested the use of the Friedman-Sage Framework to guide overall analysis.

The CSE contracted for management support with Universal Technology Corporation (UTC) in July 2003. Principal investigators for the four case studies published in the initial series included Mr. John Griffin for the C-5A, Dr. G. Keith Richey for the F-111, Mr. James Mattice for the Hubble Telescope, and Mr. Josh Collens for the Theater Battle Management Core System. These cases were published in 2004. Two additional case studies have since been added to this series with the principal investigators being Mr. John Griffin for the B-2 and Dr. Bill Stockman for the JASSM. All case studies (with the exception of JASSM) are available on the CSE website [http://www.afit.edu/cse].

The Department of Defense continues to develop and acquire joint complex systems that deliver needed capabilities demanded by our warfighter. Systems engineering is the technical and technical management process that focuses explicitly on delivering and sustaining robust, high-quality, affordable products. The Air Force leadership, from the Secretary of the Air Force through the Commander of the Air Force Materiel Command, has collectively stated the need to mature a sound systems engineering process throughout the Air Force.

Plans exist for future case studies focusing on other areas. Suggestions have included

other Joint-service programs, logistics-led programs, science and technology/laboratory efforts, additional aircraft programs, and successful commercial systems.

As we uncovered historical facts and conducted key interviews with program managers

and chief engineers, both within the government and those working for the various prime and subcontractors, we concluded that systems programs face similar challenges today. Applicable systems engineering principles and the effects of communication and the environment continue to challenge our ability to provide a balanced technical solution. We look forward to your comments on this GPS case, our other CSE published studies, and future case studies.

GEORGE E. MOONEY, SES Director, Air Force Center for Systems Engineering Air Force Institute of Technology

http://www.afit.edu/cse

3

Acknowledgements To those who contributed to this report:

The authors would like to acknowledge the special contributions of people who dedicated their time and energy to make this report accurate and complete. We offer our sincere appreciation to all people listed in Appendix 4 who volunteered their time and insight during the interviews, especially Col. (ret.) Rick Reaser. He identified an extensive list of potential interviewees at the Joint Program Office (JPO), other government agencies and contractors, and also provided several early reference documents that allowed the authors to gain significant insight into the systems engineering process when the “well appeared dry.” Capt. Steaven Meyer, GPS JPO, helped set up the capability to obtain limited access to the GPS website, which provided much- needed program baseline documents. We send a special thanks to Mr. Frank Smith, Ms. Vicki Hellmund, Andrea Snell, and Ms. Niki Maxwell from the University of Dayton Research Institute. Mr. Smith helped “in a pinch” to conduct research and interviews and provide insight into the GPS program in order to keep the study on track. Ms. Maxwell’s effort in editing and formatting resulted in a polished study report. Our apologies and thanks to Doug Robertson who, “being within arm’s reach”, was pestered with GPS trivial questions for clarification.

We also provide a special thank you and note of appreciation to our AFIT Project Leaders, Maj. Eileen Pimentel and Mr. Randy Bullard, who provided guidance to the authors, along with continuous motivation.

To those who made GPS work:

We would also like to take this opportunity to express gratitude to all the people in the program, especially the systems engineers and design engineers at Rockwell, IBM, Rockwell Collins, Magnavox, General Dynamics, the vendors, the Naval Research Laboratory, the US Naval Observatory, Aerospace Corporation, the GPS Joint Program Office and the many other supporting agencies. They took the glimmer of an idea and delivered an outstanding, precise navigation capability that has not only served the US military, but military internationally and the commercial world, spanning so many other applications beyond navigation.

We owe the people of the GPS Program a great deal of gratitude. They made sacrifices

in time, some in careers, and dedicated themselves as a team to bring a vision to reality. They worked in anonymity, never asking for credit. And without fanfare, they changed everything. Thanks.

Patrick J. O’Brien John M. Griffin

4

Table of Contents Preface ……………………………………………………………………………………………………….. 2 Foreword…………………………………………………………………………………………………….. 3 Acknowledgements ………………………………………………………………………………………. 4 Table of Contents ………………………………………………………………………………………… 5 List of Figures …………………………………………………………………………………………….. 7 1. SYSTEMS ENGINEERING PRINCIPLES …………………………………………….. 9

1.1 General Systems Engineering Process …………………………………………………………………… 9 1.1.1 Introduction…………………………………………………………………………………………………….. 9 1.1.2 Case Study …………………………………………………………………………………………………….. 11 1.1.3 Framework for Analysis ………………………………………………………………………………….. 12

1.2 GPS Friedman-Sage Matrix ………………………………………………………………………………… 13 2. SYSTEM DESCRIPTION ……………………………………………………………………. 14

2.1 Mission ………………………………………………………………………………………………………………. 14 2.2 Features ……………………………………………………………………………………………………………… 14 2.3 System Design …………………………………………………………………………………………………….. 14

2.3.1 Space Vehicle ………………………………………………………………………………………………… 14 2.3.2 User Equipment …………………………………………………………………………………………….. 17 2.3.3 Control Segment…………………………………………………………………………………………….. 18 2.3.4 Nuclear Detection System (NDS) ……………………………………………………………………… 19 2.3.5 “NAVSTAR/GPS” ………………………………………………………………………………………….. 19

3. GPS PROGRAM EXECUTION ……………………………………………………………. 20 3.1 Early Programs ………………………………………………………………………………………………….. 20 3.2 Establishment of a Joint Program ……………………………………………………………………….. 25 3.3 Concept/Validation Phase (Phase I) …………………………………………………………………….. 28

3.3.1 Objectives ……………………………………………………………………………………………………… 28 3.3.2 Requirements …………………………………………………………………………………………………. 29 3.3.3 Acquisition Strategy ……………………………………………………………………………………….. 31 3.3.4 Trade Studies ………………………………………………………………………………………………… 33 3.3.5 Risk Mitigation ………………………………………………………………………………………………. 35 3.3.6 System Integration …………………………………………………………………………………………. 38 3.3.7 Systems Engineering ………………………………………………………………………………………. 42 3.3.8 DSARC II ……………………………………………………………………………………………………… 45

3.4 System Development (Phase II, Block I) ………………………………………………………………. 45 3.4.1 Objectives ……………………………………………………………………………………………………… 45 3.4.2 Systems Engineering (JPO) …………………………………………………………………………….. 46 3.4.3 Interface Requirements …………………………………………………………………………………… 46 3.4.4 Budgetary Impacts to Functional Baseline ………………………………………………………… 47 3.4.5 Rockwell International Systems Engineering …………………………………………………….. 48 3.4.6 Atomic Clocks ……………………………………………………………………………………………….. 51 3.4.7 Control Segment…………………………………………………………………………………………….. 53 3.4.8 User Equipment …………………………………………………………………………………………….. 54 3.4.9 Design Reviews ……………………………………………………………………………………………… 56 3.4.10 System Integration ……………………………………………………………………………………….. 56

5

3.4.11 ICWG …………………………………………………………………………………………………………. 56 3.5 Production and Deployment (Phase III, Block II/IIA) ………………………………………….. 57

3.5.1 Objective ………………………………………………………………………………………………………. 57 3.5.2 Acquisition Strategy ……………………………………………………………………………………….. 57 3.5.3 Nuclear Detection System ……………………………………………………………………………….. 57 3.5.4 Shuttle Impact to Functional Baseline ………………………………………………………………. 59 3.5.5 User Equipment (UE) Development Testing Effects ……………………………………………. 62 3.5.6 Control Segment…………………………………………………………………………………………….. 63 3.5.7 Requirements Validation & Verification …………………………………………………………… 67

3.6. Replenishment Program Block IIR …………………………………………………………………….. 67 3.6.1 Objective ………………………………………………………………………………………………………. 67 3.6.2 Acquisition Strategy ……………………………………………………………………………………….. 67 3.6.3 Requirements …………………………………………………………………………………………………. 68 3.6.4 Critical Design Reviews ………………………………………………………………………………….. 68 3.6.5 User Equipment …………………………………………………………………………………………….. 69

3.7 Full Operational Capability ………………………………………………………………………………… 70 4. SUMMARY …………………………………………………………………………………………. 72 5. QUESTIONS FOR THE STUDENT …………………………………………………….. 73 6. REFERENCES …………………………………………………………………………………… 74 7. LIST OF APPENDICES ……………………………………………………………………… 78 Appendix 1 – Complete Friedman-Sage Matrix for GPS ………………………………. 79 Appendix 2 – Author Biographies ……………………………………………………………….. 70 Appendix 3 – Interviews ……………………………………………………………………………… 72 Appendix 4 – Navigation Satellite Study ………………………………………………………. 73 Appendix 5 – Rockwell’s GPS Block 1 Organization Chart ………………………….123 Appendix 6 – GPS JPO Organization Chart ……………………………………………….123 Appendix 6 – GPS JPO Organization Chart ……………………………………………….124 Appendix 7 – Operational Performance Requirements ………………………………..125

6

List of Figures Figure 1-1. The Systems Engineering Process, Defense Acquisition University ……………………….. 10 Figure 2-1. 24-Spaced-Based Satellite Constellation (Ref. 46) ………………………………………………. 15 Figure 2-2. Navigational Technology Satellite (Ref. 23) ……………………………………………………… 16 Figure 2-3. Block I GPS Satellite …………………………………………………………………………………….. 16 Figure 2-4. Block IIA GPS Satellite …………………………………………………………………………………. 16 Figure 2-5. Block IIR GPS Satellite ………………………………………………………………………………… 17 Figure 2-6. Block IIF GPS Satellite ………………………………………………………………………………… 17 Figure 2-7. Rockwell Collins Precision Lightweight GPS Receiver (PLGR) (left) and Defense Advanced GPS Receiver (DAGR) (right) a later version of the PLGR (Ref. 48, 45) ………………. 17 Figure 2-8. Magellan Marine Receiver (Ref. 46) ……………………………………………………………… 18 Figure 2-9. Control Segment (Ref. 42) ……………………………………………………………………………. 19 Figure 2-10. NDS System Segments (Ref. 49)…………………………………………………………………… 19 Figure 3-1. Program Schedule (Ref. 13) …………………………………………………………………………. 27 Figure 3-2. System Interfaces (Ref. 28) …………………………………………………………………………… 30 Figure 3-3. Rockwell Collins GDM (Ref. 47) …………………………………………………………………… 32 Figure 3-4. Planned Constellation Development before 1974. Proof of Concept has 6 Block I satellites in 2 planes. Build up to 24 Block II satellites in 3 planes (Ref. 18) ………………………… 34 Figure 3-5. NTS-2 Command and Telemetry Links (Ref. 1) ……………………………………………….. 36 Figure 3-6. NTS-2 Satellite (Ref. 23) ………………………………………………………………………………. 36 Figure 3-7. Phase 1 YPG Test Results (Ref. 51) ……………………………………………………………….. 38 Figure 3-8. GPS JPO Agency/Contractor Interfaces ………………………………………………………… 39 Figure 3-9. Phase I Specification Tree (Ref. 28) ………………………………………………………………. 40 Figure 3-10. Phase II Specification Tree (Ref. 41) ……………………………………………………………. 40 Figure 3-11. Interface Control Documents (chart from 2005 JPO SE briefing that captures the breadth of some 200 ICDs) (Ref. 29) ……………………………………………………………………………….. 42 Figure 3-12. GPS Functional Flow Diagram (Ref. 28) ……………………………………………………… 43 Figure 3-13. Block II Cesium Atomic Clock (Ref. 50) ……………………………………………………….. 52 Figure 3-14. Block IIA Satellite ……………………………………………………………………………………… 59 Figure 3-15. Space Segment System Relationship (Ref. 44) ……………………………………………….. 60 Figure 3-16. Delta II Launch of Block II Satellites …………………………………………………………… 62 Figure 3-17. Rockwell Collins Manpack (Ref. 47) ……………………………………………………………. 63 Figure 3-18. Operational Control System Top Level System Diagram (Ref. 43) …………………… 65 Figure 3-19. 24-Satellite Constellation (Ref. 49) ……………………………………………………………… 67 Figure 3-20. DoD of UE Family Tree Collins Manpack (Ref. 35) ………………………………………. 70

7

List of Tables Table 1-1. A Framework of Key Systems Engineering Concepts and Responsibilities ……………….. 13 Table 3-1. Major Events in Navigation and GPS Events/Milestones …………………………………… 21 Table 3-2. Expected GPS Performance (Ref. 13) ………………………………………………………………. 26 Table 3-3. Proposed Classes of User Equipment (Ref. 13) ………………………………………………… 28 Table 3-4. Phase I Major Contractors (Ref. 4) …………………………………………………………………. 31 Table 3-5. General Dynamics Phase I Trade Studies (Ref. 19) …………………………………………… 33 Table 3-6. GPS PPS System Error Range Budget (Ref. 42)* ……………………………………………… 44 Table 3-7. GPS Time Error Budget (Ref. 42) …………………………………………………………………… 45 Table 3-8. GPS Atomic Clocks [8, Fruehauf, 21 Reaser, 30 White] ……………………………………. 53 Table 3-9. Army and PLGR Requirements (Ref. 32) System Description …………………………….. 69

8

1. SYSTEMS ENGINEERING PRINCIPLES 1.1 General Systems Engineering Process

1.1.1 Introduction

The Department of Defense continues to develop and acquire joint systems and deliver needed capabilities to the warfighter. With a constant objective to improve and mature the acquisi- tion process, it continues to pursue new and creative methodologies to purchase these technically complex systems. A sound systems engineering process, focused explicitly on delivering and sustaining robust, high-quality, affordable products that meet the needs of customers and stake- holders must continue to evolve and mature. Systems engineering is the technical and technical management process that results in delivered products and systems that exhibit the best balance of cost and performance. The process must operate effectively with desired mission-level capabilities, establish system-level requirements, allocate these down to the lowest level of the design, and ensure validation and verification of performance, while meeting the cost and schedule constraints.

The systems engineering process changes as the program progresses from one phase to

the next, as do tools and procedures. The process also changes over the decades, maturing, growing, and evolving from the base established during the conduct of past programs. Systems engineering has a long history. Examples can be found demonstrating application of effective engineering and engineering management, as well as poorly applied, but well-defined processes. Throughout the many decades during which systems engineering has emerged as a discipline, many practices, processes, heuristics, and tools have been developed, documented, and applied.

System requirements are critical to all facets of successful system program development. First, system development must proceed from a well-developed set of requirements. Second, regardless of the evolutionary acquisition approach, the system requirements must flow down to all subsystems and lower-level components. And third, the system requirements must be stable, balanced, and must properly reflect all activities in all intended environments. However, system requirements are not unchangeable. As the system design proceeds, if a requirement or set of requirements is proving excessively expensive to satisfy, the process must rebalance schedule, cost, and performance by changing or modifying the requirements or set of requirements.

Systems engineering includes making key system and design trades early in the process to

establish the system architecture. These architectural artifacts can depict any new system, legacy system, modifications thereto, introduction of new technologies, and overall system-level behavior and performance. Modeling and simulation are generally employed to organize and assess architectural alternatives at this stage. System and subsystem design follows the functional architecture. System architectures are modified if elements are too risky, expensive, or time- consuming. Both newer object-oriented analysis and design, and classic structured analysis using functional decomposition and information flows/data modeling occur. Design proceeds logically using key design reviews, tradeoff analysis, and prototyping to reduce any high-risk technology areas.

9

Important to the efficient decomposition and creation of functional and physical archi- tectural designs are the management of interfaces and the integration of subsystems. Interface management and integration is applied to subsystems within a system or across a large, complex system of systems. Once a solution is planned, analyzed, designed, and constructed, validation and verification take place to ensure satisfaction of requirements. Definition of test criteria, measures of effectiveness (MOEs), and measures of performance (MOPs) are established as part of the requirements process, taking place well before any component/subsystem assembly design and construction occurs.

There are several excellent representations of the systems engineering process presented in the literature. These depictions present the current state of the art in maturity and evaluation of the systems engineering process. One can find systems engineering process definitions, guides, and handbooks from the International Council on Systems Engineering (INCOSE), European Industrial Association (EIA), Institute of Electrical and Electronics Engineers (IEEE), and various Department of Defense (DoD) agencies and organizations. They show the process as it should be applied by today’s experienced practitioner. One of these processes, long used by the Defense Acquisition University (DAU), is depicted in Figure 1-1. It should be noted that this model is not accomplished in a single pass. This iterative and nested process gets repeated to the lowest level of definition of the design and its interfaces.

Figure 1-1. The Systems Engineering Process, Defense Acquisition University

The DAU model, like all others, has been documented in the last two decades, and has

expanded and developed to reflect a changing environment. Systems are becoming increasingly complex internally and more interconnected externally. The process used to develop aircraft and

10

systems of the past was effective at the time. It served the needs of the practitioners and resulted in many successful systems in our inventory. Notwithstanding, the cost and schedule performance of the past programs are replete with examples of well-managed programs and ones with less-stellar execution. As the nation entered the 1980s and 1990s, large DoD and commercial acquisitions experienced overrunning costs and slipping schedules. The aerospace industry and its organizations were becoming larger and were more geographically and culturally distributed. Large aerospace companies have worked diligently to establish common systems engineering practices across their enterprises. However, because of the mega-trend of teaming in large (and some small) programs, these common practices must be understood and used beyond the enterprise and to multiple corporations. It is essential that the systems engineering process govern integration, balance, allocation, and verification, and be useful to the entire program team down to the design and interface level.

Today, many factors overshadow new acquisition; including system-of-systems (SoS) con- text, network centric warfare and operations, and rapid growth in information technology. These factors are driving a more sophisticated systems engineering process with more complex and capable features, along with new tools and procedures. One area of increased focus of the sys- tems engineering process is the informational systems architectural definitions used during system analysis. This process, described in DoD Architectural Framework (DoDAF), emphasizes greater reliance on reusable architectural views describing the system context and concept of operations, interoperability, information and data flows, and network service-oriented characteristics. 1.1.2 Case Study

The systems engineering process to be used in today’s complex system and system-of- systems is a process matured and founded on principles developed in the past. Examination of systems engineering principles used on programs, both past and present, can provide a wealth of lessons to be used in applying and understanding today’s process. It was this thinking that led to the construction of the AFIT CSE case studies.

The purpose of developing detailed case studies is to support the teaching of systems engineering principles. They facilitate learning by emphasizing to the student the long-term conse- quences of the systems engineering and programmatic decisions on program success. The systems engineering case studies assist in discussion of both successful and unsuccessful methodologies, processes, principles, tools and decision material to assess the outcome of alternatives at the program/system level. In addition, the importance of using skills from multiple professions and engineering disciplines, and collecting, assessing, and integrating varied functional data is empha- sized. When they are taken together, the student is provided real-world detailed examples of how the process attempts to balance cost, schedule, and performance.

The utilization and mis-utilization of systems engineering principles are highlighted, with special emphasis on the conditions that foster and impede good systems engineering practice. Case studies are used to illustrate both good and bad implementation of acquisition management and learning principles, such as:

• Every system provides a satisfactory balanced and effective product to a customer • Effective requirements analysis was applied • Consistent and rigorous applications of systems engineering management was applied

11

• Effective test planning was accomplished • There were effective major technical program reviews • Continuous risk assessments and management was implemented • Cost estimates and policies were reliable • Disciplined application of configuration management used • A rigorous system boundary was defined • Disciplined methodologies for complex systems used • Problem solving incorporated understanding of the system within the bigger

environment (customer’s customer)

The systems engineering process transforms an operational need into a system or several system-of-systems elements. Architectural elements of the system are allocated and translated into detailed design requirements by the systems engineering process. The systems engineering process, from the identification of the need to the development and utilization of the product, must continuously integrate and balance the requirements, cost, and schedule to provide an operationally effective system throughout its life cycle. Systems engineering case studies highlight the various interfaces and communications to achieve this balance, which include:

• The program manager/systems engineering interface is essential between the operational user and developer (acquirer) to translate the needs into performance requirements for the system and subsystems.

• The government/contractor interface is essential for the practice of systems engineering to translate and allocate the performance requirements into detailed requirements.

• The developer (acquirer)/user interface within the project is essential for the systems engineering practice of integration and balance.

The systems engineering process must manage risk, both known and unknown, as well as

both internal and external. Risk management will specifically capture and access risk factors and their impact, for example, uncontrollable influences such as actions of Congress, changes in fund- ing, new instructions/policies, changing stakeholders, changing user requirements, or changing contractor and government staffing levels. Case studies can clearly illustrate how risk manage- ment is executed during actual programs.

Lastly, the systems engineering process must respond to “Mega Trends” in the systems

engineering discipline itself, as the nature of systems engineering and related practices do vary with time. Case studies can suggest new systems engineering process ideas and, on the other hand, serve as reminders of the systems engineering essentials needed to ensure program success.

1.1.3 Framework for Analysis

The systems engineering case studies published by AFIT employ the Friedman-Sage framework and matrix as the baseline assessment tool to evaluate the conduct of the systems engineering process for the topic program. The framework and the derived matrix can play an important role in developing case studies in systems engineering and systems management, especially case studies that involve systems acquisition. The Friedman-Sage framework is a nine-row by three-column matrix shown in Table 1-1.

12

Table 1-1. A Framework of Key Systems Engineering Concepts and Responsibilities Concept Domain Responsibility Domain 1. Contractor

Responsibility 2. Shared

Responsibility 3. Government Responsibility

A. Requirements Definition and Management B. Systems Architecture and Conceptual Design C System and Subsystem Detailed Design and

Implementation

D. Systems Integration and Interface E. Validation and Verification F. Deployment and Post Deployment G. Life Cycle Support H. Risk Assessment and Management I. System and Program Management

Six of the nine concept domain areas in Table 1-1 represent phases in the systems engineering lifecycle:

A. Requirements Definition and Management B. Systems Architecture and Conceptual Design C. Detailed System and Subsystem Design and Implementation D. Systems Integration and Interface E. Validation and Verification F. Deployment and Post-Deployment

Three of the nine concept areas represent necessary process and systems management support: G. Life Cycle Support H. Risk Assessment and Management I. System and Program Management

While other concepts could have been identified, the Friedman-Sage framework suggests

these nine are the most relevant to systems engineering, in that they cover the essential life cycle processes in the systems engineering acquisition and the systems management support in the conduct of the process. Most other areas that are identified during the development of the matrix appear to be subsets of one of these. The three columns of this two-dimensional framework represent the responsibilities and perspectives of government and contractor, and the shared responsibilities between the government and the contractor. In teaching systems engineering in DoD, there has previously been little distinction between the duties and responsibilities of the government and industry activities. While the government has the responsibility in all nine concept domains, its primary objective is establishing mission requirements. 1.2 GPS Friedman-Sage Matrix The Friedman-Sage matrix is used herein retrospectively, as an assessment tool for the systems engineering process for the GPS program. The authors selection of learning principles is reflected in the Part 1 Executive Summary of this case.

13

2. SYSTEM DESCRIPTION

2.1 Mission

The Global Positioning System (GPS) is a satellite-based radio navigation system. It provides suitably equipped users the capability to precisely determine three-dimensional position and velocity and time information on a global basis (Ref. 12). The capability was developed to provide the United States and DoD with worldwide navigation, position, and timing capabilities to support military operations by enhancing ground, sea, and air warfighting efficiencies. How- ever, by presidential directive, it was officially made available to the civilian community in 1983.1 GPS also provides the capability to conduct time transfer for synchronization purposes through the use of precise time standards. GPS supports a secondary mission to provide a highly survivable military capability to detect, locate, and report nuclear detonations in the Earth’s atmosphere and in near-Earth space in real time. 2.2 Features

“GPS is a highly accurate, passive, all-weather 24-hour, worldwide navigational system (Ref. 23).” Each GPS satellite continuously transmits precise ranging signals at two L-band fre- quencies: L1 and L2, where L1 = 1575.42 MHz and L2 = 1227.6 MHz. Trilateration is the method of determining the relative positions of the user.

GPS provides Nuclear Detonation Detection System (NDS) capability. With NDS on- board the satellites, the system can detect nuclear detonation (NUDEC) on or above the surface. 2.3 System Design

GPS consists of three major segments: the Space Vehicle (SV), the User Equipment (UE), and the Control Station (CS). 2.3.1 Space Vehicle

The space vehicle segment consists of a system of 24 space-based satellites, of which three are spares (see Figure 2-1 for satellite constellation). The Block II satellites are configured in a constellation of six equally spaced orbital planes, inclined at 55 degrees and with four satellites in each plane. The spares are deployed in every other orbital plane. The satellite orbital radius is 26,561.7 km. Each satellite has a 12-hour orbit. Precise time is provided by a redundant system of rubidium and/or cesium atomic clocks on-board the SV.

Each satellite is capable of continuously transmitting L1 and L2 signals for navigation and timing, and L3 signal for nuclear detonation data (see Section 2.3.4 for further details). It is also capable of receiving commands and data from the master control station, and data from remote antennas via S-band transmissions.

1 GPS was always available to the civilian community. The GPS JPO worked to make the civilian community a part of GPS before the directive was issued. User charges were in effect for a very short period. President Reagan’s directive for free commercial use of GPS after the Korean aircraft was shot down culminated several ongoing efforts to eliminate the charge and make GPS free to the civilian community [25, Scheerer].

14

Figure 2-1. 24-Spaced-Based Satellite Constellation (Ref. 46)

The satellites transmit timing and navigational data on the two L-band frequencies, L1 and L2. Three pseudo-random noise (PRN) ranging codes are in use:

• The course/acquisition (C/A)-code has a 1.023 MHz chip rate, a period of 1 millisecond (ms), and is used primarily to acquire the P-code. Each satellite has a unique (C/A)- code. Literature also uses the term “clear/acquisition” for C/A. Both appear acceptable.

• The precision (P)-code has a 10.23 MHz chipping rate, a period of days, and is the principal navigation ranging military code.

• The (Y)-code is used in place of the (P)-code whenever the anti-spoofing (A-S) mode of operation is activated. Contrary to the (C/A)-code, each satellite has the same (P)- code, which is almost a year long, but each satellite is assigned a unique (P)-code that is reset every seven days. In this mode, the (P)- and (Y)-code functionality is often referred to the P(Y)-code. Modulated on the above codes is the 50 bps data stream. P- and P(Y)-code are for military use only.

The C/A-code is available on the L1 frequency only; however, future satellite constel-

lations will carry added signals, including a (C/A)-code on L2 and the P-code on both L1 and L2. The various satellites all transmit on the same frequencies, L1 and L2, but with individual (C/A)- code assignments. The (C/A)-code is available to all civilian users.

Due to the spread spectrum characteristic of the signals, the system provides a large mar-

gin of resistance to interference. Each satellite transmits a navigation message containing its orbital elements, clock behavior, system time, and status messages. In addition, an almanac is also provided, which gives the approximate data for each active satellite. This allows the user set to find all satellites once the first has been acquired.

There are four sets of satellite efforts discussed in this report: The Navigational Tech-

nology Satellites (NTS) launched in Phase I during concept validation phase (Figure 2.2), the Block I development satellites (Figure 2-3), the Block II/IIA production satellites (Figure 2.4), and the Block IIR (Figure 2-5). The Block IIF replacement satellites (Figure 2.6) photograph is provided for additional information.

15

Figure 2-2. Navigational Technology Satellite (Ref. 23)

Pr ov

id ed

b y

H ug

o Fr

ue ha

uf

Figure 2-3. Block I GPS Satellite

Pr ov

id ed

b y

H ug

o Fr

ue ha

uf

Figure 2-4. Block IIA GPS Satellite

16

Pr ov

id ed

b y

H ug

o Fr

ue ha

uf

Figure 2-5. Block IIR GPS Satellite

P ro

vi de

d by

H ug

o Fr

ue ha

uf

Figure 2-6. Block IIF GPS Satellite 2.3.2 User Equipment

In general, the user equipment (receiver) compares the time a signal was transmitted by a satellite with the time it was received. The time difference, along with the location of the satellites, allows the receiver to determine the user location. Signals from a minimum of four different satellites are required to determine a three-dimensional position. The user equipment (receiver) generally consists of an antenna assembly, receiver, data processor, control/display unit, power supply, and interface unit. There are numerous applications represented by user equip- ment, including those shown in Figures 2.7 and 2.8.

Figure 2-7. Rockwell Collins Precision Lightweight GPS Receiver (PLGR) (left) and Defense Advanced GPS Receiver (DAGR) (right) a later version of the PLGR (Ref. 48, 45)

17

Figure 2-8. Magellan Marine Receiver (Ref. 46)

2.3.3 Control Segment

The control segment commands, uploads system and control data to, monitors the health of, and tracks the space vehicle to validate ephemeris data. The control segment consists of a Master Control Station (MCS) located at Colorado Springs (Schriever AFB); five remote moni- tor stations which are located in Hawaii, Ascension Island, Diego Garcia, Kwajalein, and Colo- rado Springs; three ground antennas which are located at Ascension Island, Diego Garcia, and Kwajalein; and a Pre-Launch Compatibility Station, which can also function as a ground antenna, located at Cape Canaveral AFS. Figure 3-9 illustrates the elements of the control segment (CS).

The remote monitor stations track each GPS satellite in orbit, monitor the SV’s naviga- tional signals and health information, and simultaneously relay this information to the MCS. Each monitor station has the ability to track up to 11 satellites at once on L1 and L2 signals.

The ground antennas have the capability to upload time corrections and navigation data

to the satellites (one at a time per ground antenna) via S-band transmissions. The ground anten- nas also command the satellites and receive satellite telemetry data.

The ground equipment for receipt of precise time data from a satellite for the US Naval

Observatory (USNO) is located in the Washington DC area. There is a backup precise time moni- toring facility at Schriever AFB [31, Winkler]. USNO monitors the time transfer performance and provides data to the MCS on GPS time relative to USNO Coordinated Universal Time (UTC). The MCS is responsible for providing offset information to ensure that the GPS time can be maintained within a specified accuracy to UTC when the offset corrections are applied. Note that the SV atomic clocks require periodic updates, as the clocks are only relatively stable.

The ground equipment for receipt of the nuclear detection data via L3 was not the re-

sponsibility of the GPS Joint Program Office. The GPS control segment was responsible for maintaining the required environment for the Integrated Operational Nuclear Detonation (NUDET) Detection Systems (IONDS) and the Nuclear Detection System (NDS) sensor.

18

Figure 2-9. Control Segment (Ref. 42) 2.3.4 Nuclear Detection System (NDS)

A satellite detecting a NUDET processes the data and crosslinks it to other satellites via Ultra-High Frequency (UHF). All SVs with NUDET data transmit to the NDS User Segment via a specific L3 frequency. The satellites also transmit NUDET data over the Space-Ground Link Subsystem (SGLS) operating on S-band. Figure 2-10 depicts the NDS system segments.

Figure 2-10. NDS System Segments (Ref. 49) 2.3.5 “NAVSTAR/GPS”

Dr. Brad Parkinson (Col., ret.) relates the title Global Positioning System “…originated with Major General Hank Stelling, who was the Director of Space for the U.S. Air Force DCS Research and Development (RDS) in the early 1970s” (Ref. 6). The title NAVSTAR was suggested by Mr. John Walsh, an Associate Director of Defense Development, Research and Engineering (DDR&E) who made decisions with respect to the program budget. Within this report, the term “Global Positioning System” or “GPS” will commonly be used.

19

3. GPS PROGRAM EXECUTION

The GPS program traces it heritage from the early 1960s when Air Force Systems Com- mand initiated satellite-based navigation systems analysis, conducted by Aerospace Corporation. The case study follows the execution of the GPS program from the inception of the idea to the Full Operational Capability (FOC) release, 27 Apr 1995. The discussion will cover the transition from concept through development, production, and operational capability release. The concen- tration of the case study is not limited to any particular period, and the learning principles come from various times throughout the program’s schedule. Table 3-1 shows the events and milestones key to the development of the concept, produc- tion, and the eventual operational capability. This table will be the reference for keeping dates and events in the proper chronological context. The term “Block” applies to certain phases of the program. These will be discussed in greater detail later in the report. However, to provide insight into the table, the following explanation is provided: • Navigational Technology Satellites (NTS): Concept validation phase (also known as Phase I) • Block I Satellites, also known as Navigational Development Satellites (NDS): System Veri-

fication phase of GPS Block I in-orbit performance validation (also known as Phase II) • Block II/IIA Satellites: Production phase (also known as Phase III) • Block IIR Satellites: Replacement operational satellites

3.1 Early Programs

The GPS program evolved as a result of several navigation studies, technology demon- strations, and operational capabilities. Some of the key efforts that helped establish potential needs, and the technological feasibility to initiate the NAVSTAR/GPS, are briefly discussed to provide an appreciation of those efforts and how they affected the systematic approach used by the GPS Program.

Sea and air navigation needs during World War II resulted in two systems being devel-

oped: the United Kingdom GEE and the United States Long Range Navigation (LORAN) which was developed from the GEE technology. These were the first navigational systems to use multiple radio signals and measure the Doppler Effect (i.e., the difference in the arrival of signals), as a means of determining position. After the Russian Sputnik I launch in 1957, there were several efforts looking into space applications. Soon after the Sputnik I launch, Drs. Geier and Weiffenbach at John Hopkins University Applied Research Laboratory (ARL) conducted a study of the Sputnik space-generated signals. The study concluded that a complete set of orbit parameters for a near-earth satellite could be inferred to useful accuracy from a single set of Doppler shift data (single pass from horizon to horizon). Applying “the inverse problem” (knowing the orbit), the ground location could be predicted. ARL was aware of the Navy’s need to precisely determine the location of Polaris submarines as an initial condition for Polaris launch. After discussions with the Navy, ARL submitted a proposal to the Navy in 1958 for the TRANSIT Navigational System based upon the technical effort on orbit ephemeredes algorithms they devolved. Out of this effort, the Polaris program provided initial sponsorship.

20

Table 3-1. Major Events in Navigation and GPS Events/Milestones

Mar 1942 British GEE System became operational 1941 – 1943 Long Range Navigation (LORAN) developed and operationally implemented

1957 Demonstration of establishing satellite ephemeris through measurement of Doppler shift by Applied Research Laboratory (Ref. 8) 13 April 1960 First navigation satellite TRANSIT launched by the Navy

1963 Air Force Project 621B established 5 Dec 1963 First operational TRANSIT satellite launched 1964 TIMATION begins development under Roger Easton at the Naval Research Laboratory 1967 First TIMATION satellite launched by Navy 1967 TRANSIT fully operational

1968 Navigation Satellite Executive Group (NAVSEG) established among three services within DoD

31 Aug 1971 DoD Directive listed and confirmed US Naval Observatory for establishing, coordinating, and maintaining time and time interval

19 Jun 1972 Defense Navigation Satellite System Program (DNSSP) Management Directive signed (later evolved into GPS Program)

13 Dec 1973 Defense System Acquisition and Review Board (DSARC) approval to proceed with the GPS program 8 Aug 1974 Block I Satellite Contract Award to Rockwell International Sep 1974 Block I User Equipments and Ground Station Contract Award to General Dynamics

14 Jul 1974 Navigational Technology Satellite (NTS) I (a refurbished TIMATION II) satellite with first atomic clock (two Rubidium Clocks) launched June 1975 Contract Award to Texas Instruments for Manpack & Aircraft Receivers 22 Feb 1978 First Block I Navigation Development Satellite (NDS) is launched 5 Jun 1979 DSARC II approval to proceed into Full Scale Development (FSD) Fall 1979 Decision from the Pentagon to cut constellation from 24 to 18 due to DoD funding cutback

26 Apr 1980 First GPS satellite to carry the Integrated Operational Nuclear Detection System (IONDS) launched 16 Sept 1983 President Reagan directs GPS become available to civilian community at a no-charge basis May 1983 Block II satellite contract award to Rockwell International April 1985 First GPS user equipment production contract Oct 1985 Seventh and last Block I satellite launched 28 Jan 1986 Space Shuttle Challenger accident Jun 1986 DSARC IIIA approved to proceed into production 14 Feb 1989 First Block II production satellite launched 21 Jun 1989 Block IIR Satellite contract award to GE Astro Space division 26 Nov 1990 Selective Availability activated per Federal Radio Navigation Plan 26 Nov 1990 First Block IIA production satellite with Nuclear Detection Systems capability launched

8 Dec 1993 Secretary of Defense declares NAVSTAR GPS Initial Operation Capability (IOC) with a constellation of Block I/II/IIA satellites 27 Apr 1995 HQ Air Force Space Command declares GPS fully operational with Block II/IIA satellites 29 Mar 1996 Presidential Policy on GPS – discontinue Selective Availability within a decade 31 Dec 1996 Navy terminates TRANSIT operations 6 Nov 1997 Last block IIA satellite launched 23 July 1997 First successful Block IIR satellite launch 1 May 2000 Selective Availability function discontinued

21

The Advanced Research Projects Agency (ARPA) became the formal sponsor of the pro- gram later in 1958, supported by the Navy’s Strategic System Program Office. Dr. Richard Kirschner managed the APL program. The operational configuration was six satellites in polar orbit at approximately 600 nautical miles. Satellite ephemeris was broadcasted, and the provided navigational solution was two-dimensional. Additionally, the receiver had to know its own altitude and correct for platform velocity. Consequently, this system was not suited for aircraft applications. Navigational accuracy was approximately 100-meter Circular Error Probable (CEP). Even though the system was designed for a two- to three-year life, some of the systems attained up to 16 years of service. This system became available to the civilian community in 1967. “TRANSIT pioneered many areas of space technology, including stabilization systems, advancing time and frequency standards, multiple spacecraft launchings, and the first electronic memory computer in space” (Ref. 10). Near- and real-time orbit prediction, led by Messrs. Hill and Anderle of the Naval Surface Weapons Center (NSWC), was a key technology that TRANSIT matured that was valuable to the GPS [17, Parkinson].

Aerospace Corporation was conducting studies looking into military applications, most being space-based concepts. One of these studies, Project 57, encompassed the use of satellites for improving navigation for fast-moving vehicles in three dimensions. It was “in this study that the concept for GPS was born” (Ref. 8). The Air Force encouraged Aerospace Corp. to continue these studies stipulating that “…it had to be a true navigational system…unlimited number of users…providing global coverage…sufficiently accurate to meet military needs…” (Ref. 8). This project eventually became Air Force Project 621B established in 1963, which continued to evolve the concept. A key systems engineering report, in annotated briefing form, was constructed in 1963-1964 and is included in Appendix 5. This report summarizes the early GPS concept for the orbits and the signal structure. The trade studies conducted by Aerospace at the time showed a concept that provided a high-dynamic capability using two pseudorandom noise signals would allow use by high-performance aircraft, as well as all the other vehicles requiring navigation information. The signal could be detected by users at levels less than 1/100th of ambient noise. This was accomplished using the spread spectrum concept, which was in its infancy at the time. This technique rejected noise and, thereby, had some inherent anti-jam capability. The concept relied on continuous measurement from the ground for signal synchronization and included a system of “…four separate satellite constellations, each served by an independent ground-control station, at least two of which would have to be located outside of the United States, (and) was not acceptable from a survivability standpoint” (Ref. 24). Time was transmitted from the ground to the satellites. The project successfully demonstrated satellite ranging based upon pseudorandom noise signals. Testing was conducted at Holloman AFB/White Sands Missile Range (WSMR) in early 1972 using simulated transmitters on the desert floor and in balloons. Aircraft accuracy was demonstrated to be less than 5 m for position and less than 0.3 m/sec for velocity. During this time, signal definition studies were being conducted with Magnavox Research Lab and Philco-Ford Corp. Magnavox Hazeltine and Aerospace Corporation provided significant efforts that led to the jam-resistant passive ranging signal (CDMA Spread spectrum–Pseudo-random noise) [17, Parkinson].

22

Roger Easton, Navy Research Laboratory (NRL), “formulated a concept in April 1964 for transmitted ranging signals along with primary CW signal, such that the distance to the target satellite could be passively measured…” (Ref. 23). This concept led to the initiation of the Navy’s TIMATION program and “…under the direction of Roger Easton, (the project) concen- trated on developing an improved quartz frequency standard for satellites and determining the most effective satellite constellation for providing worldwide coverage” (Ref. 23). The concept proposed was to advance the development of high-stability clocks, time transfer capability and three-dimensional navigation, and to determine the most effective satellite configuration for global coverage. Side-tone range signals were transmitted from the satellite and space-borne clocks would be updated by a master clock on the ground. TIMATION utilized clocks on-board the satellite that were derived from stable crystal oscillators (Ref. 23). The baseline signal struc- ture would require different frequencies when multiple satellites were transmitting. The two TIMATION satellites launched under this program were at a 500 nautical mile polar orbit. These initial satellites validated the feasibility of time transfer from the satellite at several worldwide locations.

In order to minimize updates required to space-borne atomic clocks, NRL pursued a

change to the international time standard. “Since the satellite navigation was going to be an expected major and critical user of Precise Time, the NRL (Roger Easton)…urged USNO (Dr. Winkler) to work for a change in the timekeeping adjustment procedures. This was accomplished due in part to several other initiatives including Dr Winkler’s…with adoption of the new Coordinated Universal Time (UTC) system by the responsible coordinating international bodies, the CCIR (Comité Consultatif International des Radio Communications), the ITU (International Telecommunications Union), the IAU (International Astronomical Union), and the CIPM (International Conference for Weights and Measures)… effective 1970. The new UTC system with very infrequent leap seconds and a fixed frequency avoided (important particularly for space applications) the small frequency adjustments used then to keep the Atomic clock time (UTC) in close agreement (<0.9s) with earth time (UT1)” (Ref. 34).

Deputy Secretary Packard2issued DoD Directive 5160.51 on 31 August 1971, re-

emphasizing the designation of the USNO as the responsible agency for ensuring “uniformity in precise time and time interval operations including measurements…” and “…for establishment of overall DoD requirements for time and time interval” (Ref. 24).

The Army was also interested in satellite navigation systems. “The U.S. Army developed

the SECOR (Sequential Collation of Range) system and the first SECOR transponder was orbited on ANNA-1B in 1962. The SECOR system continued in use through 1970. The system operated on the principle that an electromagnetic wave propagated through space undergoes a phase shift proportional to the distance traveled. A ground station transmitted a phase-modulated signal, which was received by the satellite-borne transponder and returned to the ground. The phase shift experienced by the signal during the round trip from ground to satellite and back to ground was measured electronically at the ground station, which provided as its output a digitized representation of range” (Ref. 25). Thirteen satellites were launched between 1964 and 1969. 2 Honorable David Packard was Deputy Secretary of Defense from 1969 to 1971.

23

In 1968, the Joint Chief of Staff (JCS) directed an effort to develop concepts of a three- dimensional, global, continuous navigational system. This effort resulted in the establishment of the Navigation Satellite Executive Steering Group (NAVSEG) [1, Beard]. It was “…chartered to determine the feasibility and the practicality of a space-based navigation system for improving military navigation and positioning” (Ref. 26). NAVSEG contracted a number of studies to fine tune the basic navigation concepts. These included choice of frequency (L-band vs. C-band), design of signal structure, atomic clock development, and selection of satellite concept configuration. They also managed concept debates in which ARL pushed for expanded TRANSIT, NRL for expanded TIMATION, and the Air Force pushed for synchronous orbits with pseudorandom noise signals (Ref. 27). The Naval Weapons Lab-Dahlgren (now the Naval Surface Weapons Center-Dahlgren) conducted significant studies in tracking and orbit predictions. All the major navigational studies sponsored by the NAVSEG from 1968 through 1972 were classified. The original concept plan, which was later modified with the establishment of a joint program office, was to have a demonstration of each proposed navigational concept being developed by the services to evaluate their capabilities. [1, Beard].

No defined operational need among the services drove the development of a space-based

navigation system to improve air, land, or sea navigation and position accuracy, other than the Navy’s requirement. Recall this requirement was for precise location of their nuclear submarines used for missile launch that was being fulfilled by the TRANSIT system. The TRANSIT, originally intended for submarines, was beginning to be used by commercial marine navigators. Each service was individually exploring technology efforts for navigational improvements with space-based satellite concepts.

In May 1972, the Secretary of the Air Force endorsed a draft Concept Development Paper

to the Director, Defense Research and Engineering (DDR&E). The paper described an “opera- tional feasibility demonstration program using a constellation of repeater satellites” (Ref. 12). Decisions had previously been made that a joint test program would be conducted using a pseudo-random noise generator developed under Air Force funding onboard the TIMATION III satellite to be launched in late 1973, actually launched in 1974 as Navigation Technology Satel- lite (NTS) I.

A Program Management Directive (PMD) for a Satellite System for Precise Navigation

was issued by HQ USAF Deputy Director of Space, DCS/Research and Development on 19 July 1972. The purpose of the PMD was for Air Force Systems Command (AFSC) “…to define and configure a satellite-based positioning system…(to) provide suitably equipped users the capability to determine three dimensional position and velocity, and time information on a global basis” (Ref. 12). The PMD also directed an initial demonstration of the operational feasibility of a global posi- tioning system with the intent to verify the system technical concepts such as accuracy, availability, signal structure, and satellite tracking. A six-year (FY73-78), $148M projected program was identi- fied in the PMD. Magnavox Research Laboratories and Philco-Ford Corporation were already conducting studies on signal structure candidates and TRW was investigating user equipment receiver configurations, requirements, and costs based upon previous HQ USAF direction.

24

3.2 Establishment of a Joint Program

Deputy Secretary of Defense Packard was concerned about the proliferation of programs being individually pursued by the services within DoD. He advocated joint efforts where similar or parallel efforts were being addressed among the services. He took action to combine service activities with a lead service being designated to reduce development, production, and logistics costs. There was a proliferation of navigation systems by the individual services and the individual weapons systems with unique navigation systems. The practically independent effort of the three services to develop and enhance spaced-based navigation systems became an excellent candidate for a joint program. DoD directed that the spaced-based navigation efforts by the three services would become a joint program. The Air Force was directed to be the lead with multi- service participation. The Joint Program Office (JPO) was to be located at the Space and Missile System Organization (SAMSO) at Los Angeles Air Station.3

Col. Brad Parkinson was designated the program director. The JPO was manned with a

Deputy Program Managers from the Air Force, the Army, the Navy, Defense Mapping Agency, the Marine Corps, and the Coast Guard. Col. Parkinson added a strong base of technical experts in the appropriate functions for space, navigation systems, Kalman Filters, signal structure, signal generation, electronics, and testing. Aerospace Corporation continued to provide valuable technical and systems engineering analysis to the JPO as it had during Project 621B. Eventually, there would be representatives from Strategic Air Command (SAC), NATO, and other international organizations in the JPO.

Soon after the establishment of the JPO, the first major task was to obtain approval for the

program. The JPO structured a program that closely resembled the Air Force 621B system. This program was presented to the Defense System Acquisition and Review Council (DSARC) in late August 1973 to gain approval to proceed into the concept/validation phase. “Dr. Malcolm Currie, then head of DDR&E4, expressed strong support for the idea of a new satellite-based navigation system, but requested that the concept be broadened to embrace the views and requirements of all services” (Ref. 12). DoD viewed the viability of the program based upon two overriding issues:

1. Should a universal, precise positioning and navigation system be initiated? This question reduces down to two sub-questions: Will a universal system permit a significant reduction in the total DoD cost for positioning and navigation? Will military effectiveness be significantly increased by a universal system?

2. What is the best program orientation and pace for achieving the desired capability? A universal navigation system could replace a significant portion of the current and planned

navigation and positioning equipment such as LORAN, TRANSIT, VOR, OMEGA, DOPPLER, RADAR, range instrumentation, geodetic equipment, LRPDS, and ILS Approval. The Office of Secretary of Defense (OSD) estimated that cumulative expenditure of funds from 1973 to the mid-1980s for operations and maintenance of these facilities ranged from $7.5 B to $12.5 B. However, approval for the program to proceed was not obtained and the near-term task ahead was clearly defined to develop a joint technical program.

3 This decision was most likely based upon the Air Force having been identified by DoD in the past as the lead service in operational space systems. 4 Dr. Malcolm Currie was Director DDR&E from 1973 to 1977.

25

Col. Parkinson assembled approximately 12 JPO members at the Pentagon over the 1973 Labor Day weekend and tasked the team to develop a program that would utilize the best of all services’ concepts and technologies. The technology up to that time frame had advanced: 1) space system reliability through the TRANSIT program; 2) the stability of atomic clocks and quartz crystal oscillator through NRL efforts and the TIMATION program; 3) the precise ephemeris tracking and algorithms prediction from APL/NRL/TIMATION, Project 621B, and the Navy Surface Weapons Center; 4) the spread spectrum signal structure primarily from Project 621B; and 5) the large-scale integrated circuits in a general industry-wide effort. Reliability of satellites and large-scale integrated circuits had been proven. The resultant pro- gram was a synthesis of the best from each service’s programs. This culminated in formulating an integrated program that assessed the viability of mixing these new and emerging technologies. As Dr. Parkinson said, “Rarely, however, have so many seemingly unrelated technical advances occurred almost simultaneously that would permit a complex system like GPS to become a reality” (Ref. 22)? The revised program went through a series of briefings to key decision makers prior to reconvening the DSARC I. The DSARC I was held on 13 Dec 1973 and approval was granted to proceed with the program into a concept development phase. The funding line of $148M for the new program was established, allowing NRL to continue with the TIMATION work, especially to develop and mature the atomic clock. The 621B funding line disappeared. It is interesting to note the relative accuracy with which the Aerospace Corporation study assessed cost for similar types of technology implementation. Chart No. 75 in Appendix 5 shows a $111M prediction in FY64 dollars for the early concept, compared with $148M in 1973 for the integrated service approach.

At this time, there was neither operating command support nor any operational mission

need nor Concept of Operations, and no advocacy for this effort. Additionally, there was some negative feedback from operational commands that preferred funding to be spent on weapon systems [17, Parkinson; 11, Green]. DoD began taking on the role of customer/user. They were also becoming the advocates for the program – especially the Director of DDR&E, Dr. Malcolm Currie – and were shaping the approach to the effort, including approval and control of performance requirements, and ensuring that the services were providing support in terms of funding [5, Currie].

The expected performance of the GPS was delineated in the approved Concept Devel-

opment Plan signed by the Deputy Secretary of Defense, 11 May 1974, as shown in Table 3-2.

Table 3-2. Expected GPS Performance (Ref. 13) Characteristic Performance

Accuracy (relative and repeatable) 5-20m (1 sigma) Accuracy (predictable) 15-30m (1 sigma)

Dimensions 3-D + time, 3-D velocity Time to acquire a fix Real Time (for stated accuracies)

Fix Availability Continuous Coverage Global

In addition to this performance, the system was to have the following additional charac-

teristics (Ref. 13):

26

1. Passive operations for all users 2. Be deniable to enemy 3. No saturation limit 4. Resistance to countermeasures, nuclear radiation and natural phenomenon 5. Common coordinate reference 6. Available for common use by all services and allies 7. Accuracy not degraded by changes in user altitudes

The program consisted of a three-phase approach: Phase I – Concept/Validation Phase II – Full-Scale Engineering Development Phase III – Production

The program estimated a limited Initial Operational Capability (IOC) could be obtained

in 1981 and a Full Operational Capability (FOC) in 1984. The program was baselined against those scheduled events.

The completion of each phase would require DSARC approval before proceeding into the

next phase, which was typical of all major DoD programs. The overall program planned initial schedule is in shown Figure 3-1. The basic tenet of this schedule, the three-phase approach, re- mained constant through the program. The specifics would change due to funding issues, tech- nical issues, and other extraneous events that would impact the program. These specific issues will be addressed throughout this report.

Figure 3-1. Program Schedule (Ref. 13)5

5 The “2×2”, “3×3”, and “3×8” are the planned constellation configurations where the first number is the number of planes and the second number is the number of SVs per plane. Only two of the three NTS SVs would be launched in the first phase of the program.

27

The unique needs of the program efforts and the systems engineering process varied

during the three phases. In all phases, the JPO provided the leadership and focus of the effort and maintained the overall control and management of the systems requirements. The contractor teams and government team worked in close collaboration and mutual support to achieve the initial vision of “five bombs in the same hole” at a reasonable cost. 3.3 Concept/Validation Phase (Phase I)

3.3.1 Objectives

The objectives of the concept/validation phase were to prove the validity of integrating the selected technologies, define system-level requirements and architecture, initiate user equip- ment development, and demonstrate operational utility. The tenets of the systems engineering process would play a key role meeting the specific two objectives.

The first objective was to determine preferred UE designs and validate life cycle cost models in the design-to-cost process. Six classes of UE were to be considered (Table 3.3). The guidance on the UE design was to incorporate a high degree of commonality among the classes through the use of modular designs. Sufficient quantities of UE models were to be procured to support a comprehensive Developmental Test and Evaluation (DT&E) (Ref. 13).

Table 3-3. Proposed Classes of User Equipment (Ref. 13)

A B C D E F High Accuracy** High dynamics of user High immunity to jamming

Medium accuracy* High dynamic of user Medium immunity to jamming

Medium Accuracy Medium dynamics of user Immunity to unintentional EMI Low Cost

High Accuracy Low dynamics of user High immunity to jamming

High Accuracy Low dynamics of user High immunity to jamming

Medium accuracy Low dynamics of user Medium immunity to jamming

CANDIDATE MISSIONS AIR FORCE Strategic aircraft Photo Reconnaissance

ARMY Helicopter USMC Close air support Helicopter NAVY Close air support Attack aircraft AIR FORCE Interdiction Close air support

ARMY Mission support NAVY Mission support Surface vehicles ASW aircraft AIR FORCE Airlift Search & Rescue Mission support

ARMY Wheeled and track vehicle NAVY Mine warfare

ARMY Man backpack USMC Man backpack

NAVY Submarine

Note: The above classes of User Equipment and Candidate missions will be refined during Phase I ** High accuracy better than 50 ft * Medium accuracy 50-500 ft + Acceptable accuracy as determined by cost tradeoffs

28

The second objective was to conduct limited demonstrations of operational utility. These demonstrations were to focus on coordinated bombing, terminal navigation, landing approaches, airborne refueling, Army land operations, special operational techniques for anti- jamming margins, and system vulnerability. This objective would also investigate satellite hardening, long-term stability of rubidium frequency standards, and provide navigation signals compatible between technology and development satellites. Experiments would continue to space qualify advanced frequency standards. Lastly, a prototype ground station would be developed and tested.

3.3.2 Requirements

Some basic requirements were identified in the Concept Development Paper (Ref 13). There was no Concept of Operations (CONOPS) or defined military need for this space-based navigation system. Col. Parkinson believed that the JPO would be responsible for developing initial CONOPS and military utilization through the technology and operational demonstration and development effort. He established a vision of two “key performance requirements” for this phase. The first was the capability to demonstrate “drop five bombs in the same hole.” This “key parameter” embodied the integration of receivers on platforms and the capability to transmit precise space-based navigation and timing data. A demonstration would provide hard data to gain support for the military utility of the system. Accordingly, he needed to have the appropriate operational people observe the demonstration and review the data in order to gain their acknowledgement of the improved capability [17, Parkinson].

The second “key parameter” in his vision was the ability to build a receiver for less than

$10,000. This complemented the first key parameter in demonstrating the affordability of this navigational improvement.

The Government foresaw the need to have the civilian community participate in the pro-

gram. The civilian community had resources to insert new technology and drive down the costs in their competitive environment to the benefit of DoD and the JPO [25, Scheerer]. At this time, no one foresaw how far the civilian community usage of the “in-the-clear” GPS capability would drive down the military cost of the user equipment – down to the $1000-$1500 range for some units. Some commercial GPS receivers can now be purchased for less than $100 [8, Fruehauf]. One additional benefit of civilian community involvement was the political support provided to keep the program going [25, Scheerer].

In the early phases of GPS, the program is better viewed as a monolithic system with the

JPO controlling all parts: space, ground, and user. As the program progresses, control dissipates. Commercial providers of the user equipment interject a strong influence. This diffusion of control becomes more evident as the Federal Aviation Administration (FAA), Coast Guard, and eventually the Galileo European Global Navigation System started providing independent signaling elements. The JPO’s ability and means to effectively conduct systems engineering dramatically changed as their control diffused. As is typical in a SoS environment, the JPO’s role becomes more as an integrator/collaborator than a developer.

An important feature of systems engineering was the JPO view of top-level requirements. Requirements were “negotiable”, i.e. tradable, which was a significant benefit that allowed the

29

evolution and development of the program as knowledge and technology advanced with time. The philosophy was to understand the risk to change versus the risk to stay on the same course. The corollary to this premise was to maximize the number of negotiable requirements. Finally, it was important to communicate requirements to customers (operational users and DoD). This program’s systems engineering philosophy would allow appropriate trades to be conducted to optimize the military utility/operational concept, cost, schedule, risk, and performance/design, as well as gain necessary support of the user.

The Phase I System Specification defined the system error budget, the system-level

functional flow diagram and interfaces, constellation support in terms of control segment, upload station performance characteristics, the classes of user equipment, the signal structure to be used, and the required software standard. Since the GPS was “a system of systems”6 not connected by hardware, other system-level physical characteristic requirements – such as reliability and maintainability, design and construction, human factors, logistics, as well as personnel and training, were deferred to the system segment specifications. There was no system verification section. For this phase, a fourth segment or element of the system was defined as the navigation technology segment to address the NTS, the NRL telemetry, tracking and control segment, and the PRN navigation assembly. Figure 3-2 defines the Phase I system interfaces.

Figure 3-2. System Interfaces (Ref. 28)

The development of the SV performance requirements was a rigorous joint development

effort with the JPO and the bidders prior to the Request for Proposal (RFP) being released. “The Air Force…clearly spelled out the requirements for the satellite. The requirements did not change during the Phase I program which allowed the team to build and test hardware and not constantly change it,” said Dick Schwartz, Rockwell Block I Program Manager. Rockwell took the detailed

6 There are various definitions of “System of Systems”. In this report, the authors determined that the GPS was a Sys- tem of Systems for the following reason: There were three major system segments (SV, CS, UE) that were developed by separate contracts and physically independent with only the interface of signals as the “string” that tied them to- gether. Each segment was considered a system composed of various subsystems that were being developed to meet the segment system performance. Each of the three “Systems’ combined to provide a system navigational capability.

30

requirements for each SV subsystem and wrote detailed subcontractor specifications for fixed- price subcontractor bids. The JPO added no additional requirements to this phase of the program. From contract award to launch in 3½ years, there were only two small configuration changes to the satellite. The main focus was on building the configuration that was developed in the year before the contract award [26, Schwartz].

3.3.3 Acquisition Strategy

The JPO was organizationally set up with three major branches/groups with respect to the segments of the system: space vehicle (SV), control segment (CS), and user equipment (UE). The systems engineering group owned the system-level configuration and interface control processes. Col. Parkinson determined that the JPO would be responsible for system integration to the initial concern of Aerospace Corporation and contractors. Managing the interfaces and retaining control of the system specification was an essential and critically important strategy for Col. Parkinson and the JPO. He believed that, “Unless I was at the center of the systems engineering involved here, I didn't think I could pull it off either, because the contractors quickly close you out of the essential decisions here. Making the trades would be left to them on what- ever motivation they had” (Ref. 21). He had difficulty convincing his own management, Gen. Schultz at Space and Missile Systems Office (SAMSO), which eventually became Space Division. Finally, he convinced him that the system was defined by signal structure in space and not by physical interfaces [17, Parkinson].

The acquisition strategy was to issue separate contracts for each segment. The Develop-

ment Concept Paper scoped the approach to contracting: “Since the vast majority of the technol- ogy for GPS is well in hand, fixed price multiple incentive contracts will be used where possible” (Ref. 13). However, the initial UE development would be cost-plus-incentive fee contracts due to the risk in the development of a low-cost, lightweight receiver.

The basic costing tenet from the services was that the Army and Navy funded unique UE and service-peculiar testing, the Navy funded NTS and testing, and the Air Force funded NDS, testing, and Air Force UE. The Air Force funded the CS and SV segments efforts.

There were six principal contractors for this phase which are shown in Table 3-4:

Table 3-4. Phase I Major Contractors (Ref. 4)

Contractor Responsibility Rockwell International (RI) Development satellites General Dynamics Control segment and direction to Magnavox Magnavox User Equipment Texas Instrument (TI) User Equipment (alternate source) Stanford Telecommunications Inc. Signal Structure

Rockwell Collins (actually under contract to Air Force Avionics Laboratory)

User Equipment (General Development Model (GDM) sponsored by the Air Force Avionics Lab. GDM also used to evaluate anti-jam system techniques)

Rockwell International, Seal Beach CA, was awarded a fixed-price incentive fee with an

Award Fee contract in Jun 1974 for four Block I satellites, one of which was the refurbished quali-

31

fication model. The contract (F04701-C-74-0527) was modified and additional satellites were purchased for a total of eight satellites (see paragraph 3.3.7 for additional insight as to the need for the additional satellites). In 1979, four replenishment satellites would be purchased under a separate contract (F04701-C-79-0153). The last Block I satellite (SV) was converted to a Block II qualification test vehicle under an engineering change proposal [21, Reaser].

In September 1974, the JPO awarded General Dynamics a contract to supply UE

receivers and develop the prototype ground control system. Additionally, this cost-plus-incentive fee (CPIF) contract was to supply 40 models of seven different classes of receivers: bombers, helicopters/fighters, transport aircraft, tanks/ships, manpack, submarines, and missiles. Magnavox was the major subcontractor for the user equipment. Litton Industries Mellonics, and Litton G&C Systems Division were major subcontractors providing supporting software for the ground control segment and instrument test equipment. Texas Instruments was awarded a fixed- price contract for development of a manpack receiver, computer equipment, and a pair of high- performance aircraft receivers. Rockwell Collins was on contract to the Air Force Avionics Laboratory to evaluate space-based navigational signals and the concept of high anti-jam receivers via a General Development Model (GDM), shown in Figure 3-3.

Figure 3-3. Rockwell Collins GDM (Ref. 47)

The DoD, realizing the strong potential for commercial application and foreseeing the

benefits of more competition, announced that those who developed receivers with their own funds could have their system evaluated and certified by the JPO.

The contractors accomplished some unique systems engineering approaches. “As a contractor (Rockwell International) we took those requirements and during the pre-proposal and proposal phase…built hardware to demonstrate the critical spacecraft technologies. We were able to include test data on real hardware in the proposal.” Rockwell built and tested hardware, such as atomic clocks, navigation band high-power amplifiers, and antennas during the proposal phase. “We had a complete design for the satellite backed up by test data that was submitted as part of the proposal” [26, Schwartz].

The SV contract type was a fixed-price incentive with a 125% ceiling and an 80%/ 20%

share between the target and ceiling. The contract also included a $100K threshold change clause (no changes under $100K) with a manpower provision for studies [11, Green]. The 125%

32

ceiling provided a margin for problem resolution and the share line provided the motivation to minimize cost. The Award Fee program evaluated management performance. “My view was that the AF had excellent people and suggestions because they viewed the program from an overall perspective, and the comments were constructive” [26, Schwartz].

There were also on-orbit incentives in the SV contract. These were daily incentives for

satellite performance in orbit where the navigation signal was measured at the CS Signal struc- ture, and strength was measured from when the satellite rose 5 degrees above the horizon until it set 5 degrees above the horizon [26, Schwartz].

Rockwell established a dedicated project organization with personnel co-located next to

the spacecraft assembly and test area. These technical personnel were handpicked by the GPS program manager. An engineer managed each subsystem and was responsible for the subsystem design, the interface with other systems, management of subcontractors, overseeing the fabrication of parts, development of test procedures, and the conduct of testing [26, Schwartz].

Aerospace Corporation provided technical experience from all of the Air Force satellite

programs. Irv Rezpnick, the Senior Aerospace manager, provided support developing the SV test programs, subcontractor reviews, and high reliability parts program [26, Schwartz].

3.3.4 Trade Studies

General Dynamics conducted a major set of trade early in Phase I (July 1974), to provide recommendations on several key program decisions required in this phase (Ref. 19). These trade studies are depicted in Table 3-5.

The trade studies below considered the impact on the next phases of the program. With

respect to the orbit portion of the study, the program baseline of 4-satellite constellations was assessed. Paragraph 3.3.7 below discusses the need for spare satellites, which drove a change to the configuration. These studies provided preliminary allocated baselines to the control segment and the UE during this initial phase of the program. As concept validation testing continued and the designs matured, final baseline allocation would be established as the program moved into the next phase. The CS consisted of three main configuration items: the master control station, the monitoring station, and the upload station.

Table 3-5. General Dynamics Phase I Trade Studies (Ref. 19) Trade Study Selection

Satellite Memory Loading Resolve the method for uploading user-required data and verifying accuracy after SV has received it. S-band uplink and L-band downlink, verified at SV Satellite Orbit Resulted in a 2/2/0 configuration

Monitor Station Sites Selection: Hawaii, VAFB, Elmendorf AFB & TBD; VAFB to be MCS and Upload Station Control Segment Computers Evaluation criteria established User Segment Computer Interim findings only…did not consider on Phases II/III User Cost/Performance Low fidelity study, some cost/performance data; no selection

User Ionosphere Model Identified important features: user storage, satellite transmission & technique accuracy User Ephemeris Model Kepler functional model, functional ephemeris Ephemeris Determination

33

In conjunction with Aerospace Corporation, the JPO conducted various analyses and trade studies on operational constellation concepts that resulted in a baseline configuration of eight satellites, each in three circular rings with 63-degree inclinations. Major considerations were the global coverage, satellite replacement issues, and the location of the remote sites. Figure 3-4 was the early planned constellation approach of constellation arrangement as the number of satellites in orbit increased. The consensus was that a trade study should be conducted to determine a higher SV orbit, as it would reduce the number of satellites required. However, the Atlas rocket with stage vehicle that was developed could only support the 1000 lb SV to the 12-hour orbit. It turned out that this orbit configuration was adequate to support the testing at Yuma Proving Grounds (YPG) with a limited constellation [11, Green]. As the program progressed, external events would require the JPO and Aerospace Corporation to conduct a trade analysis of the constellation configuration and modify the functional baseline.

Figure 3-4. Planned Constellation Development before 1974. Proof of Concept has 6 Block I satellites in 2 planes. Build up to 24 Block II satellites in 3 planes (Ref. 18)

The PRN signal structure is the key enabling technology of GPS, resulting from extensive sys- tems engineering analysis and trade studies dating back to the early Aerospace studies sponsored by AFSC/SMC (Appendix 5). The whole structure of the system revolved around the ability to communicate accurate navigation and timing data to each of the segments. Extensive signal and communications message development trade studies that bridged from Project 621B to this phase were conducted. The Project 621B study system employed signal modulation and used a repeated digital sequence of random bits. The sequences of bits were simple to generate by using a shift register, or by simply storing the entire bit sequence if the code was sufficiently short. The sensing equipment detected the start phase of the repeater sequence and used this information to determine the range to a satellite. The concept of PRN ranging was led by Aerospace Corpo- ration and Magnavox. Dr. Charles Cahn was a signal analyst who, with Dr. Robert Gold, was involved in the development of the signal architecture [28, Stansell]. The first receivers developed for PRN ranging were Magnavox Hazeltine. The signal structure was defined by Drs.

34

Nataly and Spilker. Maj. Mel Birnbaum and Dr. Van Dierendonk [17, Parkinson] led design of the message structure and the systems engineering process. 3.3.5 Risk Mitigation

One of the key risks going into this phase was the ability to validate that the Atomic Fre- quency Standards (AFSs), or clocks, performed in a space environment and provided precise timing to the user equipment. The GPS concept was based upon a reliable, ultra-stable AFS. The atomic clocks were one of the key technologies instrumental in making GPS a viable system. This technology was developed as an offshoot of research on magnetic resonance to measure natural frequencies of atoms that began in 1938 with Dr. Rabi at Columbia University. The development of atomic clock technology over the years resulted in more-accurate and smaller-packaged atomic clocks.

The atomic clocks in the GPS satellites were essential in providing GPS users accurate

position, velocity, and time determinations. They provided a precise standard time – the fourth parameter. In addition to the three-dimensional coordinates of the SV, this allowed the user to receive sets of four parameters from four satellites and solve the equations establishing a four- dimensional location of the receiver (three spatial dimensions plus time). The clocks became one of the key development items for the program.

As the GPS program was being established, plans were already in place to conduct test-

ing using the Navy TIMATION satellites with atomic clocks onboard and incorporating Project 621B code generators. The objectives of the NTS concept development tests were to validate the behavior of accurate space-based clocks, the techniques for high-resolution satellite orbit predic- tion, the dissemination of precise time data worldwide, and the signal propagation characteristics. NRL led the contracting and supply of the NTS atomic clocks. Two commercial rubidium Rb clocks purchased from Efratom Munich and a quartz crystal oscillator were flown on NTS-1. The Rb clocks were modified by NRL for flight experiments to reduce expected thermal problems in space. The NTS-1 had attitude determination problems that caused wide temperature swings, which caused frequency swings in the clock and failure after about one year. Necessary performance validation data were obtained before the failures. The Rb clocks were not space- qualified.

Rockwell developed a PRN code generator and space-borne GPS computer that were

incorporated into NTS-2. Two more-robust, space-qualified Cesium atomic clocks built by Frequency and Time System (FTS – now Symmetricom) were launched on NTS-2 [30, White].

The NTS effort was managed through a fourth segment of the GP system – the navigation-

technology segment – and focused on validating various technology concepts, especially the space-borne atomic clocks. “The navigation-technology segment of the GPS provided initial space-qualification tests of rubidium and cesium clocks. This segment also provided the original test of the GPS signals from space, certification of the relativity theory, measurement of radiation effects, longevity effects on solar cells, and initial orbital calculations…Precise time synchroni- zation of remote worldwide ground clocks was obtained using both NTS-1 and NTS-2 satellites. (During) May through September 1978 with a six-nation cooperative experiment,… (tests were) performed to inter-compare time standards of major laboratories” (Ref. 1). The NTS SVs per-

35

formed adequately for the prototype objectives intended and provided sufficient data to proceed with the further development of improved atomic clocks. NTS command and telemetry links for these tests came from many of the Navy ground systems during the TIMATION program. NTS/TIMATION SV tracking and control was accomplished at NRL’s Blossom Point, MD satellite control facility. NRL operated several NTS/TIMATION monitor sites to collect and characterize the navigational signal. Elements and functions of the NTS-2 system, including ground stations, are shown in Figure 3-5. An NTS SV is shown in Figure 3-6.

Figure 3-5. NTS-2 Command and Telemetry Links (Ref. 1)

Figure 3-6. NTS-2 Satellite (Ref. 23)

36

The other key risk addressed in this phase was the ability to validate the prototype receivers being developed could precisely predict location using the navigational and time signals being generated. The primary objective of this phase was to establish performance limits of the UE under dynamic conditions in a severe environment. As Col. Parkinson stated, it was “…a classical bureaucratic ‘Catch 22’: How could user equipment development be approved when it wasn’t clear it would work with the satellites? How could the satellites be launched without ensuring they would work with the user equipment?” (Ref. 18). Relying on experience from the Project 621WSMR test program, the JPO devised a plan to use an array of four surveyed ground-based transmitters (called pseudolites, derived from pseudo-satellites), which would generate and transmit the satellite signal. The test program would be conducted with the prototype and initial developmental UE to validate the signal compatibility with the receivers. Azimuth and angular errors were a challenge that had to be considered in the test planning and execution. The fidelity of the ground-based system would be enhanced as the Block I satellites began to be launched. Pseudolites were used in conjunction with launched satellites until a minimum of four satellites were available in orbit. The (YPG) was selected as the test site in lieu of WSMR as a result of a trade study. This approach had the benefit of enhancing the Army involvement as a stakeholder in the program. Magnavox Advanced Product Division was re- sponsible for the development and fabrication of the pseudolites and a control station at the test site.

During the initial phases of testing, problems were encountered when the receiver display would indicate an “anti-jam” threat due to the power levels being transmitted by the pseudolites. A design and procedure change eliminated the deficiency [11, Green]. This test program was the first to use a triple-triangulated laser to conduct precise measurements of aircraft location to verify user location (aircraft) [16, Parkinson]. “The laser tracking system provided an accuracy of about one meter. To simulate the much longer real distance between user equipment and the SV, an extra code offset was used” (Ref. 16). Testing was conducted at YPG from March 1977 to May 1979. Demonstrations began with user equipment installed on a C-141 cargo transport, F- 4J fighter, HH-1 helicopter, and Navy P-3 aircraft. Testing proceeded with manpack and other user host vehicles. Some of the YPG test results with respect to the blind bombing tests with the F-4J and X-set receivers, F-4J and C-141 rendezvous test and the manpack tests are shown in Figure 3-7. As the testing progressed and three satellites were in orbit, on-board ship user equipment was tested off the California coast. Eventually during this phase, over 775 mission tests were conducted with various classes of test vehicles.

37

Figure 3-7. Phase 1 YPG Test Results (Ref. 51) Air Force Test and Evaluation Command (AFTEC, later to become AFOTEC) conducted

an independent evaluation and found no significant operational issues with the operational demon- stration tests [17, Parkinson]. 3.3.6 System Integration

The JPO decided to retain core systems engineering/system integration responsibility. Col. Parkinson had a concern with the potential for proliferation of systems engineering groups within an organization. He viewed systems engineering as a common-sense approach to creating an atmosphere to synthesize solutions based upon a requirements process, and to ensure good validation/verification of the design to meet those requirements7. He advocated using good systems engineering principles to work issues as they arose [17, Parkinson].

The “major cornerstone of the program” from a program execution and system integra-

tion perspective were the interface controls. It was vital not only to this phase, but to the entire program, that a strong systems engineering process be established. This ensured that technical inputs and requirements, verification, conditions, and CONOPS of all the government, contractor agencies, and international communities were considered in a timely manner, and a means of communication among those agencies was established.

7 Col. Parkinson did not mention though implied within reasonable cost and schedule.

38

The integration role required contact with many government and industry entities. A plethora of technical expertise organizations, test organizations, users, etc. required working interfaces and integration. Figure 3-8 provides a view of the program interfaces required with other agencies/contractors and indicates the complexity of the interfaces required.

Figure 3-8. GPS JPO Agency/Contractor Interfaces

In this phase, a significant amount of fluidity among the design concept and agencies involved further underscored the need for unimpeded communications. The program set up an acquisition strategy that created separate contractual efforts for the three major segments: Space Vehicle (SV), Control Segment (CS), and User Equipment (UE). A unique fall-out of this delineation was no physical connection between the segments. All the segment interfaces within the system were related to the transmitted signals. The system specification and the Type I Interface Control Documents (ICDs) were written and controlled by the JPO. The system specification was not contractually binding on any of the segment contracts. The segment specifications and their companion ICDs written by the contractors were assessed by the JPO System Group for compliance with the system specification. These specifications and the ICD were generally written in cooperation with the JPO. Interfaces in the CS segment specifications were sometimes “soft” with respect to interfaces with other GPS segments and systems. The segment specifications were placed on contract for each of the segment contractors. This situation emphasized the need for a robust interface control process.

39

Figure 3-9 is the top-level specification tree for Block I, which includes the unique Block I navigational technology system segment. Figure 3-10 is a Block II/IIA flow chart, but provides a good indication of the interfaces for the major system segments. The JPO Systems Engineering Directorate was responsible for configuration management and accomplished the administrative duties and coordination for the Configuration Control Board chaired by the Program Director.

Figure 3-9. Phase I Specification Tree (Ref. 28)

Figure 3-10. Phase II Specification Tree (Ref. 41)

In 1975, the JPO developed and approved the Interface Control Working Group (ICWG)

Charter that outlined the program interface process. This document was signed by the service representative and the major segment contractors. The JPO had approval control over ICDs and would chair/co-chair all ICWG meetings. A contractor was identified as the Interface Control Coordinator (ICC) with administrative responsibilities in addition to the technical responsibilities for their area. This approach was consistent with the JPO being the system integrator. Again, this was an initial concern to Aerospace Corporation, who expected to have more of a system integration role in the program and with the contractors [17, Parkinson].

40

The charter described three levels of ICDs: Type I – Interface with agencies outside the JPO; i.e. system-to-system Type II – Interfaces between the major segments of the system; e.g. SV -UE Type III – Interfaces within the system segments; e.g. CS CI “A” to CS CI “B”

The Charter also established a hierarchy to the interface decision process with the Interface

Control Steering Group overseeing the Interface Management Group, who oversaw the ICWG to ensure a structured means of program issue resolution.

The JPO Systems Engineering Directorate was responsible for configuration management of specifications, Level I ICDs, and system design configurations. The directorate accomplished the administrative duties and coordination for the Configuration Control Board, chaired by the Program Director. Maj. Mel Birnbaum from the Systems Engineering Directorate was the focal point within the JPO for the ICWG process during the early phases of the program. He was credited by his peers at the JPO and on the contractor side as the key individual to making the system integration work during Phases I and II [25, Scheerer; 21, Reaser ; 8, Fruehauf; 16, Nakamura; 14, Krishnamurti; 23, Robertson]. The technical support from Aerospace Corporation to the ICWG process also contributed to the success. Their support in a system integration support role was methodic and added technical value, complementing the JPO effort [25, Scheerer]. The ICWG process would not have worked with the JPO and Aerospace Corporation alone – the contractors were an integral part of the process. Although initially reluctant to being controlled by the ICWG, each contractor became very proactive in the process. Both the JPO and the contractor program management provided an atmosphere of mission success that fed this support. Host vehicles (user systems) and other pertinent agencies were always well represented and active. Typically, ICWG meetings lasted two to three days and were very grueling according to some participants. A typical ICWG agenda would consist of a review of the contractor’s latest design, identifying interface issues/changes, and establishing action items that were logged and tracked. The status of the segment designs defined the next phase meeting agenda. There were examples of the contractors recognizing an evolving issue and, without direction, working overnight to develop a solution by the beginning of the next day’s meeting [17, Parkinson]. Though the ICWGs were well structured, there was flexibility in the process. During this phase, Rockwell Collins had a concern about the 50 Hz data message definitions in ICD-GPS-200 between the space segment and the user equipment. They called Maj. Birnbaum, identified the issues, and presented the logical rationale for the need for the change. Four weeks later, the ICD had been changed without further coordination. The JPO – as the integrator – made the change unilaterally [14, Krishnamurti].

41

The number of ICDs grew during the program. By 1979, per the ICWG Charter (YEN- 75-134), there were 19 major ICDs identified. These did not include all the Type III ICDs. Eventually, the program managed over 200 Type I-Type III ICDs [21, Reaser]. Figure 3-11 illustrates the breadth of some of the ICDs. The ICWG process was instrumental in making the system work as an integrated whole.

Figure 3-11. Interface Control Documents (chart from 2005 JPO SE briefing that captures the breadth of some 200 ICDs) (Ref. 29)

Figure 3-12, GPS Functional Flow Diagram, illustrates the interfaces with other elements

of the system besides the three major segments defined in the system specification. The other interfaces identified included the rocket, launch, range support, and data processing (computational support).

3.3.7 Systems Engineering

Although the systems engineering process in Phase I has been discussed previously, this section will expand on the concepts. For example, one of the user equipment contractors was technically competent, but lacked effective management. The JPO strongly suggested that a systems engineering firm be hired to assist the contractor in managing program and they agreed [17, Parkinson].

In order to conduct the later phase of testing at YPG with Block I SV being in the loop, a

prototype system had to be developed. This would consist of a ground control system with up- load and satellite control, and an optimized SVs test constellation. The General Dynamics Control/ User Segment trade study (Ref. 19) had established a preferred approach, which the JPO followed. An interim control system (ICS) was established at Vandenberg AFB (VAFB). The four remote sites were selected based upon three recommended by the General Dynamics study: Hawaii, Alaska, and VAFB – Guam was selected for the fourth site. The contract with General Dynamics and Magnavox was a fixed-price contract per direction from HQ AFSC/CC, Gen. Alton Slay. The program at this stage was still too fluid. Hardware was state-of-the-art and did

42

not present issues. The major effort was in software for the modeling of ephemeris equations and the atomic clocks, as well as maintaining reasonable program error margins/accuracy. Contractor- government working relationships were strained as a result of the efforts required once on contract. Eventually, communications improved and mutual trust was established [16, Nakamura]. There were no typical user/operational input requirements to this phase of the control station development. In this concept development phase, the JPO became the “user” for developing the requirements for the support systems structure, the CS. The JPO utilized experience from the Navy TIMATION launch and SV control systems, the WSMR ground testing, other Air Force rocket programs, and the unique requirements of this program to develop the CS concept of operations and the performance requirements.

Figure 3-12. GPS Functional Flow Diagram (Ref. 28)

In conjunction with this support structure effort, the Systems and Space Segment groups had to define a constellation that would maximize the test window over YPG. The General Dynamics study had recommended a constellation of four satellites. The baseline program had contracted with Rockwell for four Block I satellites, one of which was to be a refurbished qualification unit. However, the analysis did not consider the failure mode of any one satellite in orbit, which would create coverage and accuracy issues with respect to the YPG test plan. This had not been considered as an issue when the initial program plan was developed. It soon became apparent, after further analysis, that the minimum satellite requirement for testing was six in order to assure acquisition of data to meet the objectives of this phase. The program needed spare satellites to complement the four that Rockwell was on task to supply. This situation presented a cost and schedule risk to the demonstration testing. The requirement for four SVs was reflected in the budget established for the program during and soon after DSARC I. It would be quite difficult to request additional funding so soon after the baseline program was established. In the upfront program formation, the systems engineering process had not adequately addressed the

43

reliability/availability and logistics/support requirements in conjunction with the test mission, concept of operations, and schedule for this concept development phase.

While the JPO was trying to solve the critical dilemma of insufficient number of satellites

to conduct a reasonable test program, the Navy TRANSIT program was submitting a request for funding to provide an upgrade to track the Trident booster. The TRANSIT plan included use of a PRN code similar to the GPS baseline signal. The JPO saw this as an opportunity to solve their satellite dilemma. The Systems Engineering group investigated options to provide the TRANSIT program their enhanced capability and the JPO funding for the needed additional satellites. The JPO proposed an approach to have the JPO be responsible for providing TRANSIT capability. The technical solution that the GPS program developed was to accomplish the mission using a signal translator on a missile bus relay. “Dr. Bob Cooper of DDR&E requested a series of reviews addressing whether GPS could fulfill the (TRANSIT) mission” (Ref. 15). After a series of reviews, Dr. Cooper concurred with the JPO proposal and transferred $60M of Navy funds to GPS, which would allow two additional satellites to be acquired and provide TRANSIT with their enhanced capability.

The JPO, with assistance of Aerospace Corporation, conducted analyses and trade

studies. They determined that a constellation with satellites in two circular planes would allow the six satellites to cluster over the western CONUS once per day. This would provide three- dimensional coverage for one to three hours at the YPG. Each satellite was uploaded daily from the ground stations just prior to being viewed over YPG.

The two major system accuracy requirements, time and position, were allocated to vari-

ous segments via error budgets. In the Precise Positioning Service (PPS) system, range error – a measure of the error in range to each satellite as seen by the receiver – was allocated to the three major segments. These allocations are depicted in Table 3-6.

Table 3-6. GPS PPS System Error Range Budget (Ref. 42)*

Segment Error Source UERE Contribution

(meters, 95%) P-Code C/A Code

Space

Frequency standard stability 6.5 6.5 D-band delay variation 1.0 1.0 Space vehicle acceleration uncertainty 2.0 2.0 Other 1.0 1.0

Control Ephemeris prediction and model implementation 8.2 8.2 Other 1.8 1.8

User

Ionospheric delay compensation 4.5 9.8-19.6 Tropospheric delay compensation 3.9 3.9 Receiver noise and reduction 2.9 2.9 Multipath 2.4 2.4 Other 1.0 1.0

Total (RSS) System UERE (meters, 95%) 13.0 15.7-23.1 *User Range Equivalent Error (UERE) is a measure of the error in range measurement to each satellite as

seen by the receiver. The portion allocated to the Space and Control Segments is called the User Range Error (URE) and the portion allocated to the UE is called the UE Error (UEE). UERE is the root-sum-square of the URE and UEE.

44

The system time transfer error budget (in nanoseconds based upon 95% probability)

allocations are depicted in Table 3-7. Each of the major system segments was responsible for meeting their allocated error budget requirements. These time and position allocations were not only tracked by the Segment Group, but also by the Systems Group within the JPO.

Table 3-7. GPS Time Error Budget (Ref. 42)

Error Component Error (ns, 95%) US Naval Observatory Measurement Component 137 Control Segment Measurement Component 59 GPS Time Predictability 92 Navigation Message Quantization 6 Satellite Orbit 22 Satellite Clock 63 Satellite Group Delay 12 Downlink and User Equipment 65

Total (RSS) Time Transfer Error Budget 199 3.3.8 DSARC II

The programmatic culmination of Phase I was to provide evidence of meeting the objec- tives of the phase and obtain approval from DSARC II to proceed to the next phase. Included were full-scale engineering development, validated navigation signal compatibility, prototype ground station, and preferred UE designs. AFTEC determined that there were no major operational deficiencies that would prohibit continued development and testing. This phase had demonstrated the capability of the atomic clocks to be a stable system in the space environment and established cost estimates for the program. DSARC II was held on 5 Jun 1979. The “DSARC has expressed concern about system cost, notwithstanding the demonstrated performance and the significant operational benefits which will accrue by its deployment…places the DSARC approved program alternative at the Basic level and a delayed program of reduced scope.…thorough review to identify potential cost reductions (i.e. analysis of all requirements, system specifications, testing contracting, etc.) but also restraint during the engineering development phase to insure future development efforts are focused on essential modifications” (Ref. 30). As a result of the DSCARC, the baseline IOC was revised to 1986. 3.4 System Development (Phase II, Block I)

3.4.1 Objectives

The objectives of Phase II were to develop the SVs, complete Initial operational Test and Evaluation (IOT&E) of user equipment, initiate production of low-cost mission-support UE, and establish a two-dimensional limited operational capability. Rockwell International had been placed on contract for the SV development and General Dynamics was on contract for the ICS. Block I would not require implementation of selective availability or anti-spoofing

45

requirements8. The requirement for a nuclear detection system as a secondary payload was to be implemented. The launch vehicle for these SVs was the Atlas E/F. 3.4.2 Systems Engineering (JPO)

During this time frame, Col. Reynolds (JPO Director 1980 to 1983) determined that the Systems Engineering Directorate should take on more of an integration role. He believed that too many unresolved issues between the segments and/or systems were being raised to his level for conflict resolution. He wanted the Systems Engineering Directorate to be mainly responsible for the integration between the system segments. Their mission was changed to receive, debate, and allocate requirements; arbitrate issues among the segments; maintain the system architecture, which was fairly stable at this time; and continue to be responsible for the ICDs and system specification [22, Reynolds]. They would also monitor systems engineering processes being used by the segments. This Directorate was “…like an anti-body forcing Segments to make sure they were doing good systems engineering. Otherwise, the Segment group feared that the Systems Engineering Directorate would get involved in your program and possibly take over [21, Reaser].” Col. Reynolds’ philosophy during this phase was “…don’t be elegant and don’t make everything new, go with proven technology” [22, Reynolds].

Col. Reynolds also wanted to assure support from other communities (e.g. DMA, FAA,

USCG, and Cambridge Research Laboratory). This was a critical time in the program from a budget standpoint, and to proactively advocate the program utility to potential customers within DoD, international allies, and the commercial side. The Systems Engineering Directorate was responsible for providing domain knowledge of interfaces to the potential customer’s requirements. This was often accomplished on-site with demonstrations (with the manpack).

Col. Reynolds formed alliances with the communities that were neutral, or even antagonistic, toward the program. The FAA was developing the microwave landing system and GPS could be considered a threat to that program. The JPO worked with the FAA to provide better insight into the capabilities and limitations of GPS. Cambridge Research Laboratory favored the Inertial Navigational System (INS) and appeared antagonistic toward GPS. Col. Reynolds hired Cambridge Research Laboratory to conduct a study of INS and GPS, resulting in a more favorable attitude toward the program, in addition to the technical benefit of the study. 3.4.3 Interface Requirements

During the development of the Interim Control Segment (ICS), an interface issue arose with respect to telephone communications with the remote sites. The timeframe of this issue was soon after the split-up of Bell Systems (AT&T) in 1984, due to the court ruling with respect to monopoly interests. The contractors and government did not foresee the problems with the small telephone companies on the West Coast establishing unique requirements/procedures that impacted the effort to try and establish communications links among the remote stations, master control, and the test facility. Communications routes along the West Coast and over to YPG required extensive workarounds and time-consuming solutions [20, Prouty].

8 Selective availability is the intentional degradation of the transmitted signal by a time-varying bias on the C/A code. Anti-spoofing guards against fake transmissions by encrypting the P-code to form the Y-code.

46

3.4.4 Budgetary Impacts to Functional Baseline

Funding became a major issue for the program in the late 1970s and early 1980s. The Air Force, in general, was not supportive of the budget requests from the JPO. The DSARC II had recommended the continuance of the program at a reduced scope, as mentioned in Paragraph 3.3.8. Systems engineering would play a key role in reassessing the functional baseline. There had been a 10% reduction ($500M) in program funding. The program was restructured, resulting in a reduction in the number of Block II SVs and a change in some performance requirements, such as weight and power.

Senior Air Force staff questioned the ability of the system to survive threats and re-

quested that a study be conducted to identify those threats, threat countermeasures, and the cost of those countermeasures. The Defense Intelligence Agency had no defined threat against the GPS. The task was passed down to the Air Force and AFSC intelligence agencies before the JPO was finally tasked and accepted to identify and assess potential threats. Systems engineering had been continuously assessing threats to the system during the development effort. There was a classified appendix to the system specification that detailed a threat environment that the JPO had postulated, as there had not been any “official” defined threat. The UE contractors had to meet this requirement, which was a tough set of requirements with respect to ground and airborne jammers [25, Scheerer]. There was no consensus within the Air Force as to the threat requirement and there was a genuine concern about the ability to jam the receiver. Eventually, an “exaggerated” baseline threat scenario was established for the user equipment by which the foe had a powerful jammer (100 KW) on 80-foot-high towers near the Forward Edge of the Battle Area (FEBA) [25, Scheerer; 22, Reynolds]. The JPO set up and conducted testing to simulate this condition based upon many assumptions and the scenario was successfully demonstrated. However, there still was reluctance to fund the program. There was also a request to estimate the cost of nuclear hardening the SV. The JPO estimated $850M for the development and production costs [22, Reynolds].

From 1980 through 1982, funding for the program was essentially zeroed out by the Air

Force, which recommended cancellation of the program. The AF budget proposed sufficient funds to maintain operation of six Block I satellites to enable the Navy to continue data gathering and characterization of the Fleet Ballistic Missile (FBM) Improved Accuracy Program (IAP). There were indicators within the JPO at the Control Segment Critical Design Review (CDR) and at a major navigational symposium that the program was to be cancelled. Senate staffers asked the JPO for cost estimates to shut down the program , even though they had not thought about the cost to go to other alternatives. It appeared Air Staff would not support the program. The JPO fostered dependencies such as embedding GPS navigation into the platforms mission – such as the F-16 aircraft program and the Joint Tactical Information Distribution System (JTIDS) – that would stimulate funding. After a briefing by Col. Reynolds, Secretary of Defense Harold Brown9 observed the global military need, the vested alliances established by the JPO, and future potential users. He reinstated the funding, including the estimated funding for nuclear hardening. Again, DoD acted in the user capacity and was influential in saving the program. Even with the change in Presidential administrations, Secretary of Defense Casper Weinberger10 would eventually continue to support the program [22, Reynolds]. 9 Honorable Harold Brown was Secretary of Defense from 21 Jan 1977 to 20 Jan 1981 10 Honorable Casper Weinberger was Secretary of Defense from 21 Jan 1981 to 23 Nov 8

47

As a result of these budgetary exercises and funding cuts, one of the major program impacts was to the system architecture. The number of Block II satellites had to be reduced from 21 to 18. The JPO needed to determine the impact on global coverage, and what would be the optimal SV configuration. Through the systems engineering process, SV constellation trade studies to determine the minimum number of satellites were conducted primarily by the JPO and Aerospace Corporation with inputs from Rockwell. The conclusion was an 18-satellite constellation to provide continuous global coverage to primary areas of interest. After extensive analysis, a 6-plane constellation with equal spacing within the plane and a 55-degree inclination (limited by launch vehicle constraints) was selected. Note that the breakpoint between a 3-plane and 6-plane constellation was 21 SVs. Below 21 SVs, the 6-plane was more advantageous. The implementation of the presidential directive to launch all Air Force satellites from the space shuttle (see Paragraph 3.5.4 for more detail) was an influencing factor in the selection of the inclination. Since the SVs had to be man-rated with respect to the Space Shuttle, the launch site was moved from VAFB to Cape Canaveral. Launching from Cape Canaveral could not support a 63-degree inclination and had to be reduced to a 55-degree inclination [25, Scheerer]. The three spares would be inserted into every other plane, for a total of 21 satellites. The outage of any SV could disrupt the service over one or more critical areas of the globe with this configuration, until the replacement satellite was deployed [22, Reynolds; 25, Scheerer; 11, Green; 21, Reaser].

The Air Force decided in the late 1970s to remove the IONDs requirement from the GPS program and transfer it to the Defense Satellite Program (DSP). The GPS program was seeking strategic alliances to help with funding problems in this timeframe and saw an opportunity to “re- claim” this capability. They proposed to Gen. Jacobson at the Pentagon that, if the nuclear detection system requirement was returned to the GPS JPO, the nuclear detection capability could have a worldwide edge with the GPS satellites. The request was approved with the transfer of NDS inte- gration funding and the requirement was inserted into Block II [20, Prouty]. The NDS requirement had been changed from the initial IONDS, in that an electromagnetic pulse (EMP) sensor would be required. The functional baseline was again adjusted to accommodate this new requirement.

3.4.5 Rockwell International Systems Engineering

The Rockwell International GPS Satellite Program Manager organized his workforce to parallel the JPO organization so that there would be a counterpart in Rockwell for each JPO responsibility. He believed that communications were extremely important and that there was a need to know who to contact (both government and contractor) when there was an issue. Rockwell organized their engineering staff into a classic project organization with a systems engineering office, subsystems engineers, and Work Breakdown Structure (WBS) task team leaders reporting directly to the chief program engineer. The Rockwell International Block I GPS Program Organization chart is in Appendix 6. The two major ICDs were with the Control Segment and User Equipment Segment. Internal ICDS (Type IIIs) were established, as required within the subsystems. Requirements levied on Rockwell were top-level performance requirements such as SV life, signal generation, error budget, and interface requirements [21, Reaser]. Design and interface requirements drove system-level requirements in many cases, as there was no single Using Command to establish them. Contractors conducted design studies to determine the best way to implement decisions. Rockwell was focused on technical solutions that minimized cost and schedule impact [8, Fruehauf].

48

When the IONDS requirements were levied on Rockwell, a separate chief engineer became responsible for the interface of IONDS and the SV; the development of the L3 signal peculiar to IONDS data transmission; and the establishment of the ICD and MOA with the Department of Energy (DOE), specifically Sandia National Laboratories and Los Alamos Laboratory.

The Rockwell GPS Block I design and development team (Appendix 6) focused on sim-

plicity of design for easy manufacturing and addressing the functionality of the high-risk compo- nents. These high-risk items were: (a) the atomic clocks; (b) the navigation payload; (c) the RF chain/ High Power Amplifier (HPA); and (d) the antenna. These components were designed, fabricated, and tested prior to contract award to reduce risk and to demonstrate feasibility. Throughout the de- sign and development process, the theme for the GPS team was “build what is designed during the proposal phase.” This enhanced the subsequent success during the relatively short factory-to- launch-pad schedule. The successful GPS satellite design was the result of several engineering concepts:

1. Focus on designing the satellite around the most important and environmentally sensitive component – the clocks, with all other considerations virtually secondary.

2. Simplicity of design that made the satellite highly reliable, more producible, cost effective, and compatible (without constraints) for launch initially from Atlas-F ICBMs. This reduc- tion in complexity extended to launch and on-orbit operations.

3. Trade studies and subsequent sub-system designs that contributed to the GPS satellite sim- plicity and reliability included: a. Utilized single degree of freedom solar array drives and yawing the spacecraft for the

needed second degree of solar array freedom. b. Selected solid-state HPAs – versus less-expensive Travel Wave Tubes (TWT) – for long

life, reduced power consumption, and elimination of high-voltage power supplies. c. No on-board computer running the navigation-operations functions. d. Utilized passive thermal control system especially designed to accommodate the temperature-

sensitive clocks, again reducing power consumption. e. Optimized spread spectrum ranging and data-stream signal structure to meet link require-

ments, while at the same time adhering to the constraints of the national and international regulations concerning electromagnetic radiation (Note: The GPS receiving signal power was approximately 1×10-16 watts – practically undetectable – and, therefore, would not require licensing in foreign countries).

f. In response to a joint JPO and Rockwell concern about how to maximize coverage of a single SV broadcast, developed the 12-helix phased array antenna (Al Love of Rockwell International invented the unique antenna), shifting the usual excess radiated signal power at the bore site to the 5-degree elevation angle. This reduced power consumption and provided a more homogeneous radiation pattern to the earth’s surface from the SVs’ line of sight.

g. Incorporated magnetic momentum dumping11 of the active control system (ACS) reaction wheels for longer spacecraft orbital life.

11 Magnetic Momentum Dumping (MMD) was developed for the program by the Astronautic Department at the US

Air Force Academy and first tried on Block I as an experiment. After the technology was proven, it was baselined into the Block I Replenishment SVs and the Block II SVs [21 Reaser]. MMD is the capability to generate sufficient

49

The above efforts contributed to the reduction of solar panel surface area and to control the weight allocated requirement.

For the GPS Block I build phase, among the many systems engineering management concepts that contributed to cost and schedule efficiencies, was the purposeful violation of the common taboo: “a prime contractor is advised not to be in series with the contract performance of the subcontractors.” On the contrary, Rockwell placed itself in series in two areas: radiation hardening design and the high-reliability space parts program.

The radiation-hardening requirement was a new technical challenge for most subcontractors.

Rockwell offered the subcontractors “zero-risk” radiation hardening design and technical expertise via a 40-hour subcontractor bid of interface time with Dr. Norman Rudy from Rockwell’s Ballistic Missile Division. Dr. Rudy reviewed designs in-progress, often on-site, and necessary changes were accomplished up-front, thus reducing risk of meeting the radiation requirements. Often this was accomplished in unique innovative system approaches. Beside minor box redesigns and use of parts, they included needed circuit changes/additions, local parts or box shielding, and shadow shielding from other hardware at the spacecraft level. One or more of these techniques was applied, with Rockwell accepting the subcontractor’s product as compliant.

The high-reliability, space-qualified, S-Level (or S-equivalent) parts program was another risk-free venture for the subcontractors on a voluntary basis. All but one of almost a dozen sub- contractors participated in the parts pool. A qualified space parts list (QPL) was generated, with subcontractors adding unique parts that required qualification. Total-requirement part lots were purchased by Rockwell and S-equivalent screened when needed, qualified, and made available for subcontractor draw-down. Using a NASA-qualified central screening house became a source of huge cost and schedule savings. Beyond the programmatic advantages, spacecraft reliability was achieved through large and common (non-fragmented) lot date codes: traceable, predictable performance, and consistent test and screening procedures [8, Fruehauf].

Rockwell, as the SV segment developer, was the lead on the system development of the signal with coordination with the UE segment. The only systems engineering decision driven by the UE was the number of SVs that would be above the horizon (three or four) in order to keep the cost of the UE low (Section 3.4.8 provides additional information).

SV weight was an identified upfront concern – only a 50 pound margin was allowed. Tracking was by Technical Performance Measures (TPMs) and status was reviewed weekly by the RI Chief Engineer.

RI tailored the general military specifications imposed on the GPS contract before pass-

ing requirements onto the subcontractors. These tailored requirements were then incorporated into a specific boilerplate section of all the subcontractor specifications. RI engineering managers were in daily or weekly contact with their subcontractors with frequent visits. The JPO and Aerospace had people assigned to each subsystem who, as part of this mini-team with RI, evaluated all

torque through magnets to dump excess momentum from on-board reaction wheels without disturbing the precise ephemeris of the SV.

50

aspects of the subcontractor. Formal subcontractor management reviews were conducted by RI every 3-4 months with Capt. Green (JPO SV Manager), Irv Rezpnick (Senior Aerospace Manager), and other supporting personnel accompanying Mr. Schwartz. Review out-briefs were made to the subcontractor head at the facility on the results of the visit [26, Schwartz].

Box-level qualification and acceptance testing were accomplished according with MIL-

STD-1540. The program was one of the first to use this specification to detail requirements for functional, shock, vibration, and thermal testing [26, Schwartz]. See paragraph 3.3.7 for further insight on this subject.

The parts control program (mentioned above with respect to the RI systems engineering effort) was controlled by the JPO and was a significant systems engineering effort. The program was maintained under the Systems Engineering Directorate. The Configuration Control Board (CCB), administrated under this directorate, maintained configuration management of the parts program process [25, Scheerer]. There were small sets of S-level and JAN X parts approved by the government at this time. The cost and schedule associated with developing new S-level parts unique for GPS was prohibitive. Rockwell, with JPO concurrence, pursued the S-equivalent approach that took existing non-S-level approved parts and established stringent screening processes to attain a space-reliable part that met its allocated availability/reliability requirement.

The GPS Block I parts program and unique requirements/verification processes established

for S-equivalent and JAN X-equivalent parts was the basis for most of the thinking, require- ments, and processes that went into MIL-STD-1546 (USAF): Parts, Materials and Processes Standardization Control and Management Program for Spacecraft and Launch Vehicles (12 Feb 1981 original release), and MIL-STD-1547: Electronic Parts, Material and Processes for Space and Launch Vehicles (31 Oct 1981 original release) [21 Reaser].

RI’s approach to system requirements and design also included consideration of Factory-

to-Pad logistic operations. Mr. Dick Schwartz, RI GPS program manger, stated, “I think this (Factory-to-Pad) was an Aerospace (Corporation) idea and a good one. After thermal vacuum we configured the space craft for shipment, performed a final factory functional (FFF), placed the satellite on a truck, and delivered to the pad. The truck backed up to the booster at VAFB and the satellite was placed on the booster. We then had a short test to assure that no damage occurred in transportation and were ready to launch” (Ref. 37). 3.4.6 Atomic Clocks

One of the major challenges for Block I was to develop a space-qualified clock based upon the data and lessons learned from TIMATION and the NTS program. The original baseline for the Block I was that each satellite would contain two Rubidium (Rb) and one Cesium (Cs) atomic clocks after SVN #3. As it turned out, however, three Rb clocks were flown on SVN 1, 2, and 3, and 2 Rb and one second-generation preproduction model Cs clock was incorporated after SVN#3. The Cs clock was referred to as a Pre-Production Model (PPM) and was derived from the NTS-2 Cs clock [30, White]. The top-level requirements were clock stability and a service design life requirement of five years. Embedded in the service life requirement was the ability to withstand the space environment, especially thermal and radiation effects. NRL had adequately addressed the radiation effects on the clocks in the early phase of this program [21, Reaser]. Ten

51

Block I SVs were successfully inserted into orbit. The SVs generally operated between 8-14 years with, “…a majority of the clocks performing well beyond their expected life expectancy” (Ref. 31).

In this phase of the program, Rockwell was responsible for the development of the Rb atomic clocks. Radiation environment data was available and there were documented lessons learned from the TIMATION and NTS effort. The challenge for Rockwell was the Rb lamp, which was a high-risk effort. RI utilized technical expertise from Aerospace Corporation to resolve issues with the lamp. A rigorous ground test with actual hardware was conducted to verify thermal, radiation, and life cycle requirements [8, Fruehauf].

Beginning with Block I, Rockwell’s baseline clock consisted of Rockwell-Efratom pro-

duced Rb clocks. The initial Block I satellites flew three Rb clocks and no Cs units. Toward the final Block I program, Cs was introduced. For Block II/IIA, two Rb clocks and two Cs FTS clocks were established as the baseline configuration per satellite. Originally, the Cs clocks were to be provided by three different companies, with Frequency and Time Systems (FTS) supplying the majority of the Cs clocks. NRL, funded by the Navy, conducted a second source develop- ment effort for Cs clocks with FEI and Kernco. However, none of the alternate clocks ever became operational on a GPS satellite. Several second-source Cs clocks flew on Block IIA SVs. A Block II Cs atomic clock is shown in Figure 3-13.

Figure 3-13. Block II Cesium Atomic Clock (Ref. 50)

In Block IIR, a second source effort was directed by the JPO to control cost and schedule. Under RI contract, EE&G was selected to build the Rb clocks and qualified the clock for the space environment [21, Reaser]. One of the major program issues is the manufacturing base for space-qualified atomic clocks. The program purchases clocks in small lots, e.g. approximately 30-40 per lot, with a lull in lot orders for many years. There is no other commercial or military need for this space- qualified product. As a result, the clock vendors are not stable, and companies either lose their expertise and corporate knowledge or go out of business. For Phase IIR, the plan was to have (Cs) and (Rb) clocks on board the SV. The Cs clocks were to be built by SCI using technology transferred from Kernco. The technology transfer was not successful and the SCI clocks were never suitably qualified for space environment. Hence, the SV segment baselined three (Rb)

52

Perkin Elmer clocks and no Cs clocks for Phase IIR. A summary of the atomic clocks used in the SVs for the various phases is listed in Table 3-8. The problem of atomic clock supply worsened as GPS became successful and more widely used. GPS became the global standard for accurate time, thereby further shrinking the market for atomic clocks. As this market shrinks, it becomes even more difficult for the GPS program to buy the clocks it needs to maintain the global time standard. Ironically, the program’s success is killing the market for its own critical component.

Table 3-8. GPS Atomic Clocks [8, Fruehauf, 21 Reaser, 30 White]

Rb Clocks Cs Clocks

NTS-1 Two modified commercial Efratom clocks (also, 1 high-quality quartz oscillator) under contract to NRL

NTS-2 Two space-qualified FTS under contract to NRL

Block I Three Rockwell-Efratom clocks (SVN #1, 2 & 3); two Rockwell- Efratom clocks for SVN #4+

No clocks for SVN #1, 2 & 3; one FTS for SVN #4+ (NRL contract)

Block II/IIA Two Rockwell-Efratom clocks Two FTS under contract to RI

Block IIR Three EG&G (Perkin Elmer) under contract to RI

3.4.7 Control Segment

The ground support system located at VAFB and the remote sites (referred to as the ICS) were established for the concept validation phase and upgraded as required to support the Block I SVs. This was primarily a software upgrade. The ICS had to address navigation critical systems, ephemeris algorithms, L-band signals, clock state, time transfer, processing uploads, and control of SV. The concept of selective availability during this Block I effort was unclassified, which eliminated any requirement for classified crypto equipment. ICDs between Maser Control Station (MCS) and remote sites were updated. Interfaces with USNO through ICDs were also established with respect to time transfer and updates from USNO.

This phase of the program became the first real instance of operational commands supporting the program. Around 1980, HQ SAC took on the responsibility of being the operator of ICS. Training was accomplished primarily through on-the-job training from the JPO and the contractor, IBM. HQ SAC handpicked their operators, and they were all engineers [16, Nakamura]. This approach had the additional benefit of having the operators perform some limited troubleshooting. SAC also established a liaison officer at JPO and provided guidance in developing operating concepts for the control segment. Established ICDs between MCS and remote sites were updated.

In the early 1980s, a major Air Force trade study investigated whether Fortuna AFS or Colorado Springs, CO would be best suited to house the AF Consolidated Space Operations Center (CSOC). Colorado Springs was selected. Falcon AFB, which eventually became Schriever AFB, was established as the location for CSOC and the GPS Master Control Station that would be part

53

of this complex. This selection would impact requirements relating to the development of the Operational Control System (OCS) in the next phase.

USNO had the responsibility for precise time. One of the requirements for GPS is that it provides a worldwide time reference system for UTC (USNO) to every GPS user. To ensure the accuracy of the SV signal transmission, the USNO needs to receive GPS time and UTC (USNO) from the SVs and compare it with the USNO master clock. Corrections in terms of time bias and drift offset were transmitted to the GPS MCS for upload to the SVs. An ICD was established with the GPS CS. In 1978, USNO in coordination with the JPO contracted with Stanford Telecommunications to build the time transfer unit receiver in the Washington, DC area. The system became operational in 1979. Only one satellite is required to receive the precise time, assuming that the user already knows their precise position [19, Powers]. It should be noted that there were several users, especially in the commercial world, that value the GPS precise time over the GPS position data, as they already know their precise position. Early in the program with only a few satellites, some users bought GPS sets just for precise time. Today, virtually all bank transactions are date stamped with GPS time and most communication networks are synchronized with GPS time [25, Scheerer].

The SV design had an impact on the CS procedures. Orientation of the thruster rocket

plume had an adverse affect on the solar panel in certain orientations (low beta angle with respect to the sun) that created a momentum reaction, making the vehicle unstable. One of the initial Navigational Development Satellites became unstable during a maneuver and had to be recovered over a two-week time span. No design changes were made to the SVs in this phase. Procedure precautions were used to ensure that thrusters were not used when beta was low [16, Nakamura]. 3.4.8 User Equipment

One of the more important decisions made early in the program with respect to UE was based upon a system trade study. It established in the system architecture that there would be a minimum of four SVs above the horizon at all times. This allowed the development of receivers with inexpensive crystal oscillators in lieu of precision atomic clocks. The UE measures the dif- ference between the time of transmission of the signal by the SV and the time of reception of the signal by the UE to determine the three-dimensional position of the UE. With three satellites, a very precise time source would be required. However, with a fourth satellite, the fourth dimen- sion of precise time can be determined and a quartz oscillator can be used by the UE to provide the required accuracy. This decision avoided cost and potential weight/size impacts and opera- tional utility impacts to the UE.

The decision to avoid precise clocks in the UE by keeping four satellites in view

was a distinguishing factor in selecting TIMATION versus 621B. TIMATION used the fourth satellite for precise time, and 621B incorporated clocks in the UE. This key long term decision makes UE cheap at the cost of more expensive constellations. For the commercial users, this is a major benefit.

The program continually used a risk reduction philosophy of funding studies or designs to a multitude of sources, and then conducting a down-select. The competition among the contractors

54

provided investigation of new and innovative ideas, and also tailored costs. The program further reduced risk in that the multi-contracts usually were completed at a System Design Review (SDR)- or Preliminary Design Review (PDR)-type design. This approach allowed a better understanding of the events, schedule, cost, and risk in the next phase, and therefore could be better scoped in the RFP, proposal, and contract. However, this approach required both good planning knowledge as to when to implement this philosophy, and up-front funding to contract with multiple sources. This phase of the program for UE was divided into a Phase IIA and Phase IIB. In July 1979, the JPO awarded Phase IIA fixed-price contracts to Magnavox, Texas Instruments, Rockwell Collins, and Teledyne for pre-design/performance analysis. In 1982, a down-select occurred (Ref. 3). Magnavox and Rockwell Collins were both awarded Phase IIB contracts to continue development by refining requirements, fabricating proto- types, completing design, conducting qualification testing, and accomplishing extensive field testing. Most of the field testing was conducted at YPG and the Naval Ocean Systems Center at San Diego, CA. The Rockwell Collins process stressed a firm architecture supported by analysis. Their intent was to ensure that manufacturing/quality assurance were involved in the design process and strove for simplicity/commonality in the design. During this phase, Rockwell Collins used a modular approach that included a flexible module interface concept, by which modules were bolted to a common GPS receiver. This approach allowed commonality for various aircraft and reduced schedule and technical risk. Human factors played an important role in the man-machine interface, especially with the soldier variant [14, Krishnamurti].

As the number of users was increasing, both amongst the services and internationally, a

new trend emerged: some of these users were providing requirements directly to the contractor. The systems engineering process was reemphasized with the need to utilize services and international representatives within the JPO. This required the JPO to perform a systematic assessment to both validate and track the requirements. [24, Saad].

A major issue arose in the security classification requirements of the UE during the devel- opment of Selective Availability (SA) and Anti-Spoofing (AS) (SAAS) software12.13 National Security Agency (NSA) staff concluded that the UE should be considered a crypto device. This “new” requirement was assessed by the JPO. The systems engineering analysis identified major consequences to the GPS design and operations if this requirement was implemented. The CONOPS would be adversely affected due to the additional security needed in the field. The analysis also concluded that there would be potential impacts by adding another required Line Replaceable Unit (LRU) to the design to accommodate the new security requirement. An example of these impacts was that the manpack would have had a 15 pound additional LRU added to a device that already had a weight concern of ~10-15 pounds for manned portability. Several JPO discussions with NSA about the new requirement resulted in no mutual resolution, and NSA officials suggested alternative designs. The JPO systems engineering process assessed the alternative designs and found them inappropriate with respect to meeting other GPS requirements. The JPO continued their systems engineering process addressing CONOPS, 12 SA was solely software and AS was both hardware and software.

55

mission analysis, requirements and design analysis including security, and developed their own approach to the cryptology methodology. The issue finally worked its way up to the NSA Senior Manager. He considered aspects of the issue including the JPO approach, and resolved the matter by approving the JPO approach. After this, the JPO and NSA had a very constructive working relationship [25, Scheerer].

3.4.9 Design Reviews

Classic Preliminary Design Reviews (PDRs) and Critical Design Reviews (CDRs) were conducted in each of the GPS segments. MIL-STD-1521, “Technical Reviews and Audits for Systems, Equipments, and Computer Software,” was used as the basis of the design reviews. The standard was cancelled by the DoD later in the program; however, its use set up a valuable process for conducting the reviews and audits [16, Nakamura].

There was no overall GPS Systems PDR and CDR conducted. The JPO, as the system integrator, with technical assistance of Aerospace Corporation, verified compliance of segment designs to the system specification and the system architecture controlled by the JPO. This veri- fication was an ongoing effort. In some cases, the ICWG process resulted in meetings that were more like a technical interchange meeting or mini-design review, to which the meeting would define the next phase of effort based upon the segments design status [21, Reaser]. This defi- nitely was the case with the UE segment for both PDRs and CDRs. The host platform UE design reviews were informally conducted at the ICWG meetings for that UE receiver class. Types of classes for receivers included portable (soldier/land vehicles), aircraft medium dynamics (helicopters), aircraft high dynamics, and ships. The UE system segment specification design reviews, both PDR and CDR, covered all class receivers together [14, Krishnamurti]. In general, any requirement that had a “to-be-determined” status at PDR was deferred to the next upgrade program [24, Saad].

From one perspective, the ICWGs could have been considered more important as a design risk mitigation process than the typical design reviews. Issues were worked in real time and incrementally with a very structured process that tracked actions and was well-supported by the government and contractors. 3.4.10 System Integration

The JPO actually became involved in the aircraft integration to the dismay of several air- craft program offices. However, the JPO in-depth knowledge base and lessons learned from the concept validation and early system development phases were important to ensure that integration requirements were clearly defined and that there was a clear means of requirement verification. In the late 1970s and early 1980s, the program was also trying to survive among bud- get cuts and perception of cancellation. The JPO motivation was to ensure successful integration of the UE on the host platform to establish another alliance to justify proceeding with the program [21, Reaser]. 3.4.11 ICWG

The ICDs were maturing as the requirements analysis was concluding and new require- ments were being added to the program in this phase. Additional interfaces and ICDs were also required as a result of requirements development and new requirements.

56

NRL: Atomic clocks USNO: Precise time NSA: S/A & AS DOE (Sandia and Los Alamos): IONDS

The ICWGs were an excellent means to communicate, coordinate interfaces, assess design changes, and resolve problems [8, Fruehauf]. 3.5 Production and Deployment (Phase III, Block II/IIA)

3.5.1 Objective

The objectives of Block II were to “fine-tune loose ends” of the development and issue production contracts for 28 SVs [22, Reynolds]. An initial operational capability would be obtained with a mix of Block I and Block II satellites and a full operational capability with all Block II satellites. The SVs would be launched from the Space Shuttle.

Block II would include improved NDS and SV operating autonomy (ability to operate

without contact from CS up to 180 days), Anti-Spoofing and Selective Availability capabilities, and radiation-hardened electronics to improve reliability and survivability.

3.5.2 Acquisition Strategy

The strategy developed by the JPO was to procure the SVs like an aircraft system, a new approach for the space community. There would be a “lot buy,” basically a block buy of the SVs. This not only was a cost benefit, but also minimized the approval cycles through the Air Force by conducting a concurrent effort in developing the enhancements and incorporating them into a production contract [22, Reynolds]. The JPO had developed a Technical Requirement Document for this phase. The requirement for the W-Sensor of the NDS was added at a later time and the decision was originally made to allow for production incorporation at the 13th satellite.

Since the directed baseline launch vehicle was the Space Shuttle, the Air Force awarded a fixed-price contract to McDonnell Douglas to purchase 28 upper stage boosters called Payload Assist Modules (PAM-DII). Also, a separate cost-plus-support service contract was negotiated.

The SV segment contract required concurrence by RI, who was reluctant to sign up to a firm-fixed-price contract based upon their perceived risk. A team of Rockwell, subcontractors, vendors, manufacturing community, JPO, and Aerospace Corporation formulated the development plan/program. This included an extensive study of the assembly line at the Rockwell Facility at Seal Beach, CA. The team established an acceptable final program [22, Reynolds].

3.5.3 Nuclear Detection System

Early in Block I, the GPS program was tasked to include an IONDS as a secondary pay- load on the SV. The NDS provided a worldwide capability to detect, locate, and report nuclear detonations in the earth’s atmosphere or in near-earth space in near-real-time. The GPS was an ideal system to implement this capability, as the GPS functional baseline also required world- wide coverage for navigation that was implemented by the constellation configuration. The JPO did not have a requirement for the other elements of NDS: the NDS control segment and the NDS user equipment. The NDS sensors were developed by Sandia National Laboratories/Los

57

Alamos National Laboratory and provided GFE to Rockwell. The Air Force and the Department of Energy established a Memorandum of Understanding resulting in new development ICDs and some existing ICDs being modified for the interface with the system. Integration of the sensors into the SV created no significant issues. For Block II, the Air force established a requirement to upgrade to the IONDS system. The Nuclear Detonation (NUDET) Detection System (NDS) consisted of an optical sensor (Y- sensor), an X-ray sensor, a dosimeter, and an Electro-Magnetic Pulse (EMP) sensor (W-sensor). The W-sensor was a new function on the NDS. Sandia National Laboratories/Los Alamos National Laboratories developed he NDS sensors with the exception of the W-sensor. The JPO made a decision, based upon the projected schedule for the integration development effort driven by the W-sensor, to incorporate the NDS change later in Block II. The tenth Block II SV incorporated the NDS capability, and the NDS GPS satellites received the designation Block IIA. The functional baseline was adjusted for this new capability. Follow-on Block IIR SVs also included this capability. The systems engineering process identified a technical risk of integrating the W-sensor at the beginning of the program. As the integration effort continued, the task became more technically challenging than anticipated. The levels of EMI/EMC were far more sensitive than anticipated; i.e. in the 50-150 MHZ range. The basic concept was to make the SV a very good Faraday cage. Sandia National Laboratories would not sign up to develop the W-sensor, so Rockwell International was given the contractual responsibility for the development and contracted with E-Systems to provide the sensor. Sandia National Laboratories continued to provide technical support sensors [21, Reaser].

Gold foil wrap was added to the SV for electro-magnetic protection for the sensitivity of

the W-sensor. However, the SV solar panel motors emitted sufficient energy through the motor shafts that extended beyond the wrap. The W-sensor was detecting this energy. The simplest design fix for the already-designed and validated solar panel system was to add “fingers” to ground array shaft pads. This design approach presented an issue of meeting the lifetime requirement. The material of the “fingers”, which were in contact with the motor shaft, had to withstand suffi- cient life cycles without the material wearing away.

Significant studies and testing were required to define the appropriate materials for the

“fingers”. Ball Aerospace, in Boulder, was contacted to determine the material required for fingers. RI and JPO were deeply involved in the assessment. Many combinations of alloys were manufactured and tested until an Au/Ni alloy was successfully verified to meet all requirements. As Block II was a production contract with concurrent development in specific areas, the additional effort on the W-sensor was added via an H-clause in the contract. The schedule was not impacted as a result of intense effort, due to the proactive role of the team members [23, Robertson].

Integration of the X- and Y-sensors and dosimeter did not create any significant issues, as they had been integrated on other satellites. The verification of the W-sensor required RI to build a high-fidelity anechoic chamber. This effort resulted in a 12-14 month schedule impact. The cost to the W-sensor integration was $162M [23, Robertson].

58

The gold foil wrap around most of the SV resulted in a buildup of electro-magnetic energy

within the volume contained by the foil. The solar panel drive motor control system utilized a 1960s-type technology design with fusible links. There were redundant circuits (A & B strings). The combination of the noise energy and the command signal resulted in activation of a fusible link on SV-23. The consequence was that there were dual, but opposite, commands sent to the drive system. The interim operational fix was a procedural approach by which the control station would manually slew the arrays, which was a burden to the operators. The corrective action was to incorporate a static trap with a diode and capacitor added to the circuit. This design change was incorporated at a later time. The overall issue was a lack of a complete assessment of the internal satellite interface requirements and assessing the impact of the gold foil wrap design change on existing systems [18, Paul]. A Block IIA satellite is shown in Figure 3-14.

Pr ov

id ed

b y

H ug

o Fr

ue ha

uf

Figure 3-14. Block IIA Satellite 3.5.4 Shuttle Impact to Functional Baseline

The original Phase I plan for launching the Block II SVs was to use an expendable launch vehicle. The projected increased weight of the Block II SVs over the Block I SVs exceeded the Atlas series rocket payload capability by approximately 800 pounds. Delta rockets were the pre- ferred approach for the Block II SVs. However, Dr. Hans Mark, Secretary of the Air Force, issued a directive around 1979 to exclusively use the shuttle as a launch platform for all Air Force space vehicles. This implemented President Carter’s directive in the revised National Space Policy for all DoD to launch platforms from the space shuttle to “…take advantage of the flexibility of the space shuttle to reduce operating costs over the next two decades” (Ref. 34). This program requirement had a significant impact on the SV performance requirements.

The systems engineering process addressed the requirements and risk associated with

launching from the shuttle. The shuttle was man-rated, which required triple inhibits to cata- strophic risks and safe arm controls. It also required a shuttle mission specialist interface for launching from the Shuttle. In addition, analysis of the shuttle environment showed it to be more severe than normal expendable launch vehicles. An analysis of the shuttle bay capacity concluded that four GPS SVs with their required Transfer Orbit Stage and common airborne support equipment could be accommodated on one shuttle mission. Performance and interface requirements were incorporated into the Block II/Phase III Technical Requirements Document (TRD) (Ref. 44). The necessary MOUs and ICDs were established with NASA. A detailed Payload Integration Plan was developed for the SVs that complied with all NASA policies, regulations and requirements, and was updated on a periodic basis. The JPO conducted a cost-benefit

59

analysis and determined that a lot procurement of Payload Assist Modules (PAM-DII) tailored in design for the GPS shuttle launches was cost effective [27, Sponable]. Figure 3-15 shows the interface and elements/subsystems of the SV and the Shuttle (DoD Space Transportation System).

Figure 3-15. Space Segment System Relationship (Ref. 44)

As the development of the Block II SV continued, weight growth became an issue. Early

assessments identified the weight risk to the requirement of four SVs per shuttle mission and that the capacity may be only three per mission [27, Sponable]. The JPO was reviewing the actual operational launching of four satellites with respect to the risk of putting four satellites on one launch vehicle. An additional concern was the potentially lower priority GPS would receive in the shuttle manifest.

When the Space Shuttle Challenger disaster occurred in January 1986, the JPO had to de-

velop a risk mitigation plan. There was no backup or funding for alternative launch vehicles. It soon became apparent that the shuttle would not be available for operations for some unknown time. Ini- tial estimates of a six-month slippage kept growing. Further implications were that the shuttle facilities at VAFB ended after design changes in the shuttle diminished its capability for polar launches. These were key issues for all DoD launches. Eventually, the Air Force decided to contract for expendable launch vehicles on a high priority. To maximize launch flexibility, the JPO pursued a dual-access capability by establishing a baseline interface requirement for the Block II SV design. The interface could support either launch on the shuttle or a number of alternative expendable launch vehicles (ELVs). After a while, the shuttle launch requirement was

60

completely withdrawn, and no DoD satellites were allowed to use the shuttle. The severe environmental requirements driven by the shuttle compatibility required minimal changes for flight on ELVs, which helped expedite the transition to future ELV boosters [27, Sponable]. The functional baseline was again updated.

The acquisition approach for the ELV development followed the typical JPO risk mitiga-

tion approach by awarding the three $6M fixed-price contracts to develop preliminary designs and then down-selecting and awarding to the winning contractor. The Titan 3 rocket (Martin Marietta) had the ability to launch two SVs at once, but presented a problem in getting the SV to separate and transfer into a potentially different orbital plane. The Atlas Centaur rocket (General Dynamics) included a liquid-fueled third stage and the system had a significant cost impact. The Delta II (McDonnell Douglas) was ultimately selected, due to its lower cost and historical reliability. This design selection was a modification of the previous Delta rocket, stretching it about 20 feet and adding the bulbous fairing. The design of the fairing had a benefit that some of the SVs antennas did not have to be stowed during launch, which would aid reliability requirements [23, Robertson]. The Delta II was developed in two consecutive configurations: the first (Delta 6000) with an approximate payload capacity of 3670 lbs and the second (Delta 7000). The rationale for the two configurations was driven by the need to achieve a first launch date in 1989. A lighter payload version of the Delta II could meet the objective launch date (Ref. 33). The larger 4470 lb payload configuration for the heavier Block IIA SV with the NDS payload required more development time (Ref. 10). The JPO developed a plan to use the shuttle as a launch vehicle in parallel with the ELVs when the shuttle became operational again. The number of SV launches in the revised plan was originally 16 and then reduced to eight as the shuttle return-to-launch schedule slipped. Compli- cating this plan was the backlog of higher-priority satellites/payloads from other programs that could impact the GPS schedule (Ref. 33). Eventually, the decision was made not to use the shuttle.

A very structured process was established for the new ELVs and SVs. Lessons learned from launches were reviewed prior to each new launch. An Independent Readiness Review Team (IRRT) conducted a review of all qualification/verification items prior to the first launch of a new system/subsystem [23, Robertson]. Considering the commitment to develop a launch vehicle quickly, a reliable ELV source was developed in about two years. This would culminate in 28 consecutive successful launches of the Block II/IIA SVs. Key systems engineering processes that helped the program were: risk identification/mitigation, good requirements development, and good interface definition. Figure 3.16 shows a launch of a GPS SV on a Delta II rocket.

U S

A ir

F or

ce p

ho to

61

Figure 3-16. Delta II Launch of Block II Satellites

The systems engineering process was used to account for the change in the functional base- line requirement, time lines, and concept of operations with respect to logistics of the SV coming off the production line. The GPS program was the first satellite program to have such a large production run. The lengthy delay until first launch presented another dilemma for the JPO, namely, what to do with the satellites that were scheduled to come off the production line while they were waiting for flight. The SV design did not account for extreme lengthy delays before launch. The JPO tasked Rockwell to initiate a three-month systems engineering study of three options: stop production, slow the production rate, or continue the production rate and develop a storage plan and facility. The conclusion of the study was to slow down the rate of production based upon the assessment that the ELV would be available in approximately two years. This recommendation was implemented [23, Robertson].

The lot buy of PAM-DII units for use on the shuttle was now obsolete. The cost avoid- ance approach with a multi-year contract unfortunately became a burden, as there was no need for these 28 unique PAM-DIIs for shuttle use. The JPO cancelled contracts for these boosters, which resulted in not buying the last 12 units (Ref. 33). In this particular case, the risk of the lot buy was accepted based upon a firm requirement from the Secretary of the Air Force committing to the shuttle and a good cost-benefit analysis [21, Reaser].

The Challenger disaster had one benefit to the GPS program, in that it provided schedule relief. The CS had software problems and there was a moderate-to-high risk of not meeting the original launch date of late 1986. There was an extensive ongoing effort by the contractor, Aerospace Corporation, and the JPO to resolve the issues. One of the key issues included verification of selective availability. CS software releases were not complete and probably would not have supported the Block II SVs on the initial program schedule [20, Prouty]. The final operational release of the software occurred just a few months before the first Block II launch in February 1989. The delay in launching SVs into orbit adversely affected the UE developmental testing, which had planned on using early Block II SVs.

3.5.5 User Equipment (UE) Development Testing Effects

In April 1985, the JPO awarded the first Low Rate Initial Production Contract (LRIP) to Rockwell Collins. The contract included research and development, as well as production options for 1-, 2-, and 5-channel GPS airborne, shipboard, and manpack (portable) receivers. This allowed the UE to be cut into the F-16 production line. Initial JPO developments and procurements were exclusively Line Replaceable Units (LRUs), or "boxes", which included the 3A receiver for high- dynamic aircraft applications, the 3S receiver for shipboard applications, and the manpack (Figure 3-17 shows the Rockwell Collins version of the manpack). These were followed by the smaller and lighter Miniaturized Airborne GPS Receivers (MAGR) for high- and medium-dynamic aircraft.

62

Figure 3-17. Rockwell Collins Manpack (Ref. 47)

Aerospace Corp. conducted a threat assessment study for UE receivers. The JPO Systems

Engineering Directorate followed up with an assessment of the Fixed Reception Pattern Antenna (FRPA) and Controlled Reception Pattern Antenna (CRPA) and how a common antenna could satisfy all user requirements and save cost through common support and larger procurement of units. Due to the orthogonal capability of the CRPA, it was more effective in countering the threats. However, at that time, the CRPA was more complex and approximately three times more costly than the FRPA. The Navy originally selected the FRPA for its aircraft and then, years later, replaced it with the CRPA [18, Paul].

There were delays in completing the UE: “…operational testing as a result of lingering

receiver reliability problems and reevaluation of program requirements (that) …caused DoD to postpone the GPS receiver set full rate production decision until Sept. 1991, a decision originally scheduled for March 1989” (Ref. 38). The UE reliability requirements are included with other Test and Evaluation Management Plan (TEMP) operational system performance requirements pro- vided in Appendix 8 (Ref. 39). Delays in accomplishing operational testing of various receiver sets caused DoD to initially postpone operational testing until June 1990. The delays were caused by problems in integrating receiver sets with host aircraft and ships, late deliveries of receivers, availability of military personnel to conduct Army one- and two- channel tests, and the space shuttle accident which delayed launches of SVs needed for testing. On 21 Sep 1990, the Under Secretary of Defense for Acquisition postponed a full-rate production for all receiver sets until Sept. 1991. But, he approved continuing LRIP for one-, two-, and five-channel receivers through FY 1991, and recommended additional testing of the five-channel receiver sets. Five LRIP contracts were awarded to four contractors including Rockwell Collins, the initial LRIP contractor. The DSARC IIIB was further slipped to March 1992 (Ref. 40). 3.5.6 Control Segment

The program needed to develop an operational control segment to replace the ICS as the Block II SV came on line. There was also a need to upgrade the ICS to ensure continued support to the UE segment for their testing while the OCS was being developed. These two tasks were to be combined under one contractor effort. In the typical risk mitigation approach, five bidders were awarded contracts for concept design studies based upon the CS functional requirements. Upon completion of the studies, there was a down-select to three contractors: IBM Gaithersburg, Martin Marietta, and General Dynamics. This contractual effort continued to further develop the concepts and refine functional requirements, resulting in a pre-SDR functional baseline stage. IBM

63

and Martin Marietta worked to develop prototype labs and modeled receivers. General Dynamics had been the contractor during the previous phase. Again, a down-select occurred – this time, based upon the functional baseline established, IBM was selected for the continuing development. The JPO had difficulty getting IBM’s agreement to requirements because of the fluidity of the program. The JPO incentivized the contractual effort and IBM agreed to the effort [16, Nakamura]. The contract was awarded in September 1980. The Block II schedule also was aggressive and left no margin for issue resolution. Figure 3-18 illustrates the OCS top-level system diagram with functional and support groups identified.

IBM had a core of seven to eight personnel with support from other groups. They had no

previous space background in this division of IBM, but had solid systems engineering processes, a good system architecture, and documented system testing and tools [2, Berg]. The JPO augmented their lack of domain knowledge with experienced systems engineering people. Aerospace Corporation also provided key technical support. The IBM program approach was to have parallel paths for both program management and the technical group directly to the program director. This approach ensured that the technical side of the program would have opportunity to present their position to upper management when there was disagreement with program management [3, Conley]. The control segment process established system requirements and a specification tree; established functional block diagrams, physical block diagrams, and internal ICDs; and allocated requirements within the organization and to subcontractors and vendors.

The NDS requirements for the CS were minor. The roles and mission of the CS had to be

defined in order to allocate the appropriate NDS functional requirements to the CS. CS was neither responsible for the receipt of the L3 signal nor the functioning of the NDS system. Their responsibilities encompassed performing the NDS command and control of the SV as required by the user, identifying the health of the NDS system, and controlling the ambient environment (e.g. temperature) in the vicinity of the NDS.

The program offices, both at the JPO and the contractors, knew that the software and error

budget were high risk. The mitigation plan was to develop simulation and modeling to validate the software designs. Also, a national team of experts from government and industry, including the National Bureau of Standards, assisted in trying to resolve the modeling of the atomic clock. Ephemeris models were also creating problems. The TPMs used to track the software were pri- marily software lines of code (SLOC) and defect testing. The selective availability requirement was not well defined and was open to several different interpretations. Validation of selective avail- ability created issues in terms of requirement verification interpretation. Also, there was no tool to analyze the validity of the crypto data. An original estimate of the size of the CS software was 300K-400K software lines of code [20, Prouty]. The final size was 1.1 million lines of code [24, Saad]. Testing of the software was in the traditional method of unit, subsystem, and system tests, with FCA and PCA being accomplished at the appropriate levels [16, Nakamura]. Some of these issues were a result of the lack of tools to estimate design detail, the lack of clear definition on requirements, and an upfront understanding of verification approach/method required. However, the systems engineering process was used in successful resolution of the issues.

64

Figure 3-18. Operational Control System Top Level System Diagram (Ref. 43)

Initial CS software releases were in support of the Block I SV capability only. This allowed the OCS at VAFB to become operational in 1985. The accomplishment was made easier by the lack of Selective Availability encryption requirements for these releases that created challenges in Block II. (Note: Encryption was still required for satellite command uplink and data to/from the ground antennas to the MCS).

65

There was an extensive effort in the 1986 to 1989 period to resolve the Block II software problems. Validation and verification became a major issue with the software effort. One of the first problems was getting configuration designs and simulations from Rockwell. It was difficult to test the interface with the SV in the lab and a field effort was required. After JPO and Aerospace Corporation initiatives with Rockwell, a plan was devised and implemented to take Block II quali- fication boxes and rack, and upgrade the Block I simulator to a Block II configuration. The simu- lators were taken to Cape Canaveral in 1987-1988 for an extensive, almost full-time, 15-month effort allowing IBM to validate the upload and receive capability and interfaces of the CS [3, Conley]. Aerospace Corporation provided additional support to IBM in the transition of the OCS from Vandenberg AFB to Falcon AFB (now Schriever AFB) with permanent on-site support. This effort was the key to success of a final software release. IBM also developed operator and field manuals. The final software release (version 3) occurred in 1989, just in time for Block II initial launch with Delta rockets.

Training requirements for the CS were addressed by forming working groups consisting of the JPO, Aerospace Corporation, contractors, and operational personnel. Space Command had been recently formed and had taken over operations responsibility from SAC. There were no Space Command requirements. Interface meetings were established with Space Command. However, lack of continuity of key personnel within this new command resulted in different perceptions and needs, creating additional issues to address. A clear and concise MOA was established between JPO and AFSPC on responsibilities related to the control of Block II SVs when in orbit, especially when the JPO wanted to conduct system tests: e.g., deficiency report resolution verification, CS upgrade verification, the Y-sensor system level test, etc. The SV constellation baseline had been 18 satellites, based upon funding issues early in the program that had reduced the constellation from the original 24-constellation configuration. In 1987, detailed systems engineering analysis was conducted to determine the limitations of the 18-satellite constellation configuration. The JPO then briefed the limitations of the 18-satellite constellation to the operating commanders, on-site, at various locations around the world. Messages were soon received from these commands stating that the limitations of the 18-satellite constellation were not acceptable and that a larger constellation configuration should be pursued. During this timeframe, the Air Force initiated a trade study of cost-versus-performance and was interested in reducing the constellation to a two-dimensional 12-satellite configuration and queried the JPO about approach. The JPO already had the answer in terms of current 18- constellation limitations and what the real warfighter needed. The requirement driven by operational commands became a 24-satellite constellation and the Air Force would provide funding to support this requirement [11, Green]. This appears to be one of the first times that the operational commands became advocates of the program.

Trade studies and additional system assessments of the 24-constellation configuration were conducted by the JPO with technical assistance from Aerospace Corporation. Drs. Rhodus and Massatt of Aerospace Corporation, in coordination with the JPO, conducted an analysis of the constellation configuration. They considered configurations that were less sensitive to satellite drift and would be more robust during multiple satellite failures, resulting in an asymmetrical design of the SVs location – see Figure 3-19 (Ref. 18). The functional baseline was updated for the latest satellite constellation configuration (Ref. 18).

66

Figure 3-19. 24-Satellite Constellation (Ref. 49) 3.5.7 Requirements Validation & Verification

The JPO and Rockwell jointly established a Satellite Test Criteria Review Board (TCRB), which conducted a rigorous review of all SV qualification and acceptance testing during Block I [23, Robertson]. The TCRB was a contractual solution due to the JPO last-minute substitution of MIL-STD-1540A for MIL-STD-1540 (Test Requirements for Launch, Upper- Stage and Space Vehicles) in the Block I contract. Rockwell apparently did not realize the change, and the satellite and vendor programs were not in compliance [21, Reaser]. Weekly well-structured meetings were conducted with extensive efforts to validate qualification requirements and determine the root cause before concurrence or approval to proceed to the next event. The board consisted of the JPO, prime contractors, vendors, and Aerospace Corporation personnel, with the JPO contracting office chairing the meetings [21 Reaser; 23 Robertson].

OT&E could not be conducted on the SV. There was a need to conduct joint DT&E and OT&E. This joint test and evaluation were somewhat unique in this timeframe for the rocket community and required close coordination with AFOTEC. The key to making and executing the plan was AFOTEC. They helped ensure early identification of acceptance criteria [18, Paul]. 3.6. Replenishment Program Block IIR

3.6.1 Objective

The Block IIR objective was to provide 21 replacement satellites for the Block II/IIA. Also included were enhancements such as enhanced autonomy, 180-day degradation, increased radiation hardening, cross-link ranging, hot-backup of clocks, and modernization of parts.

3.6.2 Acquisition Strategy

In accordance with the DSARC II direction to compete the SV contract when the design stabilized, the JPO developed a competitive acquisition strategy. In typical JPO contractual fashion, risk mitigation was factored into the strategy. The existing satellites were basically designed with late 1960s, 1970s, and some early 1980s technologies. Part of the modernization was to optimize the navigation payload/bus system. For the modernization of the SV navigation

67

payload/satellite bus, three fixed-price contracts were issued: ITT, Rockwell Autonetics, and Garmin to develop breadboard designs.

The JPO issued two fixed-price contracts for the SV segment design, one each to Rock-

well International and General Electric Aerospace. The contractors were to design up to a PDR and then there would be a down-select. A caveat was added to this effort: The SV segment con- tractors were allowed to team with the three vendors developing the breadboard designs for the navigation payload/bus system. RI teamed with Autonetics and Garmin, and GE with ITT. The down-select occurred, and General Electric Aerospace was awarded the SV contract on 21 Jun 1989. (Note: Lockheed Martin acquired General Electric Aerospace in 1992). The JPO strategy of competing initial phases of the program had a significant benefit with respect to produceability of the Block IIR satellites. Piece parts were reduced by approximately half and touch labor by approximately two thirds [23, Robertson]. This approach utilized classic systems engineering principles of conducting detailed trade studies and prototyping prior to PDR to validate the design concept capability to meet the functional baseline in the most cost-effective manner. The competition among vendors/contractors was the forcing function to this process.

3.6.3 Requirements

HQ AFSPC acted as the centralized user for the GPS program in terms of coordinating and integrating user requirements. They established the survivability requirement that was a tech- nology challenge for the program. The increased requirements for hardening in case of nuclear detonation in space were beyond the effects of the Van Allen belt radiation requirement. This hardening requirement was identified as a risk from the initiation of the effort, and a technology development program was initiated to create hardened processor chips to the levels identified in the requirement. Once the technology solution of silicon-on-sapphire was identified, a further problem of yield rate for growing the crystals was addressed and successfully resolved [23, Robertson].

3.6.4 Critical Design Reviews

In Block 2R, the typical JPO philosophy of risk mitigation was applied in that the SV segment was competed between Rockwell International and General Electric Aerospace. Two fixed-fee contracts were issued for development up through PDR. A down-select was accomplished and General Electric won the contract. The governing requirements document for the initial contract was the Block 2R TRD developed by the JPO. The TRD was a carryover as the governing system segment document through the initial portion of the effort because of an issue with the requirement for the NDS W-sensor to operate through a nuclear event in space. General Electric wanted the system segment specification to be written to allow the NDS to “blink”, or shutdown and restart, as an interpretation of the requirement. As a result of this non-resolution of the issue, the TRD remained the functional baseline document until after CDR [23, Robertson].

An unintended error in the contract tied the production option to both the CDR and its

scheduled date and not to the CDR event itself. This presented a dilemma to the JPO. The JPO assessed that General Electric was not ready for the CDR. Yet, slippage had a major impact on the production price option, and the JPO did not want to reopen negotiations. The decision made was to conduct the CDR and exercise the option. The CDR was officially closed with numerous action items. The risk mitigation plan was to conduct monthly technical interchange meetings to further assess the design to the allocated baselines and to address outstanding action items [23, Robertson]. Certain programmatic decisions made during the course of a development program may be beyond

68

the classic systems engineering process. The systems engineering process must be flexible enough to adapt to these conditions and continue to ensure compliance with requirements and risk avoidance/mitigation. In this case, the design risk was mitigated by the continuance of a structured process to track the major CDR action items and ensure that the intent of a MIL-STD-1521-type CDR was closed at a later time. Additionally, the risk of design fabrication was identified and monitored during this period.

3.6.5 User Equipment

In the late 80s and early 90s, some of the users began to investigate the applicability of commercial GPS receiver designs to be adapted to the requirements. The Army had purchased the commercial Small Lightweight GPS Receiver (SLGR) in 1989 for demonstration and training, and it was not intended to be used in a non-tactical scenario. The manpack was approxi- mately 8 inches by 12 inches by 18 inches and battery operated, which increased the weight. It was not very user friendly to the soldier from the field standpoint, although it met the Army’s performance requirements [14, Krishnamurti]. “To reach a general agreement that an NDI (Non- Development Item) strategy was feasible, the Army had to make tradeoffs in its requirements.

The commercial products were not expected to match the performance of the AN/PSN-8

manpack, even if the selective availability and anti-spoof modifications were incorporated. Accordingly, the Army amended its 1979 requirement for the manpack to take advantage of commercial GPS technology. The intent of the changes was to get a system, as an off-the-shelf item, that would meet minimum essential requirements, be affordable, be available in the near term, and be easy to operate. The challenge was to avoid letting ‘better’ be the enemy of ‘good enough’ by curbing the desires of the design engineers to optimize performance” (Ref. 32). The JPO and Army still required the selective availability and the anti-spoofing capability, which was not a capability in the commercial industry. Some minor modification of the design would be required to meet this performance [14, Krishnamurti]. “During the period November 1990 through June 1991, a government performance specification was coordinated with industry and the government. Several industry responses indicated that a product that would meet the PLGR requirement could be available by September 1991” (Ref. 32). Contract award was made to Rockwell International, Collins Avionics and Communications Division, in March 1993. Table 3-9 describes the requirements of the PLGR compared to the Army requirements. Figure 3-20 provides a clear indication of the trend toward non-developmental items (NDI) in some areas of GPS receivers.

Table 3-9. Army and PLGR Requirements (Ref. 32) System Description Characteristic Winning Receiver Requirement Size Less than 90 in3 Less than 125 in3 Weight Less than 4 pounds Less than 4 pounds Power Less than 3 watts 3 Watts Mean time between failure 18,500 hours 18,500 hours

69

Battery life 10 hours 10 hours

Military-unique features Full selective availability Full anti-spoofing Full selective availability Full anti-spoofing

Type of operation Hand operated Hand operated Position, velocity and time @ 100 meters/sec, 2G acceleration 18 meters 18 meters

Time to first fix Less than 3 min. Less than 5 min. Time to subsequent fix Less than 1 min. Less than 1 min. Operating temperature -20o to +60oC -20o to +70oC Service life 6 year performance/ reliability warranty 5 year performance and reliability

Unit cost $1,300 in base and first option years; $772 in last option year N/A

Figure 3-20. DoD of UE Family Tree Collins Manpack (Ref. 35) 3.7 Full Operational Capability

After starting out as a vague new idea to utilize the new space frontier for navigation after the launch of Sputnik I, separate technology efforts and studies resulted in a functional baseline being established in 1973 for a more accurate and reliable means of worldwide navigation. Nearly 20 years later on 17 April 1995, Air Force Space Command declared GPS fully operational. The system would eventually accomplish one of the DoD’s major goals of consolidating suites of military navigation systems.

The system was successfully “battle-tested” in the Persian Gulf War years before the

Initial Operational Capability (IOC) and proved the operational capability worthy of the program visionaries from the late 1960s .

70

The JPO was able to successfully establish themselves as system integrators and

controller of the functional baseline. With the assistance of Aerospace Corporation, they were able to conduct the necessary system trade studies to optimize the functional baseline as enhanced requirements were identified and budgets changed. Using the baselined structured signal as the key interface, a specification tree was established based upon the interface of those signals with the three major segments. Through the well-honed interface control process, the JPO was able to manage all the segment specifications and system integration. On the contractors’ side and many other supporting government agencies, domain expertise existed at all levels which enabled personnel to see the system vision and perform their systems engineering process with success. Communications was a key ingredient that was fostered throughout GPS development.

71

4. SUMMARY

The GPS program presented challenges in various areas such as technology, customers, organization, cost, and schedule for a very complex navigation system. This system has become a beacon to military and civilian navigation and other unique applications. As best put by Gedding, GPS provides “a constellation of lighthouses in the sky …” (Ref. 8).

Several precepts or foundations of the Global Positioning Satellite program are the rea- sons for its success. These foundations are instructional for today’s programs because they are thought-provoking to those who always seek insight into the program’s progress under scrutiny. These foundations of past programs are, of course, not a complete set of necessary and sufficient conditions. For the practitioner, the successful application of different systems engineering processes is required throughout the continuum of a program, from the concept idea to the usage and eventual disposal of the system. Experienced people applying sound systems engineering principles, practices, processes, and tools are necessary every step of the way. Mr. Conley, formerly of the GPS JPO, provided these words: “Systems engineering is hard work. It requires knowledgeable people who have a vision of the program combined with an eye for detail.”

Systems engineering played a major role in the success of this program. The challenges of integrating new technologies, identifying system requirements, incorporating a system of systems approach, interfacing with a plethora of government and industry agencies, and dealing with the lack of an operational user early in the program formation required a strong, efficient systems engineering process. The GPS program imbedded systems engineering in their knowledge-base, vision, and day-to-day practice to ensure proper identification of system requirements. It also ensured the allocation of those requirements to the almost-autonomous segment developments and beyond to the subcontractor/vendor level, the assessments of new requirements, innovative test methods to verify design performance to the requirements, a solid concept of operations/mission analysis, a cost-benefit analysis to defend the need for the program, and a strong system integration process to identify and control the “hydra” of interfaces that the program encountered. The program was able to avoid major risks by their acquisition strategy, the use of trade studies, early testing of concept designs, a detailed knowledge of the subject matter, and the vision of the program on both the government and contractor side.

72

5. QUESTIONS FOR THE STUDENT The following questions are meant to challenge the reader and prepare for a case discussion.

Is this program start typical of an ARPA/ DARPA funded effort? Why or why not? Have you experiences similar or wildly different aspects of a Joint Program? What were some characteristics that should be modeled from the JPO? Think about the staffing for the GPS JPO. How can this be described? Should it be duplicated in today’s programs? Can it? Was there anything extraordinary about the support for this program? What risks were present throughout the GPS program. How were these handled? Requirement management and stability is often cited as a central problem in DoD acquisition. How was this program like, or dislike, most others? Could the commercial aspects of the User Equipment be predicted or planned? Should the COTS aspect be a strategy in other DoD programs, where appropriate? Why or why not?

73

6. REFERENCES

1. The Contribution of Navigation Technology Satellites to the Global Positioning System, Naval Research Lab Washington DC, 28 Dec 1979, DTIC ADA080548, pages 5, 15

2. Application of the NAVSTAR to the Network Synchronization of the DCS (Defense

Communications System) Defense Communications Engineering Center Reston VA, 1 Mar 1987, DTIC ADA181457

3. Cost Analysis of Navy Acquisition Alternatives for the NAVSTAR Global positioning

System, Naval Postgraduate School, Monterey CA, Dec 1982 ADA 125017

4. Command and Control Functions and organizational Structure Required to Support the NAVSTAR/Global Positioning System, Naval Postgraduate School, Monterey CA, Jun 1980, ADB051422

5. Impact of NAVSTAR Global positioning System on military Plans for Navigation and

Positioning Fixing Systems, Institute for Defense Analyses Alexandria VA, Oct 1975, ADB011137

6. Global Positioning System: Theory and Applications Vol I & Vol II, Edited by Bradford

W Parkinson and James J. Spilker, Volume 163 and 164, Progress in Astronautics and Aeronautics.

7. FAA Acceptance Tests on the Navigation System Using Time and Ranging Global

positioning System Z-set Receiver, Federal Aviation Administration Technical Center, Atlantic City, Airport, NJ 08405, Jul 1982, ADA119306

8. All in a Lifetime, Science in the Defense of Democracy, Ivan A. Getting, Vantage Press,

Copyright 1969.

9. Genesis of Satellite Navigation, William H Geier and George C. Weiffenbach, John Hopkins APL Technical Digest, Vol 19 No1, 1998

10. FAS Space Policy Project, Military, Space Programs, Transit

http://www.fas.org/spp/military/program/nav/transit.htm

11. An Overview of TRANSIT Development, Robert J. Danchik, John Hopkins APL Technical Digest, Vol 19 No1, 1998

12. HQ USAF Program Management Directive for Satellite System for Precise Navigation,

19 Jul 72.

74

13. Development Concept Paper, Number 133, NAVSTAR Global Positioning System 15 Apr 1974, Approved by Deputy Secretary of Defense 11 May 74.

14. Global Positioning System Control/User Segment System/Design Trade Study Report,

General Dynamics Corp, San Diego CA, 28 Feb 1974, AD921522

15. GPS Eyewitness: The Early Years, Bradford Parkinson, GPS World September 1994

16. Report from the Guidance and Control Panel Working Group 04 on the Impact of Global Positioning System on Guidance and Controls Systems Design for Military Aircraft Vol I, Advisory Group for Aerospace Research and Development Sep 1979

17. Defense Standardization Program, SD-2 Buying Commercial & Non-developmental

Items: A Handbook, 1 April 1996, Appendix C – Case Study 1: The Precision Lightweight GPS Receiver, http://dsp.dla.mil/documents/sd-2/appendix-c.htm

18. Retuning the GPS Constellation, 1999, Performance Analysis Working Group, Capt

Michael Violet, 2SOP/DOAS, http://www.fas.org/spp/military/program/nav/gps.ppt#266,9,GPS Constellation History

19. Global Positioning System Control/User Segment System Design Trade Study Report

General Dynamics Corp, San Diego CA, 28 Feb 74, AD9211522 & AD9211523

20. Brad Parkinson, An Interview Conducted by Michael Geselowitz, Nov 2 1999, Interview 379, for the History of Electrical Engineering the Institute of Electrical and Electronics Engineers, Inc. and the Rutgers, State University of New Jersey (http://www.ieee.org/portal/cms_docs_iportals/iportals/aboutus/history_center/oral_histor y/pdfs/Parkinson379.pdf)

21. NAVSTAR, http://www.astronaux.com/Project/NAVSTAR.htm

22. NAVSTAR: Global Positioning System-10 Years Later, 10 Oct. 1983, Proceedings of the

IEEE Vol. 71, No. 10

23. TIMATION and GPS History, http://NCST- www.NRL.Navy.mil/NCSTOrigin/TIMATION.html

24. DoD Directive 5160.51, 31 August 1971

25. Satellite Geodesy, http://www. NGS.NOAA.gov/PUBS-LIB/Geodesy 4

Layman/TR80003D.htm

26. Modernization of GPS: Plans, New Capabilities and Future Relationship to Galileo, Keith McDonald, Journal of GPS, Vol. 1, No. 1, 1-17; http://www.gmat.unsw.edu.au/wang/jgps/vlnl/vlnlpA.pdf

75

27. Central Pacific International Technology, http://www.cpit.com/en/history.html

28. SS-GPS-101B, System Specification for the NAVSTAR , Global Positioning System, Phase I, 15 Apr 1974

29. Briefing Engineering and Integration Approach, No Date (~2001-2002), Col. Rick

Reaser, Deputy System Program Director (GPS)

30. Office of Secretary of Defense (OSD) Memo, The NAVSTAR GPS, 24 August 1979

31. Satellite Acquisition, Global Positioning System, GAO/NSIAD-8-209 BR, September 1987

32. Defense Standardization Program, SD-2-Buying + Non-developmental Items: A

Handbook, 1 April 1996, Appendix C – Case Study 1: The Precision Lightweight GPS Receiver; http://dsp.dla.mil/documents/sd-2/appendix-c.htm

33. NAVSTAR, Global Positioning System (GPS), User Equipment, Novella on DoD User

Equipment, 30 June 1996; http://www.FAS.ORG/SPP/Military/Program/NAV/UEOVPR.htm

34. Presidential Directive/PD/NSC-42, Civil and Further National Space Policy, October 10

1978, http://www.globalsecurity.org/space/library/policy/national/nsc-42.htm

35. Dr. Gernot Winkler’s comments on the review of this draft report, 27 April 2007

36. NAVSTAR Global Positioning System (GPS) Navigation Technology System Segment Management Plan, July 1975

37. Dick Schwartz’ comments on the review of this draft report, 22 April 2007

38. GOA/NSIAD-91-74, Should Be limited Until Receiver Reliability Problems Are

Resolved, Mar 1991 Global Positioning System

39. Integrated Multiservice Test and Evaluation Management Plan for NAVSTAR GPS, Oct 1991, Change 2, 1 Jul 1993,

40. GPS Acquisition Program Baseline, NAVSTAR GPS, 8 Aug 2000

41. YEE-83-001, YEE Configuration Management Plan for NAVSTAR Global Positioning System, 3 Feb 1983

42. NAVSTAR User Equipment Introduction, Sep 1996

http://www.navcen.uscg.gov/pubs/gps/gpsuser/gpsuser.pdf,

76

43. ICD-GPS 209, 1 December 1983, Interface Control Document for the Control Station/Air Force Satellite Control Facility Interfaces of the NAVSTAR GPS Operational Control System Segment, Co tract F04701-80-0011, CII 793911, 8 May 84

44. YEN 78-312A, Technical Requirements Document for Phase III Space Segment of the

NAVSTAR Global Positioning System, 21 Nov 1979

45. https://gps.army.mil/gps/CustomContent/gps/ue/dagr.html

46. Wikipedia, http://en.wikipedia.org/wiki/Global Positioning System

47. The Institute of Navigation, Navigation Museum http://www.ion.org/museum/item_view.cfm

48. http://www.fas.org/spp/military/program/nav/uenovpr.htm

49. Nuclear Detonation (NUDET) Detection System (NDS) Characterization Test Plan, Air

Force Material Command, Space and Missile System Center/CZ, NAVSTAR Program Office, 1 December 1993

50. Kernco Inc website, http://www.kernco.com/index.php?page=cesium

51. Los Angeles Air Force Base website

http://www.losangeles.af.mil/smc/smc%20homepage/gpswing.doc

77

78

7. LIST OF APPENDICES

Appendix 1 – Complete Friedman-Sage Matrix for GPS Appendix 2 – Author Biographies Appendix 3 – Interviews Appendix 4 – Navigation Satellite Study Appendix 5 – Rockwell’s GPS Block I design and development team org chart Appendix 6 – GPS JPO Organization Chart Appendix 7 – Operational Performance Requirements

p p y 1. Contractor Responsibility 2. Shared Responsibility 3. Government Responsib A. A. Requirements

Definition and Management

Contactors were responsible for the allocated baseline.

Industry conducted trade studies in response to JPO taskings.

The JPO defined the overall top level. They controlled the satell structure, overall error budget, a reviewed and approved by the JP

B. B. Systems Architecture and Conceptual Design

For each segment, the contractor controlled the system architecture within the segment.

The Air Force and contractor team jointly developed the mechanization of the signal structure and its implementation

The JPO established the basic ar 1960s Air Force studies accomp validated by TRANSIT and TIM architecture with a comprehensiv controlled interfaces, designs an

C C. System and Subsystem Detailed Design and Implementation

Each segment contractor developed their own part II specs, the allocation to their vendors (e.g. EE&G for atomic clocks) and implementation of their own Systems engineering process.

System level trade sponsored by the JPO affected the segment designs and required close coordination between the two parties to reach closure. e.g. constellation change from 21 to 18

Government intermittently invol the ICWG process. Highlighted requirements could cause increa detailed designs/products were r

D. D. Systems Integration and Interface

The contractors were responsible for the ICDs within there segment. Supported the ICWGs for segment to segment ICDs.

Industry/government jointly developed the interface physical and functional definition. Incompatibilities were jointly resolved; risk was balanced against the functional baseline by the JPO

The JPO was Prime Systems Int for the Interface Working Group Configuration Control Board (C and made final decisions on app

E. Validation and Verification

Extensive laboratories and simulations were employed for testing to verify integration of components, subassemblies, and subsystems. IBM with Rockwell simulator validated upload, transmit and receive of signals at Cape Canaveral. Contractors developed test plans/procedures to verify final product met the specified requirements and conducted the testing in accordance with these plans/procedures.

Joint board established with participation of JPO, Aerospace Corporation, contractor, and vendor to track and resolve issues during qualification and acceptance testing.

The JPO was responsible for app final testing to meet specificatio validation using pseudolites on a signal concept. JPO was respon testing at Yuma Proving Ground

F. Deployment and Post Deployment

Life and accuracy performance of the constellation far exceeded the estimated design life.

Constellation updates and enhancements continue through the current program office and industry team. Acquisition strategy for replacement SVs using Block upgrades, e.g. IIR, IIF and III

The Air Force established Falco Control Center. GPS now unive baseline. Commercial drove pot

G. Life Cycle Support Minimal contractor support after launch. Software upgrades, orbit changes and response to on-orbit failures. Maintenance and operator TOs developed for CS

On going joint management of the constellation

Satellite life and software upload

H. Risk Assessment and Management

Risk planning and management was disciplined and managed at the appropriate responsibility level

The contractor government team decided jointly on both types of risk solutions.

The program office was respons trades

I. System and Program Management

Fully cooperative to the program office strategy. Although they were segment contractors, they approach the design form a system point of view. Contractors aligned organization to parallel JPO organization for improved communications.

Domain experts on the combined government and industry team were present in all the key positions

JPO provided the functional bas and the mandate “to put 5 bomb

69

Appendix 2 – Author Biographies

PATRICK J. O’BRIEN Mr. O’Brien is a retired Civil Servant and Systems Engineer employed by the University of Dayton Research Institute (UDRI) as a Senior Research Engineer. He provides technical expertise in the areas of cargo aircraft aerial delivery systems and systems engineering. Experience/Employment Highlights:

• Senior Project Engineer to the Air Force Flight Research Laboratory, Wright- Patterson Air Force Base, Ohio

o Aerial Delivery expertise on the C-17 aircraft airdrop and air-launch of the DARPA Quick Reach FALCON Rocket program

• C-17 System Program Office Flight Systems Engineer (Acting), Technical Lead Wright-Patterson Air Force Base, Ohio

• C-17 System Program Office Mission System Technical Lead, Wright- Patterson Air Force Base, Ohio

• Lead Systems Integration Engineer the B-1B Conventional Mission Upgrade Program (CMUP), Wright-Patterson Air Force Base, Ohio

• Chief Support Systems Engineer (CSSE) for the B-1B CMUP, Wright-Patterson Air Force Base, Ohio

• CSSE for the National Aero-Space Plane (NASP) program, Wright-Patterson Air Force Base, Ohio

• Technical Management Specialist for the Directorate of Support Systems Engineering, Wright-Patterson Air Force Base, Ohio

• Senior Cargo Aerial Delivery Engineer and Group Leader, Air Transport Test Loading Agency, Wright-Patterson Air Force Base, Ohio

• Chairman of the Joint Logistics Commander’s Joint Technical Airdrop Group, Wright-Patterson Air Force Base, Ohio

• Principal Air Force System Command member to NATO Air Transport Working Party

Honors/Awards:

• Outstanding Civilian Career Service Award, 2004 • Exemplary Civilian Service Award, 2004 • US Army Superior Civilian Service Award, 2003 • ASC/EN Outstanding Career Achievement Award, 2003

Education:

• B.S. Aero-Space Engineering, University of Notre Dame, 1971

JOHN M. GRIFFIN John Griffin is President, Griffin Consulting, providing systems engineering and program

management services to large and mid sized aerospace firms. He provides corporate strategy planning initiatives for company CEOs, reviews ongoing programs to assess progress and recommend corrective actions, and participates as an integral member of problem solving teams. He is active in numerous leading-edge technologies and advanced system development programs.

Experience/Employment Highlights: • Director of Engineering, Kelly Space and Technology, Inc, San Bernardino, CA

o Conceptual design process of a space launch platform • Director, Development Planning, Aeronautical Systems Center, Wright-Patterson

Air Force Base, OH • Chief Systems Engineer, Engineering Directorate • Director of Engineering, B-2 Spirit Stealth Bomber, B-2 System Program Office • Engineering leadership land management from inception through 1st flight • Source Selection Authority for two source selections • Chief engineer, F-15 Eagle Fighter • Chief Airframe Engineer, F-16 Fighting Falcon • Chief Airframe Engineer, Air Launched Cruise Missile

Honors/Awards: • Two Meritorious Service Medals • Distinguished Career Service Medal for his 37 years of achievement, 1997 • Pioneer of Stealth, 1998

• University of Detroit Mercy; Engineering Alumnus of the Year, 2002 . Education:

• University of Detroit, Detroit MI, 1964: Bachelor of Aeronautical Engineering • Air Force Institute of Technology, WPAFB OH, 1968: MS of EE • Massachusetts Institute of Technology, Cambridge MA, 1986: Senior Executive

Sloan Program Affiliations:

• Founder (1993) and President (1993-1997), Western Ohio Chapter Senior Executive Association.

• Co-founder (1995) & President (1996-1997), Defense Planning and Analysis Society.

71

72

Appendix 3 – Interviews The company affiliation and positions are those held on the GPS during the timeframe of the case study. Alphabetical list of interviews include:

1. Ron Beard, TIMATION Program Manager, NRL 2. John Berg, Aerospace Corporation, Control Segment Engineer 3. Rob Conley, Air Force, Test, Control Segment and Systems Engineering 4. Tom Donahue, Air Force, System Test Director Systems Engineering Division 5. Dr. Malcolm Currie, Office of Secretary of Defense, Director of DDR&E, 6. Don Duckro, Air Force, Space Vehicle Engineer 7. Sherman Francisco, IBM, 8. Hugo Frueholf, Rockwell, Chief Engineer, Block I 9. Stevie Gilbert, Air Force, Deputy System Program Director 10. John Gravitt, Air Force, Control Segment & Systems Engineering 11. Gaylord Green, Air Force, Air Force Chief of Space Vehicle & System Program Director 12. Jerry Holmes, Texas Instruments, User Equipment Engineering 13. Bill Kaneshiro, Air Force, Systems engineering 14. Geddi Krishnamurti, Rockwell Collins, Project Engineer thru Director of Navigation &

Mission Management Systems 15. Don Latterman, Air Force, Upper Stage Engineering & Chief Engineer 16. Russ Nakamura, Air Force, Control Segment Chief, Program Element Manager 17. Dr. Brad Parkinson, Air Force, System Program Director 18. Mike Paul, Air Force, Test Director and User Equipment Integrator 19. Ed Powers, Naval Research Laboratory & Naval Observatory 20. Preston Prouty, Aerospace Corporation, Control Segment Engineer 21. Rick Reaser, Air Force, Satellite Vehicle and Deputy Program Director 22. Jim Reynolds, Air Force, Systems Program Director 23. Doug Robertson, Air Force, Launch Program & Space Vehicle Manager 24. Joe Saad, Air Force, Division Chief User Equipment, Director System Effectiveness,

Manager Ground Systems 25. John Scheerer, Air Force, Director Systems engineering & previous Deputy of Space

Segment 26. Dick Schwartz, Rockwell, Program Director 27. Jess Sponable, Air Force, Space Vehicle, Launch Vehicle Interface 28. Tom Stansell, Magnavox, User Equipment Engineering 29. Phil Ward, Texas Instruments, User Equipment Engineering 30. Joe White, Naval Research Laboratory, Atomic Clocks 31. Dr. Gernot Winkler, Naval Observatory, Senior Executive Service

Appendix 4 – Navigation Satellite Study

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

Appendix 5 – Rockwell’s GPS Block 1 Organization Chart

123

Appendix 6 – GPS JPO Organization Chart

124

Appendix 7 – Operational Performance Requirements

125

126

127