Hardware FMEA

The probably more common and more useful type is the hardware FMEA, which requires detailed design information and concentrates on assemblies, subassemblies, and components. 

The scope is easily defined if an analytical tree is used as a feeder document (Chapter 10). The indenture levels can be identified by specifying the number of tiers of the tree to be included in the analysis (limits of resolution). A functional FMEA includes upper and/or middle tiers only a hardware FMEA includes the entire tree. 

The functional FMEA tends to use deductive logic, that is, to ask what the cause may be and to focus on the functional failure modes and their causes. It can be used early in the program and is usually done at the subsystem or assembly level. The hardware FMEA tends to be more inductive, asking what ir and when questions, in that common component failure modes are listed and then the focus of the analysis is on the effects of each failure mode. It needs fixed design data and goes to the component level. 

From the analytical tree (and/or other input documents), prepare a systematic breakdown of the system to the specified level of detail (generally subsystem or assembly level for a functional FMEA and component level for a hardware FMEA). 

Column 1—Component Description. Enter the component description (narrative description and part number, if applicable). Note that this particular form was designed for a hardware FMEA. If a functional FMEA is being performed with this form, the component may be a subsystem, assembly, or subassembly. For some projects, breaking this column into two or three separate columns may be desirable. For example, if specific part numbers are assigned to all or most components and/or if separate item numbers are desired, a separate column (usually added as the first column with the component description becoming the second column) may be added just for item or part numbers. If the function of the component is not apparent or cannot... 

The functional FMEA targets any subsystems that may exist within an entire system. The functional FMEA will evaluate each subsystem and attempt to identify the effect of any failures in these subsystems. The analyst not only looks for the possible effects of subsystem failures on the system as a whole but also examines the effect of such failures on other subsystems within the system. Although functional FMEAs are not as common as the hardware FMEA, their basic utility should not be dismissed. When a complex system (such as a nuclear reactor, an airliner, an overhead bridge crane, or a new robotic milling machine) consists of numerous secondary subsystems, each with its own set of supporting subsystems, the functional FMEA should be performed to ensure proper system safety evaluation at every level. 

The second and more common hardware FMEA examines actual system assemblies, subassemblies, individual components, and other related system hardware. This analysis should also be performed at the earliest possible phase in the product or system life cycle. Just as subsystems can fail with potentially disastrous effects, so can the individual hardware and components that make up those subsystems. As with the functional FMEA, the hardware FMEA evaluates the reliability of the system design. It attempts to identify single-point failures, as well as all other potential failures, within a system that could possibly result in failure of that system. Because the FMEA can accurately identify critical failure items within a system, it can also be useful in the development of the preliminary hazard analysis and the operating and support hazard analysis (Stephenson 1991). It should be noted that FMEA use in the development of the O SHA might be somewhat limited, depending on the system, because the FMEA does not typically consider the ergonomic element. Other possible disadvantages of the FMEA include its purposefiil omission of multiple-failure analysis within a system, as well as its failure to evaluate any operational interface. Also, in order to properly quantify the results, a FMEA requires consideration and evaluation of any known component failure rates and/or other similar data. These data often prove difficult to locate, obtain, and verify (Stephenson 1991). 

This example will develop a hardware FMEA for a proposed system that is well into the design phase of the product life cycle. For informational purposes, it is assumed that a preliminary hazard analysis was previously performed during the early stages of the design phase of this system. The information from the PHA will be used to assist in the development of the hardware FMEA. It should also be noted that the nature of a FMEA requires evaluation of subsystems, subassemblies, and/or components. For this reason, more detailed and specific descriptive information is provided here than that supplied for previous examples discussed in this text. 

There are three types of FMEA/FMECA functional FMEA/FMECA, DFMEA/ DFMECA, and PFMEA/PFMECA. Apart from these there are two other types of FMEA service FMEA and SWFMEA. In service FMEA the focus is on service issues. SWFMEA (discussed separately in later clauses) focuses on software issues. Functional FMEA/FMECA is also known as concept FMEA/FMECA or system FMEA/ FMECA. Some literature shows two types of FMEA/FMECA in the sense that one is functional and other is hardware FMEA/FMECA (where both PFMEA/PFMECA and DFMEA/DFMECA are considered under hardware FMEA/FMECA). These different types are a result of changes in analysis pattern and assessment, but the basic concepts/approaches are the same. 

Information/documentation requirements For a successful FMEA/FMECA analysis a number of documents are necessary. The variety of information/ documentations necessary for DFMEA/DFMECA and PFMEA/PFMECA will be different. Also there wiU be variations in documentations for functional and hardware FMEA/FMECA approaches ... 

The functional FMEA is used to evaluate failures in one or many subsystems that function within a larger system, while the hardware FMEA examines failures in the assemblies, subassemblies, and components within those subsystems. The FMEA, therefore, has great versatility in the system safety process. The analysis can either be specialized, without regard for other subsystems which are not within the scope of the analysis, or it can be generalized to encompass total subsystem or system effects of a given failure condition. However, because the FMEA does not consider the human factors element or multiple failure analyses within a system, other types of system safety analysis tools and techniques should also be utilized. 

---