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

Finished implementing Andrews comments.

Browse Source
This commit is contained in:
Robin Clark 2010-12-06 18:38:59 +00:00
parent 14a3dc4c34
commit 2dba32c6df
1 changed files with 119 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

177
fmmd_concept/fmmd_concept.tex
View File

@ -480,12 +480,12 @@ $\Sigma\lambda_D$ the total number of dangerous base component failure modes.
$$ DiagnosticCoverage = \Sigma\lambda_{DD} / \Sigma\lambda_D $$
The diagnostic coverage for safe failures, where $\Sigma\lambda_SD$ represents the percentage of
The diagnostic coverage for safe failures, where $\Sigma\lambda_{SD}$ represents the percentage of
safe detected base component failure modes,
and $\Sigma\lambda_S$ the total number of safe base component failure modes,
is given as
$$ SF = \frac{\Sigma\lambda_SD}{\Sigma\lambda_S} $$
$$ SF = \frac{\Sigma\lambda_{SD}}{\Sigma\lambda_S} $$
\paragraph{Safe Failure Fraction.}
@ -700,11 +700,15 @@ at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodolo
%%%
%%% OK Got up to here Lunchtime edit 06DEC2010.............
\paragraph{Design Decision: Methodology must reduce and collate errors at each functional group stage.}
SYSTEMS typically have far fewer failure modes than the sum of their component failure modes.
\paragraph{Design Decision: Methodology must collate errors at each functional group stage.}
SYSTEMS typically have far fewer failure modes than the sum of their base component failure modes.
SYSTEM level failures may be caused by a variety of component failure modes.
A SYSTEM level failure mode is an abstracted failure mode, in that
it is a symptom of some lower level failure or failures.
Tracing the SYSTEM level failure or symptom, down through
a decomposed system, will give a fault tree. This will typically
trace the SYSTEM level failure mode to some individual base compoenent failures
or combinations thereof.
% ABSTRACTION
For instance a failed resistor in a sensor at a base component level is a specific
failure mode.
@ -712,12 +716,12 @@ failure mode.
For example it could be called `RESISTOR 1 OPEN'.
%
Now consider the symptom in a functional group comprising the sensor channel that
RESISTOR 1 is part of of `RESISTOR 1 OPEN'.
RESISTOR 1 is part of `RESISTOR 1 OPEN'.
%
We might call it `READING~HIGH' failure perhaps.
The Fault has become less detailed and more general. There may be other
causes for a `READING~HIGH'. We can say that the failure
mode `READING~HIGH' is more abstract in terms of the STSEM, than `RESISTOR 1 OPEN'.
mode `READING~HIGH' is more abstract in terms of the SYSTEM, than `RESISTOR 1 OPEN'.
%
At a higher level still
this may be called `SENSOR CHANNEL 1' fault.
@ -731,8 +735,9 @@ This must be a process that incrementally reduces the number
of failure modes as the abstraction level reaches the SYSTEM level.
\paragraph{How to build a meaningful SYSTEM failure behaviour model.}
The next problem is how to we build a failure mode model
that converges to a finite set of SYSTEM level failure modes.
The next problem is how we build a failure mode model
that converges from a multitude of base
component failures to a finite set of SYSTEM level failure modes.
%
It would be better to analyse the failure mode behaviour of each
functional group, and determine the ways in which it, rather than its
@ -745,7 +750,7 @@ are extracted.
The number of symptoms will be less than or equal to the number
component failure modes, and in practise will be much less.
%
The symptoms thus become the objects used to reduce the number
Thus stage by stage symptom collection becomes the key to reducing the number
of failure modes to handle as we traverse up the hierarchy.
@ -777,7 +782,15 @@ We can take small {\fg}s of components, where the {\fg}
is a small set of components that perform a simple
task.
%
This should be small enough to be able to consider all the failure
%The functional group should perform a clearly defined task.
The design engineer must chose the components that for a {\fg}.
It should be possible to consider the {\fg} as a a component or
black box, performing a given function.
The {\fg} should be chosen as to be as small
(in terms of the number of components) as possible.
%
This should be small enough to be able %Another advantage of the functional group being small
to comfortably analyse all the failure
modes of its components.
%
We can consider these failure modes from the perspective
@ -799,46 +812,70 @@ as its failure modes.
This {\dc} can be used to build higher level
{\fg}s, and this will naturally form a hierarchy.
This hierarchy can be extended until it encompasses
an entire system. It can be considered complete when
all failure modes from all components are handled
and connectable to a SYSTEM level failure mode.
an entire system.
%
It can be considered complete when
all failure modes from all components are included in the model
and all base component failure modes can be traced
through the fault tree to SYSTEM level failure modes.
\paragraph{Directed Acyclic Graph (DAG).}
The data structure produced from collecting functional groups
and deriving components will naturally form a DAG.
To ensure this we will have to ensure that
If we ensure that
derived components cannot be included in {\fg}s
of a lower abstraction level.
of a lower abstraction level
the data structure produced from collecting functional groups
and deriving components will naturally form a DAG.
In other words we can say that we cannot allow a {\fg}
to include any component created from it.
%
%
By representing the failure mode model as a DAG, we
now have the capability to take SYSTEM level failure modes
and determine the possible combinations of component failure modes that
could have caused it.
In FTA terminology, a list of possible
causes for a SYSTEM level failure is known as a minimal cut set \cite{nasafta}.
%
%
This will allow us to define fault trees for each SYSTEM level failure.
This will mean that we be able to determine which
combinations of base component failures could cause the SYSTEM
failure.
%In FTA terminology, a list of possible
%causes for a SYSTEM level failure is known as a `cut set' \cite{nasafta}\cite{nucfta}.
If statistical models exist for the component failure modes
these failure causation trees (or minimal cut sets \cite{nucfta})
can be used to calculate Mean Time to Failure (MTTF) or Probability of Failure on demand (PFD) figures.
these failure causation trees (or minimal cut sets
\footnote{In FTA terminology a minimal cut set is the branch of a
fault tree, from the top SYSTEM level to the bottom, with the least number
of base component failure modes. If a single base component failure mode can cause
a SYSTEM level error this is usually considered a liability.})
can be used to calculate Mean Time to Failure (MTTF) or
Probability of Failure on demand (PFD) figures.
Contrast the analytical capability of FMMD with the
methodologies where the component failure modes are linked
directly to SYSTEM failure modes with no analysis stages in between.
\paragraph{Design Decision: A functional group cannot contain {\dc}s at a higher abstraction level than its self}
\paragraph{Design Decision: A functional group cannot
contain {\dc}s at a higher abstraction level than itself}
We can say that no component may be derived from itself directly
or indirectly.
We can track the `abstraction level' by increasing it each time
there is a phase of symptom collection.
We can use the symbol $alpha$ to represent the abstraction level
and make it an attribute of a component.
Base components will have an $\alpha$ level of zero.
A derived component when created must always be greater than any
of the components included in the {\fg} it was derived from.
We can implement this rule in two ways, firstly, by saying that any functional group
will take the `abstraction level + 1' of all components it includes.
Secondly we can say that no component may be derived from itself.
\paragraph{Natural Reduction in number of failure modes with abstraction level}
%
Because common symptoms are being collected, as we build the tree up-ward
the number of failure modes decreases (or exceptionally stays the same) at each level.
%
Because common symptoms are being collected, as we build the tree upward
the number of failure modes decreases (or exceptionally stays the same)
at each level.\footnote{In very unusual cases where the none
failure modes of a {\fg} can be collected into symptoms,
the number of failure modes from its components would be the
same as the number of failure modes in the component derived from it.}
This decreasing of the number of failure modes is borne out {\irl}.
Of the thousands of component failure modes in a typical product
there are generally only a handful of SYSTEM level failure modes
@ -858,14 +895,15 @@ Functional groups are 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 a {\fg}. Because we can implemnent the process in software we can thus ensure that all component failure modes
are covered.
modes within a {\fg}. Because we can implemnent the process in software we can
thus ensure that all component failure modes
are included in the model.
%
We can then treat the {\fg} as a `black box' or component in its own right.
We can now look at how the {\fg} can fail.
%
Many of the component failure modes will
cause the same failure symptoms in the {\fg} failure behaviour.
cause the same failure symptoms in the {\fg}.
We can collect these failures as common symptoms.
%
When we have our set of symptoms, we can now create
@ -875,9 +913,7 @@ modes, the collected symptoms of the {\fg}.
Because we can now have {\dcs} we can use these to form
new {\fg}s and we can build a hierarchical `failure~mode' model of the SYSTEM.
The diagram in figure \ref{fig:fmmd_hierachy}, shows one stage
of the FMMD process. The resultant {\dc} may be used to
create higher level {\fg}s in later stages.
%%- Need diagram of hierarchy
%%-
%%-
@ -889,6 +925,18 @@ create higher level {\fg}s in later stages.
\label{fig:fmmd_hierarchy}
\end{figure}
A {\fg} is a set components (each with a set of of failure modes)
that collectively group together to serve some purpose (to perform some function),
and derived components are determined
from analysis and symtom collection
of the {\fg}.
The {\dc} is equipped with a new set of failure modes
corresponding to the symptoms from the {\fg}.
The diagram in figure \ref{fig:fmmd_hierarchy}, shows one stage
of the FMMD process. The resultant {\dc} may be used to
create higher level {\fg}s in later stages.
% \begin{figure}[h]
% \centering
@ -916,13 +964,15 @@ This is represented in UML in figure \ref{fig:componentconcept}.
\subsection{Environmental Conditions, Operational States and FMMD}
Any real world sub-system will exist in a variable environment and may have several modes of operation.
In order to find all possible failures, the sub-system must be analysed for each operational state
Any real world sub-system will exist in a variable environment
and may have several modes of operation.
In order to find all possible failures, the sub-system
must be analysed for each operational state
and environment condition that can affect it.
%
Two design decisions are required here, which objects should we
analyse the environment and operational states with respect to.
we have three objects in our model that these considerations could be applied to.
Two design decisions are required here: which objects should we
analyse the environment and the operational states with respect to.
There are three objects in our model that these considerations could be applied to.
We could apply these conditions for analysis
to the functional group, the components, or the derived
component.
@ -937,10 +987,10 @@ Environmental conditions may affect different components in a {\fg}
in different ways.
For instance a system may be specified for
$0\oc$ to {85\oc} operation, but some components
$0\oc$ to $85\oc$ operation, but some components
may show failure behaviour between $60\oc$ and $85\oc$
\footnote{Opto-islolators typically show marked performace decrease after
60oC \cite{tlp181}, whereas another common component, the resistor will be unaffected.}.
\footnote{Opto-islolators typically show marked performance decrease after
60oC \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
Other components may operate comfortably within that whole temperature range specified.
Environmental conditions will have an effect on the {\fg} and the {\dc}
but they will have specific effects on individual components.
@ -962,15 +1012,16 @@ normal operation, graceful degradation or lockout.
Or they could be self~checking sub-systems that are either in a normal or self~check state.
Operational states are conditions that apply to a functional group, not individual components.
%% Andrew says that that does no make sense But I think it does
\paragraph{Design Decision.}
Operational state will be applied to {\fg}s.
\paragraph{UML Model of FMMD Analysis}
Draw a UML model showing the components and the functional group
with the ENV and OP\_STAT classes associated with them
The UML diagram in figure \ref{fig:env_op_uml}, shows the data
relationships between {\fgs} and operational states, and component
failure modes and environmental factors.
\begin{figure}[h]
@ -1008,20 +1059,21 @@ or even in other projects where the same {\dc} is used.
\subsubsection{ It should have a formal basis, that is to say, it should be able to produce mathematical proofs
\subsubsection{ 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
SYSTEM level failure modes are traceable back down the tree to
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
\footnote{Here minimal cut sets represent combinations of component failure modes that can result in s SYSTEM level failure.}
for all SYSTEM failure modes.
\subsubsection{ 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}.
\subsubsection{ It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one).}
A modified form of constraint diagram (an extension of Euler diagrams) has been developed to support the FMMD methodology.
\subsubsection{ It should be easy to use, ideally
using a graphical syntax (as oppossed to a formal mathematical one).}
A modified form of constraint diagram (an extension of Euler diagrams) has
been developed to support the FMMD methodology.
This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
advance a {\fg} to a {\dc}.
@ -1036,6 +1088,9 @@ are built from components performing a given task.
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.
This is because the mutliple failure modes are considered
within {\fgs} which have fewer failure modes to consider
at each FMMD stage.
Where appropriate multiple simultaneous failures can be modelled, by
intoducing test~cases where the conjunction of failure modes is considered.
@ -1107,16 +1162,22 @@ An UML diagram with inhibit conditions added is shown in figure \ref{fig:umlconc
\subsection{Advantages of FMMD Methodology}
\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 failure modes the {\fgs} and {\dcs} these can be generic, i.e. mechanical, electronic or software components.
\item It can be checked automatically that all component failure modes have
been considered in the model. Should a failure mode have been missed
the data model can be searched and the unhandled failure modes flagged to the design engineer.
\item Because we are modelling with failure modes the {\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 is able to produce mathematical proofs
for its results (MTTF and the cause trees for SYSTEM level faults).
\item It will have a formal basis, that is to say,
we have the data at hand to produce meaningful
results (MTTF and the cause trees for SYSTEM level faults).
\item Overall reliability and danger evaluation statistics can be computed.
By knowing all causation trees,
the statistical probabilities (from base component data) for all causes can be simply added.
\item A graphical representation based on Euler diagrams is used. Providing an interface that does not involve
formal mathematical notation. This is intended to be user friendly and to guide the user through the FMMD process
\item A graphical representation based on Euler diagrams is used.
This provides an interface that does not involve
formal mathematical/symbolic notation.
This is intended to be user friendly and to guide the user through the FMMD process
while applying automatic checks for unhandled conditions.
\item From the top down the failure mode model will follow a logical de-composition of the functionality; by
chosing {\fg}s and working bottom-up this hierarchical trait will occur as a natural consequence.