If you have performed a Design FMEA, you might be familiar with the terms “Current Prevention Controls” and “Current Detection Controls” that is used in the template. FMEA is typically performed as per AIAG-VDA FMEA standard. This standard defines the meaning and purpose of these terms. FMEA is performed for both Design and Processes. Design FMEAs are performed for the Product, System, HW or SW.
In the parallel Functional Safety world, similar cousin terms ‘Prevention Measures’ and ‘Detection Measures’ are commonly used. However, there is no fixed definition to these terms in ISO26262 (i.e., you wouldn’t be able to find these terms defined in Part-1). The terms are much more understood logically in the context of functional safety.
The goal of this article is to help the reader understand what these terms in these two worlds mean. The article will also explain how the AIAG VDA FMEA standard has bridged the functional safety gap in its 2019 edition.
“Current Prevention Controls” and “Current Detection Controls” in Design FMEA
In a Design FMEA activity, a bottom-up analysis of the functions of a product is done. The activity roughly proceeds as follows:
- The different failure modes of every function are identified
- The associated effects and causes for that failure are determined.
- The Severity (S), Occurrence (O) and Detection (D) of every effect/cause is determined
- An RPN (Risk Priority Number) is specified for every failure mode.
- RPN = Severity (S) X Occurrence (O) X Detection (D)
- Current (i.e., existing) prevention and detection controls are specified
- Based on 3 and 4, it is decided if the existing measures are sufficient to mitigate the failures or if further ‘new’ actions need to be taken, i.e., new actions to include additional prevention or detection controls.
Now, let's look at the definition of Current Prevention Controls.
Let us look at some examples.
Now, let's look at the definition of Current Detection Controls.
Let us look at some examples.
The key thing is that the ‘current prevention controls’ does not let the problem to occur or reduces its occurrence sufficiently. But despite that, if it did occur, the ‘current detection controls’ finds the problem. At the end, the design or process in scope has its failures mitigated sufficiently even before the item is produced. This is illustrated in the picture below. What means “sufficiently mitigated” must be defined for that specific design or process.
“Prevention Measures” and “Detection Measures” in ISO26262
As stated above, these terms are not defined in ISO26262, but this is the way in which we have logically understood these terms. There can be a different interpretation by another Functional Safety Engineer.
Let us look at some examples.
Comparison between FMEA and ISO26262
Let’s look at all the terms together.
While there is some overlap between ‘Current Prevention controls’ and ‘Prevention Measures’, this is not the case for ‘Detection’. While Design FMEA’s “Current Detection controls” talks about detection measures before production, Functional Safety brings in the concept of ‘Safety Mechanisms’ that detect faults at run time (i.e., after production and during operation) and ensure the system goes to safe state or mitigates the fault in some other way.
Conclusion
To respect the context of functional safety and harmonize Design FMEA and ISO26262, the AIAG VDA introduced the FMEA-MSR (FMEA for Monitoring and System Response) in 2019. The FMEA-MSR is a supplementary FMEA that may be performed for a complex program with Safety requirements or Regulatory requirements. It is mainly focussed on whether the failures of the System can be detected at run time through monitoring (i.e., diagnostic mechanisms). It brings in the aspect of what would be the safe state/state reached if a failure is detected and whether the mechanism will reach the safe state within FTTI.
FMEA-MSR extends much beyond safety, but for the scope of this article, we are restricting it to only safety. Our intent is to introduce FMEA-MSR to readers who are not aware of it, and this article does down deep dive into how it must be done.
Like the concept of ‘RPN’ in design FMEA that is used to determine which failures to mitigate, the FMEA-MSR brings in a concept called ‘Action priority’ that can be used to determine when to implement or bring in additional diagnostic mechanisms and when to skip them. Action priority allows for the prioritization of the need for Action considering Severity, Frequency of occurrence of failure causes and ability of the Monitoring mechanism to detect the fault and react/move to safe state. Unlike RPN where equal weightage is given to severity, occurrence and detection, Action priority gives highest priority to Severity, then to frequency and then to the ability of the Monitoring mechanism.
As a result of the FMEA-MSR, the DFMEA also needs to be modified to evaluate the correct implementation of the Diagnostic mechanism. For e.g.,
- “Current prevention controls” could be modified to evaluate the reliability of the diagnostic mechanism to detect the fault and react on time.
- “Current detection controls” could be modified to consider tests to verify the correct implementation and effectiveness of the diagnostic mechanism.
If you are working on an ASIL program, we recommend you have a discussion upfront on whether FMEA-MSR methodology should be followed for the safety analysis of the program. If you have already implemented FMEA-MSR in your program, please do share the learnings you gained from your experience.