started work on sw model

Makefile

@@ -4,7 +4,7 @@
 
 pdf:
 	pdflatex thesis
-	okular thesis.pdf
+	acroread thesis.pdf &
 
 
 bib:
@@ -15,4 +15,4 @@ bib:
 puzzle:
 	pdflatex puzzle.tex
 	pdflatex puzzle.tex
-	okular puzzle.pdf
+	acroread puzzle.pdf

sw_model/sw_model.tex

@@ -68,17 +68,18 @@ This chapter
 
 }
  
-\ifthenelse {\boolean{paper}}
+
-{
 \section{Basic Concepts Of FMMD}
 
 \paragraph{Creating an fault hierarchy}
 
 %%- bias this to software...
 
-The main idea of the FMMD methodology is to build a hierarchy of fault behaviour
+The main core concept of the FMMD methodology is to build a hierarchy of fault behaviour
-component models from the part
+from the part
-level up to highest system levels. This means that we model 
+level up to highest system levels. 
+
+This means that we model 
 components of a system with respect to their failure modes.
 Electrical and mechanical components have known and 
 well understood failure modes~\cite{mill1991}~\cite{fmd91}.
@@ -86,26 +87,113 @@ Software functions (apart from some standard library procedures) generally are c
 for a given application.
 In order to model system which include mechanical and electronic
 parts with software, we need some way of represent software functions
-in terms of their failure mode behaviour. More than this
+in terms of their failure mode behaviour. Also
 we need to integrate them into a hierarchical failure mode model.
 
 In order to perform FMMD analysis, which is a bottom up methodology, the first stage is to choose
 components that interact and naturally form {\fgs}. The initial {\fgs} are thus collections of base parts.
 %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.
+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.
 Contract programming defines software functions in terms of
 pre-conditions, post conditions and invariants.
-Breaking any of these is a failure mode, but our gaol is fitting these into the FMMD 
+Breaking any of these is a failure mode, and contract
-failure mode model.
+programming defines software failure modes useful for FMMD modelling.
 
-For software we already have the hierarchy, thanks to the nature of the `call tree'
+
+\subsection{Software in terms of failure modes}
+ 
+
+For software we already have the hierarchy, thanks to the nature of the `call~tree'
 in procedural languages.
-This we cannot change. Software functions, call other `lower level' functions.
+A function can fail when its post-conditions are not obeyed/completed/kept.
+In terms of a treating a function as a component, post condition
+violations are its failure modes.
+Let us consider two functions $f1()$ and $f(2)$ which have 
+post condition violation conditions. 
+
+$$  PostCondVoliations(f1) = \{ {pcf1}_1, {pcf1}_2 \} $$
+$$  PostCondVoliations(f2) = \{ {pcf2}_1, {pcf2}_2 \} $$
+
+A function which calls other functions can thus be treated as a functional group. 
+Let us consider a function $f()$ which calls $f1(),f2()$.
+
+
+\vbox{
+\begin{verbatim}
+ function f() {
+  f1();
+  f2();
+}
+\end{verbatim}
+} % vbox
+
+Its input failure modes
+are its pre-condition violations, let us define these as
+$$  PreCondVoliations f() = \{ {prf}_1, {prf}_2 \} $$
+
+For an FMMD model we need to extend the concepts of contract programming slightly.
+Contract programming deals with functions in isolation.
+We need the failure modes to propagate up a hierarchy
+(as they do in real software systems).
+We need to consider the failure effects of the called functions
+failing their post-conditions as well as the pre-condition failures
+defined for $f()$.
+
+Considering the function $f()$ as an FMMD {\fg}, the failure modes
+we must consider to analyse its failure mode behaviour are
+its pre-condition violations and the failed post conditions of
+the functions its calls.
+
+$$ fm(f()) = \{ {prf}_1, {prf}_2, {pcf1}_1, {pcf1}_2, {pcf2}_1, {pcf2}_2 \} $$
+
+We can now use these failure modes to help analyse how the 
+function $f()$ can fail. We can analyse how these
+pre-condition violations will affect the $f()$
+and  treat these as failure symptoms of the function $f()$.
+
+We can also add new post conditions to $f()$ 
+(as in contract programming) to define the correct behaviour
+of $f()$.
+
+Together these become the symptoms of failure of function $f()$.
+
+We can now treat $f()$ as a component and use its
+symptoms as failure modes.
+A function calling $f()$, using FMMD would have to
+consider these failure modes, when calling $f()$.
+
+
+In this way a software hierarchy, in terms of failure
+modes can be built up.
+This is an extension of contract programming in that it
+provides a formal basis for linking functions together
+into a software hierarchy.
+It also means that any failed post conditions
+of a function called, must be considered in the failure model,
+something that can be checked and controlled by a software tool.
+
+ 
+
+
+%This we cannot change. 
+
+
+\subsection{Interfacing Software to Electronic {\wrt} failure modes}
+
+Software functions, call other `lower level' functions.
 The lowest level functions generally either provide some 
 for of data transformation (i.e. a mathematical function such as {\em sin(x)})
-or interact with I/O. I/O is generally an interface to
+or interact with inputs and outputs (I/O). 
+
+Software interaction with I/O is generally via to
 electronics. Where mechanical components are present, they are generally
-controlled by electronic actuators, and measured via electronic transducers~\cite{elecsys}[pp194-273]
+controlled by electronic actuators, and measured via electronic transducers~\cite{elecsys}[pp194-273].
+Obviously in order to integrate software with electronic components we need
+to define this interface.
+
+A typical and common function is being able to read a voltage into
+a computer program. This example is discussed in section \ref{sec:adc}.
 
 In terms of software, we can consider the data transformations and functions used/called by a function to be the components.
 The functions called will have known failure modes (i.e. they could fail their post conditions).
@@ -117,8 +205,20 @@ In the case of I/O modules, these will be derived components with their own sets
 If a function calls a function,  the failure modes would be failed post-conditions of the called function.
 
 
+\subsection{FMMD Process}
+
+Diagram showing components with failure modes,
+the functional group; the collection of failure modes;
+the analysis stage; the symptoms, and finally the derived component.
+
+
+Now diagram showing software function,
+with pre-conditions, invariants and post conditions.
+
+
+Now an integrated diagram, showing the 
+pre-condition violations as failure modes 
 
-The failure modes of a functions components
 
 
 
@@ -142,9 +242,7 @@ the failure symptoms of the {\fg} as its set of failure modes.
 We thus consider that our software function can fail in a number of given ways.
 This new {\dc} is at a higher failure mode abstraction
 level than the {\bcs}.
-} % ifdef papaer
+
-{
-}
 
 \subsection{ An example function analysed in terms of failure modes }
 
@@ -152,8 +250,23 @@ OK here an example reading an ADC
 The values could be out of range (a pre-condition)
 The post condition is sending back a voltage, with an error condition
 
+
+This simple ADC read function contains no self checking
+we cannot be sure the multiplexer switching a selection
+of inputs to it is functioning, and we do not know
+the ADC reference voltage is accurate.
+
+What this means is the fundamental aspects of safely reading a voltage, i.e.
+we are reading the right input, and the accuracy or the reading cannot be detected.
+What we have here are effectively undetectable failure modes.
+
+
+\section{example of Software to Electronics Interfacing}
+\label{sec:adc}
+
 \subsection{ A more detailed function with ADC checking features }
 
+For safety critical product
 OK here an example reading an ADC, but testing the MUX
 and a mid range voltage ref + span and zero.