Citation
An introduction to failure mode and effects analysis (FMEA)

Material Information

Title:
An introduction to failure mode and effects analysis (FMEA)
Creator:
Gojanovic, Anthony
Publication Date:
Language:
English
Physical Description:
viii, 108 leaves : illustrations ; 29 cm

Subjects

Subjects / Keywords:
Engineering design ( lcsh )
System failures (Engineering) ( lcsh )
Engineering design ( fast )
System failures (Engineering) ( fast )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Bibliography:
Includes bibliographical references (leaves 106-108).
General Note:
Submitted in partial fulfillment of the requirements for the degree, Master of Basic Science.
General Note:
Department of Medicine
Statement of Responsibility:
by Anthony Gojanovic.

Record Information

Source Institution:
University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
37364419 ( OCLC )
ocm37364419
Classification:
LD1190.L44 1996m .G65 ( lcc )

Downloads

This item has the following downloads:


Full Text
AN INTRODUCTION TO FAILURE MODE
AND EFFECTS ANALYSIS (FMEA)
by
Anthony Gojanovic
B.A., University of Colorado, 1987
A thesis submitted to the
University of Colorado at Denver
in partial fulfillment
of the requirements for the degree of
Master of Basic Science
1996


This thesis for the Master of Basic Science
degree by
Anthony Gojanovic


Gojanovic, Anthony (M.B.S)
An Introduction to Failure Mode and Effects Analysis (FMEA)
Thesis directed by Professor Karen Kafadar
ABSTRACT
Failure Mode and Effects Analysis (FMEA) is a developmental tool used
to identify failures and effects on systems, products or services. In
addition to identifying failure modes and failure mode effects, FMEA
provides for quantification and categorization of failure information in
order to allocate and prioritize resources for risk abatement. The greatest
impact of FMEA is in pre-production phases of new product or system
development in order to provide for failure free systems and products
during implementation. FMEA is a versatile tool that has many
expressions and can be integrated with statistical and software tools to
provide for a comprehensive view of risk.
This abstract accurately represents the content of the candidate's thesis.
I recommend its publication.
Signed
Karen Kafadar


CONTENTS
Figures....................................................vii
CHAPTER
1. INTRODUCTION......................................1
Failure Study Motivations ......................3
Correct Solution, Wrong Problem?........... 3
I Need It Now and I Need It Perfect!...... 5
2. ORIGINS OF FAILURE MODE
AND EFFECTS ANALYSIS (FMEA) ......................7
3. FAILURE MODE AND EFFECTS ANALYSIS (FMEA) . 11
Tabular FMEA ................................ 11
Failure Mode Effects and Criticality Analysis. 14
4. FAILURE MODE AND EFFECTS ANALYSIS
FOR MANUFACTURING............................... 23
IV


Process and Design FMEA
. 27
5. FAILURE MODE AND EFFECTS ANALYSIS
AND SOFTWARE DEVELOPMENT..................... 29
6. STATISTICAL BASIS OF THE
FMEA WORKSHEET ............................. 31
7. FAILURE MODE EFFECTS ANALYSIS
INTEGRATION ................................. 33
Surveys......................................33
Reliability Analysis ....................... 34
Linear Models................................35
Exploratory Techniques...................... 37
Statistical Process Control................. 37
8. FAILURE MODE AND EFFECTS ANALYSIS
TERMINOLOGY ..................................39
FMEA Formats.................................39
9. PERFORMING A SUCCESSFUL FAILURE
MODE EFFECTS ANALYSIS........................ 41
v


10. LIMITATIONS OF FAILURE MODE
AND EFFECTS ANALYSIS ...............43
11. OTHER TECHNIQUES .........................45
12. THE FUTURE OF FAILURE MODE
AND EFFECTS ANALYSIS ...............47
APPENDIX
A. CASE STUDY A: A FMEA OF A PHOENIX MODEL
ROCKET RECOVERY SYSTEM ... 48
B. CASE STUDY B: STRATEGIC TEST
DESIGN MATRIX.............. 57
C. CASE STUDY C: FMEA COMPUTER
IMPLEMENTATION............. 60
FMEA.PAS.............. 69
FMEADATA.PAS.......... 73
FMEAMAT.PAS ......... 84
FMEASORT.PAS.......... 100
BIBLIOGRAPHY ...................................... 106
VI


FIGURES
Figure 1.1 Quality Lever ................................ 2
Figure 1.2 Change Comparison...............................2
Figure 3.1 Tabular FMEA.................................. 12
Figure 3.2 Failure Mode and Effects Worksheet
for Task 101 in MIL-STD-1629A................ 15
Figure 3.3 Criticality Analysis for Task 102 in
MIL-STD-1629A (Quantitative Method)......... 16
Figure 3.4 Criticality Analysis for Task 102 in
MIL-STD-1629A (Qualitative Method)........... 20
Figure 3.5 Criticality Matrix ........................... 21
Figure 4.1 FMEAC for New Product Development............. 24
Figure 4.2 FMEAC for New Product Development with
Corrected RPN ............................... 26
Figure 7.1 Life Cycle Hazard Function.................... 36
Figure A.1 Phoenix Recovery System Block Diagram .... 50
VII


Figure A.2 Phoenix Recovery System FMEA..................... 52
Figure A.3 Sorted FMEA by RPN................................ 53
Figure A.4 Sorted FMEA by Severity........................... 54
Figure A.5 Phoenix Recovery System DFMEA
and PFMEA Example .............................. 55
Figure B.1 Strategic Test Design Matrix..................... 58
Figure C.1 FMEA Data Manipulation Options.................... 61
Figure C.2 FMEA Data Graphing Options ....................... 61
Figure C.3 FMEA Sorting Options ............................. 61
Figure C.4 FMEA Data Entry Screen .......................... 62
Figure C.5 Criticality Matrix of a FMEA Data Set............. 63
Figure C.6 Stem and Leaf Plot of FMEA Probabilities .... 64
Figure C.7 Stem and Leaf Plot of FMEA Severities........... 65
Figure C.8 Stem and Leaf Plot of FMEA Risk................ 66
VIII


CHAPTER 1
INTRODUCTION
Current criteria for the success of consumer goods rely upon
product introductions that are as failure free as possible. The costs
associated with defective products from a liability or lost consumer
standpoint can have dramatic impacts on a company. In a business
environment that is becoming extremely competitive and global, the
presence of failures in a system, product or service, can only serve to
destabilize a company financially. Indeed, many companies have failed
due to the inability of providing a product that is able to meet basic
customer expectations and requirements.
The definition of failure is the inability of a system or product to
meet a required function. Failures can be dramatic and sudden or subtle
and gradual resulting in system or product degradation. Defective
consumer products from common household appliances to much
publicized automotive recalls have impacted from a few to millions of
individuals. Not only product failure but even breakdowns in a service are
potentially damaging. A misdiagnosed patient in a hospital as a result of
a communication failure can be harmful to the patient and to the
reputation of the hospital itself.
With increasing technological sophistication, the problem of finding
and correcting failures is becoming more complex and at the same time
increasingly imperative. The need for "first pass manufacturing", in
which a product or service has been made failure free prior to widespread
implementation, is critical. No longer are product recalls or field fixes
feasible, desirable or cost effective. Figure 1.1 shows the cost associated
with fixing problems as time progresses through a new product
development cycle (7, p. 170) and Figure 1.2 compares U.S. vs Japanese
company changes through a development cycle (7, p. 172). Changes
made later in the design cycle are not only expensive but give away any
competitive edge.
With increasing technological sophistication, requirements for
failure free products are becoming more stringent, and for good reasons.
For example, if a 0.1 % failure level were allowed in the United States, the
1


NUMBER OF ENGINEERING
PRODUCT
DESIGN
Figure 1.1 Quality Lever
Figure 1.2 Change Comparison
2
MONTHS


following would occur (29, p. xxvi):
- Two unsafe landings at O'Hare Airport per day.
- 12 babies given to the wrong parents each day.
- 880,000 credit card magnetic strips with wrong
information.
- 5,517,200 cases of flat soft drinks produced per year.
- Two million documents lost by the IRS each year.
Given the need for systems and products that are as failure free as
possible, tools for identifying failures and correcting them are needed. It
is the scope of this paper to discuss one such tool for identifying failures,
their effects, causes, and how a failure analysis can provide guidance in
the development of corrective action and risk abatement strategies.
Failure Study Motivations
The motivations for developing failure examination methods can
best be developed through the following examples taken from the
author's experience in commercial manufacturing.
Correct Solution. Wrong Problem?
The first case involved the development of a statistical model to
determine the risk associated with the implementation of an existing
product that was modified in order to realize a cost savings. The risk was
to be expressed through an anticipated nonconforming product rate that
would be encountered once production of the "new" product began. The
model itself was based as a linear combination of two independent
variables in order to determine the probability that a certain pre-
determined threshold value (measured as a differential between two
independent product components) for a certain failure mode would not be
exceeded. Specifically, the model used was of the form
E{a^ + a2Y2) = a^EiYj + a2E(Y2)
3


a2(a1ir1 + a2r2) = ala2(Yx) + aia2(Y2) when Yu Y2 are independent.
The data for the model was obtained through limited scale
experimentation using modified product components that were of interest.
The study was planned carefully to minimize unnecessary variability and
to insure that basic statistical assumptions were met through the use of
randomized testing.
The subsequent data were exceptional in the sense of being
symmetric and without large outlying values as interpreted through
exploratory techniques such as histograms and boxplots. The appropriate
parameters were plugged into the model and an estimate of the expected
probability that a nonconforming product would occur was obtained. The
probability, p, of a nonconforming product, was rated against the
manufacturing plant's output. The resultant rate was deemed to be
inconsequential and therefore the risk of implementation was considered
low. Thus a risk assessment based on an appropriate statistical technique
was developed early in the design stages to provide confidence that
costly process and product adjustments would not occur during
implementation nor at any time during full production of the "new"
product in question.
However, once implementation of the modified product was
started, nonconforming product began to surface. At this point, the
original model, the underlying assumptions, and data were examined.
Nothing was found to be wrong with the development or interpretation
of the model. In some ways, the model development was considered to
be "textbook" ideal. If so why were problems appearing?
The answer was with the failure mode itself. The original risk
assessment was developed for a certain type of failure mode. The failure
mode that occurred during implementation was different. No
consideration was given to alternate failure modes that could occur due
to the modifications. As a result, resources were allocated to define the
risk associated with only one particular failure mode, one which happened
to be of lesser consequence. Consequently, problems with the actually
observed failure mode had to be handled in a hasty fashion that resulted
in increased interpersonal tensions and high testing cost.
4


I Need It Now and I Need It Perfect!
Another instance that motivated the need to find ways of looking
at product failure involved the development of a new product.
Specifically, a marketing team developed an idea for improving sales
through an innovative product design feature. With new marketing
projects, rapid implementation is often critical in order to be one step
ahead of the competition. This rapid implementation or "fast track"
approach places pressure on manufacturing and engineering to quickly
develop and implement a new product. With new products, success
relies heavily on immediate conformance to customer requirements.
Failures of a new product can be devastating to the success of a
marketing strategy.
Since the product implementation time line was critical, several
issues arose which were not encountered previously. The first was
determining the anticipated overall nonconforming product rate that might
be encountered. The nonconforming rate on the existing product was
measured in parts per 10 million i.e p 0. In order to determine what the
new product would experience in terms of a nonconforming rate, the
amount of product needed would be enormous. Large quantities of
product would be required to satisfy the statistical power, given the small
observed p value, if an accurate assessment of risk was desired. The
ability to accurately assess if a true difference exists is problematic since
manufacturing large quantities of a new product is a high risk and
potentially high cost venture if problems are encountered. But a problem
may not be detected if large quantities are not run. Hence, a circle exists
that seems to have no opening. One way out of the circle is through
forced failure testing, or accelerated testing, of certain design features in
which the worst situation is evaluated in order to see if any immediate
disasters occur as compared to control samples composed of current
product manufactured under worst case conditions. This type of testing
does assist in validating design integrity to some extent e.g. detection of
catastrophes, but longterm process capability, determined by the stability
and low variability of product performance, is not easily addressed. Long
term product capability, without producing large quantities of product,
would have its assurance through understanding process failure modes
and developing corrective action to minimize such failure modes as a
result of process variability. Thus it was critical to concentrate on key
process and design failure modes that would provide the most impact if
not corrected. Since time was of the essence and resources were limited,
5


compounded with the need for "100% assurance", the question arose of
how to best determine which failure modes were most critical in order to
determine the proper focus of resources so that testing could be
performed. How was this to be accomplished? This question prompted
research into the topic of this paper.
6


CHAPTER 2
ORIGINS OF FAILURE MODE AND EFFECTS ANALYSIS (FMEA)
Research into methods for identifying and classifying failure modes
of a new product started with conversations with a co-worker about
which other fields of manufacturing is the development of failure free
products critical. The consensus was that the aerospace industry would
be one such area where failure studies would fill a necessary and obvious
need. Below are listed some examples from the aerospace sciences
which illustrates this demand for failure studies:
- The 1979 crash of a DC-10 in Chicago was the result of large
cracks in the engine mount as a result of severe and unanticipated
maintenance procedures (19, p. 112)
- The Galileo space probe sent to explore Jupiter has suffered
missions problems from a snared main antenna, a defective tape
recorder and a faulty valve in the propellant pressurization system
(5, p. 11)
- On June 3, 1980, the North American Air Defense Command
(NORAD) reported that the U.S. was under missile attack. The
alert was false and was attributed to a faulty computer circuit (14,
p. 46).
- Cold temperatures embrittled the "O" rings on the space shuttle
Challenger's solid fuel rockets resulting in tragic and complete
mission failure (19, p. 5).
Further investigations into the history of failure identification
studies in the aerospace industry led as far back to a lecture given by
Wilbur Wright in September of 1901 to the Western Society of Engineers
in which he stated (1, p. 86)
"The problems of land and water travel were solved in the 19th
7


century because it was possible to begin with small achievements
and gradually work up to our present successes. The flying
problem was left over to the 20th century, because in this case the
art must be highly developed before any flight of any considerable
duration at all can be obtained."
Wilbur Wright was expressing the need for a sophisticated
approach to developing a new mode of transportation which could not
rely on loosely connected trial and error experiments which had been
successful in other fields. Indeed, the Wright brothers, bicycle mechanics
that they were, pioneered aeronautical research, engineering and testing.
The reasons for their careful up front work was most likely motivated by
the same reasons that current manufacturing is confronted with in the
development and implementation of a new product. The Wright brothers
understood that they would be developing a "flying" machine that if
failed, even once, could result in great bodily harm. Unfortunately this
latter scenario did pan out for Orville Wright, who, on September 17,
1908, during a demonstration for the U.S. Army at Fort Meyer, suffered
a crash landing because one of the propellers developed a longitudinal
crack and failed. As a result, Orville Wright suffered injuries and his
passenger, Lieutenant Thomas Selfridge, became the first powered
airplane fatality (11, p. 230).
The Wright brothers' demonstration of a manned powered flying
machine opened the flood gates for airplane development. Aircraft for
military operations were utilized in World War I and the use of aircraft for
mail delivery and transport soon followed. Increased use of airplanes
resulted in increased air crashes (9, p. 1) and the need for increased
reliability and safety levels for aircraft based on accident rates per hour
of flying time. Airplanes were naturally becoming sleeker, faster and
more complex than their wood and cloth ancestors. The natural
consequence of this advance was increased hierarchies of interconnected
components which could fail. In 1947, a paper was presented to the
Institute of Aeronautical Sciences which stated (31, p. 11)
"Safety must be designed and built into airplanes just as are
performance, stability, and structural integrity. A safety group
must be just as important a part of a manufacturer's organization
as a stress, aerodynamics, or a weights group."
The need for reliability and safety in systems was also recognized
with rockets during World War II in Germany. The first series of 10 V-1
8


rockets (predecessor to the infamous V-2) either blew up on the launch
pad or fell into the English Channel. Robert Lusser, a mathematician, was
consulted on the problem of the V-1 rockets and developed a
mathematical formalism to describe the reliability of a series system.
Lusser determined that the old adage of "a chain is no stronger than its
weakest link" was not applicable to a series system since it failed to
account for random failure. Lusser developed the product law of series
components, or that the reliability of a series system is equal to the
product of the reliabilities of the individual components: Rs = R1R2R3...Rn.
Hence in a series system the reliability of the individual components must
be much higher than the system reliability for satisfactory system
performance. In the United States, efforts to improve reliability were
focused on the extension of quality; Better designs, stronger materials,
advanced inspection techniques, etc., were emphasized to extend the
useful life of a part or an assembly. This philosophy was illustrated with
General Motors Electro-Motive division which extended the useful life of
traction motors used in locomotives from 250,000 miles to 1 million miles
through the use of better materials and improved testing (9, p. 2).
During the Korean War in the 1950's, the Department of Defense
found that unreliable equipment required a tremendous amount of
maintenance. Specifically, the cost to the Armed Services was $2 per
year to maintain every $1 worth of electronic equipment (9, p. 2). As a
result, the government found that it was wiser to design for reliability
than it was to wait and repair equipment after failure. In the commercial
arena, on the first anniversary of jetliner service, May 2, 1953, a de
Havilland Comet disintegrated over India followed by two other Comet
midair explosions during 1954. All explosions were the result of
pressurization fatigue on the airplane's cabin and were discovered through
post mortem investigations of the wreckage (19, p. 176). This
philosophy of "fly-fix-fly" was not applicable for high risk, high cost or
high visibility systems. In the fly-fix-fly approach, improvements are
based on an examinations of failures in order to improve the next
generation of a product or system. After-the-fact testing misses the mark
in which potential failures cannot be tolerated as a finished product
component.
Missile system development in the late 1950's and early 1960's
also prompted new approaches for examining failures. The Minuteman
intercontinental ballistic missile (ICBM) was one of the first to have a
formal, disciplined system safety program (31, p. 11). Further prompting
came from the Mercury and Gemini manned rocket programs that
demanded success the first time. Disastrous accidents at four ICBM
9


missile/silo complexes in 1962 also resulted in increased safety
awareness.
From this background, failure identification strategies originated.
One early method was Failure Mode and Effects Analysis (FMEA) which
emerged to identify failures in systems. FMEA is a simplified approach to
systems reliability analysis (17, p. 559) and is utilized to identify a failure
mode of a component, its cause, and the effect on the overall system.
According to the "official" definition found in Military Standard 721C
(MIL-STD-721C), a Failure Mode and Effects Analysis is (2, p. 3)
"A procedure by which each potential failure mode in a system is
analyzed to determine the results or effects thereof on the system
and to classify each potential failure mode according to its
severity."
FMEA has evolved to include provisions for the development of
corrective action strategies for the elimination of failures.
FMEA is utilized not only in highly visible and critical items such as
aircraft, ballistic missile systems, oil refineries, nuclear power plants and
satellites, but also in new consumer product introductions. For the same
reasons, preventing large scale failures and increasing reliability before
implementation of a design or system, FMEA has become so important in
the commercial arena. "First pass manufacturing" is needed for any
organization that requires a high level of quality and reliability at product
introduction.
10


CHAPTER 3
FAILURE MODE AND EFFECTS ANALYSIS (FMEA)
Tabular FMEA
How does a Failure Mode and Effects Analysis proceed? The basic
development is through the use of a worksheet format consisting of
several columns. This is appropriately called the tabular FMEA. An
example of a general tabular FMEA is shown in Figure 3.1 (3, p. 14).
The basic idea of the FMEA, as mentioned previously, is to
characterize failures of a system or component, the causes of the failure
and the effect of the failure on subsequent components or on the overall
system. A FMEA is performed early in the design stages of a new
product or system as a way of discovering failures so that necessary
corrective action can be developed to reduce or eliminate failure modes.
FMEA is used as a preventive action tool. FMEA is also a versatile tool
that has expressions in maintainability analysis (MEA), logistical support
analysis, safety analysis and damage analysis (DMEA). These alternate
expressions were originally conceived for military applications but may be
developed for commercial products. The level of sophistication and
nature of a FMEA can be tailored to the situation at hand.
The general tabular FMEA expressed in Figure 3 consists of 9 key
columns whose function can be defined as
Column Function
1 Component under consideration.
2 A concise statement of the function or intended
4
5
3
purpose of the component.
The mode of failure of the component or the various
ways in which failures are observed.
The cause of failure.
The effects of the failure on the next component and
on the overall system.
11


Component Function Mode of Failure Cause of Failure Effect of Failure Detection Method Corrective Action Effect of Corrective Action Remarks
Local Ultimate

Figure 3.1 Tabular FMEA


6
8
9
7
The method of failure detection or discussion of how
the failure may be detected.
Possible corrective action to reduce or eliminate the
failure.
Effects of corrective action.
Remarks.
Columns 1 and 2 are used for identification and purpose of the part
under study. The function of the component and its requirements is
critical to guiding the development of the FMEA. Column 3 lists the
failure modes and may consist of many modes for each specific
component. The failure modes need to be based on the Operating
conditions at the time of failure since different situations may result in
different failure modes. Column 4, the cause of failure, are possible
reasons why the failure mode occurred. Column 5 describes the effects
of failure on the next component and on the overall system. Column 6,
the method of failure detection, is used in providing insight into what
current controls will detect the failure mode prior to actual failure.
Column 7, possible corrective action, and column 8, the effects of
proposed corrective action, answer the question of how the failure modes
will be addressed e.g. testing programs or control systems, and what
effect did the corrective action have on the failure mode itself. Column
9, the "remarks" part of the worksheet, can be used to express specific
concerns of the analyst during the analysis.
The tabular FMEA is a general method to brainstorm for failures of
a system or component. The FMEA is started when some information is
known of a system or component design and should start early in the
design cycle since the goal is development of a product as free from
failure as possible prior to full scale implementation. This goal applies not
only to conceptually new products but also to existing ones which may
be modified to new configurations. It is for this reason that FMEA is a
living document and is considered complete only when a product, system
or process is finalized with no anticipated future changes or modifications.
Tabular FMEA is a very versatile tool that can be tailored to fit the
analysis at hand and the level of indenture of a system or component.
Tabular FMEA presents the results of a FMEA session in a logical and
understandable format so that corrective action can be developed.
13


Failure Mode Effects and Criticality Analysis
Although the tabular FMEA is the cornerstone of a successful
failure identification program, there are certain drawbacks. The process
of performing a FMEA can be time intensive and generate large amounts
of paperwork if the level of analysis is broad. The tabular FMEA also
provides no quantifiable information on the severity of a failures' effect
on the overall system or on the likelihood of occurrence. The ability to
grade a failure is crucial in determining resource allocation. For example,
a faulty cigarette lighter on an automobile is far less severe to the
operation of the vehicle and safety of the passengers than faulty brakes.
The ability to characterize failures, in terms of their criticality and the
frequency with which they occur, assures that the proper response with
proper resources are allocated and that failure reduction activity is not
haphazard or misdirected towards inconsequential items. A FMEA study
can generate considerable amounts of failure modes, not all of which can
be addressed in a timely or cost effect manner. For this reason, a relative
basis to measure the importance of a failure mode on the overall success
of a product or system is needed.
The introduction of criticality analysis (CA) as a complement to
FMEA is a way to provide a ranking of failures. Criticality analysis was
introduced by NASA prior to 1965 as a way to assure that hardware used
in the space program was reliable (3, p. 17). To define (20, p. 102-1)
"The purpose of criticality analysis (CA) is to rank each potential
failure mode identified in the FMEA Task 101, according to the
combined influence of severity classification and its probability of
occurrence based upon the best available data."
The failure analysis of FMEA and CA now becomes FMECA or
Failure Mode Effects and Criticality Analysis. The "standard" for
performing a Failure Mode, Effects and Criticality Analysis is developed
in MIL-STD-1629A. Figure 3.2 represents Task 101 in MIL-STD-1629A
which is a typical FMEA worksheet but now has a column for assessing
the severity of a failure. The other columns of Task 101 are defined in
detail in MIL-STD-1629A and are similar to the definitions provided
previously for the tabular FMEA. Figure 3.3 represents a typical
worksheet for Task 102, the criticality analysis, and includes, in addition
to a severity column, specific parameters used to quantify the failure of
a component. The probabilities in Task 102 when coupled with the
14


FAILURE MODE AND EFFECTS ANALYSIS
SYSTEM___________
INDENTURE LEVEL__
REFERENCE DRAWING
MISSION______
DATE_________
SHEET______OF
COMPILED BY___'
APPROVED BY____
Item/Functiona I Identification (Nomenclature) Mission Failure Effects
Identification Number Function Failure Modes and Causes Phase / Operational Mode Local Effects Next Higher Level End Effects Failure Detection Method Compensating Provisions Severity Class Remarks

Figure 3.2 Failure Mode Effects Worksheet for Task 101 in MIL-STD-1629A


CRITICALITY ANALYSIS
SYSTEM___________
INDENTURE LEVEL__
REFERENCE DRAWING
MISSION__________
DATE_________
SHEET______OF
COMPILED BY___
APPROVED BY____
Failure Failure Failure
Failure Mission Probability Effect Mode Failure Operating Item Rem-
ftem/Func. Modes Phase ! Failure Prob Ratio Rate Time Failure Mode Crit # Crit P arks
ID Identification and Operational Severity Rate Date
Number (Nomenclature) Function Causes Mode Class Source B a t Cm = C;

Figure 3.3 Criticality Analysis for Task 102 in MIL-STD-1629A (Quantitative Method)


severity classification, aid in the development of a matrix illustrating how
the various items under a failure study compare in terms of probability of
occurrence and severity. The approaches used in the criticality analysis
can be either quantitative or semi-quantitative.
Since both Task 101 and 102 have severity classification columns,
a brief description of severity is in order. According to the MIL-STD-
1629A, the value of severity classification is to provide a qualitative
measure of the worst potential consequences resulting from a design error
or item failure. Severity is classified below (20, p. 10):
Category Classification Definition
I Catastrophic
II Critical
III Marginal
A failure which may cause
death or weapon system
loss.
A failure which may cause
severe injury, major
property damager, or major
system damage which will
result in mission loss.
A failure which may cause
minor injury, minor
property damage, or minor
system damage which will
result in delay or loss of
availability or mission
degradation.
IV Minor A failure not serious
enough to cause injury,
property damage, or
system damage, but which
will result in unscheduled
maintenance or repair.
Although the above classification is directed primarily towards
military applications, modifications can be made for use in product
designs of consumer goods.
17


With the introduction of severity to the FMEA worksheet, items
developed in a FMEA can be grouped in a logical manner. This
categorization guides the allocation of resources for failure abatement
strategies.
The key to criticality analysis is the ability to accurately quantify
failure probabilities. However, this presents certain problems. In many
instances what is known of an item's failure probability may simply not
be available and needs to be ascertained from engineering knowledge,
historical evidence or best guess. In other cases the probabilities of
failure may exist in handbooks, such as MIL-HDBK-217F, Reliability
Prediction of Electronic Equipment, that provide failure rates for electronic
equipment ranging from tubes and lasers to capacitors, resistors and
lamps. These two types of situations will result in a criticality analysis
performed in either a semi-quantitative or quantitative manner,
respectively.
Figure 3.3 represents a criticality analysis worksheet in which
failure probabilities can be assessed quantitatively e.g. obtaining certain
parameter estimates for failure modes for an item under consideration.
These parameters are located on the CA worksheet in Figure 3.3 and are
defined explicitly in MIL-STD-1629A. The estimates are then used to
calculate a failure mode criticality number, Cm, where Cm = PaXpt and
the item criticality number, Cr = ^ (PaXpt) from j = 1 to n, in which
n is the failure modes in the item that fall under a particular criticality
classification and j is the last failure mode in the item under the criticality
classification.
The above calculations are used when information pertaining to the
various parameters is known. The quantitative method is considerably
more complex than the qualitative method although it does provide for a
more accurate analysis.
The qualitative method on the other hand is much simpler and more
applicable when specific failure rate data are not available. Failure modes
identified in the FMEA are assessed in terms of probability of occurrence
and a scheme for grouping these probabilities is provided in MIL-STD-
1629A. A summary of these classifications are as follows (20, p. 102-1):
Level Category Description
Level A Frequent A high probability of
occurrence during the
operating time interval.
18


Level B Reasonably Probable A moderate probability of
occurrence during the item
operating time interval.
Level C Occasional An occasional probability
of occurrence during item
operating time interval.
Level D Remote
An unlikely probability of
occurrence during item
operating time interval.
Level E Extremely Unlikely
A failure whose probability
of occurrence is essentially
zero during item operating
time interval.
MIL-STD-1629A provides specific failure values for the above
definitions. However, the probabilities will vary depending upon the
situation at hand. In other words, the above categories may be
customized with different values and ranges of p, the probability of
failure, and need to be developed and agreed upon prior to the start of the
FMEA.
Figure 3.4 shows how the criticality worksheet appears when the
qualitative method is chosen.
Whether the analysis is quantitative or qualitative, the resultant
analysis can be charted on a criticality matrix. An example of a criticality
matrix is shown in Figure 3.5. The matrix is constructed by inserting item
or failure mode classification numbers in matrix locations representing the
severity classification and either the probability of occurrence or the
criticality number, Cr, for the item's failure modes. The resultant chart
indicates the corrective action priorities. Specifically, the diagonal line
from the origin represents increasing criticality.
The criticality matrix provides a useful pictorial of failure modes and
their overall relationship to an item or system in terms of what's
important regarding problem resolution.
MIL-STD-1629A provides a specific and methodical approach to
constructing a FMEA and Criticality Analysis, resulting in the FMECA.
MIL-STD-1629A can be modified easily to suit needs in commercial
manufacturing or service environments. If the emphasis is on the simpler
qualitative analysis, MIL-STD-1629A provides an effective brainstorming
19


CRITICALITY ANALYSIS
SYSTEM___________
INDENTURE LEVEL__
REFERENCE DRAWING
MISSION__________
DATE_________
SHEET______OF
COMPILED BY___'
APPROVED BY___
Identificatio Number Item/Functlonal Identification (Nomenclature) Function Failure Modes and Causes Mission Phase / Operational Mode Severity Class Probability Level Remarks

Figure 3.4 Criticality Analysis for Task 102 in MIL-STD-1629A (Qualitative Method)


Cr Probability of Increasing
Occurrence Criticality
Severity Classification
(Lesser Severity to Greater Severity)
Figure 3.5 Criticality Matrix
(Quantitative and Qualitative y axis scales are both shown)
21


and prioritization tool that allows both experts and non-experts to
participate in a failure study. Indeed, there are other FMEA approaches
which are effective in determining failure modes and appropriate risk
abatement strategies. Alternative approaches will be presented in the
next section.
22


