From 907ebd3b9949e381cc7f1e75196b37efa5ad1d41 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Wed, 4 Aug 2010 20:44:11 +0100 Subject: [PATCH] from the A27 refugee --- symptom_ex_process/algorithm.tex | 60 +++++++++++++++++++++++++------- symptom_ex_process/process.tex | 13 +++++-- symptom_ex_process/topbot.tex | 8 +++++ 3 files changed, 66 insertions(+), 15 deletions(-) diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 8d933ab..b60019e 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -51,13 +51,13 @@ naturally formed with the abstraction levels increasing with each tier. %\ENDFOR -The algorithm, representing the function $\bowtie$, has been broken down into five consecutive stages. -These are described using the Algorithm environment in the next section \ref{algorithms}. +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}. By defining the process and describing it using set theory, constraints and verification checks in the process are stated formally. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %\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 analysis. @@ -156,7 +156,7 @@ $$ DTC(F) = TC $$ \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 { $ \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 @@ -165,7 +165,7 @@ $$ DTC(F) = TC $$ \ENDIF \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 { $ \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 @@ -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. +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 @@ -235,9 +259,14 @@ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional g %% %% Algorithm 4 %% -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. -Let set $SP$ be the set of symptoms for the functional group $FG$. +%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. +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} $$ given by @@ -279,25 +308,32 @@ causes in the functional group $FG$} \end{algorithmic} \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 functional~group level. We now have a set $SP$ of the symptoms of failure. \ifthenelse {\boolean{paper}} { -%CUNT VIM just went and wrote random shit did you not Component failure modes must be mutually exclusive. 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. 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 -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 !!! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 8a762ab..82b6b4b 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -73,7 +73,7 @@ form `test cases'. - +\clearpage \section{A theoretical `Derived Component' example} 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} }. + +\ifthenelse {\boolean{paper}} +{ +\subsection{Define Failure mode function FM} +} +{ To re-cap from the definitions chapter \ref{chap:definitions}. +} Let the set of all possible components be $\mathcal{C}$ 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\}$. % These can then be joined to form a spider. 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}, 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. Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index 15f73ba..c4b141d 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -55,6 +55,14 @@ Top down fault isolation/finding techniques are described in \ref{NETWORKDECOMPO \label{fig:tdh} \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} A top down fault analysis system will take a system and divide it into