robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tidied algorithms

Browse Source
This commit is contained in:
Robin Clark 2010-06-21 14:24:31 +01:00
parent 4e7f73f6f5
commit 414903214c
1 changed files with 139 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

257
symptom_ex_process/symptom_ex_process_paper.tex
View File

@ -1,21 +1,22 @@
\ifthenelse {\boolean{paper}}
{
\begin{abstract}
In failure mode analysis, it is essential to
know the failure modes of the sub-systems and components used.
This paper outlines a technique for determining the failure modes of a sub-system given
its component parts.
%, and the failure modes of those parts.
its components.
This chapter describes a process for taking a functional group of components, applying FMEA analysis and then determining how that functional group can fail.
With this information, we can treat the functional group
as a component in its own right.
This new component is a derived component.
For a top down technique this would correspond to a low~level sub-system.
%The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model.
Once the failure modes have been determined for a sub-system/derived~component,
This derived component can be combined with others to form functional groups
this derived component can be combined with others to form functional groups
to model
higher level sub-systems/derived~components.
In this way a hierarchy to represent the fault behaviour
@ -36,6 +37,9 @@ automatically, where component failure mode statistics are available\cite{mil199
This paper focuses on the process of building the blocks, that are key to creating an FMMD hierarchy.
\end{abstract}
}
{}
%\clearpage
@ -48,7 +52,7 @@ A faulty piece of equipment is examined and will have a
symptom or specific fault. The suspected area or sub-system within the
equipment will next be looked into.
The trouble shooter will look for behaviour that is unusual or incorrect
to determine the next area or sub~system to look at, each time
to determine the next area or sub~system to look into, each time
moving to a more detailed lower level.
Specific measurements
and checks will be made, and finally a component or a low level sub-system
@ -57,18 +61,20 @@ A natural fault finding process is thus top~down.
\subsection{FMMD - Bottom~up Analysis}
The FMMD technique does not follow the `natural fault finding' or top down approach,
it instead works from the bottom up.
Starting with a collection of components that form
Starting with a collection of base~components that form
a simple functional group, the effect of all component error modes are
examined, as to their effect on the functional group.
The effects on the functional group can then be collected as common symptoms,
and now we may treat the functional group as a component. It has a known set of failure modes.
and now we may treat the functional group as a component as it has a known set of failure modes.
By reusing the `components' derived from functional~groups an entire
hierarichal failure mode mode of the system can be built.
By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment failure.
This means that at the design stage of a product all component failure
modes must be considered. The aim here is for complete failure mode coverage.
This also means that we can obtain statistical estimates based on the known reliabilities
of the components.
It also means that every component failure mode must at the very least be considered.
%It also means that every component failure mode must at the very least be considered.
\subsection{Static Analysis}
@ -79,7 +85,7 @@ software~inspections and project~management quality reviews are applied\cite{scc
Static testing is also applied. This is theoretical analysis of the design of the product from the safety
perspective.
Three main techniques are currenly used,
Three main techniques are currently used,
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
The technique outlined here aims to provide a mathematical frame work
to assist in the production of these three results of static analysis.
@ -113,15 +119,17 @@ CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
%and is the way in which FTA\cite{nucfta} analyses a System
%and breaks it down.
A sub-system will be composed of component parts, which
may themselves be sub-systems. However each `component part'
A sub-system will be composed of components, which
may themselves be sub-systems. However each `component'
will have a fault/failure behaviour and it should
always be possible to obtain a set of failure modes
for each `component'. In FMMD terms a sub-system is a derived component.
If we look at the sound system again as an
example; the CD~player could fail in serveral distinct ways, no matter
what has happened to it or has gone wrong inside it.
If we look at the sound system example,
the CD~player could fail in several distinct ways,
and this couldbe due to a large number of
component failure modes.
%no matter what has happened to it or has gone wrong inside it.
Using the reasoning that working from the bottom up forces the consideration of all possible
@ -129,8 +137,8 @@ component failures (which can be missed in a top~down approach)
we are presented with a problem. Which initial collections of base components should we choose ?
For instance in the CD~player example; to start at the bottom; we are presented with
a massive list of base~components, resistors, motors, user~switches, laser~diodes all sorts !
Clearly, working from the bottom~up we need to pick small
a massive list of base~components, resistors, motors, user~switches, laser~diodes, all sorts !
Clearly, working from the bottom~up, we need to pick small
collections of components that work together in some way.
These are termed `functional~groups'. For instance the circuitry that powers the laser diode
to illuminate the CD might contain a handful of components, and as such would make a good candidate
@ -138,11 +146,13 @@ to be one of the base level functional~groups.
In choosing the lowest level (base component) sub-systems we would look
for the smallest `functional~groups' of components within a system. A functional~group is a set of components that interact
for the smallest `functional~groups' of components within a system.
We can define a functional~group as a set of components that interact
to perform a specific function.
When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'.
We can now call our functional~group a sub-system. The goal here is to know how will behave under fault conditions !
We can now call our functional~group a sub-system or a derived~component.
The goal here is to know how it will behave under fault conditions !
%Imagine buying one such `sub~system' from a very honest vendor.
%One of those sir, yes but be warned it may fail in these distinct ways, here
%in the honest data sheet the set of failure modes is listed!
@ -156,10 +166,9 @@ We can now call our functional~group a sub-system. The goal here is to know how
%\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD
%1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component}
Electrical components have detailed datasheets associated with them. A useful extension of this would
Electrical components have detailed datasheets associated with them. A useful extension of this could
be failure modes of the component, with environmental factors and MTTF statistics.
Currently this sort of information is generally only available for generic component types\cite{mil1991}.
Currently this sort of failure mode information is generally only available for generic component types\cite{mil1991}.
%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to
@ -173,7 +182,9 @@ Currently this sort of information is generally only available for generic comp
System & A product designed to \\
& work as a coherent entity \\ \hline
Sub-system & A part of a system, \\
-or- derived component & sub-systems may contain sub-systems \\ \hline
-or- derived component & sub-systems may contain sub-systems. \\
& derived~components may by derived \\
& from derived components \\ \hline
Failure mode & A way in which a System, \\
& Sub-system or component can fail \\ \hline
Functional Group & A collection of sub-systems and/or \\
@ -206,40 +217,41 @@ As the functional~group is a set of components, the failure~modes
that we have to consider are all the failure modes of its components.
Each failure mode (or combination of) investigated is termed a `test case'.
Each `test case' is analysed.
The component failure modes are examined with respect to their effect on the functional~group.
The aim of this analysis is to find out how the functional~group react
%
The component failure modes in each test case
are examined with respect to their effect on the functional~group.
%
The aim of this analysis is to find out how the functional~group reacts
to each of the test case conditions.
The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
\paragraph{Symptom Identification}
When all `test~cases' have been analysed a second phase is applied.
When all `test~cases' have been analysed, a second phase is applied.
%
This looks at the results of the `test~cases' as symptoms
of the sub-system.
Single component failures within the functional~group may cause unique symptoms.
Single component failures (or combinations) within the functional~group may cause unique symptoms.
However, many failures, when looked at from the perspective of the functional group, will have the same symptoms.
These can be collected as `common symptoms'.
To go back to the CD~player example, a failed
output stage, and a failed internal audio amplifier,
will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected.
We can now consider the functional~group as a component and the common symptoms as its failure modes.
Note that here because the process is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
Were failure~modes missed any failure mode model could be dangerously incomplete.
Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes.
\ref{requirement at the start}
% \paragraph{symptom abstraction represented on the diagram} This process can be applied using a diagram. From the collection of parts for the sub-system under analysis, a set of failure modes for each component is obtained. A diagram is then drawn with each component failure mode represented by a contour. Component failure mode combinations are chosen for `test cases'.\footnote{Combinations of component failure modes can be represented by overlapping contours} A `test case' is represented on the diagram as a point or asterisk, in a region enclosed by the contours representing the failure modes it investigates. The effect on the sub-system of each test case is analysed. %It is then represented on the diagram by an asterisk on the contour representing the failure mode. The `test~case~results' are archived. When all test cases have been analysed, we switch our attention to a higher abstraction level. % We treat the sub-system as a black box, or as a component part itsself. % We can now look at the test case results from the perspective of a `user' % of this sub-system. % %
% We treat the sub-system as a `black box' and view the effects of the component failure
% at the sub-system level. This mean we are not interested so much in what the compoent does,
% but how the sub-system reacts when it fails in a certain way.
%
% Each `test case' is labelled from the perspective of the failure as seen at sub-system level.
% We can now try to simplfy by determining common symptoms. A common symptom, in this context, is defined as faults caused by different component failure modes that have the same effect from the perspective of a `user' of the sub-system. Test case results can now viewed as failure modes of the sub-sytem or `black box', and grouped together where there are common symptoms. These are grouped together by joining them with lines. These lines form collected groups (or `spiders'). See figure \ref{fig:gensubsys3}.
% It can be seen now that each {\em lone test case} and {\em spider} on the diagram is a distinct failure mode of the sub-system. This means that these failure modes represent the fault behaviour of the sub-system. We can now treat this sub-system as a component in its own right, or in other words, we have derived a failure mode model at a higher level of abstraction. We can now draw a new diagram to represent the failure modes of the sub-system. Each spider or lone test case, becomes a contour representing a failure mode of the sub-system in this new diagram (see figure \ref{fig:gensubsys4}.
\section{The Process : To analyse a base level Derived~Component/sub-system}
@ -256,7 +268,7 @@ To sumarise:
\item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use.
Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider').
\item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component.
\item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component
\item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component.
\end{itemize}
@ -264,55 +276,70 @@ Determine which test cases produce the same fault symptoms {\em from the perspec
\section{A general derived Component/Sub-System example}
Consider a functional group $FG$ with component parts $A$,$B$ and $C$.
Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$.
$$ FG = \{ A, B , C \} $$
$$ FG = \{ C_1 , C_2 , C_3 \} $$
Each part has a set of related fault modes (i.e. ways in which it can fail to operate correctly).
Let us define the following failure modes for each component part, defining a function $FM()$ where $K$
is a component part and $F$ is its set of failure modes\footnote{Base component failure modes are defined, often with
Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly).
Let us define the following failure modes for each component, defining a function $FM()$
that is passed a component and returns the set of failure modes associated with it
\footnote{Base component failure modes are defined, often with
statistics and evironmental factors in a variety of sources. \cite{mil1991}
}.
$$
FM : K \mapsto F
$$
\\
For our example abovei, let the components have the fiollowing failure~modes
\\
$$ FM(A) = \{ a_1, a_2, a_3 \} $$
$$ FM(B) = \{ b_1, b_2 \} $$
$$ FM(C) = \{ c_1, c_2 \} $$
To re-cap from the definitions chapter \ref{chap:definitions}.
%\paragraph{NOTE TO ANDREW : SHOULD I DEFINE A FUNCTION HERE THAT CONVERTS A FUNCTIONAL GROUP
%TO the set of failure modes in all its component parts ??? Am I being lazy here ???}
Let the set of all possible components be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{F}$.
We can define a function $FM$
\begin{equation}
FM : \mathcal{C} \mapsto \mathcal{P}\mathcal{F}
\end{equation}
defined by (where $C$ is a component and $F$ is a set of failure modes):
$$ FM ( C ) = F $$
%\\
And for this example:
$$ FM(C_1) = \{ a_1, a_2, a_3 \} $$
$$ FM(C_2) = \{ b_1, b_2 \} $$
$$ FM(C_3) = \{ c_1, c_2 \} $$
%In order to convert the three components with thier failure
%modes into one large set containing all the failure modes,
%we could index all Components in $FG$ with $ j \in J $ and use
\paragraph{Finding all failure modes within the functional group}
Consider the index set $j \in J$
Consider the set C to represent components and let this be indexd by $j$.
For this example consider all instances of $C_j$ to be members of $FG$,
$$ \forall j \in J | C_j \in FG $$
For FMMD failure mode analysis, we need to consider the failure modes
from all the components in the functional group as a flat set.
This can be found by applying function $FM$ to all the components
in the functional~group and taking the union of them thus:
Now take the union over the application of all components in the set $FG$
$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$
$$ FG_{cfm} = \bigcup ( \forall j \in J FM(C_j) ) $$
We can now represent the functional~group $FG$ as a set of component faulure modes $FG_{cfm}$,
thus
We can actually overload the notation for the function FM
and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus:
\begin{equation}
FG_{cfm} = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}
FM : FG \mapsto \mathcal{F}
\end{equation}
This could be seen as all the failure modes that can affect the failure mode group $FG$.
Applied to the functional~group $FG$ in the example above:
\begin{equation}
FM(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}
\end{equation}
This can be seen as all the failure modes that can affect the failure mode group $FG$.
% The failure modes of the components can be represented as contours on on the diagram in \ref{fig:gensubsys1}. \begin{figure} \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/synmptom_abstraction.jpg} % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys1} \caption{$FG_{cfm}$ Component Failure modes represented as contours} \end{figure} % % DIAGRAM WITH SPIDER % \begin{figure} % \centering % \includegraphics[scale=20]{./synmptom_abstraction.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys2} % \caption{$SS_{cfm}$ Component Failure modes represented as contours} % \end{figure} We can now look at the effects that component failure modes have on the sub-system. This process involves examining `test cases'. Each `test case' represents the fault behaviour of the sub-system due to particular combinations of component fault modes. Each test case can be represented on the diagram as a labeled point. The labeled point will reside in a region on the diagram enclosed by the contours representing particular component fault modes. The label will indicate the fault symptom from the perspective of the sub-system. For the sake of example, only single component failure modes are considered. We can now assign a test~case to each contour, and mark it on the diagram. % \begin{figure}[h+] % \centering % \includegraphics[scale=20]{./symptom_abstraction2.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys2} % \caption{Component Failure modes with analysed test cases} % \end{figure} \begin{figure} \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction2.jpg} % symptom_abstraction2.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys2} \caption{Component Failure modes with analysed test cases} \end{figure}
\subsection{Analysis of the functional group failure modes}
For this example we shall consider single failure modes.
%For each of the failure modes from $FM(FG)$ we shall
%create a test case ($fgfm_i$). Next each test case is examined/analysed
%and its effect on the functional group determined.
\par
%\vspace{0.3cm}
@ -337,21 +364,21 @@ $c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline
%\vspace{0.3cm}
Table~\ref{tab:fexsymptoms} shows the analysis process.
In this example we are only looking at single fault possibilities.
As we are only looking at single fault possibilities for this example each failure mode
is represented by a test~case.
The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}.
The test cases are analysed w.r.t. the functional~group.
These become functional~group~failure~modes ($fgfm$'s).
The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed.
% The sub-system fault symptoms are now represented on the diagram as in figure \ref{fig:gensubsys2}. A second stage of analysis is now applied. Empirically, it is often noticed that a sub-system will fail in the same way due to a variety of reasons. To the `user' of the sub-system, it does not matter which component or combination of components has failed. The sub-system can thus be considered to have its own set of failure modes. This stage of the analysis is to determine these, to collect `like symptoms'. This is performed on the diagram by linking the test cases with lines to form `spiders'
For the sake of example let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ be
For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be
identical from the perspective of the functional~group.
That is to say, that the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes
That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes
occur, is going to be the same.
For example, in our CD player example, this could mean the common symptom `no\_sound'.
No matter which component failure modes, or combinations thereof cause the problem,
the failure symptom is the same.
It may be of interest to the manufacturers and designers of the CD player why it failed but
It may be of interest to the manufacturers and designers of the CD player why it failed, but
as far as we the users are concerned, it has only one symptom,
`no\_sound'!
We can thus group these component failure modes into a common symptom, $SP1$, thus
@ -361,7 +388,6 @@ Likewise
let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}.
Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}.
% The diagram can now be drawn as in figure \ref{fig:gensubsys3}. % \begin{figure}[h+] % \centering % \includegraphics[scale=20]{./symptom_abstraction3.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys3} % \caption{Common failure modes collected as `Spiders'} % \end{figure} \begin{figure}[h+] \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction3.jpg} % symptom_abstraction3.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys3} \caption{Common failure modes collected as `Spiders'} \end{figure}
We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail.
In other words we have derived failure modes for this functional~group.
@ -386,7 +412,7 @@ Note that $fgfm_6$, while %being a failure mode has
not being grouped as a common symptom
has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear in the derived component.
This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner, my advice to all nine year olds faced with this dilema, is its best, to throw the brussell sprouts out of the dining~room window while the adults are not watching!}!
This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}!
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
@ -399,12 +425,14 @@ write
$$
\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent
$$
\begin{equation}
\bowtie(FG_{cfm}) = DC
\end{equation}
or applying the function $FM$ to obtain the $FG_{cfm}$ set
%
%\begin{equation}
% \bowtie(FG_{cfm}) = DC
%\end{equation}
%
%or applying the function $FM$ to obtain the $FG_{cfm}$ set
%
Where DC is a derived component, and FG is a functional group:
\begin{equation}
\bowtie(FM(FG)) = DC
@ -450,12 +478,12 @@ $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$ is included in a functional~group
that functional~group must be considered to be a a higher level of
\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
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.
%
@ -478,7 +506,7 @@ verification checks in the process can be stated formally.
\begin{algorithm}[h+]
~\label{alg:sympabs1}
\caption{Determine failure modes: $FG \mapsto FG_{cfm}$} \label{alg:sympabs11}
\caption{Determine failure modes: $FG \mapsto F$} \label{alg:sympabs11}
\begin{algorithmic}[1]
%\REQUIRE Obtain a list of components for the System $S$ under investigation.
%ENSURE Decomposition of $S$ into atomic components where each component $c$ has a know set of $fm$ failure modes.
@ -487,26 +515,19 @@ verification checks in the process can be stated formally.
%\STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number and the number of functional groups found.
\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}
\STATE { Let $C_{fm}$ represent a set of failure modes }
\STATE { $FM(c) \mapsto C_{fm} $} \COMMENT {Let the function $FM$ take a component and return a set of all its failure modes}
\STATE { Let $C$ represent a component}
%\ENSURE { $ \forall c | c \in FG \wedge FM(c) \neq \emptyset $}
%\ENSURE { $ c | c \in FG \wedge FM(c) \neq \emptyset $}
\ENSURE{ Each component $c \in FG $ has a known set of failure modes i.e. $FM(c) \neq \emptyset$ }
%\REQUIRE{ Ensure that all components belong to at least one functional group $\bigcup_{i=1...n} fg_i = S $ }
%symptom_abstraction
% okular
\ENSURE{ Each component $C \in FG $ has a known set of failure modes i.e. $FM(C) \neq \emptyset$ }
\STATE {let $FG_{cfm}$ be a set of all failure modes to consider for the functional~group $FG$}
\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
%\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
%\hline
Algorthim \ref{alg:sympabs11} has taken a functional group $FG$ and returned a set of failure~modes $FG_{cfm}$.
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.
@ -523,7 +544,7 @@ in the analysis stages.
\begin{algorithm}[h+]
~\label{alg:sympabs2}
\caption{Determine Test Cases: $FM_{cfm} \mapsto TC $} \label{alg:sympabs22}
\caption{Determine Test Cases: $F \mapsto TC $} \label{alg:sympabs22}
\begin{algorithmic}[1]
\REQUIRE {Determine the test cases to be applied}
@ -550,8 +571,8 @@ in the analysis stages.
\FORALL { $tc_j \in TC$ }
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
\ENSURE {$ tc_j \in \mathcal{P} FG_{cfm} $}
\COMMENT { require that the test case is a member of the powerset of $FM_{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
@ -560,12 +581,12 @@ in the analysis stages.
\STATE { let $f$ represet a component failure mode }
\REQUIRE { That all failure modes are represented in at least one test case }
\ENSURE { $ \forall f | (f \in FM_{cfm}) \wedge (f \in \bigcup TC) $ }
\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; some european standards
imply checking all double fault combinations\cite{en298} }
%\hline
Algorithm \ref{alg:sympabs22} has taken the set of failure modes $FM_{cfm}$ and returned a set of test cases $TC$.
Algorithm \ref{alg:sympabs22} has taken the set of failure modes $ F=FM(FG) $ and returned a set of test cases $TC$.
The next stages is to analyse the effect of each test case on the functional group.
\end{algorithmic}
@ -619,7 +640,8 @@ Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional g
\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.
%\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 ) $}
@ -629,9 +651,6 @@ causes in the functional group $FG$}
\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}
%\hline
@ -665,8 +684,9 @@ We now have a set $SP$ of the symptoms of failure.
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
% treated as a component, and
used in conjection with other components (or derived~components) to form functional~groups at a higher level of failure~mode~abstraction.
used in conjection with other components (or derived~components)
to form functional~groups at a higher level of failure~mode~abstraction.
Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
\end{algorithmic}
\end{algorithm}
@ -679,20 +699,21 @@ The technique provides a methodology for bottom-up analysis of the fault behavio
Because symptom abstraction collects fault modes, the number of faults to handle decreases
as the hierarchy progresses upwards.
This is seen in real life Systems. At the highest levels the number of faults
reduces. A Sound system might have, for instance only four faults at its highest or System level,
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 which combination of causes caused the fault to the user.
But as the hierarchy goes up in abstraction level the number of faults goes down.
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.
Minimal cut sets \cite{nasafta} can be determined from these, and by
analysing the statistical likely hood of the component failures
analysing the statistical likelyhood of the component failures,
the MTTF and SIL\cite{en61508} levels can be automatically calculated.