As sent to JMC for english pr
This commit is contained in:
parent
f9d7a41ce8
commit
a55aa9698d
@ -156,7 +156,7 @@ Database
|
||||
number = "",
|
||||
pages = " ",
|
||||
year = "2012",
|
||||
note = "Proceedings of the First International Workshop on Euler Diagrams (Euler 2004)",
|
||||
note = " ",
|
||||
issn = "1571-0661",
|
||||
doi = "DOI: 10.1016/j.entcs.2005.02.018",
|
||||
url = "http://www.bsigroup.com/en/assessment-and-certification-services/management-systems/standards-and-schemes/iso-9001/",
|
||||
|
@ -1223,6 +1223,18 @@ We can thus create a new component derived from analysing the {\fg} where
|
||||
%
|
||||
the symptoms of failure of the {\fg} are the failure modes of this new `{\dc}'.
|
||||
|
||||
|
||||
An outline of the FMMD process is itemised below:
|
||||
\begin{itemize}
|
||||
\item Collect components to form a {\fg},
|
||||
\item Create failure cause `test~cases' for all failure modes of the components within the {\fg},
|
||||
\item Analyse the effect of all the test~cases on the operation of the {\fg},
|
||||
\item Determine the common failure modes of the {\fg},
|
||||
\item Create and name a derived component for the {\fg},
|
||||
\item Assign the common failure modes from the {\fg} as the failure modes of the {\dc}.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
%We can now call our functional~group a sub-system or a derived~component.
|
||||
%The goal here is to know how it will behave under fault conditions !
|
||||
%Imagine buying one such `sub~system' from a very honest vendor.
|
||||
@ -1297,8 +1309,11 @@ The UML class diagram in figure
|
||||
structure with its associated failure modes.
|
||||
%
|
||||
From this diagram we see that each component must have at least one failure mode.
|
||||
%
|
||||
To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
|
||||
each failure mode is referenced back to only one component. This constraint is discussed in detail in section~\ref{sec:unitarystate}.
|
||||
each failure mode is referenced back to only one component.
|
||||
%
|
||||
This constraint is discussed in detail in section~\ref{sec:unitarystate}.
|
||||
|
||||
%%-%% MTTF STATS CHAPTER MAYBE ??
|
||||
%%-%%
|
||||
@ -2156,6 +2171,7 @@ we can ensure that all these {\fms} are traceable to subsequent {\dc} {\fms}
|
||||
in the model.
|
||||
%
|
||||
With the above condition true, we term this a `complete' FMMD failure model.
|
||||
Ensuring this condition is described in section~\ref{sec:completetest}.
|
||||
|
||||
\paragraph{State explosion problem of FMEA solved by FMMD.}
|
||||
%
|
||||
@ -2164,18 +2180,22 @@ the traditional state explosion problem in FMEA, where each failure
|
||||
mode could be considered in the context of all other components in the system
|
||||
disappears.
|
||||
%
|
||||
This is dealt with formally in section~\ref{sec:cc}.
|
||||
This issue addressed formally in section~\ref{sec:cc}.
|
||||
|
||||
\paragraph{Uses of the FMMD failure mode model.}
|
||||
%
|
||||
Having a failure mode graph/model, where base component failure modes are traceable to top event events,
|
||||
provides a forward search derived failure mode model.
|
||||
A forward search means that we can apply checks to ensure that
|
||||
all known component failure
|
||||
modes have been considered in the analysis (i.e. completeness as described above).
|
||||
%
|
||||
%A forward search means that we can apply checks to ensure that
|
||||
%all known component failure
|
||||
%modes have been considered in the analysis (i.e. completeness as described above).
|
||||
This means that for every system level failure we can track back to possible causes
|
||||
in the base components. Coupled with MTTF statistics for the base components
|
||||
this allows use to predict statistical failure rates for system level failures (this is
|
||||
described in greater detail in section~\ref{sec:determine_fms}).
|
||||
%
|
||||
We can use this model to derive information
|
||||
We can also use the FMMD model to derive information
|
||||
to assist in creating related models such as FTA~\cite{nucfta,nasafta},
|
||||
traditional FMEA, FMECA~\cite{safeware}[p.344], FMEDA~\cite{scsh}, diagnostics schemas~\cite{dbamafta}
|
||||
and other failure mode analysis methodologies.
|
@ -806,9 +806,18 @@ given by
|
||||
|
||||
$$ dtc(F) = TC $$
|
||||
|
||||
In algorithm \ref{alg22}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
|
||||
a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes)
|
||||
The function \textbf{unitary state} means that all test cases can have no pairs of failure modes sourced from the same component.
|
||||
In algorithm \ref{alg22}, the function \textbf{chosen} means that
|
||||
the failure modes for a particular test case have been chosen by
|
||||
a human operator and are additional to those chosen by the automated process (i.e they are
|
||||
special case test cases involving multiple failure modes)
|
||||
The function \textbf{unitary state} means that all test
|
||||
cases can have no pairs of failure modes sourced from the same component.
|
||||
|
||||
\label{sec:completetest}
|
||||
|
||||
This function also ensure completeness in the model.
|
||||
It ensures that for all failure modes in the {\fg} are considered in a test~case.
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
%% perhaps ref a paper here XXXXX
|
||||
|
Loading…
Reference in New Issue
Block a user