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

..

Browse Source
This commit is contained in:
Robin Clark 2013-06-13 20:46:27 +01:00
parent 61f2146afa
commit 08a180409d
2 changed files with 55 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
submission_thesis/CH8_Conclusion/copy.tex
View File

@ -1,16 +1,16 @@
\label{sec:chap8}
In this study we have examined the processes and state of the art of the four main FMEA variants.
This study has examined the processes and state of the art of the four main FMEA variants.
%
We have exposed shortcomings in these methodologies, which can be summed up as an inability to
It has exposed shortcomings in these methodologies, which can be summed up as an inability to
model hybrid software and hardware systems in a satisfactory manner, a problem with state explosion
and difficulty of re-use of analysis because there is no support for modularity.
%
The FMECA and FMEDA variants also suffer from embedding subjective and objective assessments of failure modes.
%
A modularised FMEA---Failure Mode Modular De-composition (FMMD)---was proposed.
A modularised FMEA---Failure Mode Modular De-composition (FMMD)---had been proposed.
%
This modularised version was supported by the work already established in the
This modularised version had been supported by the work already established in the
{\fms} of {\bc} in the literature~\cite{fmd91,mil1991,en298,en230}.
%
A selection of electronic examples was analysed using FMMD
@ -32,10 +32,10 @@ re-used not only in the circuit under analysis but potentially in different and
Traditional FMEA methods have been applied to software, but analysis has always to be separate from
the electronic FMEA~\cite{sfmeaa,sfmea}. %, and while modular kept strictly to a bottom-up approach.
%
Using established concepts from contract programming~\cite{dbcbe} we extended FMMD to analyse software,
Using established concepts from contract programming~\cite{dbcbe} FMMD was extended to analyse software,
which allows us to neatly solve the software hardware interfacing problem~\cite{sfmeainterface}.
%
Two examples of software and hardware hybrids were analysed as integrated FMMD models
Two examples of mixed software and hardware systems were analysed as integrated FMMD models
as a proof of concept. The first example in chapter~\ref{sec:chap6}, was
presented to the System Safety IET conference in 2012~\cite{syssafe2012}.
%
@ -51,10 +51,49 @@ the FMMD process strictly enforced this throughout the hierarchy of a model.
%
Finally the FMMD process was described algorithmically using set theory in appendix~\ref{sec:algorithmfmmd}.%{app:alg}.
In conclusion then a new method of failure analysis has been devised which improves on established techniques in the following ways:
% \begin{itemize}
% \item Must be able to analyse hybrid software/hardware systems,
% \item no state explosion (which has rendered exhaustive analysis impractical),
% \item exhaustive checking at a modular level, %(total failure coverage within {\fgs} all interacting component and failure modes checked),
% \item traceable reasoning system models,% to aid repeatability and checking,
% \item re-usable i.e. it should be possible to re-use analysis,
% \item possibility to analyse simultaneous/multiple failures,
% \item modular --- i.e. usable in a distributed system.
% % \item
% \end{itemize}
\begin{itemize}
\item FMMD provides the means to create failure models that integrate software and hardware,
\item State explosion related to exhaustive FMEA solved,
\item Modular approach means analysis work is re-usable,
\item FMMD encourages
\item Distributed systems, and smart instruments, can now be analysed and assessed,
\item Multiple failures can be analysed (without an undue state explosion cost).
\end{itemize}
Under the following assumptions and constraints:
\begin{itemize}
\item Failure modes are available for all {\bcs},
\item Analysts are capable of finding suitable {\fgs} from electronic schematics,
\item Software is hierarchical and its elements (functions) can be modelled using contract programming,
%\item
\end{itemize}
Whilst investigating FMMD a number of further areas for research revealed themselves.
These are explained below.
%\section{Conclusion}
% It is the authors belief that the practise of FMEA would be improved by taking a modular approach
% and that it is necessary that software and hardware should be included in the same failure mode models.
% %
% The proposed methodology, FMMD, provides the means to do this, and it is the authors hope that this
% or a variant thereof is taken up and used to improve system safety.
\section{Further Work}
This section describes areas that the study has revealed where the FMMD methodology may be extended or improved.
%This section describes areas that the study has revealed where the FMMD methodology may be extended or improved.
\section{Statistics: From base component failure modes to System level events/failures.}
@ -90,7 +129,7 @@ failure statistics, we calculate the reliability of this circuit.
\paragraph{Resistor FIT Calculations}
The formula for given in MIL-HDBK-217F\cite{mil1991}[9.2] for a generic fixed film non-power resistor
The formula given in MIL-HDBK-217F\cite{mil1991}[9.2] for a generic fixed film non-power resistor
is reproduced in equation \ref{resistorfit}. The meanings
and values assigned to its co-efficients are described in table \ref{tab:resistor}.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular
@ -238,7 +277,7 @@ The next analysis phase looks at how the circuit will behave under double simult
conditions.
\subsection{Pt100 Example: Double Failures and statistical data}
\paragraph{Pt100 Example: Double Failures and statistical data}
Because we can perform double simultaneous failure analysis under FMMD
we can also apply failure rate statistics to double failures.
%
@ -295,7 +334,7 @@ If we require FMMD to produce full FTA diagrams, we need to add these attributes
\paragraph{Environment, operational states and inhibit gates: additions to the UML model.}
FTA, in addition to using symbols borrowed from digital logic introduces threee new symbols to
FTA, in addition to using symbols borrowed from digital logic introduces three new symbols to
model environmental, operational state and inhibit gates; we discuss here how these can be incorporated into
the FMMD model.
@ -398,7 +437,7 @@ are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref
\clearpage
\section{Retrospective Failure Mode analysis and FMMD}
\subsection{Retrospective Failure Mode analysis and FMMD}
The reasons for applying retrospective failure mode analysis could be approving previously un-assessed
systems to a safety standard, or to determine the failure mode behaviour of an instrument used in
@ -409,7 +448,8 @@ its `bottom-up~work~flow' it
can reveal previously undetected system failure modes.
%
This is because the analyst
is forced to deal with a component failure modes by the FMMD process.
is forced to deal with all component failure modes by the FMMD process, and
all failure modes of {\dcs}.
%
FMMD requires that all failure modes of components in a {\fg} are resolved to
a symptom in the resulting {\dc}.
@ -478,7 +518,7 @@ is examined in section~\ref{sec:fta}.
\section{Objective and Subjective Reasoning stages}
%Opportunity for formal definitions and perhaps an interface or process for achieving it....
The act of applying failure mode effects analysis, in terms of cause and effect is viewed from
and engineering perspective. This is the realm of the objective.
an engineering perspective. This is the realm of the objective.
The executive decisions about deploying systems are in the domain of management and politics.
%
The dangers, or potential negative effects of a safety critical system depend not only on the system itself,
@ -487,7 +527,7 @@ and other human factors such as the training level of operatives, psychological
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 can be derived from the accident report on the 1979 Three Mile Island
An example of objective and subjective factors is demonstrated in the accident report on the 1979 Three Mile Island
nuclear accident~\cite{safeware}[App.D]. Here, a vent valve for the primary reactor coolant (pressurised water) became stuck open.
This condition causes an objectively derived failure mode, temporary loss of coolant due to a stuck valve.
%
@ -517,10 +557,3 @@ EN61508 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.
\section{Conclusion}
It is the authors belief that the practise of FMEA would be improved by taking a modular approach
and that it is necessary that software and hardware should be included in the same failure mode models.
%
The proposed methodology, FMMD, provides the means to do this, and it is the authors hope that this
or a variant thereof is taken up and used to improve system safety.

2
submission_thesis/appendixes/detailed_analysis.tex
View File

@ -826,5 +826,5 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
\end{tabular}
\end{table}
}
\clearpage
\clearpage/pr