%%
%% 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.

Or in other words we take the traditional FMEA process, and modularise it.
We break down each stage of reasoning
into small manageable groups, and use the results of those groups, as {\dcs}
to build higher level groups. 
%This has advantages of concentrating
%effort in where modules interact, 

  
%% J. Howse 04MAY2012 REMOVEFirstly, %what is meant by 
%% J. Howse 04MAY2012 REMOVEthe terms
%% J. Howse 04MAY2012 REMOVEcomponents, failure~modes, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes are defined.
%
%% J. Howse 04MAY2012 REMOVE The general concept of the cardinality constrained powerset is introduced
%% J. Howse 04MAY2012 REMOVE and calculations for it described, and performance
%% J. Howse 04MAY2012 REMOVE calculations (comparing traditional FMEA and FMMD)
%% J. Howse 04MAY2012 REMOVE are presented. % under `unitary state' fault mode conditions.
%
%% J. Howse 04MAY2012 REMOVEData types and their relationships are described using UML.
%% J. Howse 04MAY2012 REMOVEMathematical constraints and definitions are made using set theory.
}

 
\section{Introduction}
This chapter 
starts with an overview of current failure modelling techniques, and then  worked example using the new methodology, 
Failure Mode Modular De-composition (FMMD).
This is followed by a discussion on the design of the FMMD methodology and then
an ontological description is given using UML class models.
A  notation is then described to index and classify objects created in FMMD hierarchical models.


\subsection{Overview of current failure mode modelling techniques}

We briefly analyse four current methodologies.
Comprehensive overviews of these methodologies may be found
in ~\cite{safeware,sccs,nasafta,nucfta,bfmea}. 

\paragraph{Fault Tree Analysis (FTA).}
FTA~\cite{nasafta,nucfta} is a top down methodology in which a hierarchical diagram is drawn for
each undesirable top level failure/event, presenting the conditions that must arise to cause
the event. 
%
It is suitable for large complicated systems with few undesirable top
level failures and focuses on those events considered most important or most catastrophic.
%
Effects of duplication/redundancy of safety systems can be readily assessed. 
It uses notations that are readily understood by engineers 
(logic symbols borrowed from digital electronics and a fault hierarchy). 
However, it cannot guarantee to model all base component failures 
or be used to determine system level errors other than those modelled. 
%
Each FTA diagram models one top level event.
This creates duplication of modelled elements, 
and it is difficult to cross check between diagrams. It has limited 
support for environmental and operational states.


\paragraph{Fault Mode Effects Analysis (FMEA)} is used principally to determine system reliability. 
It is bottom-up and starts with component failure modes, which
lead to top level failure/events.
Each top level failure is assessed by its cost to repair (or perceived criticality) and its estimated frequency. %, using a 
%failure mode ratio. 
A list of failures according to their cost to repair~\cite{bfmea}, or effect on system reliability is then calculated. 
It is easy to identify single component failure to system failure mappings 
and an estimate of product reliability can be calculated. 
%This can be viewed as a prioritised `to~fix' list.
%
It cannot focus on complex
component interactions that cause system failure modes or determine potential 
problems from simultaneous failures. It does not consider changing environmental 
or operational states in sub-systems or components. It cannot model 
self-checking safety elements or other in-built safety features or 
analyse how particular components may fail.


\paragraph{Failure Mode Effects Criticality Analysis (FMECA)} is a refinement of FMEA, using 
extra variables: the probability of a component failure mode occurring,
the probability that this will cause a given  top level failure, and the perceived 
criticality. It gives better estimations of product reliability/safety and the 
occurrence of particular system failure modes than FMEA but has similar deficiencies.


\paragraph{Failure Modes, Effects and Diagnostic Analysis (FMEDA)} is a refinement of 
FMEA and FMECA and in addition models self-checking safety elements. It assigns two 
attributes to component failure modes: detectable/undetectable and safe/dangerous.
 Statistical measures about the system can be made and used to classify a 
safety integrity level. It allows designs with in-built safety features to be assessed. 
Otherwise, it has similar deficiencies to FMEA.
However, it has limited support 
for environmental and operational states in sub-systems or components, 
via self checking statistical mitigation. FMEDA is the methodology associated with 
the safety integrity standard EN61508~\cite{en61508}.

\subsection{Summary of Deficiencies in Current Methods}

