Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TugboatEng on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
Risk Analysis 1
- Thread starter GregPerry
- Start date
Guest
Mr. Greg,
Risk is very specific and depends on the condition and type of the Equipment and its interfaces like Operator, Working environments. I may have some details which could help you in the Risk Assessments. If you need more informations, Please contact me with specific Equipment details and its conditions, Operating environments and training details/PPE etc. currently in use.
Regards,
VCMoncee
Risk is very specific and depends on the condition and type of the Equipment and its interfaces like Operator, Working environments. I may have some details which could help you in the Risk Assessments. If you need more informations, Please contact me with specific Equipment details and its conditions, Operating environments and training details/PPE etc. currently in use.
Regards,
VCMoncee
GregLocock
Automotive
In the aeronautical and automotive worlds we'd call that an FMEA (Failure Modes and Effects Analysis). This was developed by NASA in the sixties (I guess) and is a core part of most systems engineering analyses. It's pretty easy to understand, although it can raise very hairy problems, which is good, I guess.
I don't know how much luck you'd have with web hits, it might be better to get a book.
Cheers
Greg Locock
I don't know how much luck you'd have with web hits, it might be better to get a book.
Cheers
Greg Locock
I agree with Greg on the use of FMEA. A couple of resources that may guide you in the evaluation of the probabilities of failure are:
NPRD-95 data provides failure rates for a wide variety of items, including mechanical and electromechanical parts and assemblies. The document provides detailed failure rate data on over 25,000 parts for numerous part categories grouped by environment and quality level. Because the data does not include time-to-failure, the document is forced to report average failure rates to account for both defects and wearout. Cumulatively, the database represents approximately 2.5 trillion part hours and 387,000 failures accumulated from the early 1970's through 1994. The environments addressed include the same ones covered by MIL-HDBK-217; however, data is often very limited for some environments and specific part types. For these cases, it then becomes necessary to use the "rolled up" estimates provided, which make use of all data available for a broader class of parts and environments. Although the data book approach is generally thought to be less desirable, it remains an economical means of estimating "ballpark" reliability for mechanical components.
NSWC-94/L07 - Handbook of Reliability Prediction Procedures for Mechanical Equipment. This handbook, developed by the Naval Surface Warfare Center – Carderock Division provides failure rate models for fundamental classes of mechanical components. Examples of the specific mechanical devices addressed by the document include belts, springs, bearings, seals, brakes, slider-crank mechanisms, and clutches. Failure rate models include factors that are known to impact the reliability of the components. For example, the most common failure modes for springs are fracture due to fatigue and excessive load stress relaxation. The reliability of a spring will therefore depend on the material, design characteristics and the operating environment. NSWC-94/L07 models attempt to predict spring reliability based on these input characteristics. The drawback of the approach is that, like the physics of failure models for electronics, the models require a significant amount of detailed input data (e.g., material properties, applied forces, etc.) that is often not readily available. They also do not address the issue of manufacturing defects.
NPRD-95 data provides failure rates for a wide variety of items, including mechanical and electromechanical parts and assemblies. The document provides detailed failure rate data on over 25,000 parts for numerous part categories grouped by environment and quality level. Because the data does not include time-to-failure, the document is forced to report average failure rates to account for both defects and wearout. Cumulatively, the database represents approximately 2.5 trillion part hours and 387,000 failures accumulated from the early 1970's through 1994. The environments addressed include the same ones covered by MIL-HDBK-217; however, data is often very limited for some environments and specific part types. For these cases, it then becomes necessary to use the "rolled up" estimates provided, which make use of all data available for a broader class of parts and environments. Although the data book approach is generally thought to be less desirable, it remains an economical means of estimating "ballpark" reliability for mechanical components.
NSWC-94/L07 - Handbook of Reliability Prediction Procedures for Mechanical Equipment. This handbook, developed by the Naval Surface Warfare Center – Carderock Division provides failure rate models for fundamental classes of mechanical components. Examples of the specific mechanical devices addressed by the document include belts, springs, bearings, seals, brakes, slider-crank mechanisms, and clutches. Failure rate models include factors that are known to impact the reliability of the components. For example, the most common failure modes for springs are fracture due to fatigue and excessive load stress relaxation. The reliability of a spring will therefore depend on the material, design characteristics and the operating environment. NSWC-94/L07 models attempt to predict spring reliability based on these input characteristics. The drawback of the approach is that, like the physics of failure models for electronics, the models require a significant amount of detailed input data (e.g., material properties, applied forces, etc.) that is often not readily available. They also do not address the issue of manufacturing defects.
- Thread starter
- #5
-
1
- #6
McLeod
Mechanical
- Jan 22, 2002
- 70
The form of the FMEA is not as important as the exercise of creating and maintaining it diligently, but those that I've completed or reviewed in the medical device industry have all had the same general elements. Typically, each row of the matrix relates to a particular failure or hazard (e.g. "biological contamination"
which is described in one of the columns. The effect/consequence of the hazard is described in another column (e.g. "patient infection", and receives some rating or ranking of the effect in terms of severity. The cause(s) of the failure (e.g. "ineffective sterilization process" is described in another column, and receives a probability rating for the occurrence of the failure. The method(s) of prevention or detection is described in another column (e.g. "sterilization validation and periodic audits; certification of sterilization dose", and receives a rating for the probability that the failure will be prevented or detected.
Note that many failures have several potential causes (modes) and each should be described and rated separately along with the specific mitigation methods.
The rankings are typically used in some calculation to come up with an overall criticality rating for each failure mode, which helps prioritize the mitigation activities. I've always taken the product of the probabilities and the severity weighting factor, and compared them to a list of ranges which indicate general criticality levels. The numeric portion of the FMEA is where most meetings for these documents degenerate into debate. Don't get too wrapped up in this - most ratings can reasonably be argued up or down one level, and it's all just a guess unless you have copious data behind your rating system. The important thing is to conduct the exercise with diligence and honestly identify failure modes.
The final and most important portion of the FMEA is the description of project activities which mitigate the failure modes. It's bad if the team fails to identify a significant risk; it's worse if they identify a significant risk and fail to do anything about it. It's the difference between incompetence and negligence.
The FMEA should be generated by team members from all primary disciplines, and treated iteratively as a living document. It should be created as soon as the product or process specification has been documented, and criticality levels will typically be high. As the project goes on and mitigation activities are completed, the document reviews should reflect this by lowering the probability ratings. If a change is made to the product or process, the FMEA should be consulted and updated as necessary - new failure modes may result from the change.
Another common pitfall of the FMEA process is incorrect identification of the failure mode, effect, or cause. For any given failure there is a chain of cause-effect. Stay centered on the failure mode of the product or process, and don't drift into upstream causes (e.g. "assembler doesn't follow cleanroom procedure" or downstream effects (e.g. "patient is hospitalized".
Overall, the FMEA has consistently been one of the most useful and valuable documents in the projects that I've managed or supported, second only to the product specification itself.
which is described in one of the columns. The effect/consequence of the hazard is described in another column (e.g. "patient infection", and receives some rating or ranking of the effect in terms of severity. The cause(s) of the failure (e.g. "ineffective sterilization process" is described in another column, and receives a probability rating for the occurrence of the failure. The method(s) of prevention or detection is described in another column (e.g. "sterilization validation and periodic audits; certification of sterilization dose", and receives a rating for the probability that the failure will be prevented or detected.Note that many failures have several potential causes (modes) and each should be described and rated separately along with the specific mitigation methods.
The rankings are typically used in some calculation to come up with an overall criticality rating for each failure mode, which helps prioritize the mitigation activities. I've always taken the product of the probabilities and the severity weighting factor, and compared them to a list of ranges which indicate general criticality levels. The numeric portion of the FMEA is where most meetings for these documents degenerate into debate. Don't get too wrapped up in this - most ratings can reasonably be argued up or down one level, and it's all just a guess unless you have copious data behind your rating system. The important thing is to conduct the exercise with diligence and honestly identify failure modes.
The final and most important portion of the FMEA is the description of project activities which mitigate the failure modes. It's bad if the team fails to identify a significant risk; it's worse if they identify a significant risk and fail to do anything about it. It's the difference between incompetence and negligence.
The FMEA should be generated by team members from all primary disciplines, and treated iteratively as a living document. It should be created as soon as the product or process specification has been documented, and criticality levels will typically be high. As the project goes on and mitigation activities are completed, the document reviews should reflect this by lowering the probability ratings. If a change is made to the product or process, the FMEA should be consulted and updated as necessary - new failure modes may result from the change.
Another common pitfall of the FMEA process is incorrect identification of the failure mode, effect, or cause. For any given failure there is a chain of cause-effect. Stay centered on the failure mode of the product or process, and don't drift into upstream causes (e.g. "assembler doesn't follow cleanroom procedure"
or downstream effects (e.g. "patient is hospitalized".Overall, the FMEA has consistently been one of the most useful and valuable documents in the projects that I've managed or supported, second only to the product specification itself.
QualityBob
Automotive
Greg,
You might find this software tool for FMEA's to be very useful. It guides our teams through the process using a spreadheet layout and valuable data libraries. We picked up a couple of copies from the SAE International.
QualityBob
You might find this software tool for FMEA's to be very useful. It guides our teams through the process using a spreadheet layout and valuable data libraries. We picked up a couple of copies from the SAE International.
QualityBob
The commercial nuclear industry was heavily into reliability and risk studies focusing around "Probabalistic Risk Analysis" (PRA) within the last two decades. Most of the reports were listed in abstracting publications like Government Reports Announcements and Index (GRA&I) and Atomindex which you may be able to find in a good technical library. The were issued in hardcopy form up until 1999 when they went to CD subscriptions. I have some PRA microfiche reports in my files but I'll have to look them up to give you document ordering numbers from National Technical Information Service (NTIS).
In the realm of statistical analysis of failure risks, much work was done by General Electric Research Lab in the 1960-1980 timeframe dealing with "Hazard Functions" and the like. Nelson and Hahn were the leaders of a corps of statisticians and I believe that Nelson published a book covering most of this territory. Again I need to consult my library on specific references. vanstoja
In the realm of statistical analysis of failure risks, much work was done by General Electric Research Lab in the 1960-1980 timeframe dealing with "Hazard Functions" and the like. Nelson and Hahn were the leaders of a corps of statisticians and I believe that Nelson published a book covering most of this territory. Again I need to consult my library on specific references. vanstoja
- Status
Similar threads
- Locked
- Question
- Locked
- Question