Boundary Diagram - How to construct an FMEA boundary diagram

"A boundary diagram provides a focus for the FMEA Team".

Constructing a boundary diagram for an FMEA is a relatively simple task.

However, in my experience so many people get it wrong. This can have a major impact on the complexity and quality output of the FMEA.

Let me explain why and for this I will use Design FMEA as an example.

In an organisation, the FMEA’s conducted all form part of a large jigsawpuzzle. For example, if we were to consider a copier machine then to carry out a Design FMEA on the whole product would be a daunting, if not impossible task. At a macro level, a photo copier has a number of sub-systems that are made up of sub-assemblies that have individual controls and management protocols.

So, we need to be able to manage our FMEA activity in a way that considers a number of factors including: -

• Customer critical functions
• Reliability
• System and sub-system levels
• Critical systems, sub-systems and components

As stated in other articles, the target FMEA then forms just one small part of the FMEA puzzle.

The FMEA boundary (what will be included and will not be included in this FMEA) describes the size and shape of this piece of the puzzle and will have an impact on the boundary of subsequent FMEA’s

There are some key foundations for a successful FMEA:

FMEA Saves Lives!

"How long has FMEA been around, Graham?" I was recently asked.

"About 60 years" was my reply

"Why aren't we all getting it right then?" Good question I thought.

"People need too get their act together. Its your duty to tell them how!"

So, on that note, allow me to share some thoughts with you.

When I have challenged FMEAs in the past I have been given various reasons for failure:

• It was just a paperwork exercise to satisfy an audit
• Compliance
• We didn't understand

This frustrates me becasue the consequences of a badly executed FMEA could result in injury or even death!

So if you think that you could benefit from a better understanding then read on,, as there are four aspects that need to be fully considered if an FMEA is to be effective.

The four aspects are as follows:

Boundary Diagrams which will focus your efforts

Understand design functions

Understand unintended design functions

Get control and stop things going wrong

1. Boundary Diagrams Focus Efforts

Get your team focused!

Set a boundary diagram for the FMEA.

After the design functions have been established, revisit the boundary to ensure that the FMEA considers the design in the context of its full operating environment.

Check with the team to see if any new knowledge or support from outside your team is required. Why guess when the knowledge exists with others in your organisation?

For the most part, boundary diagrams are produced without looking beyond the 'obvious', only considering the direct connections

The boundary diagram MUST reflect ALL conditions of use and application.

2. Understand Design Functions

Why is it that we don't look beyond the obvious functions?

Why don't we look at functions from a customer perspective?

What is the function of a pen? (see answer at the end!)

This is a basic design principle that all too often is not applied!

Using the Function Tree, develop a full understanding of your design funtions, then carry these prime functions forward into the FMEA

 3. Understand Unintended Functions

Do you open the microwave door to turn it off sometimes?

Do you use the steering wheel as a support to help you get in and out of your car?

Have you ever used a small screwdriver as a bradawl?

Let's face it, this is real world stuff - not all of your customers will use your products in the same or even in the intended way! Some users will intrduce unintended functions - from light to heavy use.

In terms of the design intent should you take these into consideration? Of course you should, it is necessary to consider unintended functions. Sometimes, defining such functions is critical to the products success.

4. Stop it going wrong!

The great thing about FMEA is that it never limits creativity but it does help you to decide the best available option - especially when it concerns customer safety!

In Design FMEA (DFMEA) current controls are all based around the design process and confirmation, verification and validation testing of that design. However there must be a thorough and honest review of how effective these controls will be in detecting failure.

Consider the following:

• Do your tests contain the conditions for both light and heavy customer usage profiles? A light user could cause higher levels of stress upon a given design
• Is the test population significant enough to ensure that the failure mechanisms will be present? If only 5 are tested, is this a significant enough quantity when you are looking to sell 5 million with a life expectancy of 5 years or 250,000 cycles?
• Does the test sample represent a true manufactured situation? Often prototype parts are used that do not feature the process variation experienced during manufacture
• Are design strength issues considered as part of the test? Depending on the manufactured condition the design strength has a distribution of its own
• Is the control in question in use now or intended to be used / developed at some time in the future? Only those controls in use / available at the time of the FMEA should be considered

So what is stopping you from doing it right?

Don't think you need to? Don't want to? Don't know how to? Didn't know it was important? Don't have the time?

Now you have no excuse! Go to our FMEA page to review all of the resources available for download

