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

Got a tummy bug, felt awful all day been sleeping alot

Browse Source
This commit is contained in:
Robin Clark 2013-08-31 18:47:56 +01:00
parent d45b60d8aa
commit ded619e4de
2 changed files with 96 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
submission_thesis/CH2_FMEA/copy.tex
View File

@ -1320,63 +1320,56 @@ $ \sum \lambda_{SD}$, $\sum \lambda_{SU}$, $\sum \lambda_{DD}$, $\sum \lambda_{D
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. $\Sigma\lambda_{DD}$ represents
and is normally expressed as a percentage~\cite{en61508}[2-Annex C].
%
$\Sigma\lambda_{DD}$ represents
the percentage of dangerous detected base component failure modes, and
$\Sigma\lambda_D$ the total number of dangerous base component failure modes.
%
$$ DiagnosticCoverage = \Sigma\lambda_{DD} / \Sigma\lambda_D $$
\fmmdglossFMEDA
%
%
%
%\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
The \textbf{diagnostic coverage} for safe failures, where $\Sigma\lambda_{SD}$ represents the percentage of
safe detected base component failure modes,
and $\Sigma\lambda_S$ the total number of safe base component failure modes,
is given as
%
$$ SF = \frac{\Sigma\lambda_{SD}}{\Sigma\lambda_S} $$
%
%
%
%\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
\textbf{Safe Failure Fraction.}
A key concept in FMEDA is Safe Failure Fraction (SFF).
This is the ratio of safe and dangerous detected failures
against all 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) $$
%
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.
\fmmdglossFMEDA
%
%
%
\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 aim of SIL is to classify the safety of a system,
by statistically determining how frequently it can fail dangerously.
\fmmdglossFMEDA
%
%
%\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
%\subsection{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
%FMEA can be used as a term simple to mean Failure Mode Effects Analysis, and is
%part of product approval for many regulated products in the EU and the USA...
%
\section{FMEA used for Safety Critical Approvals}
\fmmdglossDFMEA
\subsection{DESIGN FMEA: Safety Critical Approvals FMEA}
@ -1395,9 +1388,9 @@ judged to be in critical sections of the product.
%
This could be considered as a design check method, deliberately
looking for weaknesses at a theoretical level.
%
\subsection{DESIGN FMEA: Safety Critical Approvals FMEA}
%
% \begin{figure}[h]
% \centering
% \includegraphics[width=70pt,keepaspectratio=true]{./tech_meeting.png}
@ -1405,14 +1398,14 @@ looking for weaknesses at a theoretical level.
% \caption{FMEA Meeting}
% \label{fig:tech_meeting}
% \end{figure}
%
\begin{itemize}
\item Impossible to look at all component failures let alone apply FMEA exhaustively/rigorously.
\item In practice, failure scenarios for critical sections are contested, and either justified or extra safety measures implemented.
\item Often Meeting notes or minutes only. Unusual for detailed technical arguments to be documented.
\end{itemize}
%
%
\section{Conclusion}
\begin{figure}[h]
\centering
@ -1421,15 +1414,15 @@ looking for weaknesses at a theoretical level.
\caption{FMEA UML data representation with subjective system level failure modes.}
\label{fig:component_fm_rel_ana_subj_obj}
\end{figure}
%
Returning to the FMEA model, we now show that the data relationships shown in
figure~\ref{fig:component_fm_rel_ana} hold for the five variants of FMEA discussed.
We can however, extend this
with subjective failure mode symptoms (see figure~\ref{fig:component_fm_rel_ana_subj_obj}).
%
The UML data model reveals some undefined qualities of FMEA.
These raise questions and are discussed below.
%
\paragraph{Which, or how many components should we check for each {\fm} entry?}
For instance a given {\fm} will have its effect measured in relation
to some of the components in the system.
@ -1453,8 +1446,8 @@ FMEDA classifies them as dangerous or safe failures.
FMECA gives us a statistically biased criticality level.
In both of these methodologies however, there is no formal stage where we map from an objective to subjective
system failure, the processes are intertwined with the basic analysis itself.
%
%
\paragraph{Re-use potential of an FMEA report.}
Each {\fm} entry in an FMEA report should have a reasoning or comments field.
This should provide a guide to someone re-examining, or trying to re-use results
@ -1470,7 +1463,7 @@ so that the entry can be more easily reviewed or revisited/audited than a tradit
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 often be started from `cold'.
%
% MOVED TO CH3: 15MAR2013
%
% \section{Conclusions on current FMEA Methodologies}

96
submission_thesis/CH8_Conclusion/copy.tex
View File

@ -139,7 +139,7 @@ we can %therefore
use FMMD to produce an FMEDA report.
\paragraph{Pt100 Example: Single Failures and statistical data} %Mean Time to Failure}
\paragraph{Pt100 Example: Single Failures and statistical data.} %Mean Time to Failure}
From an earlier example, the model for the failure mode behaviour of the Pt100 circuit,
we can add {\bc} {\fm} statistics and determine the probability of symptoms of failure.
@ -155,11 +155,11 @@ can give conservative reliability figures when applied to
modern components}.
%
Using the MIL-HDBK-217F\cite{mil1991} specifications for resistor and thermistor
failure statistics, we calculate the reliability of the Pt100 example (see section~\ref{sec:Pt100}).
\paragraph{Resistor FIT Calculations}
failure statistics, the reliability for the Pt100 example (see section~\ref{sec:Pt100}) is calculated below.
%
%
\paragraph{Resistor FIT Calculations.}
%
The formula given in MIL-HDBK-217F\cite{mil1991}[9.2] for a generic fixed film non-power resistor
is reproduced in equation \ref{resistorfit}. The meanings
and values assigned to its co-efficients are described in table \ref{tab:resistor}.
@ -248,10 +248,10 @@ resistor{\lambda}_p = {\lambda}_{b}{\pi}_Q{\pi}_E
\label{eqn:thermistor}
\end{equation}
%
Thus thermistor, bead type, `non~military~spec' is given a FIT of 315.0
Thus thermistor, bead type, `non~military~spec' is given a FIT of 315.0.
%
Using the RIAC finding we can draw up the following table (table \ref{tab:stat_single}),
showing the FIT values for all faults considered.
showing the FIT values for all single failure modes.
%\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.}}
\fmmdglossFIT
%
@ -282,7 +282,7 @@ TC:6 $R_2$ OPEN & High Fault & High Fault & 12.42 \\ \hline
%
The FIT for the circuit as a whole is the sum of MTTF values for all the
test cases. The Pt100 circuit here has a FIT of 342.6. This is a MTTF of
about 360 years per circuit.
about $\approx 360$ years per circuit.
%
A probabilistic tree can now be drawn, with a FIT value for the Pt100
circuit and FIT values for all the component fault modes from which it was calculated.
@ -303,8 +303,8 @@ be the fault~mode we would scrutinise first.
The Pt100 analysis presents a simple result for single faults.
The next analysis phase looks at how the circuit will behave under double simultaneous failure
conditions.
%
%
\paragraph{Pt100 Example: Double Failures and statistical data}
Because we can perform double simultaneous failure analysis under FMMD
we can also apply failure rate statistics to double failures.
@ -319,13 +319,13 @@ 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 the electronic examples chapter~\ref{sec:chap5} table~\ref{tab:ptfmea2}.
the FIT values for all the combinations
failures in the electronic examples from chapter~\ref{sec:chap5} in table~\ref{tab:ptfmea2}.
%
The failure mode of concern, the undetectable {\textbf{FLOATING}} condition
requires that resistors $R_1$ and $R_2$ fail.
The failure mode of most concern, the undetectable {\textbf{FLOATING}} condition,
requires that resistors $R_1$ and $R_2$ both fail.
%
We can multiply the MTTF
together and find an MTTF for both failing.
We can multiply the MTTF probabilities for these types of resistor failing and find the 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} $.
@ -338,9 +338,16 @@ because here we have found a fault that we cannot detect (at least at this
level in the FMMD hierarchy).
%
This means that should we wish to cope with
this fault, we need to devise a new way of detecting this
this fault, we need to engineer a new way of detecting this
condition, perhaps in higher levels of the system/FMMD hierarchy.
%
\paragraph{MTTF statistics and FMMD hierarchies.}
In a large FMMD model, system/top level failures can be traced
down to {\bc} {\fms}. To determine the MTTF probability
for a system level failure, we add the MTTF statistics for all its possible causes.
Thus even for large FMMD models we can calculate accurate
statistics for electronic sourced failures.
%
%\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}}}
%
\fmmdglossFIT
@ -373,8 +380,8 @@ useful in guiding diagnostic analysis.}.
\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.
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.
%
@ -409,7 +416,9 @@ 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.}.
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 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}.
@ -458,9 +467,9 @@ 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.}
@ -481,9 +490,14 @@ are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref
\subsection{Retrospective Failure Mode analysis and FMMD}
The reasons for applying retrospective failure mode analysis could be approving previously un-assessed
systems to a safety standard, or to determine the failure mode behaviour of an instrument used in
safety critical verification. % verification.
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 h/w or s/w change,
\item upon discovery of a new {\bc} {\fm},
\item or to determine the failure mode behaviour of an previously un-assessed 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
@ -500,7 +514,10 @@ Because we can enforce a `complete' analysis, FMMD can find failure modes were m
other FMEA processes; meaning that the FMMD process can expose un-handled
failure modes.
%come to light.
\paragraph{Retrospective Failure Mode analysis and software}
%
%
\paragraph{Retrospective Failure Mode analysis and software.}
%
We can apply retrospective FMMD to electronic and software hybrid systems as well.
%
The electronic components {\fms} are established in the literature~\cite{fmd91,mil1991,en298,en230}.
@ -509,21 +526,34 @@ Each function in the software would have to be assigned a `design~contract'~\cit
contract clauses will be treated as failure modes in FMMD).
\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
re-visit.
%
For instance, which components in the system should
we check against this newly discovered failure mode?
%
This 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}).
%
\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 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.
%
This 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
@ -538,7 +568,9 @@ we can thus verify that all
failure modes from the electronics module have been dealt
with by the controlling software.
%
If not they are an un-handled error condition relating to the software hardware interface.
If not, they 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
@ -600,5 +632,9 @@ FMEDA~\cite{en61508,fmeda} with its classification of dangerous and safe failure
\fmmdglossFMEDA
\fmmdglossFMECA
%
It is the author's opinion that more work is required to clarify this area. The scope of FMMD is the objective level only.
It is the author's opinion that more work is required to clarify this area. The scope of FMMD is the objective level only.
Accurate models of objective failure modes, are seen by the author to be a pre-requisite
for subjective assessment.
\today