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

Hazel proof read this for me

Browse Source
This commit is contained in:
Robin Clark 2010-11-14 10:32:32 +00:00
parent 2af3c8b083
commit ff8ff96fe5
1 changed files with 54 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
fmmd_concept/fmmd_concept.tex
View File

@ -170,7 +170,7 @@ decide which interactions are important.
Let N be the number of components in our system, and K be the average number of component failure modes Let N be the number of components in our system, and K be the average number of component failure modes
(ways in which the component can fail). The total number of base component failure modes (ways in which the component can fail). The total number of base component failure modes
is $N \times K$. To examine the affect that one failure mode has on all the other components is $N \times K$. To examine the effect that one failure mode has on all the other components
will be $(N-1) \times N \times K$, in effect a set cross product. will be $(N-1) \times N \times K$, in effect a set cross product.
@ -189,7 +189,7 @@ be typical of a very simple temperature controller, with a micro-controller sens
we have $99 \times 100 \times 2.5 \times 10 = 247500 $. we have $99 \times 100 \times 2.5 \times 10 = 247500 $.
To look in detail at a quarter of a million test cases is obviously impractical. To look in detail at a quarter of a million test cases is obviously impractical.
If we were to consider multiple simultaneous failure modes If we were to consider multiple simultaneous failure modes,
we have yet another complication cross product. we have yet another complication cross product.
For instance for looking at double simultaneous failure modes, For instance for looking at double simultaneous failure modes,
@ -495,7 +495,7 @@ and its international analog standard IOC5108.
\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects. \item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
\item It should have a formal basis, that is to say, it should be able to produce mathematical proofs \item It should have a formal basis, that is to say, it should be able to produce mathematical proofs
for its results, such as system level error causation trees, reliability and safety statistics. for its results, such as system level error causation trees, reliability and safety statistics.
\item It should be easy to use, Ideally using a graphical syntax (as oppossed to a formal mathematical one). \item It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality \item From the top down, the failure mode model should follow a logical de-composition of the functionality
to smaller and smaller functional modules \cite{maikowski}. to smaller and smaller functional modules \cite{maikowski}.
\item Multiple failure modes may be modelled from the base component level up. \item Multiple failure modes may be modelled from the base component level up.
@ -523,18 +523,19 @@ 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 must be bottom-up.}
In order to ensure that all component failure modes are handled,
this methodology must start 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 inadvertently 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 There is an apparent conflict here. The natural way to
de-compose a system is from the top down. de-compose a system is from the top down.
% %
If we do this though, we do not naturally include
all failure modes in the modules determined as we
de-compose downwards.
%
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.
By doing that, we can take all base component failure modes
and ensure they are included in the model.
By taking components that form {\fg}s from the bottom up By taking components that form {\fg}s from the bottom up
and then taking those to form higher level and then taking those to form higher level
@ -547,6 +548,11 @@ A second justification for this is that the design process for a product require
thinking. To analyse a system from the bottom-up is a useful thinking. To analyse a system from the bottom-up is a useful
design validatio process in itself \cite{sommerville}. design validatio process in itself \cite{sommerville}.
\paragraph{Design Decision: Methodology must be bottom-up.}
In order to ensure that all component failure modes are handled,
this methodology must start 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 inadvertently excluded from the process.
\paragraph{Problem with functional group hierarchy} \paragraph{Problem with functional group hierarchy}
A hierarchy of functional grouping, leading to a system model A hierarchy of functional grouping, leading to a system model
@ -568,10 +574,16 @@ For instance a failed resistor in a sensor at a base component level is a specif
failure mode. failure mode.
% %
For example it could be called `RESISTOR 1 OPEN'. For example it could be called `RESISTOR 1 OPEN'.
Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract
or in other words describe the effect more generally.
% %
We might call it `READING~HIGH' perhaps. At a higher level still Now consider the symptom in a functional group comprising the sensor channel that
RESISTOR 1 is part of 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'.
%
At a higher level still
this may be called `SENSOR CHANNEL 1' fault. this may be called `SENSOR CHANNEL 1' fault.
At a system level it may simply be a `SENSOR FAILURE'. At a system level it may simply be a `SENSOR FAILURE'.
As we traverse up the fault tree the failure modes As we traverse up the fault tree the failure modes
@ -613,7 +625,7 @@ failure mode behaviour, but can check that all failure modes in
the hierarchy have been considered and tied to causing symptoms. the hierarchy have been considered and tied to causing symptoms.
\paragraph{Incremental Stages and \dcs}. \paragraph{Incremental Stages and \dcs .}
We can use incremental stages to build the hierarchy. We can use incremental stages to build the hierarchy.
We can take small {\fg}s of components, where the {\fg} We can take small {\fg}s of components, where the {\fg}
is a small set of components that perform a simple is a small set of components that perform a simple
@ -635,7 +647,7 @@ are the same failure w.r.t. the {\fg}.
% %
We can now treat the {\fg} as a component, and call it a {\dc}, in other words, a sub-system with a known set of failure modes. We can now treat the {\fg} as a component, and call it a {\dc}, in other words, a sub-system with a known set of failure modes.
% %
We can now create a new {\dc} and assign it these common symptoms We can now create a new/{\dc} and assign it these common symptoms
as its failure modes. as its failure modes.
% %
This {\dc} can be used to build higher level This {\dc} can be used to build higher level
@ -645,12 +657,38 @@ an entire system. It can be considered complete when
all failure modes from all components are handled all failure modes from all components are handled
and connectable to a SYSTEM level failure mode. and connectable to a SYSTEM level failure mode.
\paragraph{Directed Acyclic Graph.} This will naturally form a DAG \paragraph{Directed Acyclic Graph (DAG).}
meaning that for all SYSTEM failure modes, we will be able to trace The data structure produced from collecting functional groups
back through the DAG to possible component failure mode causes. and deriving components will naturally form a DAG.
To ensure this we will have to ensure that
derived components cannot be included in {\fg}s
of a lower abstraction level.
%
%
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}.
%
%
If statistical models exist for the component failure modes If statistical models exist for the component failure modes
these failure causation trees (or minimal cut sets \cite{nucfta}) 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. can be used to calculate Mean Time to Failure (MTTF) or Probability of Failure on demand (PFD) figures.
Constract the analytical capability of this 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}
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 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. the number of failure modes decreases (or exceptionally stays the same) at each level.