TP - 10 Troubleshooting and Maintenance Techniques: Lecture # 3

TP_10 Troubleshooting and
maintenance techniques
Lecture # 3 : Troubleshooting
Fayoum Integrated Technical Educational Cluster
(ITEC)
4/27/2021 Maintenance techniques - Dr. Hagag Maher 1

Hagag Maher Abdelhameed
Assistant Professor of Industrial Engineering
Mechanical/Industrial Engineering Department
Mail : Hagagmaher@Fayoum.edu.eg.
Mob. 01229801023 & 01008249063
Facebook: Hagag Maher

Troubleshooting for Profit
• Process machines are critical to the profitability of processes.
Safe, efficient and reliable machines are required to maintain
dependable manufacturing processes that can create
saleable, on-spec product on time, and at the desired
production rate.
• As the wards of process machinery, we wish to keep our
equipment in serviceable condition.

Troubleshooting for Profit
• One of the most challenging aspects of a machinery professional or
operator’s job is deciding whether an operating machine should be shut
down due to a perceived problem or be allowed to keep operating
and at what level of operation.
• If he or she wrongly recommends a repair be conducted, the remaining
useful machine life is wasted, but if he or she is right, they can save the
organization from severe consequences, such as product releases, fires,
costly secondary machine damage, etc.
• This economic balancing act is at the heart of all machinery
assessments.

Troubleshooting and other analysis methods
What is the difference between field troubleshooting
and other analysis methods such as a root cause
analysis, failure analysis, and a root cause failure
analysis?
Field Troubleshooting
Root cause analysis (RCA)
Failure analysais
Root cause Failure analysais (RCFA)

Field Troubleshooting
A process of determining the cause of an apparent machine problem,
i.e., symptom, while it is still operating at actual process conditions.
Troubleshooting efforts tend to focus on a specific machine or
subsystem, using a proven body of historical knowledge. The body of
knowledge may be in the form of troubleshooting tables and matrices
or manufacturer’s information.
Example #1: Pump flow has fallen well below its rated level.
Example #2: Compressor thrust bearing is running 20 °F hotter than it
was last month.
Root cause analysis (RCA)
• A broad analysis of a system made up of multiple components or subsystems
or an organization made up of multiple processes. These complex systems
may not have any historical failure information to reference and are not well
understood. The overall complexity may require that the overall system be
broken down and analyzed separately.
Example #1: The finished product from a process unit went out of spec.
Example #2: Plant XYZ safety incidents for the month of May have doubled.
• One distinction between RCA approaches and troubleshooting is that RCAs
tend to address larger problems that often require a team approach, while
troubleshooting can normally be conducted by a single individual.

Failure analysis
• The process of collecting and analyzing physical data to determine the
cause of a failure. Physical causes of failure include corrosion, bearing
fatigue, shaft fatigue, etc.
• Failure analyses can only be conducted after a component failure. A
failure is defined as a condition when a component’s operating state
falls outside its intended design range and is no longer able to safely,
or efficiently, perform its intended duty.

Root cause Failure analysais (RCFA)
• Methodology attempts to solve complex problems by attempting to
identify and correct their root causes, as opposed to simply
addressing their symptoms.
• The RCFA methodology allows an organization to dig deeper into a
failure or series of failures in order to uncover latent issues.

Troubleshooting Decision Tree
• The troubleshooter begins at the top of
the tree when a symptom is first detected.
• At this point, the troubleshooter assesses
the situation and then picks one of the
possible path forwards:
1. Do nothing
2. Modify process conditions
3. Adjust machine, i.e., balance, align,
or lubricate machine as required
4. Plan to repair

