lunch time proof read and edit
This commit is contained in:
parent
d81ea97c01
commit
554f584203
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user