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 Clark 2010-09-13 08:39:53 +01:00
commit 4abf1b73ee
5 changed files with 171 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
fmmdset/fmmdset.tex
View File

@ -163,7 +163,7 @@ and let the set of all possible failure modes be $\mathcal{F}$.
We can define a function $fm$
\begin{equation}
fm : \mathcal{C} \mapsto \mathcal{P}\mathcal{F}
fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}
\end{equation}
defined by, where C is a component and F is a set of failure modes.
@ -219,20 +219,25 @@ Consider a simple {\fg} $ FG^0_1 $ derived from two base components $C^0_1,C^0_
We can apply $\bowtie$ to the {\fg} $FG$
and it will return a {\dc} at abstraction level 1 (with an index of 1 for completeness)
$$ \bowtie( FG^0_1 ) = C^1_1 $$
$$ \bowtie fm(( FG^0_1 )) = C^1_1 $$
to look at this analysis process in more detail.
By way of exqample applying ${fm}$ to obtain the failure modes $f_N$
By way of example applying ${fm}$ to obtain the failure modes $f_N$
$$ {fm}(C^0_1) = \{ f_1, f_2 \} $$
$$ {fm}(C^0_2) = \{ f_3, f_4, f_5 \} $$
And overloading $fm$ to find the flat set of failure modes from a {\fg}
The analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}.
$$ {fm}{FG^0_1} = \{ s_6, s_7, s_8 \} $$
The symptom extraction process is now applied
i.e. the analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}
and determines the failure modes of the {\fg}..
The result of this process will be a set of derived failure modes.
Let these be $ \{ s_6, s_7, s_8 \} $.
For this example, let these be $ \{ s_6, s_7, s_8 \} $.
We can now create a {\dc} $C^1_1$ with this set of failure modes.
Thus:

6
mybib.bib
View File

@ -5,6 +5,12 @@
% $Id: mybib.bib,v 1.3 2009/11/28 20:05:52 robin Exp $
@ARTICLE{caninauto,
AUTHOR = "H. Zeltwanger",
TITLE = "Single Processor implementation of the CANopen Safety Protocol",
JOURNAL = "CAN in Automation (CiA)",
YEAR = "2008"
}
@ARTICLE{valueoflife,
AUTHOR = "W.K. Viscusi",

22
statistics/statistics.tex
View File

@ -47,6 +47,28 @@ Impact of boiler going down, no CO2 primary coolant available, possible reactor
For the Brewery, safety is of the highest importance.
For the Nuclear power station
\section{Terms and Concepts in \\ Safety Critical Engineering}
\subsection{Safety Relevant Data Object}
A Safety Relevant Data Object (SRDO)\cite{caninauto}, is a data structure describing the status of
a particular feature or attribute of a safety critical system.
For instance, in a burner this could be a flame signal value, or in a nuclear powerstation
the measure neutron flux.
\subsection{Safety relevant Object Validation Time}
Safety times can be given for SRDO's; these are termed Safety Related Object Validation Times (SROVT's)\cite{caninauto}. For instance were
a flame to fail in operation in a gas burner
standards state \cite{en298} that the gas may not continue to be fed into the
furnace for more than three seconds.
We can say that the SROVT for a flame signal in a gas burner is 3 seconds.
\subsection{Single and Double Failure Modes}
A Safety critical system must self check within the relevant SROVT's.
On detecting a failure mode it must react appropriately.
Consider the case though where two failures occurr within the
time windows of their SROVT's. We can term this a double simultaneous failure mode.
To take an extreme example, were the checking function/mechanism and the object under supervision
to fail within the SROVT, it may be impossible to detect the failure.
\section{Interfacing}
Mech - elec - sw

115
symptom_ex_process/algorithm.tex
View File