Alternatively, if you have a question or need help, you can contact me directly:

Graham Cripps

graham.cripps@resultsresults.co.uk

Tel: 01371 859 344

www.resultsresults.co.uk

You can also access an FMEA snapshot by clicking on the icon below:

P.S. What is the function of a pen?

If you said write, I’d say wrong!

Here are just a few functions of a pen: contain ink, provide grip, dispense ink

A pen will only write if it is used as part of a larger system – got it?

FMEA – Define the Product Design Function(s) or Intent – Step 2

Defining the product design function(s) is key to the success of conducting a successful Design FMEA.

FMEA is a risk management tool that looks at and manages the risk of failure of the product functions. Failure to identify these functions leads to failure of managing the risk of those failures.

Once again I will use the Design FMEA to demonstrate the FMEA process.

Introduction

If we know all of the functions that a design has to achieve, then we can consider how those functions could potentially fail to meet the customer requirement. This is the key to understanding the exact functions that the product performs.

This often causes difficulties with FMEA’s as there is a tendency to generalise functions as a combination of functions. In the first FMEA article I used a pen as an example.

Pen Example      

Let’s consider the design a fountain pen. What is a primary function of a pen? To write?. We cannot design this pen to write on its own!    

We have to consider our design functions which might be: to retain ink, to dispense ink, to provide comfortable grip, to allow left and right handed use, to resist leaks, to provide smooth contact on writing surface etc.”

The outcome that a user expects is that (in the hands of a capable person) the pen will write. However, this is not a single function of the pen design as seen in the above example but a combination of functions that deliver the customer requirement.

Define the Product Design Function(s)

A robust method of defining a products function is the use of the Function Tree. I gave a brief description of the process in a previous article but I will explain further how this is applied. 

The function tree is a process used to determine prime functions and their subordinate functions for a given product. The process steps are as follows: - 

• Brief the team

• Brainstorm the functions of the product

• Organise the brainstorm outputs onto a function tree

Brief the Team

The team is led by the design owner and briefed on the process steps and the methodology for defining the functions.

The team meeting would be arranged with appropriate team roles (leader, scribe, time manager and facilitator) and the agenda would be set to allow time for briefing, brainstorming, organising the brainstorm output and reviewing.

Brainstorm the Functions of the Design

Follow the rules of brainstorming as follows: - 

• Keep the output visual

• Keep to the allotted time (time managers role)

• Volume is king

• Do not discuss ideas (this comes later)

• Do not criticise

• Involve all of the team (facilitators role)

• Do not organise the brainstorm (this comes later)

We use a VERB-NOUN sentencing technique to describe each function.

Example - Using the fountain pen as an example, functions would look like this: -

Organise the Brainstorm Outputs onto a Function Tree

It is very seldom that design specifications are written in this way so we use the Function Tree tool to capture and sort all the functions of a design from Primary functions to tertiary functions. 

Primary Functions – those that are identified nearest to the customer usage intent 

Secondary functions – those unique functions that support the primary functions 

Tertiary functions – functions that support the secondary functions and typically support more than one function.  

Measureable level – sometimes referred to as actionable level, are those functions that will have a specific measurable or set of measurables that can be specified.

First, Organise the Brainstorm Output by selecting the primary functions, then secondary and so on. Remember there may be more that four levels and it’s OK to add or duplicate functions (see fig 1).

The model used shows just four levels. However, in practice this may be more or less than four.

To check that the functions actually support one another, start by asking “How?” the primary function is achieved, through to the secondary and so on (see fig 2).

Then we ask of the tertiary functions "why?" and moving back up the tree, providing the answer at each level, making grammatical sense throughout.

The purpose of an FMEA is to precent failures of function. Therefore, if a functions is not fully described, prevention of failure of that function cannot be managed. This will become even more evident when I describe how to detrmine and record failure modes (the way a product funtion could potentialy fail).

Complete the FMEA Form

At this stage, all the primary functions are recorded on the FMEA Form. Recording the primary functions does not mean that the other functions will be missed, there is a discipline that needs to be observed for all FMEA meetings whixh is explained in the next section.

FMEA Discipline

Accepting that conducting an FMEA is a team event, it is also important to remeber the following: -

• Keep the Boundary diagram displayed during every meeting

• Keep the Function Tree displayed during every meeting

• Complete the assessing questions at the end of each FMEA stage

