FMEA system support

AyMINE supports complete process and maintenance of the FMEA analysis. It supports both the process management as well as documentation creation and report generation.

• Process support
• Technical support
  • Principal FMEA object
  • Feature
  • Feature cause
• FMEA report generation
• FMEA Implementation notes

Support conforms the FMEA Handbook valid since year 2019.

Process support

Process support is completely based on the methodology management. FMEA processes are defined by methodology as three similar processes. The FMEA process part does not have any special implementation.

Technical support

Principal FMEA object

Technically FMEA is linked with product or analytical documentation.

When linked with product from product database, it can be more easily reused. When the same particle became a part of another product, its FMEA analysis of the particle automatically becomes part of the FMEA analysis of a new product.

However, linkage of the FMEA with the analytical documentation is more convenient, because the analysis is mostly made before product is completely described.

Process FMEA is always linked with the process definition

MSR-FMEA could be based both on the final product description as well as on the proposed product analytical documentation.

All cases are described by the following scheme

Link to the picture

Feature

Feature describes some element of functionality that is deeply analysed during the FMEA. Feature is an abstract object that has 3 descendants:

• Functionality – functional objects – support for functional analysis
• Operational status
• Property
  All 3 feature descendants have technically the same behaviour.

A feature typically specifies which type of analysis (DFMEA, PFMEA, MSR-FMEA, FTA or other model) is being examined.

Feature cause

Feature cause describes each single possibility of failure. For each failure that are fields for thread and precaution as well as for S/O/D analysis.

FMEA report generation

Report is generated from the analysed item and all particles. Single FMEA report includes only those feature cause, that are relevant for selected type of analysis.

FMEA report notes:

• Product item might contain single particle several times. In that case the particle analysis is included only once in the report. However, remember the failure might affect the parent object. Therefore, analysis for the particle failure impact to the super-part should be an analysis of that super-part.
• FMEA report calculates AP and RPN values slightly differently than the views in application: Whilst views leave non-filled S/O/D values undefined, report set them 10. Both makes sense:
  • Empty value shall remind that the evaluation is not complete
  • Default value 10 set the value to the most danger level and so not-properly-analysed failure won’t be overlooked.
• Report shall include also data about the process – not only the analysis result (the report content is predefined by the FMEA Handbook). That’s why the report generation should always be linked the analysis process
• Report is generated with support to paste it to the formal template in the Libre Writer or some similar application. User might get it required look-and-fell if necessary.

FMEA Implementation notes

Notes for system development

AP (Action Priority) calculation is calculated differently for D/P FMEA and for MSR FMEA. AP is defined independently for them by the FMEA Handbook. That’s why the value could change when the type of the FMEA analysis changes

AP is calculated both by server and client. It makes calculation faster and utilise better computational resources. Remember on that in case of change that update should be made twice.

Technically FMEA implementation is part of the am module because that is based on the amAbstractAssetType object. The process description uses the methodology from the tsk module.