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

from the A27 refugee

Browse Source
This commit is contained in:
Robin Clark 2010-08-04 20:44:11 +01:00
parent 1bf848f942
commit 907ebd3b99
3 changed files with 66 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
symptom_ex_process/algorithm.tex
View File

@ -51,13 +51,13 @@ naturally formed with the abstraction levels increasing with each tier.
%\ENDFOR %\ENDFOR
The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages. The algorithm, represented by the symbol `$\bowtie$', has been broken down into five consecutive stages.
These are described using the Algorithm environment in the next section \ref{algorithms}. %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 By defining the process and describing it using set theory, constraints and
verification checks in the process are stated formally. verification checks in the process are stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\clearpage %\clearpage
\subsection{ Determine Failure Modes to examine} \subsection{ Determine Failure \\ Modes to examine}
The first stage is to find the failure modes to consider for The first stage is to find the failure modes to consider for
analysis. analysis.
@ -156,7 +156,7 @@ $$ DTC(F) = TC $$
\IF{Single fault checking} \IF{Single fault checking}
\STATE { let $f$ represet a component failure mode } \STATE { let $f$ represent a component failure mode }
%\ENSURE { That all failure modes are represented in at least one test case } %\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ } \ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that at least each failure mode is considered at \COMMENT { This corresponds to checking that at least each failure mode is considered at
@ -165,7 +165,7 @@ $$ DTC(F) = TC $$
\ENDIF \ENDIF
\IF{Double fault checking} \IF{Double fault checking}
\STATE { let $f1,f2$ represet a component failure modes, and $c$ any component in the functional group } \STATE { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group }
%\ENSURE { That all failure modes are represented in at least one test case } %\ENSURE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ } \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ }
\COMMENT { This corresponds to checking that each possible double failure mode is considered \COMMENT { This corresponds to checking that each possible double failure mode is considered
@ -228,6 +228,30 @@ $$ ATC(TC) = R $$
Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case. Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case.
The analysis is primarily a human activity.
%
Each test case is examined in detail.
%
%
Ideally calculations or simulations
are performed to determine the functional~group failure mode
the test case failure modes will cause.
%
%
In the case of a simple
electronic circuit, we could calculate the effect on voltages
within the circuit given certain component failure modes for instance.
The affect of these unusual volatges would then be a failure
mode of the functional group and become the result of the test case.
When each test case has been analysed, we have a set of
results. These are the failure modes of the functional group.
Once a functional group has been analysed, it can be re-used in
any other design that uses it.
Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$
inputs).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage \clearpage
@ -235,9 +259,14 @@ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional g
%% %%
%% Algorithm 4 %% Algorithm 4
%% %%
This stage analyses the results from bottom-up FMEA analysis ($R$), and collects %This stage analyses the results from bottom-up FMEA analysis ($R$), and collects
results that, from the perspective of the functional~group, have the same failure symptom. %results that, from the perspective of the functional~group, have the same failure symptom.
Let set $SP$ be the set of symptoms for the functional group $FG$. iThis stage collects results into `Symptom' sets.
Each result from the preceding stage is examined and collected
into common symptom sets.
That is to say, each result in a symptom set, from the perspective of the functional group
has the same failure symptom.
Let set $SP$ be the family of symptom sets for the functional group $FG$.
$$FCS: \mathcal{R} \rightarrow \mathcal{SP} $$ $$FCS: \mathcal{R} \rightarrow \mathcal{SP} $$
given by given by
@ -279,25 +308,32 @@ causes in the functional group $FG$}
\end{algorithmic} \end{algorithmic}
\end{algorithm} \end{algorithm}
Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level. Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level, $\alpha$.
The failures have now been considered not from the component level, but from the sub-system or 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. We now have a set $SP$ of the symptoms of failure.
\ifthenelse {\boolean{paper}} \ifthenelse {\boolean{paper}}
{ {
%CUNT VIM just went and wrote random shit did you not
Component failure modes must be mutually exclusive. Component failure modes must be mutually exclusive.
That is to say only one specific failure mode may be active at any time. That is to say only one specific failure mode may be active at any time.
This condition/property has been termed unitary state failure mode. This condition/property has been termed unitary state failure mode.
Ensuring that no result belongs to more than Ensuring that no result belongs to more than
one Symptom set, enforces this. one Symptom set, enforces this, for the derived
component created in the next stage.
} }
{ {
Note ensuring that no result belongs to more than one symptom Note ensuring that no result belongs to more than one symptom
enforces unitary state failure mode constraint for derived components. set enforces unitary state failure mode constraint for derived components.
} }
%% Interesting to draw a graph here.
%% starting with components, branching out to failure modes, then those being combined to
%% test cases, the test cases producing results, and then the results collected into
%% symptoms.
%% the new component then gets the symptoms as failure modes.
%% must be drawn !!!!!
%% 04AUG2010 ~~~~ A27 refugee !!!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

13
symptom_ex_process/process.tex
View File

@ -73,7 +73,7 @@ form `test cases'.
\clearpage
\section{A theoretical `Derived Component' example} \section{A theoretical `Derived Component' example}
Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$.
@ -87,7 +87,14 @@ that is passed a component and returns the set of failure modes associated with
statistics and evironmental factors in a variety of sources. \cite{mil1991} statistics and evironmental factors in a variety of sources. \cite{mil1991}
}. }.
\ifthenelse {\boolean{paper}}
{
\subsection{Define Failure mode function FM}
}
{
To re-cap from the definitions chapter \ref{chap:definitions}. To re-cap from the definitions chapter \ref{chap:definitions}.
}
Let the set of all possible components be $\mathcal{C}$ Let the set of all possible components be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{F}$. and let the set of all possible failure modes be $\mathcal{F}$.
@ -185,7 +192,7 @@ We can thus group these component failure modes into a common symptom, $SP1$, th
$ SP1 = \{g_2, g_4, g_5\}$. $ SP1 = \{g_2, g_4, g_5\}$.
% These can then be joined to form a spider. % These can then be joined to form a spider.
Likewise Likewise
let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure mode {\em from the perspective of the functional~group}. let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure~mode {\em from the perspective of the functional~group}.
Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom},
but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$. but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$.
@ -229,7 +236,7 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Defining the analysis process as a function} \subsection{Defining the analysis process \\ as a function}
It is useful to define this analysis process as a function. It is useful to define this analysis process as a function.
Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now

8
symptom_ex_process/topbot.tex
View File

@ -55,6 +55,14 @@ Top down fault isolation/finding techniques are described in \ref{NETWORKDECOMPO
\label{fig:tdh} \label{fig:tdh}
\end{figure} \end{figure}
%%
%% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT
%% this study needs to use this term to keep the interested/in context.
The term `sub-system' is typically used in top down methodologies.
It has two equivalents in FMMD. The initial phase, where it is called
a functional~group, and the analysed phase where it is called a derived~component.
The term sub-system will be used alongside both functional~group and derived~component where necessary.
\subsection{Top-Down System De-Composition} \subsection{Top-Down System De-Composition}
A top down fault analysis system will take a system and divide it into A top down fault analysis system will take a system and divide it into