Created corrections reply document
This commit is contained in:
parent
53e54604d4
commit
8a9d0714f7
@ -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:
|
||||
|
Loading…
Reference in New Issue
Block a user