@ -15,11 +15,16 @@ and converts it to a derived~component/sub-system $DC$.
Note that
$DC$ is a derived component at a higher level of fault analysis abstraction
than the functional~group it was derived from.
However, it can still be treated
Thus, it can be treated
as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels}
We can assign an attribute of abstraction level to
components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$).
We can assign an attribute of abstraction level $\alpha$ to
components, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$).
For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$
the resulting derived~component will have an $\alpha$ value
@ -65,7 +70,7 @@ From the earlier definition of the function `fm':
The function $fm$ applied to a component returns the failure modes for that component.
The function $fm$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.
The function $fm$ takes a functional group $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.
$$ fm: \mathcal{FG} \rightarrow \mathcal{F}$$
@ -86,11 +91,13 @@ $$fm(FG) = F$$
\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 { $ F := \emptyset $} \COMMENT{Clear the set of failure modes}
\FORALL { $c \in FG $ }
\REQUIRE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\; fm(c) \neq \emptyset$ }
\STATE{ $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ }
\ENDFOR
\STATE {let $F=fm(FG)$ be a set of all failure modes to consider for the functional~group $FG$}
\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}
\RETURN { $F$ }
@ -116,7 +123,7 @@ From the failure modes associated with the functional~group
we now need to determine test cases.
The test cases are collections of failure modes.
These could be formed from single failure modes or failure modes in combination.
Let $TC$ be the set of test cases associated with the functional group $FG$.
Let $TC$ be the set of test cases, which hold combinations of failure modes $F$ (associated with the functional group $FG$).
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$
@ -128,6 +135,11 @@ $$ dtc(F) = TC $$
%% Algorithm 2
%%
%%
%% Maybe need to iterate through each failure mode, adding a new test case
%% this would build up all single fault test cases.
%%
\begin{algorithm}[h+]
~\label{alg2}
@ -136,45 +148,82 @@ $$ dtc(F) = TC $$
\REQUIRE {F is a flat set of failure modes }
\STATE { All test cases are now chosen by the investigating engineer(s). Typically all single
\STATE { All test cases are chosen by the investigating engineer(s). Typically all single
component failures are investigated
with some specially selected combination faults}
\STATE { Let $TC$ be a set of test cases }
\STATE { Let $TC$ be the set of test cases }
\STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$}
\COMMENT { Each set $tc_j$ is a `test case' }
%\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique}
\STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases}
\STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases}
\FORALL { $ f \in F $ }
\STATE{$ tc_j := f $} \COMMENT{ Assign one test case per single fault mode }
\STATE{ $ j := j + 1 $}
\ENDFOR
\STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes }
\IF{DoubleFaultChecking}
\STATE { Let $ptc$ be a provisional test case }
\FORALL { $ f1,f2 \in F $ }
\STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make a provisional test case}
%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
%% OK maybe you can't have comments after IF: half an hour wasted...
\IF { $ \mathcal{ISUNITARYSTATE}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant}
\STATE{ $ j := j + 1 $} % latex bug hunt game what fun ! #2
\STATE { $ tc_j := ptc $}
\STATE { $ TC := TC \cup tc_j $ }
\ENDIF
\ENDFOR
\ENDIF
\FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ }
%%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case}
\IF { $\mathcal{CHOSEN}(ptc) \wedge ptc \not\in TC \wedge \mathcal{ISUNITARYSTATE}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC}
\STATE{ $ j := j + 1 $} % latex bug hunt game #1
\STATE { $ tc_j := ptc $}
\STATE { $ TC := TC \cup tc_j $ }
\ENDIF
\ENDFOR
\FORALL { $tc_j \in TC$ }
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
\ENSURE {$ tc_j \in \mathcal{P}(F))$}
\ENSURE {$ tc_j \in \mathcal{P}(F) $ } % \mathcal{P}(F)$}
\COMMENT { require that the test case is a member of the powerset of $F$ }
%\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
\ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $}
\COMMENT { Test cases must be unique }
\ENDFOR
\IF{Single fault checking}
\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
least once in the analysis; more rigorous cardinality constraint
checks may be required for some safety standards}
\ENDIF
\IF{Double fault checking}
\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
as a test case; more rigorous cardinality constraint
checks may be required for some safety standards. Note if both failure modes
in the check are sourced from the same component $c$, the test case is impossible
under unitary state failure mode conditions}
\ENDIF
%
% \IF{Single fault checking}
% \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
% least once in the analysis; more rigorous cardinality constraint
% checks may be required for some safety standards}
% \ENDIF
%
% \IF{Double fault checking}
% \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
% as a test case; more rigorous cardinality constraint
% checks may be required for some safety standards. Note if both failure modes
% in the check are sourced from the same component $c$, the test case is impossible
% under unitary state failure mode conditions}
% \ENDIF
%
\RETURN $TC$
% some european standards
% imply checking all double fault combinations\cite{en298} }
@ -211,7 +260,7 @@ $$ atc(TC) = R $$
\caption{Analyse Test Cases: atc(TC) } \label{alg33}
\begin{algorithmic}[1]
\STATE { let r be a `test case result'}
\STATE { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions}
\STATE { Let the function $Analyse : tc \rightarrow r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions}
\STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$}
\FORALL { $tc_j \in TC$ }
\STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group}
@ -392,7 +441,7 @@ to form functional~groups at higher levels of failure~mode~abstraction.
\section{Linking all five stages}
$$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$
$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
\begin{algorithm}[h+]

82
symptom_ex_process/process.tex
View File

@ -11,23 +11,26 @@ Once we know how a functional~group can fail, we can treat it as a component or
with its own set of failure modes.
\paragraph{FMEA applied to the Functional Group}
As the functional~group is a set of components, the failure~modes
that we have to consider are all the failure modes of its components.
Each failure mode (or combination of) investigated is termed a `test case'.
Each `test case' is analysed.
As the functional~group contains a set of components, the failure~modes
that we have to consider are all the failure modes of its components, as
developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$.
The aim here is to build `test cases', combinations of failure~modes
to use as failure~mode analysis scenarios.
%Each failure mode (or combination of) investigated is termed a `test case'.
%Each `test case' is analysed.
%
The component failure modes in each test case
are examined with respect to their effect on the functional~group.
%
The aim of this analysis is to find out how the functional~group reacts
to each of the test case conditions.
The aim of this analysis is to find out how the functional~group fails given
the test case conditions, defined in each test case.
The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
%
\paragraph{Symptom Identification}
When all `test~cases' have been analysed, a second phase is applied.
When all `test~cases' have been analysed, a second phase can be actioned. % applied.
%
This looks at the results of the `test~cases' as symptoms
of the sub-system.
@ -42,10 +45,16 @@ will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected.
We can now consider the functional~group as a component and the common symptoms as its failure modes.
Looking at the functional group perspective failure modes, we can collect
some of these into common `symptoms'. Some test cases may cause
unique failure modes at the functional group level. These can be termed
lone symptoms.
The common symptoms of failure and lone~symptoms are identified and collected.
We can now consider the functional~group as a component and the symptoms as its failure modes.
Note that here, because the process is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
from the components in a functional~group have been handled\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}.
Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes.
\ref{requirement at the start}
@ -70,10 +79,12 @@ form `test cases'.
% \item Draw these as contours on a diagram
% \item Where si,ultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case
\item Using the `test cases' determine their effects on the failure~mode behaviour of the functional group. This is a human process involving detailed analysis of the failure modes oin the test case on the operation of the {\fg}.
\item Collect common~symptoms. i.e. determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
\item Using the `test cases' as scenarios to examine the effects of component failures
we determine failure~mode behaviour of the functional group.
This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}.
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
\item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.
\item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component.
\item A new `derived component' can now be created where each common~symptom, or lone symptom is a failure~mode of this new component.
\end{itemize}
@ -107,7 +118,7 @@ and let the set of all possible failure modes be $\mathcal{F}$.
We can define a function $fm$
\begin{equation}
{fm} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F}
{fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}
\end{equation}
defined by (where $C$ is a component and $F$ is a set of failure modes):
@ -122,26 +133,27 @@ $$ fm(C_1) = \{ a_1, a_2, a_3 \} $$
$$ fm(C_2) = \{ b_1, b_2 \} $$
$$ fm(C_3) = \{ c_1, c_2 \} $$
where $a_n,b_n,c_n$ are component failure modes.
\paragraph{Finding all failure modes within the functional group}
For fmMD failure mode analysis, we need to consider the failure modes
from all the components in the functional group as a flat set.
This can be found by applying function $fm$ to all the components
in the functional~group and taking the union of them thus:
in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus:
$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} fm(C_j) $$
$$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$
We can actually overload the notation for the function fm
We overload the notation for the function $fm$
and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
\begin{equation}
fm : FG \mapsto \mathcal{F}
fm : FG \rightarrow \mathcal{F}
\end{equation}
Applied to the functional~group $FG$ in the example above:
\begin{equation}
fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}
fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}.
\end{equation}
This can be seen as all the failure modes that can affect the failure mode group $FG$.
@ -178,12 +190,13 @@ $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline
Table~\ref{tab:fexsymptoms} shows the analysis process.
As we are only looking at single fault possibilities for this example each failure mode
is represented by a test~case.
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}.
Chosen combinations of 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 ($g$'s).
The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed.
For the sake of example, let us consider the fault symptoms of $\{g_2, g_4, g_5\}$ to be
For the sake of example, let us consider the fault symptoms of the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$
As failure modes, these
identical from the perspective of the functional~group.
That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes
occur, is going to be the same.
@ -191,7 +204,7 @@ For example, in our CD player example, this could mean the common symptom `no\_s
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 only 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 = \{g_2, g_4, g_5\}$.
@ -203,13 +216,13 @@ but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$.
We now have in $SP1$, $SP2$ and $SP3$ 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$.
We can place these in a set of symptoms.
%
$$ SP = \{ SP1, SP2, SP3 \} $$
$$ SP = \{ SP1, SP2, SP3 \}. $$
%
%
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}
These three symptoms can be considered the set of failure modes for the functional~group, if
we treat it as though it were a {\em black box}
or a {\em component} to be used in higher level designs.
%
The next stage of the process could be applied automatically.
@ -223,7 +236,10 @@ $$ fm(DC) = \{ SP1, SP2, SP3 \} $$
Note that $g_6$ has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component.
i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$.
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 once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}!
Because the process can be computerised, we can easily flag symptoms that have not been
included a derived component.
% Aw boring ! no jokes ?
% 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 once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}!
%
\ifthenelse {\boolean{paper}}
{
@ -244,11 +260,13 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
\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
Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process,
and DCFM to represent derived component failure modes, we may now
write
$$
\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
\bowtie : DCFM \rightarrow DerivedComponent
$$
%
%\begin{equation}
@ -257,7 +275,9 @@ $$
%
%or applying the function $fm$ to obtain the $FG_{cfm}$ set
%
Where DC is a derived component, and FG is a functional group:
To put this in context, where DC is a derived component, and FG is a functional group,
we may state the process of extracting a set of failure modes from a functional
group thus:
\begin{equation}
\bowtie(fm(FG)) = DC