Robin_PHD/submission_thesis/CH8_Conclusion/copy.tex

\label{sec:chap8}
%
\fmeagloss
%
This study has examined the %processes and state of the art of the 
four main FMEA variants.
%
\fmmdglossSTATEEX
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.
%
This thesis proposes modularised FMEA---Failure Mode Modular De-composition (FMMD)---to overcome some of these problems.
%
This modularised version had been supported by the work already established by the definition of
{\fms} for {\bcs} in the literature~\cite{fmd91,mil1991,en298,en230}.
%
Specific electronic examples were analysed using FMMD
to test circuit %which deliberately introduced varying circuit
topologies with conventional and circular signal paths
and mixed digital and analogue designs.
%
\fmmdglossSTATEEX
For all these examples, the state explosion related performance was compared with that of
traditional FMEA. 
%
In all cases there was a performance gain, 
that is to say that for all but trivial cases, 
the number of manual analysis operations to perform
was significantly reduced. 
\fmmdglossRD
%
Not only this, but the analysis naturally provided modules which could be re-used, 
both in the same circuit and other circuits
%re-used not only in the circuit under analysis but potentially in different 
and potentially future projects as well.

Traditional FMEA methods have been applied to software, but analysis has always been performed separately from 
the HFMEA~\cite{sfmeaa,sfmea}. %, and while modular kept strictly to a bottom-up approach.
\fmmdglossHFMEA
%
Using established concepts from contract programming~\cite{dbcbe}  FMMD was extended to analyse software,
which facilitated a solution to the software/hardware interfacing problem~\cite{sfmeainterface}.
%
Two examples of hybrid software/hardware systems were analysed as integrated FMMD models
as proof of concept. The first example in chapter~\ref{sec:chap6}, was
presented to the System Safety IET conference in 2012~\cite{syssafe2012}.
%
Chapter~\ref{sec:chap7} viewed FMMD from a formal perspective and examined problems and constraints
necessary to perform FMEA and FMMD.
%
Theoretical performance models were developed (see section~\ref{sec:theoreticalperfmodel}) which showed that with increasing modularisation
the number of manual checks to perform for analysis fell, which was validated by examining the reasoning distance performance of
the examples from chapter~\ref{sec:chap5}. % in this regard.
% 
A unitary state failure mode concept was developed (see section~\ref{sec:unitarystate}), and it was shown that
the FMMD process naturally enforced this throughout the hierarchy of a model.
\fmmdglossMUTEX
%
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}
\fmmdglossSTATEEX
\begin{itemize}
 \item FMMD provides the means to determine failure models that integrate software and hardware,
 \item the state explosion related to exhaustive FMEA reduced from a polynomial to logarithmic order,
 \item a modular approach to FMEA means that 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}
%
These benefits require 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 Functional software and its elements (hardware interfaces, data and functions) can be modelled using contract programming.
 %\item 
\end{itemize}
\fmmdglossRD


Whilst investigating FMMD a number of further areas for research revealed themselves. 
These are presented 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.
 \subsection{How traditional FMEA reports can be derived from an FMMD model.}
%
\fmmdgloss
\fmeagloss
An FMMD model has a data structure (described by UML diagrams, see figure~\ref{fig:cfg}) and by traversing an FMMD hierarchy,
system level failures can be mapped back to {\bc} {\fms} (or combinations thereof).
%
Because these mappings can be determined, reports in the traditional FMEA format (i.e. {\bc}~{\fm}~$\mapsto$~{system failure}) can be produced.
%
With the addition of {\bc} {\fm} statistics~\cite{mil1991} reliability predictions for system level failures can be provided.
%
The Pt100 example is revisited for this purpose and analysed for single and double failures, with statistics for {\bcs}
taken from MIL1991 %~\cite{mil1991}, 
in section~\ref{sec:bcstats}.
%
With an FMMD failure mode model a top down perspective is possible.
%
Each system level failure can have a causation tree produced for it, tracing back
to all {\bc} {\fms}.
%
This is very closely related to the structure of FTA (top down) failure causation graphs.
%
The possibility of automatically producing FTA diagrams from FMMD models 
is examined in section~\ref{sec:fta}.
%
\fmmdglossRD

