262 lines
11 KiB
TeX
262 lines
11 KiB
TeX
|
|
\section{Overview of Symptom Extraction Process}
|
|
|
|
% TO DO: separate these two:
|
|
|
|
\paragraph{Symptom Extraction Objective}
|
|
|
|
The objective of `symptom abstraction' is to analyse the functional~group and find
|
|
how it can fail
|
|
when specified components within it fail.
|
|
Once we know how functional~group can fail, we can treat it as a component or sub-system
|
|
with its own set of failure modes.
|
|
|
|
\paragraph{FMEA applied to the Functional Group}
|
|
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 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.
|
|
%
|
|
This looks at the results of the `test~cases' as symptoms
|
|
of the sub-system.
|
|
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.
|
|
It is possible here for an automated system to flag unhandled failure modes.
|
|
\ref{requirement at the start}
|
|
|
|
|
|
\section{The Process : To analyse a base level Derived~Component/sub-system}
|
|
|
|
To sumarise:
|
|
|
|
\begin{itemize}
|
|
\item Determine a minimal functional group
|
|
\item Obtain the list of components in the functional group
|
|
\item Collect the failure modes for each component
|
|
% \item Draw these as contours on a diagram
|
|
% \item Where si,ultaneous failures are examined use overlapping contours
|
|
% \item For each region on the diagram, make a test case
|
|
\item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group
|
|
\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.
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
\section{A theoretical `Derived Component' example}
|
|
|
|
Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$.
|
|
|
|
$$ FG = \{ C_1 , C_2 , C_3 \} $$
|
|
|
|
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}
|
|
}.
|
|
|
|
To re-cap from the definitions chapter \ref{chap:definitions}.
|
|
|
|
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}
|
|
\mathcal{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 $$
|
|
|
|
%\\
|
|
e.g.
|
|
%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 \} $$
|
|
|
|
|
|
\paragraph{Finding all failure modes within the functional group}
|
|
|
|
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:
|
|
|
|
$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} FM(C_j) $$
|
|
|
|
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}
|
|
FM : FG \mapsto \mathcal{F}
|
|
\end{equation}
|
|
|
|
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$.
|
|
|
|
\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 ($g_i$). Next each test case is examined/analysed
|
|
%and its effect on the functional group determined.
|
|
|
|
\par
|
|
%\vspace{0.3cm}
|
|
\begin{table}[h]
|
|
\begin{tabular}{||c|c|c|c||} \hline \hline
|
|
{\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\
|
|
{\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline
|
|
%
|
|
$a\_1$ & $fs\_1$ & $g_{1}$ & SP2 \\ \hline
|
|
$a\_2$ & $fs\_2$ & $g_{2}$ & SP1 \\ \hline
|
|
$a\_3$ & $fs\_3$ & $g_{3}$ & SP2\\ \hline
|
|
$b\_1$ & $fs\_4$ & $g_{4}$ & SP1 \\ \hline
|
|
$b\_2$ & $fs\_5$ & $g_{5}$ & SP1 \\ \hline
|
|
$c\_1$ & $fs\_6$ & $g_{6}$ & SP3 \\ \hline
|
|
$c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline
|
|
%
|
|
\hline
|
|
\end{tabular}
|
|
\caption{Component to functional group to failure symptoms example}
|
|
\label{tab:fexsymptoms}
|
|
\end{table}
|
|
%\vspace{0.3cm}
|
|
|
|
Table~\ref{tab:fexsymptoms} shows the analysis process.
|
|
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 ($g$'s).
|
|
The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed.
|
|
|
|
For the sake of example, let us consider the fault symptoms of $\{g_2, g_4, g_5\}$ to be
|
|
identical from the perspective of the functional~group.
|
|
That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_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
|
|
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
|
|
$ SP1 = \{g_2, g_4, g_5\}$.
|
|
% These can then be joined to form a spider.
|
|
Likewise
|
|
let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure mode {\em from the perspective of the functional~group}.
|
|
Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom},
|
|
s lone symptom can be assigned its own symptom set $SP3 = \{g_6\}$.
|
|
|
|
We have now in $SP1$, $SP2$ and $SP3$ as the three ways in which this functional~group can fail.
|
|
In other words we have derived failure modes for this functional~group.
|
|
We can place these in a set of symptoms, $SP$.
|
|
%
|
|
$$ SP = \{ SP1, SP2, SP3 \} $$
|
|
%
|
|
%
|
|
These three symptoms can be considered the set of failure modes for the functional~group, and
|
|
we can treat it as though it were a {\em black box}
|
|
or a {\em component} to be used in higher level designs.
|
|
%
|
|
The next stage of the process could be applied automatically.
|
|
Each common symptom becomes a failure mode of
|
|
a newly created derived component. Let $DC$ be the newly derived component.
|
|
This is assigned the failure modes that were derived from the functional~group.
|
|
We can thus apply the function $FM$ on this newly derived component thus:
|
|
|
|
$$ FM(DC) = \{ SP1, SP2, SP3 \} $$
|
|
|
|
Note that $g_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 as a failure mode of the derived component.
|
|
i.e. were it not to have been grouped in $SP3$, $ FM(DC)$ would have been $ \{ SP1, SP2, g_6 \}$.
|
|
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}).
|
|
The newly derived compoennt $DC$ is availble for use to form higher level functional groups, and we can thus
|
|
consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
|
|
|
|
|
|
\subsection{Defining the analysis process as a function}
|
|
|
|
It is useful to define this analysis process as a function.
|
|
Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now
|
|
write
|
|
|
|
$$
|
|
\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent
|
|
$$
|
|
%
|
|
%\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
|
|
\end{equation}
|
|
|
|
|
|
%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour.
|
|
%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4}
|
|
|
|
% \begin{figure}[h+]
|
|
% \centering
|
|
% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg}
|
|
% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
|
|
% \label{fig:gensubsys3}
|
|
% \caption{Deriving a new diagram}
|
|
|
|
|
|
This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction)
|
|
with known failure modes.
|
|
This process can be repeated using derived~components to build a
|
|
hierarchical
|
|
fault~mode
|
|
model.
|
|
|