Driving Robust Jet Engine Design through Metrics
By
Steve P. Sides
P.E. State of Florida, No. 50098
Masters in Engineering (1991)
Florida Atlantic University
B.S., Mechanical Engineering (1986)
Mississippi State University
Submitted to the Systems Design and Management Program in Partial Fulfillment of the
Requirements for the Degree of Master of Science in Engineering and Management
At the
Massachusetts Institute of Technology
February 2000
D 2000 Steve P. Sides, All rights reserved
The author hereby grants to MIT permission to reproduce and to distribute publicly and electronic copies
of this document in whole or in part.
1-7/
C-
Signature of Author
Systems Desi
gram
'Y999
Certified by
rey
Department of Aeronautics and Astro tics
Thesis Supervisor
Accepted byThomas A. Kochan
LFM / SDM Co-Director
orge
Bunker Professopjf Management
Accepted bi
6/Paul A. Lagace
LFM / SDM Co-Director
Professor of Aeronautics and Astronautics and Engineering Systems
MASSACHUSETTS 19S TITUTE
OF TECHNOLOGY
L OCA
JAN 2 OWm
LIBRARIES
EO
I
Driving Robust Jet Engine Design through Metrics
By
Steve P. Sides
Submitted to the Systems Design and Management Program on 15 December 1999 in partial
fulfillment of the requirements for the Degree of Master of Science in Engineering and
Management
ABSTRACT
This thesis proposes a methodology and defines specific program level robust system design metrics
(RSDM's) applicable at a jet engine program level. The metric applies from part, to subsystem to system
(program) level. Roll up of the metric results across subsystems to the system level is explained. The
results of the metric were found to agree very well with the results from a traditional Monte Carlo
analysis of a specific case analysis. The RSDM predicted that 99.97% of the time requirements would
be met where the Monte Carlo analysis predicted 99.98% conformance to requirements.
The metric's format is dimensionless; however, it provides insight and its results are absolute. In other
words, if the RSDM Key Response = 1 we have a three sigma capable system of producing the desired Key
Response within a specified tolerance width. For a RSDM Key Response -0.5 we have a six sigma capable
system of producing the desired Key Response.
The format of the metric is simple although the roll up from subsystems is non-trivial. This metric and
approach provide for a top down flow of requirements with a feedback of the capability to achieve the
stated requirement.
The four value streams, (1) the product's users and or buyers (a.k.a. customers), (2) the manufacturer's
shareholders, (3) the employees of the company and (4) the community in which the company operates,
were employed in a stakeholder assessment. This approach identified five key attributes for application
of the metric: (1) Affordability, (2) Dependability, (3) Thrust response, (4) Cost and (5) Engine weight.
P-diagrams are presented for a case study and an observation about P-diagrams is that they provide an
easy graphical means (typically on one page) to capture the main drivers affecting a system which should
be considered in the design parameter selection process.
It is recommended that the proposed robust system design metric (RSDM) and roll up method be
employed throughout all phases of a program and that P-diagrams be incorporated into standard work to
help instill robust design practices.
Thesis Supervisor: Daniel D. Frey
Title: Assistant Professor of Aeronautics and Astronautics
2
Table of Contents
Motivation -------------------------------------------------
4
Introduction -----------------------------------------------------Proposed Metric Features --------------------------------------------Proposed Metric Format ----------------------------------------------
8
12
13
Roll-Up Model ----------------------------------------------------
18
FVV Positioning Model vs. Monte Carlo Analysis -------------------------Stakeholder Assessment- Identification of Key Jet Engine Responses ------------------------------------------------------Jet Engine Key Responses
P-Diagrams as Part of Robust Design Culture --------------------------------------------------------------------Conclusion and Recommendation
------------------------------------------------------References
Appendix: MathCad ProfessionalTM model of a Jet Engine Fan Variable Vane
Actuation System for the purpose of demonstrating the RSDM methodology.
23
27
32
36
44
46
47
FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
--------------------------1. Simplified Model of the Re-work Cycle.
2. Schematic of a Typical Technical Performance Measure ---------------3. Schematic of a Robust Design Metric Technical Performance Measure -4. Graphical Depiction of the Capability Index ------------------------5. Schematic of Robust System Design Metric Decomposition for TSFC -6. A RSDM Decomposition of FVV Positioning -----------------------7. Monte Carlo Results from MathcadTM Model -----------------------------------------------------8. A Product Development Framework
-----------------------------9. Decomposition of the Key Responses
-------------------------------------10. Schematic of P-diagram
11. Fan Variable Vane (FVV) Actuation System Schematic --------------------------------------12. Poor Response from FVV Actuation System
13. P-diagram for FVV Actuation System Not Considering Noises ----------14. P-diagram for FVV Actuation System With Noises -------------------
Figure 1A. FVV Scheduling Schematic
Figure 2A.
Figure 3A.
Figure 4A.
Figure 5A.
Figure 6A.
Figure 7A.
-----------------------------------
Corrected FVV Rotor Speed vs. FVV Request -------------------Corrected FVV Rotor Speed vs. Actuation System Load ------------------------------------------FVV Actuator Stroke vs. FVV Angle
------------------------FVV Actuator System Stiffness Schematic
------------------------------------Effector Loop Schematic
Monte Carlo Results for FVV Positioning Capability ------------------
TABLES
Table 1. Rework Model Results for Varying Quality, Productivity & Discovery Delay
Table 2. Meaning Of RSDM ------------------------------------------Table 3. Sample Life Cycle Cost (LCC) Table for Concept or Option Selection ----------------------------------------Table 1A. Meaning of RSDM
5
9
10
15
18
23
24
29
31
36
38
38
39
40
47
49
50
52
52
53
55
6
17
42
58
3
Motivation
The motivation of this thesis comes from my work experience as an engineer in the jet
engine industry. I made a career (or at least 14 years of assignments) by being called in to solve
system or subsystem problems that were too often the result of not considering component
interface uncertainties (also known as variances or noises). After completing a robust systems
design course at MIT, I realized that the classical robust design tools existed in industry to design
and produce robust products. However, a management tool that evoked these tools and culture
seemed to be missing. Too often I've seen robust design practice give way to schedule and cost
pressures in a program. The intent of this thesis is to bring awareness of a cause of a re-work
cycle that may result from such schedule and cost pressures and how a robust design culture
might minimize this rework cycle.
The clich6 that "you are what you measure" is recognized as
being powerful and thus the need for a metric that allows the indication of the products
robustness up front in the product development phase when concepts are being selected and the
details of the architecture are being solidified.
The Re-work Cycle and The Need for Robust Design Cultures.
I gained an awareness of the rework cycle from course work in the MIT SDM program.
This awareness helped me appreciate the value and need of a robust design. To share this
appreciation, analysis results from the re-work cycle will be reviewed. Here, quality is used in
the analysis to loosely represent robust design quality. Clearly poor quality work (errors) can
cause re-work, but the lack of a robust design leads to product failure. The analogy being used
in the following analysis is poor quality of work done is indicative of insufficient use of robust
design practices.
Often, a lot of work is done but then we turn around and find there is more work to do
than originally planned. We justify this by saying we learned more or are smarter from a test or
4
now better understand the product usage. These are valid arguments; however, one might
question are they signs of poor up-front robust design practices. Let's examine the rework cycle
and the influence of quality on the amount of work done. Figure 1 provides a simplified
Vensim T model of the rework cycle.
Productivity
Staff LeveF
Potential Work Rate
Work Accomplishmen
HJ>
Quality-)<IM
Work ToDo .a .UndiscovWerrDen
Rewrk Generation
Work ToDo
ReworkLWokDn
<TIMEL STEP1>
/
Project Finished
Rework Discovery
Time To Discover Rework
Rate Of Doing Work
Cumulative
Work Done
<Work Accompfishmnent>
Figure 1. Simplified Model of the Re-work Cycle (from [Lyneis])
The items in boxes are stocks where the hourglass icons are rates or flows. All other
items are auxiliary items in the model. A stock can be thought of as a bucket in which we are
trying to collect water. The level of water in the bucket at any given time is affected by the flows
5
into and out of the bucket. In the above model, the stocks are Work To Do, Undiscovered
Rework, Work Done and Cumulative Work Done. The flows are Rework Discovery, Rework
Generation, Work Accomplishment and Rate of Doing Work. This is a simplified model in that
the effect of schedule pressures, employee moral, employee experience level and their
interactions that affect the re-work cycle are not modeled. The goal here is to provide insight to
the impact of quality of work done on the amount of work actually done.
The Vensim
model of the re-work cycle given in Figure 1 was used to investigate the
impact of productivity, work quality, and rework discovery time on completion date and total
work done. Seven model runs were conducted in which productivity, work quality and rework
discovery time were varied. The results of the simulation runs are provided in the following
Table 1.
Base
Model
Run #
1
2
Staff
Productivity
Quality
Discovery
Delay
(people)
(Tasks/
month/person)
(Tasks/
Tasks)
(months)
Cum.
Work
done
(Tasks)
100
100
4
4
1
1.5
0.75
0.75
4
4
132
132
Target
Estimated
Completion Work To
Do
Date
(month after (Tasks)
start)
40
31
3
70
100
4
0.5
0.75
4
132
4
5
6
7
25
63
35
46
100
100
100
100
4
4
4
4
1
1
1
1
1
0.5
0.75
0.75
4
4
2
6
100
198
132
132
Table 1. Rework Model Results for Varying Quality, Productivity and Discovery Delay
In Table 1, estimated completion date is the date in which the project is predicted to be
completed per the model run given the number of task to do, a staff level with specified
productivity and quality of work. The numbers of task and staff level values were held constant
at 100 tasks and 4 people respectively. In run number 4 we see that if productivity was 100%
6
and every task that a staff member did was perfect (100% quality), then it would take 25 months
for the 4 people to complete the 100 tasks and the cum work done would be a 100 tasks.
Runs 1,2 and 3 examine the effect of productivity with quality held constant at 0.75. This
means that 75 %of the work done was actually correct. With perfect productivity and 75%
quality it will take 40 months to complete the project and in actuality 132 tasks will be done at
completion. None of this was from being smarter or learning more from the product. It was
simply the impact of quality that lengthened the project and caused more work to be done. Runs
2 and 3 show that as we improve or degrade productivity we simply decrease or increase
respectively the time required to complete the project. Productivity did not change the amount of
work to be done in this simple, but insightful model.
Run 5 shows that if the quality of work done is 50% then the total work done to complete
the project is nearly doubled (198 tasks). This increased work has an adverse effect on project
completion time (increased from 25 months to 63 months). Comparing runs 1,6 and 7, indicates
that re-work discovery time primarily affects project duration.
Per the analysis, quality of work performed has a significant impact on the amount of
work that ends up being done to complete the project. Productivity and discovery delay of
rework tend to affect the duration of the project. The message here is that to finish as planned we
must produce quality work or expect significant delays in project completion due to rework. My
experience has been that we are surprised from product failures late in the development process
when staff level and funding are decreasing. After gaining this view of the re-work cycle, I felt
that poor robust design practices and cost and schedule pressures were overriding the growth of
robust design cultures. This lead me to believe that program level robust design metrics are
needed and that simple means to capture and communicate the noise consideration for a
particular design are needed.
7
Introduction
As they should, managers of jet engine development programs tend to monitor program
cost, schedule performance and Technical Performance Measures (TPM's). Typical TPM's are
weight, production cost, operability (stall margin), Thrust Specific Fuel Consumption (TSFC),
performance retention (Delta TSFC with wear out) and projected field reliability (failures per
1000 flight hours). These metrics tend to be end item characteristics and except for performance
retention and reliability do not drive product robustness. These types of end item TPM's are
important and needed; however, I submit that in addition to these metrics, TPM's that indicate
product robustness are needed to drive robustness into the design phase of a program.
When a program's cost or schedule performance exceed some predefined amount from
plan, corrective action must be defined and implemented to bring the program performance and
plan in agreement. A TPM metric usually provides both an indication of Achievement To Date
(ATD) and the Current Estimate (CE) of the TPM at service release. The ATD gives confidence
in the CE. As the CE diverges from goal, corrective action is identified and implemented to
drive the CE and goal level in agreement. These corrective actions are usually design
modifications. However, the action might be to negotiate a change in the product's requirements
to match expected performance when design modifications are not feasible within the program's
constraints.
A TPM is schematically depicted below in Figure 2. From this figure we see that at time
"I", the ATD was not on plan and the corresponding CE did not meet requirements. This metric
would indicate to management that corrective action beyond the original plan was needed.
Efforts would then be initiated to identify and implement corrective action. At point "II" in the
program monitoring, the corrective action had been implemented and the ATD reflected this
improvement. The corresponding CE was projected to then meet requirements and the program
would proceed with its plan. A metric such as this drives the program's actions, resources and
8
attention particularly in the development and verification phase of a program. Thus, if a
company desires robustness of their products, a metric should exist that indicates the robustness
of the product being designed prior to being produced.
ATD Before
Corrective Action
0
ATD After Corrective
Actio n Implemented
*g
l
CE Before Corrective
Action Implemented
E
/(
Plan Line
/
CE After Corrective
Action Implemented
Max acceptable
I
I
I
II
Time or Program Milestone
Figure 2. Schematic of a Typical Technical Performance Measure
To date, typical TPM's have driven programs to focus on the end product characteristics
and do not necessarily result in a robust design. Having a robust design from the components to
the subsystems to the engine system level will result in a design that is more tolerant to usage
variations thus providing improved customer satisfaction. A robust system design metric
(RSDM) of a particular Key Response might look like that given in Figure 3.
9
1.5 -t
0
1.0
Plan Line
o
0.5
Max acceptable
SI
I
II
I
III
IV
Time or Program Milestone
Figure 3. Schematic of a Robust Design Metric Technical Performance Measure
Typically, nominal design solutions are defined both initially and in the corrective action
phase. Later during verification testing or in the operational environments, the discovery that the
nominal design was not robust drives another design modification. This is the rework cycle and
is significantly driven by insufficient engineering and manufacturing practices that result in nonrobust designs. Given more robust initial designs and avoiding inevitable design modifications,
the rework cycle will be lessened, development surprises minimized and a robust product fielded.
Fewer reworks are obviously less costly and a robust product in the field minimizes problems
and gains customer loyalty. The challenge is to drive robust design processes into the product
development process at the start of the design phase. Providing designers and program
management with robust design training will help, but this in itself may not change the culture.
As with the clich6 "if you don't use it you lose it", it takes commitment from the entire
organization (shared vision) to drive robust design philosophy. Thus, we need metrics and best
practices to drive a robust design culture. To do this it is proposed that program level TPM's that
10
indicate product robustness be identified. Also, design solution documentation should capture
(perhaps in P-diagrams and words) how variability rejection has been achieved or considered.
This is not to say that a Taguchi design of experiments needs to be conducted at every level but
that noises or variances in interface conditions (loads, temperatures, manufacturing tolerances,
etc.) are considered in the design solution. To what level (judgement, experience, test or
analysis) this occurs is believed to be situational and not covered in this thesis. However, Pdiagrams offer a graphical means to capture the factors involved and typically can summarize a
system on one page.
Robust systems are built from robust sub-systems and metrics that capture this from the
bottom level to the top level are needed. If the metric is too complex for managers or nonTaguchi engineers to grasp and see its use, it will not succeed as a useful tool. Again, the
challenge of this thesis is to identify specific metrics and methodology that meet this need.
11
Proposed Metric Features
The desired characteristics of the metric are:
" Simple-- technically grounded program managers must be able to understand and use the
metric without having to take a robust design course or be a Taguchi design of experiments
expert. The idea of understanding sensitivity and expected variance of a main driver or noise
factor is however expected.
" Has clear meaning-- the metric must have clear meaning or at least its decomposition must
have meaning. Simply a dB representation of signal to noise ratio might not give needed
insight. For a given system, optimizing signal to noise ratios is significant and must
continue. However, when managing a program, dB from one system to another has different
meanings or importance depending on the units used in the system at hand. Thus, the metric
should have meaning from one system to another and the manager should not have to
recalibrate his or her scale of measure. The metric must have a tie to economic impact
(design and development cost, reliability, warranty cost, and customer value).
*
Independent of units--The metric should be absolute. That is the value of the metric is
independent of the units used in the roll up of influences.
" Applicable at all levels of the system-" Applicable at the system or program level such that program managers gain insight to the
products robustness features.
*
Applicable at the subsystem level such that managers of subsystems may use the same
methodology in the design decision process of subsystems.
" Applicable at the component level, especially for augmenting the Life Cycle Cost (LCC)
decision process discussed in this paper.
" Can be rolled up-- Ability to roll up results from component to subsystem to system without
generating rework or requiring re-formatting of various metrics. Though the meaning must
be clear and the metric simple, the roll up may be non-trivial.
12
Proposed Metric Format
The general form of the proposed robust systems design metric (RSDM) that meets the
desired features is given below in equation (1).
Proposed RSDM form:
a(Key Response)
c (Noise factor) i
*
6
(1)
a(noise factor)i
Allowable Tolerance
Key Response
This format comes from work [Frey] conducted in his precision machine design doctoral
work. This dimensionless format provides insight and is simple and appears to meet the
characteristics of the sought after metric. The Key Response is the feature of interest such as that
of fuel consumption in a jet engine. The noise factors would be the various items that
significantly effect the Key Response. In our jet engine model this might be component
efficiencies, control accuracy, leakage and cooling airflow and so forth. The 6a
noise factor
is just
that, the six sigma expected variance of the noise factor. The allowable tolerance of the Key
Response is the maximum allowable variation in the Key Response that is allowable and the
product or process still meets requirements.
The first part of the metric, the partial derivative of the Key Response to a noise factor
represents the sensitivity of the Key Response to one of the noise factors. The six-sigma (6a noise
factor ) part of the equation captures the expected variation of the noise factor. Dividing by the
allowable tolerance of the Key Response results in a dimensionless parameter.
13
If we let SF.equal the significance factor then:
SF, = a(Key Response) / a(Noise factor) *(6Cnoise
factor)1
/ Allowable Tolerance
Key Response
SF 2 = (Key Response) / a(Noise factor) 2 *( 6 anoise factor)2 / Allowable Tolerance
Key Response
/ Allowable Tolerance
Key Response
SFn = a(Key Response) / a(Noise factor)n *( 6 Cnoise factor)n / Allowable Tolerance
Key Response
SF 3 = a(Key Response) / a(Noise factor) 3 *( 6Gnoise
factor)3
Then the robust system design metric (RSDM) of the Key Response can be expressed as
given in equation (2):
RSDM Key
Response=
{ (Ci*SFi) 2
+ (C 2 *SF 2) 2 + (C3 *SF 3) 2 + (C 4*SF 4 )2 +. .(Cn*SFn)
2
11/2 (2)
This form assumes that the noise factors are statistically independent and that the
response surface is linear. With time if it is found that noise factors have a strong correlation then
these factors should be added and then root summed squared with the other noise effects. For
noise factors that have interactions we would use the format of equation (3) where say factor one
and two have a strong correlation. The "C" values in the equation (2) and (3) represent the
inverse of the traditional capability index of the Key Response when considering only that noise
factor.
RSDM Key Response= { ((C 1 *SFI)+ (C 2*SF 2)) 2 + (C 3*SF 3) 2 + (C 4*SF 4) 2 +...(Cn*SFn)
2
112 (3)
Process capability indices are typically used to measure or indicate a system's ability to
manufacture a product within a given specification.
The process capability index (C,) is a
14
dimensionless ratio of the amount of variation that can be tolerated and the amount of variation
present. It is defined as given in equation 4.
U-L
CP6a
(4)
Where U and L are upper and lower specification limits on a random variable and a- is the
standard deviation of the random variable. Typically, the random variable represents a
toleranced dimension that is used in a product's acceptance criteria. In this case, the random
variable is the variations of the noise factor due to all influences be it manufacturing tolerances
or noises from the environment or uncertainties in interfaces driving variance in the noise factor.
For a C, = 1 we would have a three sigma capability of producing the desired results and
for a C, = 2.0 we would have a six sigma capability of producing the desired results.
[-Tolerance Width
U
L
j
3a
U-L
3a+3
3
U-L
6a
Figure 4. Graphical Depiction of the Capability Index
15
Thus, we could represent the RSDM in terms of Cp as given in equation (5). However, if
we let C1 oc l/Cpi oc RSDM
(Key Response)1
we maintain the RSDM terminology from component to
subsystem to system and have equation (6), which is the same as equation (2). This allows us to
talk in terms of the RSDM's from one subsystem's response to the next rather than talking in
terms of the inverse of the capability index (1/Cp) and then the RSDM of the key response.
RSDM Key Response = { (3/Cpl*SF1)
2
+
(3/Cp 2 *SF 2) 2
+
(3/Cp 3*SF 3) 2
+
(3/CP4*SF 4) 2
(5)
+...(3/Cpn*SFn )2 112
RSDMKey
Response
{ (Ci*SF1) 2 + (C 2 *SF 2 )2 + (C 3 *SF 3 )2 + (C4 *SF 4 )2 +...(Cn*SFn)
2
}1/2
(6)
By considering all the main noise factor effects we roll up the combined effect of these
factors and the result is a capability index of the Key Response considering all these noise
factors. Here we have denoted this rolled up capability index as RSDM Key Response. Note that the
RSDM is inversely proportional to the classical process capability index, Cp. Thus, if RSDM
Key Response-=
1 we have a three sigma capable system of producing the desired Key Response
within a specified tolerance width. For a RSDM Key Response= 0.5 we have a six sigma capable
system of producing the desired Key Response. For the format of equation (6) the challenge is
identifying the main noise factors to consider and their effects and how to roll up their effects
from level to level (component to subsystem to system).
16
RSDM
Number Exceeding
Tolerance Width
0.5
0.6
0.75
1.0
1.2
1.5
2.0
3.0
< 2 / 1,000,000,000
< 0.6 / 1,000,000
< 63 / 1,000,000
< 3/1,000
< 12/1,000
< 46/1,000
< 134/1,000
< 32/100
Process Capability
6a
5a
4a
3a
2.5a
2a
1.5a
la
Table 2. Meaning Of RSDM
From Table 2 we see that for a RSDM value of 3, we would have a one sigma capability
of meeting the specified tolerance width and should expect 32 out of 100 systems will not meet
the tolerance width requirement (Note: RSDM= 6a / (2*Cp*a) ). We desire the RSDM to be
small (smaller the better). Achieving a RSDM of 0.5 means one is at 6a or in other words less
than 2 in a billion times the system not meet the specified requirements.
17
Roll-Up Model
We will now consider the following model to discuss a method to roll up the noise factors
to the RSDM.
C1.11 .11
S
A/C Drag
C1111
Cuu
C1.1 .12.1
A/C Weight
C1.1 2.1.1
-- +A/C
--
-
Bleed
+
Engine
PowerCu
Setting
C1.12.
Airflow
C 1.1.22.1
Fan~Ca
Afo
-olinge&
Airflows
Engine Coo~ling
Arflow
C
u
C1.23
"
Leakage Airflow
Fn
Psietio
.1.
-->
C 1.13.
Fan Efficiency
Engine RSDMrsFC
TSFC
3
__Compressor Efficiency -----
CIA
-1.
Rotor Spe
.1.6
A
Combustor Efficiency --
HPT Efficiency
SD
C1.1.
CLLI4
-----
iClearance
C..5
LPT Efficiency
----
Aug. Efficiency
---
Engine
Efficiency
Nozzle Efficiency IC1.13.
Figure 5. Schematic of Robust System Design Metric Decomposition for TSFC.
If we now apply equation (6) to Figure 5, then the RSDM for TSFC can be expressed by equation
(7).
2
2
2
RSDMTSFC = ( (C1 1. .1 * SF 1 .1 .1) + (C1 .1 .2 * SFI. 1.2 ) + (C 1.1.3 * SF 1 .1.3 ) 1/2
(7)
18
where,
SFI.1 .1=
(8)
TW
power setting
a TSFC
TW
TSFC
a Power Setting
In equation (8), "TW" represents the tolerance width or the upper limit minus the lower
limit of the denoted parameter. In equation (7), "CI.I., " is the RSDM for the power setting and
represents the capability to achieve the power setting tolerance width (TW) requirements. If
"C1 .1 .1 " = 1 then we have a 3a capability of meeting the specified limits (TW). "C1.1.2 " is the
RSDM for meeting the Leakage and cooling airflow requirements and "C1 .1.3 " is the RSDM for
the engine efficiency.
Also,
TW
Leakage & cooling airflow
TW
TSFC
TW
Engine Efficiency
TW
TSFC
*
t TSFC
a Leakage
*
(9)
& cooling airflow
a TSFC
(10)
a Engine Efficiency
Again referring to Figure 5, we would determine the RSDM for engine efficiency to be as
follows.
RSDM
Engine Efficiency
=
1 .1 .3
= ((CI..
3.1 *
SFI.I. 3. 1) 2 + (C 1 .1.3 .2 * SFI.I. 3 .2 ) 2 + ...... +(C1.1.3.7
2
*
SFI.I. 3 .7 )
)1/2
19
where,
SF
SF
SF
1.1.3.1 =
1.1.3.2=
1.1.3.7=
a Engine Efficiency
TW
Fan Efficiency
*
TW
Engine Efficiency
a Fan Efficiency
TW
Comp. Efficiency
TW
Engine Efficiency
TW
Nozzle Efficiency
TW
Engine Efficiency
*
a Engine Efficiency
a Compressor Efficiency
*
a Engine Efficiency
a Nozzle Efficiency
The "CI1 .3 .1 ,C1 1.3.2 ,C 1.1.3.3 ,C 1.1 .3.4 ,C1.I.3. 5 ,C1 .1 .3.6 ,CI.1 .3.7 " are the RSDM's for the
Fan, Compressor, Combustor, High Pressure Turbine (HPT), Low Pressure Turbine (LPT),
Augmentor and Nozzle respectively and represent the capability to achieve their allocated
tolerance width (TW) requirements at a given condition. Note that Engine Efficiency could have
been drawn directly into the engine TSFC block in Figure 5. The figure was drawn in the manner
provided to show the roll up method. Thus, note that the decomposition of the Key Response
characteristic like most decomposition is not unique. This means the various components,
subsystem and system teams should define, document and ensure consistency amongst the
decomposition of the RSDM's.
The Robust System Design Metric (RSDM) for Fan efficiency is given as follows based
on the Figure 5 decomposition.
RSDM
Fan efficiency =
C 1.1.3 .1 = ((C 1 .1 .3 .1. 1 * SFI.I. 3 . 1. 1)2 + (C1 .1 .3 .1.2 * SF 1 .I. 3 .1. 2 ) 2 +
...... +(C1.1.3. 1 .6 * SF 1 .1 .3.1.6) 2 )1/2
20
A significant question to ask is "how robust is the Fan efficiency value that is being
counted upon?" The RSDM
Fan efficiency
answers this question. If RSDM Fan
efficiency =
0.5, then
we would expect a 6 a capability of meeting the desired Fan efficiency tolerance width. In other
words less than 2.0 times out of a billion would Fan efficiency exceed (go out side) the TW
allocated to the Fan.
Another observation of this method is that the TW can be assigned and held constant.
The capability to achieve the specified TW will vary depending on the design decisions selected
through the development process. The allocation to the subsystem or factors (in this case FVV
position, hardware tolerances, etc) can be set and not constantly changed. For example, if +/-2
(plus and minus two) degrees variability or accuracy is allocated to the FVV position, this
allocation can be held as a constant requirement through the development process. The ability to
achieve this requirement is represented in the RSDM for FVV position. Managers can then make
decisions that improve the capability (RSDM) to meet this requirement. This approach is a top
down flow of requirements with a feedback of the capability to achieve the stated requirement.
Let's assume that to meet TSFC requirement that a Fan efficiency requirement of 94 +/- 2
% at a given flight condition (power setting, altitude, Mach number) has been defined. This
results in a TW
Fan Eff.
4% (+/- 2 %). One might then allocate the following TW's on Fan
efficiency drivers:
TW
FVv
TW
Airfoil geometry
=
TWAiflow =
4 degrees
(+1- 2.0 degrees)
1 degree
(+/- 0.5 degree)
2%
(+1 %)
3 %
(+1- 1.5 %)
TW
Fan Press Ratio
TW
Rotor Speed =
500 rpm
(+/- 250 rpm)
TW
Tip Clearance =
4 mils
(+/- 2 mils)
=
21
Then (equation (11)),
RSDMFan
efficiency
{
C 1..
3 .1. 1
10
aFan Eff
*
2%
4%
C 1 .1 .3 .1.4
1 1 3 15
+
Fan Eff
*
2
Fan Eff
a Rotor Speed ]
C1.1 .3.1.6 * 4 mils * aFan Eff
4%
2
a Fan Press RatioI
500 rpm *
4%
+
a Fan Airflow.
3 % * aFan Eff
4%
[C . . . .
2
Airfoil GeomJ
4%
C1 .1 .3.1.3
+
aFVV position
4%
C1 .1 .3 . 1.2
2
40 * 8Fan Eff.
2
+
+
2
}/2
Nip Clearance
The partials (aFan Eff. / aFVV position, aFan Eff / aAirfoil Geom., etc) could be stored
in a table or matrix and only updated at significant configuration updates. These sensitivities
could be based on historic data, computer models, or initial estimates. Using a matrix or table
approach of sensitivities would eliminate the constant task of defining these sensitivities. This is
a common approach used in Life Cycle Cost trades in the military jet engine world. Given these
sensitivities and corresponding TW's and subsystem capabilities (C1 .1 .3 .1.1, etc) the RSDM for
Fan efficiency could be computed or estimated per equation (11) above.
The prior discussions have provided a method for rolling up RSDM from various
components to the system response of interest. We will now focus on the FVV positioning
capability for further analysis and explanation of the method.
22
FVV Positioning- Model vs. Monte Carlo Analysis Results
A MathcadTM model of a jet engine FVV actuation system was built to calculate the
RSDM
Fvv Position
and compute results using Monte Carlo analysis on the main drivers. The model
and results are provided in appendix A.
Load
N1 sensor
FVV Position
T2 sensor
RSDMVFV
Position
1.1.11 (refer to figure 5.)
TWfvv = 4 degrees
Electronics error (LVDT)
Linkage tolerances
Figure 6. A RSDM Decomposition of FVV Positioning
Equation (12):
RSDMFVV Position =
2
CL TWload
TWfvv
6fvv 2 + Cn- T- n1
TWfvv 6n1
6load/
Drivers: Load error
NI error
2fv
+ Ct2 TWt2
Uv
TWfvv 6t2)
T2 error
2
+ Celec
TWlvdt 8fvv
2
/
TWlink 6fv\
-- 2
+ ClinkT
TWfvv 8linv
TWfvv 6lvdt
Electronics
Linkage tolerances
From the MathcadTM model the sensitivities (partial fvv/ partial load, partial fvv / partial
n 1, etc) in equation (12) were determined. The tolerance width (TW) was set as noted for each
23
of the drivers as given in equation (13). The capability to achieve the stated TW was set to three
sigma. Thus the "C" values were all set equal to 1 in the RSDM equation.
Equation (13):
RSDM calculation for a tolerance width requirement of 4.0 degrees on FVV positioning:
2
(i.0 500 0.09
RSDM:=
4
RSDM =
2
2
1)
S
4.5 1.18
100 2.98
-.
+ 1.0-- - - - - + 1.0--
250
4
4
100
0.020.275)
--
+ 1.0--
4.5
4
0.01
0.50.24
2
+ 1.0--.--4 0.25
0.82
A Monte Carlo analysis was run for 10,000 actuation systems in the model. The results
are shown in Figure 7.
Monte Carlo Results for FVV Positioning
-3448,400
300 0-
u FVVbin
.
200 0-
.0
100 0-
,.A
-6
-5
-4
-3
-2
-1
0
1
2
3
binerr
Error from Request (degrees)
4
5
6
,6J
Figure 7. Monte Carlo Results from MathcadTM Model
24
From Figure 7, the Monte Carlo result shows there is a bias in the error. This error is
from the wind up in the system due to loading the linkage system. This bias could be removed
by accounting for it in the control schedule in the engine electronic control (computer). The
mean error was found to be -0.9 degrees and the standard deviation was 0.54 degrees.
The RSDM method indicates we have a 3.6 sigma capable system of meeting the 4 degree
FVV tolerance width on FVV positioning as indicated by the 0.82 value of the RSDM (see
appendix A for these calculations). Thus, we would predict that 0.027 % of the actuation
systems would not meet the 4 degree (+/- 2 degree from nominal FVV) positioning requirement
per the RSDM method. Presented another way, the RSDM methodology would estimate that
99.973% of the systems would meet requirements.
The Monte Carlo results of the program resulted in a standard deviation of 0.54 degrees.
For a clearer comparison, we simply divided the Monte Carlo six sigma capability (6*0.54 = 3.2
degrees) by the allowable tolerance width to compute the RSDM value via the Monte Carlo
method. The RSDM as computed by the Monte Carlo analysis equals 3.2 degrees divided by 4
degrees tolerance width, which equals 0.8. This compares very well with the RSDM
methodology that resulted in a RSDM of 0.82.
Thus, the Monte Carlo analysis resulted in an estimated RSDM of 0.8. This equates to a
3.8 sigma capable system or an estimate that 99.982% of the systems built would meet
positioning requirements.
The characteristic curves and requirements used in this case analysis of the FVV
positioning are realistic and representative of a current engine's requirements. In fact these
25
requirements are from a 35000 lb thrust class engine and of the 28 system built to date all have
met the stated positioning requirements.
This FVV example analysis provides closure on the RSDM methodology as a viable
means to define robust system design metrics (RSDM's) for program management and decisions.
It validates both the metric and roll up method of the metric. The results of the proposed method
compared well (within 0.01%) of traditional analysis tools (Monte Carlo).
26
Stakeholder Assessment - Identification of Key Jet Engine
Responses
The form and roll up methodology for a robust design metric has been provided. Now
key responses to focus upon at the jet engine program level will be identified.
The four value streams [LAI Oct 1998 Plenary Workshop] often to be considered in
framing ones decision about a product are (1) the product's users and or buyers (a.k.a.
customers), (2) the manufacturer's shareholders, (3) the employees of the company and (4) the
community in which the company operates. In this context the term product is used loosely to
also capture a service. My experience has been that most all consideration regarding the product
can be mapped or aggregated to one of these four value streams. When making decisions, these
value streams should be considered for the effect of the decision on them. If any of these is
offset or favored too much, then problems will arise.
The shareholders have value in the product from their interest to make money and see the
earnings per share and dividends continually increase. The customer of the product looks for
value in the product or they will not purchase it. The employees look to the product for value
capture to provide for their jobs and financial well being. And lastly, the community in which
the product is made or the service provided is affected by the value the product provides. The
community effect is typically the effect of the employees living and doing volunteer work in the
community as well as the income the product brings to the area. Also spouses and children
working and doing volunteer work in the community brings income to the area in addition to that
from the product itself.
27
Product Buyer/Owner: Affordability or costs of ownership and product performance are the
main items of interest to the buyer. Cost of ownership is driven by product price, maintenance
price (parts and labor price), durability (how long will it last and how often it requires
maintenance) and fuel burn efficiency (how much fuel is used during operation of the product).
Of course the buyer / owner is concerned that the product meets performance specifications such
as thrust, thrust response, range, observables, environmental regulations, etc.
Product User: Assuming a fighter jet, the main user is the pilot. First and foremost in the pilot's
mind is that the engines are dependable. In other words they work no matter what the pilot
requests of the jet. Then performance of the engines becomes critical. Engine thrust response
and recently thrust vectoring is important for maneuvering the jet. Thrust Specific Fuel
Consumption sets the range of the jet without aerial refueling.
A secondary but also significant user of the engine is the airplane manufacturer. Here
engine weight and interface conditions such as power take off (mechanical and/or bleed air)
electrical connections, engine mounting and loads, fuel and hydraulic interfaces and engine inlet
aerodynamic interfaces become significant in addition to the parameters with which the pilot is
concerned.
Manufacturer Shareholders: Major US jet engine company shareholders. The shareholders are
interested in the bottom line (earning per share). They desire to increase revenues or reduce cost
and to improve or maintain the bottom line. Revenues are increased by market share or market
growth. Profits are increased by reducing the cost of goods sold and earnings per share increase
with increased revenues and constant number of shares. Of course I've over simplified the
dynamics of the bottom line.
28
Employees: Here the employees are charged with the product development and manufacturing.
From product positioning in the market to the architecture of the product and its resultant
development cost, warranty cost and performance. A product development framework that was
developed during the MIT Systems Architecture Fall 1998 class is given below and provides a
framework that may be used in architecting and designing the product and conveys the effort to
be captured by the employees:
A Product Development Framework
Manufacturing
-Capabilities
-Production Plans
Regulation
-Standards
-Environmental
Corporate strategy
Customer & Field Support
-Product Delivery Plans
-Service Contracts
-Repair Plans
Concept
-ROI
-Make to order vs. stockin g
-Platforms
Architecture
-Affordability
m,
10 Need Market Data
-Benchmarking
-Expectations
-Customer Boundaries (Risk,
LCC, Schedule, Physical)
Goal -
-
User
t
& Validation
SDevelopment
I-Testability
-Test Requirements / Plans
Product Disposal
Technology
-Trends
-Extensibility
Down stream influences
Up stream influences
Goal
What the
system
does
-
e
Market Strategy
-Competitions strategy
-Product line, price,
promotion and placement
Need
Why the
system is
being built
4
Function
-
4
Concept Overall
arching means
to the end
Function
How the
system
behaves
Concepts
Expand design space with many disjoint concepts
Look to nature for potential concepts
-
Form -4
where are
the chunks
Timing 4-When things
do or need to
occur
Customer/User
Who buys it and
who uses it
Steve P. Sides 12 Oct 1998
Reference: E. Crawley's SDM Fail 98 SA Lecture Material
Figure 8. A Product Development Framework
Community: Income and jobs brought to community, housing and educational impacts, and so
forth are the items of consideration here. These are not in the main stream of this paper and
therefore are not expanded or focused upon.
29
From the stakeholder assessment and awareness of the product development framework,
we can identify the key jet engine parameters that should be focused upon at a program level to
best position ourselves to satisfy stakeholder needs. From the buyer/owner assessment we select
affordability. From the user (pilot) assessment we select dependability, thrust response and
range. Range has influences from the drag of the airplane and fuel storage capability to engine
fuel bum efficiency. Thus, from an engine perspective we will focus on Thrust Specific Fuel
Consumption (TSFC) in regards to airplane range. However, as we will see TSFC is a subset of
affordability in that it represents the cost of operation. Thus, we will fold TSFC under
affordability. From the airplane view we add engine weight to our considerations. From the
shareholders we select cost which captures production, development and warranty cost. We
focus on cost since market pressures will set the price of the product and the resultant profits.
Therefore, by focusing on achieving cost goals, the marketers may feel confident in positioning
the product from a price viewpoint. The employees get the opportunity to architect, design,
develop and manufacture the product that best meets these needs while deploying the RSDM in
the concept selection phase.
In summary we have the following five key attributes to focus upon:
1.
Affordability
2. Dependability
3. Thrust Response
4. Cost
5. Engine Weight
30
Decomposition of the Key Responses:
RSDM key characteristic
Decomposition Level Down (n+2 is two levels down)
Affordability (n level)
n+1
Development Price
n+2
n+ 3
Test Requirements
Rig Test
Component Test
Subsystem Test
Engine Tests
Flight Test
New Technologies
Materials
Components
Processes
Staff Size
Analysis Required
Test Required
Schedule
Product Price
Part
Labor
Material
Overhead
Assembly
Labor
Material
Overhead
Maintenance Price
Part
Labor
Materials
Overhead
MTBM
Labor
Materials
Overhead
LRU rate
Labor
Materials
Overhead
Fuel Cost
Fuel price
Typically assumed constant
Fuel used
Missions
TSFC
Dependability
MTBM (mean time between maintenance)
MTBF (mean time between failure)
Precision of Performance
Thrust Response
Fan Stall Margin
Compressor Stall Margin
Rotor Weight
Temperature Limits
Control Loop Bandwidth
Cost
Product Cost
Development Cost
Warranty Cost
Weight
Maximum Engine Speeds
Temperature Limits
Manufacturing Tolerances
Materials
Figure 9. Decomposition of the Key Responses:
31
Jet Engine Key Responses
High performance and low cost of ownership are desirable for jet engines both in the
commercial and military markets. Today a jet engine has a relatively long life cycle (20 - 30
years). Thus it is desirable for it to be affordable to own and operate. A jet engine is not unlike a
car in that we want it to be reliable, be affordable to own and last a long time, get good gas
mileage and accelerate or decelerate fast when needed.
Some of the top parameters monitored in the jet engine industry are thrust response,
Thrust Specific Fuel Consumption (TSFC), dependability of the product, weight and cost of the
product. From the stakeholder assessment the following five attributes were identified: (1)
Affordability, (2) Dependability, (3) Thrust response, (4) Cost and (5) Engine weight.
From the decomposition of affordability (Figure 9), one might conclude that maintenance
cost and fuel cost will be the long-term affordability drivers after the development program has
been planned. Of interest is that MTBM affects both affordability and dependability.
The fuel price is typically not within the control of the engine manufacturer or product
buyer. Therefore, from a product development view we focus on Thrust Specific Fuel
Consumption (TSFC). Throughout the planned missions the engine will spend significant
amounts of time at flight idle, cruise (a part power setting), military power and if equipped with
augmentors it will bum a lot of fuel when in augmentation. Thus, monitoring and managing the
TSFC of the engine at these key power settings seems appropriate. Today, approximately 80%
of the fuel bum occur at cruise conditions for aircraft. Therefore, it seems prudent to assess the
robustness of TSFC at a cruise power setting. Perhaps TPM's based upon nominal performance
should be monitored for all of these critical power settings, but as a minimum a RSDMTSFC
power
at cruise
is recommended.
32
Thrust Specific Fuel Consumption is important in that it represents how much fuel in
used for a given engine power or thrust setting. Poor TSFC will decrease the range and mission
effectiveness an aircraft can achieve without aerial refueling and increase the cost of ownership
in that more fuel is required to operate the vehicle. The first level noise factors that affect TSFC
are given in equation (14) and are decomposed to lower levels in Figure 5 in prior sections of this
report.
TSFC = f(Engine Efficiency, Secondary System Air Cooling Flow, Power Setting)
(14)
Dependability captures reliability, durability and repeatability of the product. We want
the engine to be reliable in that it performs the intended function when needed and durable in that
these functions may be performed over and over without extensive maintenance. Also, we want it
to be repeatable or have precision in its performance. One method to make a product reliable is
by adding redundancy. Another method would be to make the design robust in that redundancy
is not required. Typically adding redundancy adds maintenance cost in that more parts are
available for failure and thus more maintenance.
A robust design rejects noises and
disturbances and thereby provides some precision in performance (i.e. meets required
performance within tolerance width requirements.). The first level noise factors proposed for
dependability are given in equation (15).
Dependability = f (MTBF, MTBM, Repeatability)
(15)
Thrust response refers to how well the engine responds to pilot input via the throttle. For
large throttle input the pilot desires the engine thrust to change a significant amount in a short
time. For small throttle input the pilot desires accuracy. Small throttle input is used for
33
maneuvers such as aerial refueling, formation flying or landing. The noise factors that effect
thrust response are given in the following equation (16).
Thrust response = f(Fan Stall Margin, Compressor Stall Margin, Rotor Weight,
(16)
Temperature Limits, Control Loop Bandwidth)
Product cost refers to the manufacturing cost or the cost required to produce the product,
development cost and warranty cost. The company wants to keep cost low for competitive and
profit reason. The production cost captures the materials, overhead and standard cost to produce
the product. Other drivers that increase or decrease cost are tolerances. Tighter tolerances tend
to drive manufacturing cost up as does exotic or specialty materials. Of course the number of
units to be produced (economies of scale) affect the product cost. However, a RSDM could
assume a fixed set of sales for management reasons. The baseline could be adjusted, as
management deemed necessary for significant changes in volume. The intent of the RSDM here
would be to understand the robustness of the product cost estimated. For development cost the
intent would be to capture the likelihood that the program could be developed within the planned
schedule and assets. The intent of the warranty cost part of the metric would be an assessment of
the capability of the product to meet performance (TSFC) and durability requirements. Thus the
RSDM for TSFC and dependability would feed into the warranty RSDM. The proposed first
level noise factors for product cost are given in equation (17).
Cost = f (Material Cost, Manufacturing Cost, Warranty Cost, Development Cost)
(17)
The product's weight is initially scaled from existing engines. As the design of the
product solidifies the weight estimate is refined. Thus, a noise factor would be maturity of the
design. The less mature the more likely the weight target will be missed. The manufacturability
of the design puts the weight at risk. Difficult to make parts due to either materials or geometry
with large tolerances might drive weight variation. Duty cycle variations either from actual use
34
or from engines to engine performance variation could drive rotor speeds and component
temperatures, which eventually affect engine weight. Exotic high-risk materials for temperature,
strength or weight reason carry some risk to engine weight. The proposed first level noise factors
for engine weight are given in equation (18).
Weight = f (Materials, Geometry Complexity, Duty Cycle Variation)
(18)
The above five Key Responses are offered for program level RSDM's. The intent of
these Key responses and their first level noise factors has been provided. For TSFC, an example
decomposition (see Figure 5) has been provided. The completion of the TSFC decomposition
and the development of the remaining five responses is left to the user. The decomposition of the
responses is not unique. Two different companies or even people for that matter are likely to
decompose the proposed responses differently and both are correct. However, some
decomposition may be easier to work with and better map to analysis and how the company is
organized. The decomposition of these responses is left to the user and is not considered a trivial
or insignificant task.
35
P-diagrams as Part of Robust Design Culture
A case example will now be presented to provide an appreciation of how powerful a
simple tool such as the P-diagram could be if included in standard work or practices. Standard
work in this case refers to the work instructions that guide engineering in the product
development phase. It ranges from checklist of analysis to be done to modeling tools and
analysis that should be conducted or used all the way to expected manufacturing capabilities.
Standard work often captures typical test needed in the design and development of the product or
process. Here we will be focusing on the up front design phase. Often standard work is referred
to as the guide to best practices and process.
The P-diagram is powerful in that it is graphical, easy to understand and encourages one
to consider the systems at hand. A generic P-diagram as presented by [Phadke] is presented
below in Figure 10.
Noise Factors
Product or Process
Response
Signal Factor
Control Factors
Figure 10. Schematic of P-diagram
36
The signal factor is set by the system user or operator and is the desired or intended
response of the system. Noise factors are those parameters that can not be controlled by the
designer or may not be well known. This may be the case with interface conditions between
components or manufacturing variability. The designers may agree upon design load interface
conditions; however, there may be some variation in the exact load conditions. Another variation
or noise might be the actual environmental conditions in which a product might operate (dirty vs.
clean, hot vs. cold, etc.). The main noises in a system and their impact on the system need to be
considered.
The control factors are the parameters that can be specified by the designer. Control
factors are sometimes referred to as design parameters. An example of a control factor would be
the mechanical advantage in an actuation system. The response is the resultant output of the
process or product given the signal factor, noise factors and control factors.
Design errors during a jet engine's fan inlet guide vane actuation system design will now
be examied as an effort to show how a P-diagram might have prevented the errors by bringing
awareness to the design situation. The fan inlet guide vanes will be referred to as FVV's (Fan
Variable Vanes). The FVV's are modulated via an actuation system in response to signals from
the electronic engine control. The engine electronic control is basically the computer that is on
board the engine that determines requested poistions for engine valves and actuators given thrust
request from the airplane computers. The modulation of the FVV's results in turning of the air
entering the fan. The intent of this turning is to optimize the angle of attack of the air to the fan
rotor and pressure ratio across the rotor to maximize fan efficiency and fan stall margin. As the
FVV's close, the aerodynamic load significantly increases on the vanes. This load is then
tranferred through vane arms to a synchronization ring to the linkage system and then to the
actuator. This system is schematicaly depicted in Figure 11 with many details omitted for clarity
of view.
37
Actuation Linkage
Sync ring
Vane arm
FVV
Airflow
Actuator
Rotor 1
FVV Rotation
Engine Center Line
Figure 11. Fan Variable Vane (FVV) Actuation System Schematic
A shortfall in the systems design was identified during engine testing at high load
conditions. The FVV's did not adequately follow the engine control requested position (vane
angle) and slew rate (degrees per second) as depicted in Figure 12.
Actual Response
0
.
Request Signal
C,,
0
Expected or Desired
Response
0
Time - seconds
5
Figure 12. Poor Response from FVV Actuation System
38
The shortfall in FVV tracking resulted in a delay in the engine development program. A
"tiger team" of experts was formed to investigate the issue. The root cause was found to be a
failure to consider the noises or potential variations in the actuation system and interface loads
during the design process. Thus, the system was underdesigned. Corrective action involved
maximizing the mechanical advantage of the actuation linkage system, lowering system friction
through material selection and the addition of liners for FVV trunions. This event could have
resulted in the redesign of an actuator which is typically an expensive and long lead item.
Fortunately, multiple minor design modification could be identified and implemented to result in
an acceptable system. A P-diagram of the originial design might look like that in Figure 13 had
one been defined.
Noise Factors were not considered
Signal Factor =
FVV angle
request and slew
rate request
FVV Actuation
System
-
Response = poor
tracking of requested
slew rate and position
Control Factors:
* Actuator size
* Mechanical advantage
of linkage system
* Materials
* Part tolerances
* Number of flaps
* Size of flaps
Figure 13. P-diagram for FVV Actuation System Not Considering Noises
39
Had a P-diagram that considered the noises or variations up front been considered, the
likelihood of this design error would have been greatly minimized. The desired P-diagram is
given below in Figure 14.
Noise Factors:
" Aero load prediction errors
* Friction factor variation due to material
variation and dirty vs. clean
environment
" Mission or Fan variation driving vane
angle travel (aero load) requirement
* Deflection load errors
Sensors and electror ic errors
I
Signal Factor =
FVV angle
request and slew
rate request
FVV Actuation
System
Response = acceptable
positioning and
tracking capability
Control Factors:
* Actuator size
* Mechanical advantage
of linkage system
* Materials
* Part tolerances
* Number of flaps
* Size of flaps
Figure 14. P-diagram for FVV Actuation System With Noises
The learning in this case was twofold. One was that a P-diagram allows a company to
simply capture generic design considerations in a system, subsystem or component design.
These considerations and awareness might lead to a significant reduction in program risk. Had
this error not been correctable with minor design modifications, the program would have
40
incurred a significant schedule delay and cost impact (12+ months and $3+ million dollars in
redesigned hardware) for a more significant change in actuator requirements.
The second learning is that not only are the noises or variances to be considered, but the
design parameters or control factors must be selected to ensure the desired response is obtained
even under the given noise factors. This is the basis of robust design methodology. We desire to
select the design parameters of components or subsystems such that they are tolerant or robust at
the interface points. In classical robust design, this means selecting the design parameters that
result in the highest signal to noise ratio. That is given the design concept, we select design
parameters to maximize the likelihood that the desired response will be achieved given noises or
variances. If an acceptable response can not be achieved with the given concept, then we search
for a concept or process that will produce acceptable response.
RSDM Could Augment Life Cycle Cost Trade Analysis.
In jet engines, as with other systems there are constraints that will bound the design.
These constraints could be cost, size or envelope to operate within, manufacturing cost or
capability, maintenance cost and performance requirements to name a few. One that is
constantly bumped against for vehicles that must fly is weight. The engineering teams work their
design concepts and eventually come to several options, which would meet requirements. To
select the best system, a Life Cycle Cost (LCC) analysis that considers the performance,
development cost, manufacturing cost, weight, maintenance cost and so forth is conducted. The
system with the lowest Life Cycle Cost is selected. LCC is a significant decision metric for jet
engines since most engines are designed to last 20+ years. Thus, affordability over the life of the
product or cost of ownership is significant to the owner or operator of these products. Thrust
Specific Fuel Consumption (how much fuel is used to produce a given amount of thrust),
reliability and maintenance cost tends to be significant drivers in the LCC analysis. Though this
tool is extremely powerful, it omits a measurement of the product robustness. The LCC analysis
41
is done based on nominal conditions. A fundamental assumption is that the concept will perform
as desired. Therefore, to ensure the validity of the LCC analysis tool a method to ensure the
product will perform as desired is needed. A robust design methodology or culture will go a long
way in ensuring this. The use of P-diagrams may help cultivate this type of thinking amongst the
engineers and designers; however, P-diagrams will not drive program managers to manage in this
culture. What is needed is a program metric that provides a measure of product robustness such
that decisions can be made to ensure the performance of the system will be met. Also, this
metric will ensure the LCC decision tool is valid.
An example life cycle trade table is given below. Perhaps the addition of the RSDM on
the impact of product robustness would make the LCC decision more valid as indicated.
Life Cycle Cost Impact, millions $
Option
Base
A
B
C
D
E
Development
Cost
base
20
15
32
18
25
Part Cost
base
300
150
168
180
225
TSFC
base
-100
-20
-150
-75
-125
Weight
base
-325
-200
-100
-175
0
Maintenance
base
-20
0
10
-35
-20
Total LCC
base
-125
-55
-4C
-87
105
Robustness
Impact
base
?
?
?
?
?
Table 3. Sample Life Cycle Cost (LCC) Table for Concept or Option Selection
For the above Table 3, one would select option "A" since it has the lowest value in LCC.
Recall that affordability or cost of ownership is a key response; therefore, we desire a low value
of LCC. Note that life cycle cost is not necessarily today's cost but represents the cost incurred
over the life of the product. Thus, a part cost increase of a few thousand dollars could end up as
a several hundred million dollar impact in our LCC table depending on the conversion factor of
42
part cost to LCC. This paper does not cover the development of such factors but recognizes
different industries have such factors. Also, the values in the above table are deltas from a
defined or selected base configuration or option. Apparently from Table 3, we conclude that for
twenty million dollars in development cost and some increase in part cost, a significant
improvement in Thrust Specific Fuel Consumption (TSFC) and a weight reduction can be
realized for option "A". This LCC method of selecting a configuration to go forward with is
powerful and has proved extremely beneficial in the jet engine industry. What is missing from
this method is the option's impact on robustness. Option "A" might be the best considering
nominal operation, but if variance were introduced it might fall apart driving high maintenance
cost. Even worse yet would be if the variances caused the product not to work at all.
These tools are just that- tools to aid our decisions. Users of these tools are reminded not
to get caught up in the exactness of the LCC or the RSDM indication at this stage. At this stage
only a relative comparison amongst the concepts is needed. Once the configuration of choice has
been identified then one might refine the LCC estimates and RSDM indicators for reporting and
management reasons. Again, it appears that a RSDM as proposed previously would augment the
design process.
43
Conclusion and Recommendation
A RSDM metric that uses a capability indicator and significance factor can be developed
for jet engine program management. The following form can be applied from system to
subsystem to component to part levels.
RSDM
Key Response =
(C 1.1.1 * SF. 1. 1)2
+ (C 1. 1.2 *
SFI.I.2) 2
+ ..
+(C1.I.k *
SF..1) 2
) 1/2
where,
"C" is the RSDM indication at the denoted decomposition level and "SF" is the
corresponding significance factor. "C" represents the capability to meet a flowed down
requirement
also,
"C
1.1.2"
would be the RSDM of the second response one level down that feeds into the
RSDM at level 1.1. The corresponding SF of "C 1.1.2" would be:
SFI.1 .2
TW main driver
*
1.1.2
TW key response
1.1
8 Key Response 1.1
8 Main Driver
1.1.2
An example case analysis provided closure on the RSDM methodology as a viable means
to define robust system design metrics (RSDM's) for program management and decisions. It
validated both the metric and roll up method of the metric. The results from the method agreed
with traditional Monte Carlo analysis within 0.01 %
44
A stakeholder assessment suggests the following attributes and key responses be focused
upon during jet engine development.
Key Attribute
1.
Affordability
RSDM Key Response
TSFC
2. Dependability
Dependability
3. Thrust Response
Thrust Response
4. Cost
Cost
5. Engine Weight
Engine Weight
Finally, the P-diagram is a graphical method to capture noise and control factors for
systems. It seems using them or some other means to capture this information as part of standard
work would prove beneficial to cultivating a robust design culture.
45
References
1.
Madhav S. Phadke, "Quality Engineering Using Robust Design", Prentice Hall, Englewood Cliffs, New Jersey,
1989
2.
John R. Taylor, "An Introduction to Error Analysis", University Science Books, Mill Valley, CA, 1982
3.
Dan Frey, "Using Product Tolerances to Driven Manufacturing System Design", Massachusetts Institute of
Technology 1997
4.
Lean Aircraft Initiative, "October 1998 Plenary Workshop", Massachusetts Institute of Technology 1998
5.
Jim Lyneis, System Dynamics Re-work Cycle, material presented in System and Project Management 15.967
Fall 1998 course at Massachusetts Institute of Technology
6.
H. Harrison and J. Bollinger, "Introduction to Automatic Controls"
7.
S.L. Dixon, "Fluid Mechanics, Thermodynamics of Turbomachinery",
2nd
Edition, Harper and Row, 1969
3
d Edition, Univ. of Liverpool, England,
1986.
8.
J. Ackermann, "Sampled-Data Control Systems-Analysis and Synthesis, Robust System Design",Germany, 1985
9.
Core Program Metrics as recommended by SEI. Guidance on Metrics,
http://sepo.nosc.mil/metricsHTML/tsld03 .htm, 18 Nov. 1999
10. Linda Rosenberg, Phd, "Developing a Successful Metric Program",
http://satc.gsfc.nasa.gov/support/ICSE NOV97/iasted.htm, 19 Nov. 1999
11. Unal, R. and E. B. Dean , Design for Cost and Quality: The Robust Design Approach , Journal of Parametrics ,
9
vol. XI , no. 1 , August, 1991. http://techreports.larc.nasa.gov/ltrs/refer/19 1/iop-91-9-l.refer.html, 19 Nov.
1999
12. Frey, D.D., K.N. Otto, and J.A. Wysocki, 1997, "Evaluating process capability given multiple acceptance
criteria", to appear in ASME Journal of Manufacturing Science and Engineering.
13. Greitzer, E.M. and Wisler, D.C.,"Gas Turbine Technology: Status and Opportunities", MIT 31 August 1999.
46
Appendix: Mathcad ProfessionalTM model of a Jet Engine Fan Variable
Vane Actuation System for the Purpose of Demonstrating the RSDM
Methodology.
The jet engine actuation system modeled here uses corrected Fan rotor speed to request an FVV
angle setting. The assessment to be made is "how well can we count on the systems ability to
meet positioning requirements"? This model allows us to assess the error from requested FVV
position to actual using the Robust System Design Metric methodology and Monte Carlo
analysis. Figure LA is a simplified schematic of the situation being modeled.
N1R2 Sensor Error
NI
T2
Xreq Effector
-VV
Nl* 50
NIR2
FVV Request
Actuator Request
Electronic Errors
0FVV
---
Actual
Linkage Tolerance
Actuation System Loading, lbf
Figure LA. FVV Scheduling Schematic
The tolerance width assigned to the FVV system is 4 degrees vane angle (+/- 2 about nominal).
The main noises being considered in the system are NI and T2 sensor errors, systems loading,
linkage system tolerance and effector loop feedback errors. The results of the two assessment
methods were found to compare within 0.01% indicating the viability of the proposed RSDM
methodology.
47
Input data
degrees R
T2mean :=520
Nlmean :=9170
rpm
Flags to turn on variance. 1=1 variance is on, 1=0.0001 variance is
basically off. Use flags to investigate model.
It2 :=1.0
Ind :=1.0
Iload :=1.0
Ito:= 1.0
Ilvdt :=1.0
number of actuation systems to be made or runs for Monte
n:=10000
Carlo analysis.
A ni
Tolerance width on N1 signal accuracy, rpm. Note the full tolerancE
:= 100
width is 6a.
A n1
an :
6
Inl
N1:=rnorm(n,N1mean, Yn1)
A T2:=4.5
Normal distribution of n systems of mean
N1mean and standard deviation Ouni
Tolerance width on T2 signal accuracy, degree R
A T2
aT2 :=-It2
6
T2 = morm( n, T2mean, oT2)
T2sqrt :=T2- 0 .5
N1R2:= 4
2 -(N1-T2sqrt)
48
Define FVV angle request as a function of corrected fan rotor speed
FVVRQN1R2):=
(-45)
if N1R258300
(9) if N1R2210115
(-45)
(Ii
- 8300)
(10115 - 8300)
otherwise
Plot the FVV Characteristic Curve
nlr2tab :=6000,6050.. 12000
10
0
-10
2
FVVRQ(nlr2tab) -20
-30
-40
I
-50
6000
7000
I
8000
I
9000
I
1*104
I
1.1*0
1.210
nlr2tab
Corrected Rotor Speed - rpm
Figure 2A. Corrected FVV Rotor Speed vs. FVV Request
49
Determine load at actuator, lbf
I
(1000)
FVVLIQN1R2):=
if NIR257100
(1000) if 98705N1R2
[(1000)+
1500.(NLR2- 7100)
(8390- 7100)
if 7100<N1R2<8390
JJ
(2500) if 83905N1R259180
[(2500)-
1500.(N1R2- 9180)1
if 9180<NIR2<9870
(9870- 9180)
Plot the Characteristic Curve of FVV Load
3000
I
I
I
I
2500
2000
FVVLD(nlr2tab)
1500
1000
500
0
6000
I
7000
8000
9000
I
I
1.104
1.1.104
1.2-104
nIr2tab
Corrected Rotor Speed - rpm
Figure 3A. Corrected FVV Rotor Speed vs. Actuation System Load
50
A Load :=500 Tolerance width on predicted load, Lbf
aLoad
A Load
Ld-Iload
6
Vecloaderror :=rnorm(n,
0.0, aLoad)
FVVLDwerf=FVVLI NR2) + Vec loaderror
Define FVV angle to actuator position relationships
FVVGAINmean: =27.5
degrees
inch
A Tol :=0.5
Tolerance and slop on linkage system, FVV degrees
aTol :=
A Tol
Itol
6
FVVGAINer =rnorm( n, 0.0, a Tol)
FVVGAIN:=FVVGAIN meani- FVVGAIN err
FVM x) :=FVVGAINmeanx- 45.5
Xmean(FVV)
(FVV+ 45.5)
FVVGAINmean
xact:=0,O.0.. 2
51
FVV Angle to Actuator Stroke
20
I
I
I
I
I
0.25
0.5
0.75
1
1.25
12
4
-4
-12
FVV(xact)
-20
-28
-36
-44
-52
-60
0
1.5
1.75
2
xact
FVV Actuator Stroke- inches
Figure 4A. FVV Actuator Stroke vs. FVV Angle
Position error due to friction and air loads on actuation system
/
/
/
/
/
Linkage spring rate, Ibf/inch
Klink:= 146000
Mount spring rate, Ibf/inch
Kmount :=
160000
Effective
Vanes
Load, lbf
LLnkkge
Mount
Linkage
Fan Case Mount
Figure 5A. FVV Actuator System Stiffness Schematic
52
Xerr_Link:= FVVLD-werr
Klink
Xerr_load
Xerrmnt:=
FVVLD wen
Kmount
XerrLinkt Xerr_mnt
FVVLD-err= (FVVGAINXerr load)
Effector Loop
T, sample Knull
Current
limit
Actuator Hardware
Electronics
4.
S
-v4
Actuator
EHSV
T 2 sample
Current limit
Granulay
Xreq
F -d ac
Kamp
Ts+1
Nominal Null
=10 mA
T2s+ 1
Xactual
S
Current amplifier
Granularity
T 2 sample
LVDT Feedback
Xfb
Figure 6A. Effector Loop Schematic
53
For the effector loop shown in Figure 6A, the steady state error will primarily consist of the
LVDT accuracy. At steady state conditions, the error between feedback position and requested
actuator position will be driven to zero. The tolerances on holding null position are taken out by
the null bias integrator. Electronic requirements on the EHSV and current amplifier are such that
response is fast and linearity (no measurable dead band) is maintained. Thus, for this exercise
we focus on the error introduced by the inaccuracy of the feedback device (LVDT).
-6
-5.5
stroke :=2.0
actuator stroke in inches
-J
-4.5
Tolerance on LVDT accuracy, inches stroke
A LVDT:=0.01-stroke
C
-4
-3.5
A LVDT
aLVDT =
Ilvdt
-3
6
-2.5
LVDTerr:= rnorm(n, 0.0, aLVD)
-2
-1.5
-1
FVVelec-err:=(FVVGAINLVDTerr)
-.5
Sum the error influences (note that the gain or linkage tolerance
was captured in load and electrical error calculations.)
FVVactual: =FVVRQ N
1R2) +
FVVLD-err+ FVVelecerr
binerr :=
0
.5
1
1.5
FVV-request :=FVVR
Nlmean-
520
2
T2mean
2.5
3
FVV-request = -19.1
3.5
FVVerror:=FVVjrequest-
maxerror:=ma(FVVerror)
FVVactual
4
FVV_bin:=hist(binerr, FVVerro)
5
minerror: =min( FVVerro)
maxerror=
1.2
4.5
5.5
minerror = -2.9
6
6.5
54
Monte Carlo Results for FVV Positioning
4000
3000 -
FVVbin
--
-
2000 -
1000 r
0
-6
-5
-4
-3
-2
-1
0
1
2
3
4
5
6
binerr
Error from Request (degrees)
Figure 7A. Monte Carlo Results for FVV Positioning Capability
Clearly from Figure 7A we see there is a bias in the error from the wind up in the system
due to loading the linkage system. This bias could be removed by accounting for it in
control schedule in the engine electronic control (computer)
Monte Carlo simulation results:
Meanerr
mean(FVV error)
FVVstd
stdev (FVV error)
Meanerr =-0.9
FVVstd = 0.54
55
Proposed RSDM methodology results:
RSDMFVV
Position =
I
TWnl fv
TWfvv 8n1
2
CLJTWload 8fvv
TWfvv 8load/
Drivers:
2
+ Ct2. TWt2 *fv
TWfvv t2
N1 error
Load error
2
+
2
-fvv\
Celec TWlvdt 6fyv\ + Clink-TW -ink
TWfvv 61in
TWfvv Tlvd
T2 error
Electronics
2
Linkage tolerances
Compute FVV to Load sensitivity
Load
deltaload:
2
deltaload
=
250
deltafvvload :=deltaload Kmount
+-in
Ki
.FVVGAINmean
deltafvvload = 0.0901
Compute FVV to NI sensitivity
deltanI
A ni
=.
2
deltanI
=
50
520
nlr2_lower:=(Nmean- deltani).
T2mean
deltafvv_nl :=FVVRQnlr2_upper)
-
nlr2_upper :=(Nmean + deltan)
520
T2mean
FVVRQnlr2_lower)
deltafvv_nl = 2.9752
56
Compute FVV to T2 sensitivity
A T2
deltat2
2
deltat2
=
2.3
520
nr2_lowert2 :=Nmean
nlr2_upper_t2 :=Nlmean
(T2mean+ deltat2)
deltafvvt2 :=FVVRQ nlr2_upperjt2)
deltafvv t2 =
-
520
(T2mean- deltat2)
FVVRQ nlr2_lower t2)
1.1805
Compute FVV to Electronics sensitivity
A LVDT
deltalvdt
2
deltalvdt
0.01
=
deltafvvlvdt :=deltalvdt -FVVGAIN_mean
deltafvvlvdt = 0.275
Compute FVV to linkage sensitivity
A Tol
2
deltatol
deltatol
=
0.25
xmean:=Xmean FVVR N1mean- 520
\ T2mean
xmean=
0.9594
deltafvvtol
deltafvvtol
(xmean-FVVGAINmea) - xmean-(FVVGAIN meant- deltatol)
=
-0.2399
57
RSDM calculation for a tolerance width requirement of 4.0 degrees on FVV positioning:
RSDM:=
.500
I .04
RSDM =
0.09
2
+ 1.04
250 /
\4
+( +(
1.0-
100
4.5 1.182
-4 4.51
0.02 0.2752
1.04 00
4 0.01
0.50.24 2
4 0.25
0.82
Table 1A. Meaning Of RSDM
RSDM
Number Exceeding
Tolerance Width
0.5
0.6
0.75
1.0
1.2
1.5
2.0
3.0
< 2 / 1,000,000,000
< 0.6 / 1,000,000
< 63 / 1,000,000
< 3 / 1,000
< 12 / 1,000
< 46 / 1,000
< 134 / 1,000
< 32 / 100
Process Capability
6a
5a
4cy
3a
2.5y
2a
1.5a
-t
2
prob(t):=------
e
dz
tI:= 1 2 3 4 5 6 7]
(1- prob(tl))=
0.317
0.046 0.003
6.332-10
Process capability
+/-1 a
+/- 2 a
+/- 4cr
+/-3 a
5.734-10
+/- 5 a
1.766-10
+/- 6 a
-5.52-10
]
+/- 7cy
58
We have RSDM = 0.82 which means a 3.6a system capability
RSDM is = (6 *g) / (2* Cp*a) = (6 * a) / (2 *t*a)
or
t = 6 / (2 * RSDM)
therefore,
3
trsdm :=
RSDM
trsdm = 3.6
Percent-act-sysfailures
:=(i
Percent-act-sysfailures
= 0.0267
-
prob(trsdm)) -100
3.2
4
RSDMmontecarlo:=---
3
trsdm
RSDMmontecarlo
trsdm =
3.8
Percent-actsysfailures
:=(1- prob(trsdm)) -100
Percent-act-sysfailures = 0.0177
Less than 0.027 percent of the actuation systems will fail to meet requirements as predicted by
the RSDM method. Per the Monte Carlo method less than 0.018 percent will fail. Said another
way; the RSDM method and Monte Carlo results compare well with a prediction of 99.973 %
and 99.982 % conformance to requirements respectively.
59
RSDM and Monte Carlo Results Comparison:
The RSDM method indicates we have a 3.6 sigma capable system of meeting the 4 degree FVV
tolerance width on FVV positioning as indicated by the 0.82 value of the RSDM. Thus, we
would predict that less than 0.027 percent of the actuation systems would not meet the 4 degree
(+/- 2 degree FVV) positioning requirement per the RSDM method.
The Monte Carlo results of the program resulted in a standard deviation of 0.54 degrees. Thus,
we would expect the 3 sigma system tolerance width to be 3.2 degrees (6*0.54 = 3.2 degrees).
This appears to compare well with the RSDM method in this case.
For a clearer comparison, we simply divided the Monte Carlo six-sigma capability by the
allowable tolerance width to compute the RSDM value via the Monte Carlo method. RSDM
Monte Carlo =3.2/4 = 0.8. The Monte Carlo method predicted 99.982% of the system would
meet requirements where the RSDM method predicted 99.973%. The proposed method and
traditional analysis tools (Monte Carlo) agree within 0.0 1%.
This example analysis provides closure on the RSDM methodology as a viable means to define
robust system design metrics (RSDM's) for program management and decisions.
60