CHAPTER 4
FAILURE MODE AND EFFECTS ANALYSIS FOR MANUFACUTURING
The methods and formats in Chapter 3 are fundamental examples
of a FMEA. However, other formats exist which yield the same end result
as the methods described above. One such format is shown in Figure
4.1, a FMEA worksheet taken from Juran's Quality Control Handbook
from the section titled "New Product Development" (6, p. 13.30). It is
more general than the FMEA methods provided by MIL-STD-1629A and
is representative of the type of FMEA worksheets currently in use in
commercial arenas and those found in related literature.
The key element behind the FMEA worksheet in Figure 4.1 is the
determination of a risk priority number or RPN. The RPN value is
calculated by multiplying values obtained in the columns titled frequency
of occurrence, degree of severity and chance of detection, here referred
to as columns A,B and C, respectively. Note that the frequency of
occurrence and degree of severity columns correspond to the probability
of occurrence and severity columns in MIL-STD-1629A but now a column
has been added to quantify the chance that a failure will be detected.
The values for these columns are the numbers 1 to 10, scaled as follows:
Column Title
A Frequency of Occurrence
1 = Rare occurrence
10 = Almost certain occurrence
B Degree of Severity
1 = Insignificant loss to the user
10 = Product inoperable or major replacement
cost or safety hazard.
23


Item: Block Number:
Function:
Analyst: Date:
Component Mode of Failure Cause of Failure Effect of Failure A Frequency of Occurance B Degree of Severity C Chance of Detection Risk Priority Number Design Action Design Validation





Frequency of Occurrence: Degree of Severity Degree of Detection:
1 = Rare occurance 1 = Insignficant loss to the user 1 = Certain detection before failure
10 = Almost certain occurance 10 = Product inoperable or major 10 = No detection possible before failure
replacement cost or safety hazard.
Figure 4.1 FMEAC for New Product Development


c
Chance of Detection
1 = Certain detection before failure
10 = No detection possible before failure
The subsequent RPN (RPN = A x B x C) is an integer between 1
(negligible risk) and 1000 (critical risk). This number is then utilized to
prioritize corrective action.
The advantage of the worksheet in Figure 4.1 is its simplicity. The
rating system is largely subjective in nature although historical information
can be utilized to guide in number assignment. For example, if a certain
item has a historically very low defect rate, the frequency of occurrence
will be a 1 or 2. On the other hand, if no information is known of how
a component may respond, the best guess of the FMEA team can be
given on the 10 point scale. Further gradations of the numbering system
can be developed. For example, in the above numbering scheme, values
from 2 to 9 have not been defined. These intermediate values can be
defined and based on specific process, product or mission requirements
that the FMEA is addressing.
Another advantage of the FMEA worksheet in Figure 4.1 is the
ability to sort the RPN number or columns A,B and C to find the "big
ticket" items. For example, a FMEA team may decide to concentrate on
the top 10% of highest RPN values, or concentrate on high severity items
with low detectability and so on. Cutoff values for RPN numbers might
be determined by the design team based on cost and resource factors e.g.
RPN values of 50 or less might be considered noise whereas RPN values
of 500 or more might require corrective action.
The last two columns of Figure 4.1 are important to the analysis.
Once specific items have been targeted for corrective action, the action
itself must be part of the FMEA. Hence the design action and design
validation columns are included. The design validation refers to how the
corrective action is verified. Once corrective action has been initiated, the
RPN number may change and Figure 4.2 illustrates a FMEA worksheet in
which the additional columns A',B' and C' are utilized to calculate the
new RPN.
25


Item: Block Number:
Function:
Analyst: Date:
Component Mode of Failure Cause of Failure Effect of Failure A Frequency of Occurence B Degree of Severity C Chance of Detection Risk Priority Number Design Action Design Velidation A' Freqeuncy B' Severity C' Detection RPN






Frequency of Occurrence:
1 = Rare occurance
10 = Almost certain occurance
Degree of Severity
1 = Insignficant loss to the user
10 = Product inoperable or major
replacement cost or safety hazard
Degree of Detection:
1 = Certain detection before failure
10 = No detection possible before failure
Figure 4.2 FMEAC for New Product Development with Corrective Action Columns


Process and Design FMEA
To this point discussion has focused on general FMEA methods as
applied to development of products or systems. Further refinements of
the FMEA are into design FMEAs (DFMEA) and process FMEAs (PFMEA).
The former focuses on the design of the product and the latter
emphasizes consistent manufacture of the design. The DFMEA occurs
first and then the PFMEA attempts to address issues related to
manufacturing variability and product consistency. The difference
between a DFMEA and PFMEA is often subtle; the following example
illustrates the differences.
Suppose a series of recyclable rockets are built to study the upper
atmosphere. The rockets are recyclable only if they return safely from
their mission with little or no appreciable damage. Safe return depends
in part upon the recovery system that consists of a parachute of a certain
diameter. The diameter of the parachute was specified in the design
stages to be 16 feet. A DFMEA resulted in a testing program that
showed the risk to rocket safety and recoverability with a 16 foot
parachute to be acceptable i.e. a "low" RPN. Next, a PFMEA on the
process related to the production of the parachute was performed and
revealed that the nominal value of parachute diameters of 16 feet is
obtainable but the process variability is extremely high. Thus some
parachutes may be smaller than 16 feet and some much larger than 16
feet; in either case, the product will fail to function as required. If the
parachute is too small, the rocket will plummet to the ground; if too large,
the rocket may be carried miles outside of the intended operating range.
As a result, machine modifications are required to reduce the variability
of the process insuring that the highest possible proportion of correct
diameters are manufactured. Note that if the process had been stable
(low variability) but the design was incorrect i.e. a mis-specified parachute
size that is too larger or too small, then the problem would be with
design.
A design FMEA is then used during design of a product, its
component parts and any of the equipment necessary to manufacture the
product. A process FMEA will be used in any process that can be
mapped and that has associated and identifiable failure modes (7, p.
175). Both the DFMEA and PFMEA are able to use the same worksheet
but it must be noted on the worksheet with a separate column whether
the failure under consideration is a process or design issue. With the
introduction of the PFMEA, the amount of paperwork will be considerably
27


increased requiring greater management.
28


CHAPTER 5
FAILURE MODE AND EFFECTS ANALYSIS AND
SOFTWARE DEVELOPMENT
Software development oftentimes requires that same basic
requirements of being failure free prior to introduction as do other
products. The criticality of software errors can be summed up in the
following examples:
- A software problem may have prevented a Patriot missile from
tracking an Iraqi Scud missile that killed 28 Americans during the
Gulf War (15, p. 62).
- The manned space capsule Gemini V missed its landing point by
100 miles due to the guidance program ignoring the motion of the
Earth around the sun (14, p. 49).
- A single incorrect character in the specification of a control
program for an Atlas rocket carrying the first interplanetary
spacecraft, Mariner I, caused the rocket to veer off course shortly
after takeoff. Both the rocket and the spacecraft had to be
destroyed (15, p. 63).
Software measures of performance can be expressed as defects per
1000 lines of code (KLOC), development time, modifications, re-writes,
etc. The same principles of FMEA, defining failures, causes and effects,
can be applied to software development. As with other products, a key
element in developing successful software is defining requirements
accurately. Accurate requirements drive design, planning and testing of
software.
How might a FMEA work with software development? Suppose
one is writing a structured program in PASCAL. Within the overall
program, there may be UNITS, or collections of constants, data types,
variables, functions and procedures. The unit may form a level of
indenture for the FMEA and individual components would be the
29


INTERFACE, CONST, TYPE, PROCEDURE and so on. Each of these in
turn could be broken down further. For example, under a specific
procedure, local declarations listed under the VAR section would be
analyzed for potential failures e.g. declaring a variable as a INTEGER when
indeed it needs to be a declared as an REAL. The key component of such
an analysis is to understand the requirements and relationships to the
overall program. As mentioned, requirements will provide the basis for
the ability to correctly devise and carry out a plan of action in the
development of the software. Testing will validate such actions and
determine if more problem solving is warranted.
A key element to software development is through the use of
metrics or measurements. Performance measurements such as reliability,
efficiency, maintainability and cost are integral to software quality
assurance. The era of undisciplined programming artists, or "hackers",
must give way to a software development that is both disciplined and
repeatable. FMEA methodology provides one tool to reach the objective
of failure free software.
30


CHAPTER 6
STATISTICAL BASIS OF THE FMEA WORKSHEET
In development of the risk priority number, the question arises as
to the statistical nature of the FMEA numbering system. Specifically,
what distribution, if any, do the occurrence, severity and detection
columns follow?
In the absence of known failure data, a generic rating system based
a scale from 1 to 10 provides a way to grade failures. Such a scale can
be viewed as being uniformly distributed i.e. described mathematically by
the discrete density function
fix) = 1
n
with mean and variance
E{X) =
x = 1,2, . ,n
, ViX) =
n2 1
12
This implies that each gradation from 1 to 10 is equally likely to
occur. Actual values used with the FMEA depend upon the knowledge
of a FMEA team.
The uniform distribution provides a reasonable description of the
rating system distribution in lieu of actual known failure data.
In addition to the column distributions, the calculation of the risk
priority number, RPN, poses some interesting questions from a probability
standpoint.
If RPN is considered to be a probability statement, the
manipulations of columns A. B and C can be viewed in two ways. If each
column is assumed to be statistically independent, then
P(ABC) = P{A) P(B) P(C).
However, this may not be entirely accurate. If columns A, B and
31


C are somehow related, the use of conditional probabilities may be more
appropriate. It is not unreasonable to imagine that provided that one event
has occurred, the probability of the next event should be in accordance
with the information provided in light of the first event. For example, if
an item in a FMEA has a low probability of occurrence, the chance of
detection may be low as well. This situation then follows the conditional
probability form
P(ABC) = P(A) P(BjA) P(C|AB)
where A, B and C are the columns defined previously. If failure data are
accurately known, the above equation will provide for a more accurate
model for the distribution of final RPN values than assuming
(unrealistically) independence.
32


CHAPTER 7
FAILURE MODE AND EFFECTS ANALYSIS INTEGRATION
The value of a FMEA is to identify failure modes along with severity
and probability of occurrence in order to rank key failures. Once this is
done, development of corrective action is the next step. The value of
corrective action is to aid in risk abatement.
Several corrective action strategies exist for both process and
design issues. These strategies may be in the form of developing new
manufacturing practices and procedures, modifying work habits,
implementation of inspection routines, and so on. One specific tool which
can be used as a corrective action strategy is statistics.
A diverse set of statistical techniques may used with a FMEA.
These techniques are not limited to only corrective action but can be used
during the construction of the FMEA to determine failure risks and
probabilities or to provide an idea of how effective was the corrective
action. In many instances, failure will be controlled by the ability to
develop predictive models. Below are some techniques to accomplish
such goals.
Surveys
Surveys are an investigative questioning technique. The primary
function of surveys in the context of FMEA is to define customer
requirements. The scope of a FMEA is determined by its ability to
address failure modes in relation to certain conditions. As mentioned in
the beginning of this paper, failure is defined as the inability of a product
or system to meet a required function. The first step is the proper
definition of what is needed from a product or service. Whether the
customer is a consumer or the next process in a production line, absence
of clear requirements may misdirect efforts needed to eliminate failure
modes. Surveys, whether they are randomly mailed questionnaires to
33


consumers or interviews among different departments in a company, fill
the need for developing clear requirements.
Reliability Analysis
Reliability is the determination of how likely a product or system
will operate without failure for a stated period of time, t. The basic idea
for the reliability of a component or system at time t is given by
R(t) = P(T >t)
where T is a continuous random variable denoting time to failure and t is
some specific time. Generally the distribution of T is modeled by a
probability distribution such as the normal, exponential, gamma or
Weibull.
Reliability models are useful in estimating the frequency of
occurrence for a failure mode in a FMEA. Oftentimes, a new product is
simply a modification of an older design from which data exist and can be
used to predict the possible outcome for a modified product. Reliability
models also may be used as a design action strategy to test different
designs.
Reliability analysis is closely related to survival analysis. Both seek
to identify factors which have an effect on the survival, over time, of a
product, system or biological entity. For example, survival analysis can
be used to model tool wear over time. Tooling failure in a stamping
process, for example, leads to nonconforming product which may fail to
meet a customer requirement. Both analyses utilize the hazard function
given by
hit)
fit)
Rit)
where f(t) is the probability density function of T (failure function) and
R(t) is the probability fo surviving to at least time t (reliability function).
The hazard function is interpreted as the instantaneous failure rate i.e. the
rate of failure at a given instant in time provided that the item has lasted
until that time. Its shape describes situations in which a product may
have a high failure rate directly after manufacture, such as an automobile
during the "break in period". After a period of time, a hazard function
34


that remains constant is referred to as the "useful life" of the system. As
the product ages, as with an automobile, breakdowns are more frequent
and occur during the "wearout" period. Break in, useful life and wearout
periods characterize the product in question. Each period may have
different failure modes with differing probabilities and severities which
must be taken into consideration in a FMEA under requirements. A graph
of a generic hazard function is shown in Figure 7.1 (12, p. 10-5).
Linear Models
Linear models can take on forms such as those expressed as
regression, analysis of variance and experimental design. The value of
linear models is the ability to develop relationships between one or more
independent variables and a response in order to provide insights into
underlying mechanisms driving such relationships. Both regression and
analysis of variance models can be utilized in experiments or with
historical data. Multiple regression models follow the form
= P 0 + PA + $2*12 + Pp.rXk.p-! +
where
P0, Px, . Pp^ are parameters
Xn, . . are known constants
are independent i\r( 0, o2)
i = 1 ,...,n
and the multi-factor analysis of variance cell means model is
-^ijk ~ Fij + ^ijk
where
\ii:j are parameters
eijk are independent N(0, a2)
i = 1,...,a; j = 1 ,...,b; k = 1,...,n
Designed experiments, when done properly (randomization,
35


h(t)
A
Figure 7.1 Life Cycle Hazard Function


elimination of extraneous variation, etc.), can provide very useful analysis
of experimental data. Designed experiments provide precise estimates
and reliable models that can be used for optimization of a product or
process. The predictive power aids in abating risk through identification
of key factors and understanding their contribution and relationships to
some output. Designed experiments also provide for developing products
that are robust or insensitive to variations in a process or environment
which certainly can play a role in risk abatement.
Exploratory Techniques
Perhaps one of the most widely utilized and powerful techniques
that is available to an analyst are exploratory data techniques.
Exploratory techniques differ from confirmatory studies in that the
probabilistic assumptions underlying standard statistical tests are not the
basis of analysis. This is not to say that exploratory and confirmatory
techniques are diametrically opposed. Rather exploratory techniques are
part of an iterative loop in which data first are explored for interesting
patterns upon which confirmatory studies based on probabilistic models
may be pursued. For example, exploratory techniques such as boxplots,
scatterplots, robust regression, median polish, etc., provide for
comparison and pattern identification. In many instances, exploratory
techniques, coupled with process knowledge, can provide conclusive
results of a data set without resorting to confirmatory techniques.
Statistical Process Control
Statistical process control, or SPC, encompasses a wide variety of
graphical and statistical tools used to analyze, control, and improve a
process or product. SPC is used extensively in quality applications.
One widely used SPC technique is the control chart. The value of
a control chart is to track the performance of a process over time. More
so, control charts are used to distinguish between natural variability
versus special causes of variability. The ability to distinguish these two
types of variation in a process form the basis of prevention. When a
37


process exhibits assignable causes of variability then action can be taken
to correct the process to bring it back under control.
The value of SPC and control charts to FMEA is in corrective
action. Control charts are used to detect situations that could pose a
problem before they actually occur. The value of this cannot be
underestimated if the purpose of FMEA is to develop a product that is
known to be failure free before use.
Control charts are also a natural consequence of designed
experiments discussed previously. If key factors of a product or process
are identified through designed experimentation, the use of control charts
assure that certain factor values are consistently manufactured in order
to produce the optimum response as determined by the designed
experiment. In many cases, experiments performed on a limited
scale do not account for manufacturing variability. Implementing a new
product on several different manufacturing processes is a risky endeavor
if different components of variability are not taken into account. Control
charts assist in tracking variability of different processes and provide the
ability to detect special causes of variation. Control charts provide the
means to compare variation between processes and pinpoint areas in
need of variability reduction or control.
38


CHAPTER 8
FAILURE MODE AND EFFECTS ANALYSIS TERMINOLOGY
A remark on FMEA terminology is in order. In the previous
discussion of Figures 4.1 and 4.2, the term FMEA was used in reference
to the worksheets and to the action of performing a failure study. In
some of the current literature on the topic of FMEA, Figures 4.1 and 4.2
are referred to as FMEA worksheets and the process as a FMEA and not
necessarily a FMECA worksheet or analysis, although Juran's Quality
Control Handbook refers to them both as FMECA. Since Figures 4.1 and
4.2 are indicative of what has been noted in current literature on the topic
and commonly referred to as FMEAs, the term FMEA will be used to
describe the worksheet and analysis. Both the FMECA and FMEA provide
essentially the same type of information but under slightly different
formats and names.
FMEA Formats
Several different types of FMEA formats or worksheets have been
discussed. Which format should one use?
In some cases a customer may require a supplier of a product or
process to develop an FMEA according to a specific format; e.g. MIL-
STD-1629A for Department of Defense contractors and SAMSO-STD-77-
2, "Failure Modes and Effects Analysis for Satellites, Launch Vehicle, and
Reentry Systems" for space vehicle contractors. Reference (21) is a
manual on performing FMEA for suppliers to the Chrysler Corporation,
Ford Motor Company and the General Motors Corporation. Learning
industry specific FMEA formats can be accomplished through courses
offered by a wide variety of organizations such as the American Society
for Quality Control (ASQC).
In instances where an organization may wish to develop a FMEA
without compliance to a specific format, one of the standard forms
39


presented in this paper can be utilized or custom formats developed. In
either case, the formats must include a list of failure modes, their
consequences and subsequent corrective action. The intent of performing
a FMEA is to define failures so that appropriate failure abatement
strategies can be developed early in the design stages before full scale
implementation of a system or product. FMEA is not "rocket science";
the use of whatever format suits a specific need while maintaining the
spirit of FMEA should be developed. Hybrid worksheets incorporating
project schedules, FMEA results and testing programs are ways of using
and extending the basic ideas of FMEA. Experimentation of formats is
worthwhile to obtain the best method that is commensurate with a
particular project. An example of an innovative failure strategy is
provided in the appendix under case study B.
Software programs can be utilized to perform FMEA and manage
the resultant analysis. Two such programs are Formuser by Engineered
Work Systems, Inc., and FMEAPLUS by Ford Motor Company (both are
registered trademarks) (29, p. 70). An excellent and quite suitable
alternative is a spreadsheet program such as Microsoft Excel that
provides the ability to sort the various columns. Of course software is
not necessary to perform an FMEA but does make the task of compiling,
updating and archiving FMEA results considerably easier. An example of
a custom program is provided in the appendix under case study C.
40


CHAPTER 9
PERFORMING A SUCCESSFUL FAILURE MODE EFFECTS ANALYSIS
FMEA is generally developed using a "brainstorming" strategy. A
FMEA is conducted through the following steps:
a) Define the system and the performance requirements.
b) Define assumptions and ground rules to be used in the
analysis.
c) Develop a block diagram, flow chart or schematic of the
subject under analysis.
d) Form a multi-disciplinary team and assign a group leader.
e) Initiate a FMEA brainstorming session.
f) Formalize the results of the FMEA in report form.
g) Develop corrective action strategies
h) Iterate the failure analysis.
The key component of a successful FMEA is the strategic use of
a multi-disciplinary team. A FMEA must not be performed by one
individual unless the scope of the problem is very limited. The use of a
cross functional team allows for a richer and more comprehensive
development of a FMEA and helps to insure that as many if not all failures
of a system or product are identified. Along with a cross functional team
is a block diagram, flow chart or schematic of the product or system
under study. The scope of the failure study can be defined with these
simple illustrative and informative devices and can provide a common
ground for the team to develop the FMEA. As important as the block
diagram and cross functional team are the system performance
requirements. The multi-disciplinary team can assist in developing
appropriate requirements that need to be met. Requirements can be
developed from consumer complaints, historical product or system
performance data or customer supplied requirements. Once the FMEA is
completed, a review locates any deficiencies in the analysis. The final
key item is to re-iterate the process once the corrective action items have
been initiated.
41


FMEA is oftentimes an intense process for defining failures of a
system or product. It is a time intensive project that may involve
thousands of labor hours and generate large amounts of paperwork. It
also depends upon good facilitation skills of the FMEA leader who must
focus the FMEA group, have the ability to draw out the necessary
information from the group and have a clear understanding of the system
and performance requirements.
42


CHAPTER 10
LIMITATIONS OF FAILURE MODE AND EFFECTS ANALYSIS
Although FMEA provides a succinct methodology for examining
failures and providing for corrective action, drawbacks of the method limit
its usage. Common problems encountered in the failure effects analysis
include the following (3, p. 85):
a) The analysis is time consuming and costly.
b) The analysis results and recommendations are often
obtained too late in design to be easily incorporated.
c) Accurate failure data are difficult to obtain.
d) The level of detail necessary for a thorough, economical and
effective analysis is difficult to define accurately.
e) The process of failure analysis is subject to inaccuracies.
f) Agreement of ratings for severity, detectability and
occurrence may be problematic within a group environment.
Except for trivial cases, one can imagine the type of FMEA and the
energy expenditure needed on a substantially complex endeavor such as
designing an aircraft or complex automotive component. A certain
amount of reduction in paperwork is achievable if a FMEA is performed
on basic components and systems and if the scope of the FMEA is
constrained. The lessons from one FMEA can be applied to other
products or systems with similar qualities as well.
Another limitation of the FMEA is that the failure modes are
assumed to be statistically independent; hence a FMEA may over-estimate
system reliability (17, p. 559) (see chapter 6). However, the primary
purpose of a FMEA is the identification of failures which may contribute
the most to a system or product unreliability.
Apart from the technical aspects of FMEA, another element
necessary and critical to efficiently and effectively develop a FMEA is
facilitation skills. FMEA is not a mindless "fill in the blank" process but
one of idea generation. The use of a multi-disciplinary team requires a
group leader with excellent facilitation skills to keep the analysis moving,
43


motivate participants, maintain focus and resolve disagreements. The
facilitator must also be familiar with FMEA development and its relation
to a certain project in order to utilize the full benefit of the group.
44


CHAPTER 11
OTHER TECHNIQUES
Failure Mode and Effects Analysis is one technique for
systematically identifying failures. Other techniques exist such as Fault
Tree Analysis (FTA), a very useful failure development technique
developed in 1961 by Bell Telephone Laboratories to evaluate the
Minuteman Launch Control System. FTA begins with an ultimate failure
effect of interest and a tree of failure causes is developed using Boolean
logic. The analysis continues until only primary events are left. The tree
is then analyzed using algebraic or graph theory principles. The FTA
provides for a depiction of a particular failure and is developed consequent
to a FMEA study.
Other techniques are Matrix FMEA (G.L. Barbour, 1977) which is
based upon a matrix development of failures; Sneak Circuit Analysis
(Boeing, 1967) used in determining failures of an electronic circuit,
pneumatic, hydraulic and mechanical systems and programming logic;
System State Phase Modelling (Tiger, 1969) which uses a logic diagram
to investigate possible states of a system; Tabular Systems Reliability
Analysis (Battelle Laboratories, 1971) which combines elements of fault
tree analysis, Markov techniques and tabular FMEA into an integrated
analysis; Event Sequence Analysis (Yellman, 1975) which traces the
effects of system failures as a function of the order in which they occur;
L.A.M technique (Reina and Squellati, 1980) which uses the physical
properties of a system to evaluate the effects of failure; Approachabiiity
Analysis (Hitachi, 1981) which uses the concept of failures caused by
improper relationships of parts and introduction of external components
or errors into the system and finally, the Failure Combination Method
(French Societe Nationale des Industries Aeronatiques et Spatiaks, 1981)
which examines the effect of single, multiple and externally influenced
failures on a system using an inductive approach.
Techniques for dealing with software and microcomputer
applications also have been developed including software sneak analysis,
integrated hardware/software analysis and integrated critical path
analysis. The above alternate techniques were obtained from Reference
45


(3) which provides a succinct overview of the techniques along with
references.
46


CHAPTER 12
THE FUTURE OF FAILURE MODE AND EFFECTS ANALYSIS
FMEA can be a costly and time consuming activity but, when used
early in a design process, can recoup any up front expenditures by
identifying and correcting failures at a point that is economically
advantageous. FMEA also belongs to the disciplined. FMEA requires a
commitment of time and energy from individuals participating in a FMEA
and their ability to articulate their expertise. FMEA is a tool that allows
the possibility of doing it right the first time versus fixing it a hundred
times later at a much higher cost.
FMEA does not cure all the ills of a product or system. It does
provide one way of listing and examining failures but is by no means the
only method or one that should necessarily be used. FMEA is a
continuous improvement tool that supplements and works with testing
and quality programs to produce the best system or product possible.
47


APPENDIX A
CASE STUDY A
A FMEA OF A PHOENIX MODEL ROCKET RECOVERY SYSTEM
The discussion in this report has focused on the ideas underlying
failure studies as expressed in the use of FMEA. This section will focus
on a simple FMEA study to illustrate the principles.
Estes Industries of Penrose, Colorado, manufactures and sells
model rocket kits. The rockets are of various sizes and complexity and
are made from wood, cardboard and plastic. The rockets use solid fuel
non-reusable engines of various sizes to propel the finished vehicles
upwards of 1500 feet in some cases. The rockets have some type of
recovery system; the most common consisting of a parachute that allows
the rocket to return undamaged so it can be flown again (barring any
losses to trees, power lines, lakes, etc).
One particular model kit is the Phoenix flying model rocket. The
Phoenix is an air-to-air guided missile that is used on fighter aircraft as an
offensive weapon against other aircraft. Unlike the real Phoenix, the 1/9
scale model consists of a recovery system that allows the rocket to be
recovered after flight to be reused again.
The basic operation is rather simple. A disposable pre-
manufactured solid rocket engine is installed in the tail section of the
rocket. The engine is plugged with a nichrome wire which is connected
to an ignition system powered by a series of batteries. The rocket is
placed on a launch pad, a circular metal plate, and fittings (launch lugs)
on the fuselage of the rocket are used to stabilize the rocket on the
platform and during launch via a metal rod. The ignition of the engine is
accomplished by pressing a button on the ignition system which is hand
held from about 10 feet away that heats up the nichrome wire and ignites
the propellent. The rocket lifts off and rapidly accelerates for a period of
time. The thrust then "cuts out" and a coast stage is activated during
which time the rocket glides to its highest altitude (the Phoenix is rated
at a maximum altitude of about 1000 feet) while trailing smoke for
48


tracking by ground personnel. The coast stage then ignites an ejection
charge that disengages the nose cone and separates the recovery system
from the fuselage. The folded parachute is deployed slowing the vehicle
for a gentle landing.
Estes rockets are well proven designs that are reliable and safe to
operate, provided they are built correctly (a process parameter) and are
used as intended. However, in the Phoenix rocket constructed
specifically for this project, modifications to the recovery system were
implemented. The recovery system consists of a parachute and shroud
lines attached to the nose cone and an elastic line called the shock cord
that is attached to the fuselage. The shock cord permits the absorption
of ejection stresses and any residual acceleration to avoid damage to the
recovery system attachment or the fuselage itself. Flame retardant paper
"wadding" protects the recovery system from hot ejection gases. The
wadding is placed between the engine and recovery system in the body
of the rocket.
The standard recovery system uses a plastic parachute with narrow
gauge shroud lines tied to the nose cone and shock cord. This design
was improved with a nylon parachute, heavier shroud lines and the use
of metal O-rings and two types of swivel hooks. The concept behind the
modifications was to prevent problems with shroud and shock cord
entanglements through the use of swivel hooks and melted parachutes
through the use of other materials. Since the design resulted in a product
modification with resultant unknown consequences, a FMEA was
performed.
The first step was to develop a block diagram of the recovery
system which is presented in Figure A.1 along with a statement of the
requirements of the recovery system. The cross hatched blocks represent
new features of the recovery system. The use and development of block
diagrams or process flow diagrams cannot be understated. Any visual
guides provide a common reference point for the FMEA team and often
alleviate conflicts in interpretation of the system or product: a picture
provides the proverbial thousand words. Block diagrams and process flow
diagrams also are useful in further developments of testing programs and
identification of key product or process parameters that may need to be
evaluated or that cannot be controlled but need to be accounted for in a
final analysis.
Once the block diagram was developed, a brainstorming session
followed. In the case of the Phoenix, the author was the sole developer
of the FMEA analysis. A correct approach would be a cross functional
team but for the purposes of this report, a solitary analysis is sufficient
49


Phoenix Recovery System
To provide for safe return (no damage or loss) under normal
flight conditions.
Figure A.1 Phoenix Recovery System Block Diagram


to illustrate the concepts of FMEA.
The results of the failure study are provided on the attached FMEA
sheets under Figures A.2, A.3 and A.4. Other forms such as the ones
listed in the text could have been utilized with similar results.
The values for each component and failure were derived by best
guess and developed on Figure A.2. Once again, if a cross functional
team was utilized the values may be more representative or 'true'.
Nevertheless, for purposes of illustration, the subsequent values for
columns A, B and C and the RPN value will suffice.
Sorting RPN values in Figure A.2 yields the results in figure A.3
with a RPN of 300 occurring with the nylon parachute. These results
indicate that corrective action should begin with items surrounding the
entanglement of the parachute with other components of the recovery
system. The action proposed is to follow the manufacturer's instructions
on packing the parachute correctly with the shroud lines. Using this same
category as an example, current packing of the parachute can be broken
down into a design or process issue as illustrated in Figure A.5. In one
case, packing of the parachute relates to the actual physical activity,
while the other, the design side, asks the question if the manufacturer
design for packing the parachute is correct. This same exercise could be
done for each item on the FMEA. Doing so would double the amount of
paperwork (at least) barring any further items added to the list for
consideration under design or process parameters. In both cases
validation of the design or process parameter might be performed with
pre-flight testing using mock up rocket bodies or other methods of
simulation.
At this point, other items could be considered with high RPN
values, such as burned or flawed shroud lines. Alternatively the analysis
can proceed with those items that may not have a relatively high RPN
value, but very high severity values as shown in Figure A.4.
The FMEA for the Phoenix model rocket is based on the assumption
that the rocket will operate under normal conditions. Normal operation in
this case implies using a certain engine size and flying in favorable
conditions (light wind, no precipitation, etc.). Altering the mission
statement would affect the FMEA analysis. For example, if the mission
were to fly in high winds, the importance of line or parachute
entanglement would be of a higher order and the ability of the McMahon
swivel hooks to rotate to keep the lines untangled would be of greater
importance. Design issues surrounding parachute diameter would also be
included since high winds and large parachutes can carry the rocket out
of a desired operating range. Well defined requirements of the system are
51


