fuck forgot to commit, thank god for wake up on lan
This commit is contained in:
parent
0a06f36469
commit
c0852cd424
@ -19,8 +19,8 @@
|
|||||||
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
|
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
|
||||||
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
|
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
|
||||||
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
||||||
\newcommand{\fg}{\em functional~group}
|
\newcommand{\fg}{functional~group}
|
||||||
\newcommand{\fgs}{\em functional~groups}
|
\newcommand{\fgs}{functional~groups}
|
||||||
\newcommand{\dc}{\em derived~component}
|
\newcommand{\dc}{\em derived~component}
|
||||||
\newcommand{\dcs}{\em derived~components}
|
\newcommand{\dcs}{\em derived~components}
|
||||||
\newcommand{\bc}{\em base~component}
|
\newcommand{\bc}{\em base~component}
|
||||||
@ -56,14 +56,16 @@ failure mode of the component or sub-system}}}
|
|||||||
|
|
||||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||||
\rfoot{\today}
|
\rfoot{\today}
|
||||||
\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
%\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
||||||
|
\lhead{Developing a rigorous bottom-up modular static failure modelling methodology}
|
||||||
% numbers at outer edges
|
% numbers at outer edges
|
||||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||||
\author{R.P.Clark$^\star$ , A.~Fish$^\dagger$ , C.~Garrett$^\dagger$, J.~Howse$^\dagger$ \\
|
\author{R.P.Clark$^\star$ , A.~Fish$^\dagger$ , C.~Garrett$^\dagger$, J.~Howse$^\dagger$ \\
|
||||||
$^\star${\em Energy Technology Control, 25 North Street, Lewes, BN7 2PE, UK} \and $^\dagger${\em University of Brighton, UK}
|
$^\star${\em Energy Technology Control, 25 North Street, Lewes, BN7 2PE, UK} \and $^\dagger${\em University of Brighton, UK}
|
||||||
}
|
}
|
||||||
|
|
||||||
\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
%\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
||||||
|
\title{Developing a rigorous bottom-up modular static failure modelling methodology}
|
||||||
%\nodate
|
%\nodate
|
||||||
\maketitle
|
\maketitle
|
||||||
|
|
||||||
@ -82,7 +84,7 @@ These properties provide advantages in rigour and efficiency when compared to cu
|
|||||||
|
|
||||||
\paragraph{Introduction}
|
\paragraph{Introduction}
|
||||||
{
|
{
|
||||||
This paper describes and appraises four current failure mode methodologies.
|
This paper describes and appraises four current failure modelling methodologies.
|
||||||
Their advantages and deficiencies are discussed and a desirable criteria list
|
Their advantages and deficiencies are discussed and a desirable criteria list
|
||||||
for an `ideal' static failure mode methodology is developed.
|
for an `ideal' static failure mode methodology is developed.
|
||||||
A new proposed
|
A new proposed
|
||||||
@ -110,8 +112,8 @@ It is suitable for large complicated systems with few undesirable top
|
|||||||
level failures and focuses on those events considered most important or most catastrophic.
|
level failures and focuses on those events considered most important or most catastrophic.
|
||||||
%
|
%
|
||||||
Effects of duplication/redundancy of safety systems can be readily assessed.
|
Effects of duplication/redundancy of safety systems can be readily assessed.
|
||||||
It uses notations that are readily understood by engineers (logic symbols from digital electronics and a fault hierarchy).
|
It uses notations that are readily understood by engineers (logic symbols borrowed from digital electronics and a fault hierarchy).
|
||||||
However, it cannot guarantee to model all base component failure modes
|
However, it cannot guarantee to model all base component failures
|
||||||
or be used to determine system level errors other than those modelled.
|
or be used to determine system level errors other than those modelled.
|
||||||
%
|
%
|
||||||
Each FTA diagram models one top level event.
|
Each FTA diagram models one top level event.
|
||||||
@ -126,13 +128,13 @@ lead to top level failure/events.
|
|||||||
Each top level failure is assessed by its cost to repair (or perceived criticality) and its estimated frequency. %, using a
|
Each top level failure is assessed by its cost to repair (or perceived criticality) and its estimated frequency. %, using a
|
||||||
%failure mode ratio.
|
%failure mode ratio.
|
||||||
A list of failures according to their cost to repair~\cite{bfmea}, or effect on system reliability is then calculated.
|
A list of failures according to their cost to repair~\cite{bfmea}, or effect on system reliability is then calculated.
|
||||||
It is easy to identify single component failure to system failure scenarios
|
It is easy to identify single component failure to system failure mappings
|
||||||
and an estimate of product reliability can be calculated.
|
and an estimate of product reliability can be calculated.
|
||||||
%This can be viewed as a prioritised `to~fix' list.
|
%This can be viewed as a prioritised `to~fix' list.
|
||||||
%
|
%
|
||||||
It cannot focus on complex
|
It cannot focus on complex
|
||||||
component interactions that cause system failure modes or determine potential
|
component interactions that cause system failure modes or determine potential
|
||||||
problems from simultaneous failure modes. It does not consider changing environmental
|
problems from simultaneous failures. It does not consider changing environmental
|
||||||
or operational states in sub-systems or components. It cannot model
|
or operational states in sub-systems or components. It cannot model
|
||||||
self-checking safety elements or other in-built safety features or
|
self-checking safety elements or other in-built safety features or
|
||||||
analyse how particular components may fail.
|
analyse how particular components may fail.
|
||||||
@ -164,7 +166,8 @@ event, this leads to repeated work, with limited ability for cross checking/mode
|
|||||||
%\subsection{Bottom-up approach: }
|
%\subsection{Bottom-up approach: }
|
||||||
|
|
||||||
\paragraph{State Explosion problem for FMEA, FMECA, FMEDA.}
|
\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
|
||||||
and operational states further increases this effect.
|
and operational states further increases this effect.
|
||||||
@ -216,11 +219,11 @@ To look in detail at a half of a million test cases is obviously impractical.
|
|||||||
% % take a circuit or system and follow all the interactions
|
% % take a circuit or system and follow all the interactions
|
||||||
% % to the components that cause the system level event.
|
% % to the components that cause the system level event.
|
||||||
|
|
||||||
\paragraph{Multiple Events from one base component failure mode}
|
%\paragraph{Multiple Events from one base component failure mode}
|
||||||
A base component failure may potentially cause more than one
|
%A base component failure may potentially cause more than one
|
||||||
SYSTEM level failure mode.
|
%SYSTEM level failure mode.
|
||||||
It would be possible to identify one top level event associated with
|
%It would be possible to identify one top level event associated with
|
||||||
a {\bcfm} and not investigate other possibilities.
|
%a {\bcfm} and not investigate other possibilities.
|
||||||
|
|
||||||
%\section{Requirements for a new static failure mode Analysis methodology}
|
%\section{Requirements for a new static failure mode Analysis methodology}
|
||||||
|
|
||||||
@ -326,20 +329,21 @@ Because we are only modelling failure modes, which could arise from
|
|||||||
mechanical, electronic or software components,
|
mechanical, electronic or software components,
|
||||||
criteria 3 is satisfied.
|
criteria 3 is satisfied.
|
||||||
%
|
%
|
||||||
In order to address the state explosion problem, the process must be modular
|
In order to address the state explosion problem, the process must be modular and hierarchical
|
||||||
and deal with small groups of components at a time, this should address criteria 1.
|
dealing with small groups of components at a time; this should address criteria 1.
|
||||||
|
%
|
||||||
In the proposed methodology components are collected into functional groups
|
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 (and optionally combinations) are considered in the
|
||||||
context of the {\fg}.
|
context of the {\fg}.
|
||||||
%
|
%
|
||||||
The component failure modes (and optional combinations) are termed `test~cases'. For each test~case
|
The component failures (and optional combinations) are termed `test~cases'. For each test~case
|
||||||
there will be a corresponding resultant failure, from the perspective of the {\fg}.
|
there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}.
|
||||||
%
|
%
|
||||||
% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
|
% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
|
||||||
%
|
%
|
||||||
From the perspective of the {\fg} failures of components will be symptoms.
|
%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
|
It is conjectured that many symptoms will be common. That is to say
|
||||||
that component failure modes, will often cause the same symptoms of failure
|
that component failures, will often cause the same symptoms of failure
|
||||||
from the perspective of a {\fg}.
|
from the perspective of a {\fg}.
|
||||||
%
|
%
|
||||||
A common symptom collection stage is now applied. Here common symptoms are collected
|
A common symptom collection stage is now applied. Here common symptoms are collected
|
||||||
@ -348,8 +352,8 @@ 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
|
This satisfies criteria 3, as we can now treat {\dcs} as pre-analysed
|
||||||
modules to re-use.
|
modules available for 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. Because the hierarchy maintains information
|
the failure mode behaviour of a SYSTEM. Because the hierarchy maintains information
|
||||||
@ -406,7 +410,7 @@ Operational states are conditions that apply to some functional groups, not indi
|
|||||||
|
|
||||||
\section{Worked Example: Non-Inverting Operational Amplifier}
|
\section{Worked Example: Non-Inverting Operational Amplifier}
|
||||||
|
|
||||||
A standard non inverting op amp (from ``The Art of Electronics'' ~\cite{aoe}[pp.234]) is shown in figure \ref{fig:noninvamp}.
|
A standard non inverting op amp~\cite{aoe}[pp.234] is shown in figure \ref{fig:noninvamp}.
|
||||||
|
|
||||||
|
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
@ -563,7 +567,7 @@ we can assign a test case number (see table \ref{pdfmea}).
|
|||||||
Each test case is analysed to determine the `symptom'
|
Each test case is analysed to determine the `symptom'
|
||||||
on the potential dividers' operation. For instance
|
on the potential dividers' operation. For instance
|
||||||
were the resistor $R_1$ to go open, the circuit would not be grounded and the
|
were the resistor $R_1$ to go open, the circuit would not be grounded and the
|
||||||
voltage output from it would be high (+ve).
|
voltage output from it would float high (+ve).
|
||||||
This would mean the symptom of the failed potential divider, would be that it
|
This would mean the symptom of the failed potential divider, would be that it
|
||||||
gives a high voltage output.%We can now consider the {\fg}
|
gives a high voltage output.%We can now consider the {\fg}
|
||||||
%as a component in its own right, and its symptoms as its failure modes.
|
%as a component in its own right, and its symptoms as its failure modes.
|
||||||
@ -948,9 +952,10 @@ back to their potential causes.
|
|||||||
|
|
||||||
\ifthenelse {\boolean{dag}}
|
\ifthenelse {\boolean{dag}}
|
||||||
{
|
{
|
||||||
We can now expand the $PD$ {\dc} and now have a full FMMD failure mode model
|
We can now expand the $PD$ {\dc} and now have a full FMMD failure %mode
|
||||||
|
model
|
||||||
drawn as a DAG, which we can use to traverse to determine the possible causes to
|
drawn as a DAG, which we can use to traverse to determine the possible causes to
|
||||||
the three high level symptoms, or failure~modes of the non-inverting amplifier.
|
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier.
|
||||||
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
|
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
|
||||||
to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies.
|
to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies.
|
||||||
}
|
}
|
||||||
@ -1090,6 +1095,8 @@ the the number of failure symptoms for a {\fg} will be less than or equal to the
|
|||||||
of component failures. In practise the number of symptoms is usually around half the
|
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.
|
number of component failure modes, for each stage of FMMD analysis.
|
||||||
|
|
||||||
|
This methodology has also been applied elsewhere to the inverting amplifier configuration.
|
||||||
|
Clearly one can then use use these derived components in more complex circuits where the advantages of FMMD become more obvious.
|
||||||
|
|
||||||
|
|
||||||
\subsection{Evaluation against Desirable Criteria}
|
\subsection{Evaluation against Desirable Criteria}
|
||||||
@ -1101,18 +1108,18 @@ We can now evaluate the FMMD method using the criteria in section \ref{fmmdreq}.
|
|||||||
|
|
||||||
{ \small
|
{ \small
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item{State Explosion must be reduced.}
|
\item{State Explosion is reduced,}
|
||||||
Because small collections of components are dealt with in functional groups
|
because small collections of components are dealt with in functional groups
|
||||||
the state explosion problem is effectively dealt with.
|
to produce derived components which are used in an hierarchical manner.
|
||||||
|
|
||||||
\item{All component failure modes must be considered in the model.}
|
\item{All component failure modes must be considered in the model.}
|
||||||
The proposed methodology will be bottom-up.
|
Since the proposed methodology is bottom-up.
|
||||||
This means that we can ensure/check that all component failure modes are handled.
|
This means that we can ensure/check that all component failure modes are handled.
|
||||||
|
|
||||||
|
|
||||||
\item{ It should be easy to integrate mechanical, electronic and software models.}
|
\item{ It should be straight forward to integrate mechanical, electronic and software models,}
|
||||||
Because FMMD models in terms of failure modes only, we have a generic failure mode entities to model.
|
because FMMD models in terms of failure modes only. % we have a generic failure mode entities to model.
|
||||||
We can describe a mechanical, electrical or software component in terms of its failure modes.
|
%We can describe a mechanical, electrical or software component in terms of its failure modes.
|
||||||
%
|
%
|
||||||
Because of this
|
Because of this
|
||||||
we can model and analyse integrated electromechanical systems, controlled by computers,
|
we can model and analyse integrated electromechanical systems, controlled by computers,
|
||||||
|
Loading…
Reference in New Issue
Block a user