Page 1

SYSTEMS ENGINEERING



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



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

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

OCR for page 1
Page 1 SYSTEMS ENGINEERING

OCR for page 1
Page 2

OCR for page 1
Page 3 Systems Engineering Challenges of the International Space Station MARK D. JENKS Boeing Space and Communications Group Huntsville, Alabama The development of the International Space Station (ISS) has presented a variety of unique systems engineering challenges. Some are simply extensions of the classical integration issues encountered with any complex development project, but many are unique to ventures of the massive scale and scope of the ISS. Here I address these unique challenges, focusing on areas where traditional thinking may be either of limited value or, in some cases, counterproductive in understanding the critical issues associated with this class of very large-scale, technically and organizationally complex projects. PROGRAM OVERVIEW The ISS program may well be the largest single international engineering project in history. It involves the direct participation of 16 nations, 88 launches (37 Shuttle, 9 Proton, 31 Progress, and 11 Soyuz), and 160 space walks (over twice the total number of space walk hours completed by NASA since Ed White's initial walk in 1964). As of September 2000, the station consists of the Russian-built Zarya and Zvezda modules and the U.S.-built Unity Node. The station begins permanent operations with the arrival of the Expedition One crew in November 2000, and, once completed, will provide an unprecedented capability for cooperative international research—both publicly and privately funded. UNIQUE SYSTEMS ENGINEERING CHALLENGES While some of the program's challenges have no direct precedent, they are more than simply interesting case studies. The continued globalization of the

OCR for page 1
Page 4 world economy, the importance of space-based communication and defense systems, and the basic human drive to extend the boundaries of knowledge and achievement all suggest that large, complex multinational enterprises like the ISS will become increasingly important over the decades to come. The primary challenges identified for discussion here are (1) the extended development cycle, (2) unique test and verification requirements and constraints, and (3) the scale and complexity of the required infrastructure. EXTENDED DEVELOPMENT CYCLE For the typical commercial development project, minimizing time to market is often the critical challenge, and development cycles are measured in months (or even weeks). In contrast, the challenge of a publicly funded megaproject like the ISS is that of dealing with a protracted development cycle, lengthened by both the scale and scope of the project as well as the funding realities of the political process. Even compared to typical development cycles for complex, integrated vehicles (such as commercial aircraft and defense aerospace systems), the flow for a project the magnitude of the ISS is unprecedented. Whereas the development flow for a major new commercial jetliner is on the order of 5 years, the ISS will have been under development for more than 15 years by the time Phase Two (three-person permanent crew capability) is completed in 2001—the original preliminary design work having been initiated in 1985. After several design concept iterations (many driven by funding changes), the Space Station Freedom configuration was replaced by the Alpha configuration in 1993, and it was again modified to the final ISS configuration—with joint Russian participation fully defined—in 1994. Technology and hardware obsolescence are among the primary difficulties faced in long-development-cycle projects like the ISS, leading to unique challenges in the areas of personnel turnover, skills and knowledge retention, as well as infrastructure and supplier base erosion. In many high-tech industries (such as internet service providers), the focus is on maintaining cutting-edge skills among a workforce in which turnover is an accepted element of a rapidly expanding industry. In contrast, the larger challenge for the ISS is maintaining key engineers with the legacy design knowledge and development history for the vehicle's various components and subsystems. Funding disruptions and uncertainties in follow-on and sustaining activities further magnify these challenges. These issues are difficult enough to address within the prime contractor organization, but with hundreds of major and subtier contractors producing low-volume, technically sophisticated components (often with little commercial follow-on potential), the challenge of maintaining the personnel, support equipment, and basic production and maintenance capability for all of the critical program hardware becomes a first-order design consideration.

OCR for page 1
Page 5 In addition to obsolescence issues and knowledge retention, the length of the development cycle poses an even more fundamental problem: the inability to generate and sustain a comprehensive experience base. Broadly viewed, the history of American human spaceflight consists of three “phases” spanning approximately 40 years: (1) the Apollo-era projects (consisting of the Mercury, Gemini, Apollo, and Skylab programs), (2) the Space Shuttle, and (3) now the ISS. With the resulting frequency of only one or two major “programs” per generation, there is limited opportunity to build a comprehensive experience base, both in terms of knowledgeable engineers and readily accessible engineering data. This operational experience base is significant because, despite the sophistication of analysis techniques and simulation technologies, there remains a substantial element of iterative, “cut and try” optimization in the basic engineering process. Analytical methodologies require correlation, and operational experience nearly always generates significant learning. Whereas the fundamental engineering approach to system development has evolved with an assumption of a robust operational feedback mechanism (the use of extensive field data generated over an extended period under a wide range and combination of operating conditions), human space technologies have not been afforded this opportunity. As a result, extensive high-fidelity ground-based testing and simulation capabilities, along with an increased focus on capture and analysis of all available operational data, have become essential. Additionally, enormous effort must be expended to ensure first-time success. The cost of failure is often extremely high, and the cost/risk trade is therefore much different in character from most ground-based applications. It is important to note that this paradigm is likely to shift as the ISS becomes permanently occupied. With operational experience will come a reduction in the real risk associated with many follow-on engineering activities, and the immediate cost/risk trade should more often result in selecting less costly options. Assuring that this shift is properly incorporated into the design and verification philosophy will be critical to enhancing the efficiency of future development activities. TEST AND VERIFICATION CHALLENGES Testing and verification of the ISS have involved a number of unique requirements and constraints. The major contributing factors include the on-orbit assembly process, the series of vehicle “stages” defining the incremental steps in the assembly process (each with unique functional performance requirements), and the requirement to operate and support human activity under the extreme environmental conditions of space. Add to this that the system is designed, built, and deployed by a consortium of 16 nations, and its parts delivered to their final assembly location by the most complex space vehicle ever built (the Space Shuttle), and the result is arguably the most difficult test and verification program ever attempted.

OCR for page 1
Page 6 The operational environment, a zero-gravity vacuum with temperature swings of hundreds of degrees within hours, poses the most obvious verification challenges. Testing under vacuum conditions is most difficult for large elements and complex mechanisms. Two examples are the thermal vacuum testing of the Common Berthing Mechanism (CBM), used to berth the non-Russian pressurized elements of the station, and the leak testing of the U.S. Laboratory. In the case of the CBM, the 20-foot thermal vacuum chamber at Marshall Space Flight Center was used to qualify the active and passive segments of the berthing mechanism under vacuum and a wide range of thermal conditions. A sophisticated resistive load system and software simulating the dynamics of the shuttle and station robotic arms were used to validate the berthing system throughout its operating range. In the case of the U.S. Laboratory leak testing, the entire element was lifted into the large vacuum chamber at Kennedy Space Center, where a low concentration of helium was introduced into the element to determine total leakage to vacuum. Both of these tests involved use of assets developed during the Apollo project, upgraded with advanced analytical and experimental techniques to further extend the precision and accuracy of test results. The one-g environment poses additional challenges when simulation of zero gravity is impractical. Perhaps the best example is the large solar array wings. Deployment of the wings in a flightlike manner under one-g conditions is impractical. The structure is not designed to withstand gravity loads, and the scale of the system makes simulation of zero gravity via counterbalancing cost prohibitive. In this case a combination of analysis and subcomponent testing is used to verify system performance. Human thermal vacuum (HTV) testing and neutral buoyancy testing are most commonly used in the development and validation of tasks requiring direct human interaction. HTV testing is typically used to assess the acceptability of planned extravehicular activities (EVAs) that require suited crew members to operate mechanical equipment under thermal vacuum conditions. Operational procedures and human factor issues can be assessed with either actual flight hardware or high-fidelity engineering units to closely simulate the equipment's operational characteristics. Neutral buoyancy testing is used for similar development and validation goals, when zero gravity, rather than thermal vacuum effects, is the critical simulation parameter. Although the mechanical systems simulations are typically of lower fidelity, neutral buoyancy testing allows realistic assessment of zero-gravity operational procedures and is the preferred means for validating large-scale operations and for conducting crew training. Zero-gravity simulation also can be accomplished in a specially outfitted KC-135, which can provide a simulated zero-gravity environment for a series of 30-second windows by flying successive parabolic flight maneuvers. Another unique element of the ISS verification program is the frequent use of “protoflight” versus conventional qualification and acceptance testing. The conventional hardware verification approach includes qualification testing (in

OCR for page 1
Page 7 which the basic hardware design is verified) of a dedicated qualification article, along with less severe acceptance testing of the flight units (to verify proper workmanship and quality control during manufacturing). But because of the cost and complexity of many ISS components, a “protoflight” concept has been adopted, whereby only flight units are built. These are then subjected to an intermediate level of testing to both qualify the design and verify workmanship. This approach offers the opportunity for reduced cost and development time, but it also puts a premium on the use of analysis to assure that adequate testing is completed so as to demonstrate performance margins without potentially damaging the flight hardware. The various vehicle “stages” consist of incremental combinations of the approximately 40 different elements composing the “assembly complete” configuration. (In contrast, the lunar landing missions involved just 3 or 4 vehicle configurations). Each stage has a unique set of functional performance requirements, and, as a result, the system verification process is an order of magnitude more complex than for a typical vehicle. In most cases, the mating elements are joined on orbit, having never previously been assembled. When possible, some elements have been brought together on the ground for integrated testing. For instance, a multi-element integrated test (MEIT) program brought together several of the U.S. flight elements in the Space Station Processing Facility (SSPF) at Kennedy Space Center. Using flight software and simulations of the other inter-facing elements, researchers tested critical functions of the station in various assembly stages. In addition, a comprehensive series of cable and hose fit checks were performed to assure proper on-orbit mating of all fluid and electrical connections between station elements. In cases in which manufacturing schedules (as in the case of the U.S. Node and the Joint Airlock) or geography (as in the case of the U.S. Node and the Russian Zarya module) prevent physical integration and fit checks, advanced digital measurement techniques are employed to determine the as-built configuration of elements that will be physically assembled for the first time on orbit. An extensive Digital Pre-assembly (DPA) program is used to document the asbuilt geometry of each element and to electronically “assemble” the station elements prior to launch. INFRASTRUCTURE SCALE AND COMPLEXITY Anyone who has visited the Kennedy Space Center and seen the Vehicle Assembly Building (VAB)—originally built to process the Saturn V and currently used to assemble the Space Shuttle and its external tanks and solid rocket boosters—and the crawler-transporter—used to move the final assembled vehicle and mobile launch platform from the VAB to the launch pad—has an appreciation for the massive infrastructure requirements of a major space project. The ISS program has benefited substantially from the existence of the Apollo-era

