325 lines
12 KiB
TeX
325 lines
12 KiB
TeX
|
|
|
|
%\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.
|
|
However, it can still be treated
|
|
as a component with a known set of failure modes.
|
|
\paragraph{Enumerating abstraction levels}
|
|
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.
|
|
%
|
|
$DC$ can be used as a system building block at a higher
|
|
level of fault abstraction. Because derived components
|
|
are collected to form functional groups, a converging hierarchy is
|
|
naturally formed with the abstraction level increasing with each tier.
|
|
|
|
|
|
The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other.
|
|
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 can be stated formally.
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}
|
|
|
|
The first stage is to find the failure modes to consider for
|
|
analysis.
|
|
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$.
|
|
|
|
$$ FM: \mathcal{FG} \mapsto \mathcal{F}$$
|
|
%%
|
|
%% Algorithm 1
|
|
%%
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs1}
|
|
\caption{FM( $FG$ )} \label{alg:sympabs11}
|
|
\begin{algorithmic}[1]
|
|
\REQUIRE {FG is a set of components}
|
|
|
|
\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 { Let $c$ represent a component}
|
|
|
|
\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG | FM(c) \neq \emptyset$ }
|
|
|
|
\STATE {let $F=FM(FG)$ be a set of all failure modes to consider for the functional~group $FG$}
|
|
|
|
%\STATE {Collect all failure modes from all the components in FG into the set $FG_{cfm}$}
|
|
%\FORALL { $c \in FG $ }
|
|
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
|
|
%\ENDFOR
|
|
|
|
\RETURN { $F$ }
|
|
|
|
%\hline
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Algorthim \ref{alg:sympabs11} has taken a functional~group $FG$ and returned a set of failure~modes $F=FM(FG)$ where each component has a known set of failure~modes.
|
|
The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used
|
|
in the analysis stages.
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ 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 could be formed from single failure modes or failure modes in combination.
|
|
Let $TC$ be the set of test cases associated withthe functional group $FG$.
|
|
|
|
$$ DTC: \mathcal{F} \mapsto \mathcal{TC} $$
|
|
|
|
%%
|
|
%% Algorithm 2
|
|
%%
|
|
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs2}
|
|
\caption{DTC: (F) } \label{alg:sympabs22}
|
|
\begin{algorithmic}[1]
|
|
|
|
\REQUIRE {F is a flat set of failure modes }
|
|
|
|
\STATE { All test cases are now 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_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}
|
|
|
|
\FORALL { $tc_j \in TC$ }
|
|
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
|
|
\ENSURE {$ tc_j \in \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 ) $}
|
|
\COMMENT { Test cases must be unique }
|
|
\ENDFOR
|
|
|
|
|
|
|
|
\STATE { let $f$ represet a component failure mode }
|
|
\ENSURE { That all failure modes are represented in at least one test case }
|
|
\ENSURE { $ \forall f | (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}
|
|
|
|
|
|
\RETURN $TC$
|
|
% some european standards
|
|
% imply checking all double fault combinations\cite{en298} }
|
|
|
|
%\hline
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Algorithm \ref{alg:sympabs22} 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{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases}
|
|
%%
|
|
%% Algorithm 3
|
|
%%
|
|
The test cases are now analysed for their impact on the behaviour of the functional~group.
|
|
Let $R$ be a set of results indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
|
|
|
|
$$ATC: \mathcal{TC} \mapsto \mathcal{R} $$
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs3}
|
|
\caption{ATC(TC) } \label{alg:sympabs33}
|
|
\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 { $ 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}
|
|
\ENDFOR
|
|
|
|
\RETURN $R$
|
|
|
|
%\hline
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case.
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ 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.
|
|
Let set $SP$ be the set of symptoms for the functional group $FG$.
|
|
|
|
$$FCS: \mathcal{R} \mapsto \mathcal{SP} $$
|
|
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs4}
|
|
|
|
\caption{FCS($R$)} \label{alg:sympabs44}
|
|
|
|
\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 sets $sp_l$}
|
|
\COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
|
|
%
|
|
%\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}
|
|
|
|
\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 ) $}
|
|
|
|
\REQUIRE {$ \forall a \in sp_l | \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{alg:sympabs44} raises the failure~mode abstraction level.
|
|
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.
|
|
|
|
|
|
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ 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} \mapsto \mathcal{DC} $$
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs5}
|
|
|
|
\caption{CDC(SP) } \label{alg:sympabs55}
|
|
|
|
\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}
|
|
\ENDFOR
|
|
\RETURN DC
|
|
%\hline
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Algorithm \ref{alg:sympabs55} 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} \mapsto \mathcal{DC} $$
|
|
|
|
\begin{algorithm}[h+]
|
|
|
|
\caption{$\bowtie(FG)$} \label{alg:sympabs66}
|
|
|
|
\begin{algorithmic}[1]
|
|
|
|
\STATE {F = FM (FG)}
|
|
\STATE {TC = DTC (F)}
|
|
\STATE {R = ATC (TC)}
|
|
\STATE {SP = FCS (R)}
|
|
\STATE {DC = CDC (SP)}
|
|
|
|
\RETURN $DC$
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
The symptom abstraction technique 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 naturally takes one 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. 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 causes caused the fault.
|
|
But as the hierarchy goes up in abstraction level, the number of faults goes down.
|
|
|
|
\subsection{Tracable 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 likelyhood of the component failures,
|
|
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
|
|
|
|
|
|
\vspace{40pt}
|
|
%\today
|
|
|