Successful Troubleshooting
It has been demonstrated that a successful troubleshooting program
can reduce machinery repair cost up to 20%. The savings come from:
1. Keeping equipment in service that are serviceable and eliminating
needless repairs.
2. Recommending required adjustments, such as balancing, before
permanent damage occurs.
3. Uncovering latent plant issues, such as fouling, flow blockage, etc.
‫ مثل القاذورات وانسداد التدفق وما إلى ذلك‬، ‫الكشف عن المشاكل الكامنة‬
4. Judiciously delaying ‫ التأخير الحكيم‬repairs in order to properly plan
work and get critical spare parts in stock before serious internal
damage occurs
Successful Troubleshooter
Troubleshooter to be successful they must have:
1. A prepared mind
The successful troubleshooter regularly studies to develop a working
knowledge of machinery technology.
2. An open mind
only follows actual clues that are uncovered during an investigation
and ignores hunches or theories that are baseless.

Successful Troubleshooter
Troubleshooter to be successful they must have:
3. A flexible mind
(When you have a hammer, everything looks like a nail.)
We should view our processes holistically, i.e., composed of numerous
elements that interact with one another. Ask others for their opinion.
4. Confidence in problem solving
There is no perfect troubleshooter. Every engineer, technical specialist,
operator, etc., has shortcomings.

LOGICAL/ANALYTICAL TROUBLESHOOTING FRAMEWORKS
These associated safety tasks should be made before
beginning:
1. Always communicate with the operator in charge before you start.
2. Get the proper permits.
3. Get the appropriate permit to work if the work is in a hazardous
area.
4. Always communicate your actions with the operator in charge as
you work.
5. Always make sure what you are doing is safe for you, your fellow
workers, and your plant.

• Logical frameworks provide the basis for structured methods to
troubleshoot problems.
• But following a step-by-step method without first thinking through
the problem is often ineffective.
• Often a logical/analytical framework does not produce the solution to
a troubleshooting problem in just one pass. We usually have to return
to a previous step and go forward again. We may have to do this
several times.

Logical/analytical frameworks can be divided into two

types:
1. Specific frameworks
2. General or generic frameworks

SPECIFIC TROUBLESHOOTING FRAMEWORKS
Specific troubleshooting frameworks have been developed to apply to
a particular instrument, class of instruments, system, or problem
domain. For example, for all types of transmitters, for pressure control
systems, or for grounding problems.
When these match up with your system, you have a distinct starting
point for troubleshooting. Otherwise, the starting point will generally
be determined by the problem description and information-gathering
process. Such frameworks typically come in several formats:
• Tables
• Flowcharts or trees
• Procedures

Tables Format
table for
troubleshooting
a magnetic flow
meter.

Flowcharts or trees Format Procedures Format

HOW A SPECIFIC TROUBLESHOOTING FRAMEWORK WORKS
Look at the troubleshooting framework shown in following flow
chart (steps highlighted) and the loop in the P&ID (A piping and
instrumentation diagram ) shown in the Figure.
Here the operator reports that the level in Tank 201 is too high,
and automatic control loop LIC201 is not responding to the
problem.
The level on the DCS (Distributed Control System) is 60% (which
is also the set point), and has not changed in quite a while.
The operator reports that he has placed the loop in manual
and the situation is under control.

Using the “tree” framework troubleshooting begins;
Step 1: Check the local indicator. The local (field) indicator shows the same
level as the DCS: OK.
Step 2: Block and zero the transmitter, and check for 0%/4mA. The
transmitter does not zero, but a check of the process connections
indicates that they are clear: not OK.
Step 3: The level transmitter appears to be the problem and is replaced.
Problem solved.
the troubleshooter decides that the problem is level transmitter and that no
more general solution is required. The final steps here would be to notify the
operator, make sure field tagging and instrument configuration are correct,
update maintenance documentation, and clear permits.

GENERIC LOGICAL/ANALYTICAL FRAMEWORKS
• Since we do not always have a specific
structured framework available, we
need a more general or generic
framework that will apply to a broad
class of problems

A SEVEN-STEP PROCEDURE
STEP 1: Define the Problem
Part of a good troubleshooter’s skill is
sorting through the reports to get to a
good definition of the actual problem.
The problem description provides the
starting point for collecting data. If you
do not know where to start, you can find
yourself collecting more data—or the
wrong data— or lost in the data you
have collected. It is like navigating: if you
don’t know where you are starting from,
you are probably lost.

