A Fish algorithm comments
This commit is contained in:
Robin Clark
parent
b3c39d692a
commit
097c23b4e9
@ -759,11 +759,11 @@ probability theory~\cite{probstat}.
|
||||
% here.
|
||||
|
||||
What is required is to define a property for
|
||||
a set of failure modes where only one failure mode can be active at a time;
|
||||
a set of failure modes $F$ where only one failure mode can be active at a time;
|
||||
or borrowing from the terms of statistics, the failure mode being an event that is mutually exclusive
|
||||
with a set $F$.
|
||||
within the set $F$.
|
||||
We can define a set of failure mode sets called $\mathcal{U}$ to represent this
|
||||
property for a set of failure modes.
|
||||
property. % for a set of failure modes.
|
||||
%
|
||||
% \begin{definition}
|
||||
% We can define a set $\mathcal{U}$ which is a set of sets of failure modes, where
|
||||
@ -817,6 +817,7 @@ we state this formally;
|
||||
|
||||
That is to say that it is impossible that any pair of failure modes can be active at the same time
|
||||
for the failure mode set $F$ to exist in the family of sets $\mathcal{U}$.
|
||||
%
|
||||
Note where there are more than two failure~modes,
|
||||
by banning any pairs from being active at the same time,
|
||||
we have banned larger combinations as well.
|
||||
|
||||
@ -3,14 +3,14 @@
|
||||
%\label{sec:symptom_abstraction}
|
||||
\label{sec:algorithmfmmd}
|
||||
|
||||
This chapter defines the process for performing one stage of the FMMD process i.e.
|
||||
This appendix formalises the process for performing one stage of the FMMD process %i.e.
|
||||
from a given {\fg} to creating a {\dc}.
|
||||
%
|
||||
The FMMD process is then examined in greater %levels of
|
||||
detail and described with set theory in
|
||||
an algorithmic context.
|
||||
%
|
||||
The intention for defining FMMD in algorithmic and set theoretic terms, is to provide
|
||||
The intention for defining FMMD in algorithmic and set theoretic terms is to provide
|
||||
a solid specification for the process that could guide a software implementation.% for it.
|
||||
|
||||
|
||||
@ -27,12 +27,12 @@ a solid specification for the process that could guide a software implementation
|
||||
|
||||
|
||||
\nocite{safeware}
|
||||
\section{Overview of the FMMD analysis Process}
|
||||
The FMMD process is described in chapter~\ref{sec:chap4},
|
||||
to re-cap, FMMD has four main stages:
|
||||
\section{Overview of the FMMD analysis process}
|
||||
The FMMD process is described in chapter~\ref{sec:chap4}.
|
||||
To re-cap, FMMD has four main stages:
|
||||
\begin{itemize}
|
||||
\item collection of components to form {\fgs},
|
||||
\item applying FMEA to the {\fg},
|
||||
\item applying FMEA to the {\fgs},
|
||||
\item collecting common symptoms from the FMEA results,
|
||||
\item creating a {\dc} representing the failure mode behaviour of the {\fg}.
|
||||
\end{itemize}
|
||||
@ -56,7 +56,7 @@ This process allows us to modularise and thus simplify FMEA analysis of systems.
|
||||
%below.
|
||||
|
||||
|
||||
\paragraph{FMEA applied to the {\fg}: choosing `test~cases'.}
|
||||
\paragraph{FMEA applied to the {\fg}: choosing test~cases.}
|
||||
As a {\fg} is a collection of components, the failure~modes
|
||||
that we have to consider are the failure modes of its components.
|
||||
%, as
|
||||
@ -87,10 +87,10 @@ Each test case must also be considered for all %applied/
|
||||
operational states and
|
||||
%in the for the case of each applied states or
|
||||
environmental conditions to which it may be exposed. In this way, all possible
|
||||
failure mode behaviour due to all the conditions that can be applied for a test case will be examined.
|
||||
failure mode behaviour, due to all the conditions that can be applied for all the test~cases will be examined.
|
||||
%
|
||||
\paragraph{Symptom Identification.}
|
||||
When all `test~cases' have been analysed, we have a set of FMEA results. % applied.
|
||||
When all test~cases have been analysed, we have a set of FMEA results for the given {\fg}. % applied.
|
||||
These results can be viewed as symptoms of failure of the {\fg}.
|
||||
%
|
||||
%This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system.
|
||||
@ -142,7 +142,7 @@ It is possible here for an automated system to flag un-handled failure modes.
|
||||
%\ref{requirement at the start}
|
||||
|
||||
|
||||
\section{A single stage of the FMMD process}
|
||||
\section{Expanding on a single stage of the FMMD process}
|
||||
|
||||
%\paragraph{To analyse a base level Derived~Component/sub-system}
|
||||
|
||||
@ -208,7 +208,7 @@ We can define a function $fm$ which returns the failure modes for a given compo
|
||||
%$$ fm ( C ) = F $$
|
||||
|
||||
We overload the notation for the function $fm$
|
||||
and define it for the set components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
|
||||
and define it for the set of components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
|
||||
|
||||
\begin{equation}
|
||||
fm : FG \rightarrow \mathcal{F} .
|
||||
@ -230,7 +230,9 @@ $$
|
||||
|
||||
|
||||
%\section{A Formal Algorithmic Description of `Symptom Abstraction'}
|
||||
\section{Algorithmic Description}
|
||||
|
||||
\section{Algorithmic Description of Symptom Abstraction}
|
||||
%\section{Algorithmic Description}
|
||||
\label{sec:symptomabs}
|
||||
The algorithm for {\em symptom abstraction} is described in
|
||||
this section
|
||||
@ -247,12 +249,12 @@ using set theory and procedural descriptions.
|
||||
% %Thus, ke
|
||||
% $DC$ can now be treated
|
||||
% as a component with a known set of failure modes.
|
||||
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
|
||||
%\ForAll { $c \in FG $ } \Comment{Find the highest abstraction level of any component in the functional group}
|
||||
% \IF{$c.\abslev > \abslev_{max}$}
|
||||
% $\abslev_{max} = c.\abslev$
|
||||
% \ENDIF
|
||||
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
|
||||
%\ENDFOR
|
||||
%\State { $ FM(c) \in FG_{cfm} $ } \Comment {Collect all failure modes from each component into the set $FM_{cfm}$}
|
||||
%\EndFor
|
||||
%
|
||||
By defining the process and describing it using set theory, constraints and
|
||||
verification checks %in the process
|
||||
@ -262,28 +264,26 @@ The algorithm, represented by the symbol `$\derivec$', is described using five a
|
||||
%These are described using the Algorithm environment in the next section \ref{algorithms}.
|
||||
%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
As a function $\derivec$ has the following signature:
|
||||
|
||||
|
||||
|
||||
\section{Algorithmic Description of Symptom Abstraction}
|
||||
%\clearpage
|
||||
$$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$
|
||||
|
||||
\begin{algorithm}[h+]
|
||||
|
||||
\caption{Derive new `Component' from {\fg}: $\derivec(FG)$} \label{alg66}
|
||||
$$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} .$$
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Derive new `Component' $DC$ from a given {\fg} $FG$: $\derivec(FG)$}
|
||||
\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 giving a set of test cases $TC$ } %to apply to the functional group }
|
||||
\STATE {R = atc (TC)} \COMMENT{ analyse the test cases giving a set of FMEA results $R$}%, for failure mode behaviour of the functional~group }
|
||||
\STATE {SP = fcs (R)} \COMMENT{ find common symptoms, aggregate results from R giving a set of symptoms $SP$}%of failure for the functional group }
|
||||
\STATE {DC = cdc (SP)} \COMMENT{ create a derived component }
|
||||
\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 giving a set of test cases $TC$ } %to apply to the functional group }
|
||||
\State {R = atc (TC)} \Comment{ analyse the test cases giving a set of FMEA results $R$}%, for failure mode behaviour of the functional~group }
|
||||
\State {SP = fcs (R)} \Comment{ find common symptoms, aggregate results from R giving a set of symptoms $SP$}%of failure for the functional group }
|
||||
\State {DC = cdc (SP)} \Comment{ create a derived component }
|
||||
|
||||
\RETURN $DC$
|
||||
\State \textbf{return} $DC$
|
||||
|
||||
\end{algorithmic}
|
||||
\label{alg66}
|
||||
\end{algorithm}
|
||||
|
||||
The symptom abstraction process allows us to take a {\fg} of components,
|
||||
@ -299,28 +299,29 @@ 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
|
||||
analysis,
|
||||
using 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 $G$ such that $\mathcal{G} \in \mathcal{P}\,\mathcal{C}$.
|
||||
%
|
||||
The function $fm$ can be overloaded with a {\fg} $\mathcal{G}$ as its domain
|
||||
and the power-set of all failure modes as its range.
|
||||
%
|
||||
%
|
||||
$$ fm: \mathcal{G} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
||||
%
|
||||
%
|
||||
using the earlier definition of the function $fm$ applied to
|
||||
all components within the given {\fg}.
|
||||
%
|
||||
% 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 $G$ such that $\mathcal{G} \in \mathcal{P}\,\mathcal{C}$.
|
||||
% %
|
||||
% The function $fm$ can be overloaded with a {\fg} $\mathcal{G}$ as its domain
|
||||
% and the power-set of all failure modes as its range.
|
||||
% %
|
||||
% %
|
||||
% $$ fm: \mathcal{G} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
||||
% %
|
||||
% %
|
||||
% %
|
||||
The next task is to formulate `test~cases'. These are a collection of combinations of these {\fms} and will be used
|
||||
in the analysis stages.
|
||||
|
||||
@ -362,89 +363,92 @@ all failure modes in components in the {\fg} are included in at least one test~c
|
||||
%
|
||||
%%
|
||||
%
|
||||
%{ \footnotesize
|
||||
\begin{algorithm}[h+]
|
||||
~\label{alg2}
|
||||
\caption{Determine Test Cases: dtc: (F) } \label{alg22}
|
||||
\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
|
||||
\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 { Let $TC$ be the set of test cases }
|
||||
\State { Let $tc_j$ be a set of component failure modes where $j$ is an index of $J$}
|
||||
\Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \in \mathbb{N}_{+}$}
|
||||
|
||||
\State { $ TC := \emptyset $ } \Comment{Initialise set of test cases}
|
||||
\State { $ j := 1 $ } \Comment{Initialise index of test cases}
|
||||
|
||||
\STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases}
|
||||
\STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases}
|
||||
\ForAll { $ f \in F $ } \Comment{ Assign one test case per single fault mode }
|
||||
\State{$ tc_j := f $}
|
||||
\State { $ TC := TC \cup tc_j $ } \Comment{ place this test case into the set TC }
|
||||
\State{ $ j := j + 1 $}
|
||||
\EndFor
|
||||
|
||||
\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 }
|
||||
%\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
|
||||
\If{DoubleFaultChecking} \Comment{ Assign one test case per valid double fault mode } %\State { Let $ptc$ be a provisional test case }
|
||||
\ForAll { $ f_1,f_2 \in F $ }
|
||||
\State { $ ptc := \{ f_1,f_2 \} $ } \Comment{Make $ptc$ a provisional test case}
|
||||
%\State { FINDING ERRORS IN LATEX SOURCE IS challenging}
|
||||
% ESCPECIALLY IN THIS 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
|
||||
\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 $ } \Comment{ place this test case into the set TC }
|
||||
\EndIf
|
||||
\EndFor
|
||||
\EndIf
|
||||
%
|
||||
% \ForAll { $ ptc \in \mathcal{P}(F) $ } \Comment{for all subsets of 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$ }
|
||||
%\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$ }
|
||||
%\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
|
||||
%\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
|
||||
%\algstore
|
||||
%\algrestore
|
||||
%
|
||||
% \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$
|
||||
\algstore{myalg}
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
\begin{algorithm}
|
||||
\begin{algorithmic} [1]
|
||||
\algrestore{myalg}
|
||||
\Ensure { $ \forall j_1,j_2 \in J \; such\; that\; j_1 \neq j_2 \big( tc_{j_1} \neq tc_{j_2} \big) $} \Comment{Ensure test cases are distinct}
|
||||
\Ensure { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ } \Comment{Ensure each test case is a subset of F}
|
||||
|
||||
\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 single failure mode is
|
||||
included as a test case.}
|
||||
\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 (see section~\ref{sec:unitarystate}) is included
|
||||
as a test case.}
|
||||
\EndIf
|
||||
\State \textbf{return} $TC$
|
||||
% some european standards
|
||||
% imply checking all double fault combinations\cite{en298} }
|
||||
|
||||
@ -452,6 +456,7 @@ all failure modes in components in the {\fg} are included in at least one test~c
|
||||
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
%} % end footnotesize
|
||||
|
||||
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 {\fg}.
|
||||
@ -477,17 +482,19 @@ $$ atc(TC) = R .$$
|
||||
~\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 component 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$ }
|
||||
\FORALL { Environmental and Specific Applied States }
|
||||
\STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Failure Mode Effects Analysis applied in the context of the {\fg}}
|
||||
%\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
|
||||
\ENDFOR
|
||||
\RETURN $R$
|
||||
\State { let r be a `test case result'}
|
||||
\State { define the function $Analyse : tc \rightarrow r $ }
|
||||
\Comment { This analysis is a human activity, FMEA, i.e. examining the component 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$ }
|
||||
\ForAll { Environmental and Specific Applied States }
|
||||
\State { $ rc_j = Analyse(tc_j) $} \Comment {this is FMEA applied in the localised context of the {\fg}}
|
||||
%\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
|
||||
\EndFor
|
||||
\State \textbf{return} $R$
|
||||
|
||||
%\hline
|
||||
\end{algorithmic}
|
||||
@ -562,38 +569,38 @@ $$ fcs(R) = SP .$$
|
||||
%
|
||||
%
|
||||
% %\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'}
|
||||
% \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}
|
||||
% %\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}
|
||||
% \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}
|
||||
%\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.
|
||||
%%% \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 }
|
||||
%%% \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}
|
||||
%%% \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$
|
||||
% \Return $SP$
|
||||
%%\hline
|
||||
%
|
||||
%\end{algorithmic}
|
||||
@ -654,15 +661,15 @@ The new component will have a set of failure modes that correspond to the common
|
||||
%
|
||||
%\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}
|
||||
% \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
|
||||
% \EndFor
|
||||
% \ENSURE { $fm(DC) \neq \emptyset$ } \Comment{Ensure that DC has a known set of failure modes}
|
||||
% \Return DC
|
||||
%%\hline
|
||||
%
|
||||
%\end{algorithmic}
|
||||
@ -702,12 +709,13 @@ naturally formed with the abstraction levels increasing with each tier.
|
||||
|
||||
\subsection{Hierarchical Simplification}
|
||||
|
||||
Because symptom abstraction aggregates fault modes, the number of faults to handle should decrease
|
||||
Since symptom abstraction aggregates fault modes, the number of faults to handle should decrease
|
||||
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,
|
||||
To go back to the sound system analogy (see section~\ref{sec:cdplayer}), it may have
|
||||
only four faults at its highest or system level,
|
||||
\small
|
||||
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
|
||||
\normalsize
|
||||
@ -720,7 +728,7 @@ as is found in practise in real world systems.
|
||||
|
||||
\subsection{Traceable Fault Modes}
|
||||
|
||||
Because the fault modes are determined from the bottom-up, the causes
|
||||
Since the fault modes are determined from the bottom-up, the causes
|
||||
for all high level faults naturally form trees.
|
||||
%
|
||||
That is to say from the bottom-up causes become symptoms, which in the next level become causes as we traverse up the tree.
|
||||
|
||||
@ -8,8 +8,10 @@
|
||||
\usetikzlibrary{shapes.gates.logic.US,trees,positioning,arrows}
|
||||
\usepackage{subfigure}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
%\usepackage{algcompatible}
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algorithmic}
|
||||
%\usepackage{algorithmicx}
|
||||
\usepackage{algpseudocode}
|
||||
\usepackage{lastpage}
|
||||
\usepackage{glossary}
|
||||
\renewcommand{\baselinestretch}{1.5}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user