|
|
Line 1: |
Line 1: |
− | The Global Positioning System (GPS) case study was developed by the United States Air Force Center for Systems Engineering (AF CSE) located at the Air Force Institute of Technology (AFIT). The GPS is a space-based radio-positioning system. A constellation of twenty-four satellites, including three spares, comprise the overall system which provides navigation and timing information to military and civilian users worldwide. GPS satellites, in one of six Earth orbits, circle the globe every twelve hours, emitting continuous navigation signals on two different L-band frequencies. The system consists of two other major segments: a world-wide satellite control network, and the GPS user equipment that can either be carried by a human user or integrated into host platforms such as ships, vehicles, or aircraft.
| + | ---- |
− | | + | '''''Lead Authors:''''' ''Rick Adcock, Sanford Friedenthal'' |
− | This case study discussion is based on the original source (O’Brien and Griffin 2007) which provides useful insights into what we might consider a "traditional" SE application. A second [[Global Positioning System Case Study II]] looks at the same case study from a broader perspective.
| + | ---- |
− | | + | In this Knowledge Area, we introduce the following key principles: life cycle, life cycle model and life cycle processes. A generic SE paradigm is described; this forms a starting point for discussions of more detailed life cycle knowledge. |
− | ==Domain Background==
| |
− | | |
− | When looking at the Global Positioning System (GPS), it would be difficult to imagine another system that relie s so heavily upon such a wide range of domains, with the possible exception of the World Wide Web (WWW). Additionally, the various systems operating within these domains must all function together flawlessly to achieve success. It is evident from reading this case study that it directly relates to the following domains:
| |
− | | |
− | * aerospace;
| |
− | * space;
| |
− | * communications; and
| |
− | * transportation.
| |
− | | |
− | This is also an example of [[System of Systems (SoS) (glossary)|systems of systems]] (SoS) and is considered an innovative technology.
| |
− | | |
− | The GPS case study includes a detailed discussion of the development of the GPS and its components, as well as other applicable areas. The reader of this study will gain an increased understanding of the effect that GPS has on military and commercial industries in the context of the systems engineering support required to achieve success.
| |
− | | |
− | ==Case Study Background==
| |
− | | |
− | The United States Air Force Center for Systems Engineering (AF CSE), established in 2002 at the Air Force Institute of Technology (AFIT), was tasked to develop case studies focusing on the application of systems engineering principles within various aerospace programs. The GPS case study (O'Brien and Griffin 2007) was developed by AFIT in support of systems engineering graduate school instruction. The cases are structured using the Friedman-Sage framework (Friedman and Sage 2003; Friedman and Sage 2004, 84-96), which decomposes a case into contractor, government, and shared responsibilities in the following nine concept areas:
| |
− | | |
− | # Requirements Definition and Management
| |
− | # Systems Architecture Development
| |
− | # System/Subsystem Design
| |
− | # Verification/Validation
| |
− | # Risk Management
| |
− | # Systems Integration and Interfaces
| |
− | # Life Cycle Support
| |
− | # Deployment and Post Deployment
| |
− | # System and Program Management
| |
− | | |
− | The Friedman-Sage framework (2004) is provided in Appendix A of the case study. This case study is an example where the government - specifically the JPO Systems Engineering Directorate - bore the responsibility for systems integration and configuration management. That is, the government played more than an oversight role in the systems engineering of the GPS system of systems. As mentioned in the case study, JPO developed the CONOPs, mission analysis, requirements and design analysis including security, and developed their own approach to the cryptology methodology. JPO coordinated the Configuration Control Board (CCB) chaired by the Program Director. JPO was also responsible for Level I ICDs and system design configurations; where the contractors were responsible for the system architecture and ICDs within their segment.
| |
− | | |
− | ==Case Study Description==
| |
− | The “Global Positioning System - Systems Engineering Case Study” describes the application of systems engineering during the concept validation, system design and development, and production phases of the GPS program (O'Brien and Griffin 2007). The case examines the applied systems engineering processes, as well as the interactions of the GPS joint program office (JPO), the prime contractors, and the plethora of government agencies that were associated with the program’s development and fielding. The systems engineering process is traced from the initiation of studies and the development of key technologies, which established the vision of a satellite navigation system in the 1960s, through to the multiphase joint-program that resulted in a fully operational capability release in 1995. This case study does not cover system enhancements incorporated through Blocks IIM, IIF, and III.
| |
− | | |
− | The GPS case study derived four learning principles (LPs) that explain the more broadly applicable areas of systems engineering knowledge that are addressed by the case study. These four LPs relate strongly to the SEBoK in the following areas:
| |
− | | |
− | *[[Enabling Individuals|enabling individuals]] (LP1);
| |
− | *[[Configuration Management|configuration management]] (LP2);
| |
− | *[[Enabling Businesses and Enterprises|enabling the organization]] (LP3); and
| |
− | *[[Risk Management|risk management]] (LP4).
| |
− | | |
− | Additionally, the GPS case study contains a thorough overview of [[Product and Service Life Management|life cycle management]] and exemplifies [[Systems Thinking|systems thinking]] principles.
| |
− | | |
− | ===Enabling Individuals===
| |
− | | |
− | ''Learning Principle 1'': Programs must strive to staff key positions with domain experts. | |
− | | |
− | From the program management team, to the systems engineering, design, manufacturing, and operations teams, the individuals on the program were well-versed in their disciplines and all possessed a systems view of the program. While communications, working relationships, and organization were important, it was the ability of the whole team at all levels to understand the implications of their work on the system that was vital. Their knowledge-based approach for decision making had the effect of shortening the decision cycle because the information was understood and the base and alternative solutions were accurately presented.
| |
− | | |
− | ===Configuration Management===
| |
− | | |
− | ''Learning Principle 2'': The systems integrator must rigorously maintain program baselines. | |
− | | |
− | The joint program office (JPO) retained the role of managing and controlling the system specification and, therefore, the functional baseline. The JPO derived and constructed a mutually agreed to set of system requirements that became the program baseline in 1973. While conducting the development program, the GPS team was able to make performance, risk, cost, and trade analyses against the functional baseline to control both risk and cost. The JPO was fully cognizant of the implications of the functional requirements on the allocated baseline because they managed the interface control working group process. Managing that process gave them first-hand knowledge and insight into the risks at the lowest level. The individual with the system integrator role must rigorously maintain the system specification and functional baseline. There must be appropriate sharing of management and technical responsibilities between the prime contractor and their government counterparts to ensure success.
| |
− | | |
− | ===Enabling the Organization===
| |
− | | |
− | ''Learning Principle 3'': Achieving consistent and continuous high-level support and advocacy helps funding stability, which impacts systems engineering stability. | |
− |
| |
− | Consistent, continuous high-level support provides the requirements and assists funding stability. In this role, the Office of the Secretary of Defense (OSD) provided advocacy and sourced the funding at critical times in the program, promoted coordination among the various services, and reviewed and approved the GPS JPO system requirements. The OSD played the central role in the establishment and survivability of the program. The GPS JPO had clear support from the Director of Defense Development, Research, and Engineering, Dr. Malcolm Currie, and program support from the Deputy Secretary of Defense, Dr. David Packard. Clearly, the armed services – particularly the Navy and the Air Force early on, and later the Army – were the primary users of GPS and the eventual customers. However, each armed service had initial needs for their individual programs, or for the then-current operational navigation systems. Additionally, the secretary of the Air Force provided programmatic support to supply manpower and facilities.
| |
− | | |
− | ===Risk Management===
| |
− | | |
− | ''Learning Principle 4'': Disciplined and appropriate risk management must be applied throughout the life cycle.
| |
− | | |
− | The GPS program was structured to address risk in several different ways throughout the multiphase program. Where key risks were known up front, the contractor and/or the government utilized a classic risk management approach to identify and analyze risk, as well as develop and track mitigation actions. These design (or manufacturing/launch) risks were managed by the office who owned the risks. Identified technical risks were often tracked by technical performance measures (such as satellite weight and software lines of codes) and addressed at weekly chief engineer’s meetings.
| |
| | | |
− | Serving in the clear role of program integrator allowed the JPO to sponsor risk trade studies at the top level. The JPO would issue study requests for proposals to several bidders for developing concepts and/or preliminary designs. Then, one contractor would be down-selected and the process would continue. This approach provided innovative solutions through competition, as well as helped in defining a lower risk, more clearly defined development program for the fixed-price contracts approach that was being used for development and production.
| + | ==Topics== |
| + | Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The Kas, in turn, are divided into topics. This KA contains the following topics: |
| + | *[[Generic Life Cycle Model]] |
| + | *[[Applying Life Cycle Processes]] |
| + | *[[Life Cycle Processes and Enterprise Need]] |
| + | See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3. |
| | | |
− | As the system integrator, the JPO was also closely involved with technical development. To identify unforeseeable unique technical challenges, the JPO would fund studies to determine the optimal approaches to new issues. There were schedule risks associated with the first launch due to unforeseen Block II issues with respect to the space vehicle and control segments (software development). Although a catastrophic event, the Challenger accident actually provided much needed schedule relief. Using decision analysis methodology led the JPO to an alternative approach to develop the expendable launch vehicle for the Block II satellites.
| + | ==Life Cycle Terminology== |
| + | The term {{Term|Life Cycle (glossary)}} is one that engineering has borrowed from the natural sciences; it is used to describe both the changes a single organism goes through over its life and how the lives of multiple organisms interact to sustain or evolve a population. We use it in engineering in the same ways to describe the complete life of an instance of a {{Term|System-of-Interest (glossary)}} (SoI); and the managed combination of multiple such instances to provide capabilities which deliver stakeholder satisfaction. |
| | | |
− | Good communication, facilitated by cooperative working relationships, was a significantly positive (though intangible) factor in the success of the GPS program, regardless of whether it was between the contractors and the government (JPO or other agencies), or between contractors and sub-contractors. A true team environment also played a significant role in reducing risk, especially considering the plethora of government agencies and contractors that were involved in the effort.
| + | A {{Term|Life Cycle Model (glossary)|life cycle model}} identifies the major {{Term|Stage (glossary)|stages}} that a specific SoI goes through, from its inception to its retirement. Life cycle models are generally implemented in development projects and are strongly aligned with management planning and decision making. |
| | | |
− | ===Life Cycle Management=== | + | ==Generic Systems Engineering Paradigm== |
| | | |
− | The GPS case study takes the reader through the initial concept of GPS (March 1942) all the way to the development, production, and operational capability of the system. The current GPS program traces its heritage to the early 1960s when Air Force Systems Command initiated satellite-based navigation systems analyses conducted by The Aerospace Corporation. The case study follows the execution of the GPS program from the inception of the idea to the full operational capability release on April 27th, 1995. The concentration of the case study is not limited to any particular period, and the learning principles come from various times throughout the program’s life.
| + | Figure 1 identifies the overall goals of any SE effort, which are: the understanding of stakeholder value; the selection of a specific need to be addressed; the transformation of that need into a system (the product or service that provides for the need); and the use of that product or service to provide the stakeholder value. This paradigm has been developed according to the principles of the [[Applying the Systems Approach|systems approach]] discussed in Part 2 and is used to establish a basis for the KAs in Part 3 and Part 4 of the SEBoK. |
| | | |
− | ===Systems Thinking===
| + | [[File:062211_BL_Paradigm.png|thumb|center|700px|'''Figure 1. Generic Systems Engineering Paradigm.''' (SEBoK Original)]] |
| | | |
− | The GPS case study highlights the need for systems thinking throughout. GPS satellites, in one of six Earth orbits, circle the globe every twelve hours. These satellites emit continuous navigation signals on two different L-band frequencies. The system consists of two other major segments: a world-wide satellite control network and the GPS user equipment that can either be carried by a human user, or integrated into host platforms such as ships, vehicles, or aircraft. The ability to conceive, develop, produce, field, and sustain the GPS demands the highest levels of systems thinking.
| + | On the left side of Figure 1, there are SoI's identified in the formation of a {{Term|System Breakdown Structure (glossary)|system breakdown structure}}. SoI 1 is broken down into its basic elements, which in this case are systems as well (SoI 2 and SoI 3). These two systems are composed of {{Term|System Element (glossary)|system elements}} that are not refined any further. |
| | | |
− | ==Summary==
| + | On the right side of Figure 1, each SoI has a corresponding {{Term|Life Cycle Model (glossary)|life cycle model}} which is composed of stages that are populated with processes. The function of these processes is to define the work that is to be performed and the associated artifacts to be produced. In a model-based approach, these artifacts are captured in the system model that represents the SoIs. Note that some of the requirements defined to meet the need are distributed in the early stages of the life cycle for SoI 1, while others are designated to the life cycles of SoI 2 or SoI 3. The decomposition of the system illustrates the fundamental concept of {{Term|Recursion (glossary)|recursion}} as defined in the ISO/IEC/IEEE 15288 standard; with the standard being reapplied for each SoI (ISO 2015). It is important to point out that the requirements may be allocated to different system elements, which may be integrated in different life cycle stages of any of the three SoI's; however, together they form a cohesive system. For example, SoI 1 may be a simple vehicle composed of a chassis, motor and controls, SoI 2 an embedded hardware system, and Sol 3 a {{Term|Software System (glossary)|software intensive}} interface and control system. |
| + | STOPPED HERE |
| + | When performing SE processes in stages, {{Term|Iteration (glossary)|iteration (glossary)}} between stages is often required (e.g. in successive refinement of the definition of the system or in providing an update or upgrade of an existing system). The work performed in the processes and stages can be performed in a {{Term|Concurrent (glossary)|concurrent}} manner within the life cycle of any of the systems of interest and also among the multiple life cycles. |
| | | |
− | The GPS case study is useful for global systems engineering learning and provides a comprehensive perspective on the systems engineering life cycle. The study is applicable for detailed instruction in the following areas:
| + | This paradigm provides a fundamental framework for understanding generic SE (seen in Part 3), as well as for the application of SE to the various types of systems described in [[Applications of Systems Engineering|Part 4]]. |
− | *[[Enabling Individuals|enabling individuals]];
| |
− | *[[Configuration Management|configuration management]];
| |
− | *[[Enabling Businesses and Enterprises|enabling the organization]];
| |
− | *[[Risk Management|risk management]];
| |
− | *[[Life Cycle Models|life cycle management]]; and
| |
− | *[[Systems Thinking|systems thinking]].
| |
− |
| |
− | The GPS case study revealed that key Department of Defense personnel maintained a clear and consistent vision for this unprecedented, space-based navigation capability. The case study also revealed that good fortune was enjoyed by the JPO as somewhat independent, yet critical, space technologies matured in a timely manner.
| |
| | | |
− | Although the GPS program required a large degree of integration, both within the system and external to the system amongst a multitude of agencies and contractors, the necessary efforts were taken to achieve success.
| + | ==References== |
− |
| |
− | Lastly, the reader of the GPS case study will gain an increased understanding of the effect that GPS has on the military and commercial industries in the context of the systems engineering support required to achieve success. The system was originally designed to help “drop five bombs in one hole” which defines the accuracy requirement in context-specific terms. The GPS signals needed to be consistent, repeatable, and accurate to a degree that, when used by munitions guidance systems, would result in the successful delivery of multiple, separately-guided munitions to virtually the identical location anywhere at any time across the planet. Forty to fifty years ago, very few outside of the military recognized the value of the proposed accuracy and most non-military uses of GPS were not recognized before 1990. GPS has increasingly grown in use and is now used every day.
| |
| | | |
− | ==References==
| |
| | | |
| ===Works Cited=== | | ===Works Cited=== |
− | Friedman, G.R. and A.P. Sage. 2003. Systems Engineering Concepts: Illustration Through Case Studies. January 19, 2003. Accessed September 2011. Available at: http://www.afit.edu/cse/docs/Friedman-Sage%20Framework.pdf.
| + | ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers.[[ISO/IEC/IEEE 15288|ISO/IEC 15288]], 2015. |
| | | |
− | Friedman, G. and A. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." ''Systems Engineering.'' 7(1): p. 84-96.
| + | ===Primary References=== |
− | | |
− | O’Brien, Patrick J., and John M. Griffin. 4 October 2007. Global Positioning System. Systems Engineering Case Study. Air Force Center for Systems Engineering (AFIT/SY) Air Force Institute of Technology (AFIT). 2950 Hobson Way, Wright-Patterson AFB OH 45433-7765
| |
| | | |
− | ===Primary References===
| + | INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc. ISBN: 978-1-118-99940-0. |
| | | |
− | O’Brien, Patrick J., and John M. Griffin. 4 October 2007. Global Positioning System. Systems Engineering Case Study. Air Force Center for Systems Engineering (AFIT/SY) Air Force Institute of Technology (AFIT). 2950 Hobson Way, Wright-Patterson AFB OH 45433-7765
| + | Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].'' London, UK: College Publications. |
| | | |
| ===Additional References=== | | ===Additional References=== |
− | none.
| + | None. |
| + | ---- |
| | | |
− | ----
| + | <center>[[Systems Engineering and Management|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Generic Life Cycle Model|Next Article >]]</center> |
− | <center>[[Hubble Space Telescope Case Study|< Previous Article]] | [[Case Studies|Parent Article]] | [[Global Positioning System Case Study II|Next Article >]]</center> | |
| | | |
| + | <center>'''SEBoK v. 2.1, released 31 October 2019'''</center> |
| | | |
− | [[Category: Part 7]][[Category:Case Study]] | + | [[Category: Part 3]][[Category:Knowledge Area]] |
− | {{DISQUS}}
| |
Lead Authors: Rick Adcock, Sanford Friedenthal
In this Knowledge Area, we introduce the following key principles: life cycle, life cycle model and life cycle processes. A generic SE paradigm is described; this forms a starting point for discussions of more detailed life cycle knowledge.
Topics
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The Kas, in turn, are divided into topics. This KA contains the following topics:
See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
Life Cycle Terminology
The term life cyclelife cycle is one that engineering has borrowed from the natural sciences; it is used to describe both the changes a single organism goes through over its life and how the lives of multiple organisms interact to sustain or evolve a population. We use it in engineering in the same ways to describe the complete life of an instance of a system-of-interestsystem-of-interest (SoI); and the managed combination of multiple such instances to provide capabilities which deliver stakeholder satisfaction.
A life cycle modellife cycle model identifies the major stagesstages that a specific SoI goes through, from its inception to its retirement. Life cycle models are generally implemented in development projects and are strongly aligned with management planning and decision making.
Generic Systems Engineering Paradigm
Figure 1 identifies the overall goals of any SE effort, which are: the understanding of stakeholder value; the selection of a specific need to be addressed; the transformation of that need into a system (the product or service that provides for the need); and the use of that product or service to provide the stakeholder value. This paradigm has been developed according to the principles of the systems approach discussed in Part 2 and is used to establish a basis for the KAs in Part 3 and Part 4 of the SEBoK.
Figure 1. Generic Systems Engineering Paradigm. (SEBoK Original)
On the left side of Figure 1, there are SoI's identified in the formation of a system breakdown structuresystem breakdown structure. SoI 1 is broken down into its basic elements, which in this case are systems as well (SoI 2 and SoI 3). These two systems are composed of system elementssystem elements that are not refined any further.
On the right side of Figure 1, each SoI has a corresponding life cycle modellife cycle model which is composed of stages that are populated with processes. The function of these processes is to define the work that is to be performed and the associated artifacts to be produced. In a model-based approach, these artifacts are captured in the system model that represents the SoIs. Note that some of the requirements defined to meet the need are distributed in the early stages of the life cycle for SoI 1, while others are designated to the life cycles of SoI 2 or SoI 3. The decomposition of the system illustrates the fundamental concept of recursionrecursion as defined in the ISO/IEC/IEEE 15288 standard; with the standard being reapplied for each SoI (ISO 2015). It is important to point out that the requirements may be allocated to different system elements, which may be integrated in different life cycle stages of any of the three SoI's; however, together they form a cohesive system. For example, SoI 1 may be a simple vehicle composed of a chassis, motor and controls, SoI 2 an embedded hardware system, and Sol 3 a software intensivesoftware intensive interface and control system.
STOPPED HERE
When performing SE processes in stages, iteration (glossary)iteration (glossary) between stages is often required (e.g. in successive refinement of the definition of the system or in providing an update or upgrade of an existing system). The work performed in the processes and stages can be performed in a concurrentconcurrent manner within the life cycle of any of the systems of interest and also among the multiple life cycles.
This paradigm provides a fundamental framework for understanding generic SE (seen in Part 3), as well as for the application of SE to the various types of systems described in Part 4.
References
Works Cited
ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers.ISO/IEC 15288, 2015.
Primary References
INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc. ISBN: 978-1-118-99940-0.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.
Additional References
None.
< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019