STEP 1: Define the Problem
When people report problems to you, the
facts may be incomplete, unclear, or buried
in too much information. Typically, someone
reports the problem as he or she sees it, and
may add the impressions of other operators
and people on the same shift.
• Simple Problems, Transient and Complex
Problems, Communication, Bias ‫( تحيز‬for
example, one common bias is that it is
always the instrument’s fault) , Degree Of
Generality

STEP 2: Collect Information Regarding
the Problem
Once a problem has been defined, you
should then collect additional
information. This step may overlap with
Step 1, and for simple problems these
two steps may even be the same.

STEP 2: Collect Information Regarding
the Problem
SYMPTOMS
The information you gather typically consists of
symptoms (what is wrong with the system) as
well as what is working properly
CHARACTERISTICS AND PARAMETERS
We also need to know what is right with the
system—what is working, the timing of the
breakdown, and what may have changed in the
system since it last worked.

STEP 2: Collect Information Regarding the
Problem
INTERVIEWS AND DATA
Typically, a large part of your information
gathering will be in the form of interviews with
the person who reported the problem and with
any other people who have relevant
information
INSPECTION
Next, you may inspect an instrument that is
suspected of being faulty or other local
instruments (such as pressure gauges,
temperature gauges, sight glasses, and local
indicators) to see if there are any indications
that might shed light on the matter.
STEP 2: Collect Information Regarding the
Problem
DOCUMENTATION AND HISTORY
After this, you will typically turn to loop
drawings, P&IDs, electrical drawings, manuals,
maintenance records, and system built-in
documentation, reviewing it for additional
information. The old saying, “When in doubt,
read the manual,” is always worth
remembering.

STEP 3: Analyze the Information
Once you have collected information, you
must start analyzing it to see if you have
enough to propose a solution. Begin by
organizing what you have collected, then
applying external knowledge and logical
principles to sort through it.

CASE-BASED REASONING
Probably the first analysis technique that you will
use is past experience you have had with the same
problem. If you have seen this situation or case
before, then you know a possible solution
“SIMILAR TO” ANALYSIS

Compare the system you are working on to similar
systems you have worked on in the past. For
example, a pressure transmitter, a differential
pressure transmitter, and a differential pressure
level transmitter are similar instruments.
“WHAT, WHERE, WHEN” ANALYSIS
You ask questions about what the information you
gathered may tell you such as:
• What is working? (For example, does the system
have power)
• What is not working?
• What is a cause of an effect (symptom)
• Where does the problem occur?
• Where does it not occur?
• When did the problem occur?
• When did it not occur?
• What has changed?
• What has not changed?
PATTERNS
Symptoms can sometimes be complex and can be
distributed over time. Looking for patterns either in
symptom actions or lack of action or in time of
occurrence can sometimes help in the analysis of
symptoms. Symptom patterns can be repetitious
(i.e., occurs only on night shift), connected to normal
events (i.e., every time a large motor is started or
when a piece of equipment is operated),
connected to a specific event (i.e., every time the
pressure is greater than 100 psig), connected to
specific operator action, or connected operational
events.
BASIC PRINCIPLES
For example, electrical current can only flow
certain ways, Ohm’s and Kirchhoff’s Laws always
work, and mass and energy always balance. Some
examples – the sum of the voltages around a loop
always equals zero, and the level in a tank is
based on the following equation:
Rate In – Rate Out = Rate of Accumulation
You can apply basic principles like these to
analyze data to determine problem areas or when
determining what is a process problem and what is
an instrument problem.

THE MANUAL
When in doubt, read the manual. The
information you have gathered can be used
in conjunction with the instrument’s or
system’s manual. It may have information on
circuits, system analysis, or troubleshooting
that can lead to a solution.

