Description of a Turbofan Engine Product Development Process by Douglas C. Hague Ph.D. Materials Science & Engineering, The Pennsylvania State University, 1995 M.S. Metals Science & Engineering, The Pennsylvania State University, 1992 B.S. Engineering Physics, The University of Tulsa, 1989 Submitted to the System Design & Management Program In Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering & Management BARKER at the Massachusetts Institute of Technology FF , February 2001 02001 Douglas C. Hague, All Rights Reserved The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this Pwhis document in whole or in part. Signature of Author Douglas C. Hague System Design and Management December 15, 2000 Certified By__ Steven D. Eppinger General Motors LFM Associate Professor of Management Science Thesis Supervisor Accepted By "/ FPaul A. Lagace LFM/SDM Co-Director Professor of Aeronautics & Astronautics and Engineering Systems Accepted By Stephen C. Graves LFM/SDM Co-Director Abraham Siegel Professor of Management Science JTE 2 Description of a Turbofan Engine Product Development Process by Douglas C. Hague Submitted to the System Design & Management Program on December 15, 2000 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Engineering & Management ABSTRACT This research explores what requirements are necessary for the development of a turbofan engine and how they evolve through the product development cycle. This work utilizes a parameter-based design structure matrix (DSM) to define the interfaces and interdependencies present in a large commercial aircraft propulsion system. The DSM was developed from the system level to the module level allowing one to examine the assumptions made throughout the entire life cycle of the product. The work utilizes the system-level DSM to show the similarities between the turbofan engine product development process (PDP) and the software spiral product development process. This work examines the parameter-based DSM in each of the design phases and attempts to understand the assumptions made in each phase and how the assumptions change as the product proceeds through the development cycle. By examination of the DSM, it was found that program goals and requirements lead to an initial set of design parameters. These design parameters are then iterated until a satisfactory product defmition is developed. Each stage concludes with the integration and testing of that stages work. In all stages risk management occurs and with the necessary revision of the program plan for subsequent stages (not in the system-level DSM). The work shows that the PDP for a turbofan engine can be viewed as a spiral process. The thesis then suggests that, in general, the current industry practices for the development of complex physical systems have similarity to the spiral framework for development of software. Thesis Advisor: Steven D. Eppinger Title: General Motors LFM Associate Professor of Management Science 3 4 ACKNOWLEDGEMENTS I would like to thank my advisor Steve Eppinger for his guidance and suggestions in this work. I would like to thank Glenn Bartkowski for sharing his in-depth knowledge of the gas turbine engines both during the development of the DSM utilized throughout this work and during our classes as we discussed the implications and situations within the Pratt & Whitney. I would also like to thank Ronnie Thebeau for keeping us balanced within UTC. The discussions and conversations between Glenn, Ronnie and I significantly enhanced the learning in our classes. I would like to thank those whom sponsored me within P&W. Bill Yee was instrumental for nominating me for the opportunity to participate in the SDM program. His guidance and insight while I was in the Materials Lab opened many doors for me. I would also like to thank Tom Johnson and Jim Adams for supporting me during the program. Tom allowed me to work in his Design Integration group while participating in the program. This allowed me to both learn and attempt to apply the knowledge I was learning concurrently. This taught me about the many opportunities and difficulties in attempting to apply the new knowledge within a corporation. Thanks to Jim for being so flexible with my work arrangements. Finally, I would like to thank my wife and my sons Collin and Galen. Thanks for being patient and for allowing me the opportunity to participate in this program. Without your unfaltering (and often unacknowledged) support I would not have made it to this point. May we move into the future on the path together without so many "opportunities." 5 6 Table of Contents A bstract........................................................................................................................................... 3 A cknowledgements......................................................................................................................... 5 Chapter1: Introduction........................................................................................................ 11 Chapter2: Background .............................................................................................................. 16 Product D evelopm ent (faster/better/cheaper).................................................................... 16 Product D evelopm ent at Pratt & W hitney............................................................................ 17 System Engineering at P& W .................................................................................................. 19 Requirem ents Docum entation w ithin P& W ...................................................................... 21 Design Structure Matrix ...................................................................................................... D SM Research........................................................................................................................ D SM within P& W .................................................................................................................. 25 27 29 Chapter3: System Level Parameter DSM .................................................................................. 32 Developm ent of the D SM .................................................................................................... 32 Direct and Indirect Parameter Interactions within the DSM .......................................... 35 Validation of the D SM ............................................................................................................. 37 Baseline D SM ........................................................................................................................... 40 Partitioning and Tearing the Param eter DSM ................................................................. 40 Chapter4: Variation of Assumptions by Stage of ProductDevelopment............................... 63 Assum ptions for Conceptual Design.................................................................................. 64 Assum ptions for Prelim inary Design.................................................................................. 76 Assum ptions for Detailed Design ........................................................................................ 78 Assum ptions for V alidation.................................................................................................. 84 Sum m ary .................................................................................................................................. 91 Chapter 5: Discussion................................................................................................................. 95 Im plications for Pratt & W hitney.......................................................................................... Requirem ents Docum entation............................................................................................. Organizational Im pacts ...................................................................................................... Simulation vs. D SM ............................................................................................................. Applications for D SM within P& W ..................................................................................... 95 95 97 100 101 G eneral Im plications of W ork.............................................................................................. Lessons from Pratt & Whitney............................................................................................. Requirem ents .................................................................................................................... Product Development and System Engineering Organizations .................. 102 102 102 104 7 System M odeling and Sim ulation..................................................................................... Assumptions, the Parameter DSM, and the Product Development Cycle ........................... Spiral vs. W aterfall Fram eworks for Product Developm ent ................................................ Spiral Developm ent and Derivative Products. ..................................................................... 105 106 110 119 Chapter 6: Conclusions and Future W ork ............................................................................... 120 Conclusions............................................................................................................................. 120 Future W ork .......................................................................................................................... 121 References .................................................................................................................................. 8 123 List of Figures Figure 1: Generic product development process [after Ulrich and Eppinger, 2000]................. 12 Figure 2: Schematic waterfall development process [Boehm, 1988]. ...................................... 13 Figure 3: Schematic spiral development process with 4 cycles [Boehm, 1988; Rechtin and Maier, 19 9 7 ]. .................................................................................................................................... 14 Figure 4: Schematic large commercial gas turbine. Subsystems are identified within the d raw ing . ................................................................................................................................ 17 Figure 5: Product development organizational structure at P&W............................................. 20 Figure 6: P&W integrated product development process [Anonymous, 2000]............. 22 Figure 7: Example Program DSM of Kodak Cheetah Project [Ulrich and Eppinger, 1995]........ 25 34 Figure 8: Sets of the P&W organization utilized in various work................................................ Figure 9: Baseline DSM developed in cooperation with Bartkowski [Bartkowski, 2001]. ......... 41 Figure 10: DSM organized by the organizational structure.......................................................... 43 Figure 11: Partitioned DSM with large block of interdependent parameters. .............. 49 53 Figure 12: The DSM with the Design parameters torn by column............................................... Figure 13: The DSM with the Design parameters torn by row..................................................... 55 Figure 14: Base DSM for stages that have the Designs determined late................. 59 Figure 15: Base DSM for stages that have the Designs determined early................ 61 Figure 16: DSM with thrust and design parameters assumed....................................................... 65 Figure 17: Partitioned DSM with assumptions for new temperature capabilities. ........... 69 Figure 18: DSM with one set of assumption during the aerothermal design.............. 71 Figure 19: DSM with a second set of assumptions during the aerothermal design.......... 73 Figure 20: Schem atic DSM for Conceptual Design. .................................................................... 75 79 Figure 21: DSM with assumptions for Preliminary Design.......................................................... 81 Figure 22: Schem atic DSM for Preliminary Design..................................................................... Figure 23: Levels of decomposition examined during product development stages................ 81 82 Figure 24: Hierarchical set of DSMs with ever increasing detail............................................. 85 Figure 25: DSM of detailed design for gas turbine engine [Mascoli, 1999]. ............... 87 Figure 26: Schem atic D SM for detail design................................................................................ 89 Figure 27: System Level DSM with assumptions for validation.................................................. 93 Figure 28: Schem atic DSM for the validation phase.................................................................... 93 Figure 29: Schematic DSM for the entire product development cycle................... Figure 30: Comparison of sequences of Conceptual Design, Preliminary Design, and Validation. ........ 94 ............. ........................................... . . . . ......... 112 Figure 31: Spiral representation of the conceptual design stage................................................. 112 Figure 32: Schematic conceptual design DSM with labels for spiral development. ......... 113 .............................................. Figure 33: Spiral representation of the preliminary design stage. Figure 34: Schematic preliminary design DSM with labels for spiral development........ 114 115 Figure 35: Spiral representation of the detail design stage......................................................... Figure 36: Schematic detail design DSM with labels for spiral development............. 115 117 Figure 37: Spiral representation of the validation stage. ............................................................ Figure 38: Schematic validation DSM with labels for spiral development............... 117 Figure 39: Schematic spiral for a waterfall product development process................................. 118 9 List of Tables Table 1: Parameters and their unique identifiers used throughout this thesis........................... Table 2: Sequence and reasons for assuming module design parameters. ............................... 10 38 52 CHAPTER 1: INTRODUCTION Product development of complex products has been studied for many years. The field of system engineering has been developed to assist in many of the technical aspects of developing a product. While many of the tools of system engineering focus on the marketing (customer) needs and how to relate them to the functions and high level requirements of a product, this thesis uses one system engineering tool to focus on the timing of assumptions made during the product development process. Finally, this work suggests that the current product development process (PDP) for turbofan engines most closely resembles the spiral product development framework that has been outlined in the software industry. The present work was originally undertaken to further understand what requirements are necessary and how they evolve through the product development cycle, conceptual design through validation. Production, field support, and disposal are not included in this work. This work utilizes a parameter-based design structure matrix (DSM) to define the interfaces and interdependencies present in a large commercial aircraft propulsion system. The DSM was developed from the top down instead of the bottom up (i.e., from a system level rather than the subsystem level). This unique perspective allows one to examine the assumptions made throughout the entire life cycle of the product. It concludes that the assumptions made in one stage of product development, once validated, often become the requirements for subsequent stages. The system perspective allows one to take (as we say in the industry) "the 40,000 feet" view of the propulsion system. The DSM work in this thesis expands upon previous work of 11 Craig Rowles and Greg Mascoli [Rowles, 1999; Mascoli, 1999]. The development of the parameters and their interactions for the DSM in this work was done in cooperation with Glenn Bartkowski [Bartkowski, 2001]. Within the aircraft propulsion industry, as well as many industries, product development can be viewed as proceeding along a generic program plan [Ulrich and Eppinger, 2000]. Figure 1 shows the generic product development cycles as it exists within many industries. While this process looks linear, many planned and unplanned iteration cycles occur within the process. Desire to reduce product development time and cost have put tremendous pressure upon the product development teams not only to eliminate unplanned iteration, but also to minimize planned iteration (if not eliminate it entirely). Stage 0 Planning Stage I Concept Development Stage 2 System-Level Design Stage 3 Detail Design Stage 4 Testing and Validation Stage 5 Production and Field Support Figure 1: Generic product development process [after Ulrich and Eppinger, 2000]. This pressure has led to many techniques and methods that shorten the generic program plan. Among these are concurrent engineering, integrated product teams, integrated computer master models, and reordering tasks for more optimal information flow. Each of these allows for the shortening and overlap of the generic program plan given in Figure 1. When attempting to put the generic PDP into a framework, the process is generally described as a waterfall product development process (Figure 2) [Boehm, 1988]. However, this work examines the PDP for a turbofan engine and it concludes that a second framework for product development more closely resembles the turbofan PDP. This second framework has been termed a spiral 12 development process due to its conceptual graphic (Figure 3) [Boehm, 1988; Rechtin and Maier, 1997]. In a spiral development process, the product is developed in every increasing complexity by progressing through a set of tasks very quickly and doing so several times. For each spiral around the process, the product becomes more complex and has more functionality. By validating the product in small increments, issues and errors within the product design are caught early and only small amounts of rework (iteration) are necessary to correct the issues. The reduced rework leads to significantly shorter development time and lower cost (as well as mitigating risk). System feasibility talidation ,.. Plans and Requiremen Validation Produc~tDesign OVerification Detailed Design Verification Code Unit Test Integration Product Verification Implementation System Test Operations and Maintenance ReLlidation Figure 2: Schematic waterfall development process [Boehm, 1988]. 13 Requirements Irr Cycle 1 Cycle 2 -- Cycle 3 - Initial Design Cycle 4 Integration and Test Define Product Figure 3: Schematic spiral development process with 4 cycles [Boehm, 1988; Rechtin and Maier, 19971. Two primary differences exists between a waterfall PDP and a spiral PDP. First, the product requirements in a waterfall development process are set very early in the process and should not change throughout the process. In a spiral process, the requirements are more flexible. Exactly how flexible is not clear in the literature. Second, the spiral process emphasizes risk analysis and mitigation. There is no such emphasis in the waterfall process. The current work utilizes the system-level DSM to show the similarities between the turbofan engine product development cycle and the spiral product development process. This work examines the single DSM in each of the design phases and attempts to understand the assumptions made in each phase and how the assumptions change as the product proceeds through the development cycle. A process called tearing is used to examine the assumptions in the DSM. Tearing a DSM is the process of making an assumption and then reordering the 14 parameters based upon the assumption. By ordering the tears according to how information is developed in a particular stage of the product development process, each stage may be examined as to how and what is occurring during the phase. By examination of the information flow between parameters in the DSM and the iteration that occurs in a stage, it was found that the information flows from the determination of program goals and requirements to an initial estimation of the design to an iterative cycle of product definition. Each stage concludes with the integration and testing of that stage's work. In all stages, risk management occurs and the necessary revision of the program plan is developed for subsequent stages. The work shows that the PDP for a turbofan engine can be viewed as a spiral process. The thesis then suggests that that, in general, the current industry practice for the development of a complex physical system is equivalent to the spiral framework for & development of software. This work also develops specific recommendations for Pratt Whitney as well as implications for general product development processes. 15 CHAPTER 2: BACKGROUND Product Development (faster/better/cheaper) As a market becomes more competitive and as the "clock speed" of an industry increases, the product development process is put under pressure to develop improved products in less time for less investment. This push towards faster/better/cheaper has led to the adoption of concepts such as concurrent engineering and product development process optimization. The design structure matrix technique is one of many tools that may be employed to improve the PDP through optimal ordering of the tasks and improved information flow. Given the large push to make drastic improvements, many changes are made without full recognition of their impacts and interactions with other portions of the product development cycle. Such blind reduction of the process without understanding of the interfaces and the interdependencies can ultimately lead to failure. One example of this was the Mars Polar Lander developed by Lockheed Martin for NASA. This failure was directly attributed to the push for development time and cost reductions [Dornheim, 2000]. Failures such as the Mars Polar Lander probably occur much more frequently than documented in public literature simply because companies are extremely reluctant to put any failure into the public arena. Under such an environment, product development management must continually push to improve their process, but must do so by developing a deep understanding of the interdependencies of the process and the risks they accept when pushing to achieve their goals. 16 Product Development at Pratt & Whitney Pratt & Whitney (P&W) develops, manufactures and supports a wide range of gas turbines. The current work will focus on a gas turbine for large commercial aircraft. A schematic of a propulsion system for a large commercial aircraft is given in Figure 4. Traditionally, the overall system has been decomposed into nine major subsystems (fan, low pressure compressor, high pressure compressor, diffuser/combustor, high pressure turbine, low pressure turbine, mechanical components, externals/controls, and nacelle). The combination of the gas turbine (the first eight subsystems) with the nacelle is termed a propulsion system. Externals HpC Mech Comp. -i Diff/ Comb HPT Core/Primary Airflow Bypass Airflow Nacelle Figure 4: Schematic large commercial gas turbine. Subsystems are identified within the drawing. A gas turbine provides propulsion to an aircraft by significantly increasing the momentum of air that goes through the engine. The propulsion systems accomplishes this by first compressing the ambient atmosphere, fuel is then added to the air and burned in a continuous manner to greatly accelerate the air. The gasses then pass through a turbine that turns the compressor stages. The hot gas then exits the core of the engine and provides thrust to the aircraft. This gas is termed the core or primary airflow. For large commercial aircraft, the thrust 17 from the hot air exiting the core of the engine is only a minor portion of the overall thrust. The majority of the propulsion is provided by having the fan accelerate a large amount of air by a small amount. This is termed the by-pass air. (To increase the momentum of air, mass*velocity, one may significantly increase the velocity of a small mass of air or slightly increase the velocity of a large mass of air. For reasons beyond this thesis, large commercial engines choose to do the latter [Smith and Mindell, 2000]). From the early development of gas turbines through the early 1980s, a product development cycle within the commnercial gas turbine industry typically lasted about 5-6 years [Epstein, 2000]. This length of time was from "launch" of the product (start of detailed design), to certification of the engine by the United States Federal Aviation Administration (FAA) or the European Joint Airworthiness Authority (JAA). Due to the drive for better products in a more timely manner, P&W implemented process improvement initiatives to reduce the product development time to 2.5 years by the year 2000. P&W strove to accomplish this while reducing the development cost by 70%. These reductions were undertaken to increase the attractiveness of P&W engines to our customers. Integrated Product Development, integrated 3-D modeling, alignment (and eventual merging) of manufacturing and engineering organizations, and the development of a system engineering organization are among the initiatives implemented at P&W in support of these goals. These initiatives eliminate wasted effort and significant amounts of rework within the product development cycle. The philosophy within the engineering and product development leadership was that the product development cycle should be replaced by a product validation cycle. P&W was to validate designs developed using the software tools implemented through 18 the process initiatives listed above. As P&W transitioned from a development company to a validation company, there was recognition that a minimal set of development tests would be necessary. However, extreme pressure from management was put on any single test to either eliminate it or minimize the amount of work necessary. Of course the design teams would push to include as much testing as possible in order to validate their software tools and designs prior to FAA/JAA certification tests (i.e., validation) were failure is unacceptable. This tension between the management and the design teams is necessary and can in fact serve to balance the process. When one of the sides develops too much power, there is no balance and the process suffers. P&W recognized this tension and initiated the formation of a system engineering organization in 1997 to help maintain this balance. For detail discussion of the organizational transformation at P&W see the following references: Womak and Jones, 1996; Rowles, 1999; Mascoli, 1999; Glynr and Pelland, 2000. System Engineering at P&W System engineering at P&W was formally instated in 1997. At that time a "three-legged stool" was put in place with three system engineering organizations representing the three legs. & The three organizations are Propulsion System Analysis (PSA), Product Development Validation (PD&V), and System Design & Component Integration (SD&CI). The organizations were developed such that each had specific responsibilities and that together, they were responsible for the technical (engineering) side of product development and field service. The current organizational structure is shown in Figure 5. (Note that the true organizational structure cannot be drawn as neat boxes in a figure and that full understanding of the organization is only developed with experience, if ever). Prior work of Mascoli, 1999 and Rowles, 1999 has the 19 perspective of the IPTs in the organization while the current work's perspective is from the system engineer (two very different parts of the organization). Chief Operating Officer VP Engineering Dir. Mod Ctr -------___ Engineering Test- PD&V VP Operations -------------------- Turbine Module Center -Engineering Certification Manager Other CIPT pebiyLeaders (6) Other Module Centers (3) Post Cert. Engines Business Ctr Manager (4) GP7000 Tech Manager PW6000 Performance - PSA VP Prograrms Turbine CIPT Software IPTs PW40000 orgaizatoa _Design Managers Secondary Flow PW4000 Other Programs Functional Systems Orgs Figure 5: Product development organizational structure at P&W. PSA has the responsibility for engine (system) level parameters. They own the simulations and models for the aerothermal cycle analysis of the engine as well as analysis for such integrative parameters as noise. In addition, PSA is responsible for the software that controls the engine. This system engineering organization is primarily responsible for the performance and operation of the engine. The PSA organization owns the "primary" gas flow in the engine. 20 The PD&V organization is primarily responsible for the assembly, testing, and certification of the engines. They are by far the largest of the system engineering organizations in that they include many assembly mechanics and test engineers. The PD&V organization develops and maintains the engine validation plan (EVP), formerly termed the engine development plan (EDP). This plan is developed within the overall schedule and resource constraints of the program (i.e., product development cycle). This organization is constantly attempting to balance the multi-project problem with limited physical resources (test cells). The SD&CI organization is by far the smallest organization in terms of people, but they have the responsibility for leading and integrating the entire physical design of the engines. In effect they have the responsibility, but not the direct supervisory link, for the entire design team and all the IPTs that design the individual components. The SD&CI organization owns the requirements and the configuration of the engines. Also within SD&CI are groups responsible for the secondary (as opposed to primary) flow within the engine, static and dynamic structural considerations at the system level (e.g., fan blade out stress loads and engine vibration). These later groups are a very functional organization while the requirements, configuration, and system integration portion of SD&CI is very program focused. Requirements Documentation within P&W The documentation of requirements for a propulsion system is the responsibility of the SD&CI organization. The process for this has been evolving over the last 5 years to facilitate integrated product development (IPD) process (Figure 6). The internal IPD process and system 21 level procedures developed for IS09000 outline the expectations for a Propulsion System and Components Requirements Document (PS/CRD). The Propulsion System Requirements Document (Chapter 1 of the PS/CRD) is developed during the preliminary design phase and is approved upon completion of the preliminary design review, termed a Level II Review. Thus, system level parameters and their associated requirements are developed early in the product development cycle. Many of these requirements are developed in Advanced Engine System Engineering organizations using a detailed aerothermal simulation and other system level models and heuristics developed over the last 50 years within P&W. IPD Phases Concept Senior Management Systems 9 K Plan Program Initial Final Follow MOU Approval & Funding Quality Validation Quality Validation the Fleet SM jjSM >SM <3 SM < 77 Concept Choice 7 KjSM K& SM < < nMM M Parts s < s s S Concept Options In Service Prior to Modules Timing Develop and Validate >P Preliminary Configuration 7 < First Engine 7 '> S S M <>p M <& P Certification Service Entry 7 Figure 6: P&W integrated product development process [Anonymous, 2000]. Following a successful Level II Review, senior management launches product development cycle and detailed design begins. At this point the responsibility for the system engineering is handed from the Advanced Engine organizations to the program specific PSA, 22 PD&V, and SD&CI organizations. This handoff is the general case for new engine designs (about one every 10 years). For derivative designs within a product family, the program specific system engineering organizations are responsible for the conceptual and preliminary design as well as the detailed design, validation and field support. One of the first tasks after launch is the development of the Component Requirements Document (Chapter 2 of the PS/CRD). Each major subsystem (fan, LPC, HPC, diffuser/combustor, HPT, LPT, mechanical components, externals/controls, and nacelle) develops the detailed requirements that will enable the subsystem (modules as they are called P&W) to meet the requirements laid out in the Propulsion System Requirements. A review and approval of the Component Requirements occurs at a Level III Design Review. Following the development of the detailed module requirements, the detailed engineering design begins. (This is sequential only in an idealized world. In actuality, the detailed design and development of requirements happen concurrently). During the detailed design, the requirements for the manufacturing of the parts are developed and when rolled together at the module level become sections of Chapter 3 in the PS/CRD. Review of the detailed design and the manufacturing requirements occurs at Level IV reviews in each integrated product team (IPT). During the detailed design of a component, it is common practice to have 3-5 designs for a specific component. These various designs define the window of design space the component will occupy. During the design and validation of the components and engine, the design is narrowed to a final design that is then released as the production design. There is a constant 23 tension between the desire of manufacturing to have the final design to produce and the desire of the design engineers to maintain as wide a design window for as long as possible. As the components and modules are produced and assembled into an integrated engine, the verification of each requirement should occur during the validation phase of the product development cycle. As gaps are identified between the actual engines and the requirements, individual recovery plans are put in place. If the gaps are in system level parameters, the system engineers usually lead a team of module level integration leaders (Deputy CIPTs) to develop and implement the recovery plan. While the procedure for developing a PS/CRD and its relationship to IPD has been in place, it is written as a suggested process and its implementation has varied widely. Of particular note is the PS/CRD for derivative products. For derivative products, the PS/CRD has been implemented as a "what has changed" or a "what is at risk" instead of as a baseline for a complete design. Often PS/CRD documents do not exist for the baseline design (the original designs were completed prior to the development of the PS/CRD methodology and no effort has been made to retroactively develop comprehensive requirements). Thus, for several platforms within P&W only highly annotated sets of requirements exist. This methodology of only developing requirements for high risk areas is similar to the suggestions for a spiral development process [Boehm, 1988]. However, as will be discussed later in this thesis, this practice carries the risk of omission of a critical interface or requirement. For highly interdependent products, this may not be the most preferred technique. 24 Design Structure Matrix The design structure matrix (DSM) is a system engineering tool that graphically represents the information flow and interdependencies among a set of items. The items can be tasks, parameters, teams or another set of related items. The DSM is a square matrix with the items listed both down the column and across the rows. An "X" or other mark at the intersection of the row and column indicates interdependency between items. The DSM analysis attempts to develop a preferred order to accomplish the items. The convention is that when completing items, a team starts at the top and works down. Note that in the convention used throughout this thesis, the marks below the diagonal are feedforwards and the marks above the diagonal are feedbacks. The following example DSM is taken directly from Ulrich and Eppinger, 1995. In Figure 7, Task A is not dependent upon any other task and can be completed first. Task B is dependent upon Task A and therefore Task B must be completed following Task A (i.e., they are sequential tasks). Since Task E is not dependent upon Task D, they may be accomplished concurrently (i.e., they are parallel tasks). A B C D E F G H I Task Receive and accept specification Concept generation/selection Design beta cartridges Produce beta cartridges Develop testing program Test beta cartridges Design production cartridge Design mold Design assembly tooling A A B X Purchase assembly equipment Frabricate molds J K Debug molds Certify cartridge Initial production run L M N C D E F G H I J K L M N Sequential Tasks X X C Parallel Tasks l7 X D -E X X X Coupled Tasks X X X F X G X X X X X X X H X X X X X I X X J X X X X X K X L M X X X N X Figure 7: Example Program DSM of Kodak Cheetah Project [Ulrich and Eppinger, 1995]. 25 For Task H, information from items A, B, F, G, and I are necessary. In this case, Task G cannot be completed until Task H and I are completed; however, Tasks H and I cannot be completed until Task G is completed. Thus in all likelihood, iteration will be necessary when completing G, H, I. These are termed coupled tasks. Completing a set of coupled tasks always involves making an initial set of assumptions. In this example, Task G can be accomplished by first guessing the output of H and I. Next H could be completed with the information from G and an assumption about I. The designer would then have a choice on whether to go on to Task I or to check the assumption made in G about the output of H. If the assumption was too far off the output, the designer may want to iterate on G prior to completing I. In this methodology, how to complete coupled tasks is left up to the development teams. A second methodology to completing a set of coupled tasks is to make the assumptions a requirement. In this way, items completed later are actually forced to fit the initial assumption. While this may not be ideal (or even possible), this practice is fairly prevalent in industry, especially for items that have a very long feedback loop. Reordering of items within a DSM has been the subject of much research. Algorithms for clustering (reordering into groups of interdependent tasks) and partitioning (reordering in an attempt to have all the dependencies below the diagonal to eliminate coupling) have been developed [Fernandez, 1998; Thebeau, 2001; Steward, 1981]. The method that allows one to make assumptions on the outputs of items and then reorder the DSM is called tearing and partitioning [Steward, 1981]. Repeated tearing and reordering will eventually result in all 26 unassuned dependencies lying below the diagonal. In this manner, by making the assumptions given, the DSM can be completed without iteration (if all assumptions are valid). In Figure 7, the three interdependencies above the diagonal would all have to be assumed. There is no reordering of this DSM that would reduce the feedback loops above the diagonal. The current work uses tearing extensively. An analysis of what parameters are assumed when and the resultant progression through parameters is used to develop the main conclusion in this thesis. Assumptions can be made for two reasons. First as discussed above, assumptions can be made to break a set of coupled tasks. Second, an assumption may be made to reduce the product development time. Returning to the prior example in Figure 7, if the output of Task K could be assumed, then Tasks J, K, L and M could be accomplished in parallel (resulting in a reduction in the overall product development time). Thus, by making selective assumptions throughout an entire set of tasks, product development time can be reduced. Of course, this assumes that the development team can develop a good set of assumptions that do not force rework at a later time. Good program managers are aware of these relationships and will make the appropriate trades of time vs. rework probability. (For significantly more detail on risk management using the DSM, see the work of Browning, 1998). DSM Research The interfaces and information flow within a product development cycle have been studied by research groups lead by Eppinger and Whitney over the last 10 years [Pinunler and Eppinger, 1994; Eppinger et al., 1994; Cronemyr et al., 1999; McCord and Eppinger, 1993; 27 Smith and Eppinger, 1997; Whitney et al., 1999]. Their work expanded the work of Steward on the DSM [Steward, 1981]. By defining the information flow between teams, parameters, or tasks, the DSM graphically represents the product development cycle. Partitioning and clustering of tasks within the DSM has lead to many suggestions for improvements concerning program planning (concurrent engineering and minimization of iterations and risk), product architecture, and organizational structure. The DSM has been utilized in many research groups to study a wide variety of products and is now being developed for use within various industries (see Second MIT DSM Workshop Program, Sept. 2000 [MIT DSM, 2000]). The DSM is a graphical method for showing iteration and information flow between a series of items. Four main types of DSMs have evolved [MIT DSM, 2000]: Team-based: where the items of concern are teams and information flows is passed between teams and through the organization. Component-based: where the items are physical components of product architecture and the relationships are material, energy, spatial, structural, and/or information. Activity-based: where the items are tasks to be completed within an overall program plan and the interactions are precedence relationships. Parameter-based: where the items are variables or design points within a product and the interactions are often mathematical relationships between the parameters. Each of these types of DSMs has specific benefits and may even be combined to show alignment between the various structures present within a companies product development process [Rowles, 1999; Sosa et al., 2000]. The technique of using a DSM has been extensively studied in industry-university relationships. Although much of the initial work utilized automotive examples, various industries have now been involved in the academic research on DSMs. The latest conference on DSM provides some perspective on the applicability of this technique. Industries involved 28 included automotive, aerospace, construction, and telecommunications. The primary link in all these industries is that they have a complex product (i.e., a product with many interfaces and interdependencies of the subsystems). Many large DSM systems are now being developed. For example, Boeing has a large, interlinked DSM that contains around 1000 parameters [Whitney et al.; Stowe, 2000]. While the process group has expended a large effort to develop this DSM, it has yet to gain general acceptance within the company and their program managers [Stowe, 2000]. Another interesting application comes from the construction industry for program planning [Huovila et al., 2000]. Here a company has developed a generic DSM (program plan) for the construction of a building. For each individual project, they spend a small amount of time altering the generic DSM for the specific building on that project. In this manner they have been able to streamline the planning and construction of a building. DSM within P&W Pratt & Whitney students in the System Design and Management program at MIT have completed three Masters theses that utilized DSM. Craig Rowles examined component-based and team-based DSMs to determine the degree of alignment between the physical architecture and the organization. Greg Mascoli developed module (subsystem) parameter-based DSMs and combined them into a system level DSM to provide a view of the architecture of a gas turbine. Steve Glynn and Tom Pelland jointly examined the work of Mascoli and Rowles to determine how information flows through Pratt & Whitney. The DSM developed later in this thesis attempts to examine Pratt & Whitney's architecture from the perspective of the entire propulsion system. This present work differs in that it takes a top down methodology instead of a bottoms up methodology that was used in the prior Pratt & Whitney students work. 29 Rowles developed an IPT (organizational) DSM as well as a physical component (architectural) DSM [Rowles, 1999]. The overlay of these matrices lead to several conclusions and recommendations on the organizational structure and integration aspects of the product development cycle. Detailed analysis and refinement of the hypotheses were completed to further understand the data and the second order interactions [Sosa et al., 2000]. Through Rowles' work, it was found that indirect interactions between components and teams are an important part of the propulsion system development and the system integration efforts were required to facilitate the interactions between large subsystems. Mascoli approached the same development process from the parameter point of view [Mascoli, 1999]. He developed a large parameter-based DSM that showed that the system architecture and the organization were aligned. The level of refinement in Mascoli's work was below the system level, but above the large subsystem level. Thus, he showed that the gas turbine engine can be decomposed into major subsections, but that there were many "system" level parameters that did not fit well with any subsystem. In fact, many research projects have found "system" level parameters/teams/components that are usually put at the top or bottom of a DSM. Following the segregation of the system parameters, the remainder of the DSM is partitioned independently. Similar to Rowles, Mascoli recommended that the system integration efforts be strengthened between the subsystem organizations. Pelland and Glynn showed how the recent organizational restructuring has traded system integration effectiveness for design-for-manufacturing effectiveness. While the communication and information transfer between modules has been made significantly less likely, the 30 manufacturing and design engineers are communicating well. This trade presupposes that the system integration can still be effectively managed by the system engineers. They recommended that a "smart" DSM be developed by the subsystems technical discipline chiefs and managed by one of the system engineering organizations. In this manner, the flow of information between IPTs and across modules could be managed with minimal wasted effort. 31 CHAPTER 3: SYSTEM LEVEL PARAMETER DSM Development of the DSM As one of the goals of this work was to approach the product development and interface management from a different perspective than prior work, the DSM developed in this work took a "system" level perspective. In this statement it is meant that the parameters used in the development of the DSM are those most often used and thought of within the system engineering organizations. Although the system engineers often delve into subsystem parameters, the objective was to view the subsystems (modules) defined in prior work as black boxes and to focus on the integrative, highly dependent, variables that define a gas turbine engine and its cycle. While prior work encompassed the system, the perspective was from a component or module level. This work utilized PW4000 engines as the basis for the DSM. The development of the DSM was accomplished cooperatively with Glenn Bartkowski [Bartkowski, 2001]. To obtain the system level perspective, interviews were conducted primarily with the system engineers within three system engineering organizations in P&W. The lowest level person interviewed for the production of the DSM was a Deputy Component Integrated Product Team Leader (Deputy CIPT), who is responsible for an entire module and many integrated product teams (IPTs). This contrasts with prior work where the primary focus was at the IPT level [Rowles, 1999; Mascoli, 1999]. This is shown schematically in Figure 8 of the P&W organizational structure. Note that there is some overlap in the people used, but the people used in this work are primarily referred to as design experts and system engineers in the prior work. 32 Rowles used "design experts" to develop his architectural DSM. The specific employees that Rowles used were what are now referred to as discipline chiefs within the Module Centers. Rowles then utilized several systems engineers to validate the work of the discipline chiefs. While this may appear to be similar to the present approach, Rowles work was developed from the Module Center perspective and then checked by the system engineers. While subtle, it is different than the present work. Upon detailed comparison of Rowles work with the present work, the identical situation is present when Mascoli's work is compared to the present work. In both cases, ~10 of their "system" parameters have been expanded into -100 parameters while the majority (60-100) of their parameters have been collapsed to 10 parameters. The work of Glynn and Pelland on the communication flow included the majority of the product development organization [Glynn and Pelland, 2000]. The parameters to be used in the DSM where obtained from written sources and from the system engineers experience. The types of documents that were used were all proprietary documents within P&W and are as follows: Design tables, internal training manuals, product reviews, FAA certification reports, Model Integrated Product Team reviews, airframe manufacturers requirements documents, and Chief Engineer's meeting presentations. Current PS/CRDs were specifically not used to define the list of parameters such that a later comparison could be made to determine what overlap and omissions were present between the documents. The list of variables was developed and reviewed by system engineers within System Design & Component Integration and Propulsion System Analysis (two of the three system engineering organizations within P&W). The entire list was then grouped and narrowed to focus 33 the list on what was considered the variables that would define the gas turbine engine to a knowledgeable outside expert. A list of 110 variables was developed. Chief Operating Officer VP Engineering VP Operations rModule PD&V Test ngineering Manager -- Certification Other CIPT Leaders (6) - -- Performance Engines Business Ctr Manager (4) Tech Manager GP7000 Secondary focus of current work PW6000 - Operability PSA Centers (3) - Center - VP Programs Prime focus of current work (secondary focus of prior work) Software Discipline Ch-es Design Managers CIP Ldr. PW4000 SD&CI Secondary Flow ------ -- PW4000 --------------IPTs - Functional Systems Orgs Other Programs Prime focus of prior work [Mascoli, 1999; Rowles 1999] Figure 8: Sets of the P&W organization utilized in various work. The method that was used to develop the interactions was to have the system engineers and other design experts in a room 2 or 3 at a time and to project the DSM onto a large screen from the computer. The design relationships were then discussed utilizing the particular expertise and knowledge of the system engineers in the room. Discussion between the engineers proved to be one of the most useful aspects of accomplishing the development of the interactions 34 in this manner. The development of the list of parameters and their interactions was accomplished in a series of one-hour meetings. These meetings occurred 2-4 times per week over a three-month period. This practice is different from most DSM work where one-on-one interviews and surveys are sent to experts. By using a participatory methodology, a consistent set of definitions and model of the gas turbine engine emerged. Specific relationships that applied to one PW4000 model but not the others were not included in the matrix. In this way, the matrix may be thought of as a platform model. For any specific design, the DSM would need to be tailored to the specific architecture. As has been discussed in prior work [Rowles, 1999], one trend of system engineers and design experts is to assume all parameters are related to all other parameters. This tendency to believe in full interaction was found to be common during the development of the current DSM. This belief was overcome by developing definitions and relationships within the parameters for direct interaction versus indirect interaction. In general, it was found that all interactions the system engineers believed were present could be found by tracing through direct relationships to get to the variables thought to be related. Thus, there are many indirect relationships that are considered important by the experts. Direct and Indirect Parameter Interactions within the DSM The distinction between direct and indirect interactions within the DSM was developed early in the work and was refined continuously as the situation merited. The working definition developed was that the parameters needed a mathematical relationship (or the possibility of such a relationship) to be considered a potential direct link. However, the presence of a mathematical 35 relationship was not sufficient to deem an interaction a direct relationship. It was quickly realized that with a series of mathematical equations, the equations could be combined and reworked such that again all parameters can be related to most other parameters. Thus, a second constraint was added that the relationship should be as simple as possible. While this constraint is subject to interpretation, system engineers are used to ambiguity and this constraint was very powerful in practical use. Third, if an indirect relationship could be thought of that explained the perceived direct relationship of variables within the DSM then no direct relationship was entered into the matrix. When applying these constraints on direct interactions, it was found that the aerodynamics of the engine could be used to separate the variables into groups and determine generic relationships. For example is was found that using core airflow as a general group and treating all the airflow parameters identically helped simplify the thought process and maintain consistency within the matrix. As an example, for core airflow the general mathematical relationship between the variables is conservation of mass. Thus, Fan Flow Capacity (airflow) has a direct link to LPC Flow Capacity has a direct link to HPC Flow Capacity. Stability Bleed flow has a direct link to HPC Flow Capacity, but it only indirectly links to the LPC Flow Capacity. To continue this example, HPC Flow Capacity and the HPC PR (pressure ratio) directly define a line called HPC Op Line. Similarly, the LPC Flow Capacity and the LPC PR define the LPC Op Line. As surge margin in a gas turbine engine is an important safety measure, it is defined as the Op Line subtracted from the stall line. The stall line is a parameter defined by the physical module design. Thus, Surge Margins are defined as directly related to the Op Line and the Design. 36 The system engineer may know that the Stability Bleed is used to change the HPC Bodie Surge Margin. In the DSM, this is accounted for in the following manner: the Stability Bleed is directly related to the HPC Flow that is directly related to the HPC Op Line that is directly related to the HPC Bodie Surge Margin. This one example is typical of the interactions and tracing of the "known" relationships through the DSM. The tracing of indirect relationships through the DSM was one method used to validate DSM. Validation of the DSM Validation of the DSM was accomplished in several ways. First, the use of many system engineers and their discussion of the interactions amongst themselves proved to be valuable in both developing the relationships as well as their mental model of the system. Second, the tracing of direct relationships to verify a known indirect relationship was used extensively while the matrix was being developed as well as after completion of the matrix (see Bartkowski, 2001 for several additional examples). Tracing of past areas of difficulty (many times called mistakes) through the DSM proved to be both valuable for validation as well as interesting and insightful to the system engineers. Third, the DSM was validated using lecture notes and textbooks from a course in gas turbines offered at MIT [Kerrebrock, 1992]. This material was used to validate both the direct interactions as well as the groupings of parameters and mathematical relationships between the variables. Finally, during subsequent analysis by both developers of the DSM (the author and Bartkowski), the interactions were validated. In the author's case, this was primarily accomplished by understanding the results of partitioning and tearing of the DSM. The parameters used and their identifying number are given in Table 1. 37 Table 1: Parameters and their unique identifiers used throughout this thesis. 1 Low Rotor Speed 2 High Rotor Speed 3 TSFC 4 LPC Stability (Op Line) 5 HPC Stability (Op Line) 6 Acceleration Time 7 Deceleration Time 8 Fan Op Line 9 Fan Design 10 LPC Design 11 HPC Design 12 Corrected Main Oil Pressure 13 Main Oil Temperature 14 Take Off Thrust 15 Reverse Thrust 16 Emissions 17 Noise 18 LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 20 HPC Bodie Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (Altitude) 22 HPC Accel Surge Margin 23 LPC Surge Margin (Max Climb) 24 LPC Surge Margin (Cruise) 25 LCF Mission (Flight Cycle) 26 Flight Envelopes (Alt, MN, Temp) 27 Typical Operating Mission 28 Burst Margin 29 Rotating Part Life 30 Vibration Low Rotor 31 Vibration High Rotor 32 Engine Weight 33 Bird Loads 34 Fan Blade Out Loads 35 Nacelle Thermals 36 External Component Thermals 37 Nacelle Drag 38 ECS Bleed 39 TCA 40 TCC Bleed 41 Starting Bleed 42 Stability Bleed 43 Thrust Balance 44 Nacelle Cooling 45 Air Oil Coolers 46 Buffer Cooler 47 HPT/LPT Leakages 48 HPT/LPT Clearances 49 Anti-Ice Bleed 50 Diff/Combustor Design 51 Life Cycle Cost 52 Manufacturing Cost 53 Airline Operating Cost 54 In Flight Shut Downs 38 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 Unscheduled Engine Removals Shop Visit Rate Engine Change Time TMC Delays and Cancellations Fan Flow Capacity LPC Flow Capacity HPC Flow Capacity Burner Flow Capacity HPT Flow Parameter LPT Flow Parameter Fan Exit Area Jet Exit Area Fuel Flow Total Inlet Temperature/Profile HPC Inlet Temperature/Profile Burner Inlet Temperature/Profile HPT Inlet Temperature/Profile LPT Inlet Temperature/Profile Exhaust Gas Temperature/Profile Fan PR LPC PR HPC PR Burner dP HPT Expansion Ratio LPT Expansion Ratio Fan Efficiency LPC Efficiency HPC Efficiency Burner Efficiency HPT Efficiency LPT Efficiency LPT Design Fan Nozzle Performance Primary Nozzle Performance Duct Losses HPC Clearances Low Rotor Inertia High Rotor Inertia Control Stability Time to Light Time to Idle Burner Blowout Margin Stator Vane Schedule Ambient Temperature Warranty Cost 2.5 Bleed Engine Pressure Ratio Control Laws Fan/LPC Tip Clearance Fuel /Air Ratio HPT Design Nacelle Design External/Control Design Mechanical Components Design 110 Fuel-Oil Coolers 39 Baseline DSM The baseline DSM developed for this work is shown in Figure 9. No immediate structure was obvious. By grouping of the parameters by areas of responsibility (i.e., imposing the current organizational structure), some structure begins to emerge in the DSM (Figure 10). However, there is no neat clustering of the interactions as found in previous work of Mascoli and Rowles. Bartkowski explores organizational and manual methods of organizing the DSM in more detail. This work focuses on mathematical partitioning and tearing of the DSM. Partitioning and Tearing the Parameter DSM Partitioning of a matrix involves reordering of the elements such that as many of the interactions as possible are all in the lower portion of the matrix (termed lower triangular). By ordering the elements in this way, information and interactions flow from one parameter to the next without any feedback. When a lower triangular matrix is not possible, partitioning may break the matrix into several sections with coupled blocks. Partitioning is not clustering in that no weighting is used to bring the upper triangular dependencies close to the diagonal. Partitioning makes no attempt to order items within a coupled block. In a lower triangular matrix, a designer may determine the values of the parameters in the order of their listing and while doing so have complete information to determine the parameters. As a designer proceeds through the listing of parameters and a parameter has a feedback from a later parameter, the designer must make an assumption concerning the value of the parameter that has yet to be determined. By making this assumption, the designer is then able to determine 40 56 Shop VisitRate 0- 27 28 29 30 31 32 33 34 36 35 37 41 42 38 3 40 43 52 54 9 W51 8 46 4 4445 5 57 66 9 6 6 7 7 7 _5 7 0 7 8 6 3 9 791M 8 w3 4 0 8 5W 91 ----- - 1 - _ 0 0 - 0 0 --- S0 0 0 o 0 0a 0 0 0 0 0o 0 -- o _0 ___ 0 o 0 0 a 0 0 0 0 0 0 S S00000 0 -______o _ a- 0 o 0 00 - -- O w 1 0 0 00 0 u11 0L 0I 0 S0 0 a a 0 0 0 0 - 0 0 0 0 S0 -D0 _ 0 a0 0 0 . 00 . a0 0 0 0 -00 0 0 0 0 00 0-a G 0 0 _ -0 - ----- 0 0 -4 -- -0 --0- 0 a 00 U 00 00 00 00 0 U0 _ |0 0--- o-- o0 a0I-T 0 ---- 0 l0 10 10 0 1 0 0 0 - - - 0 0 0al 0 0 1 0 MM- 0 0 0 0_ ol Efftaency 0 0 --- o o o 0 I 0 L 0 0 0 00 0 0 0 , 0 0 0 0 0 0 0 0 0 0 0 m a0 a 0 0 0 0 to Light 0 0 0 0 l 1 0 0 98 Stator Vane Schedule 99 Amient Temperature 00OWaaty Cos o --- -- -0 0- 0 0 10 0 Ratio 00 S 0 0 0 04 Fan/LPC Tip Cleance 05 Fel /Air Ratio 06 H-PTDsiga 1, Deiga 1 0 a 0 0 0 0 0 0 0 0 a 0 0 0 0 0 - -0 0 0 0 0 0 0 a 0 0 a - -0 Idle Tme ta Barner Blawaut Main, | 0 0 0 0 00 0,0 0 0 0 00 0 -- -- Perfomance HPO0Cleanxes Low Rotor Inertia High Rotor Inertia Control Stability 0 0 o 00 0 I 0 0 -0 S00 o0 1 0M 0 0 0 0 0 07 Nacelle Design 0sEx teDa s/G gtna l De s ig s 09 Mahanhtai CGampanents 0 Fad-Od Coolers 0 a 0 ) Exhaust Gas Temperature/Profile FanPR LPC PR SPC PR BaT ERdp LPT Expansion Ratio (PT EpFnsian Rato _ - 00- -0 0 0 1 0 0 -- - o o 0 - :--P --- - 0 00 -2- 0 0 o 74 75 76 77 78 79 80 01 25 Bleed 02 Egiae Pssure 03 Control La.s -- - - - - - - 0-. 0_ - Inlet 89 0 0 ------ _ 1 0 0 0 - 0 0 0 Temperature/Profile 82 LPG Efficienxy 83 HPC Effiency 84 Burner Eff ency 85 HPT Efficiency 86 LPT Efficiency 87 (PT Desgn 80 F.. NazzltPeforancex Pa mary Nozzle o 0 0 0 - 00C - -- 0 HPC Temperature/Profile InldtTrnpeiatara/PaofIa Barner SPIlet Tetapeaata1e/Poatle LPT Ilet Temperatare/Profle Time 26 00-- nd Caelations ap gacity 70 71 72 73 91 92 93 94 95 96 97 5 - 4 44 1 0 1 LPC Flow Capacity HPC Flow Capacity Burner Flow Capacity HPT Flow Paameter (PT Flaw Pwaraatw~ F..Fxit Aaa Jet Exit Area e1.Fan 24 - ------ 0 57 Engine Change Time 68 Fuel Flow 69 TotalInlet 23 S0 52 61 62 63 64 65 66 67 21522 0 Surge Surge 59 Dlaya 60 FFw 1213 14 2831611 Sped . Rotor 0 0 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 0 a 1 1 ,0 0o 1 | 0 0 0 _ 01 0 0 o 0 10 ---- - Itao 0 0 0 0 0 0 0 0 00 0 00 - - l0 - -- 67 Items 2 H CghRotor Speed 3 7060 4 LP0 Stabilty (Op ULi) 5 1-IF Stailty (OF Uim) 6 Aceleratin Tme 7 Decaleration Time 8 Fan Op Lim 9 F.. Dsign 10 LPC Design 11 HPC Design 12 Corected Main 0 Pressure 13 Main Oil Temperature 14 Take Off Thrust 15 Reverse Thrust 16 Emissions 17 Noise 18 LPC Takeoff Margin 19 HPCT/O Margin 20 HPC Bode Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (Aftitude) 22 HPC Accel Surge Margin 23 LPC Surge Margin (Max Climb) 24 LPC Surge Margin (Cruise) 25 LCF Mission (Fight Cycle) 26 Flight Envelopes (Alt, MN,Temp) 27 Typical Oprating Mission 28 Burst Margin 29 Rotating Part Life 30 Vibration Low Rotor 31 Vibration High Rotor 32 Engine Weight 33 Bird Loads 34 Fan Blade Out Loads 35 Nacelle Thermals 36 Extenal Component Themals 37 Nacelle Drag 30 ECS Bleed 39 TCA 40 TCC Bl ee 41 Stating Beed 42 Stability Bleed 43 Thrust Balance 44 Nacelle Coolng 45 Air Oil Coolers 40 Baffer Coler 47 HPT/LPT Leakages 48 HPT/LPT Clearances 49 Ant-a Bleed 50 Diff/Combustor Design 51 Ufe Cycle Cost Manufacturing Cost 53 Airline Operating Cost 54 Ia Right Shut Downs 55 Unscheduled Engine Removals -1 0EDE 1 Figure 9: Baseline DSM developed in cooperation with Glenn Bartkowski [Bartkowski, 2001]. 41 42 53 2 1 4 3 5 6 7 8 14 15 17 IS 19 0 53 Ailie Opeaing Cot 1 Lee Rotor Speed -__ - - - - -- - - 27 Typcel Opeating Mssion 0 .0 (1) 37 60 61 62 __ 'FU 63 Burmer Flow Capacity 64 HPT FlowParamete C 65 LPT Flow Parameter 66 Fan Exit Area 67 Jet Exit Area 68 Fuel Flow e E Ttait >1 71 72 73 74 75 76 Temperature/Profile Burner HPT inlet Temperature/Profile Temperature/Profile LPT Exhaust Gas TemperatureProfle Fan PR LPC PR - ___0_'___-__-_ ------0 (1) C: o e SO 8 W 0 o 00 _m ------ - - - M- -------M - - - -a a -- 0 0 -1 97 98 9 102 105 103 104 101 42 41 39 0 46 45 44 4 110 49 47 48 3 7--- 28 2M M33 92 93 32 30 31 - ------ o 11 9 91 06 87 07 50 35 08 --0 0 --- 0_- 4- - -- 09 12 13 0 -- 0-- -- - -- 0- -- 0 __ 0-- - a--- -- -- 0 - 0D 0 0 - - - - 0 - - ---- --- 10 0---00 - - - --- 36 --- - - -- -- - ------ - 0 S 00 0 - --0 --N --- --0--- -M -- - - - - 0 0 o 0 0 00 - --- - - - - - - - --------- --- - - -- -- - - ------------ ---- - - - - - - - -- - - - - ---- ------ ---- -- -- - - - - - - - - - - - -------- 6 00 1 0 0- -------- - ---- ---- - ----- - ---- ------- ~- 0 0 - 96 M4 M 9 --- -- - --- - --- --- - - - - -- - - --- - Nacelle Drag Fan Flow Capacity LPC Flow Capacdty HPC Row Capacity CD69 () 70 84 a5 - - ------------ 1Noise 1 LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 20 HPC Bodie Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (Altitude) 22 HPC Accel Surge Margin 23 LPC Surge Margin (Max Climb) 24 LPC Surge Margin (Cruise) 25 LCF Missin (Right Cycle) a2 a3 a 0 0 0 0HH---- ------------ rH - -- __ 15 17 80 81 - 7 Deceleaion Tim. 79 ----- 000 3 TSFC 8 Fan OpLe 14 Take Off Thust Reverse Thrust 76 77 7 74 75 0 2 High Rotor Speed 4LP Stabilty (Op Line) 5 HPC Stability (Op bne) 6 Acceleraion Time 73 - a. 70 71 72 . 9 Delys and Canellations 00 Warranty Cs L-. 69 0 -- 57 EngineChange Time 67 W8 -o0 - 0 ---- ----------- 0-0---0 0 -- prlr/rfl HPC Ictlotetmperahee/Peeofle - -- ----------- - - - - - ---------0---------- ------- --- --- -- -- -+-- -0 --- - -- - ----- -0-- - IN - -- -- - - - -0___00 0 Inlet inlet 0! 0 - - ------- ----- 0 0 - - 52 Manetactwng Cost 54 In FlightShutDowns 5 neduldEngineRemovals E 64 65 66 - O 63 - m 1Ut Cycle Cost 60 61 62 2 23 24 25 27 37 21 2M - 57 58 59 100 - 54 5 56 - 5 - 51 26 Flight Envelopes (At, MN. Temp) 0a 1 0 I 76 BerdP 792 HPT Expansion Ratio 80.LPT Epa nRatio 81 Fee Efficency - 82 LPCEienocey 83 HPO Efficiey 84 85 86 88 Sumer.Efficencoy HPT Efiiencey LPT Eficencey Fee Nozzle Perormacec - --- ------ - 0 Lase.s a - - - -____ 94 Catro Staility 95 Time to Lght - - --- - - - 7 - - -- 0 --- - 0 - - : - -- - ------ 0 0- -0- 89 Primary Nozzle Perfomance 90 Duct -M - - - -D- a --- ------ - -- - - - - - - --- -- -- ----- -- -- --- -0 - 0 0__0 _00 _____- - -- --0 - - 0 -- 0 - 77T7 HPC PR --- -- 0 -- 0 :7 77 7jo 0 10 0 96 Time t Idle - - - -- - - -- - Ratmo 05 Fuel /Ai 03 Conrol Las 04 Fn/IJC Tip - Clearance - - - - -- - ------- - 01 25Bleed 42 Stablity Bleed 41 Sart 39 TCA j 45 Air Oil Coolers 44 Nacelle Cooling 10 Fuel-Oil Coolers 38 ECS Bleed 49 Anti-Ice Bleed 4M C - S8 0 3 4 0 0 0 - - - 6 9 Fan - 7- -- - - - ----0 --- - - 0- - -0 ---- -0- - 0 - ----- - - -- -- - - -_-- ---0- - -- - -00-0 000 F-T 0-- - Design 0 a0 00000006 o 0 00 00 - - 0 0 ------ - 00 -- 0 - - 0 = 00 00 0 0 o- 0 0 --------------- 10 LPC Design 11 HPC Design 0) C) Q) O FPC leacracee 06 HPT Design 50 DffComhaetor Deigc C) Nacee Desgn 35 Nacele Thermals 08 EteccaS/Coto Deeign >% 91 87 LPT Decig E ) -- ----- M-- - - - - - - --- -- -- - - - ------ nlae OtLod 93 HighRotorInertha 32 Engine Weight C -- - --o ----------- - --- - -- 0 0 ------- ------- -0000 - otor 31 VibahionHghn E - - -- - -- --- 0 29 Relating Part bLie 30 Vbrationc jee Rte. Q) C - - --- 47 HPTILPT Leakages 48 HPT/LPT Clearances -0 --------- ------- __- 40 TCC Bleed 43 Thrust Balance 46 Buffer Cooler C o -- - - leed -- - - - - ----- - - - -- - - 97 Bumer B eel Margin 98 Stator Vane Schedule 99 Ambient Temperature 02 Egine Pessure Ratio ---6.-00--- - 26 16 Items 07 Themals 36 Extemal Com pet 09 Mechanical Components Design 12 Cerected Man Oi Pessure 13 Man Oil Tempeatue Figure 10: DSM organized by the organizational structure. 43 44 the parameter of interest. Later in the development, the assumed parameter will be determined and, depending upon the difference in the assumed and later determined value, an iteration cycle may be deemed necessary. Thus, the process of determining what is assumed and when it is assumed can significantly change the nature of the product development cycle and the preferred order for determining the parameters. Requirements and their determination are intricately intertwined in the process of making assumptions that may later force iteration. One method of avoiding iteration (and thus improving the cycle time) is to make the initially assumed values the requirements. In this way, all designers use this same assumption and the final product must conform to the requirement. Enforcing requirements and not allowing for iteration will most often result in a sub-optimal design. In this case, the trade between cycle time and optimization of the product must be made. In most industry product development processes, the actual requirements are usually flexible (robust) to a (sometimes) known amount. Thus, in practice neither the requirements are unchanged nor are the iteration cycles allowed. The science (and some art) of setting robust design requirements is an entire field of study and will not be covered here. Assumptions may be made in a DSM by first partitioning the matrix, and then ignoring individual interactions and repartitioning. This process is known as tearing a DSM. Overviews of tearing can be found in Steward's book [1981] and at several websites [PSM32, 2000; MIT DSM, 2000]. Repeated tearing of a DSM allows one to identify particular orders of parameters that may prove more resistant to iteration than others. The present work examines various sets of 45 assumptions and the resultant torn DSM and discusses implications of these assumptions within the product development cycle of gas turbine engines. Partitioning and tearing of the DSM in this work was accomplished with the software package PSM32. Don Steward and his collaborators developed this package for use within the DSM community [PSM32, 2000]. The package partitions a matrix and allows up to 9 additional levels of assumptions to be made.' Individual interactions between two parameters can be assumed or a systematic assumption may be made about a parameter. The first systematic procedure is to assume a value for a single parameter. Following this assumption, this value can be used to determine all other parameters prior to the assumed parameter being determined (tearing by column in the matrix). Tearing by column will force the parameter to be one of the last parameters to be determined (i.e., the parameter is moved to the bottom of the coupled block). The second systematic procedure is to make assumptions about all the inputs to a single parameter that have yet to be determined and then determining the value of that parameter (tearing by row). Tearing by row forces the parameter to be one of the first to be determined (i.e., moved to the top of the coupled block). Tearing by row is similar to setting a requirement or constraint that must then be used in all subsequent parameter determinations. In general, tearing by column is often the preferred method as it only needs to assume a value for a single parameter. However, both methods are utilized throughout the current analysis. 'Additional levels of assumptions may be made within the program by a hierarchical method of using the tearing numbers. The current work limited itself to 9 levels of assumptions. 46 The PSM32 software package makes suggestions as to which parameters will break the longest linkages of parameters (circuits as Steward refers the them). In this manner, the matrix may be pushed to a lower triangular form. The suggestions made by the package are not unique, but could be changed within a small set of choices by having a different initial order in the matrix. For the current analysis, initial circuits found by PSM32 were between 55 and 60 parameters long. When tearing a matrix, one must proceed with caution when accepting the program suggested parameters. Only with detailed knowledge of the product and the product development process can one know whether making the suggested assumption is possible or would be acceptable to the product development organization. This work examined the acceptance of the program suggestions as well as other means of determining which parameters may be assumed. As is discussed in Chapter 4, the order and types of assumptions made was found to vary with the stage of the product development cycle. The initial partitioning of the matrix resulted in an almost trivial answer (Figure 11). Two parameters, Flight Envelopes and Ambient Temperature, were moved to the top of the matrix. This is reasonable, as Flight Envelopes are normally give to the engine companies as requirements from the supersystem (the aircraft). Although there may be feedbacks between the engine and the aircraft that help determine the flight envelope, from the perspective of the engine as system, the flight envelope can be considered a requirement and thus, should be one of the first things determined. The ambient temperature is just the air temperature throughout the flight enveloped and is not altered by anything within the engine. Ambient temperature follows directly from the flight envelope requirement. Next there is a large block of 94 items that are interdependent. Finally, there is a small section of 14 parameters after the large interdependent 47 block that is indeed lower triangular. These variables are known to be the emergent properties of the engine system. The variables are items such Airline Operating Costs, Delays and Cancellations and other highly dependent variables. Overall, not much information could be obtained from a single attempt to partition the matrix. Apparently, the view that almost everything is related to everything else is true, at least from a cursory examination. The next step in the analysis was to tear the matrix by making various assumptions. In order to gain and experience with the tool and with tearing, the initial tears were made using the program-suggested variables. An interesting aspect of this was that the program consistently suggested many of the Design parameters (e.g., HPC Design) as the parameters which to assume. In addition, the Control Laws parameter was often suggested and appears to be similar to the module designs as far as the level of interdependency. From these first trials, it became apparent that a group of 10 related variables (Fan Design, LPC Design, HPC Design, Diff/Combustor Design, HPT Design, LPT Design, Mechanical Components Design, Externals/Control Design, Nacelle Design, and Control Laws) should be treated similarly. The fact that the Design variables should be related and that they are the first variables suggested is logical given the initial setup of the DSM. In essence, by adopting a system perspective, the designs of the modules become individual parameters that are highly interdependent with the system level parameters. Each Design parameter in the current DSM is a block (cluster) in Mascoli's DSM (except for modules that Mascoli chose to ignore for the sake of time). To more fully integrate the information from Mascoli's work, each Design parameter could have been replaced by the 48 1 2 4 6 5 7 10 9 11 Q 13 U 15 17 18 19 20 21 2.2 23 24 25 27 W 28 31 M M 35 W 37 W M 40 41 42 43 45 46 47 48 49 50 52 57 58 60 0 0 0 - - 0 0 61 63 65 1 01 0 - 62 66 -0 67 69 70 71 72 73 74 75 78 79 80 81 52 83 84 87 W 8 W Z 90 91 92 --- 94 93 0 98 02 03 06 04 07 08 09 0 0 0 00 0 0 0 - 1. 95 97 - - - -Fl. 10, 1.7 101-1-1 0 0 0- 0 0 0 a _0 0 o t -- o 10 -- - 0 0a 0 0 0 a 0 0 0 0 a o 01 0- 0 0 0 0-0 0 0 0 0 N_--- 77 0 --- -o 76 0 0 00 68 - 99 0 I-. Ml- 0 0 0 -30 - - - - - o - 1 1 o 0 0 P F o _0 4 0 o t G o a 0 _0 01 a a -L. -- - --- - - - - - - 00 Ml 11 1 1 -1 - 0 4-0 - - - - - a0 - =:: -- -- --- - 0 0 0 ol 0] 01-1 Lt 01 0 - 1 0 10 , -44- 0 I of I I -- ol o 0 I ol 0 0 0 0 -D 000 al0-0 t--l 0 -I +i 4q5-- 0 -- 1 0 0 0 0 - 0- 0 0 - - - - - - ol NMI 0 o o o o o 0 00 ON 0 0 -- 447-. 0 fio 0 I 0 1 1 a 0 0 Ol 0 I I 1 1 1 0 0 a 0 0 0 0- a -0 0 0 0 _0 -0 1 01 0 0 0 0 0 0 0 0 0 0 0 0 1 a 0 0 0 --- 0 m 0 D 1 0 1 1 I 1 0 0 0 0 0 ON- I 0 --- I- T 0 Fo Om ol 0 I 0 0 1 1 - -0 - -+- - --- i -t- 4 ---- - - - - - 0 0 0 0 - - - -10-. 00 O 0 -0 0 0 0 --- 0 0 0 - 0 0 0- 0 -0 oo a 0 6 -0 -0 -0 0 0 0 0 0 0 a 0 a 0 0 0 01 000 000 0 Ol a Ol I I 01 01010-O-J-Ffl 11 10 1 a0--0- 0 I I F 0 0 0 0 0 0 0 0 O -- f, 0-0 0 0 0 - I O 0; 1 Of , 0 0 0 0 0 al 01 01 0. I ol ol a0 - - - - - -- - - - - - a -0 0- 0-6 D 0 076 ON al ---- - - - - - - - - - -- - - -T, -11 0000a 11 11 0Oll 0 0 1--F- 0 0 0 0 0 0 0 - - -- 0 _0 0 0 0 0 0 O a a 0 - 0 0 01 0 0 I - 11 0 0 0 I 1 0 0 j0 0 - 0 I %M 0 ---- 0 . -0 0 0 _0 0 0 Ol -++ 0 0 0 --o 0 - 0 of ol 0 0 al a 0 0 01 a 1 0 0 10 0 ,lil. ol 0 0 a I 0 0 0 o 0 Ol J i - 0 0 I a I 0 1 0 14 I I o I _0 0 0 0 I 0 a 11 I 1 1 1 I Oi OF ol 1 I 0 0 0 0 0 0, I - 0 1 0 a -14- I - I a - a 01 I 0 - 0 01 o 0 a a 0 0 0. ol 0 0 0 0 FF -V=7 a 0 0 0 o 0 --- - 26 26 Flight Envelopes (Alt, MN, Temp) om99 Ambient Temperature I Low Rotor Speed 2 HIO Rotor Speed 4 LPC Stability (Op Line) 5 HPC Stability (Op Lim) 6 Acceleratior Time 7 Deosteratim Time 9 Fan Design 10 LPC Design I I HPC Design 12 Corrected Main 01 Pressure 13 Main Oil Temperature 14 Take Off Thrust 15 Reverse Thrust 17 Noise 18 LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 20 HPC: Bocke Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (Altitude) 22 HPC Aocell Surge Margin 23 LPC: Surge Margin (Max Climb) 24 LPC: Surge Margin (Cruise) 25 LCF Mission (Right Cycle) 27 Typical Operating Mission 28 Burst Margin 29 Rotating Part Ufa 30 Vibration Low Rotor 31 Vibration Kgh Rotor 32 Engine Weight 33 Bird Loads 34 Fan Blade Out Loads 35 Nacelle Thermals 36 External Component Thermals 0 37 Nacelle Drag 38 ECS Bleed 39 TCA 40 TCC Bleed 41 Starting Bleed 42 Stability Bleed 43 Thrust Balance 44 Nacelle Cooling 45 Air Oil Coolers 46 Buffer Cooler 47 HPTA-PT Leakages 48 HPTA-PT Clearances 49 Anh-lce Bleed 06t-J--ItI 111 I 50 Diff/Combustor Design 52 Manufactur-ing Cost 57 Engine Change l'irm 58 TMC 60 Fan Flow Capacity 61 LPC Raw Capacity 62 HPC Flow Capacity 63 Burner Flow Capacity 64 HPT Roiv Parameter 65 UPT Rovv Parameter 66 Fan Exit Area 67 Jet Exit Area 68 Fuel Flow 0 0 69 Total Inlet TemperaturelProfile 70 HPC Inlet Temperature/Profile 71 Burner Inlet Temperature/Profile 72 HPT Inlet Temperature/Profile 73 LPT Inlet Temperatute/Profile 74 Exhaust Gas Temperature(Profile 75 Fan PR I I 76 LPG PR 77 HPC FIR 78 Burner dP 79 HPT Expansion Ratio 80 LPT Expansion Ratio 81 Fan Efficiency 82 LPG Efficiency 113 HPG Efficiency 84 Burner Efficiency 85 HPT Ef1k:ierii:y 86 LPT Effkwwy 87 UPT Design 88 Fan Nozzle Performance 89 Primary Nozzle Perfornanoe 90 Duct Losses I i 91 HPC Clearances 92 Low Rotor Inertia 93 Hgh Rotor Inertia 94 Control Stability 98 Stator Vane Scheclule 101 2.5 Bleed 102 Engine Pressure Ratio 103 Contral Laivs 104 Fan/LPC Tip Clearance 106 HPT Design 107 Nacelle Design 108 Externall/Control Design 109 Mechanical Components Design 110 Fuel-Oil Coolers 3 TSFC 8 Fan Op Une 16 Emissions 54 In Right Shut Dovms 55 Unscheduled Engine Removals 56 Shop Visit Rate 96 Time to Idle 100 Warranty Cost 105 Fuel lAir Ratio 95 Time to Light 97 Burner Bknvout Margin 59 Delays and Cancellations ---00-9 . 53 Airline Operating Cost 51 Ufa Cycle Cost - Items - - - - ON m 0 0 -0 -a - - - I I I Ol m Figure 11: Partitioned DSM with large block of interdependent parameters. 49 50 approximately 10 variables of each module in Mascoli's work [Mascoli, 1999]. Although this may have resulted in different coupling of the parameters, it was not done in order to maintain a consistent perspective in the DSM. In the current work, the Design parameters become the parameters that most DSM practitioners refer to as the system parameters that are quickly moved to the top or bottom of their list and eliminated from further consideration. This work suggests that what is viewed as a system in an individual work depends entirely upon the perspective of the developers. System in one view may just be a subsystem or supersystem in another perspective. This supports the view that DSMs may be structured hierarchically and could easily be developed and interlinked with web-based technologies. Such a hierarchical system with approximately 1000 parameters exists at Boeing [Stowe, 2000]. Developing an order within the Design parameters required examination of the literature and industry practice as no discernable pattern was apparent within the PSM32 suggestions. In his examination of platforms within the gas turbine industry, Moy concluded that the HPC is the platform of a gas turbine engine [Moy, 2000]. Thus, the HPC Design should be the first design parameter that is assumed. Given its physical and parametric interactions with the HPC as well as the technology limitations, the HPT Design should be the second design parameter assumed. This completes the high spool of the engine that many long time gas turbine practitioners feel is the platform of an engine. Next, the low spool of the engine should be assumed. For the PW4000, the fan, LPC, and LPT are assumed in this order based upon the difficulty of the available technology and industry experience. The Diff/Combustor is next and is the only non-rotating module in the aerothermal design. These first six design parameters represent the aerothermal and structural design of the engine. The Mechanical Components 51 Design (the bearings and the associated oil and fuel systems including the gearbox) should be the first non-core design assumed followed by the External/Control Design and the Nacelle. This order works from the inside of the engine out with the outside of the engine (the nacelle) being the item that the public views on the aircraft. The relegation of the nacelle to be the last assumed may not be appropriate as this is a significant interface with the aircraft. (In fact, it is such a large interface that Boeing considers it part of their design responsibility while Airbus utilizes the engine companies or third parties to design nacelles for their aircraft). This ordering again is linked to the arguments on perspective of the DSM developer. Since the perspective of the present DSM is engine centric, the nacelle is the last design to be assumed. Table 2 summarizes the sequence and reasons for assuming the design parameters. Table 2: Sequence and reasons for assuming module design parameters. Order Assumed 1 2 3 4 5 6 7 8 9 Design Parameter Explanation HPC Design HPT Design Fan Design LPC Design LPT Design Diff/Combustor Design Mech Comp Design Externals Nacelle Platform for engine [Moy, 2000] Tightly coupled to HPC and technology limitations Available technology and historical difficulty of low spool Historical difficulty of low spool Historical difficulty of low spool Completion of aerothermal design Importance of bearings and mechanical systems Usually the last thing designed Outside of engine (only sometimes part of engine) Figure 12 and 13 represent the DSM partitioned after the Design parameters were torn in the order described above. Figure 12 represents the matrix when the parameters are torn by column (i.e., an assumed design is used for the calculation of most other parameters prior to the designs being completed). Figure 13 represents the matrix when the parameters are torn by row, 52 99 93 47 92 67 . . , I INS HPTfLPT Leakages Low Rolm Inertia Jet Exit Area Burrw Efficiency 49 90 32 37 94 33 21 85 82 6 22 7 38 30 12 34 73 15 81 70 39 46 45 41 98 42 20 10 13 68 78 89 65 79 80 1 76 4 24 01 66 35 75 02 14 27 G4 61 69 43 77 I 5 I 2 31 91 33 71 72 48 64 63 62 I i I i I - I --- T---- T-- i 86 74 " 60 40 03 52 36 88 117 I I I I i I2 1 2,73 6 7 6 7 7 - - - 9 --- 4 8 16 54 55 56 96 00 05 95 97 59 53 51 5 Ol 9 8 0 0. 0 0 0 0 -------------- ----- - -- -- - - - - ME 0 0 1 0 0 7 0 Ol 0 0-0 ONE- m--O -0 0-- 21 31 0 0 00 000 0 or 0 1 21 0 0 0 0 0 0 0 0 1 t aI I I 1 1 OlI I I I I I I I I I 1 1 1 1 1 111 1 1 1 81 -A .. I I I . I I I 49 A i I . . I I . . i i i I - iN MIN 0 1 O 1 1 1 71 I-1 i I21i 0-- 1 61 71 f 21 A AL.. 0 0 0 0 - 5 Ol 0 m 5 - a ON Om 0 0 0 6 0 0 0 7_ 0 m 5 10 0 - 7 ON ----- 0 0 d 0-- 1- - - - - --- - 1 0 0 0 0 - - - - - - al - 67 a=0 - - - - - 0 0 0- am 6 0 0 ON 0 0 01 5 4 2 - - 0 0 0 4 4 0 -bi- o 0 I -- I I a N 0 io 0 00 0 1 3 ON 0 - - - - - - - - - a - 0 0, ON OF 2 0 0 0 0 0 01 0 0 0 a 0 0 1 01 0 0 0 0 0 0 0 0 Om- 1 ---- - F-o F -0 0-0- 0 0 ol -410 0 a 0 0 0 0 0 0 0; 0 0 0 a 0 0 0 - +O 0 O-iV 7 3 2 0 010-2 0 0 a 0 0 2 0 0 0 0 0 0 0 ol 0 3 4 5 6 3 4 5 6 4 5 6 t7l 9 -9 1 0! 0 a 0 O 0 0 0 0ol al 0 0 0 a a I 0, 0 0 -0 0 21 0 0 i , iI 0 1 1 1 0 1 ol 0 0 0 0 .1 1 0 0 0 0 0 0 0 0 a 0 0.0 G- [ 0 0 0 I i 1 01 1 0 1 1 0 o 0 1 01 1 Ol 1 1 io 01I 1 1 I I 0 74+,J 71, oi L 1 1 1 i i 1 1 1 1 IL-P. I I I I I i 01 i -4-4-7 1 Al oll I i I I I i i I I 1 01 ol ol I I I 1 1 ol I nl I vi I ol I I I I I I i Ol 0 1 1 1ol 1 I I ol 01 ol ol ol ol 1 1 1 1 1 i 1 1 1'1 11,1-'!I 1 1 1 It i I1 1 1 1 1 i P 1 1 1 Ii 4 I I I I I I 1 I I I I I I I I I I I I I I I I I I I I I I i I I ; I InI I I I I I I I I I I I I I I I I I I 1 1-1 I I I I I I I I I I I I I ni A ) I I I I I I I i I ol ol ol 1 i n i I i 1 1 I1 I1 1 1 1177 II olI I I I I I I I I I ol 1 1 1 1 1 1 10 1 I ol o I 0 ol ol 0 j 01 ol 0 0 ol ol ol 01 0 0 ol ol ol ol ol o I i1 01 1 1 1 -- L I I 0 0 0 ol ol 0 0 40 0 o -----F--F- -- F-T-F 1 01 1 1 I I I 0 0 0 I I f I I ol I I I I -T-FF I I I I I. I. . .o l. I. . . . . I t F Ilii i 0-000 - 0 - - I ! -o --- 0 0 a 19 HPCT/O Surge Margin I I HPC Design TSFC Fm Op Lim Emissions In Flight Shut Dovvris Unscheduled Engine Removals Shop Visit Rate Time to Idle Warranty Cost Fuel /Air Ratio Time to Light Buimer Blov out Margin Delays and Cancellations Airline Operating Cost Life Cycle Cost :: := 3 11 8 8 5 5 5 '7- r7 , 28 Burst Margin 87 UPT Design 18 LPC Takeoff Surge Margin 23 UPC Surge Margin (Max Climb) 10 LPC, Design 9 Fan Design 106 HPT Design 9 06 19 07 25 57 29 58 08 09 50 28 87 18 23 10 Anti-Ice Bleed Duct Losses Engine Weight Nacelle Drag 94 Control Stability 33 Bird Loads 21 HPC Bodie Surge Margin (Alfitude) 85 HPT Efficiency 82 LPC Efficiericy 6 Acceleration Time 22 HPC Accel Surge Margin 38 ECS Bleed 7 Deceleration Time 30 Vibratiori Low Rolm 12 Corrected Main Oil Pressure 34 Fan Blade Out Loads 73 LPT Inlet Temperature/Profile 15 Reverse Thrust 81 Fern Efficiency 70 HPC Inlet Temperature/Profile 39 TCA 46 Buffer Cooler 45 Air Oil Coolers 41 Starling Bleed 42 Stability Bleed 20 HPC Bodie Surge Margin (Sea Level) 98 Stator Vane Schedule 110 Fuel-Oil Coolers 13 Main Oil Temperature 68 Fuel Fkwv 78 Burner dP 79 HPT Expansion Ratio 80 LPT Exparision Ratio 89 Primary Nozzle Perfornance 65 UPT Fknv Parameter I Low Rolm Speed 76 UPC PR 4 LPC Stability (Op Lim) 24 LPC Surge Margin (Cruise) 101 2.5 [Need 35 Nacelle Thermals 66 Fari Exit Area 75 Fan PR 102 Engine Pressure Ratio 14 Take Off Thrust 27 Typical Operating Mission 69 Total Inlet Terriperature/Profile 104 Fan1LPC Tip Cliaaran ce 61 UPC Flovw Capacity 43 Thrust Balance 77 HPC PR 5 HPC Stability (Op Line) 64 HPT Fim Parameter 63 Burner Flm Capacity 62 HPC Flow Capacity 2 High Rotor Speed 31 Vibratiorr Hgh Rolm 91 HPC, Clearances 83 HPC Efficiency 71 Bumer Inlet Tempwature/Profile 72 HPT Inlet Temperature[Profile 48 HPTALPT Cleararices 86 UPT Efficiency 74 Exhaust Gas Temperaturs/Profile 44 Nacelle Cooling 60 Farr Flo v Capacity 40 TCC Bleed 103 Coritroll Laiws 52 Manufacturing Cost 36 External Component Thermals 88 Fari Nozzle Perfmirnanice 17 Noise 107 Nacelle Design 25 LCF Mission (Flight Cycle) 57 Engim Change Time 29 Rotating Part Life 58 TMC 108 Extemal/Control Design 109 Mechanical Components Design 50 Diff/Combustor Design 3 8 16 54 55 56 96 100 105 95 97 59 53 51 84 - 26 - 47 92 67 64 49 90 32 37 - - 26 Flight Envelopes (Alt. MN, Tamp) 99 Ambient Temperature 93 High Rolm Inertia 0 0 0 101 1 I 10110 10 ol . Items 10 0 0 Figure 12: The DSM with the Design parameters torn by column. 53 54 15 IIII Reverse Thrust 81 Fan Efficiency 70 HPC Inlet Temperature/Profile 39 TCA 46 Buffer Cooler 45 Air Oil Coolers 41 Sarting Bleed 42 Sabily Beed 20 HPC Bodie Surge Margin (Sea Level) 98 Sttr Vne Sctedule 10 Fuel-Oil Cedere 13 Man 01 Temperaure 68 Fed Flew 78 Burner dP 79 HPTExpansion Ratio 80 LPT Expansion Ratio Perforrance Nozzle 89 Primary 65 LPT Flo Parameter 1 Low Rotor Speed 76 LPC PR 4 LPC Stability (Op Lne) 24 LPC Surge Margin (Cruise) 01 2.5 Bleed 35 Nacelle Thermas Fan Exit Area 75 Fn PR 02 Egie Pressure Ratio 14 Take Off Thrust 27 Typical Operating Mission 69 Total Inlet Temperature/Profile Fan/LPC Tip Clearance 61 LPC Flow Capacity 43 Thrust Balance 77 HPC PR 5 HPC Stability (Op Une) Parameter 64 HPT 63 Burner Flow Capacity 62 HPC Flow Capacity 2 HKgh Rotor Speed 31 Vibration HKgh Rotor 91 HPC Clearances 83 HPC Eflficiency 71 Burner Intet Temperature/Profile 72 HPT Inlet Temperature/Profile 48 HPTILPT Clearances 86 LPT Efficiency 74 Exhaust Gas Temperaure/Profile 44 Nacelle Cooling 60 Fan Flow Capacity 40 TCC Bleed 03 Control Laws 52 Manufacturing Cest 36 External Component Thermals 88 Fan Nozzle Performance 17 Nose 25 LCF Mission (Flight Cycle) 57 Engine Change Time 29 Retatng PaFLUfe 08 TMC 26 Burst Margin 18 LPC Takeoff Surge Margin 23 LPC Surge Margin (Max Climb) 19 HPCT/O Surge Margin 3 TSFC 8 Fan Op Line i0 0 04 47 87 0 I5 0 37 33 94 21 82 85 0 I- i -u 81 15 7 7 39 46 5 - - - 7 7 6 6 98 20 10 13 68_78 79 80 1 89 65 76 4 24 01 66 30 7 6 75 02 14 27 69 61 04 43 77 64 5 63 62 2 31 91 83 71 72 999999 9 7 7 6 6 7 7 7 7 7 7 7 7 5 5 5 7 66 6 6 5 5 5 - 42 9 9 T 5 41 45 9 9 9 9999 70 44 S 44444-4 0I 5 44- - t0 00i 0 _0 0 i ol I ni ni i' - T i 1 1 _I i1 11 Io I I A F--" i ' I I I I i-4 ill I I ! 12 -4-1--41- - I I -t-- -1-i-h 1 1 11-4-414-4-I!- Iol I I I -I- i ; i - - i -7 I- - - LJ --- 14-4-4-44-4 1 1 1 1 -1 - 1 - 1+1-4--4-4-4 17 1 4 14 141- 1 S1 400 H {'LK'1'1 I I I vi 4z11o14z1z1z1444z1z$zIzI I I I AUl I I I I I I I I I I I I 1 1ol ol I I I I I I I I I I I nl -F 0 t 001 T 01 I l I Io~1-3-11l -IIo I- l I I I I I I I I I I I 4-4- 11 1 0 0 00 0 0 0 I I I 0 I I I 0 - 0 o 1 - 1 1 1 +-F.-F21 1 i -F--F--F-- ll -- -111- - -- -ffi- -FF--F- 1 -- -F-I I F-F-F 1F-F- 1 0 00 0 0 0 0 0 0 00 0 0 - _ 0 0 0 0 0 00 00 0 0 0 0 0 00 00 0 - - -z-- 0 0 0 01 a a 0 0. 0 00 0 0 0 0 0 0 0 0 0 0 - =o i 0 0 0 0 0 o 0 0 0 0 -- -- 0 0 0 0 0 10 0 001 01 0 0 0 0 - -0- 0 0 -0| 0 0 0 f14 1 0 0 0 a -- 0 0-0-0-00 0 _0 - -0 0 -1-1-0 0 a 0 i i -i 0 - 0 0 0 01 0 00 0a 00 a0 0 0 -i 0 0 0 0 0 1 1DI 00 0 0 0 S a00 1 01 - -i -- 0 0 0 - - -i 0 o 0 6 0 a0 a I 0 0 { o 0 0 11-T 0 __o 0 i i i iI i i i i i i i i i i i i i i i i i i i i i i I I i ii ii ii ii i i i i 00iI i i i 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 -4- _ 0 00 0 0 _0- 0_ 1 11-4i i i I i i HI i 1!Il1 1 1 1 1d i i i1111111 i i i i i+ t : 00 0 If 1 11 1 1 ol j 01 ol ol 1 2I I II I i i i Ii I I i i i i i i i i i i i ii ii i ii i i i-i4olIi-1-1-i i i i i i i i ioi-4-4-4ii i i-- i 4I-i i -4-4-I-i iI -I 414I- -- I i 4-4-4-4 o 1-!-4-4 ol I.--1 ol214-144----- 44I~ ~--1441 -4 I 1 1 1Ialul o2 1 I u l I I I I I I I ol I ! 1 1 i i i itI I I !!! It 1iVI! ! Ti -i i -i i i i -i i i ii ii ii ii ii i i i +-F--+F-F-F-F-i- -! i i i SI tor -f-1-1-4--I-f-1-f-f-4-4-4-4-4-4-4-4-4-4-I-I-4I 1 I I -94 i-I--0--hi- -II-LII-tt-t--LtI-II-lIIIIIII-~ - 0 ol0 0 0 00 0 I 0lI I I I ol 1G II 1 I1 I1 I1 Ii 1I I i niLI1 I1 I1 I 1 f)t::ff 0 I--L I.1 01 - I I_-T 0 0 0 N0 0 0 0 i i i i i4--4-i i i 11-1-4FF444F S0 0 a0 00 S0 HM4 ~ 0 0- IoImru ~~o~ ~~ KHK H 0 ++-f I1 i1 1+--4-- 0 0 00 ol ol o ui1ui1 11'1 1 1'1 1'1 _ E--j 11 0 0I 1111 ~ Kt~J K~0____ K1 ThH ~~~~~ i i Ui ol o 0 __ __ 0 ON 0 0 I l o02f1ol l l~~ 14-1-4f -1 IA - I I I I I I I ul I I -f I0 0 _ 16 Ernisserns 73 _ 1 1- 1-1-1--1 11I1--1-444--11-4-4 F-T--" I -1-4-1-1-1-41 -4-1 -j--j--!- 0 0 34 00 o I I I I I - 12 30 77 7 7 7 38 22 999 9 99 6 0_ 0 I-I, 32 9 51 5 0 i 90 49 - 6 5 1 -10 -i i 07 08 0 0 - 09 84 67 50 6 I to 54 In Flight Shut Downs 55 Unscheduled Engine Removals 56 Shop Visit Rate 96 TimeetoIdle 00 Warranty Cost 05 Fuel /Air Ratio 95 Time to LUght 97 Burner Blowout Margin 59 Delays and Cancellations 53 Airline Operating Cost 51 Ufe Cycle Cost 92 K 0 a Flow ____ 00 10 9 66 04 9 93 - i iii11111 liif!ii0i 06 - -. 11 26 99 MN. Temp) - 26 Flight Envelopes (Alt. 99 Ambient Temperature 11 HPC Design 06 HPT Design 93 High Rotor Inertia 9 Fan Design 10 LPC Design 87 LPT Design 47 HPTILPT Leakages 92 Low Rotor Inertia 67 Je Exit Area 50 Diff/Combustor Design 84 Burner Effciency 09 Mechanical Components Design 08 External/Control Design 07 Nacelle Design 49 Anti-Ice Bleed 90 Duct Lesses 32 Engine Weight 37 Nacelle Drag 94 Control Stability 0;22________ 338BrdLoads 21 HPC Bode Surge Margin (Atitude) 85 HPT Efficiency 82 LPC Efficiency 6 Acceleration Times 22 HPC Acce Surge Margin 38 ECS Bleed 7 Deceleration Time 30 Vbraion Lw Rter 12 Corrected Main O Pressure 34 Fan BSlade Out Loads 73 LPT inlet Temperature/Profile . Items 0 T0 44; - t 0|m 0 0 0 0 4 0 00 0 0 0 0 00__,_0 Figure 13: The DSM with the Design parameters torn by row. 55 48 86 74 44 60 40 03 56 (i.e., all necessary parameter information is assumed to be known and the designs are determined first). In both these (and all subsequent) matrices, a number above 0 in the matrix represents an assumption of the variable lower in the matrix. Higher numbers represent assumptions that are made first. Thus, any tick mark that is a 9 was assumed first in the partitioning, tick marks with an 8 were assumed next, etc. down to tick marks of 0 where there is no assumption. In the above work with the Design parameters, the Control Laws were excluded from the analysis. This was done since it is not entirely clear to the author whether the Control Laws (basically the software that runs the engine) are similar enough to the physical design of hardware to be in the same set of parameters. The fact that the Control Laws parameter is part of one of the system engineering organizations shows that it is understood that this is an important system level function. For the remainder of this work, the Control Laws parameter is the first parameter assumed after the Design parameters. For the remainder of this thesis, the nine Design parameters are assumed in the order discussed above and are assumed simultaneously (i.e., all the necessary tick marks are given a 9). Whether the parameters are torn by column or by row will be dependent upon the phase of product development as is discussed below. The DSMs with these assumptions are given in Figure 14 and 15. Note that in both cases, a core block of 64 parameters remains to be examined. At this point several additional comments should be made on the specific ordering of the variables. In Figure 14, the Diffuser/Combustor Design and the Nacelle Design are not in the 57 order stated above. This is due to PSM32 reordering the variables to earlier points just above were the base designs are torn by column. The author is not aware of the logic for this move, but includes the result for future analysis. In a similar manner, the Fan Op Line, Time to Light and other variables that should be part of the aerothermal block of parameters are removed and put below the main grouping of variables during the very first partitioning prior to any assumptions. The PSM32 program separated these variables due to the interdependencies included with the parameters that are present within the current DSM. While PSM32 acted accordingly, the limited scope of the variables chosen for the DSM is the result of their separation and not their independence. Thus, they should be included as part of the aerothermal design discussed later in this work. Another apparent logical error is the variables such as HPT/LPT Leakages, Deceleration Time and variables that are brought to the top of the matrices once the Designs are assumed. Again this is due to the limited nature of the selection of variables rather than true independence. Since the design variables are large conglomerations of many lower level parameters, once assumed in PSM32, all the lower level parameters would be assumed. In practice this is not the case, but only a subset of these lower level parameters are assumed. Many of the variables brought to the top should actually be included in the aerothermal design. Separation of the designs into lower level parameters to understand the full implications of making the design assumptions is left to future work. 58 Items TSFC Fan Op Lim Emissions In Flight Shut Dovris Unscheduled Engine Removals Shop Visit Rate Tim to Idle Warranty Cost Fuel lAir Ratio Tim to Light Bumr Blowout Margin Delays and Cancellations Airline Operating Cost Life Cycle Cost 7 15 20 21 6 46 13 52 85 86 94 98 10 71 72 41 22 33 34 44 68 81 12 35 83 42 31 30 40 45 48 80 89 665 1 04 60 61 76 62 43 39 63 78 77 4 24 01 35 66 75 02 14 27 69 70 91 5 64 03 37 52 18 2 79 73 74 119 25 23 28 88 17 36 5c) 29 07 58 11 9 06 10 87 09 08 3 8 5 16 54 96 00 55 56 95 97 05 59 53 51 TTTF 91 T:T-T:: ----- 4111 T-4 9 9 -9 --- ? L i -t--t 0 -0- ---- - 0 - - - - --- -j- -9 9 0 -0 0 0 9 - - - -- - - - --- - -4- OF-P 9 9 - 0 a 9 9 - 0 0 9 9 9 - f I I I 9 9 9 _0 1 91 9 1 11 1 0 1 9 0 0 a 0 M I I 1 0 1 91 0 -ON 0 0 0 0 0 0 0 9 9 0 0 0 0 -- 0, ON a-- a 0 0 - - 1 ,0 - O -0 0 0 0 0 0 O 0 01 9, I I 6H+O. 0 0 ON 0 0 - - - - - 0 - a 0 0 1 0 0 0 0 0 0 00 9 0 0 E-- 0 1 0 0 0 N 0 - - - - - - 0 01 0 I 0 0 0 I 0 0 0 ON 0 0 0 ON 4. 0 0 O 0 0 0 0 0 0 0, a 0-0 a a _j 0 -4- a 0 - 0 N 0 9 ON 0 0 ------ --- -0 om 0-- 9 9 s -- - 0 0 -0 9 -.o 100. 0 0 9 0 0 0 ON 0 0 0 0 0 0 ON a 0 0 0 0 01 0 0 0 .1 0 0 0 0 0 0 0 0 1 0 01 9 o 9 9 9 9 9 9 9 9 0 I 0 0 0 D a 0 I . iI -4 i: I iI 1-I i1 i h tijo 0 id I I oU ll Ii II U l i I I II ol0U 1l 1I 1 I I o I 01 1 1 i 3! 0 1 (1 1 1 1 1 1 01 1 i i 01 1 1 1 1 1 l I I I I 1 I r-.00 1, 1 1 1 r-t-i 0 i i i 1 1 1 1 1 0 i I I I I ol ol;U i olUi olIi olU l II U l i 1 0 ! ui I Ui I ol ol ol 1 I oi ol i ol i oli oli ol! UiI I U l Ul Ul Ul I I I I I I i I I .1 1 ; I I I I I o l I I I I I l I i I oi 90001,i I 1 oll II .olU1l II olUl U U l 1 601 261 .1 .1 1 0 It 1 601 601 601 al I ol ol 1 I I I I i i 0 11O il O il O il i I I 101 01n i 01A l .1ol ; 1 1 1 1 1 1 1 1 1 1 1 1 11 no' ! 16,1-1 1 1 01f 01n l n0 I i I1 I n i noll n01i 101 I A l ol ol ol I H I " oli ol'l -I ol I I I I I I I I I I I I i I I I I I I I I I I I ol01 101 oll oll I U l U l 1 1 O il I 1 1 1 1 1 1 I I I I I I I -k-4- I I I I I I I I I I I I I I I I I i I I I Ul I I I 1 1 i 1 1 1 1 1 1 1 i ol ol I I n i I 1 I1 I1 I1 I1 I1 I1 I1 f1 I1 11 11 11 11 11 11 11 11 116,115, 1 11 11 11 11 11 11 11 11o l I 1i I A li A li I I I I I - - 0 - - 9 9 - 91 1 91 I I 01 1 A-! 11 11 1! -1 olj I I 1 1 nl ol 0-- 0 I I olu l olol II1 1 1 1 1I I1 I10-i I1ol l i1 1 1I I1 I1 ! 1 1 1II I1I I1I olI1-4II 0 1 1 1I o-1 Iol ol I I I I ol Uol l ol Ul Ul 0 0 0 0 1 1 i I 0!ol i iI Ii iIOi I A iI iI iIol I Ii ol I I I I I I I I I I i I A l I I I I I I I I I I I Ul I I 1 1 061 ol 1 1 1 1 1 1 01 01 i i I U l i i Y.i I I II oU ll i I i I 9i olol II ol i oI 0 0 0 0 01 I 0 0 0 0 0 0 0 ol oj 0 0, I o 10 0 i I I ol 0 I o ol 0 0 0 0 0 0 0 1 91 91 91 91 9 0 0 0 -0 9 ol 9 9 9 0 0 0 0 0 9 9 91 9 9 91 9 9. 9 9 9 99 9 91 0 o 0 o 0 9 9 9 9, 9 9 ol ol 1I I I I i 0 0 1 1-d 1 1 91 91 91, 9 91 1 9 9 9 o 0 ol 0 0 ol o oi a 91 9t 91 9 91 91 91 9 9 91 9 9 0 II I Hill ii i i 2i ol i Uol l U l 9 0 a 01 I 1 9 0 0 1 1 0 0 0, 0111 0111 1 1 1 1 1 I1 1 1 1 1 1 U l I I 1 0 1101 I I i I I I i i i Oi Oi II oli iI o l I11 ol ol ol I ! -! 1 1 1 -1 -1I -1 1 1 1 1 1 1 ! oi l ! I "! Il ulI 1 01 i i i i i i i i ol i i i i i i oli i iI I ol i i i i i1 o il I u il I I U l ol Ul Ul I U l I I I I I I I ol Ul 1 o I 1 0 0 - 0 0 00 0 I i Itm - 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0--o 0 0 F - - - to 0 0 9 0 0 0, ol ol ol - 00- 0 _0 0 0 00 +0 0 0 0! ol 0 0 I - 3 8 16 54 55 56 96 100 105 95 97 59 53 51 26 99 47 49 57 67 84 90 92 93 32 - 26 Flight Envelopes (Ait. MN. Temp) 99 Ambient Temperature 47 HPT/LPT Leakages 49 Anti-ice Bleed 57 Engine Change Tim 67 Jet Exit Area 84 Burner Efficiency 90 Duct Losses 92 Low Rotor Inertia 93 High Rotor Inertia 32 Engine Weigh( 7 Deceleration Tim 15 Reverse Thrust 20 HPC Bodie Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (AJUtude) 22 HPC Accel Surge Margin 33 Bird Loads 34 Fan Blade Out Loads 44 Nacelle Cooling 68 Fuel Flow y 81 Fan Effici 82 LPC Efficiency 155 HPT Efficiency 86 LPT Efficiency 94 Control Stability 98 Stator Vane Schedule 110 Fuel-Oil Coolers 71 Burner Inlet Tempeiature/Profile 72 HIPT Inlet Temperature/Profile 41 Starting Bleed 6 Acceleration Tim 46 Buffer Cooler 13 Man Oil Temperature 12 Corrected! Main Oil Pressure 38 ECS Bleed 83 HPC Efficiency 42 Stability Bleed 31 Vibration High Rotor 30 Vibration Low Rotor 40 TCC Bleed 45 Air Oil Coolers 48 HPT/LPT Clearances 80 LPT Expansion Ratio 89 Primary Nozzle Perfornance 65 LPT Fiov Pararneter I Low Rotor Speed 104 Fan1LPC Tip Clearaincis Capacity 60 Fan Fl 61 LPC Row Capacity 76 LPC PR 4 LPC Stability (Op Lim) 24 LPC Surge Margin (Cruise) 101 2.5 Bleed 35 Nacelle Thermals 66 Fan Exit Area 75 Fan PR 102 Engine Pressure Raho 14 Take Off Thrust 27 Typical Operating Mission 69 Totai Inlet Temperalure/Profile 70 HPC Inlet Tempwature/Profile 91 HPC Clearances 62 HPC Flow Capacity 43 Thrust Balance 39 TCA 63 Burner Flow Capwty 78 BurnerdP 77 HPC PR 5 HPC Stability (Op Lim) 64 HPT Flow Pwarneter 2 High Rotor Speed 79 HPT Expansion Ratio 73 LPT Inlet Ternpwa(ure/Profile 74 Exhaust Gw Tempera(we/Profile, 103 Coritrol Laws 37 Nacelle Drag 52 Manufacturing Cost 18 LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 23 LPC Surge Margin (Max Climb) 25 LCIF Mission (Flight Cycle) 28 Burst Margin 88 Fan Nozzle Perfor-rice, 17 Noise 36 Extemal Component Thermals 50 Diff/Combustor Design 29 Rotating Part Life 107 Nacelle Design 58 TMC 11 HPC Design 106 HPT Design 9 Fan Design 10 LPC Design B7 LPT Design 109 Mechanical Components Design 108 External/Coritrol Design m 0-M om 0 Figure 14: Base DSM for stages that have the Designs determined late. 59 60 11 06 9 10 87 9 9 50 013 9 5 09 07 47 49 57 67 N 9() 92 93 32 7 15 20 21 22 33 34 U 68 81 82 86 86 98 10 71 72 41 6 45 13 12 W W 42 31 30 40 45 48 80 89 65 1 04 60 9 9 9 9 9 61 76 4 24 01 9 9 35 02 75 14 27 69 70 91 62 43 39 63 5 7a 64 2 79 73 74 03 37 52 9 9 9 9 9 IS 19 23 25 M 85 17 36 29 50 3 8 16 5t O 95 97 13 51 9 _9 ss -0 9 9 -- i 9 o 9 9 91 9 9 9 9 9 9 9 9 9 9 9 9 9 a 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 M __ 9 9 9 9 0 99 9 9 9 9 9 9 11 9 1 911 91 99 - 9 1 9 9 9 9 9 9 19 1 9 0 9 0 - 9 9 9 1 9 9 9 - - - - - 9 9 -- 9 9 9 9 -0 0 0 0 a 0 0 01 m 1- 4 - __L__. Ll.___L _. ILI --- - - 0 10 - 9 9 9 9 9 9 9 9 9 -9 9 9 1 - 9 0 01 0 -T-0 __T_ TO-a D _0 0 0 0 0 0 0 0 0 0 10 -0 0 0 0 0 1 0 1 1 ol 0 1 1 0 - 0 0, 0 _0 0 0 a 0 0 0 0 0 0 ol 0 0[ 0 0 0 ol 0 0 0 0 0 1 0 -- ol 1 ol ---- -- 0 0 0 0 0 0 0 0 M 0 0 0 0 0 0 a ON ON 0 ON 0' 0, ---O_____0 0 0 ol 0 0 O a 0 0 -- - - I 0 1 1 4-- - - 0 0- - I 0 -----IN - Of ON 00 T-T-I i T_ D 0 - - O__ 1 0 0 -- a o o o o ol ol ol ol 0 0 A lpill 1 1 1i i i i i i I I ol 0: 01'114 1011 01'-0 I nl iI oi ol ol ol 1 0 I ni -t- nt I I I - i +-4- 0 0 o o 0 I 1 1 1 :f 1 11 0 1 1 I o 0-- o I ol I-01 I I I I I 1 I I I I I I :: 1 1ol9 00 ol 6 III III "I III i 0 IN 0 0 0 77 0 0 _0 0 0 0 0 1 0N -im I m 1 0 0 I ! I Iol I ! ni n t I I I I I I I I I olV If Ii II II II II II II fI olnU l I I I 0I 0 i i i i i i I I -4- I I1 1 11 1I l l Ii Ii Ii Ii Ii IIi 1 !-1-! 1 1 !'1'! 1 ttt !-1 1 1 1 1 -1 1 !'1 III o o 0 0 06! 0 0 III I iI iI IiI IiI iII iI iI iI iI iI iI i; ii I I I I I i I I I I 0 0 I I I i I I I i I 0-----0 0 0 0 0 01 1 1 1 1 1 1 1 1 I I I I I I I I I i 0 1 01 0 11-2. i .11 1 HIII 11 ii iii -1!I 1Hii-ii 1I 1I 1i -1 1 1 1-1 11 1 11 1 ! ! l I n1 i 1 I 1 I ! I 11111411 1 1 !,,!al 1111,,12.1 ol ol Hil i i i i i i i 'i i i i i 'i .'i ! i i i i i i 0 0 I 0 ol I I 1 0 1 "1 01 i ol 0 i 01 i 1 1 1 1 1-1 i 00 1 ! 1 11 1 11 0 I I L -Tq-F-l I H!'I'llH 4i f-i i i+-i i i i i 4i Hill 00 0 - oF --- 0 0 0 - t60!20i 2.12"1ol I I I i .2i0 o0i o0i il 0 1 1 0 1 0101i J101ol I11Iol.1O F-T-1 F J F-T J ol 1oTJ -T-T - i1 01J OF OTOT 01-9 1 o l I I I I I 1 01 I I : L iI olUli oli olUli Uloli ali Oi ofi Ofi alJ iI iI iI 0 0 0IN 0 001 11 -6 0 ___77 1 01 0 0 0 ill! 1 Al i 0 0 1 1 1 1 I I I I 1 0) 0 IN 0 a ol i i i i i i i ii ii i i i i i i i i i i i i i 1 1 '104- l i -4 i i -i ol oi 1 0 0 LL I nl 0 0 a 0 11 O nj 0 0 4- 0 I Al nl 0 0 0 0 a Ia 0 0 Ol I nl 0 .4 .1 0 1 ON 0 0 O___ - a 0 00 " 0- 0 0 0 0 0 0 0 I I I 0 0 0 ol 0 0 0 a - - 00 JIRO I - 0 ! TSFC Fan Op Line Ernissions In Flight Shut Downs Unscheduled Engine Removals Shop Visit Rate Time to Idle Warranty Cost Fuel /Air Ratio Time to Light Burner Blowout Margin Delays and Cancellations Aldine Operating Cost Life Cycle Cost M - 3 8 16 54 55 56 96 100 105 95 97 59 53 51 26 -0 ! 26 Right Envelopes (Ajt MN. Tamp) 99 Ambient Ternperature 11 HPC Design 106 HPT Design 9 Fan Design 10 LPC Design 87 LPT Design 50 Diff/Combustor Design 106 Extemal/Control Design 109 Mechanical Components Design 107 Nacelle Design 47 HPTAPT Leakages 49 Anti-los Bleed 57 Engine Change Time 67 Jet Exit Area 64 Burner Efliciancy 90 Duct Losses 92 Low Rotor inertia 93 High Rotor Inertia 32 Engine Weight 7 Deceleration Time 15 Reverse Thrust 20 HPC Bodie Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (AJUtude) 22 HPC Accal Surge Margin 33 Bird Loads 34 Fan Blade Out Loads 44 Nacelle Cooling 68 Fuel Flow 81 Fan Efficiewy a2 LPC; EMciency 85 HIPT Efficiency 86 LPT Efficiency 94 Control Stability 98 Stator Vane Schedule 110 Fuel-Oil Coolers 71 Burner Irge(Ternperature/Profile 72 HPT Inlet Tarriperature/Profile 41 Starting Bleed 6 Acceleration Time 46 Buffer Cooler 13 Main 01 Temperature 12 Corrected Main Oil Pressure 38 EGS Bleed 83 HPC EMciency 42 Stability Bleed 31 Vibration High Rotor 30 Vibration Low Rotor 40 TCC Bleed 45 Air Oil Coolers 48 HPT/LPT Cleai-ances, 80 LPT Expansion Ratio 89 Primary Nozzle Perfornarice 65 LPT Flow Parameteir I Low Rotor Speed 104 FarV1_PC Tip Chwance 60 Fan Flow Capacity 61 LPC Flow Capacity 76 LPC PIR 4 LPC Stability (Op Lim) 24 LPC Surge Margin (Cruise) 101 2.5 Bleed 35 Nacelle Thermals 66 Fan Exit Area 75 Fan PR 102 Engine Pressure Ratio 14 Take Off Thrust 27 Typical OWating Mission 69 Total Intel Ternperature/Proffle 70 HPC Inlet Temperature/Profile 91 HPC Clearances 62 HPC Flow Capacity 43 Thrust Balance 39 TCA 63 Burner Flow Capacity 78 Burner clP 77 HPC PR 5 HIPC Stability (Op Lim) 64 HPT Flow Parameter 2 High Rotor Speed 79 HPT Expansion Ratio 73 LPT Intel Terriperatuni/Profile 74 Exhaust Gas TetriperaturelProfile 103 Contral Laws 37 Nacelle Drag 52 Manufacturing Cost 18 LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 23 LPC Surge Margin (Max Climb) 25 LCF Mission (Flight Cycle) 28 Burst Margin 88 Fan Nozzle Performance 17 Noise 36 External Component Thermals 29 Rotating Part Life 58 TMC . Items 0 0 0 0 0 ON 0 0 -O-M 0 0 Figure 15: Base DSM for stages that have the Designs determined early. 61 62 CHAPTER 4: VARIATION OF ASSUMPTIONS BY STAGE OF PRODUCT DEVELOPMENT The product development process involves developing and incrementally improving a design concept until it has evolved into a full product. The process by which the product is developed is a series of steps where the product is developed and validated in an ever increasing level of complexity. In general, as the product moves through the development process fewer assumptions are made and more has been validated. The process by which assumptions are made and how they are validated is the topic of this chapter. The analysis is broken down into four stages of product development (conceptual design, preliminary design, detailed design, and validation). Note that here and throughout the remainder of the thesis preliminary design and system-level design are meant to be synonymous. Production and field service are not included in the present analysis since all assumptions are (supposedly) validated prior to production and release to the field. The analysis in this and subsequent chapters is confined to products that are past the stage where the architecture is undergoing radical innovation. In general, this work is believed to be valid for products that have a dominant design. By limiting the scope of the analysis, a single architectural DSM should be valid. For the incremental changes in architecture, the DSM may be updated. However for products that are undergoing radical architectural changes, little reuse is possible and a standard product development cycle is unlikely to be present. In this framework, all analysis in the current chapter based upon either Figure 14 or Figure 15, both of which are derived from Figure 9. In other words, all analyses completed in 63 this work are based upon a single parameter-based DSM. The analyses differ only in the assumptions made (i.e., how the parameters were torn). Assumptions for Conceptual Design The first question asked when developing a commercial engine is what is the required thrust. The thrust necessary sets the class of engine that the aircraft will require. With a simple analysis, the desired thrust of the engine dictates the optimal overall pressure ratio. Many thrust/pressure ratio combinations have been explored in the past and, for commercial engines where the primary need of the airlines is thrust with low fuel consumption, knowing the thrust and the application desired leads to a small set of engine designs (e.g., 90,000 lb. thrust for a commercial passenger aircraft). Gas turbine manufactures emphasize the reuse of designs and typically develop concepts for engines around successful designs of the past. Once the class of engine is known the next questions that are asked are what has been done in the past on which to base this design and what technologies/design concepts are going to be inserted into the concept. The representation of this question in a DSM would be to assume design parameters that are the best the company has developed to date (not necessarily put into service). In a DSM, the thrust followed by the base design parameters would be torn by row (Figure 16). Modifications to the design parameters would then be accomplished based upon the new design concepts or technology. The concept designer then develops the aerothermal cycle based upon the constraints imposed by the designs. Note that most of the following discussion is based upon lectures at MIT and several texts [Epstein, 2000; Kerrebrock, 1992]. 64 Items 06 9 11 10 B7 50 W B8 a a 8 21 22 8 a 68 89 94 10 41 46 13 12 42 80 64 63 61 74 45 7 44 62 M43 2 79 73 48 M5 86 U4 81 38 77 78 72 a2 70 91 83 3W31 65 71 43 1 76 3W 4 01 24 35 W66 40 75 02 W -8 aa 8B8 8 -88 a 0 8 a8 a 8 6 5 3 88 20 98 23 1B 19 17 29 28 36 58 3 0 16 54 55 M 00 05 95 N9 97 59 53 51 9 a 8888 8 8 B88 8 8 8 8 8 5 a8a -__ _ _8 8888888 8888.8 811 8-a8 a8 8 a 8 0 8 88a88 8 8 88 88 8 8 8 8 0 a 0 0 0 0 0 0 0 0 0 0 0 oo a0 - -o o 0 - - 2 1 o 0 : - - - - - -0O 0 - - -- - 0 a o 0 S0 S0 0 0 om 0 ol o l 0 0 0 0 0 0 0 -0 0 0 0 a0 _ -- 0 S0 a0 0 0 0 0 0 0 00 a 0 0 0 0 0 0 0 _- 00 -0 0 0 0 0 - a 0 00 0 S0 0-6 0 O alo I--f-- 0 - - 0 1100 o0 -- 0 -0 0 0 $ 0 0 0 0 00 a_ 0 0 0 0 C0 - o 0 0 - 0 0 a o 0 00o0 1 a 0 0 - 00 S0 low 0 000 0---o0 a0 S0 00 S0 0 1-I 0 0 1 5 0--1----0 5- 0 1 010101ol ol IolIol I II I I I I I I I I I IolI01 i ' 111 no -. ti i - i -i i Ii ii ii i I I I I I I I 1 1 1 1 1 0 0 00 0 0 0 0 0 0 0 0 -0 000 I I- 0 1i - iti - -Ii i 0l 0 I I -t 1 0 0 1o 0 4 i 0i I I Iol Iol I I - 0 0 0 -000 00 i 00 0 0 0 0 0 i 0 0 __0 -1 - I 0 0 1 1 1 1 1 1 1 1 1 o l I I n Ii II II o lI II II n Il Ii I1 I I 1 0 I 01 I0 oI 1011 1 i n' 01i i., i i i i 101 0i ,-" oi 0 0 0 !i0 101n' 101I 01I o 0 0 00 00 -U i i I i Iit IIddI 0 0 0 0 0 io i i0i -A0 ii 1 0 0 S 0 0 001 0 0 0 I I TON -0 0 a %0 0 0 - ol I 0 - II t I 0 00 1 0 001 0 1 0- 0 0 0 zIzI {ozI o o 0 -T - - - -7 0 001 00F o 0 0 0 0 500 I0 -f-S _ 00 i1 i 4 I 0 - i + _ 0 0 - i - 0 - i a! 3 TSPC an Op bee 8 0 00 0 0 00 1 -0 0 a 000 a0 - 0 -- 1 - - 0 04++ 0 0 0 S0 - -- - 0 0 0 II I 1 o 0 0 00 - 0 l0 0 - 0 0 91 HPC Clearances 83 HPCEfficincy 71 Bone Int Tetnperature/Profile 43 Thrust Balance 39 TCA 65 LPT FRnw Parameter 1 Low Rotor Speed 76 LPC PR 4 LPC Stability (Op Line) 24 LPC Surge Margin (Cruise) 101 25 BlOeed 35 Nacelle Thermals 66 Fan Eit Aea Capacity 60 Fan 40 TCC Bleed 75 Fan PR 102 Engine Pressure Ratio 103 Control Laws 6 Acceleration Timee 5 HPC Stability (Op bee) 20 HPC Bodie Surge Margin (Sea Leve) 98 Stator Vane Schedule 23 LPC Surge Margin (Max Climb) 88 Fan Nozzle Performance 17 Noise 18 LPC Takeoff Surge Margin 19 HPCT/O Sog. Marins 29 Rotang Part Life 28 Burst Margin 36 Etenal Component Thermals 58 TMC - al0 0 0 o[a0 0 w4- 30 Viketion Lao Rotor 31 Vibration High Rotor i i1 69 8 Out - i i- i 2.- i -n - *i- -i -*-i 'i i 49 47 32 90 67 52 27 37 25 a 88 888 a 8 88 aa 8 80 16 Enessions 54 In Flight Shut Downs 55 Unscheduled Engine Removals 56 Shop Visit Rate 96 Time to Idle 100 Warranty Cost 105 Fue /Air Ratio 95 Time toaUght 97 Burnear Blowout Margin 59 Delays and Cancellations 53 Airfine Operating Cost 51 Life Cycle Cost 92 67 M4 93 9 B Oil - t -t-ti 07 a - 8a - a8 a 88a8 8a-a 8a8a.8aaa888B8 a8---8-_- 26 99 14 15 26 Flight Envelopes (Alt, MN. Temp) 99 Ambient Temperature 14 Take Off Thrust 15 Reverse Thrust II HPC Design 106 HPT Design 9 Fan Design 10 LPC Design 87 LPT Design 50 Diff/Combustor Design 109 Mechanical Components Design 108 Extenal/Control Design 107 Nacelte Design 67 Jet Exit Area 84 Buter Efficiency 93 High Rotor Inertia 92 Low RoI nertia 49 Anti-Iae Bleed 47 HPT/LPT Leakages 32 Engine Weight 90 Duct Losses 57 Engine Change Time 52 Manufacturing Cost 27 Typical Operating Mission 37 Nacelle Drag 25 LCF Mission (Right Cycle) 69 Total Inlet Temperature/Profile 21 HPC Bohe Surge Margin (Altitude) 22 HPC Accel Surge Margin 68 Fuel Plow 89 Primary Nozzle Perfonance 94 Control Stability 110 Fuet-Oil Coolers 41 Starting Bleed 46 Buffer Cooler 13 Main Oil Temperature Pressure 12 Corrected Main 42 Stability Bleed LPT Expansion Ratio 74 Exhaust Gas Temperature/Profile 64 HPT Flow Paramteir 63 Buner Flow Capacity 61 LPCPow Capaciy 45 Air Oil Coolers 44 Nacelle Cooling 7 Deceleration Time Loads 34 Fan Blade 33 Bird Loads 62 HPC Flows Capacity 2 High Rotor Speed 79 HPT Expansion Ratio 73 LPT Inlet Temperature/Profile 48 HPT/LPT Cleerances 85 HPT Efficiency a6 LPTEfficiency 104 Fan/LPC Tip Clearance 81 Fan Efficiency 38 ECS Bleed 77 HPC PR 78 BunetdP 72 HPT Inlet Tennperature/Proffle 82 LPC Effidency 70 HPC Inlet Temperature/Profle _ _ _ 1 ___ Oi1 i[ OiOTI Joofl Oio0II OioFII i1 i1 i1 i1 OT I 4-4- I I I I I I II 10 0 017 0 100 0-0_0 _ 0 0 Figure 16: DSM with thrust and design parameters assumed. 65 66 For the last 50 years, one of the limiting technology aspects of a gas turbine is its turbine inlet temperature. For modern engines, the turbine inlet temperature is well above the melting point of the materials that make up the turbine. Coatings and cooling technology are used to keep the alloys from melting and maintaining the component integrity throughout its life. The compressor exit temperature is also limited by the materials at the rear of the compressor although design trades are such that no coatings or cooling are currently used in the compressor (and therefore the allowable temperatures are significantly below the melting point of the materials). In the DSM, the first two parameters assumed during the aerothermal design of an engine (the large block of Figure 16) are the HPT Inlet Temperature and the compressor exit temperature (termed the Burner Inlet Temperature in the current work). Note that not only are the overall temperatures important, but also their profiles. Making these assumptions leads to narrowing of the large interdependent block of the DSM (Figure 17). After these two technology limited parameters are determined, the aerothermal design can be determined. The flow capacity of the fan and the core modules (and thus, the bypass ratio) are the first parameters to be determined during the aerothermal design. Interdependent with the determination of flow capacities are the pressure ratios across the modules. This combination then sets the operating lines and therefore the surge margins. Transient behavior and secondary flow requirements are also interlinked with the flow capacity and pressure ratio determination. Figure 18 and Figure 19 represent two possible set of assumptions with the difference being when and how the assumptions are made about the secondary flow parameters (bleeds and leakages). In practice, aerothermal design undergoes many iterations in computer simulation. Due to the number of iterations, the particular order the assumptions is not extremely important. 67 During conceptual design at P&W, many possible technology and cycle combinations are explored with the deliverable of two or three of the options completed in detail. These options are then considered in a upper level management review with a single concept being selected to proceed to preliminary design. The DSMs in Figure 18 and 19 would be typical of the conceptual design process. For P&W, the conceptual DSM can be represented by: 1) obtaining the supersystem requirements from the airframer as well as program goals 2) obtaining the details of historical designs and developing new design concepts 3) assuming technology improvements and evaluating risks 4) completing many iterations on the aerothermal design, and for select options 5) validating integrative parameters to ensure the airframer requirements and program goals are met. Here the author has taken the liberty of changing the pure parameter DSM to a task-based DSM where each task is the determination of a single parameter from the parameter DSM. Following conceptual design, the full engine has been designed. It is a virtual, paper engine, but the complete engine with all modules is running within the computer simulation. The design is based upon many rough assumptions that are based upon historical capability and scaling as well as new design concepts and technology. These five steps can be generalized and represented in a schematic DSM (Figure 20). One note of caution on this and the remaining schematic DSMs in this thesis. The schematic 68 26 99 14 11 15 06 9 10 87 50 08 09 07 47 4957 67 84 32 27 37 52 69 2503 90 9293 7 68 94 6 71 72 22 33 81 82 86 38 20 70 45 85 73 21 74 26 Fight Envelops (Alt MN, Temp) 99 OAmbient Temperature 14 Take Off Ths 15 Rverse Thust 11HPC Design 106 HPT Design 9 Fan Design 10 LPC Dsign 87 LPT Design 8 8 8 8 8 8 _ 8 888 8 8 4 76 75 39 65 48 80 79 181 8 8_ 111 _ 1 1 1 1 8 8 ___8 8 8 8 8 8 8 8 88 88 888 88 9 _ 8 8 8 ! 888 8 78 5 77 64 31 2 _ a 8 a 5 8 30 34 91 62 02 83 10 13 12 18 19 ---- 118 H-Ili 8 88 8 8 8 - 8 _ ___8 8 8 i .48[ B 88 8 8 8___88 a' 8 8 _ 8 8 a a a 881a 8 8 8 8 B 8 8 - - - - - -8-8 88-8-8 8 8 88s8 888 - 888 a 88 a a 888 8 8 0 0 1 I 0 Inet TmperatureProfile a--.- 1 10 o 73 74 21 98 LPTInlet Temperature/Profile Exhaust Gas Temperature/Profile HPC Bodie Surge Margin (Alitude) Staor Vane Schedule 40 89 43 24 7CC Bled Primry Nozzle Ps/o..., Thustlanceto LPC Srg Margn (Cuse). t K0K0 o 0 ---- 0 _0 0 --_-_- - - - -- 0 0 I 0 C7 0 7 l 7 7 7 0 0 7 7 7 7 7 7 7 7 7 7 7 6 -0 0 6 0 00 a 0 01 0 0 -- - - 0 101 2.5 Bleed 61 LPC FlowsCopady 63 BnssP Floss Capacy 00 0 I F0 Level) 0 7 7 0 0 (Sea 7 66 0 a- 7 o -0 Io 0 o 0 00_ -- -- - Surge Inet 85HPTEffiiency 0 a I 001 I 01 00 0 01 01 0 -- - -F 0 Sltatng Bled 0 0 0 0 -0 6 F. Flow Capacty 44 NaTllT Coolin a 0 1 0 _0 0 ULi) 0 G, 0 64 I/PT FRows Piramel. 2 High Rotsr Speed 31 Vbtono High Rotsr 30 Vbain Loss Rots, 34 Fn Bade 0ut Lods 91 I/PC Cisoaos 62 I/PC Floss Capaiy 83 I/PC Eficiency. 102 Engine Pressure o 0 f I 0 I i I i 0 I 0 0 ~~0 58 TMC 3 TSFC 8 Fan Op Une 0,010 00 0 r 0I 0100 0 0 0,0 0m 0 -0 0 00I00 0 0 0 0 000 0 0 0 L_ 01 00 [0 1 8 0 00 o ol ol ol 0= I - 0 0 O a 0 0 00 0 t[1 I z~z~'IzzL I ~1~ 000 0 10 IL 0L 0 10 i o iUi Ui IIi ! i- - i i i Ui i iII olIliI UiI ! i i i i i i i i i i i i i. i l Y+00 0 0 G I0 t o 000 000 0o 0 0 0 l ;0 0 0 0 i ii i o 0 1 0 0 0A0000 0 0 0 110 Fuel-Oil 0 01 ala 1 1 0 0 0 0 0 0 0 0 00 10 Ratio 000 0 0 Coolers 13 MainC 1 Temperature 12 Corrected Mao n0 Pressure 18 LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 23 LPC Surge Margin (Max Climb) 28 Bkrst Margin 88 Fan Nozzle Performance 17 Noise 36 Extenal Component Thermals 29 Rotating Part U.fe 0 _-A 48 HT/LPTClearance.s 77 HPC PR 5 HPC Saility (OpLine) 0 0- o 0 0 0 00 o oa M -0 -00000 39 TCA 80 LFT Expansion Ratio 79 I/PT Epaso Rtbo 78 Os...dF IM 0 a00 30 NoeeTesrsiiss 6F.. Exit Aea 1 Los RotsSpsod 104 Fas/LPC Tip Cearance 7 sFPR 77 HPC PR 4 LPC Stabily (Op 65 PT RosswPtosrmetd 00-6 - 1 - ) SLPlity Blee 46 Bffot Coler 000I0 0 1 04 66 d aa Burner Inet 00 35 00 25 Mission (Right Cycle) 103 Control Laws 7 Deceleration Time 68 Fuel Flow 94 Control Stability 6 Acceleration Time Temperature/Profile 71 72 HPT Inlet Tmperature/Profile 22 HPC Accel Surge Margin 33 Bird Loads 81 Fan Efficiency 82 LPC Efficiency 86 LPT Efficiency 38 ECSBleed Margin 20 HPC Bodie 70 HPC Trmperature/Profile 45 Air Oil Coolers F 000 __ _00I 44 60 8 8 32 Engine Weight 27 Typical Operating Mission 37 Nacelle Drag 52 Manufacturing Cost 42 46 - 8 8 ___ a 8 Design 42 8 8 _ 90 Duct Losses 92 Low RotorI nertia 93 High RotorI nertia 41 1 8181 1 81 8 88888 _0_ Burner Efficiency LCF 1 63 41 8 HPTLPT Leakages Anti-ce Blod Engine Change Time Jet Exit Area 69 Total 888 61 -1-1--I-I 8 Extemal/Control Design Mechanical Components Design Nacelle 1 8 S 50 Diff/Combustor Design 108 109 107 47 49 57 67 84 888 8 8 01 43 24 98 40 89 -4- 0 - _ Items - 0 l00 16 Emssoos 54 I Flight Shut Downs 55 Unscheduled Engine Removals 0 0000 o 0 56 Shosp Visit Rts 96 Tos Idle 100 Warranty Cost to S o-0, 0 -0 I I 0o0 0 0 0 0 0 ol 957 0r 1 010 01-o - 105 Fol/Air Ratio 10 95 Tie, to Uight 97 Bumer Bloot Margin 59 Delays and Cancellations 53 Airline Operating Cost 51 Uf Cycle Cost 0 S 0 0 0 0 0 0 0 1 ol o f~d 00 -- 0 0 0 0 0 0 0 F F F- o ol I1 o t -it IliI t o '! -t-i - i i1 t I I 1 01 i Ii I I A 101 F F- - F I I - -F-F-FF- - F FF- F- t FFF F-FFFFF- - F- I-t t- t- n 101 ~K3HI {KK ILILL L I F1 -01I1F I F- 101 I - I -F -F-F-F 101 Al'11 I I i l~ ill 11W IAl H I I I LI I I ~zIzIzIzIzI 0 a 0 -0 0 00 ME E 0 0 0 0 _1 0 0 0 Figure 17: Partitioned DSM with assumptions for new temperature capabilities. 69 23 28 88 17 36 29 70 AA Items 26 W 14 45 11 OS 9 10 07 a a 9 08 07 a I a 8 a aa a 8 a 47 57 67 U W 92 93 32 5 8 27 37 8 8 52 M 81 a 25 1 a_ 03 81 7 M 1 71 6 1 1 1 72 81 62 1 77 B W al 41 3f 4 al 21 8 al n 8[ SO 8 - 75 - a al 8 44 15 I I 1 6i a M I I 86 64 I 2 l .1 7. 1 2. 69 79 7S 7. 7 1 43 _B 46 M 8 8 81 82 31 W a 14 a 70 91 02 8 -8 11 13 12 IS 19 n M 17 36 58 3 a 16 51 M % W 05 95 97 59 51 B_ a I 8i -i N -- a -- a -a -a- i- a 5 -6 a 6 a -8 8 a _0 a -8 8 a __a a T 0 0 _0 0 0 a B a a 0 a a o o a a 0 0 0D D 0 a 0 o o -0 -f,.oo o ol a a 0 1 0 71 M 0 I 0 0 0- 1 f 6m 5 51 1 5 77 _H4 0 0 0 0 0 0 0 0 1 a -_ Q - - _ 0 5 5 5 - - - - - - - - - - 0 __20 a ___Om 0 0 OT; 4, 7.0 0 0 0 a 0 0 4 4 4 4 4 4 4 4 41 4, 4 1 41 0 _340 i m 01 a 0 0 0 0 ------ 0 0 0 0 0 0 01 -1 0 0 0- 01 1 01 1 0 4_0 1 8 0 0 0 0 1 0 _0 om-_ t 0 0 0 ol 0 0 0 0 0 0 _ 0ON--- ___ 0 0 1 I I ! -1 _I -4- I I I i i -1 -1 olol oi01 01oi 01oi o ==..Ol om I i 0 I I 1 i I1 I1 I I I1 I1 I I o lI I I t I I I I I i I I oln i I I I I I I I I I I I I 1 1-4 ii idi ii ii i i i -! -i i i i i -i i i i i i --N. i -i i i i I 1 1 1 1 1 1 1 1 1 it 01I1I1II1 11 I I I I nl 1 I ni nl I :k -ii i i i i i i i i Oi Ji Ji ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii Oii i i 'ii Oii i i i i i orJ oJf JOF O-TJ -OTJ aF-oT 7or ol ol of al OF 7OT ol ol J oli 1 1 1 1 1 1 ! 1 1 1 +-4 1 1 1 1 olI ol I olI a!I alf 1 ol ol olI 1 1 1 1 1 I1 of H !V! 11 1 I I I I I1 I1 1 1 1 1 1 1 1 1 1 ol ! 1 1 1 1 1 1 1 1 1 I I 11 1 1 1 I i ii i i i ol i i i i i i i i Ii Ii i 01i i i i i i i i i;lli 1I 1i 1 1 1 1 1 ol ol ol ol i0ol! ol l oll 1 1 1 1 1 1 I I ol i u i 0 i u i i Ili Ui Oi ol I ol oli Ui U I I ol ol u1I iI IliI IliI iI iI iI iI iI iI i1 i1 i1 i1 i1 Ui1 i1 i1 iI1 iI1 iI1 IliI1 IliI1 Ili I1 Jolul i ol T-- F I H H H-1 ii i I ni n n l n n, ol ol I I r--o I 1 ol ol 0 1I 01 0! aj !'1 1IJol 1"1 1 4 i ii i i i i i i i i i i i TiTit-44iI2 1 i 1-+- 1 1 1I;-iolGi 1 1 1 1 11i 11I 1I1 1I1i 1I1i TI-T---] pIol i i i i i ,1 i1 i1 1 T iIi ifii !i ii ii ii i ui i i i i i i i i i -I i I i i I I I I ----------- 00 01 ITIT n' iI ii I i i i i ol'n i-OT 1 ni1 I! I1!.!! I ,Ii Ii Ii -iI 0! , 4 I i i i ol i ol ol ! i i i i i 'iol ol'i '! 4i ! '! 'i 'i I i I t 44.4 1I ol 1 ol1 11 11 114 i i i 0! i i i F-1 iiiiiiiiiiiii J i i I i i i 01 ol 01J i i ! i i - I 1 6 1 1 1 1 1 1 1 1 l o' ! 1 11 1 01n l 0 0 01 1 m D 1 1 '1 1 0 0 0 Ol ul 1 0 r-T-4:4 i i i ii 11 1 1 i i i i i i i i I I ii ii 1 1i i I -L- -L -L., TI o 1ol 0, 0 i i i i i i i i i i 4- 9,1 9.1 qffffi-p,- I 4-4- 4 1 1 1 1 1 1 601 I 1 01 ol 01 ol I I I I I EE of !! OT21 1 1 1 1 1 1 1 1 1 1 1 1 1ol ! ol ! al ! ol I 1 1 1 1 1 1OF OF ! 1 01 0 0 10 I 1 - 0 I 0 __6 a 0 1 000-of 2 0 0 0 _4 0 0 0 1 0 0 0 al 1 0 0 -0 o 0 0 0 0 ol 76- 00 - 0 " 26 Flight Envelopes (AR, MN. Temp) 99 Ambiwt Temperature 14 Take Off Thimst 15 Reverse Thrust I I HPC Design 106 HPT Design 9 Fan Design 10 LPC Design 87 UPT Design 50 Diff/Combustor Design 108 Exlemal/Control Design 109 Mechanical Components Design 107 Nacelle Design 47 HPTILPT Leakages 49 Anfi-Ice Bleed 57 Engine Change Time 67 M Exit Area 84 Burner Efficiency 90 DuctLosses 92 Low Rolm Inertia 93 High Rotor Inertia 32 Engine Weight 27 Typical Operating Mission 37 Nacelle Drag 52 Manufacturing Cost 69 Total Intel Temparature/Profile, 25 LCF Mission (Flight Cycle) 103 C;oiritrol Laws 7 Deceleration rime 68 Fuel Raw 94 Control Stability 6 Acceleration Time 71 B Inlet Temperature(Proffie 72 HPT Inlet Temperaturre/Profile 62 HPC Flow Capacity T7 HPC PR 38 ECS Bleed 41 Starting Bleed 42 Stability Bleed 5 HPC Stability (Op Una) 20 HPC Bodie Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (Attitude) 22 HPC Accel Surge Margin 60 Fan Flow Capacity 75 Fan PR 44 Nacelle Cooling 45 Air Oil Coolers 40 TCC Bleed 85 HPT Efficiemy 86 LPT Efficiency 64 HPT Flow Parameter 2 High Rotor Speed 63 Burner Flow Capacity 104 Farv1.PC Tip Clearance 101 2.5 Bleed 61 LPC: Rm Capacity 76 LPC PR 4 UPC Stability (Op Lim) 24 UPC Surge Margin (Cruise) 65 LPT Flow Parametw 80 UPT Expansion Ratio 89 Pnmary Nozzle Perfornance 79 HPT Expansion Ratio 78 Burner dP 73 LPT Inlet Temperatuire/Profile 74 Exhaust Gas Temparature/Profile 35 Nacelle Thermals 66 Fan Exit Area I Low Rotor Speed 43 Thrust Balance 39 TCA 48 HPT/LPT Clearanciis 46 "or Cooler 98 Stator Vane Schedule 33 Bird Loads at Fan Efficiency 82 UPC Efficiency 31 Vibration High Rotor 30 Vibration Low Rotor 34 Fan Blade Out Loads 70 HPC Inlet Temperaftire/Profile 91 HPC, Clearances 83 HPC Efficiency 102 Engine Pressure Ratio 110 Fuel-Oil Coolers 13 Main Oil Temperature 12 Comicted Main Oil Pressure 18 UPC Takeoff Surge Margin 19 HPCT10 Surge Margin 23 UPC Surge Margin (Max Climb) 28 Burst Margin 88 Fan Nozzle Performance 17 Noise 36 Extemal Component Thermals 29 Rotating Part Life 55 TMC 3 TSFC 8 Fan Op Lim 16 Emissions 54 In Right Shut Downs 55 Unscheduled Engine Removals 56 Shop Visit Rate 96 Tim to Idle 100 Warranty Cost 105 Fuel Ar Ratio 95 Tim to Light 97 Burner Blowout Margin 59 Delays and Cancellations 53 Airline Operating Cost 51 Life Cycle Cost 1 ol ol ol 0_=F 0 Figure 18: DSM with one set of assumption during the aerothermal design. 71 72 - I -8---a88a88a8a 0ii 09 07 47 49 I--FT-F T--FTTII111111111!III i15 I11 i06 l 9 I10 I87 I50 08 II 67 84 57 93 90 92 32 27 37 52 69 25 03 7 68 94 6 71 86c 85 82 81 72 MM -+ 06 Fani 10 87 50 08 09 07 8 I 8 11 i 8 8a1 8888 8q a8 38 42 66 61 60 1 75 76 5 4 77 22 21 64 98 20 2 63 65 - 80 - -- - -- 78 79 89 73 - 74 35 46 44 40 33 31 -- , D, " -- 30 04 i '0 ' Ii 2 70 24 39 45 43 48 34 o1 . , I 91 62 83 02 10 13 12 18 19 23 28 W8 17 36 29 58 I 88 8 11= 8 - 41 T- , 8 8. a + 1 a 8 81 al I 8 '1 a 88 8 1 81 al8 I I 1 1 el L [ I 8 81 1 1 81 4-. 1 81 8 16 IaiI 181 | - I I 00 05 95 54 55 56 96 -t| i i i 88 8 8 1 8a 81 8 3 97 59 S3 51 | --8 -8 -8a8 aa -8-8a a -8 Beed 67 84 T0 Inertia 52 03 68 6 86 _0 0 0- IF- Inlet 00 0 0 ol 0 ol Burner Inlet Inlet 5 0 0 _0 S0 a 0 0 0 5 0 0 0 0 38 ECS Bleed Bleed 42 Fan Exit Area 1 La. Rotor Speed LPC Flow Capacity Fan Flow Capaity 75 Fan PR 76 LPCPR 77 HPC PR 4 LPC (Op Line) HPC Stability (Op Lim) 22 HPC Accl Surge Margin 21 HPC Bodie Surge Margin (Atitude) 20 HPC Bodie Surge Margin (Sea Level) 64 HPT Flow Parameter 98 Stator Vane Schedule 2 High Rotor Flow Capacity LPT Flow Paramet-r 78 Burner dIP 79 HPT Expansioni Ratio LPT Expansion Ratio Temperature/Profile 73 LPT Primary Nozzle Perfomnance 74 Exhaust Gas Temperature/Profile 35 Nacelle Thermals 46 Buffer Cooler 44 Nacelle Cooling 40 TCC 33 Bird Loads 31 Vbratiort High Rotor 30 Vibrationi Low Rotor Fan/LPC Tip Clearance 70 HPC Temrperature/Profile 24 LPC Surge Margin (Cruise) 39 TCA 45 Air Coolers 43 Thrust Balance 4a HPT/LPT Clearances 34 Fan Blade Loadls 25 Bleed 91 HPC Clearances HPC Flow HPC Efficiency Engine Pressure Ratio 10 Fuel-Oil Coolers Main Temnperature 12 Corrected Main Pressure 18 LPC Takeoff Surge Margin 66 0 _0 _ o Inertia 7 0 0 Stability 00 01 a-- 0 - - 0 0 0 0 0-01 o 0 0 a 01-0 '0 0 0 0 0 0 03 0 - 0 -0 0 0 0 0 00 0 Oil 0: 0 2 PC Suge Margn (Max<Climb) 28 Burst Margin 88 Fan Nozzle Performance 17 Noise 36 Extemnal Component Thermals 29 Rotating Part Life 58 TMC 3 TSFC Fmn ULim 16 Emissions Fight Shut D-wns 55 Unscheduled Engine Removals 56 Shop Visit Rate 96 Time to Warranty Cost Fue/Air Ratio a00 0 51 1 0 0 05 1 0 a o 0 05 0 0 0 0 0500 0 00 a 0 0 0 0 0 0 0 0 0 00 0 0 O .1 0 0 0104 11'-41111111 -1'o 1'1 11'1 11--1---1 1111 1l1llo4JII11o111411iI1'1 I I I 0 0 0 5 o 00 0 off0 0 0 0 0 o 0 0 0 0 Capacity 0 00 00 0 0 -00 - - - - 00 - 6 0 0 Out 55 0. 0 0 0a 55 3030 0 0 00a 0 0 Oil 8 o o 0 0 5 Inlet Oil 55 5 0 0 0 0 a5 0 0 00 0 ~000 0 03 S0 Speed 4 00 S0 Inlet 01 62 83 02 13 - 6 -a-m 0 0 Bleed o L 0 15o 14 a 0 005 5 75 77 75 7775 0 65 04 757 0 0 ol Stablity 80 89 0 7 0 0 60 63 Burner 7 50 0 0 61 5 7 DC0 - 8 8 8'Sa' , I Off p I , , 14 88888a8a88888-8 a8 0 26 99 14 26 Flight Envelopes (Alt, MN. Temnp) 99 Ambient Temperature Take Thrust 15 Reverse Thrust I1I HPC Design HPT Design 9 Design LPC Design LPT Design Diff/Combustor Design Extemnal/Control Design Mechanical Componenits Design Nacelle Design 47 HPT/LPT Leakages 49 Anti-Ice 57 Engine Change Time Jet Exit Area Burner Efficiency 90 Duct Losses 92 Low Rotor 93 High Rotor 32 Engine Weight 27 Typical Operating Mission 37 Nacelle Drag Manufacturing Cost Temnperatum/Profile 69 Total 25 LCF Mission (Flight Cycle) Cointro Laws 7 Deceleration Time Fuel Flow 94 Control Stability Acceleration Time Temperature/Profile 71 Temnperature/Profle 72 HPT LPT Efficiency as HPT Efficiency 82 LPC Efficiency 8Fan Efcry - . Items -I - II - -t -I Noma - -- 1 0 Op 54 In 00 05 Idle 97 Burner Blowcout Margin 59 Delays and Cancellations 53 Aaline Operating Cost 51 Life Cycle Cost F- F ol 0 I i --I-- I 1 1 I 1 o I I F-F-T-T II I I -T-T-F-T-T--F- -4- ol ol o Io 09 9 i - I I I I I I Figure 19: DSM with a second set of assumptons during the aerothermal design. 73 74 DSM are believed to be applicable to a wide range of PDPs across industries. The authors experience suggests that the gas turbine PDP is fairly typical and appears to be consistent both with the authors System Design & Management education at MIT and with informal discussions with employees in other industries. However, detailed examination of other companies' PDPs is left to further work. Following the development of all the parameters in the DSM, the P&W process calls for the development team to summarize all the progress and risks that are present in the current state of the product and to plan the next stage of the PDP. The team then holds a senior management review where a decision is made as to whether to proceed to preliminary design. Determination Supersystem Requirements Historical Capability and New Design Concepts New Technology - - Concepts - - Determination of Highly Integrative Parameters Figure 20: Schematic DSM for Conceptual Design. 75 - - - Iterative, System-Level Simulation of Assumptions for Preliminary Design Although, preliminary design may seem to have many features in common with the conceptual design, the order in which the assumptions are made is different. For preliminary design, the initial aerothermal design parameters are used as a starting point to build a detailed system level simulation. The detailed simulation output is used as test conditions to validate the new technology as well as the new design concepts assumed during conceptual design. Due to risks identified during preliminary design, the design then undergoes iteration until the preliminary design is found to meet the supersystem requirements and program goals at a minimal risk. At this point, the preliminary design is used to develop system requirements and the program is launched. Figure 21 is the DSM ordered appropriately for the preliminary design phase. When extended to the general product development process, preliminary design consists of: 1) Obtain output of conceptual design, supersystem requirements, and program goals 2) Develop detailed system-level simulation to assist in risk identification 3) Validate the technology and design concepts within the module design 4) Document integrative parameters and system-level requirements This schematic preliminary design process is shown in Figure 22. In general, the simulations and models used in preliminary design are of a higher level of fidelity than the simulations in conceptual design. Also following preliminary design, the new technology and design concepts have been verified at the modular level. Note that in preliminary design, the aerothermal design 76 is completed prior to the validation of new technology and design concepts. Thus, these categories of parameters are determined in reverse order from conceptual design. Similar to the end of Concept Design, a product review is held with senior management at the end of Preliminary Design. At the product review, the plan for the remainder of the program is presented to senior management. To develop the program plan a very detailed risk management process is followed to identify and mitigate the major risks to the program. The deliverable from the preliminary design is the validation of the assumptions made during conceptual design and a set of system requirements that will be used for the detailed design of the engine. At this point the system-level requirements are documented and become very difficult and costly to change. However, the subsystem and component requirements are still flexible within the overall system requirements. The system requirements are documented as Chapter 1 in the PS/CRD. As Mascoli stated in his work, one of the enabling features designing a complex product with geographically distributed design teams is 1) a set of system-level requirements and 2) only small levels of interdependence of the subsystems. Preliminary design develops and documents system-level requirements with a high degree of fidelity for the detailed design and validation of the product. For large, distributed design teams, an architecture 2 that minimizes the inter-module 2When first attempting to develop an innovating complex product, the design teams are generally very small and are therefore do not need to worry as much about the independence of the modules. However, as an innovative product emerges into a market and competition based upon product architecture changes to competition based on process improvements, it may be that the architecture that allows the specialization and independence of the subsystems is able to improve faster than other architectures. This may lead the market to select the more modular architecture to become the dominant design. 77 interactions is one of the goals of concept design. Conceptual design thus sets one of the enabling features of the development of complex product architectures. Assumptions for Detailed Design The system-level requirements developed in preliminary design are used to start the detailed design of the product. Detailed design is normally accomplished on individual subsystems, at times termed parts, components, and modules. As such, the designers and design teams are developed and trained to be experts within their narrow functional area. The level of detail is much greater during this phase of design and as many people have stated, this is the deep dive of product development (Figure 23). During this phase, the system-level DSM developed in the current work is not appropriate. A DSM such as developed by Mascoli may be better suited for this phase of design, but even his DSM was considered a system level DSM. His work had approximately 10 parameters for each module. One view of this is that the 10 parameters defined the subsystems that are present within the module. A more appropriate level of detail may be to have a DSM of near 100 parameters for each module. This level of detail is what is most often developed during DSM research. For examples, see the work in the automotive industry [Pimmler and Eppinger, 1994]. This concept leans toward the hierarchical design of a set of DSMs. Figure 24 shows this schematically. 78 Items 2fi W 47 49 57 67 U W 92 93 32 7 65 94 6 14 15 27 69 71 72 72 77 3B 41 42 5 21 61 76 4 24 W 40 45 01 48 86 05 64 2 79 80 73 89 65 43 M 0 74 -- 4-- 78 --- 14604759aX382W 3181 ,1- 1Vj NNOWNWi6i" & 347091 8302 10 13 t2033752 18 - 1923252888 173650290758 JIM 9 10 87 3 09 8 16 54 IPT 1-14- - - - - - - - - - 55 56 % Do 05 95 97 i i i i 59 IF 51 1 -9 9 9 -9 9 - - - - - - 9 - - - 7 - - 9 - -a 44 - - - - - - - - - 0 - - - - - - - - - - - ,F 0 0 0 0 11 0 I 1 1 61 0 0 0 1 5 5 51 1 0 9 1.0 0 0 a 8 9- 0 a 9 9 9 0 4 4 4 4 4 4 0 00 E7 1 ni i 1 1 1 1 1 1 1 1 1 1 1 If 1 1 I 01I I I I I I I I i -A 1 1 1 111111111111 i i ol ii i1 o0i [--F-V-- t0 i i i OiI -F- I I iA i i i i i i i i i i o li Ii Ii Ii i i i i i i i i i I I Tor a! - f -0 0 iII I I I I I I I 1 om 11 I 1 1 11 I I I 1 1 1 1 I I I I I I I I I I I i I 1 1 I I 8 I I I I I 191 I 1 0%0 0 --0 ol 1 1 1 1 1 I Iol Oiol ofA i i i i i i i i i ui ol o 0 a a o 0- 0 I i I i i i i i i i I 0 It91 1 9 i 1 o 1 I I i I I I 9 91 0 0 - -I--- 9 9 9 9, OM ON i i I t- 1 91 OM 0 om - I o ol i I i T-1 1 M 0 0 0 1 I ! ! i i 9 1 1 1 1 1 1 1 1-11 1 101 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 I -+-:!-F T 9i 0 i i i I I I I I I I i i i i i i i i i i i i i i qq 81 II 1IN 1 111 o 1 1 1 olIli Uiol I 0 Fl Ii Ii I I I 01 1 1 1 1 i 0 1101i i i i i i i i i I-OT i i O i1 i I -F-IFoT i i i i i i i i i i i i i i i i i1 i1 i1 i1 i1 olrll; Ul I I I I I I I 1 1 01 0 1 1 1 1 ol i i iIIUiI i i i i i i 11 1 1 1 1 1 11 1 _I 21_ I I ol 14- IA ii i i i i i I 01I ol-0 1 1 I I o o ol I I omI I ol I I I I I I I I - I I I i I I I I - I!i P.21i i1 ii ii ii ii - , i I 51 1 1 011111 1 om 0 9 9 7 0 -0 00 9 0 9 9 9 9 9 9 9 9 9 0 0 1 01 1 1 0 0 1 0 0 a 11 1 I 1 1 1 1 ol 0 0 0 0 0 0 0 o 0 -- o Oft ol o 0 8 -9 0 8 0 o 0 a -- 6 0 0 1 am 9-- 0 o, --- 0 0, ------ 01 0 0 a 0 0- 0 ol 0 0 0 0, 0 0 a ----- 0 0 0 ol 0 0 0- 0 -0 0 0 _0 a o a a a -- o 0 0 0 0+-o - 0 0- -0 0 0 0 -2 00 -0 0 a 0 0 - 0 o -0 0 09 - - 0 0 0 0 0 0 0 0 1 1 0 - 0- - 0 o a 0 0 a 0 O ol o o o a 0 -o o 0 0 0 +:.0 0 0 0 0 - - 0 - - - - - - 9 9 9 o 0 0 0 0 0 91 0 0 o a 9 9 - -9 o - - - - - 9 0 9 9 0 a 0 9 9 9 0 0 0 0! ol a o ol ol 0 0 I I o 01 o 0 -+- - - -- 0 0 0 0 0 o 0 o0 0 1 0 1 a 0 9 ol 0 a ---- - - 0 0 - 9 0 0 D 0 -4 ol 0 o 0 0 o a o 0 71 4FG _0 -0+9f - - - 9 9 9 0 t o 0, 0 0 0 0 , 0 0 0 --- ------ 9 0 0 - 99 0 -0- - a- 0 a0 o Iio 4-0 1--1-6-01 0,0o---- Iol -R 9 9 01 o ol 0 0 0 al 1 9 0 -J0 9 0 - 26 Flight Envelopes (AR, MN, Temp) 99 Ambient Temperature 47 HPT/LPT Leakages 49 Anti-lice Bleed 57 Engine Change Time 67 Jet Exit Area 64 Burner Effiriericy 90 DuctLosses, 92 Low Rotor Inertia 93 High Rotor Inertia 32 Engine Weight 7 Deceleration Time 60 Fuel Rm 94 Control Stability 6 Acceleration Time 14 Take Off Thrust 15 Reverse Thrust 27 Typical Operating Mission 69 Total Inlet Ternperatura(Proffie 71 Bumer Inlet Terriperature/Profile 72 HPT Inlet TemperaturelProfile 72 HPC Flow Capacity 77 HPC PR 38 ECS Bleed 41 Starting Bleed 42 Stability Bleed 5 HPC Stability (Op Una) 22 HPG Accel Surge Margin 20 HPC Bodie Surge Margin (Sea Level) 21 HPC Bodie Surge Margin (Aftitude) 61 LPG Rm Capacity 76 LPC PR 4 UPC Stability (Op Lim) 24 LPC Surge Margin (Cruise) 60 Fan Rm Capacity 40 TOG Bleed 44 Nacelle Cooling 45 Air Oil Coolers 01 2.5 Bleed 48 HPTILPT Clearances 86 UPT EMicency 85 HPT Efficiency 64 HPT Flo v Parametw 2 High Rotor Speed 79 HPT Expansion Ratio 90 LPT Expansion Ratio 73 LPT Inlet Tamperature/Prolile 89 Primary Nozzle Perforriance 65 LPT Flow Parameter 43 Thrust Balance 39 TCA 63 Burrw R Capacity 74 Exhaust Gas Tempwature[Proftle 78 Bumer dP 35 Nacelle Thermals 66 Fan Exit Area 1 Low Rotor Speed 46 Buffer Goder 04 Fan/LPC Tip Clearance 75 Fan PR 90 Stalor Vane Schedule 33 Bird Loads 82 LPC Efficienc:y 30 Vibration Low Rotor 31 Vibration High Rotor 81 Fan Efficiency 34 Fan Blade Out Loads 70 HPC Inlet Ternperature/Profile 91 HPC Ctearances B3 HPC Efficiency 02 Engine Pressure Ratio 10 Fuel-Oil Coolers 13 Main Oil Temperature 12 Corrected Main Oil Pressure 03 Coritrol Laws 37 Nacelle Drag 52 Manufacturing Cost IS LPC Takeoff Surge Margin 19 HPCT/O Surge Margin 23 UPC Surge Margin (Max Climb) 25 LCF Mission (Flight Cycle) 28 Burst Margin 88 Fan Nozzle Performance 17 Noise 36 Extemal Componeitt Thermals 50 Diff/Combustor Design 29 Rotating Part Life 07 Nacelle Design 58 TMC 11 HPC Design 06 HPT Design 9 Fan Design 10 LPC Design 87 LPT Design 09 Mechanical Components Design 08 External/Coritrol Design 3 TSFC 8 Fan Op Une 16 Emissions 54 In Right Shut Doivris 55 Unsctieduled Engine Removals 56 Shop Visit Rate 96 Time to Idle 00 warrarity Cost 05 Fuel lAir Ratio 95 Time to Light 97 Burner Blo vwt Margin 59 Delays and Cancellations 53 Airline Operating Cost 51 Life Cycle Cost - , I. -6-6 0 0 0 0 0-0.1 0 0 0 - -+ - !J 7t4:a 0 0 0-- - - - - - -0 -- L Figure 21: DSM with assumptions for Preliminary Design. 79 80 Determination of Conceptual Design, Supersystem Requirements, and Program Goals Detailed Syste n-L evel Simulation Subsystem Validation of New Technology and Design Concepts - Document Integrative Parameters and System Level Parameters Figure 22: Schematic DSM for Preliminary Design. D=C] Concept . Preliminary Validation Ogg 0n Detail 51UL -9 Figure 23: Levels of decomposition examined during product development stages. 81 t - I - I - /'x on -H-H-++J-H 11 11 HH! I i ................... i ! ! i i i i i - -M System (current work) _::_ TIl'~IrF 1st Level of Decomposition [Mascoli, 1999] 2nd Level Decomposition (future work) Figure 24: Hierarchical set of DSMs with ever increasing detail. Iteration in a more integrated level of decomposition than is currently being worked, e.g., at the system level during detailed design, is both expensive and time consuming; however, many times it is both desirable and necessary to ensure larger problems do not occur even later in the product development process. Within P&W, the development of a program plan that includes iteration at the system level has historically been accomplished in an ad hoc manner if it occurred at all. As the business focused on reducing the product development time and costs, 82 iteration during the detailed design phase was replaced by simulation and iteration in the preliminary design phase. While this does decrease costs and product development time, without the proper tools and risk mitigation planning, it could potentially result in design issues being uncovered during validation where all changes are both very expensive and time consuming (which result in customer satisfaction and public relations nightmares). While risk mitigation during program planning has been occurring within P&W for many years, up until recently, there has not been a formalized process. Within the last year, a formalized process for risk reduction during program planning has been established within P&W. The P&W process does not utilize DSM, but rather explicitly accounts for the interdependencies in another manner [see Zeidner and Wood, 2000 for a public discussion the process]. Utilization of a formalized risk reduction process has resulted in system level iteration cycles being inserted to program plans. While the specifics cannot be discussed in this work, the iteration cycles inserted have been of the inter-module type (the area of the "glue" engineer discussed by Mascoli) as well as the system-level type (the area of the aerothermal cycle). This risk mitigation planning now occurs during preliminary design and is inserted into the program plan prior to the start of detailed design. Risk identification and mitigation within modules occurs, but it is not currently part of a formalized process and still occurs on an ad hoc basis. The detailed design phase at P&W is represented well by the work by Mascoli (although development of a DSM with increased level of detail for each module would enhance the 83 representation, this is left for future work), Figure 253. The steps that occur during the detailed design stage may be generalized as follows: 1) Obtain system-level requirements from the preliminary design phase 2) Develop requirements and identify risks for module to meet 1)4 3) Complete detailed design and develop integrative module parameters 4) Validate component design through production of prototype parts Steps 1-3 occur within a parameter DSM. Step 4 occurs in preparation for system validation. A schematic of the detailed design DSM is shown in Figure 26. The end of detailed design and the start of validation is not as well defined within P&W as these stages always overlap. This is in part due to the desire for the detailed requirements to remain flexible as long as possible. The Level IV product review essentially ends Detailed Design for a component; however, changes to occur following the review. Throughout the Detailed Design and Validation stages, the program plan in continually updated to both reflect the current status of the program and to insert additional risk mitigation efforts that are identified during these stages.5 Assumptions for Validation Validation of gas turbine engines consists of measuring parameters on complete engines in a series of tests that are defined by the FAA and JAA. The passing of these tests allows for certification that the engines are safe to fly on an airframe. The FAA and JAA testing does not 3 Figure 22 is taken directly from the work of Greg Mascoli. The author would like to thank Greg for permission to use his work. 4 Historically at P&W, the module requirements are decomposed into two sets of requirements: the component requirements (design), and the product requirements (manufacturing). These requirements are approved by module management in Level III and Level IV Design Reviews. 5 The program plan is allowed to change during the detailed design and validation stages as long as the certification date and the budget are maintained. If either of these must change for the worse, a senior management review of the reasons is required. 84 I Aircraft/EngnoRange B Pass Ratio 1 1 1 I Development Cost Drag 1 11i Drability/LUfe Emissions Engne Fow Cor 1 Rot-rSped (N2) Low Rotor Speed (NI) High-Low Spool Work -o 1 11 1 1 1 1 1 it1 1 it 1 1 1 t 1 t 1I Ii lii 1it 1 11 1 1II 1 1 I i t Jet Velocity 1 Maintesance Cost Matemial Setecion Nos Overalt Pressure Ratio Production Cost ii 1 Propulsive Efficency Relability (Engie System Spefic Flow (W/A) sperature) T3 (HPC Exit T T4 (Cotbustor Exit T 1 I 1 11 1 1 1 1 1 it 1 1 1 t 1i1 1 1 1 1 1 1 1 Ill 1 Ii i i 1 atoie Thermal Efflnocy Thermal Manag mbnt Subsystais Thrust Weight 1 1 1i It1 Total Flow 1 1 1 1 I I TSFC Turbine Cooling dir Enie prabulty Maium|lW'%nt ..-- III--.-. Fan Airfoil Fan Blade Containmsent Fan Eficiency Fan Gap/chord ratio Fan Fee Fan Fan 1 W4. m 1 Operability/Surge Pressure Ratio Tip Diameter Tip Speed Fe Blades Nunber tNuber of FEGV Fan Hub/Tip Ratio inlet Distortion LPC Airfol LPC Axial Gapping LPC Airfoil Counts LPC Blade Tip Clearance LPC Bleeds (Config. & Flows, LPC Diameter (nlet/iEit) LPC Disk/Drum Design LPC Eficiency LPC Length LPC Operabiity (SurgeM LRC Pressur w Ratio owrk) i 1 1 I I 1 1% 9f1 1 1 1 1 1 of i tI 1 1 1 FK I 1 1 1 .Is 1 1 Be~ R~tSteo tn N JHPC MladeM~Root Stress (Limiting) HPC Axial Gapping HPC Airfoil Counts HPC Bleeds (Config. & Flows, I 1 HPC Case Design HPC Diameter (Inlet/Exit) HPC Disk/Drun Design APC Elicuncy APC Exit PresTemp Proille APC Length APC Operability (Surge Margin) -PC Pressure Ratio -PC Stage Count -PC Tip Clearance /rnable I 1 1 11 1 1 1 ARC Airfoil 1 1 1 II1 1 1U 1 1 I I 1 1 1 I 1 1 ~ 1 1 1 1 ombustor Pressure Loss Temperature Diffuser Delta Pressure Reovery )ifuser/Comsbustur Length Sembustor uit Tetnperature Stirucurel 1 i1i ill 1 a -- I 1 1i 1 1 -- t--- _---- _ 11 _ 13 I I 1 1 i1 ii 3 3 1 I Speed StIOS CiSud Meter Shaft Lw Rotor Citical Speed 1 11 11 1 Lw Ror Shaft Design Lw Rotor Shaft Torque PT Airfoil Counts PT BtadeTip 11 1 Stillness sembostor Effiuienoy Durability/Coatings Selection HPT AN^2 APT Airfoil Counts APT Blade Tip Clerace IPT Airfoil Design APT Disk Design APT Efflieny HPT Expansion Ratio APT Fmw ereameer APT LesNgth APT Stag Count APT Ve oy Rtie Cleerencie 1 1 1 I 11 11 1 1 11 PT Case Cooling PT Diaenter (nle/Edt) PT Dsk Design PT Efticiency PT Expansion Ratio -PT Legth PT Stage Count PT V dtyRatio PT Il1 111 GometryConfiguration .ombustor iser 1 ..... Its..1 I %I Airfoil 3enng Locations aid aeiog Reliability eaerog Tedwointgy (ON) Bed Design Ai & Lube System Frus Mou t ~IM 1 Il 111 odgraionA Figure 25: DSM of detailed design for gas turbine engine [Mascoli, 1999]. 85 86 ~ - I, Determination of System Requirements Module Requirements Proto ype - ~ oro uction Prt--- - i - -- yi - Ydi - - --- -- u~euieeT ~-- Prototype production - - - ----- ---- ~- s- ---------~um -- mProdtype ro uction Figure 26: Schematic DSM for detail design. require superior fuel consumption, low maintenance cost or other customer driven requirements. Thus, many of these parameters are also measured during the validation of the engine. For several of the highly integrative, customer requirements, no direct measurement is possible prior to years of field experience. For example, the rotating part life is not determined during validation testing do to the length of time and expense to directly measure it. In order to "validate" these parameters, P&W will measure many of the parameters that are inputs to and/or control the integrative parameter. P&W then states that given the input parameters were as expected and the quality of the estimation procedure developed over P&W's history is good, the integrative parameter has a particular value. In this way, P&W validates all parameters whether they are measured directly or indirectly. During validation P&W measures thousands of parameters, many of which are parameters utilized in the DSM of the present work. 87 Examination of the validation phase in terms of a DSM, the assumptions (or requirements) are the hardware output from the detailed design phase. To proceed through the validation phase, many aerothermal and mechanical parameters are measured and then compared to the system-level requirements developed during preliminary design and the component requirements developed during detail design. With two major and several minor exceptions, many of the parameters in the system-level DSM developed in this work are measured early on the first prototype engine that arrives in the test stand. The two exceptions are the detailed performance parameters (TSFC and module efficiencies) and the operability parameters (the surge margins). Although the performance parameters are roughly measured on the first engine, validation of these parameters is accomplished on a highly instrumented, dedicated performance engine. Similarly for the operability parameters, the operating line is measured on the first engine, but the surge line is not measured (hopefully) and the surge margins validated until a dedicated engine. Although several of the component requirements are validated on the first engine, most of the detailed module requirements are validated during a dedicated stress and telemetry engine for each core. The minor exceptions to the measurement and validation of the system-level requirements are due to the parameters that depend upon the detailed validation of modules (and therefore the dedicated engines) prior to their validation. Upon validation of the modules, these parameters are then integrated and validated as a whole. A validation DSM is shown in Figure 27. 88 9 II HPC Design HPT Design 9 Fan Design 10 LPC Design 87 LPT Design 50 Diff/Combustor Design 06 9 9 9 9 9 9 9 9 0 9 63 Burner Flow Capacity 78 Brrnr d 79 HPT Expansion Ratio 80 LPT Expansion Ratio 89 Primary Nozzle Perfomanrce LPT Flow Parameter 65 91 HPCClearances 85 HPT Efficiency 75 Fee PR 83 HFC Effiuieny 96 Staler Ve Shedule 8 LPT fficienuy 10 Fuel-04 Coolers 13 Main Oil Temperature 12 Corrected Man 01 Pressure 37 Nacelle Drag 52 Manufacturing Cost 18 LPC Takeoff Surge Margin 19 HFCTIO Surge Mrgn 23 LPC Suge Margin (Max Climb) 25 LCF Mission (Flight Cycle) 28 Burst Margin Fan Nozzle Performance 17 Noise 36 External Component Thermals 29 Rotating Part Life 92 32 92 03 7 9 -t 9 9 00000000--FF 6 02 2 14 9--7 74 15 31 27 30 9 9 9 9 .a 9 76 77 62 38 61 41 22 4 5 9 9 9 __9 9 -- 9 9 9 9 9 9 9 9 9 9 9 9 -9 I- 82 81 9 -9 9 9 04 69 34 20 21 42 24 71 70 73 46 40 43 39 44 01 3 45 66 00 40 64 9 9 63 78 79 89 80 65 9 9 911 9 9 999 -9 9 - 96 9 - --- + 44 --- +9 9 9 9 J1 0 7 8 ~ ~~00 a 8a8 0 0 111ifY1 Vffff f'f'f'tIf ':: 't'f'f'f'f'f 11111111 ff1 f'f'f'f'f'f -F - ,InI ImtiT~z 0 0li i i 4 'ii-+4 0 0 0A~ 10 0 0 - o4o 0 0 It 0 0 0 0 0 0 0 _ 29K 0 0 00 5 5 ol 1 0 0 0 0 0 1 1 1 1T--F -4-4 i I I I ol 0 0 - 00o I _ 0-i+t4 o0 0 o0 -0 0 o I_ I I I I I I _ 1 1 ___ I _ __ 5i 51 51 5 5 1111$ lfzfifzif 1. 0 0 0 0 a I'I'i.t1t't'~f 11111'III15f~4~ I15 i i - F-i - - - F - F - L. -1. -.-L A 1 1 S0 -1V, 1 00 0 0 3 FI I i-i -+- <- HIII-111111-11111HIIII 1i -i i - i i i iIii-~ F-i Fi i-F -- 1i - - --1I - F-i- iO i - - - I Fii i - -i -F -F - t- t i I 00 +- > 11 I I 01 3 _7 z II - - Hi 1 I I I - A- - F - I I I I I i I I F--F--F-F I I 1 1 1 1 1 01 1 1 11 1 1 I1I'1 0 14- I I I III 1 _4_ I I t t t -A-AA-1 -I- i 1 1 1 -I -i-A---AA-4r-rF-FF-F 1 11 1 1--F !1!!-A-4-- !I! 1 1 zizI '1 '1'1'1'1']'1'f '1 '1'1'1'1'f 'I 'I 'I 'I 'I 'I I F-f ~14"flfl 3 ILA --L-- -F-F--t--l--I-A--F--I-F-F-F-F-F-F-F-F-F-f-f-I--F-F-F-F-F-F-F-F-F-F-F-F-f- ['1'1'14'L'I'f '1 '1 :1 II 'I '1 '1 I4z]I]zf If IfIf IfIf If IfIf If If If If III U' iF-F 1 K~H~fl ~1Th HW 3~31i1J1H - 131 1 3- 11 01 -- F I 1b0 1 1 1 01 01 F-A I I I '------ r-I-*-I-+-F-I-F-F-F-F-F-F-F-F-F-F-F-I-- 1 1 t -1 '1 1 14JII HHLI '' 0 11 I I I I I I I I I I I I I I I I I i i i .. I0! ' I I I I4'K I i i i [ L-- I 0 -- 00 00 100 o 0 0__ - 1 I I I01AI 1 01 01 101 i -1I I 404 F-4- II 0 0 -1 f- I 4- 3 3 - -F -F -t I I L o----Or 0 80 - 1 31 3J II- IF ii i ii i ii ii i ii ii i ii i ii i ii i iii i ii ii i ii i i ii i ii ii i ii i I - -11-i i- i i-iiiiiii1li1lo i 0 4I I I 4 1 1 1 1 1 1 1 _ 1 _ 0 0 - i5I 51 o] ~1 I lii m I ' l l l l.! 1.1 1 -1 f11 f i l iz 1 ! !t 'l l !!111 1 -1 0't't'1 1o !41 0 4 I 00 0 0 00 -0 4-- l 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1- 1 ff111111111 f'11'1'1' t44'f'f-4 f'f'fzfzf'f 00 +-- - Ooo0S0 5 I I o o 04 0 -0 0 5 0 0 0 07p 00 o 0 000 0 I _I _ I _ I 0 0 0 1~io111 I i 5 5P 5 55 0 i -A--A---A---A-A--A-F-4--4--4-4----A-A-A-F-F-F-F-F-F-I--F--A-I--1--1-+--F--F-F-F-F-F--F-F--t- fzf'1z1z1'1zt till] 0 0 0 t-. t -l t iA- - I-A-A-- i - F-f - - F-F- - -F- - t 1 1 - -i1 1 i1Aii1-A1 1 1 1 -A-A-A-A--A-I--A-A---4--A--A--A----F---F-F-F--F-F-F-F-1-F-F-F-F -F-F--F--F-F-F-F-F-F-i il I I I -]-A-A-F-F-A-A-A-I--A-A-I-A-A--A--F-F-F-F-F-F-F-F-1-F-F-F-F-F-F-F-F-I--F-F-F---F1 i i i 0 05 40 0 0 -a-i-- ii ii i 0 i li 0 0 - 0 0 I 00-F -4 6 0t 0 0 1 0 0 61115 6 . 71 - 0 7 - IL-I. 1 - 00 0 0 G 0,I 0 0 o o 0- 0---- 0 6 58 TMC TSFC B FnOptine 16 Emisison In Flight Shut Dowrs 55 Unscheduled Engine Removals 56 Shop Visit Rate 96 Time to Idle 00 Warranty Cost 05 Fuel Air Ratio 95 Tirm to ight 9 Burner Benent Margin 5 Delays end Canceltons 53 Airien Operating Cet 51 Lile Cyle Cet 3 0 00 0 0- 0 0 f ___ 1 0 0 0 0- 0 00 -0- _ _ 1T1 0 -0 0- 00 a 0 -- 0-0 -- 0000 0 0 -- 0 - 54 0! 011<1 __ 1 011111 0 1 __ _ __I -III _ I_ oIII-aKt-4 II I1 i 0101 1 ~-0------- I I I I II t I I -- I I I I I 91 9 9 9 FF:: 9 9 72 9 9 79 t9 9 9 99t 33 1 9 9 9 9 _ 94 9 9 9 9 9 91 9 9 9 9 68 - L% 14- 40 HPTtLPTnCearances 64 lIFT Flee Paranreter 90 04 - a-0 01 2.5 Bleed 30 Nacelle Thermals 66 FanEx8t4Area 60 Fan Flow Capacity 67 0- 92 High Rotor Inertia 32 Engine Weight 03 Control Lnaws 7 Deceleration Time 68 Fuel Row 94 Control Stability 6 Acoeleratian Tee 02 Engine Pressure Ratio 14 Take Off Thrust 2 High Rotor Speed 74 Exhaust Gas Temperature/Profile 1 Low Rotor Speed 39 TCA 57 0 0 -0 0 0 0 0 0 0 010 0 92 Low Rotor Inertia 44 Nacelle Cooling 45 Air Oil Coolers 49 0 84 69 Total Inlet Temperature/Profile 04 Fan/LPC Tip Clearance 81 Fan Efficiency 02 LPC Efficiency 76 LPC FR 77 HPC PR 62 HPC Flow Capacity 61 LPC Row Capacity 38 ECS Bleed 41 Starting Bleed 5 HPC Stability (Op Line) 4 LPC Stability (Op Line) 22 HPC Accel Surge Margin 20 HPC Bodie Surge Margin (Sea Level) 42 Stability Bleed 21 HPC Bodie Surge Margin(Altitude) 24 LPC Surge Margin (Cruise) 70 HPC Inlet Temperature/Profile 71 Burner Inlet Temperature/Proftle 72 HPT Intet Temperature/Profile 73 LPT Inlet TemperalureProfile 46 Butler Conoler 40 TCC Bleed 43 Thrust Balance 47 0 67 Jet Exit Area Burner Efficiency 90 Duct Losses 33 Brd Lods 15 Reverse Thrust 31 Vibration High Rotor 30 Vibration Lw Rotor 27 Typical Operating Mission 34 Fan Blade Out Loads 9 00 57 Engine Change Time 0 9 9 9 9 9 Design 07 Nacelle Design 47 HPT/LPT Leakages 49 Anti-ce Bleed 0 9 9 9 07 9 9 9_ 08 Extemal/Control Design 09 Mechanical Components 9 9 9 9 99 09 00 87 50 10 9 + 06 11 99 - 26 26 Flight Envelopes (Alt, MN, Temp) 99 Ambient Temperature - Items I I I I I I I I I 1- 10 __ I IololI olI ol I I ol 0 0 011 0 1 1 1 1 1 ORR -I1 8 75 83 98 86 10 13 12 90 Generalizing the P&W example results in steps for validation as follows: 1) Obtain module hardware and develop system prototypes 2) Measure parameters as possible through system testing 3) Determine integrative parameter values 4) Validate parameters meet all requirements, mitigate risks identified A schematic validation DSM is shown in Figure 28. Risk identification and mitigation occur continuously during validation. Also during validation (or earlier) a plan of support of the engines in the field is developed. This includes any issues that arise during validation that can be resolved following certification (e.g., a cyclic life shortfall in a rotating part). Deliverables from the validation phase are measurements (or calculation from measurements) of all the system level and component level requirements as well as certification by the FAA and JAA. Summary A system-level DSM has been developed in this work for a gas turbine engine. It differs from earlier work in that it was developed from a high level system engineer's (or chief engineer's) perspective. As such, the subsystem (module) designs of a gas turbine engine are represented by single parameters. It was found that most of the issues that the system engineers work with on a daily basis are not represented in the DSM directly. Instead it was found that chains of direct interactions (i.e., indirect links), represent most issues dealt with on a daily basis. From discussions and examples found when working with the system engineers, most issues are 91 linked through three or more direct interactions (although no example was found to have more than six links). Given the indirect nature of the DSM and the interdependencies of the parameters, it was of no surprise when initial attempts at partitioning the matrix produced few results. In order to develop a better understanding of the DSM, this work examined what parameters are assumed and when they are assumed. The nature of the assumptions made and its interrelationship with the requirements were examined as a function of time within the product development cycle. It was discovered that a single DSM used multiple times could represent the majority of the product development cycle (conceptual design, preliminary design, and validation). The exception is detailed design where the system-level DSM is viewed as requirements and more detailed DSMs are required for each subsystem being designed. Combining the DSMs for each stage into a single matrix is schematically represented in Figure 29. Note that in this context each parameter is actually a task to determine the parameter value and not the parameter itself. While the schematic DSMs show rearrangement of the parameters in the DSM from a high live view, Figure 30 compares the sequencing of each of the DSMs to the order in Figure 18, the one order of assumptions that could occur during conceptual design. 92 Assembly of Parts and Components into System - 1 1 1 - Testing and Measurement of Parameters Determination of Highly Integrative Parameters Validation of System Requirements Figure 28: Schematic DSM for the validation phase. .1 1= 51MMU U ........... 0b ...... ...... ~ Figure 29: Schematic DSM for the entire product development cycle. 93 0 Q C ( C 100 100 - c 80 c 60 8060 0)D 0 40 o 40 S2-20 08 1 C-) 11 21 31 41 51 61 71 81 91 101 Conceptual Design (1) Sequence 100- 11 21 1 11 21 100a a) CO 80- U) - 60 a) a, 40 -0 20 40 20 a), 0 a) 0 1 80- c60 31 41 51 61 71 81 91 101 Conceptual Design (2) Sequence 1 11 21 31 41 51 61 71 81 91 101 Preliminary Design Sequence 20, 31 41 51 61 71 81 Validation Sequence 91 101 Figure 30: Comparison of sequences of Conceptual Design, Preliminary Design, and Validation. 94 CHAPTER 5: DISCUSSION This chapter has been divided into two sections. First, the implications of the research for Pratt & Whitney are discussed. In this section are several discoveries that are not conclusions that could be drawn from the work discussed in the prior chapters. However, the path of research often leads one to discover items that should be discussed (thus, their appearance in this chapter). In the second section, the specific P&W recommendations are generalized and other implications discussed. Implications for Pratt & Whitney Requirements Documentation The requirements documentation at P&W, the PS/CRD, has evolved into a quality set of documents. The suggestions given here will only serve to enhance the documents and streamline their implementation and flow-down. Five recommendations are suggested by the current research. 6 First, include the Design Table as part of the PS/CRD. The design table formalizes the aerothermal requirements at the system level and is used by the IPTs to design their components. Having two separate sets of requirements only serves to confuse the IPTs. This is especially true when the aerothermal design is undergoing fast iteration for various scenarios that could develop during product development and field service. The inclusion of the Design Table in the PS/CRD The author had the opportunity to implement these recommendations in the PW4000-100 PS/CRD and will subsequently propose a revised SLP where these suggestions may become part of the formal P&W procedure for the development of a PS/CRD. 6 95 will help clarify the requirements for the design of an engine. Subsequent release of a new Design Table would force the PS/CRD to be updated and a holistic set of requirements released simultaneously. With the Design Table as a separate document, conflicts between the Design Table requirements and the PS/CRD are much more likely to exist. The integration of the Design Table with the PS/CRD will also encourage more interaction and collaboration between the PSA and SD&CI organizations. Second, insert the risk reduction and mitigation planning into the PS/CRD. Communication of the methods and reasons behind the development of the program plan will serve to drive the understanding and appreciation of the risk through the product development organization. Tracking of the progress of the program against the planned risk waterfall will also serve to highlight the success and difficulties in a product development cycle. This helps to drive understanding from the product development team to both upper management and the detailed design engineers at a geographically dispersed locations. Third, eliminate the Design and Validation Process sections of the PS/CRD. This section is redundant with System Level Procedures (SLPs) controlled through IS09000 certification. The PS/CRD should only contain requirements and not procedures by which to accomplish the requirements. Only in cases where a decision is made to violate certain procedures should a procedural requirement be included. Fourth, develop a minimal set of times for a PS/CRD to be released and updated. The PS/CRD is initially released at launch of the detailed design, but its control and maintenance has 96 not been a focus of the SD&CI organization. At a minimum, the PS/CRD should be updated and rereleased following the testing of the first engine, upon certification, following flight test, and after three years of service. For these last two releases, the focus of the PS/CRD should be on support of the engine in the field (i.e., specifics about the product development cycle should be removed or restated). Finally, the PS/CRD should be updated and released at the initiation of any large change to a module (i.e., a derivative design or a FAA major change). As has been the theme throughout this work, it is not possible to change a module in any significant way without altering the entire system. All PS/CRDs should be a complete set of requirements. This is especially true for derivative models or module changes as it reinforces the requirements to maintain commonality. Focusing a PS/CRD too much on only the desired hardware changes risks missing an interaction that may prove to be important. The issue here is resource constraints for derivative programs that do not have a baseline PS/CRD. Management will be required to trade resources required to develop of a holistic set of requirements with the potential for confusion and error caused by incomplete or conflicting requirements. Fortunately, as time progresses with all new engines having PS/CRDs, this situation will occur less and less. Organizational Impacts Since one of the abilities of the DSM is to align organizations with the associated architecture and program plan, the DSM in this work examined to see if any changes would be beneficial. This analysis does suggest some realignment within the system engineering organizations. 97 First, the DSM does reinforce that PSA (the aerothermal parameters) and SD&CI (the design and structural parameters) may be separate organizations at some level; however, the interconnections between the parameters suggests that a single chief engineer should be present over each product development cycle. The current lack of a single person responsible for the entire tecimical delivery of the engine relegates the authority for any conflicts to the Program Office and its Program Manager. While on some programs, the Program Office has informally designated one of the three systems engineers the role of Chief Engineer, it does not always occur and in these cases the program office makes many technical decisions. This upsets the balance between forces pulling towards faster/cheaper and the forces pulling towards better (when they are in conflict). When this balance is upset, it may result in a less than desirable product. A Chief Engineer role to balance the Program Office and Program Manager role should be put in place. The single chief engineer suggestion is in direct agreement with a conclusion of Mascoli and agrees with the spirit of Rowles suggestions. (Rowles did not specifically address the three system engineering organizations, but rather referred to them in combination as system engineers.) One difficulty in implementing this role would be the development of single person with all the skills necessary to balance the needs of the organization. While these talents do not exist in enough people to implement this across P&W, with strong deputies in each systems engineering specialty, a person could grow into this role. One thing that is a given is that without the Chief Engineer role present in the organization, little incentive exists for people to obtain the broad expertise necessary for such a role. 98 One comment on the current work is that the PD&V organization is not represented in the DSM other than being responsible for the measurement of the parameters during validation. While this may lead one to suggest that PD&V is not of sufficient importance to the product development to warrant a system engineering organization, the author believes that this omission is due to the focus of this work on the parameter-based DSM. If a task-based DSM would have been completed, it may have suggested that PD&V is the only system engineering organization necessary. Thus, the author believes that each of three system engineering organizations serves a valuable role within P&W. The final glaring omission in the present study is the presence of a Manufacturing Systems Engineering organization. At the present time, it is unclear to the author as to the need and value created by this organization. This uncertainty is due to the author's lack of knowledge of this organization and its role within P&W. The study of this organization and its role would be a fruitful area for future thought and work. Within the three system engineering organizations, the DSM suggests that the secondary flow organization may align better with PSA than with SD&CI. As can be seen in Figures 18, 19, 21, 25, and 27, the parameters that are the responsibility of the secondary flow organization (i.e., bleeds and leakages) are an integral part of the aerothermal design that is PSA's responsibility.7 There are two main lines of communications within the secondary flow organizations: one based upon the aerothermal design already discussed and the other based upon the cooling and temperature impacts on the structural integrity of the components. The author assumes that in the development of the current organization it was thought that large block in the middle of all the P&W specific DSMs is the aerothermal design of the engine. This region is the system-level simulation in the schematic DSMs. 7 The 99 communication along the structural impacts was more important and thus, the inclusion of the secondary flow team within SD&CI. The present work suggests that the alignment be changed not because of the aerothermal design being of more importance, but that closer alignment with PSA will occur without the loss of alignment with the structural organizations within each module. In the current organization secondary flow communicates structural issue to the module center teams. Little information flow is necessary to SD&CI and all SD&CI has been is secondary conduit for information flow (especially through the PS/CRD). Thus, little will be lost by removing secondary flow from SD&CI and significant alignment will occur with PSA. Simulation vs. DSM At P&W and in general within the gas turbine industry, system-level simulations of the entire gas turbine are fairly common and very detailed. These simulations have been developed over many years through experience at the companies as well as by the extensive research completed at universities across the world. A gas turbine physics and parameter interdependencies are well understood (at least for the aerothermal cycle). The companies use these simulations extensively during the design and development of engines and have even considered eliminating the development testing due to the capabilities of the simulations to design components "right" the first time. (Actually it is not the first time, it is the first time in producing physical components only. Prior to making components, many iteration cycles occur in the virtual world). The implications of having these high quality system level simulations is that most of the interdependencies are already accounted for and the DSM is of less importance than in industries 100 where these types of simulations and knowledge of the interdependencies do not exist. The most fruitful area for DSMs would then be in the areas where detailed, physics-based simulations do not exist. Another areas where a DSM may be helpful is at the interfaces between the simulations. Applications for DSM within P&W Two areas are perceived to exist for application of the DSM tool within P&W. The first is in training an engineer in the intricacies of the interfaces within the gas turbine. Currently, only years of experience within the industry at the system level (or graduate education at universities like MIT) give an engineer the mental model that includes many of the interdependencies present within the gas turbine. The DSM may be a valuable tool for newly hired engineers to begin to understand the interdependence of the parameters. The young engineer would then be aware enough to ask for assistance in determining the exact affects of a relationship. Second, the DSM could act as a quick reference guide to system engineers when dealing with individual design issues. It may serve as a guide as to whom to ask about the impacts of an engineering change. 101 General Implications of Work Lessons from Pratt & Whitney Requirements Several lessons can be learned from the Pratt & Whitney experience. First, the development and documentation of system requirements should be started early in the product development cycle and continuously monitored and updated throughout the cycle. Establishing system-level requirements (actually documented assumptions) early allows the entire product development team to work from a single set of assumptions. Establishing the time phasing of the requirements development to the product development cycle helps keep many of the detailed requirements flexible while maintaining the system-level requirements necessary to meet the customer desires. Requirements are only established when a change in the parameter becomes difficult or time intensive. For processes that have changing customer desires a hierarchical ordering of requirements establishment will allow the teams to understand what can be changed easily and what would require the entire PDP to be restarted. Maintaining the requirements document with periodic updates is essential to keeping the entire product development team working to the same set of assumptions. One note of caution is that as the frequency of updates to the requirements increases, communication of the updates becomes more and more important and time consuming (depending of course on the tools used). Thus, a balance is needed between having the most recent requirements available and the manpower required to communicate these requirements across the product development teams. 102 The requirements document developed should include all requirements for a particular level of decomposition. For example, all system level requirements should be present in a single location. Pratt & Whitney had requirements developed and published by organizational boundaries. This is not a preferred method for the requirements. This work suggests combining all the system requirements into a single document. (Note a document is not necessarily a paper document, it could be a single electronic file or database). Subsystem requirements should either be in the same document as the higher level requirements or maintain strong links such that as requirements change on one level of decomposition, the changes flow to the other levels within the product. The present work suggests that the risk mitigation plans should be inserted into the requirements documentation. While the author believes this is the best approach for P&W, it is not the only approach for disseminating the risk reduction plans and iterations cycles that have been inserted into a project management plan. The need is for the product development team to have the risk identification and mitigation plans communicated to them. On many large product development projects, most of the IPT members are far away from the program planning. Thus, the communication of the risk mitigation plan within the program plan allows the individual team members to understand the strategy, reasoning and layout of the tasks they are charged with completing. This helps to align the product development team around the program plan. The updating and tracking of the risk levels within the program helps the individuals understand the progress against plan and be more likely to accept changes to the plan when the need arises. 103 ProductDevelopment and System EngineeringOrganizations As companies strive to improve their product development cycles by decreasing the cycle time (faster), decreasing the costs (cheaper), and increasing the quality of the product (better), conflict often occurs between the faster/cheaper and the better. While organizations strive to find initiatives and improvement that will allow all three to occur simultaneously, many times the goals are in conflict. For these situations, an organization should strive to balance the forces that are driving to each goal. Developing an organization or culture that has one or two of the goals stronger than the other is a situation that has a high risk of failure. Striving for too low a cost risks getting a product to market on time with poor quality. Trying to get the product to market in the quickest manner will sacrifice cost and quality. A perfect product will never get to market at any cost. Thus in most situations, a balance must be formed between these goals. For very large, complex products where hundreds if not thousands of individuals are working to bring a product to market, the work must be decomposed into smaller pieces to then be integrated together. Balancing the forces that pull the product to market is not a trivial task. Many organizations accomplish this task by developing matrix organizations where individuals are responsible to both functional organizations (where quality of work is usually the dominant goal) and to product organizations (where cost and speed to market are often the dominant goals). The balance is set by maintaining the strength and power of each organization. For large product development teams, a system engineering or chief engineering organization often resides at the top of the functional organizations. For such organizations, the balance must be maintained between the product organization and the Chief Engineer. In the authors view, P&W had upset the balance by dividing the Chief Engineers role between three separate system 104 engineering organizations. While P&W management correctly observed that the system engineering has at least three specialties in their product, separation of the system engineering into three organizations led to a situation where balance was not maintained and the speed and cost goals were driven at the expense of product quality. Inserting a Chief Engineer by product would likely reinstate the balance. The main lesson in organizational development using a DSM is that the balance of goals in the product development cycle must be maintained while working to align the organizations to the architecture and program plan. System Modeling and Simulation The gas turbine industry has a very mature set of system models and simulations that include most of the interdependencies present in a gas turbine engine. For industries like the gas turbine industry, the simulation and modeling allows for many iteration cycles to occur during product development. Often these iteration cycles are not even recognized by the majority of the product development organization. These simulations and models also allow for quick response to issues and problems that arise during the development cycle. However, one of the dangers in using the simulations and models is that the only individuals that understand the entire set of interactions are the people that develop the model. Often not even the users of the model understand the interactions until they have a significant amount of experience using the tools. This leads to an over reliance on the simulations and can lead to the slowing of product development when this organization gets overburdened with requests of "what-if' questions. (This is the positive side as at least individuals are asking about the interactions. Often people 105 may not even know enough to realize there are interactions that they should be concerned about). This is where the DSM may play an important role in product development. The DSM can raise awareness and understanding of the interdependencies present in the product and release some of the this burden from the simulation organization. For industries where high quality system level simulations do not exists, the DSM may play a much stronger role in assisting the system engineer during product development. This situation is almost always the case for innovative products and new architectures. It is also the case in mature industries where the system level interactions are not simple physics (as in the gas turbine), but a mixture of complex interactions that are not yet well understood from first principal physics (e.g., the automotive industry). Assumptions, the Parameter DSM, and the Product Development Cycle Assumptions that occur during product development are often made to break a known feedback loop such that the first cycle through the development of parameters may be completed. As was suggested earlier, these assumptions often become requirements that are then passed through to later stages of product development. During the current work, 3 of the 4 stages of product development examined are represented by a single system-level, parameter-based DSM. As each stage had different assumptions, the order in which the parameters were developed changed for each stage. For the detailed design phase, the system-level DSM did not provide enough information. More detailed subsystem level DSMs were suggested as being more appropriate for detail design. 106 Overall, the repetition of the use of a single DSM (with an expanded DSM for detailed design) and the relationship between the DSMs is shown in Figure 29. While a single example the relationships between the DSM and the product development cycles has been shown, the author believes that this repetitive use of a system-level parameter DSM occurs in many product development cycles. The P&W product development cycle appears to be typical of a large, complex development cycle of a physical product. Many companies have represented their product development cycle with a V (Figure 23). In this representation, the development cycle starts with high level work, decomposes and designs at a low, part level and then integrates all the parts together to work the total product again at high level (thus, the high, low, high, V representation). Many system engineering and product development texts also support this generic process where conceptual and preliminary design develop requirements at progressively more detailed levels. These are followed by a detailed design phase that generates the individual components and parts, and an integration phase that assembles the entire product and validates that it meets the goals and requirements [Ulrich and Eppinger, 1995; Rechtin and Maier, 1997]. As the product moves through the development cycle the assumptions made change. For the conceptual design phase, the details of the performance of a subsystem are assumed from historical values and changed based upon new design concepts put forth for a particular concept. Technology that could be inserted into the new product is then assumed. Based upon the historical and new technology parameters assumed, the performance of the system is developed. After many iteration cycles, each which develops a different conceptual product, one may select several of the concepts to complete the development of the highly integrative parameters (or one 107 may chose to determine them for each concept depending upon the costs to determine these highly integrative parameters). Again see Figure 20 for representation of this in a schematic DSM. For conceptual design, performance heuristics and parametric design validate the product. At this point the product is a design that represents the entire product (although at a very sparse way). As the design moves into the preliminary design phase the system level performance analysis is completed in significantly more detail (e.g., from a parametric or heuristic based evaluation to a detailed simulation based evaluation). Following the detailed definition of necessary system level parameters, the technology and design concepts are validated. This validation often occurs through independent subsystem testing. There may be several (but not usually too many) iteration cycles between the detailed system level performance parameters and the subsystem validation. At the completion of the preliminary design phase the system level performance parameters are often then defined as the system level (and possibly subsystem level) requirements. During preliminary design, validation of the system occurs through the system level performance simulation. See Figure 22 for the schematic DSM for preliminary design. At this point the product is a complete (although virtual) product. The requirements are then passed through to the subsystems for the detailed design phase. The detailed design phase assumes the system level requirements from the preliminary design phase and the subsystem development occurs relatively independently. While there may be some iteration between subsystems, it is rare that the iteration cycle extends up into the system level performance parameters. From this discussion, it is obvious that selection of system level 108 parameters is very important. The desire to keep options and design space as open as possible suggests that the options that can be kept open the longest are interactions and interdependencies that are within the subsystem or between a limited number of subsystems and do not alter the overall system in a major way. For example, the size and external interface of a power generator may be somewhat flexible, however, the output voltage and maximum current may be constrained very tightly. The deep dive into the details of the design lead to the DSMs to be greatly expanded with each subsystem potentially having its own matrix. (Note that the matrices must be interlinked as there will be interactions between the subsystems, Figure 24 ). See Figure 26 for a schematic how DSM represents detailed design. In detailed design, the validation of the design is the actual production of the entire subsystem. Once the detailed designs are complete and the subsystems produced, the validation phase of product development must integrate and test the complete system. For validation, the assumptions (although very real physically) are the individual subsystems. The subsystems are assembled into a complete system and each of the system level performance parameters are measured. These measurements are then compared to the requirements developed in the preliminary and detailed design phases to assess whether the product meets the necessary goals of the program. Following measurement of the system level parameters the highly integrative (usually customer driven) parameters that cannot be measured are calculated. The DSM shown in Figure 28 can represent this phase. For each stage of product development, the output of the stage resulted in being the assumptions and/or requirements for the following stage. Thus, the aerothermal parameters of 109 conceptual design are the assumptions in preliminary design. The validated system-level parameters of preliminary design become the requirements of detailed design. The physical hardware of detailed design becomes the required pieces for assembly of the prototypes in validation. Within P&W, this passage of bulk information from one stage of product development to another is always accompanies by a management Design Review. In this case single events conclude one stage and start another. Spiral vs. Waterfall Frameworks for Product Development Product development of complex systems has traditionally been represented by a "waterfall" type of process where a serial set of stages occur to bring a product to market (Figure 2) [Rechtin and Maier, 1997]. In general, the PDP can be broken down into conceptual design, preliminary design, detailed design, and validation (see Figure 1). Within the last several years, a new framework has been developed within the software industry that instead of a waterfall development process, the software industry uses a "spiral" (Figure 3). The spiral framework is one that the product development process involves moving through the a series of tasks. The original spiral moved through four phases (Determine objectives, alternatives, and constraints; Evaluate alternatives, identify, resolve risks; Develop, verify next-level product; Plan next phases) [Boehm, 1988; McConnell, 1996]. Each cycle through the process results in a product with more functionality. Since then several slightly differing sets of phases have been suggested (Function, Form, Build, Certify) and (Requirements, Design, Build, Integrate/Test) as well as several others [Rechtin and Maier, 1997]. The current work addresses both types of phases, but uses the following set of phases (Requirements, Initial Design, Define Product, Integrate/Test) as a hybrid. The risk management and planning phases in the original work are discussed as 110 appropriate to the phases. The following discussion argues that the PDP of P&W (and as a typical PDP, many complex physical system PDPs) is better represented by the spiral framework than the waterfall framework. Since many practitioners understand the waterfall framework and consider most hardware processes to be a waterfall framework, the following discussion focuses on how the PDP of P&W fits into the spiral framework. Examination of the Conceptual Design Stage in hardware development shows that first many requirements are developed from the supersystem, historical designs, and new technologies and design concepts. The team then determines a set of initial system level parameters and identifies the risks involved in a particular concept. If the concept is deemed acceptable, the designer refines the parameters and defines the product (although still at a very high level). The details are often the result of heuristics and parametric calculations. The designers then integrate and test their conceptual design through simple system-level simulations and comparison to previous designs. At this point the product has made its first complete loop around the spiral (Figure 31). The stages of the spiral can also be represented as part of the DSM (Figure 32). The program plan is then updated and a review with senior management held. At the end of Conceptual Design, the product is a high level virtual prototype. ill Requirements Initial Design Supersystem, history, Estimation of new technology, and design concepts system-parameters ~l- 1 KL) Comparison of system to goals and requirements Heuristics and simulation of system Integration and Test Define Product Figure 31: Spiral representation of the conceptual design stage. Determination Supersystem Requirements Hi apability and New Design Concepts New Technology -k 4.' IterativeDi0eilneuiation of Product Determination of Highly Integrative Parameters < "I00 Figure 32: Schematic conceptual design DSM with labels for spiral development. 112 The Preliminary Design Stage accepts the requirementsdeveloped in the Conceptual Design Stage and proceeds the initial design of the auxiliary systems and estimation of the additional detail for current subsystems. A system-level simulation is often developed. This simulation is exercised to increase the level ofproduct definition. This is followed by the integrationand testing of the new technology and design concepts in individual subsystems. Several loops around the phases may occur during preliminary design, especially if one or more of the technologies or design concepts are not validated as meeting the assumptions. See Figure 33 for representation of the spiral Preliminary Design Stage. The spiral can also be represented in the schematic DSM (Figure 34). At the end of Preliminary Design, the product is a fairly complete virtual, system-level design and set of requirements. A detailed risk management activity is completed during Preliminary Design. Completion of the Preliminary Design Stage occurs by updating the program plan and holding a senior management review. Requirements Assumptions from Concept Design Stage Initial Design Addition of auxiliary subsystems and development of detailed simulation Validation of new technology and design concepts at module level Iteration and refinement of system parameters Integration Define and Test Product Figure 33: Spiral representation of the preliminary design stage. 113 . Determination of Coceptual Design, Supersystem Requirements, and Program Goals Requirements Detailed - S ion Product Subsystem Validation of New Technology and Design Concep- Document Integrative Parameters and System Level Parameters Figure 34: Schematic preliminary design DSM with labels for spiral development. Separation of Detailed Design Stage into phases proceeds along similar arguments. Each module accepts the system-level requirementsdeveloped during Preliminary Design and then establishes module and component-level requirements. The team develops an initial design based upon the requirements and historical designs and then proceeds to define the product (components) to is highest level of fidelity. At this point a detailed 3-D model or print is completed. Testing of the design occurs as the part is manufactured into a physical entity. For detailed design each subsystem makes its own path through the spiral. At the end of detailed design the product exists in its entirety (often in both the physical world and as a fully developed 3-D solid model in the virtual world). Figure 35 represents the spiral of the Detail Design Stage. Representation in the form of a DSM of the spiral during detail design is given in Figure 36. Risk identification and mitigation occurs within each module on an ongoing basis. Detail Design 114 Subsystem Subsystem Subsystem Subsystem 1 2 3 4 Initial Design Requ Irements Prelimin ary Design First pass from historical designs Manufacturing of components Detailed definition and print development evel from System- Integration and Test Define Product Figure 35: Spiral representation of the detail design stage. Determination of System Requirements Ig - wPPA 7ule DnDefine Product--Pr P rototy~ f --- t -P- -- - ;C ule - - / -Product - - - emlreents Define - r e0ue Jr - ----------------- ~~?r4. ~ Prot~W~e entsS -- CDefine Product P 9tpfe/Test Requirements ReqwpflP ts I Product_ PW90OW9eTest - -- d&6WWt ModJ$WP4(fiMits- Define ~~~~~~ -~- - - ~- -- - ~ ~ - - -- ~-- - ---------- - -NI Product ProtctVyf fel1 Figure 36: Schematic detail design DSM with labels for spiral development. 115 A, ends during the Validation Stage and is completed with final input for the module into the program plan and holding a management review. Finally, the Validation Stage of product development receives is requirements from the FAA and JAA as well in the form of the physical hardware delivered from each module. The initialdesign (actually the assembly methods for the first physical prototype) is completed prior to the first prototype going to test. The product then proceeds through a set of detailed tests that fully define the performance and operation of the prototype. Integrationand test occurs when the measured values are compared to the requirements and goals for the product to either validate the product or initiate and additional iteration cycle to mitigate the risk of releasing a substandard product. This completes the last cycle of the spiral development process. See Figure 37 for the representation of Validation in the spiral framework. Figure 38 is a schematic representation of spiral validation in a DSM. As the Validation Stage is ending, the program develops a plan for field support of the product. This spiral actually continues through field support and retirement, but that is beyond the scope of the current work. The complete spiral representation of the waterfall product development cycle is shown in Figure 39. Note that in this schematic, 4 cycles around the spiral are complete. This need not necessarily be the case as any of the phases may proceed around the spiral more than once, or two or more stages may be combined. (The combination of stages occurs most frequently with the conceptual and preliminary design phases at P&W, especially for derivative designs). 116 Initial Requirements Design FAA and JAA regulations and component hardware Assembly of prototype product ro* Comparison to Goals and Requirements Measurement of parameters Define Product Integration and Test Figure 37: Spiral representation of the validation stage. equiretsand Components into System De ine easurement of sure t ) "Testing anic - 4.ot PANd Determination of Highly Integrative Parameters Validation of System Requirements 'Or Figure 38: Schematic validation DSM with labels for spiral development. 117 Requirements ---- Concept Design Preliminary Design Detail Design Validation Initial Design rrr. Integration and Test Define Product Figure 39: Schematic spiral for a waterfall product development process. As the above discussion shows, the P&W PDP is very well characterized by the spiral framework of product development. Although it may also be viewed as a waterfall process, the current practices using continuous risk management, repeated program planning, and the repeated progression through increasingly detailed phases all support the P&W PDP being more of a spiral development process than a pure waterfall. In addition, the hierarchical method of setting requirements to maintain flexibility in the design for as long as possible (even into Validation) suggests more of the spiral framework. As this work has previously noted, the generic nature of the P&W PDP leads the author to generalize the conclusion and stage that in general complex physical products are developed using a spiral PDP rather than a waterfall PDP. While physical products were originally developed by the waterfall framework, practitioners have learned the weaknesses of the waterfall through mistakes and other problems. As such, they have adapted the waterfall process into the spiral process without changing the label. 118 Spiral Development and Derivative Products. A separate discussion seems necessary concerning one author-perceived weakness in the above discussion. For many software products, the developer may actually put the product on the market after one of the first loops around the product development cycle. Subsequent loops around the cycle add functionality and are released as upgrades or new versions. It is difficult to imagine that a virtual engine could be sold to anyone; however, if one examines the platform strategies within the hardware companies, the hardware product development cycle again fits the spiral. In this case, the first spiral is the development of the platform and each subsequent loop is the development of a derivative product. In general, the author believes that for the development of complex physical products the difference between the spiral PDP and the waterfall PDP is only one of perspective. In practice, the separation of waterfall and spiral product development processes is not meaningful. However as is usually the case, having multiple perspectives on a process is useful and can be insightful as it allows one to see improvement opportunities that could not be viewed from the other perspective. Thus, discussion and work on both frameworks is worthy of future work. 119 CHAPTER 6: CONCLUSIONS AND FUTURE WORK Conclusions This work focused on the assumptions and requirements that are made during product development. The work focused on the management of a complex product from the system level and used a higher level perspective than previous work. The DSM was the main tool used throughout this work. There are two main conclusions from this work: 1) A single, system-level parameter DSM may be used to represent three stages of product development (concept design, preliminary design, and validation). The only difference in the DSMs for each stage is the assumptions (i.e., what is assumed and in what order are the assumptions made). 2) PDPs for complex physical products are well represented by the spiral framework of a PDP. The authors viewpoint is that in practice there is little or no difference in the application of these frameworks to a product development cycle. In addition, several recommendations for Pratt & Whitney were given: 1) Include all requirements (including risk management) for a product in a single document (do not include processes) 2) Update requirements at specified occasions 3) Reorganize the system engineering organizations and insert a single chief engineer for a product. 4) Move the secondary flow organization into PSA from SD&CI 5) DSM is not as important at P&W due to the detailed system simulation capability 6) DSM would be a good training tool for new hires to assist in the understanding of the interdependencies present in a gas turbine. The issue of perspective was discussed many times in this thesis with the conclusion that many seeming conflicts are only differences in perspective. The experience and knowledge of individuals is limited and therefore, when approaching a problem or issue, each person brings a unique perspective. Open discussion of various perspectives can prove to be insightful as one 120 attempts to change perspectives to view a problem or issue from a different angle. Often the most insightful conclusions come from these discussions. The author hopes that the discussions of perspective included in this thesis operate along these lines. Future Work Many directions may be taken from this work. Several specific opportunities are discussed within the text. The items outlined here are more general paths for potential future work. 1) Extend the work on spiral and waterfall development to determine if the framework outlined here is applicable to other industries. The current work generalizes and makes conclusions based upon the author's research and experience within a single industry. While it was hypothesized that the conclusions made are applicable across industries, work across several additional industries with physical products would prove useful either to reinforce the conclusions made here or to show their limited applicability. 2) Examine the detailed ordering of the parameters output by PSM32. When assumptions are made concerning very integrative parameters (e.g., one of the module designs), the program may recommend that a parameter be completed very early after assumption of the integrative parameter. In practice, these parameters are rarely completed that early. This may be due high level portions of the integrative parameter are what is assumed, but the parameters actually depend upon some portion of integrative parameter that is not necessarily assumed. This may lead to one saying that the integrative parameters should be divided into many smaller parameters. While this may be the most rigorous and scientific method, it quickly makes a DSM unwieldy. Thus, exploration of how to better represent the relationships may be useful. 3) Benchmarking of system engineering organizations and their relationship to the management of product development. The balance of power within product development organizations is becoming more and more important as companies are pushed to ever improve the product development process. System engineers should play a large role within P&W. Is this an appropriate approach and how do other companies utilize there system engineers? 4) Although not as general, develop detailed DSMs for each module in a gas turbine. With the addition of these DSMs, a hierarchical ordering of DSMs that would be a complete representation of a gas turbine would be available. 121 5) Finally, utilize the system-level DSM developed in this work to generate a generic risk management process. This would extend the specific process developed by Tyson Browning [Browning, 1998] to a general case. Care would need to be taken to make the process user friendly and quick to accomplish. 122 REFERENCES & Anonymous, 2000. "Operating Guidelines for Integrated Program Deployment at Pratt Whitney." Pratt & Whitney. November 2000. Bartkowski, G., 2001. "Accounting for System Level Interactions in Knowledge Management Initiatives." Massachusetts Institute of Technology Master's Thesis. 2001. Boehm, B.W., 1988. "A Spiral Model of Software Development and Enhancement." Computer, May 1988, pp. 61-72. Browning, T.R., 1998. "Modeling and Analyzing Cost, Schedule and Performance in Complex System Product Development." Massachusetts Institute of Technology Ph.D. Thesis. 1998. Cronemyr, P., Ohrwall-Rinnback, A., and Eppinger, S.D., 1999. "A Decision Support Tool for Predicting Impact of Development Process Improvements." Journal of Engineering Design. Forthcoming 2001. Dornheim, M.A., 2000. "NASA Says MPL Was Too Cheap, Too Fast." Aviation Week & Space Technology, pp. 40, April 3, 2000. Eppinger, S.D., Whitney, D.E., Smith, R.P., and Gebala, D.A., 1994. "A Model-Based Method for Organizing Tasks in Product Development." Research in EngineeringDesign, Vol. 6, No. 1, pp. 1-13. Epstein, A.H., 2000. MIT lecture notes in 16.511 Gas Turbine Engines. Fall 2000. Fernandez, C.I.G., 1998. "Integration of Product Architecture to Support Effective Team CoLocation." Massachusetts Institute of Technology Master's Thesis. 1998. Glynn, S.V. and Pelland, T., 2000. "Information Flow & Knowledge Capture Lessons for Distributed Integrated Product Teams." Massachusetts Institute of Technology Master's Thesis. 2000. Huovila, P., Leinonen, J., and Truch, P., 2000. "Intimate Relations Between Theory and Practice Linking DSM with Construction Project Management Tools." Second MIT DSM International Workshop, Cambridge, MA, September, 2000. Kerrebrock, J.L., 1992. "AircraftEngines and Gas Turbines, 2 nd Ed." MIT Press, Cambridge, MA. 123 Mascoli, G.J., 1999. "A Systems Engineering Approach to Aero Engine Development in a Highly Distributed Engineering and Manufacturing Environment." Massachusetts Institute of Technology Master's Thesis. 1999. McConnell, S., 1996. "Rapid Development-Taming Wild Software Schedules," pp. 13 3-161. Microsoft Press, Redmond, WA. McCord, K.R. and Eppinger, S.D., 1993. "Managing the Integration Problem in Concurrent Engineering." Sloan School of Management Working PaperNumber 3594. Massachusetts Institute of Technology. MIT DSM, 2000. http://web.mit.edu/dsm Moy, H.M., 2000. "Commercial Gas Turbine Engine Platform Strategy and Design." Massachusetts Institute of Technology Master's Thesis. 2000. Pimmler, T.U. and Eppinger, S.D., 1994. "Integration Analysis of Product Decompositions." ASME Conference on Design Theory and Methodology. Minneapolis, MN. September 1994. DE-Vol. 68, pp. 343-35 1. PSM32, 2000. http://www.problematics.com Rechtin, E. and Maier, M.W., 1997. "The Art of Systems Architecting." CRC Press. New York. Rowles, C.M. 1999. "System Integration Analysis of a Large Commercial Aircraft Engine." Massachusetts Institute of Technology Master's Thesis. 1999. Smith, G.E. and Mindell, 2000. "Emergence of the Turbofan Engine." Pp. 107-155 in Galison, P. and Roland, A. eds. Atmospheric Flight in the Twentieth Century. Kluwer Academic Publishers. Smith, R.P. and Eppinger, S.D., 1997. "Identifying Controlling Features of Engineering Design Iteration." Management Science, Vol. 43, No. 3, pp. 276-293. March 1997. Sosa, M., Eppinger, S., and Rowles, C., 2000. "The Effects of Product Architecture on Technical Communication in Product Development." Sloan School ofManagement Working Paper,July 2000 Massachusetts Institute of Technology. Stowe, M., 2000. "Identifying & Integrating Project Information for Increased Throughput." Second MIT DSM International Workshop, Cambridge, MA, September, 2000. And personal communication, 2000. Thebeau, R.E., 2001. "Knowledge Management of System Interfaces and Interactions for Product Development Process. Massachusetts Institute of Technology Master's Thesis, 2001. 124 Ulrich, K.T. and Eppinger, S.D., 2000. ProductDesign and Development. Hill, Inc. 2nd Ed. McGraw Whitney, D.E. 2000. Private communication. Whitney, D.E., Dong, Q., Judson, J., and Mascoli, G., 1999. "Introducing Knowledge-Based Engineering into an Interconnected Product Development Process." Proceedingsof the 1999 ASME Design EngineeringTechnical Conferences, Las Vegas, NV. pp. 1-10. September, 1999. Womak, J.P. and Jones, D.T., 1996. "Lean Thinking: Banish Waste and Create Wealth in Your Corporation." Simon & Schuster, New York. Zeidner, L. and Wood, R., 2000. "The Collaborative Innovation (CI) Process." Transactions from the 1 2 'h Symposium on Quality Function Deployment, pp. 375-385. QFD Institute. 125