450 lines
18 KiB
TeX
450 lines
18 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}
|
|
We can assign an attribute of abstraction level to
|
|
components $\alpha$, 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.
|
|
|
|
The function $fm$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$.
|
|
|
|
$$ fm: \mathcal{FG} \rightarrow \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
|
|
%%
|
|
|
|
\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}
|
|
|
|
\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$ }
|
|
\ENDFOR
|
|
|
|
\STATE {let $F=fm(FG)$ be a 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 could be formed from single failure modes or failure modes in combination.
|
|
Let $TC$ be the set of test cases associated with the functional group $FG$.
|
|
|
|
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$
|
|
|
|
given by
|
|
|
|
$$ dtc(F) = TC $$
|
|
|
|
%%
|
|
%% Algorithm 2
|
|
%%
|
|
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg2}
|
|
\caption{Determine Test Cases: dtc: (F) } \label{alg22}
|
|
\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 ) $}
|
|
\ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $}
|
|
\COMMENT { Test cases must be unique }
|
|
\ENDFOR
|
|
|
|
|
|
\IF{Single fault checking}
|
|
\STATE { let $f$ represent a component failure mode }
|
|
%\ENSURE { That all failure modes are represented in at least one test case }
|
|
\ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
|
|
\COMMENT { This corresponds to checking that at least each failure mode is considered at
|
|
least once in the analysis; more rigorous cardinality constraint
|
|
checks may be required for some safety standards}
|
|
\ENDIF
|
|
|
|
\IF{Double fault checking}
|
|
\STATE { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group }
|
|
%\ENSURE { That all failure modes are represented in at least one test case }
|
|
\ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ }
|
|
\COMMENT { This corresponds to checking that each possible double failure mode is considered
|
|
as a test case; more rigorous cardinality constraint
|
|
checks may be required for some safety standards. Note if both failure modes
|
|
in the check are sourced from the same component $c$, the test case is impossible
|
|
under unitary state failure mode conditions}
|
|
\ENDIF
|
|
|
|
\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 $R$ be a set of 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
|
|
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 \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}
|
|
\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 the functional~group failure mode
|
|
the test case failure modes will cause.
|
|
%
|
|
%
|
|
In the case of a simple
|
|
electronic circuit, we could calculate the effect on voltages
|
|
within the circuit given certain component failure modes, for instance.
|
|
The affect of these unusual volatges would then be a failure
|
|
mode of the functional group and become the result of the test case.
|
|
When each test case has been analysed, we have a set of
|
|
results. These are the failure modes of the functional group.
|
|
|
|
Once a functional group has been analysed, it can be re-used in
|
|
any other design that uses it.
|
|
Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$
|
|
inputs), 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 $SP$ be the family of symptom sets for the functional group $FG$.
|
|
|
|
$$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{$sp_l \in \mathcal{P} R$} \COMMENT{Select 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} \mapsto \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 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 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 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 likelihood of the component failures,
|
|
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
|
|
|
|
|
|
\vspace{40pt}
|
|
%\today
|
|
|