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

445
submission_thesis/appendixes/algorithmic.tex
View File

@ -3,86 +3,94 @@
%\label{sec:symptom_abstraction}
\label{sec:algorithmfmmd}
This section decribes the algorithm for performing one step of
FMMD analysis
analysing a {\fg} and determining from it a {\dc}.
Algorithms using set theory describe the process.
It begins with an overview of the FMMD process, and then contrasts and compares it
to diagnostic analysis (fault finding).
This discussion 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.
The algorithm for performing FMMD is then presented.
This chapter defines the process for performing one stage of the FMMD process i.e.
from forming a {\fg} to creating a {\dc}.
%This section decribes the algorithm for performing one step of
%FMMD analysis
%analysing a {\fg} and determining from it a {\dc}.
%
%Algorithms using set theory describe the process.
%An overview of the FMMD process is presented and it is then compared to
%diagnostic analysis (fault finding).
%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.}
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.
We can then go further and consider these to
be symptoms of failure of the {\fg}.
Because component failures will often manifest themselves as the same symptoms of failure,
we are able to collect common symptoms of failure for the {\fg}.
%
%
With the collected common symptoms, we can treat the {\fg}
as a component in its own right.
This new component being derived from the {\fg}.
%
In the field of safety engineering this derived component corresponds to a low~level sub-system.
%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.
%
Once the failure modes have been determined for a sub-system/{\dc},
this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}.
%
In this way a hierarchy to represent the fault behaviour
of a system can be built from the bottom~up. This process can continue
until there is a complete hierarchy representing the failure mode
behaviour of the entire system under analysis.
%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 extraction' process.
The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy.
}
% \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.}
%
% To perform FMMD a {\fg} (a collection of components) is chosen
% FMEA is applied to it.
% %
% %In this way, we determine how that {\fg} can fail.
% This gives us a set of failure modes for the {\fg}.
% %
% The {\fg} is not viewed as a component, or module,
% and the FMEA results considered
% be its symptoms of failure.
% %
% Because component failures will often manifest themselves as the same symptoms of failure,
% we are able to collect common symptoms of failure for the {\fg}.
% %
% %
% With the collected common symptoms, we can treat the {\fg}
% as a component in its own right. We term this a `{\dc}'.
% %This new component being derived from the {\fg}.
% %
% %The `{dc}' can be thought of as a low~level sub-system.
% %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.
% %
% Once the failure modes have been determined for a sub-system/{\dc},
% this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}.
% %
% In this way a hierarchy to represent the fault behaviour
% of a system can be built from the bottom~up. This process can continue
% until there is a complete hierarchy representing the failure mode
% behaviour of the entire system under analysis.
% %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}
%\today
\paragraph{Mutual exclusive property of the failure modes of a {\dc}}
Because the symptoms have been collected from
identical failure effects of the {\fg} they are mutually exclusive.
That is to say no failure mode effects of a component of a {\fg}
can be shared by a {\dc} failure mode.
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}.
\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.
%
% %\today
% \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
% Because the symptoms have been collected from
% identical failure effects of the {\fg} they are mutually exclusive.
% That is to say no failure mode effects of a component of a {\fg}
% can be shared by a {\dc} failure mode.
% 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}.
%
% \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}
%
%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,
%and can thus model an integrated electro-mechanical software controlled system.
%
\subsection{Top Down or Natural Trouble Shooting}
We firstly look at the `natural' trouble shooting process.
Fault finding is instinctively performed from the top-down.
A faulty piece of equipment is examined and will have a
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
%% 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,
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.
% \subsection{Top Down or Natural Trouble Shooting}
% We firstly look at the `natural' trouble shooting process.
% Fault finding is instinctively performed from the top-down.
% A faulty piece of equipment is examined and will have a
% 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
% %% 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,
% 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}
\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:
\paragraph{FMMD analysis Objective.}
The objective of `symptom abstraction' is to analyse the functional~group and find
how it can 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
%
% \paragraph{FMMD analysis Objective.}
% The objective of `symptom abstraction' is to analyse the functional~group and find
% how it can 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
% 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.
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.}
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
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
to use as failure~mode analysis scenarios.
%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.
%
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.
%
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
a set of failure mode symptoms. The designer can now treat this piece of circuitry as a black box, or {\dc}.
the failure modes of its components.
%
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
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.
@ -310,42 +331,43 @@ will both cause the same failure symptom; $no\_sound$ !
\paragraph{Collection of Symptoms.}
%Looking at the
examining failure from the
functional group perspective failure modes, we collect
some of these into common `symptoms' where possible.
%
Some test cases may cause
unique failure modes at the functional group level. These can be termed
lone symptoms.
%
The common symptoms of failure and lone~symptoms are identified and collected.
% examining failure from the
% functional group perspective failure modes, we collect
% some of these into common `symptoms' where possible.
% %
% Some test cases may cause
% unique failure modes at the functional group level. These can be termed
% lone symptoms.
% %
% 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 call this new component a `{\dc}'.
%
%Note that here, b
Because the 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
failure modes have been included in at least one test case, and modelled individually.
Because the FMMD process is bottom up, we can ensure that all failure modes
from the components in a {\fg} have been considered.
%\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
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
Were failure~modes to be missed, the resulting failure mode model would be %dangerously
incomplete.
%
It is possible here for an automated system to flag un-handled failure modes,
which solves the main failing of top~down methodologies
It is possible here for an automated system to flag un-handled failure modes.
%which solves the main failing of top~down methodologies
%\cite{topdownmiss},
that of not
guaranteeing to model all component failure modes.
%that of not
%guaranteeing to model all component failure modes.
%\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:
@ -365,12 +387,17 @@ form `test cases'.
\item Using the `test cases' as scenarios to examine the effects of component failures,
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}.
Where specific environment conditions, or applied states are germane to the {\fg}, these must be examined
This is a human process, applying FMEA for each test case.
%
Where specific environment conditions, or operational states are germane to the {\fg}, these must also be examined
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 A new `derived component' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component.
%
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the {\fg}}.
%
\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}
@ -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}$
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$).
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}.
\begin{equation}
@ -662,7 +691,7 @@ $$
\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{Algorithmic Description}
\label{sec:symptomabs}
The algorithm for {\em symptom extraction} is described in
The algorithm for {\em symptom abstraction} is described in
this section
%describes the symptom abstraction process
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$.
%The sub-system $SS$ is a collection
%of failure~modes of the sub-system.
Note that
$DC$ is a derived component at a higher level of fault analysis abstraction
than the functional~group from which it was derived.
%Thus,
$DC$ can now be treated
as a component with a known set of failure modes.
% Note that
% $DC$ is a derived component at a higher level of fault analysis abstraction
% than the functional~group from which it was derived.
% %Thus,
% $DC$ can now be treated
% as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels}
\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$).
For a base component, let the abstraction level be zero.
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
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.
$$ 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$
@ -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
special case test cases involving multiple failure modes)
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}

2
submission_thesis/appendixes/detailed_analysis.tex
View File

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