Chapter 26

Failure Modes and Effects

Analysis
Chapter Outline
26.1 Uncertainties During 26.7.2
Failure Cause 377
Development 373 26.7.3
Failure Effect 377
26.2 Failure Modes and Effects 26.7.4
Severity Factor 378
Analysis 374 26.7.5
Probability of
26.3 History of the Development Occurrence 379
of FMEA 374 26.7.6 Ease of Detection 380
26.4 Multiple Causes and Effects 26.8 Risk Priority Number 381
Involved in FMEA 375 26.9 Procedure for FMEA 381
26.5 Types of FMEA’s 375 26.10 Responsibility for Action 386
26.6 When to Use FMEA 376 26.11 Benefits of FMEA 386
26.7 Basic Terms of Reference 26.12 FMEA Software 388
in FMEA 377 26.13 Conclusion 388
26.7.1 Failure Mode 377 Further Reading 389

26.1 UNCERTAINTIES DURING DEVELOPMENT

Every product or project undertaken by the engineer is an experiment because
each stage of the design or development is experienced for the first time. There
are uncertainties at every stage, and the engineer is bound to make presump-
tions, either from data, books, or from his experience. These uncertainties can
be in the form of:
l models used for the design calculations,
l performance characteristics of the materials,
l inconsistencies in the materials purchased,
l nature of the pressure the finished product will encounter,
l size of the product, whether a medium-sized product or a large-sized product,
l volume of production, viz, batch production or mass production,
l specialized materials and skills used in the manufacture.
Apart from the above, the engineer may also experience uncertainties from
the viewpoint of several other variables in the development.

Total Quality Management: Key Concepts and Case Studies. http://dx.doi.org/10.1016/B978-0-12-811035-5.00026-X

Copyright © 2017 BSP Books Pvt. Ltd. Published by Elsevier Inc. All rights reserved. 373
374   Total Quality Management: Key Concepts and Case Studies

26.2 FAILURE MODES AND EFFECTS ANALYSIS

Failure mode and effects analysis (FMEA) is one of the best management tools
to analyze the potential failure modes within a system under conditions of un-
certainties, as stated above. Its principle is quite basic, and has been practiced
since the olden days as the trial and error method. But since learning from each
failure is both costly and time-consuming, the modern form of FMEA was de-
veloped during the 1940s, as explained in the following section. It emphasizes
the probability of occurrence of that failure, and the severity of its effect on the
system of every uncertainty. It is used to identify potential failure modes, deter-
mine their effect on the operation of the product, and identify actions to mitigate
the failures. It analyzes potential reliability problems early in the development
cycle, where it is easier to take actions to overcome these issues, thereby, en-
hancing reliability through design. FMEA should always be done whenever
failures would mean potential harm or injury to the user of the end item being
designed. According to Besterfield et al., FMEA is a “before-the-event” action
requiring a team effort to easily and inexpensively alleviate changes in design
and production. It is widely used in manufacturing industries in various phases
of the product lifecycle and is now being applied in the service industry, too.

26.3 HISTORY OF THE DEVELOPMENT OF FMEA

l FMEA has its origin during the late 1940s for military usage by the US Armed
Forces. This is incorporated in the military document MIL-P-1629, dated
November 9, 1949, titled Procedures for Performing a Failure Mode, Effects,
and Criticality Analysis, and subsequently ratified as MIL-STD-1629A.
l Its effectiveness in identifying and reducing any unseen problems encour-
aged its application for space research and design, specifically in the Apollo
Space program and in developing the means to put a man on the moon and
return him safely to earth.
l Its industrial application came during the early 1970s when the Ford Motor
Company, reeling after the failure of its Pinto car project, introduced FMEA
to the automotive industry to improve design, and for safety and regulatory
considerations. SAE have documented this as SAE J 1739.
l FMEA methodology is now extensively used in a variety of industries,
including semiconductor processing, food service, plastics, software, and
healthcare.
l It is integrated into advanced product quality planning (APQP) to provide
primary risk mitigation tools and timing in the prevention strategy, in both
design and process formats.
l The automotive industry action group requires the use of FMEA in the au-
tomotive APQP process and published a detailed manual on how to apply
the method. Each potential cause must be considered for its effect on the
product or process and, based on the risk, actions are determined and risks
revisited after actions are complete.
 Failure Modes and Effects Analysis Chapter | 26  375

l Toyota has taken this one step further with its design review based on
failure mode (DRBFM) approach. The method is now supported by the
American Society for Quality, which provides detailed guides on applying
the method.
l The Aerospace industry uses the term “Failure Modes, Effects and Criticality
Analysis” (FMECA), to highlight the criticality factor in the application of
FMEA is followed by Criticality analysis by which each potential failure is
ranked according to the combined influence of severity and probability of
occurrence. It identifies single point failures and ranks each failure accord-
ing to a severity classification of failure effect, helping to identify weak
links of design.
l Failure reporting and corrective action system (FRACAS) is another impor-
tant component of FMEA.

26.4 MULTIPLE CAUSES AND EFFECTS INVOLVED IN FMEA

FIG. 26.1 FMEA relationships.

Most real systems do not follow the simple cause and effect model. As ex-
plained in the tree diagrams, a single cause may have multiple effects, and a
combination of causes may lead to a single or multiple effects. This can also be
represented in Fig. 26.1.

26.5 TYPES OF FMEA’S

There can be several forms of FMEA based on which aspect of the activity is
analyzed, and can be illustrated as per Fig. 26.2. Other forms of FMEA like
System or Service can be interpolated into this illustration.
Concept FMEA (CFMEA)
l The concept FMEA is used to analyze concepts in the early stages before the
component is defined (most often at system and subsystem level).
l It focuses on potential failure modes associated with the proposed functions
of a concept proposal.
l This type of FMEA includes the interaction of multiple systems and interac-
tion between the elements of a system at the concept stages.
376   Total Quality Management: Key Concepts and Case Studies

FIG. 26.2 Relationship between the three forms of FMEA.

Design FMEA (DFMEA)

l The design FMEA is used to analyze products before they are released to
production.
l It focuses on potential failure modes of products caused by design
deficiencies.
l Design FMEAs are normally done at three levels—system, subsystem, and
component levels.
l This type of FMEA is used to analyze hardware, functions, or a combination.
Process FMEA (PFMEA)
l The process FMEA analyzes the potential failure modes within the process
to identify the severity and frequency, based on past experience with similar
processes, enables us to design these failures away from the process system
with minimum effort and resource expenditure.
l The process FMEA is normally used to analyze manufacturing and assem-
bly processes at the system, subsystem, or component levels.
l This type of FMEA focuses on potential failure modes of the process that are
caused by manufacturing or assembly process deficiencies.
Other forms of FMEA can be
l System FMEA, which focuses on global system functions.
l Service FMEA, which focuses on service functions.
l Software FMEA, which focuses on software functions.
l Design Review Based on Failure Mode (DRBFM), a term coined by Toyota
Motor Corporation, as an extension to DFMEA.

26.6 WHEN TO USE FMEA

l Whenever a new product or process is being initiated.
l Whenever changes are made to the product design, process, or the operat-
ing conditions. The product and process are interrelated. When the product
design is changed, the process is affected and vice-versa.
 Failure Modes and Effects Analysis Chapter | 26  377

l Whenever new regulations are being incorporated.

l When the customer feedback indicates problems in the product or process.

26.7 BASIC TERMS OF REFERENCE IN FMEA

26.7.1 Failure Mode
The manner by which a failure occurs and is observed, for example, electri-
cal short-circuiting, corrosion, cracking, or deformation. It may be noted that a
failure mode in one component can lead to another failure mode in the same, or
another component. Therefore, each failure mode should be listed in technical
terms and also giving due consideration for their interrelations. IEC 812-1985
enumerates the generic failure modes as below:

