In my recent blog,”Model-Based FMEA”, I wrote about the functional model serving as the basis of the Design FMEA in the IQ-Software.  The basic premise is that we will fully know the failures when we understand the function; only when we deviate from the function (in a significant way), do we achieve “failure.”  Through this logic, I propose that we aren’t likely to correctly and comprehensively define the failures if we can’t clearly state the functions.  In other words, if we define that bolt and nut exist in our system for the purpose of clamping plates A & B together, we can think most clearly and comprehensively of the failures, “clamp load too low,” and “no clamp load provided.”  With clear functions, we get clear failures.

Function

The fundamental basis of a solid DFMEA analysis is the functional description.  So how do we write a “good” function?  And, what’s “good” anyway? Good equates to stating, in verb-noun format, why the device exists and what actions it performs in service.  A bolt wasn’t placed in service to prevent corrosion of itself!

The function must never be confused with the requirement.  The requirement, “Prevent Corrosion,” should not be confused with the primary function of the bolt and nut, to “Provide Clampload.”  If we base our function/failure analysis on corrosion, we start to get lost; by defining the failure of the bolt to be “Corrosion” we lose sight on the failure of the clampload.  There are some very good energy-based function writing methodologies available on the internet that can be found with some simple searches.  One you may not think to look for, unless you’ve been trained in the methodology, would be the function writing methodology with the TRIZ way of thinking… and if you don’t know TRIZ, I’ll leave that discovery to you.  Trust me, it’s a fascinating story of how it came to be and a wondrous methodology for breaking-through design problems.

In my years as an FMEA practitioner and facilitator, I find the concept of function writing to be the most difficult for engineers to consistently perform correctly over time.  The draw of the “requirement” is just too strong.  We drive these points home in our training from APIS because the point isn’t just to teach how to run the IQ-Software.  The point is to become skilled in performing high-quality, function-based, risk analysis on your systems.  Carry on!

Find us on:
&