Changed the UML to be consistent

and added copy to introduce the instance diagram.

submission_thesis/CH4_FMMD/copy.tex

@@ -1599,6 +1599,25 @@ We may now use the  {\em INVAMP} {\dc} in even higher level {\fgs}.
 An analysis report is generated for each stage in the FMMD  % {\fg} to {\dc}
 process. %\footnote
 %
+The UML model in figure~\ref{fig:cfg} describes a hierarchical structure similar to that of a file system with directories,
+but instead of directory and file nodes, there are closely linked {\fgs} and {\dcs} pairs, that perform a similar structural functions. 
+%
+The NONINVAMP example is shown as an instance
+diagram below (see figure~\ref{fig:instanceNONINVAMP}). 
+%
+By tracing the component failure modes to symptoms
+(which would defined in the analysis reports) 
+the failure causation logic can be followed and thus the DAG's derived (see figure~\ref{fig:noninvdag1}).
+%
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt]{./CH4_FMMD/instance_diagram_NONINVAMP.png}
+ % instance_diagram_NONINVAMP.png: 1162x657 pixel, 72dpi, 40.99x23.18 cm, bb=0 0 1162 657
+ \caption{Instance diagram for the NONINVAMP example.}
+ \label{fig:instanceNONINVAMP}
+\end{figure}
+
+
 %
 \paragraph{Traceability and quality of FMMD analysis.}
 By having an analysis report report for each analysis stage, %i.e. {\fg} to {\dc},
