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

Lunch time edit 21SEP2010, ready for JMC to proof read

Browse Source
This commit is contained in:
Robin Clark 2010-09-21 14:34:23 +01:00
parent 21a964db69
commit df0b9de2db
8 changed files with 57 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -149,24 +149,31 @@ especially where they are non obvious top-level faults.
In order to analyse from the bottom-up, we need to take
small groups of components from the parts~list that naturally
work together to perform a simple function;
the components to include in a {\fg} are chosen by a human, the analyst.
work together to perform a simple function.
The components to include in a {\fg} are chosen by a human, the analyst.
%We can represent the `Functional~Group' as a class.
When we have a
`{\fg}' we can look at the components it contains,
and from this determine the failure modes of all the components that belong to it.
%
% and determine a failure mode model for that group.
The `{\fg}' as used by the analyst is a collection of component failures modes.
%
% expand 21sep2010
%The `{\fg}' as used by the analyst is a collection of component failures modes.
The analysts interest is the ways in which the components within the {\fg}
can fail. All the failure modes of all the components with an {\fg} are collected
into a flat set of failure modes.
%
Each of these failure modes, and optionally combinations of them, are
formed into `test cases' which are
analysed for their effect on the failure mode behaviour of the `{\fg}'.
%
From this we can determine a new set of failure modes, the failure modes of the
Once we have the failure mode behaviour of the {\fg}, we can determine a new set of failure modes, the derived failure modes of the
`{\fg}'.
%
Or in other words we can determine how the `{\fg}' can fail.
We can now consider the {\fg} as a sort of super component
with a known set of failure modes.
with its own set of failure modes.
\subsection{From functional group to newly derived component}
@ -198,8 +205,8 @@ these `derived~failure~modes'.
We thus have a `new' component, or system building block, but with a known and traceable
fault behaviour.
The UML representation shows a `functional group' having a one to one relationship with a derived~component.
We can represent this using a UML diagram in figure \ref{fig:cfg}.
The UML representation shows a `functional group' having a one to one relationship with a derived~component,
which we represent in the UML diagram in figure \ref{fig:cfg}.
The symbol $\bowtie$ is used to indicate the analysis process that takes a
functional group and converts it into a new component.
@ -648,6 +655,14 @@ $$ F = \Omega(C) \backslash \{OK\} $$
The $OK$ statistical case is the largest in probability, and is therefore
of interest when analysing systems from a statistical perspective.
This is of interest for the application of conditional probability calculations
such as Bayes theorem.
such as Bayes theorem \cite{probstat}.
%%-
%%- Need a complete and more complicated UML diagram here
%%- the other parts were just fragments to illustrate points
%%-
%%-
\vspace{40pt}

3
fmmd_concept/Makefile
View File

@ -13,3 +13,6 @@ paper: paper.tex fmmd_concept_paper.tex
#
fmmd_concept_paper.tex: fmmd_concept.tex paper.tex
cat fmmd_concept.tex | sed 's/fmmd_concept\///' > fmmd_concept_paper.tex
bib:
bibtex paper

2
fmmd_concept/paper.tex
View File

@ -25,7 +25,7 @@
\input{fmmd_concept_paper}
\bibliographystyle{plain}
\bibliography{vmgbibliography,mybib}
\bibliography{../vmgbibliography,../mybib}
\today
\end{document}

2
symptom_ex_process/algorithm.tex
View File

