Maintenance Engineering

Certificate Course
By Career Guidance
Cell (CGC)
Department of Mechanical
Engineering, Failure Mode
College of Engineering and Computer
Science Analysis in
Module 1 Part B MAINTENANCE
 QUICK REVISION………..

“Reliability is the outcome of effective maintenance,

which gauges an asset's ability to function as intended for
a specific period”.
A functionally significant (FSI) item is an item whose
failure would affect safety or could have significant
operational or economic impact in a particular operating
or maintenance context
QUICK REVISION………..

Logic
Diagram
QUICK REVISION………..

Decision
Tree
Failure Mode Analysis
in MAINTENANCE

A primary responsibility of the maintenance engineer is to

identify and analyze asset failures and deviations from
optimum performance. This responsibility requires tools or
methods that the engineer can use to effectively
determine the potential failure modes of assets, as well as
determine the true root cause of the problem. The
maintenance engineer’s toolbox includes:
Failure Mode Analysis
in MAINTENANCE

SIMPLIFIED FAILURE MODES AND EFFECTS ANALYSIS (SFMEA)

It is a top-down method of analyzing a design, and is

widely used in industry. There are many different
company and industry standards, but one of the most
widely used is the Automotive Industry Action Group
(AIAG).Using this standard you start by considering each
component or functional block in the system and how it
can fail, referred to as failure modes.
 Failure Mode Analysis in MAINTENANCE

Determination of the effect of each failure mode, and the

severity on the function of the system is carried out.
Determination of the likelihood of occurrence and of
detecting the failure. The procedure is to calculate the risk
priority number, or RPN, using the formula:

The second stage is to consider corrective actions, which can

reduce the severity or occurrence, or increase detection.
 Failure Mode and Effect Analysis –A case Study

FAILURE MODES AND

EFFECTS ANALYSIS
(FMEA)

https://www.researchgate.net/publication/328842169_Failure_Modes_and_Effects_Analysis_of_Chemical_Storage
 Failure Mode and Effect Analysis –A case Study

FAILURE MODES AND

EFFECTS ANALYSIS
(FMEA)

https://www.researchgate.net/publication/328842169_Failure_Modes_and_Effects_Analysis_of_Chemical_Storage
 Failure Mode and Effect Analysis –A case Study

FAILURE MODES AND

EFFECTS ANALYSIS
(FMEA)

https://www.researchgate.net/publication/328842169_Failure_Modes_and_Effects_Analysis_of_Chemical_Storage
Failure Mode and Effect Analysis –A case Study

Detection
Criteria

https://www.researchgate.net/publication/328842169_Failure_Modes_and_Effects_Analysis_of_Chemical_Storage
Failure Mode and Effect Analysis –A case Study

Severity
Criteria

https://www.researchgate.net/publication/328842169_Failure_Modes_and_Effects_Analysis_of_Chemical_Storage
 Failure Mode and Effect Analysis –A case Study

Occurrence
Criteria

https://www.researchgate.net/publication/328842169_Failure_Modes_and_Effects_Analysis_of_Chemical_Storage
Case Study
FMEA
analysis

https://ro.uow.edu.au/dubaipapers/674/
 Factors - Severity

FMEA
Analysis
 Factors - Occurrence

FMEA
Analysis
 Factors - Detection

FMEA
Analysis
 Reliability Predictions and MTBF
Reliability predictions form the groundwork for
reliability analyses. They are used to compute the
predicted failure rate or mean time between
failures (MTBF) of your system. MTBF is usually
expressed in terms of hours. For example, if your
FMEA system has a predicted MTBF of 1000 hr, this means
Analysis that, on average, your system experiences one
failure in 1000 hr of operation.
 Reliability, Availability,
Maintainability Analysis
This analytical approach is a top-down method
that identifies failure modes, predicted failure
frequency (MTBF), maintainability (MTTR) from a
system or top-level viewpoint.
FMEA
MTTR-Mean time to repair
Analysis MTTRS-Mean time to restore system
MTTRF-Mean time to restore function
DLH/MA-Direct labor hours per maintenance action
TPCR-Total parts cost per removal or replacement
PFD- Probability of fault detection
 Fault-tree analysis
Fault-tree analysis is a method of analyzing system
reliability and safety. It provides an objective basis for
analyzing system design, justifying system changes,
performing trade-off studies, analyzing common failure
modes, and demonstrating compliance with safety and
FMEA environment requirements. It is different from a
Analysis Simplified Failure Mode and Effect Analysis in that it is
restricted to identifying system elements and events that
lead to one particular undesired event. Following Figure
shows the steps involved in performing a fault-tree
analysis.
 Fault-tree process