@@ -1756,496 +1775,7 @@ The abstraction level concept is formally defined in section~\ref{sec:abstractio
 
 
 
-% 
+ 
-% %$$ \mathcal{fm}(C) \rightarrow S $$
-% %$$ {fm}(C) \rightarrow S $$
-% \paragraph{Abstraction Levels of {\fgs} and {\dcs}}
-% 
-% 
-% \label{sec:indexsub}
-% We can indicate the abstraction level of a component by using a superscript.
-% Thus for the component $c$, where it is a `base component' we can assign it
-% the abstraction level zero, $c^0$. Should we wish to index the components
-% (for example as in a product parts-list) we can use a sub-script.
-% Our base component (if first in the parts-list) could now be uniquely identified as
-% $c^0_1$.
-% 
-% We can further define the abstraction level of a {\fg}.
-% 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
-% `${\FG}^0$'. % The functional group set may also be indexed.
-% 
-% We can apply symptom abstraction to a {\fg} to find
-% its symptoms. 
-% %We are interested in the failure modes
-% %of all the components in the {\fg}. An analysis process
-% We define the symptom abstraction process with the symbol  `$\derivec$'.
-% % is applied to the {\fg}.
-% %
-% The $\derivec$ function takes a {\fg}
-% as an argument and returns a newly created {\dc}.
-% %
-% %The $\derivec$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}.
-% 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:
-% 
-% \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 (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.
-% 
-% \paragraph{The symptom abstraction process in outline.} 
-% The $\derivec$ function processes a functional group and returns a derived component.
-% Firstly, all the failure modes from all the components in the {\fg} 
-% are used to create failure scenarios, which can be single failure modes
-% or combinations of failure modes where unitary state failure mode constraints do not apply.
-% %
-% With all the failure scenarios, an analyst can   
-% determine how each scenario will affect the {\fg}.
-% This will give one failure mode behaviour result for each failure scenario.
-% With these results, we collect common symptoms.
-% That is to say, that many of the resultant failure modes, will exhibit the same symptom of failure from the perspective
-% of a user of the {\fg}.
-% %
-% We now can treat the functional group as a sort of `super~component'.
-% %
-% In order to make this new `super~component' usable, it needs to be in the form of a
-% component, that is, it has a name, and a set of failure modes.
-% %
-% We can do this by creating a new {\dc} and assigning a name to it, and assigning its set of 
-% 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 {\dc} must have a higher abstraction level than the {\fg}
-% from which it was derived---or---in other words, the symptom abstraction process `$\derivec$' 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{sec:algorithmfmmd} respectively.
-% 
-% 
-% \paragraph{Surjective constraint applied to symptom collection.}
-% We can stipulate that symptom collection process is surjective~\cite{dmfnt}.
-% % i.e. $ \forall f in F $ 
-% By stipulating surjection for symptom collection, we ensure
-% that each component failure mode maps to at least one symptom.
-% This also ensures that all symptoms have at least one component failure
-% mode (i.e. one or more failure modes that caused it).
-% %
-% 
-% \subsection{FMMD Hierarchy}
-% 
-% By applying stages of analysis to higher and higher abstraction
-% levels, we can converge to a complete failure mode model of the system under analysis.
-% Because the symptom abstraction process is defined as surjective (from component failure modes to symptoms)
-% 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
-% 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.
-% %This is a natural process. When we have complicated systems
-% %they always have a small number of system failure modes in comparison to
-% %the number of failure modes in its sub-systems/components..
-% 
-% 
-% \subsection{Derived Component like concepts in safety literature}
-% 
-% Integrated components such as OP-AMPS are already treated as {\dcs}
-% in literature.
-% An Op-AMP is an integrated circuit comprising some hundred or so individual components
-% but in the literature ~\cite{fmd91}[3-116] is is described as a simple component with a set of failure modes.
-% 
-% % Idea stage on this section, integrated circuits and some compond parts (like digital resistors)
-% % are treated like base components. i.e. this sets a precedent for {\dcs}.
-% % 
-% % RE WRITE ---- concept is that some complicated components, like 741 are  treated as simple components 
-% % in the literature.
-% % 
-% % \begin{itemize}
-% %  \item Look at OPAMP circuits, pick one (say $\mu$741)
-% % %  \item Digital transistor perhaps, inside two resistors and a transistor.
-% % %  \item outline a proposed FMMD analysis
-% % %  \item Show FMD-91 OPAMP failure modes -- compare with FMMD
-% % \end{itemize}
-% % 
-% % % The gas burner standard (EN298~\cite{en298}), only considers OPEN and SHORT for resistors
-% % (and for some types of resistors OPEN only).
-% % FMD-91~\cite{fmd91}(the US military failure modes guide) also includes `parameter change' in its description of resistor failure modes.
-% % Now a resistor will generally only suffer parameter change when over stressed.
-% % EN298 stipulates down rating by 60\% to maximum stress
-% % possible in a circuit. So even if you have a resistor that preliminary tells you would
-% % never be subjected to say more than 5V, but there is say, a 24V rail
-% % on the circuit, you have to choose resistors able to cope with the 24V
-% % stress/load and then down rate by 60\%. That is to say the resitor should be rated for a maximum
-% % voltage of $ > 38.4V$ and should be rated 60\% higher for its power consumption at $38.4V$.
-% % Because of down-rating, it is reasonable to not have to consider parameter change under EN298 approvals.
-% % 
-% % \clearpage
-% % Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself.
-% 
-% 
-% % \subsection{{\fgs} Sharing components and Hierarchy}
-% % 
-% % With electronics we need to follow the signal path to make sense of failure modes
-% % effects on other parts of the circuit further down that path.
-% % %{\fgs} will naturally have to be in the position of starter 
-% % A power-supply is naturally first in a signal path (or failure reasoning path).
-% % That is to say, if the power-supply is faulty, its failure modes are likely to affect
-% % the {\fgs} that have to use it.
-% % 
-% % This means that most electronic components should be placed higher in an FMMD
-% % hierarchy than the power-supply.
-% % A shorted de-coupling capactitor caused a `symptom' of the power-supply, 
-% % and an open de-coupling capactitor should  be considered a `failure~mode' relevant to the logic chip.
-% % % to consider.
-% % 
-% % If components can be shared between functional groups, this means that components
-% % must be shareable between {\fgs} at different levels in the FMMD hierarchy.
-% % This hierarchy and an optionally shared de-coupling capacitor (with line highlighted in red and dashed)  are shown
-% % in figure~\ref{fig:shared_component}.
-% % 
-% % \begin{figure}
-% %  \centering
-% %  \includegraphics[width=250pt,keepaspectratio=true]{CH5_Examples/shared_component.png}
-% %  % shared_component.png: 729x670 pixel, 72dpi, 25.72x23.64 cm, bb=0 0 729 670
-% %  \caption{Optionally shared Component}
-% %  \label{fig:shared_component}
-% % \end{figure}
-% 
-% % \subsection{Hierarchy and structure}
-% % By having this structure, the logic circuit element, can accept failure modes from the 
-% % power-supply (for instance these might, for the sake of example  include: $NO\_POWER$, $LOW\_VOLTAGE$, $HIGH\_VOLTAGE$, $NOISE\_HF$, $NOISE\_LF$.
-% % Our logic circuit may be able to cope with $LOW\_VOLTAGE$ and $NOISE\_LF$, but react with a serious symptom to $NOISE\_HF$ say.
-% % But in order to process these failure modes it must be at a higher stage in the FMMD hierarchy.
-% 
-% %\pagebreak[4]
-% 
-% 
-% 
-% \section{Double Simultaneous Failures}
-% 
-% The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low.
-% However, some critical systems have to consider these type of eventualities.
-% The burner control industry has to consider double failures, as specified in European Norm 
-% EN298~\cite{en298}. EN298 does not specifically state that
-% double simultaneous failures must be considered. What it does say is that
-% in the event of a lockout---a condition where an error has been detected and 
-% the equipment moves to a safe non-functioning state---no secondary failure may cause a dangerous condition.
-% %
-% This is slightly vague: there are so many possible component failures that could
-% cause a secondary failure, that it is very difficult not to interpret this
-% as meaning we have to cater for double simultaneous failures for the most critical sections
-% of a burner control system. 
-% %
-% In practise---in the field of EN298: burner controllers---this means triple safeguards to ensure the fuel
-% is not allowed to flow under an error condition. This would of course leave the possibility of
-% other more complex double failures tricking the controller into thinking the 
-% combustion was actually safe when it was not. 
-% %
-% It would be impractical to
-% perform the number of checks (as the checking is a time-consuming human process) required of RFMEA on a system as complex as a  burner controller.
-% 
-% It has been shown that, for all but trivial small systems, double failure mode checking
-% is impossible from a practical perspective.
-% FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature 
-% of choosing {\fgs} we will not (in the initial stages) be cross checking all possible
-% combinations of double failures in all of the components.
-% 
-% The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks 
-% to model failure mode scenarios. The failure scenario is defined by the contours that enclose it.
-% Consider a system which has four components $c_1 \ldots c_4$.
-% Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$.
-% Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$.
-% 
-% We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group.
-% For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing
-% with failure mode $b$. We can express this as $c_2 a \cup c_1 b$.
-% 
-% 
-% \begin{figure}[h]
-%  \centering
-%  \includegraphics[width=300pt,keepaspectratio=true]{CH5_Examples/dubsim1.png}
-%  % dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330
-%  \caption{Simultaneous Failure Mode Scenarios}
-%  \label{fig:dubsim1}
-% \end{figure}
-% 
-% 
-% 
-% 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$ 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.
-% 
-% What is really required is a way that all double simultaneous failures
-% are checked.
-% 
-% One way of doing this is to apply double failure mode
-% checking to all {\fgs} higher up in the hierarchy.
-% 
-% This guarantees to check the symptoms caused by the 
-% failure modes in the other {\fgs} with the symptoms
-% derived from the other {\fgs} modelling for double failures.
-% %
-% By traversing down the tree, we can automatically determine which
-% double simultaneous combinations have not been resolved.
-% %
-% By applying double simultaneous checking until no single failures
-% can lead to a top level event, we
-% implement traceable and provable, complete double failure mode coverage.
-% 
-% To extend the example in figure~\ref{fig:dubsim1} we can map the failure 
-% scenarios.
-% For Functional Group 1 (FG1), let us map:
-% \begin{eqnarray*}
-%   FS1 & \mapsto & S1   \\
-%   FS2 & \mapsto & S3    \\
-%    FS3 & \mapsto & S1     \\
-%   FS4 & \mapsto & S2     \\
-%   FS5 & \mapsto & S2     \\
-%   FS6 & \mapsto & S3    
-% \end{eqnarray*}
-% 
-% Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$.
-% 
-% 
-% For Functional Group 2 (FG2), let us map:
-% \begin{eqnarray*}
-%   FS1 & \mapsto & S4   \\
-%   FS2 & \mapsto & S5    \\
-%    FS3 & \mapsto & S5     \\
-%   FS4 & \mapsto & S4     \\
-%   FS5 & \mapsto & S6     \\
-%   FS6 & \mapsto & S5    
-% \end{eqnarray*}
-% 
-% Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4, S5, S6 \}$
-% 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}.
-% 
-% A software tool tracking the analysis process
-% could check that all possible single and double 
-% failure modes combinations have been analysed as failure scenarios.
-% 
-% %single 
-% %XXXXXXXXXXXXXXXXXXXXXXXXXX
-% %This AUTOMATIC check can reveal WHEN double checking no longer necessary 
-% %in the hierarchy to cover dub sum !!!!! YESSSS
-% 
-% 
-% \section{Conclusion}
-% %\subsection{Evaluation of FMMD}
-% 
-% %By applying the methodology in section \ref{fmmdproc}, the wishlist can
-% %now be evaluated for the proposed FMMD methodology.
-% 
-% We evaluate the FMMD method using the criteria in section \ref{fmmdreq}.
-% Table \ref{tbl:comparison} compares the current methodologies and FMMD using these criteria.
-% { %\small
-% \begin{itemize}
-% \item{State explosion is reduced,}
-% %State Explosion is reduced,
-% because small collections of components are dealt within functional groups
-% which are used to create derived components which are then used in an hierarchical manner.
-% 
-% \item{All component failure modes must be considered in the model.}
-% %All component failure modes must be considered in the model.
-% Since the proposed methodology is bottom-up,
-% this means that we can ensure/check that all component failure modes are handled.
-% 
-% 
-% \item{ It should be straightforward to integrate mechanical, electronic and software models,}
-% %It should be straight forward to integrate mechanical, electronic and software models,
-% because FMMD models in terms of  failure modes only. % we have a generic failure mode entities to model.
-% %We can describe a mechanical, electrical or software component in terms of its failure modes. 
-% %
-% Because of this 
-% we can model and analyse integrated electromechanical systems, controlled by computers,
-% using a common notation. An electronic/software FMMD example is given in~\ref{sec:elecsw}.
-% 
-% \item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
-% %It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
-% The hierarchical nature, taking {\fg}s and deriving components from them, means that 
-% commonly used {\dcs} can be re-used in a design % (for instance self checking digital inputs)
-% or even in other projects where the same {\dc} is used. Several examples of re-used {\dcs}
-% may be found in chapter~\ref{sec:chap5}.
-% 
-% 
-% \item{ Formal basis: data should be available to produce mathematical proofs and traceability.}
-% %It should have a formal basis, data should be available to produce mathematical proofs
-% %for its results
-% Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs},
-% system level failure modes are traceable back down the fault tree to
-% 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.
-% %
-% An added advantage of FMMD, is that there are typically several stages of reasoning
-% to go from a base component failure mode to a system/top level event.
-% %
-% Each of these reasoning stages are represented by {\fg} to {\dc} analysis processes, traversing up the FMMD hierarchy.
-% %
-% Compare this to traditional FMEA where
-% we only have one reasoning stage, that of 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
-% % and danger evaluation statistics sourced from the component failure mode statistics~\cite{fmd91,mil1991}.
-% 
-% % \item{ It should be easy to use, ideally 
-% % using a graphical syntax (as opposed to a formal mathematical one).}
-% % A modified form of constraint diagram (an extension of Euler diagrams) has
-% % been developed to support the FMMD methodology.
-% % This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
-% % advance a {\fg} to a {\dc}.
-% 
-% 
-% % \item{ From the top down the failure mode model should follow a logical de-composition of the functionality
-% % to smaller and smaller functional modules \cite{maikowski}.}
-% % The bottom-up approach fulfils the  logical de-composition requirement, because the {\fg}s
-% % are built from components performing a given task. 
-% % 
-% 
-% \item{ Multiple failure modes (conjunction - where more that one failure mode is active) 
-% may be modelled from the base component level up.}
-% %Multiple failure modes (conjunction) may be modelled from the base component level up.
-% By breaking the problem of failure mode analysis into small stages
-% and building a hierarchy, the problems associated with needing to 
-% analyse all possible combinations of base level components
-% within a system are reduced.
-% 
-% % by an exponential order.
-% This is because the multiple failure modes considered
-% within {\fgs} have fewer failure modes to consider 
-% at each FMMD stage.
-% Where appropriate, multiple simultaneous failures can be modelled by
-% introducing {\fcs} %test~cases 
-% where the conjunction of failure modes is considered.
-% An example demonstrating multiple failure mode analysis may be found in section~\ref{sec:Pt100}.
-% \end{itemize}
-% }
-% 
-% { %\tiny
-% \begin{table}[ht]
-% \caption{Features of static Failure Mode analysis methodologies} % title of Table
-% \centering % used for centering table
-% \begin{tabular}{||l|c|c|c|c|c||}
-% \hline \hline
-% % \textbf{Des.} & \textbf{FTA}  & \textbf{FMEA} &   \textbf{FMECA} & \textbf{FDEMA} &   \textbf{FMMD}   \\
-% \textbf{\tiny Des.} & \textbf{\tiny FTA}  & \textbf{\tiny FMEA} &   \textbf{\tiny FMECA} & \textbf{\tiny FDEMA} &   \textbf{\tiny FMMD}   \\
-%  \textbf{\tiny Crit.}  &   \textbf{}   & \textbf{}     &   \textbf{}      & \textbf{}      &   \textbf{}   \\
-% %   R         &    wire        & res +         & res -    & description
-% \hline
-% \hline
-%  C1: % state exp    
-%                 &  partial      &               &                 &               &   $\tickYES$  \\ \hline
-%  C2: % $\forall$ failures 
-%                 &               &$\tickYES$  &    $\tickYES$   &    $\tickYES$ &  $\tickYES$  \\  \hline
-%  C3: %mech,elec,s/w & $\tickYES$    
-%                 &               &                 &               &             & $\tickYES$ \\  \hline
-%  C4: %modular        
-%                 &               &               &                 &  partial      &  $\tickYES$   \\ \hline
-%  C5: %formal         
-%                 &  partial     &  partial       &  partial       &  partial    &  $\tickYES$   \\ \hline
-%  C6: %multiple fm    
-%                 &   $\tickYES$  &               &                 &  partial    &  $\tickYES$    \\ \hline
-% \hline
-% \hline
-% \end{tabular} 
-% \label{tbl:comparison}
-% \end{table}
-% }
-% %\clearpage
-% 
-% 
-% %\subsection{}
-% 
-% 
-% %This new approach is called 
-% Failure Mode Modular De-Composition (FMMD) is designed 
-% to be a more rigorous  and `data~complete' model than
-% the current four approaches.
-% %
-% That is, 
-% from an FMMD model, we should be able to 
-% derive outline models that the other four methodologies would have been 
-% able to create. As this approach is modular, many of the results of 
-% analysed components may be re-used in other projects, so 
-% test efficiency is improved.
-% %Clearly the more complex the original system is the more benefit,
-% %i.e. less components and derived components, will be produced from decomposing the 
-% %system into functional groups.
-% 
-% FMMD is based on generic failure modes, so it is not constrained to a 
-% particular field. It can be applied to mechanical, electrical or software domains. 
-% It can therefore be used to analyse systems comprised of electrical,
-% mechanical and software elements in one integrated model.
-% Furthermore the reasoning path is traceable. By being able to trace a 
-% top level event down through derived components, to base component
-% failure modes, with each step annotated as {\fcs}, the model is easier to maintain.
-% 
-% The example used here is deliberately small for the purpose
-% of being presenting the methodology showing  more than only one stage of hierarchy,
-% worked examples for common electronic circuits, digital analogue hybrids and software electronic
-% hybrid systems are given in chapter~\ref{sec:chap5}.
-% %FMMD has been applied
-% %to larger systems encompassing mechanical, electrical and software
-% %elements. 
-% FMMD represents a new technique in that it
-% can address all the criteria in table 3, whereas the other methodologies
-% can only cover some.
-% 
-% 
-% FMMD not only has advantages of efficiency (reduction of state explosion), it also
-% provides the capability to model entire electro-mechanical-software systems using a common notation
-% and processes.
-% %\ifthenelse {\boolean{paper}}
-% %{
-% %\input{abstract}
-% %%%- \input{fmmd}
-% %%%- %\input{introduction}
-% %%%- \input{topbot}
-% %%%- %\input{sys_abs}
-% %%%- \input{process}
-% %%%- \input{algorithm}
-% %
-% %}
-% %{
-% %\label{symptomex}
-% %%%- \input{./introduction}
-% %%%- \input{./topbot}
-% %%%- %\input{./sys_abs}
-% %%%- \input{./process}
-% %%%- \input{./algorithm}
-% %}
-% %
-% %
-% %{
-% %\section{Introduction}
-% %\label{chap:sympex}
-% %This chapter describes the process for taking a {\fg},
-% %analysing its failure mode behaviour from the failure modes
-% %and interactions of its components,
-% %and creating a {\dc} that represent the failure mode behaviour of that {\fg}.
-% %
-%