Bashed out yourdon design of pid controller

mybib.bib

@@ -591,7 +591,12 @@ year = {2012},
  howpublished = "British standards Institution http://www.bsigroup.com/",
   year =         "2003"
 }
-
+@MISC{en230,
+  author =       "E N Standard",
+  title =        "EN230:2005 Automatic burner control systems for oil burners",
+ howpublished = "British standards Institution http://www.bsigroup.com/",
+  year =         "2005"
+}
 @MISC{en60730,
   author =       "E N Standard",
   title =        "EN60730: Automatic Electrical controls for household and similar use",
@@ -639,7 +644,14 @@ OPTissn = {},
  OPTabstract = {},
 }
 
-
+@book{Yourdon:1989:MSA:62004,
+ author = {Yourdon, Edward},
+ title = {Modern structured analysis},
+ year = {1989},
+ isbn = {0-13-598624-9},
+ publisher = {Yourdon Press},
+ address = {Upper Saddle River, NJ, USA},
+} 
 
 
 @Manual{pic18f2523,

submission_thesis/CH2_FMEA/copy.tex

@@ -11,7 +11,7 @@ on the behaviour and safety of the system."
 
 
 \section{FMEA}
-
+\label{basicfmea}
 %\subsection{FMEA}
 %\tableofcontents[currentsection]
 \paragraph{FMEA basic concept.}
@@ -179,8 +179,19 @@ FMEA based methodologies are forward searches\cite{Lutz:1997:RAU:590564.590572}
 methodologies such as FTA~\cite{nucfta,nasafta}
 Forward search types of fault analysis is said to be `deductive'.
 \paragraph{Reasoning distance}
+\label{reasoningdistance}
 A reasoning distance is the number of stages of logic and reasoning
 required to map a failure cause to its potential outcomes.
+In our basic FMEA example in section~\ref{basicfmea}
+we were tasked to consider one failure mode against all the components in the milli-volt reader.
+To create a complete FMEA report on the milli-volt reader we would have had to examine every 
+known failure mode of every component within it---against all its other components.
+The reasoning~distance is defined as  the sum of the number of failure modes, against all other components
+in that system.
+If the milli-volt reader had say 100 components, with three failure modes each, this
+would give a reasoning distance of 3 * 100 * 99.
+
+
 %.... general concept... simple ideas about how complex a
 %failure analysis is the more modules and components are involved
 % cite for forward and backward search related to safety critical software

submission_thesis/CH5_Examples/Makefile

@@ -6,7 +6,8 @@ PNG_DIA = blockdiagramcircuit2.png  bubba_oscillator_block_diagram.png  circuit1
 	pt100_tc.png         pt100_tc_sp.png      shared_component.png   stat_single.png    three_tree.png  \
 	tree_abstraction_levels.png   vrange.png sigma_delta_block.png ftcontext.png ct1.png hd.png         \
         sigdel1.png sdadc.png bubba_euler_1.png bubba_euler_2.png eulersd.png eulersdfinal.png              \
-	eulerfivepole.png eulerswhw.png
+	eulerfivepole.png eulerswhw.png context_diagram_PID.png context_diagram2_PID.png context_software.png \
+	context_calltree.png
 
 
 

submission_thesis/CH5_Examples/copy.tex

@@ -25,7 +25,7 @@ a variety of typical embedded system components including analogue/digital and e
 %In order to implement FMMD in practise, we review the basic concepts and processes of the methodology.%
 %Each example has been chosen to demonstrate 
 %FMMD applied to 
-%
+%They go in salads too
 % % The first section
 % % ~\ref{sec:determine_fms} looks at how we determine failure mode sets for {\bcs} 
 % % (in the context of the safety standards
@@ -54,7 +54,7 @@ loop topology---using a `Bubba' oscillator---demonstrating how FMMD id different
 Two analysis strategies are employed, one using
 initially identified {\fgs} and the second using a more complex hierarchy of {\fgs} and {\dcs}, showing
 that a finer grained/more de-composed approach offers more re-use possibilities in future analysis tasks.
-\item Section~\ref{sec:sigmadelta} demonstrates FMMD can be applied to mixed anal;ogue and digital circuitry
+\item Section~\ref{sec:sigmadelta} demonstrates FMMD can be applied to mixed analogue and digital circuitry
 using a sigma delta ADC.
 %shows FMMD analysing the sigma delta 
 %analogue to digital converter---again with a circular signal path---which operates on both 

submission_thesis/CH5_Examples/software.tex

@@ -149,7 +149,7 @@ an ADC and its multiplexer.
 With the voltage determined at the ADC we read the intended quantitative
 value from the external equipment.
 
-\subsection{Simple Software Example}
+\section{Simple Software Example: Reading a \ft input into software}
 
 
 Consider a software function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$)
