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