Created corrections reply document

This commit is contained in:
Robin Clark 2015-08-22 14:59:16 +01:00
parent 53e54604d4
commit 8a9d0714f7

View File

@ -62,7 +62,7 @@ failure mode of the component or sub-system}}}
\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}}
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
\newcommand{\bcfm}{base~component~failure~mode}
\newcommand{\cf}[1]{{\tiny \textbf{#1()}}}
\newcommand{\cf}[1]{{\footnotesize \textbf{#1()}}}
\newcommand{\swhw}{software~hardware}
\newcommand{\sw}{software}
\newcommand{\hw}{hardware}
@ -1585,7 +1585,7 @@ Each electronic {\dc} will be described and cited in more detail below.
\paragraph{ADCMUX and Read\_ADC.}
The {\dc} from \cite{syssafe2012} is re-used for this analysis. %section~\ref{readADC}.
This analysis was performed on a `C' function which
This analysis was performed on a `C' function (\cf{Read\_ADC}) which
read a value from an analogue to digital converter (ADC) hardware element.
The analysis revealed that it could fail in three ways.
$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
@ -1593,10 +1593,10 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
%
\paragraph{TIMER.}
%
The internal timer, from a programmer's perspective is a register, which when read
A hardware timer, from a programmer's perspective is a register, which when read
returns an incremented time value.
%
Essentially its a free running integer counter with an interfacing register.
Essentially its a free running, precisely clocked integer counter with an interfacing register.
%
Using two's complement mathematics, by subtracting
the time last read value, we can calculate the interval
@ -1647,7 +1647,10 @@ Typically there are many other I/O modules incorporated (e.g. TIMERS, UARTS, PWM
In this project the ADCMUX, TIMER, PWM and general purpose computing facilities are used.
%
Consider the general~computing, CLOCK, PROM and RAM failure modes:
$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
\begin{eqnarray*}
fm (micro-controller) = \{ PROM\_FAULT, \\ RAM\_FAULT, \\ CPU\_FAULT, \\ ALU\_FAULT, \\ CLOCK\_STOPPED \}.
\end{eqnarray*}
%$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
%
\subsection{Temperature Controller Software Elements FMMD}
Identified Software Components:
@ -1722,7 +1725,7 @@ pre-defined range would be detected as an unacceptable voltage range failure.}.
%
The post-condition 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'.
A failure of this post-condition is that the wrong value would be returned: this {\fm} is named $VAL\_ERR$.
%
\clearpage
Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
@ -1782,7 +1785,7 @@ When FMMD analysis has been performed this gives a {\dc}, named
%\fmmdglossADC
Collecting symptoms from table~\ref{tbl:tbl:gettemperature}, the {\dc} $convert\_ADC\_to\_T$ is assigned the following failure modes:
Collecting symptoms from table~\ref{tbl:gettemperature}, the {\dc} $convert\_ADC\_to\_T$ is assigned the following failure modes:
$$
fm(convert\_ADC\_to\_T) = \{ VOLTAGE\_HIGH , VOLTAGE\_LOW, VAL\_ERR\} .
$$
@ -1832,7 +1835,7 @@ This analysis is presented in table~\ref{tbl:geterror}.
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
\hline
@ -1896,7 +1899,7 @@ it is the calling function that sets the context for the \cf{PID} function (i.e
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
\hline
@ -1919,9 +1922,9 @@ To add some perspective here, if the failure mode is detectable i.e. $KnownContr
it is the responsibility of the calling function to act on this and attempt a safety measure (in this case to turn off the heater and indicate an error condition).
Where the failure mode is not detectable the control will
in all likelihood apply an incorrect output.
Part of FMMD failure analysis is recognising that a design may have
undetectable errors. re-design of the modules affected can be identified by their position in the hierarchy
and thus solutions devised.
A feature of the FMMD failure analysis process is that it can reveal that a design may have
undetectable errors: re-design of the areas affected --- determined by where they are first recognised in the call tree --- identifies their position in the hierarchy
and thus solutions can be devised.
@ -1938,7 +1941,7 @@ and thus solutions devised.
%
The software call tree for the afferent flow has now been modelled using FMMD;
this is represented as an Euler diagram in figure~\ref{fig:euler_afferent_PID}.
Two call tree branches remain. The LED indication branch and the
Two smaller call tree branches remain. The LED indication branch and the
PWM/heater output.
%
\subsubsection{Efferent flow, PID demand value to PWM output}
@ -1963,9 +1966,35 @@ 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.
%
to implement the power output demand. The result of a failure in these pre or post conditions
would be the heater output being incorrect $HeaterOutputIncorrect$.
As the PWM controls a digital output, this could also fail by sticking HIGH or LOW
resulting in the symptoms $HeaterOnFull$ and $HeaterOff$.
%
\begin{table}[h+]
\center
\label{tbl:heateroutput}
\caption{ heateroutput: Failure Mode Effects Analysis} % title of Table
\begin{tabular}{|| l | l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
\hline
PWM & FC1: Output sticks HIGH & heater always on & $HeaterOnFull$ \\ \hline
PWM & FC2: Output sticks LOW & heater always off & $HeaterOff$ \\ \hline
HEATER & FC3: SHORT & heater always off & $HeaterOff$ \\ \hline
HEATER & FC4: OPEN & heater always off & $HeaterOff$ \\ \hline
\cf{heateroutput} & FC5: post condition fails & software failure in & $HeaterOutputIncorrect$ \\
& in function \cf{heateroutput} & \cf{heateroutput} & \\ \hline
\end{tabular}
\end{table}
%
A {\dc} is created called HeaterOutput, see table~\ref{tbl:heateroutput},
with the following failure modes:
@ -2006,10 +2035,6 @@ The post-condition is that the function \cf{setLEDS} will supply correct indicat
%
A {\fg} is formed from the GPIO, the LEDs and the software function \cf{setLEDs}.
%
FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
%
%
%
%
%
\begin{figure}[h]
@ -2022,7 +2047,7 @@ FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
\end{figure}
%
%
The {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
FMMD analysis is applied to this {\fg} resulting in the {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
$$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$
%
%
@ -2062,6 +2087,47 @@ determined previously:
\end{itemize}
%
The post-condition for the monitor function is that it implements the PID control task correctly.
\begin{table}[h+]
\center
\label{tbl:heateroutput}
\caption{ heateroutput: Failure Mode Effects Analysis} % title of Table
\begin{tabular}{|| l | l | c | l ||} \hline
% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
\hline
\rowcolor{LightCyan}
\textbf{Component} & \textbf{Failure} & \textbf{Failure } & \textbf{Symptom} \\
\rowcolor{LightCyan}
\textbf{} & \textbf{cause} & \textbf{Effect} & \\ \hline
\hline
micro-controller & FC1: $PROM\_FAULT$ & heater always on & $ControlFailure$ \\ \hline
micro-controller & FC2: $RAM\_FAULT$ & heater always off & $ControlFailure$ \\ \hline
micro-controller & FC3: $CPU\_FAULT$ & heater always off & $ControlFailure$ \\ \hline
micro-controller & FC4: $ALU\_FAULT$ & heater always off & $ControlFailure$ \\ \hline
micro-controller & FC5: $CLOCK\_STOPPED$ & heater always off & $ControlFailure$ \\ \hline
\hline
PID & & & \\ \hline
PID & & & \\ \hline
PID & & & \\ \hline
LEDOutput & & & \\ \hline
LEDOutput & & & \\ \hline
LEDOutput & & & \\ \hline
\cf{monitor} & FC99: post condition fails & software failure in & $ControlFailure$ \\
& in function \cf{monitor} & \cf{monitor} & \\ \hline
\end{tabular}
\end{table}
%\fmmdglossCONTRACTPROG
A {\dc} for the standalone temperature controller is now created, and given the name TempController.
It will have the following failure modes: