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

Merge branch 'master' of dev:/home/robin/git/thesis

Browse Source
This commit is contained in:
Robin P. Clark 2013-07-29 12:35:57 +01:00
commit 2db7cd7319
1 changed files with 22 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
submission_thesis/appendixes/algorithmic.tex
View File

@ -268,7 +268,7 @@ The FMMD process is described in chapter~\ref{sec:chap4}, to re-cap, FMMD has fo
% with its own set of failure modes.
% Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system
% with its own set of failure modes.
This process allows us to modularise and simply FMEA analysis of systems.
This process allows us to modularise and simplify FMEA analysis of systems.
%
The FMMD process stages are expanded upon below.
@ -291,8 +291,8 @@ each test case.
%
%The goal of the process is to produce a set of failure modes from the perspective of the user of the {\fg}.
%
In other words, if a designer has a previously analysed module to use, he need not be concerned with
the failure modes of its components: it is handed it as a derived component,
In other words, if a designer has a previously analysed module to use, he/she need not be concerned with
the failure modes of its components: it is handled it as a derived component,
which has its own FMMD defined set of failure modes. % symptoms.
%
The designer can now treat this module as a black box (i.e. as a {\dc}).
@ -402,7 +402,7 @@ we determine the failure~mode behaviour of the {\fg}.
%
This is a human process, applying FMEA for each test case.
%
Where specific environment conditions, or operational states are germane to the {\fg}, these must also be examined
Where specific environmental conditions, or operational states are germane to the {\fg}, these must also be examined
for each test case.
%
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the {\fg}}.
@ -675,11 +675,13 @@ for each test case.
% }
% {
\subsection{Single FMMD stage described as a `symptom~abstraction~process'}
\subsection{Single stage of FMMD described as a `symptom~abstraction~process'}
We can view one stage of FMMD analysis as the act of symptom abstraction.
This is because we take a {\fg} and from its component failure modes and FMEA analysis, symptoms of failure derived.
%
This is because we take a {\fg} and from its component failure modes and FMEA analysis, derive symptom of failure. %symptoms of failure derived.
%
These derived failure mode, failure modes of the {\fg} considered as an entity or component, are abstract
or at a higher level in the systems modular hierarchy.
%To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
@ -750,7 +752,7 @@ 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
one higher that the highest $\abslev$ value of any of the components
one higher than the highest $\abslev$ value of any of the components
in the {\fg} used to derive it.
Thus a derived component sourced from base components
will have an $\abslev$ value of 1.
@ -779,10 +781,10 @@ naturally formed with the abstraction levels increasing with each tier.
%\ENDFOR
The algorithm, represented by the symbol `$\derivec$', has been broken down into five consecutive stages.
The algorithm, represented by the symbol `$\derivec$', is now broken down into five consecutive steps.
%These are described using the Algorithm environment in the next section \ref{algorithms}.
By defining the process and describing it using set theory. Constraints and
verification checks in the process are stated formally.
By defining the process and describing it using set theory constraints and
verification checks in the process can be stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -1077,10 +1079,10 @@ The analysis is primarily a human activity.
Calculations or simulations
are performed to determine how the failure modes in each test case will
affect the functional~group.
Ideally field data and/or formal physical testing should be used in addition static failure mode reasoning
Ideally field data and/or formal physical testing should be used in addition to static failure mode reasoning
where possible.
%
When the all the test cases have been analysed
When all the test cases have been analysed,
we will have a `result' for each `test case'.
%
Each result will be described from the perspective of %{\wrt} to
@ -1205,7 +1207,7 @@ set enforces the `unitary state failure mode constraint' for derived components.
%%
%% Algorithm 5
%%
This final stage, is the creation of the derived component.
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.
@ -1247,7 +1249,7 @@ to form functional~groups at higher levels of failure~mode~abstraction.
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
\subsection{Hierarchical Simplification}
Because symptom abstraction collects aggregates fault modes, the number of faults to handle should decrease
Because symptom abstraction aggregates fault modes, the number of faults to handle should decrease
as the hierarchy progresses upwards.
%This is seen by casual observation of real life Systems. NEED A GOOD REF HERE
At the highest levels the number of faults
@ -1257,7 +1259,9 @@ A sound system might have, for instance only four faults at its highest or syste
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
\normalsize
The number of causes for any of these faults is very large.
%
It does not matter to the user, which combination of component failure~modes caused the fault.
%
But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level:
as is found in practise in real world systems.
@ -1265,9 +1269,12 @@ as is found in practise in real world systems.
Because 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 we traverse up the tree.
%
This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms
in FMMD analysis hierarchies.
%
These trees can be also traversed to produce
minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
analysing the statistical likelihood of the component failures,