Risk Management Assess the methods used for identifying risk, using specific evidence to support your claims. For example, how

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 …

Running head: CASE STUDY HUBBLE SPACE TELESCOPE SYSTEMS ENGINEER 1

Running head: CASE STUDY HUBBLE SPACE TELESCOPE SYSTEMS ENGINEER 2