Merge branch 'master' of dev:/home/robin/git/thesis

burner/Makefile

@@ -0,0 +1,17 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex burner_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	okular paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+burner_paper.tex: burner.tex
+	cat burner.tex | sed 's/burner\///' > burner_paper.tex

burner/burner.tex

@@ -0,0 +1,63 @@
+%
+% Make the revision and doc number macro's then they are defined in one place
+
+\begin{abstract}
+things can get very abstract
+\end{abstract}
+
+
+\section{Overview of A Burner Controller : Safety Perspective}
+
+\section{Background to the Industrial Burner Safety Analysis Problem}
+
+An industrial burner is a good example of a safety critical system.
+It has the potential for devistating explosions due to boiler overpressure, low water, or
+ignition of an explosive mixture, and, because of the large amounts of fuel used,
+is also a fire hazard. Industrial boilers are often left running unattended 
+for long periods of time (typically days).  
+
+To add to these problems
+Operators are often under pressure to keep them running. A boiler supplying
+heat to a large greenhouse complex could ruin crops
+should it go off-line. Similarly a production line relying on heat or steam
+can be very expensive in production down-time should it fail.
+This places extra responsibility on the burner controller.
+
+
+These are common place and account for a very large proportion of the enery usage
+in the world today (find and ref stats)
+Industrial burners are common enough to have different specific standards
+written for the fuel types they use \ref{EN298} \ref{EN230} \ref{EN12067}.
+
+A modern industrial burner has mechanical, electronic and software
+elements, that are all safety critical. That is to say
+unhandled failures could create dangerous faults.
+
+A more detailed description of industrial burner controllers
+is dealt with in chapter~\ref{burnercontroller}.
+
+
+Systems such as industrial burners have been partially automated for some time.
+A mechanical cam arrangement controls the flow of air and fuel for the range of
+firing rate (output of the boiler).
+
+These mechanical systems could suffer failures (such as a mechanical linkage beoming
+detached) and could then operate in a potentially dangerous state.
+
+More modern burner controllers use a safety critical computer controlling
+motors to operate the fuel and air mixture and to control the safety 
+valves.
+
+In working in the industrial burner industry and submitting product for
+North American and European safety approval, it was apparent that
+formal techniques could be applied to aspects of the ciruit design.
+Some safety critical circuitry would be subjected to thought experiments, where 
+the actions of one or more components failing would be examined.
+As a simple example a milli-volt input could become disconnected.
+A milli-volt input is typically amplified so that its range matches that
+of the A->D converter that you are reading. were this signal source to become disconnected
+the systems would see a floating, amplified signal.
+A high impedance safety resistor can be added to the circuit,
+to pull the signal high (or out of nornal range) upon disconnection.
+The system then knows that a fault has occurred and will not use  
+that sensor reading (see \ref{fig:millivolt}). 

burner/mybib.bib

