diff --git a/sw_model/Makefile b/sw_model/Makefile
new file mode 100644
index 0000000..81bf418
--- /dev/null
+++ b/sw_model/Makefile
@@ -0,0 +1,21 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex sw_model_p.tex
+	pdflatex paper.tex
+	#dvipdf paper
+	mv paper.pdf sw_model_paper.pdf
+	okular sw_model_paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+sw_model_p.tex: sw_model.tex
+	cat sw_model.tex | sed 's/sw_model\///' > sw_model_p.tex
+
+
+bib:
+	bibtex paper
diff --git a/sw_model/paper.tex b/sw_model/paper.tex
new file mode 100644
index 0000000..57c9947
--- /dev/null
+++ b/sw_model/paper.tex
@@ -0,0 +1,35 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath}
+
+\usepackage{ifthen}
+\newboolean{paper}
+\setboolean{paper}{true} % boolvar=true or false
+
+\input{../style}
+
+\begin{document}
+\pagestyle{fancy}
+
+%\outerhead{{\small\bf Propositional Logic Diagram}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{Failure Mode Modular de-Composition of Software}
+\maketitle 
+%
+% to make the stand alone paper the processed version is required.
+\input{sw_model_p}
+
+\bibliographystyle{plain}
+\bibliography{../vmgbibliography,../mybib}
+
+%\begin{verbatim}
+%$Id: paper.tex,v 1.1 2009/06/05 18:35:31 robin Exp $
+%\end{verbatim}
+
+\end{document}
diff --git a/sw_model/sw_model.tex b/sw_model/sw_model.tex
new file mode 100644
index 0000000..4248dff
--- /dev/null
+++ b/sw_model/sw_model.tex
@@ -0,0 +1,214 @@
+% $Id: ons calling functionsin Exp $
+
+% 
+
+\ifthenelse {\boolean{paper}}
+{
+\begin{abstract} 
+This paper
+%
+describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
+models failure mode behaviour in software, electronic and mechanical
+domains. The methodology therefore can model integrated
+software/electrical/mechanical systems. This paper concentrates
+on the software modelling, begining with
+a discussion on general software stucture, afferent. transform and effenet 
+data flow, and then the hierarchical call tree nature of software.
+Software functions are then described from a failure mode perspective
+integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
+The paper then shows how FMMD models from electrical and mechanical
+domains can be seamlessly integrated with the software failure mode models.
+
+With a methodology that provides a common notation for these three domians
+complete and connected failure mode modelling can be applied to 
+real time systems, such as safety critical smart devices and 
+embedded industrial control machinery.
+
+\end{abstract}
+}
+{
+\section{Introduction}
+This chapter
+%
+
+describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
+models failure mode behaviour in software, electronic and mechanical
+domains. The methodology therefore can model integrated
+software/electrical/mechanical systems. This paper concentrates
+on the software modelling, begining with
+a discussion on general software stucture, afferent. transform and effenet 
+data flow, and then the hierarchical call tree nature of software.
+Software functions are then described from a failure mode perspective
+integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
+The paper then shows how FMMD models from electrical and mechanical
+domains can be seamlessly integrated with the software failure mode models.
+
+With a methodology that provides a common notation for these three domians
+complete and connected failure mode modelling can be applied to 
+real time systems, such as safety critical smart devices and 
+embedded industrial control machinery.
+
+}
+ 
+\section{ Modern Devices }
+
+From the automobile to the microwave oven, we increasingly rely on
+embedded computing, controlling electro mechanical
+devices etc etc etc
+
+\section{ Data Flow Modelling }
+
+A computer system can be considered to simply process data, and data flow modelling
+exists in various forms. \cite{yourdon} \cite{sommerville}
+
+Essentially data flow modelling starts with a context diagram, where
+the inputs and outputs to a process are identified.
+These inputs and outputs connect to a process `bubble'
+representing the computing, or data transformation.
+
+
+
+EXAMPLE CONTEXT DIAGRAM
+
+
+The data input to the system is afferent data flow, the data actually processed is
+known as transform data and the data output is termed `efferent' flow.
+
+The next stage in the process is to consider the transform, or computing bubble.
+Each stream of input data is taken to transform `bubbles' that 
+process the data and pass it on to other bubles which process the data to be sent out.
+
+
+This process can continue zooming into each `bubble' until the transformation processes they
+represent are simple enough to implement  as functions in a programming language.
+
+The next stage, is to pick a transform bubble somewhere in the middle 
+of these diagrams and assign it as the `main' \\ref{kandr} or start
+funtion.
+
+As a design methodology, ignoring real time constraints, this is a very good way
+of analysiing a problem and getting a good software structure.
+
+What is interesting though is that this naturally determines a hierarchy
+where the hardware, the sensors and actuators in an embedded system,
+naturally fall to the lowest point in the software hierarchy.
+
+n fact because we use electronics to measure mechanical devices,
+we can establish a hierarchy of the three domians 
+in terms of software.
+That is to say Software at the top of the hierarchy, Electronics below it, and mechanical
+systems below electronics.
+
+%%-s is the process of identifying, modeling and documenting how data moves around an information system.
+%%- Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the
+%%- holding areas for data), external entities (what sends data into a system or receives data from a system),
+%%- and data flows (routes by which data can flow).
+%%-Discuss afferent efferent flow, how h/w naturally goes at the bottem end 
+%%-of the software structure.
+
+Establish this general structure
+
+
+SW
+
+ELEC
+
+MECH
+
+:'e,'f move .
+
+
+\section{ Software structure}
+All software has a natural hierarchy or call tree structure.
+The first called function will call others and the hierarchy
+will be controlled by a call stack.
+
+
+\section{FMEA applied to s/w}
+
+%tref navy Msc
+Failure MOde Effects analysis can be applied to software.
+We can treat a software function as a funtional group.
+All the functions it calls are components 
+that are used to build it.
+
+\section{Failure Modes and functions}
+
+Describe functions, how pre conditions map to
+input failure modes and post conditions to 
+failure mode symptoms.
+
+Traditionally written as a form of guard.
+
+Here we are interested in the ways the functions can fail.
+
+
+\section{Basic Concepts Of FMMD}
+
+
+\paragraph{Creating an fault hierarchy}
+
+%%- bias this to software...
+
+The main idea of the methodology is to build a hierarchy of fault modes from the part
+level up to highest system levels. 
+
+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.
+In terms of software, we can considered the functions called by a function to be the components.
+The functions called will have known failure modes (i.e. they can fail their post conditions).
+
+
+For this study a {\fg} will mean a collection of components.
+In order to determine the symptoms or failure modes of a {\fg},
+we need to consider all failure modes of its components.
+By analysing the fault behaviour of a `{\fg}' with respect these failure modes
+we can derive a new set of possible failure modes.
+Thus we can consider how a software function will react to the failure modes of the functions it calls.
+%
+This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of 
+fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways.
+
+In other words we have taken a {\fg}, and analysed how it can fail according to the failure modes of its parts.
+These new failure~modes are derived failure modes.
+%The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
+%being derived from the {\fg}. 
+We can now create a new `{\dc}' which has
+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}.
+%What this means is the `fault~symptoms' of the module have been derived.
+%
+%When we have determined the fault~modes at the module level these can become a set of derived faults.
+%By taking sets of derived faults (module level faults) we can combine these to form modules
+%at a higher level of fault abstraction. An entire hierarchy of fault modes can now be built in this way,
+%to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
+%as parts, parts which may now be combined to create new functional groups, 
+%but as parts at a higher level of fault abstraction. 
+\ifthenelse {\boolean{paper}}
+{
+Reference the symptom abstraction paper here
+}
+{
+This analysis and symptom collection process is described in detail in the Symptom extraction (see chapter \ref{symptomex}).
+}
+
+
+\section{ Applying Software to the FMMD Hierarchy}
+
+Follow the natural call function hierarchy, model the 
+flow of failure modes and symptom collection as before.
+
+
+
+\section{interfacing Software to Hardware}
+
+Nature of this is sensors and actuators.
+Describe.
+Example of failure modes of a hardware element being
+integrated into s/w
+
+Use prev example of milli-volt amp with check resistor.
diff --git a/thesis.tex b/thesis.tex
index 8772a03..18215cb 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -105,6 +105,9 @@
 \chapter{A Formal Description of FMMD}
 \input{fmmdset/fmmdset}
 
+\chapter{Modelling Software With FMMD}
+\input{sw_model/sw_model}
+
 
 \chapter{FMMD functional~group to \\derived component example : PT100 4 wire Temperature Sensor}
 \typeout{ ---------------- pt100}