\paragraph{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level
event, this leads to repeated work, with limited ability for cross checking/model validation.
Also, the analysis process can miss top level events that bottom-up techniques
can reveal.

%\subsection{Bottom-up approach: }

\paragraph{State Explosion problem for FMEA, FMECA, FMEDA.}
The bottom-up techniques all suffer from % a problem of 
state explosion.
To perform the analysis rigorously, we would need to consider the effect
of a component failure against all other components. Adding environmental
and operational states further increases the state explosion.

Let $N$ be the number of components in our system, and $K$ be the average number of component failure modes
(ways in which a component can fail). The approximate total number of base component failure modes
is $N \times K$. 
%
The total number of cases to examine, to determine the effect of all failure modes 
on all 
components 
will be approximately $(N-1) \times N \times K$. %, in effect a very large set cross product.
%
If $E$ is the number of environmental conditions to consider
in a system, and $A$ the number of applied/operational states (or modes of the system),
the bottom-up analyst is presented with two
additional %cross product 
factors, yielding approximately
$(N-1) \times N \times K \times E \times A$.
%
If we put some typical very small embedded system numbers\footnote{These figures would
be typical of a very simple temperature controller, with a micro-controller, sensors, an RS485 interface,
supporting circuitry and heater circuitry.}
 into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$
we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $ checks to perform.
%
To look in detail at half a million fault~scenarios is obviously impractical.


% Requirements for an improved methodology The deficiencies identified in the 
% current methodologies are used to establish criteria for an improved methodology.

\paragraph{Reasoning distance - complexity and reachability.}
\label{sec:rd}
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
working heuristically. A base component failure will typically 
be conceptually removed by several stages from a top level event.
%In electronics terms, all components on the signal path from the component that failed.
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components
that must interact along the signal path to reach the top level event.
Where $C$ represents the set of components in a failure mode causation chain,
$c_i$ represents a component in $C$ and
the function $fm$ returns the  failure modes for a given component, equation
\ref{eqn:complexity}, returns the `reasoning~distance'.
\begin{equation}
R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
\label{eqn:complexity} 
\end{equation}
%
The reasoning distance is a value representing the number of failure modes
to consider to rigorously determine the causation chain
from the base component failure to the system level event.
%
The reasoning distance serves to show that when the causes of a top level
event are completely determined, a large amount of work, not
typical of heuristic or intuitive interpretation, is required.

Reasoning distances will be large for complicated systems, and this is therefore a weakness in both
FMEA and FTA type analyses. This concept is developed further to create a metric for comparing 
complexities from FMEA and FMMD analysis in section~\ref{sec:cc}.

% could have a chapter on this.
% take a circuit or system and follow all the interactions
% to the components that cause the system level event.

\paragraph{Multiple Events from one base component failure mode.}
A base component failure may potentially cause more than one
system level failure mode.
It could be possible to identify one top level event associated with
a {\bc} {\fm} and not investigate other possibilities, using FMEA or FTA techniques. 
 
 
\paragraph{Software FMEA models are performed separately from Hardware FMEA.}
%If software FMEA or Software FTA is performed it is always performed separately from
%hardware FMEA.
Work on  SFMEA (which is yet to be widely employed in international standards) does not seek to integrate
hardware and software models, but to perform
FMEA on the software in isolation~\cite{procsfmea}.
Some work has been performed using databases
to track the relationships between variables 
and system failure modes~\cite{procsfmeadb}, and work has been performed to 
introduce automation into the FMEA process~\cite{appswfmea} and code analysis
automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing 
failure causation through the software hardware interfaces.

Although the SFMEA and hardware FMEAs are performed separately,
some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive)
to be performed on the same system to provide insight into the
software hardware/interface~\cite{embedsfmea}. 
Although this
would give a better picture of the failure mode behaviour, it
is by no means a rigorous approach to tracing errors that may occur in hardware
through to the top (and therefore ultimately controlling) layer of software.
%\section{Requirements for a new static failure mode Analysis methodology}

\section{Desirable Criteria.}
From the deficiencies outlined above,  we can form a set of desirable criteria for an enhanced failure mode methodology.
{ %\small
\label{criteria}
\begin{enumerate}
%\begin{itemize}
\label{fmmdreq}
\item Address the state explosion problem. % 1
\item Ensure that all component failure modes are considered in the model. % 2
\item Be easy to integrate mechanical, electronic and software models \cite{sccs}[p.287]. %3
\item Be modular, in that commonly used {\fgs} can be re-used in other designs/projects. %4
\item Have a formal basis, i.e. be able to produce mathematical traceability %5
for its results, such as  error causation trees.%, reliability and safety statistics.
%\item It should be easy to use, ideally using a 
%graphical syntax (as opposed to a formal symbolic/mathematical text based language).
%\item From the top down, the FMMD model of a system, should follow a logical de-composition of the functionality
%to smaller and smaller functional groupings--or--modules. \cite{maikowski}.
\item Be able to model multiple (simultaneous) failure modes.% 6 % from the base component level up.
\end{enumerate}
%\end{itemize}
}


% 

% The design process follows this 
%rationale, sub-systems are build t%o perform often basic functions from base components.
%We can term these small groups {\fgs}.
% 
% Components should be collected
% into small functional groups to enable the examination of the effect of a
% component failure mode on the other components in the group.
% Once we have the failure modes, or symptoms of failure of a {\fg}
% it can now be considered as `derived component' with a known set 
% of failure symptoms. We can use this `derived component' to build higher level 
% functional groups.
% 
% This helps with the reasoning distance problem,
% because we can trace failure modes back through complex interactions and have a structure to
% base our reasoning on, at each stage.
% 


%Development of the new methodology 
% 
% \section{An ontology of failure modes}
% In order to address the state explosion problem, the process must be modular
%and deal with small groups of components at a time. This approach should address the state explosion problem : criteria 1.
% An ontology is now developed of  
% failure modes and their relationship to environmental factors, 
% applied/operational states and the hierarchical nature inherent in product design, 
% defining the relationships between the system as a whole, components, 
% failure modes, operational and environmental states. 
% 
% 
% Components have sets of failure modes associated with them.
% Failure modes for common components may be found in 
% the literature~\cite{fmd91,mil1991}.
% We can associate a component with its failure modes.
% This is represented in UML in figure \ref{fig:component_concept}.
% 
% \begin{figure}[h]
%  \centering
%  \includegraphics[width=200pt,keepaspectratio=true]{./component.png}
%  % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
%  \caption{Component with failure modes UML diagram}
%  \label{fig:component_concept}
% \end{figure}

% 
% \subsection{Modular Design}
% 
% When designing a system from the bottom-up, small groups of components are selected to perform
% simple functions. These can be termed {\fgs}.
% When the failure mode behaviour, or symptoms of failure 
% of a {\fg} are determined, it can be treated as a component in its own right.
% 
% % Functional groups
% % are then brought together to form more complex and higher level {\fgs}.
% Used in this way the {\fg} has become a {\dc}. The symptoms of failure
% of the {\fg} can be considered the failure modes of its {\dc}.
% Derived~Components can be used to create higher level {\fgs}.
% Repeating this process will lead to identify-able higher level
% groups, often referred to as sub-systems. We can call the entire collection/hierarchy
% of sub-systems the system. 



\section{The proposed Methodology}
\label{fmmdproc}
% Any new static failure mode methodology must ensure that it 
% represents all component failure modes and it therefore should be bottom-up, 
% starting with individual component failure modes.
To ensure all component failure modes are represented, the new methodology must be bottom-up.
%
This seems essential to satisfy criterion 2.
The proposed methodology is therefore a bottom-up process
starting with base~components.
%
Since we are only modelling failure modes, which could arise from
mechanical, electronic or software components,
criterion 3 is satisfied.
%
In order to address the state explosion problem, the process should be modular and hierarchical,
dealing with small groups of components at a time; this should address criterion 1.


%\paragraph{Outline of the Failure mode methodology.}
%
A {\em {\fg}}, is defined as a small collection of components
that interact to provide
a function or task within a system.
%
In the proposed methodology components are collected into functional groups
and each component failure (and possibly multiple simultaneous component failures) are considered in the 
context of the {\fg}.

%% GARK
%
The component failures are termed {\em{\fcs}}. %`test~cases'. 
For each {\fc}
there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}.
%
% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
%
%From the perspective of the {\fg} failures of components will be symptoms.
It is conjectured that many symptoms will be common. That is to say
that component failures will often cause the same symptoms of failure
from the perspective of a {\fg}.



