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

spell check of fmmd_concept.tex

Browse Source
This commit is contained in:
Robin Clark 2011-03-17 09:36:34 +00:00
parent f8dc65d9bf
commit 882986fc02
1 changed files with 28 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
fmmd_concept/fmmd_concept.tex
View File

@ -12,7 +12,7 @@ incremental and rigorous approach.
%of failure causes for flat ).
%It describes the need for the new methodology to be bottom-up, and
%then the need for incremental modularisation
%to build a fault mode hierarchy, which leads to the conceopt of functional grouping,
%to build a fault mode hierarchy, which leads to the concept of functional grouping,
%analysis of those groupings, and from that
%the creation of derived components.
%%
@ -38,7 +38,7 @@ In addition to addressing the traditional weaknesses of
Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Failure Mode Effects Criticality Analysis (FMECA)
and Failure Mode Effects and Diagnostic Analysis (FMEDA), FMMD provides the means to model multiple failure mode scenarios
as specified in newer European Safety Standards \cite{en298}.
The proposed methodology is bottom-up and can guarantee to leave no component failure mode unhandled.
The proposed methodology is bottom-up and can guarantee to leave no component failure mode un-handled.
It is also modular, meaning that the results of analysed components may be re-used in other projects.
}
}
@ -105,7 +105,7 @@ advantages that are discussed in the next section.
\paragraph{FMMD in context.}
Failure Mode Modular De-composition
(FMMD) aims to address the
weaknesses in the four established methodoligies, and to add
weaknesses in the four established methodologies, and to add
features such as the ability to analyse multiple
failure mode scenarios, and to allow modular re-use
of analysis.
@ -279,7 +279,7 @@ of missing component failure modes \cite{faa}[Ch.9].
%, or modelling at
%a too high level of failure mode abstraction.
FTA was invented for use on the minuteman nuclear defence missile
systems in the early 1960s and was not designed as a rigorous
systems in the early 1960's and was not designed as a rigorous
fault/failure mode methodology.
It was designed to look for disastrous top level hazards and
determine how they could be caused.
@ -289,12 +289,12 @@ notation using logic symbols, that guides the analysis.
This methodology was designed for
experienced engineers sitting around a large diagram and discussing the safety aspects.
Also the nature of a large rocket with red wire, and remote detonation
failsafes meant that the objective was to iron out common failures
fail-safes meant that the objective was to iron out common failures
not to rigorously detect all possible failures.
Consequently it was not designed to guarantee to covering all component failure modes,
and has no rigorous in-built safeguards to ensure coverage of all possible
system level outcomes.
Also each system level error (or undesireable event) requires its own FTA tree.
Also each system level error (or undesirable event) requires its own FTA tree.
This increases the amount of work to do, and in the case of updates to
particular sub-systems, introduces the requirement to update every FTA
tree modelling that use the affected sub-system.
@ -322,7 +322,7 @@ $O$ its occurrence\footnote{The occurrence $O$ is the
probability of the failure happening.},
and $D$ giving the failures detectability\footnote{Detectability: often failures
may occur but not be noticed or cause an effect.
Consider an unused feature failing.}. Muliplying these
Consider an unused feature failing.}. Multiplying these
together,
gives a risk probability number (RPN), given by $RPN = S \times O \times D$.
This gives in effect
@ -345,7 +345,7 @@ FMEA described in this section (\ref{pfmea}) is sometimes called `production FME
\subsection{FMECA}
Failure mode, effects, and criticality analysis (FMECA) extends FMEA adding a criticality factor.
Failure mode, effects, and critically analysis (FMECA) extends FMEA adding a critically factor.
This is a bottom up methodology, which takes component failure modes
and traces them to the SYSTEM level failures.
%
@ -356,12 +356,12 @@ electronic components was published by the DOD
in 1991 (MIL HDK 1991 \cite{mil1991}) and is a typical
source for MTFF data.
%
FMECA has a probability factor for a component error occuring % causing
FMECA has a probability factor for a component error occurring % causing
termed the $\alpha$ factor.
%\footnote{for a given component failure mode there will be a $\beta$ value, the
%probability that the component failure mode will cause a given SYSTEM failure}.
%
A second probability factor, the liklihood that the component failure
A second probability factor, the likelihood that the component failure
mode will cause a given SYSTEM failure, is termed the $\beta$ factor.
As often the component failure mode cannot be proven to cause a SYSTEM level failure, but is
assigned a heuristic probability $\beta$ factor by the design engineer.
@ -371,17 +371,10 @@ is often justified using Bayes theorem \cite{probstat}.
%
The results of FMECA are similar to FMEA, in that component errors are
listed according to importance, based on
probability of occurrence and criticality.
probability of occurrence and critically.
% to prevent the SYSTEM fault of given criticallity.
Again this essentially produces a prioritised `to~do' list.
%%-WIKI- Failure mode, effects, and criticality analysis (FMECA) is an extension of failure mode and effects analysis (FMEA).
%%-WIKI- FMEA is a a bottom-up, inductive analytical method which may be performed at either the functional or
%%-WIKI- piece-part level. FMECA extends FMEA by including a criticality analysis, which is used to chart the
%%-WIKI- probability of failure modes against the severity of their consequences. The result highlights failure modes with relatively high probability
%%-WIKI- and severity of consequences, allowing remedial effort to be directed where it will produce the greatest value.
%%-WIKI- FMECA tends to be preferred over FMEA in space and North Atlantic Treaty Organization (NATO) military applications,
%%-WIKI- while various forms of FMEA predominate in other industries.
\subsubsection{ FMECA weaknesses }
@ -389,8 +382,8 @@ Again this essentially produces a prioritised `to~do' list.
\item Possibility to miss the effects of failure modes at SYSTEM level.
\item Possibility to miss environmental affects.
\item The $\beta$ factor is based on heuristics and typically does not reflect any rigorous calculations.
\item The $\alpha$ factor is generally taken from lierature for generic component such as MIL~HDBK~\cite{mil1992}
and may not take into account operational states and environemtnal factors.
\item The $\alpha$ factor is generally taken from literature for generic component such as MIL~HDBK~\cite{mil1992}
and may not take into account operational states and environmental factors.
\item Complex component interaction effects can be missed.
\item No possibility to model base component level double failure modes.
\end{itemize}
@ -409,8 +402,7 @@ This technique
evaluates a product's statistical level of safety
taking into account its self-diagnostic ability.
The calculations and procedures for FMEDA are
described in EN61508 %Part 2 Appendix C
\cite{en61508}[Part 2 App C].
described in EN61508~\cite{en61508}[Part 2 App C].
The following gives an outline of the procedure.
@ -422,7 +414,7 @@ Probability of Failure on Demand (PFD), and Probability of Failure
in continuous Operation, or Failure in Time (FIT).
\paragraph{Failure in Time (FIT).} Continuous operation is measured in failures per billion ($10^9$) hours of operation.
For a continuously running nuclear powerstation, industrial burner or aircraft engine
For a continuously running nuclear power-station, industrial burner or aircraft engine
we would be interested in its operational FIT values.
\paragraph{Probability of Failure on Demand (PFD).} For instance with an anti-lock system in
@ -472,7 +464,7 @@ environmental conditions.
\paragraph{Self Diagnostics.}
We next evaluate the SYSTEM's self-diagnostic ability.
%Each component’s failure modes and failure rate are now available.
%Each component's failure modes and failure rate are now available.
Failure modes are now classified as safe or dangerous.
This is done by taking a component failure mode and determining
if the SYSTEM error it is tied to is dangerous or safe.
@ -492,7 +484,7 @@ self checking features.
%
This gives us four level failure mode classifications:
Safe-Detected (SD), Safe-Undetected (SU), Dangerous-Detected (DD) or Dangerous-Undetected (DU),
and the probablistic failure rate of each classification
and the probabilistic failure rate of each classification
is represented by lambda variables
(i.e. $\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$).
@ -575,9 +567,9 @@ against all safe and dangerous failure probabilities.
\paragraph{Classification into Safety Integrity Levels (SIL).}
There are four SIL levels, from 1 to 4 with 4 being the highest safety level.
In addition to probablistic risk factors, the
In addition to probabilistic risk factors, the
diagnostic coverage and SFF
have threshold bands beoming stricter for each level.
have threshold bands becoming stricter for each level.
Demanded software verification and specification techniques and constraints
(such as language subsets, s/w redundancy etc)
become stricter for each SIL level.
@ -590,7 +582,7 @@ Thus FMEDA uses statistical methods to determine
a safety level (SIL), typically used to meet an acceptable risk
value, specified for the environment the SYSTEM must work in.
EN61508 defines in general terms,
risk assessment and required SIL levels \cite{en61508} [5 Annex A].
risk assessment and required SIL levels~\cite{en61508}[5 Annex A].
%the probability of
%failures occurring, and provide an adaquate risk level.
@ -656,7 +648,7 @@ section of the product.
%will be if it occurs.
This leads to the practise of having components within a SYSTEM partitioned into different
safety level zones as recomended in EN61508\cite{en61508}. This is a vague way of determining
safety level zones as recommended in EN61508\cite{en61508}. This is a vague way of determining
safety, as it can miss unexpected effects due to `unexpected' component interaction.
The Statistical Analysis methodology is the core philosophy
@ -714,7 +706,7 @@ further into the way the system works and is built.
\paragraph{Need for a `bottom-up' system de-composition.}
There is an apparent conflict here as de-composition ormally implies a top-down approach. The natural way to
There is an apparent conflict here as de-composition normally implies a top-down approach. The natural way to
de-compose a system is from the top down.
%
If we do this though, we do not naturally include
@ -1061,7 +1053,7 @@ in different ways.
For instance, a system may be specified for
$0\oc$ to $85\oc$ operation, but some components
may show failure behaviour between $60\oc$ and $85\oc$
\footnote{Opto-islolators typically show marked performance decrease after
\footnote{Opto-isolators typically show marked performance decrease after
$60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
Other components may operate comfortably within that whole temperature range specified.
Environmental conditions will have an effect on the {\fg} and the {\dc},
@ -1121,7 +1113,7 @@ Because component failure modes are considered, we have a generic entity to mode
We can describe a mechanical, electrical or software component in terms of its failure modes.
%
Because of this
we can model and analyse integrated electro mechanical systems, controlled by computers,
we can model and analyse integrated electromechanical systems, controlled by computers,
using a common notation.
\subsubsection{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
@ -1253,7 +1245,7 @@ Taking the four current failure mode methodologies into consideration, and compa
\begin{itemize}
\item It can be checked automatically that all component failure modes have
been considered in the model. Should a failure mode have been missed
the data model can be searched and the unhandled failure modes flagged to the design engineer.
the data model can be searched and the un-handled failure modes flagged to the design engineer.
\item Because we are modelling with failure modes the {\fgs} and {\dcs} these can be generic,
i.e. mechanical, electronic or software components.
\item The {\dcs} are re-usable, in that commonly used modules can be re-used in other designs/projects.
@ -1267,10 +1259,10 @@ the statistical probabilities (from base component data) for all causes can be s
This provides an interface that does not involve
formal mathematical/symbolic notation.
This is intended to be user friendly and to guide the user through the FMMD process
while applying automatic checks for unhandled conditions.
while applying automatic checks for un-handled conditions.
\item From the top down the failure mode model will follow a logical de-composition of the functionality; by
chosing {\fg}s and working bottom-up this hierarchical trait will occur as a natural consequence.
\item Undetectable or unhandled failure modes will be specifically flagged.
\item Undetectable or un-handled failure modes will be specifically flagged.
\item It is possible to model multiple failure modes.
\end{itemize}
@ -1317,7 +1309,7 @@ functions, given requirements and constraints such as the number of combinations
of failure causes.
It describes the need for the new methodology to be bottom-up, and
then the need for incremental modularisation
to build a fault mode hierarchy, which leads to the conceopt of functional grouping,
to build a fault mode hierarchy, which leads to the concept of functional grouping,
analysis of those groupings, and from that
the creation of derived components.
}