IEC 60812:2018 pdf free download – Failure modes and effects analysis (FMEA and FMECA)
For large or complex systems (e.g. a railway), it might be necessary to sub-divide the systeminto subsystems (e.g. rolling stock,signalling，control room) for each of which an FMEA isperformed.The sub-division may be along physical or functional boundaries,and might beinfluenced by contractual requirements or organizational factors. The sub-division should beselected so that the size of each FMEA is manageable and each FMEA is logically connectedto any others so that the influences of the subsystems on each other,and on the system as awhole are considered. Special attention should be paid to the interfaces between thesubsystems and the boundaries within which they fall should be clearly defined.
5.2.3.2Determine level and approach
An FMEA can be applied at any level of sub-division of an item or process hierarchy (Table 1).The FMEA may be approached in different ways depending on the analysis purpose andstage. Annex A provides guidance and examples.
EXAMPLE During early development stages an FMEA can be applied to the top- or mid-levels in the hierarchyand the causes for the failure modes limited to the failure of the elements in the next lower level(s). In later stagesof development, elements at the lowest level of the hierarchy relevant to the objectives are considered.All failuremodes associated with that element and their effects on the next higher level are identified. The FMEA will,however, always identify the effects of failure modes on the top level of the hierarchy within the analysis scope.
5.2.3.3Define the boundaries of the subject of the analysis
The boundaries, relationships, dependencies and interfaces between the subject of the FMEAand other parts of the system，including human interfaces, should be delineated. Thedefinition of boundaries should include inputs to, and outputs from, the item or process andexplicitly specify which interfaces are within the scope of analysis and which are excluded.
The boundaries depend on the context and might be influenced by factors such as design orintended use. It may be necessary to explicitly place items or process steps outside theboundaries in order to constrain the size of the FMEA or because detailed knowledge of themcannot be obtained.
Where possible, boundaries should be defined to facilitate each FMEA and its integration withother related studies. In some cases, it might be useful to define boundaries from a functionalviewpoint to limit the number of links to other items or processes outside the analysis.This isoften the case if the item or process is functionally complex with multiple interconnectionswithin or across the boundaries.
5.2.3.4 Define use scenarios
When an FMEA is undertaken，it is always in the context of one or more specific usescenarios. Use scenarios to which the FMEA is to be applied should be defined in line withthe objectives of the analysis and described in sufficient detail to facilitate the identification ofall relevant failure modes. The scenarios might include defined states outside specifiednormal use condition.
EXAMPLE Scenarios can be “normal operation”or “storage”when analysing hardware，or ‘night shif”or”emergency response” when analysing a process.
The scenario description normally includes the physical environmental conditions，such asambient conditions in conjunction with conditions created by other items or activities in thevicinity.Other relevant factors include organizational constraints,such as staffing levels,orphysical or psychological stresses that could influence human behaviour.