Featured Product
This Week in Quality Digest Live
Risk Management Features
Wudan Yan
Cold plasma and high-pressure systems might help reduce the risks of foodborne disease outbreaks
Mike Richman
Whether close at hand or far afield, gratitude surrounds us
Paul Foster
Achieving sustainable continuous improvement
Amy Mahn
The five functions of NIST’s Cybersecurity Framework
Ryan E. Day
How BioBridge Global leverages a digital QMS in the heavily regulated world of regenerative medicines

More Features

Risk Management News
How to build your dream team, explode your growth, and let your business soar
Transforming a dysfunctional industry
An invite from Alcon Laboratories
Why not be the one with your head lights on while others are driving in the dark?
The FDA wants medical device manufactures to succeed, new technologies in supply chain managment
The audit solution provides 360-degree, real-time visibility into nonconformance status and completion
Preparing your organization for the new innovative culture
Standard recognizes that everyone is critical to a successful quality management process.

More News

Richard Harpster

Risk Management

The Case Against the AIAG-VDA DFMEA

Why this methodology should not be adopted

Published: Wednesday, January 31, 2018 - 13:42

Richard Harpster's op-ed is in response to a recent Quality Digest article and webinar discussing the benefits of the draft AIAG-VDA FMEA Handbook. As he points out at the end of this article, the AIAG has provided a means to solicit comments, pro or con, on the handbook. We encourage interested parties to provide feedback to the AIAG.
--Editors

On Nov. 27, 2017, the Automotive Industry Action Group (AIAG) made a draft available of the co-developed AIAG-VDA FMEA Handbook for a 90-day stakeholder review and commenting period. The group who developed the handbook should be applauded for attempting to develop a standardized method for failure mode and effects analysis (FMEA) to replace the German Association of the Automotive Industry (VDA) and AIAG methodologies, and asking for public comment on the results of their efforts before its release.

Unfortunately, if adopted, the handbook’s proposed design FMEA (DFMEA) methodology will result in an implementation that is considerably less effective and much more inefficient than AIAG’s current methodology, found in its 4th Edition FMEA Manual. Although this article will provide general information on how the AIAG-VDA Handbook DFMEA and AIAG 4th Edition DFMEA methods work, it will not go deeply into the details.

The definition of risk

Risk has two components: the severity of harm when an objectionable incident occurs and the probable occurrence of the objectionable incident causing the harm. When managing risk in the design process, an objectionable incident occurs whenever a product design fails to meet a product design requirement.

Purpose of a design FMEA

The primary task of the design engineer is to create a set of specifications that define a product that will meet the product design requirements. The specifications contain the information required to build the product. They include dimensional and material specifications as well as required software code, if applicable. Due to the wide variety of product design requirements a product might have and the fact that some of the requirements can be competing, it is often impossible for the design engineer to define specifications that will meet all the product design requirements all the time. All designs have risk when they are released for manufacture.

When done properly, the DFMEA is a structured risk assessment of the adequacy of the product design specifications in defining a product that will meet the product design requirements. It enables the design engineer to identify the product failures that can occur and the specifications that control whether such failures will happen. When properly performed, the design FMEA allows the design engineer to identify the product design specifications that must be risk-optimized to reduce the design risk to a level that is acceptable to both the customer and company.

Example: Potential design failure requiring risk management

Following is a very simple example to explain how a properly performed DFMEA is used to manage risk. The product that is the focus of the example is a twin bed. The target life for the twin bed is 10 years. The twin bed is supposed to be able to withstand the forces of a 250-lb person getting into and out of the bed four times per day, which is a total of 14,600 entry and exit cycles over the target life of 10 years. There is a concern that the wooden legs might structurally fail due to occupant entry shock impacts over the bed’s lifetime due to the lower limit of wooden-leg diameter specification being too low. The company wishes to assess the risk of releasing the current twin bed design with the current wooden-leg diameter specification.

Using the AIAG DFMEA method to manage risk

Following is a properly constructed DFMEA using the AIAG 4th Edition DFMEA method that could be used to assess the risk of releasing the current wooden-leg diameter specification described above.

