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

Changes made before the Gastec Holland visit I expect, all looked good from git gui.

Browse Source
This commit is contained in:
Robin Clark 2013-07-23 21:17:17 +01:00
parent 3c24ddd24a
commit 8f42d9ef2b
3 changed files with 60 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
submission_thesis/CH8_Conclusion/copy.tex
View File

@ -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
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
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.
@ -543,7 +543,7 @@ the Human Machine Interface~(HMI)~\cite{stranks2007human}.
\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
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
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.
%
For the objective failure mode determined by
FMEA, that of temporary loss of coolant,
we would not reasonably expect this to go unchecked and cause such a critical failure.
FMEA, that of leakage of coolant,
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
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.}
%
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
EN61508 with its classification of dangerous and safe failures.
Two methodologies have started to consider this aspect, FMECA~\cite{fmeca} with its criticality and probability factors, and
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.

80
submission_thesis/appendixes/algorithmic.tex
View File

@ -5,6 +5,10 @@
This chapter defines the process for performing one stage of the FMMD process i.e.
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
%FMMD analysis
%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).
%This is followed by justification for using a bottom-up, forward search
%approach, along with modularisation.
A theoretical example of FMMD using set theory is given following on to
a description of the process presented as an algorithm.
%A theoretical example of FMMD using set theory is given following on to
%a description of the process presented as an algorithm.
%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.
% %The symptom abstraction or abstraction process, is the key process in creating an FMMD hierarchy.
% }
\vspace{40pt}
%\vspace{40pt}
% %\today
% \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
% Because the symptoms have been collected from
@ -245,8 +249,15 @@ a description of the process presented as an algorithm.
\nocite{safeware}
\section{Overview of the FMMD analysis Process}
The FMMD process is described in chapter~\ref{sec:chap4}
With the FMEA results for a {\fg} common symptoms of failure can be determined. This is termed `symptom~abstraction'.
The FMMD process is described in chapter~\ref{sec:chap4}, to re-cap, FMMD has four main stages:
\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:
%
% \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.
% 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.
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.
% 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.
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
presented as an algorithm.
%
The FMEA process is described in greater detail below.
\paragraph{FMEA applied to the Functional Group.}
As the functional~group contains a set of components, the failure~modes
that we have to consider are all the failure modes of its components, as
developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
The aim here is to build `test cases', combinations of failure~modes
to use as failure~mode analysis scenarios.
As a {\fg} is a set of components, the failure~modes
that we have to consider are the failure modes of its components.
%, as
%developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
%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 `test case' is analysed.
%
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.
%
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
the failure modes of its components.
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: 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 piece of circuitry as a black box, or {\dc}.
The designer can now treat this module as a black box, or {\dc}.
\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
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
detailing each test case result along with its resultant
{\fg} failure mode.
If this data is kept in the model and could be used to
automatically examine the effects of environmentally sourced common mode failure scenarios.
%As part of this analysis process,
To aid test repeatability, quality and audit trails, records should be kept
detailing not only each test case result along with its resultant
{\fg} failure mode, but the reasoning applied to obtain the analysis.
%
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
@ -379,7 +392,7 @@ To summarise:
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
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 Draw these as contours on a diagram
% \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}.
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}$
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
% $DC$ is a derived component at a higher level of fault analysis abstraction
% than the functional~group from which it was derived.
% %Thus,
% %Thus, ke
% $DC$ can now be treated
% as a component with a known set of failure modes.

5
submission_thesis/appendixes/detailed_analysis.tex
View File

@ -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.
\label{detail:PHS45}
\center
\begin{table}[h+]
\center
\caption{PhaseShift: Failure Mode Effects Analysis: Single Faults} % title of Table
\label{tbl:firstorderlp}
@ -506,7 +507,7 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
{
\tiny
\begin{table}[h+]
\centering
\center
\caption{ Read\_Pt100: Failure Mode Effects Analysis} % title of Table
\label{tbl:readPt100}