Phoenix Recovery System FMEA
Component Mode of Failure Cause of Failure Effect of Failure Frequency Severity Detection RPN Action
1 McMahon Swivel Hook Partial or No Rotation Mis-specified swivel Tangled or twisted lines 5 5 5 125 Larger Hook
2 McMahon Swivel Hook Partial or No Rotation Thermal Expansion Tangled or twisted lines 1 5 10 50 Increase Recovery wadding
3 McMahon Swivel Hook Partial or No Rotation Thermal Expansion Tangled or twisted lines 1 5 10 50 Hook with different properties
4 McMahon Swivel Hook Partial or No Rotation Fouling Tangled or twisted lines 3 5 10 150 Clean/replace after flight
5 McMahon Swivel Hook Partial or No Rotation Fouling Tangled or twisted lines 3 5 10 150 Increase recovery wadding
6 McMahon Swivel Hook Partial or No Rotation High Coeff of ball friction Tangled or twisted lines 1 5 1 5 Lubricate
7 McMahon Swivel Hook Partial or No Rotation High Coeff of ball friction Tangled or twisted lines 1 5 1 5 Replace
8 McMahon Swivel Hook Broken Hooks Stress (overuse) Component Detachment 1 10 5 50 Inspection or replacement
9 McMahon Swivel Hook Broken Hooks Mis-specified Component Detachment 5 10 1 50 Heavier gage hook
10 Nose Cone Swivel Hook Broken Hooks See McMahon Failures None 1 1 1 1
11 Nose Cone Swivel Hook Broken Hooks Stress (overuse) Component Detachment 2 3 6 Inspection or replacement
12 Nose Cone Swivel Hook Broken Hooks Mis-specified Component Detachment 2 3 6 Heavier gaqe hook
13 Shroud Lines Breakage Material Flaw Reduced Recoverability 2 10 5 100 Pre-flight inspection
14 Shroud Lines Breakage Material Flaw Reduced Recoverability 2 10 2 40 Line replacement
15 Shroud Lines Breakage Burned Reduced Recoverability 2 10 5 100 Increase wadding
16 Shroud Lines Breakage Burned Reduced Recoverability 2 10 5 100 Flame retard line
17 Shroud Lines Entanglement Incorrect Pack Reduced Recoverability 4 5 10 200 Pack per mfg. instructions
18 Shroud Lines Entanglement Incorrect line gage Reduced Recoverability 1 5 5 Change line gage
19 Nylon Parachute No deployment Tight pack Reduced Recoverability 2 10 5 100 Pack per mfg. instructions
20 Nylon Parachute No deployment Incorrect Pack Reduced Recoverability 3 10 5 150 Pack per mfg. instructions
21 Nylon Parachute No deployment Burned Reduced Recoverability 10 10 100 Increase wadding
22 Nylon Parachute No deployment Entanglement Reduced Recoverability 3 10 10 300 Pack per mfg. instructions
23 Nylon Parachute Ripped Material Flaw Reduced Recoverability 7 5 35 Inspect
24 Nylon Parachute Ripped Ground Ensnarement Reduced Recoverability 3 7 21 Inspect
25 Nylon Parachute Detachment Line connector missoecified Reduced Recoverability 2 10 5 100 Inspect
26 Nylon Parachute Detachment Connector burned Reduced Recoverability 1 10 10 100 Inspect
27 O-ring Breakage Stress (overuse) Component Detachment 1 10 10 100 Pre-flight inspection
28 O-ring Breakage Mis-specified Component Detachment 1 10 10 100 Heavier gage
29 O-ring Ring Separation Stress (overuse) Component Detachment 1 10 1 10 Pre-flight inspection
30 O-rino Ring Separation Mis-soecified Component Detachment 1 10 1 10 Heavier aaae
Figure A.2 Phoenix Recovery System FMEA
52


Phoenix Recovery System FMEA
Sorted by RPN
Component Mode of Failure Cause of Failure Effect of Failure Frequency Severity Detection RPN Action
22 Nylon Parachute No deployment Entanglement Reduced Recoverability 3 10 10 300 Pack per mfg. instructions
17 Shroud Lines Entanglement Incorrect Pack Reduced Recoverability 4 5 10 200 Pack per mfg. instructions
20 Nylon Parachute No deployment Incorrect Pack Reduced Recoverability 3 10 5 150 Pack per mfg. instructions
4 McMahon Swivel Hook Partial or No Rotation Fouling Tangled or twisted lines 3 5 10 150 Clean/replace after flight
5 McMahon Swivel Hook Partial or No Rotation Fouling Tangled or twisted lines 3 5 10 150 Increase recovery wadding
1 McMahon Swivel Hook Partial or No Rotation Mis-specified swivel Tangled or twisted lines 5 5 5 125 Larger Hook
13 Shroud Lines Breakaqe Material Flaw Reduced Recoverability 2 10 5 100 Pre-flight inspection
15 Shroud Lines Breakage Burned Reduced Recoverability 2 10 5 100 Increase wadding
16 Shroud Lines Breakaqe Burned Reduced Recoverability 2 10 5 100 Flame retard line
19 Nylon Parachute No deployment Tight pack Reduced Recoverability 2 10 5 100 Pack per mfg. instructions
21 Nylon Parachute No deployment Burned Reduced Recoverability 1 10 10 100 Increase wadding
25 Nylon Parachute Detachment Line connector misspecified Reduced Recoverability 2 10 5 100 Inspect
26 Nylon Parachute Detachment Connector burned Reduced Recoverability 1 10 10 100 Inspect
27 O-rinq Breakage Stress (overuse) Component Detachment 1 10 10 100 Pre-flight inspection
28 O-rinq Breakage Mis-specified Component Detachment 1 10 10 100 Heavier gage
8 McMahon Swivel Hook Broken Hooks Stress (overuse) Component Detachment 10 5 50 Inspection or replacement
9 McMahon Swivel Hook Broken Hooks Mis-specified Component Detachment 5 10 1 50 Heavier gaqe hook
2 McMahon Swivel Hook Partial or No Rotation Thermal Expansion Tangled or twisted lines 5 10 50 increase Recovery wadding
3 McMahon Swivel Hook Partial or No Rotation Thermal Expansion Tangled or twisted lines 5 10 50 Hook with different properties
14 Shroud Lines Breakaqe Material Flaw Reduced Recoverability 2 10 2 40 Line replacement
23 Nylon Parachute Ripped Material Flaw Reduced Recoverability 7 5 35 Inspect
24 Nylon Parachute Ripped Ground Ensnarement Reduced Recoverability 3 7 21 Inspect
29 O-rinq Ring Separation Stress (overuse) Component Detachment 10 10 Pre-flight inspection
30 O-rinq Ring Separation Mis-specified Component Detachment 10 1t) Heavier gage
11 Nose Cone Swivel Hook Broken Hooks Stress (overuse) Component Detachment 2 3 6 Inspection or replacement
12 Nose Cone Swivel Hook Broken Hooks Mis-specified Component Detachment 2 3 6 Heavier gage hook
6 McMahon Swivel Hook Partial or No Rotation High Coeff of ball friction Tangled or twisted lines 5 5 Lubricate
7 McMahon Swivel Hook Partial or No Rotation High Coeff of ball friction Tangled or twisted lines 5 5 Replace
18 Shroud Lines Entanglement Incorrect line gage Reduced Recoverability 5 5 Change line gage
10 Nose Cone Swivel Hook Broken Hooks See McMahon Failures None 1 1 1
Figure A.3 Sorted FMEA by RPN
53


Phoenix Recovery System FMEA
Sorted by Severity
Component Mode of Failure Cause of Failure Effect of Failure Freauencv Severity Detection RPN Action
22 Nylon Parachute No deployment Entanglement Reduced Recoverability 3 10 10 300 Pack per mfg. instructions
20 Nylon Parachute No deployment Incorrect Pack Reduced Recoverability 3 10 5 150 Pack per mfg. instructions
13 Shroud Lines Breakaqe Material Flaw Reduced Recoverability 2 10 5 100 Pre-flight inspection
15 Shroud Lines Breakaqe Burned Reduced Recoverability 2 10 5 100. Increase waddina
16 Shroud Lines Breakaqe Burned Reduced Recoverability 2 10 5 100 Flame retard line
19 Nylon Parachute No deployment Tight pack Reduced Recoverability 2 10 5 100 Pack per mfg. instructions
21 Nylon Parachute No deployment Burned Reduced Recoverability 1 10 10 100 Increase waddinq
25 Nylon Parachute Detachment Line connector misspecrfied Reduced Recoverability 2 10 5 100 Inspect
26 Nylon Parachute Detachment Connector burned Reduced Recoverability 1 10 10 100 Inspect
27 O-rinq Breakaqe Stress (overuse') Component Detachment 1 10 10 100 Pre-fliqht inspection
28 O-rinq Breakaqe Mis-specified Component Detachment 1 10 10 100 Heavier qaqe
8 McMahon Swivel Hook Broken Hooks Stress (overuse) Component Detachment 1 10 5 50 Inspection or replacement
9 McMahon Swivel Hook Broken Hooks Mis-specified Component Detachment 5 10 1 50 Heavier qaqe hook
14 Shroud Lines Breakaqe Material Flaw . Reduced Recoverability 2 10 2 40 Line replacement
29 O-ring Ring Separation Stress (overuse) Component Detachment 1 10 1 ' 10 Pre-fliqht inspection
30 O-rinq Ring Separation Mis-specified Component Detachment 1 10 1 1t) Heavier qaqe
23 Nylon Parachute Ripped Material Flaw Reduced Recoverability 1 7 5 35 Inspect
24 Nylon Parachute Ripped Ground Ensnarement Reduced Recoverability 3 7 21 Inspect
17 Shroud Lines Entanglement Incorrect Pack Reduced Recoverability 4 5 10 200 Pack per mfg. instructions
4 McMahon Swivel Hook Partial or No Rotation Fouling Tangled or twisted lines 3 5 10 150 Clean/replace after flight
5 McMahon Swivel Hook Partial or No Rotation Fouling Tangled or twisted lines 3 5 10 150 Increase recovery waddinq
1 McMahon Swivel Hook Partial or No Rotation Mrs-specified swivel Tangled or twisted lines S 5 5 125 Larqer Hook
2 McMahon Swivel Hook Partial or No Rotation Thermal Expansion Tangled or twisted lines 1 5 10 50 Increase Recovery waddinq
3 McMahon Swivel Hook Partial or No Rotation Thermal Expansion Tangled or twisted lines 1 5 10 50 Hook with different properties
6 McMahon Swivel Hook Partial or No Rotation High Coeff of ball friction Tangled or twisted fines 1 5 5 Lubricate
7 McMahon Swivel Hook Partial or No Rotation High Coeff of ball friction Tangled-or twisted lines 1 5 5 Replace
18 Shroud Lines Entangtement Incorrect line gage Reduced Recoverability 1 5 1 5 Change line qaqe
11 Nose Cone Swivel Hook Broken Hooks Stress (overuse) Component Detachment 1 2 3 6 Inspection or replacement
12 Nose Cone Swivel Hook Broken Hooks Mis-specified Component Detachment 1 2 3 6 Heavier qaqe hook
10 Nose Cone Swivel Hook Broken Hooks See McMahon Failures None 1 1 1 1
Figure A.4 Sorted FMEA by Severity
54


PHOENIX RECOVERY SYSTEM FMEA
Component Mode of Failure Cause of Failure Effect of Failure Frequency of Occurence Degree of Severity Chance of Detection Risk Priority Number Process or Design Action Remarks
Nylon Parachute No deployment Entanglement Reduced recoverability 3 10 10 300 p Package per mfg. instructions
No deployment Entanglement Reduced recoverability 1 10 10 100 D Redesign parachute pack
ui
CXI
Figure A.5 Phoenix Recovery System DFMEA and PFMEA


imperative prior to starting a FMEA.
The cursory analysis of the Phoenix recovery system yielded many
failure modes. The values to determine the RPN numbers were not
'scientific' by any means. Nevertheless, the goal of targeting a failure
mode in need of corrective action was met.
56


