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

Bank Holiday Weekend editing.

Browse Source 
Off to play with the unicycle now by the allotments....
This commit is contained in:
Robin Clark 2013-05-27 17:09:13 +01:00
parent 0776011964
commit 52a9dba6b7
3 changed files with 281 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
mybib.bib
View File

@ -358,6 +358,14 @@ keywords={Aerospace engineering;Aerospace industry;Aerospace safety;Automotive e
doi={10.1109/HASE.2004.1281774},
ISSN={1530-2059},}
@book{stranks2007human,
title={Human Factors and Behavioural Safety},
author={Stranks, J.},
isbn={978-0-7506-6542-1},
url={http://books.google.co.uk/books?id=7RXYN2CIphMC},
year={2007},
publisher={Butterworth-Heinmann}
}
@INPROCEEDINGS{1372150,
author={Hartkopf, S.},

16
submission_thesis/CH2_FMEA/copy.tex
View File

@ -817,7 +817,21 @@ be subject to management and/or political pressure.
%
The two most recent variants of FMEA,
FMEDA and FMECA have dipped a metaphorical toe into the subjective realm, FMECA with itself `criticality~factor' and
FMEDA with its definition of `dangerous'.
FMEDA with its definition of `dangerous'.
%
However, while starting to address the subjective side
of failure analysis,
these methodologies
do not separate the final subjective stage from the objective. % stage of analysis.
%
A subjective assessment is made during the analysis of each {\bc} {\fm}
regardless of the fact that most {\bc} {\fms} cause shared
system level failures.
%
This means that work at the subjective
level is repeated.
%
Detailed work on subjective analysis is beyond the scope of this study.
\paragraph{Multiple Simultaneous Failure Modes.}

374
submission_thesis/CH8_Conclusion/copy.tex
View File

@ -1,103 +1,64 @@
\label{sec:chap8}
In this study we have 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
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.
%
This modularised version was supported by the work already established in the
{\fms} of {\bc} in the literature~\cite{fmd91,mil1991,en298,en230}.
%
A selection of electronic examples were analysed using FMMD
which deliberately introduced varying circuit
topologies with conventional and circular signal paths
and mixed digital and analogue designs.
%
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 reduced.
%
Not only this but the analysis naturally provided modules which could be re-used,
re-used not only in the circuit under analysis but potentially in different and future projects as well.
Traditional FMEA methods have been applied to software, but analysis has always 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,
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
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}.
%
Chapter~\ref{sec:chap7} viewed FMMD from a formal perspective and looked at problems and constraints
necessary to perform FMEA and FMMD.
%
Theoretical performance models were developed which showed that with increasing modularisation
the number of manual checks to perform for analysis fell, which was validated by examining the
electronic examples in this regard.
%
A unitary state failure mode constraint was developed for the failure modes of a component, and it was shown that
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}.
\section{Further Work}
\subsection{Environment, operational states and inhibit gates: additions to the UML model.}
FTA~\cite{nasafta,nucfta} models environmental, operational state and inhibit gates, and these can be incorporated into
the FMMD model.
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 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.
%
Operational states and environmental conditions can %must
be factored into the UML model.
\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 is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}.
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, we can therefore eliminate some failure modes from the model.
\paragraph{Operational states.}
Within the field of safety critical engineering, we often encounter
elements that include test or self-test facilities.
%
We also encounter degraded performance
(such as only performing functions in an emergency) and lockout/emergency conditions.
These can be broadly termed operational states. %, and apply to the
%functional groups.
%
We need to determine which UML class is most appropriate to hold a relationship
to operational states.
%
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 we associate operational states with {\fgs}.
%therefore are the best objects to model
%operational states.% with.
\paragraph{Inhibit Conditions.}
A third data class may be required if modelling inhibit conditions~\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.
\paragraph{UML Diagram Additional Objects.}
The additional objects System, Environment 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, incorporating Environmental, Operational State and Inhibit gates}
\label{fig:cfg2}
\end{figure}
%% 31JAN2012
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.}
\label{sec:bcstats}
Knowing the statistical likelihood of a component 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.
@ -289,13 +250,20 @@ we can also apply failure rate statistics to double failures.
%%
%
If we consider the failure modes to be statistically independent we can calculate
the FIT values for all the combinations failures in table~\ref{tab:ptfmea2}.
the FIT values for all the combinations failures in the the electronic examples chapter~\ref{sec:chap5} table~\ref{tab:ptfmea2}.
%
The failure mode of concern, the undetectable {\textbf{FLOATING}} condition
requires that resistors $R_1$ and $R_2$ fail. We can multiply the MTTF
together and find an MTTF for both failing. The FIT value of 12.42 corresponds to
requires that resistors $R_1$ and $R_2$ fail.
%
We can multiply the MTTF
together and find an MTTF for both failing.
%
The FIT value of 12.42 corresponds to
$12.42 \times {10}^{-9}$ failures per hour. Squaring this gives $ 154.3 \times {10}^{-18} $.
%
This is an astronomically small MTTF, and so small that it would
probably fall below a threshold to sensibly consider.
%
However, it is very interesting from a failure analysis perspective,
because here we have found a fault that we cannot detect at this
level. This means that should we wish to cope with
@ -303,6 +271,133 @@ this fault, we need to devise a way of detecting this
condition in higher levels of the system.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period. Associated with continuous demand systems under EN61508~\cite{en61508}}}
\subsection{Deriving FTA diagrams from FMMD models}
\label{sec:fta}
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, we can trace all the causes of system failures
down to the base component level.
%
This would be enough to create a fault causation tree, 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 we require FMMD to produce full FTA diagrams, we need to add these attributes to the FMMD UML model.
\paragraph{Environment, operational states and inhibit gates: additions to the UML model.}
FTA%~\cite{nasafta,nucfta}
models environmental, operational state and inhibit gates, and these can be incorporated into
the FMMD model.
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 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.
%
Operational states and environmental conditions can %must
be factored into the UML model.
%
We may encounter a condition where we would want to inhibit some action of the system.
This is rather like a logical guard criterion. For instance in the gas burner standard EN298
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.
\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 is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}.
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, we can therefore eliminate some failure modes from the model.
\paragraph{Operational states.}
Within the field of safety critical engineering, we often encounter
elements that include test or self-test facilities.
%
We also encounter degraded performance
(such as only performing functions in an emergency) and lockout/emergency conditions.
These can be broadly termed operational states. %, and apply to the
%functional groups.
%
We need to determine which UML class is most appropriate to hold a relationship
to operational states.
%
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 we associate operational states with {\fgs}.
%therefore are the best objects to model
%operational states.% with.
\paragraph{Inhibit Conditions.}
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, we therefore link this with
both environmental conditions and failure modes.
\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, incorporating Environmental, Operational State and Inhibit gates}
\label{fig:cfg2}
\end{figure}
\clearpage
\section{Retrospective Failure Mode analysis and FMMD}
The reasons for applying retrospective failure mode analysis could be approving previously un-assessed
@ -310,46 +405,93 @@ systems to a safety standard, or to determine the failure mode behaviour of an
safety critical verification. % verification.
%
FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with
its work flow it
can reveal undetected failure modes.
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.
%
FMMD requires that all failure modes of components in a {\fg} are resolved to
a symptom in the resulting {\dc}.
%
%
FMMD can find failure modes that are not
dealt with as a symptom, i.e. were unintentionally ignored
dealt with as a symptom, i.e. were ignored
or forgotten. This means that FMMD will route out un-handled
failure modes.
%come to light.
%
We can apply retrospective FMMD to electronic and software hybrid systems as well.
Each function in the software will have to be assigned a `design~contract'~\cite{dbcbe} (where violations of
%
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).
%
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.
% 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, we can then integrate them into the FMMD model.
%
FMMD models both software and hardware;
we can thus verify that all
failure modes from the electronics module, have been dealt
by the controlling software. If not they are an un-handled error condition.
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 the controlling software.
%
If not they are an un-handled error condition relating to the software hardware interface.
%
% 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,
we thus reveal design deficiencies.
we thus reveal design deficiencies inboth the software and the software/electronics interface.
%in the hardware/software interface.
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, we raise
the safe failure fraction (SFF).
\section{How traditional FMEA reports can be derived from an FMMD model.}
%
An FMMD model has a data structure (described by UML diagrams, see figure~\ref{fig:cfg}), and by traversing this
we can map system level failures back to {\bc} {\fms} (or combinations thereof).
%
Because we can determine these mappings we can produce reports in the traditional FMEA format ({\bc}~{\fm}~$\mapsto$~{system failure}).
%
With the addition of {\bc} {\fm} statistics~\cite{mil1991} we can provide reliability predictions for system level failures.
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.
We could for instance take each system level failure and produce a causation tree 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}.
%
\section{Objective and Subjective Reasoning stages}
Opportunity for formal definitions and perhaps an interface or process for achieving it....
%Opportunity for formal definitions and perhaps an interface or process for achieving it....
The act of applying failure mode effects analysis, is in terms of cause and effect viewed from
and 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 its self,
but on the environment they are used in
and other human factors such as the training level of operatives~\cite{stranks2007human}.
%
We could term this subjective reasoning. With the system level failure
we have to determine its level of criticality, or how serious the risk posed is.
%
Two methodologies have started to consider this aspect, FMECA with its criticality and probability factors, and
EN61508 with its classification of dangerous and safe failures.
%
It is the authors opinion that more work is required to clarify this area. FMMD stops at the objective level.
\section{Conclusion}