|
|
|
|
@ -104,13 +104,12 @@ All the failure modes of all the components within a {\fg} are collected.
|
|
|
|
|
%
|
|
|
|
|
%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 component failure mode can considered as a `failure~scenario' or 'test~case'
|
|
|
|
|
applied to a {\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}'.
|
|
|
|
|
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 its symptoms of failure.
|
|
|
|
|
%,
|
|
|
|
|
@ -170,329 +169,10 @@ In this way we can incrementally apply FMEA to an entire system. %, with documen
|
|
|
|
|
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).
|
|
|
|
|
FMEA (because the analysis is typically performed in several small stages
|
|
|
|
|
thus avoiding state explosion).
|
|
|
|
|
%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
|
|
|
|
|
% %%
|
|
|
|
|
\fmmdglossSTATEEX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Worked Example: Non-Inverting Amplifier}
|
|
|
|
|
@ -525,7 +205,7 @@ 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}'.
|
|
|
|
|
we can treat them as a collection of components with a specific functionality---i.e. a `{\fg}'.
|
|
|
|
|
This {\fg} has two members, $R1$ and $R2$.
|
|
|
|
|
%
|
|
|
|
|
The potential divider circuit can be considered as a component
|
|
|
|
|
@ -590,7 +270,7 @@ for it outputting a low voltage `LowPD'. % Andrew asked for this to be defined b
|
|
|
|
|
%
|
|
|
|
|
{ \small
|
|
|
|
|
\begin{table}[ht]
|
|
|
|
|
\caption{Potential Divider: Failure Mode Effects Analysis: Single Failures} % title of Table
|
|
|
|
|
\caption{Potential Divider: FMEA for single failures} % title of Table
|
|
|
|
|
\centering % used for centering table
|
|
|
|
|
\begin{tabular}{||l|c|c|l||}
|
|
|
|
|
\hline \hline
|
|
|
|
|
@ -995,7 +675,7 @@ showing the choice of de-composition of the system into {\fgs} (see figure~\ref{
|
|
|
|
|
%where the curves
|
|
|
|
|
%define the components and {\dcs} used to form the INVAMP model, see figure~\ref{fig:eulerfmmd}.
|
|
|
|
|
%
|
|
|
|
|
\begin{figure}[h]
|
|
|
|
|
\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
|
|
|
|
|
@ -1004,6 +684,8 @@ the components have been grouped into {\fgs} and then used as {\dcs} to build th
|
|
|
|
|
\label{fig:eulerfmmd}
|
|
|
|
|
\end{figure}
|
|
|
|
|
%
|
|
|
|
|
%\clearpage %%% This figure seems to escape furher down the chapter
|
|
|
|
|
%
|
|
|
|
|
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
|
|
|
|
|
@ -1025,108 +707,14 @@ 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.
|
|
|
|
|
@ -1238,8 +826,9 @@ 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
|
|
|
|
|
%We %can
|
|
|
|
|
%define a
|
|
|
|
|
{\Fgs} have been defined 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'.
|
|
|
|
|
@ -1252,8 +841,7 @@ 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
|
|
|
|
|
%
|
|
|
|
|
A new component can be 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:
|
|
|
|
|
@ -1420,9 +1008,16 @@ it is common to term the modules identified as sub-systems.
|
|
|
|
|
%
|
|
|
|
|
\fmmdglossFTA
|
|
|
|
|
\fmmdglossSS
|
|
|
|
|
\fmmdglossFG
|
|
|
|
|
%
|
|
|
|
|
When modularising failure mode behaviour from the bottom up, it is more meaningful to call them `derived~components'.
|
|
|
|
|
When modularising failure mode behaviour from the bottom up,
|
|
|
|
|
it is more meaningful to call them `{\dcs}'.
|
|
|
|
|
%
|
|
|
|
|
This is because they have been derived from the bottom-up according to functional
|
|
|
|
|
criteria, rather than with the top down approach, de-composed from
|
|
|
|
|
a system into 'sub-systems'.
|
|
|
|
|
%
|
|
|
|
|
\fmodegloss
|
|
|
|
|
\fmmdglossDC
|
|
|
|
|
%
|
|
|
|
|
|
|
|
|
|
@ -1504,6 +1099,7 @@ especially where there are non-obvious top-level faults.
|
|
|
|
|
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'.
|
|
|
|
|
\fmmdglossSA
|
|
|
|
|
%
|
|
|
|
|
This is dealt with in detail using an algorithmic description, in appendix \ref{sec:algorithmfmmd}.
|
|
|
|
|
\fmmdglossFG
|
|
|
|
|
@ -1526,7 +1122,7 @@ and creates a new {\dc} from it.
|
|
|
|
|
%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
|
|
|
|
|
As a derived component inherits from 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.
|
|
|
|
|
@ -1575,11 +1171,13 @@ The UML representation (in figure \ref{fig:cfg}) shows a `{\fg}' having a one t
|
|
|
|
|
|
|
|
|
|
\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}.
|
|
|
|
|
@ -1590,8 +1188,11 @@ 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}.
|
|
|
|
|
This {\fg} is now analysed and a {\dc} created to represent the failure mode behaviour
|
|
|
|
|
of the {\em INVAMP}\footnote{The results of this analysis are placed into the analysis~report. This will contain
|
|
|
|
|
mapping relationships between the component {\fms} and the {\dc} {\fms} and ideally, descriptions that would
|
|
|
|
|
aid auditors to understand the reasoning behind each analysis test~case.}.
|
|
|
|
|
\fmmdglossSS
|
|
|
|
|
%
|
|
|
|
|
%
|
|
|
|
|
We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}.
|
|
|
|
|
@ -1681,8 +1282,10 @@ a level 2 {\dc} ($\abslev=2$).
|
|
|
|
|
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}.
|
|
|
|
|
to order the tree, and assist in preventing recursion in the hierarchy (i.e. where
|
|
|
|
|
a {\fg} could erroneously include a component above its-self in the hierarchy).
|
|
|
|
|
%
|
|
|
|
|
The abstraction level concept is formally defined in appendix~\ref{sec:abstractionlevel}.
|
|
|
|
|
|
|
|
|
|
% \section{Set Theory Description}
|
|
|
|
|
%
|
|
|
|
|
@ -1807,7 +1410,7 @@ by a symptom within a {\fg}, and therefore the failure modes of a {\dc} are mutu
|
|
|
|
|
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}
|
|
|
|
|
create failure modes models that have a many to one mapping from {\bc} {\fm}
|
|
|
|
|
to system level failure, or symptom (see section~\ref{sec:onetoone}).
|
|
|
|
|
%
|
|
|
|
|
\fmmdglossMUTEX
|
|
|
|
|
@ -1821,6 +1424,10 @@ we can have a final stage where we consider the subjective or contextual effects
|
|
|
|
|
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;
|
|
|
|
|
@ -1829,8 +1436,16 @@ mode could be considered in the context of all other components in the system---
|
|
|
|
|
%
|
|
|
|
|
With FMMD, because the {\fgs} have small numbers of components in them, we can easily apply XFMEA within the {\fgs}.
|
|
|
|
|
%
|
|
|
|
|
In broad terms, FMMD mitigates state explosion by reducing the number of checks---{\fms} against components)---to perform.
|
|
|
|
|
%
|
|
|
|
|
This issue addressed formally in section~\ref{sec:cc}.
|
|
|
|
|
\fmmdgloss
|
|
|
|
|
\fmmdglossSTATEEX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\paragraph{Uses of the FMMD failure mode model.}
|
|
|
|
|
%
|
|
|
|
|
@ -1842,7 +1457,7 @@ provides a forward search derived failure mode model.
|
|
|
|
|
%
|
|
|
|
|
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
|
|
|
|
|
this allows prediction of 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
|
|
|
|
|
|
Robin Clark