robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

OK just about to put the noninvopamp in

Browse Source
This commit is contained in:
Robin Clark 2011-06-17 18:36:48 +01:00
parent e7a09768b7
commit cc5791f7b8
1 changed files with 47 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
fmmd_concept/System_safety_2011/submission.tex
View File

@ -105,7 +105,6 @@ and there is no facility to cross check between diagrams. It has limited
support for environmental and operational states.
<<<<<<< HEAD
\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
%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.
%
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)}
FMEA is used principally in manufacturing.
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
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.
To perform the analysis rigorously, we would need to consider the effect
of a component failure against all other components. Adding environmental
@ -236,12 +240,11 @@ for its results, such as error causation trees.%, reliability and safety statis
%\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
% rationale, sub-systems are build to perform often basic functions from base components.
% 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
@ -261,7 +264,8 @@ for its results, such as error causation trees.%, reliability and safety statis
%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,
@ -304,22 +308,43 @@ for its results, such as error causation trees.%, reliability and safety statis
\section{The proposed Methodology}
\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.
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
context of the {\fg}. These are termed `test~cases'. For each test~case
there will be a corresponding failure mode, from the perspective of the {\fg}.
context 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
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}.
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
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
and may have several modes of operation.
@ -336,8 +361,8 @@ 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.
Consider ambient temperature, pressure or even electrical interference levels.
{\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.
@ -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.
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]
% \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
\section{Worked example: Non Inverting Operational Amplifier}
\subsection{FMMD analysis Example: A Voltage/Potential Divider}
\begin{figure}