STEP 4: Determine Sufficiency of
Information
When you are gathering information, how
do you know that you have enough? Can
you determine a cause and propose a
solution to solve the problem? This is a
decision point for moving on to the step of
proposing a solution.

Information
THE DIRECT PROCESS
Sometimes Steps 2, 3, and 4 may lead a
troubleshooter directly to a solution. The direct
process is generally based on three methods:
experience, historical documentation, and use of
the manual.
But be careful to not jump the gun and move on to
testing a solution before you have firmed up all
your facts. There may be costs associated with
testing the solution that can be prevented with a
little forethought.

STEP 4: Determine Sufficiency of Information
THE ITERATIVE PROCESS
More commonly, Steps 2, 3, and 4 work in concert,
in a repetitive or iterative fashion, to help you find
a solution. Here you collect information, analyze it,
and decide if you have enough to propose a
solution. If not, then you go back to Step 2 to
collect more information, and so on, until you have
a proposed solution.
Now you will need a logical process to make this

iterative procedure successful. Several approaches,
such the linear approach and the “divide and
conquer” method, may apply.
Information
Linear Approach
For example, suppose a pressure signal is
reading incorrectly in the DCS. The DCS
signal is not zero, so there appears to be a
signal from the field (and consequently the
problem is probably not loss of power), but
the signal is dead—it does not move when
compared to the signal prior to the
problem.

STEP 4: Determine Sufficiency of Information
“divide and conquer” approach
is a common technique that the electronics
industry uses to test systems.
You choose a likely point, or the midpoint of
the system, and test it. If it tests bad, then
the upstream section of the system contains
the faulty part. The upstream section is then
divided in two parts and the system is
tested at the dividing point. If the test is
good, the downstream section contains the
bad part and is then divided in two, and so
on until the cause of the problem is found.
STEP 5: Propose a Solution
When you believe that you have
determined the cause of the problem,
propose a solution. In fact, you may
propose several solutions based on your
analysis. Usually the proposed solution will
be to remove and replace (or repair) a
bad part. In some cases, however, your
proposal may not offer complete certainty
of solving the problem and will have to be
tested, or another, more certain solution
tried instead.
STEP 5: Propose a Solution
If you have several possible
solutions,
1. propose them in the order of their
probability of success.
2. Do not try several solutions at once. This
is called the “shotgun approach” and
will confuse the issue.
3. Do not rush to a compromise solution
proposed by a “committee "either.

STEP 6: Test the Proposed Solution
Once a solution or combination of solutions
have been proposed, they must be tested
to see if your analysis of the problem is
correct.
SPECIFIC VERSUS GENERAL SOLUTIONS

Be careful of specific solutions to more general
problems. At this step you must determine if the
solution needed is more general than the specific
one proposed. In most cases, a specific solution will
be repairing or replacing the bad instrument.
SPECIFIC VERSUS GENERAL SOLUTIONS
For example, you replace a bad transmitter,
which solves the transmitter problem. But what
if replacing the transmitter only results in the
new transmitter going bad? Suppose a
transmitter with very long signal lines sustains
damage from lightning transients. The specific
solution would be replacing the transmitter; the
general solution might be to install transient
protection on the transmitter as well.

THE ITERATIVE PROCESS
If the proposed and tested solution is not
the correct one, then return to Step 3,
“Analyze the Information.” Where might
you have gone astray? If you find your
mistake, then move on to propose another
solution. If not, move back to Step 2,
“Collect Information.” It is time to gather
more information that will lead you to the
real solution.
STEP 7: The Repair
In the repair step, implement the solution
you have proposed. In some cases, testing a
solution results in the repair, as when
replacing a transmitter both tests the
solution and repairs the problem. Even in
this case, there will generally be some
additional work to be done, such as
tagging, updating the database, and
updating maintenance records, in order to
complete the repair.
WHY TROUBLESHOOTING FAILS
The most common reasons troubleshooting fails are

