morning edit
This commit is contained in:
parent
1986f5f5ba
commit
7b53515ea6
@ -83,9 +83,12 @@ These properties provide advantages in rigour and efficiency when compared to cu
|
||||
\section{Introduction}
|
||||
|
||||
This paper describes and criticises the four current failure mode methodologies,
|
||||
presents a table of the deficiencies and advantages, and then presents a new proposed
|
||||
methodology. A worked example is then provided, which models the failure mode
|
||||
discusses their advantages and deficiencies and defines a desirable criteria list
|
||||
for an ideal static failure mode methodology.
|
||||
A new proposed
|
||||
methodology is then described and discussed. A worked example is then provided, which models the failure mode
|
||||
behaviour of a non inverting op-amp.
|
||||
Using the worked example the new methodology is evaluated.
|
||||
|
||||
|
||||
\paragraph{Current methodologies}
|
||||
@ -318,15 +321,22 @@ mechanical, electronic or software components,
|
||||
criteria 3 is satisfied.
|
||||
%
|
||||
In order to address the state explosion problem, the process must be modular
|
||||
and deal with small groups of components at a time. This approach should address the state explosion problem : criteria 1.
|
||||
and deal with small groups of components at a time, should address criteria 1.
|
||||
In the proposed methodology components are collected into functional groups
|
||||
and each component failure mode (and optionally combinations) are considered in the
|
||||
context of the {\fg}.
|
||||
%
|
||||
The component failure modes (and optional combinations) are termed `test~cases'. For each test~case
|
||||
there will be a corresponding resultant failure, from the perspective of the {\fg}.
|
||||
%
|
||||
% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
|
||||
A symptom collection stage is then applied. Here common symptoms are collected
|
||||
%
|
||||
From the perspective of the {\fg} failures of components will be symptoms.
|
||||
It is proposed that many symptoms will be common. That is to say
|
||||
that component failure modes, will often cause the same symptoms of failure
|
||||
from the perspective of a {\fg}.
|
||||
%
|
||||
A common symptom collection stage is then applied. Here common symptoms are collected
|
||||
from the results of the test~cases. Because optional combinations of failures are possible,
|
||||
multiple failures can be modelled, satisfying criteria 6.
|
||||
%
|
||||
@ -547,10 +557,10 @@ we can assign a test case number (see table \ref{pdfmea}).
|
||||
Each test case is analysed to determine the `symptom'
|
||||
on the potential dividers' operation. For instance
|
||||
were the resistor $R_1$ to go open, the circuit would not be grounded and the
|
||||
voltage output from it would be the +ve supply rail.
|
||||
voltage output from it would be high (+ve).
|
||||
This would mean the symptom of the failed potential divider, would be that it
|
||||
gives an output high voltage reading. We can now consider the {\fg}
|
||||
as a component in its own right, and its symptoms as its failure modes.
|
||||
gives an output high voltage reading.%We can now consider the {\fg}
|
||||
%as a component in its own right, and its symptoms as its failure modes.
|
||||
|
||||
From table \ref{pdfmea} we can see that resistor
|
||||
failures modes lead to some common `symptoms'.
|
||||
@ -662,9 +672,9 @@ We can use the symbol $\bowtie$ to represent taking the analysed
|
||||
\ifthenelse {\boolean{dag}}
|
||||
{
|
||||
We can now represent the potential divider as a {\dc}.
|
||||
Because have its symptoms or failure mode behaviour,
|
||||
Because we have its symptoms or failure mode behaviour,
|
||||
we can treat these as the failure modes of a a new {\dc}.
|
||||
We can represent that as a DAG (see figure \ref{fig:dc1dag}).
|
||||
We can represent this as a DAG (see figure \ref{fig:dc1dag}).
|
||||
|
||||
\begin{figure}[h+]
|
||||
\centering
|
||||
@ -692,7 +702,7 @@ We can represent that as a DAG (see figure \ref{fig:dc1dag}).
|
||||
|
||||
Because the derived component is defined by its failure modes and
|
||||
the functional group used to derive it, we can use it
|
||||
as a building block for other {\fgs} in the same way as we used the resistors $R1$ and $R2$.
|
||||
as a building block for other {\fgs} in the same way as we used the base components $R1$ and $R2$.
|
||||
|
||||
%\clearpage
|
||||
|
||||
@ -1064,10 +1074,13 @@ to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysi
|
||||
\paragraph{Worked example. Effect on State explosion.}
|
||||
The potential divider {\dc} reduced the number of failures to consider from four to two.
|
||||
The op-amp and potential divider modelled together, reduced the number of
|
||||
failure symptoms from eight to three. Because symptoms are collected, we can state
|
||||
base component failures from eight to three failure symptoms.
|
||||
%
|
||||
In general,
|
||||
because symptoms are collected, we can state
|
||||
the the number of failure symptoms for a {\fg} will be less then or equal to the number
|
||||
of component failues. In practise the number of symptoms is usually around half the
|
||||
number of component failure modes.
|
||||
of component failures. In practise the number of symptoms is usually around half the
|
||||
number of component failure modes, at each stage of FMMD analysis.
|
||||
|
||||
|
||||
|
||||
@ -1086,11 +1099,11 @@ the state explosion problem is effectively dealt with.
|
||||
|
||||
\item{All component failure modes must be considered in the model.}
|
||||
The proposed methodology will be bottom-up.
|
||||
This ensures that all component failure modes are handled.
|
||||
This means that we can ensure/check that all component failure modes are handled.
|
||||
|
||||
|
||||
\item{ It should be easy to integrate mechanical, electronic and software models.}
|
||||
Because component failure modes are considered, we have a generic entity to model.
|
||||
Because FMMD models in terms of failure modes only, we have a generic failure mode entities to model.
|
||||
We can describe a mechanical, electrical or software component in terms of its failure modes.
|
||||
%
|
||||
Because of this
|
||||
@ -1099,21 +1112,24 @@ using a common notation.
|
||||
|
||||
\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
|
||||
The hierarchical nature, taking {\fg}s and deriving components from them, means that
|
||||
commonly used {\dcs} can be re-used in a design (for instance self checking digital inputs)
|
||||
commonly used {\dcs} can be re-used in a design% (for instance self checking digital inputs)
|
||||
or even in other projects where the same {\dc} is used.
|
||||
|
||||
|
||||
|
||||
\item{ It should have a formal basis, data should be available to produce mathematical proofs
|
||||
for its results}
|
||||
Because the failure mode of a SYSTEM is a hierarchy of {\fg}s and derived components
|
||||
Because the failure mode model of a SYSTEM is a hierarchy of {\fg}s and {\dcs}
|
||||
SYSTEM level failure modes are traceable back down the fault tree to
|
||||
component level failure modes. This provides causation trees \cite{sccs} or, minimal cut sets~\cite{nasafta}[Ch.1pp3]
|
||||
for all SYSTEM failure modes.
|
||||
component level failure modes.
|
||||
%
|
||||
This allows causation trees \cite{sccs} or, minimal cut sets~\cite{nasafta}[Ch.1pp3]
|
||||
to be determined by traversing the DAG from top level events down to their causes.
|
||||
|
||||
|
||||
\item{ It should be capable of producing reliability and danger evaluation statistics.}
|
||||
The minimal cuts sets for the SYSTEM level failures can have computed MTTF
|
||||
and danger evaluation statistics sourced from the component failure mode statistics \cite {mil1991}.
|
||||
and danger evaluation statistics sourced from the component failure mode statistics~\cite{fmd91,mil1991}.
|
||||
|
||||
% \item{ It should be easy to use, ideally
|
||||
% using a graphical syntax (as opposed to a formal mathematical one).}
|
||||
@ -1129,7 +1145,7 @@ The bottom-up approach fulfils the logical de-composition requirement, because
|
||||
are built from components performing a given task.
|
||||
|
||||
|
||||
\item{ Multiple failure modes may be modelled from the base component level up.}
|
||||
\item{ Multiple failure modes (conjunction) may be modelled from the base component level up.}
|
||||
By breaking the problem of failure mode analysis into small stages
|
||||
and building a hierarchy, the problems associated with the cross products of
|
||||
all failure modes within a system are reduced by an exponential order.
|
||||
@ -1150,7 +1166,7 @@ to be a %superset
|
||||
a more rigorous and `data~complete' model than
|
||||
the current four approaches, that is to say,
|
||||
from an FMMD model, we should be able to
|
||||
derive models that the other four methodologies would have been
|
||||
derive outline models that the other four methodologies would have been
|
||||
able to create. As this approach is modular, many of the results of
|
||||
analysed components may be re-used in other projects, so
|
||||
test efficiency is improved.
|
||||
|
Loading…
Reference in New Issue
Block a user