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

FMEDA and SIL

Browse Source 
+ general tidying
This commit is contained in:
Robin Clark 2010-11-09 19:25:15 +00:00
parent 88e3a81153
commit 2af3c8b083
1 changed files with 97 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

130
fmmd_concept/fmmd_concept.tex
View File

@ -246,7 +246,7 @@ system level outcomes.
\subsection { FMEA }
\label{pfmea}
This is an early static analysis methodology, and concentrates
on SYSTEM level errors which have been investigated.
The investigation will typically point to a particular failure
@ -270,7 +270,7 @@ a prioritised `todo list', with higher the $RPN$ values being the most urgent.
\paragraph{note.} FMEA is sometimes used in its literal sense, that is to say
failure Mode effects Analysis, simply looking at a systems internal failure
modes and determing what may happen as a result.
FMEA described in this section is sometimes called `production FMEA'.
FMEA described in this section (\ref{pfmea}) is sometimes called `production FMEA'.
\subsection{FMECA}
@ -319,39 +319,105 @@ Failure Modes, Effects, and Diagnostic Analysis (FMEDA).
This is a process that takes all the components in a system,
and from the failure modes of those components, the investigating engineer
must tie them to possible SYSTEM level events/failure modes.
This technique
evaluates and the product’s self-diagnostic ability,
The calculations and procedure for FMEDA are
described in EN61508 Part 2 Appendix C \cite{en61508}[Part 2 App C].
The following gives an outline of the procedure.
\paragraph{FMEA}
The first stage is to apply FMEA to the SYSTEM.
Within the product all failure rates of individual
components contribute to the overall product failure rate.
Failure rates of individual components in the SYSTEM
are calculated based on component type and
environmental conditions.
\paragraph{Overall SYSTEM failure rate}
Product failure rate is the sum of all component
failure rates. This is the sum of safe and unsafe
failures.
\paragraph{Self Diagnostics}
We next evaluate the SYSTEMS’s self-diagnostic ability.
Each component’s failure mode and its failure rate are listed.
Failure modes are classified as safe or dangerous\footnote{Again this is taking a component failure mode and determing
how it will react with any other components in the SYSTEM and making a decision
based on hueistics.}.
detectable failures are labelled `$\lambda_D$' and safe failures `$\lambda_S$' by EN61508.
\paragraph{Determine Detectable and Undetecable Failures}
Each safe and dangerous failure mode is determined as detectable or un-detectable by the SYSTEMS’s
self checking features.
%
The result is a list of all components, their failure modes, the failure mode classification
as Safe-Detected (SD), Safe-Undetected (SU), Dangerous-Detected (DD) or Dangerous-Undetected (DU),
and the failure rate of each classification using the failure rate
prediction results ($\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$).
Because some failure modes may not be discovered theoretically during the
next step is to investigate using an actual working SYSTEM.
This requires the deliberate introduction
of failures; any new failures discovered at this stage are classified
$\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$
and added to the result set.
%SD, SU, DD, DU.
\paragraph{Diagnostic Coverage.}
The diagnostic coverage is simply the ratio
of the dangerous detected probabilities
against the probability of all dangerous failures,
and is normally expressed as a percentage.
$$ DiagnosticCoverage = \Sigma\lambda_{DD} / \Sigma\lambda_D $$
The diagnostic coverage for safe failures is given as
$$ SF = \frac{\Sigma\lambda_SD}{\Sigma\lambda_S} $$
\paragraph{Safe Failure Fraction.}
A key concept in FMEDA is Safe Failure Fraction (SFF).
This is the ratio of safe and dangerous detected failures
against the safe and dangerous failure probabilities.
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) $$
This is the ratio of
Step 4 Calculate SFF, SIL and PFD
The SIL level of the product is finally determined from the Safe Failure Fraction (SFF) and the Probability of Failure on Demand (PFD). The following formulas are used.
SFF = (lSD + lSU + lDD) / (lSD + lSU + lDD + lDU)
PFD = (lDU)(Proof Test Interval)/2 + (lDD)(Down Time or Repair Time)
% Often a given component failure mode there will be a $\beta$ value, the
% probability that the component failure mode will cause a given SYSTEM failure.
\paragraph{Risk Mitigation}
The component may be mitigated by a vatriety of factors
\begin{itemize}
\item Automatic checking
\item Down rating
\item Coverage of self checking
\end{itemize}
The component may be have its risk factor
reduced by the checking interval (or $\tau$ time between self checking procedures).
Ultimately this technique calculates a risk factor for each component.
The risk factors of all the components are summed and
give a value for the `safety level' for the equipment in a given environment.
%%-he FMEDA technique considers
%%-• All components of a design,
%%-• The functionality of each component,
%%-• The failure modes of each component,
%%-• The impact of each component failure mode on the product functionality,
%%-• The ability of any automatic diagnostics to detect the failure,
%%-• The design strength (de-rating, safety factors) and
%%-• The operational profile (environmental stress factors).
\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
diagnostic coverage and SFF
have threshold bands beoming stricter for each level.
Software techniques and constraints are
also become stricter for each SIL level.
This uses MTFF and other statistical models to determine the probability of
failures occurring.
FMEDA uses MTFF and other statistical models to determine the probability of
failures occurring, and provide an adaquate risk level.
%
A component failure mode, given its MTTF
the probability of detecting the fault and its safety relevant validation time $\tau$,
contributes a simple risk factor that is summed
in to give a final risk result.
%A component failure mode, given its MTTF
%the probability of detecting the fault and its safety relevant validation time $\tau$,
%contributes a simple risk factor that is summed
%in to give a final risk result.
%
Thus a statistical
model can be implemented on a spreadsheet, where each component
@ -408,14 +474,15 @@ safety level zones \cite{en61508}. This is a vague way of determining
safety.
The Statistical Analysis methodology is the core philosophy
of the Safety Integrity Levels (SIL) of EN61508 \cite{en61508}.
of the Safety Integrity Levels (SIL) ebodied in EN61508 \cite{en61508}
and its international analog standard IOC5108.
\subsubsection{ FMEDA weaknesses }
\begin{itemize}
\item Possibility to miss the effects of failure modes at SYSTEM level.
\item Statistical nature allows critical failures considered acceptable for given S.I.L. level.
\item Statistical nature allows a proportion of undetected failures for given S.I.L. level.
\item Allows a small proportion of `undetectable' error conditions.
\item No possibility to model base component level double failure modes.
\end{itemize}
@ -427,14 +494,9 @@ of the Safety Integrity Levels (SIL) of EN61508 \cite{en61508}.
\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
\item It should have a formal basis, that is to say, it should be able to produce mathematical proofs
for its results.
\item It should be capable of producing reliability and danger evaluation statistics.
for its results, such as system level error causation trees, reliability and safety statistics.
\item It should be easy to use, Ideally using a graphical syntax (as oppossed to a formal mathematical one).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
for its results.
\item It should be capable of producing reliability and danger evaluation statistics.
\item It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
to smaller and smaller functional modules \cite{maikowski}.
\item Multiple failure modes may be modelled from the base component level up.
\end{itemize}
@ -482,7 +544,8 @@ Top down de-compositon applies functional
de-composition, because it seeks to break the system down
into manageable and separately testable entities.
A second justification for this is that the design process for a product requires both top down and bottom-up
thinking.
thinking. To analyse a system from the bottom-up is a useful
design validatio process in itself \cite{sommerville}.
\paragraph{Problem with functional group hierarchy}
@ -550,7 +613,7 @@ failure mode behaviour, but can check that all failure modes in
the hierarchy have been considered and tied to causing symptoms.
\paragraph{Incremental Stages and {\dcs}}.
\paragraph{Incremental Stages and \dcs}.
We can use incremental stages to build the hierarchy.
We can take small {\fg}s of components, where the {\fg}
is a small set of components that perform a simple
@ -594,7 +657,8 @@ the number of failure modes decreases (or exceptionally stays the same) at each
%
This decreasing of the number of failure modes is bourne out {\irl}.
Of the thousands of component failure modes in a typical product
there are generally only a handful of SYSTEM level failure modes.
there are generally only a handful of SYSTEM level failure modes
(or top level `symptoms' of underlying failures).
%
\subsection{Outline of the FMMD process}