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

JMC proof read CH4

Browse Source
This commit is contained in:
Robin Clark 2012-05-13 14:25:30 +01:00
parent bad6a518b3
commit d0d8e91d56
2 changed files with 44 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
submission_thesis/CH4_FMMD/copy.tex
View File

@ -176,8 +176,8 @@ Tracing a component level failure up to a top level event, without the rigour ac
working heuristically. A base component failure will typically
be conceptually removed by several stages from a top level event.
%In electronics terms, all components on the signal path from the component that failed.
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
that must interact to reach the top level event.
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components
that must interact along the signal path to reach the top level event.
Where $C$ represents the set of components in a failure mode causation chain,
$c_i$ represents a component in $C$ and
the function $fm$ returns the failure modes for a given component, equation
@ -192,8 +192,8 @@ to consider to rigorously determine the causation chain
from the base component failure to the system level event.
%
The reasoning distance serves to show that when the causes of a top level
event are completely determined, a large amount of work not
typical of heuristic or intuitive interpretation is required.
event are completely determined, a large amount of work, not
typical of heuristic or intuitive interpretation, is required.
Reasoning distances will be large for complicated systems, and this is therefore a weakness in both
FMEA and FTA type analyses. This concept is developed further to create a metric for comparing
@ -223,7 +223,7 @@ introduce automation into the FMEA process~\cite{appswfmea} and code analysis
automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing
failure causation through the software hardware interfaces.
Although the SFMEA and hardware FMEAs are performed separately
Although the SFMEA and hardware FMEAs are performed separately,
some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive)
to be performed on the same system to provide insight into the
software hardware/interface~\cite{embedsfmea}.
@ -371,7 +371,7 @@ from the results of the {\fcs}. Because it is possible to model combinations of
criterion 6 is satisfied.
%
With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}.
The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
The failure modes of this new {\dc} are the symptoms of the {\fg} from which it was derived.% from.
This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed
modules available for re-use.
@ -520,7 +520,7 @@ and determine how they affect the operation of the potential divider.
For this example we look at single failure modes only.
For each failure mode in our {\fg} `potential~divider'
For each failure mode in our {\fg} `potential~divider',
we can assign a {\fc} number (see table \ref{tbl:pdfmea}).
Each {\fc} is analysed to determine the `symptom'
of the potential dividers' operation. For instance
@ -553,7 +553,7 @@ gives a high voltage output.%We can now consider the {\fg}
\vbox{
From table \ref{pdfmea} we can see that the resistor
From table \ref{tbl:pdfmea} we can see that the resistor
failures modes lead to some common symptoms.
By drawing directed edges, from the failure modes to the symptoms
we can show the relationships between the component failure modes and resultant symptoms.
@ -607,7 +607,7 @@ This is represented in the DAG in figure \ref{fig:fg1adag}.
We can now make a `derived component' to represent this potential divider.
This can be named \textbf{PD}.
This {\dc} will have two failure modes.
We can use the symbol $\derivec$ to represent taking the analysed
We can use the symbol $\derivec$ to represent the process of taking the analysed
{\fg} and creating from it, a {\dc}. The creation of the {\dc} \textbf{PD} is
represented in figure~\ref{fig:dc1}.
@ -885,8 +885,9 @@ This model now has two stages of analysis hierarchy, as represented in figure~\r
We can now expand the $PD$ {\dc} and have a full FMMD failure %mode
model
drawn as a DAG, which we can use to traverse to determine the possible causes to
drawn as a DAG, which we can use traverse, and thus determine all possible causes to
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier.
%
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies.
@ -947,7 +948,7 @@ defines a `part' thus
This definition of a `part' is useful, but consider combinatorial parts, such as quad packaged op-amps.
Here we have four op-amps on one chip. For FMEA we would consider each op-amp in the package
as a separate building block for a circuit.
We in fact need to go a little further than the above definition of a part,
We, in fact, need to go a little further than the above definition of a part,
and say that we want to define an atomic entity used as a building block.
%The term component, in American English, can mean a building block or a part.
%In British-English a component generally is given to mean the definition for part above.
@ -1240,7 +1241,7 @@ and from this determine the failure modes of all the components that belong to i
%The analysts interest is in the ways in which the components within the {\fg}
%can fail.
%
All the failure modes of all the components within an {\fg} are collected.
All the failure modes of all the components within a {\fg} are collected.
As each component mode holds a set of failure modes, the {\fg} represents a set of sets of failure modes.
We convert this
into a flat set
@ -1269,13 +1270,13 @@ and collecting symptoms of failure, is termed `symptom abstraction'.
}
{
This
is dealt with in detail using an algorithmic description, in section \ref{sec:symptom_abstraction}.
is dealt with in detail using an algorithmic description, in section \ref{sec:algorithmfmmd}.
}
% define difference between a \fg and a \dc
A {\fg} is a collection of components, a {\dc} is a new `theoretical'
component which has a set of failure modes, which
corresponds to the failure symptoms from the {\fg} from which it was derived.
component which has a set of failure modes,
corresponding to the failure symptoms from the {\fg} from which it was derived.
%
We consider a {\dc} as a black box, or component
for use.
@ -1329,13 +1330,13 @@ The lowest level in this hierarchy are the {\bcs}, the resistors and the op-amp.
%
The resistors are collected into a {\fg}, and the ${PD}$ derived component is created above them.
%
As this derived component inherits the properties of a component we may use
As this derived component inherits the properties of a component, we may use
it in {\fg} higher in the hierarchy.
%
The $PD$ derived component is now placed into a functional group
with the op-amp.
%
This {\fg} is now analysed and the a {\dc} created to
This {\fg} is now analysed and a {\dc} created to
represent the failure mode behaviour of the $INVAMP$.
%
We may now use the $INVAMP$ {\dc} in even higher level {\fgs}.
@ -1404,20 +1405,22 @@ as a data structure.
The `parts~list' is the
key reference point and starting point. % in the data structure.
Our base components are kept here.
From these the initial {\fgs} are formed, and from the first {\fgs}
From these the initial {\fgs} are formed, and from the first {\fgs},
the first {\dcs}. Two other data types/entities are required
however: we need to model environmental and operational states and
where they fit into the data structure.
A system will be expected to perform in a given environment.
%
Environment in the context of this study
means external influences the System could be expected to work under.
means external influences under which the System could be expected to work.% under.
%
A typical data sheet for an electrical component will give
a working temperature range for instance.
a working temperature range, for instance.
Mechanical components could be specified for stress and loading limits.
Systems or sub-systems may have distinct operational states. For instance a safety critical controller
Systems or sub-systems may have distinct operational states. For instance, a safety critical controller
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
authorised human intervention takes place.
A safety critical circuit may have a self test mode.
@ -1438,7 +1441,7 @@ With given environmental constraints, we can therefore eliminate some failure mo
\paragraph{Operational states.}
Within the field of safety critical engineering, we often encounter
sub-system that include test or self-test facilities.
sub-systems that include test or self-test facilities.
%
We also encounter degraded performance
(such as only performing functions in an emergency) and lockout conditions.
@ -1536,10 +1539,13 @@ The symptom abstraction process must always raise the abstraction level
for the newly created {\dc}.
Using $\abslev$ (as described in~\ref{sec:alpha}) to symbolise the fault abstraction level, we can now state:
$$ \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. $$
\begin{equation}
\label{eqn:abslevinc}
\derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1.
\end{equation}
\paragraph{Functional Groups may be indexed.}
We will typically have more than one {\fg} on each level of FMMD hierarchy (expect the top level where there will only be one).
We will typically have more than one {\fg} on each level of FMMD hierarchy (except the top level, where there will only be one).
We index the {\fgs} with a sub-script, and can then uniquely identify them using their level and their index.
For example ${\FG}^{3}_{2}$ would be the second {\fg} at the third level of abstraction in an FMMD hierarchy.
@ -1566,11 +1572,12 @@ failure modes being the failure symptoms of the {\fg} from which it was derived.
%A new {\dc} is created
%where its failure modes, are the symptoms from {\fg}.
%
Note that the component must have a higher abstraction level than the {\fg}
it was derived from.
Note that the {\dc} must have a higher abstraction level than the {\fg}
from which it was derived---or---in other words, the symptom abstraction process `$\derivedc$' increments
the abstraction level $abslev$, as stated in equation~\ref{eqn:abslevinc}.
The symptom abstraction process is described formally and algorithmically
in sections~\ref{sec:formalfmmd} and \ref{algotithmfmmd} respectively.
in sections~\ref{sec:formalfmmd} and \ref{sec:algorithmfmmd} respectively.
\paragraph{Surjective constraint applied to symptom collection.}
@ -1591,7 +1598,7 @@ the number of symptoms is guaranteed to be less than or equal to
the number of component failure modes. This means the top level {\dc} in a hierarchy should have a number of {\fms} less than or equal
to the sum of {\fms} in its base components.
In practise however, the number of symptoms greatly reduces as we traverse
In practise, however, the number of symptoms greatly reduces as we traverse
up the hierarchy.
This is echoed in real life systems, where the top level events/failures
are always orders of magnitude smaller than sum of {\fms} in its base components.
@ -1726,8 +1733,8 @@ with failure mode $b$. We can express this as $c_2 a \cup c_1 b$.
From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined.
How do we model the double failures that occur across the {\fgs}, for instance
$c_4 a \cup c_1 a$.
It could be argued that because functional groups are chosen for their functionality, and re-usability
$c_4 a \cup c_1 a$ where $c_4 a$ is a failure mode in FG1 and $c_1 a$ from FG2.
It could be argued that because functional groups are chosen for their functionality, and re-usability,
that component failures in one should not affect a different {\fg}, but this is a weak argument.
Merely double checking within {\fgs} would be marginally better than
only applying it to the most obvious critical elements of a system.
@ -1747,7 +1754,7 @@ double simultaneous combinations have not been resolved.
%
By applying double simultaneous checking until no single failures
can lead to a top level event, we
double failure move coverage.
implement traceable and provable, complete double failure mode coverage.
To extend the example in figure~\ref{fig:dubsim1} we can map the failure
scenarios.
@ -1778,7 +1785,7 @@ Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4
and these are the result of considering double simultaneous failures of its components.
A commonly used temperature measuring circuit, the $Pt100$, is analysed
for double simultaneous failure analysis in section~\ref{sec:pt100}.
for double simultaneous failure analysis in section~\ref{sec:Pt100}.
A software tool tracking the analysis process
could check that all possible single and double
@ -1837,7 +1844,10 @@ component level failure modes.
%
This allows cut sets~\cite{nasafta}[Ch.1p3]
to be determined by traversing the DAG from top level events down to their causes.
%
This has the added advantage of each {\fg} to {\dc} stage being a documented
failure mode reasoning entity. Compare this to traditional FMEA where
we only have one stage, base component failure mode to top level event.
% \item{ It should be capable of producing reliability and danger evaluation statistics.}
% The minimal cuts sets for the system level failures can have computed MTTF

2
submission_thesis/appendixes/formal.tex
View File

@ -3,7 +3,7 @@
\chapter{Formal Definitions}
\label{formalfmmd}
\label{sec:formalfmmd}
\section{An algebraic notation for identifying FMMD enitities}
Consider all `components' to exist as
members of a set $\mathcal{C}$.