• If questions remain unanswered at the end of any meeting, keep a question log for the team.

Graham Cripps

Results Consortium Ltd

www.resultsresults.co.uk

FMEA – Determine the scope of the FMEA (FMECA) - Step 2

Having formed the FMEA team you now need to determine the scope of the FMEA.

Introduction

The scope of the FMEA describes, very precisely, what will and what will not be included in this FMEA. That’s not to say that items or interactions that are excluded will not be subject to an FMEA but just not in this one.

Defining the scope of the FMEA uses a tool called a boundary diagram. This is a simple tool based upon a block diagram and is explained later in this article.

This activity requires the core team to contribute as consideration will need to be given to not only the target item (the item that is the target of the FMEA) but also any direct or indirect interactions with other components, sub-assemblies or systems.

Constructing the Boundary Diagram

The Boundary diagram is constructed in three phases: -

• Draw a block diagram of the item and it’s directly connecting items

• Determine the interactions between the target item and all connecting parts

• Agree the boundary to be considered in this FMEA 

For the purposes of this article I will use a the design of spark plugto demonstrate how to construct the Boundary Diagram.

1. Draw the Block Diagram

The first step is to draw a block diagram including all of the directly connecting parts, sub-assemblies or systems.

I have used a generic example of a spark plug assembly to demonstrate how this might be done.

In this example I have simplified the blocks to show the main components that have a functional relationship to the spark plug assembly.

2. Determine the interactions

The second step requires the FMEA Team to consider the relationships between all the items in the block diagram.

In this example I have suggested some linkages. 

E.g. The relationship between the plug assembly and the gasket ring is the retaining fit, the relationship between the spark plug assembly and the fuel mixture is the spark gap in the correct position.

I have kept this diagram fairly simple for demonstration purposes. In most cases at this point we would also consider the robustness issues as well.

Robustness - introduced by Genichi Taguchi and refers to the operation of a component, sub-assembly or system in the presence of the operating environment and all of the internal and external variations.

3. Agree the Boundary of this FMEA

Having agreed the block diagram and the connections or linkages between each of the blocks, the team now determine the scope of the FMEA. The scope of a design FMEA (DFMEA) is restricted to:-

• Failures attributed to design only (i.e. does not include manufacturing , fitting or other induced errors unless through design issues) E.g. If a spark plug was fitted but cross threaded, this would not be considered unless the relationship between the cylinder head and the fitting tool induced the error.

•  Analysis of items within the boundary diagram

In this example the boundary diagram shows that this FMEA will include the spark plug assembly, the provision for retaining the spark plug connector, the provision for retaining the retained gasket ring, the retained gasket itself, positioning of the spark gap and provision of a hexagonal shape for the fitting and removal tools.  However we won’t include the plug removal tool, spark plug connector, fuel mixture or the cylinder head in this FMEA.

What the boundary diagram does for the FMEA Team is to provide a focus for the analysis. This does not mean that all the other linkages and interactions are not subjected to analysis, just not in this instance.

FMEA is like a jig-saw puzzle. Each FMEA fits into the jig-saw puzzle to build the complete picture of the design

Using the Boundary Diagram

Once completed, the boundary diagram becomes a visual aid for the FMEA team to use at each meeting to ensure that they are focussed on the agreed scope of the FMEA.

FMEA Template

My previous article discussed forming the FMEA Team and included a free FMEA Template (FMEA Form). If you would like a copy please click on the link at the begining of this paragraph.

Graham Cripps

Results Consortium Ltd

www.resultsresults.co.uk

FMEA – A team based and structured approach

Introduction

Potential Failure Modes and Effects Analysis (FMEA), or the analysis of the effects of failure of a design is used widely in the automotive, aerospace and associated industries.

A team based activity using an FMEA Template, Failure Mode and Effects Analysis (FMEA) is a risk management tool that, when applied well, can minimise the risk of failure of a product, process, service or design. FMEA is not a standalone quality tool it is supported by customer requirement input, customer usage data and other quality tools. 

A completed FMEA is only the beginning. The output of the FMEA is an action plan to minimise the risk of failure in one or more of three ways: - 

• Minimising the severity of the effects of failure – the most difficult to do

• Minimising the likely occurrence of the causes of potential failures

• Maximising the detection or prevention of the failure mechanism (causes of failure) by providing data for design verification plans

