robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added retrospecive FMMD to conclusions.

Browse Source
This commit is contained in:
Robin Clark 2013-02-23 12:11:40 +00:00
parent 24d7898669
commit 9ea9b8f3f0
1 changed files with 38 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
submission_thesis/CH7_Conclusion/copy.tex
View File

@ -295,3 +295,41 @@ this fault, we need to devise a way of detecting this
condition in higher levels of the system. condition in higher levels of the system.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period. Associated with continuous demand systems under EN61508~\cite{en61508}}} \glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period. Associated with continuous demand systems under EN61508~\cite{en61508}}}
\section{Retrospective Failure Mode analysis and FMMD}
The reasons for applying retrospective failure mode analysis could be approving previously un-assessed
systems to a safety standard, or to determine the failure mode behaviour of an instrument used in
safety critical verification verification.
%
FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with
its work flow it
can reveal undetected failure modes.
%
FMMD requires that all failure modes of components in a {\fg} are resolved to
a symptom in the resulting {\dc}.
%
%
FMMD can find failure modes that are not
dealt with as a symptom, i.e. were unintentionally ignored
or forgotten. This means that FMMD will route out un-handled
failure modes.
%come to light.
%
We can apply retrospective FMMD to electronic and software hybrid systems as well.
Each function in the software will have to be assigned a `design~contract'~\cite{dbcbe} (where violations of
contract clauses will be treated as failure modes in FMMD).
%
By doing applying contracts and seeing how calling functions deal with
the failures in the functions they call, we reveal un-handled the error conditions in
the software.
%
FMMD models both software and hardware;
we can thus verify that all
failure modes from the electronics module, have been dealt
by the controlling software. If not they are an un-handled error condition.
%
By performing FMMD on a software electronic hybrid system,
we can reveal design deficiencies.
%in the hardware/software interface.
In Safety Integrity Level (SIL)~\cite{en61508} terms by identifying undetectable faults and fixing them, we raise
the safe failure fraction (SFF).