Failure Mode and Effects Analysis

Failure mode and effect analysis (FMEA) is commonly known (and often used) as a bottom-up analysis technique. In that sense, it proceeds by analysing the system components individually, or sometimes collectively, to determine failure effects thereof on the system52. The history of FMEA (and its criticality version known as FMECA53) goes back to the 1950s (Rausand et al., 2004). At the time, the technique was introduced in response to the growing concerns about the reliabilty of military systems. The standard guidelines in (MIL-STD-1629A, 1980) were thereafter developed and revised during the 1970s.

49 _{X + X.Y  X}

50

In both directions, i.e., probability of occurrence of the top event as well as allocation of probability budgets to lower-level events (i.e., the predictive role of quantitative FTA mentioned earlier).

51 _{For the purposes of, e.g., helping in the demonstration of compliance with the quantitative}

requirements derived from FHAs. This can facilitate the assessments and reviews of the certification authorities (ARP4761, 1996).

52 _{The technique aims at addressing the consequences that result from, typically, single failures.} 53 _{It adds to the FMEA a formal classification of failure effects according to severity and}

probability of each contributing factor to system level hazards. This helps in implementing corrective measures to mitigate the high risk effects. For more information about FMECA, we refer the reader to (MIL-STD-1629A, 1980).

52

The technique commonly uses a tabular description to link failure modes54 (of the system constituent parts) to their induced effects and magnitude identified accordingly. We wish to note, though, that an FMEA table may contain a number of optional columns that correspond to, e.g., means of failure detection, severity of the failure effects (with mitigation strategies if possible) as well as comments and recommendations (Pumfrey, 1999). FMEA can be useful in many ways such as (but not limited to) serving as a basis for probabilistic reliability and availability analysis, providing future references for consideration of design changes (to avoid or minimise the effects of the most critical failures identified), and helping to show how some design alternatives can (or cannot) represent optimal trade-offs55 — i.e., designs that meet dependability criteria (such as safety, reliability and availability) at a minimum cost.

There are different ways to conduct an FMEA (depending on the application), but the following are generally considered as major steps.

 Definition of the system and its components.

 Identification of the operating states of the components.

 Identification of the component failure modes and the possible effects of each component failure.

 Investigation of other factors e.g. detection and protection.  Making conclusions and recommendations.

As an example, Table 2—2 represents a part of an FMEA which corresponds to the ABS (depicted in Figure 2—5). For the component “vehicle speed sensor”, two failure modes are considered: no signal and false signal. For example, an omission of output from the vehicle speed sensor (i.e., “No signal”) makes the ABS ineffective, since it becomes impossible to detect the lock up tendencies of the wheels — the ABS interprets that a wheel is being likely to lock up by determining its brake slip according to the signal received from the vehicle speed sensor. As a consequence on the vehicle, the braking

54

i.e., forms of deviation from correct service (Avizienis et al., 2004).

55

In (Papadopoulos et al., 2011), the safety analysis tool framework (HiP-HOPS) integrates an automated optimisation of design models using genetic algorithms to evolve designs into new and optimal ones.

53

system switches to regular (i.e., no ABS function). As for the last column of the table, it shows some comments related to such a situation, like directing the driver to prevent wheel lock up by manually pumping the brake pedal. The comments can also include some warnings to prepare the driver, e.g., a possible yawing of the vehicle depending on the condition of the road, or during a panic stop.

Table 2—2. Fragment of FMEA for the ABS

Component Failure Mode Subsystem Effects Vehicle Effects Comments Vehicle speed sensor No signal Impossible to determine the brake slip for each wheel, and thus the corresponding lock up tendencies cannot be determined.

Vehicle braking in the regular manner (i.e. ABS inactive).

1) The driver has to manually pump the brakes to prevent wheel lock up. 2) The vehicle may spin on wet and slippery roads (or during a panic stop)

False signal

Incorrect

determination of the vehicle speed leading to incorrect

calculations of the different wheel brake slips. 1) Possible lock up of wheels during braking (the corresponding lock up tendencies were not detected by the ABS).

2) Possible

unnecessary changes to the fluid pressure at each wheel (performed automatically by the ABS). Effect 1) same as above. Effect 2) possibility of non optimised vehicle braking (depending on the vehicle speed estimation and the brake pedal position).

Despite the purely combinatorial aspect of FTA and FMEA (which makes them classified as static approaches too), there is a contemporary and important research focus — both industrial and academic — on using these techniques in conjunction with influential, state-of-the-art modelling languages like AADL and Altarica. In the circle of the aerospace industry for instance, there is a recent work about generating FMEA and FTs from AADL models. This work is described in (Hecht et al., 2011) and (Hecht et al., 2010) concerning an automated generation of FMEA and in (Joshi et al., 2007)

54

concerning a generation of fault trees. AADL is clearly gaining growing acceptance in the aerospace community and Altarica’s modelling and analysis platform — a tool which uses computer-performed generation of fault trees — was qualified as a validation tool in several aerospace projects, including Airbus civil aircraft programs (Bernard R. , 2009). Besides, the company Dassault Aviation56 has demonstrated the consistency of its Falcon 7X flight controls according to the requirements of the certification authorities with the aid of Altarica models. Dassault Aviation has developed an Altarica tool for the Conception and Analysis of Systems (so-called OCAS) with a generator of fault trees from Altarica57 models proposed in (Rauzy, 2002). The generated FTs can then be analysed by the Aralia tool (Dutuit & Rauzy, 1997); the performed analysis is both qualitative — in order to extract all the minimal cut-sets — and quantitative to calculate probabilities of the top events.