1857 lines
78 KiB
TeX
1857 lines
78 KiB
TeX
%%
|
|
%% CHAPTER 4 : Failure Mode Modular Discrimination
|
|
%%
|
|
\label{sec:chap4}
|
|
% \ifthenelse {\boolean{paper}}
|
|
% {
|
|
% \abstract{
|
|
% This paper defines %what is meant by
|
|
% the terms
|
|
% components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
|
|
% %The application of Bayes theorem in current methodologies, and
|
|
% %the suitability of the `null hypothesis' or `P' value statistical approach
|
|
% %are discussed.
|
|
% The general concept of the cardinality constrained powerset is introduced
|
|
% and calculations for it described, and then for
|
|
% calculations under `unitary state' fault mode conditions.
|
|
% Data types and their relationships are described using UML.
|
|
% Mathematical constraints and definitions are made using set theory.}
|
|
% }
|
|
% {
|
|
% \section{Overview}
|
|
% This chapter defines the FMMD process and related concepts and calculations.
|
|
% FMMD is in essence modularised FMEA. Rather than taking each component failure mode
|
|
% and extrapolating top level or system failure symptoms from it,
|
|
% small groups of components are collected into {\fgs} and analysed,
|
|
% and then {\dcs} are used to represent the {\fgs}.
|
|
% These {\dcs} are used to then build further {\fgs} until a hierarchy of {\fgs}
|
|
% and {\dcs} has been built, converging to a final {\dc}
|
|
% at the top of the hierarchy.
|
|
%
|
|
% Or in other words we take the traditional FMEA process, and modularise it.
|
|
% We break down each stage of reasoning
|
|
% into small manageable groups, and use the results of those groups, as {\dcs}
|
|
% to build higher level groups.
|
|
% %This has advantages of concentrating
|
|
% %effort in where modules interact,
|
|
|
|
|
|
%% J. Howse 04MAY2012 REMOVEFirstly, %what is meant by
|
|
%% J. Howse 04MAY2012 REMOVEthe terms
|
|
%% J. Howse 04MAY2012 REMOVEcomponents, failure~modes, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes are defined.
|
|
%
|
|
%% J. Howse 04MAY2012 REMOVE The general concept of the cardinality constrained powerset is introduced
|
|
%% J. Howse 04MAY2012 REMOVE and calculations for it described, and performance
|
|
%% J. Howse 04MAY2012 REMOVE calculations (comparing traditional FMEA and FMMD)
|
|
%% J. Howse 04MAY2012 REMOVE are presented. % under `unitary state' fault mode conditions.
|
|
%
|
|
%% J. Howse 04MAY2012 REMOVEData types and their relationships are described using UML.
|
|
%% J. Howse 04MAY2012 REMOVEMathematical constraints and definitions are made using set theory.
|
|
% }
|
|
|
|
|
|
\section{Introduction}
|
|
This chapter
|
|
starts with %starts with %an overview of current failure modelling techniques, and then
|
|
a worked example to introduce % using
|
|
a new methodology,
|
|
Failure Mode Modular De-composition (FMMD).
|
|
This is followed by a discussion on the design of FMMD, a
|
|
%an ontological
|
|
description of the FMMD process and finally the
|
|
data structures required using UML class models.
|
|
|
|
% This chapter defines the FMMD process and related concepts and calculations.
|
|
FMMD is in essence a modularised variant of traditional FMEA~\cite{sccs}[pp.34-38].
|
|
\fmmdgloss
|
|
%
|
|
%FMEA is a bottom-up, or forward search failure mode technique starting with
|
|
%base component failure modes~\cite{safeware}[p.341].
|
|
%
|
|
%\subsection{FMMD Process in outline.}
|
|
%
|
|
In order to analyse from the bottom-up and apply a modular methodology, we need to take
|
|
small groups of components that naturally
|
|
work together to perform a simple function: we term these groups `{\fgs}'.
|
|
%
|
|
\fmmdglossFG
|
|
%
|
|
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.
|
|
%
|
|
%Initial {\fgs} will consist of {\bcs}.
|
|
%
|
|
% and determine a failure mode model for that group.
|
|
%
|
|
% expand 21sep2010
|
|
%The `{\fg}' as used by the analyst is a collection of component failures modes.
|
|
%The analysts interest is in the ways in which the components within the {\fg}
|
|
%can fail.
|
|
%
|
|
All the failure modes of all the components within a {\fg} are collected.
|
|
%
|
|
%As each component %mode holds
|
|
%has a set of failure modes associated with it,
|
|
%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 the failure modes and not sets of failure modes~\cite{joyofsets}[p.8].
|
|
%
|
|
%In practical term each component failure mode is considered as a `failure~scenario' or 'test~case'
|
|
%for the {\fg}.
|
|
%
|
|
Each of these failure modes %, and optionally combinations of them, are
|
|
%formed into failure~scenarios 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 its symptoms of failure.
|
|
%,
|
|
%or the failure modes of the {\dc}.
|
|
%for the {\fg}.
|
|
%
|
|
We view these symptoms as the %derived
|
|
failure modes of the {\fg}.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossSYMPTOM
|
|
%Or in other words
|
|
That is, we can determine how the {\fg} can fail.
|
|
As we now have a set of failure modes for the {\fg} we can treat it as a component.
|
|
We can now consider the {\fg} as a `{\dc}' % sort of super component
|
|
with its own set of failure modes.
|
|
%
|
|
\fmmdglossDC
|
|
% 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}.
|
|
% We analyse each {\fg} in order to determine its failure mode behaviour.
|
|
% %of the {\fg}.
|
|
% With the failure mode behaviour we can obtain a set of failure modes
|
|
% for the {\fg}.
|
|
% %
|
|
% Or in other words we determine how the {\fg}, as an entity can fail.
|
|
% %
|
|
% We can then create a new theoretical component to represent the {\fg}.
|
|
% %
|
|
% We call this a {\dc}.
|
|
% %
|
|
%We term this newly created component as a `{dc}'.
|
|
%This {\dc} has a set of failure modes: we can thus treat it as a `higher~level' component.
|
|
%
|
|
Because a {\dc} has a set of failure modes we can use it in higher level {\fgs}
|
|
which in turn produce higher level {\dcs}.
|
|
%
|
|
We can then use these {\dcs} to build further {\fgs} until a hierarchy of {\fgs}
|
|
and {\dcs} has been built, converging to a final {\dc}
|
|
at the top of the hierarchy.
|
|
%
|
|
The failure modes of the final or top {\dc}
|
|
are the failure modes of the system under investigation.
|
|
%
|
|
That is, we take the traditional FMEA process and modularise it from the bottom-up.
|
|
%We break down each stage of reasoning
|
|
%into small manageable groups, and use the failure mode behaviour from them to create {\dcs}
|
|
%to build higher level groups.
|
|
In this way we can incrementally apply FMEA to an entire system. %, with documented reasoning stages.
|
|
\fmmdglossDC
|
|
\fmmdgloss
|
|
%
|
|
This has advantages of concentrating
|
|
effort in where modules interact (interfaces), of
|
|
being able to re-use work and savings in the complexity of performing
|
|
FMEA (because the analysis is typically performed in several small stages).
|
|
%A notation is then described to index and classify objects created in FMMD hierarchical models.
|
|
|
|
|
|
|
|
% \subsection{Summary of Deficiencies in Current Methods}
|
|
%
|
|
% \paragraph{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
|
|
% level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level
|
|
% event, this leads to repeated work, with limited ability for cross checking/model validation.
|
|
% Also, the analysis process can miss top level events that bottom-up techniques
|
|
% can reveal.
|
|
%
|
|
% %\subsection{Bottom-up approach: }
|
|
%
|
|
% \paragraph{State Explosion problem for FMEA, FMECA, FMEDA.}
|
|
% The bottom-up techniques all suffer from % a problem of
|
|
% state explosion.
|
|
% To perform the analysis rigorously, we would need to consider the effect
|
|
% of a component failure against all other components. Adding environmental
|
|
% and operational states further increases the state explosion.
|
|
%
|
|
% Let $N$ be the number of components in our system, and $K$ be the average number of component failure modes
|
|
% (ways in which a component can fail). The approximate total number of base component failure modes
|
|
% is $N \times K$.
|
|
% %
|
|
% The total number of cases to examine, to determine the effect of all failure modes
|
|
% on all
|
|
% components
|
|
% will be approximately $(N-1) \times N \times K$. %, in effect a very large set cross product.
|
|
% %
|
|
% If $E$ is the number of environmental conditions to consider
|
|
% in a system, and $A$ the number of applied/operational states (or modes of the system),
|
|
% the bottom-up analyst is presented with two
|
|
% additional %cross product
|
|
% factors, yielding approximately
|
|
% $(N-1) \times N \times K \times E \times A$.
|
|
% %
|
|
% If we put some typical very small embedded system numbers\footnote{These figures would
|
|
% be typical of a very simple temperature controller, with a micro-controller, sensors, an RS485 interface,
|
|
% supporting circuitry and heater circuitry.}
|
|
% into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$
|
|
% we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $ checks to perform.
|
|
% %
|
|
% To look in detail at half a million fault~scenarios is obviously impractical.
|
|
%
|
|
%
|
|
% % Requirements for an improved methodology The deficiencies identified in the
|
|
% % current methodologies are used to establish criteria for an improved methodology.
|
|
%
|
|
% \paragraph{Reasoning distance - complexity and reachability.}
|
|
% \label{sec:rd}
|
|
% Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
|
|
% working heuristically. A base component failure will typically
|
|
% be conceptually removed by several stages from a top level event.
|
|
% %In electronics terms, all components on the signal path from the component that failed.
|
|
% The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components
|
|
% that must interact along the signal path to reach the top level event.
|
|
% Where $C$ represents the set of components in a failure mode causation chain,
|
|
% $c_i$ represents a component in $C$ and
|
|
% the function $fm$ returns the failure modes for a given component, equation
|
|
% \ref{eqn:complexity}, returns the `reasoning~distance'.
|
|
% \begin{equation}
|
|
% R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
|
|
% \label{eqn:complexity}
|
|
% \end{equation}
|
|
% %
|
|
% The reasoning distance is a value representing the number of failure modes
|
|
% to consider to rigorously determine the causation chain
|
|
% from the base component failure to the system level event.
|
|
% %
|
|
% The reasoning distance serves to show that when the causes of a top level
|
|
% event are completely determined, a large amount of work, not
|
|
% typical of heuristic or intuitive interpretation, is required.
|
|
%
|
|
% Reasoning distances will be large for complicated systems, and this is therefore a weakness in both
|
|
% FMEA and FTA type analyses. This concept is developed further to create a metric for comparing
|
|
% complexities from FMEA and FMMD analysis in section~\ref{sec:cc}.
|
|
%
|
|
% % could have a chapter on this.
|
|
% % take a circuit or system and follow all the interactions
|
|
% % to the components that cause the system level event.
|
|
%
|
|
% \paragraph{Multiple Events from one base component failure mode.}
|
|
% A base component failure may potentially cause more than one
|
|
% system level failure mode.
|
|
% It could be possible to identify one top level event associated with
|
|
% a {\bc} {\fm} and not investigate other possibilities, using FMEA or FTA techniques.
|
|
%
|
|
%
|
|
% \paragraph{Software FMEA models are performed separately from Hardware FMEA.}
|
|
% %If software FMEA or Software FTA is performed it is always performed separately from
|
|
% %hardware FMEA.
|
|
% Work on SFMEA (which is yet to be widely employed in international standards) does not seek to integrate
|
|
% hardware and software models, but to perform
|
|
% FMEA on the software in isolation~\cite{procsfmea}.
|
|
% Some work has been performed using databases
|
|
% to track the relationships between variables
|
|
% and system failure modes~\cite{procsfmeadb}, and work has been performed to
|
|
% introduce automation into the FMEA process~\cite{appswfmea} and code analysis
|
|
% automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing
|
|
% failure causation through the software hardware interfaces.
|
|
%
|
|
% Although the SFMEA and hardware FMEAs are performed separately,
|
|
% some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive)
|
|
% to be performed on the same system to provide insight into the
|
|
% software hardware/interface~\cite{embedsfmea}.
|
|
% Although this
|
|
% would give a better picture of the failure mode behaviour, it
|
|
% is by no means a rigorous approach to tracing errors that may occur in hardware
|
|
% through to the top (and therefore ultimately controlling) layer of software.
|
|
% %\section{Requirements for a new static failure mode Analysis methodology}
|
|
%
|
|
% \section{Desirable Criteria.}
|
|
% From the deficiencies outlined above, we can form a set of desirable criteria for an enhanced failure mode methodology.
|
|
% { %\small
|
|
% \label{criteria}
|
|
% \begin{enumerate}
|
|
% %\begin{itemize}
|
|
% \label{fmmdreq}
|
|
% \item Address the state explosion problem. % 1
|
|
% \item Ensure that all component failure modes are considered in the model. % 2
|
|
% \item Be easy to integrate mechanical, electronic and software models \cite{sccs}[p.287]. %3
|
|
% \item Be modular, in that commonly used {\fgs} can be re-used in other designs/projects. %4
|
|
% \item Have a formal basis, i.e. be able to produce mathematical traceability %5
|
|
% for its results, such as error causation trees.%, reliability and safety statistics.
|
|
% %\item It should be easy to use, ideally using a
|
|
% %graphical syntax (as opposed to a formal symbolic/mathematical text based language).
|
|
% %\item From the top down, the FMMD model of a system, should follow a logical de-composition of the functionality
|
|
% %to smaller and smaller functional groupings--or--modules. \cite{maikowski}.
|
|
% \item Be able to model multiple (simultaneous) failure modes.% 6 % from the base component level up.
|
|
% \end{enumerate}
|
|
% %\end{itemize}
|
|
% }
|
|
%
|
|
%
|
|
% %
|
|
%
|
|
% % The design process follows this
|
|
% %rationale, sub-systems are build t%o perform often basic functions from base components.
|
|
% %We can term these small groups {\fgs}.
|
|
% %
|
|
% % Components should be collected
|
|
% % into small functional groups to enable the examination of the effect of a
|
|
% % component failure mode on the other components in the group.
|
|
% % Once we have the failure modes, or symptoms of failure of a {\fg}
|
|
% % it can now be considered as `derived component' with a known set
|
|
% % of failure symptoms. We can use this `derived component' to build higher level
|
|
% % functional groups.
|
|
% %
|
|
% % This helps with the reasoning distance problem,
|
|
% % because we can trace failure modes back through complex interactions and have a structure to
|
|
% % base our reasoning on, at each stage.
|
|
% %
|
|
%
|
|
%
|
|
% %Development of the new methodology
|
|
% %
|
|
% % \section{An ontology of failure modes}
|
|
% % In order to address the state explosion problem, the process must be modular
|
|
% %and deal with small groups of components at a time. This approach should address the state explosion problem : criteria 1.
|
|
% % An ontology is now developed of
|
|
% % failure modes and their relationship to environmental factors,
|
|
% % applied/operational states and the hierarchical nature inherent in product design,
|
|
% % defining the relationships between the system as a whole, components,
|
|
% % failure modes, operational and environmental states.
|
|
% %
|
|
% %
|
|
% % Components have sets of failure modes associated with them.
|
|
% % Failure modes for common components may be found in
|
|
% % the literature~\cite{fmd91,mil1991}.
|
|
% % We can associate a component with its failure modes.
|
|
% % This is represented in UML in figure \ref{fig:component_concept}.
|
|
% %
|
|
% % \begin{figure}[h]
|
|
% % \centering
|
|
% % \includegraphics[width=200pt,keepaspectratio=true]{./component.png}
|
|
% % % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
|
|
% % \caption{Component with failure modes UML diagram}
|
|
% % \label{fig:component_concept}
|
|
% % \end{figure}
|
|
%
|
|
% %
|
|
% % \subsection{Modular Design}
|
|
% %
|
|
% % When designing a system from the bottom-up, small groups of components are selected to perform
|
|
% % simple functions. These can be termed {\fgs}.
|
|
% % When the failure mode behaviour, or symptoms of failure
|
|
% % of a {\fg} are determined, it can be treated as a component in its own right.
|
|
% %
|
|
% % % Functional groups
|
|
% % % are then brought together to form more complex and higher level {\fgs}.
|
|
% % Used in this way the {\fg} has become a {\dc}. The symptoms of failure
|
|
% % of the {\fg} can be considered the failure modes of its {\dc}.
|
|
% % Derived~Components can be used to create higher level {\fgs}.
|
|
% % Repeating this process will lead to identify-able higher level
|
|
% % groups, often referred to as sub-systems. We can call the entire collection/hierarchy
|
|
% % of sub-systems the system.
|
|
%
|
|
%
|
|
%
|
|
% \section{The proposed Methodology}
|
|
% \label{fmmdproc}
|
|
% % Any new static failure mode methodology must ensure that it
|
|
% % represents all component failure modes and it therefore should be bottom-up,
|
|
% % starting with individual component failure modes.
|
|
% To ensure all component failure modes are represented, the new methodology must be bottom-up.
|
|
% %
|
|
% This seems essential to satisfy criterion 2.
|
|
% The proposed methodology is therefore a bottom-up process
|
|
% starting with base~components.
|
|
% %
|
|
% Since we are only modelling failure modes, which could arise from
|
|
% mechanical, electronic or software components,
|
|
% criterion 3 is satisfied.
|
|
% %
|
|
% In order to address the state explosion problem, the process should be modular and hierarchical,
|
|
% dealing with small groups of components at a time; this should address criterion 1.
|
|
%
|
|
%
|
|
% %\paragraph{Outline of the Failure mode methodology.}
|
|
% %
|
|
% A {\em {\fg}}, is defined as a small collection of components
|
|
% that interact to provide
|
|
% a function or task within a system.
|
|
% %
|
|
% In the proposed methodology components are collected into functional groups
|
|
% and each component failure (and possibly multiple simultaneous component failures) are considered in the
|
|
% context of the {\fg}.
|
|
%
|
|
% %% GARK
|
|
% %
|
|
% The component failures are termed {\em{\fcs}}. %`test~cases'.
|
|
% For each {\fc}
|
|
% there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}.
|
|
% %
|
|
% % MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
|
|
% %
|
|
% %From the perspective of the {\fg} failures of components will be symptoms.
|
|
% It is conjectured that many symptoms will be common. That is to say
|
|
% that component failures will often cause the same symptoms of failure
|
|
% from the perspective of a {\fg}.
|
|
%
|
|
%
|
|
%
|
|
% %
|
|
% A common symptom collection stage is now applied. Here common symptoms are collected
|
|
% from the results of the {\fcs}. Because it is possible to model combinations of failures,
|
|
% criterion 6 is satisfied.
|
|
% %
|
|
% With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}.
|
|
% The failure modes of this new {\dc} are the symptoms of the {\fg} from which it was derived.% from.
|
|
% This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed
|
|
% modules available for re-use.
|
|
%
|
|
% By using {\dcs} in higher level functional groups, a hierarchy can be built representing
|
|
% the failure mode behaviour of a system. Because the hierarchy maintains information
|
|
% linking the symptoms to component failure modes (via {\fcs}), we have traceable
|
|
% reasoning connections from base component failures to top level failures.
|
|
% The traceability should satisfy criterion 5.
|
|
%
|
|
% % ONTOLOGY - NO ROOM IN 6 PAGES OF PAPER
|
|
% % \paragraph{Environmental Conditions, Operational States.}
|
|
% %
|
|
% % Any real world sub-system will exist in a variable environment
|
|
% % and may have several modes of operation.
|
|
% % In order to find all possible failures, a sub-system
|
|
% % must be analysed for each operational state
|
|
% % and environmental condition that could affect it.
|
|
% % %
|
|
% % A question is raised here: which objects should we
|
|
% % associate the environmental and the operational states with ?
|
|
% % There are three objects in our model to which these considerations could be applied.
|
|
% % We could apply these conditions
|
|
% % to {\fgs}, components, or {\dcs}.
|
|
% %
|
|
% % \paragraph {Environmental Conditions.}
|
|
% %
|
|
% % Environmental conditions are external to the
|
|
% % {\fg} and are often things over which the system has no direct control
|
|
% % ( e.g. ambient temperature, pressure or electrical interference levels).
|
|
% % %
|
|
% % Environmental conditions may affect different components in a {\fg}
|
|
% % in different ways.
|
|
% %
|
|
% % For instance, a system may be specified for
|
|
% % $0\oc$ to $85\oc$ operation, but some components
|
|
% % may show failure behaviour between $60\oc$ and $85\oc$
|
|
% % \footnote{Opto-isolators typically show marked performance decrease after
|
|
% % $60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
|
|
% % Other components may operate comfortably within that whole temperature range specified.
|
|
% % Environmental conditions will have an effect on the {\fg} and the {\dc},
|
|
% % but they will have specific effects on individual components.
|
|
% %
|
|
% % It seems obvious that
|
|
% % environmental conditions should apply to components.
|
|
% % %A component will hold a set of environmental states that
|
|
% % %affect it.
|
|
% %
|
|
% % \paragraph {Operational States}
|
|
% %
|
|
% % Sub-systems may have specific operational states.
|
|
% % These could be a general health level, such as
|
|
% % normal operation, graceful degradation or lockout.
|
|
% % Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state.
|
|
% %
|
|
% % Operational states are conditions that apply to some functional groups, not individual components.
|
|
%
|
|
% %\section{The Non-Inverting Operational Amplifier}
|
|
% %When this constraint is complied with, we can use the FMMD method to
|
|
% %build hierarchical bottom-up models of failure mode behaviour.
|
|
% %This and the definition of a component are
|
|
% %described in this chapter.
|
|
% %When building a system from components,
|
|
% %we should be able to find all known failure modes for each component.
|
|
% %For most common electrical and mechanical components, the failure modes
|
|
% %for a given type of part can be obtained from standard literature~\cite{mil1991}
|
|
% %\cite{mech}. %The failure modes for a given component $K$ form a set $F$.
|
|
%
|
|
% \label{defs}
|
|
% %%
|
|
% %% Paragraph component and its relationship to its failure modes
|
|
% %%
|
|
|
|
|
|
\section{Worked Example: Non-Inverting Amplifier}
|
|
\label{sec:noninvamp}
|
|
%% here bring in sys safety paper from 2011
|
|
%%
|
|
%% GARK BEGIN
|
|
|
|
We demonstrate the principles of FMMD, by using it to analyse a
|
|
commonly used circuit, a non-inverting amplifier built from an op amp~\cite{aoe}[p.234] and
|
|
two resistors; a circuit schematic for this is shown in figure \ref{fig:noninvamp}.
|
|
%
|
|
\begin{figure}[h+]
|
|
\centering
|
|
%\includegraphics[width=100pt,keepaspectratio=true]{../../noninvopamp/noninv.png}
|
|
\includegraphics[width=300pt,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.
|
|
%
|
|
The resistors act as a potential divider---assuming the op-amp has high impedance---and
|
|
program the inverting 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.
|
|
|
|
|
|
\paragraph{Analysing the failure modes of the Potential Divider.}
|
|
\label{subsec:potdiv}
|
|
Since the resistors work to provide a clearly defined function, that of a potential divider,
|
|
we can treat them as a collection of components with a specific functionality---which can be termed a `{\fg}'.
|
|
This {\fg} has two members, $R1$ and $R2$.
|
|
%
|
|
The potential divider circuit can be considered as a component
|
|
that provides the function of splitting two voltages into three,
|
|
the third voltage being a ratio defined by the values of the resistors.
|
|
%Taken as an entity the potential divider can be viewed as a {\dc}.
|
|
%That is to say we can treat the potential divider, comprised of two resistors
|
|
%to act as a {\dc}.
|
|
%
|
|
Using the EN298 specification for resistor failure~\cite{en298}[App.A],
|
|
we can assign failure modes of $OPEN$ and $SHORT$ to the resistors individually (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}).
|
|
%
|
|
Each resistor failure mode is a potential {\fc} in the potential~divider.
|
|
%%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
|
|
a failure in
|
|
the potential~dividers' operation.
|
|
%
|
|
For instance
|
|
if resistor $R_1$ were to become open, then the potential~divider would not be grounded and the
|
|
voltage output from it would float high (+ve).
|
|
%
|
|
This would mean the resulting failure of the potential~divider would be voltage high output.
|
|
%
|
|
The failure mode of a high potential~divider output is termed `HighPD', and
|
|
for it outputting a low voltage `LowPD'. % Andrew asked for this to be defined before the table. ...
|
|
%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 Failures} % title of Table
|
|
\centering % used for centering table
|
|
\begin{tabular}{||l|c|c|l||}
|
|
\hline \hline
|
|
% FIDDLINGING HATAR HAVING TO REMOVE THE TERM FAILURE SCENARIO HERE....
|
|
% GOOD ENOUGH FOR THE IET/IEEE, but then they live in the real
|
|
% world don't they....
|
|
%\textbf{Failure} & \textbf{Pot.Div} & \textbf{Symptom} \\
|
|
%\textbf{scenario} & \textbf{Effect} & \textbf{Description} \\
|
|
|
|
\textbf{Failure } & \textbf{Pot.Div} & \textbf{Derived Component} \\ % \textbf{Symptom} \\
|
|
\textbf{Cause} & \textbf{Effect} & \textbf{Failure modes} \\ %\textbf{Description} \\
|
|
% R & wire & res + & res - & description
|
|
\hline
|
|
\hline
|
|
FC1: $R_1$ SHORT & LOW & LowPD \\
|
|
FC2: $R_1$ OPEN & HIGH & HighPD \\ \hline
|
|
FC3: $R_2$ SHORT & HIGH & HighPD \\
|
|
FC4: $R_2$ OPEN & LOW & LowPD \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\label{tbl:pdfmea}
|
|
\end{table}
|
|
}
|
|
%
|
|
%\vbox{
|
|
From table \ref{tbl:pdfmea} we can see that the resistor
|
|
failures modes lead to some common symptoms of failure from the perspective of the {\fg}.
|
|
%YOU FIDDLINGING FITTAS, TELL ME TO USE THE TERM SYMPTOM AND THEN TELL ME TO FIDDLINGING REMOVE IT A YEAR LATER> FITTAS
|
|
%symptoms.
|
|
%These common symptoms of failure are an important concept for FMMD.
|
|
Notice the many to one mapping from {\bc} failure modes to {\dc} failure mode;
|
|
this is a typical effect of an FMMD analysis stage, and means that with each analysis stage we reduce
|
|
the number of failure modes to consider.
|
|
%
|
|
%\fmmdglossDC
|
|
%This means that we can take multiple failure modes from {\fgs} components and resolve them
|
|
%to failure modes of the {\fg}.
|
|
%
|
|
%This means that
|
|
We thus simplify the FMMD analysis task for further stages.
|
|
%
|
|
By drawing vertices for failure modes, % symptoms,
|
|
and edges for the relationships between them
|
|
%component failure modes and
|
|
%{\dc} failure modes. % resultant symptoms.
|
|
%The {\fg} can now be considered a derived component.
|
|
we represent the analysis with 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,-1.0) {$R_1$};
|
|
\node[component] (R2) at (0,-3.0) {$R_2$};
|
|
|
|
\node[failure] (R1SHORT) at (\layersep,-0) {$R1_{SHORT}$};
|
|
\node[failure] (R1OPEN) at (\layersep,-1.8) {$R1_{OPEN}$};
|
|
|
|
\node[failure] (R2SHORT) at (\layersep,-3.4) {$R2_{SHORT}$};
|
|
\node[failure] (R2OPEN) at (\layersep,-5.2) {$R2_{OPEN}$};
|
|
|
|
\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,-1.0) {HighPD};
|
|
\node[symptom] (PDLOW) at (\layersep*2,-3.0) {LowPD};
|
|
|
|
\path (R1OPEN) edge (PDHIGH);
|
|
\path (R2SHORT) edge (PDHIGH);
|
|
|
|
\path (R2OPEN) edge (PDLOW);
|
|
\path (R1SHORT) edge (PDLOW);
|
|
|
|
\end{tikzpicture}
|
|
|
|
\caption{Failure mode graph of the Potential~Divider}
|
|
\label{fig:fg1adag}
|
|
\end{figure}
|
|
%
|
|
We now have % can now create % formulate
|
|
a {\dc} to represent this potential divider:
|
|
we name this \textbf{PD}.
|
|
\fmmdglossDC
|
|
This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
|
% HTR 05SEP2012 We use the symbol $\derivec$ to represent the process of taking the analysed
|
|
% HTR 05SEP2012 {\fg} and creating from it a {\dc}.
|
|
% HTR 05SEP2012 The creation of the {\dc} \textbf{PD} is represented as a
|
|
% HTR 05SEP2012 hierarchy diagram in figure~\ref{fig:dc1}.
|
|
% HTR 05SEP2012 We represent the {\dc} \textbf{PD}, as a DAG in figure \ref{fig:dc1dag}.
|
|
%We could represent it algebraically thus: $ \derivec(PotDiv) =
|
|
% FIDDLINGING OVERSATTNING THIS IS to be REMOVED TOO : FITTAS
|
|
% \begin{figure}[h+]
|
|
% \centering
|
|
% \includegraphics[width=200pt,keepaspectratio=true]{./CH4_FMMD/dc1.png}
|
|
% % dc1.jpg: 430x619 pixel, 72dpi, 15.17x21.84 cm, bb=0 0 430 619
|
|
% \caption{From functional group to derived component, a hierarchical diagram showing how the {\fg} is analysed using the $\derivec$
|
|
% manual process and from this the {\dc} is created.}
|
|
% \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) {{\em 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 the {\dc} Potential Divider (PD) and its failure modes.}
|
|
% \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 a generic op-amp.}
|
|
%
|
|
\label{sec:opamp_fms}
|
|
%\clearpage
|
|
Let us now consider the op-amp as a {\bc}. According to
|
|
FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes %(with assigned probabilities):
|
|
latch-up (l\_up), where the output voltage is stuck at high , % (12.5\%),
|
|
latch-down (l\_dn), where the output voltage is stuck low, %(6\%),
|
|
no-operation (noop), where the op-amp cannot drive the output, %(31.3\%),
|
|
and low~slew~rate (lowslew) where the op-amp cannot react quickly to changes on its inputs. %(50\%).
|
|
\nocite{mil1991}
|
|
%
|
|
%\ifthenelse {\boolean{dag}}
|
|
%{
|
|
\fmodegloss
|
|
%
|
|
%\clearpage
|
|
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.}
|
|
The op-amp and the {\dc} {\em PD} now % andrew heavily critised this sentence but it made sense to Chris and I
|
|
form a {\fg} to model the failure mode behaviour of 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}.
|
|
%
|
|
The two components in this new {\fg}, the op-amp and the {\dc} {\em PD} have failure modes, which we use
|
|
as {\fcs} in table~\ref{tbl:ampfmea1}.
|
|
%Each of these failure modes will be given a {\fc} for analysis,
|
|
%and this is represented in table \ref{tbl:ampfmea1}.
|
|
% FITTAS NOW I CANNOT USE THE TERM FAILURE SCENARIO---was first column of table below
|
|
%
|
|
%\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
|
|
%% FIDDLINGING HATAR HAVING TO REMOVE THE TERM FAILURE SCENARIO --- whats is this the fucking
|
|
%%childrens version
|
|
%\textbf{Failure} & \textbf{Amplifier} & \textbf{Derived component} \\ %Symptom} \\
|
|
% \textbf{Scenario} & \textbf{Effect} & \textbf{Failure Modes} \\ %Description} \\
|
|
%%FFor
|
|
|
|
%%% Undrar jag om fittan ska avstand mot failure fucking cause
|
|
%
|
|
\textbf{Failure} & \textbf{Amplifier} & \textbf{Derived component} \\ %Symptom} \\
|
|
\textbf{Cause} & \textbf{Effect} & \textbf{Failure Mode} \\ %Description} \\
|
|
% R & wire & res + & res - & description
|
|
\hline
|
|
\hline
|
|
FC1: $OPAMP$ & Output & AMPHigh \\
|
|
LatchUP & High & \\ \hline
|
|
|
|
FC2: $OPAMP$ & Output Low& AMPLow \\
|
|
LatchDown & Low gain & \\ \hline
|
|
|
|
FC3: $OPAMP$ & Output Low & AMPLow \\
|
|
No Operation & & \\ \hline
|
|
|
|
FC4: $OPAMP$ & Low pass & LowPass \\
|
|
Low Slew & filtering & \\ \hline
|
|
|
|
FC5: {\em PD} & Output High & AMPHigh \\
|
|
LowPD & & \\ \hline
|
|
|
|
FC6: {\em PD} & Output Low & AMPLow \\
|
|
HighPD & Low Gain & \\ \hline
|
|
%TC7: $R_2$ OPEN & LOW & & LowPD \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\label{tbl:ampfmea1}
|
|
\end{table}
|
|
}
|
|
%
|
|
%
|
|
%
|
|
\label{sec:invamp}
|
|
%
|
|
\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,-7) {$R_1$};
|
|
\node[component] (R2) at (0,-8.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.6) {$R1_{SHORT}$};
|
|
\node[failure] (R1OPEN) at (\layersep,-7.4) {$R1_{OPEN}$};
|
|
|
|
\node[failure] (R2SHORT) at (\layersep,-9.0) {$R2_{SHORT}$};
|
|
\node[failure] (R2OPEN) at (\layersep,-11.0) {$R2_{OPEN}$};
|
|
|
|
|
|
|
|
% 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,-7) {HighPD};
|
|
\node[symptom] (PDLOW) at (\layersep*2,-8.6) {LowPD};
|
|
|
|
|
|
|
|
\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 {\bcs} 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 {\dc} failure modes; {\em AMP\_High, AMP\_Low, LowPass}. % see figure~\ref{fig:fgampb}.
|
|
% HTR 05SEP2012
|
|
This model now has two stages of analysis, as represented in figure~\ref{fig:eulerfmmd}.
|
|
%
|
|
From the analysis in table \ref{tbl:ampfmea1} we can create the {\dc} {\em NONINVAMP}, which
|
|
represents the failure mode behaviour of the non-inverting amplifier.
|
|
%
|
|
% HTR 05SEP2012 \begin{figure}[h]
|
|
% HTR 05SEP2012 % HTR 05SEP2012 \centering
|
|
% HTR 05SEP2012 \includegraphics[width=225pt]{./CH4_FMMD/dc2.png}
|
|
% HTR 05SEP2012 % dc2.png: 635x778 pixel, 72dpi, 22.40x27.45 cm, bb=0 0 635 778
|
|
% HTR 05SEP2012 \caption{Hierarchy representing the two stage FMMD analysis
|
|
% HTR 05SEP2012 (i.e. two `$\derivec$' processes taking {\fgs} and creating {\dcs}) for the non-inverting amplifier}
|
|
% HTR 05SEP2012 \label{fig:dc2}
|
|
% HTR 05SEP2012 \end{figure}
|
|
%
|
|
%
|
|
We can represent the analysis stages of INVAMP as an Euler diagram,
|
|
showing the choice of de-composition of the system into {\fgs} (see figure~\ref{fig:eulerfmmd}).
|
|
%where the curves
|
|
%define the components and {\dcs} used to form the INVAMP model, see figure~\ref{fig:eulerfmmd}.
|
|
%
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=300pt]{./CH4_FMMD/eulerfmmd.png}
|
|
% eulerfmmd.png: 413x207 pixel, 72dpi, 14.57x7.30 cm, bb=0 0 413 207
|
|
\caption{FMMD analysis of the INVAMP represented as an Euler diagram, showing how
|
|
the components have been grouped into {\fgs} and then used as {\dcs} to build the analysis hierarchy.}
|
|
\label{fig:eulerfmmd}
|
|
\end{figure}
|
|
%
|
|
We can now examine the failure mode relationships in the {\dc} {\em INVAMP} by drawing it as a DAG.
|
|
%expand the {\em PD} {\dc} and have a full FMMD failure %mode
|
|
%model
|
|
We can traverse this DAG, tracing the top level % symptoms
|
|
failure modes
|
|
down to the base component failure modes, %leaves of the tree (the leaves being {\bc} failure modes),
|
|
and thus determine all possible causes for
|
|
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier {\dc} {\em INVAMP}.
|
|
%
|
|
Knowing all possible causes for a top level event/failure~mode
|
|
is extremely useful;
|
|
if a particular top~level/system~failure was classified as catastrophic for instance,
|
|
we could use this information
|
|
to strengthen components that could cause that particular top level event/system~failure.
|
|
%
|
|
Figure \ref{fig:noninvdag1} shows a DAG,
|
|
from which we can trace top level failure modes to the base component failure modes
|
|
that can cause them.
|
|
That is, we can trace failure mode effects
|
|
from base component level to the top and vice versa.
|
|
|
|
|
|
\fmodegloss
|
|
\fmmdgloss
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
\fmmdglossSYMPTOM
|
|
|
|
|
|
% \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}
|
|
|
|
% Here we define the terms as used in the worked example.
|
|
%
|
|
% \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 used at the lowest level of an FMMD model.
|
|
% % \footnote{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}}).}. %% where did this footnote GO????
|
|
% % seems like its a bug in TeX 04JUN2012
|
|
% \\
|
|
% {\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
|
%
|
|
%
|
|
% Component & A building block, this may be a {\bc} or a {\dc}. \\%or manufacturers part. \\
|
|
% {\em Constraint} & This object must have a defined set of failure~modes. \\ \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
|
|
%
|
|
% %%A part failure mode is the way in which a component fails "functionally" on component level. Often a part has only a few failure modes.
|
|
% Failure mode & A failure mode~\cite{sccs}[p.8] is the way in which a component may fail functionally (i.e. the way in which it can fail to perform
|
|
% its intended function). A component will typically have few failure modes. \\ \hline
|
|
%
|
|
% Functional Grouping & A collection of
|
|
% components with a functional purpose.
|
|
% \\ \hline
|
|
%
|
|
% % Symptom & A failure symptom of a {\fg}, 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 NOT DISCUSSED HERE NOW......
|
|
% Unitary State & A component with `unitary~state' failure modes, means that it cannot fail
|
|
% with more than one of its failure modes at a time.\\ \hline
|
|
%%%% TOLD TO REMOVE THIS BUT FIDDLINGING HATAR TO HAVE TO DO IT
|
|
% Failure Scenario & A single failure mode (or a combination), used to
|
|
% determine failure mode effects on a {\fg}.
|
|
%\\
|
|
% \hline
|
|
% \end{tabular}
|
|
% \caption{Failure Mode Modular De-composition: definitions and terms}
|
|
% \label{tbl:fmmd_defs}
|
|
% \end{table}
|
|
|
|
|
|
\paragraph{A discussion on the terms Parts, Components and Base Components.}
|
|
A component is anything we use to build a %a product or
|
|
system.
|
|
It could be something quite complicated
|
|
like an %integrated
|
|
micro-controller/servo motor, or quite simple like the resistor.
|
|
%
|
|
We %can
|
|
usually identify a
|
|
component by its name, a manufacturer's part number and perhaps
|
|
a vendor's reference number. %In a controlled production evironment
|
|
%
|
|
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 parts, such as quad packaged op-amps:
|
|
in this case we have four op-amps on one chip.
|
|
%
|
|
Using traditional FMEA methods~\cite{sccs}[p.34] we would consider each op-amp in the package
|
|
as a separate building block for a circuit. For FMMD each of these four op-amps
|
|
in the chip would be considered to be a separate {\bc}.
|
|
% CAN WE FIND SUPPORT FOR THIS IN LITERATURE???
|
|
\fmmdglossBC
|
|
%
|
|
We need to go further than the above definition of a part, and define % defining
|
|
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 be the lowest level---an entity with which we begin our analysis---a component
|
|
that we use as a starting bottom-up building block.
|
|
%This is a choice made by the analyst, often guided by the standards to which the analysis is being performed. % to.
|
|
%
|
|
Both op-amps and transistors have published statistical failure rates and yet an op-amp is constructed from transistors.
|
|
%
|
|
However, a circuit designer would usually consider individual transistors and individual op-amps
|
|
as lowest level building blocks.
|
|
%
|
|
In fact any lowest level building block with published failure modes could be considered to be a {\bc},
|
|
but this determination is the choice of the analyst, which may be influenced by the particular
|
|
standard~\cite{en298}~\cite{en61508} %~\cite{en230}
|
|
to which we are approving/analysing a system.
|
|
|
|
%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 lisfuckup mode or not?????ted in table~\ref{tbl:fmmd_defs} and discussed below.
|
|
|
|
%% FIDDLINGING STEREO SUB_SYSTEM EXAMPLE, THE FIDDLINGING CHILDRENS SECTION
|
|
|
|
\subsection{Definition of terms: sound system example.}
|
|
\label{sec:cdplayer}
|
|
%000000elpful 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 piece of equipment that performs a given task. % safety critical product.
|
|
%
|
|
A component can be viewed as a sub-system that is a part of some larger system.
|
|
%
|
|
A modular system common to many homes is the sound separates audio system or stereo hi-fi.
|
|
%
|
|
This is used as an example to describe the concepts {\fg} and {\dc} found in FMMD.
|
|
%
|
|
For instance a stereo amplifier separate/slave is a component.
|
|
%The
|
|
A whole sound system consists perhaps of the following components:
|
|
CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
|
|
|
|
\fmmdglossSYS
|
|
\fmmdglossSS
|
|
%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{Functional Groupings and Components.} % {\fgs} and components.}
|
|
Components can be composed of components, recursively down to
|
|
the {\bcs}.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossBC
|
|
%
|
|
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 {{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, etc.
|
|
%Clearly,
|
|
Working from the bottom~up, we need to pick small
|
|
collections of components that work together in some way.
|
|
These collections are termed `{\fgs}'.
|
|
\fmmdglossFG
|
|
%
|
|
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
|
|
as one of the base level {\fgs}. It is a good candidate because
|
|
it performs a well defined function and it could be considered a design module.
|
|
|
|
\paragraph{Functional grouping 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 {\fg} as a set of components that interact
|
|
to perform a specific function.
|
|
%
|
|
When we have analysed the fault behaviour of a {\fg}, we can treat it as a `black~box'.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
%
|
|
%
|
|
The {\fgs} fault behaviour will consist of a set of %
|
|
failure modes caused by combinations
|
|
of its component's failure modes.
|
|
%
|
|
We can thus create a new component derived from analysing the {\fg} where
|
|
%
|
|
the symptoms of failure of the {\fg} are the failure modes of this new `{\dc}'.
|
|
%
|
|
An outline of the FMMD process is itemised below:
|
|
\begin{itemize}
|
|
\item Collect components to form a {\fg},
|
|
\item Create failure cause `test~cases' for all failure modes of the components within the {\fg},
|
|
\item Analyse the effect of all the test~cases on the operation of the {\fg},
|
|
\item Determine the common failure modes of the {\fg},
|
|
\item Create and name a derived component for the {\fg},
|
|
\item Assign the common failure modes from the {\fg} as the failure modes of the {\dc}.
|
|
\end{itemize}
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
\fmmdgloss
|
|
\fmmdglossBC
|
|
%
|
|
The FMMD process is described in using formal definitions and algorithms in section~\ref{sec:symptomabs}.
|
|
|
|
%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}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% \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 {\bcs}
|
|
there is established literature for the failure modes for the system designer to consider
|
|
(often with accompanying statistical
|
|
failure rates)~\cite{mil1991,en298,fmd91}.
|
|
%
|
|
\fmmdglossBC
|
|
%
|
|
For instance, a simple resistor is generally considered
|
|
to fail in two ways, it can go open circuit or it can short.
|
|
%
|
|
Electrical components have data-sheets associated with them. The data sheets
|
|
supply detailed information on the component as supplied by the manufacturer.
|
|
%
|
|
\fmodegloss
|
|
%
|
|
Because they are written for system designers, and to an extent advertise the product,
|
|
they rarely give %show %clearly detail the
|
|
failure modes of the component.
|
|
%
|
|
For FMEA purposes, ideally failure modes along with
|
|
with environmental factors and MTTF~\cite{sccs}[p.165] statistics would be presented.
|
|
%
|
|
Given the growing usage of FMEA/FMEDA and the emergence of SIL as a safety benchmark in industry, this may change.
|
|
%
|
|
Currently, failure mode information is generally only available for generic component types~\cite{mil1991, fmd91}.
|
|
%
|
|
Thus we can associate a set of failure modes to types of component,
|
|
for example $ResistorFaultModes=\{OPEN, SHORT\}$\footnote{The failure modes of the resistor
|
|
are discussed in section~\ref{sec:resistorfm}.}.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=200pt]{./CH4_FMMD/component.png}
|
|
% component.png: 436x136 pixel, 72dpi, 15.38x4.80 cm, bb=0 0 436 136
|
|
\caption{UML diagram of a component and its associated failure modes.}
|
|
\label{fig:component}
|
|
\end{figure}
|
|
|
|
% \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.
|
|
%
|
|
\label{ch4:mutex}
|
|
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.
|
|
%
|
|
\fmmdglossMUTEX
|
|
%
|
|
This constraint is discussed in detail 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 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
|
|
By `modularising a system' we 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.
|
|
%
|
|
\fmmdglossFTA
|
|
\fmmdglossSS
|
|
%
|
|
When modularising failure mode behaviour from the bottom up, it is more meaningful to call them `derived~components'.
|
|
%
|
|
\fmmdglossDC
|
|
%
|
|
|
|
\section{Failure Modes in depth}
|
|
|
|
%To perform FMEA appraisals we begin with {\bcs}~\cite{en298}~\cite{bfmea}~\cite{en61508}.
|
|
%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.
|
|
%
|
|
\fmmdglossSYMPTOM
|
|
%
|
|
With these symptoms, we can trace their effects through the system under investigation
|
|
and finally determine top-level failure events. % 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.
|
|
\fmmdglossFMECA
|
|
Another top down methodology is to apply cost benefit analysis
|
|
to determine which faults are the highest priority to fix~\cite{bfmea}.
|
|
%
|
|
%\fmmdglossFMEA
|
|
\fmeagloss
|
|
%
|
|
The aim of FMMD analysis is to produce complete\footnote{Completeness dependent upon the completeness/correctness of the {\fms} supplied by the germane standard
|
|
for our {\bcs}.} 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 (such as FTA)
|
|
can miss individual failure modes of components~\cite{faa}[Ch.~9],
|
|
especially where there are non-obvious top-level faults.
|
|
%
|
|
\fmmdglossFTA
|
|
%
|
|
|
|
|
|
\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'.
|
|
%
|
|
This is dealt with in detail using an algorithmic description, in appendix \ref{sec:algorithmfmmd}.
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
% % define difference between a \fg and a \dc
|
|
% A {\fg} is a collection of components. A {\dc} is a new `theoretical'
|
|
% component which has a set of failure modes,
|
|
% corresponding to the failure symptoms from the {\fg} from which it was derived.
|
|
% %
|
|
% We now consider a {\dc} as a black box, or component
|
|
% for use in further levels of analysis.
|
|
% %, 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 (see figure~\ref{fig:cfg}), 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.
|
|
As a derived component inherits component, the UML model shows
|
|
that it inherits the property of a set of failure modes.
|
|
%
|
|
%These failure modes are the failure mode behaviour---or symptoms---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.
|
|
A {\fg} must comprise of at least one component, and the UML diagram shows this
|
|
with the one to many relationship.
|
|
%
|
|
Under exceptional circumstances a component may need to be a member of more than
|
|
one {\fg} (this is looked at in section~\ref{sec:sideeffects}).
|
|
%
|
|
The relationship between
|
|
the {\fg} and component is therefore---using UML notation---`$ \star \leftrightarrow 1..\star$'.
|
|
%
|
|
A {\fg} will only be associated with one {\dc} and is given a one to one relationship in the UML diagram.
|
|
%
|
|
Each {\fg} will have one analysis report associated with it.
|
|
%
|
|
The UML representation (in figure \ref{fig:cfg}) shows a `{\fg}' having a one to one relationship with a derived~component.
|
|
%
|
|
%
|
|
%%% FORMAL DEF SLIGHTLY OUT OF PLACE HERE ---- J.HOWSE
|
|
% 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 (over all possible components),
|
|
% and $\mathcal{{\DC}}$ the set of all derived components,
|
|
% we express the analysis process $\derivec$ as $$ \derivec : \mathcal{\FG} \rightarrow \mathcal{{\DC}} .$$
|
|
% \end{definition}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=300pt,,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}
|
|
\label{sec:fmmd_uml}
|
|
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:eulerfmmd}. % ~\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 created from its analysis, is shown enclosing R1 and R2. % above the {\fg}.
|
|
%
|
|
As this derived component inherits the properties of a component, we may use
|
|
it in a {\fg} higher in the hierarchy.
|
|
%
|
|
The {\em PD} derived component is now placed into a {\fg}
|
|
with the op-amp.
|
|
%
|
|
This {\fg} is now analysed and a {\dc} created to
|
|
represent the failure mode behaviour of the {\em INVAMP}.
|
|
%
|
|
%
|
|
We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}.
|
|
%
|
|
An analysis report is generated for each stage in the FMMD % {\fg} to {\dc}
|
|
process. %\footnote
|
|
%
|
|
The UML model in figure~\ref{fig:cfg} describes a hierarchical structure similar to that of a file system with directories,
|
|
but instead of directory and file nodes, there are closely linked {\fgs} and {\dcs} pairs, that perform a similar structural functions.
|
|
%
|
|
The NONINVAMP example is shown as an instance
|
|
diagram below (see figure~\ref{fig:instanceNONINVAMP}).
|
|
%
|
|
By tracing the component failure modes to symptoms
|
|
(which would defined in the analysis reports)
|
|
the failure causation logic can be followed and thus the DAG's derived (see figure~\ref{fig:noninvdag1}).
|
|
%
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=400pt]{./CH4_FMMD/instance_diagram_NONINVAMP.png}
|
|
% instance_diagram_NONINVAMP.png: 1162x657 pixel, 72dpi, 40.99x23.18 cm, bb=0 0 1162 657
|
|
\caption{Instance diagram for the NONINVAMP example.}
|
|
\label{fig:instanceNONINVAMP}
|
|
\end{figure}
|
|
|
|
|
|
%
|
|
\paragraph{Traceability and quality of FMMD analysis.}
|
|
By having an analysis report report for each analysis stage, %i.e. {\fg} to {\dc},
|
|
we add traceability to the reasoning applied to the FMMD process.
|
|
%
|
|
Consider that traditional FMEA has one large reasoning stage, that of component failure mode
|
|
directly to system level failure. The reasoning given is typically a one line comment
|
|
on a spreadsheet entry~\cite{sccs}[p.38]. % (if we are lucky!).
|
|
%
|
|
FMMD typically has several reasoning stages (i.e. from each {\fg} to {\dc}) up to the
|
|
final system level {\dc}.
|
|
%
|
|
Thus, each possible cause for a system failure %{\fm}
|
|
will have a collection of FMMD analysis reports associated with it.
|
|
%
|
|
These collections of analysis reports will provide a cause and effect
|
|
story for each possible scenario that could cause the system level failure.
|
|
%
|
|
Traceability of design processes are considered necessary for
|
|
safety critical product~\cite{en61508} and is an important concept
|
|
in quality systems~\cite{iso9001}.
|
|
%
|
|
Having analysis reports increases the traceability---or documented paper trail---aiding understanding
|
|
and maintainability for failure mode models.
|
|
%
|
|
Also a detailed cause and effect model is useful for creating diagnostic schemas~\cite{dbamafta}.
|
|
|
|
|
|
|
|
\paragraph{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 components
|
|
would have an $\abslev$ value of 1.
|
|
%
|
|
In our example the resistors and op-amp are level zero ({\bcs}, $\abslev=0$), the {\em PD} a level 1 {\dc} ($\abslev=1$) and the {\em INVAMP}
|
|
a level 2 {\dc} ($\abslev=2$).
|
|
%\clearpage
|
|
Because {\fgs} may include components at varying levels
|
|
of $\abslev$, having it quickly available as an attribute
|
|
will be required in practical implementations
|
|
to order the tree, and assist in preventing recursion in the hierarchy.
|
|
The abstraction level concept is formally defined in section~\ref{sec:abstractionlevel}.
|
|
|
|
% \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 the {\bcs} the initial {\fgs} are formed, and from the first {\fgs},
|
|
%the first {\dcs}.
|
|
%
|
|
% \paragraph{Re-factoring the UML model to remove {\fgs}.}
|
|
% While useful for describing the context of the FMMD analysis process,
|
|
% it is desirable to remove the {\fg} from the UML diagram as this is by-product of the analysis process.
|
|
% Figure~\ref{fig:cfg2} presents a final (and simpler) UML model for FMMD.
|
|
% However, the analysis report, is a core feature of FMMD. Having an analysis
|
|
% report associated with each incremental stage in the analysis is a strength
|
|
% compared to traditional FMEA, where we only have one stage (possibly undocumented)
|
|
% for each {\bc} {\fm} to system level event/failure mode.
|
|
% The {\fg} and the analysis report have one to one relationships. We can therefore re-factor
|
|
% these into an analysis report (which would list the components used to
|
|
% make up and thus define the {\fg}) associated with the {\dc}.
|
|
%
|
|
%
|
|
% %
|
|
% % Two other data types/entities are required
|
|
% % however: we need to model environmental and operational states and
|
|
% % where they fit into the data structure.
|
|
% % %
|
|
%
|
|
%
|
|
%
|
|
% % \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=300pt,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}.
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Conclusion}
|
|
|
|
%Tie into wish list at end of chapter 3. Solves state explosion, completeness, traceability, models for related such as FMECA
|
|
|
|
\paragraph{Failure model Completeness.}
|
|
It is undesirable to miss any component {\fm} in the analysis process; were this to
|
|
happen our failure model would be incomplete.
|
|
%
|
|
Given the starting conditions of base component {\fms} from the literature,
|
|
we can ensure that all these {\fms} are traceable to subsequent {\dc} {\fms}
|
|
in the model.
|
|
%
|
|
With the above condition true, we term this a `complete' FMMD failure model.
|
|
Ensuring this condition is described in section~\ref{sec:completetest}.
|
|
|
|
\paragraph{Mutual exclusivity of {\dc} failure modes.}
|
|
%
|
|
It is a desirable feature of a component that its failure modes
|
|
are mutually exclusive.
|
|
%
|
|
This also applies to {\dcs} produced in the FMMD process.
|
|
%
|
|
In the FMMD process symptoms are are collected, i.e no component failure modes may be shared
|
|
by a symptom within a {\fg}, and therefore the failure modes of a {\dc} are mutually exclusive.
|
|
%
|
|
Thus FMMD naturally produces {\dcs} with failure modes that are mutually exclusive.
|
|
%
|
|
This property forces the FMMD analyst to
|
|
create failure modes models that have a one to one mapping from {\bc} {\fm}
|
|
to system level failure, or symptom (see section~\ref{sec:onetoone}).
|
|
%
|
|
\fmmdglossMUTEX
|
|
%
|
|
This property, termed a `unitary~state~failure~mode', is examined formally in section~\ref{ch7:mutex}.
|
|
|
|
\paragraph{Objective and contextual/subjective failure symptoms.}
|
|
Because the top level failure symptoms of an FMMD analysis are objective, or the result of reasoning,
|
|
we can have a final stage where we consider the subjective or contextual effects of these symptoms.
|
|
%
|
|
With traditional FMEA methodologies we
|
|
have to make this decision (the contextual effects) for each component {\fm} in the system.
|
|
|
|
\paragraph{State explosion problem of FMEA solved by FMMD.}
|
|
%
|
|
Because FMMD considers failure modes within functional groups;
|
|
the traditional state explosion problem in FMEA where the ideal of exhaustive FMEA (XFMEA)---where each failure
|
|
mode could be considered in the context of all other components in the system---disappears.
|
|
%
|
|
With FMMD, because the {\fgs} have small numbers of components in them, we can easily apply XFMEA within the {\fgs}.
|
|
%
|
|
This issue addressed formally in section~\ref{sec:cc}.
|
|
\fmmdgloss
|
|
|
|
\paragraph{Uses of the FMMD failure mode model.}
|
|
%
|
|
Having a failure mode graph/model, where base component failure modes are traceable to top event events,
|
|
provides a forward search derived failure mode model.
|
|
%A forward search means that we can apply checks to ensure that
|
|
%all known component failure
|
|
%modes have been considered in the analysis (i.e. completeness as described above).
|
|
%
|
|
This means that for every system level failure we can traverse back to possible failure causes
|
|
in the base components. Coupled with MTTF statistics for the base components
|
|
this allows use to predict statistical failure rates for system level failures (this is
|
|
described in greater detail in section~\ref{sec:determine_fms}).
|
|
%
|
|
We can also use the FMMD model to derive information
|
|
to assist in creating related models such as FTA~\cite{nucfta,nasafta},
|
|
traditional FMEA, FMECA~\cite{safeware}[p.344], FMEDA~\cite{scsh}, diagnostics schemas~\cite{dbamafta}
|
|
and other failure mode analysis methodologies.
|
|
\fmmdglossFTA
|
|
\fmmdglossFMECA
|
|
\fmmdglossFMEDA
|
|
\fmmdgloss
|
|
%\fmmdglossFMEA
|
|
\fmeagloss |