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

.

Browse Source
This commit is contained in:
Robin 2010-05-30 18:57:41 +01:00
parent f997b2ec78
commit 9ea027ac14
1 changed files with 42 additions and 160 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

198
symptom_ex_process/symptom_ex_process.tex
View File

@ -7,29 +7,25 @@ its component parts.
%, and the failure modes of those parts. %, and the failure modes of those parts.
The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint %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.
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, Once the failure modes have been determined for a sub-system,
that sub-system may be treated as a `component' or `black box' and used that sub-system may be treated as a `component' or `black box' and used
in conjunction with other such analysed sub-systems, to model in conjunction with other such analysed sub-systems, to model
higher level sub-systems. In this way a hierarchy to represent the fault behaviour higher level sub-systems. In this way a hierarchy to represent the fault behaviour
of a system can be built. of a system can be built.
%FMMD hierarchy %FMMD hierarchy
The hierarchy is built from the bottom up. The hierarchy is built from the bottom up.
Starting with component failure modes at the bottom. Starting with component failure modes at the bottom.
Because the process is bottom-up, syntax checking and tracking can ensure that Because the process is bottom-up, syntax checking and tracking can ensure that
no component failure mode can be overlooked. no component failure mode can be overlooked.
Once a hierarchy is in place it can be converted into a fault data model. Once a hierarchy is in place it can be converted into a fault data model.
%
From the fault data model, automatic generation From the fault data model, automatic generation
of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible. of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible.
Also statistical reliability\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced Also statistical reliability\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced
automatically, where component failure mode statistics are available\cite{mil1991}. automatically, where component failure mode statistics are available\cite{mil1991}.
%
This paper focuses on the process of building the blocks that are used in the hierarchy. This paper focuses on the process of building the blocks that are used in the hierarchy.
\end{abstract} \end{abstract}
@ -100,7 +96,7 @@ A sub-system will be composed of component parts, which
may themselves be sub-systems. However each `component part' may themselves be sub-systems. However each `component part'
will have a fault/failure behaviour and it should will have a fault/failure behaviour and it should
always be possible to obtain a set of failure modes always be possible to obtain a set of failure modes
for each `component'. for each `component'. In FMMD terms a sub-system is a derived component.
If we look at the sound system again as an If we look at the sound system again as an
example; the CD~player could fail in serveral distinct ways, no matter example; the CD~player could fail in serveral distinct ways, no matter
@ -153,7 +149,7 @@ Currently this sort of information is generally only available for generic comp
System & A product designed to \\ System & A product designed to \\
& work as a coherent entity \\ \hline & work as a coherent entity \\ \hline
Sub-system & A part of a system, \\ Sub-system & A part of a system, \\
& sub-systems may contain sub-systems \\ \hline -or- derived component & sub-systems may contain sub-systems \\ \hline
Failure mode & A way in which a System, \\ Failure mode & A way in which a System, \\
& Sub-system or component can fail \\ \hline & Sub-system or component can fail \\ \hline
Functional Group & A collection of sub-systems and/or \\ Functional Group & A collection of sub-systems and/or \\
@ -173,73 +169,43 @@ Base Component & Any bought in component, which \\
\paragraph{symptom abstraction described} \paragraph{symptom abstraction described}
The objective of `symptom abstraction' is to analyse the functional~group and find out what will happen to it, The objective of `symptom abstraction' is to analyse the functional~group and find
when specified component failure modes occur. how it can fail
Once we know how it fails as a functional~group, we can treat it as a component or sub-system 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. 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 failure mode (or combination of) investigated is termed a `test case'.
Each `test case' is analysed. Each `test case' is analysed.
The component failure modes are examined with respect to their effect on the functional~group. The component failure modes are examined with respect to their effect on the functional~group.
\paragraph{Symptom identification and collection}
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 This looks at the results of the `test~cases' as symptoms
of the sub-system. of the sub-system.
In this way `test~case~results' are grouped as common symptoms, from the perspective of the sub-system. Single component failures 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 To go back to the CD~player example, a failed
output stage, and a failed internal audio amplifier, output stage, and a failed internal audio amplifier,
will both cause the same failure; $no\_sound$ ! will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure are identified and collected.
we can now consider the functional~group as a component and the common symptoms as its failure modes.
% \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. % %
\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 % 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, % 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. % 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. % 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}.
We can now try to simplfy by determining common symptoms. % 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}.
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 sub-system} \section{The Process : To analyse a base level sub-system}
@ -249,15 +215,14 @@ To sumarise:
\item Determine a minimal functional group \item Determine a minimal functional group
\item Obtain list of components in the functional group \item Obtain list of components in the functional group
\item Collect the failure modes for each component \item Collect the failure modes for each component
\item Draw these as contours on a diagram % \item Draw these as contours on a diagram
\item Where multiple failures are examined use overlapping contours % \item Where si,ultaneous failures are examined use overlapping contours
\item For each region on the diagram, make a test case % \item For each region on the diagram, make a test case
\item Examine each test case and determine the effect of the component failure modes on the behaviour of the functional group \item Examine each failure mode of all the components in the functional~group, and determine its effect on the failure 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. \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. Join common symptoms with lines connecting them (sometimes termed a `spider'). Determine which test cases produce the same fault symptoms.% Join common symptoms with lines connecting them (sometimes termed a `spider').
\item The lone test cases and the spiders are now the fault mode behaviour of the sub-system. \item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component.
\item A new diagram can now be drawn where each spider, or lone test case from the original diagram \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
is represented as a contour. These contours represent the failure modes of the sub-system.
\end{itemize} \end{itemize}
@ -291,53 +256,7 @@ thus
% 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}
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}
\par \par
\vspace{0.3cm} \vspace{0.3cm}
@ -355,49 +274,26 @@ $c\_2$ & $fs\_7$ \\ \hline
\vspace{0.3cm} \vspace{0.3cm}
% 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'
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 $SP1 = \{fs_2, fs_4, fs_5\}$ to be an identical For the sake of example let us consider the fault symptoms $SP1 = \{fs_2, fs_4, fs_5\}$ to be an identical
failure mode at the {\em sub-system} level. These can then be joined to form a spider. Likewise failure mode at the {\em sub-system} level. These can then be joined to form a spider. Likewise
let $SP2 = \{fs_1, fs_3, fs_7\}$ be an identical failure mode at the {\em sub-system} level. let $SP2 = \{fs_1, fs_3, fs_7\}$ be an identical failure mode at the {\em sub-system} level.
Let $\{fs_6\}$ be a distinct failure mode at {\em sub-system} level. Let $\{fs_6\}$ be a distinct failure mode at {\em sub-system} level.
The diagram can now be drawn as in figure \ref{fig:gensubsys3}. % 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}
% \begin{figure}[h+] We have now in $SP1$, $SP2$ and $fs_6$ the three ways in which this sub-system can fail.
% \centering In other words we have derived failure modes for this sub-system.
% \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}
The third stage of the process could be applied automatically.
Each common symptom becomes a failure mode of
a newly created derived component.
The third stage of the process can be applied automatically.
Each `spider' or `lone test case' becomes a contour
in the new diagram (see figure \ref{fig:gensubsys4}.
The result of this will be, a set of failure modes for the sub-system, as though it were a {\em black box} The result of this will be, a set of failure modes for the sub-system, as though it were a {\em black box}
or a {\em component} to be used in higher level designs. or a {\em component} to be used in higher level designs.
We have now in $SP1$, $SP2$ and $fs_6$ the three ways in which this sub-system can fail.
In other words we have derived failure modes for this sub-system.
%\section{The Process : To analyse a base level sub-system} %\section{The Process : To analyse a base level sub-system}
@ -442,7 +338,7 @@ In other words we have derived failure modes for this sub-system.
% is represented as a contour. These contours represent the failure modes of the sub-system. % is represented as a contour. These contours represent the failure modes of the sub-system.
% \end{itemize} % \end{itemize}
This sub-system may now therfore, be represented as three separate failure modes. This sub-system or derived~component may now therefore, be represented as three separate failure modes.
We may now treat this sub-system as we would a component with a known set of failure modes. We may now treat this sub-system as we would a component with a known set of failure modes.
The failure modes of the Sub-system $SS$ are now the set $SS_{fm} = \{ SP1, Sp2, fs_6 \}$. The failure modes of the Sub-system $SS$ are now the set $SS_{fm} = \{ SP1, Sp2, fs_6 \}$.
@ -466,23 +362,9 @@ The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' sym
% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541
% \label{fig:gensubsys3} % \label{fig:gensubsys3}
% \caption{Deriving a new diagram} % \caption{Deriving a new diagram}
% \end{figure}
%
\begin{figure}[h+]
\centering
\includegraphics[width=3in,height=3in,bb=0 0 376 410]{symptom_abstraction/symptom_abstraction4.jpg}
% symptom_abstraction4.jpg: 418x455 pixel, 80dpi, 13.27x14.45 cm, bb=0 0 376 410
\caption{Deriving a new diagram}
\label{fig:gensubsys4}
\end{figure}
The derived diagram in figure \ref{fig:gensubsys4} shows the functional group of components $A,B,C$ This sub-system or derived~component, with its three error modes, can now be treated as a component (although at a higher level of abstraction)
analysed as a sub-system. The result is a set of fault modes that define the fault mode behaviour of that sub-system.
This sub-system, with its three error modes, can now be treated as a component (although at a higher level of abstraction)
with known failure modes. with known failure modes.