The job of the example DFMEA is to determine the risk of wooden-leg fracture due to releasing the current wooden-leg diameter specification to manufacturing. The concern is the lower limit of the specification may be too low. The DFMEA accomplishes the risk assessment in the following manner:
1. The verifiable design requirement that the DFMEA is assessing, the adequacy of the product design specification, is placed in the “Item/Requirements” column. (“Must be resistant to 14,600 entries and exits of a 250-lb person over 10 years.”)
2. The failure to meet the design requirement is defined in the “Failure Mode (FM)” column. (“Leg fracture due to shock impact from repetitive entries.”)
3. A description of the harm that can be experienced when the failure occurs is provided in the “Failure Effects (FE)” column. (“Possible injury to occupant.”)
4. A numerical rating is placed in the “Sev” (i.e., “Severity”) column, which corresponds to the severity of harm described in the “Failure Effects” column. (“10.”)
5. The product design specification whose adequacy is being assessed and the way it may have been mis-specified is entered in the “Failure Cause (FC)” column. (“Wooden-leg diameter is specified too small.”)
6. The method that will be used to determine the probability of the “Failure Mode” happening due to the “Failure Cause” are placed in the “Prevention” and “Detection” controls column. (“Bed Entry and Exit Durability Testing.”)
7. A numerical rating equivalent to the probability determined by the “Prevention” and “Detection” controls, is placed in the “Occ” (i.e., “Occurrence) column. (“2”.)
8. The “Sev” and “Occ” are looked up in a risk matrix that has symbols corresponding to the level of risk indicated by the “Sev” and “Occ” ratings. The appropriate risk level symbol is placed in the “Class” column. (“YS.”)

Using the proposed handbook DFMEA methodology to manage risk

In the AIAG-VDA DFMEA method, the design requirements, failure modes, effects, and causes are not entered directly into the DFMEA as they are in the AIAG 4th Edition FMEA. They are derived from a structure analysis, function analysis, and failure analysis. As we will see, this proves to be much more inefficient.

The first step is to create a structure analysis. For the example provided, one would create a structure analysis by creating a graphical representation of the literal description of the twin bed construction, including the wooden-leg diameter specification. The following is what the resultant structure analysis would look like.

 

The next step is to create a function analysis, which is derived by defining the design functions/requirements for the assembly, subassemblies, and components of the structure analysis. Because we are performing a DFMEA to assess the risk of a specific product failure, the twin bed assembly function would be limited to “twin bed assembly must be resistant to shock impacts from 14,600 entries and exits of a 250-lb person over 10 years.”

The next step would be to define the design function/requirement. Because a portion of the shock seen at the mattress will be absorbed by the mattress and wooden-leg rubber wheels, a lower impact load will be seen by the frame subassembly. Determination of the impact of the mattress on the shock load seen by the frame subassembly could take considerable time and effort. The impact of the wooden-leg rubber wheels on the shock load on the frame subassembly is even more complex because changes in wheel dimensions and material type could result in the wheel absorbing different levels of shock, thus changing the design requirement.

For these two reasons, it would be extremely difficult and highly unlikely that the twin bed designer would attempt to define a verifiable shock-load resistance requirement at the frame subassembly level unless forced to define one to fulfill the need to populate a function analysis. If forced to define one, the most like entry would be something like “Frame subassembly must be resistant to shock impacts from 14,600 entries,” which is not verifiable.

Because we are unable to define a verifiable design function/requirement for the frame subassembly, it will also be impossible to define verifiable design function/requirements for the wooden-leg subassembly and wooden leg. Like the frame subassembly, the most likely design function/requirements that will be created are “wooden leg assembly must be resistant to shock impacts from 14,600 entries” and “wooden leg must be resistant to shock impacts from 14,600 entries,” neither of which are verifiable.

The function analysis for the example provided would look like the following:

 

Once the function analysis has been created, the next step is to construct the failure analysis. When constructing the failure analysis, each failure must be described in terms of the level at which it occurs.

Keep in mind that the AIAG-VDA DFMEA method does not allow you to talk about structural failure of the wooden leg until you get to the wooden leg level in the analysis. So, in our example, the first failure would be at the twin bed assembly level. Because the failure must be defined in terms of the level at which the failure occurs, a failure entry for the twin bed assembly level would be “twin bed assembly structural failure due to shock impact from repetitive entries.”

Using the same logic, the second-level failure would be “frame subassembly structural failure due to shock impact from repetitive entries.” The third level failure would be “wooden leg subassembly structural failure due to shock impact from repetitive entries.” The fourth level would be “wooden leg structural failure due to shock impact from repetitive entries.” Finally, in the fifth level, we get to the product design specification issue we wish to investigate, which is the “wooden leg diameter is specified too small,” a result we got to much more quickly and efficiently in the AIAG 4th Edition FMEA.

