Information Technology Reference
In-Depth Information
Level 1
Level 1
Module 1
FMEA
Level 2
Module 1.1
Level 2
Module 1.2
Module 1.3
FMEA
Level 3
Module 1.2.1
Level 3
Module 1.2.2
Module 1.2.3
FIGURE 16.3
SFMEA hierarchy.
constitute a good starting point also for the FMEA for software-based systems.
Depending on the objectives, level, and so on. of the specific FMEA this procedure
easily can be adapted to the actual needs case by case (Haapanen et al., 2000).
In this section, we focus on the software failure modes, effects in the failure mode,
effects analysis of a software-based control, and automation system application. A
complete FMEA for a software-based automation system should include both the
hardware and software failure modes and their effects on the final system function.
In this section, however, we limit ourselves only to the software part of the analysis;
the hardware part being discussed more in Yang and El-Haik (2008) and El-Haik and
Mekki (2008) with the DFSS framework.
FMEA is documented on a tabular worksheet; an example of a typical FMEA
worksheet is presented in Figure 16.3; this readily can be adapted to the specific
needs of each actual FMEA, application.
Risk analysis is a quantitative extension of the (qualitative) FMEA, as described in
Chapter 15. Using the failure effects identified by the FMEA, each effect is classified
according to the severity of damage it causes to people, property, or the environment.
The frequency of the effect to come about, together with its severity, defines the
criticality. A set of severity and frequency classes are defined, and the results of
the analysis is presented in the criticality matrix. The SAE J-1739 standard adds a
third aspect to the criticality assessment by introducing the concept of a risk priority
Search WWH ::
Custom Search