@ -146,7 +146,7 @@ $$ dtc(F) = TC $$
\caption{Determine Test Cases: dtc: (F) } \label{alg22}
\begin{algorithmic}[1]
\REQUIRE {F is a flat set of failure modes }
\REQUIRE {F is a non empty flat set of failure modes }
\STATE { All test cases are chosen by the investigating engineer(s). Typically all single
component failures are investigated

19
symptom_ex_process/process.tex
View File

@ -32,9 +32,8 @@ The goal of the process is to produce a set of failure modes from the perspectiv
\paragraph{Symptom Identification}
When all `test~cases' have been analysed, a second phase can be actioned. % applied.
%
This looks at the results of the `test~cases' as symptoms
of the sub-system.
Single component failures (or combinations) within the functional~group may cause unique symptoms.
This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system.
%Single component failures (or combinations) within the functional~group may cause unique symptoms.
However, many failures, when looked at from the perspective of the functional group, will have the same symptoms.
These can be collected as `common symptoms'.
To go back to the CD~player example, a failed
@ -56,7 +55,9 @@ from the components in a functional~group have been handled\footnote{Software ca
failure modes have been included in at least one test case, and modelled individually. For Double
Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well}.
Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes.
It is possible here for an automated system to flag unhandled failure modes,
which solves the main failing of top~down methodologies \cite{topdownmiss}, that of not
guaranteeing to model all component failure modes.
\ref{requirement at the start}
@ -137,7 +138,7 @@ where $a_n,b_n,c_n$ are component failure modes.
\paragraph{Finding all failure modes within the functional group}
For fmMD failure mode analysis, we need to consider the failure modes
For FMMD failure mode analysis, we need to consider the failure modes
from all the components in the functional group as a flat set.
This can be found by applying function $fm$ to all the components
in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus:
@ -188,8 +189,8 @@ $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline
%\vspace{0.3cm}
Table~\ref{tab:fexsymptoms} shows the analysis process.
As we are only looking at single fault possibilities for this example each failure mode
is represented by a test~case.
As we are only looking at single fault possibilities for this example each test case
is represented by one failure mode.
Chosen combinations of Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}.
The test cases are analysed w.r.t. the functional~group.
These become functional~group~failure~modes ($g$'s).
@ -237,7 +238,7 @@ Note that $g_6$ has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component.
i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$.
Because the process can be computerised, we can easily flag symptoms that have not been
included a derived component.
included as failure modes in a {\dc}.
% Aw boring ! no jokes ?
% This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}!
%
@ -275,7 +276,7 @@ This generalises the function $\bowtie$ and allows us to build
hierarchical failure mode models.
Where a {\fg} is composed of derived components, for sake of example
Where $DC_1, DC_2, DC_3 $ are {\dc}'s and $DCFM$ is a set of failure modes thus
where $DC_1, DC_2, DC_3 $ are {\dc}'s and $DCFM$ is a set of failure modes thus
$FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$
We can apply the symptom abstraction process $\bowtie$

17
symptom_ex_process/sys_abs.tex
View File

@ -29,10 +29,11 @@ The goal of the process is to produce a set of failure modes from the perspectiv
\paragraph{Symptom Identification}
When all `test~cases' have been analysed, a second phase is applied.
%
This looks at the results of the `test~cases' as symptoms
of the sub-system.
Single component failures (or combinations) within the functional~group may cause unique symptoms.
However, many failures, when looked at from the perspective of the functional group, will have the same symptoms.
This looks at the results of the `test~cases' as failure modes from the perspective of
of the {\fg}/sub-system.
%%Single component failures (or combinations) within the functional~group may cause unique symptoms.
However, many failures, when looked at from the perspective of the functional group, will have the same `symptoms' (or
in other words the sub-system/{\fg} will fail in the same way for a variety of causes.
These can be collected as `common symptoms'.
To go back to the CD~player example, a failed
output stage, and a failed internal audio amplifier,
@ -43,10 +44,12 @@ will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected.
We can now consider the functional~group as a component and the common symptoms as its failure modes.
We can now consider the functional~group as a component and the symptoms as its failure modes.
Note that here because the process is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes.
\ref{requirement at the start}
It is possible at this stage for an automated system to flag unhandled failure modes,
which fulfills the wish list in chapter \ref{requirement at the start}, removing
the main drawback with top-down methodologies, that of missing component failure mode
in the model \cite{nancy_crit_fta_top_down}.

2
symptom_ex_process/topbot.tex
View File

@ -37,7 +37,7 @@ Specific measurements
and checks will be made, and finally a component or a low level sub-system
will be found to be faulty.
A natural fault finding process is thus top~down.
Top down fault isolation/finding techniques are described in \ref{NETWORKDECOMPOSITION}.
Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
%%
%% to fool the graphics insertion to make it compatible