@@ -0,0 +1,404 @@
+%
+%
+% $Id: mybib.bib,v 1.5 2008/12/18 17:05:23 robin Exp $
+%
+%
+
+@TechReport{db,
+ author = {R Clark, D Legge},
+ title = {ETC6000 Daughterboard Design notes},
+ institution = {ETC HR221850},
+ year = {2004},
+ key = {},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ issn = {HR221850},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@TechReport{mil1991,
+ author = {U.S. Department of Defence},
+ title = {Reliability Prediction of Electronic Equipment},
+ institution = {DOD},
+ year = {1991},
+ key = {MIL-HDBK-217F},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@Manual{tlp181,
+ title = {TLP 181 Datasheet},
+ key = {TOSHIBA Photocoupler GaAs Ired & Photo−Transistor},
+ author = {Toshiba inc.},
+ OPTorganization = {},
+ %address = {http://www.toshiba.com/taec/components2/Datasheet\_Sync//206/4191.pdf},
+ OPTedition = {},
+ OPTmonth = {},
+ year = {2009},
+OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+
+
+
+@Manual{pic18f2523,
+ title = {PIC18F2523 Datasheet},
+ OPTkey = {},
+ author = {Microchip inc},
+ OPTorganization = {},
+ address = {http://ww1.microchip.com/downloads/en/DeviceDoc/39755c.pdf},
+ OPTedition = {},
+ OPTmonth = {},
+ year = {2009},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+
+@Book{wt,
+ title = {Water Treatment Essentials for Boiler Plant Operation},
+ publisher = {Mc Graw Hill ISBN 0-07-048291-5},
+ year = {1997},
+ author = {Robert G Nunn},
+ ALTALTeditor = {},
+ OPTkey = {},
+ OPTvolume = {},
+ OPTnumber = {},
+ OPTseries = {},
+ OPTaddress = {},
+ OPTedition = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {ISBN 0-07-048291-5},
+ OPTlocalfile = {},
+ OPTabstracts = {},
+}
+
+@TechReport{pcbAI222562,
+ author = {C Talmay},
+ title = {Circuit Schematic TDS Daughterboard AI222562},
+ institution = {ETC},
+ year = {2010},
+ OPTkey = {},
+ OPTtype = {},
+ OPTnumber = {AI222562},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@TechReport{spiraxsarco,
+ author = {Spirax Sarco},
+ title = {http://www.spiraxsarco.com/resources/steam-engineering-tutorials.asp},
+ institution = {Spirax Sarco},
+ year = {2010},
+ OPTkey = {},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@Book{aoe,
+ title = {The Art of Electronics},
+ publisher = {Cambridge},
+ year = {1989},
+ author = {Paul Horowitz, Winfield Hill},
+ %author = {},
+ OPTkey = {},
+ OPTvolume = {},
+ OPTnumber = {},
+ OPTseries = {},
+ OPTaddress = {},
+ OPTedition = {2nd},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {ISBN 0-521-37095-7},
+ OPTlocalfile = {},
+ OPTabstracts = {},
+}
+
+@TechReport{eurothermtables,
+ author = {},
+ title = {Thermocouple Emf TABLES and PLATINUM 100 RESISTANCE THERMOMETER TABLES},
+ institution = {Eurotherm},
+ year = {1973},
+ OPTkey = {},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {June},
+ OPTnote = {Bulletin TT-1},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@MISC{iso639-1,
+ title = "ISO 639-1: Code for the Representation of Names of Languages",
+ author = "International Standardization Organization",
+ howpublished = "http://www.loc.gov/standards/iso639-2/criteria1.html"
+ year = "1998"
+}
+
+@MISC{nano-x,
+ title = "The nano-X windowing system",
+ author = "Greg Haerr",
+ howpublished = "http://www.microwindows.org/"
+ year = "2003"
+}
+
+
+
+
+@MISC{X11,
+ title = "The XFree86 Project, Inc",
+ author = "Open Source",
+ howpublished = "http://www.xfree86.org/"
+ year = "1992"
+}
+
+
+http://www.xfree86.org/
+
+@MISC{iso639-2,
+ title = "ISO 639-2: Code for the Representation of Names of Languages",
+ author = "International Standardization Organization",
+ howpublished = "http://www.loc.gov/standards/iso639-2/criteria1.html"
+ year = "1998"
+}
+
+
+@misc{ touchscreenprod,
+       author = "M. Thirsk",
+       title = "Touchscreen Production Procedure : HR~222165",
+       howpublished = "Internal ETC Document",
+       year = "2008" };
+
+
+@misc{ touchscreensoftware,
+       author = "ETC Software Dept.",
+       title = "Touchscreen Software released to Production : HR~222162",
+       howpublished = "Internal ETC Software (medium: 2 MMC cards)",
+       year = "2008" };
+
+@misc{ touchscreengui,
+       author = "D.J. Legge, R.P.Clark",
+       title = "Touchscreen GUI Design Document : HR~222163",
+       howpublished = "Internal ETC Document",
+       year = "2008" };
+
+
+@misc{ gumstix,
+       author = "Gumstix Inc",
+       title = "Gumstix Home Page",
+       howpublished = "WEB http://www.gumstix.com/",
+       year = "2008" };
+
+
+@misc{ fltk,
+       author = "FLTK open Source Developers",
+       title = "Fast Light Toolkit",
+       howpublished = "WEB http://www.fltk.org/",
+       year = "2008" };
+
+
+@Book{ldd,
+author = {Jonathon Corbet},
+ALTeditor = {Alessandro Rubini},
+ALTeditor = {Greg Kroah-Hartman},
+title = {Linux Device Drivers},
+publisher = {O'Reilly ISBN 0-596-00590-3},
+year = {1998},
+OPTkey = {ISBN 0-596-00590-3},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {linux},
+OPTaddress = {},
+OPTedition = {3rd},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+
+@Book{bash,
+author = {Carl Albing},
+title = {Bash Cookbook},
+publisher = {O'Reilly ISBN 0-596-52678-4},
+year = {2007},
+OPTkey = {ISBN 0-596-52678-4},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {unix/linux},
+OPTaddress = {},
+OPTedition = {},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{sedawk,
+author = {Dale Dougherty, Arnold Robbins},
+title = {Sed and Awk},
+publisher = {O'Reilly ISBN 1-56592-225-5},
+year = {1997},
+OPTkey = {ISBN 1-56592-225-5},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {unix/linux},
+OPTaddress = {},
+OPTedition = {},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{bels,
+author = {Karim Yaghmour},
+title = {Building Embedded LINUX systems},
+publisher = {O'Reilly ISBN ISBN 0-596-00222-X},
+year = {2003},
+OPTkey = {ISBN 0-596-00222-X},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {linux},
+OPTaddress = {},
+OPTedition = {3rd},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{can,
+author = {Olaf Pfeiffer},
+ALTeditor = {Andrew Ayre},
+ALTeditor = {Christian Keydel},
+title = {Embedded networking with CAN and CANopen},
+publisher = {RTC ISBN 0-929392-78-7},
+year = {2003},
+OPTkey = { },
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {Embedded Systems},
+OPTaddress = {},
+OPTedition = {1st},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.rtcbooks.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Article{article,
+author = {dd},
+title = {dd},
+journal = {dd},
+year = {2008},
+OPTkey = {},
+OPTvolume = {},
+OPTnumber = {},
+OPTpages = {1,2},
+OPTmonth = {JAN},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{sqlite,
+author = {Micheal Owens},
+title = {The definitive guide to SQLite},
+publisher = {Apres ISBN 1-59059-673-0},
+year = {2006},
+OPTkey = {},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {Databases/SQLite},
+OPTaddress = {},
+OPTedition = {},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+

burner/paper.tex

@@ -0,0 +1,27 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{../style}
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+\outerhead{{\small\bf PT100 FMMD analysis}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{PT100 FMMD analysis}
+\maketitle 
+\input{burner_paper}
+
+\bibliographystyle{plain}
+\bibliography{vmgbibliography,mybib}
+
+\today
+\end{document}

component_failure_modes_definition/Makefile

@@ -0,0 +1,17 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex component_failure_modes_definition_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	okular paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+component_failure_modes_definition_paper.tex: component_failure_modes_definition.tex
+	cat component_failure_modes_definition.tex | sed 's/component_failure_modes_definition\///' > component_failure_modes_definition_paper.tex

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -0,0 +1,111 @@
+
+\abstract{ This chapter defines what is meant by the terms
+components, component fault modes and `unitary~state' component fault modes.
+The application of Bayes theorem  in current methodologies, and
+the unsuitability of the `null hypothesis' or p value statistical approach.
+Mathematical constraints and definitions are made using set theory.
+}
+
+ 
+\section{Introduction}
+When building a system from components, 
+we should be able to find all known failure modes for each component.
+For most common electrical and mechanical components, the failure modes
+for a given type of part can be obtained from standard literature\cite{mil1991}
+\cite{mech}. %The failure modes for a given component $K$ form a set $F$.
+
+
+\subsection{Unitary State Component Failure Mode sets}
+
+An important factor in defining a set of failure modes is that they
+should be as clearly defined as possible.
+%
+It should not be possible for instance for
+a component to have two or more failure modes active at once.
+
+Having a set of failure modes where $N$ modes could be active simultaneously
+would mean having to consider $2^N$ failure mode scenarios.
+% 
+Should a component be analysed and simultaneous failure mode cases exit,
+the combinations could be represented by a new failure modes, or
+the component should be considered from a fresh perspective,
+perhaps considering it as several smaller components
+within one package.
+
+\begin{definition}
+A set of failure modes where only one fault mode
+can be active at a time is termed a `unitary~state' failure mode set.
+This is termed the $U$ set thoughout this study.
+This corresponds to the `mutually exclusive' definition in 
+probability theory\cite{probandstat}.
+\end{definition}
+
+We can define a function $FM()$ to 
+take a given component $K$ and return its set of failure modes $F$.
+
+$$  FM : K \mapsto F $$
+
+We can further define a set $U$ which is a set of sets of failure modes, where
+the component failure modes in each of its members are unitary~state.
+Thus if the failure modes of $F$ are unitary~state, we can say $F \in U$.
+
+
+\subsection{Component failure modes : Unitary State example}
+
+A component with simple ``unitary~state'' failure modes is the electrical resistor.
+
+Electrical resistors can fail by going OPEN or SHORTED.
+However they cannot fail with both conditions active. The conditions
+OPEN and SHORT are mutually exclusive.
+Because of this the failure mode set $F=FM(R)$ is `unitary~state'.
+
+
+Thus
+
+$$ R_{SHORTED} \cap R_{OPEN} = \emptyset $$
+
+
+We can make this a general case by taking a set $C$ representing a collection
+of component failure modes,
+We can now state that
+
+
+$$ c1 \cap c2 \neq \emptyset  | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U  $$
+
+That is to say that if it is impossible that any pair of failure modes can be active at the same time
+the failure mode set is not unitary~state and does not exist in the family of sets $U$
+
+ Note where that are more than two failure~modes, by banning pairs from happening at the same time
+ we have banned larger combinations as well
+
+
+
+\subsection{Bayes Theorem}
+
+Describe application - likely hood of faults being the cause of symptoms -
+probablistic approach - no direct causation paths to the higher~abstraction fault mode.
+Often for instance a component in a module within a module within a module etc
+that has a probability of causing a SYSTEM level fault.
+
+Used in FTA\cite{NASA}\cite{NUK}. Problems, difficult to get reliable stats 
+for probability to cause because of small sample numbers... 
+
+FMMD approach can by traversing down the tree  use known component failure figures
+to 
+%$$ c1 \cap c2 \eq \emptyset  | c1 \neq c2 \wedge c1,c2 \in C \wedge C \in U  $$
+
+%Thus if the failure~modes are pairwaise mutually exclusive they qualify for inclusion into the 
+%unitary~state set family.
+
+
+
+\subsection{Tests of Hypotheses and Significance}
+
+In high reliability systems the fauls are often logged - strange occurances - 
+processors resetting - what are the common factors - P values -
+for instance very high voltage spikes can reset micro controllers -
+but how do you corrollate that with unshielded suppressed contactors...
+
+Maybe looking at the equipment and seeing if there is a 5\%
+level of the error being caused ?
+i.e. using it to search for these conditions ?

component_failure_modes_definition/component_failure_modes_definition.tex~

@@ -0,0 +1,108 @@
+
+\abstract{ This chapter defines what is meant by the terms
+components, component fault modess and `unitary~state' component fault modes.
+Mathematical constraints and definitions are made using set theory.
+}
+
+ 
+\section{Introduction}
+When building a system from components, 
+we should be able to find all known failure modes for each component.
+For most common electrical and mechanical components, the failure modes
+for a given type of part can be obtained from standard literature\cite{mil1991}
+\cite{mech}. %The failure modes for a given component $K$ form a set $F$.
+
+An important factor in defining a set of failure modes is that they
+should be as clearly defined as possible.
+%
+It should not be possible for instance for
+a component to have two or more failure modes active at once.
+
+Having a set of failure modes whhere $N$ modes could be active simultaneously
+would mean having to consider $2^N$ failure mode scenarios.
+% 
+Should a component be analysed and simultaneous failure mode cases exit,
+the combinations could be represented by a new failure modes, or
+the component should be considered from a fresh perspective,
+perhaps considering it as several smaller components
+within one package.
+
+\begin{definition}
+A set of failure modes where only one fault mode
+can be active at a time is termed a `unitary~state' failure mode set.
+\end{definition}
+
+We can define a function $FM()$ to 
+take a given component $K$ and return its set of failure modes $F$.
+
+$$  FM : K \mapsto F $$
+
+We can further define a set $U$ which is a set of sets of failure modes, where
+the component failure modes in each of its members are unitary~state.
+Thus if the failure modes of $F$ are unitary~state, we can say $F \in U$.
+
+
+\subsection{Component failure modes : Unitary State example}
+
+A component with simple ``unitary~state'' failure modes is the electrical resistor.
+
+Electrical resistors can fail by going OPEN or SHORTED.
+However they cannot fail with both conditions active. The conditions
+OPEN and SHORT are mutually exlusive.
+Because of this the failure mode set $F=FM(R)$ is `unitary~state'.
+%A more complex component, say a micro controller could have several
+%faults active. It could for instance have a broken I/O output
+%and an unstable ADC input. Here the faults cannot be considered `unitary~state'.
+
+% A set of failure modes, where only one or no failure modes
+% are active is termed an `unitary~state' failure mode set. This
+% will be donoted as set $A$.
+% 
+To define `unitary~state' using set theory we can define a function
+`active'.
+The function $active(f)$ deontes that the failure mode $f$ (where $f$ is an element of $F$) is currently active.
+
+Thus for the set $F$ to exist in $U$ the following condition must be true.
+
+\begin{equation}
+\label{unitarystate_def}
+ F \in U | f \in F \wedge active(f) \wedge f1 \in F \wedge  f1 \neq f  \wedge \neg active(f1) 
+\end{equation}
+
+As an example the resistor $R$ 
+has two failure modes $R_{open}$ and $R_{shorted}$. 
+
+$$ FM(R) =  F = \{ R_{open}, R_{shorted} \} $$
+ 
+Applying equation \ref{`unitarystate'_definition} to a resistor
+for both fault modes
+
+ $$ active(R_{short}) | R_{short} \in F \wedge R_{open} \in F \wedge R_{open} \neq R_{short}  \wedge \neg active(R_{open})  $$
+ $$ active(R_{open}) | R_{open} \in F \wedge R_{short} \in F \wedge R_{short} \neq R_{open}  \wedge \neg active(R_{short})  $$
+
+For the case of the resistor with only two failure modes the results above, being true,
+show that the failure modes for a resistor of $ F = \{ R_{open}, R_{shorted} \} $ are `unitary~state'
+component failure modes.
+
+Thus 
+     $$ FM(R) =  \{ R_{open}, R_{shorted} \} \in U $$
+
+
+A general case can be stated by taking equation \ref{unitary_state_def} and making it a function thus.
+
+
+\begin{equation}
+\label{`unitarystate'_def}
+ UnitaryState(F) =  \forall f \in F | active(f) \wedge  f1 \in F \wedge f1 \neq f  \wedge \neg active(f1) 
+\end{equation}
+
+%Which can be written
+
+%$$  UnitaryState(FM(K)) $$
+
+
+
+% should this be a paragraph in Symptom Abstraction ????
+
+
+

component_failure_modes_definition/component_failure_modes_definition_paper.tex

@@ -0,0 +1,79 @@
+
+\abstract{ This chapter defines what is meant by the terms
+components, component fault modes and `unitary~state' component fault modes.
+Mathematical constraints and definitions are made using set theory.
+}
+
+ 
+\section{Introduction}
+When building a system from components, 
+we should be able to find all known failure modes for each component.
+For most common electrical and mechanical components, the failure modes
+for a given type of part can be obtained from standard literature\cite{mil1991}
+\cite{mech}. %The failure modes for a given component $K$ form a set $F$.
+
+An important factor in defining a set of failure modes is that they
+should be as clearly defined as possible.
+%
+It should not be possible for instance for
+a component to have two or more failure modes active at once.
+
+Having a set of failure modes where $N$ modes could be active simultaneously
+would mean having to consider $2^N$ failure mode scenarios.
+% 
+Should a component be analysed and simultaneous failure mode cases exit,
+the combinations could be represented by a new failure modes, or
+the component should be considered from a fresh perspective,
+perhaps considering it as several smaller components
+within one package.
+
+\begin{definition}
+A set of failure modes where only one fault mode
+can be active at a time is termed a `unitary~state' failure mode set.
+This is termed the $U$ set thoughout this study.
+This corresponds to the `mutually exclusive' definition in 
+probability theory\cite{probandstat}.
+\end{definition}
+
+We can define a function $FM()$ to 
+take a given component $K$ and return its set of failure modes $F$.
+
+$$  FM : K \mapsto F $$
+
+We can further define a set $U$ which is a set of sets of failure modes, where
+the component failure modes in each of its members are unitary~state.
+Thus if the failure modes of $F$ are unitary~state, we can say $F \in U$.
+
+
+\subsection{Component failure modes : Unitary State example}
+
+A component with simple ``unitary~state'' failure modes is the electrical resistor.
+
+Electrical resistors can fail by going OPEN or SHORTED.
+However they cannot fail with both conditions active. The conditions
+OPEN and SHORT are mutually exclusive.
+Because of this the failure mode set $F=FM(R)$ is `unitary~state'.
+
+
+Thus
+
+$$ R_{SHORTED} \cap R_{OPEN} = \emptyset $$
+
+
+We can make this a general case by taking a set $C$ representing a collection
+of component failure modes,
+We can now state that
+
+
+$$ c1 \cap c2 \neq \emptyset  | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U  $$
+
+That is to say that if it is impossible that any pair of failure modes can be active at the same time
+the failure mode set is not unitary~state and does not exist in the family of sets $U$
+
+ Note where that are more than two failure~modes, by banning pairs from happening at the same time
+ we have banned larger combinations as well
+
+%$$ c1 \cap c2 \eq \emptyset  | c1 \neq c2 \wedge c1,c2 \in C \wedge C \in U  $$
+
+%Thus if the failure~modes are pairwaise mutually exclusive they qualify for inclusion into the 
+%unitary~state set family.

component_failure_modes_definition/paper.tex

@@ -0,0 +1,27 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{style}
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+\outerhead{{\small\bf Unitary State Failure Mode Sets}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{Unitary State Failure Mode Sets}
+\maketitle 
+\input{component_failure_modes_definition_paper}
+
+\bibliographystyle{plain}
+\bibliography{vmgbibliography,mybib}
+
+\today
+\end{document}

component_failure_modes_definition/style.tex

@@ -59,6 +59,15 @@ depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}}
 \newcommand{\key}[1]{\fbox{\sc#1}}                      % Box for keys
 \newcommand{\?}{\_\hspace{0.115em}}                     % Proper spacing for 
                                                         %   underscore
+\newcommand{\rev}{PA5}
+\newcommand{\etcdoc}{ HR222975 }
+\newcommand{\wlc}{{Water~Level~Controller~Unit}}
+\newcommand{\ft}{{\em 4 $\rightarrow$ 20mA } }
+\newcommand{\tds}{TDS Daughterboard}
+\newcommand{\oc}{$^{o}{C}$}
+\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
+\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
+\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
 %----- Display example text (#1) in typewriter font
  
 %\newcommand{\example}[1]{\\ \smallskip\hspace{1in}{\tt #1}\hfil\\
@@ -118,11 +127,23 @@ depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}}
 %  \normalfont \begin{quote}}{\end{quote}\par}
 \usepackage{amsthm}
 
-\newtheorem{example}{Example:}[examplec]
+\newtheorem{example}{Example:}
-
+\newtheorem{definition}{Definition:}
-\newtheorem{definition}{Definition:}[examplec]
 \newtheorem*{summary}{Summary:}
 
+
+%
+\newcommand{\Fam}{{\mathbb F}}
+\newcommand{\Pow}{{\mathbb P}}
+\newcommand{\Dis}{{\vee}}
+\newcommand{\Con}{{\wedge}}
+\newcommand{\FMEA}{{\bowtie}}
+%
+\newcommand{\Nat}{{\mathbb N}}
+\newcommand{\Real}{{\mathbb R}}
+\newcommand{\Complex} {{\mathbb C}}
+\newcommand{\Rational} {{\mathbb Q}}
+%
 %\newenvironment{example}
 %{ \stepcounter{examplec} \vspace{10pt} \normalfont\bfseries Example:(\arabic{chapter}.\arabic{examplec})
 %  \normalfont \begin{quote}}{\end{quote}\par}

fmmdset/Makefile

@@ -0,0 +1,16 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex fmmdset_p.tex
+	pdflatex paper.tex
+	#dvipdf paper
+	okular paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+fmmdset_p.tex: fmmdset.tex
+	cat fmmdset.tex | sed 's/fmmdset\///' > fmmdset_p.tex

fmmdset/fmmdset.tex

@@ -878,7 +878,45 @@ from $1$ to $cc$ thus
 % $$ {\sum}_{k = 1..cc} {\#S \choose k} = \frac{\#S!}{k!(\#S-k)!} $$
 %
 
-$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!} $$
+$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!}    $$
+
+
+
+\subsection{Actual Number of combinations to check with Unitary State Fault mode sets}
+
+Where all components analysed only have one fault mode, the cardinality constrained powerset
+calculation give the correct number of test case combinations to check.
+Because  set of failure modes is constrained to be unitary state, the acual number will
+be less.
+
+
+What must actually be done is to subtract the number of component `internal combinations'
+from the cardinality constrain powerset number.
+
+Thus were we to have a simple circuit with two components R and T, of which
+$FM(R) = {R_o, R_s}$ and $FM(T) = {T_o, T_s, T_h}$.
+For a cardinality constrained powerset of 2, because there are 5 error modes
+gives $\frac{5!}/{1!(5-1)!} + \frac{5!}{2!(5-2)!}  = 15$. OK
+5 single fault modes, and ${2 \choose 5}$ ten double fault modes.
+However we know that the faults are mutually exclusive for a component.
+We must then subtract the number of `internal' component fault combinations.
+For component R there is only one internal component fault that cannot exist
+$R_o \wedge R_s$. As a combination ${2 \choose 2} = 1$ . For $T$ the component with 
+  three  fault modes ${2 \choose 3} = 3$.
+Thus for $cc == 2$ we must subtract $(3+1)$.
+
+Written as a general formula, where C is a set of the components (indexed by j where J 
+is the set of componets under analyis) and $\#C$
+indicates the number of mutually exclusive fault modes the compoent has:-
+
+%$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!}    $$
+
+$$ \#\mathcal{P}_{cc} S = {\sum^{k}_{1..cc}  \frac{\#S!}{k!(\#S-k)!}}  - {\sum^{j}_{j \in J} {\#C_{j} \choose cc}}  $$
+
+
+
+%$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc}  \big[ \frac{\#S!}{k!(\#S-k)!}  - \sum_{j} (\#C_{j} \choose cc \big]  $$
+
 
 \section{Future Ideas}
 

fmmdset/fmmdset_p.tex

@@ -1,925 +0,0 @@
-
-
-
-% $Id: fmmdset.tex,v 1.7 2009/06/06 11:52:09 robin Exp $
-
-
-
-
-
-%
-\newcommand{\Fam}{{\mathbb F}}
-\newcommand{\Pow}{{\mathbb P}}
-\newcommand{\Dis}{{\vee}}
-\newcommand{\Con}{{\wedge}}
-\newcommand{\FMEA}{{\bowtie}}
-%
-\newcommand{\Nat}{{\mathbb N}}
-\newcommand{\Real}{{\mathbb R}}
-\newcommand{\Complex} {{\mathbb C}}
-\newcommand{\Rational} {{\mathbb Q}}
-%
-%\newtheorem{theorem}{Thoeorem}
-% 
-% \def\lastname{Clark}
-% \begin{document}
-% \begin{frontmatter}
-%   \title{ Failure Mode Modular De-Composition } \author{Robin Clark\thanksref{ALL}\thanksref{r.clark@energytechnologycontrol.com}}
-%   \address{ Energy Technology Control\\
-%     25 North Street, Lewes, BN7 2PE, Great Britain} 
-
-\begin{abstract} 
-This chapter describes a process for analysing safety critical systems, to formally prove how safe the
-designs and built -in safety measures are. It provides
-the rigourous method for creating a fault effects model of a system from the bottom up  using part level fault modes.
-From the model fault trees, 
-modular re-usable sections of safety critical systems,
-and accurate, statistical estimation for fault frequency can be derived automatically.
-It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
-It is intended to be used to formally prove systems to meet EN and UL standards, including and not limited to
-EN298, EN61508, EN12067, EN230, UL1998.
-
-\end{abstract}
-
-
-% \begin{keyword}
-%   fault~tree fault~mode EN298 EN61508  EN12067  EN230 UL1998 safety~critical
-% \end{keyword}
-% \end{frontmatter}
-
-
-% \bibliographystyle{unsrt}
-
-\section{Introduction}
-
-%This paper describes the  Failure Mode Modular de-Composition (FMMD)  method.
-% described here, models a safety critical system from the bottom up.
-
-The purpose of the FMMD methodology is to apply formal techniques to
-the assessment of safety critical designs, aiding in identifying detected and undetected faults
-\footnote{Undetectabed faults 
-are faults which may occur but are not self~detected, or are impossible to detect by the system}.
-Formal methods are just begining to be specified in some safety standards.\footnote{Formal methods 
-such as the Z notation appear as `highly recomended' techniques in the EN61508 standard, but
-apply only to software currently}.However, some standards are now implying the handling of
-simultaneous faults which complicates the scenario based approvals that are currently used.
-
-% Some safety critical system assemesment criteria 
-%are statistical, and require a target failure rate per hour of operation be met \cite{EN61508}.
-%Specific safety standards may apply criteria such as no single part failure in a system may lead to
-%a dangerous fault. 
-
-There are two main philosophies in assessing safety critical systems.
-One is to specify an acceptable level of dangerous faults per hour of operation\footnote{The probability of failure per hour (PFH)
-is measured in failures per 1e-9 seconds}.
-This is a statistical approach. This is the approach taken by the European safety reliability 
-standard EN61508 commonly referred to as the Safety Integrity Level (SIL)
-standard.
-The second is to specify 
-that any single or double part faults cannot lead to a dangerous fault in the system under consideration.
-This entails tracing the effects of all part failure modes 
- and working out if they can lead to any dangerous faults in the system under consideration.
-%For instance, during WWII after operational research teams had analysed  data it was determined that
-% an aircraft engine that can, through one part failure cause a catastrophic failure is an unacceptable design.\cite{boffin} .
-
-Both of these methods require a complete fault analysis tree.%\cite{FMEA}. 
-The statistical method 
-requires additional Mean Time To Failure (MTTF) data for all part failure modes.
-
-The FMMD methodology applies defined stages and processes that will
-create a modular fault mode hierarchy. From this
-complete fault analysis trees can be determined. It uses a modular approach, so that repeated sections
-of system design can be modelled once, and re-used.
-%formally prove safety critical 
-%hardware designs. 
-The  FMMD method creates a hierarchy from
-part~fault~mode level up to system level. 
-%It does this using
-%well defined stages, and processes.  
-%It allows re-use of analysed modules DOH DOH DOH
-%, and to create a framework where
-%fault causation trees, and statistical likelihood 
-%of faults occurring are 
-When a design has been analysed using this method, fault~trees may be traversed, and statistical likelihoods of failure
-and dangerous~faults can be determined from traversing the fault tree down to the MTTFs of individual parts.
-
-
-%Starting with individual part failure modes, to collections of %parts (modules)
-%and then to module level fault modes.
-
-\subsection{Basic Concepts Of FMMD}
-
-\subsubsection { What is a part ? }
-
-A Part here means a lowest level component, an entity which can be bought and 
-hopefully has some statisics for MTTF and known failure modes.
-Where manufacturers MTTF data is non-existant (or unverified) a guide such as MIL1992\cite{MIL1992} may be used.
-Parts for approved safety critical systems under formal observance~\cite{FMproduction} 
-will be documented in a parts list. The `parts list' is a formal document for 
-both design and quality assured production.
-A parts list will typically include
-the manufacturers part number, guidance for placement in the system, 
-a functional description, vendor parts numbers
-and a description. A resistor, capacitor or a microcontroller would be typical of a `part'.
-A part will normally have a set of failure~modes, or ways in which it can fail. Thus a set of failure~modes
-is associated with each part. 
-
-\subsubsection{ Creating a fault hierarchy}
-
-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
-parts that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of 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 parts themselves, but in the ways in which they can fail.
-
-For this study a Module will mean a collection of fault modes.
-For a module formed from a {\em functional group} this will be the collection of all fault modes of its parts.
-By analysing the fault behaviour of a `module' with respect to all the fault~modes, 
-we can derive a new set of possible fault~modes at the module level. 
-This new set of faults is the set of derived faults from the module level and is thus at a higher level of 
-fault~mode abstraction. Thus we can say that the module as a whole entity can fail in a number of well defined ways.
-
-In other words we have taken a functional group, and analysed how it can fail according to the failure modes of its parts.
-The ways in which the module can fail now become a new set of fault modes, the fault~modes
-derived from the module. 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. 
-
-
-
-%Choosing small sections of the system, by choosing a collection of interacting parts we can form
-%modules. These parts are collected together to form modules $M$. These modules are then 
-%analysed with respect to the failure modes of the parts that make them up.
-%This leads to a set of fault modes for each module, the derived fault~modes $D$.
-%These derived fault modes may now be used at a higher abstraction level.
-%A hierarchy can be built, with each level representing a higher level of fault abstraction.
-
-%Each part may fail in a number of ways.  
-We can take the levels of abstraction and view them as a hierarchy, with part level faults at the bottom.
-Each time we analyse a set of fault modes, with respect to how they interact,
-we get a new set of faults a higher level of fault abstraction.
-At the lowest level of fault~mode abstraction is the
-part failure modes. This is the hierarchy abstraction level zero. Functional~groups, collections of parts are also at
-abstraction level 0. Combining derived fault modes from functional groups to form {\em modules}, will
-also be at level 0. 
-%By deriving the fault modes for a particular module.
-A set of faults derived from a `module' will be at abstraction level 1.
-Thus the module, a collection of parts is analysed, and the fault symtopms of that module derived.
-The act of analysing and deriving new faults raises the abstraction level.
-
-
-Simple parts may have
-a single failure mode, and more  complex ones may have hundreds.
-% Hazel 11FEB2008 said this was difficult to read
-%It can be easily seen that trying to judge the effect of a single part mode failure against
-%all other parts failure modes in the system would be a thankless and practically impossible task.
-Were we to analyse the effect of each part failure mode against all other parts in the circuit,
-we could be facing a very large task.
-Modularisation allows detailed (part fault mode level) analysis of well defined functional groups within a system.
-The hierarchy allows the combining of these modules to form meaningful fault represention of the system.
-
-
-An example of a simple system will illustrate this.
-
-\subsection{Example FMMD Hierarchy}
-
-
-%%% This is the tikz picture ??/
-%
-%\begin{figure}[h+]
-%\centering
-%\input{mvsblock.tex}
-%\caption{Block Diagram : Example  Milli-Volt Sensor : Block Diagram}
-%%\includegraphics[scale=0.20]{ptop.eps}
-%\label{fig:mvsblock}
-%\end{figure}
-%
-Consider a simple electronic system, that provides say two milli amplifiers
-which supplies these onward via serial link - RS232. This is simple in concept, plug in a 
-computer, run a terminal prgram, and the instrument will report the milli volt readings in ASCII
-with any error messages.
-
-% in CRC checksum protected packets.
-
-It is interesting to look at one of `functional groups'. The millivolt amplifiers are a good example.
-These can be analysed by taking a functional~group, the components surrounding the op-amp, 
-a few resistors to determine offset and gain,
-a safety resistor, and perhaps some smoothing capacitiors.
-These components form the functional group. The circuit is then analysed for all the fault combinations 
-of these parts. This produces a large collection of possible fault~modes for the milli-volt amplifier.
-The two amplifiers are now connected to the ADC which converts the voltages to binary words for the microprocessor.
-The microporessor then uses the values to determine if the readings are valid and then formats text to send
-via the RS232 serial line.
-
-
-\begin{figure}[h+]
-%\centering
-%\input{millivolt_sensor.tex}
-\includegraphics[scale=0.4]{millivolt_sensor.eps}
-\caption{Hierarchical Module Diagram : Milli-Volt Sensor Example}
-\label{fig:mvs}
-\end{figure}
-
-This has a number of obvious functional~groups, the PCB power supply, the milli-volt amplifiers,
-the analog to digital conversion circuity, the micro processor and the UART (serial link - RS232 transceiver).
-It would make sense when analysing this system to take each one of these functional~groups in turn and examine them closely.
-
-It would be sensible if the system could detect the most obvious fault~modes  by self testing.
-When these have been examined and diagnostic safeguard strategies have been thought up,
-we might look at reporting any fault via the RS232 link.
-% (if it still works !).
-
-By doing this we have already used a modular approach. 
-We have analysed each section of the circuitry,
-and then using the abstract errors derived from each module, 
-can fit these into a picture of the 
-fault~modes of the milli-volt monitor as a whole. However this type of analysis is not guaranteed
-to rigourously take into account all fault~modes. 
-It is useful to follow an example fault though levels of abstraction hierarchy however, see below.
-   
-%The FMMD technique, 
-%goes further than this by considering all part fault~modes and 
-%places the analysis phases into a rigid structure. 
-%Each analysis phase is
-%described using set theory in later sections. 
-%By creating a rigid hierarchy, not only can we traverse back
-%down it to find possible causes for system errors, we can also determine 
-%combinations of fault modes that cause certain high level fault modes.
-%For instance, it may be a criteria that no single part failure may cause a fatal error.
-%If a fault tree can trace down to a single part fault for a potentially fatal 
-%fault mode, then a re-design must be undertaken.
-%Some standards for automated burner controllers demand that two part failure modes cannot cause 
-%a dangerous/potentially fatal error. Again having a complete fault analysis tree will reveal these conditions.
-
-
-\subsection{An example part Fault and its subsequent \\ abstraction to system or top level}
-
-An example of a part fault effect on the example system is given below, showing how this fault 
-manifests itself at each abstraction level.
-
-%\begin{example}
-As an example let us consider a resistor failure in the first milli-volt sensor.
-
-Let us say that this resistor, R48 say, with the particular fault mode `shorted'
-causes the amplifier to output 5V.
-At the part level we have one fault mode in one part. 
-%This is the lowest or zero level of fault abstraction.
-Let us say that this amplifier has been designed to amplify the milli-volt input
-to between 1 and 4 volts, a convenient voltage for the ADC/microcontroller to read.
-Any voltage outside this range will be considered erroneous.
-As the resistor short causes the amplifier to output 5V we can detect the error condition.
-This resistor is a part in the `millivolt amplifier 1' module.
-% (see figure \ref{fig:mvs}).
-The fault mode at the derived fault  level (abstraction level 1) is OUTPUT\_HIGH.
-Looking higher in the hierarchy, the next abstraction level higher, level 2, will see this as
-a  `CHANNEL\_1' input fault. 
-%The system as a whole (abstraction level 3) will see this as 
-%a `MILLI\_VOLT\_SENSOR' fault~mode.
-%\end{example}
-
-\subsubsection{Abstraction Layer Summary \\ for example fault.}
-\begin{description}
-%\begin{list}
-\item[Abstraction Level 0 :] Resistor has fault mode `R48\_SHORT' in amplifier 1.
-\item[Abstraction Level 1 :] Amplifier 1 has fault mode `OUTPUT\_HIGH'.
-\item[Abstraction Level 2 :] Milli-volt sensor has `CHANNEL\_1' fault.
-%\item[Abstraction Level 3 :] System has `MILLI\_VOLT\_SENSOR' fault.
-%\end{itemize}
-%\end{list}
-\end{description}
-
-
-
-
-
-Thus we have looked at a single part fault and analysed its effect from the
-bottom up on the system as a whole, going up through the abstraction layers.
-
-\subsubsection{Fault Abstraction Level}
-\label{fal}
-Let the fault abstraction level mean the number of times an element of a system
-has been transformed by applying fault modes effects analysis. In the example above
-the error becomes more abstract, each time we zoom out and consider the effects of
-the fault on more generalised sections of the system.
-
-
-\section{ Fault Modes and Collections }
-
-
-A safety critical system is usually a collection of highly specified interacting parts.
-These are 
-documented in a 'parts list', which is taken to define to the standards
-agencies the authorised parts that will be used for a particular approved product.
-This is an important document, used in an official sense, by standards agency
-inspectors, often to validate production processes. 
-
-\begin{definition}
-Let $L$ be the index set for a given system.
-Let $p$ denote a part in the `parts~list' $ P_L = \{ \; p_l \; | \; l \; \in \; L \; \} $
-Thus $P_L$ represents a set of all parts in a safety critical product.
-\end{definition}
-
-{\em
-Should this be a list instead ?
-$ P_L = < \; p_1..L \; | \; p_l \; \in \; P_L \; > $
-}
-
-All parts in a safety critical system have known  
-`fault~modes'.
-
-A fault~analysis function $fa$  may be applied to a part part $p$
-returning a set of `fault~modes'.
-
-\begin{definition}
-Let the set $D^{a}_{l}$ represent a set of derived fault~modes.
-where $a$ represents the abstraction level, and $l$ is an index to the part that gives rise to these fault modes.
-A superscript of $0$ indicates that the fault~modes have been derived from
-the lowest abstraction level, the parts~level.
-%Let $K_p$ be the set of possible fault~modes for a given part `$p$',
-%Let $p$ denote a part in the `parts~list' indexed by the variable l,  $ PL = \{ {p}_{l} | l \in L \} $
-%Thus PL represents a set of all parts in the system.
-\end{definition}
-
-\begin{definition}
-\label{func:fa}
-$$ fa(p_l) = \{ f_1, f_2, f_3 ... f_n \} = D^{0}_{l} $$
-where $f_1...f_n$ represent part fault modes for the part $p_l$.
-
-The fault~modes corresponding to part $p_l$ are represented by the set $ D^{0}_{l}$.
-\end{definition}
-
-%\begin{example}
-For instance were part number 48 in a parts~list to be a wire wound resistor
-applying fault analysis
-would derive two fault conditions, open and short.
-$$ fa(p_{48}) = \{ OPEN_{48}, SHORT_{48} \} = D^{0}_{48}$$
-\label{disjointnotcare}
-%\end{example}
-
-\subsection { Defining an entire system \\ as a family of fault modes}
-
-As a thought experiment, let us consider an entire system in terms of all its fault modes.
-So without breaking a circuit into modules or chunks or whatever, just consider all the fault modes of all the components in a system.
-One way of analysing a system would be to take each part fault mode 
-in turn and then to determine its effect on the system as a whole.
-This means taking a particular part fault mode and checking its effects upon every other component in the system.
-
-\begin{definition}
-\label{func:s0}
-Let $S^{0}$ be a family of sets of part~faults, for all parts in the parts list
-\label{systemlevel0}
-$$ {S^{0}} = \{  \; D^{0}_{l} \; | \; l  \; \in \; L  \; \} $$
-which is the same as saying 
- $${S^{0}} = \{ fa(x) | x \in P_{L} \} $$
-\end{definition}
-
-The entire set of all part `fault~modes' for a complete system $S^{0}$, can be defined
-by a family of all part fault~mode sets $D^{0}_{s}$, indexed by s with L as the index set.
-
-$S^0$ then represents all the fault modes of all the parts in the system we are analysing.
-
-We could analyse this circuit by taking each part~fault~mode and working out what effect it will have on the system as a whole.
-This would be analysing the system from the perspecive of the effect of single part failures.
-
-We could go further and take all combinations of double simultaneous faults possible
-and examine their effect on the system.
-
-
-%\begin{equation}
-%\label{systemlevel0}
-% {S^{0}} = \{  \; K^{0}_{l} \; | \; l  \; \in \; L  \; \} = \{ fa(x) | x \in P_{L} \} 
-%\end{equation}
-
-%
-%-OR- In terms of the parts~list, parts transformed to set $K$ by function`$fa$' all exist in $S^0$
-%$$   \forall x  \{ x \in PL | fa(x) \in S^{0} \}$$
-%
-
-To completely analyse the effect of all part failure modes we would
-need to consider their affects in all combinations. In other words we
-would have to look at each fault~mode and then see how it affected every other component in the system
-and then work out what effect that would have on the entire system.
-Checking every combination of fault~modes corresponds to the power set of the union of the set in $S^0$
-
-(using $ \mathcal{P} $ to represent the power set, and  $(\bigcup {S^0})$ to mean flattening the family of sets).
-
-
-$$ AllcombinationsofPartFaults = \mathcal{P} ({\bigcup}_{l \in L} D^{0}_{l}) = \mathcal{P} (\bigcup {S^0}) $$
-
-%where $ \cup \mathcal{F}S = \{ x | \forall A \in \mathcal{F}(x \in A) \} = \{x|\forall A ( A \in \mathcal{F} \rightarrow x \in A) \} $
-
-That is to say, checking for all the part faults in the system, in all combinations.
-% (including the empty set)
-Taking the power set $ \mathcal{P} $ of the union of the family $S^0$, i.e. $ \mathcal{P} (\bigcup {{S}^{0})} $, would give us all possible
-combinations of part faults in the system.
-
-
-% Get the formula from the 2004 paper done with JEAN
-
-\begin{example}A typical circuit board with say 1000 parts each of which have 
-say, 5 error modes, would mean $S^0$ would have 5000 elements.
- 
-Thus, to check for the effect of single part failure modes would entail 5000 checks against 999
-parts.
-To check for all double failures $(5000-1)^2*998$
-To check all possible combinations of failure modes, 
-would lead to an astonishing number part~failure~modes to check ($2^{5000}$).
-A full check at the part fault mode level is therefore impractical.
-\end{example}
-
-
-\subsection{Reducing the Power set combinations}
-It would be much better if we could break the problem down into manageable chunks,
-analyse the behaviour of the chunks and then combine them, with other fundtional~groups, 
-that have been analysed.
-
-In this way we could build a hierarchy of modules with analysis phases
-leading to an eventual model of the entire system.
-
-\begin{definition}
-Let $F$ be a functional group of components within a system.
-A `functional~group' once identified will be a sub-set of the parts~list $P_L$.
-$ F \subseteq P_L $
-\end{definition}
-
-A {\em functional group} defined from the parts is at the zero'th level of abstraction. 
-The {\em functional group} is a collection: no analysis has been applied
-and it therefore is a group at zero level fault abstraction.
-To indicate this it will be given a superscript of 0.
-There may be a large number of functional~groups identified at this stage.
-An index will be used as a subscript to identify them. Thus $F^{0}_{4}$ would be the fourth
-identified functional group.
-
-\begin{example}
-Looking at the milli-volt sensor in figure~\ref{fig:mvs}, 
-we can easily identify the milli-volt amplifier as a functional group.
-It has a small number of components and one specific well defined job.
-That is to amplfy a milli volt signal to within a given range and to
-pass this on to another functional group to read it (the ADC).
-\end{example}
-
-The functional group as a list of parts is not directly useful. If we define a function
-`$fm$` that translates a set of parts (functional~group) into a corresponding family of
-fault~mode sets, these can be used for further analysis. 
-These families of fault mode sets are termed `modules'.
-
-%Using the function $\#$ to represent cardinality thus $\#(A) = Cadinality(A)$. 
-
-\begin{definition}
-Let $M^{a}_{n}$ represent a family of derived fault modes 
-corresponding to the functional group $F^{a}_{n}$, where $a$ represents the abstraction level
-and $n$ is an index.
-\end{definition}
-
-The set $M^{0}_{n}$ is a family of fault~modes corresponding to the {\em functional group} 
-$F^{0}_{n}$, where the superscript $a$, represents the 
-hierarchy/abstraction level, and $n$ corresponds to the functional group index.
-
-\begin{definition}
-\label{func:fm}
-The function fm translates a set of parts to a set of corresponding fault~modes
- $$fm: F^{0}_{n}  \rightarrow M^{0}_{n} $$
-or
-$$ M^{0}_{n} = \{ fa(p) | p \in F^{0}_{n} \} $$
-%
-% completeness not necessaary with cardinality of sets as it iterates over whole parts list
-% $$ fm( M^{a}_{n} ) = \forall x \{ x | ( x \in M^{a}_{n} \rightarrow ( fa(x) \in K^{a}_{n} ) \Con ( \#(M^{a}_{n}) =  \#(K^{a}_{n} ) ) \}$$
-%
-\end{definition}
-
-\begin{summary} 
-Beginning with the 
-individual parts, we have combined these to functional~groups.
-These functional groups have been converted into a family of corresponding sets of fault~modes (modules).
-The next stage is to perform fault~mode~effect~analysis to determine the ways in which the `module' can fail.
-Or in other words a set of faults at the `module'
-level : i.e. a higher level of fault~mode abstraction.
-\end{summary}
-
-\section { FMEA : Fault Mode Effect Analysis }
-
-Fault mode effects analysis, is the process of looking at a module and determining how it will fail
-according to different scenarios of part failures.
-This can be in the nature of a thought experiment (for instance looking an an electronic circuit, 
-we might say what happens if this resistor goes open etc),
-or could be based on empirical data. However the results gathered would always be subject to
-the scrutiny and approval of any standards agency they would be submitted to\footnote{Some standards are now listing common electronic parts with associated fault~modes that must be considered for
-the approval process \cite{EN61508}.}. Often in an approval process, the approval agencies will talk through fault scenarios and require that manufacturers defend against potential part faults. This is on the basis of experience and knowledge of the type of
-system under analysis. It is not necessarilly a rigourous or mathematically complete process.
-
-%This analysis needs to be performed by an expert
-%for the system under scrutiny.
-%\begin{definition} A module is a family of sets of `fault modes' of parts (eqn \ref{module}).\end{definition}
-
-By looking at how the part fault~modes within a module interact; and then
-analysing the scenario for every fault~mode combination, we can determine a new set of fault~modes, fault~modes
-from the perspective of the module.
-
-\begin{definition}
-Let  $D^{a+1}_{n}$ be the set of  fault~modes derived from a  module $M^{a}_{n}$.
-A superscript will define the abstraction level and a subscript the module index.
-Note that the act of deriving fault~modes from a module, raises the abstraction level.
-
-\end{definition}
-
-\begin{definition}
-Let the symbol $\FMEA$ mean `fault mode effects analysis'. This will translate a set  family $M$ into a corresponding set $D$.
-i.e. $ \bowtie: M^{a}_{n}  \mapsto D^{a+1}_{n}$ The $\bowtie$ operation has the effect of raising the fault abstraction level.
-
-\end{definition}
-
-%Each module analysed map to a derived set
-%which will have the same subscript and index.
-%A module at abstraction level 0, can be mapped
-% to a derived set by applying $\FMEA$ to the M set thus:
-\begin{equation}
-\label{derive0}
- D^{1}_{N} \; =    \FMEA({\cal P} \; \bigcup \; M^{0}_{N}) =  \FMEA({\cal P} \; \bigcup \; fm (F^{0}_{N}) \; ) 
-\end{equation}
-
-The set $ D^{1}_{N} $ is the set of errors derived from the Nth module at abstraction level 0.
-$D^1_{n}$ sets derived in this way, could now be used in the same way as the $D^0_n$ sets  were in the last example,
-but at a higher level of abstraction. Thus one or more  $ D^{1}_{N} $ sets can be combined
-to form a $M^1_{n}$ set i.e. 
-
-\begin{example}
-For example, we could build a first level $M$ set from three first level module derived fault modes, say
-$ D^{1}_{1}, D^{1}_{4}, D^{1}_{7}$.
-$$ M^{1}_{N} =  \{ D^{1}_{1}, D^{1}_{4}, D^{1}_{7} \} $$
-This $ M^{1}_{N} $ set may now be subjected to FMEA and will return a set of derived fault~modes at the second level of hierarchy thus
-
-\begin{equation}
- D^{2}_{N} \; =    \FMEA({\cal P} \; (\bigcup \; M^{1}_{N})) 
-\end{equation}
-
-This may continue up until the hierarchy is complete, with the fault~modes becoming more and 
-more abstract as the hierarchy gets higher. The top of the hierarchy will be a set of derived 
-fault modes, representing the system fault modes.
-
-\end{example}
-\subsection{The FMEA Process}
-
-In practise the combinations of fault modes to be analysed are placed on a 
-matrix, and the fault effect is determined for each combination under scrutiny.
-
-It may be found that one or more combinations of part fault~modes will lead to the same module
-level fault~mode. The means that the module could fail in the same way due to a variety of causes, 
-and this fact will be useful later for determining fault trees. But more importantly, it means that the number
-of fault conditions for a module should be smaller than the sum of all the part error conditions
-in the module. 
-
-
-\subsection{ Practical limits for the number \\ of fault mode combinations to \\ consider within a module}
-
-It may not be deemed necessary to analyse all scenarios from the power-set of an $M$ set.
-Some European standards will only consider one part fault at a time for analysis
-and stricter ones\ref{en298} imply checking for double simultaneous faults. Statistically it 
-becomes very unlikely to have more than two parts fail suddenly and 
-European\ref{en298} and North American\ref{UL1998} standards reflect this belief. 
-To express this formally we can use a cardinality restricted powerset see \ref{ccp}
-Thus for considering single part fault modes only, equation \ref{derive0} becomes
-
-$ D^{2}_{N} \; =    \FMEA({\cal P}_1 \; (\bigcup \; M^{1}_{N}))$ 
-And for considering double and single fault modes $ D^{2}_{N} \; =    \FMEA({\cal P}_2 \; (\bigcup \; M^{1}_{N}))$.
-
-{\em NOTE: need proof here of how this translates UP the hierarchy, because as it goes UP
-only more error sources can be included in the fault tree NOT LESS OK need the express this formally maybe}
-
-
-%Collecting the derived fault modes is thus important.
-The FMEA process can be represented visually, by making part fault modes contours and scenario test
-cases points. Points which have the same module level fault~mode can now be joined by lines.
-
-%Although this looks very much like a spider diagram, but it would be misleading to think of it so.
-Note this is not a diagram representing sets. The Euler diagram here
-is being used to represent logical conditions.
-Each collection of test~cases joined by line(s) is a derived fault mode at the module level.
-
-\subsection{FMEA Diagram : Definition of Symbols}
-
-
-
-%\begin{figure}[t+]
-%\centering
-%\epsfig{file=cimg5043fmmd_spider.eps, width=\textwidth}
-%\caption{ FMEA Diagram : Example Incomplete Analysis }
-%\label{fig:sdfmea}
-%\end{figure}
-
-\begin{figure}
-\centering
-\input{fmea_diagram.tex}
-\caption{FMEA Diagram : Example Incomplete Analysis}
-\label{fig:sdfmea}
-\end{figure}
-
-When viewed as an FMEA diagram, each part fault mode would become a contour.
-Each (asterisk `*') represents test~case corresponding to a combination of fault~modes within the module.
-Overlapping contours represent the occurrence of simultaneous faults (i.e. all the fault modes
-corresponding to contours are considered active for the test case).
-
-\begin{summary}
-\begin{itemize}
-\item Test cases are represented by `*' marks.
-\item Conjuction of fault~modes (i.e. simultaneous faults) are represented by overlapping regions of contours.
-\item Lines joining test cases mean the test cases cause the same fault at the module or $M$ set abstraction level.
-\end{itemize}
-\end{summary}
-
-{\em TO DO: well formness and specific rules for FMEA diagrams}
-
-\subsection {Example FMEA process using an FMEA diagram}
-
-Consider a simple functional~group  $ F^0_1 $ derived from two parts $p1,p2$.
-
-Applying fault analysis to these parts gives sets of corresponding fault modes
-(where $D^0_p$ is the set of fault modes for the part $p$, 
-and the individual fault modes use an indexed lower case $f$ 
-with the part number with a post fixed fault type, here a..z).
-
- $$ fa(p1) = \{ f_{p1a}, f_{p1b}, f_{p1c} \} = D^0_{p1} $$  
-
- $$ fa(p2) = \{ f_{p2a}, f_{p2b} \} = D^0_{p2} $$
-
-
-Applying the `$fm$' function defined in (\ref{func:fm}) to the functional group $F$ 
-gives an $M$ set. This is a module that we can use for fault behaviour analysis.
-
- $$ fm( F_{1}^{0}  )  =  M_{1}^{0} =  \{ D^0_{p1}, D^0_{p2} \} $$
-
-Note the definition of the Union of this family is
-
-$$ {\bigcup}{M_1^0} =  \{ f_{1a}, c_{1b}, f_{1c},  f_{2a}, f_{2b} \} $$
-
-To analyse the effects of the fault~modes on the module,  we first take the power set of the union of this family
-
- $$  \mathcal{P} ({\bigcup}{M_1^1}) =  \mathcal{P} \{ f_{1a}, f_{1b}, f_{1c},  f_{2a}, f_{2b} \} $$
-
-The Power-set returns all possible combinations of faults. In this case it would be $2^5$ number of combinations to check.
-We could restrict the cardinality of the powersets and reduce the complexity level.
-For this we can use a restricted cardinality powerset (see \ref{ccp}).
-If we restrict our search to single faults  and  double simultaneous faults $\mathcal{P}_{2}$, we can use a two dimensional
- Euler\footnote{Euler diagrams are here not used to represent sets, but are used to represent boolean logic conditions}
- diagram to represent this. In this Euler diagram, for simplicity, only 5 test cases 
-have been analysed (see figure \ref{fig:sdfmea}). 
-For the purposes of this example it has been decided that some combinations of part faults, cause the same module level error.
-Where this happens test~cases are joined by lines to indicate that they cause the same fault 
-(from the module or $M^a_n$ set perspective).
-
-The single point $f2$ represents a module fault mode caused by the 
-combined part failures of $ f_{p2b}$ and $f_{p1a}$.
-
-As an equation
-
- $$f2 \rightarrow f_{p2b} \Con f_{p1a} $$
-
-Two pairs of test cases cause the same module level error.
-$f1$ and $f3$, are both joined to two test cases by connecting lines.
-
-The module level fault mode $f1$ was caused by either fault~mode $c_{1b}$ or by
-the combination of $f_{p1c} \Con f_{p2b}$. 
-As an equation  
-$$f1 \rightarrow f_{p1b}  \Dis (f_{p1c} \Con f_{p2b}) $$
-
-Similarly the logical causes for $f3$, are  
-$$f3 \rightarrow (  ( f_{p1a} \Con f_{p2a} ) \Dis (  f_{p1b} \Con f_{p2a} )    ) $$
-or simplifying by distributive law
-$$f3 \rightarrow (  f_{p2a} \Con (  f_{p1b} \Dis f_{p2a} )    ) $$
-
-All joined test cases and individual test cases, discovered during the FMEA process,
-can now be considered 
-to be derived fault modes for the module.
-
-Thus: 
-
-$$ D^{1}_{1} = \FMEA  ({\bigcup}{M^{0}_{1}}) = \FMEA  {\cup} fm({F^{0}_{1}}) = \{ f1, f2, f3 \} $$
-
-
-$ D^{1}_{1} $ is now a set of fault~modes for the module. We can now 
-treat this in the same way we treated the part fault mode sets ($M^{0}_{n}$), 
-and take several derived ( $ D^{1}_{n} $) sets and combine them to form higher level modules.
-This is like considering the derived set to be a part, but a part at a higher level of abstraction.
-The process can then continue until up in abstraction levels until we have a complete hierarchical model.
-
-Note for the purpose of reducing clutter from this example we are ignoring the other test cases. A full analysis would include
-all test cases.
-
-\begin{figure}
-\centering
-\input{fmmdh.tex}
-\caption{FMMD example Hierarchy}
-\label{fig:sdfmea}
-\end{figure}
-
-\section {Building the Hierarchy - Higher levels \\ of Fault Mode Analysis}
-
-Figure \ref{fig:fmmdh} shows a hierarchy of failure mode descopmosition.
-
-It can be seen that the derived fault~mode sets are higher level abstractions of the fault behaviour of the modules.
-We can take this one stage further by combining the $D^{1}_{N}$ sets to form modules. These 
-$M^2_{N}$ fault mode collections can be used to create $D^3_{N}$ derived fault~modes sets and so on.
-At the top of the hierarchy, there will be one final (where $t$ is the 
-top level) set $D^{t}_{N}$ of abstract fault modes. The causes for these
-system level fault~modes will be traceable down to part fault modes. 
-
-
-A hierarchy of levels of faults becoming more abstract at each level should
-converge to a small sub-set of system level errors.
-This thinning out of the number of system level errors is borne out in practise ;
-real time control systems often have a small number of major reportable faults (typically $ < 50$), 
-even though they may have accompanying diagnostic data.
-
-
-
-\cite{sem}
-
-
-
-%\begin{figure}
-%\subfigure[Euler Diagram]{\epsfig{file=fmmd_hierarchy_cimg5040.eps,width=4.2cm}\label{fig:exa}}
-%\subfigure[Intersection A B ]{\epsfig{file=exampleareasubtraction2.eps,width=4.2cm}\label{fig:exb}}
-%\subfigure[area to subtract]{\epsfig{file=exampleareasubtraction3.eps,width=4.2cm}\label{fig:exc}}
-%\subfigure[A second graphic]{\epsfig{file=exampleareasubtraction3.eps,width=2cm}}
-%{\epsfig{file=fmmd_hierarchy_cimg5040.eps,width=12cm}
-%\label{fig:ex}
-%\caption{Simple Euler Diagram}
-%\end{figure}
-
-\cite{sem}
-
-
-
-\section {Modelling considerations}
-
-\subsection{FMEA diagramatic syntax and Well Formedness }
-
-{\em TO DO RULES AND MEANING}
-
-\subsection{The Parts List, Set or Bag}
-
-The Parts list is indexed by the set $L$ to ensure all parts are unique.
-Thus Set suffices and no bags required.
-
-
-\subsection{The Empty Set}
-Note that any power~set will always include the empty set. 
-Thus $\emptyset  \in  ({\cal P} \cup {\cal F}S)$ corresponds to the 
-state where there are no active errors in any of the parts
-in the system i.e. it is in correct operational state.
-
-$$ CorectOperationalState = \emptyset  \in  ({\cal P} \cup {\cal F}S) $$
-
-This simply says that where no part fault modes are active the system must be functioning correctly.
-If this is not the case, then all part~fault modes have not been considered. 
-\subsection{Complete Coverage of Fault Modes }
-
-To ensure that all fault modes are represented, each fault mode from
-the union all subsets of $S$ ($\cup {S}$) must be represented by a first 
-level module.
-
-$$ CompleteCoverage = \forall \; x  \exists  \; y \; ( \;  x  \; \in  \; (\bigcup  \; S) \; \Rightarrow \; x  \; \in  \; (\bigcup  \; D^{1}_{y}) ) $$
-
-That is to say that where a fault~mode exists in the system, it must be
- included in at least one module.
-Were it not to be we would have a fault~condition that was not modelled.
-
-The $CompleteCoverage$ check would not ensure that the modules had been 
-identified correctly, but would ensure that there were no missing 
-fault~modes, and acts as a type of syntax check.
-Note also, that this means the modules could share parts
- (although this would be unusual in practise).
-
-\subsection{ Part Fault modes Conjoint and Disjoint }
-
-Note that in the example (\ref{disjointnotcare}) the part fault modes are disjoint, the resistor cannot be both open and shorted
-at the same time. Not all part fault modes are disjoint, however. Consider a complicated part 
-like a micro~processor. This could easily have more than one fault~mode active.
-
-
-\section {notes}
-
-
-\subsection{ The Parts List }
-
-A parts list is typically a document with an enumerated list of parts.
-Each part includes a description, placement information, manufacturers part number and optional comments and vendor sourcing numbers.
-It is a document tied to a particular hardware revision of a product, and is used for the procurement of parts
-and as a cross check for inspectors from standards agencies.
-
-
-{\em NEED EXAMPLE PARTS LIST HERE....}
-
-
-\subsection{ Proof of number of part~failure \\ modes preserved in hierarchy build}
-
-Here need to prove that if we have an abstract fault, then as it goes higher in the tree, it can only collect MORE not less
-actual part~failure modes. This is obvious but needs a proof.
-Also this means may need dummy modules to not violate jumping up the tree structure
-
-%Complete coverage for all derived hierarch levels can be generalised thus:
-
-%$$ CompleteCoverage = \forall \; h \; \forall \; x  \exists  \; y \; ( \;  x  \; \in  \; \cup  \; {\cal F} \; D^{h} 
-% \; \Rightarrow \; x  \; \in  \; \cup  \; M^{h}_{y} ) $$
-
-
-\subsection{Cardinality Constrained Powerset }
-\label{ccp}
-
-A Cardinality Constrained powerset is one where sub-sets of a cardinality greater than a threshold
-are not included. This theshold is called the cardinality constraint.
-To indicate this the cardinality constraint $cc$, is subscripted to the powerset symbol thus $\mathcal{P}_{cc}$.
-Consider the set $S = \{a,b,c\}$. $\mathcal{P}_{2} S $ means all subsets of S where the cardinality of the subsets is 
-less than or equal to 2.
-
-$$ \mathcal{P} S = \{ 0, \{a,b,c\}, \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} $$
-
-$$ \mathcal{P}_{2} S = \{ \{a,b\},\{b,c\},\{c,a\},\{a\},\{b\},\{c\} \} $$
-
-$$ \mathcal{P}_{1} S = \{ \{a\},\{b\},\{c\} \} $$
-
-A $k$ combination is a subset with $k$ elements.  
-The number of $k$ combinations (each of size $k$) from a set $S$ 
-with $n$ elements (size $n$) is the binomial coefficient
-
-$$ C^n_k = {n \choose k} = \frac{n!}{k!(n-k)!}$$
-
-To find the number of elements in a cardinality constrained subset S with up to $cc$ elements
-in each comination sub-set,
-we need to sum the combinations, 
-%subtracting $cc$ from the final result 
-%(repeated empty set counts)
-from $1$ to $cc$ thus
-
-%
-% $$ {\sum}_{k = 1..cc} {\#S \choose k} = \frac{\#S!}{k!(\#S-k)!} $$
-%
-
-$$ \#\mathcal{P}_{cc} S = \sum^{k}_{1..cc} \frac{\#S!}{k!(\#S-k)!} $$
-
-\section{Future Ideas}
-
-\subsection{ Production Quality Control }
-
-Having a fault causation tree, could be used for PCB board fault finding (from the fault codes that are reported
-by the equipment). This could be used in conjunction with a database to provide 
-Production oriented FMEA\footnote{The term FMEA applied to production, is a statistical process of 
-determining the probability of the fault occurring and multiplying that by the costs incurred from the fault. 
-This quickly becomes a priority to-do list with the most costly faults at the top}
-
-
-\subsection { Test Rigs }
-
-Test rigs apply a rigourous checking process to safety critical equipment before 
-they can be sold, and this usually is a legal or contractural requirement, backed up by inspections
-and and an approval process.
-
-They are usually a clamp arrangement where the PCB under test is placed.
-Precesion and calibrated test signals are then applied to the board under test. For PCBs containing 
-microprocessor, custom test~rig software may be run on them to excersize
-active sections of the PCB (for instance to drive outputs, relays etc).
-
-The main purpose of a test rig is to prevent fault equipment from being shipped.
-However, often a test rig, will reveal an easy to fix fault on a board (such as a part not soldered down completely
-or missing parts). These boards can be mended and re-submitted to the test rig.
-
-It is often a problem, when a unit fails in a test rig, to quickly determine why it has failed.
-
-Having a fault causation tree, would be useful for identifying which parts may be missing, not soldered down
-or simply incorrect. The test rig armed with the fault analysis tree could point to parts or combinations of parts that could be checked
-to correct the product.
-
-\subsection {Modules - re-usability}
-
-In the example system in the introduction, the milli-volt amplifiers
-are the same circuit. The set of derived faults for the module may therefore
-simply be given a different index number and re-used.
-
-\subsection{ Multi Channel Safety Critical Systems }
-
-Where a system has several independent parrallel tasks, each one can be a separate hierarchy.
-
-% \small
-% \bibliography{vmgbibliography,mybib}
-% \normalsize
-
-
-% Typeset in \ \ {\huge \LaTeX} \ \ on \ \  \today 
-
-\begin{verbatim}
-CVS Revision Identity $Id: fmmdset.tex,v 1.7 2009/06/06 11:52:09 robin Exp $
-\end{verbatim}
-
-%\end{document}
-
-%\theend
-
-
-

fmmdset/paper.tex

@@ -4,7 +4,7 @@
 \usepackage{fancyhdr}
 \usepackage{tikz}
 \usepackage{amsfonts,amsmath}
-\input{style}
+\input{../style}
 
 \begin{document}
 \pagestyle{fancy}

introduction/introduction.tex

@@ -21,12 +21,21 @@ This changed the target for the study slightly to encompass these domains in a c
 I completed an MSc in Software engineering in 2004 at Brighton university while working for
 an Engineering firm as a software Engineer. 
 The firm make industrial burner controllers.
-iIndustrial Burners are potentially very dangerous industrail plant.
+Industrial Burners are potentially very dangerous industrial plant.
-They are subject to stringent safety regulations and any product controlling them
+They are generally left running unattended for long periods.
-must conform to specific `EN' standards. This involved not only writing software and designing hardware in compliance,
+They are subject to stringent safety regulations and 
-but also stages of formal certification testing. The certification testing had to be performed by
+must conform to specific `EN' standards. 
-`competent body' recognised under European law. A significant part
+
-of this process was `static testing'. This involved looking at the design of the products,
+One cannot merely comply with the standards.
+
+The product must be `certified' by an independent 
+and 
+`competent body' recognised under European law.
+The cerification involved stress testing with repeated operation cycles,
+within a range of temperatures. Electrical stress testing with high voltage interference, and
+power supply voltage surges and dips. Electro static discharge testing, and
+EMC (Electro Magnetic Compatibility). A significant part
+of this process however, was `static testing'. This involved looking at the design of the products,
 from the perspective of components failing, and the effect on safety this would have.
 Some of the static testing involved checking that the germane `EN' standards had
 been complied with. Failure Mode Effects Analysis (FMEA) was also applied. This involved
@@ -36,9 +45,19 @@ answer was required, or a counter proposal to change the design to cope with
 the comonent failure eventuality. FMEA was time consuming, and being directed by
 experts undoubtly ironed out many potential safety faults before the product saw
 light of day. However it was quickly apparent that only a small proportion
-of copmponent~failure modes was considered. Also  there was no formaliswm.
+of copmponent~failure modes was considered. Also  there was no formalism.
 The component~failure~modes investigated were not analysed within
 any rigourous framework.
+
+\subsection{ Blanket Risk Reduction Approach }
+
+The suite of tests applied for a certified product amount to a `blanket'  approach.
+That is to say that by applying Electrical, repeated operations, and environmental
+stress testing it is hoped that the majority of latent faults are discovered.
+The FMEA, or static sections, only look at the most obviously safety critical
+aspects, and a small minority of the total component base for a product.
+
+Systememic faults, or mistakes will often by-pass this testing.
  
 \subsection{Possibility of applying mathematical techniques to FMEA}
 
@@ -66,23 +85,25 @@ obviously impractical.
 \subsection{General description of a Safety Critical System}
 
 A safety critical system is one in which lives may depend upon it or 
-it has the potential to become dangerous.
+it has the potential to become dangerous\cite{sccs}.
-(/usr/share/texmf-texlive/tex/latex/amsmath/amstext.sty)
+%(/usr/share/texmf-texlive/tex/latex/amsmath/amstext.sty)
 
 An industrial burner is typical of plant that is potentially dangerous.
 An incorrect air/fuel mixture can be explosive.
 Medical electronics for automatically dispensing drugs or maintaining
 life support are examples of systems that lives depend upon.
 
-\subsection{Two approaches : Probablistic, and Compnent fault tolerant}
+\subsection{Two approaches : Probablistic, and  Deterministic}
 
 There are two main philosophies applied to safety critical systems certification.
-\paragraph{Statistical safety Measures}
+\paragraph{Probablistic safety Measures}
-One is a general number of acceptable failure per hour of operation.
+One is a general number of acceptable failures per hour\footnote{The common metric is Failure in Time (FIT) values - failures per ${10}^{9}$ 
+hours of operation} of operation or
+a given statistical failure on demand.
 This is the probablistic approach and is embodied in the european standard 
 EN61508 \cite{EN61508}.
 
-\paragraph{Prescriptive safety Measures}
+\paragraph{Deterministic safety Measures}
 The second philosophy, applied to application specific standards, is to investigate
 components ior sub-systems in the critical safety path and to look at component failure modes
 and ensure that they cannot cause dangerous faults.
@@ -114,67 +135,36 @@ reference chapter dealing speciifically with this but given a quick overview.
 \subsubsection{Overview of current testing and certification}
 ref chapter speciifically on this but give an overview now
 
-\section{Background to the Industrial Burner Safety Analysis Problem}
-
-An industrial burner is a good example of a safety critical system.
-It has the potential for devistating explosions due to boiler overpressure, or
-ignition of an explosive mixture, and, because of the large amounts of fuel used,
-is also a fire hazard. Also Industrial boilers are often left running unattended 
-for long periods of time (typically days).  
-
-To add to these problems
-Operators are often under pressure to keep them running. An boiler supplying
-heat to a large greenhouse complex could ruin crops
-should it go off-line. Similarly a production line relying on heat or steam
-can be very expensive in production down-time should it fail.
-This places extra responsibility on the burner controller.
-
-
-These are common place and account for a very large proportion of the enery usage
-in the world today (find and ref stats)
-Industrial burners are common enough to have different specific standards
-written for the fuel types they use \ref{EN298} \ref{EN230} \ref{EN12067}.
-
 A modern industrial burner has mechanical, electronic and software
 elements, that are all safety critical. That is to say
 unhandled failures could create dangerous faults.
 
-To add to these problems
+%To add to these problems
-Operators are often under pressure to keep them running. An boiler supplying
+%Operators are often under pressure to keep them running. An boiler supplying
-heat to a large greenhouse complex could ruin crops
+%heat to a large greenhouse complex could ruin crops
-should it go off-line. Similarly a production line relying on heat or steam
+%should it go off-line. Similarly a production line relying on heat or steam
-can be very expensive in production down-time should it fail.
+%can be very expensive in production down-time should it fail.
-This places extra responsibility on the burner controller.
+%This places extra responsibility on the burner controller.
-
+%
-
+%
-These are common place and account for a very large proportion of the enery usage
-in the world today (find and ref stats)
-Industrial burners are common enough to have different specific standards
-written for the fuel types they usei \ref{EN298} \ref{EN230} \ref{EN12067}.
-
-A modern industrial burner has mechanical, electronic and software
-elements, that are all safety critical. That is to say
-unhandled failures could create dangerous faults.
-
-A more detailed description of industrial burner controllers
-is dealt with in chapter~\ref{burnercontroller}.
-
-\subsection{Mechanical components}
-describe the mechanical parts - gas valves damper s
-electronic and software
-give a diagram of how it all fits A
-together with a 
-\subsection{electronic Components}
-
-\subsection{Software/Firmware Components}
-
-
-\subsection{A high level Fault Hierarchy for an Industrial Burner}
-
-This section shows the component level, leading up higher and higher in the abstraction level
-to the software levels and finally a top level abstract level. If the system has been
-designed correctly no `undetected faults' should be present here.
 
+% This needs to become a chapter
+%\subsection{Mechanical components}
+%describe the mechanical parts - gas valves damper s
+%electronic and software
+%give a diagram of how it all fits A
+%together with a 
+%\subsection{electronic Components}
+%
+%\subsection{Software/Firmware Components}
+%
+%
+%\subsection{A high level Fault Hierarchy for an Industrial Burner}
+%
+%This section shows the component level, leading up higher and higher in the abstraction level
+%to the software levels and finally a top level abstract level. If the system has been
+%designed correctly no `undetected faults' should be present here.
+%
 \section{An Outline of the FMMD Technique}
 
 The methodology takes a bottom up approach to
@@ -182,8 +172,10 @@ the design of an integrated system.
 Each component is assigned a well defined set of failure modes.
 The components are formed into modules, or functional groups.
 These functional groups are analysed with respect to the failure modes of the 
-components. The `functional group' or module will have a set of derived
+components. The `functional group' or module will, after analysis, have a set of derived
-failure modes. The number of derived failure modes will be 
+failure modes. Thus we can now treat our `functional group' as a component in its own right,
+ with its own set of failure~modes.
+The number of derived failure modes will be 
 less than or equal to the sum of the failure modes of all its components.
 A `derived' set of failure modes, is at a higher abstraction level.
 derived modules may now be used as building blocks, to model the system at
@@ -197,6 +189,7 @@ A formal description of this process is dealt with in Chapter \ref{fmmddefinitio
 %on simple control systems for maintaining temperature
 %and for industrial burners. It is hoped that a general mathematical 
 %framework is created that can be applied to other fields of safety critical engineering.
+\subsection{Automated Systems and Safety}
 
 Automated systems, as opposed to manual ones are now the norm 
 in the home and in industry.
@@ -221,6 +214,13 @@ As the automation takes over more and more functions from the human operator it
 A classic example of an automated system failing, is the therac-25.
 This was an X-ray dosage machine, that, due to software errors
 caused the deaths of several patients and injured more during the 1980's.
+The Therac-25 was a designed from a manual system, which had checks and interlocks,
+and was computerised. Software bugs were the primnary causes of the radiation
+overdoses. 
+\cite{therac}
+Any new safety critical analysis methodology should
+be able to model software, electrical and hardware faults using 
+a common notation.
 
 
 % http://en.wikipedia.org/wiki/Autopilot
@@ -238,30 +238,6 @@ corrections cannot be enough.
 It could also develop an internal fault, and must be able to cope with this.
 
 
-Systems such as industrial burners have been partially automated for some time.
-A mechanical cam arrangement controls the flow of air and fuel for the range of
-firing rate (output of the boiler).
-
-These mechanical systems could suffer failures (such as a mechanical linkage beoming
-detached) and could then operate in a potentially dangerous state.
-
-More modern burner controllers use a safety critical computer controlling
-motors to operate the fuel and air mixture and to control the safety 
-valves.
-
-In working in the industrial burner industry and submitting product for
-North American and European safety approval, it was apparent that
-formal techniques could be applied to aspects of the ciruit design.
-Some safety critical circuitry would be subjected to thought experiments, where 
-the actions of one or more components failing would be examined.
-As a simple example a milli-volt input could become disconnected.
-A milli-volt input is typically amplified so that its range matches that
-of the A->D converter that you are reading. were this signal source to become disconnected
-the systems would see a floating, amplified signal.
-A high impedance safety resistor can be added to the circuit,
-to pull the signal high (or out of nornal range) upon disconnection.
-The system then knows that a fault has occurred and will not use  
-that sensor reading (see \ref{fig:millivolt}). 
 
 
 
@@ -389,6 +365,12 @@ The problem lay in a seal that had an operating temperature range.
 On the day of the launch the temperature of this seal was out of range.
 A bottom up safety approach would have revealed this as a fault.
 
+The FTA in use by NASA and the US Nuclear regulatory commisssion 
+allows for enviromental considerations such as temperature\cite{NASA}\cite{NUK}.
+But because of the top down nature of the FTA technique, the safety designer must be aware of
+the environemtnal constraints of all component parts in order to use this correctly.
+This element of FTA is discussed in \ref{surveysc}
+
 \section{Problems with Natural Language}
 
 Written natural language desciptions can not only be ambiguous or easy to misinterpret, it
@@ -427,6 +409,8 @@ temperature being the most typical. Very often what happens to the system outsid
 \section{Project Goals}
 
 \begin{itemize}
+\item To create a Bottom up FMEA technique that is modular and permits a linked hierarchy to be 
+build representing the fault behaviour of a system.
 \item To create a user friendly formal common visual notation to represent fault modes
 in Software, Electronic and Mechanical sub-systems.
 \item To formally define this visual language.

introduction/introduction.tex~

@@ -1,399 +0,0 @@
-
-
-\section{Introduction}
-
-$$ \int_{0\-}^{\infty}  f(t).e^{-s.t}.dt  \; | \; s \in C$$
-
-This thesis describes the application of, mathematical (formal) techniques to
-the design of safety critical systems. 
-The initial motivation for this study was to create a system
-applicable to industrial burner controllers. 
-The methodology developed was designed to cope with
-both the specific `simultaneous failures'\cite{EN298},\cite{EN230},\cite{EN12067}
-and the probability to dangerous fault approach\cite{EN61508}.
-
-The visual notation developed was initially designed  for electronic fault modelling.
-However, it could be appleid to mechanical and software domains as well.
-Due to this a common notation/diagram style
-can be used to model any integrated safety relevant system.
-
-\section{Safety Critical Systems}
-
-\subsection{General description of a Safety Critical System}
-
-A safety critical system is one in which lives may depend upon it or 
-it has the potential to become dangerous.
-(/usr/share/texmf-texlive/tex/latex/amsmath/amstext.sty
-
-An industrial burner is typical of plant that is potentially dangerous.
-An incorrect air/fuel mixture can be explosive.
-Medical electronics for automatically dispensing drugs or maintaining
-life support are examples of systems that lives depend upon.
-
-\subsection{Two approaches : Probablistic, and Compnent fault tolerant}
-
-There are two main philosophies applied to safety critical systems.
-One is a general number of acceptable failure per hour of operation.
-This is the probablistic approach and is embodied in the european standard 
-EN61508 \cite{EN61508}.
-
-The second philosophy, applied to application specific standards, is to investigate
-components ior sub-systems in the critical safety path and to look at component failure modes
-and ensure that they cannot cause dangerous faults.
-With the application specific standards detail
-specific to the process are 
-This philosophy is first mentioned in aircraft safety operation reseach WWII
-studies. Here potential single faults (usually mechanical) are traced to
-catastrophic failures 
-
-% \cite{boffin}.
-
-
-
-% 
-% \begin{example}
-% \label{exa1}
-% Test example
-% \end{example}
-% 
-% And that is example~\ref{exa1}
-
-\subsection{Overview of regulation of safety Critical systems}
-
-reference chapter dealing speciifically with this but given a quick overview.
-\subsubsection{Overview system analysis philosophies }
-- General safety standards
-- specific safety standards
-
-\subsubsection{Overview of current testing and certification}
-ref chapter speciiffically on this but give an overview now
-
-\section{Background to the Industrial Burner Safety Analysis Problem}
-
-An industrial burner is a good example of a safety critical system.
-It has the potential for devatating explosions due to boiler overpressure, or
-ignition of an explosive mixture, and, because of the large amounts of fuel used,
- is a potential fire hazard. They are often left running unattended 24/7.  
-
-To add to these problems
-Operators are often under pressure to keep them running. An boiler supplying
-heat to a large greenhouse complex could ruin crops
-should it go off-line. Similarly a production line relying on heat or steam
-can be very expensive in production down-time should it fail.
-This places extra responsibility on the burner controller.
-
-
-These are common place and account for a very large proportion of the enery usage
-in the world today (find and ref stats)
-Industrial burners are common enough to have different specific standards
-written for the fuel types they usei \ref{EN298} \ref{EN230} \ref{EN12067}.
-
-A modern industrial burner has mechanical, electronic and software
-elements, that are all safety critical. That is to say
-unhandled failures could create dangerous faults.
-
-To add to these problems
-Operators are often under pressure to keep them running. An boiler supplying
-heat to a large greenhouse complex could ruin crops
-should it go off-line. Similarly a production line relying on heat or steam
-can be very expensive in production down-time should it fail.
-This places extra responsibility on the burner controller.
-
-
-These are common place and account for a very large proportion of the enery usage
-in the world today (find and ref stats)
-Industrial burners are common enough to have different specific standards
-written for the fuel types they usei \ref{EN298} \ref{EN230} \ref{EN12067}.
-
-A modern industrial burner has mechanical, electronic and software
-elements, that are all safety critical. That is to say
-unhandled failures could create dangerous faults.
-
-A more detailed description of industrial burner controllers
-is dealt with in chapter~\ref{burnercontroller}.
-
-\subsection{Mechanical components}
-describe the mechanical parts - gas valves damper s
-electronic and software
-give a diagram of how it all fits A
-together with a 
-\subsection{electronic Components}
-
-\subsection{Software/Firmware Components}
-
-
-\subsection{A high level Fault Hierarchy for an Industrial Burner}
-
-This section shows the component level, leading up higher and higher in the abstraction level
-to the software levels and finally a top level abstract level. If the system has been
-designed correctly no `undetected faults' should be present here.
-
-\section{An Outline of the FMMD Technique}
-
-The methodology takes a bottom up approach to
-the design of an integrated system.
-Each component is assigned a well defined set of failure modes.
-The components are formed into modules, or functional groups.
-These functional groups are analysed with respect to the failure modes of the 
-components. The `functional group' or module will have a set of derived
-failure modes. The number of derived failure modes will be 
-less than or equal to the sum of the failure modes of all its components.
-A `derived' set of failure modes, is at a higher abstraction level.
-derived modules may now be used as building blocks, to model the system at
-ever higher levels of abstraction until the top level is reached.
-
-Any unhandled faults will appear at this top level and will be `un-resolved'.
-A formal description of this process is dealt with in Chapter \ref{fmmddefinition}.
-
- 
-%This principally focuses 
-%on simple control systems for maintaining temperature
-%and for industrial burners. It is hoped that a general mathematical 
-%framework is created that can be applied to other fields of safety critical engineering.
-
-Automated systems, as opposed to manual ones are now the norm 
-in the home and in industry.
-
-Automated systems have long been recognised as being more effecient and 
-more accurate than a human opperator, and the reason for automating a process
-can now be more likely to be cost savings due to better effeciency
-thatn a human operator \ref{burnereffency}.
-
-For instance
-early automated systems were mechanical, with cams and levers simulating
-fuel air mixture  profile curves over the firing range.
-Because fuels vary slightly in calorific value, and air density changes with the weather, no optimal tuning can be optional.
-In fact for asethtic reasons (not wanting smoke to appear at the flue)
-the tuning was often air rich, causing air to be heated and 
-uneccessarily passed through the burner, leading to direct loss of energy.
-An automated system analysing the combustions gasses and automatically
-adjusting the fuel air mix can get the effeciencies very close to theoretical levels.
- 
-
-As the automation takes over more and more functions from the human operator it also takes on more responsibility.
-A classic example of an automated system failing, is the therac-25.
-This was an X-ray dosage machine, that, due to software errors
-caused the deaths of several patients and injured more during the 1980's.
-
-
-% http://en.wikipedia.org/wiki/Autopilot
-To take an example of an Autopilot, simple early autopilots, were  (i.e. they
-prevented the aircraft staying from a compass bearing and kept it flying striaght and level). 
-Were they to fail the pilot would notice quite quickly
-and resume manual control of the bearing.
-
-Modern autopilots control all aspects of flight including the engines, and take off and landing phases.
-The automated system does not have the 
-common sense of a human pilot either, if fed the wrong sensory information
-it could make horrendous mistakes. This means that simply reading sensors and applying control
-corrections cannot be enough.
- Checking for error conditions must also be incorporated. 
-It could also develop an internal fault, and must be able to cope with this.
-
-
-Systems such as industrial burners have been partially automated for some time.
-A mechanical cam arrangement controls the flow of air and fuel for the range of
-firing rate (output of the boiler).
-
-These mechanical systems could suffer failures (such as a mechanical linkage beoming
-detached) and could then operate in a potentially dangerous state.
-
-More modern burner controllers use a safety critical computer controlling
-motors to operate the fuel and air mixture and to control the safety 
-valves.
-
-In working in the industrial burner industry and submitting product for
-North American and European safety approval, it was apparent that
-formal techniques could be applied to aspects of the ciruit design.
-Some safety critical circuitry would be subjected to thought experiments, where 
-the actions of one or more components failing would be examined.
-As a simple example a milli-volt input could become disconnected.
-A milli-volt input is typically amplified so that its range matches that
-of the A->D converter that you are reading. were this signal source to become disconnected
-the systems would see a floating, amplified signal.
-A high impedance safety resistor can be added to the circuit,
-to pull the signal high (or out of nornal range) upon disconnection.
-The system then knows that a fault has occurred and will not use  
-that sensor reading (see \ref{fig:millivolt}). 
-
-
-
-\begin{figure}
-\vskip 7cm
-\special{psfile=introduction/millivoltsensor.ps hoffset=0 voffset=0 hscale=35 vscale=35 }\caption[Milli-Volt Sensor with safety resistor]{
-Milli-Volt Sensor with safety resistor
-\label{fig:millivolt}}
-\end{figure}
-
-For exmaple, if the sensor supplies a range of 0 to 40mV, and RG1 and RG2 are such that the op-amp supplies a gain of 100
-any signal between 0 and 4 volts on the ADC will be considered in range. Should the sensor become disconnected the 
-opamp will supply its maximum voltage, telling the system the sensor reading is invalid. 
-
-This introduces a level of self checking into the system.
-We need to be able to react to not only errors in the process its self,
-but also validate and look for internal errors in the control system.
-
-This leads on to an important concept of three main states of a safety critical system.
-
-
-% To improve productivity, performance, and cost-effectiveness, we are developing more and more safety-critical systems that are under computer control. And centralized computer control is enabling many safety-critical systems (e.g., chemical and pesticide factories) to grow in size, complexity, and potential for catastrophic failure.
-
-% We use software to control our factories and refineries as well as power generation and distribution. We also use software in our transportation systems including airplanes, trains, ships, subways, and even in our family automobiles. Software is also a major component of many medical systems in which safe functioning is critical to the safety of patients and operators alike. Even when the software does not directly control safety-critical hardware, software can provide operators and users with safety-critical data with which they must make safety-critical decisions (e.g., air traffic control or medical information such as blood bank records, organ donor information, and patient medical records). As we have come to rely more on software-intensive systems, we have come to rely more on those systems functioning safely.
-
-% Many accidents are caused by problems with system and software requirements, and “empirical evidence seems to validate the commonly stated hypothesis that the majority of safety problems arise from software requirements and not coding errors” [Leveson1995]. Major accidents often result from rare hazards, whereby a hazard is a combination of conditions that increases the likelihood of accidents causing harm to valuable assets (e.g., people, property, and/or the environment). Most requirements specifications are incomplete in that they do not specify requirements to eliminate these rare hazards or mitigate their consequences. Requirements specifications are also typically incomplete in that they do not specify what needs to happen in exceptional “rainy day” situations or as a response to each possible event in each possible system state although accidents are often caused by the incorrect handling of rare combinations of events and states that were considered to be either impossible or too unlikely to worry about, and were therefore never specified. Even when requirements have been specified for such rare combinations of events and conditions, they may well be ambiguous (an unfortunately common characteristic of requirements in practice), partially incomplete (missing assumptions obvious only to subject matter experts), or incorrect, or inconsistently implemented. Thus, the associated hazards are not eliminated or the resulting harm is not properly mitigated when the associated accidents occur. Ultimately, safety related requirements are important requirements that need to be better engineered.
-
-% The goal of this column is to define safety requirements and clarify how they differ from safety constraints and from functional, data, and interface requirements that happen to be safety critical. I start by defining safety in terms of a powerful quality model and show how quality requirements (including safety requirements) can be specified in terms of the components of this quality model. I will then show how to use the quality model to specify safety requirements. Then, I will define and discuss safety constraints and safety-critical requirements. Finally, I will pose a set of questions regarding the engineering of these three kinds of safety-related requirements for future research and experience to answer.
-
-Safety critical systems in the context of this study, means that a safety critical system may be said to be in three distinct 
-overall states.
-Operating normally, operating in a lockout mode with a detected fault, and operating
-dangerously with an undetected fault.
-
-The main role of the system designers of safety critical equipment should be to eliminate the possibility of this last condition.
-
-% Software plays a critical role in almost every aspect facet of our daily lives - from , to driving our cars, to working in our offices. 
-% Some of these systems are safety-critical. 
-% Failure of software could cause catastrophic consequences for human life. 
-% Imagine the antilock brake system (ABS) in your car. 
-% A software failure here could render the ABS inoperable at a time when you need it most. 
-% For these types of safety-critical systems, having guidelines that define processes and 
-% objectives for the creation of software that focus on software quality, or the ability 
-% to use software that has been developed under this scrutiny, has tremendous value 
-% for developers of safety-critical systems.
-
-\section{Motivation for developing a formal methodology}
-
-A feature of many safety critical systems specifications,
-including EN298, EN230 \cite{EN298} \cite{EN230} 
-is to demand, 
-at the very least that single failures of hardware
- or software cannot 
-create an unsafe condition in operational plant. Further to this
-a second fault introduced, must not cause an unsafe state, due
-to the combation of both faults.
-\vskip 0.3cm
-This sounds like an entirely reasonable requirement. But to rigorously
-check the effect a particular component fault has on the system,
-we could check its effect on all other components.
-Should a diode in the powersupply fail in a  particular way, by perhaps
-introducing a ripple voltage, we should have to look at all components
-in the system to see how they will be affected. 
-
-%However consider a typical
-%small  system with perhaps 1000 components each 
-%with an average of say 5 failure modes.
-Thus, to ensure complete coverage, each of the effects of
- the failure modes must be applied
- to all the other components. 
-Each component must be checked against the
- failure modes of all other components in the system.
-Mathematically with components as 'c' and failure modes as 'Fm'.
-
-
-\equation
-\label{crossprodsingle}
-checks = \{ \; (Fm,c) \; \mid \; \stackrel{\wedge}{c} \; \neq \; c \}
-\endequation
-
-Where demands 
-are made for resilience against two
-simultaneous failures this effectively squares the number of checks to make. 
-\equation
-\label{crossproddouble}
-doublechecks = \{ \; (Fm_{1},Fm_{2},c) \; \mid \\ \; c_{1} \; \neq \; c_{2} \; \wedge \; Fm_{1} \neq Fm_{2} \; \}
-\endequation
-
-
-If we consider a system which has a total of
-$N$  failure modes (see equation \ref{crossprodsingle}) this would mean checking a maximum of 
-\equation
- NumberOfChecks = \frac{N ( N-1 )}{2} 
-\endequation
-
-for individual component failures and their effects on other components when they fail. 
-For a very small system with say 1000 failure modes this would demand a potential of 500,000
- checks for any automated checking process. 
-\vskip 0.3cm
- European legislation\cite{EN298} directs that a system must be able to react to two component failures 
-and not go into a dangerous state.
-\vskip 0.3cm
-This raises an interesting problem from the point of view of formal modelling. Here we have a binary cross product of all components
-(see equation \ref{crossproddouble}).
-This increases the number of checks greatly. Given that the binary cross product is $ (N^{2} - N)/2 $ and has to be checked against the remaining
-$(N-2)$ components.
-\equation
-\label{numberofchecks}
- NumberOfchecks = \frac{(N^{2} - N) ( N - 2)}{2}
-\endequation
-
-Thus for a 1000 failure mode system, roughly a half billion possible checks would be required for the double simultaneous failure scenario. This astonomical number of potential combinations, has made formal analysis of this
-type of system, up until now, impractical. Fault simulators %\cite{sim} 
-are commonly used for the gas certification process. Thus to
-manually check this number of combinations of faults is in practise impossible.
-A technique of modularising, or breaking down the problem is clearly necessary.
-
-\section{Challenger Disaster}
-
-One question that anyone developing a safety critical analysis design tool
-could do well to answer, is how the methodology would cope with known previous disasters.
-The Challenger disaster is a good example, and was well documented and invistigated.
-
-The problem lay in a seal that had an operating temperature range.
-On the day of the launch the temperature of this seal was out of range.
-A bottom up safety approach would have revealed this as a fault.
-
-\section{Problems with Natural Language}
-
-Written natural language desciptions can not only be ambiguous or easy to misinterpret, it
-is also not possible to apply mathematical checking to them.
-
-A mathematical model on the other hand can be checked for 
-obvious faults, such as tautologies and contradictions, but also 
-intermediate results can be extracted and these checked.
-
-Mathematical modeling of systems is not new, the Z language
-has been used to model systems\cite{ince}. However this is not widely
-understood or studied even in engineering and scientific circles.
-Graphical techniques for representing the mathematics for
-specifying systems, developed at Brighton and Kent university
-have been used and extended by this author to create a methodology
-for modelling complex safety critical systems, using diagrams.
-
-This project uses a modified form of euler diagram used to represent propositional logic.
-%The propositional logic is used to analyse system components.
-
-
-\section{Ideal System Designers world}
-
-Imagaine a world where, when ordering a component, or even a complex module
-like a a failsafe sensor/scientific instrunment, one page of the datasheet
-is the failure modes of the system. All possible ways in which the component can fail
-and how it will react when it does. 
-
-\subsection{Environmentally determined failures}
-
-Some systems and components are guaranteed to work within certain environmental constraints,
-temperature being the most typical. Very often what happens to the system outside that range is not defined.
-Where this is the case, these are undetectable errors.
-
-
-\section{Project Goals}
-
-\begin{itemize}
-\item To create a user friendly formal common visual notation to represent fault modes
-in Software, Electronic and Mechanical sub-systems.
-\item To formally define this visual language.
-\item To prove that tehe modules may be combined into hierarchies that
-truly represent the fault handling from component level to the
-highest abstract system 'top level'.
-\item To reduce to complexity of fault mode checking, by modularising and 
-building complexity reducing hierarchies.
-\item To formally define the hierarchies and procedure for bulding them.
-\item To produce a software tool to aid in the drawing of diagrams and
-ensuring that all fault modes are addressed.
-\item To allow the possiblility of MTTF calculation for statistical
-reliability/safety calculations.
-\end{itemize}
-
-
-% fuckin\end{document}

logic_diagram/logic_diagram.tex

@@ -12,7 +12,7 @@ that control the flow of a computer program. This type of diagram can therefore
 integrate logical models from mechanical, electronic and software domains.
 Nearly all modern safety critical systems involve these three disiplines.
 %
-It is intended to be used for analysis of automated safety critical systen
+It is intended to be used for analysis of automated safety critical systems.
 Many types of safety critical systems now legally 
 require fault mode effects analysis\cite{FMEA},
 but few formal systems exist and wide-spread take-up is
@@ -231,12 +231,11 @@ In English:
 Test points on the concrete diagram pair-wise connected by a `joining line'
 
 
-A collection of test points connected by joining lines, is an Fuctionally Merged Group, $FMG$
+A collection of test points connected by joining lines, is an Functionally Merged Group, $FMG$
 or `test point disjunction'.
 An $FMG$ has members which are test points.
 
-{may be merged
+{
-and create a  
 \definition{ 
 %A spider is a set of test points where, 
 %a test point is a member of a spider where it can trace a path connected by joining lines
@@ -256,6 +255,7 @@ A singleton test point can be considered a sequence of one test point and is the
 
 
 % \subsection{Abstract Description of PLD}
+%and create a  
 % 
 % An Abstract PLD {\em Propositional logic diagram} consists of contours $C$ defining zones $Z$,  test points $T$ (which
 % are defined by the zone they inhabit) and pair wise connections $W$, which connect test points.
@@ -284,11 +284,10 @@ A singleton test point can be considered a sequence of one test point and is the
 \item A $FMG$ represents the disjunction of all test points that are members of it.
 \end{itemize}
 
-To obtain the set of propositions from a PLD, each $FMG$ must be processed. For each test case
+To obtain the set of propositions from a PLD, each $FMG$ must be traversed
+along each joining line. For each test case
 in the $FMG$ a new section of the equation is disjuctively appended to it.
 
-
-
 Let conjunctive logic equation associated with a test point
 be determined from the contours that enclose it.
 i.e. the contours $\mathcal{X}$ from the zone it inhabits.
@@ -397,6 +396,7 @@ In the diagram \ref{fig:ld_and} the area of intersection between the contours $a
 represents the conjunction of those conditions. The point $P$ represents the logic equation
 $$ P = (a \wedge b) $$
 There are no disjunctive joining lines and so this diagram represents one equation only, $ P = (a \wedge b) $.
+Note that $P$ is considered to be an $FMG$ with one element, $ (a \wedge b) $
 
 \paragraph{How this would be interpreted in failure analysis} 
 In failure analysis, this could be considered to be a sub-system with two failure states $a$ and $b$.
@@ -430,23 +430,43 @@ $$ P = (a) $$
 $$ Q = (b) $$  
 
 The two test cases are joined by a the line named $R$.
-we thus apply disjunction to the test cases.
+we thus apply exclusive disjunction to the test cases.
-$$ R = P \vee Q $$ 
+$$ R = P \oplus Q $$ 
 substituting the test cases for their Boolean logic equations gives
-$$ R = ((a) \vee (b)) $$.
+\begin{equation}
+\label{eqn:l_or}
+ R = ((a) \oplus (b)) 
+\end{equation}
+
+\paragraph{Failure Analysis Interpretation}
+Equation \ref{eqn:l_or} would be interpretted to mean that
+either failure mode a or b occurring, would have the same failure symptom for the circuit/sub-system
+under analysis.
 
 
 
 \clearpage
 \subsection {Labels and useage}
 
-In diagram \ref{fig:ld_meq} Z and W were labeled but were not necessary for the final expression
+%In diagram \ref{fig:ld_meq} Z and W were labeled but were not necessary for the final expression
-of $ R = b \vee c $. The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning.
+%of $ R = b \vee c $. The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning.
-Test cases joined by disjunction, all become represented in one, resultant equation.
+%Test cases joined by disjunction, all become represented in one, resultant equation.
-Therefore only test cases not linked by any disjunctive joining lines need be named.
+%Therefore only test cases not linked by any disjunctive joining lines need be named.
+%
+%The diagram   \ref{fig:ld_meq} can therefore be represented as in diagram \ref{fig:ld_meq2}, with 
+%two unnamed test cases.
+
+Diagram \ref{fig:ld_meq} 
+shows three Functionally Merged groups, Q, R and P.
+
+Z and W were labeled but this was not necessary for determination of the final expression
+of $ R = b \oplus c $. 
+%The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning.
+%Test cases joined by disjunction, all become represented in one, resultant equation.
+%Therefore only test cases not linked by any disjunctive joining lines need be named.
+%The diagram   \ref{fig:ld_meq} can therefore be represented as in diagram \ref{fig:ld_meq2}, with 
+%two unnamed test cases.
 
-The diagram   \ref{fig:ld_meq} can therefore be represented as in diagram \ref{fig:ld_meq2}, with 
-two unnamed test cases.
 
 \begin{figure}[h]
  \centering
@@ -457,7 +477,7 @@ two unnamed test cases.
 
 % 
 % \begin{figure}[h+]
-% %\centering
+% %\centeringeragraph
 % %\input{millivolt_sensor.tex}
 % \begin{center}
 %  \includegraphics[width=200pt,bb=0pt 0pt 600pt 600pt]{logic_diagram/ldmeq2.jpg}
@@ -470,12 +490,20 @@ two unnamed test cases.
 
 
 \paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, this could be considered to be a sub-system with two failure states $a$ and $b$.
+In failure analysis, this could be considered to be a sub-system with three failure states $a$,$b$ and $c$.
-The proposition $P$ considers the scenario where either failure~mode is active.
+It has three FMG's Q,R and P. Thus there are three ways in which this sub-system can fail.
-Additionally it says that either failure mode $a$ or $b$  being active
-will have a resultant effect $R$ on the sub-system. Note that the effect 
-of $a$ and $b$ both being active is not defined on this diagram.
 
+% \tiny
+\vspace{0.3cm}
+ \begin{tabular}{||c|c|l||} \hline \hline
+   {\em $FMG$ }  & {\em Failure Mode equation } &  {\em comments  }      \\ \hline
+       Q         &  $(a)$           &    T     \\ \hline
+       P         &  $(b \oplus c)$    &    T     \\ \hline
+       R         &  $(b \wedge c)$  &    F     \\ \hline
+      % T         &  T  &    T     \\ \hline \hline
+ \end{tabular}
+\vspace{0.3cm}
+% \normalsize
 
 \clearpage
 
@@ -488,15 +516,22 @@ Repeated contours are allowed in PLD diagrams.
 Logical contradictions or tautologies can be detected automatically by
 a software tool which assists in drawing these diagrams.
 
-
-
 \begin{figure}[h]
  \centering
- \includegraphics[bb=0 0 485 206]{logic_diagram/repeated.jpg}
+ \includegraphics[width=400pt,bb=0 0 560 195,keepaspectratio=true]{./logic_diagram/repeated.jpg}
- % repeated.jpg: 539x229 pixel, 80dpi, 17.11x7.27 cm, bb=0 0 485 206
+ % repeated.jpg: 560x195 pixel, 72dpi, 19.76x6.88 cm, bb=0 0 560 195
- \label{fig:repeat}
+ \caption{Contours can appear more than once in a PLD}
+ \label{fig:repeated}
 \end{figure}
 
+% 
+% \begin{figure}[h]
+%  \centering
+%  \includegraphics[bb=0 0 485 206]{logic_diagram/repeated.jpg}
+%  % repeated.jpg: 539x229 pixel, 80dpi, 17.11x7.27 cm, bb=0 0 485 206
+%  \label{fig:repeat}
+% \end{figure}
+
 %  \begin{figure}[h]
 %  \centering
 %  \includegraphics[bb=0 0 486 206]{./repeated.jpg}
@@ -513,19 +548,22 @@ $$ Q = (a) \wedge (c) $$
 
 The two test cases are joined by a the line named $R1$.
 we thus apply disjunction to the test cases.
-$$ R1 = P \vee Q $$ 
+$$ R1 = P \oplus Q $$ 
-$$ R1 = b \vee ( a \wedge c ) $$.
+$$ R1 = b \oplus ( a \wedge c ) $$.
 
 $R2$ joins two other test cases
-$$R2 = a \vee c $$
+$$R2 = a \oplus c $$
 
 The test~case residing in the intersection of countours $B$ and $A$
 represents the logic equation $R3 = a \wedge b$.
 
 \paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$
+In failure analysis, $R2$ is the symptom of either failure~mode $a$ or $c$
-occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring.
+occurring. $R1$ is the symptom of $b$ exclusive-or $a \wedge c$ occurring.
-There is an additional symptom, that of the test case in $A \wedge B$.
+The third FMG or  symptom shown is test case in $a \wedge b$.
+This diagram is incomplete, there is no test case for the fault mode $a$.
+The `available region' $a \backslash b$ has no test case, and this would be considered a `syntax error'
+by the FMMD software tool.
 
 
 
@@ -537,7 +575,7 @@ There is an additional symptom, that of the test case in $A \wedge B$.
 
 Very often a failure mode can only occurr
 given a searate environmental condition.
-In Fault Tree Analysis (FTA) this is represented by an inhibit gate.
+In Fault Tree Analysis (FTA) this is represented by an inhibit gate.\cite{NASA},\cite{NUK}
  
   \begin{figure}[h]
  \centering
@@ -559,7 +597,7 @@ that for failure~mode $C$ to occur failure mode $A$
 must have occurred.
 A well known example of this is the space shuttle `O' ring failure that
 caused the 1986 challenger disaster \cite{wdycwopt}.
-For the failure mode to occurr the ambiant temperature had to
+For the failure mode to occur the ambient temperature had to
 be below a critical value.
 If we take the failure mode of the `O' ring to be $C$
 and the temperature below critical to be $A$, we can see that
@@ -746,30 +784,34 @@ The intention for these diagrams is that they are used to collect
 component faults and combinations thereof, into faults that,
 at the module level have the same symptoms.
 
-\subsection{Example Sub-system}
+The act of collecting common symptoms by joining lines is seen as intuitive.
+Syntax checking (looking for contradictions and tautologies), as well as detecting
+errors of ommission are automated in the FMMD tool.
 
-For instance were a `power supply' being analysed there could be several
+%\subsection{Example Sub-system}
-individual component faults or combinations that lead to
+%
-a situation where there is no power. This can be described as a state 
+%For instance were a `power supply' being analysed there could be several
-of the powersupply being modeelled as NO\_POWER.
+%individual component faults or combinations that lead to
-These can all be collected by  DISJUCNTION, i.e. that this this or this
+%a situation where there is no power. This can be described as a state 
-fault occuring will cause the NO\_POWER fault. Visually this disjuction is
+%of the powersupply being modeelled as NO\_POWER.
-indicated by the joining lines.
+%These can all be collected by  DISJUCNTION, i.e. that this this or this
-As far as the user of the `power supply' is concerned, the power supply has failed
+%fault occuring will cause the NO\_POWER fault. Visually this disjuction is
-with the failure mode $NO\_POWER$.
+%indicated by the joining lines.
-The `power supply' module, after this process will have a defined set of
+%As far as the user of the `power supply' is concerned, the power supply has failed
-fault modes and may be considered as a component at a higher
+%with the failure mode $NO\_POWER$.
-level of abstraction. This module can then be combined 
+%The `power supply' module, after this process will have a defined set of
-with others at the same abstraction level.
+%fault modes and may be considered as a component at a higher
-Note that because this is a fault collection process 
+%level of abstraction. This module can then be combined 
-the number of component faults for a module
+%with others at the same abstraction level.
-must be less than or equal to the sum of the number of component faults.
+%Note that because this is a fault collection process 
+%the number of component faults for a module
+%must be less than or equal to the sum of the number of component faults.
 
 %Typeset in \ \ {\huge \LaTeX} \ \ on \ \  \today 
 
-\begin{verbatim}
+%\begin{verbatim}
-CVS Revision Identity $Id: logic_diagram.tex,v 1.17 2010/01/06 13:41:32 robin Exp $
+%CVS Revision Identity $Id: logic_diagram.tex,v 1.17 2010/01/06 13:41:32 robin Exp $
-\end{verbatim}
+%\end{verbatim}
 Compiled last \today
 %\end{document}
 

logic_diagram/logic_diagram.tex~

@@ -1,779 +0,0 @@
-
-
-\begin{abstract} 
-%This chapter describes using diagrams to represent propositional logic.
-Propositial Logic Diagrams have been designed to provide an intuitive method for visualising and manipulating
-logic equations, to express fault modes in Mechanical and Electronic Systems.
-%To aid hierarchical stages of fault analysis, it has been specifically developed for the purpose of 
-%joining conjunctive conditions with disjuctive conditions
-%to group the effects of failure modes.
-Diagrams of this type can also be used to model the logical conditions
-that control the flow of a computer program. This type of diagram can therefore
-integrate logical models from mechanical, electronic and software domains.
-Nearly all modern safety critical systems involve these three disiplines.
-%
-It is intended to be used for analysis of automated safety critical systen
-Many types of safety critical systems now legally 
-require fault mode effects analysis\cite{FMEA},
-but few formal systems exist and wide-spread take-up is
-not yet the norm.\cite{takeup}. 
-%
-Because of its visual nature, it is easy to manipulate and model
-complicated conditions that can lead to dangerous failures in 
-automated systems.
-
-% No need to talk about abstraction yet, just define PLD PROPERLY
-
-The Diagrams described here form the mathematical basis for a new visual and formal system
-for the analysis of safety critical software and hardware systems.
-\end{abstract}
-
-%\title{Propositional Logic Diagrams}
-%\begin{keyword}
-%  fault~tree fault~mode EN298 EN61508  EN12067  EN230 UL1998 safety~critical logic euler venn propositional
-%\end{keyword}
-%\end{frontmatter}
-
-% In software looking at one condition means lots of dont care situations
-% in static analysis we look at given sub-sets of faults and assume the other faults
-% are not active.
-% This is a major cultural difference !
-% it deserves a whole chapter.
-
-
-\section{Introduction}
-
-Propositional Logic Diagrams (PLDs) have been devised
-to collect and simplfy fault~modes in safety critical systems undergoing
-static analysis\cite{FMEA}\cite{SIL}.
-
-This type of analysis treats failure modes within a system as logical
-states. PLD provides a visual method for modelling failure~mode analysis
-within these systems, and specifically
-identifying common failure symptoms in a user friendly way.
-Contrasting this to looking at many propositional logic equations directly
-in a text editor or spreadsheet, a visual method is percieved as being more intuitive.
-
-
-%Traditional set theory is often represented by Euler\cite{euler} or Spider\cite{spider}
-%diagrams. These use contours to describe inclusion in a set.may be merged and create a  
-%Propositional Logic Diagrams (PLDs) use named contours represent a logical conditions.
-%Where an Euler diagram would use
-%overlapping contours to represent inclusion in sets,
-%PLDs use these to represent conjunction of the conditions.
-
-%Named reference points may be placed onto the diagram,
-%these represent test cases for conjunction. 
-%These can be joined by lines to apply disjunction.
-%In a spider diagram the lines would represent that the object represented coul;d belong to either set.
-%in a PLD it means that the logical conditions represent disjuction; a boolean OR condition.
-%these points may be joined. 
-
-PLDs use  three visual features that
-can be combined to represent logic equations. Closed contours, test cases, and lines that
-link test cases.
-All features may be labelled, and the labels must be unique within a diagram, however contours may be repeated in the diagram.
-%Aditionally a label begining with the `$\neg$' character, applied only to a contour, represents negation.
-
-
-%Regions defined by contours are used to represent given conjunctive logical conditions.
-
-Test cases are marked by asterisks. These are used as a visual `anchor'
-to mark a logical condition, the logical condition being defined by the contours
-that enclose the region on which the test~case has been placed.
-The contours that enclose represent conjuction.
-Test~cases may be connected by joining lines. These lines represent disjunction (Boolean `OR') of
-test~cases.
-
-With these three visual syntax elements, we have the basic building blocks for all logic equations possible.
-\begin{description}
-\item Test cases - Points on the plane indicating a logical condition.
-\item Conjunction - Overlapping contours
-\item Disjunction - Joining of named test cases.
-%\item Negation - Countours negatively named
-\end{description}
-
-% Because of this
-% we have the complete suite of logical primitives here, conjunction, disjuction and negation.
-% Form these complex logic equations can be respresented in 2D.
-
-% Another advantage of this is being able to describe `don't care' conditions.
-% Very often in digital hardware design, or in a computer program
-% many logical conditions are  `don't care'.
-% These are difficult to specify in set theory.
- 
-
-
-
-\section{Formal Description of PLD}
-
-Definitions of conrete and abstract PLD's follow.
-Well-formedness conditions for PLD's are separated from this definition, because of 
-practical differences between the way they are used to represent software as opposed to
-representing electronics and mechanical systems.
-
-\subsection{Concrete PLD Definition}
-
-A concrete {\em Propositional logic diagram} is a set of labeled {\em contours}
-(closed curves) in the plane. The minimal regions formed by the closed curves
-can by occupied by `test points'.
-The `test points' may be joined by joining lines.
-A group of `test points' connected by joining lines
-is defined as a `test point disjunction' or Spider.
-Spiders may be labeled.
-
-To differentiate these from common Euler diagram notation (normally used to represent set theory)
-the curves are drawn using dotted and dashed lines.
-
-\subsection{ PLD Definition}
-In English:
-The elements that can be found in a PLD diagram are a number of contours,
-a number of test points and joining lines that connect
-test points.
-{
-\definition{A concrete PLD $d$ is a set comprising of a set of 
-closed curves $C=C(d)$, a set of test points $T=T(d)$ and 
-a set of test point joining lines $J=J(d)$.
- $$d=\{C,T,J\}$$
-}
-}
-
-In English:
-Each element of  the diagram has a unique label within the diagram.
-%Thus the set of labels found in a diagram is 
-%a subset of the powerset of characters that can be present in a label.
-
-%{
-%\definition{ $ \mathcal{F}_{d}:C(d) \rightarrow  \mathcal{P}\Lambda$ is a 
-%function associating a label drawn from an infinite 
-%set of labels $\Lambda$.
-%}
-%}
-
-%In English:
-%A minimal region of a PLD diagram d is a 
-%region bounded by curves.
-%connected component of $\mathbb{R}^{2} - \; \bigcup_{c \in C(d)} c$
-
-%That is to say the complement of all other regions is subtracted from the plane.
-%- Or in another way- that smallest area defined by the curves that enclose it
-
-
-%% \hat is used to indicate CONCRETE
-
-{
-\definition{
-  A minimal region of concrete PLD diagram d is a connected component of  
-
-$$ \mathbb{R}^{2} - \; \bigcup_{\hat{c} \in \hat{C}(\hat{d})}\hat{c}$$
-
-% I.e. The contours break the connectivity
-}
-}
-
-{
-\definition
-{
-  Let d be a PLD and $ \mathcal{X} \subseteq \hat{C}(\hat{d})$ a set of countours.
- If the set
-$$ \hat{z} =  \bigcap_{c \in \mathcal{X}} 
-             {interior} 
-             (\hat{c}) 
-             \; \cup \;
-              \bigcap_{\hat{c} \in \hat{C}-X} 
-             exterior (\hat{c}) 
-$$
-
-is non empty, then $\hat{z}$ is a concrete zone of $\hat{d}$. A zone is  a union of minimal regions. The set of all concrete zones of $\hat{d}$
- is denoted $ \hat{\mathcal{Z}} $. 
-
-% NOT interested in labelling the zones.
-% but am interested in  
-%The set of labels associated with the contours in $\mathcal{X}$ is the zone label set $\hat{\mathcal{Z}}(\hat{z})$
-%of $\hat{z}$.
-%$$ \hat{\mathcal{L}}(\hat{z}) = \bigcup_{\hat{c} \in \mathcal{X}} \mathcal{F}_{d}(\hat{c}) $$
-%
-% So Z is the set of all available for use ZONES; great !
-
-}
-}
-
-
-Each minimal region in the plane may be inhabited by one or more `test points'.
-% One or more because in software the same logical conditions mean existing in the same 
-% region. For electroincs or mechanical, one test point per region is
-% mandatory. How to describe ?????
-Each test point can be  associated with the set of contours that enclose it.
-%defined the minimal region it inhabits.
-
-{
-\definition{ $ \mathcal{Z}_{d}:T(d)\rightarrow \mathcal{C}$ is a function 
-associating a testpoint with a set of contours in the plane. This corresponds to the interior of the contours defining the zone.
-}
-}
-
-Pairs of test points may be joined by joining lines.
-The operator $\stackrel{join}{\leftrightarrow}$ is used to
-show that two points are joined by a line in the concrete diagram.
-
-{
-\definition{
- 
-$ \mathcal{F}_{j}$ is a function 
-associating a joining line with a pair of test points. The Join t1,t2 is defined as
-
-%$$ \mathcal{F}_{d}:J(d)\rightarrow \{t1,t2\ | t1 \in T(d) \wedge  t2 \in T(d) \wedge t1 \neq t2 %\wedge t1 \stackrel{join}{\leftrightarrow} t2\} $$
- $$ \mathcal{F}_{d}:J(d)\rightarrow \{t1,t2\ | t1 \in T(d) \wedge  t2 \in T(d) \wedge t1 \neq t2 \} $$
-} 
-}
-
-In English:
-Test points on the concrete diagram pair-wise connected by a `joining line'
-
-
-A collection of test points connected by joining lines, is an Fuctionally Merged Group, $FMG$
-or `test point disjunction'.
-An $FMG$ has members which are test points.
-
-{may be merged
-and create a  
-\definition{ 
-%A spider is a set of test points where, 
-%a test point is a member of a spider where it can trace a path connected by joining lines
-%to another member of the spider. A singleton test point can be considered a spider. 
-Let d be a PLD : An $FMG$ is a maximal set of test points in d where
-the test points belong to a sequence connected by joining lines such that:
-
-$$ t_i \stackrel{join}{\leftrightarrow} t_n, for \; i = 1, ..., n $$
-
-
-OR consider an $FMG$ as a tree whose nodes are test points.
-
-} 
-}
-
-A singleton test point can be considered a sequence of one test point and is therefore also an $FMG$.
-
-
-% \subsection{Abstract Description of PLD}
-% 
-% An Abstract PLD {\em Propositional logic diagram} consists of contours $C$ defining zones $Z$,  test points $T$ (which
-% are defined by the zone they inhabit) and pair wise connections $W$, which connect test points.
-% Collections of test points, linked by shared conecting lines, form a set of test point groups $G$. 
-% 
-% A Zone defined by the contours that enclose it in the concrete diagram.
-% 
-% $$ Z \subseteq C $$
-% 
-% A test point $t \in T$ in habits a zone on the diagram.
-% 
-% $$ \eta(t) = Z $$
-% 
-% A joining line $$ w \in W $$ joins test points.
-% 
-% $$ w = t1 \stackrel{join}{\rightarrow} t2 | t1 \neq t2 \wedge t1 \in T \wedge t2 \in T $$
-% 
-% A test point group $g \in G$ is defined by test points linked by shared connecting lines.
-
-
-\subsection{Semantics of PLD}
-
-\begin{itemize}
-\item A closed curve in a PLD represents a condition (logical state) being modelled.
-\item A test point represents the conjunction of the conditions represented by the curves that enclose it. 
-\item A $FMG$ represents the disjunction of all test points that are members of it.
-\end{itemize}
-
-To obtain the set of propositions from a PLD, each $FMG$ must be processed. For each test case
-in the $FMG$ a new section of the equation is disjuctively appended to it.
-
-
-
-Let conjunctive logic equation associated with a test point
-be determined from the contours that enclose it.
-i.e. the contours $\mathcal{X}$ from the zone it inhabits.
-
-{
-\definition{
- 
-Let $\mathcal{F}_{t}$  be a function mapping a test point to a proposition / logical equation $p \in P$.
-The test point inhabits the zone $\mathcal{Z}$ which is a collection of contours (the contours that enclose the test point.
-
-$$ \mathcal{F}:T \rightarrow P $$
-
-%$$ \mathcal{F}(t): p  = \bigwedge_{c \in \mathcal{Z}}  \Lambda c  $$  
-
-$$ \mathcal{F}(t): p  = \bigwedge_{c \in \mathcal{Z}}  c $$
-}
-}
-
-
-
-In English:
-Thus a `test point' enclosed by contours labelled $a,b,c$ would be represented by the logic equation
-$ a \wedge b \wedge c $.
-
-{
-\definition{
-Let $\mathcal{G}_{fmg}$ be a function that returns a logic equation for a given $FMG$ 
-$fmg$ in the diagram, where an FMG  is a non empty set of test points 
-%  $t$ is a `test point'
-
-$$ \mathcal{G}:FMG \rightarrow P_{fmg} $$
-
-The logic equation representing an FMG $p_{fmg}$ can be determined thus.
-
-$$\mathcal{G}_{fmg}(fmg) = \bigvee_{t \in fmg} (\; \mathcal{F}_{t} (t) \;) $$
-}
-}
-
-The abstract PLD diagram is a set of logic equations representing all FMGs, 
-along with unused zones (i.e. zones that are not inhabited by FMGs).
-{
-\definition{
-\label{FMGderivation}
-A diagram can be reduced to a collection of $FMG$s.
-A new diagram can be derived from this, replacing a contour for each FMG.
-This diagram is at one higher level of abstraction then the diagram that
-it was produced from.
-}
-}
-
-
-\section{Example Diagrams}
-
-
-\subsection {How to read a PLD diagram}
-
-PLD diagrams are read by first looking at the test case points.
-The test case asterisk will be enclosed by one or more contours.
-These contours are collected and form the logical conjunction 
-equation for the test case. 
-These test case points thus represent the conjunctive aspects
-of an equation defined in a PLD. Where these test cases are joined by lines;
-these represent disjunction of the conjunctive aspects defined by the test cases.
-Joining lines thus represent dis-junction in a PLD.
-
-%Where negation and assertion of a logical condition is required in the same diagram, a separate contour can be created, which is 
-%..assigned the same name as its positive counter part, but preceded by a negation `$\neg$' sign.
-%Obviously were a drawing to show conjunction of a contour and its complement
-%this would result in a contradiction for any test case placed on it, and would be a visual `syntax error'. 
-
-%Note that negation is handled explicitly. This is to allow `don't care'
-%conditions. Should a test case be outside a contour, that contour is a `don't care' condition.
-%In a PLD, contours may be represented in complement, to provide
-%logical negation. Here the contour name is begun with the negation symbol `$\neg$'.
-%%To represent conjunction of logical conditions (Boolean `AND'), contours may be overlapped.
-
-%Providing explicit negation, in addition to disjunction and conjunction
-%allows us to represent `don't care' or `tri-state' logical conditions. Simply by
-%not using the conditions we are not interested in they are `don't care'.
-%
-
-%\section{Example Logic Diagrams}
-
-\subsection{ Logical AND example }
-
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 279 247]{logic_diagram/ldand.jpg}
- % ldand.jpg: 279x247 pixel, 72dpi, 9.84x8.71 cm, bb=0 0 279 247
- \label{fig:ld_and}
-\end{figure}
-
-% \begin{figure}[h+]
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{logic_diagram/ldand.jpg}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% 
-% %\includegraphics[scale=0.6]{ldand.eps}
-% \caption{Logical AND}
-% \label{fig:ld_and}
-% \end{figure}
-
-
-In the diagram \ref{fig:ld_and} the area of intersection between the contours $a$ and $b$
-represents the conjunction of those conditions. The point $P$ represents the logic equation
-$$ P = (a \wedge b) $$
-There are no disjunctive joining lines and so this diagram represents one equation only, $ P = (a \wedge b) $.
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, this could be considered to be a sub-system with two failure states $a$ and $b$.
-The proposition $P$ considers the scenario where both failure~modes are active.
-
-\clearpage
-\subsection { Logical OR example }
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 476 264]{logic_diagram/ldor.jpg}
- % ldor.jpg: 476x264 pixel, 72dpi, 16.79x9.31 cm, bb=0 0 476 264
- \label{fig:ld_or}
-\end{figure}
-
-% \begin{figure}[h+]
-% %\centering
-% %\input{ldor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{logic_diagram/ldor.jpg}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.60]{ldor.eps}
-% \caption{Logical OR}
-% \label{fig:ld_or}
-% \end{figure} % OR
-
-
-The diagram \ref{fig:ld_or} is converted to Boolean logic by first looking at the test cases, and 
-the contours they are placed on. 
-$$ P = (a) $$ 
-$$ Q = (b) $$  
-
-The two test cases are joined by a the line named $R$.
-we thus apply disjunction to the test cases.
-$$ R = P \vee Q $$ 
-substituting the test cases for their Boolean logic equations gives
-$$ R = ((a) \vee (b)) $$.
-
-
-
-\clearpage
-\subsection {Labels and useage}
-
-In diagram \ref{fig:ld_meq} Z and W were labeled but were not necessary for the final expression
-of $ R = b \vee c $. The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning.
-Test cases joined by disjunction, all become represented in one, resultant equation.
-Therefore only test cases not linked by any disjunctive joining lines need be named.
-
-The diagram   \ref{fig:ld_meq} can therefore be represented as in diagram \ref{fig:ld_meq2}, with 
-two unnamed test cases.
-
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 572 297,scale=0.7,keepaspectratio=true]{./ldmeq2.jpg}
- % ldmeq2.jpg: 572x297 pixel, 72dpi, 20.18x10.48 cm, bb=0 0 572 297
- \label{fig:ld_meq2}
-\end{figure}
-
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0pt 0pt 600pt 600pt]{logic_diagram/ldmeq2.jpg}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.4]{ldmeq2.eps}
-% \caption{Several Logical Expressions with unamed test cases}
-% \label{fig:ld_meq2}
-% \end{figure}
-
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, this could be considered to be a sub-system with two failure states $a$ and $b$.
-The proposition $P$ considers the scenario where either failure~mode is active.
-Additionally it says that either failure mode $a$ or $b$  being active
-will have a resultant effect $R$ on the sub-system. Note that the effect 
-of $a$ and $b$ both being active is not defined on this diagram.
-
-
-\clearpage
-
-
-
-\subsection { Repeated Contour example }
-
-
-Repeated contours are allowed in PLD diagrams.
-Logical contradictions or tautologies can be detected automatically by
-a software tool which assists in drawing these diagrams.
-
-
-
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 485 206]{logic_diagram/repeated.jpg}
- % repeated.jpg: 539x229 pixel, 80dpi, 17.11x7.27 cm, bb=0 0 485 206
- \label{fig:repeat}
-\end{figure}
-
-%  \begin{figure}[h]
-%  \centering
-%  \includegraphics[bb=0 0 486 206]{./repeated.jpg}
-%  % repeated.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 486 206
-%  \label{fig:repeated}
-% \end{figure}
-
-
-
-The diagram \ref{fig:repeat} is converted to Boolean logic by first looking at the test cases, and 
-the contours they are placed on. 
-$$ P = (b) $$ 
-$$ Q = (a) \wedge (c) $$  
-
-The two test cases are joined by a the line named $R1$.
-we thus apply disjunction to the test cases.
-$$ R1 = P \vee Q $$ 
-$$ R1 = b \vee ( a \wedge c ) $$.
-
-$R2$ joins two other test cases
-$$R2 = a \vee c $$
-
-The test~case residing in the intersection of countours $B$ and $A$
-represents the logic equation $R3 = a \wedge b$.
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$
-occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring.
-There is an additional symptom, that of the test case in $A \wedge B$.
-
-
-
-\clearpage
-
-
-\subsection { Inhibit Failure }
-
-
-Very often a failure mode can only occurr
-given a searate environmental condition.
-In Fault Tree Analysis (FTA) this is represented by an inhibit gate.
- 
-  \begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 364 227]{logic_diagram/inhibit.jpg}
- % inhibit.jpg: 404x252 pixel, 80dpi, 12.83x8.00 cm, bb=0 0 364 227
- \label{fig:inhibit}
-\end{figure}
-% 
-% \begin{figure}[h]
-%  \centering
-%  \includegraphics[bb=0 0 364 228]{./inhibit.jpg}
-%  % inhibit.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 364 228
-%  \label{fig:inhibit}
-% \end{figure}
-
-The diagram \ref{fig:inhibit} has a test case in the contour $C$.
-Contour $C$ is enclosed by contour $A$. This says
-that for failure~mode $C$ to occur failure mode $A$
-must have occurred.
-A well known example of this is the space shuttle `O' ring failure that
-caused the 1986 challenger disaster \cite{wdycwopt}.
-For the failure mode to occurr the ambiant temperature had to
-be below a critical value.
-If we take the failure mode of the `O' ring to be $C$
-and the temperature below critical to be $A$, we can see that
-the low temperature failure~mode $C$ can only occurr if $A$ is true.
-The `O' ring could fail in a different way independant of the critical temperature and this is 
-represented, for the sake of this example, by contour $D$.
-
-In terms of propositional logic, the inhibit gate of FTA, and the countour enclosure
-of PLD represent {\em implication}.
-\\
-% \tiny
-\vspace{0.3cm}
- \begin{tabular}{||c|c|c|c||} \hline \hline
-   {\em $c$ }  & {\em $a$ } &  {\em $R1$  }      \\ \hline
-       F         &  F  &    T     \\ \hline
-       F         &  T  &    T     \\ \hline
-       T         &  F  &    F     \\ \hline
-       T         &  T  &    T     \\ \hline \hline
- \end{tabular}
-\vspace{0.3cm}
-% \normalsize
-
-$$ R1 = c \implies a $$
-$$ R2 = a $$
-$$ R3 = d $$
-
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$
-occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring.
-Note that although R2 is a symptom of the sub-system, on its own
-it will not lead to a dangerous failure~mode of the subsystem.
-
-
-% \subsection { Representing Logical Negation }
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{ldor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{logic_diagram/ldneg.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.60]{ldneg.eps}
-% \caption{Logical Negation}
-% \label{fig:ld_neg}
-% \end{figure} % OR
-% 
-% Diagram \ref{fig:ld_neg} represents the logical equation $$ P = a \wedge b \wedge \neg c $$.
-% 
-% \paragraph{How this would be interpreted in failure analysis} 
-% In failure analysis this test case represents the scenario where failure modes $a$ and $b$
-% are active but $c$ is not.
-% 
-% 
-% 
-% \clearpage
-% \subsection { Logical XOR example }
-% 
-% An exclusive or condition is represented by diagram \ref{fig:ld_xor}.
-% The Equations represented are as follows.
-% 
-% firstly looking at the test case points
-% $$ P = (\neg a \wedge b) $$ 
-% $$ Q = (\neg b \wedge a) $$ 
-% 
-% now joining them with the disjuctive line
-% $$ R = P \vee Q $$ 
-% 
-% Giving R as a Boolean equation
-% $$ R = (\neg a \wedge b) \vee (\neg b \wedge a) $$
-% or taking the symbol $\oplus$ to mean exclusive-or
-% $$R = a \oplus b $$
-% 
-% 
-% % \begin{figure}[h] %% SOMETHING IS WRONG says latex. very helpful tell me what it fucking is then
-% % \centering
-% % \caption{Example `XOR' Diagram}
-% % \includegraphics[scale=0.80]{ldxor.eps}
-% % \label{fig:ld_xor}
-% % \end{figure} % XOR
-% 
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-% % bb= llx lly urx ury; 
-%  \includegraphics[width=200pt,bb=0pt 0pt 800pt 800pt]{logic_diagram/ldxor.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% 
-% %\includegraphics[scale=0.4]{ldxor.eps}
-% \caption{Logical XOR}
-% \label{fig:ld_xor}
-% \end{figure}
-% 
-% \clearpage
-% \subsection { Logical IMPLICATION example }
-% 
-% 
-% An implication $a \rightarrow b$ is represented by diagram \ref{fig:ld_imp}.
-% The Equations represented are as follows.
-% 
-% Looking at the conjuctive environment of the test cases
-% $$P = (\neg a)$$
-% $$Q = (b)$$
-% From the joining `disjunctive' line R in the diagram.
-% $$R = P \vee Q$$
-% Leading to
-% $$R = (\neg a) \vee (b)$$
-% which is the standard logic equation for implication.
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{logic_diagram/ldimp.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.4]{ldimp.eps}
-% \caption{Logical Implication}
-% \label{fig:ld_imp}
-% \end{figure}
-% 
-% \tiny
-% %\vspace{0.3cm}
-% \begin{tabular}{||c|c|c|c||} \hline \hline
-% 
-%   {\em $a$ }  & {\em $b$ } &  {implication \em $(\neg a) \vee (b) $  }      \\ \hline
-%       F         &  F  &    T     \\ \hline
-%       F         &  T  &    T     \\ \hline
-%       T         &  F  &    F     \\ \hline
-%       T         &  T  &    T     \\ \hline \hline
-% \end{tabular}
-% %\vspace{0.3cm}
-% \normalsize
-% 
-% \clearpage
-% \subsection { Diagram representing several Logic Equations Example }
-% 
-% 
-% bb=0 0 450 404
-% 
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0pt 0pt 600pt 600pt]{logic_diagram/ldmeq.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.4]{ldmeq.eps}
-% \caption{Several Logical Expressions}
-% \label{fig:ld_meq}
-% \end{figure}
-% 
-% %The effect of using explicit negation, means that a test case being outside a given contour does not imply negation, it implies a `don't care'
-% %condition.
-% 
-% Three simple equations are represented in the  diagram \ref{fig:ld_dc}.
-% 
-% %The Set of contours $\mho$ represent the `don't care' conditions.
-% 
-% The Equations represented are as follows.
-% 
-% %$$ Q = a \; | \; \mho\{b,c\} $$
-% 
-% %$$ P = b \wedge c \; | \; \mho\{a\} $$
-% 
-% $$ Q = a $$
-% $$ P = b \wedge c $$
-% $$ R = b \vee c $$
-% 
-% % XXXXXX gives annoying impossible to understand syntax messages
-% %\small
-% %\bibliography{vmgbibliography,mybib}
-% %\bibliography{vmgbibliography}
-% %\normalsize
-% 
-\section{Intended use in FMMD}
-
-The intention for these diagrams is that they are used to collect
-component faults and combinations thereof, into faults that,
-at the module level have the same symptoms.
-
-\subsection{Example Sub-system}
-
-For instance were a `power supply' being analysed there could be several
-individual component faults or combinations that lead to
-a situation where there is no power. This can be described as a state 
-of the powersupply being modeelled as NO\_POWER.
-These can all be collected by  DISJUCNTION, i.e. that this this or this
-fault occuring will cause the NO\_POWER fault. Visually this disjuction is
-indicated by the joining lines.
-As far as the user of the `power supply' is concerned, the power supply has failed
-with the failure mode $NO\_POWER$.
-The `power supply' module, after this process will have a defined set of
-fault modes and may be considered as a component at a higher
-level of abstraction. This module can then be combined 
-with others at the same abstraction level.
-Note that because this is a fault collection process 
-the number of component faults for a module
-must be less than or equal to the sum of the number of component faults.
-
-%Typeset in \ \ {\huge \LaTeX} \ \ on \ \  \today 
-
-\begin{verbatim}
-CVS Revision Identity $Id: logic_diagram.tex,v 1.17 2010/01/06 13:41:32 robin Exp $
-\end{verbatim}
-Compiled last \today
-%\end{document}
-
-%\theend
-
-
-

logic_diagram/logic_diagram_paper.tex

@@ -1,779 +0,0 @@
-
-
-\begin{abstract} 
-%This chapter describes using diagrams to represent propositional logic.
-Propositial Logic Diagrams have been designed to provide an intuitive method for visualising and manipulating
-logic equations, to express fault modes in Mechanical and Electronic Systems.
-%To aid hierarchical stages of fault analysis, it has been specifically developed for the purpose of 
-%joining conjunctive conditions with disjuctive conditions
-%to group the effects of failure modes.
-Diagrams of this type can also be used to model the logical conditions
-that control the flow of a computer program. This type of diagram can therefore
-integrate logical models from mechanical, electronic and software domains.
-Nearly all modern safety critical systems involve these three disiplines.
-%
-It is intended to be used for analysis of automated safety critical systen
-Many types of safety critical systems now legally 
-require fault mode effects analysis\cite{FMEA},
-but few formal systems exist and wide-spread take-up is
-not yet the norm.\cite{takeup}. 
-%
-Because of its visual nature, it is easy to manipulate and model
-complicated conditions that can lead to dangerous failures in 
-automated systems.
-
-% No need to talk about abstraction yet, just define PLD PROPERLY
-
-The Diagrams described here form the mathematical basis for a new visual and formal system
-for the analysis of safety critical software and hardware systems.
-\end{abstract}
-
-%\title{Propositional Logic Diagrams}
-%\begin{keyword}
-%  fault~tree fault~mode EN298 EN61508  EN12067  EN230 UL1998 safety~critical logic euler venn propositional
-%\end{keyword}
-%\end{frontmatter}
-
-% In software looking at one condition means lots of dont care situations
-% in static analysis we look at given sub-sets of faults and assume the other faults
-% are not active.
-% This is a major cultural difference !
-% it deserves a whole chapter.
-
-
-\section{Introduction}
-
-Propositional Logic Diagrams (PLDs) have been devised
-to collect and simplfy fault~modes in safety critical systems undergoing
-static analysis\cite{FMEA}\cite{SIL}.
-
-This type of analysis treats failure modes within a system as logical
-states. PLD provides a visual method for modelling failure~mode analysis
-within these systems, and specifically
-identifying common failure symptoms in a user friendly way.
-Contrasting this to looking at many propositional logic equations directly
-in a text editor or spreadsheet, a visual method is percieved as being more intuitive.
-
-
-%Traditional set theory is often represented by Euler\cite{euler} or Spider\cite{spider}
-%diagrams. These use contours to describe inclusion in a set.may be merged and create a  
-%Propositional Logic Diagrams (PLDs) use named contours represent a logical conditions.
-%Where an Euler diagram would use
-%overlapping contours to represent inclusion in sets,
-%PLDs use these to represent conjunction of the conditions.
-
-%Named reference points may be placed onto the diagram,
-%these represent test cases for conjunction. 
-%These can be joined by lines to apply disjunction.
-%In a spider diagram the lines would represent that the object represented coul;d belong to either set.
-%in a PLD it means that the logical conditions represent disjuction; a boolean OR condition.
-%these points may be joined. 
-
-PLDs use  three visual features that
-can be combined to represent logic equations. Closed contours, test cases, and lines that
-link test cases.
-All features may be labelled, and the labels must be unique within a diagram, however contours may be repeated in the diagram.
-%Aditionally a label begining with the `$\neg$' character, applied only to a contour, represents negation.
-
-
-%Regions defined by contours are used to represent given conjunctive logical conditions.
-
-Test cases are marked by asterisks. These are used as a visual `anchor'
-to mark a logical condition, the logical condition being defined by the contours
-that enclose the region on which the test~case has been placed.
-The contours that enclose represent conjuction.
-Test~cases may be connected by joining lines. These lines represent disjunction (Boolean `OR') of
-test~cases.
-
-With these three visual syntax elements, we have the basic building blocks for all logic equations possible.
-\begin{description}
-\item Test cases - Points on the plane indicating a logical condition.
-\item Conjunction - Overlapping contours
-\item Disjunction - Joining of named test cases.
-%\item Negation - Countours negatively named
-\end{description}
-
-% Because of this
-% we have the complete suite of logical primitives here, conjunction, disjuction and negation.
-% Form these complex logic equations can be respresented in 2D.
-
-% Another advantage of this is being able to describe `don't care' conditions.
-% Very often in digital hardware design, or in a computer program
-% many logical conditions are  `don't care'.
-% These are difficult to specify in set theory.
- 
-
-
-
-\section{Formal Description of PLD}
-
-Definitions of conrete and abstract PLD's follow.
-Well-formedness conditions for PLD's are separated from this definition, because of 
-practical differences between the way they are used to represent software as opposed to
-representing electronics and mechanical systems.
-
-\subsection{Concrete PLD Definition}
-
-A concrete {\em Propositional logic diagram} is a set of labeled {\em contours}
-(closed curves) in the plane. The minimal regions formed by the closed curves
-can by occupied by `test points'.
-The `test points' may be joined by joining lines.
-A group of `test points' connected by joining lines
-is defined as a `test point disjunction' or Spider.
-Spiders may be labeled.
-
-To differentiate these from common Euler diagram notation (normally used to represent set theory)
-the curves are drawn using dotted and dashed lines.
-
-\subsection{ PLD Definition}
-In English:
-The elements that can be found in a PLD diagram are a number of contours,
-a number of test points and joining lines that connect
-test points.
-{
-\definition{A concrete PLD $d$ is a set comprising of a set of 
-closed curves $C=C(d)$, a set of test points $T=T(d)$ and 
-a set of test point joining lines $J=J(d)$.
- $$d=\{C,T,J\}$$
-}
-}
-
-In English:
-Each element of  the diagram has a unique label within the diagram.
-%Thus the set of labels found in a diagram is 
-%a subset of the powerset of characters that can be present in a label.
-
-%{
-%\definition{ $ \mathcal{F}_{d}:C(d) \rightarrow  \mathcal{P}\Lambda$ is a 
-%function associating a label drawn from an infinite 
-%set of labels $\Lambda$.
-%}
-%}
-
-%In English:
-%A minimal region of a PLD diagram d is a 
-%region bounded by curves.
-%connected component of $\mathbb{R}^{2} - \; \bigcup_{c \in C(d)} c$
-
-%That is to say the complement of all other regions is subtracted from the plane.
-%- Or in another way- that smallest area defined by the curves that enclose it
-
-
-%% \hat is used to indicate CONCRETE
-
-{
-\definition{
-  A minimal region of concrete PLD diagram d is a connected component of  
-
-$$ \mathbb{R}^{2} - \; \bigcup_{\hat{c} \in \hat{C}(\hat{d})}\hat{c}$$
-
-% I.e. The contours break the connectivity
-}
-}
-
-{
-\definition
-{
-  Let d be a PLD and $ \mathcal{X} \subseteq \hat{C}(\hat{d})$ a set of countours.
- If the set
-$$ \hat{z} =  \bigcap_{c \in \mathcal{X}} 
-             {interior} 
-             (\hat{c}) 
-             \; \cup \;
-              \bigcap_{\hat{c} \in \hat{C}-X} 
-             exterior (\hat{c}) 
-$$
-
-is non empty, then $\hat{z}$ is a concrete zone of $\hat{d}$. A zone is  a union of minimal regions. The set of all concrete zones of $\hat{d}$
- is denoted $ \hat{\mathcal{Z}} $. 
-
-% NOT interested in labelling the zones.
-% but am interested in  
-%The set of labels associated with the contours in $\mathcal{X}$ is the zone label set $\hat{\mathcal{Z}}(\hat{z})$
-%of $\hat{z}$.
-%$$ \hat{\mathcal{L}}(\hat{z}) = \bigcup_{\hat{c} \in \mathcal{X}} \mathcal{F}_{d}(\hat{c}) $$
-%
-% So Z is the set of all available for use ZONES; great !
-
-}
-}
-
-
-Each minimal region in the plane may be inhabited by one or more `test points'.
-% One or more because in software the same logical conditions mean existing in the same 
-% region. For electroincs or mechanical, one test point per region is
-% mandatory. How to describe ?????
-Each test point can be  associated with the set of contours that enclose it.
-%defined the minimal region it inhabits.
-
-{
-\definition{ $ \mathcal{Z}_{d}:T(d)\rightarrow \mathcal{C}$ is a function 
-associating a testpoint with a set of contours in the plane. This corresponds to the interior of the contours defining the zone.
-}
-}
-
-Pairs of test points may be joined by joining lines.
-The operator $\stackrel{join}{\leftrightarrow}$ is used to
-show that two points are joined by a line in the concrete diagram.
-
-{
-\definition{
- 
-$ \mathcal{F}_{j}$ is a function 
-associating a joining line with a pair of test points. The Join t1,t2 is defined as
-
-%$$ \mathcal{F}_{d}:J(d)\rightarrow \{t1,t2\ | t1 \in T(d) \wedge  t2 \in T(d) \wedge t1 \neq t2 %\wedge t1 \stackrel{join}{\leftrightarrow} t2\} $$
- $$ \mathcal{F}_{d}:J(d)\rightarrow \{t1,t2\ | t1 \in T(d) \wedge  t2 \in T(d) \wedge t1 \neq t2 \} $$
-} 
-}
-
-In English:
-Test points on the concrete diagram pair-wise connected by a `joining line'
-
-
-A collection of test points connected by joining lines, is an Fuctionally Merged Group, $FMG$
-or `test point disjunction'.
-An $FMG$ has members which are test points.
-
-{may be merged
-and create a  
-\definition{ 
-%A spider is a set of test points where, 
-%a test point is a member of a spider where it can trace a path connected by joining lines
-%to another member of the spider. A singleton test point can be considered a spider. 
-Let d be a PLD : An $FMG$ is a maximal set of test points in d where
-the test points belong to a sequence connected by joining lines such that:
-
-$$ t_i \stackrel{join}{\leftrightarrow} t_n, for \; i = 1, ..., n $$
-
-
-OR consider an $FMG$ as a tree whose nodes are test points.
-
-} 
-}
-
-A singleton test point can be considered a sequence of one test point and is therefore also an $FMG$.
-
-
-% \subsection{Abstract Description of PLD}
-% 
-% An Abstract PLD {\em Propositional logic diagram} consists of contours $C$ defining zones $Z$,  test points $T$ (which
-% are defined by the zone they inhabit) and pair wise connections $W$, which connect test points.
-% Collections of test points, linked by shared conecting lines, form a set of test point groups $G$. 
-% 
-% A Zone defined by the contours that enclose it in the concrete diagram.
-% 
-% $$ Z \subseteq C $$
-% 
-% A test point $t \in T$ in habits a zone on the diagram.
-% 
-% $$ \eta(t) = Z $$
-% 
-% A joining line $$ w \in W $$ joins test points.
-% 
-% $$ w = t1 \stackrel{join}{\rightarrow} t2 | t1 \neq t2 \wedge t1 \in T \wedge t2 \in T $$
-% 
-% A test point group $g \in G$ is defined by test points linked by shared connecting lines.
-
-
-\subsection{Semantics of PLD}
-
-\begin{itemize}
-\item A closed curve in a PLD represents a condition (logical state) being modelled.
-\item A test point represents the conjunction of the conditions represented by the curves that enclose it. 
-\item A $FMG$ represents the disjunction of all test points that are members of it.
-\end{itemize}
-
-To obtain the set of propositions from a PLD, each $FMG$ must be processed. For each test case
-in the $FMG$ a new section of the equation is disjuctively appended to it.
-
-
-
-Let conjunctive logic equation associated with a test point
-be determined from the contours that enclose it.
-i.e. the contours $\mathcal{X}$ from the zone it inhabits.
-
-{
-\definition{
- 
-Let $\mathcal{F}_{t}$  be a function mapping a test point to a proposition / logical equation $p \in P$.
-The test point inhabits the zone $\mathcal{Z}$ which is a collection of contours (the contours that enclose the test point.
-
-$$ \mathcal{F}:T \rightarrow P $$
-
-%$$ \mathcal{F}(t): p  = \bigwedge_{c \in \mathcal{Z}}  \Lambda c  $$  
-
-$$ \mathcal{F}(t): p  = \bigwedge_{c \in \mathcal{Z}}  c $$
-}
-}
-
-
-
-In English:
-Thus a `test point' enclosed by contours labelled $a,b,c$ would be represented by the logic equation
-$ a \wedge b \wedge c $.
-
-{
-\definition{
-Let $\mathcal{G}_{fmg}$ be a function that returns a logic equation for a given $FMG$ 
-$fmg$ in the diagram, where an FMG  is a non empty set of test points 
-%  $t$ is a `test point'
-
-$$ \mathcal{G}:FMG \rightarrow P_{fmg} $$
-
-The logic equation representing an FMG $p_{fmg}$ can be determined thus.
-
-$$\mathcal{G}_{fmg}(fmg) = \bigvee_{t \in fmg} (\; \mathcal{F}_{t} (t) \;) $$
-}
-}
-
-The abstract PLD diagram is a set of logic equations representing all FMGs, 
-along with unused zones (i.e. zones that are not inhabited by FMGs).
-{
-\definition{
-\label{FMGderivation}
-A diagram can be reduced to a collection of $FMG$s.
-A new diagram can be derived from this, replacing a contour for each FMG.
-This diagram is at one higher level of abstraction then the diagram that
-it was produced from.
-}
-}
-
-
-\section{Example Diagrams}
-
-
-\subsection {How to read a PLD diagram}
-
-PLD diagrams are read by first looking at the test case points.
-The test case asterisk will be enclosed by one or more contours.
-These contours are collected and form the logical conjunction 
-equation for the test case. 
-These test case points thus represent the conjunctive aspects
-of an equation defined in a PLD. Where these test cases are joined by lines;
-these represent disjunction of the conjunctive aspects defined by the test cases.
-Joining lines thus represent dis-junction in a PLD.
-
-%Where negation and assertion of a logical condition is required in the same diagram, a separate contour can be created, which is 
-%..assigned the same name as its positive counter part, but preceded by a negation `$\neg$' sign.
-%Obviously were a drawing to show conjunction of a contour and its complement
-%this would result in a contradiction for any test case placed on it, and would be a visual `syntax error'. 
-
-%Note that negation is handled explicitly. This is to allow `don't care'
-%conditions. Should a test case be outside a contour, that contour is a `don't care' condition.
-%In a PLD, contours may be represented in complement, to provide
-%logical negation. Here the contour name is begun with the negation symbol `$\neg$'.
-%%To represent conjunction of logical conditions (Boolean `AND'), contours may be overlapped.
-
-%Providing explicit negation, in addition to disjunction and conjunction
-%allows us to represent `don't care' or `tri-state' logical conditions. Simply by
-%not using the conditions we are not interested in they are `don't care'.
-%
-
-%\section{Example Logic Diagrams}
-
-\subsection{ Logical AND example }
-
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 279 247]{ldand.jpg}
- % ldand.jpg: 279x247 pixel, 72dpi, 9.84x8.71 cm, bb=0 0 279 247
- \label{fig:ld_and}
-\end{figure}
-
-% \begin{figure}[h+]
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{ldand.jpg}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% 
-% %\includegraphics[scale=0.6]{ldand.eps}
-% \caption{Logical AND}
-% \label{fig:ld_and}
-% \end{figure}
-
-
-In the diagram \ref{fig:ld_and} the area of intersection between the contours $a$ and $b$
-represents the conjunction of those conditions. The point $P$ represents the logic equation
-$$ P = (a \wedge b) $$
-There are no disjunctive joining lines and so this diagram represents one equation only, $ P = (a \wedge b) $.
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, this could be considered to be a sub-system with two failure states $a$ and $b$.
-The proposition $P$ considers the scenario where both failure~modes are active.
-
-\clearpage
-\subsection { Logical OR example }
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 476 264]{ldor.jpg}
- % ldor.jpg: 476x264 pixel, 72dpi, 16.79x9.31 cm, bb=0 0 476 264
- \label{fig:ld_or}
-\end{figure}
-
-% \begin{figure}[h+]
-% %\centering
-% %\input{ldor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{ldor.jpg}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.60]{ldor.eps}
-% \caption{Logical OR}
-% \label{fig:ld_or}
-% \end{figure} % OR
-
-
-The diagram \ref{fig:ld_or} is converted to Boolean logic by first looking at the test cases, and 
-the contours they are placed on. 
-$$ P = (a) $$ 
-$$ Q = (b) $$  
-
-The two test cases are joined by a the line named $R$.
-we thus apply disjunction to the test cases.
-$$ R = P \vee Q $$ 
-substituting the test cases for their Boolean logic equations gives
-$$ R = ((a) \vee (b)) $$.
-
-
-
-\clearpage
-\subsection {Labels and useage}
-
-In diagram \ref{fig:ld_meq} Z and W were labeled but were not necessary for the final expression
-of $ R = b \vee c $. The intended use of these diagrams, is that resultant logical conditions be used in a later stage of reasoning.
-Test cases joined by disjunction, all become represented in one, resultant equation.
-Therefore only test cases not linked by any disjunctive joining lines need be named.
-
-The diagram   \ref{fig:ld_meq} can therefore be represented as in diagram \ref{fig:ld_meq2}, with 
-two unnamed test cases.
-
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 572 297,scale=0.7,keepaspectratio=true]{ldmeq2.jpg}
- % ldmeq2.jpg: 572x297 pixel, 72dpi, 20.18x10.48 cm, bb=0 0 572 297
- \label{fig:ld_meq2}
-\end{figure}
-
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0pt 0pt 600pt 600pt]{ldmeq2.jpg}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.4]{ldmeq2.eps}
-% \caption{Several Logical Expressions with unamed test cases}
-% \label{fig:ld_meq2}
-% \end{figure}
-
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, this could be considered to be a sub-system with two failure states $a$ and $b$.
-The proposition $P$ considers the scenario where either failure~mode is active.
-Additionally it says that either failure mode $a$ or $b$  being active
-will have a resultant effect $R$ on the sub-system. Note that the effect 
-of $a$ and $b$ both being active is not defined on this diagram.
-
-
-\clearpage
-
-
-
-\subsection { Repeated Contour example }
-
-
-Repeated contours are allowed in PLD diagrams.
-Logical contradictions or tautologies can be detected automatically by
-a software tool which assists in drawing these diagrams.
-
-
-
-\begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 485 206]{repeated.jpg}
- % repeated.jpg: 539x229 pixel, 80dpi, 17.11x7.27 cm, bb=0 0 485 206
- \label{fig:repeat}
-\end{figure}
-
-%  \begin{figure}[h]
-%  \centering
-%  \includegraphics[bb=0 0 486 206]{./repeated.jpg}
-%  % repeated.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 486 206
-%  \label{fig:repeated}
-% \end{figure}
-
-
-
-The diagram \ref{fig:repeat} is converted to Boolean logic by first looking at the test cases, and 
-the contours they are placed on. 
-$$ P = (b) $$ 
-$$ Q = (a) \wedge (c) $$  
-
-The two test cases are joined by a the line named $R1$.
-we thus apply disjunction to the test cases.
-$$ R1 = P \vee Q $$ 
-$$ R1 = b \vee ( a \wedge c ) $$.
-
-$R2$ joins two other test cases
-$$R2 = a \vee c $$
-
-The test~case residing in the intersection of countours $B$ and $A$
-represents the logic equation $R3 = a \wedge b$.
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$
-occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring.
-There is an additional symptom, that of the test case in $A \wedge B$.
-
-
-
-\clearpage
-
-
-\subsection { Inhibit Failure }
-
-
-Very often a failure mode can only occurr
-given a searate environmental condition.
-In Fault Tree Analysis (FTA) this is represented by an inhibit gate.
- 
-  \begin{figure}[h]
- \centering
- \includegraphics[bb=0 0 364 227]{inhibit.jpg}
- % inhibit.jpg: 404x252 pixel, 80dpi, 12.83x8.00 cm, bb=0 0 364 227
- \label{fig:inhibit}
-\end{figure}
-% 
-% \begin{figure}[h]
-%  \centering
-%  \includegraphics[bb=0 0 364 228]{./inhibit.jpg}
-%  % inhibit.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 364 228
-%  \label{fig:inhibit}
-% \end{figure}
-
-The diagram \ref{fig:inhibit} has a test case in the contour $C$.
-Contour $C$ is enclosed by contour $A$. This says
-that for failure~mode $C$ to occur failure mode $A$
-must have occurred.
-A well known example of this is the space shuttle `O' ring failure that
-caused the 1986 challenger disaster \cite{wdycwopt}.
-For the failure mode to occurr the ambiant temperature had to
-be below a critical value.
-If we take the failure mode of the `O' ring to be $C$
-and the temperature below critical to be $A$, we can see that
-the low temperature failure~mode $C$ can only occurr if $A$ is true.
-The `O' ring could fail in a different way independant of the critical temperature and this is 
-represented, for the sake of this example, by contour $D$.
-
-In terms of propositional logic, the inhibit gate of FTA, and the countour enclosure
-of PLD represent {\em implication}.
-\\
-% \tiny
-\vspace{0.3cm}
- \begin{tabular}{||c|c|c|c||} \hline \hline
-   {\em $c$ }  & {\em $a$ } &  {\em $R1$  }      \\ \hline
-       F         &  F  &    T     \\ \hline
-       F         &  T  &    T     \\ \hline
-       T         &  F  &    F     \\ \hline
-       T         &  T  &    T     \\ \hline \hline
- \end{tabular}
-\vspace{0.3cm}
-% \normalsize
-
-$$ R1 = c \implies a $$
-$$ R2 = a $$
-$$ R3 = d $$
-
-
-\paragraph{How this would be interpreted in failure analysis} 
-In failure analysis, $R2$ is the symptom of either failure~mode $A$ or $C$
-occurring. $R1$ is the symptom of $B$ or $A \wedge C$ occurring.
-Note that although R2 is a symptom of the sub-system, on its own
-it will not lead to a dangerous failure~mode of the subsystem.
-
-
-% \subsection { Representing Logical Negation }
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{ldor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{ldneg.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.60]{ldneg.eps}
-% \caption{Logical Negation}
-% \label{fig:ld_neg}
-% \end{figure} % OR
-% 
-% Diagram \ref{fig:ld_neg} represents the logical equation $$ P = a \wedge b \wedge \neg c $$.
-% 
-% \paragraph{How this would be interpreted in failure analysis} 
-% In failure analysis this test case represents the scenario where failure modes $a$ and $b$
-% are active but $c$ is not.
-% 
-% 
-% 
-% \clearpage
-% \subsection { Logical XOR example }
-% 
-% An exclusive or condition is represented by diagram \ref{fig:ld_xor}.
-% The Equations represented are as follows.
-% 
-% firstly looking at the test case points
-% $$ P = (\neg a \wedge b) $$ 
-% $$ Q = (\neg b \wedge a) $$ 
-% 
-% now joining them with the disjuctive line
-% $$ R = P \vee Q $$ 
-% 
-% Giving R as a Boolean equation
-% $$ R = (\neg a \wedge b) \vee (\neg b \wedge a) $$
-% or taking the symbol $\oplus$ to mean exclusive-or
-% $$R = a \oplus b $$
-% 
-% 
-% % \begin{figure}[h] %% SOMETHING IS WRONG says latex. very helpful tell me what it fucking is then
-% % \centering
-% % \caption{Example `XOR' Diagram}
-% % \includegraphics[scale=0.80]{ldxor.eps}
-% % \label{fig:ld_xor}
-% % \end{figure} % XOR
-% 
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-% % bb= llx lly urx ury; 
-%  \includegraphics[width=200pt,bb=0pt 0pt 800pt 800pt]{ldxor.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% 
-% %\includegraphics[scale=0.4]{ldxor.eps}
-% \caption{Logical XOR}
-% \label{fig:ld_xor}
-% \end{figure}
-% 
-% \clearpage
-% \subsection { Logical IMPLICATION example }
-% 
-% 
-% An implication $a \rightarrow b$ is represented by diagram \ref{fig:ld_imp}.
-% The Equations represented are as follows.
-% 
-% Looking at the conjuctive environment of the test cases
-% $$P = (\neg a)$$
-% $$Q = (b)$$
-% From the joining `disjunctive' line R in the diagram.
-% $$R = P \vee Q$$
-% Leading to
-% $$R = (\neg a) \vee (b)$$
-% which is the standard logic equation for implication.
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0 0 450 404]{ldimp.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.4]{ldimp.eps}
-% \caption{Logical Implication}
-% \label{fig:ld_imp}
-% \end{figure}
-% 
-% \tiny
-% %\vspace{0.3cm}
-% \begin{tabular}{||c|c|c|c||} \hline \hline
-% 
-%   {\em $a$ }  & {\em $b$ } &  {implication \em $(\neg a) \vee (b) $  }      \\ \hline
-%       F         &  F  &    T     \\ \hline
-%       F         &  T  &    T     \\ \hline
-%       T         &  F  &    F     \\ \hline
-%       T         &  T  &    T     \\ \hline \hline
-% \end{tabular}
-% %\vspace{0.3cm}
-% \normalsize
-% 
-% \clearpage
-% \subsection { Diagram representing several Logic Equations Example }
-% 
-% 
-% bb=0 0 450 404
-% 
-% 
-% \begin{figure}[h+]
-% %\centering
-% %\input{millivolt_sensor.tex}
-% \begin{center}
-%  \includegraphics[width=200pt,bb=0pt 0pt 600pt 600pt]{ldmeq.eps}
-%  % resistor_pld.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 450 404
-% \end{center}
-% %\includegraphics[scale=0.4]{ldmeq.eps}
-% \caption{Several Logical Expressions}
-% \label{fig:ld_meq}
-% \end{figure}
-% 
-% %The effect of using explicit negation, means that a test case being outside a given contour does not imply negation, it implies a `don't care'
-% %condition.
-% 
-% Three simple equations are represented in the  diagram \ref{fig:ld_dc}.
-% 
-% %The Set of contours $\mho$ represent the `don't care' conditions.
-% 
-% The Equations represented are as follows.
-% 
-% %$$ Q = a \; | \; \mho\{b,c\} $$
-% 
-% %$$ P = b \wedge c \; | \; \mho\{a\} $$
-% 
-% $$ Q = a $$
-% $$ P = b \wedge c $$
-% $$ R = b \vee c $$
-% 
-% % XXXXXX gives annoying impossible to understand syntax messages
-% %\small
-% %\bibliography{vmgbibliography,mybib}
-% %\bibliography{vmgbibliography}
-% %\normalsize
-% 
-\section{Intended use in FMMD}
-
-The intention for these diagrams is that they are used to collect
-component faults and combinations thereof, into faults that,
-at the module level have the same symptoms.
-
-\subsection{Example Sub-system}
-
-For instance were a `power supply' being analysed there could be several
-individual component faults or combinations that lead to
-a situation where there is no power. This can be described as a state 
-of the powersupply being modeelled as NO\_POWER.
-These can all be collected by  DISJUCNTION, i.e. that this this or this
-fault occuring will cause the NO\_POWER fault. Visually this disjuction is
-indicated by the joining lines.
-As far as the user of the `power supply' is concerned, the power supply has failed
-with the failure mode $NO\_POWER$.
-The `power supply' module, after this process will have a defined set of
-fault modes and may be considered as a component at a higher
-level of abstraction. This module can then be combined 
-with others at the same abstraction level.
-Note that because this is a fault collection process 
-the number of component faults for a module
-must be less than or equal to the sum of the number of component faults.
-
-%Typeset in \ \ {\huge \LaTeX} \ \ on \ \  \today 
-
-\begin{verbatim}
-CVS Revision Identity $Id: logic_diagram.tex,v 1.17 2010/01/06 13:41:32 robin Exp $
-\end{verbatim}
-Compiled last \today
-%\end{document}
-
-%\theend
-
-
-

logic_diagram/paper.aux

@@ -1,32 +0,0 @@
-\relax 
-\citation{FMEA}
-\citation{takeup}
-\citation{FMEA}
-\citation{SIL}
-\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
-\@writefile{toc}{\contentsline {section}{\numberline {2}Formal Description of PLD}{1}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Concrete PLD Definition}{2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.2} PLD Definition}{2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Semantics of PLD}{3}}
-\newlabel{FMGderivation}{{9}{3}}
-\@writefile{toc}{\contentsline {section}{\numberline {3}Example Diagrams}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}How to read a PLD diagram}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.2} Logical AND example }{4}}
-\newlabel{fig:ld_and}{{3.2}{4}}
-\@writefile{toc}{\contentsline {paragraph}{How this would be interpreted in failure analysis}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.3} Logical OR example }{5}}
-\newlabel{fig:ld_or}{{3.3}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Labels and useage}{6}}
-\newlabel{fig:ld_meq2}{{3.4}{6}}
-\@writefile{toc}{\contentsline {paragraph}{How this would be interpreted in failure analysis}{6}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.5} Repeated Contour example }{7}}
-\newlabel{fig:repeat}{{3.5}{7}}
-\@writefile{toc}{\contentsline {paragraph}{How this would be interpreted in failure analysis}{7}}
-\citation{wdycwopt}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.6} Inhibit Failure }{8}}
-\newlabel{fig:inhibit}{{3.6}{8}}
-\@writefile{toc}{\contentsline {paragraph}{How this would be interpreted in failure analysis}{8}}
-\bibstyle{plain}
-\bibdata{vmgbibliography,mybib}
-\@writefile{toc}{\contentsline {section}{\numberline {4}Intended use in FMMD}{9}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Example Sub-system}{9}}

logic_diagram/repeated.fig

@@ -1,27 +0,0 @@
-#FIG 3.2  Produced by xfig version 3.2.5
-Landscape
-Center
-Metric
-A4      
-100.00
-Single
--2
-1200 2
-5 1 0 1 0 7 50 -1 -1 0.000 0 1 0 0 5173.463 2296.817 3555 2430 5310 3915 6795 2385
-5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 6772.500 3082.500 5715 2070 6840 1620 7830 2070
-1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1980 2205 1011 1011 1980 2205 2835 2745
-1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3150 2205 1028 1028 3150 2205 4095 2610
-1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 6255 2070 1070 1070 6255 2070 7245 2475
-1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 7515 2115 1138 1138 7515 2115 8595 2475
-4 0 0 50 -1 0 12 0.0000 4 75 105 2430 2520 *\001
-4 0 0 50 -1 0 12 0.0000 4 75 105 6795 2340 *\001
-4 0 0 50 -1 0 12 0.0000 4 75 105 7785 2340 *\001
-4 0 0 50 -1 0 12 0.0000 4 75 105 5670 2340 *\001
-4 0 0 50 -1 0 12 0.0000 4 75 105 3510 2385 *\001
-4 0 0 50 -1 0 12 0.0000 4 135 135 1620 1035 A\001
-4 0 0 50 -1 0 12 0.0000 4 135 135 2970 945 B\001
-4 0 0 50 -1 0 12 0.0000 4 135 135 5985 810 A\001
-4 0 0 50 -1 0 12 0.0000 4 135 135 7515 810 C\001
-4 0 0 50 -1 0 12 0.0000 4 135 240 4770 3690 R1\001
-4 0 0 50 -1 0 12 0.0000 4 135 240 5985 1800 R2\001
-4 0 0 50 -1 0 12 0.0000 4 135 240 2340 2160 R3\001

pt100/Makefile

@@ -0,0 +1,17 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex pt100_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	okular paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+pt100_paper.tex: pt100.tex
+	cat pt100.tex | sed 's/pt100\///' > pt100_paper.tex

pt100/paper.tex

@@ -0,0 +1,27 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{../style}
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+\outerhead{{\small\bf PT100 FMMD analysis}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{PT100 FMMD analysis}
+\maketitle 
+\input{pt100_paper}
+
+\bibliographystyle{plain}
+\bibliography{vmgbibliography,mybib}
+
+\today
+\end{document}

pt100/pt100.tex

@@ -3,21 +3,22 @@
 
 \begin{abstract}
 The PT100, or platinum wire \ohms{100} sensor is 
-a wisely used industrial temperature sensor that is
+a widely used industrial temperature sensor that is
-are slowly replacing the use of thermocouples in many 
+slowly replacing the use of thermocouples in many 
 industrial applications below 600\oc, due to high accuracy\cite{aoe}.
 
 This chapter looks at the most common configuration, the 
 four wire circuit, and analyses it from an FMEA perspective twice.
 Once considering single faults (cardinality constrained powerset of 1) and then again, considering the 
-possibility of double simultaneous faults (cardinality constrained powerset of 2).
+possibility of double faults (cardinality constrained powerset of 2).
 
 The analysis is performed using Propositional Logic
-diagrasms to aid in the reasoning process, which takes
+diagrams to assist the reasoning process.
-the failure modes of the components, and produces a 
+This chapter describes taking
-failure mode model for the circuit as a whole.
+the failure modes of the components, analysing the circuit using FMEA
+and producing a failure mode model for the circuit as a whole.
 Thus after the analysis the PT100 temperature sensing circuit, may be veiwed 
-from an FMEA persepective as a component itsself, with a set of know failure modes.
+from an FMEA persepective as a component itself, with a set of known failure modes.
 
 \end{abstract}
 
@@ -33,10 +34,11 @@ from an FMEA persepective as a component itsself, with a set of know failure mod
 
 \section{Overview of PT100 four wire circuit}
 
-The PT100 four wire circuit consists of teo resistors supplying 
+The PT100 four wire circuit uses two wires to supply small electrical current,
-a current to a third, the thermistor or PT100. By measuring volatges
+and returns two sense volages by the other two.
+By measuring volatges
 from sections of this circuit forming potential dividers, we can determine the 
-current resistance of the platinum wire sensor. The resistance
+resistance of the platinum wire sensor. The resistance
 of this is directly related to temperature, and may be determined by
 look-up tables or a suitable polynomial expression.
 
@@ -50,28 +52,31 @@ look-up tables or a suitable polynomial expression.
 \end{figure}
 
 
-
+The voltage ranges we expect from this three stage potential divider
-
-The voltage ranges we expect from from this three stage potential divider
 are shown in figure \ref{fig:pt100vrange}. Note that there is
-an expected range for each reading for a given temperature span.
+an expected range for each reading, for a given temperature span.
 Note that the low reading goes down as temperature increases, and the higher reading goes up.
 For this reason the low reading will be reffered to as {\em sense-}
 and the higher as {\em sense+}.
 
-\subsection{Accuracy despite variable resistance in cables}
+\subsection{Accuracy despite variable \\ resistance in cables}
 
-For electronic and accuracy reasons the four wire circiut is used
+For electronic and accuracy reasons a four wire circuit is preffered
-because of resistance in the cables. Resitance from the supply
+because of resistance in the cables. Resistance from the supply
  causes a slight voltage 
 drop in the supply to the PT100. As no significant current
 is carried by the two `sense' lines the resistance back to the ADC
-causes only a negligible voltage drop. The current flowing though the 
+causes only a negligible voltage drop, and thus the four wire 
+configuration is more accurate. 
+
+\subsection{Calculating Temperature from \\ the sense line voltages}
+
+The current flowing though the 
 whole circuit can be measured on the PCB by reading a third
 sense voltage from one of the load resistors. Knowing the current flowing
 through the circuit   
 and knowing the voltage drop over the PT100, we can calculate its 
-resistance  by ohms law $V=I.R$, $R=\frac{I}{V}$. 
+resistance  by ohms law $V=I.R$, $R=\frac{V}{I}$. 
 Thus a little loss of supply current due to resistance in the cables
 does not impinge on accuracy.
 The resistance to temperature conversion is achieved 
@@ -82,7 +87,7 @@ through the published PT100 tables\cite{eurothermtables}.
 This sub-section looks at the behaviour of the PT100 four wire circuit 
 for the effects of component failures.
 All components have a set of known `failure modes'.
-In other words we know that a given component can fail in several distict ways.
+In other words we know that a given component can fail in several distinct ways.
 Studies have been published which list common component types 
 and their sets of failure modes, often with MTTF statistics \cite{mil1991}.
 Thus for each component, an analysis is made for each of it failure modes,
@@ -95,17 +100,17 @@ Where this occurs a circuit re-design is probably the only sensible course of ac
 
 
 
-\subsection{Single Fault FMEA Analysis of PT100 Four wire circuit}
+\subsection{Single Fault FMEA Analysis \\ of PT100 Four wire circuit}
 
 \label{fmea}
-Looking at this circuit, it simply consists of three resistors.
+This circuit simply consists of three resistors.
 Resistors according to the DOD Electronic component fault handbook
 1991, fail by either going OPEN or SHORT circuit \cite{mil1991}.
 %Should wires become disconnected these will have the same effect as
 %given resistors going open. 
-For the purpose of his analyis;
+For the purpose of this analyis;
 $R_{1}$ is the \ohms{2k2} from 5V to the thermistor,
-$R_p$ is the PT100 thermistor and $R_{2}$ connects the thermistor to ground.
+$R_3$ is the PT100 thermistor and $R_{2}$ connects the thermistor to ground.
 
 We can define the terms `High Fault' and `Low Fault' here, with reference to figure
 \ref{fig:pt100vrange}. Should we get a reading outside the safe green zone
@@ -113,10 +118,11 @@ in the diagram we can consider this a fault.
 Should the reading be above its expected range this is a `High Fault'
 and if below a `Low Fault'.
 
-The Table \ref{ptfmea} plays through the scenarios of each of the resistors failing
+Table \ref{ptfmea} plays through the scenarios of each of the resistors failing
-in both SHORT and OPEN failure modes, and predicts an error condition in the readings.
+in both SHORT and OPEN failure modes, and hypothesises an error condition in the readings.
-The range 0\oc to 300\oc will be analysed using potential divider equations to 
+The range {0\oc} to {300\oc} will be analysed using potential divider equations to 
-to the out of range voltage limits in section \ref{ptbounds}.
+determine out of range voltage limits in section \ref{ptbounds}.
+
 \begin{table}[ht]
 \caption{PT100 FMEA Single Faults} % title of Table
 \centering % used for centering table
@@ -130,8 +136,8 @@ to the out of range voltage limits in section \ref{ptbounds}.
  $R_1$ SHORT    &  High Fault        &  -       &  Value Out of Range Value \\ \hline
 $R_1$  OPEN     &  Low Fault         & Low Fault     &  Both values out of range \\ \hline
  \hline
-$R_p$  SHORT    &  Low Fault          & High Fault      &   Both values out of range \\ \hline
+$R_3$  SHORT    &  Low Fault          & High Fault      &   Both values out of range \\ \hline
- $R_p$  OPEN     &  High Fault         & Low  Fault    &  Both values out of range \\ \hline
+ $R_3$  OPEN     &  High Fault         & Low  Fault    &  Both values out of range \\ \hline
 \hline
 $R_2$ SHORT     &  -         &  Low Fault   &  Value Out of Range Value \\  
  $R_2$ OPEN     &  High Fault         & High Fault     &  Both values out of range \\ \hline
@@ -141,26 +147,21 @@ $R_2$ SHORT     &  -         &  Low Fault   &  Value Out of Range Value \\
 \end{table}
 
 From table \ref{ptfmea} it can be seen that any component failure in the circuit
-will cause a common symptom, that of one or more of the values being out of range.
+should cause a common symptom, that of one or more of the values being `out of range'.
 Temperature range calculations and detailed calculations
 on the effects of each test case are found in section \ref{pt100range}
-and \ref{pt100temp}. So by defining an acceptable measurement/temperature range, and ensuring the 
+and \ref{pt100temp}. 
-values are always within these bounds we can be confident that none of the
-resistors in this circuit has failed.
 
 
-\subsection{Single Fault Modes as PLD}
-
-% Place in PLD diagram
 
 \subsection{Range and PT100 Calculations}
 \label{pt100temp}
 PT100 resistors are designed to 
-have a resistance of ohms{100}  at 0 \oc \cite{eurothermtables}.
+have a resistance of \ohms{100}  at {0\oc} \cite{aoe},\cite{eurothermtables}.
 A suitable `wider than to be expected range' was considered to be {0\oc} to {300\oc}
 for a given application. 
 According to the Eurotherm PT100
-tables \cite{eurothermtables}, this corresponded to the resistances \ohms{60.28}
+tables \cite{eurothermtables}, this corresponded to the resistances \ohms{100}
 and \ohms{212.02} respectively. From this the potential divider circuit can be
 analysed and the maximum and minimum acceptable voltages determined.
 These can be used as bounds results to apply the findings from the 
@@ -169,8 +170,13 @@ PT100 FMEA analysis in section \ref{fmea}.
 As the PT100 forms a potential divider with the \ohms{2k2}  load resistors,
 the upper and lower readings can be calculated thus:
 
+
 $$ highreading = 5V.\frac{2k2+pt100}{2k2+2k2+pt100} $$
 $$ lowreading = 5V.\frac{2k2}{2k2+2k2+pt100} $$
+So by defining an acceptable measurement/temperature range,
+and ensuring the 
+values are always within these bounds we can be confident that none of the
+resistors in this circuit has failed.
 
 To convert these to twelve bit ADC (\adctw) counts:
 
@@ -201,18 +207,61 @@ Table \ref{ptbounds} gives ranges that determine correct operation. In fact it c
 for any single error (short or opening of any resistor) this bounds check
 will detect it.
 
-\subsection{Proof of Out of Range Values for Failures}
+
+\section{Single Fault FMEA Analysis \\ of PT100 Four wire circuit}
+
+\subsection{Single Fault Modes as PLD}
+
+The component~failure~modes in table \ref{ptfmea} can be represented as contours
+on a PLD diagram. 
+Each test case, is defined by the contours that enclose
+it. The test cases here deal with single faults only
+and are thus enclosed by one contour each.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./pt100/pt100_tc.jpg}
+ % pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365
+ \caption{PT100 Component Failure Modes}
+ \label{fig:pt100_tc}
+\end{figure}
+
+This circuit supplies two results, sense+ and sense- voltage readings.
+To establish the valid voltage ranges for these, and knowing our
+valid temperature range for this example ({0\oc} .. {300\oc}) we can calculate
+valid voltage reading ranges by using the standard voltage divider equation \ref{eqn:vd}
+for the circuit shown in figure \ref{fig:vd}.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=100pt,bb=0 0 183 170,keepaspectratio=true]{./pt100/voltage_divider.png}
+ % voltage_divider.png: 183x170 pixel, 72dpi, 6.46x6.00 cm, bb=0 0 183 170
+ \caption{Voltage Divider}
+ \label{fig:vd}
+\end{figure}
+%The looking at figure \ref{fig:vd} the standard voltage divider formula (equation \ref{eqn:vd}) is used.
+
+\begin{equation}
+\label{eqn:vd}
+ V_{out} = V_{in}.\frac{Z2}{Z2+Z1}
+\end{equation}
+
+
+
+\subsection{Proof of Out of Range \\ Values for Failures}
 \label{pt110range}
 Using the temperature ranges defined above we can compare the voltages
 we would get from the resistor failures to prove that they are
-`out of range'. There are six cases and each will be examined in turn.
+`out of range'. There are six test cases and each will be examined in turn.
 
-\subsubsection{ Voltages $R_1$ SHORT } 
+\subsubsection{ TC1 : Voltages $R_1$ SHORT } 
 With pt100 at 0\oc 
 $$ highreading = 5V $$
 Since the highreading or sense+ is directly connected to the 5V rail,
 both temperature readings will be 5V..
-$$ lowreading = 5V.\frac{2k2}{2k2+68\Omega} = 4.85V$$
+$$ lowreading = 5V.\frac{2k2}{2k2+100\Omega} = 4.78V$$
 With pt100 at the high end of the temperature range 300\oc.
 $$ highreading = 5V $$
 $$ lowreading = 5V.\frac{2k2}{2k2+212.02\Omega} = 4.56V$$
@@ -220,13 +269,33 @@ $$ lowreading = 5V.\frac{2k2}{2k2+212.02\Omega} = 4.56V$$
 Thus with $R_1$ shorted both readingare outside the 
 proscribed range in table \ref{ptbounds}.
 
-\subsubsection{ Voltages $R_1$ OPEN } 
+\subsubsection{ TC2 : Voltages $R_1$ OPEN } 
 
 In this case the 5V rail is disconnected. All voltages read are 0V, and 
 therefore both readings are outside the
 proscribed range in table \ref{ptbounds}.
 
-\subsubsection{ Voltages $R_p$ SHORT } 
+
+\subsubsection{ TC 3 : Voltages $R_2$ SHORT }
+
+With pt100 at 0\oc 
+$$ lowreading = 0V $$
+Since the lowreading or sense- is directly connected to the 0V rail,
+both temperature readings will be 0V.
+$$ lowreading = 5V.\frac{100\Omega}{2k2+100\Omega} = 0.218V$$
+With pt100 at the high end of the temperature range 300\oc.
+$$ highreading = 5V $$
+$$ lowreading = 5V.\frac{212.02\Omega}{2k2+212.02\Omega} = 0.44V$$
+
+Thus with $R_2$ shorted both readings are outside the 
+proscribed range in table \ref{ptbounds}.
+
+\subsubsection{ TC : 4 Voltages $R_2$ OPEN }
+Here there is no potential divider operating and both sense lines
+will read 5V, outside of the proscribed range.
+
+
+\subsubsection{ TC 5 : Voltages $R_3$ SHORT } 
 
 Here the potential divider is simply between
 the two 2k2 load resistors. Thus it will read a nominal;
@@ -242,85 +311,124 @@ $$ 5V.\frac{2k2*1.01}{2k2*1.01+2k2*0.99} = 2.525V $$
 These readings both lie outside the proscribed range.
 Also the sense+ and sense- readings would have the same value.
 
-\subsubsection{ Voltages $R_p$ OPEN } 
+\subsubsection{ TC 6 : Voltages $R_3$ OPEN } 
 
 Here the potential divider is broken. The sense- will read 0V and the sense+ will
 read 5V. Both readings are outside the proscribed range.
 
-\subsubsection{ Voltages $R_2$ SHORT }
+\subsection{Summary of Analysis}
 
-With pt100 at -100\oc 
+All six test cases have been analysed and the results agree with the hypothesis
-$$ lowreading = 0V $$
+put in  Table \ref{ptfmea}. The PLD diagram, can now be used to collect the
-Since the lowreading or sense- is directly connected to the 0V rail,
+symptoms. In this case there is a common and easily detected symptom for all these single 
-both temperature readings will be 0V.
+resistor faults :  Voltage out of range.
-$$ lowreading = 5V.\frac{68\Omega}{2k2+68\Omega} = 0.15V$$
-With pt100 at the high end of the temperature range 300\oc.
-$$ highreading = 5V $$
-$$ lowreading = 5V.\frac{212.02\Omega}{2k2+212.02\Omega} = 0.44V$$
 
-Thus with $R_2$ shorted both readingare outside the 
+A spider can be drawn on the PLD diagram to this effect.
-proscribed range in table \ref{ptbounds}.
-\subsubsection{ Voltages $R_2$ OPEN }
-Here there is no potential divider operating and both sense lines
-will read 5V, outside of the proscibed range.
 
-%\vbox{
+In practical use, by defining an acceptable measurement/temperature range,
-%\subsubsection{Calculating Bounds: High Value : HP48 RPL}
+and ensuring the 
-%
+values are always within these bounds we can be confident that none of the
-%
+resistors in this circuit has failed.
-%HP RPL calculator program to take pt100 resistance
-%and convert to voltage and {\adctw} values.
-%
-%\begin{verbatim}
-%<< -> p 
-%        <<
-%            p 2200 + 2200 2200 + p + / 5 * DUP 5
-%            / 4096 *
-%        >>
-%>>
-%\end{verbatim}
-%}
-%
-%\vbox{
-%\subsubsection{Calculating Bounds: LOW Value : HP48 RPL}
-%
-%
-%HP RPL calculator program to take pt100 resistance
-%and convert to voltage and {\adctw} values.
-%
-%\begin{verbatim}
-%<< -> p 
-%        <<
-%            p 2200 2200  p 2200 + + / 5 * DUP 5
-%            / 4096 *
-%        >>
-%>>
-%\end{verbatim}
-%}
-%
-%\subsection{Implementation of Four Wire Circuit}
-%
-%A standard 4 wire PT100\cite[pp 992]{aoe} circuit is read by 
-%ports on the 12 bit ADC of the PIC18F2523\cite{pic18f2523}.
-%Three readings are taken. A reading to confirm the voltage level
-%over $R_2$ is taken,
-%from which the current can be determined.
-%The two sense lines then give the voltage over the PT100 thermistor.
-%As we know the current flowing through it we can determine the 
-%resistance.
-%
-%After verification (PT100 voltages/readings in range etc) the temperature
-%value is determined by interpolation via the PT100 tables \cite{eurothermtables}.
-%First order low pass filtering is then applied to smooth the value.
-%\section{Water Level Readings - \ft Inputs}
-%\label{wl}
-%After h/w revision 0.4, water level sensor \ft connections are wired to the TDS daughterboard,
-%but are passed to the main unit via a multiplexer, and connect to the
-%14 pin harwin (to PIN 13 of JP1 \cite{pcbAI222562}).
-%
-%The safety critical \ft water~level readings are thus handled in the \wlc.
-%
 
-\subsection{Single Fault FMEA Analysis of PT100 Four wire circuit}
+
-typeset in {\Huge \LaTeX} \today
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./pt100/pt100_tc_sp.jpg}
+ % pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365
+ \caption{PT100 Component Failure Modes}
+ \label{fig:pt100_tc_sp}
+\end{figure}
+
+
+The PT100 circuit can now be treated as a component in its own right, and has one failure mode, 
+{\textbf OUT\_OF\_RANGE}. It can now be represnted as a PLD see figure \ref{fig:pt100_singlef}.
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=100pt,bb=0 0 167 194,keepaspectratio=true]{./pt100/pt100_singlef.jpg}
+ % pt100_singlef.jpg: 167x194 pixel, 72dpi, 5.89x6.84 cm, bb=0 0 167 194
+ \caption{PT100 Circuit Failure Modes : From Single Faults Analysis}
+ \label{fig:pt100_singlef}
+\end{figure}
+
+
+
+
+%Interestingly we can calculate the failure statistics for this circuit now.
+%Mill 1991 gives resistor stats of ${10}^{11}$ times 6 (can we get special stats for pt100) ???
+\clearpage
+\subsection{Mean Time to Failure}
+
+Using the MIL1991\cite{mil1991} specifications for resistor and thermistor
+failure statistics we calculate the reliability of this circuit.
+MIL1991 gives MTTF for a wide range of common components.
+It does not specify how the components will fail (in this case OPEN or SHORT). {Some standards, notably EN298 only consider resistors failing in OPEN mode}.
+FMD-97 Gives 27\% OPEN and 3\% SHORTED, for resistors under certain electrical and environmental stresses. This example 
+compromises and uses a 90:10 ratio, for resistor failure. 
+Thus for this example resistors are expevcted to fail OPEN in 90\% of cases and SHORTED 
+in the other 10\%.
+
+A standard fixed film resistor, for use in a benign environment, non military spec at
+temperatures up to 60\oc is given a probability of 13.8 failures per billion ($10^9$)
+hours of operation. This figure is referred to as a FIT\footnote{FIT values are measured as the number of failures per billion hours of operation, (roughly 1.1 Million years). The smaller the FIT number the more reliable the fault~mode}, Failure in time.
+
+A thermistor, bead type, non military spec is given a FIT of 3150.
+
+Using the RIAC finding we can draw up the following table (table \ref{tab:stat_single}),
+showing the FIT values for all faults considered.
+
+
+
+\begin{table}[h+]
+\caption{PT100 FMEA Single // Fault Statistics} % title of Table
+\centering % used for centering table
+\begin{tabular}{||l|c|c|l|l||}
+\hline \hline
+ \textbf{Test} & \textbf{Result} & \textbf{Result } & \textbf{MTTF}   \\
+ \textbf{Case} &  \textbf{sense +} & \textbf{sense -} & \textbf{per $10^9$ hours of operation}   \\
+%   R         &    wire        & res +         & res -    & description
+\hline
+\hline
+TC:1 $R_1$ SHORT    &  High Fault        &  -       &  12.42 \\ \hline
+TC:2 $R_1$  OPEN     &  Low Fault         & Low Fault     &  1.38 \\ \hline
+ \hline
+TC:3 $R_3$  SHORT    &  Low Fault          & High Fault      &   2835 \\ \hline
+TC:4 $R_3$  OPEN     &  High Fault         & Low  Fault    &   315 \\ \hline
+\hline
+TC:5 $R_2$ SHORT     &  -         &  Low Fault   &  12.42 \\  
+TC:6 $R_2$ OPEN     &  High Fault         & High Fault     &  1.38 \\ \hline
+\hline
+\end{tabular} 
+\label{tab:stat_single}
+\end{table}
+
+The FIT for the circuit as a whole is the sum of MTTF values for all the 
+test cases. The PT100 circuit here has a  FIT of 3177.6. This is a MTTF of
+about 360 years per circuit.
+
+A Probablistic tree can now be drawn, with a FIT value for the PT100
+circuit and FIT values for all the component fault modes that it was calculated from.
+We can see from this that that the most likely fault is the thermistor going OPEN.
+This circuit is 8 times more likely to fail in this way than in any other.
+Were we to need a more reliable temperature sensor this would probably 
+be the fault~mode we would scrutinise first.
+
+
+\begin{figure}[h+]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 856 327,keepaspectratio=true]{./pt100/stat_single.jpg}
+ % stat_single.jpg: 856x327 pixel, 72dpi, 30.20x11.54 cm, bb=0 0 856 327
+ \caption{Probablistic Fault Tree : PT100 Single Faults}
+ \label{fig:stat_single}
+\end{figure}
+
+
+The PT100 analysis presents a simple result for single faults. 
+The next analysis phase looks at how the circuit will behave under double simultaneous failure
+conditions.
+
+\clearpage
+\section{ PT100 Double Simultaneous \\ Fault Analysis}
+
+% typeset in {\Huge \LaTeX} \today
 

standards/Makefile

@@ -0,0 +1,17 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex standards_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	okular paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+standards_paper.tex: standards.tex
+	cat standards.tex | sed 's/standards\///' > standards_paper.tex

standards/paper.aux

@@ -0,0 +1,11 @@
+\relax 
+\bibstyle{plain}
+\bibdata{vmgbibliography,mybib}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}European Safety Standards Legal Framework}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}North American Legal Framework}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Cross Referencing}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}EN298}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}UL1998}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {7}EN230}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {8}EN61508}{1}}

