robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
b338d1502c
Robin_PHD/submission_thesis/CH4_FMMD/copy.tex
robin f30d53bb0f forgot to commit last night was in such as rush. 
This is the draft version of CH4 as sent to
Chris Garret och de javla lat skitstovlar.
2012-04-25 18:24:22 +01:00

2978 lines
125 KiB
TeX
Raw Blame History

%%
%% CHAPTER 4 : Failure Mode Modular Discrimination
%%
\ifthenelse {\boolean{paper}}
{
\abstract{
This paper defines %what is meant by
the terms
components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
%The application of Bayes theorem in current methodologies, and
%the suitability of the `null hypothesis' or `P' value statistical approach
%are discussed.
The general concept of the cardinality constrained powerset is introduced
and calculations for it described, and then for
calculations under `unitary state' fault mode conditions.
Data types and their relationships are described using UML.
Mathematical constraints and definitions are made using set theory.}
}
{
\section{Overview}
This chapter defines the FMMD process and related concepts and calculations.
FMMD is in essence modularised FMEA. Rather than taking each component failure mode
and extrapolating top level or system failure symptoms from it,
small groups of components are collected into {\fgs} and analysed,
and then {\dcs} are used to represent the {\fgs}.
These {\dcs} are used to then build further {\fgs} until a hierarchy of {\fgs}
and {\dcs} has been built, converging to a final {\dc}
at the top of the hierarchy.
Firstly, %what is meant by
the terms
components, failure~modes, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes are defined.
%
The general concept of the cardinality constrained powerset is introduced
and calculations for it described, and performance
calculations (comparing traditional FMEA and FMMD)
are presented. % under `unitary state' fault mode conditions.
%
Data types and their relationships are described using UML.
Mathematical constraints and definitions are made using set theory.
}
\section{Introduction}
This
\ifthenelse {\boolean{paper}}
{
paper
}
{
chapter
}
describes the data types and concepts for the Failure Mode Modular De-composition (FMMD) method.
When analysing a safety critical system using
any form of Failure Mode Effects Analysis (FMEA), we need clearly defined failure modes for
all the components that are used in a given system.
%
We introduce a constraint that
component failure modes must be mutually exclusive within individual components.
This concept is later developed as the condition of `unitary state' fault modes.
%When this constraint is complied with, we can use the FMMD method to
%build hierarchical bottom-up models of failure mode behaviour.
%This and the definition of a component are
%described in this chapter.
%When building a system from components,
%we should be able to find all known failure modes for each component.
%For most common electrical and mechanical components, the failure modes
%for a given type of part can be obtained from standard literature~\cite{mil1991}
%\cite{mech}. %The failure modes for a given component $K$ form a set $F$.
\label{defs}
%%
%% Paragraph component and its relationship to its failure modes
%%
\section{ Defining the term Component }
\begin{figure}[h]
\centering
\includegraphics[width=300pt,bb=0 0 437 141,keepaspectratio=true]{CH4_FMMD/component.png}
% component.png: 437x141 pixel, 72dpi, 15.42x4.97 cm, bb=0 0 437 141
\caption{A Component and its Failure Modes}
\label{fig:component}
\end{figure}
Let us first define a component.
%This is anything with which we use to build a product or system.
This is anything we use to build a product or system.
It could be something quite complicated
like an integrated micro controller, or quite simple like the humble resistor.
We can define a
component by its name, a manufacturers' part number and perhaps
a vendor's reference number.
Geoffrey Hall, writing in Spacecraft systems engineering\cite{scse}[p.619]
defines a `part' thus
``{{Part(definition)}---The lowest level of assembly, beyond which further disassembly irrevocably destroys the item''
The term component, in American English, can mean a building block or a part.
In British-English a component generally is given to mean the definition for part above.
For this study, we will use {\bc} to mean a `part', and component
to mean a part or a sub-assembly. Definitions used in FMMD is listed in table~\ref{tbl:fmmd_defs} and discussed below.
%%
\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 data-sheets 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}.
\begin{table}[h]
\center
\begin{tabular}{||p{3cm}|p{10cm}||}
\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
Unitary State & A component may be in only one of its failure modes at a time. \\
\hline
\end{tabular}
\caption{Failure Mode Modular De-composition: definitions and terms}
\label{tbl:fmmd_defs}
\end{table}
% \begin{table}[h+]
% \caption{CANbus messages id}
% \begin{tabular}{|p{1cm}|p{10cm}|}
% \hline \hline
% \textbf{Bit Field} & \textbf{Description} \\ \hline \hline
% 29 & Priority bit, set to zero gives the can message high priority in physical layer arbitration.\\ \hline
% 27-26 & extended source unit, 2 bits (shift left by 4).\\ \hline
% 25-24 & extended local unit, 2 bits (shift left by 4).\\ \hline
% 20 & unit to unit bit. This means message for communication between UNITS on the CANbus, not peripheral devices.\\ \hline
% 19-16 & source unit address (see bits 27-26).\\ \hline
% 15-12 & local unit address (see bits 25-24).\\ \hline
% 11 & broadcast bit (for time signals etc.).\\ \hline
% 10-5 & can handle (6 bit peripheral identifier, used in conjunction with six bit local address).\\ \hline
% 4 & peripheral bit, set to 0 indicates a message from a UNIT, to 1 from a peripheral.\\ \hline
% 3-0 & CAN ID message. For messages between peripherals and units, this identifies the message type. \\
% \hline \hline
% \end{tabular}
% \label{tbl:fmmd_defs}
% \end{table}
What components all have in common is that they can fail, and fail in
a number of well defined ways. For common base-components
there is established literature for the failure modes for the system designer to consider (often with accompanying statistical
failure rates)~\cite{mil1991}~\cite{en298}~\cite{fmd91}. For instance, a simple resistor is generally considered
to fail in two ways, it can go open circuit or it can short.
Thus we can associate a set of faults to this component $ResistorFaultModes=\{OPEN, SHORT\}$\footnote{The failure modes of the resistor
are discussed in section~\ref{sec:resistorfm}.}.
The UML diagram in figure
\ref{fig:component} shows a component as a data
structure with its associated failure modes.
From this diagram we see that each component must have at least one failure mode.
To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
each failure mode is referenced back to only one component. This constraint is discussed in section~\ref{sec:unitarystate}.
%%-%% MTTF STATS CHAPTER MAYBE ??
%%-%%
%%-%% This modelling constraint is due to the fact that even generic components with the same
%%-%% failure mode types, may have different statistical MTTF properties within the same
%%-%% circuitry\footnote{For example, consider resistors one of high resistance and one low.
%%-%% The generic failure modes for a resistor will be the same for both.
%%-%% The lower resistance part will draw more current and therefore have a statistically higher chance of failure.}.
Controlled products are typically built using a large number of base-components and these are traditionally
kept in a `parts~list'.
For a safety critical product this is usually a formal document
and is used for ordering systems from third parties, and by quality inspectors
to ensure the correct parts are being fitted.
%The parts list is shown for completeness here, as people involved with Printed Circuit Board (PCB) and electronics production, verification and testing would want to know where it lies in the model.
The parts list is not actively used in the FMMD method, but is shown in the UML model for completeness.
For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components.
\begin{figure}[h]
\centering
\includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{CH4_FMMD/componentpl.png}
% componentpl.png: 712x68 pixel, 72dpi, 25.12x2.40 cm, bb=0 0 712 68
\caption{Parts List of Components}
\label{fig:componentpl}
\end{figure}
Components in the parts list % (bought in parts)
will be termed `base~components'.
Components derived from base~components (i.e. sub-assemblies) will not always require
parts~numbers\footnote{It is common practise for sub-assemblies, PCB's, mechanical parts,
software modules and some collections of components to have part numbers.
This is a production/configuration~control issue, and linked to Bill of Material (BOM)~\cite{opmanage}
database structures etc. Parts numbers for derived components are not directly related to the analysis process
we are concerned with here.}, and will
not require a vendor reference, but must be named locally in the FMMD model.
We can term `modularising a system', to mean recursively breaking it into smaller sections for analysis.
When modularising a system from the top~down, as in Fault Tree Analysis~\cite{nasafta}\cite{nucfta} (FTA),
it is common to term the modules identified as sub-systems.
When modularising failure mode behaviour from the bottom up, it is more meaningful to call them `derived~components'.
\section{Failure Modes in depth}
For FMEA appraisals of systems we begin with components.
%These will have a set of failure modes assigned to them.
In order to perform FMEA we require a set of failure modes for each component in the system under investigation.
These are failure modes from the perspective of the user
of the component. We are not usually concerned with how the component has failed
internally. What we need to know are the symptoms of failure.
With these symptoms, we can trace their effects through the system under investigation
and determine outcomes.
Different approval agencies may list different failure mode sets for the same generic components.
This apparent anomaly is discussed in section~\ref{sec:determine_fms} using two common electronic components
as examples.
%%
%% DETAILED LOOK AT TWO COMPONENTS AND THEIR FAILURE MODES
%%
%% FROM TWO LITERATURE SOURCES, FMD-91 and EN298
%%
%%% THIS HAS BEEN TAKEN OUT AND PLACED IN THE C_GARRET OPAMPS DOCUMENT
\section{Fault Mode Analysis, top down or bottom up?}
Traditional static fault analysis methods work from the top down.
They identify faults that can occur in a system, and then work down
to see how they could be caused. Some apply statistical techniques to
determine the likelihood of component failures
causing specific system level errors. For example the FMEA variant FMECA, uses
Bayes theorem~\cite{probstat}[p.170]~\cite{nucfta}[p.74] (the relation between a conditional probability and its reverse)
and is applied to specific failure modes in components and their probability of causing given system level errors.
Another top down methodology is to apply cost benefit analysis
to determine which faults are the highest priority to fix~\cite{bfmea}.
The aim of FMMD analysis is to produce complete failure
models of safety critical systems from the bottom-up,
starting, where possible with known base~component failure~modes.
An advantage of working from the bottom up is that we can ensure that
all component failure modes must be considered. A top down approach
can miss individual failure modes of components~\cite{faa}[Ch.~9],
especially where there are non-obvious top-level faults.
In order to analyse from the bottom-up, we need to take
small groups of components from the parts~list that naturally
work together to perform a simple function.
The components to include in a {\fg} are chosen by hand.
%a human, the analyst.
%We can represent the `Functional~Group' as a class.
When we have a
`{\fg}' we can look at the components it contains,
and from this determine the failure modes of all the components that belong to it.
%
% and determine a failure mode model for that group.
%
% expand 21sep2010
%The `{\fg}' as used by the analyst is a collection of component failures modes.
%The analysts interest is in the ways in which the components within the {\fg}
%can fail.
%
All the failure modes of all the components within an {\fg} are collected.
As each component mode holds a set of failure modes, the {\fg} represents a set of sets of failure modes.
We convert this
into a flat set
of failure modes for use in analysis.
A flat set is a set containing just failure modes and not sets of failure modes~\cite{joyofsets}.
%
Each of these failure modes, and optionally combinations of them, are
formed into `test cases' which are
analysed for their effect on the failure mode behaviour of the `{\fg}'.
%
Once we have the failure mode behaviour of the {\fg}, we can determine a new set of failure modes, the derived failure modes of the
`{\fg}'.
%
Or in other words we can determine how the `{\fg}' can fail.
We can now consider the {\fg} as a sort of super component
with its own set of failure modes.
\subsection{From functional group to newly derived component}
\label{fg}
The process for taking a {\fg}, analysing its failure mode behaviour considering
all the failure modes of all the components in the group,
and collecting symptoms of failure, is termed `symptom abstraction'.
\ifthenelse {\boolean{paper}}
{
}
{
This
is dealt with in detail using an algorithmic description, in section \ref{sec:symptom_abstraction}.
}
% define difference between a \fg and a \dc
A {\fg} is a collection of components, a {\dc} is a new `theoretical'
component which has a set of failure modes, which
corresponds to the failure symptoms from the {\fg} from which it was derived.
%
We consider a {\dc} as a black box, or component
for use.
%, and in this case it would have a set of failure modes.
%Looking at the {\fg} in this way is seeing it as a {\dc}.
In terms of our UML model, the symptom abstraction process takes a {\fg}
and creates a new {\dc} from it.
%To do this it first creates
%a new set of failure modes, representing the fault behaviour
%of the functional group. This is a human process and to do this the analyst
%must consider all the failure modes of the components in the functional
%group.
The newly created {\dc} requires a set of failure modes of its own.
These failure modes are the failure mode behaviour of the {\fg} from which it was derived.
%
Because these new failure modes were derived from a {\fg}, we can call
these `derived~failure~modes'.
%It then creates a new derived~component object, and associates it to this new set of derived~failure~modes.
We thus have a `new' component, or system building block, but with a known and traceable
fault behaviour.
The UML representation (in figure \ref{fig:cfg}) shows a `functional group' having a one to one relationship with a derived~component.
The symbol $\derivec$ is used to indicate the analysis process that takes a
functional group and converts it into a new component.
\begin{definition}
With $\mathcal{\FG}$ representing the set of all functional groups, and $\mathcal{{\DC}}$ the set of all derived components,
this can be expressed as $$ \derivec : \mathcal{\FG} \rightarrow \mathcal{{\DC}} $$ .
\end{definition}
\begin{figure}[h]
\centering
\includegraphics[width=400pt,bb=0 0 712 286,keepaspectratio=true]{./CH4_FMMD/cfg.png}
% cfg.png: 712x286 pixel, 72dpi, 25.12x10.09 cm, bb=0 0 712 286
\caption{Basic UML Meta model for FMMD hierarchy}
\label{fig:cfg}
\end{figure}
\subsection{Keeping track of the derived components position in the hierarchy}
\label{sec:alpha}
The UML meta model in figure \ref{fig:cfg}, shows the relationships
between the entities used in FMMD.
Note that because we can use derived components to build functional groups,
this model intrinsically supports % building a
hierarchy.
%
In use we will build a hierarchy of
objects, functional~groups formed with derived~components, and after symptom~abstraction creating
derived components yet higher up in the structure.
%
To keep track of the level in the hierarchy (i.e. how many stages of component
derivation `$\derivec$' have lead to the current derived component)
we can add an attribute to the component data type.
This can be a natural number called the level variable $\abslev \in \mathbb{N}$.
% J. Howse says zero is a given in comp sci. This can be a natural number called the level variable $\alpha \in \mathbb{N}_0$.
The $\abslev$ level variable in each component,
indicates the position in the hierarchy. Base or parts~list components
have a `level' of $\abslev=0$.
% I do not know how to make this simpler
Derived~components take a level based on the highest level
component used to build the functional group it was derived from plus 1.
So a derived component built from base level or parts list components
would have an $\abslev$ value of 1.
%\clearpage
% \section{Set Theory Description}
%
% $$ System \stackrel{has}{\longrightarrow} PartsList $$
%
% $$ PartsList \stackrel{has}{\longrightarrow} Components $$
%
% $$ Component \stackrel{has}{\longrightarrow} FailureModes $$
%
% $$ FunctionalGroup \stackrel{has}{\longrightarrow} Components $$
%
% Using the symbol $\derivec$ to indicate an analysis process that takes a
% functional group and converts it into a new component.
%
% $$ \derivec ( FG ) \rightarrow DerivedComponent $$
%
\subsection{Relationships between functional~groups and failure modes}
Let the set of all possible components be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{F}$, and $\mathcal{PF}$ is the power-set of
all $\mathcal{F}$.
We can define a function $fm$ as equation \ref{eqn:fmset}.
\label{fmdef}
\begin{equation}
fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}
\label{eqn:fmset}
\end{equation}
%%
% Above def gives below anyway
%
%The is defined by equation \ref{eqn:fminstance}, where C is a component and F is a set of failure modes.
%
%\begin{equation}
% fm ( C ) = F
% \label{eqn:fminstance}
%\end{equation}
\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 a functional~group.
%In a functional group we have a collection of Components
%that hold failure mode sets.
we need to collect failure mode sets from the components and place them all
%modes
into a single set; this can be termed flattening the set of sets.
%%Consider the components in a functional group to be $C_1...C_N$.
The flat set of failure modes $FSF$ we are after can be found by applying function $fm$ to all the components
in the functional~group and taking the union of them thus:
%%$$ FSF = \bigcup_{j=1}^{N} fm(C_j) $$
$$ FSF = \bigcup_{c \in FG} fm(c) \; .$$
We can actually overload the notation for the function $fm$ % FM
and define it for the set components within a functional group $\mathcal{FG}$ (i.e. where $\mathcal{FG} \subset \mathcal{C} $)
in equation \ref{eqn:fmoverload}.
\begin{equation}
fm : \mathcal{FG} \rightarrow \mathcal{F}
\label{eqn:fmoverload}
\end{equation}
\section{Unitary State Component Failure Mode sets}
\label{sec:unitarystate}
\paragraph{Design Descision/Constraint}
An important factor in defining a set of failure modes is that they
should represent the failure modes as simply and minimally as possible.
It should not be possible, for instance, for
a component to have two or more failure modes active at once.
Were this to be the case, we would have to consider additional combinations of
failure modes within the component.
Having a set of failure modes where $N$ modes could be active simultaneously
would mean having to consider an additional $2^N-1$ failure mode scenarios.
Should a component be analysed and simultaneous failure mode cases exist,
the combinations could be represented by new failure modes, or
the component should be considered from a fresh perspective,
perhaps considering it as several smaller components
within one package.
This property, failure modes being mutually exclusive, is termed `unitary state failure modes'
in this study.
This corresponds to the `mutually exclusive' definition in
probability theory~\cite{probstat}.
\begin{definition}
A set of failure modes where only one failure mode
can be active at one time is termed a {\textbf{unitary~state}} failure mode set.
\end{definition}
Let the set of all possible components be $ \mathcal{C}$
and let the set of all possible failure modes be $ \mathcal{F}$.
The set of failure modes of a particular component are of interest
here.
What is required is to define a property for
a set of failure modes where only one failure mode can be active at a time;
or borrowing from the terms of statistics, the failure mode being an event that is mutually exclusive
with a set $F$.
We can define a set of failure mode sets called $\mathcal{U}$ to represent this
property for a set of failure modes.
\begin{definition}
We can define a set $\mathcal{U}$ which is a set of sets of failure modes, where
the component failure modes in each of its members are unitary~state.
Thus if the failure modes of a component $F$ are unitary~state, we can say $F \in \mathcal{U}$ is true.
\end{definition}
\section{Component failure modes: Unitary State example}
An example of a component with an obvious set of ``unitary~state'' failure modes is the electrical resistor.
Electrical resistors can fail by going OPEN or SHORTED.
For a given resistor R we can apply the
function $fm$ to find its set of failure modes thus $ fm(R) = \{R_{SHORTED}, R_{OPEN}\} $.
A resistor cannot fail with the conditions open and short active at the same time,
that would be physically impossible! The conditions
OPEN and SHORT are thus mutually exclusive.
Because of this, the failure mode set $F=fm(R)$ is `unitary~state'.
%
%
%Thus because both fault modes cannot be active at the same time, the intersection of $ R_{SHORTED} $ and $ R_{OPEN} $ cannot exist.
%
The intersection of these is therefore the empty set, $ R_{SHORTED} \cap R_{OPEN} = \emptyset $,
therefore
$ fm(R) \in \mathcal{U} $.
We can make this a general case by taking a set $F$ (with $f_1, f_2 \in F$) representing a collection
of component failure modes.
We can define a boolean function {\ensuremath{\mathcal{ACTIVE}}} that returns
whether a fault mode is active (true) or dormant (false).
We can say that if any pair of fault modes is active at the same time, then the failure mode set is not
unitary state:
we state this formally
\begin{equation}
\exists f_1,f_2 \in F \dot ( f_1 \neq f_2 \wedge \mathcal{ACTIVE}({f_1}) \wedge \mathcal{ACTIVE}({f_2}) ) \implies F \not\in \mathcal{U}
\end{equation}
%
% \begin{equation}
% c1 \cap c2 \neq \emptyset | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U
% \end{equation}
That is to say that it is impossible that any pair of failure modes can be active at the same time
for the failure mode set $F$ to exist in the family of sets $\mathcal{U}$.
Note where there are more than two failure~modes,
by banning any pairs from being active at the same time,
we have banned larger combinations as well.
\subsection{Design Rule: Unitary State}
All components must have unitary state failure modes to be used with the FMMD methodology and
for base~components this is usually the case. Most simple components fail in one
clearly defined way and generally stay in that state.
However, where a complex component is used, for instance a microcontroller
with several modules that could all fail simultaneously, a process
of reduction into smaller theoretical components will have to be made.
We can term this `heuristic~de-composition'.
A modern micro-controller will typically have several modules, which are configured to operate on
pre-assigned pins on the device. Typically voltage inputs (\adcten / \adctw), digital input and outputs,
PWM (pulse width modulation), UARTs and other modules will be found on simple cheap microcontrollers~\cite{pic18f2523}.
For instance the voltage reading functions which consist
of an ADC multiplexer and ADC can be considered to be components
inside the micro-controller package.
The micro-controller thus becomes a collection of smaller components
that can be analysed separately~\footnote{It is common for the signal paths
in a safety critical product to be traced, and when entering a complex
component like a micro-controller, the process of heuristic de-compostion
is then applied to it.}.
\paragraph{Reason for Constraint.} Were this constraint to not be applied
each component would not contribute $N$ failure modes to consider but potentially
$2^N$.
%
This would make the job of analysing the failure modes
in a {\fg} impractical due to the sheer size of the task.
%Note that the `unitary state' conditions apply to failure modes within a component.
%%- Need some refs here because that is the way gastec treat the ADC on microcontroller on the servos
\section{Handling Simultaneous Component Faults}
For some integrity levels of static analysis, there is a need to consider not only single
failure modes in isolation, but cases where more then one failure mode may occur
simultaneously.
%
Note that the `unitary state' conditions apply to failure modes within a component.
This does not preclude the possibility of two or more components failing simultaneously.
%
%The scenarios presented deal with possibility of two or more components failing simultaneously.
%
It is an implied requirement of EN298~\cite{en298} for instance to
consider double simultaneous faults\footnote{Under the conditions
of LOCKOUT~\cite{en298} in an industrial burner controller that has detected one fault already.
However, from the perspective of static failure mode analysis, this amounts
to dealing with double simultaneous failure modes.}.
%
To generalise, we may need to consider $N$ simultaneous
failure modes when analysing a functional group.
%
This involves finding
all combinations of failures modes of size $N$ and less.
%The Powerset concept from Set theory is useful to model this.
%
The power-set, when applied to a set S is the set of all subsets of S, including the empty set
\footnote{The empty set ( $\emptyset$ ) is a special case for FMMD analysis, it simply means there
is no fault active in the functional~group under analysis.}
and S itself.
%
We augment the power-set concept here to deal with counting the number of
combinations of failures to consider, under the conditions of simultaneous failures.
%
In order to consider combinations for the set S where the number of elements in
each subset of S is $N$ or less, a concept of the `cardinality constrained power-set'
is proposed and described in the next section.
%\pagebreak[1]
\subsection{Cardinality Constrained Powerset }
\label{ccp}
A Cardinality Constrained power-set is one where subsets of a cardinality greater than a threshold
are not included. This threshold is called the cardinality constraint.
To indicate this, the cardinality constraint $cc$ is subscripted to the powerset symbol thus $\mathcal{P}_{cc}$.
Consider the set $S = \{a,b,c\}$.
The power-set of S:
$$ \mathcal{P} S = \{ \emptyset, \{a,b,c\}, \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} .$$
$\mathcal{P}_{\le 2} S $ means all non-empty subsets of S where the cardinality of the subsets is
less than or equal to 2.
$$ \mathcal{P}_{\le 2} S = \{ \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} . $$
Note that $\mathcal{P}_{1} S $ (non-empty subsets where cardinality $\leq 1$) for this example is:
$$ \mathcal{P}_{1} S = \{ \{a\},\{b\},\{c\} \} $$.
\paragraph{Calculating the number of elements in a cardinality constrained powerset}
A $k$ combination is a subset with $k$ elements.
The number of $k$ combinations (each of size $k$) from a set $S$
with $n$ elements (size $n$) is the binomial coefficient~\cite{probstat} shown in equation \ref{bico}.
\begin{equation}
C^n_k = {n \choose k} = \frac{n!}{k!(n-k)!} .
\label{bico}
\end{equation}
To find the number of elements in a cardinality constrained subset S with up to $cc$ elements
in each combination sub-set,
we need to sum the combinations,
%subtracting $cc$ from the final result
%(repeated empty set counts)
from $1$ to $cc$ thus
%
% $$ {\sum}_{k = 1..cc} {\#S \choose k} = \frac{\#S!}{k!(\#S-k)!} $$
%
\begin{equation}
|{\mathcal{P}_{cc}S}| = \sum^{cc}_{k=1} \frac{|{S}|!}{ cc! ( |{S}| - cc)!} . % was k in the frac part now cc
\label{eqn:ccps}
\end{equation}
\subsection{Actual Number of combinations to check with Unitary State Fault mode sets}
If all of the fault modes in $S$ were independent,
the cardinality constrained powerset
calculation (in equation \ref {eqn:ccps}) would give the correct number of test case combinations to check.
Because sets of failure modes in FMMD analysis are constrained to be unitary state,
the actual number of test cases to check will usually
be less than this.
This is because combinations of faults within a components failure mode set
are impossible under the conditions of unitary state failure mode.
To modify equation \ref{eqn:ccps} for unitary state conditions, we must subtract the number of component `internal combinations'
for each component in the functional group under analysis.
Note we must sequentially subtract using combinations above 1 up to the cardinality constraint.
For example, say
the cardinality constraint was 3, we would need to subtract both
$|{n \choose 2}|$ and $|{n \choose 3}|$ for each component in the functional~group.
\subsubsection{Example: Two Component functional group cardinality Constraint of 2}
For example: suppose we have a simple functional group with two components R and T, of which
$$fm(R) = \{R_o, R_s\}$$ and $$fm(T) = \{T_o, T_s, T_h\}.$$
This means that the functional~group $FG=\{R,T\}$ will have a component failure mode set
of $fm(FG) = \{R_o, R_s, T_o, T_s, T_h\}$
For a cardinality constrained powerset of 2, because there are 5 error modes ( $|fm(FG)|=5$),
applying equation \ref{eqn:ccps} gives :-
$$ | P_2 (fm(FG)) | = \frac{5!}{1!(5-1)!} + \frac{5!}{2!(5-2)!} = 15.$$
This is composed of ${5 \choose 1}$
five single fault modes, and ${5 \choose 2}$ ten double fault modes.
However we know that the faults are mutually exclusive within a component.
We must then subtract the number of `internal' component fault combinations
for each component in the functional~group.
For component R there is only one internal component fault that cannot exist
$R_o \wedge R_s$. As a combination ${2 \choose 2} = 1$. For the component $T$ which has
three fault modes ${3 \choose 2} = 3$.
Thus for $cc = 2$, under the conditions of unitary state failure modes in the components $R$ and $T$, we must subtract $(3+1)$.
The number of combinations to check is thus 11, $|\mathcal{P}_{2}(fm(FG))| = 11$, for this example and this can be verified
by listing all the required combinations:
$$ \mathcal{P}_{2}(fm(FG)) = \{
\{R_o T_o\}, \{R_o T_s\}, \{R_o T_h\}, \{R_s T_o\}, \{R_s T_s\}, \{R_s T_h\}, \{R_o \}, \{R_s \}, \{T_o \}, \{T_s \}, \{T_h \}
\}
$$
and whose cardinality is 11. % by inspection
%$$
%|
%\{
% \{R_o T_o\}, \{R_o T_s\}, \{R_o T_h\}, \{R_s T_o\}, \{R_s T_s\}, \{R_s T_h\}, \{R_o \}, \{R_s \}, \{T_o \}, \{T_s \}, \{T_h \}
%\}
%| = 11
%$$
\pagebreak[1]
\subsubsection{Establishing Formulae for unitary state failure mode
cardinality calculation}
The cardinality constrained powerset in equation \ref{eqn:ccps}, can be modified for % corrected for
unitary state failure modes.
%This is written as a general formula in equation \ref{eqn:correctedccps}.
%\indent{
%To define terms :
%\begin{itemize}
%\item
Let $C$ be a set of components (indexed by $j \in J$)
that are members of the functional group $FG$
i.e. $ \forall j \in J | C_j \in FG $.
%\item
Let $|fm({C}_{j})|$
indicate the number of mutually exclusive fault modes of component $C_j$.
%\item
Let $fm(FG)$ be the collection of all failure modes
from all the components in the functional group.
%\item
Let $SU$ be the set of failure modes from the {\fg} where all $FG$ is such that
components $C_j$ are in
`unitary state' i.e. $(SU = fm(FG)) \wedge (\forall j \in J | fm(C_j) \in \mathcal{U}) $, then
%\end{itemize}
%}
\begin{equation}
|{\mathcal{P}_{cc}SU}| = {\sum^{cc}_{k=1} \frac{|{SU}|!}{k!(|{SU}| - k)!}}
- {\sum_{j \in J} {|FM({C_{j})}| \choose 2}} .
\label{eqn:correctedccps}
\end{equation}
Expanding the combination in equation \ref{eqn:correctedccps}
\begin{equation}
|{\mathcal{P}_{cc}SU}| = {\sum^{cc}_{k=1} \frac{|{SU}|!}{k!(|{SU}| - k)!}}
- {{\sum_{j \in J} \frac{|FM({C_j})|!}{2!(|FM({C_j})| - 2)!}} } .
\label{eqn:correctedccps2}
\end{equation}
\paragraph{Use of Equation \ref{eqn:correctedccps2} }
Equation \ref{eqn:correctedccps2} is useful for an automated tool that
would verify that a single or double simultaneous failures model has complete failure mode coverage.
By knowing how many test cases should be covered, and checking the cardinality
associated with the test cases, complete coverage would be verified.
%\paragraph{Multiple simultaneous failure modes disallowed combinations}
%The general case of equation \ref{eqn:correctedccps2}, involves not just dis-allowing pairs
%of failure modes within components, but also ensuring that combinations across components
%do not involve any pairs of failure modes within the same component.
%%%%- NOT SURE ABOUT THAT !!!!!
%%%- A recursive algorithm and proof is described in appendix \ref{chap:vennccps}.
%%\paragraph{Practicality}
%%Functional Group may consist, typically of four or five components, which typically
%%have two or three failure modes each. Taking a worst case of mutiplying these
%%by a factor of five (the number of failure modes and components) would give
%%$25 \times 15 = 375$
%%
%%
%%
%%\begin{verbatim}
%%
%%# define a factorial function
%%# gives 1 for negative values as well
%%define f(x) {
%% if (x>1) {
%% return (x * f (x-1))
%% }
%% return (1)
%%
%%}
%%define u1(c,x) {
%% return f(c*x)/(f(1)*f(c*x-1))
%%}
%%define u2(c,x) {
%% return f(c*x)/(f(2)*f(c*x-2))
%%}
%%
%%define uc(c,x) {
%% return c * f(x)/(f(2)*f(x-2))
%%}
%%
%%# where c is number of components, and x is number of failure modes
%%# define function u to calculate combinations to check for double sim failure modes
%%define u(c,x) {
%%f(c*x)/(f(1)*f(c*x-1)) + f(c*x)/(f(2)*f(c*x-2)) - c * f(c)/(f(2)*f(c-2))
%%}
%%
%%
%%\end{verbatim}
%%
\pagebreak[1]
\section{Component Failure Modes and Statistical Sample Space}
%\paragraph{NOT WRITTEN YET PLEASE IGNORE}
A sample space is defined as the set of all possible outcomes.
For a component in FMMD analysis, this set of all possible outcomes is its normal (or `correct')
operating state and all its failure modes.
We can consider failure modes as events in the sample space.
%
When dealing with failure modes, we are not interested in
the state where the component is working correctly or `OK' (i.e. operating with no error).
%
We are interested only in ways in which it can fail.
By definition, while all components in a system are `working~correctly',
that system will not exhibit faulty behaviour.
%
We can say that the OK state corresponds to the empty set.
%
Thus the statistical sample space $\Omega$ for a component or derived~component $C$ is
%$$ \Omega = {OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3} ... failure\_mode_{N} $$
$$ \Omega(C) = \{OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3}, \ldots ,failure\_mode_{N}\} . $$
The failure mode set $F$ for a given component or derived~component $C$
is therefore
$ fm(C) = \Omega(C) \backslash \{OK\} $
(or expressed as
$ \Omega(C) = fm(C) \cup \{OK\} $).
The $OK$ statistical case is the (usually) largest in probability, and is therefore
of interest when analysing systems from a statistical perspective.
This is of interest for the application of conditional probability calculations
such as Bayes theorem~\cite{probstat}.
The current failure modelling methodologies (FMEA, FMECA, FTA, FMEDA) all use Bayesian
statistics to justify their methodologies~\cite{nucfta}\cite{nasafta}.
That is to say, a base component or a sub-system failure
has a probability of causing given system level failures\footnote{FMECA has a $\beta$ value that directly corresponds
to the probability that a given part failure mode will cause a given system level failure/event.}.
Another way to view this is to consider the failure modes of a
component, with the $OK$ state, as a universal set $\Omega$, where
all sets within $\Omega$ are partitioned.
Figure \ref{fig:partitioncfm} shows a partitioned set representing
component failure modes $\{ B_1 ... B_8, OK \}$ : partitioned sets
where the OK or empty set condition is included, obey unitary state conditions.
Because the subsets of $\Omega$ are partitioned, we can say these
failure modes are unitary state.
\begin{figure}[h]
\centering
\includegraphics[width=350pt,keepaspectratio=true]{./CH4_FMMD/partitioncfm.png}
% partition.png: 510x264 pixel, 72dpi, 17.99x9.31 cm, bb=0 0 510 264
\caption{Base Component Failure Modes with OK mode as partitioned set}
\label{fig:partitioncfm}
\end{figure}
\section{Components with Independent failure modes}
Suppose that we have a component that can fail simultaneously
with more than one failure mode.
This would make it seemingly impossible to model as `unitary state'.
\paragraph{De-composition of complex component.}
There are two ways in which we can deal with this.
We could consider the component a composite
of two simpler components, and model their interaction to
create a derived component.
\ifthenelse {\boolean{paper}}
{
This technique is outside the scope of this paper.
}
{
%This technique is dealt in section \ref{sec:symtomabstraction} which shows how derived components may be assembled.
}
\begin{figure}[h]
\centering
\includegraphics[width=200pt,bb=0 0 353 247,keepaspectratio=true]{./CH4_FMMD/compco.png}
% compco.png: 353x247 pixel, 72dpi, 12.45x8.71 cm, bb=0 0 353 247
\caption{Component with three failure modes as partitioned sets}
\label{fig:combco}
\end{figure}
\paragraph{Combinations become new failure modes.}
Alternatively, we could consider the combinations
of the failure modes as new failure modes.
We can model this using an Euler diagram representation of
an example component with three failure modes\footnote{OK is really the empty set, but the term OK is more meaningful in
the context of component failure modes} $\{ B_1, B_2, B_3, OK \}$ see figure \ref{fig:combco}.
For the purpose of example let us consider $\{ B_2, B_3 \}$
to be intrinsically mutually exclusive, but $B_1$ to be independent.
This means the we have the possibility of two new combinations
$ B_1 \cap B_2$ and $ B_1 \cap B_3$.
We can represent these
as shaded sections of figure \ref{fig:combco2}.
\begin{figure}[h]
\centering
\includegraphics[width=200pt,bb=0 0 353 247,keepaspectratio=true]{./CH4_FMMD/compco2.png}
% compco.png: 353x247 pixel, 72dpi, 12.45x8.71 cm, bb=0 0 353 247
\caption{Component with three failure modes where $B_1$ is independent}
\label{fig:combco2}
\end{figure}
We can calculate the probabilities for the shaded areas
assuming the failure modes are statistically independent
by multiplying the probabilities of the members of the intersection.
We can use the function $P$ to return the probability of a
failure mode, or combination thereof.
Thus for $P(B_1 \cap B_2) = P(B_1)P(B_2)$ and $P(B_1 \cap B_3) = P(B_1)P(B_3)$.
\begin{figure}[h]
\centering
\includegraphics[width=200pt,bb=0 0 353 247,keepaspectratio=true]{./CH4_FMMD/compco3.png}
% compco.png: 353x247 pixel, 72dpi, 12.45x8.71 cm, bb=0 0 353 247
\caption{Component with two new failure modes}
\label{fig:combco3}
\end{figure}
We can now consider the shaded areas as new failure modes of the component (see figure \ref{fig:combco3}).
Because of the combinations, the probabilities for the failure modes
$B_1, B_2$ and $B_3$ will now reduce.
We can use the prime character ($\; \prime \;$), to represent the altered value for a failure mode, i.e.
$B_1^\prime$ represents the altered value for $B_1$.
Thus
$$ P(B_1^\prime) = B_1 - P(B_1 \cap B_2) - P(B_1 \cap B_3)\; , $$
$$ P(B_2^\prime) = B_2 - P(B_1 \cap B_2) \; and $$
$$ P(B_3^\prime) = B_3 - P(B_1 \cap B_3) \; . $$
We now have two new component failure mode $B_4$ and $B_5$, shown in figure \ref{fig:combco3}.
We can express their probabilities as $P(B_4) = P(B_1 \cap B_3)$ and $P(B_5) = P(B_1 \cap B_2)$.
%%-
%%- Need a complete and more complicated UML diagram here
%%- the other parts were just fragments to illustrate points
%%-
%%-
\section{Complete UML Diagram}
In this section we examine the entities used in FMMD and their relationships.
We have been building parts of the data structure up until now,
and can now complete the picture.
For the complete UML data model we need to consider the System
as a data structure.
The `parts~list' is the
key reference point and starting point. % in the data structure.
Our base components are kept here.
From these the initial {\fgs} are formed, and from the first {\fgs}
the first {\dcs}. Two other data types/entities are required
however: we need to model environmental and operational states and
where they fit into the data structure.
A system will be expected to perform in a given environment.
Environment in the context of this study
means external influences the System could be expected to work under.
A typical data sheet for an electrical component will give
a working temperature range for instance.
Mechanical components could be specified for stress and loading limits.
Systems or sub-systems may have distinct operational states. For instance a safety critical controller
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
authorised human intervention takes place.
A safety critical circuit may have a self test mode.
Operational states and environmental conditions must be factored into the UML model.
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
levels of electrical interference, high voltage contamination on supply
lines, radiation levels etc.
Environmental influences will affect specific components in specific ways.\footnote{A good example of a part
affected by environmental conditions, in this case temperature, is the opto-isolator
which is typically affected at around \oc{60}. Most electrical components are far more robust to temperature.~\cite{tlp181}.}.
Environmental analysis is thus applicable to components.
Environmental influences, such as over stress due to voltage
can be eliminated by down-rating of components as discussed in section~\ref{sec:determine_fms}.
With given environmental constraints, we can therefore eliminate some failure modes from the model.
\paragraph{Operational states.}
Within the field of safety critical engineering, we often encounter
sub-system that include test or self-test facilities.
%
We also encounter degraded performance
(such as only performing functions in an emergency) and lockout conditions.
These can be broadly termed operational states. %, and apply to the
%functional groups.
%
We need to determine which UML class is most appropriate to hold a relationship
to operational states.
%
Consider for instance an electrical circuit that has a TEST line.
When the TEST line is activated, it supplies a test signal
which will validate the circuit. This circuit will have two operational states,
NORMAL and TEST mode.
%
It seems better to apply the operational states to functional groups.
%
Functional groups by definition implement functionality, or purpose
of particular sub-systems, and therefore are the best objects to model
operational states.% with.
\paragraph{Inhibit Conditions.}
Some failure modes may only be active given specific environmental conditions
or when other failures are already active.
To model this, an `inhibit' class has been added.
This is an optional attribute of
a failure mode. This inhibit class can be triggered
on a combination of environmental or failure modes.
\paragraph{UML Diagram Additional Objects.}
The additional objects System, Environment and Operational States
are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref{fig:cfg2}.
\label{completeuml}
\begin{figure}[h]
\centering
\includegraphics[width=400pt,keepaspectratio=true]{./CH4_FMMD/master_uml.png}
% cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
\caption{Complete UML diagram}
\label{fig:cfg2}
\end{figure}
%% XXX bit of a loose end here, maybe delete this
% \subsection{Ontological work on FMEA}
%
% Ontological work on FMEA reviewed so far, has concentrated on
% formalising the natural language process of FMEA and thus
% defining relationships between components, failure modes and top level outcomes
% an overview of this work may found here~\cite{ontfmea}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{An algebraic notation for identifying FMMD enitities}
Consider all `components' to exist as
members of a set $\mathcal{C}$.
%
Each component $c$ has an associated set of failure modes.
We can define a function $fm$ that returns a
set of failure modes $F$, for the component $c$.
Let the set of all possible components be $\mathcal{C}$
and let the set of all possible failure modes be $\mathcal{\FG}$.
We now define the function $fm$
as
\begin{equation}
\label{eqn:fm}
fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{\FG}.
\end{equation}
This is defined by, where $c$ is a component and $F$ is a set of failure modes,
$ fm ( c ) = F. $
We can use the variable name $\FG$ to represent a {\fg}. A {\fg} is a collection
of components.
%We thus define $FG$ as a set of chosen components defining
%a {\fg}; all functional groups
We can state that
{\FG} is a member of the power set of all components, $ \FG \in \mathcal{P} \mathcal{C}. $
We can overload the $fm$ function for a functional group {\FG}
where it will return all the failure modes of the components in {\FG}
given by
$$ fm ({\FG}) = F. $$
Generally, where $\mathcal{{\FG}}$ is the set of all functional groups,
\begin{equation}
fm : \mathcal{{\FG}} \rightarrow \mathcal{P}\mathcal{F}.
\end{equation}
%$$ \mathcal{fm}(C) \rightarrow S $$
%$$ {fm}(C) \rightarrow S $$
\paragraph{Abstraction Levels of {\fgs} and {\dcs}}
\label{sec:indexsub}
We can indicate the abstraction level of a component by using a superscript.
Thus for the component $c$, where it is a `base component' we can assign it
the abstraction level zero, $c^0$. Should we wish to index the components
(for example as in a product parts-list) we can use a sub-script.
Our base component (if first in the parts-list) could now be uniquely identified as
$c^0_1$.
We can further define the abstraction level of a {\fg}.
We can say that it is the maximum abstraction level of any of its
components. Thus a functional group containing only base components
would have an abstraction level zero and could be represented with a superscript of zero thus
`${\FG}^0$'. % The functional group set may also be indexed.
We can apply symptom abstraction to a {\fg} to find
its symptoms.
%We are interested in the failure modes
%of all the components in the {\fg}. An analysis process
We define the symptom abstraction process with the symbol `$\derivec$'.
% is applied to the {\fg}.
%
The $\derivec$ function takes a {\fg}
as an argument and returns a newly created {\dc}.
%
%The $\derivec$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}.
The symptom abstraction process must always raise the abstraction level
for the newly created {\dc}.
Using $\abslev$ (as described in~\ref{sec:alpha}) to symbolise the fault abstraction level, we can now state:
$$ \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. $$
\paragraph{Functional Groups may be indexed.}
We will typically have more than one {\fg} on each level of FMMD hierarchy (expect the top level where there will only be one).
We index the {\fgs} with a sub-script, and can then uniquely identify them using their level and their index.
For example ${\FG}^{3}_{2}$ would be the second {\fg} at the third level of abstraction in an FMMD hierarchy.
\paragraph{The symptom abstraction process in outline.}
The $\derivec$ function processes a functional group and returns a derived component.
Firstly, all the failure modes from all the components in the {\fg}
are used to create failure scenarios, which can be single failure modes
or combinations of failure modes where unitary state failure mode constraints do not apply.
%
With all the failure scenarios, an analyst can
determine how each scenario will affect the {\fg}.
This will give one failure mode behaviour result for each failure scenario.
With these results, we collect common symptoms.
That is to say, that many of the resultant failure modes, will exhibit the same symptom of failure from the perspective
of a user of the {\fg}.
%
We now can treat the functional group as a sort of `super~component'.
%
In order to make this new `super~component' usable, it needs to be in the form of a
component, that is, it has a name, and a set of failure modes.
%
We can do this by creating a new {\dc} and assigning a name to it, and assigning its set of
failure modes being the failure symptoms of the {\fg} from which it was derived.
%A new {\dc} is created
%where its failure modes, are the symptoms from {\fg}.
%
Note that the component must have a higher abstraction level than the {\fg}
it was derived from.
\paragraph{Surjective constraint applied to symptom collection.}
We can stipulate that symptom collection process is surjective.
% i.e. $ \forall f in F $
By stipulating surjection for symptom collection, we ensure
that each component failure mode maps to at least one symptom.
This also ensures that all symptoms have at least one component failure
mode (i.e. one or more failure modes that caused it).
%
\subsection{FMMD Hierarchy}
By applying stages of analysis to higher and higher abstraction
levels, we can converge to a complete failure mode model of the system under analysis.
Because the symptom abstraction process is defined as surjective (from component failure modes to symptoms)
the number of symptoms is guaranteed to be less than or equal to
the number of component failure modes. This means the top level {\dc} in a hierarchy should have a number of {\fms} less than or equal
to the sum of {\fms} in its base components.
In practise however, the number of symptoms greatly reduces as we traverse
up the hierarchy.
This is echoed in real life systems, where the top level events/failures
are always orders of magnitude smaller than sum of {\fms} in its base components.
%This is a natural process. When we have complicated systems
%they always have a small number of system failure modes in comparison to
%the number of failure modes in its sub-systems/components..
\subsection{Derived Component like concepts in safety literature}
Integrated components such as OP-AMPS are already treated as {\dcs}
in literature.
An Op-AMP is an integrated circuit comprising some hundred or so individual components
but in the literature ~\cite{fmd91} is is described as a simple component with a set of failure modes.
% Idea stage on this section, integrated circuits and some compond parts (like digital resistors)
% are treated like base components. i.e. this sets a precedent for {\dcs}.
%
% RE WRITE ---- concept is that some complicated components, like 741 are treated as simple components
% in the literature.
%
% \begin{itemize}
% \item Look at OPAMP circuits, pick one (say $\mu$741)
% % \item Digital transistor perhaps, inside two resistors and a transistor.
% % \item outline a proposed FMMD analysis
% % \item Show FMD-91 OPAMP failure modes -- compare with FMMD
% \end{itemize}
%
% % The gas burner standard (EN298~\cite{en298}), only considers OPEN and SHORT for resistors
% (and for some types of resistors OPEN only).
% FMD-91~\cite{fmd91}(the US military failure modes guide) also includes `parameter change' in its description of resistor failure modes.
% Now a resistor will generally only suffer parameter change when over stressed.
% EN298 stipulates down rating by 60\% to maximum stress
% possible in a circuit. So even if you have a resistor that preliminary tells you would
% never be subjected to say more than 5V, but there is say, a 24V rail
% on the circuit, you have to choose resistors able to cope with the 24V
% stress/load and then down rate by 60\%. That is to say the resitor should be rated for a maximum
% voltage of $ > 38.4V$ and should be rated 60\% higher for its power consumption at $38.4V$.
% Because of down-rating, it is reasonable to not have to consider parameter change under EN298 approvals.
%
% \clearpage
% Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself.
% \subsection{{\fgs} Sharing components and Hierarchy}
%
% With electronics we need to follow the signal path to make sense of failure modes
% effects on other parts of the circuit further down that path.
% %{\fgs} will naturally have to be in the position of starter
% A power-supply is naturally first in a signal path (or failure reasoning path).
% That is to say, if the power-supply is faulty, its failure modes are likely to affect
% the {\fgs} that have to use it.
%
% This means that most electronic components should be placed higher in an FMMD
% hierarchy than the power-supply.
% A shorted de-coupling capactitor caused a `symptom' of the power-supply,
% and an open de-coupling capactitor should be considered a `failure~mode' relevant to the logic chip.
% % to consider.
%
% If components can be shared between functional groups, this means that components
% must be shareable between {\fgs} at different levels in the FMMD hierarchy.
% This hierarchy and an optionally shared de-coupling capacitor (with line highlighted in red and dashed) are shown
% in figure~\ref{fig:shared_component}.
%
% \begin{figure}
% \centering
% \includegraphics[width=250pt,keepaspectratio=true]{CH5_Examples/shared_component.png}
% % shared_component.png: 729x670 pixel, 72dpi, 25.72x23.64 cm, bb=0 0 729 670
% \caption{Optionally shared Component}
% \label{fig:shared_component}
% \end{figure}
% \subsection{Hierarchy and structure}
% By having this structure, the logic circuit element, can accept failure modes from the
% power-supply (for instance these might, for the sake of example include: $NO\_POWER$, $LOW\_VOLTAGE$, $HIGH\_VOLTAGE$, $NOISE\_HF$, $NOISE\_LF$.
% Our logic circuit may be able to cope with $LOW\_VOLTAGE$ and $NOISE\_LF$, but react with a serious symptom to $NOISE\_HF$ say.
% But in order to process these failure modes it must be at a higher stage in the FMMD hierarchy.
\pagebreak[4]
\section{Defining the concept of `comparison~complexity' in FMEA}
%
% DOMAIN == INPUTS
% RANGE == OUTPUTS
%
When performing FMEA, we have a system under investigation, which will be
comprised of a collection of components which have associated failure modes.
The object of FMEA is to determine cause and effect:
from the failure modes (the causes, {\fms} of {\bcs}) to the effects (or symptoms of failure) at the top level.
%
To perform FMEA rigorously
we could stipulate that every failure mode must be checked for effects
against all the components in the system.
We could term this `rigorous~FMEA'~(RFMEA).
The number of checks we have to make to achieve this, gives an indication of the complexity of the task.
%
We could term this `comparison~complexity', as the number of
paths between failure modes and components necessary to achieve RFMEA for a given system/functional~group.
% (except its self of course, that component is already considered to be in a failed state!).
%
Obviously, for a small number of components and failure modes, we have a smaller number
of checks to make than for a complicated larger system.
%
We can consider the system as a large {\fg} of components.
We represent the number of components in the {\fg} $G$, by
$ | G | $,
(an indexing and sub-scripting notation to identify particular {\fgs}
within an FMMD hierarchy is given in section~\ref{sec:indexsub}).
The function $fm$ has a component as its domain and the components failure modes as its range (see equation~\ref{eqn:fm}).
We can represent the number of potential failure modes of a component $c$, to be $ | fm(c) | .$
If we index all the components in the system under investigation $ c_1, c_2 \ldots c_{|\FG|} $ we can express
the number of checks required to rigorously examine every
failure mode against all the other components in the system.
We can define this as a function, Comparison Complexity, $CC$, with its domain as the system
or {\fg}, $\FG$, and
its range as the number of checks to perform to satisfy a rigorous FMEA inspection.
Where $\mathcal{\FG}$ represents the set of all {\fgs}, and $ \mathbb{N} $ any natural integer, $CC$ is defined by,
\begin{equation}
%$$
CC:\mathcal{\FG} \rightarrow \mathbb{N},
%$$
\end{equation}
and, where n is the number of components in the system/{\fg}, $|fm(c_i)|$ is the number of failure modes
in component ${c_i}$, is given by
\begin{equation}
\label{eqn:CC}
%$$
%%% when it was called reasoning distance -- 19NOV2011 -- RD(fg) = \sum_{n=1}^{|fg|} |fm(c_n)|.(|fg|-1)
CC(\FG) = (n-1) \sum_{1 \le i \le n} fm(c_i).
%$$
\end{equation}
This can be simplified if we can determine the total number of failure modes in the system $K$, (i.e. $ K = \sum_{n=1}^{|G|} {|fm(c_n)|}$);
equation~\ref{eqn:CC} becomes
%$$
\begin{equation}
\label{eqn:rd2}
CC(\FG) = K.(|\FG|-1).
\end{equation}
%$$
%Equation~\ref{eqn:rd} can also be expressed as
%
% \begin{equation}
% \label{eqn:rd2}
% %$$
% CC(G) = {|G|}.{|fm(c_n)|}.{(|fg|-1)} .
% %$$
% \end{equation}
\subsection{A general formula for counting Comparison Complexity in an FMMD hierarchy}
An FMMD Hierarchy will have reducing numbers of functional groups as we progress up the hierarchy.
In order to calculate its comparison~complexity we need to apply equation~\ref{eqn:CC} to
all {\fgs} on each level.
We define a helper function $g$ with a domain of the level $i$ in an FMMD hierarchy $H$, and a co-domain of a set of {\fgs} (specifically all the {\fgs} on the given level),
defined by
\begin{equation}
%$$
g(H, i) \rightarrow \forall {\FG}^{\xi} \;where\; ({\xi} = {i}) \wedge ({\FG}^{\xi} \in H) .
%$$
\end{equation}
Where $L$ represents the number of levels in the FMMD hierarchy,
$|g(\xi)|$ represents the number of functional groups on the level
and $H$ represents an FMMD hierarchy,
we overload the comparison complexity thus:
%$$
\begin{equation}
\label{eqn:gf}
CC(H) = \sum_{\xi=0}^{L} \sum_{j=1}^{|g(H,\xi)|} CC({\FG}_{j}^{\xi}).
%$$
\end{equation}
\pagebreak[4]
\subsection{Complexity Comparison Examples}
The potential divider discussed in section~\ref{potdivfmmd} has four failure modes and two components and therefore has $CC$ of 4.
$$CC(potdiv) = \sum_{n=1}^{2} |2|.(|1|) = 4 $$
Even considering a $example$ system with just 81 components (with these components
having 3 failure modes each) we would have an $CC$ of
$$CC(example) = \sum_{n=1}^{81} |3|.(|80|) = 19440 .$$
Ensuring all component failure modes are checked against all other components in a system
-- applying FMEA rigorously -- could be termed
Rigorous FMEA (RFMEA).
The computational order for RFMEA would be polynomial ($O(N^2.K)$) (where $K$ is the variable number of failure modes).
This order may be acceptable in a computational environment: However, the choosing of {\fgs} and the analysis
process are by-hand/human activities. It can be seen that it is practically impossible to achieve
RFMEA for anything but trivial systems.
%
% Next statement needs alot of justification
%
It is the authors belief that FMMD reduces the comparison complexity enough to make
rigorous checking feasible.
\pagebreak[4]
%\subsection{Using the concept of Complexity Comparison to compare RFMEA with FMMD}
\begin{figure}
\centering
\includegraphics[width=400pt,keepaspectratio=true]{CH5_Examples/three_tree.png}
% three_tree.png: 851x385 pixel, 72dpi, 30.02x13.58 cm, bb=0 0 851 385
\caption{FMMD Hierarchy with number of components in {\fg} fixed to 3 $(|G| = 3)$ } % \wedge (|fm(c)| = 3)$}
\label{fig:three_tree}
\end{figure}
\subsection{Comparing FMMD and RFMEA comparison complexity}
Because components have variable numbers of failure modes,
and {\fgs} have variable numbers of components, it is difficult to
use the general formula for comparing the number of checks to make for
RFMEA and FMMD.
%
If we were to create an example by fixing the number of components in a {\fg}
and the number of failure modes per component, we can derive formulae
to compare the number of checks to make from an FMMD hierarchy to RFMEA applied to
all components in a system.
Consider $k$ to be the number of components in a {\fg} (i.e. $k=|{\FG}|$),
$f$ is the number of failure modes per component (i.e. $f=|fm(c)|$), and
$L$ to be the number of levels in the hierarchy of an FMMD analysis.
We can represent the number of failure scenarios to check in a (fixed parameter for $|{\FG}|$ and $|fm(c_i)|$) FMMD hierarchy
with equation~\ref{eqn:anscen}.
\begin{equation}
\label{eqn:anscen}
\sum_{n=0}^{L} {k}^{n}.k.f.(k-1)
\end{equation}
The thinking behind equation~\ref{eqn:anscen}, is that for each level of analysis -- counting down from the top --
there are ${k}^{n}$ {\fgs} within each level; we need to apply RFMEA to each {\fg} on the level.
The number of checks to make for RFMEA is number of components $k$ multiplied by the number of failure modes $f$
checked against the remaining components in the {\fg} $(k-1)$.
If, for the sake of example, we fix the number of components in a {\fg} to three and
the number of failure modes per component to three, an FMMD hierarchy
would look like figure~\ref{fig:three_tree}.
\subsection{RFMEA FMMD Comparison Example}
Using the diagram in figure~\ref{fig:three_tree}, we have three levels of analysis.
Starting at the top, we have a {\fg} with three derived components, each of which has
three failure modes.
Thus the number of checks to make in the top level is $3^0.3.2.3=18$.
On the level below that, we have three {\fgs} each with a
an identical number of checks, $3^1.3.2.3=56$.%{\fg}
On the level below that we have nine {\fgs}, $3^2.3.2.3=168$.
Adding these together gives $242$ checks to make to perform FMMD (i.e. RFMEA {\em{within the}}
{\fgs}).
If we were to take the system represented in figure~\ref{fig:three_tree}, and
apply RFMEA on it as a whole system, we can use equation~\ref{eqn:CC},
$CC(G) = \sum_{n=1}^{|G|} |fm(c_n)|.(|G|-1)$, where $|G|$ is 27, $fm(c_n)$ is 3
and $(|G|-1)$ is 26.
This gives:
$CC(G) = \sum_{n=1}^{27} |3|.(|27|-1) = 2106$.
In order to get general equations with which to compare RFMEA with FMMD,
we can re-write equation~\ref{eqn:CC} in terms of the number of levels
in an FMMD hierarchy.
%
The number of components in the system, is number of components
in a {\fg} raised to the power of the level plus one.
Thus we re-write equation~\ref{eqn:CC} as:
\begin{equation}
\label{eqn:fmea_state_exp21}
\sum_{n=1}^{k^{L+1}}.(k^{L+1}-1).f \; , % \\
%(N^2 - N).f
\end{equation}
or
\begin{equation}
\label{eqn:fmea_state_exp22}
k^{L+1}.(k^{L+1}-1).f \;. % \\
%(N^2 - N).f
\end{equation}
We can now use equation~\ref{eqn:anscen} and \ref{eqn:fmea_state_exp22} to compare (for fixed sizes of $|G|$ and $|fm(c)|$)
the two approaches, for the work required to perform rigorous checking.
For instance, having four levels
of FMMD analysis, with these fixed numbers,
%(in addition to the top zeroth level)
will require 81 base level components.
$$
%\begin{equation}
\label{eqn:fmea_state_exp22}
3^4.(3^4-1).3 = 81.(81-1).3 = 19440 % \\
%(N^2 - N).f
%\end{equation}
$$
$$
%\begin{equation}
% \label{eqn:anscen}
\sum_{n=0}^{3} {3}^{n}.3.3.(2) = 720
%\end{equation}
$$
% \subsection{Exponential squared to Exponential}
%
% can I say that ?
\section{Problems in choosing membership of functional groups}
\subsection{Side Effects: A Problem for FMMD analysis}
A problem with modularising according to functionality is that we can have component failures that would
intuitively be associated with one {\fg} that may cause unintended side effects in other
{\fgs}.
For instance were we to have a component that on failing $SHORT$ could bring down
a voltage supply rail, this could have drastic consequences for other
functional groups in the system we are examining.
\pagebreak[3]
\subsubsection{Example de-coupling capacitors in logic circuits}
A good example of this, are de-coupling capacitors, often used
over the power supply pins of all chips in a digital logic circuit.
Were any of these capacitors to fail $SHORT$, they could bring down
the supply voltage to the other logic chips.
To a power-supply, shorted capacitors on the supply rails
are a potential source of the symptom, $SUPPLY\_SHORT$.
In a logic chip/digital circuit {\fg} open capacitors are a potential
source of symptoms caused by the failure mode $INTERFERENCE$.
So we have a `symptom' of the power-supply, and a `failure~mode' of
the logic chip to consider.
A possible solution to this is to include the de-coupling capacitors
in the power-supply {\fg}.
% decision, could they be included in both places ????
% I think so
Because the capacitor has two potential failure modes (EN298),
this raises another issue for FMMD. A de-coupling capacitor going $OPEN$ might not be considered relevant to
a power-supply module (but there might be additional noise on its output rails).
But in {\fg} terms the power supply, now has a new symptom that of $INTERFERENCE$.
Some logic chips are more susceptible to $INTERFERENCE$ than others.
A logic chip with de-coupling capacitor failing, may operate correctly
but interfere with other chips in the circuit.
There is no reason why the de-coupling capacitors could not be included {\em in the {\fg} they would intuitively be associated with as well}.
This allows for the general principle of a component failure affecting more than one {\fg} in a circuit.
This allows functional groups to share components where necessary.
This does not break the modularity of the FMMD technique, because, as {\irl},
one component failure may affect more than one sub-system.
It does uncover a weakness in the FMMD methodology though.
It could be very easy to miss the side effect and include
the component causing the side effect into the wrong {\fg}, or only one germane {\fg}.
\section{Double Simultaneous Failures}
The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low.
However, some critical systems have to consider these type of eventualities.
The burner control industry has to consider double failures, as specified in European Norm
EN298~\cite{en298}. EN298 does not specifically state that
double simultaneous failures must be considered. What it does say is that
in the event of a lockout---a condition where an error has been detected and
the equipment moves to a safe non-functioning state---no secondary failure may cause a dangerous condition.
%
This is slightly vague: there are so many possible component failures that could
cause a secondary failure, that it is very difficult not to interpret this
as meaning we have to cater for double simultaneous failures for the most critical sections
of a burner control system.
%
In practise---in the field of EN298: burner controllers---this means triple safeguards to ensure the fuel
is not allowed to flow under an error condition. This would of course leave the possibility of
other more complex double failures tricking the controller into thinking the
combustion was actually safe when it was not.
%
It would be impractical to
perform the number of checks (as the checking is a time-consuming human process) required of RFMEA on a system as complex as a burner controller.
It has been shown that, for all but trivial small systems, double failure mode checking
is impossible from a practical perspective.
FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature
of choosing {\fgs} we will not (in the initial stages) be cross checking all possible
combinations of double failures in all of the components.
The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks
to model failure mode scenarios. The failure scenario is defined by the contours that enclose it.
Consider a system which has four components $c_1 \ldots c_4$.
Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$.
Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$.
We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group.
For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing
with failure mode $b$. We can express this as $c_2 a \cup c_1 b$.
\begin{figure}[h]
\centering
\includegraphics[width=300pt,keepaspectratio=true]{CH5_Examples/dubsim1.png}
% dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330
\caption{Simultaneous Failure Mode Scenarios}
\label{fig:dubsim1}
\end{figure}
From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined.
How do we model the double failures that occur across the {\fgs}, for instance
$c_4 a \cup c_1 a$.
It could be argued that because functional groups are chosen for their functionality, and re-usability
that component failures in one should not affect a different {\fg}, but this is a weak argument.
Merely double checking within {\fgs} would be marginally better than
only applying it to the most obvious critical elements of a system.
What is really required is a way that all double simultaneous failures
are checked.
One way of doing this is to apply double failure mode
checking to all {\fgs} higher up in the hierarchy.
This guarantees to check the symptoms caused by the
failure modes in the other {\fgs} with the symptoms
derived from the other {\fgs} modelling for double failures.
%
By traversing down the tree, we can automatically determine which
double simultaneous combinations have not been resolved.
%
By applying double simultaneous checking until no single failures
can lead to a top level event, we
double failure move coverage.
To extend the example in figure~\ref{fig:dubsim1} we can map the failure
scenarios.
For Functional Group 1 (FG1), let us map:
\begin{eqnarray*}
FS1 & \mapsto & S1 \\
FS2 & \mapsto & S3 \\
FS3 & \mapsto & S1 \\
FS4 & \mapsto & S2 \\
FS5 & \mapsto & S2 \\
FS6 & \mapsto & S3
\end{eqnarray*}
Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$.
For Functional Group 2 (FG2), let us map:
\begin{eqnarray*}
FS1 & \mapsto & S4 \\
FS2 & \mapsto & S5 \\
FS3 & \mapsto & S5 \\
FS4 & \mapsto & S4 \\
FS5 & \mapsto & S6 \\
FS6 & \mapsto & S5
\end{eqnarray*}
Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4, S5, S6 \}$
and these are the result of considering double simultaneous failures of its components.
A commonly used temperature measuring circuit, the $Pt100$, is analysed
for double simultaneous failure analysis in section~\ref{sec:pt100}.
A software tool tracking the analysis process
could check that all possible single and double
failure modes combinations have been analysed as failure scenarios.
%single
%XXXXXXXXXXXXXXXXXXXXXXXXXX
%This AUTOMATIC check can reveal WHEN double checking no longer necessary
%in the hierarchy to cover dub sum !!!!! YESSSS
%\ifthenelse {\boolean{paper}}
%{
%\input{abstract}
%%%- \input{fmmd}
%%%- %\input{introduction}
%%%- \input{topbot}
%%%- %\input{sys_abs}
%%%- \input{process}
%%%- \input{algorithm}
%
%}
%{
%\label{symptomex}
%%%- \input{./introduction}
%%%- \input{./topbot}
%%%- %\input{./sys_abs}
%%%- \input{./process}
%%%- \input{./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}.
%
\section{Algorithmic Description of Symptom Abstraction}
\label{sec:symptom_abstraction}
This section uses algorithms and set theory to describe the process for
analysing a {\fg} and determining from it a {\dc}.
%
\paragraph{Symptom Abstraction in brief}
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]{./CH4_FMMD/top_down_de_comp.png}
% 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
hierarchical 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{mil1991}.
%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}
%}
%
%\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 a 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 any failure~modes missed, the failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag un-handled 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:
$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
$$
Given by
$ \derivec ( FG ) = DC $
as per the example in precedeing section \ref{theoreticalsx}.
\paragraph{Extending $\derivec$ to {\dcs}}
It is useful to further define the $\derivec$ function, to
take the failure modes from derived components (as well as base components)
and return a new derived component.
This generalises the function $\derivec$ 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 $\derivec$
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}
\derivec ( FG_{derived} ) = DC_{derived}
\end{equation}
The case
where a {\fg} has been created from {\dcs}
using function `$\derivec$' 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}.
%%$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent
%%\derivec : FG_{derived} \rightarrow DC
%%$$
%
%\begin{equation}
% \derivec(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}
%% \derivec((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 `$\derivec$' 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:
$$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent
\derivec : \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 `$\derivec$') 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 $\abslev$ to
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
For a base component, let the abstraction level be zero.
If we apply the symptom abstraction process $\derivec$,
the resulting derived~component will have an $\abslev$ value
one higher that the highest $\abslev$ 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 $\abslev$ 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 $\abslev$ 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.\abslev > \abslev_{max}$}
% $\abslev_{max} = c.\abslev$
% \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 `$\derivec$', 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
$$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$
\begin{algorithm}[h+]
\caption{Derive new `Component' from Functional Group: $\derivec(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{\FG} $$
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 power-set 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{unitary state} 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, $\abslev$.
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