the advice suite the advice suite
site map the advice suite sentient systems ltd
Advice Suite > FMECA Advice > FMECA - What? Where? Why? When?
 
Reliability Advice
FMECA Advice
Requirements Management Advice
What is FMECA?
FMECA - What? Where? Why? When?
Contents
    What is FMECA?
    Where is FMECA used?
    Why do we do FMECA?
    When should FMECA be implemented?


What is FMECA?
FMECA is a well established method for identifying all possible failures within a system, the possible effects of these failures and any potential consequences. By ranking these potential problems in terms of ‘Severity’ and ‘Criticality’, the FMECA process can be used to identify and focus attention on areas of greatest concern within a design.




Where is FMECA used?
FMECA is used to support a number of different engineering activities. These include:

  • Reliability Analyses – The FMECA should identify areas of greatest concern from a logistic and / or safety viewpoint. Such areas should then be targeted for possible design changes which may for instance improve reliability.
  • Maintainability Analyses – The FMECA often records and / or highlights areas of the design which require some form of scheduled maintenance activity.
  • Testability Analyses – FMECA often includes a detailed analysis of detection methods including any Built In Test (BIT).
  • Safety Analyses – failure mode criticality results will often feed into the Fault Tree Analyses.




Why do we do FMECA?
A FMECA provides a method of identification and assessment of potential design weaknesses. A well implemented FMECA provides a form of impartial design review and can be used to highlight areas which should be considered for design change or support process change. The FMECA should provide the following analyses:

  • Functional Assessment – The FMECA process normally requires a good understanding of the basic system design. Although functional design errors are not always included in the FMECA report, the process of FMECA will often highlight any functional errors which can be referred back to the design engineers.
  • Highlight Critical design areas – The FMECA should highlight areas of the design which are of particular concern from a logistic and safety viewpoint. Once these areas are highlighted, a decision can be made regarding any changes to make the design more robust. Such changes may be in terms of a redesign (e.g. additional redundancy) or perhaps scheduled maintenance.
  • Assess Failure Detection – The FMECA can be used as part of a Testability Analysis and may be used to identify areas of the design which have inadequate detection coverage.




When should FMECA be implemented?
In order to be effective, the purpose and scope of the FMECA needs to be well defined, and implemented at the correct stage in the life cycle. If the FMECA process is implemented too early, there may not be enough information available to produce a meaningful analysis. If the FMECA process is implemented too late, any resultant design changes will be at a much greater cost in terms of time and money. The first option involves a higher level ‘Functional FMECA’ and the second involves a more detailed, low level, ‘Component FMECA’. These two terms are further described in the following two paragraphs:

  • Functional FMECA: If detailed design information is unavailable, it is still possible to carry out FMECA on a functional basis. In order to produce this type of FMECA, a set of Functional Block Diagrams (FBDs) is normally produced which identifies appropriate signals and / or functions. A functional FMECA can provide early feedback on potential design problems. A typical Functional FMECA will often have the following characteristics:
    • No completed designs required.

    • Good potential for influencing design.

    • Can only provide an analysis at a relatively high level.

  • Component Level FMECA: This type of FMECA can be produced later in the design process and is able to provide a detailed analysis of the design from a ‘failures’ point of view. A typical Component Level FMECA will often have the following characteristics:
    • As a minimum, preliminary software / hardware designs are required.
    • Design changes identified at this stage are likely to be costly.
    • Low level analysis which can impact and support a number of subsequent analyses.




©Sentient Systems Ltd 2004. All rights reserved.