Edit into CH3 from AF and Chris Garrett:wq
This commit is contained in:
parent
52cd17eba6
commit
3909317287
@ -927,6 +927,13 @@ ISSN={1530-2059},}
|
|||||||
YEAR = "1995"
|
YEAR = "1995"
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@BOOK{cbds,
|
||||||
|
AUTHOR = "Chris~Price",
|
||||||
|
TITLE = "Computer-Based Diagnostic Systems ISBN 3-540-76198-5",
|
||||||
|
PUBLISHER = "Springer Practitioner series",
|
||||||
|
YEAR = "1999"
|
||||||
|
}
|
||||||
|
|
||||||
@BOOK{sem,
|
@BOOK{sem,
|
||||||
AUTHOR = "J.~Woodcock,~Martin~Loomes",
|
AUTHOR = "J.~Woodcock,~Martin~Loomes",
|
||||||
TITLE = "Software Engineering Mathematics ISBN 0-273-02673-9",
|
TITLE = "Software Engineering Mathematics ISBN 0-273-02673-9",
|
||||||
|
@ -18,18 +18,26 @@ Static testing is at the theoretical, or design level, and involves
|
|||||||
looking at failure scenarios and trying to predict how systems would react.
|
looking at failure scenarios and trying to predict how systems would react.
|
||||||
%
|
%
|
||||||
This thesis deals with one area of static testing, that of Failure Mode Effects Analysis (FMEA)~\cite{iec60812}, a commonly
|
This thesis deals with one area of static testing, that of Failure Mode Effects Analysis (FMEA)~\cite{iec60812}, a commonly
|
||||||
used technique that is legally mandatory for a wide range of equipment certification.
|
used technique that is a legal requirement %mandatory
|
||||||
|
for a wide range of equipment certification.
|
||||||
|
|
||||||
The ability to assess the safety of man made equipment has been a concern
|
The ability to assess the safety of machinery %man made equipment
|
||||||
|
has been a concern
|
||||||
since the dawn of the industrial age~\cite{usefulinfoengineers,steamboilers}.
|
since the dawn of the industrial age~\cite{usefulinfoengineers,steamboilers}.
|
||||||
%
|
%
|
||||||
|
% The philosophy behind safety measures has progressed
|
||||||
|
% over time and by World War Two we began to see concepts such as `no single component failure should cause
|
||||||
|
% a dangerous system failure'~\cite{boffin} emerging~\cite{echoesofwar}[Ch.13].
|
||||||
The philosophy behind safety measures has progressed
|
The philosophy behind safety measures has progressed
|
||||||
with time and by World War Two we began to see concepts such as `no single component failure should cause
|
over time and by World War Two concepts such as `no single component failure should cause
|
||||||
a dangerous system failure'~\cite{boffin} emerging~\cite{echoesofwar}[Ch.13].
|
a dangerous system failure'~\cite{boffin} emerged~\cite{echoesofwar}[Ch.13].
|
||||||
%
|
%
|
||||||
Concepts such as these allow us to apply
|
Concepts such as these allow
|
||||||
objective criteria to safety assessment. We can extend the `no~single~failure' concept
|
objective criteria of safety assessment.
|
||||||
to double or even multiple failures being unacceptable as the cause of dangerous states.
|
%
|
||||||
|
The `no~single~failure' concept can be extended
|
||||||
|
to double or even multiple failures being
|
||||||
|
unacceptable as the cause of dangerous states.
|
||||||
%
|
%
|
||||||
The concept of a double failure causing a dangerous condition being forbidden
|
The concept of a double failure causing a dangerous condition being forbidden
|
||||||
can be found in the legally binding European standard EN298\footnote{EN298:2003 became
|
can be found in the legally binding European standard EN298\footnote{EN298:2003 became
|
||||||
@ -41,29 +49,31 @@ in 2006~\cite{en298}.
|
|||||||
More sophisticated statistically based standards, i.e EN61508~\cite{en61508} and variants thereof,
|
More sophisticated statistically based standards, i.e EN61508~\cite{en61508} and variants thereof,
|
||||||
are based on statistical thresholds for the frequency of dangerous failures.
|
are based on statistical thresholds for the frequency of dangerous failures.
|
||||||
%
|
%
|
||||||
We could state, for instance, that we can tolerate an `acceptable' maximum number of
|
For instance, acceptable maximum numbers of
|
||||||
dangerous failures per billion hours of operation.
|
dangerous failures per billion hours of operation could be stated.
|
||||||
%
|
%
|
||||||
We can then broadly categorise orders of failure rates into Safety Integrity Levels (SIL)~\cite{scsh}.
|
% We can then broadly categorise orders of failure rates into Safety Integrity Levels (SIL)~\cite{scsh}.
|
||||||
|
Orders of failure rates can then be broadly categorised into Safety Integrity Levels (SIL)~\cite{scsh}.
|
||||||
%
|
%
|
||||||
So for a maximum of 10 potentially dangerous failures per billion hours of operation we assign a SIL level of 4,
|
So for a maximum of 10 potentially dangerous failures per billion hours of operation a SIL level of 4 is assigned,
|
||||||
for 100 a SIL level of 3, and so on in powers of ten.
|
for 100 a SIL level of 3, and so on in powers of ten.
|
||||||
%
|
%
|
||||||
If we can determine a SIL rating,
|
If SIL ratings can be determined,
|
||||||
we can match it against a risk.
|
they can be matched against given risks.
|
||||||
%
|
%
|
||||||
The more dangerous the consequences of failure
|
The more dangerous the consequences of failure
|
||||||
the higher SIL rating we can demand for it.
|
the higher the SIL rating. % we can demand for it.
|
||||||
%
|
%
|
||||||
A band-saw with one operative may require a SIL rating of 1,
|
A band-saw with one operative may require a SIL rating of 1,
|
||||||
but something with higher potential for harm to a larger number of people,
|
%but something with higher potential for harm to a larger number of people,
|
||||||
such as a nuclear power-station or air-liner,
|
but systems
|
||||||
with far greater consequences on dangerous failure
|
such as nuclear power-stations or air-liners,
|
||||||
may require a SIL rating of 4.
|
with far greater consequences on dangerous failure,
|
||||||
|
may require a SIL ratings of 4.
|
||||||
%
|
%
|
||||||
That is while a low incidence of failure may be tolerable on a band-saw,
|
%That is while a low incidence of failure may be tolerable on a band-saw,
|
||||||
extremely low incidences of failure would be tolerable in a nuclear plant.
|
%extremely low incidences of failure would be tolerable in a nuclear plant.
|
||||||
SIL ratings provide another objective yardstick for the measurement of system safety.
|
%SIL ratings provide another objective yardstick for the measurement of system safety.
|
||||||
%governing failure conditions and determining risk levels associated with systems.
|
%governing failure conditions and determining risk levels associated with systems.
|
||||||
|
|
||||||
All of these risk assessment techniques are based on variations of %on the theme of
|
All of these risk assessment techniques are based on variations of %on the theme of
|
||||||
@ -94,13 +104,13 @@ firstly looking at a variety of common electronic circuits and then at electroni
|
|||||||
}
|
}
|
||||||
|
|
||||||
\section{Motivation}
|
\section{Motivation}
|
||||||
The motivation for this study came from two sources, one academic (my Software Engineering MSc project) and the other
|
The motivation for this study came from two sources, one academic (the author's Software Engineering MSc project) and the other
|
||||||
practical (as a practising embedded software engineer working with FMEA on safety critical burner systems).
|
practical (the author is a practising embedded software engineer working with FMEA on safety critical burner systems).
|
||||||
%
|
%
|
||||||
% AF does not think the paragraph below should be included 12JAN2013
|
% AF does not think the paragraph below should be included 12JAN2013
|
||||||
\paragraph{MSc Project: Euler/Spider diagram Editor.}
|
\paragraph{MSc Project: Euler/Spider diagram Editor.}
|
||||||
I had recently completed an
|
The author had recently completed an
|
||||||
MSc and my project was to create an Euler/Spider~Diagram~\cite{howse:spider} editor in Java.
|
MSc and the project was to create an Euler/Spider~Diagram~\cite{howse:spider} editor in Java.
|
||||||
This editor allowed the user to draw Euler/Spider diagrams, and could then
|
This editor allowed the user to draw Euler/Spider diagrams, and could then
|
||||||
represent these as abstract---i.e. mathematical---definitions.
|
represent these as abstract---i.e. mathematical---definitions.
|
||||||
%
|
%
|
||||||
@ -110,25 +120,28 @@ to formal languages for software specification.
|
|||||||
An added attraction for using spider diagrams was that they could be used in
|
An added attraction for using spider diagrams was that they could be used in
|
||||||
proving logic~\cite{stapleton:atpieds} and theorems~\cite{theoremflower,Fish200553} in an intuitive way.
|
proving logic~\cite{stapleton:atpieds} and theorems~\cite{theoremflower,Fish200553} in an intuitive way.
|
||||||
%
|
%
|
||||||
Because of my daily work exposure to FMEA,
|
Because of the author's daily work exposure to FMEA,
|
||||||
I started thinking of ways to apply formal languages and spider diagrams to
|
%I started thinking
|
||||||
|
it was natural to think
|
||||||
|
of ways to apply formal languages and spider diagrams to
|
||||||
failure mode analysis.
|
failure mode analysis.
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
\paragraph{European Safety Requirements increase in scope and complexity.}
|
\paragraph{European Safety Requirements increase in scope and complexity.}
|
||||||
At work---which consisted of designing, testing, building and writing embedded `C' and assembly language code for safety critical
|
At work---which consisted of designing, testing, building and writing embedded `C' and assembly language code for safety critical
|
||||||
industrial burners---we were faced with a new and daunting requirement.
|
industrial burners---the design team was faced with a new and daunting requirement.
|
||||||
Conformance to the latest European standard, EN298~\cite{en298}.
|
Conformance to the latest European standard, EN298~\cite{en298}.
|
||||||
%
|
%
|
||||||
It appeared to ask for the impossible:
|
It appeared to ask for the impossible:
|
||||||
not only did it require the usual safety measures (self checking of ROM and RAM, watchdog processors with separate clock sources, EMC and the
|
not only did it require the usual safety measures (self-checking of ROM and RAM, watchdog processors with separate clock sources, EMC and the
|
||||||
triple fail safe control of valves), it had one new clause in it that had far reaching consequences.
|
triple fail safe control of valves), it had one new clause in it that had far reaching consequences.
|
||||||
%
|
%
|
||||||
It stated that in the event of a failure, where the controller had gone into a `lockout~state'--- a state where the controller
|
It stated that in the event of a failure, where the controller had gone into a `lockout~state'--- a state where the controller
|
||||||
applies all possible safety measures to stop fuel entering the burner---it was not permitted to % could not
|
applies all possible safety measures to stop fuel entering the burner---it was not permitted to % could not
|
||||||
become dangerous should another fault occur.
|
become dangerous should another fault occur.
|
||||||
%
|
%
|
||||||
In short this meant we had to be able to deal with double failures.
|
In short this meant %we had to be able to
|
||||||
|
dealing with double failures.
|
||||||
%
|
%
|
||||||
Any of the components that could, in failing, create a dangerous state were already
|
Any of the components that could, in failing, create a dangerous state were already
|
||||||
documented and approved using failure mode effects analysis (FMEA).
|
documented and approved using failure mode effects analysis (FMEA).
|
||||||
@ -149,44 +162,66 @@ analysis of identical circuitry was performed many times.
|
|||||||
|
|
||||||
%
|
%
|
||||||
\subsection{Modularising/De-Composing FMEA: Initial concepts.} % and augmenting this with concepts from Euler/Spider Diagrams.}
|
\subsection{Modularising/De-Composing FMEA: Initial concepts.} % and augmenting this with concepts from Euler/Spider Diagrams.}
|
||||||
|
%
|
||||||
In the field of digital signal processing there is an algorithm that revolutionised
|
In the field of digital signal processing there is an algorithm that revolutionised
|
||||||
access to frequency analysis of digital samples called the Fast Fourier transform (FFT)~\cite{fftoriginal}.
|
access to frequency analysis of digital samples called the Fast Fourier transform (FFT)~\cite{fftoriginal}.
|
||||||
This took the discrete Fourier transform (DFT), and applied de-composition to its
|
This took the discrete Fourier transform (DFT), and applied de-composition to its
|
||||||
mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].
|
mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].
|
||||||
%
|
%
|
||||||
By doing this it broke the computing order of complexity problem down from having a polynomial %n exponential
|
By doing this it broke the computing order of complexity down from having a polynomial %n exponential
|
||||||
%order
|
%order
|
||||||
to logarithmic order~\cite{ctw}[pp.401-3].
|
to logarithmic order~\cite{ctw}[pp.401-3].
|
||||||
I wondered if this thinking could be applied to the state explosion problems encountered in FMEA.
|
%
|
||||||
|
The author wondered if this thinking could be applied to the state explosion problems encountered in FMEA.
|
||||||
%
|
%
|
||||||
%Following the concept of de-composing a problem, and thus simplifying the state explosion---using the thinking behind
|
%Following the concept of de-composing a problem, and thus simplifying the state explosion---using the thinking behind
|
||||||
%the fast Fourier transform (FFT)~\cite{fpodsadsp}[Ch.8], which takes a complex intermeshed series of real and imaginary number calculations
|
%the fast Fourier transform (FFT)~\cite{fpodsadsp}[Ch.8], which takes a complex intermeshed series of real and imaginary number calculations
|
||||||
%and by de-composing them, simplifies the problem.
|
%and by de-composing them, simplifies the problem.
|
||||||
My reasoning was that if we analysed %were we to analyse
|
|
||||||
the problem in small modules, from the bottom-up following the FFT example, we could apply
|
|
||||||
checking for all double failure scenarios.
|
|
||||||
%
|
%
|
||||||
Once these first modules were analysed---we now call them {\fgs}---we could determine the symptoms of failure for them.
|
% My reasoning was that if we analysed %were we to analyse
|
||||||
Using the symptoms of failure, we could now treat these modules as components in their own right---or {\dcs}---and use them to build higher level
|
% the problem in small modules, from the bottom-up following the FFT example, we could apply
|
||||||
{\fgs}. Higher and higher levels of {\fgs} could be built until we had a hierarchy
|
% checking for all double failure scenarios.
|
||||||
representing a failure mode model for the system.
|
The authors reasoning was that if %were we to analyse
|
||||||
|
the problem were analysed in small modules, from the bottom-up following the FFT example,
|
||||||
|
checking for all double failure scenarios could have been applied.
|
||||||
%
|
%
|
||||||
Because this is modular, %we can apply double simultaneous failure mode checking; and as %because
|
% Once these first modules were analysed---we now call them {\fgs}---we could determine the symptoms of failure for them.
|
||||||
double simultaneous failure mode checking can be applied as
|
% Using the symptoms of failure, we could now treat these modules as components in their own right---or {\dcs}---and use them to build higher level
|
||||||
|
% {\fgs}. Higher and higher levels of {\fgs} could be built until we had a hierarchy
|
||||||
|
% representing a failure mode model for the system.
|
||||||
|
Once these first modules were analysed---now called {\fgs}---the symptoms of failure could be determined for them.
|
||||||
|
%
|
||||||
|
Using the symptoms of failure, these modules could be treated as components in their own right---or {\dcs}---and used to build higher level
|
||||||
|
{\fgs}.
|
||||||
|
%
|
||||||
|
Higher and higher levels of {\fgs} could be built until a hierarchy
|
||||||
|
representing a failure mode model for the complete system had been created.
|
||||||
|
%
|
||||||
|
%Because this is modular, %we can apply double simultaneous failure mode checking; and as %because
|
||||||
|
Double simultaneous failure mode checking can be applied as
|
||||||
the number of components
|
the number of components
|
||||||
in each {\fg} is typically small; we therefore avoid state explosion problems. % for the general case. % AF says `in the general case' here 12JAN2013
|
in each {\fg} is typically small; state explosion problems are thus avoided. % for the general case. % AF says `in the general case' here 12JAN2013
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
If we apply
|
% If we apply
|
||||||
double checking all the way up the hierarchy we can guarantee to have considered
|
% double checking all the way up the hierarchy we can guarantee to have considered
|
||||||
every double simultaneous failure of all components in a system.
|
% every double simultaneous failure of all components in a system.
|
||||||
|
If
|
||||||
|
double checking is applied all the way up the hierarchy,
|
||||||
|
%we can guarantee to have considered
|
||||||
|
all possible
|
||||||
|
double simultaneous failures in a system can be guaranteed to have been considered.
|
||||||
%
|
%
|
||||||
This means, as a fortunate by-product, that many multiple as well as double
|
This means, as a fortunate by-product, that many multiple as well as double
|
||||||
failures would be analysed, but because failure modes are traceable from the base components to the top level---or system---failure modes,
|
failures would be analysed, but because failure modes are traceable from the base components to the top level---or system---failure modes,
|
||||||
these relationships can be held in a traversable data structure.
|
these relationships can be held in a traversable data structure.
|
||||||
%
|
%
|
||||||
If held in a traversable data structure we can apply automated methods to search for all the combinations of multiple failure modes
|
% If held in a traversable data structure we can apply automated methods to search for all the combinations of multiple failure modes
|
||||||
within the model that had been analysed. Because of this, it will not always %it may not
|
% within the model that had been analysed.
|
||||||
|
If held in a traversable data structure automated methods can be applied to search for all the combinations of multiple failure modes
|
||||||
|
throughout the model being analysed.
|
||||||
|
%
|
||||||
|
Because of this, it will not always %it may not
|
||||||
be necessary to apply double checking
|
be necessary to apply double checking
|
||||||
at all higher levels in the analysis hierarchy, to achieve complete double failure coverage.
|
at all higher levels in the analysis hierarchy, to achieve complete double failure coverage.
|
||||||
%
|
%
|
||||||
@ -239,21 +274,23 @@ FMEA which solves the problems of:
|
|||||||
To support this, worked examples using the new methodology were created and the work published and presented to
|
To support this, worked examples using the new methodology were created and the work published and presented to
|
||||||
IET safety conferences. % in 2011~\cite{syssafe2011} and 2012~\cite{syssafe2012}.
|
IET safety conferences. % in 2011~\cite{syssafe2011} and 2012~\cite{syssafe2012}.
|
||||||
%
|
%
|
||||||
The development of FMMD, starting with a critique of FMEA and a wish-list for a better methodology,
|
The development of FMMD, starting with a critique of FMEA and a ``wish-list'' for a better methodology,
|
||||||
was presented to the IET System safety conference in 2011,~\cite{syssafe2011}.
|
was presented to the IET System safety conference in 2011,~\cite{syssafe2011}.
|
||||||
%
|
%
|
||||||
FMEA, currently cannot integrate software models into its hardware failure mode models~\cite{sfmea,modelsfmea,embedsfmea,sfmeainterface}.
|
FMEA, currently cannot integrate software models into its hardware failure mode models~\cite{sfmea,modelsfmea,embedsfmea,sfmeainterface}, but
|
||||||
%
|
%
|
||||||
FMMD can use the existing structure of functional software, in conjunction
|
FMMD can use the existing structure of functional software, in conjunction
|
||||||
with contract programming, to model software and this concept was presented to the IET System safety conference in 2012~\cite{syssafe2012}.
|
with contract programming to model software;
|
||||||
|
%and
|
||||||
|
this concept was presented to the IET System safety conference in 2012~\cite{syssafe2012}.
|
||||||
|
|
||||||
\paragraph{Overview---quick guide to contents of the thesis.}
|
\paragraph{Overview of the thesis.}
|
||||||
Chapter~\ref{sec:chap2} examines the current state of FMEA based methodologies, Chapter~\ref{sec:chap3}
|
Chapter~\ref{sec:chap2} examines the current state of FMEA based methodologies, Chapter~\ref{sec:chap3}
|
||||||
examines the benefits and drawbacks of these methodologies
|
examines the benefits and drawbacks of these methodologies
|
||||||
and proposes a detailed wish list for an ideal FMEA technique.
|
and proposes a detailed wish list for an ideal FMEA technique.
|
||||||
Chapter~\ref{sec:chap4} proposes Failure Mode Modular de-composition (FMMD)---a modularised variant
|
Chapter~\ref{sec:chap4} proposes Failure Mode Modular de-composition (FMMD)---a modularised variant
|
||||||
of FMEA designed to address the points in the detailed wish list.
|
of FMEA designed to address the points in the detailed wish list.
|
||||||
Chapter~\ref{sec:chap5} provides worked examples using common electronic circuits.
|
Chapter~\ref{sec:chap5} provides worked examples using selected electronic circuits.
|
||||||
Chapter~\ref{sec:chap6} gives two examples of integrated software and electronic systems analysed using FMMD.
|
Chapter~\ref{sec:chap6} gives two examples of integrated software and electronic systems analysed using FMMD.
|
||||||
Metrics and evaluation, along with an example showing double simultaneous failure analysis,
|
Metrics and evaluation, along with an example showing double simultaneous failure analysis,
|
||||||
are provided in Chapter~\ref{sec:chap7}, with a conclusion and further work in Chapter~\ref{sec:chap8}.
|
are provided in Chapter~\ref{sec:chap7}, with a conclusion and further work in Chapter~\ref{sec:chap8}.
|
||||||
|
@ -329,7 +329,8 @@ include the failure mode DRIFT. EN298 does not include this, mainly because it i
|
|||||||
that effectively side step that problem.
|
that effectively side step that problem.
|
||||||
%
|
%
|
||||||
For this study we will take the conservative view from EN298, and consider the failure
|
For this study we will take the conservative view from EN298, and consider the failure
|
||||||
modes for a generic resistor to be both OPEN and SHORT.
|
modes for a generic resistor to be both OPEN and SHORT. We use the function $fm$
|
||||||
|
to return a set of failure modes,
|
||||||
i.e.
|
i.e.
|
||||||
\label{ros}
|
\label{ros}
|
||||||
$$ fm(R) = \{ OPEN, SHORT \} . $$
|
$$ fm(R) = \{ OPEN, SHORT \} . $$
|
||||||
@ -519,7 +520,7 @@ $$ fm(OPAMP) = \{ LOW, HIGH, NOOP, LOW_{slew} \} $$
|
|||||||
|
|
||||||
|
|
||||||
The EN298 pinouts failure mode technique cannot reveal failure modes due to internal failures,
|
The EN298 pinouts failure mode technique cannot reveal failure modes due to internal failures,
|
||||||
and that is why is misses the $LOW_{slew}$.
|
and that is why it misses the $LOW_{slew}$.
|
||||||
%
|
%
|
||||||
The FMD-91 entries for op-amps are not directly usable as
|
The FMD-91 entries for op-amps are not directly usable as
|
||||||
component {\fms} in FMEA or FMMD and require interpretation.
|
component {\fms} in FMEA or FMMD and require interpretation.
|
||||||
@ -615,7 +616,8 @@ that reports its readings via RS-232.
|
|||||||
\subsection{FMEA Example: Milli-volt reader}
|
\subsection{FMEA Example: Milli-volt reader}
|
||||||
Let us perform an FMEA and consider how one of its resistors failing could affect
|
Let us perform an FMEA and consider how one of its resistors failing could affect
|
||||||
it.
|
it.
|
||||||
For the sake of example let us choose resistor R1 in the OP-AMP gain circuitry.
|
%For the sake of example
|
||||||
|
Let us choose resistor R1 in the OP-AMP gain circuitry.
|
||||||
% \begin{figure}
|
% \begin{figure}
|
||||||
% \centering
|
% \centering
|
||||||
% \includegraphics[width=175pt]{./mvamp.png}
|
% \includegraphics[width=175pt]{./mvamp.png}
|
||||||
@ -640,8 +642,8 @@ For the sake of example let us choose resistor R1 in the OP-AMP gain circuitry.
|
|||||||
\fmeagloss
|
\fmeagloss
|
||||||
|
|
||||||
|
|
||||||
The analysis above has given us a result for one failure scenario i.e.
|
The analysis above has given us a result for % one failure %scenario i.e.
|
||||||
for one component failure mode.
|
one single component failure mode.
|
||||||
A complete FMEA report would have to contain an entry
|
A complete FMEA report would have to contain an entry
|
||||||
for each failure mode of all the components in the system under investigation.
|
for each failure mode of all the components in the system under investigation.
|
||||||
%
|
%
|
||||||
@ -716,11 +718,11 @@ we can hop from module to module eliminating working modules, until we find the
|
|||||||
failure~\cite{maikowski}.
|
failure~\cite{maikowski}.
|
||||||
%
|
%
|
||||||
The rationale and work-culture of those tasked to
|
The rationale and work-culture of those tasked to
|
||||||
perform FMEA are generally personnel who have performed fault finding.
|
perform FMEA are generally personnel who have performed fault finding~\cite{cbds}[p.97].
|
||||||
%
|
%
|
||||||
|
|
||||||
|
|
||||||
FMEA is a theoretical discipline.
|
FMEA is a theoretical discipline. %AF does not like this!
|
||||||
%
|
%
|
||||||
It would be very unusual to build a circuit and then simulate
|
It would be very unusual to build a circuit and then simulate
|
||||||
component failure modes.
|
component failure modes.
|
||||||
@ -749,8 +751,11 @@ For a more complete analysis, we should perhaps examine each component {\fm} alo
|
|||||||
forwards and backwards from the placement
|
forwards and backwards from the placement
|
||||||
of the component exhibiting the {\fm} under investigation.
|
of the component exhibiting the {\fm} under investigation.
|
||||||
%
|
%
|
||||||
Also, whether following the effects through the signal path {\em only} is acceptable, and instead
|
% Also, whether following the effects through the signal path {\em only} is acceptable, and instead
|
||||||
would looking at its effect on all other components in the system be necessary?
|
% would looking at its effect on all other components in the system be necessary?
|
||||||
|
Is following the effects of a {\fm} {\em only} through the components along the signal path acceptable?
|
||||||
|
This could easily ignore side effects; this leads onto the idea of
|
||||||
|
looking at a {\fm}'s effects on all other components in the system. % be necessary?
|
||||||
%is a matter for debate.
|
%is a matter for debate.
|
||||||
%
|
%
|
||||||
In practise, a compromise is made between the amount of time/money that can be spent
|
In practise, a compromise is made between the amount of time/money that can be spent
|
||||||
@ -930,14 +935,17 @@ statistical estimates of the equipment reliability.
|
|||||||
\fmmdglossBS
|
\fmmdglossBS
|
||||||
A forward search starts with possible failure causes
|
A forward search starts with possible failure causes
|
||||||
and uses logic and reasoning to determine system level outcomes.
|
and uses logic and reasoning to determine system level outcomes.
|
||||||
Forward search types of fault analysis is said to be `inductive'.
|
%
|
||||||
|
Forward search types of fault analysis are said to be `inductive'.
|
||||||
%
|
%
|
||||||
A backward search starts with (undesirable) system level events and
|
A backward search starts with (undesirable) system level events and
|
||||||
works back down to potential causes using de-composition
|
works back down to potential causes using de-composition
|
||||||
of the system and logic.
|
of the system and logic.
|
||||||
FMEA based methodologies are forward searches\cite{Lutz:1997:RAU:590564.590572} and top down
|
FMEA based methodologies are forward searches\cite{Lutz:1997:RAU:590564.590572} and top down
|
||||||
methodologies such as FTA~\cite{nucfta,nasafta} are backward searches.
|
methodologies such as FTA~\cite{nucfta,nasafta} are backward searches.
|
||||||
Forward search types of fault analysis is said to be `deductive'.
|
%
|
||||||
|
Forward search types of fault analysis are said to be `deductive'.
|
||||||
|
%
|
||||||
Backward (or bottom-up) searches are said to be inductive (i.e. the results of failure are
|
Backward (or bottom-up) searches are said to be inductive (i.e. the results of failure are
|
||||||
induced).
|
induced).
|
||||||
|
|
||||||
@ -946,7 +954,7 @@ induced).
|
|||||||
\paragraph{Reasoning distance.}
|
\paragraph{Reasoning distance.}
|
||||||
\label{reasoningdistance}
|
\label{reasoningdistance}
|
||||||
\fmmdglossRD
|
\fmmdglossRD
|
||||||
A reasoning distance is the number of stages of logic and reasoning used
|
A reasoning distance, is defined here, as the number of stages of logic and reasoning used
|
||||||
in {\fm} analysis to map a failure cause to its potential outcomes.
|
in {\fm} analysis to map a failure cause to its potential outcomes.
|
||||||
%
|
%
|
||||||
In our basic FMEA example in section~\ref{basicfmea}
|
In our basic FMEA example in section~\ref{basicfmea}
|
||||||
@ -966,9 +974,16 @@ this would give us the maximum reasoning distance.
|
|||||||
%
|
%
|
||||||
We term this the exhaustive FMEA case.
|
We term this the exhaustive FMEA case.
|
||||||
%does not
|
%does not
|
||||||
The exhaustive~reasoning~distance would be
|
% The exhaustive~reasoning~distance would be
|
||||||
the sum of the number of failure modes, against all other components
|
% the sum of the number of failure modes, against all other components
|
||||||
in that system.
|
% in that system.
|
||||||
|
The exhaustive~reasoning~distance for a particular component
|
||||||
|
would be to multiply
|
||||||
|
the number of failure modes it has by the number of remaining components
|
||||||
|
in the system.
|
||||||
|
%
|
||||||
|
The exhaustive reasoning~distance for a system would be the
|
||||||
|
the sum of these multiplications for all the components it contains.
|
||||||
%
|
%
|
||||||
If the milli-volt reader had say 100 components, with three failure modes each, this
|
If the milli-volt reader had say 100 components, with three failure modes each, this
|
||||||
would give an exhaustive reasoning distance---for single failure analysis---of 3 * 100 * 99.
|
would give an exhaustive reasoning distance---for single failure analysis---of 3 * 100 * 99.
|
||||||
@ -1007,12 +1022,12 @@ of a failure mode with all other components in a system). Or in other words,
|
|||||||
---we would need to look at all possible failure scenarios.
|
---we would need to look at all possible failure scenarios.
|
||||||
%to do this completely (all failure modes against all components).
|
%to do this completely (all failure modes against all components).
|
||||||
This is represented in the equation below, %~\ref{eqn:fmea_state_exp},
|
This is represented in the equation below, %~\ref{eqn:fmea_state_exp},
|
||||||
where $N$ is the total number of components in the system, and
|
where $N$ is the total number of components in the system, $RD_{single}$ is the reasoning~distance and
|
||||||
$f$ is the number of failure modes per component.
|
$f$ is the number of failure modes per component.
|
||||||
%
|
%
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\label{eqn:fmea_single}
|
\label{eqn:fmea_single}
|
||||||
N.(N-1).f % \\
|
RD_{single} = N.(N-1).f % \\
|
||||||
%(N^2 - N).f
|
%(N^2 - N).f
|
||||||
\end{equation}
|
\end{equation}
|
||||||
%
|
%
|
||||||
@ -1029,10 +1044,10 @@ scenarios\footnote{Certain double failure scenarios are already legal
|
|||||||
requirements---The European Gas burner standard (EN298:2003)---demands the checking of
|
requirements---The European Gas burner standard (EN298:2003)---demands the checking of
|
||||||
double failure scenarios (for burner lock-out scenarios).}
|
double failure scenarios (for burner lock-out scenarios).}
|
||||||
(two components failing within a given time frame) and the order becomes $O(N^3)$.
|
(two components failing within a given time frame) and the order becomes $O(N^3)$.
|
||||||
|
Where $RD_{double}$ is the reasoning~distance for double failure scenarios:
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\label{eqn:fmea_double}
|
\label{eqn:fmea_double}
|
||||||
N.(N-1).(N-2).f % \\
|
RD_{double} = N.(N-1).(N-2).f . % \\
|
||||||
%(N^2 - N).f
|
%(N^2 - N).f
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
@ -1096,12 +1111,15 @@ number for the germane component {\fm}.
|
|||||||
%
|
%
|
||||||
Fixing problems with the highest RPN number
|
Fixing problems with the highest RPN number
|
||||||
will return most cost benefit~\cite{bfmea}.
|
will return most cost benefit~\cite{bfmea}.
|
||||||
|
%
|
||||||
|
An example PFMEA report is presented in table~\ref{tbl:pfmeareport}.
|
||||||
|
|
||||||
% benign example of PFMEA in CARS - make something up.
|
% benign example of PFMEA in CARS - make something up.
|
||||||
\subsection{PFMEA Example}
|
\subsection{PFMEA Example}
|
||||||
\begin{table}[ht]
|
\begin{table}[ht]
|
||||||
|
\label{tbl:pfmeareport}
|
||||||
\caption{FMEA Calculations} % title of Table
|
\caption{FMEA Calculations} % title of Table
|
||||||
%\centering % used for centering table
|
\centering % used for centering table
|
||||||
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
||||||
\textbf{Failure Mode} & \textbf{P} & \textbf{Cost} & \textbf{Symptom} & \textbf{RPN} \\ \hline \hline
|
\textbf{Failure Mode} & \textbf{P} & \textbf{Cost} & \textbf{Symptom} & \textbf{RPN} \\ \hline \hline
|
||||||
relay 1 n/c & $1*10^{-5}$ & 38.0 & indicators fail & 0.00038 \\ \hline
|
relay 1 n/c & $1*10^{-5}$ & 38.0 & indicators fail & 0.00038 \\ \hline
|
||||||
@ -1168,8 +1186,9 @@ a particular failure~mode occurring within a component~\cite{fmd91}.
|
|||||||
\textbf{FMECA $\beta$ value.}
|
\textbf{FMECA $\beta$ value.}
|
||||||
The second probability factor $\beta$, is the probability that the failure mode
|
The second probability factor $\beta$, is the probability that the failure mode
|
||||||
will cause a given system failure.
|
will cause a given system failure.
|
||||||
This corresponds to `Bayesian' probability, given a particular
|
%
|
||||||
component failure mode, the probability of a given system level failure.
|
This corresponds to `Bayesian' probability, i.e. given a particular
|
||||||
|
component failure mode, the probability of a given system level failure~\cite{nucfta}[VI-19].
|
||||||
|
|
||||||
\textbf{FMECA `t' Value.}
|
\textbf{FMECA `t' Value.}
|
||||||
The time that a system will be operating for, or the working life time of the product is
|
The time that a system will be operating for, or the working life time of the product is
|
||||||
@ -1324,9 +1343,9 @@ and is normally expressed as a percentage~\cite{en61508}[2-Annex C].
|
|||||||
%
|
%
|
||||||
$\Sigma\lambda_{DD}$ represents
|
$\Sigma\lambda_{DD}$ represents
|
||||||
the percentage of dangerous detected base component failure modes, and
|
the percentage of dangerous detected base component failure modes, and
|
||||||
$\Sigma\lambda_D$ the total number of dangerous base component failure modes.
|
$\Sigma\lambda_D$ the total number of dangerous base component failure modes,
|
||||||
%
|
%
|
||||||
$$ DiagnosticCoverage = \Sigma\lambda_{DD} / \Sigma\lambda_D $$
|
$$ DiagnosticCoverage = \Sigma\lambda_{DD} / \Sigma\lambda_D . $$
|
||||||
\fmmdglossFMEDA
|
\fmmdglossFMEDA
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
@ -1337,7 +1356,7 @@ safe detected base component failure modes,
|
|||||||
and $\Sigma\lambda_S$ the total number of safe base component failure modes,
|
and $\Sigma\lambda_S$ the total number of safe base component failure modes,
|
||||||
is given as
|
is given as
|
||||||
%
|
%
|
||||||
$$ SF = \frac{\Sigma\lambda_{SD}}{\Sigma\lambda_S} $$
|
$$ SF = \frac{\Sigma\lambda_{SD}}{\Sigma\lambda_S} . $$
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
@ -1346,9 +1365,9 @@ $$ SF = \frac{\Sigma\lambda_{SD}}{\Sigma\lambda_S} $$
|
|||||||
A key concept in FMEDA is Safe Failure Fraction (SFF).
|
A key concept in FMEDA is Safe Failure Fraction (SFF).
|
||||||
This is the ratio of safe and dangerous detected failures
|
This is the ratio of safe and dangerous detected failures
|
||||||
against all safe and dangerous failure probabilities.
|
against all safe and dangerous failure probabilities.
|
||||||
Again this is usually expressed as a percentage.
|
Again this is usually expressed as a percentage,
|
||||||
%
|
%
|
||||||
$$ SFF = \big( \Sigma\lambda_S + \Sigma\lambda_{DD} \big) / \big( \Sigma\lambda_S + \Sigma\lambda_D \big) $$
|
$$ SFF = \big( \Sigma\lambda_S + \Sigma\lambda_{DD} \big) / \big( \Sigma\lambda_S + \Sigma\lambda_D \big) . $$
|
||||||
%
|
%
|
||||||
SFF determines how proportionately fail-safe a system is, not how reliable it is.
|
SFF determines how proportionately fail-safe a system is, not how reliable it is.
|
||||||
A weakness in this philosophy; adding extra safe failures (even unused ones) would improve the apparent SFF, this
|
A weakness in this philosophy; adding extra safe failures (even unused ones) would improve the apparent SFF, this
|
||||||
@ -1389,7 +1408,7 @@ judged to be in critical sections of the product.
|
|||||||
This could be considered as a design check method, deliberately
|
This could be considered as a design check method, deliberately
|
||||||
looking for weaknesses at a theoretical level.
|
looking for weaknesses at a theoretical level.
|
||||||
%
|
%
|
||||||
\subsection{DESIGN FMEA: Safety Critical Approvals FMEA}
|
%\subsection{DESIGN FMEA: Safety Critical Approvals FMEA}
|
||||||
%
|
%
|
||||||
% \begin{figure}[h]
|
% \begin{figure}[h]
|
||||||
% \centering
|
% \centering
|
||||||
@ -1402,7 +1421,7 @@ looking for weaknesses at a theoretical level.
|
|||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Impossible to look at all component failures let alone apply FMEA exhaustively/rigorously.
|
\item Impossible to look at all component failures let alone apply FMEA exhaustively/rigorously.
|
||||||
\item In practice, failure scenarios for critical sections are contested, and either justified or extra safety measures implemented.
|
\item In practice, failure scenarios for critical sections are contested, and either justified or extra safety measures implemented.
|
||||||
\item Often Meeting notes or minutes only. Unusual for detailed technical arguments to be documented.
|
\item Often meeting notes or minutes only. Unusual for detailed technical arguments to be documented.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
@ -1415,10 +1434,14 @@ looking for weaknesses at a theoretical level.
|
|||||||
\label{fig:component_fm_rel_ana_subj_obj}
|
\label{fig:component_fm_rel_ana_subj_obj}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
%
|
%
|
||||||
Returning to the FMEA model, we now show that the data relationships shown in
|
Returning to the FMEA model, the data relationships shown in
|
||||||
figure~\ref{fig:component_fm_rel_ana} hold for the five variants of FMEA discussed.
|
figure~\ref{fig:component_fm_rel_ana} hold for the five variants of FMEA discussed.
|
||||||
We can however, extend this
|
%
|
||||||
with subjective failure mode symptoms (see figure~\ref{fig:component_fm_rel_ana_subj_obj}).
|
This could be extended, if it is considered that the system level symptoms have subjective
|
||||||
|
interpretations.
|
||||||
|
%
|
||||||
|
With the addition of subjective failure mode symptoms, the UML model for FMEA gains an attribute
|
||||||
|
(see figure~\ref{fig:component_fm_rel_ana_subj_obj}).
|
||||||
%
|
%
|
||||||
The UML data model reveals some undefined qualities of FMEA.
|
The UML data model reveals some undefined qualities of FMEA.
|
||||||
These raise questions and are discussed below.
|
These raise questions and are discussed below.
|
||||||
@ -1426,29 +1449,36 @@ These raise questions and are discussed below.
|
|||||||
\paragraph{Which, or how many components should we check for each {\fm} entry?}
|
\paragraph{Which, or how many components should we check for each {\fm} entry?}
|
||||||
For instance a given {\fm} will have its effect measured in relation
|
For instance a given {\fm} will have its effect measured in relation
|
||||||
to some of the components in the system.
|
to some of the components in the system.
|
||||||
We could choose these components by stipulating several criteria,
|
%
|
||||||
relating this to the signal path or adjacency in the electronic circuit, among which are:
|
These components can be chosen by stipulating several criteria,
|
||||||
|
relating this to the signal path or adjacency in the electronic circuit,
|
||||||
|
potential strategies are listed below:
|
||||||
|
%
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item look at all components electronically adjacent (i.e. connected to the affected component)
|
\item look at all components electronically adjacent (i.e. connected to the affected component),
|
||||||
\item Look at all components connected (as above) and those one removed (those connected to those connected to the affected component)
|
\item Look at all components connected (as above) and those one removed (those connected to those connected to the affected component),
|
||||||
\item Look at components forward of the {\fm} in the signal path.
|
\item Look at components forward of the {\fm} in the signal path,
|
||||||
\item Look at all components in the signal path.
|
\item Look at all components in the signal path,
|
||||||
\item Look at all components in the signal path including those one connection removed on.
|
\item Look at all components in the signal path including those one connection removed,
|
||||||
\item Look at all components in the system.
|
\item Look at all components in the system (i.e. XFMEA).
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
No current variant of FMEA gives any guidelines for which, or how many components to check for a given {\fm}.
|
No current variant of FMEA gives any guidelines for which, or how many components to check for a given {\fm}.
|
||||||
\fmmdglossRD
|
\fmmdglossRD
|
||||||
\paragraph{FMEA gives us objective system level failures/symptoms, what do we do with subjective or contextual failures resulting from this?}
|
\paragraph{FMEA gives us objective system level failures/symptoms.} %, what do we do with subjective or contextual failures resulting from this?}
|
||||||
|
%
|
||||||
The two more modern variants of FMEA, FMECA and FMEDA start to address the problem of subjective/contextual
|
The two more modern variants of FMEA, FMECA and FMEDA start to address the problem of subjective/contextual
|
||||||
failure symptoms of a system.
|
failure symptoms of a system.
|
||||||
%
|
%
|
||||||
FMEDA classifies them as dangerous or safe failures.
|
FMEDA classifies them as dangerous or safe failures.
|
||||||
|
%
|
||||||
FMECA gives us a statistically biased criticality level.
|
FMECA gives us a statistically biased criticality level.
|
||||||
In both of these methodologies however, there is no formal stage where we map from an objective to subjective
|
%
|
||||||
system failure, the processes are intertwined with the basic analysis itself.
|
In both of these methodologies however, there is no formal stage where objective to subjective
|
||||||
|
system failures are mapped, this processes seems to be intertwined with the basic analysis itself.
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
\paragraph{Re-use potential of an FMEA report.}
|
\paragraph{Re-use potential of an FMEA report.}
|
||||||
|
%
|
||||||
Each {\fm} entry in an FMEA report should have a reasoning or comments field.
|
Each {\fm} entry in an FMEA report should have a reasoning or comments field.
|
||||||
This should provide a guide to someone re-examining, or trying to re-use results
|
This should provide a guide to someone re-examining, or trying to re-use results
|
||||||
on a similar project.
|
on a similar project.
|
||||||
@ -1464,121 +1494,6 @@ Because FMEA is traditionally performed with one entry per component {\fm}, full
|
|||||||
are rare.
|
are rare.
|
||||||
This means that re-use, review and checking of traditional analysis must often be started from `cold'.
|
This means that re-use, review and checking of traditional analysis must often be started from `cold'.
|
||||||
%
|
%
|
||||||
% MOVED TO CH3: 15MAR2013
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
% \section{Conclusions on current FMEA Methodologies}
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
%
|
|
||||||
% %% FOCUS
|
|
||||||
% The focus of this chapter %literature review
|
|
||||||
% is to establish the current practice and applications
|
|
||||||
% of FMEA.
|
|
||||||
% %, and to examine its strengths and weaknesses.
|
|
||||||
% %% GOAL
|
|
||||||
% Its
|
|
||||||
% goal is to identify central issues and to criticise and assess the current
|
|
||||||
% FMEA methodologies.
|
|
||||||
% %% PERSPECTIVE
|
|
||||||
% The perspective of the author, is as a practitioner of static failure mode analysis techniques
|
|
||||||
% concerning approval of product
|
|
||||||
% to European safety standards, both the prescriptive~\cite{en298,en230} and statistical~\cite{en61508}.
|
|
||||||
% A second perspective is that of a software engineer trained to use formal methods.
|
|
||||||
% Examining FMEA methodologies for mathematical properties, influenced by
|
|
||||||
% formal methods applied to software, should provide a perspective not traditionally considered.
|
|
||||||
% %% COVERAGE
|
|
||||||
% The literature reviewed, has been restricted to published books, European safety standards (as examples
|
|
||||||
% of current safety measures applied), and traditional research, from journal and conference papers.
|
|
||||||
% %% ORGANISATION
|
|
||||||
% The review is organised by concept, that is, FMEA can be applied to hardware, software, software~interfacing and
|
|
||||||
% to multiple failure scenarios etc. Methodologies related to FMEA are briefly covered for the sake of context.
|
|
||||||
% %% AUDIENCE
|
|
||||||
% % Well duh! PhD supervisors and examiners....
|
|
||||||
%
|
|
||||||
% % \subsection{Related Methodologies}
|
|
||||||
% % FTA --- HAZOP --- ALARP --- Event Tree Analysis --- bow tie concept
|
|
||||||
% % \subsection{Hardware FMEA (HFMEA)}
|
|
||||||
% % \subsection{Multiple Failure scenarios and FMEA}
|
|
||||||
% % \subsection{Software FMEA (SFMEA)}
|
|
||||||
%
|
|
||||||
% \paragraph{Current work on Software FMEA}
|
|
||||||
%
|
|
||||||
% SFMEA usually does not seek to integrate
|
|
||||||
% hardware and software models, but to perform
|
|
||||||
% FMEA on the software in isolation~\cite{procsfmea}.
|
|
||||||
% %
|
|
||||||
% Work has been performed using databases
|
|
||||||
% to track the relationships between variables
|
|
||||||
% and system failure modes~\cite{procsfmeadb}, to %work has been performed to
|
|
||||||
% introduce automation into the FMEA process~\cite{appswfmea} and to provide code analysis
|
|
||||||
% automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately,
|
|
||||||
% some schools of thought aim for Fault Tree Analysis (FTA)~\cite{nasafta,nucfta} (top down - deductive)
|
|
||||||
% and FMEA (bottom-up inductive)
|
|
||||||
% to be performed on the same system to provide insight into the
|
|
||||||
% software hardware/interface~\cite{embedsfmea}.
|
|
||||||
% %
|
|
||||||
% Although this
|
|
||||||
% would give a better picture of the failure mode behaviour, it
|
|
||||||
% is by no means a rigorous approach to tracing errors that may occur in hardware
|
|
||||||
% through to the top (and therefore ultimately controlling) layer of software.
|
|
||||||
%
|
|
||||||
% \paragraph{Current FMEA techniques are not suitable for software}
|
|
||||||
%
|
|
||||||
% The main FMEA methodologies are all based on the concept of taking
|
|
||||||
% base component {\fms}, and translating them into system level events/failures~\cite{sfmea,sfmeaa}.
|
|
||||||
% %
|
|
||||||
% In a complicated system, mapping a component failure mode to a system level failure
|
|
||||||
% will mean a long reasoning distance; that is to say the actions of the
|
|
||||||
% failed component will have to be traced through
|
|
||||||
% several sub-systems, gauging its effects with and on other components.
|
|
||||||
% %
|
|
||||||
% With software at the higher levels of these sub-systems,
|
|
||||||
% we have yet another layer of complication.
|
|
||||||
% %
|
|
||||||
% %In order to integrate software, %in a meaningful way
|
|
||||||
% %we need to re-think the
|
|
||||||
% %FMEA concept of simply mapping a base component failure to a system level event.
|
|
||||||
% %
|
|
||||||
% SFMEA regards, in place of hardware components, the variables used by the programs to be their equivalent~\cite{procsfmea}.
|
|
||||||
% The failure modes of these variables, are that they could become erroneously over-written,
|
|
||||||
% calculated incorrectly (due to a mistake by the programmer, or a fault in the micro-processor on which it is running), or
|
|
||||||
% external influences such as
|
|
||||||
% ionising radiation causing bits to be erroneously altered.
|
|
||||||
%
|
|
||||||
%
|
|
||||||
% \paragraph{FMEA and Modularity}
|
|
||||||
% From the 1940's onwards, software has evolved from a simple procedural languages (i.e. assembly language/Fortran~\cite{f77} call return)
|
|
||||||
% to structured programming ( C~\cite{DBLP:books/ph/KernighanR88}, pascal etc) and then to object oriented models (Java C++...).
|
|
||||||
% FMEA has undergone no such evolution.
|
|
||||||
% %
|
|
||||||
% In a world where sensor systems, often including embedded software components, are brought in to
|
|
||||||
% create complex systems, FMEA still follows a rigid {\bc} {\fm} to system level error model,
|
|
||||||
% that is only suitable for simple electro mechanical systems.
|
|
||||||
%
|
|
||||||
%
|
|
||||||
%
|
|
||||||
% %
|
|
||||||
%
|
|
||||||
% %
|
|
||||||
% % MAYBE MOVE THIS TO CH3, FMEA CRITICISM
|
|
||||||
% % 30JAN2013
|
|
||||||
% %
|
|
||||||
%
|
|
||||||
% \subsection{Where FMEA is now.}
|
|
||||||
% FMEA useful tool for basic safety --- provides statistics on safety where field data impractical ---
|
|
||||||
% very good with single failure modes linked to top level events.
|
|
||||||
% FMEA has become part of the safety critical and safety certification industries.
|
|
||||||
% %
|
|
||||||
% SFMEA is in its infancy, and there are corresponding gaps in
|
|
||||||
% certification for software, EN61508~\cite{en61508}, recommends hardware redundancy architectures in conjunction
|
|
||||||
% with FMEDA for hardware: for software it recommends language constraints and quality procedures
|
|
||||||
% but no inductive fault finding technique.
|
|
||||||
% %
|
|
||||||
% FMEA has adapted from a cost saving exercise for mass produced items~\cite{bfmea,generic_automotive_fmea_6034891}, to incorporating statistical techniques
|
|
||||||
% (FMECA) to allowing for self diagnostic mitigation (FMEDA).
|
|
||||||
% %
|
|
||||||
% However, it is still based on the concept of single component failures mapped to top~level/system~failures.
|
|
||||||
% All these FMEA based methodologies have the following short comings:
|
|
||||||
% \begin{itemize}
|
|
||||||
% \item Impossible to integrate Software and hardware models,
|
|
||||||
% \item State explosion problem exacerbated by increasing complexity due to density of modern electronics,
|
|
||||||
% \item Impossibility to consider all multiple component failure modes~\cite{FMEAmultiple653556}
|
|
||||||
% \end{itemize}
|
|
@ -9,20 +9,23 @@ critical light.
|
|||||||
Chapter~\ref{sec:chap2} introduced concepts underlying FMEA, and this chapter seeks to
|
Chapter~\ref{sec:chap2} introduced concepts underlying FMEA, and this chapter seeks to
|
||||||
use these concepts to determine the drawbacks and advantages in its current usage.
|
use these concepts to determine the drawbacks and advantages in its current usage.
|
||||||
%
|
%
|
||||||
Legally mandatory FMEA for a large proportion of safety critical systems
|
Legally mandatory FMEA, for a large proportion of safety critical systems
|
||||||
in Europe and the USA, at the very least means that experienced
|
in Europe and the USA, at the very least means that experienced
|
||||||
engineers have to discuss a system at a level of detail starting
|
engineers have to discuss a system at a level of detail starting
|
||||||
at {\bc} {\fms}.
|
at {\bc} {\fms}.
|
||||||
\fmmdglossBC
|
\fmmdglossBC
|
||||||
|
\fmodegloss
|
||||||
%
|
%
|
||||||
This undoubtedly reveals dangers inherent in designs and makes
|
This undoubtedly reveals dangers inherent in designs and makes
|
||||||
our lives safer. This chapter aims to look for the deficiencies in current FMEA processes, to probe for weaknesses
|
our lives safer. This chapter aims to look for the deficiencies in current FMEA processes, to probe for weaknesses
|
||||||
and look for ways in which it could be performed better and more efficiently.
|
and look for ways in which it could be performed better and more efficiently.
|
||||||
|
|
||||||
A major problem is with the scope of examination---or required reasoning distance---to apply
|
A major problem is with the scope of
|
||||||
for FMEA analysis.
|
examination---i.e. which/how~many components should we check against a particular failure mode---to
|
||||||
|
apply for FMEA analysis.
|
||||||
|
%
|
||||||
Checking all combinations quickly leads to a state explosion problem:
|
Checking all combinations quickly leads to a state explosion problem:
|
||||||
limiting the number of components to check for against a given {\bc}
|
defining limits for the number of components to check for against a given {\bc}
|
||||||
{\fm} could address this.
|
{\fm} could address this.
|
||||||
%
|
%
|
||||||
The difficulties of integrating software
|
The difficulties of integrating software
|
||||||
@ -30,6 +33,7 @@ and hardware in FMEA failure models mean that FMEA is showing its age: designed
|
|||||||
in an era of simple electro-mechanical systems, the modern world with ubiquitous
|
in an era of simple electro-mechanical systems, the modern world with ubiquitous
|
||||||
cheap micro-controllers and processors mean that most of today’s systems are
|
cheap micro-controllers and processors mean that most of today’s systems are
|
||||||
now software/hardware hybrids.
|
now software/hardware hybrids.
|
||||||
|
\fmeagloss
|
||||||
%
|
%
|
||||||
|
|
||||||
Even analogue electronics, with the advent of surface mount and miniature components,
|
Even analogue electronics, with the advent of surface mount and miniature components,
|
||||||
@ -40,12 +44,13 @@ of the era when FMEA methodologies were invented.
|
|||||||
|
|
||||||
With FMEA it is very difficult to perform %impossibility of performing
|
With FMEA it is very difficult to perform %impossibility of performing
|
||||||
meaningful
|
meaningful
|
||||||
multiple failure analysis.
|
multiple failure analysis~\cite{FMEAmultiple653556,maikowski}.
|
||||||
The main reasons for this are that in electronics, each failure
|
The main reasons for this are that in electronics, each failure
|
||||||
can introduce a circuit topology change.
|
can introduce a circuit topology change and state explosion
|
||||||
|
means there can be extremely large numbers of double failures to check.
|
||||||
%
|
%
|
||||||
In software, in a similar vein,
|
In software, in a similar vein,
|
||||||
one failure can influence the programmatic behaviour and decisions made
|
one failure can influence the programmatic behaviour and decisions made,
|
||||||
complicating the analysis of additional failures.
|
complicating the analysis of additional failures.
|
||||||
%
|
%
|
||||||
Dual failure analysis is required by some recent European standards~\cite{en298,en230}
|
Dual failure analysis is required by some recent European standards~\cite{en298,en230}
|
||||||
@ -97,7 +102,8 @@ For instance we may have several signal input and output
|
|||||||
structures that are repeated.
|
structures that are repeated.
|
||||||
%
|
%
|
||||||
The failure mode behaviour of these repeated structures will be the same.
|
The failure mode behaviour of these repeated structures will be the same.
|
||||||
However with the {\bc} {\fm} to system level failure mode mapping
|
%
|
||||||
|
However with the {\bc} {\fm} to system level failure mode mapping paradigm of FMEA
|
||||||
work is likely to be repeated.
|
work is likely to be repeated.
|
||||||
|
|
||||||
\subsection{FMEA does not support modularity.}
|
\subsection{FMEA does not support modularity.}
|
||||||
@ -146,8 +152,8 @@ precision of analysis, and for by-products of
|
|||||||
the process such as developing diagnostic fault trees from
|
the process such as developing diagnostic fault trees from
|
||||||
FMEA analyses.
|
FMEA analyses.
|
||||||
|
|
||||||
|
\section{Comparison Complexity}
|
||||||
\section{Reasoning Distance used to measure Comparison Complexity}
|
%\section{Reasoning Distance used to measure Comparison Complexity}
|
||||||
\label{sec:reasoningdistance}
|
\label{sec:reasoningdistance}
|
||||||
Traditional FMEA cannot ensure that each failure mode of all its
|
Traditional FMEA cannot ensure that each failure mode of all its
|
||||||
components are checked against any other components in the system which
|
components are checked against any other components in the system which
|
||||||
@ -161,29 +167,58 @@ which components to check the effect of a component failure mode. % on.
|
|||||||
%
|
%
|
||||||
Typically FMEA will be performed by following the signal path
|
Typically FMEA will be performed by following the signal path
|
||||||
of the component failure mode to its system level effect,
|
of the component failure mode to its system level effect,
|
||||||
echoing fault finding reasoning.
|
echoing fault finding/diagnostic techniques~\cite{garrett}. % reasoning.
|
||||||
\fmmdglossSIGPATH
|
\fmmdglossSIGPATH
|
||||||
%
|
%
|
||||||
This is less than ideal
|
This is less than ideal
|
||||||
and it can easily miss interactions with adjacent components, that could cause
|
and it can easily miss interactions with adjacent components, that could cause
|
||||||
other system level symptoms.
|
other system level symptoms.
|
||||||
%
|
%
|
||||||
Were we to compare the reasoning distance with the theoretical maximum, the sum of all failure
|
% Were we to compare the reasoning distance with the theoretical maximum, the sum of all failure
|
||||||
modes in a system, multiplied by the number of components in it, we could arrive at a maximum
|
% modes in a system, multiplied by the number of components in it, we could arrive at a maximum
|
||||||
reasoning distance, which we can use as a comparison complexity figure.
|
% reasoning distance, which we can use as a comparison complexity figure.
|
||||||
|
If the reasoning distance is compared with the theoretical maximum, i.e.
|
||||||
|
as defined in equation~\ref{eqn:fmea_single}, this can be used as a comparison complexity figure.
|
||||||
%
|
%
|
||||||
This figure would mean we could compare the maximum number of checks (i.e. exhaustive %rigorous
|
% This figure would mean we could compare the maximum number of checks (i.e. exhaustive %rigorous
|
||||||
analysis) with the number actually performed.
|
% analysis) with the number actually performed.
|
||||||
|
This figure would mean this maximum number of checks (i.e. exhaustive %rigorous
|
||||||
|
analysis) could be compared to the number actually performed.
|
||||||
|
%
|
||||||
|
In effect a yard~stick for the efficiency, in terms of work,
|
||||||
|
for a particular analysis technique.
|
||||||
|
|
||||||
\paragraph{The ideal of exhaustive FMEA (XFMEA).}
|
\paragraph{The ideal of exhaustive FMEA (XFMEA).}
|
||||||
|
%
|
||||||
Obviously, exhaustively checking every component failure mode in a system,
|
Obviously, exhaustively checking every component failure mode in a system,
|
||||||
against all other components is the ideal for finding all possible system level failures.
|
against all other components is the ideal for finding all possible system level failures.
|
||||||
While this is impossible for all but trivial systems, we note that it should be possible
|
%
|
||||||
|
While this is impossible for all but trivial systems, it should be possible
|
||||||
for small groups of components that work together to provide a well defined function.
|
for small groups of components that work together to provide a well defined function.
|
||||||
We could term such a group a `{\fg}'. Potentially here we have a way of de-composing
|
%
|
||||||
|
A small group of components performing a well defined function
|
||||||
|
is termed a `{\fg}'.
|
||||||
|
%
|
||||||
|
Potentially, using {\fgs}, is a way of de-composing
|
||||||
the problem and reducing the $O(N^2)$ state explosion effect
|
the problem and reducing the $O(N^2)$ state explosion effect
|
||||||
associated with XFMEA. An order $N^2$ could be seen as desirable in an automated process such as a search algorithm, but here
|
associated with XFMEA.
|
||||||
it is a time consuming manual process which demands experienced and highly qualified personnel.
|
%
|
||||||
|
That is if the analysis problem can be broken into smaller steps, involving
|
||||||
|
small groups of components, XFMEA could be applied within those, without
|
||||||
|
causing a debilitating state explosion effect.
|
||||||
|
%
|
||||||
|
This property is examined in section~\ref{sec:theoreticalperfmodel}.
|
||||||
|
%
|
||||||
|
% Thus there would are many smaller reasoning distances, where
|
||||||
|
% $n_i$ are small {\fgs} of the components in a system $S$
|
||||||
|
% which has a number of components $N$.
|
||||||
|
% The reasoning distance $n_i^2$
|
||||||
|
%
|
||||||
|
A comparison complexity order, or reasoning distance, of $O(N^2)$
|
||||||
|
could be seen as desirable in an automated process such as a search algorithm,
|
||||||
|
but here it is a time consuming manual process which
|
||||||
|
demands experienced and highly qualified personnel.
|
||||||
|
%
|
||||||
It is therefore desirable to reduce this order further.
|
It is therefore desirable to reduce this order further.
|
||||||
|
|
||||||
|
|
||||||
@ -315,7 +350,8 @@ of the communications physical layer. This means the signal path will
|
|||||||
cross several hardware/software interfaces.
|
cross several hardware/software interfaces.
|
||||||
\fmmdglossSIGPATH
|
\fmmdglossSIGPATH
|
||||||
%(figure~\ref{fig:distcon}
|
%(figure~\ref{fig:distcon}
|
||||||
The failure reasoning paths for a distributed real time system, with its multiple passes of the hardware/software
|
The failure reasoning paths for a distributed real time system, % AF does not like this but I think its OK
|
||||||
|
with its multiple passes of the hardware/software
|
||||||
interface, mean traditional FMEA, for these systems,
|
interface, mean traditional FMEA, for these systems,
|
||||||
is impossible to perform.
|
is impossible to perform.
|
||||||
%
|
%
|
||||||
@ -339,22 +375,24 @@ utterly anachronistic in the distributed real time system environment.
|
|||||||
\section{FMEA ---- general criticism --- conclusion}
|
\section{FMEA ---- general criticism --- conclusion}
|
||||||
|
|
||||||
%\subsection{FMEA - General Criticism}
|
%\subsection{FMEA - General Criticism}
|
||||||
|
A summary of deficiencies in current FMEA methodologies is listed below:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item FMEA type methodologies were designed for simple electro-mechanical systems of the 1940's to 1960's.
|
%\item FMEA type methodologies were designed for simple electro-mechanical systems of the 1940's to 1960's,
|
||||||
\item Reasoning Distance - component failure to system level symptom process is undefined in regard
|
\item State explosion - impossible to perform FMEA exhaustively, %rigorously
|
||||||
to the components to check against each given component {\fm}.
|
\item Difficult to re-use previous analysis work,
|
||||||
\item State explosion - impossible to perform FMEA exhaustively. %rigorously
|
\item Very difficult to model simultaneous/multiple failures,
|
||||||
\item Difficult to re-use previous analysis work.
|
\item Software and hardware models are separate (if the software is modelled at all) meaning the software interface may not be correctly modelled,
|
||||||
\item Very difficult to model simultaneous failures.
|
%\item reasoning distance -- component failure to system level symptom process is undefined in regard
|
||||||
\item Software and hardware models are separate (if the software is modelled at all).
|
%to the components to check against each given component {\fm},
|
||||||
|
\item FMEA methodologies are undefined in regard to which components to check against given failure modes,
|
||||||
|
%
|
||||||
\item Distributed real time systems are very difficult to analyse with FMEA because they typically involve many hardware/software interfaces.
|
\item Distributed real time systems are very difficult to analyse with FMEA because they typically involve many hardware/software interfaces.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
Traditional forms of FMEA are no longer % fit for purpose!
|
Traditional forms of FMEA are no longer % fit for purpose!
|
||||||
of meaningful use for modern systems incorporating programmatic elements.
|
of meaningful use for complex modern systems especially those incorporating programmatic elements.
|
||||||
They were designed to analyse simple electro-mechanical systems
|
They were designed to analyse simple electro-mechanical systems
|
||||||
and even the commonplace large integrated analogue circuits (that are physically small), are
|
and even common place large analogue circuits (that are usually physically small), are
|
||||||
getting too complicated for meaningful analysis using FMEA.
|
getting too complicated for meaningful analysis using FMEA.
|
||||||
%
|
%
|
||||||
%
|
%
|
||||||
@ -461,30 +499,29 @@ FMEA has become part of the safety critical and safety certification industries.
|
|||||||
%
|
%
|
||||||
SFMEA is in its infancy, and there are corresponding gaps in
|
SFMEA is in its infancy, and there are corresponding gaps in
|
||||||
certification for software, EN61508~\cite{en61508} a modern standard based
|
certification for software, EN61508~\cite{en61508} a modern standard based
|
||||||
on a modern variant of FMEA, recommends hardware redundancy architectures in conjunction
|
on a modern variant of FMEA, FMEDA, recommends hardware redundancy architectures in conjunction
|
||||||
with FMEDA for hardware: for software it recommends language constraints and quality procedures
|
with FMEDA for hardware: for software it recommends language constraints, software life cycle control, testing regimes and quality procedures
|
||||||
but no inductive fault finding technique.
|
but no inductive fault finding technique.
|
||||||
%
|
%
|
||||||
FMEA has adapted from a cost saving exercise for mass produced
|
FMEA has adapted from a cost saving exercise for mass produced
|
||||||
items~\cite{bfmea,generic_automotive_fmea_6034891}, to incorporating statistical techniques
|
items~\cite{bfmea,generic_automotive_fmea_6034891}, to incorporating statistical techniques
|
||||||
(FMECA) to allowing for self diagnostic mitigation (FMEDA).
|
(FMECA) to allowing for self diagnostic mitigation (FMEDA).
|
||||||
%
|
%
|
||||||
However, it is still based on the concept of single component failures mapped to top~level/system~failures.
|
However, it is still based on the concept of single component failures mapped to top~level/system~failures,
|
||||||
All these FMEA based methodologies have the following short comings:
|
with a one step analysis stage.
|
||||||
\begin{itemize}
|
% All these FMEA based methodologies have the following short comings:
|
||||||
\item Impossible to integrate Software and hardware models,
|
% \begin{itemize}
|
||||||
\item State explosion problem exacerbated by increasing complexity due to density of modern electronics,
|
% \item Impossible to integrate Software and hardware models,
|
||||||
\item Impossible to consider all multiple component failure modes~\cite{FMEAmultiple653556}
|
% \item State explosion problem exacerbated by increasing complexity due to density of modern electronics,
|
||||||
\end{itemize}
|
% \item Impossible to consider all multiple component failure modes~\cite{FMEAmultiple653556}
|
||||||
|
% \end{itemize}
|
||||||
|
%
|
||||||
|
|
||||||
%\subsection{FMEA - Better Methodology - Wish List}
|
%\subsection{FMEA - Better Methodology - Wish List}
|
||||||
|
%
|
||||||
|
%
|
||||||
\subsection{FMEA - Better Methodology - Wish List}
|
\subsection{FMEA - Better Methodology - Wish List}
|
||||||
|
%
|
||||||
We now form a wish list, stating the features that we would want
|
A wish list is presented, stating the features that should exist
|
||||||
in an improved FMEA methodology,
|
in an improved FMEA methodology,
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Must be able to analyse hybrid software/hardware systems,
|
\item Must be able to analyse hybrid software/hardware systems,
|
||||||
@ -497,8 +534,10 @@ in an improved FMEA methodology,
|
|||||||
\item modular --- i.e. usable in a distributed system.
|
\item modular --- i.e. usable in a distributed system.
|
||||||
% \item
|
% \item
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
%
|
||||||
%FMEDA is a modern extension of FMEA, in that it will allow for
|
%FMEDA is a modern extension of FMEA, in that it will allow for
|
||||||
%self checking features, and provides detailed recommendations for computer/software architecture,
|
%self checking features, and provides detailed recommendations for computer/software architecture,
|
||||||
%but
|
%but
|
||||||
|
%
|
||||||
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
|
|
||||||
|
@ -1599,10 +1599,10 @@ We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}.
|
|||||||
An analysis report is generated for each stage in the FMMD % {\fg} to {\dc}
|
An analysis report is generated for each stage in the FMMD % {\fg} to {\dc}
|
||||||
process. %\footnote
|
process. %\footnote
|
||||||
%
|
%
|
||||||
The UML model in figure~\ref{fig:cfg} describes a hierarchical structure similar to that of a file system with directories,
|
The UML model in figure~\ref{fig:cfg} describes a hierarchical structure analogous to that of a file system with directories,
|
||||||
but instead of directory and file nodes, there are closely linked {\fgs} and {\dcs} pairs, that perform a similar structural functions.
|
but instead of directory and file nodes, there are closely linked {\fg} and {\dc} pairs, that perform a similar structural function.
|
||||||
%
|
%
|
||||||
The NONINVAMP example is shown as an instance
|
To demonstrate the hierarchical nature of the UML model for FMMD, the NONINVAMP example is presented as an instance
|
||||||
diagram below (see figure~\ref{fig:instanceNONINVAMP}).
|
diagram below (see figure~\ref{fig:instanceNONINVAMP}).
|
||||||
%
|
%
|
||||||
By tracing the component failure modes to symptoms
|
By tracing the component failure modes to symptoms
|
||||||
|
@ -496,7 +496,7 @@ are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref
|
|||||||
\centering
|
\centering
|
||||||
\includegraphics[width=400pt,keepaspectratio=true]{./CH8_Conclusion/master_uml_further_work.png}
|
\includegraphics[width=400pt,keepaspectratio=true]{./CH8_Conclusion/master_uml_further_work.png}
|
||||||
% cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
|
% cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
|
||||||
\caption{FMMD UML diagram, incorporating Environmental, Operational State and Inhibit gates}
|
\caption{FMMD UML diagram extended for potential compatibility with FTA: incorporating Environmental, Operational State and Inhibit gates}
|
||||||
\label{fig:cfg2}
|
\label{fig:cfg2}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
|
@ -1,114 +1,118 @@
|
|||||||
%\renewcommand{\baselinestretch}{1.15}
|
%\renewcommand{\baselinestretch}{1.15}
|
||||||
\chapter*{Colophon}
|
\chapter*{Colophon}
|
||||||
|
|
||||||
% In short ``Thanks every body''!
|
In short ``Thanks every body''!
|
||||||
% %
|
%
|
||||||
% \\
|
\\
|
||||||
% \\
|
\\
|
||||||
% %
|
%
|
||||||
% Completing my PhD %degree
|
Completing my PhD %degree
|
||||||
% is the most intellectually challenging %% FUCK OFF ZERNIKE POLYNOMIALS WERE MORE DIFFICULT --- and actually useful unlike set theory
|
is the most intellectually challenging %% FUCK OFF ZERNIKE POLYNOMIALS WERE MORE DIFFICULT --- and actually useful unlike set theory
|
||||||
% activity of my first 52 years of my life! %% SET THEORY IS A LOAD OF BOLLOCKS
|
activity of my first 52 years of my life! %% SET THEORY IS A LOAD OF BOLLOCKS
|
||||||
% %
|
%
|
||||||
% The best and worst moments of this journey
|
%The best and worst moments of this journey
|
||||||
% have been shared with many people.
|
%have been shared with many people.
|
||||||
% %
|
%
|
||||||
% It has been a great privilege to spend several years
|
It has been a great privilege to spend several years
|
||||||
% visiting the Mathematics and Engineering departments of
|
visiting the Mathematics and Engineering departments of
|
||||||
% the University of Brighton, pushing me forward in clarity of self-expression,
|
the University of Brighton, pushing me forward in clarity of self-expression,
|
||||||
% precision through mathematics, critical assessment and carefully crafted English:
|
precision through mathematics, critical assessment and carefully crafted English:
|
||||||
% its members will always remain dear to me, and a strong influence.
|
its members will always remain dear to me. %, and I am sure, a strong influence
|
||||||
% %
|
%on work I produce after this.
|
||||||
% %%%% IS THIS BIT A BIT MAD???? YES! 27AUG2013
|
%
|
||||||
% % % % Like an army recruits training Sergeant Major I found them
|
%%%% IS THIS BIT A BIT MAD???? YES! 27AUG2013
|
||||||
% % % % hard task masters at first, and then, as with realising the rationale behind training and
|
% % % Like an army recruits training Sergeant Major I found them
|
||||||
% % % % {\em even} parade drill, respected and grew to like them.
|
% % % hard task masters at first, and then, as with realising the rationale behind training and
|
||||||
% % % % %
|
% % % {\em even} parade drill, respected and grew to like them.
|
||||||
% %
|
% % % %
|
||||||
% My first debt of gratitude must go to my supervisors,
|
%
|
||||||
% Dr. A. Fish,
|
My first debt of gratitude must go to my supervisors,
|
||||||
% Dr. C Garret and %% TOP BLOKE
|
Dr. A. Fish,
|
||||||
% %Dr. C Garret, %% TOP BLOKE
|
Dr. C Garret and %% TOP BLOKE
|
||||||
% Professor J. Howse. %% JAVALA LAT HUND
|
%Dr. C Garret, %% TOP BLOKE
|
||||||
% %Dr. A. Fish. %% JAVALA LAT HUND
|
Professor J. Howse. %% LAT HUND
|
||||||
% %
|
%Dr. A. Fish. %% JAVALA LAT HUND
|
||||||
% They patiently provided the guidance,
|
%
|
||||||
% encouragement and advice necessary for me to proceed through the
|
They patiently provided the guidance,
|
||||||
% research, consolidation and write-up phases of the PhD program,
|
encouragement and advice necessary for me to proceed through the
|
||||||
% to prepare and present three papers to conferences~\cite{syssafe2011,syssafe2012,Clark_fastzone}
|
research, consolidation and write-up phases of the PhD program,
|
||||||
% and to complete and submit this thesis.
|
to prepare and present three papers to conferences~\cite{syssafe2011,syssafe2012,Clark_fastzone}
|
||||||
% \\
|
and to complete and submit this thesis.
|
||||||
% \\
|
\\
|
||||||
% %
|
\\
|
||||||
% %
|
%
|
||||||
% I owe a debt of thanks to Dr J. flower, my MSc project supervisor,
|
%
|
||||||
% who explained that the chapter in my project documentation postulating a modular form of
|
I owe a debt of thanks to Dr J. flower, my MSc project supervisor,
|
||||||
% FMEA---which had %obvious
|
who explained that the chapter in my project documentation postulating a modular form of
|
||||||
% potential for making the process %FMEA
|
FMEA---which had %obvious
|
||||||
% more efficient---was a concept worthy of being developed for a PhD and assisting me
|
potential for making the process %FMEA
|
||||||
% to present the chapter as %submit this as
|
more efficient---was a concept worthy of being developed for a PhD and assisting me
|
||||||
% a conference paper~\cite{Clark200519}.
|
to present the chapter as %submit this as
|
||||||
% %
|
a conference paper~\cite{Clark200519}.
|
||||||
% Further I thank her for encouraging me to apply for the PhD. %% PITY SHE DID NOT STAY ON AS MY PHD SUPERVISOR
|
%
|
||||||
% %
|
Further I thank her for encouraging me to apply for the PhD. %% PITY SHE DID NOT STAY ON AS MY PHD SUPERVISOR
|
||||||
% \\
|
%
|
||||||
% \\
|
\\
|
||||||
% %
|
\\
|
||||||
% I am deeply thankful to the directors of {\etc} not only for
|
%
|
||||||
% funding this course, but providing training and work experience in the
|
I am deeply thankful to the directors of {\etc} not only for
|
||||||
% field of safety critical engineering, and giving me Friday
|
funding this course, but providing training and work experience in the
|
||||||
% afternoons to pursue my studies.
|
field of safety critical engineering, and giving me Friday
|
||||||
% %
|
afternoons to pursue my studies.
|
||||||
% At Energy~Technology~Control, the following people gave encouragement, and
|
%
|
||||||
% validated the concepts for the `modular~FMEA' that I was developing, Martin~Thirsk, Colin~Talmay,
|
At Energy~Technology~Control, the following people gave encouragement, and
|
||||||
% Darren~Legge and Hazel~Anderson.
|
validated the concepts for the `modular~FMEA' that I was developing,
|
||||||
% %
|
Martin~Thirsk,
|
||||||
% These Engineers, whose whole careers
|
Colin~Talmay,
|
||||||
% have been focused on the safety critical electronic/computing area,
|
Darren~Legge and
|
||||||
% gave valuable time to look at and comment on my FMMD proposals.
|
Hazel~Anderson.
|
||||||
% %
|
%
|
||||||
% Their comments gave me confidence that the methodology I was developing had
|
These Engineers, whose whole careers
|
||||||
% %was not only an academic exercise but had
|
have been focused on the safety critical electronic/computing area,
|
||||||
% potential practical
|
gave valuable time to look at and comment on my FMMD proposals.
|
||||||
% applications and benefits.
|
%
|
||||||
% %
|
Their comments gave me confidence that the methodology I was developing had
|
||||||
% The environment and context of the work at {\etc}
|
%was not only an academic exercise but had
|
||||||
% was very useful for clarifying concepts relating to FMEA and
|
potential practical
|
||||||
% safety; at least once a week there is a new practical case study arising
|
applications and benefits.
|
||||||
% and being discussed, be it, say, the observability of the effect of failures in an
|
%
|
||||||
% traditional amplifier configuration,
|
The environment and context of the work at {\etc}
|
||||||
% or how a particular sensor could fail.
|
was very useful for clarifying concepts relating to FMEA and
|
||||||
% %
|
safety; at least once a week there is a new practical case study arising
|
||||||
% The field of industrial burner control, is highly regulated and
|
and being discussed, be it, say, the observability of the effect of failures in an
|
||||||
% is rich with practical examples of safety measures built into
|
traditional amplifier configuration,
|
||||||
% hybrid digital/electronic systems.
|
or how a particular sensor could fail.
|
||||||
% %
|
%
|
||||||
% This has given me many opportunities to % has been % be
|
The field of industrial burner control, is highly regulated and
|
||||||
% apply the new methodology against `real~world' problems.
|
is rich with practical examples of safety measures built into
|
||||||
% %
|
hybrid digital/electronic systems.
|
||||||
% %and thus its
|
%
|
||||||
% %theoretical aspects have been often
|
This has given me many opportunities to % has been % be
|
||||||
% %sounded out against `real~world' problems.
|
apply the new methodology against `real~world' problems.
|
||||||
% %
|
%
|
||||||
% These real~world failure scenarios and their proposed solutions, were often detailed in
|
%and thus its
|
||||||
% requirements and design documentation, submitted in support of
|
%theoretical aspects have been often
|
||||||
% safety accreditation.
|
%sounded out against `real~world' problems.
|
||||||
% %
|
%
|
||||||
% I was glad to be tasked to produce many of these documents.
|
These real~world failure scenarios and their proposed solutions, were often detailed in
|
||||||
% %
|
requirements and design documentation, submitted in support of
|
||||||
% Again I thank {\etc}, for giving me
|
safety accreditation.
|
||||||
% these parallel tasks, which aided my studies.
|
%
|
||||||
% \\
|
I was glad to be tasked to produce many of these documents.
|
||||||
% \\
|
%
|
||||||
% %
|
Again I thank {\etc}, for giving me
|
||||||
% %
|
these parallel tasks, which aided my studies.
|
||||||
% I wish to thank my parents, Jennifer and Richard Clark.
|
\\
|
||||||
% % MY MUM for proof reading alot!
|
\\
|
||||||
% I hope that this work makes you proud.
|
%
|
||||||
% %
|
%
|
||||||
% \\
|
I wish to thank my parents, Jennifer and Richard Clark.
|
||||||
% \\
|
% MY MUM for proof reading alot!
|
||||||
|
I hope that this work makes you proud.
|
||||||
|
%
|
||||||
|
\\
|
||||||
|
\\
|
||||||
|
|
||||||
%\vspace{3cm}
|
\vspace{3cm}
|
||||||
Typeset in \LaTeX \today.
|
Typeset in \LaTeX \today.
|
||||||
\renewcommand{\baselinestretch}{1.5}
|
\renewcommand{\baselinestretch}{1.5}
|
||||||
|
Loading…
Reference in New Issue
Block a user