OCR for page 1
Page 8 infrastructure. Updated and tailored for use with the Shuttle and now the ISS, this infrastructure is critical to execution of the ISS program. In addition, such facilities as the SSPF, built specifically for processing the ISS elements, represent a major new investment in ground handling, support, and test equipment. Mission control centers in Houston and Moscow, along with mission support facilities at the various development sites, represent an equally extensive investment for on-orbit control and operations. Probably the most complex (and unique) infrastructural elements of the program are the launch vehicles themselves. With 88 total launches (U.S. and Russian) scheduled, assessing the cost and risk associated with the launch infrastructure and incorporation of these elements into basic design trades is extremely difficult. Future programs, particularly those driven by purely commercial incentives, will require an increased focus on the cost and risk associated with infrastructure and support elements of various design options. Minimizing the additional infrastructure requirements and reducing the cost of developing and maintaining that infrastructure will be key to the economic viability of future human space projects. While minimizing the required asset base is a key focus across many of today's manufacturing industries, properly valuing the existing infrastructure and minimizing additional investment requirements are more complex for multinational projects, particularly those with a legacy of heavy government involvement. As international joint ventures become a mainstay of global business, properly valuing and integrating technology and infrastructure contributions of partners in large-scale international ventures is an issue of significant consequence—beyond the ISS. SUMMARY Current trends in macroeconomics, defense systems, and advanced communications seem to suggest that large, complex, multinational enterprises like the ISS will become increasingly important over the decades to come. Here I have outlined a variety of unique systems engineering challenges associated with the development of the ISS, including the protracted development cycle, test and verification requirements, and infrastructure considerations. The extended development cycle offers major challenges in the areas of technical obsolescence and skills retention. Additionally, the limited number of new programs minimizes the opportunities to build and maintain a comprehensive engineering experience base. With the start of continuous ISS operations in November 2000, this constraint will be softened, offering the opportunity to make a major shift in the basic development paradigm that has existed since the start of human spaceflight. Verification of a system assembled and operated on orbit requires unique testing technologies and places a premium on advanced simulation and analysis

OCR for page 1
Page 9 techniques. The facilities and equipment to support this complex verification task, along with the massive infrastructure associated with launch processing and on-orbit operations, represent a huge investment and a major challenge to developing a commercially viable human spaceflight industry. This paper has focused on the definition and description of these unique challenges, but the more critical job is to extend the lessons of the ISS to better prepare the engineering community for the challenges of similar projects in the years to come.