Robin Clark
5dce3ea282
Each test case must be examined in the light of any applied states or environmental conditions applied to it. For instance a test circuit that has two positions has two states. Each one must be applied to all the test cases. In the case of the NASA O ring this could have been the environmental temperature range behaviour etc
535 lines
21 KiB
TeX
535 lines
21 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.
|
|
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.
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
|
|
\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}
|
|
|
|
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 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
|
|
%%
|
|
|
|
|
|
%%
|
|
%% 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}
|
|
\FORALL { Environmental and Specific 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
|
|
\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}
|
|
This 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 $$
|
|
|
|
The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$.
|
|
|
|
%\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}
|
|
The function $cdc$ 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.
|
|
\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}
|
|
%% 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}
|
|
%\today
|
|
|