User Modules

Product FMEA allows you to analyze, based on the structure of the product, what each individual component of the product has features, functions and operating modes. Based on these, you can then perform the FMEA itself. - Functions, modes and features are a key input for further analysis

Step 1: Breakdown into parts

Within Product description there are 3 lines of separate breakdown:

Breakdown into parts of the product - what it consists of. The description is immediately on the product homepage
Analytical documentation of a specific part. Each individual part can be described by analytical documents describing the technical structure. This is a technical analysis that typically only arises after the FMEA analysis in the next step. It is therefore not the basis for FMEA
Specific variants product - bookmark Specific Products We present it for order, it is not a description of the product as such, but an option to describe the different variants - e.g. a version of an OEM product for different end manufacturers. Specific products typically inherit a large part of the properties and thus the FMEA analysis. For a specific product, a differential FMEA is subsequently done.

Step 2: Analyze each part separately

Remember:_ Without a quality description of the properties, FMEA is not possible. If you don't have a quality description, no one (and therefore no audit) will approve the product as safe.

Function

Functions describe what a product does and how it behaves. The typical description of a function is input/stimulus, data processing and output.

From the FMEA perspective, the following questions are important:

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

Operational modes

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

Off (whether no power supply or in stand-by mode)
Disconnected (actually switched off all inputs, e.g. due to a fault in the vicinity)
Diagnostics for starting the current
Normal operation
Operation in restricted mode
Operation in safety mode
Shutdown
...

Modes must be recorded, optimally there should also be a status map or at least for each a description of what state and under what circumstances the system will get into that state. (The states can also be linked directly in the system to the status map - but this only makes sense if you actually use the links for analysis).

It is important to evaluate as part of the analysis

What product features are available in the given mode
What system requirements may be coming in and whether the product will be able to service them in each particular mode. If not, what may be the other connection
What resources (e.g. power consumption) are needed in the given mode and what will happen if it is not/is no longer available

Properties

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

Emissions (e.g. elmg. radiation, vibration, noise, heat)
Size/volume changes
Durability with respect to external conditions (the important feature typically is durability with respect to temperature, humidity, etc.)

Risk and measures search

For each individual feature, operating mode and feature, the FMEA describes the risks if a failure occurs and those risks need to be evaluated. The system provides support to identify key variables for each feature (links describe in more detail the meaning of the rating scale)

Each of the values needs to be set separately for each variable - the system automatically prefills the values and calculates how each property is in the product of "risk" - the so-called rating. It gives you a complete overview of what needs to be done - to reduce risk.

Definition of measures to reduce risk

For risks whose overall rating exceeds the limit set for the product, measures need to be set, not reduced. The system makes it possible to directly define 2 basic types of measures

Requirement for developed product
Safety measures related to product manufacture (and related controls)

You create both types of measures directly from the identified property. It is important to create them from a property or link a property to a requirement/procedure in order to retain information on what really reduced the risk - this allows you to additionally document what measures have been taken and analyse whether they are adequate. On the contrary, for requirements and procedures it will be obvious why they are needed.

Step 3: FMEA Report

When you have the analysis done, the entire FMEA is generated into the report by the FMEA function. The analysis creates the report directly in AyMINE in HTML form - you have the possibility to add additional information before exporting it to PDF. You can thus easily add the information requested by the customer.

Although the generated FMEA analysis is in principle editable, it should not be used for the analysis itself - you would lose the match with the documentation of the product itself.

Remember

FMEA documentation matters

Thorough FMEA documentation is an essential part of. You need FMEA analysis not only when inventing a product, but throughout its entire life cycle:

When there is a problem that you will solve e.g. 8D report, so FMEA is an essential foundation
When you develop a new version of a product, all you need to do is differential FMEA analysis. You will save most of the work, but only if you can prove that you know the original FMEA and - and this is important - you also know its conclusions and how they were reflected in the product design.
Of course, you will need it for the audit
If there is ever a need to address whether you have done what was necessary for the reliability of the product, quality FMEA is a key proof of a responsible approach.

Special features of a product

FMEA documentation should cover important features of a product, which definitely include the influence of the feature on the safety or cybersecurity of the production itself.
For each feature of a product, you can define your own type and symptoms according to the needs of your analysis. In addition, you can use a set of symptoms that are shared with the requirements and workflows. If you use these, they will automatically transfer to the requirements and procedures created by FMEA – making sure they are not lost anywhere (standards like ISO26262, ISO62061 and others require this).

Notes

Standard methodologies in AyMINE use symptoms shared with the requirements for "safety" attributes – indicating that a feature affects:

Security
Cybersecurity
Overall reliability
They are required by legislation

##You Might Be Interested In