morning edit
This commit is contained in:
parent
a734d0eae7
commit
839da93a3e
@ -391,51 +391,73 @@ and unused available zones.
|
||||
|
||||
\section{Context, functional groups, failure modes and symptoms}
|
||||
|
||||
The intended application of these diagrams, is to model failure modes
|
||||
of collection of components, or {\fgs}. The aim is to
|
||||
create a derived component that represents the {\fg}.
|
||||
PLD diagrams are designed to aid this process.
|
||||
% Asterisks represent combinations of failure
|
||||
%modes. These are failure mode scenarios, or `test~cases'.
|
||||
|
||||
\input{shortfg}
|
||||
|
||||
\subsection{Symptom Collection}
|
||||
|
||||
\paragraph{Failure Mode Modular De-Composition (FMMD).}
|
||||
The methodology using these propositional logic diagrams is concerned with
|
||||
taking functional groups of components, analysing how the functional group
|
||||
can fail, and then deriving a failure mode model for the functional group
|
||||
so that we can treat it as a component in its own right, or as a `derived component'
|
||||
|
||||
\paragraph{From component failure modes to {\fg} failure modes.}
|
||||
We represent the failure
|
||||
modes of the components within a {\fg} as contours in the diagram.
|
||||
The test cases represent combinations of component failure modes
|
||||
within the functional group.
|
||||
The test cases, when analysed can be grouped into $SMG$s.
|
||||
The SMG, Symptomatically merged group, is a collection of test
|
||||
cases where the failure symptom is the same.
|
||||
within the functional group. These are drawn as asterisks on the diagram.
|
||||
%
|
||||
Each SMG
|
||||
The test cases, when analysed can be grouped into $SMG$s.
|
||||
The $SMG$, Symptomatically merged group, is a collection of test
|
||||
cases where their failure symptoms, from the perspective of the {\fg}, is the same.
|
||||
%
|
||||
Each $SMG$
|
||||
defines a failure mode behaviour of the functional group as though the
|
||||
{\fg} were considered as a high level component.
|
||||
%
|
||||
As we may be interested in treating the functional group
|
||||
and a component to model higher levels of design, or failure mode abstraction,
|
||||
as a {\dc} to model higher levels of design, or failure mode abstraction,
|
||||
we can derive a new diagram from the $SMG$s. Each $SMG$ represents a failure
|
||||
mode of the functional group, therefore in the higher level diagram
|
||||
each SMG is represented by a contour.
|
||||
each $SMG$ is represented by a contour.
|
||||
|
||||
{
|
||||
\definition{
|
||||
\label{SMGderivation}
|
||||
%A diagram can be drawn to represent the collection of $SMG$s.
|
||||
The diagram $d$ represents $SMG$s as graphs of asterisks connected with joining lines.
|
||||
A new diagram can be derived from this, replacing each SMG with a contour in the new diagram.
|
||||
A new diagram can be derived from this, replacing each $SMG$ with a contour in the new diagram.
|
||||
This diagram is at one higher level of failure~mode abstraction than the diagram that
|
||||
it was produced from.
|
||||
This diagram is the `symptom collection' diagram derived form $d$.
|
||||
}
|
||||
}
|
||||
\subsection{Derived Component}
|
||||
|
||||
\paragraph{Derived Component.}
|
||||
The diagram $d$ represents the failure modes of a functional group,
|
||||
with the joining lines defining the its symptom collection.
|
||||
The `symptom collection' respresents the functional group
|
||||
at a higher level of failure mode abstraction. It represents the
|
||||
{\fg} as a higher level component, or {\textbf{derived component}}, with a defined set of failure modes.
|
||||
The `symptom collection' represents the functional group
|
||||
at a higher level of failure mode abstraction. That is to say,
|
||||
the contours in the new diagram represent the ways in which the {\fg} considered
|
||||
as an entity can fail. The new represents the
|
||||
{\fg} as a higher level component, or {\textbf{derived component}}, with its own set of failure modes.
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
% ref symptom extraction process paper HERE
|
||||
}
|
||||
{
|
||||
Chapter \ref{chap:sympex} describes the symptom abstraction process, detailing algorithms and
|
||||
validation and consistency checks applied.
|
||||
}
|
||||
|
||||
|
||||
\section{Example Diagrams}
|
||||
|
||||
@ -503,7 +525,7 @@ sub-system failures, for instance two fuel shutdown safety valves failing to clo
|
||||
% reference gas shutoff valve closure example
|
||||
%
|
||||
|
||||
\clearpage
|
||||
%\clearpage
|
||||
\subsection { Logical XOR example }
|
||||
|
||||
\begin{figure}[h]
|
||||
@ -556,7 +578,7 @@ under analysis.
|
||||
|
||||
|
||||
|
||||
\clearpage
|
||||
%\clearpage
|
||||
\subsection {Labels and usage}
|
||||
|
||||
%In diagram \ref{fig:ld_meq} Z and W were labelled but were not necessary for the final expression
|
||||
@ -624,7 +646,7 @@ of $ R = b \oplus c $.
|
||||
In failure analysis, this could be considered to be a functional~group with three failure states $a$,$b$ and $c$.
|
||||
It has three SMG's Q,R and P. Thus there are three ways in which this functional~group is considered to fail.
|
||||
|
||||
\clearpage
|
||||
%\clearpage
|
||||
|
||||
|
||||
|
||||
@ -688,9 +710,10 @@ by the FMMD software tool.
|
||||
|
||||
|
||||
|
||||
\clearpage
|
||||
%\clearpage
|
||||
|
||||
|
||||
\pagebreak[3]
|
||||
\subsection { Inhibit Failure }
|
||||
|
||||
%
|
||||
@ -914,6 +937,15 @@ The act of collecting common symptoms by joining lines is seen more intuitive
|
||||
than lists of logic equations. % seen as BY ME ! HA !
|
||||
It also neatly by-passes the problem of having test cases
|
||||
which could inadvertently be placed into more than one $SMG$.
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
% explain unitary state failure modes here? I'd rather not have to in the `paper' version.... 16MAR2011
|
||||
}
|
||||
{
|
||||
Having $SMG$s share test~cases would violate the concept of unitary state
|
||||
failure modes (see \ref{sec:unitarystate}).
|
||||
}
|
||||
|
||||
Syntax checking (looking for contradictions and tautologies), as well as detecting
|
||||
errors of omission are automated in the FMMD tool.
|
||||
|
||||
@ -954,7 +986,7 @@ configuration is being termed \textbf{pair-wise intersection} of contours, in th
|
||||
A PLD editor can be set to ensure that each diagram has a test case for every
|
||||
double simultaneous failure instance.
|
||||
|
||||
\clearpage
|
||||
\pagebreak[3]
|
||||
\section{N Simultaneous Errors}
|
||||
|
||||
There are systems where it may be necessary to model for N simultaneous failures.
|
||||
@ -1013,4 +1045,5 @@ The test case AFE represents the condition where all four engines have failed \c
|
||||
%\theend
|
||||
|
||||
|
||||
|
||||
%\pagebreak[4]
|
||||
\clearpage
|
@ -23,8 +23,8 @@
|
||||
%\fancyfoot[LE,RO]{\thepage}
|
||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||
\rfoot{\today}
|
||||
\lhead{Propositional Logic Diagram FMMD}
|
||||
|
||||
\lhead{Propositional Logic Diagram }
|
||||
\rhead{FMMD - Failure Mode Modular De-Composition}
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
|
@ -8,7 +8,7 @@ of components `functional groups'.
|
||||
%
|
||||
For instance we may have a handful of components
|
||||
brought together to perform a simple function
|
||||
like amplifying a signal or a power supply.
|
||||
like a `signal amplifier' or a `power supply'.
|
||||
%
|
||||
The components in a {\fg} can be considered
|
||||
to be `functionally~adjacent' to each other, in that
|
||||
|
Loading…
Reference in New Issue
Block a user