robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9c46c5e2de
Robin_PHD/symptom_ex_process/symptom_ex_process.tex
Robin Clark e15c2ef6d5 staying late again
2011-02-08 18:56:50 +00:00

1259 lines
53 KiB
TeX
Raw Blame History

\ifthenelse {\boolean{paper}}
{
\input{abstract}
%%- \input{fmmd}
%%- %\input{introduction}
%%- \input{topbot}
%%- %\input{sys_abs}
%%- \input{process}
%%- \input{algorithm}
}
{
\label{symptomex}
%%- \input{./symptom_ex_process/introduction}
%%- \input{./symptom_ex_process/topbot}
%%- %\input{./symptom_ex_process/sys_abs}
%%- \input{./symptom_ex_process/process}
%%- \input{./symptom_ex_process/algorithm}
}
{
\section{Introduction}
\label{chap:sympex}
This chapter describes the process for taking a {\fg},
analysing its failure mode behaviour from the failure modes
and interactions of its components,
and creating a {\dc} that represent the failure mode behaviour of that {\fg}.
This chapter uses algorithms and set theory to describe the process.
%
In essence, we take a {\fg} ( a collection of components),
and apply FMEA analysis locally on this {\fg}.
%
In this way, we determine how that {\fg} can fail.
We can then go further and consider these to
be symptoms of failures in the components of the {\fg}.
We can collect common symptoms of failure for the {\fg}.
%
%
With the collected common symptoms, we can treat the {\fg}
as a component in its own right.
This new component, is derived from the {\fg}.
In the field of safety engineering this derived component corresponds 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/{\dc},
this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}.
%
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.
\fmmdgloss
%
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/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced
automatically\footnote{Where component failure mode statistics are available \cite{mil1991}}.
%
This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy.
We can term this stage in FMMD analysis as the `symptom extraction' process.
The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy.
}
\vspace{40pt}
%\today
\section{Fault Finding and Failure Mode Analysis}
\subsection{Static Analysis}
In the field of safety critical engineering, to comply with
European Law, a product must be certified under the appropriate `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 methodologies are currently used,
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
The FMMD process is a static modelling methodology, aimed primarily for design verification of
safety critical systems.
%
However, FMMD also provides the mathematical framework
to assist in the production of the three traditional methods of static analysis.
From the model created by the FMMD methodology, statistical, FTA and FMEA models
can be derived.
FMMD can model electrical, mechanical and software failures using a common notation,
and can thus model an integrated electro-mechanical software controlled system.
\subsection{Top Down or Natural Trouble Shooting}
It is interesting here to look at the `natural' trouble shooting process.
Fault finding is instinctively 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 be looked into next.
%
The trouble shooter will look for behaviour that is unusual or incorrect
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
will be found to be faulty.
A natural fault finding process is thus top~down.
Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
%%
%% to fool the graphics insertion to make it compatible
%% with thesis and papaer level directories.
%%
%% ln -s . symptom_ex_process
%%
%% insert diagram here
\begin{figure}[h]
\centering
\includegraphics[width=300pt,bb=0 0 587 445,keepaspectratio=true]{symptom_ex_process/top_down_de_comp.jpg}
% top_down_de_comp.jpg: 587x445 pixel, 72dpi, 20.71x15.70 cm, bb=0 0 587 445
\caption{Top Down Failure De-Composition Diagram}
\label{fig:tdh}
\end{figure}
%%
%% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT
%% this study needs to use this term to keep the interested/in context.
The term `sub-system' is typically used in top down methodologies.
It has two equivalents in FMMD.
Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'.
In FMMD a {\fg} becomes a {\dc} after analysis.
The term sub-system will be used alongside both {\fg} and {\dc} where necessary.
\subsection{Top-Down System De-Composition}
A top down fault analysis system will take a system and divide it into
several sub-systems, and determine the safety dependencies
of the System on those sub-systems. In the case of large complicated
systems, the sub-systems themselves may be broken down into simpler sub-systems.
A top down hierarchy is shown in figure \ref{fig:tdh}.
\subsection{FMMD - Bottom~up Analysis}
The FMMD methodology does not follow the `natural fault finding' or top down approach,
it instead works from the bottom up.
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, as it has a known set of failure modes.
%
By reusing the `components' derived from functional~groups, an entire
hierihical failure mode model of the system can be built.
That is to say, using derived components in higher level functional groups,
a hierarchy is naturally formed.
%
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 components\cite{mil1992}.
%It also means that every component failure mode must at the very least be considered.
%{
%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 the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'.
These are listed in table~\ref{tab:symexdef}.
A system, is any coherent entity that would be sold as a product. % safety critical product.
A sub-system is a system that is part of some larger system.
For instance a stereo amplifier separate/slave 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.
\paragraph{Sub-systems, {\fgs} and components.}
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 example,
the CD~player could fail in several distinct ways,
and this could have been caused by a 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
component failures (which can be missed in a top~down approach \cite{faa}[Ch.9])
we are presented with a problem. Which initial collections of base components should we choose?
For instance in the CD~player example; if we 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.
\paragraph{Functional group to {\dc} process outline.}
In choosing the lowest level (base component) sub-systems we would look
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'.
The fault behaviour will consist of a set of `symptoms' caused by combinations
of its component failure modes.
We can thus make a new `component' derived from the functional~group.
The symptoms of the {\fg} are the failure modes of this new `derived component'.
%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!
%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 could
be failure modes of the component, with environmental factors and MTTF statistics.
Currently this sort of failure mode information is generally only available for generic component types \cite{mil1991}.
%\vspace{0.3cm}
\begin{table}[h]
\center
\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. \\
& derived~components may be derived \\
& from derived components \\
& Constraint: This object must have a defined set of failure~modes \\ \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
Symptom & A failure mode of a functional group, caused by \\
& a combination of its component failure modes \\ \hline
Base Component & Any bought in component, or \\
& lowest level module/or part \\
& Constraint: This object must have a defined set of failure~modes \\ \hline
\hline
\end{tabular}
\caption{Symptom Extraction Definitions}
\label{tab:symexdef}
\end{table}
\fmodegloss
\glossary{name={system}, description={A product designed to work as a coherent entity}}
\glossary{name={sub-system}, description={A part of a system, sub-systems may contain sub-systems and so-on}}
\glossary{name={derived component}, description={A theoretical component, derived from a collection of components (which may be derived components themselves)}}
\glossary{name={functional group}, description={A collection of sub-systems and/or components that interact to perform a specific function}}
\glossary{name={symptom}, description={A failure mode of a functional group (of components), caused by a combination of its component failure modes}}
\glossary{name={base component}, description={Any bought in component, or lowest level module/or part}}
%\glossary{name={entry name}, description={entry description}}
\nocite{safeware}
\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, for each test case.
The goal of the process is to produce a set of failure modes from the perspective of the user of the functional~group.
%
In other words, if a designer is handed an piece of circuitry to use, he need not be concerned with
the failure modes of its components. He is handed it as a derived component, which has
a set of failure mode symptoms. The designer can now treat this piece of circuitry as a black box, or {\dc}.
\paragraph{Environmental Conditions or Applied States.}
Each test case must be considered for all applied/operational states and
%in the for the case of each applied states or
environmental conditions to which it may be exposed. In this way, all possible
failure mode behaviour due to the test case conditions will be examined.
As part of this analysis process, records must be kept
detailing each test case result along with its resultant
{\fg} failure mode.
This data will be kept in the model and can be used to
examine environmentally sourced common mode failure scenarios.
%%- A {\fg} may, in the case of an electronic circuit have
%%- applied states. For instance test modes, shutdown or lockout modes etc.
%%- which are inputs to the circuit.
%%- In this case each test case from the {\fg} must be analysed with
%%- respect to all these states.
%%-
%%- A mechanical device may be required to work in different
%%- temperature or pressure ranges for instance and its failure mode behaviour may
%%- change due to enviromental factors.
%%-
\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 summarise:
\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 the failure~mode behaviour of the functional group.
This is a human process, involving detailed analysis of the component failure modes in the test case on the {\fg}.
Where specific environment conditions, or applied states are germane to the {\fg}, these must be examined
for each test case.
\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}
\ifthenelse {\boolean{paper}}
{
\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 environmental factors in a variety of sources. \cite{mil1991}
}.
\subsection{Define Failure mode function $fm$}
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}
\label{theoreticalsx}
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 are
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 disappeared from the analysis process}.
Were the designer to have overlooked this test case, it could appear as a failure mode of the derived component.
i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ could 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{sec:aims}).
%}
%
This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component
with known failure modes
(although at a higher level of abstraction).
This process can be repeated using {\dcs} to build a
hierarchical fault~mode model.
The newly derived component $DC$ is available 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{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$
is the set of all derived components, we can define the symptom abstraction process thus:
$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} .
$$
Given by
$ \bowtie ( FG ) = DC $
as per the example in precedeing section \ref{theoreticalsx}.
\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 we could collect these into a {\fg} thus
$FG_{derived} = \{ DC_1, DC_2, DC_3 \}$.
$DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$
$DCFM = fm(FG_{derived})$.
We can apply the symptom abstraction process $\bowtie$
to the {\fg} comprised of derived components
because we can obtain a failure mode set,
(the failure mode set we have named $DCFM$).
Thus we can now move up another abstraction level by applying
symptom abstraction/extraction to the functional group
$FG_{derived}$ shown in equation \ref{eqn:fgderived}.
\begin{equation}
\label{eqn:fgderived}
\bowtie ( FG_{derived} ) = DC_{derived}
\end{equation}
The case
where a {\fg} has been created from {\dcs}
using function `$\bowtie$' leads us to
{\dc}s at a higher level of failure mode abstraction.
A notation will be described in the next section
to keep track of the abstraction level of a {\dc}.
%%$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
%%\bowtie : FG_{derived} \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((FG)) = DC
%%\end{equation}
In other words by analysing a functional group containing derived components,
we have a new derived component as our result.
This naturally
builds a bottom-up failure mode model and
with each iteration the model becomes more abstract will eventually reach
the SYSTEM level.
%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}
%% IF this is a paper it needs work on the description here.
}
{
To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
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 $$
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}
Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$
is the set of all derived components, we can define the symptom abstraction process thus:
$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} .
$$
The next section describes the details of the symptom extraction process.
}
%\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 and procedural descriptions.
%
The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$
and a new derived~component/sub-system $DC$.
%The sub-system $SS$ is a collection
%of failure~modes of the sub-system.
Note that
$DC$ is a derived component at a higher level of fault analysis abstraction
than the functional~group from which it was derived.
%Thus,
$DC$ can now be treated
as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels}
We can assign an attribute of abstraction level $\abslevel$ to
components, where $\abslevel$ is a natural number, ($\abslevel \in \mathbb{N}_0$).
For a base component, let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$,
the resulting derived~component will have an $\abslevel$ value
one higher that the highest $\abslevel$ value of any of the components
in the functional group used to derive it.
Thus a derived component sourced from base components
will have an $\abslevel$ value of 1.
%
%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,
%the functional~group must take the abstraction level
%of the highest assigned to any of its components.
%
%With a derived component $DC$ having an abstraction level
The attribute $\abslevel$ can be used to track the
level of fault abstraction of components in an FMMD hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is
naturally formed with the abstraction levels increasing with each tier.
\fmmdgloss
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
% \IF{$c.\abslevel > \abslevel_{max}$}
% $\abslevel_{max} = c.\abslevel$
% \ENDIF
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
%\ENDFOR
The algorithm, represented by the symbol `$\bowtie$', has been broken down into five consecutive stages.
%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 are stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Algorithmic Description of Symptom Abstraction}
%\clearpage
$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
\begin{algorithm}[h+]
\caption{Derive new `Component' from Functional Group: $\bowtie(FG)$} \label{alg66}
\begin{algorithmic}[1]
\STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group }
\STATE {TC = dtc (F)} \COMMENT{ determine all test cases } %to apply to the functional group }
\STATE {R = atc (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group }
\STATE {SP = fcs (R)} \COMMENT{ find common symptoms }%of failure for the functional group }
\STATE {DC = cdc (SP)} \COMMENT{ create a derived component }
\RETURN $DC$
\end{algorithmic}
\end{algorithm}
The symptom abstraction process allows us to take a functional group of components,
analyse the failure
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
The checks and constraints applied in the algorithm ensure that all component failure
modes are covered.
This process provides the analysis `step' to building a hierarchical failure mode model
from the bottom-up.
%\clearpage
\subsection{ Determine Failure Modes to Examine}
The first stage is to find the failure modes to consider for
analysis,
using the earlier definition of the function `fm'.
The function $fm$ applied to a component returns the failure modes for that component.
Thus its domain is the set of all components $\mathcal{C}$ and its range
is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$.
$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$
A {\fg} is a collection of components such that $\mathcal{FG} \in \mathcal{P}\,\mathcal{C}$.
The function $fm$ can be overloaded with a functional group $\mathcal{FG}$ as its domain
and the powerset of all failure modes as its range.
$$ fm: \mathcal{FG} \rightarrow \mathcal{P}\,\mathcal{F} $$
%
%%Let $FG$ be the set of components in the functional group under analysis, and $c$
%%be components that are members of it. This function returns a flat set of failure modes $F$.
%given by
%$$fm(FG) = F$$
%%%
%%% Algorithm 1
%%%
%
%%%-
%%%- A such that B is C
%%%-
%
%
%\begin{algorithm}[h+]
% ~\label{alg1}
%\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11}
%\begin{algorithmic}[1]
%\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. }
%\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big( fm(c) \neq \emptyset \big)$.}
%
%%\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 { $ F := \emptyset $ } \COMMENT{Clear the set of failure modes}
%\FORALL { $c \in FG $ }
%\STATE { $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ }
%\ENDFOR
%
%\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}
%
%
%\RETURN { $F$ }
%
%%\hline
%%
%\end{algorithmic}
%\end{algorithm}
%
%Algorthim \ref{alg11} has taken a functional~group $FG$ and returned a set of failure~modes $F=fm(FG)$
%(given that each component has a known set of failure~modes).
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes and will be used
in the analysis stages.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\clearpage
\subsection{ Determine Test Cases}
From the failure modes associated with the functional~group,
we now need to determine test cases.
The test cases are collections of failure modes.
These can be formed from single failure modes or failure modes in combination.
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$
be the set of all failure modes.
%(associated with the functional group $FG$).
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$
given by
$$ dtc(F) = TC $$
In algorithm \ref{alg22}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes)
The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the same component.
\ifthenelse {\boolean{paper}}
{
%% perhaps ref a paper here XXXXX
}
{
This is discussed in chapter \ref{sec:unitarystate}.
}
%%
%% Algorithm 2
%%
%%
%% Maybe need to iterate through each failure mode, adding a new test case
%% this would build up all single fault test cases.
%%
\begin{algorithm}[h+]
~\label{alg2}
\caption{Determine Test Cases: dtc: (F) } \label{alg22}
\begin{algorithmic}[1]
\REQUIRE {F is a non empty flat set of failure modes }
\STATE { All test cases are chosen by the investigating engineer(s). Typically all single
component failures are investigated
with some specially selected combination faults}
\STATE { Let $TC$ be the 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 $ } \COMMENT {Ensure the test cases are complete and unique}
\STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases}
\STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases}
\FORALL { $ f \in F $ }
\STATE{$ tc_j := f $} \COMMENT{ Assign one test case per single fault mode }
\STATE{ $ j := j + 1 $}
\ENDFOR
%\STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes }
\IF{DoubleFaultChecking}
%\STATE { Let $ptc$ be a provisional test case }
\FORALL { $ f1,f2 \in F $ }
\STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make $ptc$ a provisional test case}
%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
% ESCPECIALLY IN THIS FUCKING ENVIRONMENT 22OCT2010
%% OK maybe you can't have comments after IF: half an hour wasted...
\IF { $ {isunitarystate}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant}
\STATE{ $ j := j + 1 $} % latex bug hunt game what fun ! #2
\STATE { $ tc_j := ptc $}
\STATE { $ TC := TC \cup tc_j $ }
\ENDIF
\ENDFOR
\ENDIF
\FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ }
%%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case}
\IF { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC}
\STATE{ $ j := j + 1 $} % latex bug hunt game #1
\STATE { $ tc_j := ptc $}
\STATE { $ TC := TC \cup tc_j $ }
\ENDIF
\ENDFOR
%\FORALL { $tc_j \in TC$ }
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
%
% Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt
%\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
%
% \IF{Single fault checking}
% \STATE { let $f$ represent a component failure mode }
% %\ENSURE { That all failure modes are represented in at least one test case }
% \ENSURE { $ \forall f \;such\;that\; (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; more rigorous cardinality constraint
% checks may be required for some safety standards}
% \ENDIF
%
% \IF{Double fault checking}
% \STATE { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group }
% %\ENSURE { That all failure modes are represented in at least one test case }
% \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ }
% \COMMENT { This corresponds to checking that each possible double failure mode is considered
% as a test case; more rigorous cardinality constraint
% checks may be required for some safety standards. Note if both failure modes
% in the check are sourced from the same component $c$, the test case is impossible
% under unitary state failure mode conditions}
% \ENDIF
%
\ENSURE { $ \forall j1,j2 \in J \; such\; that\; j1 \neq j2 \big( tc_{j1} \neq tc_{j2} \big) $}
\ENSURE { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ }
\RETURN $TC$
% some european standards
% imply checking all double fault combinations\cite{en298} }
%\hline
\end{algorithmic}
\end{algorithm}
Algorithm \ref{alg22} has taken the set of failure modes $ F=fm(FG) $ and returned a set of test cases $TC$.
The next stage is to analyse the effect of each test case on the functional group.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{ Analyse Test Cases}
%%
%% Algorithm 3
%%
The test cases are now analysed for their impact on the behaviour of the functional~group.
Let $\mathcal{R}$ be the set of all test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
$$ atc: \mathcal{TC} \rightarrow \mathcal{R} $$
given by
$$ atc(TC) = R $$
\begin{algorithm}[h+]
~\label{alg3}
\caption{Analyse Test Cases: atc(TC) } \label{alg33}
\begin{algorithmic}[1]
\STATE { let r be a `test case result'}
\STATE { Let the function $Analyse : tc \rightarrow r $ } \COMMENT { This analysis is a human activity, examining the component 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$ }
\FORALL { Environmental and Specific Applied States }
\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 $ } \COMMENT{Add $rc_j$ to the set R}
\STATE{ $ R := R \cup rc_j $ } \COMMENT{Add $rc_j$ to the set R}
\ENDFOR
\ENDFOR
\RETURN $R$
%\hline
\end{algorithmic}
\end{algorithm}
Algorithm \ref{alg33} has built the set $R$, the sub-system/functional group results for each test case.
The analysis is primarily a human activity.
%
Each test case is examined in detail.
%
%
Calculations or simulations
are performed to determine how the failure modes in each test case will
affect the functional~group.
Ideally field and formal physical testing data should be used in addition
where possible.
%
When the all the test cases have been analysed
we will have a `result' for each `test case'.
Each result will be described {\wrt} to the {\fg}, not the components failure modes
in its test case.
%
%In the case of a simple
%electronic circuit, we could calculate the effect on voltages
%within the circuit given a certain component failure mode, for instance.
%%
%
Thus we will have a set of
results corresponding to our test cases. These share a common index value ($j$ in the algorithm description).
These results are the failure modes of the functional group.
%Once a functional group has been analysed, it can be re-used in
%any other design that uses it.
%Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$
%inputs), and in this case the analysis would only need to be performed once.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\clearpage
\subsection{ Find Common Symptoms}
%%
%% Algorithm 4
%%
%This stage analyses the results from bottom-up FMEA analysis ($R$), and collects
%results that, from the perspective of the functional~group, have the same failure symptom.
This stage collects results into `symptom' sets.
Each result from the preceding stage is examined and collected
into common symptom sets.
That is to say, each result in a symptom set, from the perspective of the functional group,
has the same failure symptom.
Let set $\mathcal{SP}$ be the set of all symptoms,
and $\mathcal{R}$ be the set of all test case results.
$$fcs: \mathcal{R} \rightarrow \mathcal{SP} $$
given by
$$ fcs(R) = SP $$
%\begin{algorithm}[h+]
% ~\label{alg4}
%
%\caption{Find Common Symptoms: fcs($R$)} \label{alg44}
%
%\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 the indexed `symptoms' $sp_l$}
% \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
% \STATE{$SP := 0$} \COMMENT{ initialise the `symptom family set'}
%%
% %\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}
%\REPEAT
%
% \STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'}
% \STATE{$Let \; sp_l \in \mathcal{P} R$ such that R is in a common symptom group } \COMMENT{determine common symptoms from the results set}
% \STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set}
% \STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP}
% \STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect}
%
%\UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom}
%
%%% \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 \;such\;that\; \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}
%
% \RETURN $SP$
%%\hline
%
%\end{algorithmic}
%\end{algorithm}
%Algorithm \ref{alg44}
This raises the failure~mode abstraction level, $\abslevel$.
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.
\ifthenelse {\boolean{paper}}
{
Component failure modes must be mutually exclusive.
That is to say only one specific failure mode may be active at any time.
This condition/property has been termed unitary state failure mode.
Ensuring that no result belongs to more than
one symptom set, enforces this, for the derived
component created in the next stage.
}
{
Note ensuring that no result belongs to more than one symptom
set enforces the `unitary state failure mode constraint' for derived components.
}
%% Interesting to draw a graph here.
%% starting with components, branching out to failure modes, then those being combined to
%% test cases, the test cases producing results, and then the results collected into
%% symptoms.
%% the new component then gets the symptoms as failure modes.
%% must be drawn !!!!!
%% 04AUG2010 ~~~~ A27 refugee !!!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\subsection{ Create Derived Component}
%%
%% Algorithm 5
%%
This final stage, is the creation of the derived component.
This derived component may now be used to build
new functional groups at higher levels of fault abstraction.
Let $DC$ be a derived component with its own set of failure~modes.
$$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} $$
given by
$$ cdc(SP) = DC $$
The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$.
%\begin{algorithm}[h+]
% ~\label{alg5}
%
%\caption{Create Derived Component: cdc(SP) } \label{alg55}
%
%\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}
% \STATE { $DC := DC \cup f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
%
% \ENDFOR
% \ENSURE { $fm(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes}
% \RETURN DC
%%\hline
%
%\end{algorithmic}
%\end{algorithm}
%Algorithm \ref{alg55}
The function $cdc$ 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
used in with other components (or derived~components)
to form functional~groups at higher levels of failure~mode~abstraction.
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
\subsection{Hierarchical Simplification}
Because symptom abstraction collects fault modes, the number of faults to handle decreases
as the hierarchy progresses upwards.
%This is seen by casual observation of real life Systems. NEED A GOOD REF HERE
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 to the user, which combination of component failure~modes caused the fault.
But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level.
\subsection{Traceable Fault Modes}
Because the fault modes are determined from the bottom-up, the causes
for all high level faults naturally form trees.
These trees can be traversed to produce
minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
analysing the statistical likelihood of the component failures,
the MTTF and SIL\cite{en61508} levels can be automatically calculated.
%%%\section{Example Symptom Extraction}
%% There already is an example of the process before the algorithmic description
%%%This is a simplified version of the pt100 example in chapter \ref{pt100}.
\vspace{40pt}
%\today
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
Reference in New Issue View Git Blame Copy Permalink