Modules

FMEA allows the analysis of each individual component of the product based on its structure, examining its properties, functions, and operational modes. Based on these, the FMEA itself is carried out. – Functions, modes, and properties are key inputs for further analysis.

In line with the methodology, AyMINE supports the following within the FMEA analysis:

Analysis of individual parts and individual properties (structural analysis)
Functionality analysis (dynamic analysis)
Description of operational modes.

For each element, threats, risks that may arise, and proposed measures are analyzed.

Functions

Functions describe what the product does and how it behaves. A typical function description includes input/trigger, data processing, and output.

For FMEA, the important questions are:

What inputs is the function not prepared for (for example, deviation of input values due to overheating)
How is it ensured that if the function fails, it will not endanger the product or its surroundings (including the user)
How does the product recover if the function fails
All potential problems should be documented during the analysis.

Operational Modes

For each product, all operational modes must be described, including those that may last for a very short time. Typical operational modes include:

Off (whether with no power supply or in standby mode)
Disconnected (actually turned off inputs, for example, due to a failure in the surroundings)
Diagnostic for current startup
Normal operation
Operation in restricted mode
Operation in emergency (safety) mode
Shutdown
...

Modes must be recorded, ideally with a state map or at least a description for each, explaining the circumstances under which the system enters each state. (States can also be directly linked in the system to a state map – this makes sense only if the links are actually used for analysis).

During the analysis, it is important to evaluate:

What product functions are available in a given mode,
What system requirements may arise, and whether the product can handle them in each specific mode. If not, what other consequences may it have
What resources (e.g., power consumption) are needed in that mode and what happens if they are unavailable or stop being available

Properties

Properties include any other features of the product that are important for functional and safety analysis. Typical properties include:

Emissions (e.g., electromagnetic radiation, vibrations, noise, heat)
Changes in size/volume
Durability concerning external conditions (important properties often include lifetime considering temperature, humidity, etc.)

Risk Identification

For each individual function, operational mode, and property, FMEA describes the risks that may arise if a failure occurs, and these risks need to be assessed. The system provides support for defining key parameters for each property (the references describe in more detail the significance of the rating scale):

Each of these values must be defined separately for each parameter – the system automatically pre-fills the values and calculates how "risky" each property is in the product – the so-called rating. This provides a complete overview of what needs to be addressed – to reduce risk.

Definition of Risk Reduction Measures

For risks whose overall rating exceeds the threshold set for the product, measures to reduce them must be defined. The system allows you to define two basic types of measures:

Requirement for the developed product
Safety measures related to the product’s production (and associated controls)

Both types of measures are created directly from the identified property. It is important to create them from the property or link the property with the requirement/procedure to retain the information on how the risk was actually reduced – this way, you can later demonstrate what measures were taken and analyze whether they are appropriate. Conversely, for requirements and procedures, it will be clear why they are necessary.

Step 3: FMEA Report

Once the analysis is complete, the entire FMEA is generated into a report using the FMEA function. The analysis creates a report directly in AyMINE in HTML format – you can then add additional information before exporting it to PDF if needed. This allows you to easily add customer-required information.

Although the generated FMEA analysis is editable, it should not be used for the analysis itself – you would lose alignment with the product documentation.

Don't forget

FMEA Documentation Matters

Thorough FMEA documentation is an essential part of development. You need FMEA analysis not only when designing the product but throughout its entire lifecycle:

When a problem arises that you need to address, for example, with an 8D report, so FMEA is an essential foundation.
When developing a new version of the product, you only need to perform a differential FMEA analysis. Most of the work will be saved, but only if you can prove that you know the original FMEA and – importantly – you understand its conclusions and how they were reflected in the product design.
You will, of course, need it for audits.
If it ever needs to be resolved whether you’ve done everything necessary for the product's reliability, quality FMEA is a key piece of evidence for a responsible approach.

Special Characters of Product Properties

FMEA documentation should cover the important properties of the product, including their impact on safety or cybersecurity of the product itself. For each product property, you can define your own type and characteristics according to the needs of your analysis. Additionally, you can use a set of attributes shared with requirements and procedures. If you use them, they will automatically transfer to the requirements and procedures created based on FMEA – ensuring nothing is lost (as required by standards like ISO 26262, ISO 62061, and others).

RPN vs AP - Understanding FMEA Evaluation

The 2019 standard (FMEA Handbook) advocates using the Action Priority index instead of RPN (Risk Priority Number). Its calculation is different, and so is the output. While RPN is calculated as the product of severity (S), occurrence (O), and detection (D), AP is recalculated from the same values using a table. AP’s calculation is similar to ASIL assessment according to ISO 26262.

The FMEA Handbook explains the reason for the change:
RPN is not an adequate tool for determining what to focus on, as it gives equal weight to all three dimensions (S, O, D). This can give equal weight to two risks with very different S × O products, and the team then doesn't know which to prioritize. The threshold set on the RPN value is insufficient.

In comparison, the fundamental difference between AP and RPN is:

If both S and O are very high, the priority rating will be the highest regardless of D.
If at least one of S or O is very high, the AP will be at least medium-level.
In practice, AP evaluation rules reduce the importance of detection ability in the overall rating.

We believe the reasoning isn't entirely correct, but that's secondary. The practical impact is that AyMINE supports both RPN and AP because:

According to AP, you need to choose what to focus on, as the current FMEA methodology requires this prioritization method.
RPN, in our opinion, provides more accurate comparisons – instead of 3 AP values, it gives 1000 product values, plus it allows the calculation of sum and other statistical analyses, which makes it easier to compare individual components against each other. Based on these comparisons, it's easier to decide what to focus on globally.

## You might be interested in * [Information on how to set up your own property types or characteristics can be found here](/doc/en/sys/sysAdmin). * [We discuss HARA analysis here](/doc/cs/am/amProduct_HARA) and [FMEA in general here](/doc/en/tsk/tskFMEA).