.
This commit is contained in:
parent
c5d4e340e8
commit
9e0a4a0e48
@ -61,7 +61,43 @@ The algorithm, represented by the symbol `$\bowtie$', has been broken down into
|
|||||||
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
|
|
||||||
|
|
||||||
|
|
||||||
|
\section{Algorithmic Description of Symptom Abstraction}
|
||||||
|
%\clearpage
|
||||||
|
$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
|
||||||
|
|
||||||
|
\begin{algorithm}[h+]
|
||||||
|
|
||||||
|
\caption{Derive new `Component' from Functional Group: $\bowtie(FG)$} \label{alg66}
|
||||||
|
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
|
||||||
|
\STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group }
|
||||||
|
\STATE {TC = dtc (F)} \COMMENT{ determine all test cases } %to apply to the functional group }
|
||||||
|
\STATE {R = atc (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group }
|
||||||
|
\STATE {SP = fcs (R)} \COMMENT{ find common symptoms }%of failure for the functional group }
|
||||||
|
\STATE {DC = cdc (SP)} \COMMENT{ create a derived component }
|
||||||
|
|
||||||
|
\RETURN $DC$
|
||||||
|
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
The symptom abstraction methodology allows us to take a functional group of components,
|
||||||
|
analyse the failure
|
||||||
|
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
|
||||||
|
The checks and constraints applied in the algorithm ensure that all component failure
|
||||||
|
modes are covered.
|
||||||
|
This process provides the analysis `step' to building a hierarchical failure mode model
|
||||||
|
from the bottom-up.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
%\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
|
||||||
@ -69,46 +105,59 @@ analysis.
|
|||||||
From the earlier definition of the function `fm':
|
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$ applied to a component returns the failure modes for that component.
|
||||||
|
Thus its domain is the set of all components $\mathcal{C}$ and its range
|
||||||
|
is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$.
|
||||||
|
|
||||||
The function $fm$ takes a functional group $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.
|
$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
||||||
|
|
||||||
$$ fm: \mathcal{FG} \rightarrow \mathcal{F}$$
|
A {\fg} is a collection of components such that $\mathcal{FG} \in \mathcal{P}\,\mathcal{C}$.
|
||||||
|
|
||||||
|
The function $fm$ can be overloaded with a functional group $\mathcal{FG}$ as its domain
|
||||||
|
and the powerset of all failure modes as its range.
|
||||||
|
|
||||||
|
|
||||||
%Let $FG$ be the set of components in the functional group under analysis, and $c$
|
$$ fm: \mathcal{FG} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
||||||
%be components that are members of it. This function returns a flat set of failure modes $F$.
|
|
||||||
given by
|
|
||||||
$$fm(FG) = F$$
|
|
||||||
%%
|
|
||||||
%% Algorithm 1
|
|
||||||
%%
|
|
||||||
|
|
||||||
\begin{algorithm}[h+]
|
|
||||||
~\label{alg1}
|
|
||||||
\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11}
|
|
||||||
\begin{algorithmic}[1]
|
|
||||||
\REQUIRE {FG is a set of components (a functional~group)}
|
|
||||||
|
|
||||||
\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
|
|
||||||
|
|
||||||
\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}
|
|
||||||
|
|
||||||
|
|
||||||
\RETURN { $F$ }
|
|
||||||
|
|
||||||
%\hline
|
|
||||||
%
|
%
|
||||||
\end{algorithmic}
|
%%Let $FG$ be the set of components in the functional group under analysis, and $c$
|
||||||
\end{algorithm}
|
%%be components that are members of it. This function returns a flat set of failure modes $F$.
|
||||||
|
%given by
|
||||||
Algorthim \ref{alg11} has taken a functional~group $FG$ and returned a set of failure~modes $F=fm(FG)$
|
%$$fm(FG) = F$$
|
||||||
(given that each component has a known set of failure~modes).
|
%%%
|
||||||
|
%%% Algorithm 1
|
||||||
|
%%%
|
||||||
|
%
|
||||||
|
%%%-
|
||||||
|
%%%- A such that B is C
|
||||||
|
%%%-
|
||||||
|
%
|
||||||
|
%
|
||||||
|
%\begin{algorithm}[h+]
|
||||||
|
% ~\label{alg1}
|
||||||
|
%\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11}
|
||||||
|
%\begin{algorithmic}[1]
|
||||||
|
%\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. }
|
||||||
|
%\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big( fm(c) \neq \emptyset \big)$.}
|
||||||
|
%
|
||||||
|
%%\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 $ }
|
||||||
|
%\STATE { $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ }
|
||||||
|
%\ENDFOR
|
||||||
|
%
|
||||||
|
%\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}
|
||||||
|
%
|
||||||
|
%
|
||||||
|
%\RETURN { $F$ }
|
||||||
|
%
|
||||||
|
%%\hline
|
||||||
|
%%
|
||||||
|
%\end{algorithmic}
|
||||||
|
%\end{algorithm}
|
||||||
|
%
|
||||||
|
%Algorthim \ref{alg11} has taken a functional~group $FG$ and returned a set of failure~modes $F=fm(FG)$
|
||||||
|
%(given that each component has a known set of failure~modes).
|
||||||
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
|
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
|
||||||
in the analysis stages.
|
in the analysis stages.
|
||||||
|
|
||||||
@ -116,14 +165,16 @@ in the analysis stages.
|
|||||||
|
|
||||||
|
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
\clearpage
|
%\clearpage
|
||||||
\subsection{ Determine Test Cases}
|
\subsection{ Determine Test Cases}
|
||||||
|
|
||||||
From the failure modes associated with the functional~group
|
From the failure modes associated with the functional~group
|
||||||
we now need to determine test cases.
|
we now need to determine test cases.
|
||||||
The test cases are collections of failure modes.
|
The test cases are collections of failure modes.
|
||||||
These could be formed from single failure modes or failure modes in combination.
|
These can be formed from single failure modes or failure modes in combination.
|
||||||
Let $TC$ be the set of test cases, which hold combinations of failure modes $F$ (associated with the functional group $FG$).
|
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$
|
||||||
|
be the set of all failure modes.
|
||||||
|
%(associated with the functional group $FG$).
|
||||||
|
|
||||||
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$
|
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$
|
||||||
|
|
||||||
@ -131,6 +182,10 @@ given by
|
|||||||
|
|
||||||
$$ dtc(F) = TC $$
|
$$ dtc(F) = TC $$
|
||||||
|
|
||||||
|
The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
|
||||||
|
a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes)
|
||||||
|
The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component.
|
||||||
|
This is discussed in section \ref{unitarystate}.
|
||||||
%%
|
%%
|
||||||
%% Algorithm 2
|
%% Algorithm 2
|
||||||
%%
|
%%
|
||||||
@ -165,16 +220,17 @@ $$ dtc(F) = TC $$
|
|||||||
\STATE{ $ j := j + 1 $}
|
\STATE{ $ j := j + 1 $}
|
||||||
\ENDFOR
|
\ENDFOR
|
||||||
|
|
||||||
\STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes }
|
%\STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes }
|
||||||
|
|
||||||
\IF{DoubleFaultChecking}
|
\IF{DoubleFaultChecking}
|
||||||
|
|
||||||
\STATE { Let $ptc$ be a provisional test case }
|
%\STATE { Let $ptc$ be a provisional test case }
|
||||||
\FORALL { $ f1,f2 \in F $ }
|
\FORALL { $ f1,f2 \in F $ }
|
||||||
\STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make a provisional test case}
|
\STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make $ptc$ a provisional test case}
|
||||||
%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
|
%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
|
||||||
|
% ESCPECIALLY IN THIS FUCKING ENVIRONMENT 22OCT2010
|
||||||
%% OK maybe you can't have comments after IF: half an hour wasted...
|
%% 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}
|
\IF { $ {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{ $ j := j + 1 $} % latex bug hunt game what fun ! #2
|
||||||
\STATE { $ tc_j := ptc $}
|
\STATE { $ tc_j := ptc $}
|
||||||
\STATE { $ TC := TC \cup tc_j $ }
|
\STATE { $ TC := TC \cup tc_j $ }
|
||||||
@ -182,27 +238,23 @@ $$ dtc(F) = TC $$
|
|||||||
\ENDFOR
|
\ENDFOR
|
||||||
\ENDIF
|
\ENDIF
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ }
|
\FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ }
|
||||||
%%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case}
|
%%\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}
|
\IF { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {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{ $ j := j + 1 $} % latex bug hunt game #1
|
||||||
\STATE { $ tc_j := ptc $}
|
\STATE { $ tc_j := ptc $}
|
||||||
\STATE { $ TC := TC \cup tc_j $ }
|
\STATE { $ TC := TC \cup tc_j $ }
|
||||||
\ENDIF
|
\ENDIF
|
||||||
\ENDFOR
|
\ENDFOR
|
||||||
|
|
||||||
\FORALL { $tc_j \in TC$ }
|
%\FORALL { $tc_j \in TC$ }
|
||||||
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
|
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
|
||||||
\ENSURE {$ tc_j \in \mathcal{P}(F) $ } % \mathcal{P}(F)$}
|
%
|
||||||
\COMMENT { require that the test case is a member of the powerset of $F$ }
|
% Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt
|
||||||
|
%\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 \; 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 }
|
||||||
\COMMENT { Test cases must be unique }
|
%\ENDFOR
|
||||||
\ENDFOR
|
|
||||||
%
|
%
|
||||||
% \IF{Single fault checking}
|
% \IF{Single fault checking}
|
||||||
% \STATE { let $f$ represent a component failure mode }
|
% \STATE { let $f$ represent a component failure mode }
|
||||||
@ -224,6 +276,8 @@ $$ dtc(F) = TC $$
|
|||||||
% under unitary state failure mode conditions}
|
% under unitary state failure mode conditions}
|
||||||
% \ENDIF
|
% \ENDIF
|
||||||
%
|
%
|
||||||
|
\ENSURE { $ \forall j1,j2 \in J \; such\; that\; j1 \neq j2 \big( tc_{j1} \neq tc_{j2} \big) $}
|
||||||
|
\ENSURE { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ }
|
||||||
\RETURN $TC$
|
\RETURN $TC$
|
||||||
% some european standards
|
% some european standards
|
||||||
% imply checking all double fault combinations\cite{en298} }
|
% imply checking all double fault combinations\cite{en298} }
|
||||||
@ -239,9 +293,6 @@ The next stage is to analyse the effect of each test case on the functional grou
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
\clearpage
|
\clearpage
|
||||||
\subsection{ Analyse Test Cases}
|
\subsection{ Analyse Test Cases}
|
||||||
@ -249,9 +300,9 @@ The next stage is to analyse the effect of each test case on the functional grou
|
|||||||
%% Algorithm 3
|
%% Algorithm 3
|
||||||
%%
|
%%
|
||||||
The test cases are now analysed for their impact on the behaviour of the functional~group.
|
The test cases are now analysed for their impact on the behaviour of the functional~group.
|
||||||
Let $R$ be a set of test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
|
Let $\mathcal{R}$ be the set of all test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
|
||||||
|
|
||||||
$$ atc: \mathcal{TC} \rightarrow \mathcal{R} $$A
|
$$ atc: \mathcal{TC} \rightarrow \mathcal{R} $$
|
||||||
given by
|
given by
|
||||||
$$ atc(TC) = R $$
|
$$ atc(TC) = R $$
|
||||||
|
|
||||||
@ -283,27 +334,33 @@ Each test case is examined in detail.
|
|||||||
%
|
%
|
||||||
%
|
%
|
||||||
Ideally calculations or simulations
|
Ideally calculations or simulations
|
||||||
are performed to determine the functional~group failure mode
|
are performed to determine how the failure modes in each test case will
|
||||||
the test case failure modes will cause.
|
affect the functional~group.
|
||||||
%
|
%
|
||||||
|
When the all the test cases have been anaslysed
|
||||||
|
we will have a `result' for each `test case'.
|
||||||
|
Each result will be described w.r.t. to the {\fg}, not the components failure modes
|
||||||
|
in its test case.
|
||||||
%
|
%
|
||||||
In the case of a simple
|
%In the case of a simple
|
||||||
electronic circuit, we could calculate the effect on voltages
|
%electronic circuit, we could calculate the effect on voltages
|
||||||
within the circuit given certain component failure modes, for instance.
|
%within the circuit given a certain component failure mode, for instance.
|
||||||
The affect of these unusual voltages 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.
|
Thus we will have a set of
|
||||||
Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$
|
results corresponding to our test cases. These share a common index value ($j$ in the algorithm description).
|
||||||
inputs), and in this case the analysis would only need to be performed once.
|
These results 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), and in this case the analysis would only need to be performed once.
|
||||||
|
%
|
||||||
|
|
||||||
|
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
\clearpage
|
%\clearpage
|
||||||
\subsection{ Find Common Symptoms}
|
\subsection{ Find Common Symptoms}
|
||||||
%%
|
%%
|
||||||
%% Algorithm 4
|
%% Algorithm 4
|
||||||
@ -315,59 +372,61 @@ Each result from the preceding stage is examined and collected
|
|||||||
into common symptom sets.
|
into common symptom sets.
|
||||||
That is to say, each result in a symptom set, from the perspective of the functional group
|
That is to say, each result in a symptom set, from the perspective of the functional group
|
||||||
has the same failure symptom.
|
has the same failure symptom.
|
||||||
Let set $SP$ be the family of symptom sets for the functional group $FG$.
|
Let set $\mathcal{SP}$ be the set of all symptoms,
|
||||||
|
and $\mathcal{R}$ be the set of all test case results.
|
||||||
|
|
||||||
$$fcs: \mathcal{R} \rightarrow \mathcal{SP} $$
|
$$fcs: \mathcal{R} \rightarrow \mathcal{SP} $$
|
||||||
given by
|
given by
|
||||||
$$ fcs(R) = SP $$
|
$$ fcs(R) = SP $$
|
||||||
|
|
||||||
\begin{algorithm}[h+]
|
%\begin{algorithm}[h+]
|
||||||
~\label{alg4}
|
% ~\label{alg4}
|
||||||
|
|
||||||
\caption{Find Common Symptoms: fcs($R$)} \label{alg44}
|
|
||||||
|
|
||||||
\begin{algorithmic}[1]
|
|
||||||
|
|
||||||
|
|
||||||
%\REQUIRE {All failure modes for the components in $fm_i = fm(fg_i)$}
|
|
||||||
\STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$}
|
|
||||||
\STATE {Let $SP$ be a set whose members are the indexed `symptoms' $sp_l$}
|
|
||||||
\COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
|
|
||||||
\STATE{$SP := 0$} \COMMENT{ initialise the `symptom family set'}
|
|
||||||
%
|
%
|
||||||
%\COMMENT{This corresponds to a fault symptom of the functional group $FG$}
|
%\caption{Find Common Symptoms: fcs($R$)} \label{alg44}
|
||||||
%\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode}
|
%
|
||||||
\REPEAT
|
%\begin{algorithmic}[1]
|
||||||
|
%
|
||||||
\STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'}
|
%
|
||||||
\STATE{$sp_l \in \mathcal{P} R$} \COMMENT{Select common symptoms from the results set}
|
% %\REQUIRE {All failure modes for the components in $fm_i = fm(fg_i)$}
|
||||||
\STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set}
|
% \STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$}
|
||||||
\STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP}
|
% \STATE {Let $SP$ be a set whose members are the indexed `symptoms' $sp_l$}
|
||||||
\STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect}
|
% \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
|
||||||
|
% \STATE{$SP := 0$} \COMMENT{ initialise the `symptom family set'}
|
||||||
\UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom}
|
|
||||||
|
|
||||||
%% \FORALL { $ r_j \in R$ }
|
|
||||||
%% \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ }
|
|
||||||
%% %\STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ }
|
|
||||||
%% \COMMENT{ Collect common symptoms.
|
|
||||||
%% Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it
|
|
||||||
%%causes in the functional group $FG$}
|
|
||||||
%% %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $}
|
|
||||||
%%
|
%%
|
||||||
%% \ENSURE {$ \forall a \in sp_l \;such\;that\; \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
|
% %\COMMENT{This corresponds to a fault symptom of the functional group $FG$}
|
||||||
%% \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set }
|
% %\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode}
|
||||||
%%
|
%\REPEAT
|
||||||
%% \ENDFOR
|
%
|
||||||
\STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents}
|
% \STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'}
|
||||||
|
% \STATE{$Let \; sp_l \in \mathcal{P} R$ such that R is in a common symptom group } \COMMENT{determine common symptoms from the results set}
|
||||||
|
% \STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set}
|
||||||
|
% \STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP}
|
||||||
|
% \STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect}
|
||||||
|
%
|
||||||
|
%\UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom}
|
||||||
|
%
|
||||||
|
%%% \FORALL { $ r_j \in R$ }
|
||||||
|
%%% \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ }
|
||||||
|
%%% %\STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ }
|
||||||
|
%%% \COMMENT{ Collect common symptoms.
|
||||||
|
%%% Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it
|
||||||
|
%%%causes in the functional group $FG$}
|
||||||
|
%%% %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $}
|
||||||
|
%%%
|
||||||
|
%%% \ENSURE {$ \forall a \in sp_l \;such\;that\; \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
|
||||||
|
%%% \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set }
|
||||||
|
%%%
|
||||||
|
%%% \ENDFOR
|
||||||
|
% \STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents}
|
||||||
|
%
|
||||||
|
% \RETURN $SP$
|
||||||
|
%%\hline
|
||||||
|
%
|
||||||
|
%\end{algorithmic}
|
||||||
|
%\end{algorithm}
|
||||||
|
|
||||||
\RETURN $SP$
|
%Algorithm \ref{alg44}
|
||||||
%\hline
|
This raises the failure~mode abstraction level, $\alpha$.
|
||||||
|
|
||||||
\end{algorithmic}
|
|
||||||
\end{algorithm}
|
|
||||||
|
|
||||||
Algorithm \ref{alg44} 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.
|
||||||
@ -412,62 +471,35 @@ given by
|
|||||||
|
|
||||||
$$ cdc(SP) = DC $$
|
$$ cdc(SP) = DC $$
|
||||||
|
|
||||||
\begin{algorithm}[h+]
|
The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$.
|
||||||
~\label{alg5}
|
|
||||||
|
|
||||||
\caption{Create Derived Component: cdc(SP) } \label{alg55}
|
%\begin{algorithm}[h+]
|
||||||
|
% ~\label{alg5}
|
||||||
|
%
|
||||||
|
%\caption{Create Derived Component: cdc(SP) } \label{alg55}
|
||||||
|
%
|
||||||
|
%\begin{algorithmic}[1]
|
||||||
|
%
|
||||||
|
% \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 DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
||||||
|
% \STATE { $DC := DC \cup f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
||||||
|
%
|
||||||
|
% \ENDFOR
|
||||||
|
% \ENSURE { $fm(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes}
|
||||||
|
% \RETURN DC
|
||||||
|
%%\hline
|
||||||
|
%
|
||||||
|
%\end{algorithmic}
|
||||||
|
%\end{algorithm}
|
||||||
|
|
||||||
\begin{algorithmic}[1]
|
%Algorithm \ref{alg55}
|
||||||
|
The function $cdc$ is the final stage in the process. We now have a
|
||||||
\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 DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
|
||||||
\STATE { $DC := DC \cup f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
|
||||||
|
|
||||||
\ENDFOR
|
|
||||||
\ENSURE { $fm(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes}
|
|
||||||
\RETURN DC
|
|
||||||
%\hline
|
|
||||||
|
|
||||||
\end{algorithmic}
|
|
||||||
\end{algorithm}
|
|
||||||
|
|
||||||
Algorithm \ref{alg55} is the final stage in the process. We now have a
|
|
||||||
derived~component $DC$, which has its own set of failure~modes. This can now be
|
derived~component $DC$, which has its own set of failure~modes. This can now be
|
||||||
used in with other components (or derived~components)
|
used in with other components (or derived~components)
|
||||||
to form functional~groups at higher levels of failure~mode~abstraction.
|
to form functional~groups at higher levels of failure~mode~abstraction.
|
||||||
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
|
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
|
||||||
|
|
||||||
\section{Linking all five stages}
|
|
||||||
|
|
||||||
$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
|
|
||||||
|
|
||||||
\begin{algorithm}[h+]
|
|
||||||
|
|
||||||
\caption{Derive new `Component' from Functional Group: $\bowtie(FG)$} \label{alg66}
|
|
||||||
|
|
||||||
\begin{algorithmic}[1]
|
|
||||||
|
|
||||||
\STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group }
|
|
||||||
\STATE {TC = dtc (F)} \COMMENT{ determine all test cases } %to apply to the functional group }
|
|
||||||
\STATE {R = atc (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group }
|
|
||||||
\STATE {SP = fcs (R)} \COMMENT{ find common symptoms }%of failure for the functional group }
|
|
||||||
\STATE {DC = cdc (SP)} \COMMENT{ create a derived component }
|
|
||||||
|
|
||||||
\RETURN $DC$
|
|
||||||
|
|
||||||
\end{algorithmic}
|
|
||||||
\end{algorithm}
|
|
||||||
|
|
||||||
The symptom abstraction methodology allows us to take a functional group of components,
|
|
||||||
analyse the failure
|
|
||||||
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
|
|
||||||
The checks and constraints applied in the algorithm ensure that all component failure
|
|
||||||
modes are covered.
|
|
||||||
This process provides the analysis `step' to building a hierarchical failure mode model
|
|
||||||
from the bottom-up.
|
|
||||||
|
|
||||||
\subsection{Hierarchical Simplification}
|
\subsection{Hierarchical Simplification}
|
||||||
|
|
||||||
Because symptom abstraction collects fault modes, the number of faults to handle decreases
|
Because symptom abstraction collects fault modes, the number of faults to handle decreases
|
||||||
@ -481,7 +513,7 @@ $$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT
|
|||||||
\normalsize
|
\normalsize
|
||||||
The number of causes for any of these faults is very large.
|
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.
|
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 faults goes down.
|
But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level.
|
||||||
|
|
||||||
\subsection{Traceable Fault Modes}
|
\subsection{Traceable Fault Modes}
|
||||||
|
|
||||||
@ -492,6 +524,9 @@ minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
|
|||||||
analysing the statistical likelihood of the component failures,
|
analysing the statistical likelihood of the component failures,
|
||||||
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
|
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
|
||||||
|
|
||||||
|
%%%\section{Example Symptom Extraction}
|
||||||
|
%% There already is an example of the process before the algorithmic description
|
||||||
|
%%%This is a simplified version of the pt100 example in chapter \ref{pt100}.
|
||||||
|
|
||||||
\vspace{40pt}
|
\vspace{40pt}
|
||||||
%\today
|
%\today
|
||||||
|
|||||||
532
symptom_ex_process/algorithm.tex.old
Normal file
532
symptom_ex_process/algorithm.tex.old
Normal file
@ -0,0 +1,532 @@
|
|||||||
|
%%
|
||||||
|
%
|
||||||
|
%
|
||||||
|
% OBSOLETE DO NOT EDIT.
|
||||||
|
% This is the one with the simple functions described as algorithms
|
||||||
|
%
|
||||||
|
%% 23OCT2010
|
||||||
|
%%
|
||||||
|
|
||||||
|
%\section{A Formal Algorithmic Description of `Symptom Abstraction'}
|
||||||
|
\section{Algorithmic Description}
|
||||||
|
|
||||||
|
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 derived~component/sub-system $DC$.
|
||||||
|
%The sub-system $SS$ is a collection
|
||||||
|
%of failure~modes of the sub-system.
|
||||||
|
Note that
|
||||||
|
$DC$ is a derived component at a higher level of fault analysis abstraction
|
||||||
|
than the functional~group it was derived from.
|
||||||
|
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 $\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
|
||||||
|
one higher that the highest $\alpha$ value of any of the components
|
||||||
|
in the functional group used to derive it.
|
||||||
|
Thus a derived component sourced from base components
|
||||||
|
will have an $\alpha$ value of 1.
|
||||||
|
%
|
||||||
|
%If $DC$ were to be included in a functional~group,
|
||||||
|
%that functional~group must be considered to be at a higher level of
|
||||||
|
%abstraction than a base level functional~group.
|
||||||
|
%
|
||||||
|
%In fact, if the abstraction level is enumerated,
|
||||||
|
%the functional~group must take the abstraction level
|
||||||
|
%of the highest assigned to any of its components.
|
||||||
|
%
|
||||||
|
%With a derived component $DC$ having an abstraction level
|
||||||
|
The attribute $\alpha$ can be used to track the
|
||||||
|
level of fault abstraction of components in an FMMD hierarchy. Because base and derived components
|
||||||
|
are collected to form functional groups, a hierarchy is
|
||||||
|
naturally formed with the abstraction levels increasing with each tier.
|
||||||
|
|
||||||
|
|
||||||
|
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
|
||||||
|
% \IF{$c.\alpha > \alpha_{max}$}
|
||||||
|
% $\alpha_{max} = c.\alpha$
|
||||||
|
% \ENDIF
|
||||||
|
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
|
||||||
|
%\ENDFOR
|
||||||
|
|
||||||
|
|
||||||
|
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}
|
||||||
|
|
||||||
|
The first stage is to find the failure modes to consider for
|
||||||
|
analysis.
|
||||||
|
From the earlier definition of the function `fm':
|
||||||
|
|
||||||
|
The function $fm$ applied to a component returns the failure modes for that component.
|
||||||
|
Thus its domain is the set of all components $\mathcal{C}$ and its range
|
||||||
|
is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$.
|
||||||
|
|
||||||
|
$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
||||||
|
|
||||||
|
A {\fg} is a collection of components such that $\mathcal{FG} \in \mathcal{P}\,\mathcal{C}$.
|
||||||
|
|
||||||
|
The function $fm$ can be overloaded with a functional group $\mathcal{FG}$ as its domain
|
||||||
|
and the powerset of all failure modes as its range.
|
||||||
|
|
||||||
|
|
||||||
|
$$ fm: \mathcal{FG} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
||||||
|
|
||||||
|
|
||||||
|
%Let $FG$ be the set of components in the functional group under analysis, and $c$
|
||||||
|
%be components that are members of it. This function returns a flat set of failure modes $F$.
|
||||||
|
given by
|
||||||
|
$$fm(FG) = F$$
|
||||||
|
%%
|
||||||
|
%% Algorithm 1
|
||||||
|
%%
|
||||||
|
|
||||||
|
%%-
|
||||||
|
%%- A such that B is C
|
||||||
|
%%-
|
||||||
|
|
||||||
|
|
||||||
|
\begin{algorithm}[h+]
|
||||||
|
~\label{alg1}
|
||||||
|
\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11}
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. }
|
||||||
|
\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big( fm(c) \neq \emptyset \big)$.}
|
||||||
|
|
||||||
|
%\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 $ }
|
||||||
|
\STATE { $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ }
|
||||||
|
\ENDFOR
|
||||||
|
|
||||||
|
\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}
|
||||||
|
|
||||||
|
|
||||||
|
\RETURN { $F$ }
|
||||||
|
|
||||||
|
%\hline
|
||||||
|
%
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
Algorthim \ref{alg11} has taken a functional~group $FG$ and returned a set of failure~modes $F=fm(FG)$
|
||||||
|
(given that each component has a known set of failure~modes).
|
||||||
|
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
|
||||||
|
in the analysis stages.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
|
\clearpage
|
||||||
|
\subsection{ Determine Test Cases}
|
||||||
|
|
||||||
|
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 can be formed from single failure modes or failure modes in combination.
|
||||||
|
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$
|
||||||
|
be the set of all failure modes.
|
||||||
|
%(associated with the functional group $FG$).
|
||||||
|
|
||||||
|
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$
|
||||||
|
|
||||||
|
given by
|
||||||
|
|
||||||
|
$$ dtc(F) = TC $$
|
||||||
|
|
||||||
|
The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
|
||||||
|
a human operator and are additional to those chosen by the automated process (i.e.e they are special case test cases involving multiple failure modes)
|
||||||
|
The function \textbf{unitarystate} means that the test case has no pairs of failure modes sourced from the component.
|
||||||
|
This is discussed in section \ref{unitarystate}.
|
||||||
|
%%
|
||||||
|
%% 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}
|
||||||
|
\caption{Determine Test Cases: dtc: (F) } \label{alg22}
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
|
||||||
|
\REQUIRE {F is a non empty flat set of failure modes }
|
||||||
|
|
||||||
|
\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 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 $ptc$ a provisional test case}
|
||||||
|
%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
|
||||||
|
% ESCPECIALLY IN THIS FUCKING ENVIRONMENT 22OCT2010
|
||||||
|
%% OK maybe you can't have comments after IF: half an hour wasted...
|
||||||
|
\IF { $ {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 { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {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} $}
|
||||||
|
%
|
||||||
|
% Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt
|
||||||
|
%\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 ) $}
|
||||||
|
%\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
|
||||||
|
%
|
||||||
|
\ENSURE { $ \forall j1,j2 \in J \; such\; that\; j1 \neq j2 \big( tc_{j1} \neq tc_{j2} \big) $}
|
||||||
|
\ENSURE { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ }
|
||||||
|
\RETURN $TC$
|
||||||
|
% some european standards
|
||||||
|
% imply checking all double fault combinations\cite{en298} }
|
||||||
|
|
||||||
|
%\hline
|
||||||
|
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
Algorithm \ref{alg22} has taken the set of failure modes $ F=fm(FG) $ and returned a set of test cases $TC$.
|
||||||
|
The next stage is to analyse the effect of each test case on the functional group.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
|
\clearpage
|
||||||
|
\subsection{ Analyse Test Cases}
|
||||||
|
%%
|
||||||
|
%% Algorithm 3
|
||||||
|
%%
|
||||||
|
The test cases are now analysed for their impact on the behaviour of the functional~group.
|
||||||
|
Let $\mathcal{R}$ be the set of all test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
|
||||||
|
|
||||||
|
$$ atc: \mathcal{TC} \rightarrow \mathcal{R} $$
|
||||||
|
given by
|
||||||
|
$$ atc(TC) = R $$
|
||||||
|
|
||||||
|
\begin{algorithm}[h+]
|
||||||
|
~\label{alg3}
|
||||||
|
\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 \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}
|
||||||
|
%\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R}
|
||||||
|
\STATE{ $ R := R \cup rc_j $ } \COMMENT{Add $rc_j$ to the set R}
|
||||||
|
\ENDFOR
|
||||||
|
|
||||||
|
\RETURN $R$
|
||||||
|
|
||||||
|
%\hline
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
Algorithm \ref{alg33} 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 how the failure modes in each test case will
|
||||||
|
affect the functional~group.
|
||||||
|
%
|
||||||
|
When the all the test cases have been anaslysed
|
||||||
|
we will have a `result' for each `test case'.
|
||||||
|
Each result will be described w.r.t. to the {\fg}, not the components failure modes
|
||||||
|
in its test case.
|
||||||
|
%
|
||||||
|
%In the case of a simple
|
||||||
|
%electronic circuit, we could calculate the effect on voltages
|
||||||
|
%within the circuit given a certain component failure mode, for instance.
|
||||||
|
%%
|
||||||
|
|
||||||
|
%
|
||||||
|
Thus we will have a set of
|
||||||
|
results corresponding to our test cases. These share a common index value ($j$ in the algorithm description).
|
||||||
|
These results 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), and in this case the analysis would only need to be performed once.
|
||||||
|
%
|
||||||
|
|
||||||
|
|
||||||
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
|
\clearpage
|
||||||
|
\subsection{ Find Common Symptoms}
|
||||||
|
%%
|
||||||
|
%% 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.
|
||||||
|
This 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 $\mathcal{SP}$ be the set of all symptoms,
|
||||||
|
and $\mathcal{R}$ be the set of all test case results.
|
||||||
|
|
||||||
|
$$fcs: \mathcal{R} \rightarrow \mathcal{SP} $$
|
||||||
|
given by
|
||||||
|
$$ fcs(R) = SP $$
|
||||||
|
|
||||||
|
\begin{algorithm}[h+]
|
||||||
|
~\label{alg4}
|
||||||
|
|
||||||
|
\caption{Find Common Symptoms: fcs($R$)} \label{alg44}
|
||||||
|
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
|
||||||
|
|
||||||
|
%\REQUIRE {All failure modes for the components in $fm_i = fm(fg_i)$}
|
||||||
|
\STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$}
|
||||||
|
\STATE {Let $SP$ be a set whose members are the indexed `symptoms' $sp_l$}
|
||||||
|
\COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
|
||||||
|
\STATE{$SP := 0$} \COMMENT{ initialise the `symptom family set'}
|
||||||
|
%
|
||||||
|
%\COMMENT{This corresponds to a fault symptom of the functional group $FG$}
|
||||||
|
%\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode}
|
||||||
|
\REPEAT
|
||||||
|
|
||||||
|
\STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'}
|
||||||
|
\STATE{$Let \; sp_l \in \mathcal{P} R$ such that R is in a common symptom group } \COMMENT{determine common symptoms from the results set}
|
||||||
|
\STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set}
|
||||||
|
\STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP}
|
||||||
|
\STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect}
|
||||||
|
|
||||||
|
\UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom}
|
||||||
|
|
||||||
|
%% \FORALL { $ r_j \in R$ }
|
||||||
|
%% \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ }
|
||||||
|
%% %\STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ }
|
||||||
|
%% \COMMENT{ Collect common symptoms.
|
||||||
|
%% Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it
|
||||||
|
%%causes in the functional group $FG$}
|
||||||
|
%% %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $}
|
||||||
|
%%
|
||||||
|
%% \ENSURE {$ \forall a \in sp_l \;such\;that\; \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
|
||||||
|
%% \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set }
|
||||||
|
%%
|
||||||
|
%% \ENDFOR
|
||||||
|
\STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents}
|
||||||
|
|
||||||
|
\RETURN $SP$
|
||||||
|
%\hline
|
||||||
|
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
Algorithm \ref{alg44} 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}}
|
||||||
|
{
|
||||||
|
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, for the derived
|
||||||
|
component created in the next stage.
|
||||||
|
}
|
||||||
|
{
|
||||||
|
Note ensuring that no result belongs to more than one symptom
|
||||||
|
set enforces the `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 !!!
|
||||||
|
|
||||||
|
|
||||||
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
|
\clearpage
|
||||||
|
\subsection{ Create Derived Component}
|
||||||
|
%%
|
||||||
|
%% Algorithm 5
|
||||||
|
%%
|
||||||
|
This final stage, is the creation of the derived component.
|
||||||
|
This derived component may now be used to build
|
||||||
|
new functional groups at higher levels of fault abstraction.
|
||||||
|
Let $DC$ be a derived component with its own set of failure~modes.
|
||||||
|
|
||||||
|
$$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} $$
|
||||||
|
|
||||||
|
given by
|
||||||
|
|
||||||
|
$$ cdc(SP) = DC $$
|
||||||
|
|
||||||
|
\begin{algorithm}[h+]
|
||||||
|
~\label{alg5}
|
||||||
|
|
||||||
|
\caption{Create Derived Component: cdc(SP) } \label{alg55}
|
||||||
|
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
|
||||||
|
\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 DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
||||||
|
\STATE { $DC := DC \cup f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
||||||
|
|
||||||
|
\ENDFOR
|
||||||
|
\ENSURE { $fm(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes}
|
||||||
|
\RETURN DC
|
||||||
|
%\hline
|
||||||
|
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
Algorithm \ref{alg55} is the final stage in the process. We now have a
|
||||||
|
derived~component $DC$, which has its own set of failure~modes. This can now be
|
||||||
|
used in with other components (or derived~components)
|
||||||
|
to form functional~groups at higher levels of failure~mode~abstraction.
|
||||||
|
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
|
||||||
|
|
||||||
|
\section{Linking all five stages}
|
||||||
|
|
||||||
|
$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
|
||||||
|
|
||||||
|
\begin{algorithm}[h+]
|
||||||
|
|
||||||
|
\caption{Derive new `Component' from Functional Group: $\bowtie(FG)$} \label{alg66}
|
||||||
|
|
||||||
|
\begin{algorithmic}[1]
|
||||||
|
|
||||||
|
\STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group }
|
||||||
|
\STATE {TC = dtc (F)} \COMMENT{ determine all test cases } %to apply to the functional group }
|
||||||
|
\STATE {R = atc (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group }
|
||||||
|
\STATE {SP = fcs (R)} \COMMENT{ find common symptoms }%of failure for the functional group }
|
||||||
|
\STATE {DC = cdc (SP)} \COMMENT{ create a derived component }
|
||||||
|
|
||||||
|
\RETURN $DC$
|
||||||
|
|
||||||
|
\end{algorithmic}
|
||||||
|
\end{algorithm}
|
||||||
|
|
||||||
|
The symptom abstraction methodology allows us to take a functional group of components,
|
||||||
|
analyse the failure
|
||||||
|
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
|
||||||
|
The checks and constraints applied in the algorithm ensure that all component failure
|
||||||
|
modes are covered.
|
||||||
|
This process provides the analysis `step' to building a hierarchical failure mode model
|
||||||
|
from the bottom-up.
|
||||||
|
|
||||||
|
\subsection{Hierarchical Simplification}
|
||||||
|
|
||||||
|
Because symptom abstraction collects fault modes, the number of faults to handle decreases
|
||||||
|
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
|
||||||
|
is significantly less than the sum of its component failure modes.
|
||||||
|
A sound system might have, for instance only four faults at its highest or system level,
|
||||||
|
\small
|
||||||
|
$$ 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.
|
||||||
|
|
||||||
|
\subsection{Traceable Fault Modes}
|
||||||
|
|
||||||
|
Because the fault modes are determined from the bottom-up, the causes
|
||||||
|
for all high level faults naturally form trees.
|
||||||
|
These trees can be traversed to produce
|
||||||
|
minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
|
||||||
|
analysing the statistical likelihood of the component failures,
|
||||||
|
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
|
||||||
|
|
||||||
|
\section{Example Symptom Extraction}
|
||||||
|
|
||||||
|
This is a simplified version of the pt100 example in chapter \ref{pt100}.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\vspace{40pt}
|
||||||
|
%\today
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user