Symphony Technologies

Failure Mode & Effects Analysis:
A Technique to Effectively Mitigate Risks  

The Structure of FMEA

In this article:The Elements of FMEA

Understanding the correct structure and effective practice of FMEA:

With FMEA you look at

  • Failures: You identify how things can go wrong
  • Effects of Failures: You understand various impacts of Failure. Failures with severe impact need to be resolved on priority.
  • Causes of Failure: You take action on these. Actions are most effective when they prevent causes of failure from occurring.
FMEA will become effective only if the correct relationship between Failure Modes, Effects, Causes, actions and other elements is understood. The FMEA structure needs to be understood in its correct perspective.

The figure above shows the structure of FMEA.

Failure Modes, Effects, Causes, Actions are thus elements of FMEA. Let us now examine each element in the FMEA structure. There are two ways of looking at an element of FMEA.

The Designers view: This describes how the designer would look at the FMEA element. For DFMEA the designer is the Product Designer, and for PFMEA the designer is the Process Designer. The Designer is the one responsible for a failure-free working of the system.

Customer’s View: This describes how the customer would look at the FMEA element. The term Customer refers to the user of the system. These can be end-users (ones who buy the products) or internal customers within the organization.

A very good way of correctly identifying and describing the element is to understand whether it is looked upon from the Customer’s view or the Designer’s view.

Here are some examples of Customers and Designers:

  1. For a DFMEA for a vehicle braking system the Customer is the person who drives the car. The Designer is the brake system designer.
  2. For a PFMEA for an Ambulance operation in a hospital, the Customer is the patient as well as the hospital staff availing of the Ambulance service. The Designer is the Ambulance service provider.
  3. For a PFMEA for a restaurant service, the Customer is the one who visits the restaurant and would like to be served good quality food in a prompt manner. The Designer is the restaurant manager who designs the logistics and work-flow of the ordering system and is responsible for the quick and accurate service of good food.
Having understood Designers and Customers, let us look at the elements of FMEA.
  1. Item or Process Step: A DFMEA refers to an Item and a PFMEA to a Process Step as a starting point of the Analysis. You perform the analysis on an Item or a Process Step.

    Examples of items are a Radiator in a truck, seat in an office or a probe in a patient heart-rate monitor. Items can refer to components, aggregates or entire products. Examples of Process Steps are Receiving a phone call for Pizza delivery, Logging a customer complaint or Brazing Radiator tubes. An item should be described as visualized by the customer as well by the Designer. The views of the Customer and the Designer are not different for an item. Most of the time the end Customer may not have a view of items embedded deeper in the product. For example a person driving a car does not have a view of the fuel injection system that delivers fuel to the engine. The internal Customer, who is the technologist responsible for the fuel economy of the car understands this item well.

  2. Function: Function is the task the system should perform in order to satisfy the quality or performance expectations of the Customer.

    Examples of Functions are Pumping Water to the overhead tank for a water pump DFMEA, and delivery of metered fluids and drugs through an Intravenous delivery in a Patient Safety FMEA. The function should be described as viewed by the Customer. A function description is the answer to the question, ‘what should the product or process do to satisfy the customer?’

    A lot many times the analysts stop at the primary function description. Functions may go way beyond only the primary one. For example, a pump may have a primary function of delivering water to an overhead tank. However a noise-free and vibration-free operation is also an important function. The Automotive FMEA manual gives a listing of the following categories of functions that need to be considered:

    • Primary Design intent
    • Safety
    • Government regulations
    • Reliability (Life of the Function)
    • Loading and Duty Cycles: Customer Product usage profiles
    • Quiet Operations: Noise, Vibration and Harshness (NVH)
    • Fluid Retention
    • Ergonomics
    • Appearance
    • Packaging & Shipping
    • Service
    • Design for Assembly
    • Design for Manufacturability

    If functions from all the above categories are considered, the FMEA becomes a lot more comprehensive.

  3. Requirement: A requirement is a technical specification or a numerical measure of the desired function. Being a technical measure, this needs to be described from the Designer’s point of view.

    Examples of requirements are:

    • Flatness of 0.2 mm on a sealing surface for a Gate Valve PFMEA
    • Pizza Delivery within 30 minutes for a Pizza Chain Service FMEA
    • Braking Distance of 6 meters when traveling at 40 Km/hr for a vehicle braking system DFMEA.

    Identifying requirements help you in quantifying the expectations from a function. This leads to a more precise way of addressing failure.

  4. Failure Mode: A Failure Mode is the negation of the requirement. It is a description of the way in which a Requirement is not met with. A Failure Mode needs to be described from the Customer’s as well as the Designer’s point of view. It can be identified by both. Examples of failure Modes:
    • An Ambulance reaching late for a Healthcare FMEA
    • A seal not being able to sustain the peak fluid pressure required by the design in a valve DFMEA
    • A hotel check-out time exceeding the stipulated 3 minutes in a Service FMEA

  5. Effects and their respective Severities: Once a Failure Mode is identified, the team takes it up for detailed analysis. A Failure will lead to many Effects. Some effects are more severe in consequences, other less. Each one of the effects identified with the Failure Mode must be noted along with its severity ranking. The severity ranking is a number on the 1- 10 scale that tells you about how serious that Effect of failure is. Rank 1 is for the least severe failure and rank 10 is for the most severe one. Effects should always be written as perceived by the Customer. One Failure mode will lead to many effects. Thus potentially every effect identified can occur once the Failure occurs. This means that the most serious Effect can also occur once the Failure occurs. Some examples of effects are
    • The Failure Mode of Vehicle Braking Distance excess can have the following two causes
      • Accident leading to fatality: Very serious
      • Driver Discomfort: Less serious

    It must be understood that once the braking distance exceeds the stipulated value both, accident as well as driver discomfort will occur.

  6. Causes, Occurrence & Detection rankings and Current Controls: Causes are mechanisms or events that lead to failure. These are identified by the analyst. The Cause descriptions should be written therefore as perceived by the designer. Along with the Cause narration, the following need to be identified:
    • Current controls of Prevention of the Cause from occurring.
    • Occurrence Ranking (scale 1- 10) that tells you how frequently a failure due to this cause can occur, in spite of the Current Control of Prevention being in place.
    • Current controls of detection that will detect that the cause or the Failure Mode has occurred.
    • Detection Ranking (scale 1- 10) that tells you how easy or difficult is it to identify the cause or failure once it occurs, in spite of the Current Detection Control being in place.

  7. Risk Priority Number (RPN): The Risk Priority Number for every Cause is the multiplication:
    • Occurrence Ranking X Detection Ranking X Highest Severity Ranking associated with the Failure Mode

    The RPN is one of the metrics that helps you prioritize causes with high risks on which actions need to be taken.

  8. Actions: Actions need to be taken on Causes. Several Actions can be taken to address the potential risk associated with the cause. The Actions, Responsibility and Schedule thus need to be logged for each cause. Results of actions completed also need to be logged with each cause.

    Actions that have worked towards improvement provide an analyst with a model problem solving cycle in future risk analysis. Actions that have not yielded benefits also need to be logged to remind the future analysts of what has not worked in the past.