1. Structural failure (rupture) 17. Restricted flow

2. Physical binding or jamming 18. False actuation
3. Vibration 19. Failing to stop
4. Failing to remain in position 20. Failing to start
5. Eccentric rotation 21. Failing to switch
6. Failed interlocking system 22. Premature operation
7. Failing to open 23. Delayed operations
8. Failing to close 24. Erroneous input (increased)
9. Internal leakage 25. Erroneous input (decreased)
10. External leakage 26. Erroneous output (increased)
11. Fails out of tolerance (high) 27. Erroneous output (decreased)
12. Fails out of tolerance (low) 28. Loss of input
13. Inadvertent operation 29. Loss of output
14. Intermittent operation 30. Shorted (electrical)
15. Erratic operation 31. Open (electrical)
16. Erroneous indication 32. Leakage (electrical)
33. Other unique failure conditions as applicable to the system characteristics,
requirements, and operational constraints

26.7.2 Failure Cause

The product or process defects or any other quality imperfections would initiate
further deterioration leading to a failure. Some failure modes may have more
than one cause or mechanism of failure and each of these shall be listed and
analyzed separately.

26.7.3 Failure Effect

Failure effect is the immediate consequences of a failure on operation, f­ unction
or functionality, or status generally, as perceived or experience by the user.
Some of the effects can be cited as, injury to the user, inoperability of the
product or process, deterioration in product quality, nonadherence to the speci-
fications, emanation of odors, noise, etc. Also the effect of this failure on other
systems in immediate contact with the system that failed has to be considered.
If a component fractures, it may cause vibration in the subsystem that is in
378   Total Quality Management: Key Concepts and Case Studies

contact with the fractured part. FMEA is the technique used in analyzing the
potential failures and their effect on the system.

26.7.4 Severity Factor

A symbolic measure of the failure effect is the severity factor, which is the as-
sessment of the seriousness of the effect of the potential failure. It is noteworthy
that the severity represents the seriousness of the failure and not the mode of the
failure. Besterfield emphasizes in this connection that no single list of severity
criteria is applicable to all designs, and the team should agree on evaluation
criteria and on a ranking system that are consistent throughout the analysis. The
severity of the effect is given a severity number (S) from 1 (no danger) to 10
(critical), as given in Table 26.1.

TABLE 26.1 Rankings of Severity of Effect

Severity
Effect Severity of Effect Factor
Hazardous Very high ranking with potential failure 10
without warning mode affects safe operation and regulation
noncompliance. Failure occurs without warning.

Hazardous with Very high ranking with potential failure 9

warning mode affects safe operation and regulation
noncompliance. Failure occurs with warning.

Very high Hazardous. Even if the component does not 8

fracture, it becomes inoperable.

High Item is operable, but with loss of performance. 7

Customer is dissatisfied.

Moderate Product is operable but with loss to comfort/ 6

convenience. Customer experiences discomfort.

Low Product is operable, but with loss to comfort/ 5

convenience. Customer has some discomfort.

Very low Certain item characteristics do not conform to 4

specifications, but noticed by most customers.

Minor Certain item characteristics do not conform to 3

specifications, but noticed by average customers.

Very minor Certain item characteristics do not conform to 2

specifications, but noticed by some discriminating
buyers (referred to as dissatisfies in Chapter 3).

None No effect 1
 Failure Modes and Effects Analysis Chapter | 26  379

26.7.5 Probability of Occurrence