A structured process, FMEA is often thought to be a difficult tool to use. However, where the design of a process, product or service has been well researched, documented and planned, FMEA builds on this knowledge and uses this data to consider all the risks associated with the use of the intended FMEA design.

The FMEA Template (or form - please see link at bottom of post)

Contrary to popular belief, the FMEA form does not drive the FMEA process, in fact the FMEA form has two specific purposes: -

• To record and communicate the FMEA progress and outcomes

• To record the action plan for, and the monitoring of, all necessary actions identified during the FMEA process.

The FMEA Process

There are 10 steps in the FMEA process. For the purpose of this article we will concentrate on the Design FMEA. 

STEP 1 – Form the FMEA Team

The FMEA is carried out by a core team whose members are dictated by the subject of the FMEA and would include: Design Engineer, Process Engineer, Customer Representative (someone who has a clear understanding of customer requirements), and Quality Engineer.  A support team is established to support the FMEA process as and when required and typically include: specialists; supplier representatives. 

It is critical that the team includes at least one experienced FMEA practitioner to ensure the success of the FMEA activity.

 STEP 2 - Determine Scope of the FMEA

An important step in the FMEA process is to set the scope of the FMEA (what will and what will not be included in this FMEA). If too much is included, then the FMEA becomes very time consuming and difficult to manage. This is one of the biggest reasons why FMEA’s often fail.

To determine the scope of a Design FMEA a Boundary Diagram is used. The boundary diagram is constructed from the design specification and should include the physical links or interactions between parts and sub-assembly levels. Also to be considered are the outcomes of the Robustness study. These linkages include considering the operating environment, interactions with other systems, customer usage (intended and unintended) and fatigue.

Once the boundary diagram has been completed and the scope identified, the composition of the team will need to be reconsidered to ensure all the necessary skills and knowledge are available to the core team.

Step 3 - Define the Product Design Functions (or Intent)

If we know all of the functions that a design has to achieve, then we can consider how we could potentially fail to meet the customer requirement. This is the key to understanding the exact functions that the product performs.

Example:  We are to design a fountain pen. So what is a primary function of a pen? To write? Well, no. We cannot design a pen that writes on its own!

We have to consider our design inputs which might be: to retain ink, to dispense ink, to provide comfortable grip, to allow left and right handed use, to resist leaks, to facilitate smooth contact on writing surface etc.

We use a VERB-NOUN sentencing technique to describe each function. To dispense (verb) ink (noun). So a pen could fail to dispense ink. The user would experience failure to write, but this is the effect of failure of a prime function (this principle is explained later in this document).

It is very seldom that design specifications are written in this way so we use the Function Tree tool to capture and sort all the functions of a design from Primary functions to tertiary functions. To do this, the functions are brainstormed using the sentencing technique (described above). The Prime Functions are then identified from which we ask “how is this function achieved”. Using other functions brainstormed, the process is continued until an actionable level is reached (a level that could have a measurable attached to it based on the design specification). This is repeated for all primary functions. Then we ask of the tertiary functions why and moving back up the tree, providing the answer at each level, making grammatical sense throughout. See our separate article on the use of function trees.

Step 4 - Define Potential Failure Modes

Failure modes are often confused with the effects of the failure mode i.e. the toaster gave me a shock!. The failure mode is “fails to provide electrical insulation” where the shock is an effect of the failure. “Provide electrical insulation” is the function.

Failure modes are limited to just four main categories: -

• Total Failure – the product fails to deliver the intended function

• Partial Failure – the product fails to deliver all the intended function

• Intermittent Failure – the product fails to deliver the intended function sometimes

• Degraded Function – the product functionality degrades over time

There can be no other type of failure. Consider a domestic toaster. It can fail as follows:

Total – does not heat up or retain bread

Partial – heats up but does not retain the bread

Intermittent – sometimes takes three or four attempts to retain or heat the bread

Degraded – over time the toaster takes longer to brown the toast

All failure modes (the way the product fails to meet the designed intent or customer need) will fall into one of these four categories.

At this stage the Design FMEA process has a team established that are capable and knowledgeable to perform the FMEA and have a specialist support team identified. The scope of the FMEA and the potential failure modes have been identified and fully described.

Step 5 - Determine and Rank the severity of the effects of failure.

The effects of the failure modes are considered by the team in the following 7 categories: -

•  Part (subject of the design FMEA)

• Assembly (the next level assembly that the part fits)