FMEA
Analysis

A fault event is an abnormal system state. A

normal event is expected to occur.
Case Study

Example of fault-tree
logic diagram.
 CAUSE-AND-EFFECT
ANALYSIS
Cause-and-effect analysis or Ishakawa diagram is a graphical
approach to failure analysis. It is also referred to as fishbone
analysis, a name derived from the fish-shaped pattern that
is used to plot the relationship between various factors that
contribute to a specific event. Typically, a fish bone analysis
plots four major classifications of potential causes (i.e.,
man, machine, material, and methods), but can include any
combination of categories. Following Figure illustrates a
simple analysis.
CAUSE-AND-EFFECT
ANALYSIS

This approach has one

serious limitation. The
fishbone graph does
not provide a clear
sequence of events
that leads to failure.

Typical cause-and-effect diagram.

SEQUENCE-OF-EVENTS
ANALYSIS
Sequence-of-events analysis is perhaps the most effective
method of evaluating a problem or failure that can be clearly
fixed in time. The analysis starts with the exact time of the
observed problem or failure and systematically identifies all
changes that took place prior to and following that time.
Again, the assumption in this analytical approach is that one
or more changes caused the observed problem or failure. The
sequence-of-events diagram should be a dynamic document
that is generated soon after a problem is reported and
continually modified until the event is fully resolved.
Typical sequence-of-event diagram
Define Events and
Forcing Functions
Qualifiers that provide all confirmed background or support data
needed to accurately define the event or forcing function should
be included in a sequence-of-events diagram. For example, each
event should include date and time qualifiers that fix the time
frame of the event. When confirmed qualifiers are not available,
assumptions may be used to define unconfirmed or perceived
factors that may have contributed to the event or function.
However, every effort should be made during the investigation to
eliminate the assumptions associated with the sequence-of-
events diagram and to replace them with known facts.
 Pareto Analysis
All of us are aware that there are always more problems than
we have time to work on them, more capital projects than
we have available funds, more necessary tasks than time in a
week and more demand for solution of problems than
resources to address them. Because this is a reality in any
operation, the need to look at these challenges utilizing the
Pareto principle is all the more crucial. The challenge is not
to solve as many problems as we can, but how to take a
limited resource (time) and get the maximum return on any
time spent with problem solving efforts.
 Pareto Analysis
Performing a Pareto analysis on a problem gives clear
direction as to how to prioritize time and resources to get
this maximum return. Pareto can be used for three distinct
purposes:
• Prioritize and justify time and resources spent on
problems.
• Problem clarification—further defines nature of problem to
give direction to problem solving activities.
• Objectively document or test to see if improvement
efforts are effective—a benchmark.
80/20 Rule

80/20 Rule: A few causes usually account for a majority of the problem
(or 80 percent) while a multitude of other causes accounts for only a
very small part of the problem (or 20 percent).
• Eighty percent of rejects are caused by 20 percent of the total
potential reasons.
• Eighty percent of instrument downtime is caused by 20 percent of
the total potential causes.
• Eighty percent of lab testing time, 20 percent of the total types of
tests.
• Eighty percent of time, 20 percent of the total potential tasks.
• Eighty percent of accidents/injuries, 20 percent of the total
potential types
80/20 Rule

Procedure

• Clearly define problem to be analyzed and its purpose.

