Changed all the diagrams to make zones consistent in the examples.
@ -1,4 +1,4 @@
|
||||
PDF_READER = acroread
|
||||
PDF_READER = okular
|
||||
#
|
||||
# Make the propositional logic diagram a paper
|
||||
#
|
||||
|
Before Width: | Height: | Size: 8.8 KiB After Width: | Height: | Size: 8.7 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
@ -127,7 +127,8 @@ All features may be labelled, and the labels must be unique within a diagram, ho
|
||||
|
||||
%Regions defined by contours are used to represent given conjunctive logical conditions.
|
||||
|
||||
Test~cases are marked by asterisks. These are used as a visual `anchor'
|
||||
Test~cases are marked by asterisks. The asterisk is used rather than a point, because is analogous to the constraint
|
||||
diagram universal qualifier~\cite{uconstraintd}. These are used as a visual `anchor'
|
||||
to mark a logical condition, the logical condition being defined by the contours
|
||||
that enclose the region on which the test~case has been placed.
|
||||
The contours that enclose represent conjunction.
|
||||
@ -136,7 +137,7 @@ test~cases.
|
||||
|
||||
With these three visual syntax elements, we have the basic building blocks for all logic equations possible.
|
||||
\begin{description}
|
||||
\item Test cases - Points (asterisks) on the plane indicating a logical condition.
|
||||
\item Test cases - (asterisks) on the plane indicating a logical condition.
|
||||
\item Conjunction - Overlapping contours
|
||||
\item Exclusive Disjunction - Joining of named test~cases.
|
||||
%\item Negation - Countours negatively named
|
||||
@ -266,7 +267,7 @@ associating a test-point with a set of contours in the plane. This corresponds t
|
||||
|
||||
Pairs of test cases may be joined by joining lines.
|
||||
The operator $\stackrel{join}{\leftrightarrow}$ is used to
|
||||
show that two points are joined by a line in the concrete diagram.
|
||||
show that two test~cases are joined by a line in the concrete diagram.
|
||||
|
||||
{
|
||||
\definition{
|
||||
@ -280,7 +281,7 @@ associating a joining line with a pair of test cases. The Join t1,t2 is defined
|
||||
}
|
||||
|
||||
%In English:
|
||||
Test points on the concrete diagram pair-wise connected by a `joining line'
|
||||
Test~cases on the concrete diagram pair-wise connected by a `joining line'
|
||||
|
||||
The graph formed by test~cases connected by joining lines is called an $SMG$.
|
||||
%A collection of test cases connected by joining lines, is an Symptom Merged Group, $SMG$
|
||||
@ -387,7 +388,7 @@ $$\mathcal{G}(fmg) = \bigoplus_{t \in fmg} (\; \mathcal{F}_{t} (t) \;) \; .$$
|
||||
|
||||
The semantics of the diagram is the set of logic terms representing all its SMGs,
|
||||
along with unused zones (i.e. zones that are not inhabited by SMGs).
|
||||
Thus the abstract representation of the diagram, becomes a list of logic terms
|
||||
Thus the interpretation of the diagram, is a list of logic terms
|
||||
% and unused available zones
|
||||
.
|
||||
|
||||
@ -433,6 +434,9 @@ 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.
|
||||
|
||||
|
||||
\input{fmmdstereoexample}
|
||||
|
||||
{
|
||||
\definition{
|
||||
\label{SMGderivation}
|
||||
@ -477,9 +481,9 @@ validation and consistency checks applied.
|
||||
PLD diagrams are read by first looking at the test case asterisks.
|
||||
The test case asterisk will be enclosed by one or more contours.
|
||||
These contours are collated and used to form the logical conjunction
|
||||
equation for the test case.
|
||||
These test case points thus represent the conjunctive aspects
|
||||
of an equation defined in a PLD. Where these test cases are joined by lines;
|
||||
term for the test case.
|
||||
These test~cases thus represent the conjunctive aspects
|
||||
of an term defined in a PLD. Where these test cases are joined by lines;
|
||||
these represent disjunction of the conjunctive aspects defined by the test cases.
|
||||
Joining lines thus represent exclusive disjunction in a PLD.
|
||||
|
||||
@ -511,14 +515,14 @@ Joining lines thus represent exclusive disjunction in a PLD.
|
||||
\end{figure}
|
||||
|
||||
|
||||
In the diagram \ref{fig:ld_and} the area of intersection between the contours $a$ and $b$
|
||||
In the diagram \ref{fig:ld_and} the area of intersection between the contours $a$ and $c$
|
||||
represents the conjunction of those conditions. The point $P$ represents the logic equation
|
||||
$$ P = (a \wedge b) $$
|
||||
$$ P = (a \wedge c) $$
|
||||
There are no joining lines % and so this diagram represents one equation only, $ P = (a \wedge b) $.
|
||||
and this diagram represents an $SMG$ with one element. %, $ (a \wedge b) $
|
||||
|
||||
\paragraph{How this would be interpreted in failure analysis}
|
||||
In failure analysis, this could be considered to be a functional~group with two failure states $a$ and $b$.
|
||||
In failure analysis, this could be considered to be a functional~group with two failure states $a$ and $c$.
|
||||
The proposition $P$ considers the scenario where both failure~modes are active.
|
||||
|
||||
For base component level analysis, this would be considering two base component failures
|
||||
@ -541,35 +545,15 @@ sub-system failures, for instance two fuel shutdown safety valves failing to clo
|
||||
\label{fig:ld_or}
|
||||
\end{figure}
|
||||
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[width=250pt]{logic_diagram/ldor.jpg}
|
||||
% % ldor.jpg: 476x264 pixel, 72dpi, 16.79x9.31 cm, bb=0 0 476 264
|
||||
% \label{fig:ld_or}
|
||||
% \caption{Logical XOR example PLD diagram}
|
||||
% \end{figure}
|
||||
|
||||
% \begin{figure}[h+]
|
||||
% %\centering
|
||||
% %\input{ldor.tex}
|
||||
% \begin{center}
|
||||
% \includegraphics[width=200pt,bb=0 0 450 404]{logic_diagram/ldor.jpg}
|
||||
% % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
|
||||
% \end{center}
|
||||
% %\includegraphics[scale=0.60]{ldor.eps}
|
||||
% \caption{Logical OR}
|
||||
% \label{fig:ld_or}
|
||||
% \end{figure} % OR
|
||||
|
||||
|
||||
The diagram \ref{fig:ld_or} is converted to propositional logic by first looking at the test cases, and
|
||||
the zones they are placed in.
|
||||
$$ P = (a) $$
|
||||
$$ Q = (b) $$
|
||||
$$ S = (a) $$
|
||||
$$ U = (b) $$
|
||||
|
||||
The two test cases are joined by a the line named $R$.
|
||||
We thus apply exclusive disjunction to the test cases:
|
||||
$$ R = P \oplus Q \; . $$
|
||||
$$ R = S \oplus U \; . $$
|
||||
substituting the test cases for their propositional logic equations gives
|
||||
\begin{equation}
|
||||
R = ((a) \oplus (b)) \; .
|
||||
@ -580,6 +564,7 @@ substituting the test cases for their propositional logic equations gives
|
||||
Equation \ref{eqn:l_or} would be interpreted to mean that
|
||||
either failure mode a or b occurring, would have the same failure symptom for the circuit/functional~group
|
||||
under analysis. If $a \wedge b$ occurred this could have a completely different failure mode symptom.
|
||||
The SMG $R$, says if either failure modes $a$ or $b$ occur singly, they have the same failure symptom.
|
||||
|
||||
|
||||
|
||||
@ -595,9 +580,9 @@ under analysis. If $a \wedge b$ occurred this could have a completely different
|
||||
%two unnamed test cases.
|
||||
|
||||
Diagram \ref{fig:ld_meq2}
|
||||
shows three test~cases, Q, R and P.
|
||||
shows three test~cases, U, R and P.
|
||||
|
||||
Z and W were labelled but this was not necessary for determination of the final expression
|
||||
S and T were labelled, but this was not necessary for determination of the final expression
|
||||
of $ R = b \oplus c $.
|
||||
%The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning.
|
||||
%Test cases joined by disjunction, all become represented in one, resultant equation.
|
||||
@ -640,9 +625,11 @@ of $ R = b \oplus c $.
|
||||
\begin{tabular}{||c|c|l||} \hline \hline
|
||||
{\em $SMG$ } & {\em Failure Mode equation } & {\em comments } \\ \hline
|
||||
|
||||
P & $(b \wedge c)$ & Symptom P is active when `$b \wedge a$' is \\ \hline
|
||||
Q & $(a)$ & Symptom Q is active when fault mode `a` is \\ \hline
|
||||
R & $(b \oplus c)$ & Symptom R is active when either `b' or `c' is \\ \hline
|
||||
P & $(a \wedge c)$ & Symptom P is active when `$a \wedge c$' is \\ \hline
|
||||
|
||||
R & $(a \oplus c)$ & Symptom R is active when either `a' or `c' is \\ \hline
|
||||
U & $(b)$ & Symptom U is active when fault mode `b` is \\ \hline
|
||||
% symptom U is only guaranteed when it is the only active failure mode in the {\fg}
|
||||
% T & T & T \\ \hline \hline
|
||||
\end{tabular}
|
||||
\vspace{0.3cm}
|
||||
@ -650,8 +637,8 @@ of $ R = b \oplus c $.
|
||||
|
||||
\paragraph{How this would be interpreted in failure analysis}
|
||||
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.
|
||||
|
||||
It has three SMG's $P$,$R$ and $U$. Thus there are three ways in which this functional~group is considered to fail.
|
||||
Note that symptom $U$ is only guaranteed when it is the only active failure mode in the {\fg}.
|
||||
%\clearpage
|
||||
|
||||
|
||||
@ -671,31 +658,15 @@ a software tool which assists in drawing these diagrams.
|
||||
\label{fig:repeated}
|
||||
\end{figure}
|
||||
|
||||
%
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[bb=0 0 485 206]{logic_diagram/repeated.jpg}
|
||||
% % repeated.jpg: 539x229 pixel, 80dpi, 17.11x7.27 cm, bb=0 0 485 206
|
||||
% \label{fig:repeat}
|
||||
% \end{figure}
|
||||
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[bb=0 0 486 206]{./repeated.jpg}
|
||||
% % repeated.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 486 206
|
||||
% \label{fig:repeated}
|
||||
% \end{figure}
|
||||
|
||||
|
||||
|
||||
The diagram \ref{fig:repeated} is converted to propositional logic by first looking at the test cases, and
|
||||
the contours they are placed on thus:
|
||||
$$ P = (b) \; ,$$
|
||||
$$ Q = (a) \wedge (c) \; .$$
|
||||
$$ U = (b) \; ,$$
|
||||
$$ P = (a) \wedge (c) \; .$$
|
||||
|
||||
The two test cases are joined by a the line named $R1$.
|
||||
we thus apply disjunction to the test cases:
|
||||
$$ R1 = P \oplus Q \;,$$
|
||||
$$ R1 = U \oplus P \;,$$
|
||||
$$ R1 = b \oplus ( a \wedge c ) \; .$$
|
||||
|
||||
$R2$ joins two other test cases
|
||||
@ -711,7 +682,7 @@ The third SMG %or symptom
|
||||
shown is test case $R3$ (representing equation $a \wedge b$).
|
||||
This diagram is incomplete, there is no test case for the fault mode $a$.
|
||||
The `available region' $a \backslash b$ (i.e. the area defined by contour $a$ excluding contour $b$) has no test case,
|
||||
and this would be considered a `syntax error'
|
||||
and this could be considered a `syntax error'
|
||||
by the FMMD software tool.
|
||||
|
||||
|
||||
@ -871,7 +842,23 @@ The test case AFE represents the condition where all four engines have failed \c
|
||||
|
||||
\section{Conclusion}
|
||||
|
||||
|
||||
PLD's provide a means to visually model failure modes within {\fgs} and after analysis
|
||||
of the test cases, extract the {\fg}'s common failure symptoms.
|
||||
%
|
||||
Because PLD's model failure modes generally, they are not constrained to
|
||||
any particular discipline.
|
||||
%
|
||||
Most methodologies are aimed at solving problems for a particular discipline,
|
||||
UML for instance is only suitable for modelling software.
|
||||
FMEA, FMEDA and FMECA are good at modelling
|
||||
electronic and mechanical systems, but struggle with software.
|
||||
%
|
||||
FTA models all systems, but from the top down, and rarely giving complete coverage
|
||||
to all base component failure modes.
|
||||
%
|
||||
PLD's can be used to model Mechanical, Electrical and Software
|
||||
failure modes. More importantly the interfaces between these disciplines can be modelled
|
||||
seamlessly.
|
||||
% Elevator Pitch
|
||||
|
||||
%\pagebreak[4]
|
||||
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |