664 lines
35 KiB
TeX
664 lines
35 KiB
TeX
|
|
\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.
|
|
|
|
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 trat 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 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
|
|
to model
|
|
higher level sub-systems/derived~components.
|
|
In this way a hierarchy to represent the fault behaviour
|
|
of a system can be built from the bottom~up. This process can continue
|
|
until there is a complete hierarchy representing the failure mode
|
|
behaviour of the entire system under analysis.
|
|
%FMMD hierarchy
|
|
Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage.
|
|
Because the process is bottom-up, syntax checking and tracking can ensure that
|
|
no component failure mode can be overlooked.
|
|
Once a hierarchy is in place it can be converted into a fault data model.
|
|
%
|
|
From the fault data model, automatic generation
|
|
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
|
|
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.
|
|
|
|
\end{abstract}
|
|
|
|
%\clearpage
|
|
|
|
\section{Introduction}
|
|
|
|
\subsection{Top Down or natural trouble shooting}
|
|
It is interesting here to look at the `natural' trouble shooting process.
|
|
Fault finding is intinctively performed from the top-down.
|
|
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
|
|
moving to a more detailed lower level.
|
|
Specific measurements
|
|
and checks will be made, and finally a component or a low level sub-system
|
|
will be found to be faulty.
|
|
A natural fault finding process is thus top~down.
|
|
\subsection{FMMD - Bottom~up Analysis}
|
|
The FMMD technique described here works the other way. It works from the bottom up.
|
|
Starting with a collection of 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.
|
|
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.
|
|
|
|
\subsection{Static Analysis}
|
|
|
|
In the field of safety critical engineering; to comply with
|
|
European Law a product must be certified under the approriate `EN' standard.
|
|
Typically environmental stress, EMC, electrical stressing, endurance tests,
|
|
software~inspections and project~management quality reviews are applied\cite{sccs}.
|
|
|
|
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,
|
|
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.
|
|
From the model created by the FMMD technique, the three above failure mode
|
|
descriptions can be derived.
|
|
|
|
{
|
|
The aims are
|
|
\begin{itemize}
|
|
\item To automate the process where possible
|
|
\item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups)
|
|
\item To use a modular approach so that analysed sub-systems can be re-used
|
|
\item Automatically ensure no failure mode is unhandled
|
|
\item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically
|
|
\end{itemize}
|
|
}
|
|
|
|
|
|
\subsection{Systems, functional groups, sub-systems and failure modes}
|
|
|
|
It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `derived~component/sub-system'.
|
|
These are listed in table~\ref{tab:symexdef}.
|
|
|
|
A System, is really any coherent entity that would be sold as a safety critical product.
|
|
A sub-system is a system that is part of some larger system.
|
|
For instance a stereo amplifier separate is a sub-system. The
|
|
whole Sound System, consists perhaps of the following `sub-systems':
|
|
CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
|
|
|
|
%Thinking like this is a top~down analysis approach
|
|
%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'
|
|
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.
|
|
|
|
|
|
Using the reasoning that working from the bottom up forces the consideration of all possible
|
|
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
|
|
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
|
|
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
|
|
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 !
|
|
%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!
|
|
|
|
|
|
%This type of thinking is starting to become more commonplace in product literature, with the emergence
|
|
%of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}.
|
|
%FIT (Failure in Time - expected number of failures per billion hours of operation) values
|
|
%are published for some micro-controllers. A micro~controller
|
|
%is a complex sub-system in its self and could be considered a `black~box' with a given reliability.
|
|
%\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
|
|
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}.
|
|
|
|
|
|
%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to
|
|
%erform a given function.
|
|
|
|
%\vspace{0.3cm}
|
|
\begin{table}[h]
|
|
\begin{tabular}{||l|l||} \hline \hline
|
|
{\em Definition } & {\em Description} \\ \hline
|
|
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
|
|
Failure mode & A way in which a System, \\
|
|
& Sub-system or component can fail \\ \hline
|
|
Functional Group & A collection of sub-systems and/or \\
|
|
& components that interact to \\
|
|
& perform a specific function \\ \hline
|
|
Base Component & Any bought in component, which \\
|
|
& hopefully has a known set of failure modes \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\caption{Symptom Extraction Definitions}
|
|
\label{tab:symexdef}
|
|
\end{table}
|
|
%\vspace{0.3cm}
|
|
|
|
|
|
\section{The Symptom abstraction Process}
|
|
|
|
% TO DO: separate these two:
|
|
|
|
\paragraph{Symptom Extraction Described}
|
|
|
|
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 are examined with respect to their effect on the functional~group.
|
|
The philosophy behind this analysis is, how will the functional~group react
|
|
to each of the test case conditions. The aim 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 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 this is bottom up, we can ensure that all failure modes
|
|
associated with a functional~group have been handled.
|
|
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}
|
|
|
|
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 general derived Component/Sub-System example}
|
|
|
|
Consider a functional group $FG$ with component parts $A$,$B$ and $C$.
|
|
|
|
$$ FG = \{ A, B , C \} $$
|
|
|
|
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
|
|
statistics and evironmental factors in a variety of sources. \cite{mil1991}
|
|
}.
|
|
|
|
$$
|
|
FM : K \mapsto F
|
|
$$
|
|
\\
|
|
For our example above
|
|
\\
|
|
$$ FM(A) = \{ a_1, a_2, a_3 \} $$
|
|
$$ FM(B) = \{ b_1, b_2 \} $$
|
|
$$ FM(C) = \{ c_1, c_2 \} $$
|
|
|
|
\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 ???}
|
|
|
|
We can now represent the functional~group $FG$ as a set of component faulure modes $FG_{cfm}$,
|
|
thus
|
|
|
|
\begin{equation}
|
|
FG_{cfm} = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}
|
|
\end{equation}
|
|
|
|
|
|
|
|
% 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
|
|
%\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$ & $fgfm_{1}$ & SP2 \\ \hline
|
|
$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline
|
|
$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline
|
|
$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline
|
|
$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline
|
|
$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline
|
|
$c\_2$ & $fs\_7$ & $fgfm_{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.
|
|
In this example we are only looking at single fault possibilities.
|
|
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
|
|
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
|
|
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 = \{fgfm_2, fgfm_4, fgfm_5\}$.
|
|
% These can then be joined to form a spider.
|
|
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.
|
|
We can place these in a set of symptoms, $SP$.
|
|
%
|
|
$$ SP = \{ SP1, SP2, fgfm_6 \} $$
|
|
%
|
|
%
|
|
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, fgfm_6 \} $$
|
|
|
|
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!}!
|
|
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
|
|
|
|
|
|
\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
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
|
|
%\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 sub-system $DC$.
|
|
%The sub-system $SS$ is a collection
|
|
%of failure~modes of the sub-system.
|
|
$DC$ is a derived component at a higher level of fault analysis abstraction,
|
|
it may be thus be treated
|
|
as a component with a known set of failure modes.
|
|
Thus $DC$ can be used as a system building block at a higher
|
|
level of fault abstraction.
|
|
|
|
|
|
The algorithm, representing the function $\bowtie$, has been broken down into five stages, each following on from the other.
|
|
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 can be stated formally.
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Failure Modes to examine}
|
|
%%
|
|
%% Algorithm 1
|
|
%%
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs1}
|
|
\caption{Determine failure modes: $FG \mapsto FG_{cfm}$} \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.
|
|
|
|
|
|
%\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}
|
|
|
|
%\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
|
|
|
|
\STATE {let $FG_{cfm}$ 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
|
|
|
|
%\hline
|
|
Algorthim \ref{alg:sympabs11} has taken a functional group $FG$ and returned a set of failure~modes $FG_{cfm}$.
|
|
The next task is to formulate `test cases'. These are the combinations of failure~modes that will be used
|
|
in the analysis stages.
|
|
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ Determine Test Cases}
|
|
%%
|
|
%% Algorithm 2
|
|
%%
|
|
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs2}
|
|
\caption{Determine Test Cases: $FM_{cfm} \mapsto TC $} \label{alg:sympabs22}
|
|
\begin{algorithmic}[1]
|
|
|
|
\REQUIRE {Determine the test cases to be applied}
|
|
|
|
\STATE { All test cases are now chosen by the investigating engineer(s). Typically all single
|
|
component failures are investigated
|
|
with some specially selected combination faults}
|
|
|
|
\STATE { Let $TC$ be a 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 $ }
|
|
|
|
%\STATE { $ \bigcup_{j=1...N} tc_j = \bigcup TC $ }
|
|
%\COMMENT { All $tc_j$ test cases sets belong to $TC$ }
|
|
|
|
%\REQUIRE { $ TC \subset \bigcup (FM_{cfm}) $ }
|
|
%\COMMENT { $TC$ is the set of all test_cases
|
|
% Let TC be a subset of the powerset of the failure modes $ FG_{cfm} $,
|
|
%i.e. only failure modes present in $ FG_{cfm} $ are present in sets belonging to $ TC $}
|
|
|
|
|
|
\COMMENT { Ensure the test cases are complete and unique }
|
|
|
|
\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 { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
|
|
\COMMENT { Test cases must be unique }
|
|
\ENDFOR
|
|
|
|
|
|
|
|
\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) $ }
|
|
\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$.
|
|
The next stages is to analyse the effect of each test case on the functional group.
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ Analyse Test Cases}
|
|
%%
|
|
%% Algorithm 3
|
|
%%
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs3}
|
|
\caption{Analyse Test Cases: $ TC \mapsto R $} \label{alg:sympabs33}
|
|
\begin{algorithmic}[1]
|
|
\STATE { let r be a `test case result'}
|
|
\STATE { Let the function $Analyse : tc \mapsto 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}
|
|
\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 $ }
|
|
\ENDFOR
|
|
|
|
%\hline
|
|
Algorithm \ref{alg:sympabs33} has built the set $R$, the sub-system/functional group results for each test case.
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ Find Common Symptoms}
|
|
%%
|
|
%% Algorithm 4
|
|
%%
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs4}
|
|
|
|
\caption{Find Common Symptoms: $ R \mapsto SP $} \label{alg:sympabs44}
|
|
|
|
\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 sets $sp_l$}
|
|
\COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
|
|
%
|
|
%\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}
|
|
|
|
\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 | \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}
|
|
|
|
%\hline
|
|
Algorithm \ref{alg:sympabs44} raises the failure~mode abstraction level.
|
|
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.
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
\clearpage
|
|
\subsection{Algorithmic Description of Symptom Abstraction \\ Create Derived Component}
|
|
%%
|
|
%% Algorithm 5
|
|
%%
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg:sympabs5}
|
|
|
|
\caption{Treat the symptoms as failure modes of the Derived~Component/Sub-System: $ SP \mapsto DC $} \label{alg:sympabs55}
|
|
|
|
\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}
|
|
\ENDFOR
|
|
%\hline
|
|
|
|
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.
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
|
|
\section{To conclude}
|
|
|
|
The technique provides a methodology for bottom-up analysis of the fault behaviour of complex safety critical systems.
|
|
|
|
\subsection{Hierarchical Simplification}
|
|
|
|
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,
|
|
\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.
|
|
|
|
\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
|
|
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
|
|
|