331 lines
14 KiB
TeX
331 lines
14 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 a 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 contains a set of components, the failure~modes
|
|
that we have to consider are all the failure modes of its components, as
|
|
developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$.
|
|
The aim here is to build `test cases', combinations of failure~modes
|
|
to use as failure~mode analysis scenarios.
|
|
%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 fails given
|
|
the test case conditions, defined in each test case.
|
|
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 can be actioned. % applied.
|
|
%
|
|
This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/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}
|
|
Looking at the functional group perspective failure modes, we can collect
|
|
some of these into common `symptoms'. Some test cases may cause
|
|
unique failure modes at the functional group level. These can be termed
|
|
lone symptoms.
|
|
The common symptoms of failure and lone~symptoms are identified and collected.
|
|
We can now consider the functional~group as a component and the symptoms as its failure modes.
|
|
Note that here, because the process is bottom up, we can ensure that all failure modes
|
|
from the components in a functional~group have been handled\footnote{Software can check that all
|
|
failure modes have been included in at least one test case, and modelled individually. For Double
|
|
Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well}.
|
|
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,
|
|
which solves the main failing of top~down methodologies \cite{topdownmiss}, that of not
|
|
guaranteeing to model all component failure modes.
|
|
\ref{requirement at the start}
|
|
|
|
|
|
\section{The Process}
|
|
|
|
\paragraph{To analyse a base level Derived~Component/sub-system}
|
|
|
|
To sumarise:
|
|
|
|
\begin{itemize}
|
|
\item Choose a set of components to form a functional group.
|
|
% \item Obtain the list of components in the functional group
|
|
\item Collect the failure modes of each component into a flat set.
|
|
\item Choose all single instances (and optional selected combinations\footnote{
|
|
Some specific combinations of failure modes might be included. For instance where
|
|
a very reliable part is duplicated but very critical, like the 4 engines on a 747
|
|
aircraft.}) of the failure modes to
|
|
form `test cases'.
|
|
\item If required create test cases from all valid double failure mode combinations within the {\fg}.
|
|
% \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 Using the `test cases' as scenarios to examine the effects of component failures
|
|
we determine failure~mode behaviour of the functional group.
|
|
This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}.
|
|
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
|
|
\item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.
|
|
\item A new `derived component' can now be created where each common~symptom, or lone symptom is a failure~mode of this new component.
|
|
\end{itemize}
|
|
|
|
|
|
|
|
\pagebreak[1]
|
|
\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}
|
|
}.
|
|
|
|
|
|
\ifthenelse {\boolean{paper}}
|
|
{
|
|
\subsection{Define Failure mode function $fm$}
|
|
}
|
|
{
|
|
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}
|
|
{fm} : \mathcal{C} \rightarrow \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 \} $$
|
|
|
|
where $a_n,b_n,c_n$ are component failure modes.
|
|
|
|
\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 (where F is the set of all failure modes for all components in the functional group) thus:
|
|
|
|
$$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$
|
|
|
|
We 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 \rightarrow \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 test case
|
|
is represented by one failure mode.
|
|
Chosen combinations of 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 the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$
|
|
As failure modes, these
|
|
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},
|
|
but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$.
|
|
|
|
We now have in $SP1$, $SP2$ and $SP3$ 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 = \{ SP1, SP2, SP3 \}. $$
|
|
%
|
|
%
|
|
These three symptoms can be considered the set of failure modes for the functional~group, if
|
|
we 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$ 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 \}$.
|
|
Because the process can be computerised, we can easily flag symptoms that have not been
|
|
included as failure modes in a {\dc}.
|
|
% Aw boring ! no jokes ?
|
|
% 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!}!
|
|
%
|
|
\ifthenelse {\boolean{paper}}
|
|
{
|
|
An advantage of a bottom-up process is that failure modes
|
|
from base level components cannot be overlooked.
|
|
}
|
|
{
|
|
An advantage of a bottom-up process is that failure modes
|
|
from base level components cannot be overlooked.
|
|
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
|
|
}
|
|
%
|
|
The newly derived component $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}
|
|
|
|
Where $\mathcal{F}$ is the set of all sets of failure modes, and $\mathcal{DC}$
|
|
is the set of all derived components, we can define the symptom abstraction process thus:
|
|
$$
|
|
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
|
|
\bowtie : \mathcal{F} \rightarrow \mathcal{DC}
|
|
$$
|
|
|
|
\paragraph{Extending $\bowtie$ to {\dcs}}
|
|
|
|
It is useful to further define the $\bowtie$ function, to
|
|
take the failure modes from derived components (as well as base components)
|
|
and return a new derived component.
|
|
This generalises the function $\bowtie$ and allows us to build
|
|
hierarchical failure mode models.
|
|
|
|
Where a {\fg} is composed of derived components, for sake of example
|
|
where $DC_1, DC_2, DC_3 $ are {\dc}'s and $DCFM$ is a set of failure modes thus
|
|
$FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$
|
|
|
|
We can apply the symptom abstraction process $\bowtie$
|
|
to the failure mode set $DCFM$.
|
|
|
|
The case
|
|
where a {\fg} has been created from {\dcs}
|
|
using function `$\bowtie$' leads us to
|
|
{\dc}'s at a higher level of fault abstraction.
|
|
|
|
$$
|
|
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
|
|
\bowtie : DCFM \rightarrow DC
|
|
$$
|
|
%
|
|
%\begin{equation}
|
|
% \bowtie(FG_{cfm}) = DC
|
|
%\end{equation}
|
|
%
|
|
%or applying the function $fm$ to obtain the $FG_{cfm}$ set
|
|
%
|
|
To put this in context, where FG is a functional group, sourced from base or derived components,
|
|
we may state the process of
|
|
analysing the failure modes in the {\fg} and returning a {\dc} thus:
|
|
\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 {\dc} $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 {\dcs} to build a
|
|
hierarchical fault~mode model.
|
|
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|