robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

CH6 tidied and made a macro for

Browse Source 
displaying C functions
This commit is contained in:
Robin Clark 2013-06-15 15:35:39 +01:00
parent 08a180409d
commit 9da2299e7f
3 changed files with 63 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
mybib.bib
View File

@ -1045,8 +1045,7 @@ ISSN={1530-2059},}
howpublished = "British standards Institution http://www.bsigroup.com/",
year = "1985"
}
year = "2002"
}
@MISC{javaarea,
author = "Sun~Micro~Systems",
@ -1058,6 +1057,9 @@ ISSN={1530-2059},}
author = "E N Standard",
title = "61508:2002 Functional safety of electrical/electronic/programmable electronic safety related systems",
howpublished = "British standards Institution http://www.bsigroup.com/",
year = "2002"
}
@Manual{lm358,
title = {Datasheet: Low-Power dual operation amplifiers LM158,LM258,LM358: Doc ID 2163 Rev 10},

99
submission_thesis/CH6_Software_Examples/software.tex
View File

@ -253,7 +253,13 @@ We can now examine a software function that performs a conversion from the volta
a per~mil representation of the {\ft} input current.
%
For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is used.
We initially assume a function \textbf{read\_ADC} that returns a floating point %double precision
%
A 'C' function function is declared with parenthesis to
differentiate from other type of variables (data types or pointers).
In this document we borrow that format, hence the C~language
function called `main' will be presented as \cf{main}.
%
We initially assume a function \cf{read\_ADC} that returns a floating point %double precision
value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}).
@ -296,12 +302,12 @@ int read_4_20_input ( int * value ) {
%}
%}\clearpage
\caption{Software Function: \textbf{read\_4\_20\_input}}
\caption{Software Function: \cf{read\_4\_20\_input}}
\label{fig:code_read_4_20_input}
%\label{fig:420i}
\end{figure}
\clearpage
We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\_ADC}, which returns a
We now look at the function called by \cf{read\_4\_20\_input}, \cf{read\_ADC}, which returns a
voltage for a given ADC channel.
%
This function
@ -366,7 +372,7 @@ double read_ADC( int channel ) {
return dval;
}
\end{verbatim}
\caption{Software Function: \textbf{read\_ADC}}
\caption{Software Function: \cf{read\_ADC}}
\label{fig:code_read_ADC}
\end{figure}
%}
@ -588,7 +594,7 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
\paragraph{Functional Group - Software - voltage to per mil - VTPM }
This function sits on top of the $RADC$ {\dc} determined above.
We look at the pre-conditions for the function $read\_4\_20\_input$, % which we can call $RI$
We look at the pre-conditions for the function \cf{read\_4\_20\_input}, % which we can call $RI$
to determine its {\fms}.
Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}.
We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition
@ -597,7 +603,7 @@ we can state,
$$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$
We can now form a functional group with the {\dc} $RADC$ and the
software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $.
software component \cf{read\_4\_20\_input}, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $.
@ -605,7 +611,7 @@ software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\
\tiny
\begin{table}[h+]
\center
\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table
\caption{$G_3$: \cf{Read\_4\_20}: Failure Mode Effects Analysis} % title of Table
\label{tbl:r420i}
\begin{tabular}{|| l | c | l ||} \hline
@ -645,7 +651,7 @@ software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\
}
The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$.
The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value is proportional (0-999) to the
The postcondition for the function \cf{read\_4\_20\_input}, {\em /* ensure: value is proportional (0-999) to the
4 to 20mA input */} corresponds to the $VAL\_ERR$ and is already in the set of failure modes.
% \paragraph{Final Functional Group}
For single failures these are the two ways in which this function
@ -797,7 +803,8 @@ Using figure~\ref{fig:context_diagram_PID} we review the system in terms of its
with the data sources (the Pt100 inputs) and the data sinks (the heater output and the LED indicators).
%
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
For the Pt100 sensor, we will need to read the voltages it outputs and %for
this
will therefore require an ADC and MUX.
%
For the output, we can use a Pulse Width Modulator (PWM) (this is a common module found on micro-controllers
@ -865,8 +872,8 @@ this is clearly going to be the monitor function.
The monitor function will orchestrate the control process.
Firstly it will examine the timer value, and when appropriate, call the PID function.
The PID function call
determine\_set\_point\_error and that calls convert\_ADC\_to\_T
which calls Read\_ADC (the function developed in the earlier example)
\cf{determine\_set\_point\_error} and that calls \cf{convert\_ADC\_to\_T}
which calls \cf{Read\_ADC} (the function developed in the earlier example)
which reads from physical hardware.
%
With the set point error value the PID function will return
@ -946,8 +953,10 @@ $$ fm(PWM) = \{ HIGH, LOW \}.$$
\paragraph{Micro-Controller.}
The Micro controller is a complex piece of highly integrated electronics.
Typically, along with a micro-processor with PROM and RAM, they have many I/O modules including UARTS, PWM, ADCMUX, CAN
General I/O and interrupt lines to name but a few.
At a minimum it would include a micro-processor with PROM and RAM
general I/O lines ane external interupt lines.
Typically therer are many other I/O module incorporated (e.g. TIMERS, UARTS, PWM, ADC, ADCMUX, CAN).
In this project we are using the ADCMUX, TIMER, PWM and general purpose computing facilities.
We have to therefore consider the general~computing, CLOCK, PROM and RAM failure modes.
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
@ -955,12 +964,12 @@ $$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLO
\subsection{Temperature Controller Software Elements FMMD}
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)
\item --- \cf{Monitor} (which calls PID algorithm and sets status LEDS)
\item --- \cf{PID} (which calls cf{determine\_set\_point\_error} and \cf{output\_control})
\item --- \cf{determine\_set\_point\_error} (which calls convert\_ADC\_to\_T)
\item --- \cf{convert\_ADC\_to\_T} (which calls read\_ADC which we can re-use from the last example)
\item --- \cf{read\_ADC}
\item --- \cf{output\_control} (which sets the PWM hardware according to the PID demand value)
\end{itemize}
With the call tree structure defined (see figure~\ref{fig:context_calltree}), we can now analyse these
components from the bottom-up, starting with the afferent flow, the reading of the temperature and its conversion
@ -971,20 +980,20 @@ We start with the afferent flow from the Pt100.
%with the software, and consider the hardware elements
%used (if any) by each software function.
Starting at the bottom, we form a {\fg} with
the function read\_ADC and the Pt100.
the function \cf{read\_ADC} and the Pt100.
This gives us a {\dc} which we call
$ReadPt100$.
ReadPt100.
%
%
The {\dc} Read\_Pt100 is a failure mode model of the Read\_ADC function and the Pt100
The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} function and the Pt100
hardware, and has the following failure modes:
$$ fm (Read\_Pt100) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
We move along the afferent flow, and we come to the convert\_ADC\_to\_T function.
This will call Read\_ADC twice, one for the high Pt100 value, again for the lower. % and once for to read a current sense.
We move along the afferent flow, and we come to the \cf{convert\_ADC\_to\_T} function.
This will call \cf{Read\_ADC} twice, one for the high Pt100 value, again for the lower. % and once for to read a current sense.
We then, calculate the resistance of the Pt100 element, and with this---using a
polynomial or a lookup table~\cite{eurothermtables}---calculate the temperature.
The pre-conditions for the function are that:
@ -999,8 +1008,8 @@ Note that a temperature outside the pre-defined range will also cause these erro
The postcondition is that it returns a temperature within a given tolerance to the temperature at the sensor.
A failure of this post-condition can be termed temp\_incorrect.
\clearpage
We apply FMMD to the {\fg} formed by Read\_Pt100 and the function convert\_ADC\_to\_T.
We can call the resulting {\dc} Get\_Temperature. This analysis is presented in table~\ref{tbl:gettemperature}.
We apply FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
We can call the resulting {\dc} \cf{Get\_Temperature}. This analysis is presented in table~\ref{tbl:gettemperature}.
The analysis is presented in table~\ref{tbl:readPt100}.
@ -1013,9 +1022,9 @@ $$fm(Get\_Temperature) = \{ Pt100\_out\_of\_range, temp\_incorrect \}$$
Following the afferent flow further, we come to a function to determine the control error value.
This is simply the target temperature subtracted from the measured.
We thus form a {\fg} with our newly {\dc} Get\_Temperature
and the function determine\_set\_point\_error.
and the function \cf{determine\_set\_point\_error}.
%
The pre-condition for determine\_set\_point\_error is that the temperature read by it
The pre-condition for \cf{determine\_set\_point\_error} is that the temperature read by it
is accurate, and its post condition is to return the correct control error value.
Most failure modes from a Pt100 are observable.
we can divide the post condition into two variants, a known incorrect error value, KnownIncorrectErrorValue
@ -1033,28 +1042,31 @@ $$fm(GetError) = \{ KnownIncorrectErrorValue, IncorrectErrorValue \}.$$
We now follow the afferent path to the PID algorithm.
Here we assume that the PID constants are fixed (i.e. are not parameters).
We use the $GetError$ {\dc} and the PID function to form a {\fg}.
The pre-condition for the PID function is that % are that it is called
The pre-condition for the \cf{PID} function is that % are that it is called
%iat the correct frequency and that
it receives the correct error value.
The post-condition is that it outputs correct control values.
% RESP FOR TIMEING IS ON CALLING FUNCTION AND IS A SEPARATE ERROR- TGHINK ABOUT JITTER.....
% and controll values..... Jitter might not matter, wrong int times would
% controlling function provdes context of use.
Those familiar with the PID algorithm may realise that digital signal processing algorithms are sensitive to calling frequency.
%Those familiar with the PID algorithm may realise that digital signal processing algorithms are sensitive to calling frequency.
All digital signal processing algorithms are sensitive to calling frequency, and thus should be time invariant~\cite{fpodsadsp}[p.58].
Were this function to be called at an incorrect rate, its output
would be wrong (the differential and integral parameters would effectively have been changed).
could be erroneous (the differential and integral parameters would effectively have been changed).
%
However this problem is a failure mode for the function calling it.
However this problem is a failure mode for the function calling it i.e. the context of use (see section~\ref{sec:subjectiveobjective}) .
% discussion, the subjective
% being the context the {\dc} is used for/in, and the objective
% being the logic and process of the failure mode analysis.
%
The calling function sets the context for the PID algorithm (i.e. what it is used for).
If this PID were to be used, say as some form of low pass filter, we could consider jitter
for instance.
%If this PID were to be used, say as some form of low pass filter, we could consider jitter
%for instance.
%
In a control environment with PID, jitter would not be a significant factor.
%In a control environment with PID, jitter would not be a significant factor.
%
This harks back to the context of use (see section~\ref{sec:subjectiveobjective}) discussion, the subjective
being the context the {\dc} is used for/in, and the objective
being the logic and process of the failure mode analysis.
%HARK THE HERALD ANGELS SING... HARK????
We now create a PID {\dc}, with the following failure modes:
@ -1077,12 +1089,13 @@ PWM/heater output.
\subsubsection{Efferent flow, PID demand value to PWM output}
The monitor function calls the output\_control function with the PID demand.
The output\_control function then sets the PWM hardware register, which causes the mark space output of the PWM module to
The monitor function calls the \cf{output\_control} function with the PID demand.
The \cf{output\_control} function then sets the PWM hardware register, which causes the mark space output of the PWM module to
apply the demanded power. We form a {\fg} with the Heating element, a PWM module and the output\_control function to model this branch
of the efferent flow. We apply FMMD analysis to this {\fg} in table~\ref{tbl:heateroutput}.
For the output\_control function, we have a pre-condition that the PWM module is
For the \cf{output\_control} function, we have a pre-condition that the PWM module is
configured and working, and has the correct clock frequency.
%
A second pre-condition is that the heating element is connected and working.
The post condition is that it sets the correct value into the PWM register
to implement the power output demand.
@ -1120,9 +1133,9 @@ would indicate to the operator that an error had occurred.
The pre-condition for this function is that the GPIO
is connected to working LEDS.
%
The post condition is that the function setLEDS will supply correct indication by flashing the LEDs.
The post condition is that the function \cf{setLEDS} will supply correct indication by flashing the LEDs.
%
We form a {\fg} from the GPIO, the LEDs and the software function setLEDs.
We form a {\fg} from the GPIO, the LEDs and the software function \cf{setLEDs}.
%
We apply FMMD analysis to this {\fg} in table~\ref{tbl:ledoutput}.

3
submission_thesis/style.tex
View File

@ -31,7 +31,7 @@
\setlength{\oddsidemargin}{0mm} \setlength{\evensidemargin}{0mm}
%
\newcommand{\permil}{\ensuremath{0/{\!}_{00}}}
%\newcommand{\emp}{ELECTRO MAGNETIC FUKING PULSE}
\newcommand{\emp}{} %% was italics
\newcommand{\sd}{\ensuremath{\Sigma \Delta ADC}}
%\newcommand{\sd}{\ensuremath{Sigma\;Delta\;ADC}}
@ -57,6 +57,7 @@
\newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}}
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
\newcommand{\half}{\ensuremath{\frac{1}{2}}}
\newcommand{\cf}[1]{\textbf{#1()}}
%
% OK after about 3 years its not rigorous FMEA (RFMEA) anymore, oh no, its Exhaustive FMEA