morning edit

This commit is contained in:
Robin Clark 2011-03-16 09:05:08 +00:00
parent a734d0eae7
commit 839da93a3e
3 changed files with 54 additions and 21 deletions

View File

@ -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

View File

@ -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}

View File

@ -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