%
A common symptom collection stage is now applied. Here common symptoms are collected
from the results of the {\fcs}. Because it is possible to model combinations of failures,
criterion 6 is satisfied.
%
With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}.
The failure modes of this new {\dc} are the symptoms of the {\fg} from which it was derived.% from.
This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed
modules available for re-use.
 
By using {\dcs} in higher level functional groups, a hierarchy can be built representing
the failure mode behaviour of a system. Because the hierarchy maintains information 
linking the symptoms  to component failure modes (via {\fcs}), we have traceable
reasoning connections from base component failures to top level failures.
The traceability should satisfy criterion 5.

%  ONTOLOGY - NO ROOM IN 6 PAGES OF PAPER
% \paragraph{Environmental Conditions, Operational States.}
% 
% Any real world sub-system will exist in a variable environment
% and may have several modes of operation.
% In order to find all possible failures, a sub-system 
% must be analysed for each operational state
% and environmental condition that could affect it.
% %
% A question is raised here: which objects should we 
% associate  the environmental and the operational states with ?
% There are three objects in our model to which these considerations could be applied.
% We could apply these conditions  
% to {\fgs}, components, or {\dcs}.
% 
% \paragraph {Environmental Conditions.}
% 
% Environmental conditions are external to the
% {\fg} and are often things over which the system has no direct control
% ( e.g. ambient temperature, pressure or  electrical interference levels).
% %
% Environmental conditions may affect different components in a {\fg}
% in different ways.
% 
% For instance, a system may be specified for
% $0\oc$  to $85\oc$ operation, but some components
% may show failure behaviour between $60\oc$  and $85\oc$ 
% \footnote{Opto-isolators typically show marked performance decrease after
% $60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
% Other components may operate comfortably within that whole temperature range specified.
% Environmental conditions will have an effect on the {\fg} and the {\dc},
% but they will have specific effects on individual components.
% 
% It seems obvious that
% environmental conditions should apply to components.
% %A component will hold a set of environmental states that
% %affect it. 
% 
% \paragraph {Operational States}
% 
% Sub-systems may have specific operational states.
% These could be a general health level, such as 
% normal operation, graceful degradation or lockout.
% Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state.
% 
% Operational states are conditions that apply to some functional groups, not individual components.

%\section{The Non-Inverting Operational Amplifier}
%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{Worked Example: Non-Inverting Amplifier}

%% here bring in sys safety papaer from 2011
%%
%% GARK BEGIN




To demonstrate the principles behind FMMD, we use it to analyse a 
commonly used circuit, the non-inverting  op amp~\cite{aoe}[p.234], shown in figure \ref{fig:noninvamp}.



\begin{figure}[h+]
 \centering
 %\includegraphics[width=100pt,keepaspectratio=true]{../../noninvopamp/noninv.png}
 \includegraphics[width=100pt,keepaspectratio=true]{./CH4_FMMD/noninv.png}
 % noninv.jpg: 341x186 pixel, 72dpi, 12.03x6.56 cm, bb=0 0 341 186
 \caption{Standard non inverting amplifier configuration}
 \label{fig:noninvamp}
\end{figure}



The function of the resistors in this circuit is to set the amplifier gain.
They operate as a potential divider and program the minus input on the op-amp
to balance them against the positive input, giving the voltage gain ($G_v$)
defined by $ G_v = 1 + \frac{R2}{R1} $ at the output.



As the resistors work to provide a specific function, that of a potential divider,
we can treat them as a functional group. This functional group has two members, $R1$ and $R2$.
Using the EN298 specification for resistor failure~\cite{en298}[App.A],
we can assign  failure modes of $OPEN$ and $SHORT$ to the resistors (assignment of failure modes 
is discussed in more detail in section~\ref{sec:resistorfm}).
 
We represent a resistor and its failure modes as a directed acyclic graph (DAG)
(see figure \ref{fig:rdag}).
\begin{figure}[h+]
 \centering
 \begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
     \tikzstyle{every pin edge}=[<-,shorten <=1pt]
     \tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
     \tikzstyle{component}=[fmmde, fill=green!50];
     \tikzstyle{failure}=[fmmde, fill=red!50];
     \tikzstyle{symptom}=[fmmde, fill=blue!50];
     \tikzstyle{annot} = [text width=4em, text centered]
     \node[component] (R) at (0,-0.8) {$R$};
     \node[failure] (RSHORT) at (\layersep,-0) {$R_{SHORT}$};
     \node[failure] (ROPEN) at (\layersep,-1.6) {$R_{OPEN}$};
     \path (R) edge (RSHORT);
     \path (R) edge (ROPEN);
 \end{tikzpicture}
 \caption{DAG representing a resistor and its failure modes}
 \label{fig:rdag}
 \end{figure}
 
Thus $R1$ has failure modes $\{R1\_OPEN, R1\_SHORT\}$ and $R2$ has failure modes $\{R2\_OPEN, R2\_SHORT\}$.



%     
We look at each of these base component failure modes,
and determine how they affect the operation of the potential divider.
%Each failure mode scenario we look at will be given a test case number,
%which is represented on the diagram, with an asterisk marking 
%which failure modes is modelling (see figure \ref{fig:fg1a}).

 


 
For this example we look at single failure modes only.
For each failure mode in our {\fg} `potential~divider',
we can assign a {\fc} number (see table \ref{tbl:pdfmea}).
Each {\fc} is analysed to determine the `symptom'
of the potential dividers' operation. For instance
if resistor $R_1$ was to go open, then the circuit would not be grounded and the 
voltage output from it would float high (+ve).
This would mean the symptom of the failed potential divider would be that it
gives a high voltage output.%We can now consider the {\fg}
%as a component in its own right, and its symptoms as its failure modes.

{ \small
\begin{table}[ht]
\caption{Potential Divider: Failure Mode Effects Analysis: Single Faults} % title of Table
\centering % used for centering table
\begin{tabular}{||l|c|c|l||}
\hline \hline
 \textbf{Fault}    & \textbf{Pot.Div} &   \textbf{Symptom}   \\
 \textbf{Scenario} &  \textbf{Effect} &   \textbf{Description}   \\
%   R         &    wire        & res +         & res -    & description
\hline
\hline
 FS1: $R_1$ SHORT    &  LOW       &          LowPD \\ 
 FS2: $R_1$  OPEN    &  HIGH        &         HighPD \\ \hline
 FS3: $R_2$ SHORT    &  HIGH        &        HighPD \\  
 FS4: $R_2$ OPEN     &  LOW         &        LowPD \\ \hline
\hline
\end{tabular} 
\label{tbl:pdfmea}
\end{table}
}


\vbox{
From table  \ref{tbl:pdfmea} we can see that the resistor 
failures modes lead to some common symptoms.
By drawing directed edges, from the failure modes to the symptoms
we can show the relationships between the component failure modes and resultant symptoms.
%The {\fg} can now be considered a derived component.
This is represented in the DAG in figure \ref{fig:fg1adag}.
}

\begin{figure}[h]
 \centering
 \begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
     \tikzstyle{every pin edge}=[<-,shorten <=1pt]
     \tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
     \tikzstyle{component}=[fmmde, fill=green!50];
     \tikzstyle{failure}=[fmmde, fill=red!50];
     \tikzstyle{symptom}=[fmmde, fill=blue!50];
     \tikzstyle{annot} = [text width=4em, text centered]
 
     \node[component] (R1) at (0,-0.7) {$R_1$};
     \node[component] (R2) at (0,-1.9) {$R_2$};

     \node[failure] (R1SHORT) at (\layersep,-0) {$R1_{Sh}$};
     \node[failure] (R1OPEN) at (\layersep,-1.1) {$R1_{Op}$};

     \node[failure] (R2SHORT) at (\layersep,-2.4) {$R2_{Sh}$};
     \node[failure] (R2OPEN) at (\layersep,-3.7) {$R2_{Op}$};
 
     \path (R1) edge (R1SHORT);
     \path (R1) edge (R1OPEN);

     \path (R2) edge (R2SHORT);
     \path (R2) edge (R2OPEN);

     % Potential divider failure modes
     %  
     \node[symptom]  (PDHIGH) at (\layersep*2,-0.7) {$PD_{HIGH}$};
     \node[symptom] (PDLOW) at (\layersep*2,-2.2) {$PD_{LOW}$};

     \path (R1OPEN) edge (PDHIGH);
     \path (R2SHORT) edge (PDHIGH);

     \path (R2OPEN) edge (PDLOW);
     \path (R1SHORT) edge (PDLOW);

 \end{tikzpicture}

 \caption{Failure symptoms of the  `Potential Divider'}
 \label{fig:fg1adag}
 \end{figure}
 

We can now make a `derived component' to represent this potential divider.
This can be named \textbf{PD}.
This {\dc} will have two failure modes.
We can use the symbol $\derivec$ to represent the process of taking the analysed 
{\fg} and creating from it, a {\dc}. The creation of the {\dc} \textbf{PD} is
represented in figure~\ref{fig:dc1}.

%We could represent it algebraically thus: $ \derivec(PotDiv) = 
\begin{figure}[h+]
 \centering
 \includegraphics[width=200pt,keepaspectratio=true]{./CH4_FMMD/dc1.png} %%% Where the f**king hell is this file ????? in an old paper even in the SYSSAFE2011
 % dc1.jpg: 430x619 pixel, 72dpi, 15.17x21.84 cm, bb=0 0 430 619
 \caption{From functional group to derived component}
 \label{fig:dc1}
\end{figure}


We can now represent the potential divider as a {\dc}.
Because we have its symptoms (or failure mode behaviour),
we can treat these as the failure modes of a new {\dc}.
We can represent this as a DAG (see figure \ref{fig:dc1dag}).

\begin{figure}[h+]
 \centering
 \begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
     \tikzstyle{every pin edge}=[<-,shorten <=1pt]
     \tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
     \tikzstyle{component}=[fmmde, fill=green!50];
     \tikzstyle{failure}=[fmmde, fill=red!50];
     \tikzstyle{symptom}=[fmmde, fill=blue!50];
     \tikzstyle{annot} = [text width=4em, text centered]
     \node[component] (PD) at (0,-0.8) {$PD$};
     \node[symptom] (PDHIGH) at (\layersep,-0) {$PD_{HIGH}$};
     \node[symptom] (PDLOW) at (\layersep,-1.6) {$PD_{LOW}$};
     \path (PD) edge (PDHIGH);
     \path (PD) edge (PDLOW);
 \end{tikzpicture}
 \caption{DAG representing a Potential Divider (PD) its failure symptoms}
 \label{fig:dc1dag}
 \end{figure}

The derived component is defined by its failure modes and 
the functional group used to derive it.
%We can consider this an an orthogonal WHAT???? Group ???? Collection ????
We now have a {\dc} model for a generic potential divider, and can use it
as a building block for other {\fgs} in the same way as we used the base components $R1$ and $R2$.

\clearpage

%\paragraph{Failure Mode Analysis of the OP-AMP}

Let use now consider the op-amp. According to 
FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes:
latchup(12.5\%), latchdown(6\%), nooperation(31.3\%), lowslewrate(50\%).
\nocite{mil1991}

%\ifthenelse {\boolean{dag}}
%{
We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
\begin{figure}[h+]
 \centering
 \begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
     \tikzstyle{every pin edge}=[<-,shorten <=1pt]
     \tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
     \tikzstyle{component}=[fmmde, fill=green!50];
     \tikzstyle{failure}=[fmmde, fill=red!50];
     \tikzstyle{symptom}=[fmmde, fill=blue!50];
     \tikzstyle{annot} = [text width=4em, text centered]

     \node[component] (OPAMP) at (0,-1.8) {$OPAMP$};
   
     \node[failure] (OPAMPLU) at (\layersep,-0) {l-up};
     \node[failure] (OPAMPLD) at (\layersep,-1.2) {l-dn};
     \node[failure] (OPAMPNP) at (\layersep,-2.4) {noop};
     \node[failure] (OPAMPLS) at (\layersep,-3.6) {lowslew};

     \path (OPAMP) edge (OPAMPLU);
     \path (OPAMP) edge (OPAMPLD);
     \path (OPAMP) edge (OPAMPNP);
     \path (OPAMP) edge (OPAMPLS);
   
 \end{tikzpicture}
 % End of code
 \caption{DAG representing failure modes of an Op-amp}
 \label{fig:op1dag}
 \end{figure}

%}
%{
%}
\clearpage
%\paragraph{Modelling the OP amp with the potential divider.}
We can now consider merging the OP amp and the potential divider, to
form a {\fg} to represent the non inverting amplifier. We have the failure modes of the {\dc} for the potential divider, 
so we do not need to go back and consider the individual resistor failure modes that defined its behaviour.


 
We can now create a  {\fg} for the non-inverting amplifier
by bringing together the failure modes from \textbf{opamp} and \textbf{PD}.
Each of these failure modes will be given a {\fc} for analysis,
and this is represented in table \ref{ampfmea}.
 
%\clearpage
{\footnotesize
\begin{table}[h+]
\caption{Non Inverting Amplifier: Failure Mode Effects Analysis: Single Faults} % title of Table
\centering % used for centering table
\begin{tabular}{||l|c|c|l||}
\hline \hline
 \textbf{Fault}    & \textbf{Amplifier} &   \textbf{Symptom}   \\
 \textbf{Scenario} &  \textbf{Effect} &   \textbf{Description}   \\
%   R         &    wire        & res +         & res -    & description
\hline
\hline
 FS1: $OPAMP$    &  Output               &       AMPHigh \\ 
  LatchUP                        &  High                          &          \\ \hline

 FS2: $OPAMP$  &  Output Low&       AMPLow \\  
   LatchDown                       &   Low gain                         &          \\ \hline

 FS3: $OPAMP$  &  Output Low         &        AMPLow \\  
   No Operation                      &                       &               \\ \hline

 FS4: $OPAMP$   &  Low pass  &       LowPass \\  
     Low Slew   &  filtering &              \\ \hline

 FS5: $PD$          &   Output High         &       AMPHigh \\  
    LowPD                     &                       &              \\ \hline

 FS6: $PD$       &  Output Low &        AMPLow \\  
    HighPD       &   Low Gain   &              \\ \hline
 %TC7: $R_2$ OPEN     &  LOW       &      &  LowPD \\ \hline
\hline
\end{tabular} 
\label{ampfmea}
\end{table}
}


 

\begin{figure}[h+]
 \centering
 \begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
     \tikzstyle{every pin edge}=[<-,shorten <=1pt]
     \tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
     \tikzstyle{component}=[fmmde, fill=green!50];
     \tikzstyle{failure}=[fmmde, fill=red!50];
     \tikzstyle{symptom}=[fmmde, fill=blue!50];
     \tikzstyle{annot} = [text width=4em, text centered]
 
     % Draw the input layer nodes
     %\foreach \name / \y in {1,...,4}
     % This is the same as writing \foreach \name / \y in {1/1,2/2,3/3,4/4}
     %    \node[component, pin=left:Input \#\y] (I-\name) at (0,-\y) {};
 
     \node[component] (OPAMP) at (0,-1.8) {$OPAMP$};
     \node[component] (R1) at (0,-6) {$R_1$};
     \node[component] (R2) at (0,-7.6) {$R_2$};

     %\node[component] (C-3) at (0,-5) {$C^0_3$};
     %\node[component] (K-4) at (0,-8) {$K^0_4$};
     %\node[component] (C-5) at (0,-10) {$C^0_5$};
     %\node[component] (C-6) at (0,-12) {$C^0_6$};
     %\node[component] (K-7) at (0,-15) {$K^0_7$};
 
     % Draw the hidden layer nodes
     %\foreach \name / \y in {1,...,5}
     %    \path[yshift=0.5cm]

             \node[failure] (OPAMPLU) at (\layersep,-0) {l-up};
             \node[failure] (OPAMPLD) at (\layersep,-1.2) {l-dn};
             \node[failure] (OPAMPNP) at (\layersep,-2.5) {noop};
             \node[failure] (OPAMPLS) at (\layersep,-3.8) {lowslew};

             \node[failure] (R1SHORT) at (\layersep,-5.1) {$R1_{Sh}$};
             \node[failure] (R1OPEN) at (\layersep,-6.4) {$R1_{Op}$};

            \node[failure] (R2SHORT) at (\layersep,-7.7) {$R2_{Sh}$};
             \node[failure] (R2OPEN) at (\layersep,-9.0) {$R2_{Op}$};



     % Draw the output layer node
 
%      % Connect every node in the input layer with every node in the
%      % hidden layer.
%      %\foreach \source in {1,...,4}
%      %    \foreach \dest in {1,...,5}
     \path (OPAMP) edge (OPAMPLU);
     \path (OPAMP) edge (OPAMPLD);
     \path (OPAMP) edge (OPAMPNP);
\path (OPAMP) edge (OPAMPLS);

     \path (R1) edge (R1SHORT);
     \path (R1) edge (R1OPEN);

     \path (R2) edge (R2SHORT);
     \path (R2) edge (R2OPEN);


     % Potential divider failure modes
     %  
     \node[symptom]  (PDHIGH) at (\layersep*2,-6) {$PD_{HIGH}$};
     \node[symptom] (PDLOW) at (\layersep*2,-7.6) {$PD_{LOW}$};



     \path (R1OPEN) edge (PDHIGH);
     \path (R2SHORT) edge (PDHIGH);


     \path (R2OPEN) edge (PDLOW);
     \path (R1SHORT) edge (PDLOW);



     \node[symptom]  (AMPHIGH) at (\layersep*3.4,-3) {$AMP_{HIGH}$};
     \node[symptom] (AMPLOW) at (\layersep*3.4,-5) {$AMP_{LOW}$};
      \node[symptom] (AMPLP) at (\layersep*3.4,-7) {$LOWPASS$};

     \path (PDLOW) edge (AMPHIGH);
     \path (OPAMPLU) edge (AMPHIGH);

     \path (PDHIGH) edge (AMPLOW);
     \path (OPAMPNP)  edge (AMPLOW);
     \path (OPAMPLD) edge (AMPLOW);

     \path (OPAMPLS) edge (AMPLP);
%      %\node[symptom,pin={[pin edge={->}]right:Output}, right of=C-1a] (O) {};
%      \node[symptom, right of=C-1a] (s1) {s1};
%      \node[symptom, right of=C-2a] (s2) {s2};
%  
%  
%  
%      \path (C-2b) edge (s1);
%      \path (C-1a) edge (s1);
%  
%      \path (C-2a) edge (s2);
%      \path (C-1b) edge (s2);
%  
%      %\node[component, right of=s1] (DC) {$C^1_1$};
%  
%      %\path (s1) edge (DC);
%      %\path (s2) edge (DC);
%      
%  
%  
%      % Connect every node in the hidden layer with the output layer
%      %\foreach \source in {1,...,5}
%      %    \path (H-\source) edge (O);
%  
%      % Annotate the layers
%      \node[annot,above of=C-1a, node distance=1cm] (hl) {Failure modes};
%      \node[annot,left of=hl] {Base Components};
%      \node[annot,right of=hl](s) {Symptoms};
     %\node[annot,right of=s](dcl) {Derived Component};
 \end{tikzpicture}
 % End of code
 \caption{Full DAG representing failure modes and symptoms of the Non Inverting Op-amp Circuit}
 \label{fig:noninvdag1}
 \end{figure}

Let us consider, for the sake of the example, that the voltage follower (very low gain of 1.0)
amplification characteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application
in hand (say milli-volt signal amplification).

For this amplifier configuration we have three failure modes; $AMPHigh, AMPLow, LowPass$.%see figure~\ref{fig:fgampb}.
This model now has two stages of analysis hierarchy, as represented in figure~\ref{fig:dc2}.

\begin{figure}[h]
 \centering
 \includegraphics[width=225pt]{./CH4_FMMD/dc2.png}
 % dc2.png: 635x778 pixel, 72dpi, 22.40x27.45 cm, bb=0 0 635 778
 \caption{Hierarchy representing the two stage FMMD analysis of the non-inverting amplifier}
 \label{fig:dc2}
\end{figure}

We can now expand the $PD$ {\dc} and  have a full FMMD failure %mode 
model
drawn as a DAG, which we can use traverse, and thus determine all possible causes to
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier.
%
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies.





\paragraph{Worked example. Effect on State explosion.}
The potential divider {\dc} reduced the number of failures to consider from four to two.
The op-amp and potential divider modelled together, reduced the number of 
base component failures from eight to three failure symptoms. 
%
In general,
because symptoms are collected, we can state
the number of failure symptoms for a {\fg} will be less than or equal to the number
of component failures.
% In practise the number of symptoms is usually around half the 
%number of component failure modes, for each stage of FMMD analysis.
%This methodology has also been applied elsewhere to the inverting amplifier configuration.
%One can then use use {\dcs} in more complex circuits where the advantages of FMMD become more obvious,
%(such as $8^{th}$ order filters using four bi-quad op-amp stages).



%% GARK END



\clearpage

% 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 (see section~\ref{sec:unitarystate}). 

\section{Defining terms}

The worked example used terms such as {\fg}, component, and {\dc}.
This chapter aims to define these terms.


\subsection{Parts, components and base components}
A component 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''.

This definition of a `part' is useful, but consider combinatorial parts, such as quad packaged op-amps.
Here we have four op-amps on one chip. For FMEA we would consider each op-amp in the package
as a separate building block for a circuit.
We, in fact, need to go a little further than the above definition of a part, 
and say that we want to define an atomic entity used as a building block.
%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.
We define {\bc} to mean a lowest level of assembly `part' or an atomic entity, which ever is the smaller
and component to mean either a part or a sub-assembly. 
Definitions used in FMMD are listed in table~\ref{tbl:fmmd_defs} and discussed below.

%%  FUCKING STEREO SUB_SYSTEM EXAMPLE, THE FUCKING CHILDRENS SECTION

\subsection{Systems, functional groups, sub-systems and failure modes: sound system example}

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.
A modular system common in most homes is the sound separates audio system or stereo hi-fi.
This is now used as an example to describe terms used in FMMD.
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 {\textbf{the CD players internal}} 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 failure 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~\cite{sccs}[p.165] 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  

 

Base Component & An atomic building block. Typically this would be a part on a parts list.
                 In the case of combinatorial packaged parts (such as a chip containing
                 four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}})
       \\
{\em Constraint} & This object must have a defined set of failure~modes \\    \hline 


Component  & A building block, this may be a part from a parts list or a sub-assembly. \\ \hline



Sub-system & A part of a system, sub-systems may contain sub-systems etc. \\ \hline % in FMMD terminology
             %this would be both a {\em{\dc}} and a {\fg}. \\
%{\em 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 % WHICH MUST BE UNIQUE AND SEPARATE WITHIN THE \fg
               a combination of its component failure modes. \\ \hline


Derived Component & A theoretical component, created to represent the failure
                    mode behaviour of a {\fg}. \\  
{\em Constraint} & This object must have a defined set of failure~modes. \\    \hline 


Unitary State & A component with `unitary~state' failure modes, means that it may cannot fail
with more than one of its failure modes at a time.\\    \hline 

Failure Scenario & A single failure mode (or a combination), used to
                   determine failure mode effects on a system or {\fg}.
\\

 \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}.}.


\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}

The UML class 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 (FTA)~\cite{nasafta}\cite{nucfta} ,
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 {\bcs}. 
%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 {\bc} 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 a {\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}[p.8].
%
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:algorithmfmmd}.
}

% 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,
corresponding 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}


%% Here we need how this meta model translates into the FMMD Hierarchy

\subsection{How the UML Meta Model maps to an FMMD Hierarchy}

The UML meta model above (see figure~\ref{fig:cfg}) describes a hierarchical structure. %% Might be a UML pattern that is well known ..... 05MAY2012
This is because, as {\dcs} inherit the properties of 
components, {\dcs} may be used to form {\fgs}.
%
Consider the hierarchy from the example in figure~\ref{fig:dc2}.
The lowest level in this hierarchy are the {\bcs}, the resistors and the op-amp.
%
The resistors are collected into a {\fg}, and the ${PD}$ derived component is created above them.
%
As this derived component inherits the properties of a component, we may use
it in {\fg} higher in the hierarchy. 
%
The $PD$ derived component is now placed into a functional group
with the op-amp. 
%
This {\fg} is now analysed and a {\dc} created to 
represent the failure mode behaviour of the $INVAMP$.
%
We may now use the  $INVAMP$ {\dc} in even higher level {\fgs}.



\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 led 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 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 $$
% 


%%-
%%- 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 under which 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~\cite{tlp181}
which is typically affected at around \oc{60}. Most electrical components are far more robust to temperature.}.
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-systems 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}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%





%$$ \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:

\begin{equation}
 \label{eqn:abslevinc}
 \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1.
\end{equation}

\paragraph{Functional Groups may be indexed.}
We will typically have more than one {\fg} on each level of FMMD hierarchy (except 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 {\dc} must have a higher abstraction level than the {\fg}
from which it was derived---or---in other words, the symptom abstraction process `$\derivec$' increments
the abstraction level $\abslev$, as stated in equation~\ref{eqn:abslevinc}.

The symptom abstraction process is described formally and algorithmically 
in sections~\ref{sec:formalfmmd} and \ref{sec:algorithmfmmd} respectively.


\paragraph{Surjective constraint applied to symptom collection.}
We can stipulate that symptom collection process is surjective~\cite{dmfnt}.
% 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}[3-116] 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{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$ where $c_4 a$ is a failure mode in FG1 and $c_1 a$ from FG2.
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
implement traceable and provable, complete double failure mode 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


\section{Conclusion}
%\subsection{Evaluation of FMMD}

%By applying the methodology in section \ref{fmmdproc}, the wishlist can
%now be evaluated for the proposed FMMD methodology.

We evaluate the FMMD method using the criteria in section \ref{fmmdreq}.
Table \ref{tbl:comparison} compares the current methodologies and FMMD using these criteria.
{ %\small
\begin{itemize}
\item{State explosion is reduced,}
%State Explosion is reduced,
because small collections of components are dealt within functional groups
which are used to create derived components which are then used in an hierarchical manner.

\item{All component failure modes must be considered in the model.}
%All component failure modes must be considered in the model.
Since the proposed methodology is bottom-up,
this means that we can ensure/check that all component failure modes are handled.


\item{ It should be straightforward to integrate mechanical, electronic and software models,}
%It should be straight forward to integrate mechanical, electronic and software models,
because FMMD models in terms of  failure modes only. % we have a generic failure mode entities to model.
%We can describe a mechanical, electrical or software component in terms of its failure modes. 
%
Because of this 
we can model and analyse integrated electromechanical systems, controlled by computers,
using a common notation. An electronic/software FMMD example is given in~\ref{sec:elecsw}.

\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
%It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
The hierarchical nature, taking {\fg}s and deriving components from them, means that 
commonly used {\dcs} can be re-used in a design % (for instance self checking digital inputs)
or even in other projects where the same {\dc} is used. Several examples of re-used {\dcs}
may be found in chapter~\ref{sec:chap5}.


\item{ Formal basis: data should be available to produce mathematical proofs and traceability.}
%It should have a formal basis, data should be available to produce mathematical proofs
%for its results
Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs},
system level failure modes are traceable back down the fault tree to
component level failure modes. 
%
This allows cut sets~\cite{nasafta}[Ch.1p3]
to be determined by traversing the DAG from top level events down to their causes.
%
An added advantage of FMMD, is that there are typically several stages of reasoning
to go from a base component failure mode to a system/top level event.
%
Each of these reasoning stages are represented by {\fg} to {\dc} analysis processes, traversing up the FMMD hierarchy.
%
Compare this to traditional FMEA where
we only have one reasoning stage, that of base component failure mode to top level event.

% \item{ It should be capable of producing reliability and danger evaluation statistics.}
% The minimal cuts sets for the system level failures can have computed MTTF
% and danger evaluation statistics sourced from the component failure mode statistics~\cite{fmd91,mil1991}.

% \item{ It should be easy to use, ideally 
% using a graphical syntax (as opposed to a formal mathematical one).}
% A modified form of constraint diagram (an extension of Euler diagrams) has
% been developed to support the FMMD methodology.
% This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
% advance a {\fg} to a {\dc}.


% \item{ From the top down the failure mode model should follow a logical de-composition of the functionality
% to smaller and smaller functional modules \cite{maikowski}.}
% The bottom-up approach fulfils the  logical de-composition requirement, because the {\fg}s
% are built from components performing a given task. 
% 

\item{ Multiple failure modes (conjunction - where more that one failure mode is active) 
may be modelled from the base component level up.}
%Multiple failure modes (conjunction) may be modelled from the base component level up.
By breaking the problem of failure mode analysis into small stages
and building a hierarchy, the problems associated with needing to 
analyse all possible combinations of base level components
within a system are reduced.

% by an exponential order.
This is because the multiple failure modes considered
within {\fgs} have fewer failure modes to consider 
at each FMMD stage.
Where appropriate, multiple simultaneous failures can be modelled by
introducing {\fcs} %test~cases 
where the conjunction of failure modes is considered.
An example demonstrating multiple failure mode analysis may be found in section~\ref{sec:Pt100}.
\end{itemize}
}

{ %\tiny
\begin{table}[ht]
\caption{Features of static Failure Mode analysis methodologies} % title of Table
\centering % used for centering table
\begin{tabular}{||l|c|c|c|c|c||}
\hline \hline
% \textbf{Des.} & \textbf{FTA}  & \textbf{FMEA} &   \textbf{FMECA} & \textbf{FDEMA} &   \textbf{FMMD}   \\
\textbf{\tiny Des.} & \textbf{\tiny FTA}  & \textbf{\tiny FMEA} &   \textbf{\tiny FMECA} & \textbf{\tiny FDEMA} &   \textbf{\tiny FMMD}   \\
 \textbf{\tiny Crit.}  &   \textbf{}   & \textbf{}     &   \textbf{}      & \textbf{}      &   \textbf{}   \\
%   R         &    wire        & res +         & res -    & description
\hline
\hline
 C1: % state exp    
                &  partial      &               &                 &               &   $\tickYES$  \\ \hline
 C2: % $\forall$ failures 
                &               &$\tickYES$  &    $\tickYES$   &    $\tickYES$ &  $\tickYES$  \\  \hline
 C3: %mech,elec,s/w & $\tickYES$    
                &               &                 &               &             & $\tickYES$ \\  \hline
 C4: %modular        
                &               &               &                 &  partial      &  $\tickYES$   \\ \hline
 C5: %formal         
                &  partial     &  partial       &  partial       &  partial    &  $\tickYES$   \\ \hline
 C6: %multiple fm    
                &   $\tickYES$  &               &                 &  partial    &  $\tickYES$    \\ \hline
\hline
\hline
\end{tabular} 
\label{tbl:comparison}
\end{table}
}
%\clearpage


%\subsection{}


%This new approach is called 
Failure Mode Modular De-Composition (FMMD) is designed 
to be a more rigorous  and `data~complete' model than
the current four approaches.
%
That is, 
from an FMMD model, we should be able to 
derive outline models that the other four methodologies would have been 
able to create. As this approach is modular, many of the results of 
analysed components may be re-used in other projects, so 
test efficiency is improved.
%Clearly the more complex the original system is the more benefit,
%i.e. less components and derived components, will be produced from decomposing the 
%system into functional groups.

FMMD is based on generic failure modes, so it is not constrained to a 
particular field. It can be applied to mechanical, electrical or software domains. 
It can therefore be used to analyse systems comprised of electrical,
mechanical and software elements in one integrated model.
Furthermore the reasoning path is traceable. By being able to trace a 
top level event down through derived components, to base component
failure modes, with each step annotated as {\fcs}, the model is easier to maintain.

The example used here is deliberately small for the purpose
of being presenting the methodology showing  more than only one stage of hierarchy,
worked examples for common electronic circuits, digital analogue hybrids and software electronic
hybrid systems are given in chapter~\ref{sec:chap5}.
%FMMD has been applied
%to larger systems encompassing mechanical, electrical and software
%elements. 
FMMD represents a new technique in that it
can address all the criteria in table 3, whereas the other methodologies
can only cover some.


FMMD not only has advantages of efficiency (reduction of state explosion), it also
provides the capability to model entire electro-mechanical-software systems using a common notation
and processes.
%\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}.
%