Following are the resultant structural, function, and failure analyses that will be used to construct the DFMEA.

The AIAG-VDA DFMEA form was developed to support the implementation of the structure analysis, function analysis, failure analysis, and DFMEA. Consequently, there is additional information in the handbook DFMEA form that is not found in the AIAG 4th Edition DFMEA form. This additional information is not needed to support the use of the DFMEA as a design risk management tool.

Following is information that is common to both the AIAG-VDA DFMEA and AIAG 4th Edition DFMEA methods and is derived from the structure, function, and failure analyses. The table shows the slight difference in terminology between the headers of the two methods.

 

Instead of the one DFMEA required to handle the issue with the AIAG 4th Edition DFMEA method, we now need four DFMEAs when using the proposed AIAG-VDA method. A review of the contents of the multiple AIAG-VDA DFMEAs reveals every design FMEA has a design function/requirement that is not verifiable or a failure cause that does not identify the product design spec that is being assessed. The presence of either of these conditions makes the line of the design FMEA that they occur on ineffective for managing risk. Two of the four DFMEAs generated using this method have both conditions present.

It is not uncommon when reviewing DFMEAs created using a DFMEA methodology that populates using the structure, function, and failure analysis (i.e., the AIAG-VDA DFMEA methodology) to find that every line of every DFMEA either contains a design function/requirement that is not verifiable or a failure cause that does not identify a product design specification that may have been improperly specified.

Conclusion

If the AIAG-VDA DFMEA methodology (which uses structure, function, and failure analyses to determine critical DFMEA content) is implemented, it will result in an automotive DFMEA process that is both considerably less effective and much more inefficient than the current methodology described in the AIAG 4th Edition FMEA manual. A better path to standardization between VDA and AIAG design FMEA methodologies is to accept the current AIAG 4th Edition DFMEA methodology as the starting core methodology and make the necessary adjustments to it to arrive at a joint AIAG-VDA DFMEA standard.  

Given the large number of companies already using the structure, function, and failure analysis to create the content of their DFMEAs, this article is sure to be met with a lot of resistance. If you have any questions about anything in this article or other elements of the proposed AIAG-VDA FMEA Handbook, please feel free to contact the author. If you wish to provide comments to the AIAG about the proposed changes you can do so at the AIAG Quality Store.

Discuss

About The Author

Richard Harpster’s picture

Richard Harpster

Richard Harpster is president of Harpco Systems, which he founded in 1987. Harpco Systems specializes in providing software, training, and consulting for risked-based product lifecycle management (RBPLM). During the past 30 years, Harpster has helped hundreds of companies implement improved risk-based design and manufacturing systems in a wide variety of industries. He is a recognized expert in the application of FMEAs and has invented several new concepts, including the linking of design FMEAs to process FMEAs in 1990, which became an automotive industry standard 18 years later. His latest inventions in the field of RBPLM include Requirements Risk Assessment (RRA), Usage Risk Assessment (URA), Multiple Integrated Cause Analysis (MICA) and Rapid Integrated Problem Solving (RIPS). He has published several papers on the topic of RBPLM.

Comments

The Case Against the AIAG-VDA DFMEA

Did you attend the AIAG Quality Summit where the team of volunteers on this effort presented detailed information on why the changes were made to over 100 attendees?  I did and most of the people that I spoke to see the changes as continuous improvement.  We all know that people do not like change.  As a quality professional, you know that you cannot have continuous improvement with change.

It would be helpful if your article included reference to meetings or phone calls that you had with any of the volunteers that have spent a tremendous amount of time to make the new AIAG VDA FMEA standard.   I believe the volunteers that worked long and hard on creating a new and innovative FMEA processes to achieve the goal of a global automotive standard, the ones that wrestled with terms, formatting, approach, would be happy to share their input on this subject.

There is now a “white paper” being distributed regarding this article that includes a new introductory paragraph with the statement that this article provides “proof that the new approach is considerably less effective and more inefficient.”   Unless this article was written with a significant amount of research (more than a single example by a single individual), and input from any of the people involved in the process, and maybe included some data driven voice of the customer survey results, then this article should be properly labeled as “your opinion” as it does not qualify as “proof.”

