.
This commit is contained in:
parent
5d598082c2
commit
a98b4ee918
@ -19,8 +19,8 @@ modular.}
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
There are three methodologies in common use for failure mode modelling.
|
||||
These are FTA, FMEA
|
||||
There are four methodologies in common use for failure mode modelling.
|
||||
These are FTA, FMEA, FMECA
|
||||
and FMEDA (a form of statistical analysis).
|
||||
|
||||
These methodologies have several draw backs.
|
||||
@ -221,10 +221,13 @@ to smaller and smaller functional modules \cite{maikowski}.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Proposed Methodology}
|
||||
\section{Proposed Methodology \\ Failure Mode Modular De-Composition (FMMD)}
|
||||
|
||||
The proposed methodology will be bottom-up. to fulfill the logical de-composition requirement
|
||||
it must build {\fg}s from the bottom-up. These are minimal collections of components
|
||||
The proposed methodology will be bottom-up.
|
||||
Thiure that all component failure modes are handled.
|
||||
The bottom-up approach also fulfills the logical de-composition requirement.
|
||||
FMMD builds {\fg}s of components from the bottom-up.
|
||||
Thus the {\fg}s are minimal collections of components
|
||||
that work together to perform a simple function.
|
||||
We can perform a failure mode effects analysis on each of the component failure
|
||||
modes within the {\fg}. We can thus ensure that all component failure modes
|
||||
@ -236,9 +239,24 @@ When we have out set of symptoms, we can now create
|
||||
a {\dc}. The {\dc} will have as its set of failures
|
||||
modes, the collected symptoms of the {\fg}.
|
||||
|
||||
Because we can now have a {\dc} we can use these to form
|
||||
Because we can now have a {\dcs} we can use these to form
|
||||
new {\fg}s and we can build a hierarchical model of the system failure modes.
|
||||
|
||||
Advantages
|
||||
|
||||
\begin{itemize}
|
||||
\item It can be checked, automatically that, all component failure modes have been considered in the model.
|
||||
\item Because we are modelling with {\fgs} and {\dcs} these can be generic, i.e. mechanical, electronic or software components.
|
||||
\item The {\dcs} are re-usable, in that commonly used modules can be re-used in other designs/projects.
|
||||
\item It will have a formal basis, that is to say, it should be able to produce mathematical proofs
|
||||
for its results (MTTF and the causes for SYSTEM level faults).
|
||||
\item Overall reliability and danger evaluation statistics can be computed.
|
||||
\item A graphical representation based on Euler diagrams is proposed.
|
||||
\item From the top down the failure mode model should will a logical de-composition of the functionality, by
|
||||
chosing {\fg}s this happens as a natural consequence.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
%%- \section{building blocks of a safety critical systen}
|
||||
|
Loading…
Reference in New Issue
Block a user