Edit for CH4 and CH5 mainly

papers/fmea_software_hardware/software_fmea.tex

@@ -514,7 +514,7 @@ We now apply FMMD starting with the hardware.
 \section{Failure Mode effects Analysis}
 
 Four emerging and current techniques are now used to 
-alpply FMEA to the hardware, the software, the software medium and the software hardware insterface.
+apply FMEA to the hardware, the software, the software medium and the software hardware insterface.
 
 \subsection{Hardware FMEA}
 

submission_thesis/CH4_FMMD/copy.tex

@@ -550,6 +550,9 @@ This would mean the symptom of the failed potential divider would be voltage hig
 \vbox{
 From table  \ref{tbl:pdfmea} we can see that the resistor 
 failures modes lead to some common symptoms.
+These common symptoms are an important concept for FMMD.
+It means that we can take multiple failure modes from a {\fg} and resolve them 
+to a a common symptom. This means that we simplify the FMEA analysis task for further stages.
 By drawing directed edges from the failure modes to the symptoms,
 we can show the relationships between the component failure modes and resultant symptoms.
 %The {\fg} can now be considered a derived component.
@@ -605,7 +608,7 @@ This {\dc} will have two failure modes.
 We 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}.
-We then represent the {\dc} as a DAG in figure  \ref{fig:dc1dag}.
+We represent the {\dc} \textbf{PD}, as a DAG in figure  \ref{fig:dc1dag}.
 
 
 %We could represent it algebraically thus: $ \derivec(PotDiv) = 
@@ -853,7 +856,7 @@ and this is represented in table \ref{tbl:ampfmea1}.
 %      %\path (s2) edge (DC);
 %      
 %  
-%  
+%  	`
 %      % Connect every node in the hidden layer with the output layer
 %      %\foreach \source in {1,...,5}
 %      %    \path (H-\source) edge (O);
@@ -1001,11 +1004,12 @@ Failure Scenario & A single failure mode (or a combination), used to
 \subsection{Parts, Components and Base Components.}
 A component is anything we use to build a %a product or 
 system. 
-It could be something %quite complicated 
+It could be something quite complicated 
 like an %integrated 
-micro-controller, or quite simple like the resistor.
+micro-controller/servo motor, or quite simple like the resistor.
 %
-We can identify a 
+We %can 
+identify a 
 component by its name, a manufacturer's part number and perhaps
 a vendor's reference number.
 
@@ -1023,7 +1027,7 @@ 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.
-We define {\bc} to be the lowest level---or entities we begin with in our analysis---of component that we use as a building block.
+We define {\bc} to be the lowest level---an entity with which we begin our analysis---of component that we use as a building block.
 This is a choice made by the analyst, often guided by the standards to which the analysis is being performed. % to. 
 %
 Both op-amps and transistors have published statistical failure rates and yet an op-amp is constructed from transistors.
@@ -1181,7 +1185,7 @@ structure with its associated failure modes.
 %
 From this diagram we see that each component must have at least one failure mode.
 To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
-each failure mode is referenced back to only one component. This constraint is discussed in section~\ref{sec:unitarystate}.
+each failure mode is referenced back to only one component. This constraint is discussed in detail in section~\ref{sec:unitarystate}.
 
 %%-%% MTTF STATS CHAPTER MAYBE ??
 %%-%%
@@ -1313,13 +1317,15 @@ Initial {\fgs} will consist of {\bcs}.
 %
 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.
+As each component %mode holds 
+has a set of failure modes associated with it, 
+the {\fg} represents a set of sets of failure modes.
 %
 We convert this 
 into a flat set 
 of failure modes for use in analysis.
 %
-A flat set is a set containing just failure modes and not sets of failure modes~\cite{joyofsets}[p.8].
+A flat set is a set containing just the failure modes and not sets of failure modes~\cite{joyofsets}[p.8].
 %
 %In practical term each component failure mode is considered as a `failure~scenario' or 'test~case'
 %for the {\fg}.
@@ -1414,7 +1420,8 @@ with the op-amp.
 This {\fg} is now analysed and a {\dc} created to 
 represent the failure mode behaviour of the {\em INVAMP}.
 An analysis report is generated for each {\fg} to {\dc}
-process.
+process\footnote{By having an analysis report report for each analysis stage, i.e. {fg} to {\dc},
+we increase the tracability in the reasoning applied to to the FMEA process.}.
 %
 We may now use the  {\em INVAMP} {\dc} in even higher level {\fgs}.
 
@@ -1454,7 +1461,7 @@ Because {\fgs} may include components at varying levels
 of $\abslev$, having it quickly available as an attribute
 will be required in practical implementations
 to order the tree, and prevent recursion in the hierarchy.
-
+The abstraction level concept is formally defined in section~\ref{sec:abstractionlevel}.
 
 % \section{Set Theory Description}
 % 
@@ -1522,7 +1529,7 @@ make up and thus define the {\fg}) associated with the {\dc}.
 
 \begin{figure}[h]
  \centering
- \includegraphics[width=400pt,keepaspectratio=true]{./CH4_FMMD/master_uml.png}
+ \includegraphics[width=300pt,keepaspectratio=true]{./CH4_FMMD/master_uml.png}
  % cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
  \caption{Complete UML diagram}
  \label{fig:cfg2}

