cmac1.co.uk cmac1

Welcome Guest

Search:

A short discourse on diagnostic principals

Print View
by: Chris McAndrew
Total views: 37
Word Count: 834

The following is a discussion of diagnostic principals which can be applied to virtually any fault finding situation. The basic premise is to distil fault finding down to a common set of instructions which can be adapted to suite the needs of the problem at hand.

Diagnostics is an investigative process which applies logic to test theories through observation and experimentation.

Solving problems first requires a logical and systematic procedure which allows you to gather the available information, discard that which is irrelevant, discover other useful facts and draw logical conclusions in order to arrive at the cause of the problem.

Or, in the words of Sherlock Holmes;

“When you have eliminated the impossible, whatever remains, however improbable, must be the truth"
 

The Basics


1/. Gather information.

2/. Clearly, state the problem

3/. Form a hypothesis

4/. Test the hypothesis

5/. Observe the results and draw conclusions

6/. Repeat steps 1 to 6 until you are happy with step 5.
 

Gather information


You must gather all the information available about the effect of fault in order to discover its cause, ideally that information should come from multiple sources;

1/. Check power lights, status indicators and displays. Do not forget the basics, has it been unplugged or has the fuse blown?

2/. Seek commonalities and exclusivities.

Is everyone having the same fault?
Does it only affect people in one area?
Does it only affect one person?
Does the fault occur at a specific time?

3/. Ask users what they are experiencing, but treat this information with care – most users are non technical. Users have also been known to lie, particularly if they believe that they are responsible for the fault.

4/. Check the system log files

5/. Check and verify system configurations – are there any known software issues?

6/. ALWAYS try to reproduce the fault.

7/. Ask yourself – Is this really a fault?<
 

Clearly, state the problem


This is the process of reviewing all the available information and getting a clear understanding of the perceived fault.

For example, let’s say that you have a user complaining that they can not transfer a call to an outside line. However, upon investigation you find that they are pressing this when they should be pressing this .

Now, we have a training issue NOT A FAULT!!!
 

Form a hypothesis


Having collected your information and clearly stating what the problem is you now need to for your initial hypothesis.

The best way to do this is in the form of a question which can be proven or disproved.

1/. Extension 123 was working before and it is not working now. At what point in time did it break and what broke it?

Is it

a). The handset
b). The cables
c). The power etc, etc, etc?

2/. Why won’t Ops Manager install/start/run etc, etc?
 

Test the hypothesis


Once you have stated the problem and formed a hypothesis you must devise a method to test that hypothesis.

Your testing must enable you to eliminate one single possible cause by changing only one setting at a time.

If you make more than one change at a time you will not be able to eliminate all possible causes and it is quite likely that you will never find the root cause of the actual problem.

If you can not identify the root cause, how will you repair it the next time?
 

Observe the results and draw conclusions


After each test note whether the change you made did or did not solve the problem, gather any new information and then draw a conclusion as to whether the problem is solved or whether the change you made had any affect on the problem at all.

Once you have drawn conclusions you can devise new tests to eliminate other possible causes.
 

Repeat steps 1 to 6 until you are happy with step 5.


This entire methodology is based upon removing the possible causes of the fault, one at a time, until the root cause has been identified and eliminated. Therefore, until the root cause has been identified – go back to part one and start again!!
 

The three most important laws of diagnostics


 

1/. Murphy’s Law


If you skip a step, Murphy's Law states that the step you skip is where the problem will lie.
 

2/. Holmes Law


When you have eliminated the impossible, whatever remains, however improbable, must be the truth
 

3/. Occam's razor


The explanation of any phenomenon should make as few assumptions as possible, eliminating those that make no difference in the observable predictions of the explanatory hypothesis or theory.

OR

All other things being equal, the simplest solution is the best.