Please let me know if you disagree with my opinion regarding this article.

John M. Cachat

AIAG-VDA FMEA Handbook

Mr. Cachat,

I have over 20 years of experience with the VDA methodology.  I had the opportunity to talk to one of the people who participated in the writing of the 1996 Edition of the VDA manual many years ago.  The original manual was designed to push a software which anyone who has knowledge of the VDA process knows the name of the package.  The preference of the software package has plagued the VDA for years.  Page 3 of the 2012 version of the VDA Volume-4: Product and Process FMEA contains the following disclaimer: “It is pointed out that no special software program was preferred by these representatives”. 

The original software vendor now has multiple competitors.  Consequently, although the 2012 standard on which the new AIAG-VDA DFMEA methodology is based does not demonstrate a preference for any particular software package it is pushing the methodology embodied in the original software and its current competitors rather than an optimized form of Design FMEA or Process FMEA.  In the next couple of weeks, there will be an additional article published highlighting why the proposed AIAG-VDA PFMEA methodology is less effective and more inefficient that than the AIAG 4th Edition PFMEA methodology.  We have not decided on a publication source yet.  When we do, we will post it here.  You will also be able to obtain a copy on our website at www.harpcosystems.com.

The fundamental flaw of the VDA DFMEA methodology in the 1990’s still remains the fundamental flaw of the VDA DFMEA methodology in 2018.  The VDA DFMEA methodology more closely resembles a fault tree analysis than a Design FMEA process.  In a fault tree, the only root causes are the last leaves on the tree.  In a properly performed Design FMEA all causes of every line of the Design FMEA must be a root cause if the line of the DFMEA is to be used to manage risk.  Another critical element of an effective Design FMEA is that the Requirements in the first column must be verifiable.  One only needs to look at the examples in the proposed AIAG-VDA Handbook, VDA System FMEA Failure Mode and Effects Analysis (1996) and VDA Volume-4: Product and Process FMEA (2012) to see that non-verifiable requirements are a very common occurrence in the Function Analysis.  The reason for this is that you do not need verifiable requirements to perform a fault tree analysis.  In fact, you don’t even need requirements if you are doing a fault tree analysis.  If you look at the diagrams explaining the failure relationships between the different assembly, subassembly and components in the AIAG-VDA Handbook (page 45), 1996 VDA Manual (page 41, 42, 43) and 2012 VDA Manual (page 40) you will find no reference to a function.  When I look at some of the failures in the Failure Analysis I sometimes struggle how it was derived from the function in the Function Analyis.

The example in the article was made very simple so people could understand the differences between the VDA and AIAG 4th Edition DFMEA methodologies.  In the next 24-36 hours I am going to redo the article and replace the Twin Bed DFMEA example with the Throttle Positioner example found in the VDA Volume-4: Product and Process FMEA Manual (2012).  I will clearly demonstrate why Design FMEA methodologies which use the structure, function and failure analysis trees to populate the DFMEA are both ineffective as a risk management tool and very inefficient.  The new article will not be published on Quality Digest.  I will post a shortcut here when it is available.  The article will also be available on our webite.

As far as my qualifications to write the article, I have never used public opinion to determine the proper way to perform a Design or Process FMEA.  I invented the concept of linking DFMEAs to PFMEAs in 1987. I taught people not to use RPN in 1990.  As a plant manager, I always had my people include receiving in our Process FMEA despite the fact that the AIAG Process FMEA manual told me not to.  I knew out of spec product from our suppliers was one of our greatest sources of risk.  After nine months of implementation of the way I thought Process FMEAs should be done and not the way the manuals were teaching the process, we had average measurable cost savings of $144,000 per week in our plant.  I was excited about the power of Process FMEAs.  People thought I was crazy.  After 30 years of doing Design and Process FMEAs on everything from cancer treatments to hybrid vehicles to flat screen TVs I feel very qualified to speak on the topic of Design and Process FMEAs.

Rich Harpster

The new method may make the DFMEA more exhaustive

Going through the breakdown of systems in subsystems and components is an enabler of more exhaustive DFMEAs where the DFMEA team considers all the potential failure modes of all subsystems and components. The new process should allow more design specifications at the subsystem levels and component levels. DFMEA team members should consider failure modes of the components and failure modes of the interactions among different components. The team should also account for the implications of the specifications. For instance in the twin bed example, if you assume that the supports of the beds have saddle-like dampers then the design of the bed may pass a dynamic test while failing a static load. Hence the team needs to define static load specifications, which is quite realistic since two people may sleep on the twin bed for let us say10 hours.

