morning edit spell check.
SOON: Chap 5 to bton for chris garret Chap 7 to J Howse
This commit is contained in:
parent
ed71fc00f3
commit
860607b1ef
@ -563,9 +563,11 @@ model can be implemented on a spreadsheet, where each component
|
||||
has a calculated risk, a fault detection time (if any), an estimated risk importance
|
||||
and other factors such as de-rating and environmental stress.
|
||||
With one component failure mode per row,
|
||||
all the statistical factors for SIL rating can be produced\footnote{A SIL rating will apply
|
||||
to an installed plant, i.e. a complete installed and working SYSTEM. SIL ratings for individual components or
|
||||
sub-systems are meaningless, and the nearest equivalent would be the FIT/PFD and SFF and diagnostic coverage figures.}.
|
||||
all the statistical factors for SIL rating can be produced\footnote{A SIL rating will
|
||||
apply to an installed plant, i.e. a complete installed and working SYSTEM.
|
||||
SIL ratings for individual components or
|
||||
sub-systems are meaningless, and the nearest equivalent would be the
|
||||
FIT/PFD and SFF and diagnostic coverage figures.}.
|
||||
|
||||
|
||||
|
||||
@ -622,14 +624,14 @@ 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 a proportion of undetected failures for given S.I.L. level. These could be catostophic failures, as long as the percieved probability is low enough, they are considered acceptable for EN61508.
|
||||
\item Statistical nature allows a proportion of undetected failures for given S.I.L. level. These could be catastrophic failures, as long as the perceived probability is low enough, they are considered acceptable for EN61508.
|
||||
\item Complex component interaction effects are more likely to be seen (because self diagnostic capability is considered), than FMEA or FMECA but can still be missed.
|
||||
\item Allows a small proportion of `undetectable' error conditions.
|
||||
\item No possibility to model base component level double failure modes.
|
||||
\end{itemize}
|
||||
%AND then how we can solve all there problems
|
||||
|
||||
\section{A wish list for a failure mode methodolgy}
|
||||
\section{A wish list for a failure mode methodology}
|
||||
\begin{itemize}
|
||||
\item All component failure modes must be considered in the model.
|
||||
\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
|
||||
@ -637,7 +639,7 @@ and its international analog standard IOC5108.
|
||||
\item It should have a formal basis, that is to say, be able to produce mathematical proofs
|
||||
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 symbolic/mathematical text based language).
|
||||
graphical syntax (as opposed to a formal symbolic/mathematical text based language).
|
||||
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
|
||||
to smaller and smaller functional groupings \cite{maikowski}.
|
||||
\item Multiple failure modes may be modelled from the base component level up.
|
||||
@ -682,8 +684,8 @@ and ensure they are included in the model.
|
||||
By taking components that form {\fg}s from the bottom up
|
||||
and then taking those to form higher level
|
||||
{\fg}s we can get a close approximation of the de-composition process from the bottom up.
|
||||
The philosophy of top down de-compositon is very similar.
|
||||
Top down de-compositon applies functional
|
||||
The philosophy of top down de-composition is very similar.
|
||||
Top down de-composition 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
|
||||
@ -691,7 +693,7 @@ thinking. To analyse a system from the bottom-up is a useful
|
||||
design validation process in itself \cite{sommerville}.
|
||||
%%
|
||||
%% CAN we find a ref for both top and bottom up being used
|
||||
%% as design validaion ????
|
||||
%% as design validation ????
|
||||
|
||||
\paragraph{Design Decision: Methodology must be bottom-up.}
|
||||
In order to ensure that all component failure modes are handled,
|
||||
@ -877,7 +879,7 @@ there is a phase of symptom collection.
|
||||
We can use the symbol $alpha$ to represent the abstraction level
|
||||
and make it an attribute of a component.
|
||||
Base components will have an $\alpha$ level of zero.
|
||||
A derived component when created must alwayave a graater $\alpha$ value than any
|
||||
A derived component when created must always have a greater $\alpha$ value than any
|
||||
of the components included in the {\fg} from which it was derived.
|
||||
|
||||
|
||||
@ -908,7 +910,7 @@ 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 implemenent the process in software we can
|
||||
modes within a {\fg}. Because we can implement the process in software we can
|
||||
thus ensure that all component failure modes
|
||||
are included in the model.
|
||||
%
|
||||
@ -960,7 +962,7 @@ create higher level {\fg}s in later stages.
|
||||
% \end{figure}
|
||||
%
|
||||
% \vspace{20pt}
|
||||
% NEED DIAGRAM OF HIERACY
|
||||
% NEED DIAGRAM OF HIERARCHY
|
||||
% \vspace{20pt}
|
||||
|
||||
We associate a component with its failure modes.
|
||||
@ -1101,11 +1103,11 @@ are built from components performing a given task.
|
||||
By breaking the problem of failure mode analysis into small stages
|
||||
and building a hierarchy, the problems associated with the cross products of
|
||||
all failure modes within a system are reduced by an exponential order.
|
||||
This is because the mutliple failure modes are considered
|
||||
This is because the multiple failure modes are considered
|
||||
within {\fgs} which have fewer failure modes to consider
|
||||
at each FMMD stage.
|
||||
Where appropriate, multiple simultaneous failures can be modelled by
|
||||
intoducing test~cases where the conjunction of failure modes is considered.
|
||||
introducing test~cases where the conjunction of failure modes is considered.
|
||||
|
||||
\subsubsection {Inhibit Conditions}
|
||||
Some failure modes only occur when another failure has occurred, or
|
||||
@ -1242,7 +1244,7 @@ The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}.
|
||||
{
|
||||
% chapter
|
||||
\section{Re-Factoring the UML Model}
|
||||
This chapter has used UML diagrams to develop the data types required to implment FMMD.
|
||||
This chapter has used UML diagrams to develop the data types required to implement FMMD.
|
||||
The terms used in FMMD and the UML data model are further refined in
|
||||
chapter \ref{defs}.
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user