• • Lack of knowledge
• • Failure to apply an organized approach to data gathering
• • Choosing the wrong entry point
• • Dimensional thinking : People sometimes think “one-dimensionally,”
along a line or in one direction. We can think in three dimensions. By
analogy, consider driving a car: when you just concentrate on driving
down a road, you are thinking in one dimension; when you navigate
using a map, you are thinking in two dimensions.

Summary:
❑Troubleshooting for Profit
❑LOGICAL/ANALYTICAL TROUBLESHOOTING
Discussion FRAMEWORKS
&Questions! ❑A SEVEN-STEP PROCEDURE
❑WHY TROUBLESHOOTING FAILS

T H A N K S F O R L I S T E N I NG
Hagagmaher@fayoum.edu.eg Hagag Maher
01008249063
Hagag Maher
01229801023

TP - 10 Troubleshooting and Maintenance Techniques: Lecture # 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TP - 10 Troubleshooting and Maintenance Techniques: Lecture # 3

Uploaded by

Copyright:

Available Formats

TP_10 Troubleshooting and

4/27/2021 Maintenance techniques - Dr. Hagag Maher 1

4/27/2021 Maintenance techniques - Dr. Hagag Maher 2

4/27/2021 Maintenance techniques - Dr. Hagag Maher 3

4/27/2021 Maintenance techniques - Dr. Hagag Maher 4

4/27/2021 Maintenance techniques - Dr. Hagag Maher 5

4/27/2021 Maintenance techniques - Dr. Hagag Maher 7

4/27/2021 Maintenance techniques - Dr. Hagag Maher 8

4/27/2021 Maintenance techniques - Dr. Hagag Maher 9

4/27/2021 Maintenance techniques - Dr. Hagag Maher 10

4/27/2021 Maintenance techniques - Dr. Hagag Maher 12

4/27/2021 Maintenance techniques - Dr. Hagag Maher 13

4/27/2021 Maintenance techniques - Dr. Hagag Maher 14

4/27/2021 Maintenance techniques - Dr. Hagag Maher 15

Logical/analytical frameworks can be divided into two

4/27/2021 Maintenance techniques - Dr. Hagag Maher 16

4/27/2021 Maintenance techniques - Dr. Hagag Maher 17

4/27/2021 Maintenance techniques - Dr. Hagag Maher 18

4/27/2021 Maintenance techniques - Dr. Hagag Maher 19

4/27/2021 Maintenance techniques - Dr. Hagag Maher 21

4/27/2021 Maintenance techniques - Dr. Hagag Maher 22

4/27/2021 Maintenance techniques - Dr. Hagag Maher 23

4/27/2021 Maintenance techniques - Dr. Hagag Maher 24

4/27/2021 Maintenance techniques - Dr. Hagag Maher 25

4/27/2021 Maintenance techniques - Dr. Hagag Maher 26

4/27/2021 Maintenance techniques - Dr. Hagag Maher 27

4/27/2021 Maintenance techniques - Dr. Hagag Maher 29

4/27/2021 Maintenance techniques - Dr. Hagag Maher 30

“SIMILAR TO” ANALYSIS

4/27/2021 Maintenance techniques - Dr. Hagag Maher 34

4/27/2021 Maintenance techniques - Dr. Hagag Maher 35

4/27/2021 Maintenance techniques - Dr. Hagag Maher 36

4/27/2021 Maintenance techniques - Dr. Hagag Maher 37

Now you will need a logical process to make this

4/27/2021 Maintenance techniques - Dr. Hagag Maher 39

4/27/2021 Maintenance techniques - Dr. Hagag Maher 42

SPECIFIC VERSUS GENERAL SOLUTIONS

4/27/2021 Maintenance techniques - Dr. Hagag Maher 44

The most common reasons troubleshooting fails are

4/27/2021 Maintenance techniques - Dr. Hagag Maher 47

❑WHY TROUBLESHOOTING FAILS

4/27/2021 Maintenance techniques - Dr. Hagag Maher 48

4/27/2021 Maintenance techniques - Dr. Hagag Maher 49

You might also like