1980 lines
86 KiB
TeX
1980 lines
86 KiB
TeX
%%
|
|
%% 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
|
|
\ifthenelse {\boolean{paper}}
|
|
{
|
|
paper
|
|
}
|
|
{
|
|
chapter
|
|
}
|
|
starts with a 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.
|
|
|
|
|
|
We briefly analyse four current methodologies.
|
|
Comprehensive overviews of these methodologies may be found
|
|
in ~\cite{safeware,sccs}.
|
|
|
|
\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.
|
|
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
|
|
that must interact 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 (where it is actually performed) 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 separate 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} 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{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 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 to traverse to determine the 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 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
|
|
\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 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}[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: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}
|
|
|
|
|
|
%% 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 the 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 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-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}.
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
|
|
|
|
|
|
%$$ \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.
|
|
|
|
The symptom abstraction process is described formally and algorithmically
|
|
in sections~\ref{sec:formalfmmd} and \ref{algotithmfmmd} 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$.
|
|
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
|
|
|
|
\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.
|
|
|
|
|
|
% \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}.
|
|
%
|
|
|
|
|
|
|
|
|