more edits
This commit is contained in:
parent
221cd307cb
commit
0a204effe0
@ -472,12 +472,25 @@ This project uses a modified form of euler diagram used to represent proposition
|
||||
%The propositional logic is used to analyse system components.
|
||||
|
||||
|
||||
\section{Ideal System Designers world}
|
||||
\section{Determining Component Failure Modes}
|
||||
\subsection{Electrical}
|
||||
Generic component failure modes for common electrical parts can be found in MIL1991.
|
||||
Most modern electrical components have associated data sheets. Usually these do not explicitly list
|
||||
failure modes.
|
||||
% watch out for log axis in graphs !
|
||||
\subsection{Mechanical}
|
||||
Find refs
|
||||
\subsection{Software}
|
||||
Software must run on a microprocessor/microcontroller, and these devices have a known set of failure modes.
|
||||
The most common of these are RAM and ROM failures, but bugs in particular machine instructions
|
||||
can also exist.
|
||||
These can be checked for periodically.
|
||||
Software bugs are unpredictable.
|
||||
However there are techniques to validate software.
|
||||
These include monitoring the program timings (with watchdogs and internal checking)
|
||||
applying validation checks (such as independent functions to validate correct operation).
|
||||
|
||||
|
||||
Imagaine a world where, when ordering a component, or even a complex module
|
||||
like a a failsafe sensor/scientific instrunment, one page of the datasheet
|
||||
is the failure modes of the system. All possible ways in which the component can fail
|
||||
and how it will react when it does.
|
||||
|
||||
\subsection{Environmentally determined failures}
|
||||
|
||||
@ -489,19 +502,19 @@ temperature being the most typical. Very often what happens to the system outsid
|
||||
\section{Project Goals}
|
||||
|
||||
\begin{itemize}
|
||||
\item To create a Bottom up FMEA technique that is modular and permits a linked hierarchy to be
|
||||
build representing the fault behaviour of a system.
|
||||
\item To create a Bottom up FMEA technique that permits a connected hierarchy to be
|
||||
built representing the fault behaviour of a system.
|
||||
\item To create a procedure where no component failure mode can be un-handled.
|
||||
\item To create a user friendly formal common visual notation to represent fault modes
|
||||
in Software, Electronic and Mechanical sub-systems.
|
||||
\item To formally define this visual language.
|
||||
\item To prove that tehe modules may be combined into hierarchies that
|
||||
truly represent the fault handling from component level to the
|
||||
\item To formally define this visual language in concrete and abstract domains.
|
||||
\item To prove that the derived~componets used to build the hierarchies
|
||||
provide traceable fault handling from component level to the
|
||||
highest abstract system 'top level'.
|
||||
\item To reduce to complexity of fault mode checking, by modularising and
|
||||
building complexity reducing hierarchies.
|
||||
\item To formally define the hierarchies and procedure for bulding them.
|
||||
\item To produce a software tool to aid in the drawing of diagrams and
|
||||
ensuring that all fault modes are addressed.
|
||||
\item to provide for determinisic and probablistic failure mode analysis processes
|
||||
\item To allow the possiblility of MTTF calculation for statistical
|
||||
reliability/safety calculations.
|
||||
\end{itemize}
|
||||
|
@ -3,7 +3,7 @@
|
||||
\begin{abstract}
|
||||
%This chapter describes using diagrams to represent propositional logic.
|
||||
Propositial Logic Diagrams have been designed to provide an intuitive method for visualising and manipulating
|
||||
logic equations, to express fault modes in Mechanical and Electronic Systems.
|
||||
a specific sub-set of logic equations, to express fault modes in Mechanical and Electronic Systems.
|
||||
%To aid hierarchical stages of fault analysis, it has been specifically developed for the purpose of
|
||||
%joining conjunctive conditions with disjuctive conditions
|
||||
%to group the effects of failure modes.
|
||||
@ -46,11 +46,13 @@ for the analysis of safety critical software and hardware systems.
|
||||
Propositional Logic Diagrams (PLDs) have been devised
|
||||
to collect and simplfy fault~modes in safety critical systems undergoing
|
||||
static analysis\cite{FMEA}\cite{SIL}.
|
||||
|
||||
%
|
||||
This type of analysis treats failure modes within a system as logical
|
||||
states. PLD provides a visual method for modelling failure~mode analysis
|
||||
within these systems, and specifically
|
||||
identifying common failure symptoms in a user friendly way.
|
||||
states.
|
||||
PLD provides a visual method for modelling failure~mode analysis
|
||||
within these systems, and aids the collection of
|
||||
common failure symptoms.
|
||||
%
|
||||
Contrasting this to looking at many propositional logic equations directly
|
||||
in a text editor or spreadsheet, a visual method is percieved as being more intuitive.
|
||||
|
||||
@ -72,7 +74,7 @@ in a text editor or spreadsheet, a visual method is percieved as being more intu
|
||||
PLDs use three visual features that
|
||||
can be combined to represent logic equations. Closed contours, test cases, and lines that
|
||||
link test cases.
|
||||
All features may be labelled, and the labels must be unique within a diagram, however contours may be repeated in the diagram.
|
||||
All features may be labelled, and the labels must be unique within a diagram, however contours may be repeated.
|
||||
%Aditionally a label begining with the `$\neg$' character, applied only to a contour, represents negation.
|
||||
|
||||
|
||||
@ -82,7 +84,7 @@ Test cases are marked by asterisks. 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 conjuction.
|
||||
Test~cases may be connected by joining lines. These lines represent disjunction (Boolean `OR') of
|
||||
Test~cases may be connected by joining lines. These lines represent disjunction (Boolean `XOR') of
|
||||
test~cases.
|
||||
|
||||
With these three visual syntax elements, we have the basic building blocks for all logic equations possible.
|
||||
@ -127,9 +129,7 @@ the curves are drawn using dotted and dashed lines.
|
||||
|
||||
\subsection{ PLD Definition}
|
||||
In English:
|
||||
The elements that can be found in a PLD diagram are a number of contours,
|
||||
a number of test points and joining lines that connect
|
||||
test points.
|
||||
Possible elements in a PLD diagram are contours, test points and joining lines that connect test points.
|
||||
{
|
||||
\definition{A concrete PLD $d$ is a set comprising of a set of
|
||||
closed curves $C=C(d)$, a set of test points $T=T(d)$ and
|
||||
@ -231,27 +231,27 @@ In English:
|
||||
Test points on the concrete diagram pair-wise connected by a `joining line'
|
||||
|
||||
|
||||
A collection of test points connected by joining lines, is an Functionally Merged Group, $FMG$
|
||||
or `test point disjunction'.
|
||||
An $FMG$ has members which are test points.
|
||||
A collection of test points connected by joining lines, is an Symptom Merged Group, $SMG$
|
||||
or `test point disjunction'. The $SMG$ is the analog of the Spider in constraint diagrams.
|
||||
An $SMG$ has members which are test points.
|
||||
|
||||
{
|
||||
\definition{
|
||||
%A spider is a set of test points where,
|
||||
%a test point is a member of a spider where it can trace a path connected by joining lines
|
||||
%to another member of the spider. A singleton test point can be considered a spider.
|
||||
Let d be a PLD : An $FMG$ is a maximal set of test points in d where
|
||||
Let d be a PLD : An $SMG$ is a maximal set of test points in d where
|
||||
the test points belong to a sequence connected by joining lines such that:
|
||||
|
||||
$$ t_i \stackrel{join}{\leftrightarrow} t_n, for \; i = 1, ..., n $$
|
||||
|
||||
|
||||
OR consider an $FMG$ as a tree whose nodes are test points.
|
||||
OR consider an $SMG$ as a tree whose nodes are test points.
|
||||
|
||||
}
|
||||
}
|
||||
|
||||
A singleton test point can be considered a sequence of one test point and is therefore also an $FMG$.
|
||||
A singleton test point can be considered a sequence of one test point and is therefore also an $SMG$.
|
||||
|
||||
|
||||
% \subsection{Abstract Description of PLD}
|
||||
@ -281,12 +281,12 @@ A singleton test point can be considered a sequence of one test point and is the
|
||||
\begin{itemize}
|
||||
\item A closed curve in a PLD represents a condition (logical state) being modelled.
|
||||
\item A test point represents the conjunction of the conditions represented by the curves that enclose it.
|
||||
\item A $FMG$ represents the disjunction of all test points that are members of it.
|
||||
\item A $SMG$ represents the disjunction of all test points that are members of it.
|
||||
\end{itemize}
|
||||
|
||||
To obtain the set of propositions from a PLD, each $FMG$ must be traversed
|
||||
To obtain the set of propositions from a PLD, each $SMG$ must be traversed
|
||||
along each joining line. For each test case
|
||||
in the $FMG$ a new section of the equation is disjuctively appended to it.
|
||||
in the $SMG$ a new section of the equation is disjuctively appended to it.
|
||||
|
||||
Let conjunctive logic equation associated with a test point
|
||||
be determined from the contours that enclose it.
|
||||
@ -314,25 +314,25 @@ $ a \wedge b \wedge c $.
|
||||
|
||||
{
|
||||
\definition{
|
||||
Let $\mathcal{G}_{fmg}$ be a function that returns a logic equation for a given $FMG$
|
||||
$fmg$ in the diagram, where an FMG is a non empty set of test points
|
||||
Let $\mathcal{G}_{fmg}$ be a function that returns a logic equation for a given $SMG$
|
||||
$fmg$ in the diagram, where an SMG is a non empty set of test points
|
||||
% $t$ is a `test point'
|
||||
|
||||
$$ \mathcal{G}:FMG \rightarrow P_{fmg} $$
|
||||
$$ \mathcal{G}:SMG \rightarrow P_{fmg} $$
|
||||
|
||||
The logic equation representing an FMG $p_{fmg}$ can be determined thus.
|
||||
The logic equation representing an SMG $p_{fmg}$ can be determined thus.
|
||||
|
||||
$$\mathcal{G}_{fmg}(fmg) = \bigvee_{t \in fmg} (\; \mathcal{F}_{t} (t) \;) $$
|
||||
$$\mathcal{G}_{fmg}(fmg) = \bigoplus_{t \in fmg} (\; \mathcal{F}_{t} (t) \;) $$
|
||||
}
|
||||
}
|
||||
|
||||
The abstract PLD diagram is a set of logic equations representing all FMGs,
|
||||
along with unused zones (i.e. zones that are not inhabited by FMGs).
|
||||
The abstract PLD diagram is a set of logic equations representing all SMGs,
|
||||
along with unused zones (i.e. zones that are not inhabited by SMGs).
|
||||
{
|
||||
\definition{
|
||||
\label{FMGderivation}
|
||||
A diagram can be reduced to a collection of $FMG$s.
|
||||
A new diagram can be derived from this, replacing a contour for each FMG.
|
||||
\label{SMGderivation}
|
||||
A diagram can be reduced to a collection of $SMG$s.
|
||||
A new diagram can be derived from this, replacing a contour for each SMG.
|
||||
This diagram is at one higher level of abstraction then the diagram that
|
||||
it was produced from.
|
||||
}
|
||||
@ -396,7 +396,7 @@ In the diagram \ref{fig:ld_and} the area of intersection between the contours $a
|
||||
represents the conjunction of those conditions. The point $P$ represents the logic equation
|
||||
$$ P = (a \wedge b) $$
|
||||
There are no disjunctive joining lines and so this diagram represents one equation only, $ P = (a \wedge b) $.
|
||||
Note that $P$ is considered to be an $FMG$ with one element, $ (a \wedge b) $
|
||||
Note that $P$ is considered to be 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 sub-system with two failure states $a$ and $b$.
|
||||
@ -491,12 +491,12 @@ of $ R = b \oplus c $.
|
||||
|
||||
\paragraph{How this would be interpreted in failure analysis}
|
||||
In failure analysis, this could be considered to be a sub-system with three failure states $a$,$b$ and $c$.
|
||||
It has three FMG's Q,R and P. Thus there are three ways in which this sub-system can fail.
|
||||
It has three SMG's Q,R and P. Thus there are three ways in which this sub-system can fail.
|
||||
|
||||
% \tiny
|
||||
\vspace{0.3cm}
|
||||
\begin{tabular}{||c|c|l||} \hline \hline
|
||||
{\em $FMG$ } & {\em Failure Mode equation } & {\em comments } \\ \hline
|
||||
{\em $SMG$ } & {\em Failure Mode equation } & {\em comments } \\ \hline
|
||||
Q & $(a)$ & T \\ \hline
|
||||
P & $(b \oplus c)$ & T \\ \hline
|
||||
R & $(b \wedge c)$ & F \\ \hline
|
||||
@ -560,7 +560,7 @@ represents the logic equation $R3 = a \wedge b$.
|
||||
\paragraph{How this would be interpreted in failure analysis}
|
||||
In failure analysis, $R2$ is the symptom of either failure~mode $a$ or $c$
|
||||
occurring. $R1$ is the symptom of $b$ exclusive-or $a \wedge c$ occurring.
|
||||
The third FMG or symptom shown is test case in $a \wedge b$.
|
||||
The third SMG or symptom shown is test case in $a \wedge b$.
|
||||
This diagram is incomplete, there is no test case for the fault mode $a$.
|
||||
The `available region' $a \backslash b$ has no test case, and this would be considered a `syntax error'
|
||||
by the FMMD software tool.
|
||||
@ -788,6 +788,16 @@ The act of collecting common symptoms by joining lines is seen as intuitive.
|
||||
Syntax checking (looking for contradictions and tautologies), as well as detecting
|
||||
errors of ommission are automated in the FMMD tool.
|
||||
|
||||
|
||||
\section{Double Simultaneous Fault Modelling}
|
||||
|
||||
matrix diagram
|
||||
|
||||
|
||||
\section{N Simultaneous Errors}
|
||||
|
||||
Venn N example
|
||||
|
||||
%\subsection{Example Sub-system}
|
||||
%
|
||||
%For instance were a `power supply' being analysed there could be several
|
||||
|
@ -150,6 +150,19 @@ computer providing the processing. re-phrase.
|
||||
Need tree diagram here with MECH as lowest, electronics and then SW
|
||||
as typical program structure.
|
||||
{\huge DIAGRAM REQUIRED}
|
||||
|
||||
|
||||
|
||||
|
||||
\section{General Placement of Software in an Embedded System}
|
||||
|
||||
Sw acts as transfrom flow . Sensors (electronics ) are afferent flow.
|
||||
Actuators are efferent flow.
|
||||
|
||||
The s/w sits in the midlle.
|
||||
The s/w can apply checking to <F9>and therefore naturally sits at the top of the hierarchy.
|
||||
|
||||
Similarities with yourdon dataflow mwethod here
|
||||
\clearpage
|
||||
|
||||
%%\bibliography{vmgbibliography,mybib}
|
||||
|
Loading…
Reference in New Issue
Block a user