The question here is: Should the team record the breakdowns in new forms? Not necessarily as long an auditor or a reviewer assesses every DFMEA to ensure that the DFMEA team has taken into accounts failure modes inherent to each subsystem and each component. Mandating that DFMEA teams record the trees in new form means the AIAG and VDA are not confident that for every organization, DFMEA teams will define failure modes for every subsystem and for every component.

However, even when there such mandates, a team may still miss important failures modes as I illustrated with the static load failure mode. There may even be other misses. For instance, requiring that bed users do not weight greater than 250 pounds does not mean that users may follow such rules. Such requirement by itself requires a design specification – need for a technical bulletin to be communicated to all business customers and individual end users. We have to be careful; the tree may be mandatory while the content of the DFMEA is not robust. The role of auditors/reviewers is critical.

Full disclosure and transperancy

I did not mean to challenge your qualifications.  I respect your background and reputation. 

I still maintain there is a difference between "proof" and "opinion."

In the spirit of full disclosure and transparency, you reference an "1996 VDA edition designed to push a software.”  I think it is appropriate for you to disclose to the readers that your company, Harpco Systems, sells Quality Plus a FMEA software package that will have to be updated to reflect these changes that will take time and cost you money.

VDA Vs. AIAG Comparison Using VDA Manual Example

In response to comments that the proof presented in the article about the problems with the proposed AIAG-VDA Handbook DFMEA methodology was invalid because of the simplicity of the Twin Bed example provided, I have written another paper which uses the Throttle Positioner example found the 2012 VDA FMEA manual.  This example was used by the VDA to explain how to implement the VDA DFMEA methodology.  Like the first article, the paper will provide proof that the proposed AIAG-VDA Handbook DFMEA method is both less effective and more inefficient than the current AIAG 4th Edition DFMEA methodology. 

The paper can be accessed at: 

https://www.harpcosystems.com/articles/case-against-the-aiag-vda-dfmea

 

Response

Mr. Cachat,

It is true that we have a software package that supports a methodology that although not identical supports the AIAG 4th Edition FMEA methodololgy.  We have made several small but critical changes to the AIAG 4th Edition methodology because in its current form it is not optimized.  When we teach our classes, we teach them independent of any software package including our own.  If we have a workshop where our goal is to teach the concepts of the Design FMEA or Process FMEA as well as develop a deliverable for a customer, we provide the workshop output in Excel.  

We would never update our software to use the structure, function and failure analysis to determine the content of our Design and Process FMEAs because the methodology does not work and will hurt the ability of our customers to risk optimize their designs and processes.  We obviously must protect our current automotive customers in the event the AIAG-VDA Handbook goes through in its current form.  We have studied the new Excel format.  The good news is that when you always have verifyable design requirements and root causes in the cause columns of your DFMEA which we do, you solved the most difficult problem which is the creation of an effective risk management tool.  The challenge is to create the Design FMEA and Process FMEAs correctly while making it look like you used the VDA methodology to get there when you did not.  We feel confident we know how to do it.  It should take us less than two weeks to create the code once we see what has been agreed to.  We obviously would not want to waste the time doing it now.

To us the Design FMEA and Process FMEA are two critical tools that must be used correctly if risk is to be proplerly managed during the product lifecycle.  The goal is not to fill out a FMEA form to meet a customers paper requirement but to create better designs and processes.  Read my LinkedIn recommendations if you want to understand what we teach and what we are about. 

I look forward to reviewing your comments when I take the example from the VDA 2012 FMEA Manual to show why the VDA methodology is both ineffective and inefficient.  Since the example is from the manual, no one can argue it is not applicable.  If you use engineering common sense to evaluate the example and can set aside your FMEA paradigms, I believe you will see the weaknesses of the methodology.

Rich Harpster

Rebuttal

Mr. Harpster,

Compromise is never easy.  There is no simple answer.  Human beings are naturally resistant to change.  However, sometimes there are compelling reasons to consider changing long-held practices.  A comparative assessment of AIAG and VDA FMEA methods revealed many strengths and weaknesses.

