Recent years have seen many companies working hard to implement a new FMEA standard jointly developed by the two major automotive organizations AIAG and VDA.
As history shows, sooner or later the AIAG & VDA standard will also become commonplace in companies conducting FMEA analysis in other industries.
Basic principles of working with FMEA according to AIAG & VDA
Very simplistically, the basic features of FMEA work according to the AIAG & VDA standard are:
- risk analysis in seven, clearly defined steps,
- a new, extensive form for documenting the analysis,
- using the AP (action priority) indicator to show the need for improvement activities.
Problematic issues in using the standard when conducting SFMEA analyses
In the context of analyses such as DFMEA (design analysis) or PFMEA (process analysis), this new standard and the changes it introduces seem to be a very good thing – especially as I adapt it further to the specifics of a particular company.
However, in the context of SFMEA (software FMEA) analysis, also called SwFMEA, a major problem arises. It stems from how the AP index is determined. A specially developed table is used for this, which assigns an adequate AP value for any SEV (severity), OCC (occurrence) and DET (detection) values: H – high, M – medium, L – low. The values of H, M, L “show” how desirable improvement activities are for the problem under consideration. An excerpt from such a table is shown in Picture 1.
Pic.1. Excerpt from AP table Source: own study
According to the AIAG & VDA standard, in the case of AP = H and AP = M, improvement actions should be implemented, and only AP = L signals a “safe” situation that does not require our interaction.
This way of “pricing” risk is a significant change, compared to previous indicators such as:
- RPN = SEV*OCC*DET,
- ARPN = SEV + OCC + DET.
Also, it’s not that we don’t currently calculate the product or sum, or that we don’t currently have a number (e.g., RPN = 120), but a symbol (H/M/L).
The problem lies in the “logic” of determining the new indicator.
In the case of RPN or ARPN, each component (SEV, OCC, DET) was equally “important.” One could just as well reduce risk by improving prevention (lowering OCC) as by improving controls (improving DET).
In the case of AP, the situation is very different. As you can see in the table – if SEV = 9 – 10, and OCC = 7 – 10, then no control allows us to “go down” from level H. In the case of, for example, PFMEA, this is not a problem, but rather a motivation to address process improvement by reducing the occurrence of the cause of the failure (lowering the OCC by preventive actions, e.g. in terms of TPM, improving operator competence or implementing poka-yoke).
When doing an SFMEA analysis, it is not that simple anymore. Well, one of the “types” of SFMEA analysis is the assessment of software in terms of usability (viewpoint – usability). This type of analysis checks how the program “reacts” to user mistakes. Obviously, programmers usually have no influence on how often a user makes a mistake. They can introduce solutions that detect incorrect use and even block the system to prevent severe consequences. However, this is a procedure that develops control, i.e. detecting the cause of a system failure, which allows for minimizing the DET indicator. However, the AP indicator “underestimates” such solutions, remaining at levels H or M.
How to properly perform SFMEA analysis according to the AIAG & VDA standard?
Companies that have programming departments and want to comprehensively implement the new AIAG & VDA standard thus have a serious dilemma. They are left with three choices:
- Introduce a company-wide uniform standard for determining AP and accept that programmers will often have H or M.
- Use alternative risk indicators for software and SFMEA analysis.
- Encouraged by the example with the SAE standard, make changes to the AP table layout so that control activities are more “appreciated.”
Summary
The choice of a particular solution will ultimately depend, of course, on the specifics of the company and the competence of the facilitators. As always, it is worth keeping pragmatism above all in mind here – may SFMEA not become a burden, but a tool for real software improvement.
Related sources: 1. AIAG & VDA FMEA Handbook, ed.1, 2019
Leave A Comment
You must be logged in to post a comment.