as given to Hazel to proof read
This commit is contained in:
parent
70ed6fdfe9
commit
27f11dc4f4
@ -342,7 +342,7 @@ to smaller and smaller functional modules \cite{maikowski}.
|
|||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
|
|
||||||
\section{Proposed Methodology \\ Failure Mode Modular De-Composition (FMMD)}
|
\section{}
|
||||||
|
|
||||||
\paragraph{New methodology Must be bottom-up}
|
\paragraph{New methodology Must be bottom-up}
|
||||||
In order to ensure that all component failure modes have been covered
|
In order to ensure that all component failure modes have been covered
|
||||||
@ -363,7 +363,16 @@ in \cite{maikowski}. This top down technique de-composes by functionality.
|
|||||||
Simpler and simpler functional blocks are discovered as we delve
|
Simpler and simpler functional blocks are discovered as we delve
|
||||||
further into the way the system works and is built.
|
further into the way the system works and is built.
|
||||||
|
|
||||||
|
\paragraph{Design Decision: Methodology Mus be Bottom-up}
|
||||||
|
In oder to ensure that all component failure modes are handled,
|
||||||
|
this methodology must statrt at the bottom, with base component failure modes.
|
||||||
|
In this way automated checking can be applied to all component failure modes
|
||||||
|
to ensure none have been inadvertantly excluded from the process.
|
||||||
|
|
||||||
\paragraph{Need for a `bottom-up' system de-composition}
|
\paragraph{Need for a `bottom-up' system de-composition}
|
||||||
|
There is an apparent conflict here. The natural way to
|
||||||
|
de-compose a system is from the top down.
|
||||||
|
%
|
||||||
What is required here is to mimic this top-down de-composition
|
What is required here is to mimic this top-down de-composition
|
||||||
with a bottom up technique.
|
with a bottom up technique.
|
||||||
|
|
||||||
@ -381,14 +390,24 @@ This means that we have to tie base component failure modes
|
|||||||
to SYSTEM level errors. This is the `possibility to miss failure mode effects
|
to SYSTEM level errors. This is the `possibility to miss failure mode effects
|
||||||
at SYSTEM level' critism of the FTA, FMEDA and FMECA methodologies.
|
at SYSTEM level' critism of the FTA, FMEDA and FMECA methodologies.
|
||||||
|
|
||||||
|
\paragraph{Design Decision: Methodolgy must reduce and collate errors at each functional group stage}
|
||||||
|
SYSTEMS typically have far fewer failure modes then the sum of its comonent failure modes.
|
||||||
|
Many SYSTEM level errors may be caused by a variety of component level errors.
|
||||||
|
At each fucntional group collection, there must be a process to collect
|
||||||
|
common symptoms and reduce the number of failure modes to handle.
|
||||||
|
|
||||||
\paragraph{How to build a SYSTEM failure behaviour model}
|
\paragraph{How to build a SYSTEM failure behaviour model}
|
||||||
The next problem is how to we build a failure mode model
|
The next problem is how to we build a failure mode model
|
||||||
that converges to a finite set of SYSTEM level failure modes.
|
that converges to a finite set of SYSTEM level failure modes.
|
||||||
%
|
%
|
||||||
It would be better would be to analyse the failure mode behaviour in each
|
It would be better would be to analyse the failure mode behaviour of each
|
||||||
functional group, and determine the ways in which it, rather than its
|
functional group, and determine the ways in which it, rather than its
|
||||||
components, can fail.
|
components, can fail.
|
||||||
|
%
|
||||||
|
By doing this, the natural process whereby symptoms of the {\fg},
|
||||||
|
which can potentially be caused by more then one
|
||||||
|
component failure mode, become the target for reducing the number
|
||||||
|
of failure modes to handle as we traverse up the hierarchy.
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Component failures and {\fg} failure symptoms}
|
\paragraph{Component failures and {\fg} failure symptoms}
|
||||||
|
Loading…
Reference in New Issue
Block a user