Probability of occurrence is the chance that one of the specific failure causes will
occur. This recoding of probability of occurrence must be done for every cause
indicating the probability of occurrence of that cause. This can be done by look-
ing at the occurrence of failures for similar products or processes, and the failures
that have been documented for them in technical terms. For FMEA, such an oc-
currence rate can be assigned a numerical value from 1 to 10, the least frequent
being 1 and the most frequent being 10 (Table 26.2). If this value is more than 4, it
implies that the actions needed to identify and analyze them shall be more meticu-
lous. Besterfield et al. suggest the following guideline questions for evaluation.
l What is the service history or field experience with similar systems or
subsystems?
l Is the component similar to a previous system or subsystem?
l How significant are the changes in the component is a new model?
l Is the component completely new?
l Is the component application any different form the previous?
l Is the component environment any different than before?

TABLE 26.2 Rankings of Probability of Occurrence

Probability of Possible Failure Ranking
Occurrence Explanation Rate No.
Very high Failure is almost inevitable >1 in 2 10

1 in 3 9

High Generally associated with 1 in 8 8

processes similar to previous
processes that have often 1 in 20 7
failed

Moderate Generally associated 1 in 80 6

with processes similar to
previous processes that have 1 in 400 5
experienced occasional 1 in 2000 4
failures

Low Isolated failures associated 1 in 15,000 3

with similar processes

Very low Only isolated failures 1 in 150,000 2

associated with almost
identical processes

Remote Failure is unlikely. No failures <1 in 1,500,000 1

ever associated with almost
identical processes
380   Total Quality Management: Key Concepts and Case Studies

26.7.6 Ease of Detection

This is the ability of the inspecting mechanism and/or design control to detect
the potential cause or the subsequent failure mode before the component or the
subsystem is completed for production. The proper inspection methods need to
be chosen. First, an engineer should look at the current controls of the system
that prevent failure modes from occurring, or which detect the failure before it
reaches the customer. Hereafter, one should identify testing, analysis, monitor-
ing, and other techniques that can be or have been used on similar systems to
detect failures. From these controls, an engineer can learn how likely it is for
a failure to be identified or detected. This parameter, too, is given a numerical
value between 1 and 10, called the Detection Rating (Table 26.3). This ranking
measures the risk that the failure will escape detection. A high detection number
indicates that the chances are high that the failure will escape detection.

TABLE 26.3 Rankings of Ease of Detection

Ease of Detection Explanation Ranking No.
Absolutely impossible No known controls available for detection 10
of the failure mode

Very remote Very remote likelihood that the current 9

controls will detect failure mode

Remote Remote likelihood that the current controls 8

will detect failure mode

Very low Low remote likelihood that the current 7

controls will detect failure mode

Low Low remote likelihood that the current 6

controls will detect failure mode

Moderate Moderate remote likelihood that the 5

current controls will detect failure mode

Moderately high Moderately high remote likelihood that the 4

current controls will detect failure mode

High High remote likelihood that the current 3

controls will detect failure mode

Very high Very high remote likelihood that the 2

current controls will detect failure mode

Almost certain Reliable controls are known with similar 1

processes and currant controls almost
certain to detect the failure mode
 Failure Modes and Effects Analysis Chapter | 26  381

Other terminology used in FEMA:

l Indenture levels: An identifier for item complexity. Complexity increases as
levels are closer to one.
l Local effect: The failure effect as it applies to the item under analysis.
l Next higher level effect: The failure effect as it applies at the next higher
indenture level.
l End effect: The failure effect at the highest indenture level or total system.

26.8 RISK PRIORITY NUMBER

Risk priority number (RPN) is a function of the three parameters discussed
above, viz, the severity of the effect of failure, the probability of occurrence,
and the ease of detection for each failure mode. RPN is calculated by multiply-
ing these three numbers as per the formula below,
RPN = S ´ P ´ D
where S is the severity of the effect of failure, P is the probability of failure, and
D is the ease of detection.
RPN may not play an important role in the choice of an action against f­ ailure
modes, but will help in indicating the threshold values for determining the areas
of greatest concentration. In other words, a failure mode with a high RPN num-
ber should be given the highest priority in the analysis and corrective action.
The relationship between the above mentioned parameters of FEMA may be
represented as in Fig. 26.3.

