Information Technology Reference
In-Depth Information
using fault tree analysis 9 (FTA). “Serious” elements are important for the
design itself. “Critical” elements are regulated by the government for any
public concern.
The failure effects are propagated to the system level, such as the flight man-
agement system (FMS) in which severity designations are associated with each
failure mode. A FMS crash probably will cause the mission to be abandoned,
which conventionally is considered “Serious.” Crash of a flight control system
may jeopardize the safety of the aircraft and would be considered “Catas-
trophic.” Failures that impair mission effectiveness (short of abandonment) are
designated “Critical,” and all others are considered “Marginal.”
Depending on application, the reliability assessment can deal exhaustively
with all failure modes that lead to severity “Catastrophic” and “Serious” failures
(Table 16.3) and summarize the protection against other types of failure severity.
For the highest severity failure modes, it is essential that detection (step 8 of this
section) is direct and close to the source and that compensation is immediate
and effective, preferably by access to an alternate routine or stand-by processor.
For the lower severity failure modes, detection by effect (removed from the
source) can be acceptable, and compensation by default value or retry can
be used. Where gaps are found, the required corrective action in most cases
is obvious. This severity treatment, tied to system effects, is appropriate for
management review and may be preferred to one using failure rates.
The reliability assessment has an important legacy to test; once a failure
mode is covered by detection and compensation provisions, the emphasis in
test can shift to testing these provisions with fewer resources allocated to
testing the functional code. Because detection and compensation provisions
take a limited number of forms, test case generation is simplified, and the cost
of test is reduced.
A control plan is needed to mitigate the risks for the catastrophic and the se-
rious elements. The team needs to develop proactive design recommendations.
Potential causes: Generally, these are the set of noise factors and the defi-
ciencies designed in resulting from the violation of design principles, axioms,
and best practices (e.g., inadequate assumptions). The study of the effect of
noise factors helps the software DFSS team identify the mechanism of failure.
The analysis conducted by the team with the help of the functional decomposi-
tion (Chapter 13) allows for the identification of the interactions and coupling
of their scoped project with the surrounding environment. For each potential
failure mode identified in Column 2, the DFSS team needs to enter a cause in
this column.
5. Occurrence: Occurrence is the assessed cumulative subjective rating of the
software failures that could occur throughout the intended life. In other words,
the likelihood of the event “the cause occurs.” SFMEA usually assumes that
if the cause happens then so does the failure mode. Based on this assumption,
9 See Chapter 15.
Search WWH ::




Custom Search