@@ -596,30 +596,158 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig
 
 
 
-We can represent %the hierarchy in figure~\ref{fig:hd} algebraically, 
+%HTR 18NOV2012 We can represent %the hierarchy in figure~\ref{fig:hd} algebraically, 
-the analysis hierarchy algebraically using the `$\derivec$' function:
+%HTR 18NOV2012 the analysis hierarchy algebraically using the `$\derivec$' function:
-%using the groups as intermediate stages:
+%HTR 18NOV2012 %using the groups as intermediate stages:
-\begin{eqnarray*}
+%HTR 18NOV2012 \begin{eqnarray*}
-G_1 &=&  \{R,ADC\} \\
+%HTR 18NOV2012 G_1 &=&  \{R,ADC\} \\
-CMATV &=&  \;\derivec (G_1) \\
+%HTR 18NOV2012 CMATV &=&  \;\derivec (G_1) \\
-G_2 &=& \{CMATV, read\_ADC \} \\
+%HTR 18NOV2012 G_2 &=& \{CMATV, read\_ADC \} \\
-RADC &=&  \; \derivec (G_2) \\
+%HTR 18NOV2012 RADC &=&  \; \derivec (G_2) \\
-G_3 &=& \{ RADC, read\_4\_20\_input \} \\
+%HTR 18NOV2012 G_3 &=& \{ RADC, read\_4\_20\_input \} \\
-R420I &=&  \; \derivec (G_3) \\
+%HTR 18NOV2012 R420I &=&  \; \derivec (G_3) \\
-\end{eqnarray*}
+%HTR 18NOV2012 \end{eqnarray*}
-or, a nested definition,
+%HTR 18NOV2012 or, a nested definition,
-$$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$ 
+%HTR 18NOV2012 $$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$ 
 
  
+%\section
+
+
+%HTR 18NOV2012 This nested structure means that we have multiple traceable
+%HTR 18NOV2012 stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage 
+%HTR 18NOV2012 of reasoning for each component failure mode.
+
+
+
+\section{Closed Loop Control Hardware/Software Hybrid Example}
+
+It is desirable to model a complete standalone system with FMMD.
+Not only a standalone system, but ideally a hybrid software/hardware system.
+Temperature control is a first order differential problem, and is often 
+addressed using the Proportional Integral differential (PID) algorithm~\cite{dcods}.
+Traditionally this was performed in analogue electronics
+with trimmer potentiometers providing the P and I parameters.
+Since the introduction of micro-processors, it has been possible to
+implement PID programmatic-ally.
+An FMMD analysis of a PID temperature controller would mean an
+analysis of a standalone system without being un-wieldingly large.
+\paragraph{PID Temperature Control.}
+PID control starts with a setpoint, or desired value for a process
+(here the temperature). It reads the process value and determines an error value for it.
+The aim of the PID controller is to minimise this error term, by setting an output value,
+which is fed back into the process (in this example the amount of power to supply the heater).
+The error value is integrated and multiplied by an I constant.
+A differential of the error value is calculated and multiplied by a D constant.
+The error value its self is multiplied by a P constant, and all three of these are added
+to obtain the output required.
+\subsection{Design Stage: Implementation on a micro-controller.}
+When writing a computer program it is always useful to 
+produce a structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MSA:62004}, see figure~\ref{fig:context_diagram_PID}.
+The Yourdon methodology also gives us a guide as to which software
+functions should be called to control the process, or in `C' terms be the main function.
+%
+\begin{figure}[h]+
+ \centering
+ \includegraphics[width=300pt]{./CH5_Examples/context_diagram_PID.png}
+ % context_diagram_PID.png: 818x324 pixel, 72dpi, 28.86x11.43 cm, bb=0 0 818 324
+ \caption{Yourdon Context Diagram for PID Temperature Controller.}
+ \label{fig:context_diagram_PID}
+\end{figure}
+We have two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor.
+For the Pt100 sensor, we will need to read the voltages it outputs and for this
+we will need and ADC and MUX. 
+For the output, we can use a Pulse Width Modulator (PWM) output. This is a common module found on micro-controllers
+allowing a variable power output. PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}.
+We can now build more detail into the Yourdon diagram, with the afferent flow coming through the MUX and ADC on the micro-controller, and the afferent 
+channelled through a PWM module, again built into the micro-controller.
+\begin{figure}[h]+
+ \centering
+ \includegraphics[width=300pt]{./CH5_Examples/context_diagram2_PID.png}
+ % context_diagram_PID.png: 818x324 pixel, 72dpi, 28.86x11.43 cm, bb=0 0 818 324
+ \caption{Yourdon Context Diagram for PID Temperature Controller.}
+ \label{fig:context_diagram2_PID}
+\end{figure}
+The Yourdon methodology allows us to zoom into transform bubbles and analyse them in more
+detail, the controlling software requires definition.
+we follow the data streams through the process, creating transform bubbles as required.
+In all `bare~metal' software architectures, we need a rudimentary operating system, often referred to as the monitor.
+PID, because the algorithm depends heavily on integration, is time sensitive
+and we therefore need to invoke at at specific intervals.
+Most micro-controllers feature several general purpose timers~\cite{pic18f2523}.
+We can use an internal timer in conjunction with the monitor function
+to call the PID algorithm at a specified interval.
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=300pt]{./CH5_Examples/context_software.png}
+ % context_software.png: 1023x500 pixel, 72dpi, 36.09x17.64 cm, bb=0 0 1023 500
+ \caption{Context diagram of the software in the PID temperature controller}
+ \label{fig:contextsoftware}
+\end{figure}
+sing figure~\ref{fig:contextsoftware} we can now pick the transform bubble we 
+want to be the `main' or controoling function in the software.
+This can be thought of as picking one bubble and holding it up. The other bubbles hang underneath
+forming the software call tree hierarchy, see figure~\ref{fig:context_calltree}.
+\begin{figure}[h]+
+ \centering
+ \includegraphics[width=300pt]{./CH5_Examples/context_calltree.png}
+ % context_calltree.png: 800x783 pixel, 72dpi, 28.22x27.62 cm, bb=0 0 800 783
+ \caption{Software yourdon diagram converted to programatic call tree.}
+ \label{fig:context_calltree}
+\end{figure}
+
+
+This is clearly going to be the monitor function.
+This will examine the timer value, and call the PID function, which will call first
+the determine\_set\_point\_error function with that calling convert\_ADC\_to\_T
+which calls Read\_ADC (the function developed in the earlier example).
+With the set point error value the PID function will call the output control function with its PID 
+demand. On returning to the monitor function, it will return the PID demand value.
+
+
+Now we have the system design we have all the components, hardware elements and software functions
+that will be used in the temperature controller.
+We can list these and begin, from the bottom-up
+applying FMMD analysis.
+
+\clearpage
+\subsection{FMMD Analysis of PID temperature Controller}
+
+To summarise from the design stage,
+Identified electronic components:
+\begin{itemize}
+ \item ADCMUX --- Electronics, analysed in previous example.
+ \item TIMER --- Internal micro controller timer
+ \item HEATER --- Heating element, essentially a resistor.
+ \item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100}.
+ \item micro-controller --- the medium for running the software
+\end{itemize}
+
+Identified Software Components:
+\begin{itemize}
+ \item --- Monitor (which calls PID algorithm and sets status LEDS)
+ \item --- PID (which calls determine\_set\_point\_error and output\_control)
+ \item --- determine\_set\_point\_error (which calls convert\_ADC\_to\_T)
+ \item --- convert\_ADC\_to\_T (which calls read\_ADC which we can re-use from the last example)
+ \item --- read\_ADC
+ \item --- output\_Control (which sets the PWM hardware according to the PID demand value)
+\end{itemize}
+
+
+With the call tree structure, we can now analyse these 
+components from the bottom-up.
+
+
+
+
+
+
 
 
 
-This nested structure means that we have multiple traceable
-stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage 
-of reasoning for each component failure mode.
 
 %\clearpage
-\subsection{Conclusion: Software/Hardware FMMD Model}
+\section{Conclusion: Software/Hardware FMMD Model}
 
 The {\dc} representing the {\ft} reader
 in software shows that by FMMD, we can integrate
@@ -632,8 +760,6 @@ reasoning stage.
 %
 Each reasoning stage will have an associated analysis report.
 %
-
-
 With traditional FMEA methods the reasoning~distance is large, because
 it stretches from the component failure mode to the top---or---system level failure.
 For this reason applying traditional FMEA to software stretches