FIG. 26.3 The five basic steps of FMEA.

26.9 PROCEDURE FOR FMEA

In principle, the causes or the specific faults are described in terms of those
that can be detected and controlled. Action taken generally should result in a
382   Total Quality Management: Key Concepts and Case Studies

lower severity, lower occurrence, or higher detection rating by adding valida-

tion and verification controls
1. Identify the functions.
2. Identify the failure modes.
3. Identify the effects of the failure modes.
4. Determine the probability of occurrence (see Table 12.2).
5. Determine the severity of occurrence (see Table 12.3).
6. Apply this procedure for potential consequences.
7. Identify possible causes.
8. Identify the root cause.
9. Calculate the criticality.
10. Identify special characteristics.
11. Assess the probability that the proposed system detects the potential
weaknesses.
Princeton Plasma Physics Laboratory suggests the following basic steps
for FMEA:
1. Define the system and its functional and operating requirements;
a. Include primary and secondary functions, expected performance, system
constraints, and explicit conditions that constitute a failure. The system
definition should also define each mode of operation and its duration.
b. Address any relevant environmental factors, such as temperature, humid-
ity, radiation, vibration, and pressure during operating and idle periods.
c. Consider failures that could lead to noncompliance with applicable regu-
latory requirements. For example, a failure that could result in a pollut-
ant release that exceeds environmental permit limits.
2. Develop functional block diagrams showing the relationships among the el-
ements and any interdependencies. Separate diagrams may be required for
each operational mode. As a minimum, the block diagram should contain:
a. A breakdown of the system into major subsystems, including functional
relationships;
b. Appropriately and consistently labeled inputs and outputs and subsystem
identification;
c. Any redundancies, alternative signal paths, and other engineering fea-
tures that provide “failsafe” measures.
Existing drawings developed for other purposes may be used for the
FMEA if the above elements are adequately described.
3. Identify failure modes, their cause and effects.
a. IEC 812 1985 provides a list of failure modes, reproduced here as table
in Section 26.7.1, to describe the failure of any system element.
b. Identify the possible causes associated with each postulated failure mode.
The above list can be used to define both failure modes and failure causes.
Thus, for example, a power supply may have a specific failure mode “loss
of output” (29), and a failure cause “open (electrical)” (31).
 Failure Modes and Effects Analysis Chapter | 26  383

c. Identify, evaluate, and record the consequences of each assumed failure

mode on system, element operation, function, or status. Consider main-
tenance, personnel, and system objectives, as well as any effect on the
next higher system level.
4. Identify failure detection and isolation provisions and methods. Determine
if other failure modes would give an identical indication and whether sepa-
rate detection methods are needed.
5. Identify design and operating provisions that prevent or reduce the effect of
the failure mode. These may include:
a. Redundant items that allow continued operation if one or more ele-
ments fail;
b. Alternative means of operation;
c. Monitoring or alarm devices;
d. Any other means permitting effective operation or limiting damage.
6. Identify specific combinations of multiple failures to be considered. The
more multiple failures considered, the more complex the FMEA becomes.
In many such cases it would be advantageous to perform a FMECA using
the guidance of IEC Standard 812 or MIL-STD-1629A. Using the FMECA,
the severity of failure effects are categorized, the probability is determined,
and the number of redundant mitigating features needed to keep the prob-
ability of failure acceptably low are better determined.
7. Revise or repeat, as appropriate, the FMEA as the design changes. Changes
may be in direct response results of the previous FMEA or may be due to
unrelated factors.
Kenneth Crow, on the website http://www.npd-solutions.com/fmea.html,
suggests the following procedure for FMEA, which is quite similar to the
above detailed procedure by Princeton Plasma Physics Laboratory, but is more
exhaustive.
1. Describe the product/process and its function. An understanding of the
product or process under consideration is important to have clearly articu-
lated. This understanding simplifies the process of analysis by helping the
engineer identify those product/process uses that fall within the intended
function, and which ones fall outside. It is important to consider both inten-
tional and unintentional uses because product failure often ends in litiga-
tion, which can be costly and time-consuming.
2. Create a block diagram of the product or process. A block diagram of the
product/process should be developed. This diagram shows major com-
ponents or process steps as blocks connected together by lines that in-
dicate how the components or steps are related. The diagram shows the
logical relationships of components and establishes a structure around
which the FMEA can be developed. Establish a coding system to iden-
tify system elements. The block diagram should always be included with
the FMEA form.
384   Total Quality Management: Key Concepts and Case Studies