\subsection{Statistics: From base component failure modes to System level events/failures.}
\label{sec:bcstats}
Knowing the statistical likelihoods of a components failing can give a good indication
of the reliability of a system, or in the case of dangerous failures, the Safety Integrity Level 
of a system.
%
EN61508~\cite{en61508} requires that statistical data is available and used for all component failure modes
analysed by FMEDA.
%
FMMD, as a bottom up methodology can use component failure mode statistical data, and incorporate it
into its hierarchical model.
%By way of example, the Pt100 analysis %example 
%from section~\{sec:pt100} has been used to demonstrate this.
Because an FMMD model can be used to generate an FMEA report, 
with additional {\bc} failure mode statistics
an FMEDA report can be produced.
%
FMMD has been applied with component failure statistics to the Pt100 example in appendix~\ref{detailed:Pt100stats}.
%
This demonstrates FIT values being obtained for single and doubly sourced system failure modes
in a way that is compatible with FMEDA/EN61508.


%we can %therefore 
%use FMMD to produce an FMEDA report.
\frategloss
\fmmdglossFIT


\subsection{Composition of {\fgs}.}

%The choice of components for a {\fg} are that they are components that
%work together to perform a pre-defined function.work together to perform a pre-defined function.
The members of a {\fg} are chosen to be components that work together to perform a specific function.
%
The  choice of {\fg} membership is made by the analyst.
%
The act of choosing components to form a {\fg}
raises questions about the circuit under investigation.
%
Ideally {\fgs} will be able to act as standalone modules.
%
%That is they should perform their function in the context of teir use, but
%
An inverting amplifier configuration, or a low pass filter are good examples of these:
they have clear inputs and outputs, and are resilient to what they are connected to at
the output (in electronics terms they have low output impedance).
%
In defining members for {\fgs} the analyst is forced to consider the interfaces between elements
of circuitry to identify modules. 
%
The aim is to prevent undue influence on modules identified from circuitry
they are/may be connected to.
%
Consider the resistor capacitor low pass stage first looked at in example~\ref{sec:lp}. %\label{sec:lp}
%
This circuit element, while applying a filtering effect, has a high output impedance.
%
With a simple OpAmp buffer amplifier on its output stage, it becomes an effective low impedance output standalone module\footnote{A well behaved, or ideal electronics `module' will
have a high impedance input (i.e. it will not overload and affect any driving stages) and a low output impedance (i.e. it will drive an electrical load at the output without being affected its-self).}.
%
The resistor/capacitor low pass stage and the OpAmp
are good candidates therefore for being considered as a standalone module, and thus a {\fg}.

However, different analysts may choose different {\fgs}
when analysing the same circuit.
%
This means that {\fgs} are not guaranteed to be unique.
%
This apparent anomaly  is explored in the examples~\ref{sec:invamp},~\ref{sec:bubba} where different 
structures of the FMMD hierarchy were used to analyse the same circuitry.
%
The same system level failure modes were obtained, but the more de-composed examples
offered better performance in terms of comparison complexity.
%%
Potential problems of side effects and {\fg} membership choices are discussed in section~\ref{subsec:choosingfgs}.
%
Further work may be required to apply justification for the choice of  membership in {\fgs}.
%
For software already written this problem does not exist as  the choice of membership has already been made by the programmer.

%
\subsection{Deriving FTA diagrams from FMMD models}
\label{sec:fta}
\fmmdglossFTA
%
Fault Tree Analysis (FTA)~\cite{ftahistory} is a top down methodology that
draws a fault tree---or top down fault causation diagram---for each given top-level
failure. 
%
With an FMMD model, all the causes of system failures
down can be traced to the base component level.
%
The DAG produced from an FMMD analysis could be considered %%% THANKS ANDREW !
as a unification of all FTA trees of a system.
%
This would in fact,  be enough to create all fault causation trees, but FTA introduces 
concepts of operational and environmental states, and inhibit gates.
%
The FMEA philosophy in relation to these three concepts are to assume that they are worst cases, that they
{\em may} occur, 
and determine what system failures may arise. 
%
The FTA perspective is that some safety can be built in
by preventing certain things happening (inhibit gates), and by considering 
different behaviour due to environmental or operational states~\cite{nucfta,nasafta}.
%
If FMMD is required to produce full FTA diagrams, these 
attributes must be added to the FMMD UML model\footnote{Top down failure mode models, such as FTA, are additionally 
useful in guiding diagnostic analysis.}.
%
\fmmdglossINHIBIT
\fmmdglossFTA
%
%%
%% Here could describe how XOR not OR is implemented and how AND
%% only works due to failure symptoms being derived from multiple failures.
%% This is a tangent and probably detracts from the main flow.
%% 02SEP2013
%%
\paragraph{Environment, operational states and inhibit gates: additions to the UML model.}
%
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 is discussed below.
%
A  system will be expected to perform in a given environment.
%
Environment in the context of this study
means external influences under which the system could be expected to work. % under.
%
A typical data sheet for an electrical component will give 
a working temperature range: %, for instance.
mechanical components could  be specified for stress and loading limits.
It is unusual to have failure modes  described in product literature, although
for complicated components with firmware, errata documents~\cite{pic18f25k80erratta} are sometimes produced.

Systems may have distinct operational states. For instance, a safety critical controller
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until 
authorised human intervention takes place.
A safety critical circuit may have a self test mode which could be operated externally:
a micro-processor may have a SLEEP mode etc.
%
To make FMMD compatible with FTA operational states and environmental conditions should %can %must 
be factored into the UML model.
%
An undesired condition may occur where it could be necessary to inhibit some action of the system.
This is rather like a logical guard criterion. For instance in the gas burner standard EN298 it
states that a flame detector must confirm that a pilot flame has been established before the main burner fuel can be applied.
In FTA terms this would be an `inhibit' condition on the main fuel, i.e. PILOT\_NOT\_CONFIRMED.
\fmmdglossFTA
The nature of these three attributes is examined and decisions are made as how they should fit into the UML
model for FMMD developed in section~\ref{sec:fmmd_uml}.

\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
levels of electrical interference, high voltage contamination on supply
lines, radiation levels etc.
%
Environmental influences will affect specific components in specific ways\footnote{A good example of a part 
affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181}
which  typically starts having performance problems at {60 \oc} and above. 
Most electrical components are robust to temperature variations and 
would not normally require special environmental consideration/attributes.}.
Environmental analysis is thus applicable to components.
%
Environmental influences, such as over-stress due to voltage
can be eliminated by down-rating components as discussed in section~\ref{sec:determine_fms}.
%
With given environmental constraints, it is therefore possible to eliminate some failure modes from the model.
\fmmdglossFTA

