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

..

Browse Source
This commit is contained in:
Robin Clark 2013-07-14 13:07:50 +01:00
parent 584b23bd3b
commit 3c24ddd24a
2 changed files with 238 additions and 209 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

429
submission_thesis/appendixes/algorithmic.tex
View File

@ -3,86 +3,94 @@
%\label{sec:symptom_abstraction} %\label{sec:symptom_abstraction}
\label{sec:algorithmfmmd} \label{sec:algorithmfmmd}
This section decribes the algorithm for performing one step of This chapter defines the process for performing one stage of the FMMD process i.e.
FMMD analysis from forming a {\fg} to creating a {\dc}.
analysing a {\fg} and determining from it a {\dc}. %This section decribes the algorithm for performing one step of
Algorithms using set theory describe the process. %FMMD analysis
It begins with an overview of the FMMD process, and then contrasts and compares it %analysing a {\fg} and determining from it a {\dc}.
to diagnostic analysis (fault finding). %
This discussion is followed by justification for using a bottom-up, forward search %Algorithms using set theory describe the process.
approach, along with modularisation. %An overview of the FMMD process is presented and it is then compared to
A theoretical example of FMMD using set theory is given. %diagnostic analysis (fault finding).
The algorithm for performing FMMD is then presented. %This is followed by justification for using a bottom-up, forward search
%approach, along with modularisation.
A theoretical example of FMMD using set theory is given following on to
a description of the process presented as an algorithm.
%for performing FMMD is then presented.
% %
\section{FMMD as a process.} % \section{FMMD as a process.}
In FMMD we take a group of components with a functional purpose, apply
FMEA, and then determine how the {\fg} can fail.
We determine the common symptoms of failure of the {\fg}, and then
create a new {\dc} which has, as its failure modes, the symptoms we determined.
\paragraph{FMMD and failure mode models.}
In essence, we take a {\fg} (a collection of components),
and apply FMEA analysis locally on this {\fg}.
% %
In this way, we determine how that {\fg} can fail. % % In FMMD we take a group of components with a functional purpose, apply
We can then go further and consider these to % % FMEA, and then determine how the {\fg} can fail.
be symptoms of failure of the {\fg}. % % We determine the common symptoms of failure of the {\fg}, and then
Because component failures will often manifest themselves as the same symptoms of failure, % % create a new {\dc} which has, as its failure modes, the symptoms we determined.
we are able to collect common symptoms of failure for the {\fg}.
% %
% \paragraph{FMMD and failure mode models.}
% %
With the collected common symptoms, we can treat the {\fg} % To perform FMMD a {\fg} (a collection of components) is chosen
as a component in its own right. % FMEA is applied to it.
This new component being derived from the {\fg}. % %
% % %In this way, we determine how that {\fg} can fail.
In the field of safety engineering this derived component corresponds to a low~level sub-system. % This gives us a set of failure modes for the {\fg}.
%The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model. % %
% % The {\fg} is not viewed as a component, or module,
Once the failure modes have been determined for a sub-system/{\dc}, % and the FMEA results considered
this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}. % be its symptoms of failure.
% % %
In this way a hierarchy to represent the fault behaviour % Because component failures will often manifest themselves as the same symptoms of failure,
of a system can be built from the bottom~up. This process can continue % we are able to collect common symptoms of failure for the {\fg}.
until there is a complete hierarchy representing the failure mode % %
behaviour of the entire system under analysis. % %
%FMMD hierarchy % With the collected common symptoms, we can treat the {\fg}
Using the FMMD technique, the hierarchy is built from the bottom up to % as a component in its own right. We term this a `{\dc}'.
ensure complete failure mode coverage. % %This new component being derived from the {\fg}.
Because the process is bottom-up, syntax checking and tracking can ensure that % %
no component failure mode can be overlooked. % %The `{dc}' can be thought of as a low~level sub-system.
Once a hierarchy is in place, it can be converted into a generic failure mode model. % %The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model.
\fmmdgloss % %
% % Once the failure modes have been determined for a sub-system/{\dc},
From the fault data model, automatic generation % this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}.
of FTA \cite{nasafta} (Fault Tree Analysis) and minimal cuts sets \cite{nucfta} are possible. % %
Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced % In this way a hierarchy to represent the fault behaviour
automatically\footnote{Where component failure mode statistics are available \cite{mil1991}}. % of a system can be built from the bottom~up. This process can continue
% % until there is a complete hierarchy representing the failure mode
This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy. % behaviour of the entire system under analysis.
We can term this stage in FMMD analysis as the `symptom extraction' process. % %FMMD hierarchy
The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy. % Using the FMMD technique, the hierarchy is built from the bottom up to
} % ensure complete failure mode coverage.
% Because the process is bottom-up, syntax checking and tracking can ensure that
% no component failure mode can be overlooked.
% Once a hierarchy is in place, it can be converted into a generic failure mode model.
% \fmmdgloss
% %
% %From the fault data model, automatic generation
% %of FTA \cite{nasafta} (Fault Tree Analysis) and minimal cuts sets \cite{nucfta} are possible.
% %Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced
% %automatically\footnote{Where component failure mode statistics are available \cite{mil1991}}.
% %
% This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy.
% We can term this stage in FMMD analysis as the `symptom abstraction' process.
% %The symptom abstraction or abstraction process, is the key process in creating an FMMD hierarchy.
% }
\vspace{40pt} \vspace{40pt}
%\today % %\today
\paragraph{Mutual exclusive property of the failure modes of a {\dc}} % \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
Because the symptoms have been collected from % Because the symptoms have been collected from
identical failure effects of the {\fg} they are mutually exclusive. % identical failure effects of the {\fg} they are mutually exclusive.
That is to say no failure mode effects of a component of a {\fg} % That is to say no failure mode effects of a component of a {\fg}
can be shared by a {\dc} failure mode. % can be shared by a {\dc} failure mode.
This ensures the mutually exclusive, or unitary state failure mode property, meaning % This ensures the mutually exclusive, or unitary state failure mode property, meaning
the failure modes of a {\dc} are suitable for use in higher level {\fgs}. % the failure modes of a {\dc} are suitable for use in higher level {\fgs}.
\subsection{Diagnostic analysis and Failure Mode Analysis}
Fault finding is a closely related discipline to failure mode analysis.
In diagnostic analysis, we generally start with a high level --- or system ---failure type.
We trace this from the top, de-composing the systems until we come to
a component or sub-system that has caused the failure.
While there are similarities between diagnostic failure mode tracing and static failure mode analysis
it is important to discuss the differences between them.
% %
% \subsection{Diagnostic analysis and Failure Mode Analysis}
% Fault finding is a closely related discipline to failure mode analysis.
% In diagnostic analysis, we generally start with a high level --- or system ---failure type.
% We trace this from the top, de-composing the systems until we come to
% a component or sub-system that has caused the failure.
% While there are similarities between diagnostic failure mode tracing and static failure mode analysis
% it is important to discuss the differences between them.
% %
%\subsection{Static Analysis} %\subsection{Static Analysis}
% %
%In the field of safety critical engineering, to comply with %In the field of safety critical engineering, to comply with
@ -105,80 +113,80 @@ it is important to discuss the differences between them.
%FMMD can model electrical, mechanical and software failures using a common notation, %FMMD can model electrical, mechanical and software failures using a common notation,
%and can thus model an integrated electro-mechanical software controlled system. %and can thus model an integrated electro-mechanical software controlled system.
% %
\subsection{Top Down or Natural Trouble Shooting} % \subsection{Top Down or Natural Trouble Shooting}
We firstly look at the `natural' trouble shooting process. % We firstly look at the `natural' trouble shooting process.
Fault finding is instinctively performed from the top-down. % Fault finding is instinctively performed from the top-down.
A faulty piece of equipment is examined and will have a % A faulty piece of equipment is examined and will have a
symptom or specific fault. % symptom or specific fault.
%
The suspected area or sub-system within the
equipment will be looked into next.
%
The trouble shooter will look for behaviour that is unusual or incorrect
to determine the next area or sub~system to look into, each time
moving to a more detailed lower level.
Specific measurements
and checks will be made, and finally a component or a low level sub-system
will be found to be faulty.
A natural fault finding process is thus top~down.
Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
Fault tree analysis is a top down static failure mode analysis technique~\cite{nucfta,nasafta}.
% % % %
%% to fool the graphics insertion to make it compatible % The suspected area or sub-system within the
%% with thesis and papaer level directories. % equipment will be looked into next.
% % % %
%% ln -s . symptom_ex_process % The trouble shooter will look for behaviour that is unusual or incorrect
% to determine the next area or sub~system to look into, each time
% moving to a more detailed lower level.
% Specific measurements
% and checks will be made, and finally a component or a low level sub-system
% will be found to be faulty.
% A natural fault finding process is thus top~down.
% Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
% Fault tree analysis is a top down static failure mode analysis technique~\cite{nucfta,nasafta}.
% %%
% %% to fool the graphics insertion to make it compatible
% %% with thesis and papaer level directories.
% %%
% %% ln -s . symptom_ex_process
% %%
%
% %% insert diagram here
%
% \begin{figure}[h]
% \centering
% \includegraphics[width=300pt,bb=0 0 587 445,keepaspectratio=true]{./CH4_FMMD/top_down_de_comp.png}
% % top_down_de_comp.jpg: 587x445 pixel, 72dpi, 20.71x15.70 cm, bb=0 0 587 445
% \caption{Top Down Failure De-Composition Diagram}
% \label{fig:tdh}
% \end{figure}
%
% %%
% %% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT
% %% this study needs to use this term to keep the interested/in context.
% The term `sub-system' is typically used in top down methodologies.
% It has two equivalents in FMMD.
% Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'.
% In FMMD a {\fg} becomes a {\dc} after analysis.
% The term sub-system will be used alongside both {\fg} and {\dc} where necessary.
%
% \subsection{Top-Down System De-Composition}
%
% A top down fault analysis system will take a system and divide it into
% several sub-systems, and determine the safety dependencies
% of the System on those sub-systems. In the case of large complicated
% systems, the sub-systems themselves may be broken down into simpler sub-systems.
% A top down hierarchy is shown in figure \ref{fig:tdh}.
%
% \subsection{FMMD - Bottom~up Analysis}
% The FMMD methodology does not follow the `natural fault finding' or top down approach,
% it instead works from the bottom up.
% Starting with a collection of base~components that form
% a simple functional group, the effect of all component error modes are
% examined, as to their effect on the functional group.
% % % %
% The effects on the functional group can then be collected as common symptoms,
%% insert diagram here % and now we may treat the functional group as a component, as it has a known set of failure modes.
\begin{figure}[h]
\centering
\includegraphics[width=300pt,bb=0 0 587 445,keepaspectratio=true]{./CH4_FMMD/top_down_de_comp.png}
% top_down_de_comp.jpg: 587x445 pixel, 72dpi, 20.71x15.70 cm, bb=0 0 587 445
\caption{Top Down Failure De-Composition Diagram}
\label{fig:tdh}
\end{figure}
% % % %
%% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT % By reusing the `components' derived from functional~groups, an entire
%% this study needs to use this term to keep the interested/in context. % hierarchical failure mode model of the system can be built.
The term `sub-system' is typically used in top down methodologies. % That is to say, using derived components in higher level functional groups,
It has two equivalents in FMMD. % a hierarchy is naturally formed.
Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'. % %
In FMMD a {\fg} becomes a {\dc} after analysis. % By working from the bottom up, we can trace all possible sources
The term sub-system will be used alongside both {\fg} and {\dc} where necessary. % that could cause a particular mode of equipment failure.
% This means that at the design stage of a product all component failure
\subsection{Top-Down System De-Composition} % modes must be considered. A benefit of FMMD is complete failure mode coverage.
% This also means that it is possible to obtain statistical estimates based on the known reliabilities
A top down fault analysis system will take a system and divide it into % of components~\cite{mil1991}.
several sub-systems, and determine the safety dependencies % %It also means that every component failure mode must at the very least be considered.
of the System on those sub-systems. In the case of large complicated
systems, the sub-systems themselves may be broken down into simpler sub-systems.
A top down hierarchy is shown in figure \ref{fig:tdh}.
\subsection{FMMD - Bottom~up Analysis}
The FMMD methodology does not follow the `natural fault finding' or top down approach,
it instead works from the bottom up.
Starting with a collection of base~components that form
a simple functional group, the effect of all component error modes are
examined, as to their effect on the functional group.
%
The effects on the functional group can then be collected as common symptoms,
and now we may treat the functional group as a component, as it has a known set of failure modes.
%
By reusing the `components' derived from functional~groups, an entire
hierarchical failure mode model of the system can be built.
That is to say, using derived components in higher level functional groups,
a hierarchy is naturally formed.
%
By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment failure.
This means that at the design stage of a product all component failure
modes must be considered. A benefit of FMMD is complete failure mode coverage.
This also means that it is possible to obtain statistical estimates based on the known reliabilities
of components~\cite{mil1991}.
%It also means that every component failure mode must at the very least be considered.
%{ %{
@ -237,20 +245,28 @@ of components~\cite{mil1991}.
\nocite{safeware} \nocite{safeware}
\section{Overview of the FMMD analysis Process} \section{Overview of the FMMD analysis Process}
The FMMD process is described in chapter~\ref{sec:chap4}
With the FMEA results for a {\fg} common symptoms of failure can be determined. This is termed `symptom~abstraction'.
% TO DO: separate these two: % TO DO: separate these two:
%
\paragraph{FMMD analysis Objective.} % \paragraph{FMMD analysis Objective.}
The objective of `symptom abstraction' is to analyse the functional~group and find % The objective of `symptom abstraction' is to analyse the functional~group and find
how it can fail % how it can fail
when specified components within it fail. % when specified components within it fail.
Once we know how a functional~group can fail, we can treat it as a component or sub-system % Once we know how a functional~group can fail, we can treat it as a component or sub-system
% with its own set of failure modes.
Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system
with its own set of failure modes. with its own set of failure modes.
This process allows us to modularise and simply FMEA analysis of systems.
The FMEA process is reviewed here, introducing
formal definitions that will be used in the description of FMMD
presented as an algorithm.
\paragraph{FMEA applied to the Functional Group.} \paragraph{FMEA applied to the Functional Group.}
As the functional~group contains a set of components, the failure~modes As the functional~group contains a set of components, the failure~modes
that we have to consider are all the failure modes of its components, as that we have to consider are all the failure modes of its components, as
developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$. developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
The aim here is to build `test cases', combinations of failure~modes The aim here is to build `test cases', combinations of failure~modes
to use as failure~mode analysis scenarios. to use as failure~mode analysis scenarios.
%Each failure mode (or combination of) investigated is termed a `test case'. %Each failure mode (or combination of) investigated is termed a `test case'.
@ -260,16 +276,21 @@ The component failure modes in each test case
are examined with respect to their effect on the functional~group. are examined with respect to their effect on the functional~group.
% %
The aim of this analysis is to find out how the functional~group fails given The aim of this analysis is to find out how the functional~group fails given
the test case conditions, for each test case. each test case.
%
The goal of the process is to produce a set of failure modes from the perspective of the user of the functional~group. The goal of the process is to produce a set of failure modes from the perspective of the user of the functional~group.
% %
In other words, if a designer is handed a piece of circuitry to use, he need not be concerned with In other words, if a designer is handed a piece of circuitry to use, he need not be concerned with
the failure modes of its components. He is handed it as a derived component, which has the failure modes of its components.
a set of failure mode symptoms. The designer can now treat this piece of circuitry as a black box, or {\dc}. %
He is handed it as a derived component, which has a set of failure mode symptoms.
%
The designer can now treat this piece of circuitry as a black box, or {\dc}.
\paragraph{Environmental Conditions or Applied States.} \paragraph{Environmental Conditions or Operational States.}
Each test case must be considered for all applied/operational states and Each test case must be considered for all %applied/
operational states and
%in the for the case of each applied states or %in the for the case of each applied states or
environmental conditions to which it may be exposed. In this way, all possible environmental conditions to which it may be exposed. In this way, all possible
failure mode behaviour due to all the conditions that can be applied to a test case will be examined. failure mode behaviour due to all the conditions that can be applied to a test case will be examined.
@ -310,42 +331,43 @@ will both cause the same failure symptom; $no\_sound$ !
\paragraph{Collection of Symptoms.} \paragraph{Collection of Symptoms.}
%Looking at the %Looking at the
examining failure from the % examining failure from the
functional group perspective failure modes, we collect % functional group perspective failure modes, we collect
some of these into common `symptoms' where possible. % some of these into common `symptoms' where possible.
% % %
Some test cases may cause % Some test cases may cause
unique failure modes at the functional group level. These can be termed % unique failure modes at the functional group level. These can be termed
lone symptoms. % lone symptoms.
% % %
The common symptoms of failure and lone~symptoms are identified and collected. % The common symptoms of failure and lone~symptoms are identified and collected.
% %
% We can now create a new component and consider the symptoms as its failure modes.
Common symptoms of failure of the {\fg} are collected.
% %
We can now create a new component and consider the symptoms as its failure modes. We can now create a new component and consider the symptoms as its failure modes.
% %
We call this new component a `{\dc}'. We call this new component a `{\dc}'.
% %
%Note that here, b %Note that here, b
Because the process is bottom up, we can ensure that all failure modes Because the FMMD process is bottom up, we can ensure that all failure modes
from the components in a functional~group have been handled\footnote{Software can check that all from the components in a {\fg} have been considered.
failure modes have been included in at least one test case, and modelled individually. %\footnote{Software can check that all failure modes have been included in at least one test case, and modelled individually. For Double
%Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}.
% %
For Double Were failure~modes to be missed, the resulting failure mode model would be %dangerously
Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}.
%
Were any failure~modes missed, the failure mode model could be %dangerously
incomplete. incomplete.
% %
It is possible here for an automated system to flag un-handled failure modes, It is possible here for an automated system to flag un-handled failure modes.
which solves the main failing of top~down methodologies %which solves the main failing of top~down methodologies
%\cite{topdownmiss}, %\cite{topdownmiss},
that of not %that of not
guaranteeing to model all component failure modes. %guaranteeing to model all component failure modes.
%\ref{requirement at the start} %\ref{requirement at the start}
\section{The Process} \section{A single stage of the FMMD process}
\paragraph{To analyse a base level Derived~Component/sub-system} %\paragraph{To analyse a base level Derived~Component/sub-system}
To summarise: To summarise:
@ -365,12 +387,17 @@ form `test cases'.
\item Using the `test cases' as scenarios to examine the effects of component failures, \item Using the `test cases' as scenarios to examine the effects of component failures,
we determine the failure~mode behaviour of the functional group. we determine the failure~mode behaviour of the functional group.
% %
This is a human process, involving detailed analysis of the component failure modes in the test case on the {\fg}. This is a human process, applying FMEA for each test case.
Where specific environment conditions, or applied states are germane to the {\fg}, these must be examined %
Where specific environment conditions, or operational states are germane to the {\fg}, these must also be examined
for each test case. for each test case.
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}. %
\item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail. \item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the {\fg}}.
\item A new `derived component' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component. %
\item The common~symptoms are now the fault mode behaviour of the {\fg}.
i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.
%
\item A new `{\dc}' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component.
\end{itemize} \end{itemize}
@ -543,8 +570,10 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Defining the analysis process \\ as a function} \subsection{Defining the analysis process as a function}
We define one stage of the FMMD process, taking a {\fg} and deriving a {\dc}
by the symbol `D'.
Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$
is the set of all derived components, we can define the symptom abstraction process thus: is the set of all derived components, we can define the symptom abstraction process thus:
$$ $$
@ -577,7 +606,7 @@ because we can obtain a failure mode set,
(the failure mode set we have named $DCFM$). (the failure mode set we have named $DCFM$).
Thus we can now move up another abstraction level by applying Thus we can now move up another abstraction level by applying
symptom abstraction/extraction to the functional group symptom abstraction to the {\fg}
$FG_{derived}$ shown in equation \ref{eqn:fgderived}. $FG_{derived}$ shown in equation \ref{eqn:fgderived}.
\begin{equation} \begin{equation}
@ -662,7 +691,7 @@ $$
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} . \derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
$$ $$
The next section describes the details of the symptom extraction process. The next section describes the details of the symptom abstraction process.
} }
@ -671,26 +700,26 @@ The next section describes the details of the symptom extraction process.
%\section{A Formal Algorithmic Description of `Symptom Abstraction'} %\section{A Formal Algorithmic Description of `Symptom Abstraction'}
\section{Algorithmic Description} \section{Algorithmic Description}
\label{sec:symptomabs} \label{sec:symptomabs}
The algorithm for {\em symptom extraction} is described in The algorithm for {\em symptom abstraction} is described in
this section this section
%describes the symptom abstraction process %describes the symptom abstraction process
using set theory and procedural descriptions. using set theory and procedural descriptions.
% %
The {\em symptom abstraction process} (given the symbol `$\derivec$') takes a functional group $FG$ The {\em symptom abstraction process} (given the symbol `$\derivec$', D for derive) takes a functional group $FG$
and a new derived~component/sub-system $DC$. and a new derived~component/sub-system $DC$.
%The sub-system $SS$ is a collection %The sub-system $SS$ is a collection
%of failure~modes of the sub-system. %of failure~modes of the sub-system.
Note that % Note that
$DC$ is a derived component at a higher level of fault analysis abstraction % $DC$ is a derived component at a higher level of fault analysis abstraction
than the functional~group from which it was derived. % than the functional~group from which it was derived.
%Thus, % %Thus,
$DC$ can now be treated % $DC$ can now be treated
as a component with a known set of failure modes. % as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels} \paragraph{Enumerating abstraction levels}
\label{sec:abstractionlevel} \label{sec:abstractionlevel}
We can assign an attribute of abstraction level $\abslev$ to As described in section~\ref{sec:alpha} we can assign an attribute of abstraction level $\abslev$ to
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$). components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
For a base component, let the abstraction level be zero. For a base component, let the abstraction level be zero.
If we apply the symptom abstraction process $\derivec$, If we apply the symptom abstraction process $\derivec$,
@ -776,15 +805,15 @@ The function $fm$ applied to a component returns the failure modes for that comp
Thus its domain is the set of all components $\mathcal{C}$ and its range Thus its domain is the set of all components $\mathcal{C}$ and its range
is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$. is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$.
$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{\FG} $$ $$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$
A {\fg} is a collection of components such that $\mathcal{\FG} \in \mathcal{P}\,\mathcal{C}$. A {\fg} is a collection of components $G$ such that $\mathcal{G} \in \mathcal{P}\,\mathcal{C}$.
The function $fm$ can be overloaded with a functional group $\mathcal{\FG}$ as its domain The function $fm$ can be overloaded with a {\fg} $\mathcal{G}$ as its domain
and the power-set of all failure modes as its range. and the power-set of all failure modes as its range.
$$ fm: \mathcal{\FG} \rightarrow \mathcal{P}\,\mathcal{F} $$ $$ fm: \mathcal{\FG} \rightarrow \mathcal{P}\,\mathcal{G} $$
% %
%%Let $FG$ be the set of components in the functional group under analysis, and $c$ %%Let $FG$ be the set of components in the functional group under analysis, and $c$
@ -855,7 +884,7 @@ the failure modes for a particular test case have been chosen by
a human operator and are additional to those chosen by the automated process (i.e they are a human operator and are additional to those chosen by the automated process (i.e they are
special case test cases involving multiple failure modes) special case test cases involving multiple failure modes)
The function \textbf{unitary state} means that all test The function \textbf{unitary state} means that all test
cases can have no pairs of failure modes sourced from the same component. cases can have no pairs of failure modes sourced from the same component, see section~\ref{sec:unitarystate}.
\label{sec:completetest} \label{sec:completetest}

2
submission_thesis/appendixes/detailed_analysis.tex
View File

@ -826,7 +826,7 @@ FMMD analysis tables from chapter~\ref{sec:chap6}.
\end{tabular} \end{tabular}
\end{table} \end{table}
} }
\clearpage/pr \clearpage
\subsection{Gnuplot script for hypothetical XFMEA FMMD reasoning distance comparision} \subsection{Gnuplot script for hypothetical XFMEA FMMD reasoning distance comparision}
\label{sec:gnuplotxfmeafmmdcomp} \label{sec:gnuplotxfmeafmmdcomp}