3. Complete the header on the FMEA form worksheet: Product/System,

Subsys./Assy., Component, Design Lead, Prepared By, Date, Revision
(letter or number), and Revision Date. Modify these headings as needed.
4. Use the diagram prepared above to begin listing items or functions. If items
are components, list them in a logical manner under their subsystem/as-
sembly, based on the block diagram.
5. Identify failure modes. A failure mode is defined as the manner in which a
component, subsystem, system, process, etc., could potentially fail to meet
the design intent. Examples of potential failure modes include:
a. Corrosion
b. Hydrogen embrittlement
c. Electrical short or open
d. Torque fatigue
e. Deformation
f. Cracking
6. A failure mode in one component can serve as the cause of a failure mode in
another component. Each failure should be listed in technical terms. Failure
modes should be listed for the function of each component or process step.
At this point, the failure mode should be identified whether or not the failure
is likely to occur. Looking at similar products or processes and the failures
that have been documented for them is an excellent starting point.
7. Describe the effects of those failure modes. For each failure mode identi-
fied, the engineer should determine what the ultimate effect will be. A
failure effect is defined as the result of a failure mode on the function of the
product/process as perceived by the customer. They should be described in
terms of what the customer might see or experience should the identified
failure mode occur. Keep in mind the internal as well as the external cus-
tomer. Examples of failure effects include:
a. Injury to the user
b. Inoperability of the product or process
c. Improper appearance of the product or process
d. Odors
e. Degraded performance
f. Noise
Establish a numerical ranking for the severity of the effect. A com-
mon industry standard scale uses 1 to represent no effect and 10 to
indicate very severe with failure affecting system operation and safety
without warning. The intent of the ranking is to help the analyst de-
termine whether a failure would be a minor nuisance or a catastrophic
occurrence to the customer. This enables the engineer to prioritize the
failures and address the real big issues first.
8. Identify the causes for each failure mode. A failure cause is defined as a
design weakness that may result in a failure. The potential causes for each
 Failure Modes and Effects Analysis Chapter | 26  385

failure mode should be identified and documented. The causes should be

listed in technical terms and not in terms of symptoms. Examples of poten-
tial causes include:
a. Improper torque applied
b. Improper operating conditions
c. Contamination
d. Erroneous algorithms
e. Improper alignment
f. Excessive loading
g. Excessive voltage
9. Enter the probability factor. A numerical weight should be assigned to each
cause that indicates how likely that cause is (probability of the cause occur-
ring). A common industry standard scale uses 1 to represent not likely and
10 to indicate inevitable.
10. Identify current controls (design or process). Current controls (design or
process) are the mechanisms that prevent the cause of the failure mode
from occurring or which detect the failure before it reaches the customer.
The engineer should now identify testing, analysis, monitoring, and other
techniques that can or have been used on the same or similar products/
processes to detect failures. Each of these controls should be assessed to
determine how well it is expected to identify or detect failure modes. After
a new product or process has been in use, previously undetected or uniden-
tified failure modes may appear. The FMEA should then be updated and
plans made to address those failures to eliminate them from the product/
process.
11. Determine the likelihood of detection. Detection is an assessment of the
likelihood that the current controls (design and process) will detect the
cause of the failure mode or the failure mode itself, thus preventing it from
reaching the customer.
12. Review RPNs. The RPN is a mathematical product of the numerical se-
verity, probability, and detection ratings: RPN = (severity) × (probability) ×
(detection)
The RPN is used to prioritize items than require additional quality planning
or action.
13. Determine recommended action(s) to address potential failures that have
a high RPN. These actions could include specific inspection, testing or
quality procedures; selection of different components or materials; de-
rating; limiting environmental stresses or operating range; redesign of
the item to avoid the failure mode; monitoring mechanisms; perform-
ing preventative maintenance; and inclusion of back-up systems or
redundancy.
14. Assign responsibility and a target completion date for these actions. This
makes responsibility clear-cut and facilitates tracking.
386   Total Quality Management: Key Concepts and Case Studies