An important note on the FMEA Structure:

It can be seen from the discussion above, that a FMEA is a tree like structure.

  • An Item or Process Step can have several Functions.
  • A single Function can have Several Requirements.
  • A Requirement can be negated by several Failure Modes.
Once a Failure Mode is identified, it can be seen that
  • Each Failure Mode can lead to several Effects. Each one of the effects can potentially happen once the Failure occurs
  • Each failure Mode can be caused by several Causes. Each one of the causes can potentially lead to the Failure. Either singly or multiply.

FMEA thus does not follow Cause-Effect relationships.

FMEAs represented in a spreadsheet format can be misleading due to the Failure Modes, Causes and Effects written in a Row-Column format. It gives a notion that the Effect written in the first row is associated with the Cause written in the first row. Analysis resulting out of this confusion can lead one on the wrong path and may not prove to be an effective one.

For an effective implementation FMEAs need to be organized in a tree format. The spreadsheet-like format that you see is only a report document representation of the actual FMEA which is easy for printing.


The next article in this series explores ways to build an action orientation into your FMEA efforts.

Readers are welcome to interact, make suggestions and discuss the article with the author.

Author: Ravindra Khare is a Founder and Director of Symphony Technologies. He is a qualified Mechanical and Industrial Engineer and a keen student of Quality & Productivity Technology for the past 25 years. He can be contacted at e-mail address: ravi@symphonytech.com or through us at webmaster@symphonytech.com


  Share on Facebook Share on Linkedin Share on Twitter Email to Friends

 
In this series of articles on FMEA
by Ravindra Khare:

Article 1: Understanding the FMEA Process

Article 2: Structure of FMEA

Article 3: FMEA Priorities and Actions

Published July 2013.


Software from SymphonyTech

FMEA Executive

 

FMEA Executive software helps you perform Design and Process FMEA.

Thoughtfully designed features help you take your FMEA effort beyond mere documentation.

Your FMEA initiative becomes Effective and a Result oriented.

More information & Demo Download...


Privacy Policy | © Symphony Technologies Go to Top of PageTop