Information Technology Reference
In-Depth Information
number (RPN), defined as the product of three entities, severity, occurrence (i.e.,
frequency), and detection (Haapanen et al., 2000).
A SFMEA can be described
7
as complementary to the process of defining what
software must do to satisfy the user—the customer. In our case the process of “defining
what software must do to satisfy the user—the customer” is what we entertain in the
software DFSS project road map discussed in Chapter 11. The DFSS team may visit
existing datum FMEA, if applicable, for further enhancement and updating. In all
cases, the FMEA should be handled as a living document.
16.3.1
SFMEA Hierarchy
The FMEA is a bottom-up method in which the system under analysis first is divided
hierarchically into components as in Figure 16.3. The division should be done in such
a way that the failure modes of the components (modules) at the bottom level can be
identified. We suggest the method of axiomatic design, as discussed in Chapter 13.
The failure effects of the lower level components constitute the failure modes of the
upper level components.
The basic factors influencing the selection of the proper lowest level of system
decomposition are the purpose of the analysis and the availability of system design
information.
When considering the SFMEA, the utmost purpose of the analysis usually is
to find out whether there are some software faults that, in some situation, could
jeopardize the proper functioning of the system. The lowest level components from
which the analysis is started are then units of software executed sequentially in a
single processor or concurrently in a parallel processor of the system (Haapanen
et al., 2000).
For control-based software, a well-established way to realize software-based
safety-critical automation applications is to implement the desired functions on an
automation system platform (e.g., on a programmable logic system or on a more
general automation system). The software in this kind of realization, is divided into
system software and application software. The system software (a simple operating
system) can be divided further into the system kernel and system services. Examples
of the kernel functions include the system boot, initialization, self-tests and so on,
whereas the system services, for example, take care of different data handling op-
erations. The platform also includes a library of standardized software components
with the function blocks (“modules”), of which the application is constructed by
connecting (“configuring”) adequate function blocks to form the desired application
functions, which rest on the system service support (Haapanen et al., 2000).
A natural way of thinking then would suggest that the FMEA of a software-
based application could be started from the function block diagrams by taking the
individual function blocks as the lowest level components in the analysis. In practice,
this procedure, however, seems unfeasible. First, this approach, in most cases, leads
7
See AIAG FMEA Handbook, 2002.
Search WWH ::
Custom Search