introduction

who?

gps_case_study.pdf

Home >Business & Finance homework help >Management homework help >introduction

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

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

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

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

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

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

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

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.

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

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

• 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.

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.

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].

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.

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

Pr ov

id ed

b y

H ug

o Fr

ue ha

Figure 2-3. Block I GPS Satellite

Pr ov

id ed

b y

H ug

o Fr

ue ha

Figure 2-4. Block IIA GPS Satellite

Pr ov

id ed

b y

H ug

o Fr

ue ha

Figure 2-5. Block IIR GPS Satellite

P ro

vi de

d by

H ug

o Fr

ue ha

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)

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.

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.

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.

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

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].

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.

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.

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.

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):

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 “2x2”, “3x3”, and “3x8” 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.

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

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

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

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.

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-

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%

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

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.

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-

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)

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.

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.

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.

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].

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].

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

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

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.

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

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.

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

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].

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 1x10-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

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.

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

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)

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

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

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.

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.

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

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].

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

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

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

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

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.

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

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.

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).

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).

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

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

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

http://dsp.dla.mil/documents/sd-2/appendix-c.htm

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 .

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.

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.

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?

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,

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.

http://www.fas.org/spp/military/program/nav/transit.htm

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

http://dsp.dla.mil/documents/sd-2/appendix-c.htm

http://www.ieee.org/portal/cms_docs_iportals/iportals/aboutus/history_center/oral_history/pdfs/Parkinson379.pdf

http://www.astronaux.com/Project/NAVSTAR.htm

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,

http://www.cpit.com/en/history.html

http://www.fas.org/SPP/Military/Program/NAV/UEOVPR.htm

http://www.globalsecurity.org/space/library/policy/national/nsc-42.htm

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

https://gps.army.mil/gps/CustomContent/gps/ue/dagr.html

http://en.wikipedia.org/wiki/Global

http://www.ion.org/museum/item_view.cfm

http://www.fas.org/spp/military/program/nav/uenovpr.htm

http://www.kernco.com/index.php?page=cesium

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

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.

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

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

SYSTEMS ENGINEERING PRINCIPLES
2. SYSTEM DESCRIPTION
3. GPS PROGRAM EXECUTION
4. SUMMARY
5. QUESTIONS FOR THE STUDENT
6. REFERENCES
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 1 Organization Chart
Appendix 6 – GPS JPO Organization Chart
Appendix 7 – Operational Performance Requirements