Your article concludes that the team should have started with (Excel-based) AIAG 4th Edition methods, and (by inference) expected the Europeans to modify their software-based methods to conform to it.  This in an unrealistic expectation.  Instead, the methods were compared side-by side, and every effort was made to accommodate both.

The team started with one goal:  Common rating tables.  After many iterations, we finally achieved that. We then set our sights even higher; joint publication of a common FMEA method that could allow multi-national companies and suppliers in various regions to create FMEAs that would not have to be re-worked to satisfy local formats.  More importantly, we considered the fundamental need to identify the functions and intended performance requirements of the part being analyzed.  Highly complex mechatronic systems with safety-related effects require analysis which comprehensively adresses reliable detection of faults and automated responses which reduce the severity of effect in order to maintain a safe state or state of regulatory compliance.  The draft joint publication gives the advanced practitioner a basis for this assessment.  The other problem that the participants recognized was the inherent weakness of RPN in threshold-based assessments of the need for action, and the pressue to assess a low RPN by those who may be motivated to sell their product to a customer.  We considered several alternatives, and finally compromised on the prioritization of the need for action to reduce risk, rather than prioritizing the qualitative assessment of risk.  After more than three years of work by an international team of experts, a compromise was reached.  It is not perfect, as evidenced by the thousands of comments already received.  Adjudication of these comments will be an extreme effort.  However, I believe the final publication will represent a valuable contribution to the design and manufacture of quality products.  In this age of ever-increasing automation, the FMEA method must evolve to support of the needs of industry.

Mike Bucala

Daimler Trucks North America

VDA Vs. AIAG Comparison Using VDA Manual Example

In response to comments that the proof presented in the article about the problems with the proposed AIAG-VDA Handbook DFMEA methodology was invalid because of the simplicity of the Twin Bed example provided, I have written another paper which uses the Throttle Positioner example found the 2012 VDA FMEA manual.  This example was used by the VDA to explain how to implement the VDA DFMEA methodology.  Like the first article, the paper will provide proof that the proposed AIAG-VDA Handbook DFMEA method is both less effective and more inefficient than the current AIAG 4th Edition DFMEA methodology. 

The paper can be accessed at: 

https://www.harpcosystems.com/articles/case-against-the-aiag-vda-dfmea

 

Response

Mr. Bucala,

Change for the sake of change is not good when the result harms a process rather than helps it.  The AIAG 4th Edition Design FMEA manual has weaknesses but can be considerably strengthened through some rather simple changes.  I believe the VDA Design FMEA process is fundamentally flawed and I do not believe it can be fixed.

You make the statement “Your article concludes that the team should have started with (Excel-based) AIAG 4th Edition methods, and (by inference) expected the Europeans to modify their software-based methods to conform to it. This in an unrealistic expectation.”  Starting in the 1990s, the VDA process has always been about the software and not about an optimized FMEA process.  I remember sitting in a room with a gentleman who participated in the writing of the 1996 Version of the VDA manual and explaining to him why the methodology would not work.  Although he could not refute what I was saying, he simply stated that the software they used did it a certain way and that was the way it was going to be done.

As far as core DFMEA and PFMEA methodology goes, the new AIAG-VDA Handbook adopts the VDA 2012 DFMEA methodology.  The only compromise I see between the AIAG and VDA is the introduction of an extremely complicated Excel spreadsheet that contains information that plays no role in risk management but is required to support the structure, function and failure analyses.   People will never be successful in implementing the new methodology with the proposed spreadsheet.  They will need software designed to support the VDA method.

Finally, the Action Priority shares some of the same weaknesses as RPN.  In the next couple of days, I will put together a paper on its weaknesses.  We need to teach people how to properly populate the Class columns of both the DFMEA and PFMEA.  Although the Special Characteristic definition in the proposed handbook is one that many people follow, it is not the original defintion of a Special Characteristic which had a Severity and Occurrence component that could be used to manage risk.  The improper definition of the Special Characteristic has cost companies millions of dollars.

Removal of the Class Column from the DFMEA is a major mistake.  It is very effective in managing risk when used correctly.

I really hope all the comments people are sending will result in significant core philosophy changes in the proposed AIAG-VDA Handbook.  If not, I believe harmonization will do more harm than good.

Rich Harpster

Why your case is wrong

Dear Mr. Harper,