15. Indicate actions taken. After these actions have been taken, re-assess the
severity, probability, and detection and review the revised RPNs. Are any
further actions required?
16. Update the FMEA as the design or process changes, the assessment changes
or new information becomes known.

26.10 RESPONSIBILITY FOR ACTION

FMEA is a team operation. Everyone should feel fully involved in the process
and in moving towards the goal. Nevertheless, it is always advisable to delegate
certain responsibilities to specified persons, so that the monitoring and report-
ing can be effective. It is suggested that some of the responsibilities be allocated
between the line manager, the analyst, and the reviewer as follows:
Line manager
1. Assign individuals to perform FMEA (analyst) and another individual to re-
view it (reviewer). The reviewer shall have as much expertise and technical
experience as the analyst.
Analyst
2. Describe the system under analysis, prepare system diagrams, and use exist-
ing documentation to depict all major components and their performance
criteria. The level of assembly may vary with the level of the analysis.
3. Perform FMEA as per the procedure described earlier.
4. Sign FMEA and provide it to the reviewer.
Reviewer
5. Review FMEA for technical content and sign if no significant problems are
identified. Otherwise discuss the FMEA with the analyst.
6. Ensure that the full FMEA documents are filed in the Operations Center.

26.11 BENEFITS OF FMEA

l Effective prevention planning program
l Identification of change requirements
l Cost reduction
l Increased throughput
l Decreased waste
l Decreased warranty costs
l Reduction of nonvalue added operations
l Improvement in the quality, reliability and safety of a product/process
l Improvement in company image and competitiveness
l Increased user satisfaction
l Reduced system development timing and cost
l Data collection (expert systems) for reduced future failures.
 Failure Modes and Effects Analysis Chapter | 26  387

l Reduce warranty concerns

l Early identification and elimination of potential failure modes
l Minimal late changes and associated cost
l Catalyst for teamwork and idea exchange between functions
l Reduction in the possibility of same kind of failure in future
While the general benefits of FMEA can be listed as above, the category-
wise benefits can be summarized as under:
Concept FMEA
l Helps selecting the optimum concept alternatives, or determine changes to
design specifications.
l Identifies potential failure modes caused by interactions within the concept.
l Increases the likelihood all potential effects of a proposed concept’s failure
modes are considered.
l Identifies system level testing requirements.
l Helps determine of hardware system redundancy may be required within a
design proposal.
Design FMEA
l Aids in the objective evaluation of design requirements and design
alternatives.
l Aids in the initial design for manufacturing and assembly requirements.
l Increases the probability that potential failure modes and their effects have
been considered in the design/development process.
l Provides additional information to help plan thorough and efficient test
programs.
l Develops a list of potential failure modes ranked according to their effect on
the customer. Establishes a priority system for design improvements.
l Provides an open issue format for recommending and tracking risk reducing
actions.
l Provides future reference to aid in analyzing field concerns.
Process FMEA
l Identifies potential product-related process failure modes.
l Assesses the potential customer effects of the failures.
l Identifies the potential manufacturing or assembly process causes and iden-
tifies process variables on which to focus controls or monitoring.
l Develops a ranked list of potential failure modes, establishing a priority sys-
tem for corrective action considerations.
l Documents the results of the manufacturing or assembly process.
l Identifies process deficiencies.
l Identifies confirmed critical characteristics and/or significant characteristics.
l Identifies operator safety concerns.
l Feeds information on design changes required and manufacturing feasibility
back to the designers.
388   Total Quality Management: Key Concepts and Case Studies

26.12 FMEA SOFTWARE

The following software have been developed for industrial and dedicated
­application as per information available in internet. It may be remembered that
FMEA software refers to the software available for FMEA solutions, whereas
Software FMEA refers to the process of applying FMEA so solve problems in
software development.
1. ASENT FMEA Software—Raytheon’s premiere reliability and maintainabil-
ity tool suite. Includes a very powerful FMECA tool that combines FMECA,
RCM analysis, and testability analysis.
2. Byteworx—Powerful, cost-effective software for FMEA. It is the global
choice of the Ford Motor Company. Byteworx FMEA is fully compliant
with SAE J-1739 Third Edition.
3. FMEA-Pro—FMEA/FMECA software from Dyadem. An all-in-one soft-
ware solution provides corporate consistency and assists with corporate
compliance.
4. Isograph Software—Their Reliability Workbench contains a FMEA/
FMECA tool.
5. Item Software—FMEA/FMECA/FMEDA—Failure Mode Effects Analysis
tool.
6. Quality Plus—FMEA software from Harpco Systems, Inc. Performs both
Design and Process FMEAs.
7. RAM Commander Software—ALD’s integrated FMEA/FMECA modules
have been adopted by many civil, military, aerospace, energy and pharma-
ceutical organizations worldwide.
8. Relex Software—Offers FMEA tools and FMEA software to process FMEA
and meet all functional FMEA standards for criticality matrix.
9. XFMEA—FMEA software from ReliaSoft. Provides expert support for all
types of FMEA.

26.13 CONCLUSION
As seen in this chapter, FMEA helps us in anticipating unexpected failures and
providing for their corrective action during the design stage itself. Right from
the days of its conception in the 1940s, it has today become a must for the
designers.
 Failure Modes and Effects Analysis Chapter | 26  389

On the Lighter Side

Mouse Potato – An amusing modern slang term for a
person who sits for long periods in front of a computer,
especially using the internet, instead of engaging in
more active and dynamic pursuits. Mouse Potato is an
adaptation of the older 1970’s slang 'couch potato',
referring to a person who spends too much time sitting
on sofa, watching TV, eating and drinking. Both terms
originated in the USA, although these lifestyles are now
worldwide.
Clicklexia - Ironic computing slang for a user's tendency
to double-click on items when a single click is required,
often causing the window or utility to open twice.
-Both from Business Dictionary

FURTHER READING
[1] Langford JW. Logistics—principles and applications. New York, NY: McGraw Hill; 1995.
[2] IEC Standard 812. Procedure for failure mode and effects analysis (FMEA), November 16,
2014.
[3] MIL-STD-1629. A procedures for performing a failure mode, effects and criticality analysis,
August 4, 1998.
[4] Stamatis DH. Failure mode and effect analysis—from theory to execution. Milwaukee, WI:
ASQ Publications; 1997.
[5] www.pppl.gov/eshis/procedures/eng000.
[6] FMEA, by Kenneth Crow from the website http://www.npd-solutions.com/fmea.html.
[7] www.weibull.com/basics/fmea.
[8] www.qualitytrainingportal.com/resources/fmea.
[9] www.pppl.gov/eshis/procedures/eng008 of Princeton Plasma Physics Laboratory.
[10] www.reliasoft.com/xfmea of Relia Soft Corporation for Xfmea interface.
[11] https://en.wikipedia.org/wiki/Strategic_planning for strategic planning.
[12] www.skymark.com/resources/tools/affinity_diagram for affinity diagram and cause and effect
diagram.
[13] www.qualitytrainingportal.com/resources/fmea for severity rating scale.