robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sunday afternoon edits

Browse Source
This commit is contained in:
Robin 2010-05-30 18:14:47 +01:00
parent 23092c9e75
commit 97e2f802b5
5 changed files with 77 additions and 523 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

573
fmmdset/fmmdset.tex
View File

@ -1,13 +1,6 @@
% $Id: fmmdset.tex,v 1.7 2009/06/06 11:52:09 robin Exp $ % $Id: fmmdset.tex,v 1.7 2009/06/06 11:52:09 robin Exp $
%\newtheorem{theorem}{Thoeorem}
% %
% \def\lastname{Clark}
% \begin{document}
% \begin{frontmatter}
% \title{ Failure Mode Modular De-Composition } \author{Robin Clark\thanksref{ALL}\thanksref{r.clark@energytechnologycontrol.com}}
% \address{ Energy Technology Control\\
% 25 North Street, Lewes, BN7 2PE, Great Britain}
\begin{abstract} \begin{abstract}
This chapter describes a process for analysing safety critical systems, to formally prove how safe the This chapter describes a process for analysing safety critical systems, to formally prove how safe the
@ -22,14 +15,7 @@ EN298, EN61508, EN12067, EN230, UL1998.
\end{abstract} \end{abstract}
% \begin{keyword}
% fault~tree fault~mode EN298 EN61508 EN12067 EN230 UL1998 safety~critical
% \end{keyword}
% \end{frontmatter}
% \bibliographystyle{unsrt}
\section{Introduction} \section{Introduction}
@ -91,16 +77,8 @@ and dangerous~faults can be determined from traversing the fault tree down to th
\subsection{Basic Concepts Of FMMD} \subsection{Basic Concepts Of FMMD}
\subsubsection { Definitions }
\begin{list} \paragraph{ Creating a fault hierarchy}
\item base component - a component with a known set of unitary state failure modes
\item functional group - a collection of components chosen to perform a particular task
\item derived failure mode - a failure symptom of a functional group
\item derived component - a functional group after analysis
\end{list}
\subsubsection{ Creating a fault hierarchy}
The main idea of the methodology is to build a hierarchy of fault modes from the part The main idea of the methodology is to build a hierarchy of fault modes from the part
level up to highest system levels. level up to highest system levels.
@ -138,6 +116,21 @@ Applying the same process with derived components we can bring derived component
together to form functional groups and create new derived components together to form functional groups and create new derived components
at a higher abstraction level. at a higher abstraction level.
\subsubsection { Definitions }
\begin{itemize}
\item base component - a component with a known set of unitary state failure modes
\item functional group - a collection of components chosen to perform a particular task
\item derived failure mode - a failure symptom of a functional group
\item derived component - a functional group after analysis
\end{itemize}
\subsubsection{An algebraic notation for identifying FMMD enitities}
Each component $C$ is a set of failure modes for the component.
We can define a function $\mathcal FM$ that returns the
set of failure modes $S$ for the component.
$$ \mathcal{FM}(C) \rightarrow S $$
We can indicate the abstraction level of a component by using a superscript. We can indicate the abstraction level of a component by using a superscript.
Thus for the component $C$, where it is base component we can asign it Thus for the component $C$, where it is base component we can asign it
@ -146,460 +139,75 @@ the abstraction level zero thus $C^0$. Should we wish to index the components
Our base component (if first in the parts~list) could now be uniquely identified as Our base component (if first in the parts~list) could now be uniquely identified as
$C^0_1$. $C^0_1$.
A functional group can use the letter $F$. A function group is a collection
of components. We thus define $F$ as a set of components.
We can further define the abstraction level of a functional group.
We can say that it is the maximum abstraction level of any of its
components. Thus a functional group containing only base components
would have an abstraction level zero and could be represented with a superscript of zero thus
$F^0$. The functional group set may also be indexed.
We can apply symptom abstraction to a functional group to find
a set of derived failure modes. We are interested in the failure modes
of all the components in the functional group. An analysis process
defined as $\bowtie$ is applied to the functional group.
%Choosing small sections of the system, by choosing a collection of interacting parts we can form $$ \bowtie(F^N) \rightarrow C^{N+1} $$
%modules. These parts are collected together to form modules $M$. These modules are then
%analysed with respect to the failure modes of the parts that make them up. The $\bowtie$ function processes each member (component) of the set $F$ and
%This leads to a set of fault modes for each module, the derived fault~modes $D$. extracts all the component failure modes, which are used by the analyst to
%These derived fault modes may now be used at a higher abstraction level. determine the derived failure modes. A new derived component is created
%A hierarchy can be built, with each level representing a higher level of fault abstraction. where its failure modes are the symptoms from $F$.
% Note that the component will have a higher abstraction level than the functional
%%Each part may fail in a number of ways. group it analysed.
%We can take the levels of abstraction and view them as a hierarchy, with part level faults at the bottom.
%Each time we analyse a set of fault modes, with respect to how they interact, \subsubsection{FMMD Hierarchy}
%we get a new set of faults a higher level of fault abstraction.
%At the lowest level of fault~mode abstraction is the By applying stages of analysis to higher and higher abstraction
%part failure modes. This is the hierarchy abstraction level zero. Functional~groups, collections of parts are also at levels we can converge to a complete failure mode model of the system under analysis.
%abstraction level 0. Combining derived fault modes from functional groups to form {\em modules}, will
%also be at level 0.
%%By deriving the fault modes for a particular module.
%A set of faults derived from a `module' will be at abstraction level 1.
%Thus the module, a collection of parts is analysed, and the fault symtopms of that module derived.
%The act of analysing and deriving new faults raises the abstraction level.
%
%
%Simple parts may have
%a single failure mode, and more complex ones may have hundreds.
%% Hazel 11FEB2008 said this was difficult to read
%%It can be easily seen that trying to judge the effect of a single part mode failure against
%%all other parts failure modes in the system would be a thankless and practically impossible task.
%Were we to analyse the effect of each part failure mode against all other parts in the circuit,
%we could be facing a very large task.
%Modularisation allows detailed (part fault mode level) analysis of well defined functional groups within a system.
%The hierarchy allows the combining of these modules to form meaningful fault represention of the system.
%
An example of a simple system will illustrate this. An example of a simple system will illustrate this.
\subsubsection{Fault Abstraction Level} \subsection {Example FMEA process using an FMEA diagram}
\label{fal}
Let the fault abstraction level mean the number of times an element of a system
has been transformed by applying fault modes effects analysis. In the example above
the error becomes more abstract, each time we zoom out and consider the effects of
the fault on more generalised sections of the system.
Consider a simple functional~group $ F^0_1 $ derived from two base components $C^0_1,C^0_2$.
\section{ Fault Modes and Collections } We can apply $\bowtie$ to the functional~group $F$
and it will return a derived component at abstraction level 1 (with an index of 1 for completeness)
$$ \bowtie( F^0_1 ) = C^1_1 $$
A safety critical system is usually a collection of highly specified interacting parts. to look at this analysis process in more detail.
These are
documented in a 'parts list', which is taken to define to the standards
agencies the authorised parts that will be used for a particular approved product.
This is an important document, used in an official sense, by standards agency
inspectors, often to validate production processes.
\begin{definition} By way of exqample applying $\mathcal{FM}$ to obtain the failure modes $f_N$
Let $L$ be the index set for a given system.
Let $p$ denote a part in the `parts~list' $ P_L = \{ \; p_l \; | \; l \; \in \; L \; \} $
Thus $P_L$ represents a set of all parts in a safety critical product.
\end{definition}
{\em
Should this be a list instead ?
$ P_L = < \; p_1..L \; | \; p_l \; \in \; P_L \; > $
}
All parts in a safety critical system have known $$ \mathcal{FM}(C^0_1) = \{ f_1, f_2 \} $$
`fault~modes'. $$ \mathcal{FM}(C^0_2) = \{ f_3, f_4, f_5 \} $$
A fault~analysis function $fa$ may be applied to a part part $p$
returning a set of `fault~modes'.
\begin{definition} The analyst now considers failure modes $f_{1..5}$ in the context of the functional group.
Let the set $D^{a}_{l}$ represent a set of derived fault~modes. The result of this process will be a set of derived failure modes.
where $a$ represents the abstraction level, and $l$ is an index to the part that gives rise to these fault modes. Let these be $ \{ f_6, f_7, f_8 \} $.
A superscript of $0$ indicates that the fault~modes have been derived from We can now create a derived component $C^1_1$ with this set of failure modes.
the lowest abstraction level, the parts~level.
%Let $K_p$ be the set of possible fault~modes for a given part `$p$',
%Let $p$ denote a part in the `parts~list' indexed by the variable l, $ PL = \{ {p}_{l} | l \in L \} $
%Thus PL represents a set of all parts in the system.
\end{definition}
\begin{definition} Thus:
\label{func:fa}
$$ fa(p_l) = \{ f_1, f_2, f_3 ... f_n \} = D^{0}_{l} $$
where $f_1...f_n$ represent part fault modes for the part $p_l$.
The fault~modes corresponding to part $p_l$ are represented by the set $ D^{0}_{l}$. $$ \mathcal{FM}(C^1_1) = \{ f_6, f_7, f_8 \} $$
\end{definition}
%\begin{example}
For instance were part number 48 in a parts~list to be a wire wound resistor
applying fault analysis
would derive two fault conditions, open and short.
$$ fa(p_{48}) = \{ OPEN_{48}, SHORT_{48} \} = D^{0}_{48}$$
\label{disjointnotcare}
%\end{example}
\subsection { Defining an entire system \\ as a family of fault modes}
As a thought experiment, let us consider an entire system in terms of all its fault modes.
So without breaking a circuit into modules or chunks or whatever, just consider all the fault modes of all the components in a system.
One way of analysing a system would be to take each part fault mode
in turn and then to determine its effect on the system as a whole.
This means taking a particular part fault mode and checking its effects upon every other component in the system.
\begin{definition}
\label{func:s0}
Let $S^{0}$ be a family of sets of part~faults, for all parts in the parts list
\label{systemlevel0}
$$ {S^{0}} = \{ \; D^{0}_{l} \; | \; l \; \in \; L \; \} $$
which is the same as saying
$${S^{0}} = \{ fa(x) | x \in P_{L} \} $$
\end{definition}
The entire set of all part `fault~modes' for a complete system $S^{0}$, can be defined
by a family of all part fault~mode sets $D^{0}_{s}$, indexed by s with L as the index set.
$S^0$ then represents all the fault modes of all the parts in the system we are analysing.
We could analyse this circuit by taking each part~fault~mode and working out what effect it will have on the system as a whole.
This would be analysing the system from the perspecive of the effect of single part failures.
We could go further and take all combinations of double simultaneous faults possible
and examine their effect on the system.
%\begin{equation}
%\label{systemlevel0}
% {S^{0}} = \{ \; K^{0}_{l} \; | \; l \; \in \; L \; \} = \{ fa(x) | x \in P_{L} \}
%\end{equation}
%
%-OR- In terms of the parts~list, parts transformed to set $K$ by function`$fa$' all exist in $S^0$
%$$ \forall x \{ x \in PL | fa(x) \in S^{0} \}$$
%
To completely analyse the effect of all part failure modes we would
need to consider their affects in all combinations. In other words we
would have to look at each fault~mode and then see how it affected every other component in the system
and then work out what effect that would have on the entire system.
Checking every combination of fault~modes corresponds to the power set of the union of the set in $S^0$
(using $ \mathcal{P} $ to represent the power set, and $(\bigcup {S^0})$ to mean flattening the family of sets).
$$ AllcombinationsofPartFaults = \mathcal{P} ({\bigcup}_{l \in L} D^{0}_{l}) = \mathcal{P} (\bigcup {S^0}) $$
%where $ \cup \mathcal{F}S = \{ x | \forall A \in \mathcal{F}(x \in A) \} = \{x|\forall A ( A \in \mathcal{F} \rightarrow x \in A) \} $
That is to say, checking for all the part faults in the system, in all combinations.
% (including the empty set)
Taking the power set $ \mathcal{P} $ of the union of the family $S^0$, i.e. $ \mathcal{P} (\bigcup {{S}^{0})} $, would give us all possible
combinations of part faults in the system.
% Get the formula from the 2004 paper done with JEAN
\begin{example}A typical circuit board with say 1000 parts each of which have
say, 5 error modes, would mean $S^0$ would have 5000 elements.
Thus, to check for the effect of single part failure modes would entail 5000 checks against 999
parts.
To check for all double failures $(5000-1)^2*998$
To check all possible combinations of failure modes,
would lead to an astonishing number part~failure~modes to check ($2^{5000}$).
A full check at the part fault mode level is therefore impractical.
\end{example}
\subsection{Reducing the Power set combinations}
It would be much better if we could break the problem down into manageable chunks,
analyse the behaviour of the chunks and then combine them, with other fundtional~groups,
that have been analysed.
In this way we could build a hierarchy of modules with analysis phases
leading to an eventual model of the entire system.
\begin{definition}
Let $F$ be a functional group of components within a system.
A `functional~group' once identified will be a sub-set of the parts~list $P_L$.
$ F \subseteq P_L $
\end{definition}
A {\em functional group} defined from the parts is at the zero'th level of abstraction.
The {\em functional group} is a collection: no analysis has been applied
and it therefore is a group at zero level fault abstraction.
To indicate this it will be given a superscript of 0.
There may be a large number of functional~groups identified at this stage.
An index will be used as a subscript to identify them. Thus $F^{0}_{4}$ would be the fourth
identified functional group.
\begin{example}
Looking at the milli-volt sensor in figure~\ref{fig:mvs},
we can easily identify the milli-volt amplifier as a functional group.
It has a small number of components and one specific well defined job.
That is to amplfy a milli volt signal to within a given range and to
pass this on to another functional group to read it (the ADC).
\end{example}
The functional group as a list of parts is not directly useful. If we define a function
`$fm$` that translates a set of parts (functional~group) into a corresponding family of
fault~mode sets, these can be used for further analysis.
These families of fault mode sets are termed `modules'.
%Using the function $\#$ to represent cardinality thus $\#(A) = Cadinality(A)$.
\begin{definition}
Let $M^{a}_{n}$ represent a family of derived fault modes
corresponding to the functional group $F^{a}_{n}$, where $a$ represents the abstraction level
and $n$ is an index.
\end{definition}
The set $M^{0}_{n}$ is a family of fault~modes corresponding to the {\em functional group}
$F^{0}_{n}$, where the superscript $a$, represents the
hierarchy/abstraction level, and $n$ corresponds to the functional group index.
\begin{definition}
\label{func:fm}
The function fm translates a set of parts to a set of corresponding fault~modes
$$fm: F^{0}_{n} \rightarrow M^{0}_{n} $$
or
$$ M^{0}_{n} = \{ fa(p) | p \in F^{0}_{n} \} $$
%
% completeness not necessaary with cardinality of sets as it iterates over whole parts list
% $$ fm( M^{a}_{n} ) = \forall x \{ x | ( x \in M^{a}_{n} \rightarrow ( fa(x) \in K^{a}_{n} ) \Con ( \#(M^{a}_{n}) = \#(K^{a}_{n} ) ) \}$$
%
\end{definition}
\begin{summary}
Beginning with the
individual parts, we have combined these to functional~groups.
These functional groups have been converted into a family of corresponding sets of fault~modes (modules).
The next stage is to perform fault~mode~effect~analysis to determine the ways in which the `module' can fail.
Or in other words a set of faults at the `module'
level : i.e. a higher level of fault~mode abstraction.
\end{summary}
\section { FMEA : Fault Mode Effect Analysis }
Fault mode effects analysis, is the process of looking at a module and determining how it will fail
according to different scenarios of part failures.
This can be in the nature of a thought experiment (for instance looking an an electronic circuit,
we might say what happens if this resistor goes open etc),
or could be based on empirical data. However the results gathered would always be subject to
the scrutiny and approval of any standards agency they would be submitted to\footnote{Some standards are now listing common electronic parts with associated fault~modes that must be considered for
the approval process \cite{EN61508}.}. Often in an approval process, the approval agencies will talk through fault scenarios and require that manufacturers defend against potential part faults. This is on the basis of experience and knowledge of the type of
system under analysis. It is not necessarilly a rigourous or mathematically complete process.
%This analysis needs to be performed by an expert
%for the system under scrutiny.
%\begin{definition} A module is a family of sets of `fault modes' of parts (eqn \ref{module}).\end{definition}
By looking at how the part fault~modes within a module interact; and then
analysing the scenario for every fault~mode combination, we can determine a new set of fault~modes, fault~modes
from the perspective of the module.
\begin{definition}
Let $D^{a+1}_{n}$ be the set of fault~modes derived from a module $M^{a}_{n}$.
A superscript will define the abstraction level and a subscript the module index.
Note that the act of deriving fault~modes from a module, raises the abstraction level.
\end{definition}
\begin{definition}
Let the symbol $\FMEA$ mean `fault mode effects analysis'. This will translate a set family $M$ into a corresponding set $D$.
i.e. $ \bowtie: M^{a}_{n} \mapsto D^{a+1}_{n}$ The $\bowtie$ operation has the effect of raising the fault abstraction level.
\end{definition}
%Each module analysed map to a derived set
%which will have the same subscript and index.
%A module at abstraction level 0, can be mapped
% to a derived set by applying $\FMEA$ to the M set thus:
\begin{equation}
\label{derive0}
D^{1}_{N} \; = \FMEA({\cal P} \; \bigcup \; M^{0}_{N}) = \FMEA({\cal P} \; \bigcup \; fm (F^{0}_{N}) \; )
\end{equation}
The set $ D^{1}_{N} $ is the set of errors derived from the Nth module at abstraction level 0.
$D^1_{n}$ sets derived in this way, could now be used in the same way as the $D^0_n$ sets were in the last example,
but at a higher level of abstraction. Thus one or more $ D^{1}_{N} $ sets can be combined
to form a $M^1_{n}$ set i.e.
\begin{example}
For example, we could build a first level $M$ set from three first level module derived fault modes, say
$ D^{1}_{1}, D^{1}_{4}, D^{1}_{7}$.
$$ M^{1}_{N} = \{ D^{1}_{1}, D^{1}_{4}, D^{1}_{7} \} $$
This $ M^{1}_{N} $ set may now be subjected to FMEA and will return a set of derived fault~modes at the second level of hierarchy thus
\begin{equation}
D^{2}_{N} \; = \FMEA({\cal P} \; (\bigcup \; M^{1}_{N}))
\end{equation}
This may continue up until the hierarchy is complete, with the fault~modes becoming more and
more abstract as the hierarchy gets higher. The top of the hierarchy will be a set of derived
fault modes, representing the system fault modes.
\end{example}
\subsection{The FMEA Process}
In practise the combinations of fault modes to be analysed are placed on a
matrix, and the fault effect is determined for each combination under scrutiny.
It may be found that one or more combinations of part fault~modes will lead to the same module
level fault~mode. The means that the module could fail in the same way due to a variety of causes,
and this fact will be useful later for determining fault trees. But more importantly, it means that the number
of fault conditions for a module should be smaller than the sum of all the part error conditions
in the module.
\subsection{ Practical limits for the number \\ of fault mode combinations to \\ consider within a module}
It may not be deemed necessary to analyse all scenarios from the power-set of an $M$ set.
Some European standards will only consider one part fault at a time for analysis
and stricter ones\ref{en298} imply checking for double simultaneous faults. Statistically it
becomes very unlikely to have more than two parts fail suddenly and
European\ref{en298} and North American\ref{UL1998} standards reflect this belief.
To express this formally we can use a cardinality restricted powerset see \ref{ccp}
Thus for considering single part fault modes only, equation \ref{derive0} becomes
$ D^{2}_{N} \; = \FMEA({\cal P}_1 \; (\bigcup \; M^{1}_{N}))$
And for considering double and single fault modes $ D^{2}_{N} \; = \FMEA({\cal P}_2 \; (\bigcup \; M^{1}_{N}))$.
{\em NOTE: need proof here of how this translates UP the hierarchy, because as it goes UP
only more error sources can be included in the fault tree NOT LESS OK need the express this formally maybe}
%Collecting the derived fault modes is thus important.
The FMEA process can be represented visually, by making part fault modes contours and scenario test
cases points. Points which have the same module level fault~mode can now be joined by lines.
%Although this looks very much like a spider diagram, but it would be misleading to think of it so.
Note this is not a diagram representing sets. The Euler diagram here
is being used to represent logical conditions.
Each collection of test~cases joined by line(s) is a derived fault mode at the module level.
\subsection{FMEA Diagram : Definition of Symbols}
%\begin{figure}[t+]
%\centering
%\epsfig{file=cimg5043fmmd_spider.eps, width=\textwidth}
%\caption{ FMEA Diagram : Example Incomplete Analysis }
%\label{fig:sdfmea}
%\end{figure}
%
% \begin{figure}
% \centering
% \input{fmmdset/fmea_diagram.tex}
% \caption{FMEA Diagram : Example Incomplete Analysis}
% \label{fig:sdfmea}
% \end{figure}
We can represent this analysis process in a diagram see figure \ref{fig:onestage}
\begin{figure}[h] \begin{figure}[h]
\centering \centering
\includegraphics[width=400pt,bb=0 0 379 391,keepaspectratio=true]{fmmdset/fmea_diagram.png} \includegraphics[width=200pt,bb=0 0 268 270]{fmmdset/onestage.jpg}
% fmea_diagram.png: 379x391 pixel, 72dpi, 13.37x13.79 cm, bb=0 0 379 391 % onestage.jpg: 268x270 pixel, 72dpi, 9.45x9.52 cm, bb=0 0 268 270
\caption{FMEA Diagram : Example Incomplete Analysis} \caption{FMMD analysis of functional group}
\label{fig:sdfmea} \label{fig:onestage}
\end{figure} \end{figure}
When viewed as an FMEA diagram, each part fault mode would become a contour.
Each (asterisk `*') represents test~case corresponding to a combination of fault~modes within the module.
Overlapping contours represent the occurrence of simultaneous faults (i.e. all the fault modes
corresponding to contours are considered active for the test case).
\begin{summary}
\begin{itemize}
\item Test cases are represented by `*' marks.
\item Conjuction of fault~modes (i.e. simultaneous faults) are represented by overlapping regions of contours.
\item Lines joining test cases mean the test cases cause the same fault at the module or $M$ set abstraction level.
\end{itemize}
\end{summary}
{\em TO DO: well formness and specific rules for FMEA diagrams}
\subsection {Example FMEA process using an FMEA diagram}
Consider a simple functional~group $ F^0_1 $ derived from two parts $p1,p2$.
Applying fault analysis to these parts gives sets of corresponding fault modes
(where $D^0_p$ is the set of fault modes for the part $p$,
and the individual fault modes use an indexed lower case $f$
with the part number with a post fixed fault type, here a..z).
$$ fa(p1) = \{ f_{p1a}, f_{p1b}, f_{p1c} \} = D^0_{p1} $$
$$ fa(p2) = \{ f_{p2a}, f_{p2b} \} = D^0_{p2} $$
Applying the `$fm$' function defined in (\ref{func:fm}) to the functional group $F$
gives an $M$ set. This is a module that we can use for fault behaviour analysis.
$$ fm( F_{1}^{0} ) = M_{1}^{0} = \{ D^0_{p1}, D^0_{p2} \} $$
Note the definition of the Union of this family is
$$ {\bigcup}{M_1^0} = \{ f_{1a}, c_{1b}, f_{1c}, f_{2a}, f_{2b} \} $$
To analyse the effects of the fault~modes on the module, we first take the power set of the union of this family
$$ \mathcal{P} ({\bigcup}{M_1^1}) = \mathcal{P} \{ f_{1a}, f_{1b}, f_{1c}, f_{2a}, f_{2b} \} $$
The Power-set returns all possible combinations of faults. In this case it would be $2^5$ number of combinations to check.
We could restrict the cardinality of the powersets and reduce the complexity level.
For this we can use a restricted cardinality powerset (see \ref{ccp}).
If we restrict our search to single faults and double simultaneous faults $\mathcal{P}_{2}$, we can use a two dimensional
Euler\footnote{Euler diagrams are here not used to represent sets, but are used to represent boolean logic conditions}
diagram to represent this. In this Euler diagram, for simplicity, only 5 test cases
have been analysed (see figure \ref{fig:sdfmea}).
For the purposes of this example it has been decided that some combinations of part faults, cause the same module level error.
Where this happens test~cases are joined by lines to indicate that they cause the same fault
(from the module or $M^a_n$ set perspective).
The single point $f2$ represents a module fault mode caused by the
combined part failures of $ f_{p2b}$ and $f_{p1a}$.
As an equation
$$f2 \rightarrow f_{p2b} \Con f_{p1a} $$
Two pairs of test cases cause the same module level error.
$f1$ and $f3$, are both joined to two test cases by connecting lines.
The module level fault mode $f1$ was caused by either fault~mode $c_{1b}$ or by
the combination of $f_{p1c} \Con f_{p2b}$.
As an equation
$$f1 \rightarrow f_{p1b} \Dis (f_{p1c} \Con f_{p2b}) $$
Similarly the logical causes for $f3$, are
$$f3 \rightarrow ( ( f_{p1a} \Con f_{p2a} ) \Dis ( f_{p1b} \Con f_{p2a} ) ) $$
or simplifying by distributive law
$$f3 \rightarrow ( f_{p2a} \Con ( f_{p1b} \Dis f_{p2a} ) ) $$
All joined test cases and individual test cases, discovered during the FMEA process,
can now be considered
to be derived fault modes for the module.
Thus:
$$ D^{1}_{1} = \FMEA ({\bigcup}{M^{0}_{1}}) = \FMEA {\cup} fm({F^{0}_{1}}) = \{ f1, f2, f3 \} $$
$ D^{1}_{1} $ is now a set of fault~modes for the module. We can now
treat this in the same way we treated the part fault mode sets ($M^{0}_{n}$),
and take several derived ( $ D^{1}_{n} $) sets and combine them to form higher level modules.
This is like considering the derived set to be a part, but a part at a higher level of abstraction.
The process can then continue until up in abstraction levels until we have a complete hierarchical model.
Note for the purpose of reducing clutter from this example we are ignoring the other test cases. A full analysis would include
all test cases.
% \begin{figure} % \begin{figure}
% \centering % \centering
@ -658,65 +266,6 @@ even though they may have accompanying diagnostic data.
\section {Modelling considerations} \section {Modelling considerations}
\subsection{FMEA diagramatic syntax and Well Formedness }
{\em TO DO RULES AND MEANING}
\subsection{The Parts List, Set or Bag}
The Parts list is indexed by the set $L$ to ensure all parts are unique.
Thus Set suffices and no bags required.
\subsection{The Empty Set}
Note that any power~set will always include the empty set.
Thus $\emptyset \in ({\cal P} \cup {\cal F}S)$ corresponds to the
state where there are no active errors in any of the parts
in the system i.e. it is in correct operational state.
$$ CorectOperationalState = \emptyset \in ({\cal P} \cup {\cal F}S) $$
This simply says that where no part fault modes are active the system must be functioning correctly.
If this is not the case, then all part~fault modes have not been considered.
\subsection{Complete Coverage of Fault Modes }
To ensure that all fault modes are represented, each fault mode from
the union all subsets of $S$ ($\cup {S}$) must be represented by a first
level module.
$$ CompleteCoverage = \forall \; x \exists \; y \; ( \; x \; \in \; (\bigcup \; S) \; \Rightarrow \; x \; \in \; (\bigcup \; D^{1}_{y}) ) $$
That is to say that where a fault~mode exists in the system, it must be
included in at least one module.
Were it not to be we would have a fault~condition that was not modelled.
The $CompleteCoverage$ check would not ensure that the modules had been
identified correctly, but would ensure that there were no missing
fault~modes, and acts as a type of syntax check.
Note also, that this means the modules could share parts
(although this would be unusual in practise).
\subsection{ Part Fault modes Conjoint and Disjoint }
Note that in the example (\ref{disjointnotcare}) the part fault modes are disjoint, the resistor cannot be both open and shorted
at the same time. Not all part fault modes are disjoint, however. Consider a complicated part
like a micro~processor. This could easily have more than one fault~mode active.
\section {notes}
\subsection{ The Parts List }
A parts list is typically a document with an enumerated list of parts.
Each part includes a description, placement information, manufacturers part number and optional comments and vendor sourcing numbers.
It is a document tied to a particular hardware revision of a product, and is used for the procurement of parts
and as a cross check for inspectors from standards agencies.
{\em NEED EXAMPLE PARTS LIST HERE....}
\subsection{ Proof of number of part~failure \\ modes preserved in hierarchy build} \subsection{ Proof of number of part~failure \\ modes preserved in hierarchy build}
Here need to prove that if we have an abstract fault, then as it goes higher in the tree, it can only collect MORE not less Here need to prove that if we have an abstract fault, then as it goes higher in the tree, it can only collect MORE not less

2
introduction/introduction.tex
View File

@ -22,7 +22,7 @@ This changed the target for the study slightly to encompass these three domains
\section{Background} \section{Background}
I completed an MSc in Software engineering in 2004 at Brighton university while working for I completed an MSc in Software engineering in 2004 at Brighton University while working for
an Engineering firm as a software Engineer. an Engineering firm as a software Engineer.
The firm make industrial burner controllers. The firm make industrial burner controllers.
Industrial Burners are potentially very dangerous industrial plant. Industrial Burners are potentially very dangerous industrial plant.

14
logic_diagram/logic_diagram.tex
View File

@ -399,11 +399,11 @@ There are no disjunctive joining lines and so this diagram represents one equati
Note that $P$ is considered to be an $SMG$ 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} \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$. In failure analysis, this could be considered to be a faunctional~group with two failure states $a$ and $b$.
The proposition $P$ considers the scenario where both failure~modes are active. The proposition $P$ considers the scenario where both failure~modes are active.
\clearpage \clearpage
\subsection { Logical OR example } \subsection { Logical XOR example }
\begin{figure}[h] \begin{figure}[h]
\centering \centering
\includegraphics[bb=0 0 476 264]{logic_diagram/ldor.jpg} \includegraphics[bb=0 0 476 264]{logic_diagram/ldor.jpg}
@ -440,7 +440,7 @@ substituting the test cases for their Boolean logic equations gives
\paragraph{Failure Analysis Interpretation} \paragraph{Failure Analysis Interpretation}
Equation \ref{eqn:l_or} would be interpretted to mean that Equation \ref{eqn:l_or} would be interpretted to mean that
either failure mode a or b occurring, would have the same failure symptom for the circuit/sub-system either failure mode a or b occurring, would have the same failure symptom for the circuit/functional~group
under analysis. under analysis.
@ -490,8 +490,8 @@ of $ R = b \oplus c $.
\paragraph{How this would be interpreted in failure analysis} \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$. 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 sub-system can fail. It has three SMG's Q,R and P. Thus there are three ways in which this functional~group can fail.
% \tiny % \tiny
\vspace{0.3cm} \vspace{0.3cm}
@ -628,7 +628,7 @@ $$ R3 = d $$
\paragraph{How this would be interpreted in failure analysis} \paragraph{How this would be interpreted in failure analysis}
In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$ In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$
occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring. occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring.
Note that although R2 is a symptom of the sub-system, on its own Note that although R2 is a symptom of the functional~group, on its own
it will not lead to a dangerous failure~mode of the subsystem. it will not lead to a dangerous failure~mode of the subsystem.
@ -791,11 +791,13 @@ errors of ommission are automated in the FMMD tool.
\section{Double Simultaneous Fault Modelling} \section{Double Simultaneous Fault Modelling}
TO DO:
matrix diagram matrix diagram
\section{N Simultaneous Errors} \section{N Simultaneous Errors}
TO DO:
Venn N example Venn N example
%\subsection{Example Sub-system} %\subsection{Example Sub-system}

2
pt100/pt100.tex
View File

@ -290,7 +290,7 @@ $$ lowreading = 5V.\frac{212.02\Omega}{2k2+212.02\Omega} = 0.44V$$
Thus with $R_2$ shorted both readings are outside the Thus with $R_2$ shorted both readings are outside the
proscribed range in table \ref{ptbounds}. proscribed range in table \ref{ptbounds}.
\subsubsection{ TC : 4 Voltages $R_2$ OPEN } \subsubsection{ TC 4 : Voltages $R_2$ OPEN }
Here there is no potential divider operating and both sense lines Here there is no potential divider operating and both sense lines
will read 5V, outside of the proscribed range. will read 5V, outside of the proscribed range.

9
thesis.tex
View File

@ -9,6 +9,7 @@
\input{style} \input{style}
%\usepackage{hyperref}
\begin{document} \begin{document}
\pagestyle{fancy} \pagestyle{fancy}
@ -118,6 +119,11 @@
Safety critical in that it must not overheat, and that it must alarm Safety critical in that it must not overheat, and that it must alarm
for incorrect temperature. for incorrect temperature.
\chapter{Conclusion}
%\input{conclusion/conclusion}
\appendix
\chapter{FMMD tool : Design Issues} \chapter{FMMD tool : Design Issues}
reference the MSC document and describe the Java extension classes. reference the MSC document and describe the Java extension classes.
@ -132,9 +138,6 @@ Software documentation for fmmd tool.
%\chapter{FMMD tool : Algorithms and Euler Diagram Parsing} %\chapter{FMMD tool : Algorithms and Euler Diagram Parsing}
\chapter{Conclusion}
%\input{conclusion/conclusion}
\small \small
\bibliographystyle{abbrv} \bibliographystyle{abbrv}
\bibliography{vmgbibliography,mybib} \bibliography{vmgbibliography,mybib}