Your Structure analysis seems to be lacking the innitial element wich is the end user, on the other hand the function analysis is wrong the functions need to describe what each element is trying to achieve. In your example the functions/requirements seem to be the same, you just changed the function by adding the name of the element in discussion. The six steps in the new manual do the opposite of what you described, they promote a deeper analysis of each element by considering each element independently. I really doubt that a design engineer even with the old method would describe the function/requirements as you did in your example. In my opinion the 4th edition and this new AIAG/VDA DFMEA are not so much different in the method, I would say that the new approach with the function analysis enriched, can lead to better results as it opens discussions on functions on lower levels and many times were forgotten. Sorry to say this, I don't mean to disrespect but I am afraid that comments like this show the lack of willingless to change.

Response

I am sorry I do not know your name.  If you knew me you would know that I love change when it is good.  As a plant manager I used to tell my people that we wanted to live on the “edge of chaos” where we questioned everything but performed all changes under deliberate control when we think something will provide benefit.  To be honest I see very little benefit in the proposed changes contained in the AIAG-VDA FMEA Handbook and a lot of potential harm.

As I stated in my response to Mr. Cachat above, the example in the article was made very simple so people could understand the differences between the VDA and AIAG 4th Edition DFMEA methodologies.  In the next 24-36 hours I am going to redo the article and replace the Twin Bed DFMEA example with the Throttle Positioner example found in the VDA Volume-4: Product and Process FMEA Manual (2012).  I will clearly demonstrate why Design FMEA methodologies which use the structure, function and failure analysis trees to populate the DFMEA are both ineffective as a risk management tool and very inefficient.  The new article will not be published on Quality Digest.  I will post a shortcut here when it is available.  The article will also be available on our website.

Hopefully, after reading the new article you will understand why I am trying so hard to educate people about the impact the proposed methodology will have on the US automotive industry.

Hello Mr. Harper, I will

Hello Mr. Harper,

I will wait to see your example, but If you think the new handbook is wrong, you should use the commenting sheet in excel provided in the AIAG website to make your proposals.  That is an approach that I have not seen in other publications which more or less dictate what is going to be published. In this new handbook we all have the opportunity to provide opinions and proposals to change the content before it is published. I understand the posted handbook is not the final version to be publised so there is still time to make proposals instead of posting an article with no real evidence that the method is ineffective and very inneficient as you said.

VDA Vs. AIAG Comparison Using VDA Manual Example

In response to comments that the proof presented in the article about the problems with the proposed AIAG-VDA Handbook DFMEA methodology was invalid because of the simplicity of the Twin Bed example provided, I have written another paper which uses the Throttle Positioner example found the 2012 VDA FMEA manual.  This example was used by the VDA to explain how to implement the VDA DFMEA methodology.  Like the first article, the paper will provide proof that the proposed AIAG-VDA Handbook DFMEA method is both less effective and more inefficient than the current AIAG 4th Edition DFMEA methodology. 

The paper can be accessed at: 

https://www.harpcosystems.com/articles/case-against-the-aiag-vda-dfmea

 

Reponse

At the beginning of the article I stated “The group who developed the handbook should be applauded for attempting to develop a standardized method for failure mode and effects analysis (FMEA) to replace the German Association of the Automotive Industry (VDA) and AIAG methodologies, and asking for public comment on the results of their efforts before its release.”  I mean what I said.  None of my comments should be taken personally.  I have an advantage over the committee in that I do not have to achieve consensus amongst multiple people.  I just need to come up with a DFMEA process that creates better designs.

The reason I did not take the Excel comment route is that I wanted to educate as many people as quickly as possible.  There is a very important decision coming up and time is of the essence.  If I had chosen the comment route, I would have just been one comment of many.  It took considerable time and effort to develop the article.  I wanted the article to be simple to understand yet detailed enough so people could see the definite difference between the AIAG 4th Edition DFMEA method and the proposed DFMEA method. 

I also believe exchanges such as the one we are currently having are very important educational tools.  If I had used the comment route, we would not be having this exchange. When teaching, I always tell my students that if I say anything that goes against what they believe that they should challenge me.  Both the student and teacher learn when this happens.

In closing I must admit that I don't understand the comment about no evidence.  I have demonstrated that four VDA DFMEAs will be needed to replace the one AIAG 4th Edition DFMEA.  I have demonstrated that every line of the VDA DFMEAs has one or more issues that make the VDA DFMEAs ineffective as risk management tools.  Are these not proof of ineffectiveness and inefficiency?  Perhaps you could provide a VDA DFMEA example which would refute what I have written.