• Select a time period (“window”) to be analyzed—week, month, year, and so on.
Always select a large enough window to allow most sources of variation or
problems to occur.
• Select a method to stratify the data (e.g., off-standard occurrences by standard,
and off-standard occurrences by parameter or by day of week).
• Collect and organize data by stratified categories. Compute frequency of
occurrence for each item (or # of tests, hours, and so on). Try to avoid using
percentages. Where possible translate to dollars.
80/20 Rule

• The totals calculated in step 4 will be equal to the height of the bars
on the diagram.
• Along the vertical axis, put units of measurement (e.g., pounds,
number of occurrences, hours, dollars).
• Draw a vertical “bar” to the appropriate scale with the biggest
category first, the next largest bar to the right of it and continue on to
the right. Make the bars equal in width and adjoining each other.
• Create an “all others” category and place it to the far right.
80/20 Rule

Option

• Construct a vertical scale on the right side from 0 to 100

percent.
• Plot a cumulative percent line graph.
 80/20 Rule
Key Points
• First step in making improvements—justifies spending time.
• Can be applied to variety of problems—process, product, operational, administrative,
safety, work-life.
• May be used to tell whether improvement efforts were effective.
• Assists in the efforts to go from effect to cause.
• Procedure is to categorize data, assign a value to each category (preferably in terms of
dollar), sort
in order from largest to smallest, and construct a bar graph.
• If a number of categories have very small values, they should be lumped together as
“other.”
• Indicate on Pareto (shaded boxes) those categories that comprise the vital few (80
percent of problem).
 80/20 Rule

Guidelines for interpretation:

• Which categories comprise the vital few?
• If problem solving has taken place, has the category
moved or “shifted places”?
• Is there a second-level Pareto that can be done, on the
top category, to shed further light on the problem?
80/20 Rule

Interpretation
• First few bars will represent the vital few. It is easier
to reduce the tallest bar by one-half than to eliminate
the shortest bar.
• If improvements take place, order will change over
time.
• If no work is done on the problem but the order
changes over time, the window is too small or the
process is severely out of control.
 80/20 Rule
Application.
In the context of problem solving, Pareto charts can be used in one of
three ways:
• Determine if a problem is significant—when performing a Pareto
analysis, is it part of the vital few?
• Use as a measure of effectiveness for problem solving—construct a
Pareto of “before” and com pare to a Pareto of “after” and then a change
is implemented.
• Further define a problem to reveal possible causes or give better
direction to problem solving. This would involve doing a “second-level”
Pareto.
80/20 Rule
 Flow Charts
A flow chart is a pictorial representation showing all of the
steps of a process. The picture illustrates all of the changes
that occur to the product through each stage. Details of four
Ws (Who, What, When, and Where) are helpful if written
beneath blocks of the flow chart.
Procedure. The people with the greatest amount of knowledge
about the process meet to brainstorm—a flow chart. This
might take more than one session to complete.
 Flow Charts
• List all of the steps in the process. The first few versions may not result in the
steps being listed in their actual sequence. It is important at this point to identify
all the steps.
• When all steps have been identified, sequence them in proper order.
• Plot flow chart, steps as blocks (equal size) starting at top left of paper and
moving step by step from left to right.
• If the process has many steps (operations) and cannot be completed on a single
line, drop down one level and continue on, starting at the left side again.
• Only those steps that contribute to the completion of the product/service are
included on-line. Non contributing support type operations (testing, approval,
movement between process stages) are plotted off-line as circles.
 Flow Charts
Key Points
• The easiest way to ensure common understanding of a process is to draw a picture of it.
• Keep it simple but at the same time ensure all steps are shown.
• In using this tool, teams will often realize how “nonstandard” or ill-defined a process
might be.
• Before doing a flow chart of “what should be,” the team should flow chart “what is.”
• Ensure Who, What, When, and Where are answered in looking at the flow chart.
• Keep in mind there are several different ways to use this tool but the procedure remains
the same.
• After completing a flow chart of the current process, the team should ask the question:
“What should be changed in this process (add a step, delete a step, modify a step) to help
eliminate the problem?”
 Control Charts
Control charts (Following Fig.) are a graphical run chart of a
measurement that can, through the use of control limits, distinguish
between chance causes of variation due to system elements and special
causes of variation due to a significant change in the process. With the
implementation of the Statistical Process Control (SPC) Systems,
personnel use this on-line SPC tool to continually monitor processes,
take actions when appropriate and document. These activities will help
ensure that the demonstrated process capabilities are achieved.
Control Chart
CONTROL CHARTS
CONTROL CHARTS
Key Points
• Always ensure that the conditions under which the first set of data was
gathered is as close as possible to when the second set was gathered—except
for the deliberate change of the independent variable.
• If other “uncontrolled” variables might be changing, it is recommended that
they be plotted as well for both periods to ensure “equivalent” conditions.
These are sometimes called “noise” variables— variables that are not part of
the experimental variables, but could influence the dependent variable if it is
not held constant.
• If there is more than one independent variable of interest and there might
be a relationship between them, then do not use this technique.
 CONTROL CHARTS

Key Points
If the team has identified three or four different independent variables to be
investigated and there is a strong feeling that one “interacts” with another to
have an effect on the dependent variable— then experimental design—or Q3
techniques should be used. The TQI specialist can assist you with an
experimental design.
• The power/certainty of your conclusion is related to the quality of your data
collection (holding noise variables constant) and the quantity. However,
collecting data points beyond 20 in number has a point of diminishing return.
• Collecting at least seven data points in the “after” period will allow all OOC
rules to be experienced if, indeed, there is a shift.
 References

Maintenance Engineering Handbook 7th Edition by Keith Mobley (Author), Lindley

Higgins (Author), Darrin Wikoff (Author), Publisher : McGraw-Hill Professional; 7th
edition (March 21, 2008), ISBN-10 : 0071546464, ISBN-13 : 978-0071546461