Archive for June, 2008

FMEA and test Plans

Thursday, June 19th, 2008

Back in the USA and teaching at one of the Japanese automaker’s design facilities in the Detroit Area today. The topic came up as to how the Test plan can be affected by the Design FMEA activity.

My response to the question was as follows:

One of the Design FMEA’s jobs is to determine that the testing and prevention methods are adequate to either prevent a failure mode and cause mechanism from happening, (Prevention affects Occurrence) and to determine if a test or groups of tests will excite a failure mode either directly or through a cause which was deemed probable during the analysis (This is the Detection number) A detection ranking is assigned to each test and the lowest number is placed in the Detection column. Here is where the process goes wrong.

The purpose of the the detection ranking is to give an honest assessment of the tests to determine if they are harsh enough and have the causes which have high Occurrence represented within it. If the test does not consider a cause that has a high Occurrence then the ranking should climb. A ranking greater than 3 (my opinion not to standard) then an action should be considered to improve the test to make it more representative of how the team invisions a failure. The Detection action (with no regard to RPN) is captured and given a timing and responsibility for follow-up. The RPN has nothing to do with determining if a test improvement is necessary.

The RPN is assigned to the action (not the other way around) and the resulting RPN after the action is taken is compared to the original for overall relative risk improvement. In fact the RPN is the only way to tell (numerically) if actions were successful in general. The RPN has each element where actions can be taken so it represents a good overall risk reduction comparison. The key word is comparison. OOOPs getting off topic here. Back to testing.

The test improvements are intended to excite the failure mode with the high occurrence causes present in order to fail the part or system, etc… On the other side the design engineer, knowing a risk exists takes an action to prevent a failure so the two opposing forces are equaled. What do I mean by this? The test guys are trying to fail the part with excitation (within specification limits of course) and the product design guys are trying to prevent the failure by strengthening the area (cause) that was determined to have risk. So try as they might, the test guys will experience a pass not a failure.

Remember we should not learn anything through this test  plan as we are trying to verify that the design is acceptable. The design verification should be confirmed or backed up by the test after having first gained confidence in the design through prevention means (standards, FEA, Best practices and Product DNA) 

FMEA for the Department of Defense

Thursday, June 12th, 2008

It amazes me as to the usefulness of FMEA across many industries. I am sitting in the lobby of a major defense contractor for the second day of a FMEA risk mitigation event for the Hummer replacement. The new designs are intended to reduce the effectiveness of IED’s or Improvised Explosive Devices. The FMEA is being used to reduce the probability of failure of various systems as they contribute to the potential failure. In other words a systems approach. Some systems have greater responsibility to deliver protection and survivability than others, but all are responsible for some of the functional requirement.

The outputs of FMEA in these examples are extracted from the FMEA and managed through a risk management method embedded within the project management system. This is a great way to get the value from FMEA and then populate the Design Reviews with the actions, responsibility and timing. Follow-up is most likely to occur in these cases. This is a major flaw with using FMEA alone as some folks simply forget to review the actions in a timely way.

Always remember to update the FMEA after the actions have been taken as this assures future considerations of the actions taken in new FMEA development.

Design Controls prevention and Detection

Wednesday, June 11th, 2008

Just a note while on the road in New York about prevention and detection controls. Some confusion exists about these two very distinct types of controls.

Prevention controls include things that help you do it right the first time without having to physically test. These include FEA, Modeling technology, Product DNA, and Standards that can be followed. Note that FEA in a iterative design process as opposed to using a the design process. These Type 1 controls affect the Occurrence number and are not to be evaluated for the Detection ranking.

Detection controls or type 2 controls are used to detect design weakness and potential errors. Tests and formal protocols, physical representations of parts, past test results etc… each is rated independantly of each other for each cause and failure mode. the lowest value is used for the detection ranking to be included in the FMEA. More on Process FMEA in my next post

China says yes to FMEA

Tuesday, June 3rd, 2008

Working in China this week. The FMEA process is just starting to take off in China. The concept of FMEA is always somewhat hard to start with. The design engineers here still struggle with the same issues that design communities everywhere else struggle with. Why do this? I am a good design engineer. I won’t make mistakes.

The message here is the same everywhere: The design engineer should never do their own Design FMEA. Think about it. What will they find? And if they find something, why did they not find it before the FMEA? The design engineer should be doing the FMEA in his or her head as the design process progresses. The Design FMEA is done by a team of people including other design personnel that provide the questions and drive for doing a good job. The design engineer responsible for the design is required for two reasons:

1) They are in the best position to know when the FMEA should be performed: roughly 50% of design completion time or earlier.

2) They need to provide the team with the philosophy of the design direction and choices made.

They must never drive the FMEA as the result will follow the the design engineers lead, and that would diminish the value of FMEA for uncovering possible failure modes, their causes and mechanisms and the actions that will be suggested to make the design better.

Your comments are always welcome!