Hello Mr. Harper, I accept

Hello Mr. Harper,

I accept your challenge, let's do this, please publish your example in the AIAG 4th edition form and I would take your example and change it to the new AIAG/VDA handbook method, I promise I would not use any dedicated software only excel. I will make my example public following the six steps. let me know where to post it, if you want to keep the twin bed example is fine too, or maybe a simplier product that can be understood by all the readers. It will take time and effort I know that for sure but I can demonstrate the advantages of using the method in the new handbook.

Note: I do not work for AIAG or VDA or FMEA software company, I am just an FMEA enthusiastic.

Challenge

The challenge is to create a proper Design FMEA using the structure, function and failure trees used by the AIAG-VDA Handbook.  The problem with the tree method is that it drives you to the wrong entries for the Design FMEA.  If I give you a properly constructed Design FMEA, I have given you the answer.  You could ignore the directions the AIAG-VDA Handbook gives you for the entries in the various trees and just feed the Design FMEA entries to the tree.  The AIAG-VDA Handbook gives clear instructions on the relationships between columns in the DFMEA forms and entries in the various trees.  People need to understand that the trees method is not only inefficient it leads to the wrong answer. 

Based on your comments, you believe a proper Design FMEA can be constructed using the tree based method in the AIAG-VDA Handbook.  Prove it with a product of your choice.  Just make sure the product has sub-assemblies and components.  If you feel more comfortable using the VDA method since it has been arround for 20+ years, feel free to do so. 

If you do not have the ability to post your Design FMEA, send it to my email at richard.harpster@harpcosystems.com and I will set it up so everyone can view it.  Feel free to use whatever software you would like.

By the way, a name would be great.  If you believe in something very strongly and want to promote it, you should want to link your name to it.  I have never been afraid to link my name to anyting I publish or responses to publications.

A VDA approach beneficial in other situations

The example you picked is indeed quite hard to work-out however I think it is a really specific situation which fortunately only applies to a minority of situations.

For these we definitely need a work-around to avoid repeating the same function at each level of the structure tree. Like for example the decision not to propagate a requirement which applies to all sub-components.

This latest handbook stresses that business and timing considerations must be taken into consideration when deciding which actions to perform and as such it is likely that no bed-making organization would spend thousands of hours into defining the specific requirements of a single wooden leg in regards to the 15 k cycles.

I find there are also other situations in which the System Analysis (which was designed by VDA initially and only incorportated in the joint handbook later on) proves to support beneficially the thinking process (especially in projects whose complexity is higher than a bed design).

VDA Vs. AIAG Comparison Using VDA Manual Example

In response to comments that the proof presented in the article about the problems with the proposed AIAG-VDA Handbook DFMEA methodology was invalid because of the simplicity of the Twin Bed example provided, I have written another paper which uses the Throttle Positioner example found the 2012 VDA FMEA manual.  This example was used by the VDA to explain how to implement the VDA DFMEA methodology.  Like the first article, the paper will provide proof that the proposed AIAG-VDA Handbook DFMEA method is both less effective and more inefficient than the current AIAG 4th Edition DFMEA methodology. 

The paper can be accessed at: 

https://www.harpcosystems.com/articles/case-against-the-aiag-vda-dfmea

 

Response

Your following comment is interesting: "This latest handbook stresses that business and timing considerations must be taken into consideration when deciding which actions to perform and as such it is likely that no bed-making organization would spend thousands of hours into defining the specific requirements of a single wooden leg in regards to the 15 k cycles.”

You are making my point for me.  Engineers will not spend the time and effort to develop verifyable functions/requirements for each of the sub-assemblies and components in order to build the Function Analysis as required by the proposed AIAG-VDA Handbook DFMEA methodology.  They will create generic statements.  Even if they wanted to, in many cases they cannot.  For example, how does one translate meeting a resonant frequency requirement or a noise requirement into individual component and sub-assembly requirements?  The answer is you cannot.

Unfortunately, the ineffectiveness and inefficiency of the VDA method increases with the complexity of the product.

AIAG-VDA FMEA Standard - Publication date?

Richard

An interesting discssion - thank you.

Does anybody know when the ne standard will become generally available?

Phil