lunch time proof read and edit

This commit is contained in:
Robin Clark 2011-01-17 14:09:59 +00:00
parent d81ea97c01
commit 554f584203

View File

@ -135,7 +135,8 @@ of components, {\fgs}, and then analysing how they can fail.
\input{./shortfg}
\paragraph{Micro Vs. Macro failure mode analysis.}
This analysis is performed using FMEA from a micro rather than a macro perspective.
The FMMD analysis is performed using failure mode effects analysis
from a micro rather than a macro perspective.
Thus instead of looking at component failure modes and determining how
they {\em may} cause a failure at SYSTEM level, we are looking at how
they {\em will} affect the component's local {\fg}.
@ -198,7 +199,7 @@ and therefore human judgement must be used to
decide which interactions could be important.
Let N be the number of components in our system, and K be the average number of component failure modes
(ways in which the base~component can fail). The total number of base component failure modes
(ways in which a base~component can fail). The total number of base component failure modes
is $N \times K$. To examine the effect that one failure mode has on all
the other components\footnote{A base component failure will typically affect the sub-system
it is part of, and create a failure effect at the SYSTEM level.}
@ -230,7 +231,8 @@ For instance looking at double simultaneous failure modes, where $\#C$
is the number of checks to perform
the equation reads $\#C = (N-2) \times (N-1) \times N \times K \times E$.
The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes and link them
The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes\footnote{Often component failures, rather than individual component
failure modes are used, making the analysis process less precise.} and link them
to SYSTEM level failure modes. Because of the astronomical number of possible interactions,
some valid ones are in danger of being missed, we can term this analysis as a `leap~of~faith'
(i.e. leaping from from the
@ -273,9 +275,9 @@ Consequently it was not designed to guarantee to covering all component failure
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.
This increase the amount of work to do, and in the case of updates to
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 sub-system.
tree modelling that use the affected sub-system.
\subsubsection{ FTA weaknesses }
\begin{itemize}
@ -407,7 +409,8 @@ to succeeding to operate correctly on demand.
}
{
FMEDA is a statistical analysis methodology and is used from one of two perspectives,
Probability of Failure on Demand (PFD) (see \ref{survey:pfd}), and Probability of Failure
Probability of Failure on Demand (PFD) (see \ref{survey:pfd})
, and Probability of Failure
in continuous Operation, or Failure in Time (FIT) (see \ref{survey:fit}).
}
@ -420,7 +423,11 @@ Each component is analysed in terms of how its failure
would affect the system.
Failure rates of individual components in the SYSTEM
are calculated based on component type and
environmental conditions. The SYSTEM errors are categorised as `safe' or `dangerous'.
environmental conditions.
%The SYSTEM errors are categorised as `safe' or `dangerous'.
%
%Statistical data exists for most component types \cite{mil1992}.
%
@ -457,7 +464,7 @@ based on heuristics or field data.
\paragraph{Determine Detectable and Undetectable Failures.}
Each safe and dangerous failure mode is now
classified as detectable or un-detectable.
For the higher integrity levels, EN61508 assumes that products have a high proportion of
For the higher integrity levels, EN61508 requires that products have a high proportion of
self checking features.
%
This gives us four level failure mode classifications:
@ -676,7 +683,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. The natural way to
There is an apparent conflict here as de-composition ormally 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
@ -716,8 +723,10 @@ The base components will typically have several failure modes each.
Given a typical embedded system may have hundreds of components,
this means that we would still have to tie base component failure modes
to SYSTEM level errors.
%
The problem with this is that the base component failure mode under investigation,
effects are not rigorously examined in relation to functionally adjacent components.
are not rigorously examined in relation to functionally adjacent components.
%
Thus there is the `possibility to miss failure mode effects
at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies.
%%%
@ -798,6 +807,9 @@ In this way as we build the hierarchy, we naturally abstract the
failure mode behaviour, but can check that all failure modes in
the hierarchy have been considered and tied to causing symptoms.
\paragraph{Design Decision: Derived components can be determined from functional groups}
The symptoms obtained from analysing a {\fg} will be used as the `failure~modes'
of its corresponding {\dc}.
\paragraph{Incremental Stages and \dcs .}
We can use incremental stages to build the hierarchy.
@ -871,7 +883,7 @@ a SYSTEM level error this is usually considered a liability.})
can be used to calculate Mean Time to Failure (MTTF) or
Probability of Failure on demand (PFD) figures.
Contrast the analytical capability of FMMD with the
methodologies where the component failure modes are linked
methodologies where the component failure modes/components are linked
directly to SYSTEM failure modes with no analysis stages in between.
@ -917,8 +929,8 @@ Functional groups are collections of components
that work together to perform a simple function.
%
We can perform a failure mode effects analysis on each of the component failure
modes within a {\fg}. Because we can implement the process in software we can
thus ensure that all component failure modes
modes within a {\fg}. Because we can guide the process in software we can
ensure that all component failure modes
are included in the model.
%
We can then treat the {\fg} as a `black box' or component in its own right.