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

gone though the algorithms but probably need to look at a printout

Browse Source
This commit is contained in:
Robin 2010-06-05 16:55:34 +01:00
parent 09d4ebc3d1
commit db0f705ccc
1 changed files with 82 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
symptom_ex_process/symptom_ex_process.tex
View File

@ -191,7 +191,7 @@ Base Component & Any bought in component, which \\
% TO DO: separate these two:
\paragraph{symptom abstraction described}
\paragraph{Symptom Extraction Described}
The objective of `symptom abstraction' is to analyse the functional~group and find
how it can fail
@ -207,7 +207,7 @@ Each `test case' is analysed.
The component failure modes are examined with respect to their effect on the functional~group.
The philosophy behind this analysis is, how will the functional~group react
to each of the test case conditions. The aim is to produce a set of failure modes from the perspective of the functional~group.
\paragraph{Symptom identification}
\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
@ -261,6 +261,9 @@ Determine which test cases produce the same fault symptoms {\em from the perspec
\section{A general derived Component/Sub-System example}
Consider a functional group $FG$ with component parts $A$,$B$ and $C$.
$$ FG = \{ A, B , C \} $$
Each part has a set of related fault modes (i.e. ways in which it can fail to operate correctly).
Let us define the following failure modes for each component part, defining a function $FM()$ where $K$
is a component part and $F$ is its set of failure modes\footnote{Base component failure modes are defined, often with
@ -277,7 +280,10 @@ $$ FM(A) = \{ a_1, a_2, a_3 \} $$
$$ FM(B) = \{ b_1, b_2 \} $$
$$ FM(C) = \{ c_1, c_2 \} $$
We can now represent the sub-system as a set of component faulure modes $FG_{cfm}$,
\paragraph{NOTE TO ANDREW : SHOULD I DEFINE A FUNCTION HERE THAT CONVERTS A FUNCTIONAL GROUP
TO the set of failure modes in all its component parts ??? Am I being lazy here ???}
We can now represent the functional~group $FG$ as a set of component faulure modes $FG_{cfm}$,
thus
\begin{equation}
@ -309,10 +315,11 @@ $c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline
%\vspace{0.3cm}
Table~\ref{tab:fexsymptoms} shows the analysis process.
In this example we are only looking a single fault possibilities.
In this example we are only looking at single fault possibilities.
The 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 ($fgfm$'s).
These become functional~group~failure~modes ($fgfm$'s).
The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed.
% The sub-system fault symptoms are now represented on the diagram as in figure \ref{fig:gensubsys2}. A second stage of analysis is now applied. Empirically, it is often noticed that a sub-system will fail in the same way due to a variety of reasons. To the `user' of the sub-system, it does not matter which component or combination of components has failed. The sub-system can thus be considered to have its own set of failure modes. This stage of the analysis is to determine these, to collect `like symptoms'. This is performed on the diagram by linking the test cases with lines to form `spiders'
For the sake of example let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ be
@ -320,10 +327,10 @@ identical from the perspective of the functional~group.
That is to say, that the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes
occur, is going to be the same.
For example, in our CD player example, this could mean the common symptom `no\_sound'.
No matter which component failure modes, or combinations thereof cause the problem, the fault
the symptom is the same.
No matter which component failure modes, or combinations thereof cause the problem,
the failure symptom is the same.
It may be of interest to the manufacturers and designers of the CD player why it failed but
as far as we the users are concerned, it has the one symptom,
as far as we the users are concerned, it has only one symptom,
`no\_sound'!
We can thus group these component failure modes into a common symptom, $SP1$, thus
$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$.
@ -336,6 +343,10 @@ Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the fun
We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail.
In other words we have derived failure modes for this functional~group.
We can place these in a set of symptoms, $SP$.
%
$$ SP = \{ SP1, SP2, fgfm_6 \} $$
%
%
These three symptoms can be considered the set of failure modes for the functional~group, and
we can treat it as though it were a {\em black box}
@ -344,16 +355,17 @@ or a {\em component} to be used in higher level designs.
The next stage of the process could be applied automatically.
Each common symptom becomes a failure mode of
a newly created derived component. Let $DC$ be the newly derived component.
This has the failure modes that were derived from the functional~group.
This is assigned the failure modes that were derived from the functional~group.
We can thus apply the function $FM$ on this newly derived component thus:
$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$
Note that $fgfm_6$, while being a failure mode has not been grouped as a common symptom
has {\textbf not dissappeared from the analysis process}.
Note that $fgfm_6$, while %being a failure mode has
not being grouped as a common symptom
has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear in the derived component.
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, my advice to all nine year olds faced with this dilema, is its best to throw the brussell sprouts out of the dining~room window while the adults are not watching!}!
The process must not allow failure modes to be ignored or forgotten.
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, my advice to all nine year olds faced with this dilema, is its best, to throw the brussell sprouts out of the dining~room window while the adults are not watching!}!
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
\subsection{Defining the analysis process as a function}
@ -399,25 +411,35 @@ model.
%\section{A Formal Algorithmic Description of `Symptom Abstraction'}
\section{Algorithmic Description}
\section{A Formal Algorithmic Description of `Symptom Abstraction'}
The algorithm for {\em symptom abstraction} is described in
The algorithm for {\em symptom extraction} is described in
this section
%describes the symptom abstraction process
using set theory.
The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$
and converts it to a sub-system $SS$.
The sub-system $SS$ is a collection
of failure~modes of the sub-system.
The sub-system $SS$ may now be treated
and converts it to a sub-system $DC$.
%The sub-system $SS$ is a collection
%of failure~modes of the sub-system.
$DC$ is a derived component at a higher level of fault analysis abstraction,
it may be thus be treated
as a component with a known set of failure modes.
Thus $SS$ can be used as a system building block at a higher
Thus $DC$ can be used as a system building block at a higher
level of fault abstraction.
The algorithm has been broken down into five stages, each following on from the other.
The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other.
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 can be stated formally.
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}
%%
%% Algorithm 1
%%
\begin{algorithm}[h+]
~\label{alg:sympabs1}
@ -431,8 +453,8 @@ The algorithm has been broken down into five stages, each following on from the
\STATE { Let $FG$ be a set of components } \COMMENT{ The functional group should be chosen to be minimally sized collections of components that perform a specific function}
\STATE { Let $c$ represent a component}
\STATE { Let $CFM$ represent a set of failure modes }
\STATE { $FM(c) \mapsto CFM $} \COMMENT {Let the function $FM$ take a component and return a set of all its failure modes}
\STATE { Let $C_{fm}$ represent a set of failure modes }
\STATE { $FM(c) \mapsto C_{fm} $} \COMMENT {Let the function $FM$ take a component and return a set of all its failure modes}
%\ENSURE { $ \forall c | c \in FG \wedge FM(c) \neq \emptyset $}
%\ENSURE { $ c | c \in FG \wedge FM(c) \neq \emptyset $}
@ -441,22 +463,28 @@ The algorithm has been broken down into five stages, each following on from the
%symptom_abstraction
% okular
\STATE {let $FG_{cfm}$ be a set of failure modes}
\STATE {let $FG_{cfm}$ be a set of all failure modes to consider for the functional~group $FG$}
\STATE {Collect all failure modes from the components into the set $FM_{cfm}$}
%\FORALL { $c \in FG $ }
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from the components into the set $FM_{cfm}$}
%\ENDFOR
\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$}
\FORALL { $c \in FG $ }
\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
\ENDFOR
%\hline
Algorthim \ref{alg:sympabs11} has taken a functional group $FG$ and returned a set of failure~modes $FG_{cfm}$.
The next task is to formulate `test cases'. These are the collections of failure~modes that will be used
The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used
in the analysis stages.
\end{algorithmic}
\end{algorithm}
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases}
%%
%% Algorithm 2
%%
\begin{algorithm}[h+]
~\label{alg:sympabs2}
@ -508,6 +536,12 @@ The next stages is to analyse the effect of each test case on the functional gro
\end{algorithmic}
\end{algorithm}
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases}
%%
%% Algorithm 3
%%
\begin{algorithm}[h+]
~\label{alg:sympabs3}
\caption{Analyse Test Cases: $ TC \mapsto R $} \label{alg:sympabs33}
@ -526,7 +560,11 @@ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional g
\end{algorithm}
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms}
%%
%% Algorithm 4
%%
\begin{algorithm}[h+]
~\label{alg:sympabs4}
@ -564,35 +602,40 @@ causes in the functional group $FG$}
%\hline
Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level.
The failures have now been considered not from the component level, but from the sub-system or
functional group level.
functional~group level.
We now have a set $SP$ of the symptoms of failure.
\end{algorithmic}
\end{algorithm}
\clearpage
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component}
%%
%% Algorithm 5
%%
\begin{algorithm}[h+]
~\label{alg:sympabs5}
\caption{Treat the symptoms as failure modes of the Sub-System: $ SP \mapsto SS $} \label{alg:sympabs55}
\caption{Treat the symptoms as failure modes of the Derived~Component/Sub-System: $ SP \mapsto DC $} \label{alg:sympabs55}
\begin{algorithmic}[1]
\STATE { Let $SS$ be a set of faliure modes with failure modes $f$ indexed by $l$ }
\STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ }
\FORALL { $sp_l \in SP$ }
\STATE { $ f_l = ConvertToFaultMode(sp_l) $}
\STATE { $ f_l \in SS $}
\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
\ENDFOR
%\hline
Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a
sub-system $SS$, which has its own set of failure~modes. This can now be treated
as a component, and used to form functional~groups at a higher level of failure~mode~abstraction.
derived~component $DC$, which has its own set of failure~modes. This can now be
% treated as a component, and
used in conjection with other components (or derived~components) to form functional~groups at a higher level of failure~mode~abstraction.
\end{algorithmic}
\end{algorithm}
\clearpage
\section{To conclude}
The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems.