Introduction

In this article we explain what a "failure mode" is - this is a very common term used in reliability engineering and it is important to understand what is really means and when it should be used.

What is failure?

Reliability is simply the absence of failure – so when looking to improve reliability, we need to talk about avoiding failure. But what is failure? It is the inability of something to perform a required function. All simple stuff. However, saying that something has failed or broken usually isn’t enough to get things up and running again.

We need to understand how something has failed – we need to know the failure mode. There is a textbook definition of a failure mode:

“The manner in which something fails”

 

Using failure modes to describe failure

Describing how something fails is generally straight forward; bent, broken, no output, missing, open circuit…

Where it can get difficult though, is doing this consistently, especially when it's formally recorded in a FRACAS or FMEA. This can be very apparent when reviewing work from multiple contributors.

Perhaps the most common source of variation arises from the nuance that separates failure modes, effects and causes. The reason for this is because they are all one and the same thing, just seen from different perspectives.

Failure modes example

Let’s take a laptop computer for example (as there is a good chance that you’re reading this blog on one). What is a failure mode of the laptop?

• No display
• Inoperable
• Damaged case
• Overheating
• Loss of data
• Wobbly hinge

Every one of these could be considered a manner in which a laptop fails – but each could also be classified as a cause or effect to a failure mode, depending on the perspective taken.

One of the best ways to resolve this is to more clearly define the system. There are many ways to define a system, one of the most effective ways is to use a functional block diagram (FBD), as this gives a visual representation that clearly shows boundaries, interfaces and relationships. Shown below, is a FBD for a laptop:

Cause and effect relationships

With a diagram like the one shown above, it is clearer what part of the system is under consideration and this helps us identify whether we are referring to a cause, effect or failure mode. We do this by considering the cause-effect relationship.

As can be seen, an effect is a cause to the effect above and vice versa. Therefore, we need to consider what the item under consideration is, in order to identify whether a record is classified correctly. Taking the example above, if we are looking at the laptop as a system, then the highest level (far left circle) represents the failure mode. The effect of this would sit to the left (and is at this stage undetermined) and causes will sit to the right. Where the causal chain is not clear, it is useful to insert the words ‘due to’ in order to identify correct order.

Summary

To ensure that failure modes are described consistently well, make sure that the item under consideration is understood – along with how it fits into the world. To do this we can use FBDs and causal chains to match failure modes to items, with the failure modes of other items becoming causes and effects of other items within the system.

How we can help you

Wilde Analysis has both extensive experience of performing Life Data Analysis consultancy projects and using the ReliaSoft APIs to provide solutions to client needs, please contact info@WildeRisk.co.uk to find out more.