standards/paper.log

@@ -1,11 +1,11 @@
-This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2009.7.3)  9 JAN 2010 08:58
+This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) (format=pdflatex 2010.2.1)  4 APR 2010 13:40
 entering extended mode
  %&-line parsing enabled.
 **paper.tex
 (./paper.tex
 LaTeX2e <2005/12/01>
 Babel <v3.8h> and hyphenation patterns for english, usenglishmax, dumylang, noh
-yphenation, ukrainian, russian, bulgarian, loaded.
+yphenation, loaded.
 (/usr/share/texmf-texlive/tex/latex/base/article.cls
 Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
 (/usr/share/texmf-texlive/tex/latex/base/size10.clo
@@ -354,7 +354,7 @@ Package: amsthm 2004/08/06 v2.20
 \thm@postskip=\skip56
 \thm@headsep=\skip57
 \dth@everypar=\toks31
-) (./style.tex
+) (../style.tex
 LaTeX Font Info:    Redeclaring symbol font `AMSb' on input line 34.
 LaTeX Font Info:    Overwriting symbol font `AMSb' in version `normal'
 (Font)                  U/msb/m/n --> U/msb/m/n on input line 34.
@@ -402,140 +402,28 @@ LaTeX Font Info:    Try loading font information for U+msb on input line 20.
 
 (/usr/share/texmf-texlive/tex/latex/amsfonts/umsb.fd
 File: umsb.fd 2002/01/19 v2.2g AMS font definitions
-)
+) (./standards_paper.tex)
-(./logic_diagram_paper.tex
+No file paper.bbl.
-
-LaTeX Warning: Citation `FMEA' on page 1 undefined on input line 17.
-
-
-LaTeX Warning: Citation `takeup' on page 1 undefined on input line 19.
-
-
-LaTeX Warning: Citation `FMEA' on page 1 undefined on input line 48.
-
-
-LaTeX Warning: Citation `SIL' on page 1 undefined on input line 48.
-
 [1
 
-{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2]
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./paper.aux) ) 
-LaTeX Font Info:    Try loading font information for OMS+cmr on input line 282.
-
-
-(/usr/share/texmf-texlive/tex/latex/base/omscmr.fd
-File: omscmr.fd 1999/05/25 v2.5h Standard LaTeX font definitions
-)
-LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10> not available
-(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 282.
-
-
-Package pdftex.def Warning: Option `bb' does not make sense,
-(pdftex.def)                using `viewport' instead on input line 379.
-
-<ldand.jpg, id=27, 280.04625pt x 247.92625pt>
-File: ldand.jpg Graphic file (type jpg)
- <use ldand.jpg> [3] [4 <./ldand.jpg>]
-
-Package pdftex.def Warning: Option `bb' does not make sense,
-(pdftex.def)                using `viewport' instead on input line 409.
-
-<ldor.jpg, id=34, 477.785pt x 264.99pt>
-File: ldor.jpg Graphic file (type jpg)
- <use ldor.jpg>
-Overfull \hbox (22.54091pt too wide) in paragraph at lines 409--412
- [][] 
- []
-
-
-LaTeX Warning: Reference `fig:ld_or' on page 5 undefined on input line 427.
-
-[5
-
- <./ldor.jpg>]
-
-LaTeX Warning: Reference `fig:ld_meq' on page 6 undefined on input line 443.
-
-
-LaTeX Warning: Reference `fig:ld_meq' on page 6 undefined on input line 448.
-
-
-LaTeX Warning: Reference `fig:ld_meq2' on page 6 undefined on input line 448.
-
-
-Package pdftex.def Warning: Option `bb' does not make sense,
-(pdftex.def)                using `viewport' instead on input line 453.
-
-<ldmeq2.jpg, id=38, 574.145pt x 298.11375pt>
-File: ldmeq2.jpg Graphic file (type jpg)
- <use ldmeq2.jpg> [6
-
- <./ldmeq2.jpg>]
-
-Package pdftex.def Warning: Option `bb' does not make sense,
-(pdftex.def)                using `viewport' instead on input line 495.
-
-<repeated.jpg, id=42, 486.91913pt x 206.87288pt>
-File: repeated.jpg Graphic file (type jpg)
- <use repeated.jpg>
-Overfull \hbox (31.57466pt too wide) in paragraph at lines 495--498
- [][] 
- []
-
-
-LaTeX Warning: Reference `fig:repeat' on page 7 undefined on input line 509.
-
-[7
-
- <./repeated.jpg>]
-
-Package pdftex.def Warning: Option `bb' does not make sense,
-(pdftex.def)                using `viewport' instead on input line 544.
-
-<inhibit.jpg, id=47, 364.9635pt x 227.6505pt>
-File: inhibit.jpg Graphic file (type jpg)
- <use inhibit.jpg>
-
-LaTeX Warning: Reference `fig:inhibit' on page 8 undefined on input line 556.
-
-
-LaTeX Warning: Citation `wdycwopt' on page 8 undefined on input line 561.
-
-[8
-
- <./inhibit.jpg>])
-No file paper.bbl.
-[9] (./paper.aux)
-
-LaTeX Warning: There were undefined references.
-
-
-LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
-
- ) 
 Here is how much of TeX's memory you used:
- 8211 strings out of 94834
+ 8154 strings out of 95086
- 138420 string characters out of 1179182
+ 137506 string characters out of 1183256
- 186929 words of memory out of 1500000
+ 183820 words of memory out of 1500000
- 11211 multiletter control sequences out of 10000+50000
+ 11159 multiletter control sequences out of 10000+50000
- 12986 words of font info for 50 fonts, out of 1200000 for 2000
+ 9805 words of font info for 37 fonts, out of 1200000 for 2000
- 212 hyphenation exceptions out of 8191
+ 28 hyphenation exceptions out of 8191
- 47i,11n,49p,350b,269s stack positions out of 5000i,500n,6000p,200000b,5000s
+ 47i,6n,49p,350b,196s stack positions out of 5000i,500n,6000p,200000b,5000s
-</usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmbx10.pfb></usr/share/texmf
+</usr/share
--texlive/fonts/type1/bluesky/cm/cmbx12.pfb></usr/share/texmf-texlive/fonts/type
+/texmf-texlive/fonts/type1/bluesky/cm/cmbx12.pfb></usr/share/texmf-texlive/font
-1/bluesky/cm/cmbx9.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmex10.
+s/type1/bluesky/cm/cmbx9.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/c
-pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmmi10.pfb></usr/share/tex
+mr10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmr12.pfb></usr/share
-mf-texlive/fonts/type1/bluesky/cm/cmmi7.pfb></usr/share/texmf-texlive/fonts/typ
+/texmf-texlive/fonts/type1/bluesky/cm/cmr17.pfb></usr/share/texmf-texlive/fonts
-e1/bluesky/cm/cmr10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmr12.
+/type1/bluesky/cm/cmr9.pfb>
-pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmr17.pfb></usr/share/texm
+Output written on paper.pdf (1 page, 42142 bytes).
-f-texlive/fonts/type1/bluesky/cm/cmr7.pfb></usr/share/texmf-texlive/fonts/type1
-/bluesky/cm/cmr9.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmsl10.pf
-b></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmsy10.pfb></usr/share/texmf
--texlive/fonts/type1/bluesky/cm/cmsy7.pfb></usr/share/texmf-texlive/fonts/type1
-/bluesky/cm/cmti10.pfb></usr/share/texmf-texlive/fonts/type1/bluesky/cm/cmtt10.
-pfb></usr/share/texmf-texlive/fonts/type1/bluesky/ams/msbm10.pfb>
-Output written on paper.pdf (9 pages, 211917 bytes).
 PDF statistics:
- 108 PDF objects out of 1000 (max. 8388607)
+ 33 PDF objects out of 1000 (max. 8388607)
  0 named destinations out of 1000 (max. 131072)
- 38 words of extra memory for PDF output out of 10000 (max. 10000000)
+ 13 words of extra memory for PDF output out of 10000 (max. 10000000)
 

standards/paper.tex

@@ -0,0 +1,27 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{../style}
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+\outerhead{{\small\bf Safety Critical Standards Review}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{Safety Critical Standards Review}
+\maketitle 
+\input{standards_paper}
+
+\bibliographystyle{plain}
+\bibliography{vmgbibliography,mybib}
+
+\today
+\end{document}

standards/pt100.tex

@@ -0,0 +1,434 @@
+%
+% Make the revision and doc number macro's then they are defined in one place
+
+\begin{abstract}
+The PT100, or platinum wire \ohms{100} sensor is 
+a widely used industrial temperature sensor that is
+slowly replacing the use of thermocouples in many 
+industrial applications below 600\oc, due to high accuracy\cite{aoe}.
+
+This chapter looks at the most common configuration, the 
+four wire circuit, and analyses it from an FMEA perspective twice.
+Once considering single faults (cardinality constrained powerset of 1) and then again, considering the 
+possibility of double faults (cardinality constrained powerset of 2).
+
+The analysis is performed using Propositional Logic
+diagrams to assist the reasoning process.
+This chapter describes taking
+the failure modes of the components, analysing the circuit using FMEA
+and producing a failure mode model for the circuit as a whole.
+Thus after the analysis the PT100 temperature sensing circuit, may be veiwed 
+from an FMEA persepective as a component itself, with a set of known failure modes.
+
+\end{abstract}
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 714 180,keepaspectratio=true]{./pt100/pt100.jpg}
+ % pt100.jpg: 714x180 pixel, 72dpi, 25.19x6.35 cm, bb=0 0 714 180
+ \caption{PT100 four wire circuit}
+ \label{fig:pt100}
+\end{figure}
+
+
+\section{Overview of PT100 four wire circuit}
+
+The PT100 four wire circuit uses two wires to supply small electrical current,
+and returns two sense volages by the other two.
+By measuring volatges
+from sections of this circuit forming potential dividers, we can determine the 
+resistance of the platinum wire sensor. The resistance
+of this is directly related to temperature, and may be determined by
+look-up tables or a suitable polynomial expression.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=150pt,bb=0 0 273 483,keepaspectratio=true]{./pt100/vrange.jpg}
+ % pt100.jpg: 714x180 pixel, 72dpi, 25.19x6.35 cm, bb=0 0 714 180
+ \caption{PT100 expected voltage ranges}
+ \label{fig:pt100vrange}
+\end{figure}
+
+
+The voltage ranges we expect from this three stage potential divider
+are shown in figure \ref{fig:pt100vrange}. Note that there is
+an expected range for each reading, for a given temperature span.
+Note that the low reading goes down as temperature increases, and the higher reading goes up.
+For this reason the low reading will be reffered to as {\em sense-}
+and the higher as {\em sense+}.
+
+\subsection{Accuracy despite variable \\ resistance in cables}
+
+For electronic and accuracy reasons a four wire circuit is preffered
+because of resistance in the cables. Resistance from the supply
+ causes a slight voltage 
+drop in the supply to the PT100. As no significant current
+is carried by the two `sense' lines the resistance back to the ADC
+causes only a negligible voltage drop, and thus the four wire 
+configuration is more accurate. 
+
+\subsection{Calculating Temperature from \\ the sense line voltages}
+
+The current flowing though the 
+whole circuit can be measured on the PCB by reading a third
+sense voltage from one of the load resistors. Knowing the current flowing
+through the circuit   
+and knowing the voltage drop over the PT100, we can calculate its 
+resistance  by ohms law $V=I.R$, $R=\frac{V}{I}$. 
+Thus a little loss of supply current due to resistance in the cables
+does not impinge on accuracy.
+The resistance to temperature conversion is achieved 
+through the published PT100 tables\cite{eurothermtables}.
+
+\section{Safety case for 4 wire circuit}
+
+This sub-section looks at the behaviour of the PT100 four wire circuit 
+for the effects of component failures.
+All components have a set of known `failure modes'.
+In other words we know that a given component can fail in several distinct ways.
+Studies have been published which list common component types 
+and their sets of failure modes, often with MTTF statistics \cite{mil1991}.
+Thus for each component, an analysis is made for each of it failure modes,
+with respect to its effect on the 
+circuit. Each one of these scenarios is termed a `test case'.
+The resultant circuit behaviour for each of these test cases is noted. 
+The worst case for this type of
+analysis would be a fault that we cannot detect.
+Where this occurs a circuit re-design is probably the only sensible course of action.
+
+
+
+\subsection{Single Fault FMEA Analysis \\ of PT100 Four wire circuit}
+
+\label{fmea}
+This circuit simply consists of three resistors.
+Resistors according to the DOD Electronic component fault handbook
+1991, fail by either going OPEN or SHORT circuit \cite{mil1991}.
+%Should wires become disconnected these will have the same effect as
+%given resistors going open. 
+For the purpose of this analyis;
+$R_{1}$ is the \ohms{2k2} from 5V to the thermistor,
+$R_3$ is the PT100 thermistor and $R_{2}$ connects the thermistor to ground.
+
+We can define the terms `High Fault' and `Low Fault' here, with reference to figure
+\ref{fig:pt100vrange}. Should we get a reading outside the safe green zone
+in the diagram we can consider this a fault.
+Should the reading be above its expected range this is a `High Fault'
+and if below a `Low Fault'.
+
+Table \ref{ptfmea} plays through the scenarios of each of the resistors failing
+in both SHORT and OPEN failure modes, and hypothesises an error condition in the readings.
+The range {0\oc} to {300\oc} will be analysed using potential divider equations to 
+determine out of range voltage limits in section \ref{ptbounds}.
+
+\begin{table}[ht]
+\caption{PT100 FMEA Single Faults} % title of Table
+\centering % used for centering table
+\begin{tabular}{||l|c|c|l|l||}
+\hline \hline
+ \textbf{Test} & \textbf{Result} & \textbf{Result } & \textbf{General}   \\
+ \textbf{Case} &  \textbf{sense +} & \textbf{sense -} & \textbf{Symtom Description}   \\
+%   R         &    wire        & res +         & res -    & description
+\hline
+\hline
+ $R_1$ SHORT    &  High Fault        &  -       &  Value Out of Range Value \\ \hline
+$R_1$  OPEN     &  Low Fault         & Low Fault     &  Both values out of range \\ \hline
+ \hline
+$R_3$  SHORT    &  Low Fault          & High Fault      &   Both values out of range \\ \hline
+ $R_3$  OPEN     &  High Fault         & Low  Fault    &  Both values out of range \\ \hline
+\hline
+$R_2$ SHORT     &  -         &  Low Fault   &  Value Out of Range Value \\  
+ $R_2$ OPEN     &  High Fault         & High Fault     &  Both values out of range \\ \hline
+\hline
+\end{tabular} 
+\label{ptfmea}
+\end{table}
+
+From table \ref{ptfmea} it can be seen that any component failure in the circuit
+should cause a common symptom, that of one or more of the values being `out of range'.
+Temperature range calculations and detailed calculations
+on the effects of each test case are found in section \ref{pt100range}
+and \ref{pt100temp}. 
+
+
+
+\subsection{Range and PT100 Calculations}
+\label{pt100temp}
+PT100 resistors are designed to 
+have a resistance of \ohms{100}  at {0\oc} \cite{aoe},\cite{eurothermtables}.
+A suitable `wider than to be expected range' was considered to be {0\oc} to {300\oc}
+for a given application. 
+According to the Eurotherm PT100
+tables \cite{eurothermtables}, this corresponded to the resistances \ohms{100}
+and \ohms{212.02} respectively. From this the potential divider circuit can be
+analysed and the maximum and minimum acceptable voltages determined.
+These can be used as bounds results to apply the findings from the 
+PT100 FMEA analysis in section \ref{fmea}.
+
+As the PT100 forms a potential divider with the \ohms{2k2}  load resistors,
+the upper and lower readings can be calculated thus:
+
+
+$$ highreading = 5V.\frac{2k2+pt100}{2k2+2k2+pt100} $$
+$$ lowreading = 5V.\frac{2k2}{2k2+2k2+pt100} $$
+So by defining an acceptable measurement/temperature range,
+and ensuring the 
+values are always within these bounds we can be confident that none of the
+resistors in this circuit has failed.
+
+To convert these to twelve bit ADC (\adctw) counts:
+
+$$ highreading = 2^{12}.\frac{2k2+pt100}{2k2+2k2+pt100} $$
+$$ lowreading = 2^{12}.\frac{2k2}{2k2+2k2+pt100} $$
+
+
+\begin{table}[ht]
+\caption{PT100 Maximum and Minimum Values} % title of Table
+\centering % used for centering table
+\begin{tabular}{||c|c|c|l|l||}
+\hline \hline
+ \textbf{Temperature} & \textbf{PT100 resistance} & 
+\textbf{Lower} & \textbf{Higher} & \textbf{Description}   \\ 
+\hline
+% {-100 \oc} &  {\ohms{68.28}} &  2.46V         &   2.53V      & Boundary of   \\ 
+%            &                 &  2017\adctw   &   2079\adctw  &   out of range LOW \\ \hline
+  {0 \oc}   & {\ohms{100}}    &  2.44V         &   2.56V       & Boundary of         \\
+            &                 &  2002\adctw   &   2094\adctw   &  out of range LOW        \\ \hline
+ {+300 \oc} & {\ohms{212.02}}  &  2.38V         &   2.62V       & Boundary of                       \\
+            &                  &  1954\adctw   &   2142\adctw   &  out of range HIGH  \\ \hline
+\hline
+\end{tabular} 
+\label{ptbounds}
+\end{table}
+
+Table \ref{ptbounds} gives ranges that determine correct operation. In fact it can be shown that
+for any single error (short or opening of any resistor) this bounds check
+will detect it.
+
+
+\section{Single Fault FMEA Analysis \\ of PT100 Four wire circuit}
+
+\subsection{Single Fault Modes as PLD}
+
+The component~failure~modes in table \ref{ptfmea} can be represented as contours
+on a PLD diagram. 
+Each test case, is defined by the contours that enclose
+it. The test cases here deal with single faults only
+and are thus enclosed by one contour each.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./pt100/pt100_tc.jpg}
+ % pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365
+ \caption{PT100 Component Failure Modes}
+ \label{fig:pt100_tc}
+\end{figure}
+
+This circuit supplies two results, sense+ and sense- voltage readings.
+To establish the valid voltage ranges for these, and knowing our
+valid temperature range for this example ({0\oc} .. {300\oc}) we can calculate
+valid voltage reading ranges by using the standard voltage divider equation \ref{eqn:vd}
+for the circuit shown in figure \ref{fig:vd}.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=100pt,bb=0 0 183 170,keepaspectratio=true]{./pt100/voltage_divider.png}
+ % voltage_divider.png: 183x170 pixel, 72dpi, 6.46x6.00 cm, bb=0 0 183 170
+ \caption{Voltage Divider}
+ \label{fig:vd}
+\end{figure}
+%The looking at figure \ref{fig:vd} the standard voltage divider formula (equation \ref{eqn:vd}) is used.
+
+\begin{equation}
+\label{eqn:vd}
+ V_{out} = V_{in}.\frac{Z2}{Z2+Z1}
+\end{equation}
+
+
+
+\subsection{Proof of Out of Range \\ Values for Failures}
+\label{pt110range}
+Using the temperature ranges defined above we can compare the voltages
+we would get from the resistor failures to prove that they are
+`out of range'. There are six test cases and each will be examined in turn.
+
+\subsubsection{ TC1 : Voltages $R_1$ SHORT } 
+With pt100 at 0\oc 
+$$ highreading = 5V $$
+Since the highreading or sense+ is directly connected to the 5V rail,
+both temperature readings will be 5V..
+$$ lowreading = 5V.\frac{2k2}{2k2+100\Omega} = 4.78V$$
+With pt100 at the high end of the temperature range 300\oc.
+$$ highreading = 5V $$
+$$ lowreading = 5V.\frac{2k2}{2k2+212.02\Omega} = 4.56V$$
+
+Thus with $R_1$ shorted both readingare outside the 
+proscribed range in table \ref{ptbounds}.
+
+\subsubsection{ TC2 : Voltages $R_1$ OPEN } 
+
+In this case the 5V rail is disconnected. All voltages read are 0V, and 
+therefore both readings are outside the
+proscribed range in table \ref{ptbounds}.
+
+
+\subsubsection{ TC 3 : Voltages $R_2$ SHORT }
+
+With pt100 at 0\oc 
+$$ lowreading = 0V $$
+Since the lowreading or sense- is directly connected to the 0V rail,
+both temperature readings will be 0V.
+$$ lowreading = 5V.\frac{100\Omega}{2k2+100\Omega} = 0.218V$$
+With pt100 at the high end of the temperature range 300\oc.
+$$ highreading = 5V $$
+$$ lowreading = 5V.\frac{212.02\Omega}{2k2+212.02\Omega} = 0.44V$$
+
+Thus with $R_2$ shorted both readings are outside the 
+proscribed range in table \ref{ptbounds}.
+
+\subsubsection{ TC : 4 Voltages $R_2$ OPEN }
+Here there is no potential divider operating and both sense lines
+will read 5V, outside of the proscribed range.
+
+
+\subsubsection{ TC 5 : Voltages $R_3$ SHORT } 
+
+Here the potential divider is simply between
+the two 2k2 load resistors. Thus it will read a nominal;
+2.5V.
+
+Assuming the load resistors are 
+precision components, and then taking an absolute worst case of 1\% either way.
+
+$$ 5V.\frac{2k2*0.99}{2k2*1.01+2k2*0.99} = 2.475V $$
+
+$$ 5V.\frac{2k2*1.01}{2k2*1.01+2k2*0.99} = 2.525V $$
+
+These readings both lie outside the proscribed range.
+Also the sense+ and sense- readings would have the same value.
+
+\subsubsection{ TC 6 : Voltages $R_3$ OPEN } 
+
+Here the potential divider is broken. The sense- will read 0V and the sense+ will
+read 5V. Both readings are outside the proscribed range.
+
+\subsection{Summary of Analysis}
+
+All six test cases have been analysed and the results agree with the hypothesis
+put in  Table \ref{ptfmea}. The PLD diagram, can now be used to collect the
+symptoms. In this case there is a common and easily detected symptom for all these single 
+resistor faults :  Voltage out of range.
+
+A spider can be drawn on the PLD diagram to this effect.
+
+In practical use, by defining an acceptable measurement/temperature range,
+and ensuring the 
+values are always within these bounds we can be confident that none of the
+resistors in this circuit has failed.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 518 365,keepaspectratio=true]{./pt100/pt100_tc_sp.jpg}
+ % pt100_tc.jpg: 518x365 pixel, 72dpi, 18.27x12.88 cm, bb=0 0 518 365
+ \caption{PT100 Component Failure Modes}
+ \label{fig:pt100_tc_sp}
+\end{figure}
+
+
+The PT100 circuit can now be treated as a component in its own right, and has one failure mode, 
+{\textbf OUT\_OF\_RANGE}. It can now be represnted as a PLD see figure \ref{fig:pt100_singlef}.
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=100pt,bb=0 0 167 194,keepaspectratio=true]{./pt100/pt100_singlef.jpg}
+ % pt100_singlef.jpg: 167x194 pixel, 72dpi, 5.89x6.84 cm, bb=0 0 167 194
+ \caption{PT100 Circuit Failure Modes : From Single Faults Analysis}
+ \label{fig:pt100_singlef}
+\end{figure}
+
+
+
+
+%Interestingly we can calculate the failure statistics for this circuit now.
+%Mill 1991 gives resistor stats of ${10}^{11}$ times 6 (can we get special stats for pt100) ???
+\clearpage
+\subsection{Mean Time to Failure}
+
+Using the MIL1991\cite{mil1991} specifications for resistor and thermistor
+failure statistics we calculate the reliability of this circuit.
+MIL1991 gives MTTF for a wide range of common components.
+It does not specify how the components will fail (in this case OPEN or SHORT). {Some standards, notably EN298 only consider resistors failing in OPEN mode}.
+FMD-97 Gives 27\% OPEN and 3\% SHORTED, for resistors under certain electrical and environmental stresses. This example 
+compromises and uses a 90:10 ratio, for resistor failure. 
+Thus for this example resistors are expevcted to fail OPEN in 90\% of cases and SHORTED 
+in the other 10\%.
+
+A standard fixed film resistor, for use in a benign environment, non military spec at
+temperatures up to 60\oc is given a probability of 13.8 failures per billion ($10^9$)
+hours of operation. This figure is referred to as a FIT\footnote{FIT values are measured as the number of failures per billion hours of operation, (roughly 1.1 Million years). The smaller the FIT number the more reliable the fault~mode}, Failure in time.
+
+A thermistor, bead type, non military spec is given a FIT of 3150.
+
+Using the RIAC finding we can draw up the following table (table \ref{tab:stat_single}),
+showing the FIT values for all faults considered.
+
+
+
+\begin{table}[h+]
+\caption{PT100 FMEA Single // Fault Statistics} % title of Table
+\centering % used for centering table
+\begin{tabular}{||l|c|c|l|l||}
+\hline \hline
+ \textbf{Test} & \textbf{Result} & \textbf{Result } & \textbf{MTTF}   \\
+ \textbf{Case} &  \textbf{sense +} & \textbf{sense -} & \textbf{per $10^9$ hours of operation}   \\
+%   R         &    wire        & res +         & res -    & description
+\hline
+\hline
+TC:1 $R_1$ SHORT    &  High Fault        &  -       &  12.42 \\ \hline
+TC:2 $R_1$  OPEN     &  Low Fault         & Low Fault     &  1.38 \\ \hline
+ \hline
+TC:3 $R_3$  SHORT    &  Low Fault          & High Fault      &   2835 \\ \hline
+TC:4 $R_3$  OPEN     &  High Fault         & Low  Fault    &   315 \\ \hline
+\hline
+TC:5 $R_2$ SHORT     &  -         &  Low Fault   &  12.42 \\  
+TC:6 $R_2$ OPEN     &  High Fault         & High Fault     &  1.38 \\ \hline
+\hline
+\end{tabular} 
+\label{tab:stat_single}
+\end{table}
+
+The FIT for the circuit as a whole is the sum of MTTF values for all the 
+test cases. The PT100 circuit here has a  FIT of 3177.6. This is a MTTF of
+about 360 years per circuit.
+
+A Probablistic tree can now be drawn, with a FIT value for the PT100
+circuit and FIT values for all the component fault modes that it was calculated from.
+We can see from this that that the most likely fault is the thermistor going OPEN.
+This circuit is 8 times more likely to fail in this way than in any other.
+Were we to need a more reliable temperature sensor this would probably 
+be the fault~mode we would scrutinise first.
+
+
+\begin{figure}[h+]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 856 327,keepaspectratio=true]{./pt100/stat_single.jpg}
+ % stat_single.jpg: 856x327 pixel, 72dpi, 30.20x11.54 cm, bb=0 0 856 327
+ \caption{Probablistic Fault Tree : PT100 Single Faults}
+ \label{fig:stat_single}
+\end{figure}
+
+
+The PT100 analysis presents a simple result for single faults. 
+The next analysis phase looks at how the circuit will behave under double simultaneous failure
+conditions.
+
+\clearpage
+\section{ PT100 Double Simultaneous \\ Fault Analysis}
+
+% typeset in {\Huge \LaTeX} \today
+

standards/standards.tex

@@ -0,0 +1,30 @@
+%
+% Make the revision and doc number macro's then they are defined in one place
+
+\begin{abstract}
+This chapter describes the legal frameworks and standards organisations
+that exist in Europe and North America.
+Some specific standards (that the author has experience with directly)
+are reviewed.
+\end{abstract}
+
+
+\section{Introduction}
+
+\section{European Safety Standards Legal Framework}
+\section{North American Legal Framework}
+
+Protection against being sued mainly ! UL - underwriters laboratories.... etc
+
+\section{Cross Referencing}
+
+Stabndards of ten reference other - i.e. EMC testing in EN298 refers toEN blah blah to level blah blah
+
+
+\section{EN298}
+
+\section{UL1998}
+
+\section{EN230}
+
+\section{EN61508}

standards/standards_paper.tex

@@ -0,0 +1,30 @@
+%
+% Make the revision and doc number macro's then they are defined in one place
+
+\begin{abstract}
+This chapter describes the legal frameworks and standards organisations
+that exist in Europe and North America.
+Some specific standards (that the author has experience with directly)
+are reviewed.
+\end{abstract}
+
+
+\section{Introduction}
+
+\section{European Safety Standards Legal Framework}
+\section{North American Legal Framework}
+
+Protection against being sued mainly ! UL - underwriters laboratories.... etc
+
+\section{Cross Referencing}
+
+Stabndards of ten reference other - i.e. EMC testing in EN298 refers toEN blah blah to level blah blah
+
+
+\section{EN298}
+
+\section{UL1998}
+
+\section{EN230}
+
+\section{EN61508}

survey/Makefile

@@ -0,0 +1,17 @@
+
+#
+# Make the propositional logic diagram a paper
+#
+
+
+paper:	paper.tex survey_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	okular paper.pdf
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+survey_paper.tex: survey.tex
+	cat survey.tex | sed 's/survey\///' > survey_paper.tex

survey/mybib.bib

@@ -0,0 +1,404 @@
+%
+%
+% $Id: mybib.bib,v 1.5 2008/12/18 17:05:23 robin Exp $
+%
+%
+
+@TechReport{db,
+ author = {R Clark, D Legge},
+ title = {ETC6000 Daughterboard Design notes},
+ institution = {ETC HR221850},
+ year = {2004},
+ key = {},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ issn = {HR221850},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@TechReport{mil1991,
+ author = {U.S. Department of Defence},
+ title = {Reliability Prediction of Electronic Equipment},
+ institution = {DOD},
+ year = {1991},
+ key = {MIL-HDBK-217F},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@Manual{tlp181,
+ title = {TLP 181 Datasheet},
+ key = {TOSHIBA Photocoupler GaAs Ired & Photo−Transistor},
+ author = {Toshiba inc.},
+ OPTorganization = {},
+ %address = {http://www.toshiba.com/taec/components2/Datasheet\_Sync//206/4191.pdf},
+ OPTedition = {},
+ OPTmonth = {},
+ year = {2009},
+OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+
+
+
+@Manual{pic18f2523,
+ title = {PIC18F2523 Datasheet},
+ OPTkey = {},
+ author = {Microchip inc},
+ OPTorganization = {},
+ address = {http://ww1.microchip.com/downloads/en/DeviceDoc/39755c.pdf},
+ OPTedition = {},
+ OPTmonth = {},
+ year = {2009},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+
+@Book{wt,
+ title = {Water Treatment Essentials for Boiler Plant Operation},
+ publisher = {Mc Graw Hill ISBN 0-07-048291-5},
+ year = {1997},
+ author = {Robert G Nunn},
+ ALTALTeditor = {},
+ OPTkey = {},
+ OPTvolume = {},
+ OPTnumber = {},
+ OPTseries = {},
+ OPTaddress = {},
+ OPTedition = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {ISBN 0-07-048291-5},
+ OPTlocalfile = {},
+ OPTabstracts = {},
+}
+
+@TechReport{pcbAI222562,
+ author = {C Talmay},
+ title = {Circuit Schematic TDS Daughterboard AI222562},
+ institution = {ETC},
+ year = {2010},
+ OPTkey = {},
+ OPTtype = {},
+ OPTnumber = {AI222562},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@TechReport{spiraxsarco,
+ author = {Spirax Sarco},
+ title = {http://www.spiraxsarco.com/resources/steam-engineering-tutorials.asp},
+ institution = {Spirax Sarco},
+ year = {2010},
+ OPTkey = {},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@Book{aoe,
+ title = {The Art of Electronics},
+ publisher = {Cambridge},
+ year = {1989},
+ author = {Paul Horowitz, Winfield Hill},
+ %author = {},
+ OPTkey = {},
+ OPTvolume = {},
+ OPTnumber = {},
+ OPTseries = {},
+ OPTaddress = {},
+ OPTedition = {2nd},
+ OPTmonth = {},
+ OPTnote = {},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {ISBN 0-521-37095-7},
+ OPTlocalfile = {},
+ OPTabstracts = {},
+}
+
+@TechReport{eurothermtables,
+ author = {},
+ title = {Thermocouple Emf TABLES and PLATINUM 100 RESISTANCE THERMOMETER TABLES},
+ institution = {Eurotherm},
+ year = {1973},
+ OPTkey = {},
+ OPTtype = {},
+ OPTnumber = {},
+ OPTaddress = {},
+ OPTmonth = {June},
+ OPTnote = {Bulletin TT-1},
+ OPTannote = {},
+ OPTurl = {},
+ OPTdoi = {},
+ OPTissn = {},
+ OPTlocalfile = {},
+ OPTabstract = {},
+}
+
+@MISC{iso639-1,
+ title = "ISO 639-1: Code for the Representation of Names of Languages",
+ author = "International Standardization Organization",
+ howpublished = "http://www.loc.gov/standards/iso639-2/criteria1.html"
+ year = "1998"
+}
+
+@MISC{nano-x,
+ title = "The nano-X windowing system",
+ author = "Greg Haerr",
+ howpublished = "http://www.microwindows.org/"
+ year = "2003"
+}
+
+
+
+
+@MISC{X11,
+ title = "The XFree86 Project, Inc",
+ author = "Open Source",
+ howpublished = "http://www.xfree86.org/"
+ year = "1992"
+}
+
+
+http://www.xfree86.org/
+
+@MISC{iso639-2,
+ title = "ISO 639-2: Code for the Representation of Names of Languages",
+ author = "International Standardization Organization",
+ howpublished = "http://www.loc.gov/standards/iso639-2/criteria1.html"
+ year = "1998"
+}
+
+
+@misc{ touchscreenprod,
+       author = "M. Thirsk",
+       title = "Touchscreen Production Procedure : HR~222165",
+       howpublished = "Internal ETC Document",
+       year = "2008" };
+
+
+@misc{ touchscreensoftware,
+       author = "ETC Software Dept.",
+       title = "Touchscreen Software released to Production : HR~222162",
+       howpublished = "Internal ETC Software (medium: 2 MMC cards)",
+       year = "2008" };
+
+@misc{ touchscreengui,
+       author = "D.J. Legge, R.P.Clark",
+       title = "Touchscreen GUI Design Document : HR~222163",
+       howpublished = "Internal ETC Document",
+       year = "2008" };
+
+
+@misc{ gumstix,
+       author = "Gumstix Inc",
+       title = "Gumstix Home Page",
+       howpublished = "WEB http://www.gumstix.com/",
+       year = "2008" };
+
+
+@misc{ fltk,
+       author = "FLTK open Source Developers",
+       title = "Fast Light Toolkit",
+       howpublished = "WEB http://www.fltk.org/",
+       year = "2008" };
+
+
+@Book{ldd,
+author = {Jonathon Corbet},
+ALTeditor = {Alessandro Rubini},
+ALTeditor = {Greg Kroah-Hartman},
+title = {Linux Device Drivers},
+publisher = {O'Reilly ISBN 0-596-00590-3},
+year = {1998},
+OPTkey = {ISBN 0-596-00590-3},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {linux},
+OPTaddress = {},
+OPTedition = {3rd},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+
+@Book{bash,
+author = {Carl Albing},
+title = {Bash Cookbook},
+publisher = {O'Reilly ISBN 0-596-52678-4},
+year = {2007},
+OPTkey = {ISBN 0-596-52678-4},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {unix/linux},
+OPTaddress = {},
+OPTedition = {},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{sedawk,
+author = {Dale Dougherty, Arnold Robbins},
+title = {Sed and Awk},
+publisher = {O'Reilly ISBN 1-56592-225-5},
+year = {1997},
+OPTkey = {ISBN 1-56592-225-5},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {unix/linux},
+OPTaddress = {},
+OPTedition = {},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{bels,
+author = {Karim Yaghmour},
+title = {Building Embedded LINUX systems},
+publisher = {O'Reilly ISBN ISBN 0-596-00222-X},
+year = {2003},
+OPTkey = {ISBN 0-596-00222-X},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {linux},
+OPTaddress = {},
+OPTedition = {3rd},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.oreilly.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{can,
+author = {Olaf Pfeiffer},
+ALTeditor = {Andrew Ayre},
+ALTeditor = {Christian Keydel},
+title = {Embedded networking with CAN and CANopen},
+publisher = {RTC ISBN 0-929392-78-7},
+year = {2003},
+OPTkey = { },
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {Embedded Systems},
+OPTaddress = {},
+OPTedition = {1st},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {www.rtcbooks.com},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Article{article,
+author = {dd},
+title = {dd},
+journal = {dd},
+year = {2008},
+OPTkey = {},
+OPTvolume = {},
+OPTnumber = {},
+OPTpages = {1,2},
+OPTmonth = {JAN},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+
+@Book{sqlite,
+author = {Micheal Owens},
+title = {The definitive guide to SQLite},
+publisher = {Apres ISBN 1-59059-673-0},
+year = {2006},
+OPTkey = {},
+OPTvolume = {},
+OPTnumber = {},
+OPTseries = {Databases/SQLite},
+OPTaddress = {},
+OPTedition = {},
+OPTmonth = {},
+OPTnote = {},
+OPTannote = {},
+OPTurl = {},
+OPTdoi = {},
+OPTissn = {},
+OPTlocalfile = {},
+OPTabstract = {}
+};
+

survey/paper.tex

@@ -0,0 +1,27 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{../style}
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+\outerhead{{\small\bf Survey of Safety Critical Static Analysis Methods}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{Survey of Safety Critical Static Analysis Methods}
+\maketitle 
+\input{survey_paper}
+
+\bibliographystyle{plain}
+\bibliography{vmgbibliography,mybib}
+
+\today
+\end{document}

survey/survey.tex

@@ -0,0 +1,58 @@
+%
+% Make the revision and doc number macro's then they are defined in one place
+
+\begin{abstract}
+
+\end{abstract}
+
+\section{FMEA}
+
+Two meanings, a general one Fault Mode Effects Analysis, meaning general statics diagnosis of a design, looking
+at faults that can occur and their effect.
+
+
+\subsection{Manufacturing Cost Reduction FMEA}
+
+Second a methodology for reducing cost in manufacturing by taking fauls, their frequency
+and their cost, multiplying these together, and then coming up with a priority list
+for fixing knmown faults.
+"The basics of FMEA by Robin E. McDermott et all"
+ISBN 0-527-76320-9.
+
+
+\subsection{Deterministic FMEA}
+
+EN298 no two individual component failures may give rise to a dangerous condition.
+
+\section{FMEDA Failure effect Mode Diagnositic Analysis}
+
+This is a probablistic based methodology.
+
+\subsection{Safe Failure Fraction}
+
+Introduce the idea of coverage.
+A good example is RAM in a microprocessor/microcontroller, we cann ot give 100i\% coverage to it.
+We can perform some tests that give us 60\% coverage etc
+
+\subsection{Diagnostic interval}
+
+Reducing FIT with detecting a fraction of the faults within an interval. Give formulas etc
+
+
+\subsection{Redundancy - Models}
+
+1oo1 2oo3 etc
+
+\subsection{Field Data}
+
+OK for EN61508, not OK for nuclear industry find refs.
+
+
+\section {FTA}
+
+Fault tree Analysis
+Show how it works, top down, 
+% read exita doc and ref it
+
+% typeset in {\Huge \LaTeX} \today
+

thesis.tex

@@ -51,20 +51,27 @@
 \input{introduction/introduction}
 
 \chapter{An overview of European and North Americans Standards}
-%\input{standards/standards}
+\input{standards/standards}
 
 \chapter{Statistical Methods and Models}
 %\input{statistics/statistics}
 
-\chapter{Survey of Safety Critical Analysis Metyhodologies and Tools Available}
+\chapter{Survey of Safety Critical Analysis Methodologies and Tools Available}
-%\input{survey/survey}
+\input{survey/survey}
+
+
+
+\typeout{ ---------------- Component Failure Modes Definition }
+\chapter { Component Failure Modes Definition}
+\input{component_failure_modes_definition/component_failure_modes_definition} 
+
 
 \typeout{ ---------------- Propositional Logic Diagrams}
 \chapter {Propositional Logic Diagrams}
 \input{logic_diagram/logic_diagram}
 
 \typeout{ ---------------- Electronic Components as PLDs}
-\chapter {Electronic Components as PLDs}
+\chapter {Common Electronic Components as PLDs}
 \input {components_as_plds/components_as_plds}
 
 \typeout{ ----------------  Software as PLDs}
@@ -72,7 +79,7 @@
 \input{sw_as_plds/sw_as_plds}
 
 \typeout{ ----------------  Mechanical Sub-systems as PLDs}
-\chapter {Mechanical Sub-systems as PLDs}
+\chapter {Common Mechanical Sub-systems as PLDs}
 %\input{mech_as_plds/mech_as_plds}
 
 
@@ -121,7 +128,7 @@ Software documentation for fmmd tool.
 \input{fzd/fzd}
 
 \chapter{A detailed look at the safety systems required by industrial burner controller}
-%\input{indburner/indburner}
+\input{burner/burner}
 
 %\chapter{FMMD tool : Algorithms and Euler Diagram Parsing}