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

appendix B : we removal

Browse Source
This commit is contained in:
Robin P. Clark 2013-09-11 17:40:48 +01:00
parent fd55a7a81e
commit b537dff47b
1 changed files with 33 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
submission_thesis/appendixes/algorithmic.tex
View File

@ -51,7 +51,7 @@ This process allows us to modularise and thus simplify FMEA analysis of systems.
\paragraph{FMEA applied to the {\fg}: choosing test~cases.}
As a {\fg} is a collection of components, the failure~modes
that we have to consider are the failure modes of its components.
to consider are the failure modes of its components.
%, as
%developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
%The aim here is to build `test cases',
@ -83,7 +83,7 @@ environmental conditions to which it may be exposed. In this way, all possible
failure mode behaviour, due to all the conditions that can be applied for all the test~cases will be examined.
%
\paragraph{Symptom Identification.}
When all test~cases have been analysed, we have a set of FMEA results for the given {\fg}. % applied.
When all test~cases have been analysed, a set of FMEA results exists for the given {\fg}. % applied.
These results can be viewed as symptoms of failure of the {\fg}.
%
%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.
@ -115,12 +115,12 @@ These results can be viewed as symptoms of failure of the {\fg}.
% We can now create a new component and consider the symptoms as its failure modes.
Common symptoms of failure of the {\fg} are collected.
%
We can now create a new component to represent the {\fg} and consider these aggregated symptoms as its failure modes.
A new component is created to represent the {\fg} and the aggregated symptoms considered as its failure modes.
%
We call this new component a `{\dc}'.
This new component is called a `{\dc}'.
%
%Note that here, b
Because the FMMD process is bottom up, we can ensure that all failure modes
Because the FMMD process is bottom up, it can be ensured that all failure modes
from the components in a {\fg} have been considered.
%\footnote{Software can check that all 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.}.
@ -154,7 +154,7 @@ form `test~cases'.
% \item Where simultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case
\item Using the `test cases' as scenarios to examine the effects of component failures, %% APPLY FMEA
we determine the failure~mode behaviour of the {\fg}.
the failure~mode behaviour of the {\fg} is determined.
%
This is a human process, applying FMEA for each test case.
%
@ -192,7 +192,7 @@ that will be used in the algorithmic description of FMMD.
Let the set of all possible components be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{F}$ and $\mathcal{P}$ the powerset.
\fmmdgloss
We can define a function $fm$ which returns the failure modes for a given component (see section~\ref{sec:formal7}):
The function $fm$ is defined which returns the failure modes for a given component (see section~\ref{sec:formal7}):
\begin{equation}
{fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} .
@ -201,8 +201,8 @@ We can define a function $fm$ which returns the failure modes for a given compo
%defined by (where $C$ is a component and $F$ is a set of failure modes):
%$$ fm ( C ) = F $$
We overload the notation for the function $fm$
and define it for the set of components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
The notation for the function $fm$ is overloaded
and defined for the set of components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
\begin{equation}
fm : FG \rightarrow \mathcal{F} .
@ -211,7 +211,7 @@ fm : FG \rightarrow \mathcal{F} .
Where $\mathcal{FG}$ is the set of all sets of {\fgs}, and $\mathcal{DC}$
is the set of all derived components, we can define the symptom abstraction process thus:
is the set of all derived components, the symptom abstraction process is defined thus:
$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
@ -327,13 +327,15 @@ all components within the given {\fg}.
\subsection{ Determine Test Cases}
From the failure modes associated with the functional~group,
we now need to determine test cases.
test cases must next be determined.
%we now need to determine test cases.
%
The test cases are collections of failure modes.
These can be formed from single failure modes or failure modes in combination.
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$
be the set of all failure modes.
%(associated with the functional group $FG$).
We define the function $dtc$ thus:
The function $dtc$ is defined thus:
%
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC}, $$
%
@ -507,7 +509,7 @@ Ideally field data and/or formal physical testing should be used in addition to
where possible.
%
When all the test cases have been analysed,
we will have a `result' for each `test case'.
a `result' will exist for each `test case'.
%
Each result will be described from the perspective of %{\wrt} to
the {\fg}, not the members of it i.e. the components. % failure modes.
@ -519,8 +521,10 @@ the {\fg}, not the members of it i.e. the components. % failure modes.
%%
%
Thus we will have a set of
results corresponding to our test cases. These share a common index value ($j$ in the algorithm description).
A set of
results corresponding to our test cases is now available.
%
These share a common index value ($j$ in the algorithm description).
These results are the failure modes of the {\fg}.
\fmmdgloss
%Once a functional group has been analysed, it can be re-used in
@ -546,7 +550,7 @@ has the same failure symptom.
Let set $\mathcal{SP}$ be the set of all symptoms,
and $\mathcal{R}$ be the set of all test case results.
%
We define the function $fcs$ thus:
The function $fcs$ is defined thus:
%
$$fcs: \mathcal{R} \rightarrow \mathcal{SP} ,$$
given by
@ -602,7 +606,7 @@ $$ fcs(R) = SP .$$
This raises the failure~mode abstraction level, $\abslev$ (see section~\ref{sec:alpha}).
The failures have now been considered not from the component level, but from the sub-system or
functional~group level.
We now have a set $SP$ of the symptoms of failure.
A set $SP$, the symptoms of failure is obtained.
%
\ifthenelse {\boolean{paper}}
{
@ -638,7 +642,7 @@ This final stage is the creation of the derived component.
This derived component may now be used to build
new {\fgs} at higher levels of fault abstraction.
Let $DC$ be a derived component with its own set of failure~modes.
We define the function $cdc$ thus:
The function $cdc$ is defined thus:
$$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} , $$
%
given by
@ -670,19 +674,23 @@ The new component will have a set of failure modes that correspond to the common
%
%Algorithm \ref{alg55}
%The function $cdc$ is the final stage in the process.
We now have a
derived~component $DC$, which has its own set of failure~modes. This can now be
A
derived~component $DC$, which has its own set of failure~modes has been created.
%
This can now be
used in with other components (or derived~components)
to form functional~groups at higher levels of failure~mode~abstraction.
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
\paragraph{Enumerating abstraction levels.}
\label{sec:abstractionlevel}
As described in section~\ref{sec:alpha} we can assign the attribute of abstraction level $\abslev$ to
%
As described in section~\ref{sec:alpha} the attribute of abstraction level $\abslev$ can be assigned to
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
%
For a base component, let the abstraction level be zero.
%
If we apply the symptom abstraction process $\derivec$,
the resulting derived~component will have an $\abslev$ value
The symptom abstraction process is applied giving a $\derivec$,
this derived~component will have an $\abslev$ value
one higher than the highest $\abslev$ value of any of the components
in the {\fg} used to derive it.
%
@ -725,7 +733,8 @@ as is found in practise in real world systems.
Since the fault modes are determined from the bottom-up, the causes
for all high level faults naturally form trees.
%
That is to say from the bottom-up causes become symptoms, which in the next level become causes as we traverse up the tree.
That is to say from the bottom-up causes become symptoms,
which in the next level become causes as the tree is traversed upwards.
%
This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms
in FMMD analysis hierarchies.