APPENDIX B
CASE STUDY B
STRATEGIC TEST DESIGN MATRIX
New product development at a beverage company1 in the form of
packaging products (i.e. aluminum cans and lids) prompted the
development of an approach to guarantee that new designs would provide
customer required functionality at time of introduction into the
marketplace. A system was developed to address consumer functionality
requirements based upon the general premises of a classic FMEA but
modified to address management expectations and requirements. A
cross-functional team consisting of representives from the disciplines of
Quality Engineering, Quality Assurance and Research and Development
developed a Strategic Design Matrix (STD) during the Spring of 1996.
The STD matrix provides a "scorecard" to upper management on tracking
and evaluating risk of new products during pre-production or development
stages. The STD is driven by consumer requirements e.g. leaking
container, loss of C02, openability, etc., to better anticipate possible risks
prior to introduction to the field.
The STD matrix is shown in figure B.1. The matrix consists of 12
columns which are largely self explanatory. The key feature of the STD
which has made it successful is the success status column. This column
is coded as green, yellow or red indicating no risk, potential risk and
failure, respectively. The coding is determined by comparing test results
against pre-determined success criteria. For example, a customer
requirement is no container leakage. A possible test would be to ship test
product with control product and evaluate the two samples. If leakage
is found in the test sample and the success criteria states the absence of
leakers, the success status column would be colored red along with a test
reference number or name of the experimenter. On the other hand, if no
1 The company which developed the STD (with the author's assistance) asked not
be to referred to by name in this paper.
57


Strategic Test Design Matrix
Consumer Potential Cause(s) Tests tor Consumer Department Decision Date Risk Probability Proceed to Next
Qualification Issues of Consumer Design (D) or Issues (Design Packaging (Individual Success Success Based on Test Given Test Phase Based on
Passed
Warning (potential risk)
Failed (risk known)
mH
Figure B.1 Strategic Test Design Matrix


leakers are found but the sample size is small, the column may be colored
yellow indicating caution since the small sample may not detect a problem
with a potentially small defect rate (low statistical power). In this
manner, management can quickly glance at the STD matrix and pinpoint
areas of concern via the color coding. Specific points related to risk are
explained under the risk probability given test results column and can be
based on statistical information derived from a test, such as a "p" value
for example. Decision date and proceed to next phase columns allow
management to see how results are affecting project timelines.
The key to success in development of the STD matrix was through
the use of a cross-functional team which not only brainstormed how the
matrix should look like, but also to develop a list of the customer
requirements and failure modes. The STD matrix is a new concept and
work continues on its development. Specifically, the approach needs to
be carried over into production phases of new designs in order to address
possible failures caused by manufacturing variability. Failure modes and
customer requirements at later production stages can be detailed through
the use of a standard FMEA approach with critical elements subsequently
transferred to the STD matrix along with testing requirements. Additional
concerns with the STD matrix are with effectively communicating success
status to a broader group of individuals that may be connected with a
particular development project.
59


APPENDIX C
CASE STUDY C
FMEA COMPUTER IMPLEMENTATION
A wide variety of computer programs exist to accomplish the goals
of a Failure Mode Effects Analysis. Specialized programs can be
developed using a programming language and a compiler. One such
program was developed using Borland's Turbo PASCAL version 6.0.
The structured program developed is called "Failure Mode Effects
Analysis", (executable file designation is FMEA.EXE) and is based on
elements found in MIL-STD-1629A and the book Knowledge Based
Management under the chapter "Failure Mode and Effects Analysis" (26,
p. 132). Specifically, a system is defined and components of the system
are listed with failure modes, causes, probabilities and severities. A risk
priority number is defined as the product of a failure's occurrence and
severity.
The program uses two base screens to develop the analysis. The
first screen, Figure C.1 is used select for data entry, display, sorting and
graphing routines. Selecting the graphing function brings up a second
screen. Figure C.2, to graph elements of a FMEA data file in different
formats. Sorting is accomplished through the screen shown in Figure C.3.
The program allows components of a system to be entered into a
file along with failure mode, failure probability, failure effect, failure
severity, failure cause and calculated component risk as shown in the in
figure C.4. Each component entered is given an identification number.
Currently no corrective action column is included in the software. The
data that is entered provides a quick overview of risk for individual
components when manipulated with the graphics option. The graphics
option will allow the component identification numbers to be graphed on
a criticality matrix as adopted from MIL-STD-1629A or to be broken down
by failure probability, failure severity and overall risk and graphed as a
stem and leaf type plots. Examples of each are shown in Figures C.5,
C.6, C.7 and C.8, respectively, along with a listing of the actual data file
60


RECORD
MANAGER
[I] Input FMEA Data
[D] Display FMEA Table
[G] Graphical Display
[S] Sort FMEA Data
[Q] QUIT THE PROGRAM
Figure C.1 FMEA Data Manipulation Options
Failure Mode Effects Graphing
[C] Criticality Matrix
[0] Stem and Leaf of Occurrence
[S] Stem and Leaf of Severity
[R] Stem and Leaf of Risk
[Q] QUIT ROUTINE
Figure C.2 FMEA Data Graphing Options
Failure Mode Effects Sorting
[P] Sort on Probability
[S] Sort on Severity
[R] Sort on Risk
[I] Sort on ID Nimber
[Q] QUIT ROUTINE
Figure C.3. FMEA Sorting Options
61


Failure Mode Effects Worksheet
Failure Failure Failure
ID Component Mode Prob Effect Severe Cause Risk
1 Engine Misfires 2 Low mpg 2 Dirty Injectors 4
2 Cooling Overheats 4 Engine damage 9 Poor flow 36
3 Exhaust Leaks 2 CO emissions 10 Faulty joints 20
4 Trans SI ips 3
PROB: 1 = Unlikely .. 10 Certain SEVERE: 1 = No Impact .. 10 = High Impact
Figure C.4 FMEA Data Entry Screen
62


+
1 1 I J Criticality
10 + l + 1 Matrix
9 1 + 1 +
1 1 1 1 File
p 8 + 9 5 +
r 1 1 1 1 AUTO
o 7 + +
b 1 1 1 1
a 6 + + System
b 1 1 1 1
i 5 + 11 12 + Autcmob i 1 e
i l 1 1 1
i 4 + 2 +
t 1 t \ 1 Date
y 3 + 6 4 +
I 1 1 1 9/18/1996
2 + 1 1 7 10 3 + 1
1 1 + 1 1 8 1 + 1 1

1 ' 2 3 4 5 6 7 8 9 10
Severity
Failure Mode Effects Surmary
File : AUTO System : Automobile Date : 9/18/1996
ID Ccmponent Failure Mode Prob Failure Effect Severe Failure Cause Risk
1 Engine Misfires 2 Low mpg 2 Dirty injectors' 4
2 Cooling Overheats 4 Engine damage 9 Poor flow 36
3 Exhaust Leaks 2 CO emissions 10 Faulty joints 20
4 Trans Slips 3 Low perform 6 Internal damage 18
5 Steering Play 8 No control 10 T i e rods damaged 80
6 Tires Rapid wear 3 High cost 3 Low pressure 9
7 E1ect Battery wear 2 High cost 3 Shorted wiring 6
8 Air Bag No deployment 1 No safety 10 Defective bag 10
9 Brakes Grab 8 No control 9 Binded linkage 72
10 Cruise No operation 2 No speed cntrl 5 Ccmputer fault 10
11 Body Leaks 5 Wet interior 2 Poor body fit 10
12 Fuel Purp Low psi 5 Uneven run 7 Faulty valve 35
Figure C.5 Criticality Matrix of a FMEA Data Set (by ID)
63


File : AUTO System : Automobile Date : 9/18/1996
Stem and Leaf Matrix
Occurrence
10
7
8 3 1 6 4 2 12 11 9 5
1 2 3 4 5 6 7 8
Not Likely
9 10
Likely
Failure Mode Effects Surrmary
File : AUTO System : Autcmob i1e Date : 9/18/1996
Failure Failure Failure
ID Component Mode Prob Effect Severe Cause Risk
9 Brakes Grab 8 No control 9 Binded linkage 72
5 Steering Play 8 No control 10 Tie rods damaged 80
11 Body Leaks 5 Wet interior Poor body fit 10
12 Fuel Pimp Low psi 5 Uneven run 1 Faulty valve 35
2 Cooling Overheats 4 Engine damage 9 Poor f1ow 36
6 Tires Rapid wear 3 High cost 3 Low pressure 9
4 Trans Si ips 3 Low perform 6 Internal damage 18
3 Exhaust Leaks 2 CO emissions 10 Faulty joints 20
1 Engine Misfires 2 Low mpg 2 Dirty injectors 4
10 Cruise No operation 2 No speed cntrl 5 Computer fault 10
7 Elect Battery wear 2 High cost 3 Shorted wiring 6
8 Air Bag No deployment 1 No safety 10 Defective bag 10
Figure C.6 Stem and Leaf Plot of FMEA Probabilities (by ID)
64


File : AUTO
System : Automobile
Date : 9/18/1996
Stem and Leaf Matrix
Severity
11 7
1 6
+-------+---+
1 2 3
Not Severe
10 4 12
4 5 6 7
8
9 5
2 3
+----+-----+
8 9 10
Severe
Failure Mode Effects Surmary
File : AUTO System : Automobile Date : 9/18/1996
Failure Failure Failure
ID Component Mode Prob Effect Severe Cause Risk
8 Air Bag No deployment 1 No safety 10 Defective bag 10
5 Steering Play 8 No control 10 Tie rods damaged 80
3 Exhaust Leaks 2 CO emissions 10 Faulty joints 20
9 Brakes Grab 8 No control 9 Binded linkage 72
2 Cooling Overheats 4 Engine damage 9 Poor flow 36
12 Fuel Pimp Low psi 5 Uneven run 7 Faulty valve 35
4 Trans Slips 3 Low perform 6 Internal damage 18
10 Cruise No operation 2 No speed cntrl 5 Computer fault 10
6 Tires Rapid wear 3 High cost 3 Low pressure 9
7 Elect Battery wear 2 High cost 3 Shorted wiring 6
1 Engine Misfires 2 Low mpg 2 Dirty injectors 4
11 Body Leaks 5 Wet interior 2 Poor body fit 10
Figure C.7 Stem and Leaf Plot of FMEA Severities (by ID)
65


File : AUTO System : Automobile Date : 9/18/1996
Stem and Leaf Matrix
Risk
7 6 1 11 10 8 4 12 3 2 9 5
1-9 10 -19 20-29 30-39 40-49 50-59 60-69 70-79 80-89 90-100
Low Risk High Risk
Failure Mode Effects Surmary
File : AUTO System : Automobi le Date : 9/18/1996
Failure Failure Failure
ID Component Mode Prob Effect Severe Cause Risk
5 Steering Play 8 No control 10 Tie rods damaged 80
9 Brakes Grab 8 No control 9 Binded linkage 72
2 Cooling Overheats 4 Engine damage 9 Poor flow 36
12 Fuel Pump Low psi 5 Uneven run 7 Faulty valve 35
3 Exhaust Leaks 2 CO emissions 10 Faulty joints 20
4 Trans Slips 3 Low perform 6 Internal damage 18
8 Air Bag No deployment 1 No safety 10 Defective bag 10
11 Body Leaks 5 Wet interior 2 Poor body fit 10
10 Cruise No operation 2 No speed cntrl 5 Computer fault 10
6 Tires Rapid wear 3 High cost 3 Low pressure 9
7 Elect Battery wear 2 High cost 3 Shorted wiring 6
1 Engine Misfires 2 Low mpg O Dirty injectors 4
Figure C.8 Stem and Leaf Plot of FMEA Risk (by ID)
66


used.
The program provides the mechanism to quickly determine high risk
items in a system. The basis behind the analysis relies on standard
methods of developing a FMEA such as determining correct requirements
and operating phases for a system and determination of the level of detail
needed.
A summary of program elements is provided in the following
matrix:
Program Elements for FMEA.EXE
Program (.PAS) Components Function
FMEA Procedure LocateFile Assign a file for data entry, display or manipulation.
Main program driver Key menu items for data input, data file display, data sorting and data graphing.
FMEADATA Procedure AddRecord Input for the FMEA data sheet.
(Unit) Procedure Display Display a FMEA data file.
Procedure Sort Menu options for sorting failure occurrence, failure severity, combined risk or component ID categories.
FMEAMAT (Unit) Procedure GraphSelect Menu options for presenting the data in the form of a criticality matrix or stem and leaf plot for failure occurrence, severity or overall risk.
Procedure GraphDisplay Mechanism for displaying FMEA data in the appropriate user selected formats to the screen.
FMEASORT (Unit) Function Prob_Less_Than Ordering of pairs of failure occurrence values.
Function Severe_Less_Than Ordering of pairs of failure severity values.
Function Risk_Less_Than Ordering of pairs of combined risk values.
Function !D_Less_Than Ordering of pairs of component identification values.
Procedure Quicksort The actual sorting routine. Boolean values from the functions are passed into this procedure for processing.
The source code for the software is listed on the following pages
and includes all the Pascal components used to gather, sort and display
67


data starting with the main program driver. The sorting routine was based
on work developed by Professor Zenas Hartvigson for PASCAL
programming coursework at the University of Colorado at Denver (8). A
degree of editing was necessary in order to properly format the source
code to the report but the overall program is unchanged from the actual
working version.
68


FMEA.PAS
PROGRAM Fmea;
{
PROSPECTUS
This program driver was developed to utilize various program
components to act as a vehicle in performing a Failure Mode Effects
Analysis. Specifically, the units called are
FmeaMat Graphing of FMEA data
FmeaSort Routine for sorting FMEA data files
FmeaData Unit for allowing a user to build a FMEA file
The FMEA format is a modification of the one outlined under
MIL-STD-1629A and the book Knowledge Based Mangement by
Schmidt, Kiemele and Berdine (Air Academy Press, 1996) in order
to provide a fundamental way in which to quickly determine critical
failure modes in a system or process.
AUTHOR
Written by Tony Gojanovic, Summer 1996. Compiled with
Borland Turbo Pascal Version 6.0.
}
USES
Crt,
FmeaMat, {Graphing of FMEA data}
FmeaSort, (Sorts the FMEA data}
FmeaData; {The record manager unit for FMEA data}
^****************************************************j
PROCEDURE LocateFile (VAR Routine,InFile: STRING);
{Prompt the user for the location of the file he/she wishes to process...}
VAR
Key, {Part of pause and data entry routines...}
Answer : CHAR;
69


BEGIN
ClrScr;
Answer : = 'N';
WHILE Answer < > 'Y' DO
BEGIN
TEXTCOLOR(WHITE);
Gotoxy(02,08);
WRITE(OUTPUT,' Please Input The Path And Filename of the file to be
Routine);
Gotoxy(04,10);
TEXTCOLOR(Yellow);
WRITE(OUTPUT/ ->
Gotoxy(29,10);
READLN(INPUT,lnFile);
TEXTCOLOR(WHITE);
REPEAT
Gotoxy(50,12);
WRITE(OUTPUT/ ');
Gotoxy(02,12);
WRITE(OUTPUT,' Your drive\directory\ filename selection is ');
Gotoxy(55,12);
TEXTCOLOR(Yellow);
WRITE(OUTPUT,lnFile);
TEXTCOLOR(WHITE);
Gotoxy(02,13);
WRlTE(OUTPUT,' Is this correct (Y/N)?');
Gotoxy(32,13);
Answer: =ReadKey;
Answer := UPCASE(Answer);
UNTIL (Answer = 'Y') OR (Answer = 'N');
WRITELN(OUTPUT);
END;
TEXTCOLOR(LightGray);
END; {End of procedure LocateFile}
^#*#*************|\zi^|(\j PROGRAM DRIVER******************}
VAR
Endit : BOOLEAN; {Part of looping controls}
Choice,
Continue,
Key : CHAR; {Used in user selections}
70


GraphFile,
RoutineType,
DataFile : STRING; {Tracking of filenames and analysis types}
BEGIN
Endit : = TRUE; {Variable initialization}
Choice: = ';
Key :=";
RoutineType := ';
{Main menu with choices and input prompts}
TEXTBACKGROUND(BLUE);
REPEAT
REPEAT
ClrScr;
TEXTBACKGROUND(BLUE);
TEXTCOLOR(White);
Gotoxy(20,3);
WRITE(OUTPUT/R ECORD MANAGER');
Gotoxy(20,4);
WR1TE(0UTPUT/---------------------------');
TEXTCOLOR(Yellow);
Gotoxy(30,9);
DELAY(150);
WRITE(OUTPUT/[l] Input FMEA Data');
Gotoxy(30,11);
DELAY(150);
WRITE (OUTPUT,' [D] Display FMEA Table');
Gotoxy(30,13);
DELAY! 150);
WRITE(OUTPUT/[G] Graphical Display');
Gotoxy(30,15);
DELAYd 50);
WRITE(OUTPUT,'[S] Sort FMEA Data');
Gotoxy(30,17);
DELAYd 50);
WRITE(OUTPUT/[Q] QUIT THE PROGRAM');
choice: = UPCASE(ReadKey); {Read what key has been pressed -
convert to caps }
UNTIL (Choice = 'D') OR (Choice = 'S') OR (Choice = 'I') OR
(Choice = 'G') OR (Choice = 'Q');
71


ClrScr;
CASE Choice OF {Choices for the program}
T : BEGIN {Input data}
ClrScr;
RoutineType : = 'INPUT';
LocateFile(RoutineType,DataFile);
AddRecord(RoutineType,DataFile);
END;
'D' : BEGIN {Display a data file}
ClrScr;
RoutineType : = 'DISPLAYED';
LocateFile(RoutineType,DataFile);
Display(DataFile);
END;
'S' : BEGIN {Sort a data file}
RoutineType := 'SORTED';
LocateFile(RoutineType,DataFile);
Sort(DataFile);
END;
'G' : BEGIN {Graphing a data file}
RoutineType : = 'CHARTED';
LocateFile(RoutineType,DataFile);
GraphSelect(DataFile);
END;
'O' : BEGIN
Endit : = FALSE;
END;
END;
UNTIL Endit < > TRUE; {End of choices}
END. {End of program driver}
72


FMEADATA.PAS
UNIT FmeaData;
{This unit is utilized for data entry and display}
INTERFACE
TYPE
MasterRecord = RECORD {Defining the record}
System, {The type of system to be studied}
Mission, {The purpose and operating range of the system}
Component, {The components that make up the system}
Failure, {The failure of a specific component}
Cause, {What caused the failure to happen}
Effect : STRING [25]; {The effect system failure}
ID, {A numeric assigned to the component}
FMEADay, {The day on which the FMEA was performed}
FMEAMonth, {The month of the FMEA}
FMEAYear, {The year on which the FMEA was performed}
Occurrence, {The liklihood of the failure}
Severity, {The severity of the failure}
Risk : INTEGER {The combined risk number of
occurrence and severity}
END;
MasterRecordFile = FILE OF MasterRecord;
PROCEDURE AddRecord (VAR Operation,DataSource : STRING);
PROCEDURE Display (DataToDisplay : STRING);
PROCEDURE Sort (DataToSort : STRING);
^************* ****************************************
IMPLEMENTATION
USES
Graph, {Pascal Graphics Unit}
Dos, {Dos unit }
BGIDriv, { all the BGI drivers }
73


BGIFont, { all the BGI fonts }
Crt, {CRT device unit }
FmeaSort; {The sorting unit for the FMEA data sets}
CONST
GraphMode : INTEGER = 0; {Initialize graphics to appropriate
graph mode}
{*****************************************************:
PROCEDURE AddRecord (VAR Operation,DataSource : STRING);
{This procedure is utilized to develop a data file used in the FMEA study}
VAR
key : CHAR; {Used in pausing}
F_Mission, {Variables used in collecting user information}
FSystem,
F_Component,
F_Failure,
F_Effect,
F Cause : STRING [25];
MstrFile : MasterRecordFile;
Mstrlnfo : MasterRecord;
TDay,
TMonth,
TYear,
F Id,
I,
yCount,
F_Occurrence,
F_Severity,
F_Risk : INTEGER;
Finished : BOOLEAN;
BEGIN
yCount : = 8;
FJD : = 1;
F_Component : = '
BEGIN
{Screen formatting and data entry}
ClrScr;
TEXTCOLOR(White);
Gotoxy(23,2);
{Indexing variable}
{Part of screen formatting}
{Used to terminate data entry}
74


WRITE(OUTPUT/Failure Mode Effects Worksheet');
Gotoxy(30,3);
WRITE(OUTPUT,'File Information');
Gotoxy(29,7);
WRITE(OUTPUT,'System : ');
READLN(INPUT,F_System);
Gotoxy(29,9);
WRITE(OUTPUT,'Mission : ');
READLN(INPUT,F_Mission);
REPEAT
Gotoxy(45,11);
ClrEOL;
Gotoxy(25,11);
WRITE(0UTPUT,' Month (1..12) = ');
Gotoxy(45,11);
TEXTCOLOR(White);
READLN(INPUT,TMonth);
UNTIL (TMonth > = 1) AND (TMonth < = 12);
REPEAT
Gotoxy(45,12);
ClrEOL;
Gotoxy(25,12);
WRITE(OUTPUT,' Dated..31) = ');
Gotoxy(45,12);
TEXTCOLOR(White);
READLN(INPUT,TDay);
UNTIL (TDay > = 1) AND (TDay < = 31);
REPEAT
Gotoxy(45,13);
ClrEOL;
Gotoxy(25f13);
WRlTE(OUTPUT,'Year (1996..2100) = ');
Gotoxy(45,13);
READLN(INPUT,TYear);
UNTIL (TYear > = 1996) AND (TYear < = 2100);
Gotoxy(25,24);
WRITEIOUTPUT,'Press Any Key To Continue');
END;
ASSIGN(MstrFile,DataSource);
REWRITE(MstrFile);
REPEAT
75


IF ((yCount = 23) OR (yCount = 8)) THEN
BEGIN
ClrScr;
yCount : = 8;
TEXTBACKGROUND(BLUE);
TEXTCOLOR(White);
Gotoxy(23,2);
WRITE(OUTPUT/Failure Mode Effects Worksheet');
Gotoxy(23,3);
WRITEIOUTPUT,'--------------------');
Gotoxyd ,6);
WRITE(OUTPUT,'ID');
Gotoxy(4f6);
WRITE(OUTPUT/Component');
Gotoxyd 7,5);
WRITE(OUTPUT/Failure');
Gotoxyd 7,6);
WRITE(OUTPUT,' Mode ');
Gotoxy(30,6);
WRITE(OUTPUT,'Prob');
Gotoxy(38,5);
WRITE(OUTPUT,'Failure');
Gotoxy(38,6);
WRITE(OUTPUT,'Effect');
Gotoxy(50,6);
WRITE(OUTPUT,'Severe');
Gotoxy(62,5);
WRITE(OUTPUT,'Failure');
Gotoxy(62,6);
WRITE(OUTPUT,' Cause');
Gotoxy(75,6);
WRITE(OUTPUT,'Risk');
Gotoxyd ,7);
WRITE(OUTPUT,'------------------------------------------');
TEXTCOLOR(Yellow);
Gotoxy(2,24);
WRITE(OUTPUT,'PROB: 1 = Unlikely .. 10 = Certain SEVERE: 1 =
No Impact .. 10 = High Impact');
END;
TEXTCOLOR(LightCyan);
Gotoxyd ,y Count);
76


WRITE(OUTPUT,F_ID);
Gotoxy(4,yCount);
READLN (INPUT, FComponent);
IF F_Component < > '*' THEN {Termination of data entry}
BEGIN
Gotoxyd 5,yCount);
READLN(INPUT,F_Failure);
REPEAT
Gotoxy(31 ,yCount);
ClrEOL;
READLN(INPUT,F_Occurrence);
UNTIL (F_Occurrence > = 1) AND (F Occurrence < = 10);
Gotoxy(37,yCount);
READLN(INPUT,F_Effect);
REPEAT
Gotoxy(52,yCount);
ClrEOL;
READLN(INPUT,F_Severity);
UNTIL (FSeverity > = 1) AND (FSeverity < =10);
Gotoxy(58,yCount);
READLN(INPUT,F_Cause);
F_Risk := F_Occurrence*F_Severity;
Gotoxy(76,yCount);
WRITE(OUTPUT,F_Risk);
yCount : = yCount + 1;
ASSIGN(MstrFile,DataSource);
RESET(MstrFile);
SEEK(MstrFile,FILESIZE(MstrFile)); {Appending of the file}
Mstrlnfo.System := F_System;
Mstrlnfo.Mission := F_Mission;
Mstrlnfo.ID : = F id;
Mstrlnfo.Component : = F_Component;
Mstrlnfo.Failure : = F_Failure;
Mstrlnfo.Occurrence : = F Occurrence;
Mstrlnfo.Effect : = F Effect;
Mstrlnfo.Cause : = F_Cause;
Mstrlnfo.Severity : = F Severity;
Mstrlnfo.Risk : = F_Risk;
Mstrlnfo.FMEADay : = TDay;
Mstrlnfo.FMEAMonth : = TMonth;
Mstrlnfo.FMEAYear : = TYear;
77


WRITE(MstrFile,Mstrlnfo);
FJd : = FJd + 1;
CLOSE (MstrFile);
END;
UNTIL (F_Component =
END; {End of procedure AddRecord}
j****************************************************j
PROCEDURE Display {DataToDisplay : STRING);
{Procedure display opens a FMEA data file and displays the contents to
screen}
VAR
TempFile : MasterRecordFile; {The FMEA file...}
ContinueChoice,
Key : CHAR;
Rec : MasterRecord;
RecordNumber,
Counter,
RecordNo,
yCount,
I : INTEGER;
{Part of pause}
{The record structure}
{Part of screen formatting}
{Used to read record number}
{Part of screen formatting}
BEGIN
RecordNo : = 0; {Variable initialization}
RecordNumber := 0;
Counter : = 1;
yCount : = 9;
Counter : = 0;
ASSIGN (TempFile, DataToDisplay); {Assigning the file to be opened}
RESET (TempFile);
REPEAT
SEEK (TempFile, RecordNo);
READ (TempFile, Rec);
IF ((yCount = 23) or (yCount = 9)) THEN
BEGIN
ClrScr;
yCount : = 9; {Screen formatting}
TEXTBACKGROUND(BLUE);
TEXTCOLOR(White);
Gotoxy(23,1);
WRITE(OUTPUT,'Failure Mode Effects Summary');
78


Gotoxy(23,2);
WRITE(OUTPUT,'---------------------');
Gotoxy(10,4);
WRITE(OUTPUT/File : ',DataToDisplay);
Gotoxy(30,4);
WRITE(OUTPUT,'System : ',Rec.System);
Gotoxy(55,4);
WRITE(0UTPUT,'Date:',Rec.FMEAMonth,7',
Rec.FMEADay,7'fRec.FMEAYear);
Gotoxy(1,7);
WRITE(OUTPUT,'ID');
Gotoxy(4,7);
WRITE(OUTPUT/Component');
Gotoxy(17,6);
WRITEIOUTPUT/Failure');
Gotoxy(17,7);
WRITE(OUTPUT,' Mode ');
Gotoxy(30,7);
WRITE(OUTPUT,'Prob');
Gotoxy(38,6);
WRITECOUTPUT/Failure');
Gotoxy(38,7);
WRITE (OUTPUT,' Effect');
Gotoxy(50,7);
WRITE(OUTPUT,'Severe');
Gotoxy(62,6);
WRITE(OUTPUT,'Failure');
Gotoxy(62,7);
WRITE(OUTPUT,' Cause');
Gotoxy(75,7);
WRITE(OUTPUT,'Risk');
Gotoxy(1,8);
WRITE(OUTPUT,'------------------------------------------');
TEXTCOLOR(Yellow);
END; {End of formatting}
BEGIN {Beginning of data file reading and display}
WITH Rec DO
BEGIN
TEXTCOLOR(LightCyan);
Gotoxy(1 ,yCount);
WRITE(OUTPUT,ID:2);
79


Gotoxy(4,yCount);
WRITE(OUTPUT,Component);
Gotoxy( 15,yCount);
WRITE(OUTPUT, Failure);
Gotoxy(31 ,yCount);
WRITE(OUTPUT,Occurrence);
Gotoxy(37,yCount);
WRITE(OUTPUT,Effect);
Gotoxy(52fyCount);
WRITE(OUTPUT,Severity);
Gotoxy(58,yCount);
WRITE(OUTPUT,Cause);
Gotoxy(76,yCount);
WRITE(OUTPUT,Risk);
RecordNo : = RecordNo + 1;
yCount : = yCount + 1;
END;
END;
IF yCount = 23 THEN '
key : = Readkey;
UNTIL EOF(TempFile);
CLOSE(TempFile);
key : = Readkey;
END;{End of procedure Display}
^* ************************************************** *^
PROCEDURE Sort {DataToSort : STRING);
{Procedure Sort prompts the user to sort an FMEA file !on various
columns}
{Calls on the unit FMEASort}
VAR
Choice, {Variables for screen formatting and prompts}
TypeSort,
key : CHAR;
EndRoutine : BOOLEAN;
I : INTEGER;
BEGIN
EndRoutine : = TRUE;
REPEAT
REPEAT
80


ClrScr;
TEXTBACKGROUND(BLUE);
TEXTCOLOR(White);
Gotoxy(23,3);
WRITE(OUTPUT/Failure Mode Effects Sorting');
Gotoxy(23,4);
WRITE(OUTPUT,'---------------------');
Gotoxy(23,7);
WRITE(OUTPUT,'[P] Sort on Probability');
Gotoxy(23,9);
WRITE(OUTPUT,'[S] Sort on Severity');
Gotoxy(23fT1);
WRITE(OUTPUT,'[R] Sort on Risk');
Gotoxy(23,13);
WRITE(OUTPUT,'[l] Sort on ID Number');
Gotoxy(23,15);
WRITE(OUTPUT,'[Q] QUIT ROUTINE');
choice: =UPCASE(ReadKey); {Read what key has been pressed}
UNTIL (Choice = 'P') OR (Choice = 'S') OR (Choice = 'R')
OR (Choice = 'I') OR (Choice = 'Q');
CASE Choice OF
'P' : BEGIN (Sort on failure occurrence}
ClrScr;
gotoxy(25,12);
TextColor(Yellow);
WRITE(OUTPUT,'Sorting ',DataToSort/ on Probability');
QuickSort(DataToSort,Prob_Less_Than);
FOR I : = 1 TO 15 DO
BEGIN
Gotoxy(25 + l,14);
WRITE(OUTPUT,'.');
DELAY(TOO);
END;
Gotoxy(25,16);
WRITE(OUTPUT,'Press Any Key To Continue');
key : = Readkey;
END;
'S' : BEGIN {Sort on failure severity}
ClrScr;
gotoxy(25,12);
81


TextColor(Yellow);
WRITE(OUTPUT/Sorting ',DataToSort,' on Severity');
QuickSort(DataToSort,Severe_Less_Than);
FOR I := 1 TO 15 DO
BEGIN
Gotoxy(25 + l,14);
WRITE(OUTPUT/.');
DELAY! 100);
END;
Gotoxy(25f 16);
WRITE(OUTPUT/Press Any Key To Continue');
key : = Read key;
END;
'R' : BEGIN {Sort on combined risk value}
ClrScr;
gotoxy(25,12);
TextColor(Yellow);
WRITE(OUTPUT,'Sorting ',DataToSort,' on Risk');
QuickSort(DataToSort,Risk_Less_Than);
FOR I : = 1 TO 15 DO
BEGIN
Gotoxy(25 + l,14);
WRITE(OUTPUT,'.');
DELAY! 100);
END;
Gotoxy!25,16);
WRITE(OUTPUT,'Press Any Key To Continue');
key : = Readkey;
END;
'l' : BEGIN {Sort on component ID}
ClrScr;
gotoxy(25,12);
TextColor(Yellow);
WRITE(0UTPUT,'Sorting ',DataToSort,' on ID Number');
QuickSort(DataToSort,ID_Less_Than);
FOR I := 1 TO 15 DO
BEGIN
Gotoxy(25 + I,14);
WRITEtOUTPUT,'.');
DELAY! 100);
END;
82


Gotoxy(25,16);
WRITE(OUTPUT/Press Any Key To Continue');
key : = Read key;
END;
'Q' : BEGIN
EndRoutine : = FALSE;
END;
END;
UNTIL EndRoutine < > TRUE;
END; {End of procedure Sort}
^****************************************************
BEGIN
END.
83


FMEAMAT.PAS
UNIT FmeaMat;
{This unit is used for graphing of failure mode data obtained in FmeaData)
INTERFACE
TYPE
MasterRecord = RECORD {Defining the record)
System, {The type of system to be studied)
Mission, {The purpose and operating range of the system)
Component, {The components that make up the system)
Failure, {The failure of a specific component)
Cause, {What caused the failure to happen)
Effect : STRING [25]; {The effect system failure)
ID, {A numeric assigned to the component)
FMEADay, {The day on which the FMEA was performed)
FMEAMonth, {The month of the FMEA)
FMEAYear, {The year on which the FMEA was performed)
Occurrence, {The liklihood of the failure)
Severity, {The severity of the failure)
Risk : INTEGER {The combined risk number of
occurrence and severity)
END;
MasterRecordFile = FILE OF MasterRecord;
PROCEDURE GraphDisplay (DataFile : STRING; Routine : CHAR);
PROCEDURE GraphSelect (VAR DataFile : STRING);
p****************************************************
IMPLEMENTATION
USES
Graph, {Pascal Graphics Unit)
Dos, {Dos unit }
BGIDriv, {all the BGI drivers )
BGIFont, {all the BGI fonts )
FmeaSort, {Sort routine for FMEA data)
Crt; {CRT device unit }
CONST
GraphMode : INTEGER = 0; {Initialize graphics to appropriate
84


graph
mode}
|****************************************************
PROCEDURE GraphSelect (VAR DataFile : STRING);
{Screen displays to prompt the user for a graphing selection}
VAR
Choice, {Variables used in screen formatting and prompts}
TypeSort,
GraphRoutine,
key : CHAR;
EndRoutine : BOOLEAN;
I : INTEGER;
BEGIN
EndRoutine : = TRUE;
REPEAT
REPEAT
{Screen formatting and options}
ClrScr;
TEXTBACKGROUND(BLUE);
TEXTCOLOR(White);
Gotoxy(23,3);
WRITE(OUTPUT/Failure Mode Effects Graphing');
Gotoxy(23,4);
WRITE(OUTPUT,'--------------------');
Gotoxy(23,7);
WRITE(OUTPUT,'[C] Criticality Matrix');
Gotoxy(23,9);
WRITE(OUTPUT,'[0] Stem and Leaf of Occurence');
Gotoxy(23,11);
WRITE(OUTPUT,'[Sl Stem and Leaf of Severity');
Gotoxy(23,13);
WRITE(OUTPUT,'[R] Stem and Leaf of Risk');
Gotoxy(23,15);
WRITE(OUTPUT,'[Q3 QUIT ROUTINE');
choice: = UPCASE(ReadKey); {Read what key has been pressed -
convert to caps}
UNTIL (Choice = 'C') OR (Choice = 'O') OR (Choice = 'S')
OR (Choice = 'R') OR (Choice = 'Q');
85


CASE Choice OF
'C' : BEGIN {Criticality graph}
GraphRoutine := 'C';
GraphDisplay (DataFite,GraphRoutine);
END;
'O' : BEGIN {Stem and Leaf of failure occurrence}
GraphRoutine : = 'O';
GraphDisplay (DataFile,GraphRoutine);
END;
'S' : BEGIN {Stem and Leaf of failure severity}
GraphRoutine : = 'S';
GraphDisplay (DataFile,GraphRoutine);
END;
'R' : BEGIN {Stem and Leaf of combined risk measure}
GraphRoutine := 'R';
GraphDisplay (DataFile,GraphRoutine);
END;
'Q' : BEGIN {Quit the routine}
EndRoutine : = FALSE;
END;
END;
UNTIL EndRoutine < > TRUE;
END; {End of procedure GraphSelect}
^****************************************************j
PROCEDURE GraphDisplay (DataFile: STRING; Routine : CHAR);
{Procedure to display failure data in different modes}
VAR
TempFile : MasterRecordFile;
Key : CHAR;
Rec : MasterRecord;
I, {Variables for screen formatting and display}
J,
K,
L,
Occ,
Sev,
R,
y1 ,y2,y3,y4,y5,y6,y7,y8,y9,y 10,
x1 ,x2,x3,x4,x5,x6,x7,x8,x9,x10,
86


xAxis,
yAxis,
Index,
xCount,
yCount,
Spacer,
pCount,
RecordNo : INTEGER;
BEGIN
ClrScr;
xCount : = 11;
RecordNo : = 0;
I : = 0;
Index : = 0;
Spacer : = 0;
yCount := 1;
pCount := 10;
yi = 18;
y2 = 18;
y3 = 18;
y 4 = 18;
y5 = 18;
y6 = 18;
y7 = 18;
ys = 18;
y9 = 18;
y10: = 18;
{Variable initialization}
CASE Routine OF
X' : BEGIN
{Criticality} ClrScr; {Formatting the criticality matrix}
{Matrix} FOR Spacer : = 1 TO 2 DO
BEGIN
FOR I : = 11 TO 65 DO
BEGIN
Gotoxyd,yCount);
WRITE(OUTPUT/-');
END;
FOR I := 1 TO 12 DO
87


BEGIN
Gotoxy(xCount,yCount);
WRITE(OUTPUT,' +');
xCount : = xCount + 5;
END;
xCount : = 11;
yCount : = 23;
END;
FOR Spacer : = 2 TO 22 DO
BEGIN
Gotoxyd 1,Spacer);
WRITEfOUTPUT/ ]');
Gotoxy (66,Spacer);
WRITE(OUTPUT/|');
END;
yCount : = 3;
FOR I : = 1 TO 10 DO
BEGIN
Gotoxyd 1,y Count);
WRITE(OUTPUT/ +');
Gotoxy (8,yCount);
WRITE(OUTPUT,pCount);
Gotoxy (66,yCount);
WRITE(OUTPUT,' + ');
pCount : = pCount 1;
yCount : = yCount + 2;
END;
xCount : = 16;
FOR J := 1 TO 10 DO
BEGIN
Gotoxy(xCount,24);
WRITE(OUTPUT,J);
xCount : = xCount + 5;
END;
Gotoxy(3,7);
WRITE(OUTPUT,'P');
Gotoxy (3,8);
WRITE(OUTPinyr');
Gotoxy (3,9);
WRITE(OUTPUT,'o');
Gotoxy(3,10);
88


WRITE(OUTPUT,'b');
Gotoxy(3,11);
WRITE(OUTPUT/a');
Gotoxy(3,12);
WRITE(OUTPUT,'b');
Gotoxy(3,13);
WRITE(OUTPUT,'i');
Gotoxy(3,14);
WRITE(OUTPUT,T);
Gotoxy(3,15);
WRITE(OUTPinyi');
Gotoxy(3,16);
WRITE(OUTPUT,'t');
Gotoxy(3,17);
WRITE(OUTPUT,'y');
Gotoxy(69,2);
WRITE(OUTPUT,'Criticality');
Gotoxy(69,3);
WRITE(OUTPUT,'Matrix');
Gotoxy(35,25);
WRlTE(OUTPUT,'Severity');
QuickSort(DataFile,ID_Less_Than); {Sorting on ID}
ASSIGN (TempFile, DataFile); {Assigning the data file}
RESET(TempFile);
SEEK (TempFile, 1);
READ (TempFile, Rec);
Gotoxy(69,6);
WRITE(OUTPUT,'File');
Gotoxy(69,7);
WRITE(OUTPUT,'--------');
Gotoxy(69,8);
WRITE(OUTPUT,Datafile);
Gotoxy(69,11);
WRITE(OUTPUT,'System');
Gotoxy(69,12);
WRITE(OUTPUT,'--------');
Gotoxy(69,13);
WRITE(OUTPUT,Rec.System);
Gotoxy(69,16);
WRITE(OUTPUT,'Date');
Gotoxy(69,17);
89


WRITE(OUTPUT/---------');
Gotoxy(69,18);
WRITE(OUTPUT,Rec.FMEAMonth,'/',
Rec.FMEADay,'/',Rec.FMEAYear);
yCount : = 23;
xCount : = 11;
RESET (TempFile);
REPEAT {Display all ID numbers on the matrix}
SEEK (TempFile, RecordNo);
READ (TempFile, Rec);
WITH Rec DO
BEGIN
Occ : = Occurrence;
Sev : = Severity;
xCount := xCount + (5 *Sev);
yCount := yCount-(2*Occurrence);
Gotoxy (xCount,yCount);
WRITE(OUTPUT,ID);
RecordNo : = RecordNo + 1;
yCount : = 23;
xCount : = 11;
END;
UNTIL EOF(TempFile);
CLOSE(TempFile);
key : = Readkey;
END; {End of display for all ID numbers}
'0','SVR' : BEGIN
{Stem and Leaf} Gotoxy(30,5);
{Plots} WRITE(OUTPUT,'Stem and Leaf Matrix');
CASE Routine OF
'O' : BEGIN {Failure occurrence display}
Gotoxy(16,19);
WRITE(OUTPUT,'+ + + + +
+ + + + + ');
Gotoxy(16,20);
WRITE(OUTPUT,'1 2 3 4 5
6 7 8 9 10');
Gotoxy(36,7);
WRITE(OUTPUT,'Occurence');
Gotoxy (13,22);
WRITE(OUTPUT,'Not Likely');
90


Gotoxy(60,22);
WRITE(OUTPUT/Likely');
END;
'S' : BEGIN {Failure severity display}
Gotoxy{16,19);
WRITE(OUTPUT,' + + + + +
++++ + ');
Gotoxyd 6,20);
WRITE(OUTPUT/1 2 3 4 5
6 7 8 9 10');
Gotoxy(36,7);
WRITE(OUTPUT,'Severity');
Gotoxyd 3,22);
WRITE(OUTPUT,'Not Severe');
Gotoxy(60,22);
WRITE(OUTPUT,'Severe');
END;
'R' : BEGIN {Combined risk number display}
Gotoxy(6,19);
WRITE(OUTPUT,' +----+-----+-----+----+
----+----+-----+-----+
----1----1-');
Gotoxy(6,20);
WRITE(OUTPUT,' 1-9 10-19 20-29 30-39
40-49 50-59 60-69 70-79
80-89 90-100');
Gotoxy(36,7);
WRITE(OUTPUT,' Risk');
Gotoxy(6,22);
WRITE(OUTPUT,'Low Risk');
Gotoxy(69,22);
WRITE(OUTPUT,'High Risk');
END;
END; {End of graphical screen formatting}
QuickSort(DataFile,ID_Less_Than); {Sort on ID numbers}
ASSIGN (TempFile, DataFile);
RESET (TempFile);
REPEAT
SEEK (TempFile, RecordNo);
READ (TempFile, Rec);
Gotoxyd 0,2);
91


WRITE(OUTPUT/File : ',DataFile);
Gotoxy{30,2);
WRITE(OUTPUT,'System : ',Rec.System);
Gotoxy(55,2);
WRITE(OUTPUT,'Date : '.Rec.FMEAMonth,'/',
Rec.FMEADay,'/',Rec.FMEAYear);
WITH Rec DO
BEGIN
CASE Routine OF
'O' : BEGIN {Display component ID occ}
Occ : = Rec.Occurrence;
CASE Occ OF
1 : BEGIN
x1 := 15;
Gotoxy(x1,y1);
WRITE(OUTPUT,ID:2);
y1 := y1 1;
END;
2 : BEGIN
x2 : = 20;
Gotoxy(x2,y2);
WRITE(OUTPUT,ID:2);
y2 := y2- 1;
END;
3 : BEGIN
x3 : = 25;
Gotoxy(x3,y3);
WRITE(OUTPUT,ID:2);
y3 : = y3 1;
END;
4 : BEGIN
x4 : = 30;
Gotoxy(x4,y4);
WRITE(OUTPUT,ID:2);
y4 : = y4 1;
END;
5 : BEGIN
x5 : = 35;
Gotoxy(x5,y5);
WRITE(OUTPUT,ID:2);
y5 := y5 1;
92


Full Text

PAGE 1

AN INTRODUCTION TO FAILURE MODE AND EFFECTS ANALYSIS (FMEA) by Anthony Gojanovic B.A., University of Colorado, 1987 A thesis submitted to the University of Colorado at Denver in partial fulfillment of the requirements for the degree of Master of Basic Science 1996

PAGE 2

This thesis for the Master of Basic Science degree by Anthony Gojanovic has been approved by Date

PAGE 3

Gojanovic, Anthony (M.B.S) An Introduction to Failure Mode and Effects Analysis (FMEA) Thesis directed by Professor Karen Kafadar ABSTRACT Failure Mode and Effects Analysis (FMEA) is a developmental tool used to identify failures and effects on systems, products or services. In addition to identifying failure modes and failure mode effects, FMEA provides for quantification and categorization of failure information in order to allocate and prioritize resources for risk abatement. The greatest impact of FMEA is in pre-production phases of new product or system development in order to provide for failure free systems and products during implementation. FMEA is a versatile tool that has many expressions and can be integrated with statistical and software tools to provide for a comprehensive view of risk. This abstract accurately represents the content of the candidate's thesis. I recommend its publication. KareflKafadar

PAGE 4

CONTENTS Figures .......................................... vii CHAPTER 1. INTRODUCTION . . . . . . . . . . . . . 1 Failure Study Motivations . . . . . . . . . 3 Correct Solution, Wrong Problem? . . . . . 3 I Need It Now and I Need It Perfect! . . . . 5 2. ORIGINS OF FAILURE MODE AND EFFECTS ANALYSIS (FMEA) . . . . . . . 7 3. FAILURE MODE AND EFFECTS ANALYSIS (FMEA) . 11 Tabular FMEA . . . . . . . . . . . . . 11 Failure Mode Effects and Criticality Analysis . . . 14 4. FAILURE MODE AND EFFECTS ANALYSIS FOR MANUFACTURING . . . . . . . . . . 23 iv

PAGE 5

Process and Design FMEA . . . . . . . . . 27 5. FAILURE MODE AND EFFECTS ANALYSIS AND SOFTWARE DEVELOPMENT .............. 29 6. STATISTICAL BASIS OF THE FMEA WORKSHEET ....................... 31 7. FAILURE MODE EFFECTS ANALYSIS INTEGRATION ........................... 33 Surveys ............................... 33 Reliability Analysis . . . . . . . . . . . 34 Linear Models . . . . . . . . . . . . . 35 Exploratory Techniques . . . . . . . . . . 37 Statistical Process Control . . . . . . . . . 37 8. FAILURE MODE AND EFFECTS ANALYSIS TERMINOLOGY . . . . . . . . . . . . . 39 FMEA Formats . . . . . . . . . . . . . 39 9. PERFORMING A SUCCESSFUL FAILURE MODE EFFECTS ANALYSIS . . . . . . . . . 41 v

PAGE 6

10. LIMITATIONS OF FAILURE MODE AND EFFECTS ANALYSIS . . . . . . . . . 43 11. OTHER TECHNIQUES . . . . . . . . . . . 45 12. THE FUTURE OF FAILURE MODE APPENDIX A. AND EFFECTS ANALYSIS . . . . . . . . . 47 CASE STUDY A: A FMEA OF A PHOENIX MODEL ROCKET RECOVERY SYSTEM 48 B. CASE STUDY B: STRATEGIC TEST DESIGN MATRIX ............ 57 C. CASE STUDY C: FMEA COMPUTER IMPLEMENTATION . . . . . 60 FMEA.PAS . . . . . . 69 FMEADATA.PAS ........ 73 FMEAMAT.PAS . . . . 84 FMEASORT.PAS . . . 100 BIBLIOGRAPHY .................................. 106 vi

PAGE 7

Figure 1 .1 Figure 1.2 Figure 3.1 Figure 3.2 Figure 3.3 Figure 3.4 Figure 3.5 Figure 4.1 Figure 4.2 Figure 7.1 Figure A.1 FIGURES Quality Lever . . . . . . . . . . . . 2 Change Comparison ... : . . . . . . . . 2 Tabular FMEA . . . . . . . . . . . 12 Failure Mode and Effects Worksheet .for Task 101 in MIL-STD-1629A .......... 15 Criticality Analysis for Task 102 in MIL-STD-1629A (Quantitative Method) . . . 16 Criticality Analysis for Task 102 in MIL-STD-1629A (Qualitative Method) . . . 20 Criticality Matrix . . . . . . . . . . 21 FMEAC for New Product Development . . . 24 FMEAC for New Product Development with Corrected RPN . . . . . . . . . . . 26 Life Cycle Hazard Function . . . . . . . 36 Phoenix Recovery System Block Diagram 50 vii

PAGE 8

Figure A.2 Phoenix Recovery System FMEA . . . . . 52 Figure A.3 Sorted FMEA by RPN . . . . . . . . . 53 Figure A.4 Sorted FMEA by Severity . . . . . . . 54 Figure A.5 Phoenix Recovery System DFMEA and PFMEA Example . . . . . . . . . 55 Figure 8.1 Strategic Test Design Matrix . . . . . . 58 Figure C.1 FMEA Data Manipulation Options . . . . . 61 Figure C.2 FMEA Data Graphing Options . . . . . . 61 Figure C.3 FMEA Sorting Options . . . . . . . . 61 Figure C.4 FMEA Data Entry Screen . . . . . . . 62 Figure C.5 Criticality Matrix of a FMEA Data Set . . . 63 Figure C.6 Stem and Leaf Plot of FMEA Probabilities . . 64 Figure C.7 Stem and Leaf Plot of FMEA Severities . . . 65 Figure C.8 Stem and Leaf Plot of FMEA Risk . . . . . 66 viii

PAGE 9

CHAPTER 1 INTRODUCTION Current criteria for the success of consumer goods rely upon product introductions that are as failure free as possible. The costs associated with defective products from a liability or lost consumer standpoint can have dramatic impacts on a company. In a business environment that is becoming extremely competitive and global, the presence of failures in a system, product or service, can only serve to destabilize a company financially. Indeed, many companies have failed due to the inability of providing a product that is able to meet basic customer expectations and requirements. The definition of failure is the inability of a system or product to meet a required function. Failures can be dramatic and sudden or subtle and gradual resulting in system or product degradation. Defective consumer products from common household appliances to much publicized automotive recalls have impacted from a few to millions of individuals. Not only product failure but even breakdowns in a service are potentially damaging. A misdiagnosed patient in a hospital as a result of a communication failure can be harmful to the patient and to the reputation of the hospital itself. With increasing technological sophistication, the problem of finding and correcting failures is becoming more complex and at the same time increasingly imperative. The need for "first pass manufacturing", in which a product or service has been made failure free prior to widespread implementation, is critical. No longer are product recalls or field fixes feasible, desirable or cost effective. Figure 1.1 shows the cost associated with fixing problems as time progresses through a new product development cycle (7, p. 170) and Figure 1.2 compares U.S. vs Japanese company changes through a development cycle (7, p. 172). Changes made later in the design cycle are not only expensive but give away any competitive edge. With increasing technological sophistication, requirements for failure free products are becoming more stringent, and for reasons. For example, if a 0.1% failure level were allowed in the United States, the 1

PAGE 10

PAYOFFS Figure 1.1 i 0 :: w w I Quality Lever USCOMP"2 Change Figure 1. Comparison 2

PAGE 11

following would occur (29, p. xxvi): -Two unsafe landings at O'Hare Airport per day. -12 babies given to the wrong parents each day. 880,000 credit card magnetic strips with wrong information. 5,517,200 cases of flat soft drinks produced per year. -Two million documents lost by the IRS each year. Given the need for systems and products that are as failure free as possible, tools for identifying failures and correcting them are needed. It is the scope of this paper to discuss one such tool for identifying failures, their effects, causes, and how a failure analysis can provide guidance in the development of corrective action and risk abatement strategies. Failure Study Motivations The motivations for developing failure examination methods can best be developed through the following examples taken from the author's experience in commercial manufacturing. Correct Solution. Wrong Problem? The first case involved the development of a statistical model to determine the risk associated with the implementation of an existing product that was modified in order to realize a cost savings. The risk was to be expressed through an anticipated nonconforming product rate that would be encountered once production of the "new" product began. The model itself was based as a linear combination of two independent variables in order to determine the probability that a certain pre determined threshold value (measured as a differential between two independent product components) for a certain failure mode would not be exceeded. Specifically, the model used was of the form 3

PAGE 12

The data for the model was obtained through limited scale experimentation using modified product components that were of interest. The study was planned carefully to minimize unnecessary variability and to insure that basic statistical assumptions were met through the use of randomized testing. The subsequent data were exceptional in the sense of being symmetric and without large outlying values as interpreted through exploratory techniques such as histograms and boxplots. The appropriate parameters were plugged into the model and an estimate of the expected probability that a nonconforming product would occur was obtained. The probability, p, of a nonconforming product, was rated against the manufacturing plant's output. The resultant rate was deemed to be inconsequential and therefore the risk of implementation was considered low. Thus a risk assessment based on an appropriate statistical technique was developed early in the design stages to provide confidence that costly process and product adjustments would not occur during implementation nor at any time during full production of the "new" product in question. However, once implementation of the modified product was started, nonconforming product began to surface. At this point, the original model, the underlying assumptions, and data were examined. Nothing was found to be wrong with the development or interpretation of the model. In some ways, the model development was considered to be "textbook" ideal. If so why were problems appearing? The answer was with the failure mode itself. The original risk assessment was developed for a certain type of failure mode. The failure mode that occurred during implementation was different. No consideration was given to alternate failure modes that could occur due to the modifications. As a result, resources were allocated to define the risk associated with only one particular failure mode, one which happened to be of lesser consequence. Consequently, problems with the actually observed failure mode had to be handled in a hasty fashion that resulted in increased interpersonal tensions and high testing cost. 4

PAGE 13

I Need It Now and I Need It Perfect! Another instance that motivated the need to find ways of looking at product failure involved the development of a new product. Specifically, a marketing team developed an idea for improving sales through an innovative product design feature. With new marketing projects, rapid implementation is often critical in order to be one step ahead of the competition. This rapid implementation or "fast track" approach places pressure on manufacturing and engineering to quickly develop and implement a new product. With new products, success relies heavily on immediate conformance to customer requirements. Failures of a new product can be devastating to the success of a marketing strategy. Since the product implementation time line was critical, several issues arose which were not encountered previously. The first was determining the anticipated overall nonconforming product rate that might be encountered. The nonconforming rate on the existing product was measured in parts per 10 million i.e p "' 0. In order to determine what the new product would experience in terms of a nonconforming rate, the amount of product needed would be enormous. Large quantities of product would be required to satisfy the statistical power, given the small observed p value, if an accurate assessment of risk was desired. The ability to accurately assess if a true difference exists is problematic since manufacturing large quantities of a new product is a high risk and potentially high cost venture if problems are encountered. But a problem may not be detected if large quantities are not run. Hence, a circle exists that seems to have no opening. One way out of the circle is through forced failure testing, or accelerated testing, of certain design features in which the worst situation is evaluated in order to see if any immediate disasters occur as compared to control samples composed of current product manufactured under worst case conditions. This type of testing does assist in validating design integrity to some extent e.g. detection of catastrophes, but long term process capability, determined by the stability and low variability of product performance, is not easily addressed. Long term product capability, without producing large quantities of product, would have its assurance through understanding process failure modes and developing corrective action to minimize such failure modes as a result of process variability. Thus it was critical to concentrate on key process and design failure modes that would provide the most impact if not corrected. Since time was of the essence and resources were limited, 5

PAGE 14

compounded with the need for "100% assurance", the question arose of how to best determine which failure modes were most critical in order to determine the proper focus of resources so that testing could be performed. How was this to be accomplished? This question prompted research into the topic of this paper. 6

PAGE 15

CHAPTER 2 ORIGINS OF FAILURE MODE AND EFFECTS ANALYSIS (FMEA) Research into methods for identifying and classifying failure modes of a new product started with conversations with a co-worker about which other fields of manufacturing is the development of failure free products critical. The consensus was that the aerospace industry would be one such area where failure studies would fill a necessary and obvious need. Below are listed some examples from the aerospace sciences which illustrates this demand for failure studies: -The 1979 crash of a DC-1 0 in Chicago was the result of large cracks in the engine mount as a result of severe and unanticipated maintenance procedures (19, p. 112) -The Galilee space probe sent to explore Jupiter has suffered missions problems from a snared main antenna, a defective tape recorder and a faulty valve in the propellant pressurization system (5,p.11) On June 3, 1980, the North American Air Defense Command (NORAD) reported that the U.S. was under missile attack. The alert was false and was attributed to a faulty computer circuit ( 14, p. 46). Cold temperatures embrittled the "0" rings on the space shuttle Challenger's solid fuel rockets resulting in tragic and complete mission failure (19, p. 5). Further investigations into the history of failure identification studies in the aerospace industry led as far back to a lecture given by Wilbur Wright in September of 1901 to the Western Society of Engineers in which he stated (1, p. 86) "The problems of land and water travel were solved in the 19th 7

PAGE 16

century because it was possible to begin with small achievements and gradually work up to our present successes. The flying problem was left over to the 20th century, because in this case the art must be highly developed before any flight of any considerable duration at all can be obtained." Wilbur Wright was expressing the need for a sophisticated approach to developing a new mode of transportation which could not rely on loosely connected trial and error experiments which had been successful in other fields. Indeed, the Wright brothers, bicycle mechanics that they were, pioneered aeronautical research, engineering and testing. The reasons for their careful up front work was most likely motivated by the same reasons that current manufacturing is confronted with in the development and implementation of a new product. The Wright brothers understood that they would be developing a "flying" machine that if failed, even once, could result in great bodily harm. Unfortunately this latter scenario did pan out for Orville Wright, who, on September 17, 1908, during a demonstration for the U.S. Army at Fort Meyer, suffered a crash landing because one of the propellers developed a longitudinal crack and failed. As a result, Orville Wright suffered injuries and his passenger, Lieutenant Thomas Selfridge, became the first powered airplane fatality (11, p. 230). The Wright brothers' demonstration of a manned powered flying machine opened the flood gates for airplane development. Aircraft for military operations were utilized in World War I and the use of aircraft for mail delivery and transport soon followed. Increased use of airplanes resulted in increased air crashes (9, p. 1) and the need for increased reliability and safety levels for aircraft based on accident rates per hour of flying time. Airplanes were naturally becoming sleeker, faster and more complex than their wood and cloth ancestors. The natural consequence of this advance was increased hierarchies of interconnected components which could fail. In 1947, a paper was presented to the Institute of Aeronautical Sciences which stated (31, p. 11) "Safety must be designed and built into airplanes just as are performance, stability, and structural integrity. A safety group must be just as important a part of a manufacturer's organization as a stress, aerodynamics, or a weights group." The need for reliability and safety in systems was also recognized with rockets during World War II in Germany. The first series of 10 V-1 8

PAGE 17

rockets (predecessor to the infamous V-2) either blew up on the launch pad or fell into the English Channel. Robert Lusser, a mathematician, was consulted on the problem of the V-1 rockets and developed a mathematical formalism to describe the reliability of a series system. Lusser determined that the old adage of "a chain is no stronger than its weakest link" was not applicable to a series system since it failed to account for random failure. Lusser developed the product law of series components, or that the reliability of a series system is equal to the product of the reliabilities of the individual components: R, = R,R2R3 R.,. Hence in a series system the reliability of the individual components must be much higher than the system reliability for satisfactory system performance. In the United States, efforts to improve reliability were focused on the extension of quality. Better designs, stronger materials, advanced inspection techniques, etc., were emphasized to extend the useful life of a part or an assembly. This philosophy was illustrated with General Motors Electro-Motive division which extended the useful life of traction motors used in locomotives from 250,000 miles to 1 million miles through the use of better materials and improved testing (9, p. 2). During the Korean War in the 1950's, the Department of Defense found that unreliable equipment required a tremendous amount of maintenance. Specifically, the cost to the Armed Services was $2 per year to maintain every $1 worth of electronic equipment (9, p. 2). As a result, the government found that it was wiser to design for reliability than it was to wait and repair equipment after failure. In the commercial arena, on the first anniversary of jetliner service, May 2, 1953, a de Havilland Comet disintegrated over India followed by two other Comet midair explosions during 1954. All explosions were the result of pressurization fatigue on the airplane's cabin and were discovered through post mortem investigations of the wreckage (19, p. 176). This philosophy of "fly-fix-fly" was not applicable for high risk, high cost or high visibility systems. In the fly-fix-fly approach, improvements are based on an examinations of failures in order to improve the next generation of a product or system. After-the-fact testing misses the mark in which potential failures cannot be tolerated as a finished product component. Missile system development in the late 1950's and early 1960's also prompted new approaches for examining failures. The Minuteman intercontinental ballistic missile (ICBM) was one of the first to have a formal, disciplined system safety program (31, p. 11 ). Further prompting came from the Mercury and Gemini manned rocket programs that demanded success the first time. Disastrous accidents at four ICBM 9

PAGE 18

missile/silo complexes in 1962 also resulted in increased safety awareness. From this background, failure identification strategies originated. One early method was Failure Mode and Effects Analysis (FMEA) which emerged to identify failures in systems. FMEA is a simplified approach to systems reliability analysis (17, p. 559) and is utilized to identify a failure mode of a component, its cause, and the effect on the overall system. According to the "official" definition found in Military Standard 721 C (MIL-STD-721C), a Failure Mode and Effects Analysis is (2, p. 3) "A procedure by which each potential failure mode in a system is analyzed to determine the results or effects thereof on the system and to classify each potential failure mode according to its severity." FMEA has evolved to include provisions for the development of corrective action strategies for the elimination of failures. FMEA is utilized not only in highly visible and critical items such as aircraft, ballistic missile systems, oil refineries, nuclear power plants and satellites, but also in new consumer product introductions. For the same reasons, preventing large scale failures and increasing reliability before implementation of a design or system, FMEA has become so important in the commercial arena. "First pass manufacturing" is needed for any organization that requires a high level of quality and reliability at product introduction. 10

PAGE 19

CHAPTER 3 FAILURE MODE AND EFFECTS ANALYSIS (FMEA) Tabular FMEA How does a Failure Mode and Effects Analysis proceed? The basic development is through the use of a worksheet format consisting of several columns. This is appropriately called the tabular FMEA. An example of a general tabular FMEA is shown in Figure 3.1 (3, p. 14). The basic idea of the FMEA, as mentioned previously, is to characterize failures of a system or component, the causes of the failure and the effect of the failure on subsequent components or on the overall system. A FMEA is performed early in the design stages of a new product or system as a way of discovering failures so that necessary corrective action can be developed to reduce or eliminate failure modes. FMEA is used as a preventive action tool. FMEA is also a versatile tool that has expressions in maintainability analysis (MEA), logistical support analysis, safety analysis and damage analysis (DMEA). These alternate expressions were originally conceived for military applications but may be developed for commercial products. The level of sophistication and nature of a FMEA can be tailored to the situation at hand. The general tabular FMEA expressed in Figure 3 consists of 9 key columns whose function can be defined as Column 1 2 3 4 5 Function Component under consideration. A concise statement of the function or intended purpose of the component. The mode of failure of the component or the various ways in which failures are observed. The cause of failure. The effects of the failure on the next and on the overall system. 11

PAGE 20

Effect of Failure Effect of Detection Corrective Corrective Component Function Mode of Cause of Local Ultimate Method Action Action Remarks Failure Failure ..... N Figure 3.1 Tabular FMEA

PAGE 21

6 7 8 9 The method of failure detection or discussion of how the failure may be detected. Possible corrective action to reduce or eliminate the failure. Effects of corrective action. Remarks. Columns 1 and 2 are used for identification and purpose of the part under study. The function of the component and its requirements is critical to guiding the development of the FMEA. Column 3 lists the failure modes and may consist of many modes for each specific component. The failure modes need to be based on the operating conditions at the time of failure since different situations may result in different failure modes. Column 4, the cause of failure, are possible reasons why the failure mode occurred. Column 5 describes the effects of failure on the next component and on the overall system. Column 6, the method of failure detection, is used in providing insight into what current controls will detect the failure mode prior to actual failure. Column 7, possible corrective action, and column 8, the effects of proposed corrective action, answer the question of how the failure modes will be addressed e.g. testing programs or control systems, and what effect did the corrective action have on the failure mode itself. Column 9, the "remarks" part of the worksheet, can be used to express specific concerns of the analyst during the analysis. The tabular FMEA is a general method to brainstorm for failures of a system or component. The FMEA is started when some information is known of a system or component design and should start early in the design cycle since the goal is development of a product as free from failure as possible prior to full scale implementation. This goal applies not only to conceptually new products but also to existing ones which may be modified to new configurations. It is for this reason that FMEA is a living document and is considered complete only when a product, system or process is finalized with no anticipated future changes or modifications. Tabular FMEA is a very versatile tool that can be tailored to fit the analysis at hand and the level of indenture of a system or component. Tabular FMEA presents the results of a FMEA session in a logical and understandable format so that corrective action can be developed. 13

PAGE 22

Failure Mode Effects and Criticality Analysis Although the tabular FMEA is the cornerstone of a successful failure identification program, there are certain drawbacks. The process of performing a FMEA can be time intensive and generate large amounts of paperwork if the level of analysis is broad. The tabular FMEA also provides no quantifiable information on the severity of a failures' effect on the overall system or on the likelihood of occurrence. The ability to grade a failure is crucial in determining resource allocation. For example, a faulty cigarette lighter on an automobile is far less severe to the operation of the vehicle and safety of the passengers than faulty brakes. The ability to characterize failures, in terms of their criticality and the frequency with which they occur, assures that the proper response with proper resources are allocated and that failure reduction activity is not haphazard or misdirected towards inconsequential items. A FMEA study can generate considerable amounts of failure modes, not all of which can be addressed in a timely or cost effect manner. For this reason, a relative basis to measure the importance of a failure mode on the overall success of a product or system is needed. The introduction of criticality analysis (CA) as a complement to FMEA is a way to provide a ranking of failures. Criticality analysis was introduced by NASA prior to 1965 as a way to assure that hardware used in the space program was reliable (3, p. 17). To define (20, p. 102-1) "The purpose of criticality analysis (CAl is to rank each potential failure mode identified in the FMEA Task 101, according to the combined influence of severity classification and its probability of occurrence based upon the best available data." The failure analysis of FMEA and CA now becomes FMECA or Failure Mode Effects and Criticality Analysis. The "standard" for performing a Failure Mode, Effects and Criticality Analysis is developed in MIL-STD-1629A. Figure 3.2 represents Task 101 in MIL-STD-1629A which is a typical FMEA worksheet but now has a column for assessing the severity of a failure. The other columns of Task 101 are defined in detail in MIL-STD-1629A and are similar to the definitions provided previously for the tabular FMEA. Figure 3.3 represents a typical worksheet for Task 102, the criticality analysis, and includes, in addition to a severity column, specific parameters used to quantify the failure of a component. The probabilities in Task 1 02 when coupled with the 14

PAGE 23

(J1 SYSTEM, ________________ INDENTURE LEVEL ________ __ REFERENCE DRAWING ________ MISSION ______________ __ ltem/Functiona failure ldentific&tion I Identification Modes and Number (Nomenclature) Function Causes FAILURE MODE AND EFFECTS ANALYSIS Mission failure Effects Phase f Operational local Next '"' Mod Effects Higher Effects Level Failure Detection Compensating Method Provisions DATE COMPILED BY ________ __ APPROVED BY ________ __ Severity Class Remerks I Figure 3.2 Failure Mode Effects Worksheet for Task 101 in MIL-STD-1629A

PAGE 24

Ol SYSTEM INDENTU1;;R;::E:-;L-;:Eo;-V;;oE;-L----REFERENCE DRAWING ____ MISSION _______ ltem/Func. 10 Identification Number {Nomenclature) Function Failure Modes ""' Causes CRITICALITY ANALYSIS Failure Failure Mission Probability Effect Phase I Failure Prob Operational SeYerity Rate Date Mode Class Source B -Failure Modo Failure Operating Ratio Rate Time lX }.P DATE COMPILED BY ____ __ APPROVED BY ____ Item Rem-Failure Mode Crit # Crit # ""' em =Ba.l. t CI p Figure 3.3 Criticality Analysis for Task 102 in MIL-STD-1629A (Quantitative Method)

PAGE 25

severity classification, aid in the development of a matrix illustrating how the various items under a failure study compare in terms of probability of occurrence and severity. The approaches used in the criticality analysis can be either quantitative or semi-quantitative. Since both Task 101 and 102 have severity classification columns, a brief description of severity is in order. According to the MIL-STD1629A, the value of severity classification is to provide a qualitative measure of the worst potential consequences resulting from a design error or item failure. Severity is classified below (20, p. 1 0): Category Classification Catastrophic II Critical Ill Marginal IV Minor Definition A failure which may cause death or weapon system loss. A failure which may cause severe tnjury, major property damager, or major system damage which will result in mission loss. A failure which may cause minor InJury, minor property damage, or minor system damage which will result in delay or loss of availability or mission degradation. A failure not serious enough to cause injury, property damage, or system damage, but which will result in unscheduled maintenance or repair. Although the above classification is directed primarily towards military applications, modifications can be made for use in designs of consumer goods. 17

PAGE 26

With the introduction of severity to the FMEA worksheet, items developed in a FMEA can be grouped in a logical manner. This categorization guides the allocation of resources for failure abatement strategies. The key to criticality analysis is the ability to accurately quantify failure probabilities. However, this presents certain problems. In many instances what is known of an item's failure probability may simply not be available and needs to be ascertained from engineering knowledge, historical evidence or best guess. In other cases the probabilities of failure may exist in handbooks, such as MIL-HDBK-217F, Reliability Prediction of Electronic Equipment, that provide failure rates for electronic equipment ranging from tubes and lasers to capacitors, resistors and lamps. These two types of situations will result in a criticality analysis performed in either a semi-quantitative or quantitative manner, respectively. Figure 3.3 represents a criticality analysis worksheet in which failure probabilities can be assessed quantitatively e.g. obtaining certain parameter estimates for failure modes for an item under consideration. These parameters are located on theCA worksheet in Figure 3.3 and are defined explicitly in MIL-STD-1629A. The estimates are then used to calculate a failure mode criticality number, em, where em = paJ.pt and the item criticality number, C, = L ( paJ.Pt) j from j = 1 to n, in which n is the failure modes in the item that fall under a particular criticality classification and j is the last failure mode in the item under the criticality classification. The above calculations are used when information pertaining to the various parameters is known. The quantitative method is considerably more complex than the qualitative method although it does provide for a more accurate analysis. The qualitative method on the other hand is much simpler and more applicable when specific failure rate data are not available. Failure modes identified in the FMEA are assessed in terms of probability of occurrence and a scheme for grouping these probabilities is provided in MIL-STD1629A. A summary ofthese classifications are as follows (20, p. 102-1): Category Level A Frequent 18 Description A high probability of occurrence during the operating time interval.

PAGE 27

Level B Level C Level D Level E Reasonably Probable Occasional Remote Extremely Unlikely A moderate probability of occurrence during the item operating time interval. An occasional probability of occurrence during item operating time interval. An unlikely probability of occurrence during item operating time interval. A failure whose probability of occurrence is essentially zero during item operating time interval. MIL-STD-1629A provides specific failure values for the above definitions. However, the probabilities will vary depending upon the situation at hand. In other words, the above categories may be customized with different values and ranges of p, the probability of failure, and need to be developed and agreed upon prior to the start of the FMEA. Figure 3.4 shows how the criticality worksheet appears when the qualitative method is chosen. Whether the analysis is quantitative or qualitative, the resultant analysis can be charted on a criticality matrix. An example of a criticality matrix is shown in Figure 3.5. The matrix is constructed by inserting item or failure mode classification numbers in matrix locations representing the severity classification and either the probability of occurrence or the criticality number, C,, for the item's failure modes. The resultant chart indicates the corrective action priorities. Specifically, the diagonal line from the origin represents increasing criticality. The criticality matrix provides a useful pictorial of failure modes and their overall relationship to an item or system in terms of what's important regarding problem resolution. MIL-STD-1629A provides a specific and methodical approach to constructing a FMEA and Criticality Analysis, resulting in the FMECA. MIL-STD-1629A can be modified easily to suit needs in commercial manufacturing or service environments. If the emphasis is on the simpler qualitative analysis, MIL-STD-1629A provides an effective brainstorming 19

PAGE 28

N 0 INDENTURE LEVEL REFERENCE MISSION ____________ Item/Functional ldentificatio Identification Number (Nomenclaturel Function CRITICALITY ANALYSIS Mission Phase I Failure Modes Operational Mode Severity Class and Causes DATE _________ SHEET __ OF COMPILED BY APPROVED BY ________ Probab!Hty Level Remarks Figure 3.4 Criticality Analysis for Task 102 in MIL-STD-1629A (Qualitative Method)

PAGE 29

c, Probability of Increasing Occurrence Criticality High Low A ::::: .-:: .. ::.:.:::..:r.. :.::.::.:.-: .. :. .. .J:::.:::.... ..:::.::.-:;:-.::.:.:.-.: ... ::::::::::: -............................. ............................. ............................. .................................. ...................................................... '1" ...................... !.. ...................... .. B ............................. i ............................. j ............................. .................................. -............................. 1 ............................. 1 ........................... 1 ................................. .. ............................. L ............................ J. ............................ L ................................ .. _c:_ : :_-[:: ::-: :: : : "":::::.::.::: .. .:::::.\:.::::::::::::::::.:.::::r:::::::.:: .. :.::.::.::.:.:L.: .. : .. ::":"""::: .... :::: ............................. L ........................... j ............................ L ............................... ; : : : E :.-:: .. ::::::::: .. :::::::::r::.::.:::::::: .. ::::::r::::.:::::: .. :::::::-.:1::::::::::::.::.:::::.:::: : : IV Ill II Severity Classification (Lesser Severity to Greater Severity) Figure 3. 5 Criticality Matrix (Quantitative and Qualitative y axis scales are both shown) 21

PAGE 30

and prioritization tool that allows both experts and non-experts to participate in a failure study. Indeed, there are other FMEA approaches which are effective in determining failure modes and appropriate risk abatement strategies. Alternative approaches will be presented in the next section. 22

PAGE 31

CHAPTER 4 FAILURE MODE AND EFFECTS ANALYSIS FOR MANUFACUTURING The methods and formats in Chapter 3 are fundamental examples of a FMEA. However, other formats exist which yield the same end result as the methods described above. One such format is shown in Figure 4.1, a FMEA worksheet taken from Juran's Quality Control Handbook from the section titled "New Product Development" (6, p. 13.30). It is more general than the FMEA methods provided by MIL-STD-1629A and is representative of the type of FMEA worksheets currently in use in commercial arenas and those found in related literature. The key element behind the FMEA worksheet in Figure 4.1 is the determination of a risk priority number or RPN. The RPN value is calculated by multiplying values obtained in the columns titled frequency of occurrence, degree of severity and chance of detection, here referred to as columns A,B and C, respectively. Note that the frequency of occurrence and degree of severity columns correspond to the probability of occurrence and severity columns in MIL-STD-1629A but now a column has been added to quantify the chance that a failure will be detected. The values for these columns are the numbers 1 to 10, scaled as follows: Column A B Frequency of Occurrence 1 = Rare occurrence 10 = Almost certain occurrence Degree of Severity 1 = Insignificant loss to the user 10 = Product inoperable or major replacement cost or safety hazard. 23

PAGE 32

N .,. Item: Function: Analyst: Mode of Component Failure Frequency of Occurrance: 1 :-o: Rare occurance Cause of Failure 10 = Almost certain occurance I Block Number: I Date: A B Effect of Frequency of Degree of Failure Occurance Severity Degree of Severity 1 = lnsignficant loss to the user 1 0 = Product inoperable or major replacement cost or safety hazard. c Chance of Detection Risk Priority Design Design Number Action Validation Degree of Detection: 1 = Certain detection before failure 10 = No detection possible before failure Figure 4.1 FMEAC for New Product Development

PAGE 33

c Chance of Detection 1 = Certain detection before failure 1 0 = No detection possible before failure The subsequent RPN (RPN = A x 8 x C) is an integer between 1 (negligible risk) and 1000 (critical risk). This number is then utilized to prioritize corrective action. The advantage of the worksheet in Figure 4.1 is its simplicity. The rating system is largely subjective in nature although historical information can be utilized to guide in number assignment. For example, if a certain item has a historically very low defect rate, the frequency of occurrence will be a 1 or 2. On the other hand, if no information is known of how a component may respond, the best guess of the FMEA team can be given on the 10 point scale. Further gradations of the numbering system can be developed. For example, in the above numbering scheme, values from 2 to 9 have not been defined. These intermediate values can be defined and based on specific process, product or mission requirements that the FMEA is addressing. Another advantage of the FMEA worksheet in Figure 4.1 is the ability to sort the RPN number or columns A,8 and C to find the "big ticket" items. For example, a FMEA team may decide to concentrate on the top 10% of highest RPN values, or concentrate on high severity items with low detectability and so on. Cutoff values for RPN numbers might be determined by the design team based on cost and resource factors e.g. RPN values of 50 or less might be considered noise whereas RPN values of 500 or more might require corrective action. The last two columns of Figure 4.1 are important to the analysis. Once specific items have been targeted for corrective action, the action itself must be part of the FMEA. Hence the design action and design validation columns are included. The design validation refers to how the corrective action is verified. Once corrective action has been initiated, the RPN number may change and Figure 4.2 illustrates a FMEA worksheet in which the additional columns A' ,8' and C' are utilized to calculate the new RPN. 25

PAGE 34

N 0) Item: Function: Analyst: Component Mode of Cause of Fsilure Fallwe Frequency of Occurrance: 1 = Rare occurance 10 = Almost certain occurance Effect of Failure I Block Number: I Date: A B c Risk Frequency of Degree of Chance ot Priority Occurence Detection Number Degree of Severity 1 = lnsignficant loss to the user 1 0 = Product inoperable or major replacement cost or safety hazard Design Design A' B' C' Action Velidetion Freqouncy Severity Detection RPN Degree of Detection: 1 = Certain detection before failure 1 0 = No detection possible before failure Figure 4.2 FMEAC for New Product Development with Corrective Action Columns

PAGE 35

Process and Design FMEA To this point discussion has focused on general FMEA methods as applied to development of products or systems. Further refinements of the FMEA are into design FMEAs (DFMEA) and process FMEAs (PFMEA). The former focuses on the design of the product and the latter emphasizes consistent manufacture of the design. The DFMEA occurs first and then the PFMEA attempts to address issues related to manufacturing variability and product consistency. The difference between a DFMEA and PFMEA is often subtle; the following example illustrates the differences. Suppose a series of recyclable rockets are built to study the upper atmosphere. The rockets are recyclable only if they return safely from their mission with little or no appreciable damage. Safe return depends in part upon the recovery system that consists of a parachute of a certain diameter. The diameter of the parachute was specified in the design stages to be 16 feet. A DFMEA resulted in a testing program that showed the risk to rocket safety and recoverability with a 16 foot parachute to be acceptable i.e. a "low" RPN. Next, a PFMEA on the process related to the production of the parachute was performed and revealed that the nominal value of parachute diameters of 16 feet is obtainable but the process variability is extremely high. Thus some parachutes may be smaller than 16 feet and some much larger than 16 feet; in either case, the product will fail to function as required. If the parachute is too small, the rocket will plummet to the ground; if too large, the rocket may be carried miles outside of the intended operating range. As a result, machine modifications are required to reduce the variability of the process insuring that the highest possible proportion of correct diameters are manufactured. Note that if the process had been stable (low variability) but the design was incorrect i.e. a mis-specified parachute size that is too larger or too small, then the problem would be with design. A design FMEA is then used during design of a product, its component parts and any of the equipment necessary to manufacture the product. A process FMEA will be used in any process that can be mapped and that has associated and identifiable failure modes (7, p. 175). Both the DFMEA and PFMEA are able to use the same worksheet but it must be noted on the worksheet with a separate column whether the failure under consideration is a process or design issue. With the introduction of the PFMEA, the amount of paperwork will be considerably 27

PAGE 36

increased requiring greater management. 28

PAGE 37

CHAPTER 5 FAILURE MODE AND EFFECTS ANALYSIS AND SOFTWARE DEVELOPMENT Software development oftentimes requires that same basic requirements of being failure free prior to introduction as do other products. The criticality of software errors can be summed up in the following examples: -A software problem may have prevented a Patriot missile from tracking an Iraqi Scud missile that killed 28 Americans during the Gulf War (15, p. 62). -The manned space capsule Gemini V missed its landing point by 100 miles due to the guidance program ignoring the motion of the Earth around the sun (14, p. 49). -A single incorrect character in the specification of a control program for an Atlas rocket carrying the first interplanetary spacecraft, Mariner I, caused the rocket to veer off course shortly after takeoff. Both the rocket and the spacecraft had to be destroyed (15, p. 63). Software measures of performance can be expressed as defects per 1000 lines of code (KLOC), development time, modifications, re-writes, etc. The same principles of FMEA, defining failures, causes and effects, can be applied to software development. As with other products, a key element in developing successful software is defining requirements accurately. Accurate requirements drive design, planning and testing of software. How might a FMEA work with software development? Suppose one is writing a structured program in PASCAL. Within the overall program, there may be UNITS, or collections of constants, data types, variables, functions and procedures. The unit may form a of indenture for the FMEA and individual components would be the 29

PAGE 38

INTERFACE, CONST, TYPE, PROCEDURE and so on. Each of these in turn could be broken down further. For example, under a specific procedure, local declarations listed under the VAR section would be analyzed for potential failures e.g. declaring a variable as a INTEGER when indeed it needs to be a declared as an REAL. The key component of such an analysis is to understand the requirements and relationships to the overall program. As mentioned, requirements will provide the basis for the ability to correctly devise and carry out a plan of action in the development of the software. Testing will validate such actions and determine if more problem solving is warranted. A key element to software development is through the use of metrics or measurements. Performance measurements such as reliability, efficiency, maintainability and cost are integral to software quality assurance. The era of undisciplined programming artists, or "hackers", must give way to a software development that is both disciplined and repeatable. FMEA methodology provides one tool to reach the objective of failure tree software. 30

PAGE 39

CHAPTER 6 STATISTICAL BASIS OF THE FMEA WORKSHEET In development of the risk priority number, the question arises as to the statistical nature of the FMEA numbering system. Specifically, what distribution, if any, do the occurrence, severity and detection columns follow? In the absence of known failure data, a generic rating system based a scale from 1 to 10 provides a way to grade failures. Such a scale can be viewed as being uniformly distributed i.e. described mathematically by the discrete density function f(x) = 1 x=1,2, ... ,n n with mean and variance E(X) n + 1 V(X) n2 1 = = 2 12 This implies that each gradation from 1 to 10 is equally likely to occur. Actual values used with the FMEA depend upon the knowledge of a FMEA team. The uniform distribution provides a reasonable description of the rating system distribution in lieu of actual known failure data. In addition to the column distributions, the calculation of the risk priority number, RPN, poses some interesting questions from a probability standpoint. If RPN is considered to be a probability statement, the manipulations of columns A. Band C can be viewed in two ways. If each column is assumed to be statistically independent, then P(ABC) = P(A) P(B) P(C). However, this may not be entirely accurate. If columns A, B and 31

PAGE 40

C are somehow related, the use of conditional probabilities may be more appropriate. It is not unreasonable to imagine that provided that one event has occurred, the probability of the next event should be in accordance with the information provided in light of the first event. For example, if an item in a FMEA has a low probability of occurrence, the chance of detection may be low as well. This situation then follows the conditional probability form P(ABC) = P(A) P(B I A) P(C I AB) where A, 8 and Care the columns defined previously. If failure data are accurately known, the above equation will provide for a more accurate model for the distribution of final RPN values than assuming (unrealistically) independence. 32

PAGE 41

CHAPTER 7 FAILURE MODE AND EFFECTS ANALYSIS INTEGRATION The value of a FMEA is to identify failure modes along with severity and probability of occurrence in order to rank key failures. Once this is done, development of corrective action is the next step. The value of corrective action is to aid in risk abatement. Several corrective action strategies exist for both process and design issues. These strategies may be in the form of developing new manufacturing practices and procedures, modifying work habits, implementation of inspection routines, and so on. One specific tool which can be used as a corrective action strategy is statistics. A diverse set of statistical techniques may used with a FMEA. These techniques are not limited to only corrective action but can be used during the construction of the FMEA to determine failure risks and probabilities or to provide an idea of how effective was the corrective action. In many instances, failure will be controlled by the ability to develop predictive models. Below are some techniques to accomplish such goals. Surveys Surveys are an investigative questioning technique. The primary function of surveys in the context of FMEA is to define customer requirements. The scope of a FMEA is determined by its ability to address failure modes in relation to certain conditions. As mentioned in the beginning of this paper, failure is defined as the inability of a product or system to meet a required function. The first step is the proper definition of what is needed from a product or service. Whether the customer is a consumer or the next process in a production line, al;lsence of clear requirements may misdirect efforts needed to eliminate failure modes. Surveys, whether they are randomly mailed questionnaires to 33

PAGE 42

consumers or interviews among different departments in a company, fill the need for developing clear requirements. Reliability Analysis Reliability is the determination of how likely a product or system will operate without failure for a stated period of time, t. The basic idea for the reliability of a component or system at time t is given by R(t) = P(T > t) where T is a continuous random variable denoting time to failure and t is some specific time. Generally the distribution of T is modeled by a probability distribution such as the normal, exponential, gamma or Weibull. Reliability models are useful in estimating the frequency of occurrence for a failure mode in a FMEA. Oftentimes, a new product is simply a modification of an older design from which data exist and can be used to predict the possible outcome for a modified product. Reliability models also may be used as a design action strategy to test different designs. Reliability analysis is closely related to survival analysis. Both seek to identify factors which have an effect on the survival, over time, of a product, system or biological entity. For example, survival analysis can be used to model tool wear over time. Tooling failure in a stamping process, for example, leads to nonconforming product which may fail to meet a customer requirement. Both analyses utilize the hazard function given by h(t) : f(t) R ( t) where f(t) is the probability density function of T (failure function) and R(t) is the probability fo surviving to at least time t (reliability function). The hazard function is interpreted as the instantaneous failure rate i.e. the rate of failure at a given instant in time provided that the item has lasted until that time. Its shape describes situations in which a product may have a high failure rate directly after manufacture, such as an automobile during the "break in period". After a period of time, a hazard function 34

PAGE 43

that remains constant is referred to as the "useful life" of the system. As the product ages, as with an automobile, breakdowns are more frequent and occur during the "wearout" period. Break in, useful life and wearout periods characterize the product in question. Each period may have different failure modes with differing probabilities and severities which must be taken into consideration in a FMEA under requirements. A graph of a generic hazard function is shown in Figure 7.1 (12, p. 10-5). Linear Models Linear models can take on forms such as those expressed as regression, analysis of variance and experimental design. The value of linear models is the ability to develop relationships between one or more independent variables and a response in order to provide insights into underlying mechanisms driving such relationships. Both regression and analysis of variance models can be utilized in experiments or with historical data. Multiple regression models follow the form where 13 o, 131 13 p-1 are parameters Xi1 xi,p-1 are known constants Ei are independent N(O, cr2 ) i = 1, ... ,n and the multi-factor analysis of variance cell means model is where 1-1 iJ are parameters EiJk are independent N( o, cr2 ) i = 1, ... ,a; j = 1, ... ,b; k = 1, ... ,n Designed experiments, when done properly (randomization, 35

PAGE 44

..... <4 .s:: 36 ..-! :J ..... (]) Ul :J c: -,.; I .-'<: r1l (]) 1-< .0 c 0 ;::; () c :::J u.. -o "' N "' :c Q) () > u r--Q) :::J OJ u..

PAGE 45

elimination of extraneous variation, etc.), can provide very useful analysis of experimental data. Designed experiments provide precise estimates and reliable models that can be used for optimization of a product or process. The predictive power aids in abating risk through identification of key factors and understanding their contribution and relationships to some output. Designed experiments also provide for developing products that are robust or insensitive to variations in a process or environment which certainly can play a role in risk abatement. Exploratory Techniques Perhaps one of the most widely utilized and powerful techniques that is available to an analyst are exploratory data techniques. Exploratory techniques differ from confirmatory studies in that the probabilistic assumptions underlying standard statistical tests are not the basis of analysis. This is not to say that exploratory and confirmatory techniques are diametrically opposed. Rather exploratory techniques are part of an iterative loop in which data first are explored for interesting patterns upon which confirmatory studies based on probabilistic models may be pursued. For example, exploratory techniques such as boxplots, scatterplots, robust regression, median polish, etc., provide for comparison and pattern identification. In many instances, exploratory techniques, coupled with process knowledge, can provide conclusive results of a data set without resorting to confirmatory techniques. Statistical Process Control Statistical process control, or SPC, encompasses a wide variety of graphical and statistical tools used to analyze, control, and improve a process or product. SPC is used extensively in quality applications. One widely used SPC technique is the control chart. The value of a control chart is to track the performance of a process over time. More so, control charts are used to distinguish between natural variability versus special causes of variability. The ability to distinguish these two types of variation in a process form the basis of prevention. When a 37

PAGE 46

process exhibits assignable causes of variability then action can be taken to correct the process to bring it back under control. The value of SPC and control charts to FMEA is in corrective action. Control charts are used to detect situations that could pose a problem before they actually occur. The value of this cannot be underestimated if the purpose of FMEA is to develop a product that is known to be failure free before use. Control charts are also a natural consequence of designed experiments discussed previously. If key factors of a product or process are identified through designed experimentation, the use of control charts assure that certain factor values are consistently manufactured in order to produce the optimum response as determined by the designed experiment. In many cases, experiments performed on a limited scale do not account for manufacturing variability. Implementing a new product on several different manufacturing processes is a risky endeavor if different components of variability are not taken into account. Control charts assist in tracking variability of different processes and provide the ability to detect special causes of variation. Control charts provide the means to compare variation between processes and pinpoint areas in need of variability reduction or control. 38

PAGE 47

CHAPTER 8 FAILURE MODE AND EFFECTS ANALYSIS TERMINOLOGY A remark on FMEA terminology is in order. In the previous discussion of Figures 4.1 and 4.2, the term FMEA was used in reference to the worksheets and to the action of performing a failure study. In some of the current literature on the topic of FMEA, Figures 4.1 and 4.2 are referred to as FMEA worksheets and the process as a FMEA and not necessarily a FMECA worksheet or analysis, although Juran's Quality Control Handbook refers to them both as FMECA. Since Figures 4.1 and 4.2 are indicative of what has been noted in current literature on the topic and commonly referred to as FMEAs, the term FMEA will be used to describe the worksheet and analysis. Both the FMECA and FMEA provide essentially the same type of information but under slightly different formats and names. FMEA Formats Several different types of FMEA formats or worksheets have been discussed. Which format should one use? In some cases a customer may require a supplier of a product or process to develop an FMEA according to a specific format; e.g. MILSTD-1629A for Department of Defense contractors and SAMSO-STD-772, "Failure Modes and Effects Analysis for Satellites, Launch Vehicle, and Reentry Systems" for space vehicle contractors. Reference (21) is a manual on performing FMEA for suppliers to the Chrysler Corporation, Ford Motor Company and the General Motors Corporation. Learning industry specific FMEA formats can be accomplished through courses offered by a wide variety of organizations such as the American Society for Quality Control (ASQC). In instances where an organization may wish to develop FMEA without compliance to a specific format, one of the standard forms 39

PAGE 48

presented in this paper can be utilized or custom formats developed. In either case, the formats must include a list of failure modes, their consequences and subsequent corrective action. The intent of performing a FMEA is to define failures so that appropriate failure abatement strategies can be developed early in the design stages before full scale implementation of a system or product. FMEA is not "rocket science"; the use of whatever format suits a specific need while maintaining the spirit of FMEA should be developed. Hybrid worksheets incorporating project schedules, FMEA results and testing programs are ways of using and extending the basic ideas of FMEA. Experimentation of formats is worthwhile to obtain the best method that is commensurate with a particular project. An example of an innovative failure strategy is provided in the appendix under case study B. Software programs can be utilized to perform FMEA and manage the resultant analysis. Two such programs are Formuser by Engineered Work Systems, Inc., and FMEAPLUS by Ford Motor Company (both are registered trademarks) (29, p. 70). An excellent and quite suitable alternative is a spreadsheet program such as MicroSoft Excel that provides the ability to sort the various columns. Of course software is not necessary to perform an FMEA but does make the task of compiling, updating and archiving FMEA results considerably easier. An example of a custom program is provided in the appendix under case study C. 40

PAGE 49

CHAPTER 9 PERFORMING A SUCCESSFUL FAILURE MODE EFFECTS ANALYSIS FMEA is generally developed using a "brainstorming" strategy. A FMEA is conducted through the following steps: a) Define the system and the performance requirements. b) Define assumptions and ground rules to be used in the analysis. c) Develop a block diagram, flow chart or schematic of the subject under analysis. d) Form a multi-disciplinary team and assign a group leader. e) Initiate a FMEA brainstorming session. f) Formalize the results of the FMEA in report form. g) Develop corrective action strategies h) Iterate the failure analysis. The key component of a successful FMEA is the strategic use of a multi-disciplinary team. A FMEA must not be performed by one individual unless the scope of the problem is very limited. The use of a cross functional team allows for a richer and more comprehensive development of a FMEA and helps to insure that as many if not all failures of a system or product are identified. Along with a cross functional team is a block diagram, flow chart or schematic of the product or system under study. The scope of the failure study can be defined with these simple illustrative and informative devices and can provide a common ground for the team to develop the FMEA. As important as the block diagram and cross functional team are the system performance requirements. The multi-disciplinary team can assist in developing appropriate requirements that need to be met. Requirements can be developed from consumer complaints, historical product or system performance data or customer supplied requirements. Once the FMEA is completed, a review locates any deficiencies in the analysis. -r:he final key item is to re-iterate the process once the corrective action items have been initiated. 41

PAGE 50

FMEA is oftentimes an intense process for defining failures of a system or product. It is a time intensive project that may involve thousands of labor hours and generate large amounts of paperwork. It also depends upon good facilitation skills of the FMEA leader who must focus the FMEA group, have the ability to draw out the necessary information from the group and have a clear understanding of the system and performance requirements. 42

PAGE 51

CHAPTER 10 LIMITATIONS OF FAILURE MODE AND EFFECTS ANALYSIS Although FMEA provides a succinct methodology for examining failures and providing for corrective action, drawbacks of the method limit its usage. Common problems encountered in the failure effects analysis include the following (3, p. 85): a) The analysis is time consuming and costly. b) The analysis results and recommendations are often obtained too late in design to be easily incorporated. c) Accurate failure data are difficult to obtain. d) The level of detail necessary for a thorough, economical and effective analysis is difficult to define accurately. e) The process of failure analysis is subject to inaccuracies. f) Agreement of ratings for severity, detectability and occurrence may be problematic within a group environment. Except for trivial cases, one can imagine the type of FMEA and the energy expenditure needed on a substantially complex endeavor such as designing an aircraft or complex automotive component. A certain amount of reduction in paperwork is achievable if a FMEA is performed on basic components and systems and if the scope of the FMEA is constrained. The lessons from one FMEA can be applied to other products or systems with similar qualities as well. Another limitation of the FMEA is that the failure modes are assumed to be statistically independent; hence a FMEA may over-estimate system reliability (17, p. 559) (see chapter 6). However, the primary purpose of a FMEA is the identification of failures which may contribute the most to a system or product unreliability. Apart from the technical aspects of FMEA, another element necessary and critical to efficiently and effectively develop a FMEA is facilitation skills. FMEA is not a mindless "fill in the blank" process but one of idea generation. The use of a multi-disciplinary team requires a group leader with excellent facilitation skills to keep the analysis moving, 43

PAGE 52

motivate participants, maintain focus and resolve disagreements. The facilitator must also be familiar with FMEA development and its relation to a certain project in order to utilize the full benefit of the group. 44

PAGE 53

CHAPTER 11 OTHER TECHNIQUES Failure Mode and Effects Analysis is one technique for systematically identifying failures. Other techniques exist such as Fault Tree Analysis (FTA), a very useful failure development technique developed in 1961 by Bell Telephone Laboratories to evaluate the Minuteman Launch Control System. FTA begins with an ultimate failure effect of interest and a tree of failure causes is developed using Boolean logic. The analysis continues until only primary events are left. The tree is then analyzed using algebraic or graph theory principles. The FTA provides for a depiction of a particular failure and is developed consequent to a FMEA study. Other techniques are Matrix FMEA (G.L. Barbour, 1977) which is based upon a matrix development of failures; Sneak Circuit Analysis (Boeing, 1967) used in determining failures of an electronic circuit, pneumatic, hydraulic and mechanical systems and programming logic; System State Phase Modelling (Tiger, 1969) which uses a logic diagram to investigate possible states of a system; Tabular Systems Reliability Analysis (Battelle Laboratories, 1971) which combines elements of fault tree analysis, Markov techniques and tabular FMEA into an integrated analysis; Event Sequence Analysis (Yellman, 1975) which traces the effects of system failures as a function of the order in which they occur; L.A. M technique (Reina and Squellati, 1980) which uses the physical properties of a system to evaluate the effects of failure; Approachability Analysis (Hitachi, 1981) which uses the concept of failures caused by improper relationships of parts and introduction of external components or errors into the system and finally, the Failure Combination Method (French Societe Nationale des Industries Aeronatiques et Spatiaks, 1981) which examines the effect of single, multiple and externally influenced failures on a system using an inductive approach. Techniques for dealing with software and microcomputer applications also have been developed including software sneak analysis, integrated hardware/software analysis and integrated critical path analysis. The above alternate techniques were obtained from Reference 45

PAGE 54

(3) which provides a succinct overview of the techniques along with references. 46

PAGE 55

CHAPTER 12 THE FUTURE OF FAILURE MODE AND EFFECTS ANALYSIS FMEA can be a costly and time consuming activity but, when used early in a design process, can recoup any up front expenditures by identifying and correcting failures at a point that is economically advantageous. FMEA also belongs to the disciplined. FMEA requires a commitment of time and energy from individuals participating in a FMEA and their ability to articulate their expertise. FMEA is a tool that allows the possibility of doing it right the first time versus fixing it a hundred times later at a much higher cost. FMEA does not cure all the ills of a product or system. It does provide one way of listing and examining failures but is by no means the only method or one that should necessarily be used. FMEA is a continuous improvement tool that supplements and works with testing and quality programs to produce the best system or product possible. 47

PAGE 56

APPENDIX A CASE STUDY A A FMEA OF A PHOENIX MODEL ROCKET RECOVERY SYSTEM The discussion in this report has focused on the ideas underlying failure studies as expressed in the use of FMEA. This section will focus on a simple FMEA study to illustrate the principles. Estes Industries of Penrose; Colorado, manufactures and sells model rocket kits. The rockets are of various sizes and complexity and are made from wood, cardboard and plastic. The rockets use solid fuel non-reusable engines of various sizes to propel the finished vehicles upwards of 1500 feet in some cases. The rockets have some type of recovery system; the most common consisting of a parachute that allows the rocket to return undamaged so it can be flown again (barring any losses to trees, power lines, lakes, etc). One particular model kit is the Phoenix flying model rocket. The Phoenix is an air-to-air guided missile that is used on fighter aircraft as an offensive weapon against other aircraft. Unlike the real Phoenix, the 1/9 scale model consists of a recovery system that allows the rocket to be recovered after flight to be reused again. The basic operation is rather simple. A disposable pre-manufactured solid rocket engine is installed in the tail section of the rocket. The engine is plugged with a nichrome wire which is connected to an ignition system powered by a series of batteries. The rocket is placed on a launch pad, a circular metal plate, and fittings (launch lugs) on the fuselage of the rocket are used to stabilize the rocket on the platform and during launch via a metal rod. The ignition of the engine is accomplished by pressing a button on the ignition system which is hand held from about 1 0 feet away that heats up the nichrome wire and ignites the propellent. The rocket lifts off and rapidly accelerates for a period of time. The thrust then "cuts out" and a coast stage is activated during which time the rocket glides to its highest altitude (the Phoenix is rated at a maximum altitude of about 1 000 feet) while trailing smoke for 48

PAGE 57

tracking by ground personnel. The coast stage then ignites an ejection charge that disengages the nose cone and separates the recovery system from the fuselage. The folded parachute is deployed slowing the vehicle for a gentle landing. Estes rockets are well proven designs that are reliable and safe to operate, provided they are built correctly (a process parameter) and are used as intended. However, in the Phoenix rocket constructed specifically for this project, modifications to the recovery system were implemented. The recovery system consists of a parachute and shroud lines attached to the nose cone and an elastic line called the shock cord that is attached to the fuselage. The shock cord permits the absorption of ejection stresses and any residual acceleration to avoid damage to the recovery system attachment or the fuselage itself. Flame retardant paper "wadding" protects the recovery system from hot ejection gases. The wadding is placed between the engine and recovery system in the body of the rocket. The standard recovery system uses a plastic parachute with narrow gauge shroud lines tied to the nose cone and shock cord. This design was improved with a nylon parachute, heavier shroud lines and the use of metal 0-rings and two types of swivel hooks. The concept behind the modifications was to prevent problems with shroud and shock cord entanglements through the use of swivel hooks and melted parachutes through the use of other materials. Since the design resulted in a product modification with resultant unknown consequences, a FMEA was performed. The first step was to develop a block diagram of the recovery system which is presented in Figure A.1 along with a statement of the requirements of the recovery system. The cross hatched blocks represent new features of the recovery system. The use and development of block diagrams or process flow diagrams cannot be understated. Any visual guides provide a common reference point for the FMEA team and often alleviate conflicts in interpretation of the system or product: a picture provides the proverbial thousand words. Block diagrams and process flow diagrams also are useful in further developments of testing programs and identification of key product or process parameters that may need to be evaluated or that cannot be controlled but need to be accounted for in a final analysis. Once the block diagram was developed, a brainstorming session followed. In the case of the Phoenix, the author was the sole deyeloper of the FMEA analysis. A correct approach would be a cross functional team but for the purposes of this report, a solitary analysis is sufficient 49

PAGE 58

U'1 0 Phoenix Recovery System To provide for safe return (no damage or loss) under normal flight conditions. B Shock Co1d Mount Shock Co1d Figure A.1 Phoenix Recovery System Block Diagram

PAGE 59

to illustrate the concepts of FMEA. The results of the failure study are provided on the attached FMEA sheets under Figures A.2, A.3 and A.4. Other forms such as the ones listed in the text could have been utilized with similar results. The values for each component and failure were derived by best guess and developed on Figure A.2. Once again, if a cross functional team was utilized the values may be more representative or 'true'. Nevertheless, for purposes of illustration, the subsequent values for columns A, B and C and the RPN value will suffice. Sorting RPN values in Figure A.2 yields the results in figure A.3 with a RPN of 300 occurring with the nylon parachute. These results indicate that corrective action should begin with items surrounding the entanglement of the parachute with other components of the recovery system. The action proposed is to follow the manufacturer's instructions on packing the parachute correctly with the shroud lines. Using this same category as an example, current packing of the parachute can be broken down into a design or process issue as illustrated in Figure A.5. In one case, packing of the parachute relates to the actual physical activity, while the other, the design side, asks the question if the manufacturer design for packing the parachute is correct. This same exercise could be done for each item on the FMEA. Doing so would double the amount of paperwork (at least) barring any further items added to the list for consideration under design or process parameters. In both cases validation of the design or process parameter might be performed with pre-flight testing using mock up rocket bodies or other methods of simulation. At this point, other items could be considered with high RPN values, such as burned or flawed shroud lines. Alternatively the analysis can proceed with those items that may not have a relatively high RPN value, but very high severity values as shown in Figure A.4. The FMEA for the Phoenix model rocket is based on the assumption that the rocket will operate under normal conditions. Normal operation in this case implies using a certain engine size and flying in favorable conditions (light wind, no precipitation, etc.). Altering the mission statement would affect the FMEA analysis. For example, if the mission were to fly in high winds, the importance of line or parachute entanglement would be of a higher order and the ability of the McMahon swivel hooks to rotate to keep the lines untangled would be of greater importance. Design issues surrounding parachute diameter also be included since high winds and large parachutes can carry the rocket out of a desired operating range. Well defined requirements of the system are 51

PAGE 60

Phoenix Recovery System FMEA il i I i \WiatOd 125 I La:, I 12 I B1okeo Hooks i 1 2 3 6 i t hook B'eakaoe """"'" .. 2 10 5 100 I Redooed s,eakaoe 2 to 2 40 Uoe' Keoooeo !Uoe S
PAGE 61

I 117 I"' '"" l2o ea':.::':rt, I No I I I Ls earnal ot NO Rolatioo I 1 I earnal ot NO Rotatioo '""'' Bceakago I Lioo> "'"'""' I Shtoodl ooo Btoakaot 19 Pa";,;;c;:'.,, No I 21 No 25 Pa:: ... @! p,:';;,:.. i27 0-ilog Bteakago 28 0-rioo ""''kaoe Is I I I Brokoo Hook> 12 Is MCM>OOO ernl Of NO Rotatioo !Lioe. ., .... ,. IZl e.::,,. Ripped 24 Ripped O..rir s.!:::::',oo 3C 0-riog ,:::;>,00 Brokoo Hook> 12 sv.;,.l Hook Btokoo Hook> 8 7 1 Lines JOI SwNo!Hooki Phoenix Recovery System FMEA Sorted by RPN ;t I 3 10 KOOOCOO locorroct Pack 4 5 I 3 10 Foolloo ,:;::,: 3 5 Foollc ,:;::,: 3 5 .W.I .::,:;::,: 5 5 Matorial Flaw I 2 10 ""'"'' 2 10 Bomod 2 10 Tight pack 1 2 10 KOOOCOO Bomed .li 1 10 Lme """'"" .. 2 tO Rod""' 1 10 Stre" (""'""'' 1 10 ,, 1 tO Str"' 1 10 5 10 I ,::,;:::::, 1 5 1 5 Mteril Flw KeOOCOO. 2 10 Keoocoo Mteol Flw ;t 1 7 Groood 3 7 I Str" 1 10 I 1 10 I Stress n 1 2 I I 1 2 Of tw\stod """ t 5 ,.,:,:;:;;,,., 1 5 I Rodocod '"" t 5 1 t 10 300 10 200 1em ":'' mtg. 5 150 pet mtg. I 10 150 flloht 10 150 teco'''Y 5 125 5 100 5 tOO I 5 100 Flame ''""' lioo 5 too eac> ":'' mtg. 10 100 5 100 l1osoect 10 100 ltnsoect 10 tOO IPto-fllght lo.oectioo 10 100 I t Of 5 50 I t so 'hook 10 50 lwaddino 10 50 :;:,:,:;;;: diffotoot 2 40 I 5 35 lospect t 2t lospect 1 10 _, 1 "' I""''"' tOt 3 6 3 6 "'"'" oaoe hook t 5 Lobrioato t 5 IR.,Ic t 5 1 1 Figure A.3 Sorted FMEA by RPN 53

PAGE 62

Com nent Nylon 22 Parachute Nylon 20 Parachute 13 Shroud Lines 15 Shroud Lines 16 Shroud Lines Nylon 19 Parachute Nylon 21 Parachute Nylon 25 Parachute Nylon 26 Parachute I 27 O-rin'"' 28 O-rin McMahon 8 Swivel Hook 9 McMahon \ Swivel Hook 14 Shroud Lines 1 29 0-rino 30 0-rinn Nylon 23: Parachute Nylon 24 Parachute 17 Shroud Lines McMahon 4 Swivel Hook McMahon 5 Swivel Hook McMahon 1 Swivel Hook McMahon 2 Swivel Hook McMahon 3 Swivel Hook McMahon 6 Swivel Hook McMahon 7 Swivel Hook 18 Shroud lines Nose Cone 11 Swivel Hook Nose Cone 121 Swivel Hook Nose Cone 10 Swivel Hook Phoenix Recovery System FMEA Sorted by Severity Mode of Failure Cause of Failure Effect of Failure Fco uenc Reduced No de lovment Entannlement Recoverabilitv 3 10 Reduced No de lo'-ent Incorrect Pack Recoverabilitv 3 10 Reduced Breakane Material Flaw Recoverabilitv 2 10 Reduced Breakane Burned RecoverabHitv 2 10 Reduced I Breakane Burned Recoverabilitv 2 10 Reduced No de IO'"'"'ent Tinht nack Recoverabiliru 2 10 Reduced No de lovment Burned Recoverabilitv 1 10 Line connector Reduced Detachment missoecified Recoverabi.litv" 2 10 Connector Reduced Detachment burned Recoverabilihi 1 10 Component Breakane Stress tove11.1se Detactlment 1 10 Component Breakaoe Mis-soecified Detachment 1 10 Stress fove11.1se1! Component I Broken Hooks Detachment 1 10 I Component Broken Hooks Mis-soecified Detachment 5 10 Reduced Breaka,.,e Material Flaw Recoverabilitv 2 10 Ring Component Seoaration Stress /overuse Detachment 1 10 Ring I Component I Senaration Detachment 1 10 Reduced I Rinned Material Flaw Recoverabilltv 1 7 Ground Riooed Ensnarement Recoverabil" 3 7 Reduced Entan,..,lement Incorrect Pack Recoverabilitv 4 5 Partial or No Tangled or I Rotation Foul inn twisted lines 3 5 Partial or No Tangled or Rotation Fou!ino twisted lines 3 5 Partial or No Mis-specified Tangled or Rotation swivel twisted lines 5 5 Partial or No Thermal Tangled or Rotation Exnansion twisted lines 1 5 Partial or No Thermal Tangled or Rotation Ex"ansion twisted lines 1 5 Partial or No High Coeffof Tangled or Rotation ball friction twisted lines 1 5 Partial or No High Coeffof Tangled-or Rotation bait friction twisted lines 1 5 Incorrect line Reduced Entanc lement Recoverabilitv 1 5 Component Broken Hooks Stress /overuse Detachment 1 2 Broken Hooks I Component Mis-soeoified Detachment 1 2 1 See McMahon Broken Hooks i Failures None 1 1 Detection RPN Action Pack per mfg. 10 300 instructions Pack per mfg. 5 150 instructions 5 100 Pre-fli ht insoection 5 100 Increase waddino 5 100 Flame retard line Pack per mfg. I 5 100 instructions I 10 100 Increase waddina I 5 100 lnsoect 10 i 100 !nsoect 10 I 100 Pre-flinht insnection I 10 I 100 Heavier aaae I Inspection or 5 50 reo!acement 1 50 Heavier oaoe hook 2 40 Line replacement 1 I 10 Pre-flioht insoection 1 "' ,Heavieroaae 5 35 Inspect 1 21 lnsoect I Pack per mfg. 10 200 instructions Clean/replace after 10 150 l!ioht i Increase recovery 10 150 waddina 5 125 lar er Hook Increase Recovery 10 50 wadding Hook with different 10 50 roDerties 1 5 lubricate 1 5 Re lace 1 5 Chance line oaae I Inspection or 3 6 re lacement 3 6 Heavier nane hook i 1 1 Figure A.4 Sorted FMEA by Severity 54

PAGE 63

01 01 Component Nylon Parachute Mode of Failure No deployment No deployment PHOENIX RECOVERY SYSTEM FMEA Cause of Effect of Frequency Degree Chance Risk Process Action Remarks Failure Failure of of of Priority 0' Occurence Severity Detection Number Design Entanglement Reduced 3 10 10 300 p Package per recoverability mfg. instructions Entanglement Reduced 1 10 10 100 D Redesign recoverability parachute pack Figure A.5 Phoenix Recovery System DFMEA and PFMEA

PAGE 64

imperative prior to starting a FMEA. The cursory analysis of the Phoenix recovery system yielded many failure modes. The values to determine the RPN numbers were not 'scientific' by any means. Nevertheless, the goal of targeting a failure mode in need of corrective action was met. 56

PAGE 65

APPENDIX B CASE STUDY B STRATEGIC TEST DESIGN MATRIX New product development at a beverage company' in the form of packaging products (i.e. aluminum cans and lids) prompted the development of an approach to guarantee that new designs would provide customer required functionality at time of introduction into the marketplace. A system was developed to address consumer functionality requirements based upon the general premises of a classic FMEA but modified to address management expectations and requirements. A cross-functional team consisting of representives from the disciplines of Quality Engineering, Quality Assurance and Research and Development developed a Strategic Design Matrix (STD) during the Spring of 1996. The STD matrix provides a "scorecard" to upper management on tracking and evaluating risk of new products during pre-production or development stages. The STD is driven by consumer requirements e.g. leaking container, loss of C02 openability, etc., to better anticipate possible risks prior to introduction to the field. The STD matrix is shown in figure 8.1. The matrix consists of 12 columns which are largely self explanatory. The key feature of the STD which has made it successful is the success status column. This column is coded as green, yellow or red indicating no risk, potential risk and failure, respectively. The coding is determined by comparing test results against pre-determined success criteria. For example, a customer requirement is no container leakage. A possible test would be to ship test product with control product and evaluate the two samples. If leakage is found in the test sample and the success criteria states the absence of leakers, the success status column would be colored red along with a test reference number or name of the experimenter. On the other hand, if no 1 The company which developed the STD I with the author's assistance) asked not be to referred to by name in this paper. 57

PAGE 66

()"! OJ Strategic Test Design Matrix Consumer Potential Cause(s) Tests for Consumer Decision Date Risk Probability Proceed to Next Qualification Issues of Consumer Design (D) or Issues (Design Packaging Department (Individual Success Success Based on Test Given Test Phase Based on Phase Issues location Res nsibfe Crlteria Passed Warning (potential risk) Failed (risk known) status Figure 8.1 Strategic Test Design Matrix Results Results Test

PAGE 67

leakers are found but the sample size is small, the column may be colored yellow indicating caution since the small sample may not detect a problem with a potentially small defect rate (low statistical power). In this manner, management can quickly glance at the STD matrix and pinpoint areas of concern via the color coding. Specific points related to risk are explained under the risk probability given test results column and can be based on statistical information derived from a test, such as a "p" value for example. Decision date and proceed to next phase columns allow management to see how results are affecting project timelines. The key to success in development of the STD matrix was through the use of a cross-functional team which not only brainstormed how the matrix should look like, but also to develop a list of the customer requirements and failure modes. The STD matrix is a new concept and work continues on its development. Specifically, the approach needs to be carried over into production phases of new designs in order to address possible failures caused by manufacturing variability. Failure modes and customer requirements at later production stages can be detailed through the use of a standard FMEA approach with critical elements subsequently transferred to the STD matrix along with testing requirements. Additional concerns with the STD matrix are with effectively communicating success status to a broader group of individuals that may be connected with a particular development project. 59

PAGE 68

APPENDIX C CASE STUDY C FMEA COMPUTER IMPLEMENTATION A wide variety of computer programs exist to accomplish the goals of a Failure Mode Effects Analysis. Specialized programs can be developed using a programming language and a compiler. One such program was developed using Borland's Turbo PASCAL version 6.0. The structured program developed is called "Failure Mode Effects Analysis", (executable file designation is FMEA.EXE) and is based on elements found in MIL-STD-1629A and the book Knowledge Based Management under the chapter "Failure Mode and Effects Analysis" (26, p. 132). Specifically, a system is defined and components of the system are listed with failure modes, causes, probabilities and severities. A risk priority number is defined as the product of a failure's occurrence and severity. The program uses two base screens to develop the analysis. The first screen, Figure C.1 is used select for data entry, display, sorting and graphing routines. Selecting the graphing function brings up a second screen, Figure C.2, to graph elements of a FMEA data file in different formats. Sorting is accomplished through the screen shown in Figure C.3. The program allows components of a system to be entered into a file along with failure mode, failure probability, failure effect, failure severity, failure cause and calculated component risk as shown in the in figure C.4. Each component entered is given an identification number. Currently no corrective action column is included in the software. The data that is entered provides a quick overview of risk for individual components when manipulated with the graphics option. The graphics option will allow the component identification numbers to be graphed on a criticality matrix as adopted from MIL-STD-1629A or to be broken down by failure probability, failure severity and overall risk and graphed as a stem and leaf type plots. Examples of each are shown in Figures C.5, C.6, C.7 and C.8, respectively, along with a listing of the actual data file 60

PAGE 69

R E C 0 R D MANAGER [ 1] Input FMEA Data [D] Display FMEA Table [G] Graphical Display [S] Sort FMEA Data [ Q] 00 I T THE PROGRAM Figure C.1 FMEA Data Manipulation Options Failure Mode Effects Graphing [C] Criticality Matrix [OJ Stan and Leaf of Occnrrence [S] Stan and Leaf of Severity [R] Stem and Leaf of Risk [Q] OOIT ROUTINE Figure C.2 FMEA Data Graphing Options Failure Mode Effects Scrting [P] Scrt on Probability [S] Sort on Severity [R] Sort on Risk [ I ] Sort on !D Number [Q] QUIT ROUTINE Figure C.3. FMEA Sorting Options 61

PAGE 70

ID Conponent 1 Engine 2 Coo 1 ing 3 Exhaust 4 Trans Failure Mode Effects Worksheet Failure Mode Misfires Overheats Leaks S 1 ips Prob 2 4 2 3 Failure Effect Low rnpg Engine damage ex> en iss ions Severe 2 9 10 Failure Cause Dirty Injectors Pocr flow Faulty joints Rlsk 4 36 20 PROB: 1 =Unlikely .. 10 =Certain SEVERE: 1 :No Impact .. 10: High Impact Figure C.4 FMEA Data Entry Screen 62

PAGE 71

+----+----+----+----+----+----+----+----+----+----+----+ p r 0 b a b t y 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + + 11 6 4 7 10 Criticality + Matrix + File 9 5 + ---------AUTO + + System ----------12 + Autarobile 2 + Date + ----------9/18/1996 3 + 8 + +----+----+----+----+----+----+----+----+----+----+----+ 1 2 3 4 5 6 7 8 9 10 Severity Failure Mode Effects Summary File AUTO System : Automobile Date 9/18/1996 I D Carponent 1 Engine 2 Cooling 3 Exhaust 4 Trans 5 Steering 6 Tires 7 Elect 8 Air Bag 9 Brakes 10 Cruise 11 Body 12 Fuel Purp Failure Mode Misfires OVerheats Leaks s 1 ips Play Rapid wear Battery wear No deployment Grab No operation leaks Low ps 1 Prob 2 4 2 3 8 3 2 1 8 2 5 5 Failure Effect Severe Low rrpg 2 Engine damage 9 CO emissions 10 Low perfonm 6 No control iO High cost 3 High cost 3 No safety 10 No control 9 No speed cntrl 5 Wet interior 2 Uneven run 7 Failure Cause Risk Dirty injectors 4 Poor flow 36 Faulty joints 20 Internal damage 18 Tie rods damaged 80 Low pressure 9 Shorted wiring 6 Defective bag 10 Binded linkage 72 Computer fault 10 Poor body fit 10 Faulty valve 35 Figure C.5 Criticality Matrix of a FMEA Data Set (by ID) 63

PAGE 72

F i ie 8 AUTO 10 7 3 6 4 Systar1 Autcrrobi le Stem and Leaf Matr1x 2 Occ:.J.rrence 12 11 Date 9 5 9/18/1996 2 3 4 5 6 7 8 9 10 Not Likely Likely File 10 Corponent 9 Brakes 5 Steering 11 Body 12 Fuel PUT!) 2 cooling 6 Tires 4 Trans 3 Exhaust 1 Engine 10 Cruise 7 Elect 8 Air Bag Failure Mode Effects Sunrary AUTO Failure Mode Grab Play Leaks Low psi Overheats Rapid wear S 1 ips leaks Misfires No operation Battery wear No dep 1 oyment System: Automobile Date 9/18/1996 Prob Failure Effect Severe Failure Cause 8 8 5 5 4 3 3 2 2 2 2 1 No control 9 No control 10 Wet interior Uneven run 7 Engine damage 9 High cost 3 Low perform 6 CO emissions 10 Low rrpg 2 No speed cntr 1 5 High cost 3 No safety iO Blnded linkage Tie rods damaged Poor body fit Faulty valve Poor flow Low pressure Internal damage Faulty joints Dirty injectors Corputer fault Shorted wiring Defective bag Figure C.6 Stem and Leaf Plot of FMEA Probabilities (by ID) 64 Risk 72 80 10 35 36 9 18 20 4 10 6 10

PAGE 73

File AUTO 11 1 7 6 System Automobile Stem and Leaf Matrix Severity 10 4 12 Date 9/18/1996 9 2 8 5 3 +----+----+----+----+----+----+----+----+----+ 2 3 4 5 6 7 8 9 10 Not Severe Severe File !D Coi'ponent 8 Air Bag 5 Steering 3 Exhaust 9 Brakes 2 Cooling 12 Fuel PL111P 4 Trans 10 Cruise 6 Tires 7 Elect 1 Engine 11 Body Failure Mode Effects Summary AUTO System: Automobile Date 9/18/1996 Failure Mode Prob Failure Effect Severe Failure cause Risk No deployment Play Leaks Grab Overheats Low psi Slips No operation Rapid wear Battery wear Misfires Leaks 1 8 2 8 4 5 3 2 3 2 2 5 No safety No control 10 10 ro emissions 10 No control 9 Engine damage 9 Uneven run 7 Low perfonn 6 No speed cntrl 5 High cost 3 High cost 3 Low 01Jg 2 Wet interior 2 Defective bag 10 Tie rods damaged 80 Faulty joints 20 Binded linkage 72 Poor flow 36 Faulty valve 35 Internal damage 18 Computer fault 10 Low pressure 9 Shorted wiring 6 Dirty injectors 4 Poor body fit 10 Figure C. 7 Stem and Leaf Plot of FMEA Severities (by I D) 65

PAGE 74

File ALJTO 7 6 1 11 10 8 4 3 System: Automobile Stem and Leaf Matrix 12 2 Risk Date 9/18/1996 9 5 +------+------+------+------+------+------+------+------+------+------+ 1-9 10-19 20-29 30-39 40-49 50-59 60-69 70-79 80-89 90-100 Low Risk High Risk Failure Mode Effects Summary File ALJTO ID Ccrrponent 5 Steering 9 Brakes 2 cooling 12 Fuel Pl.ll'!' 3 Exhaust 4 Trans 8 Air Bag 11 Body 10 Cruise 6 Tires 7 Elect Engine Failure Mode Play Grab Overheats Low psi Leaks Slips No dep 1 oyment Leaks No operation Rapid wear Battery wear Misfires System: Automobile Date 9/18/1996 Prob Failure Effect Severe Failure Cause Risk 8 8 4 5 2 3 1 5 2 3 2 2 No control No control Engine damage Uneven run 10 9 9 7 CO emissions 10 Low perform 6 No safety 10 Wet interior 2 No speed cntrl 5 High cost 3 High cost 3 Low rrpg 2 Tie rods damaged 80 Binded linkage 72 Poor flow 36 Faulty valve 35 Faulty joints 20 Internal damage 18 Defective bag 10 Poor body fit 10 Computer fault 10 Low pressure 9 Shorted wiring 6 Dirty injectors 4 Figure C.8 Stem and Leaf Plot of FMEA Risk (by ID) 66

PAGE 75

used. The program provides the mechanism to quickly determine high risk items in a system. The basis behind the analysis relies on standard methods of developing a FMEA such as determining correct requirements and operating phases for a system and determination of the level of detail needed. A summary of program elements is provided in the following matrix: Program Elements for FMEA EXE Program Components Function (.PAS) FMEA Procedure LocateFile Assign a file tor data entry, display or manipulation. Main program driver Key menu items for data input, data file display, data sorting and data graphing. FMEADATA Procedure AddRecord Input tor the FMEA data sheet. (Unit) Procedure Display Display a FMEA data tile. Procedure Sort Menu options tor sorting failure occurrence, failure severity, combined risk or component ID categories. FMEAMAT Procedure GraphSelect Menu options for presenting the data in the !Unit) form of a criticality matrix or stem and leaf plot for failure occurrence, severity or avera!! risk. Procedure GraphDisplay Mechanism tor displaying FMEA data in the appropriate user selected formats to the screen. FMEASORT Function Prob_Less_ Than Ordering of pairs of failure occurrence (Unit) values. Function Severe Less Than Ordering of pairs of failure severity values. Function Risk Less Than Ordering of pairs of combined risk values. Function ID _Less_ Than Ordering of pairs of component identification values. Procedure QuickSort The actual sorting routine. Boolean values from the functions are passed into this procedure for processing. The source code for the software is listed on the following pages and includes all the Pascal components used to gather, sort and display 67

PAGE 76

data starting with the main program driver. The sorting routine was based on work developed by Professor Zenas Hartvigson for PASCAL programming coursework at the University of Colorado at Denver (8). A degree of editing was necessary in order to properly format the source code to the report but the overall program is unchanged from the actual working version. 68

PAGE 77

FMEA.PAS PROGRAM Fmea; { } PROSPECTUS This program driver was developed to utilize various program components to act as a vehicle in performing a Failure Mode Effects Analysis. Specifically, the units called are FmeaMat FmeaSort FmeaData Graphing of FMEA data Routine for sorting FMEA data files Unit for allowing a user to build a FMEA file The FMEA format is a modification of the one outlined under MIL-STD-1629A and the book Knowledge Based Mangement by Schmidt, Kiemele and Berdine (Air Academy Press, 1996) in order to provide a fundamental way in which to quickly determine critical failure modes in a system or process. AUTHOR Written by Tony Gojanovic, Summer 1996. Compiled with Borland Turbo Pascal Version 6.0. USES Crt, FmeaMat, FmeaSort, FmeaData; {Graphing of FMEA data} {Sorts the FMEA data} {The record manager unit for FMEA data} {****************************************************} PROCEDURE LocateFile (VAR Routine,lnFile: STRING); {Prompt the user for the location of the file he/she wishes to process ... } VAR Key, {Part of pause and data entry routines ... } Answer : CHAR; 69

PAGE 78

BEGIN ClrScr; Answer : = 'N'; WHILE Answer < > 'Y' DO BEGIN TEXTCOLOR(WHITE); Gotoxy(02,08); WRITE(OUTPUT: Please Input The Path And Filename of the file to be ',Routine); Gotoxy(04, 1 0); TEXTCOLOR(Yellow); WRITE(OUTPUT: --> <--'); Gotoxy(29, 1 0); READLN(INPUT,InFile); TEXTCOLOR(WHITE); REPEAT Gotoxy(50, 12); WRITE(OUTPUT: '); Gotoxy(02, 12); WRITE(OUTPUT: Your drive\directory\ filename selection is '); Gotoxy(55, 12); TEXTCOLOR(Yellow); WRITE(OUTPUT,InFile); TEXTCOLOR(WHITE); Gotoxy(02, 13); WRITE(OUTPUT: Is this correct (Y/N)?'); Gotoxy(32, 13); Answer:= Read Key; Answer : = UPCASE(Answer); UNTIL (Answer = 'Y') OR (Answer = 'N'); WRITELN(OUTPUT); END; TEXTCOLOR(LightGray); END; {End of procedure LocateFile} {**** ** * ********MAIN PROGRAM DRIVER**** ** * * ** * *} VAR End it Choice, Continue, Key :BOOLEAN; :CHAR; {Part of looping controls} {Used in user selections} 70

PAGE 79

GraphFile, Routine Type, DataFile : STRING; {Tracking of filenames and analysis types} BEGIN End it : = TRUE; Choice:= '; {Variable initialization} Key : = ,; Routine Type : = '; {Main menu with choices and input prompts} TEXTBACKGROUND(BLUE); REPEAT REPEAT ClrScr; TEXTBACKGROUND(BLUE); TEXTCOLOR(White); Gotoxy(20,3); WRITE(OUTPUT,'R E C 0 R D M A N A G E R '); Gotoxy(20,4); WRITE ( 0 UTPUT, '-----------------------------------------'); TEXTCOLOR(Yellow); Gotoxy(30,9); DELAY(150); WRITE(OUTPUT,'[I] Input FMEA Data'); Gotoxy(30, 11); DELAY(150); WRITE(OUTPUT,'[D] Display FMEA Table'); Gotoxy(30, 13); DELAY(150); WRITE(OUTPUT,'[G] Graphical Display'); Gotoxy(30, 15); DELAY(150); WRITE(OUTPUT,'[S] Sort FMEA Data'); Gotoxy(30, 17); DELAY(150); WRITE(OUTPUT,'[Q] QUIT THE PROGRAM'); choice: =UPCASE(ReadKey); {Read what key has been pressed -convert to caps } UNTIL (Choice = 'D') OR (Choice = 'S') OR (Choice = 'I') OR (Choice = 'G') OR (Choice = 'Q'); 71

PAGE 80

ClrScr; CASE Choice OF {Choices tor the program} 'I' : BEGIN {Input data} ClrScr; RoutineType : = 'INPUT'; Locate File (Routine Type, Data File); AddRecord(RoutineType,DataFile); END; 'D' :BEGIN {Display a data file} ClrScr; Routine Type : = 'DISPLAYED'; LocateFile(RoutineType, DataFile); Display(DataFile); END; 'S' : BEGIN {Sort a data file} Routine Type : = 'SORTED'; LocateFile(Routine Type,DataFile); Sort(DataFile); END; 'G' : BEGIN {Graphing a data tile} RoutineType : = 'CHARTED'; LocateFile(RoutineType, Data File); GraphSelect(DataFile); END; 'Q' : BEGIN END; End it : = FALSE; END; UNTIL Endlt < > TRUE; {End of choices} END. {End of program driver} 72

PAGE 81

FMEADATA.PAS UNIT FmeaData; {This unit is utilized for data entry and display} INTERFACE TYPE MasterRecord = RECORD {Defining the record} System, {The type of system to be studied} Mission, {The purpose and operating range of the system} Component, {The components that make up the system} Failure, {The failure of a specific component} Cause, {What caused the failure to happen} Effect : STRING [25]; {The effect system failure} ID, {A numeric assigned to the component} FMEADay, {The day on which the FMEA was performed} FMEAMonth, {The month of the FMEA} FMEAYear, {The year on which the FMEA was performed} Occurrence, {The liklihood of the failure} Severity, {The severity of the failure} Risk : INTEGER {The combined risk number of occurrence and severity} END; MasterRecordFile = FILE OF MasterRecord; PROCEDURE AddRecord (VAR Operation,DataSource: STRING); PROCEDURE Display (DataToDisplay : STRING); PROCEDURE Sort (DataToSort : STRING); {*****************************************************} IMPLEMENTATION USES Graph, Dos, BGIDriv, {Pascal Graphics Unit} {Dos unit } { all the BGI drivers } 73

PAGE 82

BGIFont, { all the BGI fonts } Crt, {CRT device unit } FmeaSort; {The sorting unit for the FMEA data sets} CONST GraphMode : INTEGER = 0; {Initialize graphics to appropriate graph mode} {*****************************************************} PROCEDURE AddRecord (VAR Operation,DataSource : STRING); {This procedure is utilized to develop a data file used in the FMEA study} VAR key :CHAR; {Used in pausing} F _Mission, F_System, {Variables used in collecting user information} F _Component, F _Failure, F _Effect, F Cause MstrFile Mstrlnfo TDay, TMonth, TYear, F_ld, : STRING [25]; : MasterRecordFile; : MasterRecord; I, {Indexing variable} yCount, {Part of screen formatting} F _Occurrence, F _Severity, F Risk Finished : INTEGER; :BOOLEAN; BEGIN yCount: = 8; F_ID := 1; F _Component:= '; BEGIN {Screen formatting and data entry} ClrScr; TEXTCOLOR(White); Gotoxy(23,2); 74 {Used to terminate data entry}

PAGE 83

WRITE(OUTPUT,'Failure Mode Effects Worksheet'); Gotoxy(30,3); WRITE(OUTPUT,'File Information'); Gotoxy(29,7); WRITE(OUTPUT,'System : '); READLN(INPUT,F _System); Gotoxy(29,9); WRITE(OUTPUT,'Mission : '); READLN(INPUT,F _Mission); REPEAT Gotoxy(45, 11 ); ClrEOL; Gotoxy(25, 11 ); WRITE(OUTPUT,' Month (1 .. 12) = '); Gotoxy(45, 11 ); TEXTCOLOR(White); READLN(INPUT,TMonth); UNTIL (TMonth > = 1) AND (TMonth < = 12); REPEAT Gotoxy(45, 12); ClrEOL; Gotoxy(25, 12); WRITE(OUTPUT,' Date (1 .. 31) = '); Gotoxy(45, 12); TEXTCOLOR(White); READLN(INPUT, TDay); UNTIL (TDay > = 1) AND (TDay < = 31); REPEAT Gotoxy(45, 13); ClrEOL; Gotoxy(25, 13); WRITE(OUTPUT,'Year (1996 .. 2100) = '); Gotoxy(45, 13); READLN(INPUT,TYear); UNTIL (TYear > = 1996) AND (TYear < = 2100); Gotoxy(25,24); WRITE(OUTPUT,'Press Any Key To Continue'); END; ASSIGN(MstrFile,DataSource); REWRITE(MstrFile); REPEAT 75

PAGE 84

IF ((yCount = 23) OR (yCount = 8)) THEN BEGIN ClrScr; yCount: = 8; TEXTBACKGROUND(BLUE); TEXTCOLOR(White); Gotoxy(23,2); WRITE(OUTPUT,'Failure Mode Effects Worksheet'); Gotoxy(23,3); WRITE ( 0 UTPUT, '------------------------------'); Gotoxy( 1 6); WRITE(OUTPUT, 'ID'); Gotoxy(4,6); WRITE(OUTPUT, 'Component'); Gotoxy(17,5); WRITE(OUTPUT, 'Failure'); Gotoxy(17,6); WRITE(OUTPUT,' Mode '); Gotoxy(30,6); WRITE(OUTPUT,'Prob'); Gotoxy(38,5); WRITE(OUTPUT,'Failure'); Gotoxy(38, 6); WRITE ( 0 UTPUT,' Effect'); Gotoxy(50,6); WRITE(OUTPUT,'Severe'); Gotoxy ( 62,5); WRITE(OUTPUT, 'Failure'); Gotoxy( 62, 6); WRITE(OUTPUT,' Cause'); Gotoxy(75,6); WRITE(OUTPUT, 'Risk'); Gotoxy( 1 ,7); WRITE ( 0 UTPUT, '----------------------------------------------------------------'); TEXTCOLOR(Yellow); Gotoxy(2,24); WRITE(OUTPUT,'PROB: 1 =Unlikely .. 10 =Certain SEVERE: 1 = No Impact .. 10 = High Impact'); END; TEXTCOLOR(LightCyan); Gotoxy( 1, yCount); 76

PAGE 85

WRITE(OUTPUT,F _I D); Gotoxy(4, yCount); READLN(INPUT,F _Component); IF F_Component <>'*'THEN {Termination of data entry} BEGIN Gotoxy(15,yCount); READLN(INPUT,F _Failure); REPEAT Gotoxy(31, yCount); ClrEOL; READLN(INPUT,F _Occurrence); UNTIL (F _Occurrence > = 1) AND (F _Occurrence < = 1 0); Gotoxy(37, yCount); READLN(INPUT,F _Effect); REPEAT Gotoxy(52, yCount); ClrEOL; READLN(INPUT,F _Severity); UNTIL (F_Severity > = 1) AND (F_Severity < =10); Gotoxy(58, yCount); READLN(INPUT,F _Cause); F _Risk:= F _Occurrence*F _Severity; Gotoxy(76, yCount); WRITE(OUTPUT,F _Risk); yCount : = yCount + 1 ; ASSIGN(MstrFile,DataSource); RESET ( MstrFile); SEEK(MstrFile,FILESIZE(MstrFile)); {Appending of the file} Mstrlnfo.System : = F _System; Mstrlnfo.Mission : = F _Mission; Mstrlnfo.ID : = F _ld; Mstrlnfo.Component : = F _Component; Mstrlnfo.Failure : = F _Failure; Mstrlnfo.Occurrence: = F _Occurrence; Mstrlnfo.Effect : = F _Effect; Mstrlnfo.Cause := F_Cause; Mstrlnfo.Severity : = F _Severity; Mstrlnfo.Risk : = F _Risk; Mstrlnfo.FMEADay : = TDay; Mstrlnfo.FMEAMonth : = TMonth; Mstrlnfo.FMEAYear: = TYear; 77

PAGE 86

WRITE(MstrFile,Mstrlnfo); F _ld : = F _ld + 1; CLOSE (MstrFile); END; UNTIL (F_Component = '*'); END; {End of procedure AddRecord} {****************************************************} PROCEDURE Display (DataToDisplay : STRING); {Procedure display opens a FMEA data file and displays the contents to screen} VAR TempFile : MasterRecordFile; {The FMEA file ... } ContinueChoice, Key :CHAR; Rec : MasterRecord; Record Number, Counter, Record No, yCount, I :INTEGER; BEGIN {Part of pause} {The record structure} {Part of screen formatting} {Used to read record number} {Part of screen formatting} RecordNo : = 0; {Variable initialization} Record Number : = 0; Counter : = 1; yCount : = 9; Counter : = 0; ASSIGN (TempFile, DataToDisplay); {Assigning the file to be opened} RESET (TempFile); REPEAT SEEK (TempFile, RecordNo); READ (TempFile, Rec); IF ((yCount = 23) or (yCount = 9)) THEN BEGIN ClrScr; yCount : = 9; {Screen formatting} TEXTBACKGROUND(BLUE); TEXTCOLOR(White); Gotoxy(23, 1 ); WRITE(OUTPUT,'Failure Mode Effects Summary'); 78

PAGE 87

Gotoxy(23,2); WRITE(OUTPUT, '------------------------------'); Gotoxy(10,4); WRITE(OUTPUT,'File: ',DataToDisplay); Gotoxy(30,4); WRITE(OUTPUT,'System : ',Rec.System); Gotoxy(55,4); WRITE(OUTPUT, 'Date:' ,Rec.FMEAMonth,' /', Rec.FMEADay,' /' ,Rec.FMEAYear); Gotoxy( 1, 7); WRITE(OUTPUT,'ID'); Gotoxy(4, 7); WRITE(OUTPUT,'Component'); Gotoxy( 17, 6); WRITE(OUTPUT, 'Failure'); Gotoxy(17, 7); WRITE(OUTPUT,' Mode '); Gotoxy(30, 7); WRITE(OUTPUT,'Prob'); Gotoxy(38,6); WRITE(OUTPUT,'Failure'); Gotoxy(38, 7); WRITE(OUTPUT,'Effect'); Gotoxy(50, 7); WRITE(OUTPUT,'Severe'); Gotoxy(62,6); WRITE(OUTPUT, 'Failure'); Gotoxy(62, 7); WRITE(OUTPUT,' Cause'); Gotoxy(75,7); WRITE(OUTPUT, 'Risk'); Gotoxy(1 ,8); WRITE ( 0 UTPUT, '---------------------------------------------------------------'); TEXTCOLOR(Yellow); END; {End of formatting} BEGIN {Beginning of data file reading and display} WITH Rec DO BEGIN TEXTCOLOR(LightCyan); Gotoxy(1 ,yCount); WRITE(OUTPUT,ID:2); 79

PAGE 88

Gotoxy(4, yCount); WRITE(OUTPUT,Component); Gotoxy(15,yCount); WRITE(OUTPUT,Failure); Gotoxy(31, yCount); WRITE(OUTPUT,Occurrence); Gotoxy(37, yCount); WRITE(OUTPUT,Ettect); Gotoxy(52,yCount); WRITE(OUTPUT,Severity); Gotoxy(58,yCount); WRITE(OUTPUT,Cause); Gotoxy(76, yCount); WRITE(OUTPUT,Risk); Record No : = Record No + 1; yCount : = yCount + 1; END; END; IF yCount = 23 THEN key : = Read key; UNTIL EOF(TempFile); CLOSE(TempFile); key:= Readkey; END;{End of procedure Display} {****************************************************} PROCEDURE Sort (DataToSort : STRING); {Procedure Sort prompts the user to sort an FMEA file on various columns} {Calls on the unit FMEASort} VAR Choice, {Variables tor screen formatting and prompts} TypeSort, key :CHAR; EndRoutine : BOOLEAN; I :INTEGER; BEGIN End Routine : = TRUE; REPEAT REPEAT 80

PAGE 89

ClrScr; TEXTBACKGROUND(BLUE); TEXTCOLOR(White); Gotoxy(23,3); WRJTE(OUTPUT,'Failure Mode Effects Sorting'); Gotoxy(23,4); WRITE ( 0 UTPUT, '------------------------------'); Gotoxy(23, 7); WRITE(OUTPUT,'[P] Sort on Probability'); Gotoxy(23,9); WRITE(OUTPUT,'[S] Sort on Severity'); Gotoxy(23, 11 ); WRITE(OUTPUT,'[RJ Sort on Risk'); Gotoxy(23, 13); WRITE(OUTPUT,'[I] Sort on ID Number'); Gotoxy(23, 15); WRITE(OUTPUT,'[Q] QUIT ROUTINE'); choice:= UPCASE(ReadKey); {Read what key has been pressed} UNTIL (Choice = 'P') OR (Choice = 'S') OR (Choice = 'R') OR (Choice = 'I') OR (Choice = 'Q'); CASE Choice OF 'P' : BEGIN {Sort on failure occurrence} ClrScr; gotoxy(25, 12); TextColor(Yellow); WRITE(OUTPUT,'Sorting ', DataToSort,' on Probability'); QuickSort(DataToSort,Prob _Less_ Than); FOR I : = 1 TO 15 DO BEGIN Gotoxy(25 +I, 14); WRITE(OUTPUT,' .'); DELAY(1 00); END; Gotoxy(25, 16); WRITE(OUTPUT,'Press Any Key To Continue'); key : = Read key; END; 'S' : BEGIN {Sort on failure severity} ClrScr; gotoxy(25, 12); 81

PAGE 90

TextColor(Yellow); WRITE(OUTPUT,'Sorting ',DataToSort,' on Severity'); QuickSort(DataToSort,Severe _Less_ Than); FOR I : = 1 TO 15 DO BEGIN Gotoxy(25 +I, 14); WRITE(OUTPUT,' .'); DELAY(100); END; Gotoxy(25, 16); WRITE(OUTPUT,'Press Any Key To Continue'); key : = Read key; END; 'R' : BEGIN {Sort on combined risk value} ClrScr; gotoxy(25, 12); TextColor(Yellow); WRITE(OUTPUT,'Sorting ',DataToSort,' on Risk'); QuickSort(Data To Sort, Risk_ Less_ Than); FOR I : = 1 TO 15 DO BEGIN Gotoxy(25 +I, 14); WRITE(OUTPUT,'.'); DELAY(100); END; Gotoxy(25, 16); WRITE(OUTPUT,'Press Any Key To Continue'); key : = Read key; END; 'I' : BEGIN {Sort on component ID} ClrScr; gotoxy(25, 12); TextColor(Yellow); WRITE(OUTPUT,'Sorting ',DataToSort,' on ID Number'); QuickSort(DataToSort,ID _Less_ Than); FOR I : = 1 TO 15 DO BEGIN Gotoxy(25 +I, 14); WRITE( OUTPUT,'.'); DELAY(100); END; 82

PAGE 91

Gotoxy(25, 16); WRITE(OUTPUT,'Press Any Key To Continue'); key : = Read key; END; 'Q' :BEGIN END; EndRoutine : = FALSE; END; UNTIL EndRoutine < > TRUE; END; {End of procedure Sort} {****************************************************} BEGIN END. 83

PAGE 92

FMEAMAT.PAS UNIT FmeaMat; {This unit is used for graphing of failure mode data obtained in FmeaData} INTERFACE TYPE MasterRecord = RECORD {Defining the record} System, {The type of system to be studied} Mission, {The purpose and operating range of the system} Component, {The components that make up the system} Failure, {The failure of a specific component} Cause, {What caused the failure to happen} Effect : STRING [25]; {The effect system failure} ID, {A numeric assigned to the component} FMEADay, {The day on which the FMEA was performed} FMEAMonth, {The month of the FMEA} FMEAYear, {The year on which the FMEA was performed} Occurrence, {The liklihood of the failure} Severity, {The severity of the failure} Risk : INTEGER {The combined risk number of occurrence and severity} END; MasterRecordFile = FILE OF MasterRecord; PROCEDURE GraphDisplay (DataFile : STRING; Routine : CHAR); PROCEDURE GraphSelect (VAR DataFile: STRING); {*****************************************************} IMPLEMENTATION USES Graph, {Pascal Graphics Unit} Dos, {Dos unit } BGIDriv, {all the BGI drivers} BGIFont, {all the BGI fonts } FmeaSort, {Sort routine for FMEA data} Crt; {CRT device unit } CONST GraphMode : INTEGER = 0; {Initialize graphics to appropriate 84

PAGE 93

graph mode} {****************************************************} PROCEDURE GraphSelect (VAR DataFile : STRING); {Screen displays to prompt the user for a graphing selection} VAR Choice, {Variables used in screen formatting and prompts} TypeSort, GraphRoutine, key :CHAR; EndRoutine : BOOLEAN; I :INTEGER; BEGIN End Routine : = TRUE; REPEAT REPEAT {Screen formatting and options} ClrScr; TEXTBACKGROUND(BLUE); TEXTCOLOR(White); Gotoxy ( 23, 3); WRITE(OUTPUT,'Failure Mode Effects Graphing'); Gotoxy(23,4); WRITE (OUTPUT,'-----------------------------'); Gotoxy(23, 7); WRITE(OUTPUT,'[Cl Criticality Matrix'); Gotoxy(23,9); WRITE(OUTPUT,'[O] Stem and Leaf of Occurence'); Gotoxy(23, 11); WRITE(OUTPUT,'[S] Stem and Leaf of Severity'); Gotoxy(23, 13); WRITE(OUTPUT,'[R] Stem and Leaf of Risk'); Gotoxy(23, 15); WRITE(OUTPUT,'[Q] QUIT ROUTINE'); choice:= UPCASE(ReadKey); {Read what key has been pressed -convert to caps} UNTIL (Choice = 'C') OR (Choice = '0') OR (Choice = 'S') OR (Choice = 'R') OR (Choice = 'Q'); 85

PAGE 94

CASE Choice OF 'C' : BEGIN {Criticality graph} GraphRoutine : = 'C'; GraphDisplay (DataFile, GraphRoutine); END; '0' : BEGIN {Stem and Leaf of failure occurrence} GraphRoutine: = '0'; Graph Display (DataFile, GraphRoutine); END; 'S' : BEGIN {Stem and Leaf of failure severity} GraphRoutine : = 'S'; Graph Display (Data File, GraphRoutine); END; 'R' : BEGIN {Stem and Leaf of combined risk measure} GraphRoutine : = 'R'; GraphDisplay (DataFile,GraphRoutine); END; 'Q' : BEGIN {Quit the routine} EndRoutine : = FALSE; END; END; UNTIL EndRoutine < > TRUE; END; {End of procedure GraphSelect} {****************************************************} PROCEDURE GraphDisplay (DataFile: STRING; Routine : CHAR); {Procedure to display failure data in different modes} VAR TempFile Key Rec I' J, K, L, Occ, Sev, R, : MasterRecordFile; :CHAR; : MasterRecord; {Variables for screen formatting and display} y1 'y2,y3,y4,y5,y6,y7,y8,y9,y1 0, x1 ,x2,x3,x4,x5,x6,x7,x8,x9,x1 0, 86

PAGE 95

xAxis, yAxis, Index, xCount, yCount, Spacer, pCount, Record No :INTEGER; BEGIN ClrScr; {Variable initialization} xCount : = 11 ; RecordNo : = 0; I := 0; Index : = 0; Spacer : = 0; yCount : = 1; pCount 10; y1 := 18; y2 := 18; y3 := 18; y4 := 18; y5 := 18; y6 := 18; y7 : = 18; y8 := 18; y9 := 18; y1 0: = 18; CASE Routine OF 'C' : {Criticality} {Matrix} BEGIN ClrScr; {Formatting the criticality matrix} FOR Spacer : = 1 TO 2 DO BEGIN FOR I : = 11 TO 65 DO BEGIN Gotoxy(l, yCount); WRITE(OUTPUT,' -'); END; FOR I : = 1 TO 12 DO 87

PAGE 96

BEGIN Gotoxy(xCount, yCount); WRITE( OUTPUT,'+'); xCount : = xCount + 5; END; xCount : = 11; yCount : = 23; END; FOR Spacer : = 2 TO 22 DO BEGIN Gotoxy(11 ,Spacer); WRITE(OUTPUT,' l '); Gotoxy(66,Spacer); WRITE(OUTPUT,' l '); END; yCount: = 3; FOR I : = 1 TO 1 0 DO BEGIN Gotoxy(11 ,yCount); WRITE(OUTPUT,' +'); Gotoxy(8, yCount); WRITE(OUTPUT,pCount); Gotoxy( 66, yCount); WRITE(OUTPUT,' +'); pCount : = pCount 1; yCount : = yCount + 2; END; xCount : = 16; FOR J : = 1 TO 10 DO BEGIN Gotoxy(xCount,24); WRITE(OUTPUT,J); xCount : = xCount + 5; END; Gotoxy(3, 7); WRITE(OUTPUT,'P'); Gotoxy(3,8); WRITE(OUTPUT,'r'); Gotoxy(3,9); WRITE(OUTPUT,'o'); Gotoxy(3, 10); 88

PAGE 97

WRITE(OUTPUT,'b'); Gotoxy(3, 11); WRITE(OUTPUT, 'a'); Gotoxy(3, 12); WRITE(OUTPUT,'b'); Gotoxy(3, 13); WRITE(OUTPUT,'i'); Gotoxy(3, 14); WRITE(OUTPUT,'I'); Gotoxy(3, 15); WRITE(OUTPUT, 'i'); Gotoxy(3, 16); WRITE(OUTPUT, 't'); Gotoxy(3, 17); WRITE(OUTPUT,'y'); Gotoxy(69,2); WRITE(OUTPUT,'Criticality'); Gotoxy(69,3); WRITE(OUTPUT,'Matrix'); Gotoxy(35,25); WRITE ( 0 UTPUT, 'Severity'); QuickSort(DataFile,ID Less Than); {Sorting on ID} ASSIGN (TempFile, DataFile); {Assigning the data file} RESET(TempFile); SEEK (TempFile, 1); READ (TempFile, Rec); Gotoxy(69,6); WRITE(OUTPUT, 'File'); Gotoxy( 69, 7); WRITE( OUTPUT,'----------'); Gotoxy(69,8); WRITE(OUTPUT,Datafile); Gotoxy(69, 11 ); WRITE(OUTPUT,'System'); Gotoxy(69, 12); WRITE(OUTPUT, '----------'); Gotoxy(69, 13); WRITE( OUTPUT, Rec. System); Gotoxy(69, 16); WRITE( OUTPUT, 'Date'); Gotoxy(69, 17); 89

PAGE 98

WRITE(OUTPUT, '----------'); Gotoxy(69, 18); WRITE(OUTPUT,Rec.FMEAMonth,' /', Rec.FMEADay,' /' ,Rec.FMEAYear); yCount : = 23; xCount : = 11; RESET (TempFile); REPEAT {Display aiiiD numbers on the matrix} SEEK (TempFile, RecordNo); READ (TempFile, Reel; WITH Rec DO BEGIN Occ : = Occurrence; Sev : = Severity; xCount: = xCount+(5*Sev); yCount : = yCount-(2*0ccurrence); Gotoxy(xCount, yCount); WRITE(OUTPUT ,I D); Record No : = Record No + 1; yCount : = 23; xCount : = 11 ; END; UNTIL EOF(TempFile); CLOSE(TempFile); key : = Read key; END; {End of display for all ID numbers} '0' ,'S' ,'R' : BEGIN {Stem and Leaf} Gotoxy(30,5); {Plots} WRITE(OUTPUT,'Stem and Leaf Matrix'); CASE Routine OF '0' : BEGIN {Failure occurrence display} Gotoxy(16, 19); WRITE( OUTPUT,'+----+----+----+----+--+ ----+ ----+ ----+ ----+ '); Gotoxy(16,20); WRITE(OUTPUT,' 1 2 3 4 5 6 7 8 9 10'); Gotoxy(36, 7); WRITE(OUTPUT,'Occurence'); Gotoxy(13,22); WRITE(OUTPUT,'Not Likely'); 90

PAGE 99

Gotoxy(60,22); WRITE(OUTPUT, 'Likely'); END; 'S' BEGIN {Failure severity display} Gotoxy(16, 19); WRITE(OUTPUT,' + ----+ ----+ ----+ ----+ ---+ ----+ ----+ ----+ ----+ '); Gotoxy(16,20); WRITE(OUTPUT,'1 2 3 4 5 6 7 8 9 1 0'); Gotoxy(36, 7); WRITE(OUTPUT, 'Severity'); Gotoxy(13,22); WRITE(OUTPUT,'Not Severe'); Gotoxy(60,22); WRITE(OUTPUT,'Severe'); END; 'R' BEGIN {Combined risk number display} Gotoxy(6, 19); WRITE ( 0 UTPUT,' + ------+ ------+ ------+ ------+ ------+ ------+ ------+ ------+ ------+ ------+ '); Gotoxy(6,20); WRITE(OUTPUT,' 1-9 10-19 20-29 30-39 40-49 50-59 60-69 70-79 80-89 90-1 00'); Gotoxy(36, 7); WRITE(OUTPUT,' Risk'); Gotoxy(6,22); WRITE(OUTPUT,'Low Risk'); Gotoxy(69,22); WRITE(OUTPUT,'High Risk'); END; END; {End of graphical screen formatting} QuickSort(DataFile,ID _Less_ Than); {Sort on ID numbers} ASSIGN (TempFile, DataFile); RESET (TempFile); REPEAT SEEK (TempFile, RecordNo); READ (TempFile, Rec); Gotoxy(1 0,2); 91

PAGE 100

WRITE(OUTPUT,'File: ',DataFile); Gotoxy(30,2); WRITE(OUTPUT,'System : ',Rec.System); Gotoxy(55,2); WRITE(OUTPUT,'Date: ',Rec.FMEAMonth,'/', Rec.FMEADay, '/' ,Rec.FMEA Year); WITH Rec DO BEGIN CASE Routine OF '0' : BEGIN {Display component ID occ} Occ : = Rec.Occurrence; CASE Occ OF 1 : BEGIN x1 : = 15; Gotoxy(x1 ,y1 ); WRITE(OUTPUT,ID:2); y1:=y1-1; END; 2 BEGIN x2: = 20; Gotoxy(x2, y2); WRITE(OUTPUT,ID:2); y2: = y2-1; END; 3 BEGIN x3: = 25; Gotoxy(x3,y3); WRITE(OUTPUT,ID:2); y3 : = y3-1; END; 4 BEGIN x4: = 30; Gotoxy(x4, y4); WRITE(OUTPUT,ID:2); y4: = y4-1; END; 5 BEGIN 92 x5: = 35; Gotoxy(x5,y5); WRITE(OUTPUT,ID:2); y5 : = y5-1;

PAGE 101

END; 6 BEGIN x6: = 40; Gotoxy(x6, y6); WRITE(OUTPUT,ID:2); y6: = y6-1; END; 7 BEGIN x7: = 45; Gotoxy(x7,y7); WRITE(OUTPUT,ID:2); y7 : = y7 -1; END; 8 BEGIN x8: = 50; Gotoxy(x8,y8); WRITE(OUTPUT,ID:2); y8 : = y8-1; END; 9 BEGIN x9: = 55; Gotoxy(x9,y9); WRITE(OUTPUT,ID:2); y9: = y9-1; END; 10: BEGIN x10 := 60; Gotoxy(x1 O,y1 0); WRITE(OUTPUT,ID:2); y10:=y10-1; END; END; END; 'S' BEGIN {Display component ID by sev} Sev : = Rec.Severity; CASE Sev OF 1 : BEGIN 93 x1 := 15; Gotoxy(x1 ,y1 ); WRITE(OUTPUT,ID:2); y1:=y1-1;

PAGE 102

END; 2 BEGIN x2 : = 20; Gotoxy(x2, y2); WRITE(OUTPUT,ID:2); y2: = y21; END; 3 BEGIN x3 : = 25; Gotoxy(x3, y3); WRITE(OUTPUT,ID:2); y3 : = y31; END; 4 BEGIN x4: = 30; Gotoxy(x4, y4); WRITE(OUTPUT,ID:2); y4: = y41; END; 5 BEGIN x5: = 35; Gotoxy(x5, y5); WRITE(OUTPUT,ID:2); y5 : = y5 1; END; 6 BEGIN x6: = 40; Gotoxy(x6, y6); WRITE(OUTPUT,ID:2); y6 : = y61; END; 7 BEGIN x7: = 45; Gotoxy(x7 ,y7); WRITE(OUTPUT,ID:2); y7 : = y71; END; 8 BEGIN 94 x8: = 50; Gotoxy(x8, y8); WRITE(OUTPUT,ID:2);

PAGE 103

y8 : = y8-1; END; 9 BEGIN x9: = 55; Gotoxy(x9,y9); WRITE(OUTPUT,ID:2); y9 : = y9-1; END; 10: BEGIN x10 := 60; Gotoxy(x1 O,y1 0); WRITE(OUTPUT,ID:2); y10:=y10-1; END; END; END; 'R' BEGIN {Display component ID by combined risk number} R : = Rec.Risk; CASE R OF 1 .. 9 : BEGIN x1 : = 9; Gotoxy(x1 ,y1 ); WRITE(OUTPUT,ID:2); y1 : = y1 1; END; 10 .. 19 : BEGIN x2: = 16; Gotoxy (x2, y 2); WRITE(OUTPUT,ID:2); y2 : = y2-1; END; 20 .. 29 : BEGIN x3: = 23; Gotoxy(x3,y3); WRITE(OUTPUT,ID:2); y3 : = y3-1; END; 30 .. 39 : BEGIN 95 x4: = 30; Gotoxy(x4,y4);

PAGE 104

WRITE(OUTPUT, ID:2); y4: = y4-1; END; 40 .. 49 : BEGIN x5 : = 37; Gotoxy(x5,y5); WRITE(OUTPUT,ID:2); y5 : = y5-1; END; 50 .. 59 : BEGIN x6: = 44; Gotoxy(x6, y6); WRITE(OUTPUT,ID:2); y6 : = y6-1; END; 60 .. 69 : BEGIN x7:=51; Gotoxy(x7,y7); WRITE(OUTPUT,ID:2); y7 : = y7-1; END; 70 .. 79 : BEGIN x8: = 58; Gotoxy(x8, y8); WRITE(OUTPUT,ID:2); y8: = y8-1; END; 80 .. 89 : BEGIN x9: = 65; Gotoxy(x9, y9); WRITE(OUTPUT,ID:2); y9 : = y9-1; END; 90 .. 100 : BEGIN END; END; 96 x10 := 72; Gotoxy(x1 O,y1 0); WRITE(OUTPUT,ID:2); y10 := y101; END;

PAGE 105

END; RecordNo: = Record No + 1; {Step through the file} END; UNTIL EOF(TempFile); CLOSE(TempFile); key : = Read key; END; {End of displays for 0, C and R} END; {End of case for general categories} END; {End of procedure GraphDisplay} {****************************************************} { * * * * * * * * *IN ITI ALIZA Tl 0 N * * * * * * * * * * * *} VAr { } GraphDriver, Error: Integer; Key: CHAR; The following section was added in to combine the Pascal graphics with the main executable. It is the modified BGILINK program that was provided with the Pascal 6.0 software and was modified specifically for this program initialization section. BEGIN {Initialization section} { Register all the drivers } IF RegisterBGidriver(@CGADriverProc) < 0 THEN BEGIN Writeln('CGA', ': ', GraphErrorMsg(GraphResult)); Halt(1); END; IF RegisterBGidriver(@EGAVGADriverProc) < 0 THEN BEGIN Writeln('EGA/VGA', ': ', GraphErrorMsg(GraphResult)); Halt(1 ); END; IF RegisterBGidriver(@HercDriverProc) < 0 THEN BEGIN Writeln('Herc', ': ', GraphErrorMsg(GraphResult)); Halt(1 ); END; IF RegisterBGidriver(@ATTDriverProc) < 0 THEN BEGIN 97

PAGE 106

Writeln(' AT&T',':', GraphErrorMsg(GraphResult)); Halt(1); END; IF RegisterBGidriver(@PC3270DriverProc) < 0 THEN BEGIN Writeln('PC 3270', ': ', GraphErrorMsg(GraphResult)); Halt(1 ); END; { Register all the fonts } IF RegisterBGifont(@GothicFontProc) < 0 THEN BEGIN Writeln('Gothic', ': ', GraphErrorMsg(GraphResult)); Halt(1 ); END; IF RegisterBGifont(@SansSerifFontProc) < 0 THEN BEGIN Writeln('SansSerif', ': ', GraphErrorMsg(GraphResult)); Halt(1 ); END; IF RegisterBGifont(@SmaiiFontProc) < 0 THEN BEGIN Writeln('Small', ': ', GraphErrorMsg(GraphResult)); Halt(1J; END; IF RegisterBGifont(@TriplexFontProc) < 0 THEN BEGIN Writeln('Triplex', ': ', GraphErrorMsg(GraphResult)); Halt(1 ); END; GraphDriver : = Detect; { autodetect the hardware } lnitGraph(GraphDriver, GraphMode, "); { activate graphics } IF GraphResult < > grOk THEN { any errors? } BEGIN Writeln('Graphics in it error: ', GraphErrorMsg(GraphDriver)); Halt(1 ); END; CloseGraph; GraphDriver : = Detect; { autodetect the hardware } 98

PAGE 107

lnitGraph(GraphDriver, GraphMode, "); { activate graphics} IF GraphResult < > grOk then { any errors? } BEGIN Writeln('Graphics in it error: '; GraphErrorMsg(GraphDriver)); Halt(1 ); END; {Display of program name and software identification} SetGraphMode(GraphMode); {Set graph mode to current device} SetColor(White); SetlineStyle(Solidln,O, ThickWidth); SetFi II Style (Solid Fill, Lig htG ray); Rectangle(125, 70.475.420); FloodFill(145,80, White); SetTextStyle(TriplexFont, HorizDir, 4); SetColor(GetBkColor); OutTextXY(200, 140.'Failure Mode'); OutTextXY(174, 175.'Effects Analysis'); SetTextStyle(SansSerifFont, HorizDir, 1); SetColor(Biue); OutTextXY(185,300.'Press Any Key To Proceed'); OutTextXY(186,300.'Press Any Key To Proceed'); SetTextStyle(DeFaultFont, HorizDir, 1 ); OutTextXY ( 175 .400.'TonyG Software Explorations 1996'); key:= Read key; RestoreCrtMode; {Restore the screen to original configuration} END. {End of initialization} 99

PAGE 108

FMEASORT.PAS UNIT FmeaSort; { $R-,S-} { } PROSPECTUS This unit will accept a tile of a certain type and sort it by failure occurrence, failure severity, overall failure risk or component ID. ALGORITHM A tile of MasterRecord is read into the unit. The tile is sorted according to rules in the various functions using the QUICKSORT algorithm. See each function or procedure tor more detailed description of how they work. AUTHOR Orginally written by Zenas Hartsvigson tor Math 5260 at the University of Colorado at Denver in the laboratory and course handbook (1992) and accompanying software. Modified tor the failure mode effects program called FMEA.PAS by Tony Gojanovic. Modified source code tor this unit written and compiled with Boreland Turbo Pascal Version 6.0 and CSE editor. Modified Summer 1996. Comments with a ZH are credited to Zenas Hartsvigson. {****************************************************} INTERFACE TYPE MasterRecord = RECORD {Defining the record} System, {The type of system to be studied} Mission, {The purpose and operating range of the system} Component, {The components that make up the system} Failure, {The failure of a specific component} 100

PAGE 109

Cause, {What caused the failure to happen} Effect : STRING [25]; {The effect system failure} ID, {A numeric assigned to the component} FMEADay, {The day of the FMEA} FMEAMonth, {The month of the FMEA} FMEAYear, {The year on which the FMEA was performed} Occurrence, {The liklihood of the failure} Severity, {The severity of the failure} Risk INTEGER {The combined risk number of occurrence and severity} END; MasterRecordFile = FILE OF MasterRecord; File_ Name_ Type =STRING; {General procedure/function type for use in quick-sorter operation ZH} Order_ Type = FUNCTION (rec _1, rec_2: MasterRecord): BOOLEAN; {The main operations that will sort the file} FUNCTION Prob _Less_ Than (rec_1, rec_ 2: MasterRecord): BOOLEAN; FUNCTION Severe_Less_ Than (rec_1, rec_2: MasterRecord): BOOLEAN; FUNCTION Risk_Less_Than (rec_1, rec_2: MasterRecord): BOOLEAN; FUNCTION ID_Less_Than (rec_1, rec_2: MasterRecord): BOOLEAN; PROCEDURE QuickSort(VAR file_name: File_Name_Type; Less_Than: Order_Type); {**************************************************} IMPLEMENTATION USES Crt; {***************************************************} FUNCTION Prob_Less_ Than (rec_1, rec_2: MasterRecord): BOOLEAN; { } This operation will order two records, rec_1 and rec_2 in terms of given probabilities. Depending on position, the function will be given a BOOLEAN value to be used in the main sorting routine. 101

PAGE 110

BEGIN IF rec 1 .occurrence+ rec 1 .occurrence > rec_2.occurrence + rec_2.occurrence THEN Prob Less Than:= TRUE --ELSE Prob _Less_ Than: = FALSE; END; {****************************************************} FUNCTION Severe_ Less_ Than (rec _1, rec _2: MasterRecord): BOOLEAN; { } This operation will order two records, rec_1 and rec_2 in terms of severity values. Depending on position, the function will be given a BOOLEAN value to be used in the main sorting routine. BEGIN IF rec_1.severity + rec_1.severity > rec_2.severity + rec_2.severity THEN Severe Less Than:= TRUE ELSE Severe_Less_ Than:= FALSE; END; {****************************************************} FUNCTION Risk_Less_Than (rec_1, rec_2: MasterRecord): BOOLEAN; { } This operation will order two records, rec_1 and rec_2 in terms of calculated risk values. Depending on position, the function will be given a BOOLEAN value to be used in the main sorting routine. BEGIN IF rec 1.risk+rec 1.risk > rec 2.risk+rec 2.risk ---THEN Risk Less Than:= TRUE --ELSE Risk_Less_Than: =FALSE; END {****************************************************} 102

PAGE 111

FUNCTION ID _Less_ Than (rec_1, rec_2: MasterRecord): BOOLEAN; { } This operation will order two records, rec_1 and rec_2 in terms of component ID values. Depending on position, the function will be given a BOOLEAN value to be used in the main sorting routine. BEGIN IF rec_1.id+rec_1.id < rec_2.id+rec_2.id THEN ld Less Than:= TRUE ELSE ld_Less_Than: = FALSE; END; {***************************************************} PROCEDURE QuickSort(VAR file_name: File_Name_Type; Less_ Than: Order_ Type); { QUICKSORT sorts elements in the array, a, with indices between} { LO and HI (both inclusive). Note that the QUICKSORT proce-} { dure provides only an "interface" to the program. The actual } { processing takes place in the SORT procedure, which executes } { itself recursively. (ZH) } VAR data _file : MasterRecordFile; {********************************} PROCEDURE Sort(left, right: INTEGER); { Sort selects one record as an anchor in the data file between the left-index and right-indes values. It reorganizes all of the records in the disk file starting with the record at the left-index and going to the record at the right-index so that those records "less than" than the anchor are on the left-side of the anchor and all other records are on the right-side. It should be observed that the anchor will be moved to the right or left as needed to accommodate locating the smaller items to its left and the bigger items to its right. When the items have been moved, thEt left-side and the right-side are not ordered. These "sides" are passed recursively to sort by giving the indices of the ends of each 103

PAGE 112

} "side." A side of length 1 is sorted. (ZH) VAR i, j: INTEGER; partition_ anchor, i_th_rec, j th rec: MasterRecord; BEGIN i: = left; j: = right; {indices {ZH)} {capture the partition_anchor record, which is selected to be middle record in the disk file (ZH)} Seek (data _file, (left + right) DIV 2); READ (data file, partition anchor); -REPEAT {read in i_th record from the disk file (ZH)} Seek (data_file, i); READ (data_file, i_th_rec); {read data file from left-to-right until a record is found that is not Less_ Than the partition _anchor record (ZH)} WHILE Less_Than (i_th_rec, partition_anchor) DO BEGIN i: = i + 1; Seek (data _file, i); READ (data_file, i_th_rec); END; {read in the j_th record from the disk file (ZH)} Seek (data_file, j); READ (data_file, j_th_rec); {read data file from right-to-left until a record is found that is equal or Less_ Than the partition_anchor recon;l (ZH)} WHILE Less_ Than (partition_anchor, j_th_rec) DO BEGIN 104

PAGE 113

j:=j-1; Seek (data_file, j); READ (data file, j th rec); ---END; IF (i < = j) THEN BEGIN {swap the i_th and j_th disk file records (ZH)} Seek (data_file, i); WRITE (data file, j th rec); --Seek (data_file, j); WRITE (data_file, i_th_rec); {move index for left pointer to the right and move index for right pointer to the left (ZHl} i: =i+1; j: = j-1 ; END; UNTIL i>j; IF left
PAGE 114

BIBLIOGRAPHY 1. Gulick, F.E.C. "The Origins of the First Powered, Man-carrying Airplane." Scientific American, July 1979, pp. 86-100. 2. "Definitions of Terms for Reliability and Maintainability." MIL-STD721C. Washington D.C.: Department of Defense, June 12, 1981. 3. Dussault, Heather B. The Evolution and Practical Application of Failure Modes and Effects Analysis. Rome Air Development Center Document RADC-TR-83-72. Springfield, VA: National Technical Information Service, March 1983. 4. Frankel, Ernest G. Systems Reliability and Risk Analysis. Boston: Martinus Nijhoff Publishers, 1984. 5. "Galileo's Latest Glitch." Sky and Telescope, January 1996, p. 11. 6. Gryna, Frank M. "Product Development." Juran's Quality Control Handbook. 4th ed. New York: McGraw Hill Book Company, 1988, pp. 13.1-13.77. 7. Hatty, Mark, and Norm Owens. "Potential Failure Modes and Effects Analysis: A Business Perspective." Quality Engineering, 7(1) (1994-95), 169-186. 8. Hartvigson, Zenas. "Problem Solving with Pascal II." Laboratory 9. and Course Handbook, University of Colorado at Denver, 1992, pp. 60-63. Henley, Ernest J., Kumamoto, Hiromitsu. Assessment. Englewood Cliffs: 1981. Reliability and Risk Prentice Hall Inc., 10. Juran, J.M., and Frank M. Gryna. Quality Planning From Product Development Through Use. 2nd ed. 106

PAGE 115

------------------....................... .... From Product Development Through Use. York: McGraw Hill Book Company, 1980. 2nd ed. New 11. Kelly, Fred G. The Wright Brothers. New York: Dover Publications, Inc., 1989. 12. Kiemele, Mark J., Schmidt, Stephen R. Basic Statistics: Tools for Continuous Improvement. Colorado Springs: Air Academy Press, 1993. 13. Lam, K.D., Watson, Frank D., Schmidt, Stephen R. Total Quality: A Textbook of Strategic Quality, Leadership and Planning. Colorado Springs, Air Academy Press, 1991, 14. Lin, Herbert. "The Development of Software for Ballistic Missile Defense." Scientific American, December 1985, pp. 46-53. 15. Littlewood, Bev and Lorenzo Strigini. "The Risks of Software." Scientific American, November 1992, pp. 62-75. 16. "Maintainability Program for Systems and Equipment." MIL-STD470B. Washington D.C.: Department of Defense, May 30, 1989. 17. Nelson, Wayne. Applied Life Data Analysis. New York: John Wiley and Sons, 1982. 18. O'Connor, Patrick D.T. Practical Reliability Engineering. 2nd ed. Chichester: John Wiley and Sons, 1989. 19. Petroski, Henry. To Engineer is Human. The Role of Failure in Successful Designs. New York: Vintage Books, 1992. 20. "Procedures for Performing a Failure Mode, Effects and Criticality Analysis." MIL-STD-1629A. Washington D.C.: Department of Defense, November 24, 1980. 21. Potential Failure Mode and Effects Analysis (FMEA). Reference Manual. Chrysler Corporation, Ford Motor Company, General Motors Corporation, 1995. 107

PAGE 116

22. "Reliability Growth Management." MIL-STD-189. Washington D.C.: Department of Defense, February 13, 1981. 23. "Reliability Prediction of Electronic Equipment." MIL-HDBK-217F. Washington D.C.: Department of Defense, December 2, 1991. 24. "Reliability Program for Systems and Equipment Development and Production." MIL-STD-7858. Washington D.C.: Department of Defense, September 15, 1980. 25. Ross, Sheldon. A First Course in Probability. New York: Macmillan Publishing Company, 1988. 26. Schmidt, Stephen R., Kiemele, Mark J., Berdine, Ronald J. Knowledge Based Management: Unleashing the Power of Quality Improvement. Colorado Springs: Air Academy Press, 1996. 27. Shcherbak, Yuri M. "Ten Years of the Chornobyl Era." Scientific American, April 1996, pp. 44-49. 28. Spingran, Ray. "Tutorial: Failure Modes, Effects, and Criticality Analysis." Reliability Review, June 1984, pp. 27-28. 29. Stamatis, D.H. Failure Mode and Effect Analysis: FMEA From 30. Theory to Execution. Milwaukee: ASQC Quality Press, 1995. "System Safety Program Washington D.C.: 19, 1993. Requirements." MIL-STD-882C. Department of Defense, January 31. Roland, Harold E., and Brian Moriarty. System Safety Engineering and Management. New York: John Wiley and Sons, 1983. 32. "United complains to Boeing about problems with 777." Rocky Mountain News, 7 March 1996, Sec. A. p. 48. 108