OK just about to put the noninvopamp in
This commit is contained in:
parent
e7a09768b7
commit
cc5791f7b8
@ -105,7 +105,6 @@ and there is no facility to cross check between diagrams. It has limited
|
|||||||
support for environmental and operational states.
|
support for environmental and operational states.
|
||||||
|
|
||||||
|
|
||||||
<<<<<<< HEAD
|
|
||||||
\paragraph{Fault Mode Effects Analysis FMEA)} is used principally in manufacturing.
|
\paragraph{Fault Mode Effects Analysis FMEA)} is used principally in manufacturing.
|
||||||
Each top level failure is assessed by its cost to repair and its frequency,%, using a
|
Each top level failure is assessed by its cost to repair and its frequency,%, using a
|
||||||
%failure mode ratio.
|
%failure mode ratio.
|
||||||
@ -114,7 +113,12 @@ It is easy to identify single component failure to system failure scenarios
|
|||||||
and an estimate of product reliability can be calculated.
|
and an estimate of product reliability can be calculated.
|
||||||
%
|
%
|
||||||
It cannot focus on
|
It cannot focus on
|
||||||
=======
|
component interactions that cause system failure modes or determine potential
|
||||||
|
problems from simultaneous failure modes. It does not consider environmental
|
||||||
|
or operational states in sub-systems or components. It cannot model
|
||||||
|
self-checking safety elements or other in-built safety features or
|
||||||
|
analyse how particular components may fail.
|
||||||
|
|
||||||
\subsection{Fault Mode Effects Analysis FMEA)}
|
\subsection{Fault Mode Effects Analysis FMEA)}
|
||||||
FMEA is used principally in manufacturing.
|
FMEA is used principally in manufacturing.
|
||||||
Each defect is assessed by its cost to repair and its frequency. %, using a
|
Each defect is assessed by its cost to repair and its frequency. %, using a
|
||||||
@ -152,9 +156,9 @@ the safety integrity standards IOC5108 and EN61508~\cite{en61508}.
|
|||||||
level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level
|
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.
|
event, this leads to repeated work, with limited ability for cross checking/model validation.
|
||||||
|
|
||||||
\subsection{Bottom-up approach: FMEA, FMECA, FMEDA}
|
%\subsection{Bottom-up approach: }
|
||||||
|
|
||||||
\paragraph{State Explosion problem}
|
\paragraph{State Explosion problem for FMEA, FMECA, FMEDA.}
|
||||||
The bottom -up techniques all suffer from a problem of state explosion.
|
The bottom -up techniques all suffer from a problem of state explosion.
|
||||||
To perform the analysis rigorously, we would need to consider the effect
|
To perform the analysis rigorously, we would need to consider the effect
|
||||||
of a component failure against all other components. Adding environmental
|
of a component failure against all other components. Adding environmental
|
||||||
@ -236,13 +240,12 @@ for its results, such as error causation trees.%, reliability and safety statis
|
|||||||
%\end{itemize}
|
%\end{itemize}
|
||||||
}
|
}
|
||||||
|
|
||||||
% A new methodology must ensure that it represents all component failure modes and it therefore should be bottom-up,
|
|
||||||
% starting with individual component failure modes.
|
|
||||||
%
|
%
|
||||||
% In order to control the state explosion problem, the process must be modular
|
|
||||||
% and deal with small groups of components. The design process follows this
|
% The design process follows this
|
||||||
% rationale, sub-systems are build to perform often basic functions from base components.
|
%rationale, sub-systems are build t%o perform often basic functions from base components.
|
||||||
% We can term these small groups {\fgs}.
|
%We can term these small groups {\fgs}.
|
||||||
%
|
%
|
||||||
% Components should be collected
|
% Components should be collected
|
||||||
% into small functional groups to enable the examination of the effect of a
|
% into small functional groups to enable the examination of the effect of a
|
||||||
@ -261,7 +264,8 @@ for its results, such as error causation trees.%, reliability and safety statis
|
|||||||
%Development of the new methodology
|
%Development of the new methodology
|
||||||
%
|
%
|
||||||
% \section{An ontology of failure modes}
|
% \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
|
% An ontology is now developed of
|
||||||
% failure modes and their relationship to environmental factors,
|
% failure modes and their relationship to environmental factors,
|
||||||
% applied/operational states and the hierarchical nature inherent in product design,
|
% applied/operational states and the hierarchical nature inherent in product design,
|
||||||
@ -304,22 +308,43 @@ for its results, such as error causation trees.%, reliability and safety statis
|
|||||||
|
|
||||||
\section{The proposed Methodology}
|
\section{The proposed Methodology}
|
||||||
\label{fmmdproc}
|
\label{fmmdproc}
|
||||||
The proposed methodology is a bottom-up process
|
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.
|
||||||
|
This seems essential to satisfy criteria 2.
|
||||||
|
The proposed methodology is therefore a bottom-up process
|
||||||
starting with base~components.
|
starting with base~components.
|
||||||
These are collected into functional groups
|
%
|
||||||
|
Because we are only modelling failure modes, which could arise from
|
||||||
|
mechanical, electronic or software components,
|
||||||
|
criteria 3 is satisfied.
|
||||||
|
%
|
||||||
|
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.
|
||||||
|
In the proposed methodology components are collected into functional groups
|
||||||
and each component failure mode (and optionally combinations) are considered in the
|
and each component failure mode (and optionally combinations) are considered in the
|
||||||
context of the {\fg}. These are termed `test~cases'. For each test~case
|
context of the {\fg}.
|
||||||
there will be a corresponding failure mode, from the perspective of the {\fg}.
|
%
|
||||||
|
The component failure modes (and optional combinations) are termed `test~cases'. For each test~case
|
||||||
|
there will be a corresponding resultant failure, from the perspective of the {\fg}.
|
||||||
|
% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
|
||||||
A symptom collection stage is then applied. Here common symptoms are collected
|
A symptom collection stage is then applied. Here common symptoms are collected
|
||||||
from the results of the test~cases.Diagram1
|
from the results of the test~cases. Because optional combinations of failures are possible,
|
||||||
|
multiple failures can be modelled, satisfying criteria 6.
|
||||||
|
%
|
||||||
With a collection of the {\fg} failure symptoms, we can now create a {\dc}.
|
With a collection of the {\fg} failure symptoms, we can now create a {\dc}.
|
||||||
The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
|
The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
|
||||||
|
This satisfies criteria 3, as we can now treat {\dcs} as ready analysed
|
||||||
|
modules to re-use.
|
||||||
|
|
||||||
By using {\dcs} in higher level functional groups, a hierarchy can be built representing
|
By using {\dcs} in higher level functional groups, a hierarchy can be built representing
|
||||||
the failure mode behaviour of a SYSTEM.
|
the failure mode behaviour of a SYSTEM. Because the hierarchy maintains information
|
||||||
|
linking the symptoms to test~cases to component failure modes, we have traceable
|
||||||
|
reasoning connections from base component failures to top level failures.
|
||||||
|
The traceability should satisfy criteria 5.
|
||||||
|
|
||||||
|
|
||||||
\subsection{Environmental Conditions, Operational States}
|
\paragraph{Environmental Conditions, Operational States.}
|
||||||
|
|
||||||
Any real world sub-system will exist in a variable environment
|
Any real world sub-system will exist in a variable environment
|
||||||
and may have several modes of operation.
|
and may have several modes of operation.
|
||||||
@ -336,8 +361,8 @@ to {\fgs}, components, or {\dcs}.
|
|||||||
\paragraph {Environmental Conditions.}
|
\paragraph {Environmental Conditions.}
|
||||||
|
|
||||||
Environmental conditions are external to the
|
Environmental conditions are external to the
|
||||||
{\fg} and are often things over which the system has no direct control.
|
{\fg} and are often things over which the system has no direct control
|
||||||
Consider ambient temperature, pressure or even electrical interference levels.
|
( e.g. ambient temperature, pressure or electrical interference levels).
|
||||||
%
|
%
|
||||||
Environmental conditions may affect different components in a {\fg}
|
Environmental conditions may affect different components in a {\fg}
|
||||||
in different ways.
|
in different ways.
|
||||||
@ -364,40 +389,9 @@ 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.
|
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.
|
Operational states are conditions that apply to some functional groups, not individual components.
|
||||||
%% Andrew says that that does no make sense But I think it does
|
|
||||||
%
|
|
||||||
%\paragraph{Design Decision.}
|
|
||||||
%Operational state will be applied to {\fg}s.
|
|
||||||
%
|
|
||||||
%\paragraph{UML Model of FMMD Analysis}
|
|
||||||
%
|
|
||||||
% The UML diagram in figure \ref{fig:env_op_uml}, shows the data
|
|
||||||
% relationships between {\fgs} and operational states, and component
|
|
||||||
% failure modes and environmental factors.
|
|
||||||
|
|
||||||
|
|
||||||
% \begin{figure}[h]
|
\section{Worked example: Non Inverting Operational Amplifier}
|
||||||
% \centering
|
|
||||||
% \includegraphics[width=200pt,bb=0 0 818 249,keepaspectratio=true]{./fmmd_env_op_uml.png}
|
|
||||||
% % fmmd_env_op_uml.jpg: 818x249 pixel, 72dpi, 28.86x8.78 cm, bb=0 0 818 249
|
|
||||||
% \caption{UML model of Environmental and Operational states w.r.t FMMD}
|
|
||||||
% \label{fig:env_op_uml}
|
|
||||||
% \end{figure}
|
|
||||||
|
|
||||||
%
|
|
||||||
% \begin{figure}[h]
|
|
||||||
% \centering
|
|
||||||
% \includegraphics[width=200pt]{./fmmd_env_op_uml.png}
|
|
||||||
% % fmmd_env_op_uml.png: 816x246 pixel, 72dpi, 28.79x8.68 cm, bb=0 0 816 246
|
|
||||||
% \caption{UML model of failure mode ontology}
|
|
||||||
% \label{fig:env_op_uml}
|
|
||||||
% \end{figure}
|
|
||||||
|
|
||||||
%This is because environmental \def\layersep{2.5cm}conditions will apply SYSTEM wide,
|
|
||||||
%but may only affect specific components.
|
|
||||||
|
|
||||||
%DEVELOP UML MODELS
|
|
||||||
|
|
||||||
|
|
||||||
\subsection{FMMD analysis Example: A Voltage/Potential Divider}
|
\subsection{FMMD analysis Example: A Voltage/Potential Divider}
|
||||||
\begin{figure}
|
\begin{figure}
|
||||||
|
Loading…
Reference in New Issue
Block a user