...

papers/software_fmea/software_fmea.tex

@@ -173,7 +173,72 @@ What FMEA is, briefly variants...
 
 \section{Modularising FMEA}
 
-Advantages to modularisation, ref SYS SAFETY 2011 paper,
+In outline, in order to modularise FMEA, we must create small modules form the bottom-up.
+We can do this by taking collections of base~components that 
+perform (ideally) a simple and well defined task.
+We can call these {\fgs}.
+We can then analyse the failure mode behaviour of a {\fg}
+using all the failure modes of all its components.
+When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg}
+we can treat it as a {\dc}.
+We can now use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model
+of the failure mode behaviour of a system. An example of this process, applied to an inverting op-amp configuration
+is given in~\cite{syssafe2011}.
+
+\paragraph{Modulaeising FMEA: Creating a fault hierarchy.}
+
+The main concept of Failure Mode Modular Discrimination (FMMD) is to build a hierarchy of failure behaviour from the {\bc}
+level up to the top, or system level, with analysis stages between each 
+transition to a higher level in the hierarchy. 
+
+
+The first stage is to choose
+{\bcs} that interact and naturally form {\fgs}. The initial {\fgs} are   collections of base components.
+%These parts all have associated fault modes. A module is a set fault~modes. 
+From the point of view of fault analysis, we are not interested in the components themselves, but in the ways in which they can fail.
+
+A {\fg} is a collection of components that perform some simple task or function.
+%
+In order to determine how a  {\fg} can fail,
+we need to consider all failure modes of its components.
+%
+By analysing the fault behavior of a `{\fg}' with respect to all its components failure modes,
+we can determine its symptoms of failure.
+%In fact we can call these
+%the symptoms of failure for the {\fg}.
+
+With these symptoms (a set of derived faults from the perspective of the {\fg}) 
+we can now state that the {\fg} (as an entity in its own right) can fail in a number of well defined ways.
+%
+In other words we have taken a {\fg}, and analysed how 
+\textbf{it} can fail according to the failure modes of its components, and then
+determined the {\fg} failure modes.
+
+\paragraph{Creating a derived component.} 
+We create a new `{\dc}' which has
+the failure symptoms of the {\fg} from which it was derived, as its set of failure modes.
+This new {\dc} is at a higher `failure~mode~abstraction~level' than {\bcs}.
+%
+\paragraph{An example of a {\dc}.}
+To give an example of this, we could look at the components that
+form, say an amplifier. We look at how all the components within it
+could fail and how that would affect the amplifier.
+%
+The ways in which the amplifier can be affected are its symptoms.
+%
+When we have determined the symptoms, we can
+create a {\dc} (called say AMP1) which has a {\em known set of failure modes} (i.e. its symptoms).
+We can now treat $AMP1$ as a pre-analysed, higher level component.
+The amplifier is an abstract concept, in terms of the components.
+To a make an `amplifier' we have to connect a a group of components
+in a specific configuration. This specific configuration corresponds to 
+a {\fg}. Our use of it as a building block corresponds to a {\dc}.
+
+
+DIAGRAM of FMMD Hierarchy.
+
+Note the diagram of the FMMD hierarchy is very similar to a simple non-recursive 
+programmatic function call tree.
 
 \section{Software: How can we apply FMEA}
 
@@ -184,7 +249,7 @@ of components, {\fgs} and symptoms of failure for a functional group.
 
 A  programatic function is very similar to a functional group.
 It calls other functions, which could be viewed as its `components'.
-It has outputs which will be used by functiona that may call it.
+It has outputs which will be used by functions that may call it.
 
 However, we need to define a clear concept of failure modes of a function in order to
 map FMMD to software.
@@ -202,6 +267,11 @@ functions that interact with hardware/electronics.
 
 \subsection{Contract programming description}
 
+Contract programming is a discipline for building software functions in a controlled
+and traceable way. Each function is subject to pre-conditions (constraints on its inputs),
+post-conditions (constraints on its outputs) and function wide invariants (rules).
+
+
 \subsubsection{Mapping contract pre-condition violations to failure modes}
 \subsubsection{Mapping contract post-condition violations to symptoms}
 
@@ -210,6 +280,8 @@ functions that interact with hardware/electronics.
 \subsection{Simple Software Example}
 
 Make up a sensor that can read a value but can fail by being out of range 4-20mA ???
+Thus our sensor can be seen as working corectly if its voltage is between
+0.9 and 4.4, but outside that range it is considered to have failed.
 
 %\clearpage
 \section{Conclusion}