\paragraph{Operational states.}
%
Within the field of safety critical engineering, 
elements are often encountered that include test or self-test facilities. 
%
Degraded performance
(such as only performing certain functions in an emergency) and lockout/emergency conditions
are also common conditions that are considered.
%
These can be broadly termed operational states. %, and apply to the 
%functional groups.
%
The UML class most appropriate to hold a relationship
to operational states must be chosen.
%
Consider for instance an electrical circuit that has a TEST line.
When the TEST line is activated, it supplies a test signal
which will validate the circuit. This circuit will have two operational states,
NORMAL and TEST mode.
%
It seems more appropriate to apply the operational states to {\fgs}
which %
%Functional groupings 
by definition implement functionality, or purpose.
On this basis operational states are associated with {\fgs}.
%therefore are the best objects to model
%operational states.% with.

\paragraph{Inhibit Conditions.}
\fmmdglossINHIBIT
Inhibit conditions and the symbols used for them are described in~\cite{nasafta}[p.40]. % is required. %desired.
%
Some failure modes may only be active given specific environmental conditions
or when other failures are already active.
%
To model this, an `inhibit' class has been added.
%
This is an optional attribute of 
a failure mode. 
%
This inhibit class can be triggered
on a combination of environmental or failure modes.
%
In the UML diagram, this is therefore, linked  with 
both environmental conditions and failure modes.
%
%
%
\fmmdglossFTA

\paragraph{UML Diagram Additional Objects.}
The additional objects System, Environment, Inhibit and Operational States
are added to  UML diagram in figure \ref{fig:cfg} are represented in figure \ref{fig:cfg2}.
%
\label{completeumlfurtherwork}
%
\begin{figure}[h]
 \centering
 \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
 \caption{FMMD UML diagram extended for potential compatibility with FTA: incorporating Environmental, Operational State and Inhibit gates}
 \label{fig:cfg2}
\end{figure}

\clearpage

\subsection{Retrospective failure mode analysis and FMMD}
\fmmdgloss
The reasons for applying retrospective failure mode analysis could be:
\begin{itemize}
 %\item approving previously un-assessed systems to a safety standard,
 \item to re-visit a safety analysis after a small hardware or software change,
 \item upon discovery of a new {\bc} {\fm}---or in software---a new contract programming requirement,
 \item to determine  the failure mode behaviour of an previously un-assessed sub-system/instrument used in safety critical verification.
\end{itemize}
  % verification.
%
FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with
its `bottom-up~work~flow' it
can reveal previously undetected system failure modes.
%
This is because the analyst 
is  forced to deal with all component failure modes when applying the FMMD process, and
all failure modes of the resultant {\dcs} as the hierarchy is built.
%
FMMD requires that all failure modes of components in a {\fg} are resolved to
a symptom in the resulting {\dc}.
%
 As `complete' analysis can be enforced, FMMD can find failure modes which were missed by
other FMEA processes; meaning that the  FMMD process can expose un-handled 
failure modes.
%come to light.
%
%
\paragraph{Retrospective failure mode analysis and software.}
%
 Retrospective FMMD can be applied to electronic and software hybrid systems. %as well.
%
The electronic components {\fms} are established in the literature~\cite{fmd91,mil1991,en298,en230}.
%
Each function in the software would have to be assigned a `design~contract'~\cite{dbcbe} (where violations of
contract clauses will be treated as failure modes in FMMD).
\fmmdgloss

\paragraph{Effect of newly discovered failure modes in components.}
%
Using traditional FMEA when discovering a new failure mode in a component or
sub-system it could be difficult to know
which parts of the FMEA analysis to
re-visit. 
%
For instance, which components in the system should the
newly discovered failure mode be checked against?
%
This concern is linked to the concepts behind
the need for failure mode coverage against all components in the system, that provoked discussions
leading to idealised XFMEA requirements (see section~\ref{sec:reasoningdistance}).
%
\fmmdgloss
\fmmdglossSFMEA
%
Using FMMD only those modules in the hierarchy above the 
component with the new failure mode need be re-visited.
%
The failure mode DAGs (see chapter~\ref{sec:chap4}) can be traced to determine exactly which
{\fgs} exist in the hierarchy above the affected {\bcs}.
%
This means that with FMMD the re-work task can be precisely defined.
%
Also where a new {\bc} {\fm} is merged with an existing symptom in the analysis
the re-work need not continue above it in the hierarchy.
%
That is a new {\bc} {\fm} may cause a symptom already found in the analysis hierarchy.
%
Finding these could be automated in a software tool that can traverse the failure mode trees.
%
% By %doing 
% applying contracts and seeing how calling functions deal with
% the failures in the functions they call, we reveal un-handled the error conditions in 
% the software.
% By treating hardware interfaces to software as {\dcs}, we automatically have a list of the failure modes
% of the electronics.
%%
With the contracts in place for the software functions, they can be integrated into the FMMD model.
%
FMMD models both software and hardware;
thus it can be verified that all
failure modes from the electronics module have been dealt
with by the controlling software. 
%
If not, this would be an  un-handled error condition relating to the software/hardware interface.
%
This again can be flagged using an automated tool.
%
% That is the  hardware interfaces to software in FMMD is a {\dc}, 
% the failure modes of this {\dc} are the list of all known failure modes
% of the electronics.
%
By performing FMMD on a software electronic hybrid system,
design deficiencies are revealed in both the software, the electronics and the software/electronics interface.
%in the hardware/software interface.
%
\fmmdglossFMEDA
\fmmdgloss
FMEDA does not handle software ---or---the software/hardware interface.
It thus potentially misses many undetected failures (in EN61508 terms undetected-dangerous and undetected safe failures).
In Safety Integrity Level (SIL)~\cite{en61508} terms, by identifying undetectable faults and fixing them,  
the safe failure fraction (SFF) is raised.
%
%
\subsection{Creation of a software FMMD tool.}
%
A software tool could be created with an extendible library/database of 
base and derived components.
%
This tool could guide the user through the analysis and hierarchy construction processes
and use the constraints and algorithms defined in appendix~\ref{sec:algorithmfmmd} and 
the UML diagram developed (see figure~\ref{fig:cfg})
for verification of the process and models produced.

%
%
\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, is commonly performed from
an `engineering' oriented cause and effect 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,
but on the environment in which they are used
and other human factors such as the training level of operatives, psychological and logical factors in 
the Human Machine Interface~(HMI)~\cite{stranks2007human}.
%
\paragraph{Objective and Subjective Reasoning in FMEA: Three Mile Island nuclear accident example.}
An example of objective and subjective factors is demonstrated in the accident report on the 1979  Three Mile Island 
nuclear accident~\cite{safeware}[App.D]. Here, a vent valve for the primary reactor coolant (pressurised water) became stuck open.
This condition caused an objectively derived  failure mode --- `leakage~of~coolant' --- due to a stuck valve.
%
This, if recognised correctly by the operators, would have lead quickly to a  reactor shut-down and
a maintenance procedure  to replace the valve.
%
The failure was not recognised in time %however, 
and coolant was lost
until a partial meltdown of the reactor fuel occurred, with a resulting
leak of radioactive material into the environment. 
%
For the objective failure mode determined by
FMEA, that of leakage of coolant,
it would not be reasonable to expect this to go unchecked and unresolved for an extended period and cause such a critical failure.
%
The criticality level of that {\fm} %accident 
was therefore subjective. 
%
It was not known how the operators
would have reacted and deficiencies in the Human Machine Interface (HMI) were not a factor in the failure analysis.


\paragraph{Further Work: Objective and Subjective Reasoning in FMEA.}
%
Criticality prediction can be said to be in the domain of subjective reasoning. 
%
With an objectively defined  system level failure
it is often required to next determine its level of criticality, or how serious the risk posed would be.
%
Two methodologies have started to consider this aspect, FMECA~\cite{fmeca} with its criticality and probability factors, and 
FMEDA~\cite{en61508,fmeda} with its classification of dangerous and safe failures.
%
\fmmdglossFMEDA
\fmmdglossFMECA
%
It is the author's opinion that more work is required to clarify this area. 
%
Accurate models of objective failure modes, are seen by the author to be a pre-requisite
for subjective assessment.
%
The scope of FMMD is the objective level only,
but offers significant benefits in terms of accuracy and labour savings.
%
It also offers integrated modelling of software and hardware.
%
Its failure mode model can also be used to assist in producing traditional FMEA formats.
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\today%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%