• System (the system that this part contributes to)

• Product (the overall product)

• Customer (the user of the product)

• Regulations (current legislation applicable in the country of use)

• Other (any other category that may be industry or market specific)

The effects are recorded on the Design FMEA effects list (optional) and the FMEA form against the failure mode being considered. This will give a natural left to right flow       across the FMEA record.

Each effect is now ranked in terms of its severity using the Design FMEA ranking tables. The highest severity is the one carried forward and recorded against the failure mode being considered.

Step 6 - Determine and Rank the likely occurrence of the causes of the failure modes

At this point we need to understand that the effect of the failure mode and the cause are not linked, other than through the failure mode itself. In other words, we are looking for the cause/s of the failure mode. The failure mode has effects that are experienced (sometimes called symptoms) as a result of that failure mode.

The team should brainstorm all the possible causes of failure. At this point it is important to note that we are confined to the scope of the failure mode of a specific function. Failure of the design to perform as intended. Therefore, mistakes that may be made during manufacture of the design can only be considered if they are as a direct result of design omissions.

Once the failure modes have been established, they are arranged in order against the failure mode on the FMEA form (a continuation of the flow established during the last process step).

Using the Design FMEA Ranking tables, each potential cause is ranked as to the likelihood of occurrence. The ranking is recorded alongside the cause in question.  Because the use of ranking tables is not an “exact science”, the introduction of past experiences and other data is useful.

Step 7 - Establish and Rank all existing Design Controls

At this stage we are considering the existing design controls, this will include all those that are part of the current design and design verification processes. These controls may fall into one of four categories: -

•  Detection controls that will detect the cause of failure

• Detection controls that will detect the failure mode

• Preventative controls that will prevent the cause from occurring

• Preventative controls that will prevent the failure mode from occurring

Once established, we use the DFME rating tables to rate how likely these controls are to work, the higher the number the less likely the control will work.

For example, if a design verification test does not consider or test for the cause (or failure mode), then this test will rate 9 or 10. If the test does consider the cause (or failure mode) and is such that it includes for the most demanding customer profile, then the rate could be 2 or 3 (ranking needs to consider the size of the tested population).

This process is repeated for all causes. In many cases, the causes will impact on more than one failure mode.

Step 8 - Calculate the RPN and establish priority of, and determine the actions required

As mentioned in the introduction, FMEA is a risk management tool and this and the next stage are all about minimising the risk of potential failures. We now have a record of: -

• All the potential failure modes

• The effects of failure for each failure mode and their severity rating

• The causes of failure for each failure mode and their likely occurrence rating

• The current detection and prevention design controls rated in terms of likelihood of detecting or preventing each failure mode.

Armed with this information we can now consider which of the failure modes is of greatest concern to the business. To do this we need to consider how we are going to prioritise them. To do this we calculate the Risk Priority Number (RPN). However, the RPN used in isolation can be misleading.

Results recommend the following approach when considering the priority of any required actions:-

• High severity with high occurrence, form the obvious highest priority.

• Other combinations will be driven by the company priority policy.

NOTE: in many cases it will not be possible to reduce severity therefore the focus must be on reducing likely occurrence.

Step 9 - Plan and implement improvement actions and establish revised RPN

We are now nearing the completion of the DFMEA process whereby the identified and agreed actions are to be planned and implemented. To this end, as well as throughout the FMEA process in general, we used the Deming P.D.C.A. Cycle (refer to your free FMEA Snap Shot Template)

DO – Carry out the modifications to the necessary design processes. This includes documenting the changes in all associated processes and reviewing test data outcome requirements.

CHECK – Carry out checks to ensure that the changes have taken place and are effective.

ACT - Take action on any advers results

Step 10 - Close the DFMEA process

The Design FMEA has now been completed for the chosen design function or design intent. However, the FMEA process cannot be considered complete until all the final closing actions have been taken. These include: -

• The DFMEA has been fully completed and all actions closed out.

• The question log has been fully closed out

• All lessons learnt have been recorded and communicated

• All processes now reflect the new agreed standards

• The FMEA Champion is fully aware of the outputs from the DFMEA

• All core and support team members’ contributions have been formally recognised.

• The complete DFMEA includes all documentation raised during the process including: -

• Data gathered

• Function tree

• Boundary diagram

• Change notes and other actionable documents.

 Graham Cripps

Results Consortium Ltd