Upstream Application of FMEA

FMEA is not limited to evaluating a finished or even provisional design by trained reliability engineers. Using FMEA as far upstream as possible can influence a system's early architectural concept, but it's less precise and less predictive because it is even further from any actual experience with the system. Figure 13.2 illustrates the use of FMEA at several levels during design and development. Although it is taken from the hardware design and development arena,^[8] it will later be seen to be applicable to software practice. Clearly the risks identified for concept FMEA are very different from those that may occur for design FMEA or process FMEA. The point is that failure modes resulting from design errors and failure modes resulting from implementation or process errors result in very different kinds of risk and subsequent failure.

Figure 13.2. Types of FMEA That Apply to Software as Well as Hardware Architecture

Adapted from G. S. Wasserman, Reliability Verification, Testing, and Analysis in Engineering Design (New York: Marcel Dekker, 2003), p. 41.

Concept or architectural FMEA is applied at the beginning of a development project when the system's feasibility or application is first being assessed. It is used to clarify and define intended functions and their interdependencies, to assess design feasibility and implementation technology, and to determine whether redundancy is required or desirable. The scope of architectural FMEA begins at the system's top functional level but may be applied recursively throughout the system hierarchy all the way to the component level.

Design FMEA is the classical application level for the method and is still the place where it provides the most benefit as far upstream in the development process as possible. Concept, equipment, and process FMEA forms are similar in structure but differ in terms of guidelines for entering ratings. At the design level the entries can be defined most crisply.

A failure mode is the manner in which a component or system failure occursthe way in which the component or subsystem does not or might not meet the design intent or specification. It is simply the answer to the question "In what ways could this subsystem or component fail?" Naturally a failure mode can propagate through the system hierarchy, and the failure observed at each level must be noted in the form. Potential failure modes are usually considered to fall into one of four categories:^[9]

• No function: Complete absence of the intended function

• Partial function: Does not meet some of the required functions

• Intermittent function: Sometimes performs the function properly

• Unintended function: Some unintended function is performed

Potential effects of failure are defined as the effects of the failure mode on the function as perceived by the customer. There may be four types of customers:

• An internal customer, or the next stage in the development process

• An external customer or buyer of the systemin our case, of an enterprise business application (say, the CFO)

• The application's end user (say, an accounting clerk)

• A government agency/standard (abroad, the local Generally Accepted Accounting Practices [GAAP]) or regulatory body (in the United States, the Financial Accounting Standards Board [FASB])

Severity defines the seriousness of the failure effect on the customer. Table 13.1 is adapted from the severity ratings used by FMEA practitioners in the auto industry.

Table 13.1. Adaptation of the Auto Industry Severity Rating System^[10]

Severity	Description of Failure Rate	Rating	Reliability Target
Safety	Fails to meet federal safety standards	9 or 10	100%
Major	Stops the product's operation (catastrophic)	7 or 8	95%
Moderate	Product fails to perform one or more functions	4, 5, or 6	80 to 90%
Low	Causes customer annoyance	2 or 3
Minor	Customer use problem	1

Although developed by the automobile industry, this FMEA severity scale is already more suitable for software and shows more dynamic range than the earlier example. Of course, automobiles have a number of computers in them these days, from three to nine or more, so software error modes are becoming a factor in their reliability as systems as well.

The occurrence scale of failures has likewise been extended by the automobile industry to provide the spectrum shown in Table 13.2.

Table 13.2. Occurrence Rating System Used by the Auto Industry^[11]

Probability of Failure	Possible Rates	Rating
Very high (inevitable)	1 in 2 1 in 3	10 9
High (repeated failures)	1 in 8 1 in 20	8 7
Moderate (occasional)	1 in 80 1 in 400 1 in 2,000	6 5 4
Low (few failures)	1 in 15,000 1 in 150,000	3 2
Remote (failure unlikely)	1 in 1,500,000	1

This table also is more representative of software, again perhaps because automobiles today are complex electromechanical machines controlled by computer software.

FMEA can be viewed as a Pareto chart, as described in Chapter 6, for prioritizing the allocation of resources for design improvements, modifications, and/or upgrades. The design FMEA team should prioritize actions based on those failure modes with effects that have the highest severity ratings and with causes that have the highest severity times occurrence ratings. In spite of the numerical trapping of FMEA and its strong basis in mathematical and statistical analysis (see Modarres, Kaminskiy, and Krivtsov for a rigorous mathematical treatment of reliability engineering),^[12] FMEA is still an art, not a science. The further upstream in the development process it is applied, the more prescient and less scientific it becomes, yet at the same time it is more useful and insightful for motivating design changes.