submission_thesis/CH5_Examples/copy.tex

@@ -42,9 +42,11 @@ four op-amp stages with supporting components.
 Section~\ref{sec:sigmadelta} shows FMMD analysing the sigma delta analogue to digital converter---which operates on both 
 analogue and digital signals.
 %
-Finally section~\ref{sec:Pt100} demonstrates both statistical 
+Sections~\ref{sec:Pt100}~and~\ref{sec:Pt100d} demonstrate both statistical 
 failure mode classification %  analysis for top level events traced back to {\bc} failure modes
 and the analysis of double simultaneous failure modes.
+%
+Finally section~\ref{sec:elecsw} demonstrates FMMD analysis of a combined electronic and software system.
 
 % \section{Basic Concepts Of FMMD}
 % 
@@ -3014,7 +3016,7 @@ conditions.
 
 %\clearpage
 \section{ Pt100 Double Simultaneous  Fault Analysis}
-
+\label{sec:Pt100d}
 In this section we examine the failure mode behaviour for all single 
 faults and double simultaneous faults.
 This corresponds to the cardinality constrained powerset of one (see section~\ref{ccp}), of
@@ -3375,7 +3377,7 @@ from the top down and eventually call the lowest level library or IO
 functions that interact with hardware/electronics.
 
 What is potentially difficult with a software function, is deciding  what
-are failure modes, and later what a failure symptoms.
+its failure modes and symptoms are.
 With electronic components, we can use literature to point us to suitable sets of
 {\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}.%~\cite{en61508}~\cite{en298}.
 With software, only some library functions are well known and rigorously documented
@@ -3396,7 +3398,7 @@ post-conditions (constraints on its outputs) and function wide invariants (rules
 A precondition, or requirement for a contract software function
 defines the correct ranges of input conditions for the function
 to operate successfully.
-
+%
 For a software function, a violation of a pre-condition is 
 in effect a failure mode of `one of its components'.
 
@@ -3409,8 +3411,8 @@ Post conditions could  be either  actions performed (i.e. the state of hardware
 
 \paragraph{Mapping contract `invariant' violations to symptoms and failure modes.}
 
-Invariants in contract programming may apply to inputs to the function (where they can be considered {\fms} in FMMD terminology),
-and to outputs (where they can be considered {failure symptoms} in FMMD terminology).
+Invariants in contract programming may apply to inputs to the function (where violations can be considered {\fms} in FMMD terminology),
+and to outputs (where violations can be considered {failure symptoms} in FMMD terminology).
 
 
 \subsection{Combined Hardware/Software FMMD}
@@ -3422,11 +3424,14 @@ to supply a current signal to represent the value to be sent~\cite{aoe}[p.934].
 Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale,
 and this is referred to as {\ft} signalling.
 %
-{\ft} has a an electrical advantage as well, because the current in a loop is constant~\cite{aoe}[p.20]
+{\ft} signalling has  intrinsic electrical  safety advantages.
+%
+Because the current in a loop is constant~\cite{aoe}[p.20]
 resistance in the wires between the source and receiving end is not an issue
 that can alter the accuracy of the signal.
 %
-This circuit has many advantages for safety. If the signal becomes disconnected
+%This circuit has many advantages for safety. 
+If the signal becomes disconnected
 it reads $0mA$ at the receiving end: as this is outside the {\ft} range
 it is easy to detect as an error condition rather than an incorrect value.
 %
@@ -3906,15 +3911,16 @@ With this analysis
 we have a complete `reasoning~path' linking the failures modes from the 
 electronics to those in the software.
 Each functional group to {\dc} transition represents a 
-reasoning stage.
+reasoning stage. AEach reasoning stage will have an associated analysis report.
 %
 
 
 With traditional FMEA methods the reasoning~distance is large, because
 it stretches from the component failure mode to the top---or---system level failure.
 For this reason applying traditional FMEA to software stretches
-the reasoning distance even further.
-
+the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is 
+performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware 
+interfacing is treated as a seperate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea}
 
 
 We now have a {\dc} for a {\ft} input in software.
@@ -3929,7 +3935,7 @@ detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
 
 A software specification for a hardware interface will concentrate on
 how to interpret raw readings, or what signals to apply for actuators.
-Using FMMD we can determine an accurate failure model for the interface as well.
+Using FMMD we can determine an accurate failure model for the interface as well~\cite{sfmeainterface}.
 %
 %Detailing this however,  is beyond the scope %and page-count 
 %of this paper. 

submission_thesis/CH7_Conclusion/copy.tex

@@ -58,7 +58,7 @@ Functional groupings by definition implement functionality, or purpose, and ther
 operational states.% with.
 
 \paragraph{Inhibit Conditions.}
-A third data class may be required if modelling of inhibit conditions~\cite{nasatfa}[p.40] is desired.
+A third data class may be required if modelling of inhibit conditions~\cite{nasafta}[p.40] is desired.
 Some failure modes may only be active given specific environmental conditions
 or when other failures are already active.
 To model this, an `inhibit' class has been added.

submission_thesis/appendixes/algorithmic.tex

@@ -645,6 +645,7 @@ as a component with a known set of failure modes.
 
 
 \paragraph{Enumerating abstraction levels}
+\ref{sec:abstractionlevel}
 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.