Changes made before the Gastec Holland visit I expect, all looked good from git gui.
This commit is contained in:
parent
3c24ddd24a
commit
8f42d9ef2b
@ -385,7 +385,7 @@ a micro-processor may have a SLEEP mode etc.
|
|||||||
To make FMMD compatible with FTA operational states and environmental conditions should %can %must
|
To make FMMD compatible with FTA operational states and environmental conditions should %can %must
|
||||||
be factored into the UML model.
|
be factored into the UML model.
|
||||||
%
|
%
|
||||||
We may encounter a condition where we would want to inhibit some action of the system.
|
An undesired condition may occur where it could be necessary to inhibit some action of the system.
|
||||||
This is rather like a logical guard criterion. For instance in the gas burner standard EN298 it
|
This is rather like a logical guard criterion. For instance in the gas burner standard EN298 it
|
||||||
states that a flame detector must confirm that a pilot flame has been established before the main burner fuel can be applied.
|
states that a flame detector must confirm that a pilot flame has been established before the main burner fuel can be applied.
|
||||||
In FTA terms this would be an inhibit condition on the main fuel, i.e. PILOT\_NOT\_CONFIRMED.
|
In FTA terms this would be an inhibit condition on the main fuel, i.e. PILOT\_NOT\_CONFIRMED.
|
||||||
@ -543,7 +543,7 @@ the Human Machine Interface~(HMI)~\cite{stranks2007human}.
|
|||||||
\paragraph{Objective and Subjective Reasoning in FMEA: Three Mile Island nuclear accident example.}
|
\paragraph{Objective and Subjective Reasoning in FMEA: Three Mile Island nuclear accident example.}
|
||||||
An example of objective and subjective factors is demonstrated in the accident report on the 1979 Three Mile Island
|
An example of objective and subjective factors is demonstrated in the accident report on the 1979 Three Mile Island
|
||||||
nuclear accident~\cite{safeware}[App.D]. Here, a vent valve for the primary reactor coolant (pressurised water) became stuck open.
|
nuclear accident~\cite{safeware}[App.D]. Here, a vent valve for the primary reactor coolant (pressurised water) became stuck open.
|
||||||
This condition causes an objectively derived failure mode, temporary loss of coolant due to a stuck valve.
|
This condition causes an objectively derived failure mode --- `leakage~of~coolant' --- due to a stuck valve.
|
||||||
%
|
%
|
||||||
This, if recognised correctly by the operators, would have lead to
|
This, if recognised correctly by the operators, would have lead to
|
||||||
a short reactor shut-down and then
|
a short reactor shut-down and then
|
||||||
@ -554,8 +554,8 @@ until a partial meltdown of the reactor fuel occurred, with a resulting
|
|||||||
leak of radioactive material into the environment.
|
leak of radioactive material into the environment.
|
||||||
%
|
%
|
||||||
For the objective failure mode determined by
|
For the objective failure mode determined by
|
||||||
FMEA, that of temporary loss of coolant,
|
FMEA, that of leakage of coolant,
|
||||||
we would not reasonably expect this to go unchecked and cause such a critical failure.
|
we would not reasonably expect this to go unchecked/resolved for an extended period and cause such a critical failure.
|
||||||
%
|
%
|
||||||
The criticality level is therefore subjective. We cannot know how the operators
|
The criticality level is therefore subjective. We cannot know how the operators
|
||||||
would have reacted, and deficiencies in the HMI were not a factor in the failure analysis.
|
would have reacted, and deficiencies in the HMI were not a factor in the failure analysis.
|
||||||
@ -564,10 +564,10 @@ would have reacted, and deficiencies in the HMI were not a factor in the failure
|
|||||||
\paragraph{Further Work: Objective and Subjective Reasoning in FMEA.}
|
\paragraph{Further Work: Objective and Subjective Reasoning in FMEA.}
|
||||||
%
|
%
|
||||||
We could term the criticality prediction to be in the domain of subjective reasoning. With an objectively defined system level failure
|
We could term the criticality prediction to be in the domain of subjective reasoning. With an objectively defined system level failure
|
||||||
we have to determine its level of criticality, or how serious the risk posed would be.
|
we often are next required to determine its level of criticality, or how serious the risk posed would be.
|
||||||
%
|
%
|
||||||
Two methodologies have started to consider this aspect, FMECA with its criticality and probability factors, and
|
Two methodologies have started to consider this aspect, FMECA~\cite{fmeca} with its criticality and probability factors, and
|
||||||
EN61508 with its classification of dangerous and safe failures.
|
FMEDA~\cite{en61508,fmeda} with its classification of dangerous and safe failures.
|
||||||
%
|
%
|
||||||
It is the author's opinion that more work is required to clarify this area. FMMD stops at the objective level.
|
It is the author's opinion that more work is required to clarify this area. The scope of FMMD is the objective level only.
|
||||||
|
|
||||||
|
@ -5,6 +5,10 @@
|
|||||||
|
|
||||||
This chapter defines the process for performing one stage of the FMMD process i.e.
|
This chapter defines the process for performing one stage of the FMMD process i.e.
|
||||||
from forming a {\fg} to creating a {\dc}.
|
from forming a {\fg} to creating a {\dc}.
|
||||||
|
%
|
||||||
|
The FMMD process is then examined in greater levels of detail and described with set theory in
|
||||||
|
an algorithmic context.
|
||||||
|
%
|
||||||
%This section decribes the algorithm for performing one step of
|
%This section decribes the algorithm for performing one step of
|
||||||
%FMMD analysis
|
%FMMD analysis
|
||||||
%analysing a {\fg} and determining from it a {\dc}.
|
%analysing a {\fg} and determining from it a {\dc}.
|
||||||
@ -14,8 +18,8 @@ from forming a {\fg} to creating a {\dc}.
|
|||||||
%diagnostic analysis (fault finding).
|
%diagnostic analysis (fault finding).
|
||||||
%This is followed by justification for using a bottom-up, forward search
|
%This is followed by justification for using a bottom-up, forward search
|
||||||
%approach, along with modularisation.
|
%approach, along with modularisation.
|
||||||
A theoretical example of FMMD using set theory is given following on to
|
%A theoretical example of FMMD using set theory is given following on to
|
||||||
a description of the process presented as an algorithm.
|
%a description of the process presented as an algorithm.
|
||||||
%for performing FMMD is then presented.
|
%for performing FMMD is then presented.
|
||||||
|
|
||||||
%
|
%
|
||||||
@ -73,7 +77,7 @@ a description of the process presented as an algorithm.
|
|||||||
% We can term this stage in FMMD analysis as the `symptom abstraction' process.
|
% We can term this stage in FMMD analysis as the `symptom abstraction' process.
|
||||||
% %The symptom abstraction or abstraction process, is the key process in creating an FMMD hierarchy.
|
% %The symptom abstraction or abstraction process, is the key process in creating an FMMD hierarchy.
|
||||||
% }
|
% }
|
||||||
\vspace{40pt}
|
%\vspace{40pt}
|
||||||
% %\today
|
% %\today
|
||||||
% \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
|
% \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
|
||||||
% Because the symptoms have been collected from
|
% Because the symptoms have been collected from
|
||||||
@ -245,8 +249,15 @@ a description of the process presented as an algorithm.
|
|||||||
|
|
||||||
\nocite{safeware}
|
\nocite{safeware}
|
||||||
\section{Overview of the FMMD analysis Process}
|
\section{Overview of the FMMD analysis Process}
|
||||||
The FMMD process is described in chapter~\ref{sec:chap4}
|
The FMMD process is described in chapter~\ref{sec:chap4}, to re-cap, FMMD has four main stages:
|
||||||
With the FMEA results for a {\fg} common symptoms of failure can be determined. This is termed `symptom~abstraction'.
|
\begin{itemize}
|
||||||
|
\item collection of components to form {\fgs},
|
||||||
|
\item applying FMEA to the {\fg},
|
||||||
|
\item collecting common symptoms from the FMEA results,
|
||||||
|
\item creating a {\dc} representing the failure mode behaviour of the {\fg}.
|
||||||
|
\end{itemize}
|
||||||
|
%
|
||||||
|
%This is termed `symptom~abstraction'.
|
||||||
% TO DO: separate these two:
|
% TO DO: separate these two:
|
||||||
%
|
%
|
||||||
% \paragraph{FMMD analysis Objective.}
|
% \paragraph{FMMD analysis Objective.}
|
||||||
@ -255,37 +266,36 @@ With the FMEA results for a {\fg} common symptoms of failure can be determined.
|
|||||||
% when specified components within it fail.
|
% when specified components within it fail.
|
||||||
% Once we know how a functional~group can fail, we can treat it as a component or sub-system
|
% Once we know how a functional~group can fail, we can treat it as a component or sub-system
|
||||||
% with its own set of failure modes.
|
% with its own set of failure modes.
|
||||||
Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system
|
% Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system
|
||||||
with its own set of failure modes.
|
% with its own set of failure modes.
|
||||||
This process allows us to modularise and simply FMEA analysis of systems.
|
This process allows us to modularise and simply FMEA analysis of systems.
|
||||||
The FMEA process is reviewed here, introducing
|
%
|
||||||
formal definitions that will be used in the description of FMMD
|
The FMEA process is described in greater detail below.
|
||||||
presented as an algorithm.
|
|
||||||
|
|
||||||
|
|
||||||
\paragraph{FMEA applied to the Functional Group.}
|
\paragraph{FMEA applied to the Functional Group.}
|
||||||
As the functional~group contains a set of components, the failure~modes
|
As a {\fg} is a set of components, the failure~modes
|
||||||
that we have to consider are all the failure modes of its components, as
|
that we have to consider are the failure modes of its components.
|
||||||
developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
|
%, as
|
||||||
The aim here is to build `test cases', combinations of failure~modes
|
%developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
|
||||||
to use as failure~mode analysis scenarios.
|
%The aim here is to build `test cases',
|
||||||
|
Single or combinations of failure~modes are used to create failure~mode analysis scenarios, or `test cases'.
|
||||||
%Each failure mode (or combination of) investigated is termed a `test case'.
|
%Each failure mode (or combination of) investigated is termed a `test case'.
|
||||||
%Each `test case' is analysed.
|
%Each `test case' is analysed.
|
||||||
%
|
%
|
||||||
The component failure modes in each test case
|
The component failure modes in each test case
|
||||||
are examined with respect to their effect on the functional~group.
|
are examined with respect to their effect on the {\fg}.
|
||||||
%
|
%
|
||||||
The aim of this analysis is to find out how the functional~group fails given
|
The aim of this analysis is to find out how the {\fg} fails given
|
||||||
each test case.
|
each test case.
|
||||||
%
|
%
|
||||||
The goal of the process is to produce a set of failure modes from the perspective of the user of the functional~group.
|
%The goal of the process is to produce a set of failure modes from the perspective of the user of the {\fg}.
|
||||||
%
|
%
|
||||||
In other words, if a designer is handed a piece of circuitry to use, he need not be concerned with
|
In other words, if a designer has a previously analysed module to use, he need not be concerned with
|
||||||
the failure modes of its components.
|
the failure modes of its components: it is handed it as a derived component,
|
||||||
|
which has its own FMMD defined set of failure modes. % symptoms.
|
||||||
%
|
%
|
||||||
He is handed it as a derived component, which has a set of failure mode symptoms.
|
The designer can now treat this module as a black box, or {\dc}.
|
||||||
%
|
|
||||||
The designer can now treat this piece of circuitry as a black box, or {\dc}.
|
|
||||||
|
|
||||||
\paragraph{Environmental Conditions or Operational States.}
|
\paragraph{Environmental Conditions or Operational States.}
|
||||||
|
|
||||||
@ -295,11 +305,14 @@ operational states and
|
|||||||
environmental conditions to which it may be exposed. In this way, all possible
|
environmental conditions to which it may be exposed. In this way, all possible
|
||||||
failure mode behaviour due to all the conditions that can be applied to a test case will be examined.
|
failure mode behaviour due to all the conditions that can be applied to a test case will be examined.
|
||||||
|
|
||||||
As part of this analysis process, records must be kept
|
%As part of this analysis process,
|
||||||
detailing each test case result along with its resultant
|
To aid test repeatability, quality and audit trails, records should be kept
|
||||||
{\fg} failure mode.
|
detailing not only each test case result along with its resultant
|
||||||
If this data is kept in the model and could be used to
|
{\fg} failure mode, but the reasoning applied to obtain the analysis.
|
||||||
automatically examine the effects of environmentally sourced common mode failure scenarios.
|
%
|
||||||
|
This data can be kept in the model as part of an analysis report.
|
||||||
|
%and could be used to
|
||||||
|
%automatically examine the effects of environmentally sourced common mode failure scenarios.
|
||||||
|
|
||||||
|
|
||||||
%%- A {\fg} may, in the case of an electronic circuit have
|
%%- A {\fg} may, in the case of an electronic circuit have
|
||||||
@ -379,7 +392,7 @@ To summarise:
|
|||||||
Some specific combinations of failure modes might be included. For instance where
|
Some specific combinations of failure modes might be included. For instance where
|
||||||
a very reliable part is duplicated but very critical, like the 4 engines on a 747
|
a very reliable part is duplicated but very critical, like the 4 engines on a 747
|
||||||
aircraft.}) of the failure modes to
|
aircraft.}) of the failure modes to
|
||||||
form `test cases'.
|
form `test~cases'.
|
||||||
\item If required, create test cases from all valid double failure mode combinations within the {\fg}.
|
\item If required, create test cases from all valid double failure mode combinations within the {\fg}.
|
||||||
% \item Draw these as contours on a diagram
|
% \item Draw these as contours on a diagram
|
||||||
% \item Where simultaneous failures are examined use overlapping contours
|
% \item Where simultaneous failures are examined use overlapping contours
|
||||||
@ -662,7 +675,11 @@ the SYSTEM level.
|
|||||||
}
|
}
|
||||||
{
|
{
|
||||||
%To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
|
%To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
|
||||||
|
The FMMD process is now described introducing
|
||||||
|
set theoretical definitions % formal definitions
|
||||||
|
that will be used in the description of FMMD
|
||||||
|
presented as an algorithm.
|
||||||
|
%
|
||||||
Let the set of all possible components be $\mathcal{C}$
|
Let the set of all possible components be $\mathcal{C}$
|
||||||
and let the set of all possible failure modes be $\mathcal{F}$.
|
and let the set of all possible failure modes be $\mathcal{F}$.
|
||||||
|
|
||||||
@ -712,7 +729,8 @@ and a new derived~component/sub-system $DC$.
|
|||||||
% Note that
|
% Note that
|
||||||
% $DC$ is a derived component at a higher level of fault analysis abstraction
|
% $DC$ is a derived component at a higher level of fault analysis abstraction
|
||||||
% than the functional~group from which it was derived.
|
% than the functional~group from which it was derived.
|
||||||
% %Thus,
|
% %Thus, ke
|
||||||
|
|
||||||
% $DC$ can now be treated
|
% $DC$ can now be treated
|
||||||
% as a component with a known set of failure modes.
|
% as a component with a known set of failure modes.
|
||||||
|
|
||||||
|
@ -10,8 +10,9 @@ in chapter 5 have been moved here for reference.
|
|||||||
FMEA study of a resistor and capacitor in use as a phase changer.
|
FMEA study of a resistor and capacitor in use as a phase changer.
|
||||||
|
|
||||||
\label{detail:PHS45}
|
\label{detail:PHS45}
|
||||||
\center
|
|
||||||
\begin{table}[h+]
|
\begin{table}[h+]
|
||||||
|
\center
|
||||||
\caption{PhaseShift: Failure Mode Effects Analysis: Single Faults} % title of Table
|
\caption{PhaseShift: Failure Mode Effects Analysis: Single Faults} % title of Table
|
||||||
\label{tbl:firstorderlp}
|
\label{tbl:firstorderlp}
|
||||||
|
|
||||||
@ -506,7 +507,7 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
|
|||||||
{
|
{
|
||||||
\tiny
|
\tiny
|
||||||
\begin{table}[h+]
|
\begin{table}[h+]
|
||||||
\centering
|
\center
|
||||||
\caption{ Read\_Pt100: Failure Mode Effects Analysis} % title of Table
|
\caption{ Read\_Pt100: Failure Mode Effects Analysis} % title of Table
|
||||||
\label{tbl:readPt100}
|
\label{tbl:readPt100}
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user