What is an FMEA?
FMEA stands for Failure Mode and Effects Analysis. During development, an FMEA ensures that the reliability of the product is acceptable. As a systems engineer, the FMEA is part of our toolbox. I will describe exactly how it works below.
What is acceptable reliability?
When it comes to Security If it is a question of reliability, the legislator usually specifies what constitutes acceptable reliability. However, this must then also be proven and the FMEA is a tool for making qualitative statements about this. Of course, there are also other techniques.
In addition to the legislator, some customers themselves have reliability requirements that may go beyond the legal requirements. Even without legal requirements, an FMEA can make sense, but the costs usually have to be justified. Satellites are a good example. Here, the operator has a high interest in reliability.
Minimal FMEA
An FMEA is typically presented as a table. From left to right, we read a "Failure Mode" and its effect in each row. There are Numerous variants of the FMEA sometimes with alternative names, such as DFMEA or PFMEA. However, even the simple FMEA often consists of many columns to record the relevant information. Below I show a minimal example of a system in which there is a cooling circuit.
| Type of failure | Cause | Effect | Severity |
|---|---|---|---|
| Pump stops | Power failure | Overheating | Medium (3) |
One type of failure is when the pump stops. This could be caused by a power failure, for example. If the pump stops, the system overheats, but not immediately. Therefore, the severity was classified as "medium". The value (3) quantifies the severity on a scale from e.g. Slight (1) to Fatal (5). This can be used later for calculations (see "Assessing risks").
Any creative engineer could now immediately expand this table: Are there other causes besides a power failure? Are there other effects, e.g. in other operating phases? Another "failure" of the pump could be the pump running at the wrong time. And finally: We have only looked at the pump. What about the other system components that can fail? Even for a moderately sized system, dozens of lines can quickly accumulate here.
More metadata
In practice, the table shown is hardly usable, we need more metadata. Typical additional columns are
- Component - Which component does the analysis refer to? In the example shown, this would be the pump.
- Probability - How often do we expect this type of failure? This can also be linked to a numerical scale (1-5).
- Effect differentiation - It can be useful to differentiate here. In the example: The local effect is initially the stopping of the coolant flow. The global effect is overheating
- Detection - How easy is it to determine this type of failure? A numerical scale (1-5) can also be useful here.
Assess risks
The metadata that evaluates the effect can be quantified. This is often done by simply assigning a number to each value, as we have already shown above. A simple method of evaluation is to multiply the values associated with scales, i.e. severity times probability times detection. Many requirements management tools can also calculate this automatically. Here is a screenshot from Jama Connect:
Mitigating risks
The aim of the exercise is to build a reliable system. One requirement could be to set a maximum value for the Risk Priority Number. If the value is too high, we have to mitigate the risk. In concrete terms, this means that additional columns are added to the FMEA. As a rule, the mitigation is recorded in the form of requirements. In the example of the pump, the following could be added as a mitigating requirement: "The system must switch off automatically in the event of overheating". Whether this requirement is appropriate is another question.
Typically, the Risk Priority Number is recalculated after mitigation to ensure that the mitigation is sufficient.
FMEA is hard work
As mentioned at the beginning, this description contains many simplifications. An FMEA analysis from practice can quickly have dozens of columns and hundreds of rows. The analysis is not difficult, it is actually just hard work.
This makes it all the more important to set up the working environment correctly. An FMEA can easily be implemented in Excel. However, I assume that developments that require an FMEA are documented in a proper requirements management tool. And in this case, I would strongly recommend managing the FMEA in the same tool.
FMEA in the requirements management tool
In the screenshot above, each line of the FMEA represents a separate element of the "Risk" type. This means that Jama versions each line of the FMEA. Furthermore, we can use the traceability of Jama. This means that the mitigation is not part of the FMEA, but a separate requirement. This gives us traceability between the risk and the mitigating requirements. If the risk changes, Jama automatically marks the linked requirements as "suspect". We can also create and maintain traceability from component to risk.
I suspect that other tools provide similar mechanisms. Precisely because it is about security, we should avoid separate data storage (Excel) wherever possible.
Photo by Damian Zaleski on Unsplash
