Forgot to commit
This commit is contained in:
Robin Clark
parent
ec7dc38679
commit
db28cb4635
29
mybib.bib
29
mybib.bib
@ -384,12 +384,13 @@ Pages = {279 - 293},
|
||||
Title = {An evaluation of failure modes and effects analysis generation method for conceptual design.},
|
||||
Volume = {18},
|
||||
URL = {http://search.ebscohost.com.ezproxy.brighton.ac.uk/login.aspx?direct=true&db=buh&AN=17784368&site=ehost-live},
|
||||
Year = {2005},
|
||||
Year = {2005}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{931423,
|
||||
author={Throop, D.R. and Malin, J.T. and Fleming, L.D.},
|
||||
booktitle={Aerospace Conference, 2001, IEEE Proceedings.}, title={Automated incremental design FMEA},
|
||||
booktitle={Aerospace Conference, 2001, IEEE Proceedings.},
|
||||
title={Automated incremental design FMEA},
|
||||
year={2001},
|
||||
month={},
|
||||
volume={7},
|
||||
@ -397,7 +398,7 @@ number={},
|
||||
pages={7 -3458 vol.7},
|
||||
keywords={Analytical models;Design automation;Design engineering;Discrete event simulation;Failure analysis;Hybrid power systems;Performance analysis;Production;Propulsion;Steady-state;aerospace computing;aerospace simulation;discrete event simulation;engineering computing;failure analysis;production engineering computing;CONFIG hybrid discrete event simulator;EPOCH Simulation for Failure Analysis software;EPOCH algorithm;automated incremental design FMEA;automatic generation;design models;engineering product/operations cross-cutting hybrid simulation ;failure modes;failure modes/effects analysis;functional labels;propellant production plant;scenario scripts;scenario-based analyses;space systems;timestep modeling;},
|
||||
doi={10.1109/AERO.2001.931423},
|
||||
ISSN={},}
|
||||
ISSN={}}
|
||||
|
||||
@INPROCEEDINGS{5754453,
|
||||
author={Snooke, N. and Price, C.},
|
||||
@ -411,7 +412,7 @@ pages={1 -6},
|
||||
keywords={Analytical models;Fault diagnosis;Hardware;Programming;Software;Testing;Unified modeling language;safety-critical software;MISRA C;component diagrams;low-level languages;low-level programming;model-driven automated software FMEA;model-driven software developments;safety critical embedded systems;sequence diagrams;software development philosophy;software effects analysis;software failure mode;source code embedded testing;state charts;use case diagram;Failure modes and effects analysis;model-driven software development;software FMEA;},
|
||||
doi={10.1109/RAMS.2011.5754453},
|
||||
ISSN={0149-144X},}
|
||||
Baiqiao HUANG
|
||||
|
||||
@INPROCEEDINGS{FMECAresearch,
|
||||
author={Ying Chen and Cui Ye and Bingdong Liu and Rui Kang},
|
||||
booktitle={Prognostics and System Health Management (PHM), 2012 IEEE Conference on}, title={Status of FMECA research and engineering application},
|
||||
@ -424,8 +425,7 @@ keywords={automobile industry;electronics industry;failure analysis;military sta
|
||||
doi={10.1109/PHM.2012.6228914},
|
||||
ISSN={2166-563X},}
|
||||
|
||||
Software FMEA Approach Based on Failure Modes
|
||||
Database
|
||||
|
||||
@ARTICLE{sfmeaauto,
|
||||
AUTHOR = "Barbara J. Czerny et all. Delphi Corporation.",
|
||||
TITLE = "Effective Application of Software Safety Techniques for Automotive Embedded Control Systems",
|
||||
@ -448,11 +448,7 @@ Database
|
||||
}
|
||||
|
||||
|
||||
%A process for failure modes and effects analysis of computer software
|
||||
|
||||
%Ozarin, N.
|
||||
%Omnicon Group Inc., Hauppauge, NY, USA
|
||||
%Siracusa, M.
|
||||
@ARTICLE{procsfmea,
|
||||
AUTHOR = "Ozarin, N.",
|
||||
TITLE = "A process for failure modes and effects analysis of computer software",
|
||||
@ -460,14 +456,7 @@ Database
|
||||
YEAR = "2003"
|
||||
}
|
||||
|
||||
%This paper appears in:
|
||||
%Software Engineering and Data Mining (SEDM), 2010 2nd International Conference on
|
||||
%Date of Conference: 23-25 June 2010
|
||||
%Author(s): Wang, Danhua
|
||||
% State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China
|
||||
% Pan, Jingui
|
||||
% On Page(s): 187 - 191
|
||||
% Product Type: Conference Publications
|
||||
|
||||
@ARTICLE{appswfmea,
|
||||
AUTHOR = "Danhua Wang",
|
||||
TITLE = "An approach of automatically performing fault tree analysis and failure mode effects techniques to Software",
|
||||
@ -750,7 +739,7 @@ year = {2012},
|
||||
YEAR = "2002"
|
||||
}
|
||||
|
||||
@
|
||||
|
||||
@BOOK{usefulinfoengineers,
|
||||
AUTHOR = "William Fairbairn",
|
||||
TITLE = "Useful Information for Engineers
|
||||
@ -767,7 +756,7 @@ strength of materials, the causes of boiler explosions",
|
||||
YEAR = "2010"
|
||||
}
|
||||
|
||||
% Safeware: System safety and Computers
|
||||
|
||||
|
||||
@BOOK{safeware,
|
||||
AUTHOR = "Nancy Leveson",
|
||||
|
||||
@ -56,7 +56,7 @@ The acronym FMEA can be expanded as follows:
|
||||
\item \textbf{A - Analysis,} Analyse how much impact this symptom will have on the environment/operators/the system itself.
|
||||
\end{itemize}
|
||||
%
|
||||
FMEA is a broad term; it could mean anything from an informal check on how
|
||||
FMEA is a broad term; it could mean anything from an informal check on
|
||||
how failures could affect some equipment in %an initial
|
||||
a brain-storming session
|
||||
%in product design,
|
||||
@ -111,7 +111,8 @@ To perform this we need to know how a failure
|
||||
mode, considering its effect on other components in the system
|
||||
will translate to a system level symptom/failure.
|
||||
%
|
||||
The result of FMEA is to determine a system level failures, or symptoms for each given component failure mode.
|
||||
The result of FMEA is to determine a system level failures,
|
||||
or symptoms for each given component failure mode.
|
||||
%
|
||||
In practise, each entry of an FMEA analysis of a {\bc} {\fm}
|
||||
would typically be one line in a spreadsheet.
|
||||
@ -257,7 +258,7 @@ as shown below.
|
||||
\end{itemize}
|
||||
%
|
||||
We note that the main causes of resistor value drift are overloading. % of components.
|
||||
This is borne out in in the FMD-91~\cite{fmd91}[232] entry for a resistor network where the failure
|
||||
This is borne out in the FMD-91~\cite{fmd91}[232] entry for a resistor network where the failure
|
||||
modes do not include drift.
|
||||
%
|
||||
If we can ensure that our resistors will not be exposed to overload conditions, the
|
||||
@ -398,7 +399,7 @@ EN298 does not specifically define OP\_AMPS failure modes; these can be determi
|
||||
by following a procedure for `integrated~circuits' outlined in
|
||||
annex~A~\cite{en298}[A.1 note e].
|
||||
This demands that all open connections, and shorts between adjacent pins be considered as failure scenarios.
|
||||
We examine these failure scenarios on the dual packaged $LM358$~\cite{lm358}%\mu741$
|
||||
We examine these failure scenarios on the dual packaged $LM358$~\cite{lm358} %\mu741$
|
||||
and determine its {\fms} in table ~\ref{tbl:lm358}.
|
||||
Collecting the op-amp failure modes from table ~\ref{tbl:lm358} we obtain the same {\fms}
|
||||
that we got from FMD-91, listed in equation~\ref{eqn:opampfms}.
|
||||
@ -779,7 +780,8 @@ This means that objective reasoning can be applied to determine objective effect
|
||||
of those failures depends upon the Equipment Under Control (EUC)
|
||||
and its environment.
|
||||
%
|
||||
For instance a leak of nuclear material on an aboard a spacecraft could have the consequences
|
||||
For instance a leak of nuclear material %on an
|
||||
aboard a spacecraft could have the consequences
|
||||
of loss of mission, but a leak on earth could have serious health and environmental consequences.
|
||||
This means one line of FMECA describing a system risk is an over simplification (consider that the same
|
||||
nuclear material will be present during transport and launch, and when outside earth's environment).
|
||||
@ -788,7 +790,7 @@ Subjective appraisal of the outcome of a system failure mode can also
|
||||
be subject to management and/or political pressure.
|
||||
|
||||
|
||||
\paragraph{Multiple Simultaneous Failure Modes}
|
||||
\paragraph{Multiple Simultaneous Failure Modes.}
|
||||
%
|
||||
FMEA is less useful for determining events for multiple
|
||||
simultaneous
|
||||
@ -959,7 +961,7 @@ double failure scenarios (for burner lock-out scenarios).}
|
||||
\end{equation}
|
||||
|
||||
For our theoretical 100 components with 3 failure modes each example, this is a reasoning distance of
|
||||
$100*99*98*3=2,910,600$ . % failure mode scenarios.
|
||||
$100*99*98*3=2,910,600$. % failure mode scenarios.
|
||||
In practise there is an additional concern here, that of
|
||||
the circuit topology changes that {\fms} can cause.
|
||||
|
||||
@ -1146,7 +1148,7 @@ type standards (EN61508/IOC5108).
|
||||
The end result of an EN61508 analysis is an % provides a statistical
|
||||
overall `level of safety' known as a Safety Integrity level (SIL), for a system.
|
||||
There are currently four SIL `levels', one to four, with four being the highest level.
|
||||
It allows diagnostic mitigation for self checking checking circuitry.
|
||||
It allows diagnostic mitigation for self checking circuitry.
|
||||
%
|
||||
% for four levels of
|
||||
%safety integrity, referred to as Safety Integrity Levels (SIL).
|
||||
@ -1220,8 +1222,8 @@ 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 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) improves the SFF, this
|
||||
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
|
||||
apparent loophole is closed in the 2010 edition of the standard.
|
||||
|
||||
|
||||
@ -1230,7 +1232,7 @@ apparent loophole is closed in the 2010 edition of the standard.
|
||||
\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
||||
To achieve SIL levels, diagnostic coverage and SFF levels are prescribed along with
|
||||
hardware architectures and software techniques.
|
||||
The overall the aim of SIL is classify the safety of a system,
|
||||
The overall the aim of SIL is to classify the safety of a system,
|
||||
by statistically determining how frequently it can fail dangerously.
|
||||
|
||||
|
||||
@ -1352,8 +1354,9 @@ However, as with the components that we should check against a {\fm}, there are
|
||||
the reasoning stages for an FMEA entry.
|
||||
%FMEA does not stipulat which
|
||||
Ideally each FMEA entry would contain a reasoning description
|
||||
for each component the {\fm} is checked against, so that the the entry can be reviewed or revisited/audited.
|
||||
Because FMEA is traditionally performed with one entry per component {\fm} full reasoning descriptions
|
||||
for each component the {\fm} is checked against, so that the entry can be reviewed or revisited/audited.
|
||||
%
|
||||
Because FMEA is traditionally performed with one entry per component {\fm}, full reasoning descriptions
|
||||
are rare.
|
||||
This means that re-use, review and checking of traditional analysis must be started from `cold'.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ practise % practise is a noun and practise is a verb
|
||||
in a
|
||||
critical light.
|
||||
Chapter~\ref{sec:chap2} introduced concepts underlying FMEA, and this chapter seeks to
|
||||
use these concepts to the 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
|
||||
in Europe and the USA, at the very least means that experienced
|
||||
@ -21,7 +21,7 @@ and look for ways in which it could be done better and more efficiently.
|
||||
A major problem is with the scope of examination---or required reasoning distance---to apply
|
||||
for FMEA analysis.
|
||||
Checking all combinations quickly leads to a state explosion problem:
|
||||
limiting the number of components to check for against for a given {\bc}
|
||||
limiting the number of components to check for against a given {\bc}
|
||||
{\fm} could address this.
|
||||
%
|
||||
The difficulties of integrating software
|
||||
@ -48,7 +48,7 @@ FMEA requirements.
|
||||
Other problems such as the inability to easily re-use, and validate/audit (through
|
||||
traceable reasoning) FMEA models are presented.
|
||||
%
|
||||
Finally we conclude with a list of deficiencies in current FMEA methodologies, and present a wish list
|
||||
Finally we conclude with a list of deficiencies in current FMEA methodologies and present a wish list
|
||||
for an improved methodology.
|
||||
|
||||
\section{Historical Origins of FMEA: {\bc} {\fm} to system level failure/symptom paradigm}
|
||||
@ -77,7 +77,7 @@ but the structure of current FMEA reports does not encourage this.
|
||||
Given the {\bc} {\fm} to system level failure mode paradigm it is
|
||||
difficult to re-use FMEA analysis.
|
||||
%
|
||||
Several strategies to aid re-use have been proposed~\cite{rudov2009language, patterns6113886,931423 }, but
|
||||
Several strategies to aid re-use have been proposed~\cite{rudov2009language, patterns6113886, 931423}, but
|
||||
the fundamental problem remains, that, with any changes
|
||||
to the component base in a system, it is very difficult to
|
||||
determine which FMEA test scenarios must be re-worked.
|
||||
@ -120,7 +120,8 @@ Traditional FMEA cannot ensure that each failure mode of all its
|
||||
components are checked against any other components in the system which
|
||||
it may affect, due to state explosion.
|
||||
%
|
||||
FMEA is therefore performed using heuristics to decide
|
||||
FMEA is therefore performed using heuristics % at best
|
||||
to decide
|
||||
which components to check the effect of a component failure mode on.
|
||||
%We could term the number of checks made for each failure mode
|
||||
%on aspects of the system to be the reasoning distance.
|
||||
@ -220,8 +221,9 @@ FMEA), to ensure that failure modes within the instrument cannot lead to invalid
|
||||
%
|
||||
Some work has been performed to offer black~box---or functional testing---of these instruments instead of
|
||||
static analysis~\cite{Bishop:2010:ONT:1886301.1886325}.
|
||||
%
|
||||
However, black box testing of smart instruments is
|
||||
yet to be a an approved method of validation.
|
||||
yet to be an approved method of validation.
|
||||
|
||||
Most modern instruments now use highly integrated electronics coupled to micro-controllers, which read and filter the measurements,
|
||||
and interface to an LCD readout.
|
||||
@ -236,7 +238,7 @@ systems. %by traditional FMEA.
|
||||
%to a high level of reliability by traditional FMEA.
|
||||
%
|
||||
Currently the only way that some smart~instruments have been permitted for
|
||||
use in highly critical systems is the have the extensively
|
||||
use in highly critical systems is to have them extensively
|
||||
functionally tested~\cite{bishopsmartinstruments}.
|
||||
|
||||
|
||||
@ -260,7 +262,7 @@ This adjustment could be direct, or could be another CANbus message passed to a
|
||||
%
|
||||
In terms of FMEA, see figure~\ref{fig:distcon}, our reasoning path spans (at least) four interface layers of electronics to software.
|
||||
%
|
||||
Traditional FMEA does not cater for the software hardware interface, and here we have the addition complications
|
||||
Traditional FMEA does not cater for the software hardware interface, and here we have the additional complications
|
||||
%with the additional complications
|
||||
of the communications protocol used to transmit